Здравствуйте уважаемые участники ИТ сообщества. Меня зовут Олег, я работаю в компании, которая занимается разработкой ПО. Я занимаюсь ручным и автоматизированным тестированием Linux и Unix продуктов и я хотел бы поделиться положительным опытом автоматизированного тестирования в Openshift Origin.

Цели, которые я преследую:

1. Донести до русскоязычного сообщества особенности работы с Openshift Origin в контексте тестирования.
2. Рассказать о преимуществах и недостатках тестирования в контейнерах.
3. Агрегировать и актуализировать свои знания о Kubernetes/Openshift.

Весь материал изложен в трёх статьях:

1. Тестирование в Openshift: Введение
2. Тестирование в Openshift: Внутреннее устройство кластера
3. Тестирование в Openshift: Автоматизированное тестирование

Примечание: хотелось бы сразу заметить, что излагаемый материал касается Openshift v3, а не Openshift v2 (когда компания Red Hat еще не начала использовать Kubernetes в качестве ядра для своих продуктов и сервисов).

Привет, хабрапользователь! Сегодня я попробую представить тебе очередную статью о докере. Зачем я это делаю, если таких статей уже множество? Ответов здесь несколько. Во-первых не все они описывают то, что мне самому бы очень пригодилось в самом начале моего пути изучения докера. Во-вторых хотелось бы дать людям к теории немного практики прямо по этой теории. Одна из немаловажных причин — уложить весь накопленный за этот недолгий период изучения докера опыт (я работаю с ним чуть более полугода) в какой-то сформированный формат, до конца разложив для себя все по-полочкам. Ну и в конце-концов излить душу, описывая некоторые грабли на которые я уже наступил (дать советы о них) и вилы, решение которых в докере просто не предусмотрено из коробки и о проблемах которых стоило бы задуматься на этапе когда вас распирает от острого желания перевести весь мир вокруг себя в контейнеры до осознавания что не для всех вещей эта технология годна.

Что мы будем рассматривать в данной статье?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие

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


Материал подготовлен специально для блога @Конференции Олега Бунина (Онтико) на основе моего доклада на RootConf 2017.

Начало истории вы можете вспомнить в первой статье, я же кратко напомню, что происходит.

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

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

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

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

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

Шаблоны проектирования Cucumber BDD сценариев

Цели:

• получить готовый инструмент, при помощи которого станет возможным стандартизировать процессы разработки и контроля качества исполняемых сценариев, построенных для работы в Cucumber-based технологических стеках (cucubmer jvm, SpecFlow и проч.)
• получить набор правил, позволяющих специалистам с разных проектов легко мигрировать между проектами без длительной фазы привыкания
• получить чистый, легко-читаемый код сценариев, который легко расширяется и слабо подвержен полным переписываниям текстов сценариев при минимальных изменениях UI

Итак, поехали!

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

В данной статье мы рассмотрим один из самых популярных фреймворков для автоматизации тестирования с использованием BDD-подхода – Cucumber. Также посмотрим, как он работает и какие средства предоставляет.

Эта статья также есть на английском.

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

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

Под катом — дюжина приемов в командной строке — из личного опыта.

Вот один из пользователей «следующего миллиарда»:



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

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

Первое и главное — мы отбираем хлеб у очень-очень многих. 12–14 миллиардов долларов — рынок бирж фриланса, 135 миллиардов — аутсорса для розницы, 40 миллиардов — переводов и журналистики, 150 миллиардов — удалённого обучения и персональных консультаций, а ещё есть психотерапия, телемедицина и прочее-прочее прочее.

Это всё наш рынок, потому что вы можете найти в системе нужного человека и купить 15–20 минут его времени, чтобы он показал вам, как у них в Индонезии готовят рыбу, либо ответил на пару вопросов по C++. Ну, либо сделал для вас кран, что более вероятно. Мы трезво понимаем, что в ближайшие 3–5 лет больше 5% даже рынка фриланса не занять — но всё же угрозу мы создаём кое -для кого серьёзную.

Эдуард Тянтов (Mail.ru Group)

Меня зовут Эдуард Тянтов, я занимаюсь машинным обучением в компании Mail.ru Group. Я расскажу про приложение стилизации видео с помощью нейронных сетей Artisto, про технологию, которая лежит в основе этого приложения.

Давайте я дам пару фактов о нашем приложении:

• 1-е мобильное приложение стилизации видео в мире;
• Уникальная технология стабилизации видео;
• Приложение с технологией разработаны за 1 месяц.

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

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

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

И тут кто-то произносит слово «автотесты».

И сразу начинается: это целая история, это очень сложно, это очень дорого, от этого будет больше вреда, чем пользы и вообще это кровавый Enterprise и СЕЛЕНИУМ.

Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.

Прежде чем начну рассказывать про сам selenium grid и все, что связано с ним, я хочу пояснить суть проблемы, которую мы пытались решить.

В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline.

Захотелось поделиться с вами моим способом тестирования веб-сервисов.

Принцип такой:

1. Создаем maven проект.
2. Настраиваем его так, чтобы с каждым запуском выполнялось следующее:
2.1. загружалось WSDL описание сервиса по ссылке
2.2. генерировался код клиента на основе WSDL описания
2.3. генерировался код ассертов для классов, участвующих в проверках, в том числе тех, которые были сгенерированы на предыдущем этапе
3. Пишем тесты.
4. Добавляем проект в jenkins, который и запускает само тестирование.

Нам понадобятся следующие инструменты: Java, maven, AssertJ, TestNG.

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

Добрый день!

Про утилиту сборки для Java-проектов Maven и про возможность создания локального сервера для Maven-репозитория с помощью Sonatype Nexus на Хабре уже упоминали (тут и тут). Однако, никакого рецепта по этому поводу представлено не было. Это неудивительно при наличии достаточно полной грамотной документации. По долгу службы мне пришлось настраивать его на нашей фирме, и оказалось, что советы из официальной документации не совсем подходят. Возникшей проблемой и способом ее решения я и хочу поделиться с сообществом. Но обо всем по порядку.

Зачем это нужно?

Локальный сервер для Maven-репозитория (как, например, Sonatype Nexus) может быть использован для хранения локальных артефактов Maven, и действительно пригодится командам, которые разрабатывают модульные приложения, но не собираются публиковать модули в общий доступ.

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

В проекте, над которым я работаю, мы используем огромное количество сторонних библиотек. Многие из них — адаптеры для различных сервисов. Что их объединяет, это то, что они работают с сетью. Json поверх http, soap поверх http, какие-то свои протоколы поверх http. Т.е. все так или иначе используют http. И как ни удивительно, мало кто из них пользуется преимуществами его последней версии. Я не поленился заглянуть в википедию, прошло ровно 14 лет как была принята спецификация http 1.1. И потому я решил обратиться с призывом:


Да, речь пойдет о keep alive. Суть в том, что, начиная с http 1.1, клиент и сервер могут договориться не закрывать установленное tcp-соединение после завершения запроса, а переиспользовать его для следующих запросов. Это нужно потому, что на установку соединения требуется время. Иногда это время больше, чем время самого запроса. И если все серверы уже давным-давно такую возможность поддерживают, а все браузеры и большинство других клиентов её используют, то у разработчиков различных библиотек для популярных языков программирования здесь почему-то пробел.

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

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

Введение

Думаю, не ошибусь сильно, если у большинства из нас подключение к интернету выглядит следующим образом: есть некоторый довольно скоростной проводной канал до квартиры (сейчас уже и гигабит не редкость), а в квартире его встречает роутер, который раздаёт этот интернет клиентам, выдавая им «чёрный» ip и осуществляя трансляцию адресов.

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

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

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

С чего все начиналось

Все началось с того, что я захотел установить у себя «умную» систему видеонаблюдения на Raspberry.

Хочу отдельно отметить, что для этого воспользовался несколькими статьями на Хабре. Спасибо авторам за их посты. Они реально помогли.

В итоге установил на купленном Raspberry Pi3 USB-камеру Logitech, смонтировал Яндекс.Диск и с периодичностью в 30 секунд делал снимки, которые затем копировал в папку на Яндекс.Диске.
Поигравшись с дальнейшем архивированием файлов, монтированием из отдельных снимков видео, забросил новую «игрушку» на несколько месяцев.

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

Превращаем планирование в точную науку

Как определить вектор развития продукта и совместить его полезность и инновационность? Для того, чтобы наши новые разработки с большей вероятностью «попали в цель», было принято решение провести глубокое исследование и на основе его результатов запланировать новую версию. Определением стратегии развития Macroscop занимается product-менеджер компании, и вот по какому алгоритму действовал он: