Lukas Kahwe SmithMySQL enjoying its new home (9.5.2008, 06:16 UTC)

So it seems that Sun has made it clear that the core product will remain open source. Of course the definition of what is core and what isn't is up to Sun/MySQL to decide, but it seems that overall more things will be released as open source than if MySQL would have gone through with its planned IPO. So this is a good thing. Speaking of non core products, I really like what Mike and his team are doing in the GUI department with the workbench and their other GUI tools. However since Sun is friendly to PostgreSQL and actually also distributes SQLite (its bundled with Solaris after all), I wonder if they are considering making their tools more and more portable across other RDBMS?

Link
Ken GuestThe Date_Holidays package, a pack of splitters and a pear tree. (9.5.2008, 01:15 UTC)
Some of you may know that I am a lead developer of the pear Date_Holidays package. Date_Holidays helps you calculate the dates and titles of holidays and other special celebrations. This is all driver-based so it is easy to add new drivers that calculate a country's holidays. Until recently all of ...
Link
Daniel O'ConnorPEPR, XML_GRDDL and Digg's RDFa (4.5.2008, 04:15 UTC)
So, Digg got RDFa all over the place.

That's pretty handy since I've just moved XML_GRDDL to a call for votes.

Why, you ask? Because you can have instant RDF from digg in a few lines of code (tip: you want to grab xml_grddl from SVN at the moment).
Link
Strangebuzz...?PHP_Debug V2.1.3 released (2.5.2008, 11:32 UTC)
This is just a small update to correct and close minor bugs that were on the Pear bug tracker. I have also finally added the sources on the php csv server. The last step will be to do the end user documentation in the DocBook format so it can be available in the official pear documentation. Pear...
Link
Lukas Kahwe SmithFinding the right place for a join condition (30.4.2008, 10:03 UTC)

In a little app where users can create tabs and portlets in those tabs I ran into some issues with my ordered list implementation. It turns out I just misplaced a filtering expression in the WHERE clause instead of the JOIN condition. The basic idea was that I wanted to add new portlets in the left hand column at the top. The positions from the portlets actually start at 0, but what I am doing is to insert them at 1 below the current minimum or -1 if the table is empty. Then in a second query I push everything up by one. Seemed like the most efficient way to deal with concurrency. I guess in theory I could even skip pushing things up by one, but oh well.

Here is the original query (note that I am using PDO which supports Oracle style named placeholders for all drivers including MySQL):

INSERT INTO user_tab_portlets (tab_id, portlet_id, pos, col, is_open, config)
            (SELECT :tab_id, :portlet_id, COALESCE(MIN(utp.pos)-1, -1), :col, :is_open, :config
                FROM user_tabs ut LEFT JOIN user_tab_portlets utp ON (ut.id = utp.tab_id)
                WHERE ut.id = :tab_id AND (utp.col IS NULL OR utp.col = :col)
                GROUP BY utp.tab_id, utp.col)

I sort of expected the "utp.col IS NULL OR utp.col = :col" to work out fine for the case when there are no portlets yet in the left column on the given tab, since due to the LEFT JOIN the "IS NULL" part should fire (the col is not nullable). As it turns out a more readable and actually working version of my query would look like this:

INSERT INTO user_tab_portlets (tab_id, portlet_id, pos, col, is_open, config)
            (SELECT :tab_id, :portlet_id, COALESCE(MIN(utp.pos)-1, -1), :col, :is_open, :config
                FROM user_tabs ut LEFT JOIN user_tab_portlets utp ON (ut.id = utp.tab_id AND utp.col = :col)
                WHERE ut.id = :tab_id
                GROUP BY utp.tab_id, utp.col)

Anyways, if anyone has some pointers on how to better do an ordered list in SQL please let me know. I felt quite good when I figured this one out :)

Link
Christian WeiskePHP Unconference 2008 in Hamburg (28.4.2008, 08:15 UTC)

