Nio’s Weblog

Rails 1.0: Party like it's one oh oh!15 months after the first public release, Rails has arrived at the big 1.0. What a journey! We’ve gone through thousands of revisions, tickets, and patches from hundreds of contributors to get here. I’m incredibly proud at the core committer team, the community, and the ecosystem we’ve raised around this framework….

最近连续中双色球的小奖，周日中了个5元末等奖，今天又中了个10元的，啥时候才能整个500万呀

郑钧曾经在某个电视节目上说过，当他看到小生命出现在他面前的时候，整个人的世界观都在开始改变。一个像郑钧这样的浪子都会因为神奇的小生命而改变，更何况我这样普通的人。我也开始发现自己的生活悄悄地在改变。比如之前上网看技术、新闻网站比较多，现在上网看 丽家宝贝 比较多，我们在选购婴儿床、推车等等，准备以最好的装备呵护即将诞生的小生命。我开始不太关心巴塞罗那队，不太关心 PHP，不太关心年终会不会有奖金，我只关心我的宝贝能不能安全降生。看电视的时候开始注意人名，因为我们还没有为宝宝准备一个好名字。开始关心一些理财信息，希望以后能够为他的教育筹备一些 money。我的父母将毕生的心血都花在了我身上，现在开始轮到我了，我会努力的！

Moving Legacy PHP4 apps to PHP 5.1Today, started to test moving some of our PHP4 apps to PHP5.1.1. Some of this code was written for PHP 4.0.6, over 3 years ago. The migration so far has been relatively painless. Here are some of the problems we encountered.

* We use code generators a lot, and some of the generated PHP4 code gives us the infamous "Only variable references should be returned by reference" warning. This warning is because of a memory corruption problem that can occur in all versions of PHP (4 and 5 included). When we analysed the problem, we realised that the amount of code we would have to correct would be massive, so at the moment we are disabling these warnings by setting error_reporting(E_ALL-E_NOTICE). Not the correct solution perhaps, but given the size of our code-base, it's a pragmatic one, as we have not crashed due to these memory corruptions in PHP4. If PHP5 starts to crash in weird places, then we'll look into fixing this.

For fresh PHP5 code we write, we do set error_reporting(E_ALL), and fix all notices. We do not use the E_STRICT compatibility check because of the ridiculous warnings that arise, such as the warning that the VAR statement is now obsolete; it isn't, VAR will still be supported in PHP6, and this VAR warning will apparently go away in 6 too.

* Some of the oldest code continues to use the old super-globals format $HTTP_POST_VARS and $HTTP_GET_VARS. We had to enable in php.ini the setting register_long_arrays = On to set these variables.

* We use some PEAR libraries, and did encounter a few errors, mainly because we are using an older version. These were fixed by upgrading the relevant modules.

* Apart from these issues, it was a stroll in the park. Everything worked fine. Partly because the core libraries that we use (eg. ADOdb and phpLens) are continiously tested against the latest versions of PHP. The PHP Internals Developers did a really good job maintaining backward compatibility, though the number of E_NOTICE and E_STRICT warnings you get is too alarming…

* The main issue still preventing PHP 5 migration for us is the lack of a reliable open source opcode cache for Windows. Some customers use Unix, but others are more comfortable with Windows. I have hopes for eAccelerator, which apparently is in final beta.

* Once everything stabilises in PHP 5.1 and eAccelerator, I will get our software developers to look into setting up a parallel development environment on our Windows and Linux servers for both legacy PHP4 apps and newer PHP5 ones. And then I will start looking into creating a PHP5 version of the EasyWindows installer, a full-featured PHP installer for IIS that includes fast-cgi support.