Статья «Rails for Everything» на Literally The Void отстаивает универсальность Ruby on Rails для разработки различных типов проектов, опровергая стереотип о его ограниченной применимости и подчеркивая преимущества использования полного стека Rails вместо разделения на микросервисы, в то время как комментарии на Reddit отражают разнообразие мнений разработчиков об актуальности фреймворка в 2025 году, его производительности и сравнении с современными альтернативами.

Petr.codes в «Flexible API versioning with Rails» предлагает гибкий подход к версионированию API в Ruby on Rails, рассматривая проблемы традиционных методов и демонстрируя эффективную архитектуру с использованием наследования и модулей в контроллерах, что позволяет разработчикам легко управлять изменениями между версиями API без дублирования кода.

Статья Мартейна Холса «The European Accessibility Act for websites and apps» разъясняет требования Европейского акта о доступности для цифровых продуктов, описывая сроки внедрения, технические стандарты и необходимые меры соответствия, которые должны предпринять разработчики и владельцы бизнеса для обеспечения доступности своих веб-сайтов и приложений в соответствии с законодательством ЕС.

Марк Мэнсон в статье «Why You Should Quit the News» утверждает, что следует отказаться от регулярного потребления новостей, поскольку они вызывают стресс, фокусируются на негативе и отнимают время, которое можно потратить на более ценные занятия, при этом большинство новостных материалов не имеют практического влияния на нашу повседневную жизнь.

Статистика от Stackoverflow по использованию технологий за 2024 год

Алекс Рассел в своей статье «If Not React, Then What?» критикует React за создание избыточного уровня абстракции над веб-платформой, что приводит к проблемам с производительностью и большим JavaScript-пакетам, и предлагает Web Components как более эффективную альтернативу, которая работает в гармонии с нативными возможностями браузера и следует принципам прогрессивного улучшения.

Ахмад Шадид выпустил гайд о новых CSS свойствах — «Relative Colors».

На днях заказал новые кроссовки, так как нынешние уже набегали больше тысячи. Я брал их в августе 24-го.

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

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

Получается, новые кроссовки такие же как и старые, только новые. Можно даже предположить, что набегав тысячу километров, счетчик обнуляется и кроссовки перерождаются в новые 😀.

Кажется, большинство моих постов про тренировки можно начинать с фразы "вчера была тренировка и я её сделал". Вот этот пост не исключение. Спустя несколько дней перерыва пробежал 9 км в легком темпе, а дома было небольшое ОФП. Но вряд ли эта часть кому-то интересна. Хочу сказать про другое.

На улице теплеет. Теперь 0 не ощущается как -5. Это скорее 0, а иногда и теплее. Если раньше надетых лонга, футболки и ветровки казалось не хватает (по крайней мере, первые пару километров, пока разогреваешься), то теперь ветровка кажется избыточным элементом. Не успел побежать, а уже жарко. Уже ветерок, если и есть, то не холодный. Не тот что, продувает даже непродуваемый слой одежды, залезая в душу. А, знаете, такой теплый, медленный, обнадёживающий.

В результате потепления, торговаться с собой, выходя на пробежку легче. Кажется, что мысль "точно не побегу" довольно быстро сменяется на "наверное побегу". Важно ещё сказать про время тренировок. Летом я бегал по утрам. Было очень жарко, было другое расписание. Сейчас бегаю вечером. При чём, это такой вечер, когда уже пора спать. В десятом часу тяжело себя тянуть на улицу. А если тренировка тяжелее бега по пульсу до 140 или содержит ОФП, то это вообще жопа (сорри, мам). Возможно именно поэтому каждый раз, когда хочется написать пост, я начинаю его с одной и той же фразы.

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

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

Я когда-то пробовал разбираться с tmux, но бросил. Было непонятно, и не очень надо. Сейчас использую WezTerm. Это современный кроссплатформенный терминальный эмулятор и мультиплексер. До этого работал с iTerm2, Wrap.dev, Kitty. Пробовал даже Alacrity. Но прижился WezTerm. Он довольно производительный (не самый-самый), но норм. Написан на Rust. Поддерживает GPU-ускорение рендеринга. Имеет встроенную поддержку шрифтов с лигатурами и поддерживает конфигурацию на Lua. В общем, он стоит того, чтобы его попробовать.

Для работы над проектом я обычно две вкладки. Одна содержит 3-4 панели, в каждой из которых запускаются
— Redis-сервер
— Rails-сервер
— Сборка фронта
Еще одна вкладка в редакторе с Neovim для работы с кодом.

В результате экспериментов, я пришел вот к такой конфигурации. Это ссылка на gist, чтобы не копировать все 200 строк кода в пост.

Сам файл .wezterm.lua лежит в корневой директории пользователя. В общем, ничего не обычного. Базовая конфигурация WezTerm выглядит так. Остальное в gist — пример настройки панелей.

local wezterm = require("wezterm")
local config = wezterm.config_builder()

-- Настройки шрифта и интерфейса
config.font_size = 13.0
config.font = wezterm.font("JetBrains Mono", { weight = "Bold" })
config.color_scheme = "Tokyo Night Storm"
config.line_height = 1.05
config.use_dead_keys = false

-- Настройки окна
config.window_padding = {
    left = 5,
    right = 5,
    top = 5,
    bottom = 5,
}
config.initial_cols = 120
config.initial_rows = 36

return config

Вчера была тяжёлая тренировка, и я её сделал. Возможно, делай я её утром, она не выглядела бы настолько тяжёлой. Но вечером, ближе к девяти, хочется уже «приуютиться» и не высовываться из дома. Особенно когда там по ощущениям -7 и темно.

Но вчера торг с собой был недолгим. Вчера было ограничение по времени — на 11 вечера был запланирован созвон, так что откладывать тренировку было нельзя. Надо было или бежать, или не бежать. До принятия второго варианта я ещё не созрел. Так что пришлось бежать.
2 км разминки с отрицанием, торгом, принятием. А потом лесенка: 1 км по 4:15, 1,5 км по 4:30, 2 км по 4:40 и в обратную сторону.

Окончательно расшевелился я после первого быстрого километра. Сначала мелькнула мысль: «быстро я уже сбегал, и пора бы сворачивать в сторону дома». Но то ли 300 метров восстановительной трусцы придали сил, то ли легкий дунайский бриз продул голову... Сложно сказать. Одно было заметно — как будто вспомнил, как надо бежать. И дальше уже бежалось лучше. С «терпячкой», добеганием, но лучше. Уже не было вот этих моральных терзаний о том, как устал и хочется скорее в тепло. Уже стало ТААК тепло, что все причины перестать ушли на второй план. Одним словом, разбегался.

Вчера починил перьевую ручку. Когда-то заказа ее на али, но практически сразу испортил. Ну как испортил... Заправил слишком хорошими чернилами. Китайская ручка за сто рублей не была готова к такому — чернила слишком быстро высыхали и буквально застревали в ручке, забивая канавку. Пробовал замачивать в холодной и горячей воде, промывать под давлением. Ничего не помогало. Слишком хорошие чернила были еще и водостойкими.

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

И ручка записала. Конечно, я многого от нее не ожидал. Но всё равно приятно.

Что за ручка? Это клон Lamy Safari. После починки она стала прекрасно и легко писать. Не так тонко как при покупке. Но низкая цена ручки и дешевые чернила (тоже около 100 рублей) делают эту ручку просто идеальной.

Как вы знаете, я решил отказаться от использования Strava. И вот спустя почти три месяца я прихожу к мысли, что идея была так себе. Я сразу предполагал, что от моего ухода никто кроме меня не пострадает особо. По началу эта мысль о "непричастности к большому сообществу" мне очень нравилась. Однако сейчас я понимаю, что идея была так себе. Просто представьте, что все вокруг вас едят мороженное. Даже если вы не хотели это мороженное изначально, то в какой-то момент закрадывается мысль, что и неплохо было бы...

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

Урвал классный пульсометр по очень низкой цене. Garmin HRM Pro Plus. Это была очень выгодная покупка. И теперь конечно же интересно побегать. Благо сегодня есть такая возможность. Холодный ветер, дождь и возможный гололед оставим за скобками. Задача на сегодня огонь:

1 км по 4,15, 2 км по 4,30, 2,5км по 4,40, 2 км по 4,30, 1 км по 4,15

Как раз для теста пульсометра 😀

В чем его фишка? Больше данных собирает. Если не смотреть на разные штуки, связанные с безопасностью, то из классного:

— вертикальные колебания при беге
— время контакта с землей
— баланс времени контакта левой/правой ноги
— длина и частота шага

Еще есть offline запись. Датчик сохраняет данные о тренировке без подключенных устройств. Подробный обзор можно почитать у Рэя, я вряд ли что-то больше добавлю: Garmin HRM-PRO Plus Heart Rate Strap In-Depth Review.

Представьте, что вы строите дом. Можно быстро построить его из доступных материалов, игнорируя некоторые строительные нормы, чтобы скорее въехать. Или можно делать всё по правилам, но это займёт больше времени. В первом случае вы "берёте в долг" – экономите время сейчас, но потом придётся исправлять недочёты, причём обычно с гораздо большими затратами.

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

За 19 лет работы с различными проектами я выделил три верных признака того, что технический долг начинает тормозить бизнес:

Во-первых, разработка новых функций постоянно замедляется. То, что раньше занимало пару недель, растягивается на месяц или больше. Разработчики боятся трогать старый код, опасаясь сломать существующий функционал. А некоторые части системы становятся "священными" – к ним вообще никто не хочет прикасаться.

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

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

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

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

Я бы предложил начать с простого — с простых вопросов команде: сколько времени занимает добавление типовой фичи? Насколько уверенно вы чувствуете себя при внесении изменений? Какие части системы вызывают больше всего проблем?

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

Работа с техническим долгом – это не разовая акция, а постоянный процесс. Я рекомендую начать с трёх шагов:

Первое – выделите ресурсы на технические улучшения. Классическое правило: 20% времени команды должно уходить на технический долг. Да, это может казаться дорого, но альтернатива обойдётся дороже.

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

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

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

Последние пару недель нет времени ни писать, ни бегать. Сначала боролся с соплями, потом со знаниями. Из интересного, почти отказался от VS Code и перешёл в VIM. Тут надо сразу оговориться, я пишу vim, но подразумеваю nvim. То есть в том контексте, о котором я пишу разницы нет.

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

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

Вообще я долго пытался понять что неудобно в vim и почему он для меня не работает. И в какой-то момент пришла мысль о том, что я пытаюсь использовать его как использую все остальные GUI редакторы. А надо изменить подход. То есть мало отказаться от использования мышкой, надо еще изменить способ мышления. Идея не в том, чтобы мыслить не символами и хоткеями, а командами.

Композиция команд — это очень мощная концепция в Vim/Neovim. Например, команда может состоять из трех частей:

— Оператор (что делать)
— Модификатор (сколько раз или как)
— Движение (с чем делать)

Примеры:

d2w   - delete 2 words
da{ - delete around {}
y$    - yank to end of line
ciw   - change inner word
c3j   - change 3 lines down

Вот к примеру основные операторы

• d - delete (удалить)
• y - yank (копировать)
• c - change (изменить)
• p - put (вставить)

и основные движения

• w - слово
• b - назад по словам
• e - конец слова
• $ - конец строки
• 0 - начало строки
• ^ - первый непробельный символ в строке

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

Более того, команды регистрозависимые. Например,

• word - последовательность букв, цифр и символа подчёркивания
• WORD - последовательность не пробельных символов

Поэтому

example_variable_name      # три words, то есть три нажатия w
example_variable_name      # один WORD
some-compound-word        # три words
some-compound-word        # один WORD

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

Вот последние находки для разделения одно окна на панели

— <C-w>v или :vsp - вертикальное разделение
— <C-w>s или :sp - горизонтальное

Для навигации между панелями:

— <C-h> - в левое окно
— <C-j> - в нижнее окно
— <C-k> - в окно сверху
— <C-l>- в правое

То есть идея понятна, те же hjkl + нажатый Ctrl.

А еще метки. Про них наверное отдельно надо писать. Если кратко, то ma ставит метку 'a'. mb — метку 'b'. Не важно где была поставлена эта метка в этом файле и сегодня ли. Но

- `a и `b позволяет переключаться между файлами или теми блоками где вы были очень быстро
- `` позволяет вернуться к предыдущей позиции
- '. возвращает к последним изменениям

В общем, пока я нажимал www, гуляя по словам, было прикольно, но как-то странно. Потому что преимущества с обычным редактором не были заметны. А вот метки как раз принесли очень интересные возможности.

PS: Как я писал в начале поста "я почти отказался от VS Code". Мне все еще нравится VS Code. Он прекрасен и привычен. Поэтому когда я устаю разбираться с vim, я просто переключаюсь на VS Code.