Ruby on Rails c нуля!

В этой статье мы рассмотрим:

1. Установку Git 
2. Установку RVM - Ruby Version Manager для возможности работы с несколькими версиями Ruby, а также наборами библиотек Ruby - Gem’ами.
3. Установку собственно Ruby: Ruby 1.8.7 и Ruby 1.9.3
4.  Установку SQLite, MySQL, PostgreSQL
5. Установку фреймворка Ruby on Rails 3.2 и его зависимостей
6. Установку Node.js как среду выполнения JavaScript
7. Создание нового проекта Rails
8. Работу с зависимостями проекта
9. Настройку тестового окружения и написание простых спецификаций и тестов
10. Написание кода приложения по спецификациям
11. Установку Nginx и Unicorn, и запуск приложения Rails на Unicorn и Nginx прокси
12. Работу с удаленным репозиторием
13. Работу с Continuous Integration (CI) сервером - Travis

 

Read the rest of this entry »

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

Для решения этой проблемы было предложено решение, которое называется Spork. Spork является DRb сервисом (сервером), суть которого заключается в том, что он держит приложение постоянно загруженным, так что вам не нужно его запускать каждый раз вместе с запуском тестов.

В данной статье мы рассмотрим работу Spork совместно с RSpec для Rails 3.2. Мы будем использовать RSpec потому, что он имеет встроенную поддержку DRb сервисов и является одним из самых популярных решений для тестирования и написания спецификаций.
Read the rest of this entry »

Мне на ум пришла такая идея (на оригинальность не претендую), что было бы хорошо организовывать «круговое поручительство» для разработчиков, которое заключается вот в чем:

• Группа программистов занятая в одном проекте выполняет проверку труда друг-друга.
• Круговое поручительство похоже на хоровод — тот, кто ведет тебя предоставляет тебе результаты своего труда для проверки, а ты сам предоставляешь свой код тому человеку, который идет за тобой.
• «Поручитель» не только изучает чужой код, но и делает его рефакторинг и оптимизацию производительности, там где узкие места очевидны.
• После полученных правок к своему коду каждый член команды должен изучить их и сделать соответствующие выводы.
• Через определенный промежуток времени все «перетасовываются» заново, так, чтобы у каждого появился новый «поручитель».

Что это дает?

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

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

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

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

1. Делай чтобы хоть как-то работало!
Если проект работает хоть как-то — это уже лучше, чем когда его совсем нету. Множество ошибок, неправильная архитектура, множество различных хаков, множество повторяющихся фрагментов кода, множества непроизводительного кода и т.д. — все это лучше, чем когда вообще ничего нет!
Read the rest of this entry »

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

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

Недавно начал читать книгу «Человеческое, слишком человеческое» авторства Фридриха Ницше — очень познавательное чтиво, хотя написано очень тяжело из-за чего приходится по несколько раз перечитывать одно предложение. Там была выдвинута идея того, что, нет хорошего и плохого, и плохое не может породить хорошего. Мы можем лишь сравнить два примера и сказать какой из них лучше. Грубо говоря, нет ничего отрицательного — все лишь градиент положительного.

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

Итерационный подход — замечательный подход. Вы не делаете все и сразу, и выпускаете релиз через 5 лет,да еще и с кучей багов. Вы разбиваете весь процесс на кучу версий, а каждую версию на кучу более мелких итераций. Теперь, вы сфокусированы конкретно на выпуске продукта, который выйдет максимально быстро, будет содержать минимальное количество ошибок, которые можно перектыть патчем, либо в выпуске следущей версии.
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 »

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

1. Что есть Git

Git — это мощная и популярная система контроля версий. Git отслеживает изменения в коде програм и позволяет откатывать изменения назад в случае, если они привели к каким-либо ошибкам. Кроме того Git позволяет заниматься разработкой кода коллективно, используя, например, удаленный общий репозиторий, и когда каждый разработчик создает собственную ветку в которой работает, пока не выполнит определенную работу, а затем подмешивает изменения к общему репозиторию. Ранее при разработке ПО разработчикам приходилось делать откаты назад, для этого создавалась копия папки с исходными кодами. Git делает эту работу за вас, но вместо тупого копирования, он делает «снимки» () по которым можно восстановить оригинальный код после того, как в нем были произведены нежелаемые изменения.

2. Установка Git

2.1 Зависимости Git

Для нормальной работы с Git у вас должны быть установлены следующие библиотеки: curl, openssl и zlib

2.2. Установка Git из исходников:
Для установки GIT из исходников на операционные системы семейства UNIX, вам следует для начала скачать исходники, распаковать архив и выполнить следующие команды в консоли для установки:

$ make prefix=/usr all

или

$ make prefix=/usr install

2.3. Установка Git на Linux

Для установки Git на Ubuntu следует просто выполнить в консоли команду:

$ apt-get install git-core

2.4. Установка Git на OS X
Чтобы установить Git на OS X следует в консоли выполнить следущую команду:

$ sudo port install git-core

2.5. Установка Git на Windows
Для установки Git на Windows просто скачайте установочные файлы (http://code.google.com/p/msysgit/downloads/list) и выполните из них установку.

Read the rest of this entry »