3D
Обзор Worms 3D на ag.ru, 2003 год
(еще 140 слов)
Knowledge base
Не так давно мы с вами — а верней я — рассуждал о блогах и пришел к неутешительному выводу, что бытие определяет сознание, the medium is the message, а блог — «это та ерунда, которая получилась после массовой реализации возможности быстрой и легкой публикации заметок на „домашних страничках“».
Блог — всего лишь одна из форм организации контента, просто форма не особо удачная, да и контент подходящий — сиюминутные ремарки о-чем-вижу-о-том-и-пою, иными словами — «чем удобряли, то и выросло».
Есть и другие жанры. Про один из таких жанров — назову его условно knowledge base — и я хочу немного поговорить.
Рано или поздно, создавая контент, который востребован и не теряет актуальности со временем (или теряет, но не так быстро, как, например, новости), мы начинаем понимать две простые вещи:
1. В тематике контента обнаруживаются закономерности и между разными документами можно провести некие семантические связи. Как это будет реализовано — ключевые слова, категории, рубрики, «смотрите также», хитроумные костыли для ЖЖ — не важно.
2. Так как материал устаревает медленно, время написания и вообще сортировка по времени написания по большому счету теряет смысл.
Переписав текст про ЧПУ, который оставался актуальным четыре года(!), и сделаев его совсем up-to-date, а так же написав текст о том, что же такое блог и использовав при этом наброски из «Регистра», я придумал вот что:
Документы в Сети не обязаны быть статичными. Но даже динамичный блог — это куча статичных заметочек, а когда нам нужно развить тему, мы просто пишем еще одну заметку. Иногда это оправдано, иногда — нет. Но почему-то все всегда (или почти всегда) забывают о том, что текст-то — электронный, поэтому его можно просто дописать или переписать.
Влад Головач предлагает всячески чистить архивы блога, удаляя ненужную и устаревшую информацию. Но — тогда это уже будет не блог, и вообще Влад говорит, что «хитрость в том, чтобы изменить магистральное направление блога в прошлое (которого как минимум больше)». Совершенно верно. Но есть нюанс.
Знаете, почему когда нужно продолжить тему в блоге, то об этом пишется новая заметка (в которой пусть даже и ставятся ссылки или ключевые слова, линкующие ее с предыдущими по теме)? Да потому, что новая заметка всегда сверху.
А сверху она потому, что она новая.
Но нам ничего не мешает сделать такой сайт, на котором мы будем развивать круг тем не только добавляя новые документы и связывая их со старыми, но и редактируя старые, при этом сортируя документы не по дате написания, а по дате обновления.
Выглядит это так: есть рубрикация по темам. В каждой теме есть три блока документов:
Первый — основополагающий/темообразующий документ/документы. Основной документ, раскрывающий тему и постоянно обновляющийся.
Второй — исходный материал, тот сор, из которого вырастает темообразующий блок документов.
Например, темообразующий документ: /entry/2196
Исходный/черновой материал: http://nudnik.ru/keys/blogs
Третий — устаревшие/архивные материалы, в том числе и предыдущие версии темообразующих документов.
Пользователю же при первом знакомстве всегда подсовывается темообразующий блок. Например, если я пишу в блоге заметку — ну, скажем, «еще один способ сделать ЧПУ», — то человек, который не знает, что это такое, вынужден идти по ключевым словам и узнавать.
Если же делать knowledge base, то пользователь видит, что обновилась/завелась тема ЧПУ и когда он в нее заходит, то ему не вываливается «а вот все, что у меня есть про ЧПУ, разбирайся и сортируй сам».
Кстати, когда я писал диплом, у меня была бредовая идея сделать его в виде гипертекста, основной корпус диплома сделать в виде, скажем, пятистраничного текста, который кратко, но по существу передает все содержание диплома, и в котором в ключевых местах понатыканы ссылки [show me more]. Грубо говоря, человек, который читал бы диплом, смог бы углубиться в него в любом месте и на любой уровень.
Представьте, если бы каждый абзац можно было бы расширить на страницу, а в свою очередь каждый абзац там — еще на страницу.
Вот, примерно так. Самое смешное, что это придумано сто лет назад и называется гипертекстом. Проблема в том, что почти все реализации гипертекста выходили не очень-то удачными, да и создавать полноценный гипертекст гораздо сложнее, чем простой текст.
Еще я хотел что-то хорошее написать про Wako Wiki, ибо это – инструмент, заточенный помимо всего прочего и на редактирование документов, а не на добавление новых (как блог). Проблема с Wiki только одна – на мой взгляд – там все – как бы сказать – кишками наружу, что ли. То есть, система ориентирована на писателя или на коллектив писателей, — что идеально подходит для совместного творчества, организации совместной работы над документами или для индивидуальный вещей, — таких как ToDo, например, но не очень-то ориентирована на простого читателя, которому очень много вещей просто не надо видеть.
Вот, пожалуй и все.
Проект существует с 1997 года
А еще мне очень интересно, почему Лебедев пишет на своем Руководстве «Проект существует с 1997 года»? Я понимаю, что «Copyright © 1997—2003» смотрится очень красиво.
(еще 120 слов)
ЧПУ и PHP (revisited)
ЧПУ — это термин, придуманный командой НовоКиберска, обозначает он «Человекопонятный УРЛ». Термин нигде широко не употреблялся, пока я не написал 5 сентября 2000 года заметку «ЧПУ и PHP». За эти три года термин довольно неплохо раскрутился.
За эти годы очень многие ссылались на эту заметку, поэтому я взял на себя труд переписать ее, добавив еще несколько способов сделать ЧПУ и убрав всякий мусор. Итак...
В принципе, ничего нового и оригинального в идее понятного УРЛа нет. Про это писал и Лебедев, и другие товарищи. Вообще, мне всегда нравились УРЛы такого, например, вида: php.resourceindex.com/Complete_Scripts/Guestbooks/
Итак, как это сделать в домашних условиях?
Способ раз
Вообще, самая первая мысль — это создавать для каждой заметки поддиректорию с соответствующим именем и помещать в нее index.html, то есть сделать так, чтобы по адресу spectator.ru/technology/php/user_friendly_urls лежал бы реальный файл. Разумеется, так дело не пойдет.
Способ два
Думаем дальше. Раз страница не существует, то она выдает 404. Так что вторая идея — прописать в фале .htaccess страницу, которая будет выдаваться при ошибке 404, а уже эта страница будет смотреть на текущий УРЛ и выдавать нужный документ
То есть, в .htaccess пишем:
------------------------------------
ErrorDocument 404 /index.php3
ErrorDocument 401 /index.php3
------------------------------------
Пользователь набирает spectator.ru/technology/php/user_friendly_urls, такая страница не найдена, и загружается файл index.php3. Дальше — все просто. Переменная $REQUEST_URI дает нам адрес вызываемой страницы (в данном случае это будет /technology/php/user_friendly_urls), вывести на экран соответствующий документ — дело техники.
Этого мало. В некоторых браузерах и с поисковиками такой фокус не пройдет: страница 404 будет выдавать соответствующий код, и страницы индексироваться не будут. Поэтому надо, чтобы страница, которая грузится в случае ошибки 404, изменяла бы код ошибки и сигналила, мол, все ОК, есть такая страница:
Итого: прописываем в .htaccess страницу, которая, собственно, за все отвечает (у меня это index.php3). В этой странице пишем php-скрипт, который работает с $REQUEST_URI, шлет заголовок «http/1.0 200 Ok» и отображает то, что надо.
Плюсы: Очень простой способ. Работает почти везде.
Минусы: При таком способе нельзя постить содержимое формы на несуществующие псевдоурлы. И если в Апаче ведется лог 404-ых ошибок, то он будет забит.
Способ три
Для этих (и не только) целей есть специальный модуль в Апаче, который называется mod_rewrite. Он позволяет «переписывывать урлы», то есть, преобразовывать их «на лету» по правилам, которые вы ему опишите.
Это очень мощный модуль, и если вы в нем разберетесь, то сможете творить чудеса. Сам я до сих пор довольно мало с ним работал, поэтому читайте документацию, благо, что ее полно.
Module mod_rewrite URL Rewriting Engine.
A Users Guide to URL Rewriting with the Apache Webserver.
Модуль Apache mod_rewrite.
Mod_rewrite для чайников.
Плюсы: Очень мощный способ.
Минусы: Может не хватить мозгов. На хостинге может быть не установлен этот модуль.
Способ четыре
Основан на директиве FilesMatch, которая в Апаче является core feature. Все просто. Пишем опять же в .htaccess
Action throw /index.php
ForceType throw
ForceType application/x-httpd-php
После этого все УРЛы, которые подпадают под условие «^([^.]+)$», (то есть все урлы, в которых не содержится точка) будут передаваться на index.php. Вы можете написать свое условие, разумеется.
Подробности: тут, тут или тут.
Плюсы: Простой и удобный способ.
Минусы: Говорят, что для того, чтобы ForceType работал, php должен быть подключен к апачу в виде модуля. Если php вызывается, как обыкновенный CGI — ForceType работать не будет.