So I am way behind blogging on things of importance. Like the fact that Klopstock (one of) the frisbee teams I play with won their first Ultimate Frisbee tournament. I missed the Saturday action but was right on time to injure my elbow during the final on Sunday. Then there is a lot to say about what has been going on with the TestFest month, which is now over. But in this blog post I will focus on my pet project emPHPower, leaving the well attended talk (at 8:30am too!) at DLW/IPC in Karlsruhe on Doctrine with just this little side note.

If you use YAML in PHP, then you had until recently the choice between the C based PECL extension syck or the horrible spyc PHP based implementation. With syck it has the issue that it only supports the core standard and not stuff like merge-key, which is a very very useful extension to the core YAML standard.

A few years ago a backdoor was found in Firebird, the open source fork of Interbase, that already existed in the original Interbase product and was still in the version of Interbase that was sold at the time. Nowadays this is fixed, but it was kind of scary that a company would add a backdoor and then totally forget about it, why else would they not have removed it before open sourcing (after all a backdoor only works through obscurity)? Anyways the other day another security issue (this sort of thing happens to the best of them) in Interbase that was fixed in January in Firebird already.

One CS (coding style) item I miss in most such guides is the point to always return as early as possible in your methods/functions. This translates to more readable code and less indenting. Let me give an example (btw this example is also a very bad example of meaningful variable names):

So today Roman, one of the developers on the Doctrine project, pointed me to an article that was discussing the misuse of DISTINCT. This article went so far as to say that "A SELECT DISTINCT query is frequently a "code smell". The article pointed to another article hosted at onlamp.com. That author was advocating the use of subqueries to more efficiently filter out redundant rows. Immediately I began to wonder if this is really a feasible approach since MySQL's subquery handling is very slow. I could imagine this being faster on RDBMS where the subquery implementation is more mature. That being said comments in the onlamp.com article point to the fact that even on Oracle things get slower with the subquery approach. The original article does however talk about how rewriting similar queries with a subquery improved performance on PostgreSQL.