Привет! Меня зовут Дмитрий Трофимов (@angryqa во ВКонтакте или @trofimovdigital на просторах интернета). Я тимлид отдела автоматизации тестирования в VK ID. С командой мы проделали большой путь при внедрении автотестов в наш продукт, и на этом пути мастерски овладели принципами написания идеальных тестов, которыми спешу поделиться с вами.

Привет, Хабр! Сегодня годовщина создания команды QA одного из самых нагруженных проектов VK — социальной сети ВКонтакте. Для нас это стало хорошим поводом поговорить о буднях тестировщиков. 

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

На конференциях и в неформальных беседах на работе нет-нет да и возникает разговор о важности работы QA-инженера и его роли в проекте. Это может быть и робкий вопрос коллеги-программиста «А, может, выпустим без QA?», и объёмный доклад.

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

Дисклеймер

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

На звание этой «серебряной пули» по очереди претендуют модные (и не очень) методологии разработки: Scrum, Kanban, XP, RAD, FDD и т. п. Регулярно появляются новые способы и подходы, фреймворки и инструменты. Бизнес-консультанты приходят в компании и делятся своими ноу-хау за немалые деньги, рассказывая, как правильно. А при этом хорошо бы ещё и дёшево, не так ли?

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

Давайте подумаем, что требуется от процесса, какие проблемы нужно решить и какие подходы для этого используют. А заодно я расскажу о том, как делаем мы в Badoo. Это уже третий мой пост подряд в нашем блоге на Хабре. Но на всякий случай представлюсь снова: я – Илья Агеев, руковожу QA в Badoo.

Одним из самых важных факторов, влияющих на скорость разработки и успех запуска проекта, является правильная декомпозиция идеи продакт-менеджера в задачи для непосредственно программирования. Как правильно это делать? Взять сценарий работы новой фичи от продакта и сразу начать кодить? Сначала написать приёмочные тесты, а потом – код, который будет обеспечивать их прохождение? А, может, переложить всё на плечи разработчиков – и пусть они в ходе скрам-покера сами решают?

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

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

Привет, меня зовут Иван Греков, я работаю во фронтенд-команде Badoo, занимаюсь вёрсткой пользовательских интерфейсов на проектах компании.

В работе с макетами интерфейсов я использую графические редакторы, такие как Adobe Photoshop и Sketch. В них все слои по умолчанию представляют собой прямоугольные контейнеры. Когда мы выравниванием один слой по центру относительно другого, то для выравнивания используются центры прямоугольных контейнеров. Такой подход крайне неудобен при работе с иконками, поскольку выравниваемые фигуры могут сильно отличаться от прямоугольных контейнеров. И чем больше несимметричная фигура отличается по площади и по точкам координат от прямоугольника, в границы которого она вписана, тем заметнее разница между центрами фигуры и её контейнера. Это приводит к дисбалансу композиции в интерфейсных иконках.

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

Всем привет! Я Алексей Грезов, разработчик Server Team Badoo. Мы в Badoo всегда стараемся сделать так, чтобы наш код было легко поддерживать, развивать и переиспользовать, ведь от этих параметров зависит, насколько быстро и качественно мы сможем реализовать какую-либо фичу. Одним из способов достижения этой цели является написание такого кода, который просто не позволит совершить ошибку. Максимально строгий интерфейс не даст ошибиться с порядком его вызова. Минимальное количество внутренних состояний гарантирует ожидаемость результатов. На днях я увидел статью, в которой как раз описывается, как применение этих методов упрощает жизнь разработчикам. Итак, предлагаю вашему вниманию перевод статьи про принцип "poka-yoke".

Привет. Меня зовут Марко. Я системный программист в Badoo. Представляю вашему вниманию перевод поста замечательной rakyll о новой фиче в Go 1.9. Мне кажется, что лейблы будут очень полезны для профилирования ваших Go-программ. Мы в Badoo, например, используем аналогичную штуку для того, чтобы тегировать куски кода в наших программах на С. И если срабатывает таймер и в лог выводится стек-трейс, то в дополнение к нему мы выводим такой вот тег. В нем, например, может быть сказано, что мы обрабатывали фотографии пользователя с определенным UID. Это невероятно полезно, и я очень рад, что похожая возможность появилась и в Go.

Всем привет! Меня зовут Александр, я руковожу отделом Data Team в Badoo. Сегодня я расскажу вам о том, как мы выбирали оптимальный алгоритм для вычисления квантилей в нашей распределённой системе обработки событий.

Думаю, что рефакторинг проекта – тема, близкая каждому разработчику. Зачастую мы сталкиваемся с проблемами, когда нам перестает хватать средств IDE и регулярных выражений, и тогда на помощь приходят средства вроде тех, что описаны в этом посте. Codemod скрипты – это очень мощный инструмент. После его освоения станет ясно, что ваш рефакторинг уже никогда уже не будет прежним. Поэтому я перевел этот пост для нашего хабраблога. Желаю приятного прочтения.

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

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

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

Привет, Хабр! Меня зовут Павел Мурзаков, я – PHP-тимлид в Badoo, и сегодня я расскажу вам о новой возможности получить предложение по работе в Лондоне за один день. Как вы, возможно, знаете, недавно в Москве прошло рекрутинговое мероприятие Badoo по поиску мобильных разработчиков. Оно оказалось очень успешным – мы предложили работу в Лондоне восьми ребятам и надеемся скоро увидеть их в составе нашей мобильной команды.

И, чтобы не отставать от наших iOS- и Android-команд (ведь их теперь на восемь человек больше!), мы решили ответить достойно и провести аналогичное мероприятие, на котором рассчитываем найти server-side-коллег нашим новым мобильным разработчикам!

Как известно, RxJava идеально подходит для решения двух задач: обработки потоков событий и работы с асинхронными методами. В одном из предыдущих постов я показал, как можно построить цепочку операторов, обрабатывающую поток событий от сенсора. А сегодня я хочу продемонстрировать, как RxJava применяется для работы с существенно асинхронным API. В качестве такого API я выбрал Camera2 API.

Ниже будет показан пример использования Camera2 API, который пока довольно слабо задокументирован и изучен сообществом. Для его укрощения будет использована RxJava2. Вторая версия этой популярной библиотеки вышла сравнительно недавно, и примеров на ней тоже немного.

Для кого этот пост? Я рассчитываю, что читатель – умудрённый опытом, но всё ещё любознательный Android-разработчик. Очень желательны базовые знания о реактивном программировании (хорошее введение – здесь) и понимание Marble Diagrams. Пост будет полезен тем, кто хочет проникнуться реактивным подходом, а также тем, кто хочет использовать Camera2 API в своих проектах. Предупреждаю, будет много кода!

Исходники проекта можно найти на GitHub.

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

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

Кадр из Top Gear: USA (серия 2)

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

Практически с самого начала в качестве реализации ассоциативных массивов мы использовали Judy. У неё есть C-интерфейс и множество преимуществ. Мы даже используем обёртку для PHP, так как в версиях PHP до 7.0 Judy сильно выигрывает по количеству потребляемой памяти по сравнению со встроенными мапами.

Однако время идёт, и с момента последнего релиза Judy прошло немало лет – самое время посмотреть на альтернативы.

Меня зовут Марко, я – системный программист Badoo в команде «Платформа». Мы с коллегами провели небольшое исследование в поисках альтернатив Judy, сделали выводы и решили поделиться ими с вами.

Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.

Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит