当我们需要一张描述当前系统的基础设施或物理架构的图形时候，我们通常会选用自己最喜欢的工具来绘制。但是当你使用云或者其他虚拟化技术的时候，这种方式却不再适用。我们可以使用这些平台本身提供 API 去查询实际的基础架构环境，并使用一些简单的工具比如 GraphViz（graphviz.org），一些可以输出 SVG 格式的工具，生成实时的，自动化的基础架构图（automated infrastructure diagram）。
创业提案的逻辑
最近花了大量时间在自己新的内部创业项目，免不了给各种不同的人（内部或外部）进行商业提案（Business Proposal）的工作，同时也在帮助湾区一些社会企业包装面向投资人的Pitch，结合以往大量商业合作项目的经验，我重新思考了商业提案的逻辑，相信无论提案的规模、内部或者外部、创业或者商业项目，一个合理的逻辑都是必不可少，希望这个总结能给你帮助。
2015.5 技术雷达 | 工具篇
尽管依赖管理的概念并不新奇，在很多技术栈下它甚至已经被作为一种基础开发实践，但在 PHP 社区却并非如此。Composer（getcomposer.org）作为 PHP 技术栈下的依赖管理工具，深受其他技术栈下依赖管理工具的影响。例如， Node 的 npm 以及 Ruby 的 Bundler 等。现如今 Composer 已经被 PHP 项目广泛使用，并且其本身也日趋成熟。虽然在对内部库的管理上，Composor 还有待改进，但是对于大多数外部库的管理 Composor 已能够完全胜任。
2015.5 技术雷达 | 语言和框架篇
前端 Javascript 框架持续喷井所带来的一个好处是，时不时一个新的主意出现的时候，会引起我们的思考。React.js 是一个 UI/View 框架，在这个框架中，Javascript 函数在一个响应式的数据流中生成 HTML。我们已经见到几个小的项目成功的使用了 React.js，开发人员也被其干净的易组合的组件化方式所吸引。
You are not your job
作为知识工作者，不光考虑自己所做的事情本身，多去考虑自己做的事情对于自己的伙伴、团队所造成的影响，就走上了“卓有成效”之路。
为什么你的Scrum会失败？（二）
如何评价评审会议(或者叫Demo, Showcase)的效果? 我听过的答案有客户满意, 或收集到了反馈等. 这都不够, 且不说客户满不满意本就不应是评审会议追求的东西, 就是收集到了反馈, 都不够.
为什么你的Scrum会失败？（一）
Scrum失败的原因有很多. 很普遍的一个原因是, 忽视其众多前提而仅仅是把现在的基层开发组织按照Scrum要求的那三种角色改一下, 就算是上马了, 很快Scrum也就像它的音译那样, 变成死马了, 仅留一身马皮. 我们来看一下为什么仅仅把基层开发组织改组为Scrum团队是不工作的.
浅薄的欢腾与自欺的流量
当我们在商业社会初学了讲故事的皮毛，却不知公益更需要引人入胜的故事时，鼓吹营销获得成功的本末倒置的思维又一次在“冰桶挑战赛”上演。公益不需要过度的娱乐、浅薄的关注和喧哗的吵闹，它需要朴素的内心和严肃的思考。
在约束与机会中权衡
做自己最适合的事，就有更好的生产力：在经济学教科书里，我们称之为比较优势。前段时间和几个创业的朋友聚会，发现创业起步者，尤其是靠项目盈利者，有一个最大的误区就在于复制客户或上游链条企业的模式，不少行业级的大企业也正在步入同样的误区：比如设备商做运营商的事，运营商做电商的事，电商做社交的事——这本质上都变成了服务商涉足自己客户的领域，同时又要求客户买单。
DevOps中文名: 开发自运维
在高度不确定性的产品创新中, 对市场的响应速度越来越快, 开发自运维是一个趋势, 可以缩短交付时间和对反馈的修复时间. 这种趋势的前一波浪潮, 则是”开发自测试”/“开发自设计“, 而下一波运动则极有可能是”设计自开发”.
敏捷咨询日记——沟通问题
强调沟通和杜绝浪费是敏捷最核心的东西，这两项基本是贯穿我这次咨询活动的主线－任何细微的活动都需要用心审视两个问题：我做这件事情的前提是传递价值给团队另一个人，那么价值的传递过程中有没有沟通的阻碍？价值的传递过程有没有什么东西导致了传递损耗既是浪费？从一对一沟通谈起，逻辑是你不可能消除所有的沟通壁垒，譬如你的口齿不够清楚，那么至少发现那些你可以消除的壁垒，消除它，并告知和提醒你的听众那些你不能消除的。往往人们犯的错误是：
建设全功能团队——实践篇
在咨询的过程中，我见过太多的团队把目标放在交付上，冀希望于工具，外部力量能够快速的解决问题，往往对小步前进不够耐心，不关心团队的成员。在我们这个 90%以上成员没有.Net经验，50%是毕业生的团队中，那些微不足道的改进，一点点的提升，最终造就了这个9个月中没有一天加班，几乎没有缺陷，提前交付的项目，客户甚至愿意为他们的满意额外支付3万美金作为奖励。我把全篇总结为一句话：把项目目标放在人员能力提升，让项目成功成为能力提升的副产物。
基于微服务架构，改造企业核心系统之实践
随着公司国际化战略的推行以及本土业务的高速发展，后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同，从销售团队准备材料、与客户签单、递交给合同部门，再到合同生效大概需要3.5人天。随着业务量的快速增长，签订合同的成本急剧增加。
我怎么看敏捷
去年11月份的时候，我进到了ThoughWorks实习，开始了我的TW生涯，从现在除去今年年初由于毕业论文断断续续的10天左右的请假，我已经到ThoughtWorks1年了，现在我想来我聊聊我眼中的敏捷和我对敏捷的看法。
如何建设全功能团队
团队的开发人员撇开需求沉浸在想象中的“完美”程序中；测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能；设计师造出了没有尽头的楼梯，更糟的是，客户爱上了这个设计；团队领导四处救火，力有不逮。种种迹象表明，我们得打破分工带来的壁垒，建设全功能团队——大多数人能完成大多数种类工作的团队。