Почему программисты (и не только) всегда опаздывают с дедлайнами?

Ошибка планирования — это когнитивное искажение, из-за которого мы систематически недооцениваем время, ресурсы и усилия, необходимые для выполнения задачи. Впервые описано психологами Даниэлем Канеманом и Амосом Тверски в 1979 году.

Ключевые фишки:

- Универсальность: влияет на людей независимо от опыта и экспертизы
- Устойчивость: сохраняется даже при осведомленности о нем
- Масштабируемость: проявляется как в малых задачах, так и в крупных проектах

Причины возникновения:

- Чрезмерный оптимизм 😊
- Игнорирование прошлого опыта
- Недооценка сложности и возможных препятствий
- Фокус на идеальном сценарии ("планирование наилучшего случая")
- Внешнее и внутреннее давление сроков
- Желание произвести хорошее впечатление

1️⃣ "Это просто баг, пофикшу за час!"
Спустя 8 часов: "Кто написал этот спагетти-код?!"
2️⃣ Оценка проекта: 2 недели
Реальность: 2 месяца
Причина: Забыли учесть тестирование, документацию и неизбежные правки от клиента.
3️⃣ "Внедрение нового фреймворка займет пару дней"
Месяц спустя: Команда всё еще борется с несовместимостью и неожиданными багами.

Как бороться?

- Разбивайте задачи на мелкие подзадачи
- Применяйте "планирование от прошлого": анализируйте схожие завершенные проекты
- Добавляйте буферное время (умножение оценки на Пи и т.д.)
- Учитывайте "неизвестные неизвестные": резервируйте время на непредвиденные сложности

И всё равно нихера не угадаете

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

Прожарка гитхаб-профиля 🙂

https://github-roast.pages.dev/

Go: Внутреннее устройство sync.Map, сравнение производительности с map + RWMutex

Upd.: теперь и на Хабре

Для тех, кто хочет понять, когда стоит использовать sync.Map, а когда достаточно обычной map с мьютексом.

Внутреннее устройство sync.Map

sync.Map - это потокобезопасная реализация карты в Go, оптимизированная для определенных сценариев использования.
Основная структура sync.Map выглядит примерно так:

type Map struct {
    mu Mutex
    read atomic.Value // readOnly
    dirty map[interface{}]*entry
    misses int
}

type readOnly struct {
    m       map[interface{}]*entry
    amended bool
}

type entry struct {
    p unsafe.Pointer // *interface{}
}

Здесь мы видим несколько ключевых полей:

mu - мьютекс для защиты доступа к dirty мапе
read - атомарное значение, содержащее readOnly структуру
dirty - обычная Go мапа, содержащая все актуальные значения
misses - счетчик промахов при чтении из read мапы

Основная идея sync.Map заключается в использовании двух внутренних карт: read (только для чтения) и dirty (для записи и чтения). Это позволяет оптимизировать операции чтения, которые часто не требуют блокировки.

Операция Load

При выполнении операции Load, sync.Map сначала пытается найти значение в read мапе. Если значение найдено, оно возвращается без какой-либо блокировки. Это очень быстрая операция.
Если значение не найдено в read мапе, увеличивается счетчик misses, и sync.Map проверяет dirty мапу, захватывая мьютекс. Если значение найдено в dirty мапе, оно возвращается.

Операция Store

При выполнении Store, sync.Map сначала проверяет, существует ли ключ в read мапе. Если да, она пытается обновить значение атомарно. Если это не удается (например, ключ был удален), она переходит к обновлению dirty мапы.
Если ключ не существует в read мапе, sync.Map захватывает мьютекс и обновляет dirty мапу.

Когда dirty заменяет read

Интересный момент происходит, когда количество промахов при чтении из read мапы (misses) превышает длину dirty мапы. В этом случае sync.Map выполняет операцию "продвижения":

1. Захватывается мьютекс
2. Содержимое dirty мапы копируется в новую read мапу
3. dirty мапа очищается
4. Счетчик misses сбрасывается

Это выглядит примерно так:

func (m *Map) missLocked() {
    m.misses++
    if m.misses < len(m.dirty) {
        return
    }
    m.read.Store(&readOnly{m: m.dirty})
    m.dirty = nil
    m.misses = 0
}

Такой подход позволяет адаптироваться к паттернам использования: если происходит много чтений после серии записей, dirty мапа продвигается в read, что ускоряет последующие операции чтения.

Сравнение производительности с map + RWMutex

Теперь давайте сравним производительность sync.Map с обычной map, защищенной sync.RWMutex.
Обычная потокобезопасная мапа может выглядеть так:

type SafeMap struct {
    mu sync.RWMutex
    m  map[interface{}]interface{}
}

