The simple passage of time changes us. Our personalities, identities, social circles, fears, and passions all shift to meet our needs throughout life. As we grow and mature, we must reconcile our past and resolve ourselves to the future. Time trawls up existential questions again and again: Who am I? What is my purpose? What do I want in life? What am I willing to struggle with? What happens if I fail? What could have been, but never will be? These kinds of questions can prompt deep introspection, and act as reasons for change.

My life is unrecognizable compared to even two years ago, and with these changes, new answers to those questions started to form. I found myself desiring a change.

It's a common pattern: a database developer at a startup is probably on the Product subteam of the Engineering team at their company. In a department store, shoes are a subcategory of clothing, while your favorite thermos is probably in the travel department.

In any Github organization, there are teams within teams within teams. In any large department store there are categories deeply nested. In any recipe book, there are many ways to classify food.

So how can we model them?

Not long ago, Microsoft started iterating more heavily on their long-existing "Windows Subsystem for Linux" feature. The feature has existed for some time, but recently has it become much more usable for everyday Linux development work.

In this post, we'll investigate some ways to get the most out of WSL. I won't present anything new here, just providing a single place for how I or someone else could get things set up.

When Jepsen appeared in the industry several years ago our team at PingCAP couldn't have been happier. Finally, an approachable, understandable reliability testing framework along with an enjoyable and rigorous library of analyses of popular databases.

Jepsen is an umbrella term for the software library, collection of articles, and service of the same name. Together, the project pushes distributed systems to be more accurate in their claims and more thorough in their testing.

It's been indispensable for battle-testing TiDB and TiKV, our distributed databases, as we deploy them in some of the largest technology companies in the world.

If you’re an avid reader of distributed systems news like I am, you’ve probably seen your share of benchmarks. You’ve also probably stopped taking them at face value. Unfortunately, benchmarks are hard to get right, and even more unfortunately, many articles touting benchmarks are actually benchmarketing, showcasing skewed outcomes to sell products.

So why do it at all? Let’s take a look at some of the motivations of benchmarking, the common tools, and discuss a few things to keep in mind when benchmarking.

When designing an API for your crate one topic which can come is how to handle optional arguments. Let's explore our Options in Rust!

It seems that at times of monumental change in life there is a 'before' time, and an 'after' time. For example, the time 'before' graduation, and the time 'after'. It feels appropriate for the moment. Over the other side of the summit is unknowns. Unknowns about the future, about ones place in it, and about what changes might come next.

While it is convenient at moments to make distinct 'before' and 'after' perspectives, it is not accurate. Life marches monotonically from change to change, and each before time is a composition of all previous 'before' and 'after' times. After one change, another will come, and the current ominous 'after' time, and its unknowns, will become a 'before' time, with less unknowns.

In the time since my last writing life has been nothing short of a whirlwind. It's been good though. I've relocated, started at PingCAP, found a new apartment, bought furniture(!!!), traveled, travelled more, and been working on a few other bit things.

Moving back to Victoria from Berlin was (as predicted) quite a change. Having lived here most of my life though, I still have old friends here and know the city well. The city has been changing, some areas are completely full of construction, even minutes outside of downtown. I'm quite interested in seeing where the city is going, and how they tackle problems like homelessness as the city becomes more and more expensive.

First of all, happy new year!

It's been awhile since I wrote anything, and there are many things I'd love to write more about. Sadly, time is a limited resource and I've been managing to keep quite busy. For now, I'll stick to an update about a wave of change in my life.

Recently there has been quite a bit of talk about WebAssembly, a new format for code for the web. It is a compile target for languages like C and Rust that enables us to write, and run, code from these languages in our browser.

In the interest of learning more about this technology (and to avoid writing more Javascript) let's explore together and get our hands dirty!

Disclaimer: WebAssembly is stabilized, but most implementations are not. The information contained here may become out of date or be incorrect, despite working at the time of writing.

In this post we'll be discussing one way to set up your machine for Rust development. There are different ways, particularly related to the text editor, so feel free to skip what is irrelevant to you. We'll focus on:

• Setting up Rust via Rustup.
• Valuable tools like clippy and rustfmt.
• Configuring VS Code for Rust.
• Debugging with the command line and inside of VS Code.
• Using different compile targets.

Everything we do should be functional on both Linux and MacOS, on Windows your mileage may vary. I, unfortunately, don't have a Windows instance to test on.

Recently there has been a lot of progress in the Rust language towards a robust asynchronous stack. In this article we'll take a look at what these things are, take a tour of what's available, play with some examples, and talk about how the pieces fit together.

We'll get started with the futures crate to start, move on to futures_cpupool, and then eventually to tokio. We will assume you have some knowledge of programming, and have at least thought about trying Rust before.

Lately I've been thinking a lot about the patterns and structures which we program with. It's really wonderful to start exploring a project and see familiar patterns and styles which you've already used before. It makes it easier to understand the project, and empowers you to start working on the project faster.

Sometimes you're working on a new project and realize that you need to do something in the same way as you did in another project. This thing might not be a functionality or a library, it might not be something which you can encode into some clever macro or small crate. Instead, it may be simply a pattern, or a structural concept which addresses a problem nicely.

One interesting pattern that is commonly applied to problems is that of the 'State Machine'. Let's take some time to consider what exactly we mean when we say that, and why they're interesting.

Over the last couple days at asquera we've been on a retreat at the Landhaus Fredenwalde. It's really beautiful out here and it's given me a chance to work on a few small projects which I've been wanting to explore for awhile now.

Anyways, yesterday I set up a system that uses Ansible, Let's Encrypt, nginx, and DigitalOcean to terminate HTTP and proxy requests to arbitrary hosts. The intended use case for this is to have Github Pages sites able to be dropped onto a custom domain that is SSL enabled, but there are many other use cases which I haven't experimented with (yet).

I was, primarily, interested in exploring using Ansible and DigitalOcean. It worked out quite well http://hoverbear.org/ is running on it at the moment!

Unlike most of this blog this post is not technical in the slightest, instead it's a personal update. Though, I have been wanting to write this post for a long time now!

Many things have happened in the last few months, and life is still swirling all around me. Many things seemed uncertain, other things still do. Irregardless, things are pretty darn cool.

Anyways, here's what's happened lately.

This is the fifth part of an ongoing series on configuring a new server. In our last post we discussed and configured some basic tools. For all intensive purposes, our 'root' system is complete. What we'll be doing now is building the infrastructure to run containers the way we want to.

Before we get around to setting things up, let's describe the what we're up to.

This is the fourth of a series on taking up residence on a new server. In our last post we talked about how to set up some basic network services like ssh and configure iptables, our firewall. In this post we'll talk about making your server feel like home.

There are a grand number of things we can do at this point to make our time on the machine enjoyable. Take time to evaluate your choices though. This 'root' host is going to be our 'control seat' so it's not going to be doing much more than orcestrating virtualized environments. Once we configure these environments (next post) we'll be using these for any sort of development, deployment, or experiments.

With 'root' our goal is to make a simple set of good, sharp tools to do what we need to do. These are tools like nvim which we installed earlier. If you were following the last host you may have installed mosh as well, which makes our ssh sessions safe from network changes and comfortable against latency.

This is the third in a series of posts about getting settled into a server. First we talked about choosing a server, then we talked about installing a base OS on a dedicated server. In this post we'll discuss configuring, securing, and hardening our server.

In our last post we left our new server in a very, very minimal state. Heck, we didn't even tell it it's own name! In this post we'll talk about configuration. Throughout this process we're going to try to keep things simple and tightly knit. Through most of this guide you'll need to be using sudo or acting as root.

This is the second post of a series on settling into new servers. The first was about choosing a server. This post is specifically targetted at newly acquired VPS and Dedicated servers. We'll talk about installing our chosen distribution, configuring its basics, and familiarizing ourselves with the new metal.

This is the first in a series of posts where we'll discuss the process of obtaining, setting up, and settling into a new headless server. Along the way we'll install Linux, configure firewalls and web servers, set up virtual machines, tinker with system knobs, explore automation tools, and generally have a great time.

In this post, We'll discuss things to keep in mind when searching for your own hosting, things to look for, and the differences between distinctions.

This series is not intended to be a comprehensive guide. These are just the notes and rambling of a hobbyist server admin who's loved tinkering for over a decade. I'm writing these both for my own future reference, and so my readers can suggest improvements! As always, comments are welcome via email.

Late last year I was given an opporunity to participate in the Mozilla Winter of Security 2016! I'm happy to report it was, and still is, super cool. Plans diverted significantly at the very start of the project as it was discovered that the "menagerie" of certificates we wanted to build already existed.

What joy! In order to avoid any "not-invented-here" syndrome problems we pivoted, like a failing startup, and I moved to become a contributor to BadSSL. One of my mentors, April King, happened to already be a contributor to BadSSL and helped me get acquainted with the repository and the maintainer, Lucas Garron.

I was glad to discover that BadSSL is a Jekyll site. I've used Jekyll a number of times for different tasks and really enjoy working with the program. BadSSL is deployed on the Google Cloud Platform and is primarily powered via extensive nginx configurations.

I've begun redesigning my website with my own theme! With school finishing and new employment looming I decided to take the time to make my site truly my own.

This year helped again with Gathering Our Voices. I worked in the same capacity as previous years and had a similarly great time.

Rather than talking at length about events I'd rather share pictures. All of these photos were taken by my friend Geoff Howe. All images are wholly owned by the BCAAFC and you may not reproduce or use them in anything without their permission.

Back in 2014 when I was learning about Docker I got around to making a base image for Arch Linux. It was a really fun exploration and I got to know a lot more about how Docker worked from it. I'd highly suggest trying to make your own sometime!

Docker has matured a lot since, and I've enjoyed following it. I took some time this last week to revisit my Arch Linux image and ensure it's still functional. I wasn't surprised when the scripts continued to work just fine, even after two years.

With nothing broken, I knew I only had one choice. I had to improve it!

I'm happy to introduce the first stable version of my Rust Heroku Buildpack!

Just looking to get your hands dirty? Look here.

The project was a really interesting learning experience about how Heroku does things, on bash scripting, and about multirust, which I'd not used before but now am quite a fan of! (I previously just rustup'd the newest nightly every few days.)

In April, I will be graduating from University. It's pretty darn exciting! Once that's happened I'll officially have a Computer Science Degree with a Networking option, meaning I focused primarily on networking for my upper year studies. I'll be completing my degree with (approximately) a 7.75 (out of 9.00) GPA and I'm pretty proud of that!

I've been placing a lot of thought into what comes next for me, and the only solid decision I've come to is that it's dependent on external factors. The problem with trying to build a plan is that many of the factors I have little control over.

What choices I make, and where my next years take me, will be dependent the opportunities which I am able to seize and which present themselves to me. In the past few years I've been incredibly lucky to have had a grand number of opportunities to engage with all sorts of amazing people and organizations. I'd like to continue that.

I was privileged to recieve one of the early Let's Encrypt beta certificates for https://hoverbear.org. I had an easy and fun time setting it up this evening on my Funtoo Container and wanted to quickly jot down how to!

Evolving How We Learn Systems with Lessons from Programming in the Large

Some bugs are just that+++a one off. A wayward moth that just happens to be innocently fluttering through the wrong relay at the wrong time. But some kinds of bugs aren't like that. Instead, they have risen to superstar status, plaguing veterans and newcomers alike. But what if these aren't bugs at all? What if they are actual deficiencies in safety and robustness offered by the C programming language as a consequence of the degree to which guesswork is introduced. Here we explore a more explicit approach to systems level programming supported by Rust, which we believe will better promote understanding of design intent, and eliminate some of the guesswork. Guided by a set of classic, but still relevant, bugs identified almost 15 years ago by Engler, we consider this in the context of the new generation of students learning about systems in a typical OS course, where students often first encounter these deficiencies.

A selection of images from my trip that I thought I'd share with the world.

If you want to use one of these for anything at all, just fire me an email and ask!

The next few weeks are full of excitement and busy-ness! First up is the Meetup in San Fran (See our planning). I can't wait! It will be so fun to meet many people I've already met in IRC and through the community!

If you'd like to do something, or show me around the city, let me know! I've never been to the USA before, let alone San Fransisco.

After that I'm moving into a new place! A friend and I landed a great location for the next year and we're looking forward to the changes ahead. Once I'm settled in classes will be starting and I have a very busy term ahead!

I've moved my feed over from Ghost to Jekyll! It took several hours spread across several days to transfer all of my posts out of Ghost since it's (experimental) export functionality just dumps a bunch of junk into a JSON document.

In this move most page links should still map to the same thing as before. This does not hold for images, diagrams, etc (but you should have hosted your own copy anyways).

If you're like me and have Mac hardware but run Linux you might also run into the slight annoyance with the trackpad drivers X.org defaults to.

If you haven't explored, there is a fantastic replacement called mtrack that I've had great luck with.

We've also got couple nice working examples! Yes, they're ready to play with!

Can't wait, need code? Visit Raft and check out the examples/ directory!

In preparation for the forthcoming 0.0.1 release of Raft we've taken several forward steps to improve our (already pretty darn cool!) tooling and infrastructure. If you attempt to set up any of these on your own and have issues let me know! I'd be more than happy to help. You can find our .travis.yml here.

We've been resoundingly busy with our Raft implementation after a brief period of calm in the early summer! I'll be posting a few bits over the next weeks to help people both learn Rust, and learn about Raft!

As a result of Raft development two new crates have been put together for general consumption! Both of these are macro-centric and lead mainly by James.

In Rust, function signatures tell a story. Just from glancing at the signature of a function an experienced Rust user can tell much of the functions behaivor.

In this article we'll explore some signatures and talk about how to read them and extract information from them. While exploring, you can find many great function signature examples in the Rust API docs. You can play around on the Playpen.

This article assumes some knowledge of Rust, glossing over a bit of the book should be quite sufficient if you are lacking that but have programmed before.

I've been playing around with a new project that uses a lot of collections of results, for example Vec<Result<()>> and asked some folks on Rust if they new a good way of transforming this into a Result<Vec<()>>.

Turns out, .collect() can do it for you!

Based partially off my earlier article I've set up a repository here that demonstrates how to use Travis CI to build yourself ACM styled PDFs (along with fairly decent looking HTML versions) out of a simple pandoc markdown document!

We've already talked a bit about motors in our previous articles, in this article we'll talk more about motors than the quadcopter as a whole.

In our past articles we've explored some of the basics of the mechanics of Quadcopters. In this article we'll be doing something a bit different and discussing the algorithms behind how the Quadcopter keeps itself stable.

To do this we'll actually be inspecting some of the official Bitcraze Firmware and it's stabilizer.c implementation.

It's okay if you don't know C or understand what's going on in this file, that's part of the purpose of this article!

Most intelligent devices existing in the physical world, a quadcopter included, take input from sensors and act on them in some way, possibly producing an output.

Lately we've been playing with Quadcopters a lot, one of the key components of any copter is it's motors! I'll be writing about motors next, but before that I wanted to share some small, short Arduino 'labs' that you can do either on your own or with your cohort!

All of these 'labs' are as inexpensive as we could manage in terms of parts, with the exception of the Arduino.

So, in our earlier article we talked about Yaw a little but, but we didn't get into details. First, let's take a look at what yaw looks like under simple circumstances, then we'll explain the motion.

This post is less about the mechanics of the quadcopter and more to satisfy those curious about what exactly is on the board.

Here are links to the schematics and component placements:

• Component Placement - Top
• Component Placement - bottom
• Schematics

On the pictures below we'll use the schematic symbols as they are shortest.

Spinnning tens of thousands times a second, four rotors cut through the air with their propellors. Their motion lifts them in unison, for they are connected together. In the center of the apparatus sits a bank of sensors, processors, and a radio acting in concert to control the great flow of air passing over it.

Some ways away, perhaps near, perhaps far, its pilot watches over it. Whether by program or controller, they hold the fate of the airborne being in their hands.

Quadcopters are fascinating marriages of physics, electronics, aviation, and computer science that have only become popular in the last couple of years. Examining them allows us to explore a number of interesting topics.

But first, a bit of an introduction...

One of my favorite features of Rust is iterators. They are a fast, safe, 'lazy' way of working with data structures, streams, and other more creative applications.

You can play along on http://play.rust-lang.org/ and by browsing here. This article is not a subtitute for the documentation or experience.

Twenty five years is a fairly long time, it turns out.

Stepping over the boundary for another year of life brings tends to bring about it a whirl of emotions, at least temporarily. Simultaneously the past, present, and future being about a poignant picture.

I find myself deeply in such a situation, and I have been for a couple months now. I've taken time to reflect on what has happened, what is happening, and what is to come. A few things seemed worth sharing. They may not be relevant to your situation, be the best advice, or make sense to you, but they are what I have experienced.

Don't take everyone seriously.

I did a fair amount of photography and digital imaging in high school. Please, enjoy.

In order to celebrate the new beta release of Rust, and as part of reporting requirements for my class, I'm happy to write to you regarding hoverbear/raft!

Over the past two years I helped the BC Association of Aboriginal Friendship Centres host Gathering Our Voices, the largest annual Youth Conference in BC.

This year, I helped out again! I also teamed up with Science Venture again to host 4 workshops!

Awhile ago, I wrote a First Look at Cap'n Proto. Unfortunately I didn't cover how to utilize it's RPC capabilities. In Rust, this is via the capnp-rpc-rust crate.

Let's do that!

Rust is probably my favorite programming language (as the contents of this site suggests). My interests in networks, development operations, and systems programming align strongly with Rust. They're pursuing the trifecta: Safe, Fast, Concurrent. It's been a great learning journey for me so far and I learnt to write better code in all languages.

Github Pages is Github's very generous offering of web hosting to your projects. Basically, you create a branch gh-pages and push it to Github, then browse to https://$USERNAME.github.io/$REPOSITORY.

One of my next goals in my Raft project is to tame the tick() with mio. In this post, we'll explore what it is, what it can do, and why it matters. First things first: What is MIO?

MIO is a lightweight IO library for Rust with a focus on adding as little overhead as possible over the OS abstractions.

I've been following the story about the proposed bill C-51 for a couple weeks now. When the Conservatives introduced the bill I was quite unimpressed with it's lack of oversight, among other things I heard and read about it. I expected it would change due to opposition, so I did not look much further into it.

When the Liberals decided they would support the bill I was suprised, but was busy with midterms, so did not get a chance to look more deeply into the content of the bill. But I couldn't help but be reminded of what Trudeau said about the attack on Parliment months ago:

We are a proud democracy, a welcoming and peaceful nation and a country of open arms and open hearts. We are a nation of fairness, of justice and of the rule of law. We will not be intimidated into changing that. If anything, these are the values and principles to which we must hold on even tighter.

Our dedication to democracy and to the institutions we have built is the foundation of our society and a continued belief in both will guide us correctly into the future. Staying true to our values in a time of crisis will make us an example to the world.

Criminals cannot and will not dictate to us how we act as a nation, how we govern ourselves or how we treat each other. They cannot and will not dictate our values, and they do not get to decide how we use our shared public spaces.

As you may have previously read, I've been working on implementing the Raft Distributed Consensus Algorithm in Rust for my classes (and fun!).

I've spent the majority of my free time this last week working on Raft. As you can see from this issue I've been mostly working on the idea of transactions.

A lot has taken shape in the codebase. It still will panic at unimplemented!() about 300ms after you start a node, but "That's a feature!"

Note: All interfaces and code are not final, and are for educational and interest purposes.

So, I found this (this, and this) Cap'n Proto library for Rust and wanted to explore it a bit. Unfortunately the documentation is sparse for the library, and I haven't played with Cap'n Proto before.

Cap'n Proto is what's billed as a 'Data Interchange Format' and 'Capability-Based RPC System'. Or a 'Cerealization Protocol'.

TL;DR: I've made Hoverbear/raft publicly available (It's still not ready)! Feel encouraged to contribute feedback or code via Github or email!

I've been working quite a bit on my Raft implementation over the last few days and I must say it's been quite a pleasure to work in Rust, which recently released it's 1.0.0-alpha.

It takes the work out of needing to serialize and deserialize data, it enforces data safety, and it's type checking is incredible. I'm very quickly able to make a change, build it, fix the errors the compiler catches for me, and build again, then test. So far the only times my tests have failed after a successful build was when I was accidently disgarding one of my channels.

I'm currently working on implementing the Raft Distributed Consensus protocol in Rust.

This is a project I'm doing for my CSC466 class at the University of Victoria, and I'm hoping to use it as part of one of my projects for CSC462.

At the end of the project I plan to release it as MIT licensed code. Please stay tuned...

Using the setup from my last two posts, let's play with some QoS parameters and observe the results.

The documentation for OpenWRT's QoS is rather lacking, please feel encouraged to improve it as you go!

In my last post, we explored how to set up a OpenWRT VM in VirtualBox.

Let's give it some clients! Since the router is using a intnets we need to configure some machines to use that as their primary way to connect to the internet.

Since Vagrant has support for multi-machine configurations and gives us minimal builds of machines, we'll use this for our clients.

For my CSC 467 project I'm studying the configuration and performance of various QoS parameters in OpenWRT.

The plan is to set up an OpenWRT router in VirtualBox and orcestrate some Vagrant boxes to create a VM network.

At Simbioses Lab, we've been recently looking at the federated authentication DACS as well as Keycloak. I've previously written about Keycloak, so let's take a look at DACS.

I was reading about the Docopt project the other day and really liked the standardized approach to --help prompts and argument parsing that it offers.

Luckly, there is a Rust Package to play with!

A really 'cute' problem popped up in our Data Structures & Algorithms homework and I wanted to write about it.

If you're in the class this will obviously ruin the fun, so read it later, after you're done!

An initialization system's main interface with the user is through it's configuration scripts and service files. Let's take a look at what this looks like for systemd and OpenRC.

With systemd, daemon configuration is handled by .toml configuration files. With OpenRC, this task is performed by shell scripts.

Whipped up an OpenRC script for Ghost. Feel free to use it for yourself.

Things to be aware of:

• The script was designed for Funtoo.
• The script expects Ghost to be in $GHOST_ROOT.
• The script runs Ghost as $GHOST_USER:$GHOST_GROUP.
• The script exports the $NODE_ENV to production.

In this post, we'll look at how runlevels work in two major init systems, systemd and OpenRC. If you're interested in trying out systemd, I'd suggest using an Arch Linux Live ISO. For those interested in trying OpenRC, check out Funtoo. Both of these will work great in your favorite virtualization solution.

One of my projects over the upcoming semester is to explore the Linux boot process and the job of the init (initialization) system. The init system is considered PID 1 and is responsible for a significant portion of userspace functionality. Common init systems on Linux are OpenRC and systemd. One of the key parts of an init system is to spawn new processes, like in command shell.

Executing child processes may be useful to any number of programs, but common applications include:

• Shells
• Init systems
• Launchers
• Interfacing with command line applications

One common monadic structure is the Option (or Maybe in Haskell and other languages) type. This can be seen as an encapsulation type. Consider a function which may fail to produce a meaningful value for certain inputs. For example,

fn main () {
  // Parses a string into an integer.
  from_str::<int>("4"); // A valid input.
  from_str::<int>("Potato"); // Definitely invalid.
}

While using Keycloak you may need to make authenticated requests between various services. How can this be accomplished with Immutant?

You may want to check this link to learn how to use Immutant with Keycloak.

In my past two posts, we took a surface level look at Immutant then took a look at deploying immutant applications to the Wildfly application server. This time, we'll take a look at how to integrate Keycloak with an Immutant app, again using Docker heavily.

If you haven't read the previous few articles, it might be useful to give them a quick glance over.

Currently, the tutorial on deploying to Wildfly with Immutant 2 is not written. Furthermore,the JBoss documentation isn't particularly tailored towards Clojure applications.

So, let's take a look at how to do this using the convenient dockerfiles provided by the JBoss project. We'll use Docker to simplify deployment and setup of Wildfly, but instructions for a non-docker application should be similar.

Create a basic Immutant application.

Starting from a lein new app learning command, set up your project like so:

Problem

You need a base image of Arch Linux that you're sure is a-okay.

Immutant is suite of Clojure libraries that is part of the JBossAS/Wildfly ecosystem. Great, fantastic! Clojure is a lisp that runs on the JVM, the CLR, and compiles to Javascript. Lets get started!

Some links we'll need:

• Immutant - The framework.
• Clojure - The language.
• Leiningen - The package manager.

I've been exploring the handy async over the last few days in the lab. One of my projects is a MongoDB API Adapter in Node.js and I was pleased by a novel way of handling control flow.

async.auto() is a function offered by the libary which allows you to declare a set of tasks and their dependencies, then the library determines the best way to compose the initialization.

I played dual roles for Gathering Our Voices 2014. One role was with the B.C. Association of Aboriginal Friendship Centres, and the other was with Science Venture.

The purpose of these conferences is to unite youth from throughout the country in learning, healing and sharing and to provide tangible experiences of tools, resources and knowledge that the youth can bring back to their communities.

The conference had 1800 delegates and over 2000 participants.

I helped plan and host the 11th Gathering Our Voices Aboriginal Youth Conference in Penticton, British Columbia. Much of my time was spent learning proper software design and refining the management and registration software I developed. This was my first 'real' software project.