Мёртвый скроллбар в Опере

Обнаружил в Опере 9.24 ранее неизвестный баг. Следующий код порождает мёртвый горизонтальный скроллбар:

<div style="position: absolute; overflow: auto"><div>Тарам-пам-пам</div></div>

В других браузерах всё нормально.

Clearing floats

Кто-нибудь может объяснить, почему даже маститые верстальщики до сих пор используют монструозный Easy Clearing, в то время как ещё год назад PPK опубликовал гораздо более лаконичный Clearing floats? Сравните:

Easy Clearing:
.clearfix:after {
    content: "."; 
    display: block; 
    height: 0; 
    clear: both; 
    visibility: hidden;
}

/* MSIE6- */
* html .clearfix {
    height: 1%;
}

/* MSIE7- */
.clearfix {
    zoom: 1;
}

Clearing floats:
.clearfix {
    overflow: auto; width: 100%;
}

Множественный UPDATE

Если нужно обновить сразу несколько записей, необязательно делать UPDATE для каждой из них. В простейших случаях можно использовать следующий синтаксис:
UPDATE
	table
SET
	field = ELT(FIELD(id, $sIdList), $sValueList)
WHERE
	id IN ($sIdList)

Плюс: вместо пачки запросов всего один UPDATE.

Минус: MySQL-specific.

OR vs UNION

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

Решение «в лоб»:
SELECT
	object_id AS id,
	...
FROM
	object
WHERE
	thread_id = 123
	OR parent_id = 0

Проблема в том, что такой запрос не сможет использовать индексы.

В документации по MySQL предлагают оптимальное решение: заменить OR на UNION.
SELECT
	object_id AS id,
	...
FROM
	object
WHERE
	thread_id = 123
UNION
	SELECT
		object_id AS id,
		...
	FROM
		object
	WHERE
		parent_id = 0

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

Формат TIMESTAMP

В MySQL есть два похожих типа столбцов: DATETIME и TIMESTAMP. Одно из отличий состоит в том, что DATETIME имеет вид YYYY-MM-DD HH:MM:SS, а TIMESTAMP отображается как YYYYMMDDHHMMSS. С последним и выходит загвоздка: такое представление не поддерживают ни Парсер, ни другие известные мне языки. В MySQL 4.1 это поведение исправлено. Если же доступна только версия 4.0, приходится идти на ухищрения.

Первый способ: сразу приводить дату к необходимому формату средствами MySQL (DATE_FORMAT). Подходит в большинстве случаев и, к тому же, даёт выигрыш в скорости.

Второй способ я обнаружил случайно:

DATE_ADD(dt_update, INTERVAL 0 DAY) AS dt_update

или, в «терминах» класса Sql.p:

^pSQL.dateAdd[dt_update;0] AS dt_update

Применение функции DATE_ADD с нулевым интервалом приводит дату к формату YYYY-MM-DD HH:MM:SS, с которым уже можно работать в Парсере. Способ абсолютно безопасный: когда хостер наконец проапгрейдит MySQL до последней версии, этот код останется работоспособным.

Класс для RUpay

Написал на Парсере класс для работы с системой платежей RUpay. Схема стандартная: заказ формируется на сайте магазина и отправляется на сервер RUpay. Посетитель выбирает способ оплаты и переводит деньги. После получения платежа сервер RUpay посылает уведомление об оплате на сайт магазина. Collapse )

Долой www

Сегодня уже не только нет необходимости в использовании приставки www, но даже можно говорить о том, что она вредна, и мешает тем, что приходится прописывать для каждого сайтов два URL-адреса, программистам приходится учитывать два возможных обращения к сайту, а уж как неудобно произносить вслух эти «Вэ-Вэ-Вэ» или «Даблъю-Даблъю-Даблъю»…

Согласен с Русланом Курепиным, автором сайта nowww.ru, в абсолютной бесполезности префикса www. Но избавляться от него следует осторожно, особенно, если Ваш сайт уже проиндексирован поисковыми системами.

С Яндексом всё просто: достаточно добавить в файл robots.txt директиву Host: example.com. Она подскажет Яндексу, что основным зеркалом является домен без www. Это со временем отразится и на ссылках в результатах поиска.

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

Как только сайт будет подтверждён, Вы сможете выбрать для него основное доменное имя. По идее, это должно благотворно повлиять на PageRank, т. к. по умолчанию Гугл считает его отдельно для example.com и www.example.com. Гугловцы обещают (но не гарантируют), что это настройка повлияет на ссылки в результатах поиска.

А как настроить саму переадресацию? Я использую для этой цели mod_rewrite:
RewriteCond %{HTTP_HOST} ^www\.(.+)$
RewriteRule .*           http://%1/$0 [R=301]

HTTP-cтатус 301 означает, что страница переехала навсегда, а не временно.