Posts from September 2015

We have a norm for onboarding new engineers on Day 1: Push to Production. This norm is a powerful experience for our new people and a litmus test for our systems.

Simon Whitfield pushes to Production

The Experience and Why it’s Important

Pushing to Production on Day 1 is a small and early exposure to an engineering culture that values learning, trust, collaboration, and a bias towards thoughtful action.

Always Be Shipping. As software engineers, this our role, this is why we’re here, this is how we make an impact and help others – like our customers.

This is a hands-on experience. There is an important difference between passive learning and active practice. Reading a wiki page or diagram about deployment steps and hearing our philosophy of “anyone can deploy to Production at any time, from anywhere in less than five minutes” develops knowledge. The act of deploying helps someone understand how to change our product and how it feels to make that change.

This shows the speed at which we operate. Continuous Delivery – shipping to Production multiple times per day – means we can get something useful into the hands of our customers very quickly. We pushed 2015 times in 2014, an average of 8 times per day.

This says ‘we trust you’. Our engineers are responsible for delivering code the last mile and accountable to how it affects our customers. We try to convey the magnitude and gravity of shipping to Production, but at the same time, remove the fear of deployment. Read More …

At Hootsuite, we process millions of social messages every day. We strive to keep our service stable and secure, and rely on open source projects such as Scala and Akka to achieve our goals. We are excited to contribute back to the community today with a Redis plugin for Akka Persistence.

So what is Akka and how is it useful? Akka provides means to make a distributed system scalable, asynchronous, and fault-tolerant. It achieves this by sending messages among lightweight processes called actors. These actors only communicate through Akka’s message delivery mechanism such as mailboxes and certain level of delivery guarantee. This allows developers to concentrate on actor behaviours, and not on message delivery. This is certainly the use case at Hootsuite. Most of the time, we focus on defining actors and trust Akka to deliver those millions of messages.

New Redis plugin for Akka Persistence
New Redis plugin for Akka Persistence

Read More …

Our Build Metrics

Hootsuite extensively uses continuous integration (CI) technology like Jenkins to handle the building and deployment of its codebases. Several different Jenkins servers handle codebases for our software products. CI ensures that updates to our software are integrated smoothly, allowing us to release code at a fast rate: deploys to production happen several times a day.

At the end of June, our build metrics service collected build data for just one of our Jenkins servers – the one responsible for building and deploying updates to the main Hootsuite dashboard. This service scraped data from the Jenkins API and stored it in our metrics database. To get any relevant information about the health of the build pipeline an engineer would need to learn the schema to manually write queries. This is cumbersome so we built an internal web interface that gives a snapshot of the health of the process through data visualization of statistics. Using this, any engineer can easily see the health of the build pipeline and see if something is going wrong. Our Build and Deploy engineers are also able to quickly assess whether or not the build pipeline needs improvement.

A a clear picture of the health of this build and deploy process and whether or not it needs improvement.

The Problem

Our internal build metrics service worked like so: every 15 minutes, a Ruby script scraped data from the Jenkins server and stored it in our metrics database. While this is a reasonably reliable method for obtaining data, it left  a lot of room for improvement: Read More …

For any Grade 12 student the idea of university can be daunting: “which university should I apply to/accept?” or “what field should I study?” The hardest decision I had to make was choosing between University of Waterloo’s Software Engineering Co-op program and University of Toronto’s Computer Science program. I’m currently in my senior year, enrolled in University of Waterloo co-op program, and I regret nothing.

Paul Kim

4 Flavours

In my experience, first-year was the toughest year – new people, new learning environment, and endless freedom – no one is there to scold you for skipping 8:30AM classes. The most challenging part for me was that I had to land a co-op placement for summer. This meant that I had to juggle my time between 6 courses of school work and interviews, which was very overwhelming. Not only that, but my resume wasn’t very impressive; I had zero work experience, and only some knowledge of Java and C++. Not surprisingly, I had trouble getting employed for my first co-op term. But, as they say, you learn from your mistakes. Read More …

Our newly-formed Technical Project Management team has been busy spreading the Agile gospel throughout our Engineering department, and we’re excited to announce the next Agile Vancouver Meetup will be taking place at Hootsuite offices!

On September 21st, 150+ Agile enthusiasts will gather at Hootsuite’s HQ1 to hear guest speaker Su-Laine Brodsky talk about incorporating UX design into Agile methodology. This event is free and open to all members of the Agile Vancouver Meetup group (which is free to join), but an RSVP is required. The event is filling up quickly, so if you’d like to meet other Agile users and explore the critical challenges in incorporating UX design into Agile, sign up today.

Agile Vancouver

  • Monday September 21st, 2015, doors at 6pm (presentation begins at 6:30)
  • Hootsuite HQ1 – 5 8th Ave East, Vancouver BC
  • Free to attend! Space is limited, so RSVP here (free membership required)
About Agile Vancouver:
Agile Vancouver kicked off in October, 2005 with a presentation by Alistair Cockburn. Since then it has featured speakers on a regular basis with a usual turnout of over 50 software developers and managers. The group continues to flourish and feature presentations and courses from leading practitioners around the world.
About Su-Laine Brodsky:
Su-Laine Yeo Brodsky has experienced software and website development projects from various perspectives: primarily as an interaction/user experience designer, and also as a technical communicator, sales engineer, and provider of B2B technical services. She has worked for over 15 years in the industry, designing sophisticated products ranging from video production software to school administration systems.

Whenever I tell somebody I study user experience (UX) design, I usually get blank stares. It’s a fascinating field because good design tends to be invisible, but when products aren’t designed with people in mind, that’s when the term ‘usability’ comes up in a conversation. UX design is the human component in technology that aims to make products approachable and relevant for regular people.

I’m now a senior at Simon Fraser University, enrolled in the design program. Of all the decisions I’ve made that have led to where I am today, I’m convinced that the best decision of my academic career was getting work experience early on. The tech industry moves at such a pace that universities can’t adapt their programs fast enough to prepare students for the future ahead. School is great for learning theory, but internships offer an opportunity to apply those concepts in addition to providing invaluable practical experience.

It's all about the people
It’s all about the people

Design for Real People

As designers, we’re taught to create experiences that are as simple and as elegant as possible. During that process, it can be easy to forget that we’re designing for actual people, not abstract personas. In school I often had to imagine who my user was, and likewise I made a lot of assumptions such as: all users having perfect vision. Early in my co-op, I had the opportunity to attend an interview with a sight-impaired customer. To navigate our site, this person had to use a third-party screen reading app called JAWS. In short, performing even the simplest action took a huge amount of effort. I learned that accessibility is important, and that it should be accommodated in the the beginning of the design process rather than leaving it to the end.

Read More …


Handling orientation changes on Android is one of the most frustrating things to deal with as an Android engineer. I hope to make that challenge just a little bit easier and to help you better understand exactly what’s happening when you rotate your Android device. I’m going to cover what not to do when handling orientation changes, and what you should do in some common scenarios including dealing with Fragments, AsyncTasks and ListViews.

Android Orientation Changes


When you rotate your device and the screen changes orientation, Android usually destroys your application’s existing Activities and Fragments and recreates them. Android does this so that your application can reload resources based on the new configuration. When it destroys your Activities and Fragments it will end up creating new instances of them which will wipe out all of your member variables. To work around this, Android gives you the opportunity to save your app’s state before destroying your Activities and Fragments, and the opportunity to restore your state when recreating them. Proper handling of orientation changes centers around saving this state and also avoiding memory leaks.

While it may seem a bit tedious to implement, handling orientation changes properly provides you with several benefits: you will be able to easily use alternate layouts in portrait and landscape orientations, and you will be able to handle many exceptional states such as low memory situations and interruptions from incoming phone calls without any extra code.

Read More …

What makes Futures so great?

If you’re coming from a lower level language, you might be accustomed to using threads and processes to perform tasks concurrently. In Scala, there exists a concurrency construct that works at a much higher level called a Future. A Future represents a value that will be available in the future, or the exception that occurred while evaluating that value. So, what makes Futures so great? A Future is a concurrency abstraction that represents a future value and comes with a very powerful and convenient API that lets you deal with that future result in a type-safe and high level manner. A Future can be in three possible states: it can either be scheduled/running, failed, or successful.

M is for Monad

Like many things in Scala, a Future is a monad (yes, the scary ‘m’ word). Some like to define monads as “a monoid in the category of endofunctors” (whilst this definition may be helpful for those of you strong in Category Theory, I’ve found this James Iry’s blog post less intimidating for understanding the basics of Monads and their motivation.

The Future monad is a container that holds the result of a concurrent computation, and information about whether it succeeded or failed. Read More …