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

Сегодня 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-ленту.!

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

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

Padraic Brady опубликовал замечательную статью о том, как сделать свой собственный twitter клиент с использованием Zend`овских библиотек Zend_OAuth и Zend_Service_Twitter. Рекомендую к прочтению:

Writing A Simple Twitter Client Using the PHP Zend Framework’s OAuth Library (Zend_Oauth)

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

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

Для получения уникальных записей массива в PHP есть функция array_unique();

Если элементами массива могут быть массивы, то я использую следующую функцию:

function func_array_unique($array) {
    $result = array();
    // Идея в том, что если исходный массив
    // содержал совершенно одинаковые элементы,
    // md5(serialize($value)) будет для них одинаковым
    foreach($array as $value) {
        $result[md5(serialize($value))] = $value;
    }
    // Очищаем ключи массива
    return array_values($result);
}

Выручает частенько, может и вам кому пригодиться.

Понравился пост? Будь в курсе последних событий: подпишись на 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-ленту.!

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

Спонсор поста: Боитесь стоматологов? Доверьтесь профессионалам! Стоматология в Москве - филиалом Американской стоматологической клиники (Сакраменто, Калифорния) - лучшие специалисты в своей области.

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

С этого момента могу работать с составлением официального договора. Хотя, как показывает практика единичным заказчикам такой договор не нужен. Но сейчас веду переговоры с несколькими заказчиками, которым я буду обеспечивать постоянную поддержку проектов (в основном корпоративные блоги). С такими обязательно буду заключать договора.

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

1. “Назначил” сам себе заработную плату. По окончанию каждого месяца, буду переводить эту сумму себе на дебетовую карточку и пользоваться. Это будет обычные затраты моего “предприятия”. А прибыль (разница доходов и расходов) будет реинвестироваться в дело.

2. Начал вести учет финансов фирмы отдельно от моих личных.

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

Естественно, использовать 1С для этих целей нет никакой надобности. Пересмотрел несколько программ для учета личных финансов. Хотелось что-нибудь удобное, серьезное и бесплатное. “Серьезное” имеется ввиду, лишенное “внутренних”, встроеных в программу и навязаных пользователю стратегий работы с деньгами - всякие пенсионные счета, которые нельзя удалить, ограничение уровня вложености статей доходов и т.д.

Остановился я на AbilityCash. Программа удобная и интуитивно понятная. По функционалу стандартная: счета, доходы\расходы\переводы, валюты, отчеты и графики. Для учета личных финансов вполне подходит, а вот для учета работы предприятия не очень.. Все упирается в особенности ее предназначения.  Поэтому пришлось подставить свои костыли

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

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