Заблуждения о KPI в разработке

Тема "KPI в разработке" довольно обширна — в один пост всё не уместить. Буду раскрывать ее постепенно. Начнём с заблуждений, с которыми я встречался.

- Разработка — это креативный процесс и поэтому KPI для неё невозможен
- KPI подавляет креативность
- В больших компаниях классно выстроена разработка, там много всяких систем оценок, KPI и прочего, а вот "нам в маленьких" это слишком сложно сделать
- Не все аспекты работы можно измерить количеством
- У разработчиков в целом на слово KPI возникает буря эмоций и одно большое заблуждение

На самом деле заблуждений намного больше, но уже будет перебор для одного поста, так что начнём с этих.


Разработка — это креативный процесс и поэтому KPI для неё невозможен

Во-первых, работа разработчика — это не только и не столько креативный процесс. Конечно, бывает, надо что-то придумать, но в очень ограниченных рамках. И даже наоборот: "фантазёры" — это большая боль. В 99% случаев для решения задачи в проекте уже есть готовые подходы/компоненты/механизмы (плюс само собой подразумеваю, что разработчику дают какие-либо продуктовые требования), но фантазер просто тратит лишнее своё время на придумки и лишний кодинг, и потом время коллег на ревью его "фантазий". В итоге бизнес получает решение своей задачи сильно дороже, и к ней в придачу еще получает увеличение энтропии проекта (то есть удорожание будуших задач).
Во-вторых, надо понимать, что KPI для подобных профессий (это касается не только разработчиков, но и всю продуктовую команду и в целом не ограничивается IT направлением) — это дополнительный фактор, а не основной. Он не должен напрямую влиять на зарплату, как (условно) у продавца или маркетолога. Он должен показывать относительную динамику — лучше или хуже человек/команда поработали на этой неделе по сравнению с предыдущей? Если хуже — то узнаем о проблемах и исправляем их, если лучше — узнаем и закрепляем хорошие практики. В разработке вполне применим классический менеджемент. Он точно так же работает как и везде. Просто требует технических компетенций у этих самых "менеджеров". А у нас распространено, что ты либо технарь, либо менеджер. Мало, кто развивает оба набора компетенций и отсюда дальше большой "разрыв" в работе и коммуникации.


KPI подавляет креативность

Выше уже разобрали, что подавлять тут и нечего. Но я бы тут подсветил отдельно еще раз: KPI — вспомогательный инструмент, который нужен, чтобы помогать сделать процесс работы лучше, качественнее, эффективнее, комфортнее и так далее. KPI мешает тем, кто не умеет пользоваться инструментами и подстраивается под них (а таких людей много, к сожалению). Здоровый руководитель получает от инструмента пользу и адаптирует под свои потребности. У такого руководителя ничего там нигде "подавляться" не будет. Простой пример продавливания людей под инструмент — это scrum мастеры, OKR мастеры и прочие "мастеры". Зачастую они просто занимаются тем, что подстраивают всех под инструмент, даже если это не решает никакую проблему и даже если наоборот добавляет вреда. Но сразу оговорюсь — разумеется, есть и крутые, компетентные "мастер" специалисты. Они молодцы. Но, к сожалению, я на таких не натыкался, и можно предположить, что их довольно мало.


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

Бесплатные OpenSource альтернативы Amazon AWS, Heroku и Airtable

⇨ ubicloud — собственное облако, аналог Amazon AWS. Добавляете свои серверные мощности под управление ubicloud и дальше через интерфейс можно создавать шустрые виртуалки (с бесшовной миграцией между хостами и снэпшотами), лоад балансеры, управляемый postgres, виртуальная сеть, система доступов и так далее. Рекомендую ознакомиться и иметь в виду. Выглядит очень удобно и добротно. Отлично подойдёт, если у вас много проектов или большая IT инфраструктура внутри компании.

⇨ supabase — это более высокоуровневый инструмент, аналог Firebase. Здесь мы оперируем не железом, а юзерами, таблицами, хранилищем, удобным интерфейсом администрирования и так далее. Хорошо подойдёт, если у вас есть какой-то большой главный продукт/проект. Но в целом никто не мешает комбинировать и для каждого проекта разворачивать supabase на инфраструктуре под управлением ubicloud.

⇨ coolify — аналог Heroku. Оперирует проектами, серверами и кучей вспомогательных обвязок, типа Push To Deploy и все в этом духе. Думаю это уже больше для веб-студий, фрилансеров и прочего массового мелкого производства.

⇨ piku — более минималистичный и простой аналог Coolify/Heroku для Push To Deploy.

⇨ directus — автоматический конуструктор CMS, админок и бизнес-процессов, частично аналог Airtable. Если у вас есть база данных, то может быть полезно, чтобы не кодить лишние внутренние инструменты для команды.

⇨ nocodb — прямой аналог Airtable. Из любой базы делает удобные таблицы, таск трекеры, админки и т.д.

#opensource #open_source #aws #amazon #airtable

React Native: New Architecture

Если вы вдруг пропустили — React Native релизнул версию 0.76 с новой архитектурой, в которой избавились от узкого горлышка в виде Async Bridge.

Было:
React Renderer —> Async Bridge —> Native Renderer

Стало:
React Renderer —> Native Renderer

То есть раньше на телефоне, условно, запускался JS код, который по API отправлял запросы в написанный нативно Async Bridge, который в свою очередь нативно вызывал Native Renderer. При большом кол-ве событий это создавало узкое горлышко, из-за чего RN считался "медленным". Теперь же из JS кода генерируется нативный C++ модуль, который вызывает Native Renderer напрямую. Бонусом идёт возможность обращаться к native модулям синхронно.

Было:

// ❌ Sync callback from Native Module
nativeModule.getValue(value => {
  // ❌ value cannot reference a native object
  nativeModule.doSomething(value);
});

Стало:

// ✅ Sync response from Native Module
const value = nativeModule.getValue();

// ✅ value can be a reference to a native object
nativeModule.doSomething(value);

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

#mobile #react_native #react

Понравился чеклист по информационной безопасности для SaaS сервисов и в целом IT стартапов.
Даже если вы уверены, что у вас всё на высшем уровне и большая часть пунктов покажется банальной — все равно, скорее всего найдете для себя что-то, о чем забыли.

#информационная_безопасность

Какие инструменты я использую каждый день для диагностики linux серверов (в наших проектах их многие сотни).

▪️ CPU/RAM: top, htop, sar
▪️ Диск: df, du, dstat, iostat, iotop, fatrace, fio, ioping, hdparm, sar
▪️ Сеть: iftop, iptraf, netstat, iperf, nethogs, slurm, sar
▪️ Процесс: strace, ltrace, fatrace, ps, lsof

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

#linux #devops

Как использовать strace для диагностики linux серверов.

strace показывает все сигналы и системные вызовы (syscall) для выбранного процесса. Он не покажет вам логику выполняемого кода, но по системным вызовам всё же можно понять многое, что происходит внутри. Стандартный способ использования strace -ttyfkp 123. Не пугаемся от обилия флагов, тут всё просто. Флаги -tt добавляют к выводу timestamp (так проще ориентироваться в большом потоке сообщений), -y показывает человекочитаемые названия файловых дескрипторов вместо чисел. Флаг -f означает, что собирать инфомрацию будем в том числе со всех дочерних процессов (удобно подключиться к родительскому и собирать сразу всё), а -k покажет stacktrace каждого вызова (его можно можно не включать без необходимости). И в последнем параметре -p 123 указываем PID нужного нам процесса (в данном случае 123).

Для чего это может пригодиться:

▪️ Узнать, чем занят зависший или потребляющий много ресурсов процесс. Например, может быть read/write или wait какого-то сокета к БД или внешнему сервису. Также часто бывает спам каких-нибудь mmap (выделение памяти), что намекает на какое-то большое количество создаваемых объектов или бесконечный цикл и тп.
▪️ Убедиться, что процесс получает ваш запрос. Например, в большой распределенной системе довольно сложно понять, пришёл ли запрос на нужный нам веб сервер или другой софт. Можно конечно идти по следам запроса от начала и до конца, проходя через десяток слоев абстракций и сервисов, но гораздо быстрее сразу подключиться к финальной точке назначения и просто посмотреть пришло что-то или нет.
▪️ Посмотреть текст входящего запроса/ответа или логи. Помимо того, чтобы просто понять пришёл запрос или нет, мы сразу можем увидеть текст запроса и текст ответа. Также часто бывают ситуации, когда проще прямо в strace увидеть, что какой-то софт пишет что-то в лог и где этот лог находится. На более менее крупных и нагруженных серверах у нас с десяток мест, куда пишут логи разные сервисы и системы. Например, логи могут идти в стандартный /var/log, либо в домашнюю директорию сервиса, либо в stdout docker контейнера, либо могут даже сохраняться внутри docker контейнера в файл. А еще могут уходить в syslog или в journal или даже в /dev/null. В общем, в реальной жизни в /var/log логи оказываются реже всего. В такой ситуации strace — отличная отправная точка.
▪️ Найти причину, почему процесс/запрос падает фаталом. Иногда сталкиваюсь с ситуациями, когда даже какой-нибудь nginx (!) не отдает ответ на запрос и ничего не пишет в лог. Здесь сразу на помощь приходит strace — можно посмотреть, что предшествовало ошибке и как вообще ошибка выглядела глазами syscall.

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

