H3RALD - Tag 'programming' (RSS Feed)

herald.vim 0.2.1 released

h3rald@h3rald.com — Thu, 12 Nov 2009 12:34:29 -0000

I just updated the Herald Vim color scheme to improve the readability of delimiters and search results.

Delimiters are now red (the same color as operators) instead of yellow, so that you can tell the start and end of a string or regular expression more easily. Additionally, search results are no longer highlighted with black text on an orange background for two reasons:

the orange background is a bit too strong
the black foreground causes letters to become completely hidden by the cursorline and cursorcolumn

Search results now have a gray background and a yellow background, as shown in the screenshot on the right.

If you have any constructive suggestion on how to improve this color scheme, don’t hesitate to add a comment to this post!

Take back your site, with nanoc!

h3rald@h3rald.com — Tue, 15 Sep 2009 11:32:51 -0000

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.

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:

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 &ndash; 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.

Herald (Vim Color Scheme)

h3rald@h3rald.com — Wed, 17 Jun 2009 04:11:00 -0000

I use Vim a lot. It’s my editor of choice when I code (mainly in Ruby), and also when I write my blog post and articles (mainly in Textile).
One thing I always liked about Vim was it powerful syntax highlighting: there’s probably a syntax highlighting file for every programming language ever created, even the new ones (Nimrod? Sure, here!).

Furthermore, Vim allows you to create color schemes, and that’s surprisingly easy to do. Everything you need to do is in the docs, but that may put you off, so you can just start by editing an existing one — that’s what I did.h3. InfiniteRed Black

I’ve been using the ir_black color scheme for near enough a year. It’s an excellent color scheme, recommended especially for writing Ruby code:

I honestly thought this was the best Vim color scheme until I discovered Moria…

Moria

Recently I switched to moria, mainly because I find it easier on the eyes. It’s a matter of taste, of course:

The trick is in the background: it’s not completely black. Still, I didn’t quite like the colors, so I decided to write my own…

Herald

Meet herald.vim (this is a direct link to the raw file, but you may also want to check my stash on GitHub or the script page on Vim.org):

To sum up, here’s the features offered by this new color scheme:

It’s easier to differentiate syntax elements; in particular reserved words like if or end, constants (symbols) and identifiers (instance variables).
Operators are highlighted and easier to notice.
Dark gray background and black column/row selectors.
Added highlight for titles (useful for Textile)
Comments do not stand out, unlike in most color schemes
Support for 256 color terminal (special thanks to Wolfgang Frisch for providing all the info and tools required)

So what do you think? Is it tool colorful perhaps? How would you improve it?

Personal Log - May 2009

h3rald@h3rald.com — Sun, 31 May 2009 04:35:00 -0000

Yet another extremely busy month, as you can see from the total absence of blog posts and lack of tweets even. Things are getting pretty hectic at work now I guess: less people, more work, more responsibility, same money. They call it contingency; it’s the latest trend in the Western World, didn’t you know? I’m really not impressed. I can’t complain though I guess: I still enjoy my job very much and I know it could be much worse, so it’s just a matter of enduring until autumn — or so they say.

Star Trek Premiere

The month started with an event I’d been looking for for months: the premiere of Star Trek XI, aka “Star Trek”. It’s not that J.J. Abrahms couldn’t come up with a more original name (Star Trek: Academy used to be the working title, at one point), he simply wanted to tell the world that this movie was a new beginning, an elaborate way to start from scratch, to reboot what was more than once dubbed a dying franchise.

The movie was enjoyable – daring and a bit flamboyant – but still enjoyable nonetheless. I consider myself a Star Trek fan, and although it was not the usual Star Trek movie, I somehow liked Abrahms’ bold revisitation of Roddenberry’s universe. Take a bunch of unknowns (Chris Pine) or semi-unknowns (Zachary Quinto), then add some spicy British humor (Simon Pegg) and some old friend (Leonard Nimoy) and throw in an awful lot of XXI century special effects: what you get is not the usual, let’s-all-rock-because-we’re-hit traditional Star Trek, of course, it’s an alternate version of it.

That’s precisely what the movie is meant to be: what Star Trek would have look like if it had been created in the XXI century. The timeline feels disrupted since the very first minute (nevermind the end!), with a Jim Kirk stealing his stepfather’s car. Chris Pine is an alternate Kirk, quite different from the original one, but not that bad. Zachary Quinto, on the other hand, is a true revelation: he definitely is the new Spock, and he couldn’t have been cast better. So is Simon Pegg as Scotty, but unfortunately he’s not involved enough.

The baddies were a bit of a letdown. Nero is a bit too flat, and his ship is way too fancy, no matter where it comes from. Clearly some Hollywood junkie wanted a big, invulnerable dark ship to bring havoc in the galaxy, but that is NOT a Romulan ship, period.

At any rate, I enjoyed the movie and I’m looking forward to the second one, which I hope it will be followed by many others.

Unfortunately in Italy Star Trek is not worshiped in Italy as in it is the US, which is very unfortunate… Roxanne and I decided to play along and go to the cinema half-dressed-up, but our friends Elora and Michelle came with a full-blown Uhura uniform! The whole cinema kept staring at us. It was a bit freaky, but fun (check out the pics on Facebook — if you can, that is, I won’t post them here!).

Wedding Planning

Just over a month to my wedding. Scared? You bet. Stressed out? Indeed. Roxanne and I managed to get most of the things organized in the end, luckily. In particular, this month:

We went to the British Consulate in Milan, and applied to get Roxanne’s legal documents.
I bought and had the 7 vest sets delivered to Roxanne’s brother’s (Caspar) place, in London.
I ended up buying 8 (buy three, get one free) morning suits from Marks and Spencer, and had them delivered to Caspar’s place. He’ll be sending all the stuff over soon, hopefully.
Roxanne got the dresses for the maids of honor, and apparently we have to collect them on monday.
We sent all the invites we needed to send, but we’re still waiting for confirmations. It looks like it won’t be a big wedding, probably around to 60-70 people mark.
We ordered the bomboniere, they should come through soon.
Uncle John told us he had the music for the church and the reception sorted out.
We got the rings!

We still have to organize a few things, namely:

Write and print the prayer books
Book the flight for one of my ushers
Get some fancy gifts for the bestman and the rest of the people involved in the ceremony
Get married civilly here in Genoa
Organize a party at our place for the people who can’t come to the wedding
Do something else I can’t remember right now

Yes, we are still busy as hell. I’m looking forward to it all, but I’ll definitely be much more relaxed when it’s all over!

Home Internet: Epilogue?

I got broadband at home, finally, after five months. Let’s do a quick recap:

Last December I signed up to Libero Infostrada, and told them I wanted to disconnect from Telecom
In January I actually got disconnected from Telecom, got a new phone line contract, but the Internet was never activated.
I kept calling clueless operators on both ends pointlessly for 2-3 months.
I got pissed off with Libero, so in April I signed up to Tele2, telling them to disconnect me from Libero. They told me it would take at least 4 weeks.
Meanwhile, I signed up to 3g, and got an Internet USB key. At least I can go online, even if with a crappy UMTS connection.
After a month, Telecom rings me asking if I want to come back to them, promising I’ll have the Internet back on soon enough. Out of desperation, I accept and tell them to disconnect me from Tele2.

Just when I was about to write a long post cursing Telecom and their perverted schemes to force their customers to stay with them, I receive a call from Libero and they tell me that the Internet is now activated! Unbelievable. Now all I have to do is send letters to all the other ISPs (they don’t do these things on the phone — clueless operators, remember?) telling them I don’t want anything to do with them anymore.

This is how broadband Internet works in Italy. Jealous?

Nimrod

Last month I decided I would stop programming until after the wedding and so I did (at least at home). Nevertheless, I still keep strive to keep up-to-date with everything concerning technology and in particular programming.

Out of all the tech news I came across throughout this month, the Nimrod programming language definitely struck me the most. A German guy came up with a new language — that’s not a big news, new programming languages are born every week, if not every day.

I believe Nimrod is different though. Basically, here’s why:

It’s a mixture of Lisp, Python and C. It looks a bit like Python and it behaves like it (indentation matters), it allows the creation of macros, like in Lisp, and – this is what really matters to me – it compiles to plain C (which can then be compiled using GCC or whatever).
It is open source and can be used to produce commercially distributed executables.
The manual is simple to read (but with a few rough edges), and the language looks simple to learn.
The language is not yet complete, but it’s getting close to a 1.0 release. It works as advertised, nonetheless.
It offers a comprehensive standard library, and a huge amount of libraries and wrappers from everything from Windows API to GTK and Cairo.
It is cross platform, the Windows version even comes with a one-click installer.
It has garbage collection and it supports manual memory management, if you need it.
It’s statically typed, with type inference
It can generate standalone executables, with very little overhead (90KB for an hello world program).

A language like this has been my secret dream for a long time. I thought no one would ever come up like this. I am really looking forward to give it a proper try someday. What’s wrong with it? For now, a few bits are missing (like native serialization), other than that someone pointed out the weird, rather extreme case insensitiveness of the language. Basically, case and underscores are ignored to allow programmers to use their own programming conventions.
Personally I don’t think this is that bad. After all, if you name your variables “a_thing” and “aThing” and you want them to mean different things, that’s bad programming style anyway. Nevertheless, as far as I know it’s the only language I know which offers such an extreme degree of flexibility in this sense.

Learning new things

This month I also found myself to be extremely eager to learn about new things. I’m still faithful to Ruby and all that, but I’m opening up to new possibility, for different things:

I decided to start listening to slightly more technical podcasts, which are _not_related to tech news. In this way, I don’t have the pressure of having to listen to them on a regular basis. Other than FLOSS Weekly, which is probably the best show about Open Source Software out there, I’m going to try out Software Engineering Radio and The Command Line, both slightly more technical.
Because I decided to put my personal programming projects on hold, I’m having all sort of new ideas about even more projects I could start as soon as I can. No anticipations until after my wedding, of course.
I’m using Vim all the time now, both at work and at home. I feel confident with it, but I feel I still have a lot to learn, especially when it comes to marks, registers, etc. And I’m not yet ready to write an article about it — not the kind of article I’d like to write, anyway.
I’d like to learn more about Javascript and JQuery. I played around with it and loved it, but I really never used it for anything serious yet. This, however, may change in the future.

Concatenative programming in Ruby

h3rald@h3rald.com — Sat, 28 Mar 2009 06:24:00 -0000

A while ago, I sat down examining a few alternative programming languages I might decide to learn someday. Each of those languages has its own peculiarities, and I didn’t choose them randomly, I chose them based on their popularity, power, paradigm and how actively they are developed.

I included Factor as the only representative for concatenative programming, an interesting way to write programs, but seldom used in “recent” languages (except for Factor and a few others).

The Joy of concatenative programming

If you have absolutely no clue on what I’m talking about, you should consider looking at the home page for the Joy Programming Language, or maybe just the overview: it should be enough to tikle your curiosity.

Joy is often considered the canonical concatenative programming language: a basic —but working— implementation of a simple programming language to illustrate the fundamentals of concatenative programming. Joy looks like this:

2 3 + dup *

This simple programs computes the sum of 2 and 3, pushes it on the stack, duplicates it (using the dup combinator) and then multiplies the two values, obtaining 25 as a result.

Let’s slow down a second. Here’s what happens, exactly:

Element entered	Stack contents
2	²
3	[2 3]
+	⁵
dup	[5 5]
*	²⁵

Got it? Let’s take it one step further. When you enter dup and then *, you are effectively computing the square of a number, so we can define the function square simply as:

square == dup *

In Ruby, this would be:

def square(x)
  x*x
end

What’s unusual here? — Simple, there are no variables involved. Joy doesn’t need any explicit variable or formal parameters of any sort.

There’s more. Take the following code:

[1 2 3 4] [dup *] map

The map combinator expects a list and a quoted program (the same one used to compute the square) and produces a new list containing the result of that program applied to each element of the original list. Basically the equivalent of:

[1,2,3,4].map { |e| e*e }

Do you notice anything different? — Yes, Joy doesn’t need blocks or lambdas either, it uses quoted programs instead, which are nothing but slightly fancier lists (or arrays, as you like).

Let’s recap then, Joy doesn’t need of:

lambda functions or blocks (quotation does the trick)
explicit parameters (everything you need is on the stack)
variable assignments (same as above)
explicit recursion (provided you can use combinators like linrec, primrec, binrec, etc.)

I would consider this one of the best examples of programming minimalism: an incredibly simple syntax, a very small set of rules, but a good deal of power.

Ruby objects on the stack

After reading about Joy, I realized that implementing something similar in Ruby would be an interesting mini-project (let’s say a week of lunch breaks) to understand more about concatenative programming. It would also be pointless, too: a stack-based programming language implemented on top of one of the most high-level programming languages you can find isn’t going to be fast, is it? Nevertheless, it would still be interesting.

Ruby offers everything you need to build a Joy-like DSL:

You can use arrays as …arrays, but also as quoted programs, and to model the stack itself.
You can use integers, strings, etc. as themselves
You can use Symbols as functions (we’ll get to this in a minute)

If you think about the following expression in postfix notation:

2 2 +

We could translate it into infix notation (2 + 2), because Ruby supports it, but it’s not general enough. What you could do is this though:

2.send(:+, 2)

Message sending. I can see all the SmallTalk sympathizers drooling already. Well yes, In Ruby, everything is an object, so everything has a receiver and maybe some parameters. In other words, every method call can be reduced to the following syntax:

receiver.send(method, *params)

In this way, it is safe to assume that everything has a receiver, which could be understood as a function parameter, and may have 0 or more parameters. Take the following then:

[2, 2, :+]

It’s not too different from Joy, and it’s still Ruby code. All you have to do is use something to do the following:

Take an array, and examine each item:
- If it’s an object (non-Symbol), then push it on top of the stack.
- If it’s a Symbol, then do something different, i.e.:
  - Find its receiver and its parameters and call a method.
  - Manipulate something on the stack.

In this case, we have to find :+’s receiver and its parameter and we’re sorted.

Unfortunately Ruby’s arity method isn’t that reliable. For example: "test".instance_method(:sub).arity returns -1, while it should return “2” to be useful. So we have no choice but find a way to pass the method’s arity explicitly, in some cases.

For example like this:

["Ciao, Fabio", /Ciao/, "Hello", :sub|2]

If we define a | operator for the Symbol class, it’s not too bad after all. It’s heavy, but in this way we can use any Ruby method in postfix notation.

Introducing the Concatenative Ruby DSL

Concatenative is a simple Ruby DSL for concatenative programming. You can write concatenative programs inside ordinary Ruby arrays and execute them by calling either Array#execute or Kernel#concatenate, like this:

require 'concatenative'

concatenate(
  10,
  [0, :==],
  [1, :+],
  [:dup, 1, :-],
  [:*],
  :linrec
 )

This simple program calculates the factorial of 10. As you can see, no matter how unusual it may look, it is perfectly valid Ruby code and it is equivalent to the following Joy code:

10 [0 =] [1 +] [dup 1 -] [*] linrec

Granted, Joy looks better, but that’s the tradeoff for not writing a parser for Joy syntax, after all.
Looking at the code above, there are a few things to keep in mind when programming with Concatenative:

You are using Ruby arrays, so you have to use commas, at least
functions, operators and combinators (let’s just call them words) are available as Ruby symbols
The arity of all Ruby infix operators has been already set to “1” by concatenative using the set_arity method (which simply stores the arity of a particular symbol in a constant hash)
You can specify explicit arities using the | operator (:gsub|2, or :join|1)
Unless the arity has been specified, an arity of 0 is assumed.
You can define your own concatenative functions using the Symbol#<= method, which expects a quoted concatenative program.

Performance issues

In its current form, Concatenative can be very slow, as show the “benchmarks” provided in the /examples folder, especially if you use recursive combinators. This is understandable because everything is implemented in pure Ruby, which is totally unsuitable for low level stuff.

If you are interested, you are more than welcome to submit patches and suggestions to improve Concatenative’s performance, or, if you feel brave enough, you could help me create a C extension instead: things would become much faster then.

At any rate, feel free to play with it. You can get the source from GitHub, you can get the gem from RubyForge and you can submit ticket through GitHub as well.

10 programming languages worth checking out

h3rald@h3rald.com — Sun, 21 Dec 2008 14:01:15 -0000

If you program for fun or profit, chances are that you know C, C++, Java, PHP, Perl, Python or Ruby. These programming languages are all widely known, and, to a different degree, used in commercial applications. At least some of them can safely be considered mainstream, even if that word has become so overused and misused that has almost lost its original meaning, if it ever had one.

If you are earning your living by coding, it’s often one of these languages that pays the bills. Nevertheless, true hackers frequently meander in other directions, exploring and discovering different paradigms and methodologies, sometimes to the most esoteric extremes.

“The most obvious common ‘personality’ characteristics of hackers are high intelligence, consuming curiosity, and facility with intellectual abstractions. Also, most hackers are ‘neophiles’, stimulated by and appreciative of novelty (especially intellectual novelty). Most are also relatively individualistic and anti-conformist.”

– Eric S. Raymond, The Jargon File

Even if you’re particularly devoted to one of the languages mentioned above, it is normal to be curious about what else is out there. As the end of the year approaches, I find myself thinking about learning – or at least become acquainted with – some less known, more experimental, programming languages.
I was originally planning on learning another programming language as a New Year’s Resolution, which is quite common among programmers. The most difficult task turned out to be choosing a particular language: there are so many out there which makes it very hard to decide.

This article deals with ten possible candidates, and it’s far from being an exhaustive list. The programming languages described henceforth are very different from each other, but they all have one thing in common: they all stimulate my curiosity in their own, very different ways.

Haskell

I tried to learn Haskell in the past. Quietly, I started diving into the multitude of articles, tutorials, overviews and even books about this fascinating academic language which claims to achieve functional purity though remaining extremely useful, practical and efficient. Sadly, I’m still not able to fully grasp some of its most crucial concepts, such as monads, but this still doesn’t put me off wishing to learn the language.

If you’ve never enountered Haskell before, I find The Evolution of a Haskell Programmer an amusing and informative read. Although aiming to be humorous in a way, it serves a very important didascalic purpose: it is one of the most complete collections of the different paradigms and programming approaches Haskell allows.

Besides its very elegant, pragmatic and almost-magical syntax, what really intrigues me about this language is what it offers, in terms of features:

9 different implementations (multiple compilers and interpreters)
Countless standard libraries packages which can be used to solve any programming challenge
Abundant learning material
Speed that rivals C and C++
Very mature cross-platform compatibility

The catch? It is likely to be very different from any other language you might have encountered before, and that’s probably the reason why some people find it difficult to learn and master. That being said, if you are looking for a challenging (but very rewarding, I believe) New Year’s Resolution, you should definitely go for this.

To get you started…

Erlang

Erlang is a concurrent programming language originally developed by Ericsson for their real-time applications. It goes without saying that with these premise, Erlang seems the most natural answer to all concurrency problems you may encounter in your life as a programmer.
Developing with concurrency in mind feels natural and easy in Erlang, and the performance of Erlang-powered systems can be unmatched.

Quite a few interesting applications have been developed in this language, such as:

CouchDB, a popular distributed, document-oriented database
Yaws, a high-performance web server
even Facebook Chat

The price Erlang adepts have to pay, as Damien Katz (CouchDB creator and Erlang enthusiast) points out, is:

Awkward syntax, inspired by Prolog
Weird if expressions
Difficult string operations
No classes or namespaces

…this list could go on. Damien’s article is an interesting read, enough to put anyone off learning the language if read superficially. On the other hand, it provides an invaluable resource for newcomers who wish to be prepared before taking on the challenge of learning Erlang to build their next scalable, concurrent and industry-proof application.

To get you started…

Io

Io is a relatively new programming language by Steve Dekorte which recently surfaced from Google’s oblivion (if you tried googling for it a few months ago, you couldn’t event find its home page) thanks to a short vut stimulating article by _why. It doesn’t have the best name for a programming language, that’s for sure, but it’s definitely a breath of fresh air in terms of the way it works.

Its unusual, minimalist and yet elegant and powerful syntax reminds of Smalltalk, but the language goes far beyond that. Io is an object-oriented, prototype-based, message-based and fully-reflective programming language. This means that you use messages like in Smalltalk, you create objects like in Javascript and every bit of your code can be inspected and passed around as you see fit.

If you think Ruby allows fancy (and potentially dirty) tricks like metaprogramming and monkey-patching, Io takes this to a whole different level, imposing virtually no limitation to the programmer. What’s truly amazing is that its grammar and syntax are so minimal that you can learn them in literally 10 minutes. After that, you can start experimenting, first with its extremely small core and then with its extension libraries and bindings.

Io has indeed a lot of potential. Granted, it’s still young and under development, but also already quite efficient and suitable for real-world tasks demanding high speed and concurrency. It is implemented in C, but Ola Bini started to design a similar language called Ioke for the Java Virtual Machine.

To get you started…

PLT Scheme

I stumbled upon the PLT Scheme web site while browsing for different Lisp flavors about a year ago. At the time, I was determined to learn the rudiments of Lisp and I started reading a few articles and books on this old and yet still popular language.
Although I was originally put off by certain Common Lisp literature, which dismissed Scheme as an almost-heretic attempt to revitalize an venerable language, I soon found out that Scheme – and PLT Scheme in particular – is definitely worthy of attention and interest.

Being a technical writer, I immediately became fond of the PLT Scheme Guide, one of the clearest and most well-organized examples of documentation available for a programming language I’ve ever come across.
The manual is exquisitely crafted as a Getting Started Manual and a Reference Book at the same time, though remaining pleasant to read sequentially: a rare trait in technical documentation. Best of all, it’s free: you simply have no real excuse not to read it.

Besides its excellent documentation, PLT Scheme feels like a fresh and modern implementation of one of the two most important dialects of Lisp. It’s cross-platform, it has an extensive collection of packages and a very active community behind it.
After my first attempt to learn Haskell, I felt compelled to try out PLT Scheme and it immediately felt much easier and more user friendly to learn, partly because of DrScheme a dedicated IDE/learning tool optimized to get you started and feel comfortable with the language.
Caveats? None, unless you have an adversion for parenthesis, that is.

To get you started…

Clojure

Clojure is the most recent and notable attempt to bring Lisp back to life and ready to face the challenges posed to IT systems by the new century: concurrency and scalability. Because it runs on the Java Virtual Machine, you also get Java interoperability for free, in a more Lispy flavour. Although I’m a bit reluctant to deal with anything related to Java nowadays, Clojure’s approach makes it more appealing.

Unlike other Lisps (and Schemes) you may have encountered before, Clojure comes with some interesting additions:

Multimethods
Agents asynchronous actions
Some interestings special forms
Many pre-built data structures, like Vectors, Maps, Sets, Collections, …

Despite all this, Rich Hickey became increasingly popular both in the Lisp and Java world for creating such an interesting and well-designed language. Unlike with many new (and old) programming languages, I have yet to find a single blog post or article which is seriously criticizing Clojure in any way.

To get you started…

Squeak

Squeak has become one of the most popular Smalltalk implementations available. It has been used in some very interesting projects:

EToys, a kids-oriented but powerful development environment built in Squeak, was included as part of the educational sofware suite of the OLPC.
Seaside is a modern and very productive web framework running on Squeak.
Croquet is a development solution to build complex, multi-user virtual worlds.

If you ask Randal Schwartz, he’ll explain you why Squeak and Smalltalk are at least worth a look. Personally, while I’m attracted by Smalltalk’s unique approach to programming and its friendly syntax, I am still a bit overwhelmed by the way it works.
Squeak, and Smalltalk in general, runs inside (literally) a virtual machine written in Squeak itself. This means that:

You write your code inside Squeak
You debug, inspect and interact your code inside squeak
You run your code inside Squeak
You can install Squeak on virtually any platform, including mobile phones, fairly easily

Everything lives inside Squeak. It’s very weird to picture this without actually trying it, so I suggest you download it and give it a try: it will definitely be an unusual but intriguing experience.

Smalltalk takes programming to a whole different level, which is simply unimaginable for other languages. In return, it asks you to fully embrace the Smalltalk way of doing things, according to which external text editors, external version control systems and other common tools familiar to traditional programmers simply loose their purpose.

To get you started…

OCaml

Like Smalltalk, OCaml has been getting more attention recently than in the past. Sure, not everyone is planning to learn is these days, but after reading this article I admit I was eager to give it a proper try.

Despite being statically typed, OCaml offers some of the features which are common in dynamically typed languages like Ruby, such as duck typing, the possibility of creating Domain-Specific Languages and even extending the language syntax with custom operators and constructs.

Additionally, the OCaml Batteries Included project was created as an attempt to bundle a standard set of commonly-used library together with the language core. Even if this project is still in alpha stage, it definitely looks promising.

To get you started…

Factor

Factor is to Forth what Clojure is to Common Lisp: a reincarnation of an ancient language in a more modern and practical form. In the specific case, although it borrows from Lisp and Self as well, Factor retains the main characteristics of its ancestor: it’s stack-based, concatenative and has postfix notation.
While this is enough to put some people off, if you digg deeper you’ll discover that Factor offers all the most important features available in contemporary programming languages: garbage collection, dynamic typing, an object system, … they’re just presented in a very different way:

“Learning Factor is tough. One reason for this is that Factor is very different from other programming languages. Programmers today are used to imperative programming languages where data is stored and passed around in named variables (or function calls, which name their variables). Factor is the opposite of this. A lot of code tends to be written in a functional style, and even more jarringly, variables are rare, only referenced in a small fraction of words. Nobody intends to change any of this; it’s a feature, not a bug!”

– Daniel Ehrenberg, Learning Factor

Like Haskell, Factor demands a completely different programming approach to what you may be used to, but once you get past that, it can be as useful as any other language, if not more. The Furnace web framework, which powers the Concatenative wiki, is entirely built in Factor and runs on top of a Factor web server.

To get you started…

Lua

Lua (“Moon” in Portuguese), is a lightweight and fast scripting language which can be easily embedded in other systems. Compared to the other languages mentioned in this article, it is definitely the less alien of the lot: if you know a tiny bit of C or Java, you’ll be able to understand (and possibly write) 80% of Lua code without reading a single line of its documentation.

Despite its simplicity, Lua is considered a multi-paradigm language supporting imperative, functional and even object-oriented approaches. More specifically, Lua’s tables provide a simple but powerful way to create arrays, hashes and even classes (or better, prototypes). Simple (and multiple) inheritance is achieved through metatables, which allow calls to undefined functions to be transferred to parent tables.

Lua programs are not interpreted in the traditional way: they are compiled to bytecode and then executed in the Lua Virtual Machine. As a result, Lua code tends to be executed much faster than other interpreted languages, so fast that “as fast as Lua” has become a proverbial expression.
Lua found its niche in embedded applications and games development, basically everywhere there’s the need to provide a fast scripting language which is also very easy to learn and extend with C or other languages.

To get you started…

Scala

You may not be happy to see Scala in this list instead of other very valid and equally powerful languages for the Java Virtual Machine such as Groovy. While there was no doubt on whether Clojure should have been included or not, I was a bit hesitant to include Scala. In the end, I chose to do so simply because Scala fits better in this list than other languages: as you should have noticed by now, I am somehow more inclined to learn functional languages as opposed to their object-oriented counterparts.

Scala is both object oriented and functional. It offers the best of both worlds: classes, traits and mixins which may be familiar to OOP lovers but also anonymous functions, currying and pattern matching which may please Haskell enthusiasts. Additionally, it’s also compatible with Java: so if you use Java for work, trying out Scala for pleasure is definitely the most logical next step, especially if you want to experiment with functional programming in the meantime.

Compared to learning a fully-functional (no pun intended) language like Haskell, Clojure or PLT Scheme, learning Scala is definitely easier and will feel less alien.

To get you started…

Epilogue

There are so many interesting programming language out there that it’s very hard to keep track of all of them. I hope this list can aid you in the right direction, whichever it may be.
Some people may debate over the very essence of this article: why choosing a programming language? Why spending time and energy in a task which may lead to a lot of confusion in your mind and lead you nowhere? What’s the purpose of learning something which may feel totally alien to you?

A programming language is ultimately just a tool to get your job done. If you have to write an end-user, desktop GUI application which will always run on Windows and which needs to inteface with Microsoft technologies, you’ll choose C# over Haskell, there’s no doubt about that. Especially if 500 developers in your company already develop in C# and you don’t, as a matter of fact, have a saying on the matter.

But what if you could choose? What if you wanted to develop your own geeky command line application to automate a particular task for yourself, and not because someone else tells you to do so? Would you be willing to experiment with something totally different and potentially difficult just for the sake of learning new things?

If the answer is yes, then you should take a look at this list again. Not now, maybe not this month or this year, but when you feel the time is right, and give one of these languages a shot. It may not end well (so far I attempted to learn Haskell twice, with no luck), but I promise you it will be worthwhile, in the long run.
If you already mastered some of these languages already, or even all of them, be assured that they’re plenty out there ready to be discovered and open your mind even more. Or, if you prefer, there are a lot of minds out there which may need guidance in learning and discovery. Help them. Write articles, tutorials, books, educate and evangelize: ultimately, that will be your greatest reward.

Where does your Ruby code live?

h3rald@h3rald.com — Sat, 08 Nov 2008 12:34:00 -0000

Back when I wrote my 10 reasons to learn Ruby article, I mentioned RubyGems in Reason #1 as one of they key features of the Ruby programming languages.
Indeed, gems make getting Ruby programs as easy as typing gem install <something> from the command line. When you want to distribute something new in Ruby, there’s no need to give people download links, zip files or setup programs, just tell them to get the gem. That’s perfectly normal, and extremely cool.

Gems are normally stored on RubyForge, so all you have to do is uploading your gem there, and it will be available to the rest of the universe. It’s a nice feeling. I remember when I first uploaded RawLine and then tried gem install rawline just for the hell of it: it downloaded and installed the gem, as expected.

Back in the day, if you wanted to find something written in Ruby, all you had to do is search through RubyForge, and you’d eventually find it, with a bit of luck.

Can we just have git, please?

RubyForge had, until recently, one major problem: it only allowed CVS and SVN repositories, and you had to make your choice when creating the project, once and for all. So when the cool guys at GitHub rolled out their social code hosting web site, most of the créme de la créme of RubyForge flocked there in mass migration: Rails, Merb, RSpec… you name it.
Once the big guys made the switch, a lot jumped on the GitHub bandwagon of course. Result: we have a lot of projects still on RubyForge, but quite a few (and important ones) on GitHub.

Why did people move there? Well, at first it was because they wanted a sleek-looking git host, and RubyForge didn’t offer git at the time. But git is now available on RubyForge, so why don’t people use it?
I’d like to know how many people use git on RubyForge. Apparently you can have your old SVN repository manually migrated to git, if you ask nicely (and RubyForge people are very helpful always, anyway). Still, I don’t think many people use git there, and hardly anyone (if any) moved back from GitHub.

What’s so special about this new “social code hosting” site then? I guess just a few key features:

Fast and reliable git hosting
The ability to “watch” other people’s repositories and interact with them “the git way”, also by forking.
There’s a whole new and fresh community feeling to it: you can follow people, message them, etc.
The interface is much more neat than RubyForge’s (OK, granted, it doesn’t take much)
Really cool stats and graphs
A basic, but functional, wiki

…oh, and bug tracking, too!

GitHub has no bug tracking features. It tracks an awful lot of stuff about your repositories and people working on them, but “batteries are sold separately”. You can get batteries here, for example. Apparently, GitHub and LightHouse are seamlessly integrated.

So now you can sign up to two cool brand new web applications with neat interfaces instead of sticking with the old-looking RubyForge (which comes with “batteries included”, after all).
Personally I’m very confused now. Fortunately I don’t have any extremely cool projects used by thousands of people, so jumping from one source code hosting solution from another is not really an issue for me, but I imagine it would be for others! Correct?

So, as far as I know, if you are a Rubyist, here’s what you can do:

Stick with RubyForge: it’s not so bad after all.
Embrace GitHub (and Lighthouse): it’s extremely nice to use. Some people are not too convinced that this is the best choice though.
Go for something in between, like Assembla, which actually has an impressive list of features and is powered by Rails too, so you’ll feel at home. Google Code used to be another common choice, but sadly they don’t offer git yet.
Do-it-yourself, maybe using something like Gitorius and some open source bug tracking/project management solution.

So… what choice did you make or are you planning to make?

Moving houses

There’s one simple issue to consider when moving your code to a new place: what happens to your old place. If have a relatively popular project, a lot of people may have bookmarked your project page on RubyForge, or the RubyForge subdomain which you may have used as the “home page” for your project (in truth, most of the ones who moved away still use it).

You may setup a redirection to the new home page or put a notice saying that the project moved somewhere else and point visitors to GitHub and LightHouse, or to another web site, if you wish. When Rails moved to GitHub, that wasn’t much of a problem as Rails has its own web site.

What may become a problem is your old repository. In Rails’ case, they left the old SVN repository available on sourceforge for a while and then removed it altogether. Other project owners have just abandoned their old repositories, occasionally resulting in someone else deciding to leave a note as their last SVN commit.

These solutions all work (you eventually drive people to the new home of your project), but it’s not very nice, that’s all. What happens if someone comes up with something cooler than GitHub? In all honesty, you may end up moving house over and over again.

Don’t forget the gems!

One thing I liked about RubyForge, as I wrote at the beginning, was that if you uploaded a gem there, it was immediately available to everyone typing gem install <something>.
Luckily, GitHub supports gems, too! We’re saved. The page they put up is utterly awful, but it does the job: you can have your gems hosted on GitHub.

Good! So surely I can get Rails now, right? Yup: gem install rails will get the latest version of Rails for you, straight from GitHub.

Actually, no. It doesn’t seem to work that way: sure you can get the latest rails in that way, but it will actually be downloaded from RubyForge (go check the downloads, you’ll see it there).
So even if technically you got Rails, you got it from RubyForge. If you want to get gem from GitHub, you have to add it as gem source first (that’s an una tantum operation, luckily): gem sources -a http://gems.github.com.

So, yes, you can move to GitHub and you’ll also get gem support: but please remind the users that they have to add GitHub as gem source. Or, better, you should always remember to upload your latest gems to GitHub and to RubyForge as well.

The present

To sum up:

If you want, you can stay on RubyForge. It has git, it has gems, it’s probably not nearly as prettier than competitors and is not as social, but it works.
You can opt for GitHub+LightHouse, have a slick interface, plenty of features and your project will be scattered in 2 different places + your home page, and you’ll also have to keep uploading your gems to RubyForge.
At this point, you may even go for something completely different, like Assembla or your own setup, but still upload your gems to RubyForge.

The obvious solutions at this point would be that the folks who craft rubygems (the gem which makes the gems, to be clear) add GitHub as default source. Sure as hell when that happens other people will want that too (hey, I’ll have gems.h3rald.com setup by then!). Is this the future? I hope not.

The future?

You know there’s a domain called www.rubygems.org? It’s where the gem manuals are!
As much as I love documentation, there’s nothing wrong in moving all those documents and books to something like docs.rubygems.org, right?
Then they could make RubyGems.org the only official gem server and tell people they should upload their gems there if they want to distribute them efficiently (after manual approval, if necessary, like there is on RubyForge).

In this way:

You wouldn’t have to upload stuff to RubyForge anymore
You could have the clever folks at GitHub to create a simple script to automate the upload
You’d have virtually all the gems in one place
You’d put a good domain name (currently almost forgotten) to good use

While they are at it, the clever folks at RubyGems.org could also setup a proper gem directory with a proper search. I’m sure there would be plenty of people who could help, too!

It’s not impossible, right? They said that making Rails/Ruby/RSpec documentation more accurate and accessible was impossible, but now there’s APIdock, correct?

Personally I’d like it to be a collaborative effort of the Ruby community (like ruby-lang.org), rather than one private company showing off, but I think everyone will be happy as long as it works.
I’m sure people will contribute, I would try at least (after finishing the Italian translation of ruby-lang.org, that is… erhm, well, that’s another story…).

Thoughts?

Git for the Locals

h3rald@h3rald.com — Tue, 15 Jul 2008 04:18:00 -0000

“This is a local shop for local people, we want no trouble here!”

— Edward, The League of Gentlemen

I’m normally quite cautious when it comes to IT novelties like new frameworks, new methodologies and similar, especially when it feels like they’re over-hyped. Especially nowadays, it is sometimes very hard to tell whether something new is over-hyped or really a Good Thing™ without spending some time looking into it. And especially nowadays, finding the time to look into something new can be a real challange.

I deliberately didn’t look into Git properly since it went “mainstream” (maybe I shouldn’t use this word), but when this tutorial came out I couldn’t resist. Sure, I knew Git was an amazingly fast distributed version control system, that GitHub offered free accounts, that all the cool guys were slowly starting to use it in place of Subversion, etc. etc.

What I didn’t realize though, that the most obvious advantage of this DVCS was the fact that it was distributed, i.e., it didn’t need a centralized server.

Let me repeat this: Git doesn’t need a centralized server.

Really.h3. …But it’s not user-friendly!

If you’re a Windows user and you used Subversion before, chances are that you got accustomed to TortoiseSVN, too. TortoiseSVN is — in a way — a nice graphical fron-end to SVN which provides seamless Windows Explorer integration.
Git doesn’t have anything like that yet. There’s something in the works, sure, but nothing really comparable to TortoiseSVN. Therefore, you are kindly suggested to get on and use the command line for all your git stuff.

Oh well, I personally love using command line interfaces for certain tasks, event if I spend more time on Windows than on any other OS and well, the DOS prompt is no way near to bash & Co.

For the ~~lazy gits~~ Windows users, MSysGit is the answer to all your problems. Officially you have to install Cygwin and all its crap to be able to use Git on Windows. Not that Cygwin is bad, but I personally don’t like the extra layer it creates between you and an OS symulation which is not really what’s on your machine.It would be great if you could get all the Bash goodies natively, without the hassle.

that’s basically what you get for free when you install MSysGit: the best (to date) version of Bash you could possibly dream of for Windows, along with a few handy Gnu tools and of course all git commands.
In a few click, you’ll be able to use Git (and Bash!) right away: no tricks, no hassle, no kidding.

And stop moaning about the command line not being user friendly. You want a new repository anywhere? Just type in the following:

git init
git add .
git commit

This will create your new repository in the current directory, add all your files and filders recursively, and perform the initial commit. What’s so hard in this? Nothing. And it’s faster than SVN, for sure.

Are you local?

“Being local” has its own advantages: you know where you stand, you know what to expect, you don’t depend on other people. What I didn’t fully realize about Git is that it can be a 100% local repository.

The three Git commands I mentioned earlier can be used to create a repository there, exactly where you are: not on a server far, far away.
Let’s see what this means:

You don’t need an Internet connection anymore to use a VCS
You don’t get a .svn folder in every damn directory of your project, with a load of crappy files in it.
You get only a .git folder at top level, and that’s where your repository actually is. Granted, there are going to be quite a few files in there, but they’re not going to be scattered all over the place
You can physically copy your repository anywhere and still use it
You don’t need to signup to GitHub for an account, if you only want your own VCS

OK, this is an extreme scenario, but sometimes you may want your own local repository for your stuff. You may want a place to version your documents, or a place to version your own little pet programming project nobody knows about.
With Git, you can get all the advantages of a VCS (and an incredibly fast VCS) without having to setup any server infrastructure: just install Git on your machine, and you’re done. No server processes, no hassle.

Don’t connect, synchronize

All the information your repository needs is stored in that little .git folder, nowhere else. You can copy your files and that folder, and you’ll still get your repository back wherever you are. Maybe you can zip it before copying it, and then unzip it where you need a VCS, event.

I tried using some synchronization utilities like SyncToy or RoboCopy on Windows to keep my files synchronized on multiple computers: it all started off from the fact that I can’t use SSH at work, so I wouldn’t be able to push my commits back to a central repository online like GitHub.

So here’s what I did:

I setup a local repository for my project on a local folder at work.
I started working on my project, did a few commits.
After performing the last commit for the day (you are encouraged to commit often by Git, really), I synchronized that folder with my USB key, via SyncToy.
Back at home, I used SyncToy again to synchronize my files (including the repository) between the USB key and my home computer.
Performing a git status showed that some files have been modified (all of them, actually): that’s because Git detected that they weren’t the same files which were committed, presumably because of different timestamps etc.
All I did was a git reset --hard to get exactly the same files I committed at work, with absolutely no information loss.

Isn’t it a bad thing to move your git folder back and forth and let another program to synchronize files within it? Maybe, but it seems to work so far. A safer option, in this case, may be zipping the folder before synchronizing it, just to be sure.

Conclusion

Git can do much more than this. Git offers some really interesting branching features, for example, which I didn’t mention in this article, of course, like several dozens of other commands. What I tried to point out was that Git can be used by anyone, as a fast, simple and very effective private local repository. In case you need one, that is (if you are really local).

I'm on Twitter, anyway...

h3rald@h3rald.com — Sun, 18 May 2008 09:04:00 -0000

I’ve been neglecting my blog, I know. The truth is that I’m quite busy in this period: I have more responsibilities in my daily full-time jobs, my lunch breaks are getting shorter and I don’t have much free time. At any rate, here’s what’s going on:

I’m writing a new article for an online magazine (assuming I’m gonna finish it)
I signed up for a freelance technical reviewing job, for a new Ruby book which will come out soon-ish
I’m getting ready to finally visit Rome (again), this time with my fiancée, for our fifth anniversary.
I’m slowly preparing a version 1.0 of RedBook, which involves quite a lot of refactoring (and hopefully better documentation and tests).
I’m trying to learn a little bit of Haskell: it seems to be one of the few non .NET languages able to produce standalone .exe files, nowadays…

Last but not least, I now decided to use Twitter regularly, so you can follow me there, if you wish!

New Release: RawLine 0.2.0

h3rald@h3rald.com — Wed, 02 Apr 2008 03:33:00 -0000

~~InLine~~ RawLine 0.2.0 is out!

*Raw*Line is the new name for InLine, in case you didn’t guess. The name was changed to avoid name collision problems with the RubyInline project.

Here’s what’s new:

Added /examples and /test directory to gem.
Escape codes can now be used in prompt.
It is now possible to use bind(key, &block) with a String as key, even if the corresponding escape sequence is not defined.
Added Editor#write_line(string) to print a any string (and “hit return”).
Library name changed to “RawLine” to avoid name collision issues (Bug 18879).
Provided alternative implementation for left and right arrows if terminal
supports escape sequences (on Windows, it requires the Win32Console gem).

In particular, I decided to provide an “optimized implementation” for the left and right arrows using escape sequences rather than shameful hacks. This is now possible because the Win32Console gem now enables ANSI escape sequences on Windows as well (weehee!).

So:

If you’re on *nix all good, your terminal is smart and can understand escape sequences => the new implementation will be used.
If you’re on Windows and you installed Win32Console, your termnal is smart and can understand escape sequences => the new implementation will be used.
If you’re on Windows and you didn’t install Win32Console, then your terminal is stupid and it doesn’t understand escape sequences, so the old implementation will be used.

The new implementation is significantly faster than the old one, on Windows at least, and the cursor now blinks properly when left or right arrows are pressed.

I re-emplemented only cursor movement because I’m still having some problems in getting the delete/insert escapes to work properly (or better: how I want them to work!).

InLine name change: what's your opinion?

h3rald@h3rald.com — Thu, 27 Mar 2008 05:30:00 -0000

I’ve been kindly asked by the lead developer of RubyInLine to change the name of my InLine project, due to potential confusion and conflicts.

This makes sense, and I’m ready to change the name of my project, although I’m not that good at choosing original and smart names, so well, any suggestion is more than welcome!

I was thinking of something like:

RawLine
EditLine
RawInput
RubyInput
RubyLine

I personally think that RawLine is probably the best option, but please, if have any better idea just speak up!

P.S.: “RedLine” is taken, unfortunately, otherwise it would have been my first choice since the beginning.

RawLine - a 100% Ruby solution for console inline editing

h3rald@h3rald.com — Mon, 10 Mar 2008 05:59:00 -0000

One of the many things I like about Ruby is its cross-platform nature: as a general rule, Ruby code runs on everything which supports Ruby, regardless of its architecture and platform (yes, there are quite a few exceptions, but let’s accept this generalization for now).

More specifically, I liked the fact that I could use the GNU Readline library with Ruby seamlessly on both Windows and Linux.
Readline offers quite a lot of features which are useful for those people like me who enjoy creating command-line scripts, in a nutshell, it provides:

File/Word completion
History support
Custom key bindings which can be modified via .inputrc
Emacs and Vi edit modes

Basically it makes your command-line interface fast and powerful, and that’s not an overstatement. Ruby’s own IRB can be enhanced by enabling readline and completion, and it works great — at least on *nix systems.

For some weird reason, some people had problems with Readline on Windows: in particular, things get nasty when you start editing long lines. Text gets garbled, the cursor goes up one or two lines and doesn’t come back, and other similar leprechaun’s tricks, which are not that funny after a while.

Apparently there’s no alternative to Readline in the Ruby world. If you wan’t tab completion that’s it, you’re stuck. Would it be difficult to implement some of Readline functionality natively in Ruby? Maybe, but the problem is that for some reason the Ruby Standard Library doesn’t have low level methods to operate on keystrokes…

…but luckily, the HighLine gem does! James Edward Gray II keeps pointing out here and here that HighLine’s own get_character method does just that: it returns the corresponding character code(s) right when a key is pressed, unlike IO#gets() which waits for the user to press ENTER.

Believe it or not, that tiny method can do wonders…h2. Reverse-engineering escape codes

So here’s a little script which uses get_character() in an endless loop, diligently printing the character codes corresponding to a keystroke:

#!/usr/local/bin/ruby -w

require 'rubygems'
require 'highline/system_extensions'

include HighLine::SystemExtensions

puts "Press a key to view the corresponding ASCII code(s) (or CTRL-X to exit)."

loop do

	print "=> "
	char = get_character
	case char
	when ?\C-x: print "Exiting..."; exit;
	else puts "#{char.chr} [#{char}] (hex: #{char.to_s(16)})";
	end
	
end

A pretty harmless little thing. Try to run it and press some keys, and see what you get:

Press a key to view the corresponding ASCII code(s) (or CTRL-X to exit).
=> a 96 (hex: 61)
=> 1 49 (hex: 31)
=> Q 81 (hex: 51)
=> α 224 (hex: e0)
=> K 75 (hex: 4b)

Hang on, what are the last two codes? A left arrow key on Windows, apparently.

Welcome to the wonderful world of input escape sequences!

To cut a long story short, both Windows and *nix system “terminals” translate special keystrokes into sequences of two or more codes. This applies to things like DEL, INSERT, arrows, etc. etc.
For some ideas, check out:

Windows Scancodes (Thanks Huff)
VT220 Terminal Input Sequences (Thanks James)

Let’s now assume that we’re smart and we can write a program which can parse keystroke properly, including handling different input escape sequences according to the OS, what can it be used for?
Well:

