Скачивай, Смотри онлайн, Помогай. Бесплатно, без регистрации и рейтингов! ;) Коллективное строительство фильмотеки торрент-трекера!

Представляю на суд торрент-трекер фильмов editorrent.com

Что должно в нем быть (на мой взгляд):
— отсутствие регистрации;
— отсутствие рейтингов для скачиваний;
— просмотр информации о фильме, описаний, комментариев;
— возможность просматривать скриншоты, трейлеры;
— смотреть фильмы онлайн;
— качать торренты.




( Читать дальше )

Привет всем. Это мой первый пост на ха ПыхаПыхаРу!
Сегодня написал простой валидатор. Короче может это и баян, но меня вроде пока устраивает. Состоит из одного класса, от которого потом наследуются нужные.

( Читать дальше )

Тесты сравнивающие производительность php_memcache и php_memcached. Так же тесты производительности getMulti() и setMulti().

php_memcached ничем не уступает php_memcache по быстродействию стандартного набора функций. А появившиеся в нём mult-запросы могут значительно увеличить скорость.

blgo.ru/blog/2010/05/28/mc-tests/

Igbinary — расширение для PHP, позволяющее заменить стандартные функции сериализации.

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

По скорости и компактности полученного результата Igbinary превосходит serialize в несколько раз.

Кроме предоставления функция igbinary_serialize() и igbinary_unserialize(), позволяет так же заменять механизм сериализации и в других местах: при сохранении сессий или записи в Memcached.

Более подробно и с тестами: Сериализация с Igbinary.

Думки
Я хочу написать не набор компонент на все случаи жизни, а скорее набор правил по склеиванию цельного легко управляемого продукта. Готовые компоненты будут как иллюстрации к нужным интерфейсам. Фреймворк должен становиться все проще и проще.
Про «звездные объекты»: (цитата с agiledev)

В любом проекте существует набор объектов, которые требуются большому количеству клиентов. К таким можно отнести соединение с базой данных, объекты конфигурации, пользователь, система прав, запрос(request) или ответ(response) системы, логгер, кеш – этот список можно продолжать. Раз они требуются большому числу клиентов – значит, они должны быть как минимум легко доступны практически в любой точке приложения. Для приложения средних размеров этот список уже большой – все через конструктор не передашь. Кроме этого, иногда возникает необходимость в том, чтобы сменить, скажем, метод обработки ошибок, драйвер базы данных, механизм кеширования и т.д. Идеально, если наше приложение потребовало бы при этом минимальных модификаций, не затрагивая при этом кода, реализующего бизнес-логику.

В Qb явной звездой выступает класс Qb :) Но, как мне кажется, эта уступка оправдана. Все прочие компоненты могут и должны добываться через реестр (Service Locator).

Чтиво
agiledev.ru: Управление зависимостями в PHP-коде

Последние изменения в репозитарии Qb
* Отказался от геттеров/сеттеров в компонентах. Казалось бы так красиво писать
$this->router->route()
вместо
Qb::getComponent('router', 'IQbRouter')->route()
но на самом деле длинный вариант информативнее.

Convention over Configuration

Пришел к убеждению, что надо снижать требования к конфигурированию приложения. В итоге переделал систему событий. Ядро перекроил, дема publicate временно от него отстала и не будет работать. А вот мой Hello world:

Точка входа index.php

<?php

require '../../framework/qb.php';

Qb::init()->request()->end();

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

Класс приложения в файле {appDir}/protected/application.php:

<?php

class Application extends QbCustomComponent
{
	public function request()
	{
		echo $this->baseUrl . "<br /><br />\n";
		echo 'Hello world!';
		return $this;
	}
}

$this->baseUrl реально вызывает Qb::get('baseUrl')
return $this необходим для поддержки цепочек fluent (см. выше)

Этот код уже работает, но будем потихоньку усложнять.

События через магию
Теперь события могут происходить в любом компоненте, а не в глассе Qb. Реализовано через магический метод __call — когда мы обращаемся к методу $foo->bar() будут вызваны события
beforeBar, onBar и afterBar. С оговоркой: yfcnjzobq метод bar должен отсутствовать, иначе магия не сработает. Вместо него в классе компоненты мы можем описать onBar()

Снова заглянем в наш стартовый скрипт
Qb::init()->request()->end();
Ядро фреймворка в методе init выполняет некую начальную инициализация и возвращает ссылку на объект-приложение. У этого приложения мы по цепочке вызываем методы request и затем end. Вот на end мы и протестируем события. $app->end() будет вызван как при нормальном завершении, там и при аварийном после ошибки/неперехваченного исключения. Это хорошее место для обязательных действий в конце.

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

Для простоты я описал обработчик в этом же классе. Можно было забиндить сторонние обработчики через $foo->wrap()

Перед окончанием работы выведем на страницу текст ошибок, если они были.

class Application extends QbCustomComponent
{
	public function request()
	{
		1/0; // warning
		echo $this->baseUrl . "<br /><br />\n";
		echo 'Hello world!';
		return $this;
	}

	public function beforeEnd()
	{
		$log = Qb::getLog(array(E_ERROR, E_WARNING));
		foreach ($log as $l) {
			list(, $message, $file, $line, , ) = $l[0];
			echo '<p>' . ($l[2] == E_ERROR ? 'ERROR' : 'WARNING') . ' <em>"'
				. $message . '"</em> in module <strong>' . basename($file, '.php')
				. '</strong> line <strong>' . $line
				. "</strong></p>\n";
		}
	}

Новости с полей:
Документы теперь реально можно редактировать.
Прикрутил простой валидатор.



Вычистил описания интерфейсов. Не осталось статических компонент. Не то, чтобы я был противником статических классов :) просто не хочу дублировать определения интерфейсов ещё и для статики.

Написал простую демку для испытания каркаса. Лежит в репозитории trunc/demos/publicate/



Всё, что делает — по шаблону мастрячит странички из mardown-файлов.



( Читать дальше )

Let it be!

Я стартую свой проект на PHP: веб-фреймворк Qb. Находясь под влиянием отличного фреймворка Yii, всё-таки хочу получить что-то более компактное и простое, где бы я мог применить свои идеи и наработки без лишнего мусора.

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

Как оно работает

Схема типичного приложения вот:




( Читать дальше )

Поведаю вам как сделать автоматические субдомены для связки nginx-apache.
Имеем структуру папок такую

path/to/website/example.com
		example.com/www //домен по умолчанию, обращение через example.com, www.example.com
		example.com/subomain //subdomain.example.com
		example.com/other-sub //other-sub.example.com

Конфиг NGinx:

server {
    listen   80;
    server_name example.com *.example.com;
    set $subdomain "www";
    if ($host ~* ^([a-z0-9-\.]+)\.example.com$) {
        set $subdomain $1;
    }
    if ($host ~* ^www.example.com$) {
        set $subdomain "www";
    }
    access_log /var/logs/nginxaccess_example.com.log main;
    error_log /var/logs/nginxerror_example.com.log;
    # Статическиое наполнение отдает сам nginx
    # back-end этим заниматься не должен 
    location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js)$ {
        root path/to/website/example.com/$subdomain;
    }
    # Перенаправление на back-end
    location / {
        root path/to/website/example.com/$subdomain;
        proxy_pass  http://127.0.0.1:8181;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-for $remote_addr;
		proxy_set_header Host $host;
		proxy_connect_timeout 120;
		proxy_send_timeout 120;
		proxy_read_timeout 180;
    }
}

Apache
Вариант #1 — Используем vhost_alias
Конфиг:

<VirtualHost *:8181>
	ServerName example.com
	CustomLog /var/logs/apache2_example.com.log combined
	DocumentRoot /path/to/website/example.com/www
</VirtualHost>
<VirtualHost *:8181>
	ServerName www.example.com
	ServerAlias *.example.com
	CustomLog /var/logs/apache2_subdomainexample.com.log combined
	VirtualDocumentRoot /path/to/website/example.com/%1
</VirtualHost>	

Вариант #2 — Используем mod_rewrite:
Конфиг:

<VirtualHost *:8181>
	ServerName example.com
	CustomLog /var/logs/apache2_example.com.log combined
	DocumentRoot /path/to/website/example.com/www
	ServerAlias *.example.com
	RewriteEngine On
	RewriteCond %{HTTP_HOST} !^www.example.com$
	RewriteCond %{HTTP_HOST} ^((.*)\.)example.com$
	RewriteRule ^/(.*) /%2/$1
</VirtualHost>

На этом все. Выражаю благодарность adword'у.