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

Кроме общепринятых title, keywords, description и alt ключевые слова и фразы можно (и нужно) разместить:

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

В имени страниц и подкаталогов сайта:
Не помешает назвать подкаталоги сайта и внутренние страницы ключевыми словами (запросами). Если предполагаемые запросы достаточно велики - сократите их в названии до 7-10 символов. Учитывайте значимость английских эквивалентов русскоязычных запросов.

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

Все те же title и description:
Не смотря на то, что практически все поисковики отказались от чтения meta keywords, не нужно забывать про title и description. Title особенно влияет на позиционирование по запросам из 2-х и более слов практически во всех ведущих поисковых системах.

При всех возможностях начинить сайт ключевыми словами "от" и "до", следует помнить о том, что в среднем процент ключевого слова в тексте не должен превышать 3-5%. На отдельных страницах сайта допустима высокая "концентрация" ключевого слова - до 15-20%. Главное - сохранить смысл текста и не превратить страницу в банальный дорвей.

Хочется отметить, что остальные 95-97% текста страницы также имеют значение для позиционирования. Поисковые системы распознают синонимы и общетематический набор слов и фраз. Поэтому фразу "домашние животные" лучше сочетать с "коты и собаки", чем с "дизайн и реклама".

С уважением, Игорь Бурцев. http://webmasterpro.com.ua/

Оглавление/Вверх

3Ds MAX

Осваиваем вид моделлинга - Surface.

    В этом уроке, как вы наверное догадались, не будет ни одного рисунка. Но ино здесь и не нужны. Так как я буду объяснять вам, как создавать модели на основе каркаса сплайнов.
    Начнём с того, что создадим сплайн нужной формы (например голова в профиль). Теперь, нужно к этому сплайну, добавлять ещё. Для этого, во вкладке Modify уже созданного сплайна, нажмите на кнопку Craete Line (кажется так). Затем нажмите кнопку s на вашей клаве. Это кнопка, активизирует кнопку 3D Snap Toggle. Но её активизации нам не достаточно, нажмите правой кнопкой мыши на 3D Snap Toggle и в появившемся окне выберите Endpoint (предварительно отключив Grid Points). Теперь, создавайте сплайны, от одной точки к другой. Но не через все точки, а только через нужные (их обычно только две). Часто, вам пригодится создавать точки без изменения сплайна. Это можно осуществить при помощи Refine. Этот способ лучше тем, что он просто создаёт в заданном месте, а его спомогательные рычаги становятся автоматически - относительно других точек. По этому, лучше использовать Refine вместо Inser.
    Когда вы закончите создавать сплайны (а они должны обводить основные черты модели), проследите, чтобы не было в образовавшихся полигонов более чем четыре точки. Если в полигоне больше четырёх или меньше трёх точек - полигон отображаться не будет. Лучше всего, если вы постораетесь делать четырёх-точечные полигоны, так как они более крассиво смотрятся...
    Если вы уже всё сделали, а остались только полигоны с >четырёх точек, то нажмите на кнопку Refine и создайте ещё точки в любом - удобном месте.
    Лично я считаю, что этот способ удобен для Mesh моделирования. В Surface как и в Patch можно изменять колическтво сегментов, благодаря этому, указав небольшое количество полигонов, можно будет преобразовать модель в Mesh, а затем применить модификатор Mesh Smooth. Это будет просто супер. Я лично видел некоторые работы, выполненные именно таким способом.
    Всего наилучшего. Ваш сис Админ...

Этот урок не последний из Surface. Позже выйдут новые. Причина - я ещё не имею опыта верстать сурфэйсные модели.

Сайфутдинов Нияз

Оглавление/Вверх

Авторизация с разделением прав доступа. (PHP+MySQL).

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

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

Впрочем, от слов к делу.

Начну издалека. Очень часто внешне одинаковые логины, на самом деле являются абсолютно (с точки зрения программирования) разными. К примеру, никнейм Вася и никнейм Bася для человеческого глаза абсолютно идентичны. Но это не так, во втором случае русская буква "Вэ" была заменена аналогом из латиницы "Би". К чему это может привести? По большому счету ни к чему, кроме того, что открывается обширное поле действий для интернет-хулиганов. И было бы логично защитить свой ресурс от таких демаршей. Чем и займемся. (Весь код предоставляется по принципу "как есть", то есть никаких гарантий на его работоспособность я не даю, и никакой ответственности за последствия его применений не несу)

Сперва создадим файл-библиотеку (дабы не усложнять читабельность кода в функциональных файлах) functions.tpl, куда и будем заносить все написанные нами функции.
Кстати, идея борьбы с "нехорошими" логинами не моя. Один мой хороший знакомый давно использует ее на своем форуме (forum.mitino.ptt.ru), как-то она была озвучена вслух, после чего и подхвачена мной. Суть в том, что в логине вырезаются все пробелы - то есть происходит его сжимание, после чего все сомнительные буквы кириллицы заменяются на аналогичные им по написанию из латиницы. Получается, что все похожие логины, созданные вышеописанным хулиганским способом, будут иметь один идентификатор. Соответственно, надо проверять, существует ли у нас в базе уже такой логин или нет, не по самому логину, а по его идентификатору.

function unikey($strinput){
$strinput=strtr($strinput,"ЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮЁ",
           "йцукенгшщзхъфывапролджэячсмитьбюё");//понижаем
//регистр (такая кривая реализация основана на том, что не всегда функция strtolower корректно работает с
//кириллицей)
$strimput=strtolower($strinput);
$strinput=trim($strinput);
$strinput=ereg_replace("[[:space:]]","", $strinput);//все пробелы удаляются (логин сжимается)
$strinput=strtr($strinput,"укензхваросмт","ykeh3xbapocmt");
//Заменяем "спорные" кириллические буквы на аналогичные из латиницы
return $strinput;//возвращаем получившийся идентификатор
}


Теперь определить идентификатор можно следующим образом: $loginuid=unikey($login).
И пока не забыли, напишем еще одну маленькую процедурочку. Поскольку, все равно нам придется использовать соединение с MySQL, было бы логичным упростить процесс коннекта. Чем и займемся:

//Соединение с мусклом
function my_connect(){
@mysql_connect("localhost","urmach","password");
@mysql_select_db("database");}

Теперь, соответственно, процесс коннекта производится процедурой my_connect();

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

Думаю, что принцип регистрации объяснять не нужно - пользователь заполняет корректно(!) все поля нажимает кнопку "Регистрировать". Нельзя упростить процесс, но и нельзя его усложнять - всю охоту отобьет у пользователя вообще регистрироваться.
Есть одна маленькая гадость, которую пользователь может совершить - это оставить некорректный почтовый адрес. Есть два способа обхода такой ситуации. Но использовать их лучше в совокупности. Перво-наперво проверим, а корректно ли записан e-mail с точки зрения синтаксиса. Ноавскидку это можно сделать следующим образом:

$proverka=ereg("([0-9]|[a-zA-Z]|@)(\.)((com$)|(ru$)|(net$))", $email);

И если адрес у нас правильный - $proverka имеет значение TRUE, если нас попытались обмануть - FALSE. Казалось бы все, чего же боле? Адрес известен, следовательно, можно продолжить регистрацию. Ан нет…не все так просто, а что если пользователь введет мыло, скажем, многострадального майкрософтовского саппорта? Ведь support@microsoft.com с точки зрения синтаксиса абсолютно правильный. Проверить, является ли указанный ящик ящиком пользователя, можно только выслав ему письмо на этот ящик с просьбой подтвердить регистрацию.

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

function sendmsg($to, $subject, $text, $from, $kodir)//кому,тема,текст письма, от кого, кодировка
{
if ($kodir==1):
$kodir="windows-1251";
else:
$kodir="koi8-r";
endif;

$header = "From: $from\nReply-To: $from\n";
$header .= "MIME-Version: 1.0\n";
$header .= "Content-Type: text/plain; charset=$kodir\n";
$header .= "Content-Transfer-Encoding: 8bit\n\n";
$header .= "$text\n";
mail($to, $subject, "", $header);
return true;
}

Вариации с кодировкой лучше всего учитывать еще при регистрации пользователя, для чего в таблице MySQL отвести одно поле, а в форме регистрации возможность выбора кодировки между windows-1251 и koi8-r.
Если выбрана windows-1251 в поле помещаем значение 1, для koi8-r - значение 0.

И раз уж разговор зашел о MySQL, привожу пример структуры таблицы users для хранения данных о пользователях:

#
# Структура таблицы users
#

CREATE TABLE users (
login char(15) NOT NULL,
pass char(15) NOT NULL,
email char(50) NOT NULL,
rass int(1) NOT NULL,
uid char(26) NOT NULL,
date_r date NOT NULL default '0000-00-00',
check_up int(1) NOT NULL,
luid char(15) NOT NULL,
UNIQUE KEY luid (luid)
)

Причем поле luid уникальное, в него записывается как раз результат выполнения функции unikey по логину.
Поле rass опционально и отвечает за то, хочет(1 - хочет,0 - нет) ли пользователь получать по почте рассылку (если таковая планируется). Поле check_up хранит информацию о том, подтвердил ли пользователь регистрацию нажатием соответствующей ссылки из письма (1 - да, 0 - нет).
А поле uid хранит уникальный идентификатор пользователя ( уже образованный не функцией от логина), который получим так:

$uid=md5(uniqid('').uniqid(''));//получим 26знаковый случайный уид

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

function autorize($login,$pass){
$er_f="";

//Обнулим флаг ошибки


if (($pass!="\r")and($login!="\r")):

//Проверка заполнены ли поля
my_connect();
$query="SELECT * FROM users WHERE login='$login';";
$result=mysql_query($query);


if (mysql_num_rows($result)!=0):
//Пользователь найден, сравним пароль


if (($pass==mysql_result($result, 0,'pass'))and(mysql_result($result, 0,'check_up')!=0)):
//Передадим кукис браузеру с идентификатором, кукис действителен в течение 5 часов
$id=mysql_result($result, 0,'uid');
//Выцепим ун.ид.
setcookie("id", $id, time()+18000);
else:
$er_f="yes";
endif;

else:
$er_f="yes";
endif;


endif;
return $er_f;
//значение да будет означать, что авторизация не пройдена по каким-либо причинам
}

Данной функции мы передаем полученные из формы авторизации пароль и логин, взамен она нам выдаст либо пустое значение, если логин зарегистрирован, и пароль его верен, либо значение "yes" будет означать, что в процессе авторизации произошла ошибка, и соответственна авторизация не пройдена.
К таким ошибкам приводят неправильный логин, пароль, пустые поля и пр.

Теперь обработку формы можно передать скрипту, который мы обзовем login.php:

<? require("functions.tpl"); ?>
<? $result=autorize($login,$pass);
if ($result!="yes"):
$pr="<p class=font_2>Вы прошли авторизацию и были опознаны системой.<br>
Спустя несколько секунд вы попадете на главную страницу.<br>
Если ничего не произошло, щелкните <a href=index.php>здесь</a></p>";
else:
$pr="<p class=font_2>Вы не прошли авторизацию!</p>
<p class=font_2>Возможные причины:</p>
<ul>
<li class=font_2>ошибка в пароле или логине</li>
<li class=font_2>поля логина или пароля пустые</li>
<li class=font_2>не пройдена регистрация</li>
<li class=font_2>регистрация не подтверждена</li>
</ul>
<p class=font_2>Спустя несколько секунд вы попадете на главную страницу.<br>
Если ничего не произошло, щелкните <a href=index.php>здесь</a></p>";
endif;
?>
<html>
<head>
<title>Авторизация</title>
<meta http-equiv="refresh" content="5;URL=index.php">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251">

<link rel="stylesheet" href="style.css" type="text/css">
</head>

<body bgcolor="#FFFFFF" text="#333366">
<?print $pr;?>
</body>
</html>


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

function exist_login($id){
my_connect();//Свяжемся с базой
$query="SELECT * FROM users WHERE uid='$id';";
$result=mysql_query($query);
if (mysql_num_rows($result)==0):
//Пользователь не найден
$id="";//Обнулим
else:
//Пользователь найден, возвращаем его login
$id=mysql_result($result, 0,'login');
endif;
return $id;
}

Хочу напомнить, что уникальный идентификатор сидит у нас в куке (cookie) под именем id, и хранится в течение пяти часов с момента авторизации (чтобы пользователь, часто посещающий наш ресурс был избавлен от прохождения нудного процесса авторизации каждый раз).
Следовательно простой проверкой значения exist_login($id) мы получим, если пользователь не авторизирован, пустое значение. Или логин пользователя, если он авторизирован. А уж в зависимости от этого можно решить, что мы покажем пользователю (к примеру, форму авторизации в первом случае, или ссылку "Безопасный Выход" во втором).

Кстати, насчет выхода. Удалять куки можно скриптом exit.php:

<? setcookie("id","");
//Затираем кукис
?>

<html>
<head>
<title>Выход из системы</title>
<meta http-equiv="refresh" content="3;URL=index.php">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251">

<link rel="stylesheet" href="style.css" type="text/css">
</head>

<body bgcolor="#FFFFFF" text="#333366">
<p class="font_2">Безопасный выход из системы.<br>
Спустя несколько секунд вы попадете на главную страницу.<br>
Если ничего не произошло, щелкните <a href="index.php">здесь</a></p>
</body>
</html>


С регистрацией/авторизацией покончено. Переходим к разграничению прав доступа. Для чего она нужна?
К примеру, мы имеем форум, и на каждый раздел хотим назначить своего модератора (цензора). Разграничение прав доступа нужно для того, чтобы каждый модератор мог использовать власть, данную ему нами, только в пределах своего раздела. На самом деле область применения разграничения куда шире, но это уже выходит за тематику статьи.
Сперва создадим еще одну таблицу в базе MySQL под названием admin со следующей структурой:

CREATE TABLE admin (
login char(15),
priv char(15),
UNIQUE KEY login (login)
)

Если с полем login все ясно, то в поле priv мы будем хранить привилегии для каждого модератора. Для простоты оформим привилегии так:

Раздел 1 - a
Раздел 2 - b
Раздел 3 - c
Раздел 4 - d
И так далее…
Если у модератора привилегии "acd", то он имеет право модерировать соответственно разделы 1,3 и 4, и не имеет права модерировать раздел 3. Надеюсь, принцип ясен.

Теперь вставим в нашу библиотеку еще одну функцию:

//Функция, которая по ИД определяет является ли человек админом, и если да возвращает все привелегии
//согласно таблице admin мускла, значение $ret может принимать "0" - если пользователь не админ
function admin($id){
$login=exist_login($id);//Получим логин пользователя
my_connect(); //свяжемся с базой
$query="SELECT * FROM admin WHERE login='$login';";
$result=mysql_query($query);
if (mysql_num_rows($result)!=0):
//Найдено совпадение - вернем привелегии
$ret=mysql_result($result,0,'priv');
else:
$ret=0;
endif;
return $ret; //возвратим значение
}

Как уже стало ясно, эта функция из нашего id, что засел у нас в кукисах, узнает логин пользователя, проверяет, является ли этот пользователь привилегированным, если нет - возвращает значение "0", если да - возвращает строку привилегий, от обработки которой зависит доступность ресурсов для данного пользователя.

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

Если в процессе чтения возникли вопросы, задавайте их по мылу.

© urmach, 2002 (Разработка систем управления сайтом различной сложности)
© Ted, 2001-2002 (идея функции unikey() )

Оглавление/Вверх

Разработка систем навигации

Окончание

ЗАБЛУЖДЕНИЕ РАЗРАБОТЧИКА № 1: Некоторые разработчики "закрывают глаза" на критерий пространственного расположения системы навигации и помещают ее туда, куда им бы хотелось, полагая, что информационное наполнение их Интернет-проекта является исключительным и неповторимым. Последний довод стимулирует ложную уверенность разработчиков в способность удержать посетителя при любых обстоятельствах.

Отсюда можно вывести первое правило: размещать систему навигации следует в верхней части страниц сайта.

Перемещение навигации по вертикали должно происходить не далее 1/4 видимого пространства окна, при этом необходимо учитывать разницу экранного разрешения пользовательских мониторов. Дальнейшее перемещение навигации повлечет за собой перестановку приоритетов внимания посетителя, которому будет сложно найти "точку отсчета" своих переходов по сайту относительно соседних элементов документа.

Человек устроен таким образом, что просматривать любой документ начинает либо слева направо, либо сверху вниз (за исключением жителей Японии, арабских стран и т.д.). Поэтому наиболее оптимальными вариантами размещения навигации можно считать "слева вверху" и "посередине вверху".

• Идентифицируемость

Адрес Клуба http://dweb.ru/1/icq.htm

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

Для тех, кто может, а главное хочет поделиться своими знаниями, Вы можете вступить в наш Клуб, для этого присылайте # ICQ, Имя, E-mail, Город, и темы по которым возможна консультация.

Оглавление/Вверх

Авторам

Вы хотите, чтобы ваши статьи были опубликованы в рассылках 'Веб-Дизайн, азы' и 'Веб-Дизайн. От А до Я'? Если вы считаете, что можете написать о дизайне, скриптам, графике и т.п., если Вам есть что сказать и о чем рассказать, я буду рад сотрудничеству с Вами. Присылайте свои предложения и статьи.
Давайте вместе делать общее дело! Присылайте свои соображения, мысли, истории... поделитесь своим опытом.
В качестве гонорара Вы получите несколько строк под Вашей статьёй, для рекламы/описания Вашего сайта.
Буду рад сотрудничеству.

© 2000-2002 Copyright by Dweb.RU
Копирование материалов рассылки возможно только в случае явного указания на сайт "Dweb.RU" как на источник информации. При этом обязательно явное указание адреса: http://dweb.ru/