Firefox 3 usage on the MySource Matrix site

Richard Hulse, New Media Manager at Radio New Zealand (and a MySource Matrix user) posted an interesting article today about the uptake of Firefox 3. The post has some graphs that clearly show a large shift to Firefox 3 for visitors to the Radio NZ website. That prompted me to check my own statistics for the MySource Matrix website, which are very similar.

Like Richard, I didn't see any noticeable difference in the number of users using Firefox, but there was a definite shift from Firefox 2 to Firefox 3 around the middle of June.

Visitors using Firefox

Visitors using Firefox 3

Visitors using Firefox 2

Firefox users certainly heard the call.

PHP_CodeSniffer 1.1.0 released

I uploaded the 1.1.0 stable release of PHP_CodeSniffer earlier this week. This version has been a long time coming, but does include a lot of changes. The most exciting (for me) is the ability to sniff JavaScript files and find coding standard errors within them.

We have been using this feature internally at Squiz for a few months to start cleaning up our JavaScript files and make them, as much as we can, conform to our PHP coding standards. This allows developers to move more freely between PHP and JavaScript code throughout the day.

The other great addition was contributed to me by Jake Bates and allows PHP_CodeSniffer to be used within an SVN pre-commit hook. This allows code that violates your coding standard to be blocked from your code repository; an extreme but sometimes necessary rule.

You can view the full changelog and download the release on the package download page.

iFailed

Well, not me personally; Basil from work. He let me know (on Thursday) that he'd be late in on Friday because he was heading to an Optus store in Bankstown to try and get himself an iPhone from some guy called Ahmed. I, of course, could make an exception for such a noble cause. However, a confirmation call late Thursday established that Ahmed didn't actually have any iPhones, so the deal feel through.

Early Friday morning I get another call from Baz. Now he is sitting in the line at the Optus store on George St as they apparently have a load of iPhones. He had been sitting in the line since 6am; not as dedicated as those who queued up for the midnight launch, but still pretty dedicated!

At work, we were all pretty excited about playing around with a new iPhone and we were looking forward to Baz's arrival sometime around 11am, we speculated.

I got a call about 10am...

Baz got into the store, started signing the contracts and realised that he didn't have enough points of ID to purchase the iPhone. He was heading back to work with nothing but a promise that an iPhone was being reserved for him. EPIC FAIL!!

We thought we'd cheer him up by giving him an iPhone replacement.


And to remember the event, we are organising for the following poster to be printed, framed and hung on the wall at work.


On a related note, I headed into the city today with Deborah and Gerred (his first trip to the city) to get a camera bag and grab some lunch. We were also going to head into the Apple store and take a look around. When we got there, the line to get in was three times the length of the store and around the corner. There are certainly going to be a lot of iPhones out there! For now, I have to stick with playing around with the app store on Deborah's iPod touch.

PHP_CodeSnifer coding standard tutorial updated

In my last post, I mentioned that the current PHP_CodeSniffer manual doesn't have any information about using an external standard. The manual, and coding standard tutorial, assume that the standard you are writing and testing with is located within the main PHP_CodeSniffer directory structure. This is not normally the case, so I have updated the manual to be a little more realistic.

The coding standard tutorial now takes you through the process of creating an externally managed coding standard rather than instructing you to create your standard within PHP_CodeSniffer's Standards directory. This not only documents the usage of external standards, but also makes it much easier for would-be standard developers to get started.

The updated tutorial wont be available on the PEAR site until Sunday/Monday, but you can view it on Brett Bieber's build right now. From next week, you can view it at the normal place.

As a side note, creating and compiling the manual (peardoc) on Linux is a lot easier than on OS X. I am now using a Fedora 8 VM for all my PHP_CodeSniffer development and documentation work and I highly recommend this setup.

PHP_CodeSniffer update

It's been a while since I've posted about PHP_CodeSniffer, which is probably because nothing of great interest has been happening in the project. I'm pushing forward for a 1.1.0 stable release (the first stable with JavaScript code sniffing support) and have just released version 1.1.0RC3. I'm hoping that this will be the last release candidate before the stable.

So it's been a fairly boring period of time where I haven't wanted to add any new features for fear of destabilising the code, but some changes are on the horizon now, and they should be welcome additions.

The first of these is copy/paste detection, allowing PHP_CodeSniffer to find duplicate code throughout a project and help implement some code reuse. This is a feature PHPUnit currently has, but Sebastian Bergmann has kindly offered to port it to PHP_CodeSniffer as it seems like a better fit for this particular QA feature.

To implement this, I'll be creating a new kind of sniff that will be run after all files have been sniffed. It will be passed PHP_CodeSniffer_File objects for every file tested during the run, allowing the sniff to look into each file and do project-level checking. Errors will still be reported per file, as they are now.

The other feature PHP_CodeSniffer seems destined to get is the separation of the main code sniffing core from the standards. Coding standards can already be run without having to live inside the PHP_CodeSniffer standards directory (more on that later) but unit tests can not be correctly run in this scenario. This feature should make it easier for developers to distribute their own coding standards and introduce dependencies between standards and the core.

I have tried doing this before, but I could never get the PEAR installer to write the unit tests to the directory I wanted so I could run all my tests at once. Helgi Þormar Þorbjörnsson has kindly offered to help me resolve my unit testing problems, so I'll hopefully be able to sort out this issue now.

Finally, Stefan Priebsch got a bit fed up with my crappy documentation for external standards and decided to (thankfully) write an article about how to use an external standard with PHP_CodeSniffer. Well worth a read if you're managing your own coding standard. You might even be learning about this little used feature for the first time.