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

"Зацепила" крайняя статья про многопоточность [1]. Но, с другой стороны, - а что ожидал автор, предложив исходное решение без синхронизации? Получил то, что и должен был получить. На другое рассчитывать было бы достаточно наивно. Во-первых, потому, что используется весьма  проблемная модель параллелизма. Во-вторых, расплывчатое представление о решаемой проблеме (по крайней мере, если судить по описанию). Но это уже мое личное мнение и хотелось бы его пояснить. И не просто так, а подкрепив решением.

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

Но, может, автор достиг чего-то нового? Да, вроде, нет. То, что нужно синхронизировать - не новость. Нов ли предложенный механизм синхронизации? Не знаю, поскольку не специалист в  Python. Надеюсь такие найдутся и ответят на этот вопрос.

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

Но для начала...

Краткая история вопроса

Использование переменной-счетчика в качестве общего ресурса - отнюдь не новость. Это элементарный и естественный подход к демонстрации проблем множества параллельных процессов. Насколько я припоминаю, впервые с подобным примером в серьезной литературе я столкнулся в книге [2].Предлагаемые там решения не вызвали восторга, а потому были задвинуты. И, кстати, об этом я не испытываю сожаления.

Привет, Хабр! Меня зовут Анастасия Андреева, работаю процессным аналитиком направления Business Process Management в компании GlowByte. Не так давно мой коллега рассказывал о Heflo – универсальной системе бизнес-моделирования. В рамках деятельности Heflo Club мы в GlowByte создаем обучающий контент для бизнес- и процессных аналитиков, а также для всех, кто желает познакомиться с миром BPM и освоить новую систему управления бизнес-процессами Heflo.

“Построить бизнес-процесс легко” – пестрят заголовки статей “самоназванных” гуру BPM, но так ли это на самом деле? Сегодня мы поговорим о том, как моделировать бизнес-процессы и как осуществляется их автоматизация на платформе Heflo. Это Low-code-система, преимуществом которой является практически отсутствие написания кода, что позволяет просто и быстро создавать с помощью нее цифровые решения для различных процессов компании. 

На сегодняшний день существует несколько популярных подходов к созданию ПО, которые определяют как работу вендоров, так и развитие ИТ-индустрии в целом. Первый — классическая разработка, которая предполагает работу с нуля над определенным программным продуктом для конкретного заказчика. Второй — low-code платформы и их производные, в основе которых лежит принцип ухода от парадигмы «ручного труда» за счет оптимизации бизнес-процессов на уровне платформы. 

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

Между тем, до конца разобраться в специфике low-code до сих пор не получается не только у клиентов, но даже у ИТ-специалистов. Например, часть профессионального сообщества опасается, что развитие low-code приведет к отказу от дорогой high-code разработки. В свою очередь клиенты, которые привыкли к high-code, воспринимают low-code продукты как инструмент для создания эскиза информационной системы. Рассмотрим особенности разных подходов к разработке ПО и критерии, по которым их выбирают вендоры и заказчики.

Моделирование планетарного ускорения, солнечной системы и взаимодействия любого количества объектов на космической карте в замкнутой системе!

Создались условия, чтобы подвести некий итог. Дело в том, что автоматы в SimInTech  могут быть инерционными. И это определенно знаменательный факт. Более того, он даже радует своей неожиданностью, опровергая то фактическое неверие, которое к среде было до этого. Но давайте подробнее о том, как это все таки случилось...

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

Программисты, как правило, кушают то блюдо, которое им подают. Будь это язык программирования, библиотека, фреймворк или IDE. Однако, это еще полбеды. Удивляет нежелание выбирать. Хотя это тоже можно объяснить. Выбор‑то, может, и есть, сколько новых языков появилось за последнее время, но только разницы между ними особой нет. В результате, попробовав раз, попробовав два, мы устаем и останавливаемся на чем‑то одном, т. е. пресыщаемся...

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

Однако в последнее время появилось множество не совсем точной, а часто и мифологической, информации о платформе. Это способствует завышенным ожиданиям у новичков. Такие мифы продуцируются как разработчиками no‑code, так и всевозможными курсами по обучению. И носят скорее рекламный характер, чем реальные характеристики инструментов.

Прежде чем анализировать мифы рассмотрим цикл разработки приложений на коде. 1) разработка UX дизайна (40 часов), 2) разработка UI дизайна (40 часов), 3) программирование бэкенда (120 часов), 4) программирование приложения для андроида (100 часов), 5) программирование приложения для iOs (100 часов), 6) тестирование (40 часов). Здесь трудоемкость каждого вида работ дана в часах для несложного приложения в 10 — 15 экранов. Естественно при увеличении количества экранов пропорционально будет увеличиваться и трудоемкость. Здесь мы не учитываем работу PM (прожект менеджера).

Эти цифры средние по нескольким украинским аутсорсинговым IT компаниям. Порядок выполнения работ параллельно‑последовательный: последовательно выполняются UX дизайн, UI дизайн, программирование (все три типа параллельно с некоторым опережением бэкенда), тестирование. Таким образом, общая трудоемкость составляет 440 часов, а продолжительность разработки составляет 240 часов.

Сразу отметим, что здесь не рассматриваются конструкторы основанные на шаблонах типа AppsGeyser. Они создают приложение за три шага: 1) Выбрать шаблон из 30 — 50 возможных (несколько кликов); 2) Добавить контент, например, логотип приложения, название, текст и ссылки, чтобы настроить ваше мобильное приложение (порядка 10 минут); 3) Загрузить приложение в Google Play Store. Здесь действительно практически не нужны знания, получается нативное приложение. К сожалению количество шаблонов десятки, а приложений нужно разрабатывать миллионы.

Конечные автоматы и соответственно автоматное программирование (АП) интересны в первую очередь параллелизмом и эффективностью его реализации. Причем параллелизм у КА присутствует уже на уровне компонентного КА, но несомненно важнее параллелизм сетей автоматов. На примере простого алгоритма НОД было показано, как можно легко превратить любой алгоритм в процесс, а затем из них создать более сложную схему. «Сетевая конструкция» позволяет эффективно представлять параллельные процессы и создает понятную, простую и теоретически обоснованную теорию параллельных вычислений (см. подробнее [3]).

Модель отдельного КА определяет точки и механизмы взаимодействия (здесь вспоминаем про состояния) между параллельными процессами. Состояния автомата фиксируют моменты программного и/или аппаратного прерывания/приостановки/взаимодействия процессов (см. автоматный код НОД в статье). И не важно идет ли речь идет об имитации параллелизма в рамках одного потока или это будет множество потоков или даже ядер, т. е. того, что в иной подаче звучит как in parallel и concurrently. И здесь уже надо говорить об едином времени подобно единому времени реальных процессов. Соответственно, уточняя при этом, что на формальном уровне речь идет о сетевой автоматной модели с единым дискретным временем. При этом допускается, что разные сети вправе иметь индивидуальное дискретное время.

Дискретное время — важнейший элемент автоматной модели. Оно, как и состояния, зашито в определении модели. И уже только состояния и дискретное время выделяют автоматы на фоне других моделей. Дискретное время играет важнейшую роль в формировании качественно иной, например, по отношению к той же многопоточности или многоядерности, модели и теории параллельных вычислений. Важно также понимать, что любые асинхронные сети такой теории не имеют. Можно даже утверждать, что теория параллелизма на базе КА не была бы возможна без дискретного времени и, конечно, состояний. И актуальны они именно в своей «связке».

Меня зовут Андрей Цыган - я не программист, я смотрю на технологии ИИ с точки зрения человека, кто знает что хочет, но не имеет навыков это сделать через код.

Я протестировал новый плагин Code Interpreter на реальных задачах в бизнесе и остался приятно удивлён.

На рис. 1 приведена блок-схема алгоритма нахождения наибольшего общего делителя двух натуральных чисел из книги Н. Вирта[1]. С таких алгоритмов, да и с подобных книг,  начинается или должно начинаться знакомство с программированием. И, кстати, книга Н.Вирта была одной из первых, с которой в свое время познакомился и я. Так что здесь присутствует и некий личный мотив.

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

Александр Пряхин, руководитель разработки юнита в Авито Работа, рассказал, так ли мрачно выглядит будущее для разработчиков «из плоти и крови» на фоне активного развития No Code, Low Code и нейросетей.

В свете выхода нового продукта 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 платформу, прежде чем вы решитесь использовать её для решения своих бизнес-задач.

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