paulcarey

You could consider ‘partitioning’ your DB when you migrate your schema so each DB instance only deals with a single bitemporal slice eg after 5 migrations you have 5 distinct database instances. This approach avoids bloat assuming the vast majority of queries would be served by the most recent instance, while not precluding serving verbatim responses from earlier instances.

This is interesting, but I think there's an implicit assumption here that a particular topic must be covered in depth, at which point its study is completed, not to be returned to.

And indeed, this is way many textbooks are structured. But I see no reason for this to be the case. If topics are covered lightly via an exposition and then subsequently drilled into in depth, the order, and resulting motivation becomes almost a side note.

I say this as I'm currently studying linear algebra via Coursera, and the resource that has become most valuable to me is a Scapple board with a bunch of screenshots, text and arrows. It is this (non-linear) diagram that I return to most often to help internalize and solidify my learning.

In this regard, the order of exposition becomes almost incidental.

A few years ago, I recall being impressed at the clealiness of the toilets in Edinburgh train station. An attendant was diligently wiping each urinal with a cloth, and also used the same cloth to wipe the Dyson hand dryer.

I’m sure it’s not a common practice, but I’ve avoided them ever since.

If you didn't already know that Ruby scripts can be written in a very similar way to awk, this makes for a good read.

http://tomayko.com/writings/awkward-ruby

Dev tank is on Monday, if you ask nicely you might be able to skip the waiting list http://www.meetup.com/DevTank/calendar/15487391/

If you're still around on Thu 9th, you could check out OpenCoffee http://www.meetup.com/londonocc/calendar/clgdnynqbmb/

I think you've already done the most important thing you could by creating a separate room that delineates home life from office life.

The biggest distraction I've found while working with a remote team is dealing with IM. In practice I've found this can be more distracting than low level banter in the office - you can tune out to this, and it's always obvious if a message is directed at you. Not so with group IM, where unread messages may or may not be directed at you. In short, and assuming your colleagues are happy with it, I recommend going 'Do not disturb' for a few hours every day while you focus on work without distraction.

When I was employed as a developer, I was quite obsessive about refactoring my code to the point where I considered it elegant.

Now I run my own company and am the sole developer. So these days I tend to think if my code is well factored, I'm doing it wrong.

It's not quite that simple of course. The lower down the stack a chunk of code lies - the more things that depend it - the more I want it well factored and well tested. But I'm quite comfortable with code high up the stack being scrappy, hacky and untested.

I like the speed and simplicity, but without the ability to import contacts, I'm going to treat it more like a toy than a tool.

A contrasting approach - when Mo Ibrahim set up a mobile network in African counties he knew a no-bribe approach wouldn't fly, so bribes were limited $30,000.

http://www.guardian.co.uk/lifeandstyle/2009/feb/01/mo-ibrahi...