Недавно вышла книга The dRuby book — distributed and parallel computing with Ruby (перевод японской книги, написанной автором самой библиотеки). В этой статье я попытаюсь дать обзор глав книги, касающихся библиотеки DRb. Если вам захочется ознакомиться с темой более подробно, книгу можно купить или скачать. Сразу скажу, что я не буду говорить в этом посте ни о синхронизации потоков, ни о библиотеке Rinda.

Предположим, что вы пишите систему, которая работает с более чем одним процессом. Например, у вас есть веб-сервер, который в фоновом режиме запускает задачи, работающие долгое время. Или вам просто нужно обеспечить пересылку данных из одного процесса в другой и координировать их. Для таких ситуаций и нужна библиотека DRb. Она написана целиком на Ruby и включена в стандартную библиотеку, поэтому начать работать с ней можно моментально. Для её подключения достаточно написать require 'drb'

Достоинства библиотеки DRb большей частью проистекают из динамичности самого языка Ruby.
Во-первых, при затрате минимальных усилий на подготовительном этапе, дальше вы работаете с объектами не задумываясь, где они расположены: в одном процессе или в другом. Библиотека полностью маскирует от вас все технические детали.
Во-вторых, вы не обязаны жестко прописывать интерфейс. Любой руби-объект может выставить свой интерфейс наружу — таким образом вы можете как воспользоваться функциональностью одного из стандартных классов типа Hash или Queue, а можете сделать свой класс с любым интерфейсом. Кроме того вам ничто не мешает менять интерфейс прямо в процессе исполнения, и даже использовать method_missing для обработки любых запросов. И уж разумеется, обновление интерфейса сервера вообще никак не влияет на клиента, если тот не вызывает методы, которые изменили сигнатуру или поведение. Таким образом сервер и клиент максимально независимы.
И наконец, клиент даже не обязан знать классы объектов, которые ему возвращает сервер, он может их использовать и без этого. Таким образом сервер волен скрыть столько много деталей, сколько ему угодно.
Но, конечно, есть и подводные камни, и их предостаточно. К счастью, dRuby несложен в понимании, ну а понимание его устройства позволяет большей части проблем просто не допускать. Документация к этой библиотеке, к сожалению, не проясняет множества моментов, поэтому статья будет интересна и новичкам, и людям уже поработавшим с библиотекой.

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

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

Примечание переводчика: перед прочтением этого поста рекомендую сначала ознакомиться с постом Вникаем в метаклассы Ruby.

Все рубисты знакомы с формальными определениями для include и extend. Вы делаете include модуля, чтобы добавить методы экземпляра класса, и extend — чтобы добавить методы класса. К сожалению, данные определения не совсем точны. Они не могут объяснить почему мы используем instance.extend(Module), чтобы добавить методы объекту. Разве не должны мы в этом случае использовать instance.include(Module)? Чтобы разобраться в этом вопросе, начнем с выяснения где же хранятся методы.

Вообще я бы хотел представить и немного рассказать о своём маленьком детище, так сказать о коде за вечер. Я всегда считал и считаю, что если хочешь, что-то выучить, а особенно понять технологию, то надо конечно много читать, а еще главное взять, сесть и сделать на этой технологии, что-нибудь пусть даже just for fun. Все равно ведь программирование это творческая работа и у каждого из нас есть в голове какие-то идеи проектов, сервисов, стартапов и если даже нет, то всё равно бывают возникают потребности, какие-нибудь маленькие, но если их взять и решить так за вечер — это и есть удовольствие от изучения. Это моё конечно имхо.

В 2007 году Лоран Сансонетти, разработчик из Apple, основал проект с открытым исходным кодом MacRuby. Его целью было создание интерпретатора Ruby поверх среды исполнения Objective-C, который бы обеспечивал прозрачное взаимодействие между Ruby и экосистемой OS X «Cocoa» — и ему это удалось. Теперь Сансонетти надеется сделать что-то подобное и под iOS.

От переводчика: предлагаю вам перевод начала презентации Michael Fairley — Extending Ruby with Ruby. Я перевел только первую часть из трех, потому что она имеет максимальные практические ценность и пользу, на мой взгляд. Тем не менее, настоятельно рекомендую ознакомиться с полной презентацией, в которой помимо Python приводятся примеры заимствования фишек из Haskell и Scala.

Декораторы функции

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

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

Возьмем Ruby и притворимся, что нам нужно перевести деньги с одного банковского аккаунта на другой. Вроде все просто, так?

def send_money(from, to, amount)
  from.balance -= amount
  to.balance += amount
  from.save!
  to.save!
end

Подкаст

http://ruby.rpod.ru/274255.html

Новости

• SMT_rails — Shared Mustache Templates for Rails 3 шарим темплейты между Ruby и JavaScript. Пример приложения — первые 10 продуктов генерится на сервере, следующие по скролу (scroll pagination) загружаются через JS. Для обоих используется один темплейт.
• Вышла книга The dRuby Book: Distributed and Parallel Computing with Ruby
• Вышел Ruby 1.9.3 patchlevel 194
• Ехуда Кац запустил проект Токайдо
• 16 апреля вышел ruby-plsql
• Вышло расширение к Chrome CoffeeConsole
• mruby and MobiRuby
• 19 и 20 мая Brainwashing

Хочу поделиться своими соображениями. Я читал много топиков на тему Ruby, Ruby on Rails, Ruby vs PHP, Python vs PHP. «Каждый кулик свое болото хвалит». Я считаю, что это дело сугубо каждого — какую систему или язык программирования использовать, личные предпочтения, как говорится, на вкус и цвет товарищей еще поискать. Но суть даже не в этом. Я хорошо знаю PHP, не так давно взялся за изучение Ruby и Ruby on Rails. Знаете, как ни странно это звучит, но мне нравятся обе системы — и PHP, и Ruby, возможно даже одинаково. В Ruby есть свои прелести, которые привлекают — мощность самого языка, очень понятный и лаконичный синтаксис (если с толком подойти к изучению), в PHP — простота и все та же лаконичность языка. Хорошие системы, хорошие инструменты, но все же Ruby как-то в роли догоняющего. Что же тут не так?

Данный пост является ответом на пост "Почему люди выбирают PHP, или почему миллиарды мух могут ошибаться". Надеюсь, мне удастся развеять миф о несостоятельности платформ вроде Ruby и Python, который активно распространяется PHP разработчиками, причем разработчиками т.с. нижнего сословия, которые кроме PHP больше ничего не видали. Конкретно в данной статье я формате вопрос-ответ расскажу о том, почему Ruby и Rails — реальные игроки, почему они популярны и можете ли вы их использовать для построения собственного бизнеса в интернете.

На днях нужно было построить биндинги к библиотеке libftdi, которая обеспечивает взаимодействие с чипами FTDI (чипы для преобразования последовательной передачи данных по RS-232 или уровней TTL в сигналы шины USB, для того чтобы дать возможность современным компьютерам использовать устаревшие устройства © Wikipedia).

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

У FFI есть несколько достоинств, которые сыграли в его пользу:

• Поддержка интерпретаторов MRI Ruby 1.9, MRI Ruby 1.8, JRuby, ограниченная поддержка Rubinius;
• Поддержка платформы Windows (наряду с другими);
• Отсутствие необходимости компиляции биндингов;
• Удобный язык описания биндингов.

Репозиторий биндингов для Ruby.

Взаимодействие с браузерами никогда не было работой для слабонервных: около полудюжины различных API, различные механизмы IPC, и разные возможности у разных поставщиков. Такие проекты, как WebDriver, пытаются абстрагироваться от этой сложности, к тому же в Сети можно найти десятки других «безголовых» драйверов, использующих WebKit или иные движки. В настоящее время в работе даже находится спецификация W3C на WebDriver.

Инструментирование Google Chrome

Тем не менее, в то время, как создание общего решения является сложной задачей, оказалось, что инструментирование Chrome очень просто, — как я недавно обнаружил при исследовании некоторых вопросов, связанных с сетевыми задержками. Начиная с 18 версии, Chrome теперь поддерживает протокол удалённой отладки v1.0, который предоставляет все возможности браузера с помощью обычного WebSocket!

/Applications/Path To/Google Chrome --remote-debugging-port=9222 # OSX
$> curl localhost:9222/json

[ {
   "devtoolsFrontendUrl": "/devtools/devtools.html?host=localhost:9222&page=1",
   "faviconUrl": "",
   "thumbnailUrl": "/thumb/chrome://newtab/",
   "title": "New Tab",
   "url": "chrome://newtab/",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1"
} ]

Подкаст

http://ruby.rpod.ru/273046.html

Новости

• Fork/Join для JRuby
• Evan Phoenix уходит из Engine Yard
• Скидка 1000 рублей на devConf
• Heimdallr CanCan 2.0, статья на
  Хабре про него
• Yell логгер 2.0
• Poffer защищаем представления от «случайных» переменных контроллера
• Акторы в Rubinius
• Future of MacRuby
• Ruby 1.8.7 and REE End of Life
• Новый блог Расса Олсена Без комментариев.

Специальный гость

Леонид Никаноров

• Конкурс от Mail.ru для всех любителей МакБуков
• Леонид на Моем круге

После четырех лет разработки, 31 марта этого года по результатам голосования (пресс-релиз на японском) был принят стандарт ISO/IEC 30170 на язык Ruby.

Стандарт имеет статус 60.00, что по классификации ISO означает «в публикации».

В процессе превращения большей части web-проектов в браузерные приложения, появляется много вопросов. И один из самых весомых из них – обработка прав доступа без лишнего кода. Размышления на эту тему привели нас к большой проблеме: комфортного способа реализовать защиту на уровне полей модели для ActiveRecord просто нет (Егор, привет! ;). CanCan добавляет ограничения на уровне контроллеров, но это слишком высокий уровень чтобы решить все проблемы.

Немножко пободавшись, мы написали два милых гема. Встречайте, Heimdallr (Хеймдаль) и его расширение Heimdallr::Resource. Они принесут в ваши модели мир и безопасность.

Я очень далёк от желания устраивать «cвященные войны» на тему языков программирования. Всё равно мы будем использовать те языки программирования, которые сочтём подходящими для своих задач. Когда я писал эту заметку, я предполагал, что она вызовет негативную реакцию. Меня она совсем не удивит.
Когда я впервые познакомился с ruby, я был приятно удивлён-элегантный и внятный синтаксис языка, мультиплатформенность и много всяких вкусностей.Но пользуюсь я до сих пор python, совсем не потому что python лучше чем ruby. Совсем по другим причинам.

 

Добрый день, Хабр.
Я около года работаю с Ruby и хотел бы написать о некоторых вещах, которых лично мне там часто не хватает, и которые я хотел бы видеть встроенными в язык. Пожалуй лишь пара из этих пунктов являются действительно серьезными недоработками, с остальными можно легко справиться подручными средствами.
Вроде бы недоработки и мелочь, но они ощутимо осложняют работу — приходится писать собственные библиотеки вспомогательных методов, которые и в гем не выделишь — уж больно маленькие, и без них некомфортно. А порой открываешь чужой код — и видишь там точно такие же вспомогательные функции как у тебя. Это как мне думается знак, что стандартная библиотека языка недоработана. Что же, будем надеяться, кто-нибудь из разработчиков прочтет текст и закоммитит патч. ;-)
Итак, начнем по порядку:

• Перегрузка метода разными списками аргументов, как в C++
• Отобразить хэш и получить из него другой хэш, а не массив
• Преобразовать экземпляр класса в экземпляр его же собственного подкласса
• Разные рюшечки

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

module MyModule
  module InstanceMethods
  end

  module ClassMethods
  end

  def self.included(base)
    base.include(InstanceMethods)
    base.extend(ClassMethods)
  end
end

Здесь создаются два под-модуля в рамках текущего модуля для разделения методов инстанса и методов класса. При «примешивании» модуля MyModule в класс выполняется функция included, которая добавляет необходимые методы класса и методы объектов класса.

Не так давно я открыл для себя еще одну подобную функцию, которая выполняется при наследовании

Эта статья иллюстрирует реальное применение и получение выигрыша в производительности на примере закачки файлов в хранилище Amazon S3 с использованием многопоточности на языке Ruby с использованием gem aws-sdk.

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

Ситуация раз

При регистрации пользователя мы как обычно хотим сделать подтверждение пароля. Нет проблем, добавляем :confirmation => true. Через какое-то время у сайта появляется мобильное приложение, в котором тоже реализована регистрация, но подтверждения пароля там уже нет. Как поступить в этом случае?

решение под катом