Что может заставить такую большую компанию как Lamoda с отлаженным процессом и десятками взаимосвязанных сервисов существенно менять подход? Мотивация может быть совершенно разная: от законодательной до присущего всем программистам желания экспериментировать.

Но это вовсе не значит, что нельзя рассчитывать на дополнительную выгоду. В чем конкретно можно выиграть, если внедрить events-driven API на Kafka, расскажет Сергей Заика (fewald). Про набитые шишки и интересные открытия тоже обязательно будет — не может эксперимент без них обойтись.



Disclaimer: Это статья основана на материалах митапа, который Сергей провел в ноябре 2018 года на HighLoad++. Живой опыт Lamoda работы с Kafka привлек слушателей не меньше, чем на другие доклады из расписания. Нам кажется, это отличный пример того, что всегда можно и нужно находить единомышленников, а организаторы HighLoad++ и дальше будут стараться создавать располагающую к этому атмосферу.

Тема интернета вещей и раньше проскальзывала на конференциях РИТ++ и HighLoad++, но обычно с упором на привычные нам вопросы хранилищ данных или программирования. Но в прошлом году мы решили, что настало время серьезно обсуждать IoT: аппаратное обеспечение, сети передачи данных, промышленное применение, и провели первую конференцию InoThings++ 2018.

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

InoThings++ 2018 показал, что ожидания оправданы, мероприятие прошло на 5 баллов из 5. Как это было, посмотрите и почитайте в статье Олега Артамонова, главы программного комитета и участника всех событий. В этом году, уже 4 апреля, сделаем еще лучше. Наши спикеры — исключительно практики, а в программе только важные темы. Какие именно, читайте под катом.

На нашем рынке нет конференции, которая была бы посвящена PHP. А это все равно что футбольный клуб первой лиги без своего стадиона. Ведь в России PHP на втором месте по числу вакансий для программистов (позади 1C, но впереди Java). У него разветвленная экосистема и гигантская армия «последователей».

Погрустив, участники PHP-сообщества решили исправить ситуацию, для чего скооперировались с нашей командой. Общими стараниями 17 мая в московском «Инфопространстве» пройдет профессиональная конференция для PHP-разработчиков PHP Russia 2019. Перед мероприятием мы поговорили с руководителем программного комитета Александром Макаровым (SamDark) о том, зачем нужен ивент, что он призван изменить, кого на нем ждут с докладами и чем эти доклады будут полезны.

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



Искать технических специалистов можно долго, но работа не ждет, поэтому приходится принимать на работу не достаточно квалифицированные кадры и обучать в процессе. Из вариантов: самообучение в свободное время или курсы и семинары в рабочее, но можно выбрать и игры. Артём Ларин (artem_larin) расскажет почему традиционные способы обучения ненадежны и почему игры — в чём-то лучше остальных.

В первой части рассказа по мотивам выступления Дмитрия Стогова из Zend Technologies на HighLoad++ мы разбирались во внутреннем устройстве PHP. Детально и из первых уст узнали, какие изменениях в базовых структурах данных позволили ускорить PHP 7 более чем в два раза. На этом можно было бы и остановиться, но уже в версии 7.1 разработчики пошли существенно дальше, так как идей по оптимизации у них было еще много.

Накопленный опыт работы над JIT до семёрки теперь можно интерпретировать, смотря на результаты в 7.0 без JIT и на результаты HHVM с JIT. В PHP 7.1 было решено c JIT не работать, а опять обратиться к интерпретатору. Если раньше оптимизации касались интрепретатора, то в этой статье посмотрим на оптимизацию байт-кода, с использованием вывода типов, который реализовали для нашего JIT.



Под катом Дмитрий Стогов покажет, как это все работает, на простом примере.

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

Проблемы исключений

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

Исключения трудно заметить

Существует два типа исключений: «явные» создаются при помощи вызова raise прямо в коде, который вы читаете; «скрытые» запрятаны в используемых функциях, классах, методах.

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

def divide(first: float, second: float) -> float:
    return first / second

Функция просто делит одно число на другое, возвращая float. Типы проверены и можно запустить что-то такое:  

result = divide(1, 0)
print('x / y = ', result)

Заметили? На самом деле до print исполнение программы никогда не дойдет, потому что деление 1 на 0 – невозможная операция, она вызовет ZeroDivisionError. Да, такой код безопасен с точки зрения типов, но его все равно нельзя использовать.

В первый день весны (или пятый месяц зимы, кому как) закончилась подача заявок на KnowledgeConf — конференцию про управление знаниями в IT компаниях. Признаться, итоги Call for Papers превзошли все ожидания. Да, мы понимали, что тема актуальная, видели это на других конференциях и митапах, но что у нее откроется столько новых граней и ракурсов — и подумать не могли.

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

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



