在春节前后，经常在社区中看到有关年会抽奖程序的讨论，其中抽奖的公平性是被大家讨论得最多的点。可能有的人会说可以用 random.org 来取随机数，的确这个网站可以保证数字的随机性，但如果访问 random.org 的浏览器位于一台计算机上，如何证明这个随机数确实来自 random.org 呢？如何确定这台计算机从软件到硬件、从操作系统到网络接口都没有被动过手脚呢？所以我们需要一种「可验证」的随机数生成算法，即这个算法不应该是运行在单个设备上的，而是可以在不同的设备上多次运行，并且总是得到相同的结果，这样才能被大家信服 —— 每个人都可以在自己的设备上进行验算。其实说来直接使用比特币下一个区块的 hash，或者股市收盘价格作为随机数是最简单、最具有可行性的做法了。但这并不是说比特币（矿工可以有选择性地提交区块来影响随机数）或股市不能被操控，而只是相对于我们的年会抽奖来说，他们的体量都太大了，去操控比特币或股市是不划算的。于是我想能否利用之前了解到的去中心化和区块链的知识，来实现一个去中心化的、可验算的、难以操控的抽奖程序，让这个抽奖程序以分布式的方式运行在所有参与者的设备上，会有一个后端服务器帮助客户端进行广播，但本身没有特权，客户端会对随机数的产生过程进行验算，确保没有人作弊。其实在 Ethereum（一个类似比特币的区块链）上已经有了非常成熟的随机数生成器，它基于「两阶段提交」 ...继续阅读 (10)

Stream是我在 2016 年中旬完成的一个业余项目，它希望提供一个基于发布、订阅模型的消息服务，提供 HTTP API 并传输结构化的数据（JSON）。适用的场景就是自动化工具间的通讯（例如两个运行在 NAT 内的脚本需要交换数据）、自动化脚本需要推送数据给人阅读（人可以在 Web UI 上阅读消息）。还更进一步希望能够提供移动平台的客户端，对于已经订阅的消息实现实时的推送，不过这个部分并没有完成。其实也是因为这个项目被搁置了很久，在最近我也发现了一些和 Stream 非常相似的服务（getstream.io），所以才将这个半成品发布了出来。目前 Stream 的 Web UI 可以发布、以时间轴查看消息、按照标签检索消息；HTTP API（文档位于Stream API Reference）还提供了注册和登录帐号的功能，登录帐号后发出的消息会包含你的用户名作为特殊的标签。当然，就像我其他的业余项目一样，Stream 其实更多地是在实践一些新的技术，比如基于 React 的双端渲染、React Native、RAML、Docker Swarm 等等。 ...继续阅读 (3)

Stream是我在 2016 年中旬完成的一个业余项目，它希望提供一个基于发布、订阅模型的消息服务，提供 HTTP API 并传输结构化的数据（JSON）。适用的场景就是自动化工具间的通讯（例如两个运行在 NAT 内的脚本需要交换数据）、自动化脚本需要推送数据给人阅读（人可以在 Web UI 上阅读消息）。还更进一步希望能够提供移动平台的客户端，对于已经订阅的消息实现实时的推送，不过这个部分并没有完成。其实也是因为这个项目被搁置了很久，在最近我也发现了一些和 Stream 非常相似的服务（getstream.io），所以才将这个半成品发布了出来。目前 Stream 的 Web UI 可以发布、以时间轴查看消息、按照标签检索消息；HTTP API（文档位于Stream API Reference）还提供了注册和登录帐号的功能，登录帐号后发出的消息会包含你的用户名作为特殊的标签。当然，就像我的其他的业余项目一样，其实更多地是在实践一些新的技术，比如基于 React 的双端渲染、React Native、RAML、Docker Swarm 等等。 ...继续阅读 (6)

我一直热衷于做一些奇奇怪怪的数据统计 —— 今年一整年我统计了我的每一笔支出，并在此做一个分析，感谢Expense这个小巧的记录工具和 Excel 这个分析工具。总览类别金额比例备注数码2870022%手机、电脑等房租水电2375519%餐饮2285618%网络服务1462011%云服务或订阅制软件零食75536%礼物46574%玩具45754%仅包括非电子产品皮蛋豆腐43843%交通41353%软件游戏28512%非订阅制软件和游戏生活用品25672%医疗22372%数字内容21292%电影、电子书等衣物个护13191%旅行娱乐12761%住宿费用和线下娱乐活动实体书7260%数码果然最多还是花在数码产品上，其中 58% 花在了苹果的产品上。项目金额比例备注iPhone SE * 2817628%第一个 SE 到手一周就被盗了MacBook Pro507318%公司报销了很大一部分XPS370813%基本没怎么用就转手了iPad288810%4k 显示器23998%房租水电项目金额比例平均每月房租2070087%1725电费296612%247水费890%7餐饮仅包括正餐，也包括请人吃饭；今年大部分早饭是在家煮咖啡吃饼干，并没有计入餐饮分类，午饭和晚饭则几乎全部是在外面吃的，没自己做过饭，这让这个统计变得十分简单。项目金额比例平均每日平均每次晚饭1444963%4045午饭806 ...继续阅读 (8)

我一直热衷于做一些奇奇怪怪的数据统计 —— 今年一整年我统计了我的每一笔支出，并在此做一个分析，感谢Expense这个小巧的记录工具和 Excel 这个分析工具。总览类别金额比例备注数码2870022%手机、电脑等房租水电2375519%餐饮2285618%网络服务1462011%云服务或订阅制软件零食75536%礼物46574%玩具45754%仅包括非电子产品皮蛋豆腐43843%交通41353%软件游戏28512%非订阅制软件和游戏生活用品25672%医疗22372%数字内容21292%电影、电子书等衣物个护13191%旅行娱乐12761%住宿费用和线下娱乐活动实体书7260%数码果然最多还是花在数码产品上，其中 58% 花在了苹果的产品上。项目金额比例备注iPhone SE * 2817628%第一个 SE 到手一周就被盗了MacBook Pro507318%公司报销了很大一部分XPS370813%基本没怎么用就转手了iPad288810%4k 显示器23998%房租水电项目金额比例平均每月房租2070087%1725电费296612%247水费890%7餐饮仅包括正餐，也包括请人吃饭；今年大部分早饭是在家煮咖啡吃饼干，并没有计入餐饮分类，午饭和晚饭则几乎全部是在外面吃的，没自己做过饭，这让这个统计变得十分简单。项目金额比例平均每日平均每次晚饭1444963%4045午饭806 ...继续阅读 (16)

今年年初我花了三个月的业余时间用 Laravel 开发了一个项目，在此之前，除了去年换工作准备面试时，我并没有正经地用过什么 PHP 框架。在我看来，Laravel 其实并没有太多的独创性，而只是把其他社区中那些被实践证明非常有价值的东西带到了 PHP 社区，例如自动测试、包管理、依赖注入等等。回到 PHP 本身，PHP7 无论在语言特性还是性能上都无可挑剔，我觉得限制它的使用的更多的是在异步模型上 —— 或者说它缺少一个好的异步模型。也许有人觉得 Node.js 的事件队列十分难以捉摸，但由于 Node.js 是我在生产环境使用得最多的语言，我十分熟悉 Node.js 的异步模型，对其他「普通」的语言的异步模型却比较难以接受。今年我在 Openresty 中写了一些 Lua 代码，对 Lua 的协程也有了一些简单的了解，同时我也了解到在 Python 中被使用最多的异步模型同样也是基于协程。协程最大的好处是不会对代码有侵入性 —— 你写代码的时候依然是照常地写同步代码，只需在执行的时候引入协程（对于 Web 服务就是在每收到一个请求的时候启动一个协程）就可以享受轻量级进程的好处，用更低的 CPU 和内存开销来支持更高的并发。相比之下 Node.js 的异步代码则是显式的，需要时刻考虑异步的问题，也很容易出现疏忽和错误。而且异步的函数是有传染性的，如果你调用了一个异步函数，那么后面 ...继续阅读 (8)

今年年初我花了三个月的业余时间用 Laravel 开发了一个项目，在此之前，除了去年换工作准备面试时，我并没有正经地用过什么 PHP 框架。在我看来，Laravel 其实并没有太多的独创性，而只是把其他社区中那些被实践证明非常有价值的东西带到了 PHP 社区，例如自动测试、包管理、依赖注入等等。回到 PHP 本身，PHP7 无论在语言特性还是性能上都无可挑剔，我觉得限制它的使用的更多的是在异步模型上 —— 或者说它缺少一个好的异步模型。也许有人觉得 Node.js 的事件队列十分难以捉摸，但由于 Node.js 是我在生产环境使用得最多的语言，我十分熟悉 Node.js 的异步模型，对其他「普通」的语言的异步模型却比较难以接受。今年我在 Openresty 中写了一些 Lua 代码，对 Lua 的协程也有了一些简单的了解，同时我也了解到在 Python 中被使用最多的异步模型同样也是基于协程。协程最大的好处是不会对代码有侵入性 —— 你写代码的时候依然是照常地写同步代码，只需在执行的时候引入协程（对于 Web 服务就是在每收到一个请求的时候启动一个协程）就可以享受轻量级进程的好处，用更低的 CPU 和内存开销来支持更高的并发。相比之下 Node.js 的异步代码则是显式的，需要时刻考虑异步的问题，也很容易出现疏忽和错误。而且异步的函数是有传染性的，如果你调用了一个异步函数，那么后面 ...继续阅读 (13)

转眼间又一年过去了，说实话，我的 2016 年并不是非常有趣，这一整年我都是一个人住在昆山，显得有些单调，而且因为刚刚写了一篇「20 岁的我在想些什么」，所以可以写在年度小结中的内容实在是不多了。因为皮蛋豆腐需要照顾，原打算春节就不回家了，但后来计划有变，我提前了一周休假回家，拜托同事帮忙照顾皮蛋豆腐。然后在家待了一周，除夕赶回苏州 —— 再帮忙照顾同事家的两只猫，这也是我第一次一个人过除夕，有了皮蛋豆腐现在并不能很随意的出游算是一个遗憾，虽然自动喂食机和滤水器还是能应付一到两天的。今年年初皮蛋豆腐分别做了绝育手术，一切也还算顺利。很多人说猫绝育后会变胖，因为我喜欢身手矫健的猫咪，所以我对皮蛋豆腐的体重还是很在意的，于是一整年我都在用厨房秤精确地控制它们的猫粮，最后它们的体重稳定在了 3.5 千克，我还是很满意的。皮蛋豆腐长大成为成年猫咪之后比之前稳重了一些，但依然还是会撕开我的零食、在房间里跳来跳去，所以我还是不得不在一些时候把它们关到阳台上。今年作息时间规律了一些，虽然依然是晚睡晚起，但相比之前两年还是规律了很多。晚上睡不着觉的问题依旧没什么改善，而第二天早上又要上班，这一度导致在上半年我的平均睡眠时间只有六个半小时；后来下半年因为意识到了视力的重要性，将睡觉时间提前了一些，睡不着就在听一档关于英语学习的播客，效果还不错；今年的最后两个月，我的房子附近开始有非常大的噪音 —— ...继续阅读 (14)

转眼间又一年过去了，说实话，我的 2016 年并不是非常有趣，这一整年我都是一个人住在昆山，显得有些单调，而且因为刚刚写了一篇「20 岁的我在想些什么」，所以可以写在年度小结中的内容实在是不多了。因为皮蛋豆腐需要照顾，原打算春节就不回家了，但后来计划有变，我提前了一周休假回家，拜托同事帮忙照顾皮蛋豆腐。然后在家待了一周，除夕赶回苏州 —— 再帮忙照顾同事家的两只猫，这也是我第一次一个人过除夕，有了皮蛋豆腐现在并不能很随意的出游算是一个遗憾，虽然自动喂食机和滤水器还是能应付一到两天的。今年年初皮蛋豆腐分别做了绝育手术，一切也还算顺利。很多人说猫绝育后会变胖，因为我喜欢身手矫健的猫咪，所以我对皮蛋豆腐的体重还是很在意的，于是一整年我都在用厨房秤精确地控制它们的猫粮，最后它们的体重稳定在了 3.5 千克，我还是很满意的。皮蛋豆腐长大成为成年猫咪之后比之前稳重了一些，但依然还是会撕开我的零食、在房间里跳来跳去，所以我还是不得不在一些时候把它们关到阳台上。今年作息时间规律了一些，虽然依然是晚睡晚起，但相比之前两年还是规律了很多。晚上睡不着觉的问题依旧没什么改善，而第二天早上又要上班，这一度导致在上半年我的平均睡眠时间只有六个半小时；后来下半年因为意识到了视力的重要性，将睡觉时间提前了一些，睡不着就在听一档关于英语学习的播客，效果还不错；今年的最后两个月，我的房子附近开始有非常大的噪音 —— ...继续阅读 (11)

从 2014 年末开始开发的一个互联网金融项目终于在今年三月份上线了，这是一个 Node.js 编写的 Web 服务，但上线仅仅是个开始，之后的半年时间我们仍在这个项目上进行着密集地开发。就像2014 年度的技术小结中提到的，2014 一整年我都在进行有关自动测试的实践，经过几个项目的积累，这个项目从头至尾都有着覆盖完整的自动测试，我所有的调试工作也都是借助自动测试完成的，我甚至没有在自己的电脑上运行过这个项目的前端页面。因为路由层面受业务影响很大，经常修改一些功能的行为，所以后来大部分测试都是针对 Model 层面的单元测试。这个项目使用了一种「以数据结构为核心」的设计，所谓数据结构就是一个 JavaScript 的 Object, 对应着数据库中数据表的各个字段，这些代表着业务实体的 Object 在项目中的各个函数之间传递。绝大部分函数的参数和返回值都是这种 Object, 它们在这些 Object 上获得或修改数据，并将这些 Object 与数据库同步，即使需要传递额外的数据，也是将数据作为属性附加到相关的 Object 上。可以说这是一种非常 JavaScript 的风格，因为这些 Object 非常近似于数据库中的一行记录，所以在单元测试中很容易构造，非常大地简化了单元测试中「构造特定环境」的这个步骤 —— 函数的输入和输出都是特定结构的 Object, 这对于 Jav ...继续阅读 (10)

这篇文章由我 3 月末在 LeanCloud 进行的技术分享整理而来，假定读者已有基本的密码学知识且对 Bitcoin 的实现有初步的了解。Blockchain 也叫区块链，可以认为它是 HashTree（散列树）的一种，也正因如此它有着一些和 HashTree 相同的性质：图片来自http://happypeter.github.io/bitcoin_basics/book/017_merkle_tree.html即在一个树状结构中，每个末端节点都有一个散列值，而非末端节点的散列值则是由其所有直接子节点的散列值散列而来，因此每个节点都直接或间接地包含了其所有子节点的信息。进而，只要任意一个末端节点的散列值变化，其所有父节点的散列值都会发生变化，根节点也必定变化。我可以举一个有关 HashTree 的应用：「100% 准备金证明」，它属于「零知识证明（Zero-knowledge proofs）」的这一类问题。我们可以考虑这样一个场景，Bitcion 的持有者为了进行交易，需要将 Bitcoin 寄存在交易所，理论上交易所可以将这笔钱（所有用户寄存的账户余额）挪作它用，这是用户们不希望看到的，而交易所也希望自证清白：交易所首先公布一个自己所持有的 Bitcoin 地址，供大家确认交易所确实持有这么多 Bitcoin 作为准备金，但如何证明这笔钱确实大于所有用户余额的总和呢？换句话说 ...继续阅读 (13)

有人说「JavaScript 是花了 10 天时间匆忙被设计出来的语言」，也有人说「凡是能用 JavaScript 写出来的，最终都会用 JavaScript 写出来」。写这篇文并非要对 JavaScript 做一个全面的优劣分析，而是想与大家分享一些存在于 JavaScript 及其生态系统中的、在我看来比较有趣的闪光点。插件化的语言特征JavaScript 曾经是一门兼容性最糟糕、升级最困难的语言。开发者们要苦等到所有用户都升级了浏览器，才敢使用新版本的特征。然而在最近几年，随着Babel等编译器的兴起，越来越多的 JavaScript 开发者们都放开了手，开始在生产环境中使用那些尚未被纳入标准的语言特征了。使用了 Babel 的项目需要在发布之前引入一个「构建」的步骤，将使用了较新的语言特征的源代码转译为兼容性更好、被所有浏览器所支持的早期版本的 JavaScript，所以开发者就不必再去关心用户的浏览器是否支持这项新特征了。Babel 是一个开源的、插件化的编译器框架，JavaScript 的每个语言特征（包括那些还未被纳入标准的）都被实现成了一个插件，插件可以遍历和替换AST，进而对编译的结果施加影响。令人兴奋的一点是 Babel 让语言的特征形成了模块化，也就是说开发者可以在构建脚本中来配置要使用的语言特征。Babel 的出现大大加速了 JavaScript 的进化。因 ...继续阅读 (13)

这篇文章由我 6 月末在 LeanCloud 进行的一次技术分享整理而来。我高一的时候曾读过一本「代码的力量：C/C++ 中国象棋程序入门与提高」，也想自己试着实现一个，连名字都想好了，就叫 Wizard Chess —— 哈利波特中的「巫师棋」。然而直到最近借着 AlphaGo 的热度，我才真正动起手来，代码开源在GitHub，因为是纯前端程序，所以你可以直接访问托管在云引擎上的 Demohttp://wizard-chess.leanapp.cn.国际象棋是一种「透明」的、「没有随机元素」的博弈游戏，所谓「透明」是说在任一时间，博弈双方对局面的了解都是一致的（而不像牌类游戏看不到对方的手牌），大部分棋类游戏，例如五子棋、围棋都是如此，这类游戏需要的是非常强的逻辑推理能力去预见若干回合之后的局面，本文介绍的方法也大体适用于这些棋类游戏。在技术选型上，我选择了用 TypeScript 来编写核心代码以便可以同时运行于浏览器和 Node.js, 借助 TypeScript 的编译期类型检查，可以让我们更早地发现和类型有关的错误，同时 Chrome 本身也有着非常好用的调试器和性能分析器来查找性能瓶颈。前端方面我选择用 React 来编写 UI, Web Worker 来运行计算 —— 毕竟如果在主线程进行 CPU 密集的运算会阻塞事件循环。最近一段时间，我发现在这种偏重于数据结构的程 ...继续阅读 (9)

我们经常看到网络上有很多黑程序员的段子，但那不过是一群居心叵测的人散布的谣言，企图通过给新人们留下负面的印象，进而阻止更多人进入这个行业的方式，来保证不思进取的自己不会被行业淘汰。解决问题的途径比得到结果更重要解决问题是一个通用的能力，本应在学生时代习得，若是不擅长解决问题，怕是短时间内很难提升，但在一个具体的领域里，往往「途径」更加重要。当你在一个论坛或社区提出一个问题时，有些惜字如金的大牛会直接丢给你一个链接，不会多留下哪怕半个字，不要小看一个链接，它可能比直接告诉你答案更有价值。当你进入一个新的领域，遇到问题时往往不知道应该去哪寻找答案，这时候你会想如果有一个网站，列出了作为新手可能遇到的一切问题该多好。但世上没有这么好的事情，往往这些问题和解答分散在不同的网站上 —— 从这个链接就可以点过去。不要相信一句话就可以描述的真理网络上的大牛经常提出提出一些简洁有力的口号，例如「抽象可以解决计算机领域的一切问题」、「好的代码不需要注释去解释」、「动态类型语言才能提高编码效率」、「PHP 是世界上最好的编程语言」等等。并不是说这些观点是错误的，但它们就像「苹果总是会落到地上」这种简单的理论一样，描述的情况是片面的，而非普适的。有些结论是前辈们花了大量的时间和精力探索出来的，但光知道一个结论对你的编程是没有太多指导意义的，更多的细节隐藏在得出这个结论的过程中。所以如果提出这些观点的人没 ...继续阅读 (6)

从年初开始我就希望今后每年写这样一篇文章，如果说「年度小结」和「年度小结（技术方面）」代表了我这一年做了什么事情的话，那么这个系列的文章会聊一聊我这一年在想些什么。每当我生病或者身体不舒服的时候才会去注意一下自己的身体和健康，重新审视自己的生活状态，改变一些不健康的习惯。虽说不如早点这样做，不过现在也不晚吧，也许大家年轻的时候都是这样挥霍过来的吧。有一点可能是我之前没想过的，虽然公司不加班，但其实我做业余项目、写文章、准备演讲，和加班对身体的影响可能是差不多的。感觉自己赚那么多钱也没什么意义，也许应该放慢一点节奏，多出去走走，时不时请几天假来做自己喜欢的事情？今年最令我担忧的是眼睛，虽然视力变化不明显，但总有一种感觉不如以前看得清楚了，眼睛也比以前更容易疲劳了。去医院也检查了两次，医生都说只是用眼过度，没什么大问题，要尽量减少看屏幕的时间。确实今年年末我也是这样做的 —— 碎片时间和晚上睡觉前不再看手机了，睡眠时间也增加了一个小时左右，但一想到将来的工作和娱乐都会非常依赖视力，还是感觉有一种非常大的压力。收入高了之后也就适应了这样的生活，虽然我并没有在追求这些，但钱的确给了我很多自由：可以周末毫无目的地跑到另外一个城市闲逛，可以买一些即使自己用不上的东西而不必精打细算，可以用最好的猫粮来把皮蛋豆腐喂得油亮油亮的。但赚钱的过程本身又是在限制自由，有时候也觉得自己的钱够多了，没必要为了 ...继续阅读 (7)

一个人住有一年时间了，也养成了听播客的习惯，我最喜欢的是 IPN 一档叫「太医来了」的播客，同时我也听过「内核恐慌」和「 Teahour 」这样的技术类播客，听久了也有自己录一档播客的冲动。终于经过了很多的准备工作之后，我把这个想法付诸实践了，播客的名字叫「彩排」，你可以在 iTunes 直接搜索，也可以访问caipai.fm在线收听和下载。如果有任何的建议意见，可以发邮件到feedback@caipai.fm。前三期的主题分别是「自由软件和许可证」、「番茄工作法」、「密码和互联网安全」，我本不想把它限制为一个技术类播客，但我所了解并且可以分享给大家的恐怕大部分都是技术方面的话题了。接下来的选题可能会包括： Email 、 JavaScript 、比特币、养猫等。因为我本来不善言辞，也没有音频录制和剪辑的经验，最后效果其实不是很理想，还不能与开头提到的几档播客相提并论。但在这前三期的制作中，我的水平也在一点点提高，期待将来能越做越好吧。此外我感觉一个人讲会让听众有一种「压力」，可能还是两个人以对话的方式录效果会更好，如果你希望参与进来也欢迎和我联系。 ...继续阅读 (6)

源自我在知乎对你们的 JavaScript 学习开发之路是怎样的？的回答，补充了一些对时下热点问题的看法。JavaScript 和方言三年前，我当时作为服务器端工程师，从未系统地了解过 JavaScript，只是在少数需要改前端页面时才写过几句 JavaScript，正是因为这种不了解，写起来觉得很烦，也不喜欢 JavaScript.但因为工作需要开始学习 Node.js，项目是用 CoffeeScript 写的，显然这又是一个我没见过的东西，但时间很紧，只看了一天 CoffeeScript 就开始写代码了，的确 CoffeeScript 的宽容度要比 JavaScript 好很多，语法很直观，也避开了 JavaScript 的一些坑。写了大半年 Node.js 之后我喜欢上了 Node.js 和 CoffeeScript，但我依然不太喜欢 JavaScript，但毕竟代码最后是要被编译到 JavaScript 的，所以我还是认真地读完了「JavaScript 语言精粹」和「JavaScript 权威指南」。权威指南虽然很厚，但其实通篇都是平铺直叙的介绍，读起来并不是很累，小节之间关联也比较少，很适合碎片时间阅读。什么，你说权威指南太重了？不过我看的是电子版。后来继续写了两年 Node.js，此时我 JavaScript 的编码经验依然为零 —— 我全部的代码都是 CoffeeSc ...继续阅读 (7)

这篇文章由我十月中旬在LeanCloud和十月末在Node Patry 杭州进行的技术分享整理而来。Atom 是 GitHub 在 2014 年发布的一款基于 Web 技术构建的文本编辑器，我从 2014 年末开始使用 Atom 完成我的全部工作，对 Atom 很是喜爱，也创建了 Atom 的中文社区、翻译了一部分 Atom 的文档和博客。今天我将着重介绍 Atom 背后的故事，包括底层的 Electron、如何对 Atom 进行定制、Atom 的插件化机制、Atom 在启动速度和渲染性能方面的优化等。GitHub 的联合创始人之一 Chris Wanstrath 自 2008 年便有一个想法，希望使用 Web 技术构建一个像 Emacs 一样赋予开发者充分定制的能力的编辑器。但当时他忙于他的主要工作 —— GitHub，所以 Atom 一度被搁置，直到 2011 年，GitHub 添加了一个使用 Ace 实现的在线编辑代码的功能，这重新点燃了 Chris Wanstrath 对 Atom 的热情，于是他开始在业余时间开发 Atom。在 2011 年末，Atom 成为了 GitHub 的正式项目，也有了一些全职的同事加入，最后在 2014 年初 Atom 正式发布了，并于 2015 年发布了 1.0 版本。所以 Atom 有什么亮点呢，我总结了这样几点：像 Sublime Text ...继续阅读 (7)

强类型 Vs. 弱类型强和弱是一个相对的概念，强是指倾向于将未定义的行为视作错误（Java、Python），弱是指倾向于进行隐式的转换、忽略类型相关的错误（JavaScript）。很多设计得不够严谨的语言，虽然大多数情况下（或者我们通常鼓励大家这么做）是强类型的，但也有弱类型的部分（PHP）还有的语言因为提供的抽象能力很弱，我们不得不去用弱类型的部分（C）鸭子类型（duck typing）是强弱类型的一个折中（常见于动态类型中，例如 Python），兼顾了灵活性和严谨性。我们认为弱类型是为了方便，而强类型是为了尽早发现错误。动态类型 Vs. 静态类型静态类型的变量的类型是在编译时确定的（C++、Java）；动态类型的类型是在运行时确定的（JavaScript、Python），例如你可以在一个 if 的两个分支里给一个变量赋值不同的类型。有的动态类型语言也会添加编译期的类型检查（TypeScript、Python），但因为语言本身的动态性，这些检查仅能覆盖一部分情况。在动态类型的语言中因为类型不那么重要，所以很多时候甚至没有提供指定类型的语法（隐含了运行时的自动推导）；而在静态类型语言里通常需要为变量指定类型，所以才有了编译期自动类型推导来提供便利，而动态类型语言则做不到这一点（因为不能在编译期确定类型，更无从推导）。我们认为静态类型有助于在编译时发现有关类型的错误，确定的类型也给了 ...继续阅读 (11)

在 LeanCloud 的控制台和文档中大家会接触到「并发连接数（Concurrent Connections）」这个衡量服务器负荷或处理能力的概念，但很多人并不了解什么是并发 —— 甚至在我们团队内部，很多没有服务器端开发经验的工程师对这个词的理解也不是很准确。我们还在继续优化文案来减少用户的困惑，但与此同时不如听我仔细介绍一下并发这个概念。和并发相关不得不提的一个概念就是 QPS（Query Per Second），QPS 其实是衡量吞吐量（Throughput）的一个常用指标，就是说服务器在一秒的时间内处理了多少个请求 —— 我们通常是指 HTTP 请求，显然数字越大代表服务器的负荷越高、处理能力越强。作为参考，一个有着简单业务逻辑（包括数据库访问）的程序在单核心运行时可以提供 50 - 100 左右的 QPS，即每秒可以处理 50 - 100 个请求，LeanCloud 目前也是按照请求数量进行收费的。但 QPS 只能粗略地衡量请求的数量，完全不关心服务器处理每个请求的开销。例如一个命中缓存的请求和一个需要进行多次数据库查询的请求的开销可能会有一个数量级的差距，所以 QPS 并不能十分精确地衡量服务器的负载或处理能力，因此我们引入了一个非常抽象的概念 —— 并发。大部分请求的响应时间在 15 - 30 毫秒左右，这里的响应时间是指服务器处理这个请求所花费的时间，从客户端测量 ...继续阅读 (10)

GraphQL是 FaceBook 开源的一套数据查询语言，也是Relay钦定的组件，可以在客户端以一种非常灵活的语法来获取数据，但目前支持 GraphQL 的服务还比较少，最近GitHub 也宣布了其开放 API 支持了 GraphQL。因为 GraphQL 的支持需要服务器端的更改，因此我选择了在 LeanCloud 的数据服务的基础上用 Node.js 编写一个中间层，运行在云引擎上，将 GraphQL 的查询翻译成对 LeanCloud SDK 的调用，为客户端提供 GraphQL 支持。我也参考了其他语言和框架的 GraphQL 支持，它们都需要开发者进行很多的开发或配置工作。这是因为无论在 MySQL 还是 MongoDB 中都并没有记录数据之间的关联关系（Id 和 ObjectId 都不会记录指向的表或集合，MySQL 的外键倒是会记录，但可惜用户不多）；而且即使你定义了数据之间的关联，你还是需要去定义权限 —— 哪些用户可以访问哪些数据。而 LeanCloud 的 Relation 和 Pointer 都记录了所指向的 Class，同时 LeanCloud 本身也有一套基于 sessionToken 和 ACL 的权限控制机制，因此我们完全可以做到从 LeanCloud 的数据服务获取数据之间的管理，然后遵循现有的 ACL 来自动实现对 GraphQL 的支持。le ...继续阅读 (5)

GraphQL是 FaceBook 开源的一套数据查询语言，也是Relay钦定的组件，可以在客户端以一种非常灵活的语法来获取数据，但目前支持 GraphQL 的服务还比较少，最近GitHub 也宣布了其开放 API 支持了 GraphQL。因为 GraphQL 的支持需要服务器端的更改，因此我选择了在 LeanCloud 的数据服务的基础上用 Node.js 编写一个中间层，运行在云引擎上，将 GraphQL 的查询翻译成对 LeanCloud SDK 的调用，为客户端提供 GraphQL 支持。我也参考了其他语言和框架的 GraphQL 支持，它们都需要开发者进行很多的开发或配置工作。这是因为无论在 MySQL 还是 MongoDB 中都并没有记录数据之间的关联关系（Id 和 ObjectId 都不会记录指向的表或集合，MySQL 的外键倒是会记录，但可惜用户不多）；而且即使你定义了数据之间的关联，你还是需要去定义权限 —— 哪些用户可以访问哪些数据。而 LeanCloud 的 Relation 和 Pointer 都记录了所指向的 Class，同时 LeanCloud 本身也有一套基于 sessionToken 和 ACL 的权限控制机制，因此我们完全可以做到从 LeanCloud 的数据服务获取数据之间的管理，然后遵循现有的 ACL 来自动实现对 GraphQL 的支持。le ...继续阅读 (13)

在 LeanCloud 的控制台和文档中大家会接触到「并发连接数（Concurrent Connections）」这个衡量服务器负荷或处理能力的概念，但很多人并不了解什么是并发 —— 甚至在我们团队内部，很多没有服务器端开发经验的工程师对这个词的理解也不是很准确。我们还在继续优化文案来减少用户的困惑，但与此同时不如听我仔细介绍一下并发这个概念。和并发相关不得不提的一个概念就是 QPS（Query Per Second），QPS 其实是衡量吞吐量（Throughput）的一个常用指标，就是说服务器在一秒的时间内处理了多少个请求 —— 我们通常是指 HTTP 请求，显然数字越大代表服务器的负荷越高、处理能力越强。作为参考，一个有着简单业务逻辑（包括数据库访问）的程序在单核心运行时可以提供 50 - 100 左右的 QPS，即每秒可以处理 50 - 100 个请求，LeanCloud 目前也是按照请求数量进行收费的。但 QPS 只能粗略地衡量请求的数量，完全不关心服务器处理每个请求的开销。例如一个命中缓存的请求和一个需要进行多次数据库查询的请求的开销可能会有一个数量级的差距，所以 QPS 并不能十分精确地衡量服务器的负载或处理能力，因此我们引入了一个非常抽象的概念 —— 并发。大部分请求的响应时间在 15 - 30 毫秒左右，这里的响应时间是指服务器处理这个请求所花费的时间，从客户端测量 ...继续阅读 (9)

强类型 Vs. 弱类型强和弱是一个相对的概念，强是指倾向于将未定义的行为视作错误（Java、Python），弱是指倾向于进行隐式的转换、忽略类型相关的错误（JavaScript）。很多设计得不够严谨的语言，虽然大多数情况下（或者我们通常鼓励大家这么做）是强类型的，但也有弱类型的部分（PHP）还有的语言因为提供的抽象能力很弱，我们不得不去用弱类型的部分（C）鸭子类型（duck typing）是强弱类型的一个折中（常见于动态类型中，例如 Python），兼顾了灵活性和严谨性。我们认为弱类型是为了方便，而强类型是为了尽早发现错误。动态类型 Vs. 静态类型静态类型的变量的类型是在编译时确定的（C++、Java）；动态类型的类型是在运行时确定的（JavaScript、Python），例如你可以在一个 if 的两个分支里给一个变量赋值不同的类型。有的动态类型语言也会添加编译期的类型检查（TypeScript、Python），但因为语言本身的动态性，这些检查仅能覆盖一部分情况。在动态类型的语言中因为类型不那么重要，所以很多时候甚至没有提供指定类型的语法（隐含了运行时的自动推导）；而在静态类型语言里通常需要为变量指定类型，所以才有了编译期自动类型推导来提供便利，而动态类型语言则做不到这一点（因为不能在编译期确定类型，更无从推导）。我们认为静态类型有助于在编译时发现有关类型的错误，确定的类型也给了 ...继续阅读 (7)

从年初开始我就希望今后每年写这样一篇文章，如果说「年度小结」和「年度小结（技术方面）」代表了我这一年做了什么事情的话，那么这个系列的文章会聊一聊我这一年在想些什么。每当我生病或者身体不舒服的时候才会去注意一下自己的身体和健康，重新审视自己的生活状态，改变一些不健康的习惯。虽说不如早点这样做，不过现在也不晚吧，也许大家年轻的时候都是这样挥霍过来的吧。有一点可能是我之前没想过的，虽然公司不加班，但其实我做业余项目、写文章、准备演讲，和加班对身体的影响可能是差不多的。感觉自己赚那么多钱也没什么意义，也许应该放慢一点节奏，多出去走走，时不时请几天假来做自己喜欢的事情？今年最令我担忧的是眼睛，虽然视力变化不明显，但总有一种感觉不如以前看得清楚了，眼睛也比以前更容易疲劳了。去医院也检查了两次，医生都说只是用眼过度，没什么大问题，要尽量减少看屏幕的时间。确实今年年末我也是这样做的 —— 碎片时间和晚上睡觉前不再看手机了，睡眠时间也增加了一个小时左右，但一想到将来的工作和娱乐都会非常依赖视力，还是感觉有一种非常大的压力。收入高了之后也就适应了这样的生活，虽然我并没有在追求这些，但钱的确给了我很多自由：可以周末毫无目的地跑到另外一个城市闲逛，可以买一些即使自己用不上的东西而不必精打细算，可以用最好的猫粮来把皮蛋豆腐喂得油亮油亮的。但赚钱的过程本身又是在限制自由，有时候也觉得自己的钱够多了，没必要为了 ...继续阅读 (4)

这篇文章由我十月中旬在LeanCloud和十月末在Node Patry 杭州进行的技术分享整理而来。Atom 是 GitHub 在 2014 年发布的一款基于 Web 技术构建的文本编辑器，我从 2014 年末开始使用 Atom 完成我的全部工作，对 Atom 很是喜爱，也创建了 Atom 的中文社区、翻译了一部分 Atom 的文档和博客。今天我将着重介绍 Atom 背后的故事，包括底层的 Electron、如何对 Atom 进行定制、Atom 的插件化机制、Atom 在启动速度和渲染性能方面的优化等。GitHub 的联合创始人之一 Chris Wanstrath 自 2008 年便有一个想法，希望使用 Web 技术构建一个像 Emacs 一样赋予开发者充分定制的能力的编辑器。但当时他忙于他的主要工作 —— GitHub，所以 Atom 一度被搁置，直到 2011 年，GitHub 添加了一个使用 Ace 实现的在线编辑代码的功能，这重新点燃了 Chris Wanstrath 对 Atom 的热情，于是他开始在业余时间开发 Atom。在 2011 年末，Atom 成为了 GitHub 的正式项目，也有了一些全职的同事加入，最后在 2014 年初 Atom 正式发布了，并于 2015 年发布了 1.0 版本。所以 Atom 有什么亮点呢，我总结了这样几点：像 Sublime Text ...继续阅读 (3)

