Extralogical

Ruby One Niner

2010-01-07T12:08:38Z

All my server’s Ruby applications, most notably my books site, have been running on 1.9.1 for over a month now. During the process of upgrading Ruby I jotted down a few notes on the process I followed, the problems I encountered and the ways in which I solved them. None of this is new information, but hopefully bringing these solutions together will be of use to those with similar setups, or at least to myself in the future.

Installing Ruby

I installed Ruby 1.9.1 on an Ubuntu 8.04 (LTS) server, which was reasonably simple in and of itself, although the Ruby ecosystem as a whole has clearly not quite caught up to the new VM.

Ruby 1.8.6 is still the default version of Ruby available on the Ubuntu package system, and while there is a version of Ruby 1.9 available, it’s quite out of date. For this reason, I recommend compiling it by hand from the source code provided on the Ruby website. This has the additional benefit of making upgrading your version of Ruby independent of the Ubuntu packaging hierarchy, which can be somewhat slow to update theirs.

Uninstalling Ruby 1.8.6—assuming it was installed with aptitude—is extremely simple:

sudo aptitude remove ruby1.8

The package manager will pick up on the fact that rdoc, ri and irb depend on Ruby, and uninstall them as well as ruby1.8-dev and libreadline-ruby1.8 which will be unused when ruby1.8 is gone.

If you’re following these instructions, make sure you use the latest stable version from the Ruby site, not the one I list here. Given that newer versions are likely to fix bugs and security vulnerabilities, this is extremely important. Blindly copying and pasting shell commands is a sure-fire way to create problems for yourself.

cd /usr/local/src/
sudo curl -O ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p243.tar.gz
sudo tar xzvf ruby-1.9.1-p243.tar.gz
cd ruby-1.9.1-p243/
sudo ./configure
sudo make
sudo make install

Installing gems

The RubyGems packaging system is built into Ruby 1.9, but quite a few gems are not yet compatible with the new VM. There are lots of helpful notes in this blog post, although thankfully not all of them still apply.

Is it Ruby 1.9? generally gives one a good sense of whether just running gem install foo will work, but is often lacking when it doesn’t. Some research will likely be required if you have a lot of gems.

Some gems just worked

sudo gem install hpricot \
                 rake \
                 rack \
                 rails \
                 will_paginate \
                 rdiscount \
                 fastthread \
                 passenger

Mongrel

Getting Mongrel to even run was ludicrously complicated. Here are the steps I followed to do so, but before I list them I should note that I don’t think that this is generally worth doing, unless for some reason you can’t possibly switch to an alternative web server such as Passenger.

The changes you’ll need to make to the Mongrel source code concern references to the objects of the underlying C implementation: since Ruby 1.9 is based on an entirely new virtual machine, any direct references to MRI objects have to be changed to instead refer to YARV ones.

Hack ext/http11/http11.c file to replace references to RSTRING(foo)->ptr with RSTRING_PTR(foo), RSTRING(bar)->len with RSTRING_LEN(bar), RARRAY(baz)->ptr with RARRAY_PTR(baz) and RARRAY(qux)->len with RARRAY_LEN(qux)
Run sudo ruby setup.rb && sudo make && sudo make install
Copy the mongrel.gemspec file to your RubyGems specifications directory as mongrel-1.1.5.gemspec

Obviously those changes won’t work on Ruby < 1.9. Ryan Bigg has a 1.9-compatible version, although I haven’t tried it personally.

While I did get Mongrel working, it didn’t play nicely with Rails 2.3.2 at all, so in the end I just dropped it and installed Passenger instead, which is much better in this regard, and a lot lower-maintenance. After removing Mongrel I cleaned up the following:

Config files in /etc/mongrel_cluster/
A symlink to one of the gem files in /etc/init.d/ to restart the cluster if the server rebooted
A load of mod_proxy_balancer cruft in my Apache configs

Coda Hale’s grown up server was a great hack, but its time is past. Slicehost have good articles on installing Passenger and using it to serve your application, but it’s basically very straightforward.

MySQL

The MySQL gem on RubyForge is outdated and not completely compatible with Ruby 1.9. The updated gem has to be built by hand, which is a fairly uncomplicated process.

Updating applications

Most of my application code just worked. The only real changes I had to deal with were those concerning the new String class, but these are well documented and shouldn’t be a surprise to anyone upgrading an application or library to work with 1.9. If in future I run across any other issues, I’ll add them in a supplementary section below.

The new String class

