Octopus что это за программа
Но выход, как водится, есть. Через сторонний софт поверх наэкранных клавиш можно нарисовать консольные, сделать их максимально прозрачными и лицезреть, наконец, матч или гонку во весь экран, щелкая по привычным клавишам игрового контроллера.
И на сегодняшний день я знаю как минимум две программы, на эту роль подходящие. Это Gamepad Panda Pro и Octopus. С первой у меня как-то не заладилось. Во-первых, цена кусачая. За хорошее приложение 150 рублей не жаль, но, судя по отзывам, отличной работой здесь и не пахнет. Во-вторых, для запуска этой софтинки долгое время нужен был рут, что мне совсем не подходит. На данный момент официальная версия из Play Маркета вроде как уже не требует root-прав, судя по описанию, но сломанная из сети все ещё просит. Просто взять и скачать APK-файл тоже не выйдет, приложение будет ругаться на пиратское происхождение, победить которое без дополнительных манипуляций не получится.
Перво-наперво необходимо произвести настройку, то есть подключить свой Google-профиль. Процесс освоения плагина почти ничем не отличается от настройки нового гаджета. Это, конечно, жутко не нравится службам безопасности и на все подключенные к аккаунту девайсы обрушиваются предупреждения о входе в профиль с неизвестного устройства. И это я ещё не говорю о том, что и самому «осьминогу» и его надстройке требуется какое-то безумное количество разрешений, которое не просила у меня ещё ни одна программа. Допустим, мы со всем согласны, всё настроили и хотим поиграть. Что дальше?!
Приложение с ходу распознаёт игру на смартфоне и добавляет её в свой список. Если это не то, во что мы хотим поиграть, можно воспользоваться методом «добавить вручную». Здесь пока все просто и прозрачно. Пробуем запуститься.
Выскакивает предупреждение о том, что нужно обязательно посмотреть видео, с интересной формулировкой: «чтобы получить шанс запустить игру». И эта фраза как нельзя лучше характеризует всё, что происходит потом. Вначале я целых 30 секунд смотрю рекламу какой-то деньговышибательной игры. Ладно хоть не онлайн-казино, и на том спасибо. Появляется крестик, промо-ролик можно закрыть. eFootball PES 2020 не запускается. Черный экран и всё. Ладно, не беда, пробуем снова. Здесь мне вновь надо посмотреть полминутное видео, чтобы опять надеяться на шанс и. Игра стартует. Очень-очень долго висит одна из вступительных заставок, и никаких продвижений. Я, естественно, это дело обрываю. На третий раз, наконец-то, всё заработало. Google Play Игры подцепились, но, несмотря на то, что в симуляторе у меня уже был небольшой прогресс, PES это игнорирует. Игра начинается с нуля, с процесса обучения и всего такого прочего. Мне ещё несказанно везёт, что подготовительные процедуры в eFootball не такие убивающе-долгие, как у некоторых других проектов.
Все вышеперечисленные манипуляции напомнили мне бессмертное пятничное шоу на первом канале под названием «Поле чудес». Там тоже когда-то был сектор «шанс» на барабане (может, и сейчас есть, я просто не в курсе). Кто-то из зала выкрикивал номер телефона. Человек на том конце, конечно, знать не знал, что ему будут звонить с «Поля. «, и начинались тупняки. Потому что ни один игрок из тройки по традиции не помнит задание, а бедный вызываемый даже не знает, что ему ответить. Вот и здешний «шанс» примерно такой же. И это при том, что я оплатил их плагин, вижу рекламу в самом интерфейсе Octopus и ещё тридцать секунд наблюдаю какое-то видео. Все это только ради «шанса».
Кстати, приложение недвусмысленно намекает на то, что лучше взять и установить «Панду», ибо весь рекламный блог в Octopus увешен иконками с этим милым животным. Что говорит либо о том, что у производителей подобного софта какая-то коллаборация, либо это вообще один и тот же разработчик. Что убивает и без того бьющийся в конвульсиях принцип здоровой конкуренции.
А теперь допустим, что все вышеупомянутые процедуры пройдены. Мы успешно вошли в игру под своим профилем, каков же сам игровой процесс?
Уже со стартовой заставки видно, как Octopus безошибочно подхватил клавиши от моего Xbox-контроллера, расположив четвёрку нарисованных кнопок справа. Эти накорябанные поверх интерфейса элементы миниатюрны и наполовину просвечивают. При желании их можно сделать ещё менее заметными, передвинув ползунок прозрачности. Слева одиноко расположился виртуальный стик, который полностью прячется и всплывает лишь в момент подстройки нарисованного геймпада.
Сверху кадра чуть выглядывает осьминог, который открывает нам небольшое меню. В нем можно скрыть начертание кнопок контроллера, в тех случаях, когда они покажутся лишними.
Нарисованные элементы легко двигаются по экрану и в случае необходимости переназначаются. Важно, чтобы при этом интерфейсные элементы самой игры тоже хоть немного просвечивали, ну или их прозрачность как-то настраивалась, ибо их-то никуда не сдвинешь.
Если консольных кнопок не хватает, их можно добавить, выбрав вначале специфику виртуального аналога: крестовина, стик, либо просто клавиша.
В настройках самого приложения можно, в случае чего, произвести калибровку геймпада, но мне этого не потребовалось. Могу допустить, что какому-нибудь ноунейму с АлиЭкспресса понадобится донастройка. Официальный Xbox Controller работает как надо сразу, без дополнительных манипуляций.
Поиграв с Octopus несколько дней, я в общем-то привык ко всем его, скажем так, компромиссам. Мой футбол, на удивление, стал относительно стабильно запускаться из приложения с осьминогом, а чтобы глаза не резал вступительный ролик, можно воспользоваться проверенным народным средством. Что мы обычно делаем с бесплатными играми, чтоб их реклама не раздражала?! Правильно, выключаем интернет. Естественно, что многие игры завязаны на онлайне и таких проектов, которым помогло бы отключение от сети, в Google Play всё меньше, но с Octopus дедовский способ ещё прокатывает. Запускаю «осьминога» без связи с внешним миром и щелкаю на игру. Как только вижу первые кадры вступительной заставки, это значит, что всё получилось, достаточно просто опустить шторку и включить Wi-Fi. Допускаю, что не каждая игра так сможет, но PES два раза из трёх стартует, что для меня в принципе удовлетворительно.
Но что поделать, такой я старый любитель компьютерного футбола. Хочу перемещать игроков по полю с контроллера, не принимая нового прогрессивного управления мобильных симуляторов или просто не желая до конца к нему привыкать. Потому, хоть и ворчу, но «осьминогом» пользоваться продолжаю. Это ни в коем случае не значит, что я сейчас буду его кому-то рекомендовать, нет! Наоборот, не советую скачивать эту софтинку, обойтись и привыкнуть к тому, что есть. Пусть приложение живёт само по себе, а мы с вами просто будем иметь в виду, что есть и такой способ поиграть на смартфоне. Если неймется, можно загрузить; попробовать, побаловаться, поразвлекаться. а потом снести, с глаз долой и без тени сомнения.
Введение в Octopus Deploy
Continuous Integration и Continuous Delivery де-факто являются неотъемлемой частью современной разработки проектов. Для автоматизации CI существует множество программ от различных вендоров, а вот с автоматизированием развертывания приложений дела обстоят скромнее. Одним из помощников развертывания является Octopus Deploy.
Введение
Давайте рассмотрим распространенный подход в процессе разработки. Разработчики пишут код, прогоняют unit-тесты по затронутому коду, делают commit. И делают это как можно чаще, согласно идеологии CI. Далее CI приложение (TeamCity, TFS, Jenkins, Bamboo, или другое любимое в вашей команде) собирает приложение и прогоняет автоматические тесты.
Наступает момент, когда пора отдать приложение на ручное тестирование и член команды (DevOps) развертывает приложение для тестеров.
А вот и следующий момент, пора отдавать на тестирование заказчику (User Acceptance Test или Staging).
Ну и после зеленого сигнала от заказчика наступает главный по значимости момент, публикация приложение в production. Причем часто заказчик ожидает, что если что-то пойдет не так в production’e, то ваша команда сможет откатить все изменения щелчком пальца, максимум в течение получаса.
Устройство Octopus
Осьминожка использует Octopus Server, который забирает NuGet пакеты с приложениями. Забирать их может автоматически из NuGet репозитория, подписавшись на NuGet Feed CI сервера по http/https, или из обычной папки на сервере. Как правило NuGet пакет должен содержать полное приложение, например ваш полный ASP.NET Web сайт, или все файлы необходимые для установки Windows Service’a.
Дотягивается Octopus до серверов публикации с помощью щупалец. Tentacle Agent представляет собой легковесную программу, которая запускается в виде Windows Service’a, забирает Nuget пакет с Octopus Server’a и разворачивает приложение. Есть режим общения pull и push, т.е. Tentacle периодически опрашивает сервер на новые пакеты, или Tentacle ждет сигнала от сервера и сервер push’ит. Octopus Server также запускается в виде Windows сервиса, и общается со своими щупальцами через защищенной HTTPS (TLS и X.509 сертификат). Для большей безопасности при установке Octopus необходимо настроить каким Tentacle агентам доверяет сервер и наоборот.
В текущей версии 2.0 для хранения всех данных используется встроенная база данных RavenDB, но по ряду причин в новой версии 3.0 перейдут на MS SQL Server. Кстати новая версия выйдет в ближайшие месяцы, хотя согласно политике компании у вас будет возможность обновиться до новой версии в ближайший год после покупки, после года вас не бросает на полный произвол и дают скачать критические обновления бесплатно, но уже, конечно, без новых фитч.
Среда, роли и приложения
Остановимся немного подробнее на структуре, которая может получится.
У нас три environment’a (Test, Staging и Production). Шесть серверов, на которые установлены Tentacles и куда будет устанавливаться приложение. И две роли: octo-web и octo-app. Создание ролей очень удобно, например можно указать: установить сайт только на машины, у которых есть роль octo-web, а приложение только на машины с ролью octo-app. Заметьте, что для тестирования отведен один сервер, на котором будет находится и сайт, и приложение. А на production целых три сервера, один под приложение, и два под сайт. Это очень реалистичный сценарий с развертыванием двух копий сайта (без базы данных) и последующим запуском балансировщика.
Приложение OctoFX, с ролью octo-app, будет выглядеть следующим образом:
Жизненный цикл приложения будет заключаться в прохождении Test среды, далее Staging, а затем запуска на Production.
Настройки очень широкие и можно выбирать доступные среды для разных приложений.
Шаги и переменные
Переменные
Переменные вынесены в отдельный блок и позволяют модифицировать значение в зависимости от среды, роли или имени сервера.
Рассмотрим пример с Хабром, если нам необходимы разные значения для адреса нашего сайта и мы хотим поменять переменную в web config’e, то достаточно ее добавить в блок
Тогда config файл
может быть автоматически трансформирован в Dev среде в
Удобнее всего хранить в переменных пароли, так как Octopus их шифрует и не позволяет скопировать или увидеть в дальнейшем в панели Variables. Существует возможность создать пользователей и ограничить доступ в средам. Таким образом с помощью блока переменных и ограничения доступа пользователям можно сделать так, что только администратор или Release менеджер может развернуть приложение в Production и соответсвенно увидеть пароли в конечном варианте config файла.
Имеются и специальные системные переменные. Их можно использовать также, как и пользовательские переменные, т.е. в PowerShell скриптах или Config файлах. Например, один из наших клиентов использует Umbraco сайт. Конечно в NuGet пакет имеет смысл складывать только исполняемую часть сайта, а не Гигабайты медиа контента. При обновлении сайта Octopus создает новую папку, т.е. на самом деле новый сайт, например, кладет его в папку \Octopus\Applications\UmracoSite\1.20.0\. И мы копируем с помощью PowerShell скрипта и переменной Octopus.Deployment.PreviousSuccessful.Id весь media контент из старой версии сайта в новую.
Заключение
До сих пор я встречаю ручной бэкап базы данных перед развертыванием приложения, ручное изменение config файлов, множество вариантов самописных скриптов, которые хранятся локально и отличаются у программистов и системных администраторов, и даже ручное копирование папки приложения в production и test environment.
Попробуйте минимизировать человеческий фактор и рутину в этом процессе. И удачного вам deployment’a!
Octopus Deploy. Улучшаем мир в кровавом энтерпрайзе
Сегодня я хочу рассказать о системе деплоя Octopus Deploy. На данный момент на Хабре есть всего одна вводная статья на эту тему, поэтому в своем материале я хочу расширить описание системы, подробнее рассказать о таких важных понятиях как «жизненные циклы» (lifecycles) и «каналы» (channels), а также о том, как мы внедрили и используем Octopus в своей работе.
Кто мы
Проблемы старого процесса деплоя
Когда я пришел в Тинькофф, деплой системы проводился с помощью TeamCity: использовался MSDeploy и n-ное количество powershell-скриптов различной сложности. Билд конфигурации, отвечающий за сборку проекта, и деплой были сгруппированы по имевшимся на тот момент контурам: QA и Prod.
Старый процесс сборки и деплоя на каждый контур можно условно представить следующим образом: собираем проект для заданного окружения (применяем соответствующие трансформации xml конфигов) → собираем полученные артефакты в несколько zip-файлов (по одному на каждое отдельно развертываемое приложение + скрипты миграции БД + скрипты деплоя) → деплоим на заданные для данного окружения сервера.
Так как в работе мы используем по несколько серверов для отказоустойчивости и распределения нагрузки, то процесс деплоя занимал приличное количество времени, потому что шёл последовательно по приложениям и серверам (писать на PowerShell параллельные асинхронные задачи довольно болезненно). С добавлением дополнительных контуров QA2 и Preprod количество билд-конфигураций росло, управление настройками деплоев через разрозненные параметры усложнялось.
Мы хотели унифицировать процесс деплоя на различные контуры, по возможности ускорить его, а также стандартизировать процесс доставки релизов в зависимости от их типа в принятой у нас системе версионирования: мажорные релизы должны проходить контуры QA → Pre → Prod, минорные — QA2 → Pre → Prod, хотфиксы — Pre → Prod.
Во всех этих хотелках нам помог Octopus Deploy. Вот основные плюсы, которые мы получили, внедрив его в наш процесс доставки релизов:
Установка и настройка
Установка самой системы проста и прямолинейна: из внешних зависимостей необходим только MS SQL Server для хранения базы данных. Плюс к этому на каждый сервер, на который вы собираетесь деплоить, необходимо установить агент Octopus Tentacle.
Его установка отлично автоматизируется, что убирает лишнюю ручную работу и позволяет подготавливать новые сервера к деплою. Для этого мы используем Ansible, и после установки самого приложения его настройка выполняется вот таким вот powershell-скриптом:
В результате, после создания нового сервера, он автоматически регистрируется в октопусе и на него сразу же можно деплоить. Очень удобно.
Жизненные циклы
Одной из ключевых сущностей в Octopus Deploy являются жизненные циклы (lifecycles). Они используются как для автоматического промотирования релиза между окружениями, так и для ограничения окружений, на которые может быть развернуто приложение до прохождения соответствующего тестирования.
Например, для мажорных версий жизненный цикл системы у нас определен как QA → Pre → Prod. Это означает, что мы не сможем задеплоить версию в продакшен до того, как она побывает на тестовом и препрод контурах. С другой стороны, жизненный цикл патч-версий короче: Pre → Prod, т.к. они тестируются сразу на препроде.
Каналы
С помощью каналов (channels) в Octopus можно независимо развертывать несколько версий одного проекта. Помимо правил, ограничивающих версии пакетов, для каждого канала можно указать используемый для промотирования релизов жизненный цикл, настроить процесс развертывания (т.к. у каждого шага имеется настройка, для каких каналов он должен быть выполнен), а также определить значения переменных. Каждый создаваемый в Octopus Deploy релиз обязательно относится к какому-либо каналу.
В нашем проекте у нас есть каналы для мажорных, минорных, патч-версий, а также специализированные каналы для прямого вывода на бой хотфиксов и развертывания экземпляра системы для интеграционного тестирования.
Основная прелесть заключается в возможности автоматического создания релизов в нужных каналах. Для этого в свойствах канала мы указываем диапазон версий пакетов (а также можем использовать тэги SemVer), которые нужно использовать для создания релиза в этом канале. Octopus автоматически выберет пакеты, имеющие самую последнюю версию.
Предположим, что в данный момент ведется тестирование версий V10.1 и V11.0. После сборки проекта из ветки V10.1 TeamCity зальет собранные пакеты (версия пакетов будет 10.1.0.xxxx) в Octopus и вызовет создание релиза в канале «минорных» релизов. При этом в релиз попадут именно пакеты версии 10.1.0.xxxx, несмотря на то, что в Octopus уже есть более новые пакеты с версией 11.0.0.yyyy, т.к. в Version Range у канала «минорных» релизов указан диапазон [10.1.0.00000, 10.1.0.99999).
Таким образом, различные версии приложения отлично сосуществуют друг с другом в каналах и следуют своему собственному процессу развертывания на различные окружения.
Вот пример того, как это выглядит на панели управления проектом:
Важно! Если вы добавляете новые шаги в процесс деплоя, добавьте новые пакеты в правила каналов. Если для какого-либо пакета в канале не задано ограничение по версии, Octopus будет использовать самую последнюю версию пакета. Может случиться так, что вы задеплоите приложение версии 10.1, но один пакет будет, например, версии 11.0, если он уже есть в Octopus.
Создание NuGet пакетов
Создавать пакеты для деплоя во время сборки проектов можно с помощью инструмента Octopack. Он устанавливается в необходимые проекты как NuGet-пакет, и если вас устраивают настройки по умолчанию, больше делать ничего не нужно.
Интеграция с TeamCity
Но самое интересное начинается при автоматизации процессов создания (и деплоя) релизов после сборки проекта на TeamCity. Вот как этот процесс выглядит у нас:
Guided Failures
Если в процессе деплоя на одном из шагов происходит ошибка, весь деплой останавливается и помечается упавшим. Такое поведение не всегда актуально: иногда мы готовы смириться с проблемами на некоторых шагах деплоя. Для этих случаев существует режим под названием Guided Failures.
Если он включен, и во время деплоя происходит ошибка, Octopus приостанавливает все операции и отображает специальное окно. В нем можно указать результаты расследования и решить, нужно ли продолжать процесс деплоя или нет. В истории деплоя останется пометка о том, кто, когда и какое решение принял.
Скрипты деплоя в пакетах
Иногда перед деплоем приложений и сервисов мы хотим выполнить дополнительные действия. Например, убедиться, что приложение сможет получить доступ к порту при запуске от имени сервисной учетной записи. Это можно сделать, используя дополнительные установочные скрипты, которые могут написаны как в веб-интерфейсе Octopus, так и быть частью пакета разворачиваемого приложения.
Пример пре-деплой скрипта, который удаляет и добавляет резервирование порта для одного из наших сервисов
Retention policy
Чтобы однажды не оказаться в ситуации с полностью заполненным жестким диском, в Octopus предусмотрен механизм для удаления пакетов, которые использовались в старых релизах и больше не нужны.
Политика хранения пакетов описывается на уровне жизненного цикла, но ее можно переопредить для отдельных его фаз. Так, например, для всех фаз деплоя приложения на тестовые окружения мы храним только одну последнюю версию пакета.
Для боевого окружения мы переопределяем эту настройку и храним пакеты для пяти последних релизов (на случай, если вдруг придется откатываться). Также можно указать, для каких релизов хранить пакеты на самих машинах. В случае отката можно провести деплой быстрее, не тратя время на повторное скачивание пакетов с сервера Octopus.
Дополнительные ништяки
В этом разделе хочу поделиться некоторыми powershell-скриптами, которые мы используем у себя в системе. Вы можете использовать их как есть или как пример для реализации собственных идей.
Заключение
Мы очень рады, что год назад начали использовать Octopus Deploy, и после непродолжительного периода тестовой эксплуатации полностью перешли на него для развертывания системы на всех наших окружениях.
В следующей статье я расскажу про multi-tenant deployments, которые мы используем для организации процесса развертывания фича бранчей на отдельные виртуалки, автоматически поднимаемые в локальном облаке OpenStack, для проведения изолированного тестирования отдельных задач.
Octopus что это за программа
Краткое описание:
удобная настройка геймпада/мышки+клавиатуры для игр
Играйте в Android игры используя геймпады, мышку и клавиатуру!
Переназначь управление с тачскрина на свои переферийные устройства. Активаторы и root не нужны.
— Совместимость с переферийными устройствами
Octopus поддерживает геймпады, клавиатуры и мышки.
— Предустановленные настройки
Предустановленные конфигурации кнопок для более чем 30 поддерживаемых игр, сохраняя возможность настройки.
— Облачная синхронизация
Твои настройки сохраняются в облаке вместе с твоим аккаунтом Octopus. Не нужно беспокоиться насчет потери настроек при удалении игры или смене устройства.
— Одно приложение решает все
После подключения переферии зайди в Octopus и запусти игру, никаких активаторов и root прав.
Переназначь любую кнопку так, как хочешь, синхронизируйся через облако.
Требуется Android: 4.4 и выше
Русский интерфейс: Нет
Версия: 4.4.2 Octopus (Sasha2x2)
Версия: 4.3.5 Ad-Free by Jenny Of Oldstones (moorware)
Версия: 4.2.8 build.428 (Sasha2x2)
Версия: 3.2.9 [Ad Free] Octopus (Пост Alex0047 #79510180)
Версия 3.1.0 Сообщение №546, автор cowboy335
Версия 3.0.0 Rus Сообщение №406, автор Wolf122003
Версия 3.0.1 Octopus (Пост cowboy335 #76833926)
Версия 2.4.1 Сообщение №434, автор cowboy335
Версия 2.3.1 Сообщение №420, автор cowboy335
Версия 2.3.0
1.2.0 
com.chaozhuo.gameassistant.apk ( 6.33 МБ )
1.3.0 com.chaozhuo.gameassistant1.apk ( 6.83 МБ )