今天下午骑车往通州去，想看看“大运河森林公园”。沿着京通快速的辅路走，竟然有一段路边还有这么宽阔的水面： 后来看辅路比较堵，我就在沿河的小路骑了一段。这段路是防汛路，车比较少，灰尘也少，不过路况比较差，有点越野的感觉。往前走，这小路和京通辅路交汇。后面在八里桥和北苑地铁站中间发生了悲剧，后胎扎了个铆钉！第二次骑远路就出这种事了。其实之前路上我就想了几次，万一轮胎扎了怎么办。用快没电的手机打开地图，搜到附近有个捷安特店，距离3.3公里。推车步行过去，打电话才知道人家搬了，又步行差不多1公里，到了九棵树地铁站，终于换了个新内胎。问了问，大运河森林公园还有点距离，天色不早了，灰溜溜回家。 这就是罪魁祸首，长度差不多有手机那么宽了，不偏不倚从轮胎正中央扎了进去： 我本以为带着这钉子还骑了几十米，肯定把内胎划得不成样子了。不过换下来之后发现也就一个眼，可以补补，以后出门带个备胎，哈哈： 总起来说京通辅路还是比较好走的，自行车道很宽。偶尔有些车停着，有些车也从自行车道超车，但是情况比市里好多了。比较麻烦的是过五环的那一段，从西向东就绕圈，而且路况复杂，需要小心。从东向西似乎是根本没有正常的自行车道，立交桥下有一条黑咕隆咚的路，几个电三轮车主还在那儿乱停，坐着打牌。再往前，完全没有光让人看路了（汽车是进不来这个路的），只看到前面有亮光，知道方向。冷风吹过来——这是唯一的速度指示，这时就只能放慢速度，希望路上别有坑什么的，希望后面的车不要撞你。很恐怖，所以最好还是从从西向东的那条路逆行回去（路牌是这样指示非机动车的）。我现在也还是稀里糊涂的，有个示意图就好了。

前阵子买了个入门级的山地车，捷安特欧野2.0，后来就张罗着和公司的同事们出去玩。最初定的是今天骑车去十三陵，查了一下地图，从国贸出发往返要150公里，对不常锻炼身体的我来说，强度太大了。于是后来改成了去香山。 提前几天就开始关注天气，最初的预报是周六日都下雨，当时估计去不了了。周四的时候天气预报突然改成周六日都是好天气，开始让人兴奋了。到了周五，又变成周六日下雨了，我们商定下雨的话就取消。 早上起来不想吃饭，就吃了一个小烧饼，出发了。带的东西有一个卡片相机，骑行手套，一瓶脉动，眼镜布，一件备用T恤。由于没有经验，车子的轮胎气都不够，虽然不会影响车子，但是阻力比较大，骑起来比较费力。 在大望路地铁附近跟两位住东边的同事汇合，然后沿长安街一路向西，杀向XXX广场。两个同事都经常骑车，骑得比较快，我刚开始还觉得可以追赶，用力蹬，消耗了不少体力。到西三环附近跟另一位同事汇合（这位倒是轻松啊），然后往香山走。 等到了香山脚下，腿已经基本没有力气了，稍微有个上坡，换到慢速档也坚持不了多远。最终有个同事沿防火道连骑带推上了山顶，我和另外两个大约只走了三分之一。 等了很久看见那同事下来了，原来他的碟刹因为长时间使用，温度过高，他碰了一下把指头都烫伤了，恐怖。后来用水擦了一下，跟我们一起下山。我的车是V刹，下山之后摸轮圈也发现烫得厉害，如果是从最高处一次骑下来，估计刹车就冒烟了！下山还是很爽的，累了半天，就为了那一会快乐…… 之后骑到了西三环的香格里拉大酒店，附近的新疆餐馆用餐。吃完已经4点半了，我就靠一个烧饼坚持了一天。然后各奔东西。我还是沿长安街回来，一路不时有雨滴落到身上，我下意识地尽力提高速度，还好没有被雨淋。一整天也没心情（也没力气）掏出卡片机拍照。 感觉不锻炼的话，骑平路还可以，稍微有个长一点的上坡，就很消耗体力，更别说香山那样的坡度了。北京的空气是够差的，大部分时间我罩着鼻子，还是吸了一鼻子黑。 下面是今天的路线，除去上山大约往返70公里吧： 查看大图

前阵子解决一个问题的时候，差点以为是我们自己在 HTML 代码中输出的一段信息有问题，结果发现，Chrome 的 View Source Code 竟然会重新发送一个请求！ 有史以来，所有的浏览器从来没有过这样天才的设计。大家都是老老实实，既然你让我显示源代码，那我就直接给你把正在看的这个页面的源代码显示出来。没有人想过竟然可以重新发起一个请求，去拿“纯洁的”源代码。这是革命性的！Chrome 你做到了！ 早在2008年，就已经有人提出这个 bug – View source forces page reload. 中间有人将之标记过 Fixed，但是世界末日快来了，Chrome 的稳定版本已经飚到18了，市场份额已经远超 Firefox 了，实际上这个 bug 仍然存在。我的天啊，究竟是什么样的设计，导致解决这样一个问题这么难？ 甚至还曾有开发者认为 View Source 就应该是这样的行为 (链接): Yes, when you “view source”, you’re really opening a new tab that opens the page again and displays the source rather than renders the page. Many web pages are dynamic and modify their HTML content (eg. using JavaScript/XMLHttpRequest) so we cannot display the current HTML – this is why a new request is made. ...

Winner of the 2010 BBC Samuel Johnson prize What if the nightmare imagined by George Orwell in 1984 were real? 这本书真是太棒了，我读英文还不是很快，不过书中的真实故事越来越抓住人的心理，前几天晚上都看到很晚才睡。此书中有些许关联的不同人物穿插叙事的方式也没有觉得太乱，比较自然、有条理。与1984的绝望不同，这本书除了让人看到外人很难知道的一些真相，悲哀，但同时也给人一些希望，让人珍惜亲情。此处摘录一些印象深刻的段落(数字是 Kindle 的 location)。 103 没有污染 The night sky in North Korea is a sight to behold. It might be the most brilliant in Northeast Asia, the only place spared the coal dust, Gobi Desert and carbon monoxide choking the rest of the continent. 209 They learned that China’s diluted brand of c0mmun1sm was less successful than that brought by Kim Il-sung and that millions of Chinese were going hungry. ...

37页 它（迷幻药）让我更清楚什么是重要的——创造伟大的发明，而不是赚钱。应该尽我所能，将此生放回历史和人类思想的长河。 168页 “这个道理很简单，团队扩张时，如果吸收了几名二流队员，他们就会招来更多二流队员，很快，你的团队里甚至还会出现三流队员，”他回忆道，“麦金塔的经验告诉我，一流队员只喜欢同一流队员合作，这就意味着你不能容忍二流队员。” 181页 但他对产品的关注又是斯卡利永远达不到的，而且乔布斯会侮辱任何一个算不上一流队员的人，以避免苹果出现太多的笨蛋。 205页 Paul Rand – “我解决你的问题，你付钱给我。我设计出来的东西你用也行，不用也罢，都得付钱给我，但是我不做备选。” 332页 人们总是说他们和别人合不来，他们不喜欢团队合作。但是我发现，一流选手喜欢和一流选手共事，他们只是不喜欢和三流选手在一起罢了。 392页 艺术的作用就是驱赶丑陋。 399页（这是“风水”真正有意义的地方） Steve 坚信，设计对路的建筑物会对文化起到积极的作用。 519页（书末乔布斯的原话太精彩了，大段摘录） 像IBM或微软这样的公司为什么会衰落，我有我自己的见解。这样的公司干得很好，它们进行创新，成为或接近成为某个领域的垄断者，然后产品的质量就变得不那么重要了。这些公司开始重视优秀的销售人员，因为是他们在推动销售、改写了收入数字，而不是产品的工程师和设计师。因此销售人员最后成为公司的经营者。IBM的约翰·埃克斯是聪明、善辩、非常棒的销售人员，但是对产品一无所知。同样的事情也发生在施乐。做销售的人经营公司，做产品的人就不再那么重要，其中很多人就失去了创造的激情。斯卡利加入后，苹果就发生了这样的事情，那是我的失误；鲍尔默接管微软后也是这样。苹果很幸运，能够东山再起，但我认为只要鲍尔默还在掌舵，微软就不会有什么起色。 521页 我的动力是什么？我觉得，大多数创造者都想为我们能够得益于前人取得的成就而表达感激。我并没有发明我用的语言或数学。我的食物基本都不是我自己做的，衣服更是一件都没做过。我所做的每一件事都有赖于我们人类的其他成员，以及他们的贡献和成就。我们很多人都想回馈社会，在历史的长河中再添上一笔。我们只能用这种大多数人都掌握的方式去表达——因为我们不会写鲍勃· 迪伦的歌或汤姆· 斯托帕德(Tom Stoppard)的戏剧。我们试图用我们仅有的天分去表达我们深层的感受，去表达我们对前人所有贡献的感激，去为历史长河加上一点儿什么。那就是推动我的力量。

一段计时的代码，把时间长度用“2小时37分钟28秒”这样的形式输出，但是偶然注意到结果很有问题。盯着代码看了半天，觉得逻辑判断都是正确的，后来用一个数字 debug 才找到真相。 比如 4000 秒，程序先判断如果大于一小时，就输出小时数，然后算余数。就是算余数这一步除了问题，代码写成 secs % 60*60。写代码的人为了清晰，还故意在乘号两边去掉了空格，可是这更加容易地造成了错觉，让人觉得 60*60 是先计算的。可是 “%” 的优先级和乘除是同等的！ 运算符优先级是挺难记的。我觉得，迷惑的时候，加括号就行了，可读性也绝对好。 不过这次通过 Oracle 这个文档我是记住了，”%” 和乘除都是 multiplicative operators, 所以是同等优先级。想想处理器原理，确实是这样，除法的结果不就顺便出来余数了吗。

