Exploding contracts == dilemma

Two weeks ago I was bemoaning the fact that my cash flow was in the red and my savings were running away in a torrent. I was then approached by a friend for a contract. Shortly after my interview with them I had four other clients approach me. So suddenly I'm flooded with offers!

One of the other clients was a good friend of mine as well. So I had a real dilemma on my hands. I didn't want to disappoint either one.

The first contract came first - but they hesitated on giving me a "Yes definitely" answer until after I'd started to look at the second one. I felt I had to look at each of them in good faith.

The first contract offered sexy video on the web, the second a really big name financial company

The first contract offerred a relaxed, sociable startup feel with some onsite some offsite. The second offered relaxed, sociable academic feel, onsite-only, but I'd have the chance to teach the rest of the team Rails skills.

It was pretty much neck-and-neck. It was a tough decision, from the perspective of preserving friendships. But when I weighed all the pros and cons objectively, the business decision became clear. In the end, for me, it came down to the fact that the first contract could only offer three days a week, while the second offered full-time.

I start on Tuesday.

Presenting Rails

Ok, so this post was going to be how I gave an absolutely rocking presentation on Rails to my local LUG group (SLUG).

Unfortunately, I was giving the second talk and the first one began late and then ran way over-time. So my talk was pre-empted. The SLUG team were really nice about it (they even bought me dinner), and I'll be running it next month instead.

I certainly can't fault them - the first talk was on the cool OLPC project. I was interested in listening myself. Besides which, an extra month will give me more time to polish the talk and prepare that demo I'd meant to organise...

Anyway, I did want to mention a really cool talk I stumbled over while researching other Introductory Rails talks. Jim Weirich gave this talk and has a lot of reference material available here, but what I wanted to point out the neat slide software he used.

It's called "The Takahashi method" and is a XUL file that runs in your browser. It lets you write simple and effective slides with an image or a few words on each. These give great impact to what you're trying to say.

The data file for the slides is simple plain-text markup, so it's ultra-quick to write up your slides from your presentation notes.

Here is a link to Jim's slides and data. See how punchy that is.

Anyway, that's what I would have used... if I had the chance ;)

Coding through treacle

Coding while sick is like trying to walk through fairy-floss

I once tried to explain to my aunt (a respected Dietitian) about how you need your whole brain firing on overdrive to write truly awesome code... it was difficult to explain clearly and I didn't pull it off successfully. Apparently I left her with the feeling of "and you don't think I use my brain in my work?" which was *so* not the point I was trying to make.

In my experience, most jobs (ie non knowledge-work jobs) have an element of drudgery. Tasks that you can do with only half your brain involved. You might not be able to do them while sitting in front of the tv - or while chatting with a friend... but you can do them when you're feeling less than 100%.

Coding isn't like that. Neither are things like mathematics, theoretical physics and creative writing.

At least 95% of the tasks you do require full attention. It's not like you suddenly forget how to code (or write, or whatever), it's just that if you do that work when you're not "all there"... it'll be far more buggy and inelegant. You might be able to salvage most of it, maybe with only a bit of re-writing, but if you're seriously out of it, you'll have to re-write so much of it that you might as well write it from scratch... ie you'd be better off having not written it at all.

The last week and a half has been like that for me. I've been trying to see through a near-impenetrable fug of virus-induced head-cold.

I've watched a lot of television. I've made significant in-roads into my post-easter chocolate collection. I even began a new knitting project... but I haven't coded much.

I even had trouble concentrating enough to get through my email. When you find yourself blankly staring at the screen, and realise that you've been sitting there, doped out for ten minutes doing nothing... you know there's no point firing up the text-editor.

Still, the fog has begun to clear over the last few days, so I'm slowly picking up where I left off. Which is lucky as I'm helping a friend out - he's sub-contracted a few basic rails tasks to me on his current project. Hopefully I'll be back in full-gear next week as I have a contract-interview and a talk on Rails for my local LUG.

Plugins and engines and gems, oh my!

So I was talking to friend of mine about what I was doing and how a gem was too heavy for what I wanted. He pointed out that I should consider doing it as an engine instead of a plugin.

What's the difference between a plugin and an engine you ask?

I didn't know either... engines seem to be the forgotten children of Rails in all the current plugin-love that's going around (not knocking it - I like plugins too).

Anyway, it turns out that an engine is a plugin - with some differences. An engine requires that you install the "engines" plugin first - you can't just script/install the plugin itself. However, adding that engines plugin allows your own baby to do a hell of a lot more than your standard plugin-ly functions.

An engine is a complete, vertical slice of MVC. An ordinary plugin, by comparison, is generally a small chunk of functionality such as a helper library. Engines can have an /app/ directory structure identical to a full rails site. You can also add routes and migrations (with some user-tweaking required). This allows a fully encapsulated chunk of functionality (such as what I was proposing for my little blog).

Now, mephisto and typo are both gems. This is because they contain a huge amount of functionality (they well deserve their leading status in the Rails-blog field). They contain more functionality than what most people associate with a simple plugin... more than what people would associate with an engine (if people used engines more commonly) - so they are distributed as gems.

So, to sum up:

• plugins are for small bundles of helpful code
• engines are for encapsulated slices of vertical functionality and
• gems are for complex, multi-functional systems.

So how do I make an engine?

The information on how to make an engine is a bit scattered about the web. There doesn't seem to be a whole lot out there in the way of tutorials (at least not compared to plugins).

Some of the info seems to be downright incorrect. The article that looked most promising was: the alterthoughts one, but it seems to be based on an old version of engine-construction that Just Doesn't Work. I couldn't get script/generate engine my_blog to give me anything but "can't find a generator for engine". This article is clearly built on an earlier version of both Rails and engines

The railsdoc on engines is fairly complete (though it's not a step-by-step tutorial). It turns out that you can just start out with a rails app - and turn it into an engine. Two things to remember:

Routes

Copy your engine's routes.rb into the root directory. Then instruct your users to add map.from_plugin :your_plugin into their routes.rb.

Migrations

If you have migrations, make sure they are numbered from 001. Then leave instructions for your user to run script/generate plugin_migration, then rake db:migrate.

Shared plugins

A blog needs to share the authentication plugin. But which authentication mechanism are you using? I could assume you're using the same as me (RESTful auth right?) but that's not likely. The best option is to write a wrapper library that allows people to override the functions with their own authentication system, if they choose.

Other plugins

If your plugin depends on other plugins there may be some duplication. I'm sure there must be a way that minimises double-loading of plugins eg if your plugin uses acts_as_taggable, and so does their site - maybe your install.rb could check for that and not bother installing it - but I think that may be over-optimisation.

I'm sure there must be a way to put all these tasks into "install.rb" - but I haven't had a chance to do that yet.

So, what have you done?

So I wrote a very tiny blog app (currently all is does are posts). It was enough to demonstrate the point for me while I figure out how to do the engine thing. I'm still playing with it in my spare time - but I probably won't get in installed until after the Easter long-weekend. At that point I'll also find somewhere to upload it so people can have a play with it.