-Поиск по дневнику

Поиск сообщений в comdersrek

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 10.12.2014
Записей:
Комментариев:
Написано: 99





[Перевод] О важности User Stories

Суббота, 18 Июня 2016 г. 18:39 + в цитатник
Здравствуйте, уважаемые читатели. Сегодня мы хотели бы поговорить с вами о важном аспекте гибкого управления проектами, но не о чистом Agile, а о планировании проекта и итераций. Речь пойдет о жанре «Пользовательских историй», которым посвящена очень успешная на Западе книга Джеффа Паттона с предисловием Мартина Фаулера: В статье, текст которой вас ждет под катом, мы перевели «User Story Mapping» как «визуализация функционала». Вариант взят из очень интересной книги Бориса Вольфсона "Гибкое управление проектами и продуктами", также выходившей в нашем издательстве. Итак, автор статьи прочитал труд Паттона и решил, что так должен поступить каждый. Насколько убедительные примеры он привел — судить вам. Одна из ключевых целей при планировании проекта – общими усилиями собрать требования. Но зачастую бывает сложно решить, с чего начать и на чем сосредоточиться. Визуализация функционала (story mapping) – увлекательная работа, где все члены команды участвуют в формировании списка требований (бэклога) – расклеивают карточки на стене, а не пишут скучную 100-страничную спецификацию. Такой способ визуализации функционала изобрел Джефф Паттон, а мне об этом рассказал Шираг Доши. Я считаю, что это очень эффективный и полезный способ фиксации требований на этапе продумывания проекта. Чертим карту функционала Визуализация функционала — это нисходящий способ сбора требований, которые представляются в древовидной форме. Перед началом визуализации нужно обрисовать себе весь проект целиком. Для этого расставляются цели. Для достижения цели нужно выполнить те или иные действия. А для выполнения действия пользователь должен решить задачу. При разработке ПО конкретные задачи могут быть сформулированы в виде пользовательских историй. Структура карты: Цели — Действия — Задачи — Истории Рассмотрим для примера приложение для работы с интернет-магазином, в рамках обращения с которым выделим конкретную цель:‘найти товар’. Чтобы лучше понять весь процесс, визуализируем этот функционал на карте. Достичь цель ‘найти товар’ можно несколькими способами, например, ‘просмотреть дерево с каталогом товаров’, ‘воспользоваться текстовым поиском’, ‘посмотреть промо-товары’. Остановимся на втором варианте – «просмотрим дерево с каталогом товаров» и визуализируем такой функционал. ‘ Далее, чтобы добраться до желаемого товара, пользователь должен выполнить определенные задачи, А теперь эти задачи можно сформулировать в виде пользовательских историй и перейти к разработке программы. Так и продолжаем подробно прорабатывать каждую ветку функционала, начиная с целей и достраивая целостную карту. По моему опыту, на полную визуализацию функционала может уходить от трех дней до двух недель в зависимости от размера и сложности проекта. Для справки: вот «ветка» из одной визуализации функционала, взято из реального проекта, А вот как выглядит вся карта после пяти дней работы: Итак, разобравшись с визуализацией функционала, давайте обсудим, каковы достоинства такого подхода. Преимущества визуализации функционала Визуальное представление бэклога (общая картина) позволяет всем заинтересованным поработать в одной плоскости, вместе оценить объем и сложность работы. Кроме того, эта работа косвенно помогает понять масштабы проекта. При фиксации требований на бумаге улучшается взаимодействие и формируется общее понимание работы. Поскольку время на разработку проекта обычно ограничено, визуализация функционала помогает глубоко погрузиться в проект и сосредоточиться на важных аспектах приложения. Если помечать «желаемые» фичи как «вторичные», то вся команда экономит время на разработку. Интересно, что если расклеить на стене все «истории», то команде становится проще соотносить их размеры. Структурирование проекта в виде карты помогает приоритезировать задачи и с легкостью сегментировать бэклог на релизы, конкретизируя минимально жизнеспособную версию каждого релиза. Сегментирование может быть горизонтальным или вертикальным: например, выделяем ограниченное число фич, либо выделяем много фич, но в каждой из них обозначаем уровень минимальной жизнеспособности. Визуальную карту можно преобразовать в бэклог при помощи специальных инструментов для Agile-разработки, например, Mingle. Обогащаем получившуюся карту дополнительной информацией Иногда требуется зафиксировать на карте проекта сравнительно много информации – например, пометить вопросы, возникшие в ходе работы, альтернативные подходы… все это также попадает в визуализацию. Вот несколько практических примеров: Разными цветами обозначаем различные уровни карты. Например, цели будут оранжевыми, фичи – голубыми, сюжеты – зелеными, а истории – желтыми. Рядом с соответствующей областью карты размещается каркасная модель. Организуем специальную нотацию при помощи особых стикеров – например, в виде точек или звездочек: Важно помечать и вторичные фичи, чтобы у всех было общее представление о проекте Важно выделять альтернативные возможности, чтобы UX получался более насыщенным, а неосновные решения были не слишком затратными На маленьких стикерах ставим пометки, записываем предположения, предварительные выводы или вопросы Альтернативные способы визуализации функционала При визуализации функционала важно сначала определиться со структурой, а затем дорабатывать ее по мере необходимости. Необходимо уже в самом начале работы представлять себе структуру проекта и отталкиваться от нее. Иногда целостная структура получается только спустя две-три итерации. Один вариант альтернативной структуры называется‘пользовательские путешествия’. Такой подход помогает определиться с требованиями с точки зрения пользователя – например, покупателя, продавца, администратора, т.д. В таком случае визуализация приобретает вид Пользователь — Цели — Путешествия — Действия — Истории. Другая альтернатива, особенно при разработке NFR (нефункциональных требований) может быть такой: NFR — Требование — История. Полная карта больших проектов может содержать до шести уровней. Однако в типичном проекте обычно достаточно 3 уровней. Подготовка к визуализации функционала Итак, вы твердо намерены начинать следующий проект с визуализации функционала. Вот что для этого потребуется: Большой конференц-зал со свободными стенами, который будет в вашем распоряжении на весь срок продумывания проекта. Разноцветные стикеры, по одному стикеру на каждый уровень. Жирные маркеры, чтобы надписи на стикерах легко читались издалека. Особые стикеры (точки или звездочки) – чтобы фиксировать на карте дополнительную информацию. Маркерная доска, на случай, если в каких-то местах клеить стикеры на стены будет неудобно. Хороший фотоаппарат, чтобы сфотографировать всю карту. Делюсь опытом Занимаясь визуализацией функционала, я часто сталкивался с проблемами и преодолевал их. Далее – несколько советов о том, как избежать распространенных ошибок и успешно справиться с визуализацией. На этапе визуализации функционала мы знакомимся с требованиями к продукту, и поэтому обязательно фиксируем все возможности вместе с альтернативами, чтобы избежать бесконечных дискуссий. Вдаваясь в подробности, регулярно расставляем приоритеты, чтобы не тратить времени на маловажные темы. Регулярно убираем ненужные стикеры, чтобы они не превратились в огромную неоглядную кучу. Оставляем удобные проходы вдоль стен. Работая со стикерами, следим, чтобы они не загибались и не слипались на протяжении всего проекта – иначе их будет сложно рассмотреть на фотографиях. Заключение Визуализация функционала – эффективный механизм продумывания требований к проекту, поскольку он очень нагляден. Такой подход помогает прийти к общему пониманию проблемы, выделить имеющиеся пробелы в бэклоге, уловить взаимозависимости, точнее оценить относительные размеры этапов проекта. В дальнейшем такая визуализация помогает правильно сегментировать проект и адекватно спланировать время на подготовку всех релизов.

Метки:  

Некачественный мир открытых госфинансов

Пятница, 17 Июня 2016 г. 20:40 + в цитатник
Источник картинки: indianexpress.com/article/business/budget/budget-2016-rs-25k-cr-falls-short-of-psu-banks-hopes Открытые данные (как и все остальные направления) развиваются в России своеобразно: сложно понять и привыкнуть к тому, что о доходах и расходах государства узнать намного проще, чем об экологии, образовании, здравоохранении. При этом федеральные и региональные ведомства публикуют в основном реестры подведомственных учреждений, списки актуальных вакансий и адреса культурных учреждений и аптек (весьма “заезженные” массивы данных с ограниченными областями применения). Финансовые государственные органы смотрят на открытость намного шире: Министерство финансов регулярно публикует данные о сводной бюджетной росписи (расходы федерального бюджета), открывает исторические бюджеты, проводит конкурсы и встречи для разработчиков Региональные и муниципальные финансовые органы размещают информацию о бюджетах, их проектах, отчетах об исполнении бюджетов (да, не всегда качественно, не всегда в одном месте, но данные есть и ими можно пользоваться). В цифрах: примерно 90 региональных и 23 000 муниципальных бюджетов в год. Федеральное казначейство размещает реестры субсидий, участников и неучастников бюджетного процесса, данные о государственных контрактах. В цифрах: реестр участников бюджетного процесса насчитывает более 150 тыс. записей, количество записей о государственных контрактах приближается к 20 миллионам. Ряд других ведомств, таких как ФНС, тоже начинают совершать первые действия по открытости. Предоставление базовых данных из ЕГРЮЛ в машиночитаемом формате и бесплатно, естественно, не планируется, но попытку найти что-то интересное в их данных все же можно совершить. В целом, работа госорганов в этом направлении не может не радовать, за что отдельное спасибо Минфину и Казначейству (на правах пиара и рекламы данных), открытым к диалогу и запросам разработчиков. Одна большая проблема только в том, что во всей этой деятельности отсутствует системный подход, вследствие чего данные публикуются где угодно (попробуйте, например, собрать бюджеты всех муниципалитетов Санкт-Петербурга) и как угодно (а затем все эти бюджеты изучить, выявить ошибки и попробовать доказать муниципалитетам, что их данные не верны), а их качество оставляет желать лучшего. Из очевидных спорных моментов можно выделить следующее: Расстановка приоритетов Несмотря на наблюдение за работой Минфина с момента объявления “курса на открытость” (2012-2013 год), для меня до сих пор остается загадкой приоритизация раскрытия данных. Одной из основных мотиваций для запуска этого направления в России было вхождение в ТОП-5 в международном рейтинге Open Budget Index. Он складывается из двух показателей: прозрачность (доступ к информации и данным) и возможность участия граждан в бюджетном процессе. Со вторым показателем у нас пока все плохо (и в этом “виновато” не только государство, но и сами граждане), а вот о первом можно порассуждать. С точки зрения доступа к информации о расходах и доходах (не рассматриваем критерий “машиночитаемость”) — Россия если и не лидер в мире, то в первой тройке-пятерке точно: информация раскрывается на федеральном, региональном, муниципальном уровнях. Но выбор массивов для раскрытия вызывает вопросы, и, если раньше стандартным объяснением было: “мы не знаем, что вам [разработчикам] нужно”, то сейчас отсылка идет на проведенные Минфином опросы о востребованности финансовых данных. В опросах были перечислены такие интересные данные, как реестры расходных обязательств, федеральный бюджет, перечни публичных нормативных обязательств и еще около 30 пунктов, а в итоге опубликованы в этом году будут данные об алмазах, изумрудах и других драгоценных камнях (нужно отметить, что 2-3 интересных новых набора все же будут). За четыре года я не встретила ни одного российского или зарубежного человека, который бы интересовался российскими данными об алмазах (о продаже нефти, “госконтрактных” данных, бюджетах, финансировании СМИ спрашивают, а кто “голосовал” за открытость изумрудов для меня остается загадкой). Вопрос о сомнительном выборе данных для раскрытия не возник бы, если бы были опубликованы “базовые” данные, к которым, в первую очередь, относится федеральный бюджет (т.е. Закон “О федеральном бюджете”). Это не только основной показатель для рейтингов (Open Budget Index, Open Data Barometer), ради которых все и затевалось, но и основной финансовый документ, по которому живет и функционирует государство. Сводная бюджетная роспись (расходы федерального бюджета) публикуется в машиночитаемом формате и обновляется на сайте Минфина, а всех остальных данных из закона “О федеральном бюджете” (доходы, различные нормативы, субсидии и т.д.) в машиночитаемом виде нет. Данные регионов и муниципалитетов в XLS и CSV публикуются (не всеми, но многими), данные по контрактам и отчетам об исполнении бюджетов тоже есть, а вот федеральный бюджет у нас до сих пор только в PDF. Хотя по официальной позиции (трижды озвученной на встречах с разработчиками) “раскрытию ФЗ “О федеральном бюджете” ничего не препятствует и это будет сделано”. Вот только после появления этих данных сказать о том, что “и года не прошло” уже не получится. Прошло. Низкое качество данных Предположим, вам повезло и вы нашли нужные данные (даже вдвойне повезло — они не только есть, но и машиночитаемые). Радость от их наличия обычно длится недолго — примерно до первой попытки в них разобраться: структура бывает запутанной (передаю привет “лесенке” Минфина, малопригодной и для программиста, и для “обычного человека”), документация практически всегда отсутствует. Понять базовые данные, такие как бюджеты и контракты, можно, но сложно, — Бюджетный кодекс, системно описывающий бюджетную систему, и Альбомы ТФФ, документирующие данные о госконтрактах и госзакупках, подробны, но объемны и усыпаны специфической терминологией (что, безусловно, снижает привлекательность этих данных для разработчиков). Основные проблемы начинаются при детальном рассмотрении и попытке использовать и сопоставлять данные: Официальные данные, полученные с сайта zakupki.gov.ru, пестрят наличием опечаток в названиях организаций, путаницей с указанием валюты (о количестве контрактов, заключенных в австралийских долларах мы рассказывали в рассылке по госфинансам на прошлой неделе), путаницей в размерности (данные указываются в тысячах, когда должны быть указаны в рублях), ошибками в ИНН (фантазия физлиц при заполнении полей “ИНН/КПП” безгранична; логика представителей организаций, указывающих ИНН банка вместо ИНН своей организации не поддается объяснениям). С бюджетами не лучше. При их формировании и/или публикации неверно используются классификаторы (например, отсутствуют ведущие нули, цифра “0” заменяется буквой “о”), используются битые ссылки (например, на другие xls файлы с компьютера Маши из администрации муниципалитета), реже встречаются расхождения в суммах или некорректное понимание представителями муниципалитетов тонкостей Бюджетной системы РФ (например, МО Дворцовый использовал в 2015 году одинаковые коды для муниципальных программ, что недопустимо согласно официального ответа Комитета финансов СПб). Подробнее поговорить о качестве данных можно на хакатоне Budget Stories, который пройдет 25-26 июня в Санкт-Петербурге (меня позвали поучаствовать в нем в роли ментора, поэтому не буду скрывать свою личную заинтересованность в привлечении тех, с кем можно обсудить финансовые данные, их качество и идеи приложений). Отсутствие ответственных и низкая заинтересованность в повышении качества данных Исправить опечатки, привести адреса и телефоны к единому формату трудозатратно, но реализуемо. Сложнее разобраться с содержательными ошибками, для устранения которых требуются комментарии первоисточника. В случае с муниципальными данными (в основном с бюджетами) сложно вдвойне — уровень ИТ-грамотности и понимания специфики “открытых данных” на муниципальном уровне объективно ниже, задач и проблем и без открытых данных полно. Кроме того, формально муниципалитеты не являются третьим уровнем власти, то есть на качество их данных ни Минфин, ни региональные госорганы повлиять не могут. И, если проблема не устраняется взаимодействием с источником данных, то следующей инстанцией официально является Прокуратура, обращение в которую не является “позитивным” способом решения проблемы и вряд ли поспособствует продолжению коммуникаций с муниципалитетом (если вы планируете, например, выступать с предложениями). С госконтрактами и другими данными, полученными на zakupki.gov.ru, ситуация аналогичная — в общих словах Казначейство “реализовало предупреждающий контроль на соответствие информации о поставщиках, указанной пользователем, сведениям ЕГРЮЛ/ЕГРИП”, а в официальных ответах на конкретные вопросы с примерами неверных данных идет отсылка на “персональную ответственность, которую несет лицо, имеющее право действовать от имени заказчика”. Резюмируя: данных о госфинансах много, они интересны, не всегда качественные и сложны. А они вам нужны? Может быть вы их уже используете? А если нет, то какие причины останавливают? В любом случае спасибо за работу по открытости и, для справедливости, надо заметить, что одно оправдание у Минфина все-таки есть — им не хватает обращений и фидбека по качеству данных от разработчиков. Понятно, что оставлять официальные обращения на сайте госорганов не особо удобно (а в случае с Минфином нужно еще потратить время на выбор неочевидных категорий), но можно написать им письмо на opendata@minfin.ru (в одиночку у меня не получилось сдвинуть счетчик обращений с нуля), оставить комментарий на странице в фейсбуке или даже отметить “федеральный бюджет” и другие полезные массивы данных в опросе о востребованности данных. Кстати, представители Казначейства на встрече с разработчиками объявили, что ни одно обращение по поводу данных не остается неотвеченным, проверим? ;-)

Метки:  

Куда пойти Python’исту: Что интересного будет на конференции PyCon-2016

Пятница, 17 Июня 2016 г. 19:09 + в цитатник
3-4 июля состоится PyCon — ежегодная конференция по вопросам разработки на Python. Формат мероприятия — двухдневная конференция на природе, в ходе которой своим опытом поделятся иностранные и российские эксперты в области программирования. Чего ждать Предыдущие мероприятия проходили в Екатеринбурге, а в этом году PyCon переезжает в Москву, точнее в Подмосковье — конференция состоится в отеле «Cronwell Яхонты Таруса» в 95 км от столицы. Как пишут организаторы, в программе конференции «20 докладов, 2 воркшопа, Lightning Talks, дискуссионная панель, Unconference, афтепати с костром и песнями». Среди докладчиков Raymond Hettinger (Python core developer с 2001 года, автор и мэйнтейнер многих частей языка, США), Martin Gorner (Google, Франция), Nathaniel Manista (Google, США), Armin Ronacher (Flask framework, Австрия), David MacIver (Hypothesis, Великобритания), Jackie Kazil (Capital One, США), Александр Кошкин (Positive Technologies, США), Александр Сибиряков (Scrapinghub, Чехия), Андрей Светлов (DataRobot, Украина), докладчики из HeadHunter, Rambler&Co, Яндекса, Toptal и другие. В блоге организаторов мероприятия на «Хабре» можно прочитать интервью с некоторыми из докладчиков: Как живут и работают разработчики в Чехии: интервью с Александром Сибиряковым из Scrapinghub Интервью с автором Flask Армином Ронахером Интервью с Андреем Светловым о языке Python и не только Positive Technologies на PyCon Наша компания принимает активное участие в PyCon: Positive Technologies является генеральным партнером мероприятия, с докладами на нем выступят члены нашей команды из Бостона, Санкт-Петербурга и Нижнего Новгорода. Разработчики поделятся с коллегами опытом в создании распределенных систем, работе с server-side инструментами (например, Docker) и расскажут о разработке наших продуктов (в частности, MaxPatrol SIEM). Кроме того, на конференции будут присутствовать представители руководства компании и сотрудники HR, которые смогут рассказать об актуальных проектах и планах компании в области разработки новых продуктов. На стенде Positive Technologies все желающие смогут получить сборник исследований по практической безопасности Positive Research, который был представлен на PHDays VI (подробнее о документе рассказывал Андрей Прозоров). Приходите, будет интересно! Зарегистрироваться можно на сайте мероприятия: pycon.ru/2016/register

Метки:  

High-Density WiFi. Часть 3: О технологиях. Часть 4: о деньгах

Пятница, 17 Июня 2016 г. 07:24 + в цитатник
«Переходи в мою команду и никогда не будешь вторым» Жозе Моуриньо Теперь поговорим о каждом блоке, из которого строятся правильные HD WiFi сети Аруба. Начнем с самого важного блока HD WiFi инфраструктуры – блока оптимизации радиосреды, без которого работа HD сети невозможна в принципе. Еще раз, кратко напомню основные сложности построения HD WiFi сетей: WiFi работает в нелицензируемом спектре – огромное количество источников интерференции Часто WiFi сети пересекаются между собой, конкурируя за радиоресурс Множество не-WiFi устройств могут влиять на WiFi сеть, снижая ее производительность (Bluetooth, AV Systems, и т.д.) Радиосреда в HD сетях очень динамична, меняется крайне быстро и наплывами Для того, чтобы сеть нормально функционировала в сложной HD среде и каждому пользователю предоставлялся максимальный уровень сервиса, Аруба имеет несколько встроенных механизмов оптимизации, кратко суммированных в таблице ниже: Таблица 1. Механизмы оптимизации WiFi Оптимальное распределение радиоканалов Оптимальное распределение клиентов Оптимальное управление мощностями Оптимальное управление доступом Равномерное распределение каналов при помощи механизма Advance Radio Management (ARM) Переключение неиспользуемых каналов на другие задачи (используя ARM Aware Mode) Включение на DFS каналы, где это возможно Band Steering (переключение клиентов на 5 Ghz, не 2.4Ghz, где возможно) Равномерное распределение клиентов (используя механизм Spectrum Load Balancing) Ограничение EIRP, чтобы сократить «радиоразмер» точки и зоны перекрытия между ними Контроль излучаемой мощности на клиентах, с использованием 802.1h TPC Уменьшение влияния CCI/ACI на решения о переиспользовании каналов, оптимизируя чувствительность с помощью Receive Sensitivity Tuning Channel Reuse Управление доступом к радиосреде при помощи функционала Airtime Fairness Ограничение «chatty» протоколов Multicast Rate Optimization и IGMP Snooping Исключение старых, низкоскоростных подключений за счет уменьшение Rate Adaptation Основная нагрузка по оптимизиции радиочасти сети ложится на ARM механизм, который обеспечивает следующий функционал WiFi сети: Оптимальным образом распределяет клиентов по доступным в сети радиоканалам, а не по точкам доступа (Spectrum Load Balancing), когда ключевым параметром для выбора канала является количество клиентов на канал, а не количество клиентов на точку доступа Переключает dual-band клиентов, у которых поддерживаются оба диапазона 2.4Ghz и 5Ghz, в диапазон 5Ghz (Band Steering) Устанавливает каждому клиенту временные ограничения на доступ к среде, равномерно распределяя нагрузку между ними (Air-Time Fairness) Еще один очень важный механизм оптимизации радиосреды при развертывании HD WiFi — Cell Size Reduction (CSR), который позволяет за счет искусственного завышения порога чувствительности точки (RST, Receive Sensitivity Tuning-Based Channel Reuse) обеспечить определенный иммунитет к интерференции типа ACI и, отчасти, CCI. Чувствительность на прием (Receiving Sensitivity) точки определяет минимальный уровень сигнала, на котором устройство может принять и декодировать WiFi кадр. Если кадр WiFi приходит с уровнем сигнала ниже порога, то точка его не декодирует и рассматривает как шум на канале. В случае HD WiFi, уровень сигнала как на точке, так и на клиенте всегда будет достаточно высоким из-за близкого расстояния между ними и основные сбои в сети происходят по причине интерференции, а не уровня сигнала. Поэтому RST алгоритм меряет уровни сигнала между точкой и ассоциированными с ней клиентами и устанавливает уровень чувствительности точек, основываясь на слабейшем уровне сигнала от ассоциированных с точкой клиентов. Процесс это динамический, уровень чувствительности подстраивается под текущую радиообстановку. Таким образом, сигнал с удаленных точек и клиентов, не ассоциированных с данной точкой, игнорируется и канал может быть переиспользован на данной точке. Еще один механизм, позволяющий сберечь ресурс радиосреды – наложение ограничений на не обязательные бродкасты, мультикасты и «chatty» протоколы. Например, передавать всем устройствам в домене ARP запрос — это накладно и не всегда необходимо. Сеть Аруба может конвертировать бродкаст трафик в юникаст запрос на конкретного клиента («broadcast-filter-arp») или, если в сети начинаются бродкаст штормы, отфильтровать весь бродкаст/мультикаст трафик («broadcast-filter-all»). Использовать этот механизм нужно с осторожностью, чтобы не отфильтровать весь полезный трафик, например, комадну «broadcast-filter-all» нужно использовать только вместе с «broadcast-filter-arp». «Chatty»-протоколы тоже «съедают» много ресурсов и Аруба в своих HD сетях настоятельно рекомендует ограничивать их трафик при помощи ACL, например: Ограничить, с какими устройствами пользователи могут работать в HD домене (например, в CLI при помощи команды firewall local-valid users) Отключить IPv6, если он не нужен Отключить netbios-ns, netbios-dgm, mDNS, UPnP и SSDP, если они не нужны (большинство устройств, которые реально используют этит протоколы – «проводные» компьютеры и вполне могут обойтись без них в беспроводной сети) Постараться отфильтровать разные случайные ошибки (например, отфильтровать заранее 68 UDP порт, чтобы клиент не мог случайно стать DHCP сервером) Запретить STP В заключении разговора про радиооптимизацию, хотелось бы упомянуть еще о таком важном моменте, как роуминг. И не просто роуминг, а inter-band роуминг, когда клиент по мере движения по WiFi инфраструкруте переходит из диапазона 5Ghz в 2.4Ghz и обратно. Такая задача часто возникает при переходе из закрытых помещений (где сейчас чаще используется 5Ghz) в открытые (где чаще используется 2.4Ghz). Как правило, большинство вендоров справляются с быстрым роумингом внутри диапазона, но, как только клиент переходит между каналами в разных диапазонах и у клиента в момент перехода по каналу идет чувствительный к задержкам трафик (например, голосовой или видео звонок), в большинстве случаев, возникает задержка на несколько секунд и соединение разрывается. Проблема быстрого междиапазонного роуминга достаточно комплексная и причин, по которым прерывается связь, может быть несколько. Чаще это связано с ограничениями и особенностями работы клиента. Но, если клиент современный и поддерживает такие расширения 802.11 стандарта, как 802.11r, 802.11к и/или 802.11v (позволяющие кэшировать данные сессий аутентификации/авторизации и «видеть» топологию сети вокруг себя), то вендор из премьер-лиги, как правило, имеет технологии, позволяющие организовать междиапазонный роуминг без перерывов связи. В Арубе такая технология называет ClientMatch. Она позволяет, при определенных условиях, быстро «перекинуть» клиента на новый канал без стандартной процедуры сканирования эфира, что в разы сокращает время перехода клиента на новую точку. Теперь поговорим о не менее важном блоке решения – встроенной системе сетевой защиты. В беспроводном мире Аруба известна, в том числе, высоким уровнем безопасности своих решений. Аруба – первый вендор, поддержавший стандарт 802.11i (WPA2), первый вендор, у которого появился интегрированный Wirelss IPS (WIPS), один из первых вендоров, получивший сертификаты FIPS (позволящие продавать свои решения американскому правительству), один из первых вендоров, получивший сертификацию ICSA, первый вендор, интегрировавший в свое беспроводное решение полноценный межсетевой экран. Главный принцип, на котором построена система безопасности Аруба гласит, что пользователем беспроводной сети может быть кто угодно – работник с ноутбуком, нанятый контрактор, гость, barcode reader, принтер, VoIP телефон или злоумышленник, которые попытается взломать сеть, но если пользователь вошел в сеть, авторизовался и аутентифицировался в соответствии с политикой, прикрепленной к его роли, то НИКАКИЕ действия пользователя не должны привести к нарушению информационной безопасности. Рисунок 7. Система сетевой безопасности Множество устройств, с массой разнообразных приложений, собранные в одном месте требуют со стороны оператора сети глубокого понимания трафика, чтобы обеспечить соответсвующее качество сервиса и уровень безопасности. Чтобы это обеспечить, в решения Аруба встроен полноценный NG FW, который способен определять сетевые приложения, включать их в правила управления трафиком беспроводной инфраструктуры и умеет: Контролировать потоки трафика на базе информации 2-7 уровней модели OSI Идентифицировать конкретных пользователей и приложения, которые они используют и на базе этой информации строить политики безопасности Применять групповые политики, определенные в инфраструктуре ААА Привязывать правила обработки трафика к времени суток, типу устройства, пользователю и приложению Отключать пользователей от сети при попытках обойти правили безопасности Управлять полосой пропускания конкретного подключения и ограничивать ее для определенных приложений Реализовывать двухфакторную аутентификацию Рисунок 8. NGFW Применение функционального межсетевого экрана, встроенного в беспроводную инфраструктуру, позволяет отсекать атаки на сеть прямо на уровне доступа, вместо того, чтобы тянуть паразитный трафик до отдельностоящей системы безопасности и обратно, загружая внутренние ресурсы сети. Так как инфраструктура HD WiFi работает в основном под максимальной нагрузкой, и, кроме того, в толпе есть большие шансы остаться незамеченным, то возникает соблазн воспользоваться ситуацией и попытаться взломать сеть. Поэтому следующая, крайне важная часть системы сетевой безопасности в HD WiFi – это Wireless IPS. Основной функционал Аруба WIPS кратко перечислен в следующей таблице: Таблица 2. Функционал Аруба WIPS Функция Базовая ОС С лицензией RF Protect Wireless Detection XXXXXXX — Air Monitors XXXXXXX — Rogue Classification XXXXXXX — Wired Rogue Containment XXXXXXX — Wireless Rogue Containment XXXXXXX — IDS Attack Signatures — XXXXXXX Spectrum Analysis — XXXXXXX Total Watch — XXXXXXX Tarpiting — XXXXXXX Advanced Rogue Classification — XXXXXXX L3 Rogue Classification XXXXXXX — 802.11 Infrastructure Attack Detection — XXXXXXX Impersonation Detection — XXXXXXX Authorized Client Monitoring — XXXXXXX Malformed Packet Checks — XXXXXXX Event Correlation — XXXXXXX Monitored AP Encryption XXXXXXX — Ad-Hoc Network (IBSS) APs — XXXXXXX L3 AP Wired Containment XXXXXXX — Protect Windows Bridge — XXXXXXX Protect Valid Station — XXXXXXX Protect My SSID — XXXXXXX WIP Configuration Wizard — XXXXXXX Как видно из таблицы, часть функций это системы присутствуют в базовом ПО решения Аруба, другая часть открывается дополнительной лицензией. Мониторинг радиосреды можно организовать двумя разными способами – при помощи регулярных точек доступа и при помощи специализированных точек-мониторов. В первом случае регулярные точки будут выделять определенные промежутки времени между передачей клиентского трафика для сканирования каналов на предмет выявления угроз информационной безопасности. Во втором случае специализированная точка-монитор (далее монитор) не занимается передачей клиентского трафика вообще и все время посвящает сканированию радиоэфира. У каждого подхода есть свои преимущества и какой подход использоваться — нужно определять в каждом конкретном случае, в зависимости от условий и задачи. Сравнение некоторых аспектов работы WIPS при разных подходах приведены в таблице 3, где кратко суммированы основные функции WIPS, важные при реализации HD WiFi сетей. Таблица 3. Описание основных функций WIPS Функция/описание Как работает точка доступа Как работает монитор Сканирование каналов Все разрешенные каналы, включая не входящие в текущий домен, должны быть сконфигурированы в «scan mode» в ARM профиле. Сканируются все разрешенные каналы + редкие (например, 4.9Ghz), где сканирование идет с инкрементом по 5Mhz на предмет поиска «вражеских» точек в интервалах между стандартными каналами (в MHz это частоты 2412-2484 и 4900-5895, с инкрементом по 5 MHz). Все сканируемые каналы должны быть сконфигурированы в ‘scan mode’ в АМ профиле. Методы сканирования Примерно каждые 10 секунд точка доступа переключается с обработки данных на «домашнем» канале на сканирование других диапазонов, примерно на 100мс, что позволяет не потерять бакены на «домашнем» канале. При этом, точка тратит в среднем по 70мс на сканируемом канале, что не дает гарантии обнаружения вражеской точки по бакену (бакен от нее может пройти незамеченным). Поэтому точка способна обнаруживать вражеские точки и по другим служебным кадрам или ответам на специальные пробы. Монитор делит каналы на четыре группы – active, regulatory, all regulatory и rare и тратит по 500, 250, 200 и 100 мс на каждом типе каналов соответственно, причем время сканирования каждого типа каналов настраивается. По умолчанию, предпочтение отдается активным и регуляторным каналам. Wireless Containment Если на каком-то канале обнаружена вражеская точка доступа, то точка с клиентами не будет менять домашний канал, чтобы подавлять ее. Но если на точке в текущий момент нет клиентов и в ARM профиле установлен параметр «rouge aware», то она сменит канал и будет подавлять вражескую точку. Если же вражеская точка обнаружена на домашнем канале, то точка также будет эффективно подавлять ее работу (слать de-authorization ее клиентам) даже в случае, если с точкой ассоциированы клиенты. Если точка доступа определена как вражеская, АМ будет постоянно возвращаться на ее канал для подавления. Например, если вражеская точка обнаружена на канале 1, то схема сканирования каналов будет выглядеть примерно следующим образом 1, 6, 1, 2, 1, 11, 1, 3, 1, 6, 1... Важно, что при обнаружении вражеской точки АМ не перестает искать нарушителей и сканировать остальные каналы. Tarpitting Этот метод противодействия вражеским точкам более действенный, чем Wireless Containment c отправкой de-authorization клиентам. В случае, если обнаруженная точка классифицирована как вражеская, то при ее подавлении клиентов заставляют переключать на ложный канал или SSID: Точка определяет, что на канале есть клиенты, подключенные к вражеской точке доступа Точка посылает de-authenticate (de-auth) сообщение клиенту и вражеской точке от имени другой стороны (точки или клиента) Клиент пытается снова присоединиться к вражеской точке На запрос об ассоциации отвечает легитимная точка и присоединяет клиента к ложному каналу/SSID Клиент пытается передачать данные, но точка его попытки игнорирует Аналогично. IDS signature attack detection 100% покрытие всей сетевой инфраструктуры. Точка проверяет трафик на наличие признаков атак в процессе обслуживания клиентов. Кроме того, IDS сигнаруты проверяются в процессе сканирования других каналов, что также безопасно, т.к. в этот момент на домашнем канале нет обслуживающей точки доступа, через которую можно атаковать сеть. Менее, чем 100% покрытие инфраструктуры, т.к. монитор не находится постоянно на всех каналах, а сканирует их все по очереди. Больше шансов обнаружить атаку на активном канале, т.к. монитор тратит на нем больше времени, но это можно изменить настройками (установить время сканирования каналов вручную) Supported IDS signatures Все сигнаруты (100%). Некоторые сигнаруты (например, AP Spoofing) требуют работы WIPS в гибридном режиме, чтобы успешно обнаружить атаку. 90%+ сигнатур, поскольку часть атак, например, AP Spoofing или Premature EAP Success/Failure обнаруживаются только WIPS на базе точек в гибридном режиме (т.к. требуют дополнительную информацию, которая есть только на регулярных точках доступа, не на мониторах). Wired Containment Точка доступа может подавлять вражеские точки в проводной инфраструктуре (ARP Poisoning), если они находятся в той же проводной сети, что и вражеской устройство, которое точка слышит в радиоэфире. Аналогично. Еще несколько последних замечаний относительно реализации WIPS в HD сетях: Если WIPS построен на базе регулярных точке доступа, то у вас вся инфраструктура сети покрыта без пробелов по умолчанию; если же используются специализированные мониторы, то Аруба рекомендует соотношение точка-монитор не менее 4:1 (на 4 точки доступа минимум 1 монитор). При этом, также, как и точки доступа, мониторы тоже должны быть физически правильно размещены, чтобы в WIPS не возникало пробелов в покрытии. Сканирование радиоэфира на предмет поиска атак/вражеских точек должно быть настроено так, чтобы не мешать передаче аудио/видео потоков, чувствительных к задержкам, т.е. должно приостанавливаться на время активной передачи такого трафика на канале. У Арубы это настраивается в профилях ARM. Прежде, чем говорить о следующем блоке решения, хотелось бы, чтобы читатели задали себе вопрос – а зачем людям сеть на стадионе? Что они с ней делают? Если посмотреть профиль трафика, то ответ становится очевиден – в основном они потребляют и раздают фото и видео. Они снимают себя, поле, соседей, делают ролики и кладут это все условно в Instagram/Facebook и в перерывах смотрят, что положили в Instagram/Facebook их друзья. Поэтому трафика в HD WiFi не только много, но он еще и специфически профилирован, с подавляющим большинством мультимедиа-контента в потоке. А такой тип трафика, как известно, чувствителен не только к полосе, но и к задержкам и другим параметрам качества сети. И генерироваться этот трафик может самыми разными способами и приложениями. Рисунок 9. QoS для тегированного и не тегированного трафика Поэтому решение HD WiFi должно обеспечивать соответствующий QoS не просто по типам трафика, а по приложениям, которые этот трафик создают. Технология Аруба Application Fingerprinting и встроенный в решение DPI позволяют классифицировать трафик по протоколам всех (6) уровней модели OSI и затем, при помощи соответствующих политик, применять к трафику нужные правила. В том числе, устанавливать на мультимедийные потоки нужные параметры QoS c соответсвующей последующей обработкой, например, увеличить полосу пропускания для мультимедийного трафика. Ключевые компоненты технологии оптимизации качества передачи мультимедиа Application Fingerprinting включают в себя: Dynamic Multicast Optimization (DMO), которая поволяет налету конвертировать мультикаст трафик в unicast и передавать его беспроводным клиентам, не занимая полосу тех, кому это трафик не нужен Secure Signaling Awareness, обеспечивающая DPI для сигнализации VoIP протоколов (SIP, MS Lync) Call Protection, адаптирующий радиосреду при помощи ARM и задерживающий сканирование радиосреды при наличии на точке активного звонка Full Visibility, обеспечивающий полный мониторинг голосовых потоков и соответствующую отчетность на контроллере Highly Scalable, балансирующй нагрузки по доступным каналам и точкам на основе приоритезации голосового и видео трафика Последний блок решения HD WiFi, о котором нельзя не упомянуть – это система интеллектуального управления инфраструктурой, включая системы управления сетевой безопасностью, с которых мы и начнем. Ядром системы управления безопасностью является платформа ClearPass, которая умеет управлять доступом пользователей в сеть (идентифицировать пользователя и авторизовать его разными способами на разные виды доступа, отменять определенные виды доступа пользователя, и т.д.) устанавливать параметры доступа и подключения в сеть для устройств (например, ограничения полосы) контролировать приложения, установленные на клиентах и удаленно управлять клиетскими устройствами (например, удалять данные с устройств, устанавливать на них определенные патчи и т.д.) многое другое, связанное с: Рисунок 10. Аруба ClearPass Использование ClearPass в HD WiFi намного упрощает задачу управления доступом в сеть. Если правильно спроектировать систему доступа, клиентский портал и грамотно настроить политики управления и devices provisioning, то задача обеспечения безопасности на границе сети фактически сводится к применению разработанных политик на сеть и отслеживанию инцидентов, с последующим разбором. Чтобы можно было управлять сложной инфраструктурой HD WiFi, искать и решать потенциальные проблемы, необходима система управления сетью, в которой это делалось бы просто и наглядно. Такая система в Арубе есть, она называется Airwave и обеспечивает: Комплексное управление мобильной сетью: Централизованное, мультивендорное, мультиинфраструктурное управление и мониторинг беспроводной/проводной инфраструктуры Наглядная визуализация беспроводной/проводной инфраструктуры с картами сети Рисунок 11. Пример «карт нагрева» в Airwave И последнее, о чем хотелось бы упомянуть в этой технологичекой части – это о людях. Никакие супертехнологии не спасут проект, если он сделан «кривыми» руками. Никакие решения не будут нормально работать, если они расставлены, настроены и запущены без надлежащего понимания цели и сути задачи. Поэтому вывод простой — не экономьте на сервисе! Как говорил классик, «чтобы не было потом мучительно больно», лучше позволить делать HD WiFi сеть тому, кто имеет такой опыт и ресурсы. Часть 4. О деньгах «Неважно, о чем говорят - речь всегда идет о деньгах» Второй закон Тодда Теперь самый важный вопрос – а зачем вообще нужен HD WiFi? Ну действительно – зачем, по большому счету, WiFi сеть на стадионе? Чтобы пользователи могли online скидывать свои selfy в сеть? Какая польза от этого владельцу стадиона, который понес затраты на дизайн и разработку HD WiFi сети, покупку оборудования HD WiFi сети, настройку HD WiFi сети и ввод ее в эксплуатацию И еще понесет затраты на ее поддежку и модернизацию? Зачем владельцу стадиона все это? Ответ очень простой – HD WiFi можно и нужно монетизировать, т.е. зарабатывать на нем деньги. При этом, старомодный способ продавать гостевые учетки вместе с билетами сейчас плохо работает. Кризис, люди экономят на всем и впихнуть вместе с билетом еще и «просто доступ в сеть» становится трудно. Тем более, что мобильные 3G/LTE сети никто не отменял и мобильные операторы строят свою инфрастрктуру также с учетом потенциальной загруженности места. Поэтому монетизировать сеть нужно при помощи дополнительных сервисов, которые будут полезны многим, просты и понятны в использовании и будут не дорого стоить. И здесь вендоры из премьер-лиги опять выгодно отличаются от всех остальных производителей WiFi «железа». Во-первых, у большинства из них есть готовые сервисные платформы, на которых можно разворачивать дополнительные услуги для пользователей вашей сети и, во-вторых, как правило, у них есть развитая партнерская сеть, которая дополняет возможности по монетизации HD WiFi разными собственными приложениями. Возвращаясь к Арубе, нужно сказать что у нее есть не просто платформа, а целая сервисная инфраструктура, которая позволяет гибко реализовывать разные дополнительная услуги поверх HD WiFi сети. Эта инфраструктура включает в себя аналитический «движок» (Analytics and Location Engine, ALE), который позволяет по множеству параметров анализировать данные, получаемые из WiFi сети (например, данные о геопозиционировании клиентов), систему Bluetooth-маяков, которые делают геопозиционирование очень точным, а также платформу мобильных приложений Meridian, на базе которой можно построить разнообразные пользовательские сервисы. Рисунок 12. Analytics and Location Engine Наличие этих инструментов заставляет переосмыслить саму цель внедрения WiFi сети. Например, данные о геопозиционировании позволяют реализовать сервис по интерактивной маршрутизации пользователя внутри сети, такой «in-door GPS». Это крайне полезный и, как доказывает практика, востребованный сервис, например, в больших магазинах, где, по статистике, основная причина отказов от запланированной покупки – это неспособность покупателя найти нужный товар на полках. По личному опыту, основной вопрос к продавцам-консультантам в магазинах типа Ашан/Окей/Леруа-Мерлен – «А где найти это?». Наличие дополнительной инфраструктуры из Bluetooth маячков позволяет сделать геопозиционирование очень точным, вплоть до 1 метра и, соответственно, маршрутизацию и навигацию внутри магазина также очень точной и предметной. Например, наличие маячков под сиденьями кресел на одном из стадионов позволило реализовать сервисы по геолокации, плоть до конкретного посадочного места. Рисунок 13. Платформа Meridian Еще один популярный способ монетизации данных о геопозиционирование – использование рекламной модели, когда пользователь, проходя мимо определенных мест на карте, получает всплывающую контекстную рекламу, привязанную конкретно к тому месту, где он сейчас находится. Например, если вы идете по большому торговому центру, то в качестве рекламы могут появляться всплывающие окна о распродажах в магазинах, мимо которых вы проходите. Сервисная платформа Meridian предоставляет подписчикам доступ к API, при помощи которого разработчики могут сделать практически любое приложение, основанное на данных о геопозиционировании и загруженных в платформу картах. Дальше, помимо интеллектуальной маршрутизации/навигации в помещении и контекстной рекламы, применение этих данных ограничено только вашей фантазией. Другой подход к монетизации WiFi сетей – использование партнерской модели. У вендоров премьер-дивизиона, как уже упомянуто выше, обычно построены партнерские отношения со многими разработчиками специализированных приложений, которые могут быть интегированы в развернутую HD WiFi инфраструктуру. Например, компания YinzCam — давний партнер Аруба в области специализированных приложений для спортивных мероприятий. При помощи своих решений YinzCam могут предоставлять фанатам дополнительные сервисы, такие, как повтор ключевых моментов и/или всего матча, просмотр моментов игры с разных углов разных камер, заказ еды и напитков, программы лояльности для фанатов, и т.д. Рисунок 14. Приложения YinzCam Другой пример монетизации при помощи рекламной модели – использование решений типа рекламной платформы компании RaGaPa. При помощи этой платформы они умеют разбирать HTTP трафик и вставлять в него контекстную рекламу, определенную для данной рекламной компании и хранящуюся в специализированом облаке RaGaPa. Рисунок 15. Решение RaGaPa Подводя итог сказанному, хотелось бы подчеркнуть еще раз следующую ключевую мысль – не следует рассматривать HD WiFi инфраструктуру как следующий «центр затрат», который будет съедать ресурсы вашей компании. При правильном подходе, HD WiFi инфраструктура может стать серьезным «центром генерации прибыли».

Метки:  

Внедрение CRM: как не быть близким к провалу

Среда, 15 Июня 2016 г. 19:26 + в цитатник
Наверняка многие из вас видели в интернете фотогалереи с заброшенными торговыми центрами, огромными и некогда роскошными. Впечатляющее зрелище, особенно для бизнесмена. Но первая мысль вовсе не о том, сколько денег, инвестированных в развитие, пропало. Она о том, почему это произошло. Да, есть фактор влияния структурных сдвигов экономики, есть и «вина» онлайн-торговли. Но главное — это неумение вовремя перестроиться, адаптироваться, изменить бизнес-модель. Причём не отказываясь от существующей, а встраивая её в новые условия. Та же история может случиться с проектом внедрения CRM: система простаивает, компания меняет вендора, выбирает более дорогую систему, которая снова простаивает… Замкнутый круг. А между тем, причины неудачи довольно линейны — и в ваших руках сделать внедрение CRM успешным. Делимся опытом, как. Который год мне не удаётся найти статистику по провалам CRM-проектов в России. Они однозначно есть, иначе к нам бы не приходили люди с желанием сменить свою систему. Кроме того, в нашей среде циркулируют отдельные легенды об эпичных провалах. Но личная выборка одного вендора RegionSoft явно нерепрезентативна. Зато ежегодно публикуется интересная статистика по зарубежным внедрениями. Так, согласно десятилетнему исследованию от 25 до 60% CRM-проектов не оправдали ожиданий. 91% компаний с численностью свыше 11 человек используют CRM, а среди компаний с численностью до 10 человек таких только 50%. 78% покупателей разочаровываются в компании или не совершают покупку из-за плохого обслуживания. В то же время CRM улучшает ROI и предлагает средний доход от $5.60 за каждый потраченный $1. Сложно сказать, как это можно примерить на российский рынок — в плане отношения к CRM наш пользователь уже преодолел порог элитарности, но всё ещё не проникся европейским подходом крайней необходимости этого ПО. Всё больше представителей бизнеса признают преимущества CRM и приступают к внедрению. Нам как вендору хочется, чтобы они обжигались как можно реже. Итак, вы решили внедрить CRM. В самом начале необходимо осознать три главные вещи. CRM — это не программа с кнопкой «Увеличить продажи на 250%» в центре интерфейса. Прежде всего это инструмент стратегии CRM, управления взаимоотношениями с клиентами. Если ваш бизнес работает на рынке какое-то время, эти самые взаимоотношения уже есть и ломать их или в корне менять вместе с внедрением неверно. Особенно, если бизнес успешный, клиенты лояльные, продажи стабильные. Необходимо разворачивать CRM, адаптируя её к сложившимся процессам, автоматизировать их, но не ломать, чтобы построить заново. CRM-система — это не инструмент контроля сотрудников. Да, например, в RegionSoft CRM есть система KPI, есть отчёты по мониторингу прогресса выполнения задач, есть воронки и проч. Но это лишь инструменты управления, конечная цель которых — наладить работу менеджеров так, чтобы в итоге был удовлетворён клиент. Который, как известно, приносит прибыль. К проекту внедрения CRM нельзя подходить однобоко, а именно только как к установке программного обеспечения и появлению ярлычка на рабочем столе. Это внедрение серьёзного, мощного инструмента, который при правильном применении обеспечит реальную и ощутимую экономию трудовых ресурсов и времени, позволит переориентировать отношения с клиентами на интенсивный рост (например, за счёт точечного воздействия на сегменты). Знал бы, где упасть... Рассмотрим 10 основных ошибок и один фактор, которые могут привести к провалу внедрения CRM. Хранение данных в разрозненных источниках. Если в компании уже сформировалась клиентская база, есть информация по сделкам, складу, программам лояльности, то, как правило, это один из вариантов. У каждого менеджера свои данные на удобном им носителе, руководитель получает периодические сводные отчёты по объёмам сделок, продаж, реализации, остаткам и т.д. Есть несколько программ, в которых хранятся данные. Это могут быть разные однопользовательские СRM (вроде нашей бесплатной RegionSoft CRM Express), системы учёта клиентов типа контакт-менеджеров и даже системы управления задачами, в которых информация по сделке записана единым текстовым полем, а значит, её сложно обработать. Существует единый файл Excel, в который менеджеры вносят всю информацию. Это едва ли не самый страшный случай, поскольку неоднократно встречались повреждения файла, отсутствия бекапов, неверной сортировки, преднамеренного повреждения или несанкционированного копирования. При внедрении CRM эта база должна быть загружена в систему, так как это основа деятельности компании. И если импорт из других систем или Excel ещё возможен, то информацию из мобильников, документов и блокнотов менеджеров нужно вносить вручную. Чаще всего эта процедура игнорируется и руководством, и работниками. В итоге эффективность CRM заметно снижается, персонал продолжает блуждать от приложения к приложению, рабочий процесс затягивается, время тратится на поиск того, где записан клиент. Между тем, CRM — это надёжная аналитическая база компании, которая собирает данные в унифицированном виде. На их основе формируются отчёты, документы, происходит информирование подразделений, функционируют бизнес-процессы. Информация из системы служит основой принятия управленческих решений. Например, у вас рекламное агентство полного цикла с широким ассортиментом услуг. 2010 год — все заказывают сувенирку, SEO, кампании в Директе. Вы проплачиваете инструменты для работы с продвижением, закупаете материалы и оборудование. Неожиданно к 2014 году спрос меняется и вы видите, что календарей заказывают меньше, на складе мёртвым грузом лежат материалы для флаеров, клиенты уходят. Начинаете расспрашивать менеджеров, они говорят, что были обращения по SMM, диджитал, контенту и медийке. И обнаружилось это только после ощутимого спада или очередной инвентаризации. Если бы стояла CRM, вы могли бы изначально видеть, что спрос меняется не сезонно, а менеджеры не просто кладут трубку с ответом «Мы это не делаем», а фиксируют звонки с обращениями по новому типу услуги. Есть время перестроиться, сократить закупки, вывести из ассортимента позиции с низким и нулевым спросом. Чтобы работать с клиентами, необходимо выстроить чёткую линию аналитики, которая ляжет в основу сегментации для рассылок, изменения номенклатуры или переориентации компании. Это возможно только в одном случае — если вся информация накапливается в одной системе и никто не игнорирует этот процесс. Сбор неполной, неточной и неактуальной информации — ещё одна причина краха, связанная с аналитикой. Вызвана она тем, что менеджеры вносят информацию несвоевременно, например, по итогам месяца. С позиций CRM это опасная привычка, можно упустить из вида существенные взаимодействия. У нас было много запросов на контроль взаимодействий с клиентами — поэтому мы даже создали отдельный отчёт в RegionSoft CRM, который в графическом виде отображает динамику разработки клиента и его продвижение по этапам воронки продаж. Внедрение CRM без интеграции. Здесь практически не нужны пояснения. Есть 1С, есть сайт, есть телефония. Все эти сущности должны дружить с CRM непосредственно или опосредованно, обмениваться с ней данными. Тогда станет ясна полная картина дел в компании. Мы в RegionSoft уделяем интеграциям значительное внимание. Так, кроме базовых связок с 1С и Asterisk, у нас есть собственный сервер сценариев RegionSoft Application Server, который творит чудеса организует автоматизированные обработки, не требующие участия пользователя. Они могут выполняться по расписанию, либо по HTTP-запросу. Например, можно настроить создание архивной копии базы данных RegionSoft CRM с использованием штатного бэкапа Firebird, который будет осуществляться каждый день в 2:00 ночи, кроме субботы и воскресенья. При этом вся работа будет проделана автоматически. Именно через App Server может осуществляться интеграция с сайтом, 1С, другими учётными системами, проводиться анкетирование, проходить рассылка и проч. Отсутствие внятных целей. В нашем списке эта ошибка стоит не на первом месте, но заслуживает гран-при. И вот почему. Мотивом внедрения CRM в компании может быть что угодно: острая и объективная необходимость, мода, внедрение у знакомого, отзывы, требование инвесторов, навязывание бизнес-тренером… Но нужно чётко осознавать цель внедрения, которая в своей макро-реализации заложена в названии: управление взаимоотношениями с клиентами. И все текущие цели должны каким-то образом увязываться с этой целью. Отсутствие поддержки со стороны руководства. Очень странная ошибка, но она имеет место быть. Если CRM-система внедряется для проформы, руководство в принципе может игнорировать процесс внедрения и запуска в эксплуатацию. И вот к чему это приводит: отсутствие мотивации использовать систему игнорирование системы использование системы как инструмента контроля со стороны менеджеров среднего звена и… … саботаж со стороны сотрудников — прямое следствие предыдущего пункта. Работники могут просто отказаться работать с новым интерфейсом. Руководство должно понимать, что внедрение CRM — это не маленький проект и даже не переход на новую операционную систему. CRM потенциально модифицирует многие бизнес-процессы, скорректирует стратегию продаж, введёт дополнительные показатели эффективности и, в конечном итоге повлияет на прибыль. Поэтому руководство обязано участвовать во внедрении на всех этапах, от технического задания до обучения и начала работы. Вот, что требуется от высшего звена: Не торопить подчинённых перейти на новое программное обеспечение, а установить адекватные сроки и позволить познакомиться с CRM постепенно. Разъяснить важность внедрения. Ни в коем случае не говорить о сокращениях и не шантажировать ими. Человеческий ресурс бесценен — и освободившееся время нужно перенаправить на поиск новых клиентов, каналов продаж или на обучение. Материально и нематериально поощрять использование системы, показывать, что вы незримо в ней присутствуете и оцениваете результаты. Совместно обсуждать сложившиеся показатели и пути улучшения. Вовлечённость в процесс — мощнейший фактор мотивации. Локальная автоматизация одного отдела или одной группы. Даже среди партнёров вендоров встречается суждение о том, что в разных отделах компании может использоваться своя система автоматизации. На самом деле это дорого, сложно и снижает результативность — ведь все данные разрознены. Изолированность отделов и служб сама по себе уже болезнь организации, а если она подчёркивается разным подходом к автоматизации, это совсем плохо. Поясню на примере. Допустим, есть отдел продаж, есть склад, есть производство, есть отдел маркетинга. И все они автоматизированы отдельно, а производство так вообще пишет ручкой в журнале учёта. В итоге получается, что склад и производство не знают о потребностях и возможностях друг друга — может возникнуть затоваривание или простой. В коммерческой службе тоже бардак: маркетологи придумывают активности для несуществующих сегментов покупателей, а продажники не знают, что предложить для допродажи. И все вместе они не подозревают, что заказ на 10 000 единиц принять нельзя, потому что на складе нет комплектующих, а производство заканчивает сборку только 2 000. В общем, идеальные условия, чтобы сорвать контракт и испортить деловую репутацию. CRM с лёгкостью решает такие проблемы. Например, у нас в RegionSoft CRM при совершении продажи наименования соответствующее количество сразу списывается со склада, формируются закрывающие документы, отправляется заявка на производство, проверяется наличие комплектующих и, если их не хватает, создаётся заказ поставщику. В это же время продажники успешно и точно выставляют план продаж, а маркетологи открывают отчёты и решают, какие наименования нужно включить в летнюю распродажу, а какие и так неплохо идут. Такая взаимосвязь внутри CRM-системы делает связанной и взаимозависимой деятельность команды, а это ключ к выполнению KPI и удовлетворению клиента. Разделение бизнес-процессов и CRM — критическая ошибка. На Хабре было много постов про процессный подход, нотацию BPMN и важность соблюдения процедур. И все рассуждения отражают главную мысль — процессы должны входить в систему автоматизации организации, чтобы минимизировать человеческий фактор, управлять ресурсами, соблюдать сроки и не забывать о важных звеньях управления. Бизнес-процессы неотделимы от современных CRM-систем, поскольку они также должны привязываться к клиентам, использовать данные системы и сохранять в ней свою информацию. В RegionSoft CRM бизнес-процессы вошли в версии 5.0, и почти сразу наш нативный редактор процессов получил одобрение со стороны клиентов. Встроенные в CRM бизнес-процессы здорово усиливают её, в очередной раз связывают подразделения и выдвигают персональную ответственность на передний план. Кстати, в настройке бизнес-процессов нет ничего сложного — у нас этапы и параметры настраиваются интуитивно, не нужно никаких специфических знаний и навыков, тем более навыков программирования. Отсутствие обучения и внутренней экспертизы если не убивают внедрение, то значительно снижают его качество и увеличивают сроки. Обучение может происходить следующим образом. Самостоятельно на основе справки системы. Каждый сотрудник выделяет время на обучение и разбирается с документацией в руках. Увы, это не всегда возможно — иногда вендор ограничивается простым навигатором и полагается на коммьюнити. В последних версиях мы решили это вопрос — в дистрибутивах можно скачать детальное руководство пользователя и администратора RegionSoft CRM. Наши клиенты уже успели прозвать его учебником за две с половиной сотни страниц и максимально разжёванную информацию Воспользоваться услугами вендора. И здесь также два варианта — пройти групповое обучение офлайн или онлайн или же обучить одного сотрудника, прокачав его до уровня внутреннего эксперта. Какой вариант выбрать — зависит от множества факторов, это обсуждается индивидуально. Но в целом работает гибридная модель: ознакомительное обучение группы и формирование внутреннего эксперта, к которому в любой момент смогут обратиться сотрудники. Экономить на обучении точно не стоит — это невысокая доля в затратах на проект, а быстрый старт всё же большое преимущество. Кстати, часто задают вопрос о том, когда в течение года внедрять CRM. Ответ прост: когда у вас спад интереса клиентов. У подавляющего большинства компаний это май-август. В это время можно потратить больше времени на адаптацию и подойти к сезону продаж уже вооружённым до зубов. Мы предусмотрели и этоСегодня последний день нашей юбилейной акции и скидок 15% на все лицензии программного обеспечения RegionSoft (у нас много собственной разработки) и 60% — на установку и обучение. Выбор неподходящей CRM-системы — явление также распространённое. И опять же возникает ветвление по причинам неуспеха, который заключается в перерасходе средств или полном отказе от программного обеспечения. Не та CRM-система по технологии развёртывания и доработки. Компании соблазняются на бесплатный open source и получают безумного дорогое внедрение, доработку, вынуждены нанимать дорогостоящих администраторов и программистов, платить за коннекторы, интеграции, кастомные отчёты. А бесплатный сыр продолжает оставаться в мышеловке. Не та CRM-система по функциональности. Компании ведутся на звучные имена типа SAP или Salesforce и внедряют их решения любой ценой. Сперва они получают избыточную функциональность, а потом осознают, что не хватает элементарных вещей типа первичной документации и за неё вновь надо платить. Масштаб CRM и масштаб бизнес-процессов просто не сходятся. Перед нами тоже стояла проблема излишеств, когда клиент немного, но переплачивал за то, чем он не пользуется. Мы решили вопрос в RegionSoft CRM 6.0 — раздробили редакции на более мелкие так, чтобы каждый мог подобрать базовую конфигурацию практически точно по себе. Не та CRM-система по цене. Кроме переплаты за функциональность, есть ещё одна неприятная ловушка — абонентские платежи за аренду системы по модели SaaS, которые за пару лет основательно перерастают стоимость внедрения разового проекта. Фактор жадности. Это жирная точка в ошибках внедрения. Если выбирать CRM только исходя из цены, довольствоваться ограничениями, отказаться от профессионального внедрения и обучения, можно даже не начинать, провал обеспечен. Такой подход приемлем исключительно для компаний, штат которых укомплектован профессионалами высокого класса, способными самостоятельно доработать и развернуть систему, обучить и прояснить нюансы. Такое встречается. Казуистически. … соломку бы подстелил Небольшая памятка для тех, кто собирается внедрять CRM — как это сделать быстро и безболезненно. Соберите требования к CRM со всех отделов, обсудите их, выявите точки пересечения. Опишите основные и второстепенные бизнес-процессы, расставьте приоритеты. Выбирайте CRM-систему исходя их комплексного подхода к автоматизации и ваших бизнес-требований. В мире корпоративного программного обеспечения нет места моде — компания внедряет тот софт, который ей удобен и который поможет интенсивно работать, а не просто собирать данные, общаться в чате или учитывать рабочее время. Рассчитайте бюджет на внедрение и спрогнозируйте, во сколько вам обойдётся владение системой в течение 2-3 лет. Возможно, невинное обещание «всего 959 рублей за пользователя в месяц» обернётся серьёзными тратами уже при 10 сотрудниках. Через два года — 230 160, через три — 345 240, и это без учёта индексации. Для сравнения, стоимость 10 лицензий RegionSoft CRM Enterprise (это наша редакция со всеми наворотами, фактически ERP) обойдётся вам в 149 290 рублей, а самая популярная Professional — в 111 740 рублей. И это при том, что платите вы один раз и лицензии вечные. Вносите данные максимально тщательно и организованно. Для повторяющихся данных используйте справочники — так можно выбирать унифицированное значение, избегая ошибок и многообразия ввода. Создавайте пользовательские параметры и отчёты, используйте CRM на полную катушку. Расширяйте статусы клиентов, наименования этапов разработки, статусы задач в Service Desk. Чем детальнее информация, тем более разносторонняя м полезная получается аналитика. Внедряйте CRM постепенно, позволяйте сотрудникам тратить время на обучение и самостоятельную работу с документацией. Не жалейте бумагу — распечатайте и скрепите руководство для каждого пользователя. На начальном этапе выделите наиболее важны процессы и задачи для каждого из сотрудников — пусть они занимаются именно ими, постепенно расширяя свою вовлечённость в работу с системой. Рассматривайте данные и процессы в совокупности. Их интеграция и единая база создают систему, которая увеличивает вероятность удовлетворения интересов всех сторон и делает CRM операционно эффективной. Сделайте CRM универсальным рабочим местом (особенно важно для менеджеров по продажам!). Подключите телефонию, виртуальную АТС, интегрируйте CRM c сайтом, если это необходимо. Менеджер должен осознавать, что именно интерфейс системы является его рабочим местом. Попросите системного администратора или внутреннего эксперта обойти всех сотрудников и настроить вид и цветовую схему CRM под желания каждого пользователя — так системой будет приятнее пользоваться. Организуйте несколько этапов внутреннего обучения, проведите семинар по вопросам использования программы через несколько недель использования, создайте раздел вопросов и ответов на корпоративном портале или в общей папке. Кстати, в RegionSoft CRM это можно сделать в удобной базе знаний, доступной всем. Опять же, новички смогут изучить накопленный опыт, а это сокращает время адаптации. Мотивируйте. Подводя итоги месяца, рассказывайте, опираясь на данные из CRM, показывая графики, диаграммы и отчёты в её интерфейсе. CRM-система — это та часть автоматизации, которая нужна «ещё вчера». Если вы решились на этот шаг, обязательно продумайте все мелочи, обратите внимание на подводные камни. На самом деле, внедрение системы — проект сам по себе несложный и выполнить перечисленные правила просто в компании любого масштаба, от холдинга до студии. Главное помнить, что CRM как никакой другой софт нацелена на работу с людьми: сотрудниками, клиентами, контрагентами. В общем, нужно всё делать по-людски. Тогда оно само хорошо выйдет. Мы ищем партнёровКстати, мы ищем партнёров в регионах РФ и СНГ — пишите, звоните, особенно, если вы умеете и желаете работать и зарабатывать. Приветствуются компании и ИП, готовые писать отчёты, скрипты, обучать пользователей и забирать весь доход от этого себе, а с нами делить только стоимость лицензий.

Метки:  

Автоматизируем проверку кода или еще немного о pre-commit hook'ах

Среда, 15 Июня 2016 г. 06:42 + в цитатник
Думаю, нет нужды рассказывать хабрапользователю что такое Git / GitHub, pre-commit и как наносить ему hook справа. Перейдем сразу к делу. В сети много примеров хуков, большинство из них на shell'ах, но ни один автор не уделил внимание одному важному моменту — хук приходится таскать из проекта в проект. На первый взгляд — ничего страшного. Но вдруг появляется необходимость внести изменения в хук, который уже живет в 20 проектах… Или внезапно нужно переносить разработку с Windows на Linux, а хук на PowerShell'е… Что делать? ??????? PROFIT… «Лучше так: 8 пирогов и одна свечка!» Примеры, конечно, сильно утрированы, но с их помощью выявлены неудобства, которых хотелось бы избежать. Хочется, чтобы хук не требовалось таскать по всем проектам, не приходилось часто «допиливать», но чтобы при этом он умел: выполнять проверку отправляемого в репозиторий кода на валидность (например: соответствие требованиям PEP8, наличие документации итд); выполнять комплексную проверку проекта (юнит-тесты итд); прерывать операцию commit'а в случае обнаружения ошибок и отображать подробный журнал для разбора полетов. И выглядел приблизительно так: python pre-commit.py --check pep8.py --test tests.py Понятно, что сам хук — всего лишь стартер, а всю особую уличную магию выполняет запускаемый им скрипт. Попробуем написать такой скрипт. Заинтересовавшимся — добро пожаловать под кат. pre-commit.py Но прежде, чем скачивать готовый пример из сети приступать к разработке, рассмотрим принимающие им параметры. Заодно на их примере расскажу как все работает. Этими параметрами будем задавать основное поведение скрипта: -c или --check [скрипт1… скриптN] — запуск скриптов проверки на валидность. Скрипт должен располагаться в том же каталоге, что и pre-commit.py. Иначе — нужно указать полный путь. Каждому скрипту будут «скармливаться» файлы из текущего коммита. -t или --test [тест1… тестN] — запуск юнит-тестов и прочих скриптов, которым не требуются файлы текущего коммита. Тест должен располагаться в каталоге текущего проекта. Иначе — нужно указать полный путь. Оба параметра будут необязательными (для возможности оставить только один тип проверки), но если не указать ни один из них, pre-commit.py завершит работу с кодом «1» (ошибка). И добавим вспомогательные параметры (все необязательные): -e или --exec путь_к_интерпретатору — полный путь (с именем файла) к интерпретатору, который будет выполнять скрипты из --check и --test. Если параметр не указать — будет использован интерпретатор, которым выполняется pre-commit.py. -v или --verbose — включает подробное логирование. Если не указан — в лог записывается консольный вывод тех скриптов, выполнение которых завершилось с кодом ошибки. -o или --openlog путь_к_просмотрщику — полный путь (с именем файла) к программе, которой будем просматривать лог. -f или --forcelog — принудительное открытие лога. Если не указан — лог открывается только в случае обнаружения ошибок. Параметр применим, если указан --openlog. Логика ясна, теперь можно приступать к написанию самого скрипта. Параметры командной строки Для начала настроим парсер параметров командной строки. Здесь будем использовать модуль argparse (или «на пальцах» неплохо объясняют здесь и здесь), так как он входит в базовый пакет Python. # -*- coding: utf-8 -*- import sys import argparse # Создадим объект парсера parser = argparse.ArgumentParser() # Добавим необязательный параметр. Если параметр задан, # ему необходимо указать значение: список из 1-N элементов parser.add_argument('-c', '--check', ) # Аналогично параметру --check parser.add_argument('-t', '--test', ) # Добавим параметр-флаг. Если задан, его значение будет равно # True. Если не задан - False parser.add_argument('-v', '--verbose', ) # Необязательный параметр с обязательным значением. # Если не задан - -e', '--exec', -o', '--openlog') # Аналогично параметру --verbose parser.add_argument('-f', '--forcelog', ) # Отсекаем 1-й параметр (имя текущего скрипта), парсим # остальные параметры и помещаем результат в dict params = vars(parser.parse_args(sys.argv[1:])) Запустим скрипт со следующими параметрами: c:\python34\python c:\dev\projects\pre-commit-tool\pre-commit.py --check c:\dev\projects\pre-commit-tool\pep8.py --test tests.py И выведем содержимое params на экран: {'exec': 'c:\\python34\\python.exe', 'forcelog': False, 'test': ['tests.py'], 'check': ['c:\\dev\\projects\\pre-commit-tool\\pep8.py'], 'openlog': None, 'verbose': False} Теперь значения всех параметров находятся в словаре params и их легко можно получить по одноименному ключу. Добавим проверку наличия основных параметров: # Выход в случае отсутствия обоих параметров скриптов проверок if params.get('check') is None and params.get('test') is None: print('Не заданы скрипты проверок') exit(1) Все хорошо, но можно немного упростить себе жизнь, без ущерба гибкости. Мы знаем, что в 99% случаев скрипт валидации один и называется он, к примеру, 'pep8.py', а скрипт юнит-тестов в нашей власти каждый раз называть одинаково (и часто он тоже будет один). Аналогично с отображением лога — всегда будем использовать одну и ту же программу (пусть это будет «Блокнот»). Внесем изменения в конфигурацию парсера: # Теперь параметры принимают значением список из 0-N элементов parser.add_argument('-c', '--check', ) parser.add_argument('-t', '--test', ) # Если параметру не указывать значение, будет использовано значение из const parser.add_argument('-o', '--openlog', , ) И добавим установку значений по умолчанию: if params.get('check') is not None and len(params.get('check')) check'] = [join(dirname(abspath(__file__)), 'pep8.py')] if params.get('test') is not None and len(params.get('test')) test'] = ['tests.py'] После внесения изменений код настройки парсера должен выглядеть так: # -*- coding: utf-8 -*- import sys import argparse from os.path import abspath, dirname, join parser = argparse.ArgumentParser() parser.add_argument('-c', '--check', ) parser.add_argument('-t', '--test', ) parser.add_argument('-v', '--verbose', ) parser.add_argument('-e', '--exec', -o', '--openlog', , ) parser.add_argument('-f', '--forcelog', ) params = vars(parser.parse_args(sys.argv[1:])) if params.get('check') is None and params.get('test') is None: print('Не заданы скрипты проверок') exit(1) if params.get('check') is not None and len(params.get('check')) check'] = [join(dirname(abspath(__file__)), 'pep8.py')] if params.get('test') is not None and len(params.get('test')) test'] = ['tests.py'] Теперь строка запуска скрипта стала короче: c:\python34\python c:\dev\projects\pre-commit-tool\pre-commit.py --check --test --openlog содержимое params: {'check': ['c:\\dev\\projects\\pre-commit-tool\\pep8.py'], 'openlog': 'notepad', 'test': ['tests.py'], 'verbose': False, 'exec': 'c:\\python34\\python.exe', 'forcelog': False} Параметры победили, едем дальше. Лог Настроим объект лога. Файл лога 'pre-commit.log' будет создаваться в корне текущего проекта. Для Git рабочим каталогом является корень проекта, поэтому путь к файлу не указываем. Также, укажем режим создания нового файла при каждой операции (нам нет необходимости хранить предыдущие логи) и зададим формат лога — только сообщение: import logging log_filename = 'pre-commit.log' logging.basicConfig( , , > Последней строкой кода еще немного упростим себе жизнь — создаем алиас, которым будем пользоваться дальше по коду вместо logging.info. Shell Нам потребуется неоднократно запускать дочерние процессы и считывать их вывод в консоль. Для реализации данной потребности напишем функцию shell_command. В ее обязанности будет входить: запуск подпроцесса (с помощью Popen); считывание данных с консоли подпроцесса и их преобразования; запись считанных данных в лог, если подпроцесс завершился с кодом ошибки. Функция будет принимать аргументы: command — аргумент для Popen. Собственно то, что будет запускать в Shell'е. Но вместо цельной строки («python main.py») рекомендуют задавать списком (['python', 'main.py']); force_report — управление выводом в лог. Может принимать значения: True — принудительный вывод в лог, False — вывод, если получен код ошибки, None — запретить вывод в лог. from subprocess import Popen, PIPE def shell_command(command, '.join(x.decode('utf-8').split()) # Считываем (и преобразуем) поток stdout report = [transform(x) for x in proc.stdout] # Добавляем поток stderr report.extend([transform(x) for x in proc.stderr]) # Выводим в лог зависимо от значения аргумента force_report if force_report is True or (force_report is not None and proc.returncode > 0): to_log('[ SHELL ] %s (code: %d):\n%s\n' % (' '.join(command), proc.returncode, '\n'.join(report))) # Возвращаем код завершения подпроцесса и консольный вывод в виде списка return proc.returncode, report Head revision Список файлов текущего commit'а легко получается с помощью консольной команды Git — «diff». В нашем случае потребуются измененные или новые файлы: from os.path import basename # Устанавливаем глобальный код результата result_code = 0 # Получаем список файлов текущего commit'а code, report = shell_command( ['git', 'diff', '--cached', '--name-only', ], params.get('verbose')) if code .')[-1] > В результате targets будет содержать нечто подобное: ['C:\\dev\\projects\\example\\demo\\daemon_example.py', 'C:\\dev\\projects\\example\\main.py', 'C:\\dev\\projects\\example\\test.py', 'C:\\dev\\projects\\example\\test2.py'] Самый мучительный этап завершен — дальше будет проще. Проверка на валидность Здесь все просто — пройдемся по всем скриптам, заданным в --check, и запустим каждый со списком targets: if params.get('check') is not None: for script in params.get('check'): code, report = shell_command( [params.get('exec'), script] + targets, params.get('verbose')) if code > Пример содержимого лога на коде не прошедшем проверку на валидность: [ SHELL ] C:\python34\python.exe c:\dev\projects\pre-commit-tool\pep8.py C:\dev\projects\example\demo\daemon_example.py (code: 1): C:\dev\projects\example\demo\daemon_example.py:8:80: E501 line too long (80 > 79 characters) Запуск тестов Аналогично поступаем и с юнит-тестами, только без targets: if params.get('test') is not None: for script in params.get('test'): code, report = shell_command( [params.get('exec'), script], params.get('verbose')) if code > Отображаем лог В зависимости от глобального кода результата и параметров --openlog и --forcelog, принимаем решение — отображать лог или нет: if params.get('openlog') and (result_code > 0 or params.get('forcelog')): if sys.version_info[0] > 2: Popen([params.get('openlog'), log_filename], Открытие лога для данной версии Python не поддерживается.') Примечание. Для Python 2.x мне не удалось запустить независимый процесс из текущего скрипта. А в этом случае скрипт будет «выполняться», пока не будет закрыт блокнот. Неудобство в том, что оболочка Git не получает управление, пока «выполняется» скрипт (не закрыт блокнот). Если кто-нибудь знает, как это победить — поделитесь решением. Буду премного благодарен. И не забываем в конце скрипта вернуть в оболочку Git код результата: exit(result_code) Все. Скрипт готов к использованию. Корень зла Хук — это файл с именем «pre-commit» (без расширения), который нужно создать в каталоге: <каталог_проекта>/.git/hooks/ Для корректного запуска на Windows есть пара важных моментов: 1. Первая строка файла должна быть: #!/bin/sh Иначе увидем такую ошибку: GitHub.IO.ProcessException: error: cannot spawn .git/hooks/pre-commit: No such file or directory 2. Использование стандартного разделителя при указании пути приводит к подобной ошибке: GitHub.IO.ProcessException: C:\python34\python.exe: can't open file 'c:devprojectspre-commit-toolpre-commit.py': [Errno 2] No such file or directory Лечится тремя способами: используем двойной обратный слеш, либо берем весь путь в двойные кавычки, либо используем "/". К примеру, Windows съедает это и не давится: #!/bin/sh c:/python34/python "c:\dev\projects\pre-commit-tool\pre-commit.py" -c -t c:\\dev\\projects\\example\\test.py Конечно, так делать не рекомендуется :) Используйте любой способ, который вам нравится, но один. Приемочные испытания Тренироваться будем «на кошках»: Тестовый commit имеет новые, переименованные\измененные и удаленные файлы. Также, включены файлы, не содержащие код; сам код содержит ошибки оформления и не проходит один из юнит-тестов. Создадим хук с валидацией, тестами и открытием подробного лога: c:/python34/python c:/dev/projects/pre-commit-tool/pre-commit.py -c -t test.py test2.py -vfo И пробуем выполнить commit. Подумав пару секунд, Git desktop просигналит об ошибке: А в соседнем окне блокнот отобразит следующее: [ SHELL ] git diff --cached --name-only > .gitattributes1 demo/daemon_example.py main.py test.py test2.py [ SHELL ] C:\python34\python.exe c:\dev\projects\pre-commit-tool\pep8.py C:\dev\projects\example\demo\daemon_example.py C:\dev\projects\example\main.py C:\dev\projects\example\test.py C:\dev\projects\example\test2.py (code: 1): C:\dev\projects\example\demo\daemon_example.py:8:80: E501 line too long (80 > 79 characters) C:\dev\projects\example\demo\daemon_example.py:16:5: E303 too many blank lines (2) C:\dev\projects\example\demo\daemon_example.py:37:5: E303 too many blank lines (2) C:\dev\projects\example\demo\daemon_example.py:47:5: E303 too many blank lines (2) C:\dev\projects\example\main.py:46:80: E501 line too long (90 > 79 characters) C:\dev\projects\example\main.py:59:80: E501 line too long (100 > 79 characters) C:\dev\projects\example\main.py:63:80: E501 line too long (115 > 79 characters) C:\dev\projects\example\main.py:69:80: E501 line too long (105 > 79 characters) C:\dev\projects\example\main.py:98:80: E501 line too long (99 > 79 characters) C:\dev\projects\example\main.py:115:80: E501 line too long (109 > 79 characters) C:\dev\projects\example\main.py:120:80: E501 line too long (102 > 79 characters) C:\dev\projects\example\main.py:123:80: E501 line too long (100 > 79 characters) [ SHELL ] C:\python34\python.exe test.py (code: 1): Test 1 - passed Test 2 - passed [!] Test 3 FAILED [ SHELL ] C:\python34\python.exe test2.py (code: 0): Test 1 - passed Test 2 - passed Повторим этот же commit, только без подробного лога: c:/python34/python c:/dev/projects/pre-commit-tool/pre-commit.py -c -t test.py test2.py -fo Результат: [ SHELL ] C:\python34\python.exe c:\dev\projects\pre-commit-tool\pep8.py C:\dev\projects\example\demo\daemon_example.py C:\dev\projects\example\main.py C:\dev\projects\example\test.py C:\dev\projects\example\test2.py (code: 1): C:\dev\projects\example\demo\daemon_example.py:8:80: E501 line too long (80 > 79 characters) C:\dev\projects\example\demo\daemon_example.py:16:5: E303 too many blank lines (2) C:\dev\projects\example\demo\daemon_example.py:37:5: E303 too many blank lines (2) C:\dev\projects\example\demo\daemon_example.py:47:5: E303 too many blank lines (2) C:\dev\projects\example\main.py:46:80: E501 line too long (90 > 79 characters) C:\dev\projects\example\main.py:59:80: E501 line too long (100 > 79 characters) C:\dev\projects\example\main.py:63:80: E501 line too long (115 > 79 characters) C:\dev\projects\example\main.py:69:80: E501 line too long (105 > 79 characters) C:\dev\projects\example\main.py:98:80: E501 line too long (99 > 79 characters) C:\dev\projects\example\main.py:115:80: E501 line too long (109 > 79 characters) C:\dev\projects\example\main.py:120:80: E501 line too long (102 > 79 characters) C:\dev\projects\example\main.py:123:80: E501 line too long (100 > 79 characters) [ SHELL ] C:\python34\python.exe test.py (code: 1): Test 1 - passed Test 2 - passed [!] Test 3 FAILED Исправим ошибки, повторим commit, и — вот он, долгожданный результат: Git desktop не ругается, а блокнот показывает пустой pre-commit.log. PROFIT. Готовый пример можно посмотреть здесь. [UPD] Вместо заключения Конечно, данный скрипт — не панацея. Он полезен, когда все необходимые проверки ограничиваются локальным запуском проверочных скриптов. В комплексных проектах обычно применяется концепция Непрерывной интеграции (или CI), и здесь на помощь приходят Travis (для Linux и OS X) и его аналог AppVeyor (для Windows). Всем приятного кодинга и корректных коммитов.

Метки:  

Договор Делимобиля. Абстрагируемся и разделим

Суббота, 11 Июня 2016 г. 01:00 + в цитатник
По Делимобилю уже славно потоптались все кому не лень. Особо наивные граждане даже восхитились тем, что компания предложила ограничить ответственность фиксированной суммой. Пока историй с разборками по новым правилам не было, что там будет получаться в итоге — не вполне понятно. Но надо понимать, что договор-то никуда не делся. А значит смотреть и читать его стоит внимательно, что, собственно, все вокруг и говорят. Мол, читайте договор и потом не удивляйтесь. ОК. Давайте читать. Инструкция по чтению такая: я буду писать по-русски, но в скобках давать более точные формулировки. Если вам жалко мозг — скобки не читайте :-) Начнем с того, что договор аренды ТС, который сервис «Делимобиль» разработал для своих клиентов, является договором присоединения, что не только прямо указано в самом тексте договора, но и следует из того, как он устроен (фактического порядка его заключения). Запомним это важное словосочетание «Договор Присоединения». Это довольно сильный козырь. Специфика договора присоединения заключается в том, что клиент (присоединившаяся к договору сторона) вправе потребовать расторжения или изменения договора, если договор присоединения содержит явно хреновые (обременительные) для присоединившихся условия, которые они, исходя из здравого смысла (своих разумно понимаемых интересов), не приняла бы, если бы им дали шанс (при наличии у нее возможности участвовать в определении условий договора). Читаем пункт 2 статьи 428 ГК РФ, и нам есть немного счастья в перспективе, потому как суд вполне может изменить или расторгнуть явно невыгодный договор по требованию лузера (слабого контрагента). Более того, как указано в пункте 9 Постановления Пленума ВАС РФ от 14.03.2014 № 16 «О свободе договора и ее пределах»: «… поскольку согласно пункту 4 статьи 1 ГК РФ никто не вправе извлекать преимущество из своего недобросовестного поведения, слабая сторона договора вправе заявить о недопустимости применения несправедливых договорных условий на основании статьи 10 ГК РФ или о ничтожности таких условий по статье 169 ГК РФ». То бишь клиент сервиса, в случае несогласия с беспределом (примененными в отношении него договорными санкциями), может послать ко всем чертям (обосновать ничтожность этих условий договора со ссылкой на вышеуказанную судебную позицию). Не буду утверждать, что шансы великолепны, но они есть. Перейдем к оценке правомерности беспредела (спорных положений договора). Начнем с положений о «тройной ответственности», вокруг которых идет основной вой: само по себе трясти с лузера (возложение на должника) неустойки плюс убытки не противоречит закону. Увы. Ст. 394 ГК позволяет кредитору (компании) взыскать неустойку поверх всех убытков, если это прямо предусмотрено в договоре. Так что закон тут не нарушается. Возмещение убытков в полном размере означает, что в результате их возмещения кредитор должен остаться при своих (быть поставлен в положение, в котором он находился бы, если бы обязательство было исполнено надлежащим образом). Поэтому в убытки включают как реальный ущерб, так и упущенную выгоду (ст.15 ГК). НО! Однако за некоторые штрафы можно и нужно побороться, если что. Даже если суд признает неустойки законными, это не лишает вас (заинтересованную сторону) требовать ее уменьшения, ссылаясь на правила ст. 333 ГК РФ. Эта статья вообще очень полезна для осмысления всем, кто видит в своих договорах драконовские санкции, потому как она о соразмерности реального ущерба и санкций. В этой части суду нужно будет учесть разъяснения Пленума Верховного Суда РФ, изложенные в Постановлении от 24.03.2016 г. № 7 «О применении судами некоторых положений Гражданского кодекса Российской Федерации об ответственности за нарушение обязательств», в частности, о признаках очевидной несоразмерности неустойки последствиям нарушения обязательства, и, в частности, что неустойка, как вид ответственности, должна быть связана с нарушением. Ну и тут начинаем бороться, потому как, например, денежная компенсация за администрирование ответственности (п.5.28 договора) — явная несоразмерность. Как минимум спорно выглядят потери компании при получении штрафа с клиента, учитывая что деньги списываются с карты автоматически (безакцептно). Спорно также само пропорциональное возрастание компенсации в зависимости от размера списания, так как объем администрирования не должен сильно зависеть от размера штрафов. Клиенты же не платят компенсацию за заключение договора, хотя действия менеджеров компании по заключению тоже можно назвать «администрированием». Вот сейчас главное, чтобы это не оказалось советом... Отдельной песней выглядят условия о привлечении к оценке ущерба только эксперта, названного арендодателем. Что он там насчитает, мы все понимаем. Ровно про это же, положения п. 2.8.8 договора о том, что оценка попадания (правомерности наложенных административных штрафов за нарушение ПДД и величина ущерба) определяется исключительно по усмотрению компании-арендодателя. Эти положения кроме как адом (дискриминационными) назвать нельзя. Водитель-пользователь авто не может быть лишен прав и возможностей, предоставленных ему законом: права на обжалование (оспаривание) административных штрафов, участие в доказывании суммы ущерба. Свобода договора, на которую ссылается компания, не должна приводить к ущемлению правоспособности другой стороны. Еще более по-русски — если положения договора противоречат закону, то они пофиг. А по закону вы имеете право участвовать во всем, что определяет ваши будущие финансовые потери. Дальше у нас идет п.5.7 договора, который посвящен всяким другим моментам, за которые вам придется отвечать в случае чего (основаниям ответственности клиента). В нормальной жизни (по общим правилам возмещения вреда), страдалец (причинитель) освобождается от его возмещения, если докажет, что вред причинен не по его вине. Вина и невиновность — важные понятия. Невиновность означает, что он нормально обращается с машиной (при нормальной степени заботливости и осмотрительности, пользователь авто принял все меры для сохранения арендованной машины). Однако п.5.7 договора сказано, что вы попадаете на бабки, даже если вы не особо “при чем” (ответственность клиента за повреждения и другой вред авто даже «при случайности”, даже когда действия клиента во время “сессии аренды” не явились причиной наступления негативных последствий). Например, получается, что если автомобиль случайно угонят, когда вы вышли в магазин, то вы будете возмещать его стоимость. Но ведь невиновная ответственность за вред предусмотрена законом (ч.2 ст.1064), а не договором. Это еще один аргумент против “случайной” ответственности клиента. Обобщаем. Дисклеймер. В целом, на что клиент сервиса «Делимобиль» может рассчитывать в случае судебного спора с компанией — это вопрос не из легких. Дело в том, что абсолютно точно предсказать перспективу любого судебного спора нельзя никак. Но все же аргументация у нас есть: 1. Явно несоразмерные, “драконовские” санкции, которые по договору были “наложены” на потребителя, он может оспорить со ссылкой на специфику договора присоединения. Если следовать правилам Гражданского кодекса и позиции Верховного суда РФ о договоре присоединения, получается, что потребитель, как слабая сторона договора, вправе в свою защиту от несправедливых условий договора (например, нескольких видов штрафов за одно нарушение, явного несоответствия размера штрафа и суммы ущерба, причиненного компании и т.п.) говорить о недопустимости злоупотребления правом (ст.10 ГК РФ) или о ничтожности подобных договорных условий (ст.169 ГК РФ). Если суд признает доводы потребителя обоснованными, то откажет компании в части применения к арендатору авто этих положений договора. 2. Если даже суд согласится с законностью неустоек, это не лишает заинтересованную сторону права требовать ее уменьшения (по правилам ст. 333 ГК РФ). Например, есть в договоре так называемая денежная компенсации за администрирование ответственности (п.5.28 договора). Обоснование в пользу уменьшения этого штрафа (если не полное исключение) может быть таким: спорно выглядят потери компании при получении штрафа с клиента, учитывая безакцептное списание денег с его карты. Компания не оказывает положительную или удобную услугу для провинившегося клиента, списывая штраф. В результате можно попытаться добиться снижения или полного отказа во взыскании с клиента сервиса подобных штрафов. 3. Как утверждают клиенты сервиса, в случае ДТП документы об оценке ущерба, проведенной по инициативе «Делимобиля», на руки им не выдают. Здесь компания очевидно опирается на п.2.8.8 договора о привлечении к оценке ущерба только эксперта, названного арендодателем, о том, что оценка правомерности наложенных административных штрафов за нарушение ПДД и величина ущерба определяется исключительно по усмотрению компании-арендодателя. Здесь опять-таки клиент сервиса может выдвинуть против компании свои права как присоединившейся стороны и сослаться на недопустимость злоупотребления правом. 4. Если оспорить п.5.7 договора в части “объективного вменения“, т.е. возложения на клиента всех рисков угона и повреждения арендованного авто, то суд вполне возможно встанет на сторону пользователя и откажет компании во взыскании с арендатора этого ущерба и соответствующих штрафов. (С) Алина Тухватуллина. Кирилл Готовцев

