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

Прежде чем приступать к кодированию, я некоторое время посвятил изучению 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.

Макет будущего сайта.

Перед самым кодированием я решил сделать макет основных страничек будущего сайта. При создании макета преследовал следующие цели: оценить и прочувствовать саму идею, познакомиться с HTML и CSS, попробовать себя в качестве дизайнера. Находясь под впечатлением от чтения книги Getting Real, созданию макета я придавал большое значение, для меня было важно понять на ранних стадиях, насколько моя идея реализуема, как она будет выглядеть, насколько она адекватна и стоит ли ее вообще реализовывать. Первые наброски делал в MS Word с картинками из ClipArt'а, потом попробовал рисовать макет в MS Paint. Благодаря таким экспериментам я стал немного представлять, как может выглядеть главная страничка. В тот период мне на глаза случайно попалась книга "Философия CSS-дизайна". Штудировал я ее в обеденное время на работе. Больше всего меня поразила та гибкость в дизайне, которую можно достичь, если использовать HTML для смысловой разметки текста, а CSS для визуализации. Сайт csszengarden.com надолго стал для меня основным местом, куда уходил лимит трафика и свободное обеденное время.
Вдохновленный возможностями CSS, я принялся делать макет уже в HTML и сразу же столкнулся с различными сложностями. Поначалу было очень тяжело без знания возможностей CSS реализовать задуманное, это на первых порах очень сильно тормозило работу. Выход я нашел простой: я стал просматривать сайты и подмечать для себя наиболее понравившиеся дизайнерские решения. Просмотрев несколько десятков сайтов, я остановил свой выбор на разделе новостей сайта Apple. В данном случае я руководствовался правилом: если хочешь стать профессионалом, то научись сначала подражать другим профессионалам. При создании макета подражание я не считал чем-то зазорным. По замыслу навигация на сайте должна быть основана на облаке тегов. Нарисовать или сделать симпатичное облако тегов самостоятельно у меня не получилось, в итоге я воспользовался сервисом Tag Design. На основе подготовленных данных я сгенерировал несколько облаков с тегами, для нужд макета это оказалось более чем достаточно.
В процессе создания прототипа моя первоначальная идея начала видоизменяться. В первую очередь сервис стал более тематическим, т.е. он стал составлять одно из подмножеств от первоначальной идеи. Как следствие усложнился генерируемый пользователями контент, сообщения вида "Привет, Вася Пупкин" хотя и могут появиться, но это будет нарушением установленных правил и общей тематической направленности. Другим важным решением стала ориентация сервиса на определенную возрастную категорию. Все эти видоизменения позволили мне более точно представить, каким должен быть сервис и кто им будет пользоваться. Название я подбирал, используя различные словари, расположенные в интернете. Как оказалось, все более менее удачные названия уже кем-то были использованы. В итоге остановился на простом и распространенном рабочем названии.
Завершение создания прототипа было важным моментом. Во-первых, это означало, что я в реализации идеи продвинулся намного дальше, чем просто рассуждения вслух или запись в файле. Во-вторых, сама идея приобрела законченные очертания. В- третьих, я почувствовал драйв от всего процесса. Довести проект до завершения было уже делом чести.
Вывод:
Для проектов, которые можно отнести к разряду стратапов, создание прототипа должно носить обязательный характер. На этой стадии можно более точно оценить идею, внести в нее коррективы, предположить, кто ей будет пользоваться и как будут пользоваться. В случае, если идея покажется до конца не проработанной, ее реализацию можно отложить, тем самым избежать последующих неудач и разочарований.

Правильный выбор - основа успеха.

Итак, сформулированы цели проекта, общие требования к функциональности и к дизайну. Настало время претворять идею в жизнь. На тот момент я уже был немного знаком с Ruby, слышал о Ruby on Rails и, естественно, было желание реализовать проект, используя именно эти технологии. Этому способствовала переведенная книга Getting Real, идеи, описанные в книге, понравились и произвели на меня большое впечатление.

В конференции RubyOnRails to russian неоднократно поднимается вопрос о хостинге для RoR проектов. В странах СНГ эта новая технология только начинает появляться, поэтому выбор хостинга небольшой. Сначала я предполагал использовать бесплатный хостинг, но после изучения этого вопроса с мыслью о бесплатном хостинге пришлось расстаться (очень много нареканий на качество услуг и обслуживание). Поиск дешевого хостинга и сравнение цен было не в пользу RoR, появилась мысль написать данный проект на PHP. О PHP я знал немного: это самый популярный язык для создания динамических страниц, отлично работает с MySQL, его много ругают, но при этом с ним постоянно сравнивают другие технологии, существует много framework' ов, и нет среди них явного лидера. В стремлении минимизировать затраты на проект я стал серьезно рассматривать PHP как платформу для реализации. Для ознакомления подобрал несколько книжек для начинающих, почитал несколько сравнительных обзоров. Изучать "тяжелые" framework'и PHP у меня не было ни времени, ни возможности, поэтому под руку попался шаблонизатор Smarty, на нем и решил остановиться. Пока я подбирал книжки, выбирал шаблонизатор для PHP, скачал и настраивал Denver, я вдруг понял, что RoR мне ближе своей архитектурой и что на тот момент я уже "въехал" в принципы построения приложений, оценил скорость разработки и удобство работы с БД. В итоге скорость разработки и стала решающим фактором в пользу RoR. Я рассудил следующим образом: у меня мало опыта в создании сайтов, вообще нет опыта работы с хостерами, я не представлял, как получить имя для домена, как разместить потом сайт под этим именем, как потом сделать его популярным, что такое поисковая оптимизация. Поэтому само программирование не должно отнимать львиную долю времени и сил. В отличие от RoR PHP мне пришлось бы изучать с самого начала, но саму идею познакомиться с PHP я не оставил, возможно, при реализации другого небольшого проекта я попробую и PHP.
С базой данных было намного проще, конкуренцию MySQL мог составить только PostreSQL, но в данном вопросе я решил не рисковать и выбрал MySQL в виду его большой распространенности, а также наличия огромного количества документации. Еще одним важным решением для меня было использование CSS для дизайна и разметки страниц. В своем первом WEB приложении вся разметка была сделана с использованием таблиц, причем я не использовал технику шаблонов. Любые просьбы пользователей о том, чтобы добавить вспомогательную информацию на все страницы (в подвал или в шапку) приводили меня в некоторый ступор, я даже не представлял, сколько потребуется времени, чтобы изменить около 20-30 страниц и при этом постараться не испортить то, что уже работало. В таких случаях я им отвечал: "Это займет 2 недели" - и вопрос решался сам собой.

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