Судя по комментариям на моем блоге, большинство не пользуется сервисом gravatar.com. А зря, очень удобная вещь.

Многие, да наверное почти все, зарегистрированы и общаются хотя бы на одном форуме. И наверняка используют аватару, что повышает узнаваемость автора и позволяет легче находить в длинном треде посты от одного и того же человека. Да и просто красиво. Поэтому использование аватаров на форумах стало неким «правилом хорошего тона». А чем блогосфера хуже?

Немного о самом сервисе. Gravatar – это сервис, хранящий ваш аватар на своем сервере с привязкой его к e-mail. Надо всего лишь зарегистрироваться, указать один или несколько почтовых ящиков, которые вы используете при комментировании блогов, и загрузить аватар.

Теперь при комментировании блога, поддерживающего работу с gravatar, напротив вашего сообщения будет выводиться ваш персональный аватар. А блогов, уже интегрировавших использование глобального аватара в комментариях, становится все больше и больше. Если еще с полгода-год назад это было в диковинку, то теперь постоянно встречаю блоги с выводящимися изображениями рядом с никами комментаторов. Жалко, правда, что эти изображения чаще всего представляют из себя не персональные аватары комментаторов, а какую-то заглушку.

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

Сайт сервиса: ru.gravatar.com (совсем недавно появилась поддержка русского языка, я еще регистрировался, когда не было поддоменов).

Раздел для вебмастеров: ru.gravatar.com/site/implement. Приведены ссылки на модули для подключения граватаров к большинству популярных CMS, есть руководство по самостоятельному внедрению с примерами кода на нескольких языках. Так что прикрутка сервиса не должна вызвать каких-то проблем.

Тематику для сайта решил взять «рыбалка».

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

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

Немаловажным аспектом при выборе тематики была и ее привязка к коммерции. Сами по себе тематики хобби, спорт и прочие являются в большинстве своем малоденежными, по ним ничего не продается и не покупается. Рыбалка же, напротив, является достаточно затратным хобби далеко не детей и подростков, а вполне взрослых и состоявшихся людей. Если зайти в какой-нибудь магазин «Все для спорта», то, скорее всего, самым большим отделом будет рыболовный, где продается все, начиная от лодок и заканчивая огромным ассортиментом поплавков и блесен. Если сюда приплюсовать и разнообразные платные водоемы, туры, рассчитанные на рыбаков, наличие газет и программ по телевизору про рыбалку, раздел «охота и рыболовство» на яндекс маркете, то можно с уверенностью заявить – рыбалка денежная тематика.

Концепция же будущего сайта проста до гениальности. Сделать самый лучший сайт для рыболовов.

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

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

Предыдущие посты марафона «СДЛ. От идеи до прибыли.»:
СДЛ. От идеи до прибыли. Старт.

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

В WordPress нужный функционал уже включен в дистрибутив (блоговый движок же, возможность присоединения картинок к постам просто обязательна), в Joomla тоже все решается стандартной комплектацией движка, пусть и криво (загрузка файла через «Медиа-менеджер» с последующим копированием адреса загруженной картинки и вставки его в статью через визуальный редактор), хотя Joomla использовал только версии 1.0.x, может в 1.5.x ситуация лучше обстоит, не знаю, не проверял.

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

Решение «в лоб» и не требующее работы над движком: ручная заливка картинок по фтп на сайт и последующая вставка html кода в тело статьи. Собственно, большинство этим и пользуется (как, впрочем, и я сам раньше).

Можно реализовать загрузку файла (в том числе и изображения) активировав входящий в стандартную поставку модуль Upload, а для отображения загруженной картинки в теле ноды скачать и установить модуль Inline.

Или же скачать и активировать модули Content Construction Kit (CCK), File Field и Image Field, после чего создать в нужном нам типе ноды дополнительное поле специально для присоединения изображения.

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

И следующий существенный недостаток – изображение можно вставить только в определенное место ноды, например, до текста.

Но ведь хочется иметь возможность присоединять произвольное количество изображений и вставлять их в любое место статьи с любым позиционированием. Поэтому наиболее правильным вариантом будет использование WYSIWIG (What You See Is What You Get) редактора с возможностью загрузки изображений на сервер через веб интерфейс.

Чтобы не мелочиться, рассмотрим сразу три популярных визуальных редактора – BUEditor, CKEditor и TinyMCE. В качестве загрузчика изображений будем использовать модуль IMCE.

Визуальный редактор BUEditor с возможностью загрузки изображений

BUEditor не является визуальном редактором в чистом виде, т.к. оперировать приходится все равно html кодом. Я это недостатком не считаю, мне даже удобнее видеть не графическое представление, а сам исходник. Несравненным плюсом этого редактора, ставящим его выше всех остальных редакторов, является возможность изменения любых кнопок и создание своих собственных.

Итак, нам понадобится:

• модуль BUEditor;
• модуль IMCE.

Качаем модули, заливаем на хостинг в папку modules, активируем в Управление/Конструкция сайта/Модули (admin/build/modules).

Теперь BUEditor автоматически будет использоваться при создании новой ноды, также автоматически произошла и привязка IMCE к BUEditor. Кликнув на кнопку визуального редактора «Insert/edit image» (пиктограмма в виде фотографии заката), вы увидите функцию «Browse», с помощью которой сможете загрузить изображение с локального компьютера.

К слову, человеку непривычному будет трудно сходу разобраться в интерфейсе IMCE, так что внизу представлен принтскрин с пояснениями. Аналогичный интерфейс будет и при использовании других визуальных редакторов.

Все практически идеально, за исключением того, что вставляемая картинка не имеет атрибута align, и поэтому текст не обтекает ее. Добавим помимо полей адреса картинки, размеров и альтернативного текста, поле для ввода значения атрибута align, причем так, чтобы значение по умолчанию было «left», как самое часто используемое.

Идем в настройку BUEditor Управление/Настройка сайта/BUEditor (admin/settings/bueditor) и кликаем на «Изменить» напротив Editor name – Default. Мы попали в раздел создания новых кнопок или перепрограммирования имеющихся, чем и займемся. Ищем поле «Insert/edit image» и добавляем к коду следующее:

Таким образом создаются и атрибуты горизонтального/вертикального отступов, рамки и прочие.

Стоит заметить, что модуль IMCE умный, и если вы загрузите несколько картинок с одинаковыми расширениями и именами, они не перезапишутся, просто к именам будут добавлены индексы «_1», «_2» и т.д.

Настройки максимального веса картинок, максимального разрешения, допустимые для загрузки расширения доступны в настройках модуля IMCE Управление/Настройка сайта/IMCE (admin/settings/imce). Данные настройки не зависят от используемого визуального редактора.

И не забываем при создании ноды сменить фильтр ввода с «Filtered HTML» на «Full HTML», иначе все теги порежутся.

Визуальный редактор CKEditor с возможностью загрузки изображений

Красивый и довольно популярный визуальный редактор. Ранее известный как FCKeditor, но начиная с третье версии выпускающийся под названием CKEditor. FCK – это инициалы создателя редактора и по совместительству сокращение от английского нецензурного слова, о чем автор (бразилец) изначально как-то не подумал, в результате редактор пришлось переименовать.

Нам понадобится:

• модуль CKEditor;
• сам CKEditor версии не ниже 3.1;
• модуль IMCE.

Скачиваем, устанавливаем и активируем два модуля для Drupal – CKEditor и IMCE, после чего скачиваем дистрибутив самого CKEditor и распаковываем его в папку ckeditor модуля CKEditor. Получится три вложенных папки ckeditor/ckeditor/ckeditor, где первая папка – папка модуля, вторая папка – вложенная папка модуля и третья папка – папка самого визуального редактора.

Теперь необходимо настроить права доступа. Идем Управление/Управление пользователями/Разрешения (admin/user/permissions), ставим галочку напротив «Зарегистрированный пользователь» в графе «модуль ckeditor/access ckeditor», сохраняем.

