Ну наконец-то хоть кто-то из наших политиков заговорил про украинскую Силиконовую долину. Я уж думал не дождусь.

«Конечно, мы создадим такую долину!»

премьер-министр Украины Николай Азаров

в эфире программы «Большая политика с Евгением Киселевым»

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

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

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

Но это в России. А что у нас? А у нас даже представители крупных компаний, приходя в веб-студию заказывать сайт за несколько десятков тысяч долларов, с трудом понимают зачем он им. И как он может помогать их бизнесу. И почему, чтобы сайт начал приносить прибыль, в него нужно вложить не только деньги, но и душу. И как это даже такие большие инвестиции могут вернуться всего за 3-6 месяцев. Он просто им нужен и все — у всех есть, пусть и у нас будет.

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

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

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

Давайте разберемся, зачем нужна карта сайта интернет-магазину?

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

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

Разберемся подробней, в каких случаях просто необходимо «подсунуть» роботу ПС карту сайта.

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

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

В-третьих, в случае отсутствие ЧПУ. Это классика, и тут использование карты сайта вообще является обязательным атрибутом, ибо роботу неведомы алгоритмы формирования параметров динамических страниц такого сайта.

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

Как создать Sitemap

Создавать Sitemap можно вручную или автоматически.

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

Кстати, Sitemap можно создавать для папок, подпапок и даже подподпапок.

Важно знать, что в одном файле Sitemap должно быть не более 50000 URL, а размер файла не должен превышать 10 МБ. Если эти лимиты превышены нужно создавать несколько файлов и добавлять их в специальный файл индекса Sitemap.

Кроме того файл должен иметь кодировку UTF-8.

Проверить Sitemap на валидность можно, например, вот этим сервисом.

Как уведомить поисковые системы о файле Sitemap

Файл создан, пора рассказать о нем поисковым системам. Способов здесь несколько:

1. Самый распространенный — добавить через «Панель вебмастера», которая есть во всех популярных поисковых системах (Гугл, Яндекс).
2. Можно указать путь к Sitemap в файле robots.txt. Для этого просто добавьте следующую строку:

   Sitemap: http://www.site.ru/sitemap.xml

3. Передать файл Sitemap с помощью HTTP-запроса:
   

   /ping?sitemap=sitemap_url

   где вместо <searchengine_URL> вписываем специальный УРЛ поисковой системы.

Все остальное дело техники, а точнее — поисковых роботов. Через пару недель, после переиндексации и пары-тройки апдейтов по той же «Панели вебмастера» проверяем количество страниц в индексе. И если все было сделано правильно — радуемся жизни.

Долго ломал голову над правильной структурой ЧПУ для XXL-Маркета. Перерыл множество сайтов с желанием перенять передовой опыт ЧПУ-строения. Какого же было мое удивление, когда на сайтах-флагманах электронной коммерции Амазон и Ебей я не увидел вообще никакого ЧПУ. Гуглу, конечно, пофиг на все это человекоподобие, он то железяка, но вот о людях я бы на их месте подумал. Мне кажется, что изначально разработчики как-то не уделили внимания этому вопросу, а сейчас что-то исправлять уже совсем непросто.

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

1. Структура УРЛов должна повторять структуру сайта и каталога товаров.
   Например, site.ru/auto/electronics/acoustics/
   При этом не должно быть лишней папки catalog. Ее роль обычно выполняет главная страница.
2. Категории должны иметь название, а не цифровой идентификатор.
   Неправильно: site.ru/01/12/198/
   
3. Названия разделов и категорий должны быть на английском языке (не транслит!)
   Неправильно: site.ru/avtomobili/elektronika/avtoakustika/
   
4. Каждая страница каталога товаров должна иметь собственный УРЛ-папку
   Например, site.ru/auto/electronics/acoustics/12/
   
5. Каждый товар в категории должен проставляться цифровым идентификатором.
   Например, site.ru/auto/electronics/acoustics/765.html
   
6. Раздел новостей должен находится в отдельной папке news, а подпапками должны стать год, месяц, день, идентификатор новости (именно в этом порядке).
   Например, site.ru/news/2010/12/07/777.html
   При удалении каждого уровня появляются новости за бОльший период (день, месяц, год)
7. Раздел статей должен находится в отдельной папке topic, в ней разделы статей и их идентификаторы.
   Например, site.ru/topic/electronics/777.html
   Аналогично делаем разделы с обзорами товаров, полезной информацией, FAQ и чем угодно еще.
