typenoscript & vitest

Typenoscript - это одновременно и прекраснейшее что случалось со фронтом, когда ты пишешь бизнес-логику. Есть подсказки. Ошибки ловятся. Всё прекрасно.
Но так получилось, что мне захотелось написать свою библиотеку @signal_components. И тут я столкнулся с ужаснейшей частью: ты не можешь дебажить типы в привычном для нас виде.
А они, в случае написания библиотеки, могут быть весьма сложными.

Что мы делаем, когда нужно продебажить код? Верно: или ставим брейкпоинт, или ставим console.log и смотрим какие там значения у переменных. Но у TS подобное недоступно. Ты не можешь поставить брейкпоинт во время вычисления типа. В итоге, единственный нормальный выход - TDD. Другими словами, пишем тесты на каждый чих.

В итоге типы превращаются в портянку со скриншота. Ну или вот ссылка, если хочется потыкать самостоятельно https://github.com/XaveScor/signal-components/blob/5ef372090a45535fcfc3364d0606cb2e8e43be8b/src/types. Но я пришёл к тому, что это единственный способ одновременно и дебажить типы, и писать их.

И вот тут уже играет vitest. Интеграция всего в единый тестраннер работает удивительно хорошо. У него есть и cjs, и esm, и ts, и проверка типов, и он позволяет писать тесты в одном файле с логикой(https://vitest.dev/guide/in-source.html), и запускать тесты в браузере(https://vitest.dev/guide/browser.html). Да, часть функций находится в активной разработке, но аргументов за неvitest уже почти не остаётся.

llama.ttf

https://github.com/fuglede/llama.ttf

Как вам идея шрифта, в котором запущена нейронка?

Спасибо подобным наркоманам, потому что я теперь знаю, что в шрифтах можно запускать WASM. (Что?)
https://github.com/harfbuzz/harfbuzz/releases/tag/8.0.0

Вот кому это пришло в голову? Слишком мало мест куда майнер можно вперндюрить?
*Ушёл отключать на всех машинах эту дырень в безопасности*

https://blog.cloudflare.com/declaring-your-aindependence-block-ai-bots-scrapers-and-crawlers-with-a-single-click

А вот и первое на моей памяти решение, чтобы защищаться от тренировки на своём контенте. И учитывая что это сделало cloudflare - обучаться теперь будет весьма геморно, так как cloudflare один из самых крупных игроков на своём рынке.

Понедельник. Ссылки.

vitest 2.0. Новый мажор лучшего инструментария для тестов.
https://github.com/vitest-dev/vitest/releases/tag/v2.0.0

Новый сборщик на расте номер 1005001. Единственная вещь почему на него можно обратить внимание: он разрабатывается командой vite. А значит потенциально он будет заменой rollup в будущих релизах vite
https://rolldown.rs/about

Ещё одна причина почему нельзя грузить ресурсы с чужих доменов. Если есть возможность - всегда локализуйте зависимости: скрипты, шрифты и т.п.
https://sansec.io/research/polyfill-supply-chain-attack

Очень годный разбор давно опубликованных результатов state of js
https://www.youtube.com/watch?v=1dReRMvwckY

Инструмент для тестирования запросов нормального человека. Не мокайте fetch или xhr, если это можно не делать
https://mswjs.io

У реакта большой дефицит нормальных DnD решений. Возможно, это одно из нормальных
https://www.neodrag.dev

Прошедший скандал с чуваком, который добавлял поддержку ноды 0.4 в свелт, показал прекраснейший проект. Он направлен на то, чтобы заменять зависимости на уровне менеджера зависимостей и не качать устаревшую дичь к вам на машины
https://github.com/SukkaW/nolyfill

Совместимость и технический PR.

Обратная совместимость с конкурентами - это то преимущество, которое почему-то современные решения почти полностью игнорируют. И я не говорю про необходимость обратной совместимости между версиями, которую, к примеру, полностью игнорирует react-router. Я говорю про обратную совместимость между решениями, в случае когда одно решение пытается заменить собой другое.

Возьмём реакт мир: у нас куча библиотек, которые являются "убийцами редакса", "убийцами react-router", "убийцами реакта", но которые предоставляют примерно 0 совместимости с предыдущими решениями. Почему-то авторы либ считают, что пользователи с радостью будут брать и переписывать проект полностью на новое решение, что пользователи сами будут придумывать как дружить старое решение и новое, что нужно лишь придумывать как делать прекрасный новый мир, не задумываясь над старым.


Хорошим примером противоположного подхода является мной обожаемый vitest, на который мы недавно мигрировались буквально за неделю с jest'a. Причём большую часть времени мы занимались тем, чтобы подружить vitest с нашей немного чуждой системой для фронтенд мира(Bazel). Схожее апи с jest'ом на 90-95% позволило не просто переписывать тесты, не включая мозг, а перепоручить этот опыт LLMке, которая сделала почти что всю работу за людей. Достаточно было промта для chatgpt 4o:

Rewrite the typenoscript file from jest to vitest. Also port the noscript to ESM. Give me ONLY the total file content. No explanations!. No markdown. I want to paste your response directly into the file. Do NOT erase types inside the file.
[File]
${content}

И 95% кода было успешно переписано. Да, в некоторых ситуациях были ошибки. Но их легко поправить руками. Но почти вся рутина была автоматизирована.


Другим хорошим примером является preact. Эти ребята сделали почти полную совместимость с реактом, добавив нормальное решение в виде сигналов. Что позволяет взять и максимально постепенно переписывать код на реактивные рельсы. В отличии от solid'a, который паразитирует на реакте, но заставляет полностью переписывать код.

Ещё один хороший концептуально пример: https://github.com/SukkaW/nolyfill. Чувак ничего не изобретает и просто создаёт более эффективные решения на основе существующих апи.

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

ljharb

Ситуация с ljharb продолжает быть веселее и веселее. Это тот чувак, который решил в доку свелта добавить поддержку ноды 0.4.

Вчера я пытался в очередной раз апнуть наш проект до eslint 9 и увидел, что eslint-plugin-import принадлежит как раз этому челобеку. Следовательно, по классике, этот плагин поддерживает eslint 2, node 4 и прочую некрофилию. А так же чувак попросту не добавляет поддержку flat config и eslint 9. И вот история в том, что игнор идёт уже больше года. В итоге появляется eslint-plugin-import-x: https://www.npmjs.com/package/eslint-plugin-import-x, который поддерживает только eslint 8/9, не имеет кучи говнозависимостей и пока поддерживается новым ментейнером.

Другая история происходит прямо сейчас про библиотеку traverse. Как легко догадаться, туда тоже пришёл ljharb. В итоге ша маемо, то маемо. Но благо, благодаря этому появилась библиотека neotraverse: https://www.npmjs.com/package/neotraverse, которая является форком оригинальной, но без всей этой дичи от нашего поциента.

В итоге, если хотите получить популярный проект, то алгоритм чуток прост:
1. Смотришь, в какой очередной утилитарный проект пришел ljharb и навернул секурности
2. Делаешь форк от прошлой версии без зависимостей, обзываешь neo/nano/x-оригинальное имя и публикуешь
3. Профит, благодарные юзеры благодарны на ровном месте, репутация локального спасителя экосистемы

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

Ну и в продолжение. Узнайте заражен ли ваш пакет ljharb'ом https://voldephobia.rschristian.dev

Миграция.

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

И идеальной ситуацией будет схема:
1. депрекейт фичи в миноре версии x
2. варнинг в версиях x+1,...,x+N-1
3. выпиливание фичи в версии x+N

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

Однако, зачастую бывает такое, что нужно заменить одно решение на другое. Причём изначальное решение используется в 100500 местах в проекте. К примеру: замена React.useCallback на useEvent. Мы проводим сейчас как раз такую миграцию. И тут основная проблема в трёх местах: нужно как-то донести новое правило до всех членов команды; нужно как-то на code review замену API; нужно как-то контролировать прогресс выпиливания, чтобы не оказаться в ситуации, что у нас будет 100500 одновременных миграций.

Сложность первой проблемы в том что миграции могут длиться годами, а это значит что в проект могут спокойно приходить новые люди. А значит и их нужно посвещать в таинство колдунства;
Вторая проблема же в том, что программисты тратят слишком много времени и сил на PR. И в итоге вместо реальной работы люди начинаются докапываться до кодстайла.

Мы выработали следующее решение этой задачи:
1. Пишем ESLint правило, которое запрещает использовать старое API;
2. Во все места с ESLint ошибками добавляем ignore комменты, которые отключают ESLint ошибку для конкретных строк
3. Добавляем над ignore комментом TODO коммент.
4. В следующий раз когда программист правит файл, то он может выпилить старое API на новое, заодно проверив функциональность логики

Добавить TODO и ignore комменты можно добавить простой командой:

npx suppress-eslint-errors . --extensions=ts,tsx --parser=tsx --rules=no-restricted-syntax   

В итоге мы можем легко контролировать количество TODO комментов в коде. Программист видит какой код устарел, так как TODO комменты выделяются в редакторах другим цветом. Легко находить TODO комменты в коде, чтобы постепенно выпиливать старую логику. А ESLint правило позволяет не давать плодить программисту устаревший код.

Одни плюсы, правда если только ты можешь написать ESLint правило

пуштумастер

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

- Делать PR и мержить можно всем
- Ментейнерам можно пушить в мастер, чтобы быстро реагировать на инциденты

Но иногда ментейнер может случайно запушить свою работу в мастер, так как, к примеру, забыл создать отдельную ветку на задачу.
Подобную проблему может решить проверка на имя ветки на стороне разработчика, чтобы пуши в мастер могли работать только с --no-verify. Добавьте следующий код к себе в прекоммит хук:

#!/bin/bash

current_branch="$(git branch --show-current)"
if [[ "master" == "$current_branch" ]]; then
      echo "ERROR: local branch $current_branch is protected" 
      exit 1
fi

exit 0

Если шо, сильно не привязывайтесь к гитлабу

https://www.reuters.com/markets/deals/google-backed-software-developer-gitlab-explores-sale-sources-say-2024-07-17/

Блеск и нищета опенсорса

Jest и Vitest - это лидирующие решения для юнит тестирования js/ts кода. Но вокруг них сложилась удивительная и непонятная для меня ситуация.

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

А теперь давайте глянем на наших лидеров:
Что нам нужно от расширения jest/vitest. В 99% случаев нам понадобится написать собственный matcher. Это та штука, которая пишется expect().ВОТ_ТУТ(). И в таком случае начинается веселье:
- У тебя есть только описание того как просто сделать expect.extend
- У тебя описывается как максимально примитивно добавить типы. У Playwright, к примеру, матчеры различаются в зависимости от того что ты передаёшь в expect. У vitest'a все матчеры находятся в единой помойке. Типизация тут помогает минимально.
- У тебя попросту нет доступа из матчеров к конфигу. Соврал, нет НОРМАЛЬНОГО доступа к конфигу.
И эту сиутацию я хочу рассмотреть.

Вот у меня есть задача: написать снепшотилку директорий. Не важно что это такое. Важно то, что мне нужно получать доступ к флагу -u, который в vitest позволяет понять хочет пользователь сравнить снепшоты или же обновить их.
И делается это очень просто: никак. Точнее, никак это не описано в документации. Но зато нам даётся ссылка на jest плагин, который позволяет делать снепшоты: https://vitest.dev/guide/snapshot#image-snapshots. И тут может возникнуть мысль: "Эврика! В jest'e всё можно сделать, а vitest просто перенёс к себе эти решения".
Ну, часть вывода будет верна: Vitest перенёс решения. Но это не решения, а костыли. В jest так же ничего не описывается.

В итоге все кто пишут плагины к jest, тупо завязываются на внутренние апи. К примеру, флаг -u - это простое выражение expect.getState().snapshotState._updateSnapshot === 'all'. И да, _updateSnapshot - это приватное поле. Приватное поле на уровне типов. И даже в 2019 году было issue, чтобы сделать апи нормальным: https://github.com/jestjs/jest/issues/8732
Но, ничего не изменилось.

И это фигня. Часть апи, к примеру, лежит тупо в global: https://github.com/americanexpress/jest-image-snapshot/blob/da49e578c9a02c50aa841d05ac64e9ffd4b725fd/src/index.js#L193
Всё апи jest'a и vitest'a - это набор костылей, которые можно найти только с помощью метода тыка.


Итог: jest плюёт на расширяемость. Vitest занимается тем, что переносит костыли jest'a и так же плюёт на расширяемость. Так и живём.

Понедельник. Ссылки

https://jser.dev/2023-06-19-how-does-usestate-work/
Как работает useState в реакте. Неплохо мне помогло в написании @signal_components. Я пытаюсь в качестве эксперимента затащить сигналы в реакт. А он активно вставляет костыли тем людям, которые хотят избегать ререндеров.

https://9to5google.com/2024/07/18/googl-links/
Гугл закрыл и этот проект

https://news.1rj.ru/str/workbeer/141
Как корректно делать шорткаты в вебе

https://publint.dev
https://arethetypeswrong.github.io/
Линтеры для package.json. Рекомендую почитать правила, которые они там проверяют. Можно узнать интересное о том как резолвятся пакеты.

https://zed.dev/blog/beta
Отличнейший редактор, теперь есть на Linux. У себя на маке я полностью заменил им sublime text. Всем рекомендую в случае, если требуется просто открыть файл и как-то поиграться с ним

https://x.com/lcasdev/status/1810696257137959018?s=46&t=ohIjgaVZLt6vr9X0nBz1jg
Хром, как неожиданно(нет), даёт гуглу эксклюзивные права на многие ваши метрики(CPU, GPU, RAM, etc) на своих сайтах.

https://news.1rj.ru/str/dotrubic/234
Как GPL руинит мир. Никогда не используйте у себя любую из форм GPL

3rd party cookies

https://privacysandbox.com/news/privacy-sandbox-update/
Результат даже стал хуже. Гугл не справилась с выпиливанием наших любимых кук, поэтому хром в будущем БУДЕТ ДАВАТЬ ВЫБОР ПОЛЬЗОВАТЕЛЮ.
Из двух стульев с проблемами гугл решил выбрать оба. Никакой инфы нет, но теперь могу представить как теперь будет весело писать код. Теперь надо учитывать тупо оба случая.

Вот реально, как им в голову такие решения приходят?

bun, внезапно, реально изменил мир.

Сегодня мне понадобилось написать скрипт околосреднего размера на ts. И это так впадлу настраивать на привычном стеке. А с помощью bun - всё просто:

bun run index.ts --watch

и не нужно никакого tsc, ts-node, nodemon и прочей фигни. Оно просто работает.

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

brew install oven-sh/bun/bun

И да, всё вышенарисованное появилось в ноде как раз благодаря бану

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

К примеру, godaddy попросту украл домен моего знакомого @sergeysova, так как он паспортом не вышел.

Я сам лично пользуюсь namecheap.com и покупал reatom.dev именно там. Так как у них простейшая политика: если они не захотят с вами сотрудничать, то они попросту попросят вас увести свои домены от них куда-нибудь.

Автор effector.dev хостит свои домены на name.com и они тоже нормально относятся к своим клиентам.

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

Понедельник. Ссылки

https://2023.stateofreact.com/en-US
Результаты опроса. Из приятного: redux ненавидит 30% респондентов.
Советую прочитать этот опрос, так как это хороший способ обновить свои знания.
Плюс, из интересного: добавили комментарии. Их тоже советую глянуть.
К примеру, комментарий к useState

Not because i like it. just because it is default

Ещё бы лайки-дизлайки к комментам добавить и будет идеально

https://news.1rj.ru/str/workbeer/151
setTimeout не такой уж и кроссплатформенный. Node работает чуток по-другому, в отличии от браузеров

https://github.com/nodejs/node/pull/53725
Привет bun. Нода пытается в запуск ts файлов.

https://github.com/public-apis/public-apis?tab=readme-ov-file
Список огромного количество открытых апи с разной информацией

Прямо сейчас правительство в РФ решило взяться серьёзно за ютуб и начать его активно ломать.
И так как у меня в подписчиках достаточное количество россиян, то рекомендую ознакомиться с
https://habr.com/ru/articles/831846/
https://habr.com/ru/articles/832678/

Как минимум, чтобы отсрочить необходимость гонять видео через VPN. А так, существует только 1 нормальный способ обхода блокировок: на уровне роутера.

Древняя статья для древнего микротика: https://habr.com/ru/articles/549282/
Но для того чтобы понять принцип тунеллирования трафика по BGP в VPN - будет полезно.

Понедельник. Ссылки.

Последнюю неделю-полторы я пишу свой сборщик для js/ts библиотек, поэтому и ссылки весьма специфичные

https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#signal
У addEventListener оказывается есть возможность прокинуть abortSignal. Это куда удобнее для меня, так как
а) можно на 1 сигнал повесить сколько угодно подписок
б) не надо хранить и DOM ноду, и колбек, для того чтобы осуществить отписку

