Здравствуйте, Shtole, Вы писали:

S>Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас. Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига». Вот они-то эту нишу — no-code/low-code — и займут.

Я заметил, что и no-code системы, где можно задавать логику программы какими-то иными (возможно визуальными) средствами — даже они требуют квалификации человека.
Вы удивитесь, не каждый в состоянии ими пользоваться. Даже просто понять. Не говоря о том, чтобы тщательно и качественно делать эту самую логику. Чтобы и багов не было, и чтобы всё элегантно было.

Да, это не программный код. Но тем не менее, оказывается что и no-code сложны для обывателя.

Здравствуйте, vdimas, Вы писали:

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

Например, через формульные колонки и колонки-ссылки.

Условия, column set, сортировка, группировка — через представления. (Посмотрите, например, в Outlook. Только там всё гвоздями прибито. Зачем-то). Сложные условия — тоже через формульные колонки.

Но вообще это надо на конкретных примерах рассматривать.

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

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

Смотря что понимать под словом «визуально». Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.

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

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

Так вроде про SQL-запросы речь шла? Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?

У них своя система (буква С в слове СУБД), своё видение, и про них мне не очень интересно.

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

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

Так дело же не в том, что «мышкой нащёлкать». Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее. Щёлкаешь на кнопку — у тебя текст копипастится в запрос. Как на Спектруме. Вообще, вот это и есть мой point: вместо того, чтобы думать и делать хороший UI на замену DSL/ЯП, люди берут понятия программирования и делают так, чтобы их можно было мышкой нащёлкивать. То есть, идут по пути наименьшего сопротивления. Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.

Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии? Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей? Или в почтовом клиенте/органайзере они есть? Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля. Текст я понял так, что без них, мол, связи установить не смогу. Страшно. Вдруг мне эти связи понадобятся? Нуок, я нажимаю «Да» — бамс! Держи колонку «Код» на самом видном месте. Ну хорошо, можно, оказывается, скрыть эту колонку, если щёлкнуть по ней ПКМ. То есть, сначала меня заставляют создать ненужную для моих целей колонку, а потом искать, как её скрыть. И в той версии Access, что у меня, нет возможности скрыть эту колонку от бухгалтера, но оставить для администратора (т.е. представлений). Флаги отображения колонок глобальны, их возможные значения ни к чему не привязаны.

На всякий случай: я просто описываю то, что видит пользователь.

Короче, чтобы не перепираться тут до бесконечности. Просто посмотрите, как это сделано в Шарике. Там много умного придумано по сравнению с Access. Но колонка Id, ЕМНИП, у них тоже на самом видном месте. Ну и вообще — Шарик (был?) просто игрушкой. Чтобы можно было хоть как-то им пользоваться, я его дорабатывал в своё время с помощью хранимок, триггеров, SQLCLR и такой-то матери (напрямую работая с MS SQL, да — через их API практически полезные сценарии заведомо реализовать нельзя было), но так и не смог получить приличную производительность. Плюс у них некоторые моменты принципиально неправильно сделаны. CAML — их DSL для управления данными — был полное позорище (мааааааленькое подмножество SQL зачем-то завернули в XML), объектная модель (для того самого low code) — тоже. Ну, может с тех пор его в чём-то улучшили, но для no-code/low-code я его НЕ посоветовал бы ни при каких раскладах.

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

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

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

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

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

Ну и где там no-code/low-code? Вы просто берёте готовый продукт (Архикад) и юзаете as is. No-code/low-code это, скорее, когда берёте универсальную платформу. Создаёте структуру, представления, условия, ограничения, шаблоны, валидаторы, извещения, отправку документов и т.п. — всё это без программирования. И получаете конкретно заточенную под ваши юз-кейсы систему.

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

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

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

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

Зачем я это терпел 4 минуты? В смысле, где там no-code/low-code? Просто раньше в комплекте с редактором — например, тем же Excel'ем — шёл облегчённый viewer, чтобы юзер не обламывался, получив по почте .xls. Иногда можно было сгенерировать viewer с одним-единственным документом (как в PowerPoint). Ну вот, а эти сделали облегчённый viewer чисто в браузере и дали возможность публиковать документы через своё облако. Ну, молодцы. (Наверно). Хотя я бы лично такое не купил, потому, что даже облако выбрать нельзя. Но это к делу не относится. Что там именно no-code/low-code? В UE4, для сравнения, хоть BluePrint есть. Он всяко к теме больше отношения имеет.

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

V>Я уже формулировал — автоматизация рутины или облегчение взаимодействия с ней.

Слишком общо.

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

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

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

Внешние ключи это и есть программистский мусор, который не надо тащить в UI. Давайте возьмём пример из Википедии.

Вместо всего этого ужаса можно же просто:

а) Сделать CITY не таблицей, а колонкой-перечислением (enum'ом) в таблице с адресами. Для юзера это самое естественное. Контроль ссылочной целостности надо привязать к редактированию колонки, предлагая разумные опции в контексте операции: чем заменить удаляемое значение, если оно используется? На практике же это для чего нужно: какая-нибудь ворона забила три москвы, на все три куча ссылок в адресах, их надо смерджить. Удаляем их по одной, нас спрашивают, что использовать вместо — оба раза выбираем правильную. (Или, допустим, пустое значение — но это если колонка может быть пустой, т.е. допускаются адреса без города).

Сравните теперь, как выглядят сценарии на основе внешних ключей для юзера:

Если для внешнего ключа разрешено удаление по цепочке, то вместе с удалением Владивостока будут удалены улицы Светланская и Пушкинская с ID=3.
Если для внешнего ключа запрещено удаление по цепочке, то операция вызовет ошибку нарушения ссылочной целостности, так как в таблице STREET будут находиться улицы с кодом ID_CITY=3, который отсутствует в таблице CITY.

Блин, тут прямо не знаешь, что и выбрать — один вариант лучше другого!

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

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

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

Ага. А сиплюсплюс можно за 21 день выучить.

Если мне так и так нужно разбираться с ключами, в чём тогда смысл платформы? Она меня огородит от необходимости изучать синтаксис SQL? Но ведь дело-то не в синтаксисе, а в идеях, которые через него выражаются. На практике это приведёт к тому, что нужен будет программист на этом визуальном псевдо-языке, ну и по всем кочкам. Дешевле нанять fullstack (SQL/сервер/клиент) разработчика.

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

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

Подождите минутку. Впечатления свежи, потому, что я, раз уж тут заговорили про Access, специально его открыл и включил юзера. Чтобы разговор не был голословным. Чтобы на примерах.

Но ведь эти примеры не просто так, они показывают принципиальный подход разрабов. Вот о нём мы и говорим. На конкретных примерах. Конкретные примеры за 20 лет могут устареть, но подход-то останется. Если в новом Access именно подход поменялся по сравнению с той версией, которая у меня, так и напишите.

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

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

1. А ещё лучше (не проще, а лучше) не отображать его ни в дефолтном представлении, ни по дефолту в новых представлениях. И не задавать глупых вопросов. И автоматически задействовать его для ссылок, оставив юзеру только выбрать способ репрезентации записи.
2. Зачем нужен мастер форм? Если уж использовать мастер вообще (а не инспектор свойств, например), то это должен быть мастер представлений.

Здравствуйте, 4058, Вы писали:


4>И конечно там был Document-ум, без него ведь, подобные мероприятия не обходятся … Тоже хотели, без приличных знаний в области БД, чтобы по визуальным описаниям дальше как-то “всё само”.

у компаннии GBS Group был продукт для визуального составления SQL запросов и создания БД
все работало более менее, естественно пока база была не большая

Здравствуйте, Shtole, Вы писали:

V>>А как соединить несколько сущностей и навесить условие выборки на поле крайней такой сущности?
S>Например, через формульные колонки и колонки-ссылки.

Как это выглядит в GUI?


S>Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.

У тебя еще не было возможности открыть MS Access и посмотреть на драг н дроп? ))

Создай две-три таблицы с внешними ключами, открой Database Tools -> Relationship, мышкой накидай связи.

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


V>>Вызов тыжпрограммиста 1С обходится слишком дорого.
S>Так вроде про SQL-запросы речь шла?

Речь наоборот шла про то, чтобы юзверю не надо было учить SQL, как не надо его учить для построения приложений в MS Access.

А вызов "надомного программиста" всегда будет стоить чудовищно дорого.
Расценки вызовов 1С поддержки тому подтверждение.


S>Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?

От твоего директора, который полез программировать и не справился.


V>>Это та самая автоматизация рутины.
V>>В MS Access вполне возможно 80% приложения мышкой нащёлкать. ))
S>Так дело же не в том, что «мышкой нащёлкать».

Для no-code — именно в этом.


S>Можно сделать панельку с кнопками SELECT, *, FROM, INSERT и так далее.

Нельзя.
Для юзверя это будет что-то вроде программирования на ассемблере.


S>Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.

И что теперь?
Так и продолжать забивать гвозди микроскопом?
А нам точно компьютер для того дан, чтобы в миллионый раз ручками набивать вот это позорище полувековой давности:

FOREIGN KEY (CustomerId)  REFERENCES Customers (Id)

вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями?
Или придумать, ну не знаю, формат текста специфичный и редактор к нему, чтобы после поля ставишь ->, выскакивает попап с выбором другой таблицы или интиллисенс, начинаешь вводить, ентер/пробел/таб, в тексте остаётся как-то так:
CustomerId^{➔Customers.Id}

Меня за мои почти 30 лет карьеры плоский текст задолбал, если честно.
Воз и ныне там, с чего начинал когда-то — так всё и есть до сих пор.


А вот это г-но мамонта полувековой давности в скриптах SQL — банальная роспись индустрии в недееспособности.

No-code в числе прочих сможет сделать низлежащие форматы/языки не принципиальными, не столь важными.
Их можно будет подменять, не трогая "верхней" функциональности.

А сейчас всё пляшет от языка и только от него.
И в самих языках наблюдается отчётливый кризис жанра. ))
"Новейшие" языки пытаются изобрести то, что изобретено еще в 70-80-90-е.

Всё вместе, в некотором смысле, деградация.
Плохая интероперабельность.

Например, во времена COM программы прекрасно взаимодействовали друг с другом, а сегодня простейшее взаимодействие программ, чаще неавтоматизированное или полуавтоматизированное на основе импорта-экспорта зачастую преподносится как достижение.
Позорище это, а не достижение.

Сдаётся мне, рано или поздно OLE переизобретут. ))


S>Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии?

Разумеется!
В таблице Менделеева есть естественный ключ {атомный-номер}.

В таблице изотопов будет составной ключ {атомный-номер, массовое-число}, при этом поле "атомный-номер" мы зададим еще внешним ключом к таблице Менделеева, а значит по нему автоматически будет создан индекс.


S>Как мне удавалось писать лабы с таблицами экспериментов, ссылаясь на них, без ключевых полей?

1. От незнания.
2. От ничтожного размера хранимых данных.


S>Или в почтовом клиенте/органайзере они есть?

Почти всегда.


S>Не под капотом, а главном окне по умолчанию сразу после инсталляции? Но когда я накидал простенькую табличку в Access, первым делом, что попытке сохранить проект (mdb-файл) меня спросили, это не хочу ли я задать эти поля.

Правильно спросили.
Перевожу вопрос на русский язык:
"Вы, дядя, если не дурак, то уж точно заблудились, бо в реляционной БД имеет смысл хранить только реляционные данные. В противном случае воспользуйтесь, пожалуйста, другим видом хранилища".

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

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


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

Ладно, сорри.
Твой стиль напоминает сочинение из разряда "как я провёл лето".

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

— Говори по существу.

— Любые подробности должны тем или иным образом относиться к делу. Растекаться мыслью по древу тоже надо уметь.

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

Здравствуйте, jamesq, Вы писали:

S>>Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас. Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига». Вот они-то эту нишу — no-code/low-code — и займут.
J>Я заметил, что и no-code системы, где можно задавать логику программы какими-то иными (возможно визуальными) средствами — даже они требуют квалификации человека.

Разумеется.


J>Вы удивитесь, не каждый в состоянии ими пользоваться. Даже просто понять.

Ну да.
Некоторые по 20 лет сидят в MS Word ежедневно, а пользоваться стилями так и не научились.


J>Да, это не программный код. Но тем не менее, оказывается что и no-code сложны для обывателя.

No-code не для дураков, факт.
Но и не для программистов-профессионалов.
Это для профессионалов в других предметных областях.

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

Здравствуйте, landerhigh, Вы писали:

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

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

UML не взлетели по другой причинам.

В UML отсутствует целостность, поэтому UML-описаниям не присуща самодостаточность.

Какое-бы описание UML ты не взял, из него нельзя породить код и наборот тоже.

Единственная статическая диаграмма кассов UML, допускающая взаимно-однозначное соответствие хотя бы с частью кода — самая бесполезная из всех.

При этом UML убили единственную полезную диаграмму, бывшую популярной до неё — диаграмму "блок-схема алгоритма".

В общем, UML одно время прошлись по индустрии тактикой выжженой земли, но сами сдохли.
За что IT так не везёт — я уже ХЗ.

А потом удивляемся, почему мы растим дебилов в новом поколении?

Здравствуйте, vdimas, Вы писали:

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

Ты Query By Example имеешь в виду?

Здравствуйте, vdimas, Вы писали:

V>No-code не для дураков, факт.
V>Но и не для программистов-профессионалов.
V>Это для профессионалов в других предметных областях.

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

Здравствуйте, AleksandrN, Вы писали:

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

AN>Ты Query By Example имеешь в виду?

https://www.mssqltips.com/sqlservertip/1086/sql-server-management-studio-query-designer/
https://www.opengatesw.net/ms-access-tutorials/Access-Articles/Microsoft-Access-Query.htm

Здравствуйте, jamesq, Вы писали:

V>>No-code не для дураков, факт.
V>>Но и не для программистов-профессионалов.
V>>Это для профессионалов в других предметных областях.
J>Как бы это означает, что радикально нехватку кадров no-code средства решить не помогут.

Откуда там нехватка кадров?
Радикальная нехватка как раз в кодинге.
В том числе из-за того, что программисты кодируют то, что не должны.

Ждите новых витков увеличения ЗП...
А оно тормозит развитие IT, как ни крути...

vsb>А вообще, думаю, принципиально ничего не мешает low code подходу применяться и в более сложных проектах. Просто нужна грамотная архитектура и реализация.

Ну то есть прекрасно работает, надо только правильно пользоваться. Ага, ага.

Здравствуйте, vdimas, Вы писали:

V>Как это выглядит в GUI?
Позже покажу.

S>>Иметь таблицы с данными перед глазами — это одно. А драг-н-дропом перетаскивать колонки или тянуть стрелки для связей — это совсем, совсем другое.

V>У тебя еще не было возможности открыть MS Access и посмотреть на драг н дроп? ))
V>Создай две-три таблицы с внешними ключами, открой Database Tools -> Relationship, мышкой накидай связи.
V>Затем создай визардом новый запрос, просто накидай поля с двух связанных таблиц, убедись в режиме конструктора, что таблицы связаны по внешнему ключу как ты и указал в схеме данных до этого.

А у вас не было возможности открыть SharePoint и посмотреть как это сделано там? Объяснять бесполезно, надо попробовать. Вроде бы, мелкомягкие дают триальный доступ (если зарегистрироваться). Раньше попадались инстансы demo/demo, но дни те прошли, увы.

Вообще, SharePoint это очень хороший пример того, о чём я говорю.

С одной стороны нечего там мышкой «накидывать». Надо задавать свойства. А с другой стороны, он реализует пользовательскую систему метафор, а не программистскую. Сравнить их очень просто: я ещё ни разу не видел, чтобы юзеры без специального образования с Access'ом разбирались так же быстро, как с ШП. Как только продвинутый юзер посоздаёт пару «списков» (Lists, аналог таблицы в ШП), он очень быстро начинает делать справочники, заботиться о нормализации данных и вообще — проектировать БД. И... тут же упирается в ограничения реализации ШП. Но как маяк, задающий вектор направления no-code/low-code, ШП, повторюсь, неплохой пример.


S>>Цитирую: «А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно». Откуда у нас появился 1С-тыжпрограммист?
V>От твоего директора, который полез программировать и не справился.

??? Вообще ничего не понял.

Во-первых, там была SQL БД.

Во-вторых, SQL это не ЯП. Это язык управления БД. В том числе для запросов. Я слышал, что когда-то SQL (в командной строке) был аналогом... ну, любого современного продукта для организованного хранения данных. В том смысле, что это был пользовательский интерфейс (а не как сейчас — DSL, на котором 99.9% запросов конструируют и отправляют роботы). Причём, пользовательский в прямом значении этого слова. Считалось, что компьютерно грамотный счетовод с его помощью будет отчёты писать. Так что — директор не «полез программировать», а просто вернулся к пользовательским корням.

В-третьих, он не «не справился», а просто не знал синтаксис одной конструкции. Да я и сам не знал, я на тот момент с базами дел не имел. Просто попробовал перебрать !=, <>, второе сработало.

В-четвёртых, яжпрограммист уже трудился и моя помощь ему ничего не стоила, если не считать 10 минут рабочего времени.


S>>Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.

V>И что теперь?
V>Так и продолжать забивать гвозди микроскопом?
V>А нам точно компьютер для того дан, чтобы в миллионый раз ручками набивать вот это позорище полувековой давности:
V>

V>FOREIGN KEY (CustomerId)  REFERENCES Customers (Id)
V>

V>вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями?
V>Или придумать, ну не знаю, формат текста специфичный и редактор к нему, чтобы после поля ставишь ->, выскакивает попап с выбором другой таблицы или интиллисенс, начинаешь вводить, ентер/пробел/таб, в тексте остаётся как-то так:
V>CustomerId^{➔Customers.Id}

Я не знаю, как ещё объяснить. Я считаю (возможно, ошибочно), что «мышкой протянуть» — это искать под фонарём. Это чисто формальная попытка создать дружественный UI. Сделанная на отмирись. А по-настоящему дружественный UI это колонки-ссылки.

V>No-code в числе прочих сможет сделать низлежащие форматы/языки не принципиальными, не столь важными.

Правильный no-code ДОЛЖЕН сделать низлежащие форматы/языки АБСОЛЮТНО не важными. Иначе это будет тупой маппинг низлежащего формата на уровень UI, со всеми врождёнными особенностями.

Например, триггер для юзера — это не сами знаете что, а, например, отправка сообщения в телегу. Очень удобно, кстати. Пользователи такие вещи обожают. Представляете — вы можете сделать свою Джиру за час, вообще не программируя, при этом интегрироваться с административной базой (HR) и будут у вас уведомления в мессенджер приходить. Зачем вообще делать свою Джиру? А почему бы нет, если любой менеджер, не программируя, может за час управиться, при этом гибко подстроив под свои процессы (которые у всех разные). А ещё лучше — скачать шаблон issue tracker и донастроить его.

V>Например, во времена COM программы прекрасно взаимодействовали друг с другом, а сегодня простейшее взаимодействие программ, чаще неавтоматизированное или полуавтоматизированное на основе импорта-экспорта зачастую преподносится как достижение.
V>Позорище это, а не достижение.

Немножко пофилософствую.

Смотрите, винды всегда были проприетарными. Исходники давали только правительствам и особо доверенным партнёрам. А Андроид — опенсорсный. Кто из них более открыт?

Я скажу так, что это большой и сложный вопрос. В виндах в комплекте из коробки идёт Regedit, например. И винды когда-то поощряли хранение данных в реестре. С именованными типизированными значениями. В стоковом Андроиде как подкрутить одну из тысяч мелочей, если понадобится? Качать аппу из апстора. Хотя под капотом там наверняка можно одну запись где-нибудь поменять. Но нет инструмента — и тащи аппу. С рекламой, занимающую место и так далее.

Так вот. Применительно к управлению данными открытость не в том, чтобы был импорт-экспорт (хотя это, конечно, вещь нужная и полезная). А в том, чтобы доступ к данным у юзера был напрямую и в удобном виде. Чтобы он мог их как угодно повертеть — сделать выборку, отфильтровать, отсортировать, сгруппировать, выбрать нужное представление — не прибегая к импорту-экспорту.

V>Сдаётся мне, рано или поздно OLE переизобретут. ))

S>>Я повторю свой вопрос: зачем мне, юзеру, ключевые поля для установления связей? Разве есть они в справочнике по химии/физике/металлургии?

V>Разумеется!
V>В таблице Менделеева есть естественный ключ {атомный-номер}.

Я имел в виду, например, таблицы из этого раздела.

S>>Или в почтовом клиенте/органайзере они есть?
V>Почти всегда.

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

В каком смысле — дорогие и неэффективные?

V>Ладно, сорри.
V>Твой стиль напоминает сочинение из разряда "как я провёл лето".

Я просто хотел, чтобы вы забыли на минутку, что вы разработчик с 30 годами сикуля за плечами, и посмотрели глазами юзера.

V>================
V>Такое складывается ощущение, что ваше поколение не то что не стремится поддерживать цену своим словам, а просто не в курсе про существование такого критерия оценки личности.
V>- Говори по существу.
V>- Любые подробности должны тем или иным образом относиться к делу. Растекаться мыслью по древу тоже надо уметь.
V>- Не злоупотребляй оценочными суждениями, а лучше вообще от них отказаться в технических рассуждениях.
V>Оценочные суждения тем уместней, чем меньше информации, но всегда ли ты способен отличить ситуацию, где информации мало у всех, то бишь мало объективно, от той ситуации, где инфы мало конкретно у тебя, потому что еще зеленый?

Э-э? А какие подробности к делу не относятся? Моё поколение ещё учили, не знаю, как последующие, что полезно на конкретных примерах обсуждать, а не клеить ярлыки. Поэтому я и беру конкретные примеры.

Здравствуйте, vdimas, Вы писали:

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

А значит, и не было, да.

V>Любые САПР отродясь подаются как ср-во повышения производительности профессионалов, а не как ср-во сделать безработных дураков умными.

В начале 2000 у нас что было?
Правильно, дот-ком бум.
Россию он, по большому счету, обошел, но "там" такие вундервафли именно на излете оного и расцвели. Лохам можно было впарить что угодно.
Были даже очень платные курсы по UML. Случалось, что не знающим, что означает ромбик в начале стрелочки, на собеседовании презрительно кидали "мы вам перезвоним".

Я лично застал закономерное увядание оных в двух конторах.

Здравствуйте, Аноним931, Вы писали:

vsb>>А вообще, думаю, принципиально ничего не мешает low code подходу применяться и в более сложных проектах. Просто нужна грамотная архитектура и реализация.

А>Ну то есть прекрасно работает, надо только правильно пользоваться. Ага, ага.

Не вижу никаких принципиальных причин, по которым оно бы не могло работать.

Здравствуйте, landerhigh, Вы писали:

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

По факту не было.
Студенты когда за обеды работали — то это не в продакшен, а когда-то пилили что-то для использования по-месту.
И тот бартер был больше за машинное время. ))
И давно это было, когда ни о каком no-code речи толком не было.

Т.е, САПР уже были (электротехнические и 3D), но самих таких обсуждений не было.
Из программистских САПР с натяжкой были MS Access и FoxPro у них (последний совсем с натяжкой).
У нас появилась уникальная 1С — полноценная САПР для бухгалтерского ПО.

Остальное на САПР не тянуло.
Взять Rational Rose, Together — это не полноценные САПР, т.к. не в состоянии автоматизировать создание конечного продукта.
Это утилиты для архитекторов ПО.


V>>Любые САПР отродясь подаются как ср-во повышения производительности профессионалов, а не как ср-во сделать безработных дураков умными.
L>В начале 2000 у нас что было?
L>Правильно, дот-ком бум.
L>Россию он, по большому счету, обошел, но "там" такие вундервафли именно на излете оного и расцвели. Лохам можно было впарить что угодно.

Ну вот как раз для веба САПР не было.
Не считать же за него визивинг редактор HTML или возможность сохранить док-т Word как веб-страницу? ))


L>Были даже очень платные курсы по UML.

UML более про ООП, при чём тут бум доткомов?
Тот бум был про PHP, когда "каждая домохозяйка..." и далее по тексту.
В штатах именно домохозяйки ходили на курсы по PHP или даже ColdFusion, и для некоторых это даже сработало.
Правда, угробило PHP. ))

И да, UML там не давали.


L>Случалось, что не знающим, что означает ромбик в начале стрелочки, на собеседовании презрительно кидали "мы вам перезвоним".

Тогдашние многие айтишники не проходили ООП в ВУЗ-ах, поэтому, осваивать эту парадигму самостоятельно было необходимо, ес-но.
А что, сложно потратить пол-часа и запомнить, что означают символы UML? ))


L>Я лично застал закономерное увядание оных в двух конторах.

Оных чего?

Здравствуйте, vdimas, Вы писали:

L>>А значит, и не было, да.
V>По факту не было.

Ты меня улыбаешь.
Тебе прямо говорят — я лично застал именно это в двух конторах. "Там", естественно.
В одну из них, которая наняла непонятно кого делать дот ком себе, и ожидаемо пролетела, ушлые дельцы загнали аналог Rational Rose как вундерфавлю. Я как раз туда пришел, когда "архитектор ушел на повышение, но модель в UML уже почти готова".

V>Взять Rational Rose, Together — это не полноценные САПР, т.к. не в состоянии автоматизировать создание конечного продукта.
V>Это утилиты для архитекторов ПО.

А попытка генерации кода из оных — это для кого?

L>>Были даже очень платные курсы по UML.
V>UML более про ООП, при чём тут бум доткомов?

А что, дотком — это только веб? У меня для тебя новости.

L>>Случалось, что не знающим, что означает ромбик в начале стрелочки, на собеседовании презрительно кидали "мы вам перезвоним".
V>Тогдашние многие айтишники не проходили ООП в ВУЗ-ах, поэтому, осваивать эту парадигму самостоятельно было необходимо, ес-но.

Не надо всех по себе судить, ладно?
ООП уже к концу 90-х был тем еще баяном.

V>А что, сложно потратить пол-часа и запомнить, что означают символы UML? ))

Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей.

В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram.

Все остальное — просто набор квадратиков.

L>>Я лично застал закономерное увядание оных в двух конторах.
V>Оных чего?

Учу читать. Дорого (с)

Здравствуйте, landerhigh, Вы писали:

L>Тебе прямо говорят — я лично застал именно это в двух конторах. "Там", естественно.
L>В одну из них, которая наняла непонятно кого делать дот ком себе

Учу читать:

Студенты когда за обеды работали — то это не в продакшен, а когда-то пилили что-то для использования по-месту.

В переводе на русский — начальство не уверено в том, что это им вообще надо, но выделить немного денег на эксперименты не проч.
Когда что-то действительно надо — там сценарии всегда другие.


L>и ожидаемо пролетела, ушлые дельцы загнали аналог Rational Rose как вундерфавлю.

Так "за обеды" или задорого?


V>>Взять Rational Rose, Together — это не полноценные САПР, т.к. не в состоянии автоматизировать создание конечного продукта.
V>>Это утилиты для архитекторов ПО.
L>А попытка генерации кода из оных — это для кого?

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

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

Дя примера, в строительных САПР ты можешь накидать общую "схему" строения, допустим.
Тут стена, тут колонна, тут перекрытие, тут балка.
Но затем ты можешь задать балке профиль — нарисовать уникальный или взять библиотечный.
Задать материалы ядра и отделки (в т.ч. "пирог" утепления и т.д.) элементов.
Использовать получившуюся конструкцию в рассчётах статической нагрузки, теплопотерь, сопротивления ветру и т.д., т.е. запускать симуляцию эксплуатации.

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

В электронных САПР задаются номиналы элементов из справочника или ручками любые уникальные, опять можно посмотреть на работу будущего изделия в симуляции.
Да и вообще, автоматическая разводка. Пусть не идеальная, но примерно 90% разводки используется разведённой автоматом, остальное разводится ручками. Причём, чем точнее задашь классы/ограничения сигнальных шин, тем меньше надо будет дорабатывать автоматическую разводку.

В этом смысле программистские недо-САПР типа Rational Rose и Together позволяли строить разве что, скажем, "проволочную модель", которая прозрачна и статична, не обладает параметрами или свойствами, не допускает симуляции работы, т.е. примерно бесполезна.


L>>>Были даже очень платные курсы по UML.
V>>UML более про ООП, при чём тут бум доткомов?
L>А что, дотком — это только веб? У меня для тебя новости.

Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но.


L>>>Случалось, что не знающим, что означает ромбик в начале стрелочки, на собеседовании презрительно кидали "мы вам перезвоним".
V>>Тогдашние многие айтишники не проходили ООП в ВУЗ-ах, поэтому, осваивать эту парадигму самостоятельно было необходимо, ес-но.
L>Не надо всех по себе судить, ладно?

Я сужу не по себе, а по всем окружающим ровесникам, при том, что я был из "молодой" обоймы во второй половине 90-х — тот самый вчерашний студент.
ООП включили в программы ВУЗ-ов для 3-го курса моей специальности в год, когда я ВУЗ заканчивал.


L>ООП уже к концу 90-х был тем еще баяном.

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

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


V>>А что, сложно потратить пол-часа и запомнить, что означают символы UML? ))
L>Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей.

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


L>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram.

Диаграммы состояний были изобретены за пол-века или более до UML. ))

Разве ты не проходил их в ВУЗ-е?

UML — это, скорее, попытка разработать единую нотацию.
Но попытка вышла неудачной, т.к. нотации получились независимыми, поэтому САПР на основе ограничений UML априори не могут быть полноценными.
В общем, Гради Буч недоработал, увы.


L>Все остальное — просто набор квадратиков.

Кружочков, ромбиков, трапеций, стрелок и т.д.
Твой пренебрежительный тон должен означать некое превосходство над этим всем? ))


L>>>Я лично застал закономерное увядание оных в двух конторах.
V>>Оных чего?
L>Учу читать. Дорого (с)

Учись.

Здравствуйте, Shmj, Вы писали:

S>

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

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

Только видео с откровениями Морковки нам тут и не хватало.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Shmj, Вы писали:

S>Ваше мнение?
Я за low-compile-code. Поясню. Вот есть некий сложный объект, на котором установлена некоторая система автоматизации чего-то там. В какой-то момент было модно сложную конфигурацию делать на C#. И вот ты сидишь на объекте, к тебе прибегают взмыленные сотрудники заказчика с выпученными глазами: "Нужно вот это, аааааа, срочнаааа". Ты понимаешь, что для того, чтобы удовлетворить пожелания заказчика тебе нужно всего лишь поменять у одного параметра 5 на 6 и всё. Но, чтобы поменять, тебе нужно открыть MSVS, подгрузить сольюшен, нугетовские пакеты, поменять одну цифру, скомпилировать и обновить dll-ки. Только вот на площадке заказчика нет ни студии ни сольюшена, вообще из IDE только notepad.exe. Ну и чего делать? Завонишь в свою же поддержку, где сидит индус, которого наняли вчера, он проект видит первый раз в жизни, пытаешься ему полдня объяснить что нужно сделать, он чего-то делает, присылает, оказывется, что это не то, и он ни хрена не понял. И простая операция растягивается на несколько дней.

Я тут, конечно же, поутрировал на счет одной цифры, в реальности всё немного сложнее. Но это основная причина любви ко всяким js, поскольку они позволяют допилить продукт на месте, в смысле оперативно поставить костыль. Не надо рассказывать про ошибки архитетруы, "да кто же настройки компилирует", "бэд практис", и прочее. Есть что есть, и что характерно в копроративном софте так всегда и будет. Вообще я заметил, что приживаются и активно используются те системы, которые позволяют пользователям быстро наколбасить залепуху с костылями и имеют различные бэкдоры, чтобы сделать что-нибудь в обход регламента. Да, это очень небезопасно, но это может стать киллер-фичей в реальности (киллер-фичей во всех смыслах ). И тут, конечно, подход с low-code направлен на удовлетворение потребностей пользователей в создании залепух по месту в процессе работы, но более безопасно, ну чтобы игряясь с ружьем не отстрелили себе чего-нибудь. Но и в этом случае у пользователей рано и поздно возникнет подребность, не покрытая low-code'ом, и они полезут искать бэкдоры И найдут ведь.

Здравствуйте, Dym On, Вы писали:

DO>Я за low-compile-code. Поясню. Вот есть некий сложный объект, на котором установлена некоторая система автоматизации чего-то там. В какой-то момент было модно сложную конфигурацию делать на C#. И вот ты сидишь на объекте, к тебе прибегают взмыленные сотрудники заказчика с выпученными глазами: "Нужно вот это, аааааа, срочнаааа". Ты понимаешь, что для того, чтобы удовлетворить пожелания заказчика тебе нужно всего лишь поменять у одного параметра 5 на 6 и всё. Но, чтобы поменять, тебе нужно открыть MSVS, подгрузить сольюшен, нугетовские пакеты, поменять одну цифру, скомпилировать и обновить dll-ки. Только вот на площадке заказчика нет ни студии ни сольюшена, вообще из IDE только notepad.exe. Ну и чего делать? Завонишь в свою же поддержку, где сидит индус, которого наняли вчера, он проект видит первый раз в жизни, пытаешься ему полдня объяснить что нужно сделать, он чего-то делает, присылает, оказывется, что это не то, и он ни хрена не понял. И простая операция растягивается на несколько дней.

Воот. Первое разумное сообщение в топике с пониманием, что что такое low code/no code в реальности и зачем оно нужно.