Hacker News Digest

Один 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 способен обеспечить погружающий опыт без тяжёлых движков.

98.css — это CSS-библиотека, которая воссоздаёт визуальный стиль интерфейсов Windows 98 с точностью до деталей: выпуклые кнопки, вдавленные поля, пунктирные фокусные обводки и «выцветшие» отключённые элементы. Библиотека не содержит JavaScript — только семантический HTML и CSS, что делает её совместимой с любыми фронтенд-фреймворками. Каждый элемент, от кнопок до чекбоксов, требует корректной разметки: метки обязательны, а доступность — приоритет. Кнопки по умолчанию 75×23 пикселей, при нажатии становятся вдавленными, а фокус отмечен тонкой пунктирной линией внутри.

Поддерживаются все стандартные формы: чекбоксы с обязательными <label>, группы через класс field-row, а также стили для статусных полей и рабочих зон — status-field-border, field-border-disabled. Можно легко кастомизировать отступы и цвета, сохраняя аутентичный вид. Установка через npm или CDN: достаточно одной строки <link> для старта. Проект открыт для вкладов, MIT-лицензирован и создан как тёплый, ироничный tribute к устаревшему дизайну — с акцентом на доступность и простоту.

Пользователи обсуждают дизайн интерфейсов, сравнивая стиль Windows 98 с современными подходами, такими как flat design и избыточное белое пространство. Согласны: интерфейс должен быть интуитивным и удобным — многие считают, что современные тренды этого не обеспечивают. Спорят о плюсах и минусах выпуклых кнопок, пунктирных фокусных обводок и серых (grayed out) кнопок: последние признаны полезными в определённых случаях. Советуют сочетать современные решения с классическими элементами, адаптируя дизайн под потребности пользователя.

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.

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

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

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

EPUB‑формат, как открытый стандарт, позволяет создавать электронные книги, которые корректно отображаются в большинстве приложений и устройств. Тем не менее Kobo официально отказывается принимать такие файлы в своей экосистеме и указывает на проблемы совместимости, связывая их с работой Adobe. По их версии, ошибки появляются из‑за того, как Adobe обрабатывает метаданные, реализует DRM и генерирует файлы EPUB3, а не из‑за недостатков самого стандарта. Кроме того, Kobo требует строгий XML‑манифест и определённые метаданные, которые часто нарушаются в результате автоматической конвертации Adobe.

Кроме того, аналитика показывает, что около 70 % всех жалоб о несовместимости напрямую связаны с обработкой DRM‑защищённых EPUB‑книг в Adobe Reader, тогда как открытые книги без защиты открываются без проблем на Kobo и других платформах. Компания подчёркивает, что её собственный формат основан на EPUB, но содержит дополнительные ограничения, которые облегчают контроль над контентом. Поэтому рекомендация – конвертировать книги в поддерживаемый формат или использовать альтернативные читалки, а также, при необходимости, удалять DRM‑защиту, чтобы восстановить полноценную работу EPUB‑файлов. Таким образом, проблема остаётся в реализации Adobe, а не в самом стандарте.

• Adobe RMSDK устарел, часто «падает» и не поддерживает современные CSS‑стандарты, что приводит к проблемам с валидацией EPUB.
• Kobo использует собственный движок (Kepub) для файлов с расширением .kepub.epub, но обычные .epub проходят через старый Adobe‑движок, вызывая ошибки отображения.
• Альтернативные читатели, такие как Koreader и Calibre‑конвертер, обеспечивают лучшую совместимость и поддержку современных CSS‑возможностей.
• При публикации нужно ориентироваться на «наименьший общий знаменатель» – простые стили и минимум CSS, чтобы избежать проблем с разными e‑reader‑платформами.

Penpot — открытая платформа для совместной работы над дизайном и кодом, альтернатива Figma и Sketch. Полностью веб-ориентированный инструмент на базе SVG позволяет дизайнерам и разработчикам работать в реальном времени без потери данных: прототипы генерируют точный CSS, Flexbox и Grid-код. Поддерживает импорт из Figma, Sketch, Adobe XD; self-hosted или облачная версия.

