Recently I was trying to optimize my code a little and needed a quick way to compare the speed of different code snippets. Of course Rails comes with the Benchmark module for doing just that. It is, however, in my opinion a bit clunky for quick tests. Look at all the typing it takes just to find the average speed of a snippet over 100 iterations:

Benchmark.bm do |x|
  x.report do
    100.times do
      (1...1000).to_a.sum
    end
  end
end

So I tossed this into my ~/.irbrc file:

class Integer
  def ti(&block)
    Benchmark.bm do |x|
      x.report do
        self.times do
          yield
        end
      end
    end
  end
end

And now I can “time it” like this:

>> 100.ti {(1...1000).to_a.sum}
      user     system      total        real
  0.540000   0.050000   0.590000 (  0.597664)
=> true

Much nicer!

We’re in the process of converting our website to Radiant CMS, and one of the new things on the site is a “Blog Blurbs” section at the bottom of every page that lists our latest blog post. Our blog is in Wordpress, so I setup the RSS Reader extension in Radiant to fetch the posts. Everything worked great, except that page loading was noticeably slower. After the page gets cached everything is fine but this is included on every page so going through the site when there were not cached pages was really frustrating. I thought about modifying the RSS Reader extension to cache our blog blurbs, but I figured a more general approach would work better, so I came up with a fragment caching extension. We’re using it like this:

<r:cache name="rss_fragment" time="60">
  <r:feed:items url="[feed_url]" limit="1">
    <h3><r:feed:link /></h3>
    <p><r:feed:content max_length="300" no_html="true" /></p>
  </r:feed:items>
</r:cache>

The code is at github.

Over the past many years I have been involved in projects requiring localization into many different languages. One issue with this is how data is stored in the database.

As we support and help various customers with Postgresql related database issues, we still find users who are encoding their databases in SQL_ASCII. Perhaps there is a reason for this, if there is I haven’t figured it out yet.

In many cases, this eventually causes them problems and they end up having to switch from SQL_ASCII or some other encoding over to UTF8.

There may be more, but I know of two different ways of converting the encoding of the database to UTF8.

One way is

iconv -f iso-8859-1 -t utf-8 dump_file dump_file_recoded

The preferred way however is to use the -E option of the pg_dump command like this:

pg_dump -U postgres -W -E UTF8 -d pg_bench >pgbench.backup.

the -W command forces you to put in a password.

For more details on how to use the pg_dump command, here are the docs:

http://www.postgresql.org/docs/8.3/interactive/app-pg_dump.html