The main technical challenge when implementing the Algonomicon website was how to render the large number of mathematical equations that would be needed in the explanatory text. On the microHOWTO site there are a few simple expressions written either as source code or using ordinary HTML markup, but it was obvious from the outset that this approach would not be workable.

The equations could simply be added to the website as images. This has the advantage of placing few demands on the web browser, but the quality of the result can be variable (especially for inline equations) due to their being rendered in isolation from the rest of the page. This method can also add significantly to the bandwidth consumed by the site, and content is more difficult to edit when it is split across multiple files and multiple file formats.

An improvement would be to serve the equations as images, but generate them automatically from some for of markup embedded within the page content. This is the method that Wikipedia uses. It avoids fragmentation of the content, allows global style changes, and is both searchable and diffable. It does not help with bandwidth usage, nor with the equations being rendered separately from other content.

The ideal would be to render the equations within the browser. This can be done using a markup language called MathML, which is XML-based and is capable of being mixed with HTML or XHTML. The one big drawback is browser support. At the time of writing this was available in current versions of Firefox, Chrome, Safari and Opera, but Internet Explorer required a plugin, and the number of older browsers that would have been excluded was rather too high for my liking.

Fortunately, there is an answer in the form of MathJax. This is an Open Source JavaScript library which adds MathML support to older browsers. Nothing need be installed by the end user, and the only required change to the web site is the addition of a script element to the head of each page.

Having chosen calendrical algorithms as a first topic, it would be hard to let this day pass without publishing something about the Long Count calendar used by the Maya and other Mesoamerican cultures. There are three pages so far:

• The Mesoamerican Long Count: Introduction
• Conversion from the Julian Day Number
• Conversion to the Julian Day Number

The relationship between the Long Count and modern calendars is a matter of some dispute. For the time being I've chosen to use the Goodman Martinez Thompson (GMT) correlation, but this is purely on the grounds of popularity and is not intended as an endorsement. I will want to review this before writing any source code, and also how the calendar should behave outside of its normal range.

When creating web content, having a site with a well-defined format helps in several ways. It cuts down on the amount of work because decisions about appearance and structure need only be taken once. It is often possible to generate parts of the page automatically. Pages give value not just in their own right, but because they form part of an organised whole. The downside is that the more tightly you control the format, the narrower the range of content that can be added to the site without detracting from its coherence. You also need a substantial amount of material for a dedicated format to work, otherwise the site looks very sparse.
Most of what I have written over the past two years has fitted into the microHOWTO format. This has proved quite flexible, accommodating topics that range from system administration to programming, but by design it is very task-orientated. I want to start publishing some material about computer algorithms which is not such a good fit, but which could work well with a format of its own.
The result is a new website, www.algonomicon.org. There is not much there yet, but the same could have been said of the microHOWTO site at this stage of its development. My aim is to have a site worth visiting − for some topics at least − within a year or two.
The first topic I have chosen is the Julian calendar, specifically the conversion of dates between that system and a day number. The Gregorian calendar would have been a more useful choice, but it makes sense to describe the Julian calendar first because of the historical and mathematical links between them. I intend to provide implementations of each algorithm in a number of different programming languages, but for now there is only a mathematical description.
More to follow, including how I chose the name of the site and how the equations are rendered.

IPv6 support has been on my wishlist for the microHOWTO website since its inception. This is not technically difficult once the webserver has an IPv6 Internet connection, but IPv6 support was not readily available at the budget end of the VPS hosting market, and was difficult to justify for a site that might or might not attract significant traffic. The situation has improved somewhat in the two years since then, and while I would have to say that IPv6 support is still patchy, it is not hard to find if you look for it.
Moving the website from one host to another is straightforward because the content is kept in a Subversion repository hosted elsewhere. This must be transformed using XSLT into ready-to-serve HTML, but once the necessary software packages have been installed everything else is scripted.
No changes to the Apache configuration were needed: it is merely necessary to refrain from specifying an IP address to listen on, and (on GNU/Linux at least) either protocol can be accepted. However, a restart was necessary because the IPv6 address did not exist when the Apache process was started. Before continuing, the operation of Apache was verified using netstat (to check that it was listening on ::1, the IPv6 loopback address) and wget (to check that it would serve the URL http://[::1]/).
The final step was to create a DNS AAAA record for the webserver. This was not keyed to www.microhowto.info, because that is a CNAME, but rather to microhowto.info (which www.microhowto.info points to). The value of the record is the relevant IPv6 address, in this instance 2401:f500::161. This change will have taken some time to propogate throughout the DNS (because I had not previously shortened the TTL), but despite this the webserver was receiving IPv6 hits within the hour.
At this stage I don't expect to receive any traffic that would not arrived anyway as IPv4, but the site is at least ready for the day when IPv6 support becomes a necessity. Transitioning gdshaw.net will unfortunately take longer, because the virtual host it is on does not have an IPv6 option.

One of the advantages of the new tableless layout at microhowto.info is that it is now significantly easier to remove unnecessary elements from the page when it is printed. I think this looks better, and it certainly saves paper compared to the alternative of printing everything.

This is something I has previously implemented on codepolice.org using an HTML link element, but since traffic to the MicroHOWTO site is higher by a factor of 50 I wanted to check whether this is actually the best method.

It turns out that in terms of efficiency it probably isn’t, especially when the number of print-specific rules is small. Zoompf have a good explanation of the issues on their website (Browser Performance Problem with CSS "print" Media Type). In short, most if not all current web browsers download any print-specific CSS rules whether or not they are needed immediately, so placing them in a separate stylesheet merely increases the number of HTTP requests needed.

I didn’t like the idea of using JavaScript to load the rules because I strongly believe that users should be able to turn off scripting without penalty unless there is a compelling reason why it is needed. In this case the consequences are not too serious, but it still qualifies as an unnecessary and easily avoidable reliance on JavaScript.

I’ve written up three of the other possible methods — @media, <link> and @import — as a microHOWTO (Hide part of an HTML or XHTML document when it is printed), with some notes about their pros and cons. Both microhowto.info and codepolice.org have been altered to use single stylesheets with @media rules.

While preparing to launch the microHOWTO website last year my main priority was content creation. Appearance was not neglected entirely, but there was a limit to how much time could be justified on aesthetic considerations when the site was small and likely to have few visitors in its early days. What I did instead was ensure that the style and layout could very easily be changed at a later date without altering the content. This was achieved using an XSLT stylesheet to transform the content from XML to HTML, then using CSS to further style the content.
Since then the site has grown considerably and attracted a respectable amount of traffic. Because the style affect the usability of the whole site, a little extra effort now goes much further. A further consideration was that the topic-based index pages, which had been adequate enough for a few tens of pages, was not going to cope well with hundreds. I therefore decided it was time to review the design and look for opportunities for improvement.
As when writing software, I prefer to make changes to the site in small steps where possible so that any adverse effects (such as drops in traffic) can be more easily traced to their cause. My two objectives for the first stage of the redesign were to:

• avoid the use of tables for page-level layout; and
• prevent lines from becoming unreadably long when displayed in a wide viewport;

Both of these have now been achieved. The new layout is fluid for moderate viewport widths, but it will not allow the line length to expand beyond 60em or contract to less than 30em. (The trick needed to make it work was to set a negative left margin on the sidebar wrapper.) I'm not completely satisfied with the result yet, because in some tests the content came out about 30% wider than I would have wished, but even so it is a definite improvement on having lines of unlimited length.
Other planned improvements are to: