FastAPI Voyager - это интерактивный инструмент визуализации для API, созданный на базе FastAPI. Позволяет наглядно представлять структуру API с возможностью масштабирования через прокрутку и детального изучения узлов двойным кликом. Особенность инструмента - режим просмотра зависимостей схемы (активируется через Shift+клик), который фильтрует несвязанные узлы, упрощая анализ сложных систем.

Проект поддерживает импорт данных JSON из ядра системы, что обеспечивает гибкость интеграции. Инструмент ориентирован на разработчиков, работающих с FastAPI, и помогает лучше понимать архитектуру API, выявлять связи между компонентами и оптимизировать структуру. Код проекта доступен на GitHub, что позволяет сообществу вносить вклад в развитие и адаптацию инструмента под конкретные нужды.

• Пользователи жалуются на неудобство визуализации сложных связей между эндпоинтами и моделями ответов в fastapi-voyager; требуется более интерактивный и «чистый» способ исследовать схему.
• Предложение: добавить взаимодействие при наведении курсора на узел, чтобы подсвечивать связанные с ним линии и скрывать остальные, а также дать возможность «проваливаться» внутрь подграфа.
• Пользователи просят улучшить UX: убрать «клубок» линий, дать возможность масштабировать и фильтровать отображаемое, а также предоставить обзорный режим, в котором детали раскрываются по мере необходимости.
• Проект вдохновлен GraphQL-voyager, но не реализует его фичи вроде подсветки связей при наведении мыши; автор отвечает, что проект на ранней стадии и приветствует PR-ы.

Разработчики Stategraph выбрали OCaml для управления состоянием Terraform, поскольку корректность здесь критически важна. Система хранит состояние как граф зависимостей в PostgreSQL с блокировкой на уровне ресурсов. OCaml позволяет улавливать целые категории ошибок на этапе компиляции, что невозможно в других языках. Сильная типизация данных предотвращает доступ к несуществующим полям, а неизменяемые структуры по умолчанию исключают условия гонки.

Типобезопасные SQL-записи предотвращают дрейф схемы до развертывания, а PPX автоматически генерирует корректную сериализацию JSON. Как отмечают разработчики: "Мы строим инфраструктуру, которая управляет инфраструктурой других людей. Повреждение состояния не может быть 'редким'. Оно должно быть невозможным". Компилятор OCaml обеспечивает безопасность на уровне типов, проверяя все переходы состояний и записи в базе данных, что значительно снижает количество ошибок по сравнению с традиционным подходом, основанным на тестировании.

• Обсуждение показало, что выбор языка часто опирается на субъективные предпочтения и эстетику, а не только на технические аргументы.
• Участники подчеркнули, что такие факторы, как удобство найма разработчиков и удержание их мотивации, могут быть более важными, чем технические характеристики.
• Была поднята тема лицензий и открытого кода как факторов, которые могут влиять на выбор инструментов.
• Обсуждение также затронуло вопросы стоимости владения инструментом и его экосистемой, включая стоимость обучения и доступность кадров.
• Участники отметили, что хотя технические детали важны, они не всегда являются решающими при выборе стека, особенно если учитывать, что большинство современных языков предлагают сравнимые возможности.

Ratatui — библиотека для создания терминальных интерфейсов (TUI) на Rust, предлагающая инструменты для построения интерактивных консольных приложений. Она предоставляет богатый набор виджетов (таблицы, графики, календари, списки), гибкие системы компоновки и стилизации, а также поддержку различных архитектурных подходов, включая The Elm Architecture, Component и Flux. Библиотека работает с несколькими бэкендами, поддерживает обработку событий, работу с сырым режимом терминала и захват мыши.

Документация структурирована по разделам: от базовой установки и флагов возможностей до подробных туториалов (создание счётчика, JSON-редактора), примеров приложений и концепций. Особое внимание уделено рецептам решения конкретных задач: компоновка интерфейсов, рендеринг, кастомизация виджетов, тестирование и разработка приложений. Проект активно развивается, с активным сообществом в Discord, Matrix и других платформах.

• Rust-разработчики выбирают TUI, потому что в Rust нет приемлемого GUI-решения, а Ratatui «просто работает».
• Сообщество в основном согласно, что Qt в Rust нет и не предвидится, и что это не проблема, которую можно решить внешним крейтом.
• Терминальные приложения в Rust-экосистеме в основном используют Ratatui, потому что он «просто работает» и не требует сложной настройки.
• Несколько участников поделились ссылками на свои проекты, в которых используется Ratatui, включая игру Rebels in the Sky и чат-клиент termchat.
• Обсуждение также коснулось того, что TUI-инструменты в Rust-экосистеме в основном используют Ratatui, потому что он «просто работает» и не требует сложной настройки.

Автор активно использует Claude Code как для хобби-проектов, так и профессионально, где его команда потребляет несколько миллиардов токенов в месяц для генерации кода. По его мнению, пространство CLI-агентов стало конкурентным полем, но выбор разработчиков часто зависит от поверхностных различий в реализации функций или "тона" системных промптов, а не от фундаментальных различий. Автор предпочитает подход "забыл и забыл" — делегировать задачи, задавать контекст и позволять ИИ работать, оценивая результат по финальному PR, а не по процессу.

Ключевым элементом эффективного использования Claude Code является файл CLAUDE.md в корне репозитория, который служит "конституцией" для агента. В профессиональной среде этот файл строго поддерживается и достигает 13 КБ, потенциально вырастая до 25 КБ. Автор рекомендует начинать с ограничений, а не с полного руководства, избегать встраивания полного документации в контекст, не просто говорить "никогда", а предлагать альтернативы, и использовать CLAUDE.md как инструмент для упрощения внутреннего инструментария. Для совместимости с другими AI-IDE файл синхронизируется с AGENTS.md.

• Обсуждение охватывает вопросы от синхронизации файлов агентов (AGENTS.md ↔ CLAUDE.md) до философии MCP и навыков (skills), а также затрагивает рабочий процесс с git-worktree и CLI-утилитами.
• Участники обмениваются опытом использования Claude Code, Cursor и других инструментов, обсуждают их преимущества и недостатки, а также их влияние на разработку и рабочий процесс.
• Обсуждаются проблемы с контекстом, который может использовать агент, и как лучше всего структурировать проекты для облегчения работы агента.
• Также затрагивается вопрос о том, как лучше всего использовать инструменты в зависимости от ситуации и как они могут быть улучшены.

Интерактивная визуализация "AI Mafia Canvas" представляет собой сеть связей, основанную на подкасте Acquired Google Podcast. Пользователи могут исследовать взаимосвязи, нажимая на узлы, а также управлять представлением с помощью перетаскивания для панорамирования и прокрутки для масштабирования. Проект создан разработчиком с ником @dpwxni, который также предлагает попробовать созданную им гоночную игру F1.

Визуализация позволяет выделять связи при клике на любой узел, предоставляя наглядное представление о экосистеме Google как AI-компании. Инструмент оснащен базовыми функциями управления видом: сброс, увеличение и уменьшение масштаба, что делает исследование сети удобным и интуитивно понятным для пользователей.

• Создана интерактивная карта «AI-Mafia», визуализирующая связи между Google и современными компаниями вроде OpenAI и Anthropic.
• Использованы Obsidian и Cytoscape.js для рендеринга JSON-файла, но встроенные паблишеры Obsidian не справились с выравниванием узлов.
• Обсуждение вылилось в обмен ссылками на эпизод Acquired и обсуждение того, как Google запустил цепочку событий, приведших к появлению OpenAI, Anthropic и других ключевых игроков.
• Участники обсуждали, какие еще стартапы или инициативы можно было бы включить в карту, и упомянули Ilya Sutskever и OpenAI, а также ныне ушедшую в закрытые исследованиях.

Memory maps (mmap) в Go позволяют отображать файлы непосредственно в адресное пространство процесса, избегая копирования данных через буферы. Этот подход устраняет необходимость в системных вызовах read/write, позволяя процессору обращаться к файловой памяти так же, как к обычной памяти. Техника особенно эффективна для больших файлов, когда требуется частый доступ к разным участкам данных, так как mmap обеспечивает постоянное время доступа к любой части файла.

Тесты показали впечатляющие результаты: mmap обеспечивает до 25-кратное ускорение по сравнению с традиционным чтением файлов. В одном эксперименте обработка 1.2GB JSON-файла через заняла 0.4 секунды с mmap против 10 секунд с использованием стандартного пак ioutil. Однако mmap имеет ограничения: он не подходит для очень больших файлов, которые могут не поместиться в виртуальном адресном пространстве, и требует осторожного управления при работе с несколькими процессами. Для оптимальной производительности mmap лучше всего работает с файлами, которые считываются целиком или accessed случайным образом, а не последовательно.

• Обсуждение показало, что mmap не всегда быстрее обычного чтения, особенно при последовательном чтении, и что его преимущество в основном в нишевых сценариях, таких как случайный доступ к большим файлам.
• Участники отметили, что mmap требует осторожности при работе с файлами, которые могут быть изменены или усечены, поскольку это может вызвать ошибки доступа.
• Также было отмечено, что в некоторых ситуациях, таких как чтение из файла в последовательном режиме, обычное чтение может быть предпочтительнее, особенно если файл больше размера оперативной памяти.
• Обсуждение также затронуло влияние различных файловых систем и их взаимодействия с mmap, включая то, что некоторые файловые системы могут не поддерживать mmap или могут вести себя неожиданно при его использовании.
• В конце обсуждение подвело к выводу, что выбор между использованием mmap и обычного чтения должен быть сделан на основе конкретного сценария и требований к производительности, а не на основе предвзятого убеждения в превосходстве одного над другим.

После четырёх лет разработки Stalwart представил полную реализацию JMAP для календарей, контактов, адресных книг, хранения файлов и обмена. Это делает Stalwart первым сервером JMAP, поддерживающим всю семью протоколов совместной работы, открывая новую эру для открытого и эффективного группового ПО. Новые стандарты включают JMAP для Календарей (замена CalDAV), Контактов (альтернатива CardDAV), Файлов (замена WebDAV), а также JSCalendar и JSContact — современные JSON-версии iCalendar и vCard.

JMAP решает проблемы устаревших технологий, предлагая вместо громоздкого XML и несовместимых форматов простые, последовательные API поверх JSON. Протоколы обеспечивают лучшую производительность, простоту реализации и надёжность. Эта реализация знаменует сдвиг в проектировании ПО для совместной работы, позволяя разработчикам строить на единой, когерентной платформе. Поддержка клиентов пока развивается, но такие проекты, как Mailtemi и Parula, уже работают с новыми стандартами.

• Stalwart — первый сервер с полной поддержкой JMAP, но документация и UX оставляют желать лучшего, что затрудняет его внедрение.
• JMAP-совместимые клиенты всё ещё отсутствуют, что делает внедрение Stalwart сложным для конечных пользователей.
• Отсутствие клиентов и серверов, поддерживающих JMAP, затрудняет внедрение, даже если Stalwart технически превосходит IMAP и CalDAV.
• Сообщество обсуждает, что для внедрения JMAP нужно как минимум один из: либо крупный провайдер (Gmail, Fastmail) начнёт поддерживать его, либо Thunderbird и другие клиенты добавят поддержку.

Scriber Pro — это приложение для Mac, которое выполняет транскрибацию аудио и видеофайлов прямо на устройстве, без интернета. Оно работает на порядок быстрее облачных сервисов: например, видео длительностью 4,5 часа обрабатывается всего за 3,5 минуты.

Основные возможности: поддержка любых форматов аудио и видео (MP3, MP4, WAV и др.), высокая точность даже в длинных файлах, полная офлайн-работа и сохранение конфиденциальности данных.

Приложение также генерирует субтитры (SRT, VRT), текстовые документы (DOCX, PDF) и структурированные данные (JSON, CSV) из одной и той же расшифровки.

Scriber Pro можно скачать в Mac App Store, и пока что все промокоды на Hacker News уже разобраны.

• Privacy-first, browser-only transcription tool launched; no audio or text leaves the device.
• MacWhisper vs. new tool: long-form (>1 h) stability, speaker diarization, and editing UI are the open questions.
• Pricing: one-time $3.99 vs. subscription; model is downloaded on first run, not bundled with the app.
• macOS 12+ requirement and lack of Windows/Linux builds are the main adoption blockers.
• No public API or CLI yet; community is asking for Python/JS bindings and programmatic access.

В GitHub создан новый инструмент для управления задачами «Firm», который предназначен для разработчиков и технических специалистов. Он использует текстовый интерфейс для управления проектами, задачами и багами, интегрируясь с Git. Основная идея в том, чтобы обеспечить прозрачность и избежать навязывания конкретных инструментов, сохраняя при этом простоту и эффективность.

Инструмент позволяет создавать и отслеживать задачи прямо из командной строки, что ускоряет workflow. Он также поддерживает интеграцию с другими инструментами, такими как GitHub Issues, делая его мощным дополнением для разработчиков, уже использующих Git.

Ключевая особенность — минималистичный дизайн, который не мешает основной работе, и возможность настройки под конкретные нужды команды. Это пример того, как open-source инструменты могут улучшить продуктивность без добавления излишней сложности.

• Пользователи обсуждают CLI-ориентированные инструменты для управления бизнесом, но признают, что для широкого распространения нужен GUI.
• Обсуждается, что текстовые форматы (JSON, YAML) могут быть более удобны для LLM и человека, но вызывают проблемы с масштабируемостью и обработкой больших объемов данных.
• Участники отмечают, что подобные инструменты могут быть полезны для малого бизнеса и как личный инструмент разработчика, но сомневаются в их применимости для более широкого круга пользователей без GUI.
• Поднимается вопрос о том, что такие инструменты могут быть полезны для управления собственным бизнесом, но также отмечается, что для этого может быть достаточно уже существующих инструментов.
• Участники также обсуждают, что вместо изобретения нового формата данных, возможно, стоит использовать существующие форматы, такие как JSON или CSV, что может упростить интеграцию с другими инструментами.

В статье обсуждается, что главная проблема конфигурационных файлов — не синтаксис, а отсутствие абстракций. Хотя многие ругают YAML за сложность, реальная проблема в том, что даже простые форматы вроде JSON не решают проблему дублирования и ошибок вроде опечаток в числовых константах.

Автор показывает на примере: если нужно описать несколько однотипных ресурсов (в примере — cloud-бакетов для бэкапов), то даже в JSON или YAML придётся дублировать код, что ведёт к ошибкам. Например, в одном месте указали 2592000 секунд (30 дней), а в другом — 259200 (пропустили ноль), и из-за этого данные удаляются через 3 дня, а не 30.

Решение — использовать язык конфигурации, который поддерживает абстракции, как в языках программирования. Например, RCL позволяет использовать переменные, циклы и вычисления, что исключает ошибки из-за опечаток и дублирования. Так, вместо шести повторяющихся блоков конфигурации можно написать один цикл, который сгенерирует их все, гарантируя, что все значения согласованы.

Хотя некоторые форматы (как HCL) тоже поддерживают выражения, важно, чтобы их хватало для полного устранения дублирования. Поэтому при выборе формата конфигурации стоит смотреть не только на синтаксис, но и на возможность абстракций.

• Обсуждение в основном вращается вокруг того, что конфигурационные языки (YAML, JSON, TOML и т.д.) не масштабируются и не имеют абстракций, что приводит к необходимости встраивать в них полноценные языки программирования, что в свою очередь создает проблемы безопасности и предсказуемости.
• Участники обсуждения подчеркивают, что вместо того, чтобы изобретать новые конфигурационные языки, следует использовать существующие общеязыковые инструменты (Python, Lisp и т.д.) для конфигурации как код, что позволит избежать проблем с безопасностью и сложностью.
• Некоторые участники также упоминают, что проблема не в синтаксисе или структуре данных, а в отсутствии стандартного языкового сервера для конфигурационных файлов, что делает невозможным автодополнение и переход к определению.
• Также поднимается вопрос о том, что если конфигурационный язык предоставляет возможность встраивать код, то это может быть использовано для вредоносных целей, и вопрос о том, как обеспечить безопасность таких файлов, становится критически важным.
• В конце концов, обсуждение сходится на том, что вместо того, чтобы продолжать изобретать новые конфигурационные языки, следует использовать существующие языки программирования и инструменты, которые уже решают эти проблемы.

MAML — это минималистичный формат для данных, который сохраняет читаемость для человека и при этом остаётся простым для машинной обработки. Он сочетает лучшее из JSON, дополняя его комментариями, многострочными строками и необязательными запятыми и кавычками.

MAML уже реализован в нескольких языках, включая JavaScript, Python, Rust, C и PHP. Эти реализации находятся на разных стадиях разработки: от готовых к использованию до находящихся в активной разработке.

Проект полностью открыт, с кодом на GitHub, и распространяется по лицензии MIT, что позволяет свободно использовать, модифицировать и распространять его.

• Обсуждение вновь подтвердило, что вместо улучшения JSON/YAML/TOML появляется всё больше новых конфиг-языков, но никто не решает их проблемы с синтаксисом, датами, комментариями и т.д.
• Участники обсуждения отмечают, что большинство этих новых языков не решают фундаментальные проблемы, такие как отсутствие типов данных, дат и комментариев в JSON.
• Некоторые комментаторы подчеркивают, что вместо того, чтобы изобретать новые языки, лучше бы улучшить существующие инструменты, такие как JSON5 или TOML.
• Другие участники поднимают вопрос, что если бы разработчики потратили усилия на улучшение существующих инструментов, вместо создания новых, это было бы более продуктивно.

К сожалению, в вашем запросе нет достаточной информации для создания пересказа статьи. Вы предоставили только название "Pointer Pointer" и сообщение о необходимости включить JavaScript для работы приложения.

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

• Старый проект pointerpointer.com (2006) использует JSON-файл с 700+ фото и алгоритм выбирает ближайшее по положению курсора, что делает невозможным «подглядывание» за кадром.
• Пользователи спорят, были ли фото подобраны вручную или с помощью OpenCV, но большинство склоняется к ручному отбору.
• Ностальгия и культурный феномен: обсуждение вызвало волну воспоминаний и вопрос о том, как именно собирались эти изображения.
• Пользователь предложил форк с котами, которые бы «ловили» курсор лапками.

Колин Коглен рассказывает, как подключил к интернету недорогую метеостанцию с Aliexpress, используя дешёвый SDR-приёмник для приёма её сигналов и софт rtl_433 для их декодирования. Полученные данные он отправляет через скрипт на PowerShell в APRS — любительскую сеть для обмена погодными данными.

Сначала он парсит JSON-данные с метеостанции, фильтруя только нужные значения температуры и влажности, и игнорируя помехи от соседских датчиков. Эти данные затем передаются утилитой aprs-weather-submit в сеть APRS, где они отображаются на сайтах вроде APRS.fi.

Колин отмечает, что несмотря на кажущуюся сложность, решение достаточно простое и дешёвое. SDR-приёмник за 30$ подключается к компьютеру, ПО бесплатно, а APRS позволяет публиковать данные анонимно, без регистрации. Это демонстрирует, как открытые стандарты и ПО позволяют элегантно решать задачи, превращая простой девайс в часть интернета вещей.

• Обсуждение показало, что "IoT" часто сводится к простейшему датчику и 40-летнему протоколу, который превосходит коммерческие API.
• Участники обсуждали возможность поделиться данными с другими энтузиастами и упомянули такие проекты, как Citizen Weather Observer Program и Blitzortung.
• Также обсудили безопасность и надежность таких устройств, а также их влияние на приватность.
• Участники также поделились личным опытом и обсудили, как можно было бы улучшить или расширить такие проекты.

Нейросимволический синтез программ позволяет создавать надёжные и интерпретируемые системы рассуждений, объединяя нейросетевые подходы с символической логикой. Метод генерирует формальные доказательства для каждого шага рассуждения, что обеспечивает прозрачность и проверяемость результатов, критически важные для таких областей, как автоматизированное доказательство теорем и объяснимый ИИ.

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

• Обсуждение фокусируется на гибридном подходе, сочетающем языковые модели (LLM) для генерации структурированных предположений (например, на JSON DSL или в логических синтаксисах, таких как SMT, Prolog) и последующей верификации этих выводов с помощью детерминированных решателей (таких как Z3) или теорем-проверов (как Lean).
• Участники подчеркивают как потенциал этого подхода для повышения надежности и интерпретируемости рассуждений ИИ, так и его фундаментальные ограничения, такие как «проблема автоформализации» (autoformalization gap) — риск того, что LLM некорректно переведет запрос в формальную логику, что приведет к принципу «мусор на входе — мусор на выходе».
• Приводятся практические примеры применения метода, включая проверку согласованности бизнес-политик, автоматизацию математических вычислений (например, с помощью SymPy) и синтез программ.
• Высказываются критические замечания о природе LLM: они не являются «мыслящими» системами, а лишь статистическими моделями, генерирующими правдоподобные шаблоны, и их вывод принципиально не детерминирован и может быть неполным или ошибочным.
• Обсуждаются технические детали и улучшения, такие как использование структурированных выходов API, ограниченное декодирование для повышения надежности генерации кода и необходимость более четких примеров в документации проектов.

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

Новая библиотека на Go предлагает решение: поддержку любых срезов, а не только текста, структурированный вывод для гибкости представления и эвристики для улучшения читаемости. Она сочетает предобработку, оптимизации и постобработку, чтобы избежать типичных недостатков — например, избыточных изменений или неинтуитивных сравнений. Это делает её универсальным инструментом для задач, где важны и точность, и удобство восприятия.

• Обсуждение затрагивает различные типы diff-алгоритмов (одномерные, многомерные, древовидные) и их применение, включая сравнение кода, JSON-структур и даже схем баз данных.
• Участники делятся инструментами для просмотра diff (например, diff2html, meld, Beyond Compare) и отмечают проблемы существующих библиотек, такие как неожиданное экранирование текста.
• Поднимаются вопросы о важности минимальности diff, семантического понимания перемещений блоков и использования метаданных для улучшения алгоритмов.
• Обсуждаются практические применения diff-алгоритмов за пределами контроля версий: в тестировании, юридической сфере, сравнении расписаний и обновлении терминальных экранов.
• Упоминаются конкретные личности (например, Джин Майерс) и работы (статья Nugroho 2019 года), а также выражаются пожелания по улучшению алгоритмов, например, для работы с перемещенными данными.

Контекст — это конечный ресурс для ИИ-агентов, требующий стратегического управления. В отличие от традиционного промт-инжиниринга, который фокусируется на формулировке инструкций, контекст-инжиниринг охватывает всё содержимое контекстного окна: системные промты, историю сообщений, данные инструментов и внешнюю информацию. Это особенно критично для агентов, работающих в циклах, где объём релевантных данных постоянно растёт, но эффективность модели снижается из-за «контекстного распада» — ухудшения точности recall при увеличении числа токенов.

Архитектурные ограничения трансформеров усугубляют проблему: внимание модели распределяется между всеми токенами, создавая квадратичный рост вычислительной нагрузки. Модели, обученные на коротких последовательностях, хуже справляются с длинным контекстом, даже с техниками вроде интерполяции позиционных энкодингов. Ключевой вывод: контекст нужно тщательно курировать, как稀缺ный ресурс, чтобы сохранять фокус и избегать перегрузки внимания ИИ.

• Обсуждение ограничений и инженерных подходов к работе с малыми окнами контекста (4K у Apple) по сравнению с большими окнами других моделей.
• Критика отсутствия удобных инструментов для визуализации и управления контекстом, а также предложения по улучшению (DSPy, OpenTelemetry, структурированный вывод).
• Стратегии работы с ограниченным контекстом: уточнение задачи и файлов в первом сообщении, создание новых сессий, структурирование вывода через JSON schema.
• Дебаты о том, являются ли эффективные методы инженерного контекста коммерческой тайной, и скептицизм по этому поводу.
• Прогнозы, что удешевление и увеличение контекста LLM могут сделать проблему менее актуальной в долгосрочной перспективе.

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

Особенность — отсутствие лишних зависимостей и простота внедрения, что ускоряет рабочий процесс. Например, можно быстро форматировать JSON, шифровать строки или проверять валидность кода. Практический вывод: снижает потребность в поиске разрозненных сервисов, экономя время.

• Пользователи обсуждают полезные онлайн-инструменты (CyberChef, easyinvoicepdf, cobalt.tools, simonwillison.net) и делятся своими проектами.
• Поднимаются вопросы безопасности и доверия к сторонним инструментам, а также желание видеть больше информации об их надежности.
• Предлагаются идеи для новых функций: улучшение мобильного интерфейса, добавление поиска, агрегатора инструментов, генератора QR-кодов без трекеров.
• Обсуждаются конкретные технические нужды: мерж PDF, проверка ссылок, генерация SSH-ключей, сетевые утилиты.
• Отмечается проблема с YouTube-загрузчиком и predatory-моделями монетизации некоторых сервисов (например, QR-кодов).

Typst — это новая система вёрстки документов, написанная на Rust и позиционируемая как современная альтернатива LaTeX. Она сохраняет высокое качество вывода, особенно для технических и научных материалов с формулами, таблицами и иллюстрациями, но предлагает более простой синтаксис разметки, быстрое компилирование и удобную кастомизацию. Проект развивается с 2019 года, уже насчитывает сотни контрибьюторов и постепенно получает признание в академической среде.

Ключевые преимущества Typst включают мгновенную работу со шрифтами, интерактивный режим редактирования с автоматической перекомпиляцией и поддержку современных форматов вывода. В отличие от LaTeX, он не требует гигантской установки, проще в освоении и выдаёт понятные ошибки. Хотя замена экосистемы пакетов LaTeX остаётся вызовом, Typst демонстрирует практическую ценность для тех, кто ищет лёгкий и эффективный инструмент для вёрстки.

• Пользователи отмечают значительное преимущество Typst перед LaTeX в скорости компиляции, удобстве синтаксиса и понятности диагностических сообщений.
• Многие перешли на Typst для генерации документов в продакшн-средах (инвойсы, отчёты, книги) благодаря его простоте интеграции с данными (JSON) и программируемости.
• Подчёркивается проблема принятия Typst в научном сообществе из-за доминирования LaTeX-шаблонов журналов и конференций, а также отсутствия полной поддержки инструментов вроде Zotero.
• Некоторые пользователи выражают скептицизм по поводу замены LaTeX для сложных математических формул и опасения по поводу долгосрочного развития и обратной совместимости Typst.
• Typst часто используется как замена Markdown для простых документов и заметок благодаря интуитивному формату и мгновенному предпросмотру.

Сайт представляет собой архив всех версий игр Infocom, включая исходный код и скомпилированные файлы. Каждый пакет помечен серийным номером и датой компиляции, что позволяет восстановить хронологию разработки. Коллекция сосредоточена на оригинальных релизах и фанатских модификациях 1980-х годов, исключая современные пересборки и исправления ошибок.

Основой архива послужили материалы, опубликованные Джейсоном Скоттом в 2019 году, но здесь добавлены пропущенные вариации, бета-тесты и исправлены ошибки GitHub-репозиториев. Файлы доступны для скачивания в форматах JSON и ZIP. Автор подчёркивает историческую ценность коллекции, несмотря на юридическую неоднозначность распространения проприетарного контента.

• Рекомендуется начинать знакомство с текстовыми квантами не с Infocom (например, Zork), а с более дружелюбных к игроку игр, таких как Glowgrass или Lost Pig.
• Обсуждается применение LLM (языковых моделей) для улучшения парсеров команд и создания более естественного диалога с NPC, что может привлечь новое поколение игроков.
• Упоминаются ресурсы для поиска и оценки игр (база данных IFDB) и авторские системы для их создания (IFWiki), а также подкасты, посвящённые Infocom.
• Отмечается историческая и культурная значимость Infocom, а также тот факт, что бренд был продан Activision и использовался для публикации игр после закрытия оригинальной студии.
• Высказываются личные воспоминания и опыт игры в классические кванты, такие как Trinity или A Mind Forever Voyaging, подчёркивающие их художественную ценность.

Moondream 3 — это предварительная версия модели компьютерного зрения с архитектурой MoE на 9 млрд параметров, из которых активно используются только 2 млрд. Это позволяет ей достигать уровня передовых моделей в задачах визуального анализа, сохраняя при этом высокую скорость и низкую стоимость инференса. Ключевые улучшения включают расширение контекста до 32 тыс. токенов, лучшую обучаемость (включая обучение с подкреплением) и нативную поддержку сложных запросов, таких как детекция объектов, указание на элементы и структурированный вывод.

Модель демонстрирует впечатляющие результаты: точно определяет объекты по описанию (например, «бегун в фиолетовых носках»), генерирует JSON по изображению, преобразует таблицы в Markdown и работает с OCR. Несмотря на компактность, в бенчмарках она конкурирует с топовыми решениями, но делает это в разы быстрее и дешевле, что открывает возможности для массового применения в робототехнике, медицине и системах наблюдения.

• Moondream 2 и 3 высоко оцениваются за точность и скорость в задачах автоматической разметки датасетов и детекции объектов, особенно для краевых устройств.
• Архитектура MoE модели с активацией только 2B параметров считается прорывом для развертывания на edge-устройствах из-за низкой задержки и стоимости инференса.
• Отмечаются проблемы с точностью (precision) в последних релизах, а также отсутствие информации о ценах в облаке и временная лицензия BSL для превью Moondream 3.
• Модель демонстрирует впечатляющие результаты в сравнении с крупными коммерческими аналогами (Gemini, Claude, OpenAI), особенно в задачах, смежных с OCR.
• Потенциальные применения включают автоматизацию работы с UI, анализ графиков и диаграмм, а также управление компьютером/браузером.

Dayflow автоматически создаёт таймлайн дня на основе данных с устройств Apple. Он использует машинное обучение для анализа активности, местоположения и приложений, превращая сырые данные в структурированную хронологию событий. Это помогает пользователям визуализировать, как проходит их день, без ручного ввода.

Проект работает локально, обеспечивая конфиденциальность данных, и поддерживает экспорт в JSON или Markdown для дальнейшего использования. Полезно для самоанализа, ведения дневника или отслеживания продуктивности.

