Сердце фреймворка Flutter (который для разработчиков часто представляется только в виде набора классов на языке Dart) написано на языке С и компилируется в двоичный артефакт, известный как Flutter Engine, подключаемый к приложению и используемый из Dart-классов через механизм нативного связывания (аннотации @pragma('vm:entry-point') для вызовов из Flutter Engine в Dart, @Native и external для обращения к C++ коду во Flutter Engine из Dart).

Но в действительности Flutter Engine не имеет никакого платформо-специфического кода (при этом собран под целевую аппаратную архитектуру) и не знает, как работает платформенный event loop, как создавать потоки, на какой поверхности выполнять отрисовку сцены и не может получать информацию о действиях пользователя (касание экрана, перемещение указателя мыши, нажатие клавиш) и системных событиях. Такое архитектурное решение было сделано для того, чтобы иметь возможность запускать Flutter-приложения потенциально на любом устройстве с экраном (даже светодиодной панелью). В этой статье мы поговорим про Flutter Embedder, его роль в запуске приложения и привязке к системным event loop, а также рассмотрим сборку простого embedder для публикации Flutter приложения как VNC-сервера.

Нередко для выполнения тестов требуется запуск вспомогательных сервисов (баз данных, брокеров очередей и др.) и стандартной практикой в подходах DevOps является запуск тестов внутри управляемого окружения, где сначала создается контейнер с JVM, после чего внутри конвейера CI/CD запускаются вспомогательные контейнеры и сборка Kotlin-приложения с точкой входа для запуска тестов. Однако есть и альтернативное решение - запускать вспомогательные тестовые контейнеры непосредственно внутри JUnit-теста. В этой статье мы обсудим несколько различных подходов к управлению контейнерами из тестов для Kotlin-приложений.

Без сомнений, автоматические тесты важны для поддержания высокого качества кода, снижения вероятности повторного возникновения ранее обнаруженных ошибок и уменьшения времени подготовки к релизу. Но также не менее важно обеспечивать качество и соответствие стандартам кода самих тестов. В ряде случаев для проверок можно использовать существующие инструменты проверки стиля кода (checkstyle, pmd, sonarqube), но кроме самого кода, хороший тест также должен иметь осмысленные названия тестовых методов и давать адекватное описание причины возникшей ошибки. В этой статье мы рассмотрим использование maven-плагина статического анализа jtcop для поддержания единого стандарта именований для тестового кода.

Идея создавать полный стек веб или мобильного приложения с использованием одной технологии не является новой. Этим путем уже прошел Javascript (JS + React/Native + Node.JS), Python (cowasm + kivy) и даже Go (go/wasm, gomobile) и Dart тоже не исключение (web для него естественная среда обитания, поскольку язык создавался для замены JavaScript, также поддерживается компиляция в Wasm с включенным экспериментом wasm gc, для мобильной разработки существует фреймворк Flutter). Кроме того, приложение на Dart может компилироваться в исполняемый файл и это может дать прирост производительности для высоконагруженных систем. В этой статье мы рассмотрим несколько решений для создания бэкэнда на Dart, в первой части обсудим общие вопросы архитектуры и создадим простой сервер без фреймворка и с использованием Shelf, а во второй части статьи речь пойдет о Frog и Conduit.

В этой статье мы создадим простое приложений на основе MQTT с использованием брокера сообщений EMQX и настроим наблюдение через встроенные механизмы трассировки.

Для решения задач автоматизации рутинных процессов для системных администраторов и DevOps чаще всего используются или bash-сценарии или python. Первое решение косвенно используется и в описании Dockerfile, поскольку сценарий исполняемых команд принципиально ничем не отличается от запуска скрипта в какой-либо shell, второй подход чаще ассоциируется с автоматизацией, связанных с взаимодействием с хранилищами данных. Но несправедливо было бы обойти стороной возможность создания исполняемых сценариев на языке Kotlin, которые могут стать полноценной заменой bash-сценариям.

В этой статье мы рассмотрим несколько примеров использования Kotlin Scripting (KTS) для автоматизации в распределенной системе, будем использовать долгоживущие скрипты с ожиданием заданий через RabbitMQ, а также поработаем с файловой системой, внешними сервисами, а также попробуем использовать KTS для сборки Docker-контейнеров.

