Самодокументация кода

Документация - важная часть библиотек, которую очень лень писать. Поэтому важно уметь писать код так, чтобы он был самодокументируемым. Но с этим не справляется ни babel, ни webpack, ни eslint.

Они предлагают писать свои конфиги по простой схеме

module.exports = {...}

А что писать в этом объекте? Ну, сам догадаешься, если мы забыли описать это в документации.
Но у нас есть jsdoc, с помощью которого мы можем связывать js код и ts типы, к примеру

/**
 * @type {import('webpack').Configuration}
 */
module.exports = {}

И благодаря этим аннотациям код становится внезапно самодокументируемым. Ты можешь писать комментарии к конкретным полям в объекте, ты можешь помечать их аннотацией @deprecated, ты можешь делать что угодно. И любому программисту это понятно.

Если же у тебя TS, то надо вообще форсить людей с помощью тупых функций

type Config = {};

export const declareConfig(config: Config) {
  return config;
}

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

Из относительно хороших примеров: посмотрите как организована система плагинов у rollup. Они во всю используют этот механизм для подключения внешних плагинов. Ты не просто описываешь конфиг, а вызываешь типизированную функцию.

https://react.dev/learn/react-compiler

Хотелось бы оставить это до понедельника, но это прямо событие, Не сказать что положительное или отрицательное.

Давайте глянем что он может: он автоматически оборачивает содержимое вашего реактора компонента в костыли под именем useMemo/useCallback/React.memo. Теперь, возможно код станет поприятнее.

НО
- он работает только в Strict-Mode(привет текущая кривая экосистема)
- он работает только в рамках одного файла(привет компоненты на 100050000 строк)
- привет(предполагаю) внезапная деоптимизация кода, если вы нарушите какую-нибудь из эвристик этого компайлера, а все наверное встречались с ситуацией, когда ты забыл что-то мемоизировать и у тебя приложение падает с бесконечным ререндером. Архиотвратительная штука

Как по мне, ход интересный, но, кмк, совсем не в ту сторону.

Интересное из мира разработки, что я встретил за прошлую неделю:

- прошла реакт конф. https://twitter.com/t3dotgg/status/1790781312871383259
Не сказать что там есть что-то интересное, но ознакомиться полезно, если собираешься дальше с реактом жить

- state of html 2023. https://2023.stateofhtml.com/en-US Результаты.
Советую ещё раз глянуть state of html, только в результате отчёта. Поможет чуток освежить знания в html. Я, к примеру узнал о теге <Search> и атрибуте focusgroup

- https://blogs.vmware.com/cloud-foundation/2024/05/14/vmware-desktop-hypervisor-pro-apps-now-available-for-personal-use/
Появилось нормальное бесплатное решение для виртуализации на m1 маках. До этого приходилось прямо неплохо так мучаться. Всем советую, если надо что-то быстро проверить на другой ОС.

- https://world.hey.com/dhh/once-1-is-entirely-nobuild-for-the-front-end-ce56f6d7
Небольшой пример как чувак решил всё сделать без сборщика.

- https://www.npmjs.com/package/esm
Пакет, который позволяет в cjs код импортировать ESM на ноде. Теперь не надо ждать 22 ноды, чтобы переходить на ESM либы, если у вас cjs проект

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

- React Server Components(RSC) вы тута
- React Compiler
- Hooks

Спасибо подкасту "Веб-Стандарты"(https://www.youtube.com/@webstandards_ru), за напоминание что у меня горит от реакта. Всем рекомендую.

RSC - это возможность выполнять код ваших компонентов на сервере и прозрачно приносить результат на клиент. Звучит как очень хорошая фича. Да, звучала, около 4 лет назад.
Давайте глянем что произошло за это время:
а) Была введена новая директива "use server". Что превратило наш код в менее предсказуемую штуку с точки зрения сборки и дебага. А так же развязало руки немного в других местах(об этом в следующих сериях).
б) Если у вас есть серверные компоненты, то у вас не будет работать контекст. А у нас прямо дофига экосистемы построено на том, чтобы использовать контекст. Да, есть createServerContext. Но у него нет Consumer. Т.е. пользоваться нормально вы им не можете
в) Документации у этой штуки нет. У нас есть только референсное решение в Nextjs. И это реальная проблема. RSC состоит из двух частей: сборщика и протокола. И эти штуки закрыты. Вы не можете написать собственную имплементацию RSC. Ну, можете, если зареверc инженерите сборку некста и протокол, по которому некст общается с клиентом. Да пофигу на это. Вы даже документацию к createServerContext на react.dev не найдёте(на сайте некста тоже).

