Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1503 сообщений
Cообщения с меткой

автоматизация - Самое интересное в блогах

Следующие 30  »
kiev2376393

Домашняя автоматизация с ioBroker

Пятница, 29 Июля 2016 г. 19:19 (ссылка)

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

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Автоматизация лабораторных измерений

Вторник, 26 Июля 2016 г. 14:58 (ссылка)

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







Постановка задачи



Разработать программное обеспечение для управления подготовкой и проведением эксперимента на автоматизированном оптическом эллипсометре.



Программное обеспечение должно предоставлять возможность



  • задания начальных установок и параметров эксперимента;




  • проведения измерений оптических характеристик образцов;




  • набор первичных данных [массивы данных I(

https://habrahabr.ru/post/306434/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Автоматизация работы с серверами при помощи Hewlett Packard Enterprise Server Automation

Вторник, 26 Июля 2016 г. 14:27 (ссылка)

Современные предприятия в своей работе используют все больше серверов. Из-за этого существенно увеличивается количество рутинных задач, необходимых для их выполнения инструментов, стандартов, которые необходимо соблюдать в работе системы. Это, в свою очередь, увеличивает расходы на обслуживание, а также потери из-за разнообразных сбоев. Как решение большинства проблем можна использовать средства автоматизации. Одно из них — Hewlett Packard Enterprise (HPE) Server Automation. Это программное обеспечение для предназначенное для централизации управления и постановки на поток множества функций дата-центров, а также автоматизации критически важных мест в управлении ИТ-инфраструктурой.











Знакомство с сервером



HPE Server Automation сканирует сеть на предмет наличия серверов, которые не находятся под управлением программы и отображает их в специальном списке. Затем администратор подключает эти сервера к системе установив на каждом из них программные модули. После того, как это сделано, вы можете выполнять задачи управления на них, в том числе следующие:



Развертывание операционной системы на выделенных ресурсах: позволяет выделять физическое пространство на сервере или создавать виртуальные сервера под предварительно настроенные ОС и вводить их в управляемый пул серверов. После этого HPE Server Automation может управлять вновь созданными ресурсами.



Автоматический апгрейд ОС: HPE Server Automation умеет проводить автоматизированное, централизованное и гибкое обновление операционных систем и устанавливать необходимые патчи. Это касается серверов на базе ОС семейства Windows, Linux и Solaris. Вы можете выбирать необходимые патчи из тех, что предлагаются поставщиком операционной системы, а также настроить процесс установки, чтобы не учитывать патчи, которые несовместимы с серверной средой.



Инициализация программного обеспечения: после того, как сервер вошел в управляемый пул вы можете устанавливать и настраивать приложения с помощью специальных шаблонов, более известных как политика программного обеспечения (Software Policies). Эти шаблоны определяют, какое ПО устанавливать, какие конфигурации при этому будут применяться, а также скрипты, которые будут использоваться во время установки. Эти шаблоны позволяют определить базовую конфигурацию серверов, которая будет развернута на всех управляемых единицах в соответствии с функциями по соблюдению правил HPE Server Automation Software. Например, вы сможете установить базовую версию Apache как на всех серверах, которые находятся под управлением HPE Server Automation, так и на заданной их части.



Аудит и соответствие стандартам: функция Audit and Remediation дает возможность узнать политику конфигурации серверов и убедиться, что они ей соответствуют. В случае, если обнаруживаются несоответствия требованиям или же сервера не настроены так, как вы хотите, это можно исправить программными средствами. Так, вы можете настроить базовый сервер и на основании его образа автоматически сконфигурировать все остальные, приведя их в соответствие с заданной вами политикой.



Конфигурация ПО: вы можете создавать шаблоны конфигурации приложений и разворачивать их на всех серверах под управлением HPE Server Automation. Также вы можете проверять стандартизацию конфигурационных файлов на всех серверах в пуле.



Развертывание приложений: с помощью этой функции вы можете быстро и легко перемещать создаваемый комплекс приложений от команды разработчиков к тестировщикам и далее по цепочке.



Проверка соответствия ПО: при помощи инструмента Policy Compliance Scan можно определить, соответствуют ли спецификация политики программного обеспечения управляемого сервера конфигурации установленного на нем программного обеспечения.



Получение отчетности: HPE Server Automation предоставляет обширный набор комплексных отчетов о состоянии управляемых серверов. Эти отчеты можно гибко настраивать, что позволяет предоставлять их различным категориям пользователей.



HPE Server Automation позволяет вносить изменения в работу различных систем более безопасно и гибко. Это происходит благодаря тому, что вы можете моделировать и проверять вносимые изменения прежде, чем действительно осуществите их. Благодаря этому существенно сокращается время простоя серверов, так как вносимые впервые изменения уже проверены на работоспособность. Вам не нужно отлаживать их и и исправлять ошибки непосредственно после внесения изменений или установки обновлений.



Конфигурация HPE Server Automation



Простой установочный пакет HPE Server Automation состоит из ядра системы, его компонентов, а также базы данных Oracle, размещенных на одном сервере. Более продвинутые пакеты могут иметь дополнительные элементы:



— вторичные ядра, которые дополняют основное ядро и увеличивают мощность для управления серверами;



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



— соединение Multi-master, которое позволяет двум независимым системам обмениваться данными и осуществлять совместное управление серверами.



HPE Server Automation поддерживает установку в восьми обозначенных конфигурациях. Для других конфигураций требуется пакет HPE Professional Services.



Простая конфигурация



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







Самый простой случай установки — развертывание системы для одного дата-центра или объекта. Он состоит из всех компонентов автоматизации HPE Server Automation установленный на одном хосте управления серверами в одной сети.



База данных Oracle



Все варианты развертывания системы требуют наличия базы данных Oracle, настроенной специально для HPE Server Automation. Один из ее компонентов используется для хранения информации о вашей сети, устройствах хранения данных, управляемых серверах (вместе с операционными системами и приложениями, установленными на них) и так далее. Эта база данных является компонентом установочного пакета, однако вы можете использовать и существующую базу данных Oracle, которая была сконфигурирована для использования с HPE Server Automation.



Развертывание приложений



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



— моделировать такие компоненты приложений, как код, скрипты, конфигурационные файлы;



— управлять несколькими параллельными выпусками и версиями ваших приложений;



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



— моделировать целевые сервера, работающие под управлением элементов необходимых для приложений;



— наладить удобное и быстрое общение между разработчиками, тестировщиками, системными администраторами и другим уполномоченным персоналом;



— планировать и реализовывать циклы разработки приложений начиная от написания кода и заканчивая релизом продукта. Вы можете настроить Hewlett Packard Enterprise Server Automation в зависимости от типа вашего предприятия, принятых на нем стандартов и способов работы.



Аудит и исправление



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



Также возможности HPE Server Automation позволяют понять, как сделать сервера в управляемой среде совместимыми. Так, вы можете активировать опцию соответствия серверов стандартам определенной политики. Когда система обнаружит сервера, которые заданным стандартам не соответствуют, вы можете исправить их работу таким образом, чтобы она соответствовала принятым стандартам.



Используя клиент HPE Server Automation вы можете проверять значения параметров конфигурации серверов на основании работающего сервера с правильными параметрами или же образа подобного сервера. Также вы можете делать проверку опираясь на заданные собственноручно настройки или на основе предварительно настроенных политик аудита. Кроме этого есть возможность получать отчеты о состоянии конкретных серверов для проверки текущего состояния системы и для сравнения с другими серверами.



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



Используя аудит средства исправления и восстановления, вы также можете выполнить следующие задачи:



— сравнивать сервера и снимки системы с заданными серверами и снимками;

— создавать проверки, которые будут исполняться регулярно;

— создавать политики проверки, которые устанавливают стандарты совместимости и безопасности для вашей организации;

— создавать специфические проверки для конкретных серверов или серверных групп.

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



Возможности Hewlett Packard Enterprise Server Automation



Рассматриваемый продукт представляет набор возможностей, которые позволяют автоматизировать многие ИТ-процессы. Среди них такие инструменты как Service Automation Visualizer, Storage Visibility and Automation, а также система отчетов.



Service Automation Visualizer (SAV)



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



Storage Visibility and Automation



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



Reports



Система отчетов HPE Server Automation в режиме реального времени обеспечивает пользователя разнообразной информацией касательно управляемых серверов, сетевых устройств, программного обеспечения, патчей, операционных систем, клиентов и объектов (виртуальных и физических) и применении разнообразных политик. Также можно получить отчеты по безопасности и о действиях пользователей.



Система развертывания ресурсов



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



— Интеграцию с другими функциями и инструментами HPE Server Automation. Так как система развертывания ресурсов тесно интегрирована с набором инструментов автоматизации (включая автоматическое управление патчами, управление программным обеспечением, выполнение скриптов и т. д.), это обеспечивает гладкую передачу работы между различными отделами. Это гарантирует, что различные группы ИТ-отделов будут работать с пониманием протекающих процессов, общего состояния рабочей среды. Это является одним из залогов продуктивной работы и надежный контроль за внедрением изменений.



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



— Гибкую архитектуру предназначенную для работы во многих средах. Система развертывания HPE Server Automation поддерживает множество различных типов серверов, сетей, архитектур безопасности и операционных процессов. Такая гибкость гарантирует, что вы сможете развернуть необходимые операционные системы в соответствии с потребностями вашей организации.



Вы можете выполнять функции HPE Server Automation как из обычного, так и из веб-клиента. Система автоматизирует все типичные задачи развертывания, а именно:



— Подготовка оборудования для установки операционной системы с использованием подготовленного профиля установки ОС и использования заданных последовательностей;



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



— Установка базовой и дефолтной конфигурации операционной системы в соответствии с заданной последовательностью или планом построения.

— Установка всех последних патчей для операционных систем (список зависит от приложений, работающих на сервере);



— Выполнение определенных скриптов до и после установки ОС, которые задают определенные параметры конфигурации, например пароль root;



— Установка системных компонентов и утилит, таких как например Secure Shell, PC Anywhere, антивирусное ПО и программы для резервного копирования данных, средства мониторинга системы;



— Установка распространенного системного ПО, как, например, Java Virtual Machine.



Система развертывания HPE Server Automation поддерживает:



— Windows, Solaris и Linux;

— сетевую установку и установку с физических носителей (CD/DVD);

— а также позволяет распределять обязанности между сотрудниками центра обработки данных и системных администраторов.



Система также интегрируется с родными технологиями установки применяемых в разных операционных системах:



— Windows answer files: unattend.txt, unattend.xml, sysprep.inf

— Red Hat Kickstart

— SuSE YaST (Yet another Setup Tool)

— Solaris Jumpstart

— WINPE/WIN-BCOM/UNDI



Вы можете развернуть операционную систему на:



— физических серверах, на которых не установлен агент HPE Server Automation и нет операционной системы;

— виртуальных серверах;

— серверах, входящих в пул не управляющихся HPE Server Automation серверов и имеющих установленные ОС;

— серверах, входящих в пул управляющихся HPE Server Automation серверов и имеющих установленные ОС (переразвертывание).



Выполнение скриптов



Использование функции выполнения скриптов HPE Server Automation позволяет запускать одноразовые или сохраненные сценарии по всему пулу управляемых серверов в автоматическом режиме, а не вручную. Для системных администраторов это дает такие преимущества:



— параллельное выполнение скриптов на многих UNIX и/или Windows-серверах, что существенно экономит время и обеспечивает высокую степень согласованности;



— управление доступом осуществляется по принципу, когда только авторизованные администраторы могут выполнять сценарии на хостах, к которым они имеют доступ;



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



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



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



Поскольку средства выполнения скриптов являются неотъемлемой частью HPE Server Automation, системные администраторы получают уникальные преимущества по сравнению со сторонними инструментами:



— Используя информацию о состоянии системы и ее конфигурации для настройки скриптов также можно адаптировать скрипты под конкретные задачи узнав дополнительную информацию благодаря простой ссылке в HPE Server Automation. Это могут быть данные о пользователе или предприятии, которое владеет сервером, является ли сервер простым хранилищем или используется для вычислений, на каком объекте он находится и т. д.



— Пользователи могут совместно использовать скрипты без угрозы для безопасности, так как HPE Server Automation следит за тем, кто и на каких серверах может запускать выполнение скриптов, а также ведет комплексный аудит выполнения скриптов.



Информация об устройствах



Входящий в состав HPE Server Automation инструмент Device Explorer позволяет просматривать информацию о серверах в управляемой среде. С помощью этого обозревателя можно выполнять следующие задачи:



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



— просматривать файловую систему серверов, реестр, оборудование, программное обеспечение, список патчей и сервисов;



— узнавать информацию о свойствах сервера и его истории;



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



— проводить аудит системной информации, делать снимки состояние серверов и настроек приложений;



— просматривать и получать доступ к группам членов — серверам и другим группам;



— просматривать краткое описание группы и ее историю.



Управление виртуализацией



HPE сотрудничает с поставщиками облачных услуг и средств виртуализации. HPE поддерживает работу с VMware vCenter Server и Microsoft System Center Virtual Machine Manager (SCVMM). Также HPE имеет ограниченную интеграцию с облачным сервисом OpenStack, работающим по схеме Инфраструктура как сервис (IaaS).



Управление виртуализацией HPE Server Automation дает:



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

— простое создание виртуальных машин;

— соблюдение всех нормативных и корпоративных политик;

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







Обнаружение серверов без агента и проведение его установки



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



С ее помощью вы можете выполнить следующие задачи:



— просканировать сеть на наличие безагентных серверов;

— выбрать сервера для установки агента HPE SA;

— задать инструмент для связи и установить комбинацию логин/пароль;

— выбрать параметры установки и развертывания агентов.



Дополнительные информационные материалы вы можете найти на официальном сайте, а также YouTube-канале.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306426/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как настроить расширяемую систему для регрессионного тестирования на телефонах: опыт мобильной Почты Mail.Ru

Пятница, 22 Июля 2016 г. 15:07 (ссылка)





Привет, Хабр! Сегодня я хочу рассказать, как мы построили с нуля гибкую и расширяемую систему для выполнения автотестов на Android-смартфонах. Сейчас у нас используется около 60 устройств для регрессионного тестирования мобильного приложения Почты Mail.Ru. В среднем они тестируют около 20 сборок приложения ежедневно. Для каждой сборки выполняется около 600 UI-тестов и более 3500 unit-тестов.



Автотесты доступны круглосуточно — они экономят очень много времени тестировщиков и позволяют нам выпускать качественное приложение. Без них мы бы тестировали каждую сборку 36 часов (с учетом ожидания) или примерно 13 часов без ожидания. Вместе со сборкой, актуализацией переводов, при рабочей загрузке агентов с автотестами тестирование в среднем занимает 1.5 часа, что ежедневно позволяет нам экономить недели работы тестировщиков.



Мы рассмотрим, как всё делать с самого начала тем, кто занимается написанием автотестов, а не инфраструктурой: начиная от покупки телефона, его перепрошивки и заканчивая созданием docker-контейнеров, внутри которых будет доступен телефон для автотестов.



Какие телефоны выбрать для автотестов на Андроиде?





Когда Android только-только становился популярным, у разработчиков тестов был выбор из двух зол: покупать дорогой зоопарк телефонов либо работать с медленными и глючными виртуалками. Сегодня всё несколько проще, на рынке появились дешёвые аппараты «эконом»-класса, а виртуальный Андроид обзавёлся образом для x86 и HAXM. Однако выбор всё ещё остался, многие предпочитают для автотестов виртуальные машины, но телефоны уже стали вполне доступной опцией даже для скромного бюджета на автотестирование. Так как же выбрать телефон для регрессионных автотестов и какое оборудование ещё нужно, чтобы всё вместе оно могло работать 24/7?



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




  1. Есть возможность получить права root.

  2. Есть возможность анлока boot-раздела телефона.

  3. На телефоне стоит версия Андроида, максимально близкая к стоковой, или подобные можно установить (чтобы не пришлось лопатить кучу вариантов теста под разные интерфейсы).

  4. Оперативная память на телефоне желательно должна быть размером от 1 Гб (можно работать и на меньшей, но, даже если тесты написаны стабильно, различные проверки отображения «тяжёлых» объектов на телефоне с низкой оперативной памятью окажутся долгими).

  5. Совсем здорово, если у телефона будет долгий саппорт от производителя/пользователей, тогда у нас остаётся шанс продлить ему жизнь новыми версиями ОС.



Основная часть критериев достаточно прозрачна. Если окажется, что на телефоне что-то работает не так, то мы должны хотя бы иметь шанс заставить это работать сами. :) К сожалению, большая часть критериев — это не те вещи, о которых можно спросить продавца при покупке, поэтому в первую очередь наш путь лежит на forum.xda-developers.com и 4pda.ru/forum, где о рыночной модели можно узнать все подробности. Плюс ко всем перечисленным критериям, если модель уже долго продаётся, обращайте на форумах внимание на отзывы о браке и времени ресурса памяти и батареек, без них ваше устройство превратится в тыкву. Проблемы экрана, кнопок, корпуса, динамиков и прочего, что обычно интересует пользователя, вас, как правило, пугать не должны: телефон прекрасно будет работать с браком этих элементов, хотя всё зависит от специфики проекта.



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



1. Модель телефона имеет кучу региональных подвидов, при этом только на части из них можно получить рут или разлочить бутлоадер. Мало того что наткнуться на российский сертифицированный телефон в неофициальном магазине сложно — серые и белые телефоны выглядят одинаково, — так ещё и многие продавцы или их поставщики перепрописывают названия моделей, характеристики железа, регионы и даже версии операционных систем. Вполне возможен случай, когда внутри «Настроек» в Андроиде вы видите одну модель, внутри бутлоадера другую, а в шелле, когда набираете getprop и получаете айдишники, — третью. Просто телефон прошёл пару рук и пару регионов до вас. Сначала его хозяином был пользователь Веризона из Южной Дакоты, потом тот сдал его, в refurbished-состоянии аппарат как-то попал торговцу в Тель-Авиве, который его криво перепрошил на их версию операционной системы, а через ещё какое-то время телефон перекупил продавец в Москве, который уже стал продавать его как новый. Вам привозит его курьер, вы берёте в руки своё новое восьмиядерное перепрошиваемое российское устройство, не подозревая, что это шестиядерный залоченный региональный эксклюзив для контрактных пользователей оператора сотовой связи из США.





Элементы коробки и телефона с «современной» начинкой и высокой ценой, который по внутренним характеристикам оказался перепрошитой младшей моделью от AT&T



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





Типичные значения серийников у бюджетных телефонов



3. Псевдослучайный MAC-адрес у Wi-Fi-модуля после перезагрузки телефона. Это была довольно серьёзная проблема, потому что мы узнали о ней, когда я убедился, что «всё хорошо», телефон нам подходит, и мы заказали 20 штук точно таких же. :) В процессе работы автотестов телефоны иногда перезагружаются, через какое-то время тесты начали падать из-за отсутствия доступа к сети по Wi-Fi, хотя всё при этом выглядело нормально: соединение с сетью было и после включения/выключения Wi-Fi-модуля всё работало корректно. Просто после ребутов в какой-то момент у пары телефонов оказывался одинаковый MAC, Wi-Fi-точка доступа же пускала только последний присоединившийся. На тех телефонах, где в итоге генерился MAC-адрес, я, к сожалению, не нашёл, пришлось в загрузочном разделе поместить скрипт, который устанавливал его насильно на уникальный.





Телефон демонстрирует чудеса spoofing’а из коробки



Тем не менее, если соблюдать при выборе телефона перечисленные выше критерии, эти проблемы не должны быть фатальными — всё это можно исправить руками и заставить телефон работать как нужно.



Кроме телефонов, для запуска автотестов понадобится сам компьютер и USB-хабы, тут тоже есть несколько нюансов. Постоянно работающим телефонам нужно хорошее питание (минимум 0,5 А на устройство, лучше больше), многие хабы на рынке идут со слабыми адаптерами и никак не рассчитаны на то, что в каждый порт будет подключён постоянно работающий телефон. С планшетами ещё сложнее, девятидюймовые планшеты при постоянной работе разряжаются, экран слишком большой, приходится выбирать из семидюймовых. Из практики у нас вышло, что на адаптер в 4 А можно подключить 6–7 телефонов (в зависимости от их загрузки работой), т. е. большая часть многопортовых хабов с характеристиками типа «адаптер на 3 А, 20 USB-портов», мягко говоря, бесполезны. Самые крутые — серверные решения, но цена у них зашкаливает, так что ограничимся пользовательским рынком. Чтобы телефоны не разряжались, стоит брать хабы на четыре порта с питанием в 3 А, либо хабы на шесть портов с питанием на 4 А. Если есть хабы с хорошим питанием, но с большим количеством портов, — часть портов можно просто не использовать.



Готовим телефон к работе



Давайте для примера возьмём одну модель телефона, решим одну из проблем его операционной системы, а дальше попробуем собрать эти устройства в примитивный тестовый стенд для автотестов. Телефон сам по себе дешёвый и хороший, но с некоторыми недостатками (описанными выше). В частности, у этих телефонов одинаковый iSerial, adb видит только одно устройство. :( Совсем везде на телефоне его менять не будем, но сделаем так, чтобы adb отдельные телефоны отличал.



Для этого нам нужно будет перепрошить у телефона boot-раздел и установить на устройстве кастомный раздел восстановления — так вы сможете уберечься от неудачных экспериментов. У наших телефонов стоит МТ6580, т. е. процессор фирмы Mediatek, значит, для перепрошивки можно использовать SP Flash Tool. Ещё нужны готовый образ recovery.img и scatter-файл устройства. Почти для всех устройств их можно найти в интернете, на тех же самых ресурсах XDA и 4PDA, но при желании recovery можно перекомпилировать для своего устройства, взяв за основу TWRP, а scatter-файл создать самому. В любом случае берём наши готовые файлы и перепрошиваем:







После установки раздела восстановления сохраните через него бэкап boot-раздела и переместите его к себе на машину, обычно в этом разделе располагаются конфигурационные файлы ОС. Чтобы захардкодить свой iSerial, нужно распаковать образ загрузочного раздела телефона, это можно сделать с помощью Android Image Kitchen. Запускаем unpackimg.sh и получаем распакованный образ в папке ramdisk:







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







Находим файл, где устанавливается серийный номер ${ro.serialno}, и заменяем его на свой номер, например 999222333019:



find ramdisk/ -maxdepth 1 -name "init.mt*" -exec sed -i 's/${ro.serialno}/999222333019/g' {} +


Запаковываем образ обратно с помощью repackimg.sh, перекидываем его на телефон и устанавливаем с помощью кастомного рекавери. Теперь adb будет отличать устройства, нам остаётся включить режим разработчика на телефоне и разрешить debug в меню разработчика. Любые подобные проблемы можно решать точно таким же путём, практически всё в телефоне можно перепрошить или поправить, если этого потребуют задачи тестирования.



Настройка тестовой машины



В качестве хоста нашего стенда будем использовать обычный десктоп с установленной на него Ubuntu. Телефоны затем можно будет разделить на отдельные виртуальные машины, использовать все вместе или, как это делаю я, разделить их в отдельные docker-контейнеры.



При заказе/сборке машины, к которой будут подключены телефоны, есть специфика. Кроме стандартных HDD/RAM/CPU, нужно обратить внимание на количество USB-контроллеров на материнской плате и поддерживаемый протокол USB. Телефоны, работающие на USB 3.0 (xHCI), могут существенно ограничить максимальное количество устройств на машине (обычно 8 на контроллер, в итоге 16 устройств на машину с двумя контроллерами), поэтому стоит проверить, есть ли возможность его отключить и использовать только EHCI. Такие опции есть в биосе или ОС, лучше всего насильно отключить xHCI в биосе, если вам не нужны высокоскоростные устройства.



Создаём контейнер для телефона



Если нужно, чтобы слейв / агент системы интеграции работал с отдельным телефоном, то их следует как-то разделить. У нас агенты запускаются в отдельных docker-контейнерах, каждому из которых доступно по одному устройству, — так мы можем распределять задачи в CI на отдельные устройства, а точнее на их возможности (например, контейнер с планшетом может выполнять тесты, для которых требуется широкая диагональ экрана, а контейнер с телефоном — тесты, для которых нужна возможность принимать SMS-сообщения). Пример установки и настройки системы на Ubuntu описан далее. Устанавливаем сам Docker:



sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
echo 'deb https://apt.dockerproject.org/repo <версия ubuntu> main' >> /etc/apt/sources.list.d/docker.list
sudo apt-get update
sudo apt-get install docker-engine


В качестве сторадж-драйвера будем использовать overlayFS (работает быстрее дефолтного):



echo 'DOCKER_OPTS="-s overlay"' >> /etc/default/docker


Создаем dockerfile, из которого будем делать образы. Добавим в него Android SDK:



FROM ubuntu:trusty
ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update -y && \
apt-get install -y software-properties-common && \
add-apt-repository ppa:webupd8team/java -y && \
apt-get update -y && \
echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections && \
apt-get install -y oracle-java8-installer && \
apt-get remove software-properties-common -y && \
apt-get autoremove -y && \
apt-get clean
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
ENV ANT_VERSION 1.9.4

RUN cd && \
wget -q http://archive.apache.org/dist/ant/binaries/apache-ant-${ANT_VERSION}-bin.tar.gz && \ tar -xzf apache-ant-${ANT_VERSION}-bin.tar.gz && \ mv apache-ant-${ANT_VERSION} /opt/ant && \ rm apache-ant-${ANT_VERSION}-bin.tar.gz

ENV ANT_HOME /opt/ant
ENV PATH ${PATH}:/opt/ant/bin

ENV ANDROID_SDK_VERSION r24.4.1
ENV ANDROID_BUILD_TOOLS_VERSION 23.0.3

RUN dpkg --add-architecture i386 && \
apt-get update -y && \
apt-get install -y libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 && \
rm -rf /var/lib/apt/lists/* && \
apt-get autoremove -y && \
apt-get clean

ENV ANDROID_SDK_FILENAME android-sdk_${ANDROID_SDK_VERSION}-linux.tgz
ENV ANDROID_SDK_URL http://dl.google.com/android/${ANDROID_SDK_FILENAME}
ENV ANDROID_API_LEVELS android-15,android-16,android-17,android-18,android-19,android-20,android-21,android-22,android-23
ENV ANDROID_HOME /opt/android-sdk-linux
ENV PATH ${PATH}:${ANDROID_HOME}/tools:${ANDROID_HOME}/platform-tools
RUN cd /opt && \
wget -q ${ANDROID_SDK_URL} && \
tar -xzf ${ANDROID_SDK_FILENAME} && \
rm ${ANDROID_SDK_FILENAME} && \
echo y | android update sdk --no-ui -a --filter tools,platform-tools,${ANDROID_API_LEVELS},build-tools-${ANDROID_BUILD_TOOLS_VERSION}

###Добавим файл системы интеграции, это может быть слейв дженкинса, агент Bamboo и т. п., в зависимости от того, с чем вы работаете
ADD moyagent.sh /agentCI/


В докерфайл также можно добавить все необходимые библиотеки и файлы, которыми будет пользоваться агент системы интеграции. Соберём dockerfile:



docker build .


Теперь у нас есть образ с Android SDK, осталось сделать так, чтобы он видел только одно устройство. Для этого будем цеплять его через симлинк c помощью udev:



echo ‘"SUBSYSTEM=="usb", ATTRS{serial}=="$DEVICE_SERIAL", SYMLINK+="androidDevice1"’ >> /etc/udev/rules.d/90-usb-symlink-phones.rules


Вместо $DEVICE_SERIAL вписываем наш свежепрошитый серийник. Перезапускаем определение правил устройств:



udevadm control --reload
udevadm trigger


Теперь в пути /dev/androidDevice1 у нас будет симлинк на устройство, осталось передать его в контейнер при запуске:



docker run -i -t --rm --device=/dev/androidDevice1:/dev/bus/usb/001/1 android-docker-image:latest adb devices


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



docker run -i -t --rm --device= /dev/androidDevice1:/dev/bus/usb/001/1 android-docker-image:latest /bin/sh /agentCI/moyagent.sh


Кстати, ключ --device стал работать с симлинками относительно недавно (master-ветка на Гитхабе), до этого приходилось генерить из симлинка realpath c помощью скрипта и уже его передавать Докеру, так что если у вас не выходит подключение устройства, то добавьте в udev в параметр RUN+= такой скрипт:



realpath /dev/androidDevice1 | xargs -I linkpath link linkpath /dev/bus/usb/010/1


После этого в старых версиях Docker добавить телефон можно так:



docker run --privileged -v /dev/bus/usb/010/:/dev/bus/usb/100/ -i -t  android-docker-image:latest adb devices


Всё, можно подключать свой слейв к системе интеграции и работать с ним.



Заключение



Физические мобильные устройства в системе интеграции рано или поздно появляются у любого более-менее крупного проекта на Андроиде — неизбежно возникают необходимость покрытия ошибок, нестандартные тестовые случаи или просто фичи, которые требуют реального устройства. Кроме всего этого, устройства не используют ресурсы ваших серверов, так как процессоры и память у них свои, а хост для телефонов не должен быть супермощным, «домашний» десктоп со всем этим вполне справится. Соизмеряйте плюсы и минусы, считайте, что выгоднее, — наверняка в вашей системе автоматизированного тестирования есть место реальным устройствам. Желаю вам поменьше багов и побольше тестового покрытия. :)
Original source: habrahabr.ru.

https://habrahabr.ru/post/306236/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] ZigBee и Intel Edison: практика автоматизации переговорных комнат

Пятница, 01 Июля 2016 г. 14:35 (ссылка)

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





Мы создали интеллектуальную систему бронирования переговорных комнат (Smart Conference Room System, SCR) для того, чтобы помочь всем желающим с этими проблемами справиться.



Общий обзор



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



Система построена на основе следующих аппаратных компонентов:




  • Плата Intel Edison.

  • Плата расширения Arduino.

  • Модуль XBee ZB S2 ZigBee.

  • Android-смартфон.

  • Push-сервер.

  • Датчик освещённости ZigBee.

  • Инфракрасный датчик присутствия ZigBee.

  • Интеллектуальная розетка ZigBee.

  • Сигнализация ZigBee.



ZigBee – это спецификация набора высокоуровневых коммуникационных протоколов, которые используются для создания персональных сетей, в основе которых – небольшие маломощные цифровые передатчики. Протоколы ZigBee базируются на стандарте IEEE 802.15.4 и предназначены для использования во встраиваемых устройствах, которые требуют низкого энергопотребления и способны нормально работать при невысоких скоростях передачи данных. Сеть, построенная на основе ZigBee, будет весьма экономичной в плане потребления энергии. Для того, чтобы пройти сертификацию ZigBee, устройство должно работать от батарей не менее двух лет. Типичные применения таких устройств – это домашняя автоматизация. Например, интеллектуальные датчики присутствия, системы освещения, терморегуляторы.



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



Важный аспект платформы Arduino – это стандартизированные коннекторы, которые позволяют подключать к основному блоку с микроконтроллером множество взаимозаменяемых модулей расширения, известных как шилды (shields). Плата Intel Edison также поддерживает Arduino. Это делает Edison совместимым с тысячами модулей для Arduino, например, с XBee ZigBee.



XBee – это название марки семейства радиомодулей от Digi International, выпускаемых в стандартных форм-факторах. XBee ZB поддерживает протокол ZigBee PRO для создания сетей с ячеистой топологией.



С программной точки зрения система состоит из следующих частей:




  • Серверное ПО.

  • Приложение для Android-смартфона.

  • Прошивка для Intel Edison.



Вот как, в самых общих чертах, выглядит работа Smart Conference Room System.





Схема работы SCR



Аппаратное обеспечение



Остановимся подробнее на аппаратном обеспечении, на котором основан наш проект.



Intel Edison с коммутационной платой Arduino – это ядро системы. Так как Edison совместим с Arduino, устройства, которые могут работать с Arduino, подходят и для Edison. Например, это радиомодуль XBee ZB S2, который подключается к Edison с помощью платы расширения Arduino.





Intel Edison и радиомодуль XBee



В качестве Push-сервера мы использовали Windows-планшет Fujitsu STYLISTIC Q702 с процессором Intel Core i5-3427U (частота 1.80 ГГц), оснащённый 4 Гб оперативной памяти.





Планшет Fujitsu STYLISTIC Q702



Для того, чтобы с нашей системой было удобнее работать, мы создали для неё мобильное Android-приложение. Его испытания проводились на смартфоне Lenovo K900. Он оснащён процессором Intel Atom Z2580 (частота 2 ГГц) и 2 Гб оперативной памяти.





Смартфон Lenovo K900



Роль координатора ZigBee играет радиомодуль XBee ZB S2, выполненный в форм-факторе платы расширения для Arduino и соответствующий требованиям протокола ZigBee. Он управляет подключёнными к нему ZigBee-датчиками.





Радиомодуль XBee ZB S2



В проекте задействован датчик освещённости Netvox Z311X. Он соответствует требованиям стандарта ZigBee и отвечает за измерение уровня освещённости в помещении.





Датчик освещённости



В качестве датчика присутствия используется инфракрасный сенсор Netvox ZB11D. Он так же поддерживает работу по протоколу ZigBee и играет роль конечного сетевого устройства.





Датчик присутствия



В системе используется модуль сигнализации Netvox Z602A. Это устройство совмещает в себе средства звукового и светового оповещения и применяется в экстренных ситуациях. Модуль основан на стандарте ZigBee HA.





Сигнализация



Интеллектуальная ZigBee-розетка, применяемая в проекте, это Netvox Z809AG. Устройство совмещает функции учёта электроэнергии и управления электрическими цепями. С его помощью можно включать и выключать питание различных электроприборов в комнате.





Интеллектуальная розетка



Аппаратная инфраструктура



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





Схема устройства системы



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




  • Смартфон.

  • Push-сервер.

  • Шлюз на базе Intel Edison.

  • Набор ZigBee-датчиков.



Эти аппаратные блоки ориентированы на три основные функции SCR.




  1. Наблюдение за комнатой и оценка ситуации. ZigBee-датчики освещённости и присутствия, в режиме реального времени, поставляют сведения о ситуации в комнате шлюзу на базе Intel Edison. Для связи датчиков и шлюза используется сеть ZigBee. Edison анализирует показания, определяет, есть ли кто-нибудь в комнате, а затем отправляет свои выводы push-серверу по Wi-Fi.




  2. Бронирование комнаты и интеллектуальное расписание. Сотрудники могут резервировать переговорные, которые, по оценке системы, свободны. Делается это с помощью Android-смартфона. Если доступных переговорных нет, сотрудник может выбрать занятую комнату и включить режим ожидания освобождения переговорной. Как только система, в частности – Intel Edison, сочтёт, что выбранная комната свободна, сообщение об этом поступит на сервер, который отправит уведомление приложению на смартфоне.




  3. Удалённый доступ и управление. Приложения могут запрашивать сведения о состоянии зарезервированной комнаты по Wi-Fi через push-сервер для того, чтобы управлять устройствами в комнате, например, включать и выключать свет, и получать, в режиме реального времени, сведения с ZigBee-датчиков.



Программное обеспечение



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



На рисунке ниже показана структурная схема используемого программного решения.





Архитектура программного решения



Push-сервер



В качестве push-сервера мы использовали GlassFish 4.0. Вот, как выглядит архитектура сервера.





Архитектура сервера



Системная диаграмма сервера показана ниже. Когда Edison, пользуясь сведениями с ZigBee-датчиков, определит, что состояние помещения изменилось со «свободно» на «занято», или наоборот, он оповестит об этом сервер. Сервер, в свою очередь, изменит соответствующую запись в базе данных, а затем, если комната пуста, отправит сообщение Android-приложению.





Рабочий процесс Push-сервера



Intel Edison и ZigBee



В Arduino интерфейс между Intel Edison и координатором XBee эмулируется в виде последовательного порта. Приложение, запущенное на Intel Edison, работает как ZigBee-шлюз. С его помощью мы можем отправлять команды ZigBee-датчикам и принимать ответы от них.

Координатор ZigBee, кроме того, отвечает за передачу сведений с датчиков push-серверу.





Устройство стека ZigBee в Arduino



Мы спроектировали и реализовали в среде Arduino простой стек ZigBee, который используется для взаимодействия с датчиками. Плата работает в режиме координатора, который наблюдает за состоянием датчиков, и, если такая возможность предусмотрена, позволяет управлять ими.



Классы стека ZigBee














































Класс

Функция

XBeeAddress

Базовый класс адреса устройства ZigBee

XBeeAddress64

64-битный IEEE-адрес устройства ZigBee

XBeeAddress16

16-битный сетевой адрес устройства ZigBee

Payload

Полезная нагрузка командного кадра ZigBee

ExplicitAddressCommand

Командный кадр ZigBee, используемый в спецификации домашней автоматики

ExplicitAddressCommandResponse

Ответ на команду на явно заданный адрес

XBeeSensor

Базовый класс ZigBee-датчика

XBeeLightSensor

Датчик освещённости ZigBee

XBeeInfraSensor

Датчик присутствия ZigBee

XBeeAlarm

Сигнализация ZigBee



Основные функции ArduinoXBee



Главный класс ArduinoXBee – это XBeeCoordinator. Этот класс отвечает за управление ZigBee-датчиками. Его основные задачи заключаются в сборе сведений с датчиков и в отправке им команд для удалённого управления их поведением. Вот описание функций, применяемых для работы с датчиками.



Int getLightValue(XBeeLightSensor lightSensor). Эта функция используется для получения сведений с датчика освещённости. На её вход подаётся объект датчика освещённости, на выходе получаем целое число в диапазоне от 0 до 65535.



bool getInfraValue(XBeeInfraSensor infraSensor). Функция получает показания заданного датчика присутствия. При вызове ей передаётся объект датчика присутствия, а возвращает она логическое значение. True указывает на то, что в комнате кто-то есть, False – на то, что комната пуста.



void turnOnAlarm(XBeeAlarm alarm) и void turnOffAlarm(XBeeAlarm alarm). Эти функции, соответственно, включают и выключают сигнализацию. При их вызове используется объект, символизирующий нужное устройство, они ничего не возвращают.



void turnOnSwitch(XBeeSmartPlug plug) и void turnOffSwitch(XBeeSmartPlug plug). Эти функции позволяют включать и отключать подачу электричества интеллектуальными розетками. При вызове функций им передают объект, соответствующий розетке, они не возвращают ничего.



Приложение для Android



Когда пользователь запускает приложение, у него есть возможность создать новое расписание или управлять существующим, а именно – удалить его. Создавая новое расписание, пользователь может выполнять поиск переговорных по времени и расположению. Если комната свободна, её можно тут же зарезервировать. Если комната занята, пользователь может выбрать вариант ожидания освобождения комнаты. Как только датчики ZigBee зафиксируют освобождение комнаты в пределах заданного временного диапазона, push-сервер отправит уведомление приложению, и пользователь, который это уведомление получит, может зарезервировать комнату.





Системная диаграмма работы с Android-приложением



Пользовательский интерфейс Android-приложения



Приложение для Android мы назвали «Smart Conference Room System». Пользуясь им, сотрудник организации может забронировать переговорную и управлять зарезервированными комнатами. Вот, как выглядит главный экран приложения.





Главный экран приложения



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



Используя команду My Scheduling, пользователи могут бронировать переговорные (синий цвет используется для указания на то, что комната свободна, серый – на то, что уже забронирована). Если комната не свободна, пользователь может включить режим ожидания её освобождения.





Бронирование комнаты



Пользователи могут проверять состояние комнат, которые они забронировали, или тех, освобождения которых ожидают. Синим цветом выводятся успешно забронированные комнаты, серым – те, освобождения которых ожидает сотрудник. Здесь же можно управлять своим расписанием.





Управление расписанием



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





Уведомление об освобождении комнаты



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



Выводы



Мы разработали интеллектуальную систему управления комнатами для переговоров, в основе которой – простой ZigBee-стек для Arduino. Система может определять, в режиме реального времени, свободна комната или занята. Это позволяет упростить бронирование помещений, сделать его удобнее, повысить эффективность использования переговорных комнат.



Многое уже сделано, но мы, однако, всё ещё сталкиваемся с некоторыми сложностями. Это касается разных аспектов работы системы. Так, если говорить о её внутреннем устройстве, о стеке, на котором она основана, это ограничения функций API стека и всего комплекса. Кроме того, нужно улучшить стабильность работы системы и другие аспекты её функционирования. Мы планируем создание следующей версии Smart Conference Room System, которая будет более функциональной, стабильной и удобной, а значит позволит лучше решать её основную задачу: оптимизацию использования переговорных комнат в организациях.
Original source: habrahabr.ru.

https://habrahabr.ru/post/304546/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Teaser_Advertising

«Умный дом» от Disystems – исключительный комфорт!

Четверг, 30 Июня 2016 г. 16:07 (ссылка)


5684778_Home_500x327 (500x327, 40Kb)



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



СпециалистыDisystems используют в работе технологии «Умный дом» от американского бренда AMX. Широчайший ассортимент продуктов АМХ и их модульность позволяют нам предлагать максимально гибкие решения, прекрасно адаптируемые к любым требованиям заказчика. Благодаря этому стоимость системы автоматизации «Умный дом» может быть доступной для любого клиента - все зависит от индивидуальных пожеланий!



Автоматизация дома и превращение его в интеллектуальное здание – достижимая мечта, которую можно исполнить!



Хотите шагнуть в будущее уже сейчас? Звоните: (044) 362-00-55 // (067) 770-93-33 // (067) 658-33-95!



А также приезжайте в наш шоу-рум, который находится по адресу: пр-т В. Лобановского (Краснозвездный), 150д.



Disystems



http://www.disystems.com.ua/



info@disystems.com.ua

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

О том как я помечал пороги Хабра, Майла, ОнлиОфиса и прихожую В Кругу Друзей

Понедельник, 20 Июня 2016 г. 14:12 (ссылка)





Здравствуйте, товарищи! В опубликованных вчера предыдущих двух материалах: на Гиктаймсе и на Хабре — я рассказал о том, что такое технокоммунизм и своё видение того, как нужно к нему двигаться не политическими битвами, а развитием технологий, общественными проектами и т.д., за счёт создания всемирной автоматизированной системы «Технокоммунизм», которую нужно начинать внедрять с того места где сейчас находятся люди, а именно с полезных интернет-сервисов. Как и ожидалось, кроме нашедшихся сторонников, некоторые товарищи выразили своё непонимание того, о чём я говорю. Поэтому, теперь моя задача планомерно, серией статей, раскрывать различные вопросы более подробно, но самое главное — осуществлять реальное движение по реализации всего озвученного.



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



Начну с «помечания». На заглавной картинке изображён лев, который как раз этим занимается с сосредоточенно-довольной мордой, поскольку моя фамилия Левадный, я решил провести вот такую хулиганскую ассоциацию. История того, как я стал использовать такой термин, вот такая. До того как я бросил почти всё и начал заниматься в основном общественной деятельностью, и до того как я продался крупным компаниям, в Омске у меня была небольшая ИТ-компания. Небольшая, но во многом крутая. Офис в центре города с душевыми, кухней и местами отдыха, крупные (по местным меркам) клиенты и всё-такое. Это был мой третий бизнес, первые два были неудачными. Почему был этот удачный? Потому, что я научился не сидеть и не ждать пока кто-то ко мне придёт и скажет что-то вроде: «Мы принесли вам деньги, возьмите их и ничего не делайте». Я перестал быть социопатом (не сразу и не полностью конечно) и начал бывать в разных местах, рассказывать о себе и о друзьях, о своей компании, знакомиться с людьми. В общем налаживать те самые деловые контакты ну и просто новые социальные связи.



Термин, этот, в голове у меня появился когда мы шли с другом-коллегой по улице со стоянки к офису, шли немного с другой стороны здания, не где обычно, я вижу вывеска с названием компании и говорю, давай по пути сейчас зайдём со словами: «УРААА, свершилось!!!». А когда они офигевшие на нас буду смотреть, мы скажем: «А знаете ли вы, что наша прекрасная компания занимающаяся техподдержкой и вообще комплексной автоматизацией, теперь находится с вами прямо в одном здании?». Друг говорит, что может не будет пугать людей, я ему говорю, что да давай зайдём, вроде как территорию пометим, скажем, что мы теперь тут. Даже если сразу с нами договор не заключат, то потом вспомнят. Вот так и возник у меня этот термин. В общем зашли, дверь не туда как-то пытались открыть, когда зашли на нас уже все пялились, поэтому кричать уже не надо было. Я рассказал, что мы ИТ-компания и мы тут в здании. Они сказали, что-то типа, что на ловца и зверь бежит, у них был мальчик, которых их админил, теперь ушел работать в какую-то компанию, им как раз мы и нужны. Вот так оно происходит.







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



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









Хорошо было бы, если бы ты такой понял, что у тебя есть гениальная идея, пришёл сразу в самую крупную компанию по близости, заходишь внутрь и говоришь охране, что у тебя гениальная идея. Охранник поднимает руку, но не для того, чтобы дать тебе по физиономии, а даёт тебе карточку-ключ от всех дверей и говорит, что вам нужно к самому главном директору, он на 16-ом этаже, вы пока поднимайтесь к нему, а я предупрежу его телохранителей, что у вас гениальная идея, чтобы они вас пропустили. Вы такой поднимаетесь на 16-й этаж, видите там большую дверь рядом с которой стоят телохранители, вы подходите к ней и хотите открыть её с ноги, но не успеваете, потому что телохранители её вам услужливо открывают. Вы такой говорите им, типа вы что, решили помешать внедрению моей гениальной идеи? Они со страхом в глазах отрицательно машут головами, тогда закройте дверь — говорите вы им. Они закрывают и вы, как и было запланировано, открываете с ноги дверь самого главного директора, заходите в его приёмную. Там сидит красивая секретарша и от громкого стука из своего помещения выглядывает, тот самый, главный директор, вы ему говорите: «У меня гениальная идея». Директор практически со слезами на глазах произносит: «Ну вот и дождались… я сейчас позвоню, отменю встречу с мэром нашего города, скажу, что не до него сейчас, а вы пока располагайтесь». А секретарша такая говорит: «Похоже меняется руководство компании, я тогда пока быстро схожу кружевное нижнее бельё одену». «Не надо, вы нужны мне как профессионал своего дела» — шутите вы ей, а жестом показываете чтобы она не забыла ещё и в душ забежать. Тут прибегает самый главный директор, со взглядом любящей собаки и открытом ртом смотри на вас… Но пока в этом мире всё не так.



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



1. Сначала обратился в Хабр



Первым этапом, среди таких зверей как Хабрахабр, Гиктайм и тогда ещё и Мегамозг (помните о нём?), можно было завести ещё одну неведому зверушку Технокоммунизм, перенести туда некоторые существующие хабы и создать новые. Последующими этапами создать функционал управления общественными проектами, базовый функционал социальной сети и так далее, постепенно всё это расширяя.



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



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



2. Маил.Ру Групп



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



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



Внутри компании я бы развивал идею сделать её народным предприятием. Даже не находясь сейчас внутри компании, считаю, что Майл — одна из тех компаний, которая в России уже сейчас в основном готова стать народной. Через некоторое время начну закидывать видео-обращениями и другими материалами главного владельца Майла, олигарха Алишера Усманова, чтобы он осознал происходящие эволюционные процессы и встал на сторону трудящихся. Будет весело.



3. ОнлиОфис



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



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



4. В конечном итоге были «в Кругу Друзей»



Помните о такой соц. сети? Это, которая бывшая odnoklassniki.KM.ru. Которая соц. сеть от портала «Кирилл и Мефодий». Помните их диски с энциклопедиями? Вот с ними я продвинулся дальше всех, им понравилось, но сказали, что их компанию сейчас захватывают рейдеры, поэтому сейчас все силы уходят на то, чтобы биться с ними. Там можно было бы внедрить всё то, что я в Майле предлагал.



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



Результат



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



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



Рекомендую всем к прочтению, особенно раздел «Лучший маркетинг для „Технокоммунизма“» (третий и четвёртый лист). Все картинки с листами бизнес-плана кликабельны.



Лист 0 (заглавный)

image



Лист 1 (оглавление-резюме)

image



Лист 2 (краткое описание проекта, концепция и история — начало)

image



Лист 3 (краткое описание проекта — окончание, никакого нытья, лучший маркетинг — начало)

image



Лист 4 (лучший маркетинг — окончание, что нам стало понятно? — начало)

image




Помните те времена, когда всякие большие энциклопедии и игры были на 4 и даже на 8 дисках?




























Проголосовало 3 человека. Воздержался 1 человек.





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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/298344/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Опыт автоматизации тестирования серверного REST API с помощью Jmeter

Суббота, 18 Июня 2016 г. 21:58 (ссылка)

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.



RTLSCP реализует архитектуру REST и позволяет в запросах и ответах передавать данные в форматах JSON, KML и PNG. Причем общение по нему может происходить как по HTTP/HTTPS, так и по WS/WSS (Websocket). Этот протокол обеспечивает внешнего клиента обширным функционалом:




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

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

  • получение отчетов по устройствам, статуса работы системы от Quality of Service.

  • множество других полезных функций.



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



Тестирование системы проводится под Linux. Изначально мы пытались написать автотесты “на коленке“. Перепробовали несколько вариантов. Генерация запросов со случайными данными и отправка их на вход утилиты для нагрузочного тестирования Siege. В этом случае мы получаем только нагрузочное тестирование без возможности анализа содержимого ответа от сервера. Реализация автотестов на Python и простая отправка запросов через urllib. Тут всё веселее с анализом ответа, но получается громоздкий код, в который сложно вникать стороннему человеку и долго модифицировать.



Решением всех наших проблем стал неожиданно найденный Jmeter от Apache. Хоть на первый взгляд его графический интерфейс вызывает страх у обывателя, на деле этот инструмент помог найти большое количество багов и сэкономить много времени на тестировании RTLSCP API.



Рис. 1. Графический интерфейс Jmeter.



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



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



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





Рис. 2. Так выглядит реализация проверки создания аккаунтов.



С помощью BeanShell PostProcessor (Post тут означает, что скрипт запускается после выполнения запроса) обрабатываем ответ на запрос всех доступных в системе ресурсов. Получаем их количество и генерируем случайные Id ресурсов для последующего присвоения созданным аккаунтам прав доступа к ним. Это осуществляется следующим кодом на BeanShell:

import java.util.regex.*;
import java.util.*;
import java.util.Random;

String response = prev.getResponseDataAsString();
Pattern pattern = Pattern.compile("id");
Matcher matcher = pattern.matcher(response);
int count = 0;
while (matcher.find())
count++;
Random rd=new Random();
Set resSet = new HashSet();
while (resSet.size()<4)
resSet.add(rd.nextInt(count));
int i=1;
Iterator iterator = resSet.iterator();
while (iterator.hasNext()) {
vars.put("resForCombo"+i,iterator.next().toString());
i++;
}




Затем из ответа на запрос информации о ресурсе по его Id получаем его URL с помощью Regular Expression Extractor:





Рис. 3. Использование Regular Expression Extractor.



Тут всё очевидно, в переменную res1Addr помещается содержимое ответа, вырезанное по регулярному выражени. В конце проводим проверку всех созданных аккаунтов и их права доступа к ресурсам. Кстати, обработка Cookies для авторизации в Jmeter реализуется простым добавлением элемента HTTP Cookie Manager.



Элементы типа check AUTH_ACCOUNT_ADDED_INTO_GROUP на рисунке 2 нужны для проверки того, что каждое действие пользователя, совершенное над аккаунтами записалось в соответствующее событие в истории событий (Получаемой также через RTLSCP).



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



${__Random(300,180000)}




Или сгенерировать строку определенного размера и случайного содержания:



${__RandomString(${__Random(3,30)},ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789,)}




Понравилось, что в Jmeter любое действие можно реализовать как в коде BeanShell, так и с помощью встроенных инструментов. К примеру, получить количество доступных в системе ресурсов (выше мы это делаем через BeanShell PostProcessor ) можно реализовав Regular Expression Extractor, в котором в поле Match No. следует просто указать -1. В этом случае создаётся переменная {Reference Name}_matchNr, содержащая количество найденных в ответе по регулярному выражения строк. Так и ответ на любой запрос можно анализировать в коде BeanShell и выставлять флаги статуса выполнения элемента:



//Get response
response = prev.getResponseDataAsString();
//Check login
if (!response.contains("\"login\":\"${ulogin_g1}\"")) {
log.error("### login NOK!");
Failure= true;
//Check timestamp
} else if(!response.contains("\"create_ts\":${createTS_g1}")) {
log.error("### create_ts NOK!");
Failure= true;




Возможность комментирования каждого элемента делает автотест читабельным и позволяет ссылаться на тикет в багтрекере, например, Redmine:





Рис. 4. Комментирование элементов.



Отключение ресурсоемких проверок и добавление в Thread Group автотеста пользователей в поле Number of Treads (users) превращает наш функциональный автотест в нагрузочный. Теперь проект запускается одновременно из указанного количества потоков и нагружает сервер.





Рис. 5 Нагрузочное тестирование.



Результаты выполнения автотеста можно получить в любом удобном виде, как просмотреть в графической оболочке через View Results Tree, так и файлами логов с различными настройками:





Рис. 6 Получение результатов.



Также стоит отметить возможность в режиме реального времени отправлять результаты или любую другую информацию о статусе автотеста в различные сервисы (JDBC, JMS, Webservice). Например, на Graphite с последующим отображением в Grafana:





Рис. 7 Отправка результатов.



Естественно, у Jmeter существует некоторое количество отрицательных свойств. Например, не всегда удобный графический интерфейс и баги в нём. Но в нашей ситуации, когда срочно (и самое важное, бесплатно) требуется покрыть автоматическими тестами большое количество функций общения клиентов с сервером через протокол, Jmeter оказался незаменимым инструментом тестировщика.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303584/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Опыт автоматизации тестирования серверного REST API с помощью Jmeter

Суббота, 18 Июня 2016 г. 21:58 (ссылка)

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.



RTLSCP реализует архитектуру REST и позволяет в запросах и ответах передавать данные в форматах JSON, KML и PNG. Причем общение по нему может происходить как по HTTP/HTTPS, так и по WS/WSS (Websocket). Этот протокол обеспечивает внешнего клиента обширным функционалом:




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

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

  • получение отчетов по устройствам, статуса работы системы от Quality of Service.

  • множество других полезных функций.



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



Тестирование системы проводится под Linux. Изначально мы пытались написать автотесты “на коленке“. Перепробовали несколько вариантов. Генерация запросов со случайными данными и отправка их на вход утилиты для нагрузочного тестирования Siege. В этом случае мы получаем только нагрузочное тестирование без возможности анализа содержимого ответа от сервера. Реализация автотестов на Python и простая отправка запросов через urllib. Тут всё веселее с анализом ответа, но получается громоздкий код, в который сложно вникать стороннему человеку и долго модифицировать.



Решением всех наших проблем стал неожиданно найденный Jmeter от Apache. Хоть на первый взгляд его графический интерфейс вызывает страх у обывателя, на деле этот инструмент помог найти большое количество багов и сэкономить много времени на тестировании RTLSCP API.



Рис. 1. Графический интерфейс Jmeter.



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



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



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



image

Рис. 2. Так выглядит реализация проверки создания аккаунтов.



С помощью BeanShell PostProcessor (Post тут означает, что скрипт запускается после выполнения запроса) обрабатываем ответ на запрос всех доступных в системе ресурсов. Получаем их количество и генерируем случайные Id ресурсов для последующего присвоения созданным аккаунтам прав доступа к ним. Это осуществляется следующим кодом на BeanShell:

import java.util.regex.*;
import java.util.*;
import java.util.Random;

String response = prev.getResponseDataAsString();
Pattern pattern = Pattern.compile("id");
Matcher matcher = pattern.matcher(response);
int count = 0;
while (matcher.find())
count++;
Random rd=new Random();
Set resSet = new HashSet();
while (resSet.size()<4)
resSet.add(rd.nextInt(count));
int i=1;
Iterator iterator = resSet.iterator();
while (iterator.hasNext()) {
vars.put("resForCombo"+i,iterator.next().toString());
i++;
}




Затем из ответа на запрос информации о ресурсе по его Id получаем его URL с помощью Regular Expression Extractor:



image

Рис. 3. Использование Regular Expression Extractor.



Тут всё очевидно, в переменную res1Addr помещается содержимое ответа, вырезанное по регулярному выражени. В конце проводим проверку всех созданных аккаунтов и их права доступа к ресурсам. Кстати, обработка Cookies для авторизации в Jmeter реализуется простым добавлением элемента HTTP Cookie Manager.



Элементы типа check AUTH_ACCOUNT_ADDED_INTO_GROUP на рисунке 2 нужны для проверки того, что каждое действие пользователя, совершенное над аккаунтами записалось в соответствующее событие в истории событий (Получаемой также через RTLSCP).



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



${__Random(300,180000)}




Или сгенерировать строку определенного размера и случайного содержания:



${__RandomString(${__Random(3,30)},ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789,)}




Понравилось, что в Jmeter любое действие можно реализовать как в коде BeanShell, так и с помощью встроенных инструментов. К примеру, получить количество доступных в системе ресурсов (выше мы это делаем через BeanShell PostProcessor ) можно реализовав Regular Expression Extractor, в котором в поле Match No. следует просто указать -1. В этом случае создаётся переменная {Reference Name}_matchNr, содержащая количество найденных в ответе по регулярному выражения строк. Так и ответ на любой запрос можно анализировать в коде BeanShell и выставлять флаги статуса выполнения элемента:



//Get response
response = prev.getResponseDataAsString();
//Check login
if (!response.contains("\"login\":\"${ulogin_g1}\"")) {
log.error("### login NOK!");
Failure= true;
//Check timestamp
} else if(!response.contains("\"create_ts\":${createTS_g1}")) {
log.error("### create_ts NOK!");
Failure= true;




Возможность комментирования каждого элемента делает автотест читабельным и позволяет ссылаться на тикет в багтрекере, например, Redmine:



image

Рис. 4. Комментирование элементов.



Отключение ресурсоемких проверок и добавление в Thread Group автотеста пользователей в поле Number of Treads (users) превращает наш функциональный автотест в нагрузочный. Теперь проект запускается одновременно из указанного количества потоков и нагружает сервер.



image

Рис. 5 Нагрузочное тестирование.



Результаты выполнения автотеста можно получить в любом удобном виде, как просмотреть в графической оболочке через View Results Tree, так и файлами логов с различными настройками:



image image

Рис. 6 Получение результатов.



Также стоит отметить возможность в режиме реального времени отправлять результаты или любую другую информацию о статусе автотеста в различные сервисы (JDBC, JMS, Webservice). Например, на Graphite с последующим отображением в Grafana:



image

Рис. 7 Отправка результатов.



Естественно, у Jmeter существует некоторое количество отрицательных свойств. Например, не всегда удобный графический интерфейс и баги в нём. Но в нашей ситуации, когда срочно (и самое важное, бесплатно) требуется покрыть автоматическими тестами большое количество функций общения клиентов с сервером через протокол, Jmeter оказался незаменимым инструментом тестировщика.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303584/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Автоматизируем покупку Ж/Д билетов Укрзалізниці

Понедельник, 13 Июня 2016 г. 22:32 (ссылка)

Привет! Наверное, каждый из нас когда-то сталкивался с ситуацией, когда нужно срочно куда-то уехать, но все Ж/Д билеты уже раскуплены. В этой статье я расскажу о том, как я писал Telegram бота для отслеживания и покупки освободившихся билетов Укрзалізниці.



Как это работает



Для покупки железнодорожных билетов в Украине компания Укрзалізниця запустила ресурс http://booking.uz.gov.ua/. Ресурс удобен тем, что не нужно посещать кассы, чтобы забрать сам билет. Достаточно показать проводнику QR код с посадочного талона на экране смартфона либо распечатав на принтере.



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



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



В качестве интерфейса был выбран Telegram так как это новая платформа для меня и я хотел с ней немного разобраться. В качестве бонуса сразу получаем уведомления на мобильный, не задумываясь о push нотификациях или email'ах.

В качестве языка программирования был выбран Python.



Интерфейс



И всё же, как это работает с точки зрения пользователя?

Бот распознает следующие команды:




  • /help — вернёт список поддерживаемых команд

  • /trains 2016-06-12 Kyiv Lviv — вернёт список поездов из Киева во Львов, отправляющихся 12 июня 2016 года

  • /scan Ivanov Ivan 2016-06-12 Kyiv Lviv 743K — запустит мониторинг билетов на поезд 743К Киев-Львов. Возвращает ID данного сканирования

  • /status_1234 — вернет состояние сканирования с ID 1234

  • /abort_1234 — остановит сканирование с ID 1234



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



UZ API



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



В API используются только POST запросы. Для защиты от использования API сторонними разработчиками почти во всех вызовах в тело включается токен. Без токена можно производить только поиск станций.



Стоит также отметить, некоторые нюансы работы с датами. Во-первых, формат даты меняется в зависимости от текущей локали API. Например, для локали en формат будет mm.dd.yyyy. Тогда как для ua и ru это будет привычный нам dd.mm.yyyy. Во-вторых, для некоторых запросов дата представляется в виде timestamp, однако он зависит от состояния летнего/зимнего времени. Потому я решил не заморачиваться с сериализацией/десериализацией данных штампов, а использовать их в том виде, в котором API возвращает их.



Получение токена



Покопавшись в подключаемых сайтом скриптах, можно с легкостью обнаружить такой кусок:



var ajax = $v.ajax(url).header({
'GV-Ajax': 1,
'GV-Referer': encodeURI(GV.site.htcur_url + GV.site.requestUri),
'GV-Screen': screen.width + 'x' + screen.height,
'GV-Token': localStorage.getItem('gv-token') || ''
});


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



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



Краткий API reference



Для вызова методов API, необходимо включать следующие заголовки:



GV-Ajax: 1
GV-Referer: http://booking.uz.gov.ua/en/
GV-Token:


Поиск станций



Например, для формирования подсказок автодополнения станций выполняется запрос с пустым телом по адресу http://booking.uz.gov.ua/en/purchase/station/ky/, где ky — это то, что пользователь вводит в текстовое поле выбора станции.



В ответ сервер отправляет примерно такой JSON:



{
"value": [
{
"title": "Kyiv",
"station_id": "2200001"
},
{
"title": "Kyivska Rusanivka",
"station_id": "2201180"
},
{
"title": "Kyj",
"station_id": "2031278"
},
{
"title": "Kykshor",
"station_id": "2011189"
}
],
"error": null,
"data": {
"req_text": [
"ky",
"лн"
]
},
"captcha": null
}


Поиск поездов



Для поиска поездов необходимо выполнить запрос на http://booking.uz.gov.ua/en/purchase/search/ с таким телом:



station_id_from=2200001  # ID станции отправления
station_id_till=2218000 # ID станции назначения
date_dep=06.12.2016 # дата отправления в формате mm.dd.yyyy
time_dep=00:00
time_dep_till=
another_ec=0
search=


В ответ мы получим список поездов, следующих по указанному маршруту. Так же, в ответ будет включена информация о количестве свободных мест в вагонах каждого типа (Люкс, Купе, Плацкарт, и т. д.):



{
"value": [
{
"num": "743Л",
"model": 1,
"category": 1,
"travel_time": "5:01",
"from": {
"station_id": 2200001,
"station": "Darnytsya",
"date": 1465741200,
"src_date": "2016-06-12 17:20:00"
},
"till": {
"station_id": 2218000,
"station": "Lviv",
"date": 1465759260,
"src_date": "2016-06-12 22:21:00"
},
"types": [
{
"title": "Seating first class",
"letter": "С1",
"places": 117
},
{
"title": "Seating second class",
"letter": "С2",
"places": 176
}
],
"reserve_error": "reserve_24h"
},
{
"num": "091К",
"model": 0,
"category": 0,
"travel_time": "7:25",
"from": {
"station_id": 2200001,
"station": "Kyiv-Pasazhyrsky",
"date": 1465760460,
"src_date": "2016-06-12 22:41:00"
},
"till": {
"station_id": 2218000,
"station": "Lviv",
"date": 1465787160,
"src_date": "2016-06-13 06:06:00"
},
"types": [
{
"title": "Suite / first-class sleeper",
"letter": "Л",
"places": 11
},
{
"title": "Coupe / coach with compartments",
"letter": "К",
"places": 50
}
],
"reserve_error": "reserve_24h"
}
],
"error": null,
"data": null,
"captcha": null
}


Просмотр вагонов



Просмотреть список вагонов и количество свободных мест можно выполнив запрос на http://booking.uz.gov.ua/en/purchase/coaches/ с таким телом:



station_id_from=2200001
station_id_till=2218000
date_dep=1462976400
train=743К # номер поезда
model=3 # модель поезда
coach_type=С2 # тип вагона (люкс, купе, и т. д.)
round_trip=0
another_ec=0


В ответ мы получим список вагонов данного типа с количеством свободных мест и ценой:



{
"coach_type_id": 10,
"coaches": [
{
"num": 1,
"type": "С",
"allow_bonus": false,
"places_cnt": 21,
"has_bedding": false,
"reserve_price": 1700,
"services": [],
"prices": {
"А": 35831
},
"coach_type_id": 10,
"coach_class": "2"
},
{
"num": 3,
"type": "С",
"allow_bonus": false,
"places_cnt": 21,
"has_bedding": false,
"reserve_price": 1700,
"services": [],
"prices": {
"А": 35831
},
"coach_type_id": 9,
"coach_class": "2"
}
],
"places_allowed": 8,
"places_max": 8
}


Просмотр свободных мест



Для просмотра свободных мест в выбранном вагоне необходимо выполнить запрос на http://booking.uz.gov.ua/en/purchase/coach/ с телом:



station_id_from=2200001
station_id_till=2218000
train=743К
coach_num=1
coach_class=2
coach_type_id=19
date_dep=1462976400
change_scheme=1


В ответ получаем список свободных мест:



{
"value": {
"places": {
"А": [
"8",
"12",
"16",
"18",
"22",
"27",
"28",
"32",
"33",
"34",
"36",
"37",
"38",
"39",
"42",
"43",
"47",
"48",
"49",
"55",
"56"
]
}
},
"error": null,
"data": null,
"captcha": null
}


Работа с корзиной



Для того, чтобы положить билет в корзину, тем самым зарезервировав его на 15 минут для оплаты, необходимо выполнить запрос на http://booking.uz.gov.ua/en/cart/add/ с телом:



code_station_from:2200007
code_station_to:2218000
train:743К
date:1463580000
round_trip:0
places[0][ord]:0
places[0][coach_num]:5
places[0][coach_class]:2
places[0][coach_type_id]:22
places[0][place_num]:37
places[0][firstname]:Name
places[0][lastname]:Surname
places[0][bedding]:0
places[0][child]:
places[0][stud]:
places[0][transp]:0
places[0][reserve]:0


Мониторинг



Итак, вот мы и добрались до самой интересной части, до мониторинга свободных билетов. Для решения этой задачи был реализован класс UZScanner, который имеет несколько методов:




  • добавить поезд для мониторинга

  • удалить поезд из мониторинга

  • запуск мониторинга

  • остановка мониторинга



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



Мониторинг является асинхронным процессом и выполняется как корутина. В случае успешного резервирования билета, мониторинг выполняет callback, информируя пользователя о результате. Для этого в конструктор класса передается callback-функция.



class UZScanner(object):

def __init__(self, success_cb, delay=60):
self.success_cb = success_cb

self.loop = asyncio.get_event_loop()
self.delay = delay
self.session = aiohttp.ClientSession()
self.client = UZClient(self.session)
self.__state = dict()
self.__running = False


Для того, чтобы вызывающий код различал для какого именно пользователя произошел callback, помимо данных о самом поезде также передаётся callback ID:



def add_item(self, success_cb_id, firstname, lastname, date,
source, destination, train_num, ct_letter=None):
scan_id = uuid4().hex
self.__state[scan_id] = dict(
success_cb_id=success_cb_id,
firstname=firstname,
lastname=lastname,
date=date,
source=source,
destination=destination,
train_num=train_num,
ct_letter=ct_letter,
lock=asyncio.Lock(),
attempts=0,
error=None)
return scan_id


Основная функция мониторинга является циклом, в котором для каждого поезда запускается функция проверки наличия мест.



async def run(self):
self.__running = True
while self.__running:
for scan_id, data in self.__state.items():
asyncio.ensure_future(self.scan(scan_id, data))
await reliable_async_sleep(self.delay)


Сама же функция мониторинга работает по такому алгоритму:




  • Получить список поездов на заданную дату по заданному маршруту

  • Проверить, есть ли нужный поезд

  • Для всех вагонов (либо только для указанного типа) проверить наличие мест

  • Попробовать зарезервировать первое найденное свободное место

  • В случае успеха, выполнить callback, удалить поезд из мониторинга



async def scan(self, scan_id, data):
if data['lock'].locked():
return

async with data['lock']:
data['attempts'] += 1

train = await self.client.fetch_train(
data['date'], data['source'], data['destination'], data['train_num'])
if train is None:
return self.handle_error(
scan_id, data, 'Train {} not found'.format(data['train_num']))

if data['ct_letter']:
coach_type = self.find_coach_type(train, data['ct_letter'])
if coach_type is None:
return self.handle_error(
scan_id, data, 'Coach type {} not found'.format(data['ct_letter']))
coach_types = [coach_type]
else:
coach_types = train.coach_types

session_id = await self.book(train, coach_types, data['firstname'], data['lastname'])
if session_id is None:
return self.handle_error(scan_id, data, 'No available seats')

await self.success_cb(data['success_cb_id'], session_id)
self.abort(scan_id)

@staticmethod
async def book(train, coach_types, firstname, lastname):
with UZClient() as client:
for coach_type in coach_types:
for coach in await client.list_coaches(train, coach_type):
try:
seats = await client.list_seats(train, coach)
except ResponseError:
continue
for seat in seats:
try:
await client.book_seat(train, coach, seat, firstname, lastname)
except ResponseError:
continue
return client.get_session_id()


Заключение



Мы разобрались с API, используемым порталом http://booking.uz.gov.ua и реализовали скрипт резервирования билета. Код доступен на GitHub. Docker image доступен на DockerHub. Также доступен Telegram бот @uz_ticket_bot


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303150/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Количество и качество: как развиваются таск-трекеры в условиях конкуренции

Среда, 08 Июня 2016 г. 18:02 (ссылка)

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



Особенности этой ниши таковы, что бесплатные таск-менеджеры вполне могут конкурировать с платными продуктами, крупные корпорации – с небольшими командами энтузиастов.



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



Корпорация Microsoft запускает новый сервис — Planner. Он станет непосредственным конкурентом популярного таск-менеджера Trello. Сравнивая внешний вид и принцип работы двух сервисов, можно найти много общего.



image

Planner



image

Trello



В Planner используется концепция «досок» (boards), каждая из которых предназначена для отдельного проекта. Внутри «досок» располагаются «карточки» (cards), у которых может быть дата выполнения, вложенные файлы, категории и обсуждения. «Карточки» могут быть организованы по колонкам-«корзинам» (buckets), которым можно присваивать нужный цвет и приоритет.



Основным отличием Planner от конкурентов стала интеграция с другими продуктами Microsoft. Например, обсуждения в сервисе будут доступны и в сервисе Outlook, а файлы из Word, Excel и PowerPoint можно быстро прикреплять к «карточкам». Microsoft обещает добавить Planner в пакеты приложений всех пользователей Office 365 в «ближайшие недели».



Trello



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



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



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



За прошедший год Trello обзавелся поддержкой немецкого, французского, португальского языков. Вышли новые версии Trello Business Class и Trello Enterprise, а также приложение для Android. Изменились оповещения и система меток, которая используется для фильтрации.



image



Кроме того, у сервиса появились возможности создания закладок и перетаскивания адресов для создания карточек с Pinterest, Amazon, Airbnb, а также с компьютера.



За 2015 год некоторые другие таск-менеджеры тоже были доработаны.



Asana



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



image



Появились новые способы ведения бесед и стало больше возможностей использования анимации.



JIRA



image



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



Basecamp



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



image



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



Служба поддержки, которой Basecamp может гордиться, к счастью, не претерпела изменений. Согласно опросу Basecamp, 93 человека из 100 считают ее замечательной.



Redmine



image



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



«Битрикс24»



image



«Битрикс24» за год пережил легкий редизайн сайта и обзавелся новой функциональностью. Так появились новые CRM-формы и обмен файлами, увеличились скорость работы и объем дискового пространства, появилась поддержка португальского и китайского языков.



«Мегаплан»



За прошедший год «Мегаплан» пережил полный редизайн. Из технических возможностей появились интеграция с почтой, подсчет стоимости валютных сделок и автосценарии, повышающие лояльность клиентов. Например, если у клиента день рождения, «Мегаплан» напомнит, что нужно отправить поздравление.



image



Разработчики обновили синхронизацию с «1С», добавили аренду номеров и поддержку внешних звонков и создали фильтры клиентской базы. В мобильном приложении появились полноценные карточки проектов и управление контактами. В режиме альфа-тестирования представлено приложение для Windows Phone.



Wunderlist



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



Поддерживается большинством устройств, среди которых десктопные приложения для Windows и Mac OS, мобильные приложения для устройств на iOS, Android и Windows. Приложение доступно также на iPad, Android tablet, Kindle Fire, Apple Watch и даже Chromebook.



image



Продукт был создан в 2011 году немецкими разработчиками, а в 2015 году куплен компанией Microsoft. В 2014 году Wunderlist достиг результата в 10 миллионов пользователей, а в 2015 году — в 13 миллионов.



Рейтинг таск-менеджеров



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







Возглавил рейтинг специализированных решений для управления задачами «Битрикс24», который использует 51% респондентов. На втором месте сервис Basecamp, который выбирают 27% опрошенных. Третьим по популярности стал Redmine с 25% голосов.











Рейтинги сервисов для автоматизации таск-трекинга проводятся TAGLINE в четвертый раз. Они сформированы на основе анкетирования 510+ digital-агентств и продакшнов с производством и/или клиентским офисом в России (проводилось с августа 2014 по апрель 2016 года).







Динамика приводится по сравнению с данными, полученными TAGLINE за период с мая 2013 по август 2014 года.



Мнения экспертов



По мнению Евгения Лобанова, исполнительного директора компании AGIMA, не обязательно тестировать таск-трекеры, чтобы определиться с выбором, так как разработчики систем дают подробное описание функционала, а интерфейс и механику взаимодействия можно посмотреть на видео:

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


Эксперты сходятся во мнении, что системы управления проектами являются необходимым условием для эффективного распределения времени сотрудников. Дмитрий Провоторов, исполнительный директор компании «Мануфактура», комментирует:

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


Главный редактор TAGLINE Алексей Раменский отмечает:
«Основной тренд — начало осознанного подхода компаний к системному управлению задачами, где таск-менеджер используется не как временная «погремушка», а как концептуальная платформа, чья логика отражается в процессах компании».


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



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



«Главная задача [таск-менеджера] – всегда видеть статус по проектам и не терять задачи в почте или в Skype. Так как мы веб-студия, мне нужен был функционал, заточенный под конкретные запросы», – рассказывает Евгений Кудрявченко, директор по работе с клиентами в Vintage Web Production.



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



Необходимые функции:



• создавать проекты и задачи внутри проекта;

• назначать задачи конкретным людям;

• давать доступ клиентам, чтобы в больших проектах они видели статус и сами ставили задачи;

• диаграмма Ганта – с ее помощью визуально легче понимать, какие задачи в работе и какие выходят за рамки;

• учет времени и возможность выставленная счетов (хотя бы внутренних).



Желательно:



• русский и английский интерфейс;

• интеграция с Dropbox и Google Drive;

• возможность вести wiki по проекту.



«Мы сидим в одном офисе, поэтому чаты, групповые видео и звонки – не в приоритете. Сразу скажу – Redmine и dotProject я даже не рассматривал ввиду убогости и полного отсутствия юзабилити», – заявил он.



Евгений Кудрявченко и прочие эксперты высказали свое мнение еще о нескольких продуктах:


Basecamp (2-е место в рейтинге TAGLINE)

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



Минус – нет задач, а только списки to-do и обсуждения, которые видят все, и на человека можно назначить только to-do. Еще нет учета времени и модуля счетов, и, что мне немаловажно, диаграммы Ганта.



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


Asana (8-е место в рейтинге TAGLINE)

Работает быстро, интерфейс компактный. Много горячих клавиш, что может заметно ускорить работу, если вы их, конечно, запомните. Задачи создаются как расширенные to-do, что тоже неплохо. Но тяжело следить за большим количеством проектов – чтобы найти задачи, нужно открывать каждый проект и просматривать его. К тому же, нет клиентского доступа и учета времени.



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


«Битрикс24» (1-е место в рейтинге TAGLINE)

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


Worksection (9-е место в рейтинге TAGLINE)

Открываешь систему и все сразу понятно, интерфейс простой и логичный. Есть учет времени и возможность выставления счетов. Очень удобная диаграмма Ганта. Легко создавать клиентский доступ. Удобно управлять задачами – сделать видимость для всех или расшарить только избранным. Кроме того, можно подключить свой FTP и хранить там все макеты и дизайны. Сразу видно, сервис делала толковая веб-студия для веб-студий.



Из минусов – интеграция только с Google Drive, но нет с Dropbox и другими сервисами. И нет wiki, но можно делать заметки через Google Docs, например.


Megaplan (5-е место в рейтинге TAGLINE)

Устарел, много лишнего функционала. Зато очень удобная рассылка.


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

https://habrahabr.ru/post/302914/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Делаем собственный сервис по определению WHOIS любого домена

Четверг, 02 Июня 2016 г. 19:26 (ссылка)





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



Итак, давайте разберёмся как это работает.

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

https://habrahabr.ru/post/302494/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Что мешает развиваться автоматизации бизнес-процессов в онлайн-рекрутинге

Среда, 01 Июня 2016 г. 20:24 (ссылка)

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



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



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



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

https://habrahabr.ru/post/302414/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<автоматизация - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda