比较欣赏 A, 毕竟原帖主的状况有大把人都能做到，但是创出事业的难度要大得多了. 当然在大公司里面混着日子也是挺舒服的。

你说的这些大部分我都做过或者正在做了...

目前我的应用也是轮询，主要是初期做轮询最简单 (考虑到 IE8 的支持，同时不想弄 flash)

现在不但隔行如隔山，隔个运行环境什么的都要先了解半天名词才行. 好在虽然名词不一样，其实道理都差不多。 这种情况下，你就该让他详细的告诉你如何把运行环境在虚拟机或者哪里跑起来，你关心的是黑盒层面上的压力测试，用 ruby, python, nodejs, java ,随便什么，加上 restclient 或者 selienium 就都可以做压力测了。

当然如果是白盒，那还是别插手了，web 专家为啥需要了解你 dll 是怎么部署的。

这个招聘还不错

@Rei less 可以在开发阶段直接引用 less 源码，用 less.js 来解析 (需 IE8 以上), 但是在生产环境，是可以通过 nodejs lessc.js 来编译并混淆成 css.

bootstrap 官方原版内部的 css 用的是 less 来管理。

ruby 的世界就是 sass, coffeescript, amberjs 这些.. 因为语法类似，gem 也多. 当然不做 ruby 的，选择就更中性一点，比方我们就选了 less, 前端编程也不用 coffeescript.

在选择语言方面，个人比较喜欢原生或者语法和原生及其相似并且兼容的语言，这样出错易调试，易于掌控，而且不管用什么，原生语言是必须要了解的。

什么原因不支持 IE8?

10 年前做政府项目的时候，政府里面有个小伙子找了个借口说要用 photoshop, 于是给他 (不是我) 配了台 power G4, 当时能买内环内 5,6 平米房子了.. 口水啊.. 结果后来没两月放那落灰.... 真是无语。

你的 Users 和 Posts 可以分别做成 2 个独立的 js module, 分别配置自己的 router.

1) https://github.com/blueimp/jQuery-File-Upload/wiki/Browser-support

Copy&Paste of images

The following browsers support pasting images from the clipboard:

Google Chrome

2) Use flash

好吧，用 Rails 开发，写两行，改两行，保存，刷新网页，就能看到结果。如果用 Java，嗯，我的机器重启一次 tomcat 需要 1 分 35 秒。如果改了 Java 代码.....你懂的。还有，我用 Java 做网站经常被浏览器缓存恶心到，但用 Rails 很少有这种情况。

lz 说的这些其实都有解决方案，并非 ruby 才能这样。

你可以用 embed jetty, 启动速度超快，代码即环境，调试静态资源非常方便. 至于 java 代码，全部 test driven 基本上启动就应该直接能用了，极少时间需要 debug.

后台代码你完全可以试试 groovy, 支持 closure, 超多 sugar syntax, 完全兼容 java 文件。

asserts 缓存问题，你可能要自己规划下自动构建方式和过程，总归至少开发环境下不是问题. 你被恶心到反而说明你自己没有真的搞明白这块到底是怎么回事。

开发速度也是因人而异的，如今 opensource 如此之多，如果对界面设计要求不高的前提下，说实在的，这几种语言我真心感觉差距不大。花在各种想法和设计的理解上的时间比 coding 时间要多得多。

目前越来越多的项目都是 restful 后台，然后 web 端弱化成一个普通的 client 端. 这样做规模越大越得力，数据和逻辑都是后台，前台负责本地化展现，api 级别是 restful 的，利于扩展。

对于 native app，这么做貌似阻力不大，对于 web 的话，能熟练使用 js 并做测试的人实在太少了，所以接受的难度肯定要大不少。而且 SEO 之类的问题也比较头疼。

我个人是赞同将计算力向客户端迁移的，当然前提是应用要足够成功，越成功的应用，越多计算放在客户端，则需要的服务器维护费用会越少，当用户量超过 10w 以上的时候，差距应该会越来越明显。善用 browser cache, server side cache 等等也是减少 cpu,io 量的一个办法，但是都不如仅仅拿 JSON 那么节省 bandwidth 和计算力。

emoji, 你看看咱的代码...

我备份照片就用这句 rsync -varE /Volumes/Public/Photos/ /Volumes/General/backup_photos

少用 pull, 用 command + T

Anyone who is not an Erlang fan, does not understand OO.

自己做的小应用推荐 mongodb, 这样连 memcache 都省了. 别再纠结了，我就是从 mysql + memcache 全盘用 mongodb 重写的。

啰嗦一句，事实上如果你考虑的是全端应用，应该尽量考虑使用 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 确实非常难能可贵了。