Когда участники HighLoad++ пришли на доклад Александра Крашенинникова, они надеялись услышать про обработку 1 600 000 событий в секунду. Ожидания не оправдались… Потому что во время подготовки к выступлению эта цифра улетела до 1 800 000 — так, на HighLoad++ реальность превосходит ожидания.

3 года назад Александр рассказывал, как в Badoo построили масштабируемую систему near-realtime обработки событий. С тех пор она эволюционировала, в процессе росли объёмы, приходилось решать задачи масштабирования и отказоустойчивости, а в определённый момент потребовались радикальные меры — смена технологического стека.



Из расшифровки вы узнаете, как в Badoo заменили связку Spark + Hadoop на ClickHouse, в 3 раза сэкономили железо и увеличили нагрузку в 6 раз, зачем и какими средствами собирать статистику в проекте, и что с этими данными потом делать.



О спикере: Александр Крашенинников (alexkrash) — Head of Data Engineering в Badoo. Занимается BI-инфраструктурой, масштабированием под нагрузки, руководит командами, которые строят инфраструктуру обработки данных. Обожает всё распределённое: Hadoop, Spark, ClickHouse. Уверен, что классные распределенные системы можно готовить из OpenSource.

Принципы и приёмы обработки очередей

Константин Осипов (Mail.ru)

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

Для начала о себе — я занимаюсь разработкой СУБД Tarantool в Mail.ru. Этот доклад будет об обработке очередей. У нас много очередей внутри системы, фактически вся база данных построена как система массового обслуживания.

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

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

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

Во время собеседований на роль linux/unix администратора во многих IT-компаниях спрашивают, что такое load average, чем nginx отличается от apache httpd и что такое fork. В этой статье я постараюсь объяснить, что рассчитывают услышать в ответ на эти вопросы, и почему.

Здесь важно очень хорошо понимать основы администрирования. В идеальной ситуации при постановке задачи системному администратору выставляют ряд требований. Если же ситуация не идеальная, то, по сути, требование к администратору одно: «Хочу, чтобы всё работало». Иными словами, сервис должен быть доступен 24/7 и, если какое-то решение не удовлетворяет этим требованиям (масштабирование и отказоустойчивость относятся к доступности), то можно сказать, что администратор плохо сделал свою работу. Но если разные решения двух администраторов работают 24/7, как понять, какое из них лучше?

Хороший системный администратор при выборе решения при заданных требованиях ориентируется на два условия: минимальное потребление ресурсов и их сбалансированное распределение.

Вариант, когда одному специалисту нужно 10 серверов для выполнения задания, а второму всего 2, мы рассматривать не будем, что тут лучше – очевидно. Далее под ресурсами я буду понимать ЦПУ (cpu), ОЗУ (ram) и диск (hdd).

Давайте рассмотрим ситуацию: один администратор создал решение, которое требует 10% cpu, 5% ram и 10% hdd от всего вашего оборудования, а второй использовал для этого 1% cpu, 40% ram и 20% hdd. Какое из этих решений лучше? Тут все становится уже не так очевидно. Поэтому хороший администратор всегда должен уметь грамотно подобрать решение, исходя из имеющихся ресурсов.

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

Да и кстати, как это фото связано с Темным Лесником?



Итак, поехали дальше.

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

Я хочу сразу сказать, что в первой части будет мало о самой разработке, а больше именно истории, трудности, социальные аспекты, проблемы с которыми может столкнутся инди разработчик, а также я не могу не упомянуть Москву, покер и спорт — без которых эта история не была бы полной. Итак, прежде, чем я начну с легенды, для того чтобы немного заинтересовать читателя, за время разработки с 2013 года по 2015 год я потолстел на 22кг и превратился из спортивного парня в человека, который с трудом узнавал себя в зеркале, я выпивал в год около тысячи банок ред булла, все началось с одной-двух, сейчас уже бывает редко, чтобы я пил меньше трех. Я спал по пять, а то и четыре часа. В течении двух лет я вставал в будние дни в пять утра и ехал на работу в другой город на электричке, чтобы вечером оставалось время поработать над игрой. Я по глупости отказался от предложения в 250.000 евро на разработку игры. Вероятно итогом такой жизни стало тяжелое воспаление легких, суд с бывшим работодателем, а также серьезные проблемы со спиной из-за постоянно сидячего образа жизни. Ах ну и если этого мало, то я бросил университет и сам уволился с работы!

Что ж поехали…

Сергей Туленцев (TextMaster)

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

Кому будет полезен этот доклад? Это обзорный доклад с претензией на структурированность. Если вы что-то где-то когда-то слышали про NoSQL, то через 40 минут вы будете знать гораздо больше, вы будете легче ориентироваться в терминах и более уверенно выбирать базы данных для своего проекта.

Поговорим также про типичные примеры применения и как не надо применять NoSQL базы данных.

Александр Крижановский ( krizhanovsky, NatSys Lab.)

По Сети уже давно бегает эта картинка, по крайней мере, я ее часто видел на Фейсбуке, и появилась идея рассказать про нее:

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

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

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

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

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

Кто хоть раз тестировал свой WebAPI знает такие инструемнты, как Postman или Advanced REST (экстеншены для Chrome). Эти инструемнты всем удобны, кроме того, что не умеют сами узнавать какие модели принимает API, какие отдает и не предоставляет информацию обо всех возможных эндпоинтах. Это неудобство решает пакет Swashbuckle, который встраивает в проект генерацию Swagger спецификации и UI. Под катом коротко о том, как его прикрутить к проекту и некоторые детали относительно авторизации и работы с «перегруженными» эндпоинтами.

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


< 3% заявлений становились предложениями

Я окончил Hack Reactor в июле 2016, и мне потребовалось почти 3 месяца, прежде чем я принял предложение от Radius Intelligence. Я подавал заявления в 291 компанию, прошел 32 собеседования по телефону и 16 обычных, а также выполнил 13 задач по программированию, 11 из них — в офисах. И получил в итоге 8 предложений. Мне предлагали 60-125 тысяч долларов в компаниях США. В общем 2.8% заявок обернулись для меня выгодными предложениями.

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

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

Вот уже около трех лет я использую в работе принципы Spec By Example, Domain Driven Design и CQRS. За это время накопился опыт практического применения этих практик на платформе .NET. В статье я хочу поделиться нашим опытом и выводами, которые могут быть полезными командам, желающим использовать эти подходы в разработке.

Автор: Вячеслав Михайлов, Solutions Architect

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

Мы разберемся с процессом аутентификации пользователя, работой технологии единого входа (Single sign-on/SSO), дадим общее представлении о технологии OAuth2 и принципах ее работы, не углубляясь в особенности конкретной технической реализации. В следующей статье в качестве примера удачной реализации мы рассмотрим библиотеку Thinktecture Identity Server v3, подробнее остановимся на ее функциональных возможностях, поговорим, как собрать минимальный набор компонент, необходимый для работы в микросервисной архитектуре и достойный использования в боевой системе. В третьей части мы покажем, как расширять эту библиотеку, подстраиваясь под нужды вашей системы, а завершит цикл статей разбор различных сценариев, встречавшихся в жизни многих разработчиков с рекомендациями для каждого случая.

На прошлой неделе BBC рассказала, что для новой версии главной страницы использовала методологию БЭМ, созданную в Яндексе. По такому случаю мы решили поднять материалы мастер-класса «Разрабатываем сайт с нуля на полном стеке БЭМ-технологий» и рассказать вам, как начать использовать полный стек БЭМ-технологий в своих проектах.

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



В статье мы расскажем, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомимся с готовыми библиотеками блоков и инструментами для автоматизации сборки. Покажем, как разные инструменты — например, autoprefixer, css-препроцессор Stylus или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки по БЭМ.

На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельно остановимся на декларативных шаблонах BEMHTML и BEMTREE, которые позволяют преобразовывать данные в БЭМ-дерево, описанное в формате BEMJSON и, затем в HTML. Рассмотрим в деталях, как написать серверную часть приложения по БЭМ-методологии.

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

Я — пентестер, и так получилось, что практически на всех проектах, хотя бы отдаленно связанных с анализом инфраструктуры разработчиков, мне встречаются установленные Jenkins и TeamCity (один раз я даже видел Bamboo). Немного гугла, и я выяснил, что это все — так называемые системы непрерывной интеграции. Конечно, в какой-то момент у меня в голове стали возникать вопросы вроде: «А что это вообще за системы такие?» и «Что с ними можно сделать?», естественно, с точки зрения пентестера. Ответив на поставленные вопросы, мы поймем, какую выгоду потенциальный злоумышленник может извлечь и какой вред нанести в рамках экосистемы разработчика, используя лишь имеющуюся в ней систему непрерывной интеграции.

Agile — это модно

Думаю, что большей части читателей Хабра наверняка знакомы такие ключевые слова, как Agile, Scrum или даже Sprint. Если вдруг нет, то кратко и очень приблизительно это все можно охарактеризовать так: постоянный выпуск новых законченных (т.е. обладающих каким-то конечным набором функций) релизов приложения.
Подробнее можно почитать, например, в Википедии.
Не будем останавливаться на этом подробно, т.к. потенциальному злоумышленнику, для проведения успешной атаки, эти знания особенно и не нужны. Однако стоит заметить, что с каждым днем все больше и больше разработчиков (да большинство!) обращается в Agile-веру, и, конечно, сталкивается с необходимостью как-то управлять всеми этими бесконечными промежуточными релизами. И именно для этой цели и используются системы непрерывной интеграции.

Забегая немного вперед, нужно сказать, почему же эти системы могут заинтересовать злоумышленника (или, в нашем случае, конечно, пентестера) и почему стоит беспокоиться об их безопасности.

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

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

Мы в «Латере» занимаемся созданием биллинга для операторов связи. В блоге на Хабре мы не только рассказываем об особенностях нашей системы и деталях ее разработки (например, обеспечении отказоустойчивости), но и публикуем материалы о работе с инфраструктурой в целом. Инженер проекта Haleby.se написал в блоге материал, в котором рассказал о причинах выбора в качестве инструмента оркестрации Docker-контейнеров технологии Kubernetes. Мы представляем вашему вниманию основные мысли этой заметки.

Здравствуйте, Хабр!

Надеемся не слишком вас шокировать, признавшись в неподдельном интересе к децентрализованным приложениям.



Вместе с автором мы убеждены, что «не биткойном единым» полезны описанные технологии, и в качестве доказательства предлагаем перевод интересной статьи, в которой внятно и убедительно описаны перспективы стека Blockchain