вторник, 13 июля 2010 г. - www.msmirnov.ru

Количество багов в единицу времени

Сегодня решил провести небольшое исследование - выбрал из багтрекера количество багов, которые были созданы по проекту начиная с ноября 2004 года (т.е. почти за 6 лет).
Получил вот такой график:



Что видим на графике:
1. Четко видны пики и падения, соответствующие выходам релизов продукта. На самом деле, было бы правильно выбрать данные не по месяцам, а хотя бы по неделям, но их тогда будет слишком много, трудно будет анализировать.
2. Скорость поступления багов находится в одним и тех же рамках уже довольно давно.
Думаю это связано с примерно одинаковым объемом изменений, поставляемых в каждом релизе, а так же с примерно постоянным количеством членов проектной группы.
Мой сайт - www.msmirnov.ru

воскресенье, 11 июля 2010 г. - www.msmirnov.ru

Летний Аналитический Фестиваль-2010. День 2

Только что завершился второй день Летнего Аналитического Фестиваля conf.uml2.ru, который проходил в Центре Отдыха "Малинки" недалеко от Иваново.

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

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

Следующий стол обсуждал вопрос "Где должны готовить аналитиков". Эта тема вызвала очень жаркие споры, особенно благодаря тому, что на обсуждении присутствовал представитель Ивановского Государственного Химико-технологического Университета. Высказывались претензии у ВУЗам о том, что они не достаточно хорошо готовят специалистов системного анализа. В свою очередь представитель ВУЗа говорил, что ВУЗ дает основу, базу. А дальше - обязанность компаний.

Затем был проведен мастер-класс по разработке спецификации требований для вымышленного проекта. Мастер-класс, на мой взгляд, был несколько спорый. Я, честно говоря, ожидал от него несколько большего.

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

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

P.S.S. Запомнилось несколько интересных фраз:
- На собеседовании: Почему ты решил стать аналитиком? Потому что я плохой программист.
- У аналитика хорошо развиты комуникативые навыки. Так почему-бы ему не поработать сэйлом?
- Аналитики не нужны. Они только мешают программистам работать. А тестеры потом еще и баги пишут, что программисты не так накодили, как аналитики наанализировали.
- Анализируй визуально. Визуализируя анализируй.
- All you need is ЛАФ
Мой сайт - www.msmirnov.ru

суббота, 10 июля 2010 г. - www.msmirnov.ru

Летний Аналитический Фестиваль-2010

Сегодня прошел первый день Летнего Аналитического Фестиваля 2010 в г. Иваново (ЛАФ 2010) conf.uml2.ru, организованного сообществом системных аналитиков www.uml2.ru, на котором ваш покорный слуга имел место быть.
Проходил ЛАФ в центре Иваново в довольно уютном бизнес-центре.
Всего на фестивале присутствовало около 90 человек из разных городов.

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

Из всех докладов, которые мне удалось посетить, наиболее интересными мне показались следующие:
  1. Тестирование требований: Зачем - понятно, а вот Как?
    http://conf.uml2.ru/class/testirovanie-trebovanii-zachem---ponyatno-a-vot-kak.html

    Докладчик Нечаева Юлия (jnechaeva.blogspot.com) рассказала о своем опыте внедрения процесса тестирования требований в своей компании.

    Видео-запись доклада доступна здесь:



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

  2. Написание тестов, как вид тестирования требований
    http://conf.uml2.ru/class/napisanie-testov-kak-vid-testirovaniya-trebovanii.html

    Весьма харизматичный (в хорошем смысле слова) докладчик Мартыненко Сергей blog.shumoos.com рассказал о своем видении определения требований через изначальное определение тестов к требованиям (этакий TDD для требований).

    Особенно запомнились три его тезиса:
    - Первый вопрос, с которого надо начать общение с потенциальным заказчиком: "Как вы поймете, что проект успешен?"
    - Второй вопрос: "Кто кому и как будет сдавать проект?"

    Видео пока на сайте нет, но я думаю что будет.
    Как  появится - добавлю ссылку.
  3. Практика работы с требованиями в иностранной компании, или In Wiegers We Trust
    http://conf.uml2.ru/class/praktika-raboty-s-trebovaniyami-v-inostrannoi-kompanii-ili-in-wiegers-we-trust.html

    Докладчик Белин Александр рассказал о своем опыте формализации процесса управления требованиями в крупной международной компании.

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

    Видео пока тоже, к сожалению, не выложено - еще просто не успели. А доклад был очень интересным. Как появится - помещу сюда ссылки.
Всего было около 15-ти докладов, из которых удалось побывать на 8-ми.
Фотографировать, к сожалению, возможности не было, так как фотоаппарат сейчас в Шарье у Кати с Лидой. Надеюсь завтра скину у кого-нибудь из участников фотки. Если получиться, то опубликую.

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

А теперь спать, а то завтра опять дорога 200 км.

P.S. Город Иваново понравился - красивый, чистый, дороги хорошие, девушки симпатичные. Очень понравился.
P.P.S. Пообедали весьма отменно.
Мой сайт - www.msmirnov.ru

вторник, 6 июля 2010 г. - www.msmirnov.ru

Опыт организовации ротации Destination URLs для PPC-объектов

В этом посте я помещаю свою заметку"Опыт организовации ротации Destination URLs для PPC-объектов", опубликованную некоторое время назад на Хабре (http://michael-e-smirnov.habrahabr.ru/blog/97853/)

Введение.


Как известно, объекты PPC-поисковых систем (как правило, это keywords и ads) имеют
такой параметр, как Destination URL (целевой URL), который содержит в себе ссылку
на страницу, рекламируемую посредством платной рекламы.
Было необходимо организовать ротацию Destination URL таким образом, чтобы они последовательно
менялись друг за другом для большого количества PPC-объектов (миллионы ключевых
слов) на различных поисковых системах (Google, Yahoo, MSN, Baidu, ASK и др.).

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

Можно было просто обновлять целевые URL'ы по определенному графику, использую API
поисковых систем, но это также не могло решить проблему по нескольким причинам:
  • Многие поисковые системы (например Baidu или Yahoo) после изменения URL'ов ставят
    изменения в состояние ожидания (Pending) и тратят значительное время (до нескольких
    суток) на их проверку.
  • На Google это приводило бы к дополнительным расходам на Google Developer Token.
  • Baidu не позволяет применять URL'ы, если их домены не находятся в списке заранее
    разрешенных доменов. Поэтому смена урлов URL'ов затруднена.
  • Google обнуляет статистику по Ad’ам, если у них изменить URL, потому что внутренне
    для Google это означает создание нового Ad’а.
  • Даже при отсутствии этих проблем все равно остается проблема быстрого обновления
    большого количества объектов – т.е. если мы имеем миллионы ключевых слов, мы не
    сможем мгновенно отправить изменения на любую поисковую систему.
  • Кроме того, связь через интернет не всегда является надежной – бывают обрывы связи
    между провайдерами, сами API поисковым систем периодически глючат и т.п


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

Решение.


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

Т.е. посетитель попадает на промежуточный сервер, а затем перенаправляется на целевой
URL. Для посетителя это происходит практически незаметно.
Целевые URL’ы были объединены в группы, в пределах которых осуществлялась ротация.
В свою очередь идентификатор группы был указан в целевом URL’е для PPC-объектов.
Т.е. URL’ы ключевых слов и Ad'ов на поисковой системе имели примерно следующий вид:
my_redirect_server.ru/?rotation_group_id=123456
При попадании посетителя на промежуточный сервер происходила ротация целевых URL’ов
и посетитель перенаправлялся на выбранный URL. Ротация происходила с учетом временных
настроек целевых URL’, а также других настроек (частота отображения и т.п.).
Благодаря такому решению задача была решена.

Подводные камни.


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

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

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

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

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

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

Поскольку ротацию требовалось выполнять максимально быстро, Rotation service работал
исключительно на закешированных данных групп и текущего состояния ротации. При изменении
настроек Rotation service уведомлялся о необходимости обновить кеш.
Благодаря такому подходу обеспечивалась высокая скорость выбора целевого URL’а.
Еще одна проблема при обеспечении высокой скорости работы – это сохранение отчетных
данных, которое нельзя было выполнять в синхронном режиме.
Поэтому был реализован механизм, при котором сервера накапливали отчетные данные
в памяти и с периодичностью в несколько минут сбрасывали их в фоновом режиме на
сервер сбора статистики.

Еще одной проблемой стало обеспечение высокой скорости работы при географической
удаленности посетителей и серверов редиректа.
При работе с Baidu основная часть посетителей находилась в Китае и они испытывали
трудности при редиректе через сервера, которые располагались в Европе. Эта проблема
была решена установкой дополнительного сервера в Китае.

Заключение.


Описанное выше решение было запущено в эксплуатацию несколько лет назад и с тех
пор обеспечивает обработку до 100 миллионов запросов ежемесячно, хотя потенциал
решения значительно выше.
Мой сайт - www.msmirnov.ru