Редактор нового поколения для Action Text

В 37signals готовится важное обновление Action Text. Никаких Trix, House, Tiptap или ProseMirror. Это полноценная замена редактора, которая поднимет работу с rich text в Rails на принципиально новый уровень. Всё, что мы хотели от редактора последние годы — теперь станет реальностью.

Редактор уже используется внутри нового продукта, тестируется и полируется. Совсем скоро — релиз.

Главное:
– Полностью совместим с текущим backend и canonical markup Action Text.
– Современный WYSIWYG с поддержкой Markdown.
– Полностью клиентская реализация, легко переносимая.
– Улучшенный HTML-вывод при сохранении.

Это не просто шаг вперёд — это новая платформа для текста в Rails. Без ограничений Trix, без компромиссов. Фундамент, на котором можно строить редактор уровня Basecamp и выше.

Logman — упрощённая отладка логов Rails

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

Создано как решение реальной проблемы, с которой сталкиваются разработчики при работе с Rails-приложениями.

Открыт ранний доступ.

Как украсть лучшие практики в Rails и как избавить Rails от ruby-based фронтенда (Часть 1)

Много лет назад, на заре становления frontend сборщиков, автор Ruby on Rails (DHH) сделал ruby сборщик Sprockets. И в целом он решал свою задачу какое-то время.

Однако мир не стоял на месте и во фронтенде возникло множество инструментов и подходов. При этом Rails прилип к своим методам, а DHH все еще пытается скрестить бульдога с носорогом и выпускает очередной Sprockets под вывеской Propshaft.

С моей точки зрения все это выглядит довольно сомнительно.

Любой современный сборщик полностью заменяет Sprockets/Propshaft и становится единственным инструментом для поддержки проекта, исключая зоопарк Rails-like решений, которые разваливаются каждые 2-3 года и заменяются на что-то еще следуя предпочтениям DHH.

Как это сделать? Можем ли мы это организовать?

Конечно. Причем сделать это не так сложно, если вы имеете некоторый кругозор.

Попробуем разобраться.

Образ будущего программиста

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

Как писал пять лет назад в первом посте, никакие "джуны" никогда не были нужны и тем более не будут нужны сейчас. Примерно в то же время иронизировал над неоправданным завышением "требуемой базы" для программирования и следом же аргументировал, что один из главных навыков программиста как раз уметь НЕ погружаться слишком глубоко в омуты технического и теоретического содержания.

К сожалению (для программистов) здесь произошли важные изменения.

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

Конкретно, выглядит так будто и дальше в тренде будут области, связанные с искусственным интеллектом (машинным обучением) и формальными методами (автоматизированным доказательством теорем и верификацией алгоритмов). И всевозможные их скрещивания: применение LLM для доказательства теорем, применение теорем для доказательства (корректности работы) LLM, и пр., и пр.

Соответственно для преодоления "стеклянного потолка" программисту всё же потребуется "математическая база".

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

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

К требуемым рабочим навыкам добавится специфическая способность "сынженерить по статье". Т.е. воспроизвести результаты опубликованного исследования: связать в единую концепцию формулы, описания алгоритмов, иллюстрации и общие соображения — и скомпоновать всё в как-то работающий код.

Конечно, в первую очередь для того чтобы научиться это делать необходимо преодолеть посттравматическое расстройство от вида формул, которое, как известно, у многих имеет место со школьной скамьи. Требуйте лечения у своих психологов! :)

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

Ранее обсуждали смежные темы:

— Почему НЕ надо становиться программистом (16.07.2020)
— База для программирования (14.09.2020)
— Суть программирования — создание языков (4.03.2023)
— Kevin Buzzard — евангелист языка Lean (27.09.2024)

На #RailsWorld Joe Masilotti будет вживую собирать iOS- и Android-приложения с помощью Hotwire Native — без Swift и Kotlin. Только HTML, CSS и Rails-бэкенд. Один код — три платформы, минимум усилий.

Звучит круто. Правда в России про это вряд ли кто-то услышит.

Hotwire Native — мощный инструмент: можно строить гибридные мобильные приложения с нативными элементами и WebView прямо из Rails-кода.

Но кто о нём знает в Сбере или Самокате? Как и про PWA из коробки в Rails 8 — классная штука, которая просто пройдет мимо.

У нас Rails — это скорее "то, что было в 2010-х", чем современный фреймворк, который реально развивается. Пока в мире на нём делают мобильные приложения, мы продолжаем его игнорировать.

Задолбался с бардаком в инфраструктуре и вспомогательных сервисах, и запилил тулзу чтобы разобраться с вопросом системно, а не просто добавить закладок в браузер: https://habr.com/ru/articles/917034/

Whop: "Rails держит $1B+ GMV, 150k RPM и фуллфичный маркетплейс на 15 инженерах"

Реалтайм чат, нотификации, платежи, лайвстримы — всё в одном монолите на Rails.

150k запросов в минуту. $1 млрд оборота. Команда — 15 человек.

Джек Шарки, CTO и сооснователь, расскажет на #RailsWorld, как им это удалось — и что нужно, чтобы Rails выигрывал у Next.js в 2025:

rubyonrails.org/world/2025/day-1/jack-sharkey

Привет. Делимся записью июльского митапа SF Ruby, который мы провели вместе с Figma.

Послушали про то, как инженеры в Figma возводят Ruby-монолит, взяли на заметку, как без боли дебажить ошибки в ERB-шаблонах и узнали о борьбе с ненужными аллокациями в Ruby. А ещё посмотрели, как (зачем-то) пишут валидный Ruby-код на хинди, испанском и даже с помощью emoji 😈

https://youtu.be/b8lhXJUo_cI?si=QgATmI2bh_bL7-Qb