In the previous post we reviewed the overall design of µWeb and dove deep into the provided template language. We will continue where we left off and cover the remaining parts of the system: the presenter, the model and the application server.

This follow-up to the initial post about µWeb’s development history is running on the long side, so I’ve split it up into two parts. This one will deal with the high-level view and an in-depth analysis of the template system. The next part will deal with the presenter, database interaction layer and the standalone server.

µWeb is tagged as a minimal-size micro web-framework, and it does deliver on that promise. The code is spread out over a core of a dozen files and some included libraries and weighs in at a bit under 5000 lines of code (see Appendix A). While small, it’s certainly not the smallest out there. The smallest (in popular use) I’ve seen so far is Bottle. It provides a full web-framework in a single file, clocking in at just over 2300 lines of code. While less code is preferred, it’s not a compelling reason to pick one framework over another. Features and the ease with which you can get things done are.

We started development of µWeb without a clear set of design goals, and a number of decisions were made with a lack of information, experience and clairvoyance (though the latter is a common problem). This means that the current product suffers a number of unfortunate flaws. A good few of these can be easily fixed and improved upon, but others would require rewriting major portions of the code base. While a rewrite is an option, it would take a serious effort and there are other, more complete and functional web frameworks readily available for use. For my own day to day work I’ve migrated to Pyramid, which provides a simple and easy interface which contains solutions for all of the most common requirements, and is easy to extend.

This is the first part of a series that looks back on previous projects. There is a lot to learn from looking critically at ourselves, both admitting mistakes and acknowledging achievements. The first project will be µWeb, and will likely take up more than one installment. The foundations for this were laid in 2009, and that’s where the story starts.

During my time at Google, even working on the operations (hardware) side, there was a good bit of software involved. We made small scripts and applications that made everyday life go better and smoother. The tool of the trade was Python, and I quickly developed a strong liking for it. My fondness for it turned out to be infectious and my partner in programming developed a similar preference. To be fair, coming from a PHP background, what was there not to like…

This is part two of a two-part post on storage of JSON using SQLAlchemy. The first post covered the basics of creating a JSON column type and tracking mutations. In this post, we will continue from there to cover mutation tracking in arbitrarily nested structures.

In the previous post we ended with an example of appending to an existing list. Upon committing the changes in the session and reloading the object, it was shown the appended string had not been stored. This happened because changing the list in-place did not trigger the changed() method of the class MutableDict. Only setting or deleting a key from the dictionary marks it as changed, and marking it as changed upon access (which is all we did on the dictionary itself) would cause far too many updates of the database.

What we wanted (and perhaps expected) is behavior where changing the list marks the dictionary it’s part of as changed. And for completeness, if the dictionary contained a number of nested dictionaries, changing any of them at any level should mark the class MutableDict as changed. To achieve this, we need a solution that consists of the following parts:

1. Replacement types for list and dict where all methods that change the object in-place flag it as having changed.
2. A means to propagate the notification of change up to the top so that it reaches the class MutableDict.
3. Conversion of all mutable types to the defined replacement types. Both when they are added to the existing structure, as well as on load from the database.

This is part one of a two-part post on storage of JSON using SQLAlchemy. This post will touch on the basics of creating a JSON column type and tracking mutability, and is mostly a rehash of the SQLAlchemy documentation. The second post will cover the tracking of mutability in arbitrarily nested JSON structures, and goes beyond what is covered in the documentation.

The past weeks have been pretty busy. We moved from Leeuwarden to Hoofddorp, which in and of itself went pretty smooth, but the new apartment is still very much unfinished. In between work and getting the apartment in order, there hasn’t been a lot of time to spend on side projects, but this seemed interesting enough.

A while ago I needed to store a relatively small amount of variable-format data. The requirements are only to store the data, not search in parts of it or anything else. Additionally, it’s of such a small volume that it doesn’t warrant setting up a document database like MongoDB next to the existing SQLA+Postgres setup. The data itself consisted of a flat mapping of strings to basic scalar types. Something roughly like this:

{
    'title': 'Example data object',
    'description': 'Information about this example object',
    'storage_location': 'Top shelf in the back',
}

When you’re making a website for the general public, you need to support the browsers of that general public. One of the things that can make that particularly difficult is the large install-base of older versions of Internet Explorer that don’t run in standards mode by default. Specifically, IE8 and 9 still have a combined market share of about 30 percent.

By default these versions of Internet Explorer will run in Quirks mode rather than Standards mode. This is good for websites that were made over a decade ago and targeted IE6, but it’s a disaster for modern web development because the amount of corrective CSS required is astounding. The fix is to tell them to use their edge rendering mode; that is, the closest they can get to actual standards. From there the path to proper behavior is manageable. Microsoft has explained how to do all of this in their knowledge base, but in practice it comes down to this:

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

This will instruct Internet Explorer to use a Chrome Frame if available, and if not, use the latest rendering mode available (edge). With Google having discontinued Chrome Frame though, it’s probably best to help those users to upgrade away from older Internet Explorer versions, though that’s outside the scope of this article.

With the hackerspace open day coming up in a bit over a month, this is a perfect time to prepare some small projects. Something that can be completed in a few evenings, and is reasonably accessible to curious newcomers. A fellow hacker ordered a few nRF24 wireless transceivers a while ago, and now is as good a time as any to do something with them.

def main():
    print 'Hello world!'

if __name__ == '__main__':
    main()

Now that we have the inevitable first lines out of the way, let’s move on. This blog will focus on programming subjects, primarily the Python programming language. My current work involves a healthy amount of web framework in the form of Pyramid, which I’ve become a great fan of. Other parts of the technology stack employed may also feature in articles here.

Aside from work-inspired interests, there are other programming related topics that may feature. I occasionally tinker with Arduinos (most of the code is up on GitHub) and they may feature here. JavaScript, necessary evil that it is, may end up as a subject as well. I’m predicting this based on my many conversations with herrieii about JavaScript.