Простые вещи: February 2009

Friday, February 20, 2009

Размышения о php, его применении

Статья о моих метаниях в процессе разработки и правильном использовании PHP.

Для затравки желательно прочитать статью 10 принципов PHP специалистов.

В принципе ничего нового. Теперь что думаю я.

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

2. Фреймворки - монструозны, а если это сложить с пунктом один, получаем, что они еще и тормозны по определению.

Исходя из этих требования, а также под угрозами бешеных нагрузок я участвовал в написании проекта, который был минималистичен в плане порождения сущностей. На удобстве и скорости разработки это мало сказалось, т..к была изобретен минимальный фундамент (велосипед), который не давал скатиться в написание портянок. Зато время генерации при небольшой и средней нагрузках было 0.01-0.03 сек. Но т.к. администратор выбрал распределённую фс, это выразилось в подскакивании времени генерации до 0.1 сек.

В ходе этого я выяснил.

3. Проблемы описанные в пп 1,2 неприятны, но решаемы, в основном кэшированием и настройками серверов, или отказом от PHP.

Скажем так, оптимизация веб-сервера (отключение модулей апача, extensions php) дало прирост 10-20%, (смена апача на lighttpd +fcgi) дало прирост еще на 30%. Я бы не смог настолько оптимизировать код по всему проекту.

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

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

Прошло время я наигрался и тем, и с другим. Сразу условлюсь что проект я предлагал делать на java, но руководство выбрало php по понятным всем причинам.

А теперь пример, который просто меня убил.

Задача : написать ладдерную систему для неких игр. Грубо говоря чем с более крутым человеком ты играешь, тем больше очков ты получишь, тем выше будет твой рейтинг.

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

Реализация на php:

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

Реализация на python:

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

Реализация - быстрее чем на php(по времени разработки и отладки), скорость работы - выше, удобство использования - выше.

Самый большой плюс, система работает online!

Из недостатков - новая сложность системы в виде нового сервера.

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

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

Sunday, February 8, 2009

PHPUnit, DBUnit, тестирование или Class PHPUnit_Extensions_Database_TestCase could not be found

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

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

В процессе написания тестов возникла необходимость в инструменте для работы с fixtures + тестирования изменений в базе данных, DBUnit как extension к PHPUnit подошел замечательно.

Далее грустная история о нескольких часах дебага. И об ошибке "Class PHPUnit_Extensions_Database_TestCase could not be found"

1. Изначально был тест XXX_Test


require_once 'PHPUnit/Framework/TestCase.php';
class XXX_Test extends PHPUnit_Framework_TestCase
{
 
 public function testSmth()
 {
  $this->assertTrue(true); 
 }
}

Файл назван xxxTest.php

За некоторое время работы с phpunit я отвык пользоваться формой запуска


$phpunit TestClassName path/to/test/file.php

И пишу просто


$phpunit path/xxxTest.php
PHPUnit 3.3.10 by Sebastian Bergmann.

..

Time: 0 seconds

OK (1 test, 1 assertion)

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

В итоге класс становится таким.


require_once 'PHPUnit/Extensions/Database/TestCase.php';
class XXX_Test extends PHPUnit_Extensions_Database_TestCase
{

 protected function getConnection()
 {
  return null;// $this->createDefaultDBConnection($this->_dbObject,'sqlite'); 
 }
 
 protected function getDataSet()
 {
  return '';//$this->createFlatXMLDataSet('path/to/fixtures/dummy.xml');
 }
 
 public function testSmth()
 {
  $this->assertTrue(true);
 }
}

Функции коннекта и загрузки данных, преднамеренно реализованы криво.

Запускаем.


$phpunit path/xxxTest.php

О***ваем


PHPUnit 3.3.10 by Sebastian Bergmann.

Class PHPUnit_Extensions_Database_TestCase could not be found in /var/www/toox.com.lottery/core/classes/db/query/Rapid_Db_Query_IteratorTest.php

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

В итоге оказалось, что при работе с DBUnit обязательно использовать полную форму запуска phpunit

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


$phpunit XXX_Test path/xxxTest.php

PHPUnit 3.3.10 by Sebastian Bergmann.

E

Time: 0 seconds

There was 1 error:

1) testSmth(XXX_Test)
Argument 1 passed to PHPUnit_Extensions_Database_DefaultTester::__construct() must implement interface PHPUnit_Extensions_Database_DB_IDatabaseConnection, null given, called in /usr/share/php/PHPUnit/Extensions/Database/TestCase.php on line 146 and defined

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

Thursday, February 5, 2009

перенос svn репозитория.

Три раза менял vds. Было жалко свой svn репозиторий, и озадачился вопросом его переноса на другую машину.
Оказалось все просто как всегда.

Сначала скидываем репозиторий в dump file.


#svnadmin dump /home/svn/repo/ > /tmp/mysvn.dump

Т.е. svnadmin dump выплевывает dumpfile-formatted строки в stdout, который перенаправляется в наш файл /tmp/mysvn.dump

На другой машине


#scp login@host:/tmp/mysvn.dump /tmp
#svnadmin create /new/repo/path
#svnadmin load /new/repo/path < /tmp/mysvn.dump

Копируем при помощи scp файл себе локально, затем создаем новый репозиторий при помощи svnadmin create , далее командой svnadmin load, которая как раз читает из stdin dumpfile-formatted строки, переносим сдампленные данные.

Хотя в последнее время все чаще смотрю на mercurial, и даже начинаю использовать, пока нравится, но интересно посмотреть на это когда буду работать не один. В случае hg перенос был бы обычным бранчем, который он умеет делать через ssh (Как я думаю, могу и ошибаться).

Простые вещи