Ценность материала в том, что:

1) это хороший способ взглянуть на себя со стороны огромному числу программистов PHP, так как общая средняя квалификация этого класса программистов значительно ниже среднего по другим более серьезным языкам; взгляд со стороны поможет понять свои проблемы и найти способы их преодоления;

2) конкретные советы о том, что следует почитать/посмотреть.

Ссылка на материал: Как стать хорошим программистом и хорошим php-программистом в частности?

А ниже позволю себе сделать частичный копипаст предложенных решений.

Мастерство программирования (или скорее можно назвать Основы)

• Совершенный код,
• Чистый код,
• Рефакторинг,
• Программист-прагматик,
• Архитектура корпоративных программных приложений,
• Кодеры за работой.

Нашел очень хорошую и исчерпывающую статью на английском: How to be a Programmer: A Short, Comprehensive, and Personal Summary

Курсы, выложенные по MIT OCW:

• MIT Electrical Engineering and Computer Science

Курсы Стэнфорда:

• Mashine learning
• Natural Language Processing class
• Software Engineering for Software as a Service class

На каждом сайте внизу есть ссылки на другие курсы Стэнфорда.

Алгоритмы.

Как развивать:

Искусство программирования Кнутта — читать и выполнять задания.

Project Euer — задания по алгоритмам, можно писать на PHP.

ООП и Шаблоны проектирования

PHP: объекты, шаблоны и методики программирования М. Зандстра сейчас, наверное, лучшая книга для введения в шаблоны проектирвания для PHP.

Head First Design Patterns, на русском Паттерны проектирования — очень рекоммендуют, как очень хорошо разъясняющую книгу.

какие книги, методы обучения, задачи порекоммендуете?

PHP основы

Как развивать:

собственно работа по профессии и набор опыта,

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

Потом есть stackoverflow, там введи в поиск ~php~ и читай вопрос, давай свой ответ (про себя), потом смотри, что другие написали. Будешь по тегам смотреть заодно, что пхп-ники изучают.

Javascript Основы

Как развивать:

собственно работа по профессии и набор опыта,

JavaScript. Подробное руководство. Д. Флэнаган (читать и разбираться в пропущенных основах – типы, обьектная модель и др.)

JavaScript: The Good Parts

JavaScript. Шаблоны

Источник: Как стать хорошим программистом и хорошим php-программистом в частности? Ни автор, ни комментаторы не имеют ко мне никакого отношения.

Все предложения хостинга можно разделить на 4 группы: Shared hosting (общий сервер), VPS (virtual private server — частный виртуальный сервер), Dedicated (выделенный сервер) и Cloud (облачный хостинг). Colocation (размещение сервера) в расчет не берется, так как это просто аренда места в стойке, а не хостинг.

Итак, с чем же можно провести аналогию?

Первое, что пришло в голову — ресторан. Shared — небольшой стол, заполненный едой, а вокруг стоя тянет руки толпа студентов. VPS — типичный ресторанный стол, у каждого своя еда на тарелке, присутствует малая группа людей. Dedicated — один за столом. Cloud — вот тут самое интересное. Толком придумать идею не получилось. Если у кого получится, велкам в комменты.

Чтобы восстановить пробел с Cloud, решил перенести фокус со стола на одну емкость — стакан. Shared — стакан с жидкостью забит трубочками. VPS — стакан перегородками поделен на 4 равные части, в каждой части своя трубочка. Dedicated — одна трубочка в стакане. Cloud — система стаканов, соединенных трубочками. К этой системе равномерно подключаются трубочки «клиентов».

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

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

Решение. В консоли выполняем следующие команды:

$ sudo modprobe -r psmouse
$ sudo modprobe psmouse proto=imps

Заработал скрол? У меня — да. Если у вас тоже, по результат надо закрепить. Для этого открываем /etc/modprobe.d/options и добавляем туда строку.

sudo gedit /etc/modprobe.d/options

Строка:

options psmouse proto=imps

Теперь и после ребута скрол останется работать.

P.S. Печальные последствия такого способа заключаются в том, что из настроек мыши пропадает вкладка Touchpad.

Решение отсюда: http://superuser.com/questions/136568/get-back-the-touchpad-scrolling-missing-in-kubuntu-10-04

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

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

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

Факторный анализ места работы для разработчика ПО

1. Интерес
   • Проект
     • тематика
     • технологии
     • уровень сложности
     • нагрузки в продакшане
   • Зона ответственности
     • разброс обязанностей
     • принятие решений
   • Подчиненные
     • количество
     • качество
   • Заказчик
     • локальность
     • культурные различия
     • требовательность
2. Условия труда
   • Офис
     • эстетика
     • расположение
     • размер, оформление  комнаты и ключевых узлов
     • вентиляция и кондиционирование
     • ремонт (состояние)
     • стоянка
   • Рабочее место
     • компьютер
     • монитор
     • админские права и ограничения по ОС/ПО
     • интернет и ограничения
     • стол, стул
     • освещение
   • Коллеги и руководство
     • размер команды
     • адекватность руководителя
     • простота административной структуры
     • постановка работы команды
   • График
     • время работы
     • гибкость графика
     • отработки
3. Оплата
   • Зарплата
     • сумма
     • валюта
     • рост
   • Социальные вопросы
     • социальный пакет
     • корпоративы
   • Проблемы
     • задержки зарплаты
     • штрафы
     • ограничения контракта

Оценка по каждому фактору:

• 0 — нейтрально, нормально,
• ­­−1 — плохо,
• +1 — хорошо.

Проставляется оценка по каждому фактору 3-го порядка. Важно понимать, что оценка +1 всегда обозначает, что по данному вопросу обстоятельства в вашу пользу. Не важно как называется фактор: «уровень зарплаты» или «штрафы», +1 всегда будет обозначать, что по этому фактору вы в положении «хорошо» для себя. Соответственно −1 — значит «плохо» для вас.

Оценки суммируются по группам — факторам 1-го порядка. Каждому фактору 1-го порядка выставляется субъективный вес, который приводится к коэффициентам. Например, устанавливаются веса: «Интерес» — 10, «Условия труда» — 7, «Оплата» — 8. Тогда коэффициенты будут: «Интерес» — 40% (10/(10+7+8)=0,4), «Условия труда» — 28% (0,28), «Оплата» — 32% (0,32).

Коэффициент при факторе 1-го порядка покажет, какую долю в оценке займет этот фактор. Такой подход позволяет сильно влиять на результат в зависимости от предпочтений разных людей не меняя модели: кому-то уровень заработной платы в 2 раза (условно) важнее интереса в работе, а кому-то наоборот. В первом случае «Интерес» может получить 20%, «Оплата» — 40%, во втором соответственно наоборот.

Полученная сумма по каждому фактору 1-го порядка умножается на коэффициент этого фактора и делится на количество его факторов 3-го порядка. Затем полученные числа суммируются.

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

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

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

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

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

Модель должна быть сбалансирована по факторам 2-го порядка. Если фактор 2-го подяка имеет важное и широкое значение, то факторов 3-го порядка в нем должно быть много. Если значение слабое — мало. В остальных случаях количество факторов 3-го порядка должно быть примерно равным и относительно небольшим.

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

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

Хочу немного поделиться своими познаниями в области дисковой подсистемы операционных систем, файловых систем и работы с ними в ОС Linux. Практическая ценность этой информации заключается в алгоритме простых и быстрых бэкапов разделов, а так же подвод к следующему посту про мультизагрузочную флэшку. Можно использовать этот материал как первую попытку разобраться принципе работы дисковой подсистемы. Ничего углубленного, все описано очень поверхностно и популярно.

Материал разделен на три части: А — теория, Б — практика, В — создание мультизагрузочной флэшки.

А. Общая теория (популярно).

1. Железо.

Все физические устройства, которые используются нами повседневно для хранения информации (HDD, CD-ROM, флэшка, и даже флопик) — это блочные устройства ввода/вывода (block I/O device). Они могут подключаться к компьютеру через различные интерфейсы: IDE, SATA, eSATA, USB. Операционная система предоставляет единый прозрачный для пользователя и программиста прикладного ПО способ чтения/записи информации с/на эти носители.

С железом напрямую общаются драйвера. Драйвер — это программа, загруженная в операционную систему. Он является прослойкой между ОС и устройствами, представляя для ОС стандартный программный интерфейс блочных устройств I/O.

2. Данные на физическом диске.

Блочными эти устройства называются потому, что информация на них записывается и считывается блоками (секторами, кластерами) фиксированного размера. Размер блока кратен 512 байт. Блочный подход необходим для обеспечения высокой скорости работы дисковой подсистемы.

Сам диск форматируется (размечается) на низком уровне (на заводе). Диск состоит из цилиндров. Цилиндр — это окружность на пластине диска. Первые цилиндры расположена в центре пластины диска, последние — на внешнем краю. Каждый цилиндр делиться на секторы. В пределах секторов организуются блоки на диске. Помимо самих данных в блоках записывается информация для контроля ошибок. С этой информацией работает контроллер внутри жесткого диска и она не видна снаружи. Драйвер посылает команды контроллеру диска на уровне «считать 10 блоков 10 цилиндра 20 сектора».

Все полезные данные, записанные на носитель, организованы в разделы. В Windows каждый раздел обычно представлен в виде логического диска (C, D, E, …). На сменных носителях (флэшка, компакт-диск, флопик) как правило создан один единственный раздел, на внутренних жестких дисках — наоборот — обычно несколько разделов. Данные в разделе организованы в файловой системе.

Для каждого раздела может независимо устанавливаться свой размер блока — размер кластера. Он регулирует баланс скорость/экономичность. Блок — это минимальная адресуемая единица разметки на диске. Кластер объединяет несколько блоков — это минимальная адресуемая единица в разделе.

Таким образом устанавливается следующая логическая иерархия (от внизу вверх): блок, сектор, цилиндр — кластер — раздел — файл, каталог.

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

3. Разметка физического диска.

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

Так как на диске может быть несколько разделов, их нужно где-то перечислить с указанием пределов и свойств каждого раздела. Для этого служит таблица разделов, которая находится в начале физического диска (начало диска — это его первый блок в соответствии с адресацией). В классическом случае она входит в состав MBR (master boot record), которая целиком занимает первый блок. На всю таблицу разделов выделено 64 байта. Каждая запись таблицы состоит из адресов начала и конца раздела, типа раздела, количества секторов в разделе и флага «загруженности» раздела и занимает 16 байт. Таким образом максимальное количество разделов на диске ограничено четырьмя (16 × 4 = 64).

Так сложилось исторически, но со временем стало очевидно, что 4 раздела не всегда достаточно. Решение проблемы было найдено. Те разделы, которые размечены в заголовке диска (в MBR), назвали Primary (первичные). Их по прежнему должно быть до 4-х включительно. Дополнительно ввели понятие Extended (расширенных) разделов. Расширенный раздел включает один или более подраздел и не содержит файловой системы. Сам он является полноценным первичным разделом.

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

Разметка расширенного раздела описана в в его начале. По аналогии с MBR существует EBR (Extended boot record), расположенная в первом секторе. В ней описывается разметка логических дисков данного расширенного раздела.

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

4. Файловая система.

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

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

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

В процессе работы на диске могут возникать физические повреждения. Некоторые блоки могут становиться недоступными для чтения. Эти блоки называют «бэдами» (bad sector). Если в процессе чтения диска попадает бэд, происходит ошибка ввода/вывода (I/O error). В зависимости от того, в каком месте появился бэд-блок и сколько их появилось, может потеряеться либо часть содержимого файлов, либо в часть таблицы файлов.

При попытке записи в бэд-блок контроллер диска должен определить проблему и выделить для этого блока новое место на поверхности диска, а старое место из использования изъять (relocate bad block). Он делает это незаметно для ОС и драйверов, самостоятельно. Происходит это до тех пор, пока есть резерв места для переноса.

5. Работа с диском.

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

В ОС семейства UNIX все устройства хранения данных представлены в виде файлов в каталоге /dev:

• sda, sdb, sdc, … — физические диски (HDD, включая внешние, флэшки, IDE-сидиромы);

• fd0, fd1 — флопики.

Разделы на каждом из дисков доступны в виде sda1, sda2, sd3, …

Нумерация дисков происходит в том порядке, в котором их видит BIOS. Нумерация разделов — в порядке создания разделов на диске.

Чтобы сделать образ (образ — это побитовая копия информации, размещенной на диске или в разделе) диска целиком (например первого по BIOS — sda), нужно вычитать данные из /dev/sda в любой другой специально созданный для образа файл, используя программу последовательного копирования содержимого файла. Чтобы записать образ в файл, нужно при помощи той же программы вычитать данные из образа в /dev/sda. По аналогии можно создать/восстановить образ раздела (например, первого на первом диске — sda1), обращаясь к /dev/sda1 вместо /dev/sda.

6. Монтирование.

Чтобы «превратить» дисковое устройство в набор файлов и каталогов, к которым можно получить доступ, его необходимо примонтировать. В Windows как такового монтирования не существует. Там разделы просто подключаются к логическим дискам (C:, D:, E, …). Информация о том, какую букву присвоить какому диску, хранится в самой ОС.

В UNIX понятие монтирования является основоположным в работе с дисками и дает значительно больше гибкости, чем есть в Windows. Монтирование — это процесс привязки некоторого источника образа диска (это либо сам диск, либо файл с его образом) к некоторому каталогу в файловой системе UNIX. Файловая система в UNIX начинается из одной точки — от корневого каталога (/), и никаких логических дисков C, D, E не существует.

В начале загрузки ОС семейства UNIX в корневой каталог / монтируется раздел диска, помеченный как root (корневой). На разделе диска должны быть созданы служебные каталоги ОС, находящиеся в корне файловой системы. К ним могут монтироваться другие разделы, либо файлы могут записываться прямо в основной раздел (примонтрированный к /).

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

Для монтирования необходимо указать файловую систему образа, опции монтирования и каталог, к которому будет привязка.

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

7. MBR — загрузочная область.

В начале физического диска обычно расположена MBR (master boot record). Это загрузочная область диска. При загрузке компьютера BIOS определяет какой диск является первичным (primary) и ищет на нем MBR. Если она найдена, то ей передается управление. Если нет, выводится ошибка о том, что загрузочный диск не найден.

В MBR, кроме таблицы разделов (описано выше), располагается код программы, которая загружается в память и выполняется. Именно эта программа должна определить загрузочный раздел на диске и передать ему управление. Передача управления происходит аналогично: первый блок (512 байт) загрузочного раздела помещается в оперативную память и выполняется. Он содержит программный код, который инициирует загрузку ОС.

За счет того, что управление от BIOS при загрузке компьютера передается программе, записанной на диске, есть возможность сделать выбор загрузочного раздела более гибким. Это и делают загрузчики GRUB и LILO, широко применяемые в мире UNIX. Последний загрузчик в настоящее время использовать на современных компьютерах смысла нет. С помощью GRUB можно предоставить пользователю выбор, какой раздел загружать и каким образом.

Код GRUB слишком большой, чтобы поместиться в MBR. Поэтому он устанавливается на отдельном разделе (обычно в том разделе, который монтируется в /boot) с файловой системой FAT, FFS или Ext2. В MBR записывается код, который загружает код GRUB с определенного раздела и передает ему управление.

GRUB самостоятельно или с помощью пользователя определяет с какого раздела должна происходить загрузка. В случае Winsows-раздела ему просто передается управление точно так же, как это было бы из обычной MBR. В случае Linux-а загрузчик выполняет более сложные действия. Он загружает в память ядро ОС и передает ему управление.

Сделать бэкап загрузочной области диска так же легко, как бэкап всего диска или отдельного раздела. Суть в том, что MBR занимает первые 512 байт диска /dev/sda. Следовательно, для бэкапа MBR необходимо вычитать первые 512 байт /dev/sda в файл, а для восстановления — наоборот — файл вычитать в /dev/sda.

Озадаченно смотрю на версии «свежего софта»…

На моей бубунте уже как минимум Гном, офис и ядро более новых версий. Подозреваю, если посмотрю на прочий установленный или доступный в репозиториях софт — ситуация будет аналогичной.

Объясните — в чем смысл? Только в «проверенности» и стабильности этих версий?

Ответ:

Да. И это «только» весьма дорогого стоит. Более того, в рамках политики дебиана обновляться версии будут только на security fix’ы, то есть никаких новых фич до момента явного dist-upgrade’а. Сравните с убунтой, в которой каждые N дней пачка обновляемых пакетов.

Для десктопа это, может быть и нормально, но для сервера — неприемлимо. Я лично несколько раз сталкивался с дурацкими проблемами при обновлении версий (к счастью, только на декстопе). В списке лидеров — evolution (похерил архив почту), krusader (похерил половину настроек), deluge (криво подцепил старые настройки).

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

Таким образом, stable — это идеальное решение для сервера. А sid/ubuntu — вполне хорошо для _своего_ десктопа (решать проблемы похерившейся почты у себя неприятно, но решать их же у главбуха — куда грустнее).

Кстати, ровно той же политики придерживается и RHEL (CentOS) — у них в пятой версии до сих пор 2.6.18, хоть и с кучей бэкпортов.

© amarao, Хабрахабр.

Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

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

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

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

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

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

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

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

Хэшировать ли пароль? Это может иметь значение только в одном случае: если у пользователя один пароль на несколько сервисов. Тогда перехватчик не увидит пароля в открытом виде, чтобы использовать его на других сервисах. Но подобрать брутфорсом пароль все равно возможно. Только это уже не так тривиально, как подсмотреть в открытом виде. Так что если вы на стороне пользователя, постарайтесь пароль хэшировать до передачи.

А как делают другие?

Про Яндекс я уже рассказал. Добавлю, что пароль он передает в открытом виде и не пускает на главную страницу портала по HTTPS.

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

Google работает по HTTPS нормально. Пароль передает в открытом виде. Авторизацию по умолчанию предлагает защищенную. Способов определения, поддерживает  ли клиент HTTPS, я не нашел.

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

Вот такая статистика. Западные ресурсы и пользователи давно освоили основы безопасности в сети. Ведущие российские ресурсы защищают хотябы авторизацию пользователя. Ведущие белорусские ресурсы безопасность пользователей игнорируют полностью.

1. Домашний сервер на Debian 5.
2. Физический доступ к нему.
3. Доступ по SSH (не root).
4. USB-флешка с разделом NTFS.

Необходимо: быстро монтировать и размонтировать флешку для чтения/записи.

Вся проблема сводится к тому, что автомантирование флешек в Дебиане по дефолту делается штатными драйверами (read-only) и только с правами на монтирование. А мне необходимо было периодически скидывать инфу на флешку или с нее. Захотелось процесс оптимизировать.

Для достижения цели необходимо решить 2 задачи:

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

Делается все очень просто. Я создал shell-скрипт /root/flash следующего содержания:

#!/bin/bash

case "$1" in
	1)
		mount -t ntfs-3g /dev/sdc /media/flash/
		;;
	0)
		umount /media/flash/
		;;
	*)
		echo $"Usage: $0 {1|0}"
		exit 1
esac

При передаче скрипту 1 происходит монтирование, при передаче 0 — размонтирование флешки (если точнее, то усройства /dev/sdc).

Ссылку на скрипт размещаем в /usr/bin для удобного доступа к нему:

# ln -s /root/flash /usr/bin/flash

Теперь надо разрешить выполнение этого скрипта без пароля от имени root с помощью sudoers. Выполните:

# sudoedit

И в файл добавьте следующие строки (замените feedbee на имя вашего пользователя):

Cmnd_Alias FLASH_CMD = /usr/bin/flash
feedbee ALL=(ALL) NOPASSWD: FLASH_CMD

Собственно, всё. Теперь из под вашего пользователя можно просто выполнить:

$ sudo flash 1

для монтирования флешки, и

$ sudo flash 0

для размонтирования.

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

Самый простой пример таких сайтов — это локализованные версии одного сайта на разных языках. У меня в практике — это тематические форумы для разных групп.

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

При запуске обработки пользовательского HTTP-запроса скриптам необходимо определить, какому именно домену предназначен запрос, и выбрать соответствующий конфиг. В PHP это довольно просто сделать: заглянуть в переменную $_SERVER['SERVER_NAME']. В других языках программирования под веб, думаю, примерно так же просто.

По имени серевера определяется нужный конфиг и оттуда берутся все необходимые настройки. Все просто.

Но когда дело доходит до вызова скриптов из cron-а (или другого планировщика), то переменная $_SERVER['SERVER_NAME'] будет пуста. Оно-то и понятно: никакого сервера нет, скрипт запускается напрямую через CLI. И узнать, для какого сайта вызывается скрипт, без явной передачи домена скрипту невозможно.

Самый простой способ указать домен — это прописать его аргументом командной строки. При вызове из cron-а после имени скрипта просто пишем домен, а в коде получаем его из переменной $argv глобальной области видимости.

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

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

Таким образом ищем более удобный способ передать «указатель» на сайт. И находим: это переменные окружения. Среду окружения интерпретатор PHP получает оттуда, откуда он был запущен. Если скрипт запущен веб-сервером, то переменные будут получены от сервера. Если запускается скрипт через CLI, то среда будет получена от shell-а, в котором производился запуск. Повторю: запуск скриптов из cron-а — это обыкновенный запуск исполнимого файла в режиме CLI.

Теперь к конкретике. Чтобы переменная среды окружения попала из веб-сервера в PHP-скрипт (или скрипт/программу, написанную на других языках), ее надо установить (прописать). Для Апача установить переменную можно в файле .htaccess, либо в конфигах сервера (httpd.conf или конфиги виртуальных хостов). В идеале предпочтительно последнее. Но достаточно и минимального уровня доступа к .htaccess. Добивим в соответствующий конфиг строку:

SetEnv SITE_NAME site1

Чтобы определить переменную среды при запуске в режиме CLI (php /filename), нужно ее объявить и экпортировать:

export SITE_NAME=site1;

При запуске скрипта вручную следующей командой можно запускать сам PHP. Если запуск производится cron-ом, то стоит создать скрипт, на который ссылаться из crontab:

#!/bin/bash
export SITE_NAME=site1;
php /path

Для других сайтов вместо site1 подставляются другие имена.

Остается прочитать переменную в скрипте:

echo getenv('SITE_NAME');

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

* Стоит отметить, что в случае разных «установок»¹ одного и того же сайта (development, testing, production) принято это значение передавать сайту в виде тоже же переменной окружения. Как правило, конфиг в этом случае содержит очень много информации, одинаковой для всех «установок», а отличаться, например, могут только параметры доступа к БД. Тогда имеет смысл все установки считать за один сайт (хоть домены и разные), а отличающиеся параметры вынести в отдельный конфиг, зависимый от «установки».

¹ — Я намеряно в последнем абзаце заменил термин «окружение приложения» (application environment: тестовое, рабочее) на «установку», чтобы не было путаницы с тем окружением, где устанавливаюся переменные.

Виджет очень пока простой, содержит самый базовый функционал. Размер виджета минимальный — 1×1. При нажатии на его видимую обалсть выполняется USSD-запрос на получение баланса лицевого счета: *100#. Такой запрос используется в Беларуси всеми тремя GSM операторами.

База логотипов в программу встроена. На данный момент поддерживается только 4 оператора: МТС (Беларусь), Velcom, Life:) и Dialog. Распознавание оператора произыодится по коду сети. Название оператора в любом случае отображается так, как его отдает сеть.

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

В данный момент доработана первая публичная версия. Статус — бета.

Сайт программы.

Скачать:

Недавно Яндекс поменял формат кода информера, который он выдает на странице http://weather.yandex.ru/informer.xml. После этого сервис перестал обрабатывать новые коды. И вот сейчас все вновь работает в штатном режиме.

Полученные ранее информеры продолжают работать без перебоев.

А вот в файле настроек, который нужно размещать на том сервере, где размещается информер, исправлена ошибка в JS коде. В связи с этим, файл настроек необходимо обновить.

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

Обо всех замечаниях по работе проекта просьба писать мне на e-mail: feedbee@gmail.com.

На самом деле стандарт IEEE 802.11n действительно предусматривает теоретический предел скорости соединения в 150 МБит/с. На английской страничке Википедии, посвященной стандарту IEEE 802.11, есть сравнительная таблица скоростей. По ней видно, что предел скорости для протокола 802.11n при условии наличия канала в 40 МГц — 150 Мбит/с.

Не хочу показаться экспертом в этом вопросе. Вообще по поводу Wi-Fi N информации в сети очень мало. Все, описанное тут, — собственный небольшой опыт и результат прочтения пары тем на форумах.

Если на роутере указана скорость свыше 150 МБит/с — 300, то это значит, что будет использоваться два потока по 150 МБит/с. А это в свою очередь требуется поддержки двухпотоковой передачи не только со стороны роутера, но и со стороны клиента — т.е. особое оборудование, способное работать в связке. Получить скорость 300 МБит/с у меня не удавалось ни разу.

Так вот, покупаем мы, значит, беспроводной роутер, на котором красуется надпись 300 МБит/с, например D-Link DIR-615. Включаем, делаем минимальные настройки и подключаем к нему ноутбук, поддерживающий 802.11n. И видим скорость соединения 65 МБит/с. Лезем в настройки. Меняем дофолтное значение полосы пропускания с 20 до 20/40 МГц. Скорость соединения поднимается до 150 МБит/с.

Далее пробуем что-нибудь скачать. Максимальная реальная скорость передачи данных на ноутбук у меня составляла не более 5,5 МБайт/с, от ноутбука — 6,5 МБит/с. Средняя скорость была на 100—200 КБайт/с ниже максимальной.

Эти цифры были на статистике сетевого интерфейса. Реальная скорость передачи самих файлов была и того ниже. Она немного зависила от включения/выключения шифрования. Точно определить ее не вышло, похоже было что-то около 4,5 МБайт/с на ноут.

Такие же результаты были достигнуты ранее с роутером Netgear.

Как ни крути, а все эти скорости в 150 и тем более 300 МБит/с — маркетинговая чушь. Если реальная скорость у вас колеблется около 7 МБайт/с (56 МБит/с) — это очень хорошо. Если около 6 — нормально. А вот если ниже, чините роутер :)

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.

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