Очень хотелось бы иметь возможность (при выполнении многоэтапной процедуры) пройтись по всем шагам и просто посмотреть, что есть где (параллельно с описанием каждого шага: что на нём делается, куда и в каком виде вводится).
Замечу, что заполнение любой формы также можно превратить в многоэтапный процесс. При этом, у пользователя будет понимание того, что он пока ещё только заполняет форму, и только в конце у него будет кнопочка "Применить/Отослать/Запустить".
Недавно встретился с ситуацией: вводишь в поле текст, нажимаешь кнопку "Отправить", окно пропадает, но ничего не происходит, ничего никуда не отправляется. Дело оказалось в том, что в поле имелся лимит на количество символов, но про этот лимит пользователю ничего сообщалось.
Самое больное место систем — это отсутствие точного и понятного отображения текущего состояния. Хорошее понимание текущего состояния — залог спокойствия пользователя.
Треть университетской программы, по мнению Тайлера Коуэна, должна быть посвящена тому, как использовать ИИ и понимать его границы.
А это, вообще, кто-то понимает? ИИ — это серый ящик: что-то видно, но всё, на деле, превращается с кота Шрёдингера (или в Шрёдингера кода?). Когда будет понятно, что ИИ ничего не меняет по сути, а только перераспределяет нагрузки и ретуширует проблемы, уйдёт много лет. Образование должно учить только одному: умению думать. А вот с этим ИИ, похоже, человечество может совсем с ума сойти.
Да, и, конечно. Любая автоматизация предполагает обобщение опыта. А где это обобщение? Просто взяли набор задач и сопоставили ему набор решений, и, использовали, при этом, кучу практических примеров. А где, собственно, обобщение опыта разработки? Для этого надо как-то зафиксировать траекторию разработки реальных систем, а этого никто и никогда не делал и делать не будет! А было бы чрезвычайно интересно посмотреть на готовые системы, историю их разработки. А ещё интереснее было бы понять, как можно было бы разработать туже систему, но за один заход, без растянутого во времени процесса порождения/преодоления ошибок. Ответ на этот вопрос и есть то, в чём заключается подлинная автоматизация, и то, что должен сделать ИИ. Но! Если мы поймём, как это сделать, то зачем нам, тогда, будет нужен ИИ?
Во всех этих рассуждениях как-то пропускается алгоритмическая неразрешимость задачи проверки соответствия программы заданной спецификации. Специалисты по ИИ, наоборот, считают, что статистическими методами, дополнительно вооружёнными механизмами внимания, рассуждения и состязательности, можно удовлетворительно "сойтись" практически к любому решению, и человеческий мозг, в каком-то смысле, сам таким же статистическим образом "сходится" к решению поставленной задачи. А если вспомнить про концепцию "русел" и "джокеров", то вся "болтанка" в результата применения ИИ объясняется тем, то "джокеры" буквально пронизывают всё пространство параметров.
Настоящая автоматизация создания ПО связана с построением моделей, ибо всякий код должен соответствовать некоторой спецификации, а модель — это и есть спецификация. Соответственно, результатом применения ИИ должна быть спецификация — некая формальная спецификация, где для каждого возможного изменения указывается результат. Другими словами, мы должны получить на выходе некое пространство моделей. Разработка ПО — это некая траектория в этом пространстве. А до тех пор, пока ничего этого нет, говорить об автоматизации не приходится.
Так что если вы разрабатываете интерфейсы — хотя бы один раз в проекте сядьте за спину живому пользователю. Вы узнаете в разы больше, чем из опросов, интервью или метрик.
Можно и самому превратиться в пользователя, хотя это очень трудно, отрешиться от знания системы. В этом смысле, автор программы — "испорченный испытуемый", и, действительно, лучше наблюдать за действиями других.
А, вот, то, что касается выбора марки автомобиля (и любого другого выбора, аналогичного данному), то лучше всего иметь на экране буквенную клавиатуру, поле ввода и поле для быстрого выбора (где показывать очень небольшое количество вариантов, зависящее от размеров экрана).
С модификациями труднее. Всегда надо иметь под рукой более развернутое (и разворачивающееся в виде иерархии) описание каждой модели, чтобы пользователь мог бы найти свой вариант.
В базах данных традиционно использовалось понятие домена (уж, извините) в смысле диапазона допустимых значений. Это значит, что при описании таблицы мы ложны указывать домен, а не конкретный тип. У каждой сущности может быть довольно богатое семантическое окружение. Домен включает в себя способ управления хранимыми значениями. В Вашем примере, речь идёт о сущности, которая позволяет определённым образом упорядочить пользователей по некоторой шкале. При этом, в различных ситуациях могут использоваться различные подходы/способы. Вот для реализации этих способов и вводится более "толстый" столбец, который уже не сводится какому-то одному типу данных вроде даты.
Ещё один такой пример — это "Фамилия Имя Отчество". В различных ситуациях, требуются различные представления (как полные, так и сокращённые).
У меня такой вопрос: а почему мы обнаруживаем код, явным образом описывающий логику работы приложения? И что это за код? Это код конечного реализуемого приложения? Почему в коде явным образом указывается условие поиска, почему это условие не фигурирует в пользовательском интерфейсе (как один из вариантов)?
А что это такое? По моим узким представлениям, это т.н. сущности, то есть — набор базовых понятий, с которыми мы имеем дело: пользователи, контрагенты, заказы, товары, склады и т.д. и т.п.
Диаграмма хорошо спроектированных классов всегда вызывает эстетическое наслаждение, она элегантна и лаконична.
А почему это должна быть именно диаграмма классов? Тут ещё и вопрос в том, на каком этапе эта диаграмма используется. Можно себе представить, что эта диаграмма может использоваться на этапе разработки для общения с экспертами в выбранной предметной области, но на этапе реализации эта диаграмма может быть отображена на что-то совсем другое.
Если она относительна проста - эти дополнительные усилия никогда не окупятся. И в этом случае вам не просто не нужны хорошо проработанные entities – вам вообще не нужно отделять доменный слой от application layer, это всё – лишняя работа, целиком. Но если предметная область окажется достаточно сложна, то попытка обойтись более простыми методами может привести к тому, что ваш проект со временем флопнется...
Может быть, стоит всегда отделять один слой от другого?
Давайте посмотрим на этот вопрос, собственно, с точки зрения разработки программного обеспечения. У нас есть: (1) сущности предметной области; (2) сущности языка программирования (всякие там структуры); и (3) те сущности, которые мы выстраиваем на базе сущностей (2), чтобы воспроизвести сущности (1).
Предположим, у нес есть таблица покупок Покупки, каждая строка которой описывает отдельный купленный товар (наименование, цена, количество и стоимость). Покупки, сделанные за одно посещение (одного и того же магазина), естественным образом группируются в блоки, и мы можем ввести новую сущность ПосещениеМагазина (дата и время, название магазина). В реляционной базе данных естественным образом возникают две таблицы: основная (содержащая первичные ключи) и подчинённая (ссылающаяся на основную при помощи вторичных ключей). Мы понимаем, что стоимость — это вычисляемый столбец, который можно не хранить в базе данных, но мы можем воспринимать таблицу покупок как документальное выражение результатов действий покупателей. Далее, цены бывают разные. Мы фиксируем в таблице ту цену, по которой нам фактически продали купленный нами товар. Но есть разные цены. Есть базовая цена товара (и, при этом, на определённую дату!), а есть цена со скидкой, разные скидки (сезонные, по акции, накопительные и т.д. и т.п.). Мы можем усложнить таблицу покупок, и вести параллельный учёт различных цен, определяя фактический размер скидки простыми запросами к данной таблице. Если посмотреть в сторону магазинов, то у магазинов есть адреса (ещё одна сущность!), а это значит, что нам нужен справочник адресов. Не очень буйная фантазия представляет этот справочник как иерархический, так что при выборе адреса можно выбирать требуемый уровень (город/улица/дом/корпус/строение). Попутно заметим, что в каждом магазине может быть принята своя система наименования товаров, нам же нужны исходные данные, а это значит, что нам нужен такой же иерархический справочник Номенклатура. И ещё. Посещение магазина — это некое точечное событие. Мы может иметь единую таблицу, где описываются такие события, и тогда мы таким же единым образом будем описывать и Ваше посещение магазина, и приезд к Вам курьера, и помещение на склад продукции, и приход в научно-исследовательский институт государственного задания, по которому этот самый НИИ получает бюджетное финансирование. И это всё суть какие-то события, а это снова отдельная сущность. И если Вы её выделяете, и тратите дополнительные усилия на реализацию этой сущности (элемент семантики), то Вы получаете мощный механизм управления своими данными. Таким образом, важнейший вопрос — это вопрос о том, а какие на самом деле должны быть сущности, чтобы отобразить домены (сущности) предметной области, на сущности (классы/объекты) языка программирования.
Пытаюсь перевести на русский язык. Получается что-то вроде разработки, определяемой предметной областью.
Если вы автоматизируете работу предприятия, существующая организационная структура всегда будет прекрасной стартовой точкой.
Я предполагаю, что одну и ту же организационную структуру можно отобразить весьма различным способом. И это будет существенным образом зависеть от того, что и как будет называться нами в этой системе.
И, в большинстве случаев, на макро-уровне будет крайне близка к финальной, потому что, скорее всего, менять организационную структуру под ваши гениальные озарения никто не станет, а архитектура, игнорирующая организационную структуру, изначально нежизнеспособна
Это, скорее, философский вопрос. С моей точки зрения, смысл информационных технологий заключается именно в том, чтобы предложить новую более удобную организационную структуру. Но, это, конечно, с моей очень узкой точки зрения.
Думаю, проблемы с присваиванием не было бы, если не было неявного приведения типов. Или, если бы, оно было бы более контролируемым. Тут вопрос в том, почему, вообще, выражение "a=b" может быть проинтерпретировано как логическое.
Ужасно рад что-то проиллюстрировать. ;-) К сожалению, я не очень понятливый. Я не понял примера. Да, я (теперь!) проверил возможность вызова b() внутри a() . Но я не понял, что сломалось и где? Если написать
for i in range(2):
print(i)
break
else:
print("end")
Так. Правильно и я понимаю, что этот код бодро напечатает
0
и доблестно выйдет из цикла? А, вот, если бы не было инструкции break, то он напечатал бы все числа из диапазона (0 и 1) — каждое — на свой строчке, и напечатал бы также на отдельной строчке "end"?
В нулевые интернет был текстовым. В нём многое было (все пользователи — отчаянные энтузиасты своего дела). И многое можно было найти простым полнотекстовым поиском. Можно было, даже, пролистать десятки бесполезных страниц ссылок и найти именно то. что нужно. Сначала пропал расширенный поиск. Потом появилась поисковая оптимизация. А потом пришёл динамический интернет, когда содержимое страницы строится на ходу. При таком подходе уже мало чего можно было найти, зато ненужно стало появляться промышленных масштабах.
Говорят, что Дмитрий Анатольевич Медведев однажды заявил, что "никто никогда не вернётся в 2007 год". Хотя, скорости нынешнего интернета иногда довольно сильно проседают, и везде образуются разрывы. А ещё РКН всякие реестры ведёт. Говорят, там уже несколько тысяч разного рода материалов.
Как раз, знаменитый "Колхоз" прямо из начала нулевых. Помнится, там были учебники по математике, физике, химии и информатике. Наверное, и по гуманитарным дисциплинам были книги. Сейчас, всё, до чего не дотянулось "авторское" право, дотянулся РКН.
Очень хотелось бы иметь возможность (при выполнении многоэтапной процедуры) пройтись по всем шагам и просто посмотреть, что есть где (параллельно с описанием каждого шага: что на нём делается, куда и в каком виде вводится).
Замечу, что заполнение любой формы также можно превратить в многоэтапный процесс. При этом, у пользователя будет понимание того, что он пока ещё только заполняет форму, и только в конце у него будет кнопочка "Применить/Отослать/Запустить".
Недавно встретился с ситуацией: вводишь в поле текст, нажимаешь кнопку "Отправить", окно пропадает, но ничего не происходит, ничего никуда не отправляется. Дело оказалось в том, что в поле имелся лимит на количество символов, но про этот лимит пользователю ничего сообщалось.
Самое больное место систем — это отсутствие точного и понятного отображения текущего состояния. Хорошее понимание текущего состояния — залог спокойствия пользователя.
А это, вообще, кто-то понимает? ИИ — это серый ящик: что-то видно, но всё, на деле, превращается с кота Шрёдингера (или в Шрёдингера кода?). Когда будет понятно, что ИИ ничего не меняет по сути, а только перераспределяет нагрузки и ретуширует проблемы, уйдёт много лет. Образование должно учить только одному: умению думать. А вот с этим ИИ, похоже, человечество может совсем с ума сойти.
Да, и, конечно. Любая автоматизация предполагает обобщение опыта. А где это обобщение? Просто взяли набор задач и сопоставили ему набор решений, и, использовали, при этом, кучу практических примеров. А где, собственно, обобщение опыта разработки? Для этого надо как-то зафиксировать траекторию разработки реальных систем, а этого никто и никогда не делал и делать не будет! А было бы чрезвычайно интересно посмотреть на готовые системы, историю их разработки. А ещё интереснее было бы понять, как можно было бы разработать туже систему, но за один заход, без растянутого во времени процесса порождения/преодоления ошибок. Ответ на этот вопрос и есть то, в чём заключается подлинная автоматизация, и то, что должен сделать ИИ. Но! Если мы поймём, как это сделать, то зачем нам, тогда, будет нужен ИИ?
Во всех этих рассуждениях как-то пропускается алгоритмическая неразрешимость задачи проверки соответствия программы заданной спецификации. Специалисты по ИИ, наоборот, считают, что статистическими методами, дополнительно вооружёнными механизмами внимания, рассуждения и состязательности, можно удовлетворительно "сойтись" практически к любому решению, и человеческий мозг, в каком-то смысле, сам таким же статистическим образом "сходится" к решению поставленной задачи. А если вспомнить про концепцию "русел" и "джокеров", то вся "болтанка" в результата применения ИИ объясняется тем, то "джокеры" буквально пронизывают всё пространство параметров.
Настоящая автоматизация создания ПО связана с построением моделей, ибо всякий код должен соответствовать некоторой спецификации, а модель — это и есть спецификация. Соответственно, результатом применения ИИ должна быть спецификация — некая формальная спецификация, где для каждого возможного изменения указывается результат. Другими словами, мы должны получить на выходе некое пространство моделей. Разработка ПО — это некая траектория в этом пространстве. А до тех пор, пока ничего этого нет, говорить об автоматизации не приходится.
Можно было бы сказать, "испускает". :-)
(Жалко, надо бы дополнить статью. Но уже поздний час. Попробую завтра. Извините.)
Можно и самому превратиться в пользователя, хотя это очень трудно, отрешиться от знания системы. В этом смысле, автор программы — "испорченный испытуемый", и, действительно, лучше наблюдать за действиями других.
А, вот, то, что касается выбора марки автомобиля (и любого другого выбора, аналогичного данному), то лучше всего иметь на экране буквенную клавиатуру, поле ввода и поле для быстрого выбора (где показывать очень небольшое количество вариантов, зависящее от размеров экрана).
С модификациями труднее. Всегда надо иметь под рукой более развернутое (и разворачивающееся в виде иерархии) описание каждой модели, чтобы пользователь мог бы найти свой вариант.
Хороший пример.
В базах данных традиционно использовалось понятие домена (уж, извините) в смысле диапазона допустимых значений. Это значит, что при описании таблицы мы ложны указывать домен, а не конкретный тип. У каждой сущности может быть довольно богатое семантическое окружение. Домен включает в себя способ управления хранимыми значениями. В Вашем примере, речь идёт о сущности, которая позволяет определённым образом упорядочить пользователей по некоторой шкале. При этом, в различных ситуациях могут использоваться различные подходы/способы. Вот для реализации этих способов и вводится более "толстый" столбец, который уже не сводится какому-то одному типу данных вроде даты.
Ещё один такой пример — это "Фамилия Имя Отчество". В различных ситуациях, требуются различные представления (как полные, так и сокращённые).
У меня такой вопрос: а почему мы обнаруживаем код, явным образом описывающий логику работы приложения? И что это за код? Это код конечного реализуемого приложения? Почему в коде явным образом указывается условие поиска, почему это условие не фигурирует в пользовательском интерфейсе (как один из вариантов)?
А что это такое? По моим узким представлениям, это т.н. сущности, то есть — набор базовых понятий, с которыми мы имеем дело: пользователи, контрагенты, заказы, товары, склады и т.д. и т.п.
А почему это должна быть именно диаграмма классов? Тут ещё и вопрос в том, на каком этапе эта диаграмма используется. Можно себе представить, что эта диаграмма может использоваться на этапе разработки для общения с экспертами в выбранной предметной области, но на этапе реализации эта диаграмма может быть отображена на что-то совсем другое.
Может быть, стоит всегда отделять один слой от другого?
Давайте посмотрим на этот вопрос, собственно, с точки зрения разработки программного обеспечения. У нас есть: (1) сущности предметной области; (2) сущности языка программирования (всякие там структуры); и (3) те сущности, которые мы выстраиваем на базе сущностей (2), чтобы воспроизвести сущности (1).
Предположим, у нес есть таблица покупок Покупки, каждая строка которой описывает отдельный купленный товар (наименование, цена, количество и стоимость). Покупки, сделанные за одно посещение (одного и того же магазина), естественным образом группируются в блоки, и мы можем ввести новую сущность ПосещениеМагазина (дата и время, название магазина). В реляционной базе данных естественным образом возникают две таблицы: основная (содержащая первичные ключи) и подчинённая (ссылающаяся на основную при помощи вторичных ключей). Мы понимаем, что стоимость — это вычисляемый столбец, который можно не хранить в базе данных, но мы можем воспринимать таблицу покупок как документальное выражение результатов действий покупателей. Далее, цены бывают разные. Мы фиксируем в таблице ту цену, по которой нам фактически продали купленный нами товар. Но есть разные цены. Есть базовая цена товара (и, при этом, на определённую дату!), а есть цена со скидкой, разные скидки (сезонные, по акции, накопительные и т.д. и т.п.). Мы можем усложнить таблицу покупок, и вести параллельный учёт различных цен, определяя фактический размер скидки простыми запросами к данной таблице. Если посмотреть в сторону магазинов, то у магазинов есть адреса (ещё одна сущность!), а это значит, что нам нужен справочник адресов. Не очень буйная фантазия представляет этот справочник как иерархический, так что при выборе адреса можно выбирать требуемый уровень (город/улица/дом/корпус/строение). Попутно заметим, что в каждом магазине может быть принята своя система наименования товаров, нам же нужны исходные данные, а это значит, что нам нужен такой же иерархический справочник Номенклатура. И ещё. Посещение магазина — это некое точечное событие. Мы может иметь единую таблицу, где описываются такие события, и тогда мы таким же единым образом будем описывать и Ваше посещение магазина, и приезд к Вам курьера, и помещение на склад продукции, и приход в научно-исследовательский институт государственного задания, по которому этот самый НИИ получает бюджетное финансирование. И это всё суть какие-то события, а это снова отдельная сущность. И если Вы её выделяете, и тратите дополнительные усилия на реализацию этой сущности (элемент семантики), то Вы получаете мощный механизм управления своими данными. Таким образом, важнейший вопрос — это вопрос о том, а какие на самом деле должны быть сущности, чтобы отобразить домены (сущности) предметной области, на сущности (классы/объекты) языка программирования.
Пытаюсь перевести на русский язык. Получается что-то вроде разработки, определяемой предметной областью.
Я предполагаю, что одну и ту же организационную структуру можно отобразить весьма различным способом. И это будет существенным образом зависеть от того, что и как будет называться нами в этой системе.
Это, скорее, философский вопрос. С моей точки зрения, смысл информационных технологий заключается именно в том, чтобы предложить новую более удобную организационную структуру. Но, это, конечно, с моей очень узкой точки зрения.
То есть, разработка идёт от оборудования, а не от общей архитектуры, так?
Думаю, проблемы с присваиванием не было бы, если не было неявного приведения типов. Или, если бы, оно было бы более контролируемым. Тут вопрос в том, почему, вообще, выражение "a=b" может быть проинтерпретировано как логическое.
Ужасно рад что-то проиллюстрировать. ;-) К сожалению, я не очень понятливый. Я не понял примера. Да, я (теперь!) проверил возможность вызова b() внутри a() . Но я не понял, что сломалось и где? Если написать
то получится
Если написать
то получится
Всё ожидаемо. А что же сломалось?
Так. Правильно и я понимаю, что этот код бодро напечатает
0
и доблестно выйдет из цикла? А, вот, если бы не было инструкции break, то он напечатал бы все числа из диапазона (0 и 1) — каждое — на свой строчке, и напечатал бы также на отдельной строчке "end"?
А какое сегодня число? Не может же быть сегодня первое апреля. Неужели дело серьёзное?
Это как? И что будет-то? Это надо
b()определить доa(). Надо как-то яснее приводить пример.В нулевые интернет был текстовым. В нём многое было (все пользователи — отчаянные энтузиасты своего дела). И многое можно было найти простым полнотекстовым поиском. Можно было, даже, пролистать десятки бесполезных страниц ссылок и найти именно то. что нужно. Сначала пропал расширенный поиск. Потом появилась поисковая оптимизация. А потом пришёл динамический интернет, когда содержимое страницы строится на ходу. При таком подходе уже мало чего можно было найти, зато ненужно стало появляться промышленных масштабах.
Говорят, что Дмитрий Анатольевич Медведев однажды заявил, что "никто никогда не вернётся в 2007 год". Хотя, скорости нынешнего интернета иногда довольно сильно проседают, и везде образуются разрывы. А ещё РКН всякие реестры ведёт. Говорят, там уже несколько тысяч разного рода материалов.
Как раз, знаменитый "Колхоз" прямо из начала нулевых. Помнится, там были учебники по математике, физике, химии и информатике. Наверное, и по гуманитарным дисциплинам были книги. Сейчас, всё, до чего не дотянулось "авторское" право, дотянулся РКН.
А как быть, если после установки VS Code среда не может подключиться к своему же маркетплейсу:
?
Здесь, для властей, ключевое слово: "законным". Вот они и устанавливают границу "законности".