Метки:  

OAuth-авторизация в Mozilla Thunderbird: от зарождения до релиза

Понедельник, 06 Июня 2016 г. 19:18 + в цитатник
Некоторое время назад мы рассказывали о том, как в Mail.Ru реализован сбор почты с использованием протокола OAuth 2.0. Мы продолжаем повышать безопасность почты и продвигать стандарт OAuth 2.0 в массы. И сегодня расскажем о том, как мы добавили OAuth-авторизацию в почтовый клиент Mozilla Thunderbird. На этом примере мы разберем процесс внесения новой фичи в продукт с открытым исходным кодом, от создания тикета до релиза. Если вы давно хотели сделать свой первый pull request, но не знали как, — читайте нашу историю. 1. Общая схема работы На действия пользователя Thunderbird открывает веб-вью с адресом для OAuth-авторизации. Если пользователь успешно прошел процедуру авторизации и согласился предоставить приложению доступ к своим данным, то мы перенаправляем пользователя на адрес, указанный в параметре redirect_uri. Так приложение получит авторизационный токен и сможет использовать его для работы с нашей почтовой службой. Адрес для запроса токена: https://o2.mail.ru/login > Стоит заметить, что значение localhost для параметра redirect_uri приложение задает самостоятельно, а параметр state (используется клиентом для поддержки связи между запросом и колбэком) не передает вовсе. Ниже представлена схема взаимодействия приложения с сервисом: 2. Как устроен процесс интеграции, основные этапы Хотя сам процесс интеграции довольно простой и не занимает много времени, все же стоит рассказать об отдельных моментах, которые следует планировать заранее. Поскольку Thunderbird — это продукт компании Mozilla, мы сразу отправились на MDN. Так мы быстро получили общее представление об основных этапах интеграции: Тикет на добавление почтового клиента. Тикет на добавление конфигурации в ISP-базу. Патч в репозиторий comm-central. Патч в ISP-базу. Тестовая сборка. Сохранение обратной совместимости. Тестирование функциональности в ранних релизах. Тестирование релиза. Далее рассмотрим каждый этап в отдельности. 2.1. Тикет на добавление почтового клиента Перед тем как ставить тикет, убедитесь, что до вас этого никто не сделал. Постановка тикета является ключевым этапом в решении любой похожей задачи, поэтому очень важно правильно заполнить все обязательные поля: Продукт: Структура репозитория comm-central разделена на независимые продукты. С этим у нас проблем не возникло, поскольку название продукта MailNews сразу упоминается на стартовой странице. Компонент: Напротив этого пункта есть подсказка, однако здесь и так интуитивно понятно, что работа связана с сетью, поэтому выбираем Networking. Версия: Чтобы понять, какую версию релиза выбрать, следует обратиться к странице со списком релизов. Однако этой информации будет явно недостаточно, поскольку нам важно понимать, на каком этапе находится еще не вышедший релиз. С этим нам поможет календарь релизов. Более подробную информацию о релиз-цикле можно получить на соответствующей странице. Но если вы все-таки сомневаетесь, какую версию релиза выбрать, то не стесняйтесь задать свой вопрос в списке рассылок или IRC-канале. При крайней необходимости вам помогут ревьюверы тикета. Платформа: В нашем случае продукт платформонезависимый (all). Важность: Поскольку мы расширяем функциональность, тип будет enhancement. Ключевые слова: Список ключевых слов ограничен. Беглый поиск по похожим тикетам подсказал выбрать feature, user-doc-needed. Совет: чтобы случайно не пропустить какой-либо этап, добавьте к себе календарь. 2.2. Тикет на добавление конфигурации в ISP-базу Нам попался хороший ревьювер, который помог с заполнением большинства полей и релизом. Смотрите пример нашего тикета. 2.3. Патч в репозиторий comm-central Если вы обратили внимание, сообщество Mozilla очень трепетно относится к документированию своих продуктов. Руководство по сборке продукта, стилистике написания программного кода и пр. Все ссылки на это располагаются в одном месте и не требуют, как это часто бывает с другими продуктами, прохождения некоего квеста. Сразу скажу, что никакого "rocket science" в добавлении нового OAuth-провайдера в Thunderbird нет, — это становится понятно после грепа по репозиторию и беглого ознакомления с исходным кодом. Несмотря на то что файлов с ключевым словом OAuth было довольно много: ? hg clone http://hg.mozilla.org/comm-central ... ? hg grep --ignore-case --files-with-matches oauth | wc -l 91 Интуиция подсказывала, что все должно быть проще. И мы не ошиблись, когда открыли первый из списка файл: mailnews/base/util/OAuth2Providers.jsm Не буду томить, просто смотрите дифф: ? hg log -p -l 1 changeset: [draft] 18512:a2f404184ac0 support_oauth_mail_ru_1231642 tip author: Alexander Abashkin <monolithed@gmail.com> date: Mon, 14 Dec 2015 15:17:09 +0300 (4 months ago) summary: Bug 1231642 - Log in to Mail.Ru (IMAP/SMTP) using OAuth M mailnews/base/util/OAuth2Providers.jsm diff --git a/mailnews/base/util/OAuth2Providers.jsm b/mailnews/base/util/OAuth2Providers.jsm --- a/mailnews/base/util/OAuth2Providers.jsm +++ b/mailnews/base/util/OAuth2Providers.jsm @@ -10,32 +10,41 @@ var EXPORTED_SYMBOLS = ["OAuth2Providers var {classes: Cc, interfaces: Ci, results: Cr, utils: Cu} = Components; // map of hostnames to [issuer, scope] var kHostnames = new Map([ ["imap.googlemail.com", ["accounts.google.com", "https://mail.google.com/"]], ["smtp.googlemail.com", ["accounts.google.com", "https://mail.google.com/"]], ["imap.gmail.com", ["accounts.google.com", "https://mail.google.com/"]], ["smtp.gmail.com", ["accounts.google.com", "https://mail.google.com/"]], + ["imap.mail.ru", ["o2.mail.ru", "mail.imap"]], + ["smtp.mail.ru", ["o2.mail.ru", "mail.imap"]], ]); // map of issuers to appKey, appSecret, authURI, tokenURI var kIssuers = new Map ([ ["accounts.google.com", [ '406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com', 'xxxxxxxxxxxx', 'https://accounts.google.com/o/oauth2/auth', 'https://www.googleapis.com/oauth2/v3/token' ]], + ["o2.mail.ru", [ + 'thunderbird', + 'xxxxxxxxxxxx', + 'https://o2.mail.ru/login', + 'https://o2.mail.ru/token' + ]], ]); Если вы обратили внимание, то, к сожалению, мы пока не поддержали новый протокол, который позволяет динамически регистрировать клиент, но мы над этим работаем! И далее аттач патча по номеру тикета: hg diff -g > 1231642.patch P. S. Будьте готовы к тому, что клонирование репозитория требует до 5 Гб свободного места на диске. 2.4. Патч в ISP-базу Эта конфигурация необходима для выбора протокола, который будет использоваться по умолчанию. Пример файла-автоконфига: https://autoconfig.thunderbird.net/v1.1/mail.ru. SNN-репозиторий ISP находится по следующему адресу: https://svn.mozilla.org/mozillamessaging.com/sites/autoconfig.mozillamessaging.com/ Поскольку мы уже имели дело с этим конфигом ранее, то показать дифф будет проще, чем рассказать: ? svn diff trunk/mail.ru | vi -R - --- trunk/mail.ru| (revision 150325) +++ trunk/mail.ru| (working copy) @@ -13,6 +13,7 @@ <incomingServer > На этом этапе торопиться не стоит, даже если ваш сервер уже поддерживает OAuth-авторизацию, ведь можно получить сайд-эффект в виде неработающей авторизации. В качестве альтернативы вы можете разместить файл автоконфига на своем сервере: https://autoconfig.mail.ru/mail/config-v1.1.xml. В таком случае у вашего файла будет более высокий приоритет и вы сможете самостоятельно управлять способом авторизации не только на этапе тестирования. Если у вашего почтового сервиса есть алиасы доменов, то переживать не стоит: ISP-сервер смотрит на MX-записи. Более подробно об этом способе конфигурации сервера смотрите здесь. 2.5. Тестовая сборка Клонируем репозиторий: hg clone http://hg.mozilla.org/comm-central cd comm-central python client.py checkout Добавляем конфигурацию для тестового окружения: ? echo $'ac_add_options > .mozconfig Собираем проект: ./mozilla/mach build Если во время сборки появится ошибка о том, что исходный код устарел, то выполните следующую команду и перезапустите сборку еще раз: ./mozilla/mach mercurial-setup --update-only Более подробно о сборке проекта смотрите здесь. Возможные проблемы: Для OS X 10.9–10.10 (в 10.11 эта опция мешает сборке) может потребоваться добавить следующую опцию: echo 'ac_add_options Также в процессе сборки может возникнуть требование установить autoconf 2.13: fx-team ./mach build /usr/bin/make -f client.mk -s Adding client.mk options from : > Решение для OS X: brew rm autoconf brew tap homebrew/versions brew install autoconf213 Возможно, это наша вина, но по каким-то причинам файл configure сгенерировался с синтаксическими ошибками: 0:00.70 *** Fix above errors and then restart with\ 0:00.70 "/opt/local/bin/gmake -f client.mk build" 0:00.71 /comm-central/client.mk:361: ошибка выполнения рецепта для цели «configure» 0:00.71 gmake[1]: *** [configure] Ошибка 1 Решение: rm configure && ./mozilla/mach build Такая ошибка свидетельствует об отсутствии в системе компилятора YASM. 0:09.52 configure:21252: checking for CoreMedia/CoreMedia.h 0:09.52 configure:21262: /usr/bin/clang -E -Qunused-arguments conftest.c >/dev/null 2>conftest.out 0:09.52 configure: error: yasm is a required build tool for this architecture when webm is enabled. You may either install yasm or --disable-webm (which disables the WebM video format). See https://developer.mozilla.org/en/YASM for more details. 0:09.52 *** Fix above errors and then restart with\ 0:09.52 "/opt/local/bin/gmake -f client.mk build" 0:09.52 /comm-central/client.mk:361: ошибка выполнения рецепта для цели «configure» 0:09.52 gmake[1]: *** [configure] Ошибка 1 Решение (для OS X): brew install yasm && ./mozilla/mach build Информацию о возможных проблемах сборки можно посмотреть в файле client.mk. Будьте готовы к тому, что исходный код проекта и сборка будет занимать на диске 8,3 Гб! Запуск проекта: В конфигурации мы указали ключ --enable-debug, он поможет нам видеть всю отладочную информацию, включая исходящие запросы к сторонним сервисам. ./mozilla/mach run Команда run сама найдет путь к приложению и запустит его. В нашем случае после сборки приложение расположилось по следующему пути: ./obj-x86_64-apple-darwin15.0.0/dist/DailyDebug.app/Contents/MacOS/thunderbird Автоматизированное тестирование: Для автоматизации тестирования Thunderbird использует фреймворк MozMill и XPCShell. Запускаем модульные тесты: ./mozilla/mach xpcshell-test Более подробную информацию о модульном тестировании смотрите ниже по ссылкам: Руководство по XPCShell. Инструкция по запуску XPCShell-тестов в продукте MailNews. Информация о фреймворке для тестирования AsyncTestUtils. Запускаем интеграционные тесты: ./build/pymake/make.py mozmill Для интеграционного тестирования используется фреймворк MozMill. После локального прогона тесты запускает ревьювер, он же и проверяет заявленную функциональность. Как только релиз-инженер включит ваш патч в релиз в Treeherder CI, будет запущен цикл регрессионного тестирования. Дополнительную информацию о других видах (например, тестирование на утечки памяти) тестирования смотрите по этой ссылке. Руководство по Treeherder CI смотрите здесь. 2.6. Тестирование функциональности в ранних релизах Как только релиз-инженер включит ваш патч в ранний релиз, вы можете начинать следующий этап тестирования. Согласно рабочему процессу, первым собирается ранний релиз под названием Aurora, далее Beta и релиз. Ссылки на скачивание ранних релизов находятся здесь. Календарь поможет не пропустить важную для вас дату релиза. Общая схема этапов релиза выглядит так: Релиз-цикл каждого этапа занимает шесть недель. 2.7. Сохранение обратной совместимости Для клиентов, которые еще не обновились до 45-го релиза, должна работать стандартная схема авторизации. И если об этом не подумать заранее, то пользователь всегда будет видеть ошибку авторизации (если вручную не сменит способ авторизации): Для того чтобы сохранить обратную совместимость, мы стали отдавать конфигурационный файл, ориентируясь на User-Agent: location /mail/config-v1.1.xml 2\d } Выставляем заголовок Vary: User-Agent add_header Vary User-Agent; Теперь пользователи старых клиентов будут получать файл конфигурации без OAuth. Проверяем: ? curl 'https://autoconfig.mail.ru/mail/config-v1.1.xml' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 Lightning/4.0.5.2' 2>/dev/null | fgrep -i oauth ? curl 'https://autoconfig.mail.ru/mail/config-v1.1.xml' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/45.0.0 Lightning/4.0.5.2' 2>/dev/null | fgrep -i oauth <authentication>OAuth2</authentication> <authentication>OAuth2</authentication> <authentication>OAuth2</authentication> <authentication>OAuth2</authentication> 2.8. Тестирование релиза Теперь, когда несколько долгих месяцев позади, релиз можно скачивать с главной страницы! Далее мы покажем, что же в итоге увидит пользователь. 3. Сценарий использования Способов добавления почтового аккаунта в Thunderbird несколько, однако все они сводятся к одним и тем же действиям, поэтому рассмотрим самый очевидный: 1. Открываем стартовую страницу. В разделе создания нового почтового аккаунта выбираем Email: 2. Пропускаем этот шаг, поскольку у нас уже есть почтовый аккаунт: 3. Добавляем почтовый адрес и жмем кнопку «Продолжить»: 4. Выбираем протокол сбора почты (IMAP) и жмем кнопку «Готово»: 5. На этом шаге проверяем настройки почтового сервера и, если все в порядке, жмем кнопку «Готово»: 6. Вводим авторизационные данные от своей учетной записи в Mail.Ru: 7. Соглашаемся с тем, что Thunderbird будет собирать почту с нашего аккаунта: 8. Ожидаем, когда письма будут скачаны: 4. Заключение Как видите, мы стараемся развивать не только свои opensource-проекты, но и сторонние. Мы крайне щепетильны в вопросах безопасности, поэтому решили подключиться к разработке Mozilla Thunderbird и помочь с реализацией OAuth 2.0. Надеемся, наш пост воодушевит кого-то сделать свой первый pull request, и мир opensource статет чуточку лучше. 5. Благодарности Kent James — за код-ревью и включение нашего патча в ранний релиз. Andrew Sutherland — за помощь с ISP. 6. Информационные ссылки Как в Mail.Ru реализован сбор почты с использованием протокола OAuth 2.0 OAuth 2.0 простым и понятным языком Вводная информация по автоматизированному тестированию Thunderbird Руководство по XPCShell Инструкция по запуску XPCShell-тестов в продукте MailNews Тестирование утечек памяти в продукте MailNews Информация о фреймворке для тестирования AsyncTestUtils Репозиторий comm-central Репозиторий ISP FTP-сервер Thunderbird Treeherder CI Руководство по Treeherder CI Основная страница клиента Thunderbird Полный список релизов Thunderbird Ранние релизы Thunderbird Багтрекер Bugzilla Thunderbird API Руководство по сборке Thunderbird Документация Thunderbird Документация о репозитории comm-central Каналы связи разработчиков Thunderbird Требования к стилистике написания программного кода Информация о релиз-менеджменте Mozilla Календарь событий Mozilla