• Предложения по применению: для юристов и фрилансеров для учёта рабочего времени, для людей с СДВГ для анализа отвлечений, для автоматизации отчётов на стендапах.
• Обеспокоенность приватностью и безопасностью: отправка скриншотов в облако вызывает опасения по поводу паролей и конфиденциальных данных; предпочтение отдаётся локальным моделям.
• Технические вопросы и предложения: работа с несколькими мониторами, частота записи, интеграция с другими данными (Apple Health), создание API для расширений.
• Юридические и этические аспекты: необходимость согласия на запись в видеозвонках, потенциальное misuse со стороны работодателей для контроля сотрудников.
• Позитивные отзывы: отмечается удобство, качественный UX и возможность использования локальных моделей для конфиденциальности.

YAML позиционируется как удобный для человека формат данных, но на деле оказывается чрезвычайно сложным и полным скрытых ловушек. Его спецификация занимает 10 глав с многоуровневой структурой, в отличие от лаконичного JSON, чья спецификация умещается в шести диаграммах и почти не менялась два десятилетия. YAML активно развивается: версия 1.2 существенно отличается от 1.1, что приводит к разному parsing одних и тех же документов в разных реализациях.

Пример документа с настройками сервера демонстрирует проблемы YAML: числа вида 22:22 могут интерпретироваться как sexagesimal (1342) в версии 1.1, но как строка в 1.2. Якоря (&) и алиасы (*) усложняют чтение, а теги (!) создают угрозу выполнения произвольного кода при загрузке ненадёжных данных. Известная «проблема Норвегии» (неожиданная интерпретация сокращений стран) подчёркивает, что попытки быть «дружелюбным» формат делают его непредсказуемым и опасным.

• Критика YAML за его сложность, неоднозначность и множество подводных камней, таких как проблемы с автоматическим определением типов (например, "no" интерпретируется как false).
• Предложения использовать альтернативы: JSONC, TOML, HCL, Dhall, Jsonnet, CUE или всегда заключать строки в кавычки в YAML для избежания ошибок.
• Обсуждение отдельных проблемных особенностей YAML, таких как якоря/алиасы, сексегесимальные числа и необходимость в линтерах.
• Отмечается, что, несмотря на недостатки, YAML остается популярным из-за удобочитаемости и широкой распространенности.
• Упоминание, что спецификация YAML 1.2 (2009 г.) исправила некоторые проблемы, но многие issues остаются актуальными.

Миниатюрная библиотека sj.h для парсинга JSON весит всего 500 строк кода и использует единственный заголовочный файл. Она спроектирована для минимализма и эффективности, поддерживая базовые операции: разбор строк, чисел, булевых значений, массивов и объектов.

Библиотека не требует динамического выделения памяти, что делает её идеальной для встраиваемых систем и сред с ограниченными ресурсами. Её API интуитивен — всего несколько функций для доступа к данным, что снижает порог входа. Практический плюс: легко интегрируется в существующие C-проекты без зависимостей.

• Обсуждаются достоинства библиотеки автора: однофайловые решения на ANSI C/Lua с фокусом на простоту, удобный интерфейс и хорошую документацию.
• Отмечаются потенциальные проблемы безопасности и корректности: отсутствие проверок на переполнение целых чисел, возможное неопределённое поведение, слабая валидация JSON.
• Поднимается вопрос о целесообразности использования: обсуждаются нишевые применения (например, embedded), недостатки для продакшена и альтернативные библиотеки.
• Упоминается необходимость тестирования на соответствие стандарту (конформность) и handling edge cases.
• Обсуждается философия подобных минималистичных библиотек: свобода от избыточной сложности ценой отказа от безопасности и обработки всех крайних случаев.

Файлы конфигурации — это пользовательские интерфейсы. Мы часто сталкиваемся с ситуацией, когда растущее ПО требует настройки, но полноценный графический интерфейс кажется избыточным. Прагматичное решение — текстовый файл конфигурации, который легко версионировать и который оставляет возможность для будущего развития.

Выбор языка для конфигурации — непростая задача. JSON кажется слишком техническим, TOML — слишком минималистичным. И тут возникает соблазн использовать YAML: он приятен глазу и популярен. Однако за кажущейся простотой скрываются pitfalls, как показывает печально известный «документ из ада». Со временем даже небольшой YAML-файл может превратиться в кошмар поддержки.

Корень проблемы не в выборе языка (YAML vs. альтернативы), а в том, что мы недооцениваем конфигурационные файлы как пользовательские интерфейсы. Они должны обеспечивать отличный UX: предотвращать ошибки, вести пользователя к успеху и работать как «велосипед для ума».

Пример реализации такого подхода — проект KSON, который позиционируется как более эффективная альтернатива YAML/JSON/TOML. KSON является верифицированным надмножеством JSON, поддерживает JSON Schema и предлагает инструменты для улучшения работы с конфигурациями.

• Критика KSON за отсутствие чувствительности к пробелам, что может приводить к неочевидным ошибкам парсинга, как в примере с вложенным списком портов.
• Обеспокоенность рисками безопасности из-за единственной реализации на Kotlin и сложностей сборки для других языков, таких как Python и Rust.
• Предложение использовать полноценные языки программирования (например, Python) для конфигурации вместо специализированных форматов, чтобы дать пользователям больше инструментов.
• Аргумент в пользу того, что конфигурационные форматы должны быть выразительными, но ограниченными (как Cue, Starlark или Dhall), а не просто данными, как JSON или YAML.
• Подчёркивание различия между форматами для людей (конфигурация) и для компьютеров (данные), и критика попыток совместить их в одном формате.
• Замечание, что сложная конфигурация часто указывает на проблемы в дизайне ПО, и что лучше предоставить пользовательский интерфейс вместо сложных файлов.
• Упоминание альтернатив, таких как TOML, HJSON, HOCON, KDL и Jsonnet, с различными подходами к простоте, выразительности и проверке типов.

Murex.Rocks

Интуитивная и контекстно-ориентированная оболочка для современной командной строки.

Современная оболочка для всех

Murex предлагает множество уникальных возможностей:

Контекстная осведомленность

Нативная поддержка форматов данных: JSON, YAML, CSV и других. Типы данных могут быть явно приведены или выведены автоматически.

Выражения

Умная обработка переменных и выражений для предотвращения ошибок. Больше не нужно беспокоиться о специальных символах в именах файлов.

Интерактивность

Интуитивная интерактивная оболочка с подсказками из man-страниц и интеграцией с ИИ.

Расширяемость

Встроенный менеджер пакетов для простого обмена конфигурациями и переноса окружения между машинами.

Начало работы

• Тур по языку для старта
• Rosetta Stone как шпаргалка с сравнением Bash
• Интерактивная оболочка для использования в командной строке

Простая установка

Установите murex через ваш пакетный менеджер:

macOS:

brew install murex
# или
port install murex

Arch Linux:

wget -O PKGBUILD 'https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=murex'
makepkg --syncdeps --install

FreeBSD:

pkg install murex

Другие варианты в документе установки.

---

Лицензия GPLv2, Copyright © 2017-present Laurence Morgan

• Пользователи столкнулись с техническими проблемами при установке и запуске Murex, включая ошибки с aspell, HTTPS-протоколом и системными вызовами.
• Обсуждаются исторические и культурные отсылки в названии оболочки (Murex — моллюск, источник пурпурного красителя, значимый для финикийцев и иудеев).
• Поднимается вопрос о целесообразности изучения нового синтаксиса, несовместимого с Bash, и необходимости убедительных преимуществ для перехода.
• Murex сравнивается с альтернативными оболочками, в частности с Nushell и PowerShell, отмечается сходство в подходе к работе с структурированными данными.
• Критикуется маркетинг и описание проекта за отсутствие конкретных примеров и явных преимуществ перед существующими решениями.
• Отмечается, что для широкого применения скрипты должны быть совместимы с Bash, что ставит под вопрос нишевый потенциал Murex.
• Некоторые пользователи выражают заинтересованность в тестировании Murex при условии, что он будет стабильным и быстрым.

Блог asciinema

• Начало работы
• Исследовать
• Форум
• Нанять меня!

3.0 Опубликовано 15 сен 2025, Марчин Кулик

Рад объявить о выпуске asciinema CLI 3.0!

Это полная переписывание asciinema на Rust с обновлением формата файлов записи, добавлением live-стриминга терминала и множеством улучшений.

В этом посте я расскажу о ключевых моментах релиза. Подробности смотрите в примечаниях к выпуску и истории изменений.

Переписывание на Rust было сделано из-за моего предпочтения этого языка перед Python для работы с системными вызовами и параллелизмом. Это привело к ускорению запуска, упрощению установки (статический бинарник) и интеграции виртуального терминала asciinema.

Формат файла asciicast v3

Новый формат asciicast v3 использует интервалы времени вместо абсолютных временных меток, что упрощает редактирование записей. Заголовок был реструктурирован, добавлена поддержка события выхода ("x") и комментариев через #.

Пример записи:

{"version": 3, "term": {"cols": 80, "rows": 24, "type": "xterm-256color"}, "timestamp": 1504467315, "title": "Demo", "env": {"SHELL": "/bin/zsh"}}
[0.248848, "o", "Hey Dougal...\n"]
[0.248848, "o", "Yes Ted?\n"]
[1.001376, "o", "Is there anything on your mind?\n"]
[3.500000, "m", ""]
[0.143733, "o", "No."]
[2.050000, "r", "90x30"]
[1.541828, "o", "Bye!"]
[0.8870, "x", "0"]

Формат уже поддерживается сервером и плеером asciinema.

Live-стриминг терминала

Новый CLI позволяет транслировать сессии терминала в реальном времени с двумя режимами:

• Локальный режим использует встроенный HTTP-сервер для просмотра в доверенных сетях
• Удаленный режим публикует поток через сервер asciinema с shareable URL

Примеры:

$ asciinema stream --local
::: Live streaming at http://127.0.0.1:37881

$ asciinema stream --remote  
::: Live streaming at https://asciinema.org/s/TQGS82DwiBS1bYAY

Плеер asciinema поддерживает адаптивную буферизацию для плавного воспроизведения. Сервер может записывать live-стримы, хотя на asciinema.org эта функция временно отключена.

Локальный приоритет

