Визуальное программирование *

В свете выхода нового продукта Apple, решил рассказать про небольшой исследовательский проект в сфере vr-кодинга.

Всем привет, продолжаю свою историю увлечения кулинарией и мобильной разработкой в MIT App Inventor (буду называть "аппинвентор" далее в статье) под это дело. Будет подробно расписана эволюция моего приложения и запредельные, не побоюсь этого слова, возможности аппинвентора, который некоторые считают "инструментом для детей". Кстати, сразу, пока не забыл - дети, если у вас есть интерес к программированию вообще и мобильной разработке под андроид в частности, то я очень рекомендую вам ознакомиться с аппинвентором. А фуллстак-разработчикам и UI/UX дизайнерам возможно будет интересны мои мысли, на основе которых происходила эволюция интерфейса приложения, потому что путь к итоговому результату был очень неблизкий и я бы дорого дал, чтобы сразу придумать то, что получилось в итоге, пропустив промежуточные шаги и сэкономив два года, но я не верю, что это реально в принципе. Зато теперь у меня есть вся эволюция в картинках, так что есть о чем на Хабре рассказать и показать, короче, будет "комикс" ))).

• При работе с WYSIWYG-решениями (напр., PowerPoint) требуется выполнять вручную массу монотонной работы, они не слишком хорошо поддерживают подсветку синтаксиса, не предоставляют качественных инструментов для точной отрисовки сложных фигур и анимации, а также их не так просто интегрировать с контролем исходников.
• Декларативные инструменты (напр., Beamer или reveal.js) гораздо лучше. В них серьёзно поддерживается подсветка синтаксиса, они позволяют рисовать сложные фигуры и анимацию (в особенности Beamer) и, кроме того, с лёгкостью версионируются. Правда, ни один из используемых с ними декларативных языков (ни LaTeX, ни HTML) не дают достаточной гибкости для создания по-настоящему сложных слайдов.

Последнее время из каждого утюга кричат по технологии будущего - что Chat GPT может писать код вместо программистов, а MidJourney создавать интерфейсы вместо дизайнеров. Мы полезли в Community фигмы, а там по запросу Figma to Code больше сотни плагинов, которые обещают сгенерировать чистый работающий код на основе ваших макетов и за пару кликов создать готовое web-приложение вместо ваших frontend-разработчиков. Все это звучит вдохновляюще, но так ли это на самом деле?

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

В последнее время набирают популярность low-code и no-code платформы. В них для разработки приложений предлагается использовать визуальное программирование. При таком подходе, разработчики, в качестве которых выступают обычные бизнес-пользователи, вместо написания программного кода создают приложение при помощи мыши в графическом интерфейсе. Также визуальное программирование в некотором виде используется, например, в Конфигураторе 1С.

Однако, возникает вопрос. Какие преимущества дает визуальное программирование по сравнению с Domain Specific Language ? Безусловно это зависит области применения. С одной стороны, в классических языках визуальное программирование практически не используется. В то же время при разработке графического интерфейса такой подход конечно же имеет много преимуществ. Однако, при создании интерфейсов, например, с помощью популярной библиотеки React все-таки больше используется плоский код.

Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.

В статье я разберу, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложу «лекарства», которые помогут вам нивелировать проблемы.

В конце статьи я составил чек-лист, по которому рекомендую проверять low-code платформу, прежде чем вы решитесь использовать её для решения своих бизнес-задач.

Статья состоит из шести разделов:

Наступают времена, когда офисному сотруднику недостаточно знать Word и Excel в качестве минимального обязательного базиса программных продуктов. No‑code/Low‑code платформы и продукты — вот что незаметно становится обязательным для владения каждым. Эти платформы есть самый быстрый на сегодня способ без изучения языков программирования овладеть навыками использования искусственного интеллекта, машинного обучения, анализа big data, причём очень бигдата — на сотни миллионов строк.

Платформа Knime — один из таких инструментов. На первый взгляд это улучшенный Excel+BI. Но, когда посмотришь поглубже его возможности, то, очевидно — это обязательный инструмент будущего, по крайней мере для тех кто не являясь программистом хочет получить навыки как у программиста. Для простоты — Knime это «графическое» программирование. Берёшь квадратики, размещаешь в виде бизнес‑процесса, соединяешь их между собой и оп! — уже провёл анализ маркетингового плана или парсинг сайтов конкурентов или анализ рекламных текстов с помощью NLP. Или, даже строишь приборную доску управления производственного предприятия будучи простым менеджером/инженером. Или ведёшь обработку научных данных.

Knime позволяет, конечно, и код писать, причём на трёх языках Python, Java, R, но это не обязательно. Бизнес‑процессы знаешь, рисуешь? Вперёд!

Разумеется, при работе с огромными массивами данных, требования к компьютерным ресурсам возрастают. И что делать, если вам доступен простенький офисный или домашний компьютер? Или, если вы видите что аренда облачного ресурса на месяц дороже, чем купить компьютер с 64Гб оперативной памяти и процессором гоняющим Atomic Heart или Hogwartz Legacy на среднемалках?

Продолжаем лекции по управлению в технических устройствах (УТС). Данные лекции читаются в МГУТ им. Баумана. Автор лекций к.т.н. Козлов Олег Степанович, кафедра Ядерные Энергетические Установки, факультета машиностроения. За что ему огромное спасибо!

1. Введение в теорию автоматического управления.2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13. 

3. ЧАСТОТНЫЕ ХАРАКТЕРИСТИКИ ЗВЕНЬЕВ И СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ РЕГУЛИРОВАНИЯ. 3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ. 3.2. Типовые звенья систем автоматического управления регулирования. Классификация типовых звеньев. Простейшие типовые звенья. 3.3. Апериодическое звено 1–го порядка инерционное звено. На примере входной камеры ядерного реактора. 3.4. Апериодическое звено 2-го порядка. 3.5. Колебательное звено. 3.6. Инерционно-дифференцирующее звено. 3.7. Форсирующее звено.  3.8. Инерционно-интегрирующее звено (интегрирующее звено с замедлением). 3.9. Изодромное звено (изодром). 3.10 Минимально-фазовые и не минимально-фазовые звенья. 3.11 Математическая модель кинетики нейтронов в «точечном» реакторе «нулевой» мощности. 

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

5. Передаточные функции и уравнения динамики замкнутых систем автоматического регулирования (САР).

6. Устойчивость систем автоматического регулирования. 6.1 Понятие об устойчивости САР. Теорема Ляпунова. 6.2 Необходимые условия устойчивости линейных и линеаризованных САР. 6.3 Алгебраический критерий устойчивости Гурвица.

Привет, Хабр! Меня зовут Георгий Ржавин, работаю процессным архитектором в компании GlowByte, руковожу направлением Business Process Management. В этой статье хотел бы с вами подискутировать о вечном противостоянии подходов High Code и Low Code: где сейчас находимся и кто выигрывает. Но перед тем, как мы перейдем к основной дискуссии, сразу оговорюсь, что текущее сражение я буду рассматривать применительно к сфере автоматизации процессов, в которой сам работаю и в вопросах которой немного разбираюсь.

Сейчас в IT-сфере набирают популярность так называемые low-code и no-code системы. Разработчики таких систем твердят, что с помощью их продуктов бизнес может создавать прикладное ПО без профессиональных разработчиков. Еще и весь интернет набит статьями, которые преподносят low-code и no-code как что-то кардинально новое и очень крутое для людей, которые не умеют программировать. Так ли это на самом деле?

Привет, Habr! Сегодня я хочу поделиться опытом разработки системы контроля доступа (Access Control System, ACS) для low-code платформы Системный Геном. Задача была непростой: нужно было создать гибкую систему, которая поддерживает иерархии, автоматическую синхронизацию с приложениями и строгий контроль доступа, но при этом остаётся понятной для администраторов и быстрой в работе. В этой статье я расскажу, как мы справились с этой задачей, какие ошибки допустили на старте и как в итоге пришли к решению, которое теперь успешно работает в продакшене.

Добрый день. Меня зовут Иван, я дата‑инженер, основной профиль — доставка данных от источников до целевых систем DWH. Чаще всего работаю с Apache NIFI.

В данной статье я расскажу о вариантах старта PipeLine обработки данных в требуемое время. Статья подойдет новичкам, опытные коллеги могут дополнить в комментариях.

Здравствуй, Хабр!

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

Привет, Хабр! Меня зовут Георгий Ржавин, работаю процессным архитектором в компании GlowByte, руковожу направлением Business Process Management. В этой статье хотел бы поделиться моим видением мирового рынка ПО (в первую очередь доступного в России) по моделированию и автоматизации процессов, а также рассказать о новых инструментах. Прежде всего материал будет интересен для бизнес‑ и процессных аналитиков.

В контексте автоматного программирования ВКПа опять вспомним про SimInTech. Представляется удобным и наглядным создать аналог проекта из в SimInTech, который основан на базе элементов ее библиотеки «Конечные автоматы». Так мы осваиваем проектирование в рамках данных сред и заодно проведем сравнение технологий автоматного программирования. Ну, а за основу для достижения поставленных целей возьмем проект «Нагреватель» из SimInTech.  

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

Графы на рис. 1 представляют собой модель автоматной программы в ВКПа. И уже на уровне модели видны основные отличия. Кратко или, так сказать, в первом приближении они сводятся к следующему. На уровне отдельного процесса (автомата) мы сразу разделяем программу на части. Это операторы, названные предикатами и действиями, и управление программы – собственно модель конечного автомата (КА). А на уровне самой программы в общем случае это сеть из автоматов. В соответствии с данным ранее определением все это вместе и составляет автоматную программу.

В статье описан теоретический метод, позволяющий прояснить математические истоки алгоритмической макроконструкции силуэт.

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

Здравствуй, уважаемый Хабр!

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

Продолжим. Наша текущая цель - на примере  аттракторов достичь равенства результатов в SimInTech  и ВКПа.  Делать мы это будем приведением моделей к наиболее универсальной базе - используя языки программирования (ЯП). В ВКПа уже есть реализация на С++. Осталось создать ее в SimInTech. В таком виде они будут соответствовать друг другу. А в идеале, если языки одинаковые, даже просто совпасть. Все это должно способствовать равенству результатов. И на этом пути, кроме освоения внутреннего языка программирования SimInTech,   особых препятствий не предвидится.

Блоки на внутреннем ЯП в SimInTech создаются на базе блока PL  - блок библиотеки Динамические. Напомним реализацию модели аттрактора Лоренца на стандартных библиотечных блоках. Она приведена на рис. 1. Далее мы ее будем называть исходной схемой. Часть ее вместе с соответствующим кодом на языке программирования SimInTech (LangBlock22) представлена на рис. 2.

Здравствуйте, позвольте рассказать вам про сервис falang.io - редактор блок схем.

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