Hacker News Digest

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

Ключевой навык для дизайнеров — вкус и кураторство: умение ставить правильные задачи ИИ, отличать качественную работу от шаблонной и дорабатывать результат до осознанного, а не автоматического вида. ИИ усиливает всё: если у вас есть глубокое понимание пользователей, он поможет исследовать больше решений; если нет — просто быстрее создаст неправильный продукт. Будущее за теми, кто сочетает человеческое понимание с возможностями ИИ, а не пытается полностью заменить мышление алгоритмами.

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

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

Ключевые ошибки работодателей — устаревшие представления о длительном онбординге и интервью, сфокусированные на алгоритмах, а не на реальных навыках. Джуниоры, свободные от шаблонов, часто превосходят сеньоров в гибкости и скорости обучения. Чтобы найти лучших, стоит искать кандидатов вне традиционных каналов, например, среди тех, кто не прошёл в Y Combinator, но проявил инициативу.

• Сложности найма джунов из-за заучивания LeetCode и использования ИИ в учебе, снижения страсти к профессии.
• Риски найма слабых джунов и необходимость эффективных фильтров для выявления талантов.
• Переизбыток выпускников CS на фоне сокращения числа вакансий для новичков.
• Важность реального опыта для джунов и конкуренции с ИИ.
• Разные подходы к оценке джунов: сложные задачи vs. простые, проверка мышления и сотрудничества.

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

Ключевая проблема — запутанное управление экосистемой Ruby, разделённое между разными группами: разработчиками языка Ruby, инструментами RubyGems/Bundler и хостингом RubyGems.org. Исторически эти части развивались отдельно, а recentние слияния (например, поглощение Ruby Together Ruby Central в 2022 году) усугубили неразбериху в правах доступа и ответственности, что теперь вылилось в публичный кризис доверия.

• Обсуждение касается конфликта вокруг RubyGems и Ruby Central, где ключевой фигурой является André Arko, чье поведение и профессиональные действия ставятся под сомнение.
• Участники отмечают предвзятость и неоднозначность представленных точек зрения, включая мнение Джастина Сёрлса, который, хотя и считается авторитетом, может быть необъективен из-за связей с Shopify.
• Поднимается вопрос финансирования open-source: должна ли работа оплачиваться пропорционально вкладу, и как действия спонсоров (как в случае с Shopify) влияют на проекты.
• Обсуждаются юридические и этические аспекты, включая обвинения в плагиате кода и потенциальные судебные разбирательства, что заставляет многих участников избегать публичных комментариев.
• В целом, дискуссия сводится к необходимости прозрачности и добросовестности со всех сторон для разрешения конфликта и обеспечения устойчивости open-source проектов.

Автор, известный как «парень из Bundler», рассказывает о 15-летней истории проекта, который он помогал развивать с 2010 года. Изначально созданный Yehuda и Carl, Bundler быстро стал стандартом управления зависимостями в Ruby, сохранив свою структуру до версии 2.7.2. После ухода основателей автор взял на себя ведущую роль в поддержке, сотрудничая с Terence Lee и позже основав Ruby Together для финансирования разработки.

Сейчас Ruby Central заявляет права на владение названием Bundler, что противоречит духу сообщества. В ответ автор зарегистрировал товарный знак, чтобы защитить репутацию проекта и его maintainers, подчеркивая, что код остаётся под MIT-лицензией, а название принадлежит сообществу. Ключевая цель — обеспечить, чтобы решения по проекту принимались самими пользователями и разработчиками, а не одной организацией.

• Финансирование Ruby Central от спонсоров вроде Shopify было условием захвата контроля над Bundler и RubyGems, что привело к корпоративному захвату инфраструктуры.
• В ответ на это был зарегистрирован товарный знак Bundler, чтобы предотвратить захват и передать его под управление нового, действительно сообщественного органа.
• Ключевой риск — потеря давних мейнтейнеров, раскол сообщества и форк ключевой инфраструктуры, что создаст хаос.
• Сообщество ожидает ответа от Ruby Central, включая возобновление запланированного Zoom-звонка, но пока ситуация в подвешенном состоянии.
• Под вопросом юридическая сила товарного знака, так как его долгое отсутствие enforcement может означать отказ от прав или генерализацию.

Ruby Central применила подход «deus ex machina», в одностороннем порядке взяв под контроль всю GitHub-организацию RubyGems — ресурс, исторически принадлежавший мейнтейнерам. Они оправдывали это необходимостью нейтрализовать «опасных операторов», но использовали ситуацию для удаления ключевых участников из проектов, включая RubyGems, Bundler и RubyGems.org, и присвоения прав собственности. Shopify, главный спонсор Ruby Central, оказался вовлечён в этот процесс, что вызвало вопросы о согласованности действий с интересами сообщества.

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

• Ruby Central отменила запланированную встречу с сообществом, что вызвало недовольство.
• Shopify, используя финансовое давление на испытывающий нехватку средств Ruby Central, добилась контроля над ключевыми репозиториями (Bundler, RubyGems).
• Члены сообщества обвиняют Ruby Central в непрозрачном процессе принятия решений и отсутствии коммуникации.
• Противоречие также связано с реакцией на доклад о новом инструменте rv и последующей потерей спонсорства.
• Обсуждаются проблемы централизации управления в open-source и утраты первоначальных ценностей сообщества.

Ruby Central, испытывающая финансовые трудности после потери спонсорства Sidekiq ($250 тыс. в год), по требованию Shopify взяла под контроль ключевые проекты Ruby-сообщества — Bundler и RubyGems — без согласия их многолетних сопровождающих. Shopify пригрозила отозвать финансирование, если Ruby Central не обеспечит полный контроль над репозиториями и правами на gems, что привело к принудительному изменению прав доступа и исключению ведущих разработчиков, включая Андре Арко с 10-летним стажем.

Этот захват был преднамеренным: Shopify заранее организовала дежурство для замены прежних сопровождающих, а совет Ruby Central проигнорировал предупреждения о незаконности действий и альтернативы в виде форков. Инцидент подчеркивает риски зависимости open-source от корпоративного финансирования, где сообщество теряет автономию под давлением спонсоров.

• Sidekiq прекратил спонсорскую поддержку Ruby Central на $250 тыс. в год из-за участия DHH в RailsConf 2025, что вызвало споры о его политических взглядах.
• Shopify и Ruby Central взяли под контроль инфраструктуру RubyGems и Bundler, удалив ключевых мейнтейнеров, официально — для усиления безопасности supply chain.
• Сообщество раскололось: часть видит в действиях Shopify корпоративный захват, другие — необходимые меры после недавних атак на npm.
• Критики обвиняют Ruby Central в злоупотреблении властью и плохой коммуникации, особенно после передачи прав на репозитории без консенсуса.
• Наблюдатели отмечают, что конфликт усугубляется давними культурными разногласиями в сообществе Ruby, выходящими за рамки технических вопросов.

• Кит Питт — австралийский разработчик, отец троих детей, бывший фокусник. Считает себя не предпринимателем, а изобретателем: «ценность идеи = кто-то заплатил за неё».

• Buildkite родился как побочный проект: Кит писал e-mail-API и понадобился собственный CI. Вечерами довёл прототип до продукта, подключил PIN Payments (первый в AU простой REST-эквайринг) и выложил на $5/30/100.

• Первый «чужой» клиент из Европы (Moneybird) показал: продукт внешне нужен. Когда знакомая компания сама докинулась до $500/мес, Кит поверил, что выживет.

• Первые годы — вечера и выходные, пока жена училась; днём — работа в Envato. Рост шёл медленно, но MRR удваивался каждые 6 мес.

• 2016 — деньги кончились, зарплаты не хватало. Кит вернулся к инвесторам, поднял раунд и стал CEO полный ставка. Пришлось учиться управлять, нанимать и строить распределенную команду.

• Голос продукта выработали через публичный блог: честные посты о проблемах и фичах привели трафик и доверие разработчиков.

• Сегодня Buildkite — глобальный CI/CD с клиентами вроде Shopify и Slack; офисы в Мельбурне и SF. Кит ушёл с поста CEO, но остался техническим лидером и продолжает «изобретать».

• Buildkite хвалят за гибридную архитектуру (SaaS + свои агенты), декларативные пайплайны и приятный UI.
• Малые компании уходят: цены взлетели, фокус сместился на крупные enterprise.
• Меньшие стартапы успешно использовали Buildkite + дешёвые серверы (Hetzner) и Knapsack Pro для параллельных тестов.
• Основатель признался, что привлёк $28 млн раунда, «чтобы купить дом» — вызвал улыбку.
• Некоторые разработчики считают ИИ-ассистентов вредными для глубокого понимания задачи: «поверхностный флирт» вместо погружения.

Tempo — блокчейн первого уровня, созданный для платежей. Поддерживает все основные стейблкоины, обеспечивает 100 000+ TPS, финальность <1 сек, предсказуемые минимальные комиссии и встроенную приватность. Разработан Stripe и Paradigm при участии Visa, Deutsche Bank, Shopify, Revolut и др.

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

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

Для разработчиков

EVM-совместимый, нейтральный к стейблкоинам, нативный обмен между ними, документация скоро.

Доступ

Сейчас приоритетный доступ к тестнету для партнёров.
[partners@tempo.xyz](mailto:partners@tempo.xyz?subject=Requesting access to Tempo)

• Stripe запускает «блокчейн» Tempo под стейблкоины, чтобы ускорить и удешевить движение денег между своими клиентами.
• Критики считают проект маркетинговым трюком: вместо децентрализованной сети — закрытая база данных под контролем Stripe и партнёров.
• Главная выгода — регуляторный арбитраж: стейблкоины пока обходят банковские нормы, позволяя хранить и переводить доллары без классических банков.
• Технически ничего нового: высокая пропускная способность достигается за счёт централизованного набора валидаторов; Ethereum-совместимость нужна лишь для совместимости с инфраструктурой.
• Бизнес-кейсы — мгновенные выплаты, ликвидность между странами и спасение от медленной банковской инфраструктуры в ЛатАмерике и Азии.

