April 1st, 2009 / 3 Comments » / by SteamedFish
以前从来没有过搞 GitHub 的需求，因为觉得不需要。以前觉得像 Dropbox 这样的服务才是最适合我的。
可是，当我又一次花了 N 个小时配置字体之后，当我终于把我的字体配到完美版我在可预期的时间内都不会再配以后，我终于觉得，搞个 GitHub 太有必要啦。
我的 GitHub 链接在主页有显示。欢迎上去扔砖头。
另外，我发现 GitHub 的个人 wiki 似乎是全局可写的，不知道怎么关掉写权限，那也欢迎大家去我的项目 wiki 上涂鸦。
最后，在某月某日给大家报一条真消息：我刚刚称了体重，刚好 45KG ，不多也不少。
March 31st, 2009 / No Comments » / by SteamedFish
我们知道，如果一个网页有 rss feed 的话，在 firefox 的地址栏最右边就会显示一个 rss 按钮。点击这个按钮即可订阅 rss 。 可惜 vimperator 默认是没有地址栏的，所以也不会显示 rss 按钮。如果仅仅为了一个 rss 按钮就打开地址栏占用宝贵的空间又实在是太浪费了。 下面是一个简单的 javascript 代码，放入 ~/.vimperatorrc 中，可以在 vimperator 的 statusline 中显示这个 rss 按钮。
1 2 3 4 5 6 7 8 9 10 11 | "Show the feed-button, even if the address-bar is not displayed" javascript < <EOF (function(){ var feedPanel = document.createElement("statusbarpanel"); feedPanel.setAttribute("id", "feed-panel-clone"); feedPanel.appendChild(document.getElementById("feed-button")); feedPanel.firstChild.setAttribute("style", "padding: 0; max-height: 16px;"); document.getElementById("status-bar") .insertBefore(feedPanel, document.getElementById("security-button")); })(); EOF |
March 31st, 2009 / 4 Comments » / by SteamedFish
“我将在接下来的一年中死亡”的概率，随着我的年龄的增加，在不断的减小。减小到我上大学的时候，已经微乎其微，我已经基本上忽略了这个概率。因此，除了去庐山做自然地理实习的时候立了一份遗嘱（后来在我成功活下来之后销毁），在其他时候，一直到现在，我都是没有遗嘱的。
但是，这个概率一直不是零。而且在我来到苏州之后，这个概率似乎在增加（因为我现在每天需要在苏州园区混乱的道路上步行一个小时上下班）。我越来越感觉到我不能忽略这个问题。
除非死因是由于地球毁灭，任何人在临死之前都会想有所交待的吧。这就是为什么我们需要一份遗嘱。但是这样随即会带来以下几个问题:
如何在死亡之前对遗嘱进行保密？
如何在死亡之后自动解密遗嘱？
如何防止他人伪造或者篡改遗嘱？
第三个问题相对比较好解决，现在的各种数字签名技术已经做的非常完善了。对于前两个问题，关键在于，那个加密/解密的程序如何识别我是否已经死亡？我总不能在身体里面植入一个芯片来判断我是否还活着，然后再用不可靠的无线来操纵我的遗嘱管理程序吧。（或者不但植入芯片，而且在我身体内拖根线出来保持联网？这个。。。）
事实上，我一直没有想到比较妥当的对于前两个问题的解决方案，这也是我的遗嘱迟迟不能出炉的原因之一。
这个遗嘱加密/解密的难题的最理想解决方法是，我能够提前知道我将要在何时死亡，并且我在获知何时死亡和我真正死亡的这段时间之内有足够长的健康的时间，这样我就有充分的可能性来亲自进行相关的加密/解密/签名活动。但是，我怎么样才能实现这个理想化结果呢？当然，有许多种可能的方法。根据我所想到的几种方法的对比，最为可靠的应该是自杀。
但是，这样又会带来新的问题。因为人总是希望自己能够活得尽量长一些的（至少我现在是这样认为的，至于我以后会不会改变这个想法我就不知道了），因此带来的新问题是:
我应该在何时自杀，才能够让我活得尽可能长，并且还能够保证我在自杀之前因其他原因死亡的概率尽可能低？
如果能够知道“我在接下来的一年中死亡的概率”随着时间变化的整个曲线，那么这个问题其实是相当简单的。而“我在接下来的一年中死亡的概率”的曲线虽然不能确切的知道，我乐观的认为还是可以进行粗略的估算的。
因此我们看到，通过引人自杀，确实可以简化立遗嘱所产生的加密/解密难题。因此我决定，写一份遗嘱，并且用一种只有我能够解密的方法加密，并且在我决定自杀之前解密该遗嘱。
最后一个问题:
我真的会在将来的某个时刻自杀吗？
其实，我倾向于认为，这个问题的答案是否定的。
March 29th, 2009 / 2 Comments » / by SteamedFish
你是那剑客
悄悄的飘来
看着我的挣扎
一剑刺来
正中我的胸口
3碗黑血喷出
带走了体内的毒液
溅满了我的屋子
然后便消失不见
留下我一个人
感觉着被放空的心
挣扎着擦拭我的电脑
写这篇博客
来纪念
你的离去
我的心空荡荡的
于是不再像装满了的时候
那般沉重
我感到了自由
嗅到了流浪的味道
死亡的气息
我不再懦弱
我笑了
我不是剑客
学不会你的飘逸
学不会你的冷血
我舞弄那剑
却不慎摔倒
那剑掉下来
将我刺伤
我只能留下来
慢慢疗伤
这对于一个剑客
司空见惯
我的血
却已经流空了
我也许会死
或者会被谁
向我体内重新输入毒血
把我救活
却让我一辈子受那毒的苦
当我思考的时候
就听到有人在
黑板上用粉笔划出声音
程序里面写出 hard code
把配置文件改成参差不齐
直到我最终习惯停止思考
于是
便是喜剧的大结局
然后被所有人遗忘
不被遗忘的只有悲剧
将被你创造
如果你永远是一个剑客
March 24th, 2009 / No Comments » / by SteamedFish
读 Gentoo 的起源，有感而发。
这个世界上有很多很多种职业，多到数不胜数的地步。我从来没有思考过该如何给这些职业分类，但我知道，有一类职业，叫做技术工人，或者简称叫技工。这类职业范围相当广，比如扫地的，盖房子的，开车的，站岗的，打字的，烧锅炉的……当然了，也包括我们这些 IT 行业的写代码的，看系统的人。在 IT 业的技术工人经常被叫做 IT 民工，虽然我觉得叫做 IT 技工更合适一点。当然， IT 业也并非都是 IT 技工，例如项目经理，产品设计师等职业就不是。
技工这种职业，比起别的职业来，有个很大的特点，那就是每个人做的贡献基本上可以表示成效率乘以时间。这个特点在别的职业中是没有的。比如销售这个职业，你卖出去的产品的数量跟你去吆喝的时间就不是成正比的。
一个技工该如何提高他的贡献呢？很简单，两条，通过学习和练习来提高效率，通过勤奋来增加时间。我们把这两条总结起来，就是脚踏实地。
同时，我们也可以看到，不管多么勤奋，时间的增加是有限的。因此，在时间不至于太少的前提下，通过学习和练习提高效率对一个技工的提高是最重要的。但是，这种提高将会非常缓慢。
是的，技工这类职业，基本上不可能速成，一个技工的能力，不会出现大起大落。技工的关键词，是厚积薄发。浮躁的人，想一飞冲天一鸣惊人的人，是不适合做技工这类职业的。
现在市面上经常会有人宣传各种成功之道，教授你各种成功的技巧。这些东西都是很有道理的，可惜宣传教授的人往往不提这些东西所适合的职业。对于一个技工，千万不要被适合其他职业而不适合技工的一些技巧所吸引迷惑，尤其应该警惕那些似乎可以速成的技巧。在技工这种职业中，速成基本上必然意味着速不成。技工所需要的唯一技巧就是脚踏实地厚积薄发，可能适合销售类职业的忽悠能力，可能适合科研类职业的怀疑能力，可能适用于传媒类职业的表述能力，没有一项是技工需要的。
绝大多数的误入歧途的技工只是自身一事无成，但是并不会对他人造成任何影响。但是有极少数误入歧途者，他们所信奉的技巧，可能不仅仅会危害到误入歧途者个人，甚至会危害到整个群体。这是因为有一些技巧要么会影响他人的时间，要么会影响他人的效率，或者会影响他人通过学习和锻炼来提高效率的机会。不管这样误入歧途者通过这些技巧，取得了多么引人瞩目的成功，他的所有成就必将因为团队的崩溃而全部化为乌有。
当然，人的本性很难改变。对于误入歧途着，他们如果想努力改变自己重归正途，也并非容易。那么，为什么不反其道而行之，挑选一份适合自己本性的职业呢？对于技工是歧途的方法和技巧，也许对于另外一种行业，就是正途。
附： Gentoo 的起源 的一段节选:
People can get ugly
slpv6 development was going well and all the senior developers were happy with my progress. But unfortunately, two lower-level Stampede developers wanted to control the slpv6 project. They didn’t like the direction I was taking, and they spent most of their time insulting the new slpv6 system. Though I spent hours in heated development discussions defending the proposal against their attacks, we weren’t able to resolve anything. Eventually it became clear that they were just naturally argumentative and wouldn’t be happy until they had their way. Fortunately for me, my project had the approval of the senior Stampede developers. But these discussions began to wear on me and made Stampede development very unpleasant. Ugh!
I couldn’t avoid these guys since I had to hang out on #stampede to chat with higher-level developers. And every time I was on the channel they became combative, trying to undermine my work. They’d use devious techniques like calling for development meetings (really just an opportunity to insult my work in front of the senior developers). They’d also try to call for votes, attempting to seize control of Stampede. Of course they’d only call for a vote when they thought they had convinced enough people to agree with them. Throughout all of this I continued my slpv6 development. Needless to say, the senior development loved my work and wanted me to continue (without their support I wouldn’t have been able to stick it out).
Understanding the freak
These two guys belong to a category of developer I like to call “the freak”. But although they made my development work very unpleasant, I also learned a lot from having to deal with them. At this point I’d like to offer you an expos?f the freak developers, a sort of comprehensive overview: the qualities that make a freak, the freak’s modus operandi, and how you, the development project leader, can confront and possibly reform the freak without exerting a lot of effort.
In order to avoid emotional damage, you’ll need one prerequisite: a backbone. If you’re unable to confront the freak in a respectful but firm manner, there’s no hope. The freak’s goal is to control as much of your project as possible so that he or she will feel powerful. The freak will use several techniques to make this happen. First they’ll start unfairly criticizing or bitterly complaining about a project and/or the developers working on a project. Then they will refrain from offering any constructive solutions. They will also not be willing to help with the project in any other way unless they are promoted to the role of project manager. Their goal is to convince you to give them as much authority as possible so that they can solve problems that only they, with their finely trained freak eyes, can see.
If the criticism and complaining aren’t effective, they’ll request a developer meeting. This will be their opportunity to try and divide your development team into two factions. When they think that they’ve gotten enough people on their side, they’ll request a vote (knowing they will win). If they don’t win the vote or they are overruled, they’ll push for another developer meeting next week in which they’ll again try to divide your development team. They’ll repeat this process endlessly.
If the developer meeting approach doesn’t work, freaks will become reformers. By adopting this role they will try to streamline (read: undermine) the oppressive and unfair executive decision-making process by attempting to replace it with something more democratic (read: easily manipulated.) This will often involve convincing you that you should do whatever the majority of your developers want. Freaks love this because then you can’t override those developer meeting votes anymore (muhahaha!). If you allow this to happen, you’ve basically given the freak the keys to your Lexus. You’re powerless.
In another approach, freaks will irritate and drive away your productive developers. Then they’ll work your entire team into a frenzy as they forcefully try to reform the project’s power structure. If their efforts are finally defeated, they’ll try to rally as many defectors together as possible and fork from your project. Ouch!
Managing the freak
You can identify these guys pretty easily. They’re the ones who aren’t writing any code (nor do they have any intention to). Instead they spend their time talking about more important things. You know, those managerial issues. If you’re a project leader, it’s pretty easy to deal with them. Just tell them that you won’t consider any proposal unless they produce working code. Or insist that they constructively help the current project, which includes obeying the current project manager, before giving them the opportunity to offer any (constructive) criticism. If they write some nice code or start being more helpful, great. If not, tell them to go away. They’ll either leave the project (if you ignore them long enough), or they’ll get their act together and start writing some code and generally become more pleasant.
Unfortunately the senior Stampede developers didn’t take on freak management. In other words, they allowed these two guys to pester me (and others) to no end. While the senior developers were always in favor of my development work, they didn’t do much to get these guys under control. So one day I decided that it would be easier to create my own distribution rather than have to put up with the two freaks. I resigned from Stampede development and started making plans to produce my own distro.
While I felt a bit weird about leaving a project because of two lower-level developers, the fact that they weren’t dealt with really indicated that the project had severe managerial problems. If the higher-level developers weren’t able or willing to make sure the Stampede development effort was pleasant and rewarding, then I didn’t want to be there.
