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

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-программистом в частности? Ни автор, ни комментаторы не имеют ко мне никакого отношения.

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

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

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

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

Чтобы решить проблему отказа серверов 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 адресов на ваших доменах. Туда же повалятся уведомления о недоставках.

• исправлена ошибка, которая в последнее время неприятно сказывалась на работе сервиса;
• все переведено на UTF-8
• обновлены списки городов и стран Яндекс.Погоды

Если вы используете старый файл настрое (полученный до 22 ноября), его необходимо обновить.

Сам сервис: http://ru.commontools.net/geoip/ya.weather.get.html

UPD. Было проведено еще одно обновление сервиса.

Детектить версии нужно только популярных в СНГ немобильных версий браузеров, поэтому в моем коде определяется только Opera, Firefox, Safari, Internet Explorer и Google Chrome. Если вам потребуется определить версии большего числа браузеров, код можно легко дополнить.

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

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

Единственный нюанс по коду есть у Safari. Все версии этого браузера всегда посылали в UserAgent тег Safari/build, где buld — версия их движка. Это большая первая цифра, например 528.16. Так версии Safari отображаются в Google Analytics. Но более поздние версии стали писать свою версию в теге Version. Выглядит это примерно так: Version/4.0.2.

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

Скачать PHP-код определения версии браузера.

Перед установкой wAccelerator’а необходимо установить несколько требуемых для сборки пакетов:

# apt-get install build-essential php5-dev

Теперь можно скачать и установить eAccelerator по следующей схеме (убедитесь, что скачиваете последниюю версию исходников):

# cd /tmp
# wget http://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2
# tar xvfj eaccelerator-0.9.5.3.tar.bz2
# cd eaccelerator-0.9.5.3
# phpize
# ./configure
# make
# make install

eAccelerator установлен! Теперь необходимо настроить в конфиге PHP использование eAccelerator’а. В Debian Etchконфигурационные файлы для различных расширений PHP 5 хранятся в каталоге /etc/php5/conf.d, а ссылка на этот каталог присутствует в конфигурационном файле PHP5 /etc/php5/apache2/php.ini, что означает, что все файлы из /etc/php5/conf.d считываются при запуске или перезапуске Apache. Так что все, что нам надо сделать, это создать файл /etc/php5/conf.d/eaccelerator.ini следующего содержания:

vi /etc/php5/conf.d/eaccelerator.ini

extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

(Про разлиные настройки модуля можно почитать на странице: http://www.eaccelerator.net/wiki/Settings.)

Как видно из конфигурации, каталог /var/cache/eaccelerator используется для хранения кэша опкода PHP на диске. Его необходимо создать вручную и разрешить на запись:

mkdir -p /var/cache/eaccelerator
chmod 0777 /var/cache/eaccelerator

Теперь перезагружаем Apache и eAccelerator начинает работать:

/etc/init.d/apache2 restart

При помощи функции phpinfo() убедитесь, что модуль успешно подключен и функционирует.

Исходный материал на английском: http://www.howtoforge.com/eaccelerator_php5_debian_etch

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

Считать ли само слово «кармаграф» названием конкретного сервиса от Goodrone, либо же наименованием класса сервисов (или самого графика) — не знаю. Чтобы не заморачиваться с этим вопросом, свой кармаграф решил назвать иначе — Хаброметр. Ведь не только карму он считает и показывает, но еще хабрасилу и позицию в рейтинге (все, что выдает на данный момент API Хабра). Хаброметр отличается от Кармаграфа не смотря на визуальную схожесть дизайна основного информера. Конечно, я постарался взять все лучшее у Кармаграфа. Основное отличие Хаброметра — информеров будет несколько разных видов. Уже сейчас доступны три вида — кармаграфик, табло и минитабло.

Итак, пару слов о том что получилось. Весь сервис состоит из подсистемы сбора информации и подсистемы ее визуализации. Каждые 2 часа бот собирает информацию о значениях кармы, хабрасилы и позиции в рейтинге (я называю эти данные Хабразначениями) через API Хабра по всем зарегистрированным на сервисе пользователям. Данные сохраняются в базу. В любое время любой желающий может зайти на страницу пользователя и посмотреть историю его Хабразначений. Сейчас показывается история из 500 последних запросов (12 запросов в сутки, получается чуть больше 40 дней). В перспективе отображение определенно изменится, появится календарь. Кроме того, существуют графические информеры, на которых отображаются текущие Хабразначения юзера, максимальные и минимальные значения за время мониторинга и график кармы (наличие определенных компонентов зависит от типа (размера) информера).

Все скрипты написаны на PHP, СУБД используется MySQL (пока во всяком случае). Для рисования используется ImageMagick. Для запуска по расписанию — Cron.

Работает сервис на моем сервере (server.valera.ws), который, к слову, не очень мощный и может не выдержать хабраэффекта. Кстати, с технической точки зрения есть одно существенное отличие работы Хаброметра от Кармаграфа — информеры рисуются не по расписанию после скачки свежих данных, а при первом запросе на отображение информера после обновления данных. Другими словами, после прорисовки информера он кэшируется. Сама прорисовка происходит очень быстро. А кэш чистится после скачки свежих данных. Это позволяет разнести пиковую нагрузку на прорисовку свежих информеров во времени. К тому же, не все зарегистрированные юзеры вообще где-то разместят информеры, а тем более не разместят информеры сразу всех типов. Так что разовая прорисовка всех информеров была бы излишней.

Естественно сервис предоставляется «как есть» и бесплатный для использования. Код Хаброметра я собираюсь открыть, но несколько позже. Сначала требуется отладить его работу, исправить ошибки (которые там наверняка найдутся). Код будет открыт под лицензией GPL 3.

Сейчас сервис работает в режиме beta-тестирования. Буду рад вашим отзывам, багрепортам на e-mail feedbee@gmail.com. В первую очередь хочется добиться стабильности работы и оптимизации ресурсозатрат сервиса. Ну а далее уже заботиться об удобстве пользования.

Первым делом постараюсь доделать запланированные виды информеров. Это 31х31, 88х31 и 350х20. Так же надо будет что-то придумать с расширением цветовых гамм. Когда будет время, поработаю над дизайном страниц сервиса.

P.S. Сайт сервиса (описание системы и бота): http://habrometr.server.valera.ws.

P.S.S. Домен такой выбирал не специально, так случилось что server.valera.ws != valera.ws. Потому такой длинный.

P.S.S. Если из-за хабраэффекта накроется мой сервер, уже не кидайте много камней в огород. Пока не было возможности испытать его под нагрузкой.

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

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

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

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

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

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

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

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

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

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

Но обо всем по порядку. Для начала прочитайте статью Andex’а и «заведите» статистику на web-сервере.

Если во время установки что-то не заработало, читайте комментарии.

У меня возникла такая проблема: если сходу ошибиться с паролем, то система обратиться к гуглу с неправильным паролем столько раз, сколько отчетов экспортируется. В дефалтном варианте это 8 раз. После этого гугл естественно будет требовать от вас ввода каптчи, чтобы убедиться, что вы не подбираете пароли. А возвращать в этом случае он будет временный редирект (Temporary redirect). Его вы в логе и увидите, при этом stat.php будет вывалить нутисы про Undefined index’ы. В этом случае, надо подождать минут 20, а потом повторно запросить статистику, и все будет хорошо :)

Что меня не устроило в дефалтовых отчетах? Только то, что графики по посетителям и по посещениям были разделены. Вместо того, чтобы на одном графике сделать 3 кривых, было сделано 2 графика по 2 кривых (посетители + просмотры, посещения + просмотры).

Я решил это исправить. Но исправить так, чтобы ковырять готовый код по минимуму для простоты и быстроты решения, и для совместимости с потенциальными будущими апдейтами.

Итак, что нужно сделать? Нужно составить новый сводный отчет (*.csv), в котором будут храниться объединенные данные по посетителям, посещениям и просмотрам. И нужно сделать *settings.xml-файл, в котором будут настройки визуализации нового графика.

Генерацию сводного отчета я вынес в функцию. Она берет два отдельных отчета и составляет из них общий:

function makeFull($postfix = '')
{
	$fvisits = fopen($GLOBALS["path"] . "visits$postfix.csv", 'r');
	$fvisitors = fopen($GLOBALS["path"] . "visitors$postfix.csv", 'r');
	$ffull = fopen($GLOBALS["path"] . "full$postfix.csv", 'w');
	while (!feof($fvisits))
	{
		$visits_line = explode(';', fgets($fvisits));
		$visitors_line = explode(';', fgets($fvisitors));
		if (count($visits_line) == 3 && count($visitors_line) == 3)
		{
			// новая строка =     дата       ;        посетители       ;       посещения       ;       показы & \n
			$new_line = $visitors_line[0] . ';' . $visitors_line[1] . ';' . $visits_line[1] . ';' . $visitors_line[2];
			fputs($ffull, $new_line);
		}
	}
	fclose($fvisits);
	fclose($fvisitors);
	fclose($ffull);
}

Эту функцию надо поместить в stat.php (например в конец). Вызвать ее нужно 2 раза (отчет за все время и отчет за последние 3 месяца):

makeFull();
makeFull('_3');

Это нужно делать после генерации соответствующих отчетов, т.е. проще всего дописать в конце файла stat.php.

Далее из файлов visitors_3_settings.xml и visitors_settings.xml я сделал копии (full_3_settings.xml и full_settings.xml) и добавил в настройках графиков новый график-кривую (новую секцию <graph gid=»3″></graph>).

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

	<div id="visitors" align="center" style="padding-bottom:80px">
<strong>Для просмотра сожержимого, установите последнюю версию Adobe Flash Player</strong>
</div>
<script type="text/javascript">
	// <![CDATA[
	var so = new SWFObject("amline.swf", "amline_chart", "600", "350", "8", "#FFFFFF");
	so.addVariable("path", "./amline/");
	so.addVariable("settings_file", escape("full_settings.xml?<?php echo mktime();?>"));
	so.addVariable("data_file", escape("full.csv?<?php echo mktime();?>"));
	so.addVariable("preloader_color", "#BBBBBB");
	so.write("visitors");
	// ]]>
</script>
<div id="visitors_3" align="center" style="padding-bottom:80px">
<strong>Для просмотра сожержимого, установите последнюю версию Adobe Flash Player</strong>
</div>
<script type="text/javascript">
	// <![CDATA[
	var so = new SWFObject("amline.swf", "amline_chart", "600", "400", "8", "#FFFFFF");
	so.addVariable("path", "./amline/");
	so.addVariable("settings_file", escape("full_3_settings.xml?<?php echo mktime();?>"));
	so.addVariable("data_file", escape("full_3.csv?<?php echo mktime();?>"));
	so.addVariable("preloader_color", "#BBBBBB");
	so.write("visitors_3");
	// ]]>
</script>

Вот и все. Теперь страница статистики (index.php) выглядит примерно так:

Вид сводных диаграм из Google.Analytics

Скачка готовых файлов.

Мой мод вывода статистики затронул файлы из пакета statga от Andex’а. Изменения производились в версии statga 2.0.1. Не каснулись пакета только 2 новых файла: full_3_settings.xml и full_settings.xml. Их вы можете смело брать из моего пакета в любом случае. Как модернизировать файлы пакета statga для изменения визуализации написано выше. Так что, если Andex обновит версию, вы сможете внести правки вручную. Если нет, можно использовать готовые файлы версии 2.0.1:

Скачать модефицированную версию statga 2.0.1 feedbee mod.

Да, питонисты — тихие спокойные ребята, а пхп-шники — агрессивные дурачки, потому что:

1) Питонисты и Рубироиды при каждом удобном случае лезут в топики про php и кричат, что php — гавно, а руби/питон — круто!

2) На форумах и в IRC-чатах, когда кто-то задает вопрос `как это сделать в php/java/с++/c#` тут же находятся рубироиды и питонщики, которые кричат, что это не надо делать на данном языке, а надо делать на руби или питоне! А автор вопроса — мудак!

3) Когда дается ответ на вопрос `как это сделать в php/java/с++/c#` в несколько строк кода, тут же находится довольный рубироид и пишет все в одну только ему понятную строчку и кричит `вот как все просто на руби, а вы мудаки все еще пишете на ХХХ`!

Как же это уже раздражает…

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

Для профилирования нам понадобится компонент подсчета времени выполнения функций PHP и формирования отчета и компонент визуального представления этого отчета для анализа.

Существуют как минимум 3 профайлера PHP-кода: Xdebug, Advanced PHP Debuger и DBG. Скажу честно, два последних я даже не рассматривал по двум причинам: Xdebug — самый популярный, Xdebug встроен в сборку xampp, которая стоит на моей локальной машине.

Установка Xdebug

Интеграция Xdebug’а в PHP очень проста. С сайта www.xdebug.org необходимо скачать DLL-extension для вашей версии PHP. Вот файл для PHP 5.2.1-5.2.6 под Windows. Скачанный файл необходимо положить в каталог расширений PHP (extension_dir). А в php.ini добавить следующие строки:

extension=php_xdebug.dll

[XDebug]
;; Only Zend OR (!) XDebug
zend_extension_ts=»c:\php\ext\php_xdebug.dll»
xdebug.remote_enable=true
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.profiler_enable=1
xdebug.profiler_output_dir=»c:\temp»

При этом строки секции [Zend] требуется закомментировать (поставить ; в начале каждой строки):

[Zend]
;zend_extension_ts = «c:\php\zendOptimizer\lib\ZendExtensionManager.dll»
;zend_extension_manager.optimizer_ts = «c:\php\zendOptimizer\lib\Optimizer»
;zend_optimizer.enable_loader = 0
;zend_optimizer.optimization_level=15

Установите правильные пути в параметры zend_extension_ts и xdebug.profiler_output_dir секции XDebug. Путь xdebug.profiler_output_dir — это каталог, в который будет записан файл отчета.

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

Установка KCachegrind под Windows

Открываем любую страницу вашего сайта и в каталоге xdebug.profiler_output_dir появляется файл отчета. Открывать его в Блокноте или другом средстве просмотра текстовых файлов нет никакого смысла. Его формат невозможно воспринять в текстовом виде. Для просмотра файла отчета понадобится средство KCachegrind, которое требует наличия KDE для запуска.

Есть, правда, еще WinCachegrind, но эта программулина глючная, слабенькая и с 2005 года не обновляется. Мой файл отчета она прочитать не смогла (parse error).

Итак, приступаем к установке KCachegrind под Windows. Благо, она абсолютно простая.

1. Зайдите на www.winkde.org/pub/kde/ports/win32/installer/ и скачайте самую последнюю версию установщика.
2. Запустите установщик (есть картинки процесса установки), выберите каталог установки (например в C:\KDE), скачайте то, что вам нужно (я выбрал все пакеты — это около 230 Мб).
3. Добавьте переменную окружения KDEDIRS (Пуск > Панель управления > Система > Дополнительно > Переменные среды, нажмите «Создать» в разделе Пользовательские переменные и создайте переменную с именем KDEDIRS и значением равным папке, в которую Вы установили KDE4, напр. C:\KDE).
4. Добавьте папку библиотек, %KDEDIRS%\lib, и папку исполняемых файлов, %KDEDIRS%\bin, к переменной %PATH% Windows. (Пуск > Панель управления > Система > Дополнительно > Переменные среды, дважды щелкните на системной переменной Path и добавьте эти строки, разделяя их точкой с запятой.)
5. Если у Вас не установлена Visual Studio 2005 (или 2008), то скачайте и установите «Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)«.
6. Попробуйте запустить какое-нибудь Qt приложение в папке bin, например linguist.exe.
7. Если получилось, попробуйте запустить любое приложение KDE, такое как kwrite.exe.

Дополнительная информация по установке.

На этом установка закончена. Вы можете запустить KCachegrind (c:\KDE\bin\kcachegrind.exe) и скормить ей файл вашего отчета профайлера.

Дополнительную информацию по профилированию PHP-кода можете почитать на сайте Zend’а, а я планирую написать еще статейку на эту тему, может даже завтра.

Следующий пример абсолютно работоспособен:

<?php

$name = ‘что угодно – 1 + 44.4′;

$$name  = ‘ДА!’;

echo $$name;

Оказывается, шаблонизатор для PHP-сайтов Smarty еще жив! 17 октября на сайте появилась новость о том, что доступен альфа-релиз 3-й версии со значительными изменениями, который не совместим с версией 2.

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

Интерфейс шаблонизатора особо не изменился. Это всё те же display(), fetch() и assign(), которые покрывают процентов 99 всех потребностей. Исчез метод assign_by_ref().

Внутренности же претерпели более существенные изменения:

• Отказ от поддержки PHP4 и полное использование объектно-ориентированных возможностей PHP5. То есть в шаблонах можно использовать разыменования объектов без костылей;
• Объектно-ориентированный подход затронул и плагины: теперь каждый плагин является классом, отнаследованным от Smarty_Internal_PluginBase
• Файл основного класса — Smarty.class.php — стал подозрительно маленьким: всего 11 кб, включая здоровенные спойлеры лицензии LGPL ;)
• Все требуемые элементы, исключённые из ядра, подгружаются лишь по мере необходимости (lazy loading)
• Маленькая приятность — встроенная реализация паттерна singleton.
• Поддержка нативных PHP-шаблонов.

Надо сказать, что по сравению с веткой 2.x, дистрибутив значительно потолстел: папка libs, экспортированная из SVN, заняла немногим менее 800 кб, в то время как в версии 2.6.20 её вес был был порядка 320 кб.

Подробности о релизе — в официальном README.

Желающие могут вытащить версию из SVN:
svn checkout smarty-php.googlecode.com/svn/branches/Smarty3Alpha/

Вот тут groups.google.com/group/smarty-developers/browse_thread/thread/c29ae569842882cd немного про синтаксис:

PHP: <?= $foo ?>
Smarty: {$foo} // same as Smarty 2

PHP: <?= $foo['bar'] ?>
Smarty: {$foo['bar']} // no more {$foo.bar}

PHP: <?= $foo[$bar][$foo['bar']] ?>
Smarty: {$foo[$bar][$foo['bar']] ?> // identical to PHP

PHP: <?php foreach($foo as $bar) {… } ?>
Smarty: {foreach $foo as $bar}… {/foreach} // just a delimiter
adjustment

PHP: <?php for($x = 0; $x<$y; $x++) {… } ?>
Smarty: {for $x=0; $x<$y; $x++}… {/for} // get rid of {section}

PHP: <?php if($foo == $bar && $blah !== ‘ziggy’) {… } ?>
Smarty: {if $foo == $bar && $blah !== ‘ziggy’}… {/if}

Zend Framework — это круто. Круто, потому что удобно и логично. Потому что в нем нет ничего лишнего: можно использовать как весь фреймворк целиком, так и отдельные его компоненты. Все компоненты можно заменить своими, не нарушая целостности фреймворка. Зенд не представляет готовые части сайта, и тем более — сайты. Zend Framework — это помощник в создании сайта, не более того. Очень гибкий, масштабируемый.

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

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

Изучать ZF начал с версии 1.6. Почитал Quick Start, затем начал читать мануал. Обратил внимание, что большинство идей ZF сходятся с теми идеями, на которых я строил свой движок, причем автономно, не изучая особенности других фреймворков. Только вот реализация этих идей, естественно, у ZF гораздо лучше, полнее. Факт схожести идей заложил в моем сознании доверие к этому фреймворку. Кроме того, слышал хорошие отзывы о нем от других программистов, которые использовали раньше и используют сейчас разные фреймворки и имеют достойный опыт сравнения.

Может быть эта запись в блоге подвигла вас на изучение ZF? Тогда расскажу вам вот что. Прежде всего, сходите на сайт Zend Framework‘а и оглядитесь вокруг :) Изучение начинайте с Quick Start‘а. Там все довольно хорошо описано, но с большего. Т.е. вы сможете подготовиться к восприятию тонкостей и деталей подробного мануала. Соберите на вашем сервере сайт, который предлагает Quick Start, поэкспериментируйте с ним. Только после этого переходите к полному руководству программиста.

Так как руководство состоит из описания отдельных компонентов фреймворка (52 главы-компонента на данный момент), нужно определиться, с чего начать. Поможет опредлитсья вам как раз Quick Start. Я приведу свой порядок изучения: Introduction, Zend_Controller, Zend_Cache, Zend_Loader, Zend_View, Zend_Layout, Zend_Config, Zend_Db. Дальнейший порядок, в принципе, значения не имеет.

Статья с пошаговой инструкцией по установке memcached под ОС Windows. Скачать дистрибутив для Win32 можно отсюда: http://jehiah.cz/projects/memcached-win32/

Мануал по пользованию memcached из PHP: http://www.php.net/memcache.

Что кэшируем?

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

2. Кэширование результатов запросов, которые очень редко меняются. Например, если вы храните настройки сайта в базе, то при каждой загрузке страницы эти настройки надо получить из базы. Такой запрос отработает моментально быстро, и очевидной необходимости его кешировать нет. Но если выделить с десяток таких запросов, то их суммарное время уже можно считать значительным. При этом нагрузка ложится на часто самое узкое место в производительности сайта — демона базы данных. По-этому, может иметь смысл хранить результаты таких запросов на сервере кэширования. Для такого кэширования подойдет только способ 2 из пункта 1. Кстати, сюда же можно отнести кэширование «статических страниц», которые динамически генерирует CMS.

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

Юзерозависимость

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

В случае юзерозависимой сущности кэширования надо хранить не один элемент данных (например, число), а массив этих элементов, в котором ключ — id пользователя. И операции с такой сущностью должны быть следующие: а) получение/установка/удаление данных сущности для данного пользователя, б) получение/удаление данных сущности для всех пользователей. Для обеспечения автоматизации работы такого функционала удобно написать класс-оболочку для memcached, заточенную под конкретный фреймворк/cms (так как подсистема пользователей у всех реализована по-разному).

Чего не хватает в memcache?

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

Думаю, что завтра реализую оболочку для API memcached в PHP, которая реализует эти три дополнения, и открою ее для всех желающих.