Конкуренты как гром среди ясного неба.

Сайт был практически готов, я занимался тестированием, исправлением ошибок, проверкой работы сайта в различных браузерах, все шло по заранее намеченному плану.

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

• это не специализированные сайты, а сообщества на универсальных сервисах ("Мой круг", Diary);
• небольшая аудитория зарегистрированных читателей и авторов;
• последние материалы опубликованы около года назад;
• помимо оригинальных текстов присутствуют перепечатки из других открытых источников;

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

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

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

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

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

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

Дизайн.

Создание дизайна сайта заняло у меня очень много времени, это и не удивительно: опыта такой работы у меня не было. Пришлось разбираться с такими понятиями, как юзабилити, типографика, дизайн, графика. В работе мне помогали статьи с сайта Design For Masters.

Первый вариант дизайна я делал, ни на кого не ориентируясь, сам придумал компановку, оформление, подобрал цвета. Сложность была одна: я знал, что мне надо, но не всегда представлял, как это сделать, а если и делал, то результат был далек от задуманного. В итоге первый вариант получился просто никаким. Однажды, когда я искал в интернете ответ на какой-то вопрос по CSS, я натолкнулся на такое понятие, как "шаблон дизайна для сайта". Как оказалось, это пример дизайна, выполненный для первой странички, где вместо текста используется "lorem ipsum dolor..". Я нашел несколько сайтов, которые в большом количестве предлагали подобные шаблоны бесплатно, вместо платы они просили размещать ссылку на их сайт. Весь вечер и до глубокой ночи я просматривал эти шаблоны и отобрал около двух десятков подходящих по оформлению для моего будуего сайта. Эти шаблоны я рассчитывал использовать в качестве отправной точки, т.е. взять самый понравившийся и на основе него уже сделать дизайн. Из всего многообразия скачанных шаблонов я отобрал и отсортировал в порядке приоритета около пяти штук и принялся за переработку дизайна. Сделать дизайн сайта на основе первого шаблона было интересно в том плане, что позволило взглянуть на реализацию своей идеи чужими глазами, в данном случае глазами автора шаблона. В дальнейшем я последовательно переделывал дизайн основных страниц под другие шаблоны в надежде потом выбрать среди них наилучший. В процесе этого занятия оценил то, что использование HTML для семантической разметки текста, а CSS для визуального отображения дает очень много плюсов. Практически у меня получился готовый механизм смены визуальных тем оформления.

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

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

В последнее время в интернете стали появляться сервисы, которые можно использовать при создания сайтов. Работая над макетом и дизайном, я пробовал использовать следующие on-line инструменты:

1. Kuler от Adobe - подбор сочетающихся между собой цветов.
2. Color Scheme Generator 2 - тоже подбор цветов.
3. Logo Maker : Web 2.0 Stylr - позволяет сделать логотип в стиле Web2.0
4. Web2.0 Logo Creator by Alex P - создание логотипа.
5. Favicon.cc Generator - редактор иконок favicon.
6. YAML builder - сервис позволяет создавать различные варианты вёрстки.
7. Typetester - сервис позволяет визуально сравнить между собой несколько шрифтов.
8. Cooltext - позволяет создавать логотипы, кнопки, надписи с различными эффектами .
   

Вывод.
К дизайну и usability подходит выражение "Усложнять - просто, упрощать - сложно". Умение находить золотую середину приходит с опытом, а, чтобы получить опыт, необходимо много работать.

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

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