Apr 27, 2010 - Putting the 'I' in IDE

Developers often get het up about their editor, as it has been and probably always will be. It is a very personal choice. As it is the system you will spend untold hours interacting with.

I am not going to say there is a right or wrong system. My preference is eclipse however my reason for linking it is not in any particular shortcut or way of working. My reason for liking it is that it is integrated

There are various tasks involved in development. There is of course the coding. However there is also debugging, version control, bug tracking and often time tracking. The more tightly integrated you get all of these, the less context switching you will have to do and the more effective you will be as a developer.

To illustrate this I will take an example with a fictitious un integrated system for fixing a trivial bug.

  1. Open bug tracking software and find bug assigned to you and read it.
  2. Open editor and fix trivial bug.
  3. Build software in software building tool
  4. Test software in software environment.
  5. Open bug tracking software again to get reference to bug.
  6. Open source control software to commit bug.
  7. Open bug tracking software to mark bug as resolved

That is a lot of context switching. Compare to example with fictitious ultimate integrated environment.

  1. Open next task in UIE
  2. Fix bug
  3. Click on build in UIE
  4. Test and run test suit in UIE
  5. Commit code automatically closing ticket as you do so.

The more tightly integrated things are, the less needless work you need to do and the more effective you will be as a developer. It is worth taking the time to get your IDE to be integrated. How much time is a difficult thing to estimate. In “”the mythical man month” Fredric Brooks talks about a team having one person dedicated to writing tools.

We have bigger, more powerful tools nowadays, but in a team it may be well worth having at least one person dedicated to improving the developer experience. The maths is fairly simple. If you estimate that developers can be 20% more efficient with better tools (this will vary massively depending on the technology stack) by the time you have 5 developers the equivalent of one of them will be wasted due to avoidable inefficiencies. So let them choose the tools and have the time to get things running smoothly. And you will have more efficient and happier developers. If you have a team of more than a dozen or so developers seriously consider having someone full time to keep the developers ides and machines running as smoothly as possible.

It is not just getting the developers to work more effectively. Taking the time to have a great IDE setup will pay for itself many times over. Having the bug tracking system right in the IDE will make it easier, and hence more likely that a developer will update tickets as they work. This gives managers better reporting, and stops them from distracting the developers asking for status updates.

Jan 15, 2010 - Openspace up and running.

I have the OpenSpace module working and on Drupal.org. It is still early days but it could be used by someone with a Drupal site.

The next step is to get it integrated with the geo module.

Jul 6, 2009 - RIP XHTML2

Over the weekend I learned that the XHTML2 working group was being disbanded. I am sure that it will not be mourned by many, but personally I think it is a big step in the wrong direction for the web.

A little abridged and possibly incorrect history here.

HTML went through a number of revisions in the late nineties. HTML40.1 was publisehd in 1999, then it pretty much sat there and stagnated. So since the original .com boom, there hasn't been an update in the basic language that nearly all web pages are written in. Most of the fancy goodness that you see today comes from CSSand JavaScript, Which have had many updates in the last nine years.

XHTML was simply an XML version of HTML4, it is more strict than HTML, but due to IE not linking rendering XML files as web pages, It hasn't ever taken off. XHTML2 was meant to be the future of the web. It had been in progress for a long time, and was a major refit of the language and had many great technical advantages. The other thing was that it was properly extensible, so users wouldn’t have to wait for a whole new generation of (X)?HTML to come along before getting nice new features.

Unfortunately it was hard, and it wasn't back compatible. A lot of people got impatient and a group of upstarts came up with the Idea of HTML5, which was a lot of bells and whistles on top of HTML4. When this was first announced it was not meant to be a replacement for XHTML but an interim step. To get some features out the door fast while XHTML2 was being finalised (as of writing HTML5 is still not ready).

What now?

I continue to think that HTML5 is focused on the very short term. The form improvements could be handled much better by XFORMS. The new elements could be added in a separate namespace. I have not seen a convincing argument yet that HTML5 is anything other than a few gimmicks. I am sure that amazing things will be done with the gimmicks but as a technical step forward it is minor, mostly it is just standardising things that people are doing already. Not that this is a bad thing, in itself. But the loss of a modular extendable HTML is a heavy price to pay.

XHTML2 took the approach that a lot of the specific stuff was not needed. Keep a few general tags, and make things extensible. HTML5 goes the other way and adds a whole load of very specific tags. HTML5 has a <nav,> tag, XHTML2 had an attribute @role which could be applied to any element. To me the second approach seems much better, adding a new and unknown value to role at least gives the browser a chance to work out what the element is and know that it is dealing with something with a role that it doesn’t know about.

Looking forward I hope for two things.

One is that this doesn’t kill off Xforms. Xforms is one of the most promising standards from the W3C. I think that anyone who has written more than the most trivial HTML form could spend a day with XForms and realise how great it could be. I'll blog about it some other time.

The second is that this short termism is short lived. There will always be someone who wants a new tag to do something cool, but adding tags will only get you so far. The more tags there are in a spec the harder it is to change it. I would have though that people would have learned a lesson from a decade (nearly) of inaction on HTML.

It will be interesting to see what happens after HTML5 is finalised.