Ian Bicking: a blog

Defenders of static typing have long claimed that it helps them avoid bugs, the compiler providing a constant test of code consistency. Agile practitioners counter that tests do the same thing and much more.

I find myself inclined to something more in the middle. I don’t care for static typing, but I think programming by contract has a lot of validity, is more powerful and helpful than static typing, and works just as well in a dynamically typed language. Programming by contract is more a principle than a particular technology. Unit testing is not xUnit; that’s just one way to do it. You can do unit testing perfectly well without any framework or special infrastructure at all. Similarly programming by contract just means: state and check your up-front expectations in a piece of code, and state and check our expectations for what that code returns or does. This can be as simple as “assert isinstance(n, int)“ in your code.

Programming by contract is not enough to produce quality code. While the contract is checked at runtime that only means that exceptions are raised early and bad or inconsistent data does not propagate into the system. But it only works if you go through the code paths to invoke all those contracts.

Here’s where functional tests come in. A functional test does stuff. In a web application a functional test does a simulated HTTP request and gives you the result. Generally they are high-level and go through the entire application stack. This is in contrast to unit tests that test just one piece of code.

Proponents of unit tests say that functional tests are problematic. They often give confusing output, so that you have to work harder to debug problems when you are invoking so much code. You have combinatorial problems where it can be difficult to run tests that really get to all branches of the code. Functional tests can be slow.

Of course no one really claims you shouldn’t have a mixture of both functional and unit tests for your code, this is more a question of what the best balance is. Functional tests without runtime checks in your code are a problem. They can be fragile because people look for every detail of how the application responds to identify how specific features function. But every detail that is verified is a detail that might change and require updates to the tests.

With runtime tests functional tests can be much more compact. You can do things like simply verify that a page renders, or that code completes without an exception. If you have some confidence that it won’t be complete wrong — wrong as in without any exception but with errors — then simply exercising to code can be sufficient. In addition to getting more use out of your functional tests, you also have some assurance that production code will act in a sane way — that is, if it is broken, the code will act broken. Given a good deployment situation, the turnaround on fixing deployed bugs can be much shorter.

A while back I was reading this post about creating a simple CMS in Grok. Similar to the author over there I often get questions from friends and family who want to build a simple website about what I’d recommend. I still haven’t figured it out. Most of the big names (Plone, Drupal, etc) feel too big and complex and not content-oriented enough. On the other hand, simple systems like Google Homepages are more like HTML editors and don’t really help with managing content.

I have a vision for something much, much simpler; but I’m not sure it’s a realistic vision. There’s always feature creep. If you implement something simple, what happens when someone wants something more complicated? Do you have to throw it out? That sucks. Do you have to implement the new feature? That’s not very simple.

Here’s what I wish existed:

• Just edit content. Static files.
• Probably edit content that is slightly dynamic. Probably PHP code, but without getting too fancy with the PHP. E.g., put <?php include('header.php') ?> at the top of each file along with a footer and some variable assignments (like $title).
• Pages would have simple parent/child relationships.
• Sidebar navigation would be mostly manually managed. It would be a single PHP file, like any other. The parent/child relationships would help inform and automate aspects of that generation, but only on the UI side. There would be no attempt to incorporate fancy navigation algorithms.
• The fancy things would be done with Javascript. For instance, if you want to expand navigation depending on the context of the site. This would be easy enough to implement in Javascript, serving everyone the same content and rendering it just slightly differently to emphasize context.
• Of course it would include the important stuff like versioning and staging. With a file-oriented system you could use an existing version control system, or just simple archiving.

At my last job we wrote a content management system, and one of the last features I added I found really clever; a kind of coding judo. We wanted to add structured page types — things like a news feature with dates summary paragraphs. Instead of adding a fancy structured page system (akin to Archetypes in Plone) I just had the system look for an edit form alongside where the page would go (which itself is just a static file). The edit form has the necessary fields, and when you save the page each field turns into a variable assignment. Then there’s a template that uses these assignments. In PHP you’d have something like this:

The edit form:

You would use Javascript to make this form fancy if you were so inclined; adding client-side validation (clients were trusted to submit valid data) or marking things for a WYSIWYG editor (usually just with class="wysiwyg" and rely on unobtrusive Javascript to enable it).

For new pages you just give the form. For editing a page you use htmlfill to fill in the form with existing values.

The thing that is saved looks like:

The system would know how to parse variable assignments (to get values) and would parse the include statement to determine what editor would be used.

Extending this system required a knowledge of HTML and HTML forms, and a little knowledge of PHP (or SSIs would also work). It fit our company well, as there were quite a few people with that kind of knowledge who would interact with clients, and wouldn’t need to come to the programmers to extend the system. While I’d offer some advice on how to use the system, it was transparent enough that they could debug problems on their own.

This whole concept is not something I can justify spending time on, but it’s a CMS that I wish existed. It’s a CMS I could recommend to my friends.