Apache Kafka нередко используется как инструмент накопления истории событий или посредник для взаимодействия микросервисов, работающих с разной скоростью или ожидающих доступа к историческим данным для анализа трендов исторических данных (и в этом случае может использоваться как альтернативное решение для Time Series Database). В большинстве случаев в роли producer и consumer выступают сетевые приложения, которые взаимодействуют через драйвер с поддержкой протокола Kafka, но иногда требуется настроить интеграцию с унаследованными системами или готовыми решениями и для этого может использоваться вспомогательный инструмент Kafka Connect, представляющий большое количество готовых коннекторов. В первой части статьи мы рассмотрели способ создания коннектора для опроса REST API и анализа данных с использованием Hazelcast. В этой статье мы последовательно разберемся с созданием коннекторов для пересылки сообщений из топика во внешнюю систему (Sink Connector) для отправки данных из Kafka в TSDB базу данных TDEngine, а также обсудим, как можно выполнить нагрузочное тестирование всего стека с использованием xk6-kafka.

Когда речь заходит о создании REST-сервера для Kotlin часто на ум приходит фреймворк Ktor (от Jetbrains), использующий важные особенности Kotlin, такие как корутины и DSL-синтаксис. Ktor является модульным решением, для которого созданы расширения для всех наиболее важных аспектов разработки бэкэнда (безопасность, маршрутизация, сериализация данных, применение шаблонов, поддержка сетевых протоколов, управление сессиями, операции с заголовками, извлечение метрик и автоматическая генерация документации по API). Однако это не единственный веб-фреймворк и в некоторых случаях его синтаксис оказывается несколько запутанным (например, операции взаимодействия с неявным объектом call внутри корутин обработки запросов). В этой статье мы рассмотрим альтернативный фреймворк Jooby, который предоставляет схожий с Ktor набор функциональности, но дает больше свободы в выборе механизмов неблокирующей многозадачности и, в ряде случаев, более короткий и явный синтаксис, а также показывает более высокую производительность по результатам тестов.

Для надежной поточной обработки данных в реальном времени и принятия решений на основе анализа данных из внешнего источника нужно обеспечить организацию конвейера обработки и хранения данных, который может быть кластеризирован и распараллелен для достижения необходимой производительности и отказоустойчивости. Кроме того, нужно обеспечить механизм своевременной доставки обновленных данных (на основе периодического опроса или использования Web Sockets/SSE) в систему анализа, которая также должна иметь доступ к истории изменений (например, для анализа тренда или получения усредненных значений по временному окну). В этой статье мы поговорим про использование Apache Kafka совместно с Hazelcast для анализа данных в реальном времени, а также разработаем коннектор для Kafka Connect для извлечения данных из внешнего источника (на примере WeatherStack API)

При взаимодействии микросервисов потенциально узким местом является сетевой балансировщик, распределяющих трафик по рабочим узлам. Чаще всего для выполнения балансировки на уровне приложения используется nginx или haproxy, однако в ряде случаев (например, при необходимости трассировки распределенных запросов) для этого цели лучше подходят такие решения как Envoy или Traefik. Но среди проектов CNCF есть еще один балансировщик BFE, разработанный первоначально в baidu, который кроме всех обычных возможностей балансировщика уровня приложения, также предоставляет большие возможности для мониторинга и трассировки. В этой статье мы рассмотрим основные возможности BFE и возможности использования с Prometheus и Kubernetes.

Первоначально python как язык с динамической типизацией не предполагал никакого явного описания типов используемых объектов и список возможных действий с объектом определялся в момент его инициализации (или изменения значения). С одной стороны это удобно для разработчика, поскольку не нужно беспокоиться о корректности определения типов (но в то же время осложняло работу IDE, поскольку механизмы автодополнения требовали анализа типа выражения в ближайшей инициализации). Но это также приводило к появлению странных ошибок (особенно при использовании глобальных переменных, что само по себе уже плохое решение) и стало особенно неприятным при появлении необходимости контроля типа значений в коллекциях и созданию функций с обобщенными типами. В Python 3.12 будет реализована поддержка нового синтаксиса для generic-типов (PEP 695) и в этой статье мы обсудим основные идеи этого подхода.

Для обнаружения аномально высокой длительности выполнения отдельных функций (а также избыточного выделения или утечек памяти) используются инструменты профилирования над виртуальной машиной (например, JProfiler или Visual VM для JVM) или интегрированные в выполняемый код, например встроенный механизм при компиляции Go-приложений. Альтернативой может стать использование универсальных механизмов профилирования, которые интегрируются со средой выполнения и отправляют результаты профилирования на сервер, который может анализировать аномальное поведение и визуализировать выделение памяти и время выполнения отдельных функций (и построить flame graph по результатам анализа приложения во время выполнения). В этой статье мы рассмотрим использование Pyroscope совместно с Go для обнаружения утечек памяти.

