从毕业至今，在互联网行业从事软件研发工作，将近五年。这五年间，做过后端开发、前端开发、大数据处理等，使用过的编程语言包括：Python、PHP、Go、Java、JavaScript 等。
虽说编程语言各异，但我使用它们来写各种项目的代码却一直坚持两点：代码可读性和自解释性/自文档性（self-documentation）。这很大程度上应该是受到 Python 语言设计哲学的影响 - 追求简单易读易懂的代码。
很多人可能会认为这两点其实是一点 - 代码可读性，但我想做点区分：代码可读性突出对代码阅读者视觉上的影响，是否存在不必要的理解干扰，比如：必要的空行、变量定义与使用之间的距离、函数体/逻辑分支是否过长、逻辑表达是否直观等等。可读性高的代码通常都非常漂亮、赏心悦目。自解释性代码则更突出语义层面，比如：变量名称/函数名称/类名是否恰当、函数/方法/API 是否单一职责、工程目录结构/包/模块拆分是否符合“高内聚低耦合”原则等等 …
在我读大学那几年，设计模式可谓火极一时，各大公司校招面试也几乎都会考设计模式，反观现在，则似乎很少有人聊设计模式的话题。是因为设计模式过时了吗？还是只是一个错误的概念？从个人这几年的开发经验来看，答案是否定的，设计模式并未过时，更不是一个错误的概念。从曾经的“红极一时”到如今的“门可罗雀”，只是说明软件开发行业以更加客观理性的态度来看待设计模式。软件开发领域的技术概念也似乎总是遵循这样的流行度变迁，最终一次又一次地证明不存在“银弹”。
正确看待设计模式的前提是明白什么是设计模式。正如本书一开始就强调的：“设计模式的本质是在已有的方案之上发现更好的方案（而不是全新发明）”，这是一种务实的态度，设计模式并非是一种高大上或者神秘的东西，而是一些常见的软件工程设计问题的最佳实践方案。
那么应该如何学习设计模式？个人认为软件开发技术的学习都应该以实践为前提，只有理解实践过程中遇到的种种问题，才能明白那些技术的本质和目的是什么，每种新技术都是因某个/某些问题而出现的，软件开发高手一般都反对新手一开始就一股脑地学习设计模式。有些新手学了点设计模式的理论后，甚至在软件开发过程中生搬硬套，结果是适得其反。因此，软件开发人员应该在积累了一定的开发经验，再系统地学习设计模式，效果往往也能事半功倍。
现在有些积累一定开发经验的软件开发人员，在谈起设计模式时，一脸鄙夷。我想这也不是一种客观务实的态度。软件开发不是简单的累积代码，在实现业务功能的同时应该仔细考虑如何控制软件的复杂度。软件的复杂度分为两个层面：业务逻辑复杂度和代码实现复杂度。对同一个业务系统，不同的软件开发人员会有不同的实现 …
原文：Clarifications about Redis and Memcached
译者：youngsterxyf
译注：本文为Redis的作者所写
如果你了解我，就会知道我并不是那种认为竞品是一件坏事的人。实际上我喜欢用户有选择的空间，因此我很少做将Redis与其他技术做对比这类事情。
然而，为了选择正确的方案，用户必须获取正确的知识，这一点也是理所应当的。
本文的起因是读了Mike Perham写的一篇博文，你也许知道他是Sidekiq这一流行程序库的作者，Sidekiq又恰好使用Redis做后端。因此我毫不认为Mike是一个“反对”Redis的人。但在博文（你可以在 http://www.mikeperham.com/2015/09/24/storing-data-with-redis/ 找到这篇博文）中，他陈述到：要用缓存，“你可能应该选择Memcached（而不是Redis）”。这样看来，Mike确实简单地相信Redis不适合用做缓存，在文章中他是这样论述的：
译者：youngsterxyf
在并行处理能力方面，Python的声名并不太好。不考虑关于线程和GIL（多数情况下是合理的）的标准论据，我认为Python中关于并行的真正问题并不是一个技术问题，而是教学问题。围绕Python线程和多进程的常见教程，一般都写得不错，但也令人乏味 - 激烈非凡，对日常真正有用的东西却很少涉及。
在DuckDuckGo（DDG）中搜索“Python多线程教程”，简单调查一下排在前面的结果，就会发现它们给出的都是同样基于Class + Queue的示例。
介绍threading/multiprocessing、生产者/消费者的真实示例代码：
# coding: utf-8
# Example.py
'''
标准的多线程生产者/消费者模式
'''
import time
import threading
import Queue
class Consumer(threading.Thread):
def __init__(self …译者：youngsterxyf
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there …
原文：Fundamentals of concurrent programming
译者：youngsterxyf
本文是一篇并发编程方面的入门文章，以Go语言编写示例代码，内容涵盖：
在开始阅读本文之前，你应该知道如何编写简单的Go程序。如果你熟悉的是C/C++、Java或Python之类的语言，那么 Go语言之旅 能提供所有必要的背景知识。也许你还有兴趣读一读 为C++程序员准备的Go语言教程 或 为Java程序员准备的Go语言教程。
Go允许使用go语句开启一个新的运行期线程，即 goroutine，以一个不同的、新创建的goroutine来执行一个函数。同一个程序中的所有goroutine共享同一个地址空间。
Goroutine非常轻量，除了为之分配的栈空间，其所占用的内存空间微乎其微。并且其栈空间在开始时非常小，之后随着堆存储空间的按需分配或释放而变化。内部实现上，goroutine会在多个操作系统线程上多路复用。如果一个goroutine阻塞了一个操作系统线程 …
原文：Centralized Logging Architecture
译者：youngsterxyf
在中心化日志记录一文中，我介绍了几个工具，用于解决中心化日志记录的问题。但这些工具一般仅能解决这个问题的一部分， 这意味着需要综合使用几个工具来构建一个健壮的解决方案。
你需要解决问题的这几个主要方面：收集、传输、存储、以及分析。某些特殊的应用场景下，也许还希望具备告警的能力。
应用程序以不同的方式产生日志，一些是通过syslog，其他一些是直接写到文件。考虑一个运行在linux主机上的典型web应用，在/var/log目录会有十几个甚至更多的日志文件，
如果一些应用指定日志存放在HOME目录或者其他位置，则这些目录下也是如此。
如果你正在运营一个基于web的应用，开发人员或者运维同事需要快速地访问日志数据以便对线上问题进行排错，那么就需要一个能够近乎实时监控日志文件变化的方案。 如果使用基于日志拷贝的方式 --- 文件以固定的时间间隔拷贝到一台中心服务器上，那么仅能检查与复制操作频率相同的新增日志数据。当站点已经挂掉，而你正在等待相关日志数据的复制， 那么一分钟一次的 rsync cron 任务也许还不够快。
从另外一个角度来看，如果需要分析线下日志数据，计算各种度量指标，或者其他批量的工作 …
原文：phpmetrics of popular php projects
译者：youngsterxyf
之前我偶然发现一个名为phpmetrics的新工具，可用于计算及展示php的度量指标。我当时立马喜欢上了这个工具，并决定用它分析我认为重要的一些php项目。 我知道这个项目列表还远远不够完善，但应该仍然值得一看。我特别喜欢其中的“可维护性”报告，我发现视觉上那些红色的斑点就和丑陋的代码一样令人厌恶。
这个工具貌似还有点小bug，我会尽力尽快修复这个工具项目的这些小问题。
一些重要的说明
说明：阅读该报告的一点小提示：