PHPUnit training at Squiz

Sebastian Bergmann was in Sydney last week and I took the opportunity to have him come in and do a day of PHPUnit training for the developers at Squiz. We also went through continuous integration software like phpUnderControl and Bamboo.

It was great to finally meet Sebastian and learn a lot about the tools we will be using in MySource4 to ensure the quality of our product.

If you are thinking of some in-house PHP training, Sebastian is great tutor on all things testing and comes pre-loaded with some funny and informative stories about his travels and PHP development in general.

PHP_CodeSniffer reporting improvements

Spurred on by some feature requests and at least one annoying colleague (you know who you are), I've made some fairly good improvements to the way PHP_CodeSniffer reports the errors and warnings it finds. I've added support for the concept of error sources, allowing you to see which sniff generated an error and also filter out the messages for that sniff.

The XML, CSV and CheckStyle report formats all now include a source attribute in their output. This will allow continuous integration platforms to call PHP_CodeSniffer and produce a report of the most common errors rather than just display a list of all errors or the number of errors for each file.

You can also expose this information in the full and summary reports, although it is off by default to avoid clutter. Use the new command line argument -s to show sources in these reports. Instead of something like this:

FILE: /home/squiz/PHP_CodeSniffer/temp.php
--------------------------------------------------------------------------------
FOUND 6 ERROR(S) AND 0 WARNING(S) AFFECTING 5 LINE(S)
--------------------------------------------------------------------------------
 2 | ERROR | Missing file doc comment
 3 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 0
 3 | ERROR | Object operator must be at the start of the line, not the end
 4 | ERROR | TRUE, FALSE and NULL must be lowercase; expected "true" but found
   |       | "TRUE"
 6 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 1
 9 | ERROR | TRUE, FALSE and NULL must be lowercase; expected "false" but found
   |       | "FALSE"
--------------------------------------------------------------------------------

You get this:

FILE: /home/squiz/PHP_CodeSniffer/temp.php
--------------------------------------------------------------------------------
FOUND 6 ERROR(S) AND 0 WARNING(S) AFFECTING 5 LINE(S)
--------------------------------------------------------------------------------
 2 | ERROR | Missing file doc comment (PEAR.Commenting.FileComment)
 3 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 0 (PEAR.WhiteSpace.ObjectOperatorIndent)
 3 | ERROR | Object operator must be at the start of the line, not the end
   |       | (PEAR.WhiteSpace.ObjectOperatorIndent)
 4 | ERROR | TRUE, FALSE and NULL must be lowercase; expected "true" but found
   |       | "TRUE" (Generic.PHP.LowerCaseConstant)
 6 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 1 (PEAR.WhiteSpace.ObjectOperatorIndent)
 9 | ERROR | TRUE, FALSE and NULL must be lowercase; expected "false" but found
   |       | "FALSE" (Generic.PHP.LowerCaseConstant)
--------------------------------------------------------------------------------

There is also a totally new report format that shows a summary of your error sources. You use the command line argument --report=source to print a report like this:

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
------------------------------------------------------------
STANDARD   CATEGORY      SNIFF                         COUNT
------------------------------------------------------------
PEAR       White space   Object operator indent        3
Generic    PHP           Lower case constant           2
PEAR       Commenting    File comment                  1
------------------------------------------------------------
A TOTAL OF 6 SNIFF VIOLATION(S) WERE FOUND IN 3 SOURCE(S)
------------------------------------------------------------

You can also get it to use official source names using the -s command line argument:

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
------------------------------------------------------------
SOURCE                                                 COUNT
------------------------------------------------------------
PEAR.WhiteSpace.ObjectOperatorIndent                   3
Generic.PHP.LowerCaseConstant                          2
PEAR.Commenting.FileComment                            1
------------------------------------------------------------
A TOTAL OF 6 SNIFF VIOLATION(S) WERE FOUND IN 3 SOURCE(S)
------------------------------------------------------------

The idea with these source IDs is that you can then use them to filter your (potentially) long list of error messages and target a particular rule that you want to fix all in one go. So in this report, we have 3 errors generated from PEAR.WhiteSpace.ObjectOperatorIndent. To find out what they are, add the command line argument --sniffs=PEAR.WhiteSpace.ObjectOperatorIndent to get this:

