How to steal part of a country

Step 1: "Provide support" for members of said part of country who are unhappy with existing Government
Step 2: When Government finally gets angry enough to send in the troops, Rush in to "defend" with overwhelming force. For bonus points, shoot up parts of the country that have nothing to do with the bunch you're defending. High-value targets like airports are good, even if they're on the other side of the country.
Step 3: Give passports to all the members of the part of the country
Step 4: Ignore repeated, desperate requests for ceasefire from stunned, over-powered Government. Shoot a boat or two.
Step 5: Deploy humanitarian aid for all the victims, including large, rather permanent, military hospitals
Step 6: Finally agree that maybe we could have a cease fire. Get really prickly when anyone suggests moving troops out. If you need to justify anything, maintain they're defending previously installed humanitarian assets.
Step 7: Refuse to leave. Rely on the fact that the only people with the weaponry and motivation to do anything about it have already got themselves into a nice quagmire half way across the planet. If necessary, create a "protectorate" status for a few years to maintain some fiction of self-determination.

There you have it, the 7 step plan to territory acquisition with moral pretext bonus.

*Please note, I have no opinion whatsoever on recent world events with a remarkable resemblance to the above, I know absolutely nothing about the area or its politics

Engaged :)

So, yeah, sorry for not posting for a while, i've been busy and to be honest, my life is usually pretty ho-hum.

Not today tho, as of last night, myself and my girl serra are engaged to be married :) :) :) I'm cycling between giddy happiness and panic, but I'm told that's entirely normal, and it's mostly giddy happiness :)

Love you babe :)

Birthday code for Sam

You may need this file

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>---.+++++++++++++++..+++++++++.>++.<<------.>----------------.+++++++++.++.------------.----.---.++++++++++++++++++++++++.>+.>.

The Coolest Things from Ironman

Ok, so, everyone knows the Iron Man movie is great. If you haven't seen it:

1. Don't read any further (spoilers)
2. WHAT THE HELL ARE YOU THINKING? GO RIGHT NOW.

Right, now the legalities are out of the way..

i loved the movie for many reasons, but post-watching, a few things stuck in my mind:

1. Robot arms with fire extinguishers!
2. Being able to fly (totally cool)
3. The Anti-Tank Missile complete with Comedic Timing Device
4. Mini-reactor that glows!
5. I love that house. I love it. I want it. And the windows too.
6. Virtual ex-britas butler with sarcasm module
7. Delicious on-screen graphics

But one of the most relevant things was:

8. A competent PA

I don't have a PA. I'd like one tho. My ability to keep a consistent calendar, or todo list, or anything, is pretty weak. I try, but software has not yet evolved to the point where it can keep me organised. Sadly, I can't afford one, nor can I afford a hilarious robot arm or a house built into a cliff in Malibu. Still, I can dream right?

HORRAY!

I have finally got internet at my new place again. No more slow cellphone connection for meee...*joy*

Caching is stupid

Before you freak out, let me run with this one for a bit, it's based on some very practical experience.

Caching is one of those things we instinctively turn to when we hit some kind of performance bottleneck within a web application - after all, the web is pretty much designed to be cached and has all these lovely headers and things, so it seems to make intuitive sense that if your stuff might get cached out there, you may as well cache it in here.

The problem is that caching actually implies a serious problem, one that we often simply accept without any real thought: the authoritative source of our data is too slow to deliver the information accurately as fast as it is required.

Now, sometimes this is reasonable - if you're delivering an aggregated RSS feed then fine, you need to keep a cached copy of the source data for a while because it would be rude to hammer other peoples servers for every request.

Other times, however, it's actually just bad, and it's mostly the fault of the RDBMS.

We in the web community have become so used to the authoritative-database model of life that we refuse point-blank to delegate authority to any other system. After all, the RDBMS has all kinds of good things like ACID which will ensure your data is always consistent etc etc.

The problem is that data consistency has become this strangely religious holy grail. Never mind that foreign key constraints slow the living crap out of your inserts and updates, never mind the fact that in many cases using an ORM means you'd never have an invalid reference anyway, never mind that many people understand transactions in a database so poorly that they simply ascribe them magical powers of correctness they have no hope of guaranteeing, it's still "database or nothing!"

I remember the first time I got thrown out of that comfort zone. In 2000 I was in Sydney working for a great company called Iguana as their systems/linux guy. We were struggling pretty seriously with the huge load of information we were pulling in from the NZX and ASX and our database server was a monster. Scott Cooper - to this day my example of an brilliant programmer - was the programmer there, and simply did the obvious thing - he wrote a C daemon that stored the data in-memory, with basic checkpointing and methods for doing data catchup etc. As with everything Scott wrote, it was a work of art and brutally fast, leaving the database in the dust, relegated to dealing with historical data at its slow, databasey pace.

Since then I have rarely come across a situation where a database didn't do the job in an acceptable timeframe, but there have been a few. In every case, my initial instinctive solution was to install memcached and "do something with it". In many cases this was fine, but in a few situations it was a serious, serious error. Case in point, the most recent Entrecard release involved getting rid of half the caching we were doing - which was failing to provide accurate results, and generally screwing up - and replacing the data source entirely with an in-memory daemon that acted as the authority.

This daemon was written in python using the Twisted framework - a solution that allowed me to access data without contention issues. Careful coding meant that there were basically no loops at all within the code, preventing any possibility of lockup and providing very consistent timing for individual operations. The database had grown so large (millions of rows) that providing an accurate balance for an individual user took upwards of *3 seconds* per request, and the parallel nature of the balance modifications meant that it wasn't possible to "cache" the result effectively or accurately.

The daemon, however, consistently delivered a perfectly accurate balance in-flight in under 0.001s, dramatically improving our ability to scale The daemon also took over a number of other high-contention operations, including managing the card drops. This allowed us to return to the "glory days" of Entrecard where drops were counted immediately and the balance was always up to date, rather than the sad state of affairs we had recently where drops were processed "some time later" by a batch processing system.

Next time you're having performance problems and you start thinking about caching, queues, batches etc take a second look at your architecture - is your current authoritative data source really the best solution to the problem? perhaps rather than using a cache to wallpaper over your problem, you'd be better off creating a data source that can deliver the data at the rate you really need.

SuperHappyDevHouse

A quick note, assuming I wake up in the morning, I intend to be at the Wellington,NZ SuperHappyDevHouse at Southern Cross (the garden bar) on the 4th of May (today), I'll be doing a bunch of statistical analysis on Entrecard, drop by and say hi if you're around, many people there know me so just ask around if you don't.