-
骑行大运河森林公园未遂
今天下午骑车往通州去,想看看“大运河森林公园”。沿着京通快速的辅路走,竟然有一段路边还有这么宽阔的水面: 后来看辅路比较堵,我就在沿河的小路骑了一段。这段路是防汛路,车比较少,灰尘也少,不过路况比较差,有点越野的感觉。往前走,这小路和京通辅路交汇。后面在八里桥和北苑地铁站中间发生了悲剧,后胎扎了个铆钉!第二次骑远路就出这种事了。其实之前路上我就想了几次,万一轮胎扎了怎么办。用快没电的手机打开地图,搜到附近有个捷安特店,距离3.3公里。推车步行过去,打电话才知道人家搬了,又步行差不多1公里,到了九棵树地铁站,终于换了个新内胎。问了问,大运河森林公园还有点距离,天色不早了,灰溜溜回家。 这就是罪魁祸首,长度差不多有手机那么宽了,不偏不倚从轮胎正中央扎了进去: 我本以为带着这钉子还骑了几十米,肯定把内胎划得不成样子了。不过换下来之后发现也就一个眼,可以补补,以后出门带个备胎,哈哈: 总起来说京通辅路还是比较好走的,自行车道很宽。偶尔有些车停着,有些车也从自行车道超车,但是情况比市里好多了。比较麻烦的是过五环的那一段,从西向东就绕圈,而且路况复杂,需要小心。从东向西似乎是根本没有正常的自行车道,立交桥下有一条黑咕隆咚的路,几个电三轮车主还在那儿乱停,坐着打牌。再往前,完全没有光让人看路了(汽车是进不来这个路的),只看到前面有亮光,知道方向。冷风吹过来——这是唯一的速度指示,这时就只能放慢速度,希望路上别有坑什么的,希望后面的车不要撞你。很恐怖,所以最好还是从从西向东的那条路逆行回去(路牌是这样指示非机动车的)。我现在也还是稀里糊涂的,有个示意图就好了。
-
骑车从劲松到香山
前阵子买了个入门级的山地车,捷安特欧野2.0,后来就张罗着和公司的同事们出去玩。最初定的是今天骑车去十三陵,查了一下地图,从国贸出发往返要150公里,对不常锻炼身体的我来说,强度太大了。于是后来改成了去香山。 提前几天就开始关注天气,最初的预报是周六日都下雨,当时估计去不了了。周四的时候天气预报突然改成周六日都是好天气,开始让人兴奋了。到了周五,又变成周六日下雨了,我们商定下雨的话就取消。 早上起来不想吃饭,就吃了一个小烧饼,出发了。带的东西有一个卡片相机,骑行手套,一瓶脉动,眼镜布,一件备用T恤。由于没有经验,车子的轮胎气都不够,虽然不会影响车子,但是阻力比较大,骑起来比较费力。 在大望路地铁附近跟两位住东边的同事汇合,然后沿长安街一路向西,杀向XXX广场。两个同事都经常骑车,骑得比较快,我刚开始还觉得可以追赶,用力蹬,消耗了不少体力。到西三环附近跟另一位同事汇合(这位倒是轻松啊),然后往香山走。 等到了香山脚下,腿已经基本没有力气了,稍微有个上坡,换到慢速档也坚持不了多远。最终有个同事沿防火道连骑带推上了山顶,我和另外两个大约只走了三分之一。 等了很久看见那同事下来了,原来他的碟刹因为长时间使用,温度过高,他碰了一下把指头都烫伤了,恐怖。后来用水擦了一下,跟我们一起下山。我的车是V刹,下山之后摸轮圈也发现烫得厉害,如果是从最高处一次骑下来,估计刹车就冒烟了!下山还是很爽的,累了半天,就为了那一会快乐…… 之后骑到了西三环的香格里拉大酒店,附近的新疆餐馆用餐。吃完已经4点半了,我就靠一个烧饼坚持了一天。然后各奔东西。我还是沿长安街回来,一路不时有雨滴落到身上,我下意识地尽力提高速度,还好没有被雨淋。一整天也没心情(也没力气)掏出卡片机拍照。 感觉不锻炼的话,骑平路还可以,稍微有个长一点的上坡,就很消耗体力,更别说香山那样的坡度了。北京的空气是够差的,大部分时间我罩着鼻子,还是吸了一鼻子黑。 下面是今天的路线,除去上山大约往返70公里吧: 查看大图
-
警惕 Chrome 的查看源代码 (View Page Source) 功能
前阵子解决一个问题的时候,差点以为是我们自己在 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.…
-
Nothing to Envy
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…
-
《史蒂夫·乔布斯传》精彩摘录
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, 所以是同等优先级。想想处理器原理,确实是这样,除法的结果不就顺便出来余数了吗。
-
Java SimpleDateFormat 与 locale (以及 Mac OS X 更改语言)
遇到一个非常怪异的问题,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,而我启动…
-
无限递归导致 Segmentation fault
某服务器上一个 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”, 我这次遇到的就是最后一条。
-
wget 自动发送用户名密码
有个 Server 需要 Basic Auth 认证,但是我发现在它自己上面有一个任务会通过 wget 访问一个自己的 URL,调用的过程并没有提供用户名和密码,竟然可以成功访问! 一开始我以为是 Apache 里面配置的访问规则是对本地访问不需要认证,但是并非如此。bash alias? 也不是。加上 –debug 参数调用 wget,发现它确实在访问本机的这个域名时会加上 Authorization 这个 header, 而访问其它域名的时候则不加。 最终通过 strace 发现它会打开 $HOME/.netrc 文件,原来秘密就在里面。中间看了半天 manual,只看到它会读取 /etc/wgetrc, $HOME/.wgetrc, 没注意到还会读这个文件。我不太喜欢这种做法——谈不上安全,又不容易维护。 参考: .netrc wget
-
QQ 输入法的词频
现在 QQ 和搜狗都开始做 Mac 上的输入法。搜狗的问题是没有投入足够的资源在这上面,而它做 Mac 输入法也似乎是无奈之举。当时 QQ 突然发布了 Mac 输入法,搜狗没隔几天也赶紧出来一个,结果 bug 一大堆,至今在软件的功能和稳定性方面,搜狗依旧落后很多。 前些天用了一下搜狗输入法,在 Gmail 里的聊天界面,候选窗口无法正确定位。可能跟我用两个屏幕有关系,不过在 QQ 群里(没错,他们用 QQ 群跟用户交流)报告了之后,有人告诉我用正在测试的 1.5 版本试试。我试了一下,完全不能用,应该是切到搜狗输入法它就 crash 了。 QQ 输入法的功能现在非常稳定了,我没有遇到过任何问题。官方网站的 Mac 页面做得也有模有样(搜狗跟它一比就显得山寨),属性设置里也有丰富的选项可供选择,可是有个很致命的问题,那就是词频。我遇到许多让人觉得不可思议的词频,仅选取一小部分放在这儿 (都是第一页): 难道就是这么烂?