Badoo — это сервис знакомств, который доступен в виде сайта и мобильных приложений под основные платформы. В начале прошлого года мы глобально переработали сайт, в результате чего он превратился в «толстого клиента» и стал работать так же, как и мобильные приложения: вызывать команды на сервере и получать от него ответы согласно протоколу, описывающему взаимодействие клиентской и серверной частей. Эти две части делаются разными разработчиками, и, как правило, клиентская часть делается уже после того, как серверная будет готова. При этом есть проблема: как разработчик новой фичи может убедиться, что серверная часть работает корректно, если клиента для нее пока нет и проверить ее не на чем?

Для решения этой проблемы в любой серверной задаче у нас обязательно должны быть написаны интеграционные тесты, про которые я расскажу в этой статье.

Для того чтобы мы могли считать статистику, наш сайт в своей работе генерирует огромное количество событий. Например, при отправке сообщения другому пользователю, при заходе пользователя на сайт, при смене местоположения и т.д. События представляют из себя строку в формате JSON или GPB (Google Protocol Buffers) и содержат время отправки, идентификатор пользователя, тип события, а также поля, относящиеся непосредственно к самому событию (например, координаты пользователя).

Каждую секунду генерируются сотни тысяч событий, и нам нужны инструменты, чтобы их собирать и анализировать эффективно и с минимальной задержкой. Мы рассматривали несколько существующих решений для этой задачи и до недавнего времени использовали демон под названием Scribe от Facebook. Он в целом нас устраивал и позволял делать все, что нам нужно. Однако в какой-то момент Facebook забросил свою разработку, и при некоторых условиях Scribe начал у нас падать (например, при перегрузке upstream-серверов). Самостоятельно устранить причину падений демона у нас не получилось, поэтому мы начали искать альтернативу.

Множество статей и книг посвящено тому, как правильно проектировать API, но едва ли кто-то затрагивал тему постоянно меняющихся (гибких) API. Динамично развивающаяся компания зачастую выпускает по несколько релизов в неделю, а иногда и в день. При этом для добавления новых функций необходимо постоянно вносить изменения в существующее API. В этой статье мы расскажем о том, как мы в Badoo решаем эту задачу, какие подходы и идеи мы используем в своей работе.

Для начала я должен немного подробнее рассказать о Badoo, чтобы вы понимали, кто работает с нашим API и почему оно так часто меняется.

Вступление

Привет, хаброжитель! Уже довольно давно я хотел написать статью о том, как у нас в Badoo устроена автоматизация тестирования. Хотелось написать о чем-то интересном и, в то же время, полезном. Поделиться опытом, который можно было бы легко интегрировать почти в любую систему. И вот, такая тема назрела…

Как многие из вас знают, Badoo — это социальная сеть, ориентированная на поиск новых друзей и знакомств. Одной из важнейших задач является верификация пользователя. Ведь всем нам хочется, чтобы привлекательная девушка, с которой у нас назначена встреча, не оказалась дядей Колей из Твери.

Для верификации пользователей у нас существует много различных способов. Некоторые из них довольно привычные, такие, как верификация по номеру телефона. Есть и более необычный — верификация по фотографии. Но самая простая и быстрая — верификация через социальные сети.

Такой способ верификации профиля возможен сразу на момент его создания — регистрация через социальную сеть. Во-первых, это быстро, всего один клик и никаких дополнительных манипуляций с телефоном или веб-камерой. Во-вторых, это удобно, так как при желании можно импортировать фотографии и информацию о себе, вместо того, чтобы вводить их вручную.

Сегодня я расскажу о том, как на Badoo устроена регистрация и верификация через Facebook и о том, как мы научили selenium-тесты ее проверять.

Введение

В этой статье я расскажу, как профилировать и оптимизировать приложения на языке Go с использованием встроенных и общих инструментов, доступных в ОС Linux.

Что такое профайлинг и оптимизация? Если ваша программа работает недостаточно быстро, использует слишком много памяти, неоптимально использует процессор, вы хотите понять, в чем дело, и исправить — это и есть профайлинг и оптимизация.

Я привел такое определение, чтобы сразу отсечь вопросы некорректной работы приложения. В этой статье мы не будем говорить о проблемах мультитредового программирования, о дата-рейсах (англ. data race), о поиске ошибок (англ. debugging). Для всего этого в Go есть свои утилиты и подходы, но оставим эту тему на будущее.

В нашу жизнь уже давно вошли эмодзи. И в социальных сетях, и во всевозможных мессенджерах мы используем их не задумываясь, выражая свои эмоции всего одним символом. Но для кроссплатформенного приложения отправка и отображение эмодзи — непростая задача. Проблема заключается в том, что отправленные эмодзи с мобильных приложений не всегда отображаются корректно на веб-сайтах.

Последние версии iOS и Android имеют поддержку более 1200 символов эмодзи, но «десктопный» рынок не может похвастаться такими успехами. Мы же в Badoo хотим и делаем все, чтобы пользователям было комфортно общаться на всех платформах, не имея никаких ограничений в переписке.
Далее я расскажу, каким способом мы добились 100% поддержки эмодзи для веба.

В начале каждого года мы с коллегами составляем список интересных нам конференций, как российских, так и зарубежных. Поскольку я многократно посещал «конференции широкого профиля», то в этот раз решил посетить более узкоспециализированную, и мой выбор пал на PHP UK Conference.

PHP UK Conference проводится с 2006 года и изначально задумывалась как профильная конференция для местного PHP-сообщества, где разработчики могли бы делиться знаниями и узнавать из первых уст о об опыте профессионалов и последних достижениях в индустрии.

Если в Google ввести запрос «a b тестирование», то по теме выпадает довольно много статей, но в них больше теории и ориентированы они на менеджеров, а в качестве инструментов предлагаются готовые клиентские реализации, вроде Google Analytics. Также есть статья про очень простую серверную реализацию (в реалиях авторов, я думаю, этого вполне достаточно).

Сегодня я расскажу о том, как это происходит у нас, в Badoo, при огромном количестве пользователей по всему миру.

У нас был целый «зоопарк» инструментов для сплит-тестирования во главе с A/B фрэймворком, часть из которых разрабатывалась для других целей. Помимо прочих недостатков, все эти инструменты использовали примерно один и тот же способ для разделения пользователей на варианты — это хеширование ID пользователя плюс «соль». Такой подход нас не удовлетворял, и было принято решение разработать новую версию, в которой можно было бы избежать недостатков старых версий.

Большинство IT-компаний не делают версии своих продуктов под Windows Phone, потому что доля мобильной операционной системы от Microsoft меньше, чем у iOS и Android. Тем не менее, это третья крупнейшая мобильная операционная система на рынке, и в Badoo Windows Phone приложение уже давно существует.

Изначально оно было написано аутсорсным разработчиком на Silverlight и долгое время не обновлялось, и несколько лет у продукта не было выделенного отдела. В 2014 году в компанию пришел разработчик Windows Phone и стал поддерживать это приложение, а я стал получать на тестирование некоторые его задачи.

Через пару месяцев было решено написать полностью новое приложение, забросив почти все старые наработки во многом потому, что код был далек от идеала, а на его поддержку тратилось очень много времени. Первым новым приложением для Windows Phone стал экспериментальный проект Badoo — Hot or Not. По концепции он очень похож на Badoo, но в нем гораздо меньше функционала и он несколько отличается. Всего за 3 месяца мы вдвоем сделали приложение Hot or Not с нуля в одной ветке Git-репозитория, которую в итоге замержили в Master. А приложение TeamCity было настроено так, что каждый коммит разработчика собирался как отдельное приложение, что позволяло мне, как тестировщику, видеть историю изменений клиента.

Сегодня мы начинаем серию публикаций новых мастер-классов Технопарка. И первая из них — мастер-класс Алексея Рыбака на свободную тему, в котором он поделился со студентами соображениями о том, чем работа в реальной жизни отличается от учебы. Видео смотрите на нашем сайте, а адаптированную расшифровку — ниже.

Я работаю в компании Badoo достаточно долго, и на моих глазах этот проект из маленького стартапа превратился в большую компанию с сотнями инженеров и тысячным парком серверов, распределенных по нескольким дата-центрам. Сейчас я хотел бы рассказать о том, что считаю достаточно интересным для студентов, выбравших профессию программиста.

Не буду рассказывать о современных трендах и о том сегодня важно и нужно — об этом вам многие могут рассказать. Вместо этого поговорим о некой общечеловеческой адаптации бывших студентов к работе, которую каждый человек проходит в течение одного, а порой и нескольких лет. Процесс этот достаточно болезненный, и далеко не все «правильно» проходят эту адаптацию. Именно эта тема должна больше интересовать студентов и выпускников, чем какие-то модные технологические фишки. Хотя о них мы тоже поговорим, когда коснемся темы самообразования.

Привет, Хабр! Эта публикация — попытка развеять некоторые популярные мифы и легенды о MySQL. Я не ошибся с хабом, так как поводом для написания послужила публикация varanio Возможности PostgreSQL, которых нет в MySQL, и наоборот отсюда же. Сама публикация в части критики MySQL хоть и неидеальна, но вполне корректна, а вот комментарии к ней наводят на грустные размышления.

Вообще говоря, я собирался написать публикацию о возможностях MySQL, которые не реализованы или реализованы в PostgreSQL хуже. Но для того, чтобы не мешать много тем в одну публикацию, и учитывая довольно нелёгкую работу по сравнению того, что я знаю очень хорошо (MySQL) с тем, что я знаю очень плохо (PostgreSQL), такую публикацию я решил отложить на потом и для начала ответить сразу на многие комментарии из публикации varanio.

Что я успел понять про MySQL за несколько лет его разработки:

• развивать не ломая обратной совместимости его нельзя
• MySQL со сломанной обратной совместимостью никому не нужен.

Я опишу две серьёзные проблемы ДНК MySQL, с которыми косвенно сталкивается любой пользователь MySQL 5.1 и 5.5 (насчёт 5.6 не проверял, но не думаю, что этот момент поменялся).

Как вообще MySQL работает?

В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот материал будет полезен всем тем, кого уже не устраивают возможности и особенности MySQL, а также тем, кто делает первые шаги в Postgres. Конечно, не стоит рассматривать этот пост как исчерпывающий список различий, но для принятия решения в пользу той или иной СУБД его будет вполне достаточно.

Извиняюсь, если зря поместила пост в хаб космонавтики: к сожалению, хаба с названием «космос» или подобного не нашла. Так же извиняюсь за некоторое количество саморефлексии в трех следующих абзацах, но саморефлексия необходима, так как пост является критическим по отношению к нескольким ранее опубликованным, и за опечатки, которые наверняка присутствуют в моем посте (но будут исправляться по мере того, как я буду их замечать).

На написание своего поста меня сподвигла серия таких:

А Вы подключали телескоп к компьютеру?
Айтишник на отдыхе: а как насчет телескопа?
Айтишник на отдыхе: добавим немного астрономии?
Айтишник на отдыхе: прибамбасы к телескопу

Спасибо большое авторам, что они популяризируют любительскую астрономию, но при чтении этих постов у меня несколько раз от неудобства и стыда сжимались пальцы на ногах.
Может быть, это не так и важно: В конце концов, Хабрахабр это ресурс ИТ-ков, а любительская астрономия это всего лишь хобби, и каждый занимается хобби так, как ему нравится. А может, нет, и критиковать, поучать, как заниматься хобби можно?

Это пост про грабли, на которые Вы скорее всего наступите, если увлечетесь таким красивым, романтичным, но сложным хобби. Мой пост не является очень популярным, он рассчитан на человека, который уже хоть что-то почитал (например, вышеозначенные посты, которые мне не понравились, хотя авторам я все равно поставила плюс в карму за популяризацию). В посте могут встречаться непонятные термины. Если Вас это напрягает, пожалуйста, не читайте.

Для затравки анекдот.
Приходит в магазин телескопов покупатель, и спрашивает:

— А можно у Вас купить телескоп за три тысячи рублей?
— Ну… можно, но линзы будут пластмассовыми, и лучше не стоит, возьмите вот лучше рефрактор за 6 тысяч. — Продавец показывает рукой на самый популярный среди школьников линзовый телескоп
— Хорошо, а можно купить телескоп за 25 тысяч? — Вопрошает покупатель
— Можно, — Отвечает продавец, показывая рукой на восьмидюймовый ньютон на EQ5 — это очень хороший телескоп для начинающих
— А в него можно увидеть плеяды сквозь облака? — спрашивает покупатель
— К сожалению, нельзя… — Качает головой продавец
— А есть телескоп за 100 тысяч? — Не унимается покупатель
— Да, вот — Продавец показывает на компьютеризированный и навороченный Nexstar 11SE
— А в него можно увидеть туманность Андромеды днём?
— К сожалению, нельзя, — качает головой продавец
— А зачем тогда он такой дорогой нужен?

Так получилось, что любительская астрономия стала моим главным хобби. Мне бы очень хотелось поделиться с хабрасообществом, которое вдруг решится на обретение нового хобби, своим опытом. Может быть, далеко не самым большим, но зато своим. Мой хороший знакомый, которого я считаю лучшим визуальщиком-наблюдателем объектов дальнего космоса Москвы, а может быть и России, считает себя наблюдателем со средним скиллом(сравнивая себя с наблюдателями всего мира), меня начинающей, а все новички, получается, находятся вне классификации. Не знаю, дает ли мне такой опыт право на написание постов на тему любительской астрономии на Хабрахабре? Я раньше считала что нет, не дает, но вышеприведенная серия постов изменила эту точку зрения, и мне очень захотелось написать пост, который бы предостерег начинающих любителей астрономии (не по классификации знакомого наблюдателя), от наступления на грабли, которые могут отбить желание заниматься этим хобби.

«О каких граблях речь? Это же хобби! Им каждый занимается так, как ему нравится!» — Воскликнет скептик, и будет прав:
Например, ИТ-кам нравятся всякие высокотехнологичные жужжащие штуки, ну вот пускай и покупают мелкоскопчик с GoTo системой за ограниченный бюджет. Пусть мелкоскоп после наведения в точку на небе, где находится галактика «Игла» NGC 4565, такая красивая на фотографиях, со своими газопылевыми облаками не покажет ничего ни через окно кухни квартиры в центре Москвы, ни даже с застекленной и тёплой веранды дачи :) Главное, что мелкоскопчик жжужит, мигает красивыми красными огнями на пульте, и владелец оборудования доволен новым гаджетом и приощением к небу, сидя в тепле и комфорте, не так ли?

Или всё-таки не так? Если не так, добро пожаловать под кат. В противном случае, пожалуйста, не читайте мои многобукв про грабли, ведь в хобби наступление на грабли может быть даже своеобразным мазохизмом, и в чём-то быть приятным наступающему!

Здравствуйте, меня зовут Юрий Насретдинов, я работаю старшим инженером в Badoo. За последние полтора года я сделал несколько докладов на тему того, как работает наше облако. Слайды и видео можно посмотреть тут и тут.

Сегодня настало время рассказать о ещё одной части этой системы — о сборщике логов, который мы вместе с этой статьей выкладываем в open-source. Основная часть логики нашего облака написана на языке Go, и эта подсистема не является исключением.
Исходные коды системы: github.com/badoo/thunder
В этой статье я расскажу вам о том, каким образом мы доставляем логи приложений в нашем облаке, которое мы называем просто «скриптовым фреймворком».

Логи приложений

Наши приложения, запускаемые в облаке, представляют из себя классы на PHP, которые в простейшей реализации имеют метод run() и получают на вход данные задания, например, число от 1 до N, где N — максимальное число экземпляров для этого класса. У каждого задания есть свой уникальный id, и конечной целью является доставка логов в какое-то централизованное хранилище, где можно будет легко найти логи как конкретного запуска, так и все логи класса сразу.

