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

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

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

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

На днях поднимали небольшое продуктовое окружение на несколько нод. Для этого решили использовать Docker Swarm. Не смотря на то, что сам по себе Swarm мало отличается от "голого" докера, всё же приятно будет иметь инструмент для визуального контроля состояния всего кластера. Версии запущенных контейнеров посмотреть или переменные окружения проверить. Ну и вдвойне удобнее если такого рода задачи возникают редко и ты уже знать забыл что там и где настроено - раз в месяц например.

Перевод статьи "Hyperstack vs Hotwire"
@catprint aka Mitch VanDuyn от 26 февраля 2021 года.

Для многих не секрет, что Ruby on Rails - это фрэймворк, основанный на паттерне Model-View-Controller (MVC), где

Пришло время рассказать про замечательный инструмент Consul Registrator. Давно его используем и очень довольны - никогда нас не подводил. Более того, в одном из проектов нам пришлось использовать не его, а упрощенный аналог 🚲 - и это оказалось очень легко реализовать. Но обо всём по порядку.

Один из основных критериев правильно написанного и работающего теста - его детерминизм. Если код не меняется - результат теста тоже не должен меняться. Однако если вы пишете тесты (иначе зачем вообще читать эту заметку?), то наверняка сталкивались с плавающими тестами. Плавающие тесты - это термиты вашего приложения, они замедляют скорость разработки, скрывают баги и как следствие - стоят денег. Тех самых, на которые печеньки с кофе в офис покупают.

Во время написания статей и заметок постоянно приходится вставлять блоки кода. На текущей площадке, впрочем как и на medium, код вставляется весьма просто: