Versane

Как правильно заказывать сайт?

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

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

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

Однако прежде чем заказывать что-то, задайте потенциальному исполнителю несколько вопросов (при этом неважно, насколько вы сами понимаете их смысл):

1. Составите ли вы техническое задание (ТЗ) по моим словесным описаниям?
2. Передадите ли вы мне все исходные файлы, включая те, что относятся к дизайну (такие как PSD, FLA, CDR)?
3. Используете ли вы в своей работе систему контроля версий? Если да, то какую (варианты: SVN, CVS)?
4. Используете ли вы систему контроля ошибок (bug-tracking)? Например, Bugzilla или, может быть, что-то своё. Если да, то смогу ли я добавлять туда найденные мной ошибки и свои пожелания?
5. Будет ли исходный код содержать комментарии, понятные для меня?
6. Смогу ли я просматривать промежуточные версии на каждом этапе разработки?
7. Имеет ли исправление ошибок больший приоритет, или они исправляются вместе с написанием нового кода?
8. Есть ли у вас тестировщики, или их работу выполняют программисты?
9. Есть ли у вас отдельный эксперт по качеству, или его работу выполняют тестировщики (программисты)?

Наиболее важно получить положительные ответы на вопросы с 1 по 4. Очень желательно, чтобы ошибки исправлялись до написания нового кода, ну а наличие понятных комментариев в коде, отдельных тестировщиков и эксперта по качеству говорит о высоком уровне компании.

Наверх | Свернуть

Болтики и винтики WEB 2.0

Вы хотите получить современный сайт, которым будет приятно пользоваться? Вы хотите работать с сайтом, прилагая минимум усилий (кликов мышки) и при этом не вспоминать про функцию «открыть в новом окне»? Тогда вы просто обязаны знать, что такое «WEB 2.0».

Наиболее типичные мнения об этом термине:

• это всего лишь «buzz word», за ним ничего не стоит (но все о нём жужжат);
• это технологии AJAX (аджакс, аякс), RSS, CSS;
• это такие сайты с крупными шрифтами и пастельными тонами, градиентами;
• это сайты-блоги, wiki, основанные на комьюнити, где каждый может делиться информацией с другими;
• это новая эпоха в развитии веба.

Всё это правда и неправда одновременно, поскольку чёткого определения этого термина не существует до сих пор. Никаких новых технологий за этим также не стоит, и даже AJAX, основанный на XMLHttpRequest, успешно применялся ещё 1999 году, тогда как о WEB 2.0 заговорили только в конце 2003 года. Это слово стало модным, каким было в своё время, например, слово «евроремонт», которое, не имея конкретного значения, подразумевает лишь, что всё делается современно, красиво и удобно, не более того.

Если поискать, например, в Google «что такое евроремонт?», то мы получим результаты, заметно перекликающиеся с результатами поиска «что такое web 2.0?»:

• «Евроремонт – понятие бесконечно широкое и в какой-то степени надуманное для пущей солидности».
  Источник: http://www.rostovstroi.ru/rkv/remkve.php (результат №8)
• «Евроремонт – это профессиональный высококачественный ремонт с применением современных технологий и оборудования, включающий полный комплекс работ с дизайн-проектом».
  Источник: http://www.remont-domov.ru/repair/euro/ (результат №9)
• «Вообще, понятие "web 2.0" довольно широкое. В него входят и определенная мода на дизайн сайтов, и использование новых технологий, и даже клиентские приложения, которые довольно трудно отнести к вебу вообще».
  Источник: http://i2r.ru/static/512/out_23422.shtml (результат №2)

Таким образом, говорить «технология web 2.0» в принципе неправильно, это типичная ошибка многих компаний, которые слабо разбираются в современных технологиях и в погоне за клиентами выкрикивают модные слова, при этом не до конца понимая их смысл.

Важно не то, что компания обещает создать для вас «сайт web 2.0», а то, что конкретно она вкладывает в этот термин. Если вам просто скажут «магическое» слово AJAX, поинтересуйтесь, где именно будет использоваться эта технология. Нелишним будет и поинтересоваться о внешней составляющей сайта, благодаря которой пользователи с первого взгляда смогут сказать «да-а... это точно web 2.0!»

Наверх | Свернуть

Выбор инструментов

Вы хотите самостоятельно выбрать набор инструментов, которыми будет разрабатываться проект? Хорошо, значит этот раздел для вас.

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

Наглядно это можно представить так:

Язык для клиента – это, прежде всего, HTML и JavaScript (альтернативы вроде VB Script мы не рассматриваем). А вот выбор серверного языка не всегда очевиден. Что же тут можно предложить, исходя из предназначения сайта? Для UNIX-платформы это:

• PHP (простые сайты-каталоги, интернет-магазины, аукционы);
• RubyOnRails (блоги, форумы, фотоальбомы);
• Python (системы B2B, многомодульные интернет-магазины и аукционы);
• Perl (разбор текстовых документов и данных, многопроцессные задачи, работа с сетью – организация сервера);
• JSP, Servlets, JavaBeans (ERP системы, громоздкие проекты).

Если же серверная платформа – Microsoft Windows, то тогда наиболее подходящими будут:

• ASP.NET: C# , VB, C++ (системы B2B, многомодульные интернет-магазины и аукционы);
• JSP, Servlets, JavaBeans (ERP системы, громоздкие проекты).

Справедливости ради нужно отметить, что PHP, Perl, Python и RubyOnRails можно также использовать и на Windows-платформе, однако это повлечет за собой ряд ненужных тонкостей в настройке и поддержке сайта, а также затруднит интеграцию со сторонними модулями, разработанными в расчете на родную Unix-среду. Проще говоря, возможно, вам не удастся добавить на свой сайт какой-то сторонний модуль, например, для подсчета статистики посещений или покупок.

Наверх | Свернуть

Заглушки и хаки

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

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

// здесь нужна проверка данных
return true;

А в худшем вообще ничего не пишет и забывает об этом.

Впоследствии недоброжелатели легко смогут «сломать» сайт, написанный халтурщиками, т.е. скопировать или стереть все данные из БД или закачать и запустить свой скрипт, который удалит все файлы вашего сайта.

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

Что же такое хаки? Возвращаясь к автомобильной аналогии, можно сказать, что это прикрутка деталей на проволоку вместо установки в штатное место. Для некоторых это «стиль» программирования: такие мастера умудряются закрепить на проволоке двигатель и назначить стоимость ежемесячной «поддержки» сайта (как правило, от 3000 рублей и до бесконечности), которая будет заключаться в замене проволоки на новую раз в неделю.

Как это может выглядеть на сайте:

• наличие общего файла, в котором происходит обработка всех возможных входных параметров сайта;
• один файл с определениями всех функций сайта;
• прямое обращение к БД со всех динамических страниц;
• логин и пароль к базе данных прописан в явном виде в скрипте, отвечающем за отображение страницы сайта;
• меню и вся общая структура сайта дублируется во всех файлах, являющихся страницами;
• наличие блока switch-case для идентификации отображаемой страницы.

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

Наверх | Свернуть

Копи-паст кода (copy & paste)

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

Это почти всегда плохо и вот почему:

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

Приведем реальный пример из жизни.

Вот кусок кода, состоящий из 128 строк:

switch (type)
{
	case Type.AuctionEndedNotSoldSeller:
	mail.Subject = Template.Subject.Item.AuctionEndedNotSoldSeller + text3;
	auctionEndedNotSoldSeller = Template.Item.AuctionEndedNotSoldSeller;
	break; 

	case Type.AuctionEndedNotSoldBidder
	mail.Subject = Template.Subject.Item.AuctionEndedNotSoldBidder + text3;
	auctionEndedNotSoldSeller = Template.Item.AuctionEndedNotSoldBidder;
	break;

	case Type.AuctionEndedSoldSeller:
	mail.Subject = Template.Subject.Item.AuctionEndedSoldSeller + text3;
	auctionEndedNotSoldSeller = Template.Item.AuctionEndedSoldSeller;
	break; 

... // и далее следовали ещё 10 подобных блоков.

Он был заменен нами на 3 строки:

string typeName = type.ToString();
mail.Subject = typeof(Email.Template.Subject.Item).GetField(typeName).GetValue(null).ToString() + idtext;
templatePath = typeof(Email.Template.Item).GetField(typeName).GetValue(null).ToString();

Наверх | Свернуть

Паттерны проектирования

Сотни людей, желающих найти работу, присылали нам свои резюме с примерами кода. И только 10% из них имели представление о паттернах (шаблонах, схемах) проектирования, а опыт использования этих самых паттернов был лишь у 5% соискателей. Для чего же они нужны?

В первую очередь, для разделения "мух" и "котлет":

• дизайн сайта иногда приходится обновлять и делать это должен дизайнер и/или верстальщик, без помощи разработчика;
• бизнес-логика системы должна быть на поверхности, чтобы по требованию заказчика можно было легко (в течение часа-двух) добавить на сайт систему скидок или возможность оплаты заказов по кредитке. Очень часто приходится слышать от разработчика фразу: «Ну-у-у... это очень сложно переделать, потребуется много времени...» Такие программисты для нас – большая редкость: они либо оперативно учатся грамотно программировать, либо не задерживаются надолго;
• непосредственная обработка данных, прямая работа с базой данных и весь остальной код "низкого уровня" должен храниться отдельно, при этом упорядоченно и в соответствии с моделями (сущностями) системы, опять же для быстрого доступа и изменения.

При разработке сложных бизнес-систем практически всегда используются какие-либо паттерны, которые идеально подходят для решения целого ряда потенциальных проблем, в том числе быстродействия, надежности системы и безопасности данных. Если разработчик пишет mysql_connect внутри файла index.php, разбавляя код тегами HTML, то это не разработчик, а новичок, который, возможно, и способен сделать "сайт", но не способен его развивать и вносить изменения в сколько-нибудь разумные сроки.

Наверх | Свернуть

Нелепые сущности и связи

1. Нехватка сущностей

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

Нужно понимать, что в большинстве случаев кассиру достаточно установить видеокамеру, составить чёткие инструкции и ежедневно контролировать выручку. В случае же с платежной системой покупатель остается один на один с бездушным обработчиком платежей, и только разработчик может предусмотреть все возможные неблагоприятные исходы, чтобы в нужные моменты показать простые и понятные подсказки. К тому же разработчик должен учитывать, что некоторые покупатели попросту не смогут до конца оформить заказ и уйдут с сайта. Причины ухода могут быть как объективные (не хватило денег на кредитной карте), так и не совсем: человек ошибся в написании имени и не заметил этого, а сообщение об ошибке, к примеру, гласит «Error code: 1011». В любом случае, для владельца магазина эта информация крайне важна, он должен видеть статистику по всем недооформленным заказам и все ошибки, которые возникают в результате действий пользователей. Для этого в системе должен быть механизм отслеживания «неудачных» заказов, а также статистика по всем возникшим ошибкам, с обязательным уведомлением о критических ситуациях (по почте или с помощью SMS). Такого механизма просто не существует в большинстве предлагаемых на рынке платных и бесплатных систем электронной коммерции.

2. Лишние сущности и связи

2.1. Рассмотрим типичную систему распределения прав доступа.

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

Далее он выстраивает отношения между группами и пользователями:
- многие-ко-многим, т.е. Groups *-* Users,
и между привилегиями и пользователями:
- многие-ко-многим, т.е. Privileges *-* Users.

Вопрос о связи между группами и привилегиями, как правило, вообще никак не решается. Итого возникают 3 сущности - Users, Groups, Privileges, и вот такие связи:
Groups *-* Users
Privileges *-* Users
Groups *-* Privileges
Т.е. 3 отношения «многие-ко-многим».

Потом разработчик создаёт соответствующие таблички в БД, и думает, что все будет отлично работать. Однако ведь нужно ещё и функционал для всего этого создать, например, для администратора. Администратор может делать всё, но вот может ли он:
а) назначать новым группам привилегии или создавать новые группы без назначения им привилегий?
б) давать пользователю привилегии, не добавляя его при этом в группу?

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

