Install Ruby using the One Click Installer.
Install the ODBC module (by copying the SO files into the c:\Ruby\1.8\i386-mingw32 folder).
Install the ActiveRecord ODBC adapter (gem install activerecord-odbc-adapter).
Edit C:\Ruby\lib\ruby\gems\1.8\gems\activerecord-odbc-adapter-2.0\ lib\active_record\connection_adapters\odbc_adapter.rb – look for line 1588.
Change the line from elsif dbmsName =~ /SQLAnywhere/i to elsif dbmsName =~ /SQLAnywhere/i or dbmsName =~ /adaptiveserveranywhere/i

Write some test code – something like:


require 'rubygems'
require 'active_record'

Whatever.all

Run this - hopefully you should get no errors.
Then sit down and have a long think about what the hell you are doing.

Before Bigwig, it was Object Factory, before that it was a Delphi class that I used to create tree-structured data (imaginatively called TNode).

Bigwig’s doesn’t have a test suite and it’s not even my code – it was started by David Smalley and has contributions from Caius Durling and the rest of the Brightbox team.

But there’s just something about it – it’s a daemon (start it running and forget about it); it’s been running in production for months without a single glitch; and probably most importantly, the code is so simple that there’s almost nothing to it.

Luckily, this helpful flow-chart helps you decide what to do next.

Gemcutter’s the new kid on the block – it works as a set of plugins to the gem command that mean you can simply go `gem push my.gem` and it becomes available to the world. Nice as this is, gemcutter’s still pretty young and is currently hosted off one guy’s S3 account.

So we went back to good old-fashioned Rubyforge. Except, believe it or not, I’d never published to Rubyforge before. And it wasn’t as straightforward as it could have been.

I was using the echoe library to build my gem – which gave me a simple `rake manifest`, `rake release` workflow. All good. When you `rake release` it asks if you want to publish to rubyforge; you say “yes” and go to bed happy.

Or not in my case.

Firstly, you need to actually configure rubyforge. Install the rubyforge gem, then use `rubyforge setup` to put in your username and password. Then use `rubyforge config` to make them stick.

That done, I `rake release`d. And got a “no group_id configured for mygem” error. Eh? Googling seemed no help whatsoever – it was mentioned in a few places but people seemed to have resolved it without actually posting their solutions (or I was being blind).

What you need to do is tell Rubyforge where to put your gem. In our case we already had a project on Rubyforge that the gem could be attached to – so `rubyforge create_package project_name gem_name` did the trick. Otherwise you need to get a project set up to house your gem.

But it still didn’t work. This time complaining about a processor id. I had no idea what I was looking for this time, until I discovered this pastie by Dr Nic. The autogenerated config file (normally in ~/.rubyforge/auto-config.yml) is missing some vital information – namely codes for different processor architectures. I pasted the list into your config file and then tried the `rake release` again. And this time it worked!

processor_ids:
  IA64: 6000
  AMD-64: 1500
  Any: 8000
  Sparc: 4000
  PPC: 2000
  Other: 9999
  Alpha: 7000
  i386: 1000
  UltraSparc: 5000
  MIPS: 3000

So for the sake of posterity – and anyone else who gets “no group_id configured for mygem” or “no processor_id configured for mygem” messages, I thought I should let you know how I got there.

But it wasn’t shit. It wasn’t good. It was absolutely great.

Things started on the Friday with a free seminar by Tim Nash – all about user profiling. I missed the first half hour (as my bus had to stop and give another bus a jump start – it’s true, honest), so was a bit befuddled as we had to decide on keywords for the other attendees (based upon the introductions they had given whilst I was on the other side of town). But I came away from the session with a list of improvements to make to one of my blogs so it wasn’t a wasted trip.

This was swiftly followed by several pints of Leeds Brewery Pale Ale on an empty stomach, resulting in me failing to buy Al Carlton a drink, but being bought one by Chris Garrett (thank you). I sloped off home before I could get caught up in one of Al’s legendary nights out.

On to Saturday and the conference proper. Despite living in Leeds for years, I’d never really been to Clarence Dock, home to the Alea Casino. I was actually quite impressed – in a “let’s try and look like London” kind of way. Slide into the venue just before ten, pick up my lanyard and creep into the introductory session.

Joost de Valk told us all about optimising Wordpress. Speed is key – cache (using Memcached if possible) and distribute your assets using a Content Delivery Network to reduce those page load times.

Next, Julian Sambles told us about how the Telegraph changed its entire culture to adapt to the digital world. It’s certainly a success story (look at the number of times Gruber links to Telegraph stories; a couple of years ago if he wanted a UK angle it would have been the Guardian) – and Julian emphasised that it was mainly a cultural change, not a technical one. Another interesting fact – their digital division not only generates revenue but actually makes a profit (unlike, if you believe the rumours, the print division).

And on to my highlight. I had the pleasure of meeting Judith Lewis in the pub the night before and she was absolutely charming. But her talk was even better. She told us about how Google’s embedding search results for other media types within the standard search results page has changed the game (images, videos and news results pushing other, textual results, further down the list and often off the first page completely). Meaning you should work at getting into the video results, the image results and the news results. But the best bits were when she stepped away from the mic and told us about the “dark arts” of search. Which, of course, I could never repeat here. She then ended her talk with a lolcat.

Leading us to the lunchtime panel. There were a few complaints about the food. Personally I wasn’t bothered. I was very hungry, grabbed a few ropey sandwiches and had a couple of lovely cookies. No complaints from me; especially for less than £100. But, by the sounds of it, some people missed out because of the queues, which would be annoying. While we were eating, there was the lunchtime panel – Al Carlton, Chris Garrett, Kieron Donoghue and Patrick Altoft Dominic Hodgson taking questions via Twitter. There was also a side-competition – how many times will Kieron mention Share My Playlists? Of course, yours truly got a big laugh and round of applause for my question.

On to the afternoon sessions – where the venue was split into three. First up was Paul Robinson, who I vaguely knew from Geekups and my day job. He was explaining how the likes of Amazon and Last.fm’s recommendation engines work – and how by matching similarities between different user data and behaviour, you can add intelligence to your site. Interesting stuff.

Next up was Chris Clarkson telling us the story behind Holiday Watchdog – an affiliate site he and a friend founded in 2003 and sold in 2007. The main thing to take away from his talk was that being a limited company may protect you from company liabilities – but it doesn’t save you from being sued for defamation.

Then was Zoe Piper talking about Google Adwords. There was a lot of interesting stuff here, but unfortunately, I didn’t hear parts of it. Because the main room had been split into three, the speakers could not use the microphones – and Zoe had a quiet voice, meaning I missed big chunks of her talk. This is my only complaint of the day – it’s not Zoe’s fault – just an artefact of the room arrangement.

And finally Artur Ortega gave a talk on how disabilities have fueled innovation in the technology industry. Basically every piece of technology, that we take for granted, in our offices has a history of helping overcome disabilities; from keyboards to scanners (and mostly designed by Bell Labs, as Alexander Graham Bell’s wife was deaf and so he was motivated to solve the problems that triggered).

As I said up-front, this was a great day and a half. I learnt a lot, got to meet some great people and am once again reminded how much there is in the “web industry” that I know nothing about. It has certainly changed the way I approach my next venture.

The next Think Visibility will be in March. You better make sure that you attend.

I have no idea who he is or why he’s gone. But _why meant a lot to Ruby developers, myself included. He represented style and grace and art and weirdness – that Ruby was about more than just getting the job done in the most efficient way possible.

He had a class, descending from ActiveRecord::Base, with a custom constructor (initialize method). To debug it, he had the constructor raise an exception. In the console, Thingy.new(params) raised the exception as expected. But wotsit.thingies.find_by_field(value) did not. Even though it was instantiating an instance of Thingy and returning it.

“It must not be calling the constructor” he said.
“Rubbish” said I, “it’s a constructor. Constructors are always called. That’s the point of them”.

But as he dug deeper it certainly looked like the constructor wasn’t being called.

And then he found an article explaining that you should never rely on things being set up on in an Active Record constructor. Mainly because Active Record uses allocate to instantiate associated objects. And what is this mysterious allocate? Why explains it all.

To be honest, I’ve got mixed feelings about this. I can see the use of “allocate” – why’s example of marshalling an object makes sense (I’m slightly less sure about the way that Active Record uses it to load associations). But, to my mind, the definition of a constructor is “the code that is always called when an object is created”. So maybe I should just stop thinking of initialize as a constructor and more as an initialiser.

Suppose you’ve been working in branch X and you’re about to merge those changes into branch Y …

• work in branch X and make your commits as needed
• switch to branch Y git checkout Y
• compare the differences between X and Y git log Y..X – the order here is important; it is merge-target..merge-source
• merge the changes from X (merge-source) into Y (merge-target) git merge X

Even better, before doing the merge, while you are still in branch X, you can squash multiple commits into a single one. This way, branch Y, when you examine the log, has a single entry “implemented feature X”, instead of thirty-five entries all related to feature X in some way.

• examine the log git log or even better git log --pretty=oneline
• choose the commit that immediately precedes the one that starts your piece of work (probably the last one before you branched to start work on feature X)
• start an interactive rebase session – this is git-fancy-talk for picking some commits and typing a message – git rebase -i THE-COMMIT-ID-OF-THE-COMMIT-YOU-SELECTED-ABOVE
• Your favourite editor (or nano) will open listing the commits for feature X – edit the word “pick” to “squash” for all except the top entry, save and exit
• Your favourite editor will open again – again showing your commit messages – add a line at the top stating something like “implementation of feature X” and leave the list of individual commits on separate lines below it (adding in a Fixes #123 or whatever your issue tracker demands as the last line), save and exit
• Now if you do a git log you will see a single commit with a nice “implementation of feature X” log message
• And you’re all set to merge to your master branch without cluttering its history with a long string of commit messages

All the tests passed. Poking it on the staging server worked well. On to production and all was good.

Time passed.

Then, the app needed to be moved to a new server. Actually to a cluster. Slightly more nerve-wracking, but some playing around with the ghost gem and DNS settings and the deployment completed.

More time passed.

And then disaster struck. Well, not disaster, but it wasn’t good. Not at all.

The app had a rake task that was cronned to run every night. And it failed silently. We found out the day after and I scanned the production log file looking for evidence of what went wrong. Nowt. It didn’t even look like the rake task had run – but it had, as I had the data in front of me.

And the day after, it failed again. Another scan of the production log revealed nothing. Things were getting serious.

I suspected the cluster deployment. Maybe cron didn’t have permission to write to the log file, even though Passenger did. But everything looked good on that front. Maybe there was something else weird about the cluster setup – all the cron jobs were set to run on one of the app-servers; maybe moving it would make a difference?

To test this, I opened the Rails console and started manually recreating what the rake task was doing, on a different app-server. Which is when I noticed that script/console wasn’t writing to the production log either. What?

After a couple of hours of head scratching, I finally found out that the cluster deployment was not at fault. In fact, it seems to be the move to Rails 2.2 that had happened many weeks before – in particular it appears that the logger object no longer auto-flushes itself after writing.

We added a quick Rails.logger.auto_flushing = 1 to an initialiser and both script/console and the rake tasks wrote to the log as expected. Phew!

I seem to have nailed it down to two problems.

Firstly, monit only seems to like monitoring ferret server under certain circumstances.

Secondly, the ferret indexes don’t seem to like being rebuilt.

The first one is weird … my monit config looks like this:

check process ferret with pidfile /home/rails/myapp/current/log/ferret.pid
  start program = "/home/rails/myapp/current/script/ferret_server -e production start"
  as uid rails and gid rails
  stop program  = "/home/rails/myapp/current/script/ferret_server -e production stop"
  as uid rails and gid rails
  group ferret
  if failed port 9010 type TCP then restart
  if 5 restarts within 5 cycles then timeout

But monit often says “not monitored”. And completely fails to restart the server if it does go down.

No solution to that as yet.

The second problem is even weirder.

If I stop the server, then rebuild the indexes (I have a custom rake task that rebuilds all the indexes for my app) and restart, every search crashes ferret.

If I rebuild the indexes while the server is running, it appears to run fine. Why? I have absolutely no idea.