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

  • 做大型项目的时候, 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 字段都不会有很大影响。

  • 前后分离架构的探索之路 at 2015年09月20日

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

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

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

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

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

  • Dart -我暂时接受不了你 at 2013年12月21日

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

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

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

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

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

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

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

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

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

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