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

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

Добрый день! Меня зовут Михаил Емельянов, недавно я опубликовал на «Хабре» небольшую статью с примерным путеводителем начинающего Python-разработчика. Пользуясь этим материалом как своего рода оглавлением книги, я написал первые четыре главы мини-учебника «Ядро планеты Python», где постарался коротко, но достаточно ёмко раскрыть специфику, удобство, красоту и силу этого прекрасного языка.

Оригинал учебника лежит на GitHub, вы вольны сколько угодно дополнять и переделывать его. Самое главное — учебник написан на Jupiter Notebook, а это значит, что вы можете интерактивно редактировать код, мгновенно добавляя новые сущности или проясняя непонятные моменты.

Ultron — самый простой фреймворк для разработки UI тестов Android.

В данной статье я познакомлю вас с малоизвестным фреймворком, который позволит вам облегчить android ui тестирование.

При всех достоинствах Kafka как распределенного хранилища потока сообщений, боль вызывало раздельное хранение метаданных (топологии разделов, конфигурации кластера и прочего) и необходимость запуска в кластере рядом с Kafka еще и Apache Zookeeper. Побочным эффектом такого соседства (кроме дополнительных забот об администрировании и мониторинге) является долгое время восстановления после сбоя при больших размерах кластера, значительном количестве разделов или сложной топологии групп. Но ситуация улучшается и отличная новость появилась полторы недели назад в KIP-833, что в ближайшей версии Kafka 3.3 новый протокол согласования метаданных (KRaft), работающий внутри Kafka без Zookeeper, будет признан Production-Ready и далее постепенно зависимость от Zookeeper будет помечена как deprecated и удалена. В этой статье мы поговорим об особенностях протокола KRaft и разберемся как настроить новый кластер Kafka без необходимости установки Zookeeper.

Хорошее мобильное приложение должно быть не только создано с использованием современных архитектурных шаблонов, но и быть подготовленным к реализации автоматических тестов. Мы рассмотрим с вами на практическом примере как создается приложение с учетом возможностей тестирования, чем отличаются архитектуры и соответствующие подходы к созданию тестов и как создать полный спектр тестов от unit-тестирования бизнес-логики до End-to-End тестов приложения как единого целого. В первой части статьи мы поговорим про разработку интерфейсов без использования реактивной модели, последовательно создадим (и доработаем) приложение на архитектурах MVP и MVVM и разработаем тесты (с использованием виртуального времени на тестовом диспетчере, моков и Hilt для подстановки тестовых объектов). Во второй части статьи речь пойдет о MVI и о тестировании приложений для Jetpack Compose (включая анимацию и передачу данных через LocalComposition-объекты). Всех, кому интересна мобильная разработка, приглашаю под кат.

В РСХБ мобильную разработку мы ведём преимущественно на Flutter. В новой статье поговорим об алгоритме, который используется в любом приложении – о сборщике мусора (англ. Garbage collection). Его основной задачей, как в любом высокоуровневом языке программирования, является наблюдение за ссылками и очистка областей памяти с целью предотвращения переполнения памяти. Под катом рассказываем о том, как во Flutter работает процесс сборки “мусора” - неактивных и неиспользуемых ссылок, а также локальных и глобальных экземпляров языка Dart.

В языке Dart применяется сборщик мусора по поколениям объектов. Сборщик мусора для сборки экземпляров с коротким жизненным циклом и сборщик мусора для долгоживущих экземпляров, переживших более одного цикла сборки мусора.

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

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

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

Если повезло, то кандидат знает о необходимости проверки сетевого взаимодействия, но, за редким исключением, его знания ограничены Rewrite или Breakpoints.

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

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

Почему Flutter использует язык Dart? Основные преимущества языка Dart.

Сложность: Новичок.

Многие лингвисты считают, что естественный язык, на котором говорит человек, влияет на то, как он думает. Применяется ли та же концепция к компьютерным языкам? Программисты, работающие с разными языками программирования, часто предлагают совершенно разные решения проблем. В качестве более радикального примера, ученые-компьютерщики убрали оператор goto, чтобы поощрять более структурированные программы (не совсем тоже самое, что тоталитарные лидеры в романе "1984", удаляющие еретические слова из естественного языка, чтобы устранить мыслепреступления, но вы поняли идею).

Какое это имеет отношение к Flutter и Dart? На самом деле совсем немного. Ранняя команда Flutter оценила более дюжины языков и выбрала Dart, потому что он соответствовал тому, как они создавали пользовательские интерфейсы.

Dart — главная причина, по которой разработчики любят Flutter.

До текущего момента, отладка С кода для ZX Spectrum была возможна только в некоторых эмуляторах. В предыдущей статье описан процесс написания отладчика, который использовал цепочку gdb-клиент (z88dk) <-> gdb-протокол <-> gdbserver (эмулятор Fuse).

В этой статье описан процесс написания "железного" отладчика для ZX Spectrum, то есть такого, в котором и непосредственно целевой код и код отладчика выполняет один и тот же z80. Как и в случае с эмулятором, используется сетевой протокол gdb, для этого требуется сетевой адаптер Spectranet, который постепенно собирает вокруг себя значительное (англоязычное) сообщество.

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