Archive for the ‘Development’ Category

Авто редирект из http в https в Zend Framework

Written by Yaroslav Vorozhko on July 1, 2009 – 1:32 pm -

Привет,
Следующий Helper решает проблему редиректа из http страници на https.
Скажем надо перейти от http://mysite.com/action/param/ на https://mysite.com/action/param/

PLAIN TEXT
PHP:
  1. class My_Helper_SslSwitch extends Zend_Controller_Action_Helper_Abstract
  2.     {
  3.         public function direct()
  4.         {
  5.             if (!isset($_SERVER['HTTPS']) || !$_SERVER['HTTPS']) {
  6.                 $request    = $this->getRequest();
  7.                 $url        = 'https://'
  8.                             . $_SERVER['HTTP_HOST']
  9.                             . $request->getRequestUri();
  10.                 $redirector = Zend_Controller_Action_HelperBroker::getStaticHelper('redirector');
  11.                 $redirector->gotoUrl($url);
  12.             }
  13.         }
  14.     }

Автор хелпера Matthew Weier O'Phinney

Далее в bootstrap добавляем путь к Helper в include_path
и вызываем его, таким образом мы переводим весь сайт на использование https.

PLAIN TEXT
PHP:
  1. Zend_Controller_Action_HelperBroker::addPrefix('My_Helper');
  2. $ssl = new My_Helper_SslSwitch();
  3. $ssl->direct();

Если же вам надо включить SSL только для определенных контроллеров, то вы можете поместить следующий код в preDispath() метод контроллеров.

PLAIN TEXT
PHP:
  1. $this->_helper->sslSwith();

В данном случае мы используем объект _helper для создания объекта sslSwith и вызова метода direct().
Note: Метод direct() вызыватеся автоматически для всех Action Helpers.


Tags: , , ,
Posted in Development, PHP, Tips And Tricks, ZendFramework | No Comments »

Скрипт верификации сайта

Written by Yaroslav Vorozhko on June 21, 2009 – 2:00 pm -

Приветствую!
Предлагаю на обсуждения простой скрипт проверки принадлежности (верификации) сайта, его владельцу.

Предполагается, что владелец сайта поместил специальный meta тег в head секцию на корневой странице сайта, т.е. на home page.
Формат meta тега следующий:
<meta name="vf_key" content="29693426cfd334d8287783b49217e64f"/>

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

Функция верификации следующая:

PLAIN TEXT
PHP:
  1. /**
  2. * Function return true if verfication is successed
  3. *@param $url string - it is valid url address
  4. *@param $metaValue - string it is special code which placed as content for verification meta tag
  5. **/
  6.         public function verifyMetaTag($url, $metaValue)
  7.     {   
  8.         // we know what $url is valid url
  9.  
  10.                 //get html of the page with Zend http client
  11.         $client = new Zend_Http_Client($url, array(
  12.             'maxredirects' => 0,
  13.             'timeout'      => 30)
  14.         );
  15.         $response = $client->request();
  16.                 if (!$response){
  17.                        return false;
  18.                 }
  19.        
  20.         $html = $response->getBody();
  21.        
  22.         $headPos = strpos($html, '</head>');
  23.         $metaPos = strpos($html, $metaValue);
  24.  
  25.                 //close head section must be below our meta tag
  26.         if ($metaPos> $headPos){
  27.             return false;
  28.         }
  29.        
  30.         $htmlHead = substr($html, 0, $headPos);
  31.  
  32.                 //grab all meta tags in head section into array
  33.         preg_match_all("#<meta(.*)>#", $htmlHead, $matches);
  34.        
  35.                 //checking all meta tags on special key and value pairs
  36.         foreach ($matches[1] as $meta){
  37.                      //meta tag must have key "vf_key" and value "$metaValue"
  38.             if (strpos($meta, 'vf_key') && strpos($meta, $metaValue)){
  39.                 return true;
  40.             }
  41.         }
  42.         return false;
  43.     }

Есть ли у этого метода недостатки или может есть более простой вариант?


Tags: , ,
Posted in Development, PHP, Tips And Tricks | 8 Comments »

Интеграция SCRUM и Eventum или идеи по улучшению процесса разработки ПО

Written by Yaroslav Vorozhko on June 3, 2009 – 11:04 pm -

Интеграция SCRUM и Eventum или идеи по улучшению процесса разработки ПО

Это руководство написано для компаний которые активно используют Eventum и у которых есть желание перейти на гибкие методики разработки ПО, например на SCRUM.

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

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

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

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

SCRUM является одной из таких современный и проверенных методик разработки.

Узнать что такое SCRUM и XP вы можете посетив следующие веб-ресурсы:

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

Описывать как работать с Eventum я не буду, вы можете прочитать об этом на их официальной странице http://eventum.mysql.org/wiki/index.php/Main_Page.

Внедряем SCRUM в существующий процесс разработки

Для этого потребуются некоторые изменения:

  • ведения задач в Eventum;
  • подсчета времени;
  • планирования этапов разработки.

Требования:

  • Наличие Backlog;
  • Наличие Sprintlog;
  • Наличие Tasklog;
  • Планирование спринта (Sprintlog);
  • Ежедневные конференции;
  • Sprint Information.
  • Sprint report;

Backlog и Sprintlog

Backlog и Sprintlog — это отдельный Eventum project (скажем Project_Log), который будет содержать все истории для реализации.

История — это не техническое описание задачи. Истории в Backlog заносит владелец продукта. Он же меняет им приоритеты сортирую истории по важности.

Истории помеченные номером спринта владелец продукта менять уже не может.

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

Каждая история в backlog/sprintlog должна иметь следующие поля:

  • номер спринта (поле Category или Custom field) — для указания номера спринта к которому принадлежит история, если история не принадлежит ни одному спринту, то это поле не заполняется. ;
  • название (поле Summary);
  • описание (поле Description)
  • важность (поле Custom field);
  • предварительная оценка (поле est. dev time);
  • как продемонстрировать(поле Custom field или поле Description);

В Eventum есть специальная возможность создавать «произвольные поля» Custom fields, что добавлет большой гибкости этой системе.

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

Предварительная оценка ставиться владельцем продукта.

Поле «как продемонстрировать» заполняется программистами.

Список историй в Backlog/Sprintlog может выглядеть следующим образом:

  • Номер спринта
  • Номер истории
  • Статус — (Планируется, В процессе, Завершена)
  • Название истории
  • Важность
  • Как продемонстрировать
  • Предварительная оценка
  • Предварительная дата завершения истории

Во время планирования спринта заполняются следующие поля:

  • Номер спринта
  • Предварительная дата завершения истории
scrum backlog

scrum backlog

Tasklog

Tasklog — является еще одним проектом Eventum (например с названием Projects_task).

Tasklog содержит список технических задач, который создаются на основе историй из Sprintlog.

С помощью поля Associated issues, каждая задача в Tasklog помечается как дочерняя по отношению к истории из Sprintlog. И главное в SCRUM - задачи в Tasklog составляют программисты.

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

  • Номер задачи
  • Статус — Открыта, Выполняется, Сделана.
  • Название задачи
  • Assigned — кто ответственен за выполнение
  • Estimate dev time - Предварительная оценка времени
  • Time spent - Потраченное время

Estimate dev time должно обязательно заполнятся при создании задачи.

Time spent должно обязательно указываться после каждого цикла работ над задачей.

Scrum task log

Scrum task log

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

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

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

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

В итоге получается план работ на следующие 2-3 недели. Что является большим плюсом.

Задачи в Sprintlog беруться из Backlog по приоритету важности, чем важнее задача тем быстрее она попадет в следующий спринт.

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

Каждая задача в Sprintlog имеет свои подзадачи в Tasklog, задачи из Tasklog решаются непосредственно программистами, дизайнерами, тестерами.

Ежедневные конференции

Ежедневные конференции требуются для обсуждения текущих задач.

Sprint information

Sprint info — это список всех прошедших спринтов, он соджержит:

  • номер спринта
  • название
  • прогнозируемое время выполнения
  • реальное время выполнения
  • общую эффективность команды
  • участников команды

Для ведения Sprint info хватит обычной wiki.

Sprint report

Sprint report - это текущее состояние дел по текущему спринту.

Scrum dashboard

Scrum dashboard

В итоге

В итоге мы получаем:

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

Tags: , , ,
Posted in Development, Product Search, Основы разработки | No Comments »
« Older Entries