Making Nachos: A Material Chips Library for Android

On the Hootsuite Android team, we recently found ourselves looking for a library that implemented material chips. Unfortunately, most of the libraries that existed were extremely tightly coupled to providing chips for contacts, and we didn’t need any of the contact-related features. All we needed were chips that contained text and an optional icon, and a TextView that could provide suggestions for the user as they were typing. Unable to find an existing solution, we decided to write our own library and open-source it: Welcome to Nachos.

A terrible (but relevant) joke.
A terrible (but relevant) joke.

Continue reading “Making Nachos: A Material Chips Library for Android”

Our Path from Monolith to Microservices

How our Lack of SQL Joins and Foreign Keys Aided Us in Our Journey

“We don’t have foreign keys in our databases at Hootsuite.”


My friend practically choked on his coffee. I gently patted him on his back as he bent over and coughed, his eyes nearly popping out of his head. I felt a strange surge of excitement at his reaction, much like the kind of excitement one gets upon telling a child Santa Claus is not real. Not that I would ever do that, of course.

“We also don’t do any SQL joins,” I said.

“What?!” he spat, “Okay sure fine yeah okay but why would you not want to enforce correct data?! This is so absurd!”

He gripped his head and looked at me, fear and confusion in his eyes (and a bit of coffee on his shirt, unfortunately). After believing something for so many years, how could anyone come along and say anything otherwise? How dare anyone deny the truth? Unless, maybe.. The truth has been a lie all along?

“Are you going to tell me why?”

“Nah, you’re gonna have to wait for my blog post.”

Continue reading “Our Path from Monolith to Microservices”

Step-by-Step VRT with Mugshot

During my co-op, I was given a specific task: implement a visual test suite to check that the parts that make up our Analytics app don’t fall prey to unexpected styling changes. In this article, I will be talking about what tools I used, the contributions I made to them, and what challenges I had to overcome.

What are visual regression tests?

If you are a newbie to testing, I advise you to carefully read this article that one of our previous co-ops wrote.

In short, every functionality of a product should be covered in tests. Mainly, there are three types of tests:

  • Unit: covers small parts of the app logic
  • Integration: checks the interoperability between those parts
  • End-to-End: tests the full functionality of the app

With these in place, we’re sure that our product is up and running and no developer can break the code. But what about the style? Visual regression tests ensure that the way a product looks does not regress over time.

This requires running the app and taking “pictures” of the components that build it. This process has to be run at every change in the code, and each time the image must be compared to the one made before. That is how you make sure that nothing unexpected has changed, like one very liberal CSS selector that affects components that we’re not aware of.

Continue reading “Step-by-Step VRT with Mugshot”

How to Build a Service Oriented Data Pipeline

Has this happened to you?: An Account Manager comes to you in a panic. They’ve just lost their most important client, but the Account Manager had no idea they weren’t happy, as they had no insight into how the client was actually using the product. To make sure the Account Manager doesn’t get blindsided like this again, you want to build a tool that allows them to check in on the health of their accounts.  The backend will be built as a data pipeline – a series of jobs to collect, clean, enrich and aggregate data. But what should each job do? How will you run them in a robust way, with proper dependencies between jobs, re-runs on failure, and alerts raised when necessary? How will you handle different jobs requiring dramatically different architecture and tools, while keeping the code simple and the system cohesive?

In this presentation, given at Applicative 2016, we’ll look at the challenges we’ve faced scaling Data Analytics at Hootsuite, and how we’ve moved from a monolithic project that was becoming unmaintainable to a series of very small, loosely coupled jobs connected by a communication layer, stealing ideas from Service Oriented Architecture.
We’ll actually build a simple data pipeline for our imaginary Account Manager, constructing it as a series of Scala apps, deployed to AWS Lambda, stitched together using Airbnb’s open source Airflow tool. If you want to build something similar, feel free to steal the code as a starter project.
About the Author
yasha podeswaYasha is a Software Developer on the Data Lab team at Hootsuite, where he builds software to help the Product and Business teams make data driven, customer centric decisions. Originally an Oceanographer, he got into Software Development through scientific computing, and is an avid fan of oceans, hockey and delicious beers. Follow him on Twitter @ypodeswa.

Designing React components is easier with Cosmos

React has become the king of Javascript UI frameworks, with a tremendous rise in users, and reaching no less than 50000 stars on Github. It’s easy to see why: it allows building truly reusable UI components more easily than other competitors. It is also fast, sturdy and reliable.

All of the benefits of React – when combined with a single-page web app – can, however, lead to complications. Specifically, in the process of building a new component, you might feel the need to get visual feedback on it, for either styling or debugging matters. For example, previewing a button. Nonetheless, building and starting your entire application just for previewing that button is a slow and unnecessary process. This becomes more and more complicated if you’re using many components that have intricate relationships between them.

Read on to find out how we managed to solve this kind of problem and also how we improved the overall design experience for React developers.

Meet React Cosmos

react cosmos

In Hootsuite’s Bucharest office our front-end developers use a great open source tool for designing React components called React Cosmos. This DX (developer experience) tool provides your project with a powerful environment, in which you can easily:

  1. Render any of your project’s components under any combination of props and state – so you can easily see the output for a given input
  2. Observe how it reacts to prop changes in real-time, in a 2-way manner:
    • Edit the props/state and see the component update
    • Interact with the component and see its props/state change
Cosmos is a great tool and it helps frontend developers like me every time we need to create a new component or tweak something to an existing one. Being an open source project, Cosmos aims to make it easy to integrate it in any other project. To do that you only need to write some fixtures for your components. A fixture is simply a snapshot of the component, a serialization of its state and props at a given moment. Then, point Cosmos at those fixtures and you’re ready to go.

Continue reading “Designing React components is easier with Cosmos”

Dashboard Code Growth: Monolith vs. SOA

About three years ago, the Hootsuite Engineering team began a transition from a monolithic application to a services oriented architecture. While the journey is ongoing, we have come a long way from learning how to build services at all to efficiently delivering new customer value on top of a constellation of services.

This post shares what our journey has looked like, what we’ve learned along the way, and how key metrics have been impacted.

To gauge our progress we have tracked a number of relevant metrics:

  • Production lines of code in monolith vs SOA
  • Services in production
  • Team size
  • Reliability
As the data shows, there have been three distinct phases in our transition to SOA. This post goes into detail on each phase.

Continue reading “Dashboard Code Growth: Monolith vs. SOA”

Mobile Compose Refresh Architecture

If you’ve ever posted to a social network from Hootsuite’s iOS or Android application, then you’ve used the composer. The composer is where you write the message body of your post, maybe attach a video or GIF, and select the social networks to send it off to.

The code behind message composition, however, has grown unwieldy. The main activity on Android is somewhere in the order of 3,500 lines long. When it comes to implementing new features, it is difficult to add to and easy to break. As Publisher’s mobile team looked to revamp the design, refine some features and add others, developing a new architecture for message composition was the clear first step.

Hootsuite's Composer Window for iOS
Hootsuite’s Mobile Composer Window

Continue reading “Mobile Compose Refresh Architecture”

The Black Hole in the Source Code

At the centre of most galaxies lies a supermassive black hole. Similarly, at the heart of many existing codebases lies a supermassive tangle of legacy code. One of these phenomena is hard to understand: it seems to defy the laws of physics, and sucks the life and energy out of anyone who approaches. The other is a black hole. In this post, I will compare these two mysterious concepts and suggest some strategies for dealing with legacy code that are inspired by some of the postulated solutions to the black hole information paradox.


Continue reading “The Black Hole in the Source Code”

An Introduction to Javascript Modules and Bundling


A module is a way of dividing or grouping your code into files or sections. Modules are ideally self contained and decoupled, so that changes can be made in a single module without having to rewrite other modules.

Why Use Modules?

Modules have a number of benefits including namespacing, better maintainability, and reusability.

Without modules, it’s very easy to get namespace pollution because all variables outside of top level functions are global and accessible everywhere in the code, even if it’s unrelated. Modules allow namespacing, which creates private variables to reduce or eliminate this pollution.

Modules also allow for decoupling of unrelated code. This means that changes in one file should not require changes to be made in other files, resulting in more maintainable code.

Modules allow you to import and export a single module, so that it can be reused as many times as you would like without duplicating the code. This is great because it means that any required changes will only be needed in one spot, instead of all the potential duplicated places.

Image courtesy of Librato
Image courtesy of Librato

Continue reading “An Introduction to Javascript Modules and Bundling”

Writing Kotlin Idiomatic Code

Kotlin, a new JVM language created by Jetbrains, is quickly becoming the go-to programming  language used for Android development at Hootsuite. Its many features and Java interoperability make writing code much faster, cleaner, and less verbose. However, without being aware of language idioms it can be easy to fall back to old Java patterns. In order to maximize the utility of this new language, it is important to familiarize yourself with writing idiomatic Kotlin code. Kotlin’s features, such as the nullable types, lambdas, and delegates, differentiate the language from Java and are useful for writing effective code.


Continue reading “Writing Kotlin Idiomatic Code”