Фото Roman Pronskiy

Это перевод поста одного из главных разработчиков языка Go, Расса Кокса, где он в традиционном для новогоднего времени формате дает себе обещания и планирует выполнить их.

Наступило время принятия решений, и я подумал, что имеет смысл немного рассказать о том, над чем я хочу работать в наступившем году применительно к Go.

Каждый год я ставлю перед собой цель — помочь Go-разработчикам. Я хочу быть уверен, что то, что делают создатели Go, оказывает положительное влияние на всех Go-разработчиков. Потому что у них есть масса способов совершить ошибку: например, можно потратить слишком много времени на очистку или оптимизацию кода, которому это не требуется; откликаться только на самые распространенные или недавние жалобы и запросы; излишне сосредотачиваться на краткосрочных улучшениях. Поэтому так важно взглянуть на все со стороны и заняться тем, что принесет больше всего пользы для Go-сообщества.

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

Вы уже используете прогрессивную загрузку? А как насчёт технологий Tree Shaking и разбиения кода в React и Angular? Вы настроили сжатие Brotli или Zopfli, OCSP stapling и HPACK-сжатие? А как у вас обстоят дела с оптимизацией ресурсов и клиентской части, со вложенностью CSS? Не говоря уже о IPv6, HTTP/2 и сервис-воркерах.

Привет, Хабр! Мы в Badoo стараемся активно участвовать в жизни IT-сообщества: используем многие open-source-технологии и инструменты, а также делимся своими разработками.

Один из таких инструментов – Pinba – сервис для получения realtime-статистики от работающих приложений без накладных расходов на её сбор. Узнать побольше вы можете в этой статье.

Мы стараемся помочь всем, кто использует Pinba в своих проектах и всегда рады слышать success stories, связанные с Pinba. Этот перевод – одна из подобных историй от разработчиков Dailymotion.

Кадр из сериала «Коломбо»

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

Если кратко: в этом посте мы рассмотрим один из множества способов запуска бесконечного выполнения кода Javascript в браузере с помощью Service Worker, а еще немного покритикуем саму технологию.

Привет, Хабр! Меня зовут Марко Кевац, я системный программист Badoo в команде «Платформа», и я очень люблю Go. Если сложить эти две вещи, то вы поймёте, насколько я люблю ассемблер в Go.

Совсем недавно мы рассказывали на Хабре о том, на каких конференциях побывали. Одной из них была GopherCon 2016, где практически всем запомнился доклад Роба «Командира» Пайка про Go-шный ассемблер. Представляю вам перевод его доклада, оформленный в виде статьи. Я постарался дать в тексте как можно больше ссылок на релевантные статьи в «Википедии».

Может ли самый первый релиз продукта быть достаточно хорошо оттестированным, или кучу шишек неизбежно набьёшь уже в продакшене? Конференция по тестированию «Гейзенбаг», которую мы недавно провели в Москве, состоялась в самый первый раз, так что можно было на её наглядном примере и посмотреть. Как она прошла? Возникли ли проблемы? И как вообще должна выглядеть конференция по тестированию, если внутри него существуют подвиды с совершенно разной спецификой, а дело с ним имеют специалисты разного профиля?

Привет! Я Катя, и я – трудоголик тестировщик самого популярного приложения для новых знакомств.

Итак, раннее утро, вы – мобильный QA. Вы приходите на работу, завариваете крепкий кофе и хотите взять пару мобильных устройств для тестирования новой фичи, осознавая, какие муки выбора вам предстоят. Что это будут за устройства?

Рано или поздно каждый мобильный тестировщик задаётся вопросом, на каком количестве устройств тестировать новый функционал, чтобы поймать максимальное количество девайсозависимых багов, потратив минимум времени. Автотесты ещё не написаны, перед вами абсолютно новые фичи. И если с iOS есть хоть какая-то ясность, и список устройств ограничен, то Android «расплодился» в полнейший ад. Вы удивитесь, но для счастья нужно всего три–четыре Android-устройства. Я хочу рассказать, как с точки зрения опытного тестировщика их выбрать.

Здравствуй, Хабр! Сегодня я хочу завершить цикл статей об организации тестирования (начавшийся с изучения ошибок и опыта), рассказав о том, как же все-таки Badoo выпускает два качественных серверных релиза каждый день. Кроме пятницы, когда мы релизимся только утром. Не надо релизиться в пятницу вечером.

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

В Badoo существует несколько разных QA-флоу, отличие которых обосновано разными средствами разработки и целевыми платформами (но мы используем для них общие системы: JIRA, TeamCity, Git и т.д.), и я вам расскажу о процессе тестирования и деплоя наших серверных задач (а заодно и веб-сайта). Его можно условно разделить на 5 больших этапов (хотя тут, конечно, многие мои коллеги считают по-разному), каждый из которых включает в себя и ручную, и автоматизированную составляющую. Постараюсь рассказать вам по очереди о каждом из них, отдельно выделяя то, что изменялось и развивалось в последние годы.

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

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

Нам очень нравится формат AMA (ask me anything) на Reddit, когда кто-нибудь (в нашем случае – команда разработчиков) приходит в сабреддит AMA и говорит, что готов отвечать на заданные вопросы. Из самых запоминающихся сессий Ask Me Anything, например, команда инженеров Space X, или инженеры из Google, и даже действующий президент США Барак Обама четыре года назад отвечал на вопросы на Реддите. Недавно наша Android-команда проводила AMA и в онлайн-режиме отвечала на вопросы разработчиков.

Но в России нет своего Реддита. Зато есть свой Хабр. Поэтому мы решили прийти с форматом «задай нам вопрос» сюда. И не с пустыми руками, как велят правила AMA. Чтобы вам было проще понять тему, мы выбрали одну из наших команд – «Платформу» – и попросили ребят рассказать, чем они занимаются, на чём программируют и чего добились за время существования команды. И подвели небольшие итоги уходящего 2016 года. Поехали!

Оглавление

1. Чем занимается «Платформа»
2. Сервисы: Pinba, SoftMocks и другие
3. Системное программирование. Как мы начали использовать Go и к чему это привело
4. Фотографии
5. Скриптовое облако
6. LSD: Live Streaming Daemon
7. Cassandra Time Series: что это и как работает
8. Badoo AMA: задай вопрос разработчикам «Платформы»

Пруф, что это действительно мы.

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

В Badoo релизы происходят довольно часто. Например, серверная часть наравне с desktop web релизится дважды в день. Так что мы не понаслышке знаем, что сложное и медленное тестирование – камень преткновения разработки. Быстрое же тестирование – это счастье. Итак, сегодня я расскажу о том, как в компании Badoo устроено smoke-тестирование.

Аннотация

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

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

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

Я не берусь давать четкие определения видам тестирования в этой статье. Об интерпретации терминов, используемых для названия видов, речь пойдет в третьей части. Связано это разделение с объемом информации.

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

Оглавление

1. CodeFest, Новосибирск, Россия
2. SQA Days 19, Санкт-Петербург, Россия
3. DevConf, Москва, Россия
4. Velocity, Нью-Йорк, США
5. GopherCon, Денвер, США
6. Percona Live, Амстердам, Нидерланды
7. ZendCon, Лас-Вегас, США
8. HighLoad++, Москва, Россия

Недавно мне довелось поработать над прототипом видеочата. Это был отличный повод поближе познакомиться с концепциями WebRTC и опробовать их на практике. Как правило, когда говорят про WebRTC, подразумевают организацию аудио- и видеосвязи, но эта технология может применяться и для других интересных вещей. Я решил попробовать сделать peer-to-peer игру и поделиться опытом ее создания. Видео того что получилось и подробности реализации под катом.

Привет, Хабр! Вот уже больше четырех лет я занимаюсь ручным и автоматизированным тестированием биллинговых систем Badoo. А биллинг Badoo — один из самых развитых (и сложных) в мире, и тестировать его — чаще всего интересная и неординарная задача. Сегодня я хочу вам рассказать, почему эти системы такие интересные и могучие, чему я научился за все эти годы и почему тестировать биллинг — это не (очень) страшно. И заодно поделюсь с вами очередной партией интересных историй (да, я это дело очень люблю). Большинство вещей будет применимо не только к нашему конкретному случаю, но и к любой другой сложной платежной системе (и не только платежной, если честно).

Что же такое наш биллинг? Это система обработки платежей в социальной сети, в которой более 330 миллионов зарегистрированных пользователей. Мы принимаем платежи во всех странах мира, поддерживаем свыше тридцати активных платежных методов (а за все время их было имплементировано около ста) и обрабатываем порядка 1500 запросов в секунду. Биллинг Badoo является самостоятельным выделенным сервисом, работающим с десятком разных клиентов (разные платформы, разные приложения). Достаточно любопытная база для развития тестирования, не так ли?

Введение в MVP, MVC, MVVM и VIPER. Что между ними общего и в чем разница.

Делаете все по MVC, а получается некрасиво? Сомневаетесь, переходить ли на MVVM? Слышали о VIPER, но не уверены, стоит ли оно того?

В этой статье я кратко рассмотрю некоторые популярные архитектурные паттерны в среде iOS и сравню их в теории и на практике. Больше информации вы найдете при переходе по ссылкам, указанным в тексте.

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

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

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

Badoo — это проект с гигантским git-репозиторием, в котором есть тысячи веток и тегов. Мы используем сильно модифицированный GitPHP (http://gitphp.org) версии 0.2.4, над которой сделали множество надстроек (включая интеграцию с нашим workflow в JIRA, организацию процесса ревью и т.д.). В целом нас этот продукт устраивал, пока мы не стали замечать, что наш основной репозиторий открывается более 20 секунд. И сегодня мы расскажем о том, как мы исследовали производительность GitPHP и каких результатов добились, решая эту проблему.

Расстановка таймеров

При разработке badoo.com в девелоперском окружении мы используем весьма простую debug-панель для расстановки таймеров и отладки SQL-запросов. Поэтому первым делом мы переделали ее в GitPHP и стали измерять время выполнения участков кода, не учитывая вложенные таймеры. Вот так выглядит наша debug-панель:



В первой колонке находится имя вызываемого метода (или действия), во второй — дополнительная информация: аргументы для запуска, начало вывода команды и trace. В последнем столбце находится потраченное на вызов время (в секундах).