#4 楼 @darkbaby123 哈哈，我本来的意思是视频快来了，没想到这次 Confreaks 动作这么快！多谢提醒

YouTube 上有几个 Meetups 的频道过一遍，我记得有 chicago，seattle，boston，nyc，london 等等地区的，其中 nyc 最活跃，里面主持人两个都是 Ember Core 的成员，每个月会更新。去年的 EmberConf 过一遍，今年的 EmberConf 也快来了，记得跟上。另外还有一些零散的比较好的视频，一个比较好的搜索策略是把 Core Team 成员的名字放在 YouTube Twitter 等地方扫一遍基本上都能找到了。

还有就是这里：http://emberwatch.com/ 你可以依此为起点顺藤摸瓜，就不再需要别的 resource list 了。

#55 楼 @riophae 你没注意到宋体的优先级最低么？本文说的方法其实是指如果你要自定义（指明）字体的情况下，应该怎么去定义 font-family。如果你不在乎这一点，认为让系统自己决定就可以了，那完全可以直接一个 serif 或 sans-serif 了事。然而这种完全依赖 serif 或 sans-serif 的方式是有缺陷的。某些浏览器会定义自己的默认字体来覆盖系统的行为，因此会出现在两种浏览器下字体表现不一致的情形。而写宋体，并且把它的优先级安排在最低的意思就是：“如果我声明的字体全部都无效，那就统一给我用宋体”。当然，你可以用别的作为最后的 fallback，本文写宋体呢只是举一个例子而已，并不是强制性的。

#26 楼 @cuterxy 呵呵，不做主观评价谁好谁坏，事实上我也经常用 Jetbrains 家的各种 IDE，我只能说大家都不错，但是不至于“好多了”，也许是因为你不太会配置 Vim 吧？Vim 可以做到和 Jetbrains 一样好，其他的语言我不熟，但至少 Ruby／Javascript 是如此。我举个例子吧，比如说 WebStorm 做语法检查是用什么呢？它允许你使用 JSHint JSLing ESLint 等等常用的语法检查器，IDE 所做的就是把反馈集成到 Editor 的窗口里。那么 Vim 也一样啊，比如说我用的 Syntastic，它本身只是一个语法检查的驱动器，它的功能就是第一：允许为任何一种语言指定一个或多个语法检查器；第二：允许你配置这些语法检查器如何工作，以及 Vim 如何进行反馈。

IDE 会把这些事情事先为你做好，也可以提供给你一定的选项做调整，这自然是极好的，然而你无法做出超出 IDE 能力以外的设置。可是 Vim 不同，它可以做出更多的可控性，对于大多数程序员来说是“没有 Vim 做不到，只有你想不到”。比如说我用 Vim 可以让语法检查的结果反馈通过 Growl 或 Notification 通知给出来——这不算什么，IDE 想做到也不难，但是如果把反馈换成调用操作系统的语音引擎输出呢？甚至可以转换多语言进行语音播报呢？当然 IDE 能做到，但是值不值得去做，给不给你去做，这些是掌握在 IDE 的厂商手中的；而 Vim 是允许你掌握在自己手中的。

我举的这个例子可不是脑洞大开，事实上去年末在日本举办了一个 Vim 爱好者的会议，这个语音反馈提示已经有人做出来了，YouTube 上有现场视频，该作者展示了用日本语反馈单元测试结果的 Demo，真的很牛。

所以说语法检查、自动补全之类的事情对 Vim 来说也不算个事，IDE 会专门针对这些做优化并且让开发者开箱即用这当然是好事，Vim 想要配置到这个水准当然不容易，这是它的劣势。然而不能因此说 Vim 不如 xxx 之类的，这就有点无脑喷了。

#25 楼 @ery 测试驱动和语法检查不冲突，你可以把两者都合并到你的 automation workflow 里，配置好的话也可以通过 Growl 或 Notification 做通知。we are programmers, we can program everything

#19 楼 @ery 我不用 ST，我是 Vim 党，我用 Syntastic。重点是任何靠谱的编辑器必然都会有语法检查的功能或插件，我们写代码要遵循代码规范，但是规范本身并不应该靠人工去检查，也不值得人工去打各种 patch。所以为什么不用语法检查呢？

都不用语法检查的吗？逗号什么的根本不是个事儿啊

好像这张图还真没法说明 --force，图不达意啊

#47 楼 @mogodb 你可以在判断事情的时候不用那么极端吗？前端或 Ruby 一定要非此即彼？没有什么“完全的 XX 程序员一说”，语言是工具，需要用什么就用什么，有选择的时候就可以选用自己喜欢的或根据环境选择合适的。是程序员选择语言而不是语言决定程序员。

个人会选 Ember，但有的时候选择不是完全自由的，公司那么多项目都是基于 Angular 的，让大家完全转投 Ember 不太现实。

选择 Ember 胜于 Angular 的主要原因是对 ES6 的态度，从很多细节来看 Ember 比较贴合标准，而 Angular 即使到了 2，生态链上貌似也要多一个 atscript 才足够好，没有 atscript 的 Angular 2 还有多少魔力尚未可知。通过 ngEurope 2014 传达出的信息来看，atscript 还是不能缺的。

