Medieval Programming

symfonynerds has been running a survey. 250 symfony developers filled it out and the majority answered to question 8:

I have never developed in another web application framework

I consider this very alarming. If symfony is you first framework, then it should not be your last. Good developers need to know multiple frameworks, libraries, design patterns, concepts and so on. There is so much around that it would be very ignorant to stay with one player. You might be missing much better choices for other scenarios.

When reading the Whats new in Doctrine 2.0 slides I was very happy that Jonathan did look around. Doctrine 2.0 was redesigned to follow the Java Persistence API (and inspired by Hibernate).

This also brings up an interesting aspect of specifications: They are not only valid for the language they were designed for.

Fabien today activated Symfony components, a sub-project of symfony which aims at delivering high quality reusable components without dependencies. This is a bit more like the Zend Framework idea, but makes standalone components, not ones with many dependencies. They also power the symfony framework.

The website is really appealing, great layout and a crisp and clear design. Congratulations Fabien, keep up the good work.

PS: I really like the cartoonic animals you have chosen. Awesome!

symfony project development at the moment focuses on finding and eliminating more performance issues, as this was high on the whish list. The symfony blog has two postings about recent enhancements.

While being at it i noticed a common 5ms and highly disc bound delay that is included in every call.

It is sfProjectConfiguration#getAllPluginPaths() which returns an array of all plugins and their respective location on the file system. Its basically a sfFinder call that scans a few directories. But that costs. And it is done on every call. But usually the plugins do not change while a site is live, do they?

Here my inofficial enhancement of this. You can easily use this. Just put it into your config/ProjectConfiguration.class.php and you are done:

  public function getAllPluginPaths(){
    $cacheFile = sfConfig::get('sf_cache_dir').'/all_plugin_paths.cache';
    if (is_readable($cacheFile))
    {
      return unserialize(file_get_contents($cacheFile));
    }
 
    $allPluginpaths = parent::getAllPluginPaths();
    file_put_contents($cacheFile, serialize($allPluginpaths));
    return $allPluginpaths;
  }

Many open source projects follow the “do not reinvent the wheel” philosophy. It described the idea of using something that is existing, something proven, like the wheel we use for centuries. In open source, where work is not paid this free artifacts are appreciated, but also in commercial software people like to get something for free. I do as well.
But what if your wheel has a flat tire?

symfony uses Prado framwork for its i18n support. Prado itself uses standardized localization (CLDR) data. But the original author at Prado chose to convert the CLDR data into a custom format. Here the trouble starts.
The Prado proprietary data format was not updated since 3 years. I tried to contact the Prado folks three times, but never got an reply. In meanwhile the tickets in the symfony trac regarding I18N data being outdated started to pile up.
So in order to update symfony I18N data I had to reverse engineer the format used in Prado. It is a serialized PHP array, but I could not find how the CLDR data was converted. After searching for a while I found that Prado claimed to have imported the data from ICU.
Because the import script originally used is unknown for me I had a look at the ICU data.
Hmm yet another proprietary format… Hey cool, it is very close to YAML!
So I wrote a little script to convert proprietary ICU format into proprietary Prado format by first making a valid YAML out of it using symfony sfYaml and then postprocessing and serializing the array. During the process I found quite some mess in both, the ICU and Prado data. But because I do not want to rewrite everything around the data files, I just imported the mess and keep it messy compatible.

The morale of this tale is twofold:

• Stick to Open Data Formats – Less Hassle for everybody
• Open Source can have a short life – If you release something open source, be ready to maintain it. If you use something open source, be ready to maintain it yourself.

Now I pass the ball to all symfony users and developers: Please test this data files. Due to the vast changes from CLDR (2Megabytes of new data) and the conversion process I cannot assure or prove that they are compatible. So they most likely will appear earliest in symfony 1.3. And perhaps in Prado if they decide to take them as well (and hopefully give credit).

There are two packages:

1. The full package, including the ICU original files from this week, the intermediate yml results and the finalized symfony/Prado dat files.
2. Just the symfony/prado data dir files. You should be able to find the lib/i18n/data directory inside you symfony library path.

Please report issues preferrably to my symfony-project.com email account, the symfony mailing list or here. I cannot support Prado users, but as the i18n hasn’t changed at Prado for 3 years it most likely will work there as well.

Update:

I just commited the new I18N data for symfony 1.3. I was able to optimize the resulting files a bit towards symfony, so I could remove some extra postprocessing. This required some changes in symfony, but I assume that they are backwards compatible for 95% of the users. These changes also made the files incompatible with older symfony versions, but I anyway did not want to risk breaking stable applications.

The latest conversion script and data files are available in symfony svn.

symfony is mentioned in this post about PHP performance!
Well that was of course a bit cheating, because the posting is mine. Because we do a lot of Java performance troubleshooting and optimization and some of our customers are discussing using PHP for the web layer I found it appropriate to talk about measuring performance in PHP.
Feel free to discuss it in the comments section.

today I took an hour to update hma-info.de to symfony 1.2.

I hope that I can encourage more people to move their projects to a new version, cause there are new nice features in, performance is better, and we need some people to try it before we can release the final version of it soon.

The whole upgrading procedure of my site did not take longer than that hour, including the time I needed to fix some issues. Before the upgrade the page was running on symfony 1.0, is it was an upgrade to 1.1 and then to 1.2.

The first thing to play around with is: how to upgrade a project? The tricky thing here is that you have to use the old project which doesn’t know about an upgrade path, tell it to use the new symfony and then run the upgrade. Luckily there are instructions on the symfony web site that work like a charm.

The upgrade procedure asked me to delete a few files which were no longer required. Good! Less clutter means easier maintenance. Next I tried to run symfony propel:build-all and ran into the first issue:

Propel Behavior ‘type’ unknown

This took me the longest time to find. In my schema I had a column named ‘n’. The new yml parser translates this to ‘false’ and thus makes the properties of the column become properties of the table, which are behaviors.
I took the chance to give my columns ‘n’,'p’ and ‘s’ meaningful names.
I had to update a few save() function signatures according the symfony 1.2 upgrade guide.
The next issue I ran into was that Propel1.2 did not use a good utf-8 connection. I don’t know how it did that but the db had a utf-8 collation type but the data wasn’t. But somehow this was working before. Now I got garbage displayed. I ran a few UPDATE statements against the database, fixing the German umlauts and then I was done.
I threw away my 1.0 admin generator backend, because I anyway did not use it and regenerated a new one. Ill extend it now when I have some time this week to take advantage of the new capabilities.
I deployed and everything worked as before. But it is now even faster! And better, cause we knew, that newer is always better
Next I will update my handmade routing to utilize the new routing framework from symfony.

But first of all, I will need to redesign the frontpage. News from 2007 are no news.