Привет, Хабр! Меня зовут Оля, и я старший инженер по тестированию в Lineate. Хочу рассказать о своей попытке осознать SOLID принципы и понять, где их место в автоматизированном тестировании. 

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

Соответственно, этот материал состоит из двух частей:

- в первой возьмем простое приложение на Java и улучшим его с помощью SOLID принципов - от программы с парой классов, которые делают все подряд, дойдем до приложения, разбитого на несколько модулей с конкретными функциями (да, это еще одно объяснение SOLID - смело пропускайте, если уже и так представляете о чем это);

- во второй части посмотрим, где во фреймворках автоматизированного тестирования может использоваться SOLID.

“Мои сотрудники всегда счастливы, но времени на работу у них не хватает”.

“Мои сотрудники работают хорошо, но не выглядят довольными”.

Знакомо? Наверняка! Так бывает, когда мы ошибаемся с необходимым уровнем внимания к сотрудникам.

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

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

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

Хотите разобраться, как должен выглядеть правильный people management? Прошу под кат!

В предыдущих частях я сделал приложения, которое работает с БД, GitHub API. Все компоненты разворачиваются при помощи AWS SAM. Можно запускать реализованные функции локально. Все функции собраны воедино в одно API:

Первые шаги. Первая лямбда (Часть 1)

Разворачиваем БД (Часть 2)

Как подружиться с БД (Часть 3)

Создаем REST API (Часть 4)

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

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

В предыдущих частях я сделал кубики, из которых состоит serverless приложение:

Часть 1. Первые шаги. Первая лямбда

Часть 2. Разворачиваем БД

Часть 3. Как подружиться с БД

Реализовано 4 функции, развернута БД. Функции интегрированы с БД, запускаются локально в режиме отладки. Вся инфраструктура поднимается буквально с помощью нескольких SAM команд.

Но пока это мало похоже на какое-то целостное приложение, т.к. у приложения нет API. Мои лямбда функции не умеют обрабатывать http запросы. Так что  в этой части займусь вопросами, связанными с построениями настоящего API. Также сделаю интеграцию с github api.

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

В этой части я напишу код лямбда функции, который будет взаимодействовать с БД. Этот код по-прежнему будет запускаться локально в режиме отладки. Вместе с первой настоящей логикой появятся первые юнит тесты. Для удобства при развертывании кода в этой части я буду использовать отдельный стек serverless-bugtracker-ch3.

«Какой план на неделю? Я не знаю, чем сегодня день закончится!»

«Да зачем планировать, если все равно ничего не понятно!»

Знакомо? Наверняка! Эта та реальность, в которой мы сейчас находимся. Уровень неопределенности просто зашкаливает, и горизонт планирования сокращается, в лучшем случае, до нескольких дней, а иногда и до нескольких часов.

Но планировать можно. Более того, я скажу, что планировать НУЖНО! Это позволяет вам не только управлять ситуацией, но и значительно понижает ваш собственный уровень тревоги. Как это работает, какие есть подходы и инструменты для такого планирования - прошу под кат, все расскажу в этой статье.

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

Эта лямбда работает в облаке, может запускаться локально. Сегодня я займусь базой данных. Я буду концентрироваться на подготовке окружения для БД и её развертывании в облаке. Тут не будет кодинга на nodejs, но будет много SAM/Cloudformation кода.

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

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

Преимущества выглядят заманчивыми и многообещающими. Так ли все это? Пришло время познакомиться с serverless технологиями. Буду разбираться с новым подходом через призму опыта создания “классических” приложений. Это значит, что обязательно должны быть тесты, возможность запускать локально, возможность дебажить, несколько окружений, логи, метрики и т.д. Нет смысла знакомиться на уровне hello world приложений, которые красиво выглядят на экране. Я возьму задачу с похожими на реальность сценариями. Конечно, в сети очень много разных статей и инструкций, но нет таких, после которых ты сможешь сделать как надо, подумав обо всех проблемах заранее, а не после релиза. Поехали.

Несколько месяцев назад на моем пути возник GraphQL.

Это произошло, когда я присоединилась к одному из наших проектов, где был не только привычный REST, но и GraphQL API. Это было моё первое знакомство с ним. Я понятия не имела, что он собой представляет, в чем его особенности, а самое главное для меня, как QA инженера – не знала, как его тестировать. 

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

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

В статье будет две части:

1. Теоретическая расскажет о визуализации данных на картах в принципе, о распространенных JS библиотеках для решения этой задачи и их основных возможностях. 

2. В практической рассказ пойдет о трудностях, с которыми мы столкнулись, и о путях их преодоления.

Наверняка вы видели сервисы, показывающие пробки на дорогах. Так вот, большинство примеров будет из одного похожего проекта, где мы показывали рейтинг опасности на дорогах: уклон, резкий поворот, туман, обледенение, аварии — всё это отображается на карте в режиме реального времени. Хотите знать, как? Прошу под кат.

Я пришел в компанию Lineate работать именно на Node.js. В процессе выполнения проектов мне приходилось обращаться к более опытным коллегам и выяснять ответы на возникающие у меня вопросы, но, как оказалось, никто не был уверен в своих ответах на 100%. C Event loop разобраться сложно и не всегда понятно, зачем это нужно на практике. Поэтому даже у опытных коллег знания по этой технологии часто только теоретические — в рабочих условиях ее применяют редко. Опрос, созданный мной в Google Form, прошли около 25 человек, вопросы были совершенно стандартные, из тех, что обычно задают на собеседованиях. Правильных ответов было очень мало, около 23-24%. 

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

Результаты публикуем на Хабре. Если мы хотим добиться производительности, нам нужно отойти от стандартных идей и играть по правилам Node.js.