self.user = USER
self.password = PASS
end

To tweet, simply execute this line:
Tweet.post(:update, :status => "7 LOC Twitter API client FTW") if Rails.env.production?

Did you notice the check for production environment? That's just how leet this client is. Also, you might want to put a rescue block after it. Twitter tends to timeout, which raises an exception in ActiveResource.

First the wrong way to go about this. You don’t retrieve the pagination links and then hack at the resulting string. You do not find-and-replace link anchors and classes to get where you want. That is ugly, brittle, hard to understand and generally awful. You simply subclass the object that WillPaginate uses itself to render the links.

That is called the LinkRenderer and building your own is easy. This post led the way for me. My pagination needs are much simpler though. I do not need any of the page links; just previous and next. And I don’t need any inactive link. When we’re on the current page, no link should be rendered at all.

Without further ado here is the class I ended up with:

class MyPaginationLinkRenderer < WillPaginate::LinkRenderer
  def to_html
    links = []

    # previous/next buttons, but never a disabled one
    if @collection.previous_page && @collection.previous_page != current_page
      links.push page_link(@collection.previous_page, 'prev')
    end

    if @collection.next_page && @collection.next_page != current_page
      links.push page_link(@collection.next_page, 'next')
    end

    links.join @options[:separator]
  end

  private

    def page_link(page, classname)
      @template.link_to page.to_s, url_for(page), :rel => rel_value(page), :class => classname
    end
end

As you can see, my pagination links is an array with max two items. The previous page and the next page. By overriding the to_html method, I make sure to skip most of the built-in customisable options and go straight to the code I need.

Using this renderer instead of the default one is equally easy. Since I also need the normal pagination links, I want to specify using this renderer on each and every page. So my code to render the links looks like this:

<%= will_paginate @articles, :renderer => MyPaginationLinksRenderer %>

Lastly, to use this code I stuck it into a file in config/initalizers. Custom pagination links … DONE.

For simple sites, this really beats having to maintain entire .html files. The content files really are simple text documents, no html noise. When I am done editing these text files, I press a button and they are compiled into complete html documents with all the HEAD, META, BODY and whathaveyou goodness. I can FTP that over and the site is live, boom!

Markup haiku

Now of course when I say text document, that is almost the case. Being a web geek I do want some structure in there: bulleted lists, headers, a table maybe. To represent structure in simple text files most people choose Markdown. This works quite well. You create html bulleted lists by slapping asterisks in your text file. For reasons of sheer R&D I decided to go with haml.

Haml takes your gross, ugly templates and replaces them with veritable Haiku. Haml is the next step in generating views in your Rails application. Haml is a refreshing take that is meant to free us from the shitty templating languages we have gotten used to. Haml is based on one primary principle. Markup should be beautiful.

I have used haml on a project before and thought it was very neat. It basically is a wet dream for the prototypical detail-obsessed, dont-repeat-yourself meta-code-generating geek. Anywho. Haml enables me to express structure like headings and tables in a still very readable text file. So boom, haml was in.

Get that puppy on the server

Now for deploying a website to the server: I get sick to my stomach doing that by hand. It really is not a job you want to be doing by hand. You might upload to a wrong folder, your upload might fail, you cannot roll back easily, and what about your visitors? Do you want them to see a site that’s half-updated? So in the Rails world we use Capistrano and it works really well. In this case I felt the need to use Vlad the Deployer for this task. It’s Capistrano without all the obesity. And what do you know, it actually works. And it’s fast. Fast is good when deploying.

So now when I am done with my markup haiku, I type svn commit followed by rake vlad:update and just seconds later the updated website is live. And if I make a mistake I can revert back in under a second. Gotta love it.

Ps. I did all this just to maintain a minuscule corporate website. But the fun really was in discovering those new tools.

First thing to do is download a working version of the Ruby 1.9 POP3 library. The most recent version doesn’t work, so you need to grab an older one. This one. Download the file and save it as pop_ssl.rb.

Then you need this code to use it:

require 'pop_ssl' # I renamed the file from pop.rb to pop_ssl.rb to ensure I was requiring the correct version

Net::POP3.enable_ssl(OpenSSL::SSL::VERIFY_NONE)
Net::POP3.start('pop.gmail.com', 995, username, password) do |pop|
if pop.mails.empty?
puts 'No mail.'
else
pop.each_mail do |mail|
p mail.header
end
end
end

Which I grabbed verbatim from the blogpost linked above.

It is becoming a theme on this blog, but you are just going to have to deal with it. Earlier this week I completed a massive refactoring of an application and I am still amazed at how easy that went.

What is a refactoring? From Wikipedia:

Code refactoring is the process of changing a computer program’s internal structure without modifying its external behavior or existing functionality. This is usually done to improve code readability, simplify code structure, change code to adhere to a given programming paradigm, improve maintainability, or improve extensibility.

In other words: change. Usually, changing a live application is a nightmare. Who knows what will break? With for example a PHP site you cannot know this beforehand. And so very often the code is either not changed or a huge problems are introduced.

For radio 1 I completely refactored the Podcasts and Fragments pages and I did it in three days without anything breaking. About a third of the website changed on the inside, but nothing changed on the outside. The Podcast model even changed 90% and the accompanying database table was dropped, in lieu of a Single Table Inheritance model. Each of these things are huge by itself. All pages continued to work and the new things simply got added.

I do not know how I could have do that without an automated test suite. I do not (want to) know how PHP or .Net people do such things. (I fear they often ‘hope for the best’)

So thank you Ruby on Rails and RSpec for making this possible.

Recognize this?

@person ? @person.name : nil

Of course you do. It’s common fare since the days of C. Well, I am here to tell you it’s an ugly construct. Here’s the same thing in “idiomatic Ruby”:

@person.try(:name)

So simple. Thank you, Chris @ Github. :try will be included in Rails 2.3 as well.

I like that it only uses the standard library and that it simply works. No need to install any gem; it works on the largest number of systems out there. I did refactor the consumer class a little bit though, caching a few variables.

require 'soap/wsdlDriver'

def recipient_data(user)
{
:email => user.email,
:voornaam => user.firstname,
:achternaam => user.lastname,
:woonplaats => user.city,
:leeftijd => user.age,
:jongen_meisje => user.gender
}
end
end

vendor/rails/actionpack/lib/action_controller/routing/route.rb:31: [BUG] Bus Error
ruby 1.8.6 (2008-03-03) [universal-darwin9.0]

Purty ain’t it?