I added the Logging gem to a project I’m working on, and so far I like it a lot. It is modelled after log4j and, as such, allows you to send logs to syslog (our main usage for it).

One issue that I’ve run into with using syslog(-ng) as a Rails logger is that Rails tends to spit out multi-line log events. Unless you have a very new version of syslog-ng, this may cause syslog to interpret each new line as a new event. Unfortunately subsequent lines get written with a blank program identification, which can cause filtering rules in syslog-ng to break.

My solution to this was to monkeypatch the Logging::LogEvent with an Around Alias. This causes the data accessor to return a string with the newlines substituted with a different delimiter, << in this case. I added the Around Alias to the end of the config/logging.rb file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# Other config here...

# This is a hack to remove new lines from our log data
module Logging
  class LogEvent

    def data_with_stripped_newlines
      self.data_without_stripped_newlines.gsub("\n", " >> ")
    end

    alias_method_chain :data, :stripped_newlines

  end
end

So far it’s working quite nicely. Any better ways of doing it? Let me know!

Those of you living in a cave may not have heard that someone recently hacked GitHub to prove a point about default Rails mass-assignment settings. You can read all the gory details here and here.

At any rate, GitHub sent an email notifying everyone that they are performing an SSH key audit, and included a link to the audit page.

The page shows the SSH key’s fingerprint, but neglects to explain what it is or how to check the fingerprint on your own system. Here’s what you need to do:

• Locate your public SSH key, it’s likely at ~/.ssh/id_rsa.pub
• Run this command (or similar, depending on your system) to get the key fingerprint, replacing id_rsa.pub with the location of your public key:

1

 ssh-keygen -lf id_rsa.pub

• If the printed key fingerprint matches the fingerprint on GitHub, you’re good! If not… follow their instructions and hope for the best :-P.

So Jo and I moved to Toronto at the beginning of December, and things are going swimmingly. I’m still working for Spindance, but now from the comfort of our home study.

Once things settled down a little, I got to work revamping davidvg.com. Astute readers might note that I did the same thing last year, moving from 60cycleCMS to Typo, and ask why I’m changing it up again.

One of the bigger problems was trying to host a full-blown Rails site on Dreamhost. I like Dreamhost for the most part, but they’re really not set up for Rails sites. I sporadically had random application crashes, and the site was really slow at times. Installing the right gems was downright painful, although I imagine using Bundler would mitigate that considerably (I haven’t actually tried it). What I really wanted to do was move davidvg.com to Heroku. I had previously moved pvanreenen.com there (as well as porting it from PHP to Sinatra), and it was a very pleasent experience.

Typo is good, but it was really starting to bug me. It’s weighed down by a lot of legacy code (although they’re working on that), and I kept finding bugs that seemed to be un-squashable because of the huge and complex codebase. There were some missing or non-functional features too, like decent syntax highlighting and a comments system that played well with others. That said, I was using an older version, and I’m sure the newer versions are a lot better, but the thought of trying to upgrade Typo and merge my changes was making me ill.

A little bit of Googling revealed Octopress. It’s a static site generator based on Jekyll that uses a lot of my favourite tools, like Ruby and Sinatra. It had all the features I wanted, it was dead-easy to use, and it’s a great fit for Heroku. I was hooked pretty quickly.

So, welcome to the new Heroku-hosted, Octopress-baked version of davidvg.com. Do let me know if you see any rough edges!