RubyFlow.ru

Интроспекция цепочки вызова методов ActiveRecord::Base

Tue, 29 May 2012 14:41:40 +0000

Недавно захотелось разобраться, какие методы вызываются при вызове конкретного метода отнаследованного от ActiveRecord::Base класса.

Поэтому я придумал небольшой хак для вывода названия метода при его вызове:

module ActiveRecord
  Base.singleton_methods.each do |m|
    Base.class_eval <<-EOS
      class << self
        puts "redefining #{m}"

        define_method "#{m}_with_introspection" do |*args|
          puts "#{m}"
          send(:"#{m}_without_introspection", *args)
        end

        alias_method :"#{m}_without_introspection", :"#{m}"
        alias_method :"#{m}", :"#{m}_with_introspection"
      end
    EOS
  end
end

https://gist.github.com/2828416

Можно подключить этот код через какой-нибудь init.rb/environment.rb файл, чтобы он загружался при старте проекта или можно просто запускать его руками из irb сессии.

Вот пример использования в irb: https://gist.github.com/2828602

NB: Можно применять этот хак не только для класса ActiveRecord::Base, но и для всех классов/модулей со сложной структурой вызовов метода.

Можно легко доработать этот код не только для вывода названия метода, но и для вывода аргументов и тд.

Jenkins::Client

Wed, 23 May 2012 05:58:03 +0000

Если вы используете Jenkins в качестве сервера непрерывной интеграции, то Jenkins::Client может быть вам интересен.

Эта библиотека предоставляет удобный интерфейс для работы с Jenkins API. Вы сможете просматривать список задач, добавлять и удалять их.

Примеры кода.

Инициализация:

client = Jenkins::Client.new
client.username = "user"
client.password = "pass"
client.url = "http://jenkinsurl.com"

Получение списка задач:

client.jobs

Запуск задачи:

job = Jenkins::Client::Job.new({ :name => "job_name" })
job.start!

Вы сможете узнать больше в README - github.com/john-griffin/jenkins-client

rails-brakeman.com - поиск уязвимостей онлайн

Wed, 23 May 2012 05:52:29 +0000

Библиотека brakeman - это анализатор rails-приложений на предмет наличия в них уязвимостей.

rails-brakeman.com - это сервис, который использует эту библиотеку и предоставляет интерфейс для анализа приложений, чей код размещен на GitHub.

Ссылки:

rails-brakeman.com
репозиторий библиотеки brakeman - github.com/presidentbeef/brakeman
официальный сайт brakeman - brakemanscanner.org

Sextant

Wed, 23 May 2012 05:45:21 +0000

Sextant аналог команды rake routes, который выводит результаты в браузере.

Бывает, что в большом rails-приложении запуск rake-задачи занимает довольно много времени. Ричард Шниман (Richard Schneeman) придумал решение и реализовал его в библиотеке Sextant.

Теперь увидеть все пути (routes) приложения можно открыв страницу /rails/routes. Например,

http://localhost:3000/rails/routes

Стоит также отметить, что адрес /rails/routes доступен только development-режиме.

Ссылки:

исходный код и инструкции на GitHub - github.com/schneems/sextant
вводная статья в блоге Ричарда - Sextant: A Gem to Help you Find your Routes

Play - музыкальный сервер от GitHub

Sat, 19 May 2012 07:49:24 +0000

Продолжая тему слайдов, хочу поделиться ссылкой на стопку слайдов к выступлению Зака Холмана (Zach Holman) - "Stories From a Music-Fueled Distributed Streaming Bender". Вы узнаете о проекте Play - музыкальном сервере в офисе GitHub.

Просто красивые слайды, это еще не конец истории :) Код Play открыт и доступен на GitHub - github.com/play/play. Play имеет специфичные требования к окружению, но об этом подробно рассказано в README.

P.S. Советую посмотреть и другие слайды от Зака, если вы этого еще не сделали.

Слайды доклада "10 Things You Didn't Know Rails Could do" от JEG2

Fri, 18 May 2012 05:37:10 +0000

Прогугливаясь по просторам интернета в поисках инетересной информации, я наткнулся на доклад ruby-гуру Джеймса Эдварда Грея II. В нем собрана информация о функциональности rails, о которой вы, возможно, и не знали. Лично я для себя нашел достаточно много нового, надеюсь, вы тоже найдете... Приятного чтения!

Ссылка: https://speakerdeck.com/u/jeg2/p/10-things-you-didnt-know-rails-could-do

С уважением, @rezwyi.

"Stay young, stay curious, stay hippy..." - доклад Дэвида Хайнемайера Хенссона с конференции "RailsConf 2012"

Wed, 16 May 2012 17:35:42 +0000

В сети выложен видео-доклад Дэвида с конференеции "RailsConf 2012". Всем, кто еще не видел, очень советую...

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

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

Ссылка: https://www.youtube.com/watch?v=VOFTop3AMZ8

С уважением, @rezwyi.

Skypekit for Ruby

Fri, 11 May 2012 11:52:03 +0000

Skypekit для Ruby - библиотека для работы со Skype протоколом

http://blog.railsware.com/2012/05/11/libskypekit-and-skypekit-c-and-ruby-interface-for-skype/

ActiveRecord::Relation#merge или как объединиться с друзьями

Fri, 11 May 2012 08:45:48 +0000

Цель данного обзора показать пару приемов использования метода #merge из модуля ActiveRecord::SpawnMethods, предназначенного для объединения скоупов. relation_destination.merge(relation_source) добавляет sql-выражение из relation_source в итоговый relation_destination. Приведу пару примеров.

Допустим мы хотим получить список всех оплаченных заказов, но только для клиентов с голубыми глазами. В общем случае это могло бы быть так:

Order.paid.joins(:user).where(:users => { :eye_color => 'blue' })

# => SELECT "orders".* 
     FROM "orders" 
     INNER JOIN "users" ON "users"."id" = "orders"."user_id" 
     WHERE "orders"."status" = 3 AND "users"."eye_color" = 'blue'

Но в таком подходе есть проблема: мы должны знать все тонкости выборки этих самых клиентов с голубыми глазами. И возможно, что таковыми должны быть не только клиенты с признаком eye_color => 'blue', но и со статусом равным 1. В таком случае, чтобы разместить логику «голубых глаз» в едином удобном месте логично сделать scope в модели User:

class User < ActiveRecord::Base
  STATUS = { :visible => 1 }
  has_many :orders

  scope :blue_eye, where(:eye_color => 'blue', :status => STATUS[:visible])
end

Теперь мы можем изменить первый вариант на:

Order.paid.where(:user_id => User.blue_eye.pluck(:id))

# => SELECT id FROM "users" 
     WHERE "users"."eye_color" = 'blue' AND "users"."status" = 1
# => SELECT "orders".* FROM "orders" 
     WHERE "orders"."status" = 3 AND "orders"."user_id" IN (2, 3)

Таким образом мы избавились от первоначальной проблемы. Но возник другой момент: такая запись генерирует 2 запроса к БД (к пользователям и к заказам). При этом id'шники пользователей будут переданы во второй sql-запрос. И если пользователей с голубыми глазами будет много (сотни/тысячи), то sql-команда получится очень длинной и в большинстве случаев далеко не оптимальной (разбор плана и т.д.).

И вот на помощь к нам приходит Relation#merge:

Order.paid.joins(:user).merge(User.blue_eye)

# => SELECT "orders".* 
     FROM "orders" INNER JOIN "users" ON "users"."id" = "orders"."user_id" 
     WHERE "orders"."status" = 3 AND "users"."eye_color" = 'blue' 
     AND "users"."status" = 1

Такая цепочка вернет нужные нам заказы за один запрос с использованием SQL оператора JOIN. На мой взгляд, это выглядит достаточно лаконично, причём как с точки зрения AR, так и точки зрения результирующего sql-запроса. Если по какой-то причине мы изменим логику получения клиентов с голубыми глазами, то достаточно будет изменить scope в модели User и все другие запросы получат новые условия.

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

class Friendship < ActiveRecord::Base
  STATUS = {:verified => 5}
  belongs_to :user
  belongs_to :friend, :class_name => 'User',
             :conditions => { :friendships => { :status => STATUS[:verified] } }
end

class Article < ActiveRecord::Base
  belongs_to :user
end

class User < ActiveRecord::Base
  STATUS = { :visible => 1 }
  has_many :friendships, :dependent => :destroy
  has_many :friends, :through => :friendships,
           :conditions => { :status => STATUS[:visible] }
  has_many :articles

end

Несколько вариантов достижения поставленной цели:

1) Все условия в одном вызове:

 user = User.first

 Article.joins(:user).
   joins('INNER JOIN friendships on users.id = friendships.friend_id').
   where(:friendships => 
     { :user_id => user, :status => Friendship::STATUS[:verified]}).
   where( :users => {:status => User::STATUS[:visible]}).
   order('articles.rating desc')

# => SELECT "articles".* 
     FROM "articles" INNER JOIN "users" ON "users"."id" = "articles"."user_id" 
     INNER JOIN friendships on users.id = friendships.friend_id 
     WHERE "friendships"."user_id" = 1 AND "friendships"."status" = 5 
     AND "users"."status" = 1 
     ORDER BY articles.rating desc

2) 2 sql-запроса, идентификаторы пользователей передаются списком в функцию IN:

user = User.first
Article.where(:user_id => user.friends).
  order('articles.rating desc')

# => SELECT "users".* 
     FROM "users" INNER JOIN "friendships" 
       ON "users"."id" = "friendships"."friend_id" 
     WHERE "friendships"."user_id" = 1 
     AND ("friendships"."status" = 5 AND "users"."status" = 1)

# => SELECT "articles".* FROM "articles" 
     WHERE "articles"."user_id" IN (2, 3) 
     ORDER BY articles.rating desc

3) В один запрос с JOIN:

user = User.first
Article.joins(:user).merge(user.friends.scoped).
  order('articles.rating desc')

# => SELECT "articles".* 
     FROM "articles" INNER JOIN "users" ON "users"."id" = "articles"."user_id" 
     INNER JOIN "friendships" ON "users"."id" = "friendships"."friend_id" 
     WHERE "friendships"."user_id" = 1 
     AND ("friendships"."status" = 5 AND "users"."status" = 1) 
     ORDER BY articles.rating desc

Пример с Relation#merge демонстрирует как получить sql-запрос с объединением по друзьям. Немаловажно то, что в запрос включены все те условия, которые мы задали в ассоциациях.

На этом можно было бы и закончить данный обзор, но остался ещё один подводный камень: в Rails 3.0.x такой красивый merge к сожалению изменит SELECT "articles".* FROM на SELECT "users".* FROM, что в результате вернет пользователей, а не статьи. Чтобы это побороть, можно добавить метод экземпляра в модель User:

def join_friends
  Friendship.scoped.
    joins('INNER JOIN friendships on friendships.friend_id = users.id').
    where(:user_id => id, :status => Friendship::STATUS[:verified]).
    where(:users => {:status => STATUS[:visible]})
end

Тогда популярные статьи друзей можно получить так:

user = User.first
Article.joins(:user).merge(user.join_friends).
  order('articles.rating desc')

# => SELECT "articles".* 
     FROM "articles" INNER JOIN "users" ON "users"."id" = "articles"."user_id" 
     INNER JOIN friendships on friendships.friend_id = users.id 
     WHERE "friendships"."user_id" = 1 AND "friendships"."status" = 5 
     AND "users"."status" = 1 
     ORDER BY articles.rating desc

Вот и все, спасибо за внимание!

Полезные ссылки:

DevConf: открыто голосование

Thu, 10 May 2012 17:24:58 +0000

Всего подано 57 заявок в восьми категориях. В категории посвященной Ruby предлагаются следующие темы:

У вас есть возможность отдать свой голос за интересные доклады - http://devconf.ru/offers/