Понедельник. Интересное за прошлую неделю для меня:

Как запускать LLMки на домашнем ПК:
https://medium.com/@madalina.lupu.d/how-to-shrink-large-language-models-quantization-and-1-bit-llms-explained-c50c76df0b42
https://news.1rj.ru/str/artalog/1327

Сырость и готовность реакт компилятора:
https://www.developerway.com/posts/i-tried-react-compiler
ТЛРД - могло быть лучше

Внезапно, сборная солянка вьюшных хуков на любой вкус. Пример всем реактивным либам, что реактивные структуры данных - это как минимум неплохо:
https://vueuse.org/

Почему всегда нужно пытаться, если в худшем варианте у тебя в жизни просто ничего не изменится(Волкам и прочим не честным на руку людям, привет):
https://x.com/7rulnik/status/1797565614329880604

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

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

В нашей работе это можно применить, к примеру, к Nodejs. Просто работая ты получаешь и тестирование фич, и доп скорость. Минусы? Иногда надо переключаться на LTS, если ты столкнулся с лютым багом, который мешает работать. В остальном, кмк, одни плюсы.
Аналогично можно поступить и с браузерами: сидеть на canary версии хрома, nighly FF и т.п. чтобы просто в фоне проверять что у тебя сайт не разломается в будущих версиях браузера.

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

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

А номер телефона - это одна из основных штук, которая есть в современном мире. К нему прикрепляются все аккаунты, государство через номер телефона взаимодействует со своими гражданами. И из-за этого переезд в другую страну - это огромная заноза в заднице. Ты попросту не знаешь где ты регистрировался. И это прямо усложняет жизнь. Поэтому я стараюсь не привязывать номер телефона к сервисам. Если у сервиса есть 2fa, который работает не через СМС, то надо пользоваться не через СМС.

Но не всегда подобное возможно. И тут приходит на помощь password manager. Как раз Apple недавно сделала попытку вкатиться на этот рынок. И даже их решение на порядок лучше чем хранить пароли в голове.
Так вот, как помогает в этой задаче password manager? Просто: у вас есть список всех ваших аккаунтов за всю вашу жизнь. Пройдитесь по каждому из них и проверьте привязан ли туда ваш номер телефона. Так вы защититесь от доступа нового владельца вашего старого номера к вашим данных. Да, это геморно, но безопасность куда важнее вашего гемора.

Я лично использую 1password.com, так как он позволяет хранить так же кредитные карты, заметки, ssh ключи, доступы к БД, работать из терминала(https://news.1rj.ru/str/xavescor_code/131) и многое многое другое. Если вы не пользуетесь никаким менеджером паролей, то вы очень сильно усложняете свою жизнь. Советую задуматься об этом

Понедельник. Интересное за прошлую неделю для меня:

Выпуск подкаста. Аудио/Видео. Нарциссизм и что ожидать от таких людей:
https://news.1rj.ru/str/zachemmt/329

Запуск любого кода в воркерах. Даже того что не предполагалось. К примеру, всякие аналитики и т.п:
https://partytown.builder.io

Playwright уже на уровне cypress, а vite вскоре обгонит webpack:
https://x.com/filip_hric/status/1800538141280850409
Очень мало времени(около 1.5-2 лет) нужно реально хорошим инструментам, чтобы обогнать заплесневейших лидеров

Пример почему таймзоны это сложно и ни в коем случае нельзя работать со временем руками:
https://www.timeanddate.com/time/time-zones-interesting.html
Опишу так же свой опыт жизни в другой таймзоне, относительно продуктов, которыми я пользовался:
Я некоторое время пожил в таймзоне UTC-7, из-за чего время с Казахстаном отличалось на ровно 12 часов. Я жил для него в прошлом.
Передаю привет всем менеджерам, которые для удобства клиента запрещают искать транзакции в БУДУЩЕМ. Потому что у меня ВО ВСЕХ банках не работало отображение транзаций, так как транзакция проходила образно за 5 марта, а у тебя в это время 4 марта. А когда у клиента 4 марта, то зачем позволять ему запрашивать информацию за 5 марта? Это же БУДУЩЕЕ, там 100% ничего нет, правда? Короч, вы не умеете работать со временем. И не пробуйте даже.

https://socket.dev/npm/package/signal-components/
Удобный сайтец, который показывает чуток больше информации по вашим зависимостям. К примеру, я туда хожу, чтобы глядеть ченжлоги. Это чуток удобнее для меня

https://haveibeentrained.com
Немного забавный ресурс. "Загрузи к нам работу и мы 100% не будем на ней тренировать модель в будущем". Я похехал, но вдруг и реально оно работает.

Эта неделя была настолько скучной, что я думал вообще ничего не писать, но:

- Весёлость в одной из зависимостей свелта:
https://github.com/A11yance/axobject-query/pull/354
Чувак 1 PR'ом затащил 16 СВОИХ зависимостей в рантайм, заменил jest на СВОЙ аналог и заменил стандартную CI джобу на поделку, написанную собой.
И самое весёлое: никто не знает каким образом этот человек получил доступ к репозиторию. Просто добрый человек, который добавил поддержку node 0.4. Очень полезно, правда?)

- Реакт кардинально ломает обратную совместимость, изменив рендеринг некоторых апи с параллельного на последовательный. Что ломает кучу библиотек, которые позволяют вам делать запросы из рендера, так как они опираются на Suspense в своей логике
https://github.com/facebook/react/issues/29898
Но самое печальное, что эта проблема чуток глубже. Аж тянет "почему реакт идёт куда-то не туда pt4".

- Версель начинает монетизироваться, поэтому опенсорс идёт в контратаку. Проект, который позволяет запускать next со всеми верселевскими апихами поверх AWS или просто рантайма ноды.
https://open-next.js.org/

- Так же появились результаты state of js 2023 https://2023.stateofjs.com/en-US. Но мне там вычленить почти нечего

Почему реакт идёт куда-то не туда pt4

Ограничусь просто ссылкой на https://phryneas.de/react-server-components-controversy.

Плюс обращаю внимание на этот абзац.

So, at the beginning of 2023, I started poking the React team, and the maintainers of Apollo Client, TanStack React Query, and Redux got a meeting with the React team. The message was essentially “yeah , you can try to write an implementation now”. So we did.

Но, как уже вам известно, это не остановило авторов реакта от https://github.com/facebook/react/issues/29898

Ну вот и ко мне домой пришёл Rust.

Мы на проекте используем SWC, так как он весьма быстро собирает код. И вот после обновления на последнюю версию оказывается, что наши сорсмапы - не сорсмапы. Как минимум по мнению SWC.

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

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/
Результат даже стал хуже. Гугл не справилась с выпиливанием наших любимых кук, поэтому хром в будущем БУДЕТ ДАВАТЬ ВЫБОР ПОЛЬЗОВАТЕЛЮ.
Из двух стульев с проблемами гугл решил выбрать оба. Никакой инфы нет, но теперь могу представить как теперь будет весело писать код. Теперь надо учитывать тупо оба случая.

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