说实话，在 JS 社区对于语言的态度是分成两派的，一派推崇基于上层的扩展甚至“改革”，借助扩展编译器甚至语言的实现来对标准的进化施加影响，个人不排斥但却更喜欢另一派——在标准的基础上不断进取，以实际应用的表现去争取影响标准的进化，而不是借助外力。

另外，Ember 和 Angular 其实都是适合大规模应用框架，一般的项目个人还是倾向于基于 jspm 的 React 方案，目前还在观望 facebook 对于 flux 的进一步动作，或许能给人以惊喜。

除了框架以外，其实 http://jspm.io 才是真正值得每一个人关注的东西，基于 jspm 的 Angular 项目架构目前比较令我满意了，React 也不必说。Ember 有 Ember-CLI，不用费心，这也是 Ember 最大的优势之一。

同志们，是时候关注和认真对待前端项目的工程性了。

#45 楼 @mogodb 也没什么，就是学 Sass 的时候首次接触到了，那时候 node 才刚诞生，对于纯前端来说基本没怎么用过包管理器，记得好像是碰到了 gem 的问题搜索之后来到这里，再然后就被当时各种大牛的文章所吸引开始跳 Ruby 的坑。差不多就这样。

#43 楼 @mogodb 没念过大学。你查户口啊？

#33 楼 @mogodb 不奇怪，我本身就是前端工程师，Ruby 是我的爱好之一，也是我最喜欢的语言。

有点复杂了，就现在这个阶段来说，砍掉一半，先做一半。

#13 楼 @cqcn1991 不是躺枪，但也不是挤兑你。

话说你是否中枪并不重要，重点是人家的确给指了一条光明大道，你若是回一句“受益匪浅”并试着做一做，任谁也不会说你什么了。

大过年儿的压岁钱没少收吧？灵劲儿都哪儿去了？

你不把区别 show 出来，别人也不太好帮你判断原因的。

也有一种可能性是目标页面使用了 Ajax 动态填充内容，这个就不是那么好抓了。

#4 楼 @luikore gulp 有 ruby sass 的插件，名字就叫 gulp-ruby-sass，支持 compass 没问题。

这年头还有不支持 typo checking 的编辑器／IDE？LZ 用什么写代码？

#4 楼 @dimi 我建议你做一做兼职的设计顾问，有很多程序员在现实中迫不得已做着一些“美工”的工作，原因可能很复杂比如说公司不重视没有人帮他们设计界面细节，或者时间紧任务重来不及找人做界面等等。还有一些人出于爱好也好或者是想自己做些东西也好，工作之余也会去开发一些软件产品，这种的话除非有朋友帮忙否则是没有额外的设计资源可以利用的。

所以你可以打个招牌出去，帮这些程序员做一下设计顾问，你可以选择接收设计工作也可以选择只做顾问而不干活，取决于对方的动手能力如何。我个人倾向只做顾问，不要把自己弄成工匠了。至于报酬，互联网时代都好说，给个账号就是了。如果你可以做，我现在就可以给你介绍业务：）

#5 楼 @cjmt 这两本书不是提高审美的，选错了。

keywords: ngAnnotate, gogogo

baseController 秀一下吧，参考参考，多谢～

别想太远，好么？从眼下开始一点点做起，你也可以达到这样的水平。我说太难吧，担心你直接怕了；我说不难吧，担心你问这问那。有些东西不是问问就能学会的，要做。这个应用，看似复杂但是用到的技术并不算很艰深，所谓难者不会会者不难就在这体现出来了。

#7 楼 @betterthornbird 哦？是么，我倒是没这个问题，和路由器有关？

#2 楼 @mogodb 看那玩意干嘛？有好处？单身狗？

我能说就是因为有你这样的客户群体存在么？

两种路数。

Chrome 和 Firefox 在 CSS 上的差异不会太大，有一些老路数有经验之后就心里有底了，所以开发时只用一个就好。到了一定的时候打开两个对比一下就可以，有问题调整起来也很快。而 IE 则要看你的目标版本底线是啥。如果是 9 以上，绝大多数不兼容都是好改的，所以可以定期来做兼容性调试。而对于更低的版本，很多兼容性问题是要以牺牲语义化标签结构和 CSS Hack 来解决的，因此我会使用别的方式写 CSS，比如 IE 注释单独引入样式，或者 IE 专用样式命名空间等等。

比如说像我常年在 Mac 上开发前端，IE 我压根就没开过，全部以 Chrome 为主力，然后其他浏览器分阶段对比。发到测试服务器之后，我让测试以 IE 为主力浏览器去测，然后提交 issue 我来调整就是了。

第二种路数高大上一些，可以使用测试兼容性的云服务，比如 BrowserStack，即时给你反馈不同客户端／浏览器／版本下的页面表现，因为它运行在云端的虚拟机里，你可以只开一个浏览器直接在虚拟机窗口里调试。不过这种方法也有缺点，一是要钱，二是网速慢调起来也费劲。

归根结底还是要看你的 CSS 水平，经验丰富的开始写的时候就非常规范，非常有针对性，使用的方法／技巧都是久经考验的，可能会存在什么兼容性问题心里有数，这样的话脱离 IE 也不是什么难事。

#8 楼 @mogodb 哦，是这样么？我觉得这种底层的基础工具应该一直保持用新版本，遇到重大升级就读一下 Changelog 看看有什么变化，否则总是被各种坑耽误时间太划不来了。