日本自由行流水帐（2）交通

自由行，其实也就是自己搞定食住行，而其中最麻烦的也就是交通了。不过在城市里旅行，特别是轨道交通发达的地方，比如日本，只要实现查好路线，随身携带详细的地图和交通资料，出行还是十分方便的。
不过在谈交通前还是有必要谈谈住宿，住宿地点对每日出游的交通影响还是非常大的。之前参考的几乎所有旅游攻略上都告诉初次来访的游客，最好住在山手线沿线。山手线是东京市区的一条环线，范围大致相当于上海的4号线，山手线只长不到一公里。由于是环线，所以换乘其他线路比较方便，而东京的几个主要换乘大站和主要商业区山手线都有经过（接下来细讲）。不管是从机场出入东京还是新干线和普通列车，最多只需要一次站内换乘就可以到达山手线沿线各站。推荐的住宿地方有：新宿、池袋、上野、品川、涩谷、日暮里等。另外机场铁路可以直达新宿、池袋、品川、上野和日暮里。我们住的新宿，离车站大概5分钟的路程可以坐到附近的3条地铁以及JR站。
东京是全球轨道交通最发达的城市之一（没去过纽约和伦敦），交通系统由JR东日本、地铁（营团和都营）和几家私人铁路公司（京王、京成、小田急、东急、西武、东武等）共同运营，在东京都范围内基本没有电车地铁到不了的地方（即便有也是游客不会去的地方）。我们在日本的5天4夜里就没有坐过任何汽车，全在轨道上搞定交通。对于游客来说，线路固定、标示清楚、班次有保证的电车自然是第一首选。公交车要找站头，上车了还要担心坐过站，有的时候害怕司机不停，这些问题对于电车都基本不存在。当然，巴士和出租车贵得吓死人也是另外一方面的原因。
电车路线总览图在网上没找到特别全的版本（网上地图如google map和yahoo map除外），有一个Suica手册里的图片比较全（不过是E文的，E文虽然能看懂内容，但地名还不如日文汉字好记实用），链接在此：Click here for the map of Tokyo metropolitan area [PDF/205KB]。在线地图的话除了google外，yahoo也有非常翔实的资料，还可以选择按照路途时间和费用排序结果。
如果住在上面推荐的几个山手线沿线地方，那到东京各处都十分方便。几乎各条地铁、国铁和私铁线路都和山手线有方便的换乘。如果换乘涉及到不同的公司，则需要出站换乘（改札），这点和国内不太一样（国内一个城市的地铁一般只有一个运营公司，换乘站内为主，偶尔出站）
最后简单介绍几条线路：
山手线：JR系，东京市区环形运行，类似上海4号线和北京2号线，串起了东京大量的主要车站、景点，自由行必乘（应该也是乘坐最多的）。一圈一个小时左右，每站都停。重点车站有东京（火车站）、新宿、品川、上野、池袋、涩谷。车厢较新，每个车门上有电子显示屏报站。

山手线
山手线-新宿站

 
山手线车厢内
山手线车厢内

中央-总武线：JR，横贯东京市区的东西向铁路。途径新宿、东京、饭田桥。这次出行没坐过。有急行和每站都停的车，月台可能不同，换乘时注意。
千代田线：营团系，东北-西南走向地铁，经皇宫、表参道、明治神宫，并与小田急铁路有互通的列车；
京叶线：JR系，东京站附近出发，通往迪斯尼
丸 之内线：营团系，C字形路线，从市区西部经银座东京后折向西北，经新宿、银座、东京站、皇宫
大江户线：都营系，环形运营，和JR山手线有交叉，经新宿、东京塔、饭田桥
大江户线
大江户线

银座线：营团系，东北-西南向地铁，修建较早，经浅草、银座、表参道、涩谷
银座线浅草站
银座线浅草站

银座线某站
银座线某站

Xcode中调整控件叠放顺序

