PHP_CodeSniffer 1.0.0RC3 released with tab support

I've just released the third release candidate of PHP_CodeSniffer. This release contains a few bug fixes, some changes to the Squiz coding standard, and a great new feature to provide support for tab-indented files.

In the past, my standard response to people asking for PHP_CodeSniffer to "support tabs" was to say that PHP_CodeSniffer doesn't do anything to stop you writing standards that use tabs, but the default sniffs that come with it don't support them. But that response also alludes to the fact that PHP_CodeSniffer doesn't do anything to help you if you happen to be using tabs. That has now changed.

PHP_CodeSniffer has a new command line argument --tab-width=4 that will replace tabs inside a file with the number of spaces specified (4 in this case). There is a bit of code checking that tabs are replaced with the correct number of spaces (tabs do not always equal exactly the tab width) so it is not just a straight string replacement. That means there is a bit of additional overhead when checking files, but I don't think it is noticeable.

The benefit of using this option is that you can use all the existing sniffs to check your code and they will not produce errors about tab indentation and alignment. By the time the code gets to them, all tabs have been replaced. This makes it easier to generate your own standard using existing sniffs, and makes it easier to write sniffs as you don't have to take both indentation methods into account.

Of course, you don't have to use this feature. You can still write your own sniffs that explicitly check for tab indentation and alignment.

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

International PHP Conference 2007

The International PHP Conference has come and gone for 2007. Gergely Hodicska has an IPC 2007 "megapost" listing quite a few of the talks with links to the presentation slides. It was good to see that PHP_CodeSniffer was mentioned in a couple of the sessions:

• Tales from the eXtreme side by Lars Jankowfsky
• PHP Tools and Automation by Stefan Priebsch

Unique lock tokens in MySource4

We've recently moved onto designing the new MySource4 locking system. My work on locking during the WebDAV development lead me to the idea of unique lock tokens, which I had not previously considered for the locking system. I never saw a real need for lock tokens to be unique each time a lock is acquired on a resource, but now I have.

In MySource Matrix, each lock you acquire has a unique system-wide lock token that comprises of the asset ID and a lock type (e.g., attributes or linking). Each time that lock is acquired, the same lock token is generated.

MySource4 uses an alternative system where the lock token is always unique over time by using a UUID. This means that when you acquire a lock, MySource4 will give you this lock token and you will need to supply it back to MySource4 when you save. These lock tokens are very random and cannot be guessed. This is the same way WebDAV clients work.

The real difference in these two systems is trust.

In MySource Matrix, if you are logged in as the same user that acquired the lock, you can use that lock to save content. You do not need to supply a lock token so you can log into two different browser sessions and happily lock and save content in each.

In MySource4, if you acquire a lock in one browser, you cannot reuse that lock in another. The editing interface (acting as the client here) has to send the unique lock token back to MySource4 to save the content. The editing interface in the second browser will not know the correct lock token, and so the save will fail.

That's really all behind the scenes, and users don't need to worry about that when they lock content. In fact, users never have to explicitly lock content in MySource4, so even though the locking system is more complicated, the end-user experience is greatly simplified. It does stop one important conflict from occurring though; two editors logged in as the same user overriding the content of the other.

Although it is highly discouraged, editors will sometimes log into the system using the same username and password. Even worse, this can happen with the root account. When this happens, the locking system has no way to differentiate between the two editors, and so the locks of one become the locks of the other. This can lead to a situation where both editors are editing the same content at once and the last one to save wins.

In MySource4, once the first editor locks a piece of content, the second editor will see the content as locked because they do not have the correct lock token. So even though these two editors are logged in as the same user, they are treated as different users by the locking system.

This small change will lead to less chance of editing conflicts, including any editing that might take place in a replicated editing environment.

CruiseControl and PHP_CodeSniffer

Manuel Pichler has written a nice article about how to use PHP_CodeSniffer in the continuous build system CruiseControl. He uses PHP_CodeSniffer's XML output format and transforms it into a format that the Checkstyle Ant task can use. To quote:

This PEAR package provides a variety of pre defined coding standards like PEAR, ZEND etc., a small cli script phpcs to run PHP_CodeSniffer against your code and as best it provides an XML output generator. This output is not compatible with checkstyle but it is simple to transform into the Checkstyle format that is supported by CruiseControl. You can use the following stylesheet to transform the PHP_CodeSniffer output for your CruiseControl installation.

Manuel provides the complete XSLT and commands for transforming the XML, as well as the Ant build file. I gave the transformation a go myself, which turned this:

<?xml version="1.0" encoding="UTF-8"?>
<phpcs>
 <file name="temp.php" errors="5" warnings="0">
  <error line="2">Missing comment</error>
  <error line="13">Missing tag</error>
  <error line="13">Missing tag</error>
  <error line="13">Missing tag</error>
  <error line="13">Missing tag</error>
 </file>
</phpcs>

Into this:

<?xml version="1.0" encoding="UTF-8"?>
<checkstyle>
  <file name="temp.php">
    <error line="2" severity="error" message="Missing comment"/>
    <error line="13" severity="error" message="Missing tag"/>
    <error line="13" severity="error" message="Missing tag"/>
    <error line="13" severity="error" message="Missing tag"/>
    <error line="13" severity="error" message="Missing tag"/>
  </file>
</checkstyle>

(error messages shortened to fit)

Creating a new report format for PHP_CodeSniffer to match Checkstyle would be easy, but I haven't managed to track down any good examples of Checkstyle's XML output yet. I've put that on my todo list.

Making Ajax Work with Screen Readers

I recently came across this article about Ajax and screen readers. To quote:

The Web Accessibility Initiative's Protocols and Formats working group directly address the issue of making rich Internet applications accessible, and we borrow some of their concepts to investigate methods of ensuring that Ajax applications work with leading assistive technology products.

The article does more than just offer helpful hints. It also explains some of the inner workings of screen readers to help web developers understand why the techniques are required. A couple of Ajax form examples are also provided.

All PEAR packages now checked with PHP_CodeSniffer

Thanks to some great work by Christian Weiske, PHP_CodeSniffer has been added to the PEAR QA framework. So now, all package developers can visit the PEAR QA overview page and see how many coding standard errors and warnings they have in their package.

Here is the full announcement:

Hello all you pear developers,

Our quality assurance suite now utilizes our great package PHP_CodeSniffer to generate reports about each package's coding standards compliance.

You can get the full overview at
http://pear.cweiske.de/overview.htm
Just click at the CS error/warning count to get a detailled listing of problems in the package.

Please also note that we're currently evaluating to extend and clarify the standards. See my last email to this list or http://wiki.pear.php.net/index.php/CodingStandardsChanges

As always, comments are very welcome.

I'm also pretty happy that someone has decided to review the PEAR coding standards, as there are a few gaps that need to be filled in and some conflicting standards that need to be clarified.

My Squiz Story

I read a question on LinkedIn about "Your Story". It got me thinking about what I have achieved so far, so I've decided to write it down. Some of the specifics might be a little off, but here is "My Story" so far.

---

I started at Squiz in December 2001 after 2 years of a computer science degree at UTS. That particular degree encourages students to work full-time during their third year and come back to complete the 3-year degree in their fourth year. I have to admit that I was pretty nervous about going out into "the industry" after only 2 years of computer experience, but it turned out to not only be a great career move, but also helped greatly during my final year at uni.

I had been playing around with a personal web site and loved the idea of working with/on the internet full-time, so the job description for Squiz was very appealing. Both my (now) wife Deb and I went for the 2 positions being offered by Squiz, as did a lot of other UTS students. After two interviews, I was offered a position. Deb missed out, but ended up getting a .NET job a couple of months later. Incidentally, she now works as a senior trainer and documentation writer at Squiz. The other position was given to Daphne Chong, a mate from uni, so that eased the nerves a little.

During my second interview I was introduced to "Agi", who I assumed (by the name) was a burly seasoned Eastern European development lead. Steve "Agi" Agland was actually a skinny young PHP developer still completing his computer science degree at UTS. Agi was to become someone I learned the trade from, a good friend, and eventually best man at my wedding.

At the time, Squiz was a small company of about 20 people. Everyone worked at "the church" on Jarret street and there was only one office; Sydney. I was one of about 6 developers who not only wrote the code for the CMS, but also did all the implementation and provided client support.

On my first day, I was given the task of cutting up a design (the first of many). That involved taking a PSD file, determining the table layout (it was the bad old days of table-based design), cutting out the individual images for the cells, and coding the HTML. I had one problem; I didn't know how to code a table in HTML.

My complete lack of HTML knowledge wasn't all; I had been "coding" in PHP for 2 weeks. I had done Perl before, but I was employed to work on a large PHP Content Management System (MySource) which involved writing a lot of PHP and HTML.

Luckily for me, I was paired with a great teacher; Blair Robertson. Blair had started at Squiz the year before, also during his 3rd year of a UTS computer science degree. I remember watching him show me how to cut up this design and thinking to myself "how can this guy be so good after just 12 months?".

Blair was certainly someone to look up to and I aspired to be as good as he was. When I finally got my hands on MySource, then still reporting a version number of 0.85, I tried my best to learn it inside-out. I went home (a 2 hour trip) and worked on it all night. My greatest achievement at the time was adding colspan support into the bodycopy. I remember porting the code to Matrix a couple of years later and still being challenged by the code.

I ended up doing a lot of work on MySource, and became a more senior developer at Squiz. Eventually, it was decided that our page-based CMS needed to be upgraded to an asset-based CMS, and as the most senior full-time developers (Blair had left to go back to uni part-time) Agi and I started work converting MySource. After a few weeks, we had files working as assets, but it had become clear that we needed to start from scratch.

A meeting at JP's apartment between Agi, Blair, JP and myself reached a conclusion that we needed to start work on a new asset-based product, which was to become MySource Matrix.

Blair came back to Squiz full-time in 2003 after completing his degree. He was tasked with creating MySource Matrix, and was the only developer assigned to the project initially. I had decided to stay at Squiz full-time and complete my degree part-time over the next couple of years. That decision turned out to be a good one. A couple of months later, I started writing the MySource Matrix WYSIWYG editor and eventually started working with Blair full-time on MySource Matrix, which was one of the best experiences I have had at Squiz.

On a side note, MySource Matrix was originally named Mortar (as in "bricks and mortar") by Blair. When I started on the project, we renamed it to Resolve (a name I still love). JP and the sales team decided that Matrix was the name we were to use, which didn't sit well with Blair and I. In fact, we hated it so much that we used "MySource" in all design area tags instead of "Matrix" (they were original "Resolve" tags) and changed the version tag to "MySource v0.1.1 (Matrix)". We put "Matrix" in brackets because we were treating it as a build name and decided that we would change it with each major release. That obviously didn't happen. Later, after renaming the product to Resolve FX (at Norton's pub one night, and in our head's only) we put a hidden code into the asset map that changed the MySource Matrix logo to a Resolve FX logo.

Eventually, our two-man team turned into four as we added Marc McIntyre and Dominic Wong to the team. Squiz was really starting to expand at this time, and we were shifted into the back-room of "the church", which is now the training room. Just before Blair left to move to the UK and help start the office there, we took a famous picture that marked the day we finally embraced our new product name. The picture depicts the four Matrix developers posing in dark glasses behind a backdrop of code from the Matrix movie. Each of us signed the picture with our favorite Matrix quote, except for Blair who couldn't help writing something about the pub. I've still got the framed picture on my desk.


From left to right: me, Blair, Marc, Dom
Click for larger image
Blair leaving moved me into the lead developer role at Squiz (Agi had left to work on the movie Happy Feet with Animal Logic). Squiz grew around the new product, starting our support and implementation teams, and eventually moving into other Australian states. The dev team moved to a new office on Elswick street, just down the road from "the church", which we quickly outgrew. We traded that office in for one on the other side of "the church", which is where the majority of Squiz staff in Sydney now work.

Just before leaving the Elswick street office, Marc and I started thinking about a new product; MySource4. We had a lot of great ideas based on the years of CMS experience we now had, and finally convinced JP to start a new project team.

We assembled a team of the four best Matrix developers and started work on MySource4. Marc was the team leader and I was the project lead. I worked with Marc on the system architecture but left the coding up to the other three. I was still leading the Matrix team, so I was pretty busy during that period. I was also unit head of the development team, so I had to start doing all those managerial tasks like approving leave, performing pay reviews, and hiring new developers. That was about the time I stopped doing any real PHP development.

I had started PHP at the end of 2001 and had stopped by 2006, only four years later. I was still going to be doing some work on development tools, like our unit testing and code sniffing software, but my full-time PHP role was over. It took some getting used to.

Everything kept ticking over until the present day. Squiz is going strong, MySource Matrix is going strong, and MySource4 is well on the way to becoming a revolutionary CMS (and PHP) product. I finally graduated from UTS in 2005 with a Bachelor of Science in Computing Science and 1st class honors. Marc and I started PHP_CodeSniffer, which was accepted into PEAR in 2006. I still work on PHP_CodeSniffer regularly to keep my PHP skills current, and do some work on MySource4 itself. I'm still the lead developer of MySource Matrix and am now Product Development Manager at Squiz. Deb and I got married in 2006 and are expecting our first child in January.

I'm looking forward to the future.