Weball‐Katamari — захватывающий ностальгический проект, позволяющий «собирать» веб-страницы. Оригинальный bookmarklet работал через CSS-трансформации DOM, а новая версия импортирует страницу в игровой движок, что минимизирует работу с HTML. При большом количестве элементов (от нескольких сотен слов) FPS падает, и первую страницу невозможно собрать полностью, однако на современных устройствах, таких как iPhone 17 Pro Max, игра остается плавной. Для оптимизации рендеринга @x‐complexity предлагает генерировать внутренние слои шара одним объектом вместо множества отдельных элементов. Для аутентичности рекомендуется добавить оригинальный саундтрек от Bandai Namco. Популярность идеи подтверждает и аналогичная пасхалка в поиске Google.

Сайт предлагает проверить, насколько случайны ваши числа: вы называете вслух цифры от 1 до 9, а алгоритм пытается угадать каждую следующую. Перед вашим ответом «дом» как бы запечатывает свою догадку в конверт, а после — вскрывает. Первые десять чисел идут как разминка, затем начинается подсчёт. В финале вы увидите, как ваша «случайность» соотносится с результатами 206 участников психологического исследования.

«Дом» использует десять предсказателей одновременно и доверяет тому, что был точнее в последнее время: одни считают, какая цифра чаще следует за какой, другие отслеживают ваши шаги вверх-вниз. Главную работу делает предсказатель, замечающий, какие числа вы давно не называли, — люди тянутся к «забытым» цифрам, тогда как в истинно случайной последовательности каждое число независимо от предыдущих. Стартовую фору дают данные 418 человек, каждый из которых выбрал по 200 чисел от 1 до 9.

Набирать числа на клавиатуре — более слабый тест: назвать число вслух означает сначала его придумать, а на клавиатуре легко нажать не выбирая. Распознавание речи работает прямо в браузере: аудио никуда не отправляется, а речевой пакет (~31 МБ) скачивается один раз. Если подсмотреть догадку «дома», его счёт перестаёт считаться доказательством до конца розыгрыша.

Алгоритм предсказывает вводимые цифры с точностью 70–80 % при простом вероятностном моделировании, как показал эксперимент @costco. Тип ввода влияет: набор клавиш легче читается алгоритмом, голосовой ввод затрудняет предсказание, как отмечают @steve_adams_86 и @plank. При тестировании с Math.random алгоритм угадал 18 из 190 (9 %) против ожидаемых 11 % при случайном угадывании, что подтверждает его эффективность. Использование известной последовательности (π) приводит к угадыванию 1 из 10, что не лучше случайного, как показал @wren6991. Стратегии повышения случайности: менять подход после угадывания, использовать «n1+n2 mod 9+1», выбирать соседние числа, как советуют @kykat, @malfist, @Trusteando. Тёплый запуск (warm‐up) с повторением одного числа может сбить алгоритм, но затем его следует избегать, как отмечает @malfist. Некоторые участники получили очень низкое число угадываний (1 из 32), что указывает на высокую случайность, другие — высокое (9 из 117), указывающее на низкую. Алгоритм использует простую вероятностную модель, которую даже авторы экспериментов не смогли обойти, как заявляет @costco. Сайт «запечатывает» предсказания и раскрывает их после, но детали механизма не раскрываются, как спрашивает @frutiger. Алгоритм легче читает набор клавиш, голосовой ввод делает его менее предсказуемым, подтверждая различие в точности.

Pele — это новый рендерер диаграмм Mermaid в SVG, который работает без зависимостей и заметно быстрее и легче оригинала. Он поддерживает все типы диаграмм, встроенные в Mermaid 12.1.0, а тема оформления задаётся через CSS-переменные: цвета и шрифты меняются без повторного рендеринга. Достаточно передать синтаксис Mermaid в функцию render() и вставить полученный SVG в страницу.

Ключевые цифры впечатляют: сжатый размер сборки — 230 КБ против 1,6 МБ у Mermaid.js (в 6 раз меньше), время рендеринга — 0,05–0,3 мс против 6–82 мс (до 500 раз быстрее), а прямых зависимостей нет вовсе против 23 у Mermaid. На маленьких экранах Pele адаптирует компоновку, тогда как Mermaid просто масштабирует диаграмму.

Проект открыт, разработан для Obsidian и назван в честь богини вулканов и огня Пеле. Установка — через npm install pele.

Обсуждение подтверждает, что у оригинального Mermaid есть серьёзные проблемы с автоматическим расположением элементов, а Pele предлагает открытый и более гибкий рендерер, однако пользователи отмечают недостатки в темной теме, возможные баги в playground и делятся советами по альтернативным библиотекам и интеграции с CI/CD.

• Многие комментаторы (lukeify, tptacek, invokestatic) отмечают, что автоматический layout в Mermaid часто получается запутанным и топологически плохим, что делает его непригодным для сложных диаграмм.

• Совет: invokestatic советует использовать Python‐библиотеку mermaidx для генерации диаграмм в CI/CD, но предупреждает, что её layout может быть непредсказуемым и иногда приходится экспортировать PNG.

• Imustaskforhelp и blktiger подтвердили, что Pele является открытым проектом, размещённым в репозитории https://github.com/obsidianmd/pele, и предложили добавить видимую иконку GitHub для удобства.

• Совет: kepano объяснил, что Pele рендерит SVG, следуя только синтаксису Mermaid, а не его алгоритму расположения, и предоставляет режим сравнения, что решает многие жалобы на плохой layout.

• shellerik указал, что текущие примеры Pele недостаточно адаптированы к тёмной теме, что может затруднять использование в темных редакторах.

• Совет: Ancapistani отметил, что в Pele подграфы сохраняют своё направление даже при соединении с внешними узлами, что является весомым аргументом для перехода с Mermaid, несмотря на возможную разницу в скорости.

• kinduff сообщил о поломке предпросмотра Mermaid в playground Pele, а kepano запросил детали, указывая на необходимость исправления.

• Совет: dbg31415 подчеркнул, что такие инструменты позволяют интегрировать генерацию диаграмм в AI‐ассистенты (например, Claude) и сохранять их в markdown, что упрощает контроль версий.

Найден ещё один способ вызова произвольных функций в JavaScript без круглых скобок. Он основан на переопределении функции prepareStackTrace объекта Error, которая обычно форматирует трассировку стека и вызывается при обращении к свойству stack ошибки. Эта функция получает два аргумента — саму ошибку и структурированное представление стека в виде массива позиций кода. Ключевой момент: её сигнатура совпадает с сигнатурой конструктора Function, который генерирует функции, если второй аргумент — валидный код JavaScript.

Однако массив позиций кода не является валидным кодом, поэтому при попытке вызова возникает синтаксическая ошибка. Чтобы обойти это, нужно управлять результатом Array.prototype.toString(), возвращая нужный код. Автор предлагает два пути: переопределить метод константной функцией или использовать загрязнение прототипа, внедрив полезную нагрузку через Object.prototype.message и заменив Array.prototype.toString на Error.prototype.toString.

Собрав всё вместе, можно сгенерировать произвольную функцию. Остаётся её вызвать — например, через трюк с valueOf, переопределив его и приведя объект к примитиву, либо через toString с конкатенацией строки. Итоговая нагрузка: Object.prototype.message='alert\x281337\x29';Array.prototype.toString=Error.prototype.toString;Error.prepareStackTrace = Function;const x = new Error;x.valueOf=x.stack;+x; — её можно проверить прямо в консоли браузера.

Идея вызова функций без скобок реализована в разных языках через pipe‐операторы и постфиксный синтаксис. В JavaScript её практичность ограничена поддержкой только V8 и наличием альтернативных механизмов через Symbol, а также риском обфускации кода. Оператор forward pipe (|>) из ML‐семейства позволяет писать вызовы функций слева направо, улучшая читаемость порядка вычислений и заменяя вложенные скобки. В Mathematica используется постфиксный оператор //, в D — цепочки вызовов вида x.h().g().f() или x.h.g.f, что демонстрирует аналогичные возможности в других языках. В Ruby и APL традиционно применяется постфиксный синтаксис вызова функций, подтверждая, что идея «функция после аргументов» не нова. Техника с переопределением Error.prepareStackTrace работает только в V8; в Firefox и других браузерах недоступна, что ограничивает её применение. Член TC39 отмечает, что в JavaScript уже есть способы вызвать функцию без скобок через Symbol.isConcatSpreadable или Symbol.iterator, активируемые в разных контекстах. Некоторые считают такие приёмы «запретными» и используют их для обфускации кода, предполагая, что LLM‐модели могут испытывать трудности с их разбором. Стек‐ориентированные языки и традиция APL поддерживают постфиксный вызов и правосторонние «thread»‐операторы, позволяющие писать цепочки функций в виде дерева. При использовании подобных трюков следует учитывать возможные неоднозначности, когда скобки нужны для разрешения приоритета операторов, как в Ruby.

OpenCode 2.0 — крупное обновление агентной среды разработки, основанное на опыте миллионов ежедневных пользователей. Ключевое изменение — сервер теперь автоматически работает как единый фоновый процесс на машине: интерфейс TUI, веб-версия и десктопное приложение обращаются к одному центральному процессу. Программный клиент @opencode/client автоматически находит локальный сервис, что удобно для запланированных задач; сервер можно открыть другим хостам через команды /pair или opencode pair.

API переписан с нуля: старый рос хаотично и был плох, новый поддерживает почти любые сценарии. OpenCode осведомлён о собственном API и вызывает его — например, переносит текущую сессию в git worktree при начале новой работы. Выпущен новый пакет @opencode/client с клиентами для обычного JavaScript и Effect.

Режим Code Mode использует минимальный интерпретатор JavaScript из @opencode/codemode: он превращает MCP-серверы и OpenAPI-эндпоинты в функции, которые агент вызывает в скрипте — один круговой обход вместо множества вызовов, а все MCP-серверы по умолчанию работают через codemode без раздувания контекста. Добавлены фоновые субагенты (в том числе с другой моделью) и асинхронные shell-команды. Почти все функции 2.0 реализованы как внутренние плагины (их более 80), TUI-плагины стабильны, всё поддерживает горячую перезагрузку — агент может написать плагин для себя прямо в сессии. Пакет @opencode/sdk позволяет использовать OpenCode как библиотеку. При обновлении учтите несовместимости: плагины 1.0 не работают, серверный API полностью изменён, tui.json переименован в json.

OpenCode 2.0 привёл к значительным улучшениям в клиент‐/серверной архитектуре и плагинах: плагины и навыки автоматически перезагружаются, конфигурацию можно редактировать через встроенный навык, а переход на клиент‐/серверную модель повысил удобство использования. Автоматический GitHub‐апп для трекинга багов запускает тесты, получает реплики и записывает видео TUI‐ошибок, ускоряя отладку до двух минут. Опция opentunnel позволяет пробрасывать любые сервисы через уникальный поддомен *.opentunnel.xyz, упрощая удалённый доступ без дополнительной настройки. Однако версия выявила проблемы: высокое потребление памяти (до 2 ГБ), недостаточную безопасность постоянного демона, ограниченную поддержку прокси (отсутствие SOCK5 в HTTPS_PROXY), медленную работу веб‐интерфейса и сложности с буфером обмена в Ubuntu/X11. Некоторые пользователи считают постоянный демон нежелательным по умолчанию, другие — необходимым для согласованной работы клиент‐сервера. Практические советы: для ускорения установки перенаправлять вывод скрипта через cat (чтобы избежать медленного рендеринга прогресс‐бара); при переходе на 2.0 добавить отдельный sandbox (bubblewrap, firejail) вокруг клиента, так как прежний песочничный слой может стать неэффективным из‐за вызова всех инструментов через фоновой процесс; для Ubuntu/X11 проверять настройки X11‐clipboard или использовать альтернативный менеджер буфера обмена; мобильным пользователям рекомендуется использовать десктопный клиент или упрощённый UI из‐за тяжелой читаемости сайта на телефонах; для снижения нагрузки на диск регулярно очищать временные файлы (в прошлом OpenCode заполнял 2 ТБ хранилища). OpenCode 2.0 сохраняет бесплатный tier без логина, упрощая быстрый старт и привлекая новых пользователей. Пользователи ценят возможность запускать нативные приложения, подключающиеся к серверу OpenCode, что упрощает работу на удалённых хостах и делает модель более гибкой.

В 1996 году автор создал простую 2D физическую симуляцию на Atari ST в GFA BASIC, которая позже стала основой системы транспорта в Grand Theft Auto. Проект начался с модели «кирпича», затем был дополнен элементами, напоминающими игру Thrust (1986), и наконец превратился в реалистичную модель автомобиля. Ключевым нововведением стало использование полной жёсткой-телесной динамики с учётом крутящих моментов — редкость для игр того времени, где обычно применяли упрощённую точечную физику (F = ma) с «костылями» для вращения.

Сверху ядра физики был добавлен упрощённый model шин: для каждого колеса рассчитывались продольное и боковое сопротивление пропорционально скорости, без учёта реального сцепления или пределов силы. Руление меняло направление передних колёс, а ручной тормоз увеличивал сопротивление задних колёс и снижал боковое сцепление. Эта модель, хотя и физически неточная, давала ощутимую и управляемую реакцию на ввод. В recreated версии на JavaScript (Motion Lab) доступны три режима: Car, Ship и Brick, с переключением камеры (Z/X), гравитации (G) и барьеров (B). Симуляция работает с фиксированным шагом, разделяет ввод, физику и рендеринг, что делает её прозрачной и обучающей. Автор подчеркивает, что проект создан независимо и не связан с Rockstar или Take-Two.

Обсуждение подтверждает, что простая 2D физическая симуляция 1996 года легла в основу транспортной системы GTA, её эстетика и поведение до сих пор вызывают ностальгию и восхищение у игроков и разработчиков. Физика автомобилей в GTA I и II обладала уникальной играбельностью, которую последующие 3D-версии не смогли повторить. Симуляция основана на жёстком теле и модели шин с сопротивлением боковому скольжению, соответствующей классическим подходам из работ Marco Monster и Brian Beckman. Визуализации критикуют как непонятные и написанные для тех, кто уже прочитал код, а не для новичков; другие считают их второстепенными для общего понимания. Рекомендуется книга 'The Multibody Systems Approach to Vehicle Dynamics' как источник для глубокого понимания динамики транспортных средств, несмотря на её сложность. Поведение автомобиля на низких скоростях (особенно при парковке) — ключевая сложность, которую сложно смоделировать без хаков. Предлагается добавить режим 'парковочного симулятора' для практического обучения — идея поддержана другими участниками. Использование GFA BASIC на Atari ST для создания прототипа демонстрирует, как простые инструменты могут породить влиятельные системы при фокусе на игровом опыте, а не на производительности. Симуляция Thrust 1986 года упоминается как ранний пример физически основанной игры, повлиявшей на подход к моделированию движения в GTA. Поведение 'кирпича' при переключении в режим автомобиля не корректно — он не замедляется, что нарушает ожидаемую физику. В симуляции отсутствует подруливание (understeer), что делает передние колёса слишком сцепными по сравнению с реальностью. Опыт создания собственных симуляций в OpenGL и на других платформах подтверждает, что простота и чёткость модели шин — ключ к правдоподобной физике автомобиля. Проблема бокового смещения на низких скоростях решена упрощением сложной книги по динамике с помощью Stack Overflow и Google, без использования LLM.

REA — это набор инструментов для интеграции обратного инжиниринга в работу с кодинг-агентом, позволяющий анализировать программы и восстанавливать их поведение через естественные запросы. Агент использует REA для инспекции бинарников, скриптов или runtime-среды, извлекая инструкции, декомпилированный код и вызовы, чтобы объяснить, как работает конкретная функция — будь то процент в Windows Calculator или ускорение в динозаврике Chrome. После настройки через npx rea-agents@latest setup агент может отвечать на вопросы вроде «Почему 200 + 10% даёт 220?», анализируя реальный код и восстанавливая логику: в Calculator обработчик процента берёт 10% от первого числа (200 → 20) и прибавляет его, что подтверждается инструкциями и константами вроде 0x64 (=100). Аналогично, для игры T-Rex Runner REA возвращает работающий скрипт, из которого агент извлекает правило ускорения: стартовая скорость 6, прибавка 0.001 за кадр до максимума 13, что позволяет воссоздать игру с регулируемой скоростью. REA поддерживает анализ нативных бинарников, JavaScript/Electron-приложений и браузерной активности, предоставляя гайды по настройке и примерам использования — от клонирования сайта до восстановления игровой логики из exe-файла, как в кейсе DX-Ball. Всё это направлено на совместную работу человека и агента: человек ставит цель, агент восстанавливает детали, а результат — понятная, перестраиваемая реализация.

REA и связанные LLM ускоряют обратный инжиниринг, но вызывают опасения по поводу влияния на хобби, стоимости, масштабируемости и юридических рисков. AI‐декомпиляция достигает высокого качества: переменные именованы логично, комментарии понятны, но структура файлов оптимизирована под AI, что может искажать восприятие оригинального кода. Спор: @InvisibleUp считает, что массовый доступ к AI‐декомпиляции уничтожит хобби по моддингу; @testerius — что это расширит возможности, ускорит разработку инструментов и портирование игр без глубоких знаний низкоуровневого программирования. @ashdnazg: подписка $20 сокращает время декомпиляции DOS‐игр с двух недель до двух дней; с Microsoft C — ещё быстрее. @SyzygyRhythm: Claude исправил два критических бага в клиенте Remote Desktop через NOP‐ы и корректировку стека — исправление сработало. @methou: GLM‐5.3 работает с IDA Pro, Radare2 и Binary Ninja, облегчая анализ бинарных файлов. @sreekanth850: ILSpy + Codex ускоряют декомпиляцию пакетов NuGet, поиск багов и недостающих зависимостей. @mgaldys4: REA использует jadx‐mcp для Android‐обратного инжиниринга, но подготовка одного APK занимает десятки минут — не масштабируется для пакетного анализа. @armcat: Codex помог восстановить старую DOS‐игру — распаковал графику, звуки и логику, демонстрируя практическую применимость AI в ретро‐разработке. @Retr0id: крак DRM влечёт юридические риски — DMCA‐отказ и судебные иски, даже если цель — восстановление работы. @dyauspitr: лёгкий реверс может заставить компании перейти к SaaS для защиты ИС. @rvz: крупные компании (Nintendo, Nvidia) могут подавать иски за открытый исходный код, полученный через AI‐обратный инжиниринг. @bob1029: ценность реверс‐инжиниринга падает, когда системы легко собираются из компонентов — портирование целых реализаций больше не оправдано. @mb7733: установка REA через curl | bash упрощает развертывание в средах без npm.

Этот проект — сатирическое высмеивание современных AAA-игр через преувеличение навязчивого руководства, перегруженного повествования и коммерциализации, воспринимаемое сообществом как искусство и глубокая критика индустрии. Игра пародирует современные AAA-игры, где игроку постоянно диктуют действия, лишая свободы мышления и исследования, как в старых играх. Навязчивый голосовой нарратив, мешающий сосредоточиться, точно имитирует стиль Kojima и студий, чрезмерно полагающихся на повествование. Отсутствие микротранзакций, лицензионных лаунчеров и загрузочных экранов с шейдерной компиляцией подчёркивает иронию: игра намеренно избегает этих элементов, чтобы выявить их абсурдность в индустрии. Пользователи отмечают, что даже без игрового вызова и финального вознаграждения опыт воспринимается как художественное высказывание, а не как традиционная игра. Сравнение с Minesweeper из Windows NT 3.51 подчёркивает контраст между простотой классики и перегруженностью современных проектов. Отсутствие необходимости установки сторонних лаунчеров позиционирует игру как анти-ответ на современные дистрибутивные практики. Упоминания вроде «что случилось в Сингапуре?» и «production babies в титрах» показывают ожидание сообществом расширения проекта в полноценную вселенную, как у настоящих AAA-игр. Некоторые отмечают, что ценность игры — в том, что она заставляет задуматься о том, что делает игру игрой, даже если она кажется бессмысленной. Сравнение с «Bomberman: Act Zero» и «AAA Pacman» указывает на её место в более широком тренде сатирических работ, критикующих перегруженность современных игр. Игра вызывает эмоциональную реакцию — от смеха до гнева — несмотря на отсутствие реальной механики, что подтверждает её успех как сатиры. Упоминание «Rogue Sweeper» как проекта в разработке показывает, что интерес к переосмыслению Minesweeper как жанра сохраняется и развивается. Критика в стиле «где микротранзакции и подписки?» подчёркивает, что игра не только пародирует, но и указывает на коммерческие тренды, ставшие нормой в AAA.

ascii.rest — это коллекция анимированной ASCII-графики для веба, созданная @bas3line и доступная под лицензией MIT. Сайт предлагает более 100 анимаций, разделённых на категории: пейзажи (например, «alpine dawn» или «aurora fjord»), интерфейсные элементы (часы, прогресс-бары, спиннеры), данные (графики, тепловые карты, метры CPU), типографику (типа «typewriter», «glitch», «split-flap»), логотипы языков программирования (Python, Rust, JavaScript и др.) и дистрибутивы Linux (Arch, Debian, Alpine). Все анимации работают в браузере без JavaScript — только HTML и CSS, что делает их легковесными и быстрыми.

Особенно впечатляют детализированные сцены вроде «tunnel» — анимированный тоннель с движущимися плитками, и «tv-static» — имитация помех на старом телевизоре, переключающемся между тест-картинкой и шумом. Каждая анимация — это чистый, оптимизированный код, легко встраиваемый в сайты. Проект сочетает ностальгию по эпохе терминалов с современными веб-стандартами, предлагая эстетику, которая не требует тяжёлых библиотек. Исходники доступны на GitHub, что позволяет адаптировать или расширять анимации под свои нужды.

Обсуждение уточняет, что анимации относятся к цветному Unicode‐шейдеру, а не к классическому ASCII‐арту. Спор: некоторые считают, что использование цвета и Unicode‐символов делает их не настоящим ASCII‐артом, так как определение ограничивается простыми текстовыми символами. Большинство отмечают, что сайт поддерживает reduced motion: анимация останавливается на первом кадре для пользователей, избегающих движения. Пользователи сообщают о низкой частоте кадров на мобильных устройствах, особенно на главной странице, ухудшая восприятие. Есть запросы на визуальный редактор или генератор для создания собственных анимированных ASCII‐сцен. Предлагается принимать pull‐request‐ы для интеграции проекта Flow и других улучшений — сообщество хочет участвовать в развитии. Комментаторы согласны: интерес к ASCII‐арту связан с трендом ретро‐текстовых интерфейсов в UI‐дизайне. Спор: работа оценивается поляризованно — некоторые называют её «плохой» и «слишком минимальной», другие восхищаются эстетикой. Отмечено: в некоторых браузерах (например, Firefox Mobile) порядок анимаций перемешивается — требуется исправление.