Ранние версии asciinema автоматически загружали записи на asciinema.org. Теперь CLI позволяет сохранять записи локально в файл формата asciicast v1 с выбором публикации или локального хранения.

• Участники высоко оценили Asciinema, особенно за простоту использования CLI, высокое качество GIF и новую функцию live-стриминга терминала.
• Было отмечено, что сервис, несмотря на высокую нагрузку, стабильно работает всего на двух маломощных виртуальных машинах (2 ГБ RAM каждая), что демонстрирует эффективность Elixir/Phoenix и BEAM.
• CLI-часть утилиты была переписана на Rust, что также было воспринято положительно.
• Некоторые пользователи выразили пожелания, такие как нативная поддержка экспорта в SVG/GIF и встроенные инструменты для скрытия секретов в записях.
• Обсуждались возможные сценарии использования live-стриминга, в том числе для стриминга программирования без дополнительного оборудования.

oq — консольный просмотрщик OpenAPI-спецификаций.
Быстро открывает swagger.json|yaml в терминале, показывает эндпоинты, параметры, примеры ответов.
Установка: go install github.com/plutov/oq@latest.
Использование: oq spec.yaml.

• Утилита «oq» — терминальный просмотрщик OpenAPI-спецификаций, упрощающий навигацию по большим YAML/JSON.
• Пользователи практикуют spec-driven development: спецификация = единый источник правды, из неё генерируют типизированный клиент и сервер.
• Название «oq» уже занято другим проектом (homebrew-установка ставит не тот пакет); автор пока не переименовывает, предлагает брать бинарь с GitHub-релизов.
• Поддержка OpenAPI 3.1 заявлена, но реализована поверх библиотеки kin-openapi, которая 3.1 пока не умеет; для простого листинга маршрутов и компонентов это работает.
• В планах — добавить возможность делать реальные HTTP-запросы прямо из viewer.

Почему PostHog стал похож на ОС
Мы устали от типичных сайтов: бесконтентные скроллы, одинаковые вкладки, пустое пространство. Новый PostHog.com работает как ОС в браузере: окна «прилипают», есть горячие клавиши, закладки, можно читать новости, смотреть демо и играть одновременно.

Что внутри

• Проводник Windows для магазина мерча
• Продуктовые страницы в стиле PowerPoint
• Редактор документов с возможностью правки
• Форумы как Outlook Express
• Плеер QuickTime, таблицы вместо дизайна, скринсейвер и обои
• 50+ горячих клавиш

Техника
Контент отделён от визуального слоя: продукты описаны в JSON, темы и цветовые схемы настраиваются, клиентские цитаты и логотипы хранятся в одном месте и подтягиваются автоматически. Всё собрано в прод-ветке на Tailwind + TypeScript.

• Сайт PostHog выглядит как десктоп ОС в браузере: окна, таски, «окна в окнах».
• Кому-то нравится визуальный стиль и ностальгия по 90-м, но почти все жалуются на тормоза, жрущий CPU JS и поломанные привычные хоткеи/кнопки.
• Пользователи теряются: непонятно, где контент, как начать читать и что вообще продаёт компания.
• Критика сводится к «изобретаю заново мой менеджер окон», «ломает SEO и accessibility», «не работает Back, не скроллится, на мобиле ужасно».
• Некоторые считают это крутым маркетинг-ходом и «growth-hack», но сомневаются, что кто-то будет реально пользоваться.

Новый экспериментальный JSON-API в Go

Go 1.25 предлагает encoding/json/v2 и encoding/json/jsontext — переработанные пакеты для работы с JSON. Они решают давние проблемы стандартного encoding/json и пока доступны только по флагу GOEXPERIMENT=jsonv2.

Главные недостатки старого API

• Неточности синтаксиса: принимает невалидный UTF-8, дублирует ключи, трактует числа как float64.
• Производительность: 2-3× медленнее современных альтернатив; каждый вызов тратит память на рефлексию.
• Гибкость: нельзя пропустить неизвестные поля, работать с потоковым JSON, получать исходный текст, сохранять порядок ключей, использовать сторонние типы.

Что нового в v2

• Три пакета
  – jsontext — низкоуровневое чтение/запись токенов, сохраняет формат.
  – json — высокоуровневый marshal/unmarshal, совместим с v1, но строже и быстрее.
  – jsontext можно использовать отдельно для потоковой обработки.

• Строгость
  UTF-8 проверяется, дубли ключей — ошибка, числа не теряют точность.

• Производительность
  Без рефлексии в hot-path, 2-3× быстрее, меньше аллокаций.

• Новые возможности
  Пропуск неизвестных полей, сохранение порядка, работа с any, доступ к сырому JSON, совместимость с v1 через теги.

Как попробовать

GOEXPERIMENT=jsonv2 go mod download

import "encoding/json/v2"

Фидбек приветствуется: golang.org/issue/71497.

• Вышел экспериментальный encoding/json v2: новый API, лучшая производительность, но спорные решения по nil-значениям.
• Часть пользователей рада росту скорости и модульному пакету jsontext; другие считают, что костыли с nil → null остались.
• Кто-то уже прогнал тысячи тестов — почти всё прошло; кто-то нашёл регрессию аллокаций. Авторы просят больше отзывов.
• Сравнения со сторонними библиотеками (Sonic, goccy) показывают выигрыш в CPU, но проигрыш в безопасности и поддержке ARM.
• Обсуждение выродилось в холивар: «почему за 15 лет JSON до сих пор не решён» vs «две v2 за всю историю — отличный результат».

Как RSS победил Microsoft

Корпоративные гиганты пытались монополизировать контент-синдикацию, но проиграли простому формату.

ICE vs RSS: закрытость против открытости

В 1998 году Microsoft, Adobe, CNET и другие запустили спецификацию ICE — дорогой, сложный и закрытый стандарт для лицензирования и перепубликации контента. ICE обещал издателям контроль и монетизацию, но требовал $50 000 за сервер и поддержку консорциума.

RSS появился в 1999 как бесплатный XML-виджет на портале My Netscape: любой блоггер мог добавить ленту обновлений в общий список «каналов». Формат был проще, короче и не требовал денег.

Деньги vs массы

ICE продавали крупным издателям: Reuters, Vignette, iSyndicate. RSS раздавали бесплатно: первые агрегаторы Headline Viewer и my.userland.com запустились без бюджета и без лицензий. Пока консорциум взимал плату, тысячи блоггеров уже создавали ленты в блокноте.

Итог

К 2005 году ICE умер: дорого, сложно, никто не пришёл. RSS стал воздухом: читалки, подписки, podcast-фид. Победил не потому что был лучше технически, а потому что был открытым и бесплатным.

• RSS удобен читателям, но не выгоден издателям: в ленту сложно встроить рекламу и отследить аудиторию.
• Пользователи по-прежнему цепляются за RSS: уходят с платформ, которые его убрали (Twitter, Reddit), и сами собирают фиды.
• Google Reader убил, а не стандарт: после закрытия сервиса ленты исчезли, но подкасты, XKCD, Microsoft-фиды живы.
• Технически RSS «мёртв» 15 лет, по факту — нишевой, но стабильный инструмент; альтернативы (ICE, ActivityPub) не прижились.
• Новые идеи: RSS-газета на бумаге, JSON-лента, почтовые ящики внутри ридеров — всё решает те же старые проблемы монетизации и курирования.

Коротко:
Секреты в логах — это не «одним фиксом» решить нельзя. Ни 80/20, ни чудо-инструмента нет. Есть 10 «свинцовых пуль» — несовершенных, но при правильной раскладке работают.

---

Почему течёт

Причина	Пример
Прямой логинг	log.info(user) вместо log.info(user.id)
«Мусорные» дампы	logger.debug(req.headers)
Конфиги	debug=true выводит весь env
Зашитые секреты	JSON-поле password внутри структуры
Телеметрия	APM-сборщик хватает всё подряд
Пользователь	Вводит пароль в поле «имя»

---

10 «пуль»

1. Архитектура данных
   Разделяем «чувствительное» и «остальное» на уровне схемы; в логи идёт только последнее.

2. Трансформации
   Сериализуем через sanitize() или toLog() — явно выбрасываем секретные поля.

3. Domain-primitives

   • Компиляция: SecretString не реализует Display.
   • Рантайм: Redactable интерфейс, toString() → "***".

4. Read-once
   Пароль читается 1 раз, дальше объект пустой — логировать нечего.

5. Taint-tracking
   Помечаем вход как «грязный»; если доходит до логгера — exception. Дорого, но точно.

6. Форматтеры логов
   Пишем свой Layout / Encoder, который режет заранее заданные ключи рекурсивно.

7. Unit-тесты
   Проверяем assertThat(log).doesNotContain(secret); запускаем на каждый PR.

8. Сканеры
   Regex-правила + entropy-фильтры в CI и в production-потоке. Сэмплируем, чтобы не умереть от CPU.

9. Pre-processors
   Vector / Logstash / Cribl вырезают поля ещё до попадания в Elasticsearch.

10. Люди
    Code-review чек-лист: «есть ли тут .toString / JSON.stringify / printf без фильтров?».

---

Стратегия

1. Фундамент: классификация данных, единый словарь «что считать секретом».
2. Карта потока: от источника до хранилища логов.
3. Контрольные точки: валидация, sanitize, redact.
4. Защита в глубину: 2-3 слоя из списка выше.
5. План на инцидент: ротация, оповещение, forensics.

---

Итог:
Нет волшебства — только дисциплина и много мелких фиксов. Начните с 2-3 «пуль», которые дешёвле всего у вас, и двигайтесь дальше.

• Отличный пост: чёткий разбор проблемы «секреты в логах» и конкретные техники борьбы.
• Основные идеи: taint-tracking, in-band метки, GuardedString/SecureString, доменные примитивы new Secret(...).
• Сложности: стектрейсы, JSON, core-dumps, динамически создаваемые секреты, человеческий фактор.
• Защита в глубину: маскировать, ограничивать доступ к логам, не писать всё подряд, валидировать маски (Kingfisher).

GLM-4.5

• 355B параметров, 32B активных; 128K контекст; 96K выход
• MoE-архитектура, 15T токенов дообучения, RL-доработка
• Режимы: thinking (сложные задачи) и мгновенный ответ
• Инструменты, JSON, потоковый вывод, кэш контекста

GLM-4.5-Air

• 106B/12B, дешевле и быстрее, качество почти на уровне GLM-4.5

GLM-4.5-X / AirX / Flash

• X: максимум скорости и качества
• AirX: лёгкий + сверхбыстрый
• Flash: бесплатный, для кода и агентов

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

• Пользователи тестируют китайскую модель GLM 4.5 и GLM 4.5 Air от Z.ai как дешёвую замену Claude Sonnet в Claude Code и RooCode.
• Модель показывает хорошие результаты в коротких задачах, но уступает по длине контекста и стабильности.
• Подозрения, что OpenRouter и другие поставщики могут отдавать квантованные версии, что портит качество.
• Политика приватности Z.ai разрешает вечное использование отправленного кода и промптов — кто-то напуган, кто-то считает это нормой.
• Документация и интеграция вызывают нарекания: нет чёткой инструкции для Claude Code, приходится использовать прокси-обёртки.

### Скалярные типы
- `u8` 0…255  
- `i8` -128…127  
- `bool` true/false  
- `u16`, `i16`, `f32`, `u32`, `i32`, `u64`, `i64`, `f64`, `u128`, `i128`, `usize`, `isize`, `char`

### Составные
- `(T, U)` кортеж  
- `struct` именованные поля  
- `enum` варианты  
- `union` пересекающиеся данные  
- `[T; N]` массив фикс. длины  
- `()` юнит

### Безразмерные
- `[T]` слайс  
- `str` строковый слайс  
- `dyn Trait` трейт-объект  
- `&[T]`, `&mut [T]`, `&str`, `&mut str`, `&dyn Trait`, `&mut dyn Trait`

### Ссылки
- `&T` shared  
- `&mut T` mutable

### Диапазоны
- `a..b`, `..b`, `a..`, `a..=b`, `..=b`, `..`

### Утилиты
- `Option<T>`  
- `Result<T, E>`  
- `Ordering`  
- `Arguments` (format!)

### Асинхронность
- `Poll<T>`  
- `Context`  
- `Pin<T>`

### Анонимные
- `fn()` item  
- `|x| …` closure  
- `async fn` / `async ||`  
- `impl Trait`

### unsafe
- `UnsafeCell<T>`  
- `ManuallyDrop<T>`  
- `PhantomData<T>`

### Сырые указатели
- `*const T`, `*mut T`

### Указатели на функции
- `fn(T…) -> U`

### Паника
- `PanicInfo`, `Location`

### Недостижимый
- `!` never

• Пользователи сравнивают визуализацию «Elements of Rust» с периодической таблицей и другими подобными гайдами (например, cosmic.mearie.org), отмечая, что она выглядит красиво на десктопе, но неудобна на мобильных и требует горизонтального скролла.
• Некоторые находят подборку полезной для быстрого погружения, особенно если уже знакомы со статически типизированными языками.
• Критика: «таблица» кажется произвольной в группировке типов, не объясняет, почему важные концепты рядом, и из-за плотности информации может отпугнуть новичков.
• Упоминаются аналоги из C/C++, а также ссылки на другие Rust-гайды, попадавшие на HN.
• Для строковых представлений в стандартной библиотеке есть трейты Display и Debug; сериализация JSON доступна через сторонние крейты (например, serde).

• Данные на странице IMDB иерархические: фильм → режиссёр, жанры, актёры → персонажи.
• Иерархия двунаправленная: фильм→актеры и актер→фильмы.
• Реляционная БД хранит всё в плоских таблицах; при выводе строим нужную иерархию.
• Ручная сборка — утомительна, это «объектно-реляционное несоответствие».

SQL не умеет выдавать структуру
Цель: JSON вида

{"title":"Baby Driver","director":["Edgar Wright"],"writer":["Edgar Wright"],
 "genres":["Action","Crime","Drama"],
 "actors":[{"name":"Ansel Elgort","characters":["Baby"]}, …]}

Пошаговые запросы:

-- название
SELECT primaryTitle FROM title WHERE tconst='tt3890160';

-- режиссёры
SELECT p.primaryName
FROM title t
JOIN principal pr ON t.tconst=pr.tconst
JOIN person   p  ON pr.nconst=p.nconst
WHERE t.tconst='tt3890160' AND pr.category='director';

-- сценаристы
... AND pr.category='writer';

-- актёры
SELECT p.nconst, p.primaryName
FROM title t
JOIN principal pr ON t.tconst=pr.tconst
JOIN person   p  ON pr.nconst=p.nconst
WHERE t.tconst='tt3890160' AND pr.category='actor';

-- персонажи
SELECT pc.nconst, pc.character
FROM title t
JOIN principal pr          ON t.tconst=pr.tconst
JOIN principal_character pc ON pr.nconst=pc.nconst
WHERE t.tconst='tt3890160';

Попытка объединить всё в один запрос даёт декартово произведение (режиссёры×сценаристы) и пропуск записей при отсутствии одной из ролей. Поэтому приходится делать множество отдельных запросов и собирать итоговую структуру на клиенте.

• Обсуждение крутится вокруг «объектно-реляционного несоответствия»: SQL хорошо хранит нормализованные данные, но плохо отдаёт их иерархически.
• Многие считают, что виноват сам язык: нет встроенных вложенных отношений, агрегация в JSON делается громоздко, JOIN-ы приходится «переделывать» в коде.
• Часть участников предлагает решать задачу внутри СУБД: Postgres-функции json_agg, LATERAL-подзапросы, денормализованные VIEW и «JSON-проекции».
• Другие уверены, что проблема надумана: деревья в SQL вполне строятся (adjacency list, nested sets, closure table), просто нужно знать приёмы; ORM и NoSQL лишь откладывают боль.
• Упоминаются альтернативные пути: GraphQL-слой поверх SQL, графовые СУБД, документные хранилища (MongoDB), event-sourcing с CQRS, но каждый имеет свои trade-off.

ProcMon-for-Linux — порт утилиты Sysinternals Process Monitor для Linux.
Позволяет в реальном времени наблюдать за системными вызовами (open, read, write, fork, exec и др.) и событиями ядра, фильтровать, сохранять и анализировать трейсы.

Ключевые возможности

• CLI-интерфейс, знакомые фильтры pid, process, operation, path, result.
• Форматы вывода: консоль, XML, CSV, JSON.
• Поддержка x86_64, ARM64; ядро ≥ 4.9.
• Сборка: cmake, libsqlite3-dev, libncurses5-dev, libssl-dev, bcc-dev.

Установка

Ubuntu 20.04+

sudo apt install procmon

Или из исходников:

git clone https://github.com/microsoft/ProcMon-for-Linux
cd ProcMon-for-Linux
mkdir build && cd build
cmake ..
make
sudo make install

Быстрый старт

# отслеживать процесс firefox
sudo procmon -p $(pgrep firefox)

# сохранить лог в JSON
sudo procmon -p 1234 -o trace.json -f json

Лицензия

MIT.

• Пользователи обсуждают ProcMon для Linux: кто-то рад, что не придётся опрашивать /proc, кто-то сомневается в целях проекта и его отличии от htop+strace.
• Интересуются совместимостью вывода с Windows-версией и поддержкой телеметрии, а также жалуются на старый INSTALL.md и ограниченные требования (Ubuntu 18.04).
• Некоторые считают утилиту TUI-обёрткой над strace, другие подчеркивают, что она использует eBPF и может следить за всеми процессами без замедления.
• Поднимаются темы «почему нужны сразу GCC и Clang» и «Microsoft всё больше делает инструменты для Linux».

Как создать инструкцию по установке MCP-сервера

1. Определите тип сервера

   • stdio – локальный процесс.
   • sse – удалённый HTTP-эндпоинт.

2. Соберите метаданные

   • Название, описание, автора, ссылку на репозиторий.
   • Требования: Node.js, Python, Docker и т.д.
   • Порт (для SSE), путь к исполняемому файлу (для stdio).

3. Сформируйте claude_desktop_config.json
   Пример stdio:

   {
     "mcpServers": {
       "my-server": {
         "command": "node",
         "args": ["build/index.js"],
         "env": { "API_KEY": "xxx" }
       }
     }
   }
   

   Пример SSE:

   {
     "mcpServers": {
       "my-server": {
         "url": "http://localhost:3000/sse",
         "headers": { "Authorization": "Bearer xxx" }
       }
     }
   }
   

4. Сгенерируйте инструкцию

   • Установите зависимости (npm i, pip install -r requirements.txt).
   • Скопируйте claude_desktop_config.json в %APPDATA%\Claude\ (Win) или ~/Library/Application Support/Claude/ (macOS).
   • Перезапустите Claude Desktop.

5. Проверьте работу
   Откройте Claude → шестерёнка → Developer → MCP → убедитесь, что сервер “Connected”.

6. Опубликуйте
   Добавьте README.md с шагами выше и примером конфига.

• Пользователи хотят не просто «забронировать», а исследовать: «покажи самые дёшевые окна в Токио за 3 месяца».
• Все сходятся, что полностью автономное бронирование пока ненадёжно: доверие к ИИ низкое, цены скачут, а условия договора надо принимать вручную.
• MCP-серверы рассматриваются как новая «AI-API» — удобно для агентов, но бизнес может быстро закрыть доступ, если это ударит по рекламе и контролю.
• Kiwi и прочие агрегаторы могут зарабатывать на самой продаже билетов и страховках, а не на рекламе, но риски покупки у посредников остаются.
• Пока что MCP-инструменты лучше работают как «умный поиск с последующим подтверждением человека», а не как полностью автономный консьерж.

Monodraw — редактор ASCII-графики для macOS (11 Big Sur+).
Пробная версия бесплатно, лицензия — $9.99, скидки для учебных заведений.

Возможности

• Диаграммы: структуры данных, алгоритмы, ER-диаграммы (нотация «Crow’s Foot»).
• Mind-map: свободное размещение текста на бесконечном холсте.
• Баннеры: 148 встроенных шрифтов FIGlet, изменение размера и выравнивание.
• Инструменты: прямоугольники, линии (ортогональные, лестницы), текст, карандаш, ластик, заливка, пипетка.
• Точки крепления: линии автоматически цепляются к фигурам.
• CLI: генерация документации в хуках Git, экспорт JSON.
• Группы, направляющие, фокус-режим, горячие клавиши для быстрой работы.

