Forwarded from Токсичный (it) архитектор
Спрашиваю: «Какая нагрузка планируется?».
Ответ: «Ну, человек 50 в день... но мы готовимся к скейлу!».
В этот момент мне захотелось выйти в окно.
Давайте начистоту. Это не проработка архитектуры и не забота о будущей нагрузке. Это резюме-ориентированная разработка.
Вы тащите в проект технологии не потому, что они нужны бизнесу. А потому, что с ними ваше резюме выглядит сексуальнее для рекрутеров из Big Tech. Вам плевать, как это потом поддерживать. Главное - получить строчку в CV и свалить на +100к, пока этот карточный домик не рухнул.
Это не инженерия, а профессиональный саботаж.
Вы строите «Звезду Смерти» для доставки пиццы. В итоге мы получаем:
❗️Оверинжиниринг. Сложность системы растет экспоненциально, а польза - линейно.
❗️Техническую беспомощность. Когда ваш Istio отрыгнет ошибку, никто не поймет, почему. Потому что вы скопировали конфиг с Medium или Хабра, даже не читая документацию.
❗️Бюджет в трубу. Вместо фич бизнес платит за оплату облаков, которые просто греют воздух.
Хватит играть в стартаперов из Кремниевой долины.
📍Скука - это надежность. Скучный монолит + PostgreSQL вывезет 99% ваших задач.
📍Доказывайте необходимость. Хочешь Kafka? Покажи мне метрики, где RabbitMQ задыхается или где база лочит таблицу. Не можешь? Иди пиши код, а не занимайся ерундой.
📍Думайте о TCO (Total Cost of Ownership). Стоимость технологии - это не цена лицензии. Это зарплата тех бедолаг, которые будут чинить ваши «инновации» в 3 часа ночи.
Настоящий сеньор - это не тот, кто знает все баззворды. Это тот, кто умеет решать сложные задачи простыми инструментами, а сложные инструменты оставляет для действительно сложных проблем, а не для своего эго.
#заметкинаполях
Токсичный (it) архитектор
Please open Telegram to view this post
VIEW IN TELEGRAM
👍49👏21🔥15❤7💯5🤔3😁1
#продуктовое #манагерское
В уходящем году подрабатывал селебой.
Сначала меня позвал на стрим Невзоров. Говорили о жизни, карьере, переходе в продакты, и почему все тлен. Активно призывал думать о целях и желаниях, прежде чем ломиться в хайповые профессии.
Запись в канале Владимира — System Design World, там вообще много полезного.
Потом с Наташей Семеновой обсуждали переход из аналитика в продакты, уже более точечно. Рассказывал о темной стороне продуктовой жизни, и всячески источал скепсис и негилизм.
Запись в канале Smart Effect — там интересное про публичность, выступления и поиск себя до, после и около IT.
Главные тезисы про переходы в продакта, если лень смотреть:
— Профессия безумно романтизирована, во многих компаниях вы будете делать то, что решили топы, но отвечать за результат будете вы
— Ответственности больше, денег меньше, жизнь хуже
— Технарям должны проще даваться переходы в b2dev, b2b, платформенные продукты
— Если все равно невыносимо хочется в продукт, старайтесь делать переход внутри компании
В уходящем году подрабатывал селебой.
Сначала меня позвал на стрим Невзоров. Говорили о жизни, карьере, переходе в продакты, и почему все тлен. Активно призывал думать о целях и желаниях, прежде чем ломиться в хайповые профессии.
Запись в канале Владимира — System Design World, там вообще много полезного.
Потом с Наташей Семеновой обсуждали переход из аналитика в продакты, уже более точечно. Рассказывал о темной стороне продуктовой жизни, и всячески источал скепсис и негилизм.
Запись в канале Smart Effect — там интересное про публичность, выступления и поиск себя до, после и около IT.
Главные тезисы про переходы в продакта, если лень смотреть:
— Профессия безумно романтизирована, во многих компаниях вы будете делать то, что решили топы, но отвечать за результат будете вы
— Ответственности больше, денег меньше, жизнь хуже
— Технарям должны проще даваться переходы в b2dev, b2b, платформенные продукты
— Если все равно невыносимо хочется в продукт, старайтесь делать переход внутри компании
👍12🔥5💯4❤2
Кажется, последний анонс в этом году.
Мы решили провести в субботу открытую встречу System Design клуба, в облегченном формате и с необычной темой — проектирование системой рекомендаций. Узнаем про особенности проектирования ML-систем, инфру, построение пайплайнов и обеспечение качества.
Работаем ручками, в группах. “Просто послушать” приходить не надо. Записи не будет.
А через два часа начинаем мини-курс по промпт и контекст инжинирингу для анализа и проектирования. В следующем году будем развивать тему уже в сторону агентов, а пока можно заскочить по новогодним ценам.
Мы решили провести в субботу открытую встречу System Design клуба, в облегченном формате и с необычной темой — проектирование системой рекомендаций. Узнаем про особенности проектирования ML-систем, инфру, построение пайплайнов и обеспечение качества.
Работаем ручками, в группах. “Просто послушать” приходить не надо. Записи не будет.
А через два часа начинаем мини-курс по промпт и контекст инжинирингу для анализа и проектирования. В следующем году будем развивать тему уже в сторону агентов, а пока можно заскочить по новогодним ценам.
🔥7❤1
#околообразование
Наткнулся на на чей-то рилс про образование, там была мысль: “абсолютное большинство задач в ит - типовые. Обычно ты даешь студенту задание на самостоятельный поиск шаблонного решения, чтобы в будущем он мог распознавать соотвествующие задачи и тюнить решени при необходимости”. Примерно об этом же я писал тут.
Вроде я топлю за максимальное использование иишечки, в том числе при самообучении но расстраиваюсь на тренингах, когда вижу участников, которые просто закидывают задачу в гпт. Может в работе модельки смогут решать их задачи, но проверять, направлять и адаптировать решение уже не получится.
С другой стороны, если какие-то задачи нормально решают модельки, то однажды мы должны подняться еще на один уровень абстракции, как это было много раз? Только пока не понятно, как он будет выглядеть. В интересное время живем все же.
А с другой, адекватный манагер вполне может работать с более экспертными сотрудниками, даже должен. Тогда зачем ему нанимать людей, которые работают проксей к модельке?
Наткнулся на на чей-то рилс про образование, там была мысль: “абсолютное большинство задач в ит - типовые. Обычно ты даешь студенту задание на самостоятельный поиск шаблонного решения, чтобы в будущем он мог распознавать соотвествующие задачи и тюнить решени при необходимости”. Примерно об этом же я писал тут.
Вроде я топлю за максимальное использование иишечки, в том числе при самообучении но расстраиваюсь на тренингах, когда вижу участников, которые просто закидывают задачу в гпт. Может в работе модельки смогут решать их задачи, но проверять, направлять и адаптировать решение уже не получится.
С другой стороны, если какие-то задачи нормально решают модельки, то однажды мы должны подняться еще на один уровень абстракции, как это было много раз? Только пока не понятно, как он будет выглядеть. В интересное время живем все же.
А с другой, адекватный манагер вполне может работать с более экспертными сотрудниками, даже должен. Тогда зачем ему нанимать людей, которые работают проксей к модельке?
❤7👍6
#оффтоп #блохерское
Захотелось поделиться техническими каналами, которые приглянулись за последнее время.
Женя Янченко — тимлид разработки, пишет про технику с учетом собственного опыта, поэтому интересно читать, в отличии дефолтных карточек с пересказом спеки, которые затопили телегу. Еще есть рубрика карьерных диалогов.
Катя Пантелей — про жизнь спикера и аналитика. Осмысление DDD, Event Storming, интеграции через практику, на своих и чужих кейсах.
Токсичный it архитектор — незнаком с автором, но токсичный я токсично любит токсичные каналы, теперь про архитектуру. Еще одно напоминание, почему стоит критически относиться к громким модным словам.
Макс Шаломович наконец-то запилил канал. Год назад, но я только сейчас нашел. Тоже об архитектуре и без уважения.
Крутой AI-аналитик от Елены Беляевой — об анализе и немного о психологии с использованием AI
И вы скидывайте в комменты интересное, свои тоже можно.
Захотелось поделиться техническими каналами, которые приглянулись за последнее время.
Женя Янченко — тимлид разработки, пишет про технику с учетом собственного опыта, поэтому интересно читать, в отличии дефолтных карточек с пересказом спеки, которые затопили телегу. Еще есть рубрика карьерных диалогов.
Катя Пантелей — про жизнь спикера и аналитика. Осмысление DDD, Event Storming, интеграции через практику, на своих и чужих кейсах.
Токсичный it архитектор — незнаком с автором, но токсичный я токсично любит токсичные каналы, теперь про архитектуру. Еще одно напоминание, почему стоит критически относиться к громким модным словам.
Макс Шаломович наконец-то запилил канал. Год назад, но я только сейчас нашел. Тоже об архитектуре и без уважения.
Крутой AI-аналитик от Елены Беляевой — об анализе и немного о психологии с использованием AI
И вы скидывайте в комменты интересное, свои тоже можно.
🔥10❤1
h2h-продажи, школа, манагерство
Благодаря NextWay в этом году пришлось залезть в маркетинг и продажи. Больше всего в этой сфере бесит ванильная восторженность креативов, которая лезет из всех щелей, и бесконечная навязчивость сейлзов. Я искренне пытался делать так же, но внутреннее отвращение пересилить не получилось. Ну камон, вы на канальчик мой посмотрите.
Как-то так я оказался на марафоне Юли, где узнал о концепте human2human коммуникаций. Изначально эта штука выросла из продаж как идея перехода от агрессивного впаривания здесь и сейчас к построению долгосрочных отношений. Но ничто не мешает переносить эти принципы в манагерство и просто отношения с коллегами.
Давно хотел выплеснуть эти идеи на бумагу, а тут Юля подкинула волшебного пенделя. Хочется пафосно заявить, что всех этих принципов я всегда и везде придерживаюсь… но камон, вы на меня посмотрите.
Благодаря NextWay в этом году пришлось залезть в маркетинг и продажи. Больше всего в этой сфере бесит ванильная восторженность креативов, которая лезет из всех щелей, и бесконечная навязчивость сейлзов. Я искренне пытался делать так же, но внутреннее отвращение пересилить не получилось. Ну камон, вы на канальчик мой посмотрите.
Как-то так я оказался на марафоне Юли, где узнал о концепте human2human коммуникаций. Изначально эта штука выросла из продаж как идея перехода от агрессивного впаривания здесь и сейчас к построению долгосрочных отношений. Но ничто не мешает переносить эти принципы в манагерство и просто отношения с коллегами.
Давно хотел выплеснуть эти идеи на бумагу, а тут Юля подкинула волшебного пенделя. Хочется пафосно заявить, что всех этих принципов я всегда и везде придерживаюсь… но камон, вы на меня посмотрите.
👍5
Forwarded from А что, так можно было? Максина Юля
Продолжаю рубрику #своилюди, где я рассказываю вам про своих крутых знакомых!
Задала несколько вопросов Андрею Буракову — участнику последнего потока H2H-феста, моего курса-фестивала по human-to-human-продажам. Андрей — основатель школы анализа и проектирования NextWay, ментор и автор канала Another Tech Product.
Расспросила Андрея про H2H в работе с айтишниками, лидерство и доверие в команде.
1️⃣ Три ключевых идеи из H2H-феста, которые изменили твое видение коммуникаций?
— Не гнаться за сиюминутной выгодой и локальными победами, строить долгосрочную стратегию совместной работы, удовлетворяющую собственные и чужие интересы.
— Говорить на человеческом, как с живыми людьми, а не «клиентами», «контрагентами» и прочими объектами удовлетворения собственных интересов.
— Быть собой, не надевать чуждые роли.
2️⃣ Практики, которые помогают тебе как лидеру сохранять доверие в команде?
Право на ошибку
Однажды сотрудница поделилась: «Благодаря тому, что вы с ХХХ всегда поддерживаете меня во внешних коммуникациях, я не боюсь экспериментировать и пробовать что-то новое в команде».
Пространство для идей
Не стоит сразу критиковать и отвергать нерабочие идеи, это вызывает реакцию: «Зачем что-то предлагать, у него всегда найдется тысяча причин, почему нет».
Во-первых, вы знаете, что идея не сработает, или так думаете?
Во-вторых, люди не учатся без ошибок, задача руководителя — создать условия, в которых это можно безопасно делать. Например, помочь допилить идею и указать на возможные проблемы, но сохранить ответственность за реализацию за сотрудником.
Нормально признавать ошибки
Если сотрудник понимает это, то ему будет проще обратиться за помощью, а вы будете заранее узнавать о проблемах, а не в последний момент.
Руководителю тоже. Способность признать ошибки в большинстве случаев повышает доверие и уважение со стороны команды.
А если кто-то использует вашу открытость как инструмент манипуляций, то вы будете знать его в лицо;)
3️⃣ Как найти баланс между доверием и контролем?
— Только экспериментально. Начинать с некоторого дефолтного кредита доверия для всех и дальше корректировать его под результаты и поведение сотрудника.
— Не лезть в стили руководства и коммуникаций, которые тебе не свойственны, оставаться собой. Люди отлично распознают фальш
— Прислушиваться к интуиции. Не всегда получается формализовать ощущения, но не стоит их игнорировать. Если вам кажется, то вам не кажется.
〰️ 〰️ 〰️
Какие идеи Андрея откликаются? Поделитесь в комментах
Юля Максина | А что, так можно было?
Задала несколько вопросов Андрею Буракову — участнику последнего потока H2H-феста, моего курса-фестивала по human-to-human-продажам. Андрей — основатель школы анализа и проектирования NextWay, ментор и автор канала Another Tech Product.
Расспросила Андрея про H2H в работе с айтишниками, лидерство и доверие в команде.
— Не гнаться за сиюминутной выгодой и локальными победами, строить долгосрочную стратегию совместной работы, удовлетворяющую собственные и чужие интересы.
— Говорить на человеческом, как с живыми людьми, а не «клиентами», «контрагентами» и прочими объектами удовлетворения собственных интересов.
— Быть собой, не надевать чуждые роли.
Право на ошибку
Однажды сотрудница поделилась: «Благодаря тому, что вы с ХХХ всегда поддерживаете меня во внешних коммуникациях, я не боюсь экспериментировать и пробовать что-то новое в команде».
Пространство для идей
Не стоит сразу критиковать и отвергать нерабочие идеи, это вызывает реакцию: «Зачем что-то предлагать, у него всегда найдется тысяча причин, почему нет».
Во-первых, вы знаете, что идея не сработает, или так думаете?
Во-вторых, люди не учатся без ошибок, задача руководителя — создать условия, в которых это можно безопасно делать. Например, помочь допилить идею и указать на возможные проблемы, но сохранить ответственность за реализацию за сотрудником.
Нормально признавать ошибки
Если сотрудник понимает это, то ему будет проще обратиться за помощью, а вы будете заранее узнавать о проблемах, а не в последний момент.
Руководителю тоже. Способность признать ошибки в большинстве случаев повышает доверие и уважение со стороны команды.
А если кто-то использует вашу открытость как инструмент манипуляций, то вы будете знать его в лицо;)
— Только экспериментально. Начинать с некоторого дефолтного кредита доверия для всех и дальше корректировать его под результаты и поведение сотрудника.
— Не лезть в стили руководства и коммуникаций, которые тебе не свойственны, оставаться собой. Люди отлично распознают фальш
— Прислушиваться к интуиции. Не всегда получается формализовать ощущения, но не стоит их игнорировать. Если вам кажется, то вам не кажется.
Какие идеи Андрея откликаются? Поделитесь в комментах
Юля Максина | А что, так можно было?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍2
#AI
Долго думал, зачем люди сидят в ии-браузерах. Пару дней назад поставил Comet, теперь думаю, зачем люди сидят без ии-браузеров. Сам гуглит, сам правит ошибки, сам таблички заполняет, и вообще все сам. Мышцы копипасты радостно отдыхают
А вы уже пробовали? Нашли какой-то профит для себя?
Долго думал, зачем люди сидят в ии-браузерах. Пару дней назад поставил Comet, теперь думаю, зачем люди сидят без ии-браузеров. Сам гуглит, сам правит ошибки, сам таблички заполняет, и вообще все сам. Мышцы копипасты радостно отдыхают
А вы уже пробовали? Нашли какой-то профит для себя?
1🤣15❤3
Тем временем IBM купил-таки Confluent (это которые Кафку делают).
Наверное, хорошая новость для клиентов IBM, сомнительно - для любиителей Кафки. Не удивлюсь, если на горизонте лет пяти в РФ эту нишу заполнит YDB.
Кстати, цена вопроса - всего $11 ярдов. Вот вам и мировой почти стандарт.
Наверное, хорошая новость для клиентов IBM, сомнительно - для любиителей Кафки. Не удивлюсь, если на горизонте лет пяти в РФ эту нишу заполнит YDB.
Кстати, цена вопроса - всего $11 ярдов. Вот вам и мировой почти стандарт.
#манагерское
Имел когда-то чудесный диалог с руководителем:
— У нас разрабы не умеют разговаривать друг с другом
— Я знаю, у меня есть план
— Какой?
— Я найму специального проджекта, который затащит все коммуникации
… *дабл фейспалм*
Вроде бытовой опыт и эволюция четко говорят: use it or lose it.
Забросил на пару лет английский - лет ми спик фром май харт.
Забросил трены - подъем на 10 этаж превращается в челлендж.
Бросил прыгать по веткам - бананы только за деньги.
Но что мы делаем на работе? Праааавильно:
• бизнес и разработка не понимают друг друга — поставим туда аналитика!
• команды не могут договориться об интеграции — нам нужен архитектор!
• три лида не осилили собраться на звонок — срочно зовем проджекта!
• разрабы пишут код, который рассыпается при каждом чихе — нужно больше QA!
Решать исходную проблему не будем, воткнем костыль и будет счастье. Плевать, что исходная проблема скрыто растет: технари еще дальше от бизнеса, разрабы плодят говнокод, у команд отмирают органы коммуникаций. А когда все это вылезет, мы выбьем еще бюджетов, и засунем х10 костылей.
Хотя постойте… бюджетов больше нет?
Имел когда-то чудесный диалог с руководителем:
— У нас разрабы не умеют разговаривать друг с другом
— Я знаю, у меня есть план
— Какой?
— Я найму специального проджекта, который затащит все коммуникации
… *дабл фейспалм*
Вроде бытовой опыт и эволюция четко говорят: use it or lose it.
Забросил на пару лет английский - лет ми спик фром май харт.
Забросил трены - подъем на 10 этаж превращается в челлендж.
Бросил прыгать по веткам - бананы только за деньги.
Но что мы делаем на работе? Праааавильно:
• бизнес и разработка не понимают друг друга — поставим туда аналитика!
• команды не могут договориться об интеграции — нам нужен архитектор!
• три лида не осилили собраться на звонок — срочно зовем проджекта!
• разрабы пишут код, который рассыпается при каждом чихе — нужно больше QA!
Решать исходную проблему не будем, воткнем костыль и будет счастье. Плевать, что исходная проблема скрыто растет: технари еще дальше от бизнеса, разрабы плодят говнокод, у команд отмирают органы коммуникаций. А когда все это вылезет, мы выбьем еще бюджетов, и засунем х10 костылей.
Хотя постойте… бюджетов больше нет?
2💯34😐6❤3🤔2👍1🔥1🥱1🤨1😭1
#оффтоп
Искренне восхищаюсь, как люди изобретают высокие смыслы для бизнеса. Интересно, как табачки миссии формулируют?
Искренне восхищаюсь, как люди изобретают высокие смыслы для бизнеса. Интересно, как табачки миссии формулируют?
Компания: ХХХ - ведущий импортер, дистрибьютор и ритейлер алкогольной продукции
Наша миссия - повышать качество жизни людей через развитие винной культуры, и мы ищем человека, который будет работать над продуктом с тем же азартом и любовью к вину, что и мы.
😁21👍7🫡1
#манагерское
Бизнес vs Разработка
Ожидаемо после таких вбросов начинают сыпаться комменты:
И подобное. Простите, но…
Никакого Бизнеса не существует. Разработки тоже. Как и Требований, об этом уже писал.
Зато существует компания, в которой работают сотрудники, у которой есть руководство. Поразительно, но у всех этих людей есть свои цели. Но это неважно.
Важно, что руководство (должно) строит систему, в которой работа сотрудников приближает компанию к ее целям (обычно это деньги). И если в рамках системы возникают дихотомии вида: Бизнес vs Разработка, Продукт vs Финансы, Пиар vs Юристы — это фиаско. Как и любое противопоставление “вот есть мы, вот есть (тупые) они”.
Причем внутри итшечки это понимание существует. Сейчас почти повсеместным стандартом считаются кросс-функциональные команды, в которых собраны все необходимые роли. Необходимые для создания проекта/платформы/продукта. Отцы аджайлов настаивали, что в команды нужно затаскивать и бизнес экспертов. Интересно, почему?
Но, если вернутся на 15 лет назад и посмотреть на устройство ит в РФ, то вместо модных автономных команд увидим отделы / службы / функции разработки, анализа, тестирования, которые перекидываются задачами и регулярно ненавидят друг друга. Интересно, почему?
Получается, компании часто устроены по принципу тех же функциональных колодцев, от которых в свое время уходила итшечка, ибо это неэффективно. Интересно, почему?
Наверное потому, что вокруг одни идиоты?
Или потому, что многим это выгодно?
Зачем совместно искать решение проблем, пути достижения целей, если всегда можно заявить, что криворукая “разработка” опять сделала не то и сорвала все сроки, а тупой “бизнес” сам не понимает, чего хочет? Если прикрываться достаточным количеством переписок, встреч, нытья, можно бесконечно избегать ответственности за результат. В крайнем случае компанию сменим.
И выгодно это как хедам-лидам, так и линейным сотрудникам. Поэтому после серьезных факапов начинаются зарубы Бизнес vs Разработка, хотя в этот момент тимлид и продакт должны взяться за руки и вежливо выйти в окно.
Поэтому неважно, куда хочет инвестировать разработчик, как мычит заказчик, и о чем говорят мужчины. Важно, какое поведение возможно и выгодно в рамках существующей системы.
Хз, зачем вам эта портянка, может уснуть поможет
Бизнес vs Разработка
Ожидаемо после таких вбросов начинают сыпаться комменты:
Бизнес и разработка не понимают друг друга - это база, причем любой бизнес и любая разработка. Большинство заказчиков могут ТЗ записать только голосовым сообщением на 8 минут, из которых половина - мычание, а разрабы в душе не чают, какие проблемы бизнес пытается решить.
Разрабы поняли давно, что повышение дохода возможно только через смену работодателя. средний срок на одно месте 1-3 года. Глупо инвестировать в погружение в бизнес-проблематику, а вы всё про какой-то общий язык - ну что за фантазии!
И подобное. Простите, но…
Никакого Бизнеса не существует. Разработки тоже. Как и Требований, об этом уже писал.
Зато существует компания, в которой работают сотрудники, у которой есть руководство. Поразительно, но у всех этих людей есть свои цели. Но это неважно.
Важно, что руководство (должно) строит систему, в которой работа сотрудников приближает компанию к ее целям (обычно это деньги). И если в рамках системы возникают дихотомии вида: Бизнес vs Разработка, Продукт vs Финансы, Пиар vs Юристы — это фиаско. Как и любое противопоставление “вот есть мы, вот есть (тупые) они”.
Причем внутри итшечки это понимание существует. Сейчас почти повсеместным стандартом считаются кросс-функциональные команды, в которых собраны все необходимые роли. Необходимые для создания проекта/платформы/продукта. Отцы аджайлов настаивали, что в команды нужно затаскивать и бизнес экспертов. Интересно, почему?
Но, если вернутся на 15 лет назад и посмотреть на устройство ит в РФ, то вместо модных автономных команд увидим отделы / службы / функции разработки, анализа, тестирования, которые перекидываются задачами и регулярно ненавидят друг друга. Интересно, почему?
Получается, компании часто устроены по принципу тех же функциональных колодцев, от которых в свое время уходила итшечка, ибо это неэффективно. Интересно, почему?
Наверное потому, что вокруг одни идиоты?
Или потому, что многим это выгодно?
Зачем совместно искать решение проблем, пути достижения целей, если всегда можно заявить, что криворукая “разработка” опять сделала не то и сорвала все сроки, а тупой “бизнес” сам не понимает, чего хочет? Если прикрываться достаточным количеством переписок, встреч, нытья, можно бесконечно избегать ответственности за результат. В крайнем случае компанию сменим.
И выгодно это как хедам-лидам, так и линейным сотрудникам. Поэтому после серьезных факапов начинаются зарубы Бизнес vs Разработка, хотя в этот момент тимлид и продакт должны взяться за руки и вежливо выйти в окно.
Поэтому неважно, куда хочет инвестировать разработчик, как мычит заказчик, и о чем говорят мужчины. Важно, какое поведение возможно и выгодно в рамках существующей системы.
👏33👍11😁4❤3👎2🔥2👌1
#интеграция
Ладно, давайте о насущном. Меня дико бесит, когда маркетологи играют на FOMO. Но я ж не маркетолог?
Поэтому сейчас будет реклама и немножко грустно.
В июне 2022 я провел первый интенсив по REST API, с которого начался путь ArchWays / NextWay. Это были длинные выхи, где за три дня аналитики научились проектировать, тестировать, документировать апи. Вроде до этого формата быстрого глубокого погружения на рынке не было, но неуверен. Точно один из первых. Сейчас интенсив вырос в месячный курс, где рассматриваем работу с API намного шире и регулярно боремся с желание сделать его вдвое больше.
В начале 2023 мы запустили хардкорный тренинг по брокерам, где сначала на теннисных мячиках и простых аналогиях разбирали принципы обмена сообщениями, а потом анатомировали Кафку до деталей сериализации и устройства кластера. Получилось даже слишком хардкорно, поэтому позже пересобрали его под специфику аналитиков, добавили симуляторов и работу с RabbitMQ.
Так где реклама, фомо, почему грустно?
Ближайшие полторы недели стартуют очередные потоки этих курсов, вероятно последние.
Несколько лет назад это были самые передовые и острые темы, сейчас это базовый минимум для многих вакансий. Заниматься commodity не слишком интересно, поэтому думаем перевести их в менее интерактивный формат.
Если думали зайти, то вот расписание:
• Основы проектирования API — 31 января
• Брокеры сообщений для аналитика — 8 февраля
Можно взять оба разом, неплохой скидос получится.
Ладно, давайте о насущном. Меня дико бесит, когда маркетологи играют на FOMO. Но я ж не маркетолог?
Поэтому сейчас будет реклама и немножко грустно.
В июне 2022 я провел первый интенсив по REST API, с которого начался путь ArchWays / NextWay. Это были длинные выхи, где за три дня аналитики научились проектировать, тестировать, документировать апи. Вроде до этого формата быстрого глубокого погружения на рынке не было, но неуверен. Точно один из первых. Сейчас интенсив вырос в месячный курс, где рассматриваем работу с API намного шире и регулярно боремся с желание сделать его вдвое больше.
В начале 2023 мы запустили хардкорный тренинг по брокерам, где сначала на теннисных мячиках и простых аналогиях разбирали принципы обмена сообщениями, а потом анатомировали Кафку до деталей сериализации и устройства кластера. Получилось даже слишком хардкорно, поэтому позже пересобрали его под специфику аналитиков, добавили симуляторов и работу с RabbitMQ.
Так где реклама, фомо, почему грустно?
Ближайшие полторы недели стартуют очередные потоки этих курсов, вероятно последние.
Несколько лет назад это были самые передовые и острые темы, сейчас это базовый минимум для многих вакансий. Заниматься commodity не слишком интересно, поэтому думаем перевести их в менее интерактивный формат.
Если думали зайти, то вот расписание:
• Основы проектирования API — 31 января
• Брокеры сообщений для аналитика — 8 февраля
Можно взять оба разом, неплохой скидос получится.
❤9👍2💔1
#архитектура
Александр Поломодов запустил собственный ресурс по систем дизайну. Ощущение, будто основной фокус на подготовке к собесам. Но можно использовать как справочник: быстро глянул саммари и пошел изучать источники по ссылкам.
https://system-design.space/
Александр Поломодов запустил собственный ресурс по систем дизайну. Ощущение, будто основной фокус на подготовке к собесам. Но можно использовать как справочник: быстро глянул саммари и пошел изучать источники по ссылкам.
https://system-design.space/
System Design Space
System Design Space — Проектируй лучшие системы и проходи интервью
Изучай System Design для создания надёжных масштабируемых систем и успешного прохождения технических собеседований.
🔥16
Я уже писал, как можно использовать лего-программирование aka low-coding в качестве тренажера по проектированию.
Берете какого-нибудь бота или вебку с не самой тривиальной логикой и пилите для него бек в условном нейтоне. Бот проще, чтобы с фронтом не заморачиваться, хотя это можно взять следующим шагом.
И тут начинается веселье:
— Как лучше всего работать со стейтом? Для каких объектов вводить статусную модель?
— С каким сервисом удобнее работать: stateless или stateful?
— Давай поделим этот гигантский флоу (монолит) на несколько (микросервисов). Повлияет ли это на производительность?
— Почему бот отвечает так долго? На чем теряем время?
— Как оптимизировать работу с базой? Можно что-нибудь закэшировать?
— Выросла нагрузка, в моем тарифе ограничение на количество параллельных запусков. Сколько будет стоить масштабирование?
Т.е. проходим цикл проектирования системы от дизайна апи и бд до солюшн архитектуры.
Об этом буду вещать в субботу на Analyst Marathon в докладе Лего-программирование для аналитика.
Всего будет три блока:
• Архитектура и интеграция
• Безопасность и дынные
• Инструменты и практика
Зарегистрироваться и посмотреть всю программу можно тут.
Если пойдете, захватите скидос на 15% — AM16_YET
Берете какого-нибудь бота или вебку с не самой тривиальной логикой и пилите для него бек в условном нейтоне. Бот проще, чтобы с фронтом не заморачиваться, хотя это можно взять следующим шагом.
И тут начинается веселье:
— Как лучше всего работать со стейтом? Для каких объектов вводить статусную модель?
— С каким сервисом удобнее работать: stateless или stateful?
— Давай поделим этот гигантский флоу (монолит) на несколько (микросервисов). Повлияет ли это на производительность?
— Почему бот отвечает так долго? На чем теряем время?
— Как оптимизировать работу с базой? Можно что-нибудь закэшировать?
— Выросла нагрузка, в моем тарифе ограничение на количество параллельных запусков. Сколько будет стоить масштабирование?
Т.е. проходим цикл проектирования системы от дизайна апи и бд до солюшн архитектуры.
Об этом буду вещать в субботу на Analyst Marathon в докладе Лего-программирование для аналитика.
Всего будет три блока:
• Архитектура и интеграция
• Безопасность и дынные
• Инструменты и практика
Зарегистрироваться и посмотреть всю программу можно тут.
👍5
Чет забыл рассказать, что вечером делаем стрим с Алексеем Романовым про gRPC. Он как-то показывал бенчмарки производительности HTTP / Keep-alive / gRPC, и меня прям удивил результат. Обсудим, как все работает в жизни, а не в ванильных статьях и чек-листах по выбору технологий.
Telegram
NextWay - системный анализ и архитектура
Давно не встречались на вебинарах, мы успели соскучиться. Поэтому пригласили Алексея Романова, чтобы поговорить об использовании gRPC в реальности, его производительности и киллерфичах. И чтобы выяснить, стоит ли оно того вообще?
• Вспомним, как работает…
• Вспомним, как работает…
👍4👎1
#вайбкодинг
Чем использование код-агентов aka вайбкодинг полезно аналитику?
Если работаете в парадигме сontract first, а так сейчас работают многие, то после правки или создания спеки можно запихнуть сваггер+логику в код-агента и получить прототип сервиса. Работу с базой имитировать на уровне кода, об этом тоже агента попросим.
Разворачиваем локально, на vps, корп сервере и получаем апи, которое можно подергать постманом и посмотреть на поведение. Зачем?
• Провалидировать свое же решение и спеку
• Скинуть разрабу вместе со спекой, если он готов к новому — тут точно будет сложно из-за предрассудков
• Скинуть потребителям, если сами не осиливают моки, а вашей команде не до этого
• Почувствовать на секунду акт творения и получить недорогого дофамина
Если сервис взаимодействует с базой или брокером, можно немного упороться, взять докер и развернуть ту же постгрю и кластер кафки.
Общий процесс разработки такие эксперименты могут и не ускорить, зато вы неслабо прокачаетесь в понимании работы технологий на "техническом" уровне. И есть у меня подозрение, что в течение 5 лет это придется делать половине аналитиков.
Если на работе жестко с ИБ и процессами, берите пет-проект, спеку с курсов, любое понравившееся публичное апи.
P.S. Код-агент — это Cursor, Codex, Claude Code и т.п.
Чем использование код-агентов aka вайбкодинг полезно аналитику?
Если работаете в парадигме сontract first, а так сейчас работают многие, то после правки или создания спеки можно запихнуть сваггер+логику в код-агента и получить прототип сервиса. Работу с базой имитировать на уровне кода, об этом тоже агента попросим.
Разворачиваем локально, на vps, корп сервере и получаем апи, которое можно подергать постманом и посмотреть на поведение. Зачем?
• Провалидировать свое же решение и спеку
• Скинуть разрабу вместе со спекой, если он готов к новому — тут точно будет сложно из-за предрассудков
• Скинуть потребителям, если сами не осиливают моки, а вашей команде не до этого
• Почувствовать на секунду акт творения и получить недорогого дофамина
Если сервис взаимодействует с базой или брокером, можно немного упороться, взять докер и развернуть ту же постгрю и кластер кафки.
Общий процесс разработки такие эксперименты могут и не ускорить, зато вы неслабо прокачаетесь в понимании работы технологий на "техническом" уровне. И есть у меня подозрение, что в течение 5 лет это придется делать половине аналитиков.
Если на работе жестко с ИБ и процессами, берите пет-проект, спеку с курсов, любое понравившееся публичное апи.
P.S. Код-агент — это Cursor, Codex, Claude Code и т.п.
👍22🔥7💯5
Если вдруг юзаете аиртейбл, или у вас там лежит что-то полезное, знайте:
Причем хитро отслеживает, с левого акка сидел.
Airtable will no longer be available to users whose accounts are associated with Russia. Your account will be deactivated on February 19, 2026
Причем хитро отслеживает, с левого акка сидел.
😢4😨1