...

суббота, 20 августа 2016 г.

Немного про кино или как делать интерактивные визуализации в python


Введение


В этой заметке я хочу рассказать о том, как можно достаточно легко строить интерактивные графики в Jupyter Notebook'e с помощью библиотеки plotly. Более того, для их построения не нужно поднимать свой сервер и писать код на javascript. Еще один большой плюс предлагаемого подхода — визуализации будут работать и в NBViewer'e, т.е. можно будет легко поделиться своими результатами с коллегами. Вот, например, мой код для этой заметки.


Для примеров я взяла скаченные в апреле данные о фильмах (год выпуска, оценки на КиноПоиске и IMDb, жанры и т.д.). Я выгрузила данные по всем фильмам, у которых было хотя бы 100 оценок — всего 36417 фильмов. Про то, как скачать и распарсить данные КиноПоиска, я рассказывала в предыдущем посте.



Визуализация в python и plotly


В python есть много библиотек для визуализации: matplotlib, seaborn, портированный из R ggplot и другие (подробнее про инструменты можно почитать тут или тут). Есть среди них и те, которые позволяют строить интерактивные графики, например, bokeh, pygal и plotly, о котором собственно и пойдет речь.


Plotly позицинируется как online-платформа, где можно создавать и публиковать свои графики. Однако, эту библиотеку можно использовать и просто в Jupyter Notebook'e. К тому же у библиотеки есть offline-mode, который позволяет использовать ее без регистрации и публикации данных и графиков на сервер plotly (документация).


В целом, мне библиотека очень понравилась: есть подробная документация с примерами, поддержаны разные типы графиков (scatter plots, box plots, 3D графики, bar charts, heatmaps, дендрограммы и т.д.) и графики получаются достаточно симпатичными.


Примеры


Теперь настало время перейти непосредственно к примерам. Как я уже говорила выше, весь код и интерактивные графики доступны в NBViewer'e.


Библиотеку легко установить c помощью команды: pip install plotly.


Прежде всего, необходимо сделать import'ы, вызвать команду init_notebook_mode для инициализации plot.ly и загрузить в pandas.DataFrame данные, с которыми будем работать.


from plotly.offline import download_plotlyjs, init_notebook_mode, plot, iplot
import plotly.graph_objs as go

init_notebook_mode(connected=True)

df = pd.read_csv('kp_all_movies.csv') #скачиваем подготовленные данные
df.head()


Сколько фильмов выходило в разные годы?


Для начала построим простой bar chart, показывающий распределение фильмов по году выпуска.


count_year_df = df.groupby('movie_year', as_index = False).movie_id.count()

trace = go.Bar(
    x = count_year_df.movie_year,
    y = count_year_df.movie_id
)
layout = go.Layout(
    title='Фильмы на Кинопоиске',
)

fig = go.Figure(data = [trace], layout = layout)
iplot(fig)

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


Стали ли с годами снимать более хорошее кино?


Для ответа на этот вопрос построим график зависимости средней оценки на КиноПоиске и IMDb от года выпуска.


rating_year_df = df.groupby('movie_year', as_index = False)[['kp_rating', 'imdb_rating']].mean()

trace_kp = go.Scatter(
    x = rating_year_df.movie_year,
    y = rating_year_df.kp_rating,
    mode = 'lines',
    name = u'КиноПоиск'
)
trace_imdb = go.Scatter(
    x = rating_year_df.movie_year,
    y = rating_year_df.imdb_rating,
    mode = 'lines',
    name = 'IMDb'
)

layout = go.Layout(
    title='Оценки фильмов',
)   

fig = go.Figure(data = [trace_kp, trace_imdb], layout = layout)
iplot(fig)

На оценках по КиноПоиску и IMDb виден тренд на снижение средней оценки в зависимости от года выпуска. Но, на самом деле, из этого нельзя сделать однозначный вывод о том, что раньше снимали более качественные фильмы. Дело в том, что если уж люди смотрят старые фильмы и оценивают их на КиноПоиске, то выбирают культовое кино с заведомо более высокими оценками (думаю, мало кто смотрит проходные фильмы, вышедшие в 1940м году, по крайней мере, я не смотрю).


Есть ли различия в оценках в зависимости от жанра фильма?


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


Код
# прежде всего распарсим поле genres и data frame с размноженными строками для каждого жанра
def parse_list(lst_str):
    return filter(lambda y: y != '', 
                  map(lambda x: x.strip(), 
                      re.sub(r'[\[\]]', '', lst_str).split(',')))

df['genres'] = df['genres'].fillna('[]')
genres_data = []
for record in df.to_dict(orient = 'records'):
    genres_lst = parse_list(record['genres'])
    for genre in genres_lst:
        copy = record.copy()
        copy['genre'] = genre
        copy['weight'] = 1./len(genres_lst)
        genres_data.append(copy)

genres_df = pd.DataFrame.from_dict(genres_data)

# сформируем топ-10 жанров
top_genres = genres_df.groupby('genre')[['movie_id']].count()\
    .sort_values('movie_id', ascending = False)\
    .head(10).index.values.tolist()

N = float(len(top_genres))

# cгенерируем цвета для визуализации
c = ['hsl('+str(h)+',50%'+',50%)' for h in np.linspace(0, 360, N)]

data = [{
    'y': genres_df[genres_df.genre == top_genres[i]].kp_rating, 
    'type':'box',
    'marker':{'color': c[i]},
    'name': top_genres[i]
    } for i in range(len(top_genres))]

layout = go.Layout(
    title='Оценки фильмов',
    yaxis = {'title': 'Оценка КиноПоиска'}
)   

fig = go.Figure(data = data, layout = layout)
iplot(fig)

По графику видно, что больше всего выделяются низкими оценками фильмы-ужастики


Какие жанры чаще всего соседствуют?


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


Код
genres_coincidents = {}

for item in df.genres:
    parsed_genres = parse_list(item)
    for genre1 in parsed_genres:
        if genre1 not in genres_coincidents:
            genres_coincidents[genre1] = defaultdict(int)
        for genre2 in parsed_genres:
            genres_coincidents[genre1][genre2] += 1

genres_coincidents_df = pd.DataFrame.from_dict(genres_coincidents).fillna(0)

# отнормируем таблицу на количество фильмов каждого жанра
genres_coincidents_df_norm = genres_coincidents_df\
    .apply(lambda x: x/genres_df.groupby('genre').movie_id.count(), axis = 1)

heatmap = go.Heatmap(
    z = genres_coincidents_df_norm.values,
    x = genres_coincidents_df_norm.index.values,
    y = genres_coincidents_df_norm.columns
)
layout = go.Layout(
    title = 'Связанные жанры'
)

fig = go.Figure(data = [heatmap], layout = layout)
iplot(fig)

Читать график нужно следующим образом: 74,7% исторических фильмов также имеют тег драма.


Как менялись оценки фильмов в зависимости от жанра?


Вернемся еще раз к примеру, в котором мы смотрели на зависимость средней оценки от года выпуска и построим такие графики для различных жанров. Параллельно познакомимся с еще одной фишкой plotly: можно сконфигурировать drop-down меню и изменять график в зависимости от выбранной опции.


Код
genre_rating_year_df = genres_df.groupby(['movie_year', 'genre'], as_index = False)[['kp_rating', 'imdb_rating']].mean()

N = len(top_genres)

data = []
drop_menus = []

# конструируем все интересующие нас линии
for i in range(N):
    genre = top_genres[i]
    genre_df = genre_rating_year_df[genre_rating_year_df.genre == genre]

    trace_kp = go.Scatter(
        x = genre_df.movie_year,
        y = genre_df.kp_rating,
        mode = 'lines',
        name = genre + ' КиноПоиск',
        visible = (i == 0)
    )
    trace_imdb = go.Scatter(
        x = genre_df.movie_year,
        y = genre_df.imdb_rating,
        mode = 'lines',
        name = genre + ' IMDb',
        visible = (i == 0)
    )
    data.append(trace_kp)
    data.append(trace_imdb)

# создаем выпадающие меню
for i in range(N):
    drop_menus.append(
        dict(
            args=['visible', [False]*2*i + [True]*2 + [False]*2*(N-1-i)],
            label= top_genres[i],
            method='restyle'
        )
    )

layout = go.Layout(
    title='Фильмы по жанрам',
    updatemenus=list([
        dict(
            x = -0.1,
            y = 1,
            yanchor = 'top',
            buttons = drop_menus
        )
    ]),
)

fig = go.Figure(data = data, layout = layout)
iplot(fig)


В качестве заключения


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


Заинтересовавшимся советую посмотреть и другие примеры использования plot.ly.


Весь код и данные живут на github

Комментарии (0)

    Let's block ads! (Why?)

    Вопросы Хейлмейера, Пирса и ответы наших разработчиков

    Релиз ReactOS 0.4.2 и запуск в VirtualBox

    [Из песочницы] Использование библиотеки Android support percent на примере PercentRelativeLayout

    Документы Сноудена подтверждают достоверность данных Shadow Brokers

    В одном из наших постов, который был посвящен скомпрометированным данным кибергруппировки Equation Group, указывалось, что достоверность этих данных смог подтвердить один из ex-сотрудников NSA TAO. Другим индикатором достоверности послужил факт присутствия в архиве с данными 0day эксплойта EXTRABACON для сетевых устройств Cisco и схема именования директорий в каталоге эксплойтов. Однако, журналисты издания The Intercept, которые ранее публиковали разоблачающие NSA документы Сноудена, приводят серию других неопровержимых доказательств того, что архив Shadow Brokers действительно содержит данные кибергруппировки, которая имеет прямое отношение к NSA и известна под названием Equation Group.


    Речь идет о связи одной из вредоносных программ кибергруппы под названием SECONDDATE с теми исходными текстами, которые представлены в архиве хакеров Shadow Brokers. Ниже дано небольшое описание функций SECONDDATE, которое было взято из секретных, ранее не публиковавшихся документов Сноудена.

    SECONDDATE is a tool designed to intercept web requests and redirect browsers on target computers to an NSA web server. That server, in turn, is designed to infect them with malware. SECONDDATE’s existence was first reported by The Intercept in 2014, as part of a look at a global computer exploitation effort code-named TURBINE. The malware server, known as FOXACID, has also been described in previously released Snowden documents.

    Далее приводится скан самого секретного документа, в котором речь идет о специальной константе в коде SECONDDATE, фигурирующей в одной из вредоносных программ архива Shadow Brokers.

    Константа представляет из себя специальную строку, которую надлежит использовать в качестве идентификатора MSGID. Строка может быть жестко зашита в теле вредоносной программы, что можно увидеть на примере 14 различных файлов из архива Shadow Brokers. Один из таких файлов имеет название SecondDate-3021.exe. Ниже на скриншоте можно увидеть эту строку в теле исполняемого файла.

    В архиве можно обнаружить 47 различных файлов, которые имеют отношение к вредоносному ПО SECONDDATE, включая, различные версии его модулей, а также инструкции для его использования. Как отмечает The Intercept, SECONDDATE, на самом деле, является всего лишь компонентом более масштабного шпионского ПО NSA под названием BADDECISION. Ниже приведены слайды секретной презентации NSA, которые недавно были опубликованы изданием.

    На втором слайде показано использование атакующими компонента SECONDDATE, который используется для перенаправления трафика в системе жертвы. BADDECISION использовался в кибероперациях США в Пакистане и Ливане.

    Комментарии (0)

      Let's block ads! (Why?)

      JavaScript: где мы сейчас и куда двигаться

      [Перевод] It’s the future

      Автор сurl просит Microsoft удалить алиасы curl и wget из PowerShell

      пятница, 19 августа 2016 г.

      Мониторинг лог-журналов: Такой уязвимый лог или как подложить свинью коллегам

      [Перевод] JavaScript выходит за пределы Web в 2015 году

      Встреча любителей больших данных

      [Перевод] Зачем нам jQuery?

      Здравствуйте, дамы и господа! Вот уже без малого десять лет минуло с первого релиза библиотеки jQuery, и мы решили отряхнуть пыль веков с классики. Подумываем о выпуске третьего издания гусарской баллады об этой библиотеке:

      Чтобы пояснить, чем она нас привлекает в эпоху Node и ES6 (у нас в ассортименте и этого добра навалом) предлагаем познакомиться со статьей Коди Линдли, вышедшей вскоре после вышеупомянутого третьего издания

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

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

      Прежде чем я начну пылко отстаивать честь jQuery, давайте вернемся к ее истокам, чтобы всем стало понятно, «что» такое jQuery, и «зачем» она нужна.

      Что такое jQuery?


      jQuery – это библиотека JavaScript (т.e., она написана на JavaScript), предназначенная для абстрагирования, выравнивания, исправления и упрощения скриптинга при работе с узлами HTML-элементов в браузере или для работы в браузере без графического интерфейса.

      Итак:


      Все это оборачивается в более простой и менее корявый API, нежели нативный API DOM – вот вам и библиотека jQuery.

      Теперь позвольте объяснить, что я понимаю под “скриптингом HTML-элементов”. При помощи jQuery совершенно тривиально решаются задачи вроде «визуально скрыть второй элемент h2 в документе .html. Код jQuery для такой задачи выглядел бы так:

      jQuery('h2:eq(1)').hide();
      

      Давайте немного разберем эту строку с кодом jQuery. Сначала вызывается функция jQuery(), ей мы передаем специальный CSS-селектор библиотеки jQuery, выбирающий второй элемент h2 в HTML-документе. Затем вызывается метод jQuery.hide(), скрывающий элемент h2. Вот как прост и семантически выразителен код jQuery.

      Теперь сравним его с нативным DOM-кодом, который потребовалось бы написать, если бы мы не работали с jQuery.

      document.querySelectorAll('h2')[1].style.setProperty('display','none');
      

      Какой вариант было бы удобнее написать? А читать, а отлаживать? Также учтите, что вышеприведенный нативный DOM-код предполагает, что все браузеры поддерживают использованные здесь методы DOM. Однако оказывается, что некоторые старые браузеры не поддерживают querySelectorAll() или setProperty(). Поэтому вышеприведенный код jQuery вполне нормально работал бы в IE8, а нативный код DOM вызвал бы ошибку JavaScript. Но, все-таки, даже если бы обе строки кода работали повсюду, какую из них было бы проще читать и писать?

      Имея дело с jQuery, можно не беспокоиться о том, какой браузер что поддерживает, либо какой DOM API в каком браузере может забарахлить. Работая с jQuery, вы сможете работать быстрее решать задачи на более простом коде, и при этом не беспокоиться, так как jQuery абстрагирует за вас многие проблемы.

      jQuery = JavaScript?


      Поскольку jQuery повсеместно распространена, то вы, возможно, не вполне представляете, где заканчивается JavaScript и начинается jQuery. Для многих веб-дизайнеров и начинающих разработчиков HTML/CSS, библиотека jQuery — это первый контакт с языком программирования JavaScript. Поэтому jQuery иногда путают с JavaScript.

      Первым делом давайте оговоримся, что JavaScript – это не jQuery и даже не сам DOM API. jQuery – это сторонняя свободная библиотека, написанная на JavaScript и поддерживаемая целым сообществом разработчиков. Кроме того, jQuery не относится к числу стандартов тех организаций (напр., W3C), которые пишут спецификации HTML, CSS или DOM.

      Не забывайте, что jQuery служит прежде всего как «сахар» и используется поверх DOM API. Этот сахар помогает работать с интерфейсом DOM, который печально известен своей сложностью и обилием багов.

      jQuery – это просто полезная библиотека, которой можно пользоваться при написании сценариев для HTML-элементов. На практике большинство разработчиков прибегают к ней при DOM-скриптинге, поскольку ее API позволяет решить больше задач меньшим количеством кода.

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

      Два краеугольных камня jQuery


      Две базовые концепции, на которых основана jQuery, таковы: “найди и сделай” и “пиши меньше, делай больше.”
      Две этих концепции можно развернуть и переформулировать в виде следующего утверждения: первоочередная задача jQuery заключается в организации выбора (то есть, нахождении) или в создании HTML-элементов для решения практических задач. Без jQuery для этого потребовалось бы больше кода и больше сноровки в обращении с DOM. Достаточно вспомнить рассмотренный выше пример с сокрытием элемента h2.

      Следует отметить, что круг возможностей jQuery этим не ограничивается. Она не просто абстрагирует нативные DOM-взаимодействия, но и абстрагирует асинхронные HTTP-запросы (т.н. AJAX) при помощи объекта XMLHttpRequest. Кроме того, в ней есть еще ряд вспомогательных решений на JavaScript и мелких инструментов. Но основная польза jQuery заключается именно в упрощении HTML-скриптинга и просто в том, что с ней приятно работать.

      Еще добавлю, что польза jQuery – не в успешном устранении браузерных багов. «Краеугольные камни» нисколько не связаны с этими аспектами jQuery. В долгосрочном отношении самая сильная сторона jQuery заключается в том, что ее API абстрагирует DOM. И эта ценность никуда не денется.

      Как jQuery сочетается с современной веб-разработкой


      Библиотеке jQuery уже десять лет. Она создавалась для той эпохи веб-разработки, которую мы уже безусловно миновали. jQuery не является незаменимой технологией для работы с DOM или выполнения асинхронных HTTP-запросов. Практически все, что можно сделать с jQuery, можно сделать и без нее. А если вас интересует всего лишь пара мелких простых взаимодействий с DOM в одном-двух современных браузерах, то возможно, лучше будет воспользоваться нативными DOM-методами, а не jQuery.

      Однако, при любых разработках, связанных с BOM (браузерной моделью документа) или DOM, а не только с косметическими взаимодействиями, следует пользоваться jQuery. В противном случае вы станете изобретать велосипед (т.e. элементы абстракций jQuery), а потом испытывать его на всевозможных дорожках (т.e в мобильных браузерах и браузерах для ПК).

      Опытные разработчики знают, что такое «стоять на плечах гигантов», и когда следует избегать излишней сложности. В большинстве случаев нам все равно не обойтись без jQuery, когда нужно в сжатые сроки выполнить нетривиальную работу, связанную с HTML и DOM.

      Кроме того, даже если бы jQuery не решала ни единой проблемы с DOM или с разношерстными браузерными реализациями спецификации DOM, важность самого API ничуть бы не уменьшилась, поскольку он так удобен для HTML-скриптинга.

      Причем jQuery совершенствуется, и с ее помощью программисты могут работать толковее и быстрее. Такова ситуация сегодня, так было и на момент создания библиотеки. Сказать «мне не нужна jQuery» — все равно, что утверждать «обойдусь без lo-dash или underscore.js». Разумеется, можно без них обойтись. Но об их ценности судят не по этому.
      Их ценность — в API. Из-за излишней сложности разработка может замедляться. Поэтому нам и нравятся такие вещи как lo-dash и jQuery – с ними все упрощается. А поскольку jQuery облегчает выполнение сложных задач (например, писать сценарии для HTML), она не устареет.

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

      Приложение – важные факты об jQuery


      Наконец, перечислю некоторые важные факты, касающиеся jQuery.
      • Библиотеку jQuery написал Джон Резиг (John Resig), ее релиз состоялся 26 августа 2006. Джон признавался, что написал этот код, чтобы “произвести революцию во взаимодействии JavaScript с HTML”.
      • jQuery считается наиболее популярной и востребованной современной библиотекой JavaScript.
      • jQuery – свободное ПО, предоставляемое по лицензии MIT.
      • Существует две версии jQuery. Версия 1.x поддерживает Internet Explorer 6, 7 и 8\, а 2.x поддерживает только IE9+. Если вам требуется поддержка IE8, то придется работать с версией 1.x. Но это нормально, обе версии по-прежнему активно разрабатываются.
      • Минимальная версия jQuery 2.x имеет размер 82kb. В архиве Gzip — около 28k.
      • Минимальная версия jQuery 1.x имеет размер 96kb. В архиве Gzip — около 32k.
      • Исходный код jQuery доступен на Github.
      • На основе исходного кода с Github можно создать собственную версию jQuery.
      • jQuery можно установить при помощи менеджера пакетов bower или npm (т.e. $ bower install jquery or npm install jquery).
      • У jQuery есть официальная сеть CDN, в которой можно взять различные версии jQuery.
      • jQuery имеет простую архитектуру на основе плагинов, поэтому любой желающий может добавлять в нее собственные методы.
      • jQuery обладает обширным набором плагинов. Можно приобрести высококачественные плагины для enterprise-разработки (напр. Kendo UI) или воспользоваться не менее классными бесплатными (напр. Bootstrap).
      • jQuery можно разбить на категории (в соответствии с разбиением документации API ).

      • ajax
      • attributes
      • callbacks object
      • core
      • CSS
      • data
      • deferred object
      • dimensions
      • effects
      • events
      • forms
      • internals
      • manipulation
      • miscellaneous
      • offset
      • properties
      • selectors
      • traversing
      • utilities

      Комментарии (0)

        Let's block ads! (Why?)

        MTC и IBM: облачные сервисы и современные приложения — это просто


        Александр Климов, ведущий инженер-программист, член Академии технологий компании IBM

        Недавно в Клиентском центре IBM прошел двухдневный хакатон с целью привлечения разработчиков к поиску и разработке перспективных идей и их ознакомления с платформой для разработки облачных сервисов IBM Bluemix*.

        Участникам было необходимо организоваться в команды, придумать идею, разработать проект и презентовать его жюри хакатона, которое состояло из представителей компаний-организаторов — МТС и IBM. Жюри голосованием определяло победителей, чьи идеи и проекты как с технической, так и с точки зрения бизнеса, оказались наиболее интересными и убедительными. Обладатели трех первых мест получили денежные призы и незабываемый опыт ночной отладки и презентации своих приложений после бессонной ночи.

        Всего в хакатоне приняло участие свыше 70 человек, которые организовали 12 команд и представили 11 проектов.

        Команды, проекты и технологии


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

        Просторобот (номинация Best Project)

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

        Fraud Detector (номинация Big Data)

        Проект разработан также командой МТС, его основная концептуальная идея — решение актуальных проблем в области безопасности и телефонного мошенничества. Команда разработала Android-приложение, которое работало совместно с back-end сервисом, развернутым в Bluemix Java Instant Runtime. Были спроектированы и реализованы логика поиска и идентификации злоумышленников с использованием информации о звонках из открытых источников данных о телефонных мошенничествах и методики предиктивного анализа для выявления ранее не известных поведенческих паттернов злоумышленников.

        Авточат (номинация Original)

        Идея проекта — отправка сообщений на мобильный телефон по номеру автомобиля. Проект адресует ряд проблем, с которыми мы нередко сталкиваемся в городе, например, случаи, когда чья-то машина блокирует выезд, при этом заботясь о конфиденциальности пользователей — не раскрывая актуальных телефонов. Команда МТС, которая предложила эту идею, использовала Bluemix Node-RED — сервис, который посредством визуального прототипирования существенно упрощает и ускоряет разработку облачных приложений и IoT сервисов. Сервис Bluemix Watson Dialog помог расширить функционал элементами искусственного интеллекта для автоматизированного общения пользователей и машин.

        Также хочется еще отметить проект EcoMAP, который поставил перед собой серьезную и амбициозную цель улучшения экосистемы города с помощью искусственного интеллекта. Идея проекта: пользователь фотографирует некий объект, сервис Bluemix Watson Image Recognition распознает этот объект и обращается в специальную базу, чтобы идентифицировать материал, из которого этот предмет сделан, чтобы предоставить ближайший адрес утилизации этого предмета. Это позволяет снизить степень загрязненности окружающей среды в городе и улучшить экологическую обстановку.

        В целом, все участвующие команды использовали два подхода при проектировании и разработке своих приложений — Bluemix Instant Runtimes (IR) и Bluemix Node-RED.

        Bluemix Instant Runtimes — это классический подход в PaaS системах, который предоставляет готовые для использования окружения для разработчиков, освобождая их от необходимости установки, конфигурации и администрования. Наиболее популярные Bluemix IR — Java, Python, NodeJS, Go и Ruby On Rails.

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

        Некоторые команды активно использовали Bluemix Spark, точнее Spark-as-a-Service, для проектов, идеи которых либо были построены вокруг парадигмы Big Data, либо так или иначе оперировали подобными объемами данных, которые они хранили в Bluemix Object Storage (IBM Spectrum, ранее называвшийся GPFS).

        Bluemix предоставляет возможность работать с Docker контейнерами — сервис IBM Containers, который также помог нескольким командам решить ряд задач, например, разработка сервиса-планировщика для Spark в контейнере.

        Интроспектива: облака и разработчики


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

        IBM Bluemix позволила реализовать свои идеи быстро, не требуя каких-либо серьезных инвестиций в обучение, хотя бы потому, что предоставляет широкий выбор технологий с открытым кодом, многим из нас знакомый — Java, Python, NodeJS, Containers и т.д. Более того, с IBM Watson появляются возможности создания новых так называемых когнитивных систем — систем, построенных на принципах искусственного интеллекта.

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

        *Bluemix – это Platform-as-a-Service на базе популярной платформы с открытым кодом Cloud Foundry с обширным набором сервисов, позволяющих быстро и удобно создавать широкий спектр приложений. Каталог сервисов, доступных для разработчиков, предоставляет широкие возможности для создания таких современных систем как когнитивная аналитика, мобильные приложения, масштабируемые гибридные облачные системы, Internet of Things и многое другое. Ознакомиться с сервисом можно здесь.

        Комментарии (0)

          Let's block ads! (Why?)

          Security Week 33: отключение Secure Boot, сортировка адресатов в GMail, последствия TCP-бага в Linux

          На этой неделе по ландшафту угроз бурным потоком разлилась река политики. Тема безопасности и так политизирована донельзя, но если вам вдруг кажется, что уже как-то многовато, то спешу вас расстроить. Все только начинается. 13 августа анонимы, скрывающиеся под псевдонимом ShadowBrokers, выставили на продажу арсенал инструментов, предположительно использовавшихся в кибершпионской кампании The Equation. Напомню, исследование этой атаки опубликовали в феврале прошлого года эксперты «Лаборатории», назвав ее «Звездой смерти из галактики вредоносного ПО». Было за что: впечатляет как длительность кампании (с 2001 года, а может и раньше), так и сложность и широкая функциональность инструментов для взлома и кражи данных. Ну и технический уровень заодно, вплоть до помещения вредоносного кода в прошивку жестких дисков.

          Распродажа устроена по лучшим стандартам коммерческого делопроизводства: «шлите деньги, а мы подумаем». Но помимо обещаний, в сеть был выброшен набор файлов, явно вырезанный из чьей-то среды разработки: немножко кода, немножко скриптов, документации и так далее. Если не вестись на поводу у СМИ, которые всю неделю обсуждают версии авторства утечки — то, что априори невозможно подтвердить фактами, про ShadowBrokers можно определенно сказать следующее. Во-первых, имплементация алгоритмов шифрования RC5 и RC6 в утечке совпадает с таковой у The Equation. Это позволяет с определенной долей уверенности говорить, что связь между, строго говоря, кодом, обнаруженным в сети сейчас и пару лет назад, имеется. Подробнее с примерами тут. Во-вторых, в утечке обнаружены реальные уязвимости в устройствах Cisco (очень подробно написано у них в блоге) и Fortinet.

          Все остальное по теме можно свести к одному слову «непонятно». Утечку ShadowBrokers можно поставить в один ряд с прошлогодним взломом компании HackingTeam: и в том, и в другом случае были опубликованы опасные вредоносные инструменты. Даже самые сложные и дорогие разработки такого плана имеют тендецию к быстрому удешевлению и попаданию не в те руки. Единственный способ предовратить это — по возможности не создавать кибероружие, вне зависимости от целей. Вредоносного кода и так хватает.

          Все выпуски дайджеста — тут.

          Хакеры обсудили уязвимость механизма Secure Boot с Microsoft. Хакеры: «Все плохо». Microsoft: «Все нормально»


          Новость.

          Secure Boot — это концепция, предусматривающая запуск только авторизованного кода на самом ответственном этапе загрузки системы — после BIOS. В данном случае речь идет о реализации Secure Boot компанией Microsoft — она впервые была выпущена в продакшн вместе с Windows 8 в 2012 году. Тогда же MS получила очередную порцию проклятий от приверженцев оупен-сорса: с помощью Secure Boot ведь можно заблокировать запуск сторонних ОС (рассказать бы им тогда про Ubuntu внутри Win10 — не поверили бы). Собственно, на ARM-устройствах Microsoft так и сделано, а что касается обычных ПК — официально здесь решение остается за вендором. Случаев агрессивного попирания прав линуксоидов за четыре года зафиксировано не было, но Ричард Столлмэн все равно против.

          Подробнее про Secure Boot можно почитать на сайте Microsoft, а лучше — посмотреть сюда в документацию Fedora. Собственно, основной задачей Secure Boot является не притеснение свободолюбивых кодеров, а защита от вредоносного ПО, конкретно — от буткитов. Здесь даже Столлмэн согласен, что таки да, такая защита необходима. Двое хакеров, известные как my123 и slipstream исследовали методы работы Secure Boot и обнаружили странное: при разработке Windows 10 Redstone были добавлены новые правила (policies), с отключенными проверками кода (на наличие сертификата и/или привязку к конкретному устройству). Изменение было внесено в код файла bootmgr.efi. Через эту дыру можно как протащить неавторизованный код, так и отключить Secure Boot полностью. В двух патчах (MS16-094 и MS16-100) проблему пытались решить, отозвав определенные версии данного файла, но как утверждают хакеры, проблема не была решена полностью. Возможно она никогда не будет решена, так как, по словам исследователей, забанить абсолютно все загрузчики Microsoft не сможет, например из-за необходимости сохранить работоспособность определенных образов системы. Подробнее — в отчете здесь (берегите глаза и уши, там музыка и верстка из 1994-го, и буквы прыгают).

          Позиция Microsoft по поводу исследования сдержанная. Исследователям дали понять, что уязвимостью это не считается. В комментарии для Threatpost в компании отметили, что эксплуатация «проблемы» требует физического доступа к ARM-устройствам и не распространяется на корпоративные системы. В целом они правы: пока что, исходя из того, что нам известно, это не самая ужасная в мире уязвимость. Поэтому главное в этой истории не фактура, а мораль. Если разработчики Microsoft действительно совершили ошибку, то проблема не в ошибке, а в самой возможности ее совершения. Системы безопасности в идеале надо разрабатывать так, чтобы в них не было бэкдоров, даже легальных, чтобы в принципе не было возможности что-то потерять, случайно или в результате кражи. Это еще и запоздавший довод к февральскому диспуту между Apple и ФБР. Тогда позиция федералов заключалась в том, что им даже не нужно знать метод взлома iPhone, Apple достаточно его разработать и применить. По мнению Apple, сам факт разработки отмычки уже представлял большую опасность. Тайное всегда становится явным.

          Уязвимость в реализации протокола TCP затрагивает Linux-системы и 80% Android-устройств


          Новость. Вторая новость. Научное исследование.

          Что может быть хуже уязвимости в ядре операционной системы? Только уязвимость в реализации одного из фундаментальных протоколов. Но нет, не только. Еще хуже, когда уязвимость заложена в спецификациях протокола. Судя по всему, именно это произошло со спецификацией RFC 5961, направленной на повышение безопасности протокола TCP. В ядре Linux эти нововведения были реализованы начиная с версии 3.6, выпущенной в 2012 году. Исследователи из Калифорнийского университета под руководством Юи Цао нашли способ эксплуатации единственной особенности реализации новой спецификации в Linux — общего лимита на пакеты типа Challenge ACK. Детальная схема атаки находится за пределами моих когнитивных способностей, поэтому за подробностями прошу обращаться к оригинальному исследованию. Здесь же просто картинку оттуда покажу:


          Я все понял.jpg!

          Потенциал у уязвимости огромный: появляется возможность определить, что два адресата в сети передают друг другу TCP-пакеты, инициировать разрыв связи между ними и даже перехватывать данные (или внедрять собственные в процесс передачи). Все это — с высокой вероятностью успеха и с низкими требованиями по времени на создание условий для эксплуатации (десятки секунд). Для реализации атаки также не нужно занимать позицию man-in-the-middle, достаточно знать адреса отправителя и реципиента и иметь возможность подмены собственного IP. Помимо десктопов и серверов на Linux (для ядра уже выпущен патч), уязвимости оказались подвержены до 80% Android-устройств. Причем в данном случае, по иронии, неподверженными оказались старые смартфоны (c Android 4.3 и более ранними версиями). Новые подвержены все, включая бета-версии Android 7.0.

          Ждем апдейтов.

          GMail начинает идентифицировать недоверенных отправителей


          Новость. Анонс в блоге Google.

          Добавим минутку позитива. В ближайшее время Google начнет сообщать пользователям о том, что отправителю письма не стоит доверять. Для таких сообщений будет демонстрироваться нестандартная иконка рядом с адресом отправителя, примерно так:


          Условие для утраты доверия: несоответствие требованиям стандартов Sender Policy Framework и DKIM. Не думаю, что иконка со знаком вопроса остановит незадачливого пользователя от прочтения и реагирования на хитрое фишинговое письмо, но судя по тактике Google, непроверяемые сообщения в будущем будут отфильтровываться все более активно. Кроме того, в GMail внедрили уже давно используемую в браузерах Chrome функцию безопасного серфинга, которая предупреждает о подозрительных и вредоносных ссылках.

          Что еще произошло


          Довольно тривиальному методу спуфинга адресной строки оказались подвержены Chrome и Firefox.

          Эксперты «Лаборатории» рассказывают о таргетированной кампании Operation Ghoul, с жертвами преимущественно на Ближнем Востоке.

          Сразу несколько гостиничных сетей в США рапортуют об утечке данных кредитных карт через взлом POS-терминалов.

          Еще один интересный метод кражи данных из air-gapped систем: через анализ жужжания жесткого диска (все плавно переходят на SSD).

          Древности:
          «Printer-778»

          Опасный резидентный вирус, стандартно поражает .COM- и .EXE-файлы, кроме COMMAND.COM. У COM-файлов заменяет начало на команды: MOV BX, Loc_Virus; JMP BX. При работае с принтером (int 17h) переводит выводимую на него информацию в код ASCII-7 (обнуляет старший бит). В результате принтер отказывается «говорить» по-русски и печатать псевдографику. Вирус перехватывает int 17h, 21h.

          Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 80.

          Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

          Комментарии (0)

            Let's block ads! (Why?)

            [Из песочницы] Qt: Вывод отчета стандартными средствами (или живем без генераторов отчета)

            Joker Student Edition: Лучшие видео прошлых конференций

            Бескрайние просторы интернета часто озаряются вспышками праведного гнева по поводу бессмысленности и бесполезности студентов-айтишников, нашего образования и сетований в стиле «раньше трава была зеленее».

            Этот пост получится большим, а все вот почему: мы рассмотрим ТОП-5 докладов с двух наших студенческих конференций (Joker 2015 University Day и JPoint 2016 Student Day), поговорим о том, чего хочет молодежь в 2016 году, а также пройдемся по новому формату Joker 2016 Student Edition (Петербург, 15 октября, Экспофорум).

            Чего хотят студенты и начинающие Java-разработчики?


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

            Прежде, чем мы начнем рассматривать лучшие доклады, следует кое-что уточнить. Хоть в названиях наших конференций есть слова Student/University, важно отметить, что это профессиональные конференции, по факту рассчитанные на студентов, работающих на позиции Junior’а и ищущих свой путь в Java-мире. Кстати, это наш первый Java-ТОП без Алексея @shipilev Шипилева :)

            Итак, давайте посмотрим, какие доклады собрали максимальный отклик среди молодой аудитории:

            Виктор gAmUssA Гамов, «Распределяй и властвуй: введение в распределенные системы»
            Доклад Senior Solution Architect из компании Hazelcast, которая занимается распределенной обработкой данных (in-memory data grid) с открытым исходным кодом, включивший в себя как общее введение и обзор терминов из области распределенных вычислений, так и конкретные примеры кода и live-демки. Примечательно, что Виктор не стал останавливаться на базовых примерах, но и рассказал о подводных камнях разных подходов к организации распределенных систем.

            Mаксим Дорофеев, «Студенческий синдром: почему мы все делаем в последний момент?»
            Если вас хоть раз посещала мысль «никогда не буду откладывать работу на последнюю ночь перед дедлайном», которую вы уже через месяц успешно игнорировали, то этот бодрейший доклад для вас. Доклад по полочкам раскладывает причины подобного поведения и дает пищу для размышлений о том, как все исправить.

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

            Josh Long, Pivotal, «The Bootiful Microservice»
            Демо-доклад, на котором вы вместе со спикером (одним из лучших в мире live-кодеров), начнете с разработки простого веб-приложения при помощью Spring, а закончите на безопасном мессенджере, собранном за 1 час. Радует, что доклады отлично «заходят» и на английском языке.

            Идель Пивницкий, «Что может дать Open Source студенту. Выжимаем максимум удовольствия и пользы»
            Доклад для тех, кто не знает с чего начать. Отличная мотивация если вы думаете, что разработчик без опыта никому не нужен. Нужен!
            В видео вы найдете обзор программ поддержки начинающих разработчиков от Google, Mozilla, KDE и многих других; инструкцию, как именно начать коммитить в Open-Source; FAQ, почему вы точно подходите для работы с Open Source; подборка инструментов для этого.

            Барух jbaruch Садогурский, Кирилл tolkkv Толкачев, «Баттл инструментов для сборки — Maven vs Gradle»
            Maven — самый популярный инструмент для сборки Java приложений. Gradle всё быстрее набирает популярность и скоро-скоро затмит лидера. В этом докладе разбираемся, что лучше? Интерактивно, весело, доступно – в таком формате JavaOne Rock-Star Барух Садогурский с Кириллом Толкачевым рассказывают о популярных системах сборки и опасностях, которые они в себе таят.

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

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

            Что они получают?


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

            В начале статьи мы говорили о том, что Joker 2016 Student Edition – это профессиональная конференция, единственная в своем роде. Здесь студенты за один день смогут получить полный обзор доступных путей в мире Java (правда без Scala, но мы не садисты): от низкоуровневых исследований производительности до новейших тулзов. И здесь со студентами и Junior’ами не будут обращаться как с учениками, здесь они смогут почувствовать себя профессионалами. А это многого стоит.

            Что будет на Joker 2016 Student Edition?

            Andres Almiray, Canoo Engineering AG – Java libraries you can't afford to miss

            Посвященный 20-летию Java обзор наиболее популярных и эффективных Java библиотек и фреймворков от Java Champion с более чем 16-летним опытом в области проектирования и разработки ПО. В докладе поговорим не о тех инструментах, которые должны быть в арсенале каждого разработчика, но и обсудим многообещающие растущие проекты.

            Антон Архипов, ZeroTurnaround — Байткод для любознательных

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

            Максим Сячин, Luxoft — Микросервисы: первая кровь

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

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

            Сергей Владимиров, МФТИ (ГУ)/Сбертех – Оптимизация: не всё то золото…

            Думаете, что оптимизация — это ассемблер, борьба за наносекунды и управление GC? Не обольщайтесь, чаще всего в коде есть десятки совершенно несерьезных промахов в области производительности. В докладе приведены примеры оптимизаций реального кода, когда от изменения используемых алгоритмов получали ускорение в 100 и более раз:

            • Pattern matching. Как проверить соответствие строки 1000+ шаблонам за микросекунду;
            • Работа с ORM, скрытые связи и потери, которые выявит даже профайлер бедного человека;
            • Batch. О чём молчат stream'ы.

            Владимир Красильщик, Яндекс – Анти-введение в Big Data

            Что такое Big Data, как искать и находить эту Big Data в проектах и продуктах? Зачем, как и из чего строятся приложения, основанные на принципах Big Data. Как определить, «большая» у вас data, или маленькая?

            В этом докладе поговорим о realtime, пакетной обработке, хранении данных и покемонах.

            Andrzej Grzesik, Burberry – Are you aware of /bin of your JDK?
            Хардкорный доклад про инструментарий работы, который есть под рукой каждого Java-разработчика: анализ дампов памяти, стек-трейсов и мониторинг работы GC, – все это доступно «из коробки».

            В рамках доклада Андрей расскажет, как использовать JDK на полную катушку, сопровождая свои слова live-demo и распространенными примерами.

            Кирилл Толкачев и Александр Тарасов, Альфа-Лаборатория – От любви до ненависти — один шаг
            Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть: «А я бы сделал еще круче!»? Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях крупной корпорации.

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

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

            Дискуссионные зоны и стенды спонсоров.


            Как и в большом Joker, на Student Edition будут дискуссионные зоны: одна из ключевых фишек наших конференций 2016 года. Если вкратце – после доклада, спикеры будут еще в течение часа отвечать на вопросы, холиварить, если потребуется и вообще всячески общаться с участниками в свободном формате.

            Почти тут же ребята смогут встретиться и поговорить с разработчиками и PM’ами из крупных IT-компаний, таких как Одноклассники, Luxoft, T-Systems, EPAM, JetBrains и многие другие. Важно помнить, что на Joker SE с участниками будут говорить не как со студентами/учениками, а как с начинающими профессионалами, – это, как показывает практика прошлых конференций, многое меняет как в головах студентов, так и в умах работодателей.

            Именно для того, чтобы погрузить наших молодых участников в атмосферу «взрослого» Joker, а также дать им возможность пообщаться не только с друзьями-студентами, но и с опытными коллегами (более 80% участников Joker – разработчики уровня Senior/Middle), мы проводим Joker 2016 Student Edition 15 октября, в параллели и на той же площадке, что и «взрослый» Joker 2016.

            Шутейная задачка вместо постскриптума: напишите в комментариях, по какому принципу расставлены участницы JPoint Student Day на картинке ниже.

            Комментарии (0)

              Let's block ads! (Why?)

              Анонс Rust 1.11

              Что тестирует HPE Mobile Center

              HPE Mobile Center, по сути, является шлюзом, который помогает вашей команде централизовать активности по тестированию, мониторингу и управлению жизненным циклом мобильных приложений. Это достигается за счет централизованного использования парка мобильных устройств (физических и виртуальных, клиентских и облачных) и интеграций как с продуктами HPE ALM, так и с Open Source (Appium/Selenium).

              image

              HPE Mobile Center не ограничен тестированием мобильных приложений и мобильных версий сайтов. Приобретая начальный пакет HPE MC, пользователь получает доступ к облачному сервису мониторинга работы мобильных приложений AppPulse Mobile (ограниченно, на два приложения), доступ к Fortify-on-Demand для тестирования безопасности приложения. Также наиболее интересны и востребованы возможности для автоматического и ручного тестирования, тем более что одна лицензия на HPE UFT – модуль автоматизированного функционального тестирования тоже входит в минимальный пакет HPE Mobile Center, а Sprinter, инструмент для ручного тестирования приложений, и вовсе бесплатен для владельцев HPE MC.

              Само название — Mobile Center — подчеркивает важность и специфичность мобильного тестирования. В центре разработки HPE Software в Израиле и Китае выделено подразделение, где примерно 70 сотрудников занимаются разработкой инструментария для мобильного тестирования и прочими связанными темами. И недаром: в этой области свои проблемы и свои особенности, не всегда очевидные на первый взгляд.

              Продукты для разработки и тестирования ПО в HPE Software – это целый большой пакет инструментов и технологий HPE ADM (HPE Application Delivery Management), тесно связанных между собой. Выше уже упоминали UFT, Sprinter и Mobile Center.  Кроме них HPE ADM включает: ALM Octane – версию ALM (Application Lifecycle Management)  для планирования, реализации и сопровождения проектов разработки и внедрения по методологиям Agile и DevOps;  HPE LeanFT для написания юнит-тестов на Java, JavaScript или C# в привычной для разработчика среде (MS Visual Studio, Eclipse и IntelliJ IDEA), но с применением уникальных технологий HPE UFT, что, по мнению разработчиков, существенно ускоряет разработку таких тестов; HPE LoadRunner – всеми любимый инструмент нагрузочного тестирования, который уже давно доступен бесплатно (для нагрузки не более 50 виртуальных пользователей); инструмент виртуализации сетевых условий HPE Network Virtualization и быстрой разработки заглушек  интеграционных сред и сервисов HPE Service Virtualization.

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

              Мобильные устройства в облаках


              Особенность, конечно, не только в пресловутой фрагментации мобильных устройств, которая стала общим местом для критиков платформы Android. Тут можно выделить широкий спектр возможностей использования сенсоров мобильных устройств, мобильных жестов и пр. Требуются другие подходы. Разумеется, можно использовать мобильные эмуляторы – HPE Mobile Center поддерживает как Google SDK, так и коммерческие эмуляторы от Genymotion. Но данный подход не позволяет с точностью ответить на принципиальный вопрос: как будет проходит взаимодействие приложения с аппаратной платформой на тысячах существующих на рынке устройств?

              Есть два пути. Во-первых, тестируют все-таки не «черный ящик», а приложения, которые разрабатывались на той или иной известной платформе для программного обеспечения — Sencha Touch, Apache Cordova/PhoneGap, Adobe Air или Xamarin. Ведь данные платформы дают возможность абстрагироваться от многих особенностей железа уже на фазе разработки продукта.

              Второе (а то и первое по значению): покрытие тестирования. Имеет смысл идти не от аналитики фреймворков и кода, а от анализа и знаний о пользователях данных приложений. Если тестируются приложения для использования внутри американской компании (и таких заказчиков много), то незачем тестировать дешевые смартфоны из Азии. И наоборот: с тестированием приложений для китайского рынка лучше разберутся разработчики из шанхайского офиса, знакомые с устройствами, популярными на местном рынке. Мобильный центр позволяет централизовать все региональные парки мобильных устройств и предоставить к ним доступ всем пользователям. Эти устройства также могут быть использованы для CI/CD-циклов непрерывного тестирования пользователями Мобильного центра через плагин для Jenkins и Bamboo.

              К тому же жизнь вносит свои коррективы, ведь в мире мобильного бизнеса изменения происходят особенно быстро. Microsoft приобретает Xamarin — значит, стоит сфокусировать часть усилий на этих технологиях, чтобы быть готовым к возможному всплеску интереса клиентов. Если популярность Adobe Air пошла на убыль, усилия разработчиков выгоднее переключить на ту технологию, что в данный момент на подъеме, например на Cordova.  «Держим ухо востро и нос по ветру» — так выразился Евгений Карасик, глава подразделения Центра разработок HPE Mobile Center в Израиле.

              Виртуализация продолжается: теперь сети


              Около года назад HPE приобрела компанию Shunra Software, специализировавшуюся на ПО для виртуализации особенностей сетей, – HPE Network Virtualization, NV (благо ее сотрудники тоже находятся в Израиле и давно сотрудничают с Центром разработки). Началась работа по интеграции NV с другими продуктами HPE Software. У Mobile Center появилась еще одна возможность оторваться от конкурентов: NV тоже входит в комплект Mobile Center. Added value, как говорят в бизнесе.

              Клиенты сразу заинтересовались новым продуктом, что неудивительно: до этого мобильные устройства тестировали физически: тестировщики с мобильными телефонами разъезжали по стране, описывая, как приложения ведут себя в разных сетях и регионах. Для Израиля проблема, наверное, небольшая, но в России это стало бы настоящим безумием, недаром один из ведущих отечественных сотовых операторов уже давно и успешно использует HPE Mobile Center для данных целей. Конечно, желающих можно найти в самых разных точках страны — сообщество тестировщиков огромно, но достоверность и продолжительность результата таких всенародных тестов может устроить не всех клиентов, тем более корпоративных.

              Само собой, серьезные корпоративные клиенты — это ядро пользователей HPE MC. Большинство из них уже используют у себя продукты и/или сервисы HPE. Мобильные приложения им нужны не только и даже не столько для доступа из «внешнего мира», сколько для облегчения жизни и ускорения работы собственных сотрудников, будь то мировой банк, глобальный ритейлер или гигант автостроения. Для внутренних применений особенно важна предсказуемость работоспособности приложений внутри корпоративной сети, которая неоднородна и сложна.

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

              Если число виртуально тестируемых сетей будет расти (а как же иначе?), то при наличии гигантского парка устройств количество комбинаций окажется астрономическим. Тут уже не обойтись без применения технологий искусственного интеллекта. К счастью, разработчики Mobile Center их уже не просто используют, а, можно сказать, сделали на них ставку. Это область Big Data, Sentiment Analysis (машинный анализ эмоций), машинного обучения и прочих модных технологий. Ожидается, что в будущем аналитические модули станут все более востребованными.

              Новые парки: IoT


              В HPE Mobile Center будет, скорее всего, интегрирован и парк сенсорных устройств — шаг навстречу грядущему Интернету вещей. Такое существенное расширение деятельности не сильно обременит ресурсы компании: по сути, это перенос уже отработанных технологий на новые типы устройств.

              Мало кто сомневается в том, что клиенты заинтересуются возможностями тестирования сенсоров из мира IoT. Корпорации, желающие выглядеть современно, уже обзавелись новыми штатными единицами — директорами по Интернету вещей. Напомним, что среди 250 клиентов MC есть компании автомобильной промышленности. В новейших моделях автомобилей уже есть около 4 тыс. различных сенсоров — небольшой свой мир внутри отдельно взятой жестяной коробки. Для них решение очевидно. Но и, казалось бы, далекие от IoT структуры, например банки, тоже проявляют живой интерес к IoT. И здесь российским айтишникам выпадает очередной шанс не догонять, а пробовать среди первых.

              Комментарии (0)

                Let's block ads! (Why?)

                Вести с полей: кто и как применял качественные методы в UX Research для разработки IT-продуктов. Часть 6 из 6

                «Чтобы двигаться дальше, мы должны понять, что нужно людям»: разработка нового сервиса


                Итак, мы подошли к последней жизненной ситуации — разработке нового сервиса. Использование качественной методологии для разработки нового сервиса затрагивает все вопросы, которые мы рассмотрели ранее:
                • изучение потребностей, поведения, страхов и проблем одной или нескольких групп пользователей;
                • анализ жизненных ситуаций и среды использования;
                • изучение повседневности пользователей и рутинных действий;
                • выявление культурных особенностей, которые могут повлиять на использование IT-продукта.

                Разработка нового сервиса — это одна из самых сложных задач: риск ошибиться здесь очень велик. Исследование, проведенное с помощью качественных методов на стадии разработки продукта, снижает эти риски, но не исключает полностью. Требования к квалификации исследователей в проектной команде здесь чрезвычайно высоки. Собранные данные очень сильно влияют на результат.

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

                Кейс 22. The Understanding Group: сервис сбора пожертвований для университета

                Кейс 22. The Understanding Group: сервис сбора пожертвований для университета


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

                Департамент развития хотел дать пользователям возможность беспрепятственно делать пожертвования в неограниченных размерах — чтобы сэкономить время дарителей и удовлетворить потребность университета в дополнительном финансировании. Они не хотели гениального дизайна или однобокой стратегии. Им нужна была добротная информационная структура, где учитываются потребности организации и дарителей. Вот такая программа-максимум, которая невозможна без понимания и заказчиков, и пользователей. Для решения этой задачи обратились к услугам The Understanding Group.

                Команда The Understanding Group приступила к работе — провела серию интервью с представителями заказчика и пользователями, а также эвристический анализ интерфейса сайта. Результаты были неутешительны: сайт не содержал необходимых сведений о пожертвованиях и не обеспечивал должной обратной связи. Люди не были уверены, что отдают деньги на благие цели, а их вклад будет подтвержден и оценен. Сайт был холодным и неприветливым. Это очень мешало привлечению средств.

                По результатам интервью были созданы ключевые персонажи:

                • недавний выпускник университета;
                • даритель с большим опытом;
                • страстный любитель спорта;
                • даритель, жертвующий в память члена семьи;
                • сотрудник университета.

                Созданные персонажи и сценарии использования сайта определили приоритеты и возможности для обсуждения на двух совместных дизайн-сессиях с участием представителей заказчика. По результатам исследования команда подготовила эскизы страниц будущего сайта, которые стали предметом обсуждения. Во время первой сессии на доске делались наброски альтернативных вариантов. На второй дизайн-сессии команда The Understanding Group и представители заказчика обсудили и утвердили итоговые варианты — они стали отправной точкой для остальных эскизов рабочего процесса. Работа на сессиях повлияла на финальный дизайн сайта, в частности помогла справиться с техническими и административными ограничениями.

                Улучшения по результатам исследования заметно увеличили приток пожертвований. С момента запуска сайта:

                • пожертвования в несколько фондов сразу выросли на 100%;
                • объемы неограниченных пожертвований увеличились в пять раз;
                • выросло число положительных отзывов со стороны пользователей и сотрудников университета;
                • число звонков в клиентскую службу с жалобами и пожеланиями снизилось на 57%.

                По всем показателям — аналитика, отзывы пользователей и пожертвования — изменения на сайте помогли департаменту развития достичь цели.
                Кейс 23. Prime Motive: сайт для страховой компании CGU Insurance

                Кейс 23. Prime Motive: сайт для страховой компании CGU Insurance


                Компания CGU Insurance — одна из самых авторитетных страховых компаний в Австралии. Традиционно этот бизнес развивался при активном участии страховых брокеров, но в компании видели, что времена меняются. Интернет и мобильные устройства позволяют потребителям со всей страны покупать страховки напрямую. Страховой рынок превратился в рынок клиента, и понимание этого факта стало стартом для радикальных изменений. CGU Insurance обратилась в компанию Prime Motive, чтобы разработать сайт для онлайн-продажи страховых полисов малому бизнесу.

                Сотрудники Prime Motive вместе со своими коллегами из Deloitt провели серию интервью с владельцами малого бизнеса непосредственно на рабочих местах. Темы интервью не ограничивались страхованием: беседовали о бизнесе, его развитии, проблемах и рисках. Владельцы бизнеса делились положительным и отрицательным опытом, рассказывали о своих трудностях и опасениях, в том числе о страхе оказаться без защиты. Каждое предприятие имело свои особенности, но все владельцы были едины во мнении, что бизнес — это их жизнь и способ выживания одновременно.

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

                Кейс 24. Bowmast: изучение привычек и поведения пользователей Kiwibank ATM

                Кейс 24. Bowmast: изучение привычек и поведения пользователей Kiwibank ATM


                Команде Kiwibank, отвечающей за потребительский опыт, понадобились сведения о роли банкоматов и наличных денег в жизни потребителей. Эта информация была необходима для развития сети банкоматов и разработки новых сервисов — невозможно выполнить такую работу без понимания пользователей. Нужно было качественное исследование. За помощью обратились в компанию Bowmast, а точнее — к Нику Боумасту.

                Сначала Ник провел интервью с представителями заказчика: операционистами, маркетологами, продуктологами, сотрудниками колл-центра и аналитиками. Эти интервью позволили четко определить цели и объект исследования, а также тип данных, которые будут максимально полезными для краткосрочного и среднесрочного планирования.

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

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

                Интервью с пользователями проводились, как правило, у них дома, на кухне. Это была непринужденная беседа о том, как люди пользуются банкоматом: время суток, частота, суммы и место. Такие разговоры помогали выявить привычки и особенности поведения пользователей.

                Результаты исследования дали четкое представление о том, как банкоматы и наличные деньги вплетены в жизнь различных категорий пользователей. Это помогло заказчику определить приоритеты развития сети банкоматов с учетом удобства и пользы для клиентов. Стало понятно, какие категории пользователей заинтересованы в конкретных сервисах. Исследование позволило выявить новые пути для информирования и расширения возможностей клиентов, в том числе мобильные приложения и специализированные банковские сервисы. Заказчику показали, как усовершенствовать банкомат, чтобы он лучше отвечал потребностям пользователей. По результатам исследования была сделана нарезка видео для иллюстрации ключевых выводов. Такой формат не только чрезвычайно интересен и информативен — он помог вызвать у заказчика эмпатию по отношению к пользователям.

                * * *


                Проектная команда The Understanding Group имела серьезное преимущество: сервис приема платежей — вещь уже известная. Именно поэтому исследователи могли ограничиться проведением интервью — таким образом они получили необходимую информацию о потребностях, поведении и страхах пользователей, а также о недостатках имеющегося сервиса (для решения этой задачи они также провели эвристический анализ). Информации для создания нового удобного онлайн-сервиса приема пожертвований было достаточно. В похожей ситуации оказалась команда Prime Motive — она тоже использовала для изучения пользователей интервью. Сервис по продаже страховок уже существовал офлайн. Подробная информация о пользователях, собранная с помощью интервью, помогла перевести его в онлайн.

                Кейс Ника Боумаста отличается тем, что здесь используются два метода: интервью и наблюдение. Это объясняется тем, что Kiwibank планировал разрабатывать новые сервисы для своей системы банкоматов. Для этого компании требовалось больше информации о пользователях, в том числе об их повседневных привычках. При этом было важно выявить культурные различия между городским и сельским населением и понять, влияют ли эти различия на использование банкоматов. Фактически это был крупный запрос на информацию о среде использования. Поэтому понадобились и интервью, и наблюдение.

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

                Кейс 25. CXpartners: цифровые сервисы для муниципалитета Бристоля

                Кейс 25. CXpartners: цифровые сервисы для муниципалитета Бристоля


                Что делать, если бюджет сокращают, а жители города требуют повысить качество услуг, предоставляемых государственными структурами? С такой проблемой столкнулся муниципалитет Бристоля в Великобритании. Люди хотят, чтобы государственные услуги были такими же доступными, как заказ товаров в Amazon, — без лишних телодвижений и с любого устройства. А если это невозможно, горожане возмущаются. Нельзя уплатить налоги онлайн? Мы что, в XIX веке?! Сотрудники муниципалитета тоже разочарованы устаревшей организацией процессов в их офисе, которая заставляет впустую тратить время и деньги. Муниципалитету требовалось улучшить клиентский опыт в условиях сокращения бюджета и с минимумом персонала. Задачка была, честно скажем, не из легких. Но в муниципалитете решили, что серьезные проблемы помогают переосмыслить подход к работе. А что если сделать большинство услуг цифровыми? Идея хорошая, но надо понять, как люди пользуются государственными услугами и каковы их потребности. Для этого представители муниципалитета Бристоля обратились в компанию CXpartners.

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

                После сбора данных команда задумалась о том, какие службы можно перевести в онлайн-режим, а для каких нужно личное общение. Пользователей сгруппировали с помощью «шкалы уязвимости». На одном конце были люди, решающие такие задачи, как уплата налогов, — они хотят как можно быстрее разделаться с этой обязанностью, не прибегая к посторонней помощи. На другом конце — те, кто нуждается в консультациях сотрудников комитета по вопросам жилья и ухода: таким горожанам важна поддержка на протяжении всего пути решения задачи. Служащие муниципалитета могли варьировать режим общения в зависимости от специфики услуги и «уязвимости» ее потребителей.

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

                • удобный банк данных, созданный на базе анализа собранной информации, — он давал целостное представление о жителях Бристоля;
                • библиотеку многоразовых шаблонов для дизайна взаимодействия с пользователями;
                • практические навыки дизайна сервисов, которым обучили представителей муниципалитета.

                Сейчас любое изменение государственных сервисов учитывает потребности горожан. Теперь муниципалитет Бристоля может принимать взвешенные решения, которые позволяют улучшать клиентский опыт с минимальными затратами, — а ведь еще недавно казалось, что это невозможно. С момента запуска программы в 2013 году введено в действие 15 новых онлайн-сервисов. За первые полгода около 5000 человек заплатили налоги онлайн. За год число пользователей, которые воспользовались онлайн-бронированием времени для регистрации новорожденных, выросло с 18 до 50%.
                Кейс 26. Answer Lab: цифровой кошелек от PayPal

                Кейс 26. Answer Lab: цифровой кошелек от PayPal


                Покупки в Интернете давно уже стали привычным делом для многих, а электронными деньгами уже никого не удивишь. В компании PayPal подумали: а что если создать мобильное приложение «электронный кошелек» для покупок в обычных офлайн-магазинах. Подумали и… пошли разрабатывать? Нет, пошли проводить исследования. Не самостоятельно, а с помощью компании Answer Lab. В PayPal понимали, что для разработки такого приложения необходимо сначала детально изучить опыт покупок в офлайне.

                Answer Lab предстояло решить четыре задачи:

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

                Задачи были непростые, и команда Answer Lab подошла к заданию творчески: помимо этнографических методов, применили игры. В лаборатории компании создали прототип кофейни, чтобы проверить новую систему мобильных платежей на практике.

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

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

                * * *


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

                И Answer Lab, и CXpartners для решения задачи по разработке нового сервиса пошли в «поле», чтобы понять проблемы людей. И это очень важный момент. Качественный цифровой сервис берет свое начало в повседневной жизни пользователей, а для ее изучения необходимы качественные методы.

                Резюмируя сказанное: в ситуации разработки нового сервиса проектные команды сталкиваются с проблемой отсутствия знаний о пользователях и их повседневной жизни. Если похожий сервис уже существует, для сбора подробной информации о пользователях и их проблемах с действующим сервисом можно ограничиться проведением интервью. Если предстоит разработать сервис, который не имеет аналогов, необходимо дополнительно использовать наблюдение. Интервью и наблюдения позволяют получить информацию о потребностях, поведении, страхах и проблемах пользователей, их жизненных ситуациях, среде использования продукта, повседневности и культурных особенностях. Эти данные помогают разработать нужный и удобный сервис, который органично впишется в повседневную жизнь людей и будет решать реальные задачи.

                Заключение: качественные методы и разработка IT-продуктов в России


                Мы проанализировали опыт зарубежных компаний по использованию качественных методов для решения UX-задач. Анализ кейсов показал, что существует шесть жизненных ситуаций, когда применяется качественная методология:
                • разработка IT-продукта для конкретной группы пользователей;
                • разработка общей платформы для нескольких групп пользователей;
                • разработка профессионального интерфейса;
                • переход на мобильную платформу;
                • выход с IT-продуктом на новый локальный рынок;
                • разработка нового сервиса.

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

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

                Комментарии (0)

                  Let's block ads! (Why?)

                  Расшифровка базы данных KeePass: пошаговое руководство

                  [Из песочницы] Плагин CsvLogWriter для JMeter

                  Введение


                  Наверняка каждый, кто пользовался стандартными листенерами в JMeter, сталкивался со следующими ограничениями:
                  • стандартные листенеры не позволяют получить подробную информацию по всем запросам, прописанным в тест плане;
                  • стандартные листенеры выводят информацию в XML — формате, что осложняет дальнейший анализ логов средствами Excel и IPython.

                  Чтобы обойти данные ограничения, было принято решение переработать формирование лог-файлов с помощью нового плагина CsvLogWriter.

                  Поставленные задачи


                  Необходимо было разработать плагин для JMeter, который обладал бы следующими функциональными возможностями:
                  • вывод полного текста ошибки в строковом формате;
                  • фиксация данных по дочерним подзапросам.

                  В стандартных листенерах для JMeter фиксация полного содержания ошибки возможна в XML-формате, что доставляет неудобства для анализа. Возникла потребность сохранять текст ошибки в строковом формате с последующей записью, например, в CSV-формат для обеспечения возможности построения графиков в Excel и IPython. Обычно получаемые лог-файлы не отображают данные по дочерним подзапросам. Что крайне неудобно при использовании сложной структуры тест-плана. Пример структуры продемонстрирован на рисунке 1.


                  Рисунок 1. Структура тест-плана

                  При использовании стандартных листенеров мы сможем получить данные только по Transaction Controller1. Исходя из этого было решено добавить фиксацию данных по дочерним подзапросам, таким образом получить результаты мы сможем по Transaction Controller1, Transaction Controller 2 и вложенным в него семплерам.

                  Описание функционала плагина pflb@CsvLogWriter


                  В ходе работы был написан плагин pflb@CsvLogWriter для JMeter. К ключевым особенностям данного плагина можно отнести то, что он может фиксировать результаты работы дочерних подзапросов и записывать полный текст ошибки, при ее возникновении, в виде обычного текста, а не в XML-формате.
                  Формат лога

                  Данные, фиксируемые в лог-файле, представлены в таблице 1.
                  Таблица 1. Формат лога
                  Имя Тип Описание Примеры значений для колонки лога Единица измерения
                  1 timeStamp long Время начала или конца запроса мс
                  2 elapsed long Длительность обработки запроса: endTime — startTime — idleTime 49, 434 мс
                  3 label String Наименование компонента JMeter
                  4 responseCode String Код ответа на запрос «200», «Non HTTP response code: java.net.UnknownHostException»
                  5 responseMessage String Расшифровка кода ответа «OK», «Internal Server Error»
                  6 threadName String Имя потока «Thread Group 1-1»
                  7 dataType String Тип данных в ответе, на практике принимает два значения — «bin» или «text» «bin», «text»
                  8 success boolean Статус успешности выполнения запроса true или false
                  9 failureMessage String Сообщение об ошибке,
                  в случае срабатывания Assertion-компонента,
                  добавленного к Sampler-у.
                  В CsvLogWriter в поле записываются сообщения
                  ото всех Assertion-компонентов,
                  выполнение которых сгенерировало ошибку.
                  В базовом логере записывается только первое сообщение.
                  10 bytes int Размер ответа.
                  Значение и алгоритм расчёта зависят от настроек
                  sampler-а. На значение могут влиять responseData.length,
                  headersSize, bodySize.
                  Байт
                  11 grpThreads int Количество активных потоков в текущей группе
                  12 allThreads int Количество активных виртуальных пользователей всех групп
                  13 URL String Ссылка
                  14 Filename String Наименования файла, в который записываются ответы.
                  Поле заполняется при использовании Save Response to File Listener.
                  Этот Listener редко используется, обычно значение колонки
                  — пустая строка
                  15 Latency int Время до получения первого ответа сервера.
                  Эта временная задержка включает в себя время,
                  потраченное на соединение с сервером,
                  задержки, обусловленные установкой защищённого соединения,
                  и внутренними задержками JMeter на получение
                  первых байт ответа сервера. Если по какой-то причине
                  работа Sampler-а была приостановлена, а потом возобновлена,
                  то значение Latency будет скорректировано
                  на длительность приостановки Sampler-а.
                  мс
                  16 Encoding String Кодировка. Возвращается кодировка ответа,
                  если кодировка ответа не задана,
                  то возвращается значение кодировки по умолчанию.
                  Значение кодировки по умолчанию задано в
                  «sampleresult.default.encoding».
                  Для HTTP Request значение по умолчанию «ISO-8859-1».
                  «ISO-8859-1», «UTF-8»
                  17 SampleCount int Количество семплов.
                  Для HTTP Request значение равно 1.
                  Для JMS Sampler, выполняющего подписку на события
                  и чтение нескольких сообщений за раз,
                  значение равно количеству циклов опроса
                  или количеству прочитанных сообщений.
                  Значение всегда больше или равно одному.
                  1, 2 шт
                  18 ErrorCount int Количество ошибок.
                  Для HTTP Request значение равно 0 если success
                  и равно 1 если запрос не успешный.
                  Для других sampler-ов выполняющих обработку
                  нескольких сообщений за раз,
                  значение может быть больше 1.
                  0, 1 шт
                  19 Hostname String Наименование машины
                  20 IdleTime int Время простоя мс
                  21 Connect int Время, затраченное на установку соединения мс
                  22 headersSize int Размер заголовков Байт
                  23 bodySize int Размера тела Байт
                  24 contentType String Тип содержимого из заголовка ответа
                  25 endTime long Время конца запроса мс
                  26 isMonitor boolean Признак поставлена ли галочка Use as Monitor true, false
                  27 threadName_label String Наименование треда и компонента JMeter
                  28 parent_threadName_label String Наименование треда и компонента JMeter родителя
                  29 startTime long Время начала запроса мс
                  30 stopTest boolean Признак остановлен ли тест — кнопка Stop.
                  Также в настройках Thread Group есть опция
                  «Stop Test» при ошибке. Если в колонке «stopTest»
                  стоит true, значит произошла именно такая ситуация.
                  Сценарий прервался на текущем запросе.
                  true, false
                  31 stopTestNow boolean Признак остановлен ли тест резко — кнопка Shutdown.
                  Также в настройках Thread Group есть опция
                  «Stop Test Now» при ошибке. Если в колонке «stopTestNow»
                  стоит true, значит произошла именно такая ситуация.
                  Сценарий прервался на текущем запросе.
                  true, false
                  32 stopThread boolean Признак остановлен ли текущий поток.
                  В настройках Thread Group есть опция «Stop Thread»
                  при ошибке. Если в колонке «stopThread» стоит true,
                  значит произошла именно такая ситуация.
                  Сценарий прервался на текущем запросе.
                  true, false
                  33 startNextThreadLoop boolean Стартует ли повтор.
                  В настройках Thread Group есть опция «Start Next Thread Loop»
                  при ошибке. Если в колонке «startNextThreadLoop» стоит true,
                  значит произошла именно такая ситуация.
                  Сценарий прервался на текущем запросе.
                  true, false
                  34 isTransactionSampleEvent boolean Признак того, что текущее событие является транзакцией (TransactionController). То есть, это лишь группирующий элемент. true, false
                  35 transactionLevel int Уровень вложенности запроса.
                  Если используется иерархия Transaction Controller
                  или у подзапросов есть подзапросы,
                  то в данной колонке будет уровень вложенности.
                  0 для корневого запроса или корневого Transaction Controller.
                  1 для подзапроса, родитель которого является корневым.
                  36 responseDataAsString String Полное содержание ошибки в формате строки
                  в случае ее возникновения, если success == false,
                  то в responseData будет содержаться полное тело ответа
                  37 requestHeaders String Заголовки запроса
                  38 responseData String Полное содержание ошибки в случае ее возникновения,
                  если success == false, то в responseData будет содержаться
                  полное тело ответа, перекодированное в base64
                  39 responseHeaders String Заголовки ответа
                  40 <Имя переменной> String Переменные JMeter

                  Структура лога расширяет базовый формат CSV лога. С базовым набором параметров можно ознакомиться по ссылке http://ift.tt/2bCkRVm

                  Полученный CSV-лог можно загрузить любым базовым Listener-ом JMeter, поддерживающим загрузку CSV-лога.
                  Также в логе появились дополнительные колонки, которые могут пригодится при анализе (стр. 22-35 таблицы Формат лога).
                  Тела и заголовки ответов и запросов записываются только при ошибках (стр. 36-39 таблицы Формат лога).
                  Также в лог запишутся колонки для переменных: http://ift.tt/2bs43mt — описание возможности логировать значения переменных.

                  Интерфейс


                  Для запуска плагина необходимо заполнить поле Filename. Поле Filename содержит путь к файлу, в котором будет вестись фиксация результатов работы. Можно прописать директорию вручную, или выбрать файл используя кнопку Browse. Если указанный файл существует, то создается новый файл. Наименование нового лог-файла формируется добавлением постфикса с номером лог-файла к оригинальному наименованию.

                  Так же на форме расположены флажки. С помощью флажков можно манипулировать данными, фиксируемыми в логе. Флажок Additional parameters отвечает за фиксацию дополнительных параметров (22-35 строки в таблице Формат лога), Response data отвечает за фиксацию текста ошибок (36-39 строки в таблице Формат лога), User variables отвечает за фиксацию пользовательских переменных.

                  Интерфейс плагина представлен на рисунке 2.


                  Рисунок 2. Интерфейс плагина CSVLogWriter

                  Сравнение плагина CSVLogWriter и Simple Data Writer


                  В данном разделе попробуем провести сравнение плагина CsvLogWriter и стандартного листенера Simple Data Writer.
                  Состав логируемых данных

                  Листенер Simple Data Writer дает пользователю возможность настроить список фиксируемых данных. На рисунке 3 показано окно настроек выводимых данных.


                  Рисунок 3. Окно настроек фиксируемых данных листенера Simple Data Writer

                  Плагин CsvLogWriter всегда выводит базовый перечень параметров (аналогичный Simple Data Writer) и позволяет настроить вывод списка дополнительных данных с помощью 3 флажков на форме:

                  • Additional parameters — дополнительные параметры (22-35 строки в таблице Формат лога);
                  • Response data — тексты ошибок (36-39 строки в таблице Формат лога);
                  • User variables — пользовательские переменные (для вывода необходимо запускать JMeter с ключом -Jsample_variables).

                  Детальный перечень фиксируемых данных жестко прописан в коде. Но, как видно на рисунке 3, Simple Data Writer не может выводить текст ошибки в строковом формате. Полный текст ошибки фиксируется только в XML формате. По этой причине в случае, когда нам необходим текст ошибок приходится вести 2 лога — 1 в CSV-формате (если необходима дальнейшая обработка лога с построением графиков в Excel или iPython) и 1 в XML-формате.
                  Логирование подзапросов

                  Так же, листенер Simple Data Writer не фиксирует результаты работы дочерних подзапросов, соответственно, такой лог-файл нельзя назвать исчерпывающим. Для наглядного сравнения объема выводимых данных запустим тест, соответствующий тест-плану на рисунке 1, и посмотрим на лог-файлы. Лог-файл SimpleDataWriter представлен на рисунке 4.


                  Рисунок 4. Лог-файл Simple Data Writer

                  Как видно на рисунке 4, SimpleDataWriter выводит информацию только по Transaction Controller1. В свою очередь, плагин CsvLogWriter за счет обработки дочерних подзапросов выводит гораздо больше информации. Содержание лог-файла плагина CsvLogWriter представлено на рисунке 5.


                  Рисунок 5. Лог-файл CsvLogWriter

                  Сравнение быстродействия


                  Так же проводился анализ быстродействия метода SimpleOccured, отвечающего за обработку событий. Профилирование велось в Java VisualVM. В тест плане не использовались подзапросы. Для SimpleDataWriter тестирование запускалось с записью в 1 CSV-файл и с записью в 2 файла — CSV и XML. Количество виртуальных пользователей составляло 10, количество повторение 100. Итоги сравнения приведены в таблице 2.

                  Таблица 2. Сравнение быстродействия SimpleDataWriter и плагина CsvLogWriter

                  CsvLogWriter SimpleDataWriter (CSV+XML) SimpleDataWriter (CSV)
                  Длительность (мс), количество вызовов Длительность (мс), количество вызовов Длительность (мс), количество вызовов
                  215, 2000 23076, 4000 101, 2000

                  Выводы:
                  • CsvLogWriter в 10 раз быстрее SimpleDataWriter (XML с максимальной детализацией);
                  • CsvLogWriter в 2 раза медленнее SimpleDataWriter (CSV с максимальной детализацией);
                  • SimpleDataWriter (XML с максимальной детализацией) в 20 раз медленнее SimpleDataWriter (CSV с максимальной детализацией).

                  Ссылка на плагин


                  http://ift.tt/2bs3usX

                  Комментарии (0)

                    Let's block ads! (Why?)