Архив автора
Ротация размещений
В первой части были описаны общие принципы по вычислению ёмкостей рекламных мест. На каком-то этапе мы получили оценку ёмкости по любым комбинациям переменных таргетирования. Для построения финального прогноза этих данных недостаточно. Ведь на одном рекламном месте может происходить ротация нескольких размещений. Таким образом, чтобы рассчитать прогноз какого-то размещения, нужно знать все размещения, которые в будущем будут конкурировать с ним на данном рекламном месте. Более того, добавление нового размещения в систему влияет на прогноз всех остальных пересекающихся с ним размещений (понятно, что вновь добавленное размещение «отнимет» у остальных часть трафика).
Достаточно сложно обозначить какую-то общую схему, по которой мы можем произвести расчет. Проблема в том, что правила ротации в разных баннерных системах сильно различаются. Зачастую эти правила диктуются особенностями бизнеса (например, наличие приоритетных размещений, способных полностью «захватить» трафик). (далее…)
Теги: ad tech, forecast, прогноз, рекламные системы, ротация, таргетирование
Задача прогнозирования трафика
При создании рекламной системы очень важно предоставить рекламодателям возможность прогнозирования рекламного трафика. Такой прогноз дает пользователю понимание:
- Реально ли открутить нужное число показов в планируемые сроки
- Каков потенциал размещения баннера на данном рекламном месте с данными условиями таргетирования.
Прогноз предоставляют практически все современные системы размещения (Google AdWords, OpenX, Яндекс.Директ), правда, обычно без упоминания качества прогноза. Поговорим более детально о том, как можно построить систему прогнозирования и от чего будет зависеть качество прогноза.
(далее…)
Теги: ad tech, forecast, баннерные системы, прогноз, ротация, таргетирование
FRD и нефункциональные требования
Зачастую в практике системного аналитика, составляющего FRD, встречаются вещи неформализуемые. Примером могут быть требования типа:
- Приложение должно работать быстро
- Приложение должно потреблять мало трафика
- Видеоматериал должен быть качественным.
Такие требования, будучи записанными в FRD «как есть», являются чудовищным источником проблем впоследствии. Формализация таких требований — постоянная головная боль аналитика. Обычно аналитик решает задачу в два приема: сначала выдвигается «эквивалентное» формальное требование, затем в процессе общения (с заказчиком, экспертом предметной области и т.п.) доказывается, что такое формальное требование может заменить собой исходное требование. Вообще говоря, полученное нами требование не является функциональным; оно описывает не «что» должна уметь делать система, а «как делать». При этом «как делать» должно быть сформулировано с конкретной качественной характеристикой.
Это была преамбула к тезису о том, что системный аналитик должен хорошо владеть математическим аппаратом и заодно уметь объяснять «математику» заказчику. А теперь рассмотрим пример.
О задаче классификации
Предположим, что мы пишем FRD для системы контекстной рекламы, похожей на Amazon Omakase. Одним из модулей нашей будущей системы будет контекстный анализатор:
(далее…)
Теги: f1, f1 score, precision, recall, задача классификации, машинное обучение
Geb на практике
Я вот, скажем, люблю, когда всю работу за меня делают роботы. Поэтому считаю необходимым всякие скрипты, inspections, проверщики орфографии и, разумеется, автоматические тесты. (далее…)
Теги: geb, grails, groovy, java, jquery, selenium, spock, WebDriver
Зачем нужен deploy-скрипт
Grails-приложения очень легко собираются в WAR. Делается это так:
Помимо того, что WAR собирается, очень хочется этот WAR еще и установить на сервер. В нашем случае это Tomcat. Установка вручную требует некоторой возни:
- Остановить сервер. Убить процесс, если он не остановился сам.
- Удалить старые файлы приложения (на всякий случай)
- Скопировать новый WAR на сервер. Иногда его нужно переименовывать (скажем, в
ROOT.war)
В Maven эту работу может проделать, например, cargo plugin. Но с ним много приключений и настройки, причем он не особо учитывает особенности сервере.
Мы также можем использовать shell-скрипт. Но зачем писать на неудобном языке shell, когда есть замечательный кроссплатформенный язык Groovy?
(далее…)
Теги: deploy, gant, grails, groovy, java, jsch, scp, ssh, tomcat, war
Вступление
Тернист и извилист путь Java-платформы к правильному способу записи строчек в лог-файлы. История logging в Java довольно познавательна в плане изучения особенностей Open Source, в том числе его взаимодействия с корпорациями и единичными программистами. Я собираюсь рассказать столько, сколько возможно, об истории развития Java logging, а также о том, к чему все пришло и как жить дальше. (далее…)
Теги: commons-logging, java, java.util.logging, JUL, log4j, logback, logging, SLF4J
AJAX и все, все, все
В предыдущей серии мы делали простенькое Grails-приложение с использованием jQuery, а также решили для себя, что использовать jQuery в Grails можно и даже нужно. Обсудим более серьезные вещи, которые можно сделать с такой связкой.
Нетрудно заметить, что все больше сайтов используют AJAX и частичные обновления страниц, причем в невероятном количестве. В частности, «начиненные» AJAX ссылки могут использоваться для внутренней навигации по странице, переключения каких-то вкладок. Это хорошо тем, что
А) меньше данных нужно перегонять от сервера — только нужный кусок страницы и
Б) веб-страницы часто загружают просто гигантские CSS и JavaScript-файлы, которые при AJAX-обновлении можно повторно не загружать.
Итак, очень распространено построение приложений по сценарию: одна большая «стартовая» страница, загружающая весь JavaScript-код и CSS и более мелкие «внутренние» функциональные блоки, загружаемые через AJAX. С этим есть ряд проблем:
- В результате AJAX-действий внутреннее состояние страницы не отражено в адресной строке браузера.
- Как следствие, внутренние страницы не могут быть запомнены в закладки, нельзя «отправить ссылку другу».
- Не работает Back/Forward навигация в браузере, т.к. AJAX-ссылки не попадают в историю браузера.
Однако крупные сайты нашли некое «хакерское» решение, которое мы сейчас рассмотрим и напишем небольшой свой собственный аналог на Grails и jQuery. (далее…)
Теги: AJAX, grails, groovy, javascript, jquery
Жизнь устроена так, что показывать и обрабатывать цифровое видео всегда сложнее, чем цифровые фото:
- Видео-контент занимает гораздо больше места.
- Все манипуляции с видео (сжатие, масштабирование, перекодировка) требуют неизмеримо больше ресурсов, чем преобразование фото.
- Из-за большего объема контента суммарный видео-трафик сильно перегоняет трафик всех остальных ресурсов, да еще и требует хорошей пропускной способности.
(далее…)
Теги: codecs, hosting, transcoding, video, youtube
Объемы данных и требования к скорости их обработки за последние десятилетия многократно выросли. Системы управления базами данных (СУБД) пытаются соответствовать новым реалиям и претерпевают значительные эволюционные и революционные изменения. Одним из таких эволюционных факторов является движение в сторону т.н. вертикальных (column-based) систем хранения.
(далее…)