А теперь давайте вспомним почему реакту нужны RSC: потому что реакт тормознутый из-за миллиарда ререндеров на каждый чих и жирный донельзя по сравнению с конкурентами(пруф в комментариях). И наличие RSC совсем сорвало башню реакту, как мне кажется. Потому что React19 теперь на 20% жирнее чем React18(https://x.com/damianstasik_/status/1792144533997703506).

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

Решается эта проблема очень просто: @WebpageBot
Отправляете ссылку этому боту и он сбрасывает превью у всех пользователей. В итоге вы можете рекламить свои ссылки с всегда актуальным превью.

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

- React Server Components(RSC)
- React Compiler(RC) вы тута
- Hooks

RC - это "штука, которая позволяет упрощать ваш код, так как вам больше не нужно думать о мемоизации", как продаёт нам это решение команда реакта. Причём продаёт агрессивно. Этот продукт настолько хорош, что ребята из команды реакта ходят(https://github.com/bluesky-social/social-app/pull/4161) по репозиториям и сами внедряют его. Весьма красноречиво, не так ли?
Давайте глянем на реализацию RC. Если вы заглянете в исходники, то увидите, что ребята решили не переиспользовать уже текущие решения на рынке, а попросту написать всё своё: парсер, систему типов и логику мемоизации. Ни одно из решений, которое уже есть на рынке не было переиспользовано. К примеру, они могли бы хотя бы воспользоваться тайпскриптом, который уже давно протестирован сообществом. А это значит только одно: мы будем иметь максимальное количество магии и перестанем вовсе понимать что происходит в собранном коде.

Другая весёлая проблема: ваш итоговый код становится ещё больше. Но это же не проблема, правда? У нас же есть RSC, да? Теперь реакт - это анти-svelte. Если тот с помощью компиляции делает небольшие приложения, то RC делает толсто, но быстро(спорно).
Третье: наш код теперь не является отражением того что в реальности будет выполняться. Если в ангуляре и вью вся компиляторная магия происходит только в одном месте: в компиляции шаблонов, которые не являются кодом, то команда реакта решила собирать js.
Далее: RSC приоткрыло нам дыру в ад метапрограммирования своим "use server". Но теперь нас ничего не останавливает, поэтому RC добавляет ещё одну подобную директиву: "use no memo".

И самое печальное, что реакт своим компилятором не решает проблему ререндеров - пропы при изменении всё равно вызывают ререндер всего поддерева компонентов. И вместо решения проблемы как точечно обновлять DOM, как это делает, к примеру vue/angular/preact/svelte/lit/да_кто_угодно_кроме_реакта благодаря наличию реактивности, мы имеем монстоузное решение, которое просто позволяет разрабам не писать useMemo(sic!). А вот useEvent, который делает часть пропов стабильными, мы, конечно, вводить не будем(https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md).

Кстати, не удивлюсь, если в будущем мы будем иметь библиотеки, которые не будут попросту работать без RC. Люди же любят делать решения без сборки, ага.

В итоге, RC показывает, что фейсбук живёт в каком-то своём мире, который максимально оторван от реальности. Написать собственный язык, чтобы не писать useMemo - это прямо удивительное расходование ресурсов. Как раз по той причине, что это маскировка проблемы, а не её решение.

Ещё одна весёлая(нет) причина почему RC - чуток совсем подход невтуда.

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

https://news.1rj.ru/str/monada_kedavra/193

Очередная подборка интересных вещей, которые мне попались на прошлой неделе:

- https://v8.dev/features/iterator-helpers
У нас в рантайме наконец-то появятся операции над итераторами, что позволит перестать оборачивать все итераторы в Array.from или в [...iteratior]

- https://x.com/karlhorky/status/1792500811307622631?s=52&t=ohIjgaVZLt6vr9X0nBz1jg
Не так давно вышел ESLint@9, в котором выпилили кучу устаревших апи и сделали flat config решением по-умолчанию. Это вызвало кучу боли, так как экосистема оказалась неподготовленной к релизу. Но у flat config есть куча преимуществ, поэтому советую не откладывать миграцию. Тред выше показывает возможные проблемы при миграции и способы обхода этих проблем. Важное напоминание. Flat config поддерживается в восьмой версии еслинта, поэтому для миграции вам не нужно выпиливать устаревшие апи в вашем коде. Посто обновитесь до последнего минора v8.xx

- https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API
Новый потенциальный удобный способ работать с урлами. Пока не в стандарте.

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

- React Server Сomponents(RSC)
- React Compiler(RC)
- Hooks Вы тута

Хуки на момент своего выхода были очень крутым решением. Они позволили упростить композицию и типизацию в наших приложениях. Это позволило очень хорошо упростить нашу кодовую базу. Но у всего есть цена. Появились правила хуков, которые никак не отражены в нашем языке. И ты должен помнить, что хуки всегда должны вызываться в том же порядке и ты не можешь в один момент в компоненте выполнить 3 хука, а потом 5 хуков. У тебя как минимум в дев режиме реакт сломается.

Ну и эти ограничения вроде как не смертельны. В ангуляре и вью, к примеру, всё точно так же. Ты обязан описать всю логику в компоненте. И она не может появиться из неоткуда. За одним сверхважным исключением. ОЧЕНЬ ВАЖНЫМ. Хуки опираются на ререндер в своей работе. И это кардинально меняет картину разработки. Да, ты можешь обмазаться оптимизациями типа RC и подобного, но главное сделать ты не можешь: ты не можешь не выполнять весь код, который у тебя написан.

Почему это критично? Всё просто: потому что мы пишем библиотеки, которые решают задачу. Но почти никогда нам не требуется решение всей задачи в нашем приложении.
Простой пример: посылка запроса на сервер. В реализации этой посылки мы можем описать много логики. К примеру:
- Статус загрузки: true/false
- Загруженные данные: null | Data
- Ошибка: null | Error
- Какую часть ответа загрузили: проценты.

И вот вам сразу пример: https://codesandbox.io/p/sandbox/signal-components-simple-example-74tdrh

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

Моё мнение простое: выносите всю логику в стейт менеджер. Используйте реакт как рендерилку приложения и не более. Не верьте команде реакта, что их волшебный компилятор поправит все проблемы. Нет, не поправит. Концепция глубоко сломана. Метрикой хорошести вашего кода должно быть количество хуков в приложении. Чем их меньше, тем приложение лучше. В идеале их должно быть НОЛЬ.

Ну и обратите внимание на @reatom_ru и @effector_ru. Они помогут вам в улучшении вашего кода.

Кто не знает прошлого, у того нет будущего

Докерхаб в РФ всё. Как минимум при запросах напрямую. Потому что санкции.

Эта история чуток забавна, так как в РФ уже происходило не просто подобное событие, а куда худшее событие. В 2018 году РосКомНадзор(РКН) активно решил бороться с телеграмом. https://ru.wikipedia.org/wiki/Блокирование_Telegram_в_России. И как видите, им это не удалось. Но в процессе блокировок РКН начал активно банить всё что движется. В итоге в РФ была забанен почти весь интернет: AWS, Azure, куча других сервисов. И в этот момент остановилось абсолютно всё: от платёжных касс на короткое время и до тасок на CI на недели, если не месяцы. И если первое, конечно, печальное, то второе реально мешало работать. В то время я был дотнет разработчиком и у нас отвалились как я помню NuGet(аналог npm для дотнета), докер, npm. Вся ситуация усложнялась тем, что у нас не было единой конфигурации на всех разработческих машинах, что заставляло каждому разработчику отдельно решать проблемы с доступами.

Решение подобной проблемы - простое: кеширующий прокси. Они существуют для практически всех хостинг сервисов:
- npm https://verdaccio.org. Я его использую у себя дома для упрощения и ускорения работы.
- docker Существуют миллиарды решений. К примеру https://github.com/distribution/distribution
И даже
- steam, battlenet, EGS https://lancache.net

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

Удивлён насколько vitest передовая штука.

Да, я знал что vitest в отличии от jest прекрасно работает с ESM кодом. Но я даже не подозревал насколько они пошли дальше. К примеру, они позволяют писать тесты на ТИПЫ. На типы, Карл. Такого я не ожидал уж точно. Для писателей библиотек это просто маст хев.

Дока: https://vitest.dev/guide/testing-types
Как выглядят тесты в бою на примере моей маленькой библиотечки: https://github.com/XaveScor/signal-components/blob/f0271fd2c1ae50bf159b484b2928d654060ef536/src/props.test.ts#L78-L110

Сегодня понедельник, а значит интересности от меня за прошлую неделю

- ditox.js.org
Весьма интересный для меня IoC контейнер. Возможно, его реализацию и идеи можно будет куда-нибудь затащить ко мне в проект. Возможность заменять любой узел очень привлекательна как для тестов, так и для разработки

- https://knip.dev
Популярный, но прошедший мимо меня, вычищатель неиспользуемого кода.

- https://x.com/kotkoa/status/1785731445106827496?s=52&t=ohIjgaVZLt6vr9X0nBz1jg
История как можно подзадолбаться чтобы наиболее быстро получить лучшее предложение работы на рынке

Цифровое образование

Последние 4 месяца я занимался вплотную изучением английского, так как это хороший ключ к глобальному рынку.
И у меня произошло 3 открытия:

1) Я разучился учиться. Это прямо сложно. Я обучался оффлайн в специализированной школе по 5 часов 5 дней в неделю. И где-то через 2.5-3 месяца я чувствовал натуральную усталость и нежелание продолжать. Если вы обучаетесь сейчас, то рекомендую не терять этот навык, потому что вкатываться обратно - это прямо перелом себя. Никому не советую это испытывать на себе, но, вероятно, тебе, читатель, это придётся испытать, если хочется что-то сделать.

2) Мир за последние лет 10-15, внезапно(нет) изменился. Теперь для учёбы достаточно просто планшета. По типу айпада. Главное, чтобы у него было перо и камера. Так как с помощью камеры можно делать фотографии распечаток и рисовать на них всё что тебе требуется. А перо - это очень удобный способ ввода.
Только советую не смотреть именно решения по типу киндла, remarkable и т.п. Камера - это необходимость. Как и браузер, мессенджеры и т.п. Потому что вам практически каждый день понадобился или сделать фото, или открыть pdf, или сделать скриншот сайта или каким-либо другим образом получить изображение из внешних источников.

3) Писать и рисовать - очень полезно для обдумывания. К примеру, я сейчас пилю библиотеку, и её прототипирование на бумаге/планшете - это прямо маст хев. Где-то 2-3 месяца просто обдумывания и рисования на бумаге позволило мне избежать многих проблем, по сравнению с ситуацией если бы я взял и сразу попрыгал писать код.
Из забавного: одну из фичей я затащил в библиотеку не думая, просто потому что она показалась хорошей. В итоге: в следующей версии пришлось переделывать апи, так как я не учёл одной суровой штуки.

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

Новый месяц - новая реклама себя.

Если очень кратко: то я за деньги консультирую по разным вопросам. Если очень длинно: https://news.1rj.ru/str/xavescor_meetings_logs/6

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

Как я изучал английский

В догонку к https://news.1rj.ru/str/xavescor_code/147 хочу описать конкретную задачу, на основе которой я принял в свои инструменты планшет с ручкой.
Этой задачей было(и есть) изучение английского. В момент, когда Рф вторглась в Украину, мой уровень английского был примерно А-2, т.е. прямо ниже нуля. Поэтому, по факту, у меня около 2 лет сейчас изучения иностранного языка почти с нуля и мне хочется немного поделиться и зафиксировать некоторые вещи, как в современном мире можно изучать(не обязательно эффективно и быстро) английский на примере своего опыта.

1) изучение грамматики. Грамматика - это наверное самая дибильная вещь, которую не хочется изучать. Потому что это сложно. Научиться незаметно для себя применять грамматику мне помогло 2 инструмента:
- grammarly.com. Это автоматическая исправлялка ваших текстов на английском. Мне повезло, что за последние полтора года я пишу относительно много текстов на английском, поэтому исправления grammarly помогли мне незаметно для себя изучать грамматику. Тебя исправят в первый раз, во второй, в третий. В пятый же ты осознаешь ошибку и будешь её допускать куда реже. Это прекрасный инструмент для беглости грамматики
- gemini.google.com. Эта ЛЛМка куда лучше чатгпт 4 для изучения английского. Её основное преимущество тут: она не подчиняется командам. Почему это плюс? Потому что во время изучения языка ты не можешь дать чёткую интересную команду. Я, чаще всего, копипастил в gemini непонятные фразы и просил их объяснить мне на английском. И объяснения были вполне хорошими. Не забываем ещё о grammarly, которая исправляет тебя во время написания команд.

2) Лексикон: тут мне помогло чтение книг и, снова, gemini. Gemini обучалось на всём интернете, из-за чего все книги, которые вы читали или будете читать, уже есть в индексе ЛЛМки. Это приводит к тому, что gemini способна не только объяснить смысл самого предложения, но и объяснить контекст предложения вокруг него.
Так же с gemini ты можешь играть в разные игры, просить генерировать упражнения и многое другое. В комментарии я прикреплю скриншоты диалогов, которые у меня получались

