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

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 — система стаканов, соединенных трубочками. К этой системе равномерно подключаются трубочки «клиентов».

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

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

Если взять одного из ведущих российских облачных хостеров — selectel.ru, у которого самая низкая стоимость за Гб/час хранения данных (0,005 р), то месяц хранения бэкапов будет стоить 360—540 рублей в месяц. Это около $15. Много. При этом, платить надо еще за трафик и работу виртуальной машины во время синхронизации.

Рассмотрим сервис хранения файлов от Amazon. До терабайта там цена от $0.093 за Гб. Для хранения моих бэкапов понадобится от $9,3—14. Это поменьше, но там нет виртуальной машины, а значит сложнее синхронизация.

Для сравнения посмотрим на Dropbox. Мы знаем, что он хранит пользовательские данные на Amazon S3. Значит, не должно быть дешевле, чем в расчетах Амазона. Аккаунт Pro (100 Гб) стоит $20 в месяц. Да, дороже более чем в 2 раза.

Может Ubuntu One? 20 Гб у них стоят $3. Значит я заплачу примерно $14—22. Тоже дорого…

Стоимость внешних HDD от 250 Гб начинается от $55. Хоть надежность такого бэкапа будет гораздо ниже, чем в случае облаков, да и возни больше (ведь нельзя хранить винчестер в той же локации, где и сервер; а значит нужно либо носить его туда-сюда, либо договариваться с кем-то о бэкапах через интернет). Зато цена приятная: даже по Амазону наш HDD окупится через 6 месяцев.

Во всех расчетах не учитывались затраты на трафик. При первой синхронизации они будут велики ($10—20 для облаков), но при последующих синхронизациях они будут относительно небольшими (трудно подсчитать, ну пусть будет $1—2 в мес.). Для внешнего HDD затрат на первый слив не будет.

Есть также сервис, специализирующиеся на бэкапе в облака. Гуглятся по запросу «cloud backup». Я несколько штук посмотрел, но цен ниже $15 в месяц за 100 Гб не видел. Только больше.

Чтобы попасть в список Labs, нужно зайти в Google Maps и нажать на шестеренку в правом верхнем углу. В выпадающем меню выбрать «Maps Labs».

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

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

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

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

Тестовое задание сходу дают не все, а вот резюме читают, пожалуй, все работодатели. В зависимости от конъюнктуры рынка (отношения спроса к предложению) на этапе просмотра резюме отсеиваются до 90 % соискателей. У меня нет точных среднестатистических данных, но эмпирически рискну предположить, что в среднем отсеиваются 60—70% соискателей.

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

Выходит, что всем выгодно, когда резюме составлено хорошо. А что значит хорошо? Это значит, что соискатель хорошо подаст все свои навыки, опыт и преимущества перед конкурентами, а работодатель получить всю первичную интересующую его информацию о кандидате.

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

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

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

С позиции работодателя расскажу о своем видении резюме веб-разработчика. Язык программирования при этом значения не имеет.

От соискателя в резюме важно получить следующую информацию:

1. минимальную информацию о себе, как о личности;
2. краткую информацию об образовании;
3. подробную информацию о предыдущих местах работы;
4. подробную информацию о навыках и опыте соискателя в контексте вакансии (позиции, должности).

Эти четыре пункта обычно содержит любое резюме по любой специальности. И на этом уровне оно стандартное. А вот какую информацию нужно писать по этим пунктам и как ее преподнести? Это уже позиционно-уникально.

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

1.1) ФИО (отсюда станет ясен пол, так что писать нужно полностью)
1.2) Год рождения (или возраст, если резюме рассчитано на короткий период)
1.3) Город (место жительства, адрес не нужен)
1.4) Семья (брак, дети)
1.5) Образование (высшее/среднее/базовое или др.)
1.6) Отношение с армией (не обязательно писать, но все равно об этом спросят)
1.7) Иностранные языки (перечислить языки с указанием уровня влядения; не стоит тут писать русский, украинский или белорусский)
1.8) Позиция (должность; в одной организации может быть несколько вакансий, к которым подойдет ваше резюме, поэтому указать позицию или позиции, на которые претендует соискатель, нужно обязательно)
1.10) Желаемая заработная плата (реальная заработная плата, на которую нацелен соискатель в настоящее время; это очень важная для работодателя информация, и если соискатель знает, что он хочет, нужно обязательно указать, если не знает — на это укажет отсутствие данной информации; можно писать в стиле «от Х»)

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

2.1) Учебное заведение
2.2) Факультет
2.3) Специальность
2.4) Годы обучения (лучше указать время начала и окончания обучения, т.к. иногда возникают непонятные ситуации, когда указан только один год)
2.5) Окончен ли успешно? (если обучение прервано, об этом обязательно нужно написать отдельно)

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

3.1) Название компании (так, как оно пишется «в миру»)
3.2) Сколько человек в организации/подразделении (опционально, если компания неизвестная, просто поможет оценить ее масштаб)
3.3) Должность (позиция, так, как она называлась в компании; можно дополнить общепринятым названием позиции, если оно отличается от принятого в компании)
3.4) Время работы (лучше всего в формате мм.гггг — мм.гггг / н.в.)
3.5) Обязанности (тезисно: что реально входило в круг обязанностей, пояснения и комментарии будут уместны)
3.6) Сколько человек в подчинении (если были люди в подчинении, об этом обязательно стоит упомянуть, иначе — пропускается пункт — 0 писать не нужно)
3.7) Проекты (это отдельный список проектов, в которых соискатель принимал участие в компании; если подход не проектный или если нет желания все расписывать, можно просто описать в текстовом виде, что соискатель сделал, работая в компании)
3.7.1) Название проекта с кратким описанием (из этого должно быть понятно, какие разработки велись в рамках проекта)
3.7.2) Временные рамки участия в проекте
3.7.3) Результаты (как личные, так и общие)
3.8) Причина ухода (если указывать желания нет, не надо, но все равно скорее всего на собеседовании спросят)

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

4.1) Языки программирования, разметки, запросов и т.д. (т.е. все, что является языком чего-либо или близко к этому)
4.2) Фрэймворки и библиотеки (стоит указывать только общеизвестные; нет смысла указывать самостоятельно разработанные библиотеки и фрэймворки, если ими пользуется только сам соискатель или его [бывшие] коллеги)
4.3) Технологии (то, что не является языком или библиотекой, но существует как стандартизированная и/или общеизвестная технология: AJAX, Web Services (SOAP), COM/OLE и т.д.)
4.4) Операционные системы (если у соискателя в арсенале опыт работы только с несколькими версиями Windows, этот пункт лучше вообще опустить; он имеет смысл, когда есть опыт работы с 2-мя и более разными ОС; версии одной и той же ОС лучше объединить в одну строку; разные дистрибутивы Linux/BSD/UNIX = разные ОС; необходимо указание уровня: администрирование сервера, либо использование в качестве десктопа)
4.5) Прикладное программное обеспечение (IDE, ПО для проектирования, разработки, тестирования, специфичное для специальности; не стоит сюда писать программы общего назначения, такие как Total Commander, FAR,  MS Office, gedit и т.д.)
4.7) Другое (если есть еще что-то важное, о чем соискателю хочется рассказать, следует это сделать)

Резюме лучше всего распространять в формате PDF. Если в качестве формата все же выбран Microsoft Word, то это должен быть формат DOC не выше версии Word 2003. Категорически не рекомендуется размещать резюме прямо в письме или в текстовом файле. Лучше сделать вложение к письму (не стоит размещать ссылку на скачивание резюме). Невыполнение этих требований говорит о неуважении к работодателю и вызывает аналогичное отношение к соискателю.

В моей практике был случай, когда в ответ на вакансию я получил письмо следующего содержания: «Здравствуйте. Слать резюме надоело, поэтому не буду. Если у вас действительно есть сложные задачи и хорошо поставлен рабочий процесс, звоните +37529…..». Сомневаюсь, что с таким подходом человеку удастся найти работу. Естественно, это письмо я проигнорировал. Через несколько дней этот человек перезвонил по телефону. Конечно, стоило сразу сообщить ему, что даже разговаривать с ним нет желания. Но я этого не сделал, и постарался более-менее вежливо с ним поговорить. Через пару минут разговор был закончен по смыслу тем, что он нам не подходит.

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

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

Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное 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. Пароль в открытом виде.

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

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

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

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

При запуске обработки пользовательского 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: тестовое, рабочее) на «установку», чтобы не было путаницы с тем окружением, где устанавливаюся переменные.

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

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

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

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

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

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.

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

Учитывайте, что по информации ByFly радиус действия базовой станции в условиях городской застройки составляет около 1 км.

Updated 21:10 15.04.2010 по Минску.

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

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

Первым выступал Андрей Себрант — директор по маркетингу Яндекса. Общий доклад, ответы на общие вопросы. Убедительный рассказ о том, что время изобретения своих велосипедов с нуля прошло. Сейчас время сбора из комплектующих. Как раз поставой комплектующих и занимается Яндекс: ядро всех докладов — интеграция API сервисов Яндекса и партнерская поставка контента Яндексу в обмен на трафик.

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

Александр заметил, что надо обращать внимание на такие вещи, как карта сайта и robots.txt для повышения позиции в выдаче. Кроме того, существует множество настроек и корректировок в интерфейсе Яндекс.Вебмастер, которые необходимо использовать.

Михаил Сенин кратко поведал о серверисе Яндекс.Сайт. Самый скромный доклад и практически ничего нового.

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

В перспективе развития сервиса карт для Беларуси создание подробных карт областных центров.

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

Роман Иванов, руководитель отдела коммуникационных сервисов, рассказал про пользовательские виджеты в Яндекс.Баре. Бар сейчас существует для IE и Firefox. Виджеты могут быть динамическими (например, отображать количество писем в ящике). Создание виджетов — процесс не сложный. Уж точно не сравнится с процессом создания целого тулбара.

Антон Забанных, довольно эпотажная личность, поведал о возможностях Яндекс.Почты для доменов. Кстати, он руководитель группы сервисов персонального общения (почты). Самое интересное то, что сейчас для сайта действует ограничение в 1000 почтовых ящиков, но оно может быть без проблем и бесплатно повышено для конкретного сайта после контакта с саппортом сервиса. А через API сервиса можно создавать и удалять ящики без участия оператора. Довольно заманчивая возможность для серсвисов, которые хотят предоставить пользователям почту в своем домене.

Антон обозначил, что сервис не предназначен для использования в качестве релея (рассылка писем роботом через SMTP). В этом случае домен могут заблокировать до выяснения обстоятельств. Правда решить проблему можно с помощью прямых рассылок с помощью SPF.

Тигран Худавердян, руководитель отдела портальных сервисов, рассказал о пользе пользовательских виджетов для главной страницы Яндекса. Вера Лейзерович продемонстрировала процесс создания простейших виджетов. Кстати, на создание самого простого виджета ушло примерно 50 секунд.

Смысл создания виджетов в том, что у многих пользователей (в том числе из Беларуси) Яндекс установлен в качестве домашней страницы. Размещают виджеты около 15% этой аудитории. В итоге создатель виджета получает некислый трафик с главной Яндекса на свой сайт, Яндекс — качественный контент, а пользователь — то, что искал. Все счастливы.

Самые простые виджеты на базе RSS создавать очень легко и быстро. Кстати, большинство крупных российских интернет-СМИ именно так и сделали.

Татьяна Исаева (руководитель группы контент-менеджеров Яндекс.Новостей) озвучила, пожалуй, самый тяжелый для прослушивания доклад про Яндекс.Новости. Длинный и монотонный.

В заключении Антон Волнухин рассказал про сервис Яндекс.Блоги и API, которое он предоставляет. Он собственно и является руководителем этого сервиса.

Все с удовольствие отвечали на вопросы в кулуарах. Особенно интересно было пообщаться с Larry Novsky (имя в миру не запомнил). Не знаю, кто он в Яндексе, но он отвечал на все вопросы, и больше всех знал про «телодвижения» Яндекса в Беларуси.

На мероприятии снимали видео и обещали его выложить. Также обещали выложить все презентации в открытый доступ. Ждем пополнения в разделе Яндекс.Субботников.

Обещали повторять Субботник примерно раз в год.

Яндекс молодцы! Спасибо!

Отзывы с Я.Субботника

—

Твитер. Фотографии. Еще фото.

Яндекс в Беларуси (конспект Я.Субботника) | Яндекс.Субботник в Минске. День 1

Кратко суть верстки: внешний элемент a поставляет картинку начала кнопки (левая часть) и делать отступ слева на ширину это картинки, первый вложенный span добавляет конец кнопки и отступ справа, второй вложенный span заливает фон кнопки и объявляет ее высоту.  Последний вложенный span нужен для размещения текста кнопки по-середине.

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

Тестировалась и работает правильно в IE 7, Opera 10, Firefox 3.5, Safari 3.1.2, Chrome 3.0.195.27.

Демонстрация…

Пакетная обработка фотографий на Линуксе — это просто!

* — apt-get install imagemagick