Joel Hainley

I met with a company recently about doing some work for them. During the meeting one of the UI developers let me know that they were using xhtml in strict mode.  Now I have to admit it has been a while since I looked at xhtml and I’ve never actually done anything with the strict variant before. So I got a little curious and decided to spend some time and see what it was all about.

I pulled up the xhtml specification the next day and read through it. The name “xhtml strict” kinda hints at what you would expect to find and it does a pretty good job of living up to its name. It’s a very precise way of working with xhtml, it doesn’t allow you to “get away” with sloppiness, it requires that all attributes must be quoted, all tags must be well formed, and closed properly, attributes must be lowercase, you can’t have “name” attributes they are all id attributes and a bunch of other things like that. My initial impression was that this doesn’t seem that arduous, it’s simply a way of enforcing a convention upon a document. .

In order to see how it stands up in the “real world” I decided that I would update hamtesting.com to be xhtml 1.1 strict compliant just to see what sorts of things a developer could run into while working in this environment. Below are some of my thoughts about the process.

My initial efforts at getting all of the templates into shape went pretty quickly in about 45 minutes I was able to get all of the main site templates updated to be compliant. Things like updating the br’s and hr’s and adding /’s to input items on forms were all of the things that I expected. Also expected was that all attribute values need to be lowercased. So if you have an onclick defined for something in your page it can’t be onClick or ONCLICK or anything else, it needs to be onclick.

The first thing that kinda gave me pause for a bit was that it is really picky about which elements can be just below the root element in a document. This ends up not being an issue and actually leads to a lot more consistence in the document structure. It was a little bit of a pain at first but it quickly got into shape. The specification does spent a certain amount of time talking about which elements can contain other elements and such things, so it’s probably good to have that floating around in your head. Or use a validator plugin ( see below )

The second thing that was a little difficult was that I had used the name attribute in a lot of places for some of my javascript interactions. So first I made everything xhtml compliant by switching things from name attributes to id attributes, with this done the site didn’t work terribly well. So I updated one javascript routine in my main library and then whammo everything was working well again.

With this all done I spent a bit of time and knocked the css document into shape and got it validated as well. So now when you go to www.hamtesting.com you will see badges from w3c for the site being both xhtml compliant and css compliant. Kinda fun.

Probably the biggest lesson learned was that while the w3c’s online validator services are fine for a page or two they can be a pain after a while, especially if you are trying to validate pages that are in an authenticated area of your site. Do yourself a favor and go get a html/sgml/xhtml validator plugin for firefox so that you can just pull up the errors as you run across them.

In the end, this wasn’t as difficult as I thought it was going to be. My impressions are that xhtml is kinda nice, and using the strict variant definitely enforces a certain amount of discipline into your efforts. It’s a good exercise if you have some spare cycles and want to dig in a little.

One of the things that you notice if you are around development/engineering teams enough is that there is normally the existing solution, and the “next iteration”. Much has been written about the “second system” phenomenon and all of the pitfalls and failures that have resulted by second system thinking. Today I just want to talk about the importance of maintenance work to the growth of a developer towards understanding the hard problems within their chosen problem domain.

It seems like maintenance programming is, according to some developers, the lowest form of development on the planet. If you’ve ever been on a team in the role of maintenance programmer you have probably noticed that it’s not considered “sexy” by most of the team. Everyone is glad that you’re the designated maintenance programmer because that means that they AREN’T. Everyone wants to be working on the second system where “things are cleaner”, “we’re using better technology”, etc.

I’ve never agreed with this mentality, and here’s a dirty little secret, I LIKE maintenance work. There are few things as challenging as debugging a problem in a system you haven’t designed and fixing the problem in such a way that you leave the code better than it was when you got there. Here’s another amazing benefit of maintenance development, you learn the system and you learn how other people think and approach problems. In a similar way that Rorschach and Perceptive Aptitude Tests work, code is a projective tests for the thought processes of the developer who wrote the code. The other amazing benefit of supporting an existing application is that within a VERY SHORT amount of time supporting an existing application, a new developer is going to learn the system backwards and forwards. The developer will end up having a very deep understanding of the problems inherent in the existing design from a very realistic standpoint.

See new development is easy, you’re just trying to hit the 80% mark. If you’re in development you know what I’m referring to. “80% of the functionality is solved by 20% of the work.”. I’m willing to argue that the real work involved in a new application is done after the application is in production, that’s when you start to work on the last 20% of the application.

Maintenance work ( debugging production problems, adding new features, etc ) is when you start to solve the really hard problems that were not seen, or deferred, by the team creating the application. You often have to be creative in how you quantify the problems you are seeing, and you have to be a bit of an artist in terms of how best to quickly and easily ascertain what the hell is going on. The great part though is that you start to see how the choices made during the implementation of the system impact your ability to respond to certain things. This is the reason that I think solution architects should be in the trenches writing code with everyone else. They need to understand the results of their decisions at a very fundamental level, and the only way to do that is to keep their head in the game.

The other great thing about doing maintenance development is how easy it is to measure your contributions to the team. It normally goes like this, Tuesday morning the big client calls, he has found a bug that needs to be resolved by Friday or else they are going to have to leave the team. Tuesday, just before lunch, a meeting is called, and bad pizza is ordered. You are brought into the meeting and asked how in the world this can be fixed before Friday. If you just built the application but haven’t spent time doing maintenance since it’s release, you’re going to have to look into the application and reacquaint yourself with how it works, and see what new things have been added since you last saw the code. However, if you’ve been doing the maintenance work you can speak with authority right there in that meeting about what it is going to take to deal with that issue, and with any luck it’s already something that you have thought needed to be dealt with and have an idea about the best approach to take. So you grab two extra cokes and the last box of pizza and go back to your desk and solve the problem, test it, get it through qa and into production. A specific measurable result for your efforts, and something that others will remember.

Obviously I love to do maintenance work, I am VERY often called by clients to deal with legacy situations. I can’t count the number of times that I have had a client call up and tell me that the only person who knows anything about the application has left and “they have a huge bug and he’s trying to charge them $400 / hr to deal with it”, or they “have fired their consultant and are now left with a huge mess on their hands and could you help us”. I love this work, it’s real, it’s necessary and it’s often challenging and interesting. If you need maintenance work done feel free to contact me, I’m always looking for chances to sharpen my debugging, and code-reading skills.

Last time I talked about setting up logging for your Flex applications using the debug version of the flash player and configuring it to write to a text file. This is can be useful for debugging, but it’s not always the most efficient route for quickly getting to the bottom of a problem within Flex. Thankfully there are a few other useful tools that we can utilize to help us in our debugging. One of these tools is a project put out by Google called ReflexUtil.

For this article I’m gonna be using Adobe Flex Builder 2 to describe the process for  setting up ReflexUtil in your project. It should be relatively obvious how to add this to your project if you’re building everything using the flex sdk for development, if not let me know and I’ll post a note here about setting it up.

The process for setting this up is really well documented on the ReflexUtil website but if you haven’t used third party libraries in your Flex projects before you might spin your wheels for a few minutes. So here’s a step by step for getting things setup :

1. Download the appropriate version of ReflexUtil library from google code – there are versions for Flex 2 and Flex 3 so make sure you get the latest version for whichever version of Flex you are running .
2. Unzip the file and place it in your libraries folder – I have a master directory for all of my libraries, 3rd party and custom libraries, and I drop them into subfolders of this folder so that I have everything in one place.
3. Open up your project in Flex Builder and add the library to your project. If you’ve not done this before you just go to Project->Properties in Flex Builder then click on “Flex Build Path” on the left, once there you click on the Library Path tab on the right hand side. Then click “Add SWC” then browse to the location of the file for version I have installed in the project it is called ReflexUtil2.swc . Once you select the project a bunch of options will be availble for how to link the library to your project etc. You can get more details on things over at the Adobe documentation page that describes how to use SWC files in your Flex project
4. Now open up the application’s MXML file
5. Add <reflexutil:ReflexUtil /> tag within the application tags. ( in XML speak : make it a child node of the application element )
6. Add the ReflexUtil namespace to the application tag by adding the following : xmlns:reflexutil=”net.kandov.reflexutil.*”
7. When you run your application right click on a control and you will see some new options in the pop-up menu. Links to the ReflexUtil homepage, Open Reflex util and an option to inspect the control that has focus, and perhaps options to inspect a few more controls.
8. Click on one of the Inspect options. This will bring up a dialog bog that allows you to drill down through what could be thought of as the Flex DOM and actually modify things at runtime, layouts, values, etc. It’s pretty impressive.

That’s about it, there’s a lot of things you can probably think of that this might be useful for in your own projects. The ability to get in and muck with the UI in this way is really convenient, instead of constantly incrementing layout parameters, then recompiling, checking, then tweaking again. You can now  just pop up your ui and make adjustments until you have it the way you like, then just make a note of your settings.  It might be kinda useful to modify ReflexUtil to have the ability to write out all parameters to the debug file so that you wouldn’t have to write things down, perhaps the developers will do this.

The only other thing that really comes to mind at the moment is that you probably would want to remove ReflexUtil from your project when you put your Flex application into production. The ability of users to muck with things could be catastrophic