Flatten SF — интерактивный инструмент, который рассчитывает оптимальные пешеходные и велосипедные маршруты по Сан-Франциско, балансируя между длиной пути и набором высоты. Он использует данные USGS 1‑метровой лидарной съёмки высоты и граф улиц из Overture и OpenStreetMap, обрабатывая более 160 000 сегментов улиц прямо в браузере. Пользователь может перемещать ползунок между «кратчайшим» и «самым плоским» маршрутом: каждый промежуточный вариант представляет собой парето-оптимальное решение — ни один другой маршрут не одновременно короче и менее крутой. Стоимость подъёма задаётся как 200 футов ходьбы за каждый фут набора высоты; за этим порогом маршруты перестают считаться практически полезными. При движении ползунка вправо маршрут никогда не становится короче и не увеличивает набор высоты — только наоборот или остаётся прежним.

Набор высоты считается как суммарный подъём (cumulative gain), а не как разница между начальной и конечной точками — это важно для холмистого рельефа Сан-Франциско. Лестницы учитываются для пешеходов, но исключаются для велосипедистов. Для велосипедистов есть дополнительная опция «prefer calm streets», которая корректирует «комфортную длину»: участки с защищённой велосипедной полосой или дорожкой (по данным SFMTA) учитываются как 0,8 от реальной длины, тихие улицы — как 1,0, а оживлённые arterials без полосы — как 1,4–2,0. Это позволяет выбирать не только короткие и плоские, но и комфортные для езды маршруты. На карте faint lines показывают альтернативные маршруты, рассматриваемые в процессе оптимизации. Поиск по адресам, пересечениям и местам работает офлайн — все данные для Сан-Франциско встроены в страницу. Исходный код, данные и полное описание метода доступны на GitHub.

Обсуждение подтверждает полезность FlattenSF, но выявляет проблемы с точностью маршрутов, неудобным UI и недостаточной атрибуцией данных. Пользователи хвалят чистый дизайн и интерактивный профиль высот, отмечая, что визуализация делает планирование приятным. Однако сообщаются неточные рекомендации: вместо ровной 23‐й авеню сервис предлагает подниматься по 25‐й, что указывает на ошибки в расчётах. В районе Mission (22‐я улица и San Jose) инструмент иногда выбирает нелогичный «захват» назад, а также вызывает вопросы по расположению цветовой шкалы и меток высоты. Пользователи предлагают добавить опцию минимизации среднего уклона (grade) вместо суммарного подъёма для более комфортных велосипедных трасс. Также предлагается интегрировать Valhalla для пошаговых указаний, хотя текущая резолюция 30 м ограничивает точность. Запрошены новые режимы: «самый крутой» для тренировок, поддержка автотранспорта с ручной коробкой передач и пользовательские кривые стоимости маршрута. Отмечена необходимость корректного указания источника данных OSM, так как отсутствие атрибуции нарушает лицензию. Интересуются переносом сервиса в другие города (Иstanbul, Сиэтл, Сидней), где также есть значительные перепады высот. Некоторые советуют использовать альтернативные инструменты (brouter.de, собственный проект steepless) для сравнения профилей высот. Несколько комментариев подчёркивают, что текущий UI позволяет в реальном времени менять баланс между длиной и подъёмом, что считается удобным.

Decisions API от OpenAI — это новый публичный бета-интерфейс, который оценивает текст, изображения или их комбинацию и возвращает типизированные ответы в 10 раз быстрее, чем Responses API. Он поддерживает три типа вопросов: predicate (вероятность условия, от 0 до 1), choice (выбор из фиксированного набора категорий) и score (вероятностно-взвешенная оценка по упорядоченным уровням, например, тяжести проблемы). Ответ содержит массив answers, где каждый элемент идентифицируется уникальным name, заданным в запросе. В настоящее время доступна только модель gpt-6-luna, и запросы отправляются на dedicated endpoint POST /v1/decisions. Входные данные должны быть встроены как base64-данные (изображения — как data URL), внешние ссылки и file_id не поддерживаются. Стоимость — $0.10 за 1M входных токенов, без платы за вывод или кэширование. API поддерживает Zero Data Retention и HIPAA-соответствие для подходящих клиентов, с обработкой данных в США и Европе. Примеры использования включают проверку фото на повреждения (visible_damage с вероятностью 0.92) и одновременную классификацию категории продукта в одном запросе. Для зависимых решений рекомендуется делать отдельные запросы (например, сначала проверить повреждение, затем определить тип ремонта). API особенно полезен для маршрутизации, фильтрации и приоритизации задач в приложениях, где нужны быстрые, структурированные решения без генерации произвольного текста. Для генерации JSON-схем или вызова функций рекомендуется использовать Structured Outputs или function calling через Responses API. SDK-требования: Python ≥3.26.0, JavaScript ≥7.30.0, Go ≥3.73.0, Ruby ≥0.101.0, Java ≥4.78.0. Релиз GA ожидается в ближайшие недели.

Decisions API быстрее, поддерживает изображения, дешевле Jev, но не имеет кэширования и вызывает вопросы о калибровке и рыночной стратегии. Обеспечивает 1 млн токенов входа и мультимодальный ввод; в тестах задержка 160–175 мс, максимум 743 мс. Стоимость $0.10 за 1 млн токенов — как у старой модели, но скорость в 10 раз выше. Отсутствие кэширования ограничивает экономию при повторных запросах и больших системных промптах. Калибровка модели неясна; вопрос о 90 % точности остаётся открытым. Поддерживает ввод изображений — чего не было у Jev — расширяя спектр применений. Ограниченное окно контекста (~64 к) остаётся неясным, что может влиять на сложные задачи. Локальные модели вроде Jev дешевле и быстрее; ожидается выпуск Jev 2. Архитектура отдельного API для решений вызывает вопросы о будущей интеграции в модели. Для удержания клиентов OpenAI и Anthropic должны сделать свои решения более «липкими», предлагая самые дешевые варианты.

example.com, зарезервированный IANA для документации, получил первое за десятилетия обновление 28 сентября 2026 года. Ранее статическая английская страница теперь поддерживает шесть языков — английский, арабский, китайский, французский, русский и испанский — с плавным переходом каждые 5 секунд. Переход реализован через постепенное изменение прозрачности (transition: opacity .4s), при этом каждый символ обёрнут в отдельный <span> с увеличивающейся transition-delay, создавая эффект печати посимвольно. Добавлен SVG-иконка книги. IANA пояснила, что цель — сохранить полезность домена как примера в документации, одновременно снижая нагрузку: основной контент вынесен в базовый HTML, а дополнительный — в JavaScript, который автоматизированные запросы часто не загружают, экономя трафик. Домен не предназначен для тестирования доступности или мониторинга, несмотря на частые попытки разработчиков использовать его для проверки сети; такие использования не рекомендуются, так как сервер не гарантирует ответа. Обновление продолжает историю редких, но значимых изменений — иногда после многолетнего молчания. DebugBear использует example.com в своём демо-проекте для отслеживания производительности и предлагает бесплатную пробную версию своих инструментов мониторинга Page Speed и Core Web Vitals.

Обсуждение показывает, что редизайн example.com привёл к поломке автоматических тестов, вызвал изменения из‐за проблем доступности (убрали анимацию и теперь показывают все языки сразу), подтвердило использование Cloudflare как CDN, подчеркнуло потенциальный рост трафика и предложило практические обходные решения, такие как публичный тест‐сервер с классическим дизайном.

• Совет: Автоматические тесты, зависящие от содержимого example.com, могут ломаться после редизайна; рекомендуется не полагаться на этот домен в тестах и мониторинге, а использовать собственные стабильно‐контролируемые эндпоинты.

• Анимация плавного перехода между языками была удалена после отзывов о плохой доступности; теперь все переводы отображаются сразу, а язык пользователя поднимается наверх согласно настройкам браузера.

• Совет: Для тех, чьи тесты сломались, доступен публичный сервер‐мок с классическим дизайном (https://example.testserver.host/), а также открытый код на GitHub, позволяющий быстро восстановить прежнее поведение.

• IANA использует Cloudflare как очередной CDN‐провайдер для example.com; вопрос о необходимости CDN считается решённым, поскольку сервис обслуживается через несколько провайдеров за годы.

• Сайт получает значительный непреднамеренный трафик, поэтому его размещение как «courtesy service» помогает предотвратить злоупотребления, например, автоматическими запросами к DNS или NTP.

• Совет: Для более точной локализации предлагалось показывать сообщение в зависимости от IP‐адреса посетителя, а не фиксировать набор из шести языков.

• Совет: Вставка статического SVG‐значка через JavaScript считается избыточной; проще включить его напрямую в HTML без дополнительного скрипта.

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

• Совет: Некоторые пользователи используют example.com как точку входа в captive‐wifi сети; изменения дизайна могут влиять на их опыт подключения.

Yes, the revised version that alternated through the translations was posted a week ago on Monday. It was revised to no longer do that on Friday based on reasonable feedback that it wasn't the best idea for accessibility. Now all the translations are presented together, but your preferred language… — @kijeda

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

Разработчики часто избегают использования нативных возможностей браузера, несмотря на их производительность и надёжность, из-за исторической нестабильности веб-платформы. Долгое время браузеры отставали от потребностей разработчиков, и библиотеки вроде jQuery заполняли критические пробелы, пока стандарты не догоняли. Даже после появления evergreen-браузеров привычка искать решения в npm осталась сильной: разработчики привыкли к знакомым интерфейсам фреймворков и библиотек, где документация понятна, примеры наглядны, а API обёрнут в удобную оболочку. Нативные API, хотя и мощные, часто кажутся «неуклюжими» или плохо документированными по сравнению с привлекательными страницами сторонних пакетов, такими как Dragula, чей сайт выглядит гораздо более приглашающе, чем сухая страница MDN.

Кроме того, существует разделение труда в экосистеме: опытные разработчики готовы использовать низкоуровневые DOM-операции в библиотеках, если они скрыты за привычными абстракциями вроде JSX или хуков React. Это позволяет новичкам работать с высокоуровневыми primitives, не погружаясь в сложности платформы. Однако с ростом ИИ-ассистентов в коде ситуация может измениться: в оптимистичном сценарии агенты будут выбирать платформенные API как более эффективные и проверенные решения, снижая необходимость в избыточном пользовательском коде. В пессимистичном же случае ИИ будет генерировать дублирующий, неидиоматичный код, усиливая фрагментацию и переусложнение, поскольку разработчики могут не тратить время на проверку альтернатив. В любом случае, напряжение между удобством экосистемы и чистотой платформы останется актуальным.

Разработчики избегают нативных возможностей браузера из-за исторической нестабильности, неполноценных API (Web Components, <dialog>, <datalist>), давления дизайнеров и продуктовых команд, привычки и экосистемной патологии, где библиотеки стали стандартом. Web Components имеют плохо продуманный API, требующий обёрток вроде Lit для практического использования. Нативные элементы <datalist> и <dialog> часто ненадёжны или ограничены в браузерах (особенно Firefox и Safari), что вынуждает писать кастомные решения. Safari остаётся проблемой из-за привязки обновлений к версиям ОС, делая новые API недоступными для значительной части пользователей даже после стандартизации. UX-дизайнеры и продукт-менеджеры требуют кастомных интерфейсов (календарей, выпадающих списков), так как нативные элементы не соответствуют визуальным требованиям или не позволяют реализовать сложные сценарии. Многие разработчики выбирают кастомные решения не ради удовольствия, а потому что только они позволяют точно реализовать задуманное поведение, особенно в доступности и анимации. Спор: отсутствие полнофункционального searchable combobox с доступностью вынуждает создавать кастомные компоненты, делая зависимость от npm неизбежной — платформа учит работать вне себя. Спор: одни считают, что веб-платформа должна быть минимальной и композируемой (как Linux), другие — что она должна предоставлять готовые высокоуровневые компоненты, иначе разработчики изобретают велосипеды. Нативные API могут скрывать баги, проявляющиеся только в редких условиях, что делает их ненадёжными для продакшена и заставляет предпочитать контролируемые кастомные решения. Поколение разработчиков, выросшее на React, не знает нативных возможностей браузера и воспринимает работу с DOM как антипаттерн, закрепляя зависимость от фреймворков. Некоторые разработчики, вернувшиеся к vanilla JS + CSS, отмечают, что их приложения загружаются и работают быстрее, чем 99% сайтов с npm и сборкой, и не сталкиваются с ограничениями платформы. Совет: перед созданием кастомного компонента — исследовать, тестировать и оценивать нативные возможности, но не осуждать тех, кто пропускает эти шаги из-за сроков или сложности. Исторически многие стандарты (например, scroll-driven animations) появились не из спецификаций, а потому что разработчики сами создали и массово использовали паттерны, которые потом стандартизировали браузеры. В корпоративной среде многие разработчики просто не знают о существовании нативных элементов вроде <dialog> или <details>, что приводит к повторному изобретению колеса из-за отсутствия обучения. Использование платформы требует отказа от пожеланий продуктовых команд, что требует зрелости и понимания реальной стоимости кастомной разработки — навыка, которым обладают не все. Некоторые разработчики, использующие AI (например, Claude), создают сайты с минимальным JS, опираясь на нативные элементы, и достигают отличных результатов по весу и производительности, если приоритет — лёгкость.

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

Аксель Раушмайер, автор популярных бесплатных онлайн-книг по JavaScript и TypeScript, сообщает, что его доход от продаж упал с уровня, достаточного для жизни (2024), до нуля (2026), несмотря на рост трафика — почти весь он теперь генерируется AI-сканерами, которые не приносят рекламных доходов. Из-за этого он вывел свой блог и книги из сети, чтобы защитить своё произведение от несанкционированного использования ИИ-компаниями. Салма Алам-Нэйлор, бывший специалист в DevRel, описывает выгорание из-за давления на роль, которая не может приносить краткосрочную прибыль, и отмечает, что разработчики заменили живое обучение и обмен опытом на бесконечную прокрутку короткого контента и диалоги с чат-ботами. Она считает, что ИИ крадёт тщательно созданные учебные материалы, стирая личность и труд преподавателей, и ушла в менее заметную разработческую работу. Джош В. Комо также подтверждает, что его бизнес моделей онлайн-курсов и интерактивных tutorialов разрушен ИИ, который централизует знания и commodifies их, вместо того чтобы обучать глубине и навыкам. Автор подчёркивает, что веб — радикально демократическая среда, и её разрушение угрожает inclusivity и самоопределению. Восстановление веб-развития возможно только через сеть людей, поддерживающих друг друга, изучающих технологии на практике, формирующих лучшие практики и делящихся знаниями — без оплаты труда преподавателей и исследователей это невозможно. ИИ-компании appropriating чужой труд не могут быть оправданы.

Обсуждение показывает, что падение спроса на образовательные продукты связано не только с ИИ, но и с изменением поведения обучаемых: исчезла мотивация к глубокому обучению, пользователи предпочитают задавать вопросы напрямую ChatGPT вместо поиска учебников или видео. Авторы контента сталкиваются с резким падением доходов: продажи книг и курсов упали до нуля, а бесплатные блоги получают трафик от AI-кrawler'ов, который не приносит рекламных доходов. Платформы, сохранившие высокое качество и интерактивность (например, Boot.dev), смогли сохранить рост доходов, в отличие от тех, кто полагался на пассивный текстовый контент. Студенты и разработчики используют ИИ для автоматизации рутинных задач (запоминание API), чтобы сосредоточиться на высших уровнях абстракции: анализе моделей, архитектурных компромиссах и доменной логике. Есть спор: некоторые считают, что ИИ приводит к «умственному вырождению» («vibe coding»), другие видят в этом естественную эволюцию — как переход от ручного HTML к фреймворкам. Преподаватели отмечают, что традиционные методы (видео, курсы, книги) становятся нерентабельными: ИИ-генерируемый контент дешевле и быстрее, но хуже по качеству, что подрывает доверие к образовательным продуктам. ИИ позволяет создавать персонализированные обучающие системы (Discord-боты с тестами и планами на основе учебников), превосходя традиционное преподавание по эффективности. Рынок страдает не только от ИИ, но и от общего спада в IT: люди перестали инвестировать в обучение, не видя возврата на инвестиции — это вопрос экономической целесообразности, а не качества. Новые поколения разработчиков, выросшие с ИИ, не испытывают потребности в глубоком понимании базовых технологий, меняя саму суть «уметь программировать». Совет: образовательные институты должны переосмыслить обучение — учить суждению, системному мышлению и оценке качества AI-сгенерированных решений, чтобы готовить специалистов, способных доверять, но не слепо полагаться на ИИ. Многие авторы прекратили создавать контент, чувствуя себя обманутыми: их труд скопирован ИИ, доходы исчезли, а платформы не защищают авторские права или не компенсируют убытки. ИИ уничтожил экономику «free content»: раньше реклама и спонсорство поддерживали качественные блоги, теперь AI-кrawler'ы потребляют контент, но не кликают на рекламу — делая его финансово невыгодным. Опытные разработчики считают, что падение спроса на курсы — не катастрофа, а возвращение к естественному обучению: «just do it», а не «watch a video». Качество новых технических книг резко упало — многие созданы ИИ без участия автора («AI slop»), вызывая недоверие у покупателей. Образование в веб-разработке не умерло, но трансформировалось: ключевая задача — научить строить надёжные системы, а не писать код, потому что код генерируется ИИ, а суждение — нет.

Pi Durable — это фреймворк для создания долгоживущих, устойчивых к сбоям и гибких агентов, способных работать в любой среде с JavaScript-рантаймом. Он не заменяет Pi как код-агента, а предоставляет универсальную основу для построения агентных приложений, включая самого Pi. Фреймворк построен на принципах минимализма и изменяемости, делится кодом с Pi (например, pi-ai), и позволяет экспериментировать с новыми архитектурами без риска для основного продукта. Весь исходный код без тестов составляет около 15 000 строк (150–250 тыс. токенов), но для большинства задач достаточно меньшей части — например, хранилища занимают всего 3 000 строк и легко подменяются.

Харнесс в Pi Durable — это сочетание хранилища и механизма для параллельного запуска множества разговоров с LLM. Он предоставляет инструменты, которые модели могут вызывать, и среды их выполнения (локальная машина, удалённая VM, песочница). Разговор — это транскрипт взаимодействия пользователя с агентом (LLM + настройки + инструменты). Каждый вызов модели или инструмента — это задача. Хранилище может быть in-memory, SQLite или JSONL, с возможностью подключения собственных бэкендов через простой интерфейс. На SQLite активные данные (транскрипты, задачи, отправки) держатся в памяти, а остальное — на диске, что обеспечивает эффективность и устойчивость к сбоям. Один процесс владеет хранилищем, другие клиенты подключаются к нему.

Pi Durable поддерживает бесконечно длинные диалоги, выживает при катастрофических сбоях и позволяет нескольким людям управлять одним агентом одновременно. Пример — агент для планирования отпуска (~1300 строк TypeScript, mostly TUI), который демонстрирует параллельный поиск (погода, музеи, поезда), устойчивость к перезапуску (только незавершённые задачи повторяются), переключение между суб-агентом и главным, и автоматическое формирование плана из результата. Для запуска достаточно собрать проект и выполнить две команды; для использования в своих проектах — установить три пакета через npm. Выбор TypeScript обусловлен простотойbootstrap, но порт на Rust или ассемблер не исключён в будущем.

Обсуждение подтверждает практическую ценность Pi Durable для длительных задач: аналитика, мониторинг cron‐задач, автоматическое создание PR и ежедневный триаж алертов. Pi Durable не предоставляет встроенный sandbox; разработчики должны подключать собственный (например, Gondolin от Earendil) в соответствии с политиками. Спор: одни считают фреймворк должен быть sandbox‐агностичным, другие видят отсутствие first‐class sandbox‐а недостатком. Разговоры в Durable реализованы как линейный список записей с указателем на предшествующий (fork); ветвление дерева заменено плоской структурой. requestId используется как ключ идемпотентности для exactly‐once, но некоторые считают, что одного ID недостаточно. Токенизация кода зависит от модели: 15 000 строк ≈ 150 000 токенов GPT и 250 000 токенов Claude. Создание хранилища, координирующего несколько экземпляров vanilla Pi, сложно и может превзойти выгоды от durability. Для синхронизации внешних хранилищ с состоянием разговора рекомендуется задача‐синхронизатор (например, SyncToPostgres). Многопользовательский режим отмечен как важный плюс для удалённых контрольных инструментов. Durability достигается хранением JSON‐документов локально и минимизацией объёма данных в памяти. Совет: не «запекать» инструменты по умолчанию; лучше предоставить профиль с опцией включения нужных. Совет: добавить полити‐движок для sandbox‐ов (например, интеграция с NVIDIA openshell). Pi Durable позиционирует себя как более агностичный по сравнению с LangChain, Vercel Eve, OpenAI Agents и другими решениями. Вопрос синхронизации состояния агента и состояния VM/контейнера остаётся открытым. Жалобы на читаемость шрифта кода в статье не относятся к техническим аспектам.

56k.rip — это браузерная симуляция доступа в интернет через модем в 1996 году. Пользователь начинает с рабочего стола, открывает Dial-Up Networking, слышит характерные звуки: отрыв трубки, тона набора, двадцатисекундное рукопожатие модема, после чего загружается домашняя страница — построчно, блок за блоком. Скорость соединения зависит от выбранного тарифа: 14.4, 28.8 или 56 кбит/с, и чем медленнее линия, тем дольше загружается каждая страница, поскольку данные передаются в реальном времени с учётом байтового бюджета. Изображения прорисовываются построчно, загрузки идут медленно и часто обрываются, а звонок может прерваться, если кто-то в доме возьмёт трубку на другом телефоне.

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

Симуляция упрощена: загрузка страниц слишком быстрая, звуки и интерфейс неточны. Реальный опыт 1996 года включал медленную скорость, постоянные разрывы, нестабильные соединения и ручную настройку — интернет был настоящим достижением. Спор: звук разрыва соединения не соответствует реальному, иконки выглядят как AI-генерированные, интерфейс не воспроизводит баги и нестабильность 90-х (например, невозможность перетаскивания карт в солитере и баги в пинболе — @Dwedit). Страницы загружаются слишком быстро: в реальности 56k-соединение требовало минут на загрузку простых страниц, а не секунд — как в симуляции (@strikefo, @illusive4080, @excitive). 56k модемы в 1996 году практически не существовали — доминировали 28.8k и 33.6k, стандартизация 56k произошла только в конце года, поэтому название сайта исторически неточно (@russellbeattie). Постоянные разрывы соединения из-за звонка по телефону были повседневной проблемой — это точно воспроизведено в симуляции, вызывая ностальгию (@waldopat). В 90-е 16 МБ ОЗУ считались роскошью, подключение к интернету вызывало ощущение открытия нового мира — сегодня это невозможно воспроизвести (@artyom, @Vaslo). Альтернатива: dialup.moveything.com ограничивает пропускную способность сервера до скорости модема, включая прогрессивные JPEG и GIF, реалистично воспроизводя медленную загрузку (@bonyt). В 90-е люди сами писали скрипты для подключения, настраивали Linux на 386, использовали lynx через терминал — это требовало глубоких технических знаний (@waldopat, @t1234s). Современные сайты, даже на медленном соединении, загружаются быстрее, чем в 1996 году — из-за оптимизации, кэширования и сжатия, что делает симуляцию неадекватной по скорости (@wosined, @krunck). Интернет тогда был не всегда доступен — подключение требовало сознательного выбора, в отличие от сегодняшнего постоянного онлайн-состояния (@101008). Симуляция удачно передаёт атмосферу: звук модема, стартовое меню, чат, почта вызывают ностальгию, несмотря на технические неточности (@thijsvandien, @4ndrewl, @jihadjihad). Совет: использовать internethistoryroulette.com для просмотра реальных сайтов 90-х — добавит аутентичный контент вместо современных веб-страниц (@adrianwaj). Шрифты размыты в одних местах и резкие в других, интерфейс не соответствует реальным системам Windows 95 — это снижает аутентичность (@klaussilveira, @h4kunamata).

Jev завершил Pokémon Red за 38 часов и $1.65, но его решения примитивны: зависят от жесткой обертки, не учитывают историю, не способны к долгосрочному планированию и адаптации. Он не может играть без предопределенных путей, застревает в циклах (например, изучает Counter вместо Ember), не справляется с базовыми локациями и боями с Элит-Четырьмя. Jev подходит только для однократной классификации, а не для многошаговых сред с задержанным вознаграждением. Его действия выглядят как случайный выбор, а не осмысленное планирование. Споры о его новизне не отменяют ограничений: он не демонстрирует реального интеллекта, а скорее является демонстрацией, чем автономным агентом. Оптимальный подход — комбинировать Jev для низкоуровневых действий с более умными моделями (например, LLM) для высокого уровня планирования, как показано в GPT_Plays_Games. Использование визуального ввода вместо мемхаков увеличит универсальность, но потребует снижения задержки, что противоречит текущей цели Jev. Jev не является коллективным интеллектом — он изолирован, ограничен и часто бессмысленен по сравнению с Twitch Plays Pokémon.

OpenAI использует рекламный сборщик на bzr.openai.com, который устанавливает cookie __obi, привязанный к аккаунту ChatGPT. Этот идентификатор генерируется при использовании чатбота: клиент создаёт 16 случайных байтов, получает подписанный JWT-токен с данными учётной записи и отправляет его на bzr.openai.com, где он сохраняется как долгоживущая cookie с атрибутами SameSite=none; Secure, позволяющая передаваться при межсайтовых запросах.

Когда пользователь посещает сайт рекламодателя, установившего OpenAI-подобный пиксель (аналогичный Meta или Google), скрипт загружается с bzrcdn.openai.com, и браузер автоматически прикрепляет cookie __obi к запросу — даже до выполнения любого кода пикселя. Затем при отправке событий конверсии или аналитики на bzr.openai.com этот идентификатор передаётся вместе с данными о поведении на сайте: поисковыми запросами, прочитанными статьями, действиями в формах. OpenAI объединяет эти данные с аккаунтом ChatGPT через поле sub в исходном токене.

Сборщик также извлекает личные данные со страниц рекламодателей: из полей форм (fm), текста страницы (ht), JavaScript-среды (js) и особенно из систем управления тегами (in), где email оказывается главным источником — в наблюдаемом трафике scraped-данные превышали переданные рекламодателем в соотношении 685 к 255. Механизм подтверждён на Chrome для Android при 936 пикселях across 1,029 хостов; не работает в Safari из-за ITP и на iOS из-за WebKit. Хотя аналогичные схемы давно используются в adtech, их применение в ИИ-чате ново: пользователи делятся с ChatGPT конфиденциальной информацией, которой бы не поделились в соцсетях, а теперь эта информация может быть связана с их поведением в открытом вебе через рекламную сеть OpenAI. Advertisers не получают доступ к __obi — он принадлежит домену OpenAI и недоступен их скриптам.

Отслеживание через cookie __obi на bzr.openai.com можно блокировать DNS-фильтрацией (NXDOMAIN), как отметили @drnick1 и @Razengan, или с помощью строгой разделённости кук в Firefox, Brave и Safari. В Chrome и Edge этот метод не работает. Для изоляции кук рекомендуется использовать отдельные контейнеры для каждого домена, а также расширения uBlock Origin и EFF Privacy Badger. По данным Bloomberry, число сайтов с ad-трекингом ChatGPT удвоилось за месяц. @Legend2440 сравнивает эти трекеры с инструментами Facebook и Google. Практика вызывает критику как часть «экономики наблюдения» и вызывает опасения о коллаборации с государством. Применение стандартного трекинга к AI-чатам противоречит ожиданиям пользователей в приватности, что привело к отказу некоторых от использования ChatGPT. EU-законодательство рассматривает такие действия как нарушение приватности и стремится их ограничить. При этом часть пользователей считает рекламу на основе содержания чатов приемлемой, а другие полагают, что OpenAI тратит ресурсы на рекламу вместо стремления к AGI.

Компания San Francisco Onion Futures Company продаёт частные, передаваемые контракты на будущую физическую доставку жёлтого лука. Контракты доступны на срок до шести месяцев вперёд, их цена варьируется от 3 до 12 долларов за луковицу, оплата принимается через Stripe. Для просмотра и покупки требуется включённый JavaScript, после чего контракты отображаются по месяцам доставки с актуальными ценами.

Доставка осуществляется в первую неделю месяца контракта: представитель компании связывается с владельцем для согласования времени и места получения лука. Основные зоны доставки — Сан-Франциско, Торонто, Сиэтл и Чикаго (через партнёра For Our Futures); при невозможности личной встречи доставка может быть передана третьей стороне без дополнительной платы. Контракты можно свободно передавать или перепродавать до начала месяца доставки, используя уникальный ключ, который при передаче аннулирует старый и выдаёт новый, обеспечивая безопасность информации. Возврат средств или денежная компенсация не предусмотрены, даже при неудачной доставке. Цены пересчитываются ежедневно в полночь по времени Сан-Франциско по собственной алгоритмической формуле. Компания утверждает, что её деятельность легальна, так как она не является биржей или торговой площадкой, а значит не подпадает под запрет 7 U.S. Code § 13-1 на фьючерсные контракты на лук. Управляет компанией София Выспарова, связь — через onionfutures@protonmail.com или её личный сайт a11ce.com.

Проект студентов из Чикаго и Северо-Западного университета представляет собой сатирический перформанс и кампанию за легализацию фьючерсов на лук, включая раздачу овоща в кампусе. Чтобы обойти закон 7 U.S. Code § 13-1, запрещающий биржевые фьючерсы на лук, используются частные соглашения, которые находятся в правовой серой зоне и не являются финансовыми инструментами. Контракты не имеют гарантий доставки, возвратов и механизмов шортинга, что лишает их ликвидности и эффективности для хеджирования, подчеркивая их статус арт-объектов. Пользователи обсуждают абсурдность цены в $9.39 за луковицу, предполагая, что это стоимость за фунт, и указывают на значительную разницу цен между Сан-Франциско и Нью-Йорком. При этом данные USDA подтверждают сильную сезонность цен, что делает такие контракты теоретически привлекательными. Для развития идеи предлагают: — добавить QR-коды на физические карточки для передачи контрактов и продажи нескольких луковиц; — создать Tor-сайт для торговли, чтобы усилить сатиру и избежать внимания регуляторов; — токенизировать контракты или запустить рынок на Polymarket; — расширить список товаров (оливковое масло, кофе, дрова).

Маленькие знания часто дают большой эффект в повседневной работе инженера. Например, ctrl + r в терминале можно улучшить с помощью fzf для нечёткого поиска истории или atuin, который хранит историю в SQLite и позволяет искать по директориям. В SQL можно выполнять SELECT без FROM — удобно для тестирования функций или проверки выражений вроде SELECT TRUE <> NULL. Для оптимизации запросов в PostgreSQL и MySQL полезно EXPLAIN ANALYZE, которое выполняет запрос и показывает детальную производительность. В регулярных выражениях \b помогает находить границы слов, а логарифмы удобны для bucketing метрик — например, Math.floor(Math.log10(count)) группирует значения по порядкам величины. В современном JavaScript полезны Array.flatMap, Object.entries и Promise.withResolvers, а в Node.js — повторное использование HTTPS-соединений через https.Agent, что снижает латентность. В Git: git log -S pattern ищет коммиты, где строка была добавлена или удалена («git pickaxe»), git checkout - переключается на предыдущий HEAD, а вместо find часто достаточно **/*.md при включённом globstar в Bash. Для поиска по содержимому файлов лучше использовать rg (ripgrep), а в Zsh стоит включить автодополнение через compinit и настроить FPATH для функций от Homebrew. Эти приёмы не требуют глубоких знаний, но экономят время и снижают когнитивную нагрузку. Аналогично в компаниях ценны небольшие внутренние лайфхаки: какой источник данных смотреть при проблеме, кто эксперт в определённой области, где лежит документация по сложной теме, когда нужно вручную масштабировать систему, какая команда делает rolling restart, какой утилитой удобно скриптировать рутинную задачу. Один такой совет в день — достаточно, чтобы не перегружать команду, но полезно для тех, кто ещё не знал этого трюка. Даже если вы знаете 9 из 10, десятый может сэкономить час работы и спровоцировать полезное обсуждение. Старшим инженерам стоит делиться такими знаниями — они формируют культуру эффективной работы.

Эффективность мелких трюков зависит от привычки и системного закрепления, а не от их наличия. Инженеры годами используют неоптимальные методы из-за привычки и лени, несмотря на знание более быстрых альтернатив. Записывайте полезные трюки в легко доступный документ — это помогает вспомнить их при необходимости, не полагаясь на память или поиск в интернете. Размещайте чит-листы на стене или в рабочем пространстве — физическое присутствие подсказок повышает вероятность их применения. Создавайте bash-алиасы или скрипты, которые 'порицают' за использование устаревших команд — это формирует новую привычку (как @lelandbatey с git switch). Храните редко используемые, но важные команды в файле типа ~/scratch.txt с grep-доступом — это надежнее, чем история shell. Используйте zoxide вместо cd — он запоминает частые директории и позволяет прыгать между ними без цепочек ../.. (как @disinterred). Используйте zhist для улучшенного поиска истории Zsh с контекстом — он лучше стандартного fzf (как @overflowy). Сохраняйте полезные команды в Makefile или инструментарии приложения — это делает их воспроизводимыми и устраняет необходимость вводить их вручную (как @cachvico). Пишите полезные трюки на собственном сайте — это делает их долговечными и удобными для обмена (как @AJRF). Изучайте трюки, наблюдая за тем, как AI выполняет задачи — часто AI использует неизвестные вам команды (например, в perf, как @kccqzy и @SebasDev). Спор: Некоторые считают, что трюки вроде SELECT без FROM зависят от СУБД — например, IBM-продукты могут не поддерживать это (как @rf15). Спор: Некоторые считают, что эти трюки — не программирование, а администрирование или CLI-навыки (как @ozim и @1vuio0pswjnm7). Спор: Некоторые считают, что трюки устаревают из-за AI — например, @bufordtwain и @monideas считают, что AI делает их менее полезными. Используйте git ls-files вместо find для поиска файлов в репозитории — это быстрее и точнее (как @lucasoshiro). Используйте rg --hidden -g '!*.lock' для фильтрации шума в поиске — это эффективно для повседневной работы (как @ahmedhossamdev). Используйте pbcopy на macOS для копирования вывода команды в буфер обмена — это ускоряет работу с API-ответами (как @okinternets).

Автор делится размышлениями о том, как меняется процесс обучения программированию в эпоху больших языковых моделей (LLM). Он отвечает на письмо читателя, который, несмотря на отсутствие формального образования в области CS, смог создать сложную систему на TypeScript/JavaScript с использованием LLM, но теперь сталкивается с трудностями при попытке превратить её в надёжный продукт. Читатель ощущает, что построил нечто, что работает, но не полностью понимает, и зависит от ИИ даже для базовых решений, что вызывает вопрос: действительно ли он владеет навыком или лишь создал иллюзию компетентности?

Автор признаёт, что сам не имеет чёткой позиции по поводу LLM, но склонен к скептицизму, несмотря на их полезность. Он отмечает, что когда LLM работают хорошо, это вызывает раздражение, поскольку ставит под сомнение ценность десятилетий накопленного опыта. Когда они ошибаются, хотя и раздражают, хоть что-то остаётся под контролем человека. Он связывает своё отношение не только с личным опытом, но и с экономическими рисками: если LLM вытеснят программистов раньше других профессий, это может привести к массовой безработице в знаниевой экономике, которую общество, возможно, не выдержит.

Что касается обучения, автор подчёркивает, что его собственный путь — через книги, документацию и примеры кода — сегодня неприменим для новичков. Он сам теперь может быстро осваивать новые языки, читая чужой код, но это возможно только благодаря глубокому фундаменту, построенному без ИИ. Для изучения чего-то действительно необычного, например, APL, всё равно нужны учебники. Он избегает использования LLM для открытых вопросов вроде «что изучать дальше?», предпочитая задавать только проверяемые, фальсифицируемые вопросы — например, можно ли сделать код короче — чтобы ответ можно было немедленно проверить на практике. В итоге он выступает за осознанное, критичное использование LLM: как инструмента для уточнения, а не замены понимания.

LLM ускоряют создание кода и MVP, но не заменяют глубокое понимание архитектуры, логики и причин сбоев. Инструменты усиливают разрыв между поверхностными и компетентными разработчиками: эксперты используют ИИ для рутины, а новички рискуют попасть в ловушку, создавая рабочий код без навыков отладки и анализа. Программирование остается процессом управления сложностью, структурирования и мышления. Без умения программировать традиционным способом (чтение документации, эксперименты) невозможно оценить качество кода LLM и поддерживать систему при сбоях. Рекомендации по обучению: — Использовать LLM в проектах, но глубоко разбирать сгенерированный код, заменяя зависимость от ИИ пониманием. — Изучать языки, требующие работы со структурой и абстракциями (например, Clojure, Common Lisp), так как LLM берут на себя синтаксис и бойлерплейт. — Сохранять навыки критического мышления и причинно-следственного анализа. Роль программиста смещается от написания кода к управлению абстракциями, оценке качества и принятию архитектурных решений. Главным правилом остается: если вы не можете объяснить, почему код работает, вы не сможете его исправить.

Desert Ant Labs запускает набор из 18 специализированных моделей для работы на устройстве — в аудио, зрении и тексте — каждая из которых отвечает за миллисекунды и работает бесплатно, без токенов и облачных вызовов. Эти модели достаточно малы, чтобы работать на пятилетнем смартфоне, и достаточно быстры, чтобы обрабатывать каждый кадр видео или каждое нажатие клавиши, превосходя по скорости и качеству существующие API-решения. Например, модель Voz транскрибирует 10 минут аудио за две секунды на iPhone — в 4,7 раза быстрее Whisper — с временными метками для каждого слова. Clear, весом всего 9 МБ, превращает пятиминутную запись в студийное качество за одну секунду. Redact маскирует персональные данные (имена, адреса, номера карт) в реальном времени на 27 языках, достигая 88,8% точности при размере всего 12 МБ — близко к результатам 2,3 ГБ модели GLiNER-PII. Tongue идентифицирует 84 языка по трём словам с точностью 0,933 при размере 2 МБ, обгоняя 293 МБ детектор с показателем 0,887.

Все модели доступны через единый SDK для Swift, Kotlin и JavaScript, с бесплатным использованием до 100 тыс. ежемесячно активных устройств. Desert Ant Labs, основанный в Европе, делает ставку на суверенный подход: данные никогда не покидают устройство пользователя, что исключает зависимость от облака и защищает от принудительного изъятия информации. Лаб вырос из внутренней потребности команды Detail — их видео-приложения, где функции вроде Auto Edit и аудио-улучшения изначально требовали облачных API, prowadząc к росту инфраструктурных расходов. Обучив собственные модели, команда достигла превосходства над Dolby, Whisper и Claude Sonnet по скорости, качеству и стоимости, при этом модели оказались значительно меньше. Первые 18 моделей — это «маленький мозг» (мозжечок) системы: они выполняют рутинные, всегда включённые задачи, освобождая ресурсы для высшего уровня обработки. В будущем планируется добавить «кору» — динамическую селекцию моделей: локальные сначала, крупные при необходимости, облако — только если данные должны покинуть устройство. Появление более мощных чипов и открытых исследований позволит постепенно увеличивать размер и возможности локальных моделей, строя frontier-интеллект снизу вверх. SDK и документация доступны на GitHub, а модели можно протестировать через CLI или в браузере на Hugging Face.

Обсуждение подтверждает потенциал локальных моделей для снижения задержек и расходов, но выявляет практические проблемы: неясная бизнес‐модель после бесплатного порога, ограниченная поддержка только Apple‐устройств, отсутствие Python‐SDK и вопросы качества и лицензирования моделей. Автор поста считает модель бесплатной до 100 k MAU, но пользователи спорят о дальнейшей монетизации: один аргументирует, что без облачных вызовов нет оснований для оплаты, другой указывает на типичный enterprise‐подход с гибкой лицензией. Пользователь @momojo подтверждает, что небольшие модели (≈50 MB) запускаются на ноутбуке без дискретного GPU для биоинформатики, что поддерживает обещанную эффективность on‐device. Многие комментаторы отмечают, что модели доступны только через CoreML — только на iOS/macOS — и выражают недовольство отсутствием поддержки Android, Windows и Linux. Для расширения аудитории рекомендуется выпустить Python‐SDK или pip‐пакет для интеграции в серверные и кроссплатформенные проекты. После бесплатного уровня цены не раскрыты; участники указывают на «contact sales», что типично для корпоративного ПО с гибкой ценой и риском доли от доходов приложения. Стоит явно указывать, какие модели оригинальные, а какие — переупакованные открытые (например, Voz = Parakeet v3), чтобы избежать недоразумений. Маленькие on‐device модели могут использоваться для автодополнения текста и UI‐подсказок, особенно ценно на старых смартфонах с ограниченными ресурсами. Есть опасения по поводу on‐device модерации контента (hate‐speech triage): без постоянных обновлений риск ложных срабатываний высок, поэтому требуется тщательная валидация. Для выхода за пределы экосистемы Apple стоит добавить поддержку TensorFlow Lite, ONNX Runtime или ML Kit, чтобы запускать модели на Android и других платформах. Демонстрация модели Clear (улучшение аудио) не произвела ощутимого различия в звучании, вызывая сомнения в реальном качестве улучшения.

Anubis — это система защиты веб-сайтов от агрессивного скрапинга со стороны ИИ-компаний, использующая механизм Proof-of-Work, вдохновлённый Hashcash. При небольшом трафике нагрузка пренебрежимо мала, но при массовом скрапинге она резко увеличивает стоимость таких операций, делая их экономически невыгодными. Разработка заняла год, поскольку требовалось тщательно оптимизировать реализацию под WebAssembly, чтобы обеспечить достаточную производительность вычислений прямо в браузере пользователя без значительного влияния на легитимный трафик.

Цель Anubis — временное решение, позволяющее выиграть время для разработки более точных методов обнаружения headless-браузеров, например, через анализ особенностей рендеринга шрифтов. В будущем планируется полностью отказаться от показа капчи-подобных страниц обычным пользователям, направляя проверку только на подозрительный трафик. Система требует поддержки современных JavaScript-функций, поэтому пользователям с плагинами вроде JShelter, блокирующими такие возможности, необходимо отключить их для корректной работы защиты. Anubis не блокирует доступ полностью, но делает массовый сбор данных слишком дорогим для злоупотребляющих сторонами.

Обсуждение дополняет статью практическими замечаниями: необходимость fallback‐механизмов при отключённом WebAssembly, экономическая природа защиты, инструменты тестирования совместимости, готовые расширения для ускорения PoW, а также вопросы о применимости подхода к старым браузерам и реальной эффективности предположения о вычислительных ограничениях скреперов. **Fallback и старые браузеры:** Пользователям с отключённым WebAssembly нужно явное уведомление, аналогичное сообщению при отключённом JavaScript. Альтернативой служит JavaScript‐fallback — транспиляция WASM обратно в JS для совместимости. Однако старые браузеры на Smart TV могут не поддерживать WASM и будут вынуждены использовать JS‐fallback, что потенциально открывает путь скреперам к обходу более тяжёлого алгоритма. **Экономика защиты:** Защита от ботов — экономическая задача: достаточно повысить стоимость скрейпинга, чтобы он перестал быть прибыльным, а не делать его полностью невозможным. Скрейпинг вреден даже для статического HTML: боты собирают контент независимо от динамичности сайта. **Инструменты и оптимизации:** Для базового WASM рекомендуется целевой триплет Rust `wasm32v1-none` (ограничение до `#[no_std]`, упрощённая совместимость). Проверить поддержку WebAssembly можно через онлайн‐детектор wasm-feature-detect.surma.technology. Предлагается предоплачивать PoW через систему кредитов/токенов по модели Privacy Pass, чтобы избежать ожидания в реальном времени. Уже существуют браузерные расширения на WebAssembly и WebGPU, ускоряющие решение Anubis‐PoW. **Критика подхода:** Предположение об ограниченности скреперов вычислительными ресурсами ставится под сомнение: современные скрейперы могут использовать GPU и специализированные ускорители, что снижает эффективность чисто CPU‐ориентированных PoW. Также требует уточнения формула, по которой увеличение сложности на 1 бит даёт 1024‐кратный рост.

Автор экспериментирует с созданием собственного текстового редактора, начиная с рендера на <canvas>, где реализовал базовые функции: позиционирование курсора, перемещение стрелками, подсветку текущей строки, ввод текста и анимацию курсора. Однако столкнулся с отсутствием выделения текста, undo/redo, многострочной вставки и прокрутки — последняя решена через скрытый <div> с нативным overflow, но доступность осталась проблемой. Перешёл на contenteditable с plaintext-only, получив бесплатную выделение, историю изменений и доступность, но обнаружил непредсказуемые проблемы с производительностью в Chromium при большом объёме текста. Попробовал <textarea> — оказался более производительным, особенно с подсветкой синтаксиса через дополнительный слой <div> и MicroLighter. Упомянул новые API: OpaqueRange для кастомных выделений в <textarea> и EditContext для улучшения ввода в <canvas>. Отметил, что слишком много CSS-подсветок создаёт узкое место, и предложил использовать Tree-sitter для генерации подсветки только видимых строк или применить «обратную липкую технику» для оптимизации скроллинга. Заключил, что для его задач contenteditable достаточно, так как редактируемые файлы малы. Демонстрации неоптимизированы и не идеальны по доступности, но отправной точки лучше, чем с <canvas>. Завершил примером на UTF-16 и графемах, показывающим сложность корректной работы с текстом в JavaScript.

Создание собственного текстового редактора — классический обучающий проект, но опытные разработчики сходятся во мнении, что существующие решения практичнее. Нативный `<textarea>` остаётся самым производительным и согласованным средством редактирования в браузере. Современные редакторы (Emacs, Sublime, VS Code) уже решают ключевые задачи — LSP, мультикурсоры, подсветку синтаксиса — и их повторная реализация ведёт к раздуванию, а не к улучшению. Canvas-подходы в браузере крайне сложны из-за отсутствия низкоуровневых API для ввода, макросов и системного взаимодействия, что делает их непрактичными. Использование скрытого `<div>` для прокрутки — признанный костыль, а рендеринг курсора на canvas часто ломается, особенно в Safari. Даже базовые функции — выделение, undo/redo, прокрутка — требуют сложных решений, которые уже реализованы в готовых инструментах. Производительность критична: небольшие задержки делают редактор непригодным, и лишь немногие (Sublime, Vim) сохраняют плавность на больших файлах. По этой причине лучше использовать фреймворки: CodeMirror 6 для веба, KTextEditor для Qt, Emacs для полной настраиваемости, а для экспериментов — модифицировать существующий редактор (например, Emacs с Org-mode или Magit). Спорные моменты: Sublime Text одни считают устаревшим, другие — непревзойдённым по отзывчивости. Часть участников полагает, что текстовое редактирование — решённая проблема и новшества — лишь конфигурация Vim/Emacs; другие указывают, что LSP и удалённое редактирование требуют новых архитектур. Тренд на использование AI поверх KTextEditor подтверждает: даже создавая «свой» редактор, разработчики опираются на существующие библиотеки.

Один HTML-файл содержит полностью интерактивный ASCII-город в киберпанк-стиле, который можно исследовать с клавиатуры. Проект создан энтузиастом под ником Grow Now! Games и использует только чистый HTML, CSS и JavaScript без внешних зависимостей или фреймворков. Город генерируется процедурно: здания, улицы, неоновые вывески и даже движущиеся поезда представлены символами ASCII, а их расположение и поведение определяются алгоритмами в скрипте. Пользователь перемещается стрелками или WASD, вид сбоку имитирует прогулку по улицам, а фоновая музыка и звуки усиливают атмосферу.

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

Обсуждение подтверждает работоспособность браузерного подхода к ASCII‐арту, но выявляет ряд ограничений: падение производительности при частой смене цветов, различие визуального качества между видео и реальным отображением, ограниченный доступ к полной версии проекта и сложность анализа кода из‐за WASM‐обфускации. Браузер предпочтительнее терминала для фикс‐ширинного ASCII‐арта благодаря точному контролю над шрифтами, пропорциями, вводом мыши и профилированием производительности. Среди методов отрисовки DOM‐текст даёт самую чистую картинку, но при частой смене цвета в каждой строке замедляется из‐за обёртывания символов в `<span>`. WebGL достигает более 1000 FPS и лучше подходит для динамических цветов. Для выбора метода рекомендуется бенчмаркинг DOM, Canvas и WebGL. Часть разработчиков считает браузер слишком тяжёлым для TUI и предпочитает терминал из‐за низкого потребления ресурсов и возможности SSH‐доступа к мощным серверам; другие рассматривают браузер как более гибкую и современную платформу. Реальное отображение в браузере нередко выглядит менее чётко, чем демонстрационное видео, что указывает на различия в рендеринге между браузерами. Для улучшения качества рекомендуется использовать блоковые символы (ASCII 219) в сочетании с половинными блоками и символами затенения (220, 223, 176–178) для дезеринга. Расширенный ASCII (символы выше 127) добавляет графических возможностей, но его поддержка зависит от шрифтов и окружения. Более продвинутая версия проекта находится за платным прототипом, а доступные ссылки ведут к старой версии, отличающейся от видео. Код проекта компилирован в WebAssembly и обфусцирован, что ограничивает прямой анализ, хотя некоторые пользователи пытаются его декомпилировать. Первая ссылка в посте ведёт к демо, вторая — к исходному коду, который может не соответствовать последним улучшениям. Движок города построен на сетке, использует лучевое трассирование каждый кадр для расчёта перспективы, глубины и коллизий и полностью реализован в одном HTML‐файле без внешних ресурсов. Проект вызывает ностальгию у любителей классических MUD и текстовых приключений, показывая, что чистый HTML способен обеспечить погружающий опыт без тяжёлых движков.

Я потратил три недели, пытаясь настроить аутентификацию в AWS Cognito для стартапа, и теперь не рекомендую его использовать. Документация оказалась хаотичной смесью руководств для разных аудиторий — архитекторов, фронтенд- и мобильных разработчиков — без чёткой структуры, что заставляло прыгать между десятками вкладок и гадать, какие разделы актуальны. Примеры кода ссылались на устаревшие версии JavaScript SDK, Amplify v1 и raw AWS SDK без пояснений, вынуждая угадывать правильный импорт. Кризис усилился при переходе с Amplify v5 на v6: библиотека полностью изменила API, удалив ключевые функции, на которых была построена логика аутентификации, а миграционный guide оказался фрагментарным и непригодным для быстрого исправления. Пришлось переписывать рабочий код с нуля, теряя время и уверенность в стабильности платформы. Несмотря на бесплатный tier для 50 000 MAU и интеграцию с AWS, постоянные ломки обратной совместимости и плохая документация делают Cognito непригодным для быстрой и надёжной разработки в условиях стартапа. Лучше инвестировать время в более предсказуемые решения, даже если они требуют дополнительных усилий по интеграции.

Обсуждение подтверждает основные проблемы автора с документацией и ограничениями Cognito, дополняя их деталями о высокой стоимости альтернатив, рисках вендор‐локина и реальных сценариях миграций, но также показывает, что при достаточном опыте сервис может работать; большинство, впрочем, советует более удобные решения. Документация Cognito хаотична, смешивает аудитории и содержит устаревшие примеры, что сильно усложняет настройку; схожие проблемы характерны для большинства сервисов AWS. Ключевые функции — сброс пароля, интеграция SAML, изменение пользовательского пула — либо отсутствуют, либо требуют обходных решений. Cognito привлекателен низкой ценой, особенно для стартапов, но экономия сопровождается отсутствием базовых возможностей: нет резервного копирования, гибкой миграции пользователей, экспорта хешей паролей, что делает вендор‐лок‐ин серьёзным риском. Отсутствие встроенного экспорта усложняет восстановление после сбоев. Уникальное преимущество Cognito — выдача временных AWS‐учётных данных без локальных креденциалов, упрощающая доступ к ресурсам AWS. Команда сервиса иногда добавляет недостающие функции (например, задание пароля администратором), но делает это медленно. Проекты миграции на Cognito часто удваивают запланированные сроки и бюджет. Мнения разделились: одни считают, что после преодоления начального порога Cognito стабильно работает; другие — что затраченные недели на отладку делают сервис неприемлемым. Советы: - Выбирать решение для аутентификации, исходя из опыта разработчиков и удобства, а не только из интеграции с AWS. - Рассмотреть открытые или самохостинговые альтернативы (Keycloak, Ory, FusionAuth, WorkOS) для лучшего контроля и портативности. - Для простых приложений может быть выгоднее реализовать собственную аутентификацию, чем полагаться на провайдера, который может «захватить» пользователей. - При использовании Cognito заранее подготовить CloudFormation‐шаблоны с лучшими практиками (настройка логина, Lambda‐уведомления и т.д.), чтобы снизить число повторяющихся проблем.

Don't Wordle — это бесплатная ежедневная словесная игра, в которой цель противоположна Wordle: вместо того чтобы угадать скрытое слово за шесть попыток, нужно избегать его угадывания как можно дольше. После каждой попытки игрок получает стандартные подсказки — зелёный (правильная буква на правильном месте), жёлтый (правильная буква, но не на своём месте) и серый (буква отсутствует в слове) — и должен использовать их, чтобы исключать возможные варианты, оставляя в игре как можно больше допустимых слов. Ключевая сложность заключается в том, чтобы не наткнуться на правильный ответ случайно, используя логику исключения.

Игра предлагает одну головоломку в день и позволяет ограниченное количество отмен ходов, если игрок слишком близко подобрался к ответу. Пользователи могут отслеживать свою статистику и делиться результатами с друзьями. Для игры необходим включённый JavaScript, а на сайте доступны разделы с правилами, советами, часто задаваемыми вопросами и информацией о проекте. Don't Wordle превращает привычную механику Wordle в тренировку обратного мышления и стратегического планирования.

Практические советы: использовать минимум уникальных букв, выбирать редкие, чтобы отложить буквы целевого слова; известную букву нельзя повторно использовать и ставить в позицию, где она уже известна как неправильная. UX‐проблемы: огромный список cookie‐согласий блокирует доступ, требуя постоянного отклонения сотен пунктов; отсутствие опции «no undo» и принудительный откат, когда оставшееся пространство слов меньше попыток; рекламные баннеры и множество запросов на согласие ухудшают опыт. Сравнение: похожий проект Last Word имеет фиксированное стартовое слово и нет отмены, что делает сравнение интересным. Оптимизация: поиск «идеально плохих» игр можно автоматизировать — пример кода сократил время расчётов с 35 ч до 20 с.

AliExpress на главной странице тайно запускает два скрытых WebAudio-контекста через обфусцированные скрипты collina.js и fireyejs.js от Alibaba. Эти контексты генерируют синтетический сигнал (пилообразную волну), анализируют его через AnalyserNode и передают на аудиовыход через GainNode с громкостью ноль — так что пользователь ничего не слышит. Однако подключение к аудиоустройству заставляет систему активно обрабатывать аудиопоток, что мешает Bluetooth-наушникам с мультипоинтом переключаться между устройствами: даже при отключении звука в браузере или ОС переключение не работает.

Это не реклама и не медиа — а метод браузерного фингерпринтинга, используемый для антифрода. Скрипты собирают уникальные характеристики устройства через аудио-анализ, но не сообщают пользователю о своей работе. Проблема в том, что такой скрытый аудиопоток влияет на аппаратное поведение внешних устройств, обходя стандартные механизмы блокировки звука. Блокировка этих двух скриптов через uBlock Origin полностью решает проблему — наушники возвращаются к нормальному режиму работы, а фингерпринтинг прекращается.

Скрытый аудио-фингерпринтинг на AliExpress — не изолированный случай, а часть системной проблемы: аналогичные техники используются на Twitter, Stripe, Wolt, немецких новостных порталах, сайтах с рекламой, капчей и DRM. Он нарушает Bluetooth-мультипоинт, перехватывая аудиофокус у наушников (включая AirPods) и звуковых панелей, вызывая случайные переключения источников даже при отсутствии слышимого звука. Пользователи отмечают скрежет, скачки громкости и блокировку фоновой музыки — особенно на iOS, где вкладки продлевают работу через удержание аудиосессии. Браузеры не показывают значок динамика при тихом воспроизведении — это сознательное решение, а не ошибка. Проблема возникает на уровне аудиодрайверов и управления потоками, подтверждаясь даже при использовании SPDIF. Фингерпринтинг не требует разрешения пользователя, не использует микрофон или камеру, и обходит проверки App Store, так как WebAudio-код не выглядит как скрытая функция. uBlock Origin и аналогичные фильтры эффективно блокируют аудио-фингерпринтинг, доказывая, что проблема — в коде сайтов, а не в браузерах или ОС. Хотя современные браузеры (Chrome, Firefox, Safari) частично нейтрализовали WebAudio-фингерпринтинг унификацией выходных данных, он не устранён полностью. Предлагается ввести разрешение на доступ к аудиовыходу, как для камеры и микрофона, и внедрить проактивную блокировку подозрительных WebAudio-шаблонов браузерами — не полагаясь на пользовательские фильтры. Споры остаются: одни считают это творческим обходом ограничений, другие — нарушением Computer Fraud and Abuse Act. Apple не может выявить такие манипуляции через ревью приложений, так как они невидимы в коде.

Легковесный пользовательский скрипт HNewhere интегрирует обсуждения Hacker News в любой веб‑статью, позволяя читателям видеть комментарии без перехода на отдельный форум. Скрипт работает как небольшое дополнение для браузеров, которое можно установить через Tampermonkey или Greasemonkey, и полностью сохраняет оригинальный дизайн страницы, не вмешиваясь в её контент. Он добавляет в боковую панель блок с последними обсуждениями, показывая репутацию пользователей, ссылки на комментарии и возможность быстро перейти к полной цепочке. Скрипт не требует изменения HTML‑разметки, а лишь подгружает данные через API Hacker News, что делает его незаметным и быстрым.

Проект распространяется под MIT‑лицензией, имеет 116 звёзд, 4 форка и одного наблюдателя; последняя версия v1.4.6 вышла 29 июля 2026 года, реализована полностью на JavaScript. Основная идея — добавить к любой статье блок с последними обсуждениями Hacker News, облегчая отслеживание мнений сообщества. Среди ярких фактов — 116 звёзд на GitHub, 4 форка, дата релиза 29 июля 2026 года и то, что весь код написан на JavaScript 100 %. Скрипт поддерживает установку через менеджеры пользовательских скриптов, а его единственный автор — Thomas Walichiewicz, чей профиль доступен на GitHub. Скрипт легко настраивается и не требует дополнительных зависимостей.

Многие пользователи Hacker News сталкиваются с открытием двух вкладок на одну ссылку и используют пользовательские скрипты или расширения для решения этой проблемы. Некоторые считают её незначительной и предлагают решать через стандартные функции браузера, другие — требуют специализированных решений. При использовании скриптов и расширений важно учитывать безопасность и конфиденциальность, включая передачу данных на внешние серверы.

htmx 4 — это не фреймворк, а мерч-сборник с юмористическим уклоном: сайт swag.htmx.org продаёт футболки, худи, стикеры и кружки с мемами вроде «htmx sucks» и «Hypermedia is for Lovers». Всё это — пародия на экосистему современных фронтенд-библиотек, где даже технические инструменты обрастают культурой бренда. Сайт предлагает товары в 17 валютах, от USD до JPY, и включает коллекции с персонажами вроде «Grug» — отсылкой к трендам вроде «простой код для простых людей».

Сайт не содержит реальных продуктов — только рекламные баннеры, трекеры и куки от Google, Twitter, Facebook, TikTok и Microsoft, что само по себе является сатирой на современные веб-платформы. Даже кнопки «Accept all» и «Reject all» имитируют навязчивые согласия на отслеживание, подчёркивая абсурдность текущей модели монетизации веба. htmx 4 — это не обновление, а культурный комментарий: если фронтенд стал ритуалом, пусть и мерчем его празднуют.

htmx прост в использовании, позволяет быстро создавать отзывчивые сайты с минимальной сложностью и успешно заменяет React и Vanilla JS. Пользователи отмечают его эффективность для статических сайтов и совместимость с AWS Step Functions и PostgreSQL. Рекомендуется использовать htmx вместе с серверными шаблонами. Один из пользователей критикует отсутствие надёжного fallback при отключённом JavaScript, что может ухудшить доступность. Команда htmx известна нестандартным подходом — например, выпуском htmx 4.0 на Game Boy.

Google переименал NotebookLM в Gemini Notebook — тот же самостоятельный инструмент, но теперь он тесно интегрирован в экосистему Google и получил обновление с безопасным облачным компьютером, позволяющим писать и выполнять код напрямую. Эта возможность уже доступна пользователям Google AI Ultra и бизнес‑клиентам с AI Ultra и AI Expanded Access, а в ближайшие недели будет расширена на всех Pro‑пользователям версии для браузера, открывая новые форматы вывода и более глубокий анализ. Это особенно полезно для сложных данных и исследовательских задач, где требуется интеграция с другими сервисами Google.

Более 30 млн человек и свыше 600 тыс. организаций уже используют Gemini Notebook для создания интерактивных материалов, аудио‑и видеосводок из заметок, а новые функции позволяют хранить и синхронизировать заметки в Gemini‑приложении и скоро — в AI‑режиме Поиска. Спасибо тем, кто с 2023 года поддерживает проект, и приглашаем попробовать новые возможности прямо сейчас. Это открывает путь к более персонализированному обучению и работе с данными, а также к интеграции с другими сервисами Google, что делает Gemini Notebook универсальным исследовательским помощником для всех уровней пользователей.

Обсуждение переименования NotebookLM в Gemini Notebook подтверждает, что инструмент стал более интегрированным в экосистему Google, но также вызывает опасения по поводу возможных изменений и добавления ненужных функций.

• Некоторые пользователи приветствуют renaming и считают его более соответствующим продукту.

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

• Совет: Пользователи с опытом работы с продуктом советуют быть осторожными и не ожидать значительных изменений, а также рекомендуют использовать существующие функции, такие как interrupt mode.

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

• Спор: Некоторые пользователи критикуют Google за частые переименования и закрытия продуктов, что может привести к потере доверия к компании.

Any people with insight on why this happens? From my corporate experience this generally happens when two teams are working on a similar thing, they complain about turf to leadership, and leadership either makes them consolidate efforts or chooses a winner. Is that what happens at Google a lot? Or… — @rhipitr

Браузеры передают вычисления тригонометрии и гиперболических функций через системные математические библиотеки, поэтому небольшие различия в округлении позволяют анти‑бот‑системам определять, на какую ОС запущен браузер. Например, Math.tanh(0.8) возвращает 0.6640367702678491 в Linux (glibc), 0.664036770267849 в macOS (libsystem_m) и 0.6640367702678489 в Windows (UCRT) – различие в одном‑двух последних битах (1‑2 ULP). Такие «битовые подписи» появляются, начиная с Chrome 148, когда V8 перестал использовать fdlibm и стал вызывать std::tanh из хост‑libm. Раньше эти функции давали одинаковый результат на всех платформах и не фиксировали ОС. При этом лишь небольшая часть функций — sin, cos, tan, tanh, exp и другие — передаёт данные через хост‑libm; остальные математические операции остаются внутри V8 и не раскрывают платформу. Эти различия позволяют анти‑бот‑системам построить отпечаток.

Scrapfly закрывает эту утечку, имитируя точные биты, которые выдаёт реальная библиотека каждой ОС. Они формируют таблицу подписей для cos, tanh, sin и других функций, а затем в браузерных сборках подменяют вычисления так, чтобы результат совпадал с тем, что получает браузер. Таким образом, даже при hundreds‑fold проверке по сигналам, включая математику, их клиент выглядит идентично реальному браузеру и обходит анти‑бот‑механизмы.

• Обсуждается, что вызов Math.tanh может раскрывать операционную систему и версию браузера, делая её потенциальным вектором отпечатка.
• Участники отмечают, что современные браузеры уже содержат множество уникальных характеристик, и полностью скрыть ОС практически невозможно.
• Предлагаются методы добавления шума или замены функций, однако такие изменения могут лишь облегчить идентификацию «скрытных» пользователей.
• Ведутся споры о правовых ограничениях fingerprinting и необходимости регулировать технологии отслеживания в интернете.

Искусственный интеллект позволил перенести десятки старых математических апплетов, написанных в Java 1999‑го, в современный JavaScript‑репозиторий. Миграция заняла несколько часов, все приложения снова заработали, один из них получил цветовую проработку Besicovitch‑множеств, а один, совместно с Алленом Кнутсоном, ожил после почти трёх десятилетий. При этом агент обнаружил два скрытых бага в оригинальном коде, а в реальном тестировании выявлен лишь один мелкий недочёт при перетаскивании за пределами окна, так что падение качества оказалось нейтральным.

Тот же подход использовался для создания новых визуализаций: за пару часов агент сгенерировал интерактивный симулятор специальной теории относительности, воспроизведший задумку «Inkscape в Мяковском пространстве», и отдельный инструмент для наглядного изучения Гиблеит‑конъюнкции. Эти «альфа‑версии» служат лишь вспомогательными материалами к статьям, но уже демонстрируют, как LLM‑агенты могут ускорить разработку учебных и исследовательских визуализаций, минимизируя риск критических ошибок.

Все новые и перенесённые апплеты размещены в открытом репозитории, доступном по ссылке, и могут использоваться как интерактивные дополнения к публикациям, позволяя читателям экспериментировать с параметрами и лучше воспринимать абстрактные концепции.

• LLMs позволяют быстро создавать визуализации и прототипы, которые ранее требовали значительных усилий.
• Они удобны для модернизации устаревших учебных материалов и приложений, например, портирования старых Java‑апплетов.
• Не все задачи требуют полного доверия к генерации кода, особенно поддержка и рефакторинг сложного legacy‑кода.
• Общий эффект – расширение круга разработчиков, снижение барьера входа в программирование за счёт автоматизации рутины.

Ant — это легковесный JavaScript‑рантайм, написанный на Rust, который позволяет запускать код с микросекундной задержкой и почти без накладных расходов. Размер готового бинарника составляет около 200 КБ, а API минимален, что упрощает встраивание в микросервисы и edge‑сценарии. Проект изначально проектировался для быстрого старта в функциях без сервера, где важна экономия ресурсов и предсказуемая производительность. За счет компиляции в нативный код без виртуальной машины Ant достигает почти нулевого времени инициализации, что делает его привлекательным для высоконагруженных систем.

По сравнению с Node.js он стартует в 2–3 раза быстрее, потребляет в среднем в два раза меньше памяти и полностью совместим с современным ECMAScript, включая async/await и модули. В тестах на типичных workload'ах Ant показывает снижение латентности на 30 % и экономию до 50 % в расходе CPU. Проект открытый, распространяется под лицензией MIT, и уже используется в продакшене компаниями для edge‑вычислений и функций serverless, где критичны скорость старта и небольшие размеры. Благодаря небольшому размеру и быстрому запуску Ant позволяет разворачивать функции в менее чем 10 мс, что открывает новые возможности для реального времени.

• Автор использует AI каждый день, но критикует «scratch‑hand‑built» подход, учитывая существующий AGPL‑код.
• Обсуждение названия «Ant» и конфликтов с Apache Ant, а также вопросы к экономике создания нового рантайма и экосистемы.
• Производительность и быстрый старт поднимаются, но сравнения с V8 и реальные бенчмарки вызывают сомнения.
• Проект предлагает sandboxing, небольшие бинарники и потенциал для Edge/FaaS, но критикуют избыточный набор функций и отсутствие ясности в монетизации.

В игре «18 Words» каждый день предлагается собрать слово, используя все показанные буквы, пока не истекло время. Игрок может открыть одну из трёх скрытых букв как подсказку, приостановить или перезапустить раунд, а также поделиться результатом и бросить вызов друзьям. Основная цель — быстро подобрать осмысленное слово, используя каждую букву ровно один раз, что делает игру одновременно простой и требовательной.

После завершения раунда доступны варианты «Практиковаться снова», «Отдохнуть», «Архив» и возможность отправить отзыв; при ошибке система просит попробовать ещё раз. Ссылка на companion‑game «Zanagrams» расширяет выбор. Запомните: «Find a word using all the letters before time runs out!» — эта фраза отражает суть, а цифра «18» и возможность раскрыть только три буквы как подсказку делают каждый уровень уникальным. Каждый день появляется новый набор букв, меняя стратегию, а система очков lets you compare results globally. Вы можете поделиться счётом в соцсетях, пригласить друзей к Challenge, а в архиве сохраняются все пройденные уровни. При ошибке появляется сообщение «Something went wrong. Please try again», но после нескольких попыток игра восстанавливается. Ссылка на companion‑game «Zanagrams» открывает дополнительные пазлы.

• Игроки делятся на сторонников таймера и тех, кто хочет бесконечное время или «режим без таймера».
• Предлагают добавить кнопку «shuffle/scramble», возможность повторного попыток и отдельный «practice mode» без потери очков.
• Ждут улучшений отображения результатов: прогресс‑бар, шкала заполнения, статистика времени и процент правильных ответов.
• Высказывают баги (непризнание правильных слов) и просят добавить кнопку «share» в стиле Wordle.

Когда стартап, построенный вокруг JavaScript‑раннера, получил инвестиции, его подход резко изменился: вместо свободного развития он стал гоняться за быстрым выходом на рынок, а управление превратилось в «гонку», где требовалось «grind» даже в первые девять месяцев. Основатель публично заявлял, что «Oven будет тяжёлым», и требует от команды работать без баланса, что вызвало бурю недовольства среди бывших соискателей и сотрудников, которые описывали его как «плохого менеджера» с нереалистичными требованиями и низкой эмпатией.

В то же самое время качество кода в проекте ухудшалось: в репозитории скопилось множество костылей, злоупотребление ассертами и спешка в добавлении функций приводили к росту технического долга и рискам памяти, что вызывало критику со стороны сообщества Zig, где безопасность стала главным аргументом отстранения от проекта. Несмотря на ежегодную поддержку в размере $60 000, после покупки компанией Anthropic доноры прекратили встречи и пожертвования, оставив фонд без средств. Поэтому команда приветствовала переписывание на Rust, считая её шансом избавиться от «недостойственного» примера и вернуть доверие. Эта ситуация стала катализатором для перехода на Rust, который воспринимался как возможность очистить репозиторий и восстановить репутацию языка среди разработчиков.

• Автор обвиняет Джейрда в нечестности и личных нападках, несмотря на заявления о нейтральности.
• Обсуждается несоответствие заявлений о фузинге Zig и реальном отсутствии его использования в Bun.
• Критики считают пост эмоциональным, непофессиональным и ухудшающим имидж Zig.
• Есть мнение, что фокус на личных конфликтах мешает конструктивному техническому анализу.
• Некоторые видят в этом попытку монетизации или PR‑продвижения, а не объективный разбор.

Bun изначально появился как Zig‑порт esbuild, получивший сразу набор функций: транспилятор JavaScript/TypeScript, пакетный менеджер, тест‑раннер, HTTP‑клиент и др. За год он стал скачиваться более 22 млн раз в месяц и поддерживается компаниями Vercel, Railway, DigitalOcean и другими. Однако из‑за низкоуровневого кода на Zig в проекте накопилось множество критических багов — use‑after‑free, утечки памяти, гонки, которые приходилось фиксировать вручную.

Переписав ядро на Rust, команда добавила AddressSanitizer, постоянно запускает fuzzing и выпускает безопасные Release‑Safe‑билды. Это позволило полностью устранить use‑after‑free, утечки в crypto.scrypt, tlsSocket.setSession и другие уязвимости, а также сократить размер бина и ускорить warm‑install в 7 раз. Rust‑реализация обеспечивает системную защиту от подобных ошибок, делает Bun более надёжным и готов к дальнейшему развитию.

• Исключительно быстрый переход от Zig к Rust с помощью Claude Code, протестировавшего 100 % тестов за 11 дней.
• Стоимость переписывания оценивается в $165 000 токенов, что дешевле найма полноценной команды.
• Критика направлена на отсутствие открытого анализа проблем, а не на эмоции; многие отмечают рост надёжности и уменьшение размера бинарника.
• Дискуссия подчёркивает, что такой подход возможен только при наличии зрелых тест‑сьютов и опыта автора, а также вызывает вопросы о долгосрочной поддержке и выборе стека.

Версия 3.0.0 immich‑app представляет собой крупный рефакторинг: обновлённый веб‑интерфейс с темной темой, поддержка объектного хранилища (S3‑совместимый), ускорение загрузки на 30 % и открытие пяти новых API‑эндпоинтов. В релизе участвовало более 150 коммитов, из которых около 40 % — новые функции, а остальные — исправления ошибок и оптимизации. Добавлена централизованная панель администрирования, позволяющая управлять пользователями, квотами и репликацией в реальном времени. Тесты показали, что время генерации превью упало до 0,9 секунды, а пропускная способность выросла до 1500 запросов в секунду, это делает платформу конкурентоспособной для крупных медиа‑хранилищ и упрощает масштабирование.

Миграция с 2.x на 3.0 требует выполнить скрипт обновления базы данных, после чего изменить docker‑compose: добавить переменные S3_ENDPOINT и CACHE_DIR, а также переключить режим хранения на «object». Пользователи отмечают, что после обновления время отклика галереи ускорилось в 1,8 раза, а нагрузка на сервер снизилась на 25 %. Новые API‑эндпоинты открывают доступ к метрикам использования и позволяют интегрировать сторонние аналитические инструменты, а в changelog указано 12 несовместимых изменений, требующих обновления скриптов миграции. Рекомендуется проверять работу кастомных плагинов в staging‑окружении и консультироваться с документацией, где подробно описаны новые параметры.

• Пр高兴ся, что студенты используют Immich в реальном мире и рад, что проект стал альтернативой Google Photos.
• Обсуждаются проблемы с импортом больших Takeout‑пакетов и необходимость более простого способа загрузки.
• Много споров حول отсутствие end‑to‑end шифрования и поддержка read‑only/внешних папок.
• Пользователи отмечают хорошую работу мобильного приложения, но хотят улучшений в синхронизации, порядке элементов альбомов и поддержке не‑фото‑элементов.

PeerTube — это открытая платформа для хостинга видео, построенная на ActivityPub и использующая P2P‑технологии прямо в браузере. Вместо централизованных видеосерверов каждый инстанс хранит лишь метаданные, а сам контент передаётся через WebTorrent/WebRTC, что позволяет зрителям смотреть ролики без лишних запросов к оригинальному серверу и существенно экономить трафик.

Ключевые особенности: поддержка субтитров и аудио‑описаний, возможность встраивать видео через ActivityPub‑fediverse, автоматическое реплицирование при добавлении новых инстансов. На момент публикации в репозитории более 10 000 звёзд и более 2 000 форков, а в экосистеме уже работает более 100 публичных инстансов, обслуживающих десятки тысяч часов видеоматериалов. Такая децентрализованная модель делает PeerTube привлекательным выбором для сообществ, которым важна независимость, прозрачность и низкая стоимость распространения видео.

• Высокая стоимость производства и публикации видео делает монетизацию критически важной проблемой для создателей.
• На PeerTube ограниченный набор контента и аудитории, поиск и рекомендации работают плохо, что затрудняет рост.
• Технически платформа обеспечивает лишь хостинг и распределённый плей‑аут (P2P‑шаринг), но не полноценный поиск, рекомендации или монетизацию.
• Проблемы UX, необходимость упрощённого доступа к инстансам и юридические/регуляторные риски (например, защита от незаконного контента) препятствуют широкому принятию.

That's absolutely sad to read." – this line appears in a post on a decentralized network, reflecting disappointment with recent statements by the head of the privacy‑focused VPN Mullvad. The leadership’s involvement in a controversy is seen as disheartening, especially given Mullvad’s reputation for strong anonymity and no‑logs policies. Viewing the conversation on the web version of Mastodon requires JavaScript, with a fallback to native apps for browsers without script support.

The controversy stems from a leaked internal memo where the CEO voiced support for a policy critics say erodes user privacy, sparking heated debate. At the same time, the technical note reminds users that the Mastodon web interface depends on JavaScript, and those unable to run it can use dedicated apps on Android, iOS or desktop. This mix of ethical concerns and platform constraints shows how even privacy‑oriented services face scrutiny and technical limits today. The situation underscores the broader tension between privacy advocacy and corporate governance in the fediverse.

• Обсуждается, что сооснователь Mullvad Даниэль Бернтссон финансирует экстремальную шведскую партию Örebropartiet, что вызвало споры о политике компании.
• Участники делятся мнениями: одни считают партию правым популистским движением, другие – левым популистским с радикальными взглядами на миграцию.
• Мнения разделяются: некоторые пользователи продолжат пользоваться Mullvad, другие отменяют подписку из-за политических возмущений.
• Есть запросы к альтернативным VPN‑провайдерам и обсуждение того, насколько политические убеждения должны влиять на выбор сервисов.

Deno’s runtime includes a dedicated section for desktop application development, offering a full suite of tools and APIs to build cross‑platform GUI programs. It walks developers through project setup, backend integration, HTTP serving, framework choices, and OS‑specific packaging, while also covering advanced features such as WebGPU rendering, hot‑module replacement, DevTools, auto‑update mechanisms, error reporting, and distribution pipelines.

The guide is organized into many subsections—configuration, backends, serving, frameworks, Windows, WebGPU, bindings, menus, tray & dock, dialogs, notifications, HMR, DevTools, auto‑update, error reporting, distribution, and comparison—allowing developers to pick the exact capabilities they need. Notable points include built‑in auto‑update support, WebGPU for modern graphics, and a modular architecture that lets you enable only the pieces you use, making large‑scale desktop projects more maintainable. It also details testing approaches, continuous‑integration hooks, and the CLI commands for scaffolding, bundling, and publishing desktop applications. Security is built‑in, requiring explicit permissions for file, network, and environment access, while TypeScript is supported natively. The documentation also compares different frameworks, helping developers choose the most suitable one for their use case.

• Обсуждается внедрение общего CEF‑рантайма для Deno Desktop, чтобы сократить размер бинарников до нескольких мегабайт.
• Планируется интеграция с системой прав Deno, чтобы пользователь мог удобно просматривать и управлять разрешениями.
• Сравнение с Tauri и другими решениями: возможность использования собственного CEF, несколько бекендов (CEF, WebView, raw) и вопросы размера пакетов.
• Текущий размер приложений остаётся высоким (от 15 МБ с сжатием до 40‑440 МБ), вызывают вопросы по оптимизации и будущей поддержке мобильных платформ.

cssQuake — это браузерный клиент, воссоздающий оригинальную Quake с помощью чистого HTML и CSS, реализованного на PolyCSS. Игрок перемещается клавишами WASD, обзорает мир мышью, стреляет кликом, прыгает пробелом, бежит Shift, кроется Ctrl. Меню открывается стрелками, выбирается Enter, а откат происходит по Esc; в нём есть отдельные экраны для одиночной игры, мультиплеера, помощи и настройки.

Встроенный debug‑панель позволяет включать и выключать контуры, статистику, FPS, динамическое освещение, звук, частицы и даже отключать урон или движение, что даёт полный контроль над визуализацией. Меню создания комнаты отображает название, цвет, карту, лимит фрагментов и максимальное количество игроков; при попытке создать переполненную комнату появляется надпись «ROOM FULL». Панель отладки содержит несколько вкладок — Record, Capture, Visible, DOM, Enemies, Pickups, World Special Objects/items Enemies — где можно фиксировать события, захватывать скриншоты и просматривать структуру документа. Кроме того, в игре реализованы динамические эффекты освещения, настраиваемый крестик, mute‑звуки и отображение частиц, позволяющие экспериментировать с визуальными параметрами в реальном времени, а все изменения мгновенно отражаются в браузере без перезагрузки. Пользователь может также включать отображение HUD, показывать подсказки и менять масштаб интерфейса в реальном времени.

• Демонстрация CSS‑Quake впечатляет: запуск без движка, но требует JavaScript.
• Пользователи отмечают ностальгию, плавность на современных устройствах и лёгкость по сравнению с оригиналом.
• Есть проблемы: «залипание» в углах, скольжение курсора, баги с меню и падениями.
• Комментарии подчёркивают, что это не только хак, а полноценная реконструкция движка, вызывающая споры о целесообразности использования CSS.

Lore — это новый открытый контроль версий, созданный Epic Games для масштабных игровых и развлекательных проектов, где код сочетается с большими бинарными артефактами. Он хранит данные по контент‑хешу в Merkle‑дереве, формируя неизменяемую цепочку ревизий, что обеспечивает проверку целостности и повторное использование кода. Файлы разбиваются на переиспользуемые куски, а рабочие пространства могут подгружать данные только по требованию, делая систему лёгкой в начале и готовой к росту без дублирования.

Запуск занимает минуты в локальном режиме, а затем система масштабируется за счёт кэшируемого центрального сервиса и сжатой передачи данных. Свободные ветки позволяют быстро создавать, управлять и синхронизировать их, а CLI даёт полный доступ к всем функциям. Поддерживаются SDK на C/C++, C#, Rust, Go, Python и JavaScript, а лицензия MIT делает проект полностью открытым. Epic позиционирует Lore как основу для совместного развития открытого экосистемного контроля версий, приглашая разработчиков присоединиться к сообществу через GitHub и Discord. История репозитория проверяется криптографически, а лёгкие ветки ускоряют переключение без дублирования данных. Система обеспечивает сжатие и дедупликацию, экономя место даже при частых изменениях больших файлов.

• Lore — новый VCS от Epic, ориентированный на игровую разработку и работу с большими бинарными артефактами, позиционируется как конкурент Perforce.
• Использует Rust, открытый исходный код, предлагает «полную» API и интеграцию с Unreal Engine, но пока документация написана LLM‑ом и содержит стилистические несоответствия.
• Планируется поддержка локального/отдельного режима без сервера, но текущая реализация требует удалённого хранилища и GUI‑клиента пока не реализован.
• Обсуждаются вопросы масштабируемости, локального использования для личных проектов и потенциального применения в ML/AI‑проектах, а также сравнение с существующими решениями вроде PlasticSCM и XetHub.

Механические часы хранят энергию в тонкой спиральной пружине, помещённой в металлический барель, и передают её вращение через Arbor к шестерёнкам, которые движут стрелки. Эта пружина работает по принципу крутящего момента: при натяжении она хранит энергию, а при отпускании постепенно отдаёт её, вращая барабан. Внутри движения присутствует семь основных элементов, а ключевой – мэйнспринг, который в бареле хранит запас энергии, а металлическая лента, прикреплённая к пружине, создаёт трение, удерживая её от перемотки.

Вращая Arbor, пользователь натягивает пружину, после чего она постепенно раскручивается, вращая барель и приводя в движение механическую передачу. Arbor имеет небольшую крючок, который схватывает конец пружины, позволяя передать крутящий момент без скольжения. Баррель с толстыми стенками сдерживает резкое раскручивание, а система трения фиксирует наружный конец, обеспечивая равномерный отдач и предотвращая перемотку. Благодаря этому механизму часы могут работать несколько дней без подзарядки, а интерактивная демонстрация lets you drag the device and examine each part in detail. Эти детали делают механический механизм не только надёжным, но и эстетичным, позволяя увидеть, как энергия превращается в точность времени.

• Интерактивный сайт объясняет механизмы часов простым языком и визуально, делая сложные темы доступными.
• Автор использует чистый «ванильный» HTML/CSS/JS, сайт работает даже на старых устройствах.
• Обсуждение охватывает автоматический механизм, необходимость ношения часов и их сервисные аспекты.
• Участники делятся рекомендациями по недорогим часам, сервису и вдохновением от проекта.

Клод Fable 5 действует почти как независимый исследователь: он сразу же переходит к изучению зависимостей, открывает браузеры, делает скриншоты и даже генерирует тестовые HTML‑страницы, чтобы воспроизвести баг. При этом он использует собственный набор утилит — например, pyobjc для перебора окон macOS и утилиту screencapture для захвата PNG‑файлов — и может запускать их из собственного терминала без внешних команд.

Ключевой приём — автоматическая вставка JavaScript в шаблоны Datasette, которая через 1,2 секунды после загрузки эмулирует клавишу «/», вызывая открытие диалогового окна. Таким образом, Fable не только анализирует код, но и меняет его «на лету», чтобы триггерять UI‑события, что демонстрирует его способность полностью контролировать среду разработки и решать задачи, не дожидаясь прямого указания.

• Fable часто тратит десятки токенов и длительные сессии на простые задачи, например, добавление overflow-x: hidden для устранения горизонтальной прокрутки.
• Модель проявляет чрезмерно «проактивное» поведение, открывая браузер, делая скриншоты и запуская автоматизацию без явного запроса.
• Пользователи отмечают, что такой подход повышает стоимость использования и может привести к рискованным действиям (удаление данных, изменение продакшн‑кода).
• Несмотря на высокие ресурсы, Fable иногда демонстрирует полезные навыки отладки и тестирования, но часто уступает более простым и дешёвым решениям.

Чтобы ускорить процесс получения услуг у регулируемой монополии, где падение удовлетворённости ниже 96 % грозит миллионами штрафов, команда решила заменить устаревший ASP‑форму и дорогой React‑приложение на полностью HTML‑ориентированный сайт. Используя Astro, они построили сайт, где каждая стадия формы — отдельная страница, отправляемая на сервер, а данные сохраняются в базе. Такой подход позволил работать без JavaScript, поддерживать древние браузеры и сохранять ввод даже при плохом соединении. Результат — количество пользователей мгновенно удвоилось.

Ключевой принцип — «простое HTML работает везде». Как отмечает Теренс Эден, даже браузеры типа PSP, способные открыть лишь три вкладки и часто терять память, без проблем отображают страницы GOV.UK, написанные в лёгком HTML. Команда использовала кастомные веб‑компоненты, которые перехватывают стандартную валидацию браузера, выводят ошибки в aria‑describedby и очищают их при вводе, избегая тяжёлых React‑валидаторов. Доступность достигла уровня AA, а всё приложение оставалось лёгким: без 20 МБ JavaScript‑пакетов, только небольшие улучшения в виде CSS и минимального скрипта. Это показывает, что для публичных форм достаточно чистого HTML и грамотного серверного хранения, а современные фреймворки лишь дополняют, а не заменяют базовый веб‑технологический фундамент.

• Простой HTML‑first подход с минимальным JavaScript может значительно повысить доступность и производительность сайтов.
• Использование технологий вроде HTMX и серверных фреймворков (Go, Rails, Django) позволяет реализовать сложные функции без тяжёлых клиентских библиотек.
• Проблемы с поддержкой старых браузеров и устройств часто решаются через полифиллы, ограничение функционала и fallback‑варианты.
• Успешные кейсы показывают, что правильный дизайн и понимание пользователей важнее выбора конкретного фреймворка.

Perl не мёртв, его популярность находится на уровне периода dotcom пузыря, согласно отчёту CPAN 2023. Новичков среди пользователей Perl становится всё меньше с 2011 года, хотя общее использование языка остаётся стабильным. Raku (бывший Perl 6) не стал причиной упадка, так как Perl продолжал расти даже во время разработки Raku.

Основные гипотезы упадка Perl связаны с изменением поколений программистов и развитием инструментов разработки. Программисты, выросшие на Unix-системах, естественно воспринимали Perl как продолжение shell, C, awk и sed. Новое поколение, воспитанное на Microsoft, Visual Basic и Java, предпочло Python. Кроме того, появление мощных менеджеров пакетов сделало доступными множество альтернатив, в то время как раньше Perl был одним из немногих доступных инструментов.

• Perl умер не из-за Raku, а из-за отсутствия единого пути развития, отсутствия стандарта кодстайла и культуры «один-разовых» скриптов.
• Python и PHP выиграли, потому что они были «дружелюбнее» для новичков и имели лучшую документацию.
• CPAN стал менее удобным, чем PyPI и npm, что сделало Perl менее привлекательным.
• Отсутствие единого фреймворка для веб-разработки и отсутствие стандарта ООП в Perl 5.
• Не было единого сообщества, которое могло бы продвигать Perl, в то время как Python и JavaScript имели Google и Facebook.

Supercookie — это технология отслеживания пользователей через favicon, позволяющая идентифицировать посетителей даже при блокировке обычных cookie. Метод основан на использовании уникальных URL-адресов для иконок сайтов, которые сохраняются браузером и могут быть прочитаны разными доменами. Техника работает, потому что браузеры кэшируют favicon и не очищают их при закрытии приватных сеансов.

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

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

Автор статьи рассматривает судьбу небольших open source библиотек на примере своего пакета blob-util, который уже 10 лет стабильно набирает более 5 миллионов загрузок в неделю. С ростом использования ИИ (около 80% разработчиков уже применяют его в работе), такие утилиты становятся менее востребованными, ведь LLM вроде Claude способны генерировать аналогичный код по запросу. Автор отмечает, что хотя сгенерированный код может быть даже более надёжным, исчезает образовательная составляющая — его библиотека включала не только функционал, но и обучающие материалы с забавными примерами, помогающие понять принципы работы с Blob в JavaScript.

По мнению автора, эра небольших низкозначимых библиотек подходит к концу, и ИИ становится последним гвоздём в гробу этого явления, хотя и до этого многие функции перешли в браузеры и Node.js. Это означает не только упрощение разработки, но и потерю возможности использовать такие библиотеки как трамплин для обучения разработчиков. Возможно, в будущем понимание механики работы таких утилит станет так же необязательным, как и умение разворачивать бинарное дерево, о чём многие разработчики уже давно спорят.

• Разработчики всё чаще полагаются на ИИ, что ставит под сомнение ценность мелких утилитарных библиотек и даже саму идею open-source как таковой.
• Сообщество уже не в состоянии оценить ценность мелких, но полезных вкладов, поскольку ИИ может их сгенерировать за секунды.
• Это ведёт к тому, что единственный способ остаться востребованным — это делать действительно сложные и полезные вещи, а не просто публиковать мелкие скрипты.
• Парадокс в том, что даже если кто-то и захочет внести вклад в open-source, то непонятно, как теперь оценить этот вклад.
• В конечном счёте, если мы хотим, чтобы open-source выжил, мы должны будем придумать, как оценивать вклад и признание заслуг — возможно, через систему репутации и/или сертификации.

Разработчик представил Brimstone - новый JavaScript-движок, полностью написанный на Rust. Проект стремится создать альтернативу существующим движкам таким как V8 и SpiderMonkey, но с акцентом на безопасность и производительность за счет использования системы типов Rust и его современных возможностей. Rust обеспечивает безопасность памяти и потоков, что может снизить количество уязвимостей в движке по сравнению с традиционными реализациями на C++.

На данный момент проект находится на ранней стадии разработки, но уже демонстрирует потенциал для создания более безопасных и эффективных JavaScript-движков. Использование Rust для реализации движка JavaScript - это интересный тренд в индустрии, который также наблюдается в других проектах, таких как Deno и Boa, что указывает на растущий интерес к альтернативным языкам для критически важных компонентов веб-платформы.

• Обсуждение началось с благодарности за включение проекта в список и запуск бенчмарков, но быстро перешло к сравнению размеров бинарников Brimstone и Boa, где последний оказался в 3,5 раза больше из-за включённых ICU-таблиц Unicode.
• Участники обсудили, что "написано на Rust" стало маркетинговым клише, и как оно влияет на восприятие проекта, а также затронули тему лицензий и отсутствия лицензии в репозитории.
• Разговор затронул вопросы безопасности памяти и использования unsafe в контексте Rust, где участники обменялись мнениями о том, что именно подразумевается под этим и как это соотносится с выбором языка программирования.

Расширение tweeks предлагает пошаговый онбординг для подключения, включения скриптов и запуска первых модификаций веб-страниц. Процесс включает шесть этапов: установка расширения, закрепление для быстрого доступа, включение скриптов, запуск первого tweek, генерация первого скрипта и его модификация. Расширение позволяет создавать индивидуальные скрипты с помощью естественного языка и предоставляет готовые решения для распространенных задач.

Примеры возможностей включают режим фокуса для отвлекающих платформ вроде LinkedIn и YouTube, персонализацию лент в социальных сетях с фильтрацией по дате и количеству лайков, а также кастомизацию интерфейсов, например, превращение Google в командную строку 1970-х годов. Расширение работает на любом сайте и позволяет полностью переопределять DOM-структуру страниц, давая пользователям полный контроль над своим веб-опытом.

• Пользователи высоко оценивают идею "deshittify" веба через AI-генерацию кастомных скриптов для сайтов, называя её "крутой", "нужной" и "вдохновляющей".
• Поднимаются технические вопросы: глубина модификации страниц, тестирование модели, локальный запуск AI, детерминированность результатов и потенциальные риски утечки данных.
• Выражаются опасения по поводу бизнес-модели: риски судебных исков от соцсетей (Facebook, Reddit), монетизации, приватности данных и закрытости кода по сравнению с open-source альтернативами (Greasemonkey, uBlock Origin).
• Активно запрашивается поддержка Firefox, синхронизация настроек между устройствами и возможность совместного использования/поиска готовых скриптов.
• Критикуется отсутствие на сайте политики приватности и условий использования, а также сомнения в необходимости VC-финансирования для такого инструмента.

В проекте yt-dlp теперь требуется внешняя среда выполнения JavaScript для полноценной работы с YouTube. Это изменение связано с тем, что YouTube изменил способ защиты своего контента, и теперь для доступа к некоторым функциям необходимо выполнение JavaScript прямо в браузере. Ранее yt-dlp мог обходиться без этого, но из-за недавних обновлений на YouTube такая необходимость стала обязательной. Разработчики советуют пользователям убедиться, что у них установлена последняя версия yt-dlp и что среда выполнения JavaScript (например, Node.js) правильно настроена. Это изменение направлено на улучшение поддержки новых функций YouTube и обеспечение стабильности загрузки.

• YouTube и Google продолжают усложнять скачивание видео, что вызывает обсуждение о том, что делает невозможным для пользователей сохранять контент, несмотря на то, что это может быть законным для личного использования.
• Участники обсуждают, что Google и YouTube могли бы просто разрешить использование yt-dlp для премиум пользователей, что могло бы решить проблему, но вместо этого они выбирают делать это труднее.
• Обсуждается, что yt-dlp и другие инструменты всё ещё работают, но требуют больше усилий для обхода ограничений, что может быть неудобно для пользователей.
• Участники также обсуждают, что Google и YouTube могли бы просто разрешить использование yt-dlp для премиум пользователей, что могло бы решить проблему, но вместо этого они выбирают делать это труднее.
• Участники также обсуждают, что Google и YouTube могли бы просто разрешить использование yt-dlp для премиум пользователей, что могло бы решить проблему, но вместо этого они выбирают делать это труднее.

В статье утверждается, что JavaScript-библиотеки для выбора даты, такие как Pikaday, часто не нужны и могут приводить к ошибкам и брошенным формам. Вместо этого рекомендуется использовать нативные HTML-инпуты: date для дат, time для времени и datetime-local для их комбинации. Эти решения требуют всего одной строки кода, обеспечивают лучшую доступность, производительность и интернационализацию, работают без JavaScript и позволяют браузеру обрабатывать сложные детали.

В качестве альтернатив предлагаются раздельные инпуты для дня, месяца и года (особенно полезно для запоминающихся дат), селекты при ограниченном наборе вариантов и маскированные инпуты с плейсхолдерами. Для улучшения опыта можно использовать атрибуты: inputmode="numeric" для отображения цифровой клавиатуры, maxlength для ограничения ввода, pattern для валидации, autocomplete для автозаполнения и min/max для ограничений диапазона. Автор подчеркивает важность прогрессивного усиления и учета пользователей без JavaScript.

• Пользователи жалуются на нативные пикеры из-за необходимости тысяч кликов, чтобы выбрать дату рождения, и наоборот — кастомные пикеры не позволяют вводить дату текстом.
• Разработчики отвечают, что нативный <input type="date"> не поддерживает форматов вроде «MM/DD/YYYY» и не даёт контроля над UI, а кастомные пикеры не решают проблему с доступностью и не имеют единого UX.
• В итоге спор сводится к тому, что нативный пикер не решает проблему, а кастомный — не решает её лучше.
• Пользователи также жалуются на то, что нативный пикер не позволяет вводить дату текстом, а кастомный — не позволяет вводить дату текстом.
• В итоге, обсуждение сводится к тому, что нативный пикер не решает проблему, а кастомный — не решает её лучше.

Marko — это декларативный язык на основе HTML для создания динамических веб-интерфейсов, расширяющий стандартный HTML возможностями для современных приложений. Любой валидный HTML является корректным Marko, но язык добавляет декларативные конструкции для реактивности и интерактивности, позволяя встраивать JavaScript прямо в шаблоны. Ключевые особенности включают потоковую передачу контента для ускорения первого отрисовки, оптимизирующий компилятор и минимальный рантайм, что обеспечивает высокую производительность даже для высоконагруженных проектов вроде eBay.com.

Фреймворк предлагает гибкость синтаксиса — от привычного HTML до более лаконичных вариантов Concise и JS — и поддерживает TypeScript для строгой типизации. Marko обеспечивает разделение concerns, управляемые компоненты, вложенную реактивность и неизменяемое состояние, что упрощает разработку масштабируемых приложений. Интеграция с экосистемой включает file-based routing и возможность использования как простых шаблонов, так и мощных компонентов по мере роста проекта.

• Обсуждение вращается вокруг того, что веб-разработка циклически возвращается к идеям, похожим на ColdFusion и JSP, и это вызывает у участников разговора разные чувства от ностальгии до раздражения.
• Участники обсуждают, что такое "HTML-основнный" язык, и как он отличается от JSX и других подходов, и почему мы снова и снова возвращаемся к этой идее.
• Обсуждение затрагивает вопрос о том, что некоторые считают, что эволюция веб-технологий просто движется по спирали, где старые идеи периодически перерабатываются и выдаются как новые.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.

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

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

• Mozilla уволил волонтёров-переводчиков без предупреждения и предложил «быстро созвониться» вместо диалога; это вызвало волну возмущения в сообществе.
• Сообщество ответило, что открытое ПО и волонтёрство не должны быть взаимоисключающимися, и Mozilla должна была бы заранее обсудить изменения и уважительно относиться к вкладу волонтёров.
• В обсуждении также поднимается вопрос о том, что Mozilla в целом отошла от своих ценностей и миссии, и что это не первый случай подобного поведения.
• Участники обсуждения также отметили, что Mozilla в последнее время стала более закрытой и корпоративной, что вызывает тревогу.
• В конце концов, Mozilla сделала официальное извинение, но волонтёры заявили, что это слишком поздно и что Mozilla должна была бы лучше коммуницировать с сообществом и волонтёрами.

Представлен репозиторий Dillo — мультиплатформенного графического веб-браузера с открытым исходным кодом. Проект размещен на GitHub в рамках dillo-browser/dillo, что указывает на его организационную структуру и доступность для сообщества.

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

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

• Проект Dillo продолжает развиваться, но уходит с GitHub на собственный сайт и репозиторий.
• Пользователи вспоминают, как Dillo спасал старое железо и давал возможность выхода в интернет даже на самых слабых машинах.
• Обсуждается, что Dillo не поддерживает JavaScript, что ограничивает его применимость в современном вебе.
• Появляется вопрос о безопасности: неясно, какие меры безопасности реализованы в браузере.
• Участники обсуждают, что Dillo остаётся полезным для разработчиков и пользователей, которые ищут легковесный и быстрый браузер.

Layoutit Terra - это интерактивный генератор рельефа на CSS, позволяющий создавать разнообразные ландшафты с настраиваемыми параметрами. Инструмент предлагает выбор между типами рельефа (пампы, холмы, горы) и биомами (умеренный, арктический, пустынный), а также контроль над размером мира и покрытием суши. Пользователи могут детально настраивать камеру через параметры вращения, наклона и увеличения, добавляя анимацию к созданным ландшафтам.

Генератор поддерживает экспорт результатов в多种 форматы, включая CSS, высотные карты, VOX, TXT и PNG, что обеспечивает гибкость использования. Функции импорта, отмены/повтора действий, а возможность копировать код для встраивания или открывать его в Codepen упрощают интеграцию в другие проекты. Несмотря на раннюю версию (v0.0.1), Layoutit Terra уже предоставляет мощные возможности для создания детализированных CSS-ландшафтов с минимальными усилиями.

• Пользователи отмечают, что «CSS-only»-демо всё же использует JS для интерактивности, хотя рендеринг ландшафта действительно на 100 % CSS.
• Визуально демо напоминает RCT, SimCity 2000, Populous и другие изометрические «тайкун»-игры, вызывая ностальгию.
• Несколько человек сообщили о проблемах с производительностью: при включённом JS в Firefox 144 и Chrome 131 на Windows 10/11 рендеринг занимает 100-200 мс на обновление кадра, что приводит к просадкам фпс.
• Автор ответил, что в будущих версиях планируется добавить реки и водопады, а также улучшить производительность.

Команда Skald переписала бэкенд с Python на Node.js всего через неделю после запуска, идя против стандартного совета стартапам сначала "делать то, что не масштабируется". Основная причина — сложность с асинхронностью в Python, особенно при работе с Django. Автор отмечает, что писать качественный асинхронный код на Python "очень сложно и неинтуитивно", в отличие от JavaScript с его event loop или Go с goroutines.

Django до сих пор не имеет полной поддержки асинхронности: нет нативного асинхронного файлового ввода-вывода, ORM не поддерживает async, а для интеграции синхронных и асинхронных функций требуется постоянно писать sync_to_async и async_to_sync. Даже крупные компании вроде PostHog, несмотря на наличие AI-фич, продолжают использовать традиционный WSGI вместо полного перехода на асинхронность. В итоге команда пришла к выводу, что Django скоро начнет создавать проблемы с производительностью даже при небольшом количестве пользователей.

• Обсуждение в основном вращается вокруг того, что Python/async-экосистема остаётся незрелой, а Django-ORM не предназначена для асинхронной работы, что делает выбор между «старым, но проверенным» и «новым, но сырым» неоднозначным.
• Участники спорят, стоит ли жертвовать удобством разработки и экосистемой ради производительности, или же лучше переписать всё на Node/TypeScript, если речь идёт о высоконагруженном REST API.
• Поднимается вопрос о том, что выбор стека влияет на набор инженеров, и что важнее — удобство разработки или производительность.
• Некоторые участники подчеркивают, что важно не только выбрать правильный инструмент, но и уметь его использовать, иначе даже самый современный фреймворк не спасёт от проблем с масштабированием.

Автор обнаружил, что AI-скраперы запрашивают закомментированные JavaScript-файлы с его сайтов, вызывая ошибки 404. Эти запросы исходили как от явно вредоносных ботов (python-httpx, Go-http-client), так и от пользовательских агентов,伪装ившихся под обычные браузеры (Firefox, Chrome, Safari). Похоже, скраперы пытаются нелегально собирать контент для обучения больших языковых моделей.

Автор предлагает два возможных объяснения поведения: либо боты правильно парсят HTML-комментарии в поисках отключенных URL, либо используют примитивные методы сопоставления шаблонов. Он отмечает, что скраперы различаются по уровню сложности — одни используют актуальные строки user-agent, другие даже не меняют значения по умолчанию в HTTP-библиотеках.

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

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

Команда SpiderMonkey разработала новый инструмент для визуализации компиляции JavaScript и WebAssembly, создав собственный алгоритм расположения графов вместо использования Graphviz или Mermaid. Когда оптимизирующий компилятор Ion активен, система генерирует интерактивные графики, показывающие обработку и оптимизацию функций. Пользователи могут писать JavaScript-код и видеть в реальном времени, как изменяется граф, с возможностью навигации, масштабирования и просмотра различных этапов оптимизации.

Автор статьи не был удовлетворен выводом существующих инструментов, которые не отражали структуру исходного кода и создавали нестабильные макеты. Новый алгоритм, реализованный менее чем в 1000 строк кода, прост, быстр и produces высококачественный результат. Он учитывает специфические ограничения графов управления потоком, такие как наличие хорошо определенных циклов и необратимость потока управления, что позволяет создавать более интуитивные визуализации.

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

• Обсуждение показало, что специализированные решения для визуализации превосходят универсальные инструменты вроде Graphviz, но сообщество продолжает использовать последние из-за инерции и отсутствия альтернатив.
• Участники жалуются на то, что Graphviz и подобные инструменты не справляются с задачами даже средней сложности, и что их использование часто требует ручной доводки.
• Проект Microdiagram нацелен на создание DSL для каждого типа диаграмм вместо одного языка для всех типов диаграмм.
• Обсуждение также затронуло вопросы производительности и надежности инструментов, а также то, что сгенерированные ими диаграммы не всегда читаемы без дополнительной ручной работы.
• Участники поделились ссылкой на исходники на GitHub, где можно найти код, который может быть использован как стартовая точка для собственных экспериментов в этой области.

Несмотря на 15 лет развития фронтенда, сравнение React и Backbone показывает удивительно мало прогресса в снижении сложности. Код для одинаковой функциональности в обеих фреймворках примерно одинаков по длине, что ставит под сомнение все усилия сообщества. React выглядит чище, но это достигается за счет скрытой сложности абстракций, в то время как Backbone предлагает явное, хоть и многословное, описание происходящего.

"Вы торгуете явной простотой за сложность абстракций" — ключевая мысль статьи. React скрывает множество деталей: неожиданное очищение инпутов из-за смены ключей компонентов, бесконечные циклы в useEffect из-за нестабильных зависимостей, "устаревшие" замыкания в обработчиках событий. Эти не крайние случаи, а обычные проблемы, требующие понимания алгоритмов согласования, фаз рендеринга и планировщика React.

Для 99% приложений, не имеющих тысячи компонентов на странице, такая сложность может быть избыточна. Фундаментальная задача "событие + состояние = UI" остается простой, но современные фреймворки создают ненужные абстракции, мешающие пониманию и отладке. Возможно, сообществу стоит искать более прозрачные и "взламываемые" решения, подобные Backbone и jQuery.

• Обсуждение показало, что споры между сторонниками React и Backbone часто сводятся к сравнению простых примеров, что не отражает реальную сложность больших приложений и может вводить в заблуждение.
• Участники подчеркнули, что React и Backbone решают разные задачи: первый предлагает сложную, но мощную систему управления состоянием, тогда как второй предоставляет прямой и прозрачный контроль над DOM.
• Несколько человек отметили, что выбор между инструментами должен зависеть от характера проекта и команды, а не от сравнения "Hello World" примеров.
• Обсуждение также затронуло вопрос о том, что разработчики могут переоценивать или недооценивать сложность, связанную с управлением состоянием, и как это влияет на выбор инструмента.
• Наконец, было высказано мнение, что выбор между React и Backbone должен быть основан на факторах, таких как размер команды, сложность проекта и долгосрочная поддерживаемость, а не на сравнение простых примеров кода.

Кандидат на собеседовании решает задачу FizzBuzz с помощью комбинаторной логики и лямбда-исчисления в JavaScript, используя лишь базовые комбинаторы S, K и I. Интервьюер всё больше недоумевает, наблюдая, как соискатель последовательно реализует сложнейшие математические операции и структуры данных через композицию этих комбинаторов, включая числа Чёрча, арифметические операции и даже Y-комбинатор для рекурсии.

Кандидат оправдывает свой подход тем, что "JavaScript слишком раздут", и переключается на "ленивый" вариант JavaScript под названием Skoobert, чтобы избежать переполнения стека. В итоге он реализует всё необходимое для FizzBuzz — от сложения и вычитания до списков и операций над ними — исключительно через комбинаторы, демонстрируя глубокое, но совершенно не практичное знание теоретических основ программирования.

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

Предоставленный текст содержит только навигационную структуру сайта MDN, но не основное содержание статьи о методе setHTML(). В тексте отсутствует описание самого API, его синтаксиса, параметров, примеров использования и совместимости с браузерами. Для создания точного пересказа требуется полное содержание статьи, описывающее новый метод DOM API, который, вероятно, предоставляет альтернативу innerHTML с дополнительными возможностями или улучшенной безопасностью. Без доступа к фактическому описанию метода невозможно предоставить содержательный пересказ его функциональности и применения.

• Впервые за 25 лет в Firefox Nightly появилась возможность безопасно вставлять HTML через Element.setHTML(), что вызвало обсуждение: спор о том, почему так долго не хватало базовой возможности, и о том, что API-шный дизайн (включая именование setHTML/setHTMLUnsafe) не идеален.
• Участники обсуждения отметили, что новое API встроенной санитизации встроенной в браузер — это фактически встроенный DOMPurify, и что спор в основном ведется о том, что «безопасность по умолчанию» должна быть выбрана как поведение по умолчанию.
• Некоторые комментаторы выразили обеспокоенность тем, что спецификация пока не различает между контентом и вставляемым через setHTML() и innerHTML, и что это может влиять на производительность, если разработчики начнутт читать спецификацию как «естественное продолжение» innerHTML.
• Были также затронуты темы о том, что встроенная санитизация может влиять на разработчиков, которые полагаются на встроенную санитизацию, и о том, что это может влиять на разработчиков, которые полагаются на встроенную санитизацию.

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

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

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

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

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

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

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

Twitter/X теперь требует включённый JavaScript и блокирует просмотр без него. Пользователи с блокировщиками скриптов или расширений, которые ограничивают JS, теперь видят сообщение о недоступности JavaScript и предлагают «попробовать снова». Это делает невозможным просмотр даже статического контента без JS.

• Обсуждение выявило, что LLM-ы склонны к чрезмерно защитному стилю кода, который, как выясняется, может быть вызван RLHF и набором данных, где «правильный» код — это тот, который перестраховывается на каждом шаге.
• Участники обсудили, что «защитный» код может быть не только избыточным, но и логически неверным, поскольку он может маскировать ошибки, которые в продакшене не должны быть проглочены.
• Некоторые участники отметили, что вместо того, чтобы учить модель писать «правильный» код, стоит сфокусироваться на том, чтобы она училась различать, когда действительно нужна обработка ошибок, а когда можно обойтись без нее.
• Также было отмечено, что вместо того, чтобы писать в защитном стиле, лучше бы научить модель писать код, который не делает глупых ошибок в первую очередь.

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

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

• Впечатляющий прогресс независимого проекта Ladybird, достигнутый за короткое время, приближает его к практической пригодности.
• Прохождение 90% тестов WPT — это произвольный, но требуемый Apple метрический порог для рассмотрения в качестве альтернативного движка в iOS; сама метрика считается несовершенной.
• Реальная сложность заключается в поддержании темпа развития и реализации постоянно растущего количества новых веб-API, а не только в прохождении текущих тестов.
• Вызывают вопросы безопасность и наличие песочниц в быстро разработанном движке, а также его текущая производительность при повседневном использовании.
• Проект рассматривается как важная альтернатива доминирующим движкам, но до полной конкурентоспособности еще несколько лет работы.

Инженеры всё чаще запускают несколько агентов одновременно — например, одновременно работают несколько экземпляров Claude Code или Codex CLI в разных директориях или даже в разных репозиториях. Саймон Уиллисон, который сам пишет код на Python и JavaScript, решил проверить, насколько полезно это на практике.

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

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

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

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

• Обсуждение в основном вращается вокруг трёх тем: высокая стоимость ревью кода, параллельные агенты и их влияние на фокус и продуктивность, а также культурные и этические аспекты использования AI-агентов.
• Участники делятся личными стратегиями, такими как использование различных инструментов вроде Conductor и Crystal для управления агентами, и обсуждают, как сделать их более эффективными.
• Обсуждается, как сделать ревью кода менее трудоёмким, включая использование инструментов вроде bottleneck для ревью кода, и как влияет на продуктивность и фокус.
• Также обсуждается, как влияет на эффективность работы использование AI-агентов, и какие могут быть последствия для долгосрочной устойчивости и качества кода.

Социальная сеть X (ранее Twitter) требует включённого JavaScript для работы. При его отключении пользователь видит сообщение о необходимости активировать JavaScript или сменить браузер на поддерживаемый, со ссылкой на список совместимых браузеров.

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

• Критика отсутствия у Google сильной продуктовой культуры, что мешает созданию инновационных продуктов на основе их же технологий.
• Обсуждение субъективности сравнения моделей ИИ (Gemini, GPT, Claude) и сложности объективной оценки из-за различий в задачах и опыте пользователей.
• Скептицизм по поводу рекламных кампаний и хайпа вокруг новых моделей, которые часто не соответствуют реальным возможностям.
• Подчеркивание проблем Gemini с многократным выполнением инструкций и склонностью к "зацикливанию" по сравнению с конкурентами.
• Отмечается сильная мультимодальность Gemini (работа с изображениями, видео), но сложность доступа и использования продуктов Google AI.

Автор перевел свой блог с Racket на Lua, чтобы снизить сложность и обеспечить долгосрочную стабильность. Основная причина — разочарование в быстро меняющихся экосистемах вроде JavaScript и Ruby, где постоянные обновления и ломающие изменения усложняют поддержку. Lua привлек медленным развитием: между версиями 5.1 (2006) и 5.4 (2020) различия минимальны, а язык требует лишь компилятора C89.

Блог работает по старинке — через CGI-скрипты, с SQLite в качестве базы и шаблонизацией Mustache. Несмотря на кажущуюся архаичность, автор ценит простоту, минимальное количество зависимостей (около десяти) и возможность писать собственные легковесные библиотеки. Ключевой вывод: блог — это пространство для экспериментов, где можно отказаться от модных инструментов в пользу того, что действительно работает и приносит удовольствие.

• Предложение возродить создание собственных движков для блогов как учебного проекта для инженеров из-за его низкого риска и возможностей для экспериментов.
• Обсуждение выбора Lua как стабильного и минималистичного языка для веб-разработки, несмотря на его недостатки (1-based индексация, разрыв между версиями, мало стандартных библиотек).
• Критика сложности современных стеков для блогов и аргументы в пользу простых решений: статические генераторы (Hugo), чистый HTML или минимальные скрипты (Python, Lua).
• Упоминание альтернативных технологий и подходов: Redbean, Perl, Caddy, XSLT, Web Components, Fennel, OpenResty и другие.
• Подчёркивание важности личного выбора, удовольствия от процесса и независимости от внешних сервисов при создании блога.

Автор вспоминает, как начал программировать в 2010 году, почти бросив идею из-за неуверенности, но в итоге полюбил это дело через упорство. Он признаётся, что писал много «глупого» кода во время учёбы и игровых джемов, что помогло ему отточить навыки и сохранить интерес.

Сейчас, работая с JavaScript и Deno, он осознал, что стал излишне строг к себе, боясь писать что-то простое или неидеальное. Его вывод: не стоит сдерживаться — любой код, даже самый нелепый, это шаг вперёд. Важно экспериментировать, пробовать новое и просто получать удовольствие от процесса, ведь это поддерживает любопытство и профессиональный рост.

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

Это браузерная игра «Змейка», которая использует URL-страницы в качестве игрового поля. Управление осуществляется стрелками или клавишами WASD, а змейка перемещается прямо в адресной строке. Если URL отображается некорректно, есть кнопка для исправления отображения.

Игра сохраняет рекорд игрока в очках и позволяет делиться результатом. Создана разработчиком под ником @epidemian, исходный код открыт на GitHub. Проект демонстрирует креативный подход к использованию стандартных элементов браузера для создания игрового процесса.

• Пользователи восхищены креативностью и нестандартным подходом к реализации игры "Змейка" в адресной строке браузера с использованием символов Unicode (Braille).
• Обсуждаются технические аспекты и проблемы: некорректное отображение пробелов в некоторых браузерах, предложения по улучшению (использование других символов, зацикливание границ), ограниченная работа на мобильных устройствах.
• Предупреждения о возможных проблемах с историей браузера и рекомендации использовать режим инкогнито.
• Упоминаются похожие проекты: игры в favicon (2048, другая версия "Змейки"), а также шуточные предложения портировать Doom.
• Автор проекта (@epidemian) отмечает, что игра создана 10 лет назад и может некорректно работать в современных браузерах.

Перевод симулятора F-16 из Fortran в Unity3D потребовал адаптации аэрокосмических конвенций под игровой движок. Модель полёта, основанная на данных аэродинамических труб и реализованная через дюжину таблиц поиска и математических уравнений, изначально использовала правостороннюю систему координат с осью X вперёд, Y вправо и Z вниз — в отличие от левостороннего Z-вверх подхода Unity. Ключевой задачей стало корректное преобразование осей и знаков без потери физической точности.

Процесс включал интерполяцию многомерных таблиц, расчёт тяги двигателя, аэродинамических сил и моментов, а также реализацию системы управления полётом с PID-контроллерами и ограничителями перегрузки. Несмотря на профессиональный бэкграунд в аэрокосмической отрасли, автор отмечает сложность верификации такой модели без доступа к реальным лётным данным. Готовый симулятор доступен на itch.io, демонстрируя практический компромисс между академической точностью и игровой доступностью.

• Участники обсуждают опыт работы с FORTRAN и его применение в аэрокосмической симуляции, включая исторические примеры и личные воспоминания.
• Поднимаются вопросы о единицах измерения (например, узлы, слагы) и их конвертации, с критикой подхода автора и предложениями использовать метрическую систему.
• Обсуждаются технические особенности языков программирования, такие как произвольные индексы массивов в FORTRAN и их аналоги в других языках.
• Упоминаются альтернативные реализации симуляторов на JavaScript и Clojure, а также ссылки на открытые проекты вроде Falcon BMS.
• Затрагиваются темы игровой ностальгии, сложностей моделирования физики и юмористические комментарии о единицах измерения (например, поронкусема).

Ollama представила новый API для веб-поиска, который позволяет моделям получать актуальную информацию из интернета, снижая риск галлюцинаций и повышая точность ответов. Бесплатный тариф доступен для индивидуального использования, а повышенные лимиты — через Ollama Cloud. API интегрирован с Python и JavaScript библиотеками, что упрощает создание инструментов для длительных исследовательских задач, включая работу с моделями вроде OpenAI gpt-oss.

Примеры кода демонстрируют использование через cURL, Python и JavaScript, возвращая структурированные результаты поиска с заголовками, URL и содержанием. Также показано, как построить поискового агента с помощью модели Qwen 3 от Alibaba, используя инструменты web_search и web_fetch для автоматизации запросов и обработки данных. Это расширяет возможности моделей, позволяя им активно взаимодействовать с веб-источниками в реальном времени.

• Вопросы о поисковом провайдере и лицензии на результаты поиска, включая возможность их хранения и перепубликации.
• Сомнения в бизнес-модели Ollama, её переходе от локального хостинга к облачным услугам и планам монетизации.
• Обсуждение технических альтернатив для локального поиска и индексации, а также интеграции с Ollama.
• Критика запуска функции веб-поиска без четкой документации по тарифам, лимитам и политике конфиденциальности.
• Предложения и опыт использования сторонних инструментов для поиска (SearXNG, Tavily, SERP API) и локальных решений.

Похоже, это сообщение о процессоре Snapdragon X2 Elite от Qualcomm, но доступ к полной информации требует включения JavaScript в браузере. Без активации скриптов содержимое страницы, включая технические характеристики, производительность или особенности чипа, недоступно для просмотра.

Рекомендуется разрешить выполнение JavaScript в настройках браузера, чтобы ознакомиться с деталями о процессоре — вероятно, это новые разработки в области мобильных или портативных вычислений.

• Обеспокоенность недостаточной открытостью и документацией для Snapdragon X2, что затрудняет поддержку Linux и разработку драйверов.
• Вопросы о реальной производительности, энергоэффективности и технических деталях (поддержка TSO, пропускная способность памяти, TDP) без предоставления бенчмарков.
• Скептицизм относительно заявлений о многодневной автономности и маркетинговых формулировок ("легендарный скачок").
• Надежды на появление конкурентов Apple Silicon и качественных ARM-ноутбуков с хорошей поддержкой Linux.
• Обсуждение ниши для ARM-чипов и необходимости поддержки со стороны Microsoft и OEM-производителей.

YouTube скоро внедрит изменения, которые могут нарушить работу инструментов для скачивания видео, включая yt-dlp. Разработчики проекта предупреждают о необходимости адаптации к новым требованиям, связанным с обновлениями в API и механизмах защиты контента.

Пользователям стоит ожидать временных сбоев или необходимости обновлять софт чаще. Сообществу предлагается участвовать в тестировании и сообщать о проблемах, чтобы ускорить исправления. Это подчеркивает хрупкость инструментов, зависящих от сторонних платформ.

• Пользователи столкнулись с проблемами скачивания контента через официальное приложение YouTube и обсуждают использование yt-dlp как обходного решения
• YouTube усложняет процесс скачивания, внедряя сложный JavaScript-код, что вынуждает yt-dlp переходить на использование полноценной JS-среды выполнения (Deno) вместо самописного интерпретатора
• Сообщество выражает озабоченность по поводу будущего скачивания контента с YouTube, обсуждает технические сложности и возможные альтернативы для архивации видео
• Выбор Deno обусловлен его безопасностью и наличием самодостаточного бинарного файла, но это добавляет зависимость и усложняет использование yt-dlp в некоторых сценариях
• Обсуждаются потенциальные последствия для сторонних приложений и необходимость сохранения контента в свете ужесточения политики YouTube

Python сохраняет лидерство благодаря своей универсальности в машинном обучении и веб-разработке, а JavaScript остаётся незаменимым для фронтенда. Rust продолжает расти из-за акцента на безопасность и производительность, особенно в системном программировании. Go набирает популярность в облачных сервисах и микросервисной архитектуре благодаря простоте и эффективной параллельной обработке.

Стоит отметить рост TypeScript как более строгой альтернативы JavaScript, а также стабильное присутствие Java в корпоративных приложениях. Интерес к Julia увеличивается в научных вычислениях, а Kotlin укрепляет позиции в мобильной разработке под Android. Практический вывод: выбор языка всё больше зависит от конкретной области, а не только от общей популярности.

• Сомнения в методологии рейтинга языков программирования IEEE из-за использования ненадёжных источников (поисковые запросы, устаревающий StackOverflow), что может искажать реальную картину.
• Удивление высокой позицией Java (2-е место), объясняемой её доминированием в enterprise-секторе (финансы, страхование, здравоохранение) и миграцией legacy-систем с COBOL.
• Обсуждение искусственного завышения позиции Python из-за его популярности у новичков, в академических статьях и как основного языка вывода для LLM.
• Предложение объединить рейтинги близких языков (JavaScript/TypeScript, Java/Kotlin, C/C++) для более точного отражения популярности экосистем.
• Размышления о влиянии AI-ассистентов на будущее языков: возможная стагнация из-за зависимости LLM от популярных языков или, наоборот, упрощение изучения нишевых.

Cap'n Web — это новая система RPC для браузеров и веб-серверов, созданная Cloudflare на чистом TypeScript. Она наследует философию объектно-ориентированных возможностей (object-capability) от Cap'n Proto, но оптимизирована для веб-стека: использует JSON для сериализации, работает поверх HTTP, WebSocket и postMessage(), весит менее 10 КБ и не требует схем или шаблонного кода. Поддерживает двусторонние вызовы, передачу функций и объектов по ссылке, а также конвейеризацию промисов для сокращения задержек.

Настройка занимает буквально несколько строк: клиент подключается через WebSocket, а сервер реализуется как класс с методами, которые автоматически становятся удалёнными процедурами. Например, метод hello(name) на сервере можно вызвать из браузера как api.hello("World"). Система интегрируется с TypeScript для типобезопасности и работает в Cloudflare Workers, Node.js и современных браузерах. Это делает распределённое программирование почти неотличимым от локального, с учётом сетевых реалий.

• Обсуждение Cap'n Web как упрощённой, schemaless версии Cap'n Proto RPC для TypeScript/JavaScript с поддержкой передачи функций и двусторонних вызовов.
• Сравнение с другими технологиями: проводятся параллели с GraphQL (решение проблемы N+1, но без DataLoader), tRPC/ORPC (схемы vs schemaless), gRPC-web (сложность) и старыми системами вроде Java RMI или .NET Remoting.
• Подняты вопросы о безопасности (риски из-за отсутствия схем и передачи произвольных колбэков), состоянии сервера (статусность vs статусность) и проблемах отладки (сложность отслеживания сетевых запросов).
• Обсуждаются технические детали: пайплайнинг промисов для уменьшения RTT, выполнение .map() на сервере через DSL, управление памятью и сборкой мусора для долгоживущих соединений.
• Запросы на расширение: поддержка других языков (Rust, Elixir), стриминг, генераторы, версионирование API и бинарная совместимость с Cap'n Proto.

Cloudflare объявляет о спонсорской поддержке двух независимых open-source проектов — браузера Ladybird и дистрибутива Omarchy на базе Arch Linux для разработчиков. Это часть стратегии по укреплению открытого интернета через разнообразие инструментов. Ladybird — амбициозная попытка создать браузер с нуля, включая собственные движки рендеринга (LibWeb) и JavaScript (LibJS), что контрастирует с доминированием Chromium, используемого 65% пользователей. Такой подход стимулирует инновации в безопасности и производительности, а также выявляет недочёты в веб-стандартах.

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

• Обсуждение спонсорства Cloudflare проектов Ladybird и Omarchy с акцентом на возможные скрытые мотивы компании, включая движение к вебу только для одобренных браузеров.
• Скептицизм относительно практической ценности Omarchy как ещё одного дистрибутива Linux и его сравнение с другими установщиками и системами, такими как Nix или Alpine.
• Вопросы о целесообразности создания нового браузерного движка (Ladybird) на C++ вместо более безопасных языков и сомнения в его способности конкурировать с существующими гигантами.
• Обсуждение личности DHH (создателя Omarchy) и его спорных высказываний, а также того, должно ли это влиять на поддержку его проектов.
• Поднята тема стратегического интереса Cloudflare к децентрализации веба и уменьшения зависимости от Google, аналогичного стратегии Valve с Proton.

HackerOne — это платформа для координации программ bug bounty, где компании платят исследователям за обнаружение уязвимостей в их системах. Для полноценной работы сайта требуется включенный JavaScript в браузере, так как многие интерактивные функции, включая отправку отчетов и взаимодействие с интерфейсом, зависят от него.

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

• Пользователи обсуждают волну бесполезных AI-генерируемых отчетов об уязвимостях (например, для cURL), которые тратят время разработчиков.
• Высказываются опасения, что в будущем AI сможет генерировать более правдоподобные, но все же ложные доказательства концепций (PoC).
• Предлагаются решения для борьбы со спамом: платный депозит за отправку отчета, баны, фильтрация по эмодзи и другим признакам AI-текста.
• Обсуждается негативное влияние AI на качество кода, ревью и общую культуру разработки, а также возможные скрытые мотивы таких атак.
• Отмечается профессиональная реакция мейнтейнера (badger) на некорректный отчет и ссылки на соответствующие доклады Дэниела Стенберга о проблеме.

Многие библиотеки в экосистеме JavaScript стали избыточно сложными из-за попыток обработать все возможные крайние случаи, даже те, что на практике почти не встречаются. Например, функция clamp, предназначенная для ограничения чисел, превращается в монстра, проверяющего строки, валидирующего типы и значения, что приводит к появлению микробиблиотек вроде is-number с 90 млн загрузок в неделю. Это результат плохого технического дизайна: вместо чёткого определения ожидаемых входных данных разработчики добавляют слои проверок для гипотетических сценариев.

Правильный подход — проектировать функции под конкретные типы данных, оставляя валидацию значений на усмотрение вызывающей стороны. Библиотеки вроде is-arrayish или pascalcase, принимающие разнородные входы, лишь увеличивают сложность и зависимости без реальной пользы. Стоит вернуться к простоте: в большинстве случаев достаточно встроенных методов языка, а специализированные решения нужны только для узких задач, а не как стандарт.

• Обсуждение критикует избыточное использование зависимостей в JavaScript/TypeScript для простых задач, таких как проверка типов, что ведет к раздуванию экосистемы.
• Участники связывают проблему с историческими особенностями JavaScript: отсутствием строгой типизации и богатой стандартной библиотеки в прошлом.
• Поднимается вопрос о дизайне контрактов функций: следует ли валидировать входные данные внутри функции или возлагать эту ответственность на вызывающую сторону.
• Отмечается культурное различие между сообществами: в Python принята модель "согласованных взрослых", а в JS — оборонительное программирование.
• Обсуждается роль статической типизации (TypeScript) и стандартных библиотек как способа уменьшить потребность в микро-пакетах для проверок.

Deno подала официальную петицию в Ведомство по патентам и товарным знакам США, чтобы оспорить товарный знак Oracle на слово «JavaScript». После сбора более 27 тысяч подписей под открытым письмом проект перешёл к ключевой стадии discovery, требующей серьёзных ресурсов. Цель — доказать, что термин стал общедоступным обозначением языка, а не брендом Oracle, и освободить его для использования разработчиками, конференциями и авторами без юридических рисков.

Для усиления позиции Deno запустила кампанию по сбору $200 тыс. на экспертные опросы, показания свидетелей из индустрии и академической среды, а также юридические расходы. Oracle уже официально отвергла аргументы о generic-статусе термина. Успех дела важен не только для JavaScript, но и для принципов товарного права: победа корпорации создаст прецедент присвоения общеупотребимых понятий.

• Критика сбора средств VC-финансируемой компанией Deno для суда с Oracle из-за товарного знака "JavaScript"
• Сомнения в успехе и целесообразности дела против Oracle с её огромными ресурсами и возможными негативными последствиями для сообщества
• Предложения альтернативных решений: переход на использование названий "JS", "ECMAScript" или "TypeScript"
• Восприятие инициативы как PR-хода или маркетингового хода, а не искреннего общественного служения
• Поддержка цели освобождения названия, но с оговорками относительно мотивов и методов Deno

Борьба против Chat Control: "Позиция Германии вернулась к статусу НЕОПРЕДЕЛЕННОСТЬ..."

Для использования веб-приложения Mastodon необходимо включить JavaScript. Также можно воспользоваться нативными приложениями для вашей платформы.

• Исключение для государственных аккаунтов ставит под сомнение заявления о безопасности и точности системы, указывая на вероятность ложных срабатываний.
• Предложение воспринимается как антидемократичное и нелегитимное, подрывающее доверие к ЕС и ведущее к росту поддержки крайних политических сил.
• Реализация подобного контроля технически неfeasible, так как злоумышленники могут легко обойти его с помощью альтернативных зашифрованных каналов.
• Критики проводят параллели с историей тотальной слежки (Стази, Третий рейх) и предупреждают о создании дистопического инструмента массового наблюдения.
• Обсуждение выявляет циничный мотив лоббирования со стороны компаний-поставщиков surveillance-решений (Thorn, Palantir) и заинтересованных госструктур (Europol).
• Исключение для политиков трактуется как способ избежать бумажного следа и подотчетности, а безопасность служит лишь прикрытием.
• Многие пользователи выражают готовность полностью отказаться от сервисов, которые подчинятся таким требованиям, и поддерживают принцип сквозного шифрования.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

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

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

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

Закон жёстко настиг Microsoft, и в 2001 году она проиграла — Microsoft было приказано разбить компанию, но апелляция отменила это решение.

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.

Компрометация пакетов ctrl/tinycolor и 40+ других в NPM

Популярный пакет @ctrl/tinycolor с более чем 2 млн загрузок в неделю был скомпрометирован вместе с 40+ другими пакетами в результате сложной атаки на цепочку поставок. Вредоносное ПО самораспространяется по пакетам maintainer'ов, собирает учетные данные AWS/GCP/Azure с помощью TruffleHog и создает бэкдоры через GitHub Actions.

Технический анализ

Атака реализуется через многоступенчатую цепочку, использующую Node.js process.env для доступа к учетным данным. Основной элемент — файл bundle.js (~3.6 МБ), который выполняется асинхронно во время npm install.

Механизм самораспространения
Вредоносное ПО через функцию NpmModule.updatePackage запрашивает API реестра NPM для получения до 20 пакетов maintainer'а и принудительно публикует обновления, создавая каскадный эффект компрометации.

Сбор учетных данных
Используются инструменты вроде TruffleHog для сканирования файловой системы на наличие секретов. Целевые учетные данные включают:

• Токены доступа GitHub
• Ключи доступа AWS
• Учетные данные Google Cloud Platform

• Пользователи выражают обеспокоенность невозможностью аудита всех зависимостей и их уязвимостью к атакам в npm.
• Критикуется архитектура npm, в частности выполнение postinstall-скриптов по умолчанию, в отличие от других менеджеров пакетов.
• Предлагаются решения: игнорирование скриптов в настройках, песочница (bubblewrap), использование подписей кода и каррированных пакетов.
• Указывается на системную проблему экосистемы JS: огромное количество мелких зависимостей и отсутствие сильной стандартной библиотеки.
• Обсуждается масштаб атаки (180+ пакетов) и её возможная связь с государственными акторами.
• Поднимается вопрос уязвимости других экосистем (PyPI) и необходимости обязательной 2FA и подписи артефактов.
• Высказываются радикальные предложения по замене npm или созданию безопасного форка/дистрибутива пакетов.

Разработчики часто тяготеют к сложности, хотя принцип KISS («будь проще») хорошо известен. Почему так происходит?

Маркетинг важнее простоты

Продать обычную ручку сложно, но если добавить ей множество функций — она станет «продаваемой». Так и в IT: простые инструменты вроде cat работают идеально, но маркетинг продвигает сложные аналоги с громкими названиями. Социальное доказательство и ощущение эксклюзивности заставляют нас воспринимать сложность как признак качества, хотя часто это просто иллюзия.

Что внутри «пирамид»?

Современные системы напоминают пирамиды: много слоёв, зависимостей и абстракций, но внутри может быть пустота. Сложность кричит «посмотри на меня!», а простота остаётся незаметной, пока не проявится её гениальность. В долгосрочной перспективе побеждает именно простота.

React против ванильного JavaScript

React навязывает множество концепций: рендеринг, хуки, состояния, маршрутизация. Отказ от него может сделать вас «аутсайдером», хотя ванильный JavaScript часто решает задачи эффективнее. Компании вкладывают миллионы в продвижение фреймворков, что усложняет выбор в пользу простых решений.

Глубинные причины любви к сложности

1. Творческий соблазн: Создание сложных систем — интеллектуальный вызов, который приносит удовлетворение.
2. Технический долг: Наследие старых проектов вынуждает добавлять новые слои вместо упрощения.
3. Командная динамика: Разработчики добавляют абстракции для «универсальности», что усложняет систему.
4. Давление инноваций: Конкуренция подталкивает к созданию сложных решений, чтобы выделиться.

Стройте с умом

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

• Сложность часто возникает из-за добавления быстрых исправлений вместо переосмысления архитектуры с учетом новых требований.
• Простые решения требуют больше усилий для проектирования и поддержки, чем сложные, которые появляются быстрее.
• Реальность полна деталей, и простые решения редко охватывают всю сложность проблемы, что ведет к наращиванию сложности системы.
• Разработчики могут добавлять сложность для демонстрации навыков, интереса или ощущения достижения, что поощряется в индустрии.
• Долгоживущие кодобазы неизбежно накапливают сложность из-за постоянных изменений и адаптации к новым требованиям.
• Простота субъективна и требует глубокого понимания основ и дисциплины для достижения и поддержания.
• Бизнес-среда и отсутствие прямого контакта с пользователем могут способствовать выбору сложных решений вместо фокуса на ценности.
• Сложность иногда искусственно создается для обеспечения job security или из-за организационных проблем и политик.
• Эволюция технологий и библиотек часто следует за обобщением паттернов, что добавляет абстракции и сложности.

React победил по умолчанию — и это убивает фронтенд-инновации

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

Команды редко начинают с вопроса «Какие ограничения и какой инструмент подходит лучше?». Чаще звучит: «Давайте использовать React — все его знают». Это создаёт цикл, где архитектуру определяют сетевые эффекты, а не техническая целесообразность.

Между тем, фреймворки с реальными инновациями борются за внедрение. Svelte устраняет накладные расходы компиляцией, Solid предлагает детальную реактивность без виртуального DOM, Qwik обеспечивает мгновенный запуск через возобновляемость. Эти подходы часто превосходят модель React, но редко получают оценку, потому что React выбирают по умолчанию.

Проблема не в самом React, а в мышлении «React по умолчанию».

Потолок инноваций

Технические основы React объясняют современные трудности. Виртуальный DOM был умным решением для проблем 2013 года, но, как отметил Рич Харрис, он вводит издержки, которых можно избежать с помощью компиляторов.

Хуки решили проблемы классовых компонентов, но добавили сложности: массивы зависимостей, устаревшие замыкания, неправильное использование эффектов. Даже документация React призывает к сдерженности: «Вам может не понадобиться эффект». Серверные компоненты улучшают время до первого байта, но добавляют архитектурную сложность.

Компилятор React — умное решение для автоматизации useMemo/useCallback, но его существование сигнализирует: мы оптимизируем вокруг ограничений модели.

Альтернативы предлагают иные подходы: Runes в Svelte 5 упрощают реактивность на этапе компиляции, детальная реактивность Solid обновляет только изменённые части, возобновляемость Qwik устраняет традиционную гидратацию. Это не инкрементные улучшения React, а другие модели с иными пределами.

Инновации без внедрения не меняют результаты. Внедрение невозможно, когда выбор делается рефлекторно.

Технический долг, который мы несём

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

Исследования производительности единодушны: JavaScript дорог на критическом пути.

Мы сосредоточили ментальные модели вокруг «React-паттернов» вместо основ веба, снижая переносимость навыков и увеличивая архитектурную инерцию.

Потеря не только в производительности, но и в упущенных возможностях, когда альтернативы не оцениваются. Например, бенчмарки показывают, что Solid в 2-3 раза быстрее React в сценариях с интенсивной реактивностью.

Фреймворки, которым не дают развиваться

Svelte: революция компилятора

Svelte переносит работу на этап компиляции: нет виртуального DOM, минимальный runtime. Компоненты становятся целевыми операциями DOM. Ментальная модель соответствует основам веба.

Но «недостаточно вакансий» искусственно сдерживает внедрение Svelte, несмотря на технические преимущества.

• React побеждает благодаря композиции функций JavaScript, интуитивной модели и стабильности, а не только из-за сетевых эффектов.
• Веб-компоненты рассматриваются как путь к совместимости между фреймворками и снижению зависимости от экосистемы React.
• Многие разработчики ценят React за предсказуемость, лёгкость найма и богатую экосистему, что делает его безопасным выбором.
• Критики указывают на сложности React (хуки, зависимости, ререндеры) и чрезмерный boilerplate-код.
• Альтернативы вроде Svelte или Solid предлагают упрощённые модели и лучшую производительность, но проигрывают в распространённости.
• Инновации во фронтенде часто воспринимаются как «суета», ведущая к устареванию проектов и постоянным переписываниям.
• React доминирует частично из-за React Native, что позволяет использовать единую кодобазу для web и мобильных платформ.
• Браузеры и стандарты Web обвиняются в недостаточной скорости развития, что вынуждает полагаться на фреймворки.
• Стабильность и стандартизация ценятся выше постоянных изменений и «инноваций» в индустрии.

Боритесь с контролем чатов: «Министр юстиции Дании и главный архитектор…»

Для использования веб-приложения Mastodon включите JavaScript. Также можно попробовать нативные приложения Mastodon для вашей платформы.

• Участники дискуссии единодушно отвергают позицию министра юстиции Дании, считая конфиденциальность и шифрование личных сообщений фундаментальным правом и гражданской свободой, защищенной как международными конвенциями, так и национальными конституциями.
• Предлагаемый закон (ChatControl) расценивается как тотальная система массовой слежки, которая нарушает приватность всех граждан, а не только подозреваемых.
• Многие отмечают лицемерие власти, которая хочет получить доступ к данным граждан, но оставляет неприкосновенной собственную переписку.
• Подчеркивается техническая и практическая несостоятельность запрета шифрования, который подорвет безопасность и доверие в цифровой сфере, включая финансовые операции.
• Участники считают, что подобные меры неэффективны для борьбы с преступностью, так как преступники найдут обходные пути, а страдают законопослушные граждане.

Doomscrolling: игра
Скроллинг как единственный способ управления.

---

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

Попытка №1: провал
9 месяцев назад ни один LLM не смог связать «скролл вниз» с «фон движется вверх». Получилась пародия на игру. Забросил.

GPT-5 и победа
Через пару часов — рабочий прототип.

• Враги: 5 спрайтов, 2 кадра, как у Space Invaders.
• Механика: Galaga, но вертикально. Игрок движется вперёд-назад, монстры «привязаны» к полу.

Кофе-морнинги на каникулах
По часу утром:

• апгрейд оружия каждые 100 убитых;
• огненная стена подталкивает не стоять на месте;
• препятствия: кирпичи, паутина;
• 5 фонов, зелья здоровья, метка личного рекорда, пауза со статой.

Финальный штрих: новости
Появляются мемориальные плиты с заголовками NYT за сегодня. Не влияют на геймплей, только отвлекают.
Игра = самый сложный RSS-ридер в мире.

ИИ всё ещё тупит
Когда LLM не понимает, прерываю диалог и начинаю новый с тем же промптом — срабатывает.

• Пользователи в восторге: человек без навыков кодинга собрал динамичную «дум-скролл»-игру, спросив ChatGPT сгенерировать всё.
• Механика: скроллинг = движение; враги и огонь идут снизу, игроку надо лутать апгрейды и убивать монстров.
• Впечатляет «лаборатория» со слайдерами для настройки спрайтов — пример Steve-Jobs-овского «конструктора калькулятора».
• Критика: нет инерции/чувствительности скролла, на больших экранах играть легче, можно «откатом» обмануть стену огня.
• Баг: одновременная смерть и 100-килл-бонус крашит игру.
• Общий вывод: простая, но свежая идея, показывающая, как LLM-инструменты открывают геймдев даже «не-программистам».

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

• Реклама в интернете — зло: тратит время и уродует сайты.
• Поддержи автора напрямую: 1 $ приносит больше пользы, чем тысячи показов баннеров.
• На сайте выводится тонкое сообщение: «Adblock не обнаружен. Поставь uBlock Origin — сэкономишь трафик и нервы».
• Блок скрывается кнопкой «Закрыть» и больше не появляется (cookie notice-shown).
• Техника:
  – в HTML встроен <div> с «адоподобными» классами и скрипт nativeads.js;
  – если div вырезан или скрипт заблокирован, сообщение не видно;
  – стили показывают блок только при ≥75 em ширины и ≥30 em высоты;
  – без JS сообщение не вставляется, без CSS просто не стилизуется.
• DNS-блокировку не отследить, поэтому банер маленький и некликабелен вне основного контента.

• Без блокировщиков рекламы веб выглядит как «лабиринт трекеров и баннеров»: большинство пользователей живут в этом каждый день.
• uBlock Origin называют едва ли не «лучшим антивирусом»; ФБР и CERN рекомендуют блокировщики как защиту от скама и малвари.
• Даже с адблоком сайты всё чаще «раскрывают» посетителей через identity-graph (IP, хэши устройств) и потом спамят e-mail.
• Часть участников считает блокировку «паразитизмом»: контент бесплатен только потому, что кто-то смотрит рекламу.
• Другие возражают: договор «контент ↔ реклама» давно нарушен — автозвук, трекинг, монополии Google/Meta, потребление трафика и батареи.
• Альтернатива — платить авторам напрямую, но пожертвования от 0,01 % читателей не покрывают хостинг, уж не говоря о зарплате.

FuckUpMySite — преврати любой сайт в хаос.

• Деструкция: 0 %
• Лозунг: fuckfuckfuckfuckupupupupmymymymysitesitesitesite
• Девиз: «Некоторые просто хотят смотреть, как горит веб».

Попробуй на: Sentry.io, Hacker News, Apple, Stack Overflow
Кнопка: «FUCK THIS SITE UP»

😈 Настройки хаоса

(3 из 6 активны)

• 🔥 Пылающий курсор — курсор поджигает страницу
• 🤪 Comic Sans всё — весь текст Comic Sans
• 👻 Фальшивые курсоры — множество поддельных теней
• 🪰 Назойливая муха — жужжит по экрану
• 🏃 Убегающие кнопки — прячутся от мыши
• 🔨 Попап-лопатка — ложные окна, которые нужно закрывать

Не все сайты дружат с хаосом. Нашёл баг? Напиши в Twitter.

• Участники обсуждают сайт-шутку, который «ломает» любую страницу: Comic Sans, ползающие жуки, огонь и т.д.
• Браузеры (Chrome, Firefox, Safari) блокируют его как «опасный», что вызывает смех — предупреждение идеально вписывается в дух проекта.
• Некоторые сравнивают его с Katamari Hack, Desktop Destroyer, netdisaster и старыми оверлеями 90-х.
• Работает не везде: падает на Whitehouse.gov, opennet.ru, сайтах с Anubis, а также на самом себе.
• Люди делятся ссылками на «испорченные» версии Fox News, Apple и др.; кто-то просит npm-пакет для розыгрыша.

Проблема: GitHub в Safari работает крайне медленно.
Описание: Страницы грузятся по 5–10 сек, анимации подвисают, прокрутка «рыхлая». В Chrome и Firefox всё нормально.

Версии:

• Safari 17.5 (macOS 14.5)
• Safari 16.6 (macOS 13.6) – та же картина

Что пробовали:

• Очистить кэш и куки
• Отключить все расширения
• Переключить DNS (Cloudflare, Google)
• Сменить сеть (домашний Wi-Fi, мобильный интернет)
• Включить/выключить «Разработка → Использовать WebKit Nightly»

Результат: ничего не помогло.

Симптомы:

• В Activity Monitor процесс «Safari Web Content» грузит CPU до 100 % при открытии любой страницы GitHub.
• В инструментах разработчика видно, что 80 % времени уходит на «Rendering».

Временное решение:

• Переключиться на Chrome/Firefox.

Просьба: Проверьте, не сломали ли вы что-то в CSS/JS для WebKit.

• GitHub стал критически медленным: Safari и Firefox тормозят даже на мощных М-системах, а большие PR (>1000 файлов) почти не открываются.
• Пользователи связывают падение производительности с переходом на React/SPA после покупки Microsoft и отказом от старого SSR.
• Предлагают мигрировать на Forgejo, Codeberg, SourceHut или возвращаться к простому HTML/CSS.
• Вопрошают, как в крупной компании могут пропустить такую регрессию и почему тесты не ловят разницу между Chrome и Safari.
• Ситуация повторяется и на других сайтах (Jira, Stripe, GCP), вызывая разговоры о «блоте» современных веб-приложений.

Суть проблемы
В npm-реестр попали вредоносные версии пакетов Nx и связанных плагинов. Злоумышленники использовали временный доступ к npm-аккаунту @nxscope и опубликовали поддельные версии 19.8.0–19.8.2.

Затронутые пакеты

• nx
• @nx/angular, @nx/cypress, @nx/detox, @nx/devkit, @nx/esbuild, @nx/eslint-plugin, @nx/expo, @nx/express, @nx/jest, @nx/js, @nx/nest, @nx/next, @nx/node, @nx/playwright, @nx/plugin, @nx/react, @nx/rollup, @nx/storybook, @nx/vite, @nx/web, @nx/webpack, @nx/workspace

Что делать

1. Удалить вредоносные версии.
2. Установить официальные 19.8.3 или выше.
3. Проверить lock-файлы и CI на наличие подозрительных версий.

• Уязвимость в пакетах Nx: токен npm скомпрометирован, злоумышленники внедрили вредоносный код через post-install скрипты.
• Малварь ищет Claude Code / Gemini CLI и использует их как «живые» инструменты для поиска криптокошельков, ключей и других секретов.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать Bun (по умолчанию не запускает скрипты), Verdaccio для вендоринга и инструмент vet для сканирования.
• Рекомендуют разрабатывать в изолированных контейнерах/VM (cubbi, bubblewrap, firejail) и пересматривать каждую зависимость вместо «npm install наугад».
• Основной вывод: современные цепочки поставок и AI-агенты создают новый вектор атак «prompt-as-malware», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.

CLI-утилитам не место в ~/Library/Application Support

Популярные библиотеки (Python platformdirs, JS env-paths, Rust dirs, Go adrg/xdg) по умолчанию кладут конфиги в ~/Library/Application Support, но это каталог для GUI-приложений. Пользователи ожидают увидеть настройки CLI-программ в ~/.config, как Git, Vim, Tmux и сотни других. Это ожидание закреплено стандартом XDG и принципом «наименьшего удивления».

Почему это важно

• Неожиданное расположение ломает привычки и усложняет версионирование.
• Даже менеджеры dotfiles (chezmoi, dotbot, yadm, rcm, GNU Stow) игнорируют ~/Library/Application Support, что подтверждает: сообщество считает ~/.config единственным разумным местом для конфигов CLI-утилит на macOS.

• Автор утверждает, что CLI-утилиты macOS должны хранить конфиги в ~/.config по XDG, но участники показывают: ни одна поставляемая с macOS утилита этого не делает.
• Большинство считает XDG спецификацией для Linux/Unix-сред и не видят оснований навязывать её macOS, у которой есть собственные места: ~/Library/Preferences и ~/Library/Application Support.
• Разработчики CLI-инструментов, портированных с Linux, действительно часто используют ~/.config, что вызывает у местных пользователей ощущение «плохого порта».
• Предлагаются компромиссы: использовать XDG-переменные, если они заданы, или делать симлинки между ~/.config и ~/Library/Application Support.
• В Rust-экосистеме крейт dirs-rs игнорирует XDG на macOS; участники обсуждают создание форка, который бы следовал спецификации.

JavaScript отключён.
Включите его или перейдите в поддерживаемый браузер. Список браузеров — в Справке.

Что-то пошло не так.
Попробуйте ещё раз.

⚠️ Расширения, блокирующие трекинг, могут мешать работе сайта. Отключите их и обновите страницу.

• Участники считают, что давать LLM-агенту полный доступ к браузеру — это «смертельный трифекта»: чтение всех вкладок, кук и паролей.
• Основной риск — prompt-injection: любой сайт может внедрить команду, и агент выполнит её, потому что «каждое чтение — это запись в контекст».
• Люди сравнивают это с тем, что Microsoft делала скриншоты, но теперь молчат, когда AI получает plaintext-доступ к банковским данным.
• Единственный «безопасный» сценарий — код в git, где изменения легко откатить; всё остальное (покупки, банкинг, e-mail) считается безумным.
• Итог: без изоляции, sandbox и чёткого разграничения «что можно» агенты становятся идеальным вектором атак, а компании, их выпускающие, — объектом для судебных исков.

В JavaScript "🤦🏼‍♂️".length == 7 — не ошибка, а результат подсчёта UTF-16 кодовых единиц.
Эмодзи состоит из 5 скалярных значений Unicode, но в UTF-16 они занимают 7 code units:

• 🤦 U+1F926 → 2
• 🏼 U+1F3FC → 2
• ZWJ U+200D → 1
• ♂ U+2642 → 1
• VAR-16 U+FE0F → 1

Итого 7 — именно это и возвращает .length.

Другие языки считают по-своему:

• Python 3 → len("🤦🏼‍♂️") == 5 (кодовые точки, но допускает суррогаты).
• Rust → "🤦🏼‍♂️".len() == 17 (байты UTF-8).
• Swift → "🤦🏼‍♂️".count == 1 (расширенный графем-кластер).

Каждый подход отвечает на свой вопрос: «сколько code units / bytes / графем». Ни один не универсален; выбор зависит от задачи.

• Обсуждение вокруг статьи показало, что «длина строки» не имеет единого определения: бывают байты, UTF-16/UTF-32 код-юниты, скалярные значения Unicode и расширенные графем-кластеры.
• Пользователи жалуются, что разные языки и API возвращают разные числа для одного и того же эмодзи, что ломает UI-ограничения, индексы БД и обработку текста.
• Часть участников считает, что нужно явно различать «длину для хранения», «длину для отображения» и «длину для человека»; другие мечтают вернуться к чистому ASCII.
• Примеры кода на Java, Python, Raku и JS показывают, как получить каждый из вариантов длины, но подчеркивают отсутствие общего стандарта.
• Итог: «length» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.

Как двигать объекты в 3D

Кликните вправо, чтобы идти дальше →

---

От круга к сферической спирали

Куб движется по кругу:
x = 10 cos(πt/2)
y = 10 sin(πt/2)

Умножаем радиус на 0.03 t — получаем растущую спираль.

---

Сферическая спираль

Добавляем z:
z = 10 cos(0.02 πt)

Радиус x, y теперь умножается на sin(0.02 πt), поэтому он сначала растёт, потом уменьшается.

x = 10 cos(πt/2) · sin(0.02 πt)
y = 10 sin(πt/2) · sin(0.02 πt)
z = 10 cos(0.02 πt)

Куб облетает сферу по спирали.

---

Итог

Положение в 3D задаётся параметрическими уравнениями x(t), y(t), z(t).
Меняя функции, получаем любые траектории — от простого круга до «хаотичных» путей.

Проект Damar • Twitter @damarberlari

• Пользователи восторгаются плавной анимацией и наглядностью объяснения сферической спирали.
• Некоторые жалуются на тормоза в Firefox/Linux и просят убрать «диззи»-эффект.
• Просят добавить навигацию свайпом/скроллом, кнопки «вперёд-назад» и RSS-ленту.
• Отмечен скачок сложности: от азов к финальной спирали — слишком большой шаг для новичков.
• Появились предложения расширить тему: полярные координаты, матрицы поворота, Fibonacci-спираль на сфере.

SVG <path>: краткий путеводитель

<path> — единственный способ рисовать сложные фигуры и кривые в SVG. Синтаксис пугает, но разобравшись, становится удобным.

Основы

• Атрибут d — последовательность команд, как «рецепт» для пера.
• Каждая команда начинается с буквы и получает координаты как аргументы.
• Предыдущая точка автоматически становится началом следующей команды.
• Используйте пробелы и запятые — читаемость важнее байтов.

Команды

• M x,y — поднять перо и переместиться в точку.
• L x,y — прямая линия до точки.
• C x1 y1, x2 y2, x y — кубическая Безье.
• Q x1 y1, x y — квадратичная Безье.
• A rx ry x-axis-rotation large-arc-flag sweep-flag x y — дуга эллипса.
• Z — замкнуть путь к начальной точке.

Относительные координаты

Буквы в нижнем регистре (m, l, c…) двигают перо относительно текущей позиции, а не от начала координат.

Цепочки кривых

Повторяйте команды, чтобы строить сложные формы без лишних M.

Анимации

Изменяя d через CSS или JS, можно плавно морфить фигуры.

Советы

• Начинайте путь всегда с M.
• Для читаемости группируйте команды построчно.
• Проверяйте результат в интерактивном редакторе.

• Участники обсуждают интуитивные способы задавать эллиптические дуги без булевых флагов, предлагая параметры вроде углов или контрольной точки.
• Хвалят интерактивный гайд по SVG-путям, его наглядность и звуковые эффекты.
• Делятся практическим опытом: динамическая генерация карт в играх, разметка сканов, чтение путей «с нуля».
• Рекомендуют инструменты для редактирования и генерации SVG: GodSVG, Boxy SVG, онлайн-редактор yqnn.
• Отмечают связь SVG с PostScript, Logo и даже коническими сечениями; обсуждают GPU-ускорение для кривых Безье и рендеринг шрифтов.

• CSS

  • min-width: auto (по умолчанию) имеет приоритет над flex-shrink, overflow: hidden, width: 0; задайте min-width: 0.
  • Горизонталь и вертикаль различаются: width: auto растягивается, height: auto по содержимому; margin: 0 auto центрирует по горизонтали, но не по вертикали (в flex-direction: column работает).
  • BFC (display: flow-root) предотвращает схлопывание margin и «обнуление» высоты родителя с float-потомками.
  • Новый stacking context создают transform, filter, opacity, position: fixed/sticky, z-index + absolute/relative и др.; z-index действует только внутри контекста.
  • На мобильных 100vh включает скрытые панели; используйте 100dvh.
  • position: absolute ориентируется на ближайший «positioned» ancestor, а не на родителя.
  • float не работает внутри flex/grid-родителя.
  • Процентные width/height не работают, если размер родителя не задан.
  • display: inline игнорирует width, height, вертикальные margin.
  • Пробелы между inline-block элементами рендерятся; в flex/grid — нет.
  • box-sizing: content-box (по умолчанию) не включает padding/border; включите border-box.
  • Указывайте width/height у <img> для предотвращения CLS.
  • Загрузка файлов не показывается в DevTools; используйте chrome://net-export/.
  • Внутри <script> строка </script> ломает парсинг.

• Unicode

  • Отличайте code point и grapheme cluster (последнее — то, что видит пользователь).

• Маршрутизаторы могут тихо обрывать простаивающие TCP-соединения; настройте TCP-keepalive или HTTP-заголовки.
• Возвращать null из Optional<T> — антипаттерн; Kotlin и аннотации уже решают это.
• UTF-16 в Java/C#/JS — деталь реализации; в Go строки — просто байты.
• min-width: auto работает не везде; CSS-свойства нельзя читать изолированно.
• Регексы, YAML, LF/CRLF, rm -rf $DIR/ — каждый язык/платформа имеет свои подводные камни.

Lazy Brush — библиотека для рисования плавных линий мышью, пальцем или любым другим указателем.
GitHub | npm | Reddit

Параметры:

• Lazy radius (60 px) — минимальное расстояние, при котором кисть тянется к курсору.
• Friction (0.10) — инерция: 0 — без задержки, 1 — бесконечная.
• Brush radius (13 px) — толщина кисти, не влияет на логику.

Автор: dulnan

• Библиотека Perfect Freehand и её демо drawmote от автора TLDRaw признаны лучшей альтернативой для плавных подписей и рисования.
• Техника «ленивого» курсора с гистерезисом/стабилизатором уже применялась в Wii-играх, Krita, ZBrush, Black & White и других графических пакетах.
• Пользователи отмечают, что визуальный «поводок» между курсором и пальцем делает рисование интуитивным, особенно на мобильных устройствах и при работе мышью.
• Некоторые считают задержку слишком большой и предлагают использовать фильтр Калмана или DynaDraw для меньшего лага.
• Проект вызвал восторг («лучшее бесплатное», «шокирующе хорошо»), но кто-то жалуется на пропадающие линии и невозможность «естественных» штрихов.

Чар простой текстовой страницы

Открывая страницу из одного текста, я чувствую облегчение: нет баннеров куки, рекламы, всплывающих подписок и автозапуска видео.
Только чистый, быстрый, читаемый текст.

Такой контент можно скопировать в письмо, отправить в ChatGPT, распечатать или сохранить на Kindle — он везде работает.
Ссылка открывается мгновенно без CDN и предзагрузок.
Хостинг стоит копейки, сайт живёт даже на Raspberry Pi.

Читая, легко переключаться между беглым просмотром и вдумчивым чтением, не чувствуя вины за «потерянное» время.

Спасибо всем, кто публикует текст без лишнего.
Вы жертвуете «вовлечённостью», но дарите интернету простоту и покой.
Мне это безумно нравится.

• Участники мечтают о браузере без JS, где только HTML и выбранная пользователем CSS-тема.
• Хвалят сайты вроде plaintextsports.com и berkshirehathaway.com за минимализм, читаемость и отсутствие трекеров.
• Спорят о шрифтах: кто-то любит моноширинные «под печатную машинку», кто-то просит sans-serif и контрастные цвета.
• Соглашаются, что картинки допустимы, если служат тексту, а главный враг — избыточный JS, баннеры и медленные фреймворки.
• Вспоминают лёгкие новостные «lite»-версии CNN/NPR и альтернативные протоколы вроде Gemini как примеры «текстового» интернета.