Jan'uary

燃烧吧! 小宇宙

Fri, 11 Jul 2008 15:07:48 +0800

总觉得什么时候曾经听过这张专辑，那天在出租车上，牛奶@咖啡的声音传进耳朵的时候

深沉的音乐让人思考，单纯的音乐让人感动，我都喜欢

整张都很好听，强大的专辑

...

调整了一下UI

Thu, 10 Jul 2008 13:07:42 +0800

简单的把文章区域变宽了些，现在可以放下width>700px的图片了

推荐使用19"以上的lcd浏览否则效果很矬。。。现在19寸该是主流了吧。。。...

Famous Programmers From Adleman to Zimmermann

Thu, 10 Jul 2008 13:07:32 +0800

http://grok-code.com/37/famous-programmers-from-adleman-to-zimmermann/

...

村里来了拆迁队

Fri, 04 Jul 2008 16:07:12 +0800

转旧闻一则:

1月28日，第15届(2006年度)全国新闻摄影作品评选活动所有奖项的提名都已产生，所有金银铜大奖都将从这些作品中选出，1月29日新闻发布会将公布获得大奖的名单。图为日常生活单幅提名作品《村里来了拆迁队》。

　　2006年4月7日，羊坊村工作人员带着大批联防队员前往下一个点拆除违章建筑。当天，丰台区花乡羊坊村村民王艳荣家100多平方米的花棚被当作违章建筑强制推翻，而花乡2008奥运办公室工作人员则表示，清除违建主要针对在承包地上建房出租的行为，盖花棚不涉及土地使用性质改变，应协商解决。京华时报甄宏戈摄

...

Ruby Community Vulnerability

Thu, 03 Jul 2008 11:07:07 +0800

Ruby社区最近有点动荡，都是从大约一周之前发现的一堆vulnerabiilty开始的。

事情的经过很简单，在Apple工作的Drew Yao发现了MRI的一堆要命漏洞，随后Ruby官网给出了一堆传说fix了这些个漏洞的新版本，再然后各种能在之前ruby上运行的应用纷纷 segment fault了，随后引来ruby talk ML以及blog圈中的大讨论。

整件事情给人的感觉就是，包括matz在内ruby core team非常的不成熟。在ruby早期的发展阶段，作坊式的快速更新也许不会引起麻烦，但随着ruby社区的日益壮大，ruby现有的开发模式显然已经跟不上来自各方面的推动力量。引起麻烦的并不是MRI的这些漏洞，而是ruby现有开发模式自身的弊端: 缺乏稳定版本(1.8.6p114之前的黄金年代已经过去了)，feature控制混乱(1.8.7对1.9特性的引入仍然是一个有争议的话题), 忽略社区以及Zed Shaw们指出的core们的拒人于千里之外的姿态。

大胆猜想，如果ruby-core无法适应社区的迅速壮大，也许将来的ruby这门语言的事实标准从MRI变成JRuby, Rubinius或者众多其他Ruby实现中的一个, Rubinius的RubySpecs已经为这个可能性打下了地基。现在的ruby看起来更像一个伪开源项目,成功的OpenSource不仅仅是free，更重要的是社区建设以及和社区的互动。

ps. 一个小人的想法: 我总觉得matz有点不爽David(DHH)，MRI的发布似乎总是要给Rails带来一些麻烦。上升点高度的话，依稀间看到东西方之间的对立，西方世界夺取ruby控制权的企图已经隐隐出现。好吧，我阴谋论看多了-_-...

Survey on Ruby development

Wed, 02 Jul 2008 11:07:33 +0800

http://devver.net/blog/2008/06/the-results-of-our-ruby-development-survey/

It's interesting so many ruby developers use Vim :->

Vim is really good at its job, the only thing lack now is a convinient integration with debugger. NetBeans is impressive on debug....

Amazon charge you for their own defect?

Wed, 25 Jun 2008 12:06:14 +0800

From Amazon's FAQ:

I am sure that my queue has messages, but a call to ReceiveMessage returned none. What could be the problem?

Due to the distributed nature of the queue, a weighted random set of machines is sampled on a ReceiveMessage call. That means only the messages on the sampled machines are returned. If the number of messages in the queue is small (less than 1000), it is likely you will get fewer messages than you requested. If the number of messages in the queue is extremely small, you might not receive any messages in a particular ReceiveMessage response. Your application should be prepared to poll the queue until a message is received. Note that with the 2008-01-01 version of Amazon SQS, you’re charged for each request you make, so set your polling frequency with that in mind.

Source...

The Evolution of Pre-Launch Gmail In Screenshots

Tue, 24 Jun 2008 15:06:38 +0800

Via

...

Update your ruby on production server now

Mon, 23 Jun 2008 23:06:00 +0800

"Multiple vulnerabilities in Ruby may lead to a denial of service (DoS) condition or allow execution of arbitrary code."

http://www.ruby-lang.org/en/news/2008/06/20/arbitrary-code-execution-vulnerabilities/

Affect nearly all version of ruby .....

Tip: get better sound quality from intel 82801g integrated sound card

Thu, 19 Jun 2008 17:06:26 +0800

on ArchLinux:

echo "options snd-hda-intel enable=1 index=0 model=3stack" >> /etc/modprobe.conf...

Build your web page from ASM ..

Thu, 19 Jun 2008 16:06:36 +0800

Crazy.. "The future still belongs to assembler programmer!"...

21 Laws of Computer Programming

Wed, 18 Jun 2008 16:06:08 +0800

http://www.devtopics.com/21-laws-of-computer-programming/

Any given program, once deployed, is already obsolete.
It is easier to change the specification to fit the program than vice versa.
If a program is useful, it will have to be changed.
If a program is useless, it will have to be documented.
Only ten percent of the code in any given program will ever execute.
Software expands to consume all available resources.
Any non-trivial program contains at least one error.
The probability of a flawless demo is inversely proportional to the number of people watching, raised to the power of the amount of money involved.
Not until a program has been in production for at least six months will its most harmful error be discovered.
Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
The effort required to correct an error increases exponentially with time.
Program complexity grows until it exceeds the capabilities of the programmer who must maintain it.
Any code of your own that you haven't looked at in months might as well have been written by someone else.
Inside every small program is a large program struggling to get out.
The sooner you start coding a program, the longer it will take.
A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.
Adding programmers to a late project makes it later.
A program is never less than 90% complete, and never more than 95% complete.
If you automate a mess, you get an automated mess.
Build a program that even a fool can use, and only a fool will want to use it.
Users truly don't know what they want in a program until they use it.

...