3) Говорение: тут мне помогло, внезапно, говорение. Но не в локальных языковых клубах, а я поехал в Канаду, чтобы общаться там под наблюдением преподавателя. Локальные языковые клубы сыграли со мной злую шутку. Я стал говорить не на английском, а на локальном диалекте, который понятен только членам клуба. Не советую совершенно языковые клубы.
Так же я нашёл discord канал популярного ютубера-полиглота LanguageSIMP. У него в дискорде можно найти желающих пообщаться со всего мира на практически любом популярном языке. Интернет и дискорд сообщества - это вообще пушка для говорения

Ютуб видео и фильмы не помогают в изучении английского. Моя основная проблема сейчас - гемор в понимании речи нейтивов. И ютуб с фильмами особо этому не помогают, потому что я понимаю речь носителей на видео. Но проблема в том, что они сами знают кто их смотрит и поэтому говорят максимально понятно, выговаривая каждый звук. В реальности нейтивы так не общаются. Совсем не общаются.

Но в этом, внезапно, помогает прямо сейчас, эстеты отвернитесь, тикток. Там всем максимально плевать с высокой колокольни на качество звука и качество контента. Именно на видео где подросток ссыт себе в штаны вы найдёте то как общаются нейтивы. Прямо сейчас это основной мой канал для обучения listening. К примеру, могу посоветовать https://www.tiktok.com/@harbourcustoms?_t=8mwF9WjrEKD и подобных ребят. Научитесь понимать их - понимать живую речь станет на порядки проще.

Я с интересом посматриваю на спеку сигналов(https://github.com/tc39/proposal-signals) и недавно понял насколько реакт разрабам будет просто переходить на эту логику.

Ну посмотрите, у нас есть абсолютно прямые аналоги уже привычных инструментов:
React.useState -> new Signal.State
React.useCallback -> просто функция () => {}
React.useMemo -> new Signal.Computed(...)
React.useEffect -> new Watcher(...)

Отдельно мы можемь обрабатывать unmount. В таком случае наш рендеринг фреймворк может прокинуть нам AbortSignal, через который мы уже можем обработать анмаунт.

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

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

Как запускать 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% не будем на ней тренировать модель в будущем". Я похехал, но вдруг и реально оно работает.