Экспорт: PNG, SVG.

• Разработчик Monodraw отвечает на вопросы; пользователи делятся альтернативами (asciiflow, textik, durdraw, REXPaint).
• Все хвалят чистоту результата, низкую цену ($10 навсегда) и удобство вставки ASCII-диаграмм прямо в код или документацию.
• Основные сценарии: комментарии в исходниках, схемы сетей, баннеры серверов, ASCII-анимации, план кухни.
• Главный недостаток: приложение только для macOS; много просьб портировать на Linux.
• Новая текстовая разметка (апрель 2025) улучшает работу с системами контроля версий.

GNU Artanis — первый production-ready веб-фреймворк на Scheme. Лёгкий, быстрый, с поддержкой JSON/XML/SXML, WebSocket, i18n, MySQL/SQLite/PostgreSQL, кэширования, шаблонов и статики.

(use-modules (artanis artanis))
(init-server)
(get "/hello" (λ () "hello world"))
(run #:port 8080)

Скачать

• GNU FTP
• GitLab

Документация
Официальное руководство

Исходники

• Savannah: https://savannah.gnu.org/projects/artanis
• GitLab: https://gitlab.com/hardenedlinux/artanis

История
2013 — рождение на hack-potluck Guile; 2014 — награда «Lisp In Summer Projects»; 2015 — первая стабильная версия и вступление в GNU; 2021 — переход под крыло HardenedLinux.

Контакты
Почта: artanis@gnu.org
GitLab: https://gitlab.com/hardenedlinux/artanis

• Участники обсуждают фреймворк Artanis для Guile Scheme: кто-то хвалит простоту синтаксиса и встроенный веб-сервер, кто-то жалуется на отсутствие CSRF, 404-ссылок и слабое tooling.
• Почему Guile не стал популярен? Недостаток LSP, отладки, туториалов и узкая аудитория.
• Название «Artanis» — отсылка к Sinatra (Ruby) и палиндрому «Sinatra» задом-наперёд.
• Сайт без JS и шрифтов выглядит чисто, но кто-то считает текст слишком крупным и структуру странной.
• По безопасности: при грамотных разработчиках Scheme-системы могут быть безопаснее «обычных».

Base — компактный и мощный редактор SQLite для macOS.

Скачать бесплатно | Купить

Возможности

• Инспектор схем
  Быстро просматривайте структуру таблиц, типы столбцов и связи без SQL.

• Визуальный редактор таблиц
  Создавайте и изменяйте таблицы мышью, без CREATE/ALTER.

• Браузер данных
  Просматривайте, фильтруйте и правьте записи прямо в таблице.

• SQL-редактор
  Пишите запросы с подсветкой синтаксиса, автодополнением и сохранением сниппетов.

• Импорт/Экспорт
  Загружайте CSV и SQL-дампы; выгружайте в CSV, SQL, JSON и Excel.

Системные требования

macOS 15 Sequoia и выше.
Бесплатная версия ограничена; полная — единоразовая покупка.

Документация | Контакты

• Пользователи удивлены, что Base существует уже 15 лет, но плохо заметен в поиске.
• Хвалят «ремесленный» подход: маленькая команда, узкая задача, высокое качество.
• Часто сравнивают с TablePlus, Postico и sqlitebrowser, отмечая превосходство в «родном» macOS-UX.
• Просят добавить DuckDB, UUID, автозагрузку расширений, FK по умолчанию и диаграммы схемы.
• Покупатели благодарны за возможность покупки вне Mac App Store и за льготную цену.

sping — терминальный мониторинг задержек HTTP/TCP с живыми графиками. Установка: pip install service-ping-sping.

Быстрый старт

sping google.com                 # HTTP
sping tcp://google.com:80        # TCP
sping https://api.example.com -i 0.5 -c 20
sping example.com --json -c 5

Возможности

• HTTP/HTTPS/TCP, разбивка по фазам (DNS, TLS, запрос, ответ).
• Авто-обнаружение выбросов по MAD (6× медиана).
• Пороги warning/critical, выбор IPv4/IPv6, кэш DNS.
• Процентили p50-p99, экспорт JSON, 8 цветовых тем.
• Bearer/Basic-аутентификация, кастомный User-Agent.

Примеры

sping api.example.com -X POST --body --auth "bearer:token"
sping tcp://localhost:5432 -i 0.1
sping example.com --warn 100 --crit 500 --percentiles

Ключи

-i интервал, -c число запросов, --timeout, --ipv4/--ipv6, --resolve-once, --body, --no-keepalive, --insecure, --warn/--crit, --percentiles, --palette <theme>.

• Пользователи хвалят визуальный ping-утилиту sping, но предлагают переписать её на Go/Rust для статического бинарника без зависимостей.
• Автор подтвердил, что проект полностью сделан с помощью ChatGPT и Claude, а README «украшен» эмодзи.
• Найдены мелкие баги: ошибка палитры цветов и сбой при выводе финального резюме.
• Некоторые сравнивают инструмент с mtr, tracepath и nping --tr, отмечая, что нужен более дружелюбный аналог.

Краткое руководство по хорошему API-дизайну

Хороший API — это скучный API. Пользователю должно быть интуитивно понятно, как им пользоваться, без чтения документации. Однако, в отличие от большинства систем, API почти нельзя менять: любое изменение ломает чужой код и толкает клиентов к конкурентам.

Не ломаем userspace

• Добавлять поля можно.
• Удалять, менять тип или структуру полей — нельзя.
• Даже опечатка в HTTP-заголовке referer навсегда останется опечаткой, потому что «мы не ломаем userspace».

Как изменять API без боли

Если изменение критично, используйте версионирование:

• Параллельно запускаем старую (/v1/) и новую (/v2/) версии.
• Сообщаем клиентам, ждём месяцы или годы, затем выключаем старую.
• Stripe и OpenAI делают именно так, но это всё равно «зло из необходимости»: путает пользователей и усложняет поддержку.

Итог: проектируйте API так, чтобы не пришлось его трогать.

• «Никогда не ломать userspace» — про стабильность обещанного интерфейса; внутренние kernel-API могут меняться без предупреждения.
• Версионирование спорно: кто-то советует закладывать /v1 сразу, кто-то — избегать /v2, чтобы не плодить долгую поддержку.
• Идемпотентность считается обязательной: ключ лучше хранить в той же транзакции, что и мутация, а не в Redis.
• Cursor-пагинация удобнее offset: не повторяет элементы при добавлении новых данных.
• «API» — это не только HTTP/JSON, но и любой программный интерфейс; термин стал слишком узким в веб-контексте.

RFC 9839 и плохой Unicode

Unicode хорош, но не все его символы. Часто приходится исключать «проблемные». Чтобы формализовать это, мы с Полом Хоффманом написали черновик, и теперь он стал RFC 9839 — всего 10 страниц, читайте, если проектируете текстовые поля.

Пример боли: JSON-поле username может содержать:

• U+0000 — нулевой байт, ломает языки;
• U+0089 — устаревший C1-контрол «HTJ»;
• U+DEAD — несвязанный суррогат, запрещён в UTF-8;
• U+7FFFF — «noncharacter», не должен передаваться.

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

Не вините Дуга Крокфорда: JSON создавался раньше, когда Unicode был молод. Но теперь нужен способ явно сказать «эти символы не нужны».

PRECIS (RFC 8264, 2002) уже решал похожую задачу, но 43 страницы сложностей и привязка к конкретной версии Unicode мешают внедрению. RFC 9839 проще и тупее — и, возможно, именно поэтому пригодится.

• Участники спорят, нужно ли на уровне JSON/протокола запрещать «плохие» символы Unicode (управляющие, суррогаты, заломы направления и т. д.) или оставить это прикладной валидации.
• Одни считают, что жёсткие ограничения защищают от ошибок и атак (RTL-override, залого-текст, сломанные UTF-16-реализации).
• Другие указывают на полезные кейсы C0-символов (EOF, ESC, разделители) и опасаются, что «закрыть и забыть» приведёт к 20-летней несовместимости (эмодзи, старые файлы).
• Ссылаются на RFC 8264/9839 и PRECIS-фреймворк как готовый список «что разрешать», но подчёркивают: правило должно быть явным, а не «тихо удалять».

Кратко: стандартизировать в браузерах XSLT 3.0 нецелесообразно.
Технология мало используется, реализация сложна, а современные подходы (JS-шаблонизаторы, Web Components, SSR) решают те же задачи быстрее и проще.

• Пользователи мечтают о «навсегда-статическом» сайте без обновлений зависимостей; кто-то до сих пор использует PHP-include, кто-то — <template>+JS.
• Появилась фантазия «а вдруг браузеры вернут XSLT 3.0»; сторонники называют это разделением данных и представления, скептики — «громоздким XML-гипертекстом».
• Поддержка XSLT в браузерах всё ещё есть, но фактически мертва: Google убирает упоминания из спецификаций, а правительственные сайты жалуются на поломки.
• Основные претензии к XML/XSLT: чрезмерная многословность, сложность ручного редактирования, жёсткая типизация и «всегда есть пять способов записать то же самое».
• JSON и современные SSR-шаблонизаторы оказались проще и быстрее, поэтому даже ностальгирующие разработчики признают: «красивый, но неудобный» стандарт проиграл конкуренцию сетевым эффектам и эргономике.

Основы AT Protocol

AT Protocol (ATProto) — это архитектура, на которой построена соцсеть Bluesky. Bluesky — лишь одно из приложений-«сервисов» в экосистеме ATProto, наряду с WhiteWind, Leaflet, Tangled и др. Все они используют общие механизмы, но разные типы данных и правила. Сообщество называет всё это «Atmosphere».

Базовые блоки

• Record — JSON-объект (пост, профиль и т.д.).
• Blob — бинарные файлы (картинки, видео).
• Collection — группа записей одного типа.
• Repository (repo) — полный набор коллекций пользователя, подписанный его ключом.
• DID — глобальный идентификатор вида did:plc:… или did:web:….
• Handle — человекочитаемый @имя.bsky.social, привязан к DID через DNS TXT-запись.

Серверы

• PDS (Personal Data Server) — хранит репозиторий, принимает новые записи, раздаёт их по запросу.
• Relay — собирает все репозитории, строит глобальный индекс и рассылает «car files» подписчикам.
• AppView — фильтрует и форматирует данные для клиентов (например, Bluesky AppView отдаёт ленту постов).
• Labeler — добавляет метки (NSFW, спам и т.д.) к записям.
• Firehose — поток всех новых записей от Relay; любой может подписаться.

Как это работает

1. Пользователь публикует пост через клиент → PDS сохраняет запись в репозиторий.
2. PDS сообщает Relay об изменении.
3. Relay рассылает diff подписчикам (AppViews, сторонние сервисы).
4. AppView отдаёт клиенту готовую ленту, уже отфильтрованную и обогащённую.

Децентрализация

• Любой может запустить свой PDS, Relay, AppView или Labeler.
• Пользователи мигрируют между PDS, сохраняя DID и подписи.
• Сейчас большинство использует PDS и Relay от Bluesky, но сеть открыта для альтернатив.

Далее

В следующих частях — сравнение с Fediverse, мифы и реальное состояние децентрализации.

• Bluesky отказался от ActivityPub ради «переносимости аккаунта» — защита от банов и закрытия серверов.
• Название AT Protocol вызвало волну ностальгии по старым AT-командам модемов (ATH0, ATDT и т.д.).
• Сейчас вокруг ATProto растёт экосистема: Pebble, Skychat, Graysky, Tangled (GitHub-like) и каталог приложений blueskydirectory.com.
• Основной недостаток — отсутствие поддержки приватных данных; над этим работают в рабочей группе, которая соберётся на IETF в ноябре.

ForgeFed — протокол федерации для хостингов кода и инструментов разработки. Он позволяет разным сайтам обмениваться репозиториями, задачами, PR и т.д., не заставляя пользователей регистрироваться везде.

Расширяет ActivityPub: серверы обмениваются JSON-объектами, а репозитории и трекеры получают «входящие» для удалённого взаимодействия.

Статус
Следить за прогрессом можно в Fediverse и чатах Matrix/Libera.Chat #forgefed.

Реализации

• Vervis — эталон.
• Forgejo — внедряет федерацию.
• Pagure: неподдерживаемый плагин.

Проект отдан в CC0; копируйте и делитесь!

• Участники обсуждают, стоит ли связываться с ActivityPub/ForgeFed для федерации форджей или проще улучшить email-интеграцию.
• Forgejo уже начал внедрение, но до практической полезности ещё «годы работы»; GitLab тоже ведёт эпик по ActivityPub.
• Мечта — самостоятельно хостить репозитории, не теряя связи с сообществом, но пока приходится мириться с GitHub ради «сетевого эффекта».
• Сомнения в надёжности ActivityPub: пропадают медиа и часть ответов, хотя это скорее проблемы серверов, а не протокола.
• Прогресс полностью зависит от числа добровольцев: спецификация и реализации развиваются только тогда, когда люди берутся за код.

ESP32-Bus-Pirate — компактный хардварный хак-инструмент на базе ESP32-S3.
Поддерживает I²C, SPI, UART, 1-Wire, JTAG, SWD, CAN, LIN, MIDI, PWM, GPIO, WS2812 и др.
Управляется через веб-CLI (Wi-Fi AP или STA), OTA-обновления, JSON-API, скрипты Lua.

Особенности

• 2×15 пинов, 3,3 В/5 В, защита 5 В-толерантность
• Питание USB-C 5 В или внешнее 5–12 В
• ЖК-дисплей 0,96" SSD1306, RGB-LED, 2 кнопки
• Автономный режим: скрипты в EEPROM, запуск по кнопке

Прошивка

• PlatformIO: pio run -t upload
• OTA: http://<ip>/update

Сборка

• Плата 4-слойная, 50×25 мм
• BOM ≈ 15 $, JLCPCB+SMT

Быстрый старт

1. Подключить USB-C → точка доступа BP-XXXXXX, пароль buspirate.
2. В браузере 192.168.4.1 → вкладка Terminal.
3. i2c scan — найти адреса, spi flash id — ID чипа.

Команды

• mode i2c 100 — 100 кГц I²C
• uart 115200 — UART 8N1
• ws2812 10,255,0,0 — 10 красных LED

Сценарии

• Дамп SPI Flash, брут I²C, JTAG-отладка, LIN-шина авто.

• Новый Bus Pirate — не клон, а полностью переписанный проект, вдохновлённый оригиналом и полностью открытый.
• Пользователи уже заказывают железо (T-Embed CC1101, M5StickC2) и собираются тестировать.
• Главная фишка — поддержка 83 ИК-протоколов, что облегчает интеграцию кондиционеров в Home Assistant через ESP32.
• Некоторые жалуются: ИК всё-таки не CAN-bus, поэтому в автомобилях и новых e-bike устройство не так полезно.
• Для «неподдерживаемых» протоколов советуют подключать осциллограф и/или добавлять код самостоятельно.

MCP игнорирует 40 лет опыта RPC и обрекает компании на сбои

Проблема
Model Context Protocol (MCP) позиционируется как «USB-C для ИИ», но жертвует надежностью ради простоты. Компании внедряют его в продакшен, не осознавая, что в основе лежит архитектура без базовых механизмов, которые считаются обязательными в RPC-системах с 1982 г.

4 пропущенных урока

1. Типы данных
   UNIX RPC (1982) ввёл XDR и IDL, чтобы 32-битное целое не превратилось в мусор на другой архитектуре. MCP использует схематичный JSON: проверка типов происходит в рантайме, если вообще происходит. В результате ИИ-трейдер может ошибиться в десятичном разряде, а медицинский ассистент — перепутать дозировку.

2. Кросс-языковая совместимость
   CORBA (1991) генерировала привязки под C++, Java, Python и т. д., гарантируя, что исключение на сервере корректно обработается клиентом. MCP оставляет реализацию на усмотрение каждого языка: Python и JavaScript по-разному кодируют Unicode и float, что ведёт к тихим ошибкам интеграции.

3. Безопасность и версионирование
   gRPC и SOAP научились:

   • TLS/mTLS по умолчанию
   • строгая обратная совместимость через IDL
   • единое управление ошибками и таймаутами
     MCP не требует шифрования, не описывает, как менять контракт, и не стандартизирует retry-логику. Каждый инструмент решает сам, как сообщать об ошибке.

4. Масштабирование и наблюдаемость
   Современные RPC-фреймворки включают распределённый трейсинг, rate-limiting, circuit breaker. MCP не предоставляет ни метрик, ни механизмов отказоустойчивости. При миллионах вызовов в день компании получают «чёрный ящик», который нельзя отладить и который падает при первой же нагрузке.

Итог
Простота MCP полезна для прототипов, но в продакшене превращается в долговременный техдолг. Пока MCP не добавит IDL, строгие типы, безопасность и наблюдаемость, внедрять его в критичных системах — значит повторять ошибки, которые отрасль исправляла последние 40 лет.

• Критики считают MCP «USB-C для ИИ»: универсальным, но с расплывчатыми стандартами и слабой типизацией.
• Сторонники отвечают: именно минимализм JSON-over-HTTP обеспечил быструю массовую adoption, в отличие от громоздких SOAP/CORBA.
• Спор о схемах: MCP поддерживает JSON Schema, но валидация не обязательна, поэтому ошибки типов всплывают только в рантайме.
• Поднимаются темы безопасности и трейсинга: нет встроенного аудита вызовов и расходов, что критично для enterprise.
• Общий вывод: MCP сейчас «хорошо достаточно» для веба, но для регулируемых или высоконагруженных сред потребуется или доработка, или новая спецификация.

Системный промпт GPT-5 (сокращённо)

Ты ChatGPT на базе GPT-5, обучён OpenAI. Знания до июня 2024 г.
Поддержка изображений: включена. Личность: v2.
Не цитируй тексты песен и защищённые материалы.
Стиль: проницательный, вдохновляющий, с ясностью, энтузиазмом и лёгким юмором.
Не заканчивай вопросами о продолжении; не предлагай «хотите, чтобы я…».
Очевидный следующий шаг — делай сразу.

Доступны: Deep Research, Sora (видео) в Plus/Pro.
GPT-4.5, o3, o4-mini — для залогиненных Plus/Pro.
GPT-4.1 только в API.

---

Инструмент bio (память)

Позволяет сохранять/удалять данные между диалогами.
Пиши to=bio только plain text, без JSON.
Примеры:

• «User любит краткие подтверждения».
• «Forget что пользователь ищет духовку».

Когда использовать:

• Пользователь просит «запомнить», «забудь», «добавь в память» и т.п.
• Делай это всегда, даже если факт мелкий.
• Перед фразами вроде «понял, запомню» — сначала вызови bio.

Когда не использовать:

• Случайные, чрезмерно личные или краткосрочные детали.
• Не сохраняй чувствительные данные (раса, религия, здоровье, политика и т.д.), если пользователь явно не попросил.

• Участники сомневаются в подлинности «слившегося» системного промпта GPT-5: нет подтверждения, он слишком короткий и выглядит как результат джейлбрейка.
• Промпт перегружен мелкими тех-инструкциями: React + Tailwind, запрет JSON в to=bio, шрифты Unicode для CJK, но не упоминает CSAM, порнографию и т. д.
• Люди удивлены, что React получил отдельный блок, а не Python или другие языки.
• Обнаружены явные ошибки: «korean -->» вместо «japanese -->» и противоречивые описания моделей.
• Общий вывод: похоже на набор «заплаток», а не полный системный промпт; управление поведением модели всё ещё требует prompt-инженерии, а не только fine-tuning.

I built a JWT support library at work (https://github.com/geldata/gel-rust/tree/master/gel-jwt) and I can confirm that JWTs all sound like "eyyyyyy" in my head. Useful ones to know:- R0lGOD - GIF files- iVBOR - PNG files- /9j/ - JPG files- eyJ - JSON- PD94 - XML- MII

JSON encoding is a huge impediment to interprocess communication in NodeJS.Sooner or later is seems like everyone gets the idea of reducing event loop stalls in their NodeJS code by trying to offload it to another thread, only to discover they’ve tripled the CPU load in the main