#linux #devops #strace

Охренеть, какие объемы у Cloudflare.

Ребята логируют 50 триллионов (45 петабайт) событий в день. Это 1.5 квадриллиона событий в месяц. Об этом они рассказали в разборе недавнего инцидента, где сервис Cloudflare Logs вышел из строя на несколько часов.

Тем временем раздел Trending на Github.

Наткнулся на статью про валидацию емейлов через regexp.

Не сосчитать, сколько раз я видел странные и безуспешные попытки разработчиков написать свою валидацию емейл адресов. Практически никто не читает RFC. Впрочем, обычно эти документы не особо читаемы, так что я тоже в этой лодке. Но можно же хотя бы просто загуглить перед тем как писать какой-то код общего назначения. Ведь он уже миллион раз был написан до вас и всех собак там уже съели. Но разработчики (и не только джуны) зачем-то продолжают тратить своё время на написание заведомо некачественного и ошибочного кода.

На картинке выше только часть регэкспа, который написали энтузиасты в попытке соблюсти RFC. А вот здесь человек попытался реализовать проверку на php. Если ваша проверка не похожа на эту, то даже не показывайте мне её. ¯\_(ツ)_/¯

Как же правильно валидировать введенный юзером емейл адрес? — Просто проверить наличие @ в нём. И всё. Можно еще проверить длинну по RFC, но даже по ней идут споры и большого смысла в этом нет.

Мало ли вы не знали про такой инструмент. В Snack можно быстренько накидать простое кроссплатформенное мобильное приложение на React Native. Прямо в браузере можно редактировать код и сразу видеть результат в Anroid и iOS эмуляторах с live reload. Также можно в пару кликов отсканировать QR-код и получить приложение с live reload на своем мобильном, продолжив кодинг всё в том же браузере. Не нужно ни регистраций, ни СМС, ни даже какого-либо локального dev-окружения.

Как использовать ltrace, fatrace, ps, lsof для диагностики linux серверов.

⇨ ltrace — очень похоже на strace, но вместо syscall показывает обращения к динамически подключенным библиотекам (glibc и других). Использовать можно также указывая PID процесса через -p. Использую в дополнение к strace, когда его становится не достаточно и надо взглянуть на внутренности процесса немного под другим углом.
⇨ fatrace — выводит все обращения к файлам как для указанного процесса, так и в целом для всей системы. Можно фильтровать как по процессу (чтобы посмотреть как он нагружает диск и какие файлы использует), так и по конкретному файлу (чтобы узнать, какие процессы к нему обращаются). Также удобно использовать при поиске того, что нагружает диск в целом.
⇨ ps — инфа по текущим запущенным процессам. Стандартное использование ps ax для дальнейшей обработки в awk. Например, прибиваем все python скрипты: ps ax | grep python | awk '{print $1}' | xargs kill. Также можно просто написать ps aux для того, чтобы посмотреть, что запущено не так давно (поиск зловредов или каких-то аномалий). Флагов очень много, например, f чтобы увидеть дерево процессов или e чтобы увидеть ENV переменные для каждого процесса.
⇨ lsof — показывает открыте файлы. Может использоваться как для конкретного процесса (-p PID), так и в целом по всему серверу. По процессу используем, чтобы посмотреть сколько файлов он открывает и что это за файлы. Например, чтобы найти где лежат конфиги, логи и тп. Открытые сокеты тоже показывает, так что можно увидеть куда открыты коннекты и на чем сейчас завис процесс (долгий HTTP или БД запрос). Без указания конкретного процесса полезно, например, lsof | grep deleted, чтобы найти открытые файлы, которые были удалены с диска. При этом, пока такой мертвый файл висит открытым, то место на диске не освобождается, так что иногда полезно проверить нет ли какого-то зависшего мусора.

OpenAI выпустили ChatGPT Agent

Этот агент может не просто выдать вам ответ на вопрос, но и выполнить задачи на вашем компьютере: поискать что-то через браузер и отправить заказ, написать код, выполнить команды в терминале, почистить календарь и так далее. То есть это смесь deep research (поиск в интернете) и agent (управление компьютером).

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

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

Тем временем уже более получаса продолжается глобальный сбой сети Cloudflare. Немалая часть крупнейших сервисов (например, ChatGPT) лежит вместе с ним.

Буду ждать incident report. Поделюсь, если будет что-то интересное.

Вчера OpenAI выпустили десктопное приложение Codex

Раньше codex был только консольный, теперь появился визуальный вариант (аналог Cursor).
Из интересного — возможность запускать агентов изолированно друг от друга в своих "worktree's", чтобы они не мешали друг другу при работе над одним проектом. Плюс более тонкий выбор моделей, чем в консоли. Успел немного попользоваться, пока полет нормальный.

Есть еще автоматизации (запуск задач по расписанию). Но это я пока не придумал, для чего можно в реальности использовать.

Не успел Anthropic объявить о релизе модели Opus 4.6, как OpenAI сразу ответили релизом GPT-5.3-Codex.

Жестко.

Приступаем к тестированию. :)

ИИ отберет у людей все рабочие места? Нам всем конец?

Всё чаще вижу подобные пессимистичные прогнозы на будущее.

Что я думаю об этом?

Проблема действительно имеет место быть, но не все так однозначно. Если люди останутся без работы, то они останутся и без денег. Тогда некому будет что-либо покупать. И тогда деньги не заработают эти "ИИ бизнесы". То есть довольно вероятно, что в будущем экономика самостоятельно сбалансируется. ИИ будет отбирать старый низкоуровневый пул задач, но высокоуровневые задачи (постановка целей, ответственность за результат, запуск и отладка агентов и тп) останутся за людьми. Кажется, что сильнее всего пострадает средний класс (так как его работа будет автоматизирована полностью). Но скорее всего он просто переедет на офлайн занятость.

Пока рано сгущать краски. Сейчас я вижу реальную проблему только в том, что профессии отмирают моментально и люди не успевают адаптироваться. Вот буквально еще в сентябре-октябре ИИ был помощником для кодинга (см разницу между кодингом и программированием), просто упрощал и ускорял его. А в ноябре с релизом 5.1-codex и opus 4.5 кодинг стал полностью автоматическим и не требующим участия человека. Огромное количество людей в один миг лишились профессии. Спасает только корпоративная инерция. Даже у нас сейчас во "взрослых" проектах остается еще много кодеров (хоть найм их уже и остановлен). В новых проектах у нас кодеров уже нет изначально.

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

Последний раз я писал код руками в ноябре.

Это магия! Сегодня на практике увидел, каким будет софт уже в ближайшем будущем.

OpenAI релизнули приложение Symphony. Тут не важно, что оно делает (это тема для отдельного поста). Важна инструкция по установке.
Вместо установочного файла мы получаем инструкцию для нашего агента, как ему закодить это приложение.

Для установки Symphony надо написать агенту:

Реализуй Symphony в соответствии со спецификацией: https://github.com/openai/symphony/blob/main/SPEC.md

И всё. Агент берет в работу ТЗ и делает приложение, на каком захотите языке программирования.
Причем сразу на ходу можно, что угодно поменять под себя. Например, Symphony заточено на работу с таск трекером Linear. Я таким не пользуюсь и сказал, чтобы он сделал интеграцию с другим. Также, когда начал тестировать приложение, мне не хватило некоторых функций, и я попросил их добавить тоже.

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

Наткнулся на интересную статью от Google с таким выводом: чтобы LLM отвечала лучше, нужно просто повторить промпт два раза.

Авторы статьи протестировали подход на разных моделях и задачах и получили заметный прирост качества у non-reasoning моделей. Для reasoning моделей прирост не такой большой, но как минимум хуже не делает.

Например, есть промпт:

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

Надо повторить его 2 раза и получим более качественный результат:

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

Почему так работает?

LLM обрабатывает текст слева направо постепенно. Первая часть фразы обрабатывается без контекста завершающей части. То есть LLM начинает обрабатывать слово "изобретение" до того, как увидит условие про "изменение повседневной жизни". Конечно, когда LLM дойдёт до нужного места, она скорректирует веса и учтет новый текст. Но повторный проход увеличит шансы корректного срабатывания. Особенно это может повлиять на задачи с точными инструкциями.

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

OpenAI релизнули Codex 2.0.

Из интересного:
• встроенный быстрый браузер с возможностью комментирования конкретных элементов (это есть у разных AI IDE, но не было у простых агентов)
• встроенное управление остальными приложениями на десктопе

Остальное можно почитать здесь.

И вдогонку обновление от Anthropic — Claude Design

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

Этого прям очень не хватало.