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.
- 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
- Pepper (fresh ground black pepper, none of that powdered stuff)
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.
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:
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.
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.
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.
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.
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.
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
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
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.
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:
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.
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.
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
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
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
Gentoo result in a plethora of conflicting and/or unhelpful pages:
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
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
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
fdisk and set the
partition (there's only one when you've used GPT) to
bootable. Problem solved
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
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
I hope this helps someone out there.
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
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/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
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:
if not isinstance(field, unacceptable_field_types):
bundle.data[field.name] = getattr(bundle.obj, field.name)
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.
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.
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
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
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.
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
- Logging hours
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
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
- What'd you do yesterday?
- What're you expecting to do today?
- 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.
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
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 | | | |
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
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
Complete. If however her change broke something, or if it's simply
unsatisfactory, they move the post-it all the way back to the
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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
The line between courage and cowardice is a lot thinner than most people
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.
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
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.
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
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?
I started this year with a grand plan: travel out of country 12 times, once for
each month in the year. It didn't quite work out that way, but I got close, so
I guess I'll start this Great Big Annual Post with the sightseeing:
Following what would appear to be an unfortunate pattern, Christina and I went
North in winter, and did a weekend in Copenhagen. We saw Cirque du Soleil,
wandered around the city a bit and ate as many danishes as we possibly could.
Honestly, I'd go back just for the danishes. Maybe we will in 2014.
Photos from our trip can be found in my image gallery.
It was my first FOSDEM conference, and knowing basically
nothing about it other than the fact that it was about Free software and didn't
cost anything to attend, I booked a train and a hotel for the weekend. I had
such an amazing time, I'm already booked to go back for this year's conference.
FOSDEM is a big deal in the Free software world, and it's probably the biggest
conference of its kind in Europe. I met some of the developers of my favourite
Linux distribution and bought one of them dinner. I got to
publicly thank the GNOME developers for all of their hard
work while they were battling a mountain of user backlash, and got some
stickers, which was pretty awesome.
Stephanie loves to travel, and so do I, so when
she's in the neighbourhood (ie. within a few hours flight) we usually try to
meet up and go somewhere interesting. After much deliberation over Skype, (and
some scoffing from Christina regarding our decided destination) we settled on
Gibraltar... and it was awesome.
Incredible views from the top of the rock, fascinating military history, and
beautiful caves. Oh, and did I mention the super-crafty monkeys? If you've got
the time, and don't mind potentially getting stuck there an extra day when the
plane refuses to come due to weather, Gibraltar is pretty amazing. If you don't
feel like making the trip though, there are some photos in case you're curious.
At last, Christina was able to share her love of Edinburgh with me. She'd been
going on about its fabulousness ever since we met, so it was time that I saw it
with my own eyes.
Truth be told, Edinburgh is quite beautiful, with a diverse surrounding
landscape influencing the local architecture. We hiked to the top of Arthur's
Seat and the crags, saw a choral concert and toured the underground with a guide
I'm reasonably confident was high at the time. Oh! and I also got to eat a deep
fried Mars bar. Not at tasty as you might think. Ew.
Photos are on my image gallery if you're
Warsaw, Kraków, and Auschwitz, Poland
I'd hoped to do more travelling into the old Eastern block countries this year,
but unfortunately I was only able to visit Poland in 2013. Fortunately, since
DjagoCon EU was based there, I managed to bookend
the conference with some personal time and save on airfare in the process.
Before settling down to the conference, I toured Warsaw and Kraków,
and saw the remnants of the horrors of Auschwitz. I'm still
deeply effected by what I saw there.
There's photos from my entire Poland trip in my image gallery if you'd like to see what I saw.
Athens & Santorini, Greece
This was apparently my Greek year. Christina and I visited in June: first
Athens (Αθήνα), and then the Island of Santorini (Σαντορίνη). The weather was
hot, but not beyond my capacity, due mostly to the dryness of the climate. The
food was wonderful, and the people both friendly and accommodating. Christina's
family took us to the Acropolis (Ακρόπολις), and the Temple of Poseidon
(Aκρωτήριο Σούνιο). I also got to meet the extended family, and Eat All The
Foodz. With the exception of one horrific boat ride from Santorini to Athens,
the trip was wonderful.
Here are the pictures if you're into that.
Theresa made the trip to her favourite city in the world, and we arranged it so
I could meet her one weekend while she was in town. We didn't have a lot of
time, but we got the important part in: actually seeing each other and catching
up on what's going on in our lives. We toured a cemetery, wandered through Hyde
Park, and spent an unfortunate amount of time looking for a good steak house.
It's funny, but every time I go to London my opinion of it changes. After some
trips I despise it, and after others, I can actually see myself choosing to live
Athens, Greece (again)
I didn't expect it, but my company chose to send me back to Athens for RIPE 67,
so that I could help out for a workshop about the RESTful API I helped write for
our ATLAS project. It was an exhausting trip, that
saw me rarely leave the hotel, but there were a few evenings that I managed to
get out and explore. I took a few hours one evening to visit Plaka (Πλακα), met
Christina's father for a tour through a local museum, and for dinner at their
house, and on my last night in Athens, Vesna and I hit the beach with a couple
of her friends, had dinner there, and then headed across town to the local
hackerspace, closing the night with drinks at the
foot of the Acropolis. That was a really good time.
Christina took a work-related trip to Paris, and I decided to surprise her for
her trip home. We didn't have a lot of time for sightseeing (we'd already been
a few times each, so this wasn't all that high a priority). We actually spent
most of the night looking for a good place to eat and eventually found ourselves
disappointed at a place I thought would be good. It's the thought that counts
Finally, this was the year of Christina's first trip to Canada. We set off at
the tail end of November to see Vancouver and Kelowna, and gauging her reaction,
she seems to really like my country :-)
We met some of my friends, and most of my family, wandered through Stanley Park,
and I ate as much food as I possibly could. Seriously, I nearly broke into
tears biting into a proper cheeseburger (oh how I've missed those!) We drove
over the Rockies up to Kelowna where we did a little sightseeing and a lot of
just hanging with my family.
Photos from both Vancouver and Kelowna are available in my image gallery.
Bonus: there's a shot in there of my fabulous Movember mo.
I'm hoping that 2014 will see us make a trip to Eastern Canada, maybe a road
trip form St. John's to Toronto? We'll see.
On the personal front, the big news of the year was Christina and I moving in
This is only the second time that I've managed to get this far in a
relationship, and the last time we sort of fell into it, after having moved from
Vancouver to Ottawa. I'm hoping this time works out better.
Christmas in Amsterdam
Having a home of our own meant playing host to the Angelopoulos family over
Christmas. Christina's sister is in the UK, her cousin in Belgium, and her
parents in Athens. This made our place a logical destination for the big dinner
shindig. Her parents were here for roughly two weeks, while her sister and
cousin were crashing for only a few days. It was nice to have someone to spend
Christmas with, given that my family was thousands of kilometres away, and I
even learnt a few new Greek words in the process.
I also took a few pictures that week.
The big cloud over my life this year has been an as-yet-undefined illness that
makes me dizzy at times throughout the day. I assumed that this all started
after that horrible boat ride from Santorini, but it's impossible to tell at
this point. Since August I've had regular dizziness spells, and even fainted
once. It generally doesn't get in the way of my day, but it's still rather
disturbing. My ENT assures me that there's nothing wrong with me, which is both
encouraging and disheartening: a person knows when something isn't right, and
when their doctor just smiles at you like you're wasting their time, it tends to
get under your skin.
I've had blood tests, an ECG, and an MRI, all of which returned with "all clear"
results, so I can see where Dr. Smiley is coming from, but the symptoms are
real, so I don't know where to go from here. Christina and I talked about it
and we're going to wait a few months to see if things get better on their own.
If they don't I'll be asking for a referral to a dizziness clinic in the hopes
that they can figure this out.
I'm also getting fatter, which obviously sucks. At 34 years old, I've never
actually had to work at maintaining an appropriate weight, and the realisation
of this new reality is not a happy experience. We did just move into a building
with a gym though, and I've just started making use of it. Hopefully by this
time next year I'll be able to report that I've lost about 10kg and holding
This was also the year of version 5 of this site's software going live,
as well as another big milestone: 10 years of blogging. I
don't post here as often as I used to (it takes a good chunk of your day let me
tell you), but I do enjoy going back over this thing to see how my life has
been, so this is a labour I intend to continue. Thank you, for sharing this
with me :-)
Started on Spirithunter (again)
You know those people who have a great idea, who tell you all about how amazing
their idea is, and how one day this amazing idea will be amazing? Well I've
been one of those guys now for three years. This past few months have seen
a renewed interest in the Spirithunter project, what we me having an actual desk
to write code on now, and I'm actually starting to see traction on that front.
It'll still be a while before there's anything I can show you people, but I
think it's worth noting that things are coming back on track now.
My Father's Project
I've also got another, much smaller project going to hopefully help my family
out with a website for their own business. It's on a tight deadline though: I
started on it not long after I returned from Canada in December, and it has to
be finished and ready by February. I'm about 30% done at this point though, so
it's time to knuckle down.
Lastly, I hit my 1 year mark at RIPE back in August, and strangely, this is the
first company I've worked for ever where I'm not already bored after 1 year.
Sure, RIPE isn't perfect, and the code doesn't look anything like what I'd like
it to, but the environment is interesting, the field actually important, and
not evil. And they fly me to Athens and Warsaw to do work related stuff.
Seriously, this is a pretty good gig. You should work there.
I started 2014 with a goal of more travel, and despite missing the quantitative
mark, I look back on all the things I've seen and done this year and I'm pretty
happy with it. For next year: even more travel, this time to more Eastern block
countries like Romania and the Czech Republic would be nice, and a public beta
of Spirithunter would make for a good grade. Keep checking back here to see how
I do on that front.