3月2日，包车，峪道河大桥下车。上山轨迹丢失，上山处有村民看守收费。号称错长城，基本上是错过长城。从山沟下山，都是大石，特别不好走，路上有冰河。
路线：http://www.foooooot.com/trip/140583/
峪道河-小水峪穿越
作者： Solrex
莲花池-神堂峪长城
2月16日，自驾，两辆车，车停到莲花池村和神堂峪出口。上升下降不多，坍圮严重，险处略多，个别地方由山势代替城墙，中间有一个鲤鱼背。
路线：http://www.foooooot.com/trip/137202
大榛峪-旺泉峪-响水湖-牛犄角环形穿越
12月14日，自驾，车停到大榛峪村卫生服务站路边。不进响水湖景区，从右侧道路进沟上山。刚进山时，在哪里上长城发生了分歧，硬是从一个大岩石那上城墙，浪费了好长时间找路。建议后来者从道路上上城墙。
路线：http://www.foooooot.com/trip/124093/
Jabra Freeway车载蓝牙
本人有幸在北京市缩减摇号规模前，半年，摇到了一个小客车指标，购入了一辆 2013 款别克凯越汽车。当然，出于一贯地性(kou)价(men)比考虑，选择了自动挡低配款，也就是 14 寸钢轮毂、无天窗、无 VoiceLink、非真皮座椅、无倒车雷达。通过团友的争取，倒是赠送了倒车雷达——这东西的确有用。
开车总有需要打电话的时候，虽然不愿意冒险手持来接，但每次上车都要塞耳机也挺烦人的，于是穷人就开始羡慕高端的车载蓝牙。一个偶然的机会发现了 Jabra Freeway 这个车载蓝牙，据说美国亚马逊打折，我就拜托一个同学帮忙买了一个。价钱是450块不到，比京东卖的便宜多了。使用了半年，这里整体做个评价，供感兴趣的朋友参考。
这个东东用法呢，就是卡在汽车的遮光板上，当作车载蓝牙使用，免去了（忘）戴蓝牙耳机的烦恼。从我的使用过程来看，有几个优点值得夸一下。
一是易用。自动感应开关车门开关机，进入汽车以后蓝牙就会自动连接上；可连接两部蓝牙手机；连接部分手机时，可以在手机上显示 Freeway 的剩余电量；来电自动播报号码或姓名。这样上下车时完全不用理会它的存在，来电后只要点一下最大的通话按钮就能接通，省心。
二是声大。在声音表现上，其实它就是个蓝牙音箱，而且你在外出时也完全可以把它就当成个音箱用。这个音箱的声音能盖过车载音响。如果上高速或者车里开着广播，手机导航的播报声音就会显得很小，有 Freeway 放大音量，完全没有任何问题。音量控制按钮也很清楚，不会按错。
三是耐用。充一次电，差不多能撑两三个月，还是在经常使用导航外放音量的情况下。可以直接连点烟器充电，即使路上没电了也不用担心。
因为车载音响播放的是 U 盘，很方便，完全不需要手机通过 Freeway 再用 FM 发射音乐到车载音响。所以高级功能 RDS 完全没用过，不予评价。
下面说一下缺点，就是傻！在买来的第一天，我就把它刷成了中文系统，因为这样才能准确念出来电的联系人名字。但我发现这是 Freeway 中文版的唯一好处。Freeway 本来可以靠语音命令来调出“接听、重拨、回拨、电量、配对”等功能，但无论我尝试多少次，中文版的 Freeway 只能识别“配对”和“我能说什么”这两个命令，而且会把所有其它命令都识别成这两个其中之一。所以，在我这里，中文版的 Freeway 语音控制系统几乎是不可用状态。
总体来说，在关键的功能上，Jabra Freeway 没有让我失望，要知道好一点的蓝牙音箱或者蓝牙耳机也得两三百，Freeway 总比那些强多了。要是 Jabra 认真地做一下 Freeway 的中文版固件，把语音识别率做高一些，就完美了。
更新：13 年 9 月 Jabra 更新了一下固件，语音命令识别比原来好多了！
九寨沟印象
国庆期间的九寨沟并不是很漂亮，主要因为树叶还没有变得缤纷。但工作以后很多事情都有些不得已，老婆的假期短且不灵活是不得已，自己的工作节奏是不得已，有时候只能凑合着出发了。
原计划行程是 10 月中下旬出发，结果国庆节前临时改变主意，提前三天订好了 9 月 27 日早班川航 3U8516 的机票。趁着国庆人潮还没有涌出之前，从北京直飞九寨沟。说到直飞，还有个笑话，上飞机前才发现航班是经停重庆的，怪不得票价要便宜，可见准备之仓促，也差不多算是“一次说走就走的旅程”了。
从重庆到九黄机场这段航程，飞机的颠簸不断，但也算不上恐怖。在下降过程中，能看到云层中冒出来的雪山尖顶，些微有一种仙境的感觉。九黄机场机场貌似是削平几个山头建立来的半山平地，飞机不是很多，很空旷。
几次地震报道给我带来的印象，是说四川的公路非常危险，我们坐在机场去九寨沟镇的巴士第一排，赶紧系上了安全带。但实际上这一段的路况非常好，所谓的“九道弯”，其实比很多北京的山区公路都不如，而且车非常少，没什么大卡车。还有一点要秒杀北京山区的是，路边一直伴随着水量充足的溪流，高速流水的哗哗声盖过引擎声。
选择的旅店在九寨沟景区西北大约 1.3 公里的彭丰村的一片客栈群中，叫"客之家客栈"，有无线、热水，房间也干净，条件还算不错。但九寨沟的旅店大多数不提供一次性的拖鞋、洗漱用品，一定要记得自带。到店以后先睡了一觉，没办法，老婆是累了就睡觉的习惯。
傍晚起来，沿着公路走到景区门口，那是一个挺大的广场，前一天可以买第二天的门票，所以就顺道把门票买了。景区东侧有九寨沟的水和公路侧沟溪水交汇，沟里出来的水偏蓝绿色，沿公路边流下来的水呈黄色，泾渭分明，对我这种孤陋寡闻的人来说也算奇观了。
九寨沟长途汽车站在景区东北大约 1 公里的九寨阳光大酒店院子里，为了考察去成都长途汽车的可行性，我们又溜达到汽车站，顺便把第三天的汽车票买了，然后又走回旅馆。这个距离其实蛮尴尬的，走的话嫌远，打车的话嫌近。如果下次再来九寨沟，我大概会选择长途汽车站附近坐汽车方便，或者九寨沟镇上坐机场大巴方便，酒店档次也能略高一些。
特别说一下空气，本来以为从北京到九寨沟能洗洗肺，没想到由于特殊的地理位置限制，这里的空气反而更差。景区左右也是一条沟，客栈、饭店、民居、公路全部挤在狭窄的沟里，偏偏汽车又很多，公路两边都弥漫着尾气味。但景点内部路线够长，所以还好。
大众点评网在九寨沟的影响显然不够大，只有个别的几家饭店有评价，数量也非常少。沟里老板看到这篇文章，建议去刷刷点评的评论，好歹给我们几个靠谱的选项。选了半天，最后去了一家叫做“阿布氇孜”吃藏餐。特点就是装修个性、肉太老嚼不烂、吃完有人唱歌送哈达。还值得一提的是九寨沟周边物价比较高，大概是北京的2~3倍，如果贪吃可以适当带些零食，比当地买便宜。
第二天一大早就爬起来，迎着晨光吃早饭，然后就入沟了。九寨沟跟八达岭长城类似，都是“Y”字形（八达岭长城可能更类 V），进去以后先胡乱坐一辆车上行，到 Y 字最顶上的某个枝桠，然后再往下逛到 Y 字的中心萨日朗中心站，然后再去另一个枝桠，最后一直下到出口。Y 字沿线就是各种命名的景点，大部分是湖和瀑布，沿线有车站，离得远的景点可以坐一段车，不必非得走路。
在北方平原长大的人，真的无法想象山里的水是那么的丰富。九寨沟里到处都是湖和水，我最喜欢的有这几个：
其实漂亮的地方不止这几处，只是走着走着就把眼睛走挑剔了。九寨沟的水，任意拿出来一片，都足够秒杀其它地方，偏偏它们聚在了一起。我们去的时节树叶才刚刚泛黄，还没有到火红、金黄的氛围，所以没法体会更绚烂的美。但总的来说，不虚此行，有机会还想换个季节再来一次。
莲花池-慕田峪长城徒步
上周六，冒着北京粘稠的雾霾，我跟着绿野的“梦在珠峰”团队去长城走了一圈。野长城边的红叶没有到惊艳的地步，徒步的距离也不算多长（6公里左右），因而一点也不辛苦。总的来说，玩得还算开心。只是刚开始从莲花池公路边上野长城那段，因为还有其它团队一起上，人有些略多。也许是因为这里是进慕田峪景区最方便的逃票路线吧。
慕田峪景区最东头的敌楼（应该叫“慕字一台”），其实是一个三岔路口。我们从敌楼的窗户里钻出去，往南走了两个敌楼，休息加野餐。人特别少，感觉很好。野餐完毕后，本来计划走到 23 号敌楼的大家都不想走了，就从慕字七台和八台间的下山道出了景区。
路线：http://www.foooooot.com/trip/113900/
下山后，又去找地方吃了顿虹鳟鱼。不太顺利的是由于农家的接待能力不够强，二十多个人等了两个小时才吃上饭。晚上 8 点才开始回京，到家都 10 点多了。
八大处-香山-百望山穿越
刷手机 ROM 时忘记上传六只脚的行程，导致九寨沟和这次行程的轨迹记录丢失了。让我比较沮丧，因为这让揣了整天手机、甚至要充电保证轨迹记录的辛苦完全没有了收获。这次活动还是蛮值得纪念的：从八大处，经过香山、香山植物园，然后出百望山景区，总共有 23 公里。8 点 10 分开始爬，用时 7 小时到百望山公园门口，中间翻越了好多个大小山头，下山后感觉体力都快耗尽了。
行程发生在 10 月 30 日，也过去比较久了，不想多说，上几张图片留念罢了。
寻找更快的平方根倒数算法
机器学习的模型相关计算中，有很多诡异的运算。单个运算的开销很不起眼，但如果这些运算的量足够大，也会对性能产生一定的影响。这里谈的就是一个简单的运算：
a = b / sqrt(c);
对于 C/C++ 语言的程序员来说，sqrt 已经是非常基础的库函数，它的底层实现也仅仅是简单的一句 FSQRT (双精度是 SQRTSD) 指令，看起来没有什么优化的余地。但事实上 intel 提供了一个更快的指令，那就是 SQRTSS，利用这条指令，平方根倒数的计算速度可以达到 sqrt 版本的两倍（实测，与[1]相同）。你可以这样使用它：
#include <xmmintrin.h>
...
__m128 in = _mm_load_ss(&c);
__m128 out = _mm_sqrt_ss(in);
_mm_store_ss(&c, out);
a = b/c;
...
但这就是优化的尽头了么？不，单就求平方根倒数来说，还有一个神奇的近似算法，叫做 Fast Inverse Square Root（平方根倒数速算法）。一个神人在 Quake III Arena 游戏中使用了一个神奇的数字 0x5f3759df，创造了这个神奇的算法，这个算法可以将平方根倒数的计算速度提升到 sqrt 的 3 倍多（实测，效果比[1]差）。
float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
return y;
}
但 3 倍就是优化的尽头了么？很不幸，邪恶的 Intel 提供了这样一条指令 RSQRTSS，从硬件上支持了这个近似算法。利用这条指令，平方根倒数的计算速度能够达到 sqrt 版本的 6 倍以上！！！
#include <xmmintrin.h>
...
__m128 in = _mm_load_ss(&c);
__m128 out = _mm_rsqrt_ss(in);
_mm_store_ss(&c, out);
a = b*c;
...
虽然平方根倒数速算法只是一种近似算法，并且只有单精度版本，但是对 RSQRTSS 指令的简单测试发现大部分情况下误差在万分之一以下，指令说明书中给出的误差是 ±1.5*2^-12[2]，在非精确数值计算的工程系统中已经足够用了。
它带来的一个更有趣的后果是：如果使用 RSQRTSS 计算出来 c 的平方根倒数，然后再乘以 c，就得到了 c 的平方根近似值。用它可以反过来加速 sqrt 的运算！[1]
注1：编译相关程序时，需要打开优化开关，以实现函数的 inline
注2：RSQRTSS 和 SQRTSS 均有一个向量版本，如 RSQRTPS，可以同时计算 4 个 float 的平方根倒数；
[1] Timing square root
[2] RSQRTSS
马套峡谷-水头长城-镇边城徒步
这是跟随“梦在珠峰”这个绿野团队的第二次活动，同样的时间地点集合，遇到类似的问题：司机因看到禁行大车的标志而不肯直接开到镇边城，于是本来的“镇边城-水头长城-马套峡谷”穿越，变成了“马套峡谷-水头长城-镇边城-马套峡谷”的往返，距离也从 15 公里增加到 25 公里。这两次活动真是充分证明了户外运动的不确定性。本来以为路途很轻松所以把登山杖丢在家里，而带上了单反相机，后来证明有些失策。
马套峡谷原来叫黑沟，近期在进行旅游资源开发，改名叫做“南石洋大峡谷”。峡谷中间的路已经整修的比较规范，徒步几乎没有难度。水头长城是一段野长城，有很强的纪念意义，抗日战争时日军曾从这里突破，包抄国军后路，导致南口战役的失败。从历史照片来看，现在的水头长城还基本维持着当年的原貌，只是城墙坍塌了一些。镇边城也是南口战役激战的一个地点，现在看起来只是一个小村子。
水头长城靠近马套峡谷那面坍圮的比较厉害，爬起来很费劲，而且有些危险。但是在烽火台上吹着山风，看群山起伏，长城绵延，景色真是美不胜收，非常棒！
我以前一直有一个错觉：长城没剩多长了，剩下的应该都被整修成了景点。这次水头长城徒步以后，我仔细地看了一下卫星图，才发现长城居然还有那么长！走完野长城才感叹，修长城的劳动人民实在是太伟大了！下图中央坍圮的位置，就是当年日军通过的水头隘口，旁边竖着一面纪念碑。同时这段长城的圆角矩形烽火台，据说也是一大特色。
另一个方向的长城，几乎不成样子了，但遗迹仍然伸向远方。
下面是这次徒步的轨迹，其中有一段走岔了走了回头路，然后尾巴上一大段 10 公里走的是公路。这段公路一直走到天黑，7点多些才走到大巴车的位置。
路线：http://www.foooooot.com/trip/102227/
走了几次户外才发现北京周边还有如此地好景色，在人迹罕至的地方徒步实在是胜过景点太多了！
小海陀一日穿越
知道有绿野这个论坛让我欣喜不已。以前总发愁想郊游没办法，从没想过网上可以聚集起这样一批人。为了让自己的周末过得充实些，9 月 7 日初体验了一把自由结队的活动，参加了绿野论坛上“梦在珠峰”团队的“大、小海陀一日往返”，这是今年爬的第二座千米峰。
通告是 7 点 10 分在阜成门附近集合，但还是不可避免地有人迟到。7 点半左右大巴发车前往大海陀村，京藏堵到一塌糊涂，11 点左右才到海陀山附近。不幸地是前往大海陀村的公路限高 2.3 米，大伙儿只好在 X012 县道靠近阎家坪附近的限高架那下车，徒步从阎家坪登山，这下整段路程的强度和难度一下加大了不少，也为后面的困难埋下了伏笔。
本来是 29 人，刚上山就有一位女生晕车导致呕吐，加之看到居然是走野路，她的三个同事就陪她撤了下去。剩下的人继续登山，走了大约 8 公里才到山顶，中间集体仅休息一次吃饭。整个队伍被拉长到超过一公里。由于走的是山脊，有起伏和树木遮挡，从队中间都看不到两头。手机信号也很差或者没有，只能靠手台通信。幸好我为了这次活动买了个手台，事实证明发挥的作用还不小。
我上到松山（小海陀）山顶的时间大约是3点，大小海陀中间的鞍部平地是北京著名的扎营去处，营地能容纳几百顶帐篷。由于下山驴友反馈大海坨山有持枪民兵把守，再加上时间不是很够，领队就决定放弃登顶大海坨山，于是也没有真正走到鞍部去观察一下宿营的盛况。行程也由“大、小海陀一日往返”变成了“小海陀一日穿越”。
4 点一刻开始下山，没有从原路返回，而是下到一个垭口后从著名的销魂坡下去，然后到西大庄科。从后来的gps数据来看，销魂坡的平均坡度角应该超过了 45 度，部分路段相当惊险。要时刻提防可能被上方驴友不小心踢下来的碎石块，搞得我想着下次有必要带个头盔过来。
虽然有陡坡，但下山的路程一点都不短，轨迹显示大概有 7.6 公里。 由于天色已晚，大家都埋头赶路，前后队距离拉得更长。这条路线与上山完全不同，山脊的路线大部分是高山草甸，树很少，很空旷风景很美；下山路上全是茂密树林和灌木，根本看不了多远。我在前队里，总算在天黑前 7 点赶到了山下。只有我带了头灯，留给岔路口等后队的同学，他们一直等到快 21 点才全部下来。后来跟我反馈说头灯作用很大，能照亮一排人下山。
21点多大巴开始回城，23 点 15 才到阜成门，连地铁都没有了。
路线：http://www.foooooot.com/trip/100972/
事后我总结了一下：登山杖、手台和头灯起了很大作用，为了安全得常备；路线的临时更改导致运动强度加大，需要有一定的心理和体力准备；爬山不应该穿短裤，除了概率低的被划伤或被虫咬之外，草枝或石子会老往鞋里进更让人不舒服。最后，奉上山顶傻笑照片一张：
自驾云蒙山
最近看 zhiqiang 老晒登山、户外照片，搞得自己心里也痒痒的。正好我的车到了首保时间才开了两千公里，于是和几个同事好友约了一起自驾去爬云蒙山，顺便也磨磨车。后来约到 8 个人，两辆车。
周六早上 6 点起床，6 点半左右出发，分别在阜石路和北三环接了两个朋友，7 点上京承，7 点 20 到收费站，然后到第一个服务区与另外一辆车集合，重新分配人员。因为起得早，市区基本没堵车，只是在崔各庄收费站前堵了一点点。
后面是半程高速，怀柔桥转京密高速然后上京加路，在导航到目的地之前注意“云蒙山森林公园”路标即可。京加路比较好走，只是到云蒙山的岔道急弯比较多，距离不长。
我们9点左右到的景区，门口买票，开车进景区停车。9 点 15 分开始爬山，一路上大伙儿那是相当地欢乐。由于之前在六只脚大致查过轨迹，所以一路上都用六只脚看行走距离和海拔，我们戏称为“查看进度条”。对目的地的预判对分配食物、饮水和体力有不少的帮助，不过后来还是发现普遍食物带的多，饮水略有些少。
最终大约 12 点 30 分到达主峰山顶，拍了会儿照。后来重看照片，觉得从山顶看风光角度比半山腰略差一点，主要是绿色的山峰较多，岩石斑驳的山坡较少。云蒙山得名“小黄山”，还是斑驳的地方有看头。
拍完照片找了一个树荫吃东西，聊了会儿天，13点30开始下山，在一个分叉路发生了分歧，走了一段岔路后决定还是原路返回，大约浪费了半小时。刚下了几百米，就发现天色阴暗，偶尔有雷声传来。所有人都没带雨具，于是大家都开始加速下山，速度快了许多。中间的确滴了几点雨，但在树叶遮蔽下没淋到多少，倒是后来下到山脚发现山脚雨应该更大。走到半山腰厕所处太阳重新出来，正好一个朋友抽筋了，这才停下来等走得慢的，集合继续往下走，16点左右下到停车场。下面是爬山行程的整个轨迹：
路线：http://www.foooooot.com/trip/99623/
16点20分开车返城，在离收费站大约10公里的地方开始行驶缓慢，最终18点左右到达京承崔各庄收费站。从百度地图上看各环路一片红，于是趁收费站到5环间还没有堵死，快速从来广营桥出口出去走辅路转市内道路了。送了两个朋友到地铁站，差不多快7点转到3环回家，北三环西侧和西三环一路畅通，7点10分顺利到家。
7个小时爬山，5个多小时开车，路上还挺精神，但到家下车以后觉得脑袋有些疼。安排得有些满了，以后爬山的话，还是尽量争取参加集体包车的活动。
std::inner_product的简单性能测试
最近团队产品中用到了一些机器学习方面的算法，涉及到求向量内积，采取的是最朴素的实现方式（元素乘积循环相加）。有一天路上想到 STL 提供了一个模板函数 std::inner_product ，就好奇 libstdc++ 实现上是否对该算法做了什么优化呢？
于是做了个简单的实验：1000 维 double 类型向量乘积，用 std::inner_product 和朴素方法分别计算10000次，g++ -O2优化。第一轮使用原生 double 类型数组，第二轮使用 vector<double> 容器，分别在三个机器环境下进行了计算。
// Processors | physical = 2, cores = 32, virtual = 12, hyperthreading = no // Speeds | 12x2400.186 // Models | 12xIntel(R) Xeon(R) CPU E5645 @ 2.40GHz // Caches | 12x256 KB // GCC | version 3.4.5 20051201 (Red Hat 3.4.5-2) a*b : std::inner_product(27.934ms), for loop(40.061ms) a_v*b_v : std::inner_product(27.878ms), for loop(40.04ms) // Processors | physical = 2, cores = 12, virtual = 12, hyperthreading = no // Speeds | 12x2100.173 // Models | 12xAMD Opteron(tm) Processor 4170 HE // Caches | 12x512 KB // GCC | version 3.4.5 20051201 (Red Hat 3.4.5-2) a*b : std::inner_product(31.242ms), for loop(47.853ms) a_v*b_v : std::inner_product(31.301ms), for loop(47.815ms) // Processors | physical = 1, cores = 0, virtual = 1, hyperthreading = no // Speeds | 1x2572.652 // Models | 1xIntel(R) Core(TM) i5-3320M CPU @ 2.60GHz // Caches | 1x6144 KB // GCC | version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) a*b : std::inner_product(41.76ms), for loop(33.165ms) a_v*b_v : std::inner_product(35.913ms), for loop(32.881ms)
可以看出不同环境下 std::inner_product 的表现不尽相同，与朴素的方式相比有优有劣。瞄了一眼 gcc 4.8 的 libstdc++ 的代码，没有注意到 std::inner_product 对基本类型做什么 SSE 指令的优化。不过倒是有个并行计算的版本，可能对超大的向量计算有帮助。
虽然从性能上没有看到明显的优势，但毕竟 std::inner_product 可以简化一个循环的编码，至少可以少测一个分支嘛。而且配合重载函数的后两个 functor 参数，可以做一些有趣的事情，比如算一组数的平方和，比较两个字符串相同字符的数量等。以后呢可以多尝试一下用标准库的算法而不是自己写循环。
寻找最快的Python字符串插入方式
在 MapReduce 分布式计算时有这样一种场景：mapper 输入来自多个不同的数据源，共同点是每行记录第一列是作为 key 的 id 列，reducer 需要根据数据源的不同，进行相应的处理。由于数据到 reducer 阶段已经无法区分来自什么文件，所以一般采取的方法是 mapper 为数据记录打一个 TAG。为了便于使用，我习惯于把这个 TAG 打到数据的第二列（第一列为 id 列，作为 reduce/join 的 key），所以有这样的 mapper 函数：
def mapper1(line):
l = line.split('\t', 1)
return "%s\t%s\t%s" % (l[0], 'TAG', l[1])
这样给定输入：
s = "3001 VALUE"
mapper1(s) 的结果就是：
s = "3001 TAG VALUE"
这是一个潜意识就想到的很直白的函数，但是我今天忽然脑子转筋，陷入了“这是最快的吗”思维怪圈里。于是我就想，还有什么其它方法呢？哦，格式化的表达式可以用 string 的 + 运算来表示：
def mapper2(line):
l = line.split('\t', 1)
return l[0] + '\t' + 'TAG' + '\t' + l[1]
上面是故意将 '\t' 分开写，因为一般 TAG 是以变量方式传入的。还有，都说 join 比 + 快，那么也可以这样：
def mapper3(line):
l = line.split('\t', 1)
l.insert(1, 'TAG')
return '\t'.join(l)
split 可能要消耗额外的空间，那就换 find：
def mapper4(line):
pos = line.find('\t')
return "%s\t%s\t%s" % (line[0:pos], 'TAG', line[pos+1:])
变态一点儿，第一个数是整数嘛，换成整型输出：
def mapper5(line):
pos = line.find('\t')
pid = long(line[0:pos])
return "%d\t%s\t%s" % (pid, 'TAG', line[pos+1:])
再换个思路，split 可以换成 partition：
def mapper6(line):
(h,s,t) = line.partition('\t')
return "%s\t%s\t%s" % (h, 'TAG', t)
或者干脆 ticky 一点儿，用 replace 替换第一个找到的制表符：
def mapper7(line):
return line.replace('\t', '\t'+'TAG'+'\t', 1)
哇，看一下，原来可选的方法还真不少，而且我相信这肯定没有列举到所有的方法。看到这里，就这几个有限的算法，你猜一下哪个最快？最快的比最慢的快多少？
先把计时方法贴一下：
for i in range(1,8):
f = 'mapper%d(s)' % i
su = "from __main__ import mapper%d,s" % i
print f, ':', timeit.Timer(f, setup=su).timeit()
下面是答案：
mapper1(s) : 1.32489800453 mapper2(s) : 1.2933549881 mapper3(s) : 1.65229916573 mapper4(s) : 1.22059297562 mapper5(s) : 2.60358095169 mapper6(s) : 0.956777095795 mapper7(s) : 0.726199865341
最后胜出的是 mapper7 （tricky 的 replace 方法），最慢的是 mapper5 （蛋疼的 id 转数字方法），最慢的耗时是最慢的约 3.6 倍。最早想到的 mapper1 方法在 7 种方法中排名——第 5！耗时是最快方法的 1.8 倍。考虑到 mapper 足够简单，这个将近一倍的开销还是有一点点意义的。
最后，欢迎回复给出更快的方法！
北京生活 TIPS - 谈谈日常理财
真正意识到要摆脱单纯定期存款的理财方式，是在付按揭首付款时。由于并未提前做买房的计划，几乎所有的存款都是一年期（≥3.25%），提前支取的结果是利息按照活期（≤0.5%）计算，大概损失了几千的利息——虽然现在看来房价的涨幅让这点儿损失不值一提。
感谢水木社区的“金融产品与个人理财版”（俗称“钱包版”），让我能充分地学习网友们的智慧。这个版上的网友对各项金融业务的熟悉和专业程度，绝对超过大部分银行/证券公司自己的柜员。举几个例子：看到版上有网友说中信网银能够查询个人信用报告，我就去开了个，柜员信誓旦旦地告诉我这项服务已经关闭了——事实上一直可用；看到版上有网友说民生银行办理资金归集送U盾，我也去办一个，大堂经理完全不知道这件事情，还专门向上级请示才给办了。
很多人对理财收益多个 1%、免费送个 U 盾、免费转账/取款这种“钱包版”流行的小便宜很不屑，但我是这样看这个问题：第一，我内心承认有便宜占会让自己心情很好；第二，我把这种出于对活动、渠道、规则的充分了解，并合理利用获取收益的做法视为生活能力的锻炼，也有助于常识的培养。下面不会列举我了解到的所有理财方式，只是简单谈谈我现在怎么管钱。
怎么存钱
随时可能会使用到的资金（一般小于 5w），存在货币基金里，随时取用。简单了解一下货币基金和其历史收益，你就会知道这是一个基本无风险的投资渠道。近几年其收益基本都跑赢了定期存款，例如“博时现金收益”最近一年的收益是 4.07%，“华夏现金增利”最近一年的收益是 3.93%。而货币基金最大的优势，其实在流动性，一般申购和赎回都是 T+1 完成，即赎回款在第二个工作日到帐。华夏、嘉实等 7x24 小时 T+0 赎回方式的推广更是让这种流动性发挥到极致，7x24 T+0 赎回意味着你基本是以活期存款的流动性获得超过定期存款的收益——你还能奢望得到什么呢？
想弄清楚货币基金的操作，需要先搞明白以下几个关键词：货币（市场）型基金、风险评估、基金直销、基金代销、申购、赎回、T+0、T+1、T+2、红利转投、万份收益、7日年化收益。这里可以比较所有货币基金的收益，个人推荐购买华夏基金网站直销的“华夏现金增利”，也叫“华夏现金宝”，赎回时选择“快速赎回”就能实时到帐。记得装华夏基金手机应用，这样就相当于把卡带身上了。
一段时间内用不到的较大量资金（大于 5w），购买低风险低门槛的银行理财，一般年化收益能达到 4%~5.5%。但一定要注意区分银行理财和银行代销的理财，不要贪图收益高，6% 以上年化收益的不要动心，极可能有陷阱。对于生活变动较大的年轻人来说，不要买超过 6 个月封闭期的理财，要预备可能产生的大额支出。一般来说，小银行的理财收益高于大银行，各银行收益如何可能需要自己去探索。如果畏惧银行间搬钱太麻烦或有手续费，可以看一下这篇文章。个人推荐平安银行（和盈、强债）和民生银行（非凡）的理财产品。
关于炒股
对生活质量影响不大的一部分钱，可以尝试一下买股票。开户时需要比较一下交易手续费，一般万五（万分之五）到千一较为合适，千一以上有些高了，万五以下一般人也谈不下来。很多人视炒股为洪水猛兽，我把它视为一种社会实践。而且随着时代的发展，中国的股市肯定会越来越成熟，如果我拒其千里之外，这份知识下一代还得从别处探索，我会觉得这是一种教育失败。炒股还会让你格外关注经济形势和新闻，更深切地感受中国经济脉搏的跳动。不过一定要谨慎，我的看法是投资不宜占比过高（30%总资产以内），不宜追加投资（不是专业炒股）。关于如何炒股，我也在学习和探索，目前主要学习价值投资，关注雪球论坛上的讨论。
关于还贷
有闲钱的情况下，要不要提前还住房按揭贷款？我觉得如果按揭利率低的话，没有必要提前还。以公积金贷款为例，5年以上名义按揭利率为 4.5%，按月折算实际年化利率约为 (1 + 0.045/12)^12 - 1 = 4.594%。如果有收益不低于年化 4.6% 的投资方式（很多银行理财能够达到），完全没有必要提前还按揭贷款。因为一旦你提前还款，不仅生活中可支配资金减少，还损失了超过 4.6% 这部分的收益。
信用卡的作用
有人视信用卡为额外消费的罪恶之源，有人嫌信用卡还款麻烦有风险——逾期产生信用问题，有人惯用信用卡薅各种羊毛，而我把信用卡看成收支调节的一种工具。这样我不必带太多现金在身上，或者留在储蓄卡里，可以放心地把它们放到货币基金或理财里产生收益。至于羊毛，信息零碎又不集中，薅不薅得到就随缘了。
6年以后的变化
我都忘记曾写过这样一篇文章《Google总让我惊喜》，居然被网友翻出来评论了一把。Google Reader 要关闭这件事，的确让人伤心，因为：
From your 189 subscriptions, over the last 30 days you read 258 items, clicked 7 items, starred 13 items, and emailed 0 items.
Since October 30, 2006 you have read a total of 62,661 items.
其实这心，在 Google Reader 中的 Share 按钮被改成 +1 以后，已经伤了一次了。在我这样一个中国用户眼里，Google Reader 曾是 Google 最好的 SNS 产品，就是因为 Note 和 Share。
不太能理解 Google 放弃 Reader 的决策。基于自己的很多优秀产品（Gmail, Reader, Android, Google+），Google 吸引了很多忠实的注册用户，这一点被其它很多公司羡慕——包括百度，除了腾讯。产品推广的时候，吸引用户注册使用往往是一件很困难的事情，这时就能凸显出用户基数大的好处了。好产品越多，用户的忠诚度肯定越高。如果只有单一的产品，产品没落后用户就会轻易地流失，从这个角度看，我觉得保留 Google Reader 看起来不是一件坏事。
无论如何，Google Reader 是快没了，总要寻找其它的替代品。从目前我的探索来看，Feedly 像是一个比较好的选择，但它的连接不是 https 的，可能会被关键词过滤（或者直接被封掉）。鲜果阅读器看起来也还可以，起码比 QQ 阅读看着更像 Google Reader。豆瓣 9 点就不说了，同步的速度是个渣，也没用心做。
北京生活 TIPS - 银行服务篇
以前想过写这个，但总觉得似乎庸俗了点儿。可是好多次同事谈起这些个话题，发现大家对一些生活门道近乎毫无了解，那我想给这些刚刚开始帝都生活的朋友们分享我的一些生活经验应该是有价值的。
因为本人财力有限，下文列出的所有银行卡均为门槛在 5 万以内卡片，办卡要求 5 万以上资产的，不在本文覆盖范围内。且本人以满足个人当前需求出发，并未尝试体验所有银行服务，所以以下为不完全统计。
1. 关于免费跨行、异地转账
如果不考虑通货膨胀的话，大部分情况下都是我们薅银行的利息。大多数人被银行薅，往往发生在异地、跨行转账时。水木钱包版的前辈探索过不少免费转账的方式，我这里不一一列出，感兴趣的可以去水木看置顶或提问。
目前大部分跨行、异地转帐免费的途径均受益于央行搞的超级网银通道，有每笔不超过 5 万的限制。但是大部分银行还保留着原来的转帐通道，而且对超银通道的叫法不同，例如民生把超银通道叫做“跨行账户管理-本行转它行”，北京银行把超银通道叫做“快速转帐”。所以如果你看到下面提到某银行转帐免费，而实践的时候没有仔细去选择超银的免费通道而被收费的话，那只能怪自己不细心。
- 招商银行金普卡：手机银行跨行、异地转账免手续费，网银、ATM 收费；
- 民生银行普卡：手机银行、网银（需U盾）跨行、异地转帐免手续费，ATM 收费；
- 华夏银行普卡：网银（需U盾）跨行、异地转帐免手续费；
- 中信银行普卡：网银（需U盾）跨行、异地转帐免手续费；
- 交通银行普卡：手机银行跨行、异地转帐免手续费；
- 北京银行普卡：网银（动态口令）跨行、异地转帐免手续费；
- 深发展（平安）银行金卡：网银、ATM 跨行、异地转帐每月免前 20 笔，非超银通道；
2. 关于免费跨行、异地 ATM 取款
虽然跨行、异地 ATM 取款大家很少用，但我想并不是大家不愿意用。相信大家都经历过这样的事情：
- 需要钱时满大街地寻找银行卡对应的 ATM 机，为了省两块钱走很远的路；
- 开学、回家或出去旅游的时候带上很多现金，为了节省几十块钱的异地取款费；
- 取钱时在某银行 ATM 机前排队，尽管旁边的 ATM 机一个人也没有。
那么，看完这篇文章，希望你知道该怎么做了。如果说跨行、异地转帐功能很多股份制银行还不分伯仲的话，跨行异地取款功能基本上就可以淘汰大部分银行了。
- 华夏银行普卡：跨行、异地 ATM 取款（全球范围、要求银联合作）每天第一笔免手续费；
- 深发展（平安）银行金卡：跨行、异地 ATM 取款（全国）每月前 20 笔免手续费；
- 广发银行信用卡：跨行、异地 ATM 取溢缴款免手续费；（关键词：信用卡、溢缴款）
剩下的银行跨行、异地 ATM 取款要么不免费，要么免前 3 笔，且大部分只支持本地跨行，不支持异地本行或异地跨行免费，完全不具有可比性，就不提了。
3. 关于免年费和小额账户管理费
很多人没有注意过储蓄卡的年费和小额账户管理费。这个钱并不多，比如像工行普卡是年费 10 元，季度日均存款小于 300 元，季度末收 3 元小额账户管理费。但蚊子腿再细也是肉，如果能不被薅，自然是最好。
- 招商银行金普卡：代发工资卡免年费和小额账户管理费；否则免年费，小额账户管理费普卡小于月均 1 万收 1 元，金卡小于月均 5 万收 10 元；
- 深发展金卡：每季度要求连续一个月月均 5 万，免小额账户管理费；
- 民生银行普卡：免年费和小额账户管理费；
- 华夏银行普卡：免年费和小额账户管理费；
- 中信银行普卡：免年费和小额账户管理费；
- 建设银行普卡：开通基金直销账户，免年费和小额账户管理费；
4. 关于免费送网银安全工具
大部分人把它叫做 U 盾、U key，总之说的就是这类东西。安全工具大部分只是在推广期免费，目前北京免费送安全工具的银行有：工商银行、建设银行、招商银行、华夏银行、民生银行（开三方存管、资金归集）、广发银行。
5. 关于免费超级网银、资金归集
看到这里，我想大家对股份制小银行比传统大行的优惠有了更深刻的认识。但很多人不愿意成为这些银行客户的原因，竟然是“网点太少，存钱麻烦”！
这时候不得不介绍一下超级网银了，科普大家可以看链接。但它之所以被俗称为“超级网银”，就是可以用一家银行的网银，管理多个银行卡，使资金在各个银行卡之间（自动）流转，这也就不存在“网点太少，存钱麻烦”的问题了。
大部分超级网银关联的要求是：关联两家银行卡时，必须有两家银行的网银安全工具（U 盾或 key）。一旦完成了查询和转帐的关联，你就可以随意调动多个银行卡资金了，而且还可以使用资金归集功能自动扣款。超级网银操作只向一方收费，所以只要你有一方支持免费超级网银，所有操作就都是免费的。
- 招商银行普卡：资金归集（即扣款）免费，对外转帐收费（可以用手机银行免费绕过）；
- 民生银行普卡：所有超银功能都免费；
- 华夏银行普卡：所有超银功能都免费；
- 中信银行普卡：所有超银功能都免费；
6. 特色银行服务
北京中信银行有一项特色服务值得一提，即可以通过网银（需U盾）免费查询个人信用报告。由于人民银行对安全的考虑，个人信用报告查询只能自己到月坛南街的营业部线下查询，目前在线查询功能独有中信一家提供。
7. 总结
总结一下，不考虑银行理财、信用卡、网银易用性等因素，仅从上文列出的免费服务出发，个人认为最值得拥有的储蓄卡是：
- 华夏银行普卡：送U盾，超银扣款、转出免费（含跨行异地），全球取款手续费每天免 1 笔，无年费和小额账户管理费；
- 深发展金卡：无超银，但跨行、异地 ATM 取款每月免前 20 笔（比每天 1 笔更实用）、跨行、异地转帐也免前 20 笔（不受超银 5 万限制）；
考虑到网银易用性，第三方支付工具接受程度，民生银行的普卡也是一个好选择，只是在跨行、异地取款上较逊色于华夏。
北京生活 TIPS - 医疗服务篇
以前想过写这个，但总觉得似乎庸俗了点儿。可是好多次同事谈起这些个话题，发现大家对一些生活门道近乎毫无了解，那我想给这些刚刚开始帝都生活的朋友们分享我的一些生活经验应该是有价值的。
1. 关于医保存折
对于在北京为员工缴纳正规五险一金的公司来说，社保中医疗保险部分个人缴纳2%，公司缴纳10%。其中对于 35 岁以下职工，划拨 2.8% 到医保个人账户，即北京银行医保存折。医保个人账户是让职工用于日常门诊、买药使用，即覆盖社保卡门诊报销起付线 1800 元以下部分的医疗开支。部分省市个人账户是绑定在社保卡上的，持社保卡就医直接扣减，不可取现（这也是有些地方药房几乎和超市一样的原因）。北京市的个人账户是存折形式，可以直接取现。
那医保存折里面最多会有多少钱呢？以 2012 年为例，2011 年北京市平均工资为 4672 元，那么 2012 年社保缴存上限是 4672x300% = 14016元，医保个人账户的上限是 14016x2.8% = 392.45元。这也就是说在 2012 年你的医保存折中最高每个月可以收入 392.45元，一年最多 4709.4元。
医保存折可以怎么取现呢？很多人只知道可以到北京银行柜台取现，但那个排队时间太长了。部分北京银行网点有医保存折 ATM 机，可以直接用医保存折机器取款，但只能取到百元整数。很少人知道，医保存折可以直接在“北京农商银行”柜台取款，甚至可以在农商银行换折，这个小银行排队的人非常少；更少人知道，可以在北京银行建国支行（北京站）、九龙山支行办理医保存折关联北京银行储蓄卡，然后可以通过北京银行“动态密码版网银”“快速转帐”到他行，零手续费。
2. 关于定点医院
持北京社保卡就医，必须在 4 家定点医院、19 家 A 类医院或者专科医院才能够报销。但很多人不知道定点医院是可以改的，因为居住地与公司定下的初始定点医院较远，所以总是去那 19 家 A 类医院就医。由于 A 类医院全都是三甲医院，就医的质量保证了，但是就医过程非常痛苦。
A类医院有限，离家的路程会比较远，拖着病体跑那么远也是受罪；而且其医疗资源比较稀缺，所以各地来看病的人非常多，挂号排队是一件痛苦的事情，对于特殊的科室来说，比如牙科之类，等待时间会更长；可能三甲医院的医生有创收压力，头疼感冒的小病开的药往往也非常贵，最贵的是一些中成药，还有挂针的服务费、材料费。所以小毛病去三甲医院看病拿药完全是找虐，不如去社区的二甲或者卫生所。
北京规定社保卡指定的 4 家定点医院其中至少有 1 个二级，至少有 1 个三级或以下。所以一般可以这样分配，选择离家近的一个卫生所和一个二甲医院，选择离家近，或者在某些科上比较先进的两家三甲医院（A 类必是三甲；三甲未必属于 A 类）。所有的定点医院名录和编码可以在北京市人力资源和社会保障局网站上查询，然后将 4 家医院的名称和编码提供给公司的 HR。有的公司是 HR 负责后续变更事宜的办理；如果想快的话，可以用 HR 提供的加盖公章的申请表、U盘拷贝变更内容文件，直接到社保中心办理，当天生效。以前是理论上每年只允许变更一次定点医院，今年年中时有个新闻说不再有此类限制，不知道是不是落实下来了。
3. 关于急诊
有时候为了救命，急诊时只能选择就近的医院。按北京规定急诊可以选择就近的二级以上医院，属于医保范围。但是急诊住院只有前 7 天费用可报销，如果为了省钱，可能就得忍受转院的痛苦。其实从操作上，由于社保中心修改定点医疗机构是即时生效的，所以完全可以在 7 天内将定点医院改为急诊所在医院（除非悲催地在某个 25 日左右出事，因为每月 25 日以后社保中心不办公），就可以避免转院了——这可能需要公司 HR 的理解和支持。
溜走的2012年
隔壁传来小孩儿的夜啼，身边躺着熟睡的妻子，偶尔会踢蹬我两下。这是我今年焦躁不安夜晚的其中一个，只是有个外国名字叫做 Christmas Eve 让它显得略有些特殊。今天晚上我错过了食堂的晚饭，又是在陶然亭地铁口的沙县小吃对付了一顿。茶树菇排骨馄饨和蒸蛋，味道还不错！
这是个寒冷的冬天，也是我穿得最少的一个冬天。其实我还想穿得再少点儿，可惜我没有车，还要上班，再穿少可能就有机会坐救护车了。前天在灵山上可真的冻死了两个人。
上下班单程，我得花一个半小时，实际上这大概是个期望值。本来我还想装逼地用泊松到达来准确分析一下时间的分布，后来想想，三段路呢，别找不自在了。再说，我统计学得又不好。
自从搬到现在的办公楼，我就不怎么开心。就像正住着五星级忽然被撵到偏远的快捷酒店一样，关键是还不给退钱。天杀的，刚开始让我住地下室多好！
年初换了个完全不同的工作方向，业务的比重大一些，技术的比重小一些。喜欢谈不上，不喜欢也谈不上，事实上我也没有能谈喜不喜欢的资本。只感慨一点，评绩效时要讲业务，评职称时要讲技术，难道这就是苦逼互联网码农的宿命？在大公司里做事，有太多的无可奈何。在没能力改变的时候，只能顺势而为；无法追求做得更好时，追求做得别那么糟也不会是件坏事。
各种躁我都有一些，焦躁、烦躁、浮躁 。跟那些老成持重的教导不同，我认为这是一种自然现象，年轻时不躁恐怕就老了。但这并不能缓解想到这些躁带来的躁，一点儿也不。我尝试用各种方式来转移注意力，吉他、篆刻、手工、读书、摄影、焊电路。结果表明，哦，慢着，没有结果。对于意志力不坚定的家伙来说，这几乎是必然结果。
所以这一年伴随我的，有不少是沮丧和对自己的失望。
哦，还是有一些喜事儿，我结婚了，相信明眼人从第一段就看出来了。我“悄悄地”在老家办了个婚礼，除了对自己的喜宴饭菜很失望外，这个老式的婚礼没给我带来太多烦恼。除了老家的朋友外，我一个同学也没通知。我知道他们也不太可能来，但更重要的原因是我也很少参加同学的婚礼。理由很简单，我不愿意吃亏也不想占便宜，而记礼金实在是太累。
这一年里我们这个小家庭最显著的成就，可能就是倾尽两人的所有积蓄，在帝都西南五环外买了个小房子。我跟朋友借了些钱付首付，但没有啃老——实际上父母们也没钱给我们啃。虽然这是个还没盖好的期房，虽然它离我的公司有四十多公里，虽然它在一个我之前都没印象的房山区，但毕竟是个房子。首付有限，没有什么更好的选择。在楼市一波又一波的涨潮冲击下，这个两年后才能到手的房子让我们心中略微能安稳一些。
这个2012年，我过得可以说漫无目的，也可以说目的很单纯——就是赚钱（结婚、买房、还钱）。但是心中的道德律总是让我在痛苦地挣扎，我必须得提炼点儿什么，明确点儿什么，才能对得起这一年年虚度的光阴。这，也许就是我将要做的事。
那些害人的编码“神谕”
同其它领域一样，计算机科学和工程领域也是群星璀璨，有些耀眼的星光甚至刺得我们无法直视，只能匍匐在地上聆听神谕。也正如其它领域一样，虽然大家听到的是同样的话，却有各式各样不同的理解。我这里想讲的，就是我观察到的不同理解引发的现象。
“过早优化是万恶之源。” 这是 Donald Knuth 的一句名言。虽然大部分人都不知道，或者会忘掉前面半句：“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” Knuth 说出这句话时，可能想不到这句话会多么地流行，多么根植在很多人心中，以至于成为程序员偷懒的借口，阻碍进步的动力。因为有了这句话，在你指出别人代码中可以优化的问题时，还必须浪费口舌来解释这样的优化是必要的，不是过早优化或者过度优化。
就我的观察而言，对很多程序员来说，其能力还远远达不到过早优化的地步。但他感觉自己受到了 Knuth 的神启，仿佛具有了某种魔力，不优化代码反而成了一种优越感！关于大多数人是否具备过早优化代码的能力，我可以举几个至今我还觉得神奇的例子。
我供职的公司内部有这样一个模块，隔一两个星期总会挂掉几台服务器，现象是内存占满导致服务器假死或者宕机，但事实上根据请求推算根本不会同时使用那么多内存。最后的排查结果发现，每个线程都有这样一个数据结构，它的内存是只增不减的。当你调用它的 clear 接口，它只会把所有的内存还回自己的内存池里，而不是还给系统。这就导致可供分配的内存越来越少、越来越少...
还是这个模块里，仅仅加载一个几 K 的配置文件，就能够占用超过 1G 的内存。为什么呢？因为它用 char str[MAX_CONF_LEN] 保存配置字符串，用 struct xx_t xx[MAX_XX_NUM] 读取配置，而且这个 struct 中还有嵌套的 struct yy_t y[MAX_YY_NUM] 数组。
该模块是个个例吗？还是这家公司，一个全公司使用的公共日志库，LOGGING 宏定义中直接传一个需要系统调用的函数作为参数，导致无论关不关该级别日志都要进行一次系统调用。
这家公司好歹也位列国内顶尖的互联网公司之一，工程师的招聘要求也是极其高的，还会普遍出现这种肆意浪费资源的情况。那么我想对于大部分工程师来说，谈避免“过早优化”、“过度优化”，还为时尚早。
还有一句名言“好代码本身就是最好的文档。当你需要添加一个注释时，你应该考虑如何修改代码才能不需要注释。” 这是 Steve McConnell 说的。同样，大部分人都不知道，或者忘掉后面半句：Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?" Improve the code and then document it to make it even clearer. 如果你是程序员，回想一下多少次跟别人讨论代码是不是必须要注释时，这句话被引用到；有很多次在写代码时喜爱这句话，又多少次改别人的代码时痛恨这句话。
还是从我个人的观察来看，对很多程序员来说，其编码能力还不足以达到“代码本身就是最好的文档”的地步，包括我自己。敝司招聘过很多顶尖的工程师，有传说中的各种杰出前辈，可能在各种学校、公司内部事迹广为流传。但若是你哪天继承了他的代码遗产，就会发现很多传说中的明星跌落凡尘。成百上千行没有注释，使用一个公共库函数时要么接口就根本没注释只能基本靠猜，要么即使注释也语焉不详让你踩到未注明的大坑。每到这个时候你心里总会暗暗骂娘，后面别人再谈到他的光辉事迹时，你跟随讪笑时心中暗自腹诽：“牛逼个锤子！”
但我想很多人争论的焦点是：“注释是不是不可省略的、要强制执行的？”即使个别人能力真能达到“代码本身就是最好的文档”的地步（我还没见过），我也不建议在团队中传播“注释可以省略”这一想法。因为如果你说“注释可以省略”，可能你会发现大家都理解和实践成“终于可以不写注释了”。如果一个刚刚大学毕业、脑袋里从来没有过 documentation 概念、从来没写过注释的新人进入公司，就“终于可以不写注释了”，那么我想他的代码会很难达到“代码本身就是最好的文档”这个级别。因为他根本没有机会懂得什么叫做 documentation。
在公司里，代码注释深远地影响着团队合作的每个人，以及软件生存期里所有的维护者，甚至会影响自己的职业声誉。所以无论别人怎么想，我对注释这个问题的答案始终是：“注释是不可省略的，越完善越好的，甚至强制执行矫枉过正也没关系的！”
一种抵御 DDoS 攻击的 IP 追踪技术
在拾掇家务时，发现一页我在 2008 年 10 月做的备忘录，记录了一个可用于抵御 DDoS 攻击的 IP 追踪技术。当时因为觉得 idea 太小，不值当写成文章投出去。纸张放那里总是占地方，在博客里电子化一下，然后就能销毁了。
Differential Deterministic Packet Marking
这个 idea 是在 IP 协议的基础上做一些扩展，可以帮助用户在 DDoS 攻击时识别攻击数据包和定位攻击者。在理解这个 idea 之前，可能需要先看几篇参考文献：
[1] Z. Gao and N. Ansari, "Tracing cyber attacks from the practical perspective, " IEEE Communications Magazine, vol. 43, no. 5, pp. 123-131, 2005.
[2] A. Belenky and N. Ansari, "On deterministic packet marking, " Computer Networks, vol. 51, no. 10, pp. 2677–2700, 2007.
[3] Y. Xiang, W, Zhou, and M. Guo, "Flexible deterministic packet marking: an iP traceback system to find the real source of attacks, " IEEE Transactions on Parallel and Distributed Systems, vol. 20, no. 4, pp. 567-580, 2009.
这个 idea 主要是在 [3] 基础上做的改进，其 motivation 是仅仅使用标记段 [3] 内容太保守，用标记段再结合 IP 头中已有的信息，可以做得更好。简单来说就是运营商的接入路由器在 IP 头中增加一些标记，服务器在遭遇到 DDoS 攻击时，可以根据接入路由器增加的标记再结合 IP 头中已有的信息，识别攻击流量，以及确认攻击源。
下文的内容基于三个假设：
- Source IP 和 ingress router 的接入 interface 的 IP 经常在同一个网段中；
- 大部分网络流是正常的网络流而非 DDoS 的网络流。
- ingress router 在可控域中，未被入侵。
由假设有大部分数据包的 source IP 与 router interface IP 在同一个网段中，这样 ingress router 只需在标记段中标记与 source IP 不同的位即可进行追踪。
入口路由器上执行的标记算法是：
Algorithm：（ 16-bit Mark case, RI for Router Interface)
if (SourceAddr RIAddr ) ⊕ & 0xffff8000 = 0 // Case 1
Mark := SourceAddr ⊕ RIAddr // 1 packet
else if (SourceAddr ⊕ RIAddr ) & 0xff000000 = 0 // Case 2
Digest := hash(RIAddr)
for i=0 to 2 // 3 packets
Mark[i].M := 1
Mark[i].A := 0
Mark[i].seg := i
Mark[i].digest := Digest
Mark[i].address_diff := ((SourceAddr ⊕ RIAddr) >> (i*8)) & 0xff
else // Case 3
Digest := hash(RIAddr)
for i=0 to 3 // 4 packets
Mark[i].M := 1
Mark[i].A := 1
Mark[i].seg := i
Mark[i].digest := Digest
Mark[i].address_diff := ( RIAddr >> (i*8)) & 0xff
我提出的新 idea 对 [3] 的改进能够带来以下几个好处：
- 大部分数据包仅靠 1 个包就可以 traceback。根据上面的假设，正常的数据包应该仅仅在 IP 地址的低位与路由器接口 IP 不同，这样仅仅需要在 mark 中的低 15 位与源 IP 异或就能得到路由器接口 IP（case 1）。
- 加快路由器对正常数据包的处理速度。由于正常的数据包仅需要 1 个包就能 traceback，不需要计算地址的 hash 值，大大加快了路由器对正常数据包，也是大部分数据包的处理速度。
- 不影响正常 IP 数据包的 fragment 策略。由于大部分正常的数据包仅仅需要一个包就能 traceback，那么修改 IDENTIFICATION 域对这些数据包的 fragment 策略毫无影响。对于非正常的数据包，本算法需要多个包才能 traceback，所以对其 fragment 策略会有影响，但由于它是非正常的数据包，不用考虑后果。
之所以觉得这个 idea 小，有两个原因：
- 第一是在别人方案基础上做的改进，创新不够；
- 第二是需要部署到全网（至少某个运营商内部）所有接入路由器上，（尤其在 IPv6 已增强安全性的前提下）不太可能实现。
这也符合我对很多研究的看法，虽然有意义，但在工程上基本价值不大，基本上就自己 YY 一下。