1. Beer Alchemy Integration

    As I mentioned in my previous post, my beer recipes are now online.

    I've had several people ask me how this is done, so I think a post is in order.

    While it's entirely possible to brew beer at home without any fancy gadgets, there are several tools I use (such as my refractometer) that make the process easier, more controlled, or both. Brewing software is one of the few instruments that I'm not sure I'd want to brew without. I use a Mac, primarily, so Beer Alchemy (BA) is the obvious choice for recipe formulation, calculation, and logging.

    BA has its own HTML export mechanism for recipes, and I used this for quite a long time, but I was never really satisfied with the results. The markup was hard to style, contained a lot of clutter (occasionally useful, but often redundant information such as style parameters), and simply didn't fit well with the rest of my site.

    Beer Alchemy HTML Output

    You can also export from BA in PDF (not suitable for web publishing), ProMash's binary recipe format (a pain to convert, although there do seem to be some tools to help with this), BeerXML (normally the most accessible, but in my opinion, a poorly-designed XML format), or in BA's native .bar ("Beer Alchemy Recipe") format, which is what I chose.

    Beer Alchemy Recipe Export Dialog

    The bar format contains a property list, similar to those found throughout Apple systems. Property lists are either binary or XML (but the XML is very difficult to work with using traditional tools because of the way it employs element peering instead of a hierarchy to manage relationships). Luckily, I found a project called CFPropertyList that allows for easy plist handling in PHP. (I even contributed a minor change to this project, a while ago.)

    Once you've run the .bar file's contents through CFPropertyList, layout is very simple. Here's most of the code I use to generate my recipes:

    <?php
    $beerPath = __DIR__ . '/../resources/beer/';
     
    $recipes = apc_fetch('seancoates_recipes');
    $fromCache = true;
    if ($recipes === false) {
    	$fromCache = false;
    	foreach (new DirectoryIterator($beerPath) as $f) {
    		if ($f->isDot()) {
    			continue;
    		}
    		if (substr($f->getFilename(), -4) != '.bar') {
    			continue;
    		}
    		$cfpl = new CFPropertyList($beerPath . '/' . $f->getFilename());
    		$recipe = $cfpl->toArray();
    		$title = $recipe['RecipeTitle'];
    		$recipes[self::slugify($title)] = array(
    			'title' => $title,
    			'content' => $recipe,
    		);
    	}
    	asort($recipes);
    	if ($recipes) {
    		apc_store('seancoates_recipes', $recipes, 3600); // 1h
    	}
    }

    In addition to displaying the recipe's data, I also wanted to show the approximate (calculated) beer colour. Normally, beer recipes declare their colour in "SRM" (Standard Reference Method). There's no obvious, simple, and direct way to get from SRM (which is a number from 0 to 40—and higher, but above the mid 30s is basically "black") to an HTML colour.

    I found a few tables online, but I wasn't terribly happy with any of them, and keeping a dictionary for lookups was big and ugly. I like the way Beer Alchemy previews its colours, and since it has HTML output, I emailed the author to see if he'd be willing to share his algorithm. Steve from Kent Place Software graciously sent me an excerpt from his Objective C code, and I translated it to PHP. This might be useful for someone, and since Steve also granted me permission to publish my version of the algorithm, here it is:

    <?php
    /**
     * Calculate HTML colour from SRM
     * Thanks to Steve from Kent Place Software (Beer Alchemy)
     *
     * @param float $srm the SRM value to turn into HTML
     * @return string HTML colour (without leading #)
     */
    public function srm2html($srm)
    {
    	if ($srm <= 0.1) { // It's water
    		$r = 197;
    		$g = 232;
    		$b = 248;
    	} elseif ($srm <= 2) {
    		$r = 250;
    		$g = 250;
    		$b = 60;
    	} elseif ($srm <= 12) {
    		$r = (250 - (6 * ($srm - 2)));
    		$g = (250 - (13.5 * ($srm - 2)));
    		$b = (60 - (0.3 * ($srm - 2)));
    	} elseif ($srm <= 22) {
    		$r = (192 - (12 * ($srm - 12)));
    		$g = (114 - (7.5 * ($srm - 12)));
    		$b = (57 - (1.8 * ($srm - 12)));
    	} else { // $srm > 22
    		$r = (70 - (5.6 * ($srm - 22)));
    		$g = (40 - (3.1 * ($srm - 22)));
    		$b = (40 - (3.2 * ($srm - 22)));
    	}
    	$r = max($r, 0);
    	$g = max($g, 0);
    	$b = max($b, 0);
    	return sprintf("%02X%02X%02X", $r, $g, $b);
    }

    Here it is, in action, in JavaScript this time:

    SRM: =
     
  2. A new seancoates.com

    Over the past few weeks, my business partner Cameron and I have spent evenings, late nights, and weekends (at least partially) working on a much-improved seancoates.com.

    If you’re reading this via my feed, or through a syndication outlet, you probably hadn’t noticed.

    The primary goal of this change was to reduce (hopefully even remove) the ugliness of my main presence on the Web, and I’m very happy with the results.

    In addition to making things look nicer, we also wanted to improve the actual functionality of the site. Formerly, seancoates.com was a blog, with a couple haphazard pages thrown in. The new version serves to highlight my blog (which I fully intend to pick up with more frequency), but also contains a little bit of info about me, a place to highlight my code and speaking/writing contributions, and a good place for me to keep my beer recipes.

    Cameron came up with the simple visual design and great interaction design, so a public “Thank You” is in order for his many hours of thought and contribution. Clearly, the ugliness reduction was his doing (due to my poorly-functioning right brain).

    I’m very happy with how the site turned out as a whole, and thought I’d outline a few of my favourite bits (that might otherwise be missed at first glance).

    URL Sentences

    The technique of turning URLs into sentences was pioneered by my friend and colleague Chris Shiflett. Cameron (who shares studio space (and significant amounts of beer) with Chris) and I both like this technique, so we decided to implement it for my site.

    The main sections of the site are verbs, so this was pretty easy (once we decided on proper nomenclature). Here are a few examples:

    • seancoates.com/blogs – Sean Coates blogs…
    • seancoates.com/blogs/about-php – Sean Coates blogs about PHP (my “PHP” blog tag)
    • seancoates.com/brews – an index of my published recipes
    • seancoates.com/brews/coatesmeal-stout – the recipe page for Coatesmeal Stout

    To complement the URLs, the page title spells out the page you’re viewing in plain language, and the visual site header indicates where you are (while hopefully enticing you to click through to the other sections).

    Moving my blog from the root “directory” on seancoates.com to /blogs caused my URLs to break, so I had to whip up yet another bit of transition code to keep old links functioning. Even links on my original blog (which was hosted on blog.phpdoc.info) should still work. If you find broken links, please let me know.

    Vertical Content Integration

    My “/is” page contains feeds from Twitter and Flickr.

    The Twitter integration was pretty simple; I use the JSON version of my user feed, but I didn’t want to include @replies, so they’ve been filtered out by my code. If the fetch was successful, the filtered data is cached in APC for a short period of time so that I’m not constantly hammering Twitter’s API.

    Flickr’s integration was also very simple. After a run-in with some malformed JSON in their API, I decided to integrate through their Serialized PHP Response Format. The resulting data is also cached in APC, but for a longer period of time, as my beer tasting log changes much less frequently.

    Code Listings

    Displaying code listings on a blog isn’t quite as easy as it sounds. I recently had a discussion with a friend about redesigning his site, and he was considering using Gist from Github’s pastebin-like functionality. Doing so would have given him easy highlighting, but one thing he hadn’t considered was that his blog’s feed would be missing the embedded listings (they come from a third party, and wouldn’t actually appear in his feed’s data stream).

    Another problem we faced was one of space. While I often try to keep code to a maximum of 80 (or slightly fewer) characters wide, this isn’t always possible. Injecting a line break into the middle of a line of code is risky, especially for things like SSH keys and URLs. This problem is usually solved by setting the content’s CSS to overflow: scroll, but that littered Cameron’s beautiful design with ugly platform-specific scroll bars. “Clever” designers and developers sometimes overcome this by implementing “prettier” scroll bars, but I’m strongly against this behaviour, so I wouldn’t have it on my site.

    I’m quite happy with our eventual solution to this problem. Now, when a blog post contains code that extends beyond the normal width of the blog’s text, the right-most part of the text fades to white, and the listing is clickable. Clicking expands all listings on the page to the minimum width that will accommodate all embedded code.

    Here's some example code that stretches much wider than this column would normally allow.
    Injecting line breaks is dangerous. Here's why: http://example.com/obviously/not/a/sentence/url
    Breaking that in the middle is far from ideal.

    jQuery saved me hours of development work here, and I couldn’t recommend it more highly. Highlighting is provided by a plugin that I wrote a couple years ago. It uses GeSHi to highlight many languages. I’ve never been very happy with GeSHi’s output, but it’s Good Enough™ until I can find time to implement a better solution that uses the Tokenizer for PHP.

    Software

    In addition to PHP, this site integrates a custom version of Habari, with our own theme and plugins. One of those plugins allows me to keep my blog posts in HTML files in my Git repository, to make for much easier editing, greping, etc.

    Everything except /blogs was built within the Lithium framework. It handles all of the boring stuff like controllers, routing, and templates, so I didn’t have to write that code myself (which I find incredibly boring these days).

    Hashgrid was invaluable in ensuring that the site aligns with a visual grid (again, thanks to Cameron’s meticulous expertise). Pressing your g key will show the grid he used. I even made a few improvements to how Hashgrid works, which I hope to eventually see in the master branch.

  3. Post-ConFoo

    Today I am back in the (home) office after speaking at ConFoo last week.

    I gave two talks:

    Despite some timing issues (as is always the case for me with new talks), I think both sessions went well. I got some good, constructive feedback from attendees on how the talks could be made better, and if I get the opportunity to give them again, I'll definitely take it into consideration.

    Because PSAV (not the conference organizers' fault, other than trusting PSAV—a lesson all conference organizers eventually learn) was its normal bucket of fale, conference Internets weren't exactly usable. I was lucky enough to be in my home country (for a change), so I was able to tether on 3G for most of the week, and that kept me and a few others online. However, I think that most attendees didn't have the same opportunity, so if you attended one of my talks, I'd greatly appreciate it if you could head over to joind.in and post a comment or two about what you thought (talk-specific links above).

    After the conference ended, Andrei stayed at my place.

    On Saturday, we brewed a second annual batch of Белый, which—if all goes well—will end up at 11.5%ABV. Maybe it will be ready for next year's ConFoo. (-:

    We decided to take it easy on Sunday… sort of. We spent most of the afternoon planning out a PHP extension we'd been talking about for several months: a highly-customizable and user-hookable PHP preprocessor. Afternoon turned to evening, turned to night, and by the time we turned in, we had a working—but not yet ready for release—extension. More details to come, but here's a teaser.

  4. A Messy Breakup with Drupal (Least Worst, Part 1)

    A little over two years ago, when I got involved with the MontreAlers (note: yes, site broken... read on), the homebrewing club in Montreal, I was quickly nominated to be the sucker who would help take their aging and mostly-neglected web site, and make it somehow useful.

    At the time, the choice was simple: custom code or Drupal. Because custom code takes quite a bit of the most valuable commodity in life—time—and because I had (and continue to have) very limited spare time, I chose Drupal.

    I hacked together a custom theme (based on one of the prepackaged templates), spent a few hours configuring modules, and spent probably an equal amount of time shaking my head at the procedural and poorly-designed (for small values of "design") plugin/extension API. I grabbed some pre-built modules, and cobbled together a reasonable community site. We didn't need much, and Drupal + a few plugins solved most of our problems.

    The site was a hit. Membership in the club has climbed from a handful of members to what's often a troublingly large number of attendees to our monthly meetings. There's no direct correlation to the site, but I think all of the MontreAlers would agree that it has played a role in connecting with new likeminded people.

    As with any project whose maintainer doesn't have sufficient available time, the site got dusty over the course of the first few weeks, then dirty over the next few months, and before we even realized, the site was in a state of partial disrepair. Databases were upgraded, hardware was swapped, DNS was migrated, and PHP versions were updated. Each of these tasks of regular maintenance were met with heightened amounts of finger crossing, cursing and furious patching. After upgrades or changes, I'd usually get inquiries about why certain functionality mysteriously stopped working, which often lead to more furious patching, cursing and finger crossing.

    Over time, minor inconveniences can easily snowball into what seems like one large, insurmountable problem. The last straw for ongoing my relationship with Drupal was upon upgrading the PHP version on my server to 5.3.

    Admittedly, 5.3 is fairly young, but I was ready to take on the challenge. I'm handy enough with PHP's changes that I felt confident that I'd be able to take on any problems that Drupal presented. The obvious first step, here, was to update Drupal to the most recent release. I don't remember the exact date of the upgrade, but I do remember my feelings clearly. It was the day I started actively searching for a Drupal replacement.

    The upgrade was extremely painful. There was no clear path to upgrading from our old, stagnant Drupal install to the newest version. Updating the code was a bit painful, but possible. The Drupal upgrader/installer did take care of the database update, which was my biggest worry, and there was some documentation on how to do this on the Drupal site, but I had to dig pretty deep to find it (and I've since lost the links, so I apologize that I can't link to the references I used).

    There were two main pain points: I had to manually patch Drupal to work on PHP 5.3, and some of the third-party Drupal modules the club now depended on were not possible to upgrade.

    The patching for PHP 5.3 was not entirely unanticipated, and was reminiscent of making fixes in broken array_merge()s when jumping from 4.3 to 5.0. The real problem here is that Drupal still maintains its code in CVS, so I gave up on submitting my patches upstream shortly after diffing and trying (to no avail) to find their subversion or Git repository. I thought PHP was the last significant project to move from CVS to SVN, but I was obviously wrong.

    I fully expect Drupal will (or maybe already has) catch up to the current release of PHP (aside: they had plenty of notice to get their code up to speed—PHP 5.3 was certainly long in the tooth by 5.3.0). The real problem with the latest upgrade was that some of our modules not only didn't work with the new version of Drupal, but there was often no available upgrade for them. Our event calendar went missing, user maps (home addresses for club meetings) disappeared, our photo gallery is completely AWOL. There may be suitable replacements (read: alternative functionality in other modules) for some of our wants and needs, but the fact remains that maintenance is painful, and "upgrades"—often for the purpose of plugging security holes—take much more time and effort than I have to give.

    The underlying code in Drupal is old. It seems brittle. It doesn't do things I'd expect modern software to do such as have a good inheritance model (hint: it's [almost?] all prodedural code), have self-documenting or intuitive APIs, and it does tons of things that I simply don't care about (I'll probably blog on this last thing as a general poisonous open source trend in another episode). It's more pain than it's worth at this point, and I just need it out of my life.

    So, Drupal, we're breaking up.

    But I don't have anyone else to go (more on my short list in a near-future entry).

    (Here's the rhetorical paragraph.) Is it too much to ask for PHP code to actually be well-written? It doesn't even need to be perfect. Habari is certainly far from perfect, and it has warts, but on a whole, it's good code. Is the barrier to entry for most projects too low? Or is there just a huge lack of experience in knowing how to do things right? Maybe all of the best people are too busy doing other things? Or maybe it's a community-management problem...? I don't know.

    When it comes to software, and especially web software, I find myself always settling for "Least Worst." Habari is Least Worst. Trac is Least Worst. MediaWiki, PHPMyAdmin, Roundcube: all arguably best-in-class, but under the hood, they're often painful. I suspect my expectations are simply too high. Should I just lower them? I don't know that either.