"Come, let us make bricks, and burn them thoroughly."
– legendary builders

You may have noticed by 2020 that data is eating the world. And whenever any reasonable amount of data needs processing, a complicated multi-stage data processing pipeline will be involved.

At Bumble — the parent company operating Badoo and Bumble apps — we apply hundreds of data transforming steps while processing our data sources: a high volume of user-generated events, production databases and external systems. This all adds up to quite a complex system! And just as with any other engineering system, unless carefully maintained, pipelines tend to turn into a house of cards — failing daily, requiring manual data fixes and constant monitoring.

For this reason, I want to share certain good engineering practises with you, ones that make it possible to build scalable data processing pipelines from composable steps. While some engineers understand such rules intuitively, I had to learn them by doing, making mistakes, fixing, sweating and fixing things again…

So behold! I bring you my favourite Rules for Data Processing Pipeline Builders.

I strain to make the far-off echo yield
A cue to the events that may come in my day.
(‘Doctor Zhivago’, Boris Pasternak)

I’ll be honest: I don’t write in pure C that often anymore and I haven’t been following the language’s development for a long time. However, two unexpected things happened recently: С won back the title of the most popular programming language according to TIOBE, and the first truly interesting book in years on this language was published. So, I decided to spend a few evenings studying material on C2x, the future version of C.

Here I will share with you what I consider to be its most interesting new features.

My name is Marko and I gave a talk at Gophercon Russia this year about a very interesting kind of indexes called «bitmap indexes». I wanted to share it with the community, not only in video format, but as an article too. It's an English version and you can read Russian here. Please enjoy!

Christmas has always been one of my favourite times of the year. For me, Christmas is a season that brings so much love, laughter, happiness, and other magical things into our lives.

I was born and raised in Spain, more specifically in Tenerife, a sunny subtropical island in the middle of the Atlantic Ocean just off the African coast. I have to say that Christmas in Tenerife is very different to my the last two Christmases I’ve spent in London since joining Badoo.

One amazing plus of living in London is that I have got to see snow for the first time in my life, real snowflakes falling from the sky. Just incredible!

Talking of snowflakes, I have an interesting story to tell you about something that happened to me one day in the office the last Christmas.  It was right before I was heading home to Tenerife to spend a few days with my family.

It just so happened that last December I’d been assigned a very interesting ticket with the following description

This is the second part of a post about the creation of a pipeline that can take a Sketch file and export all the icons included in the file, in different formats, for different platforms, with the possibility of AB testing each icon.

You can read the first part of the post here.



The Sketch files, with all the icons collected, styled and properly named, were ready. Now it was time to start writing the code.

Suffice to say, the process was very much a trial and error: after the important initial code core, developed by my team lead Nikhil Verma (who set the script foundations), I went through an incremental process that required at least three phases of refactoring and quite a few revisions. For this reason, I won’t go into too much detail on how the script was developed, but rather focus on how the script works today, in its final shape.

TL;DR

Using a custom build script in Node JS, it is possible to manipulate a series of Sketch files, and then, using an internal Sketch tool, automatically export their assets, to generate multiple icon libraries, for multiple platforms and different brands, that support dynamic colourisation of the assets via design tokens, and also AB testing of the assets via naming convention. Easy peasy :)

---

Well, actually it’s not that easy, but it can certainly be done. This post is a detailed explanation of how we did it, and what we discovered along the way.

The problem we were trying to solve

At Badoo we build a dating app. Actually, multiple dating apps. For multiple platforms (iOS, Android, Mobile Web, Desktop Web), across multiple teams.

We use hundreds of icons in our apps. Some of them are the same across different apps, some are very specific to the brands the apps reflect. The icons are continuously evolving, in sync with the evolution of the design. Sometimes completely new icons are added, while others get updated, and still others get dropped (although, they often remain in the codebase).

A few months ago I came across a very interesting documentary series on Netflix called Abstract, they basically explore the output of professional designers from different sectors like architecture, graphic design, fashion, … in their workplaces.

It was easy to spot some similarities in the work of designers from other fields with that of an iOS developer who implements user interfaces. For example, when a designer is creating something that is big enough to be broken down into smaller parts, using a strategy like ‘Divide and Conquer’ is key to being able to focus on smaller parts that will be assembled at later stages in the process.

Breaking down a whole design into smaller subunits allows us to think about each problem in isolation, removing any dependencies between the components. But the full picture also needs to be present throughout the whole process, otherwise there can be problems when the time comes to fit everything back together.

On the other hand, while watching Abstract I noticed that in the design process for objects like a shoes, banners or buildings the final design remains fixed for the lifetime of the product. The design of a Nike shoe isn’t going to change after it is released and there aren’t going to be any updates once it’s on the shelf in the shop. Sometimes a design remains unchanged even 20 years later, and the product is still sound.

Hi everyone! About six months ago we launched one of Badoo’s most exciting features: Live Streaming. One of its main functionalities is that viewers can send gifts to their favourite streamers to express their appreciation. We wanted to make the gifts as fancy and as engaging as possible, so it was decided to make some of them really lively, and by this I mean animated. And to engage people even more, we, the Badoo team, planned to update those gifts and animations every few weeks.

As an iOS engineer, you might have already guessed the challenge we faced here: the need to add new animations and remove the old ones was going to require a fair amount of work from the client side. We’d need both the Android and the iOS development teams for every release — which, when combined with the amount of time App Store reviews and approval often take, would mean it might be days before each update could go live. But we solved the problem, and I’m going to explain to you how.

Solution overview

By this stage, we already knew how to export Adobe After Effects (AAE) animations into the format readable by our iOS app using the Lottie library. This time though, we went a bit further: we decided to create a kind of animation storage service, available via the internet. In other words, we would store all the actual animations on the server and deliver them to the client apps on demand:

New betas are here and these are some of the most important things that I have learned about them.

Swift 5 for Xcode 10.2 beta

Swift

Firstly, the latest Xcode beta is bundled with the following Swift version:

Apple Swift version 5.0 (swiftlang-1001.0.45.7 clang-1001.0.37.7)
Target: x86_64-apple-darwin18.2.0
ABI version: 0.6

Let’s start with the most exciting news:

Swift apps no longer include dynamically linked libraries for the Swift standard library and Swift SDK overlays in build variants for devices running iOS 12.2, watchOS 5.2, and tvOS 12.2. As a result, Swift apps can be smaller when deployed for testing using TestFlight, or when thinning an app archive for local development distribution.

Application Binary Interface stability is coming! And this is excellent news. I think this is the one of the most significant issues at the moment with Swift. Not because of side-effects but because of Swift’s failure to deliver on previous promises. Anyway, I even know people who rewrite their Apple Watch extensions to Objective C to reduce the size of binary (something like 15MB vs ~1MB in Objective C). If you want to know more about the state of ABI, follow the links: Swift — ABI Dashboard and Swift ABI Stability Manifesto.

Hello Habr! I'm Miloš from Badoo, and this is my first Habr post, originally published in our tech blog. Hope you like it, and please share and comment if you have any questions

So… React, amirite???

It appeared in the middle of the decade (plagued by the endless JavaScript framework wars), embraced the DOM, shocked everyone by mixing HTML with JavaScript and transformed the web development landscape beyond recognition.

All those accomplishments, without even being a framework.

Love it or hate it, React does one job really well, and that is HTML templating. Together with a great community and a healthy ecosystem, it’s not hard to see why it became one of the most popular and influential JavaScript libraries, if not the most popular one of all.