Ruby on Rails c нуля!

Пришло мне тут два письма с просьбой написать о STI — наследовании от одной таблицы. Материал достаточно простой, однако, если люди просят — почему не уделить написанию статьи пол часика?

Признаться честно, мне не нравится термин STI применительно к Rails, поскольку на самом деле наследуются не таблицы, а классы. Здесь больше подходит термин Class Table Inheritance поскольку один класс наследуясь от другого получает доступ к таблице основного класса.

Разберемся с терминами.

Базовый класс — это класс от которого наследуются все остальные классы.

Наследуемый класс — здесь все понятно.

Для чего необходимо STI? — STI достаточно удобная штука и используется в двух основных случаях:

1. У нас имеются две и более моделей, которые имеют абсолютно одинаковые атрибуты, но должны вести себя по разному.

2. У нас имеются две и более моделей, которые имеют несколько общих атрибутов, общие атрибуты выносятся в отдельную таблицу и отдельную модель — базовый класс.

Read the rest of this entry »

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

Рассмотрим все плюсы и минусы использования чужих и своих решений.

Плюсы решений сторонних разработчиков:

- Значительная экономия времени на разработку.

- Вы получаете уже протестированное и проверенное решение.

- Вы получаете поддержку со стороны сообщества разработчиков по вопросу использования решения. У того же Devise есть собственное сообщество, где можно решить все проблемы, задать вопросы.

Плюсы собственных решений:
- Вы отлично знакомы с кодом своего решения и вам не нужно изучать чужое решение.

- Собственное решение является более органичным относительно приложения.

- Собственное решение — решение исходя из ваших собственных желаний, которое не накладывает на вас ограничений и полностью реализует такую архитектуру какую вы представляете.

Минусы сторонних решений:

- На пользователей сторонних решений накладываются некоторые ограничения.

- Сторонее решение невсегда хорошо вписывается в архитектуру приложения.

- Очень часто требуется очень сильно дописывать строронее решение.

- Требуется время на изучение стороннего решения.

Минусы собственных решений:

- Необходимо относительно значительное время на разработку, тестирование, исправления и рефакторинг собственного решения.
Честно говоря, мне больше нравится вариант, когда собственные решения комбинируются со сторонними. Например, мне не придет идея писать свой фреймворк, однако мне пришла идея писать свою CMS на Rails и скорее всего в ней будет использоваться собственное решение для авторизации и аутентификации, однако много чего будет взято со стороны: JQuery, возможно Apotomo  и т.д.

Очень интересно мнение читателей по поводу использования своего решения или стороннего.

— полезный gem авторства Махаэля (Михаила) Дворкина, который занимается тем, что предоставляет удобное представление объектов в консоли.

Для установки Awesome Print следует просто выполнить в консоли следущую команду:

$ gem install awesome_print

Awesome Print также доступен в виде Rails-плагина, в таком случае его установку следует выполнять как установку любого другого Rail-плагина:

$ ruby script/plugin install http://github.com/michaeldv/awesome_print.git

Read the rest of this entry »

Обещал, что RubyDev Ruby tutorial будет закрыт, но не тут то было!
Вы уже должно быть прочитали главу посвященную классам и узнали о наследовании классов. Часто необходимо одмин классом наследоваться от нескольких классов, что называется множественным наследованием, однако Ruby по ряду причин не располагает возможностью множественного наследования. Отсутствие множественного наследования в Ruby несколько не препятствие и не показатель бедности и недостаточной функциональности языка, напротив, отсутствие множественного наследование избавляет программиста от различных проблем связанных с конфликтом имен, в то же время Ruby предоставляет свой альтернативу множественному наследованию — примеси (mixins).

Модули как раз таки и служат для реализации этого самого подмешивания, а также для логического объединения и инкапсуляции(отделения от внешнего мира) кода.

Представим, что ваше приложение на Ruby состоит из нескольких классов, тогда, поскольку приложение является чем-то монолитным, его следует объединить в модуль. Для особо крупных приложений используется сразу несколько модулей, один основной (корневой), который содержит приложение целиком, и несколько которые объединяют части кода приложения по определенному признаку, например в Rails имеетсямодуль ActiveRecord, который хранит весь код реализующий паттерн ActiveRecord для работы с базой данных, модуль ActiveSupport, который включает в себя другие модули, например ActionController, который хранит в себе весь код реализующий контроллеры, сам ActiveSupport отвечает за реализацию VC от паттерна MVC (Model-Viev-Controller, если забыли).

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

Read the rest of this entry »

— совсем молодой и совсем простой и маленький gem, который позволяет в очень удобный способ форматировать дату и время.

Устанавливается Stamp абсолютно так же, как и остальные gem’ы:

$ gem install stamp

Как что работает?

Stamp добавляет в экземпляры Date и Time классов могущественный метод #stamp, который принимает шаблон в соответствии с которым производит форматирование. Чтобы поиграться — запустим сеанс irb:

$ irb
require 'stamp' #=> true

date = Date.today
  #=> #<Date: 2011-07-07 (4911499/2,0,2299161)>
date.stamp("Now: 2000/01/01")
  #=> "Now: 2011/07/07"
date.stamp("%Y,%m,%d")
  #=> "2011,07,07"
date.stamp("1 April, 1873 year")
  #=> " 7 July, 2011 year"

То же актуально и для экземпляров Time:

time = Time.now
  #=> 2011-07-07 14:02:28 +0300
ruby-1.9.2-p180 :019 > time.stamp("%H:%M:%S")
  #=> "14:02:28"
ruby-1.9.2-p180 :024 > time.stamp("23:34")
  #=> "14:02"
ruby-1.9.2-p180 :025 > time.stamp("23:34:12")
  #=> "14:02:28"

Признаться честно, stamp не всегда работает так, как хочется, примеры:

date.stamp("1-1-2003")
  #=> " 7- 7-2011" - ненужный пробел!

date = Date.new(2011,12,3)
  #=> #<Date: 2011-12-03 (4911797/2,0,2299161)>
date.stamp("%d/%Y/%m")
  #=> "03/2011/12"
ruby-1.9.2-p180 :030 > date.stamp("12/12/11")
  #=> "12/12/03" - куда делся 11 год и почему дата отформатирована именно так?

Что я думаю
Stamp — полезный инструмент, который уже можно использовать для, так сказать, простого, стандартного форматирования, однако для извращений вроде %d%Y%m он не подходит, разве что используя спецсимволы форматирования, но тогда, какой смысл использовать stamp? Будем надеяться, что автор не забросит проект и будет его развивать и в скором времени мы увидим реально мощный инструмент форматирования даты и времени в любойформат, какой только может придуматься воспаленным мозгом (хотя, зачем?). Также важным для нас — русско-/украинско-/белорусско- говорящих фактором является то, что отсутствуют наши, родные названия месяцов, хотя это и не сложно допилить в каком-нить stamp-for-SNG форке =).

Линкусики:
GitHub repo:

— онлайн форматер даты и времени (можно подсматреть спецсимволы форматирования), который принадлежит тому же Джереми Вeйскоттену, который создал gem Stamp.

автора Stamp — Джереми Вейскоттена.

В связи с тем,что у меня появилось несколько идей проектов мне приходится несколько изменить формат блога. Изменения будут следующими:

1. RailsTutorial и RubyTutorial будут закрыты. Это можно объяснить не только моей большой занятостью, но и тем, что эти проекты RubyDev не получили того внимания, на которое я расчитывал. Безусловно, статьи по теме Ruby и Rails будут публиковаться приблизительно с той же продуктивностью, что и раньше, но уже не будут иметь последовательный характер. Разработка блога, которую я начал при написании учебника будет продолжаться. В связи стем, что блог, который я собираюсь создать будет иметь достаточно много кода и функций, подробное описание его разработки, как то представлялось в RubyDev Rails 3 Tutorial, невозвожно в связи с нехваткой времени, однако некоторые особенно интересные, проблематичные и важные аспекты будут рассматриваться. После того, как ядро блога будет создано будет производиться набор всех желающих поучаствовать в развитии проекта.

2. Уже давно обещал начать писать статьи по RSpec, MongoDB/Mongoid, и Javascript/JQuery, однако написание этих статей несколько уходило в сторону от основного вектора работы. В данный момент меня заинтересовало событийное программирование: EventMachine, возможно Node.js, и прочие. Могу пообещать, но не гарантировать, что на эту тему также появятся мои авторские статьи и переводы.

Что касается RSpec, то конкретно сейчас меня не сильно волнует тестирование и вообще у меня нет таких проектов в которых бы тестирование было неотъемлемой частью процесса разработки, однако я понимаю, что тема достаточно важна, и при наличии свободного времени обязательно хорошо разберусь сам с этой темой и напишу бо-о-ольшую-такую статью, экранов на 50, в которой рассмотрю подробно работу с RSpec. По MongoDB и Mongoid также планируют две огро-о-омные статьи, но конкретных сроков я не даю.

Статьи по JQuery и JavaScript будут писаться только когда я займусь разработкой клиентсткой части движка блога. Есть одиин человек, который согласился мне помогать с разработкой конкретно client-side, поэтому, возможно именно он будет вести раздел о JavaScript/JQuery.

3. Основной парадигмой блога становится: Что делаю, то и описываю. Больше никаких учебников и т.д., в лучшем случае — заметки и HowTo, которые, с натяжкой, можно использовать как учебники. Они будут очень кратко, в аскетичной манере описывать работу с чем-либо. Те же статьи по RSpec, MongoDB, Mongoid будут иметь именно такой стиль, который, возможно, будет позже разбавлен текстом дополнений и примечаний.

4. В последнее время заинтересовался технологией Bit-Torrent и созданием собственного трекера. Возможно напишу собственную реализацию сервера на Ruby, не знаю, то, что есть меня не устраивает. Если моего запала хватит на долгое время, то обещаю опубликовать статьи по теме разработки bt-сервера, каталога раздач и т.д.

P.S. Хотелось бы иметь список людей — новичков, которые желают поучаствовать в проекте разработки движка блога, возможно в других моих начинаниях, набраться опыта, возможно, создать совместную команду для разработки приложений «для себя». Если есть заинтересованные люди, то отпишитесь в комментариях к этому посту. Свой email для контакта указывайте в форме отправки комментария, так он не будет никому доступен, кроме меня.

P.P.S. Если вас интересует RSpec, то отпишитесь пожалуйста какие конкретно аспекты работы вас интересуют, какие связки и т.д. Возможно, это входит в спектр моих интересов и я смогу эти аспекты раскрыть в той большой статье о RSpec, которую обещаю написать.

Продолжая серию статей о File IO в Ruby, мы, в этой статье покопаемся в двух компонентах стандартной библиотеки языка Ruby, которые расширяют ядро Ruby IO API: модуль FileUtils и класс Pathname.

Модуль FileUtils

Модуль FileUtils предоставляет интересный подход к манипуляции файлами путем эмуляции множества команд Unix для работы с файлами и большинства их опций (флагов). То, что вы можете сделать командами типа rm -rf и ln -s может быть выполнено соответственно методами FileUtils.rb_rf и FileUtils.ln_s.

Так как они придерживаются синтаксиса знакомого большинству Ruby-программистов они являются очень простыми для понимания, делая список вызовов методов FileUtils очень похожим на сеанс bash. Пример, что приведен ниже демонстрирует эту схожесть:

require "fileutils"

FileUtils.touch(["some_file.rb", "another_file.rb"])
FileUtils.mkdir("code")
FileUtils.mv(["another_file.rb", "../other_file.rb"], "code")

Dir["code/*"]
#>> ["code/some_file.rb", "code/another_file.rb"]

FileUtils.cp_r("code", "bkp")
FileUtils.rm_r("code")

Dir["code/*"]
#>> []
Dir["bkp/*"]
#>> ["bkp/some_file.rb", "bkp/another_file.rb"]

Read the rest of this entry »