Опять поднимают про low-code и помоечку для средняков...
От: Shmj Ниоткуда  
Дата: 16.09.21 12:07
Оценка: -2
https://habr.com/ru/post/578280/

  Скрытый текст
https://www.youtube.com/watch?v=X7kxnC9v25A


Ваше мнение?
Re: Опять поднимают про low-code и помоечку для средняков...
От: Shtole  
Дата: 16.09.21 16:36
Оценка: +7
Здравствуйте, Shmj, Вы писали:

S>https://habr.com/ru/post/578280/


S>Ваше мнение?


Тоже читал сегодня. Как раз хотел обсудить. По-моему:

а) Тренд явно имеет место. Никто уже не хочет в стопицотый раз заказывать разработку, спрос на no-code платформы налицо.

б) По ссылке люди как-то... излишне прямолинейно (скажем вежливо) подходят к вопросу. Типа, а вот возьмём инструменты для разрабов, упростим их для предела, насыплем побольше визивига и диаграмм, и из инструментов для разработчиков вылепим инструменты для юзеров. Нет. Таким макаром можно разве что из хороших инструментов для разработчика получить плохие инструменты для разработчика. Как бы сравнить, чтоб понятно было... ну, типа, как в старину люди пытались автоматизировать шитьё, изготавливая андроидов / роборуку с иглой. Но ни у кого ничего не вышло, а вышло у тех, кто сконструировал швейную машину. Так и тут. Они упёрлись в идею алгоритма и пытаются дать возможность его записать какими-то P-схемами. Попутно критикуя традиционные схемы (они, мол, уступают ЯП). Но ровно то же самое можно сказать и про сами P-схемы: ЯП тупо лучше для записи алгоритмов. Тут нужен совершенно другой подход. Как говорят ТРИЗовцы: идеально, когда объекта нет, а выполняемая работа есть. Не надо грузить пользователя алгоритмами. Алгоритмы неявно должны выполняться. Допустим, юзер формулу записывает в Экселе — он разве думает, что там какой-то алгоритм под капотом? Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас. Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига». Вот они-то эту нишу — no-code/low-code — и займут.
Do you want to develop an app?
Re: Опять поднимают про low-code и помоечку для средняков...
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 16.09.21 17:07
Оценка: :)
Здравствуйте, Shmj, Вы писали:

S>Ваше мнение?


Статья ужасна, читай Вастрика
https://elibrary.ru/author_counter.aspx?id=875549
Re: Опять поднимают про low-code и помоечку для средняков...
От: vsb Казахстан  
Дата: 16.09.21 17:51
Оценка:
Моё мнение, что подход имеет место быть.

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

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

А вообще, думаю, принципиально ничего не мешает low code подходу применяться и в более сложных проектах. Просто нужна грамотная архитектура и реализация.
Re: Опять поднимают про low-code и помоечку для средняков...
От: landerhigh Пират http://www.blinnov.com
Дата: 16.09.21 18:52
Оценка: +8
Здравствуйте, Shmj, Вы писали:

S>Ваше мнение?


В 100500 раз — попытка натянуть неправильное решение на несуществующую проблему.
Самый лучший способ противодействия дуракам — предоставить им возможность самим отстрелить себе ногу.

P.S. Вот и выросло поколение, которое не застало Rational Rose
www.blinnov.com
Re[2]: Опять поднимают про low-code и помоечку для средняков...
От: 4058  
Дата: 17.09.21 05:30
Оценка: +2
Здравствуйте, landerhigh, Вы писали:

L>P.S. Вот и выросло поколение, которое не застало Rational Rose


Ну вот застал, приблизительно на стыке веков, помню на основе UML это чудо на выходе генерило (для популярных языков) классы и "пустые" методы, которые потом надо было естественно реализовывать. Помогала эта хрень только т.н. архитекторам, чтобы самим поменьше диаграмок рисовать для всякой отчетности. Естественно долго это безобразие просуществовать не могло, в той конторе, буквально и полугода не продержалось.
Контора кстати жива, и у них из всего пакета Rational, до сих пор используется ClearCase (система управления версиями).

А тут говорят, про программирование без кода (привет Дракону). Нет, рябата так дело не пойдет, сухим из воды не выйдешь.
Re: Опять поднимают про low-code и помоечку для средняков...
От: Михaил  
Дата: 17.09.21 06:07
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Ваше мнение?


А чем код плох, если вкратце?
Re[2]: Опять поднимают про low-code и помоечку для средняков
От: vdimas Россия  
Дата: 17.09.21 06:43
Оценка:
Здравствуйте, Shtole, Вы писали:

S>Таким макаром можно разве что из хороших инструментов для разработчика получить плохие инструменты для разработчика.


Но хорошие для продвинутого юзера, каким стал конструктор 1С.
Программисты должны пилить кубики для таких конструкторов.


S>ЯП тупо лучше для записи алгоритмов.


Это если приходится сражаться тупо с шириной бит типов данных, лейаутом данных в памяти и прочей низкоуровневостью.
Если нет — то любой ЯП будет хуже обычного какого-нить графического симулятора, типа Simulink, графического редактора шейдеров и т.д.


S>Тут нужен совершенно другой подход.


Ничего другого, кроме автоматизации рутины, человек пока не придумал для повышения производительности своего труда.


S>Как говорят ТРИЗовцы: идеально, когда объекта нет, а выполняемая работа есть.


В инженерии базовые объекты должны быть готовы, внесены в номенклатуру, уметь легко стыковаться м/у собой.


S>Не надо грузить пользователя алгоритмами.


Ему их можно выдать готовыми. Пользователь пусть ползунки настроек крутит.


S>юзер формулу записывает в Экселе — он разве думает, что там какой-то алгоритм под капотом?


Формула — это уже алгоритм.


S>Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас.


Нормальный UI.
У текстового процессора лист бумаги, у электронной таблицы, неожиданно, таблица.


S>Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига».


Заблуждения...
Взять обычный MS Word 2013, как-то за примерно 40 минут накидал на ём всю графику на этой картинке:
http://files.rsdn.org/21096/MusicFX.png
Просто бросаешь примитивы, крутишь им рукоятки, "фотографируешь" экран, следующий.
(кнопки щелкаются, рукоятки крутятся)

Современные игровые движки взять — тоже сплошные готовые "кубики".

А взять какой-нить Архикад, где параметрические BIM-объекты можно описывать без программирования (еще лет 5 назад я немного упражнялся в программировании на GDL-языке), теперь это в прошлом. На приемлимом уровне первым это сделал Grasshopper, пощёлкай по видео ниже, посмотри на процесс "программирования" непрограммистами:
https://www.youtube.com/watch?v=uf0QhN1bZ2o
Это именно программирование, описание алгоритма.

Аналогичные системы есть не только для графики, есть для цифровой обработки звуков, а оно потенциально обобщается до цифровой обработки любых сигналов и т.д.
Отредактировано 17.09.2021 6:45 vdimas . Предыдущая версия . Еще …
Отредактировано 17.09.2021 6:45 vdimas . Предыдущая версия .
Отредактировано 17.09.2021 6:44 vdimas . Предыдущая версия .
Re[2]: Опять поднимают про low-code и помоечку для средняков
От: vsb Казахстан  
Дата: 17.09.21 06:57
Оценка:
Здравствуйте, Михaил, Вы писали:

S>>Ваше мнение?


М>А чем код плох, если вкратце?


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

Т.е. к примеру ты создаёшь задачу по расписанию, запускать каждые 5 минут. Заходишь в эту задачу, создаёшь там действие "сделать поиск на авито по заданным параметрам". Создаёшь алгоритм для обработки результатов этого поиска: для каждого найденного объявления проверить, находилось ли оно ранее. Если не находилось, добавить в список найденных ранее и отправить SMS на такой-то номер. Всё, парсер авито для конкретной задачи готов. Делается за час. А каждый конкретный блок это уже условно сложная задача, но их можно переиспользовать, например купить в местном магазине. Каждый шаг делается через GUI, везде будут подсказки, не нужно читать никакой документации, весь алгоритм виден, как блок-схема.