FILE: /home/squiz/PHP_CodeSniffer/temp.php
--------------------------------------------------------------------------------
FOUND 3 ERROR(S) AND 0 WARNING(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
 3 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 0
 3 | ERROR | Object operator must be at the start of the line, not the end
 6 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 1
--------------------------------------------------------------------------------

Another related feature that was added is the ability to write the report output to a file in addition to writing it to the screen. This solves the problem where PHP_CodeSniffer comes across some code it cannot parse and throws PHP notices before XML output, creating invalid XML. Writing to a file is easy; just use the --report-file=filename command line argument.

All these features are currently in CVS and will be released in 1.2.0a1 very soon.

PHP_CodeSniffer and JSLint

PHP_CodeSniffer has had integration with JavaScript Lint for a while, but I recently found out that the excellent online JavaScript verifier, JSLint, can be run from the command line using Rhino.

I've just committed the JSLint sniff into the Squiz standard under the Debug category. The sniff requires you to have jslint.js on your server and rhino installed on the same machine as PHP_CodeSniffer and you need to tell PHP_CodeSniffer where to find it.

$ phpcs --config-set jslint_path /path/to/jslint.js
$ phpcs --config-set rhino_path /path/to/rhino
$ phpcs --standard=squiz /path/to/file.js

Like JavaScript Lint, not all errors and warnings need fixing, so all messages reported by jslint.js are warnings within PHP_CodeSniffer and can be hidden easily.

Interface design; an interative process

I was looking back at some old mockups and screenshots of the MySource Mini today and it is really amazing to see how the product's interface has progressed over the last 12 months or so. It's interesting to see how elements of the design changed, and while not all these mockups were built, all contributed something to the design we have today.

In this post, I'm going to show you the mockups we produced of the Settings/Administration interface. This is where you configure things like designs and caching for individual assets and for the site as a whole.

This first mockup was implemented in early 2007 and represents the first interface of the MySource Mini. We went for a desktop feel with large icons, but it gave us very little space to fit the actual editing interface. We still love large icons, and the concept of icons to represent different systems remains today.


It was soon clear we needed more space for the editing interfaces, so we went full screen. That meant sacrificing the large icons we loved so much and moving to a toolbar along the top, a concept that remains today.


The start of 2008 saw us bring on a dedicated interface designer who began reworking the main concepts of the interface. At the time, the inline content editing interface was progressing well and we wanted to bring the context you get from that interface into the settings screens. So we scaled back from full screen a little so you could see the page underneath.

This mockup was done in January 2008 and implemented soon after. It was the first time we really tried to bring that context into the rest of the interface, which we have now done using thumbnails of the page. Notice the side menu, which is almost identical to the current multi-add wizard interface.


One thing that always bothered us with this temporary interface was how dark it was. We didn't want to go for the desktop-inspired background image from the earlier mockups, but we wanted something lighter to contrast well with the black MySource Mini toolbar.

This mockup was done in March 2008 and was not implemented. It was used in most of our mockups for quite a while and was growing on us. It was light and looked fresh. It didn't have large icons, but the chunky menu buttons made up for it.


There was one thing lacking though; context. We needed somewhere to put our thumbnail and asset information.

This next mockup was very close to being the final interface. It was designed in May 2008 and implemented, although all the system icons were the same at the time. It is the first time the blue info box made an appearance, which gave us room to add a thumbnail and asset information.

In this mockup, an administration screen is shown, so the blue box does not contain asset information, but you should be able to see how we jumped to our final interface design from here.


In August 2008, we changed our minds again. The grey bar at the top was looking too much like a second toolbar and didn't feel polished enough. The whole interface was looking a bit too much like an old desktop application and we wanted something fresh.

We decided to lighten everything up and add the large icons back in. We had heaps of room for the content editing area, so we could go very web 2.0 with large menus and bright colours.


I've promised the team that I wont change my mind again, so this is the interface we will be using in the final MySource Mini release. I'm sure you'll agree it is a big improvement over our original interface and I hope you've enjoyed this small insight into our interface design process.

MySource Mini demonstration

Update: After being featured on Ajaxian, Vimeo decided they don't want to host my videos any more and deleted my account without warning. I've re-posted the 30 min demo below, but be warned - it is 117MB!

I recorded the 30 minute demonstration of the MySource Mini that I gave at the MySource Matrix International User Conference a couple of weeks ago. I've posted the demonstration online so everyone can check out this new product from Squiz, even if you couldn't make it to beautiful Coogee for the conference this year.

PHP_CodeSniffer == CSS_CodeSniffer?

Earlier this year, I added support for tokenizing JavaScript files to PHP_CodeSniffer so developers could ensure their JS files also conform to their coding standards. With new products like the MySource Mini using such rich JS interfaces, PHP developers are having to move away from traditional server-side coding improve their client-side coding skills. Having JS support in PHP_CodeSniffer was a move to recognise this and we are now using it very successfully within Squiz to check for formatting and performance errors.

The next natural step was to add support for checking CSS files. These same PHP developers are having to write large amounts of CSS these days and, in my experience, CSS files tend to be fairly messy when a large number of developers are working on them. To counter this, I've added a basic CSS tokenizer to PHP_CodeSniffer and the Squiz coding standard now enforces formatting standards such as indentation and spacing around colons.

Sniffs can be written to improve the performance of both PHP and JS code and the same is true for CSS files, although it works a little differently. One of the sniffs in the Squiz standard ensures that shorthand notation is used to define CSS colours where possible (e.g., #F0F instead of #FF00FF). This helps to ensure developers focus on keeping the size of CSS files down, even though we will certainly minimise the size before deployment. I think PHP_CodeSniffer helps to remind developers of these performance issues each time they run the checker, which can only be a good thing.

I've committed the CSS tokenizing code to CVS, so you can grab it directly from there or wait until the 1.2.0a1 release in the next few weeks.

MySource Mini hands-on at the MMIUC 2008

The MySource Matrix International User Conference for 2008 finished up just over a week ago. On the final day, I gave a 30 min live demonstration of the MySource Mini, which was followed by an afternoon of hands-on demonstrations with conference attendees on three test systems we had made available at the conference.





We all use Macs for development, but rest assured that the MySource Mini will work on Windows and Linux as well!

The whole MySource Mini team was available to walk people through the product and answer questions about both existing and upcoming features. The test systems were very popular and the developers kept busy throughout the afternoon.







Congratulations to the whole MySource Mini team for producing such an amazing product and for being such fantastic instructors on the day. The Mini was well received and plenty of people are looking forward to its release in March next year, so get back to work!