Как архитектору остаться hands-on?
Архитектору, который уже не умеет писать код, очень легкоскатиться по наклонной перестать чувствовать землю и начать создавать решения, работающие в вакууме.
Рапунцель-архитектор в башне про это.
И что же делать, если работа архитектора обычно не про написание кода?
Я делаю следующее:
– раньше грыз алгоритмы на HackerRank и даже золотую медальку получил, но сейчас перестал
– пишу фитнес функции для своих архитектур
– пишу прототипы, чтобы проверить гипотезы и снизить риски у самых важных decisions в solution (у решений в решении для строгих любителей русского 🤣)
– стартаплю свои продукты и пишу прочую автоматику, упрощающую мне жизнь
– делаю грязную работу на проектах, куда разрабы не успевают дотянуться (например тех долг могу помочь разгрести). При этом в важные и срочные задачи разрабов не лезу, говнокодить не хочется.
А вы как остаетесь hands-on?
Архитектору, который уже не умеет писать код, очень легко
Рапунцель-архитектор в башне про это.
И что же делать, если работа архитектора обычно не про написание кода?
Я делаю следующее:
– раньше грыз алгоритмы на HackerRank и даже золотую медальку получил, но сейчас перестал
– пишу фитнес функции для своих архитектур
– пишу прототипы, чтобы проверить гипотезы и снизить риски у самых важных decisions в solution (у решений в решении для строгих любителей русского 🤣)
– стартаплю свои продукты и пишу прочую автоматику, упрощающую мне жизнь
– делаю грязную работу на проектах, куда разрабы не успевают дотянуться (например тех долг могу помочь разгрести). При этом в важные и срочные задачи разрабов не лезу, говнокодить не хочется.
А вы как остаетесь hands-on?
👍12❤1
HH закрывает API для соискателей.
HRы получили много власти в вопросах найма. Подключили автофильтры, натюнили их под свои забавные критерии.
Инженеры нашли способ переломить ситуацию и вернуть прежний баланс сил.
С отключением API баланс снова смещается в сторону HRов.
Корень проблемы – сложности с поиском сигнала среди шума – этим не исправляются.
Очевидна попытка снизить количество откликов на вакансии, но их оставляют не фантомные а настоящие люди, даже если они используют автоматику. Поэтому порядок откликов не изменится.
Может быть на позициях с низким порогом входа будет заметно резкое снижение откликов (вместо 1000 будет 200), но глобально HRам это не поможет.
Промышленные инструменты автоматизации с закрытием API перейдут на веб скрапинг и успешно справятся с этим (или будут веб API HH использовать).
Для HH бороться с этим будет очень дорого и сложно и врядли они будут этим заниматься.
Посмотрим что нас ждет на HH в следующем году, но кажется, что HH теряет свою аудиторию.
После 15 декабря мой бот должен перестать работать. Посмотрю на ситуацию с HH и буду думать что дальше с ним делать
HRы получили много власти в вопросах найма. Подключили автофильтры, натюнили их под свои забавные критерии.
Инженеры нашли способ переломить ситуацию и вернуть прежний баланс сил.
С отключением API баланс снова смещается в сторону HRов.
Корень проблемы – сложности с поиском сигнала среди шума – этим не исправляются.
Очевидна попытка снизить количество откликов на вакансии, но их оставляют не фантомные а настоящие люди, даже если они используют автоматику. Поэтому порядок откликов не изменится.
Может быть на позициях с низким порогом входа будет заметно резкое снижение откликов (вместо 1000 будет 200), но глобально HRам это не поможет.
Промышленные инструменты автоматизации с закрытием API перейдут на веб скрапинг и успешно справятся с этим (или будут веб API HH использовать).
Для HH бороться с этим будет очень дорого и сложно и врядли они будут этим заниматься.
Посмотрим что нас ждет на HH в следующем году, но кажется, что HH теряет свою аудиторию.
После 15 декабря мой бот должен перестать работать. Посмотрю на ситуацию с HH и буду думать что дальше с ним делать
🔥12❤1👍1
Регулярная подборка статей вокруг архитектуры
🔹 Web rendering techniques
🔹 Budget Calculator for web performance
Takes performance expectations as input and produces Lighthouse CI configuration to be enforced as output.
🔹 Extract requirements using AI (in Russian)
An attempt to automate requirements extraction using AI
🔹 What's possible when you choose proper DB type for load
Mintlify tried to use PostgreSQL for analytical load that it wasn't designed for - architectural mistake. They moved to analytical DB (ClickHouse) and enabled new features.
🔹 Manual to grow audience on LinkedIn
Actual for social networking or blogging too
🔹 CLI tool to wait for a port or a service to enter the requested state
🔹 Web rendering techniques
🔹 Budget Calculator for web performance
Takes performance expectations as input and produces Lighthouse CI configuration to be enforced as output.
🔹 Extract requirements using AI (in Russian)
An attempt to automate requirements extraction using AI
🔹 What's possible when you choose proper DB type for load
Mintlify tried to use PostgreSQL for analytical load that it wasn't designed for - architectural mistake. They moved to analytical DB (ClickHouse) and enabled new features.
🔹 Manual to grow audience on LinkedIn
Actual for social networking or blogging too
🔹 CLI tool to wait for a port or a service to enter the requested state
👍5❤2🔥1
Что дает наибольшие улучшения в производительности системы?
Anonymous Poll
77%
Архитектурные решения
23%
Оптимизации кода
❤1
Что важнее – архитектура или код?
Дураций вопрос, конечно надо брать все вместе и побольше 🤣
Архитектура формирует фундамент решения. Код формирует его детали.
С плохим каркасом дом рухнет, с кривыми окнами и неработающей канализацией дом не рухнет, но жить в нем будет тяжко 😅
А сможем ли мы исправить ошибки в архитектуре и коде?
Исправить архитектурные ошибки очень дорого. Выбрали неудачно БД или способ деплоя (он премис, клауд), через пол года после перехода на это решение откат назад требует огромного количества ресурсов (времени, денег, компетенций). Поэтому часто с архитектурными ошибками живут долго, они обрастают травой и становятся особенностью системы.
Исправить ошибки в коде относительно просто – либо пофиксить in place, либо переписать.
Кажется странно. А почему так?
Архитектор решает важные технические проблемы. Эти решения не на квартал а на годы. Иногда некоторые части системы требуют частой глобальной модификации, но тут архитектор использует эволюционные подходы и покрывает это.
На уровне кода очень высокая динамика – бизнес постоянно хочет новые фичи, код это напрямую отражает каждый день.
Пока Дед Мороз готовит вам подарки, я готовлю для вас мега пост про то, как OpenAI создала кластер из кластеров Kafka и какие творит с ним чудеса 🎄
Дураций вопрос, конечно надо брать все вместе и побольше 🤣
Архитектура формирует фундамент решения. Код формирует его детали.
С плохим каркасом дом рухнет, с кривыми окнами и неработающей канализацией дом не рухнет, но жить в нем будет тяжко 😅
А сможем ли мы исправить ошибки в архитектуре и коде?
Исправить архитектурные ошибки очень дорого. Выбрали неудачно БД или способ деплоя (он премис, клауд), через пол года после перехода на это решение откат назад требует огромного количества ресурсов (времени, денег, компетенций). Поэтому часто с архитектурными ошибками живут долго, они обрастают травой и становятся особенностью системы.
Исправить ошибки в коде относительно просто – либо пофиксить in place, либо переписать.
Кажется странно. А почему так?
Архитектор решает важные технические проблемы. Эти решения не на квартал а на годы. Иногда некоторые части системы требуют частой глобальной модификации, но тут архитектор использует эволюционные подходы и покрывает это.
На уровне кода очень высокая динамика – бизнес постоянно хочет новые фичи, код это напрямую отражает каждый день.
Пока Дед Мороз готовит вам подарки, я готовлю для вас мега пост про то, как OpenAI создала кластер из кластеров Kafka и какие творит с ним чудеса 🎄
👍7❤3🔥3
Я устал, я ухожу решил пойти с автоматизацией в найме дальше.
Как часто вы отвечаете на вопросы
– Какие ваши зарплатные ожидания? Началась угадайка вилки компании 🤣
– Какой ваш статус в поиске?
– Почему ушли из компании Х?
–Почему у вас нос красный? Что ищете в новой компании?
– Расскажите про примеры проектов, вашу роль в них, какие архитектурные решения принимали?
Я что-то прям очень часто и надоело. Появилась мысль создать своего двойника для ответа на такие вопросы.
Телеграм бот, который использует AI для ответов на эти вопросы. AI берет только мои данные (без фантазий) из RAG.
Мои данные – это не только статический текст, может быть и видео и диаграммы.
Как думаете, HRы и нанимающие менеджеры согласятся сэкономить время обоих сторон и использовать такого двойника?
Хотели бы получить своего такого двойника?
В деле участвует AI, который дорогой, и поэтому бесплатной раздачи как с ботом, автоматизирующим отклики, не получится.
К слову бот продолжает работать, HH хоть и пугал, но свои намерения пока не реализовал.
Как часто вы отвечаете на вопросы
– Какие ваши зарплатные ожидания? Началась угадайка вилки компании 🤣
– Какой ваш статус в поиске?
– Почему ушли из компании Х?
–
– Расскажите про примеры проектов, вашу роль в них, какие архитектурные решения принимали?
Я что-то прям очень часто и надоело. Появилась мысль создать своего двойника для ответа на такие вопросы.
Телеграм бот, который использует AI для ответов на эти вопросы. AI берет только мои данные (без фантазий) из RAG.
Мои данные – это не только статический текст, может быть и видео и диаграммы.
Как думаете, HRы и нанимающие менеджеры согласятся сэкономить время обоих сторон и использовать такого двойника?
Хотели бы получить своего такого двойника?
В деле участвует AI, который дорогой, и поэтому бесплатной раздачи как с ботом, автоматизирующим отклики, не получится.
🔥9
Kafka в OpenAI.
Было:
– Центральный канал для дата пайплайнов и транзакционной нагрузки
– 37 кластеров с различными конфигурациями под разные нужды
– Каждый кластер – единая точка отказа в случае аутеджа
– Сложность подключения нового сервиса. В каком кластере нужный топик? Как получить сетевой доступ к нужному кластеру? Какие креды для него?
– Кластеры перегружены большим количеством соединений
Цель – отделить (decoupling) консьюмеров и продюсеров от кластеров Kafka.
Решение:
– Балансировщик для продьюсеров (прокси Prism).
– Балансировщик для консьюмеров (uForwarder от Uber).
– Кластеры Kafka объединяются в группы. Все кластеры в группе содержат одни и те же Kafka топики (каждый топик принадлежит одной группе кластеров).
– Создан Control Plane для управления кластером кластеров Kafka.
➕ Более эффективное масштабирование
➕ Повышенная надежность
➕ Значительное упрощение разработки и поддержки продюсеров и консьюмеров
➕ Свобода менять инфраструктуру Kafka без зависимостей на пользователей
➖ Проблемы с partitioning
➖ Нет сохранения порядка событий
➖ Нет exactly-once обработки событий
Каждый минус можно порешать на уровне обходных решений за пределами их Kafka платформы.
Стало:
– 6 груп кластеров
– zero downtime миграция на новое решение
– 99.999% доступность у новой платформы Kafka.
– Kafka больше не единая точка отказа. Инфраструктура испытывала аутедж целых регинов с нулевым эффектом на продьюсеров и минимальным эффектом на консьюмеров
– за время миграции использование Kafka внутри OpenAI выросло в 10 раз, пропускная способность выросла в 20 раз.
Графики и технические детали доступны на Boosty.
Было:
– Центральный канал для дата пайплайнов и транзакционной нагрузки
– 37 кластеров с различными конфигурациями под разные нужды
– Каждый кластер – единая точка отказа в случае аутеджа
– Сложность подключения нового сервиса. В каком кластере нужный топик? Как получить сетевой доступ к нужному кластеру? Какие креды для него?
– Кластеры перегружены большим количеством соединений
Цель – отделить (decoupling) консьюмеров и продюсеров от кластеров Kafka.
Решение:
– Балансировщик для продьюсеров (прокси Prism).
– Балансировщик для консьюмеров (uForwarder от Uber).
– Кластеры Kafka объединяются в группы. Все кластеры в группе содержат одни и те же Kafka топики (каждый топик принадлежит одной группе кластеров).
– Создан Control Plane для управления кластером кластеров Kafka.
Каждый минус можно порешать на уровне обходных решений за пределами их Kafka платформы.
Стало:
– 6 груп кластеров
– zero downtime миграция на новое решение
– 99.999% доступность у новой платформы Kafka.
– Kafka больше не единая точка отказа. Инфраструктура испытывала аутедж целых регинов с нулевым эффектом на продьюсеров и минимальным эффектом на консьюмеров
– за время миграции использование Kafka внутри OpenAI выросло в 10 раз, пропускная способность выросла в 20 раз.
Графики и технические детали доступны на Boosty.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
Регулярная подборка статей вокруг архитектуры
🔹Juniors become productive faster with AI
Kent Beck explains how AI lets companies reduce non-productive time for juniors that eventually leads to smaller learning curve to produce more seniors
🔹Fundamental guidance for product management and startups
Paul Graham explains what is really important for building great products
🔹Tips to use AI for code review
🔹Great example of release notes for performance improvements
🔹ClickHouse approach to move from C++ to Rust
Very systematic, pragmatic and declarative way to express migration process
🔹How Supabase scaled its internal DBs to cope with increased load
It's not a traditional separation of transactional and analytical load, it's a combination of both.
🔹Optimizing bandwidth in Chrome and Websockets
An interesting story how the company reconsidered all accepted standards and approaches to save $1 million a year
🔹Google explains challenges to achieve near 100% accuracy in text-to-SQL mapping
🔹Juniors become productive faster with AI
Kent Beck explains how AI lets companies reduce non-productive time for juniors that eventually leads to smaller learning curve to produce more seniors
🔹Fundamental guidance for product management and startups
Paul Graham explains what is really important for building great products
🔹Tips to use AI for code review
🔹Great example of release notes for performance improvements
🔹ClickHouse approach to move from C++ to Rust
Very systematic, pragmatic and declarative way to express migration process
🔹How Supabase scaled its internal DBs to cope with increased load
It's not a traditional separation of transactional and analytical load, it's a combination of both.
🔹Optimizing bandwidth in Chrome and Websockets
An interesting story how the company reconsidered all accepted standards and approaches to save $1 million a year
🔹Google explains challenges to achieve near 100% accuracy in text-to-SQL mapping
👍8
AI и умение думать.
В ноябре 2022 года я сильно приуныл. ChatGPT вышел в публичный релиз. Он писал плохонький код, но уже было понятно, что он быстро научиться делать это лучше.
Что ждет меня лично в будущем?
Я много экспериментировал с AI с тех пор и пришел к выводу, что AI не может принимать архитектурные решения – самое важное в работе архитектора.
AI не отвечает за свои решения, поэтому может генерить бесконечное количество решений.
Меня это обрадовало – самое важное и самое интересное в моей работе остается за человеком.
Но на днях случилось нечто, что меня снова опечалило.
Я посмотрел матч по доте между OpenAI и командой OG в 2017 году, OG были лучшими в мире в доте в те времена.
Боты OpenAI тотально доминировали над человеком в очень сложной игре с большой динамикой. Это как будто Майкл Джордан играет с детьми из садика в баскетбол.
Получается, что AI очень даже умеет принимать эффективные решения. Но почему тогда 8 лет спустя AI так плох в этом?
Я изучил как OpenAI тренировало своих ботов и стало еще печальнее.
Generative AI способен не только думать, но и принимать эффективные решения. Просто его нужно тренировать на узко специализированных кейсах для этого.
Текущие модели AI тренируются на общих кейсах, поэтому в узко специализированных они думают плохо.
Получается, что исчезновение человека в архитектуре – это просто вопрос времени и интереса AI вендоров этим заняться.
Что будем с этим делать, человеки?
В ноябре 2022 года я сильно приуныл. ChatGPT вышел в публичный релиз. Он писал плохонький код, но уже было понятно, что он быстро научиться делать это лучше.
Что ждет меня лично в будущем?
Я много экспериментировал с AI с тех пор и пришел к выводу, что AI не может принимать архитектурные решения – самое важное в работе архитектора.
AI не отвечает за свои решения, поэтому может генерить бесконечное количество решений.
Меня это обрадовало – самое важное и самое интересное в моей работе остается за человеком.
Но на днях случилось нечто, что меня снова опечалило.
Я посмотрел матч по доте между OpenAI и командой OG в 2017 году, OG были лучшими в мире в доте в те времена.
Боты OpenAI тотально доминировали над человеком в очень сложной игре с большой динамикой. Это как будто Майкл Джордан играет с детьми из садика в баскетбол.
Получается, что AI очень даже умеет принимать эффективные решения. Но почему тогда 8 лет спустя AI так плох в этом?
Я изучил как OpenAI тренировало своих ботов и стало еще печальнее.
Generative AI способен не только думать, но и принимать эффективные решения. Просто его нужно тренировать на узко специализированных кейсах для этого.
Текущие модели AI тренируются на общих кейсах, поэтому в узко специализированных они думают плохо.
Получается, что исчезновение человека в архитектуре – это просто вопрос времени и интереса AI вендоров этим заняться.
Что будем с этим делать, человеки?
1😢9🤪2🤔1
Немного веселья для баланса.
В РФ появился православный LinkedIn от HH под названием Сетка. Летом это было полуживое создание, но сейчас оно наполнилось людьми.
Сетка мне не нравится тем, что как и его исходник LinkedIn он сам решает кому показывать ваш контент. То есть автор не контролирует аудиторию.
Можно подумать, что это источник новых подписчиков, но аудитория там на любителя. Хотя классные ребята тоже попадаются.
Так а где же веселье?
Сетка выдает мне очень забавный контент. На 99.99% это филосовские высказывания Стетхема от HRов 🤣
Для любителей окунуться в трешачок Дома 2 и шоу Окна (есть в живых кто это помнит?) Сетка – это Дом 3 из HRов.
Вроде бы хочется пожелать ребятам удачи и захват рынка, но как же мне нравится их Дом 3 и не хочется чтобы это менялось😅
Где и когда еще столько HRов соберешь и заставишь их транслировать попытки познания мира.
Кстати я в Сетке здесь. HH автоматом посты из этого канала туда транслирует.
В РФ появился православный LinkedIn от HH под названием Сетка. Летом это было полуживое создание, но сейчас оно наполнилось людьми.
Сетка мне не нравится тем, что как и его исходник LinkedIn он сам решает кому показывать ваш контент. То есть автор не контролирует аудиторию.
Можно подумать, что это источник новых подписчиков, но аудитория там на любителя. Хотя классные ребята тоже попадаются.
Так а где же веселье?
Сетка выдает мне очень забавный контент. На 99.99% это филосовские высказывания Стетхема от HRов 🤣
Для любителей окунуться в трешачок Дома 2 и шоу Окна (есть в живых кто это помнит?) Сетка – это Дом 3 из HRов.
Вроде бы хочется пожелать ребятам удачи и захват рынка, но как же мне нравится их Дом 3 и не хочется чтобы это менялось😅
Где и когда еще столько HRов соберешь и заставишь их транслировать попытки познания мира.
Кстати я в Сетке здесь. HH автоматом посты из этого канала туда транслирует.
50🔥3
Новогоднего нам позитива.
Управляющие директора и CEO Salesforce жалеют, что уволили 4000 человек (c 9000 человек сократились до 5000 человек) ради замены их на AI.
– акции упали на 34%
– клиенты жалуются на значительное ухудшение качества продукта
Google начал возвращать, уволенных ранее из-за AI оптимизаций сотрудников. 20% нанятых инженеров в 2025 году - уволенные ранее сотрудники.
Я скромно тоже добавил в топку керосина. Отключил подписку на Иви, хотя был их клиентом много лет.
Была маленькая проблема, но Иви заменил всех людей на ИИ и в чате, и по телефону, и на почте – причем на абсолютно тупой ИИ.
Я послал их в попу, после долгих мучений пробить роботов.
Буду надеятся остальные извлекут уроки из чужих ошибок 🙂
Управляющие директора и CEO Salesforce жалеют, что уволили 4000 человек (c 9000 человек сократились до 5000 человек) ради замены их на AI.
– акции упали на 34%
– клиенты жалуются на значительное ухудшение качества продукта
Google начал возвращать, уволенных ранее из-за AI оптимизаций сотрудников. 20% нанятых инженеров в 2025 году - уволенные ранее сотрудники.
Я скромно тоже добавил в топку керосина. Отключил подписку на Иви, хотя был их клиентом много лет.
Была маленькая проблема, но Иви заменил всех людей на ИИ и в чате, и по телефону, и на почте – причем на абсолютно тупой ИИ.
Я послал их в попу, после долгих мучений пробить роботов.
Буду надеятся остальные извлекут уроки из чужих ошибок 🙂
🔥17👏4
Систематизация менторства.
Я провел десятки менторских сессий для русско и англо язычных аудиторий.
Бесплатное менторство плохо масштабируется и убивает качество. Я систематизировал подход и свел оплату через Boosty. В итоге меньше некачественных запросов и больше реальной пользы.
⚡Бесплатные карьерные сессии среди русскоязычной аудитории имели запросы низкого качества.
Менторские сессии по карьере были бесплатные изначально, но среди русскоязычной аудитории на такие сессии приходило очень много людей, которым было проще спросить меня, чем пользоваться гуглом. Было много запросов вида "я всю жизнь варила борщ, как мне вкатиться в IT и зашибать много денег".
Как лучше мотивировать человека пользоваться гуглом и уважать твое время? Я решил, что рублем 💡
Поэтому на русскоязычной платформе я выставил символическую цену за сессию по карьере в 1000 рублей. Все некачественные лиды сразу отпали.
⚡Бесплатное решение рабочих задач некорректно
Бывают запросы, где люди просят помочь с реальными проблемами в их работе. Компании просят помочь со стратегией развития.
Люди получают зарплату за это, компании зарабатывают на этом деньги, выглядит некорректно бесплатно делать работу, которая приносит людям деньги в моменте.
На англоязычной платформе карьерные сессии остались бесплатными, потому что некачественных лидов там было 0.
Но там существовала другая проблема – отсутствие поддержки оплаты в принципе. Запросы на менторство приходят из ЕС, Азии, Африки, США – везде свои нюансы с оплатой.
Поэтому я решил систематизировать подход на обеих платформах и свести оплату всех сессий через Boosty, который поддерживает оплату со всего мира без ограничений.
🎁 У этого подхода появился приятный side effect – для всех моих подписчиков на Boosty доступны бесплатные менторские сессии со мной.
Я провел десятки менторских сессий для русско и англо язычных аудиторий.
Бесплатное менторство плохо масштабируется и убивает качество. Я систематизировал подход и свел оплату через Boosty. В итоге меньше некачественных запросов и больше реальной пользы.
⚡Бесплатные карьерные сессии среди русскоязычной аудитории имели запросы низкого качества.
Менторские сессии по карьере были бесплатные изначально, но среди русскоязычной аудитории на такие сессии приходило очень много людей, которым было проще спросить меня, чем пользоваться гуглом. Было много запросов вида "я всю жизнь варила борщ, как мне вкатиться в IT и зашибать много денег".
Как лучше мотивировать человека пользоваться гуглом и уважать твое время? Я решил, что рублем 💡
Поэтому на русскоязычной платформе я выставил символическую цену за сессию по карьере в 1000 рублей. Все некачественные лиды сразу отпали.
⚡Бесплатное решение рабочих задач некорректно
Бывают запросы, где люди просят помочь с реальными проблемами в их работе. Компании просят помочь со стратегией развития.
Люди получают зарплату за это, компании зарабатывают на этом деньги, выглядит некорректно бесплатно делать работу, которая приносит людям деньги в моменте.
На англоязычной платформе карьерные сессии остались бесплатными, потому что некачественных лидов там было 0.
Но там существовала другая проблема – отсутствие поддержки оплаты в принципе. Запросы на менторство приходят из ЕС, Азии, Африки, США – везде свои нюансы с оплатой.
Поэтому я решил систематизировать подход на обеих платформах и свести оплату всех сессий через Boosty, который поддерживает оплату со всего мира без ограничений.
🎁 У этого подхода появился приятный side effect – для всех моих подписчиков на Boosty доступны бесплатные менторские сессии со мной.
1👍7✍2
Мой цифровой двойник.
Недавно я писал, что устал обсуждать одно и тоже и решил заменить себя двойником, чтобы
– сэкономить время обоим сторонам
– дать возможность HRам и нанимающим менеджерам в моменте получать всю необходимую им информацию обо мне и не ждать интервью
Обсудил со знакомыми и классными HRами идею – им показалось штука полезной.
Мой двойник готов @hiring_twin_bot
Стек: TypeScript, Serverless и ChatGTP
Сделал за полтора часа. Получилось быстро, потому что 100500 раз делал это и для моих личных нужд не нужно большого оверхеда.
Хотите получить своего цифрового двойника?
Бесплатно не получится (стек недешевый) – но не больше чашки кофе будет стоить в месяц.
Недавно я писал, что устал обсуждать одно и тоже и решил заменить себя двойником, чтобы
– сэкономить время обоим сторонам
– дать возможность HRам и нанимающим менеджерам в моменте получать всю необходимую им информацию обо мне и не ждать интервью
Обсудил со знакомыми и классными HRами идею – им показалось штука полезной.
Мой двойник готов @hiring_twin_bot
Стек: TypeScript, Serverless и ChatGTP
Сделал за полтора часа. Получилось быстро, потому что 100500 раз делал это и для моих личных нужд не нужно большого оверхеда.
Хотите получить своего цифрового двойника?
Бесплатно не получится (стек недешевый) – но не больше чашки кофе будет стоить в месяц.
Telegram
Архитектура с Лаптевым
Я устал, я ухожу решил пойти с автоматизацией в найме дальше.
Как часто вы отвечаете на вопросы
– Какие ваши зарплатные ожидания? Началась угадайка вилки компании 🤣
– Какой ваш статус в поиске?
– Почему ушли из компании Х?
– Почему у вас нос красный? Что…
Как часто вы отвечаете на вопросы
– Какие ваши зарплатные ожидания? Началась угадайка вилки компании 🤣
– Какой ваш статус в поиске?
– Почему ушли из компании Х?
– Почему у вас нос красный? Что…
🔥9
Поздравляю с Новым Годом 🎄
Спасибо за активную вовлеченность в работу канала
– 1095 сообщений отправляли друг другу.
– 1433 реакций оставили на наши сообщения.
Именно активная вовлеченность максимизирует пользу для всех участников.
Наиболее активным участникам в этом году я подарил подписку на Telegram Premium🎁
– @beskov - 54 комментария
– @Base_sa - 33 комментария
Желаю вам успехов и удачи в новом году!
Спасибо за активную вовлеченность в работу канала
– 1095 сообщений отправляли друг другу.
– 1433 реакций оставили на наши сообщения.
Именно активная вовлеченность максимизирует пользу для всех участников.
Наиболее активным участникам в этом году я подарил подписку на Telegram Premium
– @beskov - 54 комментария
– @Base_sa - 33 комментария
Желаю вам успехов и удачи в новом году!
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉19❤9
Будущее продуктов 2.0
Я писал ранее про роль AI в существовании SaaS продуктов. Тогда мне казалось, что будущее у SaaS продуктов остается, хоть и самописные аналоги с AI их мотивируют снижать цену.
Не все готовы распылять ресурсы на то, что не является ядром их бизнеса.
Сегодня один энтузиаст сообщил, что за 2.5 часа создал клон TypeForm (генерация опросников) с помощью Opus 4.5 AI модели. И не просто создал, а сделал исходники open source.
Почему я снова поднял эту тему?
Потому что в случае с TypeForm клиентам не так важна долгосрочная поддержка и развитие продукта. Это простые опросники, которые и через 10 лет будут такими же опросниками.
Немного скучной теории🤓
В развитии продуктов есть такое понятие как stickiness. На сколько клейким является ваш продукт для клиентов.
Stickiness бывает бизнесовая (например, имеет мало смысла уходить от продукта, когда вся компания сидит на всей линейке, привет Microsoft 365 пакет) и техническая (например, когда продукт запрещает миграцию данных из него).
Когда stickiness низкий, очень легко потерять клиента. Поэтому продуктовые вендоры stickiness стараются повысить.
У TypeForm stickiness близка к нулю. Их пользователи платят им деньги за то, чтобы самим не изобретать скучные опросники – это комодити, причем мало важное.
Хм, теперь мы можем создать аналог TypeForm за 2 часа, но нам все равно нужно поддерживать инфраструктуру и это затратно. Или не затратно?
Опросники обычно необходимы несколько дней. Для этого глобально никакой NFR не важен. Очень сильно нужно постараться, чтобы запустить сервис и сломать его сразу.
Компании с нулевой stickiness и простым решением, где нет NFR (ну ладно, где нет архитектурно важных NFR), абсолютно беззащитны перед современными AI моделями.
Как думаете, как на это отреагируют компании, чьи продукты стали максимально уязвимы перед AI?
TypeForm стало оберткой вокруг ChatGPT 😜
Они флагманской фичей рекламируют генерацию опросников через промпты. Внешний AI генерит нам опросник, TypeForm его деплоит во внешний дата центр.
Зачем в этой схеме платить $29 TypeForm?
Я писал ранее про роль AI в существовании SaaS продуктов. Тогда мне казалось, что будущее у SaaS продуктов остается, хоть и самописные аналоги с AI их мотивируют снижать цену.
Не все готовы распылять ресурсы на то, что не является ядром их бизнеса.
Сегодня один энтузиаст сообщил, что за 2.5 часа создал клон TypeForm (генерация опросников) с помощью Opus 4.5 AI модели. И не просто создал, а сделал исходники open source.
Почему я снова поднял эту тему?
Потому что в случае с TypeForm клиентам не так важна долгосрочная поддержка и развитие продукта. Это простые опросники, которые и через 10 лет будут такими же опросниками.
Немного скучной теории
В развитии продуктов есть такое понятие как stickiness. На сколько клейким является ваш продукт для клиентов.
Stickiness бывает бизнесовая (например, имеет мало смысла уходить от продукта, когда вся компания сидит на всей линейке, привет Microsoft 365 пакет) и техническая (например, когда продукт запрещает миграцию данных из него).
Когда stickiness низкий, очень легко потерять клиента. Поэтому продуктовые вендоры stickiness стараются повысить.
У TypeForm stickiness близка к нулю. Их пользователи платят им деньги за то, чтобы самим не изобретать скучные опросники – это комодити, причем мало важное.
Хм, теперь мы можем создать аналог TypeForm за 2 часа, но нам все равно нужно поддерживать инфраструктуру и это затратно. Или не затратно?
Опросники обычно необходимы несколько дней. Для этого глобально никакой NFR не важен. Очень сильно нужно постараться, чтобы запустить сервис и сломать его сразу.
Компании с нулевой stickiness и простым решением, где нет NFR (ну ладно, где нет архитектурно важных NFR), абсолютно беззащитны перед современными AI моделями.
Как думаете, как на это отреагируют компании, чьи продукты стали максимально уязвимы перед AI?
TypeForm стало оберткой вокруг ChatGPT 😜
Они флагманской фичей рекламируют генерацию опросников через промпты. Внешний AI генерит нам опросник, TypeForm его деплоит во внешний дата центр.
Зачем в этой схеме платить $29 TypeForm?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🔥2🥴1
Как мигрировать монолит в микросервисы?
Просыпается бабка со скамейки у подъезда 👵🏻
Этот вопрос вызывает у менярвотный рефлекс печаль уже больше 10 лет.
Мейнстрим сперва уверовал в микросервисы (лучше их нет на свете), затем уверовал в модульный монолит (мы не хипстеры, мы знаем как надо по феншую).
При этом реальность на земле за 10 лет не изменилась ни на дюйм.
Да, железо и совт стали комодити. Появилась культура DevOps.
Это дало людям свободу от SOA архитектур, сформированных вокруг проприетарного совта и дорогого железа. Мы получили возможность формировать модули вокруг бизнес логики.
Что люди сделали с этой свободой?
Ушли от SOA – большие молодцы. Рубль – отличный мотиватор.
Но ушли не в микросервисы а в зоопарк франкенштейнов, пусть и называют это микросервисами.
Архитектура современных систем распределенная. Да, все просто – она распределенная.
Она состоит из кучи паттернов, совмещенных вместе. Там и микросервисы, и micro kernel, и event based, и гексагональная, и много еще какая.
И это хорошо. Gang of Four учила нас 30 лет назад, что нужно быть прагматичными с паттернами.
Возвращаюсь от брюзжания к топику 😜
На самом деле вопрос стоит по другому – как мигрировать монолит в распределенную архитектуру?
Глобально существует 2 подхода.
1️⃣ Business first
Часто мы решаемся уйти в распределенную архитектуру, чтобы получить более эффективное горизонтальное масштабирование. По другим причинам тоже, но я возьму эту для объяснения, с остальными тоже самое актуально.
Это важно для наиболее критичного для бизнеса функционала. Логично мигрировать сперва самое важное для бизнеса, а потом менее важное (до миграции менее важного можно и не дойти и это тоже нормально).
Но тут возникает одна проблема – самое важное для бизнеса часто является самым популярным функционалом, от которого многое зависит.
Уже визуализировали боль? При миграции компонента, от которого зависит много других компонентов, мы имеем много подвижных частей, каждая из которых может сломаться в процессе.
2️⃣ Dependency first
Мы формируем карту зависимостей у каждого компонента. Затем мигрируем компоненты с наименьшим количеством зависимых компонентов.
Визуализировали? С каждой итерацией мы уменьшаем количество зависимых компонентов и на последней итерации компонент, от которого зависела куча компонентов, уже имеет минимум зависимых.
Выглядит как серебряная пуля. Почему же мы всегда не идем от зависимостей?
Потому что сложно объяснить бизнесу, зачем мы занимаемся миграцией самого важного функционала для бизнеса в последнюю очередь 😁
Мы уже знаем, что в архитектуре не бывает эффективного решения на все случаи жизни. Поэтому для каждой миграции мы жонглируем обоими подходами а иногда/редко даже используем оба подхода одновременно.
В каком-то смысле это вопрос управления рисками и сопутствующими затратами.
Просыпается бабка со скамейки у подъезда 👵🏻
Этот вопрос вызывает у меня
Мейнстрим сперва уверовал в микросервисы (лучше их нет на свете), затем уверовал в модульный монолит (мы не хипстеры, мы знаем как надо по феншую).
При этом реальность на земле за 10 лет не изменилась ни на дюйм.
Да, железо и совт стали комодити. Появилась культура DevOps.
Это дало людям свободу от SOA архитектур, сформированных вокруг проприетарного совта и дорогого железа. Мы получили возможность формировать модули вокруг бизнес логики.
Что люди сделали с этой свободой?
Ушли от SOA – большие молодцы. Рубль – отличный мотиватор.
Но ушли не в микросервисы а в зоопарк франкенштейнов, пусть и называют это микросервисами.
Архитектура современных систем распределенная. Да, все просто – она распределенная.
Она состоит из кучи паттернов, совмещенных вместе. Там и микросервисы, и micro kernel, и event based, и гексагональная, и много еще какая.
И это хорошо. Gang of Four учила нас 30 лет назад, что нужно быть прагматичными с паттернами.
Возвращаюсь от брюзжания к топику 😜
На самом деле вопрос стоит по другому – как мигрировать монолит в распределенную архитектуру?
Глобально существует 2 подхода.
Часто мы решаемся уйти в распределенную архитектуру, чтобы получить более эффективное горизонтальное масштабирование. По другим причинам тоже, но я возьму эту для объяснения, с остальными тоже самое актуально.
Это важно для наиболее критичного для бизнеса функционала. Логично мигрировать сперва самое важное для бизнеса, а потом менее важное (до миграции менее важного можно и не дойти и это тоже нормально).
Но тут возникает одна проблема – самое важное для бизнеса часто является самым популярным функционалом, от которого многое зависит.
Уже визуализировали боль? При миграции компонента, от которого зависит много других компонентов, мы имеем много подвижных частей, каждая из которых может сломаться в процессе.
Мы формируем карту зависимостей у каждого компонента. Затем мигрируем компоненты с наименьшим количеством зависимых компонентов.
Визуализировали? С каждой итерацией мы уменьшаем количество зависимых компонентов и на последней итерации компонент, от которого зависела куча компонентов, уже имеет минимум зависимых.
Выглядит как серебряная пуля. Почему же мы всегда не идем от зависимостей?
Потому что сложно объяснить бизнесу, зачем мы занимаемся миграцией самого важного функционала для бизнеса в последнюю очередь 😁
Мы уже знаем, что в архитектуре не бывает эффективного решения на все случаи жизни. Поэтому для каждой миграции мы жонглируем обоими подходами а иногда/редко даже используем оба подхода одновременно.
В каком-то смысле это вопрос управления рисками и сопутствующими затратами.
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥12
Гуманизм в разработке совта.
Один из работников сервиса по доставке еды поделился пугающей реальностью.
1. Приоритетная доставка – фейк.
Заказы без приоритета намеренно задерживаются на 5–10 минут, чтобы приоритетные казались быстрее на контрасте.
2. Используется скрытый "индекс отчаяния" курьеров.
Система вычисляет, насколько курьер нуждается в деньгах, анализируя его поведение (часто берет невыгодные заказы), и перестает давать им выгодные заказы.
3. Чаевые идут не курьеру напрямую а компании.
Если система видит, что клиент постоянно оставляет чаевые, то уменьшает оплату курьера по заказу на размер этих чаевых
4. "Driver Benefit Fee" и "Regulatory Response Fee" идут не курьерам.
Они идут на зарплату юристам, которые судятся с профсоюзами курьеров. То есть клиент платит, чтобы сделать жизнь курьеров тяжелее.
Никогда не думал об этом, но похоже гуманизм – одно из ключевых внутренних требований, которые я применяю в своих решениях, даже не задумываясь.
Есть еще одно внутреннее требование – integrity, но про него я как раз задумываюсь часто.
А какие у вас ключевые внутренние требования к решениям?
Один из работников сервиса по доставке еды поделился пугающей реальностью.
1. Приоритетная доставка – фейк.
Заказы без приоритета намеренно задерживаются на 5–10 минут, чтобы приоритетные казались быстрее на контрасте.
2. Используется скрытый "индекс отчаяния" курьеров.
Система вычисляет, насколько курьер нуждается в деньгах, анализируя его поведение (часто берет невыгодные заказы), и перестает давать им выгодные заказы.
3. Чаевые идут не курьеру напрямую а компании.
Если система видит, что клиент постоянно оставляет чаевые, то уменьшает оплату курьера по заказу на размер этих чаевых
4. "Driver Benefit Fee" и "Regulatory Response Fee" идут не курьерам.
Они идут на зарплату юристам, которые судятся с профсоюзами курьеров. То есть клиент платит, чтобы сделать жизнь курьеров тяжелее.
Никогда не думал об этом, но похоже гуманизм – одно из ключевых внутренних требований, которые я применяю в своих решениях, даже не задумываясь.
Есть еще одно внутреннее требование – integrity, но про него я как раз задумываюсь часто.
А какие у вас ключевые внутренние требования к решениям?
👍13🔥2🤔2😭1
Архив всех статей.
Удобная навигация по контенту – проблема, которая давно меня беспокоила.
Современные платформы (включая Telegram) заточены под скроллинг новостей (прочитал и забыл). Навигация и поиск в них – либо не существуют, либо очень неудобны.
Я решил хранить все архитектурные статьи здесь. Поддерживается
– полнотекстовый поиск
– email рассылка по новым статьям
– RSS подписка
– нативный для статей интерфейс
Как вам архив?
Удобная навигация по контенту – проблема, которая давно меня беспокоила.
Современные платформы (включая Telegram) заточены под скроллинг новостей (прочитал и забыл). Навигация и поиск в них – либо не существуют, либо очень неудобны.
Я решил хранить все архитектурные статьи здесь. Поддерживается
– полнотекстовый поиск
– email рассылка по новым статьям
– RSS подписка
– нативный для статей интерфейс
Как вам архив?
blog.theone.archi
Software Architecture | Nick | Substack
This hub is about unique aspects of software architecture that are hard to find or simply not covered in other sources. If well known topics come up, they are always discussed with a strong focus on pragmatism and real world experience. Click to read Software…
1🔥6👍3❤1
Архитектура с Лаптевым pinned «Архив всех статей. Удобная навигация по контенту – проблема, которая давно меня беспокоила. Современные платформы (включая Telegram) заточены под скроллинг новостей (прочитал и забыл). Навигация и поиск в них – либо не существуют, либо очень неудобны. Я…»
Я тут немного приутих. Вынуждено устроить пришлось цифровой детокс.
Моя маленькая принцесса батю ледянками в нокаут отправила 🤣
Врач просил глаз от девайсов поберечь.
Скоро вернусь.
А как у вас проходят праздники?
Моя маленькая принцесса батю ледянками в нокаут отправила 🤣
Врач просил глаз от девайсов поберечь.
Скоро вернусь.
А как у вас проходят праздники?
😁14😱3🙏2