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

This is the third part of a series covering the implementation of algorithms in Go. In this article, we discuss the Merge Interval algorithm. Usually, when you start learning algorithms you have to deal with some problems like finding the least common denominator or finding the next Fibonacci number. While these are indeed important problems, it is not something that we solve every day. What I like about the Merge Interval algorithm is that we apply it in our everyday life, usually without even noticing that we are solving an algorithmic problem.

Let's say that we need to organize a meeting for our team. We have three colleagues Jay, May, and Ray and their time schedule look as follows (a colored line represents an occupied timeslot):

С нарастающими скоростями и распределёнными системами всё сложнее бывает создать приложение удобным для конечного пользователя. Программы обладают кучей фич. Но выполняют ли они то, что нужно юзерам? А скорость их выполнения достаточная? А производительность при выполнении не хромает? На эти вопросы помогает ответить нагрузочное тестирование (НТ).

Меня зовут Саша, я работаю в команде тестирования Ozon Fintech и расскажу про разнообразный спектр вариантов НТ: как именно мы его применяем и какие инструменты используем. Статья будет полезна тем, кто уже что-то слышал про НТ и хочет добавить его в свой проект, но пока страшновато. Давайте разбираться!

• Основанный на блокировке ресурсов
• Основанный на создании версионной копии ресурсов.

Узнайте, как Deutsche Telecom перешла от каскадной разработки монолитного приложения к гибкой архитектуре на основе микросервисов.

07.07.2020 г., перевод статьи Bernd Rücker

Я часто обсуждаю микросервисную архитектуру с людьми, далекими от Java: разработчиками C#, Node.JS/JavaScript или приверженцами Golang. Все они сталкиваются с тем, что им нужен механизм оркестровки в микросервисной архитектуре или просто инструмент для оптимизации рабочего процесса и получения возможности упорядочения, обработки тайм-аутов, Saga и компенсирующих транзакций.

BPM-платформа с открытым исходным кодом от Camunda отлично подходит для таких задач. Дружелюбие по отношению к разработчику — одна из ключевых особенностей продукта. Но если взглянуть на его документацию, может сложиться впечатление, что в основном «дружелюбие» Camunda направлено на Java-разработчиков. Платформа предоставляет множество возможностей для подключения собственных функций и расширений, но все это делается на Java. Так ли это на самом деле?

Представим ситуацию — тестировщик находит баг, начинает обсуждать его с разработчиком — а тот настаивает, что это не баг, потому что в спецификации не было речи об этой функциональности. Знакомо?

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

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

Вы также наверняка знакомы со спорами на тему "баг это или фича". Клиенты обнаружили недоработки, и product owner приходит в команду с замечаниями. А тестировщик с разработчиком защищаются, объясняя это тем, что в изначальной постановке и речи не было о реализации этой фичи. И такие моменты потом заводятся в backlog.

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

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

В этой статье рассматриваются различные способы контейнеризации приложения Spring Boot:

- создание образа Docker с помощью файла Docker,

- создание образа OCI из исходного кода с помощью Cloud-Native Buildpack,

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

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

По моему мнению, все популярные ныне архитектуры — MVP, MVVM и даже MVI — уже давно на арене и не всегда заслуженно. Разве у них нет недостатков? Я вижу их немало. Мы у себя решили, что хватит это терпеть, и (пере)изобрели новую, максимально асинхронную архитектуру.

• Почему по умолчанию все решают задачу именно так?
• Можно ли сделать лучше?

Ваш новый разработчик только что закончил подписывать трудовой договор и с горящими глазами готов закрывать по 15 задач в день. На его пути стоит лишь одно препятствие — новый ноутбук, который пока что не настроен должным образом. Чаще всего процесс настройки окружения описывается в документе, который выдается новому разработчику. Мы не сильно далеко ушли и тоже составили такой список.

Привет, Хабр! Меня зовут Сергей, я Lead Software Engineer/Stream Lead в ЕРАМ, сертифицированный Google Cloud инженер и архитектор. Уже более 10 лет занимаюсь коммерческой разработкой для различных всемирно известных компаний, в основном с фокусом на бэкенд. А еще я очень люблю делиться своими знаниями. Сегодня хочу рассказать про Apache Airflow, который, на мой взгляд, является хорошим инструментом для построения ваших пайплайнов. 

Правда ли, что разработка в B2B и B2C — это совершенно два разных мира? Многие разработчики считают, что в B2B:

- медленная и неповоротливая разработка;

- используются технологии 10-летней давности;

- мало возможностей для профессионального развития;

- нужно постоянно писать кучу ненужных документов;

- приходится делать продукт только для клиента и сложно увидеть результат своей деятельности.

На самом деле нет. Можно организовать разработку в B2B так, чтобы было интересно работать, быстро принимать решения и постоянно развивать свои навыки.

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). Наша компания — B2B-проект, который вырос из стартапа внутри большой группы компаний. 

Расскажу о том, как у нас организованы процессы, вместе с нашими разработчиками: руководителем разработки MCS Михаилом Кебичем, руководителем разработки IAM и Hotbox Викторией Сусловой, старшим программистом команды разработки PaaS Азатом Хадиевым.

Недавно наш СТО Евгений Россинский @eross пообщался с ведущими подкаста  “Подлодка” про роль СТО. По мотивам этого общения мы подготовили две статьи с основными вопросами о СТО - как им стать и каково им быть, как его найти и сколько это стоит. Сегодня мы публикуем вторую часть этого интервью (первую часть можно прочитать тут).

В рамках современной микросервисной архитектуры мы можем разделить микросервисы на две основные группы в зависимости от их взаимосвязи и взаимодействия. Первая группа представляет из себя внешние микросервисы, которые напрямую доступны пользователям. В основном это API на основе HTTP, которые используют обычные текстовые сообщения (JSON, XML и т. д.), оптимизированные для использования сторонними разработчиками, использующие передачу репрезентативного состояния (REST) ​​в качестве коммуникационной технологии. 

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

Часть 1
Часть 2
Часть 3
Часть 4

В этой серии постов мы внимательно рассмотрим один из главных ингредиентов в контейнере – namespaces. В процессе мы создадим более простой клон команды docker run – нашу собственную программу, которая будет принимать на входе команду (вместе с её аргументами, если таковые имеются) и разворачивать контейнер для её выполнения, изолированный от остальной системы, подобно тому, как вы бы выполнили docker run для запуска из образа.

Helmfile — обёртка для helm, которая позволяет в одном месте описывать множество helm релизов, параметризовать их чарты для нескольких окружений, а также задавать порядок их деплоя.

О самом helmfile и примерах его использования можно почитать в readme и best practices guide.

Upd. 10/06/2022: Со временем довёл до ума этот подход и получилось гораздо лучше и удобнее, чем описано в статье. При возможности напишу отдельный пост, а пока с примерами улучшенного варианта можно ознакомиться здесь и здесь.

Мы же познакомимся с неочевидными способами описать релизы в helmfile

Допустим, у нас есть пачка helm-чартов (для примера пусть будет postgres и некое backend приложение) и несколько окружений (несколько kubernetes кластеров, несколько namespace'ов или несколько и того, и другого). Берём helmfile, читаем документацию и начинаем описывать наши окружения и релизы:

    .
    ├── envs
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    └── helmfile.yaml