Война продолжается
С начала активных боевых действий против попингуев прошло уже достаточно много времени. Я, честно говоря, ожидал гораздо большей активности со стороны пользователей да и самого автора скрипта блога. Однако ж тишина... Может это только мне попингуи доставляют неудобства?
Ладно, речь не о том. Я считаю попингуйство злом и намерен продолжать с ним бороться.
Предыдущая версия "Привратника" работала довольно сносно, но, к сожалению, не долго - создатели "пингуляторов" быстро поняли свои ошибки и приняли меры. Теперь простой анализ частоты хитов уже не помогает. Что ж, значит пришло время сделать выводы и пересмотреть стратегию.
Чуть более недели назад старый "Привратник" на этом сайте был списан на пенсию и его место занял новый, переписанный заново и использующий совершенно новый подход. Теперь он не смотрит ни на IP-адрес посетителя, ни на его юзер-агент, ни на все остальные "атрибуты" - это просто не нужно.
Вместо этого он выкачивает страницу, с которой якобы пришел посетитель и пытается найти в ее коде ссылку на запрашиваемую страницу. Ежели нашел - значит все в порядке и можно пропускать хит дальше в блог. Ну а если ссылку обнаружить не удалось, то попингуй получает болт калибра 404, а блог даже не подозревает, что кто-то пытался на него зайти.
Неделю скрипт работал в тестовом режиме - ничего реально не делал, лишь подробно описывал в логах свои мечты и желания - кого он признал "живым", а кого с удовольствием послал бы на три веселых цифры. Анализ этого лога позволил выявить некоторые недочеты и ошибки, внести исправления и, наконец, сегодня дать таки ему право безжалостно херить всех неугодных.
Итак, начат второй этап тестирования. Для чистоты эксперимента статистика блога (уже в который раз) была обнулена и снова выставлены на общий обзор "друзья сайта". Любуйтесь, комментируйте. Самые активные смогут первыми получить сей скрипт в свое распоряжение.
Дополнение от 5 июня.
Сегодня обнаружил досадную ошибку в скрипте - он добросовестно определял попингуйские сайты, но по-привычке никаких мер по присечению их деятельности не предпринимал. 
Сейчас положение исправлено, но пришлось снова очистить статистику... 
Идея глобального контента
Как хранить данные в БД? Этот вопрос рано или поздно встает перед любым проектировщиком сайта.
По теме проектирования баз данных написано множество книг и статей, но все они содержат больше технической информации (описания систем индексации, поиска и связывания таблиц) и предлагают дробить всю информацию на множество таблиц, не забыв склеить все это в тугой узел с помощью связей (relations) и зависимостей.
Но всегда ли это оптимально? Так ли сильно отличаются наборы хранимой информации для разных видов контента? Давайте рассмотрим, какую информацию хранят в БД "типовые" виды контента сайтов.
Статичная страница.
Это страница, содержащая некоторую полезную для посетителя информацию, которая очень редко (или вообще никогда) не изменяется. Список полей-атрибутов этого вида контента:
- Уникальный идентификатор (id) - куда ж без него?
- Идентификатор родительского элемента сайта (parent_id - мы же строим иерархическую систему)
- Заголовок (title)
- Описание (description)
- Краткое содержание (summary - используется в качестве анонса)
- Собственно текст старницы (content)
- Ключевые слова (keywords)
- Идентификатор автора (user_id)
- Дата создания (created)
- Дата последнего изменения (modified)
- Флаг опубликованности (published)
- Идентификатор логического раздела (category)
Вроде ничего не забыл....
Статья в блоге.
Представляет собой обычную статичную страницу, но еще предоставляет возможность пользователям оставлять комментарии. Соответственно набор полей тот же, что и у статической страницы.
Комментарий к статье блога.
В плане хранения информации, отличия от статичной страницы минимальны. Список полей:
- Уникальный идентификатор (id)
- Идентификатор статьи с в блоге, к которой относится данный комментарий (parent_id)
- Заголовок (title)
- Собственно текст (content)
- Идентификатор автора (user_id)
- Дата создания (created)
- Флаг промодерированности (published)
Как видим, поля всё теже, что и для статичной страницы, отличие лишь в количестве.
Пост в форуме.
Полностью совпадает со статической страницей.
Ответ к посту в форуме.
Полностью совпадает с комментарием к статье блога.
Запись в новостной ленте.
Полностью совпадает со статической страницей. Лишь будет иметь одно дополнительное поле:
- Дата, начиная с которой новость уже не актуальна (expiried)
Товар в магазине.
Используются все теже поля, что и для записи в новостях, но с небольшими дополнениями:
- цена единицы товара (price)
- количество товара на складе (number)
- картинка товара, лишь для удобства - никто не запрещает ее вставить в само описание товара (image)
Итог.
Проанализировав описанное выше, можно легко сделать вывод, что при проектировании CMF логично создать всего одну (большую) универсальную таблицу в базе данных для хранения практически любого вида контента. При этом для разработчиков модулей можно упростить многие рутинные операции, такие как, программирование ввода одних и тех же данных в разных модулях (created, modified, title, decsription, keywords и т.д.). Разработчику модуля нужно лишь сообщить системе, какие именно поля будет использовать его модуль и система сама сможет создать все необходимые формы для ввода/редактирования данных, с необходимой валидацией.
Так же этот вариант хранения данных позволяет сделать "прозрачную индексацию" - поскольку система имеет доступ ко всему контенту (и что важно - ей не нужно для получения контента обращаться к модулям, его создавшим!), то она запросто может сканировать его и строить необходимые для реализации поиска по сайту таблицы.
Сюда же стоит отнести и возможность отслеживания обновления контента без участия системы оповещения (событий), а так же и решение многих проблем, связанных с кэшированием.
Да и работать оно должно веселее, т.к. БД постоянно будет использовать одну таблицу, а значит часть ее всегда будет торчать в памяти (кэше), соответственно запросы должны выполняться гораздо быстрее...
Евровидение - 2009
Только что посмотрел первый полу-финал конкурса "Евровидение - 2009". Обычно такие вещи не смотрю, в виду полного отсутствия интереса к мероприятиям подобного типа, но сегодня пришлось - мать просила записать конкурс.
Мне, как технарю по натуре и как экс-оператору/монтажеру-свадебщику, шибко понравилась операторско-режиссерская работа. Летающая между исполнителями камера произведа весьма позитивное впечатление. Так же, как и нагромождение огромных слегка летающих экранов и то, что по большей части на этих экранах отображалось. 
Правда были и такие моменты, когда изображение на экранах практически сливалось с костюмами участников, отчего последних найти на сцене было не так-то просто - этакие замаскировавшиеся партизаны. Но может так и было задумано?...
К сожалению на телевизоре узреть всю прелесть и масштабность оформления не удается. Я только к середине программы заметил, что огромное кольцо из полукруглых экранов (прямо над головами исполнителей) время от времени меняет свою "конфигурацию". 
Что же касается самих исполнителей, тут я патриотизмом не отличусь - мне больше всех понравилась исландия (на фото) - симпатичная блондиночка с приятным голосом и миленькой песенкой. Еще, на мой взгляд, очень хорошо выступил коллектив из Армении. Остальные впечатления не произвели - все какое-то посредственное и не интересное.
А вы что думаете?
