Доклады

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

Где брать опыт когда ты Junior

Как развиваться в позиции Middle

Как не забуксовать будучи Senior

Куда уходят Сеньеры

Максимально широкое и подробное описание текущей (на начало 2020) программной и немного аппаратной архитектуры ВКонтакте, а также компромиссов, проблем и связанных с ними планов на будущее:

* Типы серверов и зачем нам их столько;

* Наши доморощенные БД;

* Немного про frontend часть;

* KPHP сегодня;

* PHP и Go в нашем продакшене;

* Деплой, мониторинг и откаты (куда без них);

* Подходы к отказоустойчивости в реалиях большого проекта.

Продукты ABBYY работают по всему миру. Никакой процессинг документа невозможен без распознавания текста, которым этот документ набран. Я расскажу, какие наработки есть у нашего RnD в разных языках, как наши модели «читают» хангыль, иероглифы и арабскую вязь. А заодно на этих примерах покажу серию простых трюков, о которых стоит помнить, когда решаешь любую задачу классификации.

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

В рамках доклада будут рассмотрены основные методики работы с базами данных для разработчиков, с особым акцентом на наиболее популярных открытых СУБД — MySQL, PostgreSQL и MongoDB.

Пользователь закрывает вкладку в браузере, и ваше замечательное фронтенд-приложение испаряется. А что если можно было бы оставить какие-то его части еще немного поработать во благо улучшения UX? Отреагировать на какие-то события, завершить начатое общение с сетью - в общем, исполнить немного кода при закрытой вкладке и даже браузере. Я расскажу о разных интересных возможностях API из семейства сервис-воркеров, позволяющих продлить жизнь приложения, чтобы всегда иметь под рукой свежие данные, не бояться проблем с сетью, уметь показывать уведомления - все ради отличного пользовательского опыта.

Профессиональное выгорание: кто виноват и что делать. Рассказ от первого лица.

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

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

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

Тезисы доклада уточняются

DevOps — это заговор сисадминов, чтобы заставить разработчиков делать чужую работу, но мы слишком умны, чтобы попасться на эту элементарную уловку ребрендингом! Посудите сами: мы написали код, он проходит тесты. Он, очевидно, работает и работает хорошо (Мы гордимся собой? Да!). И тут мы закончили.

Но приходят эти «визионеры» (все из operations, прошу заметить!) и рассказывают нам, что теперь надо учить YAML, Docker, Kubernetes и Terraform, потому что внезапно это наша головная боль?!

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

Разработчики часто пишут все, что могут в логи. И думают: когда-нибудь пригодится. И что мы имеем на самом деле?

Непрозрачные системы. Сложную инфраструктуру и корявые абстракции в коде. Гигабайты мусора, смотреть и читать которые – невозможно.

Я расскажу, как жить без логов.

Все книги, наставления и методички пишут, что без лидерства менеджеров не бывает. Вбейте в поисковике “Leadership principles”, и на вас тут же прыгнут “Amazon, 7 ways to success”, “Apple story” и прочие красивые истории. И они работают! Ну, в теории. Непонятно правда, что делать, если в книге написано, что “Insist on the highest standards”, а у тебя кругом пожар, команда - не команда, а сроки - вчера.

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

Anomaly detection suffers from unbalanced data since anomalies are quite rare. Generating artificial anomalies is a solution to such ill or not fully defined data. I will present a two-level hierarchical latent space representation that distills inliers’ feature-descriptors into more robust representations based on a variational family of distributions for zero-shot anomaly generation.

Расскажу как можно строить рекомендательные системы, на основе нестандартных подходов: от аплифт деревьев и Баеса, до Reinforcement Learning и счетчиков

– Миллионы на таргет. Как работать с выгоранием аудиторий

– Новые каналы. Практика внедрения Яндекс Дзена и Телеграма

– Новый подход в подсчете конверсий через Атрибуцию Facebook

Расскажу про роли и процессы в разработке mindbox. Результат 13ти лет эволюции Agile в бизнесе, где разработчик стал совладельцем и CEO.

• Архитектор, скрам-мастер, продукт, стейкхолдер — кто это?
• За что отвечает команда разработки
• Как создать гильдии вокруг демо
• Что измеряем вместо скорости
• Какие инструменты используем
• Как применяем социократию и самоуправления: роль открытого P&L и самоназначения ЗП

В нашей разработке 60 человек, 7 команд, 500 млн в год выручка продукта и быстро растем.

А что если, клиентский опыт, это не только «вижу» и «делаю», но и «чувствую», «думаю». Как вам мысль о том,что “продуктовые” дизайнеры на самом деле не умеют проектировать опыт и создавать продукты. А что если, гейм-дизайнеры, режиссеры и музыканты, это лучшие UX-проектировщики и продуктовики и нам срочно нужно у них всему учиться...

Расскажем как мы это видим в Сбербанке, подискутируем в процессе и праведно похоливарим в кулуарах.

Я - разработчик со стажем более 15 лет. И я также был тимлидом более трех лет. И знаете что? За время управления командами я узнал вещи, про которые мне никто не рассказывал, пока я был разработчиком. И очень зря...

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

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

Давайте тезисно, наглядно, “на пальцах” в QA Automation контексте проговорим ключевые для каждого по-настоящему опытного Автоматизатора 21 века, инженерные практики.

— Что нужно знать при переходе на подписную модель;

— Какой контент помогает продавать подписку;

— Какая модель продажи подписки работает в России;

— Как взаимодействовать с аудиторией, чтобы привлекать посетителей и конвертировалась их в подписчиков;

— Немного о пользовательском опыте и банковских процессингах;

— На какие метрики ориентироваться при прогнозировании отказа от продления подписки и как проводить передпописную кампанию.

Короткий ответ: возможно, это гораздо проще, чем вы думаете.

Это доклад для тех, кто чувствует, что «уже не торт» и теряет контакт с привычной аудиторией, потому что она ушла на другие площадки.

А ещё для компаний, которые хотели бы пользоваться Хабром как коллективным блогом, но на него (уже, ещё или совсем) нет денег.

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

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

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

Один из самых простых и популярных способов «устроить highload на ровном месте» — это написать пару необдуманных строк, изменяющих схему БД, и выложить это в «прод» без обстоятельного тестирования.

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

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

И наконец, основываясь на многолетнем опыте работы с быстрорастущими командами, обсудим организационные вопросы — как выстроить процессы разработки так, чтобы риски простоя и деградации производительности были сведены к минимуму, а команды разработчиков развивались и постоянно наращивали экспертизу работы с БД.

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

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

1. Вынужденная удалёнка. А вдруг им понравится? А им – понравится!

2. Что удерживает людей в компании на самом деле? Баланс мотиваторов

3. Ресурсное мышление. «КАКИЕ ЛЮДИ НАМ НУЖНЫ» - где поставить ударение? Как перестать закидывать задачи ресурсами.

4. Культура постоянных улучшений. Как не делать лишнего, а делать главное.

5. Новое сотрудничество. Переход от модели собственности к модели доступа.

6. SWOT-анализ. Угрозы и возможности. Проектируем стратегию жизнеобеспечения компании.

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

Многим фронтендерам не нравиться писать типы, многие ошибаются при их написании и использовании. Разработчиков понять можно. По большому счёту, статическая типизация нужна машинам, так почему бы машинам самим её не писать?!

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

История проектного управления (включая проекты по разработке ПО) длится уже более 50 лет, но в последние годы вокруг всё больше применяются гибкие методологии, и мы перестаём замечать, как меняется мир вокруг. Я расскажу о тех практиках, которые можно применять не только в работе, но и в жизни, и покажу на примерах, почему это работает.

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

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

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