Product

Airtame is a wireless streaming device which helps people work better. It’s powered by embedded Linux on custom-built hardware, with a diverse software stack ranging from our carefully-tuned firmware and high-performance C++ streaming engine, to our cross-platform Electron/React desktop application and Golang Cloud platform.

Technology

How do you make video streaming with high quality and low latency work in poor network environments? How do you integrate four different operating systems? How do you scale cloud backend to support tens of thousands of concurrently connected devices? These are just some of the many difficult challenges we face every day, and we work hard together to solve them. It’s an exciting opportunity to work alongside software, hardware and firmware deliverables with tasks that aren’t repetitive.

We have experts across the entire spectrum of technology. It gives everyone the chance to learn what they don’t know and challenge their own way of thinking. More than that, it’s a unique spread of technical knowledge, something we put it to good use every day working with the complexity of the product. Team structures are fairly flexible, and we’ve had several people start working in a specific range of activity, then gradually move to other areas of problem-solving.

Our talented engineers work with different tools, languages and types of infrastructure, and they are driven towards producing high-quality, maintainable code and software. Frequent code reviews, linting, and pairing are all integral components of our engineering culture. Significant ownership and responsibility over projects is key to our organization. Every developer is able to have a an impact on the direction of the product, and the company as a whole.

Our engineering teams

Streaming team:

In charge of the high-performance streaming pipeline, written in C and C++. And our cross-platform Application, made in Electron and JS.

Cloud team:

Working on the cloud-based administration portal for the Airtames and our upcoming internal digital signage platform called Homescreen. The tech stack here is Golang, React, AWS.

Firmware team:

Leading the efforts on the OS running on the Airtame. They cover everything from the bootloader, Linux kernel, to networking and graphics.

Infrastructure team:

Making sure our internal and external services are up and running. They do Docker, AWS, Ansible, Puppet and Jenkins.

QA team:

Ensuring the quality of our releases. They focus on both automated and manual testing. The tech stack is Python, JS and Jenkins primarily.

Community

In the past, people have relocated to work with Airtame’s Engineering team, and we pride ourselves for our sense of community.

Work is a nice mix of laidback and laser-focused. We know when to work hard, but we make sure to have fun along the way as well. Once per quarter, we host internal hackathons to get the creative juices flowing. No idea is too big, wild or crazy, and some of them might even be implemented afterwards. We value a relaxed environment where socializing is encouraged, but never mandatory. Sometimes, we even pack our toothbrush and go off-location. Here’s the Airtame team at the last offsite event, Workathon 2017 in Corfu, Greece.

Flexible work hours make all the difference to balancing work/life. That’s why 20% of an engineer’s working hours can be used to work on anything they want. It fosters creativity and independence, and we know for a fact that hobbies can lead to solid ideas of implementation.

We’re remote-friendly, something that has been put to good use by several engineers in the past. Airtame is made up of many different nationalities and clever minds, and no one should feel weighed down by the fact that they’re far from home.

Check out this Favro board we made about the Airtame culture.

What does the team say?

“Airtame is a great place for engineers who thrive on learning. I really enjoy our team breakfasts and roundtable discussions, where I can level up my knowledge in areas ranging from hardware design and kernel development to browser APIs and frontend frameworks, plus lots more in between. With 20% time, quarterly hackathons and flexibility to move between projects, I’m constantly developing my skill set, which helps keep my work fresh and engaging.”

Andrew Keating, Lead Software Engineer

Join the team!

See the full list of job openings here. To learn more about what others think of us, take a look at our company overview.

Ready to join our ambitious team? Send your CV and application to tech-jobs@airtame.com letting us know why you would be a great fit. We can’t wait to meet you!

The post Why join the Airtame engineering team? appeared first on Airtame.

The codebase consists of ~20K lines of C, plus a bit of Objective-C and C++, and it is currently being developed by a team of four engineers. Over the past few months, we have focused on stabilizing our software and improving our engineering processes.

This post discusses some of the tools and processes we’ve utilized in an effort to maintain a high standard of code quality and evade the proverbial software tar pit.

Our first line of defense against Bad Code™ is compiling with the -Werror and -Wallflags, which cause compilation to fail in the presence of any warnings. This helps our engineers catch and fix simple mistakes very early in the development process. There’s also something very satisfying about watching dozens of source files being compiled without a single complaint from the compiler.

Airtame's core compiles warning-free

Airtame’s core compiles warning-freeWe use Gerrit for code reviews and Jenkins for continuous integration. When a developer pushes a change to Gerrit, several Jenkins jobs are automatically triggered to analyze our code and provide feedback on the changes.

The first of these jobs executes Qt’s Simple Sanitizer, which ensures that Git commit messages are well-formed and that committed code does not contain any trailing whitespace characters or conflict markers, among other things.

Simple Sanitizer keeps our commit messages and source files clean

While we don’t believe in one definitive “right way” to format C code, we do feel that it is beneficial to use a consistent coding standard (ours is heavily inspired by the Linux kernel coding style). To enforce our coding standard, we run LLVM’s clang-format, passing its output to a custom Python script which produces an HTML report.

Improperly-formatted code and clang-format's suggested fix

The next code quality check is performed by LLVM’s scan-build, a deep static analyzer with a very nice Jenkins plugin. The beauty of scan-build is that it analyzes all possible paths through the code, enabling us to discover bugs before they materialize as runtime errors. We’ve found that scan-build is particularly good at detecting memory/resource management issues, especially those which are hidden in rarely-triggered edge cases.

A null pointer dereference identified by scan-build

At Airtame, automated testing is deeply ingrained in our engineering culture. Every change pushed to Gerrit causes our automated test suite to be executed on Windows, Mac, and Linux. This includes cmocka unit tests of individual modules, as well as pytest-driven end-to-end system tests.

We use gcov to measure test coverage, passing its output to gcovr to produce a Jenkins-friendly XML file, which allows us to visualize test coverage over time. Our automated tests are absolutely essential to maintaining software quality during rapid development – they have saved us countless hours of manual testing and are especially useful for exposing platform-specific issues.

Our test coverage history - still room for improvement!

We additionally run end-to-end tests through Valgrind and its Jenkins plugin in order to detect memory and threading errors. This is the last of our automated quality checks, and if it succeeds, a +1 Verified vote is applied to the Gerrit change, indicating that it is ready for peer review.

Successful code quality checks make a change eligible for review

Code reviews are another integral component of Airtame’s engineering culture. While we won’t dive too deeply into this topic (it could easily warrant its own blog post), suffice to say that we take reviews very seriously and do our best to detect “code smells” as early as possible. After a change has been peer reviewed, it can be merged via Gerrit. If it passes our manual quality assurance checks, the change is pushed to our alpha testing group, before being promoted to beta, and finally, general availability.

This is just the beginning of Airtame’s code quality journey. As our codebase grows in size and number of contributors, we’ll need to continue adapting our tools and processes.

We’re always on the lookout for talented engineers who are passionate about writing clean, maintainable code! If this sounds like you, get in touch with us at tech-jobs@airtame.com

The post Code quality at Airtame appeared first on Airtame.

But how can we actually accomplish cross-platform capability? Currently, we have 3 full-time engineers from the Airtame team dedicated to making a truly cross-platform streaming solution. Let’s go over how we make it happen.

Starter Kit

When we started this project 2 years ago, we had just one engineer working on this task. However, limited resources allocated to this project in an early phase have helped us to determine a solution that will be most efficient and proven out of all the tools available for this purpose.

During the selection process, we were driven by the following criteria in order to find the perfect framework for Airtame cross-platform capability:

• The framework has to be able to run another executable (the streaming binary)
• It has to be able to communicate with the discovery module (the piece of software that allows us to see all the Airtames on the network)
• It has to run on Windows 7+, MacOS X 10.8+ and as many UNIX systems as we can
• It has to have access to the filesystem of the OS
• Ability to design our own User Interface
• Proven track record (number of companies using it already)
• Active community and support for the framework