Вся эта неразбериха выливается во множество проблем и неудобств, которых можно было бы избежать, объединив понятия групп и привилегий, и сделав первое следствием второго. «На пальцах» это выглядит так:
Мы создаем только пользователей и привилегии, а любой набор прав называем ролью. Конечно же сущности у нас по прежнему 3, но теперь мы избежали прямой связи между привилегиями и пользователями, т.е. имеем только такие связи:
Role -* Privileges (один-ко-многим)
Users *- Role (один-ко-многим)
Всего 2 отношения «один-ко-многим», и нет никаких проблем!

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

2.2. Другой пример – обработка заказов.

Проще всего выделить сущности, поискав аналогии в реальной жизни, т.е. типичный разработчик сходу предлагает такое решение:
- Пользователь (User)
- Корзина (Cart)
- Товар (Item)
- Заказ (Order)
Итого 4 сущности.

Вместе с соответствующими связями:
User -* Cart (один-ко-многим)
Item *-* Cart (многие-ко-многим)
Order - Cart (один-к-одному)
User -* Order (один-ко-многим)

Вполне возможно такое, что у пользователя будет несколько корзин, поскольку он вправе совершить несколько покупок, а удалять старые корзины мы не можем, иначе сломается статистика. Можно, конечно, придумать "костыль" в виде ещё одной сущности, которая будет отвечать за статистику, и смело копировать в неё информацию о совершенных покупках. Можно даже оставить всё как есть и наблюдать "прелести" хранения в одной таблице БД корзин всех покупателей (сегодняшних потенциальных и реальных позапрошлогодних), усложняя себе жизнь многочисленными проверками статуса корзин (нужно ведь знать, какие корзины стали реальными заказами).

Конечно же, красивых решений много, но корзина всегда должна быть одна – для одного пользователя в один момент времени. Не нужна для неё и сама сущность "Корзина". Можно сделать всё намного проще: сохранить данные о товарах в сессии на сервере, при этом в нужный момент надо только оформить заказ, который и будет являться достоверным источником для подсчета статистики. Сущностей при этом будет всего 3, а связи будут намного проще:
User -* Order (один-ко-многим)
Order -* Item (один-ко-многим)

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

Наверх | Свернуть

Умный менеджмент

Многим хорошим разработчикам очень не хватает навыков объективной оценки своей работы, поскольку количество и сложность технологий, с которыми приходится иметь дело при разработке бизнес-системы, зачастую превышают все мыслимые и немыслимые ожидания. Начиная разрабатывать простой сайт, включающий систему управления содержимым, программист не думает о том, что помимо знаний протокола HTTP, языков HTML, JavaScript, PHP, SQL ему придется иметь дело с технологией AJAX, сопутствующим ей языком XML, а также всеми тонкостями настройки модуля mod_rewrite для веб-сервера apache. Последний, в свою очередь, может быть ещё и не подключен, а значит потребуется перекомпилировать этот самый apache, прежде чем всё наконец-то заработает. При этом любой шаг в сторону, будь то требование заказчика создавать еженедельный бекап всего сайта или добавление рассылки новостей, потребует также знание cron, bash, sendmail и файловой системы UNIX. И вполне вероятно, что какой-то из сервисов будет неправильно настроен, что также отнимет значительное время и силы.

Вот наиболее типичные ошибки менеджеров:

1. взяться за проект, не согласовав требования программной части сервера (иногда хостинг клиента вообще не позволяет настраивать веб-сервер и подключать дополнительные модули);
2. взяться за проект, не сопоставив навыки разработчика с требуемыми для исполнения проекта технологиями;
3. обвинять программиста в том, что он не может всё настроить/починить, а также заказчика в том, что он не сказал про ограничения своего хостинга;
4. пытаться найти оправдания задержкам вместо того, чтобы исключить их путём согласования новых требований и сроков.

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

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

Заказчика мало волнует то, что происходит в личной жизни программистов, он должен получить готовый продукт в строго оговоренный срок.

Наверх | Свернуть

Тестирование

Между тем, как должен работать сайт, и тем, как он на самом деле работает, иногда бывает весьма ощутимая разница.