8. Основные информационные страницы проекта делаем в разделе первого уровня.
   Например, site.ru/for-sellers/
   Здесь важно следить за тем, чтобы название информационной страницы не дублировалось с названием раздела товаров. Сделать это можно только программно (сверяя название разделов с названием статьи).

Примерно так. Возможно я что-то упустил, но основные моменты вроде зафиксировал. Жду вопросы, пожелания и предложения в камменты.

Сделаем вместе наши интернет-магазины человечнее!

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

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

А нынешние бизнес-инкубаторы и прочие интерпренерские истории ищут одиночек. Конечно, проще и дешевле найти «хорошую идею из одного человека» и подобрать под него команду. Но будет ли такая команда разделять его «стартап-болезнь», поймет ли правильно идею, сработаются ли все специалисты, сколько времени уйдет на подбор такой команды, не уйдут ли все основные силы ключевого человека на организацию процесса? Это вопросы, ответы на которые очевидны.

Поэтому стоны по поводу отсутствия рынка стартапов — результат и следствие неправильного подхода к поиску проектов самих бизнес-инкубаторов. Точка.

Вместо предисловия

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

Уже лет 5 для планирования я пользуюсь Аутлуком на ноутбуке и коммуникаторе, которые синхронизировались между собой по юэсбишному шнурку. Одно время я пытался настроить синхронизацию по блютусу, но ресурс заряда батареи КПК сразу уменьшался вдвое, что меня сильно расстраивало, и я отказался от этого способа.

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

Возвращаться к «проводной версии» синхронизации мне уже сильно не хотелось — к хорошему привыкаешь быстро, и я стал искать выход. И, что примечательно, нашел. Причем бесплатный, что меня вообще сильно радует.

А выход заключается в использовании синхронизации через Гугл.Календарь. Причем настройка всего хозяйства занимает не больше 10 минут. Но обо всем по порядку.

Настройка Гугл.Календаря

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

Настройка синхронизации в коммуникаторе

Запускаем ActiveSync — Меню — Настройка сервера… и прописываем в поле «Адрес сервера»: m.google.com. Оставляем галочку в поле «Требуется шифрованное подключение (SSL) и жмем «Далее». Вводим имя пользователя (e-mail адрес в Gmail), пароль от почты и жмем «Далее». Ставим галочки напротив «Календарь», «Контакты», «Электронная почта» и жмем «Готово». Все!

Осталось нажать «Синхронизация» и проверить как тестовая встреча перекочевала в мобильный Аутлук.

Настройка синхронизации в ноутбуке

Тут тоже все просто. Качаем и устанавливаем программу Google Calendar Sync. В процессе установки программа запросит логин и пароль — вводим e-mail и пароль от почты. По окончании установки программа сама синхронизирует данные календаря и будет это делать с заданной периодичностью.

Для синхронизации контактов качаем и устанавливаем GO Contact Sync. Там все аналогично.

Ура, заработало!

На этом, пожалуй, настройка завершена. Теперь при изменении информации в календаре или контактах на одном из источников (ноутбук, коммуникатор или Гугл.Календарь) — на двух других информация обновится автоматически и, что самое важное, без всяких проводов. Сказочно, не правда ли? Лично меня это очень радует. Пользуйтесь на здоровье.

продолжение… начало здесь

Список пользователей

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

• Пользователь : логин пользователя
• Имя : имя пользователя
• Фамилия : фамилия пользователя
• Email : адрес электронной почты пользователя
• Администратор : если стоит значок — пользователь назначается администратором, который имеет неограниченный доступ к приложению и всем проектам
• Создан : дата, когда была создана учетная запись
• Последнее подключение : дата, когда пользователь, входил в систему последний раз

Статус пользователя

В зависимости от настроек пользователи могут иметь несколько статусов:

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

Кнопка «Заблокировать / Разблокировать» позволяет активировать зарегистрированных пользователей.

Проверка подлинности пользователя

Пользователи входят в систему вводя логин и пароль. Эти данные могут вводиться непосредственно в Redmine, внешний LDAP или OpenId сервер, или в Redmine-плагины, которые позволяют, например, использовать встроенную Apache-аутентификацию.

Добавление или редактирование пользователя

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

следующая статья об управлении группами. не пропустите)