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 →
Continuous Integration (CI) and Delivery (CD) are a core processes within our engineering team. CD is hard to get right, and we pride ourselves on following best practices. In the cultural sense, we imbue the central values and DevOps culture in general: continuous improvement, tight feedback loops, automation, education, blamelessness, and autonomy.
In fact, it can be argued that CI is an absolute baseline requirement in modern software development. It is the hub for all spokes that make up engineering (devs, ops, QA, management). The build and release pipelines are therefore a mission critical production distributed system, and should be treated as such. But what happens when the pipeline (or parts of it) goes down? Important fixes can’t be pushed out, developers get blocked, visibility is lost, and everyone notices. Worse, when the problem is resolved, the commits have piled up and an important tenet is broken: small incremental changes vs. large deployments.
When starting out as a monolithic app developed with a small team, you can easily get away with just configuration management and a simple build server (eg. Ansible & Jenkins). But as time moves on, the product, team and company grow, and that monolith is half way transitioned to a handful micro-services.
Last ½ year we took a step back to look at things with a bit of perspective. We can’t just hire someone to monkey around with Jenkins and expect our growth problems to go away. A deeper re-examination and contemplation of the current issues (and future requirements) needs to take place. With a solid design philosophy, implementation more easily falls into place and decisions are made within the proper context. So, in the spirit of openness, we’re opening up our dev process in the hopes that we get insights from unexpected places and that we unexpectedly help others by providing lessons learned.
Read More →
So you’ve written this great new feature and you can’t wait for your customers to see it. The tests are passing and it looks good on your laptop. Now you just have to get it out in the open – but how do you do that?
The answer is the deploy system – the process of making the technology we create available to our customers, in the shortest time possible, checking that no bugs are caused in the process. There are many possible ways to build and deploy software, each with their own merits. Focusing time and attention on an effective build system means delivering functionality customers as opposed to losing time with processes that could otherwise be automated.
Over the past few months, we’ve been working on a new deploy system for Hootsuite Analytics. We can’t stress enough how important this process is – without it, we’d have great products that nobody would ever see. Having millions of customers, we want to be able to quickly and safely release new changes to all of them – this requires a deployment system that is consistent, fast and finds as many issues as possible before shipping out changes. This post describes our move to a Blue-Green deployment system for our Hootsuite Analytics product.
What exactly are we deploying?
In order to understand our needs, let’s go a bit through what we need to deploy. There are two main components – the web servers (we also call them web nodes) and the data processing pipeline. This post is all about the web nodes, so let’s focus on those. They are what customers directly interact with, so besides having to be up all the time, we cannot have any interrupted requests. This makes deployment a bit tricky, because we need to be sure that a server is not shut down while replying to a request.
Read More →
You’ve heard the stories – mid-day Nerf battles, golf carts in the office, plaid shirts as far as the eye can see – but have you ever wondered what it’s REALLY like inside Hootsuite? Do we all have dogs and matching beards? Does craft beer run through our veins? How well do we code during yoga time?
Get answers to these questions and many more on August 12th during the #hootjobs Twitter chat!
What is #hootjobs?
At Hootsuite, we do a lot
of hiring. A few months ago, we launched #hootjobs on Twitter as an easy, interactive way for people to engage with our recruiting team. Prospects, job seekers, and the curious are invited to ask questions about job openings
and life at Hootsuite, with our Talent team on hand to answer. This week is our first Departmental Spotlight and your chance to meet some of our Engineering team as they showcase their work, the people, the culture, and more.
Let’s Talk Engineering @ Hootsuite
On August 12th, Beier Cai
and Geordie Henderson
will be online to personally answer your questions about life in Engineering at Hootsuite. Beier is our Director of Technology (and was Hootsuite employee number 3), while Geordie is the VP of Engineering. What’s the difference? What are they looking for when they interview potential engineers? What do new hires work on when they start? Find out what you want to know.
All hands on deck for the Hootsuite Instagram launch!
How Do I Participate?
The special Engineering edition of #hootjobs takes place on Wednesday, August 12th, between 12 noon and 1pm PDT on Twitter. Be sure to follow @hootsuitelife
, and use the hashtags #hootjobs
to follow along. You can expect a lively discussion about Engineering at Hootsuite, the positions we’re recruiting for, and a few secrets along the way. Hope to see you there!
With iOS 8, Apple introduced a number of app extensions such as the Share and Today extensions, as well as WatchKit extensions for interacting with WatchKit apps. To facilitate building these extensions, Apple introduced a new (to iOS) type of framework called an embedded framework. The typical use cases Apple has shown for using these frameworks revolve around projects where the embedded framework’s code is included in the same project as the code that uses the framework (e.g., an app with a Share extension packaged up as an embedded framework residing in the same project). What hasn’t been quite as clear is how one can distribute these frameworks when the framework’s parent project and the framework consumer’s parent project are not the same project.
At Hootsuite, as we create new apps beyond our flagship iOS app (such as Suggestions by Hootsuite), we’ve become interested in sharing code between our apps as well as between our individual apps’ main target and their various extensions. For example, many projects (including the main Hootsuite iOS app) define their own branded fonts and colors in a category on UIFont and UIColor. Replicating this across several apps, each of which has several of its own extensions, quickly leads to duplication of this code many times over. The same can be said for common networking code, custom UI elements, etc. These new embedded frameworks appear to be a great way to share such common code across projects.
Read More →
“You must feel the Force around you; here, between you, me, the tree, the rock, everywhere, yes.” – Master Yoda
The Danger of Team Debt
At her PyCon 2015 keynote, Kate Heddleston explains how a familiar engineering concept – technical debt – applies to any growing organization. Any technical system can accrue technical debt as a consequence of bad design. Heddleston argues that organizations can also accrue ‘team debt‘ as a consequence of bad design: where each person added to your team eventually decreases overall team productivity. Productivity drops because each new addition lacks an understanding about the team’s processes, cultural norms, how to do their job, corporate values, code standards, architecture, and more.
Steve Blank sums it up as “all the people/culture compromises made to ‘just get it done’ in the early stages of a startup.” It’s like death by a thousand cuts – each person’s inefficiencies compound to a point where their time and effort spent navigating your ‘system’ outweighs their time and effort spent shipping code.
This was exactly our situation in our Engineering group two years ago. Our team had tripled in size from 13 to 39 in the span of two years and was slated to double again to 78 in 2014. So much of our ‘just get it done’ approach lead to misaligned expectations and lack of understanding of our code base, our practices, and our culture. Symptoms of the problem trickled in to me periodically, but the depth of the situation really hit home when someone I had hired resigned and cited some of these issues in their exit interview.
That event radically shifted the way I looked at introducing new engineers.
Lechon Kirb photo via Unsplash.com
Read More →
The obvious question that initially emerges is WHY? Why bother with all the hassle of migrating the code away from GitHub and maintaining the instances that provide the service on our own?
First of all, GitHub Enterprise offers us a more secure way to store the sensitive parts of our codebase by bringing the repositories inside our VPC. Furthermore, because the instances hosting the code and the ones using it are now much closer together, code provisioning can be done much faster.
Secondly, it is better to have some control over your downtime than to be at the mercy of GitHub (or any other service for that matter), which can lead to canceled deployments or angry developers who cannot pull their code. As frustrating as downtime is, it’s not a matter of ‘if’ it will happen, but rather ‘when’ will it will happen.
We chose GitHub Enterprise over other forms of repository hosting providers, like GitLab, because of the reasons above and because our developers were already familiar with the interface, features and embraced the GitHub flow. GitHub Enterprise is easy to update and it had a better API.
Will it stand up in our Production Environment?
Before we could actually start using GitHub Enterprise in production, we needed to see if it could support our blue/green deployment system (more details on this can be read here). This meant that it should stand hundreds of instances that needed to pull their code from the repository, simultaneously.
To test this, we have used two r3.xlarge memory optimized instances, offering 32GB of memory and 4 vCPU, in a replication setup. This is what GitHub recommends for a seat range of 500 to 3000 people.
Read More →
The art of storytelling has existed since the dawn of time, and is one of the few things that has both changed drastically over the years and yet remains essentially the same. Technology has given us the printed word, theatre, movies and television, and more – but it can all be traced back to people gathering together to share experiences.
@mixhellereid shares her story – photo by @ivancouverite
Hootsuite Labs is working to bring Vancouver’s tech community together to share stories about life in technology. Labs is the force behind some of our new products and initiatives such as the new Hootsuite Suggestions app and Hootlet, the Chrome extension that allows you to share content from anywhere you browse, and they’ve been very busy lately: in addition to their new blog, they’ve launched Venture This!: True Tales from the Tech Frontier with Rain City Chronicles. In their own words:
Venture This! is a live event series and podcast featuring real stories about life, love, and work experienced through tech-coloured glasses. Stories are told in front of a live audience, are 100% true, and offer a range of perspectives, from tech tycoons and young upstarts to the adventures and misadventures of total tech newbies. Every night reveals new insights into the strange and wonderful mysteries binding our connected world.
On Monday, June 29th, Venture This! had its inaugural event
at Hootsuite HQ1. The topic was “Rejected!”, and featured storytellers from Vancouver’s large and diverse tech community sharing their stories of rejection in the tech world. These stories will soon be available as a podcast for you to enjoy, but in the meantime, check out the Tech Vibes review of the event
The above is only a whisper of the richness of the personal accounts at the Venture This! event. With humour and honesty, the presentations provided relatable, cathartic, and cautionary stories of adversity, of external and internal origins, and coming out the other side alive.
Don’t miss out on the next Venture This!
event! Sign up
to be notified when the next session is announced, and come hear about the personal triumphs – and spectacular failures – from some of Vancouver’s best and brightest in tech.
Storytelling at Hootsuite! Photo by @mtippett
Picture this: a group of new engineering Owls situate themselves pairwise at temporary desks arranged in our yoga room. With varying technical backgrounds, we ready ourselves for participation in two weeks of Scala & Akka immersion to acquire a certain level of fluency. After reading numerous books on the subject and completing Coursera’s Functional Programming Principles in Scala, what could a Scala & Akka Dev Factory offer us that we hadn’t already encountered?
As it turns out, the course offered more than just a great technical education. Our trainer brought to life the lecture notes, code samples, exercises, and group projects with both social learning practices as well as on-the-fly adjustment of the content in order to reinforce concepts in a really unique way. Some of these techniques included positive reinforcement from daily public code reviews, and pair programming with random partners who had varying skill levels and communication styles. Our daily input into the course also let us shape our classroom experience by driving the expansion of the course topics where we felt we needed it most. These shared learning experiences gave me and my cohort a kaleidoscopic insight into the course material.
June 15/2015 Cohort from left to right: Jonathan, Yasha, Philipp, Jason, Jodi, David, Scott, Mike S., Sim, Mike R., Ryan, Isha Photo Credit: Steve Song
Read More →
Upgrading a session storage system that services 5000 requests/second without downtime is no easy task. As part of continued efforts to harden our systems at Hootsuite, we moved from a legacy Memcached and MySQL session storage to a multiple availability zone Redis setup using Amazon ElastiCache. We ran into some issues along the way, but in the end we successfully migrated millions of sessions to the new system without any downtime. This post describes our strategy, the gotchas, and step-by-step of how we made this happen.
Read More →