You Win the Internetz!

August 08, 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 06, 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 04, 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 04, 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 01, 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 01, 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?

January 01, 2014 21:24 +0000  |  Canada, Christina, Greece, Health, Ripe NCC, Travel  |  0

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:

Travel

Copenhagen, Denmark

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.

Brussels, Belgium

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.

Gibraltar, UK

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.

Edinburgh, Scottland

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 curious.

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.

London, UK

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 there.

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.

Paris, France

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 though right?

Vancouver, Canada

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.

Personal

Joined Houses

On the personal front, the big news of the year was Christina and I moving in together. 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.

My Health

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 comfortably.

This Blog

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 :-)

Corporate

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.

RIPE: 1year

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.

Conclusion

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.

January 01, 2014 15:37 +0000  |  Blogger  |  0  | 

Would you believe that it's been more than ten years since I started this blog? I only realised this fact last night as I was talking about blogging in general with Christina's parents. Her father thought that the whole pattern of blogging as quite strange, and really didn't see the point to it all, so I pointed out that I'd been blogging for years... and that's when I realised:

I've been writing on this website for a decade

That's just under ⅓ of my life. My life, as clumsy and convoluted as it has been, since I left Ottawa back in 2003. It includes stories about how I tried to build a life in Toronto, got my feet wet in political action, and even eventually running for office myself years later. There's stuff in here about the friends I've made, the women I've dated, and even the family that I've lost.

This blog is an archive of my life, and it's already ten years in.

This life is messy and rough, sometimes boring, and even remarkable at times, but more than anything, it's my life, and I must say that it's pretty amazing to have it all here, in print, forever on the Internet.

September 09, 2013 00:13 +0000  |  Christina, Ripe NCC  |  6

It's about time that I had an update on what was going on in my life, and now that everything has more-or-less settled down, and I'm trapped on a train full of drunken Brits, I might as well do my best to drown them out with some Daft Punk and spend the time blogging.

The big news of course is that Christina and I finally managed to move in together. We spent a great deal of time and deliberation finding just the right place, but in the end we settled on a beautiful apartment on right on the Ij, the river that flows past Amsterdam Centraal.

The commute for each of us is 15 minutes by bike and a little more than that by tram. The area is beautiful and the building comes with access to an indoor pool, gym, and sauna. Honestly, it's pretty awesome.

Adapting to living with Christina hasn't been as difficult as I'd expected. Only once before have I attempted living with someone like this, and that didn't work out all that well, but Christina and I seem to fit into each other's habits rather nicely. The biggest bit of friction is that she's incessantly clean, and I'm heavy on the wires & technology everywhere. We've managed to work around this though by developing systems and assigning chores for upkeep. She's teaching me to be more um... orderly, and I'm introducing her to the awesomeness that is having a fully wired home.

Speaking of "fully wired", we're set to have optic fiber installed on Tuesday by a company called XS4All. I can expect speeds nearing 100Mb/s, which in non-nerd terms means that while in Canada you could download a 2GB movie in an hour or two, I'll be able to fetch the same file in a few minutes. So. Very. awesome.

Honestly, I'm pretty happy with all this. Being with Christina is easy. While every relationship needs work and dedication, we seem to manage all of that pretty well. Communication is the big win: we talk about everything.

In that same thread, therapy is going really well too. There of course was my not-so-minor revelation a few weeks ago, but now we're working on the cloudiness that I've been dealing with for years. I'm seeing her less often though, as it doesn't feel like I need it as much anymore.

At work, things are a little stagnant, but the work is still reasonably interesting. The problem with my current situation is that there's really no way to advance into management without someone in management packing up and leaving -- something that's not very common with an employer like this one. I could look elsewhere, but as I'm otherwise happy with my work, and given that I don't want to be in the Netherlands much after Christina's PhD is complete, moving just isn't very convenient. On the upside though, I'm volunteering with the company OR, so I'm learning about that process.

I'm also coming home for Christmas(ish). Christina and I will be in Vancouver and Kelowna sometime soon (drop me an email for the details if you're curious about the details).

The only negative so far has been my former landlord. He's been a total ass when it comes to the checkout process and is withholding my damage deposit claiming damage that clearly wasn't there. It's partially my fault for trusting him not to be a dick, but honestly, are there any landlords out there that aren't assholes?. I'll never trust one again, even if they seem to be decent human beings because clearly they will all betray you given the opportunity.

So that's about it. Once the internet connection is installed, we'll be able to have Skype on again, so if you want to say hello, just look for me there. Also, if anyone reading this has a viable alternative to Skype in mind, I'm happy to entertain it :-)

September 09, 2013 00:08 +0000  |  Employment, Netherlands  |  0

In Canada, we essentially have two systems that manage the relationship between employer and employee: unionised and exploitative. Both of these options suck and for different reasons.

  • Unions tend to foster a combative relationship with management and often result in both sides making unreasonable demands of the other. Strikes and lockouts are common, as are attempts to undermine the right of workers to organise, union-busting, etc.

  • Non-unionised workplaces are all-too-often exploitative, using the threat of being replaced to push employees into working additional hours for free, taking pay-cuts, or even breaking the law. Conditions are often unsafe, and the atmosphere filled with distrust and animosity.

In a lot of European countries however, a third-way has been adopted, so much so that when I talk about the concept of labour unions with other Europeans, many of them don't understand the purpose of such a system.

So, what the heck is an OR? It's the Dutch incarnation of this third-way, a staff-elected council that represents employees in dealings with management. Far from being a token voice, their position has legal standing to the point where many key decisions: office hours, pension, health insurance, require approval from the OR.

The relationship between management and the OR is typically more amicable than the one you usually see between a labour unions and management in large part because the staff have more options available to them than work stoppage. The council is kept small, and is composed of people from the company, rather than an external body like a union. This means that the people you're arguing with are the same people you might eat lunch with. The same goes for the people you represent.

The meeting minutes are distributed to all staff by email, and elections are held every few years. The number of members is dictated by the total number of employees in the company, and anyone who has been with the company for six months or more may stand for election.

OR's are legally required of any company that exceeds 80 employees.

I tell you first-hand that this is the way to manage the relationship between employer and employee. It's not perfect, but I've never seen a more functional relationship in an office environment... and that's after working with ten companies over 14years in 4 different cities in 2 countries.

Recent images in the Gallery

@searchingfortao

  • I just donated to #Wikipedia. Help keep it free! #keepitfree https://t.co/2SwC0Oc4iv
  • I really don't understand why there's such vitrol from some LGBT folks directed toward @fakedansavage
  • As convoluted and idiotic the syntax is, I'm finally coming around to how awesome and useful git is.
  • I just upgraded RxLenses.ca to Django 1.7 -- not nearly as scary or difficult as I thought it would be.
  • Kopimi culture creates brilliant music: http://t.co/jwIzepFUns
  • From what I can tell so far, any episode of The Fall could easily be reduced to 20min of the editors weren't such obvious Kubrick devotees.