Заявки на доклады

Поиск по тегам:
Показать только принятые доклады

Нетривиальное качество

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

Программный комитет ещё не принял решения по этому докладу

Пропаганда инженерных практик

Я расскажу про свой опыт ответов на такие вопросы:
- Почему каждому хорошему разработчику хочется изобрести велосипед? И почему это хорошо?
- Чем велосипеды плохи для команды и проекта? А чем они плохи для разработчика?
- Бывают ли хорошие велосипеды? Чем измеряется качество велосипеда?
- Чья задача "поиск баланса между гранитом науки и велосипедами"?
И посмотрим на мое руководство "Как убедить начальника (не)делать велосипед"

Программный комитет ещё не принял решения по этому докладу

В 2016 году команда Хекслета полностью перевела разработку своих проектов в облака. Сначала это было вынужденное решение, но потом нам понравилось. Оказалось, что у такого подхода есть масса неочевидных плюсов. В этом докладе я расскажу про историю нашего перехода, адаптацию, использование разных редакторов, докер и многое другое. Темы:

* Проблемы разработки на маке: память, докер, среда
* Провайдеры (aws, google, do), коннекты, задержки
* Ненапряжная работа в Vim, VScode
* Правильные терминалы и интеграция с Tmux
* Совместная работа и внешние домены
* HTTPS, Веб-хуки, интеграции с внешними системами
* Terraform, Ansible и друзья
* Батарейка!

Программный комитет ещё не принял решения по этому докладу

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

Поговорим вот о чем:
Почему инспекция не улучшает качество?
Что мы изменили в процессе разработки для предотвращения дефектов? 
Хорошие и плохое пользовательские сценарии
Основы TDD, чтобы не оставить шансов дефектам
Причём здесь документация? 
Несколько вопросов для размышления

Программный комитет ещё не принял решения по этому докладу

Техлид и его команда

Команда разработки не успевает реализовывать запрашиваемый соседними командами функционал, и единственный способ получить от них необходимое — это эскалировать вопрос начальству. Разработчики демотивированы переработками и постоянной рутиной, а бизнес — вклиниванием в беклог инородных задач и частой переприоритизацией. Код и проектная информация заперта по командам, а чтобы банально запустить приложение, нужны секретные знания человека, который сейчас в отпуске... Со временем зрелые команды по наитию решают эти проблемы инженерными практиками и подходами, даже не подозревая, что пришли к InnerSource. Хорошая новость в том, что сообщество энтузиастов из мировых компаний InnerSource Commons делится лайфхаками и правильными рецептами приготовления InnerSource. Принципы open source, уже давно доказавшие свою состоятельность в разработке сложных программ, отлично перекладываются на корпоративные реалии.
Помимо правильного написания слова InnerSource, в докладе рассмотрим случаи, когда нужно нести к себе эту практику, что из мира открытой разработки применимо внутри компании, меры предосторожности, ограничения, побочные эффекты и противопоказания подхода.

Программный комитет ещё не принял решения по этому докладу

Я расскажу о том, как эффективно оказывать влияние в компании - на своего начальника, членов команды и другие подразделения. Мы разберем пошаговую методику оказания влияния, поговорим о типичных ошибках и предложим best-practices для их устранения.
Я отвечу на вопрос - “Как рождается внутреннее сопротивление в организациях и как его преодолевать?”, а Вы сможете узнать как выстроить эффективный обмен влиянием для достижения Ваших целей и задач.

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

Attendees will discover the influence of communications places into action while using your everyday people skills, added with a unique style of active listening.

This is ideal for Software Engineering, Developing & Programming team projects.

•This speech has relevant takeaways your attendees can apply to their occupations.
•The speech is clear regarding the topics that will be addressed.
•The speech demonstrates step by step the passage this lecture will take your attendees on.

•This concept has proven to advanced degrees of success in administration performance and team concept awareness.

•The approach derives from my experience as an adjunct professor (psychology & group dynamics) and experience as an interrinterrogator/profilertage negotiator.

•This research and practice will assist companies, organizations, and groups by merging psychology in consort with Active Listening Skills (ALS), resulting in an accelerated--advanced technique devised to build rapport and enhanced teambuilding mteambuildings presentation will allow businesses to use the Team Project Model to help their team members cooperate, focusing on utilizing distinctive intensities within individual elements among team members.

•By using Active Listening Skills (ALS), a method developed by the FBI, every team member will increase productivity regarding their specific missions. When united, the team members will form successful finalization of their team-goal. By applying ALS, the team’s entire task will result from a collective productive representation of their work.

Программный комитет ещё не принял решения по этому докладу

Как правильно масштабироваться

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

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

Программный комитет ещё не принял решения по этому докладу

Сейчас о Чистой Архитектуре много говорят, но в основном это делают разработчики Andriod-приложений :) А о практике применения Чистой Архитектуры в кровавом Enterprise практически нет информации, хотя эта архитектура предназначена как раз для масштабных проектов со сложной бизнес-логикой.
В докладе мы расскажем об опыте применения Чистой Архитектуры в проектах разного размера: микросервис, стартап, средний и большой проект с несколькими Backends-For-Frontend. После доклада все слушатели получат шаблон проекта для каждого размера и четкую инструкцию как масштабировать проект от меньшего размера к большему, сохранив при этом его соответствие Чистой Архитектуре.

Программный комитет ещё не принял решения по этому докладу

Мы пилили монолит

Многие монолиты упираются в предел своей производительности и у команды возникает необходимость их масштабировать. Но что делать в такой ситуации, с чего начать? Можно найти хорошую информацию как о том, как сделать качнственный монолит, так и о том, как сделать проект изначально по микросервисной архитектуре. А вот по переходу с монолита на микросервисы информации практически нет.
Мы расскажем о том, как сделать монолит модульным, выделив изолированные и взимодействующие через контракт модули. Затем - как перейти к монолитным микросервисам, внедряя доменные события и заменяя транзакции на механизм компенсации. И, наконец, как внедрить Service Bus и выделить микросервисы в отдельные процессы.

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

Реструктуризация тех.долга

Рано или поздно любой разработчик сталкивается с ним... Он разрушает судьбы и компании, но вместе с тем и создаёт новые рабочие места, из-за него вы продолбали выпустить в срок последний релиз... И имя ему — legacy-код!

На мастер-классе мы рассмотрим:
- Каковы причины появления legacy-кода?
- Почему это проблема не только разработчиков, но и в целом всего бизнеса.
- Какие техники существуют для того, чтобы бороться с причинами и последствиями.
- И конечно, практика на реальном коде, а как же без него!

Доклад принят в программу конференции

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

Заполнить bugtracker задачами технического долга недостаточно: чтобы продать бизнесу технический долг, нужно понимать “процент выплат” по каждой из задач. Встает вопрос "что важнее": вычистить лог чтобы суппорт быстрее с ним разбирался, добавить метрики в Prometheus чтобы DCO видело падение производительности, доделать честную многопоточность для хороших циферок масштабируемость и производительности или отрефакторить старую подсистему.

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

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу

Обычно о CQRS говорят в контексте производительности: разделение приложения на Read стек с денормализованной моделью и NoSQL хранилищем и на Write стек с нормализованным SQL хранилищем позволяет ускорить проект. С одной стороны - это правда, с другой - CQRS в полный рост с отдельными моделями и базами для Read и Write стеков встречается весьма нечасто.
Поэтому мы поговорим о гораздо более частом случае - стоит ли использовать рекомендуемый CQRS подход, где для каждого юскейса создается отдельный класс-хендлер в приложениях, в которых производительность не критична. Мы расскажем о восьми приемуществах, которые дает CQRS подход с отдельным классом-хендлером на каждый юскейс по сравнению с привычной слоистой архитектурой, где создается ApplicationService с методами для разных юскейсов.

Программный комитет ещё не принял решения по этому докладу

Знаете ли вы, что такое НАСТОЯЩЕЕ легаси? Настоящее легаси — это реально тонны кода и тысячи окошек интерфейсов, которыми пользуются тысячи людей. Вы убираете одно окошко, и в конце месяца работа бизнеса встает, потому что именно в нем раз в месяц смотрели статистику. Это критичная для всего бизнеса база, написанная на Perl, работающая только под OS/2 замороженной версии, которая старше ваших всех вместе взятых детей. Это десять лет назад устаревшее железо, которое интеграторы держат в ЦОДе специально для вас, потому что новое такое уже не купить, а мигрировать старый софт на более современное — невозможно.

В докладе мы НЕ БУДЕМ обсуждать, что делать, если вы уже там. Бегите, глупцы.

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

Какова роль техлида в том, чтобы система как можно дольше оставалась пригодной для модификации и сопровождения?

Всегда ли можно избежать быстрого скатывания системы в кровавое легаси. Спойлер: не всегда.

Как устроен конфликт между хотелками бизнеса и хотелками команды и как техлиду продавать рефакторинг бизнесу, а бизнес хотелки-свистелки-перделки — команде?

Программный комитет ещё не принял решения по этому докладу

Шишки, набитые в процессе разработки MVP мобильного приложения с позиции бэкенд-разработчика:
- Pros & cons разработки мобильных приложений на Flutter
- Что не плохо бы уметь до начала разработки на Flutter
- Сложно ли перейти с Kotlin на Dart
- Сколько времени надо, чтобы написать MVP на Flutter, если не писал на нем ранее
- С какими сложностями можно столкнуться
- Что общего между бэкенд-разработкой на Java/Kotlin и мобильной разработкой на Flutter
- Как искать Flutter-разработчиков в команду, если у компании пока почти нет опыта с Flutter

Программный комитет ещё не принял решения по этому докладу

Мастер-класс

Как мы обычно планируем и делаем работу в команде? Вася берет фичу A, Петя — фичу B, а Женя — С. Потом мы расходимся на несколько дней и каждый вдумчиво делает свою работу. И все бы хорошо, но с этим подходом есть несколько проблем:
* Некоторые (обычно крупные фичи) доползают до релиза медленно, потому что ими занимаются 1-2 человека. А именно такие фичи обычно самые важные и ценные!
* Время доползания до релиза увеличивается, если Вася заболеет. Перехватить то, над чем Вася работал уже несколько дней, не так-то просто, да и свою фичу надо доделывать!
* Синергии от коллективной мудрости команды не происходит или она случается поздно — на code review, когда принципиально переделывать решение, может быть, уже не хочется.

Помогает подход “навалиться и сделать”: внучка за бабку, бабка за дедку — но если в случае с репкой все понятно, то как быть нам?

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

Доклад принят в программу конференции

TechLead Conf

Часто, когда мы говорим о крупных компаниях, у нас возникают ассоциации вроде "кровавый enterprise", бесконечные NDA и тщательное регулирование всех процессов разработки. В докладе я попробую побороться с таким имиджем, рассказав три истории о том, как внутри банка развивалось и продолжает развиваться совместное владение кодом, основанное на принципах inner source. У каждой из историй разные предпосылки и особенности, но все они про совместную разработку на основе открытости и сотрудничества. В процессе рассказа разберемся, откуда берется inner source и как его создать внутри вашей компании.

Программный комитет ещё не принял решения по этому докладу

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

В докладе я расскажу о защите приложений, использующих микросервисную архитектуру и технологии контейнеризации. Рассмотрим проблемы и угрозы с точки зрения безопасности разработки и эксплуатации подобных приложений, на какие стандарты ориентироваться, какие инструменты позволят это реализовать. Подробно рассмотрим безопасность Docker и Kubernetes, а также пользу подхода Policy As Code.

Программный комитет ещё не принял решения по этому докладу

У вас есть в компании архитекторы? Крутые ребята, не правда ли?
Разве могут такие спецы быть врагами разработки, раздражать так, что не хочется даже их слушать, а тем более ждать их архитектурного решения по несколько недель? Демотивирует? Замедляет разработку?
Уверен, что они хотят, как лучше. Так ведь, архитекторы?
Ведь и разработчики крутые ребята, только делают иногда то, что взбредет им в голову, разрушая общий архитектурный ландшафт. Хочется за них все проработать, вот только времени на все не хватает, завал!

Знакомо? Тогда вам может зайти опыт Ак Барс Цифровые Технологии (Ак Барс Банк), как мы перешли на подход к гибкой архитектуре. В этом нам помогают движущие силы архитектуры.

Программный комитет ещё не принял решения по этому докладу

До 90% стартапов не становятся успешными. Причины могут быть разными - раннее масштабирование, слабая оценка рынка, недостаточное внимание к деталям. Но, зачастую, камнем преткновения становится то, что мы не осознаем потребности клиента. Тратим ресурсы, создавая то, что остается не нужным.

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

Программный комитет ещё не принял решения по этому докладу

Все слышали понятие community в IT. Но начни спрашивать, что же это такое, и окажется, что вариантов великое множество. Одни скажут, что это исключительно недостижимые команды Google и Apple. Другие - что это какие-то митапчики с пиццей. Третьи - что это чатик IT-шников города N в Telegram. Что объединяет всех этих людей? То, что большинство из них считает, что community - это какая-то внешняя сущность, и многим даже в голову не приходит попробовать создать его прямо внутри своего отдела.
Есть и те, кто задумываются о строительстве внутреннего community, но часто оставляют идею нереализованной, потому что считают, что это очень долгосрочная инвестиция, выгода от которой не очевидна, ведь мир так быстро меняется. Вложить в создание и поддержку сообщества от 50 до 150% своего рабочего времени, в то время как в должностные обязанности это часто не входит, и получить … что? Уж лучше писать код, потому что окупаемость понятна: есть код - есть зарплата.
Так может ли community существовать внутри конкретной компании или отдела? И стоит ли в него инвестировать? Вот с этим мы и попытаемся разобраться.
Я хочу поделиться опытом и рассказать, как можно организовать community таким образом, чтобы оно начало отвечать за отдельные области настройки рабочих процессов. Обсудим форматы взаимодействия с community и подготовку к встречам, а также проблемы, которые вам придется решать, если вы созреете на создание собственного внутреннего сообщества. Также на примере покажу, как окупаются инвестиции в профессиональное community, когда вдруг резко пришлось масштабироваться.
В общем, это краткий курс по инвестированию в людей, который точно даст вам пару применимых на практике инструментов.

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу