啰嗦一句,事实上如果你考虑的是全端应用, 应该尽量考虑使用 markdown 之类的描述语言, 然后各平台根据自己的情况进行 format 和 display.......

Rei 给出了答案了. underscore.... awesome!

自增 id 和 objectId 各有优劣处.

自增 id 缺点: 容易被人识别从而用机器来爬, 当然这点对于论坛之类的反而是好处. 容易被竞争对手做出统计数据

优点: 站内统计很方便, id 短小, 节约各种资源, 可以用 id 代替 createTime 来排序 等等

objectId 缺点: 太长了,太难记了, 耗费数据库空间和 log 空间

优点: 安全性高, 可以分布式计算,无计算 IO

高并发在很长一段时间内其实根本不是问题, 发帖本来就是少数行为, 即便是 mongodb 的 findAndModify + $inc 的组合,速度也足以支持至少几千个 id 的生成. (我测了下,在我机器大概 1 秒最快能生成 6k 个)

除非需要微博那种发帖量 引致网上

目前我知道新浪微博最高峰 3 万 2 每秒，Twitter 最高峰 2 万 5 每秒。 欧洲杯决赛时，Twitter 峰值 1 万 5 每秒 世界杯刘翔摔倒后，新浪微博峰值 1 万 9 每秒

我倾向于用你充分测试过的代码来控制这些细节.

DBRef 看起来太可怕了. 很难想象如果你某天改了 db 的名字居然会影响到数据库里面的数据..

另外, 一个 id 就能描述的事情居然让你弄成了 3 个字段.

目前网上对 DBRef 的评价不一,但是如果你想以后 sharding 简单一点的话, 请慎重考虑.

IE8 貌似全面悲剧.

Rspec 里面的语法在 JavaScript 里面可以对应 mocha/jasmine + BDD + expectjs/chaijs 等等 在 java 世界可以对应 cucumber framework.

以前的几个项目有要求用 cucumber 来写 selenium testcase, 那个语法 +annotation 写下来的效果几乎就和 BA 在 backlog 里面写的需求验收标准一样.

说实在的,不是 native speaker 恐怕没法意识某些老外对代码可读性的洁癖.

普通的工种过去申请绿卡要排队 5 年,一般志向远大的 ruby 青年恐怕熬不住,而且 5 年后的结果未定,有一定的风险性.

再加上美帝的工资其实还是挺悲剧的, 如果夫妇俩在国内都是中层以上, 移去美国如果不能夫妇两同时工作, 考虑到照顾小孩和租房成本, 那有效收入反而是降低了. 当然,有失也有得, 关键是看自己最最最需要的是什么...... 自由? 新鲜空气? 绿地? 食品安全? 还是在国内热闹嘈杂的环境...

@poshboytl 恩,期待你的后续文章. 作为在中国的 remote 能拿到这个 rate 确实非常难能可贵了.

@poshboytl 抱歉,没有歧视的意思. 这个确实跟你的努力和运气有关. 我所在的是一个 service company,见过挺多的人在 offshore 收入很低,而跑去 onsite 做同样的事情就能拿得很多.. 所以你们那个客户肯拿美国的 rate 给到中国的 freelancer,应该算是挺不错的了.

@huacnlee 14w 到不了的, 除去节假日和公众假日, 一个月最多能工作 20 天. 所以算下来大概 10 万吧.

Freelancer 生病,旅游,请假等等都是没有工资的,还需要自己缴各种保险. 当然好处是可以合理避税,买东西还能退税. 年轻的时候多做 Freelancer 可以多赚很多.

我也歪个楼.... 就一论坛, 又没有啥动态的信息聚合地理位置等等, 速度要是不快,也太对不起 ruby 论坛的面子了.

最早为了解决 SPA 的 SEO 问题, google 和 twitter 共同发明了 hash ban, 只要是有 hash ban 的地方,google 都会认为此页面是一个 router 路径, 会加载页面并执行完 javascript 以得到最终的页面内容.

当然, twiiter 在使用这个解决方案一段时间以后, 最终还是采用了纯路径的 SPA 效果. 技术细节无非就是--- 从某一功能页面进入以后, 所有的链接点击全部拦截掉,使用 router 来替换以达到 SPA 的效果. 如果用户收藏了某个 link 或者直接获得某个 link 进入,则从服务器端渲染出整个页面以及相关的 javascript.

对于搜索引擎而言,只有需要的关键词在 meta 和 body 里面出现,就差不多达到了 SEO 的效果.

这样的实现方案无疑增加了代码的难度, 你必须有前端代码以及后端段代码,还要保证逻辑是一致的.所以 nodejs 的解决方案能够更自然的解决这个问题. 不过很多人取巧, 使用的技巧是当用户直接访问某个 link 的时候, 计算出该 router 需要的数据,直接赋予某个 javascript 变量, 从而最大限度的复用客户端的代码.

至于百度, 目前没看到是否支持 hash ban 的证据, 可能只能通过 lz 说的方法来实现动态内容的 SEO.

IE6,7 就只配享受这样的效果... 嘿嘿嘿

人艰不拆.....

mac 谁用谁知道,terminal 超级好用, 远程或者本机虚拟机,从开发到运维全能. 既漂亮又实用,有 ssd 速度又快,有 retina 效果又靓.

就连开发工具在 mac 下都要漂亮很多, 我说 lz.... 你明白了吗?

清空下 log 试试.. 当然如果是 ssh 的问题那就暂时无解了. sudo rm /private/var/log/asl/*.asl

IE8 就已经好不少了,至少各种 framework 和 UI 都支持到了 IE8. 而且浏览器跟盗版没有丝毫的关系, winXP 最高可以到 IE8, 所以学校不应该拿着个为借口.

最好的打算当然是允许安装 firefox 或者 chrome,这样用户体验就得到了很大的提升.

我家是 HC4000， 3 年前买的， 适合客厅投距比较短的情形。 1080p DLP ，如果眼睛看不到彩虹， 选 DLP 还是挺清楚的，否则就上 3CCD。

楼主不如和我一起等待传说中的 12 寸 retina 小本， 这次没有发布，希望明年初可以上市，和 11 寸大小一致，可能稍重一些。 这是我心中完美的移动工作平台。 就算偷偷带进公司也无人知晓，可以随时带在身上，想写就写。

敏捷开发不正是适合小团队吗？ @liwei78 ，控制好节奏是 scrum master 的事情，在 agile team 里面没有 PM 这个 role。

这篇文章讲的非常生动： http://net.tutsplus.com/articles/editorials/scrum-the-story-of-an-agile-team/

餐馆服务员， 售票员（低级的那种）， 扫地阿姨，运动员， 交通协管员， 城管 等等。 就怕你离开了电脑很久，会盼着有机会上班聊天。

不懂 ruby，但是随便一搜，貌似 HTTParty 的 post body 会 encode json content。 所以多半是那个啥中文被这个 HTTParty 给转成了 \uxxxx 格式了。

我认为这并不是什么阴谋论，而是一个比较好的一个防止服务器奔溃的一个架构策略。

1）在假定大部分用户非前端工程师，无刨根问底的精神的情况下， 只有极少数用户有可能获取真正的抢购 ajax request 并制作成脚本， 可想而知该 request 估计也会通过 referrer 来进行访问保护以增加自动化难度。

2）在假设的范围内，最简单的做法是延缓随机时间，如果服务器同时最多能有 1000 个连接，每个连接要耗时 100ms， 有 10w 人抢， 那么最佳情况是分配 10 秒的队列时间，从而每个人都有机会在这 10 秒内得到 service。 如果不加以限流， 更多的人得到的是 service not available，并且服务器和数据库可能会因为 cpu 100% 而导致性能极度恶化。

如果考虑到用户看到抢购失败会不停重试，情况将更加糟糕。

3）最佳的做法则是根据服务的容量自动设置 backoff 时间， 请参加 wikipedia 这篇文章 http://en.wikipedia.org/wiki/Exponential_backoff 使用这个算法既可以获得最大的 throughout。 这个算法如果实施在服务端也可以避免一定的 DDOS 攻击，至少服务器不会崩溃。

4）通过 javascript 弹框延时的方式，所有的抢购代码都可以部署在 CDN 上， 再多人也不怕进不到抢购页面。 通过 backoff strategy， 用户不会看到 service not available 等页面， 就算退一步连 ajax post 都获取服务失败，页面上的 javascript 还是可以给用户弹个窗说抢购失败（其实是服务器忙死了）。 从而保证了比较良好的用户体验， 至少没死机不是么？

所以总体而言，通过这种方案，估计有个几台应用服务器就能轻松应对足够多的用户抢购了。