Инкрементальная валидация биомаркеров — различия между версиями

Материал из Wiki - Факультет компьютерных наук
Перейти к: навигация, поиск
 
Строка 8: Строка 8:
 
|categorize=yes
 
|categorize=yes
 
}}
 
}}
 +
 +
===Что это за проект?===
 +
tldr; необходимо в утилиту, которая сканирует директорию и валидирует находящиеся в ней файлы, добавить возможность игнорировать те из них, которые не изменялись с последней успешной валидации.
 +
 +
Есть некоторая программа, работа которой зависит от биомаркеров - строгих описаний состояния, в котором находится пациент. При этом биомаркеров много (и их число постоянно расширяется), они имеют сложный предметный смысл и синтаксис, и пишут их не обычные разработчики, а предметные эксперты (разработчиками не являющиеся). Для проверки корректности написанных биомаркеров эксперты используют специальную консольную утилиту, которая сканирует заданную директорию с биомаркерами и выводит список ошибок с указанием мест в файлах, где они произошли.
 +
 +
Проблема заключается в том, что валидация одного файла происходит довольно долго (порядок сотен миллисекунд), файлов довольно много(несколько тысяч), и утилита всегда валидирует все файлы. Таким образом, эксперту приходится ждать несколько минут проверки одного-единственного измененного файла. В рамках проекта предлагается решить эту проблему, реализовав валидацию только тех файлов, которые действительно нужно повторно валидировать после предыдущей валидации.
 +
 +
Отдельно также стоит учесть, что валидатор со временем разрабатывается, поэтому может так случиться, что предыдущая валидация была выполнена более старой версией валидатора(в которой, например, могли быть ошибки, повлиявшие на валидацию). В таких случаях необходимо игнорировать прошлые результаты валидации и повторно валидировать все файлы заново.
 +
===Начальные требования===
 +
* Понимание принципов ООП
 +
* Владение Java, C#, C++ или Python
 +
* Желание научиться писать на Java
 +
===Чему вы научитесь===
 +
* Писать на Java код, который могут прочитать другие люди
 +
* Писать на Groovy тесты, которые не падают и которые могут прочитать другие люди
 +
* Настраивать сборку проекта с помощью Gradle
 +
* Чуть-чуть писать на Groovy
 +
===Какие будут использоваться технологии===
 +
* Java 8, Groovy, Spock framework, Gradle
 +
===Критерии оценивания===
 +
* 4 --- реализована инкрементальная валидация измененных файлов
 +
* +2 балла --- проделанная работа покрыта тестами
 +
* +2 балла --- реализована проверка на то, что после последней валидации не изменялся код валидатора
 +
* 10 --- проделанная работа в виде PR принята в основной code base
 +
 +
===Контакты===
 +
Лев Хотов lev.khotov@bostongene.com

Текущая версия на 13:11, 16 октября 2018

Ментор Лев Хотов
Учебный семестр Осень 2018
Учебный курс 3-4-й курс
Максимальное количество студентов, выбравших проект: 1



Что это за проект?

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

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

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

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

Начальные требования

  • Понимание принципов ООП
  • Владение Java, C#, C++ или Python
  • Желание научиться писать на Java

Чему вы научитесь

  • Писать на Java код, который могут прочитать другие люди
  • Писать на Groovy тесты, которые не падают и которые могут прочитать другие люди
  • Настраивать сборку проекта с помощью Gradle
  • Чуть-чуть писать на Groovy

Какие будут использоваться технологии

  • Java 8, Groovy, Spock framework, Gradle

Критерии оценивания

  • 4 --- реализована инкрементальная валидация измененных файлов
  • +2 балла --- проделанная работа покрыта тестами
  • +2 балла --- реализована проверка на то, что после последней валидации не изменялся код валидатора
  • 10 --- проделанная работа в виде PR принята в основной code base

Контакты

Лев Хотов lev.khotov@bostongene.com