С одной стороны их труд действительно достоин уважения. Они сделали относительно недорогое решение за короткий срок в условиях ограниченных финансовых возможностей. Причем, эту услугу они вывели на мертвый рынок Беларуси. С другой стороны фейлов в Active Cloud получилось немало. Как раз об этих фейлах я и хочу рассказать.

Все описанное ниже касается белорусского Active Cloud. Я не знаю, отличаются ли услуги, предоставляемые в других регионах. Возможно, там что-то по-другому.

Начнем с панелей. Их две: биллинг и управление облаком. Панель биллинга общая для всего-всего и включает управление всеми подписками, от доменов и DNS, до облака. В этой панели объединено все, кроме управления самими машинами в облаке. Используется стандартное решение от Parallels. Оно очень тяжелое — страницы долго грузится. Причем, дело не только в канале интернета, но и во времени генерации страниц.

Навигация в этой панели просто ужасная. Сходу не понятно ничего. Я до сих пор до конца не понял концептуальной логики построения этой панели (проще говоря — что где искать), хотя пользуюсь ей уже несколько месяцев. Я часто с трудом нахожу то, что мне надо. Причем, делать это приходится буквально методом тыка. До интуитивности пока очень далеко. Очень.

В панели биллинга много непонятной и лишней информации, в том числе, похоже, никому ненужных цифр. Примером может служить вкладка «Статистика и анализ». Это обратная сторона универсальности («коробочное» решение от Parallels). Есть и баги. Например, у меня не работает вкладка «Статистика трафика» — она просто не подгружается.

Кстати, интерфейс для общения с саппортом — отдельная тикетная система с базой знаний. Раньше она была топором врублена в биллинговую панель — было жутко неудобно. Похоже, разработчики это поняли и стали открывать ее в новом окне. Однако, она осталась неудобной. Слоновые заголовки, «потеря» страницы после F5 (это следствие отсутствия правильного URL в address bar), опять лишняя информация, причем частично на русском, частично на английском. Засоряют экран специальные уведомительные тикеты, которые плодятся вместе со счетами и виртуальными машинами. Здесь достаточно было бы уведомлений по e-mail.

Вторая панель — управление облаком от Cloud.com. Она тоже тяжелая и тормозящая, хотя и меньше биллинга. Не очень удобная навигация, многое приходится делать в два-три клика, когда можно было бы в один.

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

При создании виртуальной машины ей задается группа (вписывается в текстовое поле). Все группы видны в меню. Машину можно удалить, но при этом группа не удалится. И переименовать группу нельзя. Раздражает.

Консоль виртуальной машины вроде работает без Java. Но она сделана на картинках-слайсах. Т.е. при изменении изображения на виртуальном экране виртуальной машины (консоль или GUI) подгружается новые картинки-квадратики. Из-за этого консоль работает медленно и с большой задержкой. Пользоваться ей неудобно.

У Active.by классный сайт. У них в штате классный дизайнер. Но их панели — это полная противоположность их сайту. И дизайнер там почти не бывал.

Кроме того, в панелях были конкретные баги. Пару раз писал в саппорт, обещали поправить. Поправили или нет — не проверял.

Само облако поначалу сбоило. Лично мне несколько раз саппорт решал проблемы отвалившейся на моей ВМ сети. При мне сеть во всем облаке (толи целиком, толи в его куске) полностью падала на несколько часов. После этого столкнулся с тем, что свежеустановленная из образа Debian x64 не получала IP по DHCP на первом и всех последующих запусках (повторялось каждый раз). После обращения в саппорт проблема была решена за пару дней. Я был в шоке…

Надо отдать должное, что облако Active.by молодое. Оно было запущено в таком виде как сейчас в конце 2011 года. То, что описано выше, происходило в январе—феврале. Сейчас в марте проблем по доступности и функционированию машин и облака в целом замечено не было.

Изначально мы хотели перевести в облако свои серверы. Но сделать это не смогли. Основной причиной тому были непонятные проблемы с производительностью дисковой подсистемы. Хотя синтетические измерения вроде бы и выдавали нормальные скорости I/O, но фактическая производительность рабочего сервера на Windows у нас оказалась колоссально хуже, чем на аналогичном по конфигурации голом железе.

Возможно, проблемы были на большом количестве IOPS (частое чтение мелких блоков). Мы не выяснили это до конца. Но факт есть факт: то, что у нас нормально работает на физическом выделенном сервере, перенести в облако мы не смогли — сильно педалит. Причем, четко видно, что педалит не по CPU, и не по памяти. Педалит именно по дисковому I/O.

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

Мне нравится Active.by. Я желаю им успехов в развитии. И надеюсь, что мой пост поможет им раскрыть глаза на собственные недостатки и исправить их. Удачи им в этом!

Актуальность информации — апрель 2012 года.

1. Мы хотим контролировать скачивание больших файлов, проверяя права доступа или считая количество закачек. Мы используем nginx и PHP (или другой серверный язык).

Это реализуется очень просто через заголовок Accel-Redirect. nginx получает запрос, передает его скрипту, скрипт в заголовки ответа выдает Accel-Redirect с ссылкой на файл, который нужно выдать пользователю. Если файл выдавать нельзя (например, нет прав), скрипт просто выдаст ошибку (например, 403).

В данном случае не важно, работает ваш PHP через проксирование из nginx на Apache, либо на *CGI. Предположим, что вы хотите отдавать на скачку файлы, которые находятся в каталоге /var/files. Тогда в секции server в nginx добавьте:

location /_download_files {
        root /var/files;
        internal;
}

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

header("X-Accel-Redirect: /_download_files/filename.zip");

Никакой выдачи (echo) делать не надо, после отдачи заголовка можно завершить работу скрипта. В этом случае будет скачан файл /var/files/filename.zip. Вместо filename.zip может быть любой длинный путь с каталогами, который должен повторять путь к файлу в /var/files/.

В принципе этого достаточно, чтобы переложить выдачу файла на плечи nginx. Если нужно обязательно показать диалог закачки (даже если файл такого типа, который браузер может показать сам), нужно добавить выдачу заголовка:

header("Content-Type: application/x-force-download");

Обратите так же внимание на то, что в случае проксирования на Apache последний обязательно установит Content-Type (по умолчанию обычно text/html) в случае PHP-скриптов, и этот тип отправится пользователю, так как nginx его не перепишет при выполнении Accel-Redirect. Т.е. в этом случае эту строку нужно писать обязательно. Как будет в случаях с *CGI, не знаю — не проверял.

Чтобы предложить пользователю имя файла для сохранения, отличное от того, что в адресной строке (это особо актуально в случаях «download.php&file_id=12332»), отправим такой заголовок:

Content-Disposition: attachment; filename="Super File Name.zip";

2. В такой схеме при проксировании на Apache не работает докачка. Исправляем.

Докачка в HTTP работает через HTTP-заголовок Range. В нем указывается с какого байта начать передачу. Можно так же указать, сколько байт нужно передать. Это передается в запросе. Например:

Range: bytes=33-
Range: bytes=33-100

Первый вариант просит отдать весь файл, начиная с 33 байта (включительно). Второй вариант просит отдать с 33 байта по 100. Чтобы браузер понял, что докачка поддерживается, сервер отдает в ответе заголовок:

Accept-Ranges: bytes

Докачка не работает из-за того, что HTTP-заголовок Range попадает в Apache после просирования и последний думает, что его просят отдать кусок PHP-файла. А он это делать не хочет и отдает ошибку: HTTP/1.1 416 Requested Range Not Satisfiable.

Исправляется это довольно легко — просто зануляйте при проксировании Range (это нужно добавить туда, где у вас описано проксирование на Apache в конфиге nginx):

proxy_set_header   Range   "";

Тогда Apache (или PHP-скрипт) ничего знать про него не будут и спокойно сделают свое дело. А nginx после Accel-Redirect отдаст ответ в соответствии с запрошенным Range.

Если жизненно необходимо видеть в скрипте запрошенный Range, то его можно либо передать через дополнительный заголовок при проксировании (proxy_add_header), либо последовать совету отсюда.

3. Даже так не работает докачка в IE 9.

Да. На сколько я понял методом простого тыка, IE требует поддержки ETag сервером для работы докачки. Игорь Сысоев (разработчик nginx) отказался внедрять в nginx поддержку ETag. Поэтому из коробки работать докачка в IE 9 не будет точно. Если это жизненно необходимо, пробуйте смотреть сюда (Ctrl+F Etag).

4. А как работает докачка в других браузерах?

Везде есть свои особенности. В общих чертах случай докачки выглядит так. Запрос/ответ на скачку (начало скачки):

GET /file.zip HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Server: nginx/1.0.3
Date: Tue, 06 Mar 2012 18:09:47 GMT
Content-Type: application/x-force-download
Content-Length: 13686314
Last-Modified: Thu, 23 Feb 2012 13:50:26 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Disposition: attachment; filename="Supre File Name.zip";
Accept-Ranges: bytes

Запрос/ответ на докачку:

GET /file.zip HTTP/1.1
Host: example.com
Range: bytes=5393683-

HTTP/1.1 206 Partial Content
Server: nginx/1.0.3
Date: Tue, 06 Mar 2012 18:10:11 GMT
Content-Type: application/x-force-download
Content-Length: 8292631
Last-Modified: Thu, 23 Feb 2012 13:50:26 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Disposition: attachment; filename="Super File Name.zip";
Content-Range: bytes 5393683-13686313/13686314

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

Opera. Она шлет указание на то, что «если файл не менялся со времени Last-Modified в первом ответе, дай мне указанный кусок; иначе — отдай мне весь файл заново». Делается это с помощью заголовка If-Range в запросе:

