Когда ты молод, ты «бессмертен» и не задумываешься о старости. Есть просто уверенность, что если много и хорошо работать, то твоя карьера и доходы будут неуклонно расти. Следуя этой стратегии, ты развиваешься в профессии уже 15, 20, 30 лет. За эти годы уже получил огромный опыт и, наверное, он обязательно поможет безбедно и интересно прожить остаток дней. Но все не так просто. Да, ты уже давно работаешь в хорошей компании, занимаешься интересными проектами, получаешь за это достойную зарплату, но в будущем уже не так уверен, как раньше. Профессиональный возраст приходит с массой вопросов, на которые нужно ответь стратегически.

 Эта статья родилась на основе обсуждения горячей темы «Олды в ИТ», которую 4 января 2021 г. мы записали для подкаста Linkmeup. Обязательно послушайте запись здесь или в любимом подкаст-приложении.

Agile методология разработки программного обеспечения и DevOps, и в особенности их упор на юзер экспириенс, обращают наше внимание на людей, стоящих за продуктами. Но действительно ли процесс разработки имеет значение или же цель попросту оправдывает средства? Лондонская P3X или People, Product, and Process Exchange в значительной степени сфокусирована на точке пересечения трех этих P, причем, пожалуй, последняя из них является наиболее интересной, поскольку объединила в себе самое большое количество акронимов - разработка через тестирование (TDD - test-driven development), разработка на основе поведения (BDD - behavior-driven development), непрерывная доставка (CD - continuous delivery), разработка на основе предметной области (DDD - domain-driven development) и многие другие - чтобы помочь командам определить, как систематически создавать лучшие системы.

Соучредитель Agile Testing Fellowship Джанет Грегори завершила свой основной доклад о процессе обеспечения качества программного обеспечения, попросив собравшихся поднять руки, если они чувствуют момент волшебства в своей agile-команде и чувствуют, что несут миру качество. Лишь несколько человек из аудитории, предположительно полностью состоящей из практикующих agile разработчиков, подняли руки.

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

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

Привет! Я хочу рассказать про свой опыт в самоорганизующейся команде. За полтора года там было от 3 до 5 разработчиков, я не занимался их наймом, но все процессы и разработку я построил с нуля. Расскажу что такое самоорганизующаяся команда, какую пользу она приносит для компании, команды, и ее участников.

В офлайне покупатель видит полки магазина и сам может понять, чего нет в наличии, а что можно положить в корзину и купить прямо сейчас. В онлайне«‎глазами»‎ пользователя становится каталог: он всегда должен быть актуальным. 

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

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

Рассказываем, как мы внедрили алгоритм автоматического отключения таких «‎призраков»‎ и уменьшили долю ненайденных товаров на 25%.

• Взаимодействие между компонентами напрямую друг с другом может привести к неожиданному поведению, в котором сложно будет разобраться разработчикам, операторам и бизнес-аналитикам.
• Чтобы обеспечить устойчивость бизнеса, вам нужно видеть все возникающие в системе взаимодействия.
• Добиться этого позволяют разные подходы: распределённая трассировка, обычно не учитывающая бизнес-аспекты; озёра данных, требующие заметных усилий по настройке получаемых срезов данных; отслеживание процессов, когда вам приходится моделировать интересующий поток задач; контроль и анализ процессов (process mining), позволяющие исследовать поток задач; и вплоть до оркестрации, в которой прозрачность процессов уже имеется.
• Мы поговорим о том, что вам нужно балансировать между оркестрацией и хореографией микросервисной архитектуры, чтобы понимать, управлять и менять свою систему.

Проблема

У каждого из нас есть не менее одной идеи на миллион. Но далеко не у каждого получается воплотить свои задумки в жизнь. Этому есть ряд причин, о которых написано немало книг и статей. Известно также, что реализовать свои идеи не получается даже у крупных компаний с большим опытом, крутой командой и немалым бюджетом. Для примера можно посмотреть на «кладбище» проектов компании Google или «морг» Microsoft. Трудно представить, что у этих компаний столько много не получившихся проектов, на которые были потрачены немалые деньги и время.

Что делать? Какое решение? В этой статье собрана большая часть методов проверки гипотез, также рассказывается о новом термине «претотипирование» с примерами известных компаний.

Имеем: проект web API на .net core с исходниками в GitHub.

Хотим: авторазвертывание на виртуалке AWS EC2 после завершения работы с кодом (для примера push в develop ветку).

Инструментарий: GitHub Actions, AWS CodeDeploy, S3, EC2.

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

Маркетолог — слишком уж разносторонняя личность. И даже если специалист углубляется в одну сферу, например, контент или SEO, понимание, как работают другие подразделения жизненно необходимо. Я работаю в сфере маркетинга уже 23 года, сейчас руковожу департаментом маркетинга и коммуникаций в в федеральном банке. Три года назад для отслеживания лучших вакансий на рынке создал telegram-канала для маркетологов. Очень важно быть в курсе того, что происходит в сфере. Каждый день появляется что-то новое, но есть некоторые ресурсы, книги и фильмы, которые не просто полезны в моей работе, а основополагающие, особенно для начинающих маркетологов. Я их разбил на так называемые номинации, постарался ранжировать от общего к специализированному:

Вам больше не помогут no-cache или max-age заголовки, вы просто не знали и не могли узнать о механизме обновления SW. Потому что про него вам не говорили.

Сравнение трех самых популярных Managed Kubernetes платформ.

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

В статье сравним Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) и Azure Kubernetes Service (AKS).

В Domain-Driven Design выделяют стратегические и тактические паттерны. Например, первые — это Единый язык, а вторые — Агрегаты. Я много раз слышал от коллег, что со стратегией всё понятно, но когда дело доходит до перехода на тактический уровень (до кода) — всё в тумане. Это приводит к некорректным техническим решениям, которые не могут компенсировать даже правильный настрой и близость к бизнесу. Для успеха проекта крайне важно освоить тактические паттерны, особенно Агрегаты. Всё потому, что Агрегаты инкапсулируют в себя почти всю бизнес-логику, это основа вашего приложения. В этой статье я и расскажу про Агрегаты, как они могут помочь и почему важно их освоить. Но...

В этом выпуске подкаста ITMO Research — Михаил Мирзаянов, основатель платформы Codeforces и ассистент факультета информационных технологий и программирования Университета ИТМО.