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

Поиск по тегам:

Организация разработки продуктов без багов (предотвращение багов, а не поиск)

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

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

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

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

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

Платформенные команды: какие проблемы решаются их наличием в компании

Какие проблемы решает группа разработки PaaS в goods.ru? Что такое разработка PaaS и в чем ее отличие от IaaS? На примере архитектуры платформенного сервиса организации A/B тестов в компании ответим на эти вопросы, покажем как сервис устроен изнутри и какую "пищу" дают результаты его работы.

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

Выбор и внедрение инженерных практик в зависимости от проблематики

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

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

Кейсы рефакторинга архитектуры и инфраструктуры

Ошибки с которыми столкнулись разработчики (Ruby, Golang, Python) при масштабировании финтех стартапа в странах Азии.

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

Расскажу, зачем может понадобиться обновлять технический стек в крупном проекте и что может помочь в организации этого процесса. В качестве примера — реальная история перевода на React и TypeScript проекта, в который коммитят около 70 человек в день. Проекта, который рендерит миллионы разных комбинаций поисковых результатов в день — поисковой выдачи Яндекса.

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

В докладе рассмотрены подходы к написанию «хорошего» кода — понятного и удобного в поддержке. Обозначены общие принципы и разобраны конкретные примеры по темам:

1. Какие существуют универсальные практики для написания хорошего кода и как держать сложность кода под контролем (связанность и зацепление, модульный подход, явное и неявное, легаси, оптимизации, исключения из правил, бизнес-логика)
2. Как сохранить порядок в репозитории (утилиты форматирования кода и линтеры, гит хуки, мертвый код, комментарии, комитлинт, нейминг, излишняя вложенность)
3. Как избежать лишней работы (надбавка за смену технологии, грех перфекционизма, когда допустимо нарушать правила)
4. Как разрешить сомнения (как определить лучшее решение, как придти к единому мнению в команде и перестать спорить, что вообще важно и когда)

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

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

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

У нас было 45 Ansible ролей, 10 YML программистов, 3 jenkins slaves, 5 лет потраченных на адаптацию пирамиды тестирования инфраструктуры. Чёртова Infrastructure As Code после нее вас развозит так, что вы похожи на хипстера из старой Ирландской новеллы, подвернутые джинсы, наклейка Ansible на ноутбуке. Не то что бы это был необходимый запас для проекта. Но если начал собирать модные инструменты, становится трудно остановиться. Единственное что вызывало у меня опасение — это Molecule. Нет ничего более беспомощного, безответственного и испорченного, чем DevOps инженер тестирующий YAML на Jenkins. Я знал, что рано или поздно мы перейдем и на эту дрянь…

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

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

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

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

Способы управления техническими знаниями внутри компании

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

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

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

Карта развития компетенций техлида

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

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

TechLead Conf

- Как начать проект, создавая сразу необходимую DevOps атмосферу в коллективе
- Как получить DevOps как процесс , а не как отдельного человека
- Как бороться с возражениями команды
- В какой момент получилось продолжать строить процессы силой Dev и QA команд, без участия так называемого "DevOps инженера"
- Какие инструменты автоматизации мы использовали и как происходило обучение QA и Dev коллег использованию
На все эти вопросы мы постараемся дать предельно четкие ответы!

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

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

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

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

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

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

Мы в ЦИАН стараемся автоматизировать любые действия, которые повторяются больше трёх раз:)
Итеративно, от небольшого набора скриптов мы пришли к своей внутренней Платформе автоматизации. Она "рулит" почти всем жизненным циклом задачи, начиная с момента заведения тикета в Jira. Это и работа с пулл-реквестами, исходным кодом, проведением ревью, автотестами, и выкладка в прод (зачастую без участия человека). Все эти процессы были описаны при помощи кода и становились сложны для разработки и поддержки. Сами системы такого плана часто превращаются в монолиты. А монолиты мы пилим на микросервисы, и этот тоже не обошли стороной. В результате чего возник вопрос, куда и в каком виде выносить работу с процессами. Выбор пал на внешний BPMN-движок от Camunda, а по каким причинам, как мы переезжали и что из этого вышло я расскажу на докладе.

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

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

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

Но вот почему-то в нашем домене ERP-систем истории BDD-успеха на поверку оказываются очередным набором UI-тестов, написанных постфактум.

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

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

P.S.
По ходу доклада я буду использовать такие слова, как: BDD, Living Documentation, "Docs As Code", Impact Mapping, Story Mapping, Scrum, Kanban, Jenkins, Allure и другие термины из лексикона Agile-коучей. Но никакой инфо-цыганщины, только практические моменты.

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

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

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

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 the areas of administration performance and team concept awareness.

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

•This RESEARCH and practice will assist companies, organizations, and groups by merging psychology in consort with Active Listening Skills (ALS), which will result in an ACCELERATED-advance technique, devised to build rapport as well as enhanced TEAMBUILDING methods.

•This presentation will allow businesses to use the TEAM PROJECT MODEL to help their team members cooperate with each other, with the focus on utilizing distinctive intensities within individual elements among members of a team.

•By using ACTIVE LISTENING SKILLS (ALS), a method developed by the FBI, every team member will increase productivity regarding their specific missions, and when united, the team members will form successful finalization of their team-goal. By applying ALS, the team’s entire task will be the result of a collective productive representation of their work.

Key Takeaways:
•Creative Problem Solving
•Customer Service & Support
•Generational Gaps & Workplace Diversity
•Goal Setting
•Leadership and Influence
•Employee Efficiency
•Using Group Dynamics
•The loss of translation in a text/email.
•The value of how things are said
•How someone hears a word

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

С ростом команды так или иначе возникает вопрос обмена знаниями и отслеживания технических решений в команде или отделе. Как правило понимание приходит тогда, когда полностью разработанные фичи зависает на ревью с серьезными претензиями к архитектуре и выбранному подходу в реализации. При этом готовую фичу переделывать сложно/дорого но и архитектурные проблемы нужно лечить. С другой стороны на больших проектах часто случаются проблемы, когда в разных частях проекта разработчики делают похожий функционал и когда казалось бы нам нужно объединить усилия и сделать его вместе, мы делаем каждый у себя и тратим на это в разы больше ресурсов. В своей практике мы столкнулись с такими проблемами и постарались их решить. Команда фронтенда в Яндекс.Деньгах насчитывает порядка 50-ти человек и нам было жизненно необходимо делиться знаниями и следить за архитектурой нашего фронтенда. В докладе я расскажу как модифицировался процесс разработки для того что бы исправить сложившиеся проблемы.

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

Мы разбиваем проект на мелкие части, формируем пулы задач. Эти импровизированные вагоны отправляем по выданным пророками Agile рельсам. Пилотный проект успешен и всех ждет новое светлое будущее. Но в это будущее команды не хотят ехать с JIRA, хотя этот продукт один из лидеров рынка. 

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

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

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

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

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

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

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

Системы непрерывной интеграции давно стали стандартом в разработке программного обеспечения и уже являются неотъемлемой частью серьезных сервисов-хостингов - travis-ci, bitbucket-pipelines, gitlab auto-devops и подобные. Но всё это инструменты, которые позволяют построить и автоматизировать процесс непрерывной интеграции, а сам факт использования этих инструментов не гарантирует наличие такого процесса в вашем проекте. Мы попробуем разобраться в самом процессе, понять что же такое качественный ci и как с его помощью навести порядок в процессе релизов.

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