Могучий русский язык и предиктивный ввод в умной клавиатуре
Русский — это вызов даже для самых продвинутых языковых моделей. Одна из ключевых причин — его морфологическая сложность. В отличие от английского языка, где у слов относительно немного форм, русский язык отличается большим количеством словоформ, которые образуются с помощью приставок, суффиксов и окончаний.
Это означает, что одно лексическое понятие, например глагол «читать», может породить десятки различных форм: «читаю», «читаем», «читаешь», «прочитал», «прочитала» и так далее. Для модели предиктивного ввода это серьезная проблема: чтобы корректно предсказывать или завершать такие слова, ей нужно либо обладать глубоким пониманием морфологии, либо иметь достаточно большой словарь, который покрывает все возможные варианты словосочетаний.
Мы увеличили размер словаря для русского языка до 40 тысяч слов и использовали модель Char CNN + RNN. Так удалось добиться прироста метрики KSS (количество сэкономленных нажатий) на 60%.
Читайте в статье ИИ-инженера Вадима Воеводкина из YADRO, как его команда улучшила предиктивный ввод на планшетах KVADRA_T и с какими сложностями столкнулась.
Как тестируют функцию Circuit Switched Fallback, которая помогает общаться с родственниками
Представим, что вы звоните семье со смартфона в 4G-сети. В вашей сети нет (или временно недоступна) поддержка голосового звонка через сеть 4G. Не имеет значения, в какой сети находится второе устройство.
Что происходит в сети оператора при таком звонке:
Телефон отправляет на базовую станцию (eNB) вызов.
Базовая станция связывается с ядром сети (MME) и запрашивает процедуру CSFB для исходящего звонка, дожидается от ядра сети подтверждения о возможности такого перехода.
После этого отправляет телефону информацию о новом подключении к 2G-сети, которое он должен установить.
После этого базовая станция завершает обслуживание абонента в 4G-сети, обслуживание переходит к станции 2G.
Голосовой вызов осуществляется через 2G-сеть.
Для тестирования такого сценария используют симулятор окружения базовой станции. Он имитирует обмен как с мобильным телефоном, так и с пакетным ядром сети. При этом базовая станция работает в обычном режиме, используются штатные методы управления и разъемы подключения, что позволяет нам рассматривать ее как черный ящик.
Симулятор позволяет автоматизировать этот этап тестирования и увеличить скорость тестов и повторяемость результатов. CSFB — это базовая функциональность, поэтому проверка проходит регулярно.
Для успешной проверки CSFB задачу декомпозируют, разделяют на уровни. О двух других ступенях «пирамиды» — тестировании в GSM-сети и системном тестировании — рассказала инженер YADRO Анастасия Беднова в своей статье.
Android-приложение «Контакты»: работает — не трогай
У многих полей контакта есть типы. Например, у номеров телефонов или адресов электронной почты по умолчанию есть типы «рабочий» и «домашний». Аналитики сказали, что нужно реализовать дополнительные типы и дать пользователю возможность создавать свои. Звучит легко, но на деле оказалось совсем непросто.
Чтобы заменить стандартные типы полей, нужно добавить новую базу данных с доступными типами полей, а также реализовать отображение и возможность выбора поля. Для этого пришлось во многом переписать код редактирования полей контакта, где и без этого логика была непростой. Теперь стало совсем сложно: при добавлении или обновлении поля в contentProvider нужно указывать тип поля, так что мы начали указывать «custom».
После добавления кастомных типов приложение потеряло стабильность, появились кейсы, в которых кастомные типы работали неправильно. Один из них приводил к крашу: база данных не успевала создаваться при открытии интента на редактирование контакта.
Изначальный путь пользователя — это открыть приложение и увидеть список контактов с аватаркой, именем и номером телефона. Пока этот список подгружался на экране, база данных обычно успевала создаться. Но мы не учли, что при открытии интента на редактирование контакта из другого приложения сразу появляется экран редактирования — в этом случае база данных не успевала инициализироваться.
Создание схемы БД и инициализация стандартными значениями происходила в отдельном потоке, так что у нас получилась небольшая гонка потоков. UI готов отобразить экран и идет в БД за данными, но БД не успевает инициализироваться, так что запрос приводил к критической ошибке. Баг воспроизводился при попытке обратиться к БД только при первом холодном запуске на устройстве или после очистки данных, так как здесь приложению приходится заново создавать схему базы данных.
Пришлось опять добавлять костыль: в отдельной корутине ожидать инициализации БД и только потом начинать рисовать экран...
Дмитрий Бражник, старший инженер-программист в департаменте разработки мобильных приложений YADRO, рассказал в статье, как его команда пыталась допилить стандартное AOSP-приложение «Контакты» и к чему они в итоге пришли.
Собеседование инженера: взгляд со стороны нанимающих специалистов
Интересно бывает послушать, над какими проектами работал человек. Но эта часть биографии частенько оказывается приукрашена и в позиционировании кандидата не помогает. В резюме может быть 30 лет опыта с описанием задач, спрашиваешь по ним, а ответа нет. Потому что человек, например, все 30 лет копипастил одно и то же, не вдаваясь в суть. Вообще, обсуждение опыта снижает эффективность собеседований, делает их… расхлябанными, что ли.
Частая ситуация на собеседовании — недостаточно глубокое погружение в интерфейс, с которым у кандидата был опыт работы. Например, указан опыт работы с протоколом USB. На собеседовании после нескольких вопросов по архитектуре протокола оказывается, что кандидат просто вставлял готовый IP без понимания принципов его работы. Но в резюме это заявлено как полноценный опыт работы с протоколом.
Когда смотришь, где человек работал, это не значит, что он там таки работал и надо трепещать перед громкими именами или регалиями. Важно не где ты работал, а что и как ты делал. Иначе будет как в старом советском анекдоте: один хвалится, что у него тетя в исполкоме работает, а в конце все узнают, что работает она там уборщицей и ничего не решает...
Семеро специалистов YADRO по направлениям схемотехники, верификации, RTL-дизайна, FPGA и аппаратной разработки рассказали, как подготовиться к собеседованию инженера, как настроиться на диалог с компанией и получить дополнительные очки в свою пользу.
Проверка знаний в эпоху LLM: опыт преподавателя из Политеха
Сегодня преподаватели сталкиваются с новой реальностью: даже уникальные задания и ежегодное обновление вариантов не гарантируют защиту от списывания. Студенты могут принести работающий код, созданный с помощью LLM-моделей, но совершенно не понимать, как он устроен. Устные собеседования могли бы помочь, но они требуют много времени и экспертности — до 15 минут на одного студента, что превращается в колоссальную нагрузку.
На курсах «Введение в язык программирования Go» и «Технологии параллельного программирования на C++» в Политехе лабораторные работы проверяются с использованием системы контроля версий GitLab. Это позволяет упорядочить процесс сдачи и проверки заданий.
Каждый студент работает в личном fork-репозитории, созданном на базе основного, предоставленного преподавателем. Решения оформляются строго по структуре: каждая задача и подзадача — в своей директории, обязательное наличие модуля go.mod, а точка входа программы размещается в cmd/. Сдача работы происходит через создание Merge Request в основной репозиторий, где автоматически запускаются все проверки.
Пример хронологии коммитов и Merge Request'ов, отправленных в основной репозиторий.
Система GitLab CI/CD выполняет серию автоматических тестов, включая проверку структуры проекта, сборку и выполнение юнит-тестов. Если хотя бы один из этапов не пройден, работа не допускается к оценке. Это дисциплинирует студентов и делает процесс проверки прозрачным и объективным.
После успешного прохождения автоматических тестов работа передается на ручную проверку преподавателю. Он дает обратную связь и при необходимости запрашивает доработку через комментарии в Merge Request. Только после этого, если все в порядке, решение попадает в основной репозиторий и считается принятым. Такой подход делает процесс обучения максимально приближенным к реальной командной разработке в индустрии.
В статье Игорь Никифоров, преподаватель с 14-летним опытом, делится проблемами, с которыми сталкиваются вузы из-за массового использования нейросетей. Он рассказывает, как это влияет на обучение, почему преподаватели вынуждены тратить больше времени на проверку, и какие шаги можно предпринять, чтобы сохранить учебный процесс.
В середине XX века социолог Никлас Луман разработал метод организации информации Цеттелькастен (Zettelkasten). Он создавал множество заметок и, чтобы не терять знания, начал вести картотеку. Система нумерации и ссылок помогала ориентироваться в карточках. У каждой заметки был уникальный номер, отражающий тему и дополнения.
Спустя полвека идеи Лумана остаются актуальными. Более того, появились программные обеспечения для ведения базы знаний. Заметки сохраняются в облаке и отображаются в виде графа.
Все заметки Дмитрия в виде графа
Веб-разработчик в YADRO Дмитрий сохраняет заметки в сервисе Obsidian. Дмитрий услышал о ПО от инженера и блогера Николая Тузова и понял, что система, похожая на картотеку, ему близка.
Программа оказалась понятной, легко адаптируемой под разные задачи. Когда Дмитрий перенес данные из Notion в Obsidian, образовалось несколько графов: по Go, хешированию и базам данных. В этой базе знаний все концепции в Go пересеклись в двух точках — интерфейсе и горутинах. Есть еще слайсы, но в основном все «лучи» сходятся именно в эти две точки.
Как Дмитрию удалось упорядочить большие объемы знаний и кому он рекомендует Цеттелькастен, читайте в статье →
Работаем со свертками в PyTorch с помощью библиотеки CUTLASS и алгоритма Implicit GEMM
Библиотека CUTLASS — это набор C++ шаблонов для реализации высокопроизводительного GEMM в коде. Она предоставляет структурные блоки, из которых можно собрать или просто вызвать операцию GEMM. Поддерживает вычисление смешанной точности, использование TensorCores и других примитивов, доступных для быстрого вычисления. В отличие от cuBLAS, это open source-библиотека. Ее относительно просто интегрироватьь и модифицировать под свои задачи.
Подход основан на тайлинге — разбиении задачи на мелкие подзадачи и распараллеливании. Как устроен процесс работы:
Процедура начинается с работы с глобальной памятью: выбираем блоки данных (тайлы) из глобальной памяти для умножения матриц.
Затем используются примитивы для переноса этих данных в shared-память, где происходит тайлинг на этом уровне.
После выполняется работа на уровне варпов и регистров с использованием TensorCores или CUDA Cores.
Эти настройки также можно конфигурировать с помощью библиотеки. Основная цель — максимально перенести данные для вычислений в регистры процессоров и свести к минимуму операции с глобальной памятью, поскольку они вызывают наибольшие задержки.
Библиотека предоставляет различные уровни специализации и конфигурирования: Device-level, Kernel-level, Block-level, warp, Instruction. Весь API представлен в виде шаблонов, из которых можно набирать те типы, которые потом инстанцируются для реализации нужного тайлинга.
Какие еще инструменты могут расширить функциональность PyTorch для работы с большими свертками? Как выбрать алгоритм, подходящий для обучения моделей? Узнаете из статьи →
На пределе железа: протестировали резервное копирование 32 виртуальных машин с дедупликацией «на лету»
Один из сценариев тестирования СХД TATLIN.BACKUP и СРК Кибер Бэкап, в котором резервное копирование производилось с inline-дедупликацией внутри каждой ВМ.
В каждую из 32 виртуальных машин установлены агенты Кибер Бэкапа, а также агенты Tboost, протокола дедупликации в TATLIN.BACKUP. Каждый агент сохраняет резервную копию в локальную папку, подключенную к целевому хранилищу через протокол T‑BOOST (точка монтирования /mnt/esxboost). В качестве хранилища резервных копий в Кибер Бэкапе указано 32 хранилища — по числу ВМ.
Чтение на источнике TATLIN.UNIFIED
График показывает, что мы достигли ограничений оборудования: пропускной способности четырех портов Ethernet по 25 Гбит/с, через которые подключен диск TATLIN.UNIFIED к хостам виртуализации.
Совокупный объем данных, переданных Кибер Бэкапом для полного резервного копирования всех ВМ, составил ~ 4 192 ГБ (32 × 131 ГБ). Параллельно выполнялись 32 операции резервного копирования. Время выполнения операций — от 8 до 11 минут.
Про совместное использование TATLIN.BACKUP и Кибер Бэкапа читайте в статье с результатами тестирования трех сценариев резервного копирования 32 виртуальных машин.
Проверяй, пока не поздно: функциональная верификация в жизненном цикле СнК
Представьте, что вы строите сложнейший механизм, где сотни тысяч элементов должны работать в идеальной синхронности. Ошибка в одном месте — и вся система может остановиться или начать вести себя непредсказуемо. Именно для того, чтобы этого не произошло, существует верификация — один из самых важных этапов разработки систем на кристалле (СнК).
Без верификации вероятность ошибок очень высока, и это может привести к некорректной работе оборудования. Поэтому задача инженеров-верификаторов — тщательно изучать документацию, разрабатывать тестовые сценарии и подтверждать, что аппаратура соответствует заявленным характеристикам и функционирует так, как задумано.
Время, необходимое для прохождения жизненного цикла СнК, зависит от команды и применяемых технологий. В индустрии считается, что эффективная работа означает выпуск нового тейп-аута (tape-out) раз в полгода. Это говорит о том, что процессы налажены и команда работает с высокой скоростью.
Жизненный цикл верификации в СнК
Однако сроки могут значительно варьироваться. Если проект строится на полностью собственных разработках без использования сторонних решений, цикл разработки может растягиваться до трех лет. Все определяется стратегией компании: в одних случаях обновления происходят каждые шесть месяцев, в других — раз в несколько лет.
В статье Дмитрий Кишко, руководитель группы функциональной верификации в YADRO, рассказал, как устроена работа инженера-верификатора, какие задачи решает команда на этапе проектирования и почему верификация — это отличный вход в профессию для тех, кто интересуется «железом» и кодом.
Верните мой 2007-й: превращаем старые фотки в снимки с зеркалок с помощью ИИ
Однажды группе ИИ-энтузиастов пришла идея: а что если обучить искусственный интеллект улучшать смартфонные снимки до профессиональных с помощью парных фотографий? Задумка понравилась. Для сбора датасета выбрали актуальные в то время Sony Xperia Z, iPhone 3GS, BlackBerry Passport и цифровую зеркалку Canon EOS 70D в качестве эталона. Модель обучили улучшать фотографии, сделанные на смартфонах, в соответствии с такими же изображениями, полученными с камеры. Проект реализовали, исходный код опубликовали на GitHub, а подробное описание — на arXiv.org. Но что же в нем интересного сейчас, почти десять лет спустя?
DPED не просто применяет косметические фильтры. Датасет способен значительно улучшать фотографии на уровне структуры изображения, детализации, динамического диапазона и цветопередачи, приближая результат именно к профессиональной зеркальной фотокамере, а не просто «улучшая» фото.
Открытый исходный код и доступность датасета DPED позволяют легко адаптировать, изменять и дорабатывать модель. Это дает большие возможности исследовательскому сообществу и разработчикам мобильных приложений. Именно гибкость и понятность архитектуры делают DPED хорошим кандидатом для дальнейших экспериментов и улучшений.
В своей статье команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ им. Р. Е. Алексеева запустила DPED на свежих версиях софта, преодолев все проблемы совместимости, и попробовала через него улучшить фото с современного планшета.
Как оптимизировать расходы на резервное копирование
10 апреля в 13:00 подключайтесь к вебинару, где специалисты YADRO и Киберпротект расскажут об эффективном использовании системы резервного копирования (СРК) в связке с системой хранения данных (СХД). СРК занимается резервным копированием и восстановлением данных, а СХД — их надежным хранением, компрессией и дедупликацией.
В прямом эфире вы сможете:
узнать о возможностях СРК Кибер Бэкап и СХД TATLIN.BACKUP,
выбрать подходящий сценарий их совместного использования,
посмотреть в реальном времени, как происходит резервное копирование средствами Кибер Бэкапа на TATLIN.BACKUP с помощью T-BOOST,
задать вопросы экспертам.
Одной из тем вебинара станет технология T-BOOST. Она позволяет выполнять дедупликацию данных на источнике: защищенном хосте или узле хранения Кибер Бэкапа. После дедупликации в хранилище передаются только уникальные данные. Это позволяет минимизировать объем передаваемых данных (снизить нагрузку на сеть) и ускорить резервное копирование.
Как выбрать языковую модель для семантического поиска
Для сопоставления смысла запроса пользователя и смысла чанка в базе знаний нужна языковая модель, которая понимает семантику.
Принцип работы моделей Bi-Encoder и Cross-Encoder
Bi-Encoder — состоит из двух трансформеров encoder-only. С помощью passage-encoder получаются эмбеддинги для всех чанков в базе знаний. Запрос от пользователя кодируется с помощью query-encoder. На этапе поиска высчитывается косинусное расстояние между query-embedding и passage-embedding. Мы получаем поисковую выдачу после ранжирования всех пассажей по убыванию косинусного расстояния. В отличие от следующей архитектуры Cross-Encoder, можно заранее сохранить эмбеддинги для пассажей и использовать их для подсчета расстояния.
Cross-Encoder — трансформер с архитектурой encoder-only и ранжирующим слоем. Этот слой выдает оценку релевантности запроса к пассажу. На вход подается двойка: запрос и пассаж. Cross-Encoder лучше понимает семантическую связь между пассажем и запросом, но для каждого пользовательского запроса он работает медленнее, так как для оценки релевантности запроса и пассажей, cross-encoder нужно запустить N раз, где N — количество пассажей.
Мы будем использовать Bi-Encoder, так как у нас много пассажей в базе знаний.
Для выбора модели удобно использовать открытый бенчмарк MTEB с рейтингом по различным моделям в зависимости от вашей задачи. Для нас лучшей оказалась модель multilingual-e5-large, Bi-Encoder c 560M параметров и размером эмбеддингов в 1024 элемента.
Инженер по разработке ПО искусственного интеллекта Павел Яковлев максимально подробно рассказал в статье, как его команда разрабатывает и оптимизирует семантический поиск по сложным документам: PDF, HTML и DOCX.
Какие проблемы решает алгоритм FastCDC при дедупликации данных
FastCDC — это алгоритм разбиения данных на блоки переменной длины (Content Defined Chunking, CDC). В отличие от нарезки с фиксированной длиной блока, FastCDC решает проблему смещения границ (boundary-shift problem), которая возникает при вставке новых данных в файл. Например, если в начало файла добавить байт, то при использовании разбиения с фиксированной длиной все последующие блоки изменятся.
Алгоритмы с переменной длиной блока, такие как FastCDC, устраняют эту проблему, поскольку устанавливают границы блоков на основе содержимого данных, используя хеш-функцию для определения неких избранных последовательностей байтов. Впрочем, если байт будет добавлен в середину какого-то блока, то этот блок будет потерян, а граница будет корректно определена уже для следующего от него блока.
FastCDC выделяется среди других алгоритмов высокой скоростьюобработки потока байтов. Основная вычислительная нагрузка на систему создается операциями разбиения данных на блоки и их сжатия, поэтому оптимизация алгоритма разбиения напрямую влияет на общую производительность.
Основная идея FastCDC заключается в следующем: среди всех возможных последовательностей байтов (множество A) выделяется подмножество B. Когда в файле обнаруживается последовательность из множества B, алгоритм устанавливает границу блока (anchor) сразу после этой последовательности.
Так как хранение подмножества B напрямую невозможно из-за огромного количества возможных последовательностей, используется хеш-функция. Она преобразует каждую последовательность байтов в числовое значение, которое определяет класс этой последовательности.
После нахождения опорного байта (anchor) алгоритм проверяет, удовлетворяет ли он дополнительным условиям. Например, FastCDC не создаст новый блок, если точка находится слишком близко к границе предыдущего блока и минимальный размер блока еще не достигнут. Если опорные байты не найдены, система отрежет блок по его максимально допустимому размеру.
Добавление всего одного нового байта 0 сдвигает все предыдущие байты вправо, что приводит к изменению содержимого каждого блока:
Эксперт по разработке ПО отдела систем обработки данных в YADRO Ростислав Ефремов в статье подробно объяснил, что такое дедупликация данных, какую роль она играет в системах резервного копирования и как работает в СХД TATLIN.BACKUP
Ответ: Это Shield box — экранированная коробка, внутри которой размещаются сотовые телефоны. Ее используют тестировщики телеком-оборудования. Коробка обеспечивает изоляцию сигнала и предотвращает возможность подключения сторонних абонентов к «тестовой» сети.
Если вы знакомы с этим оборудованием или хотите с ним познакомиться, вас могут заинтересовать несколько вакансий в команде Телекома в YADRO.
→ Некоторые из них требуют образования по специальностям Радиотехнологии или Телекоммуникации и опыта работы с системами GSM/LTE.
Команда занимается тестированием функционала базовой станции LTE/GSM на системном уровне в лаборатории или на площадке заказчика. Специалисту нужно будет разрабатывать тестовые сценарии и готовить требования к тестам радиоподсистемы LTE/GSM. Здесь у кандидата должно быть высшее образование в области телекоммуникаций или радиотехнологий, а также знание стандартов GSM//LTE, топологии и интерфейсов мобильной сети.
Команда готовит тестовые сценарии для драйв-тестов, проводит их по подготовленным тест-планам и измеряет ключевые показатели производительности базовых станций LTE/GSM с помощью измерительных комплексов. Здесь также от кандидата требуются знания принципов и законов радиосвязи, базовое понимание теории антенн и их характеристик.
→ А вот несколько вакансий, где глубокое знание телеком-технологий не является решающим фактором при отборе кандидатов.
Команда занимается тестированием собственного железа и ПО. Направление создает конкурентную линейки RAN-продуктов для мобильных сетей последних поколений — базовые станции LTE/GSM и удаленные системы управления ими. Опыт работы с телекоммуникационными системами GSM/LTE будет преимуществом.
Команда ищет инженеров по автоматизированному тестированию в несколько команд в направление разработки решений для телекоммуникаций. Необходимый опыт в автоматизации с использованием Jenkins GitLab — от двух лет. Здесь ждут кандидатов с уверенным знанием Python, Linux и пониманием сетей, базирующихся на TCP/IP.
Вам больше по душе ручное тестирование? Есть вакансия и для вас. Здесь ждут кандидатов с уверенным знанием теории тестирования (опыт — от трех лет), Linuх и пониманием сетей, базирующихся на TCP/IP.
О направлении
Команда Телеком с нуля создает телекоммуникационные решения для беспроводных мобильных сетей и сопутствующих услуг. Инженеры разрабатывают первые в России базовые станции стандартов GSM/LTE, реализуя полный стек телекоммуникационных протоколов для базовых станций и элементов ядра сети, а также системы управления и мониторинга. Здесь вы будете в хорошей компании: продукт создают профессионалы с многолетним опытом, многие из них работали в ведущих мировых телекоммуникационных корпорациях.
А как тестируют функции базовой станции, читайте по ссылке →
Петля времени в пайплайне для уменьшения числа галлюцинаций в LLM
Это — грубая схема работа RAG-пайплайна, который использует одна из ML-команд в YADRO.
Задача команды: улучшить качество выдаваемых ответов на запросы пользователей, исключив галлюцинации.
Что сделали инженеры?
Решили дообучить базовую модель при помощи LoRA на специально собранном датасете для ситуаций, когда в контексте нет ответа на вопрос пользователя. На тот момент в качестве базовой модели LLM использовали saiga_mistral_7b, которая нетребовательна к ресурсам и долгое время была в топе на Russian SuperGLUE. Есть модели лучше, но, как правило, они либо огромные, либо имеют проблемы с лицензией в России, в том числе все, что основаны на LLaMa.
Самое главное: в этом RAG-пайплайне ML-инженеры решили сделать опциональную петлю, в которой проверяли бы каждый найденный фрагмент контекста на релевантность вопросу пользователя. Только те куски контекста, которые пройдут проверку, будут попадать в финальный вопрос для LLM.
Чтобы петля фильтрации работала правильно, нужен некий маркер, который позволяет однозначно определить, что модель считает кусок контекста нерелевантным.
Что это и за маркер? И к каким результатам привела оптимизация работы модели, читайте по ссылке →
Спойлер: Модель DeepSeek-R1-Distill-Qwen-7B уступила saiga_mistral_7b по качеству, несмотря на то, что первая намного новее и вооружена механизмом reasoning.
Конкурентность в Go: просто запустить — сложнее управлять
Go предлагает удобный механизм конкурентности, позволяющий запускать задачи максимально просто — достаточно добавить go перед вызовом функции, и она начнет выполняться параллельно с основным потоком. Однако для эффективного использования такого кода важно правильно управлять синхронизацией: собирать результаты, обрабатывать ошибки и учитывать возможные сценарии выполнения. На практике этому аспекту часто уделяют недостаточно внимания.
Полезные материалы о конкурентности в Go можно найти в блоге Дейва Чени. Он рассматривает различные решения в Go, объясняя их происхождение и способы использования. В своих статьях он также подробно разбирает тему конкурентности.
Закрытый канал не блокируется. После закрытия в него нельзя отправлять данные, но можно читать. Если данных нет, возвращается нулевое значение. Это удобно при использовании range, который автоматически завершает цикл.
Закрытие канала уведомляет все горутины. Вместо того чтобы отправлять сигнал каждой горутине, достаточно закрыть канал — все ожидающие горутины получат сигнал завершения.
В отличие от языков вроде C, где конкурентность управляется через блокировки и разделяемую память, в Go используются более простые и безопасные механизмы. Однако работа с каналами требует понимания нюансов.
Владислав Белогрудов, эксперт по разработке ПО в YADRO, собрал полезные материалы про конкурентность в Go. В статье — блоги, выступления и книги, которые помогут разобраться, как в Go работать с горутинами и каналами без хаоса и дедлоков.
В YADRO есть команда, которая разрабатывает и отлаживает UEFI для самых разных продуктов компании. Подробнее о ней — в видеоролике → .
Первая особенность работы — в распределенной команде. Серверы, на которых инженеры разрабатывают прошивки, могут находиться в Москве, а разработчики — в других городах: от Владивостока до Калининграда и от Архангельска до Смоленска.
Системы, для которых разрабатывают прошивки в YADRO, делятся на два типа: с BMC и без него.
Больше о работе команды и, в целом, об истории BIOS/UEFI читайте в статье →
А если тоже хотите стать «поваром» UEFI, присмотритесь к одной из вакансий:
SystemVerilog отжил свое? На пятки наступает Scala/Chisel?
DARPA, управление перспективных исследовательских проектов Минобороны США, описывает Chisel как технологию, позволяющую маленьким командам создавать большие цифровые проекты. И я вполне могу с этим согласиться, но есть нюансы.
Chisel — это, по сути, библиотека Scala, а точнее, Domain Specific Language. Языку Scala уже больше 20 лет, он постоянно развивается, сочетает функциональное и императивное программирование. При написании кода на Scala вам доступны все библиотеки Java.
Scala — это масштабируемый язык, который позволяет добавлять свои языковые конструкции. На основе Scala можно создать язык под свои задачи. Так 12 лет назад и поступили инженеры в Беркли: выкинули из Verilog 90%, оставив только нужное, и обернули все это в Scala. Получился Chisel.
Chisel используют прежде всего для создания RTL-описаний. Также он позволяет проводить симуляцию несложных модулей. Это удобно для создания юнит-тестов и моделирования работы различных алгоритмов. В плане симуляции не стоит возлагать на Chisel такие же надежды, как на System C или что-то подобное. Симулировать вы сможете лишь очень маленькие схемки, а генерировать — хоть целые кластеры из тысяч процессоров, вообще все, что захотите.
На основе Chisel/Scala можно написать свой HLS-инструмент (High Level Synthesis), где одним росчерком пера вы будете создавать очень большие схемы, что с использованием одного Verilog невозможно.
В блоге YADRO Денис Муратов подробно сравнил Chisel/Scala с SystemVerilog в создании RTL-описаниях, раскрыл основные преимущества и недостатки альтернативы, а также ее дополнительные возможности — функциональное программирование и переиспользование модулей.
Как не надо использовать Assert, если реализуете подход Design by Contract
Использовать Assert вместо if err != nil { return err}
Одно из неправильных применений Assert — это замена им проверки, которая действительно должна быть и на которую нужно реализовать реакцию в коде.
Выполнять вычисления при вызове Assert
Еще одна распространенная и трудно выявляемая ошибка — это выполнение вычислений и присваивание значений переменным прямо при вызове Assert, которые могут быть упразднены при оптимизации кода компилятором:
e.g. Assert(i++ > 0, “осторожно, не факт, что в релизе i увеличится”),
Assert(call_to_f1(), “осторожно, не факт, что call_to_f1() будет вызвана в релизе”).
Удалять Assert, несмотря на то, что это часть описания контракта
Непонимание, что Assert — это реализация контракта, может привести к тому, что разработчик, незнакомый с DbC, захочет просто удалить проверку. Однако нужно всегда помнить, что срабатывание Assert говорит о нарушении контракта одной из сторон. То есть, если срабатывает Assert, надо прежде всего найти баг и пофиксить. А уж если контракт действительно должен быть изменен, Assert подскажет, где находятся участки кода, на которые нужно обратить внимание.
Например, вызывающая сторона может полагаться на некоторое поведение вызываемого кода. И если вызываемый код существенно изменился и контракт не выполнен, то вызываемая сторона тоже должна быть существенно переосмыслена.
В реализации пакета Go 1.23 fmt-функция Printf всегда возвращает err = nil. И практически все игнорируют возвращающееся значение ошибки, тогда как могли бы проверять постусловие assertion.Assert (err == nil). Так, рано или поздно в последующих версиях можно научить код реагировать на err, отличный от nil.
Как правильно применять assertions, если реализуете подход Design by Contract для улучшения производительности кода в продакшене? Читайте в статье →
Командное решение без долгих обсуждений: три проверенных метода
Когда времени мало, а решение нужно принять быстро, важно использовать проверенные методы. Такие подходы помогут оперативно выбрать лучший вариант без лишних обсуждений.
Этот метод помогает команде оперативно выбрать наиболее предпочтительный вариант. Каждый участник получает несколько голосов (например, в виде наклеек, отметок или фишек) и распределяет их между предложенными вариантами. Решение, набравшее больше всего голосов, считается приоритетным.
→ Степень поддержки — оцениваем и ранжируем
Этот метод предполагает, что каждый участник оценивает предложенные варианты по шкале, например, от 1 до 10. Чтобы решение считалось принятым, оно должно набрать средний балл выше установленного порога.
→ Метод NUF — объективный анализ вариантов
Этот метод помогает взвесить все «за» и «против», оценивая варианты сразу по трем ключевым критериям:
Новизна (New): насколько инновационно и оригинально это решение?
Полезность (Useful): решает ли оно реальную проблему?
Осуществимость (Feasible): есть ли ресурсы и возможности для реализации?
Каждый участник ставит оценки от 0 до 10 по каждому критерию, после чего высчитывается средний балл. Затем команда выбирает решения с лучшими показателями, ориентируясь на самые полезные и реализуемые варианты.
Как выглядит колода карт с методами принятия решений
В статье Светлана Болсуновская, стратегический коуч-консультант в YADRO, разбирает причины, по которым коллектив застревает в бесконечных обсуждениях, а также предлагает дополнительные методы, которые помогают не только принять решение, но и сделать его более эффективным.
Автор подарит колоду карт с еще большим количеством методов принятия решений тому, кто поделится своей историей в комментариях. Подробнее об условиях — в конце текста.
