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

Управление продуктом — состоявшаяся дисциплина. На продакт-менеджеров большой спрос, а практических знаний хватает не у всех, поэтому 9 декабря мы проведем профессиональную продуктовую конференцию Product Fest. К её организации и программе мы применяем правило: «Сделать такую конференцию, на которую сами хотели бы сходить».



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

В конце прошлого года, после сделки с «Ростелекомом», мы получили в свое распоряжение облачную SD-WAN/SDN-платформу для предоставления заказчикам ИБ-сервисов. Мы подключили к проекту вендоров, поставляющих свои решения в виртуализованном виде, и получилась огромная махина, которую мы назвали Единой платформой сервисов кибербезопасности, или ЕПСК. Ее ключевая особенность — поставка из облака технологий защиты с возможностью централизованного управления: развертывание и изменение отдельной сетевой функции или глобальная трансформация во всех обслуживаемых офисах занимают считанные минуты. Сегодня расскажем подробнее о ее архитектуре и «начинке».

Никита Дубко — разработчик интерфейсов в компании Яндекс. Помимо работы в Яндексе, Никита участвует в организации англоязычной конференции CSS-Minsk-JS и митапов MinskCSS и MinskJS. На FrontendConf на РИТ++ 2019 Никита выступал с докладом «Алиса, пойдем во фронтенд». В нём описан эксперимент по созданию голосового навыка от Алисы от разработчика, который раньше с ней не работал. Доклад интересен тем, что за время, пока выступает спикер, легко создать такой же навык. Рассказ об Алисе зрители выбрали лучшим на всей конференции.



За плечами Никиты десятки выступлений, на каждое из которых уходят недели. Во время подготовки он изучает много нового материала, тренирует выступления на камеру, среди коллег и друзей, оттачивает сценарий и слайды. Поэтому его доклады интересны, увлекательны и заслуженно получают высшие оценки слушателей. О подготовке к докладам, изменениях в жизни, синдроме самозванца, а также о том как выступать на конференциях, чтобы получить работу в Яндекс, в интервью Никиты Дубко. Это не совсем обычное интервью, а текстовая расшифровка подкаста Frontend Weekend, который ведёт Андрей Смирнов. Что из этого получилось, читайте под катом.

Эта серия интервью приурочена к ScalaConf — к первой настоящей конференции в России, полностью посвященной Scala, которая пройдет 26 ноября. Перед этим событием я взял интервью у 6 свидетелей и «апостолов» зарождения движения Scala в России. Здесь не будет обсуждения Free, Tagless Final, Monix, IO или ZIO, и «попинывания» Future. Моя цель — обсудить Scala в историческом контексте. Я записал все бородатые байки, сгонял в прошлое на 10 лет назад и собрал неактуальные, но интересные истории о языке.



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

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



Традиционно мы несем пользу в 6 основных направлениях. Их «говорящие» названия такие: личное развитие, работа с командой, инструментарий тимлида, развитие осознанности, трансформационные изменения в процессах и людях и выстраивание технологического процесса.

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

Но очень много интересного происходит под капотом. Как многие мобильные приложения, Почта использует push-уведомления, чтобы взаимодействовать с пользователями. Как многие iOS-приложения, Почта теряет часть уведомлений в силу особенностей работы Apple Push Notification Service.

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


Речь пойдет о remote notification, то есть уведомлениях, которые приходят с сервера через APNs (Apple Push Notification Service). Локальные уведомления затрагивать не будем и поговорим о том:

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

Ура! Мы завершили формирование программы конференции UseData Conf 2019! Эта конференция для тех, кто решает практические задачи с помощью методов машинного обучения. Между идеальным алгоритмом в вакууме и его применением на реальных данных часто лежит пропасть. Мы хотим, чтобы те, кто умеет преодолевать эту пропасть, встретились и смогли обменяться опытом.



Магия машинного обучения для управленцев, истории применения ML для анализа эффективности рекламы в телевизоре, беспилотные игрушечные машинки, нефть и автомобильные номера — это лишь часть докладов на UseData 2019. Об этих и других темах подробнее под катом.

Мы уже поднимали тему коммуникации как важнейшего навыка управленца любого уровня. Эффективность коммуникаций в компании напрямую влияет на её развитие, поэтому сегодня подробно обсудим два понятия: развитие и рефлексию.

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


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

Последнее, что хочется увидеть во время дебага кода — это хаос. Но что если этот хаос управляемый и запущен руками самого разработчика? Зачем умышленно устраивать турбулентность в слаженной работе своего приложения, как добиться душевного спокойствия при релизе важных фич и где точно вам пригодится практика хаос-инженерии, читайте в разговоре ведущих подкаста AppsCast с Павлом Осиповым PavelOsipov.

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

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



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

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

Итак, по доброй традиции у нас будет 6 основных направлений нанесения пользы. Ниже их «говорящие» названия:

• Личное развитие. 
• Работа с командой. 
• Инструментарий тимлида.
• Развитие осознанности.
• Трансформационные изменения в процессах и людях.
• Выстраивание технологического процесса. 

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



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

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

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

Всем привет. Расскажу вам про микросервисы, но немного с другой точки зрения, чем Вадим Мадисон в посте «Что мы знаем о микросервисах». Вообще я считаю себя разработчиком баз данных. При чем же тут микросервисы? В Авито используются: Vertica, PostgreSQL, Redis, MongoDB, Tarantool, VoltDB, SQLite… Всего у нас 456+ баз для 849+ сервисов. И с этим как-то нужно жить.

В этом посте я расскажу вам про то, как мы реализовали data discovery в микросервисной архитектуре. Этот пост — вольная расшифровка моего доклада с Highload++ 2018, видео можно посмотреть тут.

Суть рассказа о самом популярном пакетном менеджере для Kubernetes можно было бы изобразить с помощью эмоджи:

• коробка — это Helm (это самое подходящее, что есть в последнем релизе Emoji);
• замок — безопасность;
• человечек — решение проблемы.

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

• Кратко, что такое Helm, если вы не знали или забыли. Какие проблемы он решает и где находится в экосистеме.
• Рассмотрим архитектуру Helm. Ни один разговор о безопасности и о том, как сделать инструмент или решение более безопасным, не может обойтись без понимания архитектуры компонента.
• Обсудим компоненты Helm.
• Самый животрепещущий вопрос — будущее — новая версия Helm 3. 

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

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

Перед вами продолжение истории под названием «Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода» об Agile-трансформации в ivi. На TeamLead Conf технический директор компании Евгений Россинский (eross) рассказал, почему может понадобиться откатить всю реорганизацию команды, как при этом не переругаться и помочь разработчикам, а еще и сохранить и приумножить бизнес-эффективность.

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

С другой стороны, элементы функционального стиля программирования уже проникли в промышленные языки программирования, такие как Swift и Kotlin. Разработчики этих языков прекрасно знакомы с функциональным программированием, поэтому смогли применить его «в малом», предусмотрев многие, хотя и не все, необходимые компоненты. Чем дальше — тем больше части ФП внедряются в промышленные ЯП, и тем качественнее и полнее реализуется поддержка.

Уметь программировать в функциональном стиле полезно, чтобы упрощать себе работу, и сейчас мы посмотрим, как этим воспользоваться!


Виталий Брагилевский — преподаватель ФП, теории алгоритмов и вычислений, автор книги «Haskell in Depth» и участник комитетов Haskell 2020 и наблюдательного комитета компилятора GHC.

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

Надо понимать, часто недостаточно полистать go-database-sql.org. Лучше вооружиться чужим опытом. Еще лучше, если это будет опыт, полученный кровью и потерянными деньгами.

На РИТ++ Никита Соболев (sobolevn) выступил, как он сам назвал это, с проповедью на тему качества кода и процессов в компании. Особо впечатлительных просим налить себе ромашкового чаю, но отойти от экранов не предлагаем. Вы можете не соглашаться ни с одним из тезисов, настаивать, что трёп о сериалах — залог здоровой атмосферы в коллективе, и утверждать, что вам не нужны строгие рамки линтера и CI, чтобы писать хороший код. Но если вы хоть раз винили окружающих в неудачах на работе, вам стоит прочитать или посмотреть рассказ Никиты.

Работали ли вы когда-нибудь на плохой работе?

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



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

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

Да, это была аутсорс-разработка, но не это делало её плохой. Люди сделали ее такой.