占个坑，最近思路很活跃，想整理和分享的东西很多。先整理成PPT在内部分享，然后也分享给博客上的朋友们。
内容会包括：
今天查看google统计发现，这篇“告诉你User-Agent的含义 是什么”的博文访问量还是很高的，大家都是搜“user- agent是什么 ”来到这个页面的。
既然大家这么关心user-agent，那我顺别推荐一下最近公司应用的开源机型库 — Wurfl。作为一个机型数据库，wurfl最大的优点是数据全。提供的API也还算清晰方便，Java/PHP API都有，数据结构简单、清晰。各位想写机型库代码的朋友，建议还是以它为基础来做吧，省不少力气。感谢吴晓华的推荐。
BTW：今天Google CEO施密特说“手机已经成为计算技术最热门的领域，最聪明的开发人员在编写应用程序时首先考虑的手机平台，其次才是Windows、Mac 等桌面操作系统”。
上次和晓华聊到公司里一些程序员抱怨日复一日重复的日常维护工作，比如日复一日的网站修改、日复一日的数据统计、日复一日的配置界面书写。而我觉得其中60%以上的情况程序员本身就有自己的责任，天助自助者，程序员应该改变工作思路和方式来解救自己。
程序员应该的工作思路是什么？
是让机器做重复的工作，让业务人员做必要的人力工作，自己创造让他人工作的系统，这是一个程序员应有的工作思路和方式。
举例：类似的统计经常做，那么不要等别人给你提统计系统的需求，自己做一个统计系统出来，让业务人员使用就是了，业务人员使用不方便的地方就改进这个系统。谁说他们要我做数据统计我就只能给他一个统计结果的数字，而不能给他一个统计系统了？
再举例：有人让我给做一个发布系统，那我装个WordPress给他用行不行？他只要一个方便的网站维护后台，谁说一定要按照他画的维护界面UI一五一十的完成了？
再举例：业务人员要求广告位以一个光怪陆离的方式轮转，那我直接给他一个更简单和更有效的广告轮转策略，从而节省一堆开发，好不好？
不主动思考，主动求变，主动构建系统，那只能指望着运气来救自己出苦海了。阿弥陀佛。
转自：http://www.dbanotes.net/web/web_single_point_of_failure.html
我还没有仔细看完，没时间了，所以转过来，留以后查看。
针对小型站点的技术普及信息，中大型网站的牛人不用看，耽误您的时间我负不起这责任。 用 Windows 做网站的也别看了，不适合。
说起单点故障(Single Point of Failure，SPOF)，倒是可以想起电影 《2012》中，一把焊枪把齿轮卡住，从而导致整个舱门无法关闭，进而整个引擎无法发动。这是个有点生动的例子–如此庞大的一个系统，居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability)，这是致命的事情。
大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够 
一般来说，只要系统能够比较清楚的分出层次来，要消除单点故障还是有章可循的事情。比如，一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效的消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，而随着架构的变化，定期审查系统潜在单点也是有必要的。
有人或许会问，假设一个起步中的站点，只有一台服务器，什么东西都在一个盒子里，到底要怎么做呢? 这里的建议是先抛开主板、CPU 、内存这些，首先必须考虑硬盘(存储层)的问题，如果机器只有一块硬盘，即使你备份计划再完善(不要说你的备份也是备份在这块硬盘上的)，还是建议你起码再弄一块。做镜像，让出错的概率降低，这是划算的投入，当然消除单点，成本几乎不可避免的要增加。如果硬盘多，或者有其他备份机制，可选的方法就更多，别刻舟求剑。
第二个要考虑网卡与网线的单点问题。先说网线，如果要问一个系统里面最容易物理损坏的是哪个组件，答案恐怕非网线莫属，对于网线这样多数时候因为距离需要定制的东西，总是购买成品还是有成本的，从我观察到的情况来看，各个 IDC 的网线使用手工制作的比例不小，这个质量几乎很难控制，一根线，两个水晶头，哪一个出问题都不能正常传输。怎么办? 想办法提升网线整体质量还是弄两根网线放在那里? 解决办法早都有了，网卡绑定 (NIC bonding)一个很简单很通用的办法(refer)，但是问题是并非很多人在用。多数 PC 服务器应该都是配置了多块网卡，如果是自己攒服务器，记得网卡多一块成本没多大，但是用处会有很多。如果耐着性子看到这里，先别急着去 Google，还有问题呢，两根网线如何接到上行交换机，什么样的交换机支持绑定，如何确定绑定是真正生效的? 答案是，尝试一下。
然后是什么? 是跑多个数据库，还是跑两个 Web 服务器，一个不行用另一个顶? 对于单台服务器，其它能消除单点的地方恐怕收效也不会特别大，现在少做无用功，或许要重点考虑如何备份，如何优化，以及出现问题的时候如何做到快速恢复。有一个或许会引起争议的建议是，除了SSH 登录之外，要不要留一个 Telnet 登录的服务呢? 毕竟 SSH 服务器端守护进程不是百分百靠谱的事儿，如果 IDC 距离较远，需要斟酌一下。好吧，网站有了一点发展，用户量也增加了，感觉需要增加服务器了。再增加一台服务器，抗风险能力一下子加强了许多，毕竟一台机器质量再好，也有出错的时候。现在，Web 服务器、DB 服务器可以考虑引入 HA 的方案，如果单台服务能力够，主备模式也不错。随着网站的发展，服务器数量继续增加…
随着服务器数量的增加，到了必须要自己购买网络设备的时候了。同样的设备，一买恐怕就要买双份，原因无它–一台总要出错，哪怕是电源被拔错–而这样的情况实际上并不少见。如果预算不够，那就再等等，但是要记住，定期审查，有可能的话，进行弥补总不会错。
到现在，所有的服务器都还在一个 IDC 呢，IDC 本身也是个单点啊，服务器被黑怎么办? 机房光线被施工工人挖断怎么办? 机房停电怎么办? 找第二个机房吧。现在选 IDC 首先要考虑什么? 中国特色的互联网问题总要考虑吧，”南北互通”怎么样…或许在选择第一个机房的时候已经遇到了类似的问题，或许现在正在受到这个问题的困扰。选好 IDC 之后，首先计划一下数据如何备份过来，然后，网站的配置信息如何同步或备份过来(这是保证第一个 IDC 出了致命问题之后的最基本的恢复要求)。多个 IDC 之后不得不提上议程的要算 DNS 这个事儿了。你的 DNS 解析商靠谱么? 如果域名提供商遭受攻击，对自己的网站影响能承受么?
更多的服务器，提供更多的应用，更多的用户，更多的收入… 接下来该怎么办呢? 现在，您所面对的已经不是一个小型 Web 站点了，可以不用看这篇文章了。
到现在，我还没说人的问题，如果这些信息只有一个人知道，万一这个人出了点事情怎么办? 作为老板，还要考虑人的单点问题。
–EOF–
场景很简单：一个前端负载均衡器（lb），两个应用服务器（s1，s2），一个备用应用服务器（s3）。
希望实现：正常情况下是s1和s2提供服务，但这两个服务器都down掉的时候由备用服务器s3提供服务。
作为负载均衡器的选择，我测试了nginx、haproxy和apache，nginx和haproxy都非常容易就实现了上面的需求，apache也有文档说可以，但没有测试成功。
nginx的配置文件如下（配置文件里是一个工作的app服务器，一个backup）：
upstream mycluster {
server 192.168.1.240:8888;
server 192.168.1.222:8888 backup;
}
haproxy的配置文件如下（配置文件里是一个工作的app服务器，一个backup）：
listen appli4-backup 0.0.0.0:10004
option httpchk
#option httpchk /index.html
option persist
balance roundrobin
server inst1 192.168.1.240:8888 check inter 2000 fall 3
server inst2 192.168.1.222:8888 check inter 2000 fall 3 backup
当然，其实最后我可能haproxy和nginx都不选，而选LVS，如果LVS提供这种支持。有空继续测试LVS。
《硝烟中的Scrum和XP》电子书下载：scrum-and-xp-chinese-version
昨天写一个新项目的开发过程计划，xinbo向我推荐了《硝烟中的Scrum和XP》（Scrum and XP from Trenches）这本书。开始阅读之后就没有停下来，一口气读完，读的非常开心，所以今天写写读书笔记。并推荐大家阅读，理由有三：
好了，下面是读书笔记，同样如果对于XP或者Scrum的基本名词没有概念的，简单Google一下就好了，了解一下名词和概念就好，别读太多理论读物。
“Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。。。。一年过去了，我们在公司里从上到下都实现了Scrum。我们试过多种团队尺寸（3-12人）、sprint长度（2-6个星期）；定义“完成”的不同方式；不同形式的产品backlog和sprint backlog（Excel、Jira、索引卡）；多种测试策略、演示方式、多个Scrum团队的信息同步方式……。我们还试验了XP实践——各种各样的每日构建，结对编程，测试驱动开发，等等；还试过把XP和Scrum进行结合。”
– 我深信“持续改进”“自我完善”这是任何一个开发过程中最重要的理念。幸运的是Scrum把过程持续改进作为了其执行的一个内在环节。
“产品backlog是Scrum的核心，也是一切的起源。我们叫它故事（story），有时候也叫做backlog条目。我们的故事包括这样一些字段：ID、Name、Importance、Initial Estimate、How to demo、Note。我们曾试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去。”
– 很简单是吧？简单就对了。把那么多功夫花在这些事情干什么，有空编码去好不好！
“Sprint计划会议非常关键，应该算是Scrum中最重要的活动（这当然是我的主观意见）。要是它执行的不好，整个sprint甚至都会被毁掉。”
– 在Scrum开发过程中“项目会”是那么的少，所以我也相信“Sprint计划会”是Scrum中最重要的活动。
“Sprint计划会议会产生一些实实在在的成果：
– 我认为“确定好Sprint演示日期”这个最刺激，呵呵。
“假如sprint计划会议接近尾声，但仍然没有得出sprint目标或者sprint backlog，这时该怎么办？我们要打断它么？还是再延期一个小时？或者到时间就结束会议，然后明天继续？这种事情会一再发生，尤其是在新团队身上。你会怎么做？我不知道。但我们的做法是什么？嗯……我通常会直接打断会议，中止它。”
“几乎每次sprint计划会议都要确定sprint目标。Sprint目标需要回答这个根本的问题，“我们为什么要进行这个sprint？为什么我们不直接放假算了？””
“在大多数sprint 计划会议上，大家都会讨论产品 backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分，等等都会在会议上完成。
我们是怎样实际操作的呢？要想收到好的效果，不妨创建一些索引卡，把它们放到墙上（或一张大桌子上）。”
– 一个Backlog一张纸质卡片，听起来不错，很直观，又让大家获得几个小时离开电脑的时间。
“在sprint演示会议上，团队自豪地演示了一个新特性，但产品负责人却皱起眉头，“呃，看上去不错，但这不是我要的！”发生这种事情可真是糟透了！
怎样才能让产品负责人和团队对故事有同样的理解？或者保证所有的团队成员对每个故事都有同样的理解？嗯，这可没法做到。不过还是有些简单技术，可以识别出最明显的误解。最简单的办法就是确保每个故事的所有字段都被填满”
“注意——我们在实践TDD（测试驱动开发），所以几乎每个故事的第一个任务都是“编写一个失败的测试”，而最后一个任务是“重构”（提高代码的可读性，消除重复）。”
– 我们不做TDD，但把“重构”作为最后一个任务也是不错的哈。
“这有个很复杂的问题：技术故事。或者叫做非功能性条目，或者你想叫它什么都行。例如：安装持续构建服务器、重构DAO 层、升级 Jira”
– 这段太长了，但这个问题太重要，很多技术经理都非常关注，所以还是看原文去吧。在P54
“我们要让整个公司了解我们在做些什么，这件事情至关重要。否则其他人就会发出抱怨，甚或对我们的工作做出臆断。”
– 这段也太重要了！但是也太长，归纳一下就是：一个展示项目信息的网页、sprint开始和结束都群发邮件、将Sprint信息打印出来贴到开发团队墙上。
“我们发现管理sprint backlog最有效的形式——挂在墙上的任务板！
找一面尚未使用或者充满无用信息（如公司logo、陈旧图表或者丑陋的涂鸦）的大墙。清理墙壁（除非不得已才去请求别人许可）。在墙上贴上一张很大很大的纸（至少2×2平方米，大团队需要3×2平方米）。然后这样规划：。。。。。”
– 又是“纸质”的东西，嗯，我喜欢纸质的和写在白板上的。原因嘛，还是它可以让我远离电脑，呵呵。
“嘿，该怎样进行跟踪呢？在这种模型中，如果必须跟踪的话，那我能提供的最佳方式，就是每天给任务板拍一张数码照片。我有时也这样干，但一直没用到这些照片。如果你确实需要跟踪任务进度，任务板这种解决方案可能就不太适合你。
不过我建议你应该试着去评估一下，对sprint进行细节跟踪能带给你多大价值。Sprint完成以后，可以工作的代码已被交付，文档也被check in，那还有谁会真的关心sprint的第5天完成了多少故事呢？又有谁会真的关心“为Deposit编写失败测试”曾经的估算量是多少？”
– 我很同意。一个Sprint只有2、3周的时间，这期间的事情让项目组内部自己搞定吧，外部的人那么不放心干什么。
“在安排座位、布置桌椅这方面，有一件事情怎么强调也不为过。
让团队坐在一起！
说的更清楚一点，我说的是
让团队坐在一起！”
“我们的每日例会跟书中的几乎没啥两样。它们每天都会在同一个地方，同一个时间进行。一般我们都是开站立会议，以防止持续时间超过15分”
– 我也喜欢站着开会，可以活动一下身体。当然，也能远离电脑。
“一定要做Sprint演示。让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。”
“在有关回顾的种种一切中，最重要的就是确保回顾能够进行。由于某些原因，团队常常都不太愿意做回顾。如果不给他们点温柔的刺激，我们的大多数团队都会跳过回顾。说句实话，我认为回顾是Scrum中第二重要的事件（最重要的是sprint计划会议），因为这是你做改进的最佳时机！”
“Sprint之间的休整。我们会力求保证不在同一天举行sprint回顾和下一个sprint计划会议。”
“在绝大多数层面上组合使用XP与Scrum，我们都已经尝试过了。有些XP实践直接被Scrum解决掉了，可以被视作二者的重叠。如“整体团队”，“坐在一起”，“故事”和“计划游戏”。在这些情况下我们就直接使用了Scrum。
我们近来开始在一个团队中实施结对编程。效果相当好。虽然其他团队大多数还没有进行太多尝试，但在一个团队中使用了几个sprint之后，我已经有了很高的热情去指导其他团队进行试用。”
“测试驱动开发（TDD）阿门！对我来说，它比Scrum和XP还要重要。你可以拿走我的房子、我的电视还有我的狗，但不要试着让我停止使用TDD！”
–嗯，我还真没做过TDD
“学到的一课：如果你深陷手工回归测试的泥潭，打算让它自动化执行，最好还是放弃吧（除非做起来特别简单）。首先还是应该想办法简化手工回归测试。然后再考虑将真正的测试变成自动化执行。”
“我们在实施Scrum的时候，所做的第一件事情就是打乱特定于组件的团队（方式1），创建跨组件的团队（方式2）。它减少了诸如“我们没法完成这个条目，因为我们在等server那帮家伙完成他们的工作”之类的情况发生。不过，要是有很强烈的需求，我们也会临时创建针对特定组件展开工作的团队。”
– 嗯，我也喜欢让一个团队内部搞定尽可能多的事情。跨团队沟通就是麻烦
“每周的全体（嗯，所有参与开发的人）会议。时长15分钟。
什么？15分钟？全体参加？每一个产品所包括的全部团队中的所有人都会参加？这能行么？
是的，能行。只要你（或是其他主持会议的人）严格限定会议的时间不要过长。”
– 开大会，挺好的。信息要在团队中充分共享嘛。
最后总结一下在实施scrum的团队中的会议有哪些：
昨天和吴晓华聊这个话题聊了很久，有一些有意思的观点记录下来。
软件项目中判断一个文档是否需要书写的标准是看这个项目开发期之后这个文档是否还有持续的价值，如果尽在开发期内部的过程文档，那么这个文档就可以省了。
进一步解释一下“凡是有利于解放人力、开始写代码的决定就是好决定”：如果开发人员已经对需求和设计了然于胸，自我感觉可以进入Coding工作了，那么就应该进入Coding阶段了，这时候再去做的需求和设计文档多数就属于多余了。明明我都可以开始写代码了，那么拖着不动去写那些文档干什么呢？
把Coding的人和需求端的人扔在一起，让他们尽快开始产生有使用价值的东西，这才是王道。
对于CRUD（增删改查）就不要写需求和设计文档了。在越来越多的框架对于增删改查操作连代码都不用写了的时候，还写那些文档干什么呢？
发现自己里coding越来越远了 — 前一段同时买了两本书，一本讲python编程的，一本《梦断代码》（Dreaming in Code）。结果很明显的更喜欢读梦断代码，而读不下去python的书。《梦断代码》就是一个程序员写程序员的故事书。我想这种书籍对于任何一个有开发经验，想往软件开发管理发展的人都是有帮助的，看看别人在开发中遇到的故事对自己是经验积累，了解一下软件项目有多难，为什么那么难。
我刚读到第二章，里面提到的观点非常吸引我：
“在网景公司，写代码是重中之重，所以只要是有助于解放人力、有助于开始写代码的决定就是好决定。”
“赫兹菲尔德的总是坚持让开发者们停止设计、开始编码 — 至少不要等到地面完全凝固才开始。赫兹菲尔德告诉我：我的风格是赶快干起来，然后把它变成我们想要做的大东西。这不是平庸之作，是个大东西。不过总的开始干吧！要点在于激情开干。”