Как часто в последнее время приходится читать фразы в стиле:

"[...] И, все-таки, мы решили перейти от иерархических классификаторов к облакам тегов. Это позволит нашим пользователям [...]"

Закономерность? Эволюция? Заблуждение?

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

• Фолксономическая категоризация: блог, топка, интернет, каталог, поисковые системы.
• Таксономическая категоризация: Интернет - Персональные страницы - Блоги - Блоги о поисковых системах.

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

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

В каждом из подходов есть свои плюсы. Так почему бы их не объединить и не использовать одновременно? Я не вижу ничего плохого в том, что, например, в каталоге, помимо строго определенных иерархических рубрик, пользователи, регистрирующие сайты, указывали бы и некоторые метки (теги, ключевые слова - назовите это как угодно).

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

Недавно взглянул на график загрузки процессора хостинговой компании приложениями моего аккаунта и оказалось, что я отъедаю в среднем 5% времени процессора.

Думал каким образом лучше/проще снизить нагрузку на сервер на котором будет работать новый каталог. Одни из наиболее трудных и тяжелых запросов: получение дерева разделов каталога. Можно, конечно, реализовать иначе: уйти от структуры "id-parentid" и перейти к вложенным множествам (nested sets), но было решено все же оставить id-pid, т.к. уж слишком много на этом завязано.

Нагрузку же снижать следующим образом: подгружать иерархическое дерево разделов по требованию (ведь, если задуматься, действительно: "Зачем пользователю постоянно видеть иерархию разделов? Если она ему нужна, пусть перейдет по ссылке и получит необходимую информацию.")

Таким образом сэкономил 3 операции: получение backStack'а разделов (хлебных крошек), получение подразделов текущего раздела, получение корневых разделов. Думаю что бы еще на AJAX-запросы по требованию перенести.

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

Заходит пользователь в каталог. Переходит на страницу регистрации ресурса. Его встречает некий интеллектуальный модуль Порфирий Петрович, специалист по регистрации интернет-ресурсов, и предлагает оформить заявочку на регистрацию сайта. Заявочка заполняется, Порфирий "снимает" 2 копии, одну из них относит специалисту по анализу гипертекстовых документов - Николаю Анатольевичу, а вторую - Алексею Данилычу, специалисту по цензуре. После проведения анализа Анатолич и Данилыч формируют соответствующие заключения о доступности сайта, показатели его релевантности, содержании бранных выражений и относят их назад - Петровичу. Петрович формирует заключение и сообщает пользователю о возможности публикации ресурса: регистрирует его или отклоняет заявочку.

Красота...

"Do The Simplest Thing That Could Possibly Work" или Как хорошая идея превращается в проблему.

Почему некоторые вещи реализуются, мягко говоря, через задницу?

Последнее из подобного, с чем пришлось столкнуться: реализация билинга у провайдера Webstream, который рвет соединение каждый месяц в 0:00 для того, чтобы считать трафик за новый месяц заново (то есть с нуля мегабайт/рублей). Неужели нельзя было это реализовать программно на другом уровне? Хотя, зачем вся эта "движуха": хуйнули соединение и считаем заново.

Предлагаю идею: рвать соединение подобным образом после наступления льготного времени (вечером более дешевый тариф, стоимость трафика иная) и еще каждые сутки, тоже в 0:00 (ведь так будет проще считать статистику за сутки). Резюме: маразм.

Вот так и люди: рождаются, живут и умирают.

Один из возможных вариантов: создать разделы, ассоциированные с этим контентом, например:

• Порнография
  • Геи, лесбиянки и бисексуалы
  • Жесткое порно
  • и т.п...,

а контент, добавляемый в эти разделы, помечать специальным образом и не показывать (посетителям или поисковикам, защищая его, при помощи HTTP-заголовков, например HTTP 404 Not Found).

На прошлой неделе был написан код для получения Google PR.

• Исходный текст граббера PageRank на PHP.
• Документация к исходнику.
• Ветка на форуме Xpoint, посвященная этой проблеме.

Заголовок исходного файла:

/**
* Google Page rank data grabber.
* Based on Google toolbar data.
*
* Working with data like that:
* "Rank_1:1:6". Without XML/HTML parsing.
*
* @important:
* This code is for cognitive purposes only.
* Usage of this code is against Google's terms of service.
* No support is provided for this code.
* Can be used "as is" for your own risk.
*
* @requirements:
* - PHP version 5 (can easily be downgraded to PHP4)
* - cURL library (but you can replace curl functions with
* PHP standard fopen/fread or other)
*
* @version 1.1
* @author exstabler // PHP version
* @author snoopy // JS version
*
* @changelog:
* - 2007-01-18:
* 1. [exstabler] Deprecated method intToHex deleted.
* 2. [exstabler] Method toHex8 corrected.
*
* @sample usage:
* $obj = new PageRankGrabber();
* $rank = $obj->getRank('http://dir.org.ru');
*/

Проведены пробы движка WordPress, произведена базовая настройка, прикручен собственный шаблон, блог запущен. Что не понравилось: отсутствует русская локализация (точнее она есть, но далеко не все сообщения переведены). Сначала уж думал запустить старый-добрый poEdit и перевести блог нормально, но потом решил, что лень -- это, все-таки, великая сила. В топку.

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