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

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

  • 为什么本站不用 ObjectId at 2013年12月01日

    自增 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 貌似全面悲剧.

  • 你不需要这些 Gems at 2013年11月22日

    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 论坛的面子了.

  • Angular 的 SEO 问题 at 2013年11月10日

    最早为了解决 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 就只配享受这样的效果... 嘿嘿嘿

  • 人艰不拆.....

  • 还是关于开发工具! at 2013年11月05日

    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 格式了。

  • 小米抢购页面分析 at 2013年10月19日

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

    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 还是可以给用户弹个窗说抢购失败(其实是服务器忙死了)。 从而保证了比较良好的用户体验, 至少没死机不是么?

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