Для описания объектов и процессов в терминах бизнес-логики, конфигурирования и определения структуры и логики в сложных системах популярным подходом является использование предметно-специфических языков (Domain Specific Language - DSL), которые реализуются либо через синтаксические особенности языка программирования (например, с использованием средств метапрограммирования, аннотаций/декораторов, переопределения операторов и создания инфиксных операторов, как например в Kotlin DSL) или с помощью применения специализированных инструментов разработки и компиляторов (например, Jetbrains MPS или парсеров общего назначения, таких как ANTLR или Bison). Но существует также подход реализации DSL, основанный на синтаксическом разборе и одновременной кодогенерации для создания исполняемого кода по описанию и в этой статье мы рассмотрим некоторые примеры использования библиотеки textx для создания DSL на Python.

Тестирование приложений Jetpack Compose обычно основано на использовании библиотеки Compose UI Test и создании юнит-тестов поверх библиотек мокирования или DI. Однако этот подход требует наличия эмулятора и не всегда применим для использования в конвейере CI/CD, где обычно используется Robolectric вместо настоящего Android Runtime. При этом нередко в тестах используется скриншотное тестирование (например, через использование captureToImage в Compose UI Test) и сравнение рендеров с образцом, что изначально недоступно в Robolectric из-за особенностей рендеринга. В этой статье мы рассмотрим использование библиотеки Roborazzi, которая решает эту проблему, совместно с новым подходом к архитектуре Jetpack Compose приложений, которая была предложена Slack в библиотеке Circuit.

Со времени публикации первых фреймворков для проектирования архитектуры предприятия (например, TOGAF, FOAF, Archimate, Zachman Framework, MODAF, DoDAF, FEA, Gartner Enterprise Architecture Framework), а также попыток переноса архитектурных подходов управления жизненным циклом создания программного продукта на функционирование предприятия в целом (например, EUP) возникло устойчивое ощущение, что они не предлагают никакого конкретного решения, подходящего для любых предприятий, а следовательно не имеют особой ценности.

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

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

В интерпретируемых языках программирования (или в языках, которые включают возможность компиляции в runtime) есть возможность вычисления значения выражения, полученного из внешнего источника (например, для построения графика функции, введенной пользователем) с подстановкой актуальных значений переменных. Но JVM изначально ориентирована на компиляцию перед выполнением и механизма, аналогичного eval, в JVM нет (кроме, конечно, возможности использования Nashorn и eval в JavaScript-коде). В этой статье мы рассмотрим пример динамической генерации байт-кода из математического выражения.

Графический редактор GIMP предоставляет широкие возможности для создания расширений на языках программирования Scheme (функциональный язык, сходный с LISP) или Python. Для доступа к системным операциям и регистрации собственных действий используется общий реестр Procedural Database (PDB), через который можно выполнять любые действия со встроенными механизмами GIMP (например, создание изображения). В этой статье мы рассмотрим основы создания расширений на Python 3 и возможные подходы к тестированию расширений через PDB.

В первой части статьи мы рассмотрели подход к обработке аннотаций (и возможной генерации дополнительных исходных текстов), который используется в мире Java и долгое время применялся также для Kotlin (при этом Kotlin-код предварительно преобразовывался в Java-классы, что занимало дополнительное время для компиляции). С 2021 года стал доступен новый плагин для gradle, который основан на непосредственном анализе исходных текстов Kotlin и позволяет генерировать код без необходимости создания текстового файла. В этой статье мы разберемся как создать процессор аннотаций для KSP и как его можно протестировать?

Язык программирования Kotlin часто ассоциируется с мобильной разработкой для Android и это неудивительно, учитывая что он принят Google как официальный язык разработки, и принес множество необходимых и удобных языковых конструкций и кооперативной многозадачности, при этом сохраняя совместимость на уровне байт-кода с ранними версиями JVM. Но применимость языка существенно выше и имеющиеся библиотеки (как созданные для Java, так и разработанные специально для Kotlin) позволяют создавать обычные приложения (например, на JavaFX или с использованием платформенных графических библиотек и Kotlin Native), а также создавать код для бэкэнда c подключениям к базам данных, кэшам, очередям сообщений и т.д. При этом, если для мобильной разработки проблем с поддержкой многоязычных сообщений не возникает (благодаря механизму ресурсов, в том числе строк, которые могут быть переопределены для конкретной локали), то для бэкэнда это становится нетривиальной задачей. В этой статье мы обсудим несколько подходов для создания бэкэнда с поддержкой нескольких языков.