System Design от Чжиюн Таня
или как выжить на интервью, не превратившись в кусок тревожного желе
Если вы дочитали Алекса Сюя и такие:
«Ну всё, теперь я точно архитектор Google»,
а потом вам на интервью говорят:
«А теперь спроектируй систему, где миллионы юзеров одновременно жмут лайк на видео» —
и вы снова: «Эээ... ну… может, кэш?»,
то держите вторую дозу системного просвещения — книга Чжиюн Таня "System Design: How to Survive the Interview".
1.
Книга больше говорит о базе и по ощущениям рассчитана на программистов, все-таки.
2.
Мне перевод понравился чуть меньше. Мне не так важно, но знаю, что есть очень чувствительные к этому люди.
3.
Крутые кейсы (включая те, что редко встречаются):
- Push Notification Service
- API Rate Limiter
- Design a Web Crawler
- Система для бронирования билетов (да-да, как в авиакомпаниях)
- И даже… система аутентификации
В кейсах, опять таки, больше деталей.
4.
Перед самими кейсами больше базы алгоритмической
5.
Фреймворк систем-дизайна, который он продвигает:
- Clarify Requirements: разбираем юзкейсы и ограничения
- Define API and Data Flow: как данные гуляют по системе
- Back-of-the-envelope calculations: нагрузки, размеры, TPS
- High-level architecture: компоненты и их взаимодействие
- Bottlenecks and scaling: что сломается и как починить
- Trade-offs discussion: чем пожертвовали ради чего
6.
Мне больше понравился Алекс Сю, так как, по ощущениям, книга больше рассчитана на менеджеров, а это то, что нужно мне)
🔥 — Если уже прочитал и зашло
❤️ — В список must-read
💅 — Если не зашло
@badtechproject
или как выжить на интервью, не превратившись в кусок тревожного желе
Если вы дочитали Алекса Сюя и такие:
«Ну всё, теперь я точно архитектор Google»,
а потом вам на интервью говорят:
«А теперь спроектируй систему, где миллионы юзеров одновременно жмут лайк на видео» —
и вы снова: «Эээ... ну… может, кэш?»,
то держите вторую дозу системного просвещения — книга Чжиюн Таня "System Design: How to Survive the Interview".
1.
Книга больше говорит о базе и по ощущениям рассчитана на программистов, все-таки.
2.
Мне перевод понравился чуть меньше. Мне не так важно, но знаю, что есть очень чувствительные к этому люди.
3.
Крутые кейсы (включая те, что редко встречаются):
- Push Notification Service
- API Rate Limiter
- Design a Web Crawler
- Система для бронирования билетов (да-да, как в авиакомпаниях)
- И даже… система аутентификации
В кейсах, опять таки, больше деталей.
4.
Перед самими кейсами больше базы алгоритмической
5.
Фреймворк систем-дизайна, который он продвигает:
- Clarify Requirements: разбираем юзкейсы и ограничения
- Define API and Data Flow: как данные гуляют по системе
- Back-of-the-envelope calculations: нагрузки, размеры, TPS
- High-level architecture: компоненты и их взаимодействие
- Bottlenecks and scaling: что сломается и как починить
- Trade-offs discussion: чем пожертвовали ради чего
6.
Мне больше понравился Алекс Сю, так как, по ощущениям, книга больше рассчитана на менеджеров, а это то, что нужно мне)
🔥 — Если уже прочитал и зашло
❤️ — В список must-read
💅 — Если не зашло
@badtechproject
❤59👍7💅4🔥3
Forwarded from Хороший Project_Артем Арюткин
Тут писали подкаст с Андреем Смирновым и он почитав канал и посмотрев другие подкасты (Антон, оказывается, интервьюеры готовятся, а не как мы😁) спросил про планы на фитнес направление. Таких планов нет, да и совмещение профессиональной деятельности с таким более сомнительным - плохая затея.
Но вот один эксперимент сделать можно публичным.
Буду делиться его результатами раз в 2-4 недели.
Короче, последнее время в тренировках наблюдаю замедление прогресса.
Топ
понятных причин:
1.
Подтягивания с 25 кг доп веса нифига непросто. И переход с 8 повторений на 9 занимает 2 недели. С 18-20 кг было проще.
2.
Понятно, что есть недостаток сна. Чудес не бывает с маленькими детьми и работающими родителями.
3.
Тренировки только дома. Кроме плавания, конечно же 😁
4.
Снижение калорийности ниже 1900-2100 явно уже перебор.
Ну и видно, что после марта текущий подход более не дает результата.
Что нужно сделать?
Правильно, пересобрать питание и тренировки.
Заюзаем чатГПТ:
1.
Закинул ему свои фотки и попросил дать оценку.
Помним, что качество ответов растет, если просить ГПТ задавать вам вопросы.
2.
Отвечаем на его вопросы и описываем ситуацию:
- какое оборудование есть
- какие текущие результаты
- что с питанием и прочее.
3.
На выходе получаем программу тренировок и рекомендации по питанию (можно даже попросить его составить конкретный рацион).
Итог:
1.
ЧатГПТ составил программу тренировок и питания на 12 недель.
2.
Предложил нарастить хорошенько каллораж, добавив углеводов.
Но вот один эксперимент сделать можно публичным.
Буду делиться его результатами раз в 2-4 недели.
Короче, последнее время в тренировках наблюдаю замедление прогресса.
Топ
понятных причин:
1.
Подтягивания с 25 кг доп веса нифига непросто. И переход с 8 повторений на 9 занимает 2 недели. С 18-20 кг было проще.
2.
Понятно, что есть недостаток сна. Чудес не бывает с маленькими детьми и работающими родителями.
3.
Тренировки только дома. Кроме плавания, конечно же 😁
4.
Снижение калорийности ниже 1900-2100 явно уже перебор.
Ну и видно, что после марта текущий подход более не дает результата.
Что нужно сделать?
Правильно, пересобрать питание и тренировки.
Заюзаем чатГПТ:
1.
Закинул ему свои фотки и попросил дать оценку.
Помним, что качество ответов растет, если просить ГПТ задавать вам вопросы.
2.
Отвечаем на его вопросы и описываем ситуацию:
- какое оборудование есть
- какие текущие результаты
- что с питанием и прочее.
3.
На выходе получаем программу тренировок и рекомендации по питанию (можно даже попросить его составить конкретный рацион).
Итог:
1.
ЧатГПТ составил программу тренировок и питания на 12 недель.
2.
Предложил нарастить хорошенько каллораж, добавив углеводов.
🔥17👍11❤3✍2👌1
Блин, вы видели погоду???
Сегодня уже три 1:1 на улице провел за прогулкой!
Ну просто кайф же!
Гоу все на улицу!
@badtechproject
Сегодня уже три 1:1 на улице провел за прогулкой!
Ну просто кайф же!
Гоу все на улицу!
@badtechproject
❤28🔥20❤🔥8😁6👍4🤡2🌭1
Парадокс Симпсона — статистика, которая вас обманет, даже если вы против
Вы все наверняка помните, что есть ложь, наглая ложь и статистика.
Только я думаю, что еще есть парадокс Симпса - лучший способ обмануть себя и всех вокруг, используя статистику.
Парадокс Симпсона — это тот случай, когда ты уверен в своих данных, строишь графики, делаешь выводы... и всё неправильно.
Простой пример, чтобы охренеть:
Допустим, ты хочешь понять, какой врач лучше — доктор «А» или доктор «B» (глянь картинку в начале).
В каждой из групп доктор «A» лучше:
В легких случаях: 90% против 95% (почти одинаково)
В тяжелых: 10% против 10% (равно).
И че?
Кто по вашему лучший?
Не поглядывай!
Оказывается, гребаный доктор «B » - невероятно крут!
Как так?
Если объединить данные:
Доктор «A »: 100 из 200 = 50%
Доктор «B »: 20 из 30 = 66%
В чем подвох?
Скрытая переменная — распределение по сложности случаев. «B» работал почти только с лёгкими пациентами, а «A» тащил и тяжёлых.
Так что если не учитывать эту переменную — можно сделать прямо противоположный вывод.
Где такое встречается?
- HR: Средняя зарплата мужчин выше, но оказывается, что женщины чаще в низкооплачиваемых департаментах.
- Образование: Один вуз "хуже" по среднему баллу студентов, но если разбить по факультетам — он оказывается лучше в каждом.
- Медицина: Лекарство кажется бесполезным в общем, но помогает в каждой возрастной группе.
- Продуктовая аналитика: Фича "ухудшила" метрику, но только потому что ей пользовались в основном новички.
Что с этим делать?
- Разбивайте данные: Ищите зависимость от скрытых признаков.
- Не верьте агрегатам: Среднее — зло без контекста.
- Стройте дашборды с фильтрами: Пусть можно было посмотреть и в целом, и по сегментам.
- Ищите "речку в пустыне": Если глобально тренд один, а в каждой подгруппе — другой, это тревожный звонок.
Финалочка:
Парадокс Симпсона — напоминание, что данные без контекста могут врать. Или точнее: вы будете врать себе, глядя на данные, если не копнете глубже.
А ты знал, про парадокс раньше?
👍 - пффф, конечно
♥️ - спасибо, бро, что рассказал
🔥 - я сам себе ходячий парадокс!
P.S. И доктор «В» крут, потому что умеет правильно выбрать еще и пациентов, которых он будет вести.
@badtechproject
Вы все наверняка помните, что есть ложь, наглая ложь и статистика.
Только я думаю, что еще есть парадокс Симпса - лучший способ обмануть себя и всех вокруг, используя статистику.
Парадокс Симпсона — это тот случай, когда ты уверен в своих данных, строишь графики, делаешь выводы... и всё неправильно.
Простой пример, чтобы охренеть:
Допустим, ты хочешь понять, какой врач лучше — доктор «А» или доктор «B» (глянь картинку в начале).
В каждой из групп доктор «A» лучше:
В легких случаях: 90% против 95% (почти одинаково)
В тяжелых: 10% против 10% (равно).
И че?
Кто по вашему лучший?
Не поглядывай!
Если объединить данные:
Доктор
Доктор
В чем подвох?
Скрытая переменная — распределение по сложности случаев. «B» работал почти только с лёгкими пациентами, а «A» тащил и тяжёлых.
Так что если не учитывать эту переменную — можно сделать прямо противоположный вывод.
Где такое встречается?
- HR: Средняя зарплата мужчин выше, но оказывается, что женщины чаще в низкооплачиваемых департаментах.
- Образование: Один вуз "хуже" по среднему баллу студентов, но если разбить по факультетам — он оказывается лучше в каждом.
- Медицина: Лекарство кажется бесполезным в общем, но помогает в каждой возрастной группе.
- Продуктовая аналитика: Фича "ухудшила" метрику, но только потому что ей пользовались в основном новички.
Что с этим делать?
- Разбивайте данные: Ищите зависимость от скрытых признаков.
- Не верьте агрегатам: Среднее — зло без контекста.
- Стройте дашборды с фильтрами: Пусть можно было посмотреть и в целом, и по сегментам.
- Ищите "речку в пустыне": Если глобально тренд один, а в каждой подгруппе — другой, это тревожный звонок.
Финалочка:
Парадокс Симпсона — напоминание, что данные без контекста могут врать. Или точнее: вы будете врать себе, глядя на данные, если не копнете глубже.
А ты знал, про парадокс раньше?
👍 - пффф, конечно
♥️ - спасибо, бро, что рассказал
🔥 - я сам себе ходячий парадокс!
P.S. И доктор «В» крут, потому что умеет правильно выбрать еще и пациентов, которых он будет вести.
@badtechproject
❤151🔥43👍30👎3💯2
Давайте поможем Сереже. Искать работу дело хлопотное, особенно, если ты после курсов SkillBox😁
Серега был там директором по продукту)
P.S. Серег, я не удержался…
Серега был там директором по продукту)
P.S. Серег, я не удержался…
😁58❤4
Forwarded from ··• Серёжа печатает (Серёжа)
Не искал работу почти 8 лет. Наслушался от коллег по цеху, как легко и удобно это сейчас делать, поэтому я решил не ждать 2–3 месяца брожения, чтобы написать пост на линке!
Я начинаю искать новые проекты и вызовы для работы или, простым языком, ищу работу.
Последние 2,5 года я занимался управлением продуктом и продуктовой командой в Skillbox. Разбирали, внедряли, собирали, пересобирали. Растили метрики, внедряли новые методики и масштабировали на новые продукты, собирали эффективную структуру управления продуктом.
Несмотря на мой богатый прикладной опыт в компаниях, связанных с образованием, многое, что мы делали, можно использовать где угодно, и я в своём поиске не ограничиваю себя продуктами, связанными с образованием.
Я умею всё, что связано с:
Людьми: нанимать, управлять, строить эффективные структуры, оптимизировать, выстраивать связи между, работать с мотивацией. В том числе растить лидеров, в том числе из самых начинающих ребят. В том числе работать с процессами — искать узкие места, находить решения, внедрять изменения, цифровизировать процесс. Организовывать работу команды по разным подходам.
Продуктом: запускать, внедрять и работать с метриками, проводить кастдевы, решенческие интервью, работать с гипотезами, внедрять продуктовый процесс, делать MVP, пивоты и вот это всё. В том числе управлять командой продукта и командой продактов, синхронизировать ожидания со стейкхолдерами.
Стратегией: делать стратегии(продуктовые, командные, бизнесовые), декомпозировать стратегию до конкретных шагов, контролировать реализацию, лидировать достижение результатов.
Проектами: запускать отдельные проекты, собирать под него людей, планировать таймлайн и нагрузку, вести проекты(в том числе невыполнимые), укладываться в сроки, вести коммуникацию.
Публичной деятельностью и техническим пиаром: выступать, готовить к выступлениям и мотивировать это делать, выстраивать сообщества, организовывать офлайн и онлайн мероприятия.
И я готов дальше заниматься тем же, при этом чем-то более выраженным. Есть рекомендации)
Буду рад рекомендации, репостам и так далее. Ну конечно же ссылку на линк — https://www.linkedin.com/in/sergeypopov-56958875/
Я начинаю искать новые проекты и вызовы для работы или, простым языком, ищу работу.
Последние 2,5 года я занимался управлением продуктом и продуктовой командой в Skillbox. Разбирали, внедряли, собирали, пересобирали. Растили метрики, внедряли новые методики и масштабировали на новые продукты, собирали эффективную структуру управления продуктом.
Несмотря на мой богатый прикладной опыт в компаниях, связанных с образованием, многое, что мы делали, можно использовать где угодно, и я в своём поиске не ограничиваю себя продуктами, связанными с образованием.
Я умею всё, что связано с:
Людьми: нанимать, управлять, строить эффективные структуры, оптимизировать, выстраивать связи между, работать с мотивацией. В том числе растить лидеров, в том числе из самых начинающих ребят. В том числе работать с процессами — искать узкие места, находить решения, внедрять изменения, цифровизировать процесс. Организовывать работу команды по разным подходам.
Продуктом: запускать, внедрять и работать с метриками, проводить кастдевы, решенческие интервью, работать с гипотезами, внедрять продуктовый процесс, делать MVP, пивоты и вот это всё. В том числе управлять командой продукта и командой продактов, синхронизировать ожидания со стейкхолдерами.
Стратегией: делать стратегии(продуктовые, командные, бизнесовые), декомпозировать стратегию до конкретных шагов, контролировать реализацию, лидировать достижение результатов.
Проектами: запускать отдельные проекты, собирать под него людей, планировать таймлайн и нагрузку, вести проекты(в том числе невыполнимые), укладываться в сроки, вести коммуникацию.
Публичной деятельностью и техническим пиаром: выступать, готовить к выступлениям и мотивировать это делать, выстраивать сообщества, организовывать офлайн и онлайн мероприятия.
И я готов дальше заниматься тем же, при этом чем-то более выраженным. Есть рекомендации)
Буду рад рекомендации, репостам и так далее. Ну конечно же ссылку на линк — https://www.linkedin.com/in/sergeypopov-56958875/
❤24👍17🔥10👌2
“Платформа всё сделает за вас”- обещание, которое никто не сдержал
«Наша внутренняя платформа автоматизирует всё. Разработчик должен просто писать код и не думать ни о чём» - такой манифест написал какой-то РМ в конфлюенс еще в 2020 году и даже презентацию приложил с защиты…
Когда-то это звучало как прогресс.
Инженеры радовались: “наконец-то не надо писать Jenkins-файл”, “можно не париться с логированием”, “просто пиши сервис, остальное магия платформы”.
Но прошло время… и всё стало совсем не так весело.
1.
Новый монолит с лицом YAML'а
Ты не пишешь пайплайн — ты пишешь YAML.
Но YAML странный. Он не валидируется. У него 400 строк. И если ты ошибся с отступом — деплой ушёл в «отпуск» вместе с ответственным за платформу.
Все твои действия теперь обёрнуты в слои абстракций:
- Платформа делает деплой, но непонятно как.
- Платформа ставит алерты, но ты не знаешь, где они.
- Платформа следит за логами, но логи — это логи платформы, а не твои.
Ты уже не разработчик.
Ты шаман, который вызывает духов из CI/CD контура, обновляя pipeline.yaml и гадая по логам: где ты ошибся, о смертный.
2.
Контрибьютить в платформу? Только через обряд посвящения
Ты находишь баг. Например: пайплайн отваливается, если имя ветки начинается с hotfix/.
Ты пытаешься починить.
Но репозиторий платформы закрыт.
Там другой язык. Другая документация. Другие люди.
Чтобы внести изменение - надо собрать три комитета, написать оффер, пройти code-review у совета древних и подписать кровью SLA.
Поэтому ты ничего не правишь.
Ты просто запоминаешь: не называй ветку hotfix/.
3.
Баги, которые не баги (а просто фича не задумывалась).
Ты хочешь, чтобы сервис стартовал с другой версией базы. Или чтобы пайплайн не катился при изменении только .md.
Ты пишешь в канал поддержки.
Тебе отвечают:
“Так не предусмотрено в платформе.”
И ты вдруг понимаешь:
Ты не просто пользователь. Ты подданный.
А платформа — не инструмент. Это феодальная система. Где фичи — милость сверху.
4.
Когда документация — это GPT-галлюцинация
Документация есть. Но не про твою версию.
Ты читаешь и понимаешь:
- половина функций не работает, как описано.
- Вторая половина не описана вовсе.
Ты спрашиваешь в чате.
Тебе скидывают другой чат.
Потом ещё один.
И вот ты уже в секте "платформенного знания", где бывалые инженеры передают друг другу ansible-файлы как реликвии.
5.
И всё-таки, зачем она вообще?
На бумаге всё круто.
Платформа стандартизирует. Упрощает. Ускоряет.
На деле:
Всё, что выходит за "золотой путь" - боль.
У людей нет контекста, как работает магия.
А когда всё-таки случается инцидент - никто не знает, где копать.
Итог?
Внутренняя платформа — это не silver bullet. Это просто новый вид легаси, только с модным логотипом.
Она экономит время… до тех пор, пока ты идёшь по её дорожке.
Шаг влево- и ты уже маг-отступник, в бою с обёртками, которых никто не контролирует.
А есть ли мораль?
Не строй платформу, если не готов её поддерживать как продукт. А лучше - не ври, что она “всё сделает за тебя”.
А вот тут можно поделиться своим опытом🤪
@badtechproject
Я тут готовлю доклад на TechLeadConf о том, как возникают и развиваются платформы в разных компаниях.
И созрел вот такой пост.
«Наша внутренняя платформа автоматизирует всё. Разработчик должен просто писать код и не думать ни о чём» - такой манифест написал какой-то РМ в конфлюенс еще в 2020 году и даже презентацию приложил с защиты…
Когда-то это звучало как прогресс.
Инженеры радовались: “наконец-то не надо писать Jenkins-файл”, “можно не париться с логированием”, “просто пиши сервис, остальное магия платформы”.
Но прошло время… и всё стало совсем не так весело.
1.
Новый монолит с лицом YAML'а
Ты не пишешь пайплайн — ты пишешь YAML.
Но YAML странный. Он не валидируется. У него 400 строк. И если ты ошибся с отступом — деплой ушёл в «отпуск» вместе с ответственным за платформу.
Все твои действия теперь обёрнуты в слои абстракций:
- Платформа делает деплой, но непонятно как.
- Платформа ставит алерты, но ты не знаешь, где они.
- Платформа следит за логами, но логи — это логи платформы, а не твои.
Ты уже не разработчик.
Ты шаман, который вызывает духов из CI/CD контура, обновляя pipeline.yaml и гадая по логам: где ты ошибся, о смертный.
2.
Контрибьютить в платформу? Только через обряд посвящения
Ты находишь баг. Например: пайплайн отваливается, если имя ветки начинается с hotfix/.
Ты пытаешься починить.
Но репозиторий платформы закрыт.
Там другой язык. Другая документация. Другие люди.
Чтобы внести изменение - надо собрать три комитета, написать оффер, пройти code-review у совета древних и подписать кровью SLA.
Поэтому ты ничего не правишь.
Ты просто запоминаешь: не называй ветку hotfix/.
3.
Баги, которые не баги (а просто фича не задумывалась).
Ты хочешь, чтобы сервис стартовал с другой версией базы. Или чтобы пайплайн не катился при изменении только .md.
Ты пишешь в канал поддержки.
Тебе отвечают:
“Так не предусмотрено в платформе.”
И ты вдруг понимаешь:
Ты не просто пользователь. Ты подданный.
А платформа — не инструмент. Это феодальная система. Где фичи — милость сверху.
4.
Когда документация — это GPT-галлюцинация
Документация есть. Но не про твою версию.
Ты читаешь и понимаешь:
- половина функций не работает, как описано.
- Вторая половина не описана вовсе.
Ты спрашиваешь в чате.
Тебе скидывают другой чат.
Потом ещё один.
И вот ты уже в секте "платформенного знания", где бывалые инженеры передают друг другу ansible-файлы как реликвии.
5.
И всё-таки, зачем она вообще?
На бумаге всё круто.
Платформа стандартизирует. Упрощает. Ускоряет.
На деле:
Всё, что выходит за "золотой путь" - боль.
У людей нет контекста, как работает магия.
А когда всё-таки случается инцидент - никто не знает, где копать.
Итог?
Внутренняя платформа — это не silver bullet. Это просто новый вид легаси, только с модным логотипом.
Она экономит время… до тех пор, пока ты идёшь по её дорожке.
Шаг влево- и ты уже маг-отступник, в бою с обёртками, которых никто не контролирует.
А есть ли мораль?
Не строй платформу, если не готов её поддерживать как продукт. А лучше - не ври, что она “всё сделает за тебя”.
А вот тут можно поделиться своим опытом🤪
@badtechproject
3🔥37👍17❤7😭4🤡2👎1🤣1🖕1🤪1💊1
Примеры ИИшки в бизнесе от Гугла
Пхах, я не удержался 😁
Короче, основная проблема ИИ - завышенные ожидания и не понимание куда этот ваш ИИ всунуть-то.
«Всовывать» предлагаю туда, куда подскажет вдохновение, а вдохновение призываю искать в подобных гайдах, в том числе .
👉🏼Пока не начали читать результаты других, напомню, что мы с вами собираем свои кейсы по ссылке.
🚗 Mercedes-Benz: Голосовой помощник MBUX
Внедрение генеративного ИИ в систему MBUX позволило обеспечить более естественное и интуитивное взаимодействие с автомобилем, улучшая пользовательский опыт. (Mercedes-Benz USA Media)
🚘 General Motors (OnStar): Виртуальный помощник
Виртуальный помощник OnStar, использующий ИИ, обрабатывает более 1 миллиона запросов клиентов в месяц в США и Канаде, разгружая операторов для более сложных задач. (GM Investor)
🍕 Papa John's: Оптимизация заказов с ИИ
Сотрудничество с Google Cloud позволило Papa John's увеличить частоту заказов, повысить их стоимость, снизить затраты на обслуживание клиентов и улучшить удовлетворенность клиентов благодаря чат-боту на базе ИИ. (Papa John's International, Inc.)
🍔 Wendy's: FreshAI в drive-thru
Внедрение FreshAI в drive-thru ускорило обслуживание на 22 секунды по сравнению с местным средним показателем и достигло 99% точности заказов. (People.com, The US Sun)
🏦 Citi: Автоматизация код-ревью с ИИ
В первом квартале 2025 года Citi провел около 220 000 автоматизированных код-ревью с помощью инструмента на базе генеративного ИИ, увеличив производительность разработки. (Bank Automation News)
🏦 Deutsche Bank: Снижение ложных срабатываний
Внедрение ИИ позволило снизить количество ложных срабатываний при выявлении мошенничества на 60%, повысив эффективность и точность системы. (Toolify)
🏦 Intesa Sanpaolo: Цифровой помощник Ellis
Цифровой помощник Ellis, основанный на ИИ, улучшил взаимодействие с клиентами, предоставляя быстрые и точные ответы, что повысило удовлетворенность клиентов. (Qorusglobal)
🎨 Shutterstock: Генерация изображений с ИИ
Инструмент генерации изображений на базе ИИ позволяет пользователям создавать уникальные визуальные материалы по текстовому описанию, ускоряя процесс создания контента.
А как у вас там дела с этим?
❤️ - мы с ИИ лучшие друзья. «Всовываю» его всюду
🔥 - мы горим, какой ИИ
💊 - пока проблемы с естественным интеллектом. До 27 года лечим его, потом внедряем ИИ
@badtechproject
Гугл дропнули ультимативный гайд по использованию ИИ в бизнесе!
Пхах, я не удержался 😁
Короче, основная проблема ИИ - завышенные ожидания и не понимание куда этот ваш ИИ всунуть-то.
«Всовывать» предлагаю туда, куда подскажет вдохновение, а вдохновение призываю искать в подобных гайдах, в том числе .
👉🏼Пока не начали читать результаты других, напомню, что мы с вами собираем свои кейсы по ссылке.
🚗 Mercedes-Benz: Голосовой помощник MBUX
Внедрение генеративного ИИ в систему MBUX позволило обеспечить более естественное и интуитивное взаимодействие с автомобилем, улучшая пользовательский опыт. (Mercedes-Benz USA Media)
🚘 General Motors (OnStar): Виртуальный помощник
Виртуальный помощник OnStar, использующий ИИ, обрабатывает более 1 миллиона запросов клиентов в месяц в США и Канаде, разгружая операторов для более сложных задач. (GM Investor)
🍕 Papa John's: Оптимизация заказов с ИИ
Сотрудничество с Google Cloud позволило Papa John's увеличить частоту заказов, повысить их стоимость, снизить затраты на обслуживание клиентов и улучшить удовлетворенность клиентов благодаря чат-боту на базе ИИ. (Papa John's International, Inc.)
🍔 Wendy's: FreshAI в drive-thru
Внедрение FreshAI в drive-thru ускорило обслуживание на 22 секунды по сравнению с местным средним показателем и достигло 99% точности заказов. (People.com, The US Sun)
🏦 Citi: Автоматизация код-ревью с ИИ
В первом квартале 2025 года Citi провел около 220 000 автоматизированных код-ревью с помощью инструмента на базе генеративного ИИ, увеличив производительность разработки. (Bank Automation News)
🏦 Deutsche Bank: Снижение ложных срабатываний
Внедрение ИИ позволило снизить количество ложных срабатываний при выявлении мошенничества на 60%, повысив эффективность и точность системы. (Toolify)
🏦 Intesa Sanpaolo: Цифровой помощник Ellis
Цифровой помощник Ellis, основанный на ИИ, улучшил взаимодействие с клиентами, предоставляя быстрые и точные ответы, что повысило удовлетворенность клиентов. (Qorusglobal)
🎨 Shutterstock: Генерация изображений с ИИ
Инструмент генерации изображений на базе ИИ позволяет пользователям создавать уникальные визуальные материалы по текстовому описанию, ускоряя процесс создания контента.
А как у вас там дела с этим?
❤️ - мы с ИИ лучшие друзья. «Всовываю» его всюду
🔥 - мы горим, какой ИИ
💊 - пока проблемы с естественным интеллектом. До 27 года лечим его, потом внедряем ИИ
@badtechproject
💊50❤14🔥13👍4😁4
This media is not supported in your browser
VIEW IN TELEGRAM
Аааааааа, Наташка так и описывает мою работу 😁
Че, у вас также?
💯 - конечно, брат
❤️ - чисто, для поддержки
#пятничноеневпятницу
@badtechproject
Че, у вас также?
💯 - конечно, брат
❤️ - чисто, для поддержки
#пятничноеневпятницу
@badtechproject
💯81❤27🤣15👍3🤷♂2
Началось!
Очередной тех.дир пишет: менеджеры не должны шарить в технике!
1.
Боится, что его поймают на завышеных оценках
2.
На том, что команда вместо оптимизации пилит очередной микросевис.
3.
Святая вера, что писать код - самый-самый уникальный навык в мире.
Менеджер, должен шарить в технике и вот почему:
1.
Написание кода - не более 25% времени от разработки.
2.
Разработка - это не про код. Это про его поддержку, процессы, когда все рухнуло и т.п. И, поверьте, невозможно строить процессы, если ты нифига не понимаешь.
3.
А что за управление родмапом и рисками, если менеджер даже не понимает, в чем суть задачи?
4.
По вашему дирижер не умеет отличать инструменты? Должен ли он уметь играть на всех инструментах и быть лучшим музынкантом? Нет! Но он должен разбираться в музыке!
5.
Задача менеджера - направлять команду к результату. А когда ты не понимаешь, кто и что делает, максимум - выполнение KPI, чисто, если повезет
6.
Ты изобретаешь велосипеды из Excel
Не зная, что у вас в компании уже есть CI/CD, ты запускаешь ручную проверку в Notion.
Зачем? Ну потому что "нужно контролировать".
И создаешь ещё больше ручной работы для тех, кто и так завален багами.
7.
Ты начинаешь мешать. Активно.
У тебя есть время — потому что ты не разбираешься в технике.
А значит, ты ходишь по митингам, предлагаешь "улучшения процессов", делаешь презентации.
И вместо пользы — шум.
🔥 - я знаю техничку, а техничка знает меня
❤️ - пис, пацаны, только не устраивацте разработки в очередном подкасте
🫡 - не, ну тех.дир прав, конечно. Менеджера менеджерское, инженерам инженерское
@badtechproject
Очередной тех.дир пишет: менеджеры не должны шарить в технике!
1.
Боится, что его поймают на завышеных оценках
2.
На том, что команда вместо оптимизации пилит очередной микросевис.
3.
Святая вера, что писать код - самый-самый уникальный навык в мире.
Менеджер, должен шарить в технике и вот почему:
1.
Написание кода - не более 25% времени от разработки.
2.
Разработка - это не про код. Это про его поддержку, процессы, когда все рухнуло и т.п. И, поверьте, невозможно строить процессы, если ты нифига не понимаешь.
3.
А что за управление родмапом и рисками, если менеджер даже не понимает, в чем суть задачи?
4.
По вашему дирижер не умеет отличать инструменты? Должен ли он уметь играть на всех инструментах и быть лучшим музынкантом? Нет! Но он должен разбираться в музыке!
5.
Задача менеджера - направлять команду к результату. А когда ты не понимаешь, кто и что делает, максимум - выполнение KPI, чисто, если повезет
6.
Ты изобретаешь велосипеды из Excel
Не зная, что у вас в компании уже есть CI/CD, ты запускаешь ручную проверку в Notion.
Зачем? Ну потому что "нужно контролировать".
И создаешь ещё больше ручной работы для тех, кто и так завален багами.
7.
Ты начинаешь мешать. Активно.
У тебя есть время — потому что ты не разбираешься в технике.
А значит, ты ходишь по митингам, предлагаешь "улучшения процессов", делаешь презентации.
И вместо пользы — шум.
🔥 - я знаю техничку, а техничка знает меня
❤️ - пис, пацаны, только не устраивацте разработки в очередном подкасте
🫡 - не, ну тех.дир прав, конечно. Менеджера менеджерское, инженерам инженерское
@badtechproject
🔥129❤55🫡44👍9🤔3👎2
Плохой Project Артём Арюткин
“Платформа всё сделает за вас”- обещание, которое никто не сдержал Я тут готовлю доклад на TechLeadConf о том, как возникают и развиваются платформы в разных компаниях. И созрел вот такой пост. «Наша внутренняя платформа автоматизирует всё. Разработчик должен…
This media is not supported in your browser
VIEW IN TELEGRAM
Блин, это на столько хорошо дополняет пост и готовящийся доклад, что сегодня будет чуть сложное «пятничное»😁
1.
Если вы в платформе не думаете про «пользовательские сценарии», вида «выкатить приложение», «восстановить автоматически сервис, если он пятисотит», а мыслите формами вида:
- «создать каталог микросервисов сервисов»
- «развернуть контейнер» и т.п.
То вы, строите именно такой продукт, как в классическом ролике…
Долго, дорого,
, ну и классика
А «контейнер» и, правда, развернулся, только по пути потерялся мониторинг, настройки рейт-лимитеров и прочее…
И тогда, уж лучше бы он не разворачивался.
Поверьте, вам нужен работающий e2e сценарий, работающий в формате wow.
Вот этого жду ваши пользователи.
#пятничное
@badtechproject
1.
Если вы в платформе не думаете про «пользовательские сценарии», вида «выкатить приложение», «восстановить автоматически сервис, если он пятисотит», а мыслите формами вида:
- «создать каталог микросервисов сервисов»
- «развернуть контейнер» и т.п.
То вы, строите именно такой продукт, как в классическом ролике…
Долго, дорого,
радуйтесь, что вам на гульфик рукав не пришили
, ну и классика
к пуговицам претензии есть.
А «контейнер» и, правда, развернулся, только по пути потерялся мониторинг, настройки рейт-лимитеров и прочее…
И тогда, уж лучше бы он не разворачивался.
Поверьте, вам нужен работающий e2e сценарий, работающий в формате wow.
Вот этого жду ваши пользователи.
#пятничное
@badtechproject
1💯22😁8👌2🤣2❤1🔥1
«А что, а вдруг!»
Народ, у меня тут идет ремонт во всю и, вдруг, кто-то может подогнать хорошую скидку на технику ASKO?
С меня бутылка отличного вина😉
Если что писать сюда @badtechproject_contakt
❤12😁4✍3🥴1
Measuring Developer Experience With a Longitudinal Survey
Так-с, как и обещал в пятницу, делаю обзорчик.
Короче, Google снова выкатил вайтпейпер — статью-исследование на базе своих инженерных практик.
На этот раз про измерение Developer Experience.
Что такое Developer Experience?
Как мы помним, DevEx — это, конечно же, про печеньки, сырки и массажные кресла. Ну и зарплату! 🤑
На самом деле — нет.
DevEx — это про:
кайфовые инструменты, с которыми приятно работать;
процессы, которые помогают, а не мешают;
и то самое счастье разработчика, которое мы все ищем, но никак не найдем.
Что делает Google?
У них уникальный кейс: опросы по DevEx они ведут уже более 6 лет. Не просто «отправили анкету», а строят настоящую исследовательскую платформу.
Ключевые идеи из статьи:
1. Оценивайте сценарий, а не инструмент
Разработчик не мыслит: «поднять под».
Он мыслит: «выкатить сборку», «откатить фичу», «найти баг».
Хороший DevEx-опрос спрашивает не «нравится ли тебе Jenkins», а «насколько удобно тебе деплоить хотфикс».
2. Считайте NPS по сценариям
Идея крутая: применяй NPS (оценка 0–10, насколько порекомендуешь) к конкретным инженерным процессам.
Анализируй, где friction. Улучшай. Измеряй снова.
3. Опрос - это часть DevEx-продукта
Опрос - это не ради галочки. Это:
способ тестировать гипотезы;
метод влияния на культуру;
механизм игры в долгую.
4. Нет wow-эффекта → не проводите следующий опрос
Провели опрос - обязательно покажите, что изменилось:
- демо там проведит,
- пост в блоге напишите,
- внутреннюю рассылку намутите.
Без этого люди решат, что потратили время впустую.
5. Пульс-опросы раз в квартал
Google бьёт инженеров на 3 когорты и проводит опросы раз в квартал.
Хороший темп, если у вас 500+ инженеров. Почему бы и нет?
6. Команда: инженер + исследователь
Один - поддерживает инфраструктуру, второй - отвечает за вопросы и анализ.
7. Добавляешь вопрос - убирай старый
Желание добавить «вот ещё один важный вопросик» бесконечно. Но если вы дадите 50 пунктов — на 31-м люди будут тыкать в потолок. Ладно, не в потолок, а в среднее значение
Лучше меньше, но с фокусом и частотой. И с действием.
8. Не жди - встраивай обратную связь в продукт
Опрос - это отложенная реакция.
А лучше всего: встраивай оценку прямо в flow. После деплоя, после ревью, после CI-ошибки.
Так ты увидишь реальные данные - в моменте.
DevEx Starter Pack
Если ты только начинаешь и хочешь понять, где болит — вот 10 проверенных вопросов:
DevEx начинается с вопросов. Главное - задавать их правильно.
Народ, а у вас в компании уделяют внимание DevEx?
💯 - дааа, все по кайф
🔥 - я и есть тот, кто делает DevEx
❤️ - помнишь мы планируем разобраться с естественным интеллектом к 27+? Ну там и к DevEx приступим 😁
@badtechproject
Так-с, как и обещал в пятницу, делаю обзорчик.
Короче, Google снова выкатил вайтпейпер — статью-исследование на базе своих инженерных практик.
На этот раз про измерение Developer Experience.
Что такое Developer Experience?
Как мы помним, DevEx — это, конечно же, про печеньки, сырки и массажные кресла. Ну и зарплату! 🤑
DevEx — это про:
кайфовые инструменты, с которыми приятно работать;
процессы, которые помогают, а не мешают;
и то самое счастье разработчика, которое мы все ищем, но никак не найдем.
Что делает Google?
У них уникальный кейс: опросы по DevEx они ведут уже более 6 лет. Не просто «отправили анкету», а строят настоящую исследовательскую платформу.
Ключевые идеи из статьи:
1. Оценивайте сценарий, а не инструмент
Разработчик не мыслит: «поднять под».
Он мыслит: «выкатить сборку», «откатить фичу», «найти баг».
Хороший DevEx-опрос спрашивает не «нравится ли тебе Jenkins», а «насколько удобно тебе деплоить хотфикс».
2. Считайте NPS по сценариям
Идея крутая: применяй NPS (оценка 0–10, насколько порекомендуешь) к конкретным инженерным процессам.
Анализируй, где friction. Улучшай. Измеряй снова.
3. Опрос - это часть DevEx-продукта
Опрос - это не ради галочки. Это:
способ тестировать гипотезы;
метод влияния на культуру;
механизм игры в долгую.
4. Нет wow-эффекта → не проводите следующий опрос
Провели опрос - обязательно покажите, что изменилось:
- демо там проведит,
- пост в блоге напишите,
- внутреннюю рассылку намутите.
Вот вы проходили опрос. Мы внесли такие-то изменения. Вот, как стало лучше.
Без этого люди решат, что потратили время впустую.
5. Пульс-опросы раз в квартал
Google бьёт инженеров на 3 когорты и проводит опросы раз в квартал.
Хороший темп, если у вас 500+ инженеров. Почему бы и нет?
6. Команда: инженер + исследователь
Один - поддерживает инфраструктуру, второй - отвечает за вопросы и анализ.
У меня пока такого нет. Есть проджект, который держит опрос. Но под такой рост — модель классная.
7. Добавляешь вопрос - убирай старый
Желание добавить «вот ещё один важный вопросик» бесконечно. Но если вы дадите 50 пунктов — на 31-м люди будут тыкать в потолок. Ладно, не в потолок, а в среднее значение
Лучше меньше, но с фокусом и частотой. И с действием.
8. Не жди - встраивай обратную связь в продукт
Опрос - это отложенная реакция.
А лучше всего: встраивай оценку прямо в flow. После деплоя, после ревью, после CI-ошибки.
Так ты увидишь реальные данные - в моменте.
DevEx Starter Pack
Если ты только начинаешь и хочешь понять, где болит — вот 10 проверенных вопросов:
1. Насколько тебе удобно настроить окружение, чтобы начать новую задачу?
2. Насколько быстро ты получаешь фидбэк после коммита (CI, ревью, тесты)?
3. Насколько удобно тебе выкатывать фичу в прод в текущем процессе?
4. Если что-то ломается на проде, насколько просто найти и устранить причину?
5. Насколько тебе понятно, кто отвечает за нужный тебе компонент или систему?
6. Насколько удобно тебе получать помощь по внутренним тулзам и системам?
7. Насколько просто тебе разобраться в незнакомом коде?
8. Насколько удобно тебе участвовать в код-ревью (и получать его)?
9. Насколько ты можешь работать в фокусе, без постоянных отвлечений?
10. Насколько ты чувствуешь, что можешь влиять на процессы в команде?
DevEx начинается с вопросов. Главное - задавать их правильно.
Народ, а у вас в компании уделяют внимание DevEx?
💯 - дааа, все по кайф
🔥 - я и есть тот, кто делает DevEx
❤️ - помнишь мы планируем разобраться с естественным интеллектом к 27+? Ну там и к DevEx приступим 😁
@badtechproject
❤33🔥11👍8💯3