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



Вообще все в nginx — это модули, которые когда-то кем-то были написаны. Поэтому писать модули под nginx не только можно, но и нужно. Когда это необходимо делать и зачем, расскажет Василий Сошников (dedokOne) на примере нескольких кейсов.

Поговорим о причинах, которые побуждают писать модули на C, об архитектуре и ядре nginx, анатомии HTTP-модулей, о C-модулях, NJS, Lua и nginx.conf. Это важно знать не только тем, кто разрабатывает под nginx, но также тем, кто использует nginx-конфиги, Lua или другой язык внутри nginx.

Примечание: статья написана на основе доклада Василия Сошникова. Доклад постоянно модернизируется и обновляется. Информация в материале довольно техническая и, чтобы извлечь максимум пользы, читателям необходимо иметь опыт работы с кодом nginx на среднем уровне и выше.

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

Константин Мордань, iOS-разработчик из Mail.ru в своей работе повидал всякое: проанализировав способы управления клавиатурой в iOS, он решил поделиться основными найденными багами и подходами, которые применял для их обнаружения и исправления.



Осторожно: под кат мы поместили много гифок, чтобы наглядно демонстрировать баги. А еще больше примеров вы найдете в видео доклада Константина на AppsConf.

Zabbix — это система мониторинга. Как и любая другая система, она сталкивается с тремя основными проблемами всех систем мониторинга: сбор и обработка данных, хранение истории, ее очистка.

Этапы получения, обработки и записи данных занимают время. Немного, но для крупной системы это может выливаться в большие задержки. Проблема хранения — это вопрос доступа к данным. Они используются для отчетов, проверок и триггеров. Задержки при доступе к данным также влияют на производительность. Когда БД разрастаются, неактуальные данные приходится удалять. Удаление — это тяжелая операция, которая также съедает часть ресурсов.



Проблемы задержек при сборе и хранении в Zabbix решаются кэшированием: несколько видов кэшей, кэширование в БД. Для решения третьей проблемы кэширование не подходит, поэтому в Zabbix применили TimescaleDB. Об этом расскажет Андрей Гущин — инженер технической поддержки Zabbix SIA. В поддержке Zabbix Андрей больше 6 лет и напрямую сталкивается с производительностью.

Как работает TimescaleDB, какую производительность может дать по сравнению с обычным PostgreSQL? Какую роль играет Zabbix для БД TimescaleDB? Как запустить с нуля и как мигрировать с PostgreSQL и производительность какой конфигурации лучше? Обо всем этом под катом.

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

Мы в AppsConf думаем, что всем нам необходимо иногда выходить за пределы мобильной разработки и прокачивать шляпку буквы T в модели T-shape. Вот, например, познакомиться с серверными языками чуть глубже, чем: «Я слышал, что Ruby умер». И чуть шире — то есть не только с популярными, но и из вторых рядов и даже андеграундными.

Чтобы и вы прониклись идеей Introductory-трека, записали интервью с Никитой Соболевым. Собирались говорить о языках программирования, а получилось о программистах. Заходите под кат, если считаете, что лучше быть просто хорошим разработчиком, а не Android- или iOS-разработчиком, а особенно, если не согласны с этим. Пятница — самое время поспорить.

Кажется, что IT-инженерам легко живется. Они хорошо зарабатывают и свободно перемещаются между работодателями и странами. Но это все не просто так. «Типичный айтишник» красноглазит за компьютером со школы, а потом еще в университете, магистратуре, аспирантуре… Дальше работа, работа, работа, годы продакшн, и только тогда переезд. А потом опять работа.

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



Переезд в другой город, страну, континент или планету не так уж прост. Иной менталитет, культура, правила, законы, цены, медицина, а еще надо найти куда переезжать, оффер, жилье, сделать визу… тысячи нюансов. Как не получить нервный тик, а только максимальную выгоду и удовольствие от процесса, расскажет Денис Неклюдов (nekdenis).

По каким причинам люди уезжают, что их ждет там и как выбирать, куда переехать? Как сориентироваться на рынке труда, найти работу, подготовиться к интервью и выбрать самый выгодный оффер. На примере переездов Дениса на Пхукет, в Сингапур, Сан-Франциско и опыта множества других экспатов подготовимся к новым приключениям. Рассказ Дениса — это дорожная карта или чек-лист, который будет полезен всем, кто задумывается о переезде.

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

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

Юрий Бадальянц на РИТ++ рассказал, как в 2ГИС тестируют связку из большого числа сервисов и целого зоопарка технологий. Под катом дополненная и актуализированная под тщательным присмотром спикера версия этого доклада: какие варианты пробовали, к чему пришли, какие проблемы теперь вам не придется решать. Будет про Docker, Testcontainers, а также про Scala.

