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.
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.”
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.
- Data cleaning and processing job
- Statistic calculation job
- Airflow, a tool for building data pipelines
About the AuthorYasha 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.
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
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:
- 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
- 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
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
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.
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.
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.
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.