Создатели книги «Разгони свой сайт» порадовали новым проектом. На этот раз это сервис мониторинга работы сайтов WEBO Pulsar.

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

Доступность сайтов в WEBO Pulsar можно проверять по протоколам HTTP/HTTPS методами HEAD/GET/POST с частотой от раза в сутки до раза в минуту. Соответственно, чем чаще — тем дороже, хотя цены довольно низкие.

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

• Все необходимые типы и протоколы проверки (на подходе POP, SMTP, IMAP, DNS)
• Отображение полной диагностики ошибок (traceroute / ping / заголовки ответа)
• Добавление пользователей для просмотра статистики и уведомлений
• Картинки доступности (uptime) для каждого сайта
• Опциональное следование редиректам и проверка SSL-сертификатов
• Дополнительные точки проверки в России.

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

Упорядочены они в соответствии с рейтингом популярности TIOBE Programming Community Index.

	Java — объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems (сейчас принадлежит Oracle). Приложения Java обычно компилируются и могут работать на любой виртуальной Java-машине независимо от архитектуры и операционной системы. Считается самым популярным языком программирования в мире.
	PHP — один из самых популярных скриптовых языков программирования, применяемый в основном для разработки динамических веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров.
	Python — высокоуровневый язык программирования с акцентом на производительность разработчика (скорость и гибкость в разработке) и читаемость кода. Синтаксис ядра Python минималистичен, а стандартная библиотека включает большое количество полезных функций.
	Perl — высокоуровневый интерпретируемый динамический язык программирования с богатыми возможностями для работы с текстом, в том числе реализованными при помощи регулярных выражений. Архив дополнительных библиотек для этого языка (CPAN) содержит более 20 000 элементов. Perl существует уже около 22 лет и работает на сотне разных платформ. Поддерживается (видимо, по привычке) практически всеми хостинг-провайдерами.
	Ruby — динамический, рефлективный, интерпретируемый высокоуровневый язык программирования для быстрого и удобного объектно-ориентированного программирования. Язык обладает независимой от операционной системы реализацией многопоточности, строгой динамической типизацией, сборщиком мусора и многими другими возможностями.
	Go — компилируемый многопоточный язык программирования, разработанный компанией Google. Несмотря на простоту синтаксиса, является полноценным компиллируемым языком, но пока мало кем используется из-за своего юного возраста.

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

Алик Кириллович в своём блоге выложил огромную статью «Информационная архитектура блогов», в которой он вдумчиво и последовательно рассуждает о положительных и отрицательных моментах размещения информации в сетевых блогах.

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

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

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

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

Пока оптимальной мне кажется структура из трёх частей: блог (новости, анонсы), статьи (тематические структурированные материалы) и постепенно наполняемая wiki-часть. По крайней мере это технически проще решения Алика. А вы как считаете?

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

Firebug — это расширение для браузера Firefox, являющееся консолью, отладчиком, и DOM-инспектором JavaScript, DHTML, CSS, XMLHttpRequest.

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

Например, компания Yahoo ещё в 2007 году выпустила своё расширение Yahoo! YSlow, которое анализирует скорость загрузки всех компонентов веб-страницы и дает советы по клиентской оптимизации, основанные на собственных исследованиях и тестах Yahoo.

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

После установки этого расширения в Firebug появляются две новых вкладки: Page Speed (анализ загрузки страницы и формирование инструкций по исправлению найденных ошибок оптимизации) и Page Speed Activity (детальная отрисовка загрузки всех компонентов страницы).

Из отличий Page Speed от YSlow и аналогов можно назвать следующие: он умеет самостоятельно оптимизировать картинки и сжимать JS и CSS, а также показывать все неиспользуемые CSS-селекторы.

Ещё одно любопытное расширение для Firebug, не имеющее впрочем отношения к скорости загрузки страницы, — это SenSEO. Он анализирует огромное количество мелких факторов на странице, влияющих тем или иным образом на её поисковую оптимизацию.

Кстати, неплохо было бы сделать что-то подобное с поправкой на российские реалии. Никто не хочет озадачиться?

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

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

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

Читать далее »

Не так давно специалисты компании Google выдали вебмастерам инструмент для обеспечения более правильной индексации их сайтов своей поисковой системой — атрибут rel="canonical", указывающий на дублирующийся контент.

Теперь они добавили ещё пару атрибутов, которые должны обеспечить более правильное понимание поисковой системой материалов, разделённых на страницы — это атрибуты rel="prev" и rel="next" .

Работает это следующим образом: в head-блоке страницы прописывается тег link с атрибутами rel и href. Первый атрибут принимает значение prev или next, а второй содержит ссылку на предыдущую или следующую страницу соответственно.

Например, записи в этом блоге выводятся на главной странице и их вывод разделяется постранично. Первая страница — zhilinsky.ru, вторая — zhilinsky.ru/page/2/, и так далее. Для первой страницы конструкция будет выглядеть следующим образом:

<link rel="next" href="https://zhilinsky.ru/page/2/" />

Поскольку страница первая в списке, предыдущая страница не указывается (а у последней страницы не будет указана следующая). У второй страницы будут присутствовать уже оба атрибута:

<link rel="prev" href="https://zhilinsky.ru/" />
<link rel="next" href="https://zhilinsky.ru/page/3/" />

• Значения атрибута href могут представлять из себя как относительные, так и абсолютные пути.
• Если на странице объявлен тег base, то адреса можно указывать относительно его атрибута href.
• Разрешено использование значения rel="previous" как альтернативы rel="prev".

Если вы в чём-то ошибётесь при верстке этих атрибутов, то катастрофы не случится — Google просто проиндексирует ваши страницы, используя свои обычные алгоритмы.

Состоялся релиз инструмента для разработчиков Opera Dragonfly 1.0, встроенного в браузер Opera.

К этому релизу талантливые норвеги шли долго, я помню их секцию про Dragonfly ещё на iCamp 2008, то есть три года назад. Тогда Dragonfly планировался как мощный кроссплатформенный отладочный инструмент с возможностью удалённой отладки (в том числе и на мобильных устройствах).

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

Список возможностей Opera Dragonfly:

• Инспектор DOM
• Отладчик JavaScript
• Сетевой инспектор
• Инспектор ресурсов
• Инспектор хранилища
• Журнал ошибок
• Консоль
• Удалённый отладчик

Сейчас Opera Dragonfly — это HTML5-приложение, которое может работать как онлайн (обновления больше не нужны), так и оффлайн (из HTML5 AppCache).

Если у вас установлена свежая версия браузера Opera, то для знакомства с этим инструментом достаточно выбрать любой элемент на странице, вызвать контекстное меню и выбрать в нём пункт «Проинспектировать элемент».

Судя по первым отзывам, верстальщики довольны «Стрекозой».

Сегодня без особого шума открылся новый сервис Яндекса «Народная карта». Суть его в том, что каждый зарегистрированный пользователь может отметить на общей карте любой объект (строение, дорогу, водоём и т.п.), и эту отметку после модерации будут видеть все. Естественно, это улучшит читаемость и увеличит удобство использования карт.

Подробное описание работы сервиса «Народная карта» и обсуждение его развития происходит в блоге проекта.

Кстати, у Google тоже есть аналогичный сервис — «Картограф Google», который в России не очень популярен.

У нас куда большее распространение и популярность получил аналогичный русский геомэшап Wikimapia, использующий API Google Maps. На этом проекте города России уже очень хорошо описаны и размечены.

Так что тут мы видим типичное отличие Яндекса от Google: подчинённые Сергея Брина покупают интересующие их проекты, а сотрудники Аркадия Воложа их копируют, практически не оставляя шансов небольшим компаниям продолжать свой рост и развитие.

12 января 2010 года.

По сообщению компании Google, её сервис электронной почты Gmail подвергся серьёзной атаке, ориентировочно с территории КНР. Позже стало известно, что этой атаке, получившей кодовое имя «Aurora», подверглись сервисы ещё 33 компаний. Атака реализовалась набором эксплойтов под Internet Exporer 6, 7 и 8.

Читать далее »

Весть о скором закрытии Рейтинга популярных записей в сервисе Яндекс.Поиск по блогам вызвала у многих интерес к API, который Яндекс обещал сохранить. Уже появилось несколько новых рейтингов на основе данных этого API.

Вот и я хочу поделиться некоторыми наблюдениями в этой области.

Итак, собственно, как воспользоваться данными API рейтинга? Простейший вариант — использовать класс SimplePie. Но у нашего фида есть особенности:

1. Он за каким-то чёртом поделен на страницы, и это не лечится.
2. Часть данных передаётся в расширенном формате, непонятном стандартными RSS-классам.

Первую «особенность» можно обойти, последовательно запрашивая все страницы фида, а для обхода второй для класса придётся писать расширение.

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

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

— Большое число ссылок на сам блог или сообщество очень помогает. Например, почти все посты сообщества ru_mac попадают в топ за счёт этого.

— Намного больше шансов попасть в рейтинг у блогов на платформе LiveJournal.com. Отдельностоящих блогов там почти нет.

А теперь к досадному моменту: в фиде напрочь отсутствует какая-либо категоризация. Даже банальные теги из ЖЖ в фид не транслируются, что делает весьма затруднительным создание каких-либо тематических рейтингов на основе этого API. Я попробовал набросать некий алгоритм, выдающий записи на околокомпьютерную тематику, но эта идея потерпела фиаско — ни ручной отбор блогов, ни поиск ключевых слов в заголовках не дают нужного эффекта.

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