You Win the Internetz!

January 25, 2015 23:51 +0000  |  Auckland, Australia, Austria, Greece, New Zealand, Personal Life, Ripe NCC, Sydney, Travel, Vancouver  |  1

If there's any tradition that I try to keep on this blog, it's this annual post, the one that recaps the previous year and tries to sound optimistic about the future. I try to be thorough enough that someone might easily get a beat on what my life's been like simply by reading one post a year for the last 11 years. Of course, I've not been as disciplined as I might have liked on this front. I don't have anywhere near 11 "year in review" posts.

Looking back on some of those posts though, I realise that it must have been easy to write them: my life was either in transition, or just moving into or out of one. 2014 by comparison hasn't been particularly remarkable -- at least in the sense that one might be able to point to it as a time in my life that something was happening.

Mostly, 2014 was a year of being comfortable in my life here in Amsterdam. In much the same theme as the my life and theirs post from way back, 2014 has seen me get comfortable with the idea that I'm here for the long-term.

Christina and I are the real deal, with three years together as of February. We share a lovely place in Amsterdam with a beautiful view of the Ij and life here is pretty good. Work hasn't changed much either, but I'm comfortable in my role at RIPE and I enjoy working for a company that actually does Good for the world.

My life hasn't changed much at all this past year, but I still can report that my life is going well. I'll try to recap some of the highlights here.

Travel

As with every year since my moving to the Netherlands, 2014 had a lot of Travelling in it. Not as much as last year, but I did manage to seem some amazing places.

FOSDEM

As is becoming tradition, Christina and I took the trip down to Brussels for the annual FOSDEM conference. There's not much to report on this other than that FOSDEM is amazing and probably the best conference I've ever been to. If you've never been, you should go.

Vienna

Christina had a conference in Vienna in the Spring, and she took me with her so I could meet her friends Max & Julia who promised to give us a tour of the city. Vienna is lovely, and strangely grandiose, as if to give one the impression that The Empire was still alive and kicking. Wide open spaces surrounded by tall marble buildings, imposing in the shadow they cast on passers by -- it's not like any other city I've been to.

But the hotdog I had there, OMG. The best thing I've ever had from a street vendor. I ate something called a Bosna and every time someone mentions Vienna, I salivate.

Seriously, I'd consider a trip back just for that sausage if I could justify the environmental implications and financial costs.

Vienna from our hotel

Marseilles, Lyon, & The French Riviera

The other conference I attended in 2014 was DjangoCon Europe which, in 2013, was held in Warsaw, but this year they decided to host a 3 day conference on a tiny island off the south coast of France. I took the opportunity to do some sightseeing around Southern France and find myself surprisingly disappointed with Marseilles. Lyon on the other hand is beautiful and impressively both managed and designed. Photos from my trip can be found in my image gallery.

Lyon

Manchester & Couch

Some of you may not know this, but Christina may have been born in Greece, but her mother is British, and the other half of her family lives in a sleepy little town called Chesterfield, or Couch as I lovingly refer to it.

Chesterfield is an out-of-the-way hamlet without an airport in the North of England. When I asked people what I should see/do there, locals would always say: "Have you seen the crooked spire?" When I replied with "Yes, anything else?" I was met with silence. Yes, Chesterfield is that boring.

I did get to meet Christina's other side though, so that made the trip worth it.

Thessaloniki, Athens & Nafplio

Amazing Graffiti in Thessaloniki

Christina had another conference in Thessaloniki (Θεσσαλονίκη), so we decided to take a couple weeks and see some more of Greece. This was my third trip to Greece, but my first time leaving Athens to see other parts of the mainland.

Thessaloniki is a town with a lot of promise, but the Euro crisis has taken its toll. Some (touristy) areas are well maintained and busy, but there were whole blocks with nothing but abandoned or condemned buildings. Some amazing graffiti though. I wish the graffiti artists in the Netherlands had half as much talent.

We stopped off in Athens for a week or so to spend some time with Christina's family, and then headed off to the Peloponnese (Πελοπόννησος). Christina drove us from Athens to Nafplio (Ναύπλιο) via Corinth (Κόρινθος), and we stayed at a beautiful hotel nestled on a hill surrounded by an orange orchard. We did a little touring in Nafplio (and lots of frozen yogurt), and also took a trip up to the ruins of Mycenae (Μυκήνες) where I was attacked by giant bugs and had a mild panic attack (good times).

Vancouver & Kelowna

Thanks to an um... lets go with scheduling conflict with my dear friend Jeong-Yeon, I ended up in Vancouver this summer, burning most of my vacation days and Jeong-Yeon was nowhere to be found.

Thankfully, I have lots of friends and family there, so it was hardly a waste of a trip. I spent some time visiting in Vancouver, and then headed up to Kelowna to help out around my parent's house and play with my adorable niece.

Photos are here for those interested.

Sydney, Auckland, and much of New Zealand

The Big Trip of the year, possibly the biggest for a long time, was my trip to the country I swore I'd never set foot in, (Australia) and a further adventure into New Zealand.

My travelling partner for this one was the ever-ready-for-adventure Stephanie, who had this whole idea in the first place. We did a few days in Sydney, where I was confronted with a GIANT FUCKING ARACHNID in our hotel room and was thoroughly terrified of the wildlife for the remainder of the trip.

We did yoga on Bondi Beach. I cannot begin to confer how beautiful Bondi was. I am forever indebted to Stephanie for convincing me to face my fear and visit such a beautiful place.

I got to pet a wombat, and a kangaroo, and an echidna, and a koala named Claire. I saw penguins, and a tasmanian devil, and a cacophony of crazy looking exotic animals that weren't trying to kill me, and then I ate a kangaroo burger. Stephanie drank All The Beers, and I watched her consume what would appear to be the finest beverage in the world... something called a rum old fashioned.

And that was just Australia.

Bondi Beach

We met Sue in Auckland, who was a welcome travelling companion for a few days. She drove us from Auckland to Hobbiton where we saw hobbit houses and drank at The Green Dragon, then onto the Waitomo glow worm caves, where we went cave diving with wet suits and inner tubes. Once again, Stephanie convinced me to do something I never would have considered and I am once again thankful for it. Imagine yourself floating in darkness with billions on tiny blue lights overhead surrounded by cave walls and cool water. It was amazing.

Hobbiton

From there we headed to Rotorua, where we visited Te Puia, a Maori cultural centre, before heading back to Auckland and getting my picture next to the Xena Way sign. That was way more fun than it should have been.

We left Sue the next morning for the third and final leg of our trip: the South Island. In Queenstown I rode a horse for the first time in my life and was less terrified than I thought I'd be. I also got some really amazing pictures. We also took the long trip to see Doubtful Sound, an untouched wilderness of trees, water and wildlife, it was also the furthest South either of us had ever been. Indeed, it's the furthest South most people, alive or dead, have ever been.

The horseback trail

We rented a car in Queenstown and Stephanie drove us on the left up to Lake Tekapo where we hiked to the top of Mt. John (less impressive than it sounds, but still lovely), and we took advantage of the night sky reserve one night to see the Southern Cross and explore the night sky as we'd never seen before.

Stephanie with her Firefox ears, on Lake TekapoThe night sky in Tekapo

From Tekapo, Stephanie drove us up to Mt. Cook, only to be turned around by the weather. It would seem that we wouldn't get to see a glacier on this trip. Instead, we drove East to the outskirts of Christchurch, where there was no cell service and barely any people, so we could crash at a cool little place called SiloStay which, as it turns out, wasn't really all that awesome, so I'm not linking to them here. We did however have a quick dinner at a place called Hilltop Tavern, which had prettiest view I've ever seen from any tavern.

The next morning we drove to Christchurch to see what was left of the city after the massive 2011 earthquake. To say that the town was heavily hit is a colossal understatement, and I'm not convinced that they'll ever recover entirely. Three years later, and there are still houses and buildings everywhere that are just half-destroyed and abandoned. However it was nice to see how some were taking advantage of the opportunity to rebuild the city in a way that makes sense (more pedestrian space, better cycling infrastructure etc.). We visited the earthquake museum, learnt about the colourful use of the term munted by officials during the crisis, and then crashed at our guesthouse before getting on our respective planes the next morning.

It's was an amazing trip. It cost me thousands of Euros, sixty hours of air travel, and twelve timezones of jetlag, and I regret nothing.

Photos from all of this, save for a good many lost from my Bondi Beach trip, are available here.

Professional

Professionally, my life hasn't really changed this past year. The RIPE NCC is still a pretty good place to work, if for no other reason than that working there means that I don't go home feeling guilty every night. Instead, strangers thank me publicly for the work I do and my code is Free to share. It's pretty fabulous.

Projects

I did a lot of work this past year on a whole whack of mini projects. Now that I'm finally understanding and using git, a tool written by people who show very little interest in making tools other people can use, I'm now hosting a lot of nifty stuff on GitHub, including my ever-present side project, that mobile game Stephanie and I have been poking at over the years...

Spirithunter

I got a lot of work done on this in 2014. In fact, I had a working alpha back in September, achieving my end-of-year goal months early. I managed this in part by finally saying goodbye to doing bits of work for Collin, and in part by getting some vitimin D into me. I got more work done on this project in 1 week in Athens than I did for most of the rest of the year.

The big challenge for 2015 is going to be:

  • Moving away from django-tastypie because it's effectively abandonware
  • Switching to 1.7
  • Getting some front-end working (coughStephaniecough)
  • Getting some artists to sign on to provide some character artwork

That last one is especially tough, because let's be honest, nobody likes to work for free, so I might just have to dip into my savings and pay for some artwork up-front. I dunno.

RxLenses.ca

I also started doing a lot of work for my father's side-project, RxLenses.ca, an uncut lens reseller for retail optical stores. In the last months of the year especially, I've been working on getting a big feature setup, and once that's finished, the project should be mostly self-sustaining, so I can go back to my other stuff.

Sagan

Sagan was my first "public" component for the RIPE NCC. It was fun to write, and it's been largely embraced by both the company and the community when it comes to do doing the stuff it was designed to do, which is honestly the best any Free software can ever hope for. That's pretty awesome.

Wrap Up

So, this is a lot of stuff to read, so I hope that if you actually read it all, you aren't bored by now. 2014 was good to me, albeit rather static. 2015 is looking good though: I've got a lot of travel planned, some more side projects, and maybe even dance classes. I guess we'll see how that all pans out in about twelve months.

December 06, 2014 13:30 +0000  |  Family, Food, Grandma Lidia  |  1  | 

This is my second attempt at documenting my Grandmother's so-called "sour-soup" or "chorba" as is apparently the appropriate word for it. I've been trying to replicate it for years, but recently, she and I sat down and worked everything out (while i video recorded everything) and I've finally managed to reproduce this amazing dish. I present it now for you in the hopes that it will brighten your day too:

Note: my grandmother isn't big on measuring, so I'm afraid I don't have much to offer in the standardised quantities department. Instead, I'll be listing the ingredients in the very same way she provided them to me: in practical use cases.

Ingredients

  • Some meat.
    • Turkey is good for this, but you can get away with chicken or even beef (big chunks, not ground). Ask yourself how much you want in your soup, and that's how much you'll need.
  • 4 Parsnips
  • 4 Carrots
  • 1 Bunch of celery
  • 1 White onion
  • 1 Red pepper
  • Olive Oil
  • A handful or two of some kind of pasta or rice.
    • I typically go for orzo or white rice, but you can also use angel hair pasta.
  • A handful of Lovage
  • A handful of parsley
  • Some sour cream
  • Salt
  • Pepper (fresh ground black pepper, none of that powdered stuff)
  • A big spoonful of vinegar (for the garnish step, below)

Directions

This is a two-part system, and it's probably best if you do things one at a time. Pros like my grandmother who have been doing this for 50 years can do things in parallel, but if this is your first or second time trying this out, pace yourself and do one pot at a time.

Preparation

In this two-part system we have vegetables we're going to eat, and vegetables we're using for flavour only, so we're going to break up our veggies into two groups:

A Warning

Throughout this whole process, it's important to note that the pot should always be covered, or you'll lose too much water and you'll end up with a more stew-like soup than you probably want.

Group 1: Flavour Only

In this group you have:

  • 2 Parsnips
  • 2 Carrots
  • 2 or 3 stalks of celery
  • 1 White onion

You chop these into big pieces, no less than 7cm long. For the onion, you just cut it in half. Leave these bits on the cutter board 'cause you'll need them soon.

Group 2: For Eating

In this group you have:

  • 2 Parsnips
  • 2 Carrots
  • 2 stalks of celery (if you're into eating celery in your soup)
  • ½ Red pepper
    • I usually just throw out the other half, but you can use the whole thing if you really like red peppers.

These are all chopped into bit-sized chunks. Put the chopped bits into a great big bowl for now.

Cook That Meat

You need to quickly cook the meat to seal in the good stuff, and you also want to clean the ugly bits out of your soup before you actually start making broth so...

  • Put your big chunks of meat into a proper soup pot. You probably want something capable of about 6L or more of water. Don't worry about the size of the meat pieces yet, we'll make them mouth-friendly later.
  • Fill up said pot with water until the water just covers the meat.
  • Add some salt and pepper.
    • Don't be stingy with the salt. If you skimp out on salt early, you'll have very exciting-looking water masquerading as soup.
  • Cover the pot and crank the heat up to 10, stirring occasionally so the meat doesn't cook all on one side. When the water boils, drop the heat down to 5. If any gunk floats to the surface (this is excess fat and other undesirable bits) scoop it off with a strainer or slotted spoon.

Completing the Stock

  • Now that you've got the beginnings of your stock, add your "flavour only" vegetables. Let them hang out in the water there with the meat for a bit. Drop the heat down to 3 or 4 and let things slow-boil.

Vegetables for Eating

Now with the stock pot simmering on the side, we're going to work on the veggies we intend to eat.

  • Dump all of your for-eating veggies into a deep pan or pot. Make sure that there's room to stir stuff around because you're going to be doing a lot of that.
  • Add some olive oil. How much? Enough to sauté the veggies. Typically I start out with a little bit and add until I feel that all of the veggies are getting enough love.
  • Run the heat up to 5 or 6 and stir frequently to make sure that all of your veggies get cooked properly.

Bite-Sized Meat

Going back to your stock pot, it should have been simmering there for a good 10-20 minutes. It's time to remove everything that doesn't belong.

  • Open the pot and remove all of the vegetables. You might want to keep them around to eat separately, but they don't belong in your soup anymore.
  • Now remove the meat and place it on a cutting board.
  • Put the lid back on if you haven't already.
  • Chop up that meat (careful, it's hot) into edible bits. Go ahead and sample some if you like, but my experience has been that the meat by itself at this point isn't very tasty. All the good stuff is back in the soup. At this stage, the meat is mostly for texture.
  • Dump your chopped meat back into the stock pot
  • Dump all of your newly sautéed vegetables (along with any remaining olive oil) into the stock pot

You're almost done.

Starch

At this point, you've got a pretty functional soup, but it needs something starchy, like pasta or rice, so let's do that.

If you're going the route of orzo or rice, I highly recommend that you rinse it first to get off all the excess starch. Otherwise you risk clouding your soup. It won't taste bad, but it'll be less pretty.

If you're going the noodle route, you'll want to break it into tiny pieces so it's easier to eat.

Either way, dump your chosen carb into your soup, cover it, and let it boil at a low temperature until the pasta/rice is ready.

Garnish

At this point, the soup is edible, but not yet exciting. You need to add all of the lovage and parsley at this stage:

  • Finely chop or rip the lovage and parsley into the soup
  • Stir it a bit and let it settle for another 5-10 minutes on a very low heat.
  • Stir in the vinegar as well

Serving

Finally we're ready to eat. Portion out the soup into bowls, and just before you serve, stir in a spoonful of sour cream. I can't tell you how much better this makes things.

That's it! The portions listed above should serve about 4 bowls, but I usually double things so we have enough soup for a few days.

October 30, 2014 20:39 +0000  |  Travel  |  0

I know that my blog has been neglected over the last few years, but what better time to attempt to give it new life than when I've travelled to the other sid of the planet?

McDonald's in Arabic

I left Amsterdam on Tuesday at 2200h, and arrived here in Sydney roughly 24hours later, or Thursday morning at 0600h for those not yet fully understanding the pain of travelling east through ten timezones. We had a 3 hour stopover in Dubai, which was a little exciting until I realised that the airport is effectively a giant mall that also has planes. They did have a McDonald's though, with the signage in Arabic, and a menu which contained no pork ;-)

The architecture of the airport is pretty amazing though: Insanely high ceilings, with walls of steel and glass. I couldn't get a view of the giant tower in the downtown core though -- not from the ground at least. From the air, Dubai is about as depressing as you'd expect: hectares and hectares of tiny clay buildings, and then off in the distance beautiful spires reaching into the sky. Not that income equality isn't a problem in North America, but Dubai is definitely below the curve on this issue.

I actually managed to get some sleep on the 13hour leg from DXB to SYD and then in a jetlaggy stupor proceeded to spend about three hours in Sydney's congested airport eeking through customs with two over massive flights and three agents processing us. I picked up a SIM card at the airport too (why doens't every airport make it this easy?): $20 for 1GB/day and infinite local calls / texts.

I got into the hotel Steph had booked for us (she'd already been here for a day and was at the conference when I checked in), walked down the hall and entered the room, at which point all of the blood left my face as I yelled HOLY SHIT and ran to the other side of the room. Our room had an unwanted guest, a spider roughly the size of my fist and it was hanging out by the front door. I considered trying to get the hell out of there, but it was guarding the door now, so I called reception for help. A maintenance guy showed up with a broom and attempted to remove the beast -- note that I didn't say "kill it with violence", but rather "remove" it, as apparently there are rules about killing GIANT FUCKING ARACHNIDS here. With much skill, he wrestled with the thing for a few minutes (it was a jumper, jesus christ), and he managed to coax it into a drinking glass and then take it outside.

I did some digging on the internetz to figure out what it was that clearly wanted to devour me in my hotel room, and it turns out that it was probably a crab spider. Its bite is venomous (and probably hurts and awful lot) but is non-lethal to humans. This doesn't make it any less scary though, and its brethren are all skittering about... just outside this hotel room. Honestly, I don't understand why anyone would want to visit a place that has beasts like this -- let alone live here.

For those interested, here's a picture of the creature in question, taken with my phone, from the far side of the room as I awaited rescue. Note the door hinge in the foreground for scale. The internetz tell me that these things grow to about 7cm in diameter, which sounds about right.

Once I was well showered, I headed over to the conference where I learnt some really cool stuff about how GitHub captures and logs front-end errors, as well as some pretty cool stuff about how we evaluate languages and frameworks.

...and now it's 0730 and we've got to get ready to head out to the conference again. But first, Stephanie has promised me that there's a good breakfast place nearby. I just have to keep an eye out for dragon bugs on our way there.

October 15, 2014 15:45 +0000  |  Django  |  0

So with version 33, Firefox did something rather annoying, they now use a more restrictive library that rejects connections to servers running older versions of SSL. On the one hand, this is pretty awesome because at some point we all need to grow up and start using modern encryption, but on the other, it can make development really difficult when all you really need a an SSL setup -- any SSL setup to make your local development environment Just Work.

We've been using django-extenstion's runserver_plus feature, which is awesome because it includes a browser-based debugger and other really cool stuff, but also importantly, it supports the ability for you to run the Django runserver in SSL mode. This means that you can do stuff like:

./manage.py runserver_plus --cert=/tmp/temporary.cert

And that's enough for you to be able to access your site over SSL:

https://localhost:8000/

However, now that Firefox has thrown this monkeywrench into things, we spent far too much time today trying to figure out what was wrong and how to fix it, so I'm posting the answer here:

Basically, you just need a better cert than the one django-extensions creates for you automatically.

So, instead of just running --cert=/path/to/file and letting runserver_plus create it for you, you should run openssl yourself to create the cert and then point runserver_plus to it:

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/temporary-cert.key -out /tmp/temporary-cert.crt
$ ./manage.py runserver_plus --cert=/tmp/temporary-cert.crt

Of course, you can locate temporary-cert.* wherever you like, but you get the idea.

August 02, 2014 17:36 +0000  |  Gentoo Linux  |  0

The NUC is a pretty neat idea: Intel gives you a little box with a motherboard and a CPU inside and you decide what else you want to do with it. For me, I just wanted a quiet little server in the corner of the house, so I bought 4GB of RAM and a 500GB (cheap, spinning) hard drive. About €220 and I was ready to go... and then the pain started.

An image of the Intel NUC

Keyboard

The NUC comes with the latest-and-shiniest BIOS stuff that Intel could come up with: a whole bunch of useless polish to obfuscate the useful features you're looking for. Still, this wouldn't be so bad if it weren't for the fact that the NUC doesn't recognise some keyboards at boot time. I plugged in my primary board, hit F10 and... nothing. Lucky for me I had an old dusty Logitech solar keyboard around, otherwise this effort would have died before it started.

UEFI vs. Legacy

I'd heard of UEFI, and had a little experience trying (and failing) to get Gentoo onto a Macbook in the past. I had a weekend, so I thought it'd be a good learning experience to go the UEFI route this time. For the record, this is a Bad Idea.

UEFI support in Linux is still rather young, and resources for its use in Gentoo are sketchy and fragmented, often with conflicting advice. The handbook mentions UEFI only once in the entire document, and web searches for UEFI Gentoo result in a plethora of conflicting and/or unhelpful pages:

  • https://wiki.gentoo.org/wiki/Partition
  • https://wiki.gentoo.org/wiki/UEFI_Gentoo_AMD64_Quick_Install_Guide
  • https://wiki.gentoo.org/wiki/EFI_stub_kernel
  • https://wiki.gentoo.org/wiki/GRUB2_Quick_Start
  • https://wiki.gentoo.org/wiki/GRUB2
  • http://forums.gentoo.org/viewtopic-t-971988-highlight-intel+nuc.html
  • https://bbs.archlinux.org/viewtopic.php?id=168548

Legacy it is

So, after doing a complete install on this little Celeron box (it's slower than you might think), I decided to blow away everything and start again, this time opting for just sticking to legacy boot.

After 10 min or so poking around in Intel's ridiculous Visual Bios interface, I managed to turn off UEFI and enable Legacy (protip: you can't simply check the Legacy box: it doesn't do anything. You have to uncheck the UEFI box and magically the Legacy box will check itself. Nice job there Intel.) I rebooted using my SystemRescueCD USB stick, booted into the Gentoo setup environment and followed the handbook verbatim (choosing GPT partitioning, this important to the story) right up until the end. I rebooted and...

The NUC complained that it couldn't find any bootable partitions.

It's all in the partitions

Frustrated, bitter, and angry at this point, I started searching online again, this time specifically for gpt, intel nuc and bootable and I found this obscure forum post where someone essentially had my problem with a different machine: the BIOS was set to legacy, the disks were partitions with GPT, and the machine couldn't find a bootable disk.

The post explained that some BIOSes are dumb and require an old-style bootable flag to be set on the boot partition (read: old, fdisk-style, not parted-gpt-style partitions). The solution was to open /dev/sda in fdisk and set the partition (there's only one when you've used GPT) to bootable. Problem solved right? Wrong.

The version of fdisk that ships with SystemRescueCD is a modern one that actually recognises and attempts to make use of GPT partitions. If you open /dev/sda in this modern version, there's no ability to actually set a bootable flag. I was stuck again. Back to the Internetz to where I found this useful page that gave me the magic incantations required:

# parted /dev/sda
(parted) disk_toggle pmbr_boot
(parted) quit
# reboot

Apparently disk_toggle pmbr_boot does the very same thing as opening a GPT partitioned disk in an old version of fdisk and setting the bootable flag. After the reboot (and the removal of the USB stick from the back of the NUC), everything booted up nicely, Systemd stuff included (that part was painless).

So, to recap:

  • Don't use UEFI unless you like pain
  • Do everything old-school, and if you must use GPT, remember disk_toggle

I hope this helps someone out there.

June 18, 2014 18:01 +0000  |  Django  |  0

I ran into this problem last night, and since Googling for it didn't help, I thought it prudent to post my solution publicly in case anyone else might have a similar problem.

Tastypie is a nifty REST API server app for Django that does a lot of the work for you when all you want to do is share your model data with the world using standardised methods. It's smart enough to do introspection of your models and then use what it finds to make serialisation decisions further down the line. That's how you get from a series of model field definitions to an easy to parse JSON object.

Django-Polymorphic is an amazing piece of software that lets you effortlessly dump polymorphic attributes into your models in an understandable and performant way. With it you can do things like ask for a list of Items and get back a series of EdibleItems and MetalItems.

While both of these technologies are awesome, they don't appear to play nice together. From what I can tell, this is due to how Tastypie does its introspection: at startup time rather than run time. Introspection is done once, on the initial class, and then never again, so polymorphism just won't work.

To fix this, you have one or two options: (a) Break up your API by item type using something like /api/v1/edible-items/ and /api/v1/metal-items/ rather than just /api/v1/items/, or (b) teach Tastypie to combine them. As I needed the latter, I wrote this:

from django.db.models.fields.related import ForeignKey, OneToOneField
from tastypie.resources import ModelResource
from .models import Item

class ItemResource(ModelResource):

    class Meta:
        queryset = Item.objects.all()
        resource_name = "items"

    def dehydrate(self, bundle):
        """
        Account for django-polymorphic
        """

        unacceptable_field_types = (ForeignKey, OneToOneField)

        for field in bundle.obj._meta.fields:
            if field.name in bundle.data:
                continue
            if not isinstance(field, unacceptable_field_types):
                bundle.data[field.name] = getattr(bundle.obj, field.name)

        return bundle.data

It's not the prettiest of solutions, but it seems to do the trick for me at this stage. If you're reading this and think I've missed something, please feel free to drop me a comment.

April 18, 2014 12:18 +0000  |  Canada, Democracy, Politics  |  0

Listening to CBC radio this morning, Evan Solomon interviewed a Conservative Party senator about the Fair Elections Act. He claimed support for the bill because while he'd received a number of form letters opposed to it, "not a single personal email" had crossed his desk.

Of course, upon hearing this, I did what I could to send him a personal email, but it turns out that it's rather difficult. He didn't list any contact info on the show, so I had to look him up on Wikipedia. From there, I went to his personal website, which was down, so I visited his official page on the Senate's site and sent him this:

Subject: You said you'd not received any personal emails so...

Here's one asking you to reconsider your position on the Fair Elections Act.

The vouching issue is a big problem, but to be honest, it's not my primary concern. I object to the act on the grounds of banning vouching alone as it will disenfranchise voters at a time where our elections are bordering losing their legitimacy, but personally I see the other facets of this bill as far more dangerous.

For me, the most disturbing part of the act are the changes to spending limits that create loopholes so big that that it effectively enables rich parties to dominate the electoral process. Poorer parties, like the NDP, Greens, Bloc, and Pirates, which represent the will of millions of Canadians will be eclipsed by the war chests amassed by the already dominant parties in our country. Canada's democratic process is already biased toward a two-party system, why would you work to deepen that problem?

Then there's the constraints on Elections Canada, a spiteful swipe by the Conservative party if ever there was one. Elections Canada needs the power to compel testimony in its effort to keep our elections fair, and the Conservative Party moves instead to curtail the powers of the Chief Electoral Officer and then goes even further to do something nobody wants: block them actually promoting voting.

There's a reason no one who knows what they're talking about supports this act: it's insane. You know that deep down most of these proposals were never made in earnest. The goal has always been to distract the public with the more glaring changes (vouching, stopping Elections Canada from promoting voting), so that the financial changes -- the long-term, most damaging ones -- can slip through on an amended bill.

You're an unelected senator, and this is why I love the Senate. You're in a position to vote to turn this bill out completely with absolutely no risk to your position. You know that this is a bad bill, you have to. Have the courage to stand up for future generations in this country that want fair elections. Turn this bill back with a recommendation to introduce real electoral reform: open accounting, a modern electoral process, any number of recommendations proposed by experts in this field.

You have a choice, here and now to do something right with your position. Please don't waste it.

This Fair Elections Act is probably the most damaging piece of legislation the Conservatives have ever put forward. If it succeeds as-is, it will permanently damage the legitimacy of every Canadian government from 2015 forward. If it's amended to include only a fraction of its current payload, it will simply cripple democracy across the country.

If you're reading this and you're Canadian, please take a few minutes to learn about the act and then write to a senator about why (s)he needs to fight this. It's important.

April 01, 2014 23:24 +0000  |  Free Software, Politics  |  0

I had a bit of a revelation the other day. I realised that we live in an age where state power and secrecy is so fragile that governments are completely at a loss regarding what to do about it. All it takes is for one person with a conscience to copy a file and push it out onto the Internet and that's it: everyone can know the truth, and no one can stop it from circulating.

We've seen this at play with Wikileaks, and more recently with Edward Snowden, and the public world wide overwhelmingly supports the work of these individuals and organisations in bringing to light truths that need to be told. This amazing future we're living in, that allows us to practise journalism of conscience exists solely because of a concept we often refer to as the "Open Web", and it's under attack.

Mozilla screencap

Without getting too technical, there are concerted efforts by governments and corporations to break down the Open Web into more manageable chunks. Governments want a means to control what data gets distributed, copyright holders want a way to monitor what you share and with whom, ISPs want to turn the internet into a series of channels so that they can charge for so-called premium services, and then there's companies like Netflix that actively work to privatise the web itself, pushing for proprietary, closed standards.

Our Free and Open Internet is being attacked on all sides and no one has been a greater ally for the public good in this fight than Mozilla. Yes of course, The Pirate Bay has been a champion of our rights for years, and Google has our back... sometimes, but when it comes to a reputable, reasonable, non-profit voice in the one area that counts the most for this point in our evolution, Mozilla is it.

Mozilla's decision to promote Brendan Eich to CEO was not an endorsement of his politics, but it's still terrible for many reasons, not the least of which was the foreseeable backlash they had to have known they would face from the community who have come to love, trust, and promote Mozilla over the years. His presence in the Big Chair undermines all of that goodwill, and his unwillingness to seek some sort of reconciliation with the community only serves to damage relations further.

But this business of boycotting Mozilla, driving people away from a Free and Open Internet and into the hands of private and government interests, this is not good for anyone but Google, Apple, and the NSA. We need to prioritise the public good, over our distaste for one man's bigotry. We should condemn Mozilla's decision, but acknowledge that they're still our closest ally in the fight for a Free and Open Web.

Brendan Eich should be mocked publicly for being lost on the wrong side of history and Mozilla's board should question its decision to put at the helm of their company someone who has cost the company so much in the eyes of the public, but if we're going to continue fighting for an Open Web, we need to acknowledge who our friends are.

Hint: it's not Google.

January 22, 2014 17:46 +0000  |  Software  |  0  | 

Every once in a while I hear people speaking with authority about what exactly agile software development is, and the funny thing is, they usually conflict with other statements with similar authority about agile. Often, this is coupled with negative comments about how agile is impractical because X, which is frustrating, because some of my most productive years were spent in a fully agile office environment.

So I thought that I'd write something about agile as well, if for no other reason than to hopefully point people in the direction of what I know to be a very efficient and practical means of getting stuff done. I don't want to claim that this is the One True Way of agile development though, as I'm not interested in having the kind of conversation where we re-classify everything for the sake of giving it a name. My team lead at the time, Mike Gauthier called this system agile, and that's good enough for me.

Talk Less, Code More

The goal behind agile is to have developers spend time doing what they love: rolling code, and to keep them out of meetings they want no part of to begin with. Instead developers have only 3 responsibilities over and above writing code throughout the sprint. I'll cover these in more detail below:

  • A Morning stand up meeting: Every day, 10min
  • Sprint meeting: 1hr
    • 30min to recap the last sprint
    • 30min to prepare the next one
  • Any additional initiative taken to talk to the client about what they want

Note what isn't in that list:

  • Requirements meetings
  • Proposals
  • Logging hours
  • Documentation

The idea behind agile is essentially: "Here's a task, go!". The key to making this work is to keep the tasks simple and concise, so that the result of the sprint is incremental. Read: easy to deploy, with no surprises.

The rapid pace of an agile project means that the usual slow processes of planning meetings and wiki documentation becomes an exercise in futility: the job is done before it's planned, and it's changed not long after it's documented.

Stand Up

It sounds like a pointless process, but it's probably the most powerful part of an agile system. The morning "stand up" meeting, or "scrum" is exactly what it sounds like: the entire team stands up in a corner of the room to answer 3 questions each:

  1. What'd you do yesterday?
  2. What're you expecting to do today?
  3. What happened yesterday that prevented you from doing what you needed to do?

Each developer should talk for no more than a few minutes, answering these questions point blank. It's the opportunity for the team lead to address whatever problems were mentioned (after the meeting), and for other developers to find out that their colleagues are waiting for them to finish something.

Note that this meeting is not for design discussions, or gripes etc. Rather, the purpose is to be a quick update on what's going on -- which is why you're supposed to stand up through the whole thing. The minute someone starts to look like they need to sit, that's your cue that the meeting has gone on too long.

Sprints

Think of sprints as a deploy schedule, but short and seemingly insignificant in what they produce. While a typical software deploy schedule may last months or even years, consisting of massive upgrade paths and a long complex list of changes, sprints are typically 1-2 weeks long. You write the code, and it's live in a few days.

The big difference from other methods is that sprints are incremental, so while new features roll out bit by bit, bugs are fixed weekly with no having to maintain multiple branches for extended intervals.

Keeping the sprint short ensures 4 things:

  • The tasks are always short-term and easy to comprehend both for developers and clients
  • Clients see progress on a regular, predictable schedule
  • Releases are predictable, and easy to break new features into
  • Your team has a concrete and easy to understand goal to work toward

Code Debt

But what about those elaborate project charts with tasks designated to different developers, all colour coded by week, accounting for availability?

Gone. All of it. Throw it out. You now have a binder full of post-its, or if you're feeling all 21st century about it, a Jira task list. This bundle of tasks is your code debt and should not be organised as priorities are expected to change from sprint to sprint. At most the PM should keep a loose tally of priorities, so as to make the sprint planning meetings go smoother.

Chipping Away at that Debt

At the start of every sprint, you hold a meeting in which the project manager talks to the developers about what's most pressing in terms of bug fixes and new features. Importantly, this is a two-way conversation: the PM representing the needs of the client, and the developers representing their own limitations and the quality/maintainability of the code.

This sprint planning meeting is where you take stuff out of your code debt, break it into bite-sized chunks, and assign it to the current sprint. You need to keep the tasks small and easy to achieve in < 4hours. If it takes longer than that, it needs to be broken down. This has a couple big benefits:

  • Big jobs can be spread around, potentially finishing them faster
  • Knowledge sharing is easier as everyone has the opportunity to work on smaller portions of a greater whole.
  • It's an easy way to make big jobs suddenly feel possible.
  • Finishing a task results in a sense of accomplishment for the developers
  • Incremental change gives the client a sense that something is being done

No Ticket, No Work

Now that your sprint planning meeting has broken up a portion of your code debt into tasks, the team is presented with a white board with a simple grid layout:

+--------+--------------+-----------+------------+---------------+
|  Todo  |  Developers  |  Working  |  Finished  |  QA Complete  |
+--------+--------------+-----------+------------+---------------+
|        |  Daniel      |           |            |               |
|        +--------------+-----------+------------+---------------+
|        |  Aileen      |           |            |               |
|        +--------------+-----------+------------+---------------+
|        |  Charlie     |           |            |               |
|        +--------------+-----------+------------+---------------+
|        |  Aisha       |           |            |               |
+--------+--------------+-----------+------------+---------------+

That Todo column is where you put the amorphus blob of post-it notes, each one representing one of the aforementioned bite-sized tasks for this sprint. Note that while in this column, they aren't actually assigned to anyone; they're simply waiting for someone to take them and stick it onto their Working column.

Now, say that there are 30 tasks to complete before the end of the sprint. Aileen sits down at her desk and as she has nothing to do yet, she looks at the board and grabs the post-it about fixing a bug in email notifications. She moves the post-it from the Todo column into the Working column on her row, and opens her editor.

When the job's done, she moves it to Finished, at which point the QA team can now take a look, and when they're happy with the job, they move it to QA Complete. If however her change broke something, or if it's simply unsatisfactory, they move the post-it all the way back to the Todo column, where Charlie might grab it later that day, since Aileen has moved onto another ticket about the statistics engine.

In practise, developers will often gravitate toward tasks they're familiar with, and they'll often leave tickets that have been bounced-back by QA for the initial developer and this can be ok. However if ever one developer becomes a dominant force on a particular component, (s)he might be forbidden from working on it for a while, to make sure that the other developers have a chance to spend some time learning how that software works.

The most important part of this is that developers aren't supposed to do any work unless there's a ticket for them. This keeps people on-task toward completing the sprint on-time and as expected. If there's other work that deserves attention, this is best brought up at the next sprint planning meeting.

Spikes

It's about at this point where people start with comments like "What if the server goes down? Are we expected to wait until the next sprint to fix it?". Obviously not. Emergencies or "directives from on high" are things that can't wait and by their nature they can't be part of the sprint plan. They're also rare, so breaking a working system to accommodate them is a little absurd.

The solution is what's called a "spike". A task injected into the Todo list, typically flagged to be done as soon as possible. Its presence in a sprint taints the sprint, so that it can be pointed to in the event of an overrun:

The server went down on Friday and Aisha had to burn half her day fixing it. As a result, we only finished 33 of our 36 tickets this sprint.

This is the sort of thing talked about in the post-sprint meeting, and if more action is needed (either to fully correct the problem or to avoid future cases) these tasks are added to the next sprint.

So, How'd it Go?

There's one other meeting of consequence. At the end of every sprint, you meet to talk about how the sprint fared: what went well, what didn't. In those 30 minutes, you talk about how awesome the QA team was, and how much it sucked when that module we thought would save us work turned out to create more than it solved. It's important to use this time to blow off steam and celebrate the accomplishments of the previous sprint and to take some time to figure out what could have gone better. It facilitates knowledge sharing more than anything else, and allows the PM and team lead to make better decisions in the future.

Documentation

The one thing people freak out about most when I talk about this method is the lack of documentation. They conjure up nightmare scenarios where one of the developers is hit by a bus and "no one knows how their stuff works", or point out that new developers won't have anywhere to start. Both of these are non-issues though, so long as you stick to the process and don't write terrible code.

If any member of the team doesn't know how a component works enough to get in there and complete a task, then it's time to get that person working on one of those tasks. Knowledge transfer happens best through doing, which means making sure that every member of the team has her fingerprints on every part. To put it in real terms, if Daniel gets hit by a bus, the project can go on because Aileen, Charlie, and Aisha have all spent some time poking at the payment engine. Not one of them wrote the whole thing, but the understanding is there.

Of course this can only happen if the code is readable and adheres to established standards. Variable names should be in the common language of the team and be whole words, method calls should be given names that explain what they do, and class names should make sense as singular objects. If the code can't be understood by someone who's never seen it before, then it's broken by design. Making sure that everyone has an opportunity to interact with this code is the best way to ensure it's readability.

Be Rigid

Probably the hardest part of agile software development is sticking to the process. As simple as it is, it's just too easy to fix a bug that someone found that isn't in the sprint, or add a simple feature that the client mentioned earlier that day. If agile is going to work, this can't be allowed to happen, and a lot of people have a hard time with this.

What you have to remember is that while the process feels pointlessly rigid, it's there to protect the team and ensure that the client gets exactly what was promised on the schedule that was promised. Adding in bug fixes can potentially derail the schedule, or introduce bugs that shouldn't have been there in the first place. It teaches the client that she can have whatever she wants whenever she wants, and as it's not part of the agreed sprint, she may try to get away with not paying for it.

From the developer side, it's important to remember that we like lists. If we can look at the list of stuff to do and know that that's all that's ever going to be there for the whole sprint, this introduces a sense of calm, and knowing exactly what's expected.

To this end, it's important reward a team that manages to complete its sprint ahead of schedule. If they get everything finished by Thursday, let them take Friday off. The project is exactly as far along as you expected, so why not? Similarly, if the team is routinely late in completing the sprint, overtime is justified since the entire team helped write the sprint schedule during the planning meeting.

Conclusions

What makes agile work is having a simple and concise plan to follow, that has been agreed upon by all parties. I've worked at companies that implement this system without involving the developers so the schedule is imposed by people who have no knowledge of what actually needs to be done. I've also worked at companies where the developers run the schedule, which is to say, there's barely any schedule at all and the results are products that "mostly work", according to whatever the developer at the time thought was appropriate. As with so many other things, the key is openness, honesty, and inclusion in the process for all sides.

Agile is a system that everyone understands and agrees to, but doesn't get in the way of actually getting stuff done. It protects all parties involved from undue stress, and unexpected results, and I can honestly say that it was (at least for me) the best system to work with.

January 18, 2014 15:48 +0000  |  Star Trek  |  1

This blog has been far too serious for far too long, and as Christina and I have been ever so slowly making our way through the entire modern Star Trek series, I thought that I might do something fun here for a change.

Star Trek is a Big Deal for me. When I was a kid and oh-so-desperate to delay my bedtime, my parents instituted one rule: we could stay up late so long as we were watching Star Trek or the news. Star Trek's questions of morality and ethics became part of my own internal dialogue and even today, at 34 years old, when dealing with my own moral compass, I find myself making these decisions in a Roddenberry context.

I give you, The Top 11 Best Star Trek Episodes Ev-ar (according to me) I've done my best to include relevant YouTube video clips, but in many cases they were either too spoiler-ridden, or just didn't exist.

1. DS9: In the Pale Moonlight

Because I can live with it... I can live with it.

Hands down, the most impressive episode for me has to be In the Pale Moonlight, a brilliantly written and exceptionally acted self reflection of "one Star Fleet Officer" and the good intentions that pave his personal road to Hell. You don't even need to know much about the series to appreciate this one, so if you're just curious about what DS9 is capable of, this might be a good place to start.

2. DS9: Far Beyond the Stars

You can pulp a story, but you cannot destroy an idea! Don't you understand, that's ancient knowledge. You cannot destroy an idea! That future, I created it, and it's real! Don't you understand? It is real! I created it and it's real!

This episode has very little to do with Star Trek at all, except that it sort of has everything to do with it. It postulates the idea that science fiction is more than just stories about robots and space ships, but a means of painting a picture of a better world, a hypothetical, but more importantly possible world. Set in the US in the 1950s, the entire episode is played by the regular cast -- out of make up.

3. TNG: Measure of a Man

Now, the decision you reach here today will determine how we will regard this... creation of our genius. It will reveal the kind of a people we are, what he is destined to be; it will reach far beyond this courtroom and this... one android. It could significantly redefine the boundaries of personal liberty and freedom - expanding them for some... savagely curtailing them for others. Are you prepared to condemn him and all who come after him, to servitude and slavery? Your Honor, Starfleet was founded to seek out new life; well, there it sits! - Waiting.

They'd spent a year introducing us to Data, teaching us that while he is different, he is obviously still a person with rights... right? Measure of a Man puts that assumption on trial and forces you to come to terms with questions like the meaning of personhood.

4. DS9: The Siege of AR-558

We Hold.

War stories tend to glaze over the details, the parts we know to be brutal and gruesome, but from a bird's eye view, not very interesting. Unfortunately this tendency leads to glazing over the realities of PTSD, disfigurement, death, and the moral choices we're left with when we're down to almost nothing. AR-558 tars the image of "war hero" with a reality brush unlike anything else I've ever seen.

5. Voyager: One Small Step

Yankees, in six games

A salute to explorers over the centuries, this episode tells the story of an astronaut from the age when we basically strapped bombs to our backs and propelled ourselves into space protected by little more than a tin can. The really interesting dialogue here is from Seven of Nine, who cannot understand the interest in such a historical find. She deems the technology antiquated and the historical record useless, but comes to understand the value in exploration, and why so many risk so much for the frontier.

6. TNG: The Drumhead

With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.

Another exceptional episode from an early season of TNG, based loosely on McCarthyism, but applicable to any witch-hunt mentality, Picard's big speech at the end is something regularly referenced in serious dialogue even today.

7. TNG: Chain of Command (part 2)

But more than that, I believed that I could see five lights

Chain of Command explores the malleability of truth and the effects of torture. There are two plots in this double-length episode, but fans only ever remember "There are four lights!" We're asked to question the nature of reality and whether there's anything to gain in accepting that which we know is false.

8. DS9: Nor the Battle to the Strong

The line between courage and cowardice is a lot thinner than most people believe.

Nor the Battle to the Strong attempts to dispel the image of soldiers as war-hardened professionals and shed some light on the realities of warfare in which fear is the ever-driving force. We follow the lives of a hospital under attack, with our primary characters tending to the wounded and doing what they can to survive the assault.

9. TNG: Tapestry

There are many parts of my youth that I'm not proud of. There were... loose threads - untidy parts of me that I would like to remove. But when I pulled on one of those threads, it unraveled the tapestry of my life.

Aside from the classic scene where Q delivers flowers for a "John Luck Pikard", this is a wonderful story about what it means to reflect on your life as a whole, accepting your past regrets as part of who you are and who you would become.

10. Voyager: The Void

It was almost like being part of a federation again.

What makes Star Trek great is that unlike so many other sci-fi series, it's based in a utopian future where sharing and cooperation proves itself to be the superior model. The problem with utopian models though is that all too often they don't talk about how they got there. The Void is an attempt to show the process, and they do a wonderful job.

Honourable mention: Voyager: Living Witness

Isn't it a coincidence that the Kyrians are portrayed in the best possible light? Martyrs, heroes, saviors... Obviously, events have been reinterpreted to make your people feel better about themselves. Revisionist history - it's such a comfort.

Living Witness explores the malleability of history: were the Bad Guys really that bad, the Good Guys really that good? What if evidence were suddenly presented that invalidated previous misconceptions? What obligation do we have to set the record straight?

Recent images in the Gallery

@searchingfortao