Проектирование и рефакторинг *

Приветствую Хабравчане!

Продолжаем мучить разрабатывать движок для моей любимой игры Arcanum. В данном уроке расскажу, как движок управляет памятью и какие паттерны и подходы использует. Напишем свою мини реализацию полиморфных аллокаторов из С++ 17. Расскажу о некоторых оптимизациях в движке.

Всем привет меня зовут Роман. Я CTO компании LikeSoft и сегодня я хочу поделиться кейсом как я переводил LMS платформу на облако.

Попробуем начать с цитаты:

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

...

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

Если интересно откуда эта цитата и что с ней не так прошу под кат.

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

СУБД является неотъемлемой частью хоть сколько‑нибудь серьезного современного приложения. Соответственно, при проектировании приложения может возникнуть вопрос, как лучше сервисам взаимодействовать с базой данных: предоставляя общий доступ к одной базе или же у каждого микросервиса должна быть своя база данных. Мы рассмотрим два шаблона, предназначенных для решения данной задачи — это Shared database и Database per Microservice. Начнем с Shared database.

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

Всем привет! Предметно-ориентированное проектирование, на мой взгляд, является недопонятым подходом, о котором многие говорят, но немногие его действительно применяют.

Одним из относительно простых в реализации и полезных в архитектурном смысле паттернов, на мой взгляд, являются события предметной области (Domain Events). В данной статье я бы хотел рассказать о возможных вариантах реализации этого шаблона DDD с использованием .NET.

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

Нет волшебной кнопки «Сделать поиск идеальным», но есть способы управлять моделью scoring.

Зачастую full stack (и не только) проекты создаются без функциональных тестов.

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

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

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

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

В этой части статьи я на примере покажу, как можно спроектировать простое веб-приложение, используя функциональное тестирование, и имплементировать веб-приложение.

Привет, Хабр!

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

Привет! В продолжение темы изучения микросервисов решил разобраться с взаимодействием этих самых «сервисов», и написать простой пример взаимодействия двух сервисов между собой.

Перед чтением данной статьи, настоятельно рекомендую ознакомиться с данной статьей, по теме kafka (Kafka за 20 минут. Ментальная модель и как с ней работать)

Пример реализации можно найти тут...

Я профессионально программирую на Rust и, признаться, немного этот язык продвигаю. Поэтому можете себе представить глубину моего расстройства, когда моя младшая сестрёнка, почти не умеющая программировать, обратилась ко мне и попросила научить её C++. Я попытался её отговорить, сказав, что однажды она будет сидеть за отладкой ошибок сегментирования, вооружившись Valgrind и вспоминать этот наш разговор, размышляя, а где же она свернула не туда. Но она оказалась ещё упрямее меня и настаивала: хочу выучить язык программирования, которым действительно пользуются люди.

Я не притрагивался к C++ с тех пор, как ещё в старших классах разрабатывал игры на Cocos2D-X, но решил, что сохранившихся у меня туманных воспоминаний о «правиле трёх» (или сколько там было? Пять? Ноль?) и прочих подобных материях будет более чем достаточно, чтобы решить такую задачу. Оказалось, что и мне требуется кое-что подучить, но я с удовольствием узнал, что существует большая аудитория, с которой можно поделиться этими знаниями. Почти любую концепцию из C++ легко понять, если объяснить её в ключе «о, эта как та штука из Rust».

Притом, что C++ местами несимпатичен, этот язык по-своему красив. Я и так это знал, но, когда взялся заново учиться C++, мне стало только яснее: если Rust в какой-то степени и превосходит C++ (допустим, вы верите, что это так), то лишь потому, что сам Rust стоял на плечах такого гиганта как C++.

Так что мы потратили пару недель, проштудировав серию руководств по OpenGL от ютубера под ником TheCherno (кстати, сама серия отличная). Две недели спустя нам удалось на экране единственный статичный голубой квадратик. Я уже стал опасаться, а не начнёт ли моя сестра сомневаться, стоило ли таким образом изучать разработку игр и пытаться изобразить что-нибудь на C++. Так что тогда я решил, что следует отбросить руководства господина Черно и взяться за разработку игры всерьёз.

Как и почему компания Shopify перешла от монолитной архитектуры к модульно-монолитной.

Привет! В продолжение своих статей на тему микросервисов, решил выделить важный вопрос отношений разработки и бизнеса в целом.

Как микросервисная архитектура решает проблему взаимодействия бизнеса и разработки?

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

Rolling Updates — это стратегия деплоя, при которой обновление приложения происходит поэтапно, с минимальными перебоями в работе сервиса. Вместо остановки всех компонентов приложения и замены их новыми версиями, Rolling Updates обновляет небольшие группы (называемые батчами) экземпляров приложения, постепенно замещая старые версии новыми.

Для компании SimpleOne управление спецификациями требований было настоящей головной болью, требующей унификации подходов и учета потребностей разных команд. Мы стояли перед выбором: сделать свое решение для управления требованиями и сбора спецификаций или попробовать уже существующие практики. Концепция DocOps привлекла внимание тем, что помогает стандартизировать инструменты и навести порядок в хранении артефактов. В этой статье мы расскажем, как внедрили подход на основе docs as code, какие преимущества получили и какие трудности преодолели на пути.

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

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

Следующий возникающий в голове вопрос, когда разобрался с тем, как работать с данными в данной архитектуре (а может у кого то этот вопрос стоит первым) - как микросервисы будут взаимодействовать между собой?

В данной статье разберемся с синхронным и асинхронным взаимодействием, сложностями и разными подходами.

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

Описание проблем при работе с Camunda 7 и их решение.
Обзор на контекст камунды, оптимизация корреляции и истории