Ключевые фичи: векторный редактор с авто-layout, компоненты, состояния, инспектор кода для экспорта SVG/SVG sprites/PDF. Более 45 тыс. звёзд на GitHub, 10 тыс. форков; сообщество >100 контрибьюторов. Бесплатен для личного/коммерческого использования (EPL/MPL 2.0), фокус на доступности и privacy — без vendor lock-in.

• Смешанные отзывы о Penpot: хвалят open-source, self-hosting, низкие цены hosted-версии (дешевле Figma) и векторное редактирование.
• Основные жалобы: лаги, краши, высокое потребление памяти на больших проектах, канвасах и при навигации между страницами.
• Ожидание улучшений от нового rendering engine (open beta скоро); есть неофициальные desktop-версии и Docker-поддержка.
• Сравнение с Figma: уступает в стабильности, но привлекает свободой от proprietary облака и vendor lock-in.

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 мс на обновление кадра, что приводит к просадкам фпс.
• Автор ответил, что в будущих версиях планируется добавить реки и водопады, а также улучшить производительность.

Минимальный CSS для приятного сайта включает базовые стили, улучшающие типографику и читаемость. Начните с ограничения ширины медиа-контента: img, svg, video { max-width: 100%; display: block; } предотвращает переполнение. Для типографики используйте system-ui как безопасный шрифт, увеличьте размер до 1.25rem и установите line-height в 1.5 для лучшей читаемости.

Добавьте поддержку тёмной темы через html { color-scheme: light dark; }, но учтите, что пользователям может потребоваться ручное переключение. Ограничьте ширину основного контента с помощью main { max-width: min(70ch, 100% - 4rem); margin-inline: auto; } для оптимальной длины строки в 45–90 символов. Этот подход избегает избыточного кода и обеспечивает адаптивность.

• Обсуждаются минималистичные подходы к CSS, включая сброс стилей, базовые настройки для типографики и ограничения ширины контента для улучшения читаемости.
• Поднимается вопрос о реализации темной темы, важности ручного переключения пользователем и проблемах с "миганием" при загрузке.
• Критикуются стандартные системные шрифты и обсуждаются потенциальные проблемы с их отображением в разных ОС и локалях.
• Упоминаются различные инструменты и философии (например, SSG, Tailwind, Every-Layout) для создания простых и эффективных сайтов.
• Высказывается мнение, что пользователь должен иметь максимальный контроль над стилизацией контента, а не сайт.

У Apple есть приватное CSS-свойство для добавления эффектов Liquid Glass на веб-страницах. Оно называется -apple-visual-effect и позволяет использовать материалы вроде -apple-system-glass-material.

Однако это свойство не работает в обычном Safari — только внутри приложений через WKWebView с включённой приватной настройкой useSystemAppearance. Использование этой настройки приведёт к отклонению приложения в App Store.

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

• Участники обсуждают новую приватную CSS-функцию Apple (Liquid Glass), доступную только для системных приложений, что некоторые считают антиконкурентной практикой.
• Высказывается предположение, что сама Apple активно использует вебвью (WebViews) в своих приложениях (например, App Store, Настройки, Музыка), но делает это настолько незаметно, что пользователи их не распознают.
• Многие отмечают, что плохая репутация вебвью связана как раз с теми случаями, когда они реализованы плохо, в то время как хорошо интегрированные остаются незамеченными.
• Эстетическая ценность и utility-эффекта Liquid Glass оцениваются участниками неоднозначно: одни видят в нём возвращение личности системе, другие считают его бесполезным и уже устаревшим.
• Часть комментаторов сомневается, что данная функция даёт Apple реальное конкурентное преимущество, и считает обвинения в антиконкурентном поведении безосновательными или преувеличенными.

• Реклама в интернете — зло: тратит время и уродует сайты.
• Поддержи автора напрямую: 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 % читателей не покрывают хостинг, уж не говоря о зарплате.

Анимации не всегда нужны

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

• Объясняет (как на linear.app/ai) — ок.
• Подтверждает действие (кнопка слегка уменьшается) — ок.
• Просто «красиво» — допустимо, если пользователь видит это редко.

Частота использования
Если элемент открывают сотни раз в день (Raycast, список команд), анимации быть не должно — они только тормозят.
Клавиатурные переходы никогда не анимируются.

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

Итог
Добавляй анимацию, если она:

1. решает задачу,
2. видна редко,
3. длится < 300 мс.
   Иначе — не добавляй.

• Большинство участников сходятся: анимация должна быть почти невидимой (<150 мс) или вовсе отключаться, иначе она превращается в тормоз.
• Главный критерий целесообразности — объясняет ли анимация изменение состояния; если пользователь ждёт её окончания, чтобы продолжить, значит, она лишняя.
• «Делайт» и «восторг» нужны в основном самим дизайнерам; обычные пользователи после третьего раза хотят выключить всё, что мешает работать.
• Частые повторяющиеся действия (разблокировка, чекаут, корпоративные формы) требуют минимума анимации; для единичных экранов-онбордингов допустима более заметная, но быстрая подсказка.
• Практически каждый советует добавлять системную настройку «отключить анимацию» и уважать prefers-reduced-motion.

Проблема: 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), вызывая разговоры о «блоте» современных веб-приложений.

Репозиторий Evidlo/xsl-website
Публичный пример генерации сайта средствами XSLT: XML-документ преобразуется в полноценную HTML-страницу без серверной логики.

Ключевые файлы

• index.xml – исходные данные
• index.xsl – таблица стилей
• README.md – краткое руководство

Запуск

1. Откройте index.xml в браузере или
2. Примените XSLT-процессор: xsltproc index.xsl index.xml > index.html

Репозиторий демонстрирует, как обойтись без движков шаблонов, используя лишь стандартные XML-технологии.

• Обсуждение началось с демонстрации, как SGML/XML-entity можно использовать для «без-JS» сборки страниц, но напомнили, что браузеры никогда не реализовали полноценный SGML-парсер.
• Участники сравнили XSLT и CSS: CSS может вставлять контент, но лишь декоративно, тогда как XSLT позволяет полноценные преобразования, однако Google просит удалить XSLT из стандарта и уже прячет его за флагом в Chrome.
• Всплыли воспоминания о 2000-х, когда XML/XSLT активно применялись для документации, e-learning и CMS (Symphony), но сложность и отсутствие поддержки со стороны браузеров постепенно вытеснили технологию.
• Предложили альтернативы: серверная трансформация (PHP, CI/CD) или полный отказ в пользу современных сборщиков и SSR-фреймворков.

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/ — каждый язык/платформа имеет свои подводные камни.

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

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

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

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

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

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

Горизонт в 41,60054° N, 93,60911° W

• Высота: ~300 м над уровнем моря
• Рельеф: пологие холмы, сельхозугодья, редкие деревья
• Видимость: 20–25 км, ограничена деревьями и постройками
• Точки рельефа:
  • Север: 1,5 км до реки Des Moines
  • Юго-запад: 2 км до лесополосы
• Освещение: ровное, без резких теней из-за низкого рельефа
• Цвета: зелёные поля, тёмно-серая дорога, голубое небо

• Проект показывает реальный цвет неба прямо сейчас, используя расчёты по научной статье и данные местоположения Cloudflare.
• Пользователи в восторге: «совпадает 100 %», «в точку», «прекрасный минимализм», но ночью/при облаках видно просто чёрный или тёмный фон.
• Автор Suncalc рад, что его библиотека пригодилась; другие предлагают добавить погоду, сделать обои для iOS/десктопа или встроить в smart-дэш.
• Кто-то путается, ждёт загрузки, пока не понимает, что ночь; кто-то ставит телефон к окну и зовёт жену «посмотри!».
• В коде нет JS/CSS, только цвет фона, генерируемый сервером — это вызывает удивление и восхищение.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

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

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

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.