#22 楼 @ery 其实两种方式都能用,甚至用在同一个项目中。不过首先要搞清楚主次逻辑。而楼主的代码很明显有一定的误导性,因为 request_send
这个实现逻辑跟 api 放到一起了...
方案一对于 api 和逻辑放到一起的类是有助于理清代码条理的,因为这些 api 方法是无关紧要的。断点也不会打到 api 上,因为这类代码几乎不可能在逻辑上有错。
而方案二则对 api 和实现逻辑分开的情况更有利,比如生成 rdoc。典型案例就是 rest-client
,请求逻辑全部是 Request
的类封装了,而 api 则全部放到 RestClient
模块中,这样查阅代码非常方便,也不会弄混淆。
反编译找地址找 token
我用的是这个 gem : https://github.com/vitalie/webshot 不过它用的 js 引擎 Poltergeist 有点问题,有些超时请求会导致整个 webshot 实例错误。
广告:我的网站就是用这个 http://web-colle.herokuapp.com/
上 mq,在 action 里这么开线程作死
http://www.ruanyifeng.com/blog/2012/02/ranking_algorithm_hacker_news.html
参考这篇,不过你得首先确定什么是优秀的视频。单位时间的点击数?评论数?投票数?确定好每个参数的权重,然后自己尝试公式算法了
没错。
主要是修复存在多个数据库时的错误,因为 ActsAsTaggableOn::Utils
多数情况都是用在测试中,所以一般不会有太大影响。
issus: https://github.com/mbleigh/acts-as-taggable-on/issues/524 pr: https://github.com/mbleigh/acts-as-taggable-on/commit/43970dc2d7fb966cae332a3eaa7f53604cc06c26
与被陨石击中的机率比较的话,已知一个人每年被陨石击中的机率估计为 170 亿分之 1[1],也就是说机率大约是 0.00000000006 (6 x 10-11),等同于在一年内置立数十兆笔 UUID 并发生一次重复。换句话说,每秒产生 10 亿笔 UUID,100 年后只产生一次重复的机率是 50%。如果地球上每个人都各有 6 亿笔 UUID,发生一次重复的机率是 50%。-- 维基百科
总结:先去买顶能挡陨石的安全帽!
rails 比较偏向于 SJR 前端框架的话考虑 backbone 作为主体,加上 react 和 sammy 增强 view 和 router。(好吧,其实这个组合我还没实践过… ember 还没用过 angular1.x 生态圈发展还可以,虽然因为 2.0 和他爹的原因会减点分,但不失为一个靠谱的选择
论元编程的错误用法....
# controller.rb
def create
accessor = instance_variable_get(:@_request)
UserMailer.send :define_method, 'session', -> { accessor.session }
end
个人推荐四楼的做法,当参数传进去吧
并发写不多的话,每月几十万 pv 还是撑得住的
:plus1: 前两天刚升级到 rc,赶紧升级
http://catlog.info/2014/08/22/comfortable-mexican-sofa-quick-start/
我个人比较推荐这个 cms 插件,非常灵活,开发也活跃
我记得你们的简聊是 backbone+react?应该算是国内最早吃螃蟹的团队了,赞一个
contenteditable
之前论坛里有人写过类似的插件。
一般不会让你用 yaml 的,即使这些东西十年不变经理也会要求做成随时修改不用重启的。如果有成熟的 cms 方案,可以直接写 html 代码然后做 cache,否则还是做一个 site_settings 表吧
#5 楼 @MrPasserby 灯厂的微动事故率相当高…
没有,comfortable-mexican-sofa 这个插件倒是可以一试,不过只是提供简单的文章管理功能,你说的那些都得自己写。
这种东西看多了只会对三次元越来越绝望
9.4 关键是为 jsonb 提供更多实用的函数,新类型只是附赠的。
服务器拿去抢票了..
这么良心的贴没人吗?
不知不觉就加精了 XD