func (sm *SafeMap) Load(key interface{}) (interface{}, bool) {
    sm.mu.RLock()
    defer sm.mu.RUnlock()
    val, ok := sm.m[key]
    return val, ok
}

func (sm *SafeMap) Store(key, value interface{}) {
    sm.mu.Lock()
    defer sm.mu.Unlock()
    sm.m[key] = value
}

Производительность этих двух подходов будет зависеть от конкретного сценария использования:

- Если у вас преимущественно операции чтения, sync.Map может быть быстрее, особенно если ключи стабильны (мало добавлений новых ключей).
- Если у вас много операций записи, особенно добавления новых ключей, map + RWMutex может показать лучшую производительность.
- При небольшом количестве горутин, работающих с мапой, разница может быть незначительной, и простота map + RWMutex может быть предпочтительнее.
- При большом количестве горутин, особенно на многоядерных системах, sync.Map может показать лучшую масштабируемость.

Заключение

sync.Map - не серебряная пуля. Её внутреннее устройство оптимизировано под определенные сценарии использования.

Прикольно. Безо всякого программирования Илья сделал ии-ассистента для своих продавцов, чтобы они могли осмысленно искать товары в каталоге товаров, когда общаются с клиентами. Ноукод как он есть.

За десять минут были заменены сразу и программисты, и опытный продавец. Правда, я так понимаю, это всё может иногда галлюционировать, так что какой-никакой мозг продавца пока что еще нужен.

Я тут сделал небольшое видео про ИИ-ассистентов и как можно за 15-20 минут сделать себе штуку под названием RAG, которая будет давать ответы, отталкиваясь от ваших данных.
https://youtu.be/4RFJx7rbN2E

Ответы на вопросы: один день из жизни CTO

Антон О. попросил написать сабж.

Когда я только-только стал engineering manager, я быстро понял, что вся муть про agile, власть команды и прочая скрам-ересь – это херня полная, потому что она приводит к тормозам, а скоростным компаниям нужна agility. Agility достигается менеджерами, которые херачат и культурой несидения на жопе ровно. Короче, главным навыком является управление, управление проектами, но в первую очередь - управление временем. Миллион людей будут с этим не согласны, будут находить тысячу причин не заниматься управлением даже своего времени, говорить что это стресс, что не для всех задач, и в этом канале уже неоднократно вспыхивали подобные срачики. Ну мне не надоедает в них участвовать и нести разумное-доброе-вечное, но пост не об этом, а о работе CTO.

Так вот, был я, значит, engineering manager и решил “потрекать свое время” - ну это натурально записать “один день из моей жизни”. Помечал всё, что делаю. К середине дня я понял, что поскольку я стараюсь не откладывать мелких дел - я на записи каких-то дел трачу время сравнимое с самим делом. Задумался, не херню ли я делаю, стал мелкие дела опускать. К концу дня я посмотрел на 3 листа A4 и решил, что там решительно нет ничего полезного для анализа, и что больше никогда такой фигней я заниматься не буду.

Мораль: один день даже у CTO (а у CTO тоже много сравнительно мелких дел) если он будет записан, состоит из такого количества “мусора”, что разбираться с ним будет бесполезно. Вот небольшой список того, что могло быть в таких записях. Тут нет хронологии - это просто пример, что могло бы оказаться в этом самом пресловутом “одном дне из жизни CTO”. Утро понедельника полет на работу в Лондон. Куча встреч по ongoing projects (10 встреч в день - легко, чем корпоративнее культура - тем больше встреч). Практика в пиццерии (у меня был онбординг в лондонской пиццерии - я работал там несколько дней, работал плохо и, мне кажется, сильно достал менеджера точки). Подготовка/апдейт презентаций по тех-стратегии. Обсуждение с командой продуктовой стратегии и hiring plan на год. Полет на встречу с акционерами, презентация hiring плана и бюджета на команду. Участие в партнерской конференции - встреча со студентами. Выступление в МФТИ на клубе выпускников. Выступление перед студентами МГУ/Бауманки. Вечер, чуваки из Макинзи позвали в караоке отмечать конец проекта. Intro-calls с кучей людей, не всегда полезных, но вдруг. Подготовка сложного увольнения - бриф с партнерами E&Y. 1:1 со всеми членами моей команды. Участие в ревью – финальные менеджерские оценки, калибрация. Подготовка/выступление на all hands. Понимате? Это я просто что-то написал более-менее интересно за три минуты, а сколько я упустил?

Короче, Антон, прости - но по-моему ты не должен этого хотеть. Тебе нужен не один день из жизни СТО, а один год из жизни CTO - но тебе его никто не напишет 🙂 Впрочем, я думаю, что предыдущий абзац твое любопытство хотя бы частично удовлетворил.

Если же подходить системно о том, из чего состоит работа CTO/CIO, в чем отличие от CIO, например - то я об этому уже писал:
https://news.1rj.ru/str/rybakalexey/5 - CTO не CTO I
https://news.1rj.ru/str/rybakalexey/7 - CTO не CTO II
https://news.1rj.ru/str/rybakalexey/8 - CTO vs CIO
https://news.1rj.ru/str/rybakalexey/9 - CTO vs CIO (продолжение)

Enjoy.

Вчера вышел релиз #go 1.23 - самый спорный релиз на моей памяти https://go.dev/doc/go1.23

В нём стали доступны функции-итераторы https://go.dev/doc/go1.23#language, добавление которых вызвало довольно много негативной реакции в сообществе https://www.gingerbill.org/article/2024/06/17/go-iterator-design/

Помимо пакета нового пакета iter в пакеты slices и maps много новых функций типа Backward, Chunk, Values, Keys и Collect

Так же в этом релизе добавлена функциональность сбора телеметрии тулчейна Go. Телеметрия отключена по умолчанию и собирает анонимную информацию о параметрах go и gopls (https://go.dev/doc/telemetry). Одно время обсуждения самой возможности были довольно бурными https://www.reddit.com/r/golang/comments/10z5ig1/googles_go_may_add_telemetry_reporting_thats_on/ . Телеметрия не затрагивает результат сборки.

Посмотреть на статистические выкладки телеметрии и скачать собранный датасет можно вот тут https://telemetry.go.dev/

Список багов, пойманных телеметрией https://github.com/golang/go/issues?q=label%3Agopls%2Ftelemetry-wins

Из менее противоречивых изменений мне приглянулись
⁃ Новый флаг go mod tidy -diff - печатает изменения, которые произойдут при go mod tidy и возвращает exit_code=1 если такие изменения есть. Сильно упрощает проверки в CI
⁃ Новый флаг go env -changed - печатает изменения в go env, сделанные с помощью -w
⁃ Упрощена работа с time.Timer и time.Ticker - теперь вызовов .Reset и .Stop достаточно для корректного сброса и остановки - не надо вытаскивать stale значения из каналов
⁃ Новый пакет unique, который позволяет интернировать comparable значения
⁃ Новый пакет structs с маркерным типом structs.HostLayout для контроля memory layout структур
⁃ В go.mod корневых модулей (не зависимостей) можно использовать директиву godebug (https://go.dev/doc/godebug), которая позволяет включать старое runtime поведение некоторых частей стандартной библиотеки. Например, новое поведение таймеров можно отключить вот так

godebug(
asynctimerchan=1
)


⁃ В net/http добавили много утилит для работы с cookie и поле Request.Pattern, которое содержит паттерн роута из http.Mux. Ждём когда chi будет выставлять его тоже
⁃ Новая функция os.CopyFS, которая копирует содержимое fs.FS в локальную директорию. Писать распаковщики zip никогда не было так просто!
⁃ Максимальная глубина стека для runtime/pprof увеличина до 128 фреймов (да, я упирался в глубину стека на трейсах 😔)
⁃ Новые функции atomic.And и atomic.Or (и комплиментарные методы), которые позволяют атомарно применять битовые маски

Интерактивные заметки к релизу https://antonz.org/go-1-23/

Фиганул статью на хабр про монокультуру в программировании: https://habr.com/ru/articles/838682/ Где рассказываю про то, как монокультура (использование одной технологии повсеместно) мешает и вредит проектам

Забавная статья. ChatGPT деминифицировал код.

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

Тогда он сначала попросил ChatGPT объяснить принцип работы, а потом просто сказал, мол, а сгенери-ка ты нормальный человеко-читаемый typenoscript.

И на его удивление, получилось просто почти идеально.

Т.е., гопчат сработал как деминификатор кода.

https://glama.ai/blog/2024-08-29-reverse-engineering-minified-code-using-openai

Среди программистов довольно часто встречаются перфекционисты. Чаще, чем в других профессиях.

А ты? Перфекционируешь небось?

Программа должна быть настолько гибкой и абстрактной, чтобы если что - можно было переделать паровоз в самолёт. С помощью напильника.

Импорты должны быть отсортированы по хитрым правилам. Перед return должен быть перевод строки, иначе мы все умрём. (Или что там у вас?)

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

Короче. Предлагаю лайфхак.

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

Баланс между гибкостью кода и стоимостью этой гибкости, например. Доведите его до идеала уже, перфекционисты. Или вы не перфекционисты, а лохи просто неряшливые, что у вас баланс не совершенен?

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

А если при этом думать о системе в целом, то это будет вообще мегаидеально. Прям можно идти на международные соревнования по перфекционизму

OpenAI сделали новую модель. В отличие от предыдущих, она не сразу выдает ответ, а пытается "порассуждать". В итоге результаты в математических и программерских тестах улучшились в разы.

https://openai.com/index/introducing-openai-o1-preview/

Дженерик алиасы типов в Go в 1.24 : что это и зачем они нужны

Представьте, что вы работаете над крупным проектом на Go, который развивается уже несколько лет. В какой-то момент вы понимаете, что структура пакетов, которую вы изначально выбрали, больше не отвечает потребностям проекта. Вам нужно перенести некоторые типы из одного пакета в другой. Звучит просто, верно? Но не тут-то было!

Проблема рефакторинга в больших проектах

Представим, что у вас есть популярный пакет oldpkg с типом User:

package oldpkg

type User struct {
    ID   int
    Name string
}

Теперь вы хотите перенести этот тип в новый пакет newpkg. Но ваш тип User используется в сотнях мест по всему проекту и в зависимых проектах. Как провести такой рефакторинг без боли?

Go 1.9 представил концепцию алиасов типов. Это позволяет нам создать новое имя для существующего типа без создания нового типа. Вот как это выглядит:

package newpkg

import "path/to/oldpkg"

type User = oldpkg.User

Теперь newpkg.User и oldpkg.User - это один и тот же тип. Мы можем постепенно обновлять использование oldpkg.User на newpkg.User по всему проекту, и компилятор будет счастлив.

Но что насчет дженериков?

С появлением дженериков в Go 1.18 возникла новая проблема. Как быть, если наш тип User использует параметры типа? До сих пор алиасы типов не поддерживали параметры типа. Но это изменится в Go 1.24

Дженерик алиасы типов

Представим, что наш тип User теперь дженерик:

package oldpkg

type User[T any] struct {
    ID   T
    Name string
}

В Go 1.24 мы сможем создать алиас для этого типа следующим образом:

package newpkg

import "path/to/oldpkg"

type User[T any] = oldpkg.User[T]

Это позволяет нам сохранить полную совместимость типов при переносе дженерик-типов между пакетами.

Когда это будет доступно?

В Go 1.23 вы можете включить поддержку дженерик алиасов типов с помощью флага GOEXPERIMENT=aliastypeparams.
В Go 1.24 (ожидается в начале 2025 года) эта функция будет включена по умолчанию.

Подробности здесь

Я принес. Гуманизм против «эффективного менеджмента». Почему заботиться о людях выгодно

Вы знаете, что я тот еще гуманист 🙂 Поэтому не мог пройти мимо этого лонгрида https://habr.com/ru/articles/816545/
Текст большой, так что наливайте чай-кофе, заводите один таймер pomodoro и погружайтесь.

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

Так что, граждане тимлиды, этот контент вам точно будет полезен.

Вышел PostgreSQL 17

Производительность:

Существенно улучшена работа с памятью. Вакуум теперь потребляет до 20 раз меньше памяти, что ускоряет его работу и снижает нагрузку на систему.
Запись при высокой конкурентной нагрузке стала быстрее в 2 раза благодаря оптимизации обработки WAL.
Улучшена производительность запросов с использованием условий IN для B-tree индексов.
Добавлена поддержка SIMD-инструкций (в том числе AVX-512) для ускорения вычислений.
Оптимизирована производительность COPY для экспорта больших объемов данных.

Для разработчиков:

Расширена поддержка JSON: добавлен JSON_TABLE для конвертации json в обычные таблицы PostgreSQL.
Появились новые конструкторы и функции для работы с json: JSON, JSON_SCALAR, JSON_SERIALIZE, JSON_EXISTS, JSON_QUERY, JSON_VALUE.
Улучшена команда MERGE: добавлена поддержка RETURNING и возможность обновления представлений.
EXPLAIN теперь показывает время, затраченное на локальное чтение и запись блоков, а также использование памяти.

Репликация и обновление:

Упрощен процесс обновления между мажорными версиями при использовании логической репликации. Теперь не нужно удалять слоты репликации при обновлении.
Добавлен контроль отказоустойчивости для логической репликации.
Представлен инструмент pg_createsubscriber для конвертации физической реплики в логическую.

Безопасность и управление:

Новые опции TLS для более гибкой настройки безопасности соединений.
Добавлена предопределенная роль pg_maintain для выполнения задач обслуживания.
Улучшены возможности резервного копирования: поддержка инкрементальных бэкапов в pg_basebackup.

Мониторинг и анализ:

Добавлено отображение прогресса при вакууме индексов.
Новое системное представление pg_wait_events для более детального анализа ожидающих сессий.

Я наверно слоупок, только сейчас узнал о программе dust, замене du

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

Запустил в папке с проектами, сразу нашел гигабайтные node_modules в старых проектах, прикольно.

подробнее тут (там куча полезных параметров)

Ставится просто brew install dust