Салют, Хабр! На связи Игорь Пасечник — технический лид направления XR RnD SberDevices. Сегодня я хочу рассказать про одно из наших направлений исследований — разработку генеративных моделей для 3D-контента. 

Современные методы генерации 2D-контента, такие, как 2D-диффузионные модели (Kandinsky 3.0, SDXL), уже достигли впечатляющих результатов и несколько лет являются неотъемлемой частью современности, генеративные видео модели также активно развиваются. Кульминацией развития таких подходов, вероятно, станет представленная не так давно модель Sora. Тем не менее большинство из этих моделей до сих пор испытывают проблемы при генерации консистентных 3D-сцен и объектов.

С другой стороны стороны, существует конвенциональная 3D-графика, а также огромная индустрия и множество прикладных областей, включая игры, XR, дизайн, архитектуру, маркетинг, 3D-проектирование, где используются пайплайны на основе 3D-графики и производится контент на их основе. Методы создания 3D-моделей, такие, как ручное моделирование, 3D-сканирование и фотограмметрия, могут быть трудоёмкими, дорогостоящими и требующими специальных навыков. 3D-продакшн в общем виде использует множество инструментов для создания и рендеринга тяжелой фотореалистичной графики, адаптация генеративных 3D-пайплайнов под такие подходы достаточно тяжела из-за множества инструментов, которые такие пайплайны должны поддерживать. Также адаптация больших латентных генеративных 2D-моделей вроде SORA для прикладных задач фотореалистичной графики может стать альтернативой классическми пайплайнам на основе физического моделирования. Тем не менее, на текущий момент пайплайны работы с графикой, использующие базовый набор примитивов, включая меши, PBR-текстуры, простые модели освещения, закрывают множество прикладных задач и также могут быть востребованы у массового пользователя в случае их демократизации.

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

Rust имеет два основных типа макросов: декларативные и процедурные. Каждый из этих типов служит различным целям и предоставляет различные возможности манипуляции с кодом.

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

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

В этой статье мы как раз и рассмотрим то, как их пишут на Rust.

Начнем с декларативных!

Салют, хабр! В интернете уже довольно много материалов о том, как другие команды строили свои решения для тестирования мобильных приложений (и не только), например: Яндекс Колхоз, Ферма мобильных устройств Selectel, Ферма девайсов VK, Ферма мобильных устройств в Сбере, Мобильная ферма 101 (доклад Антона Малинского).

Я же хочу рассказать про Ферму, которую мы строим в SberDevices. 

Меня зовут Александр Телешов, и я руковожу разработкой Фермы и Чембера (но про это расскажу в другой раз). Под катом вы найдете небольшую хронологию событий развития Фермы, собранные грабли, интересные факты и забавные наблюдения.

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

В последние годы понятие клиентского опыта стало чуть ли не мантрой в бизнесе, и ведь не зря. Пользовательский интерфейс частенько становится причиной успеха того или иного продукта, поэтому анализ клиентского опыта становится не просто nice to have, а must have для каждой компании, считающей себя современными.

Автоматизированные тесты очень важны. Без них программистам приходится тратить огромное количество времени на ручную проверку и исправление кода. К сожалению, многие автотесты также тратят огромное количество времени. Простым и очевидным вариантом является создание широких тестов, которые являются автоматизированными версиями ручных тестов. Но они нестабильны и медленны.

Знающие люди используют моки и шпионы для написания изолированных тестов, основанных на взаимодействии. Их тесты надёжны и быстры, но они имеют тенденцию «блокировать» реализацию, затрудняя рефакторинг, и их приходится дополнять широкими тестами. Кроме того, часто получаются некачественные и трудные для чтения тесты.

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

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

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

История Darth Vader началась в 2011 году. Целью создания Dart было предложить альтернативу JavaScript, которая позволила бы создавать более сложные, высокопроизводительные веб-приложения, облегчая при этом процесс разработки.

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

Язык поддерживает ООП с классами и множественным наследованием, а также функциональные возможности, такие как высшие порядки функций, замыкания и асинхронность и т.п.

Система типов в Dart поддерживает как статическую типизацию, так и типизацию во время выполнения.

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

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

Понятие Quality Gate (дословно ворота качества), предполагает автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки CI/CD.

Использование принципа Quality Gates помогает решать проблемы в коде на ранних этапах, до того, как он обрастёт зависимостями. Так, в частности выявив ошибки в коде на начальных этапах разработки мы потратим меньше времени на тестирование исправленного варианта кода, что в конечном итоге позволит снизить общие расходы на разработку.

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

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

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

В нашем мире, где каждый релиз готовится в спешке, а сами релизы выходят на регулярной основе, что вы делаете, чтобы защитить своё программное обеспечение? Что вы можете сделать, какие вообще есть варианты?

С точки зрения того, что именно представляет собой CI/CD: непрерывная интеграция программного обеспечения — это процесс, целью которого является максимально проверенный дистрибутив.

Хотя характеристику «максимально проверенный» можно интерпретировать по-разному, я полагаю, что это сводится к использованию такого количества тестов, которое позволяет бюджет, а бюджет — это деньги и время.

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

Микросервисная архитектура предполагает декомпозицию монолитного приложения на несколько полностью независимо развёртываемых и масштабируемых сервисов. За пределами этого базового определения, то, что представляет собой микросервис, может быть несколько субъективным. Хотя есть несколько проверенных в бою практик, принятых такими гигантами, как Netflix и Uber, которые всегда следует принимать во внимание. И я расскажу о некоторых из них. 

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

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

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

В операционных системах семейства Windows для автоматизации выполнения задач мониторинга лучше всего использовать Powershell. И далее в этой статье мы рассмотрим несколько полезных скриптов, которые могут упростить мониторинг состояния различных компонентов ОС.

Начнем с мониторинга состояния сетевых портов и взаимодействующих с ними процессов.

Исследование Coursera по отчёту ВЭФ “Future of Jobs Report 2023”

В прошлом году Всемирный экономический форум (ВЭФ) опубликовал доклад Future of Jobs Report 2023. В нём анализируются изменения на рынке труда, а также раскрываются темы внедрения технологий, изменения рабочих мест и актуальных навыков в ближайшие пять лет. В рамках сотрудничества с ВЭФ Coursera провела исследование для отчёта и рассказала, как основанные на навыках подходы к развитию рабочей силы могут помочь вытесняемым с рынка труда работникам получить востребованную профессию.

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

Z-тест, известный также как z-критерий Фишера, представляет собой набор статистических методов для проверки гипотез, которые базируются на предположении о нормальном распределении данных. Эти методы используются для анализа, являются ли средние значения двух наборов данных одинаковыми, при условии, что дисперсия генеральной совокупности известна. Еще они применяются для анализа стандартизированных выборочных средних. Расчёт Z-статистики производится путём деления разности между анализируемой случайной величиной и её математическим ожиданием на стандартную ошибку этой величины.

В этой статье рассмотрим, что такое Z-тест, чем он полезен и сравним его с t-тестом.

В этом руководстве мы рассмотрим разработку веб-приложения по созданию GIF-файлов из видеороликов.

Функциональные возможности приложения:
- Создание GIF из видео на YouTube с определённым временным диапазоном.
- Предварительный просмотр результата перед выполнением фактической конвертации.

Компоненты системы:
- Клиентская часть на React (Next.js)
- Бэкенд-сервер на Node
- Node как Service Worker
- В качестве брокера сообщений — RabbitMQ
- Для хранения данных — MongoDB
- Для хранения медиафайлов — Google Cloud Storage

Полный код проекта можно найти на github, а по этой ссылке посмотреть демо-версию приложения.

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