When we were making the initial choice 2 years ago – QT made most sense to us. It has a fairly good UI library and we could develop it using C++. However, the main drawback of this solution was that implementing the UI was quite cumbersome, especially if you are new to this framework.

In parallel, we noticed nw.js (formerly node-webkit) rising as a technology of choice when developing cross-platform UI application. Main advantage? You write your UI as you would write a website – in a controlled environment! No need for multi-browser compatibility.

We decided to try nw.js. It worked well for us. We managed to write everything for all platforms in only one (-ish) codebase, the whole thing being written in HTML/CSS/JS with NodeJS. The nw.js’s community was quite active and many other companies were using it, so it had a proven track record and it was fairly easy to troubleshoot.

However, we started to spot some limitations of nw.js over time. The project was not updated that often, we could see some bugs (many Linux issues, frameless window issues, etc.), and we were missing features that were important to us (e.g., auto-updater and balloon notification on Windows).

Around the end of June 2015, we had an important backlog of features and bugs that were hanging because of this.

That’s when we decided to take a look at Electron (formerly atom-shell).

Electron

Electron is in fact very similar to nw.js. It uses the latest version of NodeJS and allows you to write cross-platform applications using web technologies (if you want to know more about the differences between Electron and nw.js, just follow this link.)

Nevertheless, Electron is updated more frequently, it is heavily adopted, and apparent bugs can be fixed quickly by either support from the community or the official maintainers. Moreover, Electron has more functionalities than nw.js (platform specific or not). All of that brings us closer to implementing the best user experience.

One of the main advantages of the Electron framework is that it provides core functionalities useful to almost every software: Auto update, Crash reporter, installer creation, system-specific features, etc.

Architecture

Today, the architecture of the Airtame software is designed as follows:

High-level architecture of the Airtame software on a computer. It highlights the separation in modules, which is at the heart of our software.

Main advantages of the above architecture are as follows:

• Have different release process for each “module”
• Have a clear division of responsibility in the code
• Be able to replace any module easily without impacting the rest of the application
• Provide an HTTP API that other applications can talk to
• Make the testing easier. During the development phase, we can test the front-end directly in Google Chrome if the server is running. On the other hand, it is easier to mock the API of the core functionalities of Electron (like window management and other system-related SDK)

Testing

We have divided the automatic testing into 4 stages:

• Stage 1: All of the node modules tested separately (node-airtame and node-discovery)
• Stage 2: Front-end of the application
• Stage 3: Back-end of the application
• Stage 4: The application as a whole – we have integration and functional tests to verify the functionality of a full feature or scenario (still at an early stage)

We chose Mocha for the testing job and we are happy with it. Every time we submit a change, the tests are triggered in order to validate that there was no regression and that the application is still working as expected. If the test fails, you will be unable to merge the change.

When it comes to the manual testing, we have a “QA” corner in the office along with a set of physical machines and VMs allowing us to test the user case in a real environment. The QA corner is composed of a large variety of systems:

• Windows (7, 8.1, 10)
• MacOS (10.8, 10.9, 10.10.5, 10.11)
• Ubuntu (14.04, 15.04, 15.10)

We are currently working on having even more systems set up through Virtual Machine and other physical devices in order to make Airtame the most cross-platform friendly application.

Our QA corner where we manually test the software and dongle. We have different hardware and virtual machines in order to cover as many cases as we can.

What’s next

We will continue to follow the Electron evolution process. We are planning to take a proactive role by contributing to the development of the framework ourselves.

We will continue focusing on stability and usability of the application. The new architecture of the software will help us to write more tests and to divide even more clearly the responsibility of each component. We are also internally improving our QA process (which will be a part of a future post on our QA process).

We are also listening to our users and we are trying to adapt and fix the issues to always provide the best experience.

Finally, we plan to Open Source the application. We are thrilled about this idea and we will keep you posted about its development.

If you want to download the software, follow this link.

We’re always on the lookout for talented engineers who are passionate about writing clean, maintainable code! If this sounds like you, get in touch with us at tech-jobs@airtame.com.

The post Cross-platform computer applications in practice appeared first on Airtame.