Open sourcing intervene
, a tool to selectively mock API responses and proxy everything else to the real API server.
A new approach to exception monitoring, designed for high scalability...
Two years ago, if an engineering team at SoundCloud needed data produced by another team, in many cases, that team would have had to start by building a dataset from the raw data. That meant there was no standard way to structure data into a dataset, there were errors in understanding and interpreting raw data, and there was no reuse of datasets across teams. Ownership of datasets was with the teams consuming data, even when the data itself was owned and best understood by someone else. By agreeing on an ownership strategy, a common shape for datasets, and standard tooling, SoundCloud was able to streamline these problems away. Now the data and datasets are provided by those who know best about their data, along with the help of tooling built by those who know best about building tools. Read on to learn what datasets look like at SoundCloud and how they are built.
Learn how SoundCloud improved the productivity of its iOS engineers by using Tuist to generate Xcode projects.
For a successful onboarding, you may rely on things like finding a good mentor or writing up a detailed checklist, but there’s more you can do. In this blog post, a new employee at SoundCloud illustrates a collection of engineering practices here that allowed him to get up to speed efficiently and which made the onboarding experience a positive one.
A large portion of an Android app’s build time can consist of Dagger annotation processing, and most developers agree that productivity is important, so we decided to experiment to see if we could save time when compiling the SoundCloud Android app. This blog post covers how we used Dagger Reflect to save developer time with minimal changes to our codebase.
Limiting the number of primitives we use in our code in favor of using custom types instead is an easy win. In this way, we as developers will not only reduce the possibility of bugs by using the compiler, but we will also achieve more readable and self-documented types.
Last week’s update to the SoundCloud iOS app includes support for Dark Mode. This took several months of work and collaboration between design and engineering teams across the company, so we wanted to share our approach to implementing Dark Mode and some of the obstacles we encountered along the way.
Part of a build engineer’s role is to speed up builds. Improving build performance and avoiding work with caching is one way to achieve this, but another tool in the build engineer’s belt is that of disallowing slow builds. This is part two in a series about solving Gradle remote build cache misses.
Until recently, one of the top technical risks facing SoundCloud’s Android team was increasing build times. Our engineering leadership was well aware of the problem, and it was highlighted in our company’s quarterly goals and objectives as modularization. Faster build times means more productive developers. More productive developers are happier and can iterate on products more quickly.
Modularization is key to decreasing build times, but avoiding work is another important part of the puzzle, and build caching is one way to avoid that work. Gradle, our tool for building Android, has a local file system cache that reuses outputs of previously performed tasks. We have been using the Gradle remote build cache in order to save our developers’ time. It helps us avoid redoing work that other teammates have already done or switching to old branches. However, to get the full benefits of caching, you have to go beyond simply setting it up.