https://deno.com/blog/http-imports
Deno признал, что импорты через http урлы - это чуток путь не в православную сторону

https://github.com/sveltejs/rollup-plugin-svelte/issues/104
Не забывайте при написании package.json для библиотек экспортировать сам package.json. Он бывает нужным в неожиданных сценариях

https://2ality.com/2019/10/hybrid-npm-packages.html
Немного устаревшей доки как писать esm/cjs библиотеки корректно

https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/
И как всё же их писать сложно

https://www.typenoscriptlang.org/docs/handbook/modules/appendices/esm-cjs-interop.html#library-code-needs-special-considerations
А так же нужно не забывать собирать 2 вида тайпингов, так как cjs и esm тайпинги у тайпскрипта не взаимозаменяемы

https://e18e.dev
ljharb гордился бы нами. Люди всерьёз задумались о размере пакетов. Надеюсь, что эта инициатива не заглохнет

https://storybook.js.org/blog/storybook-8-2/
И вот вам сразу практический пример как крупный проект начал думать о размере и удобстве работы с зависимостями

https://github.com/tc39/proposal-promise-try
Но не стоит считать, что ljharb абсолютное зло. Он так же делает и приятные для нас штуки

https://github.com/uBlockOrigin/uBlock-issues/wiki/About-Google-Chrome's-%22This-extension-may-soon-no-longer-be-supported%22
Manifest v3 в Хроме наступает. Походу, всё же вскоре случится

https://parceljs.org/getting-started/library/
Парсель внезапно имеет практически идеальную конфигурацию сборки для библиотек. "Практически" - потому что всё же package.json не генерится, а его приходится писать руками

Когда-то давно я видел наборы в стиле "100500 ошибочных допущений о времени/ФИО/так_далее" и мне захотелось поделиться несколькими историями/заблуждениями, когда дефолты не работают.

Важный контекст: я не являюсь гражданином РФ и никогда им не был, но прожил около 6 лет с 2016 по 2022 год в Москве и Санкт-Петербурге как трудовой мигрант.
Не очень важная, но хотелка: не стесняйтесь ставить реакции. Вам ничего не стоит, а мне приятно.
Важное уточнение для всех нероссиян: далее я буду использовать российкую терминологию, так как она отличается от международной. Загранпаспорт==паспорт и паспорт==id-карта


Заблуждение/история №1: Российский номер телефона имеют только россияне.
(Скриншоты в комментариях)
Хочется сказать что это очевидно. Но, внезапно, нет. Не очевидно. Как минимум для техподдержки Яндекса.
Вчера я решил глянуть что предлагает рекламная сеть Яндекса для телеграм каналов и обнаружил, что Яндекс предлагает мне зарегистрироваться с моим уже бывшим номером телефона, хотя я отчётливо помнил, что я его менял на казахстанский. Оказалось, что Яндекс в какой-то момент открыл мне самостоятельно счёт в Яндекс.Банке и привязал туда мой российский номер телефона. На моё желание удалить номер я увидел простую вещь: хочешь что-то с ним сделать - пиши в техподдержку. Ну, бывает, я написал(скриншот 1). И я очень сильно удивился когда меня попросили предоставить паспорт(которого у меня нет из-за отсутствия гражданства) и сделать селфи, чтобы что-то там подтвердить. Напоминаю: документов у Яндекса об открытии счёта быть не может. Да, я работал в Яндексе, но счёта в Яндекс.Банке не открывал. Итог: диалог просто был завёршён со стороны техподдержки, так как я отказался делать фото. Не знаю был ли там человек или робот, но впечатление уже сильно попортилось.
Кстати, советую и вам проверить. Авось и у вас есть счёт в Яндекс.Банке, о котором вы не знаете.
Благо второй диалог(скриншот 2) был уже куда адекватнее. Без фото и прочих данных мне пообещали, что счёт закроют. И его закрыли, правда по СМС так и не уведомили, хотя пообещали.

