Новинки архитектуры systems frameworks
Мне очень нравится термин "language smartness provider" из архитектуры поддержки многоязыковости "инструментов" различными "языковыми серверами": https://github.com/Microsoft/language-server-protocol. Вот короткий список реализаций редакторов и IDE для этой архитектуры (https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations): VS Code -- https://code.visualstudio.com, Eclipse Che https://www.eclipse.org/che/ и пока всё, стандартам Microsoft пока никто больше не следует).
Smartness в языке -- это autocomplete, goto definition, find all references и т.д.. Дальше будут language intelligence providers, начиная с линии "завершить по высказанному намерению" (http://ailev.livejournal.com/1269236.html), протокол для них уже есть.
Интересно, что архитектурно в "редакторе кода" выделен "редактор текста", который может, например, автономно встраиваться в браузер (скажем, из VS Code выделен редактор Monaco -- https://github.com/Microsoft/monaco-editor) и уже там поддерживать все сервисы language smartness provider. В принципе, и над редактором много чего можно надстроить -- в том числе и без поддержки протокола языковых серверов, а "на коленке" (например, над Atom-редактором от GitHub надстраивают многоплатформенную IDE от Facebook -- https://nuclide.io/, или одноплатформенную IDE для IoT проектов -- https://www.particle.io/dev).
В любом случае, можно выделить две части: персональную и групповую, т.е.
-- IDE/САПР/фронт-энд (поддержка veiw и viewpoint) становится модульным и скоро тут нужно ждать интересных API, и
-- workspace server/ALM/PLM бэкенд (управление конфигурацией и изменениями) тоже становятся модульными: управление версиями (обычно сейчас это Git на его API) и issue tracker (пока не цепляется по умолчанию, но это обязательно будет) пока сами по себе модули и проблема наоборот -- в их интеграции. Тут не нужно забывать, что ещё кроме репозитория описания системы есть и воплощение системы, т.е. сама система. Для программистов это работающий код. Workspace server в Eclipse Che с поддержкой инструментария DevOps решает как раз и проблему контроля конфигурации за пределами интеграции с Git, но и автоматизируя deployment. Для "железячников и бетонщиков" думайте о разнице представления системы в PLM, ERP и EAM -- в EAM как раз учитывается конфигурация реальной системы, и различия во всех этих системах идут главным образом от разительно более долгого жизненного цикла "железа и бетона". Программисту с их "утром в куплете, вечером в газете" и концепцией DevOps трудно понять, почему все данные о системе нельзя собрать в рамках одного репозитория, а вот каким-нибудь строителям с отдельным КБ и отдельным owner-operator такое понять легко. Но функционально там во многом одно и то же, обсуждать нужно этот софт похожим образом!
Для этих частей хорошо бы вспомнить и разделение на персонального и группового ассистентов из нейронета, плюс необходимость поддержания какого-то уровня privacy. Но это дело не ближайшего будущего.
От текстов (кода ли на сотне языков, CSS или XML или JSON, или даже SciFi на каком-нибудь тамильском) неизбежен переход к их унифицированному представлению во view с не-текстами. А пока не-тексты появляются, но как-то "сбоку" например, в VS Code 1.3 New API to open non-text resources -- https://code.visualstudio.com/updates/June_2016. Главное, что не-тексты уже рассматриваются! От "редактора текстов" до "редактора текстов/кода и моделей" уже буквально один шаг. Но шаг довольно-таки большой: достаточно поглядеть на "редактор 3D модели". Впрочем, машиностроительные САПРы с веб-интерфейсом уже более чем распространены (https://www.onshape.com/, http://www.autodesk.com/products/fusion-360/overview), так что и тут идёт архитектурная унификация с другими видами моделеров. А уж просто exploratory programming над какими-то базами данных на SQL -- этого тоже полно, с тем же интерфейсным инструментарием на http://electron.atom.io/ -- вот, например, графики по базам данных и код запросов в одном IDE рядышком: https://www.wagonhq.com/.
В принципе, и графические языки можно встраивать, и новые языки делать, для этого можно использовать остатки древней language workbench Xtext, сейчас они себя называют language framework. Проект с Xtext продолжает развиваться в сторону создания viewpoints с DSL, встраиваемых в современные редакторы (те же Visual Studio Code и Eclipse Che) --http://www.eclipse.org/Xtext/, http://typefox.io/. Есть и modeling workbench для графических языков, с ними и Xtext тоже работает совместно для текстового варианта языка -- https://www.eclipse.org/sirius/
Сейчас прото-systems frameworks появляются как эклектика из самых разных технологий (например, Architecturally, Visual Studio Code combines the best of web, native, and language-specific technologies. Using Electron, VS Code combines web technologies such as JavaScript and Node.js with the speed and flexibility of native apps. -- https://code.visualstudio.com/docs/editor/whyvscode). В лидеры пока выбились системы на node.js, но это явление временное, скоро подтянутся и другие языки и интерфейсные фреймворки (скажем, Eclipse Che не использует node.js сам, но работает с node.js как одним из viewpoint: https://eclipse-che.readme.io/docs/get-started-with-nodejs-and-che). Кто дочитал до этого места: как вы считаете, почему взлёт популярности node.js пару лет назад закончился? Куда ушёл фронтир и кто подхватил эстафету? Вот пруфлинк: https://www.google.com/trends/explore#q=node.js
Это я продолжаю линию на формулирование предмета системной информатики (http://ailev.livejournal.com/1272169.html, http://ailev.livejournal.com/1274210.html, http://ailev.livejournal.com/1273208.html, http://ailev.livejournal.com/1275143.html): идёт потихоньку поиск в области архитектуры systems framework, начиная пока с
-- редакторов кода (они работают с файлами в папках ОС) и потом постепенно продолжаясь на
-- IDE (они работают с проектами в репозиториях), а затем захватывая и
-- моделеры различных языков моделирования-онтологизирования
-- САПР (3D, технологические) и симуляторы
-- dashboards к базам данных для редактирования этих разной, в том числе NoSQL структуры баз данных.
-- стыка с разными workspaces, в которые входят обычно распределённые системы управления конфигурацией (контроль версий, базы данных, wiki -- это ведь тоже системы контроля версий для текстов!) и изменениями (issue trackers, и чаты -- тот же slack и прочие IRC для разработчиков. Issue перед тем как стать issue имеет свои две минуты вопросов в чате, и только потом оформляется как issue и далее проходит свой путь уже как task и потом notice. Управление изменениями -- наиболее мутный кусок, сюда ведь и case management входит с шаблонами кейсов и CMMN, и управление проектами, и "методологии разработки" утыкаются именно сюда).
Редактирование в таких средах в ходе разработки идёт как "руками", так и из языковых сниппетов (язык запросов к данным, он же язык программирования -- как в REPL реализация exploratory programming, так и "просто программирование"). Редактирование и (пошагово-ручная и автоматизированная) обработка данных (кода, моделей, текста, картинок и т.д.) плюс средства автоматизации этой обработки в одном флаконе. В игровых "песочницах" тоже так: что-то делается "руками", но что-то -- любовно написанными скриптами, ибо "нельзя же так долго и плохо". Но "рукам" место находится всегда, ручные просмотр/редактирование (browsing/editing) должны быть всего описания системы, равно как и исполнение (executing/evaluation) кода должны быть предусмотрены для напускания на всю мегамодель. Мегамодель aka "описание системы" тем самым -- "база знаний" по старинному определению: в ней лежат не только данные описания системы, но часть этих данных -- программы по их обработке. "Базой знаний" называли раньше базы данных, в которых хранились программы по обработке этих баз данных, каковые программы находились и вытаскивались языками запросов к базе.
Проблема, которую решает системная информатика, одна: в полноценном проекте нужно моделировать систему и при этом управлять конфигурацией и изменениями и данными. Для этого нужно сделать
-- systems framework/engine, который будет поддерживать множество разных view, для чего иметь какой-то протокол подключения разных viewpoints, репозиториев для них и механизмы exploration programming/modeling/querying плюс issue tracking, в том числе обеспечивая работу команды внутренних и внешних стейкхолдеров. Systems framework подразумевает и протокол подключения разной степени smartness и intelligence для viewpoints ("языков" -- программирования, моделирования, проектирования и т.д.) и общие механизмы smartness и intelligence для системного уровня (интеграции всех этих view и обеспечения индивидуальной и групповой работы), включая и "нейро" -- скажем, отслеживание cognitive load и помощь в управлении чиксентмихаевским потоком. У игровиков это "игровой движок".
-- мегамоделер, в который превращается systems framework путём начинки его необходимым набором плагинов, реализующих viewpoints и добавленную для этих viewpoints различную smartness и intelligence. Некоторые viewpoints могут подразумевать работу не с репозиториями данных, а с hardware (ибо речь может идти о симуляционных описаниях системы -- все эти hardware-in-the-loop). Мегамоделер настроен на описание какого-то класса систем, поддерживает необходимый для этого набор рабочих мест с предметно-ориентированными view и имеет репозиторий для хранения всех необходимых для проектов разработки этого класса систем данных. У игровиков это собственно игра, в том числе и её моды (разрабатываемые, вестимо, на движке).
-- прикладная система разработки для какой-то системы: мегамоделер, начинённый данными модели какой-то системы и содержащий необходимые для работы конфигурационные файлы для всех view и viewpoint, удобные для работы с данными моделей конкретной системы или их класса сниппеты кода, профили конкретных разработчиков и всё прочее, что отличает свежеразвёрнутый моделер от моделера, в котором уже год-два проектируется какое-нибудь нейроприложение, атомная станция или ГМО (life sciences ведь тут не исключение -- это ж "информатика", она для всех!). У игровиков это "сервера".
Конечно, таких архитектур будут тьмы, тьмы и тьмы. Впрочем, не "будут". Их уже огромное число: все эти "мультиязыковые редакторы" и "фреймворки приложений" уже есть. Так что нужно просто научиться
-- очень компактно об этом рассказывать, сравнивать такие системы между собой и находить их killer features
-- обсуждать пути их развития, обсуждать необходимо следующие из системного подхода функции, требуемые к реализации в рамках systems framework,
-- наоборот к предыдущему пункту: поскольку такие системы отражают практику, обогащать системный подход поддерживаемыми системными фреймворками не артикулированными явно новыми приёмами системного мышления, артикулировать эти приёмы мышления явно
-- обсуждать архитектуру таких систем и инструментарий для того, чтобы лучше их строить, быстрее развивать и с меньшими рисками эксплуатировать (systems framework engineering, можно ещё поглядеть, насколько это отлично от information systems engineering в классическом разделении software engineering, information systems, information technology, computer science -- см. типичные определения типа https://blog.soton.ac.uk/comp6044/2011/11/20/05-information-systems/ или разделения типа http://www.geteducated.com/careers/521-computer-information-systems-vs-computer-science или http://www.computersciencedegreehub.com/faq/difference-computer-science-degree-computer-information-systems-cis-degree/).
Это и есть системная информатика, interdisciplinary approach and means to enable the realization of successful information systems:
-- междисциплинарный -- то бишь с системным подходом в голове, множество viewpoints, оформляющие concerns самых разных stakeholders
-- обеспечение воплощения -- это инженерия, "от мысли к изменению мира, реализации"
-- информационные системы -- речь идёт о системах для описания систем
-- успешные -- системы для описания систем, удовлетворяющие нуждам множества стейкхолдеров.
Smartness в языке -- это autocomplete, goto definition, find all references и т.д.. Дальше будут language intelligence providers, начиная с линии "завершить по высказанному намерению" (http://ailev.livejournal.com/1269236.html), протокол для них уже есть.
Интересно, что архитектурно в "редакторе кода" выделен "редактор текста", который может, например, автономно встраиваться в браузер (скажем, из VS Code выделен редактор Monaco -- https://github.com/Microsoft/monaco-editor) и уже там поддерживать все сервисы language smartness provider. В принципе, и над редактором много чего можно надстроить -- в том числе и без поддержки протокола языковых серверов, а "на коленке" (например, над Atom-редактором от GitHub надстраивают многоплатформенную IDE от Facebook -- https://nuclide.io/, или одноплатформенную IDE для IoT проектов -- https://www.particle.io/dev).
В любом случае, можно выделить две части: персональную и групповую, т.е.
-- IDE/САПР/фронт-энд (поддержка veiw и viewpoint) становится модульным и скоро тут нужно ждать интересных API, и
-- workspace server/ALM/PLM бэкенд (управление конфигурацией и изменениями) тоже становятся модульными: управление версиями (обычно сейчас это Git на его API) и issue tracker (пока не цепляется по умолчанию, но это обязательно будет) пока сами по себе модули и проблема наоборот -- в их интеграции. Тут не нужно забывать, что ещё кроме репозитория описания системы есть и воплощение системы, т.е. сама система. Для программистов это работающий код. Workspace server в Eclipse Che с поддержкой инструментария DevOps решает как раз и проблему контроля конфигурации за пределами интеграции с Git, но и автоматизируя deployment. Для "железячников и бетонщиков" думайте о разнице представления системы в PLM, ERP и EAM -- в EAM как раз учитывается конфигурация реальной системы, и различия во всех этих системах идут главным образом от разительно более долгого жизненного цикла "железа и бетона". Программисту с их "утром в куплете, вечером в газете" и концепцией DevOps трудно понять, почему все данные о системе нельзя собрать в рамках одного репозитория, а вот каким-нибудь строителям с отдельным КБ и отдельным owner-operator такое понять легко. Но функционально там во многом одно и то же, обсуждать нужно этот софт похожим образом!
Для этих частей хорошо бы вспомнить и разделение на персонального и группового ассистентов из нейронета, плюс необходимость поддержания какого-то уровня privacy. Но это дело не ближайшего будущего.
От текстов (кода ли на сотне языков, CSS или XML или JSON, или даже SciFi на каком-нибудь тамильском) неизбежен переход к их унифицированному представлению во view с не-текстами. А пока не-тексты появляются, но как-то "сбоку" например, в VS Code 1.3 New API to open non-text resources -- https://code.visualstudio.com/updates/June_2016. Главное, что не-тексты уже рассматриваются! От "редактора текстов" до "редактора текстов/кода и моделей" уже буквально один шаг. Но шаг довольно-таки большой: достаточно поглядеть на "редактор 3D модели". Впрочем, машиностроительные САПРы с веб-интерфейсом уже более чем распространены (https://www.onshape.com/, http://www.autodesk.com/products/fusion-360/overview), так что и тут идёт архитектурная унификация с другими видами моделеров. А уж просто exploratory programming над какими-то базами данных на SQL -- этого тоже полно, с тем же интерфейсным инструментарием на http://electron.atom.io/ -- вот, например, графики по базам данных и код запросов в одном IDE рядышком: https://www.wagonhq.com/.
В принципе, и графические языки можно встраивать, и новые языки делать, для этого можно использовать остатки древней language workbench Xtext, сейчас они себя называют language framework. Проект с Xtext продолжает развиваться в сторону создания viewpoints с DSL, встраиваемых в современные редакторы (те же Visual Studio Code и Eclipse Che) --http://www.eclipse.org/Xtext/, http://typefox.io/. Есть и modeling workbench для графических языков, с ними и Xtext тоже работает совместно для текстового варианта языка -- https://www.eclipse.org/sirius/
Сейчас прото-systems frameworks появляются как эклектика из самых разных технологий (например, Architecturally, Visual Studio Code combines the best of web, native, and language-specific technologies. Using Electron, VS Code combines web technologies such as JavaScript and Node.js with the speed and flexibility of native apps. -- https://code.visualstudio.com/docs/editor/whyvscode). В лидеры пока выбились системы на node.js, но это явление временное, скоро подтянутся и другие языки и интерфейсные фреймворки (скажем, Eclipse Che не использует node.js сам, но работает с node.js как одним из viewpoint: https://eclipse-che.readme.io/docs/get-started-with-nodejs-and-che). Кто дочитал до этого места: как вы считаете, почему взлёт популярности node.js пару лет назад закончился? Куда ушёл фронтир и кто подхватил эстафету? Вот пруфлинк: https://www.google.com/trends/explore#q=node.js
Это я продолжаю линию на формулирование предмета системной информатики (http://ailev.livejournal.com/1272169.html, http://ailev.livejournal.com/1274210.html, http://ailev.livejournal.com/1273208.html, http://ailev.livejournal.com/1275143.html): идёт потихоньку поиск в области архитектуры systems framework, начиная пока с
-- редакторов кода (они работают с файлами в папках ОС) и потом постепенно продолжаясь на
-- IDE (они работают с проектами в репозиториях), а затем захватывая и
-- моделеры различных языков моделирования-онтологизирования
-- САПР (3D, технологические) и симуляторы
-- dashboards к базам данных для редактирования этих разной, в том числе NoSQL структуры баз данных.
-- стыка с разными workspaces, в которые входят обычно распределённые системы управления конфигурацией (контроль версий, базы данных, wiki -- это ведь тоже системы контроля версий для текстов!) и изменениями (issue trackers, и чаты -- тот же slack и прочие IRC для разработчиков. Issue перед тем как стать issue имеет свои две минуты вопросов в чате, и только потом оформляется как issue и далее проходит свой путь уже как task и потом notice. Управление изменениями -- наиболее мутный кусок, сюда ведь и case management входит с шаблонами кейсов и CMMN, и управление проектами, и "методологии разработки" утыкаются именно сюда).
Редактирование в таких средах в ходе разработки идёт как "руками", так и из языковых сниппетов (язык запросов к данным, он же язык программирования -- как в REPL реализация exploratory programming, так и "просто программирование"). Редактирование и (пошагово-ручная и автоматизированная) обработка данных (кода, моделей, текста, картинок и т.д.) плюс средства автоматизации этой обработки в одном флаконе. В игровых "песочницах" тоже так: что-то делается "руками", но что-то -- любовно написанными скриптами, ибо "нельзя же так долго и плохо". Но "рукам" место находится всегда, ручные просмотр/редактирование (browsing/editing) должны быть всего описания системы, равно как и исполнение (executing/evaluation) кода должны быть предусмотрены для напускания на всю мегамодель. Мегамодель aka "описание системы" тем самым -- "база знаний" по старинному определению: в ней лежат не только данные описания системы, но часть этих данных -- программы по их обработке. "Базой знаний" называли раньше базы данных, в которых хранились программы по обработке этих баз данных, каковые программы находились и вытаскивались языками запросов к базе.
Проблема, которую решает системная информатика, одна: в полноценном проекте нужно моделировать систему и при этом управлять конфигурацией и изменениями и данными. Для этого нужно сделать
-- systems framework/engine, который будет поддерживать множество разных view, для чего иметь какой-то протокол подключения разных viewpoints, репозиториев для них и механизмы exploration programming/modeling/querying плюс issue tracking, в том числе обеспечивая работу команды внутренних и внешних стейкхолдеров. Systems framework подразумевает и протокол подключения разной степени smartness и intelligence для viewpoints ("языков" -- программирования, моделирования, проектирования и т.д.) и общие механизмы smartness и intelligence для системного уровня (интеграции всех этих view и обеспечения индивидуальной и групповой работы), включая и "нейро" -- скажем, отслеживание cognitive load и помощь в управлении чиксентмихаевским потоком. У игровиков это "игровой движок".
-- мегамоделер, в который превращается systems framework путём начинки его необходимым набором плагинов, реализующих viewpoints и добавленную для этих viewpoints различную smartness и intelligence. Некоторые viewpoints могут подразумевать работу не с репозиториями данных, а с hardware (ибо речь может идти о симуляционных описаниях системы -- все эти hardware-in-the-loop). Мегамоделер настроен на описание какого-то класса систем, поддерживает необходимый для этого набор рабочих мест с предметно-ориентированными view и имеет репозиторий для хранения всех необходимых для проектов разработки этого класса систем данных. У игровиков это собственно игра, в том числе и её моды (разрабатываемые, вестимо, на движке).
-- прикладная система разработки для какой-то системы: мегамоделер, начинённый данными модели какой-то системы и содержащий необходимые для работы конфигурационные файлы для всех view и viewpoint, удобные для работы с данными моделей конкретной системы или их класса сниппеты кода, профили конкретных разработчиков и всё прочее, что отличает свежеразвёрнутый моделер от моделера, в котором уже год-два проектируется какое-нибудь нейроприложение, атомная станция или ГМО (life sciences ведь тут не исключение -- это ж "информатика", она для всех!). У игровиков это "сервера".
Конечно, таких архитектур будут тьмы, тьмы и тьмы. Впрочем, не "будут". Их уже огромное число: все эти "мультиязыковые редакторы" и "фреймворки приложений" уже есть. Так что нужно просто научиться
-- очень компактно об этом рассказывать, сравнивать такие системы между собой и находить их killer features
-- обсуждать пути их развития, обсуждать необходимо следующие из системного подхода функции, требуемые к реализации в рамках systems framework,
-- наоборот к предыдущему пункту: поскольку такие системы отражают практику, обогащать системный подход поддерживаемыми системными фреймворками не артикулированными явно новыми приёмами системного мышления, артикулировать эти приёмы мышления явно
-- обсуждать архитектуру таких систем и инструментарий для того, чтобы лучше их строить, быстрее развивать и с меньшими рисками эксплуатировать (systems framework engineering, можно ещё поглядеть, насколько это отлично от information systems engineering в классическом разделении software engineering, information systems, information technology, computer science -- см. типичные определения типа https://blog.soton.ac.uk/comp6044/2011/11/20/05-information-systems/ или разделения типа http://www.geteducated.com/careers/521-computer-information-systems-vs-computer-science или http://www.computersciencedegreehub.com/faq/difference-computer-science-degree-computer-information-systems-cis-degree/).
Это и есть системная информатика, interdisciplinary approach and means to enable the realization of successful information systems:
-- междисциплинарный -- то бишь с системным подходом в голове, множество viewpoints, оформляющие concerns самых разных stakeholders
-- обеспечение воплощения -- это инженерия, "от мысли к изменению мира, реализации"
-- информационные системы -- речь идёт о системах для описания систем
-- успешные -- системы для описания систем, удовлетворяющие нуждам множества стейкхолдеров.