居然发现你们公司离我家这么近

做大型项目的时候，shrinkwrap 是必须的。虽然 npm 的包建议使用 semver 机制，但是你很难保证每个包的开发者都能很好的遵循这个机制。在不锁定的情况下，等于把项目的稳定性交由外部社区管理，这个是多大的风险？被坑过的人都明白这个痛。

shrinkwrap 是根据你当前安装的包的版本来设定的，也就是可能你设置的版本是 ^1.0.0, 但通过 npm install 安装的是 1.0.3，最终实际被写入 shrinkwrap 的也是 1.0.3, 另外有一个 from 字段会是 >=1.0.0 <2.0.0。所以一般生成 shrinkwrap 是你在确定当前的程序能够正常运行以后。如果安装的依赖包版本有冲突，npm 还是会保持树形结构，安装改组件依赖的特定版本；生成的 shrinkwrap 中也列出这个嵌套依赖的特定版本。

另外使用 shrinkwrap 的时候注意生成的 resolved 地址可能是 localhost，这个是因为 npm install 的时候包可能是从你本地缓存中安装的。这样会导致别人拿到你的 shirkwrap 文件以后无法正确安装。所以一种方法是安装插件前用 npm clean 清理下缓存。另一种我经常用的是写一个脚本删除 shrinkwrap 文件中所有的 resolved 字段，这个只要网络正常，有没有 resolved 字段都不会有很大影响。

看到前面说 jsp 的那段的确是很多前端开发人员的痛。不只是过去，现在 jsp 这种后端模板的开发方式还是主流。这也是我为什么做一个fe-dev-server的原因。

前后端分离是一种工程解决方式，不一定是必须。可能觉得不需要分离的人做的项目还没有到那种复杂程度，这也是可以理解的。谈论是否需要前后端分离和谈论是否需要 micro service 一样，只有到了足够的规模和复杂度，才能真正发现这些玩意的价值。简单的一个小项目搞这些可能就是杀鸡用牛刀了。

另外 jQuery 这种库一直会存在，因为有他的使用场景。但 jQuery 这几年已经没有给整个前端带来工程思维上的进步了。前端社区正在追求慢慢接近于后端的工程思维演进，所以才越来越推崇 typescript，virtual dom，flux 等一系列新东西。也许 angular，react 这种所谓的笨重型框架只是整个前端历程中的过眼云烟，但他们给整个前端体系带来的思想变革是值得肯定的。

现在 nz 工资有这么高了吗？看来得回去看看了。另外你说的是 dicksmith 吧

对于不知名的电商，平均 10 pv 都很难

https://github.com/42dev/bower-rails

Google 用 dart 想解决的是 js 的性能问题，而 es6 也只是解决书写的问题，对性能没啥改进。

如果是一个本身就是前端出身的人肯定给出的是完全不一样的看法。

sjr 在我看来无法前后端分工开发，两种语言混写出错率高。

普通网站带上少量 ajax 可以用 sjr，真正的 web app 还是得看 angular，ember，knockout 之类的

我觉得这个还是要看使用场景，大多 gem 是为了解决某个领域的通用问题以简化工作量，所以不可能做到绝对高性能。事情不能一竿子打死了。

比如 devise 不但可以加密，还可以记录登陆 IP，最后登陆时间，email confirm，支持 omnioauth 使用，每一个都是对业务很有帮助的特性，一个个写是不是太麻烦了。

cancan 算不上好的权限控制插件，但做复杂权限管理的时候绝对比自己写 before filter 好。而我也更愿意在一个地方管理所有的权限，这就像一个 map view，可以从业务角度更好的看清权限分配是否合理。

个人觉得 simple form 也是个好东西，至少能让我每次都少些很多 tag，适当的配置下又是一套新的结构了。

我更愿意在写 node 的时候用 coffee，浏览器里还是算了，呵呵

这就回去了啊，还以为你会一直在上海呢

launchpad 的 bug 太明显了。。。。

速度堪忧

#45 楼 @puake 这个观点非常同意，在任何一个领域的积累都是需要很多经历的。it 技术的积累只是其中的一种而已。

@blacktulip 恩，这个就是被成功洗脑的

@Saito 这个说得有点过了，grunt 还是有很多任务插件直接就可以使用，几行配置就够了。对于 bower 完全错了，不明白，请指教

非常同意@xds2000 的说法。code review 本身没什么难的，但要让团队认可 code review 这回事就很难了。这里说的团队不光指技术人员，还有老板，项目经理等。也许技术人员可以通过 code review 得到提升，但是对于很多不是技术出生得老板，经理而言能看到的直接价值几乎没有。推动 code review 认知度是个漫长的过程，得让大佬们尝到甜头。

我觉得应该保持平时什么都关心一下，但学习的时候还是要有着重点。

很多 webpage 都很有创意啊

这天气不开空调太对不起自己了

@blacktulip 光会 javascript 不能说懂前端

无论什么语言，框架都是这样，不光是 rails。资深的程序员应该是掌握解决问题的能力和多年实践的来的丰富经验。

@nightire 非常感谢你的认真回复。我希望 type 的名字是可以和 view 的名字对应的，所以理论上是无限多种 card type, 这个也是我需要的结果。你上面提供的方法貌似不适合我的需求，自定义 helper 应该是个可行的方案。

在自定义 helper 中我没有成功，是否可以帮我一起看下问题：

{{#each card in cards}}
  {{renderCard this card.type card class="card"}}
{{/each}}

Ember.Handlebars.helper('renderCard', function(context, type, card, options) {
    if (type && card)
        return Ember.Handlebars.helpers.render.call(context, type, card, options);
});

我在新创建的 helper 里调用 render helper，不过最后还是报：Uncaught TypeError: Object [object Object] has no method 'match' 的错误。

呵呵，至少从视频上看来，我觉得 7 的设计和很多细节还是很好的。至少苹果敢于跨出这一步就已经是非常有勇气了。设计这东西仁者见仁，智者见智吧。也许大家已经多年来习惯了苹果的原始风格，很难接受新的改变。

canjs 软文吧。

用简单粗暴的方法跑起来先把任务完成就是好的开始

@yedingding 不知道是我的问题，还是 teahour podcast 的时间好像一直存在问题，在我的 iphone 里我看到的排列时间总是旧的在前面，而且时间都是 2001 年 1 月 1 日

做师傅应该是一种公益活动，应该只有喜欢的公益的人才会坚持下去。所以我觉得也别把收费什么的引入进去，几年前师徒类网站失败的大把。

@darkbaby123 你可以尝试下 ng-cloak