Вывод: не все люди - россияне
=======
Заблуждение/история №2: Не все живущие в РФ - россияне
Во времена своего студенчества родители где-то раз в месяц присылали мне деньги на жизнь. Самый простой доступный способ был отправка денег всякими посредниками типа western union или "золотая корона". В итоге после получения денег у меня была какая-то наличка на руках, которую нужно как-то закинуть на банковский счёт для удобных операций.
В то время у Тинькофф не было банкоматов и единственным способом пополнения счёта я видел пополнение через салон сотовой связи. Я использовал разные салоны: мвидео, билайн, евросеть и другие, но абсолютно везде был один нюанс: для пополнения счёта нужно было предоставить паспорт гражданина РФ. Не знаю кто это придумывал и какая форма мотивации была у сотрудников салонов, но во всех случаях общение строилось так:
1) я показывал свои документы
2) минуты 3 мне доказывали что у меня должен быть российский паспорт, даже после моих слов, что у меня нет гражданства. Эта информация просто никак не принималась людьми
3) в итоге консультант смирялся, вбивал СВОИ данные и деньги поступали ко мне на счёт

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

Заблуждение/история №3: У людей может меняться ФИО.
В 2016 году в загранпаспорте у меня была фамилия+имя+отчество, с помощью которых я устроился на первую работу, и, следовательно, получил свой набор документов
В 2018 году я получил новый загран, в котором у меня уже были фамилия+имя. Отчества не было. И это прямо прибило все гос и частные органы в РФ. У меня сломались "пенсионный фонд", "тинькофф", "сбер" и моя компания, в которой я работал. И сломались по простой причине: они не подразумевали что у человека может смениться ФИО. До сих пор у меня в РФ для государства 2 личности: ФИО и ФИ. 2 разных человека. И это мне очень больно била при попытке устроиться на работу, так как всякие СНИЛСы и прочее попросту не подходили к моей "текущей личности". В итоге каждый работодатель просто плевал на несоответствия и вроде как штрафов не получал.

Вывод: ФИО может меняться без ведома государства
=====
Заблуждение/история №4: У людей может меняться номер паспорта

По этой же причине у меня сменился и номер паспорта в 2018 году. В итоге у меня сломались госуслуги РФ. Не сказать что они мне как-то сильно нужны, но это всё равно забавно. И причина проста: документы, указанные в СНИЛС не совпадают с данными паспорта. А без этих двух сущностей иностранцу не зарегистрироваться на госуслугах РФ. И РФ не особо дружелюбно к людям, которые хотят изменить данные у них. В итоге я плюнул и решил жить без доступа к такому великому сервису как госуслуги РФ

Вывод: Не только ФИО, а вообще любые данные человека могут измениться без ведома государства.
=====
Ко всем разработчикам у меня только одна просьба: при проектировании сервисов попробуйте не забыть о том, что в вашем государстве живут не только ваши сограждане, но и другие люди.

raycast

До последнего времени мне было абсолютно фиолетово на какой ОС сидеть. Главное, чтобы задачи лучше всего выполнялись.
Проект работает лучше всего под линуксом? Буду сидеть под линуксом. Винда? Без проблем. Макось? И эта железка есть.

Это всё обеспечивалось тем, что у всех трёх ОС можно построить примерно одинаковое окружение: запускаешь терминал, в нём fish+tmux и работаешь как тебе привычно.
Но около 2 месяцев назад схема дала слабину. Потому что есть https://www.raycast.com.

Напомню свою позицию по работе с устройствами: поиск превыше всего. https://news.1rj.ru/str/xavescor_code/73
И рейкаст - это прямо идеальное продолжение этого подхода.

Если говорить вкратце: то это поисковая строка с возможностью расширения. И плагины есть практически на любой вкус.
И теперь у меня жизнь выглядит примерно так:
- Нужно что-то найти? Ищем через рейкаст в гугле или duckduckgo
- Нужно что-то объяснить? Делаем запрос через рейкаст к чатгпт
- Нужно написать маме о чём-то? Открываю чат с мамой через рейкаст через плагин к whatsapp(Плагина, делающего интеграцию с телегой, увы, нет)
- Нужно что-то перевести на другой язык? Верно. Плагин к google translate
- Нужно написать коллеге в slack? Открываешь чат с коллегой напрямую через raycast
- Хочется включить кондиционер? Плагин к home-assistant.io тоже есть в рейкасте.

Преимущество рейкаста в том, что в комьюнити есть куча поехавших, которые сделали плагины практически к чему угожно. И это всё БЕСПЛАТНО. Тебе не нужен никакой другой интерфейс для поиска кроме поиска raycast.

Кроме того raycast исправляет тупые косяки макоси:
- Есть window manager
- Есть буфер обмена с историей
- Есть возможность править менюбар

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