ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
Another Interbase Security Issue found first in Firebird
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):
Bad smells are relative to where you are coming from
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.
The TestFest half time report
So for those of you living under the rock, this month its TestFest time over in PHP-land. What started as a wild idea on IRC is now a global event that spans the globe from Europe to North and South America (I must say I really love the logo of the Costa Rica PHP UG!). So far things have more or less worked out. Not as we originally planned, but with so many people stepping up to the plate, the community is really showing how much it can achieve when it works together. If you head on over to the bug tracker (yeah originally we planned to have a custom interface) you can see that we almost have 100 submissions at this point. Watching the php-cvs commit mailinglist one can also see that a number of tests have already been committed.
Mitigating the risk of license changes
This is just a very short note about the recent license change from LGPL to GPL made by the author of extJS. When choosing an open source product make sure that the contributors are fragmented across enough organizations to prevent any chance of being able to do a license change. If that is not the case make sure that the community is large enough so that you have a good chance at succeeding with a fork if the need arises. In the case of extJS the later seems to be the case. As such the license change itself is not soooo big an issue, since a lot of people do not consider their frontend code to be proprietary anyways. The source is there for all to see. So for the most part people are fine considering their frontend to be licensed under the GPL. That being said, extJS guys are trying to make people believe that using extJS on the frontend has any effect on the backend licensing. Kinda reminds me of the MySQL client license stunt and the days when MySQL sales reps intentionally confused people about the GPL .. good that those days are over.