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.

Obscure software bugs always come in pairs

Well, for me anyway, and in MySource Matrix in particular. I don't know what it is, but obscure bugs get reported to me and shortly after I have a fix, I will be fixing the bug on one or two other systems. Yet this bug may have been in the software for years and may be extremely hard to replicate. This has been happening more and more; I think it has been three or four times in the past 12 months, which is just strange.

The strangest case is a bug in a trigger condition that was caused by the way PHP converts strings to numbers. I was so surprised we had never previously encountered the problem that I wrote a blog post on the issue. The night I wrote that post I also committed a fix to MySource Matrix. The very next day I was asked to diagnose a strange problem on another client's system with triggers. The fix I committed the night before also fixed this client's problem.

The latest case reared its head again just today. About a month ago we diagnosed and fixed a strange problem that was caused by IP addresses changing and logging a user out of MySource Matrix during the multiple requests made on the frontend (HMTL, CSS, JS etc). The session is destroyed if you get logged out, but the code that loaded a serialized class didn't first include the class file. We fixed that bug. The next week I diagnosed the same bug on another client's system. Last week I received a support ticket for the same issue. And just today I diagnosed the same problem on a system undergoing implementation. The strange thing is that we have always had systems where users have their IP changing and yet we've never seen this error.

I don't get this so much with PHP_CodeSniffer, although I do tend to fix bugs in CVS only to have someone report it via the PEAR bug tracker. They are not as common or obscure though. Perhaps the size of the project directly relates to the incidence of these sort of bugs.

I think everyone hears that these sort of things happen, and not just with software bugs, but it is still amazing to see how often it occurs.

Rating content and calculating average ratings in MySource Matrix

A new feature was released in version 3.16.6 of MySource Matrix that allows you to calculate an average rating for content based on the comments and ratings users have made. The average rating is calculated as comments are created (or approved, it's up to you) and then stored in a metadata field. This field can then be used to sort pages based on their average rating.

Adding this feature to an existing comment system is fairly easy, but I'll just run through the basics of building a comment system first.

I've built a basic site with two standard pages. Both pages have a paint layout applied that nests in an asset builder and an asset listing that are used to create new comments and list existing ones. The general idea here is that every page will have a form that users can use to create new comments and apply a rating. Under the form will be a listing that prints the current comments and the ratings users applied to them.

The home page with a couple of comments and ratings

Asset Builder

The asset builder is configured to create comment assets. In my case, I have made them Live by default, but you could choose to create them as Under Construction so you can moderate comments. On the Create Locations screen, I have configured an Additional Create Location to create the comment asset under the current asset. I've made the links TYPE_2 so they are not shown in menus.

The bottom of the Create Locations screen, showing the additional create location

The create form for comments has been customised (bottom of the asset builder's Details screen) so that the rating can be added when the comment is created. I've also renamed Title to Subject.

The contents of the Comment Create Form Layout asset

Asset Listing

The asset listing is configured to list comment assets. The root node is set as the site asset, but this will be replaced dynamically by the current asset. Direct links only is set to Yes and there is a dynamic parameter set to replace the root node with the current asset's ID.

I've customised the No Results bodycopy to print a message encouraging users to post a comment and I've printed the rating as both a percentage and as a star rating in the default type format.

The contents of the Default Format bodycopy

Paint Layout

I've nested the asset builder and the asset listing in the default type format. Be sure to nest the asset builder first otherwise new comments will not appear until the next page refresh. This is obviously not a problem if you are moderating comments as they will not appear until they are approved.

The contents of the Default Format bodycopy

Adding Comments

Once the paint layout is applied, users are presented with the following form:

The home page before any comments have been added

Once they have added a few comments, we can start to work out the average rating. The image on the left shows two comment assets under the home page. Both are TYPE_2 linked so they don't appear in menus. By linking comments directly under each page, we can easily list them using a dynamic root node. If you are moderating comments, you may find it easier to create an asset listing of all Under Construction comments under the site with a link to their Simple Edit interface rather than manually looking for comments under pages.

Calculating Average Ratings

Now that we have our standard commenting system created, we can implement the new average rating functionality. All we do is apply a metadata schema to the assets that are rated and ensure there is a Text field in the schema in which to store the average rating. Then we create a trigger that sets the average rating when a new comment is added.

The metadata schema I have created is shown below.

This metadata schema contains a single section and Text field

Make sure you set a default value (e.g., zero) so that unrated content gets a default rating.

The trigger I have created is shown below. Remember to enable triggers on the Trigger Manager Details screen.

The trigger to calculate average ratings

Once this trigger is enabled, I added a new comment to the page to force the trigger to run. I now have three comments with three different ratings; 20%, 40% and 80%. Once the trigger has fired, the value 46 has been entered into the Rating metadata field for my page. Note that the rating has been rounded down so that an asset with a rating of 99.6% is not rated at 100%.

The metadata screen of the home page

Now I can configure an asset listing to show the most popular pages in my site. This asset listing is configured to list standard pages under my site and is sorted by the value of the Average metadata field. The Default type format is configured to print the asset's name and the average rating and I've limited it to 10 assets per page.

The asset listing of the most popular pages in the site

The rating is just a percentage, but you could get tricky with JavaScript and use the values to prints stars and other graphical elements. Just remember to put a textual value in there somewhere to ensure it is accessible.

And that's it. You can use this average rating anywhere you normally use metadata, including sorting search results. And of course, this is MySource Matrix so you can configure all the frontend interfaces shown here in any way you want.

Aleks Bochniak writes... How to make a tag cloud (using Matrix)

Apart from being better at Matrix implementation than me by building his blog using MySource Matrix, Aleks has also written a great tutorial on how to build a tag cloud using Matrix. He uses metadata for tagging, an asset listing to show the tags and some JavaScript to make the magic happen.

Well worth a read if you're looking to implement a tag cloud on your own site, or if you just want to see an example of different parts of Matrix coming together to produce something beyond what they were designed to do.

MySource4 caching and keywords - I think I'm in love!

Sometimes things just fall into place.

When designing the sub-systems for MySource4, even when designing seemingly basic copies of MySource Matrix functionality, I often find myself surprised by the way we've managed to make slight design changes (often forced by the MySource4 architecture) but come out with systems that are significantly better than they are in MySource Matrix. Sometimes, design decisions made months ago suddenly start to pay off in ways I don't expect. The caching and keyword systems are a perfect example; they are a match made in heaven and I'm deeply in love with both of them!

Caching was to be a fairly simple copy of the MySource Matrix caching system. One of the strengths of MySource4 is the ability to replace core systems (like caching) with a system that is better designed for a site's specific needs. Knowing this, we started thinking about a basic caching system that Matrix users could migrate to easily, with plans to write other caching systems and allow users to pick the one they wanted. What we ended up with is something I am very proud of. Not only because of the feature set, but also because of the way it fits so nicely into my MySource4 vision. This is why we designed MySource4 like we did, and it is really starting to pay off.

The MySource4 caching system is made possible by a simple but critical change to the way content is printed. In MySource Matrix, each asset type and design area grabs attribute values from the database and prints them when required. When designing the keyword system (very early on) we made a decision to always print keywords rather than real values. So instead of a menu printing asset names and links, it would print keywords that would later be replaced by the keyword system. This provides two immediate benefits; assets and design areas take less time to print and keywords can be batch replaced in a page. Both those are performance-based, but now that decision has enabled us to make a fantastic caching system.

By utilising the MySource4 channels architecture, the caching system is able to hook into the frontend painting code and cache a copy of the page after static keywords have been replaced and before dynamic keywords have been replaced. Dynamic keywords are things like the contents of a custom form or the name of the current user, and should not be cached. The next time around, the caching system can serve up a copy of the page with just the dynamic keywords left to be replaced. Note that this is a full page cache, unlike Matrix which constructs the page each time using small cache blocks. That means that the MySource4 caching system is already faster than the MySource Matrix caching system and we haven't even got to the bonus features!

One of the biggest problems with the Matrix caching system is that we can never really know which assets are cached on which URLs. For example, we know that the name of the "Contact Us" page has changed but we have no idea which asset listings to clear the cache of or which pages have the old page name in the menu. We can't know this in Matrix because we don't have a consistent way of printing data. That is solved in MySource4 because the keyword system forces us to print keywords rather than real data. The result is that the MySource4 caching system knows exactly which URLs the name of the "Contact Us" page appears on and it can clear them for you.

That is a very powerful feature. You can now go to any asset and see exactly what parts of the asset have been cached and which URLs they are cached on. You can make an informed decision about clearing the cache; do you really want to clear 400 URLs because the name of the "Home Page" has changed?

We also have some other statistics that we are trying to decide how to use best. We know how many times a page's cache has been served and how many times it was generated (cache hits and misses). We also know how long each page generation took (on average), the static keywords used on the page and the dynamic keywords used.

We can obviously calculate how much time was saved by the caching of a page by looking at the hits and misses. That is a nice figure to have available, but it's not going to really help you in any way. So we thought about looking through the cache data and showing you how much performance improvement can be gained by removing a dynamic keyword. For example, we could calculate the time saving gained by removing the name of the current user from the design. Those sort of figures can help you modify your content and designs to improve performance.

I'd love to hear any suggestions for other ways these statistics can be used. Please leave a comment if you have some ideas.

MySource Matrix 3.18.0 RC1 released with PHP5 support

MySource Matrix 3.18.0 RC1 was released today; the first release that supports PHP5. It's been quite tough moving such a large project from PHP4 to PHP5 for a couple of reasons.

Changes to reference handling has been a big one. We've been changing so many lines of code to fix E_STRICT reference errors that we inevitably end up with some variables being copied rather than passed by reference.

Moving from PEAR::DB to PDO has also been a big deal. Not only have we moved to PDO, but we've also moved to the MySource4 DB abstraction layer, called DAL. DAL gives us the ability to write a single XML-based query for both Oracle and PostgreSQL, and native support for bind variables (an often requested feature). Learning the differences in syntax between PEAR::DB and DAL took time, as did DAL changes that were required to support the more complex queries that Matrix contains. In the end, we have a better, faster and more flexible DB abstraction layer that will see Matrix through until the MySource4 release and beyond. We also get the added benefit of testing such a key component of MySource4 in the real world.

On a more personally note, the large number of changes and testing required for this release got me more involved in Matrix development than I have been in a few years. Instead of sitting back and watching, I had enough time to dig in and convert part of the core, some packages and the unit testing system.

Speaking of unit testing, I couldn't imagine going through a process like this without an extensive unit test suite and some dedicated testers. Day-to-day, it is easy to forget why you write tests as you rarely get failures if you are careful enough. During a large core change like this, using the failing tests as a todo list gives you some guidance and, of course, confidence in your changes.

Besides PHP5 support, 3.18 has a couple of new features and improvements, some from the feature bazaar at the MMIUC 07. Many of the improvements are performance-based, with HIPOs and paint layouts getting special attention. All performance improvements in 3.18 have been road-tested in MySource4 first, so even though MySource4 has not been released, MySource Matrix users can be confident that they are benefiting indirectly from the project even at this early stage.

MySource Matrix 3.18.0 RC1 is not ready for production, but you can download a copy of the GPL version to give it a test on PHP 5.1.6 and PostgreSQL. Grab it from the MySource Matrix download page.

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.

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.

University of Malta chooses MySource Matrix

An article came through on one of my Google Alerts last week about the University of Malta using MySource Matrix to rebuild their web site. At the time, the new site was still undergoing final testing, but the University of Malta has now made it live.

The site looks fantastic, but it's also special for me as my mum's side of the family are all Maltese. I've never been to Malta, but I've seen some amazing pictures from my mum's recent trip back that make me hope I get there one day.

Congratulations to everyone involved in building another great MySource Matrix site.

MySource Matrix User Conference 2007

I've just returned from the first MySource Matrix International User Conference, held on the Gold Coast. I presented two talks at the conference, including the first public preview of MySource4. Being the first conference, nobody was really sure what to expect, but overall I really enjoyed the conference and got a lot out of it.

Obviously, I was mostly focused on the preview of MySource4, which went pretty well. I was a bit worried that we wouldn't have enough to show, but the focus on the inline content editing interfaces, including our new WYSIWYG editor (Viper), was pretty much all I could get into the 45 minute presentation anyway. With the preview past me, I'm really looking forward to digging back into the product and shifting focus onto some new interfaces, including configuration screens and design editing.

The conference had a few case studies from MySource Matrix users, which was a really great thing to see. It's been over 3 years since I first started work on Matrix (it must be close to 4 now) and I've been removed from end-users for most of that time. I only really deal with the specification phase, clients that are having problems or clients with large amounts of development. It was great, really great, to see people who have used Matrix to improve their business, and to talk to people who really love it. I particularly liked reflecting on the Tourism Tropical North Queensland project (presented by Angus Sprott) and seeing the Australian Sports Commission system (presented by Pat Birgan) that I've only ever read about in emails.

The presentations I was really looking forward to were "Website Accessibility - Can you buy your own can of beans?" from Bruce Aylward and particularly "Access to websites - how design makes all the difference" from Neil Jarvis. Watching Neil use a screen reader to navigate websites was an eye-opener. You can't understand the reasons why you strive for accessibility without seeing how it affects the user, and that goes for application developers as well. I had a chat with Bruce after the presentation and spoke about the ways in which a JavaScript-rich web application like MySource4 can be made accessible. It's certainly possible, providing the development team is committed to the goal and understand what they are doing and why they are doing it. I'm very confident that MySource4 will be an accessible web application; one of very few.

Congratulations to everyone involved with the conference and thanks to everyone who attended and made it a great couple of days.

Computerworld: Testing times for slack software development

I've been quoted in a recent Computerworld article entitled Testing times for slack software development. Answering the questions for that article gave me time to reflect on the improvements to testing that I've implemented at Squiz and what I still have left to do. I thought I'd post the questions I was asked and my responses with a bit more of an explanation for each.

Is it important to retain software testing in-house? Why?

For the testing we do, I believe it is. We know our product best, and we know how our clients use it and what they are most concerned about. We tailor our tests and testing frameworks based on that knowledge. MySource Matrix is highly complicated, especially when you consider the interactions between different parts of the system, so testing only the surface functionality is never going to be adequate. We need testers who know all the weird and wonderful ways our software can be used.

I'm sure outsourcing testing is a viable solution for plenty of software products out there, but it's not for a product like MySource Matrix. Some software products are designed with a clearly defined set of functions they must perform. It is very easy to write test cases for those products based on the original specification. A product like MySource Matrix is designed to allow complex interactions between its modules. Essentially, the product is designed to be used in ways that we have have not dreamed of yet. For this kind of product, implementation experience is essential for designing test cases, and that is something that a 3rd party testing company doesn't have.

The survey claimed the automation of software testing is low - do you agree? Why/why not?

Automated software testing tools are available for almost every programming language. Open source products are notorious for being badly tested, but unit testing (at least) has really grown in popularity over the last few years. So I'd say this problem is getting better.

From my experience working with other organisations, automated testing is rare. You often here about testing teams developing "test scripts" but the name is sometimes misleading. Ideally, a suite of test scripts is something that can be run over a product without user intervention, allowing for automated testing before rolling out each new product update. Often, test scripts are simply a set of steps that need to be manually performed by a tester, and the results recorded. This leaves the testing process open to human error. If your testing is not automated, you cannot guarantee that your test results are accurate.

A survey claimed 85 percent of defects in software projects originate in the requirements phase - do you agree?

For Squiz, I don't think this is correct. In my experience, software defects creep into the product during the system architecture design and development phases. Maybe we do the specification phase differently?

This figure of 85% is useless without knowing how the researcher defined the word "defect". If a defect is classified as a failure of the product to conform to the requirements, which is how I would roughly define it, then the only defects produced in the requirements phase and going to be conflicting requirements. While I've seen my share of conflicting requirements, a figure of 85% is certainly too high.

I see most defects during the development of new functionality and the maintenance of existing functionality once a product has been released. The first version of a product should have the least amount of defects, increasing over time based on the amount of additional development performed on the product. The first version of a product has the least number of features and those features tend to be very well tested by their creators. Of course, corporate reality sometimes kicks in and forces a product release before it is ready, so that statement doesn't always hold true.

Fixing errors in the post-implementation phase is 100 times higher than correcting bugs during development - do you agree?

When you consider the time it takes to upgrade and test a client's system after a bug fix, it's easy to see that post-implementation bug fixing is significantly more costly than bug fixes made before the product is released to users. Is it 100 times more costly? That depends on how many client systems you have out in the wild with the bug and how those systems are patched.

I'm not sure where the figure of 100 came from, but I certainly can't dismiss it. It's very hard to qualify just how much more expensive bug fixes are post-implementation but it should be obvious to any software vendor that it's worth putting in the time to detect and fix as many bugs as possible before a release. Not only is it far cheaper, but it also increases client satisfaction, and that in itself saves money.

How can the quality of software testing be upheld?

The quality of software testing is like everything else; you need to measure the effectiveness and constantly improve your processes. Each organisation needs to find some metrics that suit their product (e.g., code coverage, DB performance) and then measure them constantly as the product changes during the development phase. A process needs to be in place to identify undesirable changes and rectify the product. I believe that automation is the best way to ensure consistent quality of testing.

This really sums up what I have been trying to do at Squiz. Both unit testing frameworks I developed at Squiz had metrics built in from the beginning. Simply knowing that your tests are passing is not enough. You need to be constantly increasing the coverage of those tests and ensuring that new code is not adversely affecting the performance on the product.

The best example I have of this was a few years ago when I introduced an assertion class into MySource Matrix. Developers were able to assert that function parameters were valid before using them, allowing us to use a design by contract methodology. The problem was when to stop validating input. One core function required a DB query to validate its input, which was later found to be incredibly slow. We found this problem through the performance metrics built into our testing framework. When all your tests start reporting increased running times, you know you've made a mistake somewhere.

So where to next?

For me, it's interface testing. Testing interfaces is tricky, but there are now tools to make the job easier. For PHP, the integration between PHPUnit and the Selenium RC server (using the Testing_Selenium PEAR package) can't be beat. Selenium is easy to write test scripts for (you can record them in Firefox using an extension if you want) and the PHPUnit integration makes incorporating these scripts into your existing framework easy.

I'm looking forward to implementing a new testing framework that will allow Squiz to move beyond traditional unit testing and into an area more like functional and user acceptance testing, which has always been tough for browser-based applications.

What is inline content editing?

Update: Squiz decided to tackle this problem and we've created our own truly inline WYSIWYG editor called Viper. You can find out more, and watch a video of it in action, on the MySource Mini inline editing feature page.

A lot of products claim to have inline content editing, but it's obvious that everyone has their own interpretation of that phrase. Inline content editing seems to come in six main flavors, although I've yet to see a true inline content editing interface.

Stand-alone WYSIWYG editing

This style of content editing displays a stand-alone WYSIWYG editor embedded into an editing interface. The editing interface and the site frontend have no common elements. The WYSIWYG editor takes the styles from the site's style sheets and displays them inside the WYSIWYG editor. This allows the page author to see their content as it would be displayed on the page, but they cannot see how the content will look when the other page elements are placed around it. Generally, a preview is provided to allow the author to switch between editing and previewing the content.

The MySource Matrix administration interface uses this style of inline editing. The content editing screen and the preview screen are accessed separately, but the site design's styles are shown while editing in the WYSIWYG editor.

The advantage of this style of editing is that the author has a large area in which to edit content. The disadvantage is that the author cannot see how their content will flow inside the page without saving their work and switching to a preview.

Embedded WYSIWYG editing

This style of content editing is similar to the stand-alone WYSIWYG editor, but this style places the content items around the WYSIWYG editor so the author has an idea of how the content will fit with the overall style of the page. This inline preview is limited though. For complex pages with multiple content areas, the WYSIWYG editor itself changes the page layout and makes the inline preview less accurate. The author still requires a preview mode to confirm that the page looks the same as it does during editing.

The MySource Matrix simple edit interface uses this style of inline editing. The editor is the same as that in the administration interface, but the size is now the same as the content area and the site's design is shown around the editor. IP.Board also uses embedded WYSIWYG editing in their new quick edit forum post editing interface.

The advantage of this style of editing is that the author can see quickly how the content of the page will look within the site's design. The disadvantage is that the editing area is often smaller, resized to fit within the body area of the page. Some editors provide a full-screen mode to get around this size limitation, but that transforms the editing interface into a stand-alone editor, with all the disadvantages that brings.

Popup WYSIWYG editing

This style of content editing was made famous by RedDot. Content areas within a page preview are marked as editable using an icon that floats over the content or some other obvious style. Clicking that icon displays a stand-alone WYSIWYG editing interface. Once the content is saved, the new content is written back to the page preview.

For a good demonstration of this style of content editing, take a look at this inline editing demo video for Community Server. The first part of the video shows true inline content editing with text boxes only, not an uncommon thing to see, but the second part shows inline editing of complex page elements like HTML areas.

The advantage of this style of editing is that the preview is always accurate. The disadvantage is that content is still edited using a stand-alone editing interface, not allowing the author to see a true preview of the content until they have completed editing.

It is worth noting that some editing interfaces take this style a bit further and write back to the page preview in real-time. This allows you to switch to the preview without saving or to have the page preview and editing interface side-by-side. Certainly, this is an improvement, but it does require multiple monitors to really make use of this feature and is does require the author to switch focus frequently while editing.

Whole page WYSIWYG editing

To get around the problem of having a preview mode and an edit mode, this style of editing uses a WYSIWYG editor to edit the entire contents of the page, including the site design and all page elements. The author gets inline editing and a very accurate preview.

The advantages are obvious, but the disadvantages outweigh them in my opinion. When the entire page is editable, there is no way to lock parts of the page and stop the author from editing them. For anything but the most simple of sites, this is not an acceptable situation. Sure, you can build components into the WYSIWYG editor to stop the author from editing some content in WYSIWYG mode, but switching to the common "HTML source" mode allows the author to change all parts of the page.

Some editors get around the disadvantages by removing the source mode, or providing their own source mode that locks part of the page from being edited. Most editors that do this are written in either Flash or Java so the developers have full control over the editing interface.

If you ask me, a full screen custom WYSIWYG editor is just an application running inside the browser and not the inline content editing interface of a content management system. As new features need to be added to the CMS, they need to be built into the full-screen WYSIWYG editor. So what you end up with is just a CMS written in Flash or a Java applet.

Inline WYSIWYG editing

This style of content editing is similar to embedded WYSIWYG editing except that the editor is made to be almost invisible. By removing the borders of the editor and resizing it dynamically as the content within it changes, the author is given an almost perfect editing and preview mix. The editing feels inline and the preview looks accurate. Better yet, the author does not have to shift focus between editing and preview modes.

So is this perfect? It is very close, but not quite what I would call true inline content editing. The content generated by the WYSIWYG editor still needs to be saved back to the content repository and cleaned to remove browser-specific code that is added by the browser's editable region. Using a non-JavaScript WYSIWYG editor, such as Flash or Java, can get around this but then adds the requirement of a browser plugin.

True inline WYSIWYG editing

True inline WYSIWYG editing combines the advanced preview mode of popup WYSIWYG editing interfaces while maintaining the clean lines of inline WYSIWYG editing interfaces. For me, true inline content editing needs to be done with a JavaScript WYSIWYG editor, but not one that simply uses the browser's own editable region. A true inline WYSIWYG editor needs to alter the source of the page as the author makes changes to the content. By editing the source directly, and not just inside an editable iFrame, the author gets a truly accurate preview while editing content without having to switch to a preview mode.

This is really the holy grail of content editing interfaces, bringing inline HTML editing programs like Dreamweaver into the browser. So what's the catch? You'll be very hard pressed to find a JavaScript WYSIWYG editor that can edit the source of a page directly without requiring some sort of custom browser plugin or having strict browser requirements, like IE or Firefox support only. Mozile, the Mozilla Inline Editor, is about as close as you can get at the moment, but that editor is far from complete and doesn't work in IE.

MySource 4.0 internal demo

Today, I gave the first internal demonstration of MySource 4.0 to Squiz. At lot of people have been waiting a long time to get a look at our progress and it was great to finally be able to show them what we've been working on.

The first part of the demonstration was MySource 4.0 itself. I showed the installation process and created a simple five page website with an imported design. The inline content editing interfaces were shown with raw HTML text boxes only. Finally, I demonstrated MySource 4.0's WebDAV integration by editing a Word Document that was uploaded through the content editing interface.

The second part was a batch processing test. I added and deleted a web path and role to 135,000 pages that we had previously imported into a test system. Adding took around 26 seconds. Deleting took around 6 seconds. To compare that to MySource Matrix, we would be acting upon somewhere between 540,000 and 800,000 assets and both adding and deleting would take somewhere between 10 and 24 hours, depending on hardware and load.

The last part of the demonstration was a preview of Viper, the MySource 4.0 WYSIWYG editor. This was really exciting and drove home our goal of inline content editing. Unlike other WYWISYG editors, Viper is written in JavaScript but does not use the browser's built-in editable region. The result is an editor where we have complete control over how it works, how it looks and the HTML it produces.

We are now busy preparing features for the first public demonstration at the MySource Matrix International User Conference 2007 in September.

MySource 4.0 public demo in September

The first MySource Matrix International User Conference will be held in September this year. It's a chance for MySource Matrix users to get together and discuss the product, their implementations of it and how it can improve the organisation and delivery of content. It's also a chance for MySource Matrix users to see a preview MySource 4.0.

MySource 4.0 is still a fair way from being feature complete, but the demonstration will still showcase some exciting improvements to our content creation and editing interfaces. It will also be a chance for us to describe where we are going with this product and the kinds of development that we will be able to do in the future.

The details of the conference are:

MySource Matrix International User Conference 2007

The conference is designed to bring our user community together on an annual basis to provide best practice advice in all areas of content management and web technology.

Squiz will coordinate a cutomised program delivering functional, practical solutions that maximise the benefits of your investment with MySource Matrix.

The agenda offers a broad range of presentations and case studies lead by recongnised industry leaders and current users. Held at the Radisson Hotel on the Gold Coast, the venue will be conducive to collaboration, innovation and learning.

Your registration also includes a seat at the Squiz Innovation Awards Dinner on Thursday night, 13th September. Prizes will be awarded for users, who demonstrate excellence in MySource Matrix implementation & website innovation.

Why you should attend:

• To meet and liaise with industry leaders, topic experts and the user community
• To broaden your skill set and knowledge base - delivering more relevance to the organisation
• To gain efficiencies and best practice techniques in using MySource Matrix
• To ensure you are up to date with the latest software developments
• Be one of the first to see MySource version 4 to be released in 2008

Key Agenda Topics:

• Designing usable Web 2.0 applications
• Techniques to ensure maximum accessibility, usability and functionality
• First public preview of the much anticipated MySource version 4
• User oriented information architecture for effective web content management
• What's happening with de-centralised publishing? Pros and Cons.
• MySource Matrix Tips, Tricks, Shortcuts and more (Manual included)
• User workshops

To register for the conference visit:
http://www.hotelnetwork.com.au/conferences/conferences#squiz7
For Further details please call 02 8507 9000

A better way to cascade in MySource 4.0

When the MySource Matrix permission system was first being planned, we tried a number of different database schemas to allow permissions to inherit to assets from multiple parents. The biggest problem was the time taken to check if a permission exists (eg. read access). With permission queries being some of the most common, they really needed to be as fast as possible.

The solution we came up with was a pretty basic one; cascade permissions to all child assets when setting them. So, for example, when you grant public read access on a Site asset, we run a HIPO job to set that same permission on every asset within the site. This allows us to check if any particular asset has public read access without having to determine its position in the tree. Instead of waiting for slow queries on the frontend, we made the backend processing slower.

There are two main problems with this approach. The first is that the data storage requirements are significantly greater than if we inherited permissions. The second problem is that cascading takes a very long time.

We just finished the planning of the Roles system for MySource 4.0. The roles system replaces the Permissions system in MySource Matrix, but requires the same general concept. We reevaluated the storage of permission assignments in MySource Matrix to see if we could remove the need for cascading role assignments.

Long story short; we couldn't. We still need to have a table with all the role assignments for every asset so we can quickly access role assignments for specific assets, and so that we can join the table to add permission checks to other queries. So we turned our attention to how we cascade assignments and looked for ways to make the process faster.

Here, we did succeed.

In MySource Matrix, we first get a list of all assets under the asset we are setting permissions on. Then we loop through each asset and assign the permission. A database query is executed for each of these assets to add the permission assignment. In reality, a lot more database queries are executed to load the asset and check its current assignments. HIPO thresholds are used to process more than one asset at a time, and the Squiz Server is used to process all assets in one go. Both thresholds and the Squiz Server make the process faster, but they don't reduce the number of queries executed.

In MySource 4.0, we have always wanted to get rid of the need for HIPO jobs and the Squiz Server. We are pretty sure we don't need the Squiz Server any more, but we will still need a HIPO job of some sort. The big difference are the thresholds. Whereas in MySource Matrix you could potentially process up to 50 assets at a time, MySource 4.0 thresholds will be more like 50,000. So even with HIPO jobs, you'll probably never see them.

We have written some new queries that will allow us to process different levels of the tree in one go, or multiple levels if they fit within the threshold. The reason we can increase the number of assets processed at once so much is because we no longer load assets and insert rows one by one. Instead, our new queries can look at the tree, select an entire level, and insert several thousand rows at once. These queries can also take granted and denied permissions into account, so you can't apply public read access where it is already denied (eg. a members only area).

We tested our theory yesterday with a sample of 44,000 assets from a MySource Matrix system. The goal was to select a entire section of a tree and insert new role assignments for all assets that did not currently have that role set. Here are the results:

# INSERT INTO asset_role_assignments (assetid, userid, roleid, granted)
# SELECT distinct l.minorid AS assetid, '90211' AS userid, '1234' AS roleid, 1 AS granted FROM
# sq_ast_lnk l INNER JOIN sq_ast_lnk_tree t ON t.linkid = l.linkid
# WHERE
# t.treeid like '00010002000D00030000%'
# AND NOT EXISTS (
# SELECT 1 FROM
# sq_ast_perm p
# WHERE
# p.assetid = l.minorid
# AND p.userid = '90211'
# AND p.permission = 2
# );
INSERT 0 44041
Time: 2441.133 ms

This test was run on a dedicated database server using PostgreSQL 8.2. Over 44,000 entries were inserted in about 2.4 seconds. We calculated that processing 44,000 assets in MySource Matrix would take around 6 hours. The other thing to consider is that a Standard Page in MySource Matrix is actually 4 assets, whereas it is only 1 asset in MySource 4.0. So these figures actually tell us that MySource 4.0 can process 44,000 pages in 2.4 seconds whereas MySource Matrix can process 11,000 in 6 hours.

We have now started development of the Roles system, so it wont be too long until we can start trying this out with some real data. The results so far do look very promising though.

MySource Matrix 3.12.1, 3.10.6 released

Squiz.net today made two new point releases of the MySource Matrix Open Source Content Management System available to the public; versions 3.12.1 and 3.10.6.

Version 3.12.1 is the latest release on the most recent stable branch of MySource Matrix and provides 28 bugs fixes as well as 3 new feature improvements. The LDAP Bridge now checks for PHP LDAP support, the "Back To" bar in the admin interface now wraps across 2 lines, and the asset lineage design area now has config options for print and cache in the admin interface.

Version 3.10.6 is a bug-fix only release, providing 21 fixes to bugs previously reported in 3.10.5.

The GPL editions of both versions are now available for you to download from the MySource Matrix download page. A full list of changes within each version are provided with the downloads.

WebDAV support scheduled for MySource 4.0 alpha release

We've been having a think about the features we want to add to MySource 4.0 after the alpha release. WebDAV support was on the list of nice-to-have's, but the current demand (both internal and external to Squiz) for integrated content editing has pushed it to into the alpha release.

So I've been trying to get WebDAV support going in MySource 4.0. To say it's been a pain in the arse is putting it mildly.

I started playing with WebDAV in MySource Matrix quite a long time ago. I got to the point where I could browse a MySource Matrix system via WebDAV, but never implemented content editing. I ran out of time and need some client funding to keep the project going. It never arrived, so the project was shelved.

I started back on WebDAV yesterday and got myself back to the point where I needed to implement content editing today. As of now, I can safely say that today has been one of the most horrible in memory, and I still don't have content editing via WebDAV!

The thing that really bothers me is that every WebDAV client likes to do things differently. There is also a severe lack of examples for WebDAV support in PHP, and those I do have don't actually work for content editing. So I think I'm going to need to do a lot more reading and implement a lot of the protocol myself. That wouldn't normally annoy me, but now I'm on a deadline, and the clock is ticking.

Who will provide decoupled content management services? MySource 4.0 will.

CMS Watch has posted a new article about decoupling content management services. The article talks about the ability for customers to use a CMS but also use 3rd party products to provide services that the CMS would normally offer natively.

Mediasurface, Stellent, Documentum and many other vendors have successfully decoupled their repository search capabilities from their underlying CMS. Other observers have asked for decoupling of other services like security, and I have often seen customers asking if they can use their own choice of workflow software, version management software, and so on, instead of using features embedded in the CMS.

The article goes on to say:

To allow decoupling (or even loose coupling) of services, most of them [CMS vendors] would need to re-architect their products.

Very true.

To use MySource Matrix as an example, if we were asked to integrate a 3rd party workflow system into the product, the only solution would be a very messy trigger-based setup or a custom CMS product for that client. Workflow is so tightly integrated into the core product that removing it, or replacing it, is not practical.

Enter MySource 4.0.

One of the primary goals we had during the early planning phase of MySource 4.0 was to completely decouple the core. Services like workflow, versioning, status, metadata and permissions have been designed to be independent services with either no, or very loose coupling to each other. This goal was focussed on providing customised CMS solutions to our clients, allowing them to remove or replace these core services.

For example, workflow adds a level of complexity to the publishing process. If a custom does not require complex workflow rules, the workflow system can be removed completely without affecting the functionality of other core services. Similiarly, if the default workflow engine does not work for a customer's organisation, a new engine can be written and the default can be replaced.

This core architectural feature makes MySource 4.0 ideally suited to the integration of 3rd party services into the core. We have already anticipated support for 3rd party search engines, but it will be interesting to see what other core CMS services our customers would like replace.

MySource Matrix 3.12.0 released

Version 3.12.0 (stable) of MySource Matrix was released today. The additional week between the expected and actual release dates was used to make the release ready for the new dual licencing scheme; MySource Matrix is now available under both the GPL and the new SSV (Squiz Supported Version) licence.

In addition, the core (GPL) version of 3.12.0 now contains a significant number of new modules that were previously only available through the commercial module package. The entire CMS package, minus the Remote Content asset, and the entire News package are now freely available in the download.

Some of the new asset types included in the download are the Custom Form, the Asset Builder, the Online Poll and the RSS Feed. This is an incredible increase in functionality available in the free download.

If you are an existing user of MySource Matrix, make sure you view the updated licence page on the Squiz website for more information about the new licencing scheme, and the updated modules section of the MySource Matrix website for more information about which modules are only available under the SSV.

And of course, you can download MySource Matrix from the downloads page.

UPDATE: you can view the 3.12.0 press release on the Squiz website.

MySource Matrix 3.12.0 delayed

The release of MySource Matrix version 3.12.0, the first stable release on the 3.12 branch, has been delayed by one week. Some last minute development was planned and implemented on Friday, with some minor changes made both yesterday and today.

This new development does not affect any core functionality, so we have no need for a month-long RC2 phase.

The new release date for 3.12.0 is Monday the 15th Jan, 2007.

On a related note, versions 3.8.10 and 3.10.5 were released yesterday. Version 3.8.10 is the final regular release on the 3.8 stable branch and contains 8 bug fixes. Version 3.10.5 is a regular maintenance release for the 3.10 stable branch and contains more than 20 bug fixes as well as a couple of minor feature additions.