Через код это можно сделать на каком-нибудь пайтоне, если каждый блок уже написан в виде библиотеки, но всё равно для этого нужно знать пайтон. Так получается, что людей, которые не знают пайтон, но могут разобраться в адекватном GUI-интерфейсе, значительно больше, чем людей, которые знают пайтон. Т.е. стоит их труд значительно дешевле.
Отредактировано 17.09.2021 6:57 vsb . Предыдущая версия .
Re[3]: Опять поднимают про low-code и помоечку для средняков
От: Shtole  
Дата: 17.09.21 07:03
Оценка:
Здравствуйте, vdimas, Вы писали:

S>>Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига».


V>Заблуждения...

V>Взять обычный MS Word 2013, как-то за примерно 40 минут накидал на ём всю графику на этой картинке:
V>http://files.rsdn.org/21096/MusicFX.png
V>Просто бросаешь примитивы, крутишь им рукоятки, "фотографируешь" экран, следующий.
V>(кнопки щелкаются, рукоятки крутятся)

Потрясающие mad skillz. Только вот какое отношение это имеет к no-code/low-code?

Давайте я приведу пример того, чем занимаюсь я.

Представьте себе таблицу. Но не таблицу «Тебе, дебилушка!», как в Excel. Во-первых, её колонки типизированы, а во-вторых имеют имена. О да, это требует указать типы (число, строка, дата, флаг, ссылка) и немыслимо напрячься, вбивая имена колонок. Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа. Простой бухгалтер может из такого инструмента сделать «2B:Платёжные документы», с любыми печатными образцами, не написав ни одной строчки кода и не задумываясь ни об одном алгоритме. И P-схемы ему не нужны. И редактор форм. Причём, с моей стороны я вообще не знаю ни о геометрии документа для печати, ни о прикладном смысле строк и таблиц.
Do you want to develop an app?
Re[3]: Опять поднимают про low-code и помоечку для средняков...
От: landerhigh Пират http://www.blinnov.com
Дата: 17.09.21 07:07
Оценка: +4
Здравствуйте, 4058, Вы писали:

4>Ну вот застал, приблизительно на стыке веков, помню на основе UML это чудо на выходе генерило (для популярных языков) классы и "пустые" методы, которые потом надо было естественно реализовывать. Помогала эта хрень только т.н. архитекторам, чтобы самим поменьше диаграмок рисовать для всякой отчетности. Естественно долго это безобразие просуществовать не могло, в той конторе, буквально и полугода не продержалось.


Ну так подавалось это все под соусом "дорогие программисты не нужны, посадил секретутку накидывать квадратиков, нанял студента за обеды, чтобы их заполнить, и в продакшен". Но что-то пошло не так (c)

4>Контора кстати жива, и у них из всего пакета Rational, до сих пор используется ClearCase (система управления версиями).


Мое имхо — оно существует исключительно для откатов.
www.blinnov.com
Re[4]: Опять поднимают про low-code и помоечку для средняков...
От: 4058  
Дата: 17.09.21 08:02
Оценка: 1 (1)
Здравствуйте, landerhigh, Вы писали:

L>Ну так подавалось это все под соусом "дорогие программисты не нужны, посадил секретутку накидывать квадратиков, нанял студента за обеды, чтобы их заполнить, и в продакшен". Но что-то пошло не так (c)


Еще там был отдельный фетиш, это распечатывать большие (и абсолютно бесполезные) диаграммы на листах формата A1, обвешивать ими полу-стеклянные комнаты, и вот вся эта бригада паразитов в виде аналитиков/архитекторов с натужными попытками создать умный вид периодически позировала перед ними. Жаль тогда фотоаппаратов не было в каждом телефоне.
Кстати место происшествия — Москва 2001/2-й год.
И конечно там был Document-ум, без него ведь, подобные мероприятия не обходятся … Тоже хотели, без приличных знаний в области БД, чтобы по визуальным описаниям дальше как-то “всё само”.

4>>Контора кстати жива, и у них из всего пакета Rational, до сих пор используется ClearCase (система управления версиями).


L>Мое имхо — оно существует исключительно для откатов.


В общем-то да, плюс создание видимости какой-то активности, а то руководство не понимает чего там делают программисты, а тут хоть заумными диаграммами можно пол здания обвешать при этом не написав ни строчки кода.
Ну а что касается ClearCase, то это единственный внятный продукт (по очевидным причинам), ибо банальная СУВ и почти ничего лишнего.
Re: Опять поднимают про low-code и помоечку для средняков...
От: Muxa  
Дата: 17.09.21 10:10
Оценка: +7 :))
S>Ваше мнение?

Нам добавится работы.
Re[4]: Опять поднимают про low-code и помоечку для средняков
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 17.09.21 11:54
Оценка: +1
Здравствуйте, Shtole, Вы писали:

S>Представьте себе таблицу. Но не таблицу «Тебе, дебилушка!», как в Excel. Во-первых, её колонки типизированы, а во-вторых имеют имена. О да, это требует указать типы (число, строка, дата, флаг, ссылка) и немыслимо напрячься, вбивая имена колонок. Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа. Простой бухгалтер может из такого инструмента сделать «2B:Платёжные документы», с любыми печатными образцами, не написав ни одной строчки кода и не задумываясь ни об одном алгоритме. И P-схемы ему не нужны. И редактор форм. Причём, с моей стороны я вообще не знаю ни о геометрии документа для печати, ни о прикладном смысле строк и таблиц.

Это случайно не MS Access?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[4]: Опять поднимают про low-code и помоечку для средняков
От: vdimas Россия  
Дата: 17.09.21 13:53
Оценка:
Здравствуйте, Shtole, Вы писали:

S>Потрясающие mad skillz. Только вот какое отношение это имеет к no-code/low-code?


Потому что MS Word ты можешь потрогать ручками и представить, как примерно сейчас разрабатывают алгоритмы обработки сигналов или как алгоритмически порождают графические (в т.ч. строительные) объекты нетривиальной конструкции.

А пробовал шейдеры визуально проектировать?
Оно примерно так же (можно в блендере попробовать).
Т.е., вполне себе алгоритм, составленный из неких базовых "кубиков".

"Настоящие программисты" в этом деле разрабатывают сами кубики и способы управления ими из САПР.


S>Давайте я приведу пример того, чем занимаюсь я.

S>Представьте себе таблицу. Но не таблицу «Тебе, дебилушка!», как в Excel. Во-первых, её колонки типизированы, а во-вторых имеют имена. О да, это требует указать типы (число, строка, дата, флаг, ссылка) и немыслимо напрячься, вбивая имена колонок.

Да понятно, но в БД тоже имена, типы...
А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
Многие такие менеджеры еще позволяют графически конструировать запросы.


S>Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа.


А современные конструкторы сайтов смотрел?

А в том же MS Access можно и таблицы, и формы, и отчёты, и соотв. запросы, и вложенные сколь-угодно master-child представления (в т.ч. в отчётах), и всё без единой строчки кода.
В крайнем случае можно записать "макрос" — код исполнения макроса сгенерируется автоматически, его можно присвоить какой-нить кнопке или пункту меню, в т.ч. контекстного, т.е. в тело макроса (это просто код на VBA) заглядывать не обязательно.

Или системы для моделирования электронных схем — накидываешь "алгоритм", задаёшь входные данные (например, кнопки в GUI этой же системы-симулятора, или нетривиальные входные сигналы), запускаешь, отлаживаешь. Отладил — можно паять. ))


S>Простой бухгалтер может из такого инструмента сделать «2B:Платёжные документы», с любыми печатными образцами, не написав ни одной строчки кода и не задумываясь ни об одном алгоритме. И P-схемы ему не нужны. И редактор форм. Причём, с моей стороны я вообще не знаю ни о геометрии документа для печати, ни о прикладном смысле строк и таблиц.


Ну, кое-какие алгоритмы ему знать надо, из разряда что делает тот или иной "кубик" системы (кнопка, команда, режим, их св-ва, как взаимодействует и т.д.)
Да, юзверь в таких системах работает с предметно-ориентированной средой, заточенной на решение некоего класса задач, т.е. работает с достаточно высокоуровневыми "алгоритмами" и в тех условиях, что околосистемные вещи "кто-то" за него уже решил.

Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.

======================
В общем, моё ИМХО последние лет 20 неизменно — современные программисты слишком много заняты сугубо в прикладных вещах.
Такое ощущение, что это от неумения описывать прикладные вещи параметрически, пригодным для комбинирования извне способом, от недостаточности в индустрии накопленных таких повторно-используемых подходов-фреймворков.

Оно понятно почему так — такие вещи являются строгой ноу-хау конкретной коммерческой конторы.
Т.е., циркулирования знаний по этой области в индустрии нет.

Масла в огонь подлило еще то, что UML, по-сути, не взлетела, а привычные схемы алгоритмов до этого предали анафеме проповедники UML.
Т.е., эдакая самоанигиляция вышла. ))

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

Вот эти люди что могут в деле САПР?
Они могут только вредить узколобыми лозунгами из разряда "нормальному программисту текста достаточно".

В итоге, сегодняшние системы САПР в своих возможностях не сильно убежали от аналогичных 20-тилетней давности, увы.

Кое-какой приличный экстенсивный рост есть (в тех же 3D САПР), но они топтались на месте пару десятилетий, пока не догадались сделать, например, BIM в строительстве — совместить структуру объекта с базой знаний о нём. Но там пока что даже форматы данных и их семантика находятся в стадии устаканивания. Причём, обычным для IT способом — форматы продуктов-победителей стараются поддерживать для импорта-экспорта "остальные", вот тебе создаётся стандарт де-факто.

Например, P-CAD когда-то ввёл несколько форматов, которые за пару лет буквально стали де-факто стандартом для интеропеработности данных м/у различными САПР проектирования электроники.

Одно плохо — сегодня этот фокус повторить не удастся, т.к. инерционность у индустрии не как в начале-середине 90-х.
Т.е., когда-то быстрые эти процессы сегодня растягиваются на много-много лет.
Отредактировано 17.09.2021 14:02 vdimas . Предыдущая версия . Еще …
Отредактировано 17.09.2021 14:01 vdimas . Предыдущая версия .
Отредактировано 17.09.2021 14:00 vdimas . Предыдущая версия .
Re[5]: Опять поднимают про low-code и помоечку для средняков
От: Shtole  
Дата: 17.09.21 16:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это случайно не MS Access?


На самом деле, больше похоже на SharePoint. «Но есть нюансы» ©
Do you want to develop an app?
Re[6]: Опять поднимают про low-code и помоечку для средняков
От: Shmj Ниоткуда  
Дата: 17.09.21 17:06
Оценка:
Здравствуйте, Shtole, Вы писали:

S>На самом деле, больше похоже на SharePoint. «Но есть нюансы» ©


Re[5]: Опять поднимают про low-code и помоечку для средняков
От: Shtole  
Дата: 17.09.21 19:02
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Да понятно, но в БД тоже имена, типы...

V>А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
V>Многие такие менеджеры еще позволяют графически конструировать запросы.

Зачем пользователю графически конструировать запросы?

Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы. И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».

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

S>>Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа.

V>А современные конструкторы сайтов смотрел?

Их много, и хотя форм-фактор «конструктор сайтов» уже идёт вразрез с идеей того, что я делаю, я буду благодарен (чисто для расширения кругозора) за любые примеры того, как описанную функциональность можно сделать в других местах. Например, какие шаблоны они понимают? Txt, HTML, pdf? Что-то ещё? Какой синтаксис используют для разметки?

V>Ну, кое-какие алгоритмы ему знать надо, из разряда что делает тот или иной "кубик" системы (кнопка, команда, режим, их св-ва, как взаимодействует и т.д.)


Я стараюсь исходить из потребностей. В данном случае, как я вижу, есть потребность иметь по каждой строке (описывающей, например, транзакцию) пригодный для печати отчёт (платёжку, счёт, whatever), доступный прямо из таблицы. Соответственно, так это и представлено в UI: добавление колонки типа «Отчёт», для чего нужно выполнить одно действие (не считая задавания имени колонки): выбрать файл с шаблоном. Но, возможно, я в плену предубеждений и можно сделать то же самое понятнее для юзера.

V>Да, юзверь в таких системах работает с предметно-ориентированной средой, заточенной на решение некоего класса задач, т.е. работает с достаточно высокоуровневыми "алгоритмами" и в тех условиях, что околосистемные вещи "кто-то" за него уже решил.


Возможно, что я ошибаюсь, но как раз «предметная ориентированность» и губит все такие продукты. Выше давали ссылку на менеджер чеков для tax return, экспат в Германию описывает свои с ней приключения.

Предметно-ориентированные среды легче позиционировать, да. (То есть, «предметная ориентированность» вообще не про продукт, а про маркетинг — тот же SharePoint как только не впаривали, и как «веб-портал», и как СКД, и как чёрта в ступе, однако его техническая суть от этого не меняется). Но поскольку сама предметная область — понятие расплывчатое, если слишком углубиться в этом направлении, по ходу пьесы часто оказывается, что (в рамках той же предметной области!) сделано много неуниверсальных предположений, введено много ненужных ограничений и так далее.

Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок. Но вы же знаете, что идеал нам только снится

V>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)

V>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.

А какой именно идее? Как вы её сформулируете?

Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.

Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.

По-моему, юзеру гораздо удобнее работать с этим шиворот-навыворот: он думает не о ключевых полях, а о репрезентативных полях (полях, представляющих запись) и только в момент, говоря этим казённым языком, установления связей. То есть, когда юзер, создавая колонку со ссылкой, выбирает, значениями из какой колонки (колонок) целевой таблицы надо заполнять комбо-бокс. И на передний план выходят вопросы, странные для программиста, но очевидные для юзера, например, сохранять ли форматирование при подстановке, если да — от какого представления (если, конечно, в UI вообще есть представления).

Репрезентативное поле, в отличие от ключевого, для пользователя имеет смысл только в контексте ссылающейся таблицы. Знать его, создавая справочник, невозможно. (Потому, что невозможно заранее знать все сценарии использования справочника, на то он и справочник).

И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.

Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области. Что юзер должен с этой колонкой делать? Она же чисто техническая! И нужна, как правило, для стыковки с другими системами. Но совать её в интерфейс на самом первом (то есть, самом дорогом) месте — извините.

Как-то так.
Do you want to develop an app?
Отредактировано 17.09.2021 19:46 Shtole . Предыдущая версия .
Re[7]: Опять поднимают про low-code и помоечку для средняков
От: Shtole  
Дата: 17.09.21 19:03
Оценка:
Здравствуйте, Shmj, Вы писали:

S>>На самом деле, больше похоже на SharePoint. «Но есть нюансы» ©


S>1С


Да ради бога!
Do you want to develop an app?
Re[6]: Опять поднимают про low-code и помоечку для средняков
От: vdimas Россия  
Дата: 17.09.21 21:18
Оценка:
Здравствуйте, Shtole, Вы писали:

V>>А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.

V>>Многие такие менеджеры еще позволяют графически конструировать запросы.
S>Зачем пользователю графически конструировать запросы?

А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?


S>Да, их вот так, примерно, и пишут, эти тулзы. Это полная аналогия P-схем из заглавного сообщения. Но! Если я думаю такими категориями как «запрос», это уже всё, мне проще 5 минут почитать документацию на мускул, чем разбираться в очередной упоротой попытке визуально представить запросы.


Это тебе.
А далёким от программирования проще визуально накидать сущности, заодно увидев связи м/у ними, т.к. GUI-редактор запроса может сразу соединять внешние ключи.


S>И это, кстати, не умозрительные построения: я хорошо помню, как директор предприятия, где я когда-то работал джуном, однажды поздним вечером, когда все разошлись, пришёл на моё рабочее место с вопросом, не знаю ли я, как в SQL записать «не равно». Он срочно какой-то отчёт делал, в разрабатываемых компанией продуктах (для себя и с прицелом на продажи) нужной функциональности не нашлось, пришлось ему ковыряться в исходных данных. Что, по-моему, подтверждает тезис, что имея дело с запросами, пользователю проще уточнить синтаксис в поисковой системе или тупо позвать «тыжпрограммиста».


Вызов тыжпрограммиста 1С обходится слишком дорого.


S>Упомянутый выше Access, кстати, такой же. По крайней мере, был. (У меня старая версия). Не успел я создать таблицу, как он ошарашил меня вопросом, не хочу ли я задать ключевые поля для установления связей. Выносить в интерфейс такие вещи для меня выглядит очень странно.


Это та самая автоматизация рутины.
В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))


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


Для этого хотелось бы увидеть "описанную функциональность".
Конструкторы сайтов очень разные.


S>Например, какие шаблоны они понимают? Txt, HTML, pdf? Что-то ещё? Какой синтаксис используют для разметки?


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


S>Предметно-ориентированные среды легче позиционировать, да.


И ими легче пользоваться.
Для сред более широкого назначения не обойтись без большой сетки чего-то вроде "шаблонов пустых приложений".


S>Да и вообще, предметная ориентированность и no-code/low-code — понятия взаимоисключающие. Чем лучше представлена предметная область, тем меньше потребности в no-code/low-code. В идеале — у тебя продукт под твой user case, который вообще не требует доработок.


Да ладно.
А шкафчик свой в Архикаде нарисовать?
А здание в виде спирали и волн, построить там все балки?

Все более-менее серьезные такие вещи представляют из себя инструмент для очень продвинутого юзверя, что MS Access, что Архикад.
А непритязательные могут и SketchUp-ом побавляться, эдаким блокнотиком для зарисовок.


S>Но вы же знаете, что идеал нам только снится


Ну, активная работа идёт.
По крайней мере в строительных САПР-ах.
Можно накидать свой проект, выложить онлайн и дать клиенту сылку — он как в в трехмерной игре может побродить по будущему дому, потыкать по реквизитам, сопоставлять планы и "ощущения" от 3D.

Вот ролик аж на 4 минуты:
https://www.youtube.com/watch?v=9sUQYtSKYw0

Рекомендую не пролистывать, а вытерпеть все 4 минуты, там ничего лишнего. ))


V>>Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)

V>>А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.
S>А какой именно идее? Как вы её сформулируете?

Я уже формулировал — автоматизация рутины или облегчение взаимодействия с ней.
В первом же P-CAD можно было создавать свои блоки (макросы) из готовых элементов и использовать их затем.
Т.е. не надо повторяющиеся части схем каждй раз заново вводить.

Параметрические 3D САПР.
Параметрические — ключевое, поменял пару св-в и всё может быть пересчитано и поменяться до неузнаваемости.

Например, "играть" с проектом многоэтажного дома, подставляя разные св-ва сразу всех карнизов или выбранной группы, видов балконов и т.д.

Кульманом на ватмане это перерисовывать бесконечно.
В обычных 3D рисовалках, типа SketchUp — тоже.
А тут лениво мышкой можно гонять многие тысячи комбинаторных сочетаний всего со всем.


S>Я сформулирую главную идею так: двигаясь от нишевых продуктов в сторону no-code/low-code, не надо тащить программистский мусор в UI. Оттого, что он завёрнут в мастер, он не перестанет быть программистским мусором.


Ничего не понял.
Что такое "программистский мусор"?


S>Опять же, пример, раз уж про этот Access речь зашла: эти дурацкие ключевые поля для установления связей.


А как жить без внешних ключей? ))
Без внешних ключей не нужна никакая реляционная база, можно пользоваться нереляционной.


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


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


S>И, конечно, пользователю нафиг не нужно ограничение по уникальности при этом. Это вообще какой-то изврат! Если у него в выпадающем списке будет 10 Ивановых подряд — что ж поделать, если компания большая и там работает много Ивановых. Излишне прямолинейный пользователь откроет справочник, и посчитает, какой по порядку Иванов ему нужен. Более продвинутый пользователь настроит репрезентативное поле как ему удобно, чтобы избавиться от неоднозначности и видеть в комбо-боксе варианты типа «Иванов, Иван» или «Иванов, инженер». И опять же, никакого ограничения на уникальность комбинации. Если в компании работает два инженера Иванова или два Ивана Иванова, это просто данность.


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


S>Конечно, полностью скрыть от юзера внутренний auto incremented unique id — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области.


1. Проще убрать готовое поле из представления, чем непонятно как его добавить, особенно в первые дни работы с такими продуктами.
2. В любом случае существует некий мастер форм, где отмечаются поля, которые юзверь желает видеть на форме или в таблице.
Отредактировано 18.09.2021 11:39 vdimas . Предыдущая версия . Еще …
Отредактировано 18.09.2021 11:27 vdimas . Предыдущая версия .
Отредактировано 18.09.2021 11:25 vdimas . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.