gem_updater – полезный гем-помощник при обновлении бандла

Утилита обновляет гемы (через bundle update) и после выводит перечень changelog'ов. Оч удобно, т.к. теперь при каждом мажорно-минорном апдейте можно не лезть за ченджлогами в гугл

gem install gem_updater
gem_update

‍https://github.com/MaximeD/gem_updater

bundle install --jobs – ускоряем установку и обновление гемов

И у bundle install, и у bundle update можно задать параметр --jobs – кол-во параллельных воркеров, которые будут заниматься установкой/обновлением гемов

По-умолчанию --jobs равно 1. Ставим число, равное кол-ву ядер у процессора – получаем прирост в скорости

Также можно выставить глобальное значение по-умолчанию, и вызывать привычные bundle install, bundle update (и gem_update из поста выше – прим. ред.), и все они будут выполняться с параллелизмом

bundle config --global jobs 8

time – замеряет время выполнения команд в терминале

Полезно, когда нужно сравнить скорость выполнения команд во время экспериментов. Попробуйте, например, выполнить
time bundle install --jobs 1
time bundle install --jobs 8
и сравнить результаты

Кстати, тем же способом можно замерять вызов команд из bash и zsh
time zsh -i -c "print -n"
time bash -i -c "print -n"
Это полезно, если вы экспериментируете с расширениями и плагинами для bash и zsh. Каждая из этих команд сперва запустит zsh/bash, со всеми плагинами и конфигами, потом выполнит там команду в кавычках, и покажет итоговый отчет

annotate – держим перечень всех полей БД в ActiveRecord-моделях

Заходим, например, в модель User. Видим класс, DSL, ассоциации, методы. Но также бывает удобно в этом же файле увидеть, какие поля, индексы, дефолтные значения содержит таблица users. Annotate помогает в этом

Гем annotate запускается после каждой миграции и добавляет в модели комментарии-аннотации со всеми полями и индексами в БД по каждой модели (см. скрин)

В настройках гема можно указать, что хотим видеть в аннотациях, а что не хотим (индексы, дефолтные значения, внешние ключи), где хотим (только в моделях, или еще в тестах, фикстурах, фабриках), в начале файла или в конце (я размещаю аннотации в конце файлов – прим. ред.). Пример конфига можно найти здесь: https://github.com/gambala/rubyshow/blob/master/lib/tasks/auto_annotate_models.rake

Установка:

group :development do
  gem 'annotate'
end

Генерация конфига:

rails g annotate:install

"comments": {} – оставляем комментарии в package.json

Как правило комментарии для гемов и ярн-пакетов используются, чтобы явно обозначить зависимости или причину использования конкретной версии, жестко заданной для пакета

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

gem 'fastimage' # shrine dependency
gem 'puma', '~> 4.0' # because of capistrano3-puma incompatible with 5.0

С package.json ситуация сложнее. Это json-файл, который не только парсится командами yarn install / upgrade-interactive (и поэтому не может содержать js-комментарии), но еще и меняется ими, в ноль затирая все неочевидные для yarn комменты-хаки

Продолжение – в комментариях к посту

Dave Thomas – My Dog Taught Me to Code – 30 советов о том, как писать хороший код

https://www.youtube.com/watch?v=yCBUsd52a3s

Одно из самых вдохновляющих меня видео о кодинге. Матерый программист Дейв рассказывает о вещах, о которых многие забывают или не видят за всеми этими SOLID GRASP OOP PATTERNS. Ведь написание понятного и поддерживаемого кода – скрывается в мелочах и простых принципах

А еще это видео – спойлер к контенту на канале

В сети достаточно инфы о том, как войти в руби и рельсы и дорасти до джуна и первой работы. А что потом? Почему-то выясняется, что в реальных проектах:
- Никто не спрашивает тебя 3 принципа ООП и расшифровку каждой буквы SOLID
- Откуда-то берется легаси, который обходят стороной
- Почему-то все новые сверх-крутые гемы и js-фреймворки не спешат внедрять в продакшн

И вот ты знаешь язык, фреймворк, практики. А на деле – еще столько вопросов и серых областей, на которые не дают ответы даже сеньоры и лиды из твоей команды. И как тогда быть?

Об этом канал. Оставайся с нами

Пока я выстраиваю контент и решаю свои вопросики (новая работа, получение внж в Европе) – ссылка на мой тред в Тви по прохождению собеседований

Тред еще буду дополнять, поэтому задавайте свои вопросы, в продолжении отвечу на них тоже

https://twitter.com/gambala_codes/status/1426185185427697669

Скринкасты DHH как возможность взглянуть на вещи под другим углом

Девида (создатель Ruby on Rails, владелец Basecamp, автор книг Remote Rework) можно воспринимать по-разному. Кодер, бизнесмен, блоггер, инфлюенсер? Кто же он, хороший ли кодер, и стоит разработчикам прислушиваться к нему?

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

И DHH именно такой. И блоги DHH в HEY и на ютюбе (где раз в несколько лет появляются скринкасты) – это место, где он доносит свое виденье массам. Экспериментально, ненадежно, но очень интересно

И пока весь мир использует для фронтенда Webpack, DHH находит в современных браузерах поддержку интересной фичи, видит возможность упростить написание простого фронтенда и выливает это виденье зрителям: https://youtu.be/PtxZvFnL2i0

И когда мир смотрит и говорит – ок, Девид, но как нам использовать React, а не твои специфичные библиотеки – Девид отвечает – да в общем-то вот, работает и с реактом: https://youtu.be/k73LKxim6tw

И когда мир говорит – ок, но у нас сложный и уже отлаженный фронт, мы не можем полагаться во всем на importmaps, и нам глупо использовать уже ставший медленным в 2021-м году webpacker – Девид отвечает – ну, вот, вы можете использовать чистый esbuild без какой-либо магии со стороны Rails не напрягаясь: https://youtu.be/Chiu-0EVW3g

Интересно наблюдать за этим общением и тем, как очень сырой в первом скринкасте подход крепнет и внедряется в ядро Rails 7

Почему сырые вещи на старте – это нормально

Последний мой тезис в прошлом посте – мол, круто смотреть, как очень сырой код крепнет со временем. DHH защищает и транслирует этот подход на многих примерах того, что он делает. Например, здесь: https://youtu.be/zKyv-IGvgGE

Все потому что:

«Сырой код сегодня – надежный и вылизанный завтра»

Но если сегодня не будет даже сырого кода – какова вероятность, что он вообще появится?

Гляньте видео, там много о том, как командам удается выживать при таком подходе

В новом скринкасте DHH снова дает понять, каким простым, быстрым и тонким будет фронтенд и его сборка в Rails 7 (альфа-версия которой выйдет уже на неделе)

https://youtu.be/JsNtLiph87Y

В скринкасте видим не только сборку JS esbuild вместо webpacker'а, но и сборку Tailwind CSS их встроенным быстрым и крутейшим JIT-сборщиком. На каждое изменение в коде – 50ms сборки, обновление страницы – готово

Ждем Rails 7. Наконец-то можно будет избавиться от webpacker'а со всей его магией и webpack'а, уже давно проигрывающего по скорости другим сборщикам

А еще я очень рад за создателей Tailwind CSS. Я бесконечно топлю за эту библиотеку стилей везде, где только можно, тейлвинду была посвящена серьезная часть моих постов в групповом менторстве в прошлом году. И не без оснований. Чудеснейшая библиотека, которая еще и развивается и не перестает удивлять с каждым обновлением. Из недавнего – JIT-сборка и динамические классы-стили (если интересно, могу рассказать подробнее)

bundle open – открываем исходный код любого гема

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

Во всех таких случаях – пишем bundle open devise – и в редакторе открываются исходники devise (или другого выбранного вами гема) ровно той версии, что используется у вас в проекте

И дальше на выбор – изучаем внутрянку, API, находим проблемные места

При желании даже можно вносить точечные манки-патчи и моментально видеть изменения на localhost-стенде. Только помните – каждый такой манки-патч нужно возвращать назад, иначе не избежать неочевидных конфликтов в будущем на других проектах с этим же гемом и при обновлении версии гема. Внесли быстрые изменения – проверили – откатили изменения назад – внесли их правильно через форк гема и коммит

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

Например в Sublime Text это Gem Browser: https://packagecontrol.io/packages/Gem%20Browser

А в VS Code – Bust A Gem: https://marketplace.visualstudio.com/items?itemName=gurgeous.bust-a-gem

Вышла альфа версия Rails 7. Фичи

✦ Новый подход к фронтенду (подробно освещался ранее на этом канале)
✦ Асинхронные ActiveRecord-запросы
✦ Шифруемые ActiveRecord-атрибуты
✦ Комментарии в SQL (полезно для логов)
✦ Zeitwerk включен по-умолчанию
✦ Spring выключен по-умолчанию

https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-released/

А ниже – пара мыслей про Tailwind CSS, esbuild и путь, по которому идут рельсы во фронтенде 👇

Хорошая новость – вышел Stimulus 3.0

Новое API для параметров, значения по-умолчанию, больше колбеков, дебаг-режим, интеграция с Tailwind CSS

Анонс: https://world.hey.com/hotwired/stimulus-3-c438d432
Доки: https://stimulus.hotwired.dev/

Плохая новость – в библиотеке все еще кошмарнейшее именование. И стало еще хуже

Ребята все еще гнут свою линию и именуют контроллеры, параметры, экшны, функции и файлы по совершенно диким принципам, не основанным ни на каких стандартах ни из мира JS, ни из мира руби

Кто-то в Basecamp, совершенно незнакомый с понятием «семантический разрыв», все еще принимает идиотские решения по API

В итоге получаем фреймворк с хорошей идеей, и с cryptic API, который придется зазубрить, чтобы нормально его использовать

Не рекомендую

Кстати, Github (которые тоже используют много руби и рельс у себя) совершенно спокойно развивают Catalyst – правильный и логичный Stimulus. За ним – будущее

https://github.github.io/catalyst/

По тегу #коммит на канале доступны полезные коммиты, которые можно читать и применять в своих проектах

https://github.com/gambala/rubyshow/commit/1c46aafcf2830e7d0c0b102d3b22052f4f587e27

В сегодняшнем коммите, в рамках проекта https://ruby.show
– перешел с Webpacker v5 → v6
– с PostCSS v7 → v8
– включил JIT в TailwindCSS, чем ускорил сборку стилей в 40 раз и получил все новые фичи JIT-тейлвинда (динамические классы, доп-модификаторы и т.д.)

Перешел с webpack на esbuild и postcss cli сборщики, ускорив сборку фронтенда еще в 100-120 раз 🚀

В проекте сейчас рельсы 6.1, но и с ними, и c 6.0 – можно использовать новые гемы jsbundling-rails и cssbundling-rails

Это микрообертки (никакой магии, никаких внутренних конфигов как в вебпакере), позволяющие ненавязчиво использовать esbuild, postcss и tailwind cli, и другие современные сборщики (webpack в том числе) для сборки js и css

Чуть позже я проделаю такой же переход на другом боевом проекте побольше (вебпакер собирает там ассеты 60-130 секунд), по результатам отпишусь – прим. ред

#коммит https://github.com/gambala/rubyshow/commit/c49eec61a81661cea84a38eb0552a32ecdddfce2

Перевел на esbuild один из клиентских проектов

В вебпакере сборка фронта занимала 60-90 секунд. Сейчас в esbuild занимает 2-3

И на локальном стенде в режиме --watch собирает бандл моментально. Цифры в районе 5-50 миллисекунд

Кажется пора сесть и по горячим следам написать гайд на англ языке (который завирусится, попадет к DHH в твиттер, в rubyweekly и т.д.)

На какой платформе публикнуть гайд? Что вообще сейчас модно? DEV.to?