Nib可视化编辑器的调整很简单，不需要去点控件然后调整属性（属性里也没有index），只要在左边的Object列表里调整即可，需要浮在上面的控件往下拖即可。
另外一个方法是针对代码手工添加view的，上接口即可：
insertSubview:atIndex: See Also
– addSubview: – insertSubview:aboveSubview:
– insertSubview:belowSubview:
– exchangeSubviewAtIndex:withSubviewAtIndex:

LLVM折腾记（2）

今天主要折腾建立新的编译环境把Release版本的LLVM给编起来，主要是体力活。另外就是学到了一个可以link目录的好办法——mount -bind，这样可以节省很多空间。毕竟我只是想替换一个so文件(libstdc++.so.3.0.6).
新编译环境建好以后很快把Release版本的clang/llvm弄出来了。实验了一次编一个component的代码，效果很不错。GCC需要46秒完成的编译用llvm只需要35秒左右就可以完成，提高了将近四分之一。而在代码大小方面，具体数字不太记得了，不过缩小了估计也有三分之一，很惊人。之后的链接也没出现问题。不过忘记加载image看看这样的代码是否工作了。
下一天的主要工作就是用llvm编译全体代码，找看看有哪些不兼容的地方，顺便做个编译时间和代码体积的测评。

LLVM折腾记（1）

这两天前看了一些关于LLVM的资料，比如《程序员》上的文章和Dr. Dobbs上的 The Design of LLVM。之前还听说LLVM编译速度快、生成代码体积小效率高、架构优秀，连GCC都赶不上了，于是就开始琢磨着折腾折腾。
首先是下载编译最新的LLVM。我们的编译环境比较老，比如libstdc++的版本差了一点，最新的LLVM（包括3.1和3.0）都编译不起来（除了Debug+Assert版本，没想明白）。由于编译环境是公共的，自己fork一份出来太费劲，于是就将就用Debug版本编一个文件试试。
接下来是一般折腾找makefile里改编译器的地方，在一个已经用编译好的代码环境下通过touch一个源文件来一次只编一个，省的一下子把所有代码塞给clang/llvm遇上问题太多搞不定。预料上的问题很快就碰上了：代码里用了GCC的方言或者不符合标准的地方。clang（LLVM的C/C++/Objective-C前端）的主页上给出了目前不兼容GCC的列表：http://clang.llvm.org/compatibility.htm，大部分兼容性问题应该可以在这里找到答案。
第一个碰上的问题是关于模板类继承的：
http://clang.llvm.org/compatibility.html#dep_lookup_bases
改了点代码就编译通过了，算是完成了第一步。不过显然不能一直用Debug版本的下去，速度只有GCC的一半多一些，丧失了LLVM的一大优势。明天的任务就是fork出新的能够运行Release版本的编译环境。

日本自由行流水账（1）出游准备

这个月初，土鳖们终于盼到了第一次出国旅游的机会（也是第一次出国），目的地——日本。
准备工作大概在春节后就开始了，之前曾经有过通过途牛成行香港自助游的经历，这次也打算在网上完成。鉴于上次错过了携程上建行信用卡每单立减800的薅羊毛机会，这次就直奔携程而去了。
果不其然，携程的日本自助游也有同样的优惠，这次更给力是JCB信用卡每人最高减950。虽然手上没有JCB卡不过马上可以办一个。携程还有两个优势：酒店选择范围比较大；保证金只需要国内关系人出具担保证明而不需要交出真金白银（让人感觉很不好）。日本自由行的签证政策是需要通过旅行社办理，并且要出具酒店和机票的预定证明，好像并不受理个人（中国公民）的办理。
最后我们选择了一个五日四晚的套餐，日航早去晚回，住新宿经济型酒店。从事后来看这些选择基本都做对了。时间上是周一出发周五回来，虽然看上去是工作日，可是由于变态的清明假期安排，实际上只花了两天的假期，回来以后还可以休整两天。
日本的签证要求的材料（或者说是携程要求的）说多不多，主要就是收入证明材料和担保材料。收入证明要求年收入10万RMB以上，由公司出具或者银行盖章的流水单。如果收入够的话建议后者，我的是招行卡排个队瞬间搞定，而公司证明需要公章加上财务章，如果是大公司的话想敲这两个可能会有些麻烦。担保证明就是在国内找个人，肯赌10万担保你不非法滞留或者不去靖国神社喷红油漆的。材料交上去以后大概2-3个星期出结果，可以在网上查到。然后你可以打电话让携程把材料快递回来给你。
手续就这么多，剩下就是兑换一下日元了。出行前缴纳的费用，包括机票、4晚住宿和300块的签证费总共是3788一个人（扣去了950的优惠额），应该是赶上了赴日旅游的低谷期了。
p.s. 日本的电源插座基本都是两个口平脚的，兼容国内大部分两脚插头。另外酒店如果有网络的话记得带一个迷你无线路由，不然一身的WIFI设备对着RJ45网口也只能干瞪眼。

构建失败

Joel著名的12条测试里有两条与构建相关：

  • Can you make a build in one step?
  • Do you make daily builds?

这两条相信大部分有些规模的公司都能够做到。不过，有每日构建，就必然伴随着构建失败，特别是在多人协作的环境，由于代码依赖、开发人员失误（比如只签入了一部分代码）、代码合并等等原因，连续好几天构建都失败的情况也偶会发生。
失败的代码构建让人万分沮丧，首先打击了士气。没有人打算让伟大的项目在第一步就失败，就像70圈的F1在热身圈就冲出赛道退出比赛一样。另外还造成了大量的浪费，由于构建失败，同一天签入的代码就没法在第一时间得到测试，加大了项目后期测试的压力。而当你下载了最新代码，却发现连编译链接都无法通过，那估计你也没兴趣写代码了。
正如bug不可避免一样，构建失败也是不可避免的（特别是对于像C/C++这种有大量预编译的语言），即使构建成功与否是非常容易验证的，非黑即白。所以构建失败往往也被认为是最愚蠢的错误。不过再愚蠢的错误，也必须正面对待，而不是对犯错的哥们嘲笑或者怒吼了事。
对付一件坏事，基本上两种办法：要么预防发生，要么减小影响。

预防：

1. 降低构建的复杂度：太大的构建模块和构建链/工具链、太长的构建时间、过多的代码依赖、紧缺的构建服务器资源都会让开发人员倾向于减少构建的次数。我也不止一次看到，由于最后只改动了几个字符，开发人员懒得重新构建造成的构建失败。每个人都会偷懒（不是有句话说“偷懒就是美德”？），但如果降低偷懒的动机，偷懒自然会减少。合理的模块划分、分布式版本系统的使用（大大加快checkout时间）、更强的构建机器（CPU、内存，特别是SSD）、高效的构建方法（怎么着也得并行构建）。如果一次构建只需要15分钟而不是3个小时，没有人愿意冒风险悍然签入代码。经常是还有2个小时就下班但构建需要3个小时的情况下。
2. 惩罚：虽然嘲笑或者怒吼解决不了问题，不过一些善意的小惩罚还是可以接受的。微软90年代初的标准是5美元一次，按照收入比换算的话在国内大概20RMB应该还是合理的范围。不过国人似乎不喜欢现金，那么改成请大家吃零食也是个不错的主意。另外一个方法就是把某个恶搞标志放到TA桌子上，直到下一个人破坏了构建才能送出去。

减小影响：

3. 提高构建频率：把每日一次构建改成每日两次构建可以提早一半的时间发现问题。如果把构建频率提高到每天4-6次，并禁止在测试发布版构建和其上一次构建之间的签入任何代码（除非是修复破坏构建的代码），这样就保证至少有4-6小时的时间修复失败构建。（这个时间应该足够修复所有构建相关问题）。当然如果需要构建的版本特别多（特别是多平台发布和多分支维护的情况下），在可利用的资源条件下无法做到这个标准，可以采取差异化方案。主要工作版本和发布平台（即签入最频繁的构建）增加构建频率，几天才有一次代码签入的分支可以只做每日构建。这样就可以确保最值得关注的地方得到最多的资源。
4. 签入队列：签入的代码不马上进入开发的主分支，而是进入一个签入队列。每天签入队列里的改动要通过构建后才能进入主分支，如果当中有破坏构建的签入，则当天的所有签入都会被hold住直到问题解决。这样的代价是复杂性增加了，另外每日测试和最新的代码会有一天的延迟，不利于问题的及早发现（不过问题仍然可以追溯到某天签入代码的范围里）。
5. 专人负责：代码能否构建是软件的第一要素，这么重要的东西当然值得指派专人（或者是一个委员会）来负责。国际化团队需要在每个点（或者相近的时区）配备负责人，确保破坏构建的签入能够早几个小时被定位，甚至代替责任者修复一些愚蠢的问题。每当构建失败发生，委员会成员都会收到通知邮件，这时候他（们）应该停止手上的所有工作来解决这个问题，并在第一时间找到责任人通知其修复。如果暂时没法找到，也可以通知其peer或者在找到一两个相关reviewer的情况下自行修复。（建议与第6、8条配合使用就不会找不到责任者）
6. 自动构建：如果每次代码的签入都能够伴随一次完整的自动化构建，构建期间锁住代码库，并在确认构建结果后才允许正式签入，这样我们基本就不会碰到构建失败。这种方法其实是提高构建频度的极致。当然对于大型开发团队来说这并不现实，也可以做一些妥协，比如自动构建期间放弃代码库的锁定。毕竟由于多人同时签入代码导致的失败构建，所有人都可以理解的，而这种情况也相对较少。
7. 停止生产线：这条是丰田的做法。出现构建失败后停止所有的代码签入（当然修复构建的除外），直到下一次成功构建。期间构建负责人介入并定位问题（或者责任人自己认领）。这样有利于隔离问题，避免连续的构建失败。而夜间测试至少也有一个新的版本可以利用。
8.  签入时间限制：这条是从《微软的秘密》中看到的，所有人在下午2点之后不能签入代码。每天2点开始每日构建，一旦出现什么问题可以有人当场fix而不是将问题拖到第二天而浪费一整晚测试的宝贵时间。但对于国际化开发的团队显然不合适，实际一点的做法是要求所有人必须在下班前3小时之前做好当天的代码签入。另外，国际化开发的团队也总是有每日构建及测试的固定时间，一般会是在岸团队的夜里（想不到onshore的翻译了），可以规定在每日测试使用的版本构建前3小时内不允许的签入，而在这个构建前安排一个小的构建进行验证。总的原则是保证构建能够成功。
9. 签入前的公示：也是从《微软的秘密》里偷来的，特别是对于大规模的签入。公示可以是发邮件，也可以是在某个系统里登记一下。而每个人在签入之前也检查一下邮件或者系统。
小结一下减小影响的办法：及早发现、及早修复、隔离错误、拉长签入流水线。
最后是书托时间。关于软件开发的优秀实践，《微软的秘密》有很多很好的例子，虽然里面的有些相对现在流行的“敏捷开发”有些老土（书里写的基本上是92-95年的微软），但由于这么多年来软件开发的效率没什么本质上的提高，所以这些实践到现在仍然适用。

Smart and Get Things Done

上周在刘未鹏的博文里看到了Joel Spolsky关于招聘和管理的博客文集《Smart and Get Things Done》这本书，在网上辗转找到电子版并这几天在iPad上看完了（羞愧一下没买正版）。Joel的风格还是那么简单直白，切中要点，英文也非常好理解（移民的缘故？）。虽然书是从招聘者和公司老板的角度来谈的，不过里面很多内容还是值得广大IT从业人员一读的（特别是软件开发者）。对于短期内不会有机会参与雇佣的人来讲，也可以通过书中的一些例子来对雇佣的公司进行反向选择（如果你拥有多重选择的话）。
书里给我印象最深有两点：
1. 判断一个人是否聪明，看他能不能很快理解我（面试官）说的意思，而不是我再三解释；
2. 如果你对雇佣一个人犹豫不决，那就说“不”。
另外，他对“Hard-Core”的态度，也让我相信我当初选择从底层做起的决定是正确的。
p.s. 书名“Smart and Get Things Done”是Joel招人的最基本原则，来自于微软。