• HTML: справка по элементам, глобальным атрибутам, форматам дат/времени, руководства по адаптивным изображениям, видео и аудио.
• CSS: справка по свойствам, селекторам, @-правилам, единицам измерения; гайды по блочной модели, анимациям, Flexbox, цветам; «поваренная книга» для колонок, центрирования, карточек.
• JavaScript: справка по встроенным объектам, операторам, функциям; гайды по управлению потоком, циклам, объектам, классам.
• Web APIs: File System, Fetch, Geolocation, DOM, Push, Service Worker; гайды по Web Animations, Fetch, History, Speech API, Web Workers.
• Другие технологии: Accessibility, HTTP, URI, WebAssembly, WebDriver, WebExtensions.
• Обучение: курс «Frontend-разработчик», основы HTML, CSS, JavaScript.
• Инструменты: Playground, HTTP Observatory, генераторы теней, радиусов, границ, палитра цветов.

• Участники обсуждают, как использовать тег <template> без фреймворков: он удобен для клонирования больших фрагментов, ускоряет рендер и снижает нагрузку по сравнению с React/Vue.
• Недостаток — приходится вручную связывать данные и DOM; многие хотят единого формата «HTML+CSS+JS» для компонентов.
• Shopify, Salesforce, MedusaJS и Alpine.js уже применяют <template> в продакшене, но спецификация HTML Modules пока не завершена.

Почему в 2025 году мы всё ещё пишем на Ruby

Стартуя с Lago, мы выбрали Ruby on Rails — у команды был десятилетний опыт, и это был самый быстрый путь к рабочему API. Сегодня система обрабатывает миллионы вызовов в день, пережила множество обновлений Ruby/Rails, и, если бы начинали заново, выбор остался бы тем же.

Скорость как главное преимущество
Rails больше не «тренд» для стартапов, но его используют Shopify, GitHub, GitLab — зрелые компании, которым важна надёжность и скорость разработки. Мы взяли Rails в API-only режиме: без лишнего middleware и рендеринга, но с миграциями, валидациями, Active Record и фоновыми задачами. Это позволило тратить время на продукт, а не на костыли.

Масштабируемость
Rails не масштабируется? Это проблема архитектуры, а не фреймворка.

• Rails 8 упрощает деплой без PaaS.
• Redis + Sidekiq проверен временем.
• Ruby Fibers добавляют асинхронность.
• Puma, автомасштабирование и кеширование справляются с нагрузкой.

Недостатки, с которыми живём

• Производительность и память: ошибки дорого обходятся.
• GIL CRuby: один поток Ruby-кода за раз, поэтому тяжёлые задачи уходят в Go/Rust.
• «Магия» Rails: избегаем лишних гемов и пишем максимально явный код.

Все языки компромиссы; мы выбрали Rails, потому что знаем его настолько хорошо, что умеем обходить ограничения и получать максимум скорости разработки.

• Участники жалуются на рутину вокруг JS/TS-стека: тройное дублирование типов, самописная интеграция auth и прочие «reinventing wheels».
• Многие называют Rails «скучным, но рабочим» инструментом, который до сих пор быстро даёт полный вертикал функционала без бойлерплейта.
• Популярность Rails страдает из-за ассоциаций с «устаревшей» эпохой 10-летней давности и отсутствия хайпа, хотя кодовая база активно развивается (YJIT, ZJIT).
• На практике Rails используется для бизнес-логики и API, а Go/Rust — для I/O- или CPU-ёмких задач; Shopify и GitHub живут по такой же схеме.
• Некоторые мечтают о «Rails на другом языке» (Clojure, Gleam) или ждут, что AI сделает быстрые языки такими же удобными, как Ruby.

• Airbnb: бесшовное обновление Istio на десятках кластеров K8s, тысячи подов.
• Cloudflare + OpenAI: новые открытые модели GPT теперь в Workers AI.
• OpenAI: оценка худших рисков «открытых» LLM.
• Shopify: MCP UI — интерактивные компоненты для AI-агентов в e-commerce.
• Cloudflare: Perplexity обходит robots.txt скрытыми краулерами.
• Meta: интерфейс «человек-компьютер» на основе электромиографии запястья.
• Google: обновлённая программа разработчиков с гибкой подпиской.

• Пользователи одобрили идею «поисковика» по инженерным блогам, но попросили расширить список за пределы 15-16 крупных компаний и включить мелкие, но ценные ресурсы.
• Просят добавить RSS-фид, фильтры по темам/источникам и возможность исключать AI/LLM-контент.
• Отмечены проблемы со скоростью, Cloudflare-captcha и отсутствием тегов C#/ASP.NET.
• Некоторые делятся альтернативами: daily.dev, minifeed.net, GitHub-список kilimchoi, Kagi Lenses.
• Обсуждается, стоит ли ограничиться 10–20 тщательно отобранными блогами или открыть индекс для сотен источников.