Распределенный Ruby

Оригинал этой статьи опубликован в журнале «Системный администратор» №12 (133) за декабрь 2013.

Технология распределенного Ruby, или dRuby (Distributed Ruby), позволяет вызывать методы объектов, находящихся в другом процессе и/или на другом компьютере. При этом установка соединения, передача необходимых данных и тому подобное скрыты от программиста, и использование удаленных объектов мало чем отличается от работы с объектами, заданными внутри программы.

... ... ...

Это не единственная технология RPC, доступная при программировании на Ruby, однако более универсальные средства, такие как CORBA или XML-RPC, более сложны в использовании и требуют больших накладных расходов (кроме того, поддержка CORBA не входит в стандартную библиотеку Ruby, соответственно в сопровождении требует дополнительного внимания к совместимости версий).

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

Читать далее »

Декораторы в Ruby

Оригинал этой статьи опубликован в журнале «Системный администратор» №9 (130) за сентябрь 2013.

Как известно, в языке Python существует красивый механизм декораторов, расширяющих функционал объекта без изменения интерфейса. Это довольно мощное средство, попользоваться им удобно и приятно. Но вот проблема: наш язык программирования — Ruby!

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

... ... ...

Универсальность всегда увеличивает сложность и накладные расходы. Так что мое мнение: жили мы без декораторов в Ruby и еще поживем. Тем не менее сама методика декорирования кода, безусловно, заслуживает внимания и может с успехом применяться в самых разных задачах.

Читать далее »

Статьи в «Системном администраторе»

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

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

Немного о dRuby

DRbObject не является DRbUndumped

Что это значит? Это значит, что если мы передаем посредством dRuby из процесса A процессу B объект, принадлежащий процессу C, при работе с ним B будет обращаться непосредственно к C. Если сможет, конечно, ведь легко может статься, что и B и C имеют доступ к A, но не имеют друг к другу. Тогда получим исключение.

Впрочем, нет никаких проблем заставить A проксировать этот объект для B: obj.extend(DRbUndumped) на стороне A — и дело в шляпе.

Как проверить доступность DRbObject?

Встроенного метода, проверяющего, что объект DRbObject в действительности живой и готов к работе, почему-то нет. Но его легко написать:

class DRb::DRbObject

  def available?
    self.respond_to? :class
  rescue DRb::DRbConnError
    false
  end

end

Здесь мы пользуемся тем, что: а) DRb::DRbObject#respond_to? всегда обращается к удаленному объекту, а не проверяет сам себя; б) метод class определен у каждого объекта, т.е. при доступности вызов вернет true; и в) при недоступности генерируется вполне конкретное исключение.

---

Это все, может быть, неочевидное, но вполне нормальное поведение. А вот следующее наблюдение мне представляется багом...

К какому сервису относится объект?

Предположим, у нас один процесс поднимает несколько сервисов DRb. Ну, например, один основной на TCP, а второй — управляющий на UnixSockets (см. мой гем drctrl). А затем обращается по DRb куда-то наружу и передает туда undumped-объект... Так вот: объект этот будет привязан не к тому протоколу, по которому идет обращение, а к последнему запущенному сервису.

Чтобы это исправить, нужно вручную выставить свойство DRb::primary_server... Впрочем, в своем геме я сегодня это учел и исправил.

О железе, дыбровое...

Моему новому компьютеру скоро полгода, можно, пожалуй, уже и похвастаться, не опасаясь, что сразу после этого что-то сломается... Чтобы этот пост имел хоть какую-то информационную ценность, я постараюсь пояснить выбор комплектующих. Сразу замечу, что речь не идет о том, что какая-то модель или какой-то производитель лучше аналогов — речь идет сугубо о моем мнении касательно моих потребностей. Для других задач и/или в других условиях я бы мог выбрать и что-то другое.

В общем, если кому интересен мой хардодыбр — добро пожаловать под кат. Пришедшим за объективной информацией будет не интересно.

Читать далее »