unicorn 是基于进程的。
puma 是基于线程的。
你的代码线程安全吗?如果安全,推荐 puma
我们是 10 Billion 级别了,MySQL 暂时没什么不好的地方。
先用 Ruby 代码把 sysdate -1 计算好,转换好格式。
然后 select * from mz_guahao1 where ghrq > '2017-06-07'
From High performance MySQL.
我坚持每周游泳三次,依然有颈椎病,后来发现其实是有技巧的。保养颈椎,要从多个方面入手。
改掉过度工作学习的习惯。尽量高效工作,定时休息。而且有小孩的朋友,回家后陪儿子玩耍,放松一下也挺好,不一定非要泡在代码里。
游泳,一周 2-3 次。
买了一个网球,松解筋膜。 (每工作一小时,放松一次。)
针对性训练:站立小燕飞(每工作一小时,做 40 个。)
针对性训练:收下巴运动(每工作一小时,做 40 个。)
阻力对抗,训练颈部肌肉。
去永琪办了一张 SPA 卡,每周颈肩按摩一次。我曾经非常不屑 SPA,以为那是富人贪图享受。但按摩过后颈部真的松解下来,建议大家也试一试。
换一个适合自己的枕头。可以托起颈椎、维持弧度、不要太高。首选 tempur 的记忆枕。(切记,不可水洗)
http://www.sohu.com/a/127233952_596550
https://zhihu.com/question/19562063/answer/66488302
http://t.dianping.com/deal/22437236
https://www.zhihu.com/question/19562063/answer/109488185
登峰造极之路
我把你的标题改了,免得给那个垃圾网站带去 seo 流量。
删了,多谢提醒。
@ruby_sky 手工设置的。
我挺喜欢 CodeSchool 的,我也挺喜欢 coursera 的。还是要看创始人的 Big Picture,是为了赚钱,还是为了让更多人有接受计算机教育的机会。
做教育的,还是要真喜欢这个行业,真的是为了让更多人的潜能挖掘出来。做学生的,要知道自己想要什么,别在追逐浪潮中变成炮灰。
为队长这篇文章喝彩。
膜拜。
@teddy_1004 你留胡子比较帅。
继续写起来啊。
ruby china 现在可以靠博文赚钱了 - 打赏功能
写起来!
原来浩哥是身价 50 万的男人。
原来不会连续嵌套呀
有些程序员的满足感来自于打造产品,Rails 确实很能满足这点。
有些程序员压根不在乎做什么产品,他们以美好的代码为食。他们在意高性能、架构。产品只是他们打磨技能的工具,而不是最终目的。
没有好坏之分,只是个性不同。
如果你是后者,我觉得非常不适合做 Ruby 程序员。使用 Ruby 的大都是创业公司。需求之多,根本让你无暇顾及性能问题。
另一个尴尬的事实是:在 Ruby 圈,有 5 个 Ruby 程序员的创业公司的就是豪华团队了。喜欢刨根问底的人会很孤独,很难找到合适的同侪 (导师) 讨论这种底层问题。
有些人因此迷失在迷雾中,永远在很低的游戏关卡徘徊不前。从一家创业公司跳到另一家写 CRUD,接触的用户量永远低于 100 万,永远对全表扫描视而不见,每个列都建索引,永远不知道写的每一行代码的 bigO,更不会知道 1000 万用户时效率。
当然,偶尔运气好的人会有大师提点,比如黄志敏、谢文威。以及在英语流利说遇到优秀的同侪。与其凭运气,还不如选择下面的策略:在一个大的平台写 Java,比如腾讯、阿里。
你虽然一开始无法接触到核心的代码,只能写一些简单枯燥的业务代码。但是你有更多机会和真正的大师协作,疯狂向他们学习。他们在自己领域深耕细作,提点一下就够你学一个月。然后你耐心花 1-2 年进入核心代码组,再磨砺十年成为领域专家。
其次,关于 Rails。我们都没有资格说它不好。因为我们写不出框架,即使写出框架,在生产环境的表现也很糟糕。不是合格的轮子,也没资格自夸。
如果你是 web 开发者,2017 年,我依然觉得 Rails 是值得学习的框架。
过去一年我都在恶补计算机基础知识,每明白一点都感叹:Rails 在做到最佳实践时,还可以如此简洁、高可维护性。
源码里可以学到大量的知识,而且都是计算机基础知识。
比如
等等,数都数不完。
如果你想在计算机领域走的更远,却对 Rails 优秀的设计视而不见,将来也没有能力/可能性写出你的成名作。
就像 Elixir 社区最著名的 web 框架的作者曾经是 Rails 框架的核心开发者。
Maria 的作者曾经是 mysql 的核心开发者。
功不唐捐,在学习上的每一笔投入未来都会有收获。
你的 pros and cons 很有道理。
你可以找一个
行业专家认真讨论一下,让他给你指条明路,然后坚定的走下去。
与其犹犹豫豫,比如按他的路先走下去,边走边调整。
以前是按月付费,现在一次付费,终生享受。
超划算。
可以有一张 custom_fields 表来记录用户自定义 field 的名字。
然后再弄了一张表 custom_field_values 存自定义字段的值。
用户想加几个字段,就加几个字段。
spreadsheet +1
100 次 save 好像是真事。
菜菜发达了
Eric 又造轮子了,鼓掌。
百度统计 google analyti c
都可以拿到这些数据。
已点赞。
顺便有个疑问:
Fault.count
楼主的前两个例子都是全表扫描(select type:all / index)的例子。
在实际生产环境并不多见吧。
大部分情况是 user.faults.count,如果 user_id 索引的 cardinality 比较高的话,速度还是相当快的。
为啥迁