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.

Кратко:
С декабря 2026 г. CocoaPods Trunk станет только для чтения — новые версии и pod-ы добавлять нельзя. Существующие сборки продолжат работать, пока живы GitHub и jsDelivr.

Что меняется:

• Подачи новых Podspec будут отклоняться на уровне сервера.
• Репозиторий CocoaPods/Specs пометят как archived.
• Использование prepare_command в новых Podspec запрещено (май 2025).

График:

• май 2025 — блок prepare_command.
• конец 2025 — массовое письмо всем авторам Podspec.
• сен–окт 2026 — повторное уведомление.
• 1–7 ноя 2026 — тестовое отключение.
• 2 дек 2026 — финальный переход на read-only.

Обратная связь:

• Команда: [email protected]
• Orta: [email protected] или Bluesky @orta.io

• CocoaPods официально уходит в историю: мейнтейнеры решили прекратить развитие, признав превосходство Swift Package Manager.
• Пользователи благодарны за годы поддержки, но многие рады избавиться от «захвата» проекта xcworkspace и постоянных проблем с CDN.
• Критика SPM: не хватает команды outdated, баги в Xcode, плохие сообщения об ошибках; до 30 % пакетов ещё не перенесены.
• React Native, Flutter, Unity, Capacitor пока тесно зависят от CocoaPods; переход на SPM только в зачаточном состоянии.
• ~100 k старых pod-ов рискуют остаться без обновлений: придётся форкать и мигрировать вручную или ждать сообщества.

• Токио Tokyo
• Канда Kanda
• Акихабара Akihabara
• Окачимати Okachimachi
• Уэно Ueno
• Угисудани Uguisudani
• Ниппори Nippori
• Ниси-Ниппори Nishi-Nippori
• Табата Tabata
• Комагомэ Komagome
• Сугамо Sugamo
• Оцука Ōtsuka
• Икэбукуро Ikebukuro
• Мэдзиро Mejiro
• Такадабаба Takadanobaba
• Син-Окубо Shin-Ōkubo
• Синдзюку Shinjuku
• Ёёги Yoyogi
• Харадзюку Harajuku
• Сибуя Shibuya
• Эбису Ebisu
• Мэгуро Meguro
• Готанда Gotanda
• Осаки Ōsaki
• Синагава Shinagawa
• Таканава Gateway Takanawa Gateway
• Тамати Tamachi
• Хамамацутё Hamamatsuchō
• Симбаси Shimbashi
• Юракутё Yūrakuchō

Линии: Keihin-T. · N'EX · Saikyō · Sōbu · Ueno-T. · Yamanote
о проекте

• Пользователи делятся воспоминаниями о мелодиях станций Яманотэ: кто-то слушал их специально, кто-то узнал детскую песенку в «Гиндза», а кому-то они вызывают ностальгию.
• Несколько человек показали свои творческие проекты: психоделический коллаж, треки на основе мелодий, флаттер-приложение с объявлениями.
• Узнаём, что JR East постепенно отказывается от уникальных мелодий из-за нехватки персонала и переводит линию на единый звук.
• Появились просьбы добавить другие линии (Тозай, Чуо), сделать рингтоны и даже мод для симулятора.
• Кто-то предлагает проводить конкурсы мелодий в других странах, чтобы повторить японский опыт «маленькой радости».

LLM-разработка: краткий итог

• Мифы: LLM не делают код продакшн-готовым, требуют понимания задачи и хорошо структурированных кодовых баз. Использование LLM снижает навыки чтения документации и глубокого мышления.
• Агенты — это просто цикл «LLM → вызов локального API → ответ → LLM снова». Инструменты: навигация, редактирование, shell, поиск, MCP-серверы.
• Проблемы продуктов
  • Нестабильность: модели и цены меняются еженедельно.
  • Нет детерминизма, приходится постоянно обновлять промпты и MCP.
• Тесты
  • Python, TypeScript, Rust, Flutter, сложные рефакторинги — справляются.
  • Не справились: Token Field во Flutter (редкий компонент, сложное управление состоянием). Claude Opus 4.1 и GPT-5 провалили задачу.

Продукты

• GitHub Copilot

  • Плюсы: быстрое автодополнение, стабильность, низкая цена.
  • Минусы: слабые «агенты», нет контекста всего проекта.

• Claude Code Pro

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

• Gemini CLI / Jules

  • Плюсы: бесплатный CLI, быстрый.
  • Минусы: слабые модели, ограниченные возможности.

• Kiro, Cursor, Windsurf

  • Плюсы: встроенные редакторы, удобные интерфейсы.
  • Минусы: дороже, часто баги, привязка к конкретному редактору.

Когда LLM полезны

• Лучшие языки: Python, TypeScript/JavaScript, Go.
• Лучшие задачи:
  • Репетитивный код, тесты, миграции.
  • Документация, примеры, объяснение legacy.
• Плохо:
  • Редкие фреймворки, сложные UI, архитектурные решения.
  • Надёжность и безопасность.

Вывод
LLM — полезный инструмент для рутины и прототипов, но не заменяет мышление и глубокое понимание.

• Многие спорят с тезисом «использовать LLM в коде тривиально»: на практике нужны месяцы, чтобы понять, что делегировать, как формировать промпты и управлять контекстом.
• Кто-то сравнивает LLM с «однорукими бандитами»: результат часто случаен, а «навыки» сводятся к удаче и базовому гуглению.
• Другие делятся успешным опытом: при жёсткой архитектуре, тестах и узких промптах Claude Code и аналоги дают 9/10 полезных патчей.
• Утверждение, что LLM «заставляют» выбирать мейнстек, опровергают разработчики на Clojure, D и других нишевых языках.
• Общий вывод: LLM — мощный инструмент, но требует экспериментов, критического ревью и понимания своих ограничений; без этого он быстро превращается в источник технического долга.