Доклады

- Убьёт ли ИИ фотостоки?

- На каких стоках всё ещё стоит размещаться?

- Как стоки уменьшают авторские вознаграждения?

- Что изменилось для российских контрибьюторов в 2022?

- Тренды на фотостоках в 2023 году: чего больше всего ждут от авторов?

- Бюджет маркетинга - «достаточно» это сколько;

- Кроссфункциональная вовлеченность - зачем она нужна;

- Как выглядит план-капкан;

- Убийственные аргументы защиты бюджета

Расскажем о том, как сделать отказоустойчивый кластер MySQL для высоконагруженного проекта, где на каждый сервер можно писать и читать одновременно и безопасно на основе Galera Cluster.

зачем в соц.сетях нужен именно живой, недушный, несухой контент (Диалог с аудиторией, отстройка от конкурентов, Личный бренд)

примеры сухих текстов по нишам

разбор примеров по основным типам ошибок (канцеляризмы, клише, многомыслие и тд)

приемы, как отредактировать сухой текст до живого

3 приема небанальных продающих схемы текстов, которые сейчас в тренде

7 золотых правил, чтобы текст получился загляденье (писать о том, что реально интересно самому, выделить основную мысль и довести ее до конца, писать в потоке без цензуры, обязательно редактировать, применять образы и метафоры, разговорный стиль, Tone of Voice)

Мы разберем типовое web приложение со стороны backend на компоненты, определим категорию и зону ответственности этих компонентов и посмотрим на их составные части. Основой архитектуры будет использование паттерна Clean Arch, который хорошо себя зарекомендовал. Мы будем предполагать, что работа по выделению доменных областей проведена, стек технологий и сервисы для интеграции выбраны. Если посмотреть на уровни моделью декомпозиции [С4](https://c4model.com/), мы будем проектировать 3 уровень - диаграмму компонентов приложения.

Операционные системы нам кажутся уже устоявшимся миром, но это не так. Требования надежности и безопасности постоянно повышаются, и старые ОС такие как macOS, Windows и Linux здесь безсильны. На сцену выходят ОС на основе микроядра: безопасная операционка KasperskyOS от Лаборатории Касрерского, идущая на смену Андроида Fuchsia от Google и ветеран seL4. Но что такое микроядро и как оно устроено?

Давайте разберем что такое ОС в целом, как работают “монолитные” и новые микро-ядра. Что такое модель MILS. Заглянем под капот и разберемся с базовыми блоками на которых строятся современные микроядра. Разберем на пальцах такие основополагающие механизмы как: capability, message passing и конечно же что делает KasperskyOS более защищенной ОС.

Как рассказывать о своем опыте и шарить экспертизу коллегам?

От скучных daily scrum meeting к интересным стендапам и зажигательным митапам?

Как погружать в контекст, но не перегружать?

Расскажу об опыте моем и компании по подготовке митапов и спикеров.

Остановимся на форматах стендапов, что они дают спикерам и командам. Как это влияет на «пороки команды».

Рассмотрим инструмент обучения спикеров для выступлений внутри команды, донесения информации для топов, работы с внешней аудиторией.

Нередко мы сталкиваемся в работе с трудностями, которые раз за разом не получается эффективно решить. Например:

- откладываем до последнего важную задачу,

- не можем отказать и берем повышенные обязательства,

- сами хватаемся за задачи, которые очевидно не вмещаются в рабочую неделю,

- не можем сказать, что сроки уже точно будут сорваны и из-за этого работаем ночами,

- стесняемся заговорить о повышении,

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

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

У всех практик тайм-менеджмента, эффективной коммуникации и управления есть общий секрет: без совладания с эмоциями они не работают.

Нельзя просто так встать и сказать: "Мы сорвали сроки". Нельзя оставаться спокойным, когда коллеги подводят или манипулируют. Не так просто взять и сесть за работу, когда сама мысль о ней вызывает тошноту.

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

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

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

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

Где-то вам нужно собрать команду с нуля, где-то расширить команду с 5 до 50 человек за 3 месяца, а где-то вывести команду из кризиса за те же 3 месяца, иначе все компании конец. Везде нужен тимлид, но везде нужен разный тимлид, с разными скиллами и разными сферами деятельности.

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

Очень часто тимлиду приходится не только управлять команду, но и участвовать в процессе найма и отбора кандидатов. Поговорим о том, как эффективно настроить этот процесс и сэкономить время при отборе.

- Какая технология в описании вакансии, увеличила количество откликов в 3 раза?

- Как составить сценарий разговора, чтобы рекрутёр мог без вас выявить все красные флаги за первые 15 минут скрининга? Действуем по принципу Fail Fast.

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

Также расскажу о тех лайфхаках, которые нашел для себя за 2 года проведения собеседований.

Бонусом расскажу об особенностях найма в международную команду.

Язык Swift - главный язык разработки мобильных приложений для iOS. Он был представлен 9 лет назад и за это время никогда не останавливался в развитии. Только в его пятой версии за последние годы появились макросы, некопируемые структуры, property wrappers и result builders, инструменты работы с многопоточностью, регулярными выражениями и много что еще. При этом многие новые фишки языка из-за все увеличивающегося темпа работы часто ускользают от программистов и не становятся частью ежедневной рутины.

В докладе я покажу, как развитие Swift уже упростило наш код: сделало проще имплементацию MVVM и классических паттернов проектирования, сериализацию и десериализацию данных, кодогенерацию на примере моков и другие рутинные задачи.

⁃ подход к подбору команды, «роли по Сереже» vs «роли по стандартным типологиям»

⁃ Чем топ-команда отличается от команды разработки

⁃ Цикл жизни команды наложенный на цикл развития ее лидера

⁃ Враги и друзья команды

⁃ Мои ошибки при формировании команды

⁃ 5 советов тем, кто завтра окажется в моей роли

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

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

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

Я расскажу о том, как мы в Cloud изменили стандартные подходы к проектированию приложения...

Из доклада вы узнаете:

* какие боли несет в себе микросервисный подход;

* как не создать микросервисный монолит;

* оптимизации, оптимизации и еще раз оптимизации;

* как работать с консистентностью и Bus-фактором;

* как следить за качеством;

Приходите, скучно не будет.

Доклад основан на реальных событиях.

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

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

Внутри доклада подсветим вопросы:

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

2. Чистый код равно литературный код. Требования к написанию кода сильно изменились. Если раньше программисту было важно разбираться в том, как устроено “железо”, то сегодня во главе угла — умение чётко формулировать: насколько точно разработчик умеет выражать свои мысли, насколько код легко читать и воспринимать.

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

Практика:

— основные ошибки и проблемные моменты, которые часто встречаются на ревью.

— список рекомендаций по неймингу: подбор терминов (с примерами), внедрение политик по единообразному неймингу в компании и др.

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

- надо ли нам думать о надежности нашей системы и от чего это зависит

- как оценить надежность существующей системы

- почему надежность сложно добавить в существующую систему

- какие существуют принципы для проектирования надежных систем

- как выстроить процессы для ее достижения

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

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

- чем привлекать первоклассных специалистов в свои команды;

- как выстроить доверительную коммуникацию между отделами;

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

Скажете, что это утопия? А я отвечу, что реальность.

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

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

В докладе будут затронуты такие темы как:

- Оптимизация изображений и других медиа файлов

- Оптимизация оптимизаторов картинок

- Виды рендеринга страницы и как их выбирать

- Ленивый паттерн (но не разработчик)

- Алгоритмы сжатия файлов

- Разделение кода

- Виды кэширования для различных задач

- Оптимизация данных для пререндеринга

- Оптимизация мультиязычных сайтов

И многое другое.

Я регулярно вижу, как руководители в IT сталкиваются с задачами, которые требуют от них смелости и решительности:

-заявить о себе и достижениях своей команды внутри компании или вовне;

-преодолеть кризис смыслов и после выгорания понять, куда двигаться дальше;

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

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

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

- Цена проблемы. Сколько теряем мы и другие компании на ранних увольнениях;

- Как предсказать текучку и срок жизни сотрудника еще на этапе найма (19 параметров для оценки кандидатов).

- Best practice (не наступайте на наши грабли): как мы адаптировали оценку под себя, внедрили ее в рамках компании и какие получили результаты;

- Готовый к применению чек-лист рекрутера или нанимающего менеджера для оценки срока жизни будущего сотрудника.

— С чего начать коммуникацию с заказчиком

— Определение внутренней стратегии ведения проекта

— Тактика презентации решения в зависимости от типа клиента

— face-to-face с заказчиком (Как не зря сходить в гости к клиенту)

— С чего начать коммуникацию с заказчиком

— Определение внутренней стратегии ведения проекта

— Тактика презентации решения в зависимости от типа клиента

— face-to-face с заказчиком (Как не зря сходить в гости к клиенту)

С фразы «Ставьте задачу досконально» часто начинается путь мучений в отношениях между тем, кто ставит задачу — заказчиком, менеджером продукта или аналитиком — и разработчиками. Этот путь обычно заканчивается тупиком. В докладе я расскажу, почему это происходит, и что делать, чтобы выстроить беспроблемный процесс постановки и передачи задач в разработку.

— Подробно и с примерами расскажу про проблемы стыковки постановщика и разработчика.

— Расскажу, как организовать диалог между ролями и закрыть пробелы в экспертизе и ответственности.

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

— С технической стороны напомню об инструментах для совместного проектирования и постановки задач Impact mapping, сценарии пользователя, User story mapping, 4 context architecture. Расскажу, как наиболее эффективно пользоваться этими инструментами.

⁃ Зачем?

⁃ У нас есть практики менеджмента, значит у нас есть менеджмент?

⁃ Как? Первые шаги!

⁃ Практические кейсы.