Привет! Меня зовут Дмитрий Ли, я тимлид одной из команд разработки бэкенда в Badoo.

Когда я впервые стал тимлидом, я стал активно посещать конференции и читать умные книги об управлении командой. Однако в моей работе после этого менялось немногое. Я читал о том, каким я должен быть, в чём должен развиваться, но мне было неясно, что конкретно для этого нужно делать.

Мне пришлось не раз и не два наступить на одни и те же грабли, прежде чем я разобрался, что мешает наладить и улучшить мою работу. Поэтому для выступления на Saint TeamLead Conf я решил собрать из своего нынешнего опыта советы, которых мне не хватало на старте моей карьеры управленца. Эти вещи сильно упростили бы мне жизнь, если бы я знал о них раньше. 

Рецепты, которыми я хочу поделиться, в большей степени пригодятся начинающим тимлидам: я записал их как своеобразное наставление себе самому несколько лет назад. Эта статья написана по мотивам моего доклада на TeamLeads Conf.

12 декабря приглашаем слушателей на «открытый микрофон», посвященный разработке бэкенда. Мы позаимствовали идею у стэндаперов и хотим помочь спикерам «обкатать» технические доклады в спокойной обстановке. Собираемся в 19:00 в офисе Badoo (Москва, Цветной б-р, 2).

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

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

Формат опробуют пять спикеров, у которых будет всего десять минут, чтобы изложить свои идеи. Подробности под катом.

Если вы подумываете выступить с докладом, тем более впервые, то самое сложное — поверить в свою идею. Я знаю случаи, когда люди годами вынашивают идею доклада, видят во сне свое выступление, слышат гробовое молчание зала и просыпаются в холодном поту. В итоге даже выступить перед своими коллегами в переговорке и рассказать о новом проекте или экспериментах с технологиями банально страшно.

«Это никому не интересно», «Я не делаю ничего такого», «Мне нечего рассказывать» — классические переживания большинства спикеров-инженеров.

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

Страх присущ всем. Чтобы проверить идею, обкатать тему и оценить вероятность тапок, летящих из зала, standup-артисты практикуют мероприятия в заранее заявленном формате «открытого микрофона». Это когда у вас есть небольшой морально подготовленный зрительный зал, собственно микрофон и только 10 минут, чтобы рассказать все, что хочется. 

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

Многие из вас наверняка сталкивались с ситуацией, когда в библиотеке или фреймворке, который вы используете, есть баг или нет необходимой функциональности. Предположим, вы даже не поленились и сформировали pull request. Но примут его далеко не сразу, а следующий релиз продукта вообще может произойти через год.

Что же делать, если исправление вам срочно нужно катить в прод? Напрашивается очевидное решение — использовать форк библиотеки или фреймворка. Однако с форками не всё просто. Использовать наследования для переопределения функциональности, которую нужно изменить, не всегда возможно и часто требует больших изменений. На помощь приходят плагины для Composer, которые умеют патчить зависимости.

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

Если в строке поиска на Хабре ввести “Jira Badoo”, результаты займут не одну страницу: мы упоминаем её почти везде, потому что она играет важную роль в наших процессах. Причём каждый из нас хочет от нее немножко разного.



Разработчик, которому пришла задача на ревью, ожидает что в задаче указана ветка, есть ссылки на дифф и лог изменений. Разработчик, который писал код, ожидает увидеть в Jira комментарии по итогам ревью. Тестировщик, который получает задачу после них, хочет видеть результаты тестов и иметь возможность запустить необходимые сборки, не переходя в другие интерфейсы. Продакт-менеджеры вообще хотят создавать десять задач по разработке одновременно, нажав на одну кнопку.

И всё это сегодня доступно и происходит автоматически. Большую часть магии мы реализовали на PHP с помощью постоянно развивающегося API Jira и с использованием её webhook’а. И сегодня мы хотим поделиться с сообществом нашей версией клиента для этого API.

Сначала мы хотели просто рассказать об идеях и подходе, который мы используем, а потом решили, что к такой статье решительно не хватает кода для наглядности. Так появилась open-source-версия Badoo Jira PHP Client. Огромное спасибо ShaggyRatte за то, что помог с ее описанием. И добро пожаловать под кат!

Много лет назад я пришёл на должность разработчика в одну компанию и вскоре стал свидетелем необычной сцены. Тимлид соседнего отдела подозвал своего подчинённого посреди рабочего дня и довольно громко и развязно сказал ему: «Слышь, на вот тебе денег. Сгоняй в магазин, купи вискаря и закуски». 

Я подумал: «Да ладно! Странно всё это...». Но ситуация повторялась ещё несколько раз. Проработав в компании какое-то время, я понял, что подобное поведение там было нормой. Одни команды дружили против других, процветала подковёрщина, а топ-менеджмент абсолютно никак не реагировал на это. Я ушёл оттуда, несмотря на то, что и задачи были интересные, и условия неплохие. Но моральный климат был невыносим. 