Dieses Wochenende (26./27. April) war ich in Hamburg auf der PHP Unconference 2008, organisiert von der PHP Usergroup Hamburg. Tobias Struckmeier war so lieb mich und mindestens 6 andere Leute für das Wochenende bei sich aufzunehmen, wodurch mir dir nervige Hotelsuche oder das Übernachten in der Uni erspart blieb. Außerdem wurde der Abend etwas länger; nachts um 1 saßen wir nach der Heimfahrt von der Recycel Bar vor den Laptops und informierten uns gegenseitig über coole selbstgebaute Software :)

Sonnabend in der Eröffnungssession wurden die Sessions festgelegt - schön basisdemokratisch nach Anzahl der Wünsche der Teilnehmer. Meinen Vortrag über PEAR2 wollten nicht genug Leute (<8) hören, das Angebort für den SPARQL bekam volle 9 Punkte und wurde als auf den Sonntag 16:00 in den letzten Slot gesetzt.

Den so "gewonnen" Freiraum konnte ich sehr schön mit dem Beisitzen in den anderen Sessions füllen und hier und da was Neues aufschnappen. Das tolle an der Unconf sind eigentlich - wie überall - die Gespräche zwischen den Vorträgen, von denen es reichlich interessante gab.

Ich wurde allerdings immer mehr in dem Gefühl bestärkt, auf den falschen Gebieten tätig zu sein: Der PEAR-Talk wurde nicht genommen, das PEAR-Installerbuch in der Verlosung als zweitletztes genommen und mein SPARQL-Vortrag am Sonntagnachmittag wollten ganze drei Leute hören... Nach der Vorstellung von DBpedia entwickelte sich aber doch ein interessantes Gespräch über die Verfügbarkeit von Daten über die Menschen. Sie existieren sowieso im Netz, allerdings haben nur ... Organisationen die Mittel, sie zusammenzuführen. Ergebnis: Damit alle die gleichen Chancen haben, müssen Informationen für alle verfügbar und frei sein. Denn irgendjemand hat immer Zugriff darauf - warum also nicht alle?

Zusammenfassend war es ein sehr interessantes und schönes Wochenende. Als zum Schluß darum gebeten wurde, Kritik und Verbesserungsvorschläge einzureichen fiel mir absolut nichts ein - perfekt!

Link
Greg SherwoodPHP_CodeSniffer code taken and rebadged as Zend Framework code (26.4.2008, 00:15 UTC)
A new feature request for PHP_CodeSniffer alerted me to the effort of a couple of Zend Framework developers to create a PHP_CodeSniffer standard that can be used by all Zend Framework developers. The feature request mentioned that the name they had chosen (Zend) conflicts with the existing standard that is distributed with PHP_CodeSniffer.

I immediately thought this was a bit strange because I've already had someone from Zend contribute some code for the Zend Framework coding standard, and I've written a fair few sniffs for it myself.

I took a look at the code and noticed that almost all of the sniffs that have been committed to the Zend Framework SVN repository are just copies of the sniffs I have written for the existing PHP_CodeSniffer standards. The troubling part is that all the copyright notices and author tags have been switched to indicate that the code was written by and copyright Zend. Worse still, the licence had been changed to the Zend Framework's New BSD licence.

This is a pretty clear violation of the BSD licence under which PHP_CodeSniffer is distributed, so I've left a comment on the Coding Standard RC page in the Zend Framework wiki. I tried locating an email address, submitting an issue and even commenting on an existing issue, but it appears the Zend Framework doesn't have any scope for non-approved developer comments besides the wiki.

I did get a little angry when I saw this, but I also see this as an opportunity to complete the PHP_CodeSniffer Zend standard and get PHP_CodeSniffer our there to a new developer community. The Zend Framework obviously has a couple of developers dedicated to automating their coding standard checks using PHP_CodeSniffer, so I've provided them with an invitation to contact me and work together. I will hopefully be taken up on that offer.

