The official Twitter page quickly became inadequate to manage my tweets, so I began to search for an alternative through the myriad of Twitter clients available out there, both web and desktop based. After trying out a few desktop clients, I decided to restrict the search to web clients only: between work and home, I may use up to 4 different computers and 3 different operating system, and I really didn’t fancy the idea of keeping the same client up-to-date everywhere — even if such client existed.

Over the past months I tried dozens of different web-based Twitter clients, and narrowed the list of must-have features to the following:

• The interface should be simple to use and not too cluttered.
• I should be able to categorize tweets in columns (à la TweetDeck).
• I should be able to know, when visiting the site, how many new tweets I have to go through.
• I should be able to mark tweets as read.
• It should display media files (at least pictures) inline with the tweets.
• The interface should provide all the most common twitter actions like reply, retweet, follow/unfollow, shorten url, upload pictures etc. etc.

The good news is that I found at least one web-based client able to do all this: JournoTwit.

Introducing JournoTwit

JournoTwit was born – as many software projects – to scratch an itch:

Probably the last thing anyone was expecting me to do — even myself, was to create my own twitter client. However, I’ve been a little fed up with not having the features I wanted and running 5 or 6 accounts, I was getting annoyed at using several different applications just to have them logged in concurrently. […] In under 24 hours I put together a twitter client that functioned enough for me to call it my one and only. A few more days and I added in enough features that I felt it was good enough for public consumption. It is however, not perfect and I have plenty of improvements on my to do list for it.

JournoTwit’s introductory post by Andrew Spode Miller (@spode)

After months of public consumption, JournoTwit became a feature-packed Twitter client able to compete with a lot of mainstream alternatives – albeit remaining always relatively unknown to the masses. You can call it a niche Twitter client, able to satisfy a few basic needs:

• The ability to manage multiple Twitter accounts at once.
• The ability to categorize all incoming tweets automatically, according to the type of information within them.
• The ability to keep track of unread tweets.

These three features alone were enough to make JournoTwit my one and only Twitter client. And no, it’s not only for journalists and writers.

Interface overview

After logging in, JournoTwit looks like this:

Note: I am using the edge version of JournoTwit, a sort of development snapshot with the latest features.

At the top, some more-or-less intuitive icons allow you to perform all the most common global actions:

• Tweet
• Manual refresh
• Mark all columns as read
• Add new columns
• Quick search
• Edit settings
• Logout

Next to this global toolbar, there’s a list of links, each corresponding to a column. Clicking a link toggles the visibility of the corresponding column.

In each column, tweets are displayed in different column according to their state:

• Read
• Unread
• Selected

You can select one tweet at a time by clicking the + icon. This toggles the tweet-specific actions:

• Reply
• Send a direct message
• Save as favorite
• Retweet
• Translate

Pretty intuitive and easy to use, so far.

Default columns

When you login, you’ll notice that all your tweets are not presented in the traditional, disorganized single-column stream layout. Instead, they are sorted automatically into different columns, according to their type:

My Feed

All the tweets you sent. By default, this column is minimized.

No-Mention

All tweets containing your username without the “@”, i.e. every time someone mentions you sneakily, without sending you a reply.

Messages

All the direct messages you sent and received.

Mentions

All the tweets containing your twitter username (with “@”), such as replies to your tweets.

Statuses

All the tweets posted by people you follow that do not contain any link or cannot be categorized through other columns.

News

All the tweets posted by people you follow containing links to articles or non-multimedia web pages.

Retweets

All the retweets posted by people you follow.

Visual

All the tweets posted by people you follow containing links to pictures or videos. Where possible, media is displayed inside the tweet.

Audio

Same as above, but for audio items.

Chatter

Attempts to collect all conversations involving you or people you follow.

Surprisingly, these default columns are enough to make your Twitter experience easier and more manageable, without configure a single setting. They’re obviously not perfect: some images are not resolved automatically, for example, but it works well otherwise.

Still this may not be enough for your needs or maybe simply not the right thing. No problem: JournoTwit is extremely flexible when it comes to organizing and sorting out your tweets.

Adding new columns

All columns except for Mentions and Messages can be modified as you see fit. These two columns cannot be modified simply because there’s nothing you need to modify it, if you think about it. But they can be deleted, of course (and re-created in a blink, if you delete them by mistake).

Let’s go through the slightly geeky process of creating a column.

When you click the Add New Columns icon on the top-left corner you’ll be prompted to further clarify whether you want to add a…

