瞬息之间

近来经济形势不太好，环境所限“开源”起来就比较困难，只好“节流”。所以开始对生活中的消费子系统进行了一番审视，看看能否优化重构一番。再结合近期读到的几篇万维钢关于“生活黑客”的文章，特别是其中涉及的一个概念——精要生活，颇有一番恍然的感悟。精要生活“生活黑客”引申自黑客，而黑客的概念来自程序世界，它凝聚着一种核心的行动理念——破解与优化。而生活会被黑客看作一个系统，而系统就总是能够被重新拆...

最近读到一篇英语文章，名叫 《Don’t add your 2 cents》，初一看对这个标题有些困惑，心想这是什么意思啊？后来读完文章内容，不仅学会了一个新的英语习惯用语，还收获一个很有启发的故事。原意先来了解下这个习惯用语的背景。在维基百科的解释里 “My two cents” 或者说它的完整版 “Put my two cents in” 是一个美语的习惯表达，它用在表达一个人的试探性建议场景下

我想，谁都曾陷入过纠结中吧？我有过，而且很多次，有时就是会莫名的因为一些很小的决策选择而纠结不已。之所以纠结，可能在于人对不确定性具有本能的抵触，而决策就是在面对前方的不确定时，做出一个确定的动作。做决策时，我们通常以终为始，当 “终” 变得不确定，那么 “始” 就陷入纠结了，这样的情况下决策又该依据什么来做呢？依据合适的决策，可能没有绝对标准，但会有依据。做出理性选择需要评估选项，而评...

为什么有人也想写点东西，但持续不了多久就会放弃了？写一篇文章，算是完成一件事，而持续写作实际是在发展一个系统。仅仅完成一件事很简单，但发展成一个系统却很难。核心价值要发展一个系统，首先需要找到它的核心价值。写作这个系统有两个直接关联方——作者和读者。作者是第一驱动方，因为在你刚开始写作时，是不会有读者来驱动你写下去的。所以，要让这个系统启动起来就需要首先找到驱动作者的动力。大概八年前，...

如今，谁没点焦虑感呢？IT 这个行业里，信息和技术都在快速迭变，会让人感到焦虑；生活，年复一年，似乎总是离自己理想的生活状态还差点，也会让人感到焦虑。从个人的学习成长与生活状态这两方面来看，近来我开始尝试一种大概可以叫作 “深度” 的理念，用于对抗焦虑的感觉还不错。学习IT 行业里，关于学习有一种无奈的说法：学不动了。新思想，新技术和新实践总是在不断涌现，仅仅保持去跟踪了解就已经感觉快跟...

在「极客时间」更新了半年专栏，正好在年末更新完了，这篇算是专栏的尾声，算是一个总结式感悟，也在这里分享下。专栏的主题关乎成长，而成长的本质，就是两个字：知行 —— 始于知，终于行。知知，起于阅读；当你决定学习一样东西时，自然就会从阅读开始。从阅读中学习，要么是直接获得知识，要么就是从别人的学习经历或经验中找到值得自身借鉴的参考与启发。我硕士毕业于广州中山大学，一直让我铭记的是当年学校的校...

你有阅读的习惯吗？有自己的阅读框架吗？…国庆长假，没有到处跑，闲在家里读读书。看了一下我在豆瓣标记为 “想读” 的书籍已经突破了 300 本，而已标记读过的书才一百多本，感觉是永远读不完了。好早以前我这个 “想读” 列表是很短的，一般不超过 20 本，因为以前我看见这个列表太长了后，就会主动停止往里面再添加了，直到把它们读完了，这样倒是有助于缓解下这种读不完的压力与焦虑感。但后来渐渐想明...

一直想对过去职业生涯的成长路线做一个总结性思考，并沉淀为一部作品，今天终于完成了。1从毕业到今天，在程序这条道路上已经走了十多年了，前期在金融、电信行业写写程序，最近七年在互联网行业从事电商应用相关系统的技术工作，也一路从程序员成长为了一名架构师。今天这个时代，对于程序员来说是一个特别幸运的时代。每一个有追求的程序员都希望能获得快速的成长，但成长的道路没那么平坦和舒适，一路上充...

读到一篇关于程序员、领导力和领导者的好文章，翻译过来分享下。借用一句文中的话：“好吧，我只是个程序员，为什么需要领导？” ，读完你就知道了。做一个优秀的领导者可能不是大部分程序员会立即认同的东西。许多人的脑海里立即浮现出这样一种形象：宏大的讲台与高昂的演讲。然而，让我们看看塞斯·高汀（Seth Godin）对领导力的定义： 领导力的秘密很简单：做相信的事，画出一幅未来的图像...

离上次翻译文章有三个月了吧，虽然还是保持阅读英语文章的习惯，但也一直没读到特别能引发翻译分享冲动的好文了。三个月可能读了不下三百篇英文文章了，所以这篇肯定是很好的。读完原文，也许只需要不到二十分钟，翻译花了三个小时，且翻且珍惜吧。:)没有什么快速见效的办法，我知道这一点。作为一个社会科学迷，读了无数关于这个主题的书和博客，并且尝试了其中的很多建议 —— 然而大部分都是徒劳的。因此，我可能没有资格如此

有一种看法认为程序员是年轻人的职业。 而今天，三十岁的程序员很多都走到了十字路口程序员这个行业的知识更新速度很快，一般3到5年就需要更新换代。随着年龄增长，程序员学习和吸收新知识的速度会降低，也不再像刚毕业年轻时那样能保持更多的专注。这时老一代的程序员会感到有一种迷茫和危机感。的确，IT行业的知识更新很快，各种概念如雨后春笋般冒出，新的技术名词，新的工具，新的产品让人应接不暇。

从去年初开始接触微服务架构的一些理念，然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念。 最近关于微服务架构的讨论还是多起来，因为国外一些著名互联网公司（如：Amazon、Netflix 等）从实践中摸索出了一套新的大型系统架构方法论，并取得了成功，树立了很好的示范，然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构（Microservices）。在微服务架构（Micro

工作近十年了，[软件工程师] 一直是我职业 title 的中心词，只是前面的修饰语在不断变化，从初级、中级、高级到资深。 其实 [软件工程师] 是一个很泛化的定义，工作现实中软件工程师是被具体分工的，形成了具体定义的工程师。定义软件工程师是下面这些具体工程师的总体概括：开发工程师测试工程师UI工程师（又称设计师）产品工程师（虽然现在多称产品经理，但实际的工作内容更偏向工程师性质）运维工程

本文来自本人独立博客，更好的阅读体验点击这里「微服务架构思路对组织影响的进一步思考。」今年开始系统演化进入了第四个大版本，前两个版本我们采用的单一应用模式，核心开发团队也只有五、六人。前年团队扩张到了近 20 人左右，单一应用的维护协作成本已变得不可忽视，服务化拆分时进入第三版时我们做出的一个选择，但当时拆分粒度其实较粗，方便把团队拆分为几个小组来分

有时感觉技术选型就像个伪命题，胜出的技术占据绝对的主流，就像 java 领域中 ejb 被 ssh/ssi 框架取代。 大部分项目使用近似的模式搭建，选型在工程中变得似乎可有可无。 时间上胜出的开源技术帮助开发者在客观上做出了选择，我们先了解下影响选型的客观因素。客观因素客观因素包括如下：1. 广泛性我们都倾向于选择更广泛应用的开源技术以规避未知性风险。2. 质量质量我们会

作为一名开发者已十年，回顾过往大概经历了这么几个阶段，如下图所示：Develop Code作为刚走出学校的学生进入公司，在最初的 1～2 年内就处于该阶段。 不停的开发代码，为系统的大厦添砖加瓦，系统需要什么语言就学习什么，从 C 到 Java，从 Html到 javascript。 一会儿为 xx 银行的内控系统绘制界面，一会儿为校园一卡通的交易程序 fix bug，

背景最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章 Microservices， 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务，和我最近几年工作的实践比较相关感觉深受启发。本文吸收了部分原文观点，结合自身实践经验来探讨下服务架构模式的演化。面向服务架构（SOA）面向服务架构 SOA 思想概念的提出已不是什么新鲜事，大概在10年前就有不

曾经在一家小公司工作一段时间后被一个大集团收购，集团旗下有十多个小公司，于是开始推行一种统一开发平台，统一所有开发人员的开发模式提升规模效应。我曾使用那个平台进行业务系统开发，一套使用XML自定义的简化程序语言加上内嵌的特殊的业务函数，只能在特定的测试机上进行程序解释翻译调试。编写的过程，不需要IDE，只用文本编辑器足够，调试是个黑盒子，错误定位极其困难，业务开发人员被解脱为只需要懂业务流

前段时间应 优快云 邀请审核 Java 知识库内容，借此我也有机会好好梳理了下自己的 Java 知识体系， 成文一篇望能帮到即将走进或正在 Java 世界跋涉的程序员们。第一张，基础图大约在 2003 年我开始知道 Java 的（当时还在用 Delphi），但到 2004 年本科毕业才开始正式决定学习 Java。 那时觉得用 Delphi 写 C/S 架构的程序没什么意思，Java 当时

两年前接触到了微服务的概念，面对日益膨胀的系统感觉豁然开朗。之后的两年逐步把系统按微服务的架构理念进行了重构，并将业务迁移到了新架构之上。感觉现在差不多是时候写一篇关于微服务的总结文章了。定义在 Martin Fowler & James Lewis 的文章(参考[1])里给出了微服务架构的一个定义: 微服务架构即是采用一组小服务来构建应用的方法。 每个服务运行在独立的进

又读到一篇很好的文章，忍不住就翻译了过来。每个月我可能会读一百来篇来自英语世界的文章，其中可能有些好文会让我忍不住想翻译过来分享下，这也算是百里挑一吧。下面是原文，最后我会写写我的感想。这是一份我给 Berklee College of Music（伯克利音乐学院，当代最大的音乐学院，位于波士顿）一年级新生的演讲。于 2008 年 9 月 5 日。1. 专注、离线、切勿分心我最喜欢电影中关于训练的部

看过一部电影，引发点思考感想，写出来，这叫「影评」；听过一首歌，引发点思考感想，写出来，这叫「乐评」；看过一本书，引发点思考感想，写出来，这叫「书评」。所以这是一篇关于另一篇文章的文章（好绕），我前阵子读到一篇文章，引发了很多思考感想，写出来，这权当叫作「文评」吧。这篇文章来自一个外国人的博客，文章很短小精炼，却直击我思维的神经。为了更好的写这篇「文评」我决定先把它译在下面两条分割线之间。当作出关于

说明：第二次在 优快云 发这篇文章，以前图文链接失效，重新整理后发布。本文翻译自 Thinking Clearly About Performance 这是我三年前读到的一篇关于性能问题的好文，读完后还觉不过瘾，怕理解的不够遂又翻译了一遍，这也是当年我的第一次翻译。这几年来每次碰到性能问题，我都会想起这篇文章，它并不像很多其他关于性能问题的文章，告诉你利用什么工具怎么去解决性能问题，