-
Show-off Too
我也会画～～
-
Program? Me?
这也不是新鲜事。这也不是中国特色。从前听的版本有几个：
- 业务分析师是不会写程序的。（所以Cucumber写出来要像自然语言。）
- 测试人员是不会写程序的。（所以Selenium要有IDE。）
- 界面设计人员是不会写程序的。（所以我们还得有个叫“前端程序员”的人用HTML+CSS把图片做成页面。）
- 项目经理是不会写程序的。（这个，大家都习以为常了…）
现在最新的版本是：系统管理员是不会写程序的，所以Puppet比Chef要好那么一点点（TWers请看这两天twswdev上的讨论），因为Puppet是声明性的DSL而Chef直接就是Ruby代码。Ruby代码会把笨笨的系统管理员吓倒云云。
扯淡。
所有这些人，只要还在从事软件开发相关的工作，他们都需要描述抽象的概念、把概念分别组织、用合适的词汇使概念描述可懂、关注概念中易变的部分和不变的部分、抽取概念中的共性、消除概念描述的重复。这个，就是编程。你可以逃避它，你可以拒绝学习它，但当你认真对待它，当你把它做好了，这就是编程。那时候你就会发现，Ruby是一种具有强大表现力因此更贴心的编程语言，HTML+CSS是比Photoshop更适合描述界面的语言。
重点在于：如果你一直在用一种并非设计用于描述大量复杂抽象信息的表达方式来描述大量复杂抽象信息，你为什么不去学会一种本来就设计用来干这个的工具呢──那就是编程语言；另一方面，如果你并没有在描述大量复杂抽象信息，很可能你的工作可以被一个脚本取代。
毕竟，从前的系统管理员都是Perl和Shell的高手。现在突然说他们不会编程，这个对我来说实在太突兀了。
-
与Jason神的近距离接触
跟Jason Furnell一起工作两天了。明天还有一天。小熊嫉妒得口水都要掉下来。
me: 哎我给你讲他教画画的方法嘛我觉得多好的Zichuan: 废话Jason神偶像
那，到底好在哪里呢？他一上来不是说要分析需求或者要设计什么东西，先拿出一大堆笔，每人四支：细的水笔，粗一点的水笔，灰色马克笔，黄色马克笔。每人一张白纸。不要着急，其实每个人都可以画画：
- 先拿细笔，在纸上画几个方框的轮廓，方框之间可以有重叠之类的。画好，大家展示。把纸传给左边的人。
- 再拿粗笔，在纸上框出一块你认为是主体的区域。画好，大家展示，哎，有点主题的感觉了。把纸传给左边的人。
- 再拿黄色马克笔，涂一块你想要特别强调的区域。画好，大家展示，隔着整张桌子都能看出对面的高亮。把纸传给左边的人。
- 最后拿灰色马克笔，把主体区域之外的区域涂成灰色背景。画好，大家展示，不仅有重点，而且有立体感。
画画（而且是团队协作画画）就是这么简单。然后每个人再拿一张纸，纸上已经预先打好了六个方框。现在往方框里画你脑子里想到的东西：苹果，汽车，系统架构，业务流程……随便什么。唯一的讲究：要照刚才讲的方式来使用笔，四种笔都要用到。
十分钟的绘画课，一桌子人就开始有模有样地设计用户交互了。下午有新同学加入，没上过早上的绘画课，那画的水平真的要差一截也。不得不对Jason神油然而生仰慕。
真正商业分析的部分，参考Business Model Generation。Jason在会议室把BMC卡片一贴出来，那华丽丽的气势，只能感叹是神一般的存在啊～～
me: Jason神还抽了我的烟～三根～Zichuan: 。。。。。。。。。me: 你没办法跟他share烟萨？你又不抽烟Zichuan: 我学我下次带条芙蓉王去
-
Chef学习手记之贰：基本套餐
现在我要配置一台体面的Rails服务器。也许我会用它来跑1.HourFor.me。
要配置一台Rails服务器，首先要有一台服务器。于是我到EC2搞了一台服务器。EC2之于DevOps就像SourceForge之于轻量级J2EE：它让你有机会去尝试那些原来只有在超级大企业里才会出现的东西。你可以在自己家里、在业余时间积累经验，而且不花多少钱。我装了一台Fedora8的机器。
在学习手记之壹里我说需要有一个Chef服务器。其实Chef有三种运行的方式：你自己装Chef服务器；压根不要Chef服务器（叫Chef Solo）；或者用OpsCode做你的Chef服务器。第三种方式蛮好，又不用自己多架台服务器，又可以在世界任何地方共享我的大餐。所以我就要这样做。
首先要在OpsCode注册，并创建一个组织（organization）。这部分蛮简单，照着网站的指示一步步做就行了。我创建了一个叫“thoughtworkers”的组织。创建组织的时候小心，有免费的plan可以用的。我现在还不需要收费plan那么强的功能。
紧跟着要搞定开发环境。我要在自己的机器上建一个Chef Repository，配置与Chef服务器连接的身份认证信息。基本上，按照这个文档来操作就可以了。
接下来要在EC2那台Fedora机器上安装Chef客户端。这也蛮简单，也有一个文档。其实关键就是要把RubyGems升级到1.3.7以上，然后就可以“gem installchef”啦。装好之后执行一下“chef-client”，应该会报错，需要从本地环境拷贝/etc/chef下面的client.rb和validation.pem去Fedora机器上。
现在可以写程序咯～在ChefRepository下面的roles目录里建一个base.json文件。先不管是Rails服务器还是Django服务器，我的体面服务器必须满足一些基本条件，比如有GCC啦，有Git啦，之类的。所以我在base.json里这样描述我的体面服务器：
{“name”: “base”,”default_attributes”: {“chef”: {“server_url”: “https://api.opscode.com/organizations/thoughtworkers","cache_path“: “/var/chef/cache”,”backup_path”: “/var/chef/backup”,”validation_client_name”: “thoughtworkers-validator”,”run_path”: “/var/chef”}},”json_class”: “Chef::Role”,”run_list”: [“recipe[build-essential::default]”,”recipe[openssl::default]”,”recipe[chef::client]”,”recipe[chef::delete_validation]”,”recipe[git::default]”],”description”: “Basic Server”,”chef_type”: “role”,”override_attributes”: {}}然后涅…那台Fedora机器咋知道它自己应该有“base”这个角色呢？当然答案是它不知道。我得告诉它。Knife是Chef的便利命令行工具。比如说，可以列出所有可管的节点（必须在Chef Repository目录下）：
$ knife node list# 下面是输出回显[“ip-10-130-9-17.ap-southeast-1.compute.internal”,”jeffxiong3650”]
有两台机器。下面这个是我自己的笔记本电脑，上面那个名字很长的就是在EC2的Fedora。我要让它知道，自己有“base”这个角色要扮演：
$ knife node run_list add \ip-10-130-9-17.ap-southeast-1.compute.internal “role[base]”# 下面是输出回显{“run_list”: [“role[base]”]}好乖～现在ssh登录到Fedora上去，执行一把“chef-client”…体面的服务器就这样装好啦～试试git，没问题的说～嗯嗯，当然这只是第一步。接下来要配置好体面的Rails服务器才行呢。
（未完待续）
-
Chef学习手记之壹：概念
Chef据说是DevOps运动中的一个重要工具。现在我开始学它了。
首先是几个名词解释：
- Chef: 大厨。我就是个新手大厨。我想要烹调一桌服务器大餐，也就是一台体面的、可以用来满足某种用途的服务器，比如“一台高性能的Rails服务器”。
- Cookbook: 菜谱。别人写好的一本书，书上写着一堆相关菜色的做法（比如“家常川菜”）。一些出色的服务器大厨已经写了很多菜谱，这些是我要学习和抄袭的。
- Recipe：菜谱里的一道菜色（比如“麻婆豆腐”）。服务器大餐里的某一部分该怎么做，都在菜色里写着呢。
所以，整个故事就是：作为一个服务器大厨（Chef），我想要从现成的很多菜谱（Cookbook）里挑选几道合适的菜色（Recipe），组合成一道大餐（服务器）来款待我的客人。
（等我的手艺熟练之后我还会写我自己的菜色和菜谱，这就是后面的故事了。）
Chef的主要目标是：把服务器配置变成源代码。这样做的好处有两个：
- 自动化。我可以很轻松地把一台服务器大餐的做法直接照搬到另一台服务器上，于是我就得到了另一台大餐。
- 配置管理。服务器的配置信息可以用SVN或者Git来管理，可以分享，可以多人协作，可以跟踪变化历史。
Chef使用服务器-客户端模式管理所有需要配置的机器。使用Chef涉及至少三台机器：一台开发机器，我会在上面编写大餐的做法；一台Chef服务器，它会管理所有要配置的机器，给它们下发配置信息；至少一台Chef客户端或“节点”（Node），它就是我要烹调的大餐。
理论上，只要支持Ruby的操作系统，都可以作为Chef节点来管理。不过认真说起来，AIX、HP-UX和Windows不能算真的支持（个人认为这些到了21世纪10年代还没有体面的包管理工具的操作系统就应该自己去死）。另外，每个Cookbook对操作系统的支持也可能不同。我大概看了一下，Ubuntu和Debian应该是被支持得比较好的（再次说明一个体面的包管理工具有多重要）。
概念就是这些了。接下来我要自己动手做一顿服务器大餐。
（未完待续）
-
We Are Ninjas
-
与ThoughtWorks中国首席观察员共勉
（这个头衔不是我信口胡诌的。虽说老板说这话也不是在正式场合，不过君无戏言嘛。再加上小风同学承诺要为ThoughtWorks中国著史来着，于是这个“首席观察员”也就算名正而言顺吧。）
小风同学是目前为止唯一一个拥有“ThoughtWorkers.org”子域名博客的非TW员工。
小风同学对我们那“很有名但我不能说反正你知道我是在说谁”的客户的了解程度胜过我们很多同事。
小风同学对老板同学头脑发热时的决定第一时间提出批评。并且多次指出我个人的方向性原则性问题。
小风同学开创性地把迭代和看板引入了历史学界。尽管迄今为止没看到多少成果。
更重要的，是一起看过的那些电影那些话剧那些书，一起走过的那些山那些水那些路，一起拍过的那些照片。在小风同学的帮助下，我认为我在一定程度上脱离了低级趣味，并且在一定程度上培养了“和谐”的性情。
值此相识两周年之际，谨向首席观察员小风同学致以崇高的敬意和诚挚的谢意。并愿与小风同学携手努力，共同开创更加美好的未来。
与小风同学共勉。
-
1.HourFor.Me
想学点正经东西、做点正经事情，不一定非得去报个班上个学立个项。小风同学算了帐：只要每天坚持一个小时，一个月就差不多当是学校里修一门课了。
每天一个小时，难就难在坚持。晓庆说，他督促自己坚持跑步的办法是天天在开心网上贴跑步状态，让朋友们一起监督。豆瓣上有个每月养成一个好习惯小组，用的办法是给自己打印一张日历格，每天自己填状态。总之，首先是要把坚持的情况明确可视化出来；如果能可视化到让别人也能看见，那就能起到更好的监督作用。
所以我就做了1.HourFor.Me──对啦，就是这个域名。每天给自己坚持一小时，每个月就能有点成就。
注册，登录，给自己订个计划──必须是30天，不能多也不能少；最多3件事，再多就是给自己找借口了。每天更新执行情况。然后，拿个widget来放到自己博客上，让朋友们一起监督。
还有，如果有什么改进建议，可以告诉我──我知道widget很难看，我很快就会改进这个的。
-
关于DevOps的快速阅读
中文WikiPedia上的DevOps这个词条是我今天刚翻译过来的。
需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。
可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。
The whole point of DevOps is to enable yourBUSINESSto react to market forces as quickly, efficiently, and reliably as possible.
特别值得一提的是，DevOps对于个人来说（再一次地）是个学习和持续改进的问题。
Automate, automate, automate.
Don’t stop innovating and learning. Technology moves fast. So do customer requirements.
Chef挺好用的。Puppet也是。怎么我就想不到这么好的点子呢？
-
What's Wrong With Multi-tasking?
