Обложка канала

xpinjection. Страница 9

Авторский канал @xpinjection - опытный Java Tech Lead, Delivery Manager и консультант с 15+ лет опыта в IT. Я пишу о Java, распределённых системах, Agile, процессах разработки, инженерных практиках, QA, конференциях, инфраструктуре и многом другом...

  • xpinjection

    Я уже писал осенью прошлого года про Java 17 и мотивацию перехода на новую версию. Основные сложности миграции вероятнее всего возникнут не с вашим кодом, а с библиотеками и фреймворками в зависимостях. Как раз в конце декабря вышла версия Spring Boot 2.6.2, поэтому я бы советовал мигрировать на нее в рамках обновления, чтобы подтянуть множество обновленных версий зависимостей, совместимых с Java 17. Чтобы набить меньше шишек, можно начать с парочки статей о практическом опыте миграции со Spring Boot 2.3.x и Java 11 на Spring Boot 2.5.x и Java 17. Ссылки на статьи под постом. А для уменьшения подобной боли в будущем рекомендую в технический бэклог добавлять каждые 2-3 месяца задачу по пересмотру и обновлению зависимостей. Ну и конечно же, настроить сканирование образов и зависимостей на уязвимости в своих CI пайплайнах. #java
  • xpinjection

    С небольшим опозданием хочу поздравить вас, подписчиков моего канала, с Новым Годом! 2021-й стал однозначно для IT рынка Украины годом возможностей. Количество и качество вакансий позволило каждому удовлетворить свои амбиции по профилю работы и зарплатным ожиданиям. В то же время, этот год так и не вернул нас к полноценному офлайн общению. Минимум офлайн мероприятий, карантинные ограничения, большая часть встреч в формате онлайн, многие люди в командах не видели друг друга вживую… Хочется пожелать всем нам, чтобы в 2022-м году активный рост рынка сохранился, ситуация с пандемией наконец стабилизировалась, мы все могли путешествовать и встречаться без ограничений, а проект Дия Сити не принёс новых сюрпризов. С Новым Годом!
  • xpinjection

    К программе по выдаче 1000 гривен всем вакцинировавшимся гражданам Украины можно относиться по-разному, но есть у нее пара очень крутых последствий. Именно о них я сегодня и хотел бы поговорить. Во-первых, это первая (и достаточно успешная) попытка полностью диджитализировать социальные выплаты со стороны государства. Никаких походов в отделения банков, копий 100500 документов, уймы потраченного времени и прочего мракобесия. Простой и понятный алгоритм получения виртуальной карты целевого назначения через интеграцию с Дией. Причем, даже с функцией контроля (хоть и частичного) целевого использования данных средств. Сколько бы ни было скептиков Дии, но это определенно прорыв. По такой схеме можно реализовывать много других социальных проектов и при этом "из коробки" получать детальную статистику и аналитику, частично контролировать целевое использование средств и предотвращать многие коррупционные факторы текущих социальных программ. Во-вторых, и это еще более важный фактор, данная программа позволила банкам проверить на практике свой уровень так называемой business agility. Данный показатель демонстрирует, как быстро организация может сфокусировать свои усилия и средства на достижении определенной цели, возникшей благодаря новой возможности на рынке. Настоящий Agile именно об этом. Не о количестве Agile коучей в компании, не о прекрасных отчетах об успехах Agile трансформации и даже не о наличии Agile сообщества внутри компании. Он о способности бизнеса быть гибким и быстро реагировать на рыночные возможности, получая конкурентное преимущество на рынке. И я очень надеюсь, что для многих банков данное упражнение станет важным уроком, из которого они сделают важные выводы на наступающий 2022-й год. Государство продемонстрировало уверенный первый шаг в сторону диджитализации. И если банки не будут готовы в следующем году быстро реагировать на подобные шаги, то начнут терять клиентов (текущих и потенциальных). И это только начало интересного периода в Украине, когда государство и НБУ начинает становиться не таким закостенелым и неповоротливым. На подходе официальная работа с криптовалютами, различные формы инвестиций, диджитализация социальных выплат и многое другое... 2022-й обещает быть очень интересным! #agile
  • Реклама

  • xpinjection

    ​​Уже неделю весь мир Java разработки стоит на ушах из-за найденной уязвимости в Log4j. Она настолько проста и элегантна, что даже удивительно увидеть ее только в конце 2021 года. Под удар попало очень много энтерпрайз организаций, так как большая часть из них имеет легаси компоненты и сервисы в своей инфраструктуре. Детали данной уязвимости можно легко найти интернете. Я же поделюсь несколькими интересными выводами из случившегося: ✅ Больше всего досталось тем, кто предпочитал оставаться на Java 8, утверждая что «ничего особо крутого в Java 11 не появилось, а Java 8 работает и нас устраивает». А эта дыра на уровне JVM была закрыта как класс с версии 11.0.1. :) В Java 8 эти изменения также были портированы, но кому интересны эти скучные минорные патчи… ✅ Нашёлся другой класс людей-оптимистов, утверждающих что их это точно не коснулось, ведь они либо не используют log4j для логирования либо запускают свои сервисы на Java 11+. И они совершенно упустили из виду многочисленные компоненты middleware, запущенные в их инфраструктуре и работающие на Java в режиме чёрного ящика. Поэтому уязвимость зацепила гораздо больший фронт компаний. ✅ Странно видеть, что при всем многообразии современных инструментов безопасности многие компании до сих пор не автоматизировали анализ используемых в инфраструктуре компонентов и постоянный процесс накатывания секьюрити патчей. Это бы помогло большинству избежать проблем с минимальными рисками для работоспособности приложений и сервисов. Верно говорят, что бюджеты на безопасность появляются только после реального удара по этой самой безопасности. :) Всем хороших выходных и безопасных окружений! #Java #безопасность
  • xpinjection

    ​​😎 История о том, как разработчик, автоматизировав процесс, несколько лет ничего не делал на работе, но при этом не только получал зарплату, но и признавался лучшим среди коллег. Too good to be true, но так оно и было... Присоединяйтесь к Highload, там регулярно публикуются подборки интересных инструментов и полезных советов для разработчиков, а также истории из жизни тех, кто пишет код. 😉
  • xpinjection

    ​​Соскучились по офлайн мероприятиям? Есть желание пообщаться с коллегами на интересные технические темы за кружечкой глинтвейна? Тогда увидимся на следующей неделе 21 декабря на митапе в InnoHub, посвящённом Java 17. Ловите анонс! 💻❄️ 21 грудня запрошуємо Java-спеціалістів на новорічний мітап в InnoHub на тему “Java 17: A 3 years journey to the next LTS release”. Будемо говорити, що нового з'явилось в Java 17, які фічі мотивуватимуть розробників оновитись до цієї версії, а також обговоримо плани на майбутній розвиток Java як мови та JVM як платформи. Спікери мітапу: 🔸 Миколай Аліменков, незалежний консультант в XP Injection, 17+ років досвіду. 🔸 Руслан Костін, Java Software Engineer в Innovecs, 5+ років досвіду. 🔸 Дмитро Постолюк, Java Software Engineer в Innovecs, 10+ років досвіду. Можна долучитися до події офлайн у просторі InnoHub в Києві або отримати після завершення заходу відеозапис. На гостей InnoHub чекає новорічна afterparty з глінтвейном, можливість поспілкуватись зі спікерами під DJ-сети та отримати приємні призи. 📌 Коли: 21 грудня о 18:30. 📌 Де: InnoHub (Київ, Вацлава Гавела, 6з). Для зареєстрованих користувачів, які не зможуть взяти участь офлайн, ми підготуємо відеозапис. Участь вільна за реєстрацією ➡️ https://cutt.ly/6YGAaTc #java #митап
  • xpinjection

    Во вторник послушал доклад "How we built serverless application on AWS" от Кости Слисенко на CoffeeJUG митапе. Доклад получился просто отличным по структуре и содержимому. Не было «воды», покрыты все важные аспекты serverless разработки на AWS, продемонстрировано целостное архитектурное решение конкретной задачи практически целиком на сервисах AWS. Доклад не заточен на конкретный язык программирования, поэтому будет одинаково интересен всем разработчикам. Настоятельно рекомендую к просмотру, запись можно найти под постом. А тем, кто ищет ещё интересных технических мероприятий в этом году, могу посоветовать парочку. 15 декабря JUG.RU проведёт бесплатный митап по Java и обеспечению качества "GPB & IT_ONE. QA & JAVA MEETUP". В программе два трека по указанным направлениям. Java разработчики смогут получить полезные советы по старту с Reactive стеком и веские причины для перехода на Java 17. На QA треке будут освещены темы white-box тестирования и неэффективных практик автоматизации тестирования. Участие бесплатное, ссылку можно найти под постом. 16 декабря пройдет JUG.Online, он же JUG.EKB в формате онлайн. В программе 6 докладов от спикеров NAUMEN, JetBrains, Dodo Engineering, Haulmont, ANNA Money и Контура. Темы самые разнообразные от Linkerd и Spring Data до тестирования и хороших практик в написании библиотек. Участие бесплатное, ссылка на регистрацию под постом. #java #qa #митап #архитектура #AWS #serverless
  • xpinjection

    Инженерные практики - это ядро в разработке, без которого невозможно добиться контролируемого качества и надежной доставки ценности клиенту. Даже если вы хорошо настроили процесс разработки и взаимодействие с бизнесом. В рамках аудита по инженерным практикам мы задаём очень много вопросов клиентам, чтобы понять текущую картину и предложить план улучшений. Недавно я наткнулся на статью с коротким чеклистом для самоанализа. Это хорошая точка старта для прокачивания своих инженерных практик. #разработка
  • xpinjection

    В ноябре вышла очередная версия моей любимой IntelliJ IDEA 2021.3. И когда кажется, что в 2021 году сложно придумать что-то новое в продукте с многолетней историей, то разработчики находят чем порадовать. Вот что понравилось в этом релизе мне: - Бета версия фичи Remote Development, которая позволяет запускать бэкенд IDE на удаленной машине и работать с ним как с локальным. Очень крутая новость для обладателей не самых мощных ноутов. - Возможность разделить панель запуска и запускать рядышком 2 разных сервиса. Очень удобно для интеграции, тестирования или показа демок. - Переработанный поиск и показ использований кода. Можно быстро понять контекст без переключения в код. - Сравнение слепков профилировщика. Очень круто помогает делать сравнительный анализ при тюнинге производительности. - Новые фишки для работы с Git для тех, кто предпочитает работать не из консоли. - Наконец появилась связка настроек Spring Boot с Value и Scheduled. - Появился детектор блокирующего кода. Это поможет разработчикам допускать меньше ошибок, приводящих к забитому пулу потоков. - Теперь можно сравнивать DDL скрипты с реальной схемой БД и даже несколько схем между собой. Для легаси приложений это прямо бесценная фича. - Возможность редактировать Page Object для ваших UI тестов прямо из живой страницы окна браузера в IDE. - Я открыл для себя плагин для генерации разнообразных тестовых данных по шаблону. Раньше для этого использовал отдельные библиотеки. - Улучшено форматирование Helm шаблонов и добавлена поддержка language injection для ConfigMap. Можно будет редактировать yaml не как просто текст. - Появилась крутая фича для изучения слоев Docker образов, визуальная и очень удобная. А также можно легко сохранить локально образ из работающего контейнера. Это позволяет удобнее настраивать свои рабочие инструменты в контейнерах. Отличный получился релиз! Всем рекомендую обновиться поскорее. #java #idea
  • xpinjection

    ​​#реклама #конференции 🔥 Робіть добро, а Parimatch Tech помножить його вдвічі! Хто сказав, що #ЩедрийВівторок - це лише один день? Добрі справи мають робитися постійно. 7 грудня відбудеться щорічна продуктова конфесказавренція ProductCamp Ukraine Giving Tuesday Edition, на якій вже традиційно збиратимуть донати на благодійність. Усі внески та пожертви будуть подвоєні за рахунок організатора - міжнародної продуктової компанії Parimatch Tech. Зареєструватися на офлайн-захід та познайомитися з виступами експертів можна за посиланням. Куди підуть гроші? Партнером конференції виступить міжнародний благодійний фонд Parimatch Foundation. Головна мета фонду — розвиток дітей через спорт. Усі зібрані кошти будуть направлені на відкриття нових спортивних груп для дітей з інвалідністю, дітей-сиріт і дітей із сімей, що опинилися в складних життєвих обставинах. Конференція об'єднає учасників з України, Білорусі, Казахстану та Кіпру і пройде в гібридному форматі - онлайн та офлайн. Долучитися і послухати виступи можна безоплатно, підтримавши ініціативу донатом на будь-яку комфортну суму. 💥 А під час кава-брейку між усіма благодійниками розіграють лоти: футбольний м'яч Juventus з автографами Пауло Дибала та Алекса Сандро, а також фірмову футболку ФК Everton від Hummel з автографами всієї команди. Зробити пожертву можна будь-якої миті - до, під час чи навіть після конференції просто на сайті Parimatch Foundation. 🔥
  • xpinjection

    Тут у меня для Java разработчиков накопилось пару анонсов интересных митапов. 29 ноября команда EPAM при поддержке JUG Ru Group проведет бесплатный онлайн-митап по DevOps и Java. В программе: – Евгений Борисов и Александр Бармин с докладом «Spring Сloud goes cloud». Иногда на проектах все еще выбирают синхронное взаимодействие микросервисов. Этот доклад о том, как сделать масштабируемую динамическую синхронную архитектуру с помощью Spring Cloud, запустить это дело в облаке и прикрутить к нему Kubernetes. – Илья Феоктистов с докладом «Pulumi: программируем инфраструктуру на языках высокого уровня». При работе с Terraform у многих возникают сложности с его внутренним языком конфигурации HCL. Илья на примере Pulumi покажет более понятный подход с использованием языка Go. Начало в 11:00, участие бесплатное по предварительной регистрации. 2 декабря присоединяйтесь к Cloud Builders: Java Edition. Поговорим о Cloud Native Quarkus и последних Java фичах вместе со спикерами из Red Hat и Oracle☕️ В программе: ☕️ Роберто Кортес, Principal Software Engineer в Red Hat, выступит с техническим докладом про Cloud Native Quarkus. ☕️ Николай Парлог, Developer Advocate в Oracle и Java Champion, ответит на вопросы о Modern Java в формате fireside chat — неформальной дискуссии между модератором, спикером и участниками. ☕️ Денис Феденко, Delivery Manager, Automotive segment в Intellias, проведет lighting talk на тему: “Is EV a future? Automotive market trends and the role of Java in it” Модератор: Артем Трофимов, Software Engineer в Oracle Когда и где: 2 декабря в 19:00, онлайн. Участие бесплатное. #java #митап #конференции
  • xpinjection

    ​​Всем хорошей продуктивной недели и защиты календаря. :)
  • xpinjection

    ​​Чуть не забыл сделать ещё один анонс интересной конференции, в этот раз на DevOps тематику. С 8 по 11 ноября на конференции DevOops 2021 спикеры расскажут о лучших DevOps-практиках, которые помогли им наладить процессы в команде: ✔ Олег Ненашев, «REvolution of open source CI/CD tools»; ✔ Павел Селиванов, «Повышаем отказоустойчивость и снижаем расходы в Kubernetes»; ✔ Алина Власова, «Как сделать стабильно, когда тысячи разработчиков могут всё сломать, или как организован CI в монорепозитории "Лаборатории Касперского"»; ✔ Владимир Гурьянов, Андрей Колаштов, Дмитрий Столяров, «TSDB – взгляд изнутри. Миграция на Prometheus и Cortex. Опыт Okmeter»; ✔ Kerim Satirli, «Building Trustable Infrastructure». Посмотреть полностью готовую программу и билеты можно на сайте. А промокод xpinjection2021JRGpc поможет приобрести Personal Standard билет со скидкой 2000₽. #конференции #devops
  • xpinjection

    В отпуске было время посмотреть видео с последних конференций. Одна из них Tinkoff Agile Conference 2021. Вот доклады, которые мне понравились. «Как сохранить все хорошее при масштабировании». Классный обзор подходов и практик в масштабировании разработки. Позволяет не пустить все на самотёк и при этом наращивать команду весьма интенсивно. Надежный онбординг, хорошая документация, максимальная автоматизация на уровне инфраструктуры и тестирования, поддержание health метрик команд на уровне и т.д. «Ускоряем движение задач в 2.5 раза за 2+1 шага». Доклад о том, как можно простыми методами сфокусировать команды разработки на нужном результате. Визуализация, четкие метрики поставки ценности, фокус через WIP лимиты… «Почему ваши метрики вам не нужны». Доклад хорошо дополняет предыдущий, показывая как слепое следование метрикам может привести к нехорошим результатам. Важно видеть и анализировать всю картину, а к метрикам относиться как к вспомогательным инструментам. «Практика управления безопасностью ПО в масштабных продуктах». Доклад про современные подходы к безопасности и о чем важно не забыть. Своеобразный чеклист для самопроверки. «Гибкое управление ML проектами». Доклад о том, как обеспечить нужную гибкость, прозрачность и предсказуемость в ML проектах. Много полезных советов как ставить задачи, отслеживать прогресс, устанавливать цели, оценивать результаты. Все доклады выложены на YouTube, ссылка ⬇️ #конференции #agile
  • xpinjection

    ​​Пятничный пост на злобу дня! :)))
  • Реклама

  • xpinjection

    Продолжаем тему масштабирования организаций и сегодня поговорим о платформенных командах. Это популярное название, которое дают выделенной команде, занимающейся разработкой единой платформы или ядра продукта. Очевидно, что эта команда является компонентной и очень редко может реализовывать end-to-end ценность в одном из потоков. Обычно она делает что-то для других команд. В результате, для данной команды актуальны стандартные проблемы компонентных команд. Когда же это оправдано? 1. Команда состоит из очень узкопрофильных специалистов, которым важно работать вместе для максимальной эффективности. Например, это могут быть data science эксперты, лингвисты или специалисты по высокопроизводительному коду. Разделять их по продуктовым командам не имеет смысла. 2. Создание API платформы поверх существующих legacy систем. В этом случае очень важно централизованное видение, стандарты и практики. Команде важно работать сфокусировано с очень тесной коммуникацией. 3. Поддержка одной из сложных legacy систем. Многие legacy системы разработаны в очень специфичном технологическом стеке и требуют узких доменных знаний. Например, огромная core banking system на Cobol. Что можно сделать, чтобы минимизировать негативные аспекты для таких команд? 1. Минимизировать количество таких команд в организации. Тогда будет проще упорядочить ее работу и построить подходящий процесс разработки. 2. Команда должна иметь стратегическую цель максимально перейти на self-service модель работы с другими командами. Это значит, что продуктовые команды должны иметь возможность большую часть типовых задач решать самостоятельно по проработанным и детально описанным подходам. Принцип internal open source в действии. 3. Важно выбрать подходящий процесс разработки в зависимости от специфики команды и решаемых задач. Если задачи от продуктовых команд обычно небольшие и разнородные, то может лучше подойти Kanban. Если нужна сфокусированная среднесрочная работа, то лучше может подойти Scrum. Причём, желательно присоединяться на время работы к продуктовым командам для многокомандной работы над единой целью. 4. Нужно четко определиться с подходом для управления приоритетами. Для этого должен быть строго один принимающий решения человек. Сложно назвать его полноценным Product Owner в данном случае, так как компонентная команда не делает продукт, но чаще всего выделяют именно эту роль. 5. Если большая часть задач этой командой делается для определенной продуктовой команды, то можно присоединить ее туда. Это поможет интегрироваться плотнее в бизнес цели и приоритеты, а также избежать дублирования командных функций и ролей как people management, ScrumMaster, HR, поддержка и т.д. Компонентные команды явно не идеальны, но имеют место быть во многих контекстах. Ведь теория и реальная жизнь всегда расходятся. :) #менеджмент #масштабирование #разработка
  • xpinjection

    Продолжаем обсуждать вопрос масштабирования организаций, начатый в прошлом посте. Итак, что делать, если размер команды разработки в разы превышает допустимый для линейного масштабирования или организация занимается разработкой различных продуктов? Нужно делить организацию на части. Эти части называют по-разному: трайбы, стримы, департаменты, продуктовые группы… Давайте остановимся на коротком названии трайб для удобства. Выделение трайбов - очень непростая задача, особенно в больших и запутанных организациях. Начать стоит с формализации основных потоков ценности (value streams) для клиентов организации. Фактически, вся разработка должна существовать для доставки ценности по этим потокам. Конкретные приложения, системы и сервисы - это лишь каналы для доставки. Вот ключевые критерии для выделения трайбов: - Каждый трайб должен покрывать целиком (end to end) один или несколько потоков ценности. Это позволяет бизнесу максимально эффективно экспериментировать и управлять приоритетами. - В трайбе должны быть специалисты по всему задействованному технологическому стеку. Для legacy систем возможны исключения, но необходимо реализовывать специальные подходы для использования internal open source стратегии. - Зависимости между трайбами должны быть минимальными. Это позволяет добиться лучшей предсказуемости и фокуса в разработке, избегая постоянного бардака в приоритетах. Также, у бизнеса появляется возможность независимого масштабирования трайба под свои цели и бюджеты. Идеального мира не существует, поэтому всегда будут перекосы. Например, если раньше организация строила команды вокруг разработки легаси систем, то разделить их по трайбам будет очень нетривиальной задачей. Возможно, на переходной период лучше будет их оставить в качестве компонентных сервисных команд, обслуживающих все трайбы. А потом уже потихоньку двигаться к целевой структуре. Давайте рассмотрим пример не очень удачного разделения на трайбы и к чему оно приводит. Представим, что у большой финтех компании выделили такие трайбы: Cards для карточных продуктов, Payments для платежей и Mobile для клиентских мобильных приложений. И вот, у бизнеса из Cards трайба возникает идея нового карточного продукта, частью которого являются льготные платежи. Для реализации им нужно поставить задачу в Payments трайб, а также в Mobile трайб для добавления поддержки нового продукта в мобильном клиенте. И начинаются все те же игры с приоритетами, ведь у Payments и Mobile трайбов наверняка есть свои бэклоги с не менее приоритетными задачами и целями. Вдобавок, в Cards трайбе нет специалистов по мобильной разработке, поэтому они полагаются на решения Mobile трайба, который не так сильно погружён в домен карточных продуктов. Это может привести к плохому UX для пользователей. От бизнеса будет требоваться точная постановка задач для оценок и включения в бэклог. А это, в свою очередь, закрывает возможность для экспериментов для бизнеса. В результате, снова страдают конечные пользователи. Через некоторое время находится кто-то, предлагающий попробовать SAFe для управления всем этим бардаком зависимостей. Ведь в соседней энтерпрайз организации «внедрили SAFe и все довольны». Это лишь вопрос времени. Вуаля, и организация снова вернулась в мир водопадной разработки, только с Agile привкусом… В следующем посте я отвечу на ваши вопросы и набросы по данной теме. :) #менеджмент #разработка #масштабирование