遇到一个非常怪异的问题，Tomcat 里面有个 servlet 用 SimpleDateFormat 解析日期的，类似这样： DateFormat formatter = new SimpleDateFormat("dd-MMM-yyyy"); formatter.parse("05-Jan-2012") 但是会抛出 ParseException – Unparseable date “05-Jan-2012”. 我仔细看了看，似乎一切都是对的，不应该出错。于是写一个最简单的测试类，main 函数就这么两行，同一台机器上运行完全正常。更纳闷了。 最后在 servlet 代码里打出 formatter.format(new Date()) 的结果，发现是 “29-二月-2012”! 这才想起我最早拿到这台 MacBook Pro 时系统是中文，我改成英文但是登录界面等少数地方还是中文。不知道 Tomcat 是怎么设置的 locale，不过这里有人在 Windows 上遇到同样的问题，可以通过指定 java 参数解决。 但是苹果恰好有一个文档：Mac OS X: How to change the language displayed in the login window！看起来，我在 System Preferences 里修改的只是我当前用户的 locale，而我启动 tomcat 的时候，使用了 sudo——root 的 locale 仍然是中文？ 不管怎么样，既然有了这么专业的文档，照做就是了。不过苹果给的第一种解决办法太让人无语了： Reinstall Mac OS X and select the desired language during installation ...

某服务器上一个 cron job 是 shell 脚本调用 Java 程序，最近老是报 Segmentation fault, 每次看见此信息 /bin/sh: line 1: 4285 Segmentation fault java … 总觉得无处下手，bash 的问题？Java 版本不对？信息量太少了。其实遇到这种事情不能谎，表面上没有信息一定要挖出信息来。今天仔细一看，这个脚本把标准输出重定向到一个日志文件去了，于是去看日志。这个程序的主体是对一个信息列表做循环，恰好在每个循环的关键部分开始前、结束后都会写一条日志。其目的是为了计时，不过正是这两条日志让我很快找到了错误缘由，因为发现日志文件的末尾只有一个开始前的，说面在这个循环的处理过程里面发生了 Segmentation fault. 找出程序的源代码，发现循环里面调用的方法有一个是递归的，情况就开始明朗了，猜测就是递归无法终止导致 stack overflow，segmentation fault. 果然，根据日志里最后一行日志中记录的真实数据，发现这条数据是有问题的，会导致此方法无限递归。 Wikipedia 的 Segmentation fault 词条里有一节是 “Common causes”, 我这次遇到的就是最后一条。

有个 Server 需要 Basic Auth 认证，但是我发现在它自己上面有一个任务会通过 wget 访问一个自己的 URL，调用的过程并没有提供用户名和密码，竟然可以成功访问！ 一开始我以为是 Apache 里面配置的访问规则是对本地访问不需要认证，但是并非如此。bash alias? 也不是。加上 –debug 参数调用 wget，发现它确实在访问本机的这个域名时会加上 Authorization 这个 header, 而访问其它域名的时候则不加。 最终通过 strace 发现它会打开 $HOME/.netrc 文件，原来秘密就在里面。中间看了半天 manual，只看到它会读取 /etc/wgetrc, $HOME/.wgetrc, 没注意到还会读这个文件。我不太喜欢这种做法——谈不上安全，又不容易维护。 参考： .netrc wget

现在 QQ 和搜狗都开始做 Mac 上的输入法。搜狗的问题是没有投入足够的资源在这上面，而它做 Mac 输入法也似乎是无奈之举。当时 QQ 突然发布了 Mac 输入法，搜狗没隔几天也赶紧出来一个，结果 bug 一大堆，至今在软件的功能和稳定性方面，搜狗依旧落后很多。 前些天用了一下搜狗输入法，在 Gmail 里的聊天界面，候选窗口无法正确定位。可能跟我用两个屏幕有关系，不过在 QQ 群里（没错，他们用 QQ 群跟用户交流）报告了之后，有人告诉我用正在测试的 1.5 版本试试。我试了一下，完全不能用，应该是切到搜狗输入法它就 crash 了。 QQ 输入法的功能现在非常稳定了，我没有遇到过任何问题。官方网站的 Mac 页面做得也有模有样（搜狗跟它一比就显得山寨），属性设置里也有丰富的选项可供选择，可是有个很致命的问题，那就是词频。我遇到许多让人觉得不可思议的词频，仅选取一小部分放在这儿 (都是第一页)： 难道就是这么烂？