The Great Debate

I attended a debate at the Australian Computer Society last night:

THE GREAT DEBATE - Microsoft & Commercial Software VS Linux & the Open Source World

The Debaters:

Richard White, CEO and founder of Cargowise edi Pty Ltd. Richard's skills combine a unique 17 year understanding of the international trade and logistics industry combined with over 25 years in both software development and business management.

John-Paul Syriatowicz, Managing Director, co-founder and co-owner of Squiz.net, Australia’s largest content management system vendor. Squiz are recognised as industry leaders in relation to open source software. They are regularly invited to participate in industry forums and to consult with parties considering the use of open source software.

I found the debate entertaining, but not informative.

Ten formal questions were asked and then audience questions were accepted. The formal questions were predictable and the two minutes allocated for answers only allowed each side to rehash common arguments without providing any real evidence for their assertions. For the most part, the audience was left to make sense of the arguments themselves and understand why they made the case for each side. This approach worked fine in this case because the audience was comprised of students and industry professionals who were obviously well abreast of the cases for and against before the debate started, but I doubt many people walked away with any additional knowledge.

The questions from the floor were more interesting for me. With the formal questions being so common, it was interesting to see what people in the audience were actually thinking about. The first question asked was about mobile devices and which software model would take the lead in that area. A question like this, after so many predictable arguments, was refreshing to think about. Who would lead this market and why? I was speaking to JP after the debate and he mentioned that those audience questions got him thinking about topics he had not considered. I speak to him a lot about software development, but I hadn't heard his argument for mobile devices before. He believes that open source software will lead the way in the mobile device market because open source developers get excited about "just making things work". I have to agree with that.

One part of the debate that was disappointing was a switch that occurred after question seven. For the last three questions, Richard argued for open source and JP against. This was a staged switch, obviously designed to be entertaining. While it did get the audience laughing as the debaters pretended to have trouble with their arguments, it basically wrote off the last three questions and degraded the debate to a bit of a joke.

I think it was fairly clear to the audience that neither debater was strongly opposed to the other's views. Both Richard and JP seemed to be on the same page, seeing merits in both models and using software where they will get the most benefit rather than because of how it is produced and licenced. That's a great view to have for two people trying to grow their businesses, but it doesn't lend itself to great debating. Perhaps pitting two evangelists against each other would have produced some real heat, thrown up some less common arguments and left the audience with something to ponder.

So who won? The adjudicator declared no knock-out blow, although some may consider Richard wanting to switch sides as a general surrender. The audience was more clear, giving it to Linux & the Open Source World. Hardly a surprising result considering the number of UTS IT students in the audience.

PHP_CodeSniffer gets better newline support

I've just finished committing some fairly large changes to PHP_CodeSniffer to fix problems people are having with newlines.

Some users have reported to me that PHP_CodeSniffer incorrectly throws errors when it finds a Windows (\r\n) newline instead of a Unix (\n) one. Pattern sniffs, that check for the correct format of control structures, throw an error for every pattern tested because they are always looking for Unix newlines. When they encounter a Windows newline, the carriage return (\r) is seen as an invalid character and an error is thrown.

The problem comes from hard-coding \n characters into PHP_CodeSniffer and its sniffs. The reason this was done in the first place is because the PEAR coding standards, and those they I use myself, require you to use Unix newlines in your files.

For PHP_CodeSniffer to become more attractive to developers on other platforms, the hard-coded Unix newlines had to be removed so the existing set of sniffs could be included into new coding standards without any problems. The job is all but done now, but it was more complex than I expected.

The easy part was determining what newline character each file used. PHP_CodeSniffer already had a class that represents each file being checked, so it was pretty easy to add a check in there to look at the first line of the file and see what newline character it was using. The end result is that PHP_CodeSniffer_File now has a new public member var called eolChar that contains either a Unix (\n) newline, a Windows (\r\n) newline or a Mac (\r) newline.

The next bit was very time consuming. I had to replace all hard-coded Unix newline comparisons with $phpcsFile->eolChar. The main problem I had was that the comment parser built into PHP_CodeSniffer uses Unix newline comparisons a fair bit, but never has access to $phpcsFile. After a lot of mucking around, it's all working.

The hardest bit was changing the AbstractPattern sniff to allow a new special pattern type, EOL, that can be used instead of hard-coding \n into a pattern. There isn't anything really complicated about the code that was added, it's just that almost every change you make to that AbstractPattern sniff seems to cause a number of unit test failures. It's a great class, but it really hangs together through some sort of black magic, and I dread changing it.

It took the best part of a day to make and test all the changes, but it was worth it. The end result is that PHP_CodeSniffer will now throw the same errors and warnings for a file no matter what newline character it is using. The only exception would be a sniff specifically designed to check for a certain newline character, which is what I will now need to add to the PEAR standard to ensure users are warned that their newline characters are incorrect.

These changes are only available in CVS at the moment, but will be released in version 0.7.0 when they've had some time to settle.

PHP_CodeSniffer 0.6.0 (beta) released

Version 0.6.0 of PHP_CodeSniffer was released today. Besides a few bug fixes, support on Windows was improved greatly thanks to patches from Carsten Wiedmann, and a new command line argument was added to stop directory recursion.

From the end user documentation:

If you do not want sub-folders checked, use the -l command line argument to force PHP_CodeSniffer to run locally in the folders specified.

This allows you to specify a list of directories on the command line and stop PHP_CodeSniffer from checking their sub-directories.

You can download the new release, and view the changelog, on the download page.