GET /file.zip HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.10.229 Version/11.61
Host: example.com
Accept text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, ..., */*;q=0.1
Accept-Language: ru-RU,ru;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
If-Range: Thu, 23 Feb 2012 13:50:26 GMT
Range: bytes=5393683-

Firefox. Он делает немного иначе. Используется заголовок If-Unmodified-Since с указанием того же времени из Last-Modified. В этом случае сервер либо вернет запрошенный кусок (если файл не менялся), либо отдаст ошибку 412 Precondition Failed. Выглядит это так:

GET /file.zip HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Range: bytes=5878651-
If-Unmodified-Since: Thu, 23 Feb 2012 13:50:26 GMT

Chrome. Этот «пильмень» — самый хитрый. Он вообще не поддерживает докачку, хотя делает вид, что поддерживает. При постановке закачка на паузу он просто шлет некие TCP-пакеты для поддержания соединения. Когда сервер понимает, что его дурят, он разрывает соединение. Если дождаться этого момента и нажать в Хроме «Продолжить», он сделает умный вид, будто файл полностью скачался и все ОК, но при этом он останется в том размере, в котором успел скачаться до паузы.

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

IE. Про версию 9 уже сказано выше. Она требует работы Etag для поддержки докачки. В данном контексте ETag — это просто контрольная сумма файла. Когда Etag файла передается в первом ответе от сервера, IE даст возможность прервать скачку. При попытке докачки он отдаст заголовки:

GET /file.zip HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: falcongaze.com
Range: bytes=3494051-
Unless-Modified-Since: Mon, 05 Mar 2012 08:31:06 GMT
If-Range: "1448453-f77f31-4ba7abf5a8680"
Connection: Keep-Alive

В добавок к If-Range он передает нестадартный заголовок Unless-Modified-Since — вероятено IIS его обрабатывает (только не понятно, зачем он, если есть стандартный If-Unmodified-Since; может для поддержки старых версий IIS?).

Собственно в первом ответе Etag выглядит примерно так (если он поддерживается сервером, например, Apache):

...
ETag: "1448453-f77f31-4ba7abf5a8680"

Дополнительная информация:

• RFC 2616. Header Field Definitions;
• List of HTTP header fields.

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

Подробнее о подходе и принципах Getting Real написано в главе 1 «Введение».

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

Но авторы несколько раз обращают внимание на то, что Getting Real легко проецируется на другие области работы и жизни:

«Хоть внимание и акцентируется на разработке веб-приложений, идеи применимы к действиям вне этой сферы. Предложения маленьких групп, быстром создании макетов, ожидание итераций и многие другие могут служить руководством, запускаете ли вы бизнес, пишете ли книгу, проектируете ли веб-сайт, записываете ли альбом или делаете что-то другое. Как только вы начнёте следовать принципам Getting Real в одной области жизни, вы поймёте, как это можно использовать в других областях».

Стиль написания свободный. Настроения авторов революционные.

«Потерпите нас. Мы считаем — лучше представить идеи резко, чем тихо шептать об этом на ухо. Если это кажется дерзким и высокомерным, пусть так и будет. Мы предпочитаем быть «провокаторами», чем постоянно ныть «может быть, если…». Конечно, будут времена, когда эти правила должны будут измениться или исчезнуть. И некоторые из этих тактик, возможно, не подходят к вашей ситуации. У вас есть своя голова на плечах, решайте сами».

Авторы обращают внимание на реальные проблемы, с которыми разработчики и менеджеры сталкиваются изо дня в день, но при этом порой их даже не замечают (не принимают за проблемы), или пытаются закрыть на них глаза. В то же время книга призывает откинуть ряд надуманных проблем, которые возникают из-за чрезмерной бюрократизации процессов разработки, попыток сделать всё и сразу, неправильного подхода к планам и срокам. Этих проблем может вовсе не стать, если применять подход Getting Real.

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

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

Глава 2. «Начало»

«Сделайте меньше чем ваши конкуренты, чтобы ударить по ним. Решайте простые проблемы и оставьте сложные, противные проблемы всем остальным. Вместо превосходства попробуйте делать недостаточно».

Пишите программы для себя.

«Если вы решаете собственную проблему, вы создаёте инструмент с душой. И это является ключевым. Это означает, что вы сделаете всё отлично. И это является лучшим вариантом».

Финансируйте себя сами.

«Сейчас, чтобы начать, не требуется многого. Аппаратные средства дешевы и большое количество ПО бесплатно и имеет открытые исходные коды. И страсть не приходит с ценником».

Фиксируйте время и бюджет.

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

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

В начале пусть лучше будет меньше запланированных возможностей, чем потом будет посредственный, громоздкий и с кучей дыр безопасности результат. Оставьте волшебство Копперфильду. У вас реальный бизнес и реальный продукт».

Заведите себе врага.

«Иногда лучший способ узнать, каким должно быть ваше приложение — это узнать, каким оно не должно быть. Пусть это будет врагом вашего приложения, и вы будете видеть свет, на который вы должны идти».

Меньше рутины.

«Чем меньше в вашем приложении рутины — тем лучше.

Если рутинной работы немного и она управляема — вы можете наслаждаться».

Глава 3. «Оставайтесь небольшими».

Меньше размеры.

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

Снизьте стоимость перемен.

«Перемены — ваш лучший друг. Чем выше их цена, тем меньше их вероятность. И если ваши конкуренты могут меняться быстрее вас, вы в крайне невыгодном положении. Если цена перемен становится слишком высока — вам конец».

Начните с троих.

«Чтобы выпустить первую версию вашего продукта, можно начать только с тремя людьми. Это магическая число, которое обеспечит вам достаточный человеческий ресурс и в то же время позволит оставаться быстрым и проворным. Начните с разработчиком, дизайнером, и человеком, — который разбирается в том и другом».

Принимайте ограничения.

«Пусть ограничения ведут вас к творческим решениям».

Будьте собой.

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

Глава 4. «Приоритеты».

В чем идея?

«Найдите свою большую идею и примите решение о видении, все маленькие решения в будущем станут проще и легче».

Пренебрегайте деталями в начале.

«Успех и удовлетворение находится в деталях.

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

Проблема тогда, когда это проблема.

«Вам действительно нужно волноваться о вычислениях для 100 000 потребителей сегодня, если это будет у вас через два года?

[…]

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

Сосредоточтесь на своих клиентах.

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

Если вы ориентируетесь на всех, вы не удовлетворите никого».

Расширяйтесь и оптимизируйтесь позже.

«В начале, сделайте основу продукта, вместо масштабируемости. Создайте большое приложение, а затем тревожьтесь о том, что делать, как только оно стало успешным. Иначе вы, возможно, расточаете энергию, время, и деньги, фокусируетесь на том, что может никогда не случиться».

Делайте идейное ПО.

«Лучшее программное обеспечение имеет свое виденье. Лучшее программное обеспечение лавирует между потребностями. Когда кто-нибудь использует программное обеспечение, они не только, ищут особенности, они ищут подход. Они ищут видение для решения своих задач. Решите, что такое — ваше виденье и идите с этим».

Глава 5. «Выбор функций».

Лучше хорошая половина, чем плохое целое.

«Остерегайтесь подхода в развитии сетевого приложения, в котором все готово, но вот что-то не работает и это что-то очень важное.

[…]

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

Это не имеет значения.

«Наш любимый ответ на вопрос «Почему вы не сделали это или почему вы не сделали то?». Всегда такой: «Поскольку это не имеет значения».

Меньше функций.

«Сделайте добавление функций, трудно осуществимой задачей. Пусть каждая функция и особенность доказывает, что ее надо оставить в живых. Подобно «Бойцовскому клубу». Вы должны рассматривать только те функции и особенности, которые были протестированы в течение трех дней и за это время были востребованы максимально.

[…]

Для каждой новой функции от вас потребуется:

• 1. Сказать «нет».
• 2. Вынудить функцию доказать свое значение.
• 3. Если снова «нет», уже конец. Если, «да», продолжайте…»

Можете ли управлять этим?

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

Решение задач пользователей.

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

Забудьте о запросах функций.

«А что вы делаете со всеми этими запросами, которые к вам поступают? Где вы их храните? Как вы управляете ими? Вы этого не делаете. Просто читаете их, а затем отбрасываете.

[…] Пусть ваши клиенты будут вашей памятью. Если это действительно стоящая функция, они будут напоминать вам, пока вы не сможете не забыть».

Глава 6. «Процесс».

Запустите программу быстрее.

«С запуском программы в реальную работу, вы добирается до истинного понимания того, как она должна работать. Вы избегаете бурных разговоров, эскизов и длинных текстов, которые отдаляют вас от сути. Вы осознаете, какие мысли были тривиальны, а какие критически неприемлемы».

Не всё с первого раза.

«Не ожидайте того, что будете все понимать и делать правильно с первого раза. Пусть приложение растет и общается с вами. Позвольте ему трансформироваться и эволюционировать».

От идеи до реализации.

«Перейдите от мозговых штурмов — к эскизам — к HTML — к кодированию».

Избегайте настроек.

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

[…]

Вы сталкиваетесь с ограничением: сколько сообщений должно быть на странице? Ваша первая мысль сделать выбор 25, 50 или 100. Это легкий выход. Просто примите решение, как сделать лучше. И выберите одно число».

Сделано!

«Сделано! Это волшебное слово. Когда вы уже сделали — вы получили опыт и можете идти дальше.

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

Тестируйте в реальных условиях.

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

Глава 7. «Организация».

Не разделяйте лишний раз.

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

Единое время.

«Известно, что многие люди предпочитают работать рано утром или поздно вечером — это время когда их не беспокоят, это время самое продуктивное для них. Это время становится таким, потому что никто не прерывает работу, и никто не отвлекает.

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

Встречи ядовиты.

«Вам действительно нужны встречи? Встречи обычно возникают, когда что-то не достаточно ясно. Вместо встречи, попытайтесь упростить обсуждение и воспользуйтесь мессенджером или Campfire. Минута встречи крадет минуту реальной работы. Поставьте себе цель — избегать встреч».

Маленькие победы.

«Долгие, затянутые циклы разработки — убийцы мотивации. Это слишком долгое время между празднованием побед. Быстрые победы — факторы мотивации. Если вы допускаете длинные циклы разработки — вы убиваете мотивацию. И это может убить ваш продукт».

Глава 8. «Персонал».

Нанимайте меньше, нанимайте позже.

«Так что не нанимайте. Серъезно, не нанимайте никого. Взгляните на это с другой стороны — действительно ли работа, которая вас отягощает, так необходима? Что случиться, если вы просто её не сделаете? Можете ли вы решить проблему с данной частью системы другим способом?»

Проверяйте.

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

Не по словам, а по делам.

«Проекты с открытым кодом — находка для того, кто ищет техперсонал. Они дают вам возможность следить длительное время за работой того или иного специалиста.

Это значит, вы можете оценивать людей по-сделанному, а не по-сказанному».

Нанимайте эрудитов.

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

В маленьких командах нужны мастера «на все руки».

Неподдельный энтузиазм.

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

Нанимайте хороших писателей.

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

Глава 9. «Создание интерфейса».

Сначала — интерфейс.

«Слишком много приложений создаются с подходом «сначала программируем». Это неудачная идея. Программирование — самое сложное в создании приложения, а это значит, что и самая дорогая. И создав код, вам будет сложно его изменить. Вместо этого начинайте с дизайна интерфейса.

[…]

Другая причина для того, чтобы начинать с дизайна в том, что интерфейс и есть продукт. Вы продаете людям то, что они видят. И если вы оставите интерфейс «на потом», огрехи будут заметны».

Дизайн от эпицентра.

«Без чего страница аобсолютно не может быть — это без эпицентра. К примеру, если вы разрабатываете страницу, которая показывает пост в блоге, пост — это и есть эпицентр. Не категории в сайдбаре, не заголовок страницы, не форма комментариев внизу, а именно пост. Без поста эта страница бессмысленна».

Три состояния программы.

«Для каждого экрана вы должны рассмотреть три состояния:

• Обычное
  Экран, который люди видят каждый день при работе с приложением, заполненным данными.
• Пустое
  Экран, который люди видят при первом запуске, и ещё не успели ввести данные.
• Ошибка!
  Экран, который люди видят, когда что-то идёт не так».

С самого начала.

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

Защищайтесь.

«Посмотрим правде в глаза: неполадки обязательно будут происходить. Как бы тщательно вы не проектировали приложение, сколько бы времени не посвятили тестированию, у клиентов все равно будут случаться проблемы. Так как вы будете обрабатывать эти поломки? С помощью оборонительного дизайна.

[…]

Помните: ваше приложение может работать отлично в 90% случаев. Но если вы бросаете пользователей на произвол судьбы там, где ваша помощь им нужна – они вряд ли это забудут».

Содержание важнее целостности.

«Это нормально — сделать дизайн непоследовательным, если в этом есть смысл. Давайте людям то, что имеет смысл. Давайте то, что им нужно, и избавте от того, что лишнее. Уместность лучше последовательности».

Дизайн интерфейсов — это копирайтинг.

«Если вы думаете что каждый пиксель, каждая иконка, каждый шрифт имеет значение, вы поверите и в значимость каждой буквы. Когда вы описываете свой интерфейс, всегда смотрите на него глазами пользователей. Что они должны знать? Как это объяснить лаконично и доходчиво?»

Единый интерфейс.

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

Не создавайте отдельного интерфейса для настроек, просто встройте его функции в основной».

Глава 10. «Код».

Меньший объем программы.

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

Оптимизируйте для счастья.

«Счастливый программист — продуктивный программист. Вот почему мы оптимизируем удовлетворенность работой, и вам тоже стоит это делать. Выбирайте инструменты, базируясь не только на стандартах отрасли или производительности. Смотрите на неосязаемые факторы: чувствуется ли в инструменте страсть, гордость и мастерство? Будете ли вы по-настоящему счастливы, работая в этой среде восемь часов в день?

[…]

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

Говорит код.

«Прислушивайтесь к своему коду. Он будет высказывать предложения. Он будет сопротивляться. Он расскажет, где стоят ловушки. Он предложит новые пути решений. Он поможет вам держаться модели меньшего объема программы».

Разберитесь с долгами.

«Наваяли блок кода, который функционален, но все еще неопрятен – вот вы и набрали долгов. Набросали дизайн по принципу “и так сойдет” – ваши долги выросли опять.

Время от времени так поступать можно. Часто такая техника помогает поскорее довести проект в стиле Get Real до конца. Но все равно нужно признать эти долги и рано или поздно расплатиться с ними – вычистить неопрятный код, переделать ту страницу, которая была сделана так себе».

Открытые двери.

«Не пытайтесь запереть ваших клиентов. Позвольте им получить принадлежащую им информацию когда они хотят и как они хотят. Для этого вам придется отказаться от идеи запечатать данные. Выпустите их. Дайте людям доступ к их информации через RSS. Обеспечьте API, позволяющие другим разработчикам подсоединяться к вашей программе. Поступая так, вы облегчаете жизнь клиентам и расширяете возможности своей программы».

Глава 11. «Слова».

В функциональной спецификации нет ни грамма функциональности.

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

Не рождайте мертвых документов.

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

Расскажите короткую историю.

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

Пользуйтесь обычными словами.

«Вставьте настоящий текст вместо lorem ipsum».

Очеловечьте ваш продукт.

«Подумайте о своем продукте как о человеке. Каким человеком вы бы хотели его видеть? Вежливым? Неумолимым? Прощающим? Требовательным? Веселым? Бесстрастным? Серьезным? Разболтанным? Хотите, чтобы он выглядел параноидальным или доверяющим? Всезнайкой? Или скромным и обаятельным?»

Глава 12. «Цена и регистрация».

Бесплатные образцы.

«Раздавайте что-нибудь бесплатно

Мир полон шума и суеты. Чтобы вас заметили среди всего этого, раздавайте что-нибудь бесплатно».

Легко войти, легко выйти

«Сделайте начало использования вашей программы — и окончание использования — как можно проще».

Раскраски.

«Все эти «Растишки», зайчишки и прочие завлекушки с наклейками и раскрасками — уловки для детей».

Подсластите пилюлю.

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

Глава 13. «Продвижение».

Выпуск в голливудском стиле.

«Если выпустить программу в лесу, где ее некому использовать, произведет ли она фурор? Мы о том, что если выпустить программу без предварительной подготовки, то, скорее всего, никто о ней не узнает».

Мощный сайт для продвижения.

«Лучшее средство для продвижения продукта – сам продукт. Если вы создали приложение, которое действительно нужно клиентам, об этом непременно узнают.

Тем не менее, вам все равно нужен мощный сайт для продвижения. Что туда можно поместить?»

На волне блогов.

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

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

Начинайте рекламировать как можно раньше.

Продвижение через обучение.

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

Пища функциональности.

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

[…]

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

Следите за логами.

«Вам полезно знать, кто о вас говорит. Проверьте свои логи и узнайте, что откуда берется. Кто на вас ссылается? Кто ругается? Какие из блогов, попавшие в списки на Technorati, Blogdex, Feedster, Del.icio.us и Daypop, говорят о вас?»

Продажи в процессе.

«Существующие клиенты – ваш наиболее перспективный рынок для дальнейших продаж. Не стесняйтесь развивать бизнес с теми, кто уже знает и использует ваш продукт».

На крючке названия.

«Многие совершают большую ошибку, когда считают, что название продукта должно быть сверхинформативным. Не стоит выбирать название, которое содержит детальное описание продукта. Обычно в результате выходит немудреное и легко забывающееся название. Название Basecamр лучше, чем что-то типа Project Management Center или ProjectExpress. Writeboard – лучше, чем CollaborEdit».

Глава 14. «Поддержка».

Почувствуйте эту боль.

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

Нулевое обучение.

«Чтобы пользоваться сайтами Яндекса, Гугла или Озона, вам не нужны учебники или справочники. Почему бы вам не создать продукт, которому они тоже не нужны? Стремитесь создать продукт, не требующий обучения».

Отвечайте быстро.

«Пользователям нравится прямота, и часто их недовольство на глазах превращаются в вежливость, когда вы отвечаете быстро и прямо».

Трудная любовь.

«Будьте готовы сказать “нет” своим пользователям

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

[…]

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

В хорошей компании.

«Форумы и сетевые групповые чаты – хороший способ дать пользователям возможность задавать вопросы и помогать друг другу. Путем убирания посредника — то бишь вас — вы обеспечиваете открытый поток общения и экономите свое время».

Публикуйте ваши неудачи.

«Выпустите плохие новости и уберите их с дороги

Если что-либо пошло не так, расскажите людям. Даже если они не заметили».

Глава 15. «После выпуска».

Быстрое обновление.

«Выпустите обновление через 30 дней после выпуска

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

Продолжайте выпуск сообщений.

«Покажите, что ваш продукт живет – продолжайте блог продукта после выпуска».

Не бета, а лучше.

«В наши дни кажется, что все постоянно находится в бета-версии. Неумирающая бета-версия говорит пользователям, что вы не так уж и хотите выпускать завершенный продукт. Она говорит: “Пользуйтесь вот этим, но если оно несовершенно – это не наша вина”».

Не все ошибки в программе созданы равными.

«Если вы нашли ошибку в вашем продукте – это не повод впадать в панику. Все программы содержат ошибки, это просто неоспоримый факт.

Не нужно сразу же исправлять каждую ошибку. Большинство ошибок надоедливы, но не смертельны. Те, которые надоедливы, могут быть отложены. Ошибки типа “что-то тут выглядит не так” и подобные можно без ущерба отложить на некоторое время. А уж если ошибка ломает вашу базу данных – тогда, конечно, она должна быть исправлена немедленно».

Переждите шторм.

«Если раскачивать лодку, появляются волны. Когда вы добавляете новую функцию, изменяете правила или удаляете что-нибудь – реакции будут разными, и часто отрицательными.

Избегайте паники и желания быстро все поменять в ответ».

Не отставайте от соседей.

«Подпишитесь на новости и о своих продуктах, и о продуктах конкурентов (это всегда мудро – следить за передвижениями противника)».

Остерегайтесь монстра разбухания.

«С развитием событий не бойтесь противостоять разбуханию. Всегда будет соблазн расширять продукт в объеме. Но это делать не обязательно. То, что продукт растет и становится более зрелым – не должно значить, что и более сложным».

Двигайтесь по течению.

«То, что придает красоту сетевым приложениям – это их изменяемость. Вы не упаковываете программу в коробочку, поставляете пользователю, а потом ждете новой версии в течение многих лет. Напротив, вы можете вносить изменения по пути. Примите мысль, что ваша первоначальная идея могла быть не самой лучшей».

Глава 16. «Заключение».

Готово!

«Ну хорошо, вы это сделали! Надеемся, вы с нетерпением ждете момента, чтобы начать применять Getting Real в своих программах. Сейчас самое лучшее время, чтобы создавать отличные программы, используя минимум ресурсов. При наличии хорошей идеи, страсти, времени и навыков – выше только небо».

Воплощение.

«Каждый может прочесть книгу. Каждый может придумать идею. У каждого есть родственник, работающий веб-дизайнером. Каждый может завести блог. Каждый может нанять кого-то еще, чтобы вместе наваять какой-то код.

Разница между вами и всеми остальными в том, как хорошо вы воплощаете. Успех достигается именно безупречным воплощением».

Люди.

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

***

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

Чтобы решить проблему отказа серверов Gmail от обслуживания  при отправке большого числа писем на несуществующие адреса, используем для отправки почты из скриптов сайта локальный почтовый SMTP-сервер (MTA). Локальный сервер будет выступать в качестве mail relay. В дополнение мы откажемся от подключения из скрипта к удаленному серверу, что может быть медленно. Локальные подключения всегда должны быть быстрее и стабильнее.

Локальный сервер мы будем использовать только для отправки писем. Причем, не важно, как будет происходить отправка: непосредственно через SMTP, или с помощью MUA. Получение почты по-прежнему будет происходить с серверов Gmail.

В дистрибутиве Debian 5 по умолчанию устанавливается MTA Exim4. Он отлично подойдет для наших задач. Причем его настройка производится с помощью мастера и невероятно проста. Настроить сервер требуется на прием соединений исключительно с локального соединения. При этом не нужно поручать ему обслуживание доменов, кроме дефолтного локального (localhost).

Итак, если Exim у вас не установлен, то установим его:

# aptitude install exim4

Далее запускаем его конфигурацию:

# dpkg-reconfigure exim4-config

1. На первом шаге необходимо выбрать конфигурацию сервера. В Exim есть несколько стандартных конфигураций, предназначенных для разных случаев. Подробнее о них в мануале. Нам нужна конфигурация “internet site; mail is sent and received directly using SMTP”.

2. Далее укажите имя сервера. Оно будет передаваться в SMTP-протоколе в команде HELLO, т.е. будет видно получателям вашей почты. Лучше всего, чтобы это имя совпадало с доменом, с которого шлется почта. Например, valera.ws.

Если у вас на сервере несколько сайтов с разными доменами (см. ниже), то лучше это имя сделать нейтральным, чтобы «не палиться». Например, можно выбрать local-mail-agent.

3. Далее требуется указать, какие интерфейсы должен слушать Exim. В нашем случае удаленные подключения мало того, что не нужны, так еще и опасны: кто угодно сможет рассылать почту через ваш сервер. Указываем только 127.0.0.1.

4. Далее спрашивается, какие домены должен обслуживать сервер. Т.е. для каких доменов не нужно пересылать письма на удаленные SMTP-сервера, пользователь заберет их с этого сервера. Нам не нужно обслуживание наших доменов. Можно указать только localhost, т.к. его больше обслужить некому.

Не указывайте здесь адрес вашего сервера (подставляется по умолчанию), т.к. его обслуживание делегировано Gmail. Если его указать, то письма, отправленные на ящики вашего домена, в Gmail не попадут и останутся на сервере. Это не нужно.

5. Далее можно указать, для каких доменов сервер должен служить релеем (список через точку с запятой). Здесь не указываем ничего, так как на следующем шаге мы разрешим себе релей для всех доменов. Можете указать список ваших доменов.

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

При этой конфигурации есть один негативный момент. Если ваш сайт поломают, то злоумышленники смогут слать почту с любых доменов через ваш сервер. Если на сервере 1—2 сайта, то лучше на этом шаге оставить поле пустым, а на предыдущем шаге внести список этих доменов (для возврата на шаг назад нажмите кнопку “Cancel”). При появлении новых доменов не забывайте их заносить в конфиг. Если вы считаете свои сайты надежными, то проще всего указывать здесь 127.0.0.1.

7. Дале уточняется, является ли для нас проблемой постоянные DNS-запросы при отправке каждого письма. В 99,9% это не проблема, так что выбираем ответ на вопрос “Keep number of DNS-queries minimal (Dial-on-Demand)?” “No”.

8. Где хранить локальную почту (помните, мы указали серверу обслуживать домен localhost?) нам по сути не важно, так как этим как правило никто не пользуется. Можно выбрать вариант по умолчанию: складывать все в /var/mail.

9. Предпоследний шаг — выбор конфигурации. Хранить все в одном файле, или раскидать по множеству мелких файлов. В большой файл проще вносить большие изменения, а с мелкими проще работать в случае мелких правок. Выберите вариант на свой вкус. Я выбрал “unsplit configuration” (ответ “No”).

10. На последнем шаге укажем на какой аккаунт реального пользователя системы пересылать сообщения, отправленные на служебные аккаунты postmaster, root и т.д. Здесь имеет смысл указать ваше имя пользователя в системе.

Переконфигурировать Exim в любой момент можно тем же способом. Мастер подставит в значения по умолчанию текущие значения вашей конфигурации.

Правильная настройка SPF

Если кратко, то SPF — это способ борьбы со спамом.

Мы собираемся отправлять почту с сервера, PTR IP которого не равен одной из MX-записей сервера, а так же в большинстве случаев PTR IP не равен самому нашему домену (не всегда хостеры соглашаются менять PTR). В этом случае вероятность попадания писем в спам повышается. Но есть хороший способ ее понизить: указать правильно запись SPF нашего домена.

SPF-запись — это обыкновенная запись доменной зоны, имеющая тип TXT. Узнать текущее ее значение для домена можно с помощью команды host в Linux:

$ host -t TXT valera.ws
valera.ws TXT record currently not present

В данном примере SPF-запись не задана. Зададим ее. С моего домена почта может отправляться с серверов Gmail и с моего сервера. Для начала узнаем, какой PTR моего сайта (valera.ws):

$ nslookup valera.ws
Server:      194.224.52.4
Address:     194.224.52.4#53

Non-authoritative answer:
Name:     valera.ws
Address:  93.174.6.118

IP-адрес моего сервера 93.174.6.118. Узнаем PTR:

$ nslookup 93.174.6.118
Server:      194.224.52.4
Address:     194.224.52.4#53

Non-authoritative answer:
118.6.174.93.in-addr.arpa name = server.valera.ws.

Видно, что PTR IP, к которому привязан мой домен (IP моего сервера) — server.valera.ws.

v=spf1 a mx ptr include:_spf.google.com ~all

По порядку:

• v=spf1 — версия SPF (первая);
• a — разрешение отправлять почту с IP, указанного в A-записи домена (собственно с сервера, на который ваш домен ссылается);
• mx — разрешение отправлять почту с IP, указанных в MX-записях домена (в нашем случае сервера Gmail);
• ptr — разрешение отправлять почту с IP, PTR-запись которых содержит ваш домен (т.е. сам домен и поддомены);
• include:_spf.google.com — подключение разрешений для серверов отправки почту Gmail (совсем не обязательно почта будет слаться с серверов, указанных в MX-записи);
• ~all — нейтральная реакция на всю остальную почту; здесь можно указать -all, что будет значить, что почта, не попадающая под эти правила, — спам.

Если вы хотите отправлять почту с сервера, не попадающего под все эти правила, его можно указать по IP или домену PTR, например:

v=spf1 a mx ptr ptr:example.com include:_spf.google.com ~all

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

valera.ws.      TXT      v=spf1 a mx ptr include:_spf.google.com ~all

После обновления зоны host выдаст следующее:

$ host -t TXT valera.ws
valera.ws      TXT      «v=spf1 a mx ptr include:_spf.google.com ~all»

PHP mail()

После всей этой настройки функция mail() в PHP начнет слать почту через ваш локальный сервер на законных основаниях для антиспам-ботов. Но косяк будет в том, что в поле отправителя будет фигурировать адрес системного пользователя www-data@localdomain. Нас это не устраивает. Чтобы почта правильно слалась из mail(), необходимо использовать ее дополнительный параметр.

bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )

Именно $additional_parameters нас и интерисует. В него надо передавать реального отправителя:

mail($to, $subject, $message, $additional_headers, $additional_parameters.» -frealsender@valera.ws»);

Указывается отправитель слитно с параметром -f.

Теперь отправленные через mail() письма будут абсолютно адекватны (при условии, что вы указываете все нужные SMTP-заголовки, вроде “FROM:”, “TO:” и т.д.).

А если несколько сайтов с разными IP (настройка Exim для отправки писем с разных IP)?

Мы хотим использовать локальный SMTP-сервер для отправки почты со всех сайтов на сервере. Никаких проблем нет, если настроен Exim правильно (см. выше). Но проблема появляется, если разные сайты работают на разных IP. Мы не хотим в почте «палить» то, что все наши сайты живут на одном сервере. Но Exim по умолчанию шлет всю почту с основного (первого) IP сетевого интерфейса, а этот IP всем получателям в SMTP-заголовках “Received:” письма. Кроме того, там указывается и имя сервера, которые мы в случае с разными сайтами на сервере выбрали нейтральными.

Чтобы не «палить» IP сервера, нужно отсылать письмо на удаленный сервер с IP, равного A-записи домена сайта. Делается это несложно путем изменения конфига Exim. Внесем изменения в настройки транспорта SMTP Exim. Если вы выбрали монолитный конфиг, то нужно отредактировать файл:

# nano /etc/exim4/exim4.conf.template

Находим в файле строку “remote_smtp:” (поиск в nano — F6). Добавляем в конец этого блока:

interface = «${lookup{$sender_address_domain}lsearch{/usr/share/exim4/domain2ip}{$value}}»
helo_data = «$sender_address_domain»

Это значит, что при отправке письма нужно определить домен отправителя почты (для sender@valera.ws это valera.ws) и отправить почту с IP, к которому этот домен привязан. Само собой разумеется, что домен должен быть привязан к серверу, где установлен Exim.

Так же нужно создать файл в любом месте файл привязки доменов к IP (у домена может быть несколько IP, так что просто lookup-ить его не прокатит). Я выбрал для файла место: /usr/share/exim4/domain2ip

# nano /usr/share/exim4/domain2ip

Туда вводим наши домены по шаблону:

valera.ws: 123.123.123.123
vasya.ws: 123.123.123.124

Не забудьте дописать домен в файл в случае появления нового сайта.
Кстати, строку helo_data = «$sender_address_domain» можно добавить в файл даже если у вас один IP на все сайты. Тогда в команде HELLO SMTP-протокола (а, следовательно, и в заголовках писем) будет фигурировать ваш домен.

Идея с указанием интерфейса взята отсюда: http://www.directadmin.com/forum/showthread.php?t=36468

Проверка

Остается проверить, чтобы все ваши настройки работали верно. Для этого просто отправим письмо с локального сервера через консоль.

$ mail -a «From:feedbee@valera.ws» -s Test feedbee@gmail.com — -ffeedbee@valera.ws
Test <Ctrl-D>
Cc:

Проверяем отосланное письмо в ящике получателя:

А вот текст SMTP-протокола:

Delivered-To: feedbee@gmail.com
Received: by 10.236.109.139 with SMTP id s11cs13826yhg;
Wed, 24 Nov 2010 02:18:14 -0800 (PST)
Received: by 10.227.145.134 with SMTP id d6mr9025492wbv.195.1290593893066;
Wed, 24 Nov 2010 02:18:13 -0800 (PST)
Return-Path: feedbee@valera.ws
Received: from valera.ws (server.valera.ws [93.174.6.118])
by mx.google.com with ESMTP id b7si11085685wer.164.2010.11.24.02.18.12;
Wed, 24 Nov 2010 02:18:12 -0800 (PST)
Received-SPF: pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) client-ip=93.174.6.118;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) smtp.mail=feedbee@valera.ws
Received: from root by server.valera.ws with local (Exim 4.69)
(envelope-from <feedbee@valera.ws>)
id 1PLCQW-0006KD-Pc
for feedbee@gmail.com; Wed, 24 Nov 2010 10:18:12 +0000
To: feedbee@gmail.com
Subject: Test
From:feedbee@valera.ws
Message-Id: E1PLCQW-0006KD-Pc@server.valera.ws
Date: Wed, 24 Nov 2010 10:18:12 +0000

Test

P.S. Чтобы отправленная почта не попадала в спам, отправляйте письма только от имени реально существующих на серверах Gmail адресов на ваших доменах. Туда же повалятся уведомления о недоставках.

Уже давно стандартом агента электронной почты (MTA) стали веб-приложения типа Gmail. Такие сервисы предоставляют удобный, стабильный быстрый доступ к почте из любого места, хороший поиск писем в ящике, много места для их хранения, отличную защиту от спама. Постепенно все больше и больше людей отказывались от The Bat! и Outlook в пользу Gmail, Yahoo! Mail, Hotmail, Яндекс.Почты.

Но многим хотелось иметь почту на своем домене. Еще несколько лет назад, пользуясь почтой на своем домене, приходилось прибегать к хитростям пересылки и сбора почты, которые были доступны как минимум в Gmail и почте Яндекса. Это вызывало некоторые неудобства.

Первыми догадались бесплатно предлагать полное обслуживание почты на домене Google. В рамках проекта Google for domains (первое название) они предлагали указать MX-записи вашего домена на сервера Google и полностью возложить на себя обслуживание вашей почты, тем самым объединяя качественный сервис и красивое имя ящика.

Постепенно проект Google for domains влился в Google Apps, были введены некоторые ограничения и платный сервис. После этого на ту же тропу вступил Яндекс, открыв сервис ПДД — «Почта для домена». Политика Яндекса была значительно демократичнее Google. Пользователь получил возможность выбрать наиболее подходящий для себя сервис.

В настоящее время оба сервиса развиты достаточно хорошо и конкурентов у них на горизонте не видно.

Зачем это нужно?

Как уже было отмечено выше, Google и Яндекс предлагают стабильную, удобную, гибкую систему обработки почты и доступа к ней с помощью веб-интерфейса, а так же лучшую в мире защиту от спама. Никто другой пока не может предложить даже платно услуги такого уровня. Говорить о почтовых сервисах хостеров, или, тем более, интернет-провайдеров, уже давно не имеет смысла. А содержание своей почтовой системы на своем сервере со временем гарантированно приведет к тоннам спама в ваших ящиках. Ну и скорее всего, за год выдастся хотя бы пару дней, когда ваша почта будет «лежать».

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

Google или Яндекс?

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

В пользу Google:

• список дополнительных сервисов для домена от Google значительно шире, чем у Яндекса;
• есть поддержка других языков, кроме русского.

В пользу Яндекс.Почты:

• нет ограничения на 50 аккаунтов, как у Google в бесплатной подписке;
• есть возможность бесплатно прикрутить систему самостоятельной регистрации пользователя.

Каждый для себя сам может решить, что для него важнее. Я пробовал подключать и один сервис, и другой. От обоих остался удовлетворенным. Но для своей организации я выбрал Gmail, так как ограничение 50-ти ящиков не существенно, работать с Google я стал раньше, чем появилась «Почта для доменов» Яндекса, интерфейс Gmail мне и моим коллегам субъективно нравится больше, чем Яндекс.Почты.

Проблемы делегирования почты

При делегировании обслуживания почты на сервера Google или Яндекса, возникают некоторые вопросы с отправкой почты из скриптов. Если рассылать письма с помощью агента (MTA), «встроенного» в операционную систему, например функцией mail(), то можно сталкнуться с тем. что много писем будут попадать пользователям в спам. Это связано с настройкой агента и локального SMTP-сервера, через которого агент шлет письма.

Если рассылать почту по SMTP через сервера Google или Яндекса, то почта попадет в спам только при реально спамерском содержимом писем. Но, Google поддерживает подключения только с SSL-шифрованием. Следовательно ваш клиент должен уметь SSL. Кроме того, с целью защиты от спама Google блокирует отправку писем, если в течение некоторого малого времени не удается отправить большое число писем (приходят возвраты). Как дела с этим у Яндекса, я не проверял, но думаю, что у них тоже есть защита.

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

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

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

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

Естественно, что вопросов программисту PHP можно задать море. Особенно учитвая, что знать надо связанные области (БД, сети, HTML и иже с ним, Linux). Смысла задать все вопросы, какие только можно, конечно нету. Задача — определить уровень специалиста, чтобы принять решение: подходит он нам или нет. По-этому выбрал наиболее подходящие на мой взгляд вопросы, по которым я смогу оценить уровень кандидата.

Кроме того, конечно не одиними вопросами можно обойтись. Следует предложить пройти небольшие тесты по практическим моментам. Об этом ниже.

Вопросы

1. PHP и основы программирования
1.1. Почему PHP?
1.2. Что такое ООП, основные принципы ООП.
1.3. Понятие абстракции, наследования, инкапсуляции и полиморфизма.
1.4. Что такое MVC?
1.5. Какие паттерны проектирования вам известны?
1.6. Под какую версию PHP писали? В чем различия между четвертой и пятой версиями?
1.7. Какими сторонними библиотеками пользовались?
1.8. Опыт работы с различными Frameworks/CMS?
1.9. Типы данных в PHP? (string, int, float, object, resource, null, bool, array)
1.10. Назовите по памяти функции для работы с массивами, строками и объектами в PHP (хотя бы по 5 штук).
1.11. Что такое сериализация?
1.12. Чем отличается абстрактный класс от интерфейса?
1.13. В каких случаях лучше использовать статические методы и классы?
1.14. Можно ли создать приватный конструктор? Зачем?
1.15. Как сказывается большое количество объектов в коде на производительность?
1.16. Что такое хэш?
1.17. Что такое область видимости переменной?
1.18. Что такое PDO? Что такое ORM?
1.19. Что такое PEAR?
1.20. Когда лучше использовать mysql_pconnect?
1.21. Обязательно ли писать ?> в конце скрипта?
1.22. Как вы отлаживаете PHP-код?
1.23. Проводили когда-нибудь оптимизацию сайтов?
1.24. Какую IDE используете? Какие использовали ранее?
1.25. Что такое unit-test? Использовали?
2. Tools
2.1. Что такое Apache? mod_rewrite? nginx?
2.2. Аббревиатуры SVN и CVS о чем-нить говорят? А Git и Mercurial?
2.3. Багтрекинг системы? BugZilla? Mantis? Redmine? JIRA?
2.4 .Моделирование, UML использовали?
2.5. Что такое SSH? Какие есть варианты авторизации при входе по SSH?
3. Data Bases
3.1. Что такое реляционная база данных? Какие есть типы БД?
3.2. Нормализация, денормализация.
3.3. SQL. Join’ы, Union. Подзапросы.
3.4. Процедуры, тригеры.
3.5. Вьюшки.
3.6. InnoDB vs MyISAM.
3.7. Какие бывают индексы в MySQL?
3.8. В чем отличие MySQL от PostgreSQL?
3.9. Что такое SQL-инъекция? Приведите пример.
4. HTML + CSS
4.1. Нарисуйте простенькую форму для отправки файла.
4.2. Что такое CSS? В чем разница между записью #my и .my? Для каких атрибутов можно указать :hover?
4.3. Расшифруй вот такую запись в CSS table#a tbody td.odd {text-decoration:inherit}?
4.4. Что такое стандарты W3C?
5. JavaScript
5.1. Как работает наследование в JS?
5.2. Чем отличается хэш от объекта? (провокационный)
5.3. А хэш от массива?
5.4. Если ли опыт работы с Jquery, ExtJS? Какие фреймворки использовались?
5.5. Что такое Ajax? Есть ли опыт работы с ним?
5.6. Использовали ли FireBug? Drag-on-fly?
5.7. Что такое замыкания и как они работают?
6. Linux
6.1. С *nix знаком? Какие дистрибутивы? Почему?
6.2. Apache, PHP и СУБД устанавливали под *nix? Настраивали? Оптимизировали?
7. Networking
7.1. Что такое уровни модели OSI? Сколько их?
7.2. По какому протоколу осуществляется передача данных в сети Интернет?
7.3. Какие вообще есть сетевые протоколы?
7.4. Расскажите, что происходит, когда в строке браузера набираешь адрес и нажимаешь Enter?
7.5. Что такое WSDL & web-services? Есть опыт работы?
7.6. Что такое SSL? Как работает HTTPS? Какой принцип работы HTTPS? Какие есть варианты авторизации HTTP?
8. Что такое XSLT, XML? Есть ли опыт работы с ними?

Как отработает код?

1)
<?php
/* Что будет выведено на экран? */
$a = ‘true’;
if( 0 == $a || $a )
{
echo ‘yes’;
}

2)
<?php
/* Что будет выведено на экран? */
$a = 10;
echo $a— — — — — — — — — — — —$a;

3)

<?php
class A {private function __construct(){throw new Exception(»);} public function A(){return array(‘a’,’b’,’c’);} public static function I(){return new A();}}
/*
Как вывести на экран именно то ‘b’, которое определено в массиве выше, используя одну команду (одну строку кода)?
*/

4)
<?php

/*
Какая строчка выведется при исполнении скрипта?
Почему исполняется или не исполняется каждое из условий?
*/
$x = 1;
if ($x == ‘1’) {
echo ‘a’;
}
if ($x == true) {
echo ‘b’;
}
if((bool)$x === true){
echo ‘e’;
}
if ($x === true) {
echo ‘c’;
}
if((int)$x === true){
echo ‘d’;
}

5)
<?php
/*
Что выведет скрипт? (запускается непосредственно)
*/
error_reporting(E_ALL);
ini_set(‘display_errors’,’0′);

print $x[0];
dddxxxx();

6)
<?php
/*
Для какой версии PHP будет работать этот скрипт?
Что выведет этот скрипт?
*/
class Test{

private $var;

function setMe($value){
$this->var = $value;
}
}

class More extends Test{
public $var;
}

$oTest = new Test;
$oMore = new More;

echo $oTest->setMe(‘foo’);

echo $oMore->setMe(‘foo’);

echo $oMore->var;

echo $oTest->var;

Тест на corp.mamba.ru

http://www.corp.mamba.ru/test/promo.phtml

Ссылки

А вот и те ссылки, которые помогли мне в составлении списка.

http://habrahabr.ru/blogs/php/21681/

http://habrahabr.ru/blogs/webdev/19964/

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

Для решения этой задачи можно использовать общую базу данных, которая будет располагаться на хостинге. На сервере в локальной сети поднять сайт, указать для подключения к СУБД параметры доступа к база на удаленном сервере. Таким образом, у вас будут 2 одинаковых сайта, параллельно работающих с одним источником данных.

В принципе это обычная схема для балансировки нагрузки на фронтэнд (web-сервер). Практику много фронтэндов — один бэкэнд (база) применяют довольно часто, а следующий этап разделения нагрузки (когда уже СУБД не выдерживает напора) — кластеризация серверов баз данных. Но это лирическое отступление.

Следуюет учесть три нюанса. Во-первых, так как сервера у нас теперь два, время на них может быть разное. Следовательно при записи в базу временные показатели будут для серверов расходиться и может возникнуть путаница. Чтобы этого избежать, проще всего брать время из СУБД. Делать это надо естественно 1 раз за запрос (кэшировать), а не при каждой необходимости (при условии, что запрос выполняется не более 1 секунды; если больше, значит ваша система нуждается в оптимизации). Таким образом время на всех серверах будет синхронизировано по времени на сервере с СУБД.

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

Решить эту проблему можно через подключение к СУБД по защищенному SSL-протоколу. Популярные СУБД поддерживают SSL (MySQL, PgSQL). Подключение клиента к серверу через SSL поддерживают родные C API этих СУБД, и PHP MySQL/PgSQL API тоже. Но SSL не поддерживается PDO (во всяком случае я не нашел информацию о поддержке), который в настоящее время очень популярен и который следует использовать. По этому вариант подключения к базе через SSL отпадает.

Остается другой, довольно простой для использования и сложный для настройки вариант — перегон трафика между офисом и хостингом через VPN. Сам VPN я уже описывал в своем блоге. После поднятия VPN-тоннеля необходимо прописать роут на IP вашего сервера (того сервера, где находится СУБД) через виртуальный интерфейс VPN-соединения. Таким образом весь трафик между PHP и СУБД будет ходить по безопасному зашифрованному каналу.

Третий нюанс заключается в кэшировании. Часто кэш некоторых элементов заводят пожизненно (или на долгое время), а сбрасывается он только при изменении данных редактором. В этом случае, при внесении изменений на одном из серверов, кэш не сбросится на втором и на неопределенный срок там останется неактуальная информация. Эта проблема решается через изменение стратегии кэширования, либо использование общего сервера кэширования и выходит за рамки данной статьи. Если именно этот вопрос для вас остается актуальным, ищите информацию в гугле, т.к. та же самая проблема существует при балансировке нагрузки путем «размножения» фронэндов.

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

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

Теперь рассмотрим преимущества реестра в применении к веб-сайту.

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

Во-вторых, сайту, как и обычному приложению для ОС, требуется где-то хранить ряд своих настроек. Одни из них в процессе жизни сайта не меняются (такие настройки часто устанавливают прямо в коде в виде констант), другие можно менять (в CMS обычно есть страничка «настройки»; примерами таких настроек может служить информационное сообщение на всех страницах сайта или количество записей на одной странице в списках). Третье настройки зависят от текущего пользователя (обычно это какие-либо привилегии, часть которых часто реализуется в системе прав доступа, и персональные установки пользователя).

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

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

• ветвь глобальных настроек приложения, которые касаются всех пользователей;
• ветвь локальных настроек модулей, которые касаются всех пользователей;
• ветвь настроек текущего пользователя (подставляется в зависимости от залогиненного пользователя);
• ветвь настроек пользователя по умолчанию (all users).

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

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

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

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

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

Сделал скрин:

Сегодня вспомнил про старый скрин и решил посмотреть, исправлен ли баг за это время? :)

Оказалось, не исправлен.

Проверил на FF (самый тормозной браузер что дома, что на работе). Ровно то же самое. Скрин не делал — выглядит точно так же, как в опере. В IE не проверил по техническим причинам. Но думаю, эффект будет тот же.