Основная задача тестирования – сделать эту разницу минимальной, в идеале – сделать так, чтобы её не было вовсе. На практике это означает, что продукт должен:

• работать (все заявленные функции должны присутствовать и выполняться);
• работать правильно (фактический результат выполнения действия должен совпадать с ожидаемым результатом);
• работать понятно (вероятность возникновения вопроса «А как этим пользоваться?» должна быть сведена к нулю);
• работать быстро (приемлемое время ожидания – то, на протяжении которого пользователь не успевает подумать, что ему приходится ждать).

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

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

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

Нагрузочное тестирование — это выявление "узких мест", в которых сайт может перестать работать правильно в случае больших нагрузок.
Нагрузочное тестирование эмулирует нагрузку на сайт, превышающую нормальную, — большие объёмы данных и большое число одновременных посетителей. Конечный продукт должен оставаться работоспособным в таких «экстремальных» условиях: полностью, без сбоев и за приемлемое время выполнять любую из поставленных перед ним задач.

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

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

Тестирование – это отчасти творческий процесс, специфика которого связана с конкретной проверяемой системой, однако существуют его универсальные принципы. Один из наиболее важных — у тестирования должен быть чёткий план и организация, при которой в любой момент времени о каждом элементе системы известно: протестирован/не протестирован, работает/не работает, удобен/неудобен, безопасно/небезопасно его использование.

Наверх | Свернуть

Пара слов о юзабилити, или «Клиент всегда прав»

Вам приходилось заполнять регистрационные формы и при этом видеть сообщения об ошибках в выборе имени или длине пароля после отправки формы? А случалось при этом такое, что часть уже заполненных вами полей формы становились пустыми? Подобные системы вызывают только раздражение пользователей, оставляя впечатление, будто разработчик живет в своём маленьком мирке и вовсе не думает о том, что его творение кто-то будет использовать по прямому назначению. А ведь для того, чтобы исправить ситуацию, порой достаточно приложить минимум усилий: всего лишь добавить проверку данных в клиентскую часть, чтобы не заставлять пользователя нажимать кнопку «Отправить» и ждать целую вечность, пока эта форма передастся на сервер, а сразу же показывать, в каком из многочисленных полей он написал что-то неподходящее для системы. Да-да, именно для системы, ведь пользователя вполне устроил бы пароль из 3-4 символов, это система (т.е. разработчик или архитектор) требует как минимум 6, а то и 8 символов для пароля, что бывает оправданно лишь в редких случаях.

Какие «удобные» для клиента выводы можно сделать? Попробуем перечислить только основные для большинства сайтов:

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

Наверх | Свернуть

CMS из коробки

Если вам приходилось сталкиваться с системой управления содержимым сайта, так называемой CMS (Content Management System), то вы наверняка видели подобного «монстра»:

Это просто свалка из непонятных «обычному пользователю»* кнопок, только часть из которых может быть знакома тем, кто использует MS Word. Изменять в таком «редакторе» расположение блоков, отступы или добавлять фоновые рисунки практически невозможно, нужно в совершенстве овладеть языком HTML, иначе вы просто потеряете своё время. Посмотрите на типичные проблемы, обозначенные на этом скриншоте. Это лишь маленькая часть тех трудностей, которые вас ожидают в случае покупки подобной CMS.

Как мы решили эту проблему?

Очень просто. Мы избавились от «лишних сущностей» – в данном случае, от всей администраторской части для редактирования содержимого. Если говорить точнее, мы просто реализовали её как дополнительный режим при просмотре страницы. Таким образом, вам не нужно переходить куда-то с сайта, вы просто вводите логин и пароль администратора и сразу же изменяете любые тексты, двигаете картинки и блоки, как вам хочется, именно на этой странице, а не в «волшебном» (т.е. непредсказуемом) WYSIWYG-редакторе. Если же вы изменили какой-то общий для всех страниц блок (например меню), то система предупредит вас об этом и в случае необходимости сохранит эти изменения в общем шаблоне.

Вот список шагов для изменения контента в большинстве коробочных CMS:

1. Запомнить название/URL страницы, которую хочется изменить.
2. Войти в администраторскую часть.
3. Выбрать пункт меню для изменения содержимого сайта.
4. Отыскать нужную страницу/шаблон.
5. Перейти в режим редактирования.
6. Попытаться отредактировать с помощью WYSIWYG-монстра.
7. Если в п.6 всё получилось, то сохранить изменения.
8. Выйти из администраторской части и снова зайти на страницу.
9. Убедиться, что изменения выглядят так, как надо.

Что мы предлагаем? Просто избавиться от лишних шагов:

1. Авторизоваться как администратор на той странице, которую хочется изменить.
2. Изменить всё, что нужно, оставаясь на той же странице.
3. Сохранить изменения и сразу убедиться, что желаемый эффект достигнут.

Наверх | Свернуть

Поисковая оптимизация сайтов

Эффективность вашего сайта во многом будет определяться его посещаемостью.
Как сделать сайт более популярным? Основные понятия SEO.

SEO (Search Engines Optimization – "оптимизация под поисковые машины") – это поисковая оптимизация сайта, которую называют также продвижением или раскруткой сайта. Она представляет собой комплекс мер, которые предпринимаются для продвижения сайта в поисковых системах и, соответственно, увеличения его посещаемости. Цель оптимизации – добиться того, чтобы сайт был среди первых результатов поиска по ключевым словам и фразам, что приведет к росту его популярности среди заведомо целевой аудитории.

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

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

«Внешние» свойства сайта в интернете определяются в основном количеством и «качеством» ссылающихся на него ресурсов. Ваш сайт будет чаще фигурировать в результатах поиска, если ссылки на него размещены на многих других сайтах, особенно с похожей тематикой. Можно также включить ваш ресурс в подходящие каталоги (например в Open Directory Project и Yahoo!) и добавить информацию о нем на отраслевые профессиональные сайты. Однако будьте внимательны, не размещайте ссылки на недобросовестные ресурсы и постарайтесь, чтобы они не ссылались на ваш: это с большой вероятностью ухудшит ваш рейтинг.

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

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

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

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

При ссылочном ранжировании обычно используются определенным образом рассчитанные числовые показатели – индекс цитирования. В Рунете больше всего известен индекс цитирования поисковой машины «Яндекс», так называемый тематический индекс цитирования (тИЦ), в котором особое значение придается тематической близости ресурса и ссылающихся на него сайтов.

Наиболее популярный на сегодняшний день поисковик Google для определения релевантности результатов поиска использует, кроме сопоставления текста, учета тэга Title, ключевых слов и других факторов, собственный метод расчета индекса цитирования – Google PageRank. Это показатель «важности» страницы, основанный на исследовании «важности» внешних ссылок на нее. Ссылка со страницы А на страницу В расценивается как «голос» в пользу страницы В, причем чем «важнее» страница А, тем большее значение имеет ее «голос». Число и важность «голосов» в пользу страницы В подсчитывается, тем самым определяется ее авторитетность относительно других, в остальном равноценных страниц. Чем выше оказался этот рейтинг, тем «важнее», в свою очередь, будут ссылки с нее на другие страницы.

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

Наверх | Свернуть

Для чего нам инструмент

Для чего вообще нужны языки программирования? Почему бы всем не начать писать на ассемблерах?

Каждый язык программирования имеет в себе набор средств для решения задач, в числе которых:

• разумное использование ресурсов системы;
• быстродействие конечного кода;
• отказоустойчивость;
• удобство и скорость разработки;
• читабельность кода.

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

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

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

Каждый высокоуровневый язык дает нам средства для структурирования и переиспользования кода:

• функции/методы, циклы, полиморфизм — для предотвращения копи-паста;
• области видимости, инкапсуляция, наследование — для структурирования и предотвращения копи-паста.

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

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

В идеальном с нашей точки зрения высокоуровневом языке будущего не будет архаичных конструкций if, goto, switch-case, в нем даже не будет возникать вопрос о том, где хранить данные: в файлах, базе или памяти, поскольку компилятор сам будет это решать в зависимости от их объемов и интенсивности использования.

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

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

Наверх | Свернуть