Что такое ОСень? Или как лучшие практики из мира Java прижились в экосистеме OneScript

Меня зовут Никита Иванченко, и я хочу рассказать, как интересные практики из других Enterprise-стеков, таких, как Java, потихоньку перетекают в OneScript и могут упрощать нам жизнь.

Что такое ОСень? Какие у вас ассоциации с этим прекрасным временем года?

Я расскажу про библиотеку для OneScript, которая называется ОСень. Она так называется, потому что мы ее слизали со Spring Framework из мира Java. Spring – это весна, а ОСень – это то, что у нас получилось на OneScript.

Цель библиотеки – помочь разработчикам создавать на OneScript большие сложные приложения, которые при этом будет легко поддерживать, расширять, тестировать, дорабатывать.

На OneScript уже сейчас существует много сложных приложений – таких, как gitsync, vanessa-runner, precommit, irac, yard и другие. Многие из них у вас уже используются, и это стало частью вашей жизни. Но если посмотреть, что там внутри, возникает недоумение. Например, когда я начал знакомиться с OneScript, у меня было такое же лицо, как в меме на слайде.

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

Согласно описанию на GitHub, ОСень – это dependency injection framework для OneScript, реализующий паттерн inversion of control. Очень много непонятных страшных слов.

Ниже на слайде определение от самого автора документации – здесь прям нотка безумия.

Эти определения выглядят страшно, но на деле их пугаться не надо – через полчаса у вас вопросов вообще не останется. Если останутся, подойдете, будете задавать.

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

Прежде чем погрузиться в веселую терминологию осеннего безумия, давайте обозначим, зачем нам все это – зачем нам в OneScript писать приложения в парадигме Java?

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

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

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

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

Я умышленно сократил текст этого скрипта, чтобы он влез на слайд. Давайте на него посмотрим и подумаем, что в нем не так:

• Здесь есть хардкод настроек.

• В одном большом файле вся ответственность,

• Этот код невозможно протестировать в принципе,

• И как-то переиспользовать этот скрипт невозможно – его можно только переписать.

Тем не менее он простой как палка, линейный и, самое главное, работает.

Прежде чем перейти дальше, я напомню, что у OneScript есть ряд особенностей, которые отличают его от 1С.

Первая особенность заключается в том, что в OneScript можно создавать свои классы. Потом на их основе через «Новый» можно создавать некоторые объекты. У классов могут быть поля (реквизиты) и методы – скрытые и экспортные.

Попробуем применить эту особенность.

На слайде показано, как будет выглядеть наше первое перевоплощение – здесь сделана попытка решить те проблемы, которые мы сами себе создали в первой версии.

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

Конкретно в этом примере мы разнесли функциональность получения данных и парсинга. Я поленился дальше описывать отправку в базу данных – там будет все то же самое.

Посмотрим, что у нас осталось:

• Main.os – корневая точка входа.

• ЧитательТекстовогоФайла.os – отдельный почти независимый класс, цель которого – получать данные из текстового файла.

• ПарсерЧудногоФормата.os – совсем независимый класс, который умеет парсить из нашего чудного формата (скобочки, закорючки и все остальное).

Стало уже намного лучше, но еще не идеально, потому что наш класс ЧитательТекстовогоФайла очень зависит от Парсера – он его сам создает, настраивает и инициализирует. Возможно, для инициализации в Парсер нужно передать кучу разных параметров.

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

Попробуем решить проблему, уменьшив зависимость Читателя от Парсера.

Второе перевоплощение – применение подхода «внедрение зависимости».

Мы выносим создание Парсера через конструктор выше – на точку входа, и внедряем его переменную в Читатель.

Теперь Читателю больше вообще не нужно знать о внутреннем устройстве парсера – как его создавать, заполнять, инициализировать. Самое главное для Парсера – чтобы он соблюдал свой программный API по вызову метода РазобратьТекст. Все остальное ему уже не важно.

Осталась еще одна проблема – захардкоженный файл. Ее можно решить:

• через чтение настроек конфигов;

• через переменную окружения;

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

Я дальше покажу, как она решается.

Все классно, практически идеально, но есть нюанс, как всегда.

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

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

Прежде чем до конца нырнуть в ОСень, я расскажу про второе отличие OneScript от 1С – в OneScript есть такой специфичный объект как Рефлектор. Через Рефлектор можно смотреть метаданные другого класса: получать список его полей, методов, узнавать, какие параметры требуются в тот или иной метод, и какие аннотации навешаны методами либо полями.

На слайде – небольшой пример с описанием класса ОбъектИсследования. Здесь показано, как через Рефлектор мы из другого скрипта можем вытащить таблицу методов и таблицу свойств.

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

С его помощью можно найти все данные класса. Здесь есть таблица методов и таблица свойств, которая имеет внутри таблицу аннотаций – там лежат эти аннотации.

Обратите внимание, что в аннотациях даже допускаются именованные параметры, например:

&ВажноеПоле(УровеньВажности = "Очень")

Информацию из таких аннотаций потом можно очень хитро обыгрывать в своих приложениях.

Это сложно, не вникайте. Просто поверьте, что это есть, и это классно работает.

Основные идеи, заложенные в ОСени

Дальше начинается безумие.

В ОСени есть несколько догм, в терминах которых это все работает:

• Все есть &Желудь.

• Еще есть &Дуб и &Завязь.

• Есть &Пластилин – без пластилина Поделку сделать нельзя.

• Да, Поделка у нас тоже есть – ее можно объявить через Новый Поделка()

• Иногда поможет &Напильник, но он дорогой.

• &Блестяшка – это красиво, &Деталька – это очень удобно.

• Есть &Заготовка – с нее можно начать.

• И есть &Рогатка – из рогатки можно стрелять.

• Есть мета-аннотации – это прямо киллер-фича.

• И есть &Табакерка – она тоже очень классная.

Нравится?

Конечно же, я постараюсь рассказать об основных идеях, которые заложены в ОСени, но ничто не заменит прочтение документации.

На слайде – реакции некоторых читателей этой документации. Поулыбаемся. Прикольно.

&Желудь + &Пластилин = Поделка

Теперь немного ближе к делу.

Как я уже сказал раньше, все есть &Желудь. Давайте разберемся, что это значит.

Мы пропагандируем максимальную декомпозицию. Минимальная атомарная единица нашего приложения – это компонент, класс. Этот класс мы помечаем аннотацией &Желудь.

Не секрет, что мы оглядывались на Spring, а там есть аналогичное понятие bean – зерно. Думаю, справедливо, что раз у нас ОСень, то объект, аналогичный зерну, у нас называется Желудь.

Забавно, что если вы погрузитесь в ОСень, разберетесь в ее концепциях и подходах, а потом вам захочется переквалифицироваться в джависта и изучать Java Spring, окажется, что вы уже знаете все базовые основы, достаточные для джуна по Spring. Там все то же самое, только синтаксис другой. Это еще один хороший плюс.

Как я уже показал пару слайдов назад, в OneScript можно создавать свои классы объектов. Чтобы сделать свой класс компонентом ОСени, достаточно добавить ему аннотацию &Желудь.

Важно, что любой объект OneScript (даже движковый – например, массив, строка, структура, таблица значений) – все можно превратить в желудь.

И даже объекты из сторонних библиотек, которые вы будете использовать, тоже можно превратить в желудь.

Мы это называем «зажелудить» – такой термин у нас родился относительно недавно.

Про то, как превращать в Желуди массивы и все остальное, я дальше тоже расскажу.

Теперь, когда мы познакомились с определением Желудя, давайте закрепим результат и переведем на ОСень наше классное приложение.

• Сделаем Парсер желудем – объявим над методом ПриСозданииОбъекта аннотацию &Желудь.

• А теперь очень внимательно посмотрите на Читателя. Он тоже стал Желудем, и еще у него изменился конструктор ПриСозданииОбъекта – я убрал оттуда параметр Парсер и установку переменной модуля ПарсерЧудногоФормата.

• И над полем Парсера появилась новая аннотация &Пластилин.

Я специально сделал слайд, чтобы вы увидели, как изменился текст класса ЧитательТекстовогоФайла. Здесь можно посмотреть, что я убрал все из конструктора, добавил полю ПарсерЧудногоФормата аннотацию &Пластилин и что-то еще сделал.

Но у вас, наверное, появляется вопрос: «Какой &Пластилин? Ты о чем вообще? Таблетки забыл выпить?» Я вам отвечу – чтобы сделать ОСеннюю Поделку, нужно несколько Желудей скрепить между собой Пластилином.

А если серьезно, в нашем фольклоре аннотация &Пластилин значит, что в эту переменную нужно передать Желудь. А как передать, я сейчас объясню.

Аннотация &Пластилин указывает библиотеке о том, что в данную переменную нужно установить значение желудя. А какой желудь будет устанавливать это значение – ОСень поймет по имени этой переменной.

• Если имя переменной совпадает с именем Желудя (как в первом примере на слайде) больше ничего писать не надо – туда все само подставится.

• Если мы вдруг назвали переменную по-другому, то, чтобы ОСень смогла найти, что туда подставить, мы должны в скобочках указать имя нужного Желудя. Это – второй пример на слайде.

&Пластилин бывает нескольких разных видов – на этом слайде показаны три способа внедрения Желудей. Я их перечислю именно в том порядке, в котором это делает движок.

• Сначала вызывается конструктор ПриСозданииОбъекта(), в него через параметр с аннотацией &Пластилин("ИмяЖелудя") могут быть переданы Желуди-зависимости.

• Потом зависимости устанавливаются в поля класса, отмеченные аннотацией &Пластилин.

• И в конце вызываются процедуры-сеттеры, в которые тоже передаются значения. Такая процедура создается следующим образом: мы пишем «Установить» – это зарезервированное слово, и дальше имя нужного Желудя. Ставим методу аннотацию &Пластилин, и дальше ОСень все сделает за вас.

Мы прошли долгий путь, поняли принцип работы желудей и их взаимодействие между собой. Но у вас в головах наверняка возникает вопрос: «В какой момент происходит вся эта магия по внедрению зависимостей?»

У меня есть ответ – все происходит внутри Поделки.

Поделка – это тот самый контейнер inversion of control, о котором я рассказывал раньше. У Поделки две стадии жизни:

• Первая стадия жизни – когда мы ее конфигурируем, настраиваем, добавляем в нее Желуди и регистрируем их там.

• И вторая стадия жизни – это когда мы запускаем приложение через метод Поделка.ЗапуститьПриложение(). После этого метода мы новые Желуди туда уже добавлять не можем, но можем Желуди оттуда получать – например, через метод НайтиЖелудь().

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

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

А как следствие:

• нам проще переиспользовать такой код;

• такие приложения легче сопровождать и расширять;

• и когда между классами такая слабая связанность, это очень здорово тестировать – маленькие объекты с отдельными независящими друг от друга функциями тестами все покрываются замечательно;

• плюс к этому ОСень имеет в себе функциональность, которая позволит одни объекты мокировать другими – я об этом позже покажу, вам это тоже понравится.

И это еще далеко не все, что умеет ОСень. Но сейчас давайте двинемся дальше – я постараюсь рассказать еще что-нибудь.

Детальки, заготовки, рогатки, напильники и все-все-все

&Детальки – это такие прикольные штучки, которые могут очень сильно упростить нам жизнь.

Зачастую в коде нужно использовать какие-то значения, которыми очень хотелось бы управлять извне. Помните, у нас была история с настройкой ПутьКФайлу? Чтобы его не хардкодить, ОСень позволяет готовить конфигурационные файлы autumn-properties.json, из которых автоматически подтягиваются значения через поля скрипта с аннотацией &Деталька.

Файл autumn-properties.json мы кладем рядом со скриптом запуска и объявляем там нужные настройки через структуру в формате JSON. На слайде показано, как задается значение настройки МояНастройка.ПутьКФайлу – это значение приедет ко мне в переменную автоматически, я нигде никакой код не пишу, я все аннотациями разметил.

Причем, эти конфигурационные файлы можно писать не только в JSON, но и в YAML, если вам больше нравится YAML.

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

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

• Как только мы вешаем над этой функцией аннотацию &Завязь, она превращает то, что она возвращает, в Желудь.

Если после этого я где-то в другом Желуде напишу:

&Пластилин
Перем Команда

– тогда подключится Дуб и отдаст мне команду как объект.

Помимо команды, здесь может быть массив, таблица значений – что угодно. Так можно отдавать даже строки – например, какие-нибудь пароли.

С Дубами вроде понятно, разобрались, пытаемся идти дальше.

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

Например, мы достали Желудь из Поделки и хотим внести в него изменения – немного приукрасить перед тем, как прилепим к другому Желудю.

Чтобы это можно было сделать, нам понадобится &Напильник. Возьмем Напильник и «вжухнем» по Желудю.

Кроме шуток, &Напильник – это подписка на события, которая срабатывает при получении Желудя из Поделки, но до непосредственной установки этого Желудя в другую переменную.

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

Суть Рогатки в том, что ее код выполняется при старте приложения – когда мы пишем:

Поделка.ЗапуститьПриложение()

Рогатка выполняет свой код в процедуре ПриЗапускеПриложения() – это дополнительная инициализация на запуске.

ОСень, как и все в этом мире, с чего-то начинается. И Поделка в ОСени начинается с Заготовки.

&Заготовка – это такая хитрая штука, код которой срабатывает сразу в момент, когда мы Желудь добавляем в Поделку.

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

На этом слайде наглядно показаны моменты срабатывания подписок.

• При выполнении кода:

  Поделка = Новый Поделка();

  у нас тут же включились все Заготовки и выполнили свой код.

• Потом мы сделали:

  Поделка.ЗапуститьПриложение()

  и у нас включились все Рогатки и начали стрелять по всем.

• Потом мы достаем Желудь из Поделки и у нас там работают Напильники и делают по нему свой «вжух».

Еще одна прикольная цитата, можно посмеяться:

Задумал я писать библиотеку под Redis… начал читать документацию. Потом все как в тумане. Очнувшись, я увидел, что стою у плиты, &Напильником мешаю &Желуди в сковороде, добавляю немного &Завязей для аромата и в перерывах курю ветку &Дуба.

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

Управление Желудями при помощи мета-аннотаций

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

Звучит непонятно, но сейчас я даже не буду тратить время на объяснения, как это сделать – я просто покажу примеры:

• У нас есть аннотация &Контроллер, которая при создании объекта превращает его в Желудь и навешивает на него много интересной логики.

• Есть аннотация &КомандаПриложения – она тоже делает из вашего класса Желудь, превращает его в команду приложения и выполняет различные инфраструктурные штуки.

• Или, например, можно заменить &Пластилин на &Лог(“ИмяЛогера”) – в этом случае у нас переменная реально превращается в объект Лог, у которого можно вызвать методы Ошибка(), Информация() и т.д.

• А потом мы совсем упоролись и сделали возможность на аннотациях генерировать коллекции – таблицы значений и т.д. Это тоже превращает &Пластилин в нечто красивое.

Поговорим про виды желудей.

Первый вид, который мы рассмотрим – это синглтон, одиночка.

По умолчанию все желуди – одиночки. Желудь-одиночка создается и заполняется единожды и при следующих получениях его из Поделки либо внедрении в другие Пластилины он достается уже из кэша всегда один и тот же.

Это удобно, если Желудь не хранит в себе никаких данных, а только выполняет какую-то логику. Зачем нам для этого кучу разных объектов создавать?

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

Еще есть компанейские желуди (prototype).

Это желуди с дополнительной аннотацией:

&Характер("Компанейский")

Они точно такие же, как одиночки, но когда мы достаем такой Желудь из Поделки или пытаемся засунуть куда-то в Пластилин, он каждый раз создается новый.

Компанейские Желуди удобно использовать, когда нам нужно много объектов одного типа, но с разными настройками – т.е. они могут использовать какие-то свои данные.

Верховные желуди можно использовать для мокирования, потому что желудь с аннотацией &Верховный при добавлении в Поделку заменяет собой уже имеющийся там Желудь. Замена сопоставляется по имени желудя.

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

• Первый пример – когда мы разрабатываем приложение, которое в ходе работы получает какие-нибудь данные, например, из СУБД. Чтобы во время разработки и автотестов не зависеть от данных этой СУБД, если у нас нет ее под рукой, мы просто подменяем имеющийся в продуктовом коде Желудь, берущий данные из какой-то СУБД, другим Желудем, который никуда не обращается, а просто отдает какой-то предопределенный набор тестовых данных.

• Либо второй еще пример – когда вы используете чужую библиотеку, которая читает данные из текстового файла и куда-то их отправляет. Но вам из файла читать не нужно, вы хотите тянуть эти же данные из REST-сервиса. Что делать? Конечно, можно перепилить чужую библиотеку. А можно в готовую поделку чужого приложения закинуть свой Верховный Желудь, который подменит эту логику, откуда брать данные. И все – ничего не нужно переписывать, никому не нужно пулл-реквестить, все работает подменой Желудя. Модно, удобно, молодежно.

Это чем-то похоже на расширение в 1С с аннотацией &Вместо. Но только там она заменяет определенный метод, а здесь через аннотацию &Верховный заменяется вообще весь объект.

Прозвище – это дополнительное имя желудя. По прозвищу Желуди можно группировать – получать массив желудей с одинаковым прозвищем.

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

Под каждого подписчика мы создадим отдельный Желудь и объединим их под одним прозвищем «ПодписчикНаСобытие».

Далее через &Пластилин получим в переменную Подписчики массив Желудей с прозвищем «ПодписчикНаСобытие» и для каждого из них вызовем метод Отправить().

А в дальнейшем, если нам нужно будет расширить команды получателей, нам нужно будет лишь добавить еще один класс с нужным прозвищем.

Классно, удобно, гибко.

Экосистема библиотек для ОСени

Для ОСени уже есть целый набор инструментов и библиотек, которые либо расширяют ее функциональность, либо что-то облегчают.

Первый пример – это autumn-cli.

Наверное, все из вас использовали vanessa-runner – у него под капотом есть библиотека cli, которая позволяет делать консольные приложения. Но если вы попытаетесь разработать на базе библиотеки cli что-то инфраструктурное, вам придется очень много копипастить из каких-то шаблонов.

При разработке консольного приложения на autumn-cli ничего этого делать не надо:

• создаем класс;

• через аннотации &Опция, &КомандаПриложения, &Аргумент задаем опции, команды, аргументы;

• кидаем этот Желудь в Поделку, вызываем Поделка.ЗапуститьПриложение(), и все – оно сработает как консольное.

Легко, быстро, удобно.

Кстати, консольное приложение ovm, которое устанавливает OneScript и позволяет переключать разные версии, сейчас переписано на autumn-cli.

Autumn-logos – это обертка над библиотекой logos. С помощью autumn-logos вы можете создавать объект лога с вот такими красивыми аннотациями. Здесь даже можно использовать мета-аннотацию, не указывая имя лога – это выглядит гораздо понятнее и удобнее, чем стандартный вызов логирования.

Autumn-validate – еще одна прикольная библиотека. Она пригодится, если у вас есть какие-то поля, и вам нужно их как-то проверять.

Например:

&Минимум(-10)
&Максимум(10)
&Заполнено

Чтобы не писать «Если… Тогда…Иначе…», можно просто повесить аннотации, и библиотека сама потом проверит – правильно у вас объект заполнен или нет.

И еще чуть-чуть библиотек:

• Есть autumn-annotation-types – библиотека, которая позволяет создавать таблицы значений, структуры, массивы и т.д. с помощью красивых аннотаций.

• Есть autumn-killjoy-flavour – она заменяет все эти Желуди и Пластилины на нормальные человеческие названия. Вдруг у вас начальник увидит, что вы в коде пишете какие-то Желуди и уволит вас (или в дурку сдаст). Чтобы обезопаситься, можно использовать эту библиотеку – она подменяет все названия.

• Autumn-async – библиотека для удобного создания асинхронных методов. В OneScript есть асинхронные методы и фоновые задания, но чтобы это как-то заработало в параллель, нужно написать кучу кода. А с этой библиотекой уже не нужно писать кучу кода, пишем аннотацию &Асинх – и все, метод становится асинхронным и возвращает объект OneScript «Обещание». Классно.

• Ну, и, конечно, есть библиотека winow – это веб-фрейворк, работающий по аналогии с Spring Web. Winow позволяет с помощью этой всей магии внедрения зависимостей делать классные веб-приложения – либо REST, либо с отдачей HTML, даже веб-сокеты поддерживает. На нем можно прям сесть и написать Facebook – правда, он не вывезет 10 миллионов пользователей в секунду. Но написать можно. Кстати, по поводу winow у нас будет мастер-класс.

• Кроме этого там есть еще несколько библиотек, которые недавно появились – я не знаю, что они делают, но, наверное, они классные.

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

• Будет реализована библиотека autumn-data, которая позволит реализовать на аннотациях удобную работу с базой данных. Например, можно будет там создать элементы справочников и т.д.

• Для winow когда-нибудь выйдет библиотека для построения пользовательского интерфейса на HTML с помощью кода на OneScript. Например, мы сможем там написать: ДобавитьПолеВвода такого-то типа, и все будет работать. Когда – не знаю, но будет.

• И мы очень хотим поддержать OneScript 2.0, где есть классная директива #native, которая берет ваш код на OneScript и компилирует его сразу в .NET, чтобы все работало просто пулей.

Хочется поблагодарить:

• Никиту Федькина – это идеолог и автор ОСени, с его благословения я сейчас и выступаю перед вами.

• и Андрея Овсянкина, автора OneScript – без него вообще ничего бы не получилось. Из-за того, что он реализует все наши хотелки в OneScript, у нас и появилась ОСень.

По полезной ссылке https://github.com/autumn-library вы можете найти и прочитать все, о чем я рассказывал, и даже больше.

Вопросы

Меня удивило, что, оказывается, есть библиотека для скучного нейминга. А нет ли планов сделать отдельную версию для душнил, чтобы скучный нейминг был по умолчанию?

Чтобы использовать скучный нейминг, достаточно при объявлении точки входа добавить еще один include, и оно все сразу будет.

В начале скрипта достаточно написать

#Использовать autumn-killjoy-flavour

и нейминг автоматически меняется.

Скажите, какие приложения вы разрабатываете на OneScript, что нужно настолько сильно заморачиваться с зависимостями?

Например, целый веб-сервер с роутингом, маршрутизацией и веб-сокетами.

Из последнего, что делал, но не довел до ума, потому что времени не хватило – ради эксперимента писали парсер журнала регистрации с переливкой в ClickHouse. У нас это уже реализовано на .NET, но мы же парсим полтора терабайта логов 1С-ных – нам хотелось проверить OneScript на таких больших данных. Не очень получилось пока что, но как только директива #native в OneScript 2.0 полноценно заработает, будем использовать.

В Spring же тоже наблюдается немного странный уклон по наименованиям?

Там в основном только bean – зернышки, а все остальное – более-менее человеческое. А у нас крышу сорвало совсем, у нас все нечеловеческое.

Это же все можно завернуть в Docker? Проблем не будет никаких?

OneScript работает на Mac, на Linux, под Windows, и в Docker он тоже работает.

В Docker Hub есть уже готовые образы для OneScript.

Winow можно запустить в Docker, и у тебя будет Docker, в котором поднимается и работает сайт, написанный на OneScript. В его репозитории есть пример докерфайла.

Насколько вся эта обвязка влияет на производительность?

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

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

Это не дает какой-то дополнительной сверхнагрузки, просто нужно немножко держать в уме, что меньше компанейских, больше синглтонов, и тогда все вообще хорошо будет.

А если по скорости сравнить OneScript.Web и Winow?

Я не сравнивал. Они будут приблизительно одинаковые. Хотя в OneScript.Web под капотом стоит Kestrel, он должен быть побыстрее.

Первая версия Winow обрабатывала всего лишь 30 запросов в секунду. Сейчас она обрабатывает около 700 запросов в секунду. Я знаю как ускорить, но пока не трогаю, потому что ждем версию OneScript с директивой #native, а там будем разбираться с производительностью.

А winow работает на OneScript 2.0?

ОСень и Winow работают и на 2.0, и на 1.8.

С директивой #native на каких операционных системах будет запускаться?

Оно уже сейчас работает на всех операционных системах, но под 2.0 там несколько иной запуск.

Чтобы запускать OneScript 1.8, нужно на Linux или на Mac иметь Mono и запускать:

mono oscript.exe

А для 2.0 нужно иметь не Mono, а .NET Core, и вместо этого написать:

dotnet oscript.dll

тогда он также запускается. А когда ставишь через ovm, он сам все в PATH прописывает.

Поддерживаются ли все эти языковые конструкции в редакторе VS Code?

Сам синтаксис OneScript поддерживается, все хорошо раскрашивает. А конкретно ОСень и ее специфика – пока не поддерживается, надо дорабатывать плагин для VS Code.

А планируете поддержать?

Не в первую очередь, пока есть более насущные проблемы.

Конечно, хочется, чтобы IDE это поддерживала, насколько это возможно. Больше всего хочется, чтобы в BSL LS появился нормальный честный автокомплит по контексту. Как только появится, все остальное уже подтянется легко.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

Также предлагаем посмотреть мастер-класс.