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

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

Итак, у нас для начала уже есть сервер на котором настроен gitolite по адресу git.example.com, на нем расположен репозиторий myrepo в котором есть две основные ветки master и develop.

Общий принцип разработки такой:

1. При необходимости что-то доработать разработчик создает новую ветку из актуального состояния master
2. Делает в ней доработку и вливает ветку в develop
3. Проводится тестирование и если все хорошо, то ветка с доработкой вливается в master

Задача заключается в том, чтоб при изменениях в ветке develop они автоматически переносились в рабочую копию на хост develop.example.com, а изменения сделанные в master - на хост production.example.com.

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

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

Устройство составного индекса

Таблица для примера:

id | name   | age | gender
1  | Den    | 29  | male
2  | Alyona | 15  | female
3  | Putin  | 89  | tsar
4  | Petro  | 12  | male 

значения составного индекса будут такими:

age_gender
12male
15female
29male
89tsar 

Очередность колонок в индексе играет большую роль. Обычно колонки, которые используются в условиях WHERE, следует ставить в начало индекса. Колонки из ORDER BY — в конец.

Недавно мной было замечено, что если отправлять собственным скриптом multipart письмо на адрес @mail.ru, то оно приходит не корректно: в теле письма показывается часть заголовка и далее все части включая вложения в закодированном виде.

Происходит это ввиду того, что mail.ru почему-то не придерживается стандарта RFC, который регламентирует, что для переноса строк используется "combination CRLF (US-ASCII values 13 and 10) indicating a new line" оно же "\r\n" и заменяет такую конструкцию на двойной перевод строки, от этого нарушается разбор письма по стандарту и пользователю предлагается исходный текст письма.

Очень надеюсь, что mail.ru исправятся и будут нормально разбирать письма как все остальные, кто соблюдает стандарты, а пока временным решением является замена "\r\n" на "\n", после этого письма нормально разбираются нa mail.ru и становятся читабельными, также такой подход нормально воспринимается и другими почтовыми сервисами (gmail, yandex).

Ссылки по теме: RFC 822 и Википедия с полезной информацией и ссылками на другие RFC.

Попробую описать свой небольшой опыт накопленный за долгое время по созданию правильных редиректов средствами Apache. Все описанные методы применяются для поисковой оптимизации сайта, но могут быть полезны и для других целей. С точки зрения поисковика, редирект "permanent" или "301" делает страницу не значимой и прибавляет вес тому адресу, на который ссылается.

Первое правило: не нужно использовать директивы Redirect и RedirectMatch совместно с mod_rewrite, это поможет избежать многих мучений.

1. Дописывание WWW и наоборот

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

RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L] 

Здесь мы проверяем, что хост не начинается с www и отправляем на www.host + дописываем остальную часть урл. Аналогично можно сделать и отрывание www в случае его присутствия, но правила усложнятся.

2. Внутренние редиректы