Aaz on software

В Ruby любой объект можно превратить (сериализовать) в последовательность байт, а потом без каких-либо потерь обратно восстановить в объект. Для этого нужен модуль Marshal и методы dump и load, которые идут из коробки. Это очень любопытный механизм, потому что он универсальный (может сериализовать любой объект любого класса) и совместимый (как backward так и forward) с предыдущими версиями Ruby. Кроме того одна из целей - это маленький размер дампа. Экономят буквально на байтах. Учитывая динамическую природу Ruby, богатство функционала и большую стандартную библиотеку разработать такой формат было нетривиальной задачей.

Недавно плотно позанимался с методом BasicObject#instance_eval (полезный для построение DSL-ей в Ruby) и сделал для себя парочку открытий.

Метод Kernel#require - это стандартный способ в Ruby подключить другой файл. За простотой на самом деле стоит нетривиальная логика. Принимаешь как должное, что он адекватно и надежно работает и не думаешь, например, а потоко ли безопасен require. А атомарен ли. А как справится с циклом в зависимостях.

Rails-миграции подходят для маленьких и коротких миграций. В идеале без downtime. Это разумный выбор для нового проекта. База данных относительно маленькая, пользователей мало. Downtime - не проблема. Бага - тоже не страшно.

Мой список проблем с миграцией данных в Rails. Стандартным механизмом миграций, который доступен из коробки. Под миграцией данных я понимаю изменение данных в базе данных приложения.

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

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

Правильно провести техническое собеседование - это целое искусство. Говорят, что если много-много практиковаться то можно достичь просветления. У меня до сих пор не получилось. Видимо мало практиковал.

После недавнего выхода Ruby 3.0 я решил проверить, что gem Dynamoid нормально на нем заводится. И в процессе столкнулся с любопытными проблемами. Matz зарелизил Ruby 3.0 по традиции на католическое Рождество и вместе с тем выкатил обратно несовместимые изменения в keyword arguments. Еще в предыдущей версии Ruby 2.7 начали сыпаться deprecation warning‘и, но руки не дошли это исправить. Теперь warning‘и превратились в exception‘ы и пришлось таки этим заняться.

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

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

В самом-самом начале когда я только начинал заниматься Rubocop мне очень не хватало информации и конкретных примеров. Сразу же возникли вопросы, а какие узлы AST-дерева существуют, какие иерархии они могут образовывать, какие могут быть дочерние узлы, как перемещаться по дереву, в каком порядке вызываются callback‘и и обрабатываются узлы дерева, какой жизненный цикл у объекта-cop‘а и как кешировать промежуточные результаты… Документация не сильно помогала и пришлось нырять самому.

На днях у меня получилось влезть коготком в один из самых интересных проектов на Ruby - Rubocop. Если кто-то не сталкивался - это Ruby-линтер. Нет, не совсем так. Это целый фреймворк для разработки своих правил и проверок - он умеет статически анализировать исходных код на Ruby, проверяет (по умолчанию) правила из Ruby Style Guide и может даже автоматически корректировать/исправлять исходники - убирать лишние пробелы, заменять unless на if итд.

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

Давайте поговорим немного о Rack. Rack - это важная часть Ruby веб-стека и, де-факто, стандарт общения между веб-сервером и приложением. Все Ruby-сервера, например Puma, Unicorn или Thin, передают HTTP запросы приложению и получают обратно ответы именно по Rack интерфейсу. Обычно, правда, приложение ничего об этом не знает - обо всем уже позаботился какой-нибудь фреймворк вроде Rails или Sinatra.