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

Качественная визуализация данных не менее важна для анализа данных, чем методы математической обработки. На сегодняшний день существуют десятки (если не сотни) библиотек для визуализации наборов данных на Python, но иногда в них встречаются уникальные возможности и хотелось бы иметь возможность объединить различные инструменты в единой панели. В статье мы рассмотрим основы библиотеки panel для реализации реактивной модели интерактивных визуализаций и попробуем объединить визуализации из разных библиотек в одном dashboard.

Kubernetes, как система оркестрации, позволяет автоматизировать процесс развертывания сложных приложений и восстанавливать ожидаемое состояние кластера после сбоев. В общем случае приложение представляет собой резидентно запущенные контейнеры, которые обрабатывают запросы клиентов в цикле обработки событий, при этом при росте нагрузки могут создаваться дополнительные реплики (с использованием механизма Horizontal Pod Autoscaling). Однако, нередко бывают случаи, когда сервис используется не очень часто, но при этом в запущенном состоянии он забирает большое количество оперативной памяти или процессорного времени, и желательно обеспечить механизм запуска сервиса по запросу (или по внешнему событию). Для реализации такого варианта использования сейчас доступен инструмент knative, который был принят в марте 2022 года в качестве incubating-проекта в CNCF (Cloud Native Computing Foundation). В этой статье мы разберемся с основными понятиями knative и попробуем создать архитектуру приложения, основанную на событиях, с использованием eventing-возможностей knative.

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

Развитие методов глубокого машинного обучения привело к росту популярности нейронных сетей в задачах распознавания образов, машинного перевода, генерации изображений и текстов и многих других. С 2009 года нейронные сети попытались применить напрямую в задачах обработки графов (к которым могут относиться системы веб-страниц, связанных ссылками, словари с определенными отношениями между словами, граф социальных связей и другие) и среди возможных задач можно определить поиск кластеров узлов, создание новых графов на основе имеющейся информации о структуре графа, расширение графа и предсказание новых связей и другие. Сейчас выделяют несколько типов нейронных сетей на основе графов - сверточные графовые сети (Convolutional Graph Network), графовые изоморные сети (Graph Isomorphism Network) и многие другие и они часто используются для анализа цитирования статей, исследования текста (представление предложения как графа с указанием типов отношений между словами), изучения взаимосвязанных структур (например, исследования белковых молекул, в частности сеть Alphafold использует модель GNN) и т.д. В статье мы рассмотрим некоторые общие вопросы создания и обучения графовых сетей на основе библиотеки Python Spektral.

Вчера на официальном сайте был опубликован первый релиз-кандидат Python 3.11, который принесет важные оптимизации и доработки в возможности языка. Релиз планируется в октябре этого года, но уже сейчас можно поэкспериментировать с новыми возможностями и сегодня мы поговорим о группах исключений и асинхронных задач. Первые позволяют одновременно выбрасывать и обрабатывать несколько исключений, в то время как вторые позволяют объединять задачи в общий event loop и координированно управлять группами задач.

Тестирование сетевых приложений разделяется на несколько взаимосвязанных этапов и значительно зависит от корректности работы API. Нередко API публикует большое количество методов, манипулирующих объектами хранилища данных, часть из которых защищено механизмами авторизации. Тесты включают в себя последовательность операций по созданию-изменению-удалению объектов и могут состоять из большого количества запросов, которые предпочтительно проверять без участия тестировщика. В этой статье мы обсудим различные подходы к автоматизации тестов API с использованием Postman, Rest Assured и Karate DSL.

В первой части статьи мы рассмотрели основные и порождающие шаблоны и особенности их реализации на Dart. Теперь пришло время поговорить о структурных шаблонах и о их реализации с использованием синтаксических конструкций языка Dart и возможностей стандартной библиотеки. Мы будем стараться исключать возможности, предоставляемые такими сущностями языка как символы и рефлексия (пакет dart:mirrors), поскольку они не поддерживаются во Flutter (но обозначим возможные их применения при использовании Dart для бэкэнда), предпочитая использовать кодогенерацию во всех ситуациях, где это возможно.

Протокол DNS (Domain Name System Protocol) является одним из важнейших инфраструктурных протоколов для поддержки сети Интернет и первоначально он разрабатывался для максимальной производительности и возможности распределенного хранения неограниченного числа доменных зон. DNS может функционировать поверх UDP-протокола и это уменьшает накладные расходы на установку соединения и избыточный трафик в сети. Но одной из важнейших проблем стала безопасность обмена данными, поскольку клиент в первоначальном варианте протокола не может проверить достоверность информации и это может приводить к подмене ip-адресов злоумышленниками с переадресацией клиента на фишинговый сайт.

Для решения этой проблемы были введены расширения DNSSEC для генерации цифровой подписи ответа. Но сам запрос и ответ при этом не шифровались, что могло быть использовано для ограничения доступа к определенным доменам или для получения на транзитных узлах статистики доступа к хостам. Частично эту проблему решило использование инкапсуляций DNS-over-TLS (DoT, использует TLS для шифрования UDP-дэйтаграмм) и DNS-over-HTTPS (DoH, передает запросы и ответы поверх HTTPS-подключения), которые функционируют поверх TCP. В первом случае запрос более компактный (но может быть обнаружен по анализу трафика), во втором DNS-диалог неотличим от подключения к сайту или веб-сервисам, но при этом существенно увеличивает избыточной трафик (даже при использовании HTTP/2), а также вынужденно добавляет заголовки (которые могут использоваться для трекинга и перехвата cookies). Но можно ли как-то объединить преимущества UDP и DoH? Встречаем DNS-over-QUIC, который был утвержден в RFC9250 как Proposed Standard.

В последние годы растет популярность фреймворка для кроссплатформенной разработки приложений Flutter, а вместе с ним вторую жизнь получил и язык программирования Dart. Dart создавался как потенциальная замена JavaScript и мог бы занять нишу, которая сейчас принадлежит TypeScript, но по ряду причин он так и оставался длительное время "одним из проектов Google", который не был оценен ни для использования в web (после транспиляции в JavaScript), ни для создания серверных или десктопных приложений.

При этом компилятор Dart создает оптимизированный высокопроизводительный код для основных операционных систем и может также использоваться для компиляции в другие аппаратные архитектуры (например, для микроконтроллеров) и, в целом, Dart может использоваться как язык общего назначения для создания серверных приложений (Shelf, Aqueduct), устройств умного дома (с целевой платформой ARM и пакетом dart_periphery) и, конечно, десктопных, мобильных и веб-приложений (Flutter).

И все же язык обладает определенным набором особенностей, которые надо учитывать при реализации кода и использованию типовых паттернов проектирования. В этой статье мы рассмотрим примеры реализации самых часто используемых основных и порождающих шаблонов на языке Dart (будем использовать возможности наиболее актуальной версии Dart 2.17), а во второй части статьи будут рассмотрены более сложные структурные и поведенческие паттерны.

В конце прошлого года движок Flame для создания игровых приложений на Flutter опубликовал первую стабильную версию 1.0 и анонсировал большие изменения в системе миксинов, подходах к управлению компонентами и созданию сцены из иерархии объектов, каждый из которых может выступить в роли контейнера. Прежде всего Flame ориентирован на двумерную графику (спрайты, системы частиц, визуальные эффекты), но возможности Skia позволяют использовать трехмерные преобразования и обеспечивать работу с шейдерами, благодаря чему можно приблизиться к созданию трехмерных игр. В этой статье мы обсудим возможный путь создания трехмерных компонентов в Flame с произвольной визуализацией с использованием компилируемых шейдеров.

Любые Open Source проекты потенциально подвержены риску вредоносной модификации сторонними контрибьюторами и уязвимость может появиться на любом уровне распространения кода — от исходных текстов до двоичных артефактов, которые связываются с прикладными программами. Кроме того, нередко в библиотеках и подсистемах Linux обнаруживаются ошибки, которые могут привести к нарушению функционирования системы, аварийному завершению приложения или обходу механизмов безопасности и важно иметь возможность быстро обнаружить все затронутые этой ошибки компоненты и выполнить выпуск заплатки для 0-day уязвимости.

Для решения всех этих задач Linux Foundation в 2010 году предложил формат для описания юридических аспектов использования программного обеспечения (в частности, лицензии), происхождения артефакта (исходного кода или двоичного файла), способов контроля целостности объекта, а также зависимостей от других объектов. В 2021 году формат был принят как стандарт ISO/IEC 5962:2021 (спецификация SPVX V2.2.1) и является основой для определения SBOM (Software Bill of Materials), которые описывают зависимости компонентов, способы их верификации и описание цепочки поставок для валидации источника.

В статье мы обсудим общие принципы описания SPDX и инструменты (включая недавно открытый Microsoft SBOM Tool, ранее назывался Salus), для создания SPDX/SBOM (в том числе, для автоматической генерации на основании файлов спецификации зависимостей проекта).

Безопасность приложения определяется всеми уровнями - от операционной системы и компилятора до используемых пакетов/плагинов и кода самого приложения. Особенно этот вопрос актуален, когда значительная часть используемых компонентов поддерживается сообществом и не контролируется единой организацией или фондом и, чем более популярной становится платформа, чем больше пакетов появляется и чем больше становится кодовая база платформа, тем больше вероятность возникновения уязвимостей разного уровня (особенно в низкоуровневом коде на C++, где возможна утечка памяти, переполнение буфера, состояние гонки и другие неприятности), а также внедрения вредоносного кода разработчиками из сообщества (начиная от безобидных баннеров, до внедрения шпионского кода, бэкдоров и деструктивных функций). В статье мы обсудим какие векторы атак возможны в Dart, какие меры предпринимает сообщество и Google для снижения рисков при создании платформы и пакетов (и про бейджик openssf), и как можно обезопасить себя.

Система контейнерной оркестрации Kubernetes де факто стала золотым стандартом в DevOps, как универсальный инструмент управления конфигурацией и автоматической поддержки ожидаемого состояния системы. Но, даже при использовании Managed Kubernetes решений (например, Amazon EKS, GKE или решений от Яндекс Облака или Mail.Ru), некоторые сервисы провайдера размещаются за пределами Kubernetes (например, S3-совместимое хранилище, брокеры очередей или базы данных) и хотелось бы иметь возможность управлять с использованием общей конфигурации. В статье мы обсудим возможности использования проекта Crossplane (входит в Incubating CNCF), а также посмотрим на код провайдера на примере управления базами данных MySQL.

Библиотеки PAM (Pluggable Authentication Module) используются для добавления сложного сценария проверки учетных данных и выполнения дополнительных действий при аутентификации пользователя и доступе к службам. В этой статье мы разберемся с внутренней архитектурой PAM, особенностями конфигурации и сделаем простой модуль для отправки уведомлений в Slack при входе пользователя в систему.

Как известно, пользователи и группы в Linux определяются по целочисленному идентификатору, который используется при описании владельца и группы файла, а также для создания контекста текущего пользователя после авторизации. Но как это работает внутри? И можно ли создать свою реализацию для взаимного преобразования имен и идентификаторов и для аутентификации пользователей? В этой статье мы детально рассмотрим анатомию подсистем NSS (Name Service Switch) и создадим свою простую реализацию подсистем для использования с текстовым файлом со списком пользователей и паролей. Во второй части статьи мы поговорим о PAM и обсудим возможные способы ее реализации и применения.

При описании конфигурации инфраструктуры и развертывания информационной системы нередко случается ситуация, когда в исходные тексты или в yaml-файлы попадают секреты и ssh-ключи, которые используются для управления облачной инфраструктурой или серверами системы. Конечно же, хорошей практикой является использование систем безопасного хранения токенов доступа (например, HashiCorp Vault), но иногда, по невнимательности, секреты все же попадают в репозитории системы и хорошо, если они не являются публичными. В этой статье мы обсудим возможности инструментов SpectralOps для отслеживания и исключения таких ситуаций.

В целом компания SpectralOps (сейчас принадлежит Check Point) занимается разработкой и развитием инструментов, уменьшающих вероятность публикации чувствительной информации и предлагает целое семейство продуктов для разработчиков:

Обеспечение надежного функционирования системы при развертывании обновления системы требует запуска тестов разного уровня - от модульных тестов отдельных компонентов до интеграционных тестов, проверяющих в staging-окружении работу системы в целом. Но не менее важны для оценки готовности системы к большой кратковременной пиковой нагрузке (или злонамеренным атакам) выполнение нагрузочных тестов. В июле 2021 года компания Grafana Inc приобрела продукт k6, который изначально был ориентирован на запуск высокопроизводительных распределенных нагрузочных тестов, и это положительно повлияло на его дальнейшее развитие как встраиваемого инструмента для запуска тестов в облачных инфраструктурах или Kubernetes. В этой статье мы рассмотрим один из возможных сценариев использования k6 для тестирования сервиса в конвейере CI/CD.

Часто возникает ситуация, когда нужно развернуть приложение одновременно в нескольких облаках, совместить облачную инфраструктуру и управляемый Kubernetes-кластер или предусмотреть возможную миграцию сервиса в будущем. Одним из возможных решений для создания универсальной конфигурации может быть использование проекта Pulumi, который позволяет публиковать приложения в разные облака (GCP, Amazon, Azure, AliCloud), Kubernetes, провайдеры (например, Linode, Digital Ocean), системы управления виртуальной инфраструктурой (OpenStack) и в локальный Docker. В этой статье мы рассмотрим основные идеи проекта, создадим универсальную конфигурацию для простого Python-приложения с базой данных и настроим непрерывную доставку.

Одной из проблем развития бортовых систем для автомобиля является создание качественного переносимого программного обеспечения, которое бы работало на бортовых системах разных автопроизводителей и могло быть скомпилировано под разные аппаратные и программные архитектуры. Несмотря на очевидную актуальность, задача осложнялась прежде всего тем, что большинство автопроизводителей предпочитало создавать собственные проприетарные операционные системы, что затрудняло создание переносимого программного обеспечения. Ситуация изменилась со стартом проекта Automotive Grade Linux (AGL), поддерживаемыми крупными компаниями такими как Toyota, Mazda, Suzuki, Ford и Mercedes Benz и производителями медиасистем (например, Panasonic). И в планах развития проекта Flutter на 2022 год обозначено развитие поддержки AGL как целевой платформы для приложений. В этой статье мы рассмотрим основные идеи создания переносимых приложений для AGL на Flutter.