Posts from February 2016

How do we share our libraries internally?

In 2015, our Android team released v3 of Hootsuite’s app with a new UI following Material Design guidelines. We also gave users the Publisher feature, Instagram integration and enhanced Twitter Search. The development of these features relied on many popular open source libraries and tools, such as RxAndroid, Retrofit, Google Design, Robolectric, and many more. With the success of these libraries, our Android development team was inspired to build our own libraries to allow other teams to consume. A great idea, with a surprising complication: How do we share our library internally?

Publishing libraries to Maven Central using Gradle has been covered before by Chris Banes and others. His solution is visualized in the following diagram.

Chris Banes Maven Gradle

Our need was to be able to publish libraries to a private Maven repository like Artifcatory. We tweaked @chrisbanes‘s solution and made it available to our developers to enable them to write libraries independently and share them between teams.

Hootsuite Maven Gradle

In this post, I’m going to guide you in setting up your library to share your own Maven repository.

The Template Library Project

Most Android library projects share a similar directory structure, so we prepared a Library Template that will act as the reference for this guide. We encourage you to fork this project if you’re starting fresh.

Read More …

Hootsuite Developer Brandon Okert has authored the first in a 2-part series about Docker from a scaling perspective. To give a better understanding of how Docker can be used, Brandon provides a direct comparison between Docker and Virtual Machines, goes over the various components and tools available, and gives insight in managing Docker in the real world. Brandon also discusses prevailing Docker Ideologies and practices (as well as common exceptions), all in preparation for Part 2 of the series which will cover building scalable services with Docker. Check out his blog post, and join the discussion!

scaling

Before becoming a QA Tester, I never fully appreciated software testing. While coding, I wrote my unit tests, made sure they passed, and continued on with my life. When I got the job offer to become a QA at Hootsuite, I took it as an opportunity to learn a piece of the giant world of software testing, and now, knowing how valuable QA testing is, I think any software company without a QA team is missing out.

At Hootsuite, most teams have a dedicated QA person. They do a wide variety of things, from testing tickets, to automating the features, to creating tools for the other QA’s to use to do these things, and so much more. The QA’s here fit into the teams just like developers do. We have tickets that are created specifically for us to automate important features, and we participate in estimating how much effort is required for tickets.

You Mean to Tell Me You Can LEARN Things as a QA?

On the iOS team, we test every JIRA ticket that goes through every sprint at least once. Testing a ticket involves coming up with test cases, testing the cases on devices, and eventually automating them. Most of the time we automate a feature before it is released, but sometimes we only automate after being released. Once a feature is completely done, we go through and test each case again to ensure everything runs smoothly.

Test Cases, Test Cases Everywhere

At the bare minimum, a test case needs to cover a common or critical use path. More test cases are required to also cover edge cases and integration. Edge cases are less common use paths while integration tests are to make sure the feature interacts correctly with other features in the app. These are all important to test because we want to ensure a user can’t get our product into an unusable state. Key testing in these areas could be overlooked if we didn’t know our product inside and out. Missing any one of these cases could cause large bugs to reach users, which is never good for anyone. Repeatedly testing key features increases our knowledge of the app, which allows us to do risk analyses to figure out which features could be at risk with any new changes. Being able to pick out these features saves us from having to run a full run through of the app, usually referred to as regression, for every ticket, which is where automation comes in.

Most of our test cases are automated, but those that can't are tested manually.
Most of our test cases are automated, but those that can’t are tested manually.

Read More …

At Hootsuite, we perform penetration tests to ensure that our software and services are secure and compliant. Penetration testing (or “pen testing” for short) is a security process in which the tester attempts to exploit software using security vulnerabilities. The goal of our pen testing is preventative: to find as many security vulnerabilities in our products so that our development team can fix them.

In the field of security, there is more than one type of hacker. A hacker is categorized based on their motivation: Black hat hackers are those who seek to exploit software security vulnerabilities for malicious intent, White hat hackers are those who hack in an ethical way and try to to avoid causing damage the systems they attempt to penetrate. Pen Testers are White Hat hackers. By understanding the mindset of black hat hackers, white hat hackers can give organizations insight on how to further harden and secure the organization’s infrastructure to reduce security threats.

A Bird’s Eye View of Pen Testing
A Bird’s Eye View of Pen Testing

Read More …