artalog

Изучаем OpenTelemetry https://www.youtube.com/watch?v=ch0pTUxSCbU

Так меня бесит популяризация баша для агентов... Больше всего из-за безопасности, но есть у меня в прошлом некий опыт, который очень сильно зудит в голове... Из-за которого баш для меня архитектурно сломан. Вот вам сравнение: Bash: * Текстовая природа: В Bash всё есть строка. Передача JSON/CSV через пайпы требует постоянного парсинга (например, через `jq`), что тратит ресурсы на приведение типов. * Избыточность по CPU/RAM: Пайпы (`cmd1 | cmd2`) порождают отдельные системные процессы. Запуск утилит в циклах для обработки строк перегружает систему из-за постоянных форков. * Хрупкость кода: LLM часто упускают обработку пограничных сценариев (пробелы, пустые строки) в Bash, что ведет к порче данных. А теперь... PowerShell: * Передача объектов: Вместо текста между командами передаются .NET-объекты. Фильтрация идет напрямую через свойства (например, `$item.Name`), избавляя LLM от написания сложных регулярных выражений. * Экономия ресурсов: Все операции выполняются в рамках единого процесса (.NET), без накладных расходов на запуск новых утилит ОС. * Минус: PowerShell хуже представлен в обучающих выборках моделей, чем Bash или Python. Понимаю на сколько странно это звучит, но мне очень жаль что мы все не пишем на PS, он правда лучше 💁

А я отказался от release-please, тяжелый он. Выкачивает всю историю, а не с последнего релиза, не умеет локально (на текущей истории) без токена запускаться, да и в целом больше фреймворк, а не либу напоминает. Но conventional commit, конечно, следую. Более того, навайбкодил прекоммит хуки для удобной автогенерации скоупа коммита по вовлеченным файлам. Ну а релизы, как вы поняли, аишкой генерю. Это проще (завернул в команду) и гибче.

Собес нужно проводить через вайбкодинг Подождите, не кидайтесь помидорами, здесь есть рациональное зерно. Я тоже сначала скептично был настроен, но вот вам аргументы: 0) Мы и так вайбкодим на работе, кто-то меньше, кто-то больше, но этого все чаще, и это реально то чем собеседуемый будет заниматься после трудоустройства. 1) Компании придумать нормальное(!) проверочное задание для 1-2 часового интервью либо не реально, либо дорого и все еще не полностью репрезентативно. Придумать задачку для вайбкодинга в тысячу раз проще, можно хоть под каждого кандидата свою. 2) Большая часть кандидатов тренируются на прохождение интервью и решение этих типовых туповатых задач, вместо прокачки реальных практических навыков. Это не нормально. Вайбкод - не главное что должен уметь прогер, но это хотя бы реально применимый навык. 3) На сессии вайбкодинга можно охватить быстро сразу много аспектов типовой разработки: валидация DoD, доработки существующего кода, рефакторинг и дебаг, архитектура и, конечно, ревью. Круто же! 4) Вайбкод - это инструмент, и на интервью не нужно им забивать все гвозди, вы готовите им базу для обсуждения и работы в первой части встречи, делаете больше мозгами и руками во второй части. 5) Вайбкод уже вытягивает из ЛЛМ максимум (иначе вайбкод плохой - тоже флаг), собеседуемому сложнее считерить с другой ЛЛМ. Минусы: вам самим нужно успеть проревьюить вайбкод, что бы оценить ревью собеседуемого =D

Приятно, когда приходят с таким фидбеком 😍 Напомню, как войти: • @reatom_ru_news - канал • @reatom_ru - чат • Доки без впн: https://reatom.github.io/reatom/ • База для LLM: https://v1001.reatom.dev/llms.txt • Жсткий скилл для ревью реатом кода: npx skills add reatom/reatom --skill reatom-review, можно ранить как на существующем коде, так и на каждой итерации агента. • Большое приложение на react + reatom: https://github.com/Guria/modern-stack

lf

И еще ключевые выводы: Code as a materialized view — мы часто считаем код источником истины, потому что раньше его было сложнее всего переделывать, но теперь это уже не так. Если есть spec, её можно реализовывать по-разному, с разными техническими характеристиками. Теперь маркетинг дороже реализации, и у команд не всегда есть на него достаточно сил. Как всё это будет работать дальше: как Linux, как музыка. Есть разные дистрибутивы, разные ремиксы; нет единственного «правильного» варианта — есть вкусы, идеи и communities, которые объединяются и делают / поддерживают лучшие версии.

В посте выше шла речь о том что в гугла есть своя реализация всего. А что если бы они оставили те же контракты и апи что у либ замену которым они написали? Вот вам еще одна история Реакт, как и любоя другая библиотека состоит из двух частей - это контракты, способ описания логики который он предлагает. Майндсет если хотите. А вторая часть это его реализация. Условно можно сказать что с точки зрения разработчика выбирающего стек - первое про то как удобно будет этим пользоваться, а второе как хорошо это будет работать. И так как отдельно это не предлогалось, а самостоятельная реализация очень дорогая мы всегда рассмотраливали эти две половинки как части целого. Была очень дорогой Tanner Linsley для сайта tanstack и своего блога отделил апи реакта и написал его реализацию с тем что нужно ему. Итог получился идентичен оргиниальному реакту (а не как преакт с компат слоем), хотя разница в реализации все же была

Часть этого навсегда вырезается. Конкурентный рендеринг, разделение времени, планировщик на основе lane’ов, React DevTools и клиентский десериализатор Flight вообще не реализованы. useTransition и useDeferredValue выполняются синхронно, startTransition — это просто fn(), а планировщик — обёртка над микротасками. Это продуктовые решения: TanStack Start либо в них не нуждается, либо за это отвечает другая часть стека.

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

И еще ключевые выводы: *Code as a materialized view* — мы часто считаем код источником истины, потому что раньше его было сложнее всего переделывать, но теперь это уже не так. Если есть spec, её можно реализовывать по-разному, с разными техническими характеристиками. Теперь маркетинг дороже реализации, и у команд не всегда есть на него достаточно сил. Как всё это будет работать дальше: как Linux, как музыка. Есть разные дистрибутивы, разные ремиксы; нет единственного «правильного» варианта — есть вкусы, идеи и communities, которые объединяются и делают / поддерживают лучшие версии.

Очередной мета уровень 🫩 https://x.com/rohanpaul_ai/status/2063289804708835412

Собрал менеджер паролей на Reatom v1000. Стек: - Tauri v2, Reatom v1000, Lit - Codex, Claude Code - кастомные skills под Reatom/Lit - самописный local RAG: Tree-sitter, Qdrant, BAAI/bge-m3, BAAI/bge-reranker-v2-m3 Попутно из проекта вынес два публичных пакета: - @chromvoid/headless-ui — headless-слой для UI-поведения на Reatom v1000: состояние, actions, keyboard/focus-логика и WAI-ARIA-контракты без привязки к визуальному слою - @chromvoid/uikit — тонкий Lit UI-kit поверх headless-ui: cv-* компоненты, theme-provider, токены темы и vendored Reatom/Lit runtime helpers Что уже есть: - local-first: данные остаются на устройстве - несколько контейнеров: разные мастер-пароли открывают разные наборы секретов, то есть plausible deniability - пароли, банковские карты, OTP - браузерное расширение, которое получает секреты по зашифрованному каналу - бэкапы и восстановление - монтирование тома через FUSE - встроенные аудио/видео-плееры, просмотр изображений, Markdown-заметки - системный Credential Provider: можно хранить passkey в одном месте и использовать на разных устройствах В работе: - генерация SSH-ключей и свой SSH-agent с fallback на системный - криптокошелек - Remote Mobile to PC: USB, WSS, WebRTC; можно соединять два приложения как клиент-сервер Пока есть только Android-версия. Позже планируются iOS, macOS, Linux и Windows. Буду благодарен за любые отзывы, вопросы и техническую критику :) https://github.com/chromvoid/

камунити <3

📸 Спустя 1/3 ультра подписки курсора невероятно рад представить вам https://reatom-jsx-gallery.vercel.app/ Исходники: https://github.com/reatom/reatom/tree/v1001/examples/reatom-jsx-gallery (кстати, у нас и релиз новый под это: https://github.com/reatom/reatom/releases/tag/1001.1.0) Фишки - А ИХ МНОГО: • кроссплатформа ☀️ • просмотр всех файлов по всему дереву папки (рекурсивно) • поддержка кучи форматов включая raw • просмотр всего EXIF (ну с нормальными лейблами) • разные, действительно полезные, режимы просмотра (с ресайзом на "+" "-") • нереально быстрый просмотр фоток (после загрузки превьюшек - это еще оптимизирую) • богатый и интересный выбор тем • ничего кроме Reatom в зависимостях! 10к строк в исходниках, 60кб на загрузку! Ну и конечно - 100500 багов 💔 (но часть я уже поправил)

Будем делать галерею фотографий на веб технология производительнее нативной в MacOS через пол часа (стрим).