Update: Thought it might be easier to see the problem if you can focus on one file. Take a look at Zend's FunctionDeclarationArgumentSpacingSniff (from the ZF SVN repo) and Squiz's FunctionDeclarationArgumentSpacingSniff (from the PEAR CVS repo). Only very minor changes have been made. Even with these changes, it would be best to extend the Squiz sniff and do some minor refactoring rather than copy/paste, which I'm happy to help with.

Update: Thomas Weidner has contacted me to let me know the files have been removed from the Zend Framework SVN repo.
Link
The Nazg SpeakethEclipse Mylyn - Sync to PEAR (21.4.2008, 18:16 UTC)
Link
Greg SherwoodPHP_CodeSniffer 1.1.0a1 released (21.4.2008, 02:15 UTC)
I've just uploaded PHP_CodeSniffer version 1.1.0a1, which contains 8 bug fixes and adds a load of new features including support for sniffing JavaScript files, an SVN pre-commit hook, integration with JSL and a new collection of sniffs that implement part of the PMD.

Thanks to everyone who has submitted bug reports and special thanks to Jack Bates for the pre-commit hook, Jan Miczaika for a new sniff and Manuel Pichler for bug fixes and the PMD sniffs.

You can view the full changelog, and download the release, on the package download page.
Link
Lukas Kahwe SmithDear Marten, (18.4.2008, 06:20 UTC)

So now that you have posted some clarifications on what is going on exactly, it seems like there is less of a problem as original thought. However I must say that the the replies you posted on Jeremy's blog (and later mine as well), you let me to believe that things are quite bad indeed. Only now that I see your two posts on /, I can relax a bit again. Matthew has written a very good summary of the situation with some historical background.

I guess its great that you take the time to post on the blogs of individual community members, but next time you might want to take a bit more care on what you post. For example in my post I explicitly asked to be corrected if I misunderstood what's going on. When you posted in my blog without correcting me, I assumed that I was right with my assessment of the situation. Also I am a bit concerned about how you compare MySQL's business model with PostgreSQL, because I think they do not really compare well (at least from a community perspective), though Josh predicted back when I posted my thesis paper on exactly this topic, that MySQL is moving towards the PostgreSQL eco systems "secret sauce" business model.

So where are we at? It seems that Sun/MySQL is considering close sourcing now yet developed code that provides implementations for plugins against some of the new pluggable API's. This reduces concerns since this way the chances of things diverging between the "real community" (more on this in the next paragraph) and Sun/MySQL internal development. More importantly it means that community users can easily load community developed alternative implementations without much hassle. I have not examined the plugin API's in detail, but from what I read they all loading of plugins without a restart. That being said its still likely that most hosters will not allow average users to load new modules, but I am not sure how that will play out and how much work there has been done to make it safe for hosters to allow this. So as long as the proprietary extensions focus around plugins against clearly defined plugin APIs, I see little problem from the perspective of the community. If this makes business sense is another story.

But there is still some concern that I have with Marten's comparisons made in regards to the PostgreSQL eco system. To me the key difference between their eco system and MySQL's is that MySQL does not have a true "community" version. MySQL AB and now Sun decides on what goes into the "Community Edition". More over its exactly the same company that also employ all of the key developers, so there isn't really someone outside of Sun/MySQL that could reasonably decide what should go in. Of course there could be community votes, but this is also not how open source works. For the most part the core group around an open source projects act like benevolent dictators that make decisions based on a mixture of personal needs and the goal to keep the project alive as open source.

There is this delicate trust balance that end users put into the lead developers of the open source products they use. For example look at all the complaints that Zend has gotten for having developed a closed source byte code cache. Ever since then people have said that this should be part of PHP itself, but Zend is stopping this from happening. Even today after years of having an open source solution available that is even run by Yahoo on their servers, we still do not have a PHP release with a bundled byte code cache. However Zeev has given his blessing to bundeling APC with PHP6. Is it Zend's fault that it took this long? Did Zend do enough for PHP that it was ok to give them this money making opportunity? However the key point is that the community "gave" Zend this opportunity, because there are enough non Zend people in the core developmen

Truncated by Planet PEAR, read more at the original (another 1266 bytes)

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR