代码里的命名规则：错误的和正确的对比 →
18
让我们先看看编程大师Robert C. Martin的杰作《Clean Code》里的一句话：“注释的目的是为了弥补代码自身在表达上的不足。”这句话可以简单的理解为如果你的代码需要注释，最有可能是你的代码写的很烂。同样，如果在没有注释的情况下你无法用代码完整的表达你对一个问题或一个算法的思路，那这就是一个失败的信号。
网络里的“逆世界” →
14
邻居偷用我的无线网，我可以设置访问密码，但我决定捉弄他们。我先把网络分成两部分——一部分受信，一部分不受信。受信的部分使用一个网段，不受信的是其它网段。我使用DHCP服务器限制MAC地址，过滤无关地址。
现代浏览器中内置的几个可以等效替代jQuery的功能 →
5
就我的个人习惯来说，不管开发什么项目，即使是一个很简单的demo，我做的第一件事就是引入jQuery，这样做主要是想使用它提供的DOM选择器功能。对于一些像IE6/IE7这样的老式浏览器，这种做法是显而易见的，但是，如今现代浏览器里已经内置了完整的DOM选择器功能，能让你使用原生的浏览器提供的方法来实现jQuery的功能。
函数加里化(Currying)和偏函数应用(Partial Application)的比较 →
18
我感觉很多人都对函数加里化(Currying)和偏函数应用(Partial Application)之间的区别搞不清楚，尤其是在相似的上下文环境中它们同时出现的时候。
为什么编码规范里要求每行代码不超过80个字符的限制是合理的 →
11
现在很多软件公司采用的编码规范基本是PEP8，但每行80个字符的限制除外。GitHub上的项目，大多数都遵循PEP8规范(这一点似乎达到了高度的统一)，但遵守80个字符限制的很少。在一些有明确规定的规范标准中，这个限制可能会增加(100或120)，甚至完全删除。
我们是如何让服务器从30台缩减到2台的：从Ruby迁移到Go语言 →
13
我们开发第一版的IronWorker已经是3年前的事了，是用Ruby写的，API基于Rails开发。我们没用多久就发展成了相当大的规模，很快我们就触及到了Ruby程序的承载上限。长话短说，我们切换到了Go语言，请接着读下去，下面是事情如何一步步发展的。
一次开发人员交换角色的尝试 →
5
在一次开发讨论会中，人们都在热火朝天的讨论出现的问题，而且你却待在角落里打盹儿——这说明你毫不关心他们关心的问题。出现这种现象并不能简单的认定你是个没能力的蠢货(然而，你很有可能就是)，而是因为你确实跟他们讨论的问题不相干。
Haskell语言为什么值得你去学习 →
15
当我向一些新手推荐学习Haskell语言时，得到的反应通常是：“为什么要学Haskell？”，“这是一种实用的语言吗？”或者“这是一种我可以真正用的语言吗？”我的回答是明确的YES。Haskell并不是我工作时的主要语言(我基本上是为嵌入式系统写C程序)，但我仍然发现Haskell难以置信的有用。虽然我的工作从来不用Haskell，我仍然认为花时间去学习它是值得的。那么，为什么要学习Haskell语言呢？
史上最最佳软件开发实践指导 →
7
每过一段时间，我都能读到一些好东西，它是如此的深刻见解，写的如此的清晰，如此的条理，我必须把它收录进我的个人“史上最佳”圣物集里。最近，我新收录了一篇，非常棒的一篇叫做《Best Practices for Scientific Computing》的文章，我希望每个来读本文的读者都找个时间读读它。我在这里列出它的要点，是要鼓励你去阅读完整的全文。写的真是非常好。
代码审查：ThoughtBot官方给出的代码审查指导原则 →
4
这篇文章的内容由github官方提供，指导你如何在github上进行代码审查和如果让别人审查自己的代码。针对所有人的审查： 接受这样的事实：很多编程上的主张都是一种个人观点。应该讨论它们的利与弊，提出你的倾向观点，迅速的达成一种解决方案
测试驱动开发上的五大错误 →
8
我曾经写过很多的糟糕的单元测试程序。很多。但我坚持着写，现在我已经喜欢上了些单元测试。我编写单元测试的速度越来越快，当开发完程序，我现在有更多的信心相信它们能按照设计的预期来运行。我不希望我的程序里有bug，很多次
中间人攻击(man-in-the-middle attack)：你和互联网中间的第三人 →
26
最近看到国外有一篇有趣的文章，是关于“中间人攻击(man-in-the-middle attack)”的，本想原文翻译，但里面有大量的政治敏感度内容，不宜在本网站公布，这里仅摘译出技术相关的部分内容，供大家探讨。大概是1月26号早上8点左右，在新浪微博和Twitter上相继有中国用户报告说在访问GitHub.com网站时出现无效SSL证书警告提示。后续不断的证据显示，这是由于受到“中间人攻击(man-in-the-middle attack)”造成的。
我的优化YouTube视频播放页面的故事 →
7
三年前，当我还在YouTube做一名web程序员时，有一位资深的工程师发了一通牢骚，说播放视频的页面体积太大。这个页面体积已经膨胀到了高达1.2MB，包含有数十次的请求。这个工程师公开的宣称说，“如果他们Quake能在100KB的体积下克隆出我们的页面，我们没有理由达不到这个体积！”因为我同意他的观点，并且我正在找新的任务，于是就决定接受这个挑战，让YouTube的视频播放页面的体积减到100KB以下。
