Ещё одна тестирующая система (Виктор Яковлев, OSEDUCONF-2022) — различия между версиями

;{{SpeakerInfo}}: {{Speaker|Виктор Яковлев}}
<blockquote>
Тестирующая система ejudge, разработанная около 20 лет назад  —  стандарт для автоматизации проверки задач по
программированию как при проведении олимпиад, так и в учебном процессе. За годы эксплуатации системы ejudge в учебном
процессе на курсах, связанных с операционных системами, был накоплен опыт использования, который привёл к созданию
новой тестирующей системы. 

Новая система решает такие проблемы ejudge, как сложность администрирования и поддержки
системы; отсутствие интерфейса преподавателя для мобильный устройств. Кроме того, улучшена изоляция тестирования с
использованием Linux namespaces и cgroup, что позволяет выполнять тестирование задач на реализацию сетевых сервисов и
межпроцессного взаимодействия. В настоящее время система успешно проходит апробацию на курсе по операционным системам в
магистратуре МФТИ.
Екатерина Лапшина}}
<blockquote>
Рассмотрены варианты разработки программного кода с использованием свободного программного обеспечения, которое позволяет создать программный продукт с минимальным набором навыков через визуальные интерфейсы и конструкторы с помощью Low-code платформы.
</blockquote>

{{VideoSection}}

{{vimeoembed|917660048|800|450}}
{{youtubelink|}}

{{SlidesSection}}
[[File:Ещё одна тестирующая системаТенденции разработки программного обеспечения с использованием Low-code платформ (Виктор ЯковлевЕкатерина Лапшина, OSEDUCONF-2022).pdf|left|page=-|300px]]

{{----}}

== Thesis ==

=== Предпосылки разработки ===
Для организации приёма заданий на курсе «[https://github.com/victor-yacovlev/mipt-diht-caos Архитектура компьютеров и операционные системы]» (АКОС) ФПМИ МФТИ четвёртый год подряд используется тестирующая система [https://ejudge.ru Ejudge]. 

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

Студентам каждую неделю открываются от 2 до 4 задач по самым разным темам начиная с основ низкоуровневого
программирования, в том числе с использованием ассемблеров AArch64 и x86-64, до сетевого взаимодействия и использования
сторонних библиотек. Для каждой учебной группы создаётся отдельный контест, в который регистрируются студенты,
семинарист и учебный ассистент группы. Каждый контест имеет свои настройки дедлайнов, которые зависят от дня недели, в
который проводятся занятия определённой группы. Настройки задач и тесты  —  общие, это организовано через механизм
символических ссылок.

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

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

Для постепенной замены ejudge разрабатывается новая тестирующая система [https://github.com/victor-yacovlev/yajudge yajudge] (Yet Another Judge), которая
предназначена для использования в первую очередь именно в учебном процессе, и должна иметь следующие преимущества по
сравнению с ejudge:

* Упрощённое конфигурирование задач. Сейчас в ejudge используются конфигурации из файлов INI-формата, тексты заданий в формате XML, а если необходимо нестандартное тестирование или взаимодействие, то нужно писать вспомогательные программы на языке Си. При этом ошибки, например, в XML-структуре файлов условий, приводят к их неработоспособности с отсутствием подробной диагностики ошибки, а отлаживать нестандартное тестирование или взаимодействие достаточно трудоёмко.
* Упрощённое конфигурирование курсов. В ejudge встретились в конфигурационном файле.
* Возможность аналитики отправленных решений, наиболее важная практическая задача в этом  —  анализ решений на плагиат. В системе ejudge отправленные решения хранятся в виде файлов, пути к которым выясняются из БД, что усложняет реализацию антиплагиата.
* Большая степень изоляции, по сравнению с ejudge, при тестировании решений задач. Ввиду специфики изучаемого в курсе предмета, студенты могут использовать механизмы межпроцессного взаимодействия и взаимодействовать с сетевыми интерфейсами. Изоляция только на уровне отдельного пользователя и установка ресурсных лимитов не достаточны для безопасного выполнения программ, поскольку это не спасает, например, от посылки сигнала процессу с PID=-1, или открытию большого количества сетевых портов, которые затем не закрываются.
* Возможность тестирования задач наLow-code платформы разработки — это приложение, которое предоставляет графическийсистемах, поскольку в курсе, помимо архитектуры x86, рассматривается архитектура ARM (AArch64 в последней итерации). Хотя тестирование с использованием эмулятора qemu и кросс-компилятора позволяет решать эту задачу, этот подход нельзя назвать идеальным.
* Более современный пользовательский интерфейс. В частности, некоторые виды взаимодействий с системой (просмотр посылок, ревью кода) не требуют использования компьютера и могут выполнятся с устройств (планшеты и смартфоны), но интерфейс ejudge для этого не приспособлен.

=== Система yajudge ===
Система [https://github.com/victor-yacovlev/yajudge yajudge] состоит из центрального <i>мастер</i>-сервера, который должен быть установлен на машине с
выделенным IP-адресом. Этот сервер предназначен для взаимодействия с <i>клиентами</i> посредством веб-интерфейса
(также возможно применение «толстого» клиента), хранит сведенияпользователях, курсах и посылках в базе данных
PostgreSQL, и раздаёт задания <i>грейдерам</i>,  —  отдельным сервисам, которые выполняют тестирование посылок
задач.

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

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

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

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

Подобные платформы реализованы в том числе, как свободное программное обеспечение (СПО)<ref name="d1">[https://www.hmong.press/wiki/Low-code_development_platform Платформа разработки low-code — определение]</ref>.

Такие среды разработки применяются для создания прикладного программного обеспечения через графический интерфейс
пользователя вместо стандартного программирования вручную. С помощью платформ Low-code возможно создание используется формат YAML,
который является более компактным чем XML или JSON. Формат отдельных тестов для задач полностью позаимствован у системы
ejudge
рабочего приложения, а для не стандартных тестирующих программы и генераторов тестов используется язык Python. Более подробное
описание интерфейса приведено в [https://demo.yajudge.ru/ демо-курсе].

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

=== Тестирование решений ===
Тестирование решений реализуется отдельным сервисом, который выполняет стадии проверки стиля кода, компиляции, запуска
решений и сравнения с эталоном либов редких случаях  —  с использованием нестандартного проверяющего скрипта. Поддерживается тестирование
программ на языках программирования Си/++, языке ассемблера и скриптовых языков, например, Bash или Python. 

Перед началом тестирования создаётся изолированная файловая система с использованием [https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html OverlayFS]. Нижние слои этой файловой системы состоят из:
* Корневой файловой системы Linux-дистрибутива, который заранее подготовлен администратором. Это может быть, в простейшем случае, либо [https://alpinelinux.org Alpine Linux], либо система, установленная в отдельный каталог с помощью <tt>debootstrap</tt> илиинструментов.
* Каталога задачи, содержащего тесты дополнительные файлы. Если используется генерация тестов, то она проводится на предварительном этапе, до начала тестирования. Генерация тестов полезна, например, для генерации случайных данных, либо для создания больших файлов.

Верхний слой файловой системы предназначен для создания исполняемого файла из исходного решения и сохранения результатов
работы программы. 

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

Помимо изменения корня файловой системы, с помощью механизма [https://man7.org/linux/man-pages/man7/namespaces.7.html Linux Namespaces] производится изоляция процесса. 

Наиболее значимые подсистемы, которые изолируются:
* Точки монтирования файловых систем. Это, во-первых, необходимо для изменения корневой файловой системы без прав администратора, а во-вторых, делает безопасным тестирование решения задач на реализацию файловых систем с помощью FUSE.
* Сетевыедополнительного кодирования. Данные среды разработки
также помогают сократить объём программирования, что позволяет ускорить создание приложений. Большим преимуществом
является то, что расширяется круг людей, которые могут внести свой вклад в разработку приложения. Low-code платформы
также могут снизить первоначальные затраты на настройку, обучение и обслуживание. 

Недавнее исследование бостонской компании Mendix показало, что спрос на разработчиков среди ИТ-специалистов достиг
апогея. Почти шесть из десяти (57%) говорят, что. Необходимо для задач на сетевое взаимодействие, которое становится возможным только с той вспомогательной программой, которая входит в поставку задачи.
* Пространство процессов (PID). Это исключает возможность взаимодействия с процессами, не относящимися к задаче, используя механизм сигналов.

В качестве дополнительной меры безопасности можно запретить использование определённых функций стандартной библиотеки
языка Си. Это реализуется на стадии компиляции решения использованием механизма подмены функций (опция
<tt>wrap</tt> линковщика). Такое решение не является идеальным, и, возможно, будет заменено на использование
механизма [https://ebpf.io eBPF].

Для контроля лимитов запускаемого процесса используются два механизма, дополняющих возможности друг друга: ulimit, и
механизм [https://www.kernel.org/doc/Documentation/cgroup-v2.txt Cgroup v2], который реализован в современных ядрах Linux.

Механизм Cgroup v2 позволяет более точно контролировать некоторые ограничения выполнения, чем классический механизм
лимитов в UNIX. В частности, он даёт гарантии на количество одновременно запущенных процессов в рамках одного
контейнера, что является важным для курса по операционным системам.

=== Пользовательский интерфейс системы ===
Пользовательский интерфейс системы реализован с помощью кросс-платформенного фреймворка [https://flutter.dev Flutter], который
предназначен для мобильной разработки, но также позволяет собирать программы под основные десктопные операционные
системы (Linux, Windows, macOS), и в одностраничные Web-приложения.

Взаимодействие пользовательского интерфейса с мастер-сервером осуществляется, как и все межсервисные взаимодействия в
yajudge, через протокол [https://grpc.io gRPC], который является более производительным, чем взаимодействие через REST+JSON. Для
Web-версии клиентского приложения используется протокол gRPC-Web,  —  специальный персонала, необходимого для разработки программного
обеспечения, увеличивается, а [https://www.reworked.co/information-management/whats-behind-the-explosion-of-low-code-and-no-code-applications/ стоимость разработки программного обеспечения растёт (61%)]. 

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

Рассмотрим варианты Low-code платформ для различных целей.

* [https://nl-a.ru/nla-framework NL!A framework] — российский бесплатный low-code framework, позволяющий создавать полноценные бизнес-приложения. Модели, заложенные в кодогенератор NL!A framework, позволяют за считаные секунды создать полноценное рабочее бизнес-приложение;
* [https://www.outsystems.com/ OutSystem] — это надёжная и гибкая low-code платформа для разработки корпоративных мобильных и веб-приложений, которые разворачиваются в локальной или в гибридных средах;
* [https://soware.ru/products/mendix Mendix] — это бескодовая (no-code) программная платформа, предоставляющая инструменты для создания, тестирования,развёртывания и проверки программных приложений.


Помимо бесплатных версий популярных платформ, также существуют различные варианты Low-code СПО с открытым исходным
кодом, таких как Appsemble, Skyve, Baserow и другие. Наличие таких разнообразных платформ говорит о популярности данных
решений и их развитии.

Есть ряд других причин, по которым предприятиям следует рассматривать Low-code платформы:
#  Более быстрый выход на рынок;
#  Повышение удовлетворённости клиентов;
#  Снижение затрат на ИТ-инфраструктуру;
#  Более эффективное управление приложениями;
#  Лучшее управление ИТ;


Безусловно, подобные среды разработки — это не панацея, а лишь вариант протокола gRPC для работы в
условиях ограничений браузеров, и на стороне сервера необходим специальный прокси-сервер: либо [https://www.envoyproxy.io Envoy], либо
[https://github.com/improbable-eng/grpc-web grpcwebproxy], входящий в поставку yajudge.

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

Пока ещё не реализована функциональность для проведения Code Review, которая необходима для использования системы в
бакалавриате. Предполагается реализовать её к началу осеннего семестра 2022решения для создания нового контеста приходится избыточно дублировать одни и те же настройки, например, добавление нового преподавателя подразумевает не только добавление пользователя в таблице БД, но и правку конфигурационного XML-файла. Добавление же новой задачи в контест, может приводить к страшным последствиям, если задача добавляется не самой последней, поскольку ejudge автоматически сопоставляет ID задач с тем, в каком порядкепрограммного продукта, поэтому
Low-code платформы имеют ряд минусов:
#  Сложность в выборе подходящего ресурса;
#  Ограничения в функционале;
#  Зависимость от платформы;


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

См  также: Лапшина Е.А., Симонов В.Л. Преимущества информационных систем с веб-интерфейсом // XIX Международная конференция
«Современные информационные технологии в образовании, науке и промышленности» 29—30 апреля 2021 года, г. Москвачего провести очередную
итерацию практического тестирования.

{{----}}
[[File:{{#setmainimage:Ещё одна тестирующая системаТенденции разработки программного обеспечения с использованием Low-code платформ (Виктор ЯковлевЕкатерина Лапшина, OSEDUCONF-2022)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->

<references/>

[[Категория:OSEDUCONF-2022]]
[[Категория:Draft]]