Как стать автором
Обновить
463.08
YADRO
Тут про железо и инженерную культуру
Сначала показывать

ping: permission denied (are you root?)

Знакомы ли с этим сообщением об ошибке? И знаете ли, как ее исправить?

Этот запрет на отправку ICMP-пакетов внутри контейнера можно получить при выполнении, например, такой задачи.

Задача: Организовать k8s-кластеры в ручном режиме с помощью kubeadm и kubectl на базе cri-o (1.28+) и использовать Calico как CNI-плагин.

Кластер доступен для взаимодействия через kubectl, команда возвращает корректную информацию о кластере. Есть возможность сделать ping 8.8.8.8 с образом busybox.

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

Если вы только начали изучать Kubernetes, читайте статью с подробным разбором этой ошибки → 

Теги:
+4
Комментарии1

Тайм-менеджмент — это не про управление временем, а про управление силами

Часто мы думаем, что эффективность зависит от грамотного распределения времени. Но даже при четком плане и полном календаре можно чувствовать усталость и неудовлетворенность. Все потому, что в основе продуктивности — не количество часов, а то, сколько сил мы можем вложить в задачи.

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

Планируйте по энергии, а не по времени. Спрашивайте: «Сколько сил потребует эта задача?», а не «Сколько времени она займет?».

Оставляйте паузы на восстановление. После эмоционально или интеллектуально тяжелых задач — делайте перерывы.

Попробуйте в течение двух недель вести простой дневник состояния. Записывайте туда:

  • что делали,

  • сколько времени ушло,

  • как чувствовали себя после — энергично, нейтрально или вымотано. Это поможет выявить личные ресурсоемкие зоны.

Пример задачи из дневника состояния
Пример задачи из дневника состояния

Закладывайте запас времени. Добавляйте 15–30 минут к каждой задаче. Особенно важно для новых или сложных задач.

Планируйте перерывы осознанно. Обед и отдых — полноценные пункты в расписании. При необходимости — дайте им «рабочие» названия.

Рефлексируйте ежедневно. Удалось — зафиксируйте. Не получилось — сделайте выводы и двигайтесь дальше.

Настоящая цель тайм-менеджмента — не запихнуть больше дел, а сберечь энергию, здоровье и место для жизни.

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

Теги:
+6
Комментарии0

Data-класс вашей ошибки: как относиться к ошибкам как программист

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

Чтобы убрать эмоции из анализа ошибки и подойти к ней с «трезвой» головой, можно разложить ее как код. Вот, например, какой data-класс можно выделить у ошибки:

class Error {
  // что нужно было сделать
  var task
  // что пошло не так
  var errorDetails
  //какие возможные последствия уже есть или последуют и кто может пострадать
  var effect
  //причины ошибки
  var reasons
  //плюшки от решения сложившейся ситуации
  var benefits
  //выводы
  var experience
 //список улучшений, которые можно сделать, чтобы минимизировать повторение ошибки
  var actionItems
 }

А теперь — реализация.

Пример: Вы неверно оценили сроки выполнения целого скоупа задач, входящих в MVP для приложения Сообщения — ошиблись на целых два релиза. Никто не пострадал, но ситуация по многим аспектам неприятная.

Как бы выглядела реализация интерфейса для данного случая:

class BadEstimationForMVPMessaging {
  
  var task = эстимация MVP для приложения Сообщения. Необходимо оценить все задачи, распределить по спринтам и релизам, учесть загрузку команды и выдать предполагаемую дату релиза
  
  var errorDetails = ошибка в эстимации на два релиза (два месяца разработки команды из трех человек)
  
  var  effects = listOf(
  - релиз переносился два раза
  - демотивация команды
  - вопросы с продуктовой стороны
  )
  
  var reasons = listOf(
  - часть задач были сильно недооценены
  - не учтены зависимости, которые, конечно, вылезли только в конце
  - не заложен запас по времени
  )
  
  var  benefits = listOf(
  - хороший пример, который можно разобрать
  - прокачан навык работы с ожиданиями
  - ощутили дух стартапа с командой, решая внезапные блокеры перед релизом, и радовались запуску приложения
  )

  var experience = listOf( 
  - детальнее искать зависимости на этапе подготовки к эстимации
  - закладывать запас по времени в 2-3 релиза
  - на задачи с неизвестными апишками и стеком увеличивать коэффициент Пи*
  )
  
  var actionItems = listOf(
  - составить чек-лист для подготовки к запуску новых приложений, на который можно ориентироваться всем командам
  - обсудить с командой процесс выявления зависимостей
  )
 
}

Смотреть на ошибки так гораздо эффективнее. Вы выносите из них уроки, а не просто посыпаете голову пеплом. Попробуйте!

А больше лайфхаков по построению здоровой культуры ошибок в жизни и на работе читайте в подробной статье от Марии Киселевой, тимлида команды разработки мобильных приложений для KvadraOS в YADRO  

Теги:
+3
Комментарии0

Как защитить данные без полных бэкапов: разбираем косвенную адресацию в СХД

Мгновенный снимок (снапшот) — это компактная с точки зрения дискового пространства копия данных, созданная в определенный момент времени. Снапшот способен моментально зафиксировать состояние тома, в отличие от резервной копии, создание которой при большом объеме данных может занять длительное время и требовать остановки записи для сохранения консистентности. Снапшот же не создает независимую копию данных, а лишь обеспечивает возможность обратиться к данным тома на момент создания снапшота.

В TATLIN.UNIFIED снапшоты создаются путем копирования карты блоков данных оригинального тома. Сами данные не копируются, поэтому снапшоты создаются очень быстро и не занимают дополнительного места в области данных.

Со временем в родительском томе заполняются новые блоки данных. Некоторые данные у родительского тома и снапшота начинают различаться, но данные, на которые уже ссылается снапшот, не перезаписываются и не освобождаются. Оригинальный физический блок данных считается занятым до тех пор, пока снапшот, который на него ссылается, не будет удален. После удаления снапшота блоки данных, которые он не разделял с другими ресурсами, освобождаются и могут быть использованы для последующих операций записи. Такой вариант реализации снапшотов называют Redirect-On-Write (RoW).

В своей статье Алексей Шушарин, главный эксперт по разработке ПО в департаменте СХД YADRO, подробно рассказал о снапшотах, клонах и всех процессах, связанных с косвенной адресацией. А также о том, как грамотно вписать эту функциональность в стек хранилища.

Теги:
0
Комментарии0

Три дня, чтобы начать поддерживать инфраструктуру для базовых станций GSM/LTE

Это baseband-модуль (BBU) базовой станции, которую разработала команда Телеком в YADRO, и мы ищем DevOps-инженеров, которые к ней присоединятся. Таким специалистам нужно будет поддерживать процессы разработки (на С/С++, Go, Node.JS), развивать CI/CD и улучшать качество внутренних сервисов.

Узнать, как стать DevOps-инженером в YADRO → 

DevOps-специалистов разного уровня — от junior до senior — мы ждем по двум направлениям.

Infrastructure

Задача DevOps-инженера здесь — поддерживать бесперебойную работу инфраструктуры для разработки в телекоме. А это более 600 виртуальных машин, 20 информационных систем и десятков внутренних сервисов. Эта работа не просто про администрирование серверов, но и про автоматизацию работы и масштабирование инфраструктуры.

CI/CD

Специалисты по этому направлению организуют разработку и выпуск программно-аппаратных решений в сфере телекоммуникаций — с использованием Gitlab CI. Ежедневно они востребованы у более тысячи разработчиков и тестировщиков телекома. Цель DevOps-команды — сделать удобным процесс доставки изменений от разработчиков до продукта, а также постоянно улучшать и оптимизировать существующие решения, внедрять Observability для текущих продуктов, создавать новые инструменты.

Условия быстрого оффера

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

Больше про спринт-оффер и описания требований к специалистам — по ссылке.

Теги:
+8
Комментарии0

Генерация последовательностей случайных чисел с помощью DRAM — возможно ли это? Проверим с помощью RISC-V

На основе DRAM мы создали модель одноканального источника шума, который возвращает один случайный бит за один условный такт. Память разбита на два региона, которые не пересекаются. Первый отвечает за инициализацию одноканального сигнатурного анализатора (ОСА), который инициализирует второй подобный анализатор. Затем мы сможем взять другой регион памяти и заново инициализировать первый ОСА, что абсолютно случайным образом изменит выход второго ОСА. Такая схема позволит не перезагружать память после каждой генерации числовой последовательности — ведь в реальных проектах это, как правило, невозможно. 

Далее мы направляем данные из DRAM PUF в два подмодуля — постобработки, а также тестирования, анализа и оценки качества данных. Первый частично запускается на «железе», второй — на собранных данных на машине хоста.

Для постобработки мы протестировали шесть комбинаций. Последняя нам кажется наиболее перспективной:

  • сырые данные,

  • чистый корректор фон Неймана,

  • одноканальный сигнатурный анализатор,

  • чистый корректор фон Неймана + одноканальный сигнатурный анализатор,

  • одноканальный сигнатурный анализатор + чистый корректор фон Неймана,

  • многоканальный сигнатурный анализатор (МСА).

Зимняя школа RISC-V дала начало множеству интересных проектов. В отдельной статье мы рассказали об одном из них, где команда из БГУИР проверила гипотезу о наличии PUF в динамической памяти и создала модель одноканального источника шума. А затем реализовала постобработку и тестирование, измерила производительность генератора и оптимизировала код.

Теги:
+4
Комментарии0

Isar и еще 8 систем сборки для создания дистрибутива на Linux

Isar — система сборки, представляющая собой набор скриптов для создания пакетов и дистрибутивов на базе Debian с возможностью настройки. Организация проекта Isar похожа на Yocto Project, для сборки используется Bitbake.

Перед сборкой можно настроить параметры файловой системы, ядра, модификации списка пакетов (добавление и удаление пакетов, в том числе и собственных, изменение существующих пакетов). Систему сборки разрабатывает компания ilbers GmbH.

Архитектура системы

Так как Isar основан на Bitbake, архитектура решения состоит лишь в нескольких слоях для Bitbake, реализующих сборку и установку пакетов в соответствии с конфигурацией сборки. В основе всех этих слоев и рецептов лежат утилиты Debian Build Toolchain, которые ответственны за непосредственную сборку пакетов, разрешение зависимостей и т.д.

Как проходит процесс сборки дистрибутива в Isar
Как проходит процесс сборки дистрибутива в Isar

Особенности решения

  • Аналогично Yocto требует усилий на начальных этапах для освоения инструмента.

  • Поддерживает загрузку готовых пакетов из репозиториев Debian.

  • Подходит для embedded-дистрибутивов, где необходимо сочетание Debian-экосистемы и глубокой конфигурации.

О других embedded- и desktop-решениях решениях рассказали студенты и преподаватели СПБГЭТУ «ЛЭТИ» в обзоре систем для создания Linux-дистрибутивов.  

Теги:
+1
Комментарии0

К чему готовиться на хакатоне по проектированию SoC и созданию процессоров?

Трек UVM-верификации — результат эволюции и переосмысления задач SoC Design Challenge предыдущих лет. В этом году участники работали с конфигурируемым AXI Stream маршрутизатором, который по заданным правилам распределяет транзакции с входных каналов на выходные, избегая коллизий. Для конфигурации блока предусмотрены регистры, доступные по шине APB.

Несмотря на упоминание UVM в названии трека, окружение было несколько упрощено относительно «честного» варианта методологии. Это позволило опытным участникам проявить себя, а начинающим инженерам познакомиться с основными аспектами UVM — объектно-ориентированным подходом в SystemVerilog, модульностью и абстрагированием через моделирование на уровне транзакций.

Задача хакатона охватила наиболее «творческие» этапы верификации, существующие в департаменте разработки SoC YADRO: подготовка плана верификации и разработка эталонной модели устройства. В сжатые сроки нужно было не просто усвоить спецификацию устройства, но и грамотно расставить приоритеты в разработке — чтобы успеть найти максимальное количество ошибок в дизайне.

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

Это описание лишь одного из четырех треков SoC Design Challenge — совместного хакатона YADRO и МИЭТ, который в этом году прошел в четвертый раз. Подробное описание остальных треков и знакомство с командами — в нашем репортаже.

Теги:
+2
Комментарии0

О, сколько нам открытий чудных... готовит школа по RISC-V

Сегодня устройства на базе «молодой» архитектуры RISC-V, представленной в 2010 году, имеют ограничения по документации. Каждая инструкция в процессоре обладает двумя характеристиками исполнения, латентностью и пропускной способностью, которые зависят от реализации процессорного ядра. Латентность определяет время выполнения одной инструкции, а пропускная способность — количество инструкций, выполняемых за определенное время. Эти данные помогают разработчикам оптимизировать код и повысить эффективность выполнения алгоритмов процессором. Обычно характеристики предоставляются производителями ядер, но в настоящее время для актуальных ядер их не найти. 

Существуют стандартные инструменты для измерения латентности и пропускной способности, например llvm-exegesis. Однако из-за быстрого развития архитектуры RISC-V не все инструкции включены в эти инструменты. В рамках образовательного проекта предлагалось изучить принципы создания микробенчмарков для таких задач и измерить новые реализации недавнего векторного расширения для RISC-V (RVV) на примере плат LicheePi 4A.

Изначально мы не знали, как вычислить латентность, но знали, что на современных архитектурах скалярное сложение должно выполняться за один такт. Поэтому решили найти такой метод, который на скалярном сложении покажет латентность в один такт.

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

Так начинается лишь один из 18 интересных проектов, которые подготовили студенты в рамках Зимней школы RISC-V. О том, что это за школа и что еще разработали ее участники, читайте в нашем блоге.

Теги:
+5
Комментарии0

Как начать практиковаться в тестировании без опыта

Если вы только что окончили курсы по тестированию, знаете теорию, но не имеете реальных кейсов — это нормально. Почти каждый начинающий QA-специалист сталкивается с вопросом: «Где набраться практики, если нет опыта?».

После тренировок в песочницах следующий шаг — попробовать себя в реальном проекте. Участие в open source — отличный способ получить настоящий опыт, поработать с командой и добавить первые кейсы в портфолио. Начать тестировать WordPress можно по простому и понятному алгоритму. Шаги для старта:

  1. Установите WordPress локально.
    Самый простой способ — приложение LocalWP. Также подойдут Docker или XAMPP.

  2. Разберитесь, как устроена работа.
    Загляните на make.wordpress.org — там есть разделы для разработчиков, дизайнеров, переводчиков и тестировщиков. Обратите внимание на Test Handbook — там подробно объясняется, как тестировать, искать баги и писать отчеты.

  3. Найдите первую задачу.
    В баг-трекере Trac ищите задачи с меткой good-first-bug — они идеально подходят для старта. Прочитайте описание, повторите шаги и проверьте, воспроизводится ли баг.

  4. Включайтесь в сообщество.
    Присоединяйтесь к чату #core-test в Slack (ссылка на подключение — в make.wordpress.org/test). Там обсуждают приоритетные задачи и проводят регулярные митинги. Новичкам всегда рады!

    Пример отчета в Make WordPress Core
    Пример отчета в Make WordPress Core

В статье, Юлия Ковшова, руководитель группы компонентного тестирования в YADRO, делится опытом, где найти первые реальные задачи без трудоустройства. Если вы только начинаете карьеру в тестировании и застряли на этапе теории, это руководство поможет сделать уверенный шаг к практике.

Теги:
+4
Комментарии0

Могучий русский язык и предиктивный ввод в умной клавиатуре

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

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

Мы увеличили размер словаря для русского языка до 40 тысяч слов и использовали модель Char CNN + RNN. Так удалось добиться прироста метрики KSS (количество сэкономленных нажатий) на 60%. 

Читайте в статье ИИ-инженера Вадима Воеводкина из YADRO, как его команда улучшила предиктивный ввод на планшетах KVADRA_T и с какими сложностями столкнулась. 

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Как тестируют функцию Circuit Switched Fallback, которая помогает общаться с родственниками

Представим, что вы звоните семье со смартфона в 4G-сети. В вашей сети нет (или временно недоступна) поддержка голосового звонка через сеть 4G. Не имеет значения, в какой сети находится второе устройство.

Что происходит в сети оператора при таком звонке:

  • Телефон отправляет на базовую станцию (eNB) вызов.

  • Базовая станция связывается с ядром сети (MME) и запрашивает процедуру CSFB для исходящего звонка, дожидается от ядра сети подтверждения о возможности такого перехода.

  • После этого отправляет телефону информацию о новом подключении к 2G-сети, которое он должен установить.

  • После этого базовая станция завершает обслуживание абонента в 4G-сети, обслуживание переходит к станции 2G.

  • Голосовой вызов осуществляется через 2G-сеть.

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

Симулятор позволяет автоматизировать этот этап тестирования и увеличить скорость тестов и повторяемость результатов. CSFB — это базовая функциональность, поэтому проверка проходит регулярно.

Для успешной проверки CSFB задачу декомпозируют, разделяют на уровни. О двух других ступенях «пирамиды» — тестировании в GSM-сети и системном тестировании — рассказала инженер YADRO Анастасия Беднова в своей статье.

Теги:
Всего голосов 4: ↑4 и ↓0+5
Комментарии0

Android-приложение «Контакты»: работает — не трогай

У многих полей контакта есть типы. Например, у номеров телефонов или адресов электронной почты по умолчанию есть типы «рабочий» и «домашний». Аналитики сказали, что нужно реализовать дополнительные типы и дать пользователю возможность создавать свои. Звучит легко, но на деле оказалось совсем непросто.

Чтобы заменить стандартные типы полей, нужно добавить новую базу данных с доступными типами полей, а также реализовать отображение и возможность выбора поля. Для этого пришлось во многом переписать код редактирования полей контакта, где и без этого логика была непростой. Теперь стало совсем сложно: при добавлении или обновлении поля в contentProvider нужно указывать тип поля, так что мы начали указывать «custom».

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

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

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

Пришлось опять добавлять костыль: в отдельной корутине ожидать инициализации БД и только потом начинать рисовать экран...

Дмитрий Бражник, старший инженер-программист в департаменте разработки мобильных приложений YADRO, рассказал в статье, как его команда пыталась допилить стандартное AOSP-приложение «Контакты» и к чему они в итоге пришли.

Теги:
Всего голосов 3: ↑2 и ↓1+2
Комментарии0

Собеседование инженера: взгляд со стороны нанимающих специалистов

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

Частая ситуация на собеседовании — недостаточно глубокое погружение в интерфейс, с которым у кандидата был опыт работы. Например, указан опыт работы с протоколом USB. На собеседовании после нескольких вопросов по архитектуре протокола оказывается, что кандидат просто вставлял готовый IP без понимания принципов его работы. Но в резюме это заявлено как полноценный опыт работы с протоколом.

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

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

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии0

Проверка знаний в эпоху LLM: опыт преподавателя из Политеха

Сегодня преподаватели сталкиваются с новой реальностью: даже уникальные задания и ежегодное обновление вариантов не гарантируют защиту от списывания. Студенты могут принести работающий код, созданный с помощью LLM-моделей, но совершенно не понимать, как он устроен. Устные собеседования могли бы помочь, но они требуют много времени и экспертности — до 15 минут на одного студента, что превращается в колоссальную нагрузку.

На курсах «Введение в язык программирования Go» и «Технологии параллельного программирования на C++» в Политехе лабораторные работы проверяются с использованием системы контроля версий GitLab. Это позволяет упорядочить процесс сдачи и проверки заданий.

Каждый студент работает в личном fork-репозитории, созданном на базе основного, предоставленного преподавателем. Решения оформляются строго по структуре: каждая задача и подзадача — в своей директории, обязательное наличие модуля go.mod, а точка входа программы размещается в cmd/. Сдача работы происходит через создание Merge Request в основной репозиторий, где автоматически запускаются все проверки.

Пример хронологии коммитов и Merge Request'ов, отправленных в основной репозиторий.
Пример хронологии коммитов и Merge Request'ов, отправленных в основной репозиторий.

Система GitLab CI/CD выполняет серию автоматических тестов, включая проверку структуры проекта, сборку и выполнение юнит-тестов. Если хотя бы один из этапов не пройден, работа не допускается к оценке. Это дисциплинирует студентов и делает процесс проверки прозрачным и объективным.

После успешного прохождения автоматических тестов работа передается на ручную проверку преподавателю. Он дает обратную связь и при необходимости запрашивает доработку через комментарии в Merge Request. Только после этого, если все в порядке, решение попадает в основной репозиторий и считается принятым. Такой подход делает процесс обучения максимально приближенным к реальной командной разработке в индустрии.

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

Теги:
Всего голосов 2: ↑2 и ↓0+5
Комментарии0

От картотеки Лумана к современным графам: учим языки программирования с методом Цеттелькастен

В середине XX века социолог Никлас Луман разработал метод организации информации Цеттелькастен (Zettelkasten). Он создавал множество заметок и, чтобы не терять знания, начал вести картотеку. Система нумерации и ссылок помогала ориентироваться в карточках. У каждой заметки был уникальный номер, отражающий тему и дополнения.

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

Все заметки Дмитрия в виде графа
Все заметки Дмитрия в виде графа

Веб-разработчик в YADRO Дмитрий сохраняет заметки в сервисе Obsidian. Дмитрий услышал о ПО от инженера и блогера Николая Тузова и понял, что система, похожая на картотеку, ему близка.

Программа оказалась понятной, легко адаптируемой под разные задачи. Когда Дмитрий перенес данные из Notion в Obsidian, образовалось несколько графов: по Go, хешированию и базам данных. В этой базе знаний все концепции в Go пересеклись в двух точках — интерфейсе и горутинах. Есть еще слайсы, но в основном все «лучи» сходятся именно в эти две точки. 

Как Дмитрию удалось упорядочить большие объемы знаний и кому он рекомендует Цеттелькастен, читайте в статье →

Теги:
Всего голосов 4: ↑3 и ↓1+3
Комментарии2

Работаем со свертками в 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 для работы с большими свертками? Как выбрать алгоритм, подходящий для обучения моделей? Узнаете из статьи →

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии0

На пределе железа: протестировали резервное копирование 32 виртуальных машин с дедупликацией «на лету»

Один из сценариев тестирования СХД TATLIN.BACKUP и СРК Кибер Бэкап, в котором резервное копирование производилось с inline-дедупликацией внутри каждой ВМ.

В каждую из 32 виртуальных машин установлены агенты Кибер Бэкапа, а также агенты Tboost, протокола дедупликации в TATLIN.BACKUP. Каждый агент сохраняет резервную копию в локальную папку, подключенную к целевому хранилищу через протокол T‑BOOST (точка монтирования /mnt/esxboost)​. В качестве хранилища резервных копий в Кибер Бэкапе указано 32 хранилища — по числу ВМ.

Чтение на источнике TATLIN.UNIFIED
Чтение на источнике TATLIN.UNIFIED

График показывает, что мы достигли ограничений оборудования: пропускной способности четырех портов Ethernet по 25 Гбит/с, через которые подключен диск TATLIN.UNIFIED к хостам виртуализации. 

Совокупный объем данных, переданных Кибер Бэкапом для полного резервного копирования всех ВМ, составил ~ 4 192 ГБ (32 × 131 ГБ). Параллельно выполнялись 32 операции резервного копирования. Время выполнения операций — от 8 до 11 минут.

Про совместное использование TATLIN.BACKUP и Кибер Бэкапа читайте в статье с результатами тестирования трех сценариев резервного копирования 32 виртуальных машин.

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии0

Проверяй, пока не поздно: функциональная верификация в жизненном цикле СнК

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

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

Время, необходимое для прохождения жизненного цикла СнК, зависит от команды и применяемых технологий. В индустрии считается, что эффективная работа означает выпуск нового тейп-аута (tape-out) раз в полгода. Это говорит о том, что процессы налажены и команда работает с высокой скоростью.

Жизненный цикл верификации в СнК
Жизненный цикл верификации в СнК

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

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

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии1

Верните мой 2007-й: превращаем старые фотки в снимки с зеркалок с помощью ИИ

Однажды группе ИИ-энтузиастов пришла идея: а что если обучить искусственный интеллект улучшать смартфонные снимки до профессиональных с помощью парных фотографий? Задумка понравилась. Для сбора датасета выбрали актуальные в то время Sony Xperia Z, iPhone 3GS, BlackBerry Passport и цифровую зеркалку Canon EOS 70D в качестве эталона. Модель обучили улучшать фотографии, сделанные на смартфонах, в соответствии с такими же изображениями, полученными с камеры. Проект реализовали, исходный код опубликовали на GitHub, а подробное описание — на arXiv.org. Но что же в нем интересного сейчас, почти десять лет спустя?

DPED не просто применяет косметические фильтры. Датасет способен значительно улучшать фотографии на уровне структуры изображения, детализации, динамического диапазона и цветопередачи, приближая результат именно к профессиональной зеркальной фотокамере, а не просто «улучшая» фото.

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

В своей статье команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ им. Р. Е. Алексеева запустила DPED на свежих версиях софта, преодолев все проблемы совместимости, и попробовала через него улучшить фото с современного планшета.

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии0

Информация

Сайт
yadro.com
Дата регистрации
Дата основания
Численность
5 001–10 000 человек
Местоположение
Россия
Представитель
Ульяна Соловьева