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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скрипт написан на PHP (возможна работа как в режиме модуля Апача, так и в FastCGI), полностью валиден (в рамках соответствия стандартам xHTML1/Strict и CSS/3), имеет гибкую систему настроек и панель управления. Скрипт также может отображать историю активности ботов конкретной поисковой машины.

Скачать скрипт и получить инструкции по его установке можно на сайте его разработчика — Usings.ru, там же есть и демо-версия статистики, генерируемой скриптом.

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

Задачу «отправить POST- или GET-методом данные и получить результат через прокси» взялись выполнить два PHP-класса.

Curl HTTP Client — простая, но эффективная ООП-оболочка над библиотекой Curl. Содержит все методы, необходимые для получения данных со страниц, подмены referrer, авторизации, отправки POST-запросов, управления cookies и т.д.

Snoopy the PHP net client — PHP-класс, эмулирующий работу веб-браузера. Он автоматизирует получение содержимого страниц или, например, отправку форм. Запросы формирует функцией fsockopen().

Функции этих классов очень похожи. Оба они умеют получать содержимое страниц, отправлять любые значения полей User-agent и Refferer, передавать данные POST- и GET-методами, передавать Cookies, и ещё куча мелких бонусов у каждого класса.

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

Задача получилась такая: подключить класс, установить User-agent и Refferer, получить страницу с чужого сайта, вывести прошедшее время, повторить всё 100 раз.

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

UNIX-время или POSIX-время (Unix time) — способ кодирования времени, принятый в UNIX и некоторых других POSIX-совместимых операционных системах.

$ date -ud@1234567890
Fri Feb 13 23:31:30 UTC 2009

Фактически, unix time (или time_t по типу переменной) — это число секунд, прошедших с точки начала отсчёта, которой считается полночь (по UTC) с 31 декабря 1969 года на 1 января 1970 года, а время с этого момента называют «эрой UNIX» (Unix Epoch).

Фанаты, гики и энтузиасты ещё во времена Fidonet завели традицию — отмечать особо ровные даты в unix-time, и такие даты стали называть «time_t parties».

Вот самые круглые time_t-даты:

• 9 сентября 2001 года в 01:46:40 UTC, биллениум Unix (1000000000)
• 18 марта 2005 года в 01:58:31 UTC (1111111111)
• 13 февраля 2009 года в 23:31:30 UTC (1234567890)
• 13 июля 2012 года в 11:01:20 UTC (1342177280 = 0x50000000)
• 18 мая 2033 года в 03:33:20 UTC , второй биллениум (2000000000).

Как видите, в ночь с 13 на 14 февраля этого года ожидается юбилей. Технически с учётом поправки на часовой пояс у нас это произойдёт уже 14-го в 31 минуту и 30 секунд первого. Забавно, что 13-е число приходится на пятницу, а 14-е — день всех влюблённых.

19 января 2038 года в 03:14:08 по UTC значение переменной типа time_t достигнет 2³¹, что может привести к ошибочной интерпретации этого числа как отрицательного. Возможное решение «проблемы 2K38» —  использование не 32-х, а 64-битной переменной.

Этот пост не совсем обычный — большая его часть написана не мной. Эти мысли прислал мне Владимир «Bolzamo» Большаков, я их только немного откорректировал и добавил свои комментарии. Итак, читаем.

В наши дни web-разработка уже совсем не та, что была в 90-х, а еще через пару лет она изменится ещё больше. На дворе XXI век, и Web 2.0 принёс нам XHTML, Ajax, микроформаты, OpenID, RSS и прочие вкусности.
То, что раньше «лепилось вслепую», теперь уже перерабатывается, проходит стандартизации и спецификации. Это касается и web-технологий, в частности — языков разметки и описания web-интерфейсов: HTML и CSS, о которых и пойдет речь.

Жилинский: А что 90-е? Я в ВГТУ получал сертификат по web-программированию в 2001 году — нам тогда давали PHP3 и говорили, что «некоторые веб-мастера уже иногда используют для верстки DIV-блоки с абсолютным позиционированием, но полностью сделать страницу на них невозможно.»

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

Будучи web-программистом, и ходя большей частью по сайтам таких же гиков и фанатов развития новых технологий, иногда начинаешь считать, что весь web красив и продвинут, что Web 2.0 прочно вошел в нашу жизнь, что красивый ненавязчивый дизайн (разработанный согласно требованиям юзабилити) и блочная семантическая верстка — это обыденность, это нормально…

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

Сколько их, этих ресурсов, построенных на табличной верстке, в коде которой сломаешь обе ноги, руку и голову? Чья кодировка — windows-1251, перенос строки формата — cr/lf, а у некоторых в еще и <META NAME=»Generator» CONTENT=»FrontPage 4.0″>…

Жилинский: Много. Очень много. Даже в корпоративном сегменте, не говоря уже про Юкоз, Народ и леса сателлитов...

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

Почему HTML изучают с таблиц? Элементарно! Потому что в учебниках написано изучать HTML с таблиц. Все учебники, самоучители и методические пособия вышли в далеких 90х годах, когда CSS рассматривался, разве что, как средство выставить шрифты и расцветку сразу для всего сайта. И слыхом никто не слыхивал о разделении контента и представления.

Есть, конечно, и новые учебники. Полистал недавно парочку… Нашел в них перепечатку старых. Только версия FrontPage поменялась и добавилось пара глав о CSS и блочной верстке. Почему-то авторы этих учебников ни разу не задумываются о том, что, чтобы научить человека чему-то хорошему, надо для начала не учить его плохому.

Кто не согласен с тем, что табличная верстка — это плохо? Почитайте спецификацию: тег table предназначен для представления табличных данных, равно как микроскоп предназначен для изучения микроскопических объектов, а не для забивания гвоздей.

Как-то я разговорился на эту тему с одним программистом, который иногда зарабатывает созданием простеньких сайтов на заказ для местных организаций. Сайты делает просто удивительные: верстка табличная, картинки увесистые, скрипты самописные, ЧПУ даже и не пахло. На все мои увещевания, что это неправильно, что надо стремиться к лучшему, он просто ответил, что веб никогда не был и не будет правильным. Что HTML — это куча мусора, к которой добавили еще одну кучу мусора — CSS, и теперь пытаются присобачить третью кучу мусора, называя ее стандартами веб-разработки. Классная формулировка, которая для многих может показаться вполне резонным оправданием, чтобы продолжать забивать интернет этим самым мусором. А какая разница? Заказчик ничего в этом не смыслит, ему красиво — он доволен.

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

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

1. Делаем, как привыкли. Уже научились верстать в таблицах, кажется очень сложным изучать все тонкости и хитросплетения CSS, вдумываться в структуру документа, воевать с багами IE, чтобы достичь кросс-браузерности. На самом деле, блочная верстка куда проще и логичнее, просто сначала стоит изучить вопрос.

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

«Облако тегов» или «Облако меток» (англ. tag cloud) — визуальное представление списка ярлыков. Частота упоминаний, поисков, ссылок в интернете с определенного сайта неких слов, терминов, имен, отображается в виде изображения этих слов в формате гиперссылок. Размер изображения тем больше, чем выше релевантность данного слова.

Теги для многих удобнее категорий, и, наверное, поэтому без них сейчас не обходится ни один проект в концепциях Web 2.0. Для многих CMS есть модули или плагины, выводящие облако тегов. WordPress поддерживает такую функцию начиная с версии 2.3.

Но мне захотелось вывести такую штуку на самописном движке сайта «Коллеги: 1000 IT-блогов«. Реализация оказалась проще, чем я думал.

• 1. Создал таблицу соответствий «Тег — Число».
• 2. Заполнил её (несложная функция, подсчитывающая число вхождений тега в таблице блогов).
• 3. Рассчитал максимальное значение и исходя из него — популярность каждого тега в процентах.
• 4. Разделил теги на группы по популярности и назначил им CSS-классы.
• 5. Подготовил соответствующие CSS-классы для отображения.
• 6. Вывел облако на страницу блоком.

TagCloud.phps - формирование облака тегов.

В тексте исходника — все инструкции, дамп таблицы и CSS-классы. Посмотреть этот код в действии можно в «Коллегах».

Жилинский Владимир.

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

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

Этот сборник продвинутых функций для работы с UTF-8 текстом создан коллективным разумом форума программистов и усилиями Рината Мухтарова. Скачать архив.

Далее — список доступных функций и их описания:

1. censure. Функция определяет наличие мата (нецензурных, матерных слов) в тексте. Возвращает false, если мат не обнаружен, иначе обнаруженное матерное слово. Алгоритм достаточно надежен и быстр, в т.ч. на больших объемах данных. Метод обнаружения мата основывается на корнях и предлогах русского языка, а не на словаре, поэтому скорость очень высока.

2. cp1251_to_utf8_recursive. Функция для перекодировки данных произвольной структуры из кодировки cp1251 в кодировку UTF8.

3. cp1259_to_utf8. Конвертирует текст из кодировки cp1259 и cp1251 в кодировку UTF-8.

4. html_template. HTML-ориентированный шаблонизатор с автоматическим квотированим значений меток-заменителей.

5. html_words_highlight. «Подсветка» найденных слов для результатов поисковых систем.

6. hyphen_words. Расстановка «мягких» переносов в словах.

7. is_utf8. Возвращает true усли переданная строка — правильный UTF-8, иначе false.

8. php2js. Конвертирует данные PHP из scalar, array и hash в данные JS в scalar/array/hash.

9. strip_tags_smart. Более продвинутый аналог strip_tags() для корректного вырезания тегов из html кода. Возможности:

— корректно обрабатываются вхождения типа «a < b > c».
— корректно обрабатывается «грязный» html, когда в значениях атрибутов тагов могут встречаться символы < >.
— корректно обрабатывается разбитый html.
— вырезаются комментарии, скрипты, стили, PHP, Perl, ASP код, MS Word теги.
— автоматически форматируется текст, если он содержит html код.
— защита от подделок типа: «<script>alert(‘hi’)script>».

10. textarea_rows. Вычисляет высоту области редактирования текста (<textarea>) по значению и ширине.

11. ucs2_to_utf8. Преобразует строку из кодировки UCS-2 в UTF-8, без использования iconv.

12. utf8_autoconvert_request_charset. Перекодирует значения элементов массивов $_GET, $_POST, $_COOKIE, $_REQUEST, $_FILES из кодировки cp1251 в UTF-8, если необходимо. Побочным положительным эффектом функции является защита от XSS атаки с непечатаемыми символами на уязвимые PHP функции.

13. utf8_check. Пытается определить, находится ли строка в кдировке Unicode.

14. utf8_convert_case. Конвертирует регистр букв в строке в кодировке UTF-8.

15. utf8_escape. Перекодирует строковые объекты так, чтобы они читались везде.

16. utf8_html_entity_decode. Конвертирует все HTML-entities в символы UTF-8.

17. utf8_html_entity_encode. Конвертирует спецсимволы UTF-8 в HTML-entities.

18. utf8_simple_search_sql. Создает условия для простого поискового SQL запроса, основанного на LIKE и REGEXP.

19. utf8_str_limit. Обрезает текст в кодировке UTF-8 до заданной длины, причём последнее слово показывается целиком, а не обрывается на середине.

20. utf8_strlen. Расширенная функция strlen() для работы со строками в utf-8.

21. utf8_substr. Расширенная функция substr() для работы со строками в utf-8.

22. utf8_ucfirst. Преобразует первый символ строки в кодировке UTF-8 в верхний регистр.

23. utf8_ucwords. Преобразует в верхний регистр первый символ каждого слова в строке в кодировке UTF-8, остальные символы каждого слова преобразуются в нижний регистр.

24. utf8_unescape. Функция декодирует строку в формате %uxxxx в строку формата UTF-8.

25. utf8_unescape_recursive. Рекурсивный вариант utf8_unescape().

26. utf8_unescape_request. Корректирует глобальные массивы $_GET, $_POST, $_COOKIE, $_REQUEST, декодируя значения в юникоде, закодированные через функцию javascript escape() ~ “%uxxxx”.

Жилинский Владимир.

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

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

На западе решением этой проблемы было озадачено несколько компаний, разработавших всё, что можно найти в Google по запросу «Live Chat Software«, то есть программы для мгновенной связи оператора с посетителем сайта. По некоторым данным, такой механизм в хорошей реализации может увеличить конверсию и, соответственно, продажи более чем на 80% (!). Это вполне логично — задать вопрос специалисту проще, чем лазать по каталогу и легче, чем звонить, искать кого-то в ICQ или ждать ответа по e-mail.

Отсюда логически следует жизненный вопрос: как это реализовать, желательно самостоятельно и бесплатно?

Подход первый. Грамотный.
Будем писать сервис под себя. Самый удобный, открытый и подходящий для этой цели стандарт, на мой взгляд — Jabber . Берём class.jabber.php или немного его доработанный вариант PHP Jabber Client и пишем всё, что нам нужно. Для любителей Python: xmpppy .

Не нравится XMPP — можно рискнуть и заморочиться с ICQ, например на основе PHP-класса WebIcqPro или даже Java-библиотеки Joscar . Я думаю, что ICQ следует использовать только в том случае, когда нет возможности использовать Jabber, так как этот протокол не блещет стабильностью, надёжностью и предсказуемостью. Да и возможность несложного создания Jabber2ICQ гейта даёт Jabber`у дополнительное преимущество.

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

1. Hab.la . Весьма удобный сервис, основанный на Jabber. Легко настраивается, не вызывает конфликтов, легко интегрируется в любую страницу, позволяет использовать любой jabber-клиент на стороне оператора. Подробнее про хаблу можно почитать у Дикого .

2. Google Talk chatback badge . Просто и со вкусом, если грамотно оформить, то вполне приемлемо. Но найден недостаток в реализации — сделано с использованием Flash (Google, ЗАЧЕМ?), что ограничивает в общении неанглоязчных пользователей не-windows. Я надеюсь, в Google исправят этот косяк.

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

• Веб Мессенджер
• SiteHelper.NET
• GoTalk
• LiveContact

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

Спонсор статьи: продвижение сайтов от StarDesign. Без комментариев.

Жилинский Владимир.

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

В PHP есть ряд специальных функций для работы со строками, применимых для этой цели. Вот они:

strip_tags() — вырезает теги HTML и PHP из строки.

htmlspecialchars() — конвертирует только специальные символы (‘&’, ‘»‘, »’, ‘<‘ и ‘>’) в HTML сущности (‘&amp;’, ‘&quot;’…). Используется для фильтрации вводимых пользователем данных для защиты от XSS-атак.

htmlentities() — конвертирует все символы в строке (кроме букв) в мнемоники HTML. Используется для защиты от XSS, являясь более гибким аналогом htmlspecialchars.

stripslashes() — удаляет заэкранированные символы (после преобразования в сущности предыдущими функциями их незачем экранировать). Обычно используется в связке с проверочной функцией get_magic_quotes_gpc(), показывающей текущую установку конфигурации magic_quotes_gpc.

Эта конфигурация влияет на то, как будут обрабатываться специальные символы, содержащиеся в данных, передаваемых пользователем (массивы $_GET, $_POST, $_COOKIE). При magic_quotes_gpc = 1 эти спецсимволы (одиночные и двойные кавычки, обратный слэш, байт NULL) автоматически экранируются. При magic_quotes_gpc = 0 все данные передаются в таком виде, в каком их ввел пользователь. В последнем случае в целях безопасности требуется обрабатывать передаваемые данные.

mysql_real_escape_string — мнемонизирует специальные символы в строке для использования в операторе SQL с учётом текущего набора символов в кодировке соединения. Иными словами, функция превращает любую строку в правильную и безопасную для MySQL-запроса. Используется для очистки всех данных, передающихся в MySQL-запрос для защиты от SQL-инъекций.

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

InputClear.phps - фильтрация введённых пользователями данных.

Если кто-то обнаружит ошибки, или знает способ лучше — добро пожаловать в комментарии, мне очень интересно.

Жилинский Владимир.