Because Jekyll outputs a static site structure, it means you can host your blog (or site) from anywhere that you can serve static HTML, simply by using your favourite web server (e.g. Apache). As Tom describes in his blog post, the idea came from wanting to be able to "Blog like a Hacker". Jekyll lets you write from the comfort of your favourite text editor, and publish from the command line. Using familiar tools reduces the cognitive load involved with publishing a blog, and lets you focus on what you're writing. It doesn't hurt that even a pretty weak Web server could stand a pounding if it's just serving static files!

By default, Jekyll uses its own (slightly modified) flavour of Liquid templates, with help from pygments for syntax highlighting, and you can use textile or markdown for the content. Each Jekyll blog article template needs a header containing some metadata about that article, such as what layout to use, the article's title, and any custom information you want to provide (such as tags for that article).

Generating your site is easy: just running the jekyll command turns your directory of templates into a complete website, ready to serve. There's a Jekyll server that you can use for testing (passing --auto as an argument means it will automatically regenerate the site when things are changed).

jekyll --server --auto

Github Pages provides a neat way to publish your Jekyll-generated site. Every Github page is actually run through Jekyll when you push content to your pages repo (this works because a normal static site is also a valid Jekyll site).

The easiest way to get started with Jekyll is by installing the gem (which is available on Gemcutter), and checking out the wiki on Github, where there's some great documentation.

sudo gem install jekyll

As you might expect, Tom Preson-Werner's personal blog runs on Jekyll. Its source is publicly available on Github.

I don't like to link to individual presentations on Ruby Inside too often, but in spite of poor audio quality on the video, Tom's presentation is top notch (the slides are particularly good) and Tom covers some interesting topics that I think Ruby developers could do with revising. If you've wanted to stay on the functional bandwagon but have found yourself slipping into imperative ways where you shouldn't, this presentation is well worth a watch.

[ad] Find duplication, code smells, complex code and more in your Ruby code with Caliper! The metrics are free and setup takes just one click. Get started!

With Riot, each test consists of a block which forms a single assertion on the topic of the test, keeping the tests focused. Tests run in a specific context, and the setup code is only run once per context, further contributing to the speed of your test suite, and unlike some Ruby test frameworks, such as Shoulda, that rely on or are based on Test::Unit, Riot has taken a new approach for speed purposes. In Justin's own comparisons, Riot comes out about twice as fast as Test::Unit.

Here's an example Riot test (from the README):

context "a new user" do
  setup { User.new(:email => 'foo@bar.com') }
  asserts("email address") { topic.email }.equals('foo@bar.com')
end

Riot's comprehensive README also includes lots of examples and details on how to modify your Rakefile to run your Riot test suite in different frameworks. The full documentation is available online here.

You can install Riot as a gem from Gemcutter:

sudo gem sources -a http://gemcutter.org
sudo gem install riot

Justin also has a spin-off project called Riot Rails, which includes some Rails-related macros for testing your Ruby On Rails code, and Alex Young has written a Javascript port of Riot which is worth checking out too. He also has his own look at Riot and demonstrates how Riot can reduce redundancy in tests.

[ad] Codebase is a fast & reliable git, mercurial & subversion hosting service with complete project management built-in - ticketing, milestones, wikis & time tracking - all under one roof. Click here to try it - free.

Till now, Heroku has provided basic functionality on a semi-metered basis. You pay a monthly fee for a basic rate of service and then pay an hourly rate for more concurrency. Now, you can also add on a bunch of other features which Heroku are calling "Add-ons." Here are just a few of the more interesting ones:

• Amazon RDS (Relational Database Service) - This add-on is free from Heroku's point of view but you'll be paying Amazon.
• Bundles - A "snapshot" type backup system. You get a single bundle for free or can pay $20 for unlimited bundles.
• Cron - Daily and hourly crons can be set up with a couple of clicks.
• Memcached - You can boost your app's performance with in-memory caching provided by Memcached. The key here is that Heroku totally manages the Memcached instance - no server setup needed, etc. Currently this feature is only in private beta though..
• New Relic - Most readers should be familiar with New Relic's application performance tools by now and Heroku makes it easy to get them running directly on your Heroku-hosted apps. (As an aside, New Relic rolled out a significant update last week - version 2 of their flagship RPM system.)
• SSL - Get https:// URLs on your Heroku app with a choice between piggyback SSL (free), SNI SSL ($5 per month) or full-blown custom SSL ($100 per month).
• Websolr - A no-setup-needed Solr instance so you can get quick and easy full text indexing and search functionality in your apps.

