Search
Write a publication
Pull to refresh
8
0
Алексей @UltimaSol

Разработчик

Send message
Ответить на вопрос можно только сравнив приложения, написанные во всех этих решениях.
Не «Hello, world!» и «table1 — table2», а что-то используемое людьми. За деньги.
Давайте попробуем разобрать на примере. Часто встречается: пользователю нужны 2 жалких журнала: приходы и продажи. И сумма в кассе. (Онлайн-касса маячит на горизонте, но пока мало кто чешется)

Дистрибутив 1С для этой несложной задачи (Торговля и склад) весит 180МБ, потребует компьютер и настройки под себя руками специалиста. В результате, гипотетически, будет решен любой набор задач, если знаешь когда какую кнопку нажимать (а их в меню больше сотни). Практически же люди так и сидят с бумажками. Сложно им.

Простейший аналог в Интеграле не потребует ничего, кроме планшета или мобилы.
Выгрузка конфигурации — схема данных, отчеты, справочники — занимает меньше 15 КБ (так, к слову). Само программирование заготовки этого кустарного аналога заняло около 5 дней, и он точь-в-точь может воплотить требования среднего пользователя еще за 4-8 часов.
За 40 минут (мы пробовали) можно сделать импорт номенклатуры откуда угодно.
… а если можно — то как?

Интерактив клиентской части делается вне Интеграла (как хотите), а его шаблоны подгружаются в сервис.

Там написано в первом же абзаце, для чего этот сервис:

Я расскажу о технологической платформе, пригодной для создания информационного ядра системы или приложения. Платформа содержит простой высокоуровневый конструктор модели данных и базовый интерфейс для работы с ней, поддерживает ролевую модель доступа, эмулятор запросов SQL (CRUD), API, а также дает возможность загружать произвольные рабочие места — элементы UI — и наполнять их данными.
Вы перечислили не проблемы, а задачи. Git вам нравится? Так и грузите всё в Git, никто не мешает.

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

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

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

Про UI не совсем понятно, о чем. Вот так выглядит построение простых отчетов в приложении, без кода, но в некоторых случаях с применением арифметических формул:
www.youtube.com/watch?v=F_w5KvfmqzA&feature=youtu.be&t=210

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

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

Мы хотим попробовать, имеем право, стараемся. И будь что будет.
В принципе, здесь всё как в обычном приложении, только вместо циклов и ветвлений используются запросы и условия.

Нотификацию можно сделать множеством способов, например:
а) выбирать из базы и отображать в интерфейсе (форме с меню) напоминания о подошедшем сроке запланированных событий
б) отправлять email или СМС в момент наступления события для побуждения к дальнейшим действиям (менеджеру об оплате заказа)
в) запустить планировщик, выбирающий и отправляющий напоминалки или вызывающий сторонний сервис раз в 1-2-5 минут

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

Посмотреть как это сделано
Пример для отправки СМС и показа текущих активностей

Пульт, перезагружающийся раз в 45 секунд:



HTML-код пульта:



Отчет intSmsPult, использующийся в пульте:



Колонки отчета (Поля запроса, их можно назвать в Редакторе типов как угодно):



Присвоение пустого значения, отмеченное красным кругом, сбрасывает флажок запланированного события, чтобы СМС отправлялось 1 раз.

Напоминалки в пользовательском интерфейсе

Действия, срок совершения которых наступил, будут отображаться на форме (отмечено красным):



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



Для интеграции обычно берется код, предоставленный поставщиком сервиса. Поставщик потом вызывает указанный ему URL и отчитывается о проделанной работе. Тут вообще проблем нет. Вот, например, как это выглядит при эмуляции мобилы в браузере: youtube
(вызывается форма оплаты Сбербанка в середине третьей минуты ролика)
Это не «лучше» или «хуже», это «другое».
Ответ также сильно зависит от целевой аудитории. Для пользователей Access и FoxPro здесь легче начать работать.
В сравнении с Axapta и 1С для несложных задач заметно легче будет само решение. Для сложных задач — будет значительно дешевле менее трудоемко.
В идеальном мире — да, логарифмическая. В Интеграле тоже логарифмическая.
Однако, с ростом сложности и объема системы в какой-то момент начинаются проблемы, и часто даже случается коллапс. Для привязки к конкретной метрике мы и говорим «не хуже линейной», имея в виду, что линия не будет пересечена.

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

Ядро его достаточно компактно, это всего один скрипт, начинали его писать давно, а сейчас его почти не трогаем, поэтому обходимся без фреймворка.
Еще есть экспорт и импорт структуры и данных. То есть, можно набросать модель, выгрузить её и загрузить в другой экземпляр базы.
Это не EAV, хоть и похоже местами, не спорю.
А начали мы как раз с того, что решили проблему производительности: деградация её с ростом объема и сложности должна быть не хуже линейной.
Нет языка.
Интерфейс свёрстан в HTML (css, js для оформления), программирование делается запросами Интеграла.
Или предполагается, что персонал будет мониторить события и вызывать нужные пункты меню сам, согласно должностным инструкциям, а система в лучше случае не даст совершить действия, которые в данный момент неуместны?


Я помогаю сейчас знакомому рекрутеру делать стартап для массового подбора персонала.
Там есть приличный бизнес-процесс, включающий переходы откликов кандидатов по статусам, планирование интервью, рассылку email и смс, работу с вакансиями (набор этапов, трёхуровневые специализации, скрипты, тайм-слоты встреч, права, и т.д. и т.п.) и сайтом Хэдхантер (HH). Фрейм HH написан отдельно, используется как сторонний сервис, внедренный в интерфейс, остальное — в Интеграле. Так вот, есть формы вакансии, отклика и прочие, состоящие из блоков, которые включаются/выключаются и совершают действия (вызывают запросы, запрашивают и сохраняют данные) в зависимости от статуса отклика или иного контекста. Приложение «ведет» пользователя, ограничивает, не дает спотыкаться.
Могу показать как это работает по скайпу, со всеми запросами, исходниками и формами. В целом, всё как в обычном приложении, но без python, php, nodejs.

Построителя workflow из кубиков пока нет. Пока нет.
Приведите пример «запроса», реализующего описанную выше функциональность:

  • по нажатию кнопки «выставить счет»
  • проверить n условий (валидность заказа)
  • слазить во внешний сервис за налогами
  • создать счет с учетом налогов и дисконтов и сформировать в нем строки
  • сгенерировать ссылку на оплату
  • отправить ссылку на email клиента


Если вы внимательно читали статью, то видели там про возможности:
  • проверки условий против данных всех доступных таблиц (проверить n условий);
  • делать внешние запросы (слазить во внешний сервис, отправить email);
  • делать вложенные запросы, которыми в том числе можно создавать записи (создать счет с учетом налогов и дисконтов и сформировать в нем строки);
  • и, разумеется, делать вычисления (сгенерировать ссылку на оплату).


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

Как я оговариваюсь в статье (пару раз), пока сервис не предлагает наработок по визуализации всего этого, а предоставляет чистое поле, как если бы вы взяли Python, PostgreSQL и Apache, но упрощает работу с базой данных и разворачивание самой среды.

Пользовательский код реализуется Запросами, которые могут многое, в том числе запускать другие запросы по заданным событиям (смены статуса А на Б). Запросы можно запускать кучей способов, в том числе из интерфейса пользователя, собранного согласно процессу и параметрам, описанным в базе данных.
12 ...
9

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity