Итоги стрима
Очереди не завезли, топики-партиции остаются все теми же.
Теперь для чтения топика можно создать не только обычную Consumer Group, но и Shared Group, в чем отличия:
• распределением партиций между консьюмерами занимается сама кафка
• одной партиции могут назначить сразу несколько консьюмеров, ради равномерности потребления
• пока реализован только один алгоритм балансировки, который этой равномерности не дает, но можно пилить свои
• важно: эта механика не обеспечивает порядок чтения сообщений даже в рамках одной партиции
Главная мотивация — обеспечить большую скорость обработки потока, за счет более эффективного распределения консьюмеров по партициям в случаях, когда не важен порядок сообщений. Но пока под это реализован только протокол, а не сама логика.
Лично у меня сложилось впечатление, что это штука больше для аналитики и логов, но будем посмотреть.
Ссылки и видосы будут в @nextway_news
А тут Андрей пишет про кафку, брокеры и всякие стриминги: @data_rivers
#брокеры
Очереди не завезли, топики-партиции остаются все теми же.
Теперь для чтения топика можно создать не только обычную Consumer Group, но и Shared Group, в чем отличия:
• распределением партиций между консьюмерами занимается сама кафка
• одной партиции могут назначить сразу несколько консьюмеров, ради равномерности потребления
• пока реализован только один алгоритм балансировки, который этой равномерности не дает, но можно пилить свои
• важно: эта механика не обеспечивает порядок чтения сообщений даже в рамках одной партиции
Главная мотивация — обеспечить большую скорость обработки потока, за счет более эффективного распределения консьюмеров по партициям в случаях, когда не важен порядок сообщений. Но пока под это реализован только протокол, а не сама логика.
Лично у меня сложилось впечатление, что это штука больше для аналитики и логов, но будем посмотреть.
Ссылки и видосы будут в @nextway_news
А тут Андрей пишет про кафку, брокеры и всякие стриминги: @data_rivers
#брокеры
👍13❤4👀2
Такая картинка возникает у меня после общения с людьми на конференциях и тренингах. Справедливости ради, это относится не только к аналитикам. Всех интересует примерно одно: как выбирать технологии, покажи универсальные паттерны, дай алгоритмов и чеклистов для проектирования всего.
“Чем больше паттернов, тем лучше!” — реальное высказывание участника одного из воркшопов. Штош, внесем безумия в рабочие будни.
Не нужно выбирать технологии, эта задача встречается в реальной жизни крайне редко, и решает ее пара человек в компании/юните. Куда важнее разобраться в нюансах технологии, которую вы используете в проекте-продукте-компании.
Чем больше паттернов, тем хуже. Как-то запускали продукт, где разработку лидировал разраб, который незадолго прочитал книгу о паттернах для конкретного стека. Так вот, он реализовал там ВСЕ паттерны. Зачем?
Не существует универсальных алгоритмов, чек-листов и принципов, потому что все они выводятся из контекста и опыта авторов. Если что-то “работало” у них, не значит, что будет “работать” у вас. И не факт, что будет “работать” у этих же гурей в будущем. Это еще не затрагиваем вопрос вкусовщины и личной предвзятости.
Тогда что делать?
Хорошо бы понять, чем мы все же занимаемся. Мы проектируем распределенные системы, в которых постоянно нужно решать задачи согласования состояний, обеспечение порядка, потери данных, синхронизации версий и времени. Это все скучно, абстрактно, и непонятно, как положить на практику, правда?
Только есть проблемка — без них попытки использования паттернов, технологий и прочих базвордов равносильны блужданию в темной комнате с молотком и микроскопом. Повезет — забьем гвоздь, нет — засыпем пол осколками. Еще в окно можно выйти.
И наоборот, скучные базовые концепции позволяют самостоятельно выводить паттерны в нужных ситуациях. Обратное намного сложнее.
Можно смотреть на проектирование снизу вверх, в надежде угадать нужный инструмент под задачу, суть которой не понимаешь. Либо научиться видеть задачу и находить под нее инструменты.
Вообще, пост задумывался как нативочка к обновленному курсу по интеграции и архитектуре но рефлексировать интереснее, чем продавать. Зато сформулировал для себя, зачем делаю его. Мы учимся видеть задачу, самостоятельно изобретать решения и мыслить трейд-оффами. А еще добавили блоки про хранилища данных и работу с докером-кубером-мешами, начинаем в воскресенье.
“Чем больше паттернов, тем лучше!” — реальное высказывание участника одного из воркшопов. Штош, внесем безумия в рабочие будни.
Не нужно выбирать технологии, эта задача встречается в реальной жизни крайне редко, и решает ее пара человек в компании/юните. Куда важнее разобраться в нюансах технологии, которую вы используете в проекте-продукте-компании.
Чем больше паттернов, тем хуже. Как-то запускали продукт, где разработку лидировал разраб, который незадолго прочитал книгу о паттернах для конкретного стека. Так вот, он реализовал там ВСЕ паттерны. Зачем?
Не существует универсальных алгоритмов, чек-листов и принципов, потому что все они выводятся из контекста и опыта авторов. Если что-то “работало” у них, не значит, что будет “работать” у вас. И не факт, что будет “работать” у этих же гурей в будущем. Это еще не затрагиваем вопрос вкусовщины и личной предвзятости.
Тогда что делать?
Хорошо бы понять, чем мы все же занимаемся. Мы проектируем распределенные системы, в которых постоянно нужно решать задачи согласования состояний, обеспечение порядка, потери данных, синхронизации версий и времени. Это все скучно, абстрактно, и непонятно, как положить на практику, правда?
Только есть проблемка — без них попытки использования паттернов, технологий и прочих базвордов равносильны блужданию в темной комнате с молотком и микроскопом. Повезет — забьем гвоздь, нет — засыпем пол осколками. Еще в окно можно выйти.
И наоборот, скучные базовые концепции позволяют самостоятельно выводить паттерны в нужных ситуациях. Обратное намного сложнее.
Можно смотреть на проектирование снизу вверх, в надежде угадать нужный инструмент под задачу, суть которой не понимаешь. Либо научиться видеть задачу и находить под нее инструменты.
Вообще, пост задумывался как нативочка к обновленному курсу по интеграции и архитектуре но рефлексировать интереснее, чем продавать. Зато сформулировал для себя, зачем делаю его. Мы учимся видеть задачу, самостоятельно изобретать решения и мыслить трейд-оффами. А еще добавили блоки про хранилища данных и работу с докером-кубером-мешами, начинаем в воскресенье.
👍25💯10❤7
Балансировка трафика
Вчера на AD делал воркшоп по основам балансировки, который из-за технических проблем превратился в ит-стендап. Но будто под вечер такое аудитории даже лучше зашло.
Выкладываю ссылки, которые обещал.
Введение в проблему с наглядной визуализацией
Более серьезное погружение в алгоритмы и архитектуру балансировки
Простой пример про балансировку веб-трафика, который приходит из голых интернетов
Хардкорный разбор работы HTTP/2
Разбор работы TLS: раз, два
#интеграция
Вчера на AD делал воркшоп по основам балансировки, который из-за технических проблем превратился в ит-стендап. Но будто под вечер такое аудитории даже лучше зашло.
Выкладываю ссылки, которые обещал.
Введение в проблему с наглядной визуализацией
Более серьезное погружение в алгоритмы и архитектуру балансировки
Простой пример про балансировку веб-трафика, который приходит из голых интернетов
Хардкорный разбор работы HTTP/2
Разбор работы TLS: раз, два
#интеграция
Хабр
Алгоритмы балансировки нагрузок
Рано или поздно веб-приложения перерастают среду одного сервера. Компаниям требуется увеличить или их доступность, или масштабируемость, или и то, и другое. Чтобы сделать это, они развёртывают своё...
🔥14❤4
#архитектура #хранилища
Вы могли заметить, что каждую неделю (почти) мы проводим что-то интересное техническое в NextWay Еще вы могли заметить, что записи мы выкладываем долго и лениво. Поэтому лучше приходить вживую.
Завтра, например, мы будем обсуждать графовые хранилища — это как ГрафКЛ, только ГрафБД. Тема особенно актуальная в контексте агентов и RAGов.
Кто пропустит, я не виноват. Придется ждать записей, они будут в ютубе. Когда-нибудь.
Вы могли заметить, что каждую неделю (почти) мы проводим что-то интересное техническое в NextWay Еще вы могли заметить, что записи мы выкладываем долго и лениво. Поэтому лучше приходить вживую.
Завтра, например, мы будем обсуждать графовые хранилища — это как ГрафКЛ, только ГрафБД. Тема особенно актуальная в контексте агентов и RAGов.
Кто пропустит, я не виноват. Придется ждать записей, они будут в ютубе. Когда-нибудь.
nextway.timepad.ru
Графовые базы данных: зачем и как использовать / События на TimePad.ru
Приглашаем на глубокий практический разбор графовых баз данных — технологии, которая кардинально меняет подход к работе со связанными данными. Мы не только расскажем теорию, но и покажем на реальных примерах, как графы решают задачи, практически нерешаемые…
😁4👍2
Люблю токсичные каналы, хотя градуса замеса пока не хватает. Но все же
1
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🔥14❤7💯5🤔3😁1
#продуктовое #манагерское
В уходящем году подрабатывал селебой.
Сначала меня позвал на стрим Невзоров. Говорили о жизни, карьере, переходе в продакты, и почему все тлен. Активно призывал думать о целях и желаниях, прежде чем ломиться в хайповые профессии.
Запись в канале Владимира — System Design World, там вообще много полезного.
Потом с Наташей Семеновой обсуждали переход из аналитика в продакты, уже более точечно. Рассказывал о темной стороне продуктовой жизни, и всячески источал скепсис и негилизм.
Запись в канале Smart Effect — там интересное про публичность, выступления и поиск себя до, после и около IT.
Главные тезисы про переходы в продакта, если лень смотреть:
— Профессия безумно романтизирована, во многих компаниях вы будете делать то, что решили топы, но отвечать за результат будете вы
— Ответственности больше, денег меньше, жизнь хуже
— Технарям должны проще даваться переходы в b2dev, b2b, платформенные продукты
— Если все равно невыносимо хочется в продукт, старайтесь делать переход внутри компании
В уходящем году подрабатывал селебой.
Сначала меня позвал на стрим Невзоров. Говорили о жизни, карьере, переходе в продакты, и почему все тлен. Активно призывал думать о целях и желаниях, прежде чем ломиться в хайповые профессии.
Запись в канале Владимира — System Design World, там вообще много полезного.
Потом с Наташей Семеновой обсуждали переход из аналитика в продакты, уже более точечно. Рассказывал о темной стороне продуктовой жизни, и всячески источал скепсис и негилизм.
Запись в канале Smart Effect — там интересное про публичность, выступления и поиск себя до, после и около IT.
Главные тезисы про переходы в продакта, если лень смотреть:
— Профессия безумно романтизирована, во многих компаниях вы будете делать то, что решили топы, но отвечать за результат будете вы
— Ответственности больше, денег меньше, жизнь хуже
— Технарям должны проще даваться переходы в b2dev, b2b, платформенные продукты
— Если все равно невыносимо хочется в продукт, старайтесь делать переход внутри компании
👍12🔥4💯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💯31😐6❤3🤔2👍1🔥1🥱1🤨1😭1
#оффтоп
Искренне восхищаюсь, как люди изобретают высокие смыслы для бизнеса. Интересно, как табачки миссии формулируют?
Искренне восхищаюсь, как люди изобретают высокие смыслы для бизнеса. Интересно, как табачки миссии формулируют?
Компания: ХХХ - ведущий импортер, дистрибьютор и ритейлер алкогольной продукции
Наша миссия - повышать качество жизни людей через развитие винной культуры, и мы ищем человека, который будет работать над продуктом с тем же азартом и любовью к вину, что и мы.
😁20👍7🫡1
#манагерское
Бизнес vs Разработка
Ожидаемо после таких вбросов начинают сыпаться комменты:
И подобное. Простите, но…
Никакого Бизнеса не существует. Разработки тоже. Как и Требований, об этом уже писал.
Зато существует компания, в которой работают сотрудники, у которой есть руководство. Поразительно, но у всех этих людей есть свои цели. Но это неважно.
Важно, что руководство (должно) строит систему, в которой работа сотрудников приближает компанию к ее целям (обычно это деньги). И если в рамках системы возникают дихотомии вида: Бизнес vs Разработка, Продукт vs Финансы, Пиар vs Юристы — это фиаско. Как и любое противопоставление “вот есть мы, вот есть (тупые) они”.
Причем внутри итшечки это понимание существует. Сейчас почти повсеместным стандартом считаются кросс-функциональные команды, в которых собраны все необходимые роли. Необходимые для создания проекта/платформы/продукта. Отцы аджайлов настаивали, что в команды нужно затаскивать и бизнес экспертов. Интересно, почему?
Но, если вернутся на 15 лет назад и посмотреть на устройство ит в РФ, то вместо модных автономных команд увидим отделы / службы / функции разработки, анализа, тестирования, которые перекидываются задачами и регулярно ненавидят друг друга. Интересно, почему?
Получается, компании часто устроены по принципу тех же функциональных колодцев, от которых в свое время уходила итшечка, ибо это неэффективно. Интересно, почему?
Наверное потому, что вокруг одни идиоты?
Или потому, что многим это выгодно?
Зачем совместно искать решение проблем, пути достижения целей, если всегда можно заявить, что криворукая “разработка” опять сделала не то и сорвала все сроки, а тупой “бизнес” сам не понимает, чего хочет? Если прикрываться достаточным количеством переписок, встреч, нытья, можно бесконечно избегать ответственности за результат. В крайнем случае компанию сменим.
И выгодно это как хедам-лидам, так и линейным сотрудникам. Поэтому после серьезных факапов начинаются зарубы Бизнес vs Разработка, хотя в этот момент тимлид и продакт должны взяться за руки и вежливо выйти в окно.
Поэтому неважно, куда хочет инвестировать разработчик, как мычит заказчик, и о чем говорят мужчины. Важно, какое поведение возможно и выгодно в рамках существующей системы.
Хз, зачем вам эта портянка, может уснуть поможет
Бизнес vs Разработка
Ожидаемо после таких вбросов начинают сыпаться комменты:
Бизнес и разработка не понимают друг друга - это база, причем любой бизнес и любая разработка. Большинство заказчиков могут ТЗ записать только голосовым сообщением на 8 минут, из которых половина - мычание, а разрабы в душе не чают, какие проблемы бизнес пытается решить.
Разрабы поняли давно, что повышение дохода возможно только через смену работодателя. средний срок на одно месте 1-3 года. Глупо инвестировать в погружение в бизнес-проблематику, а вы всё про какой-то общий язык - ну что за фантазии!
И подобное. Простите, но…
Никакого Бизнеса не существует. Разработки тоже. Как и Требований, об этом уже писал.
Зато существует компания, в которой работают сотрудники, у которой есть руководство. Поразительно, но у всех этих людей есть свои цели. Но это неважно.
Важно, что руководство (должно) строит систему, в которой работа сотрудников приближает компанию к ее целям (обычно это деньги). И если в рамках системы возникают дихотомии вида: Бизнес vs Разработка, Продукт vs Финансы, Пиар vs Юристы — это фиаско. Как и любое противопоставление “вот есть мы, вот есть (тупые) они”.
Причем внутри итшечки это понимание существует. Сейчас почти повсеместным стандартом считаются кросс-функциональные команды, в которых собраны все необходимые роли. Необходимые для создания проекта/платформы/продукта. Отцы аджайлов настаивали, что в команды нужно затаскивать и бизнес экспертов. Интересно, почему?
Но, если вернутся на 15 лет назад и посмотреть на устройство ит в РФ, то вместо модных автономных команд увидим отделы / службы / функции разработки, анализа, тестирования, которые перекидываются задачами и регулярно ненавидят друг друга. Интересно, почему?
Получается, компании часто устроены по принципу тех же функциональных колодцев, от которых в свое время уходила итшечка, ибо это неэффективно. Интересно, почему?
Наверное потому, что вокруг одни идиоты?
Или потому, что многим это выгодно?
Зачем совместно искать решение проблем, пути достижения целей, если всегда можно заявить, что криворукая “разработка” опять сделала не то и сорвала все сроки, а тупой “бизнес” сам не понимает, чего хочет? Если прикрываться достаточным количеством переписок, встреч, нытья, можно бесконечно избегать ответственности за результат. В крайнем случае компанию сменим.
И выгодно это как хедам-лидам, так и линейным сотрудникам. Поэтому после серьезных факапов начинаются зарубы Бизнес vs Разработка, хотя в этот момент тимлид и продакт должны взяться за руки и вежливо выйти в окно.
Поэтому неважно, куда хочет инвестировать разработчик, как мычит заказчик, и о чем говорят мужчины. Важно, какое поведение возможно и выгодно в рамках существующей системы.
👏30👍10😁4❤2👎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