James Edward Gray II has written some very helpful articles on Ruby 1.9’s new String class and default encodings. They proved invaluable when trying to track down bugs in code written for Ruby 1.8.6 (most of the fruits of my labours in this regard are visible in URLify).

Backwards-incompatible Tempfile changes

After upgrading to Ruby 1.9.1-p243, Books on Extralogical died, with Passenger reporting an IOError. Apparently a change was made to Tempfile#unlink to fix some issues with the library on Windows, resulting in a behaviour change that broke programs on *nix systems. I edited the library file and reverted the change, which fixed the application. Hopefully a future version of Ruby will revert this change, or it will be fixed at the library level in Rack. Here’s the path to the file in question on my system:

/usr/local/lib/ruby/1.9.1/tempfile.rb

Update, 26^th August 2009

This behaviour has been reverted for the Ruby 1.9 development branch, and the fix will be backported to the 1.9.1 branch. Many thanks to Hongli Lai for pursuing this.

Update, 7^th January 2009

Having switched to Gemcutter as my primary gem source, I’ve removed the GitHub gem source details from the article.

In conclusion

In the end, only two things caused me any trouble: installing Mongrel, and installing MySQL. The latter was relatively painless once I found the right version of the library; I really don’t know why the newer version isn’t available on RubyForge. The former was a complete pain, and my advice is to scrap any Mongrel-based setup and install Passenger from the get-go—it’ll be quicker than trying to hack your old setup back together. Now that Passenger is available for nginx as well as Apache, the case is thoroughly compelling.

Paper Cuts

2009-08-23T10:04:52Z

Today I removed a few sharp edges from Paper Trail, the web application I use to keep track of my reading. It’s cheering to cross a couple of items off the issues list, although there always seem to be new ones to replace them.

Removing authentication

As a single-user application, the idea of having an entire authentication system in Paper Trail always seemed ridiculous. Obviously some form of authentication was required, so I threw together a simple and horribly insecure system based on Ryan Bates’ Super Simple Authentication.

That has now been replaced by a single naïve check—was the request made over SSL or not? Clearly this depends on the web server only allowing authenticated users to access the site via HTTPS, but since no one other than myself needs to access the site securely, this seems a reasonable approach, albeit not one that would work for any application requiring multiple users to authenticate. Regardless, it’s cheering to be able to simultaneously increase security and reduce the codebase.

Dropping accents with URLify

One thing that Paper Trail needed right from the start was a way to simply and cleanly replace letters with diacritics, e.g. replacing “é” with “e”. On a couple of occasions I’ve wanted to use the small conversion library I wrote in other applications, so extracting it into an external library was a natural move. It’s called URLify, and its tiny public API is explained in the README.

Multiple authors

The other major piece of functionality added since the initial launch was support for multiple authors, which was actually completed some months ago. Thus far I’ve only used it for All the President’s Men, although I suspect it will be more useful in the future as I start finishing—and not just starting—various books in my technical library.

Generating CSS With Stylish

2009-05-07T19:15:56Z

Writing CSS can be a frustrating experience. Browser incompatibilities bedevil one’s every move; the speed with which improvements in the specification are actually implemented by vendors is glacial; and everywhere, one is forced to copy and paste code with minor variations, simply to work around some fundamental limitations in the language.

There seems to be little that developers can do to rectify the first two problems, but solving the third is within our grasp. Stylish is my attempt at doing so. It’s a small Ruby library which allows one to generate stylesheets programmatically, via the use of a simple but powerful DSL.

When attempting to reduce code duplication (and the transcription errors which accompany it), two major weaknesses in CSS spring immediately to mind: the lack of variables, and the lack of iteration. Consider the common use case of developing minor variations on a site’s style:

.autumn a {color:#90211c;}
.autumn a:hover {color:#bb5f1b;}

.winter a {color:#16335f;}
.winter a:hover {color:#5a9bce;}

.spring a {color:#448e1c;}
.spring a:hover {color:#6bcf35;}

.summer a {color:#c8ad1a;}
.summer a:hover {color:#d3482c;}

Here we have four groups of rules, each with the same pattern but slightly different values for their selectors and declaration values. Using Stylish, we can write a small snippet of code to generate the correct structure, giving us a template which we can pass variables into.

style = Stylish.generate do
  rule :season do
    a :color => :link
    rule "a:hover", :color => :hover
  end
end

Now we need to map those variables–:season, :link and :hover–to some actual values. Note that variables are only supported for selector and declaration values, not declaration properties.

seasons = [{:season => ".autumn", :link => "90211c", :hover => "bb5f1b"},
           {:season => ".winter", :link => "16335f", :hover => "5a9bce"},
           {:season => ".spring", :link => "448e1c", :hover => "6bcf35"},
           {:season => ".summer", :link => "c8ad1a", :hover => "d3482c"}]

Finally, we can generate some CSS code. Calling to the to_s method on the style object serialises the structure we initially created, filling in the variables with concrete values from our mappings.

seasons.each do |season|
  puts style.to_s(season)
end

The entire script is available; a couple of other examples can be found in the project’s example/ directory. Installing Stylish, assuming that you have Ruby and Rubygems, is as simple as typing the following command into your terminal.

sudo gem install ionfish-stylish -s http://gems.github.com

I’ve published a fairly comprehensive introductory tutorial on the Stylish documentation site. It eases the reader into developing with Stylish through a series of code examples which demonstrate all the main features of the stylesheet generator.

Big Exit

2009-01-23T15:16:39Z

Most sensible programming languages, and plenty of other applications, have an REPL, or read-eval-print loop. They’re a good way of trying out simple commands, running scripts and so on. The trouble is, I can never remember how to leave the damn things, because they all have different ways of issuing the quit command.

Language designers like ‘Quit’ to be a command or procedure in the language itself; something syntactically and semantically correct that wouldn’t be out of place in a file of source code written in that language. In principle this is exactly right; in practice, it means every REPL implements ‘Quit’ differently, and as soon as you use more than three or four, they become harder and harder to remember. Here are a few I use fairly often.

Ruby (IRB)

> exit

In this context, exit just looks like a keyword, but it’s actually a method on the main object. If you call self.exit at the IRB prompt it’ll have the same effect.

JavaScript (Rhino)

> quit();

A function call; entering quit without the parentheses will just return the function, not call it.

Scheme (mzscheme)

> (exit)

Parentheses required, of course, since Scheme is a Lisp and exit is a procedure.

Haskell (GHCi)

> :quit

This one’s a command, as opposed to a statement in the language (Haskell is an essentially declarative language, and thus involves making statements rather than calling commands). There are a lot of useful commands in GHCi; type :? and it’ll list them for you.

MySQL

> \q
> quit
> \quit
> exit
> \exit

These all work. There might be more.

SQLite

> .exit

The dot prefix distinguishes SQLite commands from SQL queries.

Bookkeeping

2009-08-23T10:04:13Z

Quite some time ago, I started work on a program to help me keep track of my reading. It’s not entirely clear to me, even now, whether it was meant to represent a litany of achievement, to cement the ideas I read about by jotting them down, or whether it was just an exercise in literary accountancy. What is certain is that I wanted two things: a working piece of software, and a testbed for any number of new skills and techniques.

I’ve actually been using Paper Trail for a few months now, and the sharp-eyed amongst you will have noticed the Books link at the top of the site. Books on Extralogical is a record of the books I read, and secondarily a set of brief reviews. I’d like to get more of them in the state that the Hackers & Painters one is—that’s to say, a few paragraphs summarising what the book’s about and my general reaction to it. Currently, too many of the reviews are lacking either a decent précis or any editorial content, or are just badly written. That being said, I actually dropped the requirement for a review during development because I found it stopped me adding the books as I read them.

Paper Trail probably only works well in newer versions of Firefox, Safari, and possibly other advanced browsers. This is because it uses a bunch of CSS3 properties, and plenty of 2.1 ones that aren’t supported in Internet Explorer 6. The main content should remain accessible, if not as visually appealing as it could be, in most older browsers.

One exception is this histogram showing how many books I’ve read per month over the past year. It’s an SVG image, which Internet Explorer and most older browsers don’t support.

Most of the work hasn’t been on user-facing code at all, but on the writing side of things. There is no admin area: editing is integrated into the site proper. A logged-in user sees a few controls and can easily fix a typo here or rewrite a paragraph there. I’ve striven to make things simple and seamless. There’s a certain amount of JavaScript involved, with more to come as I add things like autocomplete to the authors field.

Obviously when it comes to an interface, words only go so far. Far better to check out the source code, run it locally, and have a play around. It’s an extremely simple application, but I think it achieves its modest aims reasonably well. The code is available under the GPL.

Theme Inheritance

2009-01-13T13:35:39Z

When I first read about WordPress child themes on the wp-hackers mailing list, I wondered why I hadn’t realised that feature existed. One reason it hasn’t been more widely publicised is that it wasn’t, as it stood, terribly useful. All it allowed you to do was use the templates of one theme (the parent theme) and the stylesheet of another (the child theme). You couldn’t use it to create a child theme which inherited most its template files from its parent theme, but overrode some with its own files. That has now been remedied.

Consequently, in WordPress 2.7 it will be possible to write child themes which add new templates, and override existing ones in the parent theme. This has drastic implications; Ian Stewart, who proposed the patch, thinks it “may change everything”. It makes it much easier to create new themes, yes, but even more radically, it allows users to modify existing ones without changing their code. They can modify their Tarski installations to their heart’s content, while still being able to take advantage of bug fixes and improvements.

New templates

Tarski doesn’t come with a template for the Clean Archives plugin, although it used to, and one is available from Tarski’s svn repository. But if you add it to your Tarski directory, you might forget to back it up when you upgrade (I’ve done this a few times). So you create a child theme, which inherits from Tarski, and includes the Clean Archives template—which will automatically appear in the list of available page templates.

Overriding parent templates

One thing a couple of people have requested in the past is more comprehensive author templates for Tarski, with photos, contact details and so on. I’ve been loathe to add this, which leaves people in the position of having to hack the template, and then try copy their changes into the new template when they upgrade Tarski—or worse, not upgrade at all. With a child theme they could just copy Tarski’s author.php template, make their changes, and override Tarski’s template with their own. They could then upgrade safely without having to carry any changes across.

Frameworks

Greater possibilities are now also opened up for treating themes more like frameworks or plugins. Perhaps you love Tarski’s feature set but hate the layout. Simple: keep the options page, the navbar selector, the numerous templating functions, but write your own templates. We may see themes that are more of a code library than a set of templates.

No doubt there are plenty of applications I haven’t even considered yet. It’s time for your imaginations to take over: download the trunk version of WordPress, and start hacking.

The State of the Art

2009-01-13T13:35:39Z

WordPress 2.6 is the kind of release I’d like to see the WordPress team doing more often. It contains some clever stuff, like post revisions, along with a load of bug fixes, and it didn’t take too long to develop. In the past WordPress has taken far too long between releases; a reasonably quick turnaround and a predictable release schedule make life a lot easier for those of us writing code that depends on the core.

Matt was kind enough to mention me in the release notes, but in truth I hardly did anything. These days I seem to be so busy that keeping my own projects up to date is proving beyond me, let alone contributing to things like WordPress. Finally pushing Tarski 2.2 out of the door was stressful enough to put me off continuing its development. I suspect that from this point on it’s going to enter maintenance mode, hopefully keeping pace with WordPress development in terms of feature support, but no more.

I had the pleasure of road-testing the new theme directory that Joseph Scott has put so much hard work into. I’m not sure yet how the API is going to work, but I imagine we’ll see update notices and one-click upgrades just like those for plugins. This will mean I’ll be able to drop Tarski’s own update mechanism, which will make the core code a little bit leaner and remove what’s proved to be an ongoing headache, despite the hard work of those who’ve helped me debug the various problems it’s had. You can grab Tarski from the theme directory.

In all honesty, developing in PHP with Subversion as my version control system is starting to feel very tedious. Fiddling with some WordPress hooks earlier today, I pondered how much easier it would be to do simple things if PHP had first-class functions. You could do something like this:

add_filter('the_content', function($content) {
  return '<div class="content">' . $content . '</div>';
});

Which, of course, looks a lot more like JavaScript than PHP, but despite the bad parts I’d much rather write JavaScript than PHP—and, lately, have been.

No Smoking

2009-01-13T13:35:39Z

At school we learned how to buy train tickets in French, and in the process discovered we needed to make an alien specification: fumeur ou non-fumeur? British Rail—at it may no longer have been by then, but as I still thought of it—had outlawed smoking on its trains years before. Notices on every window reminded one with threats of sanctions.

The maximum fine was £500, while on the buses it was £2000; a curious incongruity. After all, they were both grubby, unpretentious, overworked components of our public transport network. If anything, the train was a grander mode of transport—and this, I thought, should have been reflected in the fines.

Transport was the prism through which I encountered the world—a world on the move. People stared distractedly at their newspapers or out of the window, attempting to transport their minds from their prosaic surroundings just as the train transported their body through drab suburbia, from Twickenham to Clapham Junction and thence into the city. Rusting gas holders, blackened bridges, concrete tower blocks and horrid bungalows all flowed past as we clattered towards Waterloo. Occasionally one would catch a whiff of illicit cigarette smoke—but not often.

Now smoking has departed that other bastion of public life: the pub. The smokers have been kicked out, just as they were from the buses and trains. But unlike the proletarian local rail and bus networks, where there are no First Class carriages and everyone rides together, pubs and bars exhibit the same stratification as society. Barring undesirables is easy—just price them out. If they can’t afford three-fifty a pint, then by definition they’re the wrong sort.

London is too much in my blood to spurn it easily, but some grey days the grime and money and poverty—and the attitudes they bring with them—just grind me down. Between themselves, Londoners do nothing but moan about their city; put them in a room with someone from anywhere else and they’ll defend it to the death as the greatest in the world. Hardly surprising it didn’t make Monocle’s top 20 liveable cities: ambivalence, for those with open eyes, is our defining attitude.

Detect Current Page Template

2009-01-13T13:35:39Z

On the back of my hooks article last week, here’s another potentially useful WordPress trick I’ve picked up: detecting the current page template.

No SQL required

The beauty of the WordPress API is that in most situations, you can pull the values you need from the database without writing lines of SQL code. For example,

global $post;
get_post_meta($post->ID,'_wp_page_template',true);

This returns the template being used by the current page—for example, running it on my archives page would return the value archives.php, while doing it on my about page would return default. The function get_post_meta is documented in the Codex, but basically, it grabs some data from the wp_postmeta table of the database, which is used to store custom fields, including the post template.

A trip through `postmeta` land

By using the WordPress-generated $post variable, we avoid having to talk to the database directly; $post->ID returns the ID value of the current post, which can then be checked against the records in wp_postmeta. Since we want to return the page’s template, our second argument calls the key _wp_page_template, so the function will only return values with that key.

By default, the function returns an array, but by setting the third argument to true we can make it return a single result (the first one, although it’s pretty unlikely that a page has two _wp_page_template values. Obviously this technique can be extended to return the values for other custom fields, but I’ll leave that as an exercise for the reader.

The why of it

This trick could be useful for any number of things—I’m using it in Tarski to check whether a given page is an archives page, and to include or exclude certain things based on the result.

Obviously if I were just doing the include directly in the archives template, this wouldn’t be a problem, but since I’m actually calling a hook that’s present in a number of other templates, there’s no way I can tell in advance whether a given page is an archives page or not. In effect, I’m putting the coding burden onto my actions and filters, so as to not impose an overly restrictive system on end-users who might want to do something entirely different.

Coda

As a non-programmer myself, I’m always trying to work out how to do fairly simple things in WordPress. If people are interested, I could carry on writing up these code tips, so let me know what you think in the comments.

Amendment, 5^th November 2007

If you’re on the WordPress trunk, instead of bothering with all this malarky just use the is_page_template function which was added in revision 6228. It will be in the 2.4 release when that comes out, and it uses essentially the same technique as I’ve described here, albeit with—as you’d expect—much more complete error handling.

Adding Custom WordPress Hooks

2009-01-13T13:35:39Z

All theme authors should have a vague idea of what WordPress hooks are: those things you have to remember to add to your header to stop plugin authors yelling at you. More technically, they’re a way of adding to or altering the content that WordPress outputs.

There are a fair few built into WordPress, and a number need to be correctly implemented by theme authors, but I don’t propose to go into that here. What I’m going to run through in this article is how you can add your own actions and filters to your theme, to make it more flexible and customisable.

Before I get started, a couple of notes on the WordPress development environment. Firstly, updates break things. When WP 2.1 came out we had to rewrite our SQL code to work with the new database structure. 2.2 brought widgets into the core and the link in Tarski’s Options page (which was pointing to the widgets plugin page) no longer worked. For 2.3 we’re going to have to strip out our UTW code and make the theme work with the new tagging system. In other words, themes need to be kept updated, even though this will destroy any alteration of the theme’s files. Themes should come with tools that allow customisation but don’t require the alteration of core files. Users shouldn’t be deterred from upgrading by the prospect of losing their tweaks—which of course is why plugins exist.

Anatomy of a theme hook

There are two kinds of hooks: actions and filters. This article deals mainly with actions, since they’re generally simpler, but all its lessons can be applied to filters without much difficulty.

Theme hooks are just functions; wp_head is a good example of one. It’s defined in wp-includes/general-template.php, and the definition is amazingly simple:

function wp_head() {
    do_action('wp_head');
}

The do_action function that does the hard work, tying the wp_head function into WordPress’s hooks system. It’s incredibly simple to add new hooks in the same way.

Adding custom hooks

There are three steps to adding a custom hook to a theme. Firstly, add the hook function. Secondly, add the action to your theme in the spot where you want it to be executed. Thirdly, you can add a function defining the default behaviour—for example, if you were writing a hook for a header image, you’d need to write something to display a header image. Lastly, tie the two together with add_action. Note that the third and fourth steps are optional; your hook doesn’t have to do anything by default.

Since I’ve been working on adding hooks to Tarski, I’ll use an example from there. Unless stated otherwise, this code is being added to the theme’s functions.php file which is automatically included by WordPress. Below is the action definition: it adds an action named th_header to WordPress’s hooks listing.

function th_header() {
    do_action('th_header');
}

I then added the function call to the header template, so that whenever that template file is called it will do whatever actions have been added to the th_header hook:

<?php th_header(); ?>

Originally I was just going to use this to add a header image, thinking that if people wanted to make their header image rotate randomly, or display page-specific headers, they could do that with a plugin. But then I realised I could use the same hook to also display the title and the tagline. To do this, I just reused the existing header image, site title and tagline functions, and then added these lines of code to make the hook call them:

add_action('th_header','tarski_headerimage',5);
add_action('th_header','tarski_sitetitle',6);
add_action('th_header','tarski_tagline',7);

Notice that the first argument is the same for all three lines: th_header. This is the hook to which the actions are being added. The second argument is the actions (which, of course, are just functions which we’ve defined elsewhere). The third argument is the priority—the order in which the actions should be performed. This will make the header display first; then the title; then the tagline.

Tweaking with a plugin

Now the theme has its hooks, how does all this customisation work? It’s very simple—just write a plugin. This can be completely independent of the theme, so you can update the theme without fear of losing your tweaks (because they’re all in the plugin). I don’t propose to cover the basics of plugin development here; try this tutorial, or this one.

First things first: what do we want to do? Well, how about writing a little “About this site” blurb and adding it below the tagline? This is very easy: just add the function to output the blurb to your plugin, and then add an action to the requisite hook.

function output_about_text() {
    echo '<p>This site is amazing.</p>';
}

That does it for the text; how about the action?

add_action('th_header','output_about_text');

Notice that we didn’t add a priority; this value defaults to 10, so the about text will be displayed after the tagline. If you want to add it before the header image, for example, try this:

add_action('th_header','output_about_text',4);

Let’s now turn to a more complex example: replacing the header image with page-specific headers. Again, just write the function:

function page_specific_headers() {
    if(is_home()) {
        echo '<img alt="Home" src="home-page-header.gif" />';
    } elseif(is_page('about')) {
        echo '<img alt="About" src="about-page-header.gif" />';
    } else {
        echo '<img alt="Header" src="general-header.gif" />';
    }
}

Then we need to do two things: add the new action, and remove the default one.

remove_action('th_header','tarski_headerimage',5);
add_action('th_header','page_specific_headers',5);

This should remove the default header image, and replace it with the page-specific one. Note that the priority needs to be specified for both the action being removed (since it’s set in the default action) and for the action being added (since we want the header to be displayed in the same place, before the title and tagline).

Theme hooks in this mould will be a new feature in Tarski 1.5. If you want to try them out in the meantime, just check out the latest build from our Subversion repository.

Extralogical

Ruby One Niner

Installing Ruby

Installing gems

Some gems just worked

Mongrel

MySQL

Updating applications

The new String class

Backwards-incompatible Tempfile changes

Update, 26th August 2009

Update, 7th January 2009

In conclusion

Paper Cuts

Removing authentication

Dropping accents with URLify

Multiple authors

Generating CSS With Stylish

Big Exit

Ruby (IRB)

JavaScript (Rhino)

Scheme (mzscheme)

Haskell (GHCi)

MySQL

SQLite

Bookkeeping

Theme Inheritance

New templates

Overriding parent templates

Frameworks

The State of the Art

No Smoking

Detect Current Page Template

No SQL required

A trip through postmeta land

The why of it

Coda

Amendment, 5th November 2007

Adding Custom WordPress Hooks

Anatomy of a theme hook

Adding custom hooks

Tweaking with a plugin

Update, 26^th August 2009

Update, 7^th January 2009

A trip through `postmeta` land

Amendment, 5^th November 2007