Важность планирования на планшете.

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

Сейчас набирает популярность open-source сервис excalidraw.com Его применение все чаще можно встретить у блоггеров в видео на ютубе.
Простой инструмент удобный, collaborative, можно с командой в реальном времени рисовать, а потом ссылку кинуть — и всё работает без регистрации. 

В каком то смысле, это и есть тот планшет со схемами, о котором говорил Щедровицкий в #лек_5. В посте о важности схем приведены конкретные цитаты.

Например, нужно структурировать сложные, разрозненные идеи и донести их до команды/менеджера/себя самого. Стандартные инструменты (тот же Confluence) для этого слишком формальны и негибки.

А тут перед тобой открывается простой минималистичный холст, в котором можно писать текст, добавлять различные фигуры (ромб, квадрат, круг). Писать внутри них. Соединять стрелками. При последующем перемещении стрелки магнитятся к краям фигур и могут перемещаться вместе с ними. Можно вставить картинку, видео с ютуба, которое будет in place проигрываться.

Но мне могут возразить:
Рисовать схемы вручную? В 2024-том? Это же так... Долго. Я промптом в GPT-4o или Claude прошу: «нарисуй диаграмму последовательности для микросервиса аутентификации на C++ с использованием JWT и Redis для кеширования». И через 10 секунд получаю готовую, идеальную диаграмму в PlantUML или Mermaid. Я её потом только немного кастомизирую. Зачем тратить время на ручное рисование, если ИИ может сделать это за меня и, возможно, учесть нюансы, о которых я даже не подумал? Ваш Excalidraw — это крутой костыль, но будущее за prompt-based design.

Но схема, полученная таким путем, не является продуктом твоей мыследеятельности.
Все же рисовать какие-то схемки на бумаге куда приятнее.  К этим каракулям быстро привязывается наше воображение. А далее включается язык с идеями и представлениями в виде символов и значков. Появляется смысл и рефлексия. Но об этом в следующем посте.

Услышал на стриме у Декабриста

Все знают, что резюме проверяют с помощью ИИ.

при этом все знают, что резюме пишут с помощью ИИ.

Поэтому они с помощью ИИ проверяют, чтобы резюме не было написано с помощью ИИ.

Ох...

Но при этом они знают, что можно руками подредактировать резюме, которое написала ИИ, и его все равно не заметит система... Вот это да!

Внезапно Linux не грузится и показывает странную консоль initramfs> после сбоя? Не паникуйте. Это не крах — это система просит вас о помощи.

Помните: это не ошибка, а аварийный режим для вмешательства. Ваш шанс проявить себя.

ПЛАН (что делать):
1. В строке initramfs> пробуем команду fsck -y /dev/sda1 (чаще всего sda1, но может быть nvme0n1p2 и т.д., можно посмотреть ls /dev).
2. Если просит — жмём y (yes). Ждём завершения.
3. Пишем exit и пробуем загрузиться. В 90% случаев этого хватает.

Готово? Система запустилась? Вы только что вручную починили файловую систему! Теперь можно выдохнуть и разобраться в сути.

А ЧТО ЭТО БЫЛО?

Initramfs — Это мини-ОС в оперативке, чья задача — подготовить всё для загрузки основной системы. Если он не справляется и зовёт вас, причины обычно в этом:

▫️ ФС была повреждена (самое частое после сбоя питания)
▫️ Не может найти корневой диск (проблема с драйверами или конфигом)
▫️ Аппаратный сбой (отходит шлейф, умер диск)

Ваша реакция на initramfs> — это и есть то, что отличает специалиста от пользователя. Вы не переустанавливаете систему с нуля, а чините и подкручиваете её. Это ценный навык.

Для студентов: Любой сбой — это возможность глубже понять систему и прокачать скиллы. Возможность стать тем, кто расскажет о себе и про это на следующем собесе.

#linux #admin #восстановление #hardcore #timely_advice #собес

Смотрел сегодня мок-собесы и увидел совместную реализацию двух паттерное.

1. Первый - такназываемый «синглтон Мейерса»

Этот паттерн особенно подходит для управления доступом к ресурсам, таким как конфигурационные файлы, аппаратные интерфейсы, логгеры, или управление состоянием для всего приложения.

Это идиома реализации синглтона в C++, предложенная Скоттом Мейерсом. Она использует статическую локальную переменную внутри функции-геттера:

class Singleton {
public:
    static Singleton& instance() {
        static Singleton s_instance;
        return s_instance;
    }

private:
    Singleton() = default;
    ~Singleton() = default;
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};

Какие особенности есть у этого похода:

- Ленивая инициализация: объект создаётся при первом вызове instance().

- Автоматическая корректная деинициализация: деструктор вызывается при завершении программы.

- Потокобезопасность (в C++11 и выше): стандарт гарантирует, что инициализация статической локальной переменной атомарна и потокобезопасна.

Доступность: к открытым методам такого класса можно получить доступ из любой точки мира, при условии, что вы включили заголовочный файл в другие файлы проекта с помощью #include.

2. CRTP (Curiously Recurring Template Pattern)

CRTP — это идиома, где базовый класс принимает в шаблоне тип производного класса:

template <typename Derived>
class SingletonBase {
public:
    static Derived& instance() {
        static Derived s_instance;
        return s_instance;
    }

protected:
    SingletonBase() = default;
    ~SingletonBase() = default;
};

class MySingleton : public SingletonBase<MySingleton> {
    friend class SingletonBase<MySingleton>; // чтобы конструктор был доступен
private:
    MySingleton() = default;
};

Преимущества данного похода

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

#singleton #design_patterns #crtp

Точечные оценки — красивая ложь

Проект займёт 14 недель

— слышали такое?
Я слышу это постоянно. И каждый раз внутри меня что-то сжимается 😅
Эта цифра создаёт иллюзию точности. Как будто кто-то заглянул в будущее и увидел дату релиза. Реальность: это одна из тысяч возможностей.

Помню, как в одном проекте менеджер с уверенным видом объявил:

12 недель, не больше

Спойлер: проект занял 22 недели.

И знаете, что самое интересное? Никто даже не удивился. Все молча кивнули и продолжили работать, как будто так и было задумано.

Точечная оценка без вероятности бессмысленна.

Она подразумевает 100% гарантию, хотя в разработке нет ничего гарантированного.

Три понятия, которые путают:
Оценка — вероятностный прогноз
Цель — желаемый результат
Обязательство — договорённость с учётом рисков

Когда менеджер говорит «14 недель», спросите: «Какова вероятность этого числа? 50%? 30%? 10%?»

Я начал задавать этот вопрос на каждой встрече. Сначала на меня смотрели как на человека, который усложняет простые вещи. Потом начали понимать. А потом — сами стали говорить в диапазонах и вероятностях.

Без ответа цифра остаётся пустым звуком.
Или, как я люблю говорить — красивой ложью, которая всех устраивает. До момента, когда дедлайн пролетает мимо, а релиза всё нет 🙃

А как у вас в команде с оценками? Говорите диапазонами или всё ещё верите в магию точных цифр?

Асимметрия реальности

Многие представляют сроки проекта как колоколообразную кривую - симметричное распределение вокруг среднего (как нормальное распределение Гаусса).
Это неправда.

Знаете, что меня всегда удивляло? Как упорно люди верят в эту красивую симметрию. Я сам когда-то так думал, пока не словил пару болезненных уроков в моем проекте 😅
Существует предел того, насколько быстро команда может работать. Левая сторона графика обрезана - нельзя писать код быстрее физических возможностей.

Помню, как менеджер спросил меня: «А если мы добавим ещё разработчиков?» Я ответил: «Девять женщин не родят ребёнка за месяц». Он не оценил мою метафору, но суть понял 🙃

А вот количество проблем ничем не ограничено:

Критические баги в продакшене
Уход ключевого разработчика
Изменение требований на 80% готового проекта
Проблемы с инфраструктурой
Интеграция, которая «должна была работать из коробки»

Эти пункты - не теория. Это список из моего последнего квартала. Причём все пять случились в ОДНОМ проекте. Одновременно. Я до сих пор не понимаю, как мы выжили 😁
Результат: график вероятностей имеет короткий левый хвост и длинный правый.
Медиана (точка 50/50) показывает: половина проектов завершится раньше, половина - позже. И эта «половина позже» может растянуться ОЧЕНЬ далеко.
Самый долгий проект в моей практике должен был занять 3 месяца. Закончили через 11. И нет, это не провал - это просто реальность, в которой работают разработчики.


А у вас был такой проект-долгострой? Сколько в итоге длился и что пошло не так?

Иллюзия 90% уверенности

Эксперимент: людям дали тест из 10 вопросов. Нужно указать диапазон ответа с «90% уверенностью».
Результаты:

Средний балл: 2.8 из 10
Только 2% получили 8+ правильных ответов
Никто не ответил верно на все 10

Когда я впервые прочитал про этот эксперимент, подумал:

Ну это же они, обычные люди. Мы-то в IT поумнее

Провёл похожий тест в своей команде. Угадайте результат? Правильно, точно такой же провал 😅

Вывод: интуитивное ощущение «90% уверенности» на деле соответствует примерно «30% уверенности».

То же самое в проектах. Команды регулярно представляют графики с «90% уверенностью» и регулярно их превышают — в 50-60% случаев, а не в 10%.

Был у меня один тимлид, золотой человек. На каждой планёрке: «Я на 90% уверен, что закончим к пятнице». Знаете, сколько раз из десяти он укладывался? Три. ТРИ, Карл! Это вообще 30%, а не 90%.
Я его спросил:

Слушай, а ты понимаешь, что значит 90%?

Он посмотрел на меня и честно ответил:

Ну... я просто так чувствую

Вот она, вся наша «уверенность» 🙃

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

Сейчас, когда кто-то в команде говорит «я на 90% уверен», я достаю блокнот и говорю:

Отлично! Давай запишем. Будем проверять калибровку твоей уверенности

.Обычно после этого люди начинают говорить более честно: «Ну... наверное, половина на половину» 😁

А вы когда-нибудь ловили себя на таком? Говорили «я уверен на 90%», а потом оказывалось совсем не так?

Конус неопределённости

Точность оценок меняется предсказуемо на разных этапах проекта.

Погрешность по этапам:

Первоначальная концепция: ±300% (диапазон 0.25x - 4x)
=> Оценка «100 дней» = реально 25-400 дней

Утверждённое определение: ±100% (0.5x - 2x)
=> «100 дней» = 50-200 дней

Завершённые требования: ±50% (0.67x - 1.5x)
=> «100 дней» = 67-150 дней

Детальное проектирование: ±10% (0.9x - 1.1x)
=> «100 дней» = 90-110 дней

Помню встречу с инвесторами на самом старте проекта. Они спросили: «Сколько времени займёт разработка?» Я честно ответил: «От трёх месяцев до года». Знаете, что они сказали? «Нам нужна точная цифра».
Я нарисовал им этот конус на доске. Объяснил про ±300%. Они посмотрели друг на друга и снова: «Ну хорошо, но примерно?»
В итоге я сказал «полгода», они записали это как обязательство, и через восемь месяцев были очень удивлены 😅

Эталонная точность ±10% достигается только на финальной стадии проектирования.

То есть когда проект практически готов. Парадокс, да? Когда тебе больше всего нужна точность - в самом начале - её меньше всего. А когда она наконец появляется - уже всем всё равно, потому что релиз через неделю.

Критично: Конус представляет ЛУЧШУЮ возможную точность для квалифицированных оценщиков. Хуже — легко. Точнее - только случайно.

Это моё любимое. Видел я команды, которые на стадии «у нас есть идея» давали оценку с точностью до дня. Спрашиваю: «Ребят, а как вы так точно посчитали?» Ответ: «Ну, мы подумали».

Подумали. На стадии ±300% погрешности. И самое грустное - иногда они попадают в цель. И потом годами рассказывают, какие они крутые оценщики, не понимая, что им просто повезло 🙃
Сейчас я всегда показываю этот конус заказчикам в самом начале. Да, некоторые уходят искать того, кто «оценит точнее». Но те, кто остаётся, понимают игру и работать с ними - одно удовольствие.

А вы встречали людей, которые требуют точных оценок на стадии концепции? Как с ними разговариваете?

Привет!
Кажется нашел нормальное чтиво по работе.

Claude AI и Z AI (glm)

Помимо привычного текстового чата, современные платформы Claude.ai (от Anthropic) и Z.ai (от Zhipu AI) превратились в полноценные рабочие среды с широким набором инструментов для визуализации, анализа данных и автоматизации.

Инструменты и возможности Claude

Claude значительно расширил функциональность за счет внедрения специализированных режимов и интеграций, которые позволяют работать с кодом, документами и дизайном более интерактивно:

1️⃣Артефакты (Artifacts): Это отдельная интерактивная панель в правой части экрана, где Claude создает и обновляет структурированный контент. В этой панели можно:

📌Запускать код: Claude может написать игру (например, «Змейку») на HTML/JavaScript, и в нее можно играть прямо в интерфейсе.

📌Работать с React-компонентами: Создавать интерактивные элементы интерфейса с анимациями и фильтрами.

📌Генерировать диаграммы и схемы: Создавать векторные SVG-схемы архитектур или организационных структур, которые можно скачивать и масштабировать.

📌Просматривать документы: Markdown-файлы и ТЗ отображаются с красивым форматированием, а не в виде сырого текста.

2️⃣Проекты (Projects): Это выделенные рабочие пространства, которые позволяют сохранять контекст между разными чат-сессиями.

📌В проект можно загружать базу знаний (PDF, таблицы, текстовые документы) объемом до 30 МБ на файл.

📌Можно задавать системные инструкции, которые определяют роль Claude и правила его поведения для всех диалогов внутри проекта.

3️⃣Claude Code: Инструмент для разработчиков, работающий через терминал. Он имеет доступ к файловой системе, может выполнять bash-команды, делать git-коммиты и проводить глубокий рефакторинг кода.

4️⃣Claude Design: Экспериментальный инструмент для визуального дизайна. Он помогает создавать прототипы приложений, слайды и макеты на основе текстового описания, позволяя менять цвета и шрифты в реальном времени. Результаты можно экспортировать в PDF, PPTX или передавать в Canva для дальнейшей правки.

5️⃣Инструменты анализа и интеграции:

📌Analysis Tool: Позволяет загружать CSV-файлы для проведения эксплораторного анализа данных (EDA), очистки данных и построения графиков прямо в чате.

📌Claude for Sheets: Плагин для Google Таблиц, позволяющий использовать формулы Claude для массовой обработки данных в ячейках.

📌MCP (Model Context Protocol): Протокол, позволяющий подключать Claude к внешним сервисам, таким как базы данных Postgres, Figma, Slack или Google Drive.