Извне кажется, что после дедлайна все только начинается, что мы Программным комитетом только собрались и начинаем разгребать заявки, поэтому взять и обработать еще одну не трудно. Но на самом деле мы вовсе не сидели сложа руки. Но это лишь лирическое отступление, чтобы поделиться тем, как выглядит Call for Papers изнутри ПК, вернемся к докладам.

83 — это почти 3,5 доклада на одно место в программе, и теперь нам предстоит отобрать лучшие и довести их до состояния, близкого к идеалу.

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



В расшифровке доклада Степана Гончарова на AppsConf мы коснемся асинхронности: углубимся в архитектуру мобильных приложений, обсудим, зачем выделять отдельный слой для исполнения асинхронных задач, разберем требования и существующие решения, пройдемся по плюсам и минусам, и рассмотрим одну из реализаций данного подхода. А также узнаем, как управлять асинхронными задачами, зачем каждой задаче свой ID, что такое стратегии исполнения и как они помогают упростить и ускорить разработку всего приложения.

В декабре 2015 вышел PHP 7.0. Компании, которые перешли на «семерку» отметили, что увеличилась производительность, а нагрузка на сервера — уменьшилась. Первыми перешли на семерку Vebia и Etsy, а у нас Badoo, Авито и OLX. Для Badoo переход на семёрку обошелся в 1 млн. долларов экономии на серверах. Благодаря PHP 7 в OLX средняя нагрузка на сервер снизилась в 3 раза, повысилась эффективность и экономия ресурсов.

Дмитрий Стогов из Zend Technologies на HighLoad++ рассказал, благодаря чему повысилась производительность. В расшифровке: о внутреннем устройстве PHP, об идеях в основе версии 7.0, об изменениях в базовых структурах данных и алгоритмах, которые и определили успех.

Disclaimer: На март 2019 года 80% сайтов работают на PHP, и 70% из них — на PHP 5, хотя с 1 января 2019 эта версия не поддерживается. Доклад Дмитрия от 2016 года про принципы, благодаря которым произошел двукратный скачок производительности между PHP 5 и 7, — актуален и в марте 2019. Для половины сайтов — точно.

Original english version of this article is here.

Это название доклада Alex Viscreanu на Moscow Python Conf ++. До выступления еще две недели, но я, конечно, уже обо всем расспросил Алекса и под катом поделюсь спойлерами и бэкстейджем подготовки доклада: что это за опенсорсный Зоопарк такой, что он делает с нашим Python кодом и чем отличается от mypy сотоварищи.

— Расскажи немного о Kiwi, чем ты занимаешься в компании?

Kiwi.com — онлайн турагентство с секретным соусом. Компания основана в Чехии в 2012 под названием Skypicker, а в 2016 сервис сменил название и переехал на Kiwi.com. Сейчас Kiwi.com в пятерке крупнейших агрегаторов авиабилетов в Европе.

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

Чтобы вы оценили наши масштабы, вот цифры о Kiwi.com: 90 000 000+ ежедневных поисков, 25 000 ежедневно продаваемых мест и более 15 000 000 000 доступных комбинаций рейсов.

Игорь Сысоев, разработчик веб-сервера nginx, член большой семьи HighLoad++, не просто стоял у истоков нашей конференции. Я воспринимаю Игоря как своего профессионального учителя, мастера, который научил меня работать и понимать высоконагруженные системы, что на десятилетие определило мой профессиональный путь.

Естественно, я не мог пройти мимо оглушительного успеха команды NGINX… И взял интервью, но не у Игоря (он по-прежнему интроверт-программист), а у инвесторов из фонда Runa Capital, которые десять лет назад разглядели nginx, построили вокруг него бизнес-инфраструктуру, а сейчас вели сделку, беспрецедентную по размеру для российского рынка.

Цель статьи под катом — ещё раз подтвердить — возможно все! Пробуй!

Если по докладу Артёма Малышева (proofit404) будут снимать фильм, то режиссером выступит Квентин Тарантино — один фильм про Django он уже снял, снимет и второй. Все подробности из жизни внутренних механизмов Django от первого байта HTTP-запроса до последнего байта ответа. Феерия работы парсер-форм, остросюжетная компиляция SQL, спецэффекты реализации шаблонизатора для HTML. Кем и как управляется connection pool? Всё это в хронологическом порядке обработки WSGI-объектов. На всех экранах страны — расшифровка «Django under microscope».



О спикере: Артём Малышев — основатель проекта Dry Python и Core-разработчик Django Channels версии 1.0. Пишет на Python 5 лет, помогал организовывать митапы «Rannts» по Python в Нижнем Новгороде. Артём может быть знаком вам под ником PROOFIT404. Презентация к докладу хранится здесь.

«Нужно активнее нести DevOps в массы», — решили мы в прошлом году, провели масштабный ребрендинг RootConf и запустили DevOpsConf, как место, где инженеры смогли обсудить множество насущных проблем и посмотреть на то, что же творится вокруг, чем живут в близких областях, как выходят из похожих, но все же отличных ситуаций. Нам удалось собрать классную программу и, что еще важнее, аудиторию профессионалов, которым боли и их решения были нужны и понятны.

Что ж, не будем останавливаться на достигнутом — продолжим продвижение подхода интеграции процессов разработки, тестирования и эксплуатации уже в мае на РИТ++.


Поскольку DevOps в нашем понимании — это про объединение всех процессов разработки, то фестиваль конференций РИТ++, в котором участвуют и серверные и клиентские разработчики, и управленцы разных уровней, люди, выстраивающие бизнес-процессы, и многие другие специалисты IT, — самое место, чтобы говорить о DevOps.

Александр Рубин работает в компании Percona и не единожды выступал на HighLoad++, знаком участникам как эксперт в MySQL. Логично предположить, что и сегодня речь пойдет про что-то, связанное с MySQL. Это так, но лишь отчасти, потому что еще мы поговорим про интернет вещей. Рассказ будет наполовину развлекательный, особенно первая его часть, в которой посмотрим на девайс, который Александр создал, чтобы собрать урожай абрикосов. Такова уж натура настоящего инженера — хочешь фруктов, а покупаешь плату.

Предыстория

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

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

Latency Numbers Every Programmer Should Know — таблица «задержек, которые должен знать каждый программист». Там собраны средние значения времени для выполнения базовых операций компьютера в 2012-м году. Для этой таблицы есть несколько альтернативных представлений и вот одно из них.


Ссылка на источник схемы

Но какая польза мобильным разработчикам от этой информации в 2019? Кажется, что никакой, но Дмитрий Куркин (SClown) из команды Яндекс.Навигатора задумался: «А как бы таблица выглядела для современного iPhone?». Что из этого получилось, в переработанной текстовой версии доклада Дмитрия на AppsConf.

Для чего это нужно?

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

— Шеф, у нас дыра в безопасности!
— Ну хоть что-то у нас в безопасности...

Привет, Хабр!

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

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

Почему вообще обеспечение безопасности в IoT рассматривают как что-то отдельное и специфическое, непохожее на обеспечение безопасности в классических ИТ-системах?

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

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

Когда участники 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.

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

Сегодня вашему вниманию предлагается текстовая версия нашей беседы с Арсением Габдуллиным, разработчиком Тинькофф-журнала, на тему его будущего доклада на Moscow Python Conf++, но без спойлеров.

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



В беседе участвуют:

• Григорий Петров, евангелист MoscowPython, руководитель программного комитета Moscow Python Conf ++;
• Арсений Габдуллин, разработчик Тинькофф-журнала, докладчик MoscowPython Conf++;
• Злата Обуховская, тимлид Nvidia, евангелист MoscowPython, член программного комитета Moscow Python Conf++;
• Валентин Домбровский, соорганизатор и сооснователь MoscowPython,

Валентин Домбровский: Арсений, твой доклад без спойлеров — о чем ты нам расскажешь на конференции?

Привет, Хабр

За последний год тема национальных стандартов, различных указаний госрегуляторов и прочих связанных вещей стала одной из самых обсуждаемых в российской IoT-сообществе — что, впрочем, совершенно неудивительно, достаточно посмотреть на краткий список свежих событий:

• принятие предварительного национального стандарта на протокол NB-Fi компании «Вавиот»
• рекомендация Минцифры (оно же Минсвязи) при дистанционном съёме показаний приборов учёта электроэнергии пользоваться только и исключительно протоколом XNB компании «Стриж»
• невнятные решения ГКРЧ, провозглашающие что-то непонятное об использовании базовых станций российского производства в LPWAN-сетях
• напоминание РКН и ГКРЧ о порядке регистрации этих базовых станций и самих сетей
• долгожданное и одновременно неожиданное расширение безлицензионных диапазопов

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

Даже призванное быть публичным обсуждение проекта стандарта NB-Fi в Техническом комитете 194 Росстандарта по факту от публики оказалось полностью закрытым.

Мы бы хотели исправить это положение.



Итак, на InoThings++ 2019 (Москва, 4 апреля) пройдёт первое настоящее публичное обсуждение темы национальных стандартов, госрегулирования и господдержки в области Интернета вещей, в котором мы постараемся и представить все возможные точки зрения со стороны докладчиков, и дать возможность слушателям задать свои вопросы.