Так считал не только я: сейчас этой компании уже нет. Но в тот момент я понял, насколько важно работать с неформальными отношениями, насколько существенное влияние они могут оказать на бизнес в целом. Причём работать с ними должны прежде всего линейные руководители, а не HR-менеджеры или штатные психологи, потому что именно руководители ежедневно находятся в контакте со своими подчинёнными. 

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

В последние десять лет я занимаюсь тем, что руковожу командами разработки, семь из них — в Badoo. Эта статья написана по мотивам моего  выступления на Saint TeamLead Conf 2019: в ней я попытаюсь объяснить, как и зачем нужно работать над неформальными отношениями в коллективе. 

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



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

Видео и презентации — под катом. Приятного просмотра!

Меня зовут Денис Чернобай, я отвечаю за frontend-разработку в компании Badoo. Три года назад мы впервые собрали сообщество IT-руководителей, чтобы обсудить объединяющие его темы, и продолжаем следить за тем, что волнует коллег по цеху. 

Здорово, что тимлиды и CTO делятся историями успеха о построении процессов и мотивации людей. Однако за большинством таких историй стоят истории провалов, ошибок и боли. О них обычно не принято говорить в микрофон, да и (будем откровенны) просто тяжело. Но мы всё-таки попробуем!

19 октября приглашаем на пятую встречу сообщества в офисе Badoo. Провести её хотим в максимально открытом формате непридуманных историй руководителей. Будет разбор сложных кейсов, рефлексия о полученном опыте и всё, что обычно остаётся за сценой.

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

Регистрация по ссылке, подробнее о спикерах под катом.

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

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

Я буду использовать термин «время высокой точности». В документации MySQL вы увидите термин “fractional seconds”, но его дословный перевод звучит странно, а другого устоявшегося перевода я не нашёл.

Для отладки PHP-программ часто используют Xdebug. Однако стандартных возможностей IDE и Xdebug не всегда достаточно. Часть проблем можно решить с помощью Xdebug proxy — pydbgpproxy, но всё же не все. Поэтому я реализовал PHP Xdebug proxy на базе асинхронного фреймворка amphp.

Под катом я расскажу, что не так с pydbgpproxy, чего в нём не хватает и почему я не стал его дорабатывать. Также объясню, как работает PHP Xdebug proxy, и покажу на примере, как его расширять.

Привет! Меня зовут Юрий Влад, я Android-разработчик в компании Badoo и принимаю участие в создании библиотеки Reaktive — Reactive Extensions на чистом Kotlin.

В процессе работы мы столкнулись с тем, что в случае с Kotlin Multiplatform continuous integration и continuous delivery требуют дополнительной настройки. Необходимо иметь в распоряжении несколько виртуальных машин на различных операционных системах, чтобы собрать библиотеку полностью. В этой статье я покажу, как настроить continuous delivery для вашей Kotlin Multiplatform библиотеки.

Привет! Готовы материалы с Badoo PHP Meetup #3, традиционной неформальной встречи сообщества. Напомню, в этот раз мы обсуждали проблемы производительности бэкенда на PHP и их решение в разных компаниях.  



Тема нашла моментальный отклик среди почти 200 гостей — на каждом перерыве спикеров окружала толпа с вопросами. Опытом делились Александр Малащицкий из Superjob, Павел Мурзаков pmurzakov из Badoo и Антон Шабовта zloyusr из Onliner, а к панельной дискуссии также присоединились Семён Катаев из Avito и Михаил Буйлов из Mamba.

Все материалы — под катом, полезного просмотра!

Сегодня я решил перевести для вас небольшую статью о внутренностях реализации так называемых замыканий или closures. В дополнение вы узнаете о том, как Go пытается автоматически определить, нужно ли использовать указатель/ссылку или значение в разных случаях. Понимание этих вещей позволит избежать ошибок. Да и просто все эти внутренности чертовски интересны, как мне кажется!

А еще я хотел бы пригласить вас на Golang Conf 2019, которая пройдет 7 октября в Москве. Я член программного комитета конференции, и мы с коллегами выбрали много не менее хардкорных и очень, очень интересных докладов. То, что я люблю!

Под катом передаю слово автору.

Классик писал, что счастливые часов не наблюдают. В те дикие времена ещё не было ни программистов, ни Unix, но в наши дни программисты знают твёрдо: вместо них за временем проследит cron.

Утилиты командной строки для меня одновременно слабость и рутина. sed, awk, wc, cut и другие старые программы запускаются скриптами на наших серверах ежедневно. Многие из них оформлены в виде задач для cron, планировщика родом из 70-х.

Я долго пользовался cron поверхностно, не вникая в детали, но однажды, столкнувшись с ошибкой при запуске скрипта, решил разобраться основательно. Так появилась эта статья, при написании которой я ознакомился с POSIX crontab, основными вариантами cron в популярных дистрибутивах Linux и устройством некоторых из них.

Используете Linux и запускаете задачи в cron? Вам интересна архитектура системных приложений в Unix? Тогда нам по пути!

IT-Alias — уникальный вариант классической настолки, игра на взаимопонимание и проверку технического словарного запаса. Её сделали инженеры Badoo, чтобы играть с участниками конференций и наших митапов. А сегодня мы хотим сыграть в IT-Alias с читателями Хабра — и подарить несколько увесистых коробок с карточками тем, кто быстрее и точнее всех назовет загаданные нами слова.

Upd: всем спасибо за участие — 23 слова угадали всего за два часа! Итоги в конце поста, но мы предлагаем не останавливаться и продолжать играть в комментариях: загадывайте любые слова на IT-тематику.

Badoo разрабатывает несколько приложений, и каждое из них — это отдельный продукт со своими особенностями, менеджментом, продуктовыми и инженерными командами. Но все мы работаем вместе, в одном офисе и решаем похожие проблемы.

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

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

За прошедшие с момента появления языка C десятилетия было создано множество интереснейших языков программирования. Какие-то из них используются до сих пор, другие — повлияли на следующие поколения языков, популярность третьих тихо сошла на нет. Между тем архаичный, противоречивый, примитивный, сделанный в худших традициях своего поколения языков C (и его наследники) живее всех живых.

Критика C — классический для нашей индустрии эпистолярный жанр. Она звучит то громче, то тише, но в последнее время буквально оглушает. Пример — перевод статьи Дэвида Чизнэлла «C — не низкоуровневый язык», опубликованный в нашем блоге некоторое время назад. Про C можно говорить разное, в дизайне языка действительно много неприятных ошибок, но отказывать C в «низкоуровневости» — это уже слишком!

Чтобы не терпеть такую несправедливость, я собрался с духом и постарался определиться с тем, что есть язык программирования низкого уровня и чего хотят от него практики, после чего перебрал аргументы критиков C. Так получилась эта статья.

Часто бывает так, что приходишь на машину и обнаруживаешь какой-то скрипт, запущенный под системным пользователем неделю назад. Кто его запустил? Где искать этот run.php? Или добавляешь запись в /etc/crontab, а скрипт там падает с ошибкой «command not found». Почему? И что делать? 

У меня есть ответы на эти вопросы.

Современный веб практически немыслим без медиаконтента: смартфоны есть практически у каждой нашей бабушки, все сидят в соцсетях, и простои в обслуживании дорого обходятся компаниям. Вашему вниманию расшифровка рассказа компании Badoo о том, как она организовала отдачу фотографий с помощью аппаратного решения, с какими проблемами производительности столкнулась в процессе, чем они были вызваны, ну и как эти проблемы были решены с помощью софтового решения на основе Nginx, обеспечив при этом отказоустойчивость на всех уровнях (видео). Благодарим авторов рассказа Олега Sannis Ефимова и Александра Дымова, которые поделились своим опытом на конференции Uptime day 4.

— Начнем с небольшого введения о том, как мы храним и кэшируем фотографии. У нас есть слой, на котором мы их храним, и слой, где мы фотографии кэшируем. При этом, если мы хотим добиваться большого хитрейта и снижать нагрузку на стораджи, нам важно, чтобы каждая фотография отдельного пользователя лежала на одном кэширующем сервере. Иначе нам пришлось бы ставить во столько раз больше дисков, во сколько у нас больше серверов. Хитрейт у нас в районе 99%, то есть мы в 100 раз снижаем нагрузку на наши storage, и для того, чтобы это сделать, еще 10 лет назад, когда все это строилось, у нас было 50 серверов. Соответственно, для того, чтобы эти фотографии отдавать, нам нужно было по сути 50 внешних доменов, которые эти серверы обслуживают.

Естественно, сразу встал вопрос: а если у нас один сервер упадет, будет недоступен, какую часть трафика мы теряем? Мы посмотрели, что есть на рынке, и решили купить железку, чтобы она решила все наши проблемы. Выбор пал на решение компании F5-network (которая, кстати, не так давно купила NGINX, Inc): BIG-IP Local Traffic Manager.

Несколько лет назад мы в Badoo начали использовать MVI-подход к Android-разработке. Он был призван упростить сложную кодовую базу и избежать проблемы некорректных состояний: в простых сценариях это легко, но чем сложнее система, тем сложнее поддерживать её в корректном виде и тем проще пропустить баг. 

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

Наш коллега Zsolt Kocsi (Medium, Twitter) из лондонского офиса рассказал, каким образом с помощью MVI мы строим независимые компоненты, которые легко переиспользовать, какие преимущества мы получаем и с какими недостатками нам пришлось столкнуться при использовании этого подхода.