Опубликовано: Алексей Качаев | 2 комментария

К хорошему привыкаешь быстро. Так и получилось с шаблонизатором Zend FW (Zend_View, Zend_Layout) и всевозможными ViewHelper`ами.

После прочтения вот этого поста: Убираем дублирование при добавлении роутинга, об использовании констант в шаблонах Live Street, понял что такая архитектура вьевера не удобна не только мне. Хочу поделиться своими соображениями на этот счет.

Автор статьи правильно заметил, что при добавлении нового роута приходиться дублировать информацию. Но, на самом деле здесь происходит более «серьезное» дублирование, чем копипаст из config/config.route.php в Viewer.class.php — мы дублируем функционал по составлению пути — один раз это делает программист, разрабатывая модуль, второй раз это делает верстальщик, когда делает шаблон. Большее неудобство не в том, как мы доставим константу во Viewer, а именно в том факте, что верстальщику этими константами нужно пользоваться.

Если нам вдруг понадобиться изменить принцип роутинга, то придется перелапачивать весь шаблон, исправляя ошибки адресов. Имхо, если Router, решает какой Action должен отработать, пусть сам нам скажет, как к этому Action нужно обратиться. Тогда необходимость в константах во Viewer`e вообще отпадет сама собой.

Для себя я решил проблему с помощью дополнительной функции в классе роутера и специально под это дела написаного Smarty-плагина. Подробнее об этом решении читайте здесь - “Убираем константы из шаблонов“.

А мораль из этого такова: Кто сеет - Тот и жнет. Иначе организационных проблем будет просто завал.

Спонсор поста:
“Экономная” мебель для офиса

Понравился пост? Будь в курсе последних событий: подпишись на RSS-ленту.!

Опубликовано: Алексей Качаев | 2 комментария

Еще с начала этого года приглядывался к Live Street (официальный сайт) - Open Source CMS для создания блого-социальных сервисов (на подобие Хабра). Проект очень динамичный и перспективный, но сама система еще в юношеском состоянии  Тем интереснее - больше работы с мозга.

Последний месяц ввиду производственной необходимости познакомился с этим движком намного теснее - разрабатывал три модуля под заказ - “Гараж”, “Объявления”, “JS Loader”. В процессе работы над модулями внес свою лепту в рост проекта и влился в общение разарботчиков на самом livestreet.ru. Написал три статьи с описанием своих хаков и доработок.

Представляю их вам.

[Читать далее...]

Понравился пост? Будь в курсе последних событий: подпишись на RSS-ленту.!

Опубликовано: Алексей Качаев | Комментариев нет

Сегодня Zend Developer Zone оповестила о выходе ZF 1.9. Сейчас переходить на новую версию нет времени, обязательно сделаю это на следующей неделе - тогда и поделюсь впечатлениями. Новый Zend ориентирован на PHP 5.3.0 (вышедшего месяц назад), но будет нормально работать и на более старых версиях PHP.

Изменения и нововведения коснулись:

1. Zend_Rest_Route, Zend_Rest_Controller и Zend_Controller_Plugin_PutHandler;

2. Zend_Feed_Reader;

3. Zend_Db_Table;

4. Zend_Date, Zend_Locale и Zend_Translate;

5. Zend_View_Helper_BaseUrl;

6. Zend_Test_PHPUnit_Db;

7. Zend_Dojo;

8. Zend_Pdf;

9. Zend_Log_Writer_Syslog;

Подробнее об этих и других “фичах”  - читаем здесь.

Понравился пост? Будь в курсе последних событий: подпишись на RSS-ленту.!

Опубликовано: Алексей Качаев | 4 комментария

Спонсор поста: “Медсервис-М” - круглосуточная стоматологическая клиника в центре Москвы: демократичные цены и профессиональные специалисты.

Говоря простым языком, Issue Tracking — процесс учета/отслеживания/решения проблем, возникающих в программе, обработка запросов на изменение, неточности, улучшения и т. д. Наиболее важная часть этого процесса - Bug Tracking - подразумевает обработку ошибок и неточностей.

Из своего опыта работы с различными заказчиками выношу несколько полезных советов.

Совет #1. Issue Tracking - “работа для двоих” (заказчика и исполнителя).

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

Совет #2. Используйте специальные инструменты.

Таких, слава богу, создано очень много. Ознакомиться с полным (?) списком можно здесь - “Comparison of issue tracking systems“, заодно почитать о преимуществах и недостатках каждой.

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

В работе с заказчиком важно, чтобы баг-трекер был интуитивно понятен пользователю (заказчик не должен быть ни программистом, ни тестером, он вообще может слабо в компьютерах разбираться:)) и, что самое главное, доступен в сети. Поэтому локально установленный вам вряд ли поможет. Я остановился на таком варианте: http://www.assembla.com, которая дает возможность бесплатно вести публичный проект\ты. Если у вас в баг-трекере ничего серьезного не планируется держать, то это вполне подойдет.

Совет #3. Расставляйте приоритеты.

Отмечайте высоким приоритетом те баги и\или доработки, которые нужно закрыть срочно (в ближайшее время), и наоборот низким - то, что можно оставить на потом. При этом обязательно прислушивайтесь к заказчику! Вы смотрите на проект с точки зрения разработчика, поэтому некоторые моменты могут показаться вам не существенными (например, точки в отображении даты нужно заменить на слеши), а для заказчика они очень важны. Пусть это не имеет никакого основания - но ни в коем случае не игнорируйте такие вещи! Если заказчик поставил высокий приоритет, и вы с ним не согласны - объясните ему свою точку зрения и выслушайте его. Договоритесь - снижайте приоритет, не договоритесь - лучше закройте баг сразу.

Совет #4. Заносите в список багов даже те проблемы, которые тут же устраняете.

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

Совет #5. Разделяйте задачи.

Система Trac предлагает по умолчанию 3 вида тикетов (Type): defect, task, enhancement. На практике этого вполне достаточно для большинства проектов, и именно таким набором я пользуюсь. Уверен, не стоит объяснять какие тикеты для каких задач используются :).

Совет #7. Указывайте ревизии.

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

Понравился пост? Будь в курсе последних событий: подпишись на RSS-ленту.!

Опубликовано: Алексей Качаев | 8 комментариев

В одном из предыдущих постов, я уже писал, что мне иногда приходят на почту и в аську вопросы от читателей по поводу тех или иных вопросов разработки. Иногда простые, иногда посложнее. Но так или иначе, у меня уже “подсобралось” коллекция вопросиков и ситуаций “на догадку”. Назову их по аналогии из бизнеса “PHP - кейсами”. Периодически я буду публиковать наиболее показательные из них. Я не буду брать дословные вопросы из своей переписки с читателями. Скорее всего это будут некие абстрактные примеры в стиле “foo-bar” и “MyCar-YouCar”.

Если вы часто в практике встречаетесь с подобными “PHP-кейсами” - присылайте или оставляйте в комментариях!

Итак, начнем с простого, но очень полезного для новичков PHP ООП.

PHP-Кейс #1. Классы и переменные

Рассмотрим простейший код:

/**
 * @project  PHP-Case #1.  
 * @author   Alex Kachayev
 *               http://www.kachayev.ru
 */
$car_1 = 'Merce';
$car_2 = $car_1;
 
$car_1 = 'Boing';
 
print $car_2;

Даже в детском саду вам скажут, что на экран будет выведено

Merce

Изменение в первой переменной, никак не отобразилось на второй.
Рассмотрим теперь другую ситуацию.

/**
 * @project  PHP-Case #1. 
 * @author   Alex Kachayev
 *               http://www.kachayev.ru
 */
 
class Car
{
    public $model;
 
    public function __construct( $model )
    {
        $this->model = $model;
    }
}
 
$myOwnCar = new Car('BMW');
print 'My car: '. $myOwnCar->model ."\n";
 
/**
 * Даю тебе машину, такую же как моя :)
 */
$youCar = $myOwnCar;
 
/**
 * У нас с тобой одинаковые модели
 */
print 'You car: '. $youCar->model ."\n";
 
/** 
 * Мне надоело BMW, собираю все деньги, покупаю Астон Мартин
 */
$myOwnCar->model = 'Aston Martin';
print 'My new car: '. $myOwnCar->model ."\n";
 
/**
 * Посмотрим, какая машина у тебя?
 */
print 'You new car: '. $youCar->model ."\n";

Итак, что мы получим на выходе? Вот ответ:

My car: BMW
You car: BMW
My new car: Aston Martin
You new car: Aston Martin

Почему мы получили именно такой результат… Думаем и читаем мануалы :).

Давайте пойдем еще дальше, и дополнил наш кейс новым кодом: предположим мой машина разбилась…

/**
 * Разбиваем мою машину :)
 */ 
$myOwnCar = null;
 
/**
 * Посмотрим теперь на наши машины
 */
var_dump($myOwnCar);
var_dump($youCar);

Что получим на выходе? Вот такое вот “жизненное безобразие”:

My car: BMW
You car: BMW
My new car: Aston Martin
You new car: Aston Martin
NULL
object(Car)#1 (1) {
["model"]=>
string(12) “Aston Martin”
}

Т.е. твоя машина - как новенькая, а от моей только дырка от руля осталась :).

Клонирование

А если на практике мне понадобиться сделать “независимую копию объекта класса”? Для этого можно можно (и нужно) использовать clone.
[Читать далее...]

Понравился пост? Будь в курсе последних событий: подпишись на RSS-ленту.!