Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 11.09.19 17:43
Оценка:
Вот пример:

  Скрытый текст


Отсюда: http://yukosoft.ru/default.aspx


Немного перекликается с этой темой
Автор: Shmj
Дата: 19.08.19
.

Суть очевидна — для данных создать формы редактирования/отображения. Ну здесь и сами таблицы можно создать из редактора — и все это счастье занимает на диске менее 10 Мб.

Подобная идея у 1С + там еще и свой недоязык.

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

Но это все проприетарные и не пригодные для внедрения решения. Хотелось бы опенсорсного и пригодного для создания своих прог. Ну и Web-версия чтобы была.

Неужели никто ничего не придумал?
Re: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 11.09.19 18:35
Оценка: +2
Здравствуйте, Shmj, Вы писали:

S>Суть очевидна — для данных создать формы редактирования/отображения.

S>Неужели никто ничего не придумал?

Никому не нужен дебильный инструмент для дебильных задач. Если у тебя есть данные, у тебя 100% есть ЛОГИКА над этими данными. Просто вшлёпывать записи в таблицу — таких тупых задач попросту не существует. Поэтому руками пишут красивые формы с правильным порядком полей, красивым выравниванием, валидацией, хелперами и т.п.
В конце концов, наклепать формы — невелика задача, делается не приходя в сознание (как раз после обеда, когда думать лень). А главная работа — на сервере, где много всякой логики и алгоритмов.
Re[2]: MS делают видео вместо статей - где разум?
От: Shmj Ниоткуда  
Дата: 12.09.19 06:36
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Если у тебя есть данные, у тебя 100% есть ЛОГИКА над этими данными.


Для примера — см. программы чувака: http://yukosoft.ru/Programs.aspx

Типовые бизнес-задачи — внесение структурированных данных, совместный к ним доступ средствами СУБД (MS SQL, к примеру).

Логики там не так много и она уже дописывается руками. А остальное конфигурируется в конструкторе — задаете набор полей таблицы и связи. Все это счастье занимает на диске 10 Мб — не нужно скачивать гигабайты студии и разбираться как создавать сложные проекты.

K>Просто вшлёпывать записи в таблицу — таких тупых задач попросту не существует.


См. пример выше. Как раз 90% бизнес-задач — это вшлепывание данных в таблицу с распределенным доступом. Проверка доступа — так же конфигурируется — это типовая задача. Проверка валидности даных — задается на уровне СУБД.

K>Поэтому руками пишут красивые формы с правильным порядком полей, красивым выравниванием, валидацией, хелперами и т.п.


Валидация на основе ограничений СУБД. Для выравнивания в конкретно этих прогах — есть встроенный редактор — можно задавать свойства каждого элемента управления. Хотя по сути это не так важно — главное чтобы порядок полей был задан и они были просто выровнены — а отступы для всех типовые.

K>В конце концов, наклепать формы — невелика задача, делается не приходя в сознание (как раз после обеда, когда думать лень). А главная работа — на сервере, где много всякой логики и алгоритмов.


Может и не велика, но когда форма вот такая:



т.е. когда есть 6 других таблиц, связанных с данной — то представьте сколько времени уйдет на создание такой формы. Нужен не только просмотр, но и добавление/редактирование данных. Вручную забембаешься поля вводить — даже если по 1 мин. на каждое — уже дня 2 уйдет.

Вот вы бы за сколько времени создали такую форму вручную? Притом что форма должна не просто быть, но еще и связана с данными — с 7 разными таблицами + еще словари (около 10). Путем конфигурации это делается максимум за час. Сколько у тебя уйдет на ручное написание?
Отредактировано 12.09.2019 6:44 Shmj . Предыдущая версия .
Re: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 06:55
Оценка:
Здравствуйте, Shmj, Вы писали:

S>А впервые столкнулся с этим на первой работе — там чувак единолично написал такую среду а потом долгие годы коллектив ее конфигурировал. Ядро за эти годы почти не изменилось, а вот конфигурация для бухгалтерии настолько обросла, что уже никто не мог в ней разобраться.


Основная проблема таких решений, что вместо использования популярных сред и языков, приходится писать конфигурации в доморощенных дизайнерах и на птичьих языках. И рано или поздно возникает необходимость в глубоком изучении данной системы, и от "простоты" не остается и следа.
Re[2]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 07:00
Оценка:
Здравствуйте, amironov79, Вы писали:

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


Ну почему? У нас чувак сделал всю логику на MS SQL. Т.е. создается форма в редакторе, задается поля. И автоматом в базе создаются процедуры для нее — для заполения, сохранения и пр.

Т.е. стандарт — MS SQL как язык бизнес-логики.

А вот формы — в особой красивости не нуждаются — это же бизнес, там на рюшечки не смотрят. Ну да, логотип конфигурировался, порядок полей конфигурировался. Остальное не суть важно.
Re[3]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 07:19
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Ну почему? У нас чувак сделал всю логику на MS SQL. Т.е. создается форма в редакторе, задается поля. И автоматом в базе создаются процедуры для нее — для заполения, сохранения и пр.

S>Т.е. стандарт — MS SQL как язык бизнес-логики.

Они сразу с бизнес-логикой создаются? Или просто обертки для CRUD? А если часть логики должна отработать на клиенте?

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


Ага, когда потребуется "неважное" остальное, мы говорим, что наши средства разработки это не поддерживают?
Re: Многие делают - но каждый свой велосипед
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.19 07:40
Оценка:
Здравствуйте, Shmj, Вы писали:
S>Подобная идея у 1С + там еще и свой недоязык.

Идея 1С это типовые конфы и главное Бухгалтерия с учетом нашего законодательства.
Ну и франчайзи. Никто в здравом уме не будет делать учет в доморощенных системах учета.
Это лишние деньги. Проще взять персонал уже обученный для работы и допилить типовоые конфы под свои требования
Единственно можно делать какие ни будь Вэб формы или служебные программы, но с чтением,записью в 1С через Вэб или ХТТП сервисы
и солнце б утром не вставало, когда бы не было меня
Re[2]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 07:56
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Идея 1С это типовые конфы и главное Бухгалтерия с учетом нашего законодательства.

S>Ну и франчайзи. Никто в здравом уме не будет делать учет в доморощенных системах учета.
S>Это лишние деньги. Проще взять персонал уже обученный для работы и допилить типовоые конфы под свои требования
S> Единственно можно делать какие ни будь Вэб формы или служебные программы, но с чтением,записью в 1С через Вэб или ХТТП сервисы

Вы сейчас о бизнес-модели а я говорю о техническом решении.
Re[4]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 08:07
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Они сразу с бизнес-логикой создаются? Или просто обертки для CRUD?


Создаются обертки, конечно. Но если нужно что-то специфическое — то писаловь вручную. Там столько было написано за эти годы, что было просто страшно смотреть на базу. Таблиц было несколько тысяч, епта. А процедур минимум в 4 раза больше.

A>А если часть логики должна отработать на клиенте?


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

A>Ага, когда потребуется "неважное" остальное, мы говорим, что наши средства разработки это не поддерживают?


Дело в том, что этой прогой реально пользовались многие мелкие и средние бизнесы. Крупных, конечно, не было. Это прошло проверку в реальных условиях.
Re[5]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 09:18
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Дело в том, что этой прогой реально пользовались многие мелкие и средние бизнесы. Крупных, конечно, не было. Это прошло проверку в реальных условиях.


Бизнес пользуется этой системой именно как средой разработки? Конфигурации пишут сами пользователи?
Если же бизнес пользуется только конечными продуктами, то это больше маркетинговый вопрос.
Re: odoo умеет
От: Буравчик Россия  
Дата: 12.09.19 09:30
Оценка: 3 (2)
Здравствуйте, Shmj, Вы писали:

S>Неужели никто ничего не придумал?


odoo такое умеет (на питоне). В РФ редко встречается, пока.

Описываешь данные, кратко описываешь интерфейс (по принципу — это спрячь, это отображай в виде поля, это в виде списка).
Получаешь стандартизованный интерфейс, интеграцию с уже имеющимися формами/данными, возможность кастомизации (лучше, чем в 1С).

Система открытая, сама платформа и некоторые базовые модули — open source, бесплатные.
Плюс куча платных модулей (тоже open source), в т.ч. от других разработчиков.
Best regards, Буравчик
Отредактировано 12.09.2019 9:31 Буравчик . Предыдущая версия .
Re[6]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 10:02
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Бизнес пользуется этой системой именно как средой разработки? Конфигурации пишут сами пользователи?

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

Некоторые клиенты сами конфигурировали, так как там не сложно. Но в осносном платили конторе за доконфигурацию. Базовая версия без спец. конфигурации стоила в пределах средне-месячной зарплаты, спец. конфигурация — 3-5 зарплат.

Клиентов было несколько десятков и появлялись новые.

Т.к. законы все время меняются — то постоянно приходилось что-то добавлять. То отчеты для налоговой переделать (шаблоны) то пр.

Писать с нуля все это был бы ад — там же и фильры одни и те же и уйма полей.
Отредактировано 12.09.2019 10:03 Shmj . Предыдущая версия .
Re[7]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 10:52
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Т.к. законы все время меняются — то постоянно приходилось что-то добавлять. То отчеты для налоговой переделать (шаблоны) то пр.


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

S>Писать с нуля все это был бы ад — там же и фильры одни и те же и уйма полей.


Как процесс разработки выглядит? Как происходит добавление, удаление полей, изменение расположения элементов, отображение информации в зависимости от условий. Как ошибки отлаживаются? Какие чувства испытывает разработчик при работе в этой системе после работы в Visual Studio?
Отредактировано 12.09.2019 11:10 amironov79 . Предыдущая версия .
Re[2]: odoo умеет
От: amironov79  
Дата: 12.09.19 10:59
Оценка:
Здравствуйте, Буравчик, Вы писали:

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


S>>Неужели никто ничего не придумал?


Б>odoo такое умеет (на питоне). В РФ редко встречается, пока.


Сайт не очень информативный, не нашел примеров приложений. Пока выглядит, как ещё один фреймворк.
Re[3]: odoo умеет
От: Буравчик Россия  
Дата: 12.09.19 11:28
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Сайт не очень информативный, не нашел примеров приложений. Пока выглядит, как ещё один фреймворк.


Так это и есть фреймворк — для построения бизнес-приложений.

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

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

В рамках топика как раз то, что нужно — там очень быстро можно перейти от описания данных к готовому интерфейсу. Плюс есть уже готовы модули — клиент, поставщик, договор и т.п. Нет необходимости создавать их заново, достаточно немного изменить их для своих нужд.
Best regards, Буравчик
Re[8]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 12:10
Оценка:
Здравствуйте, amironov79, Вы писали:

S>>Т.к. законы все время меняются — то постоянно приходилось что-то добавлять. То отчеты для налоговой переделать (шаблоны) то пр.

A>Получается эта программа для пользователей ценна поддержкой, а не процессом разработки.

Ну вот смотрите как можно добавить новую таблицу + обвязку к ней:

  Скрытый текст


Сложно?

Добавляете таблицу и получаете типовые форму для просмотра/добавления/редактирования/удаления на основе полей.

А потом в конструкторе можно перенастроить поля, вот сам конструктор:

  Скрытый текст


Некоторые пользователи сами расширяли функционал с помощью подобных конструкторов.

У нас в конторе девелопер был только один — создатель ядра. Меня планировали взять вторым, но было слишком скучно. Остальные скорее конфигураторы, которые всему научились уже там — а именно HTML для шаблонов документов и SQL для логики.

S>>Писать с нуля все это был бы ад — там же и фильры одни и те же и уйма полей.


A>Как процесс разработки выглядит? Как происходит добавление, удаление полей, изменение расположения элементов, отображение информации в зависимости от условий. Как ошибки отлаживаются? Какие чувства испытывает разработчик при работе в этой системе после работы в Visual Studio?


Ок, давайте на конкретном примере. Вот есть форма:

  Скрытый текст


Опишите процесс создания такой формы в VS и сколько времени это у вас займет.

В готовой среде процесс выгядит так:

1. Создаете в редакторе таблиц (таком) словари (2 поля — ID и ключ). Это для модели, производителя и пр., где есть выбор.
2. Создаете в том же редакторе таблицу с полями заказа.
3. Создаете связанные таблицы — Работы, Товары, Комментарии и пр.

После этого получаете готовую форму с набором полей по умолчанию.

Далее в конструкторе группируете поля на форме, меняете порядок и пр.

Максимум 1 час займет создание такой вот формы. Ни одной строчки писать не нужно.

При этом получаете и удобные инструменты для поиска/фильтрации даныных, вот такие:

  Скрытый текст


И еще кучу ништяков по умолчанию (как то возможность менять местами колонки и пр.), о которых вам даже думать не нужно.

Как вы это сделаете в VS и сколько времени займет?
Re[3]: Многие делают - но каждый свой велосипед
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.19 12:53
Оценка:
Здравствуйте, Shmj, Вы писали:

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


S>> Идея 1С это типовые конфы и главное Бухгалтерия с учетом нашего законодательства.

S>>Ну и франчайзи. Никто в здравом уме не будет делать учет в доморощенных системах учета.
S>>Это лишние деньги. Проще взять персонал уже обученный для работы и допилить типовоые конфы под свои требования
S>> Единственно можно делать какие ни будь Вэб формы или служебные программы, но с чтением,записью в 1С через Вэб или ХТТП сервисы

S>Вы сейчас о бизнес-модели а я говорю о техническом решении.


Так то о чем ты говоришь это и есть учетная система. Для других решений не нужны свои редакторы форм и прочее.
Потому, что там дизайнеры уже учитывают текущую модель классов.
Кстати 1С потратили кучу времени и средств на создание Вэб интерфейса, коим практически и не пользуются. Достаточно тонкого клиента.
и солнце б утром не вставало, когда бы не было меня
Re[4]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 13:00
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Так то о чем ты говоришь это и есть учетная система. Для других решений не нужны свои редакторы форм и прочее.


Как не нужны? Практически весь корп. софт это имеет в основе — таблицы и работа с ними.

Тот же MS Lightswitch был призван решить эту проблему, но помер вмсте с Silverlight, на основе которого был создан.
Re[9]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 13:10
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Ок, давайте на конкретном примере. Вот есть форма:

S>Image: 8.png
S>Опишите процесс создания такой формы в VS и сколько времени это у вас займет.

1. Накидываешь на форму контейнеры, гриды, другие контролы.
2. Описываешь классы для данных.
3. Связываешь контролы с данными.
4. Пишешь запросы для работы с таблицей, связываешь их с событиями выборки и сохранения данных.
5. На каждый фильтр создаешь набор контролов и условий, связываешь их с выборкой данных.

S>При этом получаете и удобные инструменты для поиска/фильтрации даныных, вот такие:

S>Image: 16.png
S>И еще кучу ништяков по умолчанию (как то возможность менять местами колонки и пр.), о которых вам даже думать не нужно.

Так энто же DevExpress! И грид и редактор лайотов. Пользователи после таких менюшек часто звонят с вопросом, куда это у нас колонки подевались.

S>Как вы это сделаете в VS и сколько времени займет?


Да, за час не получится. Зато никакой "магии".
Re[5]: Многие делают - но каждый свой велосипед
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.19 13:13
Оценка: +1
Здравствуйте, Shmj, Вы писали:

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


S>> Так то о чем ты говоришь это и есть учетная система. Для других решений не нужны свои редакторы форм и прочее.


S>Как не нужны? Практически весь корп. софт это имеет в основе — таблицы и работа с ними.


S>Тот же MS Lightswitch был призван решить эту проблему, но помер вмсте с Silverlight, на основе которого был создан.

Вот корп и использует 1С. Зачем изобретать велосипед и затем гемороиться с ним?
У MS есть аналоги навижн и дайнамикс. Зачем им конкурентов плодить
и солнце б утром не вставало, когда бы не было меня
Re[10]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 13:14
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Да, за час не получится. Зато никакой "магии".


Ну да, для такой формы уйдет не 1 час а неделя примерно — это в лучшем случае.
Re[11]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 14:48
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Ну да, для такой формы уйдет не 1 час а неделя примерно — это в лучшем случае.


Если рука набита, то что там неделю делать? Максимум 2-3 дня по плану.
Re[12]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 15:00
Оценка:
Здравствуйте, amironov79, Вы писали:

S>>Ну да, для такой формы уйдет не 1 час а неделя примерно — это в лучшем случае.

A>Если рука набита, то что там неделю делать? Максимум 2-3 дня по плану.

Все вы так говорите — а как рельно делать — то в процессе работы сразу забуксуете и начнете искать оправдание, типа не было в Т.З.

В общем, нет смысла тратить 3 дня, когда можно простым конфигурированием сделать за 1 час.

Да и главный принцип — не дублируй себя. Зачем множество раз делать одну и ту же работу, если можно выделить общее и делать просто конфигурируя.
Re[2]: odoo умеет
От: Shmj Ниоткуда  
Дата: 12.09.19 15:06
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>odoo такое умеет (на питоне). В РФ редко встречается, пока.


Оно то хорошо, но хотелось бы .Net решение
Re[6]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 15:07
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Вот корп и использует 1С. Зачем изобретать велосипед и затем гемороиться с ним?


1С неудобен по многим причинам. Хотелось бы .Net

S> У MS есть аналоги навижн и дайнамикс. Зачем им конкурентов плодить




Видимо это и есть основная причина, почему MS зарубили такие перспективные начинания
Отредактировано 12.09.2019 15:07 Shmj . Предыдущая версия .
Re[13]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 15:29
Оценка:
Здравствуйте, Shmj, Вы писали:

S>В общем, нет смысла тратить 3 дня, когда можно простым конфигурированием сделать за 1 час.


Час потратите только на формы, а на логику теже несколько дней и уйдет. А сколько потратите на отладку, когда основной разработчик внесет неисправимые улучшения?

S>Да и главный принцип — не дублируй себя. Зачем множество раз делать одну и ту же работу, если можно выделить общее и делать просто конфигурируя.


Не думали, что если это массово не используется, значит, это не работает?
Re[14]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 15:32
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Час потратите только на формы, а на логику теже несколько дней и уйдет. А сколько потратите на отладку, когда основной разработчик внесет неисправимые улучшения?


А какая логика в этих формах?

S>>Да и главный принцип — не дублируй себя. Зачем множество раз делать одну и ту же работу, если можно выделить общее и делать просто конфигурируя.

A>Не думали, что если это массово не используется, значит, это не работает?

Это как раз массово используют, но шибко шальные деньги крутятся в этой сфере. У MS есть продукты для бизнеса, построенные по данному принципу. Собственно — все начинания пытаются уничтожить на корню, чтобы не плодить конкурентов.
Re[15]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 16:14
Оценка:
Здравствуйте, Shmj, Вы писали:

S>А какая логика в этих формах?


Ну я вот вижу кнопки "Изменить статус", "Закрыть заказ", "Поменять скидку". Думаю, за этим скрывается нечто большее, чем изменение значения поля.

A>>Не думали, что если это массово не используется, значит, это не работает?


S>Это как раз массово используют, но шибко шальные деньги крутятся в этой сфере. У MS есть продукты для бизнеса, построенные по данному принципу. Собственно — все начинания пытаются уничтожить на корню, чтобы не плодить конкурентов.


Примеры проприетарных технологий, которые сильно облегчают разработку? Примеры уничтоженных технологий? А то какой-то мировой заговор получается, прямо Индиана Джонс: В поисках серебряной пули.
Re: Многие делают - но каждый свой велосипед
От: ltc  
Дата: 12.09.19 16:52
Оценка: :)
Здравствуйте, Shmj, Вы писали:

S>Немного перекликается с этой темой
Автор: Shmj
Дата: 19.08.19
.


S>Суть очевидна — для данных создать формы редактирования/отображения. Ну здесь и сами таблицы можно создать из редактора — и все это счастье занимает на диске менее 10 Мб.


S>Но это все проприетарные и не пригодные для внедрения решения. Хотелось бы опенсорсного и пригодного для создания своих прог. Ну и Web-версия чтобы была.


S>Неужели никто ничего не придумал?


Вручную клепать такие формы — просто унижение человеческого достоинства, большей частью совершенно тупая работа.
Раз тупая — надо автоматизировать. По моему мнению, если у нас есть класс с всеми прописанными контрактами (предусловия, постусловия, инварианты), то нет ничего невозможного, чтобы сгенерировать функционально рабочую форму для редактирования сущности этого класса. Можно добавить аттрибутов для задания порядка вывода, тайтла и тому подобного (как в скаффолдинге ASP.NET). А красоту, если надо, пусть дизайнер потом прикручивает стилями или чем ещё. Причем по одной и той же модели можно потенциально генерить код хоть для веба, хоть для десктопа, хоть куда. Почему такого до сих пор нет — не знаю.
Re[16]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 17:20
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Ну я вот вижу кнопки "Изменить статус", "Закрыть заказ", "Поменять скидку". Думаю, за этим скрывается нечто большее, чем изменение значения поля.


Нет, по сути это просто инструмент для распределенного доступа к структурированным данным.

Если даже и есть типа логика, что "закрыть заказ" — учитывает сумму заказа в отчете — то это 5% от основного.

S>>Это как раз массово используют, но шибко шальные деньги крутятся в этой сфере. У MS есть продукты для бизнеса, построенные по данному принципу. Собственно — все начинания пытаются уничтожить на корню, чтобы не плодить конкурентов.


A>Примеры проприетарных технологий, которые сильно облегчают разработку? Примеры уничтоженных технологий? А то какой-то мировой заговор получается, прямо Индиана Джонс: В поисках серебряной пули.


Проприетарные от MS — MS Dynamics.

Примеры уничтоженных — MS Lightswitch и ASP.Net Dynamic Data. Уничтожили, чтобы не плодить конкурентов.

Вообще мне сразу понятно насколько данная технология облегчает работу — фактически можно выкинуть большую часть полупрофи. Т.е. тех, кто кроме формоклепания и простых запросов особо ничего не умеют — на помоечку. Но, благо, пока данная технология доступна только для крупного бизнеса за миллиарды, а все что для мелкого — наколенная поделка.
Re[2]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 17:23
Оценка:
Здравствуйте, ltc, Вы писали:

ltc>Почему такого до сих пор нет — не знаю.


Уже разобрались — оказывается это есть в виде MS Dynamics, но там шибко шальные деньги и по сути доступно только корпорациям. Все что может составить потенциальную конкуренцию — MS убивает на корню.
Re[17]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 12.09.19 18:08
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Проприетарные от MS — MS Dynamics.


S>Примеры уничтоженных — MS Lightswitch и ASP.Net Dynamic Data. Уничтожили, чтобы не плодить конкурентов.


Может просто не взлетело? И в чем удобство данных технологий? Посмотрел обзорные статьи, не понял, где простота.

S>Вообще мне сразу понятно насколько данная технология облегчает работу — фактически можно выкинуть большую часть полупрофи. Т.е. тех, кто кроме формоклепания и простых запросов особо ничего не умеют — на помоечку. Но, благо, пока данная технология доступна только для крупного бизнеса за миллиарды, а все что для мелкого — наколенная поделка.


Это какой-то хитрый план у внедренцев ms и sap: сделать проект быстро, качественно и дешево, а клиенту отдавать его долго, с багами и задорого.
Re[18]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 12.09.19 18:32
Оценка:
Здравствуйте, amironov79, Вы писали:

S>>Примеры уничтоженных — MS Lightswitch и ASP.Net Dynamic Data. Уничтожили, чтобы не плодить конкурентов.


A>Может просто не взлетело?


Да взлетело бы, если бы не похерили. Много обзорных статей, в т.ч. на русском. Просто не выгодно делиться куском пирога.

A>И в чем удобство данных технологий? Посмотрел обзорные статьи, не понял, где простота.


Удобство в автоматизации — то что обычно делают вручную и на что тратят много времени — делает алгоритм.
Re[19]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 13.09.19 04:46
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Да взлетело бы, если бы не похерили. Много обзорных статей, в т.ч. на русском. Просто не выгодно делиться куском пирога.


Обзорных много, внятных ни одной. Если бы подобные фреймворки были удобны, они бы жили и без поддержки корпораций.

A>>И в чем удобство данных технологий? Посмотрел обзорные статьи, не понял, где простота.


S>Удобство в автоматизации — то что обычно делают вручную и на что тратят много времени — делает алгоритм.


Нет никакого удобства, просто добавляется дополнительный слой, и вместо тупого клепания форм приходится заниматься еще более тупым конфигурированием. Если надо автоматизации, берешь любой шаблонизатор, пишешь генераторы под задачу, и не морочишь себе голову всякими "прорывными" технологиями.
Re[20]: Многие делают - но каждый свой велосипед
От: Буравчик Россия  
Дата: 13.09.19 06:41
Оценка: +1
Здравствуйте, amironov79, Вы писали:

A>Нет никакого удобства, просто добавляется дополнительный слой, и вместо тупого клепания форм приходится заниматься еще более тупым конфигурированием.


Наоборот, конфигурирование — более высокоуровневая работа. При конфигурировании прячется куча рутинной работы по "клепанию" форм и т.п.

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


Зачем тратить время и писать генераторы, если они уже написаны и отлажены в платформе?
Best regards, Буравчик
Re[3]: odoo умеет
От: Буравчик Россия  
Дата: 13.09.19 06:47
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Оно то хорошо, но хотелось бы .Net решение


Уверен, что это требование противоречит другому:

Но это все проприетарные и не пригодные для внедрения решения. Хотелось бы опенсорсного и пригодного для создания своих прог. Ну и Web-версия чтобы была.

Best regards, Буравчик
Re[21]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 13.09.19 07:36
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Наоборот, конфигурирование — более высокоуровневая работа. При конфигурировании прячется куча рутинной работы по "клепанию" форм и т.п.


Куда девается рутина по настройке расположения элементов? По настройке валидаций? По дополнительной обработке данных? Откуда берутся знания, как с этими конфигурациями работать, что можно делать, что нельзя? А возникнуть проблемы, где искать специалиста по кишкам этого конфигуратора?

Б>Зачем тратить время и писать генераторы, если они уже написаны и отлажены в платформе?


Так начальный вопрос, где эти платформы? Нет ответа. Всё одно и тоже, очередные фреймворки, которых уже сотни, если не тысячи.
Re[20]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 13.09.19 07:46
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Нет никакого удобства, просто добавляется дополнительный слой, и вместо тупого клепания форм приходится заниматься еще более тупым конфигурированием.


Конфигурация на порядок проще клепания форм.

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


Так вот это и есть свой велосипед. Написать подобное решение — довольно сложно и работают все они по похожему принципу.
Re[22]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 13.09.19 07:52
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Куда девается рутина по настройке расположения элементов?


Во многих случаях важна только группировка и порядок расположения элементов.

Для тонкой настройки используется визуальный редактор — это не требует написания кода.

A>По настройке валидаций?


Обычно проверки на уровне СУБД или указывают декларативно тип данных.


A>Откуда берутся знания, как с этими конфигурациями работать, что можно делать, что нельзя? А возникнуть проблемы, где искать специалиста по кишкам этого конфигуратора?


Сейчас в основном решения проприетарные — т.е. открытых и доступных для всех — нет. Просто когда создашь свой такой конфигуратор — понимаешь что это золотая жила и ты за час сможешь решать проблемы, на которые бизнес тратит человеко-месяцы. Нет смысла делиться с другими.
Re[7]: Многие делают - но каждый свой велосипед
От: pagid Россия  
Дата: 13.09.19 08:38
Оценка:
Здравствуйте, Shmj, Вы писали:

S>1С неудобен по многим причинам.

Есть другие аналогичные системы. Чем-то более удобные 1С, чем-то менее.

S>Хотелось бы .Net

Зачем?

S>Видимо это и есть основная причина, почему MS зарубили такие перспективные начинания

Что именно они зарубили?
Re[8]: Многие делают - но каждый свой велосипед
От: Буравчик Россия  
Дата: 13.09.19 09:24
Оценка:
Здравствуйте, pagid, Вы писали:

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


S>>1С неудобен по многим причинам.

P>Есть другие аналогичные системы. Чем-то более удобные 1С, чем-то менее.

Какие? Интересуют те, что:
— позволяют описывать структуру данных
— прячут всю логику хранения в БД (на основе структуры данных)
— формируют стандартный интерфейс пользователя (на основе структуры данных)

Кроме 1С я только Odoo знаю.
Best regards, Буравчик
Re[4]: odoo умеет
От: Mr.Delphist  
Дата: 13.09.19 10:28
Оценка:
Здравствуйте, Буравчик, Вы писали:

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


S>>Оно то хорошо, но хотелось бы .Net решение


Б>Уверен, что это требование противоречит другому:

Б>

Но это все проприетарные и не пригодные для внедрения решения. Хотелось бы опенсорсного и пригодного для создания своих прог. Ну и Web-версия чтобы была.


Семейство веб-технологий ASP.Net внезапно тоже .Net
Re[8]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 13.09.19 11:03
Оценка:
Здравствуйте, pagid, Вы писали:

S>>Хотелось бы .Net

P>Зачем?

Потому что работаю с этой технологией много лет.
Re[5]: odoo умеет
От: Shmj Ниоткуда  
Дата: 13.09.19 11:03
Оценка:
Здравствуйте, Mr.Delphist, Вы писали:

MD>Семейство веб-технологий ASP.Net внезапно тоже .Net


.Net (Core) — уже фактически опенсорс.
Re[22]: Многие делают - но каждый свой велосипед
От: Ночной Смотрящий Россия  
Дата: 13.09.19 12:27
Оценка:
Здравствуйте, amironov79, Вы писали:

A>Куда девается рутина по настройке расположения элементов? По настройке валидаций? По дополнительной обработке данных?


Можно нейросетку для этого сбацать, обучив на 100500 существующих учетных систем.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re: Многие делают - но каждый свой велосипед
От: Сергей  
Дата: 13.09.19 13:23
Оценка:
А попробуйте посмотрите на технологию DevExpress XAF:
https://habr.com/ru/company/devexpress/blog/140325/
особенно круто будет, если самостоятельно попробуете сваять любой пробный проектик на нём. Очень многое дает в плане понимания технологий.


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

S>Вот пример:


S>
  Скрытый текст
S>Image: ClientsSales_ClientsSales_ContractCard.jpg

S>Отсюда: http://yukosoft.ru/default.aspx



S>Немного перекликается с этой темой
Автор: Shmj
Дата: 19.08.19
.


S>Суть очевидна — для данных создать формы редактирования/отображения. Ну здесь и сами таблицы можно создать из редактора — и все это счастье занимает на диске менее 10 Мб.


S>Подобная идея у 1С + там еще и свой недоязык.


S>А впервые столкнулся с этим на первой работе — там чувак единолично написал такую среду а потом долгие годы коллектив ее конфигурировал. Ядро за эти годы почти не изменилось, а вот конфигурация для бухгалтерии настолько обросла, что уже никто не мог в ней разобраться.


S>Но это все проприетарные и не пригодные для внедрения решения. Хотелось бы опенсорсного и пригодного для создания своих прог. Ну и Web-версия чтобы была.


S>Неужели никто ничего не придумал?
Re[2]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 13.09.19 13:30
Оценка:
Здравствуйте, Сергей, Вы писали:

С>особенно круто будет, если самостоятельно попробуете сваять любой пробный проектик на нём. Очень многое дает в плане понимания технологий.


В каком смысле "понимания технологий"?
Re[23]: Многие делают - но каждый свой велосипед
От: yukosoft  
Дата: 13.09.19 15:37
Оценка:
Этот конструктор гораздо мощнее и гибче чем может показаться.
Re[22]: Многие делают - но каждый свой велосипед
От: ltc  
Дата: 13.09.19 15:50
Оценка:
Здравствуйте, amironov79, Вы писали:

Б>>Наоборот, конфигурирование — более высокоуровневая работа. При конфигурировании прячется куча рутинной работы по "клепанию" форм и т.п.


A>Куда девается рутина по настройке расположения элементов? По настройке валидаций? По дополнительной обработке данных? Откуда берутся знания, как с этими конфигурациями работать, что можно делать, что нельзя? А возникнуть проблемы, где искать специалиста по кишкам этого конфигуратора?


Порядок элементов задается специальным атрибутом. [DisplayOrder]
Настройка валидаций? В модели на бэкенде уже есть инварианты класса. Транслировать их в валидацию в форме — технически несложная задача.
Re[24]: Многие делают - но каждый свой велосипед
От: Ночной Смотрящий Россия  
Дата: 13.09.19 16:11
Оценка:
Здравствуйте, yukosoft, Вы писали:

Y>Этот конструктор гораздо мощнее и гибче чем может показаться.


Чем мощнее и гибче, тем больше работы при использовании. Голый WPF еще мощнее и гибче.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[25]: Многие делают - но каждый свой велосипед
От: yukosoft  
Дата: 13.09.19 16:52
Оценка: 4 (1)
Конечно везде есть компромисс.
Просто подобное ядро позволяет знать только основы SQL (insert, update, delete) и создавать не только связанные формы и таблицы, но и печатные формы, графики, диаграммы, различные представления графиков работ и расписаний, древовидные категории, и т.д. Так как ядро работает и с локальной Access базой и с MS SQL то процедуры и триггеры создаются в собственной экосистеме.














Но даже если задачи требуют что-то закодить на C# то можно создать простую библиотеку и в ядре вызвать метод этой библиотеки. Можно даже подписаться на событие загрузки любой формы и жанглировать элементами формы и данными в ней уже в коде C#



Всё это позволяет сосредоточиться на бизнес задаче а не на кодинге и уровень специалистов для такой системы не требуется очень высокий и высокооплачиваемый.
Re[3]: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 13.09.19 17:31
Оценка: 45 (2) +4
Здравствуйте, Shmj, Вы писали:

S>Типовые бизнес-задачи — внесение структурированных данных, совместный к ним доступ средствами СУБД (MS SQL, к примеру).

S>Все это счастье занимает на диске 10 Мб — не нужно скачивать гигабайты студии и разбираться как создавать сложные проекты.

Я могу сказать только одно: тупые инструменты не производят умный результат. Если ты думаешь, что "формочки" — это набор полей, ты сильно ошибаешься. Там есть всё, от порядка полей по важности, эстетически красивого расположения, вспомогательных хинтов и хэлперов, до психологии цвета. Чтобы ВСЁ ЭТО учесть в "генераторе форм одной кнопкой", тебе придётся поприседать НЕДЕЛЮ со всеми конфигами и атрибутами, прежде чем увидишь хоть более-менее пристойный результат.

Личный пример: на форме есть поле ввода ДР. Для удобства заполнения других (бумажных!) форм, рядом с полем есть хелпер: показывает полный возраст чела. НИ ОДИН твой конструктор не сделает такое поле! Просто потому, что бестолковый генератор никогда не заменит профессионального "клепателя форм".
Ещё один вариант был: чел вводил адрес. В принципе, ни бог весть какая инфа, но для валидации названий (и вообще для понимания, что адрес — не липовый) я сделал кнопку "Открыть в гугл-мэпс". Налицо задача, которую не просекёт ни один генератор. Потому что сегодня это "гугл-мэпс", а завтра ровно на то же поле адреса кто-то захочет навесить флаг страны. КАК это просекёт конструктор? Да никак, просто пойдёт лесом. ЧИТД.


K>>Поэтому руками пишут красивые формы с правильным порядком полей, красивым выравниванием, валидацией, хелперами и т.п.


S>Валидация на основе ограничений СУБД


Уже видна ограниченность мышления. В СУБД это byte, а на деле — дни недели. ГДЕ И КАК ты пропишешь "валидные значения — от 1 до 7"??
Далеко не всё, что имеет ограничения, легко ложится на язык СУБД или ЯОН — тут нужно прямое вмешательство человека.

S>Для выравнивания в конкретно этих прогах — есть встроенный редактор — можно задавать свойства каждого элемента управления. Хотя по сути это не так важно — главное чтобы порядок полей был задан и они были просто выровнены — а отступы для всех типовые.


Всё ясно. Думаю, не ошибусь, если скажу, что формы, которые ты клепал, были для БД из двух таблиц: Person-Order.
На деле нужно применить всё своё мастерство, чтобы красиво и аккуратно презентовать инфу, не перегружая юзера, не гемороя его скролбарами, комбобоксами, деревьями и прочими контролами-уродами. Увы, "человеческую психологию" в атрибуты не зашьёшь, тут интеллект нужен. Поэтому первый признак лабуха-программера — это его смех над "формошлёпами" — область, где он ни черта не разбирается, но уверен, что всё можно склепать-сгенерить.


S>т.е. когда есть 6 других таблиц, связанных с данной — то представьте сколько времени уйдет на создание такой формы. Нужен не только просмотр, но и добавление/редактирование данных. Вручную забембаешься поля вводить — даже если по 1 мин. на каждое — уже дня 2 уйдет.


Тебя кто-то обманул. Это не "форма", это "свалка полей-гридов-тулбаров", где даже я, программист, не могу отличить одно от другого. Если б мне показали скрин такой программы, выкинул бы её не глядя. Не особо улавливаю, чем тут можно гордиться и зачем ТАКОЕ генерить.

S>Вот вы бы за сколько времени создали такую форму вручную?


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

S> Путем конфигурации это делается максимум за час. Сколько у тебя уйдет на ручное написание?


Вот и я про то: 100 индусячих макак могут вообще склепать форму за 10 минут — эта СПЕШКА того стоит??...
Re[26]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 13.09.19 18:15
Оценка:
Здравствуйте, yukosoft, Вы писали:

Y>Просто подобное ядро позволяет знать только основы SQL (insert, update, delete) и создавать не только связанные формы и таблицы, но и печатные формы, графики, диаграммы, различные представления графиков работ и расписаний, древовидные категории, и т.д. Так как ядро работает и с локальной Access базой и с MS SQL то процедуры и триггеры создаются в собственной экосистеме.


Я так понимаю вы автор? Респект Система достойная.

Ваша разработка использует DevExpress XAF или обходится только их контролами? Не смотрели решение XAF?
Re[4]: MS делают видео вместо статей - где разум?
От: Shmj Ниоткуда  
Дата: 13.09.19 18:32
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Личный пример: на форме есть поле ввода ДР. Для удобства заполнения других (бумажных!) форм, рядом с полем есть хелпер: показывает полный возраст чела. НИ ОДИН твой конструктор не сделает такое поле! Просто потому, что бестолковый генератор никогда не заменит профессионального "клепателя форм".


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

K>Уже видна ограниченность мышления. В СУБД это byte, а на деле — дни недели. ГДЕ И КАК ты пропишешь "валидные значения — от 1 до 7"??

K>Далеко не всё, что имеет ограничения, легко ложится на язык СУБД или ЯОН — тут нужно прямое вмешательство человека.

Есть SQL CHECK Constraint:

Day1 int CHECK (Day1 >=1 AND Day1 <= 7)

K>На деле нужно применить всё своё мастерство, чтобы красиво и аккуратно презентовать инфу, не перегружая юзера, не гемороя его скролбарами, комбобоксами, деревьями и прочими контролами-уродами. Увы, "человеческую психологию" в атрибуты не зашьёшь, тут интеллект нужен. Поэтому первый признак лабуха-программера — это его смех над "формошлёпами" — область, где он ни черта не разбирается, но уверен, что всё можно склепать-сгенерить.


То о чем вы говорите — это сродни искусства. Искусство никогда не перестанет быть актуальным, однако же для большинства нужен просто функционал.

Можно стены дома украсить картинами а можно "автоматически сгенеренными" фотообоями. Для большинства второй вириант доступнее.
Re[4]: MS делают видео вместо статей - где разум?
От: Shmj Ниоткуда  
Дата: 13.09.19 18:42
Оценка:
Здравствуйте, Kolesiki, Вы писали:

K>Вот и я про то: 100 индусячих макак могут вообще склепать форму за 10 минут — эта СПЕШКА того стоит??...


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

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

Как то о таком риске и не думали...

Ну да, сложные алгоритмы она писать не сможет. Однако же их разработчики средней руки и не пишут.

Вот это и задевает — есть риск создания подобной системы и многих ждет судьба первых телефонисток
Re: Многие делают - но каждый свой велосипед
От: bnk СССР http://unmanagedvisio.com/
Дата: 13.09.19 21:14
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Неужели никто ничего не придумал?


DevExpress XAF вполне работает, рекомендую
За несколько дней слепил что-то вполне юзабельное. Внятный UI, вполне внятная кастомизация мышкой.
Немного почитать-посмотреть придется, но от рутины избавляет прямо-таки суперски.
Один и тот же код и для дектоп и для веб клиета. В общем пока я доволен, как слон, спасибо тому кто посоветовал.
В общем DevExpress молодцы.
Re[5]: MS делают видео вместо статей - где разум?
От: yukosoft  
Дата: 13.09.19 21:22
Оценка: 22 (2)
Shmj абсолютно верно пророчит судьбу многих программистов. 1С подобные системы (конструкторы) это только начало. В будущем огромный пласт программистов средней руки исчезнет так же как исчезли радиолюбители времён СССР которые на коленка собирали приёмники и усилители. Будут облачные фреймворки с машинным обучением и программы будут писаться чуть ли не на уровне общения с ИИ: "а теперь добавь поле с датой и назови его [День рождения] и добавь поле ReadOnly где будет выводится возраст на основе дня рождения. Откомпилируй. В продакшин!"

День рождения и возраст делается за 40 секунд:





Нужны ссылки: их может конструктор. Ссылаться можно хоть на сайт хоть на действие пункта меню.




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

Re[3]: MS делают видео вместо статей - где разум?
От: vsb Казахстан  
Дата: 13.09.19 22:25
Оценка: +1
Как раз щас работаю с похожей программой. Написана на дельфи, в исходниках уже лет 10 никто ничего не понимает, пересобрать невозможно. Работает кое-как. Никакие фиксы практически невозможны, под 10-й не запускается. Тоже логика в хранимках оракловых, причём они зачем-то подмножество PL/SQL перевели на русский. Видимо планировали, что это будут писать специалисты. В итоге, конечно, пишут программисты.

Там вообще ситуация патовая. Кучу функционала невозможно реализовать. Что-то реализуется сбоку-припёку, отдельными приложениями, работающими с базой ужасной структуры, что-то просто никак не реализуется. На переписывание всего нужно много десятков миллионов, их нет. Пока переписывают частями, сохраняя убогую структуру базы (Oracle 9i, крутящийся на итаниуме, ололо).

В общем работа с этой системой меня навсегда отвратила от доморощенных билдеров.
Отредактировано 13.09.2019 22:27 vsb . Предыдущая версия . Еще …
Отредактировано 13.09.2019 22:25 vsb . Предыдущая версия .
Re[6]: MS делают видео вместо статей - где разум?
От: Shmj Ниоткуда  
Дата: 14.09.19 07:22
Оценка:
Здравствуйте, yukosoft, Вы писали:

Y>День рождения и возраст делается за 40 секунд:


Правильно ли я понял, что за $500 все эти возможности станут доступны? Или сколько стоит полная версия?

И второй вопрос. Есть ли полная документация? Без наличия документации пользоваться может только автор.

К примеру, для DevExpress XAF есть огромная докуменатция.
Re[23]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 14.09.19 07:41
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Можно нейросетку для этого сбацать, обучив на 100500 существующих учетных систем.


Зачем полумеры? Можно вообще без форм обойтись, пускай нейронка данные сразу в базе генерит.
Re[2]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 14.09.19 07:44
Оценка:
Здравствуйте, bnk, Вы писали:

bnk>Один и тот же код и для дектоп и для веб клиета. В общем пока я доволен, как слон, спасибо тому кто посоветовал.

bnk>В общем DevExpress молодцы.

Пожалуйста, конечно. Но я не советовал, просто сказал, что есть такой фреймворк. Сам бы я его повтроно не стал использовать.
Re[7]: MS делают видео вместо статей - где разум?
От: amironov79  
Дата: 14.09.19 07:48
Оценка:
Здравствуйте, Shmj, Вы писали:

S>К примеру, для DevExpress XAF есть огромная докуменатция.


Документация есть, а что толку? Кто ее будет читать? Вы же всех спецалистов средней руки уже уволили.
Re[3]: Многие делают - но каждый свой велосипед
От: bnk СССР http://unmanagedvisio.com/
Дата: 14.09.19 07:54
Оценка:
Здравствуйте, amironov79, Вы писали:

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


Ты прям пугаешь
Нашел что-то получше? Или у него есть какой-то фатальный недостаток?
Re[4]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 14.09.19 08:27
Оценка:
Здравствуйте, bnk, Вы писали:

bnk>Ты прям пугаешь

bnk>Нашел что-то получше? Или у него есть какой-то фатальный недостаток?

Я его просто не осилил за пределами начального конфигуратора. Когда нужны специфические настройки, я не могу вспомнить, как я делал подобное в прошлый раз, и не могу вспомнить, где об этом можно почитать. Проще взять студию, winforms, и накидать форму без всяких заумностей, с этим подобных проблем не возникает.
Re[26]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 14.09.19 08:32
Оценка:
Здравствуйте, yukosoft, Вы писали:

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


Это, мягко говоря, неправда. Конфигуратор -- это тоже инструмент, который надо изучить и уметь правильно использовать.
Re[5]: Многие делают - но каждый свой велосипед
От: bnk СССР http://unmanagedvisio.com/
Дата: 14.09.19 09:19
Оценка:
Здравствуйте, amironov79, Вы писали:

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


Ага, понятно. Ну в какой-то мере изучать любую систему придется.
Если у нее есть нормальная документация, форум с вопросами-ответами, и если она присутствует на stackoverflow это сильно упрощает задачу.
Конкретно в моем случае имеем базу в примерно 20 таблиц, на каждую нужно нескольк формочек типа, список, детали, пикер. Это будет под сотню вьюшек (если включать дочерние табы типа, master-detail).
В XAF они — вуаля — генерятся автоматически. Модель можно апдейтить при изменении структуры базы, тоже через кнопку в UI, вюьшки перегенерируются.
Также она запоминает пользовательские настройки и код "поверх", то есть они сохраняются при обновлении.

В WinForms у меня бы точно спина вспотела делать эти формочки и поддерживать их в актуальном состоянии.

За несколько дней просмотров учебных видео и чтения доков (которые, к счастью, есть), вполне можно освоить на базовом уровне
Код писать (свои действия — "контроллеры") тоже достаточно элементарно.
Re[6]: MS делают видео вместо статей - где разум?
От: DenisCh Россия  
Дата: 14.09.19 09:23
Оценка:
Здравствуйте, yukosoft, Вы писали:

y> 1С подобные системы (конструкторы)

Ты когда в последний раз видел этот "конструктор"? Во времена 6.0?
[url=https://github.com/abbat/avalon1.0.449[/url]
Re[6]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 14.09.19 10:56
Оценка:
Здравствуйте, bnk, Вы писали:

bnk>В XAF они — вуаля — генерятся автоматически. Модель можно апдейтить при изменении структуры базы, тоже через кнопку в UI, вюьшки перегенерируются.

bnk>Также она запоминает пользовательские настройки и код "поверх", то есть они сохраняются при обновлении.

Всё так, я тоже пару месяцев ходил под впечатлением. Потом прошло.
Re[5]: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 14.09.19 12:07
Оценка: 1 (1) +1
Здравствуйте, Shmj, Вы писали:

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


Проблема в том, что КАЖУЩАЯСЯ скорость — лишь начальное "головокружение от успехов". Прибежал, нажал кнопку, генератор вывалил сотню форм, в Вилларибо снова праздник.
А на деле, вся эта сгенерённая туфта 100% будет переделываться, донастраиваться и даже переписываться.
Просто даже смешно слышать слово "бизнес" и такое позорищное "программирование" — вы формами в переходах торгуете штоле??
Любая программа имеет минимум 5-летний срок службы, с ней работают десятки разных людей, всем нужно удобство, скорость, минимум движений и минимум ошибок. Программа требует постоянного улучшения (а значит должна быть высокая сопровождаемость продуманного кода). Где тут "скорость и дешевизна" влияют вообще?? Программа, которую пишут на скорость — это говно, а не программа просто по-определению.

Есть нормальная скорость разработки. Она может быть выше за счёт каких-то упрощений, но в целом качественная форма требует какой-то объективный минимум времени.
Если ты "побырому" нагенерил сотни форм — ты всё равно потратишь время на их анализ, корректировку настроек и новую перегенерацию. Хуже того — на большом объёме глаз просто замыливается и очевидные ляпы пролезают в релиз. И потом всё равно придётся кастомайзить код, потому что ЛЮБОЙ генератор далёк от совершенства.

S>Даже если автоматически сгенеренные формы такого поля и не будут содержать, то особо никто не пострадает.


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

S> В отображении данных добавят с помощью View на стороне базы.


Шта?? Причём тут view вообще? Ты считаешь, что все добавления имеют сложность "вычислить возраст по ДР"? Ну-ну...

S>Есть SQL CHECK Constraint:

S>Day1 int CHECK (Day1 >=1 AND Day1 <= 7)

Спасибо, поржал. И что дальше? Зачем мне вообще какие-то check Constraint? СУБД — это хранилище данных, всё остальное должно делаться на уровне апп-сервера, в удобном ЯОН в красивой IDE с анализаторами, профайлерами и т.п. Перестаньте уже носиться с этими атавизмами, век "программирования внутри СУБД" безнадёжно ушёл.


S>То о чем вы говорите — это сродни искусства. Искусство никогда не перестанет быть актуальным, однако же для большинства нужен просто функционал.


Ерунда. Уже ответил выше — таких "формошлёпских" приложений — тьма, только никому эти приложения-уроды не нужны. Победит только та программа, которая действительно ОБЛЕГЧИТ мою работу. Все могут вводить ФИО, не все умеют делать это оптимально. Да и "искусства" здесь минимум — есть десятки учебников по прагматичному проектированию UI, просто читай и внедряй.

S>Можно стены дома украсить картинами а можно "автоматически сгенеренными" фотообоями. Для большинства второй вириант доступнее.


Никакой аналогии. У тебя "обои" — абсолютно оторванный от бизнеса, универсальный, ненастраиваемый продукт. В реале каждая программа постоянно "натягивается на бизнес".
Возьми десяток бизнесов "купи-продай" и У ВСЕХ найдутся свои специфичные потребности. Потому и не бывает "коробочных" "бухгалтерий", "складов", "продаж" и т.п. — все нужно допиливать, улучшать, чтобы именно твой бизнес имел с этой автоматизации профит. Просто форма ничего не улучшает, это тупо замена бумаги пикселями. Программа должна улучшать сам процесс, в этом суть.
Re[6]: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 14.09.19 12:46
Оценка: 3 (1) +1
Здравствуйте, yukosoft, Вы писали:

Y>В будущем огромный пласт программистов средней руки исчезнет


Эх, мечтатели!... Вы прям как те ЛИСПеры с горящими глазами, каких-то 30 лет назад предсказывающие ровно такой же "коллапс посредственностей". А воз? Он и ныне там.

Y>Будут облачные фреймворки с машинным обучением и программы будут писаться чуть ли не на уровне общения с ИИ: "а теперь добавь поле с датой и назови его [День рождения]


Я не спорю, место для автоматизации создания форм есть. Но вот их дальнейшее развитие/улучшение — вещь, никакими ИИ не вычислимая.

Собственно, сама практика доказывает всю убогость ваших мечт — вот уже упомянули генератор от DevEx. Я лично слышу о нём впервые. Те, которые слышали, я смотрю тоже не торопятся везде его применять. Я ВООБЩЕ НИГДЕ не вижу, чтобы на форумах было какое-то активное бурление вокруг генераторов: "ой, как всё быстро и качественно", "мы уже пятнадцатую систему на нём пишем" и т.п. С чего бы? Вы заметили тут луддитов? Или мы все тупее ДевЭкспресса? Или кто-то нарочно придумывает себе работу, вместо "генерации форм" и пития пива в освободившееся время? ПРАКТИКА — неумолимый судья, ему не нужны ваши увещевания и влажные мечты об ИИ — она прекрасно доказала никчёмность "авто-подхода". Собсно, программирование никогда и не было тупым кодированием форм — во всякой программе довольно сложноты, интересных задач, мест для оптимизаций и т.п.


Y>День рождения и возраст делается за 40 секунд:


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

Y>Нужны ссылки


НЕ НУЖНЫ ссылки. Мне вообще не нужно ничего из того, что ты мне предлагаешь из набора "возможностей генератора". Просто потому, что сама идея — ущербна в корне.
Максимум — ты можешь автоматизировать генерацию самой формы, всё остальное я напишу сам и буду чётко понимать структуру проекта. Надо — сделаю центральный валидатор, не надо — нацепляю на каждое поле. Захочу — к каждой кнопке приделаю "undo". Это уже конкретная логика, ей в генераторе не место.

Y>Ну а заниматься в коде настройкой цветов строк и полей по условиям могут позволить себе очень богатые люди.


Что тут "дорогостоящего" ты увидел?? Это обычная работа дизайнера! Более того — это ОБЯЗАТЕЛЬНАЯ часть работы по написанию программы. Сам посмотри на свои же скрины — извини, за такое барахло я и 100 рублей не дам. Потому, что за версту видно, что делал либо дилетант, либо робот — никто даже на секунду не задумался, как ВСЁ ЭТО будет воспринимать обычная "тётка из бухгалтерии". Криво расположенные поля, никакой цветовой дифференциации секций, обилие полей, минимум цветов... мне как со всем этим работать? Вот-вот, "нагенерил кучу $@#$%@#" — вот как это называют. ЗАТО БЫСТРО! И что мне твоя быстрота дала? Что она дала бизнесу? КТО будет покупать это убожество? Какой смысл делать продукт за неделю, если ГОДАМИ на рынке существуют другие продукты даже лучшего качества? Как ты их собираешься подвигать? Хоть кто-то у тебя спросил "за сколько секунд ты сгенерил интерфейс"?

Убожество всё это, прям даже смешно читать. Да, и к слову о бизнесе: задача ДевЭксов — не облегчать твоё формошлёпоство или чтобы ты написал побольше программ. Их задача — делать деньги на таких как ты, объясняя, "как круто генерить UI за секунду". То, что ты купился на эти увещевания, никак не меняет истину.
Re[6]: MS делают видео вместо статей - где разум?
От: bnk СССР http://unmanagedvisio.com/
Дата: 14.09.19 12:47
Оценка: +1
Здравствуйте, Kolesiki, Вы писали:

K>Любая программа имеет минимум 5-летний срок службы, с ней работают десятки разных людей


С чего бы это? Это же всего лишь один из возможных сценариев.

K>Есть нормальная скорость разработки. Она может быть выше за счёт каких-то упрощений, но в целом качественная форма требует какой-то объективный минимум времени.

K>Если ты "побырому" нагенерил сотни форм — ты всё равно потратишь время на их анализ, корректировку настроек и новую перегенерацию. Хуже того — на большом объёме глаз просто замыливается и очевидные ляпы пролезают в релиз. И потом всё равно придётся кастомайзить код, потому что ЛЮБОЙ генератор далёк от совершенства.

Какой нафик "релиз", когда приложение делается внутри организации, а не на продажу?
То есть, речь не шла не о "продуктовых" приложениях, которые продают, а просто об утилитарных приложениях, используемых внутри организации (типа замены Access/Excel)
Есть целый пласт таких вот "бизнес" приложений, которые никому в мире кроме пяти человек в данной конкретной организации не нужны.
И "разрабатывает" их собственный отдел IT. Вот что им делать?

K>Ну если вы пишете "автоматизацию мороженного ларька" — согласен, пострадавших мало. А если вы выходите на рынок, где ДЕСЯТКИ "формошлёпов" нагенерили своих "бухгалтерий", придётся писать что-то умнее, чем просто форма. Век тупых форм прошёл, объёмы инфы возросли кратно — в этих условиях конкурировать придётся интеллектом, скорость тут вообще никого не волнует.


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

K>Спасибо, поржал. И что дальше? Зачем мне вообще какие-то check Constraint? СУБД — это хранилище данных, всё остальное должно делаться на уровне апп-сервера, в удобном ЯОН в красивой IDE с анализаторами, профайлерами и т.п. Перестаньте уже носиться с этими атавизмами, век "программирования внутри СУБД" безнадёжно ушёл.


Чтобы нельзя было в формочке ерунду ввести. На кой хрен ради пяти человек делать "апп-сервер" со всякими прибабахами?
Пробовал например в Excel сделать условия на ввод неправильных данных в ячейку? Типа этого, только чуть сложнее.
Re[6]: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 14.09.19 13:02
Оценка:
Здравствуйте, bnk, Вы писали:

bnk>Конкретно в моем случае имеем базу в примерно 20 таблиц, на каждую нужно нескольк формочек типа, список, детали, пикер. Это будет под сотню вьюшек (если включать дочерние табы типа, master-detail).

bnk>В XAF они — вуаля — генерятся автоматически.


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

Я не понимаю, откуда столько вакансий девелоперов на, казалось бы, "стандартные" проекты, если один bnk со своим девэкс-генератором может покрыть весь рынок! Причём за неделю (судя по скорости генерации). Может, объяснишь, почему ты всё ещё не Билл Гейтс-2?
Re[7]: MS делают видео вместо статей - где разум?
От: bnk СССР http://unmanagedvisio.com/
Дата: 14.09.19 13:26
Оценка:
Здравствуйте, Kolesiki, Вы писали:


K>Я не понимаю, откуда столько вакансий девелоперов на, казалось бы, "стандартные" проекты, если один bnk со своим девэкс-генератором может покрыть весь рынок! Причём за неделю (судя по скорости генерации). Может, объяснишь, почему ты всё ещё не Билл Гейтс-2?


Да у меня нет таких способностей как у Гейтса

Я работаю в ит-отделе не-айтишной организации, мне просто нужен был какой-то инструмент чтобы с минимальным трудозатратами слепить приложение для внутреннего использования в отделе (база уже была/есть). Чтобы не требовало облаков.

Можно посмотреть по истории моих сообщений
Re[8]: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 14.09.19 14:47
Оценка: +1
Здравствуйте, bnk, Вы писали:

bnk> мне просто нужен был какой-то инструмент чтобы с минимальным трудозатратами слепить приложение для внутреннего использования


Здесь абсолютно солидарен — можно брать любой генератор и лепить формы напропалую. Но даже если "внутренние люди" и не платят тебе деньги, хочется, чтобы формы не вызывали у людей истерику.
Кстати, заметили, что про генерацию форм мы говорим "автоматическая" и "ручная", но никто не говорит "автоматическая" и "интеллектуальная"? Хотя именно голова, а не руки создают "ручные" формы!
Re[9]: Многие делают - но каждый свой велосипед
От: pagid Россия  
Дата: 15.09.19 12:43
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Какие? Интересуют те, что:

Б>- позволяют описывать структуру данных
Да.

Б>- прячут всю логику хранения в БД (на основе структуры данных)

Не знаю таких. И насколько понимаю 1С не такая.

Б>- формируют стандартный интерфейс пользователя (на основе структуры данных)

Не знаю таких, есть наверно, но не интересовался. И насколько понимаю 1С не такая.

Б>Кроме 1С я только Odoo знаю.

Не знаю как 1С сюда попала.
Re[10]: Многие делают - но каждый свой велосипед
От: Буравчик Россия  
Дата: 15.09.19 12:47
Оценка:
Здравствуйте, pagid, Вы писали:

P>Здравствуйте, Буравчик, Вы писали:


P>Не знаю таких. И насколько понимаю 1С не такая.

P>Не знаю таких, есть наверно, но не интересовался. И насколько понимаю 1С не такая.
P>Не знаю как 1С сюда попала.

Да, я понял
Best regards, Буравчик
Re[9]: Многие делают - но каждый свой велосипед
От: pagid Россия  
Дата: 15.09.19 12:49
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Потому что работаю с этой технологией много лет.

Система наподобие 1С это прежде всего высокоуровневое инструментальное средство, то что для таких дел принято называть платформой. Вполне логично, что она написана не на .Net. Хотя конечно возможность интеграции с расширениями написанными на .Net для подобной системы хотелка вполне здравая.
Re[10]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 15.09.19 13:31
Оценка:
Здравствуйте, pagid, Вы писали:

S>>Потому что работаю с этой технологией много лет.

P>Система наподобие 1С это прежде всего высокоуровневое инструментальное средство, то что для таких дел принято называть платформой. Вполне логично, что она написана не на .Net. Хотя конечно возможность интеграции с расширениями написанными на .Net для подобной системы хотелка вполне здравая.

Есть и те, что написаны на .Net — выше уже привели.
Re[11]: Многие делают - но каждый свой велосипед
От: pagid Россия  
Дата: 15.09.19 14:14
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Да, я понял

Что понял? 1C динамически генерит формы?
Re[11]: Многие делают - но каждый свой велосипед
От: pagid Россия  
Дата: 15.09.19 14:15
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Есть и те, что написаны на .Net — выше уже привели.

И как насчет их популярности? Написать несомненно можно.
Re[12]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 15.09.19 14:17
Оценка:
Здравствуйте, pagid, Вы писали:

S>>Есть и те, что написаны на .Net — выше уже привели.

P>И как насчет их популярности? Написать несомненно можно.

Про 1C знают только в России и СНГ. А вот Devexpress XAF известен во всем мире.
Re[13]: Многие делают - но каждый свой велосипед
От: DenisCh Россия  
Дата: 15.09.19 15:14
Оценка:
Здравствуйте, Shmj, Вы писали:

S> S>>Есть и те, что написаны на .Net — выше уже привели.

S> P>И как насчет их популярности? Написать несомненно можно.
S> Про 1C знают только в России и СНГ.

А ещё в Чехии, Китае, Канаде, ОАЭ...
[url=https://github.com/abbat/avalon1.0.449[/url]
Re[14]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 15.09.19 16:36
Оценка:
Здравствуйте, DenisCh, Вы писали:

DC>А ещё в Чехии, Китае, Канаде, ОАЭ...


А кол-во пользователей там какое?
Re[13]: Многие делают - но каждый свой велосипед
От: pagid Россия  
Дата: 15.09.19 19:38
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Про 1C знают только в России и СНГ. А вот Devexpress XAF известен во всем мире.

Это инструменты для разных целей.
А если по известности, то И 1С сверх известен в России и СНГ, а Devexpress XAF возможно немножечко известен, но во всем мире.
Re[14]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 15.09.19 19:49
Оценка:
Здравствуйте, pagid, Вы писали:

P>Это инструменты для разных целей.

P>А если по известности, то И 1С сверх известен в России и СНГ, а Devexpress XAF возможно немножечко известен, но во всем мире.

Согласен, Devexpress XAF — это более низкоуровневый.

Аналог 1C для белых людей — это SAP. Прибыль €4,08 млрд, Число сотрудников 96,498 тыс.

Сравните 1С — Прибыль $65 млн, Число сотрудников более 1100.

Т.е. это как сравнить детский совок и экскаватор.
Re[15]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 15.09.19 20:34
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Аналог 1C для белых людей — это SAP. Прибыль €4,08 млрд, Число сотрудников 96,498 тыс.

S>Сравните 1С — Прибыль $65 млн, Число сотрудников более 1100.
S>Т.е. это как сравнить детский совок и экскаватор.

Я думал, начальный вопрос был про удобство инструментов разработки. А он больше про инструменты по выкачиванию денег из клиента.
Re[15]: Многие делают - но каждый свой велосипед
От: DenisCh Россия  
Дата: 16.09.19 02:13
Оценка:
Здравствуйте, Shmj, Вы писали:

S> Аналог 1C для белых людей — это SAP. Прибыль €4,08 млрд, Число сотрудников 96,498 тыс.

S> Сравните 1С — Прибыль $65 млн, Число сотрудников более 1100.
S> Т.е. это как сравнить детский совок и экскаватор.

SAP это не средство ведения учёта. Это средство повышения капитализации компании...
[url=https://github.com/abbat/avalon1.0.449[/url]
Re[16]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 16.09.19 02:43
Оценка:
Здравствуйте, DenisCh, Вы писали:

DC>SAP это не средство ведения учёта. Это средство повышения капитализации компании...


Это кто вам сказал?
Re[16]: Многие делают - но каждый свой велосипед
От: pagid Россия  
Дата: 16.09.19 04:10
Оценка:
Здравствуйте, DenisCh, Вы писали:

DC>SAP это не средство ведения учёта. Это средство повышения капитализации компании...

И эта компания называется SAP
Re[17]: Многие делают - но каждый свой велосипед
От: DenisCh Россия  
Дата: 16.09.19 04:24
Оценка:
Здравствуйте, Shmj, Вы писали:

S> DC>SAP это не средство ведения учёта. Это средство повышения капитализации компании...

S> Это кто вам сказал?

Умные люди. Не ты, не переживай.
[url=https://github.com/abbat/avalon1.0.449[/url]
Re[18]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 16.09.19 04:30
Оценка:
Здравствуйте, DenisCh, Вы писали:

S>> DC>SAP это не средство ведения учёта. Это средство повышения капитализации компании...

S>> Это кто вам сказал?

DC>Умные люди. Не ты, не переживай.


А как ты себе представляешь "средство повышения капитализации компании" в отрыве от учета?
Re[17]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 16.09.19 04:48
Оценка:
Здравствуйте, Shmj, Вы писали:

DC>>SAP это не средство ведения учёта. Это средство повышения капитализации компании...


S>Это кто вам сказал?


А какие еще могут быть причины покупки решений от sap? А вам кто сказал, что sap -- это про скорость и удобство разработки? Вы знакомы с инструментами разработчика в sap (как вам после студии), вы видели abap (как впечатления после шарпа), у вас есть опыт интеграции с sap (удобно, не правда ли)?
Re[18]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 16.09.19 05:10
Оценка:
Здравствуйте, amironov79, Вы писали:

A>А какие еще могут быть причины покупки решений от sap? А вам кто сказал, что sap -- это про скорость и удобство разработки? Вы знакомы с инструментами разработчика в sap (как вам после студии), вы видели abap (как впечатления после шарпа), у вас есть опыт интеграции с sap (удобно, не правда ли)?


То же самое сможно сказать по 1C.
Re[19]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 16.09.19 05:38
Оценка:
Здравствуйте, Shmj, Вы писали:

S>То же самое сможно сказать по 1C.


Могу обобщить: то же самое можно сказать про все подобные системы. Всё, точка.
Re[6]: MS делают видео вместо статей - где разум?
От: romangr Россия  
Дата: 16.09.19 07:30
Оценка:
Здравствуйте, yukosoft, Вы писали:

Y>Shmj абсолютно верно пророчит судьбу многих программистов. 1С подобные системы (конструкторы) это только начало. В будущем огромный пласт программистов средней руки исчезнет так же как исчезли радиолюбители времён СССР которые на коленка собирали приёмники и усилители. Будут облачные фреймворки с машинным обучением и программы будут писаться чуть ли не на уровне общения с ИИ: "а теперь добавь поле с датой и назови его [День рождения] и добавь поле ReadOnly где будет выводится возраст на основе дня рождения. Откомпилируй. В продакшин!"


Y>День рождения и возраст делается за 40 секунд:


Y>Image: core8.jpg


Поздравляю! За 40 секунд с возрастом вы накосячили.
Дата рождения — 22.09.2007. Текущий день — 14.09.2019. Вы показываете возраст 12 лет, хотя 12 лет исполнится только 22.09.2019,
а на 14.09.2019 полный возраст — 11 лет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[15]: Многие делают - но каждый свой велосипед
От: bnk СССР http://unmanagedvisio.com/
Дата: 16.09.19 11:26
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Аналог 1C для белых людей — это SAP. Прибыль €4,08 млрд, Число сотрудников 96,498 тыс.

S>Сравните 1С — Прибыль $65 млн, Число сотрудников более 1100.

S>Т.е. это как сравнить детский совок и экскаватор.


Агащасблин. SAP — это ужас, летящий на крыльях ночи. По удобству использования с 1С даже близко нет.
Покупают его из-за откатов, AFAIK. Народу там много, потому что всё настолько по-аццки сделано, что без ящика водки толпы консультатнов не разберешься.
Re[19]: Многие делают - но каждый свой велосипед
От: DenisCh Россия  
Дата: 16.09.19 17:31
Оценка:
Здравствуйте, Shmj, Вы писали:

S> S>> DC>SAP это не средство ведения учёта. Это средство повышения капитализации компании...

S> S>> Это кто вам сказал?
S> DC>Умные люди. Не ты, не переживай.
S> А как ты себе представляешь "средство повышения капитализации компании" в отрыве от учета?

Купили САП — стоимость компании увеличилась. А считают в екселе, а потом данные руками переносят в 1с-бухгалтерию для сдачи отчётности.
[url=https://github.com/abbat/avalon1.0.449[/url]
Re[7]: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 16.09.19 21:46
Оценка:
Здравствуйте, romangr, Вы писали:

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

Y>>День рождения и возраст делается за 40 секунд:
Y>>Image: core8.jpg

R>Поздравляю! За 40 секунд с возрастом вы накосячили.

R>Дата рождения — 22.09.2007. Текущий день — 14.09.2019. Вы показываете возраст 12 лет, хотя 12 лет исполнится только 22.09.2019,
R>а на 14.09.2019 полный возраст — 11 лет.

Именно. Сам был сильно удивлён, но полное число лет вычисляется совсем неординарным способом:

var age = ((today.Year - birthday.Year) * 372 + (today.Month - birthday.Month) * 31 + (today.Day - birthday.Day)) / 372;


Но главная идея была не про это, а про "автоматический" дизайн — он ниачом. Всё равно, что попросить Терминатора нарисовать "Данаю".
Походу, тут какие-то засланые казачки тупо толкают чей-то инструмент, причём толкают тухло — без аргументов и с низким уровнем знаний. Неужели они считают нас тупее себя?...
Re[8]: MS делают видео вместо статей - где разум?
От: Carc Россия https://vk.com/gosha_mazov
Дата: 17.09.19 03:36
Оценка:
Здравствуйте, Kolesiki, Вы писали:


R>>Дата рождения — 22.09.2007. Текущий день — 14.09.2019. Вы показываете возраст 12 лет, хотя 12 лет исполнится только 22.09.2019,

R>>а на 14.09.2019 полный возраст — 11 лет.

K>Именно. Сам был сильно удивлён, но полное число лет вычисляется совсем неординарным способом:


K>
K>var age = ((today.Year - birthday.Year) * 372 + (today.Month - birthday.Month) * 31 + (today.Day - birthday.Day)) / 372;
K>


Нафига козе баян?
Зачем все эти дэи-тудеи — это ж просто как бубль-гум!?!

Берем текущий год вычитаем из него год рождения. Дальше сравниваем месяц\число текущие и дня рождения. Если текущее число\месяц меньше числа\месяца дня рождения, то из разницы годов вычитаем еще единичку. Ибо! © Полный год еще не прошел.
Вуаля! Готово

И даже не надо никаких приседаний на предмет високосных годов аль невисокосных.
Aml Pages Home
Re[15]: Многие делают - но каждый свой велосипед
От: Ночной Смотрящий Россия  
Дата: 17.09.19 18:35
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Аналог 1C для белых людей — это SAP.


Нет. SAP для крупных предприятий, 1С для мелких и средних. Аналог 1С скорее Dynamics 365 for Operations.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re: Многие делают - но каждый свой велосипед
От: AWSVladimir  
Дата: 17.09.19 19:25
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Неужели никто ничего не придумал?

Я таких велосипедов несколько видел.
Публичный на сколько помню Гедемин, остальные коммерческие типа Искрам или внутри-корпоративные разработки.


Проблемы которые ты не видишь:
1. Данные.
1.1 Если данных мало,то все пучком. С увеличением объемов тормоза увеличиваются в геометрической прогрессии.
Вот пример на картинке, если бы была такая форма в базе, где гигабайтные таблицы (уточняю гигабайтная не база, а таблицы), то разраба утопили бы в туалете.
1.2.Если мы говорим о профессиональной разработке, то разрабатывать нужно структуру данных в профессиональной среде, с профилированием планов и тд. Если в своем конструкторе то инструмент д/б не хуже профессионального. Такое проектирование как в примере подойдет для студенческой разработки или для прототипов.

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

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

Вот ты написал, сколько времени понадобится сделать аналогичную форму.
1-й раз, да, понадобится время, второй раз аналогичную нужно только копирование и время "причесать форму" не такое и большое, где то час, где то 4, а если совсем аналогичная, то вообще времени не надо.

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

PS: Это все подходит только для прототипов или простых систем учета.
Re[3]: MS делают видео вместо статей - где разум?
От: Sinclair Россия https://github.com/evilguest/
Дата: 18.09.19 08:37
Оценка: 39 (7) +1
Здравствуйте, Shmj, Вы писали:
S>Может и не велика, но когда форма вот такая:

S>Image: ServiceCenter_Main.jpg


S>т.е. когда есть 6 других таблиц, связанных с данной — то представьте сколько времени уйдет на создание такой формы. Нужен не только просмотр, но и добавление/редактирование данных. Вручную забембаешься поля вводить — даже если по 1 мин. на каждое — уже дня 2 уйдет.


S>Вот вы бы за сколько времени создали такую форму вручную? Притом что форма должна не просто быть, но еще и связана с данными — с 7 разными таблицами + еще словари (около 10). Путем конфигурации это делается максимум за час. Сколько у тебя уйдет на ручное написание?

Вот прямо спасибо за отличный пример.
Эта форма — тупик цивилизации. Программисту она может казаться даже красивой — полное доминирование математической модели над здравым смыслом. Нормальному человеку эта форма кажется ужасной.

Проектирование нормальных приложений идёт не от структуры данных, а от сценариев. Что люди делают с этой "формой"? Ищут заказы, создают новые заказы, изменяют существующие? Ответ "всё это, и ещё 12 действий из контекстного меню" не подходит — надо разобраться во всех из них. Классифицировать пользователей по ролям, для каждой роли знать относительные частоты всех сценариев.
Для каждого из сценариев прояснить основной успешный вариант и две-три самых популярных вариации — то есть прямо по шагам "смотрим на XXX, делаем YYY". Для каждого неуспешного сценария выяснить предлагаемые шаги по исправлению проблемы.
Внимательно изучить данные, которые нам нужно показать пользователю на каждом шаге каждого сценария, и данные, которые нужно у пользователя запросить.
Данные для показа приоритизировать. Запрашиваемые у пользователя данные нужно изучить под микроскопом на предмет того, как избежать их запроса вообще; если нельзя избежать — то минимизировать то, что спрашиваем; то, что осталось — валидируем мягким способом, расставляем хинты. Характерный пример — создаём новый заказ. А часто ли встречается такая ситуация, что клиент повторяет свой предыдущий заказ с небольшими вариациями — то есть можно его скопировать и дать подправить; ведь это быстрее, чем плодить новый? Часто ли встречается такая ситуация, что есть популярный набор работ для каждой модели телефона, и сразу после ввода букв "6s" можно угадать, что будут заказывать?

Даже не проделав всю эту титаническую работу, одного взгляда на форму достаточно, чтобы оценить её usability.
0. Поиск заказов сделан опытным мизантропом. Вместо популярного лет 10 уже паттерна query language, который бы позволял просто искать в стиле "статус:закрыт И периодтекущий месяц)" (а заодно ставить закладки или автоматически вычислять наиболее запрашиваемые фильтры) мы имеем сочетание комбобоксов и свободнотекстового поля ввода. 1990е.
1. Список заказов выведен в грид, который вдвое шире доступного места. Либо там справа — какая-то муть, которую вообще в списке заказов показывать не надо, либо пользователь вынужден постоянно скроллить влево-вправо.
2. Все связанные сущности выведены в виде гридов на взаимоисключающих табах. Нет возможности увидеть одновременно работы и материалы. WTF? Ведь очевидно, что для работы "замена экрана на S9" есть стандартный набор материалов, без которых она невыполнима. Нет, пусть пользователь потеет, ручками вбивает пары "работа-материал" в разные табы.
3. Всё, чего может быть больше одного, засовывается в грид, без малейшей попытки оценить распределение количества элементов. Например, у 99% заказов 0 или 1 платёж. Тем не менее, мы выделяем под них целый грид, а под него — отдельный таб. Теперь, чтобы посмотреть, оплачен ли заказ, надо кликать в него, а потом прыгать в таб. Десять баллов Слизерину.


В итоге вы за час делаете говно. Вот прямо берёте и увеличиваете объём страданий и ненависти в мире. Понятно, что можно сделать то же говно вручную, потратив неделю на раскладку гридов и кнопок по форме в том же виде.
Но речь не об этом, а о том, что можно было сделать UX примерно в 100 раз лучше безо всяких "гридов" и "табов", потратив чуть больше времени на анализ действий пользователей.
И вот такой, нормальный UX, вам не сделает никакой генератор. По крайней мере до тех пор, пока генератор собирается работать по модели данных.
Чтобы сделать хоть что-то приемлемое, генератор должен работать с моделью сценариев. Типа "пришёл клиент с новым заказом", "пришёл клиент забрать выполненный заказ", "позвонил клиент узнать статус заказа", "в процессе выполнения заказа возникли вопросы к клиенту, требующие согласования", "нужно оповестить клиента о готовности заказа". Вот с чем работает разработчик UI, и с чем должен работать генератор. А не со схемой типа "к заказу можно прицепить файлы, фотографии, платежи, работы и материалы". Да, можно. Ну и что?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Многие делают - но каждый свой велосипед
От: Sinclair Россия https://github.com/evilguest/
Дата: 18.09.19 08:43
Оценка: +1
Здравствуйте, Shmj, Вы писали:
S>Ну почему? У нас чувак сделал всю логику на MS SQL.
Я таких решений видел десятки.
У всех (кроме хренового качества получающегося GUI) есть одна большая проблема: то, что раньше было программой, теперь становится конфигурацией.
Ошибки в программе помогает искать IDE с её компилятором и дебаггером. Есть развитый тулчейн по контролю версий — мы всегда можем понять, кем, когда, и зачем было внесено каждое изменение; можем взять из архива исходник 2003 года и собрать его, чтобы починить багу у удалённого клиента, который не обновлялся с тех пор; можем тестировать изменение в бранче, и мёрджить в транк только проверенную версию; можем откатиться на неделю назад, чтобы исправить неверное изменение.

"Конфигурации" ничего этого не умеют. В лучшем случае они живут в текстовых файлах, которые можно засунуть в VCS.
В вашем случае они живут в базе; это означает, что вообще никто не знает, что там стоит у заказчика. Нет понятия "версия", нет blame, нет changelog, нет веток, нет confliсt resolution.
Такие решения создают больше проблем, чем решают. Пишется-то система быстро, а вот стоимость поддержки начинает зашкаливать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Многие делают - но каждый свой велосипед
От: yukosoft  
Дата: 18.09.19 20:06
Оценка: +1
кто-то писал что это реклама... На форуме программистов рекламировать конструктор который не продаётся это реклама? Кто не догадался: это не реклама, а просто попытка поделиться опытом и наработками раз подняли тему о своих велосипедах. (продаются конфигурации сделанные конструктором и пользователю доступна юзер френдли малая часть конструктора).

Ранее писали: "когда разрабатывается форма не попадающая в шаблон используемоей логики, вот тогда наступает полная жопа"

Это не так. Конструктор позволяет писать на C# любые кастомные формы и открывать их в программе. При этом эти кастомные формы могут пользоваться всей инфраструктурой конструктора если требуется (например создать пункты меню не руками).
Вот реальный пример формы которую проще было сделать в дизайнере студии чем в конструкторе так как логика работы была не стандартная.
Специально для форума написал большую зелёную надпись — а можно было и бегущих красных муравьёв.



вот как форма интегрируется в конфигурацию:



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


кто-то писал: "Вместо популярного лет 10 уже паттерна query language, который бы позволял просто искать в стиле "статус:закрыт И период текущий месяц)" мы имеем сочетание комбобоксов и свободнотекстового поля ввода"

Есть и такой конструктор запросов:



кто-то писал: "Нет возможности увидеть одновременно работы и материалы. WTF? Ведь очевидно, что для работы "замена экрана на S9" есть стандартный набор материалов, без которых она невыполнима. Нет, пусть пользователь потеет, ручками вбивает пары "работа-материал" в разные табы.
3. Всё, чего может быть больше одного, засовывается в грид, без малейшей попытки оценить распределение количества элементов. Например, у 99% заказов 0 или 1 платёж."

Конструктор умеет отображать данные в двух представлениях: табличное и карточное. Данные ищутся в табличной части а работа с данными может быть и в таблице и в карточке. Так вот конструктор как раз позволяет по требованию заказчика оперативно поменять представление.

Представим что "Нет возможности увидеть одновременно работы и материалы" — поступило от пользователя. Вот как выглядит карточка до:



и вот как выполнено требование заказчика. В конструкторе снято 3 галки и затем перемещением мыши таблицы разложены так как укажет заказчик интерфейса. Возможно скорость и не важна но это заняло около 2 минут.



Конструкторы идеальны для решения прикладных задач и когда есть необходимость постоянной доработки или переработки интерфейса. Никто не говорит о том что на конструкторах нужно писать систему реального времени управления взлётом и посадкой самолётов.

P.S.
То что этот и похожие конструкторы "говно" — даже не поддаётся сомнению — это так! Только ручное создание и изменение форм и тысячи строк кода позволяют нам всем намазывать масло на хлеб.
Re: Преимущества чистого кодогенератора
От: L_G Россия  
Дата: 19.09.19 03:48
Оценка: +2
Над проблемой периодически задумывался в течение многих лет. (Но не дождался такого приступа энтузиазма, чтобы броситься уже что-то кодировать.)

Из разных архитектурных вариантов подобной "среды" для себя остановился на варианте кодогенератора, который на основе структуры БД + какого-то дополнительного простого метаописания генерировал бы примерно такой же код, какой бы написал вручную сам программист. После этого код можно дорабатывать как обычно, стандартными средствами. А можно продолжать использовать генератор. При этом, возможно, придется вручную выделять из заново генерируемого кода нужные куски и вставлять их в нужные места основного кода. Скорее всего, при желании можно будет изолировать автоматически генерируемый код от подвергаемого ручным правкам.

Вроде бы это вписывается в термин "scaffolding". (Он используется почему-то только в веб-программировании, до которого я пока не добрался.)

Плюсы подхода особенно хорошо проявляются, если ты — наёмный программист в чужой конторе:
+ поддерживающие код после тебя не столкнутся с незнакомой и загадочной для них "средой" или "фреймворком" — везде самый обычный код.
+ в случае, если начальство и коллеги являются противниками всяких велосипедных метаинструментов, можно им ничего не говорить — просто нагенерировать себе кода и далее работать с ним, при необходимости легко зачистить все следы от присутствия своего кодогенератора. И в VCS можно коммитить только сгенерированный код.
+ как вариант, ты автоматизируешь только свою собственную работу и получаешь профит или хотя бы конкурентное преимущество.

При написании инфосистем под заказ такой подход тоже оправдан: чем отдавать самому заказчику "средства конфигурирования", не лучше ли периодически (а лучше — систематически) брать с него денежку за поддержку?

BTW, к "среде" со своим "ядром" и динамической генерацией форм наверняка тоже можно приделать возможность сгенерировать те же формы и нужный им код статически (чтобы далее всё работало точно так же без среды и ядра).

P.S. под WPF кое-что есть, сам пока не смотрел: https://stackoverflow.com/questions/704337/scaffolding-for-wpf-using-mvvm

P.P.S. Совсем забыл про вариант "Model first", когда сначала набрасывается "метаописание" (возможно, в некоей "визуальной" или табличной тулзе, т.е. не в чисто-текстовой форме), а из него генерится и сама БД, и код. С возможностью реверса БД в модель. А ведь я как-то раз все же начинал кодировать свой велосипед — именно по этому варианту.
Отредактировано 19.09.2019 10:51 L_G . Предыдущая версия . Еще …
Отредактировано 19.09.2019 10:48 L_G . Предыдущая версия .
Отредактировано 19.09.2019 5:17 L_G . Предыдущая версия .
Re[5]: Многие делают - но каждый свой велосипед
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.09.19 05:42
Оценка: 33 (4)
Здравствуйте, yukosoft, Вы писали:

Y>Специально для форума написал большую зелёную надпись — а можно было и бегущих красных муравьёв.

Image: core15.jpg
Вы не понимаете, о чём я пишу, увы.
Чисто для контекста: первую такую систему авто-генерации гуя по БД лично я написал в 1991 году на Clipper. И с тех пор наблюдаю возрождение этой идеи с завидной регулярностью.
То есть дело не в том, что я не понимаю, как это работает — я этот этап уже прошёл.

Y>кто-то писал: "Вместо популярного лет 10 уже паттерна query language, который бы позволял просто искать в стиле "статус:закрыт И период текущий месяц)" мы имеем сочетание комбобоксов и свободнотекстового поля ввода"

Y>Есть и такой конструктор запросов:
Y>Image: core12.jpg
Вы неверно понимаете мои аргументы. Дело не в конструкторе или деструкторе запросов. Речь о сценарии работы. Давайте рассмотрим подробнее паттерн, о котором я говорю.
Когда я ищу письмо в аутлуке, я могу написать просто

brent

Это мне найдёт все письма, где брент — отправитель, или получатель, или упомянут в тексте.
Если писем слишком много, я могу уточнить запрос вот так:

from:brent

Мне не надо возить мышкой, чтобы строить предикат типа "Атрибут: скролл-скролл-скролл-скролл... Имя Отправителя. Операция: клик-клик... равно содержит. b-r-e-n-t". Я просто пишу текст.
Я могу уточнить поиск, написав (опять в тексте! Безо всяких кликов, драг-н-дропов и прицеливаний в выпадающие окошки)

from:brent AND sent:August 2019

При этом, естественно, работает автодополнение.
Что это мне даёт? Всю мощь работы с текстом: то есть я могу редактировать запрос при помощи copy-paste. Автодополнение помнит мои запросы, поэтому если я часто ищу закрытые заказы, то достаточно набрать "ст", чтобы поиск предложил мне дополнить его до "статус:закрыт". И все остальные варианты запроса, вроде "статус:закрыт И закрыт>неделя назад", "статус:закрыт И закрыт:сегодня" тоже показаны прямо тут, достаточно пару раз нажать "вниз" и enter.

В чём преимущество? В пологой кривой обучения: вначале работы всё, что я умею — вводить буковки в поле ввода. Когда я осваиваю "конструктор фильтров", построенный в виде тех самых кнопочек/дропдаунов, то он строит именно текст — и если сначала я выбирал фильтр "закрытые за неделю" через меню, то через пару дней я уже запоминаю, как это пишется. Система подстраивается под меня, и в итоге я получаю доступ к фильтрам, актуальным именно для меня, буквально за пару кликов. Независимо от количества условий. Очень легко делать функции типа "сохранить как именованный фильтр", как это сделано в той же Jira.

Y>Конструктор умеет отображать данные в двух представлениях: табличное и карточное. Данные ищутся в табличной части а работа с данными может быть и в таблице и в карточке. Так вот конструктор как раз позволяет по требованию заказчика оперативно поменять представление.


Y>и вот как выполнено требование заказчика. В конструкторе снято 3 галки и затем перемещением мыши таблицы разложены так как укажет заказчик интерфейса. Возможно скорость и не важна но это заняло около 2 минут.

Y>Image: core14.jpg
Ок. А стало ли лучше? Во-первых, всё ещё кто-то должен сесть, и "заказать интерфейс". То есть проделать всю ту работу по проработке сценариев, про которую я говорил.
Во-вторых, потом надо ещё и выразить эти сценарии в терминах блоков конструктора. Вот вы за две минуты "решили" задачу "показать одновременно платежи, работы, и материалы".
Начнём с платежей. Они по-прежнему свалены в таблицу. Занято дочерта места (~7 строк) под бессмысленные заголовки, скроллбары и кнопки навигации. Это примерно как использовать рамный джип для того, чтобы тарелку с завтраком везти от кухни до дивана. В реальном UI достаточно одной строки: "Оплата: 100% (18 сентября: 2000р нал через кассу)". Если платежей несколько, то строка выглядит так: "Оплата: 100% (18 сентября: 1500р VISA, 500р нал через кассу)".
Если оплата неполная, то выглядит так: "Оплата: 25% (18 сентября: 500р нал через кассу) [+])
Таким образом, мы экономим место для действительно важных вещей на экране. Почитайте классиков — Нильсена, Тафти. У вас весь экран загажен chrome и non-data ink.

Далее — работы и материалы. В UI никак не видна связь между работами и материалами, что провоцирует на ошибки — например, есть работа по замене клавиатуры, а самой клавиатуры в заказе нет.
Неверно выполнена декомпозиция задачи. Очевидно, вместо "работ" и "материалов" должны быть "операции", которые, в свою очередь, требуют "работ" и "материалов". Попытка выразить эту идею при помощи конструктора эту идею попросту убьёт, т.к. у нас будет уже три уровня иерархии таблиц master-detail.
Очевидный способ решения — это список операций в не-табличном виде:

- замена аккумулятора: 500 р (работа: 500р, аккумулятор: 0р [+])
— замена экрана: 1100р (работа: 500р, матрица экрана: 600р [+])
[+]
Итого Работы: 1000р [Сделать скидку]
Итого Материалы: 600р

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

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

Y>Конструкторы идеальны для решения прикладных задач и когда есть необходимость постоянной доработки или переработки интерфейса.

Скорее наоборот: использование конструкторов гарантирует необходимость постоянной доработки или переработки интерфейса.
Y>То что этот и похожие конструкторы "говно" — даже не поддаётся сомнению — это так! Только ручное создание и изменение форм и тысячи строк кода позволяют нам всем намазывать масло на хлеб.
Конструкторы, на самом деле, хорошая и правильная идея. Проблема — в их ориентации на структуру данных, а не на пользовательские задачи. При этом выбор выразительных средств крайне ограничен: для списков у нас есть только "грид", а он хорошо работает для очень специфических данных.

Кроме того, основная критика всё же не в адрес конструкторов, а в адрес авто-генераторов.
Конструктор подразумевает хоть какое-то участие человека, который может попытаться применить здравый смысл и дополнительные знания — например о том, что в типичном заказе 200 строк "деталей" и только 1 платёж, а не наоборот.

Автогенератор ничего этого не знает, он видит список с кардинальностью 0..∞, и хреначит его в таблицу. Он видит набор из 30 свойств у объекта, и хреначит их всех в колонки. У него нет данных о том, какие свойства являются важными, а какие — нет; какие используются редко, а какие — часто. В итоге получаем разрежённые гриды, которые одновременно показывают слишком много всего и слишком мало всего.
Прикладной программист начинает приносить структуру в жертву богу конструктора. Например, он интуитивно понимает, что колонки "Фамилия, Имя, Отчество" — это какой-то треш, подавляет их вывод в генератор атрибутами, и придумывает вычисляемое свойство ФИО, которое клеит всё вместе, борется с лишними пробелами при отсутствующем отчестве, и изобретает специальный контрол, который используется для ввода такого "композитного" свойства.

Всё это время стоило бы потратить на дополнительные исследования реальной задачи — как раз чтобы знать, что встречается часто, а что — редко. Less is more — идеальный UX должен как показывать как можно меньше мусора, и задавать как можно меньше вопросов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 19.09.19 06:49
Оценка:
Здравствуйте, yukosoft, Вы писали:

Y>Конструкторы идеальны для решения прикладных задач и когда есть необходимость постоянной доработки или переработки интерфейса. Никто не говорит о том что на конструкторах нужно писать систему реального времени управления взлётом и посадкой самолётов.


Понимаете, это для вас (как автора) данный конструктор выглядит как очевидное средство для создания форм, а для меня это просто нагромождение гридов и контролов. Где я должен искать эти три галки (почему не четыре или не одну)), как я должен об этом узнать?

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

При этом иногда все-равно надо дорабатывать формы "руками". Как это сделает человек, обученный только работе в конструкторе? Ему сначала придется пройти долгий и нелегкий путь до опытного разработчика.

То есть целевая группа среди разработчиков практически отсутсвует. Использование подобных продуктов возможно только, если автор работает где-то рядом (вот он велосипед), или по решению высокого начальства (кровавый энтерпрайз).
Re[5]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 19.09.19 07:39
Оценка:
Здравствуйте, yukosoft, Вы писали:

Y>кто-то писал что это реклама... На форуме программистов рекламировать конструктор который не продаётся это реклама?


Подтверждаю, с автором даже не знаком.

Расскажите подробнее сколько времени ушло на написание и планируете ли продавать?
Re[6]: Многие делают - но каждый свой велосипед
От: yukosoft  
Дата: 19.09.19 08:28
Оценка: 78 (1)
Вот поиск текстом



Выбор работ и товаров это 10% от всех возможностей. И если конструктор поможет сделать 90% работы а остальные 10% нужно будет сделать "руками" то это ли не то ради чего всё делается?
Если от заказчика поступает запрос на неудобство работы с товарами и работами и он требует переделать всё на такую систему:

— замена аккумулятора: 500 р (работа: 500р, аккумулятор: 0р [+])
— замена экрана: 1100р (работа: 500р, матрица экрана: 600р [+])
[+]
Итого Работы: 1000р [Сделать скидку]
Итого Материалы: 600р

то обсуждается сроки и стоимость и делается такая система подбора в кастомной форме. И это не мешает использовать конструктор.

Опытному разработчику конструктор не нужен. Он нужен опытному руководителю.

Очень многие крупные софтверные и не софтверные конторы уже давно сделали свой "конструктор" для внутреннего использования и сидят на нём. Новички не могут ничего сломать так как уровень доступа ограничен. Профи действуют в рамках конструктора и поэтому результата всегда одинаково хороший. Гуру изредка правят конструктор.

Этот конструктор просто как пример одного из многих (просто мало кто готов показать свои велосипеды и смотреть как тычут пальцем — "говно").
Подобный конструктор пишется за 2-3 года и затем дописывается всю его жизнь.
Re[7]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 19.09.19 09:01
Оценка:
Здравствуйте, yukosoft, Вы писали:

Y>Вот поиск текстом


Но это же все фичи компонентов DevExpress. Если делать эти формы в студии, будет всё тоже самое.

Y>Этот конструктор просто как пример одного из многих (просто мало кто готов показать свои велосипеды и смотреть как тычут пальцем — "говно").

Y>Подобный конструктор пишется за 2-3 года и затем дописывается всю его жизнь.

А сколько новый сотрудник въезжает в работу, прежде чем перестает задавать уточняюшие вопросы?
Re[8]: Многие делают - но каждый свой велосипед
От: yukosoft  
Дата: 19.09.19 09:43
Оценка:
A>А сколько новый сотрудник въезжает в работу, прежде чем перестает задавать уточняюшие вопросы?

Это зависит от изначальной "стоимости" нового сотрудника и от его опыта. Если есть минимальный опыт работы с таблицами в любой базе данных то разобраться можно за месяц испытательного срока.
Re[9]: Многие делают - но каждый свой велосипед
От: amironov79  
Дата: 19.09.19 11:05
Оценка:
Здравствуйте, yukosoft, Вы писали:

Y>Это зависит от изначальной "стоимости" нового сотрудника и от его опыта. Если есть минимальный опыт работы с таблицами в любой базе данных то разобраться можно за месяц испытательного срока.


То есть стоимость сотрудника все-таки имеет значение? А то я изначально понял, что любой человек с улицы сразу начнет клепать по форме в час.
Re[4]: MS делают видео вместо статей - где разум?
От: MadHuman Россия  
Дата: 20.09.19 08:03
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Проектирование нормальных приложений идёт не от структуры данных, а от сценариев. Что люди делают с этой "формой"? Ищут заказы, создают новые заказы, изменяют существующие? Ответ "всё это, и ещё 12 действий из контекстного меню" не подходит — надо разобраться во всех из них. Классифицировать пользователей по ролям, для каждой роли знать относительные частоты всех сценариев.

Да, всё так. Но это работа не программиста, а аналитика, проектировщика интерфейсов. Уже после всей этой работы разработчик и получает ТЗ в виде конкретного экрана/формы и его дело его реализовать.
Дело же не в той конкретной форме. Мысль Shmj о том, что интерфейсы (которые предположим что уже обдуманы аналитиком и проектировщиком интерфейсов) проще и быстрее конфигурировать чем программировать ручками.
Более того во многих случаях, когда платформа позволяет, аналитики в состоянии вносить изменения в интерфейсы, не привлекая программистов.
Re[5]: MS делают видео вместо статей - где разум?
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.09.19 09:15
Оценка:
Здравствуйте, MadHuman, Вы писали:
MH>Да, всё так. Но это работа не программиста, а аналитика, проектировщика интерфейсов. Уже после всей этой работы разработчик и получает ТЗ в виде конкретного экрана/формы и его дело его реализовать.
MH>Дело же не в той конкретной форме. Мысль Shmj о том, что интерфейсы (которые предположим что уже обдуманы аналитиком и проектировщиком интерфейсов) проще и быстрее конфигурировать чем программировать ручками.
MH>Более того во многих случаях, когда платформа позволяет, аналитики в состоянии вносить изменения в интерфейсы, не привлекая программистов.
Ну, вообще-то исходная мысль Shmj была ровно о том, что интерфейс должен возникать сам из описания структуры данных, безо всяких там аналитиков.
Если же мы отказываемся от этой мысли, то у нас остаётся что? Собственно, реализация интерфейса. Он строится из каких-то кусочков, кирпичиков.
Кирпичики укладываются в формы, свёрстанные определённым образом.
Где лежит граница между программированием и конфигурированием? Вон, ещё в Delphi можно было быстро накидать контролов на форму, понастраивать свойства, привязать их друг к другу и получить работающее приложение, не написав ни строчки кода.

1. Внесение изменений "на лету". То есть при визуальном программировании в той же Delphi или Visual Studio мы всё же должны выполнить компиляцию и деплоймент, чтобы изменения увидел клиент. "Конфигуратор" потенциально даёт возможность править формы без перезапуска приложения.
На практике, для веб приложений деплоймент не сложнее кнопки Save. В том смысле, что у всех 10000 клиентов новая версия появляется одновременно, без даунтаймов и беготни с дискеткой по машинам.
Зато принуждение хранить дизайн в исходниках позволяет, как я уже говорил, пользоваться контролем версий. Если правка формы сломала приложение, то версионированные исходники позволят нам оперативно вернуть всё назад. Конфигурация, сохраняемая "в базу" таких плюшек не даёт — придётся весь тулчейн изобретать заново.

2. Состав кирпичиков. Аналитик с опытом работы неизбежно привыкает мыслить в рамках конструктора. Хорошие решения ему уже даже в голову не приходят; он сразу мыслит "вот тут будет грид, тут табы, тут тулбар". Даже если ему приходит в голову хорошая мысль, то он отбрасывает её как заведомо трудную в реализации. Типа "ну, грид с деревом и тулбаром я и сам накидаю; а за интерактивной картинкой придётся идти к разработчикам и дизайнерам, это минимум месяц ждать. Ну его".
В принципе, это можно было бы решить при помощи более могучего набора кирпичей. То, что мы видим сейчас в гуй-конструкторах — то же, что в 1994 году. Чуть другие формы кнопок, а так всё то же самое. Гриды, табы, тулбары, деревья. Дропдаун, спиннер, календарь. TreeGrid как венец сложности контрола; динамический докинг как венец кастомизации гуя пользователем. Полный тупик, уныние, казарма.

Единственная система с мало-мальски другой парадигмой форм ввода, которую я видел за последние 20 лет, была Lotus Notes. Увы, канула в небытие, раздавлена мейнстримом. Там, похоже, в какой-то момент ушёл последний человек, который понимал в usability, а наследники быстро развалили все достижения, став на несколько лет завсегдатаями WTF сайтов.

Фокус разработки usable софта переместился сначала в веб, потом в мобилки. На десктопе мы безнадёжно застряли в девяностых. Впрочем, веб — немногим лучше. Сайтов, которые было бы реально удобно использовать — единицы. Более-менее приемлемо работают только топовые мобильные приложения. И то — в каждом найдётся, за что поругать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Многие делают - но каждый свой велосипед
От: ltc  
Дата: 20.09.19 09:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>"Конфигурации" ничего этого не умеют. В лучшем случае они живут в текстовых файлах, которые можно засунуть в VCS.

S>В вашем случае они живут в базе; это означает, что вообще никто не знает, что там стоит у заказчика. Нет понятия "версия", нет blame, нет changelog, нет веток, нет confliсt resolution.
S>Такие решения создают больше проблем, чем решают. Пишется-то система быстро, а вот стоимость поддержки начинает зашкаливать.

Безотносительно здравости изначальной идеи запихивать все в базу: в чем проблема с версионностью, контролем версий, ветками и конфликтами? Вся конфигурация базы задается через скрипт, который и лежит в сорсконтроле, и версию проставляет-проверяет в базе.
Re[2]: Преимущества чистого кодогенератора
От: ltc  
Дата: 20.09.19 10:01
Оценка:
Здравствуйте, L_G, Вы писали:

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


L_G>Из разных архитектурных вариантов подобной "среды" для себя остановился на варианте кодогенератора, который на основе структуры БД + какого-то дополнительного простого метаописания генерировал бы примерно такой же код, какой бы написал вручную сам программист. После этого код можно дорабатывать как обычно, стандартными средствами. А можно продолжать использовать генератор. При этом, возможно, придется вручную выделять из заново генерируемого кода нужные куски и вставлять их в нужные места основного кода. Скорее всего, при желании можно будет изолировать автоматически генерируемый код от подвергаемого ручным правкам.


L_G>Вроде бы это вписывается в термин "scaffolding". (Он используется почему-то только в веб-программировании, до которого я пока не добрался.)


Один из серьезнейших недостатков подобного подхода это отсутствие "инкрементальности". Сгенерили по модели один раз, руками поправили чтобы было красиво. Тут модель дополняется и надо либо генерить заново и опять руками править или же плюнуть на скаффолдинг и вносить дополнения вручную. А если вносить вручную, то надо все равно по полной разбираться в итоговом коде и вникать во все детали, которых хотелось бы избежать, переложив все на генератор.

Я считаю, что можно было бы данный недостаток побороть, используя автоматический мерж. Только мержить надо не плейн-текст, а синтаксические деревья. Причем не абстрактные, а конкретные, чтобы все форматирование сохранилось.
Re[6]: MS делают видео вместо статей - где разум?
От: MadHuman Россия  
Дата: 20.09.19 10:09
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

S>Где лежит граница между программированием и конфигурированием? Вон, ещё в Delphi можно было быстро накидать контролов на форму, понастраивать свойства, привязать их друг к другу и получить работающее приложение, не написав ни строчки кода.

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

S>Зато принуждение хранить дизайн в исходниках позволяет, как я уже говорил, пользоваться контролем версий. Если правка формы сломала приложение, то версионированные исходники позволят нам оперативно вернуть всё назад. Конфигурация, сохраняемая "в базу" таких плюшек не даёт — придётся весь тулчейн изобретать заново.

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


S>2. Состав кирпичиков. Аналитик с опытом работы неизбежно привыкает мыслить в рамках конструктора. Хорошие решения ему уже даже в голову не приходят; он сразу мыслит "вот тут будет грид, тут табы, тут тулбар".

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


S>Единственная система с мало-мальски другой парадигмой форм ввода, которую я видел за последние 20 лет, была Lotus Notes. Увы, канула в небытие, раздавлена мейнстримом. Там, похоже, в какой-то момент ушёл последний человек, который понимал в usability, а наследники быстро развалили все достижения, став на несколько лет завсегдатаями WTF сайтов.

ну как же, 1с вполне нормальная платформа для учетных решений. хотя я и не являюсь их сторонником, но справедливости ради.


S>Фокус разработки usable софта переместился сначала в веб, потом в мобилки. На десктопе мы безнадёжно застряли в девяностых. Впрочем, веб — немногим лучше. Сайтов, которые было бы реально удобно использовать — единицы. Более-менее приемлемо работают только топовые мобильные приложения. И то — в каждом найдётся, за что поругать.

сайты, мобильный приложения, это всё таки другой класс приложений, это не учетные приложения для корп. использования, где оправданы конфигураторы, о которых трэд.
Re[5]: Многие делают - но каждый свой велосипед
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.09.19 10:18
Оценка:
Здравствуйте, ltc, Вы писали:
ltc>Безотносительно здравости изначальной идеи запихивать все в базу: в чем проблема с версионностью, контролем версий, ветками и конфликтами? Вся конфигурация базы задается через скрипт, который и лежит в сорсконтроле, и версию проставляет-проверяет в базе.
Ээээ что?
Вот у вас бегает ентерпрайз-приложение. Бегает пять лет. База — полсотни гигабайт.
Где-то в этой базе хранятся описания формочек, которые правятся штатным аналитиком при помощи штатного конструктора форм без перезапуска приложения.
Вот в пятницу аналитик что-то напорол, и форма разъехалась. Что мы будем делать в понедельник?
Из какого сорс контрола и какой скрипт мы будем поднимать? Или мы будем поднимать всю базу из четвергового бэкапа, с потерей всех продаж и и т.п. за пятницу и выходные?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: MS делают видео вместо статей - где разум?
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.09.19 10:21
Оценка: +1
Здравствуйте, MadHuman, Вы писали:

MH>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.

Ну, так современное программирование гуя — это оно и есть. Если мы отбросим бредовые идеи "создавать ГУИ по схеме данных" и "хранить описание ГУИ в СУБД", то останется совершенно нормальное программирование на обычном современном языке.

MH>ну как же, 1с вполне нормальная платформа для учетных решений. хотя я и не являюсь их сторонником, но справедливости ради.

1с — то же самое, вид сбоку. Для 90х — офигенная штука. С точки зрения юзабилити — твёрдые 3 с минусом.

MH>сайты, мобильный приложения, это всё таки другой класс приложений, это не учетные приложения для корп. использования, где оправданы конфигураторы, о которых трэд.

Угу. Потому что за пользование "нормальными" приложениями платит пользователь, а за пользование корпоративными платят пользователю. Поэтому пусть терпят.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Многие делают - но каждый свой велосипед
От: ltc  
Дата: 20.09.19 10:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

ltc>>Безотносительно здравости изначальной идеи запихивать все в базу: в чем проблема с версионностью, контролем версий, ветками и конфликтами? Вся конфигурация базы задается через скрипт, который и лежит в сорсконтроле, и версию проставляет-проверяет в базе.

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


Хм. Я, видимо, недостаточно въехал в контекст.
Если формочки постоянно правятся без изменения схемы базы данных, то почем нельзя относиться к ним как к обычным данным (коими они и являются в таком случае)?
Если нам важна история данных — то не апдейтим, а инсертим, по дефолту используем последнее добавленное. В таком случае откат на любое предыдущее состояние тривиален.
Re[3]: Преимущества чистого кодогенератора
От: L_G Россия  
Дата: 20.09.19 11:09
Оценка:
ltc>Один из серьезнейших недостатков подобного подхода это отсутствие "инкрементальности".

ltc>Я считаю, что можно было бы данный недостаток побороть, используя автоматический мерж. Только мержить надо не плейн-текст, а синтаксические деревья. Причем не абстрактные, а конкретные, чтобы все форматирование сохранилось.


partial class не зря же придуманы.
в winforms вроде всё неплохо решено — в автоматически генерируемые *.designer.cs лезть никакой нужды нет.
я бы к аналогу этого стремился.
Re[4]: Преимущества чистого кодогенератора
От: ltc  
Дата: 20.09.19 12:23
Оценка:
Здравствуйте, L_G, Вы писали:

ltc>>Один из серьезнейших недостатков подобного подхода это отсутствие "инкрементальности".


ltc>>Я считаю, что можно было бы данный недостаток побороть, используя автоматический мерж. Только мержить надо не плейн-текст, а синтаксические деревья. Причем не абстрактные, а конкретные, чтобы все форматирование сохранилось.


L_G>partial class не зря же придуманы.


А чем бы они помогли? Вот генератор создал что-то, функционирующий набросок UI. Теперь я хочу его адаптировать по своему вкусу, что-то поправить. А потом средствами того же генератора учесть обновления в модели.

L_G>в winforms вроде всё неплохо решено — в автоматически генерируемые *.designer.cs лезть никакой нужды нет.


Не, там другое, там же практически взаимнооднозначная конвертация получается. Это просто два представления одного и того же.
Re[7]: Многие делают - но каждый свой велосипед
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.09.19 12:30
Оценка: +1
Здравствуйте, ltc, Вы писали:
ltc>Хм. Я, видимо, недостаточно въехал в контекст.
ltc>Если формочки постоянно правятся без изменения схемы базы данных, то почем нельзя относиться к ним как к обычным данным (коими они и являются в таком случае)?
Потому что жизненный цикл учётных данных и жизненный цикл формочек отличаются. Ваш К.О.
ltc>Если нам важна история данных — то не апдейтим, а инсертим, по дефолту используем последнее добавленное. В таком случае откат на любое предыдущее состояние тривиален.
Ну вот, вы уже начинаете изобретать тот тулчейн, который ведущие компании писали тридцать и более лет. Все вот эти blame, merge, branch, и прочие code review.
В теории так можно сделать. Но тогда вы получите ровно то же программирование форм, вид сбоку. Зачем?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: MS делают видео вместо статей - где разум?
От: Ночной Смотрящий Россия  
Дата: 20.09.19 14:35
Оценка:
Здравствуйте, MadHuman, Вы писали:

MH>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.


И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[8]: MS делают видео вместо статей - где разум?
От: MadHuman Россия  
Дата: 20.09.19 14:52
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:


MH>>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.


НС>И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML

Я бы не был столь категоричен к примеру графические конструкторы сайтов бурно плодятся и развиваются, по сути в итоге рождая html на основе накликанных и сконфигурённых энд-юзером высокоуровневых блоков.
Нельзя говорить что что-то однозначно всегда лучше, панацей небывает.
И тот и иной подход имеет смысл, важно понимать когда. Вообщем как и с любой другой технологией, важно понимать рамки её применимости и бонусы и недостатки.
Re[9]: MS делают видео вместо статей - где разум?
От: Ночной Смотрящий Россия  
Дата: 20.09.19 14:54
Оценка:
Здравствуйте, MadHuman, Вы писали:

НС>>И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML

MH>Я бы не был столь категоричен к примеру графические конструкторы сайтов бурно плодятся и развиваются, по сути в итоге рождая html на основе накликанных и сконфигурённых энд-юзером высокоуровневых блоков.

Только реальное применение всех этих конструкторов ограничивается сайтами-визитками.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Преимущества чистого кодогенератора
От: L_G Россия  
Дата: 20.09.19 15:50
Оценка:
ltc>А чем бы они помогли? Вот генератор создал что-то, функционирующий набросок UI. Теперь я хочу его адаптировать по своему вкусу, что-то поправить. А потом средствами того же генератора учесть обновления в модели.

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

ltc>Не, там другое, там же практически взаимнооднозначная конвертация получается. Это просто два представления одного и того же.


я про разделение кода формы на пару файлов — полностью генерируемый (form1.designer.cs) и редактируемый программистом (form1.cs)
Re[6]: MS делают видео вместо статей - где разум?
От: Shmj Ниоткуда  
Дата: 20.09.19 17:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Фокус разработки usable софта переместился сначала в веб, потом в мобилки. На десктопе мы безнадёжно застряли в девяностых.


На самом деле 90-е были не так уж плохи в плане юзабилити...
Re[8]: Многие делают - но каждый свой велосипед
От: ltc  
Дата: 23.09.19 09:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

ltc>>Если нам важна история данных — то не апдейтим, а инсертим, по дефолту используем последнее добавленное. В таком случае откат на любое предыдущее состояние тривиален.

S>Ну вот, вы уже начинаете изобретать тот тулчейн, который ведущие компании писали тридцать и более лет. Все вот эти blame, merge, branch, и прочие code review.
S>В теории так можно сделать. Но тогда вы получите ровно то же программирование форм, вид сбоку. Зачем?

Я в данном треде не утверждаю, что это правильный путь. Просто отметил, что при желании вопросы с версионностью, восстановлением и т.д. технически разрешимы.
Re[9]: Многие делают - но каждый свой велосипед
От: Shmj Ниоткуда  
Дата: 25.09.19 12:02
Оценка:
Здравствуйте, ltc, Вы писали:

ltc>Я в данном треде не утверждаю, что это правильный путь. Просто отметил, что при желании вопросы с версионностью, восстановлением и т.д. технически разрешимы.


У нас чувак делал простой список изменения MS SQL процедур, с возможностью посмотреть diff (примерно как на RSDN версии редактирования).
Re[10]: Многие делают - но каждый свой велосипед
От: Ночной Смотрящий Россия  
Дата: 25.09.19 14:55
Оценка:
Здравствуйте, Shmj, Вы писали:

S>У нас чувак делал простой список изменения MS SQL процедур, с возможностью посмотреть diff (примерно как на RSDN версии редактирования).


Ну и нафига, если есть SSDT?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: MS делают видео вместо статей - где разум?
От: Silver_S Ниоткуда  
Дата: 01.10.19 11:50
Оценка:
Здравствуйте, Kolesiki, Вы писали:

Y>>В будущем огромный пласт программистов средней руки исчезнет

K> Эх, мечтатели!... Вы прям как те ЛИСПеры с горящими глазами, каких-то 30 лет назад предсказывающие ровно такой же "коллапс посредственностей". А воз? Он и ныне там.

Воз уже не там. Уже большой пласт отделился, стали конфигураторами 1C, а не программистами. На рынке труда не мало такой работы.
Re[8]: MS делают видео вместо статей - где разум?
От: Silver_S Ниоткуда  
Дата: 01.10.19 13:20
Оценка:
Здравствуйте, Sinclair, Вы писали:

MH>>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.

S>Ну, так современное программирование гуя — это оно и есть. Если мы отбросим бредовые идеи "создавать ГУИ по схеме данных" и "хранить описание ГУИ в СУБД", то останется совершенно нормальное программирование на обычном современном языке.

Прорыв в автоматизации такой работы случится, ИМХО, после того как появится эффективный промежуточный уровень — схема данных для пользователя, по которому автоматически строится GUI, с кастомизацией.
И решатся проблемы синхронизации серверной и пользовательской схемы данных при изменениях. Проблемы с производительностью, когда данные проходят через этот промежуточный уровень в обе стороны.
И проблемы написания логики, то ли в БД то ли в этой пользовательской схеме.
Возможно, с новым специализированным ЯП для этого.
По сложности правильно сделать этот промежуточный уровень не меньше чем создать сам SQL Server, или больше (всякие EntityFramework это пока баловство).
Но рано или поздно, оно точно постепенно появится.

MH>>ну как же, 1с вполне нормальная платформа для учетных решений. хотя я и не являюсь их сторонником, но справедливости ради.

S>1с — то же самое, вид сбоку. Для 90х — офигенная штука. С точки зрения юзабилити — твёрдые 3 с минусом.

И все таки 1C — конфигураторщики отобрали много работы у тех кто врукопашную все делает. Уже очень большая ниша когда выгоднее использовать такое решение.
Отредактировано 01.10.2019 13:23 Silver_S . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.