Blog

After four months of work, I’ve completed a new coding project!

It’s an interactive fiction game engine. It lets you create text adventures – those games before the age of computer graphics that played like a novel unfolding before your eyes. The player would write what they wanted to do in plain language, and the game would understand that and spit out what happened next.

There are tons of game engines like this out there. I wrote mine because I wanted to write interactive fiction, and I wanted to write it in a way that was intuitive to me. I also wanted to have games playable through a web browser and that could be written in languages other than English.

I created a declarative language for creating the games. Instead of programming the game by specifying what each step was to get to a final result, I made it so I could define rules for how things were related, and the game engine would figure out the rest.

I’m very proud of what I’ve put together. Next up is writing the interactive fiction I’ve been meaning to create and putting that online.

You can download the source code at GitHub.

If you’re interested in writing interactive fiction, I would recommend downloading and using Inform 7 rather than what I’ve put together. Writing stories in Inform 7 is more intuitive to non-programmers, it has great documentation, and is just much more mature of a product.

A few months ago, I disclosed that I had left my job.

I was working for a successful startup that had all the perks. I was issued a $4,500 MacBook Pro, there was beer available at all times of the day and the office was located in downtown Ottawa. On my first week we did ax throwing as a team building activity.

There was about ten people working on our product, and only a dozen in our office. The rest were in Montreal, along with HR and higher ups, or other offices. When I was hired, I was told I was the first person they hired in a year and a half. Another team member was hired shortly after me.

The job was straight-forward, working on the API back-end for point-of-sale software. The workplace, unfortunately, was extremely stressful. The team lead regularly made condescending remarks to me. Questions were met with RTFM. The tickets that the team lead wrote were often just a single sentence and trying to get more info was like pulling teeth. He and his boss continually derided the competency of others. The team lead was unable to accept constructive feedback with his code or design decisions.

Things didn’t improve. In conversations with my boss, I was treated as if it was my problem. With HR and the rest of the office being in another city, there wasn’t any other path out of the situation. I gained 40 lbs in my eight months there just from the stress.

The other person who was hired with me quit on a Thursday. I quit on the Friday. I then found out that three others had quit over my team lead’s behaviour. For my last two weeks, the team lead stopped communicating with me and the other departing employee altogether. Job postings went up a few weeks later.

I took some time off after that experience. I drove across Canada and the United-States with a friend, camping along the way. I spent a week in Vancouver. I worked on my own projects.

I landed a job as an embedded software developer developing air traffic control systems. It’s been good. Everyone helps each other. My team lead facilitates development where he can. People’s diverse skills are recognized and valued. If there’s a lesson I learned during all of this, it’s to quit toxic jobs sooner.

And so life continues.

This post is written in January 2018 and applies only to recreational use of drones that weigh under 35kg. If you’re flying your drone for work or research, or if it weights more than 35kg, you must get a Special Flight Operations Certificate.

Transport Canada has proposed new rules that they expect to become law this year. These rules include age restrictions, passing a basic knowledge test and having liability insurance of at least $100,000.

Drones are not toys

This article covers restrictions on drone use in Canada. These rules are non-negotiable. Irresponsible drone use can endanger lives.

Take the small DJI Spark drone, which has a takeoff weight of 300 grams. If it were to fall from a height of 90 meters, it would impact below with the same energy as a brick dropped from an overpass.

In Canada, a drone collided with a passenger plane near Quebec City. The drone was flying at an altitude of 450 meters near an airport. Luckily, no one was hurt. The Transport Minister noted there were 131 drone incidents which were deemed aviation safety concerns in 2017.

These incidents are preventable by adhering to the rules around drone use. Failure to adhere to these rules could result in up to $25,000 fine and jail time.

Rules

Exceptions to these rules require a Special Flight Operations Certificate. These rules are taken from Transport Canada’s website and Government notice on January 6th, 2018.

You must be:

• Flying the drone for recreational purposes
• Flying during the day

Your drone must be:

• Clearly identified with your name, address, and telephone number
• Under 35 kg

You must fly your drone:

• Within visual line of sight
• Within 500 meters of yourself
• Below 90 meters (300′ AGL)
• Not in the clouds
• Away from vehicles, vessels and the public
  • 30 meters away for drone 250 g – 1 kg
  • 75 meters away for drone 1 kg – 35 kg
  • Includes not flying over open-air assembly of people
• Away from where aircraft are close to the ground
  • 5.5 km away from airports or locations where aircraft takeoff/land
  • 1.8 km away from heliports
  • Outside controlled or restricted airspace
• Away from emergencies
  • Not over a police or first responder emergency operation site
  • 9 km away from a natural hazard or disaster area

Where you can fly

Being away from vehicles and the public is easy enough to tell. For a lot of people, it might be harder to establish if you’re 5.5 km away from an airport or in unrestricted / uncontrolled airspace.

There’s a few maps online to show where you can fly.

UAV Site Selection Tool

The UAV Site Selection Tool from the National Research Council is the best map I’ve found so far as it is the most comprehensive. You want to select the option for recreational drone and it’ll show you everywhere you’re not permitted to fly.

AirMap

AirMap provides just as comprehensive a map as the UAV Site Selection Tool but with an improved user interface.

Canadian Airspace Viewer

The Canadian Airspace Viewer from Telus identifies unrestricted and uncontrolled airspace. You’ll want to set the option to show airspace below 700′. It isn’t as comprehensive as the NRC’s UAV Site Selection Tool.

DJI Geo Zone Map

The Geo Zone Map from drone manufacturer DJI is the weakest of the contenders. They represent restricted or controlled airspace as a fixed radius from a point, when in fact some spaces are polygonal or other complex shape.

DJI deserves credit for making it so their drones cannot fly in the zones they deem restricted, but operators could still fly within restricted or controlled airspace. Do not rely on this map.

Have Fun

Flying a drone is loads of fun. So go have fun!

I gave a workshop at Random Hacks of Kindness on Trans 101 for Coders. RHOK is a bi-annual hackathon. You can view the slides I presented here.

This was the first time giving a talk to a mainly cisgender/straight audience where I didn’t feel like I had to explain who trans, cisgender, non-binary, two spirit people were. Sign of the times.

This talk focused on how to make workplaces welcoming to trans people, focusing on tech companies specifically. Advice like de-emphasizing references and academic transcripts by evaluating prospective employees with real-world coding challenges don’t apply as well to other industries. The workshop had a second theme of discussing software design. Namely, in the vein of i18n, looking at assumptions that developers make around names and gender that are not applicable to everyone and end up creating barriers for trans people.

The audience took it well.

For the rest of my time at the hackathon, I was participating. It actually went super well. The format was simple: on Friday night, the projects from NGOs would be introduced. On Saturday morning, the participants would choose which team to join, and work on the associated project for the rest of the day. There would be a bit of time Sunday morning to develop, and then projects would be presented at noon.

Our team was composed of people having very different skill sets. Everyone compromised in order to put something together. Those working on the back-end had more familiarity with Ruby and Go, but chose Python as the common language because they knew it a little bit. I worked in the front-end despite being more a back-end person, because I thought the back-end was better served by other team members.

In the end, those compromises meant that we delivered a pretty impressive product in a little over a day: a web platform that allowed you to add recipients to a list, to whom SMSs with custom messages of support could be sent at various scheduled times. We had everything done – a functional front-end with a cool domain (http://sendme.love/), a backend that would handle the text messaging, and a test harness for it all.

I was really proud of work. During the presentations, it seemed like our team worked best together. Other projects involved members coming up with multiple solutions, some of them almost indistinguishable from each other. I took that to mean that they couldn’t work together, so members did their own thing. Or a lot of work on a back-end, but no real completed MVP.

This was my second non-work related hackathon, and it gave me taste to do a third.