这篇文章由我九月末在Node Patry 杭州进行的一次技术分享整理而来。今天我想介绍的是 Node.js 开发中一个很小，但又很重要的话题 —— 错误处理。作为一名软件工程师，我想我们应该都会认可「错误是无法避免的」，因此我们必须积极地去对待这些错误，才能写出健壮的代码。首先，我想先介绍一下我们理想的错误处理是什么样的：出现错误时能将任务中断在一个合适的位置能记录错误的摘要、调用栈及其他上下文通过这些记录能够快速地发现和解决问题通常一个大的任务是由很多小的步骤构成的，很多时候当一个步骤中发生了错误，你并不能放任它在这里中断。我又要举那个经典的例子了：两个人，A 向 B 转账，当从 A 的账户扣完钱要加到 B 的账户上的时候发生了错误，这时显然你不能让整个任务中断在这里，否则就会出现数据的不一致 —— A 的账户被扣了钱但没有被加到其他任何账户上。因此我们需要通过错误处理精心地控制错误中断的位置，在必要的情况下回滚数据，确保数据的一致性。我们的程序也需要在出现错误的情况下能够显示（或记录）一个错误的摘要、调用栈，以及其他的上下文。调用栈通常语言本身会提供，但很多时候仅有调用栈是不足以定位问题的，所以我们还需要去记录那些可能与这个错误有关的「上下文」，比如当时某几个关键的变量的值。对于一个服务器端项目，如果我们决定不向用户展示错误的详情，可能还需要为用户提供一个唯一的错误编号，以便用 ...继续阅读 (16)

前因后果见知乎：阿里月饼事件；关于本文的讨论见V2EX: 关于刷月饼事件我来唱点反调可能发得有点晚了，是因为我不是有感于事件本身，而是看了大家的讨论一边倒地黑阿里，以至于有一些逻辑显得不是那么合理，所以我想仅就几个细节问题谈一谈我的想法。这是不是一个价值观问题我觉得这是一个价值观问题，就好像就是有人觉得「刷月饼」不妥甚至很严重，也有人认为没什么大不了。所谓价值观就是指你如何看待一件事情的对错、如何进行选择，很难说谁对谁错，但这两种人的价值观的确是不同的。公司因为价值观不同开除一个员工其实也没什么不对，对双方都有好处，如果被开除的人不觉得是自己的错，那么也很难说是对他的伤害。下单但没有购买算不算得到了「利益」既然下单是需要抢的，说明这个订单很可能对应着一份库存，你下单成功了意味着你得到了这样一份权利 —— 你可以在未来的一个小时里决定要不要买这个月饼，你甚至可以等有人出了一个合适的价格之后转卖这个月饼，可以说这种购买的权利就是「抢月饼」的核心利益，所以订单最后是否成交不影响刷月饼获利的这个事实。信息安全相关职位刷月饼是否可以减轻责任的确可能这个职位的工作之一就是去发现漏洞，但这也是在有工作安排的情况下，而且发现漏洞（活动规则设计不合理可以认为是广义的漏洞）后也不应该去利用它为自己谋利（是否算谋利已在前一小节讨论）。所谓 Geek 精神不应该被当作一个挡箭牌，在一个大的群体里还是要去遵 ...继续阅读 (10)

源自我在知乎对你们的 JavaScript 学习开发之路是怎样的？的回答，补充了一些对时下热点问题的看法。JavaScript 和方言三年前，我当时作为服务器端工程师，从未系统地了解过 JavaScript，只是在少数需要改前端页面时才写过几句 JavaScript，正是因为这种不了解，写起来觉得很烦，也不喜欢 JavaScript.但因为工作需要开始学习 Node.js，项目是用 CoffeeScript 写的，显然这又是一个我没见过的东西，但时间很紧，只看了一天 CoffeeScript 就开始写代码了，的确 CoffeeScript 的宽容度要比 JavaScript 好很多，语法很直观，也避开了 JavaScript 的一些坑。写了大半年 Node.js 之后我喜欢上了 Node.js 和 CoffeeScript，但我依然不太喜欢 JavaScript，但毕竟代码最后是要被编译到 JavaScript 的，所以我还是认真地读完了「JavaScript 语言精粹」和「JavaScript 权威指南」。权威指南虽然很厚，但其实通篇都是平铺直叙的介绍，读起来并不是很累，小节之间关联也比较少，很适合碎片时间阅读。什么，你说权威指南太重了？不过我看的是电子版。后来继续写了两年 Node.js，此时我 JavaScript 的编码经验依然为零 —— 我全部的代码都是 CoffeeSc ...继续阅读 (17)

这篇文章由我九月末在Node Patry 杭州进行的一次技术分享整理而来。今天我想介绍的是 Node.js 开发中一个很小，但又很重要的话题 —— 错误处理。作为一名软件工程师，我想我们应该都会认可「错误是无法避免的」，因此我们必须积极地去对待这些错误，才能写出健壮的代码。首先，我想先介绍一下我们理想的错误处理是什么样的：出现错误时能将任务中断在一个合适的位置能记录错误的摘要、调用栈及其他上下文通过这些记录能够快速地发现和解决问题通常一个大的任务是由很多小的步骤构成的，很多时候当一个步骤中发生了错误，你并不能放任它在这里中断。我又要举那个经典的例子了：两个人，A 向 B 转账，当从 A 的账户扣完钱要加到 B 的账户上的时候发生了错误，这时显然你不能让整个任务中断在这里，否则就会出现数据的不一致 —— A 的账户被扣了钱但没有被加到其他任何账户上。因此我们需要通过错误处理精心地控制错误中断的位置，在必要的情况下回滚数据，确保数据的一致性。我们的程序也需要在出现错误的情况下能够显示（或记录）一个错误的摘要、调用栈，以及其他的上下文。调用栈通常语言本身会提供，但很多时候仅有调用栈是不足以定位问题的，所以我们还需要去记录那些可能与这个错误有关的「上下文」，比如当时某几个关键的变量的值。对于一个服务器端项目，如果我们决定不向用户展示错误的详情，可能还需要为用户提供一个唯一的错误编号，以便用 ...继续阅读 (18)