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

Эта панель называется «Мои сайты» и ссылка на неё уже есть на странице Яндекс.Вебмастер, но вход пока только по приглашениям. Несколько приглашений даётся каждому активному тестеру через сутки после начала работы.

Одно приглашение получил и я, так что сервисом уже пользуюсь.

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

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

«Ошибка анализа главной страницы.»

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

Кликнув на числе страниц или числе ошибок, можно перейти на страницы «Структура сайта» и «Ошибки» соответственно.

На странице «Структура сайта» показываются разделы и подразделы сайта (что курит робот?), сколько страниц загружено в каждом и в процентах от общего числа. Разделы, как видно, определяются на основе паттернов URI.

Ошибки делятся на 3 вида: информация, предупреждение и ошибка.
На странице «Ошибки» — график по дням (Х) и числу найденных ошибок (Y) в виде гистограммы (синий, желтый, красный цвет по типам ошибок соотвественно).

Есть два вида просмотра ошибок — «Сводка» и «Ошибки по разделам». В сводке можно получить список страниц и вид ошибки по всему сайту, по разделам — соответственно по каждому разделу, что довольно удобно.

Чего-то не хватает ? Ну да, ещё бы… Все ждут появления сервиса просмотра ссылок на сайты, а его пока нет. Логичным было бы так же связать сервис с ЯК и ТИЦ по аналогии с Google PR. Да и глюков пока много — у меня, например, в FireFox не работают ссылки на FAQ справа (кривой JS, судя по всему). Так что пожелаем нашей крупнейшей отечественной ПС успехов и поможем в тестировании и отладке =)

Автор блога RMCreative нашёл замечательный сервис — pForm.

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

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

Во время проведения «Конкурса Конкурентов» Павел Воронин предложил создать единую RSS-ленту участников, используя для этого сервис Yahoo Pipes. К сожалению, что-то у нас там не вышло и сервс «ниасилил» аггрегацию такого количества потоков.

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

Feed.phps
Подумываю всё-таки реализовать идею коммьюнити-блога на основе аггрегатора по мотивам блога украинских разработчиков (ссылка в блогролле). Может, стоит устроить из этого реалити-шоу, описывая разработку и показывая код?

Кто что думает ?

В рамках проекта «Social Media Optimization PRO» Илья даёт всем желающим бесплатные советы по улучшению юзабилити и SMO оптимизации блога.

Поскольку 6-го октября начнётся работа над новым обликом этого блога, я решил послушать мнение опытного специалиста, каковым я считаю Илью.

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

• Добавить на страницу «Обо мне» фотографию автора блога.
  Думаю, можно.
• Сделать страничку «О блоге» с аннотацией, описанием тематики и списком полезных статей блога.
  Неплохая идея, сделаю.
• Установить виджет toodoo для пассивного продвижения, сбора голосов и отзывов.
  Надо посмотреть на него, может и правда стоит.
• Поставить большую картинку на подписку RSS вверх правой колонки.
  Ушло в ТЗ дизайнерам.
• Туда же поставить счетчики от Фидбернера и toodoo.
  Да, теперь это имеет смысл- цифры уже не стыдно показать.
• Также можно поставить форму подписки на емайл.
  Она висела, но оказалась невостребованна — кто-то один подписался и всё. Видимо, мои читатели знакомы с RSS.
• Организовать список самых популярных постов.
  Или плагин повешу, или руками сделаю, давно собирался.
• В конце текста поста поставить ссылки на заметки по теме.
  Надо как-то победить лень и сделать.
• Убрать директ в конце статей.
  Эх… Ну да ладно — доход от них, прямо скажем, невелик.

Курсив — это моё мнение по поводу совета. Ещё я подумываю сделать ТОП комментаторов и убрать с их ссылок nofollow. Кто что думает по поводу советов и будущих изменений ?

CAPTCHA (от англ. «Completely Automated Public Turing test to tell Computers and Humans Apart» — полностью автоматизированный публичный тест Тьюринга для различения компьютеров и людей) — торговая марка Университет Карнеги — Меллона, компьютерный тест, используемый для того чтобы определить, человек ли использует систему.

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

Существует готовое решение, которое можно просто взять и поставить на свой сайт, немного разобравшись в настройках: проект KCAPTCHA. Для его работы требуется только PHP версии 4.0.7 или выше с поддержкой библиотеки GD версии 2.

Как без особых усилий заставить PHP-код работать на порядок быстрее ? Перед тем как задаваться вопросами кеширования и масштабирования стоит попробовать оптимизировать код. Есть ряд несложных правил:

• Выносите переменные из строк. Примерно так: <?php $x=»test».$test; ?> , это на 25-40% быстрее.
• Имена переменных должны быть короче 7 символов. Это быстрее на 15%.
• В массивах не стоит обращаться к элементам по имени и без кавычек. Особенно в многомерных. Сэкономите 40%.
• А если обращение к элементу массива вынести из строки (как в пункте 1), то можно сэкономить ещё 25-30%.
• Используйте Perl-ориентированные регулярные выражения. Или хотя бы сравнивайте их с POSIX-аналогами по скорости выполнения. Скорость может отличаться до 200% на разных запросах.
• SizeOf() быстрее Count(), а в циклах sizeof лучше вообще заменить на переменную, for и while практически не отличимы, для перебора простых индексных массивов нужно использовать for или while, а для ассоциативных массивов — foreach. Плюс 30% при соблюдении.
• Для чтения файла file() быстрее, чем fopen()+цикл. Ускорение до 40%.

Прочитать про всё это подробнее, посмотреть графики скорости и загрузить все примеры можно вот тут: «Оптимизация программ на PHP».

Хотите поломать голову над задачкой по веб-программированию ? Пожалуйста. Есть код:

<table><tr><td background=#fff7eb id=message>
<?php mysql_query("INSERT INTO `res_action` (`type`, `date`, `id`, `from`, `to`, `text`, `viewed`, `hidden`)
VALUES ('hate', '08/08/07 12:15', 1070808121557, 'foo', 'bar', '', '0', '0')"); ?>
</td></tr></table>

При обработке такого кода происходит ошибка — запись добавляется в базу два раза. Стоит убрать из таблицы цвет фона — ошибка исчезает. В продолжении — ответ на задачу. Кто сообразит без подсказки ?

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

Google Sitemap — это один из довольно интересных инструментов от Google для веб-разработчиков, позволяющих в какой-то степени влиять на индексацию своих сайтов. Про то, что это такое и зачем это надо подробно написано самими разработчиками. «Скормить» sitemap консоли Google можно в четырёх форматах:

• Sitemap. Это созданный Google открытый XML-протокол.
• OAI-PMH — это инфраструктура взаимодействия на основе сбора метаданных. Не стоит это курить, я думаю.
• RSS-поток — каналы в формате RSS 2.0 и Atom 0.3.
• TXT — простой текстовый файл, содержащий один URL в каждой строке.

Сам Google рекомендует использовать первый вариант, так как он наиболее информативен для его пауков. Текстовый файл несет слишком мало информации, а OAI-PMH это что-то сугубо спецефическое. Интерес представляет возможность обработки RSS, особенно в свете покупки Google сервиса FeedBurner, обрабатывающего RSS-потоки.

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

Простейший файл с одним элементом и без необязательных параметров в формате Google Sitemap выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">
<url>
<loc>https://zhilinsky.ru/</loc>
</url>
</urlset>

Для его автоматического создания есть большое количество онлайн-сервисов.

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

Общий вывод довольно прост: глупо спорить о методах — суть не в них. Делать надо всё с умом.

Жилинский В.: Для меня блочная верстка удобнее — позволяет при программировании выкинуть из кода много мусора в tr и td и окончательно отделить контент от дизайна.

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

Так чем всё-таки таблицы от дивов при верстке принципиально отличаются ?

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

Но ведь всё равно есть различия, например, их видно на мобильной технике типа смартфонов или КПК — там сайты с разными методами верстки и смотрятся совсем по-разному.

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

И ещё такой момент — редизайн намного легче сделать с дивами — передвигать блоки можно вообще в автоматическом режиме. С таблицами — пыли наглотаешься от таких задач.

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

То есть основная мысль такая: верстать сайт нужно так, как сказал заказчик, потому что разницы нет, правильно ?

Мне пока еще не разу никто не говорил, как нужно верстать. Говорят, каков должен быть внешний вид, часто дают готовые эскизы. А верстаю наугад. Раз так, в другой раз эдак. Если заказчик скажет как-то определенно, сверстаю точно по желанию заказчика.

Ясно. Ну я, к примеру, если заказываю верстку, то пишу конкретно — вот тут блоками будет лучше, тут таблицу оставить.

Ты то разбираешься в верстке, а обычный заказчик часто даже не знает, что бывает верстка блоками, верстка таблицами.

Регулярные выражения (англ. regular expressions, жарг. регэкспы или регексы) — современная система поиска текстовых фрагментов в электронных документах, основанная на специальной системе записи образцов для поиска.

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

Во-первых, можно повесить на стенку шпаргалку по регулярным выражениям.

Во-вторых, есть замечательный инструмент — RegexPal.

Его видно на скриншоте. Этот скрипт позволяет на лету создавать и проверять шаблоны (паттерны) регэкспов, подсвечивает синтаксис и содержит подсказки. Кстати, этот скрипт можно сохранить — он работает независимо от сервера.

В-третьих, есть программа RegexBuddy, которую многие хвалят. Говорят, если с ней разобраться, то она очень удобна. Но она опять же денег стоит…

Ну и на закуску самая маленькая шпаргалка по регулярным выражениям:

. - любой символ кроме перевода строки.
^ - начало строки.
$ - конец строки.
\d,\w,\s - цифры, буквы [A-Za-z0-9_], пробел.
\D,\W,\S - всё кроме цифр, букв, пробела.
[abc] - буквы a, b, или c.
[a-z] - от a до z.
[^abc] - любой символ кроме a, b и c.
a|b - или a или b.
? - Ноль или один символов.
* - ноль или более символов.
+ - один или более символов.
{n} - точно n символов.
{n,} - n или более символов.
{m,n} - между m и n символов.