Ruby on Rails c нуля!

Будущее Rubydev, если оно будет, будет светлым. У меня есть следующие идеи по развитию проекта:

1. Не блог, но журнал. Хочу сделать из Rubydev что-то вроде SmashingMagazine, но с ориентацией на backend. Разумеется, будут статьи по frontend технологиям, но это т.с. только 30% от основного контента. Не очень люблю статьи о дизайне и юзабилити, в них очень много воды и очевидных вещей, такое чувство, что их пишут только для того, чтобы инкрементировать счетчик записей и что-бы малоопытные люди могли в комментариях небоясь раскрыть свою малоопытность общаться буд-то специалисты на абстрактные темы вроде каким цветом сделать кнопку для продажи и какой шрифт лучше — serif или sans. Ну и разумеется, новый Rubydev будет написан на Rails.

В новый Rubydev буду писать не только я, но целый коллектив редакторов. Не каждый будет иметь возможность писать статьи как то на хабре, но только редакторы. редактором может быть любой гто изьявил желание, знает тему о которой собирается писать и собирается писать более-менее постоянно, хотябы раз в месяц.

2. На Rubydev появятся обсуждения или форум, что в принципе одно и то же. Любой зарегистрированный пользователь сможет задать вопрос касательно веб разработки и получить ответ.

Есть еще много разных идей для разделов нового RubyDev, но я оставлю их пока в тайне потому, что не уверен в том, что все они будут реально востребованы и что у меня хватит времени на реализацию всех своих задумок.

Для реализации всего этого мне необходим дизайнер, который позже будет по-совместительству ведущим редактором по frontend технологиям. Если вы считаете себя хорошим или крутым дизайнером и frontend разработчиком — присылайте ваши работы или ссылки на них на egotraumatic{a}gmail.com. Если я вам пришлю ответное письмо в течении 2 дней, то это значит, что я заинтересовался вашим соучастием в разработке нового Rubydev.

Говорят, что расширение классов ядра (monkey-patching) — это зло. Тут еще некоторые ведут споры касательно того, что считать monkey-patching’ом — добавление новых методов или переопределение старых, но мы обойдем этот спор стороной и сконцентрируемся на том, как это делать безболезненно.
Read the rest of this entry »

Вам наверное знаком такой код:

a ||= []
a << elem

Так вот, вместо нее можно использовать:

a = [1,2,3,4,5]
b = nil

a = Array.new([*a, 6])
b = Array.new([*b, 1])

a # => [1, 2, 3, 4, 5, 6]
b # => [1]

UPD Предложение от Михаила Дитерле в комментариях:

a = [*a, 6]
b = [*b, 1]

Часто необходимо пользователям gem’ов позволить настраивать их на свой вкус. Как это сделать — об этом эта маленькая статья.

Добавление возможности конфигурирования делается очень просто, наиболее часто для этого используется специальный класс, но если конфигурация совсем простая, то можно обойтись Struct или хэшем. В примере ниже приведена реализация на основе класса Config, однако ее легко можно модифицировать так, чтобы использовался Struct или хэш. Очевидно, что вариант с классом конфигурации наиболее гибкий, а вариант с хэшем наиболее простой.

Read the rest of this entry »

Давайте выделим несколько наиболее выразительных групп методов:

1. Методы проверки, они возвращают true или false (методы — предикаты).
2. Методы копирующие объект и возвращающие его копию предварительно выполнив на ней определенные действия.
3. Методы преобразования, они изменяют объект для которого применяются (bang!-методы, методы — мутаторы).
4. Методы основной смысл которых — что-то передать, (я их называю методы — ссылки, к ним относятся, например аксессоры) (методы доступа).
5. Методы, которые устанавливают значения свойств/переменных (setter’ы)

Чтобы было понятнее о чем я, представляю примеры всех 4 типов методов:

1. Методы проверки (предикаты)

[1, 2, 3].empty? # => false
nil.nil? # => true

Read the rest of this entry »

Статья будет иметь несколько хаотичной. В ней я приведу несколько примеров того, что я считаю неправильной работой с ActiveRecord. Что-то в статье — истина последней инстанции, а что-то — субъективное и, возможно, ошибочное мнение автора. Статья ориентирована на тех, кто хоть немного знаком с Ruby on Rails.

Очень популярная ошибка — не использование limit(1) для выборки одиночной записи с использованием where и других методов Quering API. Суть ошибки в том, что Rails не может за вас подумать о том, что вам необходима одна единственная запись, а не все удовлетворяющие условию. В случае, когда вы не используете limit(1) будет выполняться поиск по всей таблице, а не только до первой соответствующей условию записи.

Word.where(word: 'cat')
# Word Load (0.9ms) SELECT "words".* FROM "words" WHERE "words"."word" = 'cat'
# => [records]

Word.where(word: 'cat').limit(1)
# Word Load (0.7ms) SELECT "words".* FROM "words" WHERE "words"."word" = 'cat' LIMIT 1
# => [record]

UPD Вообще не пользуйтесь .limit(1), вместо .limit(1) используйте first, если вам действительно необходим лишь один элемент. Дело в том, что limit(1) возвращает массив с одним единственным элементом, чтобы получить этот элемент нам необходимо вызывать еще один метод — first (Array#first), или обращаться к элементу через индекс — Model.limit(1)[0].

Tag.limit(1).first
# Tag Load (1.6ms)  SELECT "tags".* FROM "tags" LIMIT 1

Tag.first
# Tag Load (0.8ms)  SELECT "tags".* FROM "tags" LIMIT 1

Read the rest of this entry »

Перевод интервью на русский язык будет опубликован немного позже.

Today in our virtual studio we welcome a super guest. His name is , hi is an extremely productive programmer, Rails contributor, and maintainer of very useful projects such as MetaWhere, Squeel, Valium, etc.

Hi Ernie, please introduce yourself for RubyDev readers.

Hi Vladimir, thanks for the opportunity to “visit” with you. I’ve been a developer with for a bit over a month now, and I’ve been loving it. As for hobbies, I enjoy recreational coding, PC and console gaming (currently spending quality time with Diablo 3), reading, and spending time with my wife and stepdaughter. I also volunteer as a crisis counselor at my church.

Ernie, I want to thank you for your projects. I like MetaWhere and Valium and I have started to use Squeel in my new project. And all these three gems (or ActiveRecord extensions) are awesome and I recommend to all Rails developers to use these tools. Can you briefly describe these gems developed by you?

Sure.

and are very similar. They’re both attempts to expose more of the ARel awesomeness that underpins ActiveRecord 3.x to the developer. At its simplest, this means you can do more than equality and inclusion conditions in your where clauses without resorting to SQL snippets in strings. The primary difference between MetaWhere and its successor, Squeel, is that Squeel has an improved DSL, additional functionality, and cleaner internals. These gems really wouldn’t have been possible if it weren’t for the awesome work on ARel by Nick Kallen, Bryan Helmkamp, Emilio Tagua and of course, Aaron Patterson. Emilio and Aaron were always especially encouraging and helpful as I first began using, then contributing to ARel.

is much smaller, and much simpler. It’s just a gem that allows for improved performance when selecting only a few attributes from your AR models, because it avoids the overhead of instantiating ActiveRecord::Base objects for each returned row. The functionality is similar to “pluck” which has been added to Rails core more recently, though I think Valium is better. :D

Read the rest of this entry »

So, how to solve the «Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.» problem?

You can solve this problem by adding ‘—with-ruby-include‘ option to ‘gem install‘ command. Firstly, check your current Ruby interpreter version with this:

$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]

Or this:

$ rvm current
ruby-1.9.3-p194@r326

Secondly, you should install ruby gem that you want to be installed with this:

$ gem install <ruby gem name> — —with-ruby-include=$rvm_path/src/<ruby version>

For me Ruby version is ruby-1.9.3-p194. Real example:

$ gem install ruby-debug19 — —with-ruby-include=$rvm_path/src/ruby-1.9.3-p194/

Thats all! Happy developing with Ruby, friends!

Всего 5 дней назад DHH добавил новый репозиторий организации Rails на Github. представляет собой расширение Rails проверенное на работоспособность только с Rails 3.2 и предназначенное для выDRYивания кода маршрутизации.

Принцип работы плагина простой, вы объявляете concern’ы, а в них помещаете код общий для нескольких ресурсов.
Read the rest of this entry »