For normal characters, just print them back to the screen (get_character doesn’t print anything, it “steals” the keystroke)
For special characters, do something nice!

We could setup TAB to auto-complete the current word according to an array of matches, or bind the up arrow to load the last line typed in by the user, for example, that’s basically something Readline does, right?

RawLine: how it works and what it does

I created a small project on RubyForge called RawLine (not to be confused with RubyInline, a completely different thing altogether, sorry about that) to play around with the possibilities offered by the get_character method. The library is just a preview of things which can be done, but it’s already usable, provided that you’re brave enough to try it out, that is.

The basic idea behind RawLine is to be able to parse keystrokes properly on different platforms and re-bind them to a set of predefined, cross-platform actions or a user-defined code block.

Basic line-editing operations

The first challenge was to re-invent the wheel, i.e. re-bind keystrokes to their typical actions: a left arrow moves the cursor left, a backspace deletes the character at the left of the cursor and so on. Yes, because get_characters gives you the right character codes at the price of cancelling their normal effects, which is a great thing, as you’ll soon find out.

Printing a character on the screen was one of the easiest tasks (at first). IO#putc does the job pretty well: it prints a character out.
What about moving left? Easy: print a non-descructive backspace (\b) and hope it is really not destructive. I did some tests and it seems to do as it’s told and move the cursor back by one position.

Moving right was a little trickier: the easiest thing I found was to re-print the character under the cursor, which will then move the cursor forward (as naive as it may seem, it does the job!). If there’s nothing under the cursor, then we must be at the end of the line and it shouldn’t move anywhere, so there we go.

What if I move left a bit and then start typing normal characters? Well, everything is rewritten of course: this will be our “character replace mode”. Unfortunately users don’t like this behavior that much, so what I did was this:

Copy all characters from the one at the left of the cursor till the end of the line
Print the character to be inserted
Re-print the previously-copied characters
Move the cursor back at the right place

Again, a primitive solution which works seamlessly on all platforms, and yes, it’s fast enough that you don’t notice the difference.

As you may have guessed, this of course means that I always had to keep track of:

The cursor position within the line
The text currently printed to the screen

Backspace and delete were implemented in a similar way, you can figure it out yourself or look at the source code: I won’t bore you any further!

History management

The next step was to implement a history for both the characters inputted by the user (to allow undoing and redoing operations) and for the whole lines. This was just an ordinary programming exercise: a simple buffer with some extra controls here and there, nothing too scary.

So every “modification” to the current line being typed is saved in a line history buffer and all the lines entered are saved in another history buffer. All is left is to allow users to navigate through these buffers back and forth.
Nothing impossible: all I had to do was keeping track of the current element of the history being retrieved and then overwrite the current line with a new line stored in the buffer? How’s this line overwriting done? Same old:

Move the cursor to the beginnig of the line
Print X spaces, where X is the line length, so that the characters are no longer displayed in the console
Move the cursor back to the beginning of the line
Print the new line.

Easy and naive, as usual. But again, it works well enough.

Word completion

The other challange was word completion. The current implementation can be summarized as follows:

If TAB (or another character, if you wish) is pressed, call a user-defined completion_proc method which returns an array and show the first element of the array (in this case I actually used a cyclic RawLine::HistoryBuffer, not an array)
If the user presses TAB again, show another match, and so ad infinitum if the user keeps pressing TAB.
If the user presses another key, accept the default completion and move on.

Obviously this means that:

RawLine has to keep track of the current “word”. A word is everything separated by a user defined word_separator, which can obviously modified at runtime, with care.
Regarding the completion_proc, typically you may want to return only the elements matching the word which is currently being written, so that’s given as default parameter for your proc. Exactly like with ReadLine, the only difference is that you can access other things like the whole line and the whole history in real time, which can be really handy at times!

Here’s a simple example:

editor.completion_proc = lambda do |word|
	if word
		['select', 'update', 'delete', 'debug', 'destroy'].find_all	{ |e| e.match(/^#{Regexp.escape(word)}/) }
	end
end

Custom key bindings

All these pretty things are obviously bound to some keystrokes. If the key corresponds to only one code, everything is fine, but because special keys typically aren’t so it was necessary to implement a mechanism to track an escape key (e.g. 0xE0 and 0 on Windows and \e on Linux) and listen to further characters, in case a known sequence is found. Anyhow, the final result of the method used for character binding is the following:

bind(key, &block)

Where key can be:

A Fixnum corresponding to a single character code
An Array of one or more character codes
A String corresponding to an escape sequence
A Symbol corresponding to a known escape sequence or key
A Hash to define a new key or escape sequences

So, in the end you can do things like this:

editor.bind(:left_arrow) { editor.move_left }
editor.bind("\etest") { editor.overwrite_line("Test!!") }
editor.bind(?\C-z) { editor.undo }
editor.bind([24]) { exit }

Which, for Rubyists, it’s far sexier and more flexible than editing an .inputrc file.

How do I use it, anyway?

A code example is better than a thousand words, right? So here you are:

#!/usr/local/bin/ruby -w

require 'rubygems'
require 'rawline'

puts "*** Inline Editor Test Shell ***"
puts " * Press CTRL+X to exit"
puts " * Press CTRL+C to clear command history"
puts " * Press CTRL+D for line-related information"
puts " * Press CTRL+E to view command history"

editor = RawLine::Editor.new

editor.bind(:ctrl_c) { editor.clear_history }
editor.bind(:ctrl_d) { editor.debug_line }
editor.bind(:ctrl_e) { editor.show_history }
editor.bind(:ctrl_x) { puts; puts "Exiting..."; exit }

editor.completion_proc = lambda do |word|
	if word
		['select', 'update', 'delete', 'debug', 'destroy'].find_all	{ |e| e.match(/^#{Regexp.escape(word)}/) }
	end
end

loop do
	puts "You typed: [#{editor.read("=> ").chomp!}]"
end

This example can be found in examples/rawline_shell.rb within the RawLine source code or gem package.

Current status and availability

I currently released RawLine 0.1.0 on SourceForge, and it can be installed via:

gem install -r rawline

The RDoc documentation is available here.

Feel free to try it out. First of all try the rawline_shell.rb example, and see if it works on your machine. If it doesn’t than maybe you try re-binding some keys (use key_tester.rb to “reverse-engineer” your terminal’s input escape sequences), and let me know!

Status information and limitations:

It has been tested on Windows (XP, using the usual command prompt) and on Linux (ZenWalk, using XFCE Terminal).
It can handle lines no longer than the maximum terminal width – 2. This is to ensure that the cursor never “falls down” to the next line.
On Windows, the cursor doesn’t blink immedialy when moving left, but it moves, don’t worry.
On Linux, you should really consider installing the Termios library for a faster experience (otherwise get_character won’t parse characters correctly if you press and hold a key, and that, trust me, is a real mess!).
RawLine is very far from being a complete replacement for the ReadLine library, and it is currently in alpha stage.
Release 0.1.0 has been created after 2 weeks of sporadic coding during lunch breaks and week-ends.

For any ideas on where to go from here, comments and feedback, just reply below or send an email to my usual email address.

A closer look at Komodo Edit

h3rald@h3rald.com — Sun, 25 Nov 2007 06:23:00 -0000

What’s your favorite code editor?

This is a common question which still keeps popping up on community boards, mailing lists, comments, etc. Every programmer who writes code in some programming language normally has an editor of choice. Being realistic, most of the times it’s not only one program but several, depending on the language and on the features needed at the time.
Yes, great, but how do you choose your favorite editor?
By trying a lot of them of course: that’s what I’ve been doing since I started programming. Lately I’ve become fond of Vim (or better, gVim), although I have a few other editors I may recommend, e.g.:

Recently, however, I came across my n^th^ “what’s your favorite editor” thread and someone mentioned Komodo Edit. I knew of it already, actually, but I never had a chance to give it a proper try.
ActiveState is well known mainly for two things:

Their effort in offering a lot of commercial, windows-based Perl libraries
Their commercial IDE, Komodo IDE, which I personally tried quite a long time ago

The problems of Komodo IDE are foundamentally two:

It costs money – this is not great in a world where Eclipse and Netbeans are free
It is an IDE – which normally means ‘heavy as hell’.

It’s a matter of taste and needs: some people feel more confortable with using an editor for certain tasks, while sometimes an IDE may be the best solution, despite its potential slowness and bulk.

Komodo Edit solves the above-mentioned problems because:

It’s free
It’s an editor

Actually I wouldn’t call it an editor, because it offers quite a lot of features which are normally absent in editors — it’s something in-between, which definitely deserves a try.

User interface

Komodo Edit’s interface is one of the most clear I’ve ever come across. It is organized in four main areas plus the top menu and toolbar (which only has the buttons you REALLY need, unlike Notepad++’s 31-button-bar).

The central area is for editing, the left pane is for the Project browser, the right one is for the Toolbox and the bottom pane is for command output. Luckily enough, a set of handy little buttons is provided in the toolbar to show and hide each pane. I normally only use the Project Browser and the main editing area, leaving the Toolbox and Command Output panes hidden, but that’s up to you really.

Komodo Edit allows symultaneous editing of multiple documents, which means that it has tabs like most of the best editors out there. Furthermore, it is possible to have Komodo re-open the files edited in the last editing session, saving you a lot of time. Granted, a lot of IDE do, but this is NOT an IDE, remember? It’s an editor, or at least it is advertised as such.

In reality it has most of the power of a full-blown IDE though normally remaining under the 60K memory usage (out of 2GB of total RAM) — which is not that bad, considering what Eclipse and NetBeans need.
Out of all the extra features offered by Komodo IDE, the only one I truly miss is the Code Browser. Other than that, it quickly became my editor/IDE of choice (when gVim isn’t looking, of course…)

Lets find out why…

Editing features

Komodo Edit comes with all the editing features of ever average editor, so “[…] Code commenting, auto-indent and outdent, block selection, incremental search, reflow paragraph, join lines, enter next character as raw literal, repeat next keystroke and clean line endings on “save”.", it uses Scintilla as main editing component, which makes it a close relative of Notepad++, Notepad2 and of course SciTE when it comes to understanding languages and syntax highlighting.

This is good, of course, as Scintilla is an excellent editing component, but – I have to say this – not as good as Vim when it comes to syntax highlighting (nothing is as good as Vim though, so I can’t really complain!).
As you can see from the screenshot I included earlier on, it is possible to change the default black-on-white color scheme to something more stimulating and energy-saving. This doesn’t mean I have to manually re-set the color of each element, it actually comes with a black-background scheme, which is handy.

Supported Languages & Syntax Highlighting

Komodo Edit supports quite a few programming languages, which means it can recognize the most common ones (C, C++, Java, PHP, Python, Ruby, Perl) but it also smart enough to notice framework-specific syntaxes like Smarty, Django or RHTML.
Like every scintilla-based editors, it sports a nice HTML multi-highlighter which allows you to keep putting all the Javascript, CSS and server-side scripting into the same file, GREAT! No, you probably wouldn’t want to do that, but it’s a good thing to have.

Auto-completion

What makes this editor a really handy tool is its auto-completion capabilities. Why? well, because it supports:

Ruby: require, class modules (on . and ::), class variables and methods, method calltips.
Python
Perl
PHP
XSLT
XML
Tcl

Why is this so special? Well, because if you want this you normally need an IDE, and if you want it for Ruby AND Python AND Perl your choices are very limited.
I played with the Ruby auto-completion features quite a bit, and I’m actually really impressed.

It can suggest what to write through calltips after a require directive, after a . and a ::, and hitting CTRL+SPACE (or just tab if you configure the right option) will auto-complete what you’re writing, be it a language keyword, a variable of any kind or a method. Additionally, it comes with “soft characters support”, which means it will try to match ( [ { when possible, allowing you to write over the completed character if you want to.

Syntax Checking, Vi/Emacs key bindings and code folding

The heading is almost self-explanatory here: Komodo Edit supports code folding (you can even chose the folding chracters!) for all its supported languages, syntax checking (it can detect and display errors before running the script, very useful in Ruby, and hard to find in other editors) and Vi/Emacs key bindings.
It also offers “vi emulation”, which is constantly improving through every release – so you won’t forget Vim’s keys when I don’t use it: very nice, and again, hard to find in other editors, nevermind IDEs!

Projects and Tools

The Project Browser and Toolbox are two features which are normally presents in IDEs and which are normally not found in editors. Granted, some editors like PSPad do indeed have “projects”, but most of the others don’t. A project in Komodo Edit is normally composed by:

Some Live Folders including all the source files of the application you’re developing
An optional set of tools, commands, snippets and other goodies which may help you coding that particular application.

It is possible to create these tools by clicking the Add Item to current project button in the Projects toolbar or by clicking the Add Item to Toolbox button just over the toolbox.
Either way, you can choose among the following:

File/Remote File

Add a file on your local machine or a remote file hosted on a server you configured via Edit > Preferences > Servers. Supported protocols are: FTP,FTPS, SFTP, SCP.

Folder

This will not link to a folder and import local files in Komodo, instead, it will create a container for other tools, not for local files.

Live Folder

On the contrary, a live folder links to an actual folder on your machines, and all files and directories inside it are automatically imported. Note that it is possible to choose to include or exclude certain files or directories from being imported by right-clicking the folder and editing its properties.

Command

This will create a shortcut to a command to execute. It is possible to specify its parameters, the directory where it will be run, whether its output will be displayed in the Command Output or in a newly-spawned console window, etc. etc.

Snippet

TextMate fans will love this. Komodo will let you create a code snippet for later use. Furthermore, it is possible to specify “tabstops” to automatically select certain words when tab is pressed (so you can effectively fill in only particular fields of the snippet).

Template

A simple but effective way to create code templates.

Url

A link which will open a given url.

Open… Shortcut

This will popup an Open File dialog in a direcxtory of your choice.

Macro

For those who require even more customization, it is also possible to record or code macros in Python or javascript, and then configure their key bindings and triggers.

Custom Menu/Custom toolbar

This was really impressive. Sure you can group all your tools in folders in your current project or you can create them in the toolbox to make them available all the time, but it would be cool if the editor itself could make those tools available by default in a toolbar or a menu. Well, that’s possible: all you need to do is create a new custom menu or toolbar and populate it with your tools by drag and drop. Very, very nice!

This mini-framework to create custom tools can be used to create project templates in a blink. To show this concept, Komodo Edit comes with a Rails template with almost all the tools you need when coding a Ruby on Rails application:

Create/delete database
Generators
Migrations
Run server
Example view snippets

Conclusion

Komodo Edit is an interesting editor which offers a lot of features which are normally only available in IDEs at a smaller memory footprint. Granted, when I want to jot something down I still prefer to fire up gVim, but for a serious coding session, Komodo is the right choice.
Its close attention to details and its ease of use make developing an even more pleasant experience, although perhaps there’s still room for improvement, if you’re really fussy.

Sometimes when you start getting used of its advanced features, the lack of a code browser seems a real shame, but after all, ActiveState must sell their IDE to someone at some point!

Another thing which I would have liked is the ability to create new syntax highlighting schemes, which Notepad++ and VIM both offer. Whydoes it bothers me so much? Well, because I’d like a Textile syntax highlighting scheme for writing blogs and articles. VIM and Intype seem to be the only ones which offer it out-of-the-box, but there’s no trace of it in Komodo Edit.

Actually it is possible to create new syntax highlighting schemes and extend Komodo Edit via XUL extensions, exactly like Firefox. After a closer look, the Django syntax was added in this way.

Unfortunately there aren’t that many extensions available for Komodo Edit, yet, but the Activestate Community seems very active, so you never know. Additionally, the recently-started OpenKomodo is a new project created by ActiveState to “[…] create an open source platform for building developer environments. ActiveState has open-sourced elements of Komodo Edit, a free multi-language editor for dynamic languages based on Komodo IDE, to create the Open Komodo code base”. A new competitor for Eclipse and Netbeans will be available soon?