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

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

Очень много вопросов задают по поводу того, как правильно «прошить» ESP-модуль прошивкой ShIoTiny5 и как его настроить.Это не удивительно, так как параметров конфигурации немало. Да и разных ESP-модулей — тоже.

Действительно, есть уже несколько статей по программированию устройств ShIoTiny5, но нет ни одной, где описаны способы установки ПО - программного обеспечения - ShIotiny5 на ESP-модуль и по его системным настройкам.

Также есть вопросы по поводу того, почему система ShIoTiny5 такая какая есть, а не «вот такая», какая она рисуется в фантазиях некоторых читателей.

Попробую ответить на эти вопросы.

В этой статье нет ничего о программировании ShIotiny5.
Она целиком посвящена прошивке программного обеспечения и его конфигурации. И немного - концепциям и идеям.

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

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

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

Что такое SAP Data Services

Это графический ETL инструмент для обеспечения качественной обработки данных и их интеграции в единое хранилище. Используя Data Services (в дальнейшем DS), можно преобразовывать и очищать данные, независимо от их источника. Имеется гибкая возможность интегрироваться с любым источником. Возможно иметь единую среду для разработки, выполнения, управления и проверки безопасности.

Одной из главных функций Data Services является извлечение, преобразование и загрузка (ETL) данных из разнородных источников в целевую базу данных или хранилище данных. При помощи инструмента Designer создаются приложения (задания), которые определяют порядок преобразования и обработки данных. DS самостоятельно отслеживает время и параметры запуск заданий, собирается статистику и пробует оптимизировать работу задач. Рабочий сервер DS может выдерживать большой объем данных и поддерживать обработку данных в реальном времени.

Почитав несколько историй о том как программисты передают данные с микроконтроллеров на ПК, с целью их удобного отображения на большом экране (SCADA, LabView), пришло мне в голову рассказать еще об одном способе для этого. Способ не новый, но, похоже, не очень известный. Способ заключается в применении программы Atmel Data Visualizer или ее последователя - MPLAB Data Visualizer.

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

Несколько лет назад я писал о системе визуального программирования ShIoTiny для модулей на базе микроконтроллера ESP8266. Поэтому, чтобы не повторяться, для тех, кто "не в теме" - сразу отсылаю к моей первой статье на Хабре: ShIoTiny: малая автоматизация, интернет вещей или «за полгода до отпуска».

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

Второй базовый принцип - максимальное использование визуального представления алгоритмов в виде узлов и из связей.

Здесь я расскажу о том, что произошло в плане разработки системы ShIoTiny с момента последней публикации на Хабре о ней.

"Зацепила" крайняя статья про многопоточность [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 и нейросетей.