需要最高效编程，因此需要自己的Visual Studio环境的时候……
不过一般99.99%的时候根本不想打开最高效模式，简直就是用生命在换效率……

@zsj950618 原来程序员不看视频的么，你让v2ex上一帮宅男怎么办

@feikaras Air标称12小时的是13寸的，而我比较的是11寸的，11寸Air官方称9小时，想来到9小时不成问题，12小时有点难了

Flash的问题看来是我们的误解了，原来你指的是Mac分别装OSX和Win，而我在比较普通PC+Win和Mac+OSX……其实要说这问题，总结下来就是：Mac本子的散热真心差- -

@RoshanWu 设计师必须偏激，不偏激怎么出好设计～这样的孩子我很喜欢来着，可惜我没权限招设计师……

@feikaras

1. 确实没法比，2013的Air 11'是标称9小时（我也相信能达到），现款VAIO Pro 11'是标称7小时（我相信达不到），上了Haskwell后我们假定他能达到7小时，也差了近25%的续航时间。不过就“性能相当”这一点来说，VAIO性能相当且更轻是事实，原因是我不认为续航属于性能的一部分
2. 你确定Win和OSX在Flash上发热一样？我用过08年的Thinkpad T61P顶配，我现在手里是rMBP 15'几乎顶配（只少了SSD容量），很明显T61P放一天的Flash手还能放在键盘上轻松打字，rMBP开2小时Flash视频我就不敢长时间打字，乖乖放边上远远地看着
3. 我装了Alfred，我的Sublime开了6个窗口，但我没发现不用触摸板并且能精确定位到某个窗口的方法（直接从terminal打开文件会有另一些问题不详细说了），现在的方案是alfred切换到sublime，四指向下开expose，选择我要的。虽然CMD+~可以换窗口，但是没有一个有效的预览，为了确定当前是不是换对了要看下标题栏很麻烦。而在Windows上，我把sublime给pin在超级任务栏第3个，且排列顺序和sublime打开顺序有关，因此我永远知道“WIN+3+3是我要的那个窗口A”,“WIN+3+3+3是窗口B”，全程是不过脑子的

偶尔凌晨1点2点发个邮件会被经理说加班太多的路过……

我的意思就是，加班可以，把加班当常态也能忍，但这种有事要回家还敢把人叫回来的，我铁定不回头滚得更远些就好了

OSX对我而言最大的优势是terminal，Window就算用git bash或者cygwin都还是不行
而OSX最让我觉得不足的，是没有Windows的超级任务栏，超级任务栏激活应用太方便了，作为工程师一天编码基本都不需要鼠标和触摸板，全键盘就能搞定。诚然OSX的触摸板离得不远也挺好用，无奈毕竟效率上还是玩不过纯键盘

要说娱乐的话，OSX的Flash问题就一硬伤了，我可是想看有弹幕的视频的

@cattyhouse

Air 11' 1.08KG http://store.apple.com/us/mac/family/macbook-air
VAIO Pro 11' 1.92lb约合0.87KG http://store.sony.com/c/Pro-Series-Notebooks/en/c/S_PRO_SERIES_PAGE

配置完全相当，除了VAIO现在还没上haskwell以及没有OSX的优势，续航确实拼不过Air
Air这种铝合金的，就别和Sony这类工业设计大成者一堆玩碳纤维的比重量了……

我们有自己的框架做单页应用，社区ember、backbone、angular之类的一大堆可以做单页呢

@luikore 设计模式和模式是两回事，事件系统的出现就代表了“观察、订阅、分发”这一模式，随后被总结为“设计”模式，仅仅是挂了个名字并总结出一个共性

我们一直在谈的，是“模式”，而不是“设计模式”，这两者有很大的区别。无论是架构、设计还是开发过程，模式是始终贯穿的，而设计模式仅仅是对模式的一种常见的表达方法，取其优而去其粗即可。

所以我才说对“模式”理解成“复制粘贴一坨东西然后改改名字调个顺序”，那就等同于把“模式”和“设计模式”混为一谈，并不是一个值得推广的思路吧

@luikore 赞同“难学就容易维护升级就错了”，但这并不代表“难学就一定不易维护升级”，一定的学习代价确实能换来未来维护升级的优势，我个人也并没有针对楼主单个案例来表明“一定是后续易维护所以你要忍受着”这样的态度，可能是信息传递有些问题。

另外，如果说模式就是“复制粘贴一坨东西然后改改名字调个顺序”，只能说对模式的理解还只限于照着书抄Design Pattern的程度，尚为肤浅。

语言和库的增强，只是将模式变得更容易使用（通过语言特性等解决，比如事件之于观察者），但并不代码就不用模式。如果没有对观察者模式的理解，一个工程师可以设计出使用事件的系统？总之我不这么认为。

@fucktwice 结论我已经表达了啊，代码美观、结构好，代码的仅仅是“学习难度有所提升”，但学习完成后，开发的效率是有非常大的优势的
比如不美观结构一条线的代码，学习只要10天可以上手，以后一个功能开发5天
而美观结构好的代码，学习用了40天，以后一个功能只要2天
这么一算，10个功能是一个转折点

所以我还是更倾向于代码美观和结构合理，除非你们想当临时工

索引正确，链接池控制好，多where比join高效是很普遍的现象，更何况多where还能支持灵活的拆分和分布式数据库部署，join在遇上拆表拆机的时候就是个惨案

学习和接受难度是一回事，学完了以后的工程效率是另一回事
学习曲线陡峭不代表完成学习后依旧要艰难地进行开发
工程师最终负责的应当是整个系统、产品的生产效率，而学习只是其中的一部分，并不是全部

光看贴子顿时被价格上的那逗号给吓到了，还以为ForkLift从Finder工具转型成什么可怕的东西了

http://detail.tmall.com/item.htm?spm=a1z0k.1000775.1.107.1QaBA8&id=13371977276
不知道这东西有没有帮助

https://github.com/less/less.js/blob/master/lib/less/functions.js#L112

先转成HSL色，然后L值加一点，再转回去

显然输出的时候encode才是正确的，假设一串输入是abc，你输入时进行encode变成xyz，随后有人告诉你现在新发现了一个XSS漏洞，其中xy字符是要encode的不然会出问题，请问你要怎么处理数据库中已经有了的数据？再encode一次的话输出就出错了，不encode的话输出又是XSS漏洞