#8 楼 @gellerseu 我也不太明白你哪不明白。是哪些问题呢？

#19 楼 @zgm 我当然知道只是将 id 序列化而已，我只是觉得序列化的字段不适合用来做频繁的检索

#7 楼 @5swords 序列化也有性能问题的吧，有的用户用几千万的粉怎么办？反序列化到内存里再计算不行的吧

#6 楼 @litblaky @hooopo 的方案的什么问题？我觉得这样很好，够简单！ 要查询速度，莫非要用上传说中的“存储过程”，好高深的样子...

比如，装机量是多少？活跃用户在多少？接入应用数量是多少？热门应用用户量级是多少？支付平台交易量是多少？还有各指标的日平均增长是多少百分比...

#2 楼 @mobiwolf 说关注还没到那个程度，只是大致了解了一下； 你的回复里面有好几个“可以参考 XXX，可以看下 XXX”就不能说得更直接点么？ 既然是一个台平，我更希望看到一些统计数据，与其它平台来做对比，总不至于我拿着个手机给 BOSS 说吧 至于你说的‘搜索检索’这个不是微信做不到吧，是做与不做的问题 ‘订阅推送，沉淀用户’这个微信上一直就有的 ‘云端一体，全能体验’里面提到的微信里面着不多也有，只是形式可能不一样 ‘无需下载，即搜即用’在微信里也是那么一回事，公众号一样可以当成一个应用来做

微信着重于与用户间的互动，轻应用也许更着重于应用交互，各自没有互相替代的可能，不知道这样理解对不对

把样式做成 button 的样子

哪些是微信不能做的？活跃人数是多少？已接入应用是多大一个数量级？所谓的‘破壳检索’是不是也有排名问题？电商支付怎么搞？为什么要选‘轻应用’？为什么要 at 我？

ps. 在做微信接口开发前，很早就知道‘轻应用’，我也忘记为什么那个时候没有做‘轻应用’开发了！

:plus1:

一遍看不懂那就多看几遍，照着上面的代码写，先保证能运行，不懂的慢慢消化，web 涉及的东西本来就很多，楼主要着重去做你想做的，不要发散

:plus1:

#4 楼 @autumnwolf 哦，我以为跟 link_to 一样 仔细看你的问题，你是不是想创建一个属于 product 的 line_item 呢？如果是的，那应该写嵌套路由

:method => :post

你不会写 if else ?

<%= text_field_tag 'xxx', @your_result, disabled: true %>

国内服务器托管一般是这样，1U 单线 100M 共享带宽 ￥6000/年 域名备案通过托管商去办会很容易

我有朋友就是自己弄台服务器，然后承接各类建站业务，都放在一台服务器上

https://github.com/plataformatec/devise/wiki/How-To:-Redirect-back-to-current-page-after-sign-in,-sign-out,-sign-up,-update

https://github.com/plataformatec/devise/wiki/_pages

用 jquery-file-upload 直接表单上传到七牛那边，七牛上传后会有回调请求到我的服务器保存图片信息 至于样式，直接可以从 jquery-file-upload 的 DEMO 页面上的效果改出来，这个要自己花点时间慢慢调 CSS

这是多么基础的问题，楼主要搞清楚哪些东西是在服务器上执行的，哪些能在浏览器上执行的

erb 类似于 jsp，用来动态产生 HTML 的，里面的<% %>标签在服务器上就被执行了，返回给浏览器是执行完了的 HTML 结果

你要执行点击一个按钮去执行一个 ruby 代码，这个时候需要发出一个请求到服务器，要么提交表单，要么用 AJAX 方式发一个请求

:plus1:

#14 楼 @Skinnyworm 服务号也是在 48 小时内可以发客服消息给用户，发客服消息只能单个单个的发

快了很多

##Before(0.9.5)
Indexed 3067047 rows | Time spend: 16273.795951065s
Rebuild Index done.

##After(0.9.6)
Indexed 3193919 rows  |  Time spend: 7771.166169973s
Rebuild Index done.

raw http://api.rubyonrails.org/classes/ActionView/Helpers/OutputSafetyHelper.html#method-i-raw

rails3 html_safe

功能不错

:plus1:

#3 楼 @ruby_sky

我们的场景是一个公众号对应完全不同的业务，所以不会在一个 web 程序来接入多个公众号，也不会有太多的公众号

第一个感觉反而弄得复杂了点，里提到的一些功能如自定义菜单的实现不知道不什么要弄到 DB 里，菜单最多也就 15 个，这样设计反而变重了，菜单的变更一般都牵扯到业务的变化，代码肯定要动，这种功能直接写一个 rake 任务，方便部署

对于一些图文消息的回复，简单内容可以直接使用 gem 里面提供的方法，但有时候用 xml builder 可以做更细粒度的控制满足复杂点的需求

可能是我们还没需要你们那么大的业务需求吧

我觉得微信接口虽然设计得并不是很人性化，但相对来说还是相当简单的

个人愚见