Yet another Blog

Автоматизируем тестирование

2012-02-02T00:40:00.000+04:00

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

Во-первых, это было мое первое знакомство с такими специалистами в тестировании, как Алексей Баранцев и Наталья Руколь. Очень понравился и Алексей, и Наталься, и шляпа в которой была Наталья :-)

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

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

Алексей говорил, что начать следует с обоснования. Это отдельная стадия, во время которой нужно проанализировать работу коллег-тестировщиков, разработчиков, убедиться, что сокращение времени одного тестирования будет оценено по достоинству. Еще бы!

Далее следует заняться составлением стратегического плана. При этом нужно использовать информацию, которую вы получили при обосновании. Нужно решить, что можно поменять, а что нет. Решить, что можно поменять, но не сразу. Очень сокращенный пример такого плана быть таким: «за год сократить время выполнения тестов в 2 раза без снижения полноты покрытия». Или таким: «за год увеличить покрытия кода тестами с 40 до 80 процентов а счет увеличения количества негативных тестов без увеличения времени выполнения».

Далее, собственно идет стадия реализация вашей стратегии. При этом есть пять разновидностей ваших действий:

выжидание – вы тратите какое-то небольшое время, возможно случайно образовавшееся. Например, если заболел ведущий разработчик, то у тестировщиков наверняка будет меньше работы. Это время стоит использовать с пользой, например, подготовить один из тестов.
прорыв – вы определенными, не самыми сложными действиями, получаете сравнительно легкий и эффектный результат. Пример прорыва – это использование рекордера тестов.
давление – вы посвящаете автоматизации каждый день один-два часа, а то и больше. Или, например, автоматизируете тест любого бага, который проявился дважды.
массированный удар – до достижения запланированного уровня автоматизации осталось уже совсем немного, и вы начинаете тратить уже как минимум половину рабочего времени на автоматизацию, чтобы быстрее все «добить».
и последняя стадия – это удержание, когда приоритетом для вас является защита и реагирование. Здесь например, вы принимаете решение сразу автоматизировать тесты.

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

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

Eclipse PDT: начало работы

2011-11-13T20:47:00.001+04:00

Разбирая свои старые файлы, я наткнулся на черновик статьи, которую я так и не опубликовал. В материале речь идет об установке Eclipse для работы с PHP на удаленном сервере. Ранее я уже приводил решение для комфортной работы с Eclipse PDT по SSH. Здесь же будет небольшой гид, который должен быть полезен прежде всего тем, кто совсем немного работал с данной IDE.

Выбор дистрибутива
Прежде всего нужно выбрать подходящий дистрибутив Eclipse. Разработку для PHP в Eclipse можно вести благодаря проекту PHP Developer Tools (PDT). Чтобы загрузить дистрибутив IDE можно выбрать одну из опций, которые доступны на текущий момент:

скачать Eclipse 3.7 Classic и через меню Install new Software установить пакет "PDT Development Tools All in One SDK";
скачать Eclipse 3.6 для PHP-разработчиков (т.е. предыдущую версию IDE, но специальную сборку для PHP);
найти на странице PDT ссылки для загрузки Eclipse 3.7 для PHP-разработчиков (такие сборки у проекта PDT появились сравнительно недавно).

Начало работы
Eclipse не нужно устанавливать. Достаточно просто разместить файлы в директорию, например "C:\eclipse" для пользователей Windows.

После этого можно просто запустить "eclipse.exe". Среда разработки начнет запускаться и предложит выбрать путь до вашего рабочего каталога "Workspace". Можно выбрать примерно такой же путь, как на рисунке ниже: "С:\Users\username\workspace".

Теперь Eclipse должен запуститься. Начальный вид окна может быть различным, но нам, PHP разработчикам, интересна перспектива PHP (это настройки и вид среды разработки). Открыть перспективу PHP можно способом, показанным на рисунке ниже: выполнить команды меню "Window => Open perspective => PHP (или Other…, если PHP нет в списке)".

Редактирование удаленных файлов
В нашей работе довольно распространена необходимость редактировать файлы, расположенные на удаленных серверах. Eclipse PDT изначально позволяет работать в основном через проекты. Для удаленных файлов – удаленные проекты. Это не совсем удобно, и было бы лучше иметь возможность простого редактирования файлов, неважно локальных или удаленных.

Для этого необходимо установить расширение "Target Management" или по-другому его еще называют "Remote Systems". Для установки расширения необходимо отрыть меню "Help => Install New Software". Далее в окне выбора пакетов для установки необходимо найти "Remote System Explorer End-User-Runtime", обычно пакет находится в разделе "General Purpose Tools". После перезапуска в перспективу PHP следует добавить окно из только что установленного дополнения. Для этого следует выполнить команды: "Window => Show View => Other…".

В списке следует найти и выбрать "Remote Systems", как на рисунке ниже:

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

Создание соединения с сервером
Теперь попробуем установить соединение с удаленным сервером . Первое, что нужно сделать, это кликнуть правой кнопкой в пустой области окна "Remote Systems" и выбрать там: "New => Connection…". Далее из списка следует выбрать тип соединения "SSH Only".

Теперь нужно указать параметры соединения, достаточно ввести только Host Name, например "example.hostname.ru". Соединение создано, теперь можно попробовать подключиться. Для этого следует открыть одну из папок на удаленном сервере, например "My Home". Eclipse должен запросить у вас параметры учетной записи: логин и пароль. Если все параметры были указаны верно, теперь есть возможность легко открывать и редактировать удаленные файлы.

Кроме того, в Remote Systems можно без проблем открывать и локальные файлы, как это показано на рисунке ниже:

Автодополнение и временные файлы
Несмотря на то, что мы использовали готовый дистрибутив для PHP разработчиков или установили пакет PDT All-in-One, есть некоторые проблемы при редактировании удаленных файлов. В частности, плохо работает автодополнение.

Этот вопрос уже изучался, и было найдено некоторое решение проблемы. Оказалось, что для удаленного редактирования файлов через Remote Systems используется специальный проект. Если этот проект преобразовать в PHP-проект, то проблем с автодополнением не должно быть.

Фактически нужно выполнить следующие действия:

Необходимо закрыть Eclipse;
В проводнике или в другом файловом менеджере, например Nautilus’е, открыть рабочий каталог Workspace, для меня это каталог "С:\Users\hamuhin\workspace";
В каталоге Workspace должна быть папка "RemoteSystemsTempFiles", - это и есть проект, который нужно преобразовать;
В папку RemoteSystemsTempFiles необходимо скопировать файлы ".buildpath: и ".project", скачать их можно здесь. Если файлы уже существуют в каталоге, то их нужно переименовать в бэкап, а новые файлы разместить на их место;
Это почти все, теперь можно снова запустить Eclipse.

Проверим, что автодополнение работает. Для этого откроем любой файл на сервере webdev и попробуем ввести код $abc = str и нажать Ctrl+Пробел. Должен появиться список функций, как на рисунке ниже:

В процессе работы на диске может скопиться очень много файлов, которые когда то открывались на удаленных серверах. Со временем это может сильно замедлить работу Eclipse. Чтобы этого избежать, нужно ограничить количество временных файлов. Для этого необходимо открыть настройки Eclipse: "Window => Preferences".

В окне настроек следует найти раздел "Remote Systems / File Cache" и там включить опцию Limit cache size. Оптимальное значение может зависеть от объема оперативной памяти на машине, я обычно устанавливаю 512 или 256 МБ.

Настройки Proxy
Если Eclipse не может соединиться с сервером, то эти проблемы с сетью могут быть связаны с настройками Proxy. Для того чтобы проверить или изменить эти параметры следует открыть окно настроек Eclipse: "Window => Preferences". В фильтре можно написать "proxy", чтобы быстро найти нужный раздел.

Фильтры и скрытые файлы в Remote Systems
Часто необходимо редактировать файлы, которые находятся, например, по такому длинному пути: "/var/www/my-big-project/htdocs". Чтобы каждый раз не выбирать последовательно эти каталоги в окне Remote Systems, можно создать фильтр, который позволит быстро открывать нужные файлы.

Для создания фильтра на интересуещем каталоге, например "my-big-project", нужно кликнуть правой кнопкой и выбрать из меню: "New => Filter…". Далее можно следовать инструкциям, ничего не меняя, и только на заключительном этапе указать имя фильтра, например «my-big-project». Теперь к файлам можно обращаться по более короткому пути, с помощью нового фильтра.

Кроме того, часто бывает нужно отредактировать скрытые файлы, например ".htaccess". Обычно скрытые файлы с точкой вначале не отображаются в Remote Systems. Чтобы изменить эту опцию, нужно открыть окно настроек "Remote Systems / Files" и установить галочку в опции "Show hidden files".

Работа с разными кодировками
В настройках Eclipse можно устанавливать кодировку по умолчанию. Однако бывает так, что один проект создается в UTF-8, а другие ведутся в CP1251. Каждый раз менять настройку кодировки не очень удобно. К счастью можно задавать кодировку только для отдельных проектов, файлов или каталогов. Чтобы изменить кодировку для каталога, необходимо кликнуть правой кнопкой по нему и выбрать «Properties». В окне свойств каталога можно установить нужную кодировку, например UTF-8.

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

Обработка исключительных ситуаций

2011-11-05T17:49:00.000+04:00

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

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

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

<?php 
class Customer
{
    public function closeAccount()
    {
        if (!empty($this->uncompletePayments))
        {
            throw new Exception("Cannot close customer account with uncomplete payments");
        }
        
        $this->accountClosed = true;
    }
}
?>

<?php 
if (!$customer->canClose())
{
    $this->handleCloseError();
} else
{
    $customer->closeAccount();
    //do some other usual things
}
?>

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

В случае, если мы решили сделать исключительную ситуацию проверяемой (checked exception), то нам следует разместить вызов метода в блоке try.

<?php
class CustomerCloseException
    extends Exception
{
    
}

class Customer
{
    /**
     * Some description
     * 
     * @throws CustomerCloseException
     */
    public function closeAccount()
    {
        if (!empty($this->uncompletePayments))
        {
            throw new CustomerCloseException();
        }
        
        $this->accountClosed = true;
    }
}
?>

<?php
try
{
    $customet->closeAccount();
    //do some usual things
    
} catch (CustomerCloseException $e)
{
    $this->handleCloseError();
}
?>

Здесь необходимо явно сообщить о возможной исключительной ситуации в интерфейсе (в данном случае я это делаю с помощью тэга phpdoc @exception или @throws). Так вызывающий может понять, что ему следует ожидать.

Новое в PHPUnit 3.6

2011-11-01T22:14:00.000+04:00

Несколько дней назад вышла новая версия фреймворка для модульного тестирования PHPUnit 3.6. Попробуем разобраться, какие нововведения вошли в этот релиз.

Одно из нововведений - это возможность пользоваться методом returnSelf для mock-объектов. Ниже приведу пример, похожий на пример в документации:

<?php
class SomeClass
{
    public function doSomething()
    {
        //do something and return null
        return null;
    }
}

class ReturnSelfTest extends PHPUnit_Framework_TestCase
{
    public function testReturnSelfExample()
    {
        //GIVEN
        //create a stub for the SomeClass class
        $stub = $this->getMock('SomeClass');

        //configure the stub
        $stub->expects($this->any())
             ->method('doSomething')
             ->will($this->returnSelf());

        //WHEN
        $result = $stub->doSomething();

        //THEN
        $this->assertSame($stub, $result);
    }
}
?>

Другой новый метод для Mock-объектов называется returnValueMap. Метод позволяет указывать какое должно быть возвращаемое значение в зависимости от аргументов. Попробуем разобраться на примере:

<?php
class SomeClass
{
    public function doSomething()
    {
        //do something and return null
        return null;
    }
}

class ReturnValueMapTest extends PHPUnit_Framework_TestCase
{
    public function testReturnValueMapExample()
    {
        //GIVEN
        //create a stub for the SomeClass class
        $stub = $this->getMock('SomeClass');

        //create a map of arguments to return values.
        $map = array(
          array('Fry', 'Bender', 'ExampleResultFirst',),
          array('Lisa', 'Bart', 'Homer', 'ExampleResultSecond')
        );

        //configure the stub
        $stub->expects($this->any())
             ->method('doSomething')
             ->will($this->returnValueMap($map));

        //WHEN
        $resultFirst = $stub->doSomething('Fry', 'Bender');
        $resultSecond = $stub->doSomething('Lisa', 'Bart', 'Homer');

        //THEN
        //the provided arguments
        $this->assertEquals('ExampleResultFirst', $resultFirst);
        $this->assertEquals('ExampleResultSecond', $resultSecond);
    }
}
?>

Следующее нововведение - это директива @requires для анотации тестовых методов:

<?php
class RequiresTest extends PHPUnit_Framework_TestCase
{
    /**
     * @requires PHP 6.0
     */
    public function testRequiresExample()
    {
        //test something
    }
}
?>

Выполнение теста будет выглядеть таким образом:

phpunit -v

PHPUnit 3.6.0 by Sebastian Bergmann.

Configuration read from /home/username/application/tests/phpunit.xml

S

Time: 0 seconds, Memory: 4.25Mb

There was 1 skipped test:

1) ArticleTest::testRequiresExample
PHP 6.0 (or later) is required.

OK, but incomplete or skipped tests!
Tests: 1, Assertions: 0, Incomplete: 0, Skipped: 1.

Новое утверждение assertCount (и противоположное assertNotCount) для проверки количества элементов в массиве. И еще несколько нововведений коротко:

появилась возможность выводить результаты code coverage в текстовом виде;
еще одна новая анотация @testdox, очевидно, для генерации документации для выбранных методов;
режим strict, в котором тесты без утверждений считаются незавершенными;
и еще несколько опций запуска phpunit (узнать о них лучше всего из документации): coverage-php и printer.

Пользуясь случаем, поздравляю данный фреймворк, а точнее его создателей, со скорой круглой датой: первая версия PHPUnit вышла 27 ноября 2001 года, т.е. уже почти 10 лет назад!

Незаменимые инструменты: PHP_CodeSniffer, PHP Depend и PHPMD

2011-10-30T20:02:00.002+04:00

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

Сначала мы поговорим о PHP_CodeSniffer. Этот инструмент позволяет “понюхать” ваш код на дурные запахи. CodeSniffer незаменим, если вы хотите использовать такую инженерную практику, как code review. Не стоит самостоятельно проверять код на соблюдение принятого code style. Эту работу лучше сделает CodeSniffer. Запустить проверку можно таким способом:

phpcs --standard=PEAR application/classes

FILE: application/classes/legacy.class.php
------------------------------------------------------------------------
FOUND 4 ERROR(S) AND 1 WARNING(S) AFFECTING 5 LINE(S)
------------------------------------------------------------------------
  2 | ERROR   | Missing file doc comment
  3 | ERROR   | Missing class doc comment
  6 | ERROR   | Missing function doc comment
 11 | ERROR   | You must use "/**" style comments for a function comment
 14 | WARNING | Line exceeds 85 characters; contains 89 characters
------------------------------------------------------------------------

Time: 0 seconds, Memory: 3.25Mb

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

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

Итак, для начала, мы создадим свой стандарт кодирования, разместив свой каталог в иерархию PHP_CodeSniffer. В моем случае это такой путь: /usr/share/php/PHP/CodeSniffer/Standards/Example. Здесь мы должны разместить файл ruleset.xml со следующим содержанием. См. синтаксис файлов ruleset.

<?xml version="1.0"?>
<ruleset name="Example">
    <description>The Example coding standard.</description>
    <rule ref="PEAR" />
</ruleset>

Здесь мы позаимствовали все стандарты PEAR, а свой стандарт для проверки использования венгерской нотации для переменных мы поместим в файл Sniffs/NamingConventions/HungarianNotationSniff.php внутри нашего каталога Example. Так будет выглядеть примерное содержания для выбранной проверки:

<?php 
class Example_Sniffs_NamingConventions_HungarianNotationSniff
    extends PHP_CodeSniffer_Standards_AbstractVariableSniff
{
    
    private $_variablePrefixes = array(
        'b',    //bool
        'a',    //array
        'i',    //int
        's',    //string
        'f',    //float
        'o',    //object
        'm',    //mixed
    );
    
    private $_predefinedVariables = array(
        'this',
        'GLOBALS',
        '_SERVER',
        '_GET',
        '_POST',
        '...'    //something else
    );

    /**
     * Processes class member variables.
     *
     * @param PHP_CodeSniffer_File $phpcsFile The file being scanned.
     * @param int                  $stackPtr  The position of token.
     *
     * @return void
     */
    protected function processMemberVar(
        PHP_CodeSniffer_File $phpcsFile, 
        $stackPtr
    ) {
        $tokens = $phpcsFile->getTokens();

        $memberProps = $phpcsFile->getMemberProperties($stackPtr);
        if (empty($memberProps) === true) {
            return;
        }

        $memberName     = ltrim($tokens[$stackPtr]['content'], '$');
        $scope          = $memberProps['scope'];

        if (!$this->_isVariablePredefined($memberName) && 
            !$this->_isVariablePrefixed($memberName)
        ) {
            $error = 
                '%s member var "%s" must be prefixed with a type code';
            $data  = array(
                ucfirst($scope),
                $memberName,
            );
            $phpcsFile->addError(
                $error,
                $stackPtr,
                'MemberVarWithoutPrefix',
                $data
            );
        }
    }


    /**
     * Processes normal variables.
     *
     * @param PHP_CodeSniffer_File $phpcsFile The file being scanned.
     * @param int                  $stackPtr  The position of token.
     *
     * @return void
     */
    protected function processVariable(
        PHP_CodeSniffer_File $phpcsFile,
        $stackPtr
    ) {
        $tokens = $phpcsFile->getTokens();
        
        $variableName     = ltrim($tokens[$stackPtr]['content'], '$');
        
        if (!$this->_isVariablePredefined($variableName) && 
            !$this->_isVariablePrefixed($variableName)
        ) {
            $error = 
                'Variable "%s" must be prefixed with a type code';
            $data  = array(
                $variableName,
            );
            $phpcsFile->addError(
                $error,
                $stackPtr,
                'VariableWithoutPrefix',
                $data
            );
        }
    }

    /**
     * Processes variables in double quoted strings.
     */
    protected function processVariableInString($phpcsFile, $stackPtr)
    {
        //TODO process variables in string
        return;
    }
    
    /**
     * Check if variable is predefined
     * 
     * @param  string $variableName Variable name
     * @return bool
     */
    private function _isVariablePredefined($variableName)
    {
        return
            in_array($variableName, $this->_predefinedVariables);
    }
    
    /**
     * Check if variable is correctly prefixed
     * 
     * @param  string $variableName Variable name
     * @return bool
     */
    private function _isVariablePrefixed($variableName)
    {
        return 
            preg_match(
                '/^_?[' . implode($this->_variablePrefixes). '][A-Z]/',
                $variableName
            );
    }
}
?>

Теперь попробуем что-нибудь проверить. Для этого у меня есть тестовый файл example.class.php с таким содержимом (обратите внимание, что тестовый файл не содержит никаких нарушений стандартов кодирования от PEAR):

<?php
/**
 * Example file for PHP_CodeSniffer
 * 
 * PHP version 5 
 * 
 * @category Example_File
 * @package  Example_File
 * @author   Eugene Khamukhin <khamukhin@gmail.com>
 * @license  Some free licence
 * @link     http://blog.yetanother.ru/
 */

/**
 * Example class for PHP_CodeSniffer
 * 
 * @category Example_Class
 * @package  Example_Class
 * @author   Eugene Khamukhin <khamukhin@gmail.com>
 * @license  Some free licence
 * @link     http://blog.yetanother.ru/
 */
class Example
{
    private $_cargo;
    
    /**
     * Set cargo for space ship
     * 
     * @param ExampleCargo $cargo Cargo to deliver
     * 
     * @return null
     */
    public function setCargo($cargo)
    {
        $this->_cargo = $cargo;
    }
    
    /**
     * Deliver cargo via Planet Express
     * 
     * @return ExampleCargo
     */
    public function diliver()
    {
        //do some work
    }
}
?>

Запускаем проверку на дурные запахи и изучаем результат:

phpcs --standard=Example example.class.php 

FILE: /home/khamukhin/phpcs/example.class.php
------------------------------------------------------------------------
FOUND 3 ERROR(S) AFFECTING 3 LINE(S)
------------------------------------------------------------------------
 25 | ERROR | Private member variable "_cargo" must be prefixed
 34 | ERROR | Variable "cargo" must be prefixed with a type code
 36 | ERROR | Variable "cargo" must be prefixed with a type code
------------------------------------------------------------------------

Time: 1 second, Memory: 3.50Mb

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

Использование PHP Depend более актуально в контексте сервера непрерывной интеграции. Например, вот так будет выглядеть запуск PHP Depend в скрипте сборки для Phing:

<!-- ============================================ -->
<!-- Target: run.phpdepend                        -->
<!-- ============================================ -->
<target name="run.phpdepend">
    <phpdepend>
        <fileset dir="${build.dir}/application/classes">
            <include name="**/*.php" />
        </fileset>
        <logger type="jdepend-xml"
            outfile="${build.dir}/build/jdepend.xml" />
        <logger type="jdepend-chart"
            outfile="${build.dir}/build/pdepend/dependencies.svg" />
        <logger type="overview-pyramid"
            outfile="${build.dir}/build/pdepend/overview-pyramid.svg" />
        <analyzer type="coderank-mode" value="method" />
    </phpdepend>
</target>

Последний инструмент, который будет рассмотрен в данной статье, это PHPMD - Mess Detector. Данная утилита позволяет проверить исходный код на потенциальные проблемы, не очень оптимальные участки кода, неиспользуемые параметры, методы и т.д. Вот как может выглядеть запуск phpmd:

phpmd classes text codesize,unusedcode,naming

classes/legacy.class.php:3 This class has too many methods, 
                                consider refactoring it.

classes/legacy.class.php:3 The class Legacy has an overall 
                                complexity of 68 which is very high. 
                                The configured complexity threshold is 50.
...

Для этой утилиты также можно настраивать свои правила, а как это сделать можно найти в документации. Для code review данный инструмент также, как и PHP_CodeSniffer является просто незаменимым.

На этом серия постов про полезные инструменты не завершается, продолжение следует!

Незаменимые инструменты: phploc и phpcpd

2011-10-28T08:07:00.000+04:00

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

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

Phploc;
Phpcpd.

Обе утилиты предлагает использовать известный и уважаемый разработчик Sebastian Bergmann, что уже является неплохой рекомендацией. Phploc и Phpcpd особенно актуальны для использования на сервере непрерывной интеграции, но и не будут лишними, находясь под рукой разработчика.

Начнем с Phploc. Эта утилита позволяет померить PHP проект, т.е. это такая своеобразная линейка, lines of code. Опций у phploc совсем мало: помимо указания каталога или файла и других не очень важных параметров, можно установить путь до лог-файла, в который phploc запишет результат измерений в XML или CSV.

Запускаем phploc:

phploc --log-csv reports/phploc.csv application/classes 

phploc 1.6.1 by Sebastian Bergmann.

Lines of Code (LOC):                               2992
  Cyclomatic Complexity / Lines of Code:           0.10
Comment Lines of Code (CLOC):                       587
Non-Comment Lines of Code (NCLOC):                 2405

Namespaces:                                           0
Interfaces:                                           0
Classes:                                              1
  Abstract:                                           0 (0.00%)
  Concrete:                                           1 (100.00%)
  Average Class Length (NCLOC):                    2660
Methods:                                             62
  Scope:
    Non-Static:                                      62 (100.00%)
    Static:                                           0 (0.00%)
  Visibility:
    Public:                                          27 (43.55%)
    Non-Public:                                      35 (56.45%)
  Average Method Length (NCLOC):                     42
  Cyclomatic Complexity / Number of Methods:       4.94

Anonymous Functions:                                  0
Functions:                                            0

Constants:                                            5
  Global constants:                                   0
  Class constants:                                    5

Два показателя (Cyclomatic Complexity / Lines of Code и Cyclomatic Complexity / Number of Methods) используют такую характеристику кода, как Цикломатическая сложность. Этот показатель характеризует число ветвей в коде и вычисляется путем подсчета операторов цикла, условного перехода и переключений. Цикломатическая сложность была разработана еще в 1976 году, а ее автор Томас Дж. Мак-Кейб предлагал заставлять разработчиков разбивать код на более простые участки, если сложность модуля превышает значение 10.

Вторая утилита, о которой будет рассказано в данном посте - это Phpcpd, детектор “копипаста”. Пожалуй, никто не будет спорить, что копипаст дурно пахнет и почти наверняка приведет к ошибкам в приложении, которые проявятся рано или поздно. Утилита phploc ищет такие дурные, повторяющиеся места в коде.

phpcpd --min-tokens 50 --verbose lib

phpcpd 1.3.2 by Sebastian Bergmann.

Processing files
49 / 49 [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>] 100.00%

Found 3 exact clones with 66 duplicated lines in 4 files:

  - foo.class.php:241-252
    foo.class.php:285-296

  - copy.class.php:12-22
    paste.class.php:20-30

  - boo.class.php:833-848
    foo.class.php:391-406

0.25% duplicated lines out of 26439 total lines of code.

Time: 3 seconds, Memory: 24.25Mb

Параметры min-lines и min-tokens позволяют повышать или понижать планку того, что считать Copy/Paste. Опцией log-pmd результаты можно сохранить в формате PMD-CPD XML.

На этом пока все, продолжение следует. Делитесь в комментариях своими тулзами, которые помогают вам!

Переходим на непрерывную интеграцию с Jenkins

2011-10-26T01:29:00.000+04:00

В предыдущей статье мы подключили проект к серверу постоянной интеграции phpUnderControl. На этом мы не остановимся и теперь попробуем другой сервер непрерывной интеграции — Jenkins (ранее назывался Hudson).

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

Зачем использовать именно Jenkins? Его стоит использовать, потому что это превосходный проект, у которого есть огромное количество дополнений, его легко устанавливать и настраивать. Кроме того, для Jenkins существует мини-проект php-jenkins-template от Sebastian Bergmann (создатель PHPUnit и не только), который позволяет достаточно легко подключать PHP проекты. Да что долго говорить, лучше один раз попробовать!

Приступаем к установке. Установить Jenkins достаточно легко, например для Ubuntu нужно выполнить такие команды:

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | \
sudo apt-key add -

sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > \
/etc/apt/sources.list.d/jenkins.list'

sudo aptitude update
sudo aptitude install jenkins

Теперь можно приступить к установке php-jenkins-template. Подробное руководство по установке представлено на странице проекта, здесь же я отмечу только наиболее важные моменты.

Установить необходимые плагины (для PHP нужно установить checkstyle, cloverphp, dry, htmlpublisher, jdepend, plot, pmd, violations, xunit) можно как через терминал, так и через веб-интерфейс. Кстати, вероятно для многих главным различием между CruiseControl и Jenkins будет то, что для конфигурации первого необходимо работать преимущественно с командной строкой, а для Jenkins — в графическом интерфейсе. Прежде чем, начать установку плагинов, нужно обновить в Jenkins список доступных дополнений. Обновить этот список можно на странице: http://hostname:8080/pluginManager/advanced.

Следующим важным шагов будет установка самого шаблона для PHP проекта. Это можно сделать такими командами:

cd $JENKINS_HOME/jobs
git clone git://github.com/sebastianbergmann/php-jenkins-template.git php-template
chown -R jenkins:nogroup php-template/

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

Для сборки проекта в этом примере мы будем использовать Phing (соответствующий плагин для Jenkins нужно также установить). За основу build-скприта проекта мы будем использовать файл, который уже рассматривался в статье про phpUnderControl и Phing. Но здесь мы добавим еще несколько задач: code.browser, run.phploc, run.phpdepend.

<?xml version="1.0" encoding="UTF-8"?>
<project name="Example" default="default">
    <property name="build.dir" value="." />

    <!-- ============================================ -->
    <!-- (DEFAULT) Target: default                    -->
    <!-- ============================================ -->
    <target name="default"
        depends="lint.legacy, run.tests.legacy, run.coverage, run.mess.detector, run.copypast.detector, run.phpcodesniffer, api.docs, code.browser, run.phploc, run.phpdepend">
        <echo msg="All done." />
    </target>

    <!-- ============================================ -->
    <!-- Target: api.docs                             -->
    <!-- ============================================ -->
    <target name="api.docs">
        <docblox title="API Documentation" destdir="${build.dir}/public/apidocs/"
            quiet="true">
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
        </docblox>
    </target>

    <!-- ============================================ -->
    <!-- Target: code.browser                         -->
    <!-- ============================================ -->
    <target name="code.browser">
        <exec
            command="phpcb --source ${build.dir}/classes --output ${build.dir}/public/code-browser"
            dir="${build.dir}" />
    </target>

    <!-- ============================================ -->
    <!-- Target: lint.legacy                          -->
    <!-- ============================================ -->
    <target name="lint.legacy">
        <phplint>
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
        </phplint>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.tests.legacy                     -->
    <!-- ============================================ -->
    <target name="run.tests.legacy">
        <coverage-setup database="${build.dir}/build/coverage.db">
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
        </coverage-setup>
        <phpunit haltonfailure="true" haltonerror="true"
            codecoverage="true">
            <formatter type="xml" usefile="true"
                todir="${build.dir}/build/phpunit" />
            <formatter type="clover" usefile="true"
                todir="${build.dir}/build/phpunit" />
            <formatter type="plain" usefile="false" />
            <batchtest>
                <fileset
                    dir="${build.dir}/tests">
                    <include name="*Test.php" />
                </fileset>
            </batchtest>
        </phpunit>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.coverage                         -->
    <!-- ============================================ -->
    <target name="run.coverage" depends="run.tests.legacy">
        <coverage-report outfile="${build.dir}/build/coverage.xml">
            <report todir="${build.dir}/build/coverage"
                styledir="/usr/share/php/data/phing/etc" />
        </coverage-report>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.mess.detector                    -->
    <!-- ============================================ -->
    <target name="run.mess.detector">
        <phpmd>
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
            <formatter type="xml"
                outfile="${build.dir}/build/phpmd.xml" />
            <formatter usefile="false" type="text" />
        </phpmd>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.copypast.detector                -->
    <!-- ============================================ -->
    <target name="run.copypast.detector">
        <phpcpd>
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
            <formatter type="pmd"
                outfile="${build.dir}/build/phpcpd.xml" />
            <formatter usefile="false" type="default" />
        </phpcpd>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.phpcodesniffer                   -->
    <!-- ============================================ -->
    <target name="run.phpcodesniffer">
        <phpcodesniffer standard="Zend" showSniffs="true"
            showWarnings="true">
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
            <formatter type="checkstyle"
                outfile="${build.dir}/build/phpcodesniffer.xml" />
            <formatter type="summary" usefile="false" />
        </phpcodesniffer>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.phploc                           -->
    <!-- ============================================ -->
    <target name="run.phploc">
        <exec
            command="phploc --log-csv ${build.dir}/build/phploc.csv ${build.dir}/classes"
            dir="${build.dir}" />
    </target>

    <!-- ============================================ -->
    <!-- Target: run.phpdepend                        -->
    <!-- ============================================ -->
    <target name="run.phpdepend">
        <phpdepend>
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
            <logger type="jdepend-xml"
                outfile="${build.dir}/build/jdepend.xml" />
            <analyzer type="coderank-mode" value="method" />
        </phpdepend>
    </target>
</project>

Можно запустить сборку проекта вручную и, если все хорошо, смело включать проект в Jankins. За сборкой проекта в этом сервере непрерывной интеграции можно очень удобно следить:

В заключении я бы хотел поделиться своими субъективными наблюдениями:

в Jankins довольно удобно настраивать проект, а некорректная конфигурация одного проекта не сломает другие проекты в отличии от CruiseControl;
поражает количество плагинов, доступных для установки (например, с помощью некоторых плагинов можно отправлять сообщения о неудачных билдах в Jabber или Twitter);
интерфейс более объемный (больше разнообразных станиц для каждой сборки), чем в phpUnderControl;
если вы используете phpUnderControl, то как минимум посмотреть на Jenkins вы просто обязаны :)

Удачных экспериментов с непрерывной интеграцией и благодарю за внимание!

Подключаем PHP проект к серверу непрерывной интеграции

2011-10-25T00:03:00.000+04:00

В прошлый раз мы обсуждали автоматизацию build проекта с использованием Phing. В этом посте тема будет продолжена: настало время подключить наш проект к серверу Continuous Integration.

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

Если это первый проект, который вы подключаете к серверу непрерывной интеграции, то скорее всего стоит использовать CruiseControl с установленным дополнением phpUnderControl. Для PHP-проектов такая конфигурация является (или покрайней мере являлась) своеобразном стандартом.

Переходим от слов к делу. Нам понадобится один сервер, свежие версии CruiseControl и phpUnderControl, Subversion (в нашем примере будет использована эта система контроля версий), пакеты sun-java6-jre, sun-java6-jdk. Кроме того далее будут упоминаться различные утилиты, которые также потребуется установить на сервере CI.

Начнем с установки CruiseControl:

unzip cruisecontrol-bin-2.8.4.zip -d /opt 
ln -s /opt/cruisecontrol-bin-2.8.4 /opt/cruisecontrol

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

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
. /lib/lsb/init-functions
JAVA_HOME=/usr
NAME=cruisecontrol
DAEMON=/opt/cruisecontrol/cruisecontrol.sh
PIDFILE=/opt/cruisecontrol/cc.pid
 
test -x $DAEMON || exit 5
 
RUNASUSER=cruisecontrol
UGID=$(getent passwd $RUNASUSER | cut -f 3,4 -d:) || true
 
case $1 in
  start)
    log_daemon_msg "Starting Cruisecontrol server" "cc"
    if [ -z "$UGID" ]; then
        log_failure_msg "user \"$RUNASUSER\" does not exist"
        exit 1
    fi
    cd /opt/cruisecontrol/
    ./cruisecontrol.sh > /dev/null 2>&1
    log_end_msg $?
    ;;
  stop)
    log_daemon_msg "Stopping Cruisecontrol server" "cc"
    start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
    log_end_msg $?
    rm -f $PIDFILE
    ;;
  restart|force-reload)
    $0 stop && sleep 2 && $0 start
    ;;
  status)
    pidofproc -p $PIDFILE $DAEMON >/dev/null
    status=$?
    if [ $status -eq 0 ]; then
        log_success_msg "Cruisecontrol server is running."
    else
        log_failure_msg "Cruisecontrol server is not running."
    fi
    exit $status
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|force-reload|status}"
    exit 2
    ;;
esac

Этот скрипт нужно поместить в /etc/init.d/cruisecontrol и установить права на исполнение. Нужно также обратить внимание на пользователя RUNASUSER=cruisecontrol.

Приступаем к установке phpUnderControl, и здесь все сводится к выполнению нескольких команд:

pear channel-discover components.ez.no
pear channel-discover pear.phpundercontrol.org
pear install --alldeps phpuc/phpUnderControl-beta
/usr/bin/phpuc install /opt/cruisecontrol

Проверим, что наш сервер постоянной интеграции запускается, запускаем его /etc/init.d/cruisecontrol start и смотрим в браузере http://localhost:8080/cruisecontrol/.

Теперь займемся конфигурацией самого проекта. У CruiseControl конфигурация всех проектов хранится в одном файле config.xml. Установим наш проект:

<cruisecontrol>
    <project name="Example" buildafterfailed="false">

        <plugin name="svnbootstrapper"
            classname="net.sourceforge.cruisecontrol.bootstrappers.SVNBootstrapper" />
        <plugin name="svn" classname="net.sourceforge.cruisecontrol.sourcecontrols.SVN" />
        <plugin name="phing"
            classname="net.sourceforge.cruisecontrol.builders.PhingBuilder" />

        <listeners>
            <currentbuildstatuslistener file="logs/${project.name}/status.txt" />
        </listeners>

        <bootstrappers>
            <svnbootstrapper localWorkingCopy="projects/${project.name}/source/" />
        </bootstrappers>

        <modificationset quietperiod="0">
            <svn localWorkingCopy="projects/${project.name}/source/" />
        </modificationset>

        <schedule interval="120">
            <phing buildfile="projects/${project.name}/source/build-development.xml"
                uselogger="true" usedebug="false" />
        </schedule>

        <log dir="logs/${project.name}">
            <merge dir="projects/${project.name}/source/" />
        </log>

        <publishers>
            <artifactspublisher dir="projects/${project.name}/build/coverage"
                dest="logs/${project.name}" subdirectory="coverage" />
            <artifactspublisher dir="projects/${project.name}/public/apidocs"
                dest="logs/${project.name}" subdirectory="api" />

            <execute command="/usr/bin/phpuc graph logs/${project.name}" />
            <htmlemail mailhost="xx.xx.xx.xx" returnaddress="noreply@example.com"
                buildresultsurl="http://localhost:8080/buildresults/${project.name}"
                returnname="phpUnderControl server" logdir="logs/${project.name}">

                <failure address="fail@example.com" reportWhenFixed="true" />
            </htmlemail>
        </publishers>

    </project>
</cruisecontrol>

Обращу внимание на самое главное, исходных код будет располагаться в projects/example/source. Здесь же мы должны самостоятельно выполнить checkout проекта. Директивами svn, svnbootstrapper мы указываем, чтобы CruiseControl выполнял в каталоге с исходным кодом svn up. По мере появления новых изменений (в данном случае из центрального svn-репозитория) будет запущен процесс сборки проекта. Для сборки мы используем Phing и скрипт похожий на тот, который обсуждали в прошлом посте. Секция publishers помимо прочего содержит настройки для отправки уведомлений в случае неудачного билда.

Теперь стоит взглянуть на сам build-скрипт. Мы немного его дополним: добавим задачу по запуску проверки кода на «дурные запахи», поиск дублирования кода, и т.д.

<?xml version="1.0" encoding="UTF-8"?>
<project name="Example" default="default">
    <property name="build.dir" value="." />

    <!-- ============================================ -->
    <!-- (DEFAULT) Target: default                    -->
    <!-- ============================================ -->
    <target name="default"
        depends="run.tests, run.mess.detector, run.copypast.detector, run.phpcodesniffer, api.docs">
        <echo msg="All done." />
    </target>

    <!-- ============================================ -->
    <!-- Target: api.docs                             -->
    <!-- ============================================ -->
    <target name="api.docs">
        <phpdoc title="API Documentation" destdir="${build.dir}/public/apidocs"
            sourcecode="false" templatebase="/usr/share/php/data/phpUnderControl/data/phpdoc"
            output="HTML:Phpuc:phpuc">
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
        </phpdoc>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.tests                            -->
    <!-- ============================================ -->
    <target name="run.tests">
        <phpunit haltonfailure="true" haltonerror="true">
            <formatter type="xml" usefile="true"
                todir="${build.dir}/build/phpunit" />
            <formatter type="plain" usefile="false" />
            <batchtest>
                <fileset dir="${build.dir}/tests">
                    <include name="*Test.php" />
                </fileset>
            </batchtest>
        </phpunit>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.mess.detector                    -->
    <!-- ============================================ -->
    <target name="run.mess.detector">
        <phpmd>
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
            <formatter type="xml"
                outfile="${build.dir}/build/phpmd/phpmd.xml" />
            <formatter usefile="false" type="text" />
        </phpmd>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.copypast.detector                -->
    <!-- ============================================ -->
    <target name="run.copypast.detector">
        <phpcpd>
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
            <formatter type="pmd"
                outfile="${build.dir}/build/phpcpd/phpcpd.xml" />
            <formatter usefile="false" type="default" />
        </phpcpd>
    </target>

    <!-- ============================================ -->
    <!-- Target: run.phpcodesniffer                   -->
    <!-- ============================================ -->
    <target name="run.phpcodesniffer">
        <phpcodesniffer standard="Zend" showSniffs="true"
            showWarnings="true">
            <fileset dir="${build.dir}/classes">
                <include name="**/*.php" />
            </fileset>
            <formatter type="checkstyle"
                outfile="${build.dir}/build/phpcodesniffer/phpcodesniffer.xml" />
            <formatter type="summary" usefile="false" />
        </phpcodesniffer>
    </target>
</project>

Этот скрипт мы можем проверить, запустив самостоятельно phing -f build-development.xml. Конечно, чтобы все это работало, нужно установить phpdoc, phpcs, phpunit и xdebug.

Теперь можно выполнить несколько тестовых коммитов и понаблюдать за статистикой новых build'ов. Можно даже что-то специально сломать, чтобы проверить, как сервер непрерывной интеграции сообщит о проблеме.

Автоматизируем build для PHP-проекта с помощью Phing

2011-10-19T15:04:00.000+04:00

Традиционно с процессом build связывают такие действия, как компиляция, линковка, в итоге представление в исполняемый код. Для PHP и других скриптовых языков во всем этом нет необходимости, однако, build проекта на PHP довольно частая задача. С чем это связано? Прежде всего в понятие build веб-проектов сейчас вкладывают, помимо задач вроде компиляции, такие активности, как:

Тестирование;
Проведение необходимых изменений в БД;
Анализ исходного кода;
Генерация документации;
Минимизация;
Какие-то другие специфические для проекта задачи, которые можно выполнять автоматизированно.

Для PHP-проекта фактическим стандартом для задач build'а является приложение Phing, очень похожее своим подходом на Ant для Java. Подробно изучить Phing можно с помощью документации на официальном сайте, а также будет полезна вот эта развернутая статья (кстати не только про Phing). В этом же посте я расскажу, что Phing довольно стабильно развивается с релизом примерно раз в три месяца, в заключении приведу пример build-скрипта.

Итак начнем с установки (возможностей у Phing'а много, для некоторых типов задач понадобится установить дополнительные библиотеки):

pear channel-discover pear.phing.info
pear install phing/phing

Теперь создадим простой build-скрипт build.xml в корне проекта.

<?xml version="1.0" encoding="UTF-8"?>
<project name="Phing example" default="default">
    <property name="build.dir" value="." />

    <!-- ============================================ -->
    <!-- (DEFAULT) Target: default                    -->
    <!-- ============================================ -->
    <target name="default" depends="run.speech.engine">
        <echo msg="Hello world!" />
    </target>

    <!-- ============================================ -->
    <!-- Target: run.speech.engine                    -->
    <!-- ============================================ -->
    <target name="run.speech.engine">
        <echo msg="I can speak now!" />
    </target>
</project>

Выполнив команду

phing (можно также запускать phing -f build.xml для указания имени запускаемого скрипта) мы получим такой вывод:
Buildfile: /home/username/build-example/build.xml

Phing example > run.speech.engine:

     [echo] I can speak now!

Phing example > default:

     [echo] Hello world!

BUILD FINISHED

Total time: 0.1666 seconds

Одной из интересных практик для написания build-скриптов является создание несколько разных файлов для разных сред. Например: build-dev.xml, build-stage.xml, build-production.xml. Это действительно имеет смысл, т.к. задачи для каждой среды исполнения разные. Дальше мы попробуем написать два скрипта: build-dev.xml и build-production.xml.

Первый скрипт для среды разработки будет решать задачи проверки кода, запуска тестов и генерации документации. Начнем с проверки кода на синтаксические ошибки, для этого нужно использовать тип задач PhpLintTask:
<?xml version="1.0" encoding="UTF-8"?>
<project name="Phing example" default="default">
    <property name="build.dir" value="." />

    <!-- ============================================ -->
    <!-- (DEFAULT) Target: default                    -->
    <!-- ============================================ -->
    <target name="default" depends="lint.legacy">
        <echo msg="All done." />
    </target>

    <!-- ============================================ -->
    <!-- Target: lint.legacy                          -->
    <!-- ============================================ -->
    <target name="lint.legacy">
        <phplint>
            <fileset dir="${build.dir}/application/lib">
                <include name="**/*.php" />
            </fileset>
        </phplint>
    </target>
</project>
После запуска вывод будет примерно таким: 
Buildfile: /home/username/build-example/build-dev.xml

Phing example > lint.legacy:

  [phplint] ./application/lib/auth.class.php: No syntax errors detected
  [phplint] ./application/lib/session.class.php: No syntax errors detected
  [phplint] ./application/lib/video.class.php: No syntax errors detected

Phing example > default:

     [echo] All done.

BUILD FINISHED

Total time: 2.3877 seconds

Переходим к запуску тестов, и здесь можно использовать задачи PHPUnitTask или SimpleTestTask в зависимости от используемого фреймворка для тестирования.
<?xml version="1.0" encoding="UTF-8"?>
<project name="Phing example" default="default">
    <property name="build.dir" value="." />

    <!-- ============================================ -->
    <!-- (DEFAULT) Target: default                    -->
    <!-- ============================================ -->
    <target name="default" depends="lint.legacy, run.tests">
        <echo msg="All done." />
    </target>

    <!-- ============================================ -->
    <!-- Target: lint.legacy                          -->
    <!-- ============================================ -->
    <target name="lint.legacy">
        <phplint>
            <fileset dir="${build.dir}/application/lib">
                <include name="**/*.php" />
            </fileset>
        </phplint>
    </target>
    
    <!-- ============================================ -->
    <!-- Target: run.tests                            -->
    <!-- ============================================ -->
    <target name="run.tests">
        <phpunit haltonfailure="true" haltonerror="true">
            <formatter type="plain" usefile="false" />
            <batchtest>
                <fileset dir="${build.dir}/application/tests">
                    <include name="*Test.php" />
                </fileset>
            </batchtest>
        </phpunit>
    </target>
</project>
Последнее, что мы решили делать, это получать документацию API исходного кода. Для этого я рекомендую использовать задачу DocBloxTask.
<?xml version="1.0" encoding="UTF-8"?>
<project name="Phing example" default="default">
    <property name="build.dir" value="." />

    <!-- ============================================ -->
    <!-- (DEFAULT) Target: default                    -->
    <!-- ============================================ -->
    <target name="default" depends="lint.legacy, run.tests, api.docs">
        <echo msg="All done." />
    </target>

    <!-- ============================================ -->
    <!-- Target: lint.legacy                          -->
    <!-- ============================================ -->
    <target name="lint.legacy">
        <phplint>
            <fileset dir="${build.dir}/application/lib">
                <include name="**/*.php" />
            </fileset>
        </phplint>
    </target>
    
    <!-- ============================================ -->
    <!-- Target: run.tests                            -->
    <!-- ============================================ -->
    <target name="run.tests">
        <phpunit haltonfailure="true" haltonerror="true">
            <formatter type="plain" usefile="false" />
            <batchtest>
                <fileset dir="${build.dir}/application/tests">
                    <include name="*Test.php" />
                </fileset>
            </batchtest>
        </phpunit>
    </target>
    
    <!-- ============================================ -->
    <!-- Target: api.docs -->
    <!-- ============================================ -->
    <target name="api.docs">
        <docblox title="API Docs" destdir="${build.dir}/public/apidocs"
            quiet="true">
            <fileset dir="${build.dir}/application/lib">
                <include name="**/*.php" />
            </fileset>
        </docblox>
    </target>
</project>
В итоге при запуске phing -f build-dev.xml у нас получается такой вывод:
Buildfile: /home/username/build-example/build-dev.xml

Phing example > lint.legacy:
  ...

Phing example > run.tests.legacy:
  ...

Phing example > api.docs:
  ...

Phing example > default:

     [echo] All done.

BUILD FINISHED

Total time: 26.5158 seconds

Переходим к build-production.xml. Здесь задачи уже другие, нам более интересно минимизировать некоторые файлы (css, js) и объединить небольшие файлы одного типа. У нас получится примерно такой build-скрипт:
<?xml version="1.0" encoding="UTF-8"?>
<project name="Phing example" default="default">
    <property name="build.dir" value="./public" />

    <!-- ============================================ -->
    <!-- (DEFAULT) Target: default                    -->
    <!-- ============================================ -->
    <target name="default"
        depends="minify.css.all, minify.js.all, concatenate.css, concatenate.js">
        <echo msg="All done." />
    </target>

    <!-- ============================================ -->
    <!-- Target: minify.css.all                       -->
    <!-- ============================================ -->
    <target name="minify.css.all">
        <echo msg="Compressing CSS with YUI Compressor" />
        <fileset dir="${build.dir}/css" id="fileset.css">
            <include name="global.css" />
            <include name="blocks.css" />
        </fileset>
        <foreach param="filename" absparam="absfilename" target="minify">
            <fileset refid="fileset.css" />
        </foreach>
        <move todir="${build.dir}/css" overwrite="true">
            <mapper type="glob" from="*.css" to="*.min.css" />
            <fileset refid="fileset.css" />
        </move>
    </target>

    <!-- ============================================ -->
    <!-- Target: minify.js.all                        -->
    <!-- ============================================ -->
    <target name="minify.js.all">
        <echo msg="Compressing JS with YUI Compressor" />
        <fileset dir="${build.dir}/js" id="fileset.js">
            <include name="global.js" />
        </fileset>
        <foreach param="filename" absparam="absfilename" target="minify">
            <fileset refid="fileset.js" />
        </foreach>
        <move todir="${build.dir}/js" overwrite="true">
            <mapper type="glob" from="*.js" to="*.min.js" />
            <fileset refid="fileset.js" />
        </move>
    </target>

    <!-- ============================================ -->
    <!-- Target: minify                               -->
    <!-- ============================================ -->
    <target name="minify">
        <echo msg="Minimizing: ${filename}" />
        <exec command="java -jar yuicompressor.jar ${absfilename} -o ${absfilename}" />
    </target>

    <!-- ============================================ -->
    <!-- Target: concatenate.css                      -->
    <!-- ============================================ -->
    <target name="concatenate.css" depends="minify.css.all">
        <echo msg="Concatenating CSS" />
        <delete file="${build.dir}/css/all.min.css" />
        <append destFile="${build.dir}/css/all.min.css">
            <fileset dir="${build.dir}/css">
                <include name="global.min.css" />
                <include name="blocks.min.css" />
            </fileset>
        </append>
    </target>

    <!-- ============================================ -->
    <!-- Target: concatenate.js                       -->
    <!-- ============================================ -->
    <target name="concatenate.js" depends="minify.js.all">
        <echo msg="Concatenating JS" />
        <delete file="${build.dir}/js/all.min.js" />
        <append destFile="${build.dir}/js/all.min.js">
            <fileset dir="${build.dir}/js">
                <include name="global.min.js" />
                <include name="gallery.min.js" />
            </fileset>
        </append>
    </target>
</project>
Здесь для минимизации мы использовать YUI compressor, а для объединения файлов — директиву append. Вывод будет примерно таким:
Buildfile: /home/username/build-example/build-dev.xml

Phing example > minify.css.all:

     [echo] Compressing CSS with YUI Compressor

Phing example > minify.js.all:

     [echo] Compressing JS with YUI Compressor

Phing example > concatenate.css:

     [echo] Concatenating CSS
     ...

Phing example > concatenate.js:

     [echo] Concatenating JS
     ...

Phing example > default:

     [echo] All done.

BUILD FINISHED

Total time: 3.3199 seconds

На этом пример build для PHP проекта можно считать завершенным. Спасибо за внимание, и делитесь, для чего вы используете build в ваших проектах!



Самые интересные выступления Highload++ 2011
2011-10-09T21:31:00.001+04:00
Сегодня я бы хотел рассказать о выступлениях на Highload++, которые мне запомнились и показались полезными.
Впервые в рунете: сказ о 100М писем в день / Андрей Сас (Badoo)
Андрей рассказывал о том, как в Badoo организована отправка многочисленных писем, как они следят за средним временем с момента постановки письма в очередь и до момента доставки. О чем Андрей категорически не стал рассказывать, так это о том, как они добиваются попадания письма именно во входящие, а не спам – NDA. Одной из интересных деталей архитектуры от Badoo является очередь, как я уже заметил. Более того, одна очередь существует для генерации самих писем, а другая очередь – для их отправки. В качестве движка очередей ребята выбрали… файловую систему, так как, по мнению Андрея, очень легко добавлять новое сообщение в очередь (создать файл), легко посмотреть сколько всего сообщений в очереди (сколько файлов)  и т.д. Если такое решение о файловой системе не дает вам покоя (почему сделан такой выбор), то можно отыскать почту Андрея и расспросить все у него.
Web-scale MySQL at Facebook / Domas Mituzas
Это выступление проходило на английском, но интересно, что Domas может даже немного говорить на русском и еще лучше понимает наш прекрасный язык. Выступление было обзорным, то есть никаких потрясающих вещей мы не услышали, нам просто рассказали какие патчи для MySQL написали в Facebook. Думаю, что всю эту информацию можно найти вот здесь: https://launchpad.net/mysqlatfacebook. Во время выступления я делал некоторые заметки, и вот кое-что: для лучшего масштабирования в Facebook используют свое творение Flashcache (прозрачное кэширование данных на дисках SSD); свои патчи ребята разрабатывают для MySQL 5.1, версию 5.5 они решили пропустить, а вот MySQL 5.6 не пропустят.
12 вариантов использования Redis — в Tarantool / Александр Календарев, Константин Осипов (Mail.ru)
Решардинг Redis "на живую" / Андрей Смирнов, Василий Евсеенко (Skype)
Два эти выступления мне показались интересным, несмотря на то, что с Redis я не работал. Здесь я просто рекомендую, если эта тема вам интересна, найти видеозаписи этих докладом или как минимум слайды, они должны быть адекватными и полезными.
Pconnect: граната в руках обезьяны / Сергей Аверин (Badoo)
В течение 45 минут Сергей пытался напугать публику постоянными подключениями к БД, что у него скорее всего получилось. На самом деле, Сергей разложил по полочкам на что обязательно нужно обращать внимание перед тем, как начать использовать pconnect, например для MySQL. Здесь, мне кажется, слайды должны быть не менее полезными, чем видео.
Низкоуровневая оптимизация C/C++ / Андрей Аксенов (Sphinx)
Поймал себя на мысли, что я перестал обращать внимание на тему выступлений Андрея Аксенова, а мне достаточно увидеть только имя, чтобы решить пойти на его доклад. Такая вот у него особенная стилистика выступлений. Что же касается темы, то она должна быть интересна тем, кто имеет дело с C/C++: сначала были общие интересные принципы (было показано на примерах, как последовательное чтение из оперативной памяти отличается от не совсем последовательного), а затем пошла специфика, вплоть до того сколько микро-нано-секунд можно выиграть от замены оператора switch на несколько if.
Новое в MySQL 5.5, 5.6 и Percona Server для высоких нагрузок / Петр Зайцев (Percona)
Петр Зайцев очень уважаемый человек в мире MySQL, слушать его интересно, но увы, это выступление было полностью обзорным. Петр рассказал о нововведениях в версиях 5.5 и будущей версии 5.6. И то и другое можно без труда найти на mysql.com. У меня сложилось впечатление, что нет смысла чего-то ожидать от получасового выступления Петра, на какой бы конференции оно не состоялось – лучше рассмотреть возможность участия в мастер-классах.
Архитектура хранилища бинарных данных на Одноклассниках / Александр Христофоров, Олег Анастасьев (Одноклассники)
Ребята из Одноклассников рассказали, какие изменения они проделали для более оптимального хранения изображений, загруженных пользователями. Видео этого выступления должно быть полезным хотя бы для того, чтобы изучить какие вообще решения этой задачи выбирают разные команды. У меня не получится рассказать полностью идею Одноклассников, но вот некоторые интересные особенности: каждые данные дублируются на трех жестких дисках, а бэкапы создаются не для самих данных, а для индексов (что на этом диске есть); все данные (все изображения) на одном диске записываются в один файл; неважно на каком сервере установлен диск, если его подключить к другому серверу, то данные с этого диска будут работать.
Это было последнее выступление, о котором я хотел бы рассказать. Кстати, именно такого типа выступлений (как наша команда решила архитектурную задачу) я ждал от этой конференции, но их было чрезвычайно мало. Тем не менее, наверняка на Highload были и другие интересные доклады, которые я не смог послушать или просто пропустил, об этом наверняка поделились другие участники конференции.
Спасибо за внимание!



Немного о работе
2011-08-29T22:31:00.001+04:00
Сегодня я бы хотел рассказать читателям о своей новой работе. На работе многие из нас проводят огромную часть своего времени, и поэтому почему бы этим не поделиться, рассказать над чем сейчас работаешь, и что будет впереди.

Итак, уже полгода я работаю ведущим разработчиком в объединенной компании «Афиши» и «Рамблера». Сейчас это две компании, которые уже примерно год пробуют работать совместно. 

В объединенной компании я занимаюсь проектом Nightparty. Этот проект был запущен еще в 2003 году и сейчас является одним из самых популярных проектов о клубной культуре, вечеринках, музыке и людях, которые ко всему этому причастны. Тематика проекта мне очень нравится и близка. Редакция Nightparty — весьма молодая и состоит из очень креативных людей.  

С 2003 года проект не один раз менял, как технически, так и визуально. Вот так выглядел логотип Nightparty в прошлом :)


А вот более современное изображение проекта (плакат с прошлогоднего Казантипа):


Nightparty работает, что не удивительно на PHP, используется Zend Framework. Код проекта выполняется на нескольких application-серверах, между которыми балансируется нагрузка. Для СУБД используется MySQL 5.1. 

Одной из самых востребованных фитч проекта являются фотоотчеты — выполненные профессионалами фотографии с интересных событий и вечеринок. Для работы фотоотчетов организовано несколько серверов-хранилищ.

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

Мои коллеги-разработчики здесь работают на других платформах, и их опыт мне очень интересен. В Афише традиционно разрабатывают на ASP.NET, в Рамблере - это Python и Perl, а также мобильные платформы. Вообще опыт работы в объединенной компании похож на работу сразу в двух организациях, очень интересно наблюдать над тем как сотрудники Афиши и Рамблера знакомятся друг с другом, начинают вместе работать, придумывают и делают новые продукты.

Наша команда, сейчас ищет новых участников — PHP разработчиков, которые уверенно работают с PHP5. Если вы хотите присоединиться, то смело пишите мне, и я отвечу на все вопросы!


Блоки и виджеты в  Zend Framework
2011-08-07T21:29:00.000+04:00
В проектах, где используется Zend Framework, часто по-своему решается вопрос с размещением на страницах одинаковых блоков или виджетов. Например, это может быть блок авторизации, где для новых посетителей отображается приглашение для регистрации или авторизации. Другой пример – это блок рекламы на странице. 

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

Одним из вариантов решения данной проблемы в ZF является вызов какого-то специального действия этого же или другого контроллера из шаблона страницы:
<div id="sidebar right">
    <div class="item">
        <?php echo $this->action('list',
            'comment',
            null,
            array('count' => 10)); ?>
    </div>
</div>
Здесь в шаблоне вызывается действие «list» контроллера «comment» с передачей параметра count = 10. Такой подход имеет ряд недостатков. Во-первых, здесь происходит дополнительная диспетчеризация. Во-вторых, в самих таких действиях для виджетов приходится что-то придумывать, чтобы их не вызывали напрямую (по URL). И еще одна проблема заключается в том, что логика запрашиваемой страницы строится не только вызванным контроллером, но и, возможно, каким-то другим контроллером, вызываемым из представления. То есть получается частично перевернутая модель MVC. 

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

Каждый блок оформляется как Action Controller Helper. Чтобы выделить все блоки вместе, необходимо определить в своем Bootstrap.php:
//init resourse type for blocks
protected function _initResourceLoader()
{
    $loader = new Zend_Loader_Autoloader_Resource(
        array(
         'basePath' => APPLICATION_PATH,
         'namespace' => ''
        )
    );
    
    $loader->addResourceType('block', 'blocks', 'Block');
}
Тогда код всех блоком можно смело размещать в каталоге applications\blocks.

Чтобы было легче добавлять блоки в контроллерах, необходимо добавить еще один хелпер, который я назвал Project_Controller_Action_Helper_Block.

Хелпер подключается в Bootstrap’е и содержит пока только один интересный метод add(), который можно использовать в коде контроллеров для добавления на страницы блоков:
public function indexAction()
{
    //add blocks to page
    $this->_helper->_block->add('userLogin');
    $this->_helper->_block->add('wellcomeMessage');
}
Сами блоки сохраняют какой-то готовый для вывода контент в свои собственные сегменты макета. В макете вывод выглядит обычным образом:
<?php echo $this->layout()->userLogin; ?>
<?php echo $this->layout()->wellcomeMessage; ?>
Если блок не добавляли в контроллере, то просто ничего не будет выведено.

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

Весь исходный код можно посмотреть здесь.


Хорошие практики написания тестов для TDD
2011-06-08T22:43:00.001+04:00
Не так давно для разработчиков в компании, где я теперь работаю, Андрей Бибичев проводил тренинг TDD - Test Driven Development. Сейчас, спустя некоторое время, я бы хотел записать здесь самые основные моменты, рассказать о тех приемах, которые мне помогли, и которыми у меня получается пользоваться каждый день.

Название тестовых методов
Как ни странно, правильное название для класса или метода - это очень важная часть разработки. Тоже самое действует и для методов тестов. Одна из хороших практик названий методов - давать названия вроде ShouldDoSomethingIfSomeValueGiven, начиная с "should". Или, если использовать PHPUnit, то testShouldDoSomethingForEmptyString, тоже самое с приставкой "test". Ничего страшного, если название получается длинным, зато название точно отражает, что сейчас тестируется.

Что тестировать
Если честно признаться, то до тренинга, я всегда старался писать по одному методу в тесте на один проверяемый метод. Теперь я поступаю иначе: каждый метод теста, это какой-то определенный случай. Что-то, что должно произойти, если дернуть за какую-то ручку. Или наоборот не должно произойти. Сколько методов теста писать? Столько, сколько придумаете! На самом деле нужно самому уметь останавливаться на чем-то разумном (сразу вспомнилось, что первые 20% усилий - дают 80% результата). 

Пример выделения тест-кейсов  
Приведу небольшой пример для тестирования диалогового окна печати в Windows (воображаемый класс page с интересуемым методом parse), нам надо проверить поле, в котором вводятся номера страниц, которые нужно напечатать.
<?php
class pageTest extends PHPUnit_Framework_TestCase
{
    function testShouldBeEmptyForEmptyString()
    {
        //GIVEN
        $emptyString = '';
        
        //WHEN
        $result = page::parse($emptyString);
        
        //THEN
        $this->assertEquals(0, sizeof($result));
    }
    
    function testShoultBeSinglePageForStringWithNumber()
    {
        //GIVEN
        $numberString = '123';
        
        //WHEN
        $result = page::parse($numberString);
        
        //THEN
        $this->assertEquals(1, sizeof($result));
    }
    
    function testShouldThrowOutOfRangeExceptionWhenGetWithInvalidIndex()
    {
        //GIVEN
        $wrongString = "2345";
        $result = page::parse($wrongString);
        
        //WHEN
        //get some index (123) from page range ($result)
        
        //THEN
        $this->assertFalse(in_array(123, $result));
    }
}
?>
Структура каждого теста
Каждый тестовый метод можно разбить на три части: GIVEN, WHEN, THEN (дано, когда, тогда). В первой части мы задаем какие-то начальные условия, когда тестовый случай может наступить. Во второй части, выполняем какой-то метод проверяемого кода, здесь должно быть основное действие, которое мы хотим проверить. В последней части мы размещаем набор ассертов, делаем проверку, что результат имеет ожидаемые значения.

Писать тесты трудно
Да, очень трудно писать тесты, если проверяемый код уже был написан до тестов. Если следовать TDD, то этот процесс совсем не трудный, но увлекательный. Архитектура самого кода становится при этом более правильной.

Happy TDDing!


Userscript для уведомлений в OWA
2011-05-26T22:31:00.001+04:00
Во многих компаниях в качестве корпоративной почты используется Microsoft Exchange. При этом сотрудники, которые предпочитают ОС на основе Linux, в любом случае испытывают неудобства: всеми возможностями корпоративной почты удается воспользоваться с трудом. Если администраторы разрешили поддержку IMAP, SMTP, то половина проблем решена. Однако получить доступ к календарю и адресной книге сложнее.

Один из вариантов решения проблемы — это использование программы DavMail. Программа позволяет получить из Exchange открытые стандарты: IMAP, SMTP, LDAP и Caldav, с которыми умеет работать огромное количество свободных программ. К сожалению, это решение пока плохо работает с новой версией Exchange 2010 (там нет поддержки Webdav).

С другой стороны в Exchange 2010 представлен более пригодный к повседневному использованию веб-интерфейс (OWA). Но, чтобы полностью перейти на работу с почтой через веб-интерфейс, не хватает уведомлений о новых сообщениях. Чтобы победить этот недостаток, можно воспользоваться таким userscript'ом:
// ==UserScript==
// @name           OWA 2010 Notify
// @namespace      <namespace>
// @include        <include>
// ==/UserScript==

window.checkNewMailElement = function(){

    var newMailCount = document.getElementById('spnCV');
    var count = 1;

    if(newMailElement.style.display != 'none'){
        
        if(newMailCount.innerHTML){
            count = newMailCount.innerHTML;
        }

        GM_notification("New " + count + " message(s)", "Outlook", null);
        window.setTimeout(checkNewMailElement, 5000);
    } else{
        window.setTimeout(checkNewMailElement, 1000);
    }
}

var newMailElement = document.getElementById('lnkNwMl');

if(newMailElement){
    window.setTimeout(checkNewMailElement, 1000);
}
Сами уведомления скрипт создает с помощью функции GM_notification, которой нет в Greasemonkey, но она есть в его форке - Scriptish. Для Firefox нужно именно дополнение Scriptish, чтобы воспользоваться приведенным скриптом.

А вот так это выглядит (Mac + Growl и Ubuntu 11.04):





Как MySQL выполняет соединения
2011-03-01T00:31:00.001+03:00
В MySQL соединения реализуются с помощью вложенных циклов (nested-loop). Причем соединения — это более общее понятие, чем запросы с JOIN'ами. Даже запросы адресованные к одной таблице выполняются по алгоритму nested-loop.

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

Звучит более запутанно, чем есть на самом деле :)

Псевдокод для выбора строк вложенными циклами может выглядеть следующим образом (для таблиц Table1 — range join, Table2 — ref join , Table3 — ALL join):
// $rowSetTable1 - matching range
foreach ($rowSetTable1 as $row) {
 
 // $rowSetTable2 - matching ref key
 foreach ($rowSetTable2 as $row) {
  
  foreach ($rowSetTable3 as $row) {
  
   if ( $row condition ) {
    // send to client
   }
  }
 }
}
Рассмотрим пример запроса, в котором участвуют таблицы Table1 и Table2:
SELECT t1.col1, t1.col2, t2.col3
FROM Table1 t1 INNER JOIN Table2 t2 USING (col2)
WHERE t1.col1 = 'a' OR t1.col1 = 'b';
Визуально план выполнения запроса показан на swimlane-диаграмме:


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


Используем по полной cd
2011-02-27T21:34:00.000+03:00
Команду cd (или иногда chdir), меняющую текущий каталог, пожалуй знают все. Поэтому важно уметь пользоваться такими базовыми командами на все 100.

Что может быть особенного в cd? На самом деле только два интересных момента.

cd без параметров
Если просто написать cd без параметров, то также как и cd ~, команда переместит вас в домашний каталог.

cd -
cd - сменит директорию на прошлую, там где вы были до того, как в прошлый раз выполняли cd. Так можно быстро перемещаться между какими-то двумя каталогами. Путь до прошлой директории хранится в переменной окружения OLDPWD, с помощью значения этой переменной cd - и работает.
user@desktop:~$ cd /usr/share/
user@desktop:/usr/share$ cd ~/www/sorting/
user@desktop:~/www/sorting$ cd -
/usr/share
user@desktop:/usr/share$ cd -
/home/user/www/sorting
Текущий каталог хранится в переменной окружения PWD, одноименная команда pwd (print working directory) выводит текущий каталог.


Stdin, stdout, stderr
2011-01-18T19:39:00.001+03:00
Стандартные потоки в Unix-подобных ОС являются каналами ввода/вывода между программой и окружением.

Дескрипторы стандартных потоков:0 — стандартный ввод stdin;
1 — стандартный вывод stdout;
2 — поток для ошибок stderr.

Очень полезны конструкции, которые позволяют вывод из одного потока направить в другой. Например, так ошибки будут сохранены в заданный файл:
command 2> error.log
Другой пример сохраняет вывод  stderr и  stdout в файл:
command > file-name 2>&1
command &> file-name
При запуске команд из PHP с помощью shell_exec() или `обратных кавычек`, в PHP возвращается только  stdout, но не  stderr. Здесь будет полезным перенаправление из stderr в  stdout: 
command 2>&1
В качестве небольшого дополнения, а также финального отступление от темы, приведу небольшой совет, как получить дополнительный доступ при работе с сайтами на Битриксе (конечно, если доступ нужен). С помощью командной PHP-строки (обычно страница доступна по URL /bitrix/admin/php_command_line.php) можно запускать терминальные команды:
echo nl2br(`tail -n 100 /var/log/apache2/site-error.log 2>&1`);
Дополнение в конце команды 2>&1, как уже определили, позволяет вывести ошибки, которые могут возникнуть.


Нововведения в  MySQL 5.5
2010-12-16T19:55:00.000+03:00
На прошлой неделе у меня получилось принять участие во встрече Moscow MySQL User Group (MMUG), где в основном обсуждали новую версию MySQL.

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

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

Повышение быстродействия
Для большей скорости было добавлено много улучшений:Несколько buffer_pool'ов (рекомендуется разбивать после того, как один buffer_pool становится больше 1 GB, так лучше утилизируется CPU, растет масштабируемость);
Теперь insert_buffer работает не только для insert'ов, но и для update'ов, detele'ов;
Снова работает group commit (в момент fsync собирается несколько транзакция);
Flush из  buffer_pool теперь более плавный (иначе обычно видны скачки в быстродействии).

Инструменты диагностикиPerformance_schema — содержит данные для диагностики производительности (но данные на текущем этапе очень низкоуровневые, в основном на уровне мьютексов);
Команда SHOW ENGINE INNODB STATUS;
Новые таблицы в information_schema (можно посмотреть такие параметры, как trx_innodb_locks и trx_innodb_waits).

РепликацияПолу-синхронная репликация в виде плагина, позволяет добиться следующего: если был сделан коммит, то можно быть уверенным, что соответствующая запись на диск была сделана в bin log  на slave;
Heartbeat — события на slave (насколько я понял, позволяют раньше находить проблемы между master и slave);
Relay log — автоматическое восстановление при падении slave.

УдобствоSIGNAL и RESIGNAL для обработки ошибок в хранимых процедурах (как throw catch);
Появилось больше опций для Partitioning;
Возможность выполнить truncate для одной партиции;
Pluggable authentication - пока есть только интерфейс, а сами плагины появятся через примерно полгода.

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

В заключении несколько материалов со встечи MMUG в тему: cлайды о новых возможностей MySQL 5.5 и видео со встречи.


Скачиваем файл с сервера по SSH
2010-12-06T20:17:00.000+03:00
Случаются такие моменты, когда на удаленном сервере находится файл, который нужен на локальной машине. Например, это может быть какой-то большой лог-файл, который нужно проанализировать.

Загрузить файл с сервера можно с помощью огромного множества программ, наверняка любимая IDE способна это сделать. Но здесь я опишу, как можно скачать файл не имея практически ничего под рукой, кроме стандартной консоли (или PuTTY для случая с Windows).

Скачать файл можно такой командой:
scp user@host:/directory/SourceFile TargetFile
Синтаксис здесь очень похож на синтаксис команды cp. Обратное копирование файла с локальной машины на удаленный сервере (или с одного сервера на другой):
scp SourceFile user@host:directory/TargetFile
Если на локальной машине для авторизация с сервером по протоколу SSH настроен ключ, то команду можно записывать с помощью вашего алиаса сервера:
scp myserver:/directory/SourceFile TargetFile
И в заключении, стоит отметить, что на машинах с Windows можно воспользоваться pscp, одной из утилит, которая идет в комплекте PuTTY:
pscp user@host:/directory/SourceFile TargetFile



Синонимы паттернов проектирования
2010-10-20T22:41:00.002+04:00
Одним из преимуществ шаблонов проектирования принято считать легкость в обсуждении проектных решений: достаточно одному разработчику назвать ключевое слово (название шаблона проектирования) и все сразу поймут, о чем идет речь. При этом нет необходимости многословно описывать различные отношения между объектами или схемы наследования классов, и это действительно хорошо.

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

Abstract Factory: Kit;
Adapter: Wrapper;
Bridge: Handle-body (описатель-тело);
Command: Action, Transaction;
Facade: Glue;
Factory Method: Virtual Constructor;
Iterator: Cursor;
Memento (хранитель): Token (лексема);
Observer: Dependents, Publish-subscribe;
Proxy (заместитель): Surrogate;
Singleton: Solitaire (холостяк);
Visitor: Walker (бродяга).



Небольшие перемены
2010-10-14T22:24:00.001+04:00
У меня давно было желание использовать свой домен YetAnother, который я случайно нашел. И сегодня это получилось сделать — представляю новое, более IT-ишное имя моего блога — Yet Another Blog или в сокращенном варианте YaB.

Как мне подсказали поисковики, блогов с таким названием на самом деле много, но, думаю, что это не страшно, - на то и "Yet Another" в  Yet Another Blog.

P.S. Постараюсь делать посты в YaB чаще :)


Буферизация результатов запроса в MySQL
2010-10-06T00:52:00.002+04:00
Иногда на стороне PHP требуется обработать большое количество данных, например, перебрать все строки большой таблицы.

Недавно мой коллега Алексей Шоков рассказал об интересной возможности — использование результатов выборки MySQL без буферизации. Обычно, при выполнении запроса на выборку такая функция, как mysql_query, буферизирует все строки данных на стороне клиента, прежде чем передать эти данные в PHP-приложение, то есть весь результат сначала накапливается. Но есть возможность начать работать с результатом раньше, по мере поступления данных.

Для этого существует функция mysql_unbuffered_query:mysql_unbuffered_query() sends the SQL query query to MySQL without automatically fetching and buffering the result rows as mysql_query() does. This saves a considerable amount of memory with SQL queries that produce large result sets, and you can start working on the result set immediately after the first row has been retrieved as you don't have to wait until the complete SQL query has been performed.
Пока идет обработка результатов сам запрос можно увидеть в списке процессов MySQL со статусом «Writing to net». В памяти на стороне клиента при этом находятся только данные для одной строки.

В блоге MySQL Performance Blog можно посмотреть статью с замерами времени выполнения запросов при использовании функций mysql_query против mysql_unbuffered_query. При обработке большой таблицы последняя выигрывает.

Однако, есть некоторые ограничения использования запросов без буферизации. Здесь все вполне очевидно — нельзя использовать функции mysql_num_rows() и mysql_data_seek(), а также нельзя выполнять другие запросы в пределах одного соединения, пока не завершена работа с первым небуферизированным.

Кроме того, согласно документации MySQL C API пока идет обработка результатов запроса без буферизации (например обработка на стороне PHP), невозможно обновлять данные ни в одной таблице, которая задействована в запросе. Это ограничение представляется самым неприятным на первый взгляд. Но на самом деле, это справедливо в случае, если используется MyISAM со своей блокировкой на уровне таблиц. Если же для таблиц используется InnoDB, то обновлять данные в таблицах, задействованных для запроса без буферизации, очень даже можно. Таким образом, для определенного круга задач, такой подход в построении запросов на выборку может дать дополнительный выигрыш.

В заключении приведу небольшие участки кода для использования запросов без буферизации с другими драйверами MySQL в PHP, а также для Perl.//PDO
$dbh = new PDO(
    'mysql:host=localhost;dbname=example', 
    'user', 
    'password', 
    array(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false));
//execute some unbuffered query
//...

//change buffered settings
$dbh->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true);
Для mysqli аналогичный результат можно получить, если добавить второй параметр MYSQLI_USE_RESULT к вызову mysqli::query.

Для Perl пример кода выглядит так:use DBI();
my $dbh = DBI->connect(
 "DBI:mysql:database=example;mysql_use_result=1;host=localhost", 
 "user", 
 "password");
//execute some unbuffered query
//...



Немного о TELNET
2010-10-05T20:58:00.003+04:00
TELNET — это сетевой протокол, первая версия которого появилась в 1969 году, для удаленного доступа к серверу с помощью передачи текстовых команд. Так же называют различные утилиты для клиентской работы с этим протоколом.

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

Сейчас чаще всего TELNET можно использовать для проверки работоспособности ресурсов, отладки по протоколам HTTP, SMTP, POP3 и других текстовых протоколов. Кроме того, TELNET используется для управляющего соединения FTP.

Попробуем провести диагностику одного из наших сайтов.

Для подключения необходимо ввести: telnet allsoft.ru 80После этого необходимо ввести запрос и указать хост – доменное имя сайта, к которому этот запрос относится (ведь на сервере может быть несколько виртуальных хостов).

Чтобы посмотреть заголовки индексной страницы сайта, нужно ввести:HEAD / HTTP/1.1
Host: allsoft.ruИ после два раза нажать Enter. Ответ будет примерно таким (можно производить диагностику по коду 200 OK):HTTP/1.1 200 OK
Server: nginx
Date: Tue, 05 Oct 2010 17:00:06 GMT
Content-Type: text/html; charset=windows-1251
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/4.4.4-8+etch6
Set-Cookie: PHPSESSID=11de9255db99fcf0c439bec8eb1712df; path=/
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cacheЧтобы посмотреть не только заголовки, но и исходный код, например, этой страницы http://allsoft.ru/sysadmins/, то можно ввести:GET /sysadmins/ HTTP/1.1
Host: allsoft.ru


Innovation games
2010-08-05T23:12:00.009+04:00
На этой неделе во вторник мне вместе с коллегами посчастливилось побывать на специальном семинаре Innovation Games, который для нас провел Никита Филиппов. Мероприятие мне понравилось, и поэтому я бы хотел немного рассказать о нем.

В качестве небольшого вступления стоит рассказать, что Innovation games – это в первую очередь произведение от Luke Hohmann’а (полное название книги "Innovation Games: Creating Breakthrough Products Through Collaborative Play"). Речь идет о небольших мероприятиях, которые можно провести с командой, об играх. Цель этих игр – это не только провести весело время, а выявить то, чего вы не знаете, о чем вы не подозреваете или, как рассказывал Никита Филиппов – не знаете, что это не знаете. Таким образом, инновационные игры являются для наблюдателей  своеобразным маркетинговым исследованием. 

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

Spider Web
Для нас в центре большого листа был подготовлен круг с надписью "Product Owner", необходимо было придумать другие роли и связать их с Product Owner’ом, а также пояснить эти связи.


Speed Boat
Участникам нужно было представить быструю яхту, которая может нестись по морю. Однако на пути яхты могут быть препятствия, так называемые "камни", которые мешают быстро двигаться, да и яхта может повредиться. Нужно было придумать такие "камни", и самые опасные поместить выше – ближе всего к лодке. В нашем случае в качестве лодки нужно было представить свою карьеру.


Remember the Future
В компанию приходит новый разработчик, и первое время он, как правило, обучается. Полноценную пользу он начинает приносить, скажем, через три месяца работы. Участникам игры Remember the Future нужно было придумать, что нужно за три месяца сделать руководителю для нового сотрудника, чтобы он полностью влился, стал самым классным Разработчиком! Игра сложна тем, что действия нужно было придумывать в обратном порядке: то есть сначала нужно было придумать самое последнее действие (примерно на третьем месяце), затем ближе к тому моменту, когда новый сотрудник только появился (второй и первый месяц).


Prune the Product Tree
На очень большой заготовке было нарисовано дерево с большими корнями, ветками и листвой.  В общем случае, листья на ветка – это фитчи, сами ветки – это релизы продукта. Корни – это то, на чем стоит проект, например техническая инфраструктура. В нашем случае правила были немного другие, для нас проектом была карьера в компании.


Buy a Feature
Участники получили прайс-лист с ценами за каждую фитчу. Каждый участник располагает определенной суммой, скажем, каждый имеет по $10. На все фитчи каждому не хватает, и чтобы что-то купить, нужно договориться с другими участниками, убедить их, что именно эта фитча более необходима.

Product Box
Участники представляют, что они продают коробку с… в нашем случае с лучшем Product owner’ом. Нам нужно было разработать дизайн коробки, сделать ее такой, чтобы именно нашего Product owner’а все хотели купить! В распоряжении были белые коробки, цветные фломастеры, клей, ножницы, несколько журналов и стикеров.



Команда, где я участвовал, выпустила очень клевую коробку с Product Owner’ом "S. Jobs"!


Требования к разработчику
2010-08-05T10:31:00.002+04:00
В очередной раз составлял требования к разработчику в нашу команду. И на этот раз решил записать этот список в свой блог, чтобы:во-первых, не забывать о том, что уже писал;
и во-вторых, спросить, что на Ваш взгляд нужно добавить или убрать?

Основные обязанностипроектирование архитектуры проекта, поиск нестандартных решений;
разработка веб-приложения под большую нагрузку (PHP/MySQL) и активное участие во всём процессе разработки (от проектирования и до запуска и поддержки);
взаимодействие с коллегами, обсуждение дизайна приложений.

ТребованияPHP - опыт работы с языком от 2 лет, отличное знание сильных и слабых сторон, в т.ч. нововведения версии 5.3 (приветствуется Сертификат Zend Certified Engineer, также приветствуется опыт работы с 1С-Битрикс);
ООП - опыт самостоятельного создания и использования объектов (любого языка программирования) от 6 мес.;
Шаблоны проектирования - уверенное знание и способность на собеседовании продемонстрировать эффективное использование на языке PHP любого из 23 шаблонов GoF;
SQL и MySQL - понимание стратегии оптимизации веб-приложений, опыт написания запросов к MySQL от 1 года (приветствуется опыт работы с PostgreSQL);
Unix/linux как минимум на уровне продвинутого пользователя.

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



Репортаж с Software People - часть 2
2010-04-23T21:16:00.007+04:00
Сегодня прошел второй день конференции Software People 2010. И сегодня же я сразу попробую изложить некоторые интересные тезисы с разных выступлений. 

Типичный день эффективного лидера – Сурен Самарчан
Из чего состоит день менеджера проекта? Сурен рассказал о дневных активностях и качествах менеджеров.
Усиление своей команды. До того, как человек стал менеджером, было важно, насколько хорошо он сам работал. Теперь важно другое – насколько хорошо работает команда. Пути усиления команды:Поиск и привлечение лучших сотрудников, и увольнение худших;
Использовать любое событие (провал или победу) для обучения;
Работать в паре (2 менеджера): фидбэк, рассуждение вслух;
Кросс-функциональные задания;
Для трудных задач донести команде, что любое задание – это последовательность простых шагов,  это повысит уверенность;
Критика;
Стараться мыслить в реальном времени, например, на совещании принимать решение не заранее, а во время.
Самостоятельность. Это должно сводиться практически к одному – лидер уходит, команда продолжает добиваться успехов и развиваться. Все понятные лидеру активности должны выполняться без него.

Энергия. Лидер должен заряжать энергией команду – показывать светлое будущее и конкретные шаги к нему. На практике, это предполагает:Работать больше всех, не уставать, не жаловаться, не паниковать, не унывать;
Проактивно реагировать на инициативы;
Организация легкой конкуренции;
Устраивать демонстрации клиентам, топ-менеджерам;
Не отдаляться от команды, жить успехом команды;
Переоценивать людей (немного выше, чем они есть).
Атмосфера. Должна быть искренность и открытость, слова и мысли должны быть синхронны. Что можно сделать на практике:Начать с себя;
Давать обещания на 1 уровень абстракции выше (например, не обещать, что сложный проект будет сделан через год, а пообещать, что разработка будет идти итерациями с демонстрацией результатов после каждой итерации);
Не нужно присваивать чужие заслуги, это плохо сказывается на атмосфере;
Необходимо показывать отношение к проблемам, как-то реагировать на каждое негативное высказывание участников команды.
Вопросы. До того, как вы были менеджером, вам нужно было отвечать на вопросы. Теперь ваша задача – задавать вопросы. На практике могут пригодиться такие приемы:Если вы не эксперт в области, то нужно детально изучить какой-то небольшой фрагмент, и задавать вопросы по нему. Тогда команда будет думать, что вы знаете все;
Должно чувствоваться ваше присутствие (проверять решение вопроса, задавать его еще раз через какое-то время).
И последнее, что я бы хотел передать с этого выступления – это очень интересный прием. Если команда теряет интерес к работе (у команды уже длительное время все получается), то можно назначить для очередной итерации deadline в 2 раза меньший, то есть поделить настоящий deadline пополам и назвать команде эту цифру  :)

Технология командообразования – Сергей Архипенков
По мнению Сергея, процесс командообразования состоит из трех шагов:Правильные люди;
Лидерство;
Точим пилу.
Мне показалось очень интересным определением «правильных людей». Их эффективность - это интеллект (IQ) помноженный на эмоциональный интеллект (EQ) в квадрате.
Эмоциональный интеллект предполагает, что человек осознал себя, что он есть и чего хочет. Также должна быть воля, и умение увидеть глазами другого человека.

Связи решают все Особенно обратные – Александр Орлов
Александр потрясающе рассказал о том, какие проблемы бывают у менеджера с получением или пониманием обратной связи, что нужно сделать, чтобы избежать этих проблем, и быть на коне!
Вот ключевые мысли:Должен быть канал обратной связи между разработчиком и пользователем продукта;
Необходимо регулярно встречаться с людьми (участниками команды) один на один;
Доносить до людей конструктивную обратную связь;
Говорить Спасибо;
Не ругать публично человека, это нужно делать наедине;
Конструктивно доносить обратную связь – иначе останется осадок, человек будет думать, что менеджер не хочет видеть его в команде; здесь можно использовать правило «сэндвича»: похвалить, затем поругать, затем снова похвалить;
Думать о результате, а не о процессе (например, не отключать доступ к башоргу, вполне возможно, что это никак отрицательно на результат, на работу человека не влияет);
Получать обратную связь от сотрудников к менеджеру;
Устраивать личные ретроспективы, например для того, чтобы посмотреть все ли перечисленные рекомендации выполняются.
И последнее что я бы хотел отметить, это доклады, которые я не буду пересказывать, но, тем не менее, они мне очень понравились. Это выступления Константина Кондратюка, Максима Дорофеева и Асхата Уразбаева.

Спасибо за внимание! Ждем новых конференций!


Репортаж с Software People - часть 1
2010-04-22T20:45:00.010+04:00
Сегодня я посетил конференцию Software People 2010, и теперь хочу поделиться полученными новыми идеями.

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

Гибкое мировоззрение - Питер Хрущка (Peter Hruschka)
Питер рассказывал об Agile подходе. Если пересказывать коротко, то было выделено три ключевые роли в команде:Product owner – отвечает за требования;
Project manager – отвечает за весь проект;
Software architect – отвечает за решение требований.
Остановиться я бы хотел на роли архитектора, потому что об этом на выступлениях об Agileили Scrum обычно не говорится.
Питер сравнивает роль архитектора с таким видом спорта, как десятиборье (сразу 10 видов соревнований по легкой атлетике). У архитектора, как и у спортсмена в  десятиборье должны быть развиты необходимые навыки (умение балансировать, коммуникабельность, документирование, способность упрощения и другие).
При этом все навыки должны быть развиты в равной степени. Нельзя очень хорошо разбираться во всем, но быть, например, некоммуникабельным архитектором – это будет провал. На каком-то совещании не будет выбрана проектная идея, которую придумал некоммуникабельный архитектор, потому что он не сможет о ней хорошо рассказать, не сможет ее продать. 
Также это можно сравнить с жонглированием: можно это делать не очень быстро, однако главное не уронить ни один предмет.

Важна деталь – не следует делать Project manager’а и архитектора одним человеком.

Кто такой менеджер продукта и что он может дать компании разработчику – Дмитрий Безуглый, Константин Бредюк
Дмитрий и Константин рассказывали о разнице в управлении проектом (заказная разработка) и управление продуктом. У этих видов управления разные цели:заказная разработка – сделать работу в рамках бюджета и сроков;
для продукта – вывести его на рынок.
Если сравнивать этап R&D, то для разработки проекта, будет больше development’а, чем research. Здесь выбираются более стабильные надежные технологии. Для продукта же наоборот необходимо рисковать, выбирать что-то новое из технологий, чтобы быть впереди конкурентов, здесь больше research.
Очень интересное определение Product Manager – Прослойка Между :-)

Тестирование – это не просто тестирование – Юлия Нечаева
Юлия очень хорошо рассказала о своем подходе – Business driven testing. Этот подход отличается от других, традиционных видов тестирования, например Requirements  driven testing (проверка на соответствие требованиям, удобен менеджерам), Development driven testing (поиск ошибок. Удобен разработчикам), Priorities driven testing (тестируется часть продукта, например, которая будет демонстрироваться, удобен для души) и другие.

Business driven testing предполагает тестирование на успех продукта. То есть это может быть:тестирование на основании целей проекта;
юзабилити-тестирование;
бета-тестирование пользователями;
бета-тестирование бизнесом;
работа с поддержкой.
Все это не смогут делать только тестировщики, это могут делать также:руководитель отдела тестирования;
менеджер;
маркетолог;
аналитик.
То есть это тестирование, очевидно, должно выполняться всеми лицами, участвующими в создании продукта.

Завтра будет второй день конференции, продолжение следует!


Что такое "Index" в Git?
2010-03-01T21:42:00.011+03:00
Данный пост был написан по мотивам статей The Thing About Git и My Git Workflow, в которых затрагивалась тема Индексов (Index) в Git’е.

Git чудесен! Git позволяет писать код в своей рабочей копии для, например, пяти различных фич. И для этого не нужно взаимодействие с удаленной VCS. У себя можно делать коммиты сколь угодно часто, или наоборот редко. После этого можно что-то изменить в своих коммитах, например, поменять свое аннотационное сообщение. Можно объединить коммиты, или разбить их, - в общем можно делать все что угодно и Git никак вас в этом не ограничивает.

Но Git трудно изучить, как минимум по трем основным причинам:Git слишком мощный, он обладает большим количество функций, которые могут напугать новичка;
Git использует нестандартные названия команд, в отличии от других VCS, где например устоялись значения для таких команд, как "checkout" или "revert", но не в Git'е!
И третье – Индексы в Git, механизм позволяющий выбирать, что коммитить, например, только протестированные файлы.

Справиться с первой трудностью, с мощностью Git’а, можно изучением различной документации, например, эта книга заслуживает внимания. 

Победить вторую трудность, нестандартные названия команд, можно также изучением документации. Но если не получается привыкнуть к необычным наименованиям, то можно пойти другим путем и установить знакомые синонимы для некоторых команд:
$ cat ~/.gitconfig
[alias]
  ci = commit -a
  co = checkout
  st = status -a
$ git ci -m 'some changes'

Так можно работать с Git почти как с Subversion.  Обратите внимание на синоним для ci = commit –a. Здесь ключ –a, кажется, позволяет решить и третью проблему, не использовать Индексы. Но все же лучше разобраться, как применять Индексы в своей работе.


На изображении выше показаны основные команды и хранилища данных, здесь же можно найти и Индекс. Получается, что команда git add нужна только для того, чтобы потом команда git commit могла увидеть обновленные файлы. И как мы уже выяснили, если выполнять коммиты с дополнительным ключом git commit –a, то можно забыть о добавлении файлов в Индекс.

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


Использование Индексов в качестве контрольных точек

Часто бывает, что при изменении кода точно не знаешь удачная это идея, или нет. То есть это просто эксперимент. Эксперименты могут затянуться, и поэтому нужно делать контрольные точки. Но стоит ли выполнять коммит с экспериментальным и скорее всего неработающим кодом? Этого не хочется делать. Однако для контрольных точек можно использовать Индексы, причем неоднократно. Это похоже на маленькие шаги, после которых код достигнет рабочего состояния, и тогда уже можно выполнить коммит.


При подходе с контрольными точками используются такие команды Git:git diff покажет какие изменения были сделаны с момента последней контрольной точки;
git diff head покажет изменения с последнего коммита;
git checkout . откатит все изменения до последней контрольной точки;
git checkout head . вернет состояние последнего коммита;
git stash и git checkout -m -b позволяют прятать и возвращать все изменения со времени последнего коммита.
 
Контрольные точки позволяют неплохо справляться с ситуациями, когда необходимо экспериментировать, пробовать несколько различных вариантов подряд. На самом деле, это всего лишь один из вариантов использование Индекса, не обязательно делать именно так. В качестве альтернативы Индексу, здесь могут служить ветки, которые вскоре понадобится удалить, или же временные файлы, вроде CMainApplication.class.php, CMainApplication_new.class.php :-)


Использование индексов для разрешения проблем в рабочей копии

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

Утром я неожиданно обнаружил в почте важное сообщение об ошибке на сайте – была найдена проблема с javascript на странице.  Это была довольно критичная ошибка, и мне сразу нужно было ее исправить. Правка не заняла много времени, но когда все было готово к коммиту, я обнаружил, что git status выдает такой результат:

$ git status
# On branch master
# Changed but not updated:
# 
#     modified: models.class.php
#     modified: views/entry.html
#     modified: js/dfunctions.js
#     modified: stylesheets/ dfunctions.css

Получилось так, что в этом списке приведены файлы от двух несвязанных между собой изменений:Изменились models.class.php и views/entry.html для формы добавления комментариев;
Изменились models.class.php, js/dfunctions.js и stylesheets/ dfunctions.css для исправления утренней ошибки с javascript.

Проблема заключается в файле models.class.php, который содержит правки и от одного, и от другого изменения. И в этом месте обычно начинаются танцы с бубном, и сожаления, что нужно было сделать все по-другому.

Что же может мне помочь? Можно воспользоваться командой вроде git stash, которая позволяет временно "припрятать" изменения. Но есть другой способ решения, более элегантный и с использование Индекса Git.

Итак, мне нужно выполнить коммит с js/dfunctions.js, stylesheets/ dfunctions.css и с частью изменений из models.class.php. Так попробуем добавить этот набор в Индекс:

$ git add js/dfunctions.js
$ git add stylesheets/ dfunctions.css
$ git add --patch models.class.php
diff --git a/models.class.php b/models.class.php
index be4159d..3efd4ce 100644
--- a/models.class.php
+++ b/models.class.php
@@ -256,7 +256,7 @@
     class Bookmark {
       …
-      $bookmark_update_attributes = $this->…
+      $bookmark_save_attributes = $this->…
       …
Stage this hunk [y/n/a/d/j/J/?]?

Здесь волшебным является ключ --patch (aka --interactive) для команды добавления в Индекс git add. Этот ключ указывает Git на то, что нужно показать все изменения в указанных файлах кусок-за-куском. И для каждого куска изменений можно выбрать одну из следующих опций:y – добавить кусок в Индекс;
n – не добавлять кусок в Индекс;
a –  добавить в Индекс этот и все последующие куски в файле;
d – не добавлять в Индекс этот и все оставшиеся куски в файле;
j – оставить этот кусок неразрешенным, перейти к следующему неразрешенному куску;
J – оставить этот кусок неразрешенным и перейти к следующему куску;
k – оставить этот кусок неразрешенным и перейти к предыдущему неразрешенному куску;
K – оставить этот кусок неразрешенным и перейти к предыдущему куску;
s – разбить этот кусок на более мелкие кусочки.

Опций довольно много, что позволяет удобно выбрать, какие изменения добавлять в Индекс. Несколько кусков изменений models.class.php, которые относятся к решению бага с javascript, я добавил в Индекс, а все остальные куски изменений отклонил (они относились к фиче с добавлением комментариев).

Теперь я могу проверить, что все сделано верно:git diff --cached показывает изменения которые добавлены в Индекс;
git diff показывает все изменения в рабочей копии.

Теперь можно смело коммитить исправление бага git commit -m "fix javascript bug" и продолжать работать над формой добавления комментария. Продолжить можно в отдельной ветке, но это не обязательно – Git позволяет работать, как вам хочется!


Миграция репозитория из Subversion в Git
2010-02-23T21:26:00.006+03:00
В этом посте мне хочется написать о своем опыте работы с Git. Моя работа с Git началась не с чистого листа, т.е. не со старта проекта. Проект уже существовал, когда появилась идея перевести его с текущей системы контроля версий (Subversion) на Git.

Почему возникла необходимость перейти на Git? Такое может понадобиться, если в проекте очень много исходных файлом, и поменять их расположение невозможно. Очень хорошим примером такой ситуации является проект на Битриксе, где очень много исходных файлов и их общий объем превышает 200 МБ. В таких случаях либо вообще не используют VCS, либо используют VCS лишь частично, покрывая только те исходные файлы, которые создала команда разработки. Последний пример с частичным покрытием кода проекта на Битриксе хорошо описан в статье моего друга.

Частичный контроль версий кода решает проблемы при командной работе лишь частично. Возникла необходимость иметь в VCS весь код, и поэтому начался процесс перехода от SVN к Git. Git обещал быть невероятно быстрым, что позволяло работать с очень большим количеством исходных файлов.

За руководство к действиям я взял статью Леонида Шевцова, однако не все у меня получилось, как там описано. И поэтому я привожу здесь описание своего опыта.

Для миграции необходим git-svn, его можно установить привычным способом:

sudo apt-get install git-svn

Теперь, чтобы можно было выполнить клонирование существующего SVN-репозитория, необходимо собрать всех авторов, которые выполняли коммиты. Форматы автором в SVN и Git отличаются, в частности для Git нужны не логины пользователей (как в SVN), а их e-mail’ы.

Список авторов можно получить, выполнив такой скрипт в папке с рабочей копией SVN-репозитория:

#!/usr/bin/env bash
authors=$(svn log -q | grep -e '^r' | awk 'BEGIN { FS = "|" } ; { print $2 }' | sort | uniq)
for author in ${authors}; do
  echo "${author} = "${author} <EMAIL>";
done

Скрипт выведет список авторов примерно в таком формате:

bender = bender <EMAIL>
zoidberg = zoidberg <EMAIL>
leela = leela <EMAIL>
fry = fry <EMAIL>

Этот вывод нужно сохранить в файл (рядом с местом, где вы хотите выполнить клонирование), но сначала заменить EMAIL на действительный e-mail для каждого автора. 

Теперь можно выполнить клонирование:

git svn clone -s --authors-file=my_authors http://svn.domain.ru/project .

В этой команде ключи означают:s – git-svn будет понимать стандартные папки SVN: trunk, branches, tags;
authors-file – это файл с авторами, который был подготовлен ранее.
Через пару минут, если проект не очень большой, мы получим Git-репозиторий со всей историей проекта. Далее можно навести блеск: создать .gitignore; убрать упоминания об SVN, если они есть; упорядочить ветки. Но на данном этапе, нам достаточно получившегося Git-репозитория, с ним уже можно делать первые шаги и проводить эксперименты – способен ли Git решить проблемы, о которых было написано выше.


Немного о GDD и Agile Days
2009-12-31T14:22:00.012+03:00
Сегодня 31 декабря, канун нового 2010 года. Перед тем как попрощаться со старым годом, мне бы хотелось немного рассказать о двух важных событиях, которых произошли в ноябре и декабре 2009 года. Это Google Developer Day и Agile Days — конференции в которых я с радостью принял участие.

Google Developer Day
GDD проходил 10 ноября в здании кинотеатра Октябрь: атмосфера зрелищности комедий, триллеров, фильмов ужасов и прочих катастроф полностью передалась участникам дня. Выступающие отлично говорили и выглядели очень профессионально, иногда казалось, что они больше шоу-мены или актеры, нежели синьоры-разработчики.

Сейчас доступны практически все материалы конференции, и даже видео, вот например ниже видеоролик с открытия GDD.



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

Вот основные моменты выступления:Должно быть небольшое общее описание API, до 1 страницы;
При проектировании API на начальной стадии лучше всего договориться с большим количеством участников, чтобы заручиться поддержкой;
API не сможет удовлетворить всех пользователей, выбирая между группами пользователей, лучше сделать API таким, чтобы оно было одинаково неудобно для всех групп пользователей, нежели удобным только для какой-то одной группы;
API должно быть настолько малым, насколько это возможно, нужно помнить, что добавить что-то можно всегда, а убрать — нет;
Реализация не должна влиять на API;
Если классы API могут быть наследованы — то это необходимо документировать, либо запрещать наследование (например, директивой final в PHP);
Исключения следует использовать только для исключительных ситуаций, а не для управления порядком выполнения кода;
Следует избегать возвращения значений, которые требуют дополнительной обработки;
Следить за единообразием порядка параметров для различных методов;
И последний универсальный совет  - всегда придерживаться принципа наименьшей неожиданности.


Agile Days
На этой конференции 9 декабря гуру в разработке и управлении проектами делились своими success story, а также рассказывали о проблемах с которыми они столкнулись при использовании гибкого agile-подхода к проектам. Здесь я попробую рассказать основные мысли из некоторых выступлений.

Евгений Сорокин из Intel рассказывал, какие трудности ждут распределенную команду:У разных команд может быть разная шкала оценок;
Разные временные зоны;
Трудность с обменом знаниями;
Неудобно общаться только по телефону.

В качестве советов для преодоления этих проблем, автор рекомендовал больше общаться и вести общий бэклог. Вот еще несколько интересных мыслей от Евгения:Новичков лучше направлять на повышение знаний по ООП, добиваться кроссфункциональности, использовать парное программирование, и через несколько месяцев разница между новичками и более опытными работниками будет размываться;
Очень большие user story называют epic story, они будут постоянно готовы на 90%. Чтобы легче с ними справляться, нужно лучше понимать мотивы, стараться разбивать «эпики» на бизнес-сценарии, двигаться от простого к сложному;
Разбивать требования не следует по техническим деталям (например, если разбить требование на 1 — составить таблицы БД, 2 — написать классы), потому что в этом не будет бизнес-ценности.

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

Вообще многие на конференции отметили, что различные фишки, fun — очень полезны для команды разработчиков. Вот несколько идей, какими могут быть эти фишки:«Шапка-чеканка» - разработчик, у которого находится эта шапка может делать merge с главной веткой кода;
Какой-либо аксессуар, например меч Джедая, на ретроспективе каждый кто хочет высказаться сначала берет этот меч, и говорит только когда аксессуар в руках;
«Сокровища и проклятия» - карточки с различными наградами (сокровища) или заданиями (проклятия). Задание может быть например таким: вытереть пыль с компьютеров коллег. Карточки можно раздавать тем членам команды, которые как-то проявили себя в спринте или наоборот в чем-то провинились;
Веселое оформление карточек с заданиями для доски;
Зарядка.


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