技术
xpinjection
技术
09.05.202511:04
Интересный момент AI революции в IT заключается в том, что основным сдерживающим фактором сейчас является отсутствие у многих AI-driven мышления в работе. Не отсутствие или недостаточная эффективность инструментов для решения задач. Тут все хорошо и с каждым месяцем становится лучше и лучше. Как обычно, все упирается в людей.
Значительная часть людей продолжает делать задачи руками, потому что так «быстрее и привычнее». Они не челленджат каждый свой шаг вопросом «как сделать этот шаг с помощью AI инструментов?». И не готовы инвестировать время в построение готовых решений типовых задач, которые встречаются ежедневно в организации.
Часть людей боится стать бесполезными и потерять работу, если AI автоматизирует их основной навык. Например, будет вместо них писать код по детально описанной задаче или автоматизировать понятные тестовые сценарии. Поэтому они всячески саботируют внедрение AI инструментов в свою работу. Они не готовы принять реальность, в которой писать код больше не является уникальным навыком, доступным малому проценту специалистов.
В то же время, организации активно инвестируют в покупку и разработку AI инструментов. И хотят видеть результаты в виде сокращения усилий на разработку продуктов, ускорения разработки фичей или повышения качества продукта. И не получают их. Или получают сильно ниже ожиданий.
Это возвращает нас в старый добрый мир измерения персональной эффективности сотрудников, от которого индустрия так долго пыталась отойти. Но в этот раз организации уже вооружены более продвинутыми и эффективными инструментами для анализа. Многие организации начинают «охоту» за неэффективными сотрудниками и вводят разнообразные метрики наподобие:
- оценка качества кода и соблюдения стандартов организации через AI агентов в CI цикле;
- процент задач, которые решены с помощью AI инструментов;
- скорость решения задач в зависимости от их сложности, оцененной с помощью AI агента;
- полнота логического покрытия тестами реализованных фичей.
И мне кажется что этот тренд будет развиваться все больше и больше. Времена спокойной высокооплачиваемой айтишки с work-life balance и смузи подходят к концу. :( С другой стороны, это неизбежное последствие инноваций и технических революций.
А как обстоят дела с внедрением AI в вашей организации? Как измеряете успех и прогресс?
Значительная часть людей продолжает делать задачи руками, потому что так «быстрее и привычнее». Они не челленджат каждый свой шаг вопросом «как сделать этот шаг с помощью AI инструментов?». И не готовы инвестировать время в построение готовых решений типовых задач, которые встречаются ежедневно в организации.
Часть людей боится стать бесполезными и потерять работу, если AI автоматизирует их основной навык. Например, будет вместо них писать код по детально описанной задаче или автоматизировать понятные тестовые сценарии. Поэтому они всячески саботируют внедрение AI инструментов в свою работу. Они не готовы принять реальность, в которой писать код больше не является уникальным навыком, доступным малому проценту специалистов.
В то же время, организации активно инвестируют в покупку и разработку AI инструментов. И хотят видеть результаты в виде сокращения усилий на разработку продуктов, ускорения разработки фичей или повышения качества продукта. И не получают их. Или получают сильно ниже ожиданий.
Это возвращает нас в старый добрый мир измерения персональной эффективности сотрудников, от которого индустрия так долго пыталась отойти. Но в этот раз организации уже вооружены более продвинутыми и эффективными инструментами для анализа. Многие организации начинают «охоту» за неэффективными сотрудниками и вводят разнообразные метрики наподобие:
- оценка качества кода и соблюдения стандартов организации через AI агентов в CI цикле;
- процент задач, которые решены с помощью AI инструментов;
- скорость решения задач в зависимости от их сложности, оцененной с помощью AI агента;
- полнота логического покрытия тестами реализованных фичей.
И мне кажется что этот тренд будет развиваться все больше и больше. Времена спокойной высокооплачиваемой айтишки с work-life balance и смузи подходят к концу. :( С другой стороны, это неизбежное последствие инноваций и технических революций.
А как обстоят дела с внедрением AI в вашей организации? Как измеряете успех и прогресс?
28.02.202510:20
Сегодня новостной пост. В мире AI новости несутся просто дикими темпами, очень сложно за ними успевать. Из интересного за последние 2 месяца:
- Появление китайского DeepSeek R1 сильно тряхнуло рынок LLM. Интересная альтернатива из класса open-source моделей, которая сильно дешевле в использовании и близка по качеству ответов топовым моделям. Сам же сервис DeepSeek используют разве что отважные и безрассудные люди. Там дыры и в безопасности, и в стабильности, и в присутствии контроля правительства Китая.
- Сразу 3 крупных игрока выпустили фичу Deep Research в своих продуктах с абсолютно одинаковым названием. Это автономный агент для глубокого анализа веб контента с генерацией отчета по задаче пользователя. Первый пример массово доступного агента, который может решать задачу долго (от минут до получаса) и обрабатывать на свое усмотрение дополнительные материалы.
- Из интервью с представителями Google, OpenAI и Microsoft выглядит так, что в 2025 году фокус и основная ставка будет на создание автономных агентов через Reinforced Learning from Human Feedback. Оказалось, что дообучение базовой модели для полного решения бизнес задачи дало лучше результат чем попытка оркестрировать работу с моделями из многочисленных агентских фреймворков.
- Размер контекста перестает быть значимым фактором. Большинство моделей от популярных провайдеров перешагнули лимит в 100К токенов и он уже считается чем-то привычным. Все больше моделей предлагают лимит в 1-2 млн токенов. Это просто огромные контексты, которые позволяют решать задачи наподобие взять весь код проекта или огромный кусок базы знаний и задать по нему вопрос в одном промпте.
- Основной вектор развития моделей направлен на deep reasoning. Тут просто огромное поле для экспериментов и улучшений, которые направлены на уменьшение галлюцинаций, повышение качества и глубины ответов. Есть ощущение, что на этой веточке развития задача написания кода должна быть решена близко к идеалу.
Из мелких новостей, OpenAI выпустил новую базовую модель GPT-4.5 и возвращается к адекватному именованию моделей. :) А Anthropic зарелизил свой Claude 3.7 Sonnet и объявил его лучшей моделью для задач разработки. В новой модели можно регулировать глубину размышлений в зависимости от задачи. И в бету от того же Anthropic вышел новый тул для разработчиков Claude Code. Тут ребята решили подойти к задаче создания ассистента разработки со стороны консоли. Любопытный выбор, не терпится попробовать на практике.
- Появление китайского DeepSeek R1 сильно тряхнуло рынок LLM. Интересная альтернатива из класса open-source моделей, которая сильно дешевле в использовании и близка по качеству ответов топовым моделям. Сам же сервис DeepSeek используют разве что отважные и безрассудные люди. Там дыры и в безопасности, и в стабильности, и в присутствии контроля правительства Китая.
- Сразу 3 крупных игрока выпустили фичу Deep Research в своих продуктах с абсолютно одинаковым названием. Это автономный агент для глубокого анализа веб контента с генерацией отчета по задаче пользователя. Первый пример массово доступного агента, который может решать задачу долго (от минут до получаса) и обрабатывать на свое усмотрение дополнительные материалы.
- Из интервью с представителями Google, OpenAI и Microsoft выглядит так, что в 2025 году фокус и основная ставка будет на создание автономных агентов через Reinforced Learning from Human Feedback. Оказалось, что дообучение базовой модели для полного решения бизнес задачи дало лучше результат чем попытка оркестрировать работу с моделями из многочисленных агентских фреймворков.
- Размер контекста перестает быть значимым фактором. Большинство моделей от популярных провайдеров перешагнули лимит в 100К токенов и он уже считается чем-то привычным. Все больше моделей предлагают лимит в 1-2 млн токенов. Это просто огромные контексты, которые позволяют решать задачи наподобие взять весь код проекта или огромный кусок базы знаний и задать по нему вопрос в одном промпте.
- Основной вектор развития моделей направлен на deep reasoning. Тут просто огромное поле для экспериментов и улучшений, которые направлены на уменьшение галлюцинаций, повышение качества и глубины ответов. Есть ощущение, что на этой веточке развития задача написания кода должна быть решена близко к идеалу.
Из мелких новостей, OpenAI выпустил новую базовую модель GPT-4.5 и возвращается к адекватному именованию моделей. :) А Anthropic зарелизил свой Claude 3.7 Sonnet и объявил его лучшей моделью для задач разработки. В новой модели можно регулировать глубину размышлений в зависимости от задачи. И в бету от того же Anthropic вышел новый тул для разработчиков Claude Code. Тут ребята решили подойти к задаче создания ассистента разработки со стороны консоли. Любопытный выбор, не терпится попробовать на практике.
14.12.202411:52
Судя по количеству откликов, у всех все хорошо с работой и поэтому я очень рад за подписчиков. 🤗
02.11.202409:54
Вчерашняя рабочая пятница прошла как на этой картинке. :)
19.10.202409:44
На прошлой неделе проходила очередная конференция Devoxx. В этом году основными выделяющимися трендами стали предсказуемо AI и современные фичи Java (виртуальные потоки, развитие новых проектов и т.д.). Но при этом данные темы не забили плотно расписание докладов и в этом году разнообразных тем было более чем достаточно.
Записи докладов публиковались прямо во время конференции, но теперь уже окончательно устаканились и можно смело рекомендовать к просмотру.
Хороших вам образовательных выходных!
#конференции
https://youtube.com/playlist?list=PLRsbF2sD7JVrNB1mKqklpc23hsKtvMAXm&si=ws07R8-Ttvwy-vjV
Записи докладов публиковались прямо во время конференции, но теперь уже окончательно устаканились и можно смело рекомендовать к просмотру.
Хороших вам образовательных выходных!
#конференции
https://youtube.com/playlist?list=PLRsbF2sD7JVrNB1mKqklpc23hsKtvMAXm&si=ws07R8-Ttvwy-vjV
13.09.202408:40
Многие ждали этой осенью очередного прорыва в мире 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. Планирую сделать это на следующей неделе. Обязательно поделюсь с вами результатами.
Серия моделей o1-preview ориентирована на решение сложных проблем в таких областях как наука, программирование и математика. Новая «фича» заключается в том, что модель будет тратить больше времени на «рассуждения» перед ответом. Это позволяет им решать задачи, требующие более глубокого размышления.
Например, модель o1-preview набрала 83% баллов по квалификационным задачам международной математической олимпиады по сравнению с 13% у GPT-4. Отличные новости для школьников и студентов, ведь делать домашку станет еще легче. ;)
А вот модель o1-mini должна вызвать большой интерес у представителей IT. По заявлениям OpenAI, эта модель таргетирована на работу с кодом и не уступает по качеству o1-preview. Но при этом на 80% дешевле. Больше деталей о моделях и сравнительный анализ можно найти тут.
Интересно будет прогнать через новые модели все промпты с моего тренинга по ChatGPT. Планирую сделать это на следующей неделе. Обязательно поделюсь с вами результатами.
26.04.202513:41
Накопилось много мыслей поделиться с вами, но все не хватает времени. :( Сегодня покажу вам отличный пример game changing применения AI. Речь пойдет о проведении собеседований.
Итак, для реализации кейса нам понадобится транскрипт всего собеседования (текстовая версия). Получить ее можно разными способами. Часть инструментов для проведения онлайн митингов позволяет легко записать их, в некоторых для этого нужно будет добавить AI агента в митинг. Подойдет даже среднего качества транскрипт как у Google Meet (ему тяжело дается несколько языков и IT термины в разговоре). Но чем лучше качество, тем меньше будет возможных искажений.
Дальше с помощью ChatGPT или вашего любимого AI ассистента с помощью моделей с большим контекстным окном мы делаем детальную аналитику собеседования:
1. Общее саммари и оценки кандидата с разных ракурсов.
2. Оценка стиля интервью, качества работы интервьюера, что было классно и что можно улучшить в будущем.
3. Оценка тона ответов и степени уверенности кандидата по всем обсужденным топикам.
Это полностью решает задачу предоставления качественной обратной связи кандидату и рекрутеру, помогает выравнивать интервьюеров в организации и развивать их навыки, а также дает более объективную оценку кандидату без эмоциональной составляющей.
Теперь я могу формально описать свой стиль собеседований на senior позиции:
Формат:
Интервью структурировано в форме беседы, где интервьюер (Микола) задает как поведенческие, так и глубокие технические вопросы.
Тон:
Тон в цілому неформальний, доброзичливий, але з елементами «стресового» інтерв’ю, що дозволяє краще побачити, як кандидат поводиться під тиском або у ситуації, коли йому незручно.
Подача:
Микола веде інтерв’ю в стилі «виклик — обговорення — зворотний зв’язок», постійно кидає виклики кандидатським твердженням, просить уточнень і занурює в практичні приклади.
А вот его сильные стороны (слабые я вам конечно же не покажу):
Глибоке технічне занурення:
Інтерв'ю покриває ключові теми для senior-рівня: performance tuning, threading models (Tomcat vs Netty), бази даних, кешування, Spring Boot (стартери, автоконфігурація), архітектура сервісів, reactive vs blocking підходи.
Перевірка мислення:
Кандидату не просто ставляться технічні питання, а змушують мислити, дискутувати, захищати позицію або визнавати слабкі сторони своїх аргументів.
Виявлення глибини знань:
Інтерв’юер не задовольняється поверховими відповідями, а постійно «докопується» до розуміння, що дозволяє відокремити «зубрену теорію» від реального досвіду.
Формат близький до реальної роботи:
Наприклад, кейс із сервісом - це не просто теоретичне питання, а схоже на реальну задачу, яка дозволяє оцінити інженерний підхід кандидата.
И напоследок анонимизированный фрагмент таблицы с оценкой уверенности кандидата в ответах по затронутым на собеседовании темам:
Итак, для реализации кейса нам понадобится транскрипт всего собеседования (текстовая версия). Получить ее можно разными способами. Часть инструментов для проведения онлайн митингов позволяет легко записать их, в некоторых для этого нужно будет добавить AI агента в митинг. Подойдет даже среднего качества транскрипт как у Google Meet (ему тяжело дается несколько языков и IT термины в разговоре). Но чем лучше качество, тем меньше будет возможных искажений.
Дальше с помощью ChatGPT или вашего любимого AI ассистента с помощью моделей с большим контекстным окном мы делаем детальную аналитику собеседования:
1. Общее саммари и оценки кандидата с разных ракурсов.
2. Оценка стиля интервью, качества работы интервьюера, что было классно и что можно улучшить в будущем.
3. Оценка тона ответов и степени уверенности кандидата по всем обсужденным топикам.
Это полностью решает задачу предоставления качественной обратной связи кандидату и рекрутеру, помогает выравнивать интервьюеров в организации и развивать их навыки, а также дает более объективную оценку кандидату без эмоциональной составляющей.
Теперь я могу формально описать свой стиль собеседований на senior позиции:
Формат:
Интервью структурировано в форме беседы, где интервьюер (Микола) задает как поведенческие, так и глубокие технические вопросы.
Тон:
Тон в цілому неформальний, доброзичливий, але з елементами «стресового» інтерв’ю, що дозволяє краще побачити, як кандидат поводиться під тиском або у ситуації, коли йому незручно.
Подача:
Микола веде інтерв’ю в стилі «виклик — обговорення — зворотний зв’язок», постійно кидає виклики кандидатським твердженням, просить уточнень і занурює в практичні приклади.
А вот его сильные стороны (слабые я вам конечно же не покажу):
Глибоке технічне занурення:
Інтерв'ю покриває ключові теми для senior-рівня: performance tuning, threading models (Tomcat vs Netty), бази даних, кешування, Spring Boot (стартери, автоконфігурація), архітектура сервісів, reactive vs blocking підходи.
Перевірка мислення:
Кандидату не просто ставляться технічні питання, а змушують мислити, дискутувати, захищати позицію або визнавати слабкі сторони своїх аргументів.
Виявлення глибини знань:
Інтерв’юер не задовольняється поверховими відповідями, а постійно «докопується» до розуміння, що дозволяє відокремити «зубрену теорію» від реального досвіду.
Формат близький до реальної роботи:
Наприклад, кейс із сервісом - це не просто теоретичне питання, а схоже на реальну задачу, яка дозволяє оцінити інженерний підхід кандидата.
И напоследок анонимизированный фрагмент таблицы с оценкой уверенности кандидата в ответах по затронутым на собеседовании темам:
16.02.202511:31
Мне часто приходится нанимать разработчиков на синьор позиции и я раньше сильно удивлялся после провальных собеседований. Ведь мы по CV тщательно отбираем кандидатов, которые уже имеют значительный релевантный опыт работы на синьорной позиции. Как их тогда нанимали предыдущие работодатели и почему до сих пор с ними сотрудничают?
А потом я понял, что существуют разные виды синьорити и в разных организациях/контекстах/командах они востребованы в разной степени. Я для себя выделил такие виды:
1. Технологическая синьорити. Кандидат отлично понимает базовые технологические принципы, умеет быстро учиться и разбираться с любыми новыми для себя технологиями, в своем основном техническом стеке разбирается очень глубоко и постоянно следит за его развитием. Обычно таким людям в кайф работать в своей индустрии и они работают «по призванию». Это тот вид синьорити, который я обычно ищу для продуктовых команд.
2. Корпоративная синьорити. Кандидат имеет опыт работы с разного типа менеджментом, процессами и структурой команд, умеет играть по установленным корпоративным правилам и они не вызывают у него выгорания, может делать требуемую от него работу самостоятельно на приемлемом уровне качества. Такой вид зрелости очень востребован в аутсорс компаниях. Из таких людей можно построить костяк команды на любом проекте для любого заказчика.
3. Прикладная синьорити. Кандидат умеет быстро и достаточно качественно выполнять типовые задачи в своем технологическом стеке, с которым он уже давно работает. Он копает в глубину и по сторонам ровно настолько, чтобы решать типовые задачи от бизнеса. Переход на другой стек может быть для него очень болезненным и поэтому кандидат везде старается применять свой привычный стек, вне зависимости от контекста. Такие люди зачастую работают в IT потому что тут хорошо платят и синьорити для них ассоциируется с карьерным и зарплатным ростом.
4. Доменная синьорити. Кандидат долго работает в одном бизнес домене, отлично изучил его и знает как нужно решать бизнес задачи в этом домене. При этом, часто технологический стек может быть у кандидата весьма устаревший или специфический. Ведь его основная сила не в этом. Такие люди очень востребованы в энтерпрайз организациях со сложным бизнес доменом.
Как видите, это совершенно разные виды синьорити и все они нужны и важны в определенном контексте. Поэтому для эффективного найма нужно точно определить какой микс видов синьорити важен вам и как вы будете его определять на прескрине кандидатов и основном собеседовании.
К примеру, рассмотрим контекст найма в продуктовую фича-команду, работающую по Scrum в fintech домене. Для меня идеальным набором является сильная технологическая синьорити с кусочком корпоративной синьорити. Если в дополнение будет кусочек доменной синьорити, то это огромный плюс.
Если бы я нанимал в аутсорс компанию, то фокусировался бы на смесь прикладной и корпоративной синьорити. Технологическая и доменная синьорити несли бы в себе риск потерять сотрудника при переходе между проектами.
А потом я понял, что существуют разные виды синьорити и в разных организациях/контекстах/командах они востребованы в разной степени. Я для себя выделил такие виды:
1. Технологическая синьорити. Кандидат отлично понимает базовые технологические принципы, умеет быстро учиться и разбираться с любыми новыми для себя технологиями, в своем основном техническом стеке разбирается очень глубоко и постоянно следит за его развитием. Обычно таким людям в кайф работать в своей индустрии и они работают «по призванию». Это тот вид синьорити, который я обычно ищу для продуктовых команд.
2. Корпоративная синьорити. Кандидат имеет опыт работы с разного типа менеджментом, процессами и структурой команд, умеет играть по установленным корпоративным правилам и они не вызывают у него выгорания, может делать требуемую от него работу самостоятельно на приемлемом уровне качества. Такой вид зрелости очень востребован в аутсорс компаниях. Из таких людей можно построить костяк команды на любом проекте для любого заказчика.
3. Прикладная синьорити. Кандидат умеет быстро и достаточно качественно выполнять типовые задачи в своем технологическом стеке, с которым он уже давно работает. Он копает в глубину и по сторонам ровно настолько, чтобы решать типовые задачи от бизнеса. Переход на другой стек может быть для него очень болезненным и поэтому кандидат везде старается применять свой привычный стек, вне зависимости от контекста. Такие люди зачастую работают в IT потому что тут хорошо платят и синьорити для них ассоциируется с карьерным и зарплатным ростом.
4. Доменная синьорити. Кандидат долго работает в одном бизнес домене, отлично изучил его и знает как нужно решать бизнес задачи в этом домене. При этом, часто технологический стек может быть у кандидата весьма устаревший или специфический. Ведь его основная сила не в этом. Такие люди очень востребованы в энтерпрайз организациях со сложным бизнес доменом.
Как видите, это совершенно разные виды синьорити и все они нужны и важны в определенном контексте. Поэтому для эффективного найма нужно точно определить какой микс видов синьорити важен вам и как вы будете его определять на прескрине кандидатов и основном собеседовании.
К примеру, рассмотрим контекст найма в продуктовую фича-команду, работающую по Scrum в fintech домене. Для меня идеальным набором является сильная технологическая синьорити с кусочком корпоративной синьорити. Если в дополнение будет кусочек доменной синьорити, то это огромный плюс.
Если бы я нанимал в аутсорс компанию, то фокусировался бы на смесь прикладной и корпоративной синьорити. Технологическая и доменная синьорити несли бы в себе риск потерять сотрудника при переходе между проектами.
13.12.202417:05
На фоне общих сокращений и кризиса в IT, у меня есть для вас целый пучок горячих вакансий в продуктовые fintech и ecom:
1. Java Tech Lead. Нужен опыт с нагруженными распределенными системами, продвижение инженерных практик в команде, понимание микросервисных паттернов, глубокие знания в Spring Boot, архитектурные навыки и умение строить эффективные команды разработки.
2. Senior Java Developer. Требуются глубокие знания Spring Boot, автоматизация тестирования на уровне своих сервисов, навыки проектирования API, опыт поддержки нагруженных сервисов в продакшен среде и траблшутинга проблем, практический опыт с PostgreSQL, Kafka, RabbitMq, MongoDb.
3. Senior PHP Developer. Большой практический опыт с Symfony, автоматизация тестирования своих сервисов, опыт применения event-driven архитектурных решений, желательно иметь опыт в ecom домене.
Если чувствуете в себе силы и подходите под требования, не стесняйтесь стучаться в личку на @xpinjection.
1. Java Tech Lead. Нужен опыт с нагруженными распределенными системами, продвижение инженерных практик в команде, понимание микросервисных паттернов, глубокие знания в Spring Boot, архитектурные навыки и умение строить эффективные команды разработки.
2. Senior Java Developer. Требуются глубокие знания Spring Boot, автоматизация тестирования на уровне своих сервисов, навыки проектирования API, опыт поддержки нагруженных сервисов в продакшен среде и траблшутинга проблем, практический опыт с PostgreSQL, Kafka, RabbitMq, MongoDb.
3. Senior PHP Developer. Большой практический опыт с Symfony, автоматизация тестирования своих сервисов, опыт применения event-driven архитектурных решений, желательно иметь опыт в ecom домене.
Если чувствуете в себе силы и подходите под требования, не стесняйтесь стучаться в личку на @xpinjection.
31.10.202419:27
OpenAI запустил новую фичу ChatGPT Search. Google должен активно начинать волноваться. :)
Ну и наконец появился поиск по истории чатов. Необъяснимый парадокс почему его не добавили до этого.
#chatgpt
https://openai.com/index/introducing-chatgpt-search/
Ну и наконец появился поиск по истории чатов. Необъяснимый парадокс почему его не добавили до этого.
#chatgpt
https://openai.com/index/introducing-chatgpt-search/
12.10.202409:50
Сегодня хочу поделиться с вами тремя интересными новостями из мира ChatGPT.
1. Я прогнал большую часть задач с тренинга и часть своих прикладных задач через новую модель o1-preview. Результаты разительно отличаются. В некоторых случаях прямо вау эффект. Главное неудобство в переключении режима работы в голове с привычных техник промптинга на базовые. Иначе результат может быть хуже чем с моделью 4o.
2. OpenAI начал наконец совершенствовать UI под специфические задачи. Первым шагом стало внедрение Canvas. В специальной панели можно редактировать результаты работы модели самому или выделять кусочки и просить сделать доработки с более детальным контекстом. Для работающих с кодом и статьями это очень полезный инструмент. Вполне сойдет для разработчиков пока в IDE не внедрят что-то революционного.
3. В Playground добавили функцию помощи в генерации системных промптов. Кто не знает, Playground - это веб-кабинет для разработчиков, которые собираются интегрировать или экспериментируют с OpenAI API. Но эту фичу можно использовать и для своих обычных бытовых нужд. Структура промптов там взята из популярного шаблона. Но если она подходит под вашу задачу, то можно сэкономить кучу времени на продумывание каркаса качественного промпта. А это значит что кастомные GPT-шки можно создавать быстрее и проще.
Всем классных креативных выходных!
1. Я прогнал большую часть задач с тренинга и часть своих прикладных задач через новую модель o1-preview. Результаты разительно отличаются. В некоторых случаях прямо вау эффект. Главное неудобство в переключении режима работы в голове с привычных техник промптинга на базовые. Иначе результат может быть хуже чем с моделью 4o.
2. OpenAI начал наконец совершенствовать UI под специфические задачи. Первым шагом стало внедрение Canvas. В специальной панели можно редактировать результаты работы модели самому или выделять кусочки и просить сделать доработки с более детальным контекстом. Для работающих с кодом и статьями это очень полезный инструмент. Вполне сойдет для разработчиков пока в IDE не внедрят что-то революционного.
3. В Playground добавили функцию помощи в генерации системных промптов. Кто не знает, Playground - это веб-кабинет для разработчиков, которые собираются интегрировать или экспериментируют с OpenAI API. Но эту фичу можно использовать и для своих обычных бытовых нужд. Структура промптов там взята из популярного шаблона. Но если она подходит под вашу задачу, то можно сэкономить кучу времени на продумывание каркаса качественного промпта. А это значит что кастомные GPT-шки можно создавать быстрее и проще.
Всем классных креативных выходных!
28.08.202410:48
Сегодня поговорим о плоских организациях и способах их построения. Многие из моих клиентов декларируют желание строить плоскую организацию без иерархии менеджмента внутри. Причины простые - плоская организация в индустрии противопоставляется бюрократизированной иерархичной энтерпрайз организации. Ну и любая большая организация выросла из маленькой, поэтому ностальгические воспоминания о драйве и скорости без всяких там менеджеров постоянно всплывают в памяти.
Давайте определим для начала что будем называть плоской организацией. Для простоты, пусть это будет организация с минимальным количеством управленческих слоев между руководителями (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 менеджер с инженерным бэкграундом.
Как видите, строить и масштабировать плоскую структуру в организации можно, НО сложно, долго и дорого. Зачем тогда это нужно? На выходе получается более устойчивая организация, без критических зависимостей от конкретных людей в каждой роли. Есть возможности принимать и отвечать за решения в рамках команд, большая адаптивность в рамках организации, возможности для развития и роста без карьерной иерархии.
Надо ли это всем организациям? Уверен что нет. А вы что думаете?
Давайте определим для начала что будем называть плоской организацией. Для простоты, пусть это будет организация с минимальным количеством управленческих слоев между руководителями (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 менеджер с инженерным бэкграундом.
Как видите, строить и масштабировать плоскую структуру в организации можно, НО сложно, долго и дорого. Зачем тогда это нужно? На выходе получается более устойчивая организация, без критических зависимостей от конкретных людей в каждой роли. Есть возможности принимать и отвечать за решения в рамках команд, большая адаптивность в рамках организации, возможности для развития и роста без карьерной иерархии.
Надо ли это всем организациям? Уверен что нет. А вы что думаете?
24.03.202518:10
На фоне падающих общих показателей по количеству открытых вакансий в Украине, рад поделиться своими горячими вакансиями.
Начнем с сильного Middle+ PHP Developer. Требуется практический опыт реализации event-driven архитектуры с микросервисами на Symphony фреймворке, RabbitMq, Kafka, PostgreSQL, MongoDb. Обязательно наличие в арсенале ключевых инженерных практик и навыков DDD. Желательно иметь практический опыт с K8S.
Вторая позиция это привычный Senior Java Developer. Тут все по классике: микросервисы, Java 21+, Spring Boot, RabbitMq, Kafka, PostgreSQL, MongoDb, разворачивание и масштабирование в AWS и K8S. Ключевым навыком является умение быстро разбираться в сложном контексте и находить эффективные решения задач в режиме неопределенности. Приветствуется e-com и fintech опыт.
Ну и наконец, Senior Golang Developer. Требуется практический опыт работы с высоконагруженными сервисами и культура применения ключевых инженерных практик. Очень желательно иметь fintech или банковский опыт.
На вопросы по вакансиям буду рад ответить в комментариях или в личке. CV можно кидать сразу в личку @xpinjection.
Начнем с сильного Middle+ PHP Developer. Требуется практический опыт реализации event-driven архитектуры с микросервисами на Symphony фреймворке, RabbitMq, Kafka, PostgreSQL, MongoDb. Обязательно наличие в арсенале ключевых инженерных практик и навыков DDD. Желательно иметь практический опыт с K8S.
Вторая позиция это привычный Senior Java Developer. Тут все по классике: микросервисы, Java 21+, Spring Boot, RabbitMq, Kafka, PostgreSQL, MongoDb, разворачивание и масштабирование в AWS и K8S. Ключевым навыком является умение быстро разбираться в сложном контексте и находить эффективные решения задач в режиме неопределенности. Приветствуется e-com и fintech опыт.
Ну и наконец, Senior Golang Developer. Требуется практический опыт работы с высоконагруженными сервисами и культура применения ключевых инженерных практик. Очень желательно иметь fintech или банковский опыт.
На вопросы по вакансиям буду рад ответить в комментариях или в личке. CV можно кидать сразу в личку @xpinjection.
11.01.202512:48
Сегодня поговорим про интересные ловушки при переходе на должность следующего уровня влияния в организации. К примеру, переход из разработчика (операционный уровень) в техлида (тактический уровень) или из техлида в солюшен архитектора (стратегический уровень). Подобные переходы есть и по другим направлениям: QA инженер -> QA лид -> QA manager/Head of QA.
В чем сложность данного перехода помимо новых зон ответственности и требований к новым навыкам? На моем опыте, ключевая сложность в том, чтобы быстро обойти ключевые ловушки развития.
Первой ловушкой является операционная работа (операционка). Она натурально засасывает в себя. Ведь еще вчера ты мог делать что-то руками и очень тяжело подвинуть это по приоритетам вниз. У кого-то дополнительно добавляется страх перестать быть профессионалом своего дела или потерять уважение коллег. Операционка стремится занять все доступное время. Она обволакивает зоной комфорта.
Тут помогает контроль распределения времени и ежедневные цели. В идеале, % операционки должен быть на таком уровне, чтобы не терять связь с реальностью. Чаще всего речь о 10-20% времени. Если в новой роли получится все идеально организовать, то можно выйти на 30%. Если процент по факту выше, то почти наверняка человек попал в эту ловушку.
Вторая по значимости ловушка заключается в тяге к понятным задачам. Мозг любит понятные задачи, на них не нужно тратить много энергии или испытывать стресс. Но понятные задачи можно и нужно делегировать при переходе в новую роль. Потому что основная ценность в новой роли кроется в решении сложных и непонятных задач или декомпозиции их на понятные.
Тут помогает парочка вопросов к самому себе при выборе следующей задачи:
- Действительно ли это самая важная задача для наших ближайших целей?
- Почему эту задачу должен взять именно я? Какую ценность мое участие в задаче принесет остальным?
- Какая часть задачи должна быть решена с моим участием? Могу ли я делегировать на каком-то уровне данную задачу?
Третья ловушка сильно связана со второй и является ее продолжением. Она заключается в недоверии к качеству работы других людей. Включается формат эксперта с предыдущего уровня: «я точно знаю как сделать правильно, а они нет». И человек начинает погружаться глубоко в каждую задачу или процесс, пытаться поучаствовать в каждом принятии решений, чтобы не упустить «отклонений от правильного пути». А это быстро приводит к бутылочным горлышкам и замедлениям, когда все ждут одного человека чтобы продвигаться дальше по своей работе.
Самый простой способ проверить нахождение в этой ловушке - это взглянуть на % времени, который человек доступен для своей команды каждый день. Если для глубокого разговора по задаче нужно искать слот в календаре на 2-3 дня вперед, то человек уже по уши в этой ловушке.
Тут главным советом является отпустить морально желание «все сделать правильно» для зон с меньшим риском. Далеко не везде ошибка имеет одинаковую стоимость, а без ошибок люди плохо учатся. Еще помогает матрица с уровнями делегирования из Management 3.0 для членов своей команды. Нужно определить уровень делегирования для каждого из них и действовать соответственно текущим уровням. И иметь целью переход на хотя бы +1 уровень за 3-6 месяцев.
А какие ловушки вы встречали на своем карьерном пути при переходе в новую роль?
В чем сложность данного перехода помимо новых зон ответственности и требований к новым навыкам? На моем опыте, ключевая сложность в том, чтобы быстро обойти ключевые ловушки развития.
Первой ловушкой является операционная работа (операционка). Она натурально засасывает в себя. Ведь еще вчера ты мог делать что-то руками и очень тяжело подвинуть это по приоритетам вниз. У кого-то дополнительно добавляется страх перестать быть профессионалом своего дела или потерять уважение коллег. Операционка стремится занять все доступное время. Она обволакивает зоной комфорта.
Тут помогает контроль распределения времени и ежедневные цели. В идеале, % операционки должен быть на таком уровне, чтобы не терять связь с реальностью. Чаще всего речь о 10-20% времени. Если в новой роли получится все идеально организовать, то можно выйти на 30%. Если процент по факту выше, то почти наверняка человек попал в эту ловушку.
Вторая по значимости ловушка заключается в тяге к понятным задачам. Мозг любит понятные задачи, на них не нужно тратить много энергии или испытывать стресс. Но понятные задачи можно и нужно делегировать при переходе в новую роль. Потому что основная ценность в новой роли кроется в решении сложных и непонятных задач или декомпозиции их на понятные.
Тут помогает парочка вопросов к самому себе при выборе следующей задачи:
- Действительно ли это самая важная задача для наших ближайших целей?
- Почему эту задачу должен взять именно я? Какую ценность мое участие в задаче принесет остальным?
- Какая часть задачи должна быть решена с моим участием? Могу ли я делегировать на каком-то уровне данную задачу?
Третья ловушка сильно связана со второй и является ее продолжением. Она заключается в недоверии к качеству работы других людей. Включается формат эксперта с предыдущего уровня: «я точно знаю как сделать правильно, а они нет». И человек начинает погружаться глубоко в каждую задачу или процесс, пытаться поучаствовать в каждом принятии решений, чтобы не упустить «отклонений от правильного пути». А это быстро приводит к бутылочным горлышкам и замедлениям, когда все ждут одного человека чтобы продвигаться дальше по своей работе.
Самый простой способ проверить нахождение в этой ловушке - это взглянуть на % времени, который человек доступен для своей команды каждый день. Если для глубокого разговора по задаче нужно искать слот в календаре на 2-3 дня вперед, то человек уже по уши в этой ловушке.
Тут главным советом является отпустить морально желание «все сделать правильно» для зон с меньшим риском. Далеко не везде ошибка имеет одинаковую стоимость, а без ошибок люди плохо учатся. Еще помогает матрица с уровнями делегирования из Management 3.0 для членов своей команды. Нужно определить уровень делегирования для каждого из них и действовать соответственно текущим уровням. И иметь целью переход на хотя бы +1 уровень за 3-6 месяцев.
А какие ловушки вы встречали на своем карьерном пути при переходе в новую роль?
23.11.202413:33
Сегодня речь пойдет об архитектурных паттернах в высоконагруженных системах. Я часто слышу как люди связывают или даже отождествляют CQRS и Event-Driven Architecture. Хотя связь между ними весьма слабая.
CQRS про разделение потоков запросов на запись и чтение с фокусом их оптимизацию. Для реализации CQRS вовсе необязательно использовать Event-Driven Architecture или вообще использовать брокер сообщений/эвентов. Хотя такая реализация тоже возможна и помогает максимально разделить записывающий и читающий компоненты, принося новую боль в виде eventual consistency.
Про разные варианты реализации CQRS можно прочитать в этой статье.
Event-Driven Architecture (EDA), в свою очередь, является архитектурным подходом к построению адаптивных, устойчивых, масштабируемых распределенных систем за счет снижения уровня связанности компонентов. В его основе лежит генерация событий об изменениях в состоянии системы и построение бизнес процессов на реакции на эти события. В рамках EDA существует множество готовых дизайн паттернов под разные кейсы.
И что еще важнее, как CQRS так и EDA могут применяться не только в микросервисной архитектуре. :)
CQRS про разделение потоков запросов на запись и чтение с фокусом их оптимизацию. Для реализации CQRS вовсе необязательно использовать Event-Driven Architecture или вообще использовать брокер сообщений/эвентов. Хотя такая реализация тоже возможна и помогает максимально разделить записывающий и читающий компоненты, принося новую боль в виде eventual consistency.
Про разные варианты реализации CQRS можно прочитать в этой статье.
Event-Driven Architecture (EDA), в свою очередь, является архитектурным подходом к построению адаптивных, устойчивых, масштабируемых распределенных систем за счет снижения уровня связанности компонентов. В его основе лежит генерация событий об изменениях в состоянии системы и построение бизнес процессов на реакции на эти события. В рамках EDA существует множество готовых дизайн паттернов под разные кейсы.
И что еще важнее, как CQRS так и EDA могут применяться не только в микросервисной архитектуре. :)
30.10.202416:01
И хорошее продолжение предыдущей темы.
#kafka
https://youtu.be/2FNhKB3DK5Y?si=1NGsY8RVGlBiXjFU
#kafka
https://youtu.be/2FNhKB3DK5Y?si=1NGsY8RVGlBiXjFU
24.09.202413:00
Я давно в канале не рекомендовал книги. Но тут просто не могу пройти мимо. За $25 вы можете получить, на мой взгляд, лучший набор книг по теме software architecture. Тут есть фундаментальные книги по архитектуре от Нила Форда, набор книг по микросервисам от Сэма Ньюмана, покрыты дополнительные архитектурные направления как Domain-Driven Design, API, Event-Driven Architecture, Serverless и т.д.
С этим набором у желающих развиваться в роль архитектора не будет вопросов что бы еще прочитать полезного минимум на год вперед. :)
#architecture #books
https://www.humblebundle.com/books/software-architecture-2024-oreilly-books
С этим набором у желающих развиваться в роль архитектора не будет вопросов что бы еще прочитать полезного минимум на год вперед. :)
#architecture #books
https://www.humblebundle.com/books/software-architecture-2024-oreilly-books
24.08.202408:54
З Днем Народження, Україна! Найкраща і найрідніша країна для мільйонів людей. Така різноманітна і неповторна, незламна і незалежна!
Великий уклін усім тим, хто бореться і ризикує своїм життям заради нашої незалежності та нашого майбутнього!
Великий уклін усім тим, хто бореться і ризикує своїм життям заради нашої незалежності та нашого майбутнього!
20.03.202510:03
На днях появился торжественный анонс Apache Kafka 4.0. Из главных новостей финально отказались от использования ZooKeeper, выкатили ранний доступ к реализации очередей и новый улучшенный протокол консьюмер групп.
Давно не было таких существенных изменений в мире Kafka. Прямо не терпится пощупать на реальных кейсах.
Давно не было таких существенных изменений в мире Kafka. Прямо не терпится пощупать на реальных кейсах.
31.12.202417:13
Подошел к концу 2024 год. В IT он однозначно запомнился поразительно быстрым развитием AI. Всего за год мы получили широкое разнообразие моделей от разных провайдеров, огромные контекстные окна, новое поколение моделей с глубоким размышлением, побили все прогнозы по бенчмаркам, получили мощные AI инструменты на десктопных ОС, мобильных телефонах, в браузерах и большинстве привычных приложений… Нам сильно повезло жить в такое удивительное время.
Из негативного, этот год стал очередным годом ужасной войны, человеческих потерь и разрушений, политических манипуляций и разочарований. Печальнее всего то, что ежедневные ужасы войны стали повседневной нормой для людей. Жизнь продолжается, люди работают, воспитывают детей, ходят в отпуск, отмечают праздники, радуются жизни и строят планы на будущее. Все это возможно благодаря усилиям ЗСУ, волонтеров и других наших защитников. За что им низкий поклон!
Пусть 2025 год станет годом долгожданной победы Украины и мирного неба над головой, принесет нам еще больше инноваций, крутых идей и реализации самых амбициозных планов. Желаю каждому прожить наступающий год так, чтобы было чем гордиться! А также крепкого вам физического и ментального здоровья. С наступающим Новым Годом! 🎄🥂🍾
Из негативного, этот год стал очередным годом ужасной войны, человеческих потерь и разрушений, политических манипуляций и разочарований. Печальнее всего то, что ежедневные ужасы войны стали повседневной нормой для людей. Жизнь продолжается, люди работают, воспитывают детей, ходят в отпуск, отмечают праздники, радуются жизни и строят планы на будущее. Все это возможно благодаря усилиям ЗСУ, волонтеров и других наших защитников. За что им низкий поклон!
Пусть 2025 год станет годом долгожданной победы Украины и мирного неба над головой, принесет нам еще больше инноваций, крутых идей и реализации самых амбициозных планов. Желаю каждому прожить наступающий год так, чтобы было чем гордиться! А также крепкого вам физического и ментального здоровья. С наступающим Новым Годом! 🎄🥂🍾
11.11.202415:23
В ноябре 2024 года я праздную сразу 2 юбилея: 20 лет работы в IT и 15 лет XP Injection. Сложно поверить что я сколько лет провел в этой индустрии.
В далеком 2004 году на предпоследнем курсе универа я начал свой путь в IT как Java разработчик в маленькой компании и сразу попал в активный водоворот развития. Через полгода мне пришлось заменять единственного заболевшего техлида, а еще через полгода я уже сам работал техлидом.
Потом был переезд в Киев, работа по аутсорс и аутстаф моделям на клиентов в USA и UK как разработчик, техлид, архитектор и инженерный менеджер. А в 2009 году я решил начать учить других людей тому, что у меня неплохо получалось и организовать с единомышленниками инженерные конференции по Java, автоматизации тестирования и инженерным практикам. Так получился XP Injection.
С тех пор я начал развиваться в направлении консалтинга, появились первые клиенты из небольших продуктовых компаний. В 2015 году я решил попробовать себя в большой корпорации на синьор менеджерской позиции и присоединился к ЕПАМ. А уже в 2017 году я понял, что не хочу работать в корпорации и решил полностью уйти в консалтинг. Так начались мои самые насыщенные и интересные годы в IT. Разные клиенты, домены, проблемы, роли, задачи и вызовы…
Эти 20 лет стали настоящей проверкой на то, действительно ли я занимаюсь любимым делом и получаю от него удовольствие. Я все еще не выгорел и полон сил, поэтому show must go on! :)
В далеком 2004 году на предпоследнем курсе универа я начал свой путь в IT как Java разработчик в маленькой компании и сразу попал в активный водоворот развития. Через полгода мне пришлось заменять единственного заболевшего техлида, а еще через полгода я уже сам работал техлидом.
Потом был переезд в Киев, работа по аутсорс и аутстаф моделям на клиентов в USA и UK как разработчик, техлид, архитектор и инженерный менеджер. А в 2009 году я решил начать учить других людей тому, что у меня неплохо получалось и организовать с единомышленниками инженерные конференции по Java, автоматизации тестирования и инженерным практикам. Так получился XP Injection.
С тех пор я начал развиваться в направлении консалтинга, появились первые клиенты из небольших продуктовых компаний. В 2015 году я решил попробовать себя в большой корпорации на синьор менеджерской позиции и присоединился к ЕПАМ. А уже в 2017 году я понял, что не хочу работать в корпорации и решил полностью уйти в консалтинг. Так начались мои самые насыщенные и интересные годы в IT. Разные клиенты, домены, проблемы, роли, задачи и вызовы…
Эти 20 лет стали настоящей проверкой на то, действительно ли я занимаюсь любимым делом и получаю от него удовольствие. Я все еще не выгорел и полон сил, поэтому show must go on! :)
28.10.202418:53
Одни из моих любимых вопросов на собеседовании касаются неблокирующих протоколов коммуникации в распределенных системах. И когда речь заходит об инструментах, то я часто слышу ответ в стиле: «мы взяли Kafka в качестве брокера, потому что она проще и меньше заморочек».
Мне кажется такое мнение появляется благодаря фреймворкам, которые упрощают дефолтный опыт разработчика и позволяют быстро стартануть с новой для них технологией. И большинство даже не разбирается что там под капотом, о каких настройках стоит знать и явно установить. Для примера рекомендую посмотреть доклад с детальным разбором как Kafka работает по стороны продюсера. Думаю, многие откроют для себя что-то новое. :)
#kafka
https://youtu.be/eHWFHFQ8tKo?si=kV0ptwyJJHuNoS_4
Мне кажется такое мнение появляется благодаря фреймворкам, которые упрощают дефолтный опыт разработчика и позволяют быстро стартануть с новой для них технологией. И большинство даже не разбирается что там под капотом, о каких настройках стоит знать и явно установить. Для примера рекомендую посмотреть доклад с детальным разбором как Kafka работает по стороны продюсера. Думаю, многие откроют для себя что-то новое. :)
#kafka
https://youtu.be/eHWFHFQ8tKo?si=kV0ptwyJJHuNoS_4
17.09.202412:26
На прошлой неделе прокатилась волна обсуждений интересного документа. Опубликовали "утекшую" версию (я не уверен что такие утечки случаются без причин) описания внутренних принципов работы компании 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 каналов улучшить свои показатели.
Сразу оговорюсь, неизвестно насколько всем этим принципам и паттернам следуют на практике. Вот ТОП-10, зацепивших меня во время прочтения документа:
1. Hands-on основатель, глубоко понимающий бизнес, который тесно интегрирован в работу организации на всех уровнях. Он ассоциирует себя и свою жизнь с продуктом и его успешностью.
2. На ключевых позициях A-players, на вырост B-players, отказ от C-players. Ставка на лидерство и проактивность.
3. Четкие и понятные принципы, которыми руководствуются сотрудники организации (креатив - основной двигатель, ответственность за результат, учиться на своих ошибках и т.д.).
4. Прозрачные цели и формализованные метрики, которыми можно измерять успешность, а не фантазировать на тему успеха.
5. Ответственность за результат, а не за процесс. Взятие ответственности за достижение результата, а не перекладывание ее на обстоятельства, подрядчиков и другие причины.
6. Признание своих ошибок и извлечение из них уроков как обязательный элемент культуры.
7. Постоянный рост зрелости организации по всем фронтам (иначе сложность работы просто захлестнет и не получится поддерживать качество).
8. Строгое управление приоритетами с фокусом на критичные элементы. Управление рисками от критичных элементов.
9. Экономия бюджета за счет креативности. Бюджет важен, но не должен становиться ограничением креативности на пути к цели, за счет креативности можно экономить.
10. Привлечение консультантов и внешней экспертизы в тех областях, где нет своей экспертизы или недостаточно опыта. За счет этого можно достичь большой экономии времени (критичный ресурс) и затрат на неверные решения.
В документе также отлично разобрана тема производства популярных видео на YouTube. Может помочь владельцам YouTube каналов улучшить свои показатели.
18.08.202412:35
Я взял паузу и некоторое время ничего не публиковал в канале. Нужно было «перезарядить батарейки» и немного разгрестись по работе. Теперь буду возвращаться к регулярным постам.
Сегодня хочу затронуть тему коммуникационных стилей в распределенных системах. С популяризацией микросервисов очень много команд перешли из мира локальных вызовов кода к сильно распределенным системам. И первым натуральным позывом было просто заменить локальные вызовы на синхронные 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
Сегодня хочу затронуть тему коммуникационных стилей в распределенных системах. С популяризацией микросервисов очень много команд перешли из мира локальных вызовов кода к сильно распределенным системам. И первым натуральным позывом было просто заменить локальные вызовы на синхронные 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
显示 1 - 24 共 679
登录以解锁更多功能。