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

До Saint TeamLead Conf 2021 осталось буквально несколько недель. Мы решили открыть карты и рассказать, что ждет участников питерской конференции для тимлидов (спойлер: 4 секции докладов, 12 мастер-классов и классный нетворкинг).

У Яндекса много самописных сервисов для внутренних задач: Яндекс.Формы, Яндекс.Диск, трекер, календарь. Со временем их решили использовать не только внутри компании, но и за ее пределами. Так появилась платформа Яндекс.Коннект.

Большинство сервисов Коннекта построено на Python V3. В качестве web-фреймворка используется Django, реже Flask и Tornado, а новые чаще пишутся на FastAPI. Сервисы, как и базы PostgreSQL, MySQL и MongoDB, живут в облаке. В качестве очереди сообщений почти везде используется Celery с MongoDB в качестве брокера. Он и стал проблемой.

На Russian Python Week 2020 Владимир Колясинский, разработчик бэкенда сервисов платформы Яндекс.Коннект, рассказал, почему они пользовались связкой Celery MongoDB и почему пришлось отказаться от этого брокера. Он сравнил претендентов: Redis, RabbitMQ и YMQ, с их плюсами и минусами. Подробно разобрал процесс переезда на нового брокера, анализ его состояния и возможные проблемы. И у него получилась пошаговая инструкция, которая пригодится при подборе и настройке брокера. А для любителей разбираться самостоятельно под катом есть расшифровка доклада с конференции.

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

Мы поговорили о том, почему стоит прийти на конференцию тем, кому хочется технологического хардкора, с главой программного комитета TestDriven Conf Екатериной Семеновой. 

Довольно очевидно, что junior-разработчику и тимлиду требуется сильно различающийся набор навыков. И если в случае hard skills всё уже миллион раз проанализировано и посчитано, то о необходимом наборе soft skills в зависимости от должности мы можем только понимать на уровне ощущений и здравого смысла. 

Более того, в нашей индустрии не принято говорить после собеседования, что кандидату отказано из-за его уровня soft skills, хотя мы даже не пытаемся конкретизировать, что конкретно в нём нас не устраивает. Вы наверняка слышали или сами употребляли фразы вроде «просто человек странный», «почему-то не нравится» или «чувствуем, что он не вольется в команду». Но почему? Что на самом деле с ним не так?

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

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

Мы поговорили с Олегом о самых актуальных болях разработчиков высоконагруженных систем и о том, как их предложат решить на конференции Saint Highload++ 2021. 

Григория Петрова, Python-некроманта, совмещающего деятельность директора по техническому маркетингу (по-простому — деврела)  компании Evrone и члена программного комитета Moscow Python Conf знают уже не только питонисты.

Время от времени Григорий возглавляет Программный комитет конференции Python, меняя Валентина Домбровского, нынешнего главу ПК. Так было заведено много лет назад, чтобы каждый председатель не закостенел в организации конференции, выборе докладов и генерации идей.

Мы встретились с Григорием и узнали много интересного. Про трех китов предстоящей конференции Moscow Python Conf++ 2021. Про нейрофизиологию, которая всегда поможет. Про что будет хайп и зачем организаторам нужна фасилитация. Разумеется, мы поговорили про Python (спойлер: асинхронное программирование и Django тоже будут). Узнали, какие нас ждут доклады и какие боли питонистов будут утолены —  обо всем этом читайте под катом.

Три года назад в группе компаний ЦФТ задачи бизнеса потребовали увеличения штата разработчиков в два раза. Перед отделом эксплуатации встало две задачи: не допустить линейного роста OPS и уменьшить TTM, не потеряв при этом в недоступности, непрерывности и безопасности.

В результате в компании теперь есть всё — и NoOps, и DevOps. Где-то пришлось пойти на компромиссы и доработать концепт NoOps напильником под себя. Сергей Бердников, руководитель отдела эксплуатации, сегодня расскажет, что получилось, и разберет — почему.

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

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

Многие проекты на Django начинаются просто: есть база данных и к приложению, которое крутится на сервере, идут обращения. Например, так начиналась Dodo IS (информационная система компании Додо Пицца, где работал автор сегодняшней статьи). Но если использовать Django из коробки, можно натворить много бед и встретить пачку антипаттернов. Возможно, вы встречали такое на старых legacy-проектах.

Евгений Пешков развивает сообщество DDD-практиков, рассказывая, какие проблемы решает Domain-Driven Design (предметно-ориентированное проектирование) в современном мире. На конференции Russian Python Week 2020 он выступил с рассказом об этом. Кстати, 19 августа пройдет встреча DDDevotion-сообщества, присоединяйтесь, будем о чем поговорить.

В сегодняшней статье будет его рассказ про то, как устроен Domain-Driven Design и какие инструменты использует, чтобы наиболее точно описать требования бизнеса и сам бизнес.

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

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

На конференции HighLoad++ Весна 2021 я рассказал, как выстроить коммуникации, чтобы пользователи были на вашей стороне и не отвлекали вас от «пожарного» спасения прода. По мотивам доклада выпустил первую часть, а сегодня поговорим о том, как вести коммуникацию с пользователями, зачем это нужно и о чем говорить, когда вроде бы не о чем  Видео выступления можно посмотреть здесь.

На конференции Russian Python Week 2020 мы пообщались с двумя людьми, от которых непосредственно зависит будущее Python. 

