ИТ-рецепты

Home/ИТ-рецепты

Занятия английским языком

Обязательное условие для успешной профессиональной деятельности – владение английским языком.

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

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

Настройка непрерывной интеграции в TeamCity для Xamarin.iOS

Значение непрерывной интеграции (Continuous Integration) в разработке программного обеспечения в настоящее время является по-настоящему важным. Существует масса продуктов для применения этого подхода на практике: Hudson/Jenkins, Bamboo и многие другие. По разным, не столь существенным для нижеизложенного, причинам нами был выбран продукт TeamCity на примере которого будет продемонстрирован запуск непрерывной интеграции для мобильных проектов под  Xamarin.iOS. С некоторыми изменениями и доработками приведенный способ может быть применен и в других системах.

TeamCity «из коробки» умеет  поддерживать компиляцию C# проектов под Mono, однако с Monotouch (Xamarin.iOS) не все просто с самого начала — заставить TeamCity собрать мобильное приложение для iPhone можно только из командной строки c помощью mdtool. Такой рецепт можно найти, например, на stackoverflow. Проект нормально собирается в TeamCity, и в некотором смысле непрерывная интеграция настроена. Уже можно отслеживать как изменения в хранилище (в нашем случае Mercurial, хотя здесь это не принципиально) отражаются на успешности сборки проекта. TeamCity сообщает удалось  или не удалось собрать проект.

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

Необходимые составляющие:

1. Компьютер с OS X на котором установлен:

1.1. Xamarin.iOS со всеми зависимостями.

1.2.  TeamCity Build Agent.

1.3. Mercurial и/или SourceTree

2. Сервер с установленным  TeamCity и подключенным агентом (см 1.2).

3. Тестовый проект в хранилище. https://bitbucket.org/apalkoff/nunitliteteamcity

Первый шаг — добавление проекта в TeamCity

A) Создаем новый Build Configuration и добавляем в качестве VCS Root хранилище на Bitbucket — все стандартно.

B) Добавляем к Build Configuration первый Build Step — Command Line.

commandline_build3

После этого можно попробовать запустить сборку в TeamCity и удостовериться, что проект собирается.

Второй шаг — подготовка проекта к тестированию

При тестирование проектов с Xamarin.Ios применяется не стандартный NUnit, а модифицированная версия NUnitLite. На сайте Xamarin привидена подробная инструкция по настройке тестирования. Поскольку тесты выполняются прямо на устройстве, то тестовый проект представляет собой специальное приложение, которое запускает необходимые тесты.

testrunneroniphone

Каким же образом можно забрать результаты тестирования из устройства/эмулятора в TeamCity? Ключевой момент состоит в использовании Touch.Server, который умеет обмениваться информацией с программой, запускающей тесты.

Проще всего скопировать хранилище Touch.Server c GitHub’а на локальную машину, сбилдить Touch.Server.exe и добавить его к нашему хранилищу, например, в папочку 3rdparty. В этом случае появится возможность настроить TeamCity на запуск этой программки в качестве одного из Build Step’ов. Подробное описание Touch.Server можно найти в блоге spouliot.

В нашем случае запуск Touch.Server будем осуществлять таким образом:

mono --debug 3rdparty/Touch.Server.exe --launchsim \
Tests/bin/iPhoneSimulator/Debug/Tests.app -autoexit -logfile=TestProject.xml

При запуске на локальной машине получим в TestProject.xml вот что:

testlog

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

С) Необходимо внести изменения в код UnitTestAppDelegate.cs:

codemodification

После ребилда повторим запуск Touch.Server.exe:

testxml

Теперь совсем все хорошо, кроме двух первых строк, которые портят красивый xml. Не будем обращать на них внимание — их можно будет легко убрать с помощью утилиты sed.

Третий шаг — тестирование в TeamCity

D) Добавляем к Build Configuration второй Build Step, тоже Command Line.

commandlinetestingТеперь после билда (в папочке проекта, в файле TestProject.xml) будут находиться результаты тестирования. Осталось только объяснить TeamCity, что надо на них посмотреть.

E) Добавляем к Build Configuration в раздел Build Features XML-обработчик:

xmlprocessing

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

Применение BitTorrent Sync

Проект BitTorrent Sync безусловно заслуживает пристального внимания. Возможность синхронизации папок на разных компьютерах и устройствах без использования центрального сервера очень хороша с точки зрения безопасности и контроля. Так что же, BTSync вытеснит и заменит Dropbox, Yandex Диск, Google Drive и другие похожие сервисы?

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

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

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

Отметим, что существуют приложения BTSync для iOS и Android, можно получить доступ к API для встраивания в собственные приложения.

По нашему мнению эра классических торрентов и сервисов синхронизации с центральным сервером подходит к концу.

 

Перенос серверов на DigitalOcean

Уже на протяжении нескольких лет компания использует ряд виртуальных серверов для решения как внутренних, так и потребительских задач. Все началось в 2009 году с сервра на площадке keyweb, продолжилось в виде нескольких машин на Selectel и продолжилось с переездом на DigitalOcean.

Не будем распространяться про минусы прежних хостеров, а приведем плюсы последнего — DigitalOcean (DO):

  1. К переходу подтолкнуло появление у DO дата-центра в Амстердаме, ходить до которого можно за вполне приемлемое время.
  2. Весьма приятная стоимость. Машинка минимальной конфигурации (512MB ОЗУ, 1 ядро, 20GB на диске, 1TB трафика в месяц) стоит всего 5$.
  3. Немаловажным оказалась прозрачность ценообразования, которое позволяет точно планировать расходы на ту или инау виртуальную машину.
  4. Подключаемая возможность делать автоматические периодические полные бэкапы на лету (за 20% стоимости виртуального сервера).
  5. На всех тарифных планах без исключения используются SSD-диски.
  6. Удобная панель управления.
  7. Есть и другие плюсы, но для нашего случая не столь ценны.

Перенос сервисов прошел как и планировалось. Более длинный маршрут субъективно не привел к замедлениям в ответах на запросы.

Раздумывать нечего — пробуй!

Перейти на DigitalOcean.

Организация вывода рабочего стола (за NAT) через защищенный туннель

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

  1. Имеются две машины (Windows) подключенные к интернету.
  2. Одна из них (скажем, зеленая) имеет белый ip или находится за контролируемым оборудованием с белым ip.
  3. Вторая машина (скажем, синяя) находится в серой сети, в которой имеется доступ к интернету, однако шлюз неконтролируемый и порт-форвардинг не возможен. Вероятно также вместе со шлюзом установлен фаерволл — исходящие соединения разрешены только на 80 (http) и 443 (https) порты.
  4. Необходимо обеспечить доступ к рабочему столу синей машины с зеленой.


Тривиальное и безыскусное.

Использовать TeamViewer. Минус — неконтролируемый третий сервер (сервера) в интернете.

Слишком сложное, туннель сеть-сеть.

Организовать туннель от синей машины к зеленой, в нем проложить ppp, назначить соответствующие адреса, прописать роутинг, воспользоваться стандартными средствами, вроде rdp. Минус – слишком сложное решение для поставленной задачи.

Правильное

Организовать туннель от синей машины к зеленой (stunnel), воспользоваться возможностью VNC по инициации соединения от сервера (чей рабочий стол будет передаваться) к клиенту (где рабочий стол будет показываться).

(далее…)