Ruby on Rails c нуля!

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

Типы глаголов английского языка

verb — глагол

Прежде чем вы перейдете к урокам посвященным временам и глаголам очень важно, чтобы вы понимали, что не все глаголы английского языка являются одним и тем же. Английские глаголы подразделяются на три группы: Нормальные глаголы (Normal Verbs), Непродолжительные глаголы (Non-Continuous Verbs) и Смешанные глаголы (Mixed Verbs).
Read the rest of this entry »

За последнюю неделю я опубликовал всего одну статью, поэтому некоторые пользователи писали письма в которых вымогали новых статей=) Дело в том, что каникулы закончились и я вновь продолжаю учебу из-за чего времени стало гораздо меньше, кроме того я нашел себе работу и начал собственный проект. Не смотря на все это, статьи будут выходить каждую неделю в количестве не менее одной.

Планы на будущее:

1. Закончить цикл статей по Git. В данный момент готовится статья по работе с удаленным репозиторием.

2. Начать цикл статей по Ruby on Rails, которые будут представлять собой реальный подробный учебник.

3. Появится новый раздел по Английскому языку. К сожалению, я знаю английский только на уровне чтения технической документации и хочу улучшить свой английский для того, чтобы мочь полноценно общаться с англоязычными программистами и ускорить свои переводнические навыки =) Думаю, этот раздел, несмотря на оффтоп, будет очень полезен многим читателям.

4. Конечно же буду продолжать писать собственные статьи и переводить понравившиеся. Сейчас пишутся две огромные статьи а-ля «Почти книги», первая — о регулярных выражениях в Ruby, вторая — о методах, объектах, классах и модулях. Для новичков самое то. Читаете эти статьи и 90% материала по теме вы уже знаете.

В общем блог растет и развивается. Вот уже 100 подписчик на подходе, почти 600 зарегистрированных пользователей и 50 с лишним статей. Надеюсь мой блог вам нравится, а при воплощении новых планов, которые я описал выше, он будет вам нравиться еще больше. Кстати, у меня есть к вам 2 небольших просьбы:

1. Помогите пожалуйста с пиаром блога.

2. Плюсаните пожалуйста следующий аккаунт на хабре:
Честно скажу, на хабре вы моих статей не увидите, я его использую чисто как площадку для размещения ссылок и самопиара. Вот такой вот я коварный тип. Заранее благодарю вас за помощь и внимание к RubyDev и поздравляю с праздников всех влюбленных!

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

Ruby’новые методы define_method, method_missing и instance_eval

Одной из вещей, которые мне так нравятся в Ruby есть то, что Ruby очень похож на Lisp. Конечно, Ruby не имеет полноты макросов, но он облает набором абсолютно крутецких методов, которые позволяют сокращать ваш код и делать ваши программы более легкоподдерживаемыми. Три метода, которые я реально обожаю это: define_method, method_missing и instance_eval. В этой статье я хочу подробно рассказать о них.
Read the rest of this entry »

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

Пишем расширение на Си для Ruby, ч. 1
Пишем расширение на Си для Ruby, ч. 2

Во второй части мы изменим наш extconf.rb для того, что бы он мог найти необходимые файлы в libstree. Затем создадим класс на Ruby, который будет оберткой над структурой реализованной на Си.

Готовое расширение можно скачать на .

Использование mkmf для поиска библиотек

Как говорилось в предыдущей части, extconf.rb используется для поиска библиотек, заголовочных файлов и проверки сведений о целевой системе перед установкой. Сейчас мы научим extconf.rb находить библиотеку libstree вместе с ее заголовочными файлами. Также мы дадим пользователям возможность указывать gem’у, где находится libstree.

Настройка mkmf с помощью dir_config

Первое, что нам следует сделать, это указать mkmf, где следует изначально искать libstree. Для этого мы будем использовать метод dir_config, который принимает 3 аргумента:

* произвольная строка (обычно это имя библиотеки, в нашем случае «stree»)
* список путей, по которым надо искать заголовочные файлы
* список путей, по которым надо искать файлы библиотеки
Read the rest of this entry »

Требования:

Ruby >= 1.8.6
Rubygems >= 1.3.7

Установка RSpec

Для установки RSpec воспользуйтесь следующей консольной командой:

$ gem install rspec

Благодаря этой команде Rubygems установит следующие gem’ы:

rspec
rspec-core
rspec-expectations
rspec-mocks

Gem rspec-core устанавливает консольную команду rspec. Запустите команду rspec с параметром —help чтобы увидеть доступные опции:

$ rspec —help

С места в карьер!

Напишем простой пример, который описывает желаемое поведение программы:

# bowling_spec.rb

describe Bowling do
  describe "#score" do
    it "returns 0 for all gutter game" do
      bowling = Bowling.new
      20.times { bowling.hit(0) }
      bowling.score.should == 0
    end
  end
end

Read the rest of this entry »

Пишем расширение на Си для Ruby, ч. 1
Пишем расширение на Си для Ruby, ч. 2

Вчера на почтовый ящик мне пришло письмо от читателя блога RubyDev , к которому был приложен перевод понравившейся ему статьи авторства небезызвестного в Ruby сообществе (известного также под псевдонимом tenderlove). Большое спасибо Василию за приложенные усилия и за помощь!

А теперь собственно статья:

Мне нравится писать расширения для Ruby на C. В этом цикле статей мы разберемся, как это делать. Я раскрою такие темы, как создание рабочего окружения для написания расширения, TDD, отладку, взаимодействие со сборщиком мусора, кросс-компиляцию для windows и т.д.

К концу серии постов мы должны написать расширение, которое будет оберткой для libstree. libstree - это реализация суффиксного дерева на C.

В этой части мы подготовим все, что нам нужно для разработки, изучим шаблон обычного расширения на C и реализуем наш первый метод на C. Естественно, все это мы будем делать используя TDD и autotest.
Read the rest of this entry »

Цикл статей ПРО GIT:
Введение
Ветки (бранчи)

В прошлой статье о системе управления версиями Git я как-то слишком сухо рассказал о том, что это такое и зачем все это необходимо, позабыв о тех людях, которые совсем не знакомы с таким технологическим процессом разработки как контроль версий. Именно из-за этого своего упущения я решил начать эту статью с так сказать теории о системах управления версиями.

1. Система Управления версиями (СУВ) — что это?

1.1. Прошлый опыт

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

Вспомните последний раз, когда вы работали в MS Word или Photoshop. Работая практически с любым редактором будь то текстовый, графический, музыкальный или видеоредактор вы всегда допускаете ошибки. Затем вы исправляете эти ошибки, а затем заметив, что ваши исправления неправильны, нажимаете «Undo», «Step back up» или как там оно у вас называется? Еще часто возникает необходимость отредактировать какой-либо текст или по заготовке отрисовать детальный дизайн сайта. Тогда, чтобы не портить заготовку, вы создаете ее копию и вносите изменения в одну из копий, а если что-то пошло не так, то вы либо используете те же «откаты», либо просто удаляете файл, создаете новую копию оставшегося оригинала и заново начинаете работать. Вам ведь все это знакомо, не так ли?
Если ваш ответ утвердителен, значит вы уже знакомы с системами управления версиями и ваше «знакомство» с ними подразумевает активное их использование!

1.2. Дадим определение понятию СУВ

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

GIT — это абсолютно обычная СУВ!

1.3. Разновидности СУВ

Существует как минимум 3 основных СУВ:

— Локальный
— Централизованные
— Распределенные

1.3.1. Локальные СУВ
Локальные СУВ должны быть знакомы начинающим программистам. Вы наверняка при работе с кодом, перед началом работы создаете копию рабочего каталога для того, чтобы если вы что-то напортачили, то у вас оставался тот прогресс на котором вы остановились в прошлый раз. Лично я делал так: Допустим у меня есть рабочая директория project в этой директории я создавал папку saves в которой хранились другие директории с именами версий 1, 2, 3 и т.д. и в каждой директории находились копии всех рабочий файлов с прогрессом на определенный момент времени. Я уверен, что многие делали подобным образом, возможно именовали категории не 1, 2, 3, а более логичным способом или еще что-то типа того. Все это можно назвать локальной СУВ каменного века! Существуют также специальные программы локальных СУВ, которые позволяют автоматизировать это копирование папок и файлов или использовать другой способ сохранения стадий развития проекта (версий).

Достоинства: Простота

Недостатки: Относительно небольшая область применения, опасность потери данных в случае если ваш компьютер поломался, или его у вас украли или все уничтожил вирус или …

1.3.2. Централизированные СУВ
Когда идет работа над большим проектом с окромным количеством папок, а в них в каждой огромное количество файлов, а в них в каждом огромное количество строк кода, то над таким проектом, как правило, работает несколько человек. Из необходимости организовать работу группы людей и были созданы централизированные СУВ (из тех, о которых я слышал это Subversion и CVS).

Представьте себе монарха восседающего на золотом троне да с золотой короной на златых власах… Представьте теперь сокровищницу с неисчислимыми богатствами. А теперь представьте, как верные вассалы подношают царю налоги собранные со своих крепостных да подарки, чтобы задобрить своего владыку. — Вот примерно таким образом организованы централизированные СУВ.

Есть монарх он же главный разработчик и есть вассалы — разработчики каждый из которых вносит какую-то свою определенную лепту. Сокровищница в данном случае это центральный репозиторий в который добавляются результаты работы участников процесса разработки какого-либо проекта (налоги).

Достоинства: Высокая степень организации процесса разработки, контроль основного (центрального) репозитория, широкая область применения.

Недостатки: Существует риск потерять данные если сервер на котором размещен центральный репозиторий поломается.

1.3.3. Распределенные СУВ
Представьте детскую группу в садике. У детей урок аппликации. У каждого ребенка свои ножницы, своя цветная бумага, клей, заляпанные клеем штаны и полное довольством за свою работу лицо. Дети заканчивают делать свои работы, воспитательница собирает их, выбирает самые хорошие и отправляет их, например, на городскую выставку детского творчества предварительно сделав всем детям альбомы с копиями работ. — Все это похоже на то, как работают распределенные СУВ.

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

Git относится именно к распределенным СУВ.

Достоинства: Безопасность данных, высокая степень организации процесса разработки, широкая область применения.

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

1.3.4. История Git
Чисто как дань уважения пишу небольшой раздел об истории появления Git (честно говоря я никогда этот раздел в книгах не читаю).

Жил был на свете Антон Городецкий Линус Торвальдс и занимался он с 33 богатырями разработкой ни чего нибудь, а ядра Linux! Сами понимаете, операционные системы — это достаточно сложные программы для разработки которых без использования СУВ не обойтись. Так вот, поначалу худо-бедно богатыри вели контроль версий путем, на сколько я понимаю рабским, то есть, как я понял все это было весьма глупо, производилось вручную и было трудоемко. Затем, в 2002 году Линус Торвальдс и компания богатырей — разработчиков решили воспользоваться СУВ BitBeeper. Затем, по некоторым причинам личного характера разработчики ядра Linux решили отказаться от BitKeepera и Линус Торвальдс в порывах чувств и пребывая в необыкновенной силы порыве энтузиазма создал  Git. Read the rest of this entry »