Sprint #4 review
Закончился четвёртый спринт нашей работы над нотной программой. Честно говоря, сегодня мы не покажем вам ничего нового. В обычной практике скрама это называется «Today we cancel the demo». Но это порочная практика, когда спринт-ревью сводится к демонстрации, и если показывать нечего, то отменяется. Мы решили так не поступать, и просто расскажем вам, чем были заняты в течение этого спринта.
Мы запустили bug tracking system, которая сразу стала пополняться записями об имеющихся неполадках. Всё, что нам не нравится в нашей программе, мы сразу записываем туда - чтобы не забыть:
Из картинки это не очевидно, но мы используем Мантис не только для ведения багов, но и для планирования новых функций. (К таковым относятся, например, special verticals, введение которых запланировано на следующий спринт.)
В какой-то момент мы дадим ссылку на наш Мантис, и любой желающий сможет открыть его и посмотреть, какие баги сейчас фиксятся, какие фичи девелопятся, и на чём сейчас происходит затык. Ну а пока мы ссылку не даём, и про затык вам расскажем сами.
Сейчас мы работаем над одной из ключевых функций программы: функцией пересчёта макета. На картинке эта задача скрывается под номером 5 - «Reduce amount of recalculations». Изначально задача состояла в том, чтобы оптимизировать вычисления, ограничив их рамки только тем материалом, который необходим. Например, если мы добавили ноту на пятой странице партитуры, то ясно, что первые четыре страницы можно не пересчитывать - там ничего не изменится, и это понятно даже для авторов известной программы на букву Ф.
Самое интересное, конечно, касается последующих страниц. Если добавленная нота сделала запись слишком тесной, и один такт вылетел на следующую строчку, то мы должны пересчитать следующую строчку. И если по цепной реакции с каждой строчки по одному такту перелетело на следующую, то мы, разумеется, должны пересчитать каждую следующую. Но цепная реакция в какой-то момент остановится, поскольку в какой-то строчке окажется достаточно места для того, чтобы вместить лишний такт. Тогда и расчёты на этой строчке должны остановиться.
Кому-то покажется такой процесс излишним наворотом, однако есть такое понятие, как scalability, которое означает, что программа должна так же хорошо работать с партитурой в четыреста страниц, как и с одной страницей. И это значит, что никакие лишние расчёты недопустимы. Только необходимые.
Второй важный момент заключается в том, что прорисовка нотного текста на экране тоже требует времени, и чем больше нот помещается на экран, тем дольше она происходит. И задержка сегодня состоит совсем не в том же, в чём она состояла тридцать лет назад, когда нотные знаки рисовали на экране штриховкой или контуром, поскольку самой дорогой операцией была заливка этих контуров:
Сегодня заливка ничего не стоит, поскольку выполняется мощными видеокартами и отдельными графическими драйверами. Поэтому задача сводится к тому, чтобы быстро подать драйверу материал для прорисовки. Это значит, что максимум того, что может быть просчитано заранее, до прорисовки - должно быть уже рассчитано.
Вернёмся к нашей задаче. Одной из её подзадач является осуществление того, что по-английски называется vertical spacing. К сожалению, это нельзя перевести на русский, как вертикальный ранжир, поскольку этим термином у нас принято называть совсем другое. Назовём это вертикальным форматированием. В идеале нотные станы в одной партитурной системе должны находиться на одинаковом расстоянии друг от друга. Плюс добавочное расстояние между оркестровыми группами. Плюс дополнительное расстояние над струнными, если там требуется повторять темповые обозначения.
Однако идеальные нотные системы встречаются в жизни довольно редко. Чаще получается так, что в какой-то партии выписаны ноты в высокой тесситуре со множеством добавочных линеек. В другой - множество штрихов над станом. Или щедрым жестом нарисована лига. Или динамика под станом. Или всё сразу. Во всех этих случаях между станами требуется дополнительное расстояние. Получится, что во всей системе промежутки между станами меньше, а в этом месте - больше.
Хорошо. Но вот, допустим, наша нотная система получила больше места на странице. Как - не существенно. Например, мы перенесли ещё одну систему на другую страницу, и наша система осталась одна. Или сняли паузирующие нотоносцы, и остались только те, где есть ноты. Важно, что нашей системе говорят: у тебя теперь есть на 130% больше места, чем было, и теперь нужно систему растянуть. И вот тут начинается хитрость. Если мы возьмём и равномерно увеличим все промежутки между станами до 130%, то получится неправильно:
Потому что если в исходном варианте большее расстояние между первым и вторым станами было оправдано, то во втором варианте - нет. Значит, не стоило увеличивать все промежутки одинаково, а следовало увеличить меньшие, приблизив их величину к большему:
И только после того, как промежутки сравняются, при необходимости ещё растянуть систему, можно будет растягивать её равномерно:
Всё вышеописанное в обычных нотных программах добросовестными нотографиками делается вручную, на глаз. Очень добросовестными - при помощи расчётов на бумажке (если программа позволяет вводить цифры).
Наша программа должна осуществлять эти расчёты сама, оставив человеку лишь визуальный контроль и эстетическую правку. Алгоритм расчётов требует тщательной проработки и тестирования на большом количестве вариантов. Поэтому мы не стали завершать его в текущем спринте и продолжаем работу над ним в следующем.
Следующее спринт-ревью состоится в этом ЖЖ ровно через две недели, 6 июня, в 9:00 по московскому времени.
Мы запустили bug tracking system, которая сразу стала пополняться записями об имеющихся неполадках. Всё, что нам не нравится в нашей программе, мы сразу записываем туда - чтобы не забыть:
Из картинки это не очевидно, но мы используем Мантис не только для ведения багов, но и для планирования новых функций. (К таковым относятся, например, special verticals, введение которых запланировано на следующий спринт.)
В какой-то момент мы дадим ссылку на наш Мантис, и любой желающий сможет открыть его и посмотреть, какие баги сейчас фиксятся, какие фичи девелопятся, и на чём сейчас происходит затык. Ну а пока мы ссылку не даём, и про затык вам расскажем сами.
Сейчас мы работаем над одной из ключевых функций программы: функцией пересчёта макета. На картинке эта задача скрывается под номером 5 - «Reduce amount of recalculations». Изначально задача состояла в том, чтобы оптимизировать вычисления, ограничив их рамки только тем материалом, который необходим. Например, если мы добавили ноту на пятой странице партитуры, то ясно, что первые четыре страницы можно не пересчитывать - там ничего не изменится, и это понятно даже для авторов известной программы на букву Ф.
Самое интересное, конечно, касается последующих страниц. Если добавленная нота сделала запись слишком тесной, и один такт вылетел на следующую строчку, то мы должны пересчитать следующую строчку. И если по цепной реакции с каждой строчки по одному такту перелетело на следующую, то мы, разумеется, должны пересчитать каждую следующую. Но цепная реакция в какой-то момент остановится, поскольку в какой-то строчке окажется достаточно места для того, чтобы вместить лишний такт. Тогда и расчёты на этой строчке должны остановиться.
Кому-то покажется такой процесс излишним наворотом, однако есть такое понятие, как scalability, которое означает, что программа должна так же хорошо работать с партитурой в четыреста страниц, как и с одной страницей. И это значит, что никакие лишние расчёты недопустимы. Только необходимые.
Второй важный момент заключается в том, что прорисовка нотного текста на экране тоже требует времени, и чем больше нот помещается на экран, тем дольше она происходит. И задержка сегодня состоит совсем не в том же, в чём она состояла тридцать лет назад, когда нотные знаки рисовали на экране штриховкой или контуром, поскольку самой дорогой операцией была заливка этих контуров:
Сегодня заливка ничего не стоит, поскольку выполняется мощными видеокартами и отдельными графическими драйверами. Поэтому задача сводится к тому, чтобы быстро подать драйверу материал для прорисовки. Это значит, что максимум того, что может быть просчитано заранее, до прорисовки - должно быть уже рассчитано.
Вернёмся к нашей задаче. Одной из её подзадач является осуществление того, что по-английски называется vertical spacing. К сожалению, это нельзя перевести на русский, как вертикальный ранжир, поскольку этим термином у нас принято называть совсем другое. Назовём это вертикальным форматированием. В идеале нотные станы в одной партитурной системе должны находиться на одинаковом расстоянии друг от друга. Плюс добавочное расстояние между оркестровыми группами. Плюс дополнительное расстояние над струнными, если там требуется повторять темповые обозначения.
Однако идеальные нотные системы встречаются в жизни довольно редко. Чаще получается так, что в какой-то партии выписаны ноты в высокой тесситуре со множеством добавочных линеек. В другой - множество штрихов над станом. Или щедрым жестом нарисована лига. Или динамика под станом. Или всё сразу. Во всех этих случаях между станами требуется дополнительное расстояние. Получится, что во всей системе промежутки между станами меньше, а в этом месте - больше.
Хорошо. Но вот, допустим, наша нотная система получила больше места на странице. Как - не существенно. Например, мы перенесли ещё одну систему на другую страницу, и наша система осталась одна. Или сняли паузирующие нотоносцы, и остались только те, где есть ноты. Важно, что нашей системе говорят: у тебя теперь есть на 130% больше места, чем было, и теперь нужно систему растянуть. И вот тут начинается хитрость. Если мы возьмём и равномерно увеличим все промежутки между станами до 130%, то получится неправильно:
Потому что если в исходном варианте большее расстояние между первым и вторым станами было оправдано, то во втором варианте - нет. Значит, не стоило увеличивать все промежутки одинаково, а следовало увеличить меньшие, приблизив их величину к большему:
И только после того, как промежутки сравняются, при необходимости ещё растянуть систему, можно будет растягивать её равномерно:
Всё вышеописанное в обычных нотных программах добросовестными нотографиками делается вручную, на глаз. Очень добросовестными - при помощи расчётов на бумажке (если программа позволяет вводить цифры).
Наша программа должна осуществлять эти расчёты сама, оставив человеку лишь визуальный контроль и эстетическую правку. Алгоритм расчётов требует тщательной проработки и тестирования на большом количестве вариантов. Поэтому мы не стали завершать его в текущем спринте и продолжаем работу над ним в следующем.
Следующее спринт-ревью состоится в этом ЖЖ ровно через две недели, 6 июня, в 9:00 по московскому времени.