Готовы видео докладов с митапа Golang Moscow и мы с радостью с вами ими делимся.

1. «Go в Badoo»
Антон einstein_man Поваров

Привет, меня зовут Макс Матюхин, я PHP-программист в компании Badoo. В прошлом месяце в Лондоне прошла очередная Международная конференция разработчиков QCon 2015. Я побывал на ней и теперь хочу поделиться с вами своими впечатлениями о мероприятии и рассказать о самых интересных, на мой взгляд, выступлениях. Из этой статьи вы узнаете чуть больше про архитектуру Uber, Spotify, CloudFlare, а также о том, как Google управляет своей инфраструктурой и многом другом.

Впервые QCon состоялась в 2007 году в Лондоне и Сан-Франциско. С тех пор она стабильно набирает популярность и расширяет географию, и в этом году она пройдет в 8 городах. Лондонская QCon проходит в самом сердце британской столицы, в двух шагах от Вестминстерского Аббатства. В разное время на QCon выступали такие известные личности, как Martin Fowler, Kent Beck, Erik Meijer, Steve Vinoski, Joe Armstrong, Rich Hickey и многие другие.

И снова в эфире наша постоянная рубрика «Лекции Технопарка». На этот раз предлагаем вам ознакомиться с материалами курса «Проектирование высоконагруженных систем». Цель курса — получение студентами навыков проектирования высокоэффективных программных систем.

Как вы знаете, Badoo — сервис для поиска новых людей. Кроме всего прочего, мы позволяем искать людей вокруг и в «игре» тоже показываем людей, которые находятся недалеко от вас. Эта часть «вокруг» очень и очень важна. Ведь молодому человеку из Новосибирска гораздо интереснее познакомиться с девушкой, которая живет в пяти минутах ходьбы от него, а не во Владивостоке.
Мы до сих пор не рассказывали публично о том, как мы это делаем. Но новое открытие австрийских ученых настолько нас обрадовало, что мы решились это сделать. Перейдем же к делу.
Badoo работает по всему миру и наш поиск работает абсолютно одинаково, вне зависимости от того, в какой точке земного шара вы находитесь. Как же эффективно искать людей вокруг среди всех 200+ миллионов пользователей?
Решение нетривиально, честно говоря. Нам нужен какой-то индекс, какой-то способ сразу же сузить область поиска. В случае с земным шаром, самым простым разбиением является сетка географических широт и долгот. Однако проблема с этой сеткой в ее неравномерности. Ячейка у северного полюса и ячейка у экватора имеют совсем разные формы. Такое несимметричное разбиение вносит большие проблемы, если мы хотим равномерно распределить нагрузку по поисковому кластеру.

Сегодня мы поговорим о «низкоуровневых» кирпичиках нашего проекта — о демонах.
Хоть это и не очевидно, но практически весь функционал сайта во многом зависит от работы этих программ. Игра в “Знакомства”, поиск новых лиц, центр внимания, обмен сообщениями, статусы, геолокация и многие другие вещи завязаны на тот или иной демон. Так что можно сказать, что они помогают людям по всему миру общаться и находить новые знакомства. Одновременно на сайте могут работать и взаимодействовать между собой несколько десятков демонов. Их корректное поведение является очень важной задачей, поэтому мы решили покрывать основной функционал демонов автотестами.

В Badoo этим занимается специальный отдел. И сегодня мы расскажем о том, как у нас проходит процесс разработки этой критически важной части сайта и выполнение автотестов. Эта область достаточно специфичная и материала много, поэтому мы подготовили структурированный обзор всего процесса, чтобы разобраться в нем смогли все, кому интересно.

В качестве VCS у нас используется Git, для непрерывной интеграции — TeamCity, а в роли баг-трекера выступает JIRA. Для тестирования мы используем PHPUnit. Разработка демонов, как и остального сайта, ведется по принципу «фича ― ветка». Для того чтобы понять, что это, мы рассмотрим проекции нашего flow на Git и на JIRA.