Народ устроил хакатон по разработке с помощью Replit AI, писал о нем недавно.

Впечатления авторов:

Тесно пообщавшись с ИИ-агентом Replit, мы всей командой пришли к единому мнению — решение пока неконкурентное и нежизнеспособное. И, конечно, разработчиков заменить не в состоянии. С его помощью можно написать код для простой игры вроде «крестии-нолики», которые я сгенерировал за несколько промптов.

Но на более-менее больших и серьёзных проектах всё бесповоротно ломается. Выбрать технологии или язык – целая проблема.

Да и команды пользователя, и даже собственные предложения Replit реализует через раз — и это в лучшем случае.

В результате оказалось, что от известного GPT4 толку в подобных задачах больше, хотя и он пока заменить программиста не способен.

Replit же скорее тратит нервные клетки разработчиков (и не только), а не облегчает их труд.

Интересно, Replit AI - это обертка вокруг популярных моделей без серьезного тюнинга, или просто сырая технология?

Выглядит, что для прототипов эффективнее использовать no/low code платформы, а Replit - это онлайн IDE с инфрой для деплоя и агентом для экспеиментов. Но это сегодня. А вот что будет с приходом рассуждающих LLM типа o1 и их потомков - увидим в следующих сериях.

Как правильно выбрать хранилище под задачу

Пытаюсь понять, как у людей (команды) в рамках одной активности одновременно уживаются понятия «заказчик» и «продукт».

Если мы можем с уверенностью назвать кого-то заказчиками, то мы явно не созданием продукта занимаемся.

#оффтоп #манагерское

Как же интересно работает мозг. Встретил тезис в духе:

В работе нужно строго ограничивать зону собственной ответственности. Если сталкиваешься с проблемами вне этой зоны - эскалируй, сам не лезь, иначе потом на части разорвешься, никто спасибо не скажет. Когда руководству будет нужно, само прибежит, найдет ресурсы и спустит приоритеты.

Поток мыслей:

- Надо срочно ответить, в инете кто-то неправ!

- Как же хорошо, что большинство близких коллег не из этих

- Надеюсь, больше никогда не попаду в такой коллектив

- Интересно, как у людей формируется такая позиция?

- Подозреваю, ее формируют процессы, коммуникации и культура в компании

- Интересно, на сколько часто в моих командах складывалось такое отношение? Как избежать это или изменить?

Хотел набросить, ушел рефлексировать. Жизнь боль.

Утро начинается с кэша

Годная лекция о кэшировании от основ до сложностей реализации. Что интересного:

• Стратегии кеширования
• Считаем, когда кэш вреден
• Вытеснение данных из кэша
• Инвалидация кэша

Перед просмотром лекции советую прочитать вводную статью о кэшировании, так будет проще.

Небольшая статья о кэшировании, интересный разбор взаимодействия кэша с источником.

Где можно встретит кэши? Правильно, везде. Статья для расширения сознания.

#архитектура

#манагерское

Спасибо Пименову, прекрасная иллюстрация

Я считаю, что у нас есть некое искажение понимание клиентской ценности. Мы подменяем клиентскую ценность ценностью для понимания потребности клиента. Каждую итерацию и Стив лучше понимает что он хочет и компания Ibanez лучше понимает то, что хочет Стив. Но это не клиентская ценность. Клиентская ценность — это когда Стив получил финальную гитару. И любой на месте Стива хотел бы знать, за сколько (примерно) ему сделают гитару мечты.

Что происходит с индустрией, если аналитикам рассказывают про кубер?

Версия спикера:

При этом знание основных концепций Kubernetes позволяет глубже понимать работу ваших систем и является необходимым этапом для роста из системного аналитика в тимлида или архитектора

Вопрос 1: системному аналитику точно нужно в архитектора расти?

Вопрос 2: вы сталкиваетес на работе с кубером? Какая у вас роль? Чиркните в комментах, плз

Нашел перевод статьи на русский. Больше нет причин, чтобы откладывать

#шокконтент

Сейчас на занятии одна из участниц поделилась, как на собесе на роль сисаналиста у нее спрашивали о способах инвалидации кэша.

Что. Здесь. Происходит?

Недостающие звенья кэширования

Статья, которую можно использовать для первого знакомства с темой.

Статья, в которй раскрыто, что кэши можно найти вообще где угодно - для расширения сознания.

Дополнил исходный пост, забирайте его полностью.

#архитектура #systemdesign

#оффтоп

Пока искал фотку с конфы...

Други, кто-нибудь обитает сейчас на Пхукете? Давайте соберемся на чаек.

Тут всех приглашают поучаствовать в архитектурной кате. Онлайн, бесплатно.

Отличный вариант добрать опыта проектирования - зачем упускать?

📅 5 декабря, четверг, 19:00 мск

#оффтоп #манагерское

Как интересно работает мозг. Существует 100500 методик, как эффективно давать фидбек. Многие сходятся на том, что в него обязательно нужно включать позитивные тезисы.

Когда есть силы, стараюсь регулярно запрашивать фидбек у коллег: сотрудники, руководство, смежники.

Периодически слышу конструкции вида: “ты классно сделал ХХХ”, “здорово, что ты YYY”, “в целом все хорошо” - а дальше следует содержательная часть что человека не устраивает.

В такие моменты слушаю и думаю: “Давай уже пропустим эту херню и перейдем к делу. Захочу узнать о хорошем - спрошу прямо”. А человек же старается как лучше.

Очевидно, есть другие люди, с таким же восприятием.

Очевидно, есть люди, которых прямая подача демотивирует.

И дай мне мудрость отличить одних от других

#манагерское

Хорошо написано (оригинал):

В психологическом противостоянии заказчика и исполнителя в заказной разработке я вижу две корневых причины: несовпадение меры ответственности и меры определённости.

На заказчике всегда больше ответственности. Если команда разработки что-то не автоматизировала, в конце рабочего дня они встанут и пойдут домой, а заказчик будет делать свою работу в ночи вручную
…

При разработке продукта тоже часто возникает проблема с восприятием неопределенности, но наоборот - грустит разработка

#оффтоп
Сисдизайн секция здорового человека:

- Вам нужно спроектировать Key-Value хранилище
- Зачем?
- ...
- Спасибо, я не перезвоню

#интеграция #архитектура

Полгода ждал, когда можно будет выложить доклад в открытый доступ. Мастхев для всех, кто занимается проектированием интеграций и распределенных систем. Даже лень писать тезисы, просто смотрите.

• Надежность взаимодействий: время отклика, таймайуты, хелсчеки - и как это считать реальными числами

• Проблемы взаимодействий поверх брокеров

• Согласованность и управление транзакциями

Рекомендуется к просмотру перед изучением статьи о способах обеспечения отказоустойчивости при синхронных взаимодействиях.

#манагерское

Собирайте грибы, а не требования

Если лень читать:
1. Требований не существует
2. Задача аналитика - не собрать требования

В холиварах на тему “нужен ли аналитик?” часто слышу аргумент: “Задача по сбору требований остается, просто без аналитика ее вешают на другую роль”.

В этом высказывании есть ряд неявных допущений:

1. Существуют некоторые объективные “требования”
2. Существуют люди, которым “требования” известны - стейкхолдеры
3. С помощью особых техник можно собрать все “требования” у стейкхолдеров
4. Если реализовать “требования”, то мы получим результат, который нужен бизнесу

Все хорошо, но есть нюанс: эти допущения выполняются разве что в заказной разработке:

1. Требования - хотелки заказчика
2. Стейкхолдеры - сотрудники заказчика
3. Аналитики записывают хотелки заказчика, мы прикладываем их к договору
4. Реализуем хотелки, получаем деньги - профит

И то при особо злостном следовании “требованиям” заказчик может отказаться принимать работу или отправить нас в блеклист после сдачи проекта.

Когда мы пилим продукт, в роли “требований” могут выступать разве что ограничения регулятора и законы физики. Никаких “правильных требований”, которые можно "собрать", здесь нет. Как и нет людей, которые точно знают, что делать - мы оперируем гипотезами, исследованиями, данными разной степени достоверности.

Аналитик может быть полезен в такой среде: выявить корнеры, почеленджить логику, найти противоречия. При этом критично, чтобы в процесс проектирования решения были вовлечены и аналитик, и бизнес-эксперты с продактом, и техническая команда. С таким подходом в анализ и проектирование вовлечена вся команда. Однажды мы можем обнаружить, что она вполне справляется без аналитика.

А если без аналитика никак, то почему? Хотим работать по принципу: “Что нам сказали, то и делаем”?

#интеграция
Вот такая шикарная инфографика от Юрия Куприянова. Не со всем согласен, мои комменты тут.

Полезая штука, но как всегда буду душнить: пожалуйста, никогда (прописью: никогда) не принимайте боевые решения на основе таких таблиц / критериев / алогритмов - они никогда не будут отражать всех нюансов. А какие нюансы важны в вашем контексте, знаете только вы.

Тогда в чем польза? Систематизировать знания, сверить картину мира, если что-то кажется странным - погуглить и узнать что-то новое.