Тоже читал сегодня. Как раз хотел обсудить. По-моему:
а) Тренд явно имеет место. Никто уже не хочет в стопицотый раз заказывать разработку, спрос на no-code платформы налицо.
б) По ссылке люди как-то... излишне прямолинейно (скажем вежливо) подходят к вопросу. Типа, а вот возьмём инструменты для разрабов, упростим их для предела, насыплем побольше визивига и диаграмм, и из инструментов для разработчиков вылепим инструменты для юзеров. Нет. Таким макаром можно разве что из хороших инструментов для разработчика получить плохие инструменты для разработчика. Как бы сравнить, чтоб понятно было... ну, типа, как в старину люди пытались автоматизировать шитьё, изготавливая андроидов / роборуку с иглой. Но ни у кого ничего не вышло, а вышло у тех, кто сконструировал швейную машину. Так и тут. Они упёрлись в идею алгоритма и пытаются дать возможность его записать какими-то P-схемами. Попутно критикуя традиционные схемы (они, мол, уступают ЯП). Но ровно то же самое можно сказать и про сами P-схемы: ЯП тупо лучше для записи алгоритмов. Тут нужен совершенно другой подход. Как говорят ТРИЗовцы: идеально, когда объекта нет, а выполняемая работа есть. Не надо грузить пользователя алгоритмами. Алгоритмы неявно должны выполняться. Допустим, юзер формулу записывает в Экселе — он разве думает, что там какой-то алгоритм под капотом? Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас. Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига». Вот они-то эту нишу — no-code/low-code — и займут.
Do you want to develop an app?
Re: Опять поднимают про low-code и помоечку для средняков...
1. Есть сегмент, который не готов платить за полноценную разработку, просто никак. К примеру начинающий бизнес, у которого нет денег. Для них всё просто — или они делают себе решение на какой-то платформе, или у них вообще ничего нет. И тут ограничения не так важны, люди под них подстроятся.
2. Предварительная версия, которую можно показать потенциальному заказчику, получить какой-то фидбэк, может быть финансирование и потом уже спокойно написать как положено.
А вообще, думаю, принципиально ничего не мешает low code подходу применяться и в более сложных проектах. Просто нужна грамотная архитектура и реализация.
Re: Опять поднимают про low-code и помоечку для средняков...
В 100500 раз — попытка натянуть неправильное решение на несуществующую проблему.
Самый лучший способ противодействия дуракам — предоставить им возможность самим отстрелить себе ногу.
P.S. Вот и выросло поколение, которое не застало Rational Rose
Re[2]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, landerhigh, Вы писали:
L>P.S. Вот и выросло поколение, которое не застало Rational Rose
Ну вот застал, приблизительно на стыке веков, помню на основе UML это чудо на выходе генерило (для популярных языков) классы и "пустые" методы, которые потом надо было естественно реализовывать. Помогала эта хрень только т.н. архитекторам, чтобы самим поменьше диаграмок рисовать для всякой отчетности. Естественно долго это безобразие просуществовать не могло, в той конторе, буквально и полугода не продержалось.
Контора кстати жива, и у них из всего пакета Rational, до сих пор используется ClearCase (система управления версиями).
А тут говорят, про программирование без кода (привет Дракону). Нет, рябата так дело не пойдет, сухим из воды не выйдешь.
Re: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, 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
Это именно программирование, описание алгоритма.
Аналогичные системы есть не только для графики, есть для цифровой обработки звуков, а оно потенциально обобщается до цифровой обработки любых сигналов и т.д.
Здравствуйте, Михaил, Вы писали:
S>>Ваше мнение?
М>А чем код плох, если вкратце?
GUI-инструменты для не-посвящённых использовать проще. Пока есть готовые блоки, из которых собирается программа. Вот когда блоки заканчиваются, тут уже сложности и тут No code инструмент должен давать возможность создать этот самый блок настоящему программисту.
Т.е. к примеру ты создаёшь задачу по расписанию, запускать каждые 5 минут. Заходишь в эту задачу, создаёшь там действие "сделать поиск на авито по заданным параметрам". Создаёшь алгоритм для обработки результатов этого поиска: для каждого найденного объявления проверить, находилось ли оно ранее. Если не находилось, добавить в список найденных ранее и отправить SMS на такой-то номер. Всё, парсер авито для конкретной задачи готов. Делается за час. А каждый конкретный блок это уже условно сложная задача, но их можно переиспользовать, например купить в местном магазине. Каждый шаг делается через GUI, везде будут подсказки, не нужно читать никакой документации, весь алгоритм виден, как блок-схема.
Через код это можно сделать на каком-нибудь пайтоне, если каждый блок уже написан в виде библиотеки, но всё равно для этого нужно знать пайтон. Так получается, что людей, которые не знают пайтон, но могут разобраться в адекватном GUI-интерфейсе, значительно больше, чем людей, которые знают пайтон. Т.е. стоит их труд значительно дешевле.
Здравствуйте, 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 и помоечку для средняков...
Здравствуйте, 4058, Вы писали:
4>Ну вот застал, приблизительно на стыке веков, помню на основе UML это чудо на выходе генерило (для популярных языков) классы и "пустые" методы, которые потом надо было естественно реализовывать. Помогала эта хрень только т.н. архитекторам, чтобы самим поменьше диаграмок рисовать для всякой отчетности. Естественно долго это безобразие просуществовать не могло, в той конторе, буквально и полугода не продержалось.
Ну так подавалось это все под соусом "дорогие программисты не нужны, посадил секретутку накидывать квадратиков, нанял студента за обеды, чтобы их заполнить, и в продакшен". Но что-то пошло не так (c)
4>Контора кстати жива, и у них из всего пакета Rational, до сих пор используется ClearCase (система управления версиями).
Мое имхо — оно существует исключительно для откатов.
Re[4]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, landerhigh, Вы писали:
L>Ну так подавалось это все под соусом "дорогие программисты не нужны, посадил секретутку накидывать квадратиков, нанял студента за обеды, чтобы их заполнить, и в продакшен". Но что-то пошло не так (c)
Еще там был отдельный фетиш, это распечатывать большие (и абсолютно бесполезные) диаграммы на листах формата A1, обвешивать ими полу-стеклянные комнаты, и вот вся эта бригада паразитов в виде аналитиков/архитекторов с натужными попытками создать умный вид периодически позировала перед ними. Жаль тогда фотоаппаратов не было в каждом телефоне.
Кстати место происшествия — Москва 2001/2-й год.
И конечно там был Document-ум, без него ведь, подобные мероприятия не обходятся … Тоже хотели, без приличных знаний в области БД, чтобы по визуальным описаниям дальше как-то “всё само”.
4>>Контора кстати жива, и у них из всего пакета Rational, до сих пор используется ClearCase (система управления версиями).
L>Мое имхо — оно существует исключительно для откатов.
В общем-то да, плюс создание видимости какой-то активности, а то руководство не понимает чего там делают программисты, а тут хоть заумными диаграммами можно пол здания обвешать при этом не написав ни строчки кода.
Ну а что касается ClearCase, то это единственный внятный продукт (по очевидным причинам), ибо банальная СУВ и почти ничего лишнего.
Re: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Shtole, Вы писали:
S>Представьте себе таблицу. Но не таблицу «Тебе, дебилушка!», как в Excel. Во-первых, её колонки типизированы, а во-вторых имеют имена. О да, это требует указать типы (число, строка, дата, флаг, ссылка) и немыслимо напрячься, вбивая имена колонок. Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа. Простой бухгалтер может из такого инструмента сделать «2B:Платёжные документы», с любыми печатными образцами, не написав ни одной строчки кода и не задумываясь ни об одном алгоритме. И P-схемы ему не нужны. И редактор форм. Причём, с моей стороны я вообще не знаю ни о геометрии документа для печати, ни о прикладном смысле строк и таблиц.
Это случайно не MS Access?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, 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-х.
Т.е., когда-то быстрые эти процессы сегодня растягиваются на много-много лет.
Здравствуйте, 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 — возможно, перебор. Но совершенно незачем по дефолту отображать его во всех представлениях, чем грешат даже самые лучшие продукты в этой области. Что юзер должен с этой колонкой делать? Она же чисто техническая! И нужна, как правило, для стыковки с другими системами. Но совать её в интерфейс на самом первом (то есть, самом дорогом) месте — извините.
Здравствуйте, 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 минуты, там ничего лишнего. ))
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. В любом случае существует некий мастер форм, где отмечаются поля, которые юзверь желает видеть на форме или в таблице.
Здравствуйте, Shtole, Вы писали:
S>Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас. Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига». Вот они-то эту нишу — no-code/low-code — и займут.
Я заметил, что и no-code системы, где можно задавать логику программы какими-то иными (возможно визуальными) средствами — даже они требуют квалификации человека.
Вы удивитесь, не каждый в состоянии ими пользоваться. Даже просто понять. Не говоря о том, чтобы тщательно и качественно делать эту самую логику. Чтобы и багов не было, и чтобы всё элегантно было.
Да, это не программный код. Но тем не менее, оказывается что и no-code сложны для обывателя.
Re[7]: Опять поднимают про low-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. Зачем нужен мастер форм? Если уж использовать мастер вообще (а не инспектор свойств, например), то это должен быть мастер представлений.
4>И конечно там был Document-ум, без него ведь, подобные мероприятия не обходятся … Тоже хотели, без приличных знаний в области БД, чтобы по визуальным описаниям дальше как-то “всё само”.
у компаннии GBS Group был продукт для визуального составления SQL запросов и создания БД
все работало более менее, естественно пока база была не большая
Re[8]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, 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>Пользователь — это же не программист, у которого отобрали клавиатуру и оставили одну мышку, и не однорукий бандит.
И что теперь?
Так и продолжать забивать гвозди микроскопом?
А нам точно компьютер для того дан, чтобы в миллионый раз ручками набивать вот это позорище полувековой давности:
вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями?
Или придумать, ну не знаю, формат текста специфичный и редактор к нему, чтобы после поля ставишь ->, выскакивает попап с выбором другой таблицы или интиллисенс, начинаешь вводить, ентер/пробел/таб, в тексте остаётся как-то так: 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 имеешь в виду?
Re[4]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, vdimas, Вы писали:
V>No-code не для дураков, факт. V>Но и не для программистов-профессионалов. V>Это для профессионалов в других предметных областях.
Как бы это означает, что радикально нехватку кадров no-code средства решить не помогут. Хотя, может и снизят какой-то накал дефицита.
Re[6]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, AleksandrN, Вы писали:
V>>А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно. V>>Многие такие менеджеры еще позволяют графически конструировать запросы.
AN>Ты Query By Example имеешь в виду?
Здравствуйте, jamesq, Вы писали:
V>>No-code не для дураков, факт. V>>Но и не для программистов-профессионалов. V>>Это для профессионалов в других предметных областях. J>Как бы это означает, что радикально нехватку кадров no-code средства решить не помогут.
Откуда там нехватка кадров?
Радикальная нехватка как раз в кодинге.
В том числе из-за того, что программисты кодируют то, что не должны.
Ждите новых витков увеличения ЗП...
А оно тормозит развитие IT, как ни крути...
Re[2]: Опять поднимают про low-code и помоечку для средняков...
vsb>А вообще, думаю, принципиально ничего не мешает low code подходу применяться и в более сложных проектах. Просто нужна грамотная архитектура и реализация.
Ну то есть прекрасно работает, надо только правильно пользоваться. Ага, ага.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Re[9]: Опять поднимают про 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>вместо того чтобы мышкой за пол-секунды протянуть связь м/у сущностями? 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>Оценочные суждения тем уместней, чем меньше информации, но всегда ли ты способен отличить ситуацию, где информации мало у всех, то бишь мало объективно, от той ситуации, где инфы мало конкретно у тебя, потому что еще зеленый?
Э-э? А какие подробности к делу не относятся? Моё поколение ещё учили, не знаю, как последующие, что полезно на конкретных примерах обсуждать, а не клеить ярлыки. Поэтому я и беру конкретные примеры.
Do you want to develop an app?
Re[5]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, vdimas, Вы писали:
L>>Ну так подавалось это все под соусом "дорогие программисты не нужны, посадил секретутку накидывать квадратиков, нанял студента за обеды, чтобы их заполнить, и в продакшен". Но что-то пошло не так (c) V>Не помню такого.
А значит, и не было, да.
V>Любые САПР отродясь подаются как ср-во повышения производительности профессионалов, а не как ср-во сделать безработных дураков умными.
В начале 2000 у нас что было?
Правильно, дот-ком бум.
Россию он, по большому счету, обошел, но "там" такие вундервафли именно на излете оного и расцвели. Лохам можно было впарить что угодно.
Были даже очень платные курсы по UML. Случалось, что не знающим, что означает ромбик в начале стрелочки, на собеседовании презрительно кидали "мы вам перезвоним".
Я лично застал закономерное увядание оных в двух конторах.
Re[3]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Аноним931, Вы писали:
vsb>>А вообще, думаю, принципиально ничего не мешает low code подходу применяться и в более сложных проектах. Просто нужна грамотная архитектура и реализация.
А>Ну то есть прекрасно работает, надо только правильно пользоваться. Ага, ага.
Не вижу никаких принципиальных причин, по которым оно бы не могло работать.
Re[6]: Опять поднимают про 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>Я лично застал закономерное увядание оных в двух конторах.
Оных чего?
Re[7]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, 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>Оных чего?
Учу читать. Дорого (с)
Re[8]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, 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 априори не могут быть полноценными.
В общем, Гради Буч недоработал, увы.
L>Все остальное — просто набор квадратиков.
Кружочков, ромбиков, трапеций, стрелок и т.д.
Твой пренебрежительный тон должен означать некое превосходство над этим всем? ))
L>>>Я лично застал закономерное увядание оных в двух конторах. V>>Оных чего? L>Учу читать. Дорого (с)
Здравствуйте, Shmj, Вы писали:
S>Ваше мнение?
Я за low-compile-code. Поясню. Вот есть некий сложный объект, на котором установлена некоторая система автоматизации чего-то там. В какой-то момент было модно сложную конфигурацию делать на C#. И вот ты сидишь на объекте, к тебе прибегают взмыленные сотрудники заказчика с выпученными глазами: "Нужно вот это, аааааа, срочнаааа". Ты понимаешь, что для того, чтобы удовлетворить пожелания заказчика тебе нужно всего лишь поменять у одного параметра 5 на 6 и всё. Но, чтобы поменять, тебе нужно открыть MSVS, подгрузить сольюшен, нугетовские пакеты, поменять одну цифру, скомпилировать и обновить dll-ки. Только вот на площадке заказчика нет ни студии ни сольюшена, вообще из IDE только notepad.exe. Ну и чего делать? Завонишь в свою же поддержку, где сидит индус, которого наняли вчера, он проект видит первый раз в жизни, пытаешься ему полдня объяснить что нужно сделать, он чего-то делает, присылает, оказывется, что это не то, и он ни хрена не понял. И простая операция растягивается на несколько дней.
Я тут, конечно же, поутрировал на счет одной цифры, в реальности всё немного сложнее. Но это основная причина любви ко всяким js, поскольку они позволяют допилить продукт на месте, в смысле оперативно поставить костыль. Не надо рассказывать про ошибки архитетруы, "да кто же настройки компилирует", "бэд практис", и прочее. Есть что есть, и что характерно в копроративном софте так всегда и будет. Вообще я заметил, что приживаются и активно используются те системы, которые позволяют пользователям быстро наколбасить залепуху с костылями и имеют различные бэкдоры, чтобы сделать что-нибудь в обход регламента. Да, это очень небезопасно, но это может стать киллер-фичей в реальности (киллер-фичей во всех смыслах ). И тут, конечно, подход с low-code направлен на удовлетворение потребностей пользователей в создании залепух по месту в процессе работы, но более безопасно, ну чтобы игряясь с ружьем не отстрелили себе чего-нибудь. Но и в этом случае у пользователей рано и поздно возникнет подребность, не покрытая low-code'ом, и они полезут искать бэкдоры И найдут ведь.
Счастье — это Glück!
Re[2]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Dym On, Вы писали:
DO>Я за low-compile-code. Поясню. Вот есть некий сложный объект, на котором установлена некоторая система автоматизации чего-то там. В какой-то момент было модно сложную конфигурацию делать на C#. И вот ты сидишь на объекте, к тебе прибегают взмыленные сотрудники заказчика с выпученными глазами: "Нужно вот это, аааааа, срочнаааа". Ты понимаешь, что для того, чтобы удовлетворить пожелания заказчика тебе нужно всего лишь поменять у одного параметра 5 на 6 и всё. Но, чтобы поменять, тебе нужно открыть MSVS, подгрузить сольюшен, нугетовские пакеты, поменять одну цифру, скомпилировать и обновить dll-ки. Только вот на площадке заказчика нет ни студии ни сольюшена, вообще из IDE только notepad.exe. Ну и чего делать? Завонишь в свою же поддержку, где сидит индус, которого наняли вчера, он проект видит первый раз в жизни, пытаешься ему полдня объяснить что нужно сделать, он чего-то делает, присылает, оказывется, что это не то, и он ни хрена не понял. И простая операция растягивается на несколько дней.
Воот. Первое разумное сообщение в топике с пониманием, что что такое low code/no code в реальности и зачем оно нужно.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: Опять поднимают про low-code и помоечку для средняков
Себя поучи.
V>В переводе на русский — начальство не уверено в том, что это им вообще надо, но выделить немного денег на эксперименты не проч. V>Когда что-то действительно надо — там сценарии всегда другие.
Еще раз, тебе из первых рук говорят — была куча контор, которым было действительно надо. Кто-то ниасилил заплатить нормлальным разрабам, кого-то развели ушлые говоруны ртом, кому-то разработчиков просто не хватило.
L>>и ожидаемо пролетела, ушлые дельцы загнали аналог Rational Rose как вундерфавлю. V>Так "за обеды" или задорого?
Учу читать. Дорого.
V>Т.е., если бы эти утилиты позволяли, например, связать метод статической диаграммы с блок-схемой алгоритма или с параметризируемым шаблоном проектирования (из GoF или кучи еще библиотечных), позволял бы запускать это всё на симуляцию, задавая/играя параметрами алгоритмов — это был бы полноценный САПР. V>А так нет.
Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП, а реализация изначально автоматизирована компиляторами. То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы.
Короче, для кода САПР — это IDE со всеми плюшками.
V>В этом смысле программистские недо-САПР типа Rational Rose и Together позволяли строить разве что, скажем, "проволочную модель", которая прозрачна и статична, не обладает параметрами или свойствами, не допускает симуляции работы, т.е. примерно бесполезна.
Не примерно, а не просто бесполезна, но еще и вредна.
L>>А что, дотком — это только веб? У меня для тебя новости. V>Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но.
Иногда нужно и дальше википедии читать.
Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем.
L>>Не надо всех по себе судить, ладно? V>Я сужу не по себе, а по всем окружающим ровесникам, при том, что я был из "молодой" обоймы во второй половине 90-х — тот самый вчерашний студент. V>ООП включили в программы ВУЗ-ов для 3-го курса моей специальности в год, когда я ВУЗ заканчивал.
Да, а еще в вузах преподавали иностранные языки. С известно каким результатом.
V>Если джава, плюсы, дельфи — то да. V>И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг...
Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил
V>>>А что, сложно потратить пол-часа и запомнить, что означают символы UML? )) L>>Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей. V>Это называет "эрудиция".
Некоторые и умение "ботать по фене" эрудицией называют.
Нет смысла запоминать изначально ущербную вымученную нотацию. Ее и читать-то порой с экрана или распечатки невозможно — поди разбери это открытая стелочка, или закрытая, но не заштрихованная.
V>Она "выстреливает" не на конкретной "бессмысленной сущности", а на большом комплексе их, экономя специалисту время в каждой мелочи, встречающейся по работе.
L>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram. V>Разве ты не проходил их в ВУЗ-е?
Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?
V>Кружочков, ромбиков, трапеций, стрелок и т.д. V>Твой пренебрежительный тон должен означать некое превосходство над этим всем? ))
Не некое, а подавляющее.
Диаргамма должна быть понятна всем без исключения участникам процесса. Поэтому ты либо учишься делать визуализацию, которая понятна и заказчикам, и твоей команде, либо всю жизнь "учишь UML нотацию".
Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".
Re[10]: Опять поднимают про low-code и помоечку для средняко
Здравствуйте, landerhigh, Вы писали:
V>>Т.е., если бы эти утилиты позволяли, например, связать метод статической диаграммы с блок-схемой алгоритма или с параметризируемым шаблоном проектирования (из GoF или кучи еще библиотечных), позволял бы запускать это всё на симуляцию, задавая/играя параметрами алгоритмов — это был бы полноценный САПР. V>>А так нет. L>Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП а реализация изначально автоматизирована компиляторами.
Забавная ахинея в стиле Шарикова. ))
Изачально ведь был автокод.
Это и был "технический проект"?
А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.
В общем, коллега, еще не изобрели смайлика, чтобы выразить реакцию на подобные "окровения". ))
L>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы.
Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое.
Тут речь, скорее, о глубине иерархий сущностей проектирования, без проблем воспринимаемых человеком.
По моим наблюдениям, до глубины иерархии слоёв проектирования примерно 3 человек более-менее справляется.
Относительно алгоритмов — примерно до 7 шагов воспринимается на ура, а если больше — уже не помешает "подсказка" в том или ином виде.
Т.е., когда больше/глубже — начинаются сложности с восприятием.
Поэтому, графические представления никогда из программирования не уйдут.
И не важно, по какой нотации они выполнены.
Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде.
Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось.
Туда же псевдокод для обяснения сущности применённых "трюков".
Всё вместе резко помогло.
Реальная практика.
L>Короче, для кода САПР — это IDE со всеми плюшками.
Современные IDE не отвечают определению САПР.
Это, скорее, продвинутые текстовые редакторы исходного кода вкупе с органайзером проектов.
Я как раз рядом в обсуждениях упоминал неоднократно, что современные софтовые САПР растут из пресловутых "конструкторов сайтов".
Просто м/у простейшими конструкторами сайтов а-ля нулевые и некоторыми нынешними уже пропасть, уже ближе к берегу САПР.
V>>В этом смысле программистские недо-САПР типа Rational Rose и Together позволяли строить разве что, скажем, "проволочную модель", которая прозрачна и статична, не обладает параметрами или свойствами, не допускает симуляции работы, т.е. примерно бесполезна. L>Не примерно, а не просто бесполезна, но еще и вредна.
В нашем деле вредна лишь категоричность и прочие проявления узости ума.
L>>>А что, дотком — это только веб? У меня для тебя новости. V>>Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но. L>Иногда нужно и дальше википедии читать. L>Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем.
Увы для тебя, бум автоматизации не совпал с бумом доткомов — он начался примерно на 7 лет раньше.
И не был надутым пузырём — развитие ср-в автоматизации было поступательным.
Наверно ты имеешь ввиду, что во время бума доткомов многие участники слишком много надежд возложили на ср-ва автоматизации?
Но только это никак не повлияло на скорость развития этих ср-в.
Во времена бума доткомов много на что возложили надежд, не только на UML.
Основные надежды были:
— на быстрое продолжение развитие всемирной сети;
— на продолжение развития быстродействия компьютеров в духе 90-х;
— на продолжение развития интереса к интернету у населения со скоростью, показанной в период 95-2000-й год.
Все три пункта вошли в насыщение в начале 2000-х.
— cетка оказалась для населения дорогой и медленной.
— компьютеры резко замедлили рост быстродействия;
— даже чудовищные инвестиции в доткомы оказались не способны удовлетворить любопытство населения относительно новой технологии — т.е. развитие информационного и операционного наполнения Сети отставало от роста любопытства людей, что в итоге любопытство случилось, считай, однократным.
Но инвестиции в технологии донета не пропали даже с кризисом доткомов.
Пропали инвестиции в некоторые конкретные проекты — ну это такое...
Тут по класике надо понимать во что инвестируешь — в технологию, или в обезъянок, способных лишь использовать технологии, разработанные другими людьми.
Ну и, кризис не отменил доткомов и даже не замедлил развитие сети, но заставил более разборчиво подходить к инвестированию в этой области.
V>>Если джава, плюсы, дельфи — то да. V>>И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг... L>Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил
Но без махровых ООП-иерархий наследования — читай внимательней.
Если ты про таблицу ф-ий драйверов ОС или плагинов в некоторой прикладной системе — это тот самый компонентный подход, т.е. абстракция одного уровня.
Туда же OLE/ActiveX.
V>>>>А что, сложно потратить пол-часа и запомнить, что означают символы UML? )) L>>>Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей. V>>Это называет "эрудиция". L>Некоторые и умение "ботать по фене" эрудицией называют.
Угу, тоже порой помогает понять собеседника.
L>Нет смысла запоминать изначально ущербную вымученную нотацию.
"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так.
Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного.
И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.
Я для случая писательства не помню всех тонкостей UML, ес-но, но когда пришлось пару раз поупражняться — открыл описание нотации, открыл примеры, нарисовал за 15 мин.
Всё, вопрос исчерпан.
L>>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram. V>>Разве ты не проходил их в ВУЗ-е? L>Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?
Резьба по цитатам — это способ юления такой или как понимать?
Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности.
Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости.
V>>Кружочков, ромбиков, трапеций, стрелок и т.д. V>>Твой пренебрежительный тон должен означать некое превосходство над этим всем? L>Не некое, а подавляющее.
Пока что ты подзалетел в обсуждении несколько раз, так шта, назовём это как оно и называется — самомнением.
L>Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".
Да ладно, многие коллеги прекрасно читают без словаря.
Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. ))
В UML примерно так же, как и в любой другой области.
Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их.
Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п.
Здравствуйте, vdimas, Вы писали:
L>>Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП а реализация изначально автоматизирована компиляторами. V>Забавная ахинея в стиле Шарикова. ))
От Швондера слышу!
V>Изачально ведь был автокод. V>Это и был "технический проект"? V>А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.
И? Они до сих пор оба используются. Кое-где.
Только какое они имеют отношение к осбуждаемой теме?
L>>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы. V>Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое.
Совершенно верно. И в большинстве случаев — совершенно бессмысленно.
V>Тут речь, скорее, о глубине иерархий сущностей проектирования, без проблем воспринимаемых человеком. V>По моим наблюдениям, до глубины иерархии слоёв проектирования примерно 3 человек более-менее справляется. V>Относительно алгоритмов — примерно до 7 шагов воспринимается на ура, а если больше — уже не помешает "подсказка" в том или ином виде. V>Т.е., когда больше/глубже — начинаются сложности с восприятием.
Если разработчику при работе над конкретным модулем нужно держать в голове 7 уровенй иерархий проектирования, то вы проектируете что-то не то. Или не так. Или все вместе.
V>Поэтому, графические представления никогда из программирования не уйдут. V>И не важно, по какой нотации они выполнены.
Натравливаешь на код doxygen, он рисует достаточное графическое представление.
V>Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде. V>Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось.
Так согласно одной довольно известной догме программирования, это означает, что код — говно-с
А если серьезно, то никаких проблем в комментариях описать диаграмму поведения модуля на языке plantuml, и доксиген тебе ее интегрирует прямо в документашку.
V>Туда же псевдокод для обяснения сущности применённых "трюков".
А не надо применять "трюки".
L>>Короче, для кода САПР — это IDE со всеми плюшками. V>САПР в программировании — это примерно такое:
Ага, вот именно вот так и продавались аналоги RR в начале нулевых. Как пылесосы Кирби.
L>>Не примерно, а не просто бесполезна, но еще и вредна.
V>В нашем деле вредна лишь категоричность и прочие проявления узости ума.
Категоричность?
Софтовые конторы сейчас рисуют подробные UML модели примерно... ээ, да никогда.
Затраты времени на их построение себя не оправдывают.
Вот набросать квадратиков за 15 минут — да.
L>>Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем. V>Увы для тебя, бум автоматизации не совпал с бумом доткомов — он начался примерно на 7 лет раньше.
Увы, но ты опять не умеешь читать.
L>>Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил V>Но без махровых ООП-иерархий наследования — читай внимательней.
Махровые ООП иерархии — это такой же карго-культ, как и любая другая дичь.
V>>>Это называет "эрудиция". L>>Некоторые и умение "ботать по фене" эрудицией называют. V>Угу, тоже порой помогает понять собеседника.
Чтобы понять, что с "собеседником" беседы не получится, не обязательно обладать такой "эрудицией".
L>>Нет смысла запоминать изначально ущербную вымученную нотацию. V>"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так. V>Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного. V>И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.
Иными словами — это лишняя сущность. Вымученная. О чем я тебе и говорю.
V>Я для случая писательства не помню всех тонкостей UML, ес-но, но когда пришлось пару раз поупражняться — открыл описание нотации, открыл примеры, нарисовал за 15 мин. V>Всё, вопрос исчерпан.
Ага. No Hire
L>>>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram. V>>>Разве ты не проходил их в ВУЗ-е? L>>Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?
V>Как-то странно ты скипнул часть вопроса: V>Резьба по цитатам — это способ юления такой или как понимать?
Если ты собрался брать меня на слабо, то ты опоздал на сорок лет.
Конечные автоматы — моя любимая фишка в принципе. Наличие state diagram в любом UML редакторе лично мне помогает вбивать в голову юным падаванам правильные инженерные практики.
V>Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности. V>Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости.
Пока что только ты показываешь узость кругозора и приписываине собеседнику своих домыслов.
L>>Не некое, а подавляющее. V>Пока что ты подзалетел в обсуждении несколько раз, так шта, назовём это как оно и называется — самомнением.
Скажем так, оно довольно обоснованное. В отличие от.
L>>Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".
V>Да ладно, многие коллеги прекрасно читают без словаря.
А ты сам?
V>Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. ))
И чтобы на этот уровень выйти, нужно на языке общаться, читать и писать. А не пытаться запомнить синтетические правила, натужно натягиваемые на живой язык.
V>В UML примерно так же, как и в любой другой области. V>Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их. V>Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п.
Какая-то у тебя каша в голове, честное слово.
Re: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Dym On, Вы писали:
DO>Здравствуйте, Shmj, Вы писали:
S>>Ваше мнение? DO>Я за low-compile-code. Поясню. Вот есть некий сложный объект, на котором установлена некоторая система автоматизации чего-то там. В какой-то момент было модно сложную конфигурацию делать на C#. И вот ты сидишь на объекте, к тебе прибегают взмыленные сотрудники заказчика с выпученными глазами: "Нужно вот это, аааааа, срочнаааа". Ты понимаешь, что для того, чтобы удовлетворить пожелания заказчика тебе нужно всего лишь поменять у одного параметра 5 на 6 и всё. Но, чтобы поменять, тебе нужно открыть MSVS, подгрузить сольюшен, нугетовские пакеты, поменять одну цифру, скомпилировать и обновить dll-ки. Только вот на площадке заказчика нет ни студии ни сольюшена, вообще из IDE только notepad.exe. Ну и чего делать? Завонишь в свою же поддержку, где сидит индус, которого наняли вчера, он проект видит первый раз в жизни, пытаешься ему полдня объяснить что нужно сделать, он чего-то делает, присылает, оказывется, что это не то, и он ни хрена не понял. И простая операция растягивается на несколько дней.
Вот в этом смысле офигенно работают just-in-time вещи типа того же PHP. В целом, понятное дело, PHP — отстой, но вот что в нём круто — так это как раз возможность открыть проект прямо в проде прямо при помощи хоть vi, хоть notepad.exe и поправить его на лету.
Если мы берём ту же идею и переносим её на нормальную реализацию, получаем JSP, где у нас, фактически, конвеер зависимостей *.jsp -> *.java -> *.class -> x64.
То есть сочетаем преимущества скриптанины с преимуществами статики.
Примерно то же, на пару десятков лет моложе, имеем в виде ASP.NET.
Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений. Copy-deployment и source-level-edit — это ж то, что доктор прописал, и в очень многих сценариях.
Ну, понятно, что десктопному приложению заменять на лету определение класса не с руки — что делать с состоянием? А вот для каких-нибудь workflow движков это было бы очень даже к месту.
Я вот сейчас отлаживаю коннектор для PowerBI, и волшебным образом оказывается, что можно прямо в десктопном приложении безо всякого перезапуска переподкладывать dll. То есть я внёс изменения -> перекомпилировал -> скопировал в папочку Documents/Power BI Desktop/Custom Connectors — и всё, достаточно нажать Refresh, чтобы данные перезакачались через новую версию коннектора.
Если выкинуть из этой технологической цепочки Visual Studio и Power Query SDK, то всё станет ещё лучше — почему бы мне не править просто исходник коннектора, чтобы powerbi сам его пересобирал при необходимости?
Тем более, что сборка там занимает миллисекунды.
То, что это работает, естественно, построено на statelessness коннектора. Нет никаких объектов "устаревших классов", которые нужно как-то перетащить из старой версии в новую.
Имхо, в эту сторону и надо копать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Sinclair, Вы писали:
S>Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений.
Так для этого делают скриптовые интерфейсы, разве нет? Autocad, Photoshop, Wireshark — все они содержат в себе интерпретатор, который позволяет оперировать примитивами на уровне пользователя. Разве этого мало?
Игры так вообще сценарии всегда на скриптах делали (luajit на них и поднялась).
Re[4]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Nuzhny, Вы писали: N>Так для этого делают скриптовые интерфейсы, разве нет? Autocad, Photoshop, Wireshark — все они содержат в себе интерпретатор, который позволяет оперировать примитивами на уровне пользователя. Разве этого мало?
Да, пожалуй, вы правы. О них я как-то не подумал. N>Игры так вообще сценарии всегда на скриптах делали (luajit на них и поднялась).
С играми я достаточно слабо знаком. Полагаю, что скрипты там делали вовсе не потому, что хотелось править ошибки прямо на машине пользователя.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Sinclair, Вы писали:
S>Вот в этом смысле офигенно работают just-in-time вещи типа того же PHP. В целом, понятное дело, PHP — отстой, но вот что в нём круто — так это как раз возможность открыть проект прямо в проде прямо при помощи хоть vi, хоть notepad.exe и поправить его на лету.
То ли у вас очень странный прод, то ли ты забываешь про то что нод с рнр файлами обычно больше одной.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Sinclair, Вы писали:
S>Вот в этом смысле офигенно работают just-in-time вещи типа того же PHP. В целом, понятное дело, PHP — отстой, но вот что в нём круто — так это как раз возможность открыть проект прямо в проде прямо при помощи хоть vi, хоть notepad.exe и поправить его на лету.
Тем удивительнее желание некоторых накрутить поверх JIT старый добрый конвеер. (Вы, конечно, понимаете, о ком я). Компиляция в этом случае отлавливает ну настолько тривиальные ошибки, что за 2 года работы над достаточно сложным (назовём его так) JIT-проектом ни одна не пролезла через защитный барьер автотестов (в виде исключения «метод не найден» или чего-то вроде). При этом я регулярно сталкивался с прессингом смежных сиплюсплюсников, которым мозолило глаза отсутствие привычных вещей: этапа сборки, CMake или чего-то вроде, киловаттов на билд-сервере и т.д., и которые регулярно предлагали зачем-то («Для безопасности!». «От кого? От фашистов, что ли?») прикрутить язык, компилируемый в JIT-язык.
Я выдвинул два простых соображения:
1. У нас в управляемых средах (а именно на них крутятся JIT-языки) таких ошибок, как у вас, вообще не бывает. Когда вы вчетвером мозговые штурмы по полгода устраиваете, чтобы просто понять, где была прострелена нога. У нас ошибки другие, и компиляцией они ловятся именно что малоэффективно. Статистика саппорта/фидбека подтверждает.
2. Конвеер не бесплатен. Скорость быстрого реагирования — а с ней багофикса, внедрения, латания дыр, обхаживания клиентов и тому подобных вещей из жизни реальных проектов — снизится на порядок.
Второе соображение было услышано не очень хорошо. Когда люди носят вериги, они перестают замечать неудобства.
Мантра-оберег: в целом, понятное дело, Ecmascript — отстой, но...
S>Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений. Copy-deployment и source-level-edit — это ж то, что доктор прописал, и в очень многих сценариях.
Вредители, сэр. Ну, или дело в дотком-буме, может? Когда быстрое реагирование впервые стало по-настоящему быстрым, без этих вот «5.0, 6.0», разделяемых годами.
За пределами веба я на эту тему таких чудес насмотрелся. В одном случае нужны были скрипты для управления промышленным оборудованием. Парни хотели взять готовый движок — на тот момент, если не ошибаюсь, для этих целей актуален был Tcl — но им не дали. Тогда они сели колхозить свой (!!!), с кучей багов, кривой, ни с чем не совместимый урод, и это прошло на ура. Так я потом имел приватный разговор с европейским дилером, который сказал, что и за этот-то колхоз будет вечно за них бога молить — хоть как-то жить можно! Отдельный прикол в том, что другую часть проекта так и оставили на плюсах. Благодаря этому было создано отдельное рабочее место (позже — второе), получено одно повышение, оплачена куча перелётов по всему миру — всё это только потому, что дилер (сотрудник той же компании! финансово — все в одной лодке!) не мог, работая с промоборудованием, доступиться до него не через голову программистов. Кто ж от такого откажется.
А вообще, хоть это и казалось на уровне подкорки очевидным, давайте считать ценным вкладом в тему: low-code из формулы no-code/low-code должен быть JIT/managed.
Do you want to develop an app?
Re[4]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Nuzhny, Вы писали:
S>>Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений. N>Так для этого делают скриптовые интерфейсы, разве нет? Autocad, Photoshop, Wireshark — все они содержат в себе интерпретатор, который позволяет оперировать примитивами на уровне пользователя. Разве этого мало?
Ой, это капля в море. Как в смысле ассортимента, так и реализации. Если бы это было развито на уровне веб-приложений, было бы ядро с операциями, на которое можно натягивать любые наборы кнопок. Такое только MSO на моей памяти разрешал, да и то через три ... колено.
N>Игры так вообще сценарии всегда на скриптах делали (luajit на них и поднялась).
Осталось понять, что общего у ворона и письменного стола. В смысле, у игр и веб-приложений, которые в этом смысле действительно похожи.
Do you want to develop an app?
Re[4]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Nuzhny, Вы писали: S>>Несколько удивительно наблюдать полное отсутствие аналогов за пределами веб-приложений. N>Так для этого делают скриптовые интерфейсы, разве нет?
Ага. И эти вещи можно было делать еще 20 лет назад
Здравствуйте, Shtole, Вы писали:
S>Ой, это капля в море. Как в смысле ассортимента, так и реализации. Если бы это было развито на уровне веб-приложений, было бы ядро с операциями, на которое можно натягивать любые наборы кнопок. Такое только MSO на моей памяти разрешал
Как минимум в упомянутом Автокаде тоже самое.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, Shtole, Вы писали:
S>Представьте себе таблицу. Но не таблицу «Тебе, дебилушка!», как в Excel. Во-первых, её колонки типизированы, а во-вторых имеют имена. О да, это требует указать типы (число, строка, дата, флаг, ссылка) и немыслимо напрячься, вбивая имена колонок. Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ
По сути, Access получится.
Sapienti sat!
Re[2]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Dym On, Вы писали:
DO>Здравствуйте, Shmj, Вы писали:
S>>Ваше мнение? DO>Я за low-compile-code. Поясню. Вот есть некий сложный объект, на котором установлена некоторая система автоматизации чего-то там. В какой-то момент было модно сложную конфигурацию делать на C#. И вот ты сидишь на объекте, к тебе прибегают взмыленные сотрудники заказчика с выпученными глазами: "Нужно вот это, аааааа, срочнаааа". Ты понимаешь, что для того, чтобы удовлетворить пожелания заказчика тебе нужно всего лишь поменять у одного параметра 5 на 6 и всё. Но, чтобы поменять, тебе нужно открыть MSVS, подгрузить сольюшен, нугетовские пакеты, поменять одну цифру, скомпилировать и обновить dll-ки. Только вот на площадке заказчика нет ни студии ни сольюшена, вообще из IDE только notepad.exe.
А рабочий ноутбук на проходной отобрали? А когда следующее обновление заказчику будете ставить — там этот фикс учтется?
Может все-таки над деплойментом немного поработать чтобы он был автоматизированее и желания лезть руками на прод не возникало.
Re[3]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, Константин Б., Вы писали:
КБ>А рабочий ноутбук на проходной отобрали? А когда следующее обновление заказчику будете ставить — там этот фикс учтется? КБ>Может все-таки над деплойментом немного поработать чтобы он был автоматизированее и желания лезть руками на прод не возникало.
На прошлой работе на проходной даже сотовые телефоны и флешки просили сдавать. Чтобы пронести ноутбук — это надо у замминистра разрешение оформлять пару недель и не факт, что дадут. Пару раз было такое, что распаковывал jar, менял там в конфиге значение и запаковывал взад. Или на месте компилировал нужный файл и менял class-файл. Потому, что по уму делать — несколько дней минимум на все согласования, это неприемлемо. Потом в следующем обновлении, конечно, уже по уму было сделано.
Но всё же это особая особенность заказчика, думаю, такое редко встречается.
Здравствуйте, landerhigh, Вы писали:
V>>Изачально ведь был автокод. V>>Это и был "технический проект"? V>>А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый. L>И? Они до сих пор оба используются. Кое-где.
Дык, они и тогда использовались "кое-где", а основное сложное ПО, про которое можно было сказать, что это ПО имеет архитектуру — оно писалось на автокоде.
Повторяю вопрос: автокод — это и был "технический проект"?
L>Только какое они имеют отношение к осбуждаемой теме?
Это демонстрация изрекаемой тобой чуши.
"Технический проект" начинал свою жизнь задолго до реализации его на автокоде.
Т.е. на бумаге, будучи представлен графикой и словесным описанием.
L>>>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы. V>>Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое. L>Совершенно верно. И в большинстве случаев — совершенно бессмысленно.
Большинство написанного кода тоже выкидывается.
Хотя бы в процессе его улучшения/переписывания.
Означает ли это, что код не надо писать вовсе? ))
L>Если разработчику при работе над конкретным модулем нужно держать в голове 7 уровенй иерархий проектирования
Семь было про шаги алгоритма.
Да, бывают такие алгоритмы, в которые лучше подсматривать при их кодировании.
И таких алгоритмов большинство из тех, которые можно назвать хоть сколько-нибудь полезными, т.е. делающими хоть что-то требуемое в современном мире, начиная от работы планировщиков ОС, до мультимедии и сетевых протоколов.
L>то вы проектируете что-то не то. Или не так. Или все вместе.
Или ты сталкивался только с простейшими вещами по работе.
V>>Поэтому, графические представления никогда из программирования не уйдут. V>>И не важно, по какой нотации они выполнены. L>Натравливаешь на код doxygen, он рисует достаточное графическое представление.
))
V>>Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде. V>>Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось. L>Так согласно одной довольно известной догме программирования, это означает, что код — говно-с
С таким подходом для тебя любой код говно-с, который чуть сложнее 2+2.
Чтобы понимать код, в первую очередь надо понимать, что именно он делает.
И вот код делает что-то нетривиальное — без предварительного понимания закодированных процессов смотреть в код бесполезно.
L>А если серьезно, то никаких проблем в комментариях описать диаграмму поведения модуля на языке plantuml, и доксиген тебе ее интегрирует прямо в документашку.
Диаграмма поведения на ём толком не описывалась и сегодня имеет ряд ограничений.
Например, мне надо несколько стартовых точек и несколько конечных.
И эта диаграмма описывает поведение системы из примерно десятка объектов.
В комментари к какому из них мне нарисовать диаграмму их общей многопоточной активности?
Правильный ответ — ни к какому, оно будет жить отдельно от каждого из участвующих объектов, как и есть сейчас.
V>>Туда же псевдокод для обяснения сущности применённых "трюков". L>А не надо применять "трюки".
Бгг, "трюки" нужны для кодирования даже банального JPG (БПФ).
L>>>Короче, для кода САПР — это IDE со всеми плюшками. V>>САПР в программировании — это примерно такое: L>Ага, вот именно вот так и продавались аналоги RR в начале нулевых. Как пылесосы Кирби.
Да там один вменяемый был аналог.
L>Категоричность? L>Софтовые конторы сейчас рисуют подробные UML модели примерно... ээ, да никогда.
"Подробные" — это стадия торговли.
Или таки абсолютно никогда?
Если последнее — сразу ха-ха три раза.
Это в наколенных конторах не рисуют, где ничего сложного и не разрабатывают.
L>Затраты времени на их построение себя не оправдывают. L>Вот набросать квадратиков за 15 минут — да.
Оно примерно столько времени и требует.
Пусть иногда чуть больше, чем 15 минут, а даже около часа на некую подробную sequence-диаграмму, но оно потом экономит многие человекодни.
L>>>Нет смысла запоминать изначально ущербную вымученную нотацию. V>>"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так. V>>Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного. V>>И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна. L>Иными словами — это лишняя сущность. Вымученная. О чем я тебе и говорю.
Твоё "говорю" означает "раздавать оценочные суждения", т.е. суждения нулевой полезности. ))
L>Если ты собрался брать меня на слабо, то ты опоздал на сорок лет. L>Конечные автоматы — моя любимая фишка в принципе. Наличие state diagram в любом UML редакторе лично мне помогает вбивать в голову юным падаванам правильные инженерные практики.
Но state diagram однопоточна.
Что делать в случае трёх и более взаимодействующих потоков?
Неужели надо брать другой вид диаграммы?
V>>Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности. V>>Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости. L>Пока что только ты показываешь узость кругозора и приписываине собеседнику своих домыслов.
Пока что мне просто весело от такой незамутнённости.
V>>Да ладно, многие коллеги прекрасно читают без словаря. L>А ты сам?
Длиннее в любом случае.
V>>Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. )) L>И чтобы на этот уровень выйти, нужно на языке общаться, читать и писать.
Отож.
V>>В UML примерно так же, как и в любой другой области. V>>Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их. V>>Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п. L>Какая-то у тебя каша в голове, честное слово.
Да там сразу было понятно, что тебе ничего не понятно.
State-диаграмм ему достаточно.
Ну ОК, с этого надо было начинать. ))
Здравствуйте, vdimas, Вы писали:
V>И таких алгоритмов большинство из тех, которые можно назвать хоть сколько-нибудь полезными, т.е. делающими хоть что-то требуемое в современном мире, начиная от работы планировщиков ОС, до мультимедии и сетевых протоколов.
Назови хоть один. Не подлядывая в вики.
V>Но state diagram однопоточна. V>Что делать в случае трёх и более взаимодействующих потоков?
Ты изобретаешь многопоточный конечный автомат?
У меня для тебя плохие новости.
V>Неужели надо брать другой вид диаграммы?
Боюсь, не поможет.
Re: Опять поднимают про low-code и помоечку для средняков...
Строители "программируют" BIM–объекты мышкой. В игровых проектах умеренной сложности рулит Unreal'овские Blueprints. У промавтоматчиков, наверное, до сих пор жив MЭK 61131. В экспериментальном секторе промоборудования вполне основательно себя чувствует LabView, завязанный не на алгоритмы, а на диаграммы потоков данных. RF–алгоритмы тоже, я видел, стало модно накидывать виртуальными кубиками-проводами с крутилками. Аналитики прутся от Tableau. И т.д. и т.п.
Единственная проблема — всемогутор общего назначения таким путём не создать. Только нишевые решения, без всяких шагов влево-вправо. Связано это и с нехваткой выразительных средств nocode/lowcode. И с лютeйшим ростом когнитивной сложности графического представления — на сложных сценариях классический текст программы становится понятнее.
Re: Опять поднимают про low-code и помоечку для средняков...
low-code/no-code нужны для начала для GUI. Реализовать UI максимально полно, и предоставлять пользователю максимальную гибкость для настройки.
Чтобы не надеяться, что разработчик догадается — что нужно пользователю.
Например Visual Studio — чего там только нет, но очень нужного для меня там нет. В Solution Explorer, для перехода к проекту(когда их много), хочется не скроллировать все дерево:
— Либо как в редакторе кода — сверху combo box с проектами, при выборе перепрыгивает на нужный проект.
— Либо двойное окно. В главном видны только проекты, в дочернем содержимое выбранного проекта.
— Или другие стандартные известные трюки навигации по деревьям.
Хотя для этого есть workaround: Tab control для открытых документов закрепить слева, а не сверху. Настроить чтобы открытые документы группировались в проекты, и открыть из каждого проекта по одному документу — тогда можно быстро прыгать по проектам.
Но это тоже криво. И почему-то в этом окне при клике на проект(заголовок группы) ничего не делается — логично было бы перепрыгивать к проекту в Solution Explorer. И не помешала бы опция — показывать в нем проект, даже если в нем нет открытых документов.
Прогресс есть — движение к полноте в UI. Раньше даже tab control нельзя было закрепить слева. Но до идеального результата еще далеко.
P.S. low-code/no-code для начала нужна полнота, в базовой части.
Здравствуйте, landerhigh, Вы писали:
V>>И таких алгоритмов большинство из тех, которые можно назвать хоть сколько-нибудь полезными, т.е. делающими хоть что-то требуемое в современном мире, начиная от работы планировщиков ОС, до мультимедии и сетевых протоколов. L>Назови хоть один. Не подлядывая в вики.
Один алгоритм планировщика? Мультимедии? Сетевого протокола? ))
Я назвал те области, которыми занимался ранее и/или продолжаю заниматься сейчас.
V>>Но state diagram однопоточна. V>>Что делать в случае трёх и более взаимодействующих потоков? L>Ты изобретаешь многопоточный конечный автомат?
Я стебался над "такой-то одной диаграммы достаточно".
А над этим новым вопросом в такой забавной формулировке даже стебаться облом, бо чушь смешна поначалу, но потом приедается.
). И тут, конечно, подход с low-code направлен на удовлетворение потребностей пользователей в создании залепух по месту в процессе работы, но более безопасно, ну чтобы игряясь с ружьем не отстрелили себе чего-нибудь. Но и в этом случае у пользователей рано и поздно возникнет подребность, не покрытая low-code'ом, и они полезут искать бэкдоры 
