В данной серии статей описан процесс создания первого pet-проекта для начинающего инженера в DevOps:

Глава 1: Введение и подготовка стенда

Глава 2: Настройка центра сертификации и репозитория

Глава 3: Настройка OpenVPN

Глава 4: Настройка мониторинга

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

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

На DevOops 2020 Moscow Барух Садогурский и Леонид Игольник рассказали, какими методами можно воспользоваться для влияния на стейкхолдеров, что кому говорить, как мотивировать и как работать с возражениями. Пожалуй, за исключением парапсихологических практик и гипноза (которые не стоит раскрывать неокрепшим умам), на этом докладе спикеры показали все способы влиять, не имея полномочий на благо наступления повсеместного DevOps в индустрии.

Под катом — расшифровка доклада, а также видео с конференции. Далее повествование ведется от лица спикеров.

Это глава 20 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

В предыдущей главе мы пришли вот к такому интерфейсу, позволяющему минимизировать коллизии при создании заказов:

Простой и красивый синтаксис, множество библиотек под самые разные задачи и большое комьюнити делают Python одним из самых популярных языков программирования на сегодняшний день, который активно используется в data science и машинном обучении, веб-разработке и других областях программирования.

Когда я начал изучать питон, у меня возникло несколько вопросов.

За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании? 

Или максимы Английского языка, которые бы я хотел знать 20 лет назад.

Чем отличается хороший геймер от плохого? Хороший геймер сидит и изучает игру. Он знает каждый закуток. Он может без запинки назвать все характеристики всех юнитов в Star Craft. А самый крутой игрок знает все пропускные способности желтых, красных и синих конвейеров. А плохой игрок использует чит-коды или assistant apps. 

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

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

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

Привет, сообщество.

Я хотел бы поделиться с Вами своим объяснением того, как понять фикстуры и как начать их использовать в своих проектах, тем самым начать радоваться жизни).

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

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

— работа с проектами и задачами;

— разного рода планирование; 

— процесс интеграционного тестирования; 

— визуализация и сжигание технического долга; 

— сокращение time-to-market;

— проработка бизнес-идей и многое другое.

В декабре прошел очередной IT's Tinkoff Process Improvement #2 — митап, посвященный управлению изменениями. Вместе с коллегами из других компаний мы обсуждали, как проводить изменения и какие инструменты применять. Римма Денисовец из and Change выступила с докладом «Пять этапов для успешных изменений ADKAR», а Денис Тучин из Agile Collage раскрыл тему «3 основных ошибки агента изменений». Я же подготовил доклад «Как не навредить себе и коллегам? Стратегия проведения изменений».

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

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

В этой статье мы расскажем, как писать код для нагрузочного тестирования «не-HTTP» протоколов на примере Apache Thrift с помощью таких инструментов, как JMeter и Gatling (часть 2). Тестировать будем микросервис, который должен справляться с 50K RPS. С одной нагрузочной машины постараемся достичь производительности, заявленной в этом твите:

«Плохие программисты думают о коде. Хорошие программисты думают о структурах данных и их взаимосвязях», — Линус Торвальдс, создатель Linux.