Многие помнят Хенрика Книберга по его крутым презентациям и книжкам на темы Agile/XP/Scrum, а также красочным презентациям про роль Product Owner. Недавно он сделал обзорное видео по Generative AI, где в нарисованной истории осветил базовые темы и общее положение дел. Наслаждайтесь!

https://www.youtube.com/watch?v=2IK3DFHRFfw

Еще один “last call” по тренингам. Осталось 2 места на стартующий в пятницу 12 апреля тренинг по разработке cloud-native микросервисов на Spring Boot. В программе:

- Внутреннее устройство и ключевые компоненты Spring Boot.

- Архитектурный дизайн для получения максимальных преимуществ от Spring Boot.

- Фичи фреймворка для разработки микросервисов.

- Полноценное тестирование получившегося микросервиса.

- Подготовка к выходу в production, контейнеризация, настройка observability и maintainability.

6 модулей по 3 часа онлайн в конце рабочего дня. Присоединяйтесь!

У меня радостная новость для Java разработчиков, которые используют в работе Intellij IDEA. Вышла новая версия 2024.1 и впервые за долгое время там есть прямо очень классные фичи. Полные релиз ноуты можно почитать тут, а вот мой рейтинг самого полезного в этом релизе:

1. Full line code completion. Он не требует отдельного плагина и доплаты, работает на базе локальной модели у вас на машине. А это значит, что ваш код никуда не передается для анализа. Применение конечно ограниченное, но когда намерения понятны из контекста, то позволяет быстро написать строку готового кода или выбрать из вариантов.

2. Работа с Pull Request и Merge Request из IDE. Наконец появилась после стольких лет страданий полноценная интеграция с GitLab и GitHub. Можно делать ревью прямо в IDE, видеть статусы пайплайнов и не разрывать цикл разработки походом в браузер.

3. Поддержка Wiremock прямо в IDE. Теперь можно по любым эндпоинтам (своего приложения или импортированным через OpenAPI спецификации) в один клик создавать стабы, редактировать их с автокомплитом и потом запускать Wiremock Server прямо в IDE с разными режимами. Это прямо очень круто для тех, кто пишет изолированные интеграционные тесты.

4. Наконец появилась возможность зумить всю IDE целиком, а не только код. Как же этого раньше не хватало.

5. Маven проекты теперь открываются значительно быстрее.

6. Contitional code coverage теперь отлично визуализирует какие кейсы были покрыты, а какие нет. И теперь можно легко импортировать JaCoCo отчет, чтобы удобно разобрать покрытие кода в IDE.

7. Улучшена генерация визуальных диаграмм на базе Spring бинов. Теперь еще проще открыть приложение и в пару кликов визуализировать его структуру.

8. Stiky lines в редакторе. Наконец станет понятно при листании длинного кода где ты сейчас находишься.

9. Бета версия нового терминала. Я в принципе и так подключал к IDEA внешние терминалы и пользовался разными в зависимости от задачи, но тут прямо прикольные улучшения завезли.

Обновляйтесь поскорее и сделайте свою работу приятнее!

#java #IDE #IDEA

Сейчас многих волнует вопрос заменит ли AI нас в работе. Давайте проведем полусерьезное сравнение специалиста в какой-то сфере с автономным AI агентом.

На первом этапе рассмотрим образование или получение базовых знаний. У человека это семья, детский садик, школа, университет, самообразование. Очень долго, хрупко и очень маленький объем информации по сравнению с LLM. А источники практически такие же по качеству. Тут человек проигрывает однозначно, счет 0:1.

Дальше у человека начинается карьера в выбранной специальности. Тут он по сути проходит fine-tuning по узкому направлению на базе теоретических знаний и практических примеров. Снова долго, хрупко и искажено эмоциями. Счет 0:2.

В работе человек использует разнообразные инструменты. Как предназначенные напрямую для работы, так и прикладные, которые он сам приспособил для работы. AI агент ограничен только тем набором инструментов, который ему выдали. И он не может активно добавлять новые. Счет становится 1:2.

Самый ключевой фактор в работе человека - это умение адаптироваться по результатам обратной связи и работать динамическими группами над разными задачами. Тут пока агенты хромают, максимум реализуют встроенный RAG, но не fine-tuning на лету как человек. Ну и из-за пассивной позиции агент может работать только в рамках ограниченной статической команды таких же агентов. Счет сравнивается, 2:2.

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

Что бы вы еще добавили в критерии сравнения?

#ai

Я часто в своей работе имею дело со стартапами. И почти всегда сталкиваюсь с одними и теми же инженерными ошибками, которые приводят к негативным последствиям. Сегодня я опишу ТОП-3 подобных ошибки и их последствия в формате советов командам разработки в стартапах.

1. На первое место я поставлю совет «сфокусируйтесь со старта на ключевых фичах продукта». Очень часто команды откладывают основные вызовы и сложные фичи на потом, начиная с простых и понятных, которые «все равно потом придется делать». Это ловушка, в которую попадают очень многие.

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

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

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

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

3. На третьем месте я бы поставил совет «определитесь что для вашего продукта core домен и разрабатывайте только его». В любом продукте есть компоненты, которые реализуют ключевые отличительные фичи (core). А есть компоненты, которые реализуют общие для подобных приложений фичи (generic) или поддерживают ключевые фичи (supportive).

К generic компонентам можно например отнести аутентификацию и авторизацию, управление пользователями, управление настройками, CMS и т.д. К supportive компонентам можно например отнести отчетность, разнообразные админки, CRM и т.д.

Основная ценность вашего продукта лежит в core компонентах. Generic компоненты нужно стараться взять готовыми в open-source или платных сервисах. Supportive по возможности тоже взять готовыми или быстро разработать на базе готовых кастомизируемых решений. Это позволит выиграть кучу времени и усилий на том, что не приносит основной ценности вашему стартапу.

Следуйте этим простым советам и с большей вероятностью ваш стартап не загнется по инженерной причине. :)

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

Раньше в офисе коммуникационные каналы были повсюду. Small talks, совместные обеды, перекуры, парная работа, сфокусированные встречи в переговорках и т.д. Теперь же создается больше информационного вакуума и люди начинают пытаться его компенсировать увеличением количества онлайн митингов. Согласно исследований, количество онлайн митингов с 2020 года выросло на 62%.

Но это не суть проблемы. Основная трагедия заключается в режиме многозадачности, из которого люди не выходят на митингах. Согласно опросам, 92% людей указали что занимаются другими задачами во время митингов. К чему это приводит?

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

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

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

Я пока не встречал успешных кейсов с полным решением этой проблемы. Просто кто-то страдает очень сильно, кто-то меньше.

Из помогающих факторов я бы выделил такой ТОП-3:

1. Наличие роли фасилитатора на всех встречах и качественная подготовка к ним.

2. Налаживание культуры асинхронной связи на замену большой части митингов.

3. Обязательное правило полного присутствия на встречах с включенными камерами.

Как у вас обстоят дела в этой области? Какие практики внедрили у себя для борьбы с данной проблемой?

Публичные тренинги из-за большой загрузки по работе пока на паузе. :( Но хочу поделиться с вами парочкой видео для самообразования по одной из моих любимых тем - тестированию во время разработки. В рекомендациях сегодня 4 доклада:

1. Test Driven Design Insights про подходы к тестированию на уровне кода, разные техники, паттерны и часто встречающиеся проблемы. Основная идея доклада проста - «если код тяжело тестировать, вероятнее всего есть проблемы с дизайном».

2. Testing microservices про изменения в подходах тестирования для микросервисов. Интеграционные тесты занимают главную роль и нужно уметь ими гибко пользоваться.

3. Fake it until you make it про возможности WireMock и Testcontainers для написания классных интеграционных тестов.

4. Mocks vs Testcontainers про альтернативы использованию реальных систем в интеграционных тестах и сложностях тестирования асинхронного взаимодействия.

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

Пропонуємо зустрітись 29 травня на SPD Talk — онлайн події, присвяченій досвіду роботи з Serverless-підходом, який продовжує займати рейтинги Architecture трендів.

На зустрічі разом зі спікером Ігорем Дмітрієвим, Senior Director, Architecture, SPD Technology, ми пройдемо шлях від знайомства до успішного впровадження Serverless-підходу на багатьох проєктах та дізнаємося інсайти, плюси та мінуси роботи з ним на реальному досвіді.

📌Для кого подія?
Запрошуємо архітекторів, Java-розробників, менеджерів та лідерів команд розробників, а також усіх, хто хоче спробувати застосувати цей підхід на своїх проєктах.

📌Коли?

⏰29 травня о 19:00 (за київським часом)

📍Оnline

💸Вартість: донат від 300 грн у фонд @koloukraine. Усі кошти, зібрані у вигляді донатів при реєстрації, будуть перераховані у фонд KOLO та спрямовані на потреби наших захисників.

Лінк на реєстрацію: https://bit.ly/3WY0Z8b
Лінк на донат KOLO: https://bit.ly/3ViyL6E

30-31 мая проходит ежегодная конференция Spring I/O в Барселоне. Будет много крутых докладов. А пока можно посмотреть кейноут с ключевыми новинками и трендами:

- Выпустили Spring Boot 3.3, ведется работа над Spring 6.2 и Spring Boot 3.4 к ноябрю.

- Продвигается работа над ускорением старта и оптимизацией использования ресурсов Spring Boot приложений. CDS как один из неплохих и дешевых вариантов выиграть на старте.

- Классные новости о Spring for GraphQL. Netflix начал активно использовать у себя в сервисах. Поэтому ожидается много улучшений.

- Spring Modulith для модульных монолитов и крупных сервисов. Чтобы архитектурный дизайн был, им надо заниматься. И теперь в Spring экосистеме есть для этого зрелый компонент.

- Spring AI для тех кто хочет начать работать с AI моделями, но нет времени и желания погружаться в Python стек. Теперь LangChain «на минималках» есть в Spring Boot. Это очень круто, потому что позволяет встраивать AI модели куда угодно в рамках ваших существующих приложений.

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

#Java #SpringBoot

https://youtu.be/XUz4LKZx83g?si=DhKk5SFDlBCoJp3u

Онлайн конференція DevOpsDays: Let's Talk Security

🛡️4-5 червня завітайте на комʼюніті конференцію з питань кібербезпеки.

Буде цікаво DevOps Engineers, SRE, Security Engineers, Infrastructure Engineers, Solution Architects, Software Engineers та Tech Management.

Серед спікерів:
- Nazar Tymoshyk, CERT UA, — Sun Tzu, DevOps, and the complexities of cyber warfare in Ukrainian realities.
- Anastasiia Voitova, Cossack Labs, — Building Security Protections for Robotic Devices.
- Daniel Deogun, Omegapoint — Achieving Defence in Depth using Secure by Design.
- Petro Vavulin з Kyivstar — Information Security in the Cloud: What Should Be Done Now?
- Michał Brygidyn з Xebia — Cloud Hacking Scenarios.
- Tanya Janca з Semgrep — Worst Practices in DevSecOps.

Всі спікери та повна програма: https://devopsdays.com.ua/#agenda

За темами від учасників також будуть лампові Open Space Discussions — пропонуйте свої теми та голосуйте за ті, що цікаві вам.

📍 Участь безкоштовна.
Коли: 4-5 червня 2024 року, о 18:00 (GMT+3, київський час).

Деталі та реєстрація: https://devopsdays.com.ua

Меня часто спрашивают как обезопасить себя от потери работы в IT в связи со стремительным развитием AI. Для ответа на этот вопрос нужно попробовать представить себе типовую разработку в будущем. Перспектива 2-3 года с текущей экспоненциальной скоростью изменений вполне подойдет.

Давайте начнем с того какие навыки будут максимально обесцениваться.

1. Знания. Это самый первый навык, который идет под нож. Раньше обладание знаниями в технологии, домене, проекте, организации и т.д. считалось очень ценным. Потому что получали их люди долго и дорого. Обучение новых сотрудников занимало годы. Многие люди оставались в организации только потому что они обладали нужными знаниями.

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

Где знания все таки останутся ценными? В узких доменах, которые нигде не описаны и не могут быть использованы для обучения LLM. Но мне кажется, что даже эта область знаний будет в итоге обесценена. Автоматизируются процессы сбора знаний с людей и их формализации. Уже сейчас есть готовые технологии для выделения знаний из дискуссий, обсуждений и пользовательских интервью.

2. Написание кода. Эта область покрывается LLM проще всего, потому что языки программирования хорошо структурированы и написанного за долгие годы кода достаточно для тренировки моделей на любой вкус. Добавление инструментов для использования из LLM и цикл обратной связи для самообучения полностью закрывают вопрос. Еще 1-2 года максимум и тема будет закрыта. Как когда-то закрылась тема игры в шахматы с компьютером. :)

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

3. Документация. В эту категорию попадает целая пачка активностей: описание требований, постановка задач, формализация приемочных критериев и тестовых сценариев, техническая документация, пользовательская документация и т.д. Работа большей части аналитиков, QA инженеров, прокси PO и менеджеров полностью заменится AI инструментами.

Где тут можно зацепиться и остаться подольше? Снова таки, узкие домены, узкопрофильные практические знания и опыт. Их автоматизация может не произойти хотя бы потому что проще и дешевле будет использовать людей чем обучать модели. :)

4. Менеджмент. Тут вообще интересная история. Менеджмент нужен тогда, когда работает множество людей и нужно организовать их работу. Если людей станет сильно меньше и зрелость оставшихся будет достаточно большой, то необходимость в менеджменте сильно сократиться. Задачи наподобие организовать процессы работы команды из 2 синьоров, 2 мидлов и 5 джунов уйдут в прошлое.

Определенная необходимость в менеджменте на уровне продукта или всей организации безусловно останется. Перспективное направление это продакт менеджеры, CTO, Head of Infastructure и т.д. Обязательно с практическими навыками в своей области и умением работать с AI-powered командами.

В интересное время мы с вами живем. ;) За что люблю и одновременно не люблю IT, так это за необходимость постоянно развиваться. Не выходит просто получить какой-то набор навыков и дальше просто плыть по течению. Хотя, отстающие от реальности энтерпрайзы с кучей легаси будут еще долгое время. :)

Кому интересно почитать еще мыслей на данную тему, рекомендую глянуть статью Agile in the Age of AI.

За последние несколько лет направление оптимизации старта и использования ресурсов Java приложений очень существенно продвинулось. В каждой версии Java и Spring Boot реализуются оптимизации производительности. Помимо native образов продолжают развиваться Crac, CDS и проект Leyden.

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

Для более глубокого погружения в тему рекомендую посмотреть обзорный доклад с доступными техниками оптимизации и более глубокий доклад по применению CDS.

P.S.: Что точно не рекомендую, так это использовать buildpacks для сборки образов. Более непрозрачного и специфичного подхода сложно придумать. Хотя его по какой-то непонятной причине очень активно продвигают в Spring Boot сообществе.

#Java #SpringBoot

Я взял паузу и некоторое время ничего не публиковал в канале. Нужно было «перезарядить батарейки» и немного разгрестись по работе. Теперь буду возвращаться к регулярным постам.

Сегодня хочу затронуть тему коммуникационных стилей в распределенных системах. С популяризацией микросервисов очень много команд перешли из мира локальных вызовов кода к сильно распределенным системам. И первым натуральным позывом было просто заменить локальные вызовы на синхронные stateless протоколы как HTTP или gRPC. Благо, тех же реализаций HTTP клиентов в любом стеке предостаточно. Просто, быстро и очень похоже на локальные вызовы.

Но синхронные stateless протоколы никак не решают проблемы распределенных систем, перекладывая их целиком на разработчиков. А если разработчики не заморачиваются подобными «мелочами», то очень быстро приходят к распределенным монолитам, каскадным падениям под нагрузкой и инцидентам с потерей консистентности данных. И приходит осознание, что так настоящие микросервисы не построить.

Тут на помощь приходят асинхронные протоколы коммуникации. Тем более, решений предостаточно: олдскульный JMS, RabbitMq с AMQP протоколом, Kafka и другие решения для евент стриминга… И снова многие попадают в ловушку надежды на то, что протокол закроет собой все проблемы и сложности распределенных систем. Поэтому они просто берут настройки по умолчанию и надеются что все будет хорошо.

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

1. At-Least Once
2. At-Most Once
3. Exactly Once

Первые 2 покрываются практически всеми инструментами, но требуют разных настроек. Exactly Once может быть реализован только для определенных сценариев, далеко не во всех протоколах/реализациях и в универсальном смысле недостижим. Kafka дает разработчикам для использования все 3 семантики. Чтобы детально разобраться в теме, рекомендую почитать вот эту статью:

https://engineering.hellofresh.com/demystifying-kafka-exactly-once-semantics-eos-390ae1c32bba

#kafka #architecture

З Днем Народження, Україна! Найкраща і найрідніша країна для мільйонів людей. Така різноманітна і неповторна, незламна і незалежна!

Великий уклін усім тим, хто бореться і ризикує своїм життям заради нашої незалежності та нашого майбутнього!

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

Давайте определим для начала что будем называть плоской организацией. Для простоты, пусть это будет организация с минимальным количеством управленческих слоев между руководителями (C level) и рядовыми сотрудниками. Для маленькой организации количество таких слоев может быть 0. Это и будет наша идеально плоская организация.

Что мешает ей такой и оставаться с ростом числа сотрудников? Необходимость масштабировать следующие направления без построения иерархии менеджмента:

1. Работа со стейкхолдерами.
2. Управление требованиями и приоритетами.
3. Управление процессами разработки и поддержки.
4. Развитие инженерной культуры и архитектурных решений.
5. Работа с сотрудниками (найм, развитие, увольнение и т.д.).

1 и 2 можно отдать на роль Product Owner или Product Manager и масштабировать горизонтально по количеству продуктов или независимых продуктовых областей в организации. Если оставить чисто бизнесовую роль, то иерархия не возникает. За PnL в этом случае продолжает отвечать C level.

Пункт 3 можно попытаться построить на балансе готовых фреймворков и самоорганизации команд разработки. Для этого понадобится больший уровень зрелости членов команды и кто-то помогающий адаптировать выбранный фреймворк под потребности организации. Например, ScrumMaster или Agile Coach. Если организация не может позволить себе нанимать в команды только зрелых инженеров, то появляется потребность в роли Tech Lead (не путать с Team Lead) на уровне команд. Так как роль сугубо инженерная, то она не влияет на уровни иерархии.

Пункт 4 сложнее всего реализовать на базе самоорганизации. Тут требуется большой уровень инженерной зрелости от членов команды. Нанимать таких дорого и долго. Поэтому чаще всего организации возвращаются снова к роли Tech Lead на уровне команд. Инженерные решения на уровне всей организации можно принимать и внедрять группой техлидов во главе с CTO. Дополняют картину сильные лидеры инженерных направлений (QA, iOS, Android, Web и т.д.).

Пункт 5 самый сложный в реализации без иерархий. Напрашивается вариант отдать все эти функции HR как сервису в рамках организации. Часть потребностей это покрывает при высоком уровне квалификации HR команды. Но остаются вопросы с увольнением, ростом и развитием. Развитие можно переложить частично в формате менторства на техлида и синьор инженеров в командах. А вот увольнение и рост снова упираются в зрелость инженеров в командах. При высоком уровне зрелости можно построить процесс 360 ревью на базе сбалансированной системы оценки сотрудников.

В качестве хака некоторые компании закрывают пункт 5 «инженерными менеджерами», которые на самом деле к инженерии не имеют отношения. Их задача фактически заниматься инженерами, помогать им развиваться в организации и становиться более эффективными. Такой себе people менеджер с инженерным бэкграундом.

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

Надо ли это всем организациям? Уверен что нет. А вы что думаете?

Многие ждали этой осенью очередного прорыва в мире AI в виде GPT-5 от OpenAI. На эту тему было много рассуждений и сплетен. Но пока OpenAI порадовал нас только новыми моделями o1-preview и o1-mini.

Серия моделей o1-preview ориентирована на решение сложных проблем в таких областях как наука, программирование и математика. Новая «фича» заключается в том, что модель будет тратить больше времени на «рассуждения» перед ответом. Это позволяет им решать задачи, требующие более глубокого размышления.

Например, модель o1-preview набрала 83% баллов по квалификационным задачам международной математической олимпиады по сравнению с 13% у GPT-4. Отличные новости для школьников и студентов, ведь делать домашку станет еще легче. ;)

А вот модель o1-mini должна вызвать большой интерес у представителей IT. По заявлениям OpenAI, эта модель таргетирована на работу с кодом и не уступает по качеству o1-preview. Но при этом на 80% дешевле. Больше деталей о моделях и сравнительный анализ можно найти тут.

Интересно будет прогнать через новые модели все промпты с моего тренинга по ChatGPT. Планирую сделать это на следующей неделе. Обязательно поделюсь с вами результатами.

На прошлой неделе прокатилась волна обсуждений интересного документа. Опубликовали "утекшую" версию (я не уверен что такие утечки случаются без причин) описания внутренних принципов работы компании MrBeast YouTube Production. Их видео получают сотни миллионов просмотров на YouTube и можно уверенно называть чуть ли не самым успешным проектом на этой площадке. Поэтому принципы работы такой успешной организации однозначно вызывают интерес.

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

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

2. На ключевых позициях A-players, на вырост B-players, отказ от C-players. Ставка на лидерство и проактивность.

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

4. Прозрачные цели и формализованные метрики, которыми можно измерять успешность, а не фантазировать на тему успеха.

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

6. Признание своих ошибок и извлечение из них уроков как обязательный элемент культуры.

7. Постоянный рост зрелости организации по всем фронтам (иначе сложность работы просто захлестнет и не получится поддерживать качество).

8. Строгое управление приоритетами с фокусом на критичные элементы. Управление рисками от критичных элементов.

9. Экономия бюджета за счет креативности. Бюджет важен, но не должен становиться ограничением креативности на пути к цели, за счет креативности можно экономить.

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

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

Я давно в канале не рекомендовал книги. Но тут просто не могу пройти мимо. За $25 вы можете получить, на мой взгляд, лучший набор книг по теме software architecture. Тут есть фундаментальные книги по архитектуре от Нила Форда, набор книг по микросервисам от Сэма Ньюмана, покрыты дополнительные архитектурные направления как Domain-Driven Design, API, Event-Driven Architecture, Serverless и т.д.

С этим набором у желающих развиваться в роль архитектора не будет вопросов что бы еще прочитать полезного минимум на год вперед. :)

#architecture #books

https://www.humblebundle.com/books/software-architecture-2024-oreilly-books

Сегодня хочу поделиться с вами тремя интересными новостями из мира ChatGPT.

1. Я прогнал большую часть задач с тренинга и часть своих прикладных задач через новую модель o1-preview. Результаты разительно отличаются. В некоторых случаях прямо вау эффект. Главное неудобство в переключении режима работы в голове с привычных техник промптинга на базовые. Иначе результат может быть хуже чем с моделью 4o.

2. OpenAI начал наконец совершенствовать UI под специфические задачи. Первым шагом стало внедрение Canvas. В специальной панели можно редактировать результаты работы модели самому или выделять кусочки и просить сделать доработки с более детальным контекстом. Для работающих с кодом и статьями это очень полезный инструмент. Вполне сойдет для разработчиков пока в IDE не внедрят что-то революционного.

3. В Playground добавили функцию помощи в генерации системных промптов. Кто не знает, Playground - это веб-кабинет для разработчиков, которые собираются интегрировать или экспериментируют с OpenAI API. Но эту фичу можно использовать и для своих обычных бытовых нужд. Структура промптов там взята из популярного шаблона. Но если она подходит под вашу задачу, то можно сэкономить кучу времени на продумывание каркаса качественного промпта. А это значит что кастомные GPT-шки можно создавать быстрее и проще.

Всем классных креативных выходных!

На прошлой неделе проходила очередная конференция Devoxx. В этом году основными выделяющимися трендами стали предсказуемо AI и современные фичи Java (виртуальные потоки, развитие новых проектов и т.д.). Но при этом данные темы не забили плотно расписание докладов и в этом году разнообразных тем было более чем достаточно.

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

Хороших вам образовательных выходных!

#конференции

https://youtube.com/playlist?list=PLRsbF2sD7JVrNB1mKqklpc23hsKtvMAXm&si=ws07R8-Ttvwy-vjV