#околообразование
Наткнулся на на чей-то рилс про образование, там была мысль: “абсолютное большинство задач в ит - типовые. Обычно ты даешь студенту задание на самостоятельный поиск шаблонного решения, чтобы в будущем он мог распознавать соотвествующие задачи и тюнить решени при необходимости”. Примерно об этом же я писал тут.
Вроде я топлю за максимальное использование иишечки, в том числе при самообучении но расстраиваюсь на тренингах, когда вижу участников, которые просто закидывают задачу в гпт. Может в работе модельки смогут решать их задачи, но проверять, направлять и адаптировать решение уже не получится.
С другой стороны, если какие-то задачи нормально решают модельки, то однажды мы должны подняться еще на один уровень абстракции, как это было много раз? Только пока не понятно, как он будет выглядеть. В интересное время живем все же.
А с другой, адекватный манагер вполне может работать с более экспертными сотрудниками, даже должен. Тогда зачем ему нанимать людей, которые работают проксей к модельке?
Наткнулся на на чей-то рилс про образование, там была мысль: “абсолютное большинство задач в ит - типовые. Обычно ты даешь студенту задание на самостоятельный поиск шаблонного решения, чтобы в будущем он мог распознавать соотвествующие задачи и тюнить решени при необходимости”. Примерно об этом же я писал тут.
Вроде я топлю за максимальное использование иишечки, в том числе при самообучении но расстраиваюсь на тренингах, когда вижу участников, которые просто закидывают задачу в гпт. Может в работе модельки смогут решать их задачи, но проверять, направлять и адаптировать решение уже не получится.
С другой стороны, если какие-то задачи нормально решают модельки, то однажды мы должны подняться еще на один уровень абстракции, как это было много раз? Только пока не понятно, как он будет выглядеть. В интересное время живем все же.
А с другой, адекватный манагер вполне может работать с более экспертными сотрудниками, даже должен. Тогда зачем ему нанимать людей, которые работают проксей к модельке?
❤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
#интеграция #архитектура
Не пойму, что все на выборе технологий помешались?
Когда вы реально сидели на работе и думали, какую же базу выбрать: оракл, монгу, или постгрю? Берем кафку или реббит? Вебсокеты или http? Так, чтобы с полной свободой и ответственностью.
Примерно никогда?
Да потому что в живой природе этой задачи практически не существует. Реально эта задача возникает в первые дни стартапа, начале проекта или продукта. И то не всегда. Еще на больших масштабах иногда можно упереться в проблемы текущей технологии, тогда приходится думать о миграции.
Правда занимается этим CTO, архитектор, иногда техлид. В остальных случаях все сводится к выбору из пары альтернатив из техрадара компании по готовым рекомендациям. Или просто берем существующий стек, и все.
Возможно, дело в собесах:
• кандидат заучивает вопросы про выбор технологий, хотя никогда это делать не будет
• интервьюер оценивает ответы кандидата, хотя сам никогда это не делал
• оба изучали тему по статьям (не)известных людей с неизвестным опытом, либо на курсах
• авторы курсов тоже никогда ничего не выбирали, но умеют красиво пересказывать статьи (не)известных людей
Да что ты знаешь о матрице, Нео?! Виртуальное ит в вакууме.
Почему чужие чеклисты и гайды — это буллшит, писал тут. Тогда что делать?
• изучать проект, инфру, ограничения, проблемы
• погружаться в матчасть — изучать технологии не по статьям
• определять важные для вас критерии
На своих занятиях постоянно мучаю участников этим: приходится думать, рассуждать, маппить задачи на технологии и самостоятельно составлять чек-лист с критериями по выбору. Угадайте, к чем же я веду? Через неделю начинаю очередной поток по интеграции и архитектуре систем для ценителей осознанных страданий. Будет больно и весело, приходите.
Не пойму, что все на выборе технологий помешались?
Когда вы реально сидели на работе и думали, какую же базу выбрать: оракл, монгу, или постгрю? Берем кафку или реббит? Вебсокеты или http? Так, чтобы с полной свободой и ответственностью.
Примерно никогда?
Да потому что в живой природе этой задачи практически не существует. Реально эта задача возникает в первые дни стартапа, начале проекта или продукта. И то не всегда. Еще на больших масштабах иногда можно упереться в проблемы текущей технологии, тогда приходится думать о миграции.
Правда занимается этим CTO, архитектор, иногда техлид. В остальных случаях все сводится к выбору из пары альтернатив из техрадара компании по готовым рекомендациям. Или просто берем существующий стек, и все.
Возможно, дело в собесах:
• кандидат заучивает вопросы про выбор технологий, хотя никогда это делать не будет
• интервьюер оценивает ответы кандидата, хотя сам никогда это не делал
• оба изучали тему по статьям (не)известных людей с неизвестным опытом, либо на курсах
• авторы курсов тоже никогда ничего не выбирали, но умеют красиво пересказывать статьи (не)известных людей
Да что ты знаешь о матрице, Нео?! Виртуальное ит в вакууме.
Почему чужие чеклисты и гайды — это буллшит, писал тут. Тогда что делать?
• изучать проект, инфру, ограничения, проблемы
• погружаться в матчасть — изучать технологии не по статьям
• определять важные для вас критерии
На своих занятиях постоянно мучаю участников этим: приходится думать, рассуждать, маппить задачи на технологии и самостоятельно составлять чек-лист с критериями по выбору. Угадайте, к чем же я веду? Через неделю начинаю очередной поток по интеграции и архитектуре систем для ценителей осознанных страданий. Будет больно и весело, приходите.
1👍21❤5😁5💯2🆒2🔥1👏1
Ну что, телегу начинают официально валить. Все приготовили три буквы? К максу пойдете?
👎39🤮17💔13😁2👍1