Программирование.

Прежде чем приступать к кодированию, я некоторое время посвятил изучению RoR. Документации на русском оказалось мало, но её хватило, чтобы понять базовые концепции RoR. Очень сильно помогла статья Евгения Охотникова "Новые грани Ruby". Благодаря этой статье понимаешь магию Ruby, на основе которого сделан сам фреймвок. Приведу небольшой список статей, которые помогли мне в изучении RoR:

• Curt Hibbs. Rolling with Ruby on Rails (part I & II). Начальное погружение в RoR, имеется перевод первой части;
• Using Ruby on Rails for Web Development on Mac OS X. Пример работы с RoR (миграция, тесты...);
• http://rubyonrails.freetutorial.info/index.htm. Некий итог всех предыдущих статей.
• John McCreesh. Four Days on Rails. Описание создания более сложного приложения (ToDo List);
• Agile Web Development with Rails. Настольная книга разработчика на RoR.
• Новостная группа. Интерактивное общение с профессионалами позволит сохранить много нервов и сил.

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

Реализацию проекта я старался делать в духе Getting Real от 37 Signals, это означает следующее:

• меньше возможностей;
• меньше опций и настроек;
• меньший объем прораммы;
• кратчайшие сроки;

Применительно к моему проекту, мне пришлось принять следующие важные решения:

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

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

Поиск.
Мои рассуждения были следющими. Во первых, сделать поиск, используя возможности сервера БД MySQL достаточно быстро (на основе LIKE), но качество будет низкое, что дискредитирует саму идею поиска. Устанавливать и настраивать специализированное ПО, прежде всего Ferret, не представляя в какой физической среде будет функционировать сайт, было бы преждевременной тратой времени. Во- вторых, пока на сайте не накопится достаточного объема контента, поиск не нужен, так как искать пока нечего.

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

Визуальный редактор.
Отказ от интеграции визуального редактора - шаг спорный, но он продиктован сжатыми сроками реализации. Подключить возможность Markdown к проекту заняло от силы часа 2-3. Выбрать из нескольких редакторов один, потом интегрировать его с RoR заняло бы у меня намного больше времени по сравнению с первым вариантом.

Общие впечатления от Ruby on Rails положительные, если что-то не было реализованно в RoR, то я достаточно быстро находил плагин с нужной мне реализацией и тестами! Функционал проекта полностью ложился в идеологию RoR, что способствовало сокращению времени разработки и повышению качества реализации. Понравилась сама концепция REST и ее реализация в RoR.
Как оказалось, такая простая на первый взгляд концепция, как облако тегов, скрывает достаточно серьезный математический аппарат, проводятся достаточно серьезные математические исследования по этому поводу. Реализация механизма тегов добавляется очень легко благодаря плагину acts_as_taggable_on_steroids. Не все так просто с визуализацией тегов, я перепробовал несколько алгоритмов расчета веса тега, начиная от самого простого и заканчивая более сложным. После сравнения алгоритмов остановился на последнем.

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

• нужен минимальный функционал за минимальное время, RoR прекрасно справлялся с этим требованием. Время, затраченное на изучение готового движка и последующей его доработки, было бы намного больше по сравнению с выбранным мной вариантом;
• желание получить опыт программирования на Ruby с использованием RoR;

Мое стремление более пристальнее изучить MySQL сошло на нет благодаря реализованному в RoR механизму ActiveRecord. Едиственное, чему я научился, это запускать сервер, останавливать его и выполнять несложные SQL команды в консоле SQL. Оглядываясь назад, могу сказать, что у меня осталась некоторая неудовлетворенность от работы с RoR. Я настраивался на то, что придется потратить много времени и сил на программирование, отладку, изучение Ruby и RoR, но оказалось, что писать на Ruby, используя RoR, было просто и быстро, это позволяло сконцентрироваться не на том, как написать, а на том, что писать. Это добавляло некий fun в сам процесс работы над проектом.

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

Вывод.
Вывод простой: рекомендую прочитать Getting Real и познакомиться с Ruby On Rails.