• Set of Columns: i.e. the default columns provided by journotwit or a single column containing all the tweets. Useful if you mess things up and you want to start over again.
• Preset Column: choose from many different columns according to your needs, from different tweet types to memes (#followfriday, #musicmonday, etc.).
• Custom Column: create your own personal column, according to your specific needs.

Because the overwhelming majority of my readers is composed by geeks, I’ll just describe how to create a custom column, so that you can fully understand the power of this tool, in the right hands.

Adding a custom column

The creation of a custom column doesn’t take long, but there are quite a few things you can configure. First off, you have to specify whether you want the column to collect local or global tweets: local means the people you follow, while global means everyone on the planet. Simple enough.

Then comes the juicy geeky part: search terms and tags. Simply type a valid Twitter Search query in the textbox, so something like this:

from:jonobacon OR #ubuntu -jaunty

…will hopefully fetch all tweets posted by @jonobacon or tweets about Ubuntu, but not related to the Jaunty Jackalope release. You can also add more text box and thus perform more search queries within the same column.

Then you can filter by tweet type, enabling or disabling Statuses, Visual, Links, Audio, ReTweets and Chatter. Useful to remove the noise (if you follow @brentspiner, make sure you disable ReTweets…).

Finally, you only have to configure a few more settings:

• Whether you want to be alerted with a beep when there are new tweets in this column.
• Whether you want the column to display tweets, a tag cloud or even an image slideshow.
• The name of the column.

That’s all. Simple enough. As a side note, the “No-Mention” column is nothing but a custom column in disguise: if you try to edit it, you’ll see it’s nothing but a search for “username -@username -from:username”.

Other features and advanced settings

For the tweakers, JournoTwit also exposes the a set of global settings you can modify to enhance your experience or disable annoying behaviors (depends how you look at it):

Behavior

• Unhide column when new tweets arrive? (default: yes)
• Hide columns on Mark as Read? (default: yes)
• Play alert sounds? (default: yes)
• Animate when new items arrive? (default: yes)
• Default #hashtags and search bar to a local search? (default: no)
• Ignore Tag Coulds when marking all as read? (default: yes)
• Ignore Slide Shows when marking all as read? (default: yes)
• Warn when deleting columns? (default: yes)
• Automatically translate tweets using Google Translate? (default: no)
• Show “Did You Know?” messages on refresh? (default: yes)
• Slide show transition time(s) (default: 5)

Display Adjustment

If you are unsatisfied by JournoTwit’s default look and feel, you can change the fond size, the color theme (there are 18 possible choices) and even match the color of the icons with the current theme.

Black Listing

Straight from the contextual help:

“Here you globally black list a #hashtag, such as #microsoft, or a search phrase such as “Windows 7”. Remember to separate them with a space and that you can block on a per column basis too."

This is just what you need when you want to filter out pointless tweets. Use with care though!

Conclusion

Maybe it’s just me being a geek, but I think JournoTwit nailed it when it comes to making Twitter more productive: everything just works, and fast, unlike some of its more feature-boasting competitors. I have been using it on a daily basis for weeks, and I’ve never missed a single tweet since (unless I explicitly wanted to do so).

That being said, there are a few small features I’d like to see:

• I’d like to be able to mark single tweets, not entire columns, as read. In this way, when I go on vacation and come back, I can catch up with unread tweets more gradually, like I do with Google Reader.
• I’d like to use shortcut keys to navigate the interface, like with Google Reader.
• I’d like to configure tweets so that they only show up in one column, not in more than one (for example in Chatter, My Feed, and Mentions at the same time).
• Support for Twitter Lists…

I already told @spode about some of these, and he said he’ll look into it, we’ll see what happens. Anyhow, just give it a try, and see if you like it!

It has been two years since my last post on this subject and yes, the cake is still rising, but at what price? Will it still taste sweet now that two of its main ingredients are not part of it anymore? As Daniel puts it, probably the best thing to do now is to drink tea and to wait until the dust settles…

As far as I’m concerned, what really matters is that Garrett Woodworth (former CakePHP Project Manager) and Nate Abele (former CakePHP Lead Developer) are gone. They realized they had enough Nuts over the years and they decided to switch to a more Lithium-rich diet. More helthy and depression-proof, too!

Stupid metaphors and painful jokes aside, this is probably the best piece of news the CakePHP community received in a long time: the birth of a fork of the CakePHP framework, more precisely of the so-called Cake3 branch.

Cake3? I didn’t keep up-to-date with the buzz, so I didn’t know anything about this until today, when I decided to finally start catching up.

“Cake 3.0, on the other hand, is pretty different from the existing core code in a few notable ways. Mainly, it’s been re-written from the ground up for PHP 5.3.”

from Cake 3 interview with Nate Abele, debuggable.com

Of course, in these three years of my full immersion in the Ruby language, I almost completely forgot about PHP too. PHP 5.3 means namespace and closures, i.e. the Rubyist’s daily bread. A more modular CakePHP, properly object-oriented, with an ActiveRecord-like API for models (finally!) is definitely worth a look, especially if it’s Nut-free as well.

The new framework will be called Lithium (sounds more professional already), and it’s due to launch next monday, here: http://li3.rad-dev.org/ (at the time of writing, this link is password-protected).

Personally, I am very excited about this new project. It should have happened three years ago, really, but there’s no point in being greedy: the time has finally come. I would like to (pre-)thank Garrett and Nate for their (upcoming) amazing work, I’ll definitely keep a closer eye on it.

Five years later, after rebuilding this web site seven times using different backends (PHP + CakePHP, Ruby + Rails + Typo, etc.), I decided to make it static again, this time with a twist. It all started when I read a post by Tom Preston-Warner (GitHub co-founder) that I finally decided to give it a try. Today, the 8th release of this web site is 100% static: if you load any page, there’s no server-side interpretation going on, you’re just browsing a plain HTML page, at most with a few AJAX calls. But let’s start from the beginning…

Why I don’t need a blog platform

There’s nothing inherently wrong with blog platforms like Wordpress: they allow anyone to publish content on the web using a user-friendly administration area. They were built with one thing in mind: make publishing content on the web something as simple as possible, even for people who don’t know anything about HTML, let alone server-side scripting.

What about people who do know about web development though? Do they still need a blog platform? Depends. If you are comfortable with editing files using a text editor, if you enjoy using the command-line on a daily basis, if you like programming and hacking a little bit, if you don’t really care about fancy and user-friendly administration backends… then you probably don’t.

All you need is a system to transform a bunch of source files into a web site. The good news is that such system exists – and you’re also spoiled for choices!

Introducing site compilers

The first site compiler I discovered was Webby:

[…] Webby works by combining the contents of a page with a layout to produce HTML. The layout contains everything common to all the pages — HTML headers, navigation menu, footer, etc. — and the page contains just the information for that page. You can use your favorite markup language to write your pages; Webby supports quite a few.

There are quite a few applications like Webby, such as:

• nanoc
• Rassmalog
• Jeckyll
• WebGen
• Rog
• Rote
• Hobix
• RakeWeb
• RubyFrontier
• StaticMatic
• StaticWeb
• ZenWeb
• YurtCMS
• NanoBlogger

There are probably even more, with different features, but they all try to solve the same problem: provide a way to generate static web sites in an automated way.

I spent some time reading about each one of them, evaluating the pros and cons and in the end I decided to go for nanoc, simply because it was the only one that seemed to fit all my needs.

A quick overview of nanoc

nanoc is a nifty tool written in Ruby suitable for […] building small to medium-sized websites. In other words, anything which doesn’t involve some fancy user interaction. For what concerns blogs, the only user interaction is comments – but that’s fine, because there’s more than one web service for that, such as Disqus or IntenseDebate.

Some details on the project

Compared to the alternatives, nanoc is one of the most mature and most maintained, having hit just a few weeks ago its 3.0 release. Its creator, Denis Defreyne, uses it for his own web site and is involved with the project on a daily basis, both coding and offering support to nanoc users like myself who regularly ask questions on the nanoc user group.

Denis also seems very concerned about keeping documentation up-to-date – something that really impressed me from a technical writer’s point of view. The tutorial he put together will get you started in no time, and the manual will explain everything else you may possibly want to know. When release 3.0 came out he even put together a migration guide. If this is still not enough and you don’t mind spending some time extending the system, nanoc’s RDoc documentation is very comprehensive compared to other Ruby projects.

Sites, Items and data sources

nanoc ships with a really neat command line tool that can do most of the work for you. Nanoc3 create_site h3rald will create a new web site in a folder called h3rald. The contents of this folder are laid out according to a particular logic (convention over configuration, remember?) So:

• content – your articles, pages, stylesheets, images, …all the site content and assets.
• layouts – the site layouts (and partial layouts)
• lib – place your custom ruby code and vendor libraries here
• output – your “compiled” site, ready to be deployed
• config.yaml – your site’s configuration file. The only one (and it’s just a few lines)
• Rakefile – place any custom Rake task here
• Rules – defines the rules for compilation, layout and routing

Here’s the default config.yaml file:

--- 
data_sources: 
- items_root: /
  layouts_root: /
  type: filesystem_compact
  output_dir: output

A data source in nanoc defines where data is retrieved from to create the web site. By default, the filesystem_compact data source requires that you create two files in the /content folder for each article or page of your web page:

• One containing the actual content of the page
• Another for the page’s arbitrary metadata

By personal preference, I chose the filesystem_combined data source, which allows you to combine the content and the metadata of a page in a single file.

The source code for this very article, for example, starts like this:

-----
type: article
tags:
- website
- ruby
- programming
- writing
date: 2009-09-15 13:32:51.049000 +02:00
permalink: take-back-your-site-with-nanoc
title: "Take back your site, with nanoc!"
toc: true
-----
Back in 2004, when I bought the h3rald.com domain, this site was static. At the time I hardly 
knew HTML and CSS, nevermind server-side languages, so I remember creating a _pseudo-template_ for
 the web site layout and using it whenever I wanted to create a new page, to preserve the overall look-and-feel. 
This was a crude and inefficient strategy, of course: whenever I changed the layout I had to replicate the change
 in all the pages of the site – the whole eight of them.

At run time, the content goes through a Textile filter and the metadata is used in layouts, to generate tag links automatically, for example.

Layouts, filters, and helpers

Layouts in nanoc are similar to layouts and views in Rails, but much simpler. The same applies to helpers. Here’s a snippet from my default layout:

        <div id="container">
          <!-- CONTENT START -->
          <div id="content" class="clearfix<%= (@item[:permalink] == 'home') ? ' home' : ' standard' %>">
            <h2><%= @item[:title] %></h2>
            <%   case @item[:type]
                when 'article' then%>
                <div id="content-header">
                  <%= render 'article_meta', :article => @item %>
                </div>
              <% end %>
              <hr />
              <div id="content-body">
                <%= yield %>
              </div>
              <div id="content-footer">
                <div class="share">
                  <script type="text/javascript" src="http://w.sharethis.com/button/sharethis.js#publisher=6e34d60c-b14e-4c19-9b2f-7c35a9f0ab09&amp;type=website&amp;linkfg=%23a4282d"></script>
                  <% if @item[:feed] then %>
                  <a href="<% @item[:feed_url] || @item[:feed]+"rss/" %>" type="application/rss+xml" rel="alternate"><img src="/images/theme/feed-icon-14x14.png" alt="#"/>H3RALD - <%= @item[:feed_title]%></a>
                  <% end %>
                </div>
                <%= render 'article_buttons' if @item[:type] == 'article' %>
              </div>
            </div>

This source code snippet shows quite a few features of nanoc’s layouts:

• You can access the metadata of the page which is being rendered using the @item, so @item[:title] returns the page’s title, for example.
• Layouts can be nested, and behave like Rails’s partials. The render takes a string parameter (the name of the layout to render) and an optional hash parameter to pass variables to the layout.
• The yield method is used to include the content of a page.
• Layouts support any kind of filter, like ERB for example. Go crazy.

Helpers can be used in layouts to perform common tasks, like creating links, feeds, navigation elements and so on. Check the source code docs for more info, and of course feel free to create your own as you see fit.

Finally, filters are used to filter content markup. nanoc ships with almost everything you need, from Textile to Haml to RDoc, but nobody forbids you to create your own, and it’s dead easy.

Rules and tasks

While tasks (as in Rake tasks) do not constitute a huge part of nanoc (but as usual, you may need to create your own to perform custom operations), Rules became, as of version 3, one of the key concepts to grasp in order to make everything work. Rules are stored in the Rules file of your nanoc site, they can be used to:

• Define routes, i.e. where pages are deployed in the output folder.
• Define how pages are compiled, which filters to apply to a particular set of pages, which layouts to use, etc.
• Define how layout are handled, which filters to apply to a particular layout, etc.

You can find more information in the manual, along with other important information, but for now, let’s say you should be familiar with most of nanoc’s jargon and how it works. Let’s see what you can do with it, in practice.

Migrating from your blog platform

As of version 7, h3rald.com has been powered by the Typo blog platform. If you are not familiar with it, let’s just say it’s a sort of Wordpress built on top of Rails: database backend, pretty admin front-end, tags, comments, and all sort of things a blog may need. While Typo is pleasant enough to use, it has all the inherent disadvantages of any other similar platform:

• It relies on a database
• It relies on server-side scripting to render pages
• It uses a complex caching mechanism to produce, ultimately, semi-static pages
• It may be subject to exploits, attacks, high server loads, and similar
• You can’t really customize it beyond a certain point
• You have to upgrade your backend frequently, and often is not as painless as you may expect
• You can’t use versioning tools like git for your content, as it’s stored in a database

I’m not claiming that nanoc is blogging’s silver bullet (it was not created for that), but for sure:

• It does not rely on a database
• It does not rely on server-side scripting to render pages (not in real-time, anyway)
• It does not need a complex caching mechanism simply because it produces static pages
• It is definitely less prone to nasty things
• It’s extremely flexible and hackable with very little effort
• You don’t have to upgrade all the time, but it is really painless if you decide to
• You can use git and similar: your content is in plain old text files

Rants are beside the point, suffice to say I recently convinced myself that switching from Typo to nanoc was a good thing, so let’s see how it worked out.

Posts, pages and comments

Out of Typo’s MySQL database, I just wanted to get the following data:

• Pages and posts
• Tags
• Comments

Following the approach used by Jekyll, I decided to use the simple and powerful Sequel gem. I’m sorry to disappoint you, but the whole migration process can be summarize with the following Rake task:

  task :migrate, :db, :usr, :pwd, :host do |t, args|
    raise RuntimeError, "Please provide :db, :usr, :pass" unless args[:db] && args[:usr] && args[:pwd]
    db = Sequel.mysql args[:db], :user => args[:usr], :password => args[:pwd], :host => args[:host] || 'localhost'
    # Remove all existing pages!
    dir = Pathname.new(Dir.pwd/'content')
    dir.rmtree if dir.exist?
    dir.mkpath
    # Prepare page data
    dataset = db[:contents].where("state = 'published' || type = 'Page'")
    total = dataset.count 
    c = 1
    total_tags = []
    dataset.each do |a|
      puts "Migrating [#{c}/#{total}]: '#{a[:title]}'..."
      meta = {}
      meta['tags'] = get_tags a[:keywords]
      meta['comments'] = get_comments db, a[:id]
      meta['permalink'] = a[:permalink] || a[:name]
      meta['title'] = a[:title]
      meta['type'] = a[:type].downcase
      meta['date'] = a[:published_at]
      meta['toc'] = true
      meta['filters_pre'], extension = get_filter db, a[:text_filter_id]
      contents = convert_code_blocks meta, a[:body]+a[:extended].to_s
      write_page meta, contents, extension
      c = c+1
    end
  end

That’s it. Well, almost: you can find the get_comments, get_tags and get_filter methods in a separate utility file. Nothing special really, just a few convenience methods wrapping queries or simply processing data. Note how all information, including tags and legacy comments, is saved in each page’s metadata. The write_page method simply creates a file in the /contents folder.

Filters and highlighters

On my old site, I used mainly Textile and Markdown to write posts. However, some of my really old articles used BBCode, whose corresponding filter is not available in nanoc. No worries, I soon found out that creating a new nanoc filter came down to this:

require 'rubygems'
require 'bb-ruby'

class BbcodeFilter < Nanoc3::Filter
  identifier :bbcode

  def run(content, args)
    content.bbcode_to_html
  end

end

Yes, that’s it. Granted, the bb-ruby gem does all the work, but notice how easy it is to just plug in new Ruby code into nanoc’s architecture!

The next big challange was code highlighting. After a quick research, I found at least a half dozen of possible solutions to highlight source code. Some were javascript based, others were based on a server-side language like PHP, Ruby or Python. Again, I looked at Jekyll for inspiration and discovered they integrated the Pygments Python library. Why use a Python library for code highlighting in a Ruby-based project? Because there’s nothing to stop you (if you can run Python on your server, that is), because it looks very neat and because it supports a lot of different programming languages.

Lazy as I am, I more or less dropped Chris Wanstrath’s Ruby wrapper into my /lib folder (I just used Open3 instead of Open4 for Windows compatibility), and monkey-patched nanoc’s filtering helper as follows:

module Nanoc3::Helpers::Filtering

  def highlight(syntax, &block)
    # Seamlessly ripped off from the filter method...
    # Capture block
    data = capture(&block)
    # Reconvert 
    data.gsub! /<%/, ''
    # Filter captured data
    filtered_data = "\n<notextile>"+Albino.colorize(data, syntax)+"</notextile>\n" rescue data 
    # Append filtered data to buffer
    buffer = eval('_erbout', block.binding)
    buffer << filtered_data
  end

end

include Nanoc3::Helpers::Filtering

There you go, another thing sorted.

Tags and Feeds

Adding tagging support was a tiny bit more tricky. nanoc supports content tagging out-of-the-box though metadata and a simple helper, but I wanted to create tag pages (with feeds). Nothing too difficult though, it all came down to a simple Rake task:

  task :tags do
    site = Nanoc3::Site.new('.')
    site.load_data
    dir = Pathname(Dir.pwd)/'content/tags'
    dir.rmtree if dir.exist?
    dir.mkpath
    tags = {}
    # Collect tag and page data
    site.items.each do |p|
      next unless p.attributes[:tags]
      p.attributes[:tags].each do |t|
        if tags[t]
          tags[t] = tags[t]+1
        else
          tags[t] = 1 
        end
      end
    end
    # Write pages
    tags.each_pair do |k, v|
      write_tag_page dir, k, v
      write_tag_feed_page dir, k, 'RSS'
      write_tag_feed_page dir, k, 'Atom'
    end
  end

Again, you can find all the other simple utility methods in my utility file.

When it came to feeds, I decided to create a new method for the Blogging helper to create RSS feeds, although nanoc does come with an Atom feed generator:

  def rss_feed(params={})
    require 'builder'
    require 'time'
    prepare_feed params
    # Create builder
    buffer = ''
    xml = Builder::XmlMarkup.new(:target => buffer, :indent => 2)
    # Build feed
    xml.instruct!
    xml.rss(:version => '2.0') do
      xml.channel do
        xml.title @item[:title]
        xml.language 'en-us'
        xml.lastBuildDate @item[:last][:date].rfc822
        xml.ttl '40'
        xml.link @site.config[:base_url]
        xml.description
        @item[:articles].each do |a|
          xml.item do
            xml.title a[:title]
            xml.description @item[:content_proc].call(a)
            xml.pubDate a[:date].rfc822
            xml.guid url_for(a)
            xml.link url_for(a)
            xml.author @site.config[:author_email]
            xml.comments url_for(a)+'#comments'
            a[:tags].each do |t|
              xml.category t
            end
          end
        end
      end
      buffer
    end
  end

Nothing too daunting, once you get used to Ruby’s XML builder. I followed a similar approach for my monthly archives

3rd-party services

Finally, the interactive bits. I basically turned to third-party services and a bit of jQuery for everything which required user-interaction or pulling data from other web sites. Here’s a list of services and APIs I currently use:

• IntenseDebate, for comments.
• Google AJAX Search API for internal site-wide search.
• Twitter JSON API to fetch tweets.
• Delicious JSON API to fetch delicious bookmarks.
• BackType JSON API to fetch comments from other sites.
• GitHub JSON API to fetch GitHub commits for most of my projects

If you want to know how I integrated them, check out my /js folder, it was very simple, really.

Conclusion

I was very happy of switching to nanoc. It didn’t take me long, and I spent most of the time with non-nanoc issues (brushing up jQuery, CSS, graphics, etc.). Of course knowing the Ruby programming language helps, and if you’re not comfortable with hacking your way a little bit, then maybe it’s not for you.

Personally, I’ve been waiting for something like nanoc for a long time: its simple and yet powerful architecture makes you able to do virtually anything with it. For the first time in a long time, I feel like I’m in complete control of my web site, I know every bits of it and if I want to change the way it works or looks I only have to touch a few files.

nanoc’s metadata is mindblowing for its simplicity and power: although you’re not dealing with a database, you can query your content in the easiest ways possible. Whenever I needed a way to easily access pages, filter them, add extra logic to them, I just added metadata. If you forget something, you don’t have to change your database tables, create new relationships or anything of the sort, you simply add metadata to pages.

Be warned that tweaking nanoc gets addictive very quickly: you soon end up creating silly little tasks for making things just the way you want. For me, adding a new article to my blog now just means this:

$ rake site:article name=take-back-your-site-with-nanoc
$ vim content/articles/take-back-your-site-with-nanoc
... write & close the file ...
$ Nanoc3 compile 

…Exactly what I need. Nothing more, nothing less.

H3RALD Web Site v8.0

It’s the time of the year, again. It doesn’t happen every year but it’s definitely a trend (hence the high version number): I’m going to redesign & redevelop my web site.

This time is not the usual “Let’s pick another language and another framework and start from scratch”, but a rather more radical shift, and yet at the same time less painful. The idea is to transform H3RALD.com into a 100% static web site, without losing anything in functionality (gaining, if anything!).

Tom Preston-Werner is definitely not the first person to blog like a hacker, and his very own Jekyll is definitely not the first static web site generator our there, nevertheless, he inspired me to embrace what seems to be one of the latest trend in developer’s blogs.

The idea is simple: turn all the blog posts and pages into static content, and rely on third party web services for things like comments, search etc. For a rather extreme by very interesting example, see Tagaholic.

The advantages of this approach are many:

• Free yourself from a database.
• Free yourself from a resource-hungry, server-side app (Typo, in this case).
• Increase speed and reliability, without using caching or similar artifacts.
• Keep everything under version control.
• Don’t worry about breaking things when upgrading (even if the static content generator changes, it shouldn’t really break things).
• Unleash the power of client-side scripting (namely, JQuery).

For now, I’m just brainstorming a little bit on GitHub, feel free to participate. The first step is obviously choosing a static content generator, and atm Jekyll seems to be slightly ahead of Webby. Opinions?

Glyph

Did you ever want to write a short manual or a book, or even a long article? If so, chances are you gave LaTeX a shot and either fully embraced its philosophy or totally refused it. Sadly, I belong to the second category: I believe sequential documents like manuals or books should be easier to create simply by using HTML.

Whever I have a chance to actually start working on it, Glyph will become a document authoring framework, i.e. a way to create visually appealing documents in a simple way. All the ingredients are there, it’s only necessary to glue them together in a pretty form:

• Textile (and RedCloth) to produce clean HTML code from a human-readable markup
• CSS3 to specify page rules
• A few rake scripts to produce a standalone HTML file, TOC, Index etc.
• An internal DSL for the document structure and metadata
• Liquid for control flow, snippets and filters
• PrinceXML to generate a PDF from HTML

This project is still in planning stage, feel free to have a look at the issues/features page on GitHub. Feedback is appreciated, as usual.

Vim files & the Stash

If you read the previous two sections of this post, you may have noticed that I’m growing more and more fond of git (and GitHub). Besides the repositories I already mentioned earlier on, I also created a personal stash, which I’m using mainly to store some of my Linux dotfiles, article drafts and …Vim customizations.

If you’re looking for a color scheme for Vim, check out my very own herald.vim, and tell me what you think.

Getting ready for the Big Step

This will probably be my last post as a free man, as I’m getting married (civilly) on July 2nd and (religiously) on July 11th.
Luckily the photographer agreed to give us a CD with all the pictures taken on the big day, with no copyright restrictions attached to it (believe it or not, some photographers don’t allow you to republish your own photos unless you ask them first), so I’ll probably write a long post with pictures when we come back from our (half) honeymoon.

Everything is pretty much organized. We had troubles with the waistcoats we got from eBay: they were cut almost randomly to resamble waistcoats, but they weren’t so we had to re-order another lot of 7 sets (waistcoat, cravat and shirt this time) from another seller, this time UK-based. I seriously hope to get them in time.

On the 24th we’re having a party at our house. If you were invited, feel free to drop by, otherwise be prepared to be thrown out of the window (4th floor) by one of our ushers (Roxanne’s big brother). It’s probalby going to be about 30-40 people in the end, mainly because most of my office can’t come due to holidays they booked in advance.

What’s left to do now? Well:

• Send the bomboniere over to Ireland
• Make sure my dad actually ships the 96 specially-bottled bottles of our own wine to uncle John, in Ireland.
• Make sure uncle John doesn’t drink all the 96 bottles of wine before the wedding reception.
• Make sure my best man understood that the speech he has do make must be in English, at least 3 minutes long and not too offensive to the groom.
• Pay a huge, colossal heap of money for the whole thing. It’s going to cost us (and my dad) quite a bit, in the end. But it’s a once-in-a-lifetime experience, after all (getting totally trashed in a fancy hotel with all your family, including 2nd and 3rd grade cousins).