Blog主机迁移完毕

早上花了点时间把主机从gegehost转移到了homezz。前面一个主机我已经用了2年，是我用的第一个虚拟主机（reseller）。两年期间没碰到什么问题，加上有ssh访问，所以什么问题也自己搞定。新主机价格一样，流量一样，空间少了100M，没有ssh帐号（这点其实对我挺不方便的，不能拿来用sshd和wget了，过两天还得买一个sshd或者vpn的帐号）；好处在于速度快了很多，本来是320+ms的ping现在只有180+ms，另外可以架设自用那个啥的API，还送免费的图床（不过我用picasa）。
另外以前的邻居xyxn，如果你们还能看到这篇blog的话，你们以前的内容我也备份下来了，有兴趣可以找我要备份数据包。
最后，放几个邀请码，如果有兴趣购买homezz的又没没邀请码的可以顺便帮帮忙。
K6HB5FJ3
SR7GOM49
31NERVLH

这两周的运转

简单记录一下流水帐，也没拍照片。
上周二（清明节假期最后一天），从家里出发。第一部车是刚刚延伸过江的874，在伊敏河路上车。在从密云路大转入赤峰路后就和515走同一路线，从延吉路西段一直到最东端。军工路上开得很快，出了隧道就是浦东金桥路，然后就到底站枣庄路张杨路。
之后在云台山路站上了6号线。6号线很长一段是沿着张杨路走的，似乎导致金桥附近张杨路上的公交车不多（当年开通地铁后砍掉了几条线路）。6号线车站是明挖式的，阳光可以直接从上面透下来到达站台，当然悲剧是太短太窄。上车时没注意，坐上了小交路，结果到高青路还要下车等下班车。上南路站下车，这个站倒是很宽敞。要是再过几个星期再坐6号线的话就可以在济阳路站（现在更名东方体育中心站）换8号线了。
上南路华夏路站等576回程，虽然人不多但是一直到南浦大桥附近才有位置坐。576虽然雄风不在，但南浦大桥上还是找到当年飚车的感觉。在南浦大桥上的时候倒想起来在18摸实习期间的生活，天天坐班车从中山公园到张江。
====
今天呢就到宝山去转转。另外还打算去宝山区图书馆看看。家门口116，到江湾就满满一车人，然后在高境庙上的高架。在高架上我觉得开了挺远的才下来，感叹宝山还真是远啊。不过下桥拐入淞宝地区就是一番新的景象——至少不是沿路的工厂郊区样子（逸仙路从场中路向北沿路上都觉得很荒凉，除了地铁站附近还有点人气）。淞宝算是真正的宝山吧，给我的感觉像是南京的大厂地区或者是厦门的海沧同安，不过面积肯定大多了。后来地图上一量，大概有10多平方公里的城区吧，规模相当于地级市市区。还见到了很久没看到的沪C出租车，以前只在张江见过南汇的，现在这个是宝山的。
到了图书馆却发现在修楼闭馆，于是只好继续运转。在永清路上了51路到水产路同济路，然后换宝山1路。水产路出了淞宝就很荒凉，一直到杨行才有点人气。路过顾村外围不过没进去，最后在刘行附近下车（这名字我一开始看上去很眼熟就是想不起来，后来看到一辆教练车就想起来了）。
回程是528，不过我没想到528路线有这么长，分别在沪太路上和汶水路上开了很久，在顾村公园还上了很多回程的游客。有意思的是528有两个共和新路汶水东路站，而且是180度相对的。不知道为什么528不在汶水路地铁站地下直接大转（看到了左转车道和车辆），非要到永和路口调头。下了车屁股都坐疼了，20公里开了一个多小时。