Note: You can learn more about all the different Add-ons at Heroku's dedicated Add-ons page.

Impressive but Expensive?

As impressive as Heroku's one-command-deploy and add-ons features are, though, I can't quite put my finger on Heroku's market - they're kinda pricey. Perhaps it'd be good for professional developers who want to do a test deployment of an app on a live server without getting mired in server configuration?

For full time use, Heroku doesn't strike me as very competitive. For example, for the "Crane" 500MB storage option (billed as "perfect for a small biz app") with the recommended 4 "Dynos" the fee comes to an estimated $158 per month, and that's without any add-ons. For the entry level "dedicated" option with the recommended 8 dynos, the cost goes to $452.

Despite the cost, though, what Heroku offers is a very simple "no hassles" hosting service that, crucially, can handle significant workloads. You could rig up something similar with VPSes, dedicated boxes elsewhere, or even Amazon EC2, but you're going to be spending time doing server configuration. If playing sysadmin isn't tricky for you (I enjoy it, personally), Heroku might not be for you and you should be looking at companies like Webbynode or Linode. But if you're just a 100% developer who wants to get something up and running and doesn't want to worry about scalability too much, Heroku could be worth the extra expense.

Update: Oren Teich of Heroku got in touch with some notes regarding Heroku's value proposition versus the comparisons I made above. I quote verbatim:

 I wanted to point out that we have many users running huge sites on the free version, serving up hundreds of thousands of hits per month, and that they pricing is deceptive - for that $150 you get an AMAZINGLY high powered service, capable of serving >10 millions requests per day.

We don't do a great job right now of making it clear just how powerful a single dyno is, or what you get with the platform.  We're working on improving the pricing to be clearer.  In the meantime, getting the right message out on this is really important to us.

Also keep in mind, that the DB pricing is for DB usage only - it doesn't include your code, files on disk, etc.  That said, we know we need to right size the DB pricing, but it's amazing how far 500, or even 50 MB of pure DB usage will take you.

Heroku has many users running huge sites on the free version, serving up hundreds of thousands of hits per month.  The pricing can be deceptive, for that $150 you get an AMAZINGLY high powered service, capable of serving >10 millions requests per day.

He also noted that there's no charge for bandwidth, although there are some soft limits that haven't been hit by any users yet.

Disclaimer: Webbynode and Linode are currently Ruby Inside sponsors. Heroku, however, has no financial connection with Ruby Inside and vice versa.

[ad] Find duplication, code smells, complex code and more in your Ruby code with Caliper! The metrics are free and setup takes just one click. Get started!

The transition from RubyForge to Gemcutter/RubyGems.org isn't an overnight deal and gem publishing from RubyForge will continue to work for the time being, but within the next couple of months, RubyForge accounts will be merged with Gemcutter and an update will be made to change the canonical gem source (though, of course, you can use Gemcutter already if you like by following their instructions).

What all of this means for you as a Ruby developer is that if you want to release your own RubyGems (or "gems") in future, things will become a lot easier. Gemcutter, if you haven't checked it out, is definitely a refined evolution in terms of gem hosting - you can "push" a built gem to their server with a single command. If you want to learn how, check out Ryan Bates' awesome Gemcutter & Jeweler screencast that demonstrates how to create a gem and deploy it with Gemcutter.

[ad] Codebase is a fast & reliable git, mercurial & subversion hosting service with complete project management built-in - ticketing, milestones, wikis & time tracking - all under one roof. Click here to try it - free.

Anyone who's built a Rakefile knows it's not the most straightforward syntax, so Boson's approach of using regular Ruby code in the shape of methods added to a module is refreshing. Tasks are methods, methods are tasks - simple. Within these methods, you can use the options helper method and passed arguments to access command line options and other data. Another feature is that while, like with Rake (or Thor), Boson can execute commands from the command line, you can also do so from IRB (the Ruby "console").

It's always a bit of a crapshoot when new tools come out in the Ruby world. Some catch on, some don't. Gabriel has clearly put a lot of thought into Boson, though, so if enough people are fed up with using Rake for command launching, I think it could catch on. Gabriel's blog post outlines what Boson does perfectly. For those ready to shoot down Rake, though, don't forget to read John Barnette's awesome, recent On Rake post. Rake's not just about launching tasks - it's a killer dependency resolution engine at heart, and that can result in less code if you approach your problems the right way.

(Aside: Sorry for the slow week at Ruby Inside. Six days ago my wife gave birth to our daughter and since she had a C-section, I'm playing housewife. I have quickly discovered if you're a housewife - or husband! - you have about zero hours left at the end of the day to do any other work.. I shall try my best!)

[ad] Mobile Orchard's from Rubyist to iPhone programmer in 2 days class is coming to Portland/OR Nov 12-13 and Los Angeles/CA Nov 19-20. $1200 $799 with early reg and "inside" discount code. Note that the early registration price ends tomorrow - 10/23!

P.S. I know the term "middlewares" sounds borderline insane, but.. it works, you know what it means - yada, yada ;-)

In this post, we're going to highlight various Rack middlewares from CodeRack, an on-going Rack middleware competition:

[ad] Mobile Orchard's from Rubyist to iPhone programmer in 2 days class is coming to Portland/OR Nov 12-13 and Los Angeles/CA Nov 19-20. $1200 $799 with early reg and "inside" discount code.

As of this first draft, the e-book's 60 pages long - resulting in about 50 pages of actual content. It's clearly a draft, but Mohammed has put together a pretty readable overview of the state of not only Web servers but basic TCP servers and concurrency issues on Ruby 1.9. There are even several diagrams that provide visual demonstrations of how the different servers manage requests.

The bulk of the booklet, however, is turned over to graphs showing the results of performance tests made upon each library under different scenarios. There are too many data to summarize here, but unsurprisingly WEBrick typically loses (though not always, in a few it wins!) and Thin is typically in the lead.

[ad] Mobile Orchard's from Rubyist to iPhone programmer in 2 days class is coming to Portland/OR Nov 12-13 and Los Angeles/CA Nov 19-20. $1200 $799 with early reg and "inside" discount code.

So I wrote What I've Earned (And Learned) From Writing "Beginning Ruby" over at the new, official Beginning Ruby promotional site. I wasn't planning on mentioning it here, but the post became popular on Hacker News and Reddit to such an extent (almost 10,000 pageviews so far!) that it must be a story people want to read - so check it out.

For those who are interested, Beginning Ruby's 2nd edition was published just a couple of months ago with lots of updates, new sections, and two all-new chapters on Web application frameworks (Rails, Sinatra, and Ramaze) and GUI app development (using Shoes - erk). You can buy it at Amazon.com here or learn more at the official Beginning Ruby site. It's a great book for people who are new to Beginning Ruby (or programming generally, even) and you can see tons of reviews on Amazon's listing for the 1st edition (we're waiting for them to be merged into the 2nd edition's page!) or at the official site.

[ad] Jumpstart Lab is offering Rails Jumpstart, an introduction to Ruby on Rails, on 10/31-11/1 in Washington, DC. Save $30 with code "rubyrow"!

With Mustache, the typical view layer is split up into two sub-layers: a Ruby Class-based "view" and an HTML "template", so you can concentrate on crafting your HTML without polluting it with embedded Ruby logic. This separation also makes it easier to test your view-code.

Amusingly, the name of the project comes from the way that you insert references to the view class into the template. Tags are denoted by double curly braces, or "mustaches". e.g. {{name}}.

In their simplest form, tags are just calls to methods on your Ruby view class. But they can also take more complex forms such as block definitions, calls to partials or helpers (from modules included into your view class).

There are more examples and documentation in the GitHub project, but here's a canonical usage example from the README:

View Logic:

class Simple < Mustache
  def name
    "Chris"
  end

  def value
    10_000
  end

  def taxed_value
    value - (value * 0.4)
  end

  def in_ca
    true
  end
end

Template:

Hello {{name}}
You have just won ${{value}}!
{{#in_ca}}
Well, ${{taxed_value}}, after taxes.
{{/in_ca}}

At the moment, only Sinatra support is provided "out of the box", but it should be fairly easy to integrate with other Ruby frameworks.

Installation

Mustache is available from Gemcutter or Rip. Install in one of two ways:

$ gem install mustache
$ rip install git://github.com/defunkt/mustache.git

[ad] Codebase is a fast & reliable git, mercurial & subversion hosting service with complete project management built-in - ticketing, milestones, wikis & time tracking - all under one roof. Click here to try it - free.