Одним из главных направлений деятельности нашей компании является разработка систем онлайн-рекламы. За время существования «Грамант» мы выполнили несколько проектов в этой области. В последние годы до России докатился бум RTB-технологий, которые развиваются на Западе уже 5 лет. В настоящее время мы, как специалисты в сфере онлайн-рекламы, участвуем в разработке нескольких систем в сегменте SSP/RTB/DSP.

Сегодня исполнительный директор «Грамант» Анатолий Филин встретился с Артемом Вольфтрубом, руководившим большей частью «баннерных» проектов нашей компании, для того, чтобы обсудить наш опыт в баннерных системах, а также — то, как они в целом развиваются в общемировой тенденции. Читать дальше »

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

Shopium: интервью с руководителем проекта

В процессе работы над системой видео-хостинга часто возникают сложные технические задачи. Исполнительный директор «Грамант» Анатолий Филин захотел разобраться в том, как была на этом проекте решена проблема оптимизации доставки видео на десктопные и мобильные устройства. Для этого, он пригласил разработчиков Александра Кистанова и Андрея Лебедева, и системного инженера Дениса Елданди, и они за «круглым столом» обсудили появившиеся сложности.

Оптимизация доставки видео на десктопные и мобильные устройства

Структура и основные принципы написания технических заданий для различных созданных нами проектов, сочетание в них бизнес-требований и функциональных требований, описание основных ролей и пользовательских сценариев, «рисование ТЗ», и многое другое, вы найдете в разделе «Техническое задание. Принципы написания» на нашем сайте.

Техническое задание. Принципы написания.

FRD и нефункциональные требования

Зачастую в практике системного аналитика, составляющего FRD, встречаются вещи неформализуемые. Примером могут быть требования типа:

  • Приложение должно работать быстро
  • Приложение должно потреблять мало трафика
  • Видеоматериал должен быть качественным.

Такие требования, будучи записанными в FRD «как есть», являются чудовищным источником проблем впоследствии. Формализация таких требований — постоянная головная боль аналитика. Обычно аналитик решает задачу в два приема: сначала выдвигается «эквивалентное» формальное требование, затем в процессе общения (с заказчиком, экспертом предметной области и т.п.) доказывается, что такое формальное требование может заменить собой исходное требование. Вообще говоря, полученное нами требование не является функциональным; оно описывает не «что» должна уметь делать система, а «как делать». При этом «как делать» должно быть сформулировано с конкретной качественной характеристикой.

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

О задаче классификации

Предположим, что мы пишем FRD для системы контекстной рекламы, похожей на Amazon Omakase. Одним из модулей нашей будущей системы будет контекстный анализатор:
Читать дальше »

Geb на практике

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

На нашем видео-пректе при отдаче видео с серверов возникает вопрос производительност дисковой подсистемы. Очевидно, что гигабитные сетевые интерфейсы обладают большей производительностью, чем, скажем, RAID0 из 2х дисков. И если бы видео-ролики обладали одинаковой популярностью, то диски являлись бы узким местом при отдаче контента.
Однако же, нам повезло и всегда есть небольшой набор роликов, которые делают 80% трафика, и длинный хвост с редкой посещаемостью. Этот небольшой набор оседает в кеше файловой системы и отдается практически без дисковой активности.
Например, если у нас на сервере лежит 100 гигабайт роликов, а памяти на сервере 24 гигабайта, то мы можен нарисовать такой график. По горизонтали у нас будут «файлы», отсортированные по популярности, по вертикали — трафик, порождаемый этими файлами. Суммарный трафик — площадь поверхности под графиком.

filesystemcache

С другой стороны, всегда стоит вопрос, сколько памяти на сервер лучше поставить и как померять hit/miss ratio. В этом посте мы рассмотрим, как это можно сделать.
Читать дальше »

Зачем нужен deploy-скрипт

Grails-приложения очень легко собираются в WAR. Делается это так:

grails war

Помимо того, что WAR собирается, очень хочется этот WAR еще и установить на сервер. В нашем случае это Tomcat. Установка вручную требует некоторой возни:

  1. Остановить сервер. Убить процесс, если он не остановился сам.
  2. Удалить старые файлы приложения (на всякий случай)
  3. Скопировать новый WAR на сервер. Иногда его нужно переименовывать (скажем, в ROOT.war)

В Maven эту работу может проделать, например, cargo plugin. Но с ним много приключений и настройки, причем он не особо учитывает особенности сервере.

Мы также можем использовать shell-скрипт. Но зачем писать на неудобном языке shell, когда есть замечательный кроссплатформенный язык Groovy?

Читать дальше »

На прошлой неделе состоялась конференция «Российские интернет-технологии», на которой мы о нашем опыте работы с потоковым видео и защите видео контента.

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

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

В частности мы показали что популярные протоколы «защищенного» потокового видео, такие как RTMPE, не дают гарантии сохранности контента от нелегального копирования. Любые существующие DRM системы принципиально не могут обеспечить 100% защиты.

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

Наши выступления можно посмотреть тут

На прошлой неделе состоялась конференция «Российские интернет-технологии», на которой мы рассказывали о практике написания ТЗ, которую мы успешно применяем на наших проектах.

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

  1. Динамичная среда — интернет очень быстро меняется, постоянно появляются новые технологии, и то, что было популярным и модным несколько месяцев назад, сегодня уже не так актуально.
  2. Конкурентный рынок — в битве за аудиторию важно выйти на рынок как можно раньше, опередив конкурентов.
  3. Основной источник информации пользователи — практика показывает, что даже детальная проработка ТЗ, включая создание пользовательских групп, предварительное тестирование и т.п., не так полезна, как обратная связь от пользователей, которая может быть получена только после выхода первой версии системы. К тому же на полноценное исследование, как правило, нет времени (см. пункты 1,2)

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

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

По нашем мнению, у традиционных, «бумажных», ТЗ есть две основные проблемы:

  1. «Слишком много букв». Заказчики неохотно читают большие документы. Конечно, отчасти это вопрос их заинтересованности в результате, но, тем не менее, такая проблема реальна.
  2. Словесное описание интерфейса по-разному интерпретируется участниками процесса. Это самая большая проблема. Поскольку в веб системах значительную часть составляет пользовательский интерфейс (который, к слову, может быть весьма сложным и навороченным), основная задача этого документа — сформировать в головах заказчика и разработчиков одинаковое представление о том, как должна выглядеть система. К сожалению, словесное описание оставляет слишком большой простор для фантазии, поэтому результат в 99% случаев не соответствует представлению.


001

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

Например, такие:

002

Это позволяет решить следующие проблемы:

  1. Сокращается объем ТЗ. Его гораздо легче читать, поддерживать в актуальном состоянии и отслеживать изменения.

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

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

Полную презентацию доклада можно посмотреть на Slideshare.net

  • Sharing

    Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather