Т.е. nix просто не предназначен для этого, он решает другие проблемы, которые mise решить не в состоянии. Да, в nix ногами можно запихать и такое тоже, но это будет больно и неудобно. Те проблемы, которые решает mise, намного удобнее решать именно через mise, в т.ч. используя его совместно с nix-shell если нужен контроль окружения уровня C, который mise реализовать не в состоянии.
Возьмём типовой пример: разработчику локально нужно иметь возможность переопределить номер порта, который используется в url нужной проекту.
Вот как ИИ предлагает решать эту задачу на nix:
shell.nix
{ pkgs ? import <nixpkgs> {}
, port ? 8080
}:
let
url = "http://localhost:${toString port}";
in
pkgs.mkShell {
shellHook = ''
export PORT=${toString port}
export URL=${url}
'';
}
shell.local.nix
let
base = import ./shell.nix;
in
base {
port = 9090;
}
А вот как это делается на mise:
mise.toml
[env]
PORT = '8080'
URL = { value = 'http://localhost:$PORT', tools = true }
mise.local.toml
[env]
PORT = '9090'
Поддержки работы с секретам в nix вообще нет, предлагается запускать утилиту для расшировки (age/sops/gpg/etc.) и как-то подставлять её вывод в значение переменной окружения.
Те простыни, которые ИИ показывает в формате nix для того, чтобы реализовать запуск задачи "test" при которой выполнится команда go test -race ./... мне сюда даже копипастить страшно. Ну т.е. nix формально это может, но это настолько больно и длинно, что проще (и рекомендуется) вызывать стороннюю запускалку задач вроде make/taskfile/just/свой скрипт или собственно mise.
Не совсем так. Учитывая, что в большинстве случаев asdf заменяется на mise как drop-in, т.е. просто вместо команды asdf выполняете mise с теми же аргументами, то все эти плюсы начинают выглядеть намного интереснее даже если пока нет понимания зачем они лично Вам - просто потому, что их можно получить практически бесплатно.
По скорости - команда выполняется не раз в год, а регулярно. В случае asdf - это запуск любого инструмента, т.к. они все запускаются через shims. В старом asdf на шелле это тормозило вообще неприлично, в новом asdf на go уже приемлемо, но mise всё-равно быстрее. Но да, есть люди которых такие задержки бесят, а есть те, кто их не замечает.
Безопасность экосистемы asdf - это реальная проблема, потому что авторы asdf-плагинов это не авторы самой asdf и не авторы нужной утилиты, а абсолютно случайные товарищи, которые получают возможность выполнить любой шелл-код на вашем компе. Эти товарищи - совершенно лишние в цепочке доверия поставкам.
Больше инструментов сами по себе не установятся, просто через mise есть возможность установить такие инструменты, которые asdf устанавливать не умеет.
Миллион инструментов для работы с переменными окружения страдают от кучи разных проблем, которых нет в mise.
Nix реально нужен в проектах со сложными зависимостями от уровня C (системные библиотеки, компилятор C, etc.) - и через mise это контролировать невозможно. Но и там в плане юзабилити есть смысл использовать mise (в т.ч. и потому, что nix не особо позволяет управлять переменными окружения/секретами и задачами проекта). Просто запускать mise в этом случае нужно будет внутри nix-shell, ну и плюс можно будет упростить конфиг nix, ограничив его исключительно тем, что нельзя устанавливать/контролировать через mise.
Что до CD - если напишете логику деплоя в задаче "deploy", то на CI деплой запустится командой mise run deploy. В смысле, ничего именно mise-специфичного в CD нет.
Есть коротко: безопаснее, быстрее, удобнее, устанавливает больше инструментов, плюс поддержка переменных окружения и задач. Изначально mise разрабатывалась как drop-in replacement именно для asdf (в то время mise называлась rtx, если не путаю).
Я сам люблю unix way, но иногда ради юзабилити приходится от него отходить, и это нормально - unix way это не абсолютный идеал для вообще всех приложений.
Впрочем, лично для меня не очевидно, что в случае mise действительно необходимо в одной утилите объединить весь этот функционал. И меня немного беспокоит дальнейшее расширение её функционала. Именно поэтому я в статье не писал, что mise идеальна, но я писал, что она задала минимальную планку для будущих утилит в этом классе - потому что mise первая, кто действительно хорошо решил все три задачи.
Вообще, часть функционала автор mise реализует в отдельных утилитах: usage, fnox, pitchfork; равно как и использует чужие утилиты: watchexec. Ну т.е. про unix way он в курсе, и для объединения трех разных функций в mise возможно есть веские причины.
Вы должны были мотивировать как-то отказ от простых утилит
Это не совсем так. Лично я до mise никакими из этих утилит не пользовался. Пытался, но довольно быстро обнаруживал серьёзные проблемы, из-за чего отказывался от них и возвращался к самопальным решениям (env.sh, скрипты, tools.go). mise - первая утилита без серьёзных проблем, из всех что я видел. Поэтому статья мотивирует не отказ от других утилит, а использование именно mise. Более того, по этой причине я ничего не написал про совместимость с другими утилитами (в основном asdf и direnv), которую старается поддерживать mise для упрощения миграции.
Честно говоря, я просто не хотел превращать статью в перечисление тучи заменяемых утилит с описанием проблем каждой. Но, если хотите, вот краткий список:
Установка/обновление инструментов: asdf, aqua, nvm, pyenv, rbenv, go get -tool, …
Настройка конфигурации: direnv, dotenv, env.sh, …
Выполнение задач проекта: make, taskfile, just, mage, ./scripts/test, …
И это только для основного функционала. А помимо этого есть ещё поддержка секретов, автозапуск задач при изменении файлов - и для этого тоже есть существующие утилиты, которые заменяет mise.
В том-то и дело, что упомянутые в статье задачи нужно решать на всех проектах, и при этом полно решений, которые как-то эти задачи решают - но обычно они это делают не очень хорошо, ограничено или специфичным для конкретного языка способом. Например, для того же .env до сих пор нет единого стандарта, что в нём можно делать более сложного чем A=5. Ключевое отличие mise как раз в том, что она делает сразу всё и делает это правильно и очень гибко. Т.е. на сегодня это объективно лучшее решение, на которое действительно есть смысл перейти.
Что касается разъезжающихся версий у разрабов - если человек по каким-то причинам не обновляет инструментарий, ему утилиты не помогут.
Во-первых, утилиты помогут - об этом и речь в статье. А во-вторых тупым обновлением инструментария можно обойтись если работаешь над единственным проектом. А если проектов несколько, то у всех будут свои требования к инструментарию, и соблюдать их без помощи таких утилит будет крайне сложно.
Ну, выбор не велик - либо "ещё одна зависимость" либо бардак. Makefile не поставит используемые утилиты нужных проекту версий, не задаст переменные окружения и секреты проекта. Задачи описать в Makefile можно, но, будем откровенны, это не особо удобно, и это не основная задача make, а скорее misuse. В результате плюс к Makefile появляются .env или env.sh и дополнительные инструкции в README описывающие какие утилиты нужно самостоятельно установить для работы с проектом. Дальше версии этих утилит у разных разработчиков и на CI разъезжаются, что периодически создаёт странные проблемы. Утилиты, которые призваны эти проблемы порешать (asdf, direnv, taskfile, …) решают только часть да ещё и сами новые проблемы привносят. На этом фоне mise приятно выделяется. Но если не вникать в детали - то да, будет ровно такое впечатление, как Вы сказали.
Но я экспериментировал и на несколько месяцев отпускал поводья. Команда встаёт колом просто.
Тут одно из двух: либо команда в принципе не способна самостоятельно работать, либо им это отбил текущий стиль управления. Первое встречается редко, это должно было либо "повезти" при найме, либо команда прошла многолетний "отрицательный отбор", когда способные на самостоятельную работу просто не выдерживали и увольнялись, а оставались те, кому норм. В первом случае придётся менять всю команду, во втором помимо самоустранения необходимо нанять нового сильного тимлида практикующего другой стиль управления - если, конечно, нужно чтобы команда начала работать самостоятельно.
Команда сегодня почти уже не нужна. Всегда код пишут 1-2 самых сильных, а остальные - обуза.
Пока продукт небольшой - так было всегда. А вот когда продукт начинает активно развиваться, то 1-2 сильных разработчиков резко перестаёт хватать. Да, сегодня, если эти разработчики успешно освоят LLM, то они смогут выдавать больше результата (того же качества) в месяц. Но больше - всё-таки не в разы, по разным оценкам это 20%+. Потому что всё-равно нужно тщательно продумывать архитектуру, постановку задач и внимательно ревьювить код выдаваемый LLM. Объективно можно рассчитывать максимум на то, что команда из 2-х сильных разработчиков будет выдавать результат как будто их там таких 3, а не 2.
Помимо роста продукта нужда в команде обычно возникала ещё и потому, что во-первых не всем удавалось нанять тех самых 1-2 реально сильных, и во-вторых для защиты от bus factor. И вот это пока никуда не делось. Без контроля сильного разработчика LLM будет выдавать мусор очень среднего уровня, и bus factor тоже никуда не делся.
Если, как в Вашем случае, сильный разработчик одновременно владелец компании, и продукт достаточно небольшой чтобы он лично успевал его развивать, то да, команда особо не нужна (особенно если перекинуть всю рутину на LLM). Только вот есть проблема: шансы что бизнес будет развиваться при таком подходе стремятся к нулю. Потому что владелец либо будет тратит свои силы на бизнес, либо на код. Если он будет заниматься бизнесом, то код придётся писать кому-то другому, плюс резко увеличивается шанс, что с развитием бизнеса понадобится больше (сильных) разработчиков чтобы успевать развивать продукт. А если он будет заниматься кодом, то вполне реально поддерживать текущий уровень бизнеса, но не более того.
Всё верно, только одновременно с этим ещё крайне важно не убивать мотивацию команды. Иначе можно прийти к понятной и управляемой системе с единственным разработчиком в команде, что само по себе сильно замедлит разработку.
"Тимлид должен кодить" - это не про то, что он должен всё ревьювить круче всех, обучать и быть параллельно техлидом, а про то, что он должен иметь адекватное представление о рабочих процессах, проблемах и подходах к их решению. Если не кодить, то года за 3 можно сильно оторваться от реальности. Просто вспомните, как все писали код 3 года назад (без LLM), как пишут сейчас, и как это повлияло на рабочие процессы - и представьте, что тимлид всё это пропустил, потому что вместо того, чтобы лично пощупать LLM он ходил на созвоны и отбивал фичереквесты…
Жёсткие ревью PR с десятками замечаний и переделкой по 4 раза могут быть крайне полезны для развития и обучения команды, и давать кратный рост производительности команды. А могут душить инициативу команды и вести к её выгоранию и увольнению. Это вопрос софт-скиллов того, кто такие ревью делает - он должен учитывать много факторов: есть ли бизнес-возможность отложить мерж этого PR ради обучения, есть ли время у самого ревьювера заниматься обучением во время этого ревью, готов ли автор PR обучаться прямо в рамках работы над этим PR… ну и сдерживать собственную вкусовщину, потому что требовать чтобы другие писали ровно как ты - бессмысленно и вредно.
Доверие команде "не глядя" может идеально работать в сильной команде и полностью провалиться в слабой (равно как и в команде увлёкшейся вайб-кодингом и пользующейся отсутствием жёстких ревью чтобы быстро мержить мусор выдаваемый LLM).
Иными словами, как лучше - жёсткие ревью или доверие команде не глядя в код - сильно зависит от конкретной команды. Но, в любом случае, тимлид должен кодить. ;-)
У меня KeePassXC плюс его же браузерный плагин на десктопе, плюс Keepass2Android на телефоне, синхронизация через Dropbox - всё вместе даёт вполне неплохой UI, интеграции с браузерами и мобильными приложениями. Поддержка TOTP, кастомных полей, разных типов записей и т.п. тоже есть. В следующей версии KeePassXC 2.8 ожидается поддержка FreeDesktop Secret Service API - чтобы можно было использовать базу KeePass как штатное хранилище секретов ОС и поддерживающих его приложений.
Это всё не выглядит реальными проблемами безопасности. Первая и третья ссылки про то, что имея root доступ к устройству можно получить данные всех приложений - это факт, но с этим ничего сделать невозможно и это касается любых приложений. Вторая про возможность детектить проксик, что не является уязвимостью Signal (и не то, чтобы вообще являлось уязвимостью в принципе).
А почему именно Opus? Sonnet вроде бы не принципиально слабее, но в разы дешевле. Было бы интересно сравнить и его тоже - высока вероятность, что получим 80+ очков при стоимости сравнимой с GLM-4.7.
Т.е. nix просто не предназначен для этого, он решает другие проблемы, которые mise решить не в состоянии. Да, в nix ногами можно запихать и такое тоже, но это будет больно и неудобно. Те проблемы, которые решает mise, намного удобнее решать именно через mise, в т.ч. используя его совместно с nix-shell если нужен контроль окружения уровня C, который mise реализовать не в состоянии.
Возьмём типовой пример: разработчику локально нужно иметь возможность переопределить номер порта, который используется в url нужной проекту.
Вот как ИИ предлагает решать эту задачу на nix:
shell.nixshell.local.nixА вот как это делается на mise:
mise.tomlmise.local.tomlПоддержки работы с секретам в nix вообще нет, предлагается запускать утилиту для расшировки (age/sops/gpg/etc.) и как-то подставлять её вывод в значение переменной окружения.
Те простыни, которые ИИ показывает в формате nix для того, чтобы реализовать запуск задачи "test" при которой выполнится команда
go test -race ./...мне сюда даже копипастить страшно. Ну т.е. nix формально это может, но это настолько больно и длинно, что проще (и рекомендуется) вызывать стороннюю запускалку задач вроде make/taskfile/just/свой скрипт или собственно mise.Не совсем так. Учитывая, что в большинстве случаев asdf заменяется на mise как drop-in, т.е. просто вместо команды asdf выполняете mise с теми же аргументами, то все эти плюсы начинают выглядеть намного интереснее даже если пока нет понимания зачем они лично Вам - просто потому, что их можно получить практически бесплатно.
По скорости - команда выполняется не раз в год, а регулярно. В случае asdf - это запуск любого инструмента, т.к. они все запускаются через shims. В старом asdf на шелле это тормозило вообще неприлично, в новом asdf на go уже приемлемо, но mise всё-равно быстрее. Но да, есть люди которых такие задержки бесят, а есть те, кто их не замечает.
Безопасность экосистемы asdf - это реальная проблема, потому что авторы asdf-плагинов это не авторы самой asdf и не авторы нужной утилиты, а абсолютно случайные товарищи, которые получают возможность выполнить любой шелл-код на вашем компе. Эти товарищи - совершенно лишние в цепочке доверия поставкам.
Больше инструментов сами по себе не установятся, просто через mise есть возможность установить такие инструменты, которые asdf устанавливать не умеет.
Миллион инструментов для работы с переменными окружения страдают от кучи разных проблем, которых нет в mise.
Nix реально нужен в проектах со сложными зависимостями от уровня C (системные библиотеки, компилятор C, etc.) - и через mise это контролировать невозможно. Но и там в плане юзабилити есть смысл использовать mise (в т.ч. и потому, что nix не особо позволяет управлять переменными окружения/секретами и задачами проекта). Просто запускать mise в этом случае нужно будет внутри nix-shell, ну и плюс можно будет упростить конфиг nix, ограничив его исключительно тем, что нельзя устанавливать/контролировать через mise.
Интеграция с CI обычно в одну-две строки в конфиге CI: https://mise.jdx.dev/continuous-integration.html
Что до CD - если напишете логику деплоя в задаче "deploy", то на CI деплой запустится командой
mise run deploy. В смысле, ничего именно mise-специфичного в CD нет.Есть коротко: безопаснее, быстрее, удобнее, устанавливает больше инструментов, плюс поддержка переменных окружения и задач. Изначально mise разрабатывалась как drop-in replacement именно для asdf (в то время mise называлась rtx, если не путаю).
Вот детальное сравнение с asdf: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
Я сам люблю unix way, но иногда ради юзабилити приходится от него отходить, и это нормально - unix way это не абсолютный идеал для вообще всех приложений.
Впрочем, лично для меня не очевидно, что в случае mise действительно необходимо в одной утилите объединить весь этот функционал. И меня немного беспокоит дальнейшее расширение её функционала. Именно поэтому я в статье не писал, что mise идеальна, но я писал, что она задала минимальную планку для будущих утилит в этом классе - потому что mise первая, кто действительно хорошо решил все три задачи.
Вообще, часть функционала автор mise реализует в отдельных утилитах: usage, fnox, pitchfork; равно как и использует чужие утилиты: watchexec. Ну т.е. про unix way он в курсе, и для объединения трех разных функций в mise возможно есть веские причины.
Это не совсем так. Лично я до mise никакими из этих утилит не пользовался. Пытался, но довольно быстро обнаруживал серьёзные проблемы, из-за чего отказывался от них и возвращался к самопальным решениям (env.sh, скрипты, tools.go). mise - первая утилита без серьёзных проблем, из всех что я видел. Поэтому статья мотивирует не отказ от других утилит, а использование именно mise. Более того, по этой причине я ничего не написал про совместимость с другими утилитами (в основном asdf и direnv), которую старается поддерживать mise для упрощения миграции.
Честно говоря, я просто не хотел превращать статью в перечисление тучи заменяемых утилит с описанием проблем каждой. Но, если хотите, вот краткий список:
Установка/обновление инструментов: asdf, aqua, nvm, pyenv, rbenv, go get -tool, …
Настройка конфигурации: direnv, dotenv, env.sh, …
Выполнение задач проекта: make, taskfile, just, mage, ./scripts/test, …
И это только для основного функционала. А помимо этого есть ещё поддержка секретов, автозапуск задач при изменении файлов - и для этого тоже есть существующие утилиты, которые заменяет mise.
В том-то и дело, что упомянутые в статье задачи нужно решать на всех проектах, и при этом полно решений, которые как-то эти задачи решают - но обычно они это делают не очень хорошо, ограничено или специфичным для конкретного языка способом. Например, для того же
.envдо сих пор нет единого стандарта, что в нём можно делать более сложного чемA=5. Ключевое отличие mise как раз в том, что она делает сразу всё и делает это правильно и очень гибко. Т.е. на сегодня это объективно лучшее решение, на которое действительно есть смысл перейти.Во-первых, утилиты помогут - об этом и речь в статье. А во-вторых тупым обновлением инструментария можно обойтись если работаешь над единственным проектом. А если проектов несколько, то у всех будут свои требования к инструментарию, и соблюдать их без помощи таких утилит будет крайне сложно.
Ну, выбор не велик - либо "ещё одна зависимость" либо бардак. Makefile не поставит используемые утилиты нужных проекту версий, не задаст переменные окружения и секреты проекта. Задачи описать в Makefile можно, но, будем откровенны, это не особо удобно, и это не основная задача make, а скорее misuse. В результате плюс к Makefile появляются
.envилиenv.shи дополнительные инструкции в README описывающие какие утилиты нужно самостоятельно установить для работы с проектом. Дальше версии этих утилит у разных разработчиков и на CI разъезжаются, что периодически создаёт странные проблемы. Утилиты, которые призваны эти проблемы порешать (asdf, direnv, taskfile, …) решают только часть да ещё и сами новые проблемы привносят. На этом фоне mise приятно выделяется. Но если не вникать в детали - то да, будет ровно такое впечатление, как Вы сказали.У такого подхода уже есть и название (Spec-Driven Development) и готовые реализации, напр. от GitHub: https://github.com/github/spec-kit.
Всё верно. CTO - это не тимлид. Тимлид должен писать код, CTO не должен писать код.
Тут одно из двух: либо команда в принципе не способна самостоятельно работать, либо им это отбил текущий стиль управления. Первое встречается редко, это должно было либо "повезти" при найме, либо команда прошла многолетний "отрицательный отбор", когда способные на самостоятельную работу просто не выдерживали и увольнялись, а оставались те, кому норм. В первом случае придётся менять всю команду, во втором помимо самоустранения необходимо нанять нового сильного тимлида практикующего другой стиль управления - если, конечно, нужно чтобы команда начала работать самостоятельно.
Пока продукт небольшой - так было всегда. А вот когда продукт начинает активно развиваться, то 1-2 сильных разработчиков резко перестаёт хватать. Да, сегодня, если эти разработчики успешно освоят LLM, то они смогут выдавать больше результата (того же качества) в месяц. Но больше - всё-таки не в разы, по разным оценкам это 20%+. Потому что всё-равно нужно тщательно продумывать архитектуру, постановку задач и внимательно ревьювить код выдаваемый LLM. Объективно можно рассчитывать максимум на то, что команда из 2-х сильных разработчиков будет выдавать результат как будто их там таких 3, а не 2.
Помимо роста продукта нужда в команде обычно возникала ещё и потому, что во-первых не всем удавалось нанять тех самых 1-2 реально сильных, и во-вторых для защиты от bus factor. И вот это пока никуда не делось. Без контроля сильного разработчика LLM будет выдавать мусор очень среднего уровня, и bus factor тоже никуда не делся.
Если, как в Вашем случае, сильный разработчик одновременно владелец компании, и продукт достаточно небольшой чтобы он лично успевал его развивать, то да, команда особо не нужна (особенно если перекинуть всю рутину на LLM). Только вот есть проблема: шансы что бизнес будет развиваться при таком подходе стремятся к нулю. Потому что владелец либо будет тратит свои силы на бизнес, либо на код. Если он будет заниматься бизнесом, то код придётся писать кому-то другому, плюс резко увеличивается шанс, что с развитием бизнеса понадобится больше (сильных) разработчиков чтобы успевать развивать продукт. А если он будет заниматься кодом, то вполне реально поддерживать текущий уровень бизнеса, но не более того.
Всё верно, только одновременно с этим ещё крайне важно не убивать мотивацию команды. Иначе можно прийти к понятной и управляемой системе с единственным разработчиком в команде, что само по себе сильно замедлит разработку.
"Тимлид должен кодить" - это не про то, что он должен всё ревьювить круче всех, обучать и быть параллельно техлидом, а про то, что он должен иметь адекватное представление о рабочих процессах, проблемах и подходах к их решению. Если не кодить, то года за 3 можно сильно оторваться от реальности. Просто вспомните, как все писали код 3 года назад (без LLM), как пишут сейчас, и как это повлияло на рабочие процессы - и представьте, что тимлид всё это пропустил, потому что вместо того, чтобы лично пощупать LLM он ходил на созвоны и отбивал фичереквесты…
Жёсткие ревью PR с десятками замечаний и переделкой по 4 раза могут быть крайне полезны для развития и обучения команды, и давать кратный рост производительности команды. А могут душить инициативу команды и вести к её выгоранию и увольнению. Это вопрос софт-скиллов того, кто такие ревью делает - он должен учитывать много факторов: есть ли бизнес-возможность отложить мерж этого PR ради обучения, есть ли время у самого ревьювера заниматься обучением во время этого ревью, готов ли автор PR обучаться прямо в рамках работы над этим PR… ну и сдерживать собственную вкусовщину, потому что требовать чтобы другие писали ровно как ты - бессмысленно и вредно.
Доверие команде "не глядя" может идеально работать в сильной команде и полностью провалиться в слабой (равно как и в команде увлёкшейся вайб-кодингом и пользующейся отсутствием жёстких ревью чтобы быстро мержить мусор выдаваемый LLM).
Иными словами, как лучше - жёсткие ревью или доверие команде не глядя в код - сильно зависит от конкретной команды. Но, в любом случае, тимлид должен кодить. ;-)
Вот зачем столько слов, когда можно было обойтись одной картинкой:
У меня KeePassXC плюс его же браузерный плагин на десктопе, плюс Keepass2Android на телефоне, синхронизация через Dropbox - всё вместе даёт вполне неплохой UI, интеграции с браузерами и мобильными приложениями. Поддержка TOTP, кастомных полей, разных типов записей и т.п. тоже есть. В следующей версии KeePassXC 2.8 ожидается поддержка FreeDesktop Secret Service API - чтобы можно было использовать базу KeePass как штатное хранилище секретов ОС и поддерживающих его приложений.
А что полезного дают эти облачные сервисы, если сравнивать с тем же KeePass и синхронизацией его БД через Dropbox?
Это всё не выглядит реальными проблемами безопасности. Первая и третья ссылки про то, что имея root доступ к устройству можно получить данные всех приложений - это факт, но с этим ничего сделать невозможно и это касается любых приложений. Вторая про возможность детектить проксик, что не является уязвимостью Signal (и не то, чтобы вообще являлось уязвимостью в принципе).
А почему именно Opus? Sonnet вроде бы не принципиально слабее, но в разы дешевле. Было бы интересно сравнить и его тоже - высока вероятность, что получим 80+ очков при стоимости сравнимой с GLM-4.7.