Hacker News Digest

Социальная сеть для разработчиков под названием /dev/null строится вокруг коммитов вместо постов: вход только через GitHub, а сообщения — это простой текст до 4000 символов. Лента работает без алгоритмов, строго по времени публикации, а профили полностью повторяют данные GitHub и редактируются там же. Первые коммиты проходят ручную модерацию, после чего автоматический модератор проверяет и одобряет их сам.

Тон площадки — шутливый и «свой»: в трендах шутки про Laravel, команды вроде php artisan make:friends и composer require followers, а также жалобы на внезапную нагрузку («нужно масштабировать сервер», «они деплоят прямо с телефона, помогите»). Упоминаются разработчики Нуну Мадуру и Николя Грекас, а число пользователей предлагают оценивать по счётчику подписок одного из участников. Есть и опрос о кроссплатформенной разработке с вариантами React Native, Flutter, SuperNative (NativePHP) и Kotlin Multiplatform. Всё остальное, по ироничному девизу проекта, уходит в /dev/null.

Сообщество разработчиков скептически относится к /dev/null. Обязательный вход через GitHub считается ограничением аудитории и связью с Microsoft, противоречащей идее независимой соцсети. Модерация постов (ручная проверка первых коммитов, затем автоматическая) вызывает опасения по поводу задержек и цензуры. Заявленные новшества воспринимаются как переупаковка существующих решений вроде Mastodon и Solid, без значимых отличий от других соцсетей для разработчиков. Технические проблемы: непонятный выбор домена (dev-null.sh), простои, отсутствие ясности о стеке технологий. Предложения: добавить публичный просмотр ленты и подробную информацию о платформе до регистрации, улучшить онбординг и визуальные метафоры (git‐аналогии, подсказки). Отмечается плюс: открытый исходный код и быстрый отклик сообщества — более 200 pull‐request'ов за 48 часов. Спор о будущем: некоторые видят в /dev/null потенциал для децентрализованного обмена файлами (сравнение с Solid), другие считают его обычным хостингом с альтернативами вроде tilde.town.

Эндрю Шмеляун создал систему, позволяющую незнакомцам отправлять ему сообщения через чековый принтер. Он вдохновился другом, у которого на сайте была похожая функция, но хотел сделать её более физической. Эндрю использовал старый термопринтер Epson TM-T88IV, купленный на eBay за $50, который работает за счёт нагрева специальной бумаги, покрытой термочувствительным веществом. Поскольку принтер не распознаётся его Mac Mini, он подключил его к Raspberry Pi 4.

Для реализации проекта Эндрю выбрал PHP с фреймворком Laravel, создав сайт с простой формой без JavaScript. Система сохраняет сообщения в базу данных на случай, если принтер выйдет из строя или закончится бумага. Принтер имеет ограниченный набор символов (только стандартный алфавит, цифры и базовые знаки клавиатуры), поэтому сообщения проходят валидацию на предмет специальных символов. Ширина текстового поля соответствует ширине печати (42 символа).

• Пользователи делятся опытом с дешёвыми китайскими термопринтерами, драйверы и библиотеки для них, а также вспоминают проект Little Printer и другие попытки сделать «интернет-подключённые» термопринтеры.
• Обсуждаются вопросы безопасности при работе с термобумагой, влияние BPA и аналогичных пластификаторов, а также трудности с поставками безопасной бумаги.
• Участники делятся личным опытом: кто-то использует принтер как «интернет-факс», кто-то печатает стикеры из чека, кто-то пытается повторить Little Printer.
• Поднимается вопрос о том, что такие проекты могут быть использованы для печати зинов и других офлайн-контента.
• Также обсуждается, что при должном подходе можно было бы сделать такие проекты более доступными и устойчивыми к спаму и злоупотреблениям.

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал Phoenix LiveView. Вместо того чтобы разделять фронтенд и бэкенд на разные стеки, он нашёл решение, которое позволяет писать всё на одном языке — Elixir. Это не только ускоряет разработку, но и даёт серьёзные преимущества в производительности.

Ключевые моменты:

• Меньше кода, меньше ошибок: Вместо двух кодовых баз (например, JavaScript + PHP) всё пишется на Elixir, включая UI-логику, что снижает вероятность ошибок.
• Реальное время без усилий: LiveView использует WebSockets для двухсторонней связи в реальном времени, что встроено "из коробки" и не требует дополнительных библиотек.
• Производительность и надёжность: Бэкенд на Elixir (работающем на Erlang VM) обеспечивает высокую конкурентность и отказоустойчивость. Фоновые задачи через Oban перезапускаются автоматически при сбоях.
• Единая архитектура: Нет необходимости в отдельном API или SPA, что упрощает разработку и развертывание.

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

• Обсуждение в основном вращается вокруг сравнения Rails, Phoenix и LiveView, но при этом всплывают факты, что Rails всё ещё умеет WebSocket, а Phoenix не так уж идеален, если нужен только CRUD-приложение.
• Участники спора подчеркивают, что выбор стека часто диктуется личными предпочтениями и опытом, а не объективными преимуществами.
• Несколько раз поднимается тема, что современные фреймворки всё ещё не решают проблему масштабирования и фоновых задач, и что важнее выбрать тот стек, который действительно подходит под задачу.
• Также обсуждается, что выбор инструмента влияет на набор библиотек и сообщество вокруг него, и это может быть важнее, чем абстрактные преимущества языка.