Posts from September 2016

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.

Read More …

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.

Read More …

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

Read More …

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.


Read More …


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

Read More …