客户端的解了吗，前段时间客户端上传下载正常，但是推送是断的

喜欢安静的地方有2类人：
去安静的地方写写代码吧，说不定会有灵感
去安静的地方谈谈情吧，说不定还能野战
前者无害，后者真心就是标一处少一处……

前端的活动送node的书……真把node当前端看了啊

这么说来，在一个叫OSX的软件里捆绑了一堆叫Mail、Message、iTunes、Finder、iXxx软件的某厂商才是最恶心人的？

蛋疼地就为了ios上reeder太好用，只好边疼边等着osx的reeder不想转readkit……

有A站文章和B站视频，想不出做这个有太大必要……带实时聊天和点评的漫画阅读站曾经想做，但发现人家看漫画巴不得全屏没干扰，加上任何聊天还是评论都是满满恶意

难道迅雷再做一做把这东西直接集成进迅雷应用里，而不是以第二个应用的形态出现，就被接受了，而现在这样就不被接受？就从结果和效果上来说这两者没区别吧，看作是应用的一个功能不就好了，和捆绑没什么关系

你看itunes多好一音乐播放软件，硬是给你集成个store好烦人，这也算一种捆绑吧？

家里有一只，平时用来洗洗眼镜，还真没想过原来可以洗别的……明天把magic mouse让它洗洗吧，挺脏的了……

5120*2880这张壁纸实在恐怖，但唯一想得到能和这分辨率匹配的只有现在的iMac27进行retina化的结果了，现在27是2560x1440，retina后正好……但那东西竟然还要提高PPI简直是……

所以其实是这样的，想找个壁纸支持笔记本就16:10，支持外接的thunderbolt display或者imac就16:9，两个都支持请放弃

@wodemyworld 可能理解有些不同，我看到的重点是“数据验证*可以*很简单”，也确实是“可以很简单”，不少系统就是类型、大小、长度的验证。
而后他也说了“业务逻辑会非常复杂”，因此后端的复杂性自然是存在的。
我理解 @refresh 的重点在于：后端的业务是一次编写适应全平台的，而前端是平台定制化的。
假设一个平台下，前端与后端是1:1的工作量（老实说按我的经验前端其实比后端要多的），那么支持ios、android、PC三个平台，就是3:1的工作量，这才是为何前端在未来会更加重要的主因。
当然“后端已死”这话我不爱听，我喜欢全端- -

@wodemyworld 业务逻辑放前端没问题啊，后端也一样有一套就对了。逻辑放前端是为了让用户第一时间、最直观、最有效地获取到业务逻辑产生的信息，而不是真的信任前端产生的数据，把这两事分清楚了再说嘛

接上面，所以与其全本打印，还不如重点把这几个模块弄出来单独印刷，其它的想要的再说

材料的浪费和环境的污染确实是个麻烦事，彩色代码的纸质印刷这方面更为严重……不过比起无端大跃进的工业来说这算个啥

@sdjl 单就jQuery源码这本来说，其实根据我的经验，看jQuery的源码绝对不是学前端的一条好路子，那东西好用但源码的可读性和学习性真心是一个烂啊……

但是jQuery里有几个模块的思想很值得学，分别是：
data：
1. 如何给DOM对象加上数据，但又不把数据直接挂在DOM上产生环依赖造成内存问题
2. 如何给Object.freeze或Object.seal后的对象加数据又不会报错
3. 如何统一对象和DOM的数据存储
4. 如何把数据分隔成内部（给event之类用）和外部（给开发者用）的
event：
1. 如何统一函数调用顺序
2. event namespace的实现
3. delegate（现在的on的一部分）的实现
4. live就别看了这货坑了多少人……
5. 如何模拟capture过程（不知道现在的版本还有没有这东西）
feature：检测特性的基本思路（创造环境、检测差异、得到结果）

别的像attr、prop、dom真心是一堆没意思的拼凑和各种1年能遇上一次了不起的兼容性处理。而Deferred、Callback、ajax又太过复杂越看越容易迷失，实在没必要作为学习而去阅读

@tangzx 没，我是官方控，所以是从nodejs.org下载pkg安装的……

@subpo 再提供个实例吧，什么叫“npm把自己给玩坏了”，大概就是这样：
https://gist.github.com/otakustay/7722436
看到最后几行，npm这个命令已经不存在了对吧……
这个问题的原因其实也不难，npm把npm自己当成了一个全局的包在做事，这种理念我认为是先进的（不对自己特殊对待），但也导致了不少情况下的脆弱性（比如现在）
另外，出现这种错误当然也是有原因的，前面一次更新时，在build一个叫istanbul的库的时候被我给CTRL+C了，随后再进行sudo npm update -g就会成这样
我当然理解npm在包管理这件事上，从理念到实践基本还是能得到高分的，但作为一个程序，它本身是不是脆弱得有点过分了？
好吧为了重现下这问题（老实说还真挺容易出现的），我又得去重装nodejs了

@subpo 我们整个开发体系是在npm之上构建的，我们有内部npm registry。工程师是以逻辑严密著称的，我很想知道从“遇到过npm坏掉和包坏掉”这么自由的事是怎么推理出这个人“不写nodejs”的，或者说脱离的结果是“我在完全无厘头用谎言抹黑npm”吗？
npm自己坏掉是个很稀有且神奇的事，大概前提是这样：
1. 全局安装包
2. 这个包有native东西的依赖，比如karma这种包就会依赖些native的
3. 碰巧npm自己也依赖这东西（这个暂时只是推理，正在慢慢查原因）
4. 这个包在update命令运行时，下载完成后，正在编译安装时，被中断了
此时的表现是，直接没npm这命令了，最简单的方法是重装node，复杂的可以自己去把npm找到link回来
我们的构建平台就是npm上的一个包，依赖包大概100来个，就会出现前面说的问题，最近我正在一个一个排查是哪个依赖的原因，但就这个事实要我说npm是最好的包管理器我无法认同
在我眼里NuGet都不比npm差，纯前端的bow也能和npm打平，这种所谓最好的事情主观因素是不是太大，你有信心说服一个java工程师npm好过maven吗？

@coolicer
@subpo
别来，你说js之下最好也就算了，全业界最好怎么着也轮不到他
另外我没用过会知道npm安装东西失败会把自己弄坏？你真的有试过npm update东西到一半网络突然断掉会怎么样吗，这种先uninstall再下载再install的策略真的是正确的吗？安装带native的包甚至连npm自己都会受影响是对的吗？为何一说npm不好就会变成不写node了呢，不写node会知道npm不好？

@SkYoung 我手上有iPack、BetterZip、Entropy、Keka（我有多蛋疼），我不觉得BetterZip和Entropy能让Windows解压不乱码，而iPack这神坑就更别提了……Entropy的服务菜单还算好用但菜单项太多又删不掉很烦，BetterZip总得来说相当不好用，缺少一个迅速解压和压缩的功能，Keka太丑……
总之总结一下就是，OSX上真心就没有一个能用的压缩管理软件，一个都没有！win上哪怕是流氓HaoZip都比OSX下任何一个要好，好得多！

npm烂得我不太想捐赠……经常装个packget因为网络不通啊平台不对啊失败结果npm自己也消失了，非得重装node去，这是啥水平