На наши вопросы ответили Core-developer community on Google Cloud Дастин Инграм и Director at Python Software Foundation Кэрол Виллинг. Их ответы о том, чего не хватает языку и как он будет развиваться дальше, вы узнаете, заглянув под кат. 

Бигдата из Xsolla уволила 150 человек. Проанализировала активность каждого сотрудника компании и отсортировала всех по вовлеченности. Ну а основатель освободил от должности 150 человек внизу списка.

Да, форма увольнения (письмом) выбрана ужасно, но по сути, Xsolla пошла на то, что уже давно должны были сделать все российские IT-компании. А именно — перешла к управлению и менеджменту на основе данных. А не чуйки, интуиции и не по понятиям.

Что, если бизнес компании заключается в приеме и обработке платежей во множестве стран в режиме 365/24/7? В этом случае одной из ключевых целей ее сотрудников является доступность сервисов 99,999%. А к CI/CD в таких условиях предъявляются особые требования.

Заместитель директора департамента эксплуатации и разработки сервисных систем ECOMMPAY IT Федор Васильев на конференции HighLoad++ Весна 2021 рассказал об эволюции подходов его компании к деплою нового кода. А мы сделали на основе его доклада полезную статью, которую вы найдете под катом. 

Меня зовут Марина Перескокова. Я проработала в Яндексе 10 лет, и из стажёра-разработчика выросла до руководителя службы разработки фронтенда. За это время получилось поработать над JS API Яндекс.Карт, поруководить фронтендом сервиса yandex.ru/maps и покодить движок для векторной карты на WebGL. По итогам моего тимлидства я написала книгу.

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

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

В прошлой статье я показал, как можно собрать свой Lighthouse. Сегодня пришла очередь применить получившийся трифорс в Performance-тестах, которые мы с командой успешно применяем для оптимизации и ускорения платформ Авито. 

Это не так просто, как хотелось бы. С функциональными тестами всё прозрачно — тест либо проходит успешно, либо фэйлится. А в Perfomance-тесте у вас есть какая-то цифра, и непонятно — хорошая она или плохая. Если бы мы использовали инструмент типа Lighthouse, можно было выставить performance-бюджет, чтобы зафиксировать эту цифру на каком-то уровне. Но для динамической ситуации это не подходит. Расскажу, как это понять и использовать.

Все понимают, что shit happens — и чаще всего не если, а когда. У нас может быть много девяток в SLA, но 100% ни у кого нигде никогда не бывает. Поэтому, когда этот SHIT все-таки HAPPENS, есть два пути. 

Путь первый — проблему можно скрыть, сделав выводы для себя. Под ковер замели — никто ничего не заметил. А тому, кто заметил, сказать: «Да вам показалось, все нормально!» Можно пойти по второму пути: не врать и не бояться. Для этого, конечно, нужна уверенность в себе и своей компетенции. Тогда мы спокойно тушим пожар, а не прикрываем пятую точку (может, даже не свою). 

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

Чем интенсивнее наш feature delivering, тем быстрее падает производительность. И, конечно, приходит время автоматизировать процесс слежения, чтобы просадка не дошла до прода или даже staging-окружения.

Про прод-мониторинг, оптимизацию и ручной анализ производительности легко узнать на web.dev. Но по автоматизации слежения за производительностью до того, как фичи покатятся в прод, информации не так уж много. Сегодня расскажу, как для профилирования собрать практически свой Lighthouse, чтобы проводить performance-тесты и успешно бороться с просадкой в работе команды фронтендеров.

Привет! Меня зовут Александр Ларьяновский, я управляющий партнер Skyeng, онлайн-университета рентабельного образования Skypro. Под катом расскажу о том, как проактивность и погружение в мир бизнеса влияют на профессиональную жизнь разработчиков.

Многие знакомы с методологией Test-Driven Development и, в частности, Behavior-Driven Development. Этот подход к разработке и обеспечению качества ПО набрал большую популярность, поскольку позволяет выстроить четко установленное соответствие между бизнес-требованиями и технической реализацией продукта.

На Russian Python Week 2020 Владислав Мухаматнуров, Senior QA automation на примере проекта голосового ассистента в Tinkoff, рассказал о задачах, которые решает BDD. В своем докладе Влад разобрал, что такое BDD и Gherkin, откуда возникает потребность в поведенческом тестировании на проекте и как выглядит имплементация предметно-ориентированного языка для тестирования, базирующейся на диалогах системы. А под катом мы предлагаем вам прочитать расшифровку доклада.

Все, так или иначе, используют Open Source. Но что делать, если нам нужна новая фича или мы нашли критический баг? Можно, конечно, форкнуть репозиторий и быстро что-то поправить. Но форк нужно поддерживать, а новая версия может оказаться несовместимой с вашей. Например, GitHub потратил полтора года, чтобы обновить фреймворк Ruby on Rails с версии 3.2 до версии 5.2.

Можно отправить pull request. Так вы решите не только свою проблему, но и поможете сообществу. Но у мейнтейнера есть свой Open Source проект и контрибьюторы ему обычно только мешают. Поэтому ваш pull request могут не принять. И первый, и второй, и  десятый.

Как же тогда работать с Open Source? Михаил Грачёв, тимлид из Evrone, расскажет,  как в компании выстроили работу с Open Source и превратили это в культуру. Для тех, кто предпочитает смотреть видео — запись его выступления на TeamLead Conf 2021.