Метки:  

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

Воскресенье, 05 Июня 2016 г. 00:31 + в цитатник
Есть такие люди — тестировщики. Крайне нужные люди. Помогают совершенствовать приложения. Но есть у них страсть: все тестируют. Везде ищут баги: и в разрабатываемых нами программах, и даже в блюдах нашей столовой. Теперь вот решили протестировать и мероприятия серии CoLaboratory. А то мало ли, в друг и в этом формате публичных обсуждений есть какие-нибудь недочеты. В качестве тестового сценария они решили использовать дискуссию, посвященную тестированию приложений на мобильных платформах. Собственно, именно на это мероприятие мы и приглашаем всех тех, кому интересно тестирование мобильных приложений и ручное тестирование вообще. Будем рады видеть вас в московском офисе «Лаборатории Касперского», 7 июня в 13 часов дня. На всякий случай напоминаем адресc: Ленинградское шоссе, д.39А, стр.2. Зарегистрироваться на мероприятие можно вот на этой страничке. В рамках мероприятия наши эксперты выступят с пятью докладами. Для начала Анна Карпенко расскажет о функциональности, которую в обязательном порядке следует проверять на всех мобильных устройствах, а также сравнит тестовые сценарии для мобильных и десктопных приложений. Кроме того, расскажет и истории успеха. Ну и про фейлы тоже расскажет — куда же без них. В частности, о том, как мы однажды не вписались в гайдлайны Apple или о том, как Google счел некорректным механизм самозащиты продукта под Android, который требовал авторизации для деинсталляции. Затем Иван Цепелев поведает об эволюции средств мобильного тестирования в «Лаборатории Касперского». В частности, он расскажет о том, как выглядит APK изнутри и зачем обфусцировать код, приведет примеры основных команд Android Debug Bridge (ADB), которые позволяют работать с эмулятором и с реальными устройствами. Попутно Иван объяснит, что такое портал my.kaspersky.com, как мы его используем для синхронизации пользовательских данных между одним и тем же продуктом на разных платформах, а главное про тонкие места в тестировании этого решения. Третьим выступит Дмитрий Мячин. Он опишет проблемы характерные для конкретных версий системы Android и для прошивок конкретных устройств. В частности, он обещает рассказать о: случаях, когда в результате изменения поведения новой версии системы нам приходилось полностью менять логику продукта; случаях использования абсолютно штатных, документированных методов и API, которое, тем не менее, порой приводило к критическим ошибкам системы; смене политики Google которая приводила к выкидыванию из продукта возможностей, которые уже долгое время приносили пользу. Следующее выступление будет про функцию рассылки новостей внутри продукта. Дмитрий Бондаренко расскажет, как компания использует эту функцию, зачем она вообще нужна, и, самое главное, с какими проблемами мы столкнулись при его тестировании, насколько оно было сложно, и почему мы не смогли протестировать эту функцию сразу. Последним выступит Никита Воронов, который расскажет о том, что такое Exploratory testing и почему надо тестировать за тестировщиками. Попутно он объяснит, что мы подразумеваем под понятием риск, как он формируется, откуда мы берем показатели популярности и критичности рисков, как строим сценарии тестирования, откуда черпаем информацию и как дополнить тестирование команды. Программа мероприятия: 13:00 Открытие регистрации участников 13:45 Открытие конференции, приветственное слово — Павел Романов 14:00 Специфика тестирования мобильных приложений — Анна Карпенко 15:00 Эволюция средств мобильного тестирования в ЛК — Иван Цепелев 16:00 Перерыв 17:00 Device specific проблемы устройств под Android — Дмитрий Мячин 18:00 Про in-product marketing (IPM) — Дмитрий Бондаренко 19:00 Exploratory testing — Никита Воронов
?????? ?? ?????????? ???????????? ????

Метки:  

Разработка Docker контейнеров с помощью системы многоцелевых сценариев Sparrow

Суббота, 04 Июня 2016 г. 19:40 + в цитатник
В этой статье я хотел бы рассказать как можно создавать сценарии сборки имиджей для Docker контейнеров с помощью системы многоцелевых сценариев Sparrow*. (*) Примечание — для понимания некоторых технических нюансов данной статьи желательно иметь хотя бы поверхностное знакомство с системой многоцелевых сценариев Sparrow, краткое введение в которую ( помимо страниц документации ) можно найти в моей предыдущей статье на habrahabr.ru. Разработка Docker контейнеров Вначале немного проблематики. Имеем задачу описать сборку Docker имиджа с помощью Dockerfile. Если сценарий сборки нетривиален и содержит множество инструкций, нужно как-то выкручиваться. Помимо того, что Dockerfile не может содержать более 120 слоев ( насколько я правильно понял из документации по Docker ), иметь дело с развесистым Dockerfile не очень приятно. Что можно с этим поделать? Очевидные варианты — вынести код сборки в отдельные Bash скрипты в рабочую директорию и делать установку и настройку системы прямо из них. Другой способ — "прикручивать" сбоку какой-нибудь configuration management tool типа chef или ansible. Оставляю на откуп читателю оценку данных альтернатив ( IMHO у них есть свои плюсы и минусы ) и предлагаю третий способ — использование Sparrow. Прежде чем приводить детали реализации хочется сказать: Вариант со Sparrow чем-то то очень похож на использование Bash скриптов, с той лишь разницей, что вся логика установки выносится в Sparrow плагин, со своим исходным кодом, хранящимся в отдельном месте ( git репозитарий или центральное хранилище ). Таким образом, базовая настройка системы в контексте Docker описана в Dockerfile, а более тонкая и сложная внутри Sparrow плагина. Разработка плагина может быть отделена от контекста Dockerfile — что удобно, например вы можете на существующем Docker контейнере отлаживать процесс установки, на прибегая каждый раз к постройке имиджа командой docker build, и, как только плагин будет отлажен и готов к работе, можно еще раз прогнать полный цикл сборки системы посредством все той же командой docker build ( сбросив при этом docker кэш разумеется ). Пример реализации Итак, покажем все на конкретной системе. Требуется собрать имидж с дистрибутивом CentOS и установить приложение, написанное на Ruby версии равной 2.3. После этого запустить основной скрипт приложения из под выделенного пользователя. Исходный код приложения скачивается с некого архивного сервера. Пример взят из реальной жизни, хотя некоторые детали намеренно опущены, дабы не перегружать статью материалом. Базовая конфигурация системы Прежде чем писать код плагина, создадим Dockerfile. За базовый имидж я взял tutum/centos по причине его легковесности. По этой же причине приходится доставлять часть пакетов, но в целом это не является какой-то проблемой. $ cat Dockerfile FROM tutum/centos MAINTAINER "melezhik" <melezhik@gmail.com> RUN yum clean all RUN yum -y install nano git-core RUN yum -y install make RUN yum -y install gcc RUN yum -y install perl perl-devel \ perl-Test-Simple perl-Digest-SHA perl-Digest-MD5 perl-CPAN-Meta \ perl-CPAN-Meta-Requirements perl-Getopt-Long \ perl-JSON perl-Module-CoreList perl-Module-Metadata perl-parent perl-Path-Tiny perl-Try-Tiny \ perl-App-cpanminus perl-JSON-PP perl-Algorithm-Diff perl-Text-Diff \ perl-Spiffy perl-Test-Base perl-YAML perl-File-ShareDir-Install perl-Class-Inspector \ perl-File-ShareDir perl-File-ShareDir-Install perl-Config-General RUN cd /bin/ && curl -L https://cpanmin.us/ -o cpanm && chmod +x cpanm RUN cpanm Sparrow -q Немного комментариев по Dockerfile . nano и git-core необходимы для разработки Sparrow плагина ( смотрите далее ) — мы будем редактировать код сценариев и коммитить изменения в удаленный git репозитарий. gcc, make потребуются для сборки RubyGems и CPAN пакетов. Первые потребуются при установки Ruby через rvm, последние для установки Sparrow. Установка многочисленных perl-* пакетов через yum необходима для оптимизации процесса сборки по скорости, можно было бы не делать этого, т.к. следующая инструкция cpanm -q Sparrow установила бы требуемые зависимости сама, но установка зависимостей через cpanm в общем случае требует гораздо больше времени, чем установка "нативных" для CentOS rpm-ок. Инструкция cpanm Sparrow -q ставит среду разработки многоцелевых сценариев, не забываем, что мы собираемся разрабатывать Sparrow прямо на запущенном Docker контейнере. Итак, попробуем создать имидж: $ docker build -t ruby_app . ... ... Successfully built 25e7cd784c99 Начинаем разрабатывать плагин Отлично, имидж с базовой инфраструктурой у нас есть, можно запустить Docker контейнер и начать разработку плагина прямо на нем. $ docker run -t -i ruby_app /bin/bash $ mkdir ruby-app $ cd ruby-app $ git init . $ git remote add origin https://github.com/melezhik/ruby-app.git $ touch README.md $ git add README.md $ git config --global user.email "melezhik@gmail.com" $ git config --global user.name "Alexey Melezhik" $ git commit -a -m 'first commit' $ git push -u origin master Вышеуказанными командами мы создали шаблон проекта для нашего плагина и закоммитили все в удаленный git репозитарий. URL репозитария мы запомним, он понадобится нам далее, когда мы будем проводить полноценную сборку имиджа командой docker build Теперь сделаем небольшой отступление. Вспомним нашу задачу. Попробуем для удобства разбить ее на независимые части: Создание аккаунта пользователя приложения Установка Ruby посредством rvm Скачивание архива приложения, распаковка и установка зависимостей Для логически отдельных задач в Sparrow предусмотрен механизм модулей, воспользуемся им. Но прежде всего создадим основную историю, в которой будем делегировать выполнение задач разным модулям. Итак, все на том же запущенном Docker контейнере: $ nano hook.bash > Немного комментариев по коду. Мы имеем три второстепенных истории ( модули ) и одну основную, заданную хук файлом (hook.bash), для того, что показать как все это работает создадим заглушки для сценариев в модулях. Да, и дефолтное значение для входного параметра action должно быть задано в suite.ini файле. $ nano suite.ini action create-user install-ruby install-app Создаем заглушки сценариев: $ mkdir -p modules/create-user $ mkdir -p modules/install-ruby $ mkdir -p modules/install-app $ nano modules/create-user/story.bash echo create-user-ok $ nano modules/install-ruby/story.bash echo install-ruby-ok $ nano modules/install-app/story.bash echo install-app-ok А также проверочные файлы: $ nano modules/create-user/story.check create-user-ok $ nano modules/install-ruby/story.check install-ruby-ok $ nano modules/install-app/story.check install-app-ok Теперь запустим все через strun — консольный скрипт для выполнения Sparrow сценариев: $ strun /tmp/.outthentic/93/ruby-app/story.t .. # [/ruby-app/modules/create-user] # create-user-ok ok 1 - output match 'create-user-ok' # [/ruby-app/modules/install-ruby] # install-ruby-ok ok 2 - output match 'install-ruby-ok' # [/ruby-app/modules/install-app] # install-app-ok ok 3 - output match 'install-app-ok' # [/ruby-app] # install-ok ok 4 - output match 'install-ok' 1..4 ok All tests successful. > Отлично. Мы видим, что все сценарии отработали успешно, это и будет скелетом нашего будущего плагина. Осталось только заимплиментить заглушки наших модулей. Сценарий создания пользователя Будем исходить из того что имя пользователя является настраиваемым, дефолтное значение определяем в файле suite.ini : $ cat suite.ini action create-user install-ruby install-app user_name app-user Теперь реализация сценария: $ nano modules/create-user/story.bash > И запуск ( обратите внимание, что здесь мы воспользовались возможностью запуска отдельного сценария с помощью параметра action ): $ strun --param create-user-ok' # [/ruby-app] # install-ok ok 2 - output match 'install-ok' 1..2 ok All tests successful. > Мы видим, что сценарий отработал и пользователь создался. Обратите внимание, что большинство Bash команд внутри сценария завершаются идиоматической конструкцией cmd || exit 1, strun проверяет код выполнения сценария и если он неуспешен, то соответствующий тест проваливается, например так — попробуем создать пользователя с невалидным для системы именем: $ strun --param /tmp/.outthentic/160/ruby-app/story.t .. # [/ruby-app/modules/create-user] # create user id: / # useradd: invalid user name '/' not ok 1 - scenario succeeded not ok 2 - output match 'create-user-ok' # [/ruby-app] # install-ok ok 3 - output match 'install-ok' 1..3 # Failed test 'scenario succeeded' # at /usr/local/share/perl5/Outthentic.pm line 167. # Failed test 'output match 'create-user-ok'' # at /usr/local/share/perl5/Outthentic.pm line 213. # Looks like you failed 2 tests of 3. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests Test Summary Report ------------------- /tmp/.outthentic/160/ruby-app/story.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 1-2 Non-zero exit status: 2 > Сделаю здесь еще небольшое отступление. Зададимся вопросом зачем нам нужно проверочные файлы, если по-сути проверки кода завершения сценария должно быть достаточно. Резонный вопрос. Мы можем думать о проверочных правилах фреймворка Sparrow как о некой альтернативном способе контроля или верификации выполнения наших скриптов. В идеологии Sparrow любой выполняемый сценарий является историей в том смысле, что это некий скрипт, который запускается и чаще всего "сообщает" что-то о своей работе — образно говоря "оставляя след в истории". Это след — стандартный выходной поток stdout, содержимое которого можно провалидировать. Почему это может быть полезно: Не всегда успешный код завершения означает, что все идет хорошо Иногда хочется не выходить из скрипта аварийно ( посредством cmd || exit 1), позволив скрипту сделать свою работу до конца и отложить верификацию посредством проверки через проверочный файл. В качестве конкретного примера можно привести сценарий установки Ruby через rvm, который идет следующим по списку в нашем плане. Сценарий установки Ruby из rvm Вот как будет выглядеть сценарий установки: $ nano modules/install-ruby/story.bash yum -y install which curl -sSL https://rvm.io/mpapis.asc | gpg2 --import - || exit 1 \curl -sSL https://get.rvm.io | bash -s stable --ruby || exit 1 source /usr/local/rvm/scripts/rvm gem install bundler --no-ri --no-rdoc echo ruby version: $(ruby --version) bundler --version echo install-ruby-ok А это — проверочный файл: $ nano modules/install-ruby/story.check regexp: ruby version: ruby 2\.3 install-ruby-ok Теперь запустим данный сценарий: $ strun --param install-ruby-ok' # [/ruby-app] # install-ok ok 3 - output match 'install-ok' 1..3 ok All tests successful. > Хочется обратить внимание, что для верификации версии установленного Ruby мы воспользовались проверочным правилом ввиде регулярного выражения: regexp: ruby version: ruby 2\.3 Конечно rvm позволяет устанавливать требуемую версию явно, просто хотелось здесь привести пример когда проверки, определенные в проверочных файлах позволяют добавить дополнительную верификацию работы сценария с минимальными усилиями. Теперь можно перейти к сценарию установки приложения. Сценарий установки приложения Напомню. Нам будет необходимо: скачать тарбол по заданному урлу распаковать архив перейти в распакованную папку и выполнить команду bundle install --target ./local для установки зависимостей На этом все. Конечно в реальном приложении, нам бы пришлось бы еще запустить какой-нибудь сервис или совершить еще какие-нибудь дополнительные операции, но для демонстрации работы плагина этого должно быть достаточно. Опять таки же для простоты примера пусть у нас есть Ruby приложение состоящее из: Gemfile — в котором будут прописаны зависимости hello.rb — запускаемого скрипа, который просто выводит в консоль строчку Hello World Пакуем все архив и выкладываем все на архивный сервер га локальный nginx, теперь дистрибутив будет доступен по URL: 127.0.0.1/app.tar.gz Обновим код сценария. $ cat suite.ini action create-user install-ruby install-app user_name app-user source_url 127.0.0.1/app.tar.gz $ cat modules/install-app/story.bash > Небольшие комментарии по сценарию: Установку делаем из-под пользователя заданного в конфигурации плагина suite.ini. Для этого нам нужен пакет sudo Последняя команда запускает скрипт приложения hello.rb В проверочном файле требуем что бы в stdout был виден "след" от сценария — строчка 'Hello World' Итак, запустим сценарий: $ strun --param install-app-ok' ok 2 - output match 'Hello World' # [/ruby-app] # install-ok ok 3 - output match 'install-ok' 1..3 ok All tests successful. > Как мы видим приложение действительно установилось и скрипт hello.rb запускается. Добавим еще один "параноидальный" ассерт в проверочный файл для демонстрации возможностей системы проверок Sparrow: $ nano modules/install-app/story.check install-app-ok Hello World generator: <<CODE !bash if test -d /home/$(config user_name)/app; then echo assert: 1 directory /home/$(config user_name)/app exists else echo assert: 0 directory /home/$(config user_name)/app exists fi CODE И запустим сценарий заново. $ strun --param > В выводе получим: $ ok 3 - directory /home/app-user/app exists Публикация Sparrow плагина На этом создание плагина завершено. Закоммитим изменения и сделаем "push" в git репозитарий: $ git add . $ git commit -a -m 'all done' $ git push $ exit Мы вышли из докер контейнера он нам больше не нужен, можно его удалить: $ docker rm 5e1037fa4aef Полный цикл сборки имиджа для Docker контейнера Осталось чуть-чуть изменить Dockerfile, вспоминаем о том, что нам понадобится ссылка на удаленный git репозитарий, где мы разместили код нашего Sparrow плагина, окончательный вариант будет таким: FROM tutum/centos MAINTAINER "melezhik" <melezhik@gmail.com> RUN yum clean all RUN yum -y install nano git-core RUN yum -y install make RUN yum -y install gcc RUN yum -y install perl perl-devel \ perl-Test-Simple perl-Digest-SHA perl-Digest-MD5 perl-CPAN-Meta \ perl-CPAN-Meta-Requirements perl-Getopt-Long \ perl-JSON perl-Module-CoreList perl-Module-Metadata perl-parent perl-Path-Tiny perl-Try-Tiny \ perl-App-cpanminus perl-JSON-PP perl-Algorithm-Diff perl-Text-Diff \ perl-Spiffy perl-Test-Base perl-YAML perl-File-ShareDir-Install perl-Class-Inspector \ perl-File-ShareDir perl-File-ShareDir-Install perl-Config-General RUN cd /bin/ && curl -L https://cpanmin.us/ -o cpanm && chmod +x cpanm RUN cpanm Sparrow -q RUN echo ruby-app https://github.com/melezhik/ruby-app.git > /root/sparrow.list RUN sparrow plg install ruby-app RUN sparrow plg run ruby-app Теперь мы можем осуществить полный цикл сборки имиджа, "проиграв" все заново: $ docker build -t ruby_app > В итоге мы получим Docker имидж с требуемой системой. Заключение Применение системы многоцелевых сценариев Sparrow может быть эффективным средством построения Docker имиджей, т.к. позволяет строить сложные конфигурации, оставляя основной Dockerfile простым и лаконичным, а так же упрощая процесс разработки самих сценариев конфигурирования требуемой системы. Спасибо за внимание. Как обычно жду вопросов и конструктивной критики! :) Алексей

Метки:  

Невизуальные методы защиты сайта от спама. Часть 3. Повторы

Вторник, 24 Мая 2016 г. 10:26 + в цитатник
Продолжение статьи Невизуальные методы защиты сайта от спама Часть 3. Повторы подстрок Как уже говорилось, невизуальные методы защиты сайта от спама используют анализ текста. Один из часто встречающихся сигналов спама — это наличие повторяющихся строк. Как всегда, приведённые примеры взяты из реальных данных компании CleanTalk. Поиск таких повторов должен быть минимально ресурсоёмким. Лучше, если он будет вызываться после тестов из 1 и 2 частей статьи, которые отсеют явный спам и приведут текст к виду, пригодному для анализа. Здесь я приведу некоторую статистику, а также пример кода. 1. Пример кода Используемая нами функция определения самых длинных повторяющихся подстрок сделана по наивному алгоритму, описанному тут http://algolist.manual.ru/search/lrs/naive.php Пример вывода представлен ниже.        s  a  l  e     f  o  r     s  a  l  e     f  o  r     s  a  l  e        0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 s  0   +  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  .  .  . a  1   .  +  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  .  . l  2   .  .  +  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  . e  3   .  .  .  +  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +    4   .  .  .  .  +  .  .  .  +  .  .  .  .  +  .  .  .  +  .  .  .  . f  5   .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  . o  6   .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  .  .  .  .  .  . r  7   .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  .  .  .  .  .    8   .  .  .  .  .  .  .  .  +  .  .  .  .  +  .  .  .  +  .  .  .  . s  9   .  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  .  .  . a 10   .  .  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  .  . l 11   .  .  .  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +  . e 12   .  .  .  .  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  .  .  +   13   .  .  .  .  .  .  .  .  .  .  .  .  .  +  .  .  .  +  .  .  .  . f 14   .  .  .  .  .  .  .  .  .  .  .  .  .  .  +  .  .  .  .  .  .  . o 15   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  +  .  .  .  .  .  . r 16   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  +  .  .  .  .  .   17   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  +  .  .  .  . s 18   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  +  .  .  . a 19   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  +  .  . l 20   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  +  . e 21   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  + > > >         }; Плюсами на диагоналях отмечены найденные повторы. Видно, что число повторов равно числу отрезков диагоналей из смежных плюсов, параллельных главной и имеющих одинаковое смещение по вертикали. В реализации алгоритма собственно поиск повторяющихся символов занимает немного. Больше времени делается именно анализ диагоналей матрицы с выделением подстрок. Для этого был введен порог минимальной длины повтора. Также пришлось учесть повторы, начинающиеся с пробелов. Необходимо также было обеспечить, чтобы повторения не пересекались между собой. Поиск повторов делается от коротких к длинным. А вот и сама функция на Perl с минимальными изменениями. Для удобства приведён полный текст, выводящий матрицу выше. #!/usr/bin/perl -w use strict; use utf8; use Data::Dumper; binmode(STDOUT, ':utf8'); my $min_longest_repeat_length = 4; my $message = 'sale for sale for sale'; my %longest_repeates = (); get_longest_repeates(\$message, \%longest_repeates); print Dumper(\%longest_repeates); sub get_longest_repeates { my $test_ref = shift; # Ссылка на текст для анализа my $reps_ref = shift; # Ссылка на хэш результата my @symbols = split //, $$test_ref; my $m_len = scalar @symbols; my @matrix = (); # Квадратная матрица совпадений символов # Заполнение матрицы справа от главной диагонали for (my $i = 0; $i < $m_len; $i++) { # Строки $matrix[$i] = []; for (my $j = $i; $j < $m_len; $j++) { # Столбцы только справа от главной диагонали $matrix[$i][$j] = 1 if $symbols[$i] eq $symbols[$j]; } } # Анализ диагоналей матрицы справа от главной диагонали и заполнение результата my %repeats_tmp = (); # Хэш повторов my ($i, $j); # Перебор диагоналей справа налево, т.е. от коротких повторений к длинным for ($i = $m_len - 1; $i > 0; $i--) { my $repeat = ''; my $repeat_pos = undef; my $repeat_temp; for ($j = $i; $j < $m_len; $j++) { if (defined($matrix[$j-$i][$j]) && $matrix[$j-$i][$j] ') { $repeat =~ s/^ //; $repeat_pos = $j - length($repeat); if (length($repeat) '; } } } if ($repeat ne '') { $repeat =~ s/^ //; $repeat_pos = $j - length($repeat); if (length($repeat) '; } } foreach (keys %repeats_tmp){ $$reps_ref{$_} = 1 + scalar keys %{$repeats_tmp{$_}}; } # Вывод матрицы для диагностики print "\n"; print ' '; for (my $i = 0; $i < $m_len; $i++) { print ' ' . $symbols[$i]; } print "\n"; print ' '; for (my $i = 0; $i < $m_len; $i++) { printf '%3d', $i; } print "\n"; print "\n"; for (my $i = 0; $i < $m_len; $i++) { print $symbols[$i]; printf '%3d ', $i; for (my $j = 0; $j < $m_len; $j++) { my $value = '.'; $value = '+' if (defined $matrix[$i][$j] && $matrix[$i][$j] %1s', $value); } print "\n"; } print "\n"; } 2. Статистика повторов Нами был подобран порог минимальной длины повтора (его я не привожу специально), давший максимальную эффективность в тестах. Его результаты по числу повторов таковы: Число повторов В спаме, % В не спаме, % 2 78,58 90,28 3 11,93 4,86 4 4,45 2,08 5 2,30 1,39 6 1,93 0 7 0,22 0 8 0,37 0 9 0,07 0 3. Заключение Я показал реализацию наивного алгоритма поиска повторяющихся подстрок в тексте. Для анализа можно использовать как число повторов, так и сами повторы (например, по стоп-словам). Повторю, что в борьбе со спамом наиболее эффективны комплексные тесты.

Метки:  

[Перевод] Регулярные выражения для простых смертных

Вторник, 17 Мая 2016 г. 01:24 + в цитатник
Здравствуйте, уважаемые дамы и господа. Мы активно ищем свежую литературу на тему регулярных выражений для начинающих. Причем в данном случае нас бы скорее привлекла не переводная, а исходно русскоязычная книга, которая каким-то образом затрагивала бы и регулярные выражения при обработке естественного языка. Хотим предложить вашему вниманию следующий текст — во-первых, напомнить об этой теме, во-вторых, продемонстрировать примерный уровень сложности, который нас интересует Рано или поздно вам придется иметь дело с регулярными выражениями. Притом, какой у них сложный синтаксис, путаная документация и жесткая кривая обучения, большинство разработчиков удовлетворяются следующим: копипастят выражение со StackOverflow и надеются, что оно будет работать. Но что если бы в самом деле могли расшифровывать регулярные выражения и пользоваться ими на всю катушку? В этой статье я расскажу, почему следует еще раз присмотреться к регулярным выражениям, и как они могут пригодиться на практике. Зачем нужны регулярные выражения? Зачем вообще возиться с регулярными выражениями? Чем они могут помочь именно вам? Сравнение с шаблоном: Регулярные выражения отлично помогают определять, соответствует ли строка тому или иному формату – например, телефонному номеру, адресу электронной почты или номеру кредитной карты. Замена: При помощи регулярных выражений легко находить и заменять шаблоны в строке. Так, выражение text.replace(/\s+/g, " ") заменяет все пробелы в text, например, " \n\t ", одним пробелом. Извлечение: При помощи регулярных выражений легко извлекать из шаблона фрагменты информации. Например, name.matches(/^(Mr|Ms|Mrs|Dr)\.?\s/i)[1] извлекает из строки обращение к человеку, например, "Mr" из "Mr. Schropp". Портируемость: Почти в любом распространенном языке программирования есть своя библиотека регулярных выражений. Синтаксис в основном стандартизирован, поэтому вам не придется переучиваться регулярным выражениям при переходе на новый язык. Код: Когда пишете код, можно пользоваться регулярными выражениями для поиска информации в файлах; так, в Atom для этого предусмотрен find and replace, а в командной строке — ack. Четкость и лаконичность: Если вы с регулярными выражениями на «ты», то сможете выполнять весьма нетривиальные операции, написав минимальный объем кода. Как писать регулярные выражения Регулярные выражения проще всего изучить на примере. Допустим, вы пишете веб-страницу, на которой будет поле для ввода телефонного номера. Поскольку вы — ас веб-разработки, вам хочется дополнительно отображать на экране галочку, если телефонный номер валиден, и крестик X — если нет. <input src="check.svg"></label> <label src="x.svg"></label> > Теперь, если человек введет или вставит в поле валидный номер, то отобразится галочка. Если пользователь уберет курсор из поля ввода, а в поле при этом останется недопустимое значение, то отобразится крестик. Поскольку вы знаете, что телефонные номера состоят из десяти цифр, первым делом проверяете, чтобы isPhoneNumber выглядел так: function isPhoneNumber(string) { return /\d\d\d\d\d\d\d\d\d\d/.test(string); } В этой функции между символами / содержится регулярное выражение с десятью \d', то есть, символами-цифрами. Метод test возвращает true, если регулярное выражение соответствует строке, в противном случае – false. Если выполнить isPhoneNumber("5558675309"), метод вернет true! Ура! Однако, писать десять \d – слегка муторная работа. К счастью, то же самое можно сделать и при помощи фигурных скобок. function isPhoneNumber(string) { return /\d{10}/.test(string); } Иногда, вводя телефонный номер, человек начинает с ведущей 1. Правда было бы неплохо, если бы ваше регулярное выражение обрабатывало и такие случаи? Это можно сделать при помощи символа?. function isPhoneNumber(string) { return /1?\d{10}/.test(string); } Символ ? означает «ноль или единица», поэтому теперь isPhoneNumber возвращает true как для «5558675309», так и для «15558675309»! Пока isPhoneNumberвполне хороша, но мы упускаем одну ключевую деталь: регулярные выражения сплошь и рядом могут совпадать не со строкой, а с частью строки. Оказывается, isPhoneNumber("555555555555555555") возвращает true, поскольку в этой строке десять цифр. Проблему можно решить, воспользовавшись якорями ^ и $. function isPhoneNumber(string) { return /^1?\d{10}$/.test(string); } Грубо говоря, ^ соответствует началу строки, а $ — концу строки, поэтому теперь ваше регулярное выражение совпадет с целым телефонным номером. Серьезный пример Релиз страницы состоялся, она пользуется бешеным успехом, но есть существенная проблема. В США телефонный номер можно записать разными способами: (234) 567-8901 234-567-8901 234.567.8901 234/567-8901 234 567 8901 +1 (234) 567-8901 1-234-567-8901 Хотя пользователи и могут обойтись без пунктуации, им было бы гораздо проще вводить заранее отформатированный номер. Пусть вы и могли бы написать регулярное выражение для обработки всех этих форматов, думаю, что это плохая идея. Как бы тщательно вы ни старались учесть все форматы, все равно какой-нибудь пропустите. Кроме того, в действительности вам интересны только сами данные, а не их форматирование. Итак, чем возиться со всей этой пунктуацией, не проще ли избавиться от нее? function isPhoneNumber(string) { return /^1?\d{10}$/.test(string.replace(/\D/g, "")); } Функция replace заменяет пустой строкой символ \D, соответствующий любым символам кроме цифр. Глобальный флаг g приказывает функции заменить на регулярное выражение все совпадения, а не только первое. Еще более серьезный пример Ваша страница с телефонными номерами всем нравится, в офисе вы – король кулера. Однако, такие профессионалы как вы не останавливаются на достигнутом, поэтому вы хотите сделать страницу еще лучше. North American Numbering Plan – это стандарт по составлению телефонных номеров, используемый в США, Канаде и еще 23 странах. В этой системе есть несколько простых правил: Телефонный номер ((234) 567-8901) делится на три части: региональный код (234), код АТС (567) и номер абонента (8901). В региональном коде и коде АТС первая цифра может быть любой от 2 до 9, а вторая и третья цифры – от 0 до 9. В коде АТС 1 не может быть третьей цифрой, если вторая цифра – это 1. Ваше регулярное выражение уже соответствует первому правилу, но нарушает второе и третье. Пока давайте разберемся со вторым. Новое регулярное выражение должно выглядеть примерно так: /^1?<AREA CODE><EXCHANGE CODE><SUBSCRIBER NUMBER>$;/ Номер абонента прост, он состоит всего из четырех цифр /^1?<AREA CODE><EXCHANGE CODE>\d{4}$/ Региональный код немного сложнее. Нас интересует цифра от 2 до 9, за которой идут еще две цифры. Для этого можно использовать символьное множество! Символьное множество позволяет задать группу символов, из которых затем можно выбирать. /^1?[23456789]\d\d<EXCHANGE CODE>\d{4}$/ Отлично, но мы устанем вручную вводить все символы от 2 до 9. Сделаем код еще чище при помощи символьного диапазона. /^1?9\d\d<EXCHANGE CODE>\d{4}$/ Уже лучше! Поскольку региональный код такой же, как и код АТС, можно просто продублировать регулярное выражение, чтобы довести этот шаблон до ума. /^1?5\d\d2\d\d\d{4}$/ А как сделать, чтобы не приходилось копировать и вставлять ту часть выражения, в которой содержится региональный код? Все упростится, если использовать группу! Чтобы сгруппировать символы, их нужно просто заключить в круглые скобки. /^1?(6\d\d){2}\d{4}$/ Итак, 3\d\d содержится в группе, а {2} указывает, что эта группа должна фигурировать дважды. Вот и все! Рассмотрим окончательный вариант функции isPhoneNumber: function isPhoneNumber(string) { return /^1?(4\d\d){2}\d{4}$/.test(string.replace(/\D/g, "")); } Когда лучше обходиться без регулярных выражений Регулярные выражения – отличная штука, просто не следует решать с их помощью некоторые задачи. Не будьте слишком строги. Нет никакого смысла проявлять чрезмерную строгость, когда пишешь регулярные выражения. В случае с телефонными номерами, даже если мы учтем все правила из документа NANP, все равно невозможно определить, реален ли данный телефонный номер. Если я заделаю номер(555) 555-5555, то он совпадет с шаблоном, но ведь такого телефонного номера не существует. Не пишите HTML-парсер. Хотя регулярные выражения отлично подходят для парсинга каких-то простых вещей, синтаксический анализатор для целого языка из них не сделаешь. Если вы не любите заморачиваться, то вам вряд ли понравится разбирать нерегулярные языки при помощи регулярных выражений. Не используйте их с очень сложными строками. Полное регулярное выражение для работы с электронной почтой состоит из 6 318 символов. Простое и приблизительное выглядит так: /^[^@]+@[^@]+\.[^@\.]+$/. Общее правило таково: если у вас получается регулярное выражение длиннее одной строки кода, то, возможно, стоит поискать другое решение.

Метки:  

Финализирована программа коммьюнити-трека конференции DevCon 2016

Понедельник, 16 Мая 2016 г. 16:10 + в цитатник
Привет! Рады представить уже участникам и еще-не-участникам-но-планирующим финальную программу коммьюнити-трека. В этом году мы решили немного сменить траекторию, и дать голос сообществу. Траекторию сменили, и в коммьюнити-треке за два дня выступит 25 докладчиков. Это люди, занимающиеся совершенно разными проектами, из совершенно разных компаний, разных стран, но всех их объединяет то, что они будут говорить о реальном опыте и у участников конференции будет возможность поспрашивать тех, кто в полях познакомился с той или иной технологией или решением. Под катом — подробности, о чем будет идти речь в треке. Так как на DevCon будет трансляция, а потом и записи, весь этот уникальный контент будет доступен — не пропустите! Когда я формировал программу и общался с докладчиками, я старался минимально изменять то, в какой канве будет происходить повествование. Поэтому ожидайте кое-где хардкора, много Open Source и реального опыта :) Стараясь подобрать актуальные темы, у меня невольно получилось пересечение с основной программой в тематиках (что неизбежно, конечно), однако тюнинг презентаций позволил выровнять темы к рассказам о том, как были сделаны реальные проекты, подводные камни и др. В некоторых докладах как-то получилось так, что упоминания Microsoft практически и нет. Итак, в коммьюнити-треке вы услышите про несколько основных тем: Управление проектами: Алексей Лосев расскажет о том, как выстроить процесс разработки так, чтобы делать то, что нужно, Игорь Щегловитов из Лаборатории Касперского покажет, как анализировать ключевые счетчики производительности и не умереть в процессе, Андрей Акиньшин будет говорить про бенчмарк производительности, который он мейнтейнит и о котором недавно писал Хансельман в качестве great to use Микросервисы и контейнеры. Так как тема горячая, то и докладов прилично. Доклад про Continuous Delivery для микросервисных проектов сделает известный в сообществе Мартин Кулов, Евгений Агафонов из ABBYY расскажет про то, как все это дело использовать разработчику и что это для него будет значить, Владимир Туровцев из Logrocon, золотого партнера Microsoft и известных экспертов по ALM, за полчаса покажет, как за 72 часа построить Continuous integration в компании, Юрий Крутилин, DevExpress, сделает доклад про реальный опыт автоматизации тестирования мобильных устройств, Бернардин Катич покажет, как делать Scrum в больших проектах Интернет вещей. Богатая на доклады тема. Александр Сурков расскажет про .NET Microframework (давно же мы не видели этой темы!), Каталин Георгиу — про использование PowerBI для задач визуализации в IoT-проектах (по сути, это и не доклад будет, а серия демонстраций), Сергей Гребнов покажет супер-демо с AllJoyn, ботами, телевизором и облачными сервисами, Алексей Любко покажет, как построить действительно полезный IoT-проект — облачную пивоварню. Веб-разработка. Одна из самых сложных для меня тем — что можно рассказать людям, что было бы достаточно интересно и при этом не рассказано уже на много раз? Нашли. Денис Иванов из 2ГИС — про то, как строить простые и масштабируемые бэкенды Денис Цветцих, Трэнд Текнолоджис, со специфичным, но очень интересным докладом про то, как объять необъятное в мире MVVM-фреймворков Новак Иштван расскажет про последние (майской свежести!) изменения в Angular 2, показав самое вкусное, Адам Гранич покажет, как создавать веб-проекты, используя реактивное программирование, F# и WebSharper. Облако. Про облако мы уже рассказывали много и подробно. В этот раз сделали упор на реальные истории. Александр Лайша, Chief Development Engineer из EPAM, расскажет, как мигрировать проект на Azure Cloud Service в Azure Service Fabric, перекликаться, но не пересекаться с его докладом будет рассказ о построении глобального решения Connected Car на Service Fabric от Антона Троянова из BrightBox. Глеб Лесников из ДодоПиццы поделится тем, как делается информационная система за сетью пиццерий по всему миру, Алексей Коротаев, Odin, с интереснейшим докладом про обзор модели безопасности Azure Active Directory — на этом сейчас работает вся аутентификация в облаке! Марчин Борецки, MVP, про новый сервис Azure Functions, с помощью которого можно построить пайплайн действий со входами, выходами и выполнением промежуточных действий в облаке И еще несколько докладов, которые не вошли в вышеперечисленные темы, однако я счел преступным не рассказать о них: Дмитрий Костылев, Лаборатория Касперского, про то, как уничтожить производительность БД за 30 минут. Best practices от ведущего эксперта :) Мартин Крчек, маркетинговый директор из Madfinger Games (геймеры поймут), про то, как разрабатывать игры, которые принесут доход Петр Ляпин из ВейвПоинт, сделает вводную в то, как разрабатывать Office Add-Ins — кроссплатформенные, встраиваемые в офисные приложения модули, предлагающие различные функции для пользователя. Татьяна Кузнецова из DevExpress — про пользовательское взаимодействие в VR/AR, про предпосылки, причины и следствия :) DevCon 2016 DevCon — крупнейшая конференция Microsoft для разработчиков в России. Мы проводим ее шестой год и традиционно стараемся собрать неравнодушных к платформе Microsoft за чертой города, в комфортном загородном парк-отеле, чтобы вместе обсудить актуальные технологии и попробовать свежие версии продуктов на практике. В 2016 году DevCon предстанет в обновленном формате и мы с удовольствием делимся с вами секретами подготовки нашей конференции, а также основными анонсами: Секреты DevCon #1. Традиционный DevCon в новом формате Секреты DevCon #2. Как формируется сетка конференции Microsoft DevCon 2016 — представляем первую волну докладчиков Community-трека Анонс стартап-трека: возможен ли новый Яндекс, Parallels или Nginx сейчас в России? Запросто! Microsoft DevCon 2016 — компьютерное зрение, SQL Server 2016, Data Science и не только Мастер-класс по разработке на Xamarin: обзор технологии и погружение в разработку решений Анонс! Участникам DevCon 2016 будет доступен мастер-класс от Intel Анонс интенсива по ASP.NET Core в рамках конференции Microsoft DevCon 2016 В этом году у участников мероприятия будет больше возможностей для погружения в технологии и получения новых знаний. Мы приготовили большое количество новых интересных мастер классов, о которых подробнее расскажем в следующем анонсе. При этом DevCon — это по-прежнему больше, чем просто конференция, с насыщенной программой и общением с экспертами и коллегами вне программы. На сайте вы можете подробнее узнать, как стать участником. Напоминаем, что в этом году мы предлагаем упрощенное участие в DevCon 2016 с новой категорией билетов Guest Pass за 2500 рублей, в которые входит трансфер до места проведения, посещение всех докладов и мастер-классов первого дня конференции, и интерактивная выставка! Торопитесь успеть купить GUEST PASS на конференцию DevCon 2016. До встречи на конференции!

Метки:  

[Перевод] Intel System Studio for Microcontrollers 2015: подробности о разработке и отладке

Воскресенье, 15 Мая 2016 г. 17:57 + в цитатник
Мы уже рассказывали о том, как начать работу в Intel System Studio for Microcontrollers 2015 (ISSM) и создавать программы для Intel Quark D1000. Сегодня поговорим о том, как модифицировать в IDE Eclipse простую прошивку из примеров к ISSM. Так же рассмотрим работу с эталонной платой для проведения технических испытаний D1000 (Customer Reference Board, CRB). А именно, пользуясь JTAG-подключением, задействуем OpenOCD для того, чтобы прошить созданный нами образ в микроконтроллер и отладить код. Среда разработки для Intel Quark D1000 Intel System Studio for Microcontrollers включает в себя C/C++ компилятор, основанный на LLVM (в его состав входят ассемблер, компоновщик и библиотеки времени выполнения C/C++), GDB-отладчик и внутрисхемный отладчик OpenOCD. ISSM можно использовать как самостоятельный набор инструментальных средств, но в нём есть и плагины для интеграции с IDE Eclipse. Открываем проект прошивки в ISSM Прежде чем создавать проект для Intel Quark D1000, нужно установить необходимое программное обеспечение. А именно: IDE Eclipse для C/C++ разработчиков, ISSM, Putty и Zadig. Инсталлируя программы, старайтесь внимательно следовать руководствам, которые можно найти в директории установки ISSM, в папке «docs». Здесь мы так же предполагаем, что вы разобрались с примерами «Hello World» и «FW» для IDE Eclipse. Если это не так, пожалуйста обратитесь к разделу руководства пользователя «Using the Eclipse IDE». Его тоже можно найти в вышеупомянутой папке «docs». После того, как всё будет готово к работе, запустите Eclipse, воспользовавшись командным файлом «runEclipse.bat», указав в качестве аргумента ту папку, в которую установлена Eclipse. Затем откройте проект прошивки, в нашем случае это «FW-D1000», и выполните его сборку. Ошибок быть не должно. После того, как прошивку удалось успешно собрать, найдите файл «FW-D1000.elf», который находится в папке проекта «Binaries». Его содержимое будет таким же, как на рисунке ниже. Если вам не удаётся увидеть разделы образа с информацией о символах, нужно проверить, установлена ли на компьютере утилита «objdump». Если она действительно не установлена, обратитесь к разделу «Viewing GNU Elf and Map Files» руководства пользователя для того, чтобы установить «objdump» и настроить путь к ней на компьютере. Дамп объекта в файле FW-D1000.elf Передача данных из обработчика аппаратного прерывания После того, как стало ясно, что пример «FW-D1000» нормально компилируется, его можно изменить под собственные нужды. Здесь мы собираемся поменять строку, которую выводит в окно терминала программа «PushButton» из примера «FW-D1000». Перейдите в папку «Applicaition» проекта «FW-D1000». В ней имеется 10 приложений-примеров для Intel Quark D1000. Просмотрите файл «AppConfig.h» для того, чтобы выяснить, какое именно приложение будет интегрировано в проект, и, при необходимости, измените файл так, чтобы этим приложением было «PUSH_BUTTON_TEST». Вот как выглядит файл, в котором включена интеграция в готовый проект того, что нам нужно. //#define MAN_DECODING //#define POWER_MANAGEMENT_TEST #define PUSH_BUTTON_TEST //#define ADC2SPI_TEST //#define ADC2GPIO_TEST //#define DDS_TEST //#define OSCILLATOR_RE_TRIM //#define PWM_TESTING //#define MOTOR_CTRL //#define UART_WAKE Теперь перейдите в начальный файл приложения, «PushButton.c», который находится в папке «Applications», и слегка отредактируйте код. В результате, когда программа запустится устройстве, вы точно поймёте, что исполняется именно её изменённый вариант. Здесь мы подправили строку «rts_interrupt_msg». Эта строка будет выводиться каждую секунду по прерыванию часов реального времени (Real Time Clocl, RTC). //////////////////////////////////////////////////////////////////////////////// // это функция обратного вызова для прерывания часов реального времени //////////////////////////////////////////////////////////////////////////////// char rtc_interrupt_msg[] = "\r\nSean RTC interrupt!"; void rtc_callback_function_PB(void) { PUSH_UART(rtc_interrupt_msg,sizeof(rtc_interrupt_msg),0,0); rtc_callback(rtc_callback_function_PB); // повторно регистрируем функцию обратного вызова } Изменив файл, сохраните его. Теперь всё готов к компиляции и прошивке образа на устройство. Компиляция и прошивка образа на D1000 Для того, чтобы прошить скомпилированный образ на D1000, нужно установить JTAG-соединение с платой. В подробностях это описано в разделе руководства пользователя «Starting Debugging Session». Прежде чем открыть перспективу OpenOCD в Eclipse, проверьте, удалось ли OpenOCD успешно прочитать код «IdCode» целевого CPU, совпадает ли он с ожидаемым («Expected») кодом процессора. В этом примере мы подключились по JTAG к D1000 и установили OpenOCD-соединение до запуска Eclipse. Иногда Eclipse не может прочитать «IdCode» и показывает вместо кода нули. Если это произошло, нажмите кнопку перезагрузки и посмотрите, удалось ли OpenOCD верно определить «IdCode». После того, как всё определилось, и вы дождались появления сообщений, вроде тех, что приведены на рисунке ниже, можно прошивать изменённый образ на D1000. Консоль OpenOCD при подключении к эталонной плате D1000 После того, как удалось установить JTAG-соединение с платой D1000, соберите проект «FW-D1000» в IDE Eclipse. Если в ходе сборки ошибок не обнаружится, в папке «Binaries» появится файл образа «FW-D1000.elf». Его можно будет прошить на устройство, воспользовавшись отладочной перспективой «Debug» в Eclipse, которая настроена на использование GDB через OpenOCD. Настройка отладчика для работы с эталонной платой D1000 с использованием OpenOCD После прошивки образа появится сообщение об успешном завершении операции в консоли OpenOCD (взгляните на рисунок с консолью выше). В данном примере нужно, чтобы отладчик остановил процесс в функции «main» для пошагового исполнения. На следующем рисунке показано, как задать точку останова на входе в «main». Отладчик, после завершения прошивки и загрузки образа, остановит процессор в начале функции и будет готов к пошаговому исполнению программы. Задаём точку останова в функции «main» Теперь откроем консоль последовательного порта с помощью Putty. Нужно это для того, чтобы видеть UART-сообщения, которые будут выводиться, когда программа отправляет заданное сообщение по аппаратному событию прерывания часов реального времени (RTC) или при нажатии на кнопку (ButtonPress). При подключении к плате D1000 в нашем распоряжении будут два USB-устройства. А именно, одно – это Dual RS232 HS, которое используется для JTAG-соединения OpenOCD, а второе – это USB-интерфейс к последовательному порту. Перед запуском приложения «PushButton» нужно открыть подключение к последовательному порту, используя клиент Putty со следующими настройками: Baudrate-19200, Flow Control-XON/XOFF. Отладка: пошаговое исполнение кода Когда завершится прошивка образа, начнётся отладка кода, с самого начала функции «main», как показано на рисунке ниже. В этом примере программа «PushButton» запускается, а затем отладчик ожидает вызова функции «PushButton», главной функции приложения. Тут же можно просматривать код, написанный на языке высокого уровня, а так же – машинные команды в окне «Disassembly», в котором подсвечивается инструкция текущего указателя команд. Теперь можно приступать к отладке, выполнять шаги с обходом процедур (step over), шаги с заходом в процедуры (step into), возобновлять (resume) исполнение программы. Отладчик остановил процессор в начале функции «main» Здесь мы выполняем шаг с заходом в процедуру, затем видим исходный код входной функции «PushButton», отладчик открывает «PushButton.c» для того, чтобы указать на следующую исполняемую функцию. Шаг с заходом в процедуру, выполненный из «main» Запуск примера на D1000 В итоге, мы можем возобновить исполнение программы, она будет работать в обычном режиме. Если теперь взглянуть на окно терминала Putty, можно увидеть журнал сообщений от D1000. Сообщения, содержащие именно ту строку, которую мы выше модифицировали в коде примера, выводятся по прерываниям часов реального времени. Тестовый вывод программы, выполняемой на D1000 Об аппаратном обеспечении Эталонная плата для проведения технических испытаний (CRB V2) содержит следующие компоненты: Микроконтроллер Intel Quark D1000. Акселерометр. Флэш-память SPI. Адаптер Bluetooth LE. Модуль последовательного порта для WiFi. Конвертер последовательного порта для USB и JTAG. Модуль электропитания. Цепь зарядки батареи. Микроконтроллер Intel Quark D1000 У контроллера имеется 24 вывода GPIO, многие из которых многофункциональны (подробности о них смотрите в таблице). CRB V2 обеспечивает подключение этих выводов к контактным площадкам монтажной платы, которая очень напоминает Arduino, но не полностью совместима с этим стандартом. Стоит отметить, что несколько выводов, кроме того, подключены к периферийным устройствам, размещённым на плате. В некоторых случаях их нельзя использовать в роли многофункциональных выводов. Они отмечены в таблице и в описании аппаратных компонентов платы, которое приведено ниже. А именно, при описании выводов приведены их названия для микроконтроллера D1000, для Arduino и для платы CRB V2. Обратите внимание на то, что интерфейс SPI применяется для связи со всеми встроенными в плату периферийными устройствами с использованием следующих контактов: MST_M2SC (выход сигнала синхронизации передачи данных SPI, Arduino — D13, CRB v2 – XPB5). MST_M2SD (выход последовательной передачи данных (MOSI) SPI, Arduino – D11, CRB v2 – XPB3). MST_S2MD (вход последовательного приёма данных (MISO) SPI, Arduino – D12, CRB v2 – XPB4). Подключение выводов Intel Quark D1000 к CRB v2 Плата CRB V2, кроме того, включает в себя некоторые другие компоненты, поведением которых нельзя управлять с помощью микроконтроллера D1000. FTDI FT2232H – микросхема конвертера последовательного порта для USB и JTAG. Она используется для обеспечения консольного (UART) подключения к D1000, для программирования и отладки с использованием интерфейса JTAG. Светодиоды D6 (жёлтый) и D7 (зелёный) подключены к FTDI FT2232H, они мигают, когда устройство принимает или отправляет данные. Контроллеры Linear Technologies LTC4414, Texas Instruments BQ24080, Maxim Integrated MAX8869 применяются для организации электропитания и зарядки батареи. Светодиоды D10 и D11 подключены к BQ24080 и служат для индикации состояния заряда батареи. Схема платы Intel Quark D1000 CRB v2 Выводы Теперь вы знаете, как работать с прошивками для Intel Quark D1000 в IDE Eclipse. Вы умеете их редактировать, записывать на устройство, тестировать и отлаживать код. Так же мы рассказали об эталонной плате для проведения технических испытаний (CRB V2), которая, помимо Quark D1000, включает в себя набор дополнительных компонентов. Здесь и здесь вы можете найти подробности об Intel Quark D1000, а вот тут – об ISSM.

Метки:  

?????? ?? ?????????? ???????????? ????

Воскресенье, 15 Мая 2016 г. 16:38 + в цитатник
??????????? ?????? ?? ?????????? ???????????? ???? ? ????? ???/??????-????????????? ?????????.
?????? ?? ?????????? ???????????? ????

?????? ?? ?????????? ???????????? ????

Воскресенье, 08 Мая 2016 г. 10:52 + в цитатник
??????????? ?????? ?? ?????????? ???????????? ???? ? ????? ???/??????-????????????? ?????????.

?????? ?? ?????????? ???????????? ????

Воскресенье, 08 Мая 2016 г. 09:21 + в цитатник
??????????? ?????? ?? ?????????? ???????????? ???? ? ????? ???/??????-????????????? ?????????.
?????? ?? ?????????? ???????????? ????

?????? ?? ?????????? ???????????? ????

Пятница, 06 Мая 2016 г. 20:47 + в цитатник
??????????? ?????? ?? ?????????? ???????????? ???? ? ????? ???/??????-????????????? ?????????.

?????? ?? ?????????? ???????????? ????

Четверг, 05 Мая 2016 г. 20:04 + в цитатник
??????????? ?????? ?? ?????????? ???????????? ???? ? ????? ???/??????-????????????? ?????????.
?????? ?? ?????????? ???????????? ????

?????? ?? ?????????? ???????????? ????

Четверг, 05 Мая 2016 г. 16:28 + в цитатник
??????????? ?????? ?? ?????????? ???????????? ???? ? ????? ???/??????-????????????? ?????????.


Поиск сообщений в comdersrek
Страницы: 2 [1] Календарь