白勺的博客

在Struts2框架中JSP乱码情况处理思路

Bill — Sun, 03 Apr 2011 09:49:57 +0800

现在使用struts2框架的项目越来越多，而其间遇到乱码问题有时也不可避免，以下就该问题做一个思路总结，既然是思路总结，相关的解决办法在网上会有很多，请直接google即可。以下我们就所使用的编码是UTF-8编码格式。

1、查看jsp页面、java代码文件是否使用的统一编码。

2、struts.xml文件中是否已经加入编码<constant name=”struts.i18n.encoding” value=”UTF-8″></constant>

3、在jsp页面中加入<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>定义

4、数据库jdbc连接加入编码定义conn = DriverManager.getConnection(“jdbc:mysql://localhost/guestbook?useUnicode=true&characterEncoding=UTF-8″, “root”, “root”); （注意里面参数可能和你的项目不同）

5、在service或者action中的提交方法中（这里我们假设情况是提交汉字显示乱码）使用System.out.println(“add: ” + message.getContent());显示你提交的内容是否乱码（注意里面参数可能和你的项目不同），如果这里在控制台显示的是乱码，那说明你提交的页面以及action等还是编码不对，请再次检查是否已经统一编码。

6、如果第五条显示的是正确信息，修改数据库中的乱码为汉字，访问显示页面查看是否正常，如果正常说明你的显示流程是正确的，如果不正常，请和上一条一样查看你的显示文件代码。

7、以上几条都已经试验过，还是乱码，那么请检查你的数据库。包括，库、表、字段都要为统一编码。可以的话，把数据库以sql形式导出，查看代码编码是否正确后，再导入。

8、查看数据库my.ini文件是default-character-set=utf8编码格式。如果你使用的是绿色版，默认是不会有my.ini文件产生的，所以也就更无从谈起编码设置问题，请使用自带的例子.ini文件改名为my.ini文件设置。这里推荐安装版的设置向导。

9、如果以上问题还是得不到解决可以考虑在web.xml中使用拦截器解决了，使用拦截器解决方式非常不推荐使用，因为struts2设计的时候已经为你想的很周到了，你的项目在必须需要拦截器来解决的同时，也就意味着你可以考虑你的设计思路已经在错误的轨道上了。

10、还是不行？估计你发现了个bug或者人品问题了，good luck……

<constant name="struts.i18n.encoding" value="GBK"></constant>

为什么不用担心日本的核电站

Bill — Tue, 15 Mar 2011 13:47:57 +0800

原作：Josef Oehmen
V2EX译者：Livid

我在这里写下这些文字，是为了让大家对在日本发生的事情——核反应堆的安全问题，感到放心。事态确实严重，但是已经在控制范围内。这篇东西很长！但是你读完之后，你会比世界上任何记者都明白核反应堆究竟是怎么回事。

核泄漏确实已经发生，但是在将来不会有任何显著的泄露。

“显著泄露”大概会是个什么程度？打个比方说，可能比你乘坐一趟长途飞行，或是喝下一杯产自本身具有高程度自然辐射地区的啤酒，所受到的辐射要多一些。

我读了自从地震发生以来的所有新闻报道。可以说几乎没有一篇是准确或是无误的（当然也可能是因为地震发生之后在日本的通讯问题）。关于“没有一篇是无误的” 我并不是指那些带有反核立场的采访，毕竟这在现在也挺常见的。我指的是其中大量的关于物理和自然规律的错误，及大量对于事实的错误解读——可能是因为写稿子的人本身并不了解核反应堆是如何建造和运营的。我读过一篇来自 CNN 的三页长度的报道，每一个段落都至少包含一个错误。

接下来我们会告诉大家一些关于核反应堆的基本原理，然后解释目前正在发生的是什么。

福岛核电站的反应堆属于“沸水反应堆”（Boiling Water Reactors），缩写 BWR。沸水反应堆和我们平时用的蒸汽压力锅类似。核燃料对水进行加热，水沸腾后汽化，然后蒸汽驱动汽轮机产生电流，然后蒸汽冷却后再次回到液态，然后再把这些水送回核燃料处进行加热。蒸汽压力锅内的温度通常大约是 250 摄氏度。

上文提到的核燃料就是氧化铀。氧化铀是一种熔点在 3000 摄氏度的陶瓷体。燃料被制作成小圆柱（想像一下就像乐高积木尺寸的小圆柱）。这些小圆柱被放入一个用锆锡合金（熔点 2200 摄氏度）制成的长桶，然后密封起来。这就是一个燃料棒（fuel rod）。然后这些燃料棒被放到一起组合为一个更大的单元，然后这些燃料单元被放入反应堆内。所有的这些，就是一个核反应堆核心（core）的内容。

锆锡合金外壳是第一层护罩，用来将具有放射性的核燃料与世隔绝。

然后核心被放入“压力容器”中，也就是我们之前提到的蒸汽压力锅的比喻。压力容器是第二层护罩。这是一个坚固结识的大锅，设计用于容纳一个温度可能达到数百摄氏度的核心。在核心降温措施恢复前，压力容器起到一定的保护作用。

一个核反应堆的所有的这些“硬件”——压力容器，各种管道，泵，冷却水，然后被封装到第三层护罩中。第三层护罩是一个完全密封的，用最坚固的钢和混凝土制成的非常厚的球体。第三层护罩的设计，建造和测试只是为了一个目的：当核心完全熔融时，将其包裹在其中。为了实现这个目的，在压力容器（第二层护罩）的下方，铸造了一个非常巨大厚实的混凝土大碗，这一切都在第三层护罩的内部。这样的设计就像是为了“抓住核心”。如果核心熔融，压力容器爆裂（并且也最终融化的话），这个大碗就可以装下融化了的燃料及其他一切。这个大碗设计成让融化的燃料能够向四周铺开，从而实现散热。

在第三层护罩的周围包裹的是反应堆厂房。反应堆厂房是一个将各种风吹雨打挡住的外壳。（这也是在爆炸中被毁坏的部分，我们稍后再说）

福岛第一核电站一号机确实是通用电气的Mark I型沸水堆。新闻里露出钢筋的部分是最外部的厂房，里面的安全壳应该没事。——@铁公鸡zq

核反应的一些基本原理

铀燃料通过核分裂产生热量。大的铀原子分裂成更小的原子，这样就产生热量及中子（构成原子的一种粒子）。当中子撞击另外一个铀原子时，就触发分裂，产生更多的中子并一直继续下去。这就是核裂变的链式反应。

而现在的情况时，当一堆燃料棒凑在一起时就会很快导致过热，然后在 45 分钟后就会导致燃料棒融化。但是值得指出的是，在核反应堆内的燃料棒是绝对不可能导致像原子弹那样的核爆炸的。制造一颗原子弹实际上是相当困难的（不信你们可以去问问伊朗）。当年切尔诺贝利的情况是，爆炸是由于大量的压力积攒，氢气爆炸然后摧毁了所有的护罩，然后将大量的融化的核心挥洒到了外界（就像一颗 “脏弹”）。这样的情况为什么在日本没有发生，及为什么不会发生，请继续看下面。

为了控制链式反应的发生，反应堆操作员会用到“控制棒”。控制棒可以吸收中子，从而瞬间停止链式反应。一个核反应堆是这样设计的：当一切正常运转时，所有的控制棒是不会用到的。冷却水会在核心产生热量的同时带走热量（并转化为蒸汽和电力），并且在常规的 250 摄氏度的运转温度下还有许多余地。

而挑战在于将控制棒插入并停止链式反应后，核心依然在产生热量。虽然铀元素的链式反应已经停止，但是在铀元素的核裂变过程中会产生一些具有放射性的副产品，比如铯和碘同位素，这些元素的放射性同位素会最终衰变为更小的原子，然后失去放射性。在这些元素的衰变过程中，也会产生热量。因为它们不会再从铀元素中产生（在控制棒插入之后铀元素就停止衰变了），所以它们的数量会越来越少，然后在衰变结束的过程中，大约几天时间内，核心就会最终冷却下来。

目前让人头痛的就是这些余热。

核反应堆内的第一类放射性物质就是燃料棒中的铀元素，及放射性副产物铯和碘同位素。这些物质都在燃料棒内部。

而除此之外，还存在第二类放射性物质，产生于燃料棒外部。而首先需要说明的是，这些外部的放射性物质的半衰期都非常短，这意味着它们会在很短的时间内衰变为没有放射性的物质。“很短”的意思就是几秒。所以即使这类放射性物质被释放到自然环境中，他们也是毫无危害的。为什么呢？因为大约就你在读完 “R-A- D-I-O-N-U-C-L-I-D-E”的这几秒内，这类物质就衰变到完全不具有放射性了。这类放射性物质就是氮-16（N-16），也就是氮气（构成大气的气体之一）的具有放射性的同位素。另外就是一些稀有气体比如氩。但是这些物质是如何产生的呢？当铀原子裂变时，会产生一个中子。大部分的这些中子都会撞击到其他的铀原子由此链式反应就一直持续发生。但是其中的一些会离开燃料棒并撞击到水分子，或是冷却水中的空气。然后，一个不具有放射性的元素就会 “捕获”这个中子，并变得有放射性。而就如前文所述，在数秒内它就会衰变到它本来的面目。

上面所描述第二类的放射性物质在我们接下来要讨论的核泄露中非常重要。

福岛到底发生了什么

接下来我会试着去总结目前的主要事实。冲击核电站的地震的威力是核电站设计时所能承受的威力的五倍（里氏震级之间的放大倍数是对数关系，所以 8.9 级地震的威力是 8.2 级，即核电站的设计抗震威力的 5 倍，而不是 0.7 的差异）。所以我们首先为日本的工程技术水平喝彩，至少一切目前是保下来了。

当 8.9 级地震冲击核电站时，所有的反应堆就自动关闭了。在地震开始后的数秒内，控制棒就插入到了核心内，链式反应即刻中止。而此时，冷却系统就开始带走余热。这些余热相当于反应堆正常运转时产生的 3% 的热量。

地震摧毁了核反应堆的外部电力供应。而这是核反应堆能够遇到的最严重的故障之一，因此，在设计核反应堆的备用系统时，“电站停电”是一种被高度关注的可能性。因为核反应堆的冷却泵需要电力以维持运转。而反应堆关闭后，核电站本身就不能产生任何电力。

在地震发生后的一小时内一切情况是平稳的。为紧急情况而准备的多组柴油发电机中的一组启动，为冷却泵提供了所需的电力。然后海啸来了，比核电站设计时所预料的规模要更巨大的海啸，摧毁了所有的柴油发电机组。

在设计核电站时，工程师们所遵循的一个哲学就是“纵深防御”。这意味着你首先需要为了你能够想象到最灾难的情况设计防卫措施，然后为了你觉得可能绝对不会发生的子系统故障设计方案，以确保即使这样的可能绝对不会发生的故障发生后，核电站依然可以安全。而一场巨大的摧毁所有柴油发电机组的海啸就是这样的一种极端情况。而所有的防卫的底线就是前面提到过的第三层护罩，将一切可能发生的最糟糕情况——控制棒插入或者未插入，核心融化或者未融化——容纳于其中。

当柴油发电机组被冲走后，反应堆操作员将反应堆切换到使用紧急电池。这些电池被设计为备用方案的备用方案，用于提供给冷却系统 8 个小时所需的电力，并且也确实完成了任务。

而在这 8 个小时内，需要为反应堆找到另外一种供电措施。当地的输电网络已经被地震摧毁。柴油发电机组也已经被海啸冲走。所以最后通过卡车运来了移动式柴油发电机。

整个事件从这一刻起开始变得糟糕。运来的柴油发电机无法连接到电站（因为接口不兼容）。所以当电池耗尽后，余热就无法再被带走。

在这个点上反应堆操作员开始按照“冷却失灵”的紧急预案进行处理。这是“纵深防御”中的更进一层。理论上供电系统不至于彻底失效，但是现实如此，所以操作员们只能退到“纵深防御”中更进一层。这一切，无论对我们看起来多么不可思议，但却是反应堆操作员的培训的一部分——从日常运营到控制一个要融化的核心。

于是在这个时候外界开始谈论可能发生的核心熔融。因为到了最后，如果冷却系统无法恢复，核心就一定会融化（在几个小时或是几天内），然后最后一层防线——第三层护罩及护罩内的大碗，就将经受考验。

但是此时最重要的任务是在核心持续升温时控制住，并且确保第一层护罩（燃料棒的锆锡合金外壳），及第二层护罩（压力容器）能够保持完整并尽可能多工作一段时间，从而让工程师们能够有足够的时间修好冷却系统。

既然让核心冷却是那么重要的事情，因此反应堆内实际上有多个冷却系统（反应堆给水清洁系统，衰变降温系统，反应堆核心隔离冷却系统，备用水冷系统，及紧急核心冷却系统）。而究竟哪一个失效了或是没有失效在此时无法得知。

所以想像一下，一个在炉子上的压力锅，持续地，慢慢地在进行加热。操作员在采取各种手段去消除其中的热量，但是锅内的压力在持续上升。于是当务之急是保住第一层护罩（熔点为 2200 摄氏度的锆锡合金），及第二层护罩——压力容器。而为了保住第二层护罩，其中的压力就需要时不时进行释放。因为在紧急时刻进行压力释放是一件重要的事，所以反应堆共有 11 个用于释放压力的阀门。操作员开始通过时不时地旋松阀门来释放压力容器内的压力。此时压力容器内的温度是 550 摄氏度。

这就是关于“辐射泄露”的报道开始的时刻。我在上文中解释了为什么释放压力的同时实际上会释放第二类放射性物质（主要是 N-16 和氩），及为什么这样做其实毫无危险。放射性氮元素和氩对于人类健康没有威胁。

而就在旋松阀门的过程中，发生了爆炸。爆炸发生在第三层护罩外部，反应堆厂房内。反应堆厂房不具有隔绝放射性物质的功能。虽然目前并不清楚到底发生了什么，但是这是一个很有可能的场景：操作员决定让压力容器内的蒸汽释放到厂房内，而不是直接到厂房外部（这样可以让放射性元素有更长的时间用于衰变）。而问题在于，由于核心内的高温，水分子会分解为氧和氢——一种易爆混合气体，于是也确实在第三层护罩外爆炸了。历史上也曾发生过一次类似的爆炸，不过是在压力容器内（因为压力容器没有设计好并且操作失误），进而导致了切尔诺贝利事件。而福岛核电站不会有这样的问题。氢氧混合气体是在设计核电站时需要考虑的一个巨大问题，因此反应堆在建造时就考虑到了不能让这样的爆炸发生护罩内部。如果在护罩外部爆炸了，虽然也不是设想中的状况但是可以接受，因为即使爆炸了也不会对护罩产生影响。

因此在阀门旋送时，压力得以控制。而现在的问题时，如果水在一直沸腾的话，那么水位就会持续下降。核心大概被几米深的水覆盖，使得其能够在空气中暴露前坚持几个小时或几天。而一旦没有水覆盖，那么暴露的燃料棒就会在 45 分钟后达到其 2200 摄氏度的熔点。而这样就会导致第一层护罩，燃料棒的锆锡合金外壳融化。

而这样的事情正在开始发生。冷却系统无法在燃料棒开始融化前恢复运转，不过燃料棒中的核燃料此时依然是完好的，但是包裹燃料的锆锡合金外壳已经开始融化。而目前正在发生的，就是一些铯和碘同位素开始随着释放出来的蒸汽，泄露到反应堆外。最严重的问题——铀燃料，目前依然是受控的，因为氧化铀的熔点在 3000 摄氏度。目前已经确认的是，检测到有一部分铯和碘同位素随着蒸汽泄露到了大气中。

这似乎是一个启动“B 计划”的信号。通过在大气中检测到的铯和碘同位素，操作员可以确认某一根燃料棒的外壳（第一层护罩）已经存在破损。“A 计划”在于恢复某个常规冷却系统。为什么这个计划失败目前并不清楚，而一种可能性是海啸冲走或是污染了所有用于冷却系统的纯净水。

用于冷却系统的给水是非常纯净的，去除了所有矿物质的水。使用纯净水的原因在于：纯净水很大程度上不会被激活，因此可以保持相对无辐射。而如果是脏水，那么更容易捕获中子，进而变得更加具有放射性。这不会影响到核心——因为核心不会被冷却水影响。但是会使得操作员更难处理这些具有轻度放射性的活化水。

但是“计划 A”失败了——系统无法冷却，并且也没有额外的纯净水。因此“计划 B”被启动。而这就是目前正在发生的：

为了避免核心融化，操作员开始使用海水来冷却核心。我不是十分清楚，他们是用海水浸泡住压力容器（第二层护罩），还是淹住反应堆外壳（第三层护罩）。不过这个不是我们现在要讨论的。

要点在于核燃料现在确实已经冷却下来了。因为链式反应早就已经停止，所以目前只有非常少量的余热在产生。已经使用了的大量冷却水可以带走这些余热。因为是注入了大量的水，所以目前核心已经无法再产生足够的热量去大幅度提升压力。并且，海水中加入了硼酸。硼酸是一种“液体控制棒”。无论在发生什么样的衰变，硼都可以捕获产生的中子并进一步加速核心的冷却。

福岛核电站曾经十分接近核心融化。但是目前最坏的情况已经被避免：如果没有将海水注入，那么操作员就只能继续旋松阀门以释放压力。第三层护罩必须完全密封，以避免其中发生的核心融化泄露出任何的放射性物质，然后会经过一段等待期，等待护罩内的裂变副产品完成衰变，所有的放射性粒子会附着在护罩内壁。冷却系统最终会被恢复，融化的核心也会冷却至一个可控的温度。护罩内部会被清理。然后需要做一项棘手肮脏的事情——将融化了核心移出，将凝固了的燃料棒及燃料一块一块地装入运输装置，然后运送到核废料处理厂进行处理。根据损坏状况，核电站的这块区域需要进行修理或是彻底拆除。

那么，目前留给我们的是什么呢？

我的总结：

• 核电站会回到安全状态并始终安全
• 日本处于第 4 级别 INES 核紧急状态：核电站内事故。这对于拥有电站的公司是件糟糕事情，对其他人来说没什么影响。
• 在释放压力时同时释放了一些放射性物质。包括非常小剂量的铯和碘同位素。如果在释放时你正好坐在出口上，那么你可能需要考虑戒烟使得你的期望寿命值回归从前。这些铯和碘同位素会被带入海水，然后就不会再检测得到。
• 第一层护罩出现了一些损坏，意味着一定数量的铯和碘同位素也被释放到了冷却水中，但是不会有铀或是其他什么脏东西（因为氧化铀不溶于水）。在第三层护罩内有用于净化水的装置，这些具有放射性的铯和碘同位素会在那里被去除并且存储为核废料。
• 用于冷却的海水会在一定程度上被活化。但是因为控制棒已经完全插入，所以链式反应是不会发生的。这就意味着“主要的”核反应没有发生，因此也就不会加剧海水的活化。链式反应过程的副产物（铯和碘同位素）在这个阶段也基本上消失殆尽。这进一步减轻了海水的活化。因此最坏情况就是：用于冷却的海水中会具有一定程度的放射性，但是这些海水也同样会经由内部净化装置进行处理。
• 最终会用正常的冷却水取代海水。
• 反应堆核心会需要进行拆除并运到处理厂，就像通常的燃料更换一样。
• 燃料棒和整个核电站需要进行彻底安全检查，以避免潜在的危险。这通常需要 4 到 5 年。
• 全日本的核电站的安全防护会进行升级，以确保他们可以抵抗住九级地震及随之而来的海啸（甚至更糟糕的情况）。
• 我认为更显著的问题是随后的全国供电。日本的 55 座反应堆中的 11 座已经全部关闭并等待进行检查，这直接减少全国 20% 的核电电力，而全国 30% 的电力靠核电供应。我目前还没有去考虑国内其他核电站可能发生的事故。短缺的电力会需要依靠天然气发电站供应，而这些电站通常只是在供电高峰时用于应急。我不是十分清楚日本国内的石油，天然气和煤矿的能源供应链，及港口，炼油厂，存储及运输网络在此次地震中遭受了怎样的损失。这些都会导致电费增加，及用电高峰和重建时的电力短缺。
• 而这一切只是更大的问题的一部分。灾后应急需要解决避难所，饮用水，食物，医疗，运输，通讯设施等一系列问题，当然也包括电力供应。在一个供应链倾斜的时代，所有的这些领域中我们都会遇到挑战。

如果你希望持续了解事实，那么就忽略那些肤浅的媒体并关注以下网站：

• http://www.world-nuclear-news.org/RS_Battle_to_stabilise_earthquake_reactors_1203111.html

• http://www.world-nuclear-news.org/RS_Venting_at_Fukushima_Daiichi_3_1303111.html

• http://bravenewclimate.com/2011/03/12/japan-nuclear-earthquake/

• http://ansnuclearcafe.org/2011/03/11/media-updates-on-nuclear-power-stations-in-japan/

另，您可以在这里具体查看示意图版和，Flash动画版的示意图。

开发与研发

Bill — Mon, 10 Jan 2011 22:38:00 +0800

作为一个计算机从业人员，看到一篇文章，有些地方写的的确入木三分。另外想说的是，就国内这个大环境来说，如果一直搞技术，前途渺茫的几率大一些。

按：这几天我一直在写这篇东西，本来是胸有成竹，没想到后来越写越发现自己在这个题目下有太多话想说，而以我现在的能力又不能很好地概括总结，以至于越写越长，文章结构也变得混乱，到后来修改的时候每次都要考虑好久才能下笔，所以决定拆成两部分来发，以便阅读。这篇写得我心力交瘁，质量不算好，凑合着看吧。

同样是写程序，不同的岗位工作内容不一样，对程序质量以及工程师的要求也不一样。程序开发大概可以划分成两类：开发和研发，相应也就有开发工程师和研发工程师。很多人觉得做开发和做研发没什么区别，“都是一样对着电脑写程序啊”，但其实这两者是完全不一样的，下面我想抛开公司对员工的期望、社会对工程师的需求等其它因素，单纯从国内互联网行业“工程师个人发展”的角度来说一下我个人对这两类工作的看法。

开发一般是指产品开发，开发工程师直接为产品贡献代码。每个公司都有自己的产品线，拿 Google 来说吧，它有 Gmail, Chrome 等产品，每个产品都有很多开发工程师在后面支持，这些产品的开发、维护以及升级都是由相应的开发工程师负责的。由于开发工程师的工作直接关系到产品的质量和在线情况，所以开发工程师的责任是很重的，他可能经常为了下个版本的发布而加班，为了产品的故障不得不在休假的时候打开电脑工作，甚至在过年的时候都会接到领导的电话。所以你看到那些总抱怨加班太多，总是说自己是“IT民工”的，大部分都是开发工程师。在工程师当中，大部分人都是做产品开发的，毕竟公司都是要靠产品盈利，招聘的大部分人也要直接为产品服务。

做开发是很辛苦，但也有好处，因为需要对产品线负责，所以会是公司的核心，裁员对你威胁不大，如果你负责的产品恰好又是盈利产品的话，那么加薪、奖金、集体出游等福利都不会少。如果你足够幸运地加入了一家快速发展的创业公司，说不定一下子就发家了。还有很重要的一点是，作为产品的开发人员可以看到自己做的东西被那么多人使用，那是一种莫大的鼓励和肯定。

苦闷的开发工程师

尽管我很尊重开发工程师，但是我不得不承认，在国内大部分的公司，做开发工程师是没有前途的。首先，从微博到开心，有多少国内的产品不是山寨的？这也罢了，最恶心的是有一些产品经理连产品设计图都懒得自己画，直接去截取别人产品的图片，假如我是一个人人网的开发工程师，每天看到产品经理把 Facebook 新上线功能的截图拿过来让我做，你让我如何对产品有荣誉感和认同感？而如果一个开发工程师对自己做的东西没有荣誉感和认同感，那么他坚守自己的岗位要么是因为公司给的钱多，要么是因为他还没有找到下家。我个人认为，做开发最大的一个好处就是可以亲手实现一个“自己的作品”，就算平时很累，但最后完成它的时候也还是会无比满足，这点被剥夺了之后，和饭店打工的服务员有什么两样？不一样是为了糊口吗？

我不知道别人怎样，但我自参加工作以来就一直纠结于此——甚至开发的大部分产品都不好意思写上自己的名字；直到前不久有机会去做一个公司内部使用的平台，才终于有个作品让自己觉得满意。相信很多开发工程师参加工作之前都对互联网上很多诸如Gmail, Facebook 等优秀的产品耳熟能详，自己也常梦想做出那样的产品，但万万没有想到的是，工作之后要学习的第一课就是“不要对自己做的东西有感情”——有了感情你就不愿意做广告弹窗，不愿意看到它下线，不愿意为了短期利益伤害用户。与此同时，你还要继续听产品经理和老大们满怀激情地说“我们一定要让用户喜欢我们的产品”。一个连开发工程师本人都觉得无聊的产品如何让用户真正喜欢呢？拿搜索巨人来说吧，Google 把社交网站看作是某种形式的娱乐而不是有用的工具，所以它会在社交领域失败，再牛的技术也无法遮盖情感上的空白。不过话说回来，这好像对于国内大部分的公司都不是问题，因为它们做一款产品只是想从用户那里拿到钱，如果以后用户流失了就下线，然后再开发一个新的。他们要的不是用户的长期感情，而是一夜情，开发工程师就是一夜情的工具。

其次，国内几乎所有公司的技术流程和技术积累都做得很烂，大部分都只是片面地追求开发速度。我们在大学里受到的教育是“文档和注释很重要”，工作之后才发现文档和注释是很稀有的东西，只有特别负责任的工程师才会挤时间去写。有一个很有意思的现象是，国内很多产品发布之后会特别自豪地说“XX 是我们开发团队在时间紧迫的情况下，封闭开发了X 天就完成的！只有最牛的工程师才能创造这样的奇迹！！多少个凌晨，XX写字楼上只有我们办公室的灯还亮着……”，然后你会觉得“好感动啊”，但冷静下来想一想，这种拼命赶工做出来的东西质量会过硬吗？抛开产品质量不谈，没有时间写文档、没有时间写注释、没有时间做 code review, 没有时间做阶段总结……没有了这些，作为一个开发工程师你通过这个项目可以提升多少呢？所以好多开发工程师一开始是“代码民工”，过了几年还是“代码民工”，而一个人年富力强的时间又有几年呢？怪不得那么多人说工程师和妓女一样，都是吃青春饭的。

发展方向

我个人认为，国内的开发工程师大概有三个发展方向：1.做管理。 2. 去做架构等与产品关系不那么紧密的研发。3. 提升其它方面的能力，做 “A+ Player”，然后自己创业。我对管理没有研究，也没有兴趣，这里就不说了。研发我会在下篇中细说，这里主要说一下第三条。
为什么要关注代码之外的事情

如果你只会埋头写代码，那么代码写得再好也可能不会是一个好的开发工程师。做开发不是做学术研究，你的任务不是去钻研技术，而是利用自己的技术把产品做出来。尽管技术能力是基础，但如果无法把能力很好地应用到开发当中，那么你在团队中就没什么价值。举个例子，如果你不能很好地理解产品需求，那么就会根据自己的理解去做技术方面的架构和编码，等到后来发现了再去修改就特别麻烦，这个时候技术能力强反而成了坏事，南辕北辙的故事我想大家都听说过。

很多开发工程师属于那种“很本分”的人，从来不会提出意见，不关心产品形态和细节，只是去做产品经理提出的需求。我觉得别人把工程师叫做“代码民工”也就算了，但是工程师对自己做的东西完全没有看法，那就是甘心沦落为民工了。这也有文化的原因，国内的公司都喜欢那些不爱抱怨的员工，因为他们听话而且符合中国传统的价值观，但我更喜欢那些爱抱怨并且抱怨得有道理的人，因为国内（不只是互联网上面）粗制滥造的东西实在太他妈的多了，不抱怨才不正常，有不满才会去思考如何做得更好。

曾经听到有人谈论如何管理技术人员的时候说：“管理技术人员很简单，找一个比他们都牛的人就行了。” 这个人很了解工程师的脾气。工程师去判断其他工程师的时候，往往只看他的技术能力，觉得谁的技术好谁就最牛，其它的都无所谓。没错，技术牛的工程师写的代码质量很高，但这只是一个方面而已，判断一个人在团队中是不是“很牛”要看他对团队对产品的整体贡献，而不是他的个人能力。他能很好地理解产品需求吗？能很好地理解设计师的意图吗？和团队其他成员沟通顺利吗？写出的代码方便测试吗？会对产品提出好的建议吗？……这些都是判断一个开发工程师的标准，整体素质越高在团队中的价值也就越大。

所以要想做一个好的开发工程师，就要在写好代码的同时努力提高其它方面的能力。我知道大部分的工程师都喜欢和机器而不是和人打交道，所以遇到和产品经理、设计师以及 QA 等部门协调沟通的时候就皱眉头。协调沟通确实是一件闹心的事情，但从另一方面来说，这是开发工程师的一个得天独厚的优势：你可以深入接触产品生产线上的所有环节。需求评审的时候，你可以了解产品设计；开发界面的时候，你可以了解到视觉和交互设计；测试的时候，你可以了解到产品测试的细节；上线的时候，你也可以多观察 Ops 同事的操作。如果你可以在协调沟通的时候学会换位思考，多从对方的角度看问题，多想一下“他为什么要这么做”，那么不知不觉就会对各个领域有一些了解，进而发现原来每个领域都大有学问，就不会因为周围那些学艺不精的人而轻视他们所在的领域。

学习设计

对于工程师来说，测试和上线都是技术性的工作，和开发有很多相通的地方，而产品设计、交互设计和视觉设计等设计领域则比较陌生。对于自己不了解的东西，我们的看法往往会趋于两个极端：要么是看得高深莫测，要么是看得一文不值。其实对于大部分的东西，只要不笨并且愿意下功夫学习，总是可以学会的。尽管达到大师的水平可能需要传说中的“天赋”，但做到中等水平并不是特别困难。关于设计领域我一直在断断续续地在学习，到现在可能连略窥门径也算不上，这里只是说一下我个人对设计的理解和心得，供大家参考。

产品设计

产品设计看上去比较简单，因为只要清楚自己想要做什么，那么自然可以慢慢勾勒出产品的形态和功能。要做好产品设计，就需要平时多下一些功夫，多研究一下互联网上那些已有的产品，另外还需要多看一些诸如社会学、历史等“闲书”，举个例子，假如你想开发一款针对台湾用户的产品，那么了解一下台湾的文化肯定是有必要的。总之，学习产品设计是慢功夫，没有什么速成的捷径，只有一点一滴地不断积累才能培养出敏锐的产品意识和深刻的洞察力。

工程师学习产品设计有一个优势，那就是设计出来的产品是自己亲手实现的，你可以在实现的过程中不断重新反思原来的设计，然后加以修改和完善。这就好像写文章一样，很多时候你写东西的时候并不清楚自己具体要写什么，但只要是下笔开始写，写着写着就会发现新的想法，写作的过程同时也是思考的过程。写作和写代码很像，它们不仅可以表达想法，还可以创造想法。

视觉设计

很多工程师听到视觉设计会立刻退避三舍，觉得自己“不会画画”、“不懂配色”是不可能学习视觉设计的。诚然，视觉设计是需要更多艺术方面的基本功，要完全掌握需要长期的训练，但我们还是可以从简单的学起，慢慢培养对设计的感觉。我个人在这方面所知非常有限，但是对视觉设计中的完美主义印象深刻。

编程的时候，如果你的某行代码多了一个空行可能不会有什么问题，但在视觉设计中差了 1 个像素或者 10% 的透明度就是不可容忍的，很多设计师要求的都是 “Pixel-Perfect”——像素级别的完美。如果你不苛刻地追求完美，几个这样的“小瑕疵”就可以把整个作品毁掉。在我没有接触过视觉设计的时候很难理解这一点，切页面的时候并不会特别仔细地去看设计图，而且为了降低技术难度会想当然地篡改设计师的意图，比如把一些微小的渐变用纯色代替，这是很无知的做法。所以当设计师要求你做一个 1px 的修改的时候，即使会花掉你几个小时的时间也要听他的——只有这样才可以把界面做到百分之一百的完美。当然，设计师自己做不到完美另当别论。

此外，作为一个页面设计师，从职位名称上来看他的最终作品应该是页面，而不只是视觉效果图。所以我觉得页面设计师应该精通 CSS，只有自己才可以精确实现自己的设计意图。对于那些没有受过设计训练的工程师来说，很难注意到页面上色彩、字体和渐变的细节，让他们精确实现一个设计师的意图几乎是不可能的。精通 CSS 对于页面设计师来说并不算一个过分的要求，很多国外的设计师甚至可以自己用 PHP 写出产品原型，相比之下，国内的页面设计师进化得实在太慢了。

交互设计

交互设计是有关行为的设计，它更关注如何让产品更好用。举个例子，网页中一般都有很多超链接，当你把鼠标移动到超链接上的时候，鼠标形状会变成手型，暗示它是可以点击的，而且访问过的超链接和普通超链接的颜色是不同的，这样就很好地引导了用户行为。

之前我一直把设计和“视觉设计”等同起来，但在深入了解了之后发现，对于互联网产品来说，交互设计要比视觉设计重要得多，而且交互设计相对于视觉设计也更加有迹可循，对“感觉”要求没那么高，工程师完全可以把重点放在交互设计上。如果交互设计做得好，视觉设计遵循一些标准，那么完全可以做出一款“不难看并且好用”的产品。没有人特别夸赞 Google 的产品“好看”，但它们都特别好用，Google 注重的是易用、快速，用户体验是很棒的。

互联网行业的大部分页面设计师（Web Designer）都是学习平面设计出身的，但我觉得网页和软件设计更像是“显示器里面的工业设计”。很多平面设计师设计出的页面很好看，好像海报一样，非常适合打印出来，但往往对交互方面重视不够。不太好看影响不会很大，但不好用就没有办法留住用户，而且有时候太注重外观的视觉效果反而会分散用户的注意力进而影响产品的使用，这种 “eye candy” 是糟糕的设计。现在专门培养交互设计师的机构不多，我很希望对互联网有兴趣的工业设计师们到这个行业中来。

关于设计我就说这么多，以后有机会再另外撰文专门探讨这些主题。值得一提的是，没有人可以真正把设计和开发全部精通，如果深入到细节，无论设计和开发都会占用你大量的时间和脑力。单从设计来说，需要掌握的就有颜色、字体排印（Typography）、排版(Layout)、交互设计等，其中每一种技能又涵盖无数细节，真的是要皓首穷经才可以在其中的某个领域成为大师。不过，即使你对这些知识只是有一个大致的了解，以后在看一款产品的时候也可以从功能、交互、排版、页面代码、整体性能以及URL语义化等各个方面进行全面而细致的分析，明白它哪里做得好，哪里做得不好，而不是在那里想当然地说“真酷” 或者“狗屎”。真正了解什么是好的什么是差的，自己做东西的时候才会心中有数。

一专多能的好处

很多人可能会说：“一个人要是可以把所有事情都搞定，那还要其他人干嘛？我更相信团队的力量。” 没错，一个人就算从设计到开发都精通，如果只有他一个人做东西，开发效率也不会高。但是若你真的花心思去了解那些“与代码无关的事情”，你就会在写代码的时候更多考虑到产品经理/设计师的想法，对产品经理/设计师疏忽的地方也可以及时提醒，让自己真正地融入整个团队。目标并不一定要实现，它是用来指明方向的。开发工程师提高自己的产品意识和设计能力绝对不会是白费心血，不然的话你就只是一个实现产品的工具。你只会回答别人提出的问题，而好的问题要比好的答案有价值得多。

当你各方面能力提高得差不多的时候，应该就可以出来创业了（注意，我说的是创业，不是去创业公司打工）。因为对各个领域都有一定的了解，平时也经常接触到各个领域的人，那么在创业的时候你就很清楚自己需要什么样的产品经理/设计师，知道具有什么样能力的产品经理/设计师才是最好的，这样就可以从一开始就保证团队的质量和气质。很多互联网的业界前辈都说过“要招聘最好的人”，但问题是你如何判断一个人是不是该领域最好的呢？如果一个人对程序和设计一窍不通，满脑子都是商业运作，你觉得他有可能找出最好的工程师和设计师吗？有一次和一个创业公司的CEO聊天，他和我讲他们“只招聘 Geek”，后来我才发现他其实根本不知道什么是 Geek，只是不知道从那里听到 Geek 这个词，他真正想要的应该是那种只知道写代码愿意没日没夜任劳任怨给他当牛做马的人。国内大部分的创业公司就是这样，老大们喊着技术密集型的口号，实际上做着劳动密集型的事情，金玉其外，败絮其中。你可以和他们不一样。

我自己并没有创业的经历，也没有创业的打算，所以对创业的理解可能很片面而且天真。但是我相信，找到最好的人永远都是关键，不然即便后来成功了，也不过是多了一家靠人数取胜的血汗工厂。假如你选择成为移动互联网的独立开发者，对一个产品各个环节的全局把握也是有必要的。如果一个团队的每个人都能独当一面并且可以很好地理解其他人的意图和专业技能，就算最后在商业上失败了，那也会是一个幸福的团队，比那些除了盈利之外找不到任何亮点的团队好太多。

对产品经理的偏见

在“开发”这个小节的最后，我想多说一点自己对产品经理这个角色的看法。在国内绝大多数公司，开发工程师的作用就是把产品经理的想法以代码的方式写出来，“代码民工”这个称呼倒是很恰当。我对互联网行业的产品经理们一直感到很奇怪：他们没有能力把自己的想法实现出来，但是却几乎总是认为自己比其他人更理解产品；当工程师对产品提出自己的意见的时候，他们往往会心中不屑但尽量保持礼貌挤出微笑说一句：“呵呵，工程师不是普通用户”。一个产品本来就是需要很多人齐心协力一起完成的，产品经理和工程师的地位也是平等的，但是由于产品经理在工作流的上游，所以情况往往演变成工程师在为产品经理工作。如果产品经理真的对产品负责也就罢了，可惜的是大公司的产品经理大部分是对KPI负责，小公司的产品经理大部分是对老板的个人好恶负责，结果就是工程师跟在产品经理屁股后面做一些莫名其妙的事情。我接触到的几乎所有开发工程师都对他们的产品经理头疼不已，据他们说，好的产品经理就像真正的爱情，是极为稀有和可遇不可求的。

按照现在大部分公司的分工方式，产品经理是产品的总负责人。根据我个人的理解，产品经理之于产品，应该相当于导演之于电影，建筑师之于建筑。一个导演如果对拍摄一窍不通，那么就很难控制镜头的表现力；一个建筑师如果对建筑材料和结构一无所知，就不可能把握建筑整体的感觉。那为什么那么多人会觉得产品经理可以不懂技术不懂视觉设计，只需要写好文档画个框图然后交给别人去做就可以做出好的产品呢？本来是一个需要对各个领域融会贯通最难做得好的角色，现在反而被很多人视为清闲的差事，不爱干活的人纷纷想要转去做产品经理，实在是可悲至极。

我一直坚信好的工程师是不需要产品经理的。如果一个产品非要有一个什么产品经理的话，Google 的很多产品都不会出现，DropBox 这种只招聘工程师的公司也早就完蛋了。很多伟大的产品都是几个工程师想到一个点子然后慢慢做出来的，比如 Paypal 和 Google. 但需要说明的是，我讨厌产品经理并不是说我推崇“技术导向”——无论怎样产品都应该是让用户使用的，而不是用来炫耀技术的，只不过工程师不需要产品经理也可以设计好一个产品并且实现它。产品设计不是产品经理的专利。

想知道懂得设计的工程师没有产品经理的时候可以做出什么东西吗？去看一下 Livid 做的 V2EX 就知道了。在国内，设计和代码都有品味的网站可不多，我觉得 Livid 同学真是开发工程师的典范。

相对于开发来说，我个人更喜欢研发一点。研发和开发的一个不同之处就是研发有更多的“研究”成分在里面，也就是说研发的时候会有更多“光明正大”的学习时间，这对于那些对技术本身有追求的工程师来说是很有吸引力的。有一些人做工程师是为了可以创造出好的产品，然后挣大钱或者改变世界；也有一些人做工程师是因为对技术本身有兴趣，想要好好研究。可以凭借技术名利双收变身成功人士固然很有吸引力，但不关心世事钻研一些自己喜欢的东西也自有它的乐趣在。

研发

如果说开发产品是“输出”，那么学习思考就是“输入”，只有输出没有输入整个人就会废掉，完全沦为一颗螺丝钉。在很多公司尤其是那种经常加班赶项目的公司，你每天都会处于很忙碌的状态，脑子里想的都是赶紧把指定的任务完成上线。因为时间紧，所以你在开发过程中遇到什么问题都是只求解决，没有心思和时间去搞明白为什么会出现那种问题，在这样的工作状态下完全没有办法积累工作经验，看上去好像工作了五年，其实是工作了一年，然后重复了四年。

做研发一般不会直接为产品贡献代码，更多做的是一些基础架构或者实验性的产品，所以它有几个很明显的好处。首先，很少开会。其次，没有产品经理。第三，一般都会把质量放在第一位，时间不会特别紧。这是三个非常巨大的优势，这意味着你绝大部分时间都可以安心学习、思考、设计、编程，幸福指数会飙升。如果你是做基础架构，那么代码质量就会有硬性要求，你不得不写得健壮、易用、松耦合并且易于调试，要花心思和时间细细打磨，对个人的能力提高、习惯养成和经验积累都非常有帮助；如果你是做实验性的产品，那么你就有大量的机会和时间去调研最新的技术，而且最棒的是你可以在产品当中使用它们——这对于开发线上产品的工程师来说是不太可能的，因为不成熟的新技术存在太多未知的风险。

此外，做研发对工程师的素质要求很高，需要很好的技术基础、学习能力和研究能力——我把它看作是一个优点。从个人角度来说，我宁愿一家公司招聘非常严格需要竭尽全力才可以进去，因为严格的招聘可以保证团队所有成员的质量，不用担心进去之后会“和臭棋篓子下棋”。既然选择去做研发，那么基本可以说明你是一个对技术有追求的人，也肯定希望周围是一群和你一样的人，而不是连基础知识都不够熟悉的家伙。只有这样一群“互相看得起”的人在一块研究、学习、思考、切磋才会其乐无穷，才能够产生更多创意，做出好玩的东西。

当然，做研发也有不好的地方。只有大公司才有研发部门，这些公司一般都已经上市或者员工已经很多，你不太可能有机会一夜暴富。当你埋头做了几年研发之后，某一天去参加同学会，发现大学时候那个数据结构不及格总是求你让他拷贝编程作业的张三衣着光鲜四处敬酒。他所在的公司刚刚上市，因为进去得早，现在他变成了百万富翁而且荣升高层。于是你忽然开始怀疑自己当初的选择，连学习和编程的乐趣都变得很不真实。所以，如果你渴望建功立业，那么就不要选择做研发，或者做几年研发之后就出来闯荡。成功需要的条件很多，而编程只是你的优势之一，只有这一个优势你需要太多的运气才可以得到你想要的。

不过，我们也可以换个角度看。“乱世放不下一张安静的书桌”，现在到处都无比浮躁，有个地方可以让你安安心心做一些自己喜欢的事情已经非常难得，多少人拼命挣钱就是为了可以和你一样做自己喜欢的事情。尽管那么多人在叫嚷“搞原子弹的不如卖茶叶蛋的”，但总有一些人愿意去追求人类最高财富——知识和艺术家般的技艺。

本来做研发成就感会少一点，作为一个 Twitter 的开发工程师看到那么多人在用 Twitter 肯定会特别开心，相比之下某个在 Google 做基础研究的工程师的成就感可能没那么强烈。不过在国内环境比较神奇，开发工程师非但成就感不多，反而会不少挨骂，还经常会有负罪感，相信做过邮件推广和广告弹窗的工程师都深有体会。这样一来，研发工程师的“清苦”反而变成了一个优点，可以远离很多“不得不做”的违背良心的事情。

相信很多工程师在入行之前是喜欢技术的，但是工作之后发现完全不是自己当初想象的那个样子，然后就变得失望麻木，不再对技术有热情。其实你可以把热情延续下去，只不过要去做研发，而不是做开发。大部分由于兴趣而不是生计学习编程的人，内心真正渴望的都是去做研发，只不过没有人告诉他们开发和研发的巨大差别。现在不少大公司都有自己的研发部门，有一些还成立了自己的研究院，想要一直做技术的同学不妨尝试一下。

如何选择

很多人在大学里之所以会选择计算机为自己的专业，并不是因为自己对计算机和编程有兴趣，而是因为计算机是“热门专业”，在毕业之后也浑浑噩噩地找了一份工作进入了这个行业，做着自己并不喜欢的事情；还有一些人则是毕业之后找不到工作，然后看到一些培训机构的广告就去报名学习编程，希望广告上描绘的 “月薪过万”不只是一场梦。于是就有了越来越多的“代码民工”，在形形色色的大小公司做着又脏又累的工作，只为了“混口饭吃”。

我并不想批评这些人，毕竟在这个大环境下有着太多无奈，逼得我们无从选择。对于这样一些只想找一份好工作的人，是被骗到这个行业中来的。仔细回忆一下，这些年来我们看到的业界新闻，了解到的互联网公司文化，大部分都是有关诸如 Google, Facebook 等国外公司的；我们平时学习和使用的技术，几乎都是国外发明的。这让我们深信互联网就是那样美好，那些激动人心的东西触手可及，但请你关上电脑出门好好看一下周围：这是在中国。互联网没有国界，但互联网公司有。Google 和 Facebook 这样的公司看上去离我们很近，我们每天也使用它们的产品，但国内的互联网公司可能要几百年之后才会有那样的气质和文化。所以如果你不幸误入了这个行业，还是及早打算改行或者转型做管理比较好，这样就不需要再学习自己并不喜欢的“枯燥”技术了。

对于那些“真的”对技术有兴趣的人，要么去做一个同时具备软件设计能力的开发人员，也就是富有创造力的 Hacker；要么去做一个自得其乐的研发工程师。虽然环境恶劣，但是任何东西都挡不住真正的热爱。在这个几乎人人都把金钱作为衡量标准的社会里，你真是得到了上天的眷顾，不仅能够以自己喜欢的事情谋生，而且收入还过得去。

Hacker 是适合创业的，因为他拥有创造一个产品的全部能力。电影《社交网络》让很多以写代码为生的人产生了幻觉，Facebook 创始人传奇般的经历好像在向全世界宣布：世界是程序员的。很多人只是激动地看到扎克伯格的技术能力，但是却忽视了他的软件设计能力和对产品细节的重视程度，好像只要埋头编程就可以做出 Facebook。除了优秀的技术能力之外，扎克伯格的思考能力和创造力同样出类拔萃，可以感受得到他眼里的世界是不一样的。我们的工程师又有多少人对生活中的事物有独特而深刻的理解呢？独立思考也应该是 Hacker 的必备技能。

很多工程师都觉得自己会编程，只是缺少一个“好的 idea”；很多非技术人员则觉得自己有一个“好的 idea”，但是缺少编程能力来实现。要做一个产品，好的 idea 和实现它的能力缺一不可。然而，我们可以看到最后成功的往往是那些非技术人员，因为他们可以清楚地看到编程是一件可以学习的事情；而工程师们则往往天真地认为好的 idea 靠的是“灵机一动”，不会有意识地培养自己的观察能力和想象力。很多好的 idea 都是来自于平日对生活的敏锐观察和思考，然后这些点在某个时候忽然连成了一条线，把它简单地归结为“天才”是懒惰的做法。

“成为一个 Hacker”和“做研发”，很难说二者哪一个更困难。Hacker 在技术上可以不是一流，但他运用技术创造产品的综合能力肯定是一流的；而研发更注重技术上的造诣和理解程度，关注的是深度而不是广度。如果想要做研发，那么就要好好把基础知识研究透彻，比如数据结构、算法和网络协议等，不然很容易就会遇到瓶颈。我遇到过的每一位研发工程师都是技术上的大牛，在很多技术问题上都有非常深刻的见解；他们会从本质上分析问题，而不只是纠结于语言细节。

如果你想要通过自己的作品改变世界，那么就好好提高一下编程之外的能力，做一个好的 Hacker；如果只想埋头技术，就应该选择去做研发。不过，无论是想要做一个 Hacker 还是一个研发工程师，都需要长年累月地不断学习和思考。听上去好像非常辛苦，不过每一个热爱技术的人应该都会把学习和思考当作一种乐趣，而不是一种苦役。如果你无法享受学习和思考的乐趣，那么还是不要在技术这条路上走下去了，你会活得特别累，并且毫无幸福可言。

在这个充斥着“代码民工”并且缺乏“技术文化”的国度，我们只是关心怎么样可以活得更舒服，似乎忘记了编程本身所具有的迷人色彩。Joel Spolsky 说过，许许多多的人选择编程，首要的原因就是，他们宁愿将自己的时间花在一个公平有序的地方，一个严格的能者上庸者下的地方，一个只要你是对的就能赢得任何争论的地方。此外，我觉得选择编程还可以获得最大限度的自由和独立。因为找工作的时候只需要凭借自己的编程能力，所以不需要见人说人话见鬼说鬼话，不需要去结交权贵达人，不需要去为了所谓人脉去混圈子，也不需要看到邮件列表里有领导的邮件就去“顶”。平日里写写代码，其它时间喝酒吃肉，只交性情相投的朋友，武侠小说里的畅快适意也不过如此。这种独立和自由是极为宝贵的，你可知道有多少人在醉酒之后哭喊“安能摧眉折腰事权贵，使我不得开心颜”？

所以说，编程这件事情关乎公平，关乎自由，关乎美。而作为一个拥有编程能力的人，你可以亲手创造美。只有艺术家才可以创造美。希望有越来越多的人可以真正领会到编程的魅力所在，喜欢上这种艺术。正如 Raymond 所说，软件设计和实现应该是一门充满快乐的艺术，一种高水平的游戏。你需要用心。你需要去游戏。你需要乐于探索。

黑客事业之未来, 全依赖我们今日之创造。

最后推荐一些文章和书，这些文章和书大部分都与技术细节无关，它们讨论的是基于编程的令人心醉的文化，也适合非技术人员阅读。

1. 如何成为一名黑客。所有学习编程的都应该多看几遍这篇文章，至少把 Hacker 和 Cracker 的区别弄清楚。

2. 大教堂和市集。这是一篇关于 Linux 的经典文章。这里需要声明一下，我对那些 Windows 程序员没有偏见，只是我觉得作为一个以编程为职业的人，如果不参观一下 Linux/Unix 的深邃世界，未免太过狭隘。

3. UNIX编程艺术。这本书虽然名字叫做“编程艺术”，但里面并不讲授如何编程，而是全面展示了迷人的 Unix 哲学和文化。看完之后你会发现，那些看上去不修边幅、整日对着电脑屏幕编写代码的邋遢程序员，对于美竟然会有那么高的追求。“美在计算机科学中的地位，要比在其他任何技术中的地位都重要，因为软件太复杂了。美是抵御复杂的终极武器。” 这本书的作者 Raymond 同样是《如何成为一名黑客》和《大教堂和市集》的作者。

4. 黑客与画家。这篇文章是 Paul Graham 写的，文中详细描述了黑客与画家的相似之处。这里所说的“黑客”和《如何成为一名黑客》中所说的“黑客”略有不同，但你可以看到他们很多共同点。本文也已经被收录到《Hackers and Painters》一书，该书的中文版《黑客和画家——Paul Graham文集》由阮一峰翻译，应该很快就会面世，我十分期待。

5.创造者的品味。作者同样是 Paul Graham，文章观点独到，见解深刻，每读一次都有新的收获。

6. 软件随想录:程序员部落酋长Joel谈软件。这本书是 Joel Spolsky 的精华文章结集，作者写文章写得非常有趣，擅长讲故事，前几天我翻译的那篇《程序员阿士顿的故事》就是他的手笔。本书由阮一峰翻译，翻译质量非常高，有兴趣的可以先去试读几篇。

7. About Face3交互设计精髓。本书是交互设计领域的经典著作，作者之一 Alan Cooper 原来也是知名程序员，被称为 “Visual Basic 之父”，所以这本书里面对程序员的批评还是很中肯的。另外，书中“设计体贴的软件”的核心思想非常棒，值得程序员好好阅读和思考。

原文地址

充电误区那点事儿

Bill — Fri, 10 Dec 2010 16:38:37 +0800

流言： 新买的手机必须充满8小时以上并重复几次完全充电放电，这个过程叫做激活，这样可以使手机的电池达到最大容量。手机充满电之后必须马上拔掉电源，因为过度充电会引起电池爆炸。笔记本电脑和手机的电池最好把电用光再充电，这样可以尽量减少充放电循环次数，延长电池寿命。

真相：

新电池需要重复几次完全充电放电来激活吗？

确实有一些充电电池需要类似的“激活”工作。这就是较早的镍镉充电电池和镍氢充电电池。这些电池会产生一种被称为“记忆效应”的现象，在不完全放电的状态下充电，容易使电池过度充电，时间长了会导致电极板上增生晶体，阻塞电解液与电极板的接触，造成电池的电压下降，让使用者产生电池很快就用完了的感觉。[1]因此对于这两种电池来说，定期（而不是每次）对电池完全放电后再充电可以减轻上述原因引起的电压下降现象。

不过，现在我们手机和笔记本电脑上所使用的电池，大都是锂离子电池 (Li-ion Battery)。锂离子电池虽然身材小却可以储存大能量，因此使用的越来越广泛。锂离子电池在开始使用时不需要通过深度充放电来进行激活，也没有所谓的 “记忆效应”的，所以可以随时充电。[2]建议定期对锂离子电池进行一次完全充放电的说法，仅仅是为了校准笔记本电脑上的电量检测装置，并不是因为对电池本身有什么好处。[3]

神马？有些手机说明书上也有这么写？你要知道，手机的电池一般都不是生产手机的厂商制造出来的，说明书上的这种写法可能是为了提醒使用者测试一下电池有没有问题。另外，由于镍镉和镍氢电池的确需要激活，这种说明书上的写法也可能是由于照搬模板造成的。

过度充电会引起电池爆炸？

锂离子电池的能量密度大，电压较高（单独锂离子电池单元产生的电压可达到4.2V，而普通的镍基充电电池为1.2V），和低电压类电池相比，锂离子电池充电时电极的氧化还原反应十分剧烈，因此锂离子电池的使用条件必须受到严格限制，过度充电、过度放电、短路、高温等都会引起电池损坏，甚至发生起火和爆炸。[4]但是，实际使用中的锂离子电池是把若干个电芯连同一套安全保护电路以及多种安全装置一起封装成一块电池板。[5]这些安全设计可以保证在过度充电、过度放电和短路时自动切断电池的电路；电池内部压力过高还会触发排气装置减压；电池温度过高则会触发热熔保护装置，阻滞锂离子的运动从而停止电池的电化学反应。[6]因此，只要你不是用的质量不靠谱的山寨电池，手机充满电没有及时拔掉电源不会引起电池爆炸。

减少充放电循环次数，可以延长电池寿命？

锂离子电池的寿命和充放电次数并没有什么关系，主要的影响因素是电压和温度。研究表明，锂离子离子在完全充电的状态下长时间存放，其容量会发生明显损失。同样的，温度越高，锂离子电池的容量损失就越快，而这种损失是不可逆的，也就是说，电池的容量会永久变小。在0度环境下，电量剩余40%的锂离子电池存放一年后，其容量会损失2%；而在40度环境下，完全充满电的锂离子电池存放一年后，其容量损失高达35%。[7] 所以，应该尽量减少电池满电状态的时间。充满电后不拔掉电源，会让电池一直保持满电状态，虽然不会爆炸，但是会加快电池容量的损失速度。其实，频繁充电会比深度充电有助于延长电池的寿命，千万不要以为充电次数多会损坏电池，这个说法对锂电池并不适用。所以，好习惯是有机会就插上充勒个电，充到差不多就拔掉 ——少量多餐，但别吃太饱。[8]

结论：谣言破解。 锂离子电池用不着激活。除非有质量问题，否则也不会因为长时间插着充电而发生爆炸。锂离子电池没有记忆效应，可以随时充电，减少充放电循环次数并不能延长电池寿命。

参考资料：

[1] Memory: myth or fact?

[2] リチウムイオン二次電池や鉛蓄電池ではメモリー効果は生じない

[3] Unlike nickel and lead-based batteries, a new lithium-ion pack does not need cycling through charging and discharging.

[4] リチウムイオン二次電池 – 欠点

[5] リチウムイオン二次電池 – 市販形態

[6] 锂电池保护电路原理分析

[7] Figure 1: Non-recoverable capacity loss on lithium-ion and nickel-based batteries after storage. High charge levels and elevated temperatures hasten the capacity loss.

[8] How to prolong lithium-based batteries

鉴于很多人对目前普遍流行的锂电池充电存在误解，故转此一篇，希望对您有用。

来源：果壳网

链接：http://www.guokr.com/article/3120/

百万级访问网站前期的技术准备

Bill — Fri, 10 Dec 2010 16:17:27 +0800

作为一个技术从业者十年，逛了十年发现有些知识东一榔头西一棒槌的得满世界看个遍才整理出个头绪，那咱就系统点的从头一步一步的说，一个从日几千访问的小小网站，到日访问一两百万的小网站，怎么才能让它平滑的度过这个阶段，别在技术上出现先天不足，写给一些技术人员，也写给不懂技术的创业者。

对互联网有了解的人都有自己的想法，有人就把想法付诸实现，做个网站然后开始运营。其实从纯网站技术上来说，因为开源模式的发展，现在建一个小网站已经很简单也很便宜。当访问量到达一定数量级的时候成本就开始飙升了，问题也开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最惨的就是数据丢失，辛辛苦苦好几年，一夜回到创业前。

减少成本就是增加利润。很多事情，我们在一开始就可以避免，先打好基础，往后可以省很多精力，少操很多心。

假设你是一个参与创业的技术人员，当前一穷二白，什么都要自己做，自己出钱，初期几十万的资金，做一个应用不是特别复杂的网站，那么就要注意以下几点：

一、开发语言

一般来说，技术人员（程序员）创业都是根据自己技术背景选择自己最熟悉的语言，不过考虑到不可能永远是您一个人写程序，这点还得仔细想想。无论用什么语言，最终代码质量是看管理，所以我们还是从纯语言层面来说实际一点。现在流行的java、php、.net、python、ruby都有自己的优劣，python和ruby，现在人员还是相对难招一些，性能优化也会费些力气，.net平台买不起windows server。java、php用的还是最多。对于初期，应用几乎都是靠前端支撑的网站来说，php的优势稍大一些，入门简单、设计模式简单、写起来快、性能足够等，不过不注重设计模式也是它的劣势，容易变得松散，隐藏bug稍多、难以维护。java的优势在于整套管理流程已经有很多成熟工具来辅助，强类型也能避免一些弱智BUG，大多数JAVA程序员比较注重设计模式，别管实不实际，代码格式看起来还是不错的。这也是个劣势，初学者可能太注重模式而很难解决实际需求。

前端不只是html、css这类。整个负责跟用户交互的部分都是前端，包括处理程序。这类程序还是建议用php，主要原因就是开发迅速、从业人员广泛。至于后端例如行为分析、银行接口、异步消息处理等，随便用什么程序，那个只能是根据不同业务需求来选择不同语言了。

二、代码版本管理

如果开发人员之间的网络速度差不多，就SVN；比较分散例如跨国，就hg。大多数人还是svn的.

假设选了svn，那么有几点考虑。一是采用什么树结构。初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，一条上线分支，再往后，可能要每个小组一个分支。建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，可以上线时合并到上线分支。如果喜欢把svn当做移动硬盘用，写一点就commit一次也无所谓，就是合并的时候头大一些，这些人可以自己建个分支甚至建立个本地代码仓库，随便往自己的分支提交，测试完毕后再提交到开发分支上。

部署，可以手工部署也可以自动部署。手工部署相对简单，一般是直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。应用越复杂，部署越复杂，没有什么统一标准，只要别再用ftp上传那种形式就好，一是上传时文件引用不一致错误率增加，二是很容易出现开发人员的版本跟线上版本不一致，导致本来想改个错字结果变成回滚的杯具。如果有多台服务器还是建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后再重新加入。

不管项目多小，养成使用版本管理的好习惯，最起码还可以当做你的备份。

三、服务器硬件

别羡慕大客户和有钱人，看看机房散户区，一台服务器孤独的支撑的网站数不清。如果资金稍微充足，建议至少三台的标准配置，分别用作web处理、数据库、备份。web服务器至少要8G内存，双sata raid1，如果经济稍微宽松，或静态文件或图片多，则15k sas raid1+0。数据库至少16G内存，15k sas raid 1+0。备份服务器最好跟数据库服务器同等配置。硬件可以自己买品牌的底板，也就是机箱配主板和硬盘盒，CPU内存硬盘都自己配，也可以上整套品牌，也可以兼容机。三台机器，市场行情6、7万也就配齐了。

web服务器可以既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是MySQL的话），备份服务器干的活就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，这样WEB和数据库任意一台出问题，把备份服务器换个ip就切换上去了。备份策略，可以drbd，可以rsync，或者其他的很多很多的开源备份方案可选择。rsync最简单，放cron里自己跑就行。备份和切换，建议多做测试，选最安全最适合业务的，并且尽可能异地备份。

四、机房

三种机房尽量不要选：联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。那网通机房呢？亲，网通联通N久以前合并改叫联通了。多多寻找，实地参观，多多测试，多方打探，北京、上海、广州等各个主节点城市，还是有很多优质机房的，找个网络质量好，管理严格的机房，特别是管理要严格，千万别网站无法访问了，打个电话过去才知道别人维护时把你网线碰掉了，这比DOS都头疼。自己扯了几根光纤就称为机房的，看您抗风险程度和心理素质了。机房可以说是非常重要，直接关系到网站访问速度，网站访问速度直接关系到用户体验，我可以翻墙看风景，但买个网游vpn才能打开你这个还不怎么知名的网站就有难度了。或许您网站的ajax很出色，可是document怎么也不ready，一些代码永远绝缘于用户。

五、架构

初期架构一般比较简单，web负载均衡+数据库主从+缓存+分布式存储+队列。大方向上也确实就这几样东西，细节上也无数文章都重复过了，按照将来会有N多WEB，N多主从关系，N多缓存，N多xxx设计就行，基本方案都是现成的，只是您比其他人厉害之处就在于设计上考虑到缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存总有一天会失效，数据库复制总有一天会断掉，队列总有一天会写不进去，电源总有一天会烧坏。根据墨菲定律，如果不考虑这些，网站早晚会成为茶几。

六、服务器软件

Linux、nginx、php、mysql，几乎是标配，我们除了看名字，还得选版本。Linux发行版众多，只要没特殊要求，就选个用的人最多的，社区最活跃的，配置最方便的，软件包最全最新的，例如debian、ubuntu。至于RHEL之类的嘛，你用只能在RHEL上才能运行的软件么？剩下的nginx、php、mysql、activemq、其他的等等，除非你改过这些软件或你的程序真的不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BUG减少、性能增加。总有些道听途说的人跟你说老的版本稳定。所谓稳定，是相对于特殊业务来说的，而就一个php写的网站，大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6，python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog，看看升级说明，结合自己情况评估一下，越早升级越好，别人家都用php6写程序了这边还php4的逛游呢。优秀的开源程序升级还是很负责任的，看好文档，别怕。

以上这六点准备完毕，现在我们有了运行环境，有了基本架构骨架，有了备份和切换方案，应该开始着手设计开发方面的事情了。开发方面的事情无数，下一篇会先说一些重点。

七、数据库

几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。对于mysql，什么样的表用myisam，什么样的表用 innodb，在开发之前要确定。复制策略、分片策略，也要确定。表引擎方面，一般，更新不多、不需要事务的表可以用myisam，需要行锁定、事务支持的，用innodb。 myisam的锁表不一定是性能低下的根源，innodb也不一定全是行锁，具体细节要多看相关的文档，熟悉了引擎特性才能用的更好。现代WEB应用越来越复杂了，我们设计表结构时常常设计很多冗余，虽然不符合传统范式，但为了速度考虑还是值得的，要求高的情况下甚至要杜绝联合查询。编程时得多注意数据一致性。

复制策略方面，多主多从结构也最好一开始就设计好，代码直接按照多主多从来编写，用一些小技巧来避免复制延时问题，并且还要解决多数据库数据是否一致，可以自己写或者找现成的运维工具。

分片策略。总会有那么几个表数据量超大，这时分片必不可免。分片有很多策略，从简单的分区到根据热度自动调整，依照具体业务选择一个适合自己的。避免自增ID作为主键，不利于分片。

用存储过程是比较难扩展的，这种情形多发生于传统C/S，特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式，是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。

NoSQL。这只是一个概念。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次的写操作，内存型的甚至5万以上。例如MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。很多业务是可以用这类数据库来替代mysql的。

八、缓存。

数据库很脆弱，一定要有缓存在前面挡着，其实我们优化速度，几乎就是优化缓存，能用缓存的地方，就不要再跑到后端数据库那折腾。缓存有持久化缓存、内存缓存，生成静态页面是最容易理解的持久化缓存了，还有很多比如varnish的分块缓存、前面提到的memcachedb等，内存缓存，memcached首当其冲。缓存更新可用被动更新和主动更新。被动更新的好处是设计简单，缓存空了就自动去数据库取数据再把缓存填上，但容易引发雪崩效应，一旦缓存大面积失效，数据库的压力直线上升很可能挂掉。主动缓存可避免这点但是可能引发程序取不到数据的问题。这两者之间如何配合，程序设计要多动脑筋。

九、队列。

用户一个操作很可能引发一系列资源和功能的调动，这些调动如果同时发生，压力无法控制，用户体验也不好，可以把这样一些操作放入队列，由另几个模块去异步执行，例如发送邮件，发送手机短信。开源队列服务器很多，性能要求不高用数据库当做队列也可以，只要保证程序读写队列的接口不变，底层队列服务可随时更换就可以，类似Zend Framework里的Zend_Queue类，java.util.Queue接口等。

十、文件存储。

除了结构化数据，我们经常要存放其他的数据，像图片之类的。这类数据数量繁多、访问量大。典型的就是图片，从用户头像到用户上传的照片，还要生成不同的缩略图尺寸。存储的分布几乎跟数据库扩展一样艰难。不使用专业存储的情况下，基本都是靠自己的NAS。这就涉及到结构。拿图片存储举例，图片是非常容易产生热点的，有些图片上传后就不再有人看，有些可能每天被访问数十万次，而且大量小文件的异步备份也很耗费时间。

为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。很多网站都将cookie设置到了.domain.ltd，如果图片也在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。

如果用普通的文件系统存储图片，有一个简单的方法。计算文件的hash值，比如md5，以结果第一位作为第一级目录，这样第一级有16个目录。从0 到F，可以把这个字母作为域名，0.yourimg.com到f.yourimg.com（客户端dns压力会增大），还可以扩展到最多16个NAS集群上。第二级可用年月例如，201011，第三级用日，第四级可选，根据上传量，比如am/pm，甚至小时。最终的目录结构可能会是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync备份时可以用脚本只同步某年某日某时的文件，避免计算大量文件带来的开销。当然最好是能用专门的分布式文件系统或更专业点的存储解决方案。

下面，我们要谈谈代码了。

这一系列的最后一篇写给普通编程人员，如果不感兴趣可直接看本文最后几段。开始设计代码结构之前，先回顾一下之前准备过的事情：我们有负载均衡的 WEB服务器，有主从DB服务器并可能分片，有缓存，有可扩展的存储。在组织代码的各个方面，跟这些准备息息相关，我一二三的列出来分别说，并且每一条都以“前面讲到”这个经典句式开头，为了方便对照。别着急看经典句式，我思维跳跃了，插一段。实际开发中，我们总会在性能和代码优雅性上作折中。对于当今的计算机和语言解释器，多几层少几层对象调用、声明变量为Map还是HashMap这种问题是最后才需要考虑的问题，永远要考虑系统最慢的部分，从最慢的部分解决。例如看看你用的ORM是不是做了很多你用不到的事情，是不是有重复的数据调用。我们做的是web应用开发，不是底层框架API，代码易读易懂是保证质量很重要的一方面，你的程序是为了什么而设计，有不同的方法……算了，这个话题另起一篇文章来说，扯远了，咱继续……

WEB 服务器是要做负载均衡的，图片服务器是要分开的。对于这点，代码在处理客户端状态时，不要把状态放到单机上，举例，不要用文件session，嗯，常识。如果有可能，最好在一开始就做好用户单点认证的统一接口，包括跨域如何判断状态、静态页面如何判断状态，需要登录时的跳转和返回参数定义，底层给好接口，应用层直接就用（可参考GAE的 user服务）。登录方面的设计要考虑移动设备的特性，比如电脑可以用浮动层窗口，但NOKIA自带的浏览器或UCWEB就无法处理这种表现形式，程序一定既能处理AJAX请求又能直接通过URL来处理请求。图片服务器分开，资源文件最好也布局到图片服务器，也就是WEB服务器只服务动态程序。虽然开发测试时稍微复杂（因为需要绝对URI才能访问），但将来页面前端优化上会轻松许多，并且你的WEB服务器IO优化也轻松许多。程序引用资源文件时，要有一个统一的处理方法，在方法内部可以自动完成很多事情，例如将css/js根据组合，拼成一个文件，或者自动在生成的URI后面加上QUERYSTRING，如果将来前端用了缓存服务，那生成QUERYSTRING是最简单的刷新服务端缓存和客户端缓存的办法。

数据库会有复制，可能会多主多从，可能会分片。我们程序在处理数据的过程中，最好能抽象出来单独放做一层。拿现在流行的MVC模式来说，就是在M层下方再放一个数据层，这个数据层不是通常所说的JDBC/PDO/ActiveRecord等，而是你自己的存取数据层，仅对外暴露方法，隐藏数据存取细节。这个数据层内部不要怕写的难看，但一定要提供所有的数据存储功能，其他任何层次不要看到跟数据库打交道的字眼。之所以这样做，是因为在单关系数据库的情况下，可能会SELECT…JOIN…或直接INSERT…INTO…，可你可能会将一些表放到key-value数据库里存储，或者分片，这么做之后原来的语句和方式要全部改变，如果过于分散，则移植时会耗费很大精力，或得到一个很大的Model。在数据层面的设计上，尽量避免JOIN查询，我们可以多做冗余，多做缓存，每种数据尽量只需要一次查询，然后在你的程序里面进行组合。对于比较复杂的数据组合，在实时性要求不高的情况下，可采用异步处理，用户访问时只取处理后的结果。在对于主键的处理上，避免使用自增ID，可以用一定规则生成的唯一值当做主键，这种主键是最简单的分片分布策略。即使用自增ID，也最好用一个自增ID发生器，否则从数据库不小心被写了一下，那主键很容易冲突。

前面讲到，咱数据库前面还有某些缓存挡着。别把mysql的query cache当缓存，应用稍复杂的时候QUERY CACHE反而会成为累赘。缓存跟数据库和业务结合的很紧密，正因为跟业务关系紧密，所以这点没有放之四海而皆准的方法。但我们还是有一些规则可参照。规则一：越接近前端，缓存的颗粒度越大。例如在WEB最前端缓存整个页面，再往后一层缓存部分页面区域，再往后缓存区域内的单条记录。因为越靠近后端，我们的可操作性越灵活，并且变化最多的前端代码也比较方便编写。在实践中，因为产品需求变化速度非常快，迭代周期越来越短，有时很难将Controller和 Model分的那么清楚，Controller层面处理部分缓存必不可免，但要保证如果出现这种情况，Controller所操作的缓存一定不要影响其他数据需求方，也就是要保证这个缓存数据只有这一个Controller在用。规则二：没有缓存时程序不能出错。在不考虑缓存失效引发的雪崩效应时，你的程序要有缓存跟没缓存一个样，不能像新浪微博一样，缓存一失效，粉丝微博全空，整个应用都乱套了。在缓存必不可少的情况下，给用户出错信息都比给一个让人误解的信息强。规则三，缓存更新要保证原子性或称作线程安全，特别是采用被动缓存的方式时，很可能两个用户访问时导致同一个缓存被更新，通常情况这不是大问题，可缓存失效后重建时很可能是引发连锁反应的原因之一。规则四：缓存也是有成本的。不只是技术成本，还有人工时间成本。如果一个功能使用缓存和不使用，在可预见的访问量情况下区别微小，但使用缓存会使复杂度增加，那就不用，我们可以加个TODO标注，在下次迭代的时候加上缓存处理。

前面讲到，文件存储是独立的，那么所有的文件操作就都是远程调用。可以在文件服务器上提供一个很简单的RESTful接口，也可以提供xmlrpc 或json serveice，WEB服务器端所生成和处理的文件，全部通过接口通知文件服务器去处理，WEB服务器本身不要提供任何文件存储。你会发现很多大网站的上传图片跟保存文章是分两步完成的，就是基于这个原因。

以上几条“前面讲到”，其实无数人都讲过，我也只是结合前几篇文章用自己的话重复了一遍，真正分析起来精髓很简单——除了良好的功能逻辑分层，我们还要为数据库存储、缓存、队列、文件服务等程序外层资源调用单独设计接口，你可以把你的程序想象成是运行在 Amazon EC2 上并用他的所有web service服务，你的数据库就是它的SimpleDB，你的队列就是他的SQS，你的存储就是他的S3，唯一不同是amazon的接口是远程调用，你的是内部调用。

将支撑服务接口化，意味着将MySQL更换到PostgreSQL不需要更改业务处理程序，移植团队甚至不需要跟业务开发团队过多沟通；意味着业务开发团队是对接口编程而不是对数据库编程；意味着不会因为某个业务开发人员的失误而拖垮性能。

对程序扫盲不感兴趣的直接看这里——

产品设计完了，程序框架搭完了，可能有矛盾在这个节骨眼儿产生了。不断有产品设计抱怨说他的创意没实现到预期效果，有程序员抱怨说产品设计不切实际。这种抱怨多缘于产品人员不懂技术，技术人员不理解产品。从广义上来讲，产品包含市场策略、营销手段、功能设计，产品和技术在争论时往往把焦点放在功能上，而实际重点是，实现这个功能所消耗的成本跟能这个功能带来的利益能否换算，能否取其轻重。若可以，争议解决。若不能，则抛硬币看运气。因为一个功能的加强而引发指标井喷，或因项目拖延而导致贻误战机的例子比比皆是。激进的决策者注重利益，保守的决策者注重损失，聪明的决策者会考虑这个问题是否真的那么严重。

关系到未来的事情谁都说不准，要不怎么说创业一半靠运气呢。不过总有能说的准的事情，那就得靠数据说话。

没有100%也有99.9%的网站安装了访问统计代码，新闻联播也总说科学决策科学发展的。有了统计，能确定的事情就很多了。例如，可以根据来源-目标转化率来分析哪类渠道的人均获取成本低，根据来源-内容访问猜测用户跳出率原因，根据用户点击行为判断链接位置是否合理等。将数据以不同方式组合起来，找到内在联系，分析内因外因，制定对应策略，减少拍脑门决策。靠数据支撑运营是个非常专业的事情，虽然不懂深奥的数学模型不会复杂的公式计算，渐渐学会因为A所以B，因为A和B所以C还是相对简单的。

全系列完毕。老话，大半夜连抽烟带码字的挺伤身，转载请注明出处

饭否可以饭否……

Bill — Fri, 26 Nov 2010 21:42:13 +0800

饭否目前已经又开始对外提供服务了，据我观察很多老人又回到了其中。

饭否可以饭否，饭否希望是以前的饭否。

目前注册需要邀请，如果您需要，请猛击 http://fanfou.com/register/ZTNzwnryYlV1

跟你比起来，大部分人都像笨蛋

Bill — Mon, 01 Nov 2010 17:41:44 +0800

在互联网业界，大多数人都知道Firefox和Explorer之间的区别。我们还知道FTW是什么意思，知道ASP，PHP和RoR之间的区别。或至少知道它们之间存在区别。如果你遇到一个企业家，他从来没听说过Digg，Google Apps或Freemium模式，你也许会感到惊奇。是吗？

但也许只有我们会这样；只有我们这一小撮数码精英会花时间了解业内的几乎所有的最新动态和趋势，使自己的知识保持更新。地球上的其他人呢？大部分都可以忽略不计，这样正好。但是，当你试图搞清楚你的客户想要的是什么的时候，问题就来了。经常会是这样，他们根本不能明白你在说什么。这有些例子：

1：我父亲最近对我说他不知道如何回复一个人的短信。如果他拿的是一个很老式的手机，那也就没什么异议了，可他拿的是iPhone。这是个很难的问题吗？那好，他启动了“短信”程序指给我看。他指着这个界面，有点恼怒，说“那个该死的回复按钮在哪？？”。我都被能傻了。iPhone的界面可以说是最优雅、最简单易用的界面了。然而，上面却没有我父亲需要的一个一目了然的元素，一切都没有意义了：没有回复按钮意味着他不知道如何去回复。

2：几年之前，我在维护一个在线生日日历程序。界面非常的简单。它按月显示日期，在最上面有个大的红色按钮写着“添加生日“。按钮这么大，我认为人们不可能看不到它。不幸的是，他们真的看不到。在求助平台上我一天收到了100条求助信息，其中有60条第一句话是“我不知如何去添加一个生日“。起初我真是非常的不耐烦，这些愚昧的家伙宁愿费力发邮件给我，也不愿意多花两秒钟上下找一找。然而我之后做了一些实验，发现所有人都认为他们只需要在日历上点一下就可以添加生日。如果这么不灵，他们就会认为程序有问题。是我的错，不是他们。

3：在最近的一个招待会上，一个女士走过来告诉我，她的女儿也叫‘Loïs’。她说”我一直想遇到你，因为我发现你知道怎么把变音符号写到‘i’的上面，你能告诉我怎么在iPhone里这么做吗？”我解释给她，第二天在公司午餐的时候，我把这个故事告诉了同事。我一边笑一边说“很显然，有些人仍然不知道如何在iPhone了打出特殊字符！”。没人跟着我笑。然后有个人说“那个，我也不知道。你是怎么做到的？”然后另外一个人也承认也不知道，然后我发现没有人知道。

4：Patrick不久前接到他爸爸的一个电话，他爸爸想在网上找点东西。Patrick告诉他一个网址，他爸爸看起来不太明白他在说些什么。于是 Patrick说“你不知道吗，这是一个网站的网址”。他爸爸仍然不能理解，于是Patrick说“就是你在浏览器地址栏里输入的那行字符”，之后他爸爸答复道“我一点不知道你说的东西，我只是点击了一下上网的那个蓝色图标，Google就出来了，我输入了我想要的东西，然后就找到了”。很显然，你即使是不知道每个网站都有一个唯一的网址，你也能在网上订票，查看邮件，以及所有网上的事情。

所有的这些故事的用意是什么？如果你能在iPhone或电脑上打出想 ü, é 或 © 这样的特殊字符，如果你会使用你的iPhone上的大部分的应用，你就是我们这一小撮专家中的一员。不要以你为标准，你是个例外。使你的应用程序，网站，工具尽可能的简单，一定要找外人测一测。

那些人不是真正的笨，只是你比他们知道的多一些。不要让你的知识蒙蔽了自己。

新闻来源:外刊IT评论
[英文出处]：Compared to you, most people seem dumb Compared to you, most people seem dumb

漫画：为何你应该假装自己是一个电脑白痴

Bill — Tue, 31 Aug 2010 14:45:30 +0800

很长时间不写文章了，先转发一篇吧。看过之后深感切入生活，符合常理，意味深长啊！看来以后我要加以预防了。

点击查看大图

转自这里，图文原作：The Oatmeal 汉化：fall_ark

美国人这样教育小学生

Bill — Sun, 16 May 2010 16:16:44 +0800

看到一篇这样的文章，描述了美国怎样教育儿童成材，转载过来。我想我们需要吸取的教训太多了，但是就目前来看是无法改变的，可以改变的只能是我们自己。故，多培养一些自己的自学能力，培养自己的创新能力，培养下一代不像我们这样呆板。

当我把九岁的儿子带到美国，送他进那所离公寓不远的美国小学的时候，我就象是把自己最心爱的东西交给了一个我并不信任的人去保管，终日忧心忡忡。这是一种什么样的学校啊！学生可以在课堂上放声大笑，每天至少让学生玩二个小时，下午不到三点就放学回家，最让我大开眼界的是没有教科书。

那个金发碧眼的美国女教师看见了我儿子带去的中国小学四年级课本后，温文尔雅地说：“我可以告诉你，六年级以前，他的数学不用学了！”面对她充满善意的笑脸，我就像挨了一闷棍。一时间，真怀疑把儿子带到美国来是不是干了一生最蠢的一件事。

日子一天一天过去，看着儿子每天背着空空的书包兴高采烈的去上学，我的心就止不住一片哀伤。在中国，他从小学一年级开始，书包就满满的、沉沉的，从一年级到四年级换了三个书包，一个比一个大，让人感到“知识”的重量在增加。而在美国，他没了负担，这能叫上学吗？一个学期过去了，把儿子叫到面前，问他美国学校给他最深的印象是什么，他笑着给我一句美国英语：“自由！”这两个字像砖头一样拍在我的脑门上。

此时，真是一片深情怀念中国教育。似乎更加深刻地理解了为什么中国孩子老是能在国际上拿奥林匹克学习竞赛的金牌。不过，事已至此？也只能听天由命。

不知不觉一年过去了，儿子的英语长进不少，放学后也不直接回家了，而是常去图书馆，不时就背回一大书包的书来。问他一次借这么多书干什么，他一边看着借来的书一边打着电脑，头也不抬地说：“作业。”

这叫作业吗？一看孩子打在电脑屏幕上的标题，我真有些哭笑不得――《中国的昨天和今天》，这样大的题目，即使是博士，敢去做吗？

于是我严声厉色地问是谁的主意，儿子坦然相告：老师说美国是移民国家，让每个同学写一篇介绍自己祖先生活的国度的文章。要求概括这个国家的历史、地理、文化，分析它与美国的不同，说明自己的看法。我听了，连叹息的力气也没有了，我真不知道让一个十岁的孩子去做这样一个连成年人也未必能做的工程，会是一种什么结果？只觉得一个十岁的孩子如果被教育得不知天高地厚，以后恐怕是连吃饭的本事也没有了。

过了几天，儿子就完成了这篇作业。没想到，打印出来的是一本二十多页的小册子。从九曲黄河到象形文字，从丝路到五星红旗……热热闹闹。我没赞成，也没批评，因为我自己有点发楞，一是因为我看见儿子把这篇文章分出了章与节，二是在文章最后列出了参考书目。我想，这是我读研究生之后才运用的写作方式，那时，我三十岁。

不久，儿子的另一篇作文又出来了。这次是《我怎么看人类文化》。如果说上次的作业还有范围可循，这次真可谓不着边际了。儿子真诚地问我：“饺子是文化吗？”为了不耽误后代，我只好和儿子一起查阅权威的工具书。费了一番气力，我们完成了从抽象到具体又从具体到抽象的反反覆覆的折腾，儿子又是几个晚上坐在电脑前煞有介事地作文章。我看他那专心致志的样子，不禁心中苦笑，一个小学生，怎么去理解“文化”这个内涵无限丰富而外延又无法确定的概念呢？但愿对 “吃”兴趣无穷的儿子别在饺子、包子上大作文章。在美国教育中已经变得无拘无束的儿子无疑是把文章作出来了，这次打印出来的是十页，又是自己的封面，文章后面又列着一本本的参考书。他洋洋得意地对我说：“你说什么是文化？其实超简单――就是人创造出来让人享受的一切。”那自信的样子，似乎发现了别人没能发现的真理。后来，孩子把老师看过的作业带回来，上面有老师的批语：“我安排本次作业的初衷是让孩子们开阔眼界，活跃思维，而读他们作业的结果，往往是我进入了我希望孩子们进入的境界。”问儿子这批语是什么意思。

儿子说，老师没为我们感到骄傲，但是她为我们感到震惊。“是不是？”儿子问我。

我无言以对，我觉得这孩子怎么一下子懂了这么多事？再一想，也难怪，连文化的题目都敢作的孩子，还有什么不敢断言的事吗？

儿子六年级快结束时，老师留给他们的作业是一串关于“二次世界大战”的问题。“你认为谁对这场战争负有责任？”“你认为纳粹德国失败的原因是什么？”“如果你是杜鲁门总统的高级顾问，你将对美国投原子弹持什么态度？”“你是否认为当时只有投放原子弹一个办法去结束战争？”“你认为今天避免战争的最好办法是什么？”――如果是两年前，见到这种问题，我肯定会抱怨：这哪里是作业，分明是竞选参议员的前期训练！而此时，我已经能平心静气地循思其中的道理了。

学校和老师正是在这一个个设问之中，向孩子们传输一种人道主义的价值观，引导孩子们去关注人类的命运，让孩子们学习思考重大问题的方法。这些问题在课堂上都没有标准答案，它的答案，有些可能需要孩子们用一生去寻索。看着十二岁的儿子为完成这些作业兴致勃勃地看书查资料的样子，我不禁想起当年我学二战史的样子，按照年代事件死记应背，书中的结论明知迂腐也当成《圣经》去记，不然，怎么通过考试去奔光明前程呢？此时我在想，我们在追求知识的过程中，重复前人的结论往往大大多于自己的思考。而没有自己的思考，就难有新的创造。

儿子小学毕业的时候，已经能够熟练地在图书馆利用电脑和微缩胶片系统查找他所需要的各种文字和图象资料了。有一天，我们俩为狮子和豹的觅食习性争论起来。第二天，他就从图书馆借来了美国国家地理学会拍摄的介绍这种动物的录像带，拉着我一边看，一边讨论。孩子面对他不懂的东西，已经知道到哪里里去寻找答案了。

儿子的变化促使我重新去看美国的小学教育。我发现，美国的小学虽然没有在课堂上对孩子们进行大量的知识灌输，但是他们想方设法把孩子的目光引向校外那个无边无际的知识海洋，他们要让孩子知道，生活的一切时间和空间都是他们学习的课堂；他们没有让孩子去死记硬背大量的公式和定理，但是，他们煞费苦心地告诉孩子怎样去思考问题，教给孩子们面对陌生领域寻找答案的方法；他们从不用考试把学生分成三六九等，而是竭尽全力去肯定孩子们一切努力，去赞扬孩子们自己思考的一切结论，去保护和激励孩子们所有的创作欲望和尝试。

有一次，我问儿子的老师：“你们怎么不让孩子背记一些重要的东西呢？” 老师笑着说：“对人的创造能力中有两个东西比死记硬背更重要：一个是他要知道到哪里里去寻找所需要的比它能够记忆的多得多的知识；再一个是他综合使用这些知识进行新的创造的能力。死记硬背，就不会让一个人知识丰富，也不会让一个人变得聪明，这就是我的观点。”

我不禁记起我的一个好朋友和我的一次谈话。他学的是天文学，从走进美国大学研究所的第一天起，到拿下博士学位的整整五年，他一直以优异的成绩享受系里提供的优厚奖学金。他曾对我说：“我觉得很奇怪，要是凭课堂上的学习成绩拿奖学金，美国人常常不是中国人的对手，可是一到实践领域，搞点研究性题目，中国学生往往没有美国学生那么机灵，那么富有创造性。”我想，他的感受可能正是两种不同的基础教育体系所造成的人之间的差异。中国人太习惯于在一个划定的框子里去旅展拳脚了，一旦失去了常规的参照，对不少中国人来说感到的可能往往并不是自由，而是慌恐和茫然。

我常常想到中国的小学教育，想到那些课堂上双手背后坐得笔直的孩子们，想到那些沉重的课程、繁多的作业、严格的考试……它让人感到一种神圣与威严的同时，也让人感到巨大的压抑和束缚，但是多少代人都顺从着它的意志，把它视为一种改变命运的出路。这是一种文化的延续，它或许有着自身的辉煌，但是面对需要每个人发挥创造力的信息社会，面对明天的世界，我们又该怎样审视这种孕育了我们自身的文明呢？

你知道快递公司是怎样快递的吗？我来告诉你

Bill — Thu, 13 May 2010 09:36:16 +0800

啥话都不说，上图

点击查看大图