Голосовые помощники — не далёкое будущее, а реальная действительность. Alexa, Siri, Google Now, Алиса встроены в «умные» колонки, часы и телефоны. Они постепенно меняют наш способ взаимодействия с приложениями и устройствами. Через ассистента можно узнать прогноз погоды, купить билеты на самолет, заказать такси, послушать музыку и включить чайник на кухне, лежа на диване в другой комнате.



Siri или Alexa говорят с пользователями в основном по-английски, поэтому в России они не так популярны, как Алиса от Яндекса. Для разработчиков Алиса тоже удобнее: её создатели ведут блог, выкладывают удобные инструменты на GitHub и помогают встраивать ассистента в новые устройства.

Никита Дубко (@dark_mefody в Твиттере) — разработчик интерфейсов в Яндекс, организатор митапов MinskCSS и MinskJS и редактор новостей в Web-стандартах. Никита не работает в Яндекс.Диалогах и никак не связан с Яндекс.Алисой. Но ему было интересно разобраться, как Алиса работает, поэтому он попробовал применить её навыки для Web и подготовил об этом доклад на FrontendConf РИТ++. В расшифровке доклада Никиты рассмотрим, что полезного могут принести голосовые помощники и построим навык прямо в процессе чтения этого материала.

Мы обещали 5-6 причин перейти на Go, так и получилось! На GolangConf — конференции полностью посвященной Go — 7 октября будет 5 докладов с пометкой «Переход на Go» для тех, кто только собирается или начинает использовать этот язык в своих проектах.

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



В программе конференции 21 доклад, сессия блиц-докладов и митапы. В любое время гости конференции смогут выбрать из 3–4 разных тем и найти для себя что-нибудь интересное. Думаю даже, что более актуальной будет проблема выбора и невозможность разорваться между потоками (хорошо, что потом все будет на видео). Одновременно в разных залах будут обсуждаться темы, актуальные самым разным специалистам.

23-24 сентября 2019 в Санкт-Петербурге прошла конференция Saint TeamLead Conf 2019 для святых тимлидов и руководителей команд разработки/тестирования. Команда оргкомитета конференции под руководством Романа Ивлиева (СТО MOS.RU) провела титаническую работу — за полгода было принято и обработано 123 заявки, отобрано 42 доклада из 36 компаний, подготовлено 12 митапов и workshop-ов, приглашено 6 экспертов для выступления и дискуссии в специально отведенной зоне.

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



Накануне FrontendConf мы взяли у интервью у Сергея Попова (@sergeytovarov) и расспросили обо всем подробнее. Сергей — участник ПК, руководитель Лига А., выступающий спикер. Мы узнали о том, как идет подготовка к конференции, какие доклады он берет на курирование и чего от них ждать зрителям, для чего он выступает, о чем его новый доклад и зачем ходить на конференции.

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

Все началось в 2015-м году, когда мы, Экспресс 42, совместно с Онтико воссоздали конференцию RootConf. Формально направление конференции значилось как «Профессиональная конференция по эксплуатации и DevOps», но фактически на докладах в основном обсуждали задачи системного администрирования.

В 2018-м стало понятно, что в мире, где Dev и Ops живут в одном общем процессе, конференция только про системное администрирование уже неактуальна. Тогда мы начали постепенно менять формат конференции. Теперь наша конференция обо всем, что касается DevOps — от Kubernetes, до обсуждения изменения процессов и эффективного обмена знаниями.



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

Что объединяет Trello, Gmail, Aviasales и Google Keep? В каждом из них есть Drag-&-Drop-компоненты, которые можно перетаскивать мышкой. Использование этих компонентов делает сайты по-настоящему удобными, потому что в реальной жизни мы часто используем этот паттерн. Передвигать вещи для нас естественно, поэтому и в вебе мы хотим перемещать элементы по экрану с одного места на другое, как стикеры на доске или магнитики на холодильнике. Сортировка todo-списков, организация дашбордов, загрузка файлов — мы просто не можем себе представить все эти события без перетаскивания элементов на странице.



Но есть нюанс. Когда мы разрабатываем такие компоненты, то думаем, что наши пользователи физически видят экран и элементы, могут зацепиться за них мышкой и перетащить.Часто так и есть, но мы забываем о сегменте пользователей с проблемами зрения. Мы создаем компоненты, которыми невозможно пользоваться большой группе людей, которая просто их не видит. Как сделать так, чтобы им тоже были доступны Drag-&-Drop-компоненты?

Сергей Кригер — фронтенд-разработчик в компании SinnerSchrader. Кроме фронтенд-разработки, активно интересуется темой веб-доступности и расскажет о некоторых способах ее повышения. Под катом — рассказ о создании Drag-&-Drop-компонентов для тех, кто не видит экран и пользуется другими устройствами для взаимодействия с браузером.

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

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



Если хотите, то короткая выжимка нашего гида по DevOpsConf:

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

Однажды фронтендеру позвонил дизайнер и попросил сделать «паутинку» за запотевшим стеклом. Но потом оказалось, что это не «паутинка», а гексагональная сетка, и не за стеклом, а она уходит вдаль, и с WebGL фронтендер не знаком, а всей анимации пришлось учиться в процессе рисования. Тем фронтендером был Юрий Артюх (akella).



Юрий давно занимается версткой, а по воскресеньям записывает стримы с разбором реальных проектов. Он не профи в WebGL, не делает на нем карты, не пишет на Web-ассемблере, но ему нравится учиться чему-то новому. На FrontendConf РИТ++ Юрий рассказал, как провести одну анимацию от макета до сдачи клиенту так, чтобы все были довольны, и по дороге изучить WebGL. История идет от первого лица и включает в себя: Three.js, GLSL, Canvas 2D, графы и немного математики.

Записывайте рецепт микровиртуалок Firecracker. Берем два популярных метода изоляции многопользовательской нагрузки — виртуальные машины и контейнеры. Выжимаем лучшее из обоих подходов, максимально упрощаем, тестируем на настоящем хайлоаде. В итоге получаем непробиваемую изоляцию виртуалок, которые можно запускать за сотни миллисекунд. Именно это решение работает под капотом AWS Lambda и Fargate, запуская в облаке миллионы serverless-функций и контейнеров каждую секунду. Оно называется Firecracker.



Этот инструмент микровиртуализации доступен в OpenSource. Если ваши задачи требуют мульти-тенантной изоляции, (ну, например, вы решили сделать собственное облако), Firecracker — это то, что надо.

Василий Пантюхин, архитектор Amazon Web Services, расскажет об архитектуре Firecracker, о том, как он используется AWS Lambda, сравнит его с альтернативными решениями и приведет примеры интеграции.

Дисклеймер: всё, что ниже — это личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.

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

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

До понимания, что инфраструктура IT-компании это тоже продукт, что у нее есть цель, что надо считать затраты и отслеживать метрики, дело часто не доходит.


Знаете ли вы сколько стоит ваша инфраструктура: серверы, ПО, внешние сервисы? Как вы считаете затраты на нее, по каким метрикам? Сколько вы потеряете, если что-то упадет или не будет бэкапа? Ответы на эти вопросы знает Артём Науменко (@entsu) из Skyeng. Он работал как в компаниях с двумя разработчиками в штате, так и в корпорациях с тысячей сотрудников. Сейчас руководит инфраструктурой в Skyeng и, одновременно, СТО детского обучения Skyeng. Артем расскажет как в компании строят инфраструктуру, как зарабатывают на ней деньги и какие ошибки не стоит допускать.

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

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

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

Сказано — сделано. В Питере 23 и 24 числа в рамках Saint TeamLead Conf для этого будет два отдельных трека, в которые мы уже разместили 9 митапов. О них и пойдёт речь ниже.

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



Если ваша архитектура полностью соответствует Reactive-манифесту, составные части приложения неограниченно масштабируются с возрастанием нагрузки независимо друг от друга, и выдерживают падение любого узла, — вы знаете ответ. Но если нет, то Олег Нижников (Odomontois) расскажет, как проблему масштабируемости решили в Тинькофф, построив свой безболезненный Fallback Cache на Scala, не переписывая приложение.

Примечание. В статье будет минимум кода на Scala и максимум общих принципов и идей.

Привет! Меня зовут Евгения Голева, я выступила на TeamLeadConf с докладом про обратную связь и хочу поделиться с вами его вольной расшифровкой. Мне удалось под соусом совсем другого проекта научить инженеров давать обратную связь гораздо лучше, чем они делали это раньше. Для этого пришлось не только долго и тщательно объяснять «зачем и как», но и организовать множество подходов к снаряду под бдительным контролем и с мягкой поддержкой. Путь был непростым, усеян граблями и велосипедами, и я надеюсь, что некоторые неочевидные мысли и методы пригодятся тем, кто хотел бы привить культуру здорового фидбэка своей команде.