# L2 STAN(GUI для L2)

Нам в сентябре надо будет выкатить клиентскую утилиту для управления биржей. Я планировал использовать для этого QT/pyside. Но там не срослось. Используем альтернативный вариант - https://github.com/ocornut/imgui - она достаточно отлажена, и знакомые мне проекты на cpp ее довольно продуктивно используют как раз как дашборды для статистики и управления сервисами через API.

Тк опыта с IMGUI нет ни у тебя, ни у меня - тестим идею на дашборде к твоей предыдущей разработке. IMGUI - это фреймворк для построения UI для системных утилит на c++, отличается он от всего остальново тем что полностью работает через openGL. API к ней как раз за тобой, и это означает что в рамках проекта тестирования технологии никто тебя ограничивать не будет.
> Бонус-пак - если освоишь graphQL - это будет гораздо интересней, его кмк тут эффективней использовать по причине итеративного роста систем, и модификация или дополнение API в связи с этим - graphQL в этом плане позвляет сделать безшовную интеграцию бека с фронтом. Но это бонус-пак, те опциональное задание. Реши этот вопрос после испытаний IMGUI для python(cython).

Что нужно. по глобальному хоткею вызывается экран - достаточно чтоб оно работало в Win10. Пример как вызавыют такой экран на этой технологии: https://keminglabs.com/finda/

экран из двух частей - упрощенный аналог Apple Notes:

Одна часть - навигатор по объектам, вторая просмотр MD документов, в левой части все контролы по добавлению документов в обработку. Коректней всего сделать обновление на фронте согласно методологии off-line first, но опять-же тут решение за тобой - мне важно проверить технологию как можно скорей и начать пилить дашборд для биржи.

пример как оно у меня работает:

Могут возникнуть проблемы с рендером md - если его нет в стоке - глянь в гугл/гитхаб, я натыкался на md компонент для imgui. Также неплохо-бы было услышать от тебя оценку трудоемкости разработки кастомных коспонентов(например гистограмму или какой-либо нереализованный график/вероятно придется пару компонентов допилить для основной задачи/).

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

## Прочти после оценки, перед реализацией

Перед реализацией - небольшая вводная, чтоб избежать в дальнейшем повторной реализации приложеня. Главное задачи в данной разработке - познакомится и изучить принципы IMGUI и познакомить с ними нас - как она рисует так быстро? как нарисовать свой объект? как изменять его вид с помощью таблицы стилей? **весь процесс надо задокументировать в MD документ** :) вот отличный пример качестыенной документации: https://ru.bmstu.wiki/Apache_Ignite

Чтоб это не было rnd в вакуме приложение должно решать бизнес-задачу.

## Задачи приложения

1. запрашивать сервисы-парсеры выгрузить из сторонних ресурсов документы, те в свою очередь вместе с парсингом преобразуют эти документы в md документы - думаю у тебя на этом этапе возникнут мысли об рефакторинге тех сервисов:)

2. Подписыватся на обновление репозитория в котором сохраняются выгруженные документы.

3. Отображать выгруженные документы в приложении.

Для упращения разработки управоение репозиторием(pijul push/pull) можно не встраивать в программу на прямую, а вызывать через rpc стороннего приложения(в фоновом процессе). Интерфейс к внешним сервисам также удобней всего реализовать через JSON RPC.

## Возможные трудности

1. Вероятно в библиотеке IMGUI которая реализует рендеринг MD документов не хватает примитивов для обработки всех тегов, используемых тобой при трансформации документов, реализуй пару таких примитивов своими силами, оцени сложность такой реализации; **задокументируй процесс их реализации**.

## UI

Референс подобного приложения - apple notes - если нужно заскринить его работу в спецефических режимах - дай знать.

В одном репозитарии может быть несколько документов(в продакшене будет монорепозиторий), для построения списка или дерева документов помечаем патчи pijul, содержащие отдельные документы или их изменения KV тегами, например так:

>`project:medium; folder:{short_article_description}; parent:{parent_folder_name}; `

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

## при чем тут pijul?

Pijul является **распределенной** системой контроля версий и несет в себе реализацию 2-х базовых алгоритмов - синхронизация мастер-мастер, основанная на lock-free структуре индекса(уникальных id патчей) и реализацию модульной схемы подключения детерменированных алгоритмов выявления модификаций в документах, в основном основанных на теории патчей: одни оптимальны для выявления изменений в крупных бинарях, другие для исходного кода, третьи для текстовых документов - короче говоря там свои заморочки, отвлекатся на которые в рамках этой разработки не особо интересно, просто вместе они дают возможность относительно компактно хранить документы и историю их изменений и выбирать оптимальный алгоритм для работы с разными типами документов, синхранизируя их на нескольких независимых инстанциях.

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

## cpp vs python
Идеально использовать cpp, тк мы хотим получить приложение, способное работать в разрешении как в обычном 1920x1080^60hz так и на последних версиях самых навороченных систем: 5120x1440^240hz, при этом не напрягая пользователя требованиями к железу, и как бонус приятно иметь приложение, занимающее на диске несколько сотен кб а не несколько гб.

Но я понимаю что твой основной стек это **py**, реализуя задачу на на нем, имей ввиду - что либо ты в будущем, либо другоц разработчик перепишет все на компилируемый язык(почти наверняка cpp). Но это не обязательно будет до релиза. Так что не говнокодь:)

**PS** я тут вспомнил что на питоне куча стафа написанно для визуализаций различных графиков, я чекнул - [часть из этого стафа использует openGL](https://pyviz.org/scivis/index.html), подумай над путями интеграции в прилу виджетов различных графиков и диаграм - вероятно это понадобится в буду.

## Ссылки
1. **Pijul 0.12** https://pijul.org/downloads/
2. **IMGUI** https://github.com/ocornut/imgui
3. **IMGUI с исзмененными стилями от Adobe** https://github.com/adobe/imgui
4. **IMGUI + markdown** https://github.com/juliettef/imgui_markdown
5. **Обзор библиотек Py** https://www.anaconda.com/python-data-visualization-2018-why-so-many-libraries/