• Шаблоны проектирования
• Тайм-менеджмент для разработчика
• Библиотека быстрого поиска путей на графе. В библиотеке используется мало-известный вариант A* поиска, который называется NBA*.

Интерфейсы

• Теория ограничений в интерфейсах
• Интерфейсы: как сообщать пользователю, если "Упс, что-то пошло не так"

Полезное

• protocols_poster.pdf - постер с почти всеми протоколами. Распечатывать минимум на А3, ибо мелко и много.

DevOps = красивое название для ПРОЦЕССОВ активного взаимодействия разработчиков с администраторами (БД и систем) и автоматизаторами тестирования
, которые (процессы) максимально стандартизированы с помощью договорённостей в командах и обеспеченностью сред для разработки
и автоматизированы за счёт использования специальных инструментов поставки, прогона тестов, развёртывания.

В общем случае, счастье достигается за счёт:

• упрощения и ускорения оргпроцедур по получению техники для разработчиков с уже установленной или быстро устанавливаемой/обновляемой IDE и другими необходимыми инструментами для производства ПО, а также по получению необходимых сетевых доступов с рабочих станций.
• упрощения и ускорения оргпроцедур по выделению и масштабированию мощностей для стендов, необходимых для сборки, развёртывания и тестирования ПО
  , обычно достигается использованием интернет/интранет облачных решений (Amazon AWS, Google Cloud, Microsoft Azure, SberCloud, Yandex.Cloud)
• использования средств автоматизации операций во всём процессе поставки ПО (Jenkins, TeamCity, рукописные скрипты)
• использования средств виртуализации и контейнеризации (Docker, Kubernetes)
• внедрения практики CI/CD/CDP и неизбежно с ней связанной автоматизацией тестов (unit, API, web-API, regress)
• внедрения решений по мониторингу как целых стендов, так и отдельных хостов, ВМ, веб-сервисов и приложений
• перехода на микросервисную архитектуру и service mesh с автотестированием контрактов многочисленных API (особенно если используется модный сейчас gRPC, например-например)

N.B. В повседневности словом devops чаще обозначают РОЛЬ администратора, который сопровождает стенды разработки и тестирования, управлением всеми этими средствами автоматизации поставки CI/CD/CDP (см. ниже).

скачать схему в формате diagrams.net (бывший draw.io)

Основная идея CI/CD/CDP — создание автоматизированного конвейера поставки продукта заказчику/потребителю за счёт автоматизации:

1. чекина изменений в репозиторий;
2. статического анализа кода: на уязвимости, на соответствие требованиям и стандартам;
3. компиляции и формирования билда (сборки);
4. передачи обратной связи об успехе/неудаче билда в виде уведомлений по выбранным каналам;
5. деплоев на dev / test / staging / prod;
6. всех необходимых тестов (unit, smoke, acceptance, regression, integration, end-to-end);
7. заведения issue в СУП в случае ошибок;
8. слияния изменений с нужной веткой в случае "зелёных" тестов.

Continuous integration, CI = автоматизированная интеграция программного кода в существующий проект в репозитории с последующей компиляцией, формированием сборки и прогоном базовых автотестов.
Считается, что должно занимать <= 10 минут.

Сontinuous delivery, CD(L) = CI + автоматизированная поставка готовой сборки ПО с изменениями на сервера разработки и тестирования с прогоном автотестов.

Сontinuous deployment, CDP = CD + автоматизированное развёртывание изменений в Пром.

Всё это счастье достигается посредством использования таких инструментов как, например, GitLab CI, BitBucket Pipelines, AWS CodeBuild, Bamboo, TeamCity, Jenkins и сильно облегчающей деплои контейнеризации (Docker).

Суть

Контейнер = набор процессов, изолированный от остальной ОС, и запускаемый с отдельного образа, который содержит все файлы, необходимые для их работы (runtime & supporting files). Образ содержит все зависимости приложения и поэтому может легко переноситься из среды разработки в среду тестирования, а затем в промышленную среду.

А разве это не просто виртуализация?
Не вполне:

• Виртуализация обеспечивает одновременную работу нескольких операционных систем на одном компьютере;
• Контейнеры используют одно и то же ядро операционной системы и изолируют процессы приложения от остальной системы.

Разница между Виртуальной машиной и Контейнером

скачать схему в формате diagrams.net (бывший draw.io)

Примеры решений контейнеризации

• Облачные решения:
  • Amazon AWS ECS
  • Azure Container Service (ACS)
• On-premise решения:
  • Docker
  • Kubernetes
• Оркестрация:
  • Docker Engine API
  • Kubernetes
  • Azure Service Fabric
• Какое-то самописное решение: API-контейнеризация + ручная автоматизация

1. Делаем запрос на получение OAuth token, используя, например, basic-аутентификацию OS User'ом curl -X GET "https://master-address:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token" -H "Content-Type: application/json" -H "X-CSRF-Token: XXX" -u [username] -ikL
2. Из ответа из header'а < Location: https://10.64.33.43:8443/oauth/token/implicit#access_token=TOKENSCHMOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer берём значение TOKENSCHMOKEN (можно сразу grep'ать вместе с запросом выше), это и будет наш Bearer-токен для последующих запросов к API OS.
3. Выполняем нужный нам запрос, например почитать yaml какого-то Deployment'а curl -X GET "https://api.master-address:8443/apis/apps/v1/namespaces/[namespace]/deployments/[deployment]" -H "Content-Type: application/json" -H "Authorization: Bearer TOKENSCHMOKEN" -ik , и в ответе получаем искомый yaml.

API = application programming interface = опубликованный программный интерфейс компонента/системы, позволяющий другим компонентам/системам получать доступ к какой-либо функции.

Контракт API = зафиксированные и задокументированные ответственность поставщика и ожидания потребителя.
Включает в себя две составляющие:

• Функциональная (сигнатура и семантика):
  1. Название API
  2. Входные данные / параметры вызова (протокол, URI)
  3. Возвращаемые данные
  4. Семантика (описание функциональности)
  5. Шаблон интеграционного взаимодействия
  6. Потребитель
• Нефункциональная (SLA):
  1. Доступность (availability, %)
  2. Время ответа (latency, ms) = время, необходимое приложению, чтобы ответить на запрос
  3. Пропускная способность (throughput, transactions per second, tps) = количество транзакций (запросов), которое приложение может обработать в течение секунды
  4. Какие-либо ограничения (по размеру сообщения, безопасности и т.п.)

Обычно контракты API ведут как в Confluence (в файлах формата OpenAPI Specification, иногда называемый Swagger), так и в специальных системах — реестр API (частенько, у крупных компаний такие системы написаны "под себя").

CDC (Consumer Driven Contract) = контракт потребителя сервиса.
Представляет из себя соглашение между сервисом-поставщиком и сервисом-потребителем в том, что
сервис-поставщик обязуется уметь принимать на вход от сервиса-потребителя определённую структуру данных определённых типов, сериализованную JSON/XML/binary/...
и гарантирует возвращать в ответ определённую структуру данных определённых типов, также сериализованную.

скачать схему в формате diagrams.net (бывший draw.io)

CDC фокусируется на поведении и данных, которые важны Потребителю, т.е. требования исходят от Потребителя: мне нужно вот это.

Сам контракт в явном виде описывается с помощью некоторого IDL (interface desciption language), например:

• OpenAPI для Swagger
• WSDL для SOAP
• WADL для REST HTTP сервисов
• Protocol Buffers для gRPC

Этот подход когда-то реализован в виде WSDL/WADL-сервисов
, развивался для REST HTTP в виде, например, OpenAPI с его .yaml-файлами контрактов (Contract-First API Development with OpenAPI Generator and Connexion)
, а сейчас его популярность сильно возросла в связи с активным продвижением gRPC и его .proto-файлами контрактов (статьи GRPC сервис на примере генератора паролей и gRPC — фреймворк от Google для удалённого вызова процедур)

Проверка введённых значений на соответствие логическим критериям, а не формальным — это занятие для бэка.
Пример:

• проверка что в форму для числа введено число, а не срока — это чистый фронт;
• проверка по КЛАДР -однозначный бэк;

Также сомнительно тиражировать единый алгоритм проверки в нескольких местах.

Почему не является корректным противопоставлять эти свойства напрямую.

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

Многопоточность — способность системы выполнять несколько операции параллельно (одновременно). В современных компьютерах это физически параллельные вычисления на разных ядрах CPU (отсюда такая гонка за количеством ядер и феноменальная производительность GPU на тензорных операциях).

Junior — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.

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

Senior — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.