Этим постом сообщаю, что блог официально можно считать закрытым. Всех, кому была интересная моя писательская деятельность, приглашаю на продолжение банкета по адресу https://shepetko.com/ru/blog. Спасибо всем, кто был со мной здесь.

Классы и прототипы

Начнём с того, что вспомним, как «традиционные» ООП-языки создают объекты.

За основу мы возьмём объект по имени myCar. myCar — это максимально упрощённая версия автомобиля из материального мира. Наш объект имеет свойства, вроде color и weight, а также методы, вроде drive и honk.

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

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

Всякий раз. когда вы хотите создать новый объект myCar, вы говорите Jav'e: «сделай мне новый объект согласно спецификации, которая приведена в классе Car».

Созданный объект будет обладать свойствами и методами, которые описаны в классе. Если вы вызовете метод honk вашего объекта, то интерпретатор Java обратится к классу Car, найдёт код, который должен быть выполнен при вызове метода honk, и затем выполнит его.

Ничего нового. Теперь посмотрим. что творится в JavaScript.

Мир без классов

В JavaScript нет классов. Но как нам создавать объекты? Ведь не описывать вручную все свойства и методы всякий раз, когда нам потребуется новый объект?

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

Как же это делается в JavaScript? Вместо отношения «класс-объект» здесь используется отношение «объект-объект».

Там, где Java говорит «возьми класс Car и получи там весь код, необходимый для работы нового объекта», JavaScript говорит «вот тебе объект, который называется прототипом; возьми из него всё, что необходимо для создания нового объекта».

Подход, используемый в JavaScript, называется прототипным (Prototype-based) программированием, а тот, что используется в Java и подобных — классовым (class-based). Оба этих подхода являются отличными реализациями объектно-ориентированной парадигмы программирования, просто это два разных подхода.

Создание объектов

Ну что, пора погрузиться в код? Как нам всё-таки создать объект myCar, наделив его нужными свойствами и методами? Начнём с создания объекта «с нуля».

var myCar = {} 

myCar.honk = function() { 
    console.log("Би-бип"); 
}

myCar.drive = function() { 
    console.log("Вжжж...");
}

Теперь мы имеем объект, который может ездить и сигналить:

myCar.honk() // "Би-бип" 
myCar.drive() // "Вжжж..."

Но что, если нам нужно создать 30 автомобилей? Однозначно, копировать этот код 30 раз — не самая хорошая идея.

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

Более того, в языках вроде Java, мы делаем то же самое. Мы создаём такую машину для производства объектов в виде класса, после чего можем получать столько объектов, сколько душе угодно:

Car myCar = new Car();

Здесь ключевое слово new позволяет нам не заботиться о процессе создания объекта, беря всю работу на себя.

Но в JavaScript вся ответственность за создание объекта ложиться на нас. Но кроме того, мы получаем и больше свободы относительно того, как создаётся объект.

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

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

Рассмотрим каждый из способов детальней.

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

В нашем первом примере мы создавали объект myCar из ничего. Если мы завернём приведенный код в функцию, мы получим простую фабрику для создания объектов:

function makeCar() {
  var newCar = {} 
  newCar.honk = function() { 
    console.log("Би-бип");
  } 
}

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

function makeCar() {
  var newCar = {} 
  newCar.honk = function() { 
    console.log("Би-бип");
  }

  return newCar;
}

myCar1 = makeCar();
myCar2 = makeCar();
myCar3 = makeCar();

У приведённого способа есть существенный недостаток: на каждый создаваемый объект создаётся один метод honk. То есть, создавая 1000 объектов, мы заставим интерпретатор создать 1000 копий метода honk, которые делают одно и то же. В результате мы получим бесполезно растраченную память.

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

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

Использование конструктора для создания объектов

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

Давайте создадим конструктор для автомобилей. Мы назовём нашу функцию 'Car', в названии сделав первую букву заглавной намеренно: это широко распространённый способ именования конструкторов.

Поскольку мы рассматриваем два новых аспекта работы с объектами, мы разобьём работу на два шага.

Первым шагом мы почти повторим ранее рассмотренное решение, но только оформим его в виде конструктора:

function Car() { 
  this.honk = function() { 
    console.log("Би-бип"); 
  } 
}

Когда эта функция будет вызвана при помощи ключевого слова new, то в результаты мы получим экземпляр объекта с присоединённой к нему функцией honk:

var myCar = new Car();

Использование this и new исключает необходимость создания объектов «вручную», поскольку сам объект создаётся «за кулисами» автоматически, после чего передаётся фнкции-конструктору, где и становится доступен через this.

Проиллюстрировать вышеописанное можно при помощи следующего псевдокода:

// Псевдокод. Только для иллюстраций!
function Car(this) { 
  this.honk = function() { 
    console.log("Би-бип"); 
  } 

  return this; 
} 

var newObject = {} 
var myCar = Car(newObject);

Как уже было сказано, это решение напоминает предыдущее, то есть нам не нужно вручную создавать объекты, однако мы всё ещё не можем изменять поведение honk так, чтобы это отразилось сразу на всех созданных экземплярах. Однако, начало положено. используя конструктор, все объекты получают доступ к специальному свойству, которое связывает их с конструктором.

function Car() { 
  this.honk = function() { 
    console.log("Би-бип"); 
  } 
}

var myCar1 = new Car(); var myCar2 = new Car();
console.log(myCar1.constructor); // [Function: Car]
console.log(myCar2.constructor); // [Function: Car]

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

Источник: manuel.kiessling.net

Pimple — это очень простой DI-контейнер, который предлагает использовать PHP-замыкания, чтобы внедрение зависимостей для разработчиков было как можно более простым и естественным. В этой статье мы с вами разберём проблемы, возникающие при размещении зависимостей непосредственно в коде, как их можно избежать, используя dependency injection и как в этом может помочь Pimple, позволяя создавать код, который легче поддерживать.

Проблемы при использовании конкретных зависимостей

Почти любое приложение состоит из множества классов. Один класс вызывает методы других классов, те — третьих, и так далее. Представим, что у нас есть класс A, который использует для своей работы класс B (то есть, зависит от него):

<?php
class A {
    public function a1() {
        $b = new B();
        $b->b1();
    }
}

Класс А зависит от класса B потому, что если класс B или его метод b1 будет недоступен, то класс A не сможет работать.

Пойдём дальше. Всякий раз, когда вы внутри класса жестко определяете класс создаваемого объекта, вы создаёте конкретную зависимость от последнего. Конкретные зависимости — это неизбежный геморрой при написании тестов для вашего кода. Чем жёстко определять зависимости внутри класса, лучшим решением будет передавать их извне. Например, это можно сделать при помощи аргументов конструктора или специальных setter-методов.

Прежде чем двигаться дальше, давайте рассмотрим более реалистичный пример.

Популярные сегодня сайты социальных сетей предоставляют возможность пользователям делиться контентом на своих страницах, где можно увидеть опубликованные пользователем материалы в виде ленты. Допустим, у нас есть класс SocialFeeds, который генерирует ленты из различных соцсетей вроде Twitter, Facebook, Google+ и т. п. Для работы с каждой из них используется отдельный класс. Для примера давайте рассмотрим класс TwitterService, который реализует получение данных от Twitter.

Класс SocialFeeds запрашивает данные от Twitter, используя класс TwitterService. Тот в свою очередь извлекает из БД токен пользователя для доступа к Twitter API. Полученный токен передаётся классу OAuth, который авторизуется на Twitter, получает оттуда ленту и возвращает её классу SocialFeeds.

<?php
class SocialFeeds {
    public function getSocialFeeds() {
        $twService = new TwitterService();
        echo $twService->getTweets();
    }
}

<?php
class TwitterService {
    public function getTweets() {
        $db = new DB();
        $query = "Запрос получения данных учётной записи из БД";
        $token = $db->getQueryResults($query);

        $oauth = new OAuth();
        return $oauth->requestTwitterFeed($token);
    }
}

<?php
class OAuth {
    public function requestTwitterFeed($token) {
        // Получить ленту из Twitter, используя $token
    }
}

<?php
class DB {
    public function getQueryResults($query) {
        // Получить данные из БД и вернуть токен
    }
}

Очевидно, что SocialFeeds зависит от TwitterService. Но TwitterService в свою очередь зависит от DB и OAuth, таким образом существует непрямая зависимость SocialFeeds от DB и OAuth.

Так в чём же суть проблемы? SocialFeeds зависит от конкретных реализаций трёх классов, таким образом невозможно выполнить отдельное юнит-тестирование SocialFeeds, не прибегая к реализации остальных классов, от которых он зависит. Или, скажем, нам понадобится использовать другую СУБД или другого провайдера OAuth. Если такое произойдёт, нам придётся вносить изменения в код везде, где создаются экземпляры соответствующих классов.

Избавление от конкретных зависимостей

Решение проблемы настолько простое, насколько простой является передача объекта другому объекту в процессе выполнения программы. Существует два способа выполнения этого: внедрение зависимости в конструкторе или при помощи setter-метода.

Внедрение зависимости в конструкторе

В это варианте внедрения зависимости зависимые объекты создаются вне класса и передаются в качестве аргументов конструктора, после чего полученные объекты связываются со свойствами класса и далее используются где угодно внутри него. Вернёмся к примеру, рассмотренному выше и попробуем реализовать внедрение зависимости через конструктор.

<?php
class SocialFeeds {
    public $twService;

    public function __construct($twService) {
        $this->twService = $twService;
    }

    public function getSocialFeeds() {
        echo $this->twService->getTweets();
    }
}

Экземпляр TwitterService передаётся через параметр конструктора. SocialFeeds всё ещё зависит от TwitterService, но теперь мы можем снаружи подсовывать нужную реализацию класса или даже использовать mock-объект при тестировании класса.  С классами DB and OAuthмы по ступим точно так же:

<?php
$db = new DB();
$oauth = new OAuth();
$twService = new TwitterService($db, $oauth);
$socialFeeds = new SocialFeeds($twService);
$socialFeeds->getSocialFeeds();

Внедрение зависимости через setter-метод

Здесь всё делается точно так же, только теперь зависимости передаются не в конструктор, а через специально для этих целей созданный метод. Например, в SocialFeeds это может быть сделано так:

<?php
class SocialFeeds {
    public $twService;

    public function getSocialFeeds() {
        echo $this->twService->getTweets();
    }

    public function setTwitterService($twService) {
        $this->twService = $twService;
    }
}

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

<?php
$db = new DB();
$oauth = new OAuth();
$twService = new TwitterService();
$twService->setDB($db);
$twService->setOAuth($oauth);

$socialFeeds = new SocialFeed();
$socialFeeds->setTwitterService($twService);
$socialFeeds->getSocialFeeds();

Внедрение в конструкторе против setter-методов

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

Достоинства:

• Конструктор. Все зависимости класса сразу видны из сигнатуры метода.
• Setter. Добавлять новые зависимости можно в любой момент, не затрагивая существующий код.

Недостатки:

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

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

Роль Pimple во внедрении зависимостей

Вам может быть интересно, зачем нужен Pimple, если всё и так прекрасно решается пи помощи рассмотренных выше приёмов. Чтобы ответить на этот вопрос, нужно обратиться к принципу DRY, который гласит, что «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы».

Вернёмся к нашему примеру с внедрением зависимости через конструктор. Всякий раз, когда нам нужен объект класса SocialFeed, нам нужно заново создавать все необходимые объекты, чтобы передать их в конструкторы. Согласно DRY, такой повторяемости следует избегать, чтобы уменьшить количество головной боли в будущем, при сопровождении кода. Pimple выполняет роль контейнера, внутр которого выполняются все необходимые манипуляции перед подготовкой нужного объекта. Давайте взглянем на пример работы с Pimple, и вам сразу станет понятней о чём идёт речь:

<?php
$container = new Pimple();
$container['class_name'] = 'Test';
$container['object_name'] = function ($c) {
    return new $c['class_name']();
};

$testClass = $container['object_name'];

Сначала создаётся экземпляр контейнера Pimple, который и будет хранить всю необходимую информацию о зависимостях и создавать их в случае необходимости. Класс Pimple реализует интерфейс SPL ArrayAccess, так что снаружи работа с контейнером Pimple напоминает работу с массивами. В следующей строке мы помещаем в контейнер имя конкретного класса, объекты которого нам понадобятся в дальнейшем.  Потом мы помещаем в контейнер функцию-замыкание, которая и выполняет всю работу по созданию объектов. Обратите внимание на параметр $c в замыкании, который является ссылкой на Pimple-контейнер и позволяет получать доступ к контейнеру изнутри замыкания. В приведённом примере замыкание извлекает из контейнера имя класса через ключ 'class_name', чтобы определить имя нужного класса при создании объекта.

Дайте переработаем наш пример из начала статьи так, чтобы использовать Pimple. На официальной странице Pimple приводится пример с использованием конструкторов, а мы в нашем примере давайте будем использовать setter-методы. Обратите внимание на то. что мы не изменяем существующий код. Всё остаётся как было, мы только инкапсулируем необходимую логику в контейнер Pimple.

<?php
$container = new Pimple();
$container['oauth'] = function($c) {
    return new OAuth();
};
$container['db'] = function($c) {
    return new DB();
};
$container['tweet_service'] = function($c) {
    $twService = new TwitterService();
    $twService->setDB($c['db']);
    $twService->setOauth($c['oauth']);
    return $twService;
};
$container['social_feeds'] = function($c) {
    $socialFeeds = new SocialFeeds();
    $socialFeeds->setTwitterService($c['tweet_service']);
    return $socialFeeds;
};

$socialFeeds = $container['social_feeds'];
$socialFeeds->getSocialFeeds();

Классы DB и OAuth являются независимыми, поэтому мы создаём их экземпляры непосредственно. Затем мы внедряем их в качестве зависимостей в TwitterService, используя setter-методы. Поскольку DB и OAuth уже находятся в контейнере, мы можем получить к ним доступ непосредственно из замыкания, используя вызовы $c['db'] и $c['oauth'].

Итак, теперь зависимости инкапсулированы внутри контейнера. Теперь, если вам понадобится использовать другую реализацию DB или OAuth, вы можете просто заменить их в контейнере и всё будет работать! Используя Pimple, вы можете внедрять все зависимости в одном месте вашего кода.

Продвинутое использование Pimple

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

Pimple предоставляет такую возможность. Для того необходимо всего лишь завернуть замыкание, создающее экземпляр объекта в метод share():

<?php
$container['db'] = $container->share(function ($c) {
    return new DB();
});

До сих пор мы объявляли все сервисы с их зависимостями в одном месте, внутри контейнера Pimple. Но представьте себе ситуацию, когда вам необходимо в каком-то месте программы изменить часть поведения сервиса. Например, вы захотели использовать ORM в классе TwitterService. Мы не можем менять исходный код TwitterService, поскольку это затронет все остальные, зависимые классы.

Pimple предоставляет метод extend(), который помогает в подобных ситуациях. Посмотрите на следующий пример:

<?php
$container['tweet_service'] = $container->extend('tweet_service', function($twService, $c) {
    $twService->setDB(new ORM());
    return $twService;
});

Теперь мы можем использовать новую версию сервиса tweet_service. Первый аргумент метода extend() — это имя существующего сервиса, а второй — это замыкание, которое получает экземпляр сервиса и контейнера Pimple.

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

Итоги

Управление зависимостями является одним из краеугольных камней при разработке веб-приложений. Мы можем внедрять зависимости в конструкторах классов или использовать для этого специальные setter-методы, хотя это и тянет за собой свои недостатки. Pimple позволяет в большей степени избавиться от многих неудобств, давая возможность создавать приложения, следуя принципам DRY.

Источник: SitePoint

Scrum предлагает проводить демо в конце каждого спринта непосредственно перед ретроспективой. команда должна подготовить работающую версию, на которой инвесторам и product owner'у можно показать, какие из запланированных функций реализованы и то, что они работают.

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

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

Что ж, всё это выглядит достаточно простым. Вы являетесь гибкой командой, у вас все тесты всегда «зелёные» и ваш продукт всегда готов к использованию. Разве сложно подготовить демо? Это намного сложнее. чем вы можете себе представить!

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

Мы по-прежнему нуждаемся в руководстве

Это был момент, когда наш scrum master предложил проводить совещания ежедневно. Да! Ежедневно, каждое утро, в одно и то же время!

Я нахожу это очень полезной затеей для новых команд, где люди ещё не притёрлись друг к другу или не полностью погрузились в проект. Такие ежедневные собрания, которые называются Daily Scrum, проводятся командой ежедневно в точно определённое время. Они должны проводится обязательно до того, как будет сделана какая-либо работа за соответствующий день. В нашей команде мы решили собираться в 10 утра, что было трудновато выполнять, но тем не менее, это было хорошим решением.

Daily scrum — это простые и короткие совещания, длящиеся не более 15 минут. Целью таких совещаний является помощь команде быть в курсе того, кто и чем занят, какие имеются проблемы и узкие места в работе.

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

На daily scrum каждый участник команды должен ответить на три вопроса.

• Что было сделано вчера? Короткий ответ. 2-3- минуты максимум.
• Чем он собирается заниматься сегодня? Тоже очень коротко. Типа: «сегодня я работаю над историей N».
• Есть ли проблемы? Если есть, то что делать? Можно ли их быстро решить? Ответ должен быть коротким, освещающим суть проблемы и способа решения, если таковое имеется на данный момент. Нельзя допускать никаких подробных обсуждений проблем на этом собрании. Scrum master должен отметить для себя, что есть такая-то проблема и приступить  к её решению только после окончания собрания.

Решение проблем и устранение различного рода препятствий должны иметь наивысший приоритет в работе команды, поскольку в противном случае процесс разработки будет постоянно прерываться. Часто тому, кто столкнулся с проблемой, её решение — это всего лишь вопрос времени. В некоторых случаях для устранения препятствия требуется помощь команды. А иной раз случаются вещи, которые парализуют работу всей команды целиком.

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

Большинство наших проектов написаны на PHP. В какой-то момент нам потребовалось связывать наши приложения с VMWare. Мы посмотрели, что из официальных библиотек есть для доступа к VMWare API. Были версии для Java и Perl, а также был найден неофициальный вариант для Ruby. Мы были уверены, что у нас не возникнет проблем с использованием найденных решений и всё ограничится простыми вызовами exec () и разбором возвращаемого значения. Ну и, как нам казалось, всё это будет проще пареной репы.

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

Проблема оказалась просто огромной и отбросила сроки на недели! Конечно же. мы тут же поставили в известность product owner и совместно с ним мы разрабатывали новый график, писали новые истории, в которых отражали создание создание новой API-библиотеки.

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

Итоги

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

Главное, что я могу вам посоветовать: пробуйте Agile-техники и Scrum в частности. Пробуйте и формируйте своё мнение. Уверен, вы найдёте множество полезных моментов и сможете их внедрить в работу своей команды. Будьте гибкими, берите то, что вам подходит и пробуйте это в работе и в жизни. Не бойтесь добавлять что-то от себя. помните, что Agile — это прежде всего гибкость, а не слепое следование правилам.

Часть 1

Часть 2

Источник: Nettuts+

Пользовательские истории

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

Описание истории может звучать примерно так: «В качестве пользователя мне нужна возможность открыть папку с файлами для общего доступа со своими коллегами».

На этом этапе у нас не было определённого product owner, поэтому наш scrum master составлял описание историй сам. Это приемлемо в самом начале, но я категорически рекомендую вам разделить эти две роли! Иначе как вы себе представляете общение scrum master и product owner при планировании спринтов, если это будет одно и то же лицо?

Вы можете подумать: «Зачем вообще им общаться? Не лучше ли сделать так, чтобы один человек решал что нужно сделать и когда?». Нет, не лучше. Две роли, находящиеся в одном человеке, обязательно будут оказывать влияние одна на другую. А вот два отдельных человека уже будут куда более более объективными, направляя команду по верному пути и эффективно достигая конечного результата.

Итак product owner описывает истории, а scrum master обсуждает их выполнение с одной стороны с командой, с другой — с product owner.

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

Баги, баги, баги

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

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

Я знаю некоторые команды разработчиков, которые накапливают баги в течение трёх спринтов, а каждый четвёртый посвящают только исправлению багов. Другие практикуют разделение спринтов по принципу отношения 25% багов к 75% пользовательских историй. Некоторые команды могут работать с историями до обеда, а с багами — после. Короче, кто на что горазд.

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

Задачи или части истории

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

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

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

Технические задачи

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

В нашей команде мы для себя определили что подобные задачи должны быть отделены от историй, которые привели к возникновению этих задач. Такой подход  позволяет лучше отслеживать такие дополнительные задачи. На снимке нашей доски вы можете увидеть такие задачи на листках зелёного цвета. Там есть одна в колонке «Sprint Backlog» и три в колонке «Testing».

Технический backlog.

Этот backlog предназначен для инфраструктурных задач вроде обновления ПО, подготовки нового сервера и всего, что делает наши девелоперские будни легче. Это вещи, которые должны быть сделаны к определённому моменту и которые не имеют непосредственного отношения к разрабатываемому проекту.

В принципе нет уж такой большой необходимости помещать технические задачи в отдельный backlog. Я знаю команды, которые этого не делают. Наша команда перестала использовать технический backlog несколько месяцев назад, поскольку мы пришли к выводу, что инфраструктурные задачи настолько же важны, как и все остальные. Однако, если ваша команда молодая и опыт использования Agile-техник и Scrum в частности у вас небольшой, то лучше всё-таки выделите для техннических задач отдельный мини-backlog. Я советую вам как минимум хотя бы попробовать. Это может работать у вас, а если вдруг нет, то помещайте технические задачи в общую кучу, только выделяйте их отдельным цветом.

Великое испытание: оценка

В течение совещания по планированию мы решаем какие истории и баги из product backlog (в нашем случае — release backlog) могут быть завершены к окончанию планируемого спринта. Это может показаться простым, но на самом деле это довольно сложное занятие.

Product owner выдвигает список историй, которые необходимо завершить в первую очередь. Как правило, в этом списке больше работы, чем можно успеть сделать за отведённое на спринт время. Scrum master вместе с командой должны договориться с product owner о том, какие истории реально могут быть выполнены к концу спринта. Со временем этот процесс упрощается, поскольку product owner начинает лучше понимать с какой скоростью работает команда. Также и команда может становиться более продуктивной с течением времени, получая возможность выполнять больше работы. Очень замечательно иметь команду, которая желает превзойти ожидаемый от неё результат!

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

Story point'ы

Story point'ы — один из самых популярных методов оценки историй, багов и задач. Они не обязательно окажутся лучшим подходом в вашем случае, но для начала вам должно этого хватить.

Итак, что же такое story point? В самом начале команда отыскивает самую простую историю, которую они смогут найти на доске. Неважно, насколько она сложна для реализации технически или сколько её реализация займёт времени. Когда они находят такую историю, ей присваивается один story point. В некоторых проектах такая история может быть очень лёгкой для реализации, вроде исправления ошибки в GUI на 10 минут, но может требовать и пары часов от двух-трёх человек. Теперь, когда у вас есть точка отсчёта, вы можете оценить оставшиеся истории.

На практике это может быть куда сложнее, чем в теории. Существует минимум две распространённых системы story point'ов:

• числа Фибоначчи — 1, 2, 3, 5, 8 (может быть и 13, но это уже слишком огромная история, на мой взгляд);
• степени двойки — 1, 2, 4, 8 (может быть, 16, но старайтесь избегать такого значения по той же причине, что и в предыдущем пункте).

Выбирайте то, что вам по душе. Будьте гибкими! возможно вы захотите использовать систему с приращением в две stroy point. На здоровье!

Цвета светофора

Числа хороши и для многих технарей являются удобными. Однако в какой-то момент вы можете заметить, как разработчики начинают связывать story point'ы с часами. Типа: «Это займёт у меня два дня, значит это где-то пять story point'ов». Это неправильно! Оценки из плохих станут ещё хуже, когда вы начнёте так поступать. Stoty point'ы никогда не должны соответствовать времени и наоборот.

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

Обычно каждый цвет имеет следующее значение:

• зелёный означает, что задача простая и может быть завершена до конца спринта;
• жёлтый говорит о том, что зада имеет повышенную сложность и потребует больше усилий от разработчиков, нежели «зелёная», но также имеет большие шансы на то, чтобы быть завершённой в срок;
• красные метки присваиваются очень сложным задачам, которые вряд ли могут быть завершены за один спринт. У вас не должно быть много таких задач, или вообще быть не должно, если только вы не внедряете пятидневную систему спринтов.

Размеры футболок

Числа могут показаться вам слишком уродливым решением, цвета — слишком детским. Самое время рассказать вам о размерах футболок! Эта система также поможет вам избавиться от привычки смешивать время на выполнение и оценку сложности задачи. Всё просто: вместо чисел и цветов используйте размеры S, M, L, XL и XXL, когда  будете оценивать ваши истории.

И ещё

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

Измерение скорости разработки

Итак, вам интересно увидеть, насколько хорошо вы справляетесь с задачами на текущий спринт? Частенько используемый метод для этого — burndown-диаграмма:

На этой диаграмме вы видите пятидневный спринт с расчётом на выполнение 10 point'ов. Каждая точка на графике соответствует количеству story point'ов, оставшихся на конец дня. Зелёная линия отображает идеальный ход спринта, в котором команда ежедневно выполняет по два story point'а. Красная линия отражает реальное положение вещей, то есть скорость, с которой команда работает на самом деле.

Этого графика нет на представленном выше фото нашей доски. Наша команда использует лист формата А4 с burndown-диаграммой каждого спринта, помещая её над доской. Подводя итоги каждого дня, один из членов команды был ответственным за подсчёт количества выполненных story point'ов за тот день. Это очень простая процедура, если учесть то, что разработчики перемещают свои задачи между колонками. Таким образом легко можно подсчитать, сколько point'ов выполнено, а сколько осталось.

Не бывает наполовину выполненных историй. История либо выполнена, либо нет. Если она не выполнена, то она и не учитывается на графике.

И конечно же, вы ошибётесь с оценками! Особенно это касается тех, кто только начинает работать. И, к сожалению, нет способа этого избежать! Нет способа знать заранее, сколько point'ов вы осилите. Ваш первый график может выглядеть подобным образом:

Наш первый график точно был похож на этот. Я думаю, мы не выполнили даже и половины из того, на что подписались. Почему? Ну, наверное, потому что оценка — это сложная штука. Неважно чем вы занимаетесь, не имеет значения насколько вы хороши в этом. Когда кто-то просит вас прикинуть насколько сложно сделать что-то, что вы никогда не делали, вам придётся изрядно попотеть, прежде чем вы сможете давать более-менее адекватные оценки. Только без паники! Старайтесь изо всех сил. Со временем вам это будет даваться всё легче. В какой-то момент на коротких спринтах вы сможете достигать точности до 70%. На длинных спринтах точность ваших оценок вероятней всего будет ниже, поскольку у вас будет больше историй, а также больше переменных, которые могут оказаться не тем, чем вы ожидаете изначально.

Всякий раз, когда вы ошибаетесь, меняйте подход к оценке. На следующий спринт возьмите 4 point'а. Например:

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

Работая с burndown-графиками, хорошей практикой будет делать среднюю оценку 3-4 последних графиков, чтобы примерно определить количество story point'ов, которые вы можете взять на будущий спринт. Конечно, в самом начале у вас нет такой возможности, поэтому точность ваших оценок будет не такой высокой, как в будущем. Это нормально.

С течением времени ваши графики будут всё больше и больше походить на первый пример. Скорость работы команды будет всё более и более устойчивой.

Скорость?

Этот термин обозначает то, насколько быстро вы работаете. Иными словами: как много вы можете сделать за спринт. Одна из наиболее  концепций Agile заключается в том, чтобы иметь обеспечить постоянную скорость работы команды. При традиционном управлении проектами скорость уменьшается с возрастом проекта. Растущая его сложность приводит к неминуемому снижению скорости.

Методология Aglie направлена на то, чтобы поддерживать скорость постоянной. выпускать продукт часто сейчас и делать то чаще в будущем. Как они это делают? Scrum — один из элементов паззла. Остальными элементами являются техники, который программисты используют, чтобы улучшить процесс разработки. Например, XP (eXtreme Programming), Pair Programming, TDD (Test Driven Development) и т. п. Всё это, собранное воедино, поможет вашей команде стать лучше в разы.

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

Анализируйте прошлые результаты и улучшайте их

После нескольких первых спринтов наш scrum master собрал всю собрал всю команду и начал задавать вопросы. Мы говорили о положительных и негативных моментах, с которыми столкнулись за последнюю неделю. Это, возможно, не всегда и для всех приятно, но это бесспорно важный момент в работе. Сам процесс обсуждения того, что на ваш взгляд пошло неверным путём даёт больше осознанности происходящего. И конечно же, всегда важно знать, что вы сделали хорошо!

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

• команда слишком много спорила друг с другом;
• программисты X и Y не сотрудничали в парном программировании;
• мы слишком долго возились с мелочами X и Y;
• мы не всегда практиковали парное программирование;
• мы не написали юнит-тесты для модуля M/

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

Среди позитивных моментов из моей практики ретроспектив можно отметить:

• мы успели всё сделать вовремя;
• мы могли общаться без споров;
• некоторые участники стали более восприимчивыми к чужим идеям и предложениям;
• мы писали весь код согласно принципам TDD.

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

Часть 1

Часть 3

Источник: Nettuts+

Немного истории

На самом деле Scrum корнями уходит за пределы начала эры гибкой разработки ПО. Первое упоминание о Scrum в контексте коммерческой разработки ПО датировано 1986 годом, авторами которого являются Hirotaka Takeuchi и Ikujiro Nonaka. А вот первое официальное формальное определение Scrum представили Jeff Sutherland и Ken Schwaber в 1995 году.

Популярность Scrum выбстро выросла после публикации Agile Manifesto в 2001 году, а также книги Development with Scrum авторства Ken Schwaber и Mike Beedle.

Некоторые факты

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

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

Mike Kohn

Роли

Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»

Википедия

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

• полностью вовлечённые (committed) — участники этой группы несут непосредственную ответственность за создание конечного продукта. Участниками данной группы являются члены команды разработчиков, scrum master, product owner.
• частично вовлечённые (involved) — участники, заинтересованные в реализации продукта, но не принимающие активное участие в его разработке. Обычно это инвесторы и менеджеры.

Как мы начинали

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

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

Mike Cohn

Талантливая команда, в которой я работаю, уже много знала об Agile-техниках. От каскадной модели разработки мы пришли более гибкому процессу, что привело к более частым релизам продуктов. Мы успешно выпускали новый релиз каждые 3-6 месяцев, при этом существенно снизив уровень ошибок.

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

Этот человек и занял роль scrum master.

Scrum master

Если совсем просто, то Scrum Master — это, пожалуй, одна из наиболее важных ролей в Scrum. Этот человек является мостиком между product owner и командой. Как правило, scrum master имеет хорошую техническую подготовку и активно принимает участие в процессе разработки. Также, он или она общаются с product owner относительно пользовательских историй (user stories) и product backlog.

Scrum master координирует процесс разработки продукта, но в то же время он не занимается микроменеджментом, поскольку scrum-команда является само-организуемой. Конечно, в самом начале внедрения процесса scrum master может быть вовлечён в микроменеджмент по той простой причине, что участникам команды необходимо время и помощь, чтобы разобраться с новыми деталями и научиться себя самоорганизовывать.

У Scrum Master на самом деле больше обязанностей, о которых я расскажу дальше в статье.

Введение в sprint

У нашей команды 3-6-месячные релизы выходят без проблем, но лично я изначально даже вообразить себе не мог возможности такой частоты выпуска продукта. Я думал, что это уж очень быстро и у нас не будет времени на интеграцию и тестирование. И тут scrum master ввёл новое понятие: спринт (sprint).

Спринт является базовой единицей при планировании в Scrum. Он может занимать от недели до месяца и после его завершения продукт должен быть в стабильном состоянии и быть готовым к использованию.

Планирование спринта

Это один из нескольких типов совещаний, рекомендуемых Scrum. Перед началом каждого спринта команда, product owner и scrum master собираются для того, чтобы составить план следующего спринта. Такое совещание может занять весь день, хотя это не является хорошей практикой. На планирование одного спринта должно уходить не более двух часов.

В нашей команде планирование спринта заключается в просмотре product backlog и выборке из него задач, которые будут включены в планируемый спринт. Процесс отбора задач выполняется путём обсуждения между командой, представленной scrum master, и product owner.

Product owner

Этот человек занимается описанием пользовательских историй и сопровождением product backlog. Кроме того, он или она являются связующим звеном между командой и высшим руководством. Product owner занимается обработкой запросов от инвесторов, высшего руководства, пользователей, а также ряда других задач вроде анализа баг-репортов.

Product owner расставляет приоритеты в backlog, обеспечивая реализацию наиболее востребованной в тот момент функциональности в наиболее короткие сроки. Для этого он планирует выполнение историй так, чтобы уложиться вовремя. Это может показать сложным. А так оно и есть! Фактически, определение того, какая очередная «фича» принесёт продукту наибольшую пользу, является самой сложной задачей во всём процессе разработки. С другой стороны, иногда это очень легко, поскольку у вас может быть огромное количество пользователей, запрашивающих одну и ту же новую функцию. В таких случаях выбор очевиден. Если эти пользователи представляют бОльшую часть аудитории продукта, то реализация запрашиваемой функциональности  принесёт вам наибольший позитивный отклик от существующих пользователей.

Но опять-таки, это сложный выбор. Что делать, если реализовав другую функциональность, вы сможете вдвое увеличить вашу пользовательскую базу? То есть. перед вами выбор: либо «задобрить» существующих пользователей, либо получить ещё столько же новых. Где тут правильный выбор? Всё зависит от конкретного бизнеса, и именно на product owner лежит ответственность за правильность этого выбора.

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

Доска для планирования

Я помню то утро. когда это случилось. Я пришёл в офис и застал нашего scrum master за изготовлением самодельной доски для планирования из белых листов бумаги и скотча. Я понятия не имел, зачем он это делает. Я готовил кофе и ждал, когда он закончит.

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

В настоящий момент наша доска приспособлена для нужд Lean Development Process которым мы пользуемся сегодня. Запомните, Aglie призвана научить вас адаптироваться к изменениям. Никогда слепо не следуйте правилам.

Итак. что же у нас есть на доске?

Колонки на доске и процесс разработки

Есть четыре основные колонки:

• Release Backlog. Место. где находятся истории, запланированные к выполнению к текущему релизу. Да, продукт должен быть готов к выпуску после каждого спринта, но это совсем не означает, что мы фактически выпускаем его. Наши спринты обычно длятся 5 дней.
• Sprint Backlog. Наш процесс планирования заключается в общении с целью чётко выяснить, что product owner хочет получить к завершению спринта. Как мы определяем, какой объём работы мы сможем выполнить и что мы не успеем? При помощи оценки историй (см. ниже). В результате планирования мы перемещаем какое-то количество историй из Release Backlog в Sprint Backlog. После этого вся команда координирует усилия. чтобы за отведённую неделю выполнить запланированное.
• Working On (в работе). Тут всё просто. Когда какой-либо участник команды берёт задачу в работу, он перемещает её из Sprint Backlog  в эту колонку, таким образом сообщая всем остальным, что работа над задачей началась. Очень важно, чтобы все члены команды могли всегда иметь актуальную информацию о состоянии проекта. На фото выше вы можете увидеть тонкие полоски с именами ответственных за задачу, прилепленные к квадратным бумажкам с историями.
• Done (выполнено). Сюда помещаются все выполненные истории. Однако очень важно чётко определиться с понятием «выполнено». В идеале, в конце спринта все истории и баги должны быть перенесены в эту колонку.

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

Что значит «сделано»

Действительно, когда можно сказать, что всё, задача завершена в полном объёме? Как узнать это? «Сделано» должно быть чётко-определённым понятием, чтобы в команде всегда было однозначное мнение на этот счёт. Суть этого понятия может отличаться от команды к команде, и даже от проекта к проекту. Не существует какого-то правила, высеченного на камне. Я советую вам поднять этот вопрос на одном из совещаний и однозначно решить со всей командой. как определить, что история выполнена. Могу подкинуть вам пару идей для начала:

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

Есть огромное количество вещей, которые могут занять место в списке определения термина «сделано». Выберите то, что подходит для вашей команды и пользуйтесь. Но не забывайте пересматривать это определение время от времени. Если вы заметите, что что-то устарело — выбрасывайте это, если появились новые идеи — добавляйте.

На фото выше зелёные листочки отражают то, что у нас входит в определение «сделано» для каждого этапа процесса.

Часть 2

Часть 3

Источник: Nettuts+

Что нового?

Первое, что вы обнаружите в новом релизе, это поддержку responsive дизайна в ядре, поскольку модуль, реализовывавший её ранее, был удалён. Теперь в самой концепции ядра фреймворка заложен принцип «Mobile First», используя который, интерфейс приложения проектируется сперва для маленьких экранов, затем бОльших (об этом чуть позже).

«Практически всё было переделано так, чтобы вы начинали проектирование c устройств с маленьким экраном.»

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

Grid System

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

Включение Grid System

Чтобы сетка имела возможность корректно функционировать и реагировать на touch zooming, необходимо в заголовок документа добавить дополнительный meta-тэг:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Ширина элементов сетки

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

• Extra small devices ~ Phones (< 768px)
• Small devices ~ Tablets (>= 768px)
• Medium devices ~ Desktops (>= 992px)
• Large devices ~ Desktops (>= 1200px)

Для каждой ширины существует свой CSS-класс:

• col-xs- ~ Extra small devices
• col-sm- ~ Small devices
• col-md- ~ Medium devices
• col-lg- ~ Large devices

Чтобы пользоваться сеткой, вам понадобится элемент-контейнер с классом "container", внутри которого необходимо использовать элементы с классом "row". Обратите внимание на то, что в отличие от Bootstrap 2, теперь не используется суффикс "fluid". Далее, уже внутри "row" необходимо размещать столбцы.

<div class="container">
    <div class="row">
        <div class="col-xs-6">col-xs-6</div>
        <div class="col-xs-6">col-xs-6</div>
    </div>
</div>

Как уже было замечено, третий Bootstrap следует концепции «Mobile First». Так, колонки с суффиксом "xs" всегда будут выстраиваться горизонтально, независимо от ширины экрана. Если вы воспользуетесь префиксом "md", то при ширине экрана менее 992px столбцы будут выстраиваться вертикально и становиться 100%-й ширины, как это показано в следующем примере:

<div class="container">
    <div class="row">
        <div class="col-md-4">col-md-4</div>
        <div class="col-md-4">col-md-4</div>
        <div class="col-md-4">col-md-4</div>
    </div>
</div>

При ширине экрана более 991px вы получите следующий результат:

А вот как поведёт себя эта разметка при ширине менее 992px:

Кроме того, вы можете комбинировать классы столбцов. Допустим, вам нужно, чтобы первые два столбца из предыдущего примера выстраивались друг за другом на Small Devices (sm), а на мобильных телефонах — вертикально, вам необходимо добавить класс col-sm-6 вдобавок к col-md-4.

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

Используя комбинирование классов, вы можете создавать довольно сложные структуры. Конечно же, Grid System вмещает в себя гораздо больше, чем мы рассмотрели, однако детальное рассмотрение каждого элемента не влезет в рамки одной статьи, поэтому не ленимся и идём читать документацию.

Bootstrap CSS

Большинство классов Bootstrap CSS остались теми же, однако всё же есть несколько изменений, которые нужно иметь ввиду.

Код был полностью переписан и были изменены имена переменных. если вы заглянете в less-файлы, вы заметите, что стиль именования переменных был изменён с camelCase на использование дефисов, а также имя каждой переменной было приведено к стандарту “element-state-pseudo state”. Это означает, что классы элементов вроде:

<ul class="unstyled">...</ul>

теперь стали иметь вид:

<ul class="list-unstyled">...</ul>

То же самое касается и списков с классом «inline». Среди прочих изменений имён классов, присутствуют классы, влияющие на размер элементов. Например, размер кнопок в версии 2.* регулировался следующим образом:

<button class="btn btn-mini"></button>
<button class="btn btn-small"></button>
<button class="btn btn-large"></button>

«Размерные» суффиксы были изменены таким образом, чтобы соответствовать общей схеме именования классов в Grid System:

<button class="btn btn-xs"></button>
<button class="btn btn-sm"></button>
<button class="btn btn-lg"></button>

То же самое применимо к input-элементам и определениям видимости элементов.

Responsive-таблицы

Общий синтаксис и внешний вид таблиц остался прежним, однако следуя принципам «Mobile First», новая версия Bootstrap предлагает responsive-таблицы. Чтобы воспользоваться новой функциональностью, необходимо воспользоваться классом table-responsive"", который делает таблицу горизонтально-прокручиваемой при ширине экрана менее 768px.

<table class="table-responsive">
    <table class="table">...</div>
</table>

Формы

О существенных изменениях в формах вы можете прочесть в соответствующем разделе документации. Во первых, каждый input-элемент теперь отображается как блочный элемент 100%-й ширины. Таким образом, «размерные» классы теперь регулируют padding элемента и размер шрифта, но никак не ширину самого элемента. Для того чтобы определить ширину input-элемента, вам необходимо будет завернуть его в контейнер с нужным классом модификатором ширины.

Сама разметка форм тоже изменилась. Самый простой вариант разметки формы во втором Bootstrap выглядел так:

<form>
    <fieldset>
        <legend>...</legend>
        <label for="input">...</label>
        <input type="text" name="input" placeholder="..." >
    </fieldset>
</form>

В новой версии добавился дополнительный элемент, а также новый класс для input-элементов:

<form role="form">
    <fieldset>
        <legend>...</legend>
        <div class="form-group">
            <label for="input">...</label>
            <input type="text" name="input" class="form-control" placeholder="..." >
        </div>
    </fieldset>
</form>

Как видите, у тега form появился атрибут role, поскольку Bootstrap разрабатывается с учётом поддержки пользователей с ограниченными возможностями. Также обратите внимание на то, что метки и input-элементы завёрнуты в дополнительный контейнер с классом form-group, что опять-таки сделано для реализации responsive-подхода.

В новой версии поисковая форма была упразднена, а поскольку все input-элементы теперь имеют 100% ширину по умолчанию, стоит отдельно обратить внимание на создание inline-форм, которые в принципе идентичны вертикальным:

<form class="form-inline" role="form">
    <div class="form-group">
        <label class="sr-only" for="email">Email address</label>
        <input type="email" class="form-control" placeholder="Enter email">
    </div>
    <div class="form-group">
        <label class="sr-only" for="pass">Password</label>
        <input type="password" class="form-control" placeholder="Password">
    </div>
    <div class="checkbox">
        <label>
            <input type="checkbox"> Remember me
        </label>
    </div>
    <button type="submit" class="btn btn-default">Sign in</button>
</form>

Обратите внимание на то, что кроме класса form-inline используется класс sr-only для меток полей. Имя этого класса является сокращением от «Screen Reader only», а  сам класс предназначен для того, чтобы метки скрывались при отображении, но могли быть считанными специальными приложениями.

В случае, когда вам нужно отобразить метку, вы можете воспользоваться классами col-* и control-label, так же как и в предыдущей версии, а затем завернуть input-элемент в отдельный колоночный контейнер:

<form class="form-horizontal">
    <div class="form-group">
        <label class="col-md-2 control-label" for="email">Email address</label>
        <div class="col-md-3">
            <input type="email" class="form-control" placeholder="Enter email">
        </div>
    </div>
</form>

Есть ещё несколько значительных изменений, коснувшихся форм. Среди них удаление классов “input-prepend” и “input-append” в пользу “input-group” и “input-group-addon“. Подробнее об этом вы можете узнать из документации.

Glyphicons

Следующая область изменений, которую мы рассмотрим — это пиктограммы. Во-первых библиотека иконок пополнилась сорока новыми, а также теперь вместо файлов-изображений представлена в виде набора файлов шрифтов. Таким образом, теперь вместо того, чтобы копировать два файла glyphicons-* в каталог img, вам необходимо скопировать четыре файла из fonts. Да, именно четыре, поскольку фреймворк выбирает нужный в зависимости от возможностей используемого браузера.

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

<span class="glyphicon glyphicon-user"></span>

Переход на использование шрифтов вместо изображений даёт возможность простого масштабирования и изменения цвета. Более того, вы можете легко заменить стандартный набор пиктограмм на любой, какой пожелаете, воспользовавшись чем-то вроде Fontello.

Компоненты JavaScript

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

Модальные диалоги

Возможно, это наиболее часто используемый компонент Bootstrap. Вы обнаружите. что в целом он остался неизменным, за исключением добавившейся обёртки из двух контейнеров modal-content и modal-dialog. таким образом, если вы раньше описывали модальный диалог так:

<div class="modal hide fade">
    <div class="modal-header"></div>
    <div class="modal-content"></div>
    <div class="modal-footer"></div>
</div>

То теперь он должен  выглядеть так:

<div class="modal fade">
    <div class="modal-content">
        <div class="modal-dialog">
            <div class="modal-header"></div>
            <div class="modal-content"></div>
            <div class="modal-footer"></div>
        </div>
    </div>
</div>

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

$('#my-modal').modal('show');

Остальные компоненты остались в том же виде. Правда, аккордеон был убран в пользу сворачивающихся панелей, которые работают так же, но при этом реализуются более простой разметкой. Имена некоторых классов немного изменились, и они всё ещё требуют transitions plugin. Плагин Typeahead был убран в пользу Typeahead от Twitter.

События

События JavaScript теперь помещены в пространства имён. Что это означает для вас? Например, во втором Bootstrap, чтобы прицепиться к событию close"" какого-то alert'а, вам нужно использовать примерно следующую конструкцию:

$('#my-alert').bind('close', function() {});

В новой версии фреймворка имена событий теперь разбиты по пространствам имён, таким образом предыдущий сниппет в третьем Bootstrap будет выглядеть так:

$('#my-alert').bind( 'close.bs.alert', function() {});

Не забудьте посетить страницу JavaScript-компонент и ознакомиться со всем набором. Также не забывайте. что jQuery всё ещё обязательна для работы их всех.

Новые компоненты

Появилась пара новых компонент в CSS-части фреймворка: группы списков и панели.

Группы списков

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

Для создания такого списка используется маркированный список с классом list-group"", элементы которого имеют класс list-group-item"":

<ul class="list-group">
    <li class="list-group-item">Lorem ipsum...</li>
    <li class="list-group-item">Dolor sit...</li>
</ul>

Если вам необходимо сделать элемент списка активным, наделите его классом active"". Если же вы поместите бэйдж внутри элемента, то бейдж будет автоматически центирован вертикально и помещён вправо.

Панели

Панели предназначены для того, чтобы поместить часть контента в отдельный контейнер и определённым образом выделить его. разметка панели очень проста и может включать в себя другие компоненты фреймворка. Панели имеют заголовок, подвал и могут наделяться хорошо известными вам классами “sucess“, “error“, “warning“ и т. п. Например:

<div class="panel panel-success">
    <div class="panel-heading">Panel Heading</div>
    <div class="panel-body"><p>Some content here</p></div>
    <ul class="list-group">
        <li class="list-group-item">Lorem ipsum...</li>
        <li class="list-group-item">Dolor sit...</li>
    </ul>
</div>

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

Конфигуратор

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

Поддержка браузеров

Много страданий всем нам принёс Internet Explorer, особенно шестая версия. Даже последующие версии всё ещё несут в себе наследие этого кошмара. Если в версиях 2.x разработчики Bootstrap ещё тратили силы на поддержку вплоть до седьмого Internet Explorer, то в третьем Bootstrap вы такого уже не увидите. То же самое касается и Mozilla Firefox версий 3.6 и ниже.

Текущая версия фреймворка рассчитана на современные версии популярных ныне бразузеров (Safari, Opera, Chrome, Firefox и IE).

Поддержка IE начинается с версии 8 и выше. Несмотря на то, что в восьмой версии нет поддержки некоторых свойств, вроде border-radius"". Фреймворк работает в полном объёме, за исключением некоторых отличий во внешнем виде. Помимо всего восьмая версия IE требует respond.js, чтобы поддерживать Media Querу.

Более подробную информацию о поддержке браузеров можно получить в официальной документации.

Итоги

С самого начал своего существования Bootstrap был отличным инструментом для создания интерфейсов веб-сайтов и приложений, и новая версия не изменила положения вещей в худшую сторону.

Если бы мне можно было назвать лишь одну причину для того, чтобы использовать новый Bootstrap, я бы определённо назвал новую Grid System. В современных реалиях, когда размеры экранов клиентских устройств колеблются от самых крошечных, до огромных, способность интерфейса приложения динамически адаптироваться к размеру экрана просто незаменима. И новый Twitter Bootstrap поможет вам с этим как нельзя лучше!

Источник: NetTuts+

Для того, чтобы объект мог быть итерирован в цикле foreach, для PHP необходимо, чтобы этот объект реализовывал интерфейс Traversable. Однако, вы не можете реализовывать этот интерфейс непосредственно, и вместо этого должны использовать любой из двух дочерних интерфейсов: Iterator или IteratorAggregate.

Iterator

Интерфейс Iterator предназначен для реализации классами, объекты которых могут быть интерированы непосредственно или использоваться для создания внешних итераторов. Интерфейс определяет пять методов для реализации: rewind(), current(), key(), next() и valid().

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

<?php
class Library implements Iterator
{
    // Внутренний указатель на текущую позицию указателя в коллекции
    protected $position = 0;

    // Данные
    protected $books = [
        "Professional PHP Programming",
        "Programming Perl",
        "A Byte of Python",
        "The Ruby Way"
    ];

    // Этот метод устанавливает внутренний указатель на начало коллекции
    // и используется для начала итерации
    public function rewind() {
        echo "rewinding <br>";
        $this->position = 0;
    }

    // Этот метод возвращает текущее значение указателя
    public function current() {
        echo "current <br>";
        return $this->books[$this->position];
    }

    // Этот метод возвращает текущую позицию указателя
    public function key() {
        echo "key <br>";
        return $this->position;
    }

    // Этот метод сдвигает указатель на следующий элемент
    public function next() {
        echo "next <br>";
        ++$this->position;
    }

    // Этот метод проверяет, есть ли данные относительно текущей позиции указателя
    public function valid() {
        echo "valid <br>";
        return isset($this->books[$this->position]);
    }
}

$library = new Library();
foreach ($library as $key => $value) {
    echo $key . ": " . $value . "<br>";
}

Вывод кода будет следующим:

rewinding 
valid 
current 
key 
0: Professional PHP Programming
next 
valid 
current 
key 
1: Programming Perl
next 
valid 
current 
key 
2: A Byte of Python
next 
valid 
current 
key 
3: The Ruby Way
next 
valid

Перед началом итерации PHP вызывает метод rewind(), чтобы установить указатель на начало данных. Затем при помощи вызова метода valid() он проверяет, есть ли данные по текущей позиции указателя. Если в ответ на вызов этого метода PHP получает true, то следующим шагом будет вызван метод current(), который вернёт данные, находящие относительно текущей позиции указателя. Если вы запросите ключ в конструкции foreach, то интерпретатор будет обращаться к методу key() вашего класса, чтобы получить его. Таким образом, итерация будет продолжнать до тех пор, пока объект не вернёт false в ответ на вызов метода valid().

Iterator позволяет создавать итераторы «с нуля» и отлично подходит для решения задач, вроде той, что мы только что рассмотрели. Конечно, приведённый пример очень простой, но его задачей как раз и является в простой и наглядной форме показать вам основные принципы работы класса Iterator. Однако, более лучшим решением для работы с данными вроде тех, что приведены в примере выше (обычный массив), будет другой класс — IteratorAggregate.

IteratorAggregate

IteratorAggregate требует реализации лишь одного метода, getIterator(). Этот метод должен возвращать внешний итератор, который и будет использоваться для выполнения итераций. Переписав наш пример с использованием IteratorAggregate, получим следующее:

<?php
class Library implements IteratorAggregate {
    protected $books = [
        "Professional PHP Programming",
        "Programming Perl",
        "A Byte of Python",
        "The Ruby Way"
    ];

    // Возвращаем Iterator
    public function getIterator() {
        echo "getIterator <br>";
        return new ArrayIterator($this->books);
    }
}

$library = new Library();
foreach($library as $key => $value) {
    echo $key . ": " . $value . "<br>";
}

В результате выполнения получим:

getIterator 
0: Professional PHP Programming
1: Programming Perl
2: A Byte of Python
3: The Ruby Way

Перед началом итераций интерпретатор PHP вызывает метод getIterator(), который возвращает Iterator; в нашем случае это ArrayIterator. А дальше работа происходит уже с полученным итератором таким образом, как это описано выше. То есть, вы передаёте свои данные внешнему итератору, он делает всю работу, а вы спокойно курите в сторонке.

Поскольку оба интерфейса выполняют одну и ту же задачу, иногда бывает трудно определиться, что же нужно использовать в конкретной ситуации. Правило большого пальца гласит: используйте Iterator тогда, когда вам необходимо создать сложный итератор «с нуля», с вашим собственным блэкджеком и куртизанками. В остальных случаях не морочьте голову и пользуйтесь готовыми SPL итераторами, заворачивая в них данные и реализуйте интерфейс IteratorAggregate.

Итоги

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

Источник: SitePoint

Если вы PHP-разработчик, вы однозначно пользовались массивами. А если вы пользовались массивами, то ещё более однозначно, что вы выполняли перебор их элементов в циклах. Взгляните на любой кусок кода и с огромной долей вероятности вы увидите там цикл foreach. Так вот, итерация — это всего лишь процесс обхода списка значений, а итератор — это объект, который выполняет сам процесс, будь то обход массива, списка файлов или даже результатов выборки из таблицы БД.

Это первая часть и двухсерийной статьи. В ней я расскажу вам об итерации и о преимуществах использования некоторых классов Standard PHP Library (SPL). В SPL присутствует огромное количество итераторов и их использование во многих случаях может сделать ваш код эффективнее и читабельнее.

Где и когда использовать итераторы SPL

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

Цикл foreach создаёт копию полученного массива. Если вы имеете дело с большими объёмами данных, такой подход не годится по очевидной причине: снижение производительности. Итератор SPL работает по другому: он обрабатывает один элемент итерируемого списка за раз, делая это куда более эффективно, нежели foreach.

При создании поставщиков данных (data providers) итераторы помогают сделать их более эффективными, предлагаю возможности ленивой загрузки (lazy loading). «Ленивая загрузка» означает то, что фактическое получение данных из источника выполняет только тогда, когда эти данные нужны. Помимо прочего, вы получаете возможность трансформации данных перед тем, как отдавать их клиенту объекта.

Однако ответ на вопрос «использовать итераторы или нет» остаётся полностью результатом вашего выбора. Итераторы имею массу полезных свойств, но в некоторых случаях (в частности, с маленькими объёмами данных) затраты на их применение будут неоправданными. В любом случае, выбор остаётся за вами. Всегда старайтесь рассмотреть максимальное количество факторов, прежде чем принимать решение.

Итерация массивов

Первый итератор, который я вам хочу представить — это ArrayIterator. Его конструктор принимает массив в качестве параметра, а сам объект предоставляет методы для выполнения итерационных операций. Вот пример работы с ArrayIterator:

<?php
// Сннтаксис создания массива, введённый в PHP 5.4
$arr = ["sitepoint", "phpmaster", "buildmobile", "rubysource",
    "designfestival", "cloudspring"];

// Создаём новый итератор ArrayIterator на основе массива
$iter = new ArrayIterator($arr);

// Итерируем
foreach($iter as $key => $value) {
    echo $key . ":  " . $value . "<br>";
}

В результате получим следующий вывод:

0: sitepoint
1: phpmaster
2: buildmobile
3: rubysource
4: designfestival
5: cloudspring

Вообще. обычно вы будете использовать ArrayObject в таких случаях, вместо непосредственного использовани ArrayIterator, поскольку первый позволяет работать с объектом как с массивом в определённых контекстах. ArrayObject создаёт ArrayIterator автоматически в случаях, когда вы используете ArrayObject в цикле foreach или вызываете ArrayObject::getIterator().

Имейте ввиду, что хотя ArrayObject и ArrayIterator ведут себя подобно массивам в контексте foreach, они всё-таки являются объектами. И если вы попытаетесь использовать с ними встроенные функции PHP вроде sort() and array_keys(), вы получите ошибку.

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

Традиционным решением для обхода многомерных массивов можно считать вложенные циклы. Например:

<?php
// Многомерный массив
$arr = [
    ["sitepoint", "phpmaster"],
    ["buildmobile", "rubysource"],
    ["designfestival", "cloudspring"],
    "not an array"
];

// Первый уровень
foreach($arr as $key => $value) {
    // Второй уровень
    if (is_array($value)) {
        foreach ($value as $k => $v) {
            echo $k . ": " . $v . "<br>";
        }
    }
    else {
        echo $key . ": " . $value . "<br>";
    }
}

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

0: sitepoint
1: phpmaster
0: buildmobile
1: rubysource
0: designfestival
1: cloudspring
3: not an array

С использованием RecursiveArrayIterator можно добиться более элегантного решения:

<?php
...
$iter = new RecursiveArrayIterator($arr);

// Итерируем объект.
// Для этого нам понадобится экземпляр RecursiveIteratorIterator
foreach(new RecursiveIteratorIterator($iter) as $key => $value) {
    echo $key . ": " . $value . "<br>";
}

Вывод этого кода будет таким же, как и в предыдущем случае.

Обратите внимание на создание экземпляра RecursiveIteratorIterator и передачу ему объекта RecursiveArrayIterator. В противном случае вы получите только значения массива первого уровня и ряд уведомлений об ошибках.

Вам следует использовать RecursiveArrayIterator в случаях, когда имеете дело с многомерными массивами, поскольку он отлично справляется с рекурсивным обходом вложенных массивов. Однако, если в процессе обхода массива ему встретится итерируемый объект, то его обход — это уже ваша задача. Вот для этого случая и предназначен RecursiveIteratorIterator, который по сути является декоратором. В качестве аргумента он получает RecursiveArrayIterator, итерирует его, а также любой объект, реализующий интерфейс Iterable. Для того, чтобы в процессе итерации знать, на какой глубине в данный момент находится итератор, можно использовать метод RecursiveIteratorIterator::getDepth(). Будьте внимательны, работая с RecursiveArrayIterator и RecursiveIteratorIterator, когда имеете дело с объектами. Любой объект, реализующий Iterable, будет итерироваться тоже.

Итерация каталога файловой системы

Несомненно, любой программист время от времени сталкивается с необходимостью получения списка файлов в каталоге. Существует множество способов сделать это, используя, например, встроенные PHP-функции scandir() или glob(). Помимо них, вы также можете воспользоваться классом DirectoryIterator. Он довольно мощный сам по себе, но в случае необходимости вы можете его наследовать и расширять по своему усмотрению. Рассмотрим небольшой пример:

<?php
$dir = new DirectoryIterator("/my/directory/path");
foreach ($dir as $item)
    echo $item . "<br>";

Неплохо для двух строчек кода? И не забывайте, что вдобавок вы теперь можете пользоваться исключениями:

<?php
try {
    $dir = new DirectoryIterator("/non/existent/path");
    foreach ($dir as $item) {
        echo $item . "<br>";
    }
}
catch (Exception $e) {
    echo get_class($e) . ": " . $e->getMessage();
}

UnexpectedValueException: DirectoryIterator::__construct(/non/existent/path,/non/existent/path): The system cannot find the file specified. (code: 2)

Используя множество полезных методов вроде DirectoryIterator::isDot(), DirectoryIterator::getType() и DirectoryIterator::getSize(), вы можете получить практически всю информацию, которая только потребуется.

Если пойти дальше, то вы можете воспользоваться DirectoryIterator в связке с FilterIterator или RegexIterator, чтобы фильтровать результаты так. как вам нужно. Например:

<?php
class FileExtensionFilter extends FilterIterator
{
    // Разрешённые исключения
    protected $ext = ["php", "txt"];

    // Реализация абстрактного метода
    public function accept() {
        return in_array($this->getExtension(), $this->ext);
    }
}

// Создаём новый итератор
$dir = new FileExtensionFilter(new DirectoryIterator("./"));
...

SPL также предлагает RecursiveDirectoryIterator, который может быть использовать в точности, как и RecursiveArrayIterator. В отличие от встроенных функций, RecursiveDirectoryIterator делает множество дополнительной работы за вас, что позволяет создавать более чистый и понятный код. Заранее хочу вас предупредить об одной особенности: RecursiveDirectoryIterator не возвращает пустых каталогов. Даже если каталог содержит вложенные подкаталоги, но ни в одном из них не будет файла, то такой каталог считается пустым и не будет возвращён (в точности так же ведёт себя Git).

<?php
$iter = new RecursiveDirectoryIterator("/my/directory/path");

// Обходим содержимое каталога.
// Для этого нужен экземпляр RecursiveIteratorIterator
foreach (new RecursiveIteratorIterator($iter) as $item) {
    echo $item . "<br>";
}

Итоги

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

SPL — это «стандартная» библиотека. Иной раз вам может оказаться недостаточно функциональности отдельных её классов. В таких случаях вы всегда можете расширять эти классы и наделять их необходимыми вам функциями. В следующей статье я расскажу вам об использовании SPL-интерфейсов при создании ваших собственных классов, которые могут итерироваться так же. как и обычные массивы.

Источник: SitePoint

Основные понятия функционального программирования

Начнём с определения. Википедия сообщает, что

«Функциональное программирование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).»

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

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

О'кей, вернёмся к этому позже, а пока что рассмотрим несколько ключевых понятий функционального программирования.

Неизменность

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

Рекурсия

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

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

<?php
function sum($array) {
    if (empty($array))
        return 0;
    else
        return $array[0] + sum(array_slice($array, 1));
}

$total = sum(array(1, 2, 3)); // 6

Чистые функции и ссылочная прозрачность

Если функция не изменяет внешних по отношению к ней объектов, в том числе и не выполняет никаких операций ввода-вывода (в файл, базу данных, etc), то такую функцию называют «функцией без побочных эффектов» или «чистой функцией». Так, например, все математические функции являются чистыми, в то время как функции вроде date () и rand () — нет.

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

Функции высшего порядка

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

Лямбда-функции

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

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

$("#myButton").click(function () {
    // Работа
});

PHP обзавёлся лямбда-функциями с выходом версии 5.3, и это предоставило возможность разработчиком создавать конструкции вида:

<?php
$square = function ($arg) {
    return $arg * $arg;
};

$value = $square(2); // 4

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

Замыкания

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

<?php
$rate = .12;

$findInterest = function ($value) use ($rate) {
    return $value * $rate;
};

$interest = $findInterest(100);

Частичные функции и карринг

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

<?php
$volume = function ($length = 0, $width = 0, $height = 0) use (&$volume) {
    $args = func_get_args();
    $numArgs = func_num_args();
    if ($numArgs == 3) {
        return $length * $width * $height;
    }
    else if ($numArgs < 3) {
        return function() use(&$volume, $args) {
            $newArgs = array_merge($args, func_get_args());
            return call_user_func_array($volume, $newArgs);
        };
    }
    else {
        throw new BadFunctionCallException("Too many arguments");
    }
};

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

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

<?php
$standardVolume = $volume(10);
$vol = $standardVolume(5, 5); // 250

Карринг — это частный случай частичных функций, при котором функция, принимающая несколько аргументов, преобразуется в несколько функций, каждая из которых принимает один аргумент. То есть, вместо f (x,y,z) будет f (x)(y)(z) (хотя синтаксис PHP этого и не позволяет). Если вам интересны подробности реализации данного подхода, обратитесь к статье Timothy Boronczyk о карринге в PHP.

Преимущества и недостатки

Существует множество способов применения функционального программирования в PHP. Например, лямбда-функции широко применяются в качестве callback-функций. Так, например, в Slim Framework вы можете определить действие для роута следующим образом:

<?php
$app = new SlimSlim();
$app->get("/home", function() {
    // Вернуть содержимое домашней страницы
});

Не так давно Vance Lucas опубликовал обзор некоторых интересных вариантов использования лямбда-функций.

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

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

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

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

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

Итоги

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

Источник: SitePoint

Роутинг

Хотя в теории MVC должен отлично работать при разработке архитектуры любых систем, применительно к разработке веб-приложений обычно появляются некоторые дополнительные сложности. Первая проблема — это роутинг URLов. Роутинг это то, что не принималось во внимание, когда разрабатывался паттерн MVC, поскольку веба в то время попросту не существовало.

Итак, какие есть варианты решения проблемы роутинга? Один из вариантов решения состоит в том, чтобы заранее определить URL, на которые должно отзываться ваше приложение, и описать в базе данных или файле конфигурации необходимые для обработки каждого URL контроллер, модель и представление. Это вполне подходящее решение в случае, если вы разрабатываете статический веб-сайт вроде портфолио, где не требуется использование динамических URL. Ниже приведён пример кода, реализующий подобное решение:

<?php
$page = $_GET['page'];
if (!empty($page)) {
    $data = array(
        'about' => array('model' => 'AboutModel', 'view' => 'AboutView', 'controller' => 'AboutController'),
        'portfolio' => array('model' => 'PortfolioModel', 'view' => 'PortfolioView', 'controller' => 'PortfolioController')
    );

    foreach($data as $key => $components) {
        if ($page == $key) {
            $model = $components['model'];
            $view = $components['view'];
            $controller = $components['controller'];
            break;
        }
    }

    if (isset($model)) {
        $m = new $model();
        $c = new $controller($model);
        $v = new $view($model);
        echo $v->output();
    }
}

Таким образом, URLы вашего приложения будут выглядеть так:

example.com/index.php?page=about
example.com/index.php?page=portfolio

Приведённый выше пример MVC-системы загружает необходимую связку модель-представление-контроллер в зависимости от значения GET-параметра 'page'.

Хотя приведённых пример прост для понимания и реализации, всё же он обладает рядом недостатков. Самым очевидным и критическим является то, что приложение не готово к масштабированию, поскольку оно стеснено жёстко-закодированным набором обрабатываемых URL.

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

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

<?php
$model = $_GET['model'];
$view = $_GET['view'];
$controller = $_GET['controller'];
$action = $_GET['action'];

if (!(empty($model) || empty($view) || empty($controller) || empty($action))) {
    $m = new $model();
    $c = new $controller($m, $action);
    $v = new $view($m);
    echo $v->output();
}

Таким образом, теперь наше приложение будет принимать URL вида:

example.com/index.php?controller=controllername&model=modelname&view=viewname&action=actionname

В параметре 'action' передаётся имя метода контроллера, который необходимо вызвать. Обратите особое внимание на то, что этот метод передаёт часть данных модели, которая в свою очередь определяет, какое представление и какое его действие (метод) использовать. Это может быть значение параметра 'action' или данные полученные контроллером, или что-либо другое. Важно одно: никогда не позволяйте контроллеру напрямую передавать данные в представление. Контроллер может работать только с моделью и пользовательским вводом.

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

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

Если ко всему прочему воспользоваться паттерном Front Controller, то вы получите полный контроль над загрузкой данных во время обработки запроса. Alejandro Gervasio написал неплохую статью о паттерне Front Controller, освещающую основную идею паттерна в связке с концепцией MVC. Автор также рекомендует к ознакомлению сайт Tom Butler — идеальное чтиво для тех, кто желает разобраться в принципах построения системы динамического роутинга в контексте MVC.

DRY

Ключевым аргументом в пользу использования MVC является возможность ясной организации структуры создаваемой системы за счёт минимизации дублирования кода. Любой хороший разработчик придёт в ужас, увидев в исходных кодах одно и то же в разных местах. Практика построения чистого кода, повторно используя имеющиеся компоненты настолько, насколько это возможно, следует философии DRY — Don't Repeat Yourself.

Принцип DRY гласит: «каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы». Целью DRY является мотивировать разработчика проектировать и строить каждый аспект системы так, чтобы в результате получить логически организованное, гибкое и легко расширяемое решение. Если вы заметили, что дублируете код, расположенный в другой части системы, создайте метод, содержащий этот код, и используйте его вызов везде, где вам это потребуется. Таким образом вы сможете создать оптимальную систему, готовую использованию кэширования, что в свою очередь позволит сократить время её работы.

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

Темплейты

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

Чтобы было понятней, о чём речь, рассмотрим коротенький пример загрузки шаблона в представлении и передачи ему данных:

<?php
class Model {
    public $tstring;

    public function __construct(){
        $this->tstring = "The string has been loaded through the template.";
        $this->template = "tpl/template.php";
    }
}

<?php
class View {
    private $model;

    public function __construct($model) {
        $this->controller = $controller;
        $this->model = $model;
    }

    public function output() {
        $data = "<p>" . $this->model->tstring ."</p>";
        require_once($this->model->template);
    }
}

<!DOCTYPE html>
<html>
 <head>
  <meta charset="charset=utf-8">
  <title>The Template name</title>
 </head>
 <body>
  <h1><?php echo $data; ?></h1>
 </body>
</html>

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

Заключение

Паттер MVC в своё время оказал большое влияние на процесс разработки десктоп-приложений. Он был и по сей день является горячей темой для обсуждения среди разработчиков. Споры разгораются тем больше, когда речь заходит об использовании его в контексте PHP-приложений, и это является хорошим знаком того, что PHP-разработчики тянутся к прекрасному, стараясь применять лучшие принципы в своей работе. Если вы всё ещё не знакомы с MVC, пожалуйста, потратьте немного своего драгоценного времени на его изучение. Вы не пожалеете!

Источник: SitePoint

Хотя изначально MVC был спроектирован для разработки десктоп-приложений, он был адаптирован для современных задач и пользуется у веб-разработчиков огромной популярностью, поскольку за счёт разделения ответственности стало возможным создавать более ясный, готовый к повторному использованию код. Паттерн MVC приводит к созданию ясных, модульных систем, что позволяет разработчикам очень быстро вносить изменения в существующий код.

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

Понимание MVC

Как уже было сказано, название паттерна происходит от аббревиатуры трёх слов: Model (модель), View (представление) и Controller (контроллер). Вкратце принцип работы паттерна можно проиллюстрировать одной схемой (оригинальный вариант можно найти на Википедии):

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

Модель

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

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

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

Представление

Представление — это то, где данные, полученные от модели, выводятся в нужном виде. В традиционных веб-приложениях, разработанных в рамках MVC-паттерна, представление — это часть системы, где выполняется генерация HTML-кода. Представление также отвечает за получение действий от пользователя с тем чтобы отправить их контроллеру. Например, представление отображает кнопку в пользовательском интерфейсе, а после её нажатия вызывает соответствующее действие контроллера.

Существуют некоторые заблуждения относительно предназначения представления, особенно в среде веб-разработчиков, которые только начинают строить свои приложения с использованием MVC. Одним из наиболее часто нарушаемых правил является то, что представление никоим образом не должно общаться с моделью, а все данные, получаемые представлением должны поступать только от контроллера. На практике же разработчики часто игнорируют эту концепцию, стоящую в основах MVC-паттерна. В статье Fabio Cevasco The CakePHP Framework: Your First Bite наглядно показан этот сбивающий с толку подход к MVC на примере фреймворка CakePHP, одним из многих нестандартных MVC-фреймворков:

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

Помимо этого, существует распространённое заблуждение о том, что представление — это просто темплейт-файл. Как заметил Tom Butler, это заблуждение имеет огромный масштаб из-за того, что многие разработчики с самого начала неправильно понимают структуру MVC, после чего начинают вливать эти «знания» дальше, массы начинающих разработчиков. В действительности представление — это гораздо больше, чем просто темплейт, однако много фреймворков, построенных на базе MVC-паттерна, настолько исказили концепцию представления, что уже всем пофигу, насколько правильными являются их приложения с точки зрения MVC-паттерна.

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

Контроллер

Контроллер — это последняя часть связки MVC. Задачей контроллера является получение данных от пользователя и манипуляция моделью. Именно контроллер, и только он, является той частью системы, которая взаимодействует с пользователем.

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

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

MVC в PHP

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

<?php
class Model {
    public $string;

    public function __construct() {
        $this->string = "MVC + PHP = Awesome!";
    }
}

<?php
class View {
    private $model;
    private $controller;

    public function __construct($controller, $model) {
        $this->controller = $controller;
        $this->model = $model;
    }

    public function output() {
        return "<p>" . $this->model->string . "</p>";
    }
}

<?php
class Controller {
    private $model;

    public function __construct($model) {
        $this->model = $model;
    }
}

Основные классы готовы. Теперь давайте свяжем их вместе и запустим наше приложение:

<?php
$model = new Model();
$controller = new Controller($model);
$view = new View($controller, $model);
echo $view->output();

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

Давайте немного расширим приложение, добавив немного интерактивности, чтобы увидеть, как работает контроллер:

<?php
class Model {
    public $string;

    public function __construct() {
        $this->string = “MVC + PHP = Awesome, click here!”;
    }
}

<?php
class View {
    private $model;
    private $controller;

    public function __construct($controller,$model) {
        $this->controller = $controller;
        $this->model = $model;
    }

    public function output() {
        return '<p><a href="mvc.php?action=clicked"' . $this->model->string . "</a></p>";
    }
}

<?php
class Controller {
    private $model;

    public function __construct($model) {
        $this->model = $model;
    }

    public function clicked() {
        $this->model->string = “Updated Data, thanks to MVC and PHP!”
    }
}

И в завершение немного модернизируем связующий код:

<?php
$model = new Model();
$controller = new Controller($model);
$view = new View($controller, $model);

if (isset($_GET['action']) && !empty($_GET['action'])) {
    $controller->{$_GET['action']}();
}

echo $view->output();

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

Итоги

В этой небольшой статье мы рассмотрели основные концепции шаблона проектирования MVC и разработали простенькое приложение на его базе, хотя конечно, нам ещё очень далеко до того, чтобы использовать это в реальной жизни. В следующей статье мы рассмотрим основные затруднения, с которыми вы столкнётесь, если плотнее займётесь построением архитектуры приложения на базе MVC-паттерна. Stay tuned!

Источник: SitePoint

Основным достоинством Glances является её ориентированность на консоль, поскольку мониторинг в 99% случаев необходим на серверах. Вторым плюсом сего чуда является возможность работы в клиент-серверном режиме. Ну и мелкие плюшки, вроде цветовой подсветки превышения пороговых значений и ведения логов, также придают некоторого шарма. Итак, утилита позволяет выполнять мониторинг в одном окне:

• использование CPU;
• Load Average;
• использование RAM и Swap;
• битрейт интерфейсов;
• данные сенсоров (только в Linux);
• битрейт ввода-вывода;
• использование ФС;
• информацию о процессах;

Установка

Согласно информации на гитхаб-странице проекта, на сегодняшний день утилита присутствует в пакетных репозиториях Debian (SID), Arch, Fedora, Redhat и FreeBSD. Если же вам по каким-то причинам необходимо установить Glance платформо-независимым способом, то можно воспользоваться штатным Python-установщиком PIP. Пример для Denian/Ubuntu:

sudo apt-get update
sudo apt-get install python-pip build-essential python-dev
sudo pip install Glances

Ну и, если вы хотите установить утилиту где-нибудь на Mac или Windows, не поленитесь ознакомиться с соответствующими инструкциями.

Запуск и работа

В standalone-режиме Glance запускается без ключей, если только вы не хотите изменить таймаут обновления данных, который по умолчанию равен одной секунде. Если вы хотите умерить пыл Glance, можно увеличить этот параметр при запуске:

glances -t 5

Ну и, собственно, вот она:

Зелёным цветом выделены показания, находящиеся в пределах нормы. Далее, в порядке возрастания критичности значения показателя используются цвета: синий, пурпурный и красный.

Горячие клавиши

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

• 'a' включает автоматическую сортировку списка процессов:
  • если CPU IoWait > 60%, то сортировка выполняется по активности ввода-вывода;
  • если CPU > 70%, то сортировка выполняется по занимаемому процессорному времени;
  • если MEM > 70%, то процессы сортируются по занимаемому объёму памяти;
• 'b' переключает отображение сетевой активности между битами/сек и байтами/сек;
• 'c' сортирует процессы в порядке убывания потребления процессорного времени;
• 'd' включает/отключает отображение блока статистики дискового ввода-вывода;
• 'f' включает/отключает отображение данных о смонтированных ФС;
• 'h' показывает справку по горячим клавишам;
• 'i' сортирует процессы по активности ввода-вывода;
• 'l' включает/отключает отображение лог-сообщений;
• 'm' сортирует процессы по объёму занимаемой памяти;
• 'n' включает/отключает отображение сетевой статистики;
• 'p' сортирует процессы по имени;
• 's' включает/отключает отображение статистики сенсоров (работает только после вызова Glances с флагом '-e');
• 'w' удаляет неактуальные лог-сообщения типа warning;
• 'x' удаляет неактуальные лог-сообщения типа warning и critical;
• '1' переключает отображение процессорной статистики между общим и поядерным представлениями;
• 'q' завершает работу программы.

Лог-сообщения

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

Запуск в клиент-серверном режиме

Glances умеет работать в режиме клиент-сервер, таким образом вы можете избавиться от необходимости подключаться по SSH каждый раз. Для того, чтобы запустить Glances на сервере, используйте флаг -s:

glances -s

после чего можете подключиться клиентом:

glances -s @server

заменив @server на имя хоста или IP-адрес сервера.

По умолчанию утилита цепляется на все интерфейсы, на порт 61209. Если вам необходимо привязать Glances к другому интерфейсу, используйте флаг -B:

glances -B 192.168.0.1

Для переопределения TCP-порта предназначен флаг -p:

glances -p 16666

Начиная с недавно вышедшей версии 1.6 вы можете указать пароль подключения:

glances -P mysupersecret

Для коммуникаций Glances использует стандартный XML/RPC, таким образом желающие могут сообразить для Glances и собственный фронтенд.

Больше информации

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

Доля Android 2.3 «Gingerbread» уменьшилась с 47% до 45.6%; такими темпами эта версия исчезнет с графиков не ранее чем через два с половиной года. Её предшественница, Android 2.2 «Froyo», всё ещё занимает около 8.1% рынка Android-устройств, что на 0.9% меньше, чем в начале января.

Судя по всему, осталось лишь несколько месяцев до того, как использование Android 4.x станет доминировать над предыдущими версиями.

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

На Turpial я наткнулся, как всегда, совершенно случайно и решил попытать счастья ещё разик. На деле же он оказался просто замечательным, несмотря на всё ещё активный девелопмент и заявление разработчиков, что мол, сырое всё. Ха, делают вид, что Gwibber не видели. Ну да ладно, к делу.

Turpial написан на Python и может использовать как Qt, так и GTK для работы GUI. На сегодняшний день он умеет работать с API Twitter и Identica (второе, вероятно, мало кому нужно, но тем не менее), обладает минималистичным интерфейсом и таким же набором опций конфигурации. Короче, просто прелесть!

Информацию о том, как установить Turpial в своём дистрибутиве, вы можете найти на соответствующей странице проекта, а в ArchLinux счастливые пользователи могут установить сие чудо следующим образом:

pacman -Sy
pacman -S turpial

После первого запуска Turpial предложит вам указать ваши данные для авторизации и выбрать сервис (Twitter или Identica):

Для тех, кто нуждается в работе приложения через прокси-сервер, справа вверху есть кнопочка дополнительных настроек подключения, вызывающая соответствующий диалог:

После нажатия кнопки Connect, вам будет предложено авторизовать приложение через Twitter API:

После того, как авторизуете приложение и получите PIN-код, введите его в строке ниже и нажимайте ОК:

После этого Turpial сможет подключиться к вашему Twitter-аккаунту и теперь можно приступать к общению!

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

Также есть возможность переключить приложение в «широкий» формат, хотя с трудом представляю, кому это может понадобиться:

Помимо чтения ленты Turpial предлагает ряд контекстных действий над сообщениями:

Править профиль учётной записи:

Обновлять статус:

Управлять избранным:

Загружать изображения:

И ещё несколько полезных мелочей.

Как уже было сказано, набор опций настроек минимален, но лично мне кажется, его более чем достаточно. Из интересного: вы можете настроить частоту обновления каждой вкладки в основном окне, включить минимизацию в трей, активировать «расширение» сокращённых URL:

«заглушить» отдельных особей:

И отфильтровать слова, которые вы не хотите видеть:

В общем, всем, кому нужен хороший, лёгкий и не падающий каждые три минуты десктопный twitter-клиент, очень и очень рекомендую!