Переходим к настройкам модуля CKEditor Управление/Настройка сайта/CKEditor (admin/settings/ckeditor). Кликаем на «Изменить» напротив Профиль/Advanced и в выпадающем списке «File browser type (Image dialog)» выбираем IMCE.

Все, теперь к каждому полю для ввода текста автоматически добавляется визуальный редактор CKEditor. Хотя это иногда может быть и не желательно, например когда надо вводить заведомо не отформатированный текст. Запрет привязки CKEditor к полям определенных страниц прописывается в разделе «CKEditor Global Profile» настроек модуля (выпадающий список Visibility settings, где надо перечислить адреса или маски адресов).

Если у вас не отображается визуальный редактор, проверьте файл вашей темы page.tpl.php, перед закрывающим тегом body должна быть такая строчка:

Или же можете протестировать на теме Garland, если в ней все работает нормально, то проблему стоит искать в файлах шаблона.

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

Визуальный редактор TinyMCE с возможностью загрузки изображений

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

Нам потребуется:

• модуль Wysiwyg (API, позволяющее интегрировать визуальные редакторы в Drupal);
• модуль IMCE Wysiwyg bridge («мост», соединяющий Wysiwyg с IMCE);
• модуль IMCE (модуль для загрузки изображений на сервер с локального компьютера);
• визуальный редактор TinyMCE (Main package).

Качаем, заливаем на сервер и активируем модули Wysiwyg, IMCE Wysiwyg bridge и IMCE. Затем качаем дистрибутив TinyMCE и распаковываем его в папку sites/all/libraries/. Если папки libraries не существует, то создаем ее.

Переходим к настройке Wysiwyg Управление/Настройка сайта/Wysiwyg (admin/settings/wysiwyg) и привязываем формат ввода «Full HTML» к редактору TinyMCE. После привязки, напротив формата ввода «Full HTML» появится кнопка «Изменить», кликаем по ней, переходя в раздел подключения кнопок и модулей.

Разворачиваем выпадающий список «Buttons and plugins» и отмечаем как минимум пункты «Image» и «IMCE». Можно сразу выбрать и другие кнопки, которые будут отображаться в визуальном редакторе, например «Bold», «Italic», «Underline». Сохраняем.

Теперь при создании ноды при выборе формата ввода «Full HTML» будет отображаться визуальный редактор TinyMCE. Для загрузки картинки с компьютера на сервер кликните на пиктограмму с деревом, появится диалоговое окошко для загрузки изображения, где вы также можете указать альтернативный текст, позиционирование относительно текста, вертикальный и горизонтальный отступы и размер рамки.

И проверьте в файле page.tpl.php вашей темы наличие строчки <?php print $closure ?> до закрывающего тега </body>. В противном случае визуальный редактор не будет отображаться.

PS
Выбор директории для сохранения файлов указывается в настройках модуля IMCE, но только в пределах папки, определенной по умолчанию в Drupal (sites/default/files/). Изменить ее можно в Управление/Настройка сайта/Файловая система (admin/settings/file-system). Я иногда для хранения файлов создаю отдельную папку files в корне сайта, но это уже личное дело каждого.

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

Лично я не зациклен на постоянном обновлении Drupal в пределах одной ветки, если поставил Drupal 6.14 или 6.15, то так и буду держать на нем сайт, несмотря на то, что сейчас актуальной версией является 6.16. Конечно, если в новой версии фиксится какой-то значительный баг, то обновиться стоит, а так обновление ради обновления, ИМХО, не имеет особого смысла. Какие баги пофиксились в последней версии, можно посмотреть на официальном сайте Drupal.

Также не советую и использовать пока для сайтов семерку, на то она и альфа версия. Хотя поиграться на локалхосте стоит. Сам, признаюсь, еще не ставил, но уже то, что дистрибутив семерки весит больше шестерки аж в два раза, говорит о многом.

Если же вы сидите на 5.xx, то настоятельно рекомендую обновиться до шестой версии, несмотря на то, что пятерка тоже постоянно обновляется (на текущий момент последней стабильной версией является 5.22, релиз был с месяц назад).

Инструкция по обновлению с Drupal 5.xx до Drupal 6.xx.

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

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

• Установите тему по умолчанию Garland. Также не забывайте, что тема, созданная под Drupal 5.xx, не будет работать под Drupal 6.xx. Заранее убедитесь в наличии версии нужного шаблона под шестую версию или, если тема уникальная, готовьтесь натягивать ее на Друпал по новой.

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

• Скачайте последнюю стабильную версию Drupal и файл перевода к нему.

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

• Почитайте документацию к модулям, возможно для каких-то из них предусмотрено специфическое обновление. Вся нужная информация обычно содержится в файлах readme.txt или upgrade.txt в папке модуля. Я же обычно не уделяю этому внимание, а иду читать инструкции только когда что-то начинает работать не так. Подход неправильный, стараюсь исправляться)

• Сохраните файлы из старых модулей, которые вы модифицировали, в папку с новой версией модуля. Обычно это только файлик i18n-ascii.txt модуля pathauto.

• Сохраните файлы .htaccess и robots.txt, если конечно вы вносили в них изменения.

• Сохраните папки files и sites. К слову, папки files в корне может и не быть, т.к. вообще стандартная папка в Drupal для хранения файлов это sites/default/files. Хотя я советую не копировать всю папку sites целиком, а сохранить только необходимые из нее файлы и папки. Это, как уже говорилось выше, папка files (если она содержит какие-то нужные файлы, а не создана автоматически и не является пустой) и файл настроек settings.php, т.к. в случае если сайт является старым, вы экспериментировали с различными модулями и т.д., папка sites может быть забита различным ненужным мусором, который вряд ли когда-то понадобится. Также не забудьте сохранить все созданные вручную папки и не являющиеся системными (например, папку с вашими шаблонами оформления).

• Удалите с хостинга все системные папки и файлы Drupal. Т.е. по сути надо удалить все, включая файл index.php.

• Залейте на хостинг новые системные файлы Drupal из скаченного дистрибутива. Скопируйте обратно на хостинг ранее сохраненные папки и файлы (файл settings.php обязательно).

• Запустите файл update.php, для этого наберите в адресной строке http://site.ru/update.php. При этом вы должны быть все еще залогинены как администратор (хотя все файлы сайта удалялись и заливались новые, сессия админа все еще действительна). Следуйте инструкциям (в большинстве случаев надо нажимать только «далее»). В выпадающих списках с цифрами выбирайте наибольшую (номер обновления).

• Залейте в папку modules ранее скаченные дополнительные модули, активируйте их и снова запустите файл update.php.

• Импортируйте новый файл перевода.

• Проверьте все настройки (настройки модулей, права доступа и т.д.) и отображение сайта, сравните с настройками старой версии сайта (который в идеале должен быть у вас запущен параллельно на локалхосте).

• Снимите сайт с обслуживания.

Мда, как-то длинновато получилось. Ладно, если в сжатом виде, то:

• Сохраните на компьютер все пользовательские папки с файлами и конфигурационный файл settings.php.
• Установите тему Garland и отключите все дополнительные модули.
• Удалите все системные папки и файлы и залейте на их место новые.
• Скопируйте обратно файл settings.php и сохраненные папки.
• Запустите файл update.php и следуйте инструкциям.
• Удалите старые модули, залейте новые, запустите update.php.

PS

Добавил еще одну рубрику на блоге, “Drupal”. При создании сайтов чаще всего отдаю предпочтение именно этой CMS, следовательно и посты про Drupal будут появляться регулярно, и правильнее было бы выделить их в отдельную рубрику.

Решил запустить марафон «СДЛ. От идеи до прибыли.».

Сателлиты более не интересны, новые не делаю и постепенно избавляюсь от старых. Теперь СДЛ и только СДЛ (ну, не считая дорвеев, но их в расчет не берем).

Сейчас перманентно занимаюсь сразу несколькими сайтами и подумал, почему бы не описывать в блоге создание «от и до» одного из них. В этом, собственно, и заключается весь смысл марафона «СДЛ. От идеи до прибыли.».

Таким образом, в течение нескольких месяцев будет опубликована серия постов, в каждом из которых рассмотрится тот или иной этап создания, раскрутки и монетизации сайта. Примерные тематики будущих постов такие:

• Тематика и концепция.
• Домен, логотип.
• Семантическое ядро.
• Структура сайта.
• Техническая реализация.
• Источники контента.
• Разработка дизайна.
• Продвижение сайта.
• Создание форума.
• Монетизация проекта.

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

Марафон будет считаться завершенным тогда, когда сайт возьмет топ-10 Яндекса не менее чем по 70% продвигаемых запросов, и когда прибыль с сайта составит не менее 500$ в месяц.

Я сторонник красивого и оптимизированного кода, хоть и не всегда у меня получается следовать всем правилам «хорошего тона» в программировании.

Сейчас же речь пойдет о правильном использовании двойных и одинарных кавычек в php. Перед тем, как начать писать пост, я бегло просмотрел имеющиеся у меня книги по php, и, что странно, ни в одной не увидел правильного использования кавычек. Почему – для меня загадка. Обвинять авторов в дилетантстве нет ни малейшей возможности, книги далеко не для «чайников». Может быть просто не хотели акцентировать на этом внимание, дескать кому надо, тот сам разберется.

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

Следовательно, если нам надо вывести текст «как есть», то используем одинарные кавычки. Если необходимо подставить вместо переменной ее значение – двойные (если переменная только одна, то кавычки можно и вовсе опустить). Часто можно встретить такой код:

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

Рассмотрим тривиальную задачу вывода переменной в составе текста, в том числе и с использованием html кода.

Все выводится хорошо, текст и выделенная жирным дата, которая подставляется вместо переменной. Но необходимо помнить две вещи. Первое, это особенность интерпретатора: конкатенация строк происходим намного быстрее и требует меньше ресурсов, нежели синтаксический анализ строк. И второе - не стоит забывать про парадигму программирования «разделяй и властвуй». Не надо мешать все в одно, гораздо правильнее будет разделить текст на две части – требующую и не требующую парсинга интерпретатором. Таким образом, пример выше стоит записать так:

Естественно, следовать этому правилу (заключать все, что не требует парсинга, в одинарные кавычки) надо не только при выводе текста, но и при присвоении значений строковым переменным:

Или, например, при использовании строк при передаче аргументов функции:

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

Не писал ежемесячных итогов последние четыре месяца, т.к. перестал писать в блог вообще. Сейчас вернулся, следовательно и отчитываться тоже надо.

Расписывать доход/расход детально нет никакого желания. Все те же копейки. В среднем, около 200 рублей в сутки, хотя сейчас спустился до 130-140. Падение в основном связано с тем, что начал избавляться от всякого рода ГС, приносящих несколько рублей в день. В ближайшее время доход, скорее всего, просядет еще больше, решил на днях удалить из сапы и оставшиеся сателлиты.

Резкий рост дохода должен начаться через месяц-два-три, когда доделаю СДЛ-ли и начну их потихоньку монетизировать.

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

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

Наконец-то обновился с Drupal 5 до Drupal 6, плюс почистил базу (мягко сказать удивился, когда обнаружил, что база весит аж 24 метра, как оказалось, 16 метров приходится на 100500 спамных комментариев в гостевой книге, модуль которой я когда-то поставил, а выключить забыл, а 5 метров занимала таблица с логами системных событий).

Сменил дизайн. Не шедевр, конечно, но, ИМХО, всяко лучше предыдущего шаблона. Рисовать старался без всяких изысков, максимально простым и удобным.

Чуток подправил форму комментирования, чтобы занимала меньше места. Прикрутил Gravatar. Больше вроде особых изменений не вносил.

Решил сменить тематику блога. Теперь он называется не «Работа в интернете», а «Блог вебмастера», т.к. упор все-таки хочется делать на девелоперство. Про сео, партнерки и прочее писать естественно не перестану, конечной ведь целью все равно является зарабатывание денег, иначе какой смысл делать сайты. Только все это сео надо бы отодвинуть на второй план, слишком уж многие на нем зациклились, забывая, что оно является лишь средством монетизации проекта. Но чтобы сайт монетизировать, этот сайт для начала надо сделать, а не пытаться заработать на воздухе раскручивая сателлиты и прочие гс.

В связи с чем к и так уже разросшемуся списку рубрик решил добавить еще несколько:

• (X)HTML/CSS – верстка;
• JavaScript/Ajax – а ведь ява скрипт стремительно набирает обороты, чего стоит хотя бы библиотека jQuery, которой и четырех лет нет, ну а Ajax это отдельный разговор, сейчас уже трудно встретить крупный веб-проект без его использования;
• Дорвеи – таки да, несмотря на не совсем удачный опыт дорвеестроительста, заниматься я ими не перестану, это интересно, как в плане программирования, так и в плане seo;
• Дизайн – долго думал, создавать эту рубрику или нет, решил создать, т.к. хороший дизайн вещь дорогая и порой является просто непозволительной роскошью, а всякие фри шаблоны это удел по большей степени сателлитов, поэтому навык рисования простеньких дизов для своих проектов лишним всяко не будет.

Дописывая этот пост, также решил и удалить пару разделов – это «форекс» и «ссылки». Форексом заниматься всякое желание пропало, заместо него пришло новые увлечение – покер, но под него у меня отдельный блог. Ну а смысла в разделе «ссылки» когда есть раздел «seo» никакого нет. Посты не пропали, раскидал их по другим подходящим рубрикам.

Назвать меня игроманом сложно, уже как несколько лет на компьютере начисто отсутствует ранее стандартная папка Games. Хотя в стародавние времена, стоит признать, мог убить несколько дней на Козаков, NFS, GTA, Готику, Call of Duty, Unreal Tournament, Warcraft и т.д.

И вот несколько месяцев назад на одном из форумов, где обсуждался Google Wave и тенденции к отказу от десктопного софта в пользу веб сервисов, наткнулся на ссылку на сайт quakelive.com.

Я никогда не был ярым поклонником Quake, но, тем не менее, решил зарегистрироваться, т.к. интересно было посмотреть, как из Quake III Arena смогли сделать браузерную игру. Впрочем, полностью браузерной ее назвать сложно, надо сначала скачать плагин для браузера, который в свою очередь выкачает аж 300 метров требуемых файлов.

Подсел буквально сразу. Это было то, чего мне так не хватало – возможности поиграть 20-30 минут в какой-нибудь шутер, качество которого не отличалось бы от качества аналогичных компьютерных игр, и при этом отсутствовала бы необходимости устанавливать тяжеловесную игрушку и настраивать ее для подключения к игровым серверам. Теперь достаточно только залогиниться на сайте, и можно сразу начинать играть на любой из десятков карт с живыми соперниками.

По материалам википедии:
С 24 февраля 2009 года начато открытое бета-тестирование игры. За первые шесть часов с момента начала регистрации игроков, желающих принять участие в этом бета-тестировании, было создано 113 тыс. учётных записей. К ноябрю 2009 года было зарегистрировано более 1 000 000 пользователей.

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

За все время моей деятельности в интернет, пусть пока и не очень успешной, точка зрения по поводу того, как выбирать тематику для создания СДЛ, у меня успела поменяться не раз. В этом посте постараюсь сформулировать свои мысли по поводу процесса выбора тематики для создания СДЛ на данный момент.

Выбор общей тематики
Ну, тут все неизменно. Сайты стоит делать по той тематике, которая вам близка и которую вы хорошо знаете, ведь как ни как, а заполнять сайт, писать статьи и т.д. придется именно вам. Правда, не редко бывает и так, что сфера интересов ну никак не пересекается с чем-то коммерческим или популярным, а делать сайт, интересный только вам и, быть может, небольшой группе людей, не имеет никакого смысла. Здесь уже придется подумать над выбором темы, которая вам не особо и близка, но, главное, в которой вы хотите и можете разобраться, без этого никак. Брать тему, которая и популярная, и коммерческая, и вроде конкурентов по ней мало, но которая вам претит – глупая затея. Да, для MFA самое то, но не для СДЛ. В СДЛ главное хотеть развивать ресурс, в первую очередь потому что вам это интересно.

Семантическое ядро
Да, таки пришел к пониманию того, что начинать делать СДЛ надо именно с составления семантического ядра и последующей внутренней оптимизации. Если раньше я не видел четкой зависимости между созданием сайта и запросами, по которым он будет продвигаться, то теперь уже отталкиваюсь от такой схемы – есть интересная тематика, составляем под нее список запросов, под эти запросы делаем сайт. Если кратко – нет смысла делать сайт ради сайта, необходимо уже заранее четко понимать, что его придется выводить в топ10 по группе запросов. Если же раскручивать сайт в поисковиках не планируется, зачем вообще тогда его создавать? Ради удовольствия? Под сапу? Ведь сайт-то мы делаем, в конечно счете, ради денег. А деньги это трафик. Не думая заранее о позициях, не думаем о трафике, а значит не думаем и о деньгах, теряя таким образом основную нашу цель создания СДЛ, и в итоге сам процесс становится бессмысленным убийством времени.

Качество
Это, наверно, главный пункт. Причем на который практически никто не обращает внимание. Как было сказано выше, еще до создания сайта мы должны иметь хотя бы частично сформированное семантическое ядро и четко понимать, что нам придется выводить сайт в топ по всем нашим запросам. Поэтому стоит изначально изучить лидеров тематики, весь топ10 по каждому запросу. Сможете ли вы сделать сайт более качественным и интересным, чем уже представленные в топе? Если нет, то от этой тематики придется отказаться, ибо нет смысла раскручивать то, что не идет ни в какое сравнение с уже существующими сайтами. Наша цель – создать сайт, который потенциально станет лидером в своей нише, ну или как минимум твердым середнячком. Обычно такая процедура сравнивания своего будущего детища с уже существующими сайтами сильно отрезвляет, начинаешь понимать, что все сделанные в прошлом «СДЛ» были СДЛ только для тебя одного, а на самом деле являлись не более чем ГС.

Конкуренция
Многие боятся конкуренции, засилия старых трастовых сайтов в топе, высокими потенциальными затратами на достижение топа. Но стоит ли выбирать тематику более простую? Я думаю, что нет. Поиски простых путей обычно мало к чему приводят. Поэтому, если даже выбранная тематика кажется очень сложной, но вы можете сделать сайт, удовлетворяющий предыдущему пункту, то почему бы и нет? А деньги для раскрутки сайта можно будет черпать с прибыли этого же сайта. В конечном счете, чем труднее поставленная цель, тем интереснее ее достижение.

Окупаемость
Еще один концептуальный момент при выборе тематики для СДЛ. Отобьются ли вложения? Не останется ли сайт убыточным даже по достижению топа по всем запросам? Эти и другие аналогичные вопросы появляются сразу же, как только приходится вкладывать в проект не только свое время, но и деньги. Раньше я считал потенциальный трафик, который я получу, если войду в топ10, смотрел биды в контексте по основным ключам, рассчитывал, сколько я смогу заработать на сапе и какие для этого понадобятся пузомерки и т.д. Т.е. пытался решить проблему прибыльности еще не существующего и не раскрученного ресурса. Глупо? Да, глупо. Теперь я поступаю намного проще, а самое простое решение, как известно, частенько оказывается и самым правильным. Я смотрю все сайты из топ10 по всем основным запросам. Если среди них большинство сайтов-визиток, интернет представительств оффлайнового биза, интернет магазины и прочее – я больше не возвращаюсь к этой тематике. Если же практически все сайты являются контентными проектами, на которых висит контекст, какие-то баннеры, может созданы партнерские разделы, продаются ссылки или статьи и т.д., то это однозначно говорит о том, что окупать затраты на продвижение и при этом получать прибыль только за счет размещения рекламы более чем реально, и эта тематика нам подходит. За счет чего в итоге будем окупать затраты мы – не суть важно, главное, что такая возможность имеется, так что вопрос монетизации ресурса может быть закрытым до тех пор, пока у нас уже не будет готов проект, имеющий уже некоторые количество трафика.

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