|
Размер: 4944
Комментарий:
|
Размер: 6340
Комментарий:
|
| Удаления помечены так. | Добавления помечены так. |
| Строка 2: | Строка 2: |
| ==== ... а также обо всём, чего четыре, о том, что такое fun, о гибких конструкторах, оболочках, Пути Unix и полушариях ==== | ==== ... а также обо всём, чего четыре, о том, что такое fun, о гибких конструкторах, оболочках, Пути Unix, полушариях и ==== ''Примечание: эта лекция читалась ровно '''две''' пары. Отчего так вышло -- ума не приложу...'' |
| Строка 24: | Строка 25: |
| Требования к интерфейсу управления системой (т. е. к <!> "гибкому конструктору решений") 0.#0 Интерфейс -- это средства, позволяющие ''человеку'' управлять ''системой'' 1. Запуск "задач" 2. Взаимодействие задач * По данным * По управлению 3. Формализация решений 4. (требование '''многопользовательской''' системы) масштабируемость интерфейса Unix-решение: 0.#0 Дисциплина взаимодействия человека и подзадач в системе: * Любой синхронный источник и/или приёмник данных == файл * Пространство имён == файловая система * Все данные, предназначенные для человека, -- текстовые 1. Подзадача == процессы 2. Решение задачи == организация взаимодействия процессов * перенаправление В/В * POSIX IPC 3. Высокоуровневый ЯП (shell) и сцнари к нему 4. Минимизация аппаратных требований (текстовый в/в, терминал) Следствие: '''интерфейс командндой строки''': * Средство эффективного ручного управления * Средство эффективной интеграции подзадач-процессов * Высокоуровневый ЯП |
Требования к интерфейсу управления системой (т. е. к <!> "гибкому конструктору решений"): '''Интерфейс''' -- это средства, позволяющие ''человеку'' управлять ''системой'' || '''Абстрактный "конструктор"''' || '''Интерфейк командной строки''' || ||Набор "деталей" || Запуск '''процессов''' || ||<(|2>"Крепёж" || Взаимодействие процессов по данным, '''IO''' || || Взаимодействие процессов по управлению, '''IPC''' || ||"Терминология" || Пространство имён -- '''filesystem''' ("всё -- файл") || ||<(|4>"Язык описания" ||<:>'''Shell''': || || Диалог с пользователем, '''интерпретатор''' командной строки || || Управление процессами и файлами, '''оболочка''' || || Формализация созданных решений задач, '''ЯП''' || ||"Наглядность" || Информационное пространство -- '''manpages''' (документированность) || ||"Умопостижимость" || "Человекоприемлемость", '''config files''' ("всё -- текст") || Требование '''многопользовательской''' системы: масштабируемость интерфейса * Минимизация аппаратных требований (текстовый в/в, терминал) |
| Строка 50: | Строка 46: |
== Что не умеет Shell и когда это нужно? == * Сетевое взаимодействие (какой-то новый тип конструктора?) * ''Само''документированность (use the rource, Luke) * ''Ввод'', а не ''выбор'' (create, not search) === Преимущество выбора перед вводом === 1. Многократные действия (экономия времени и снижение вероятности ошибки) 2. Непрофессиональные действия (интерфейс отражает ''легенду'', а не действительные элементы управления) 3. Сложные действия, умолчания, прочий искусственный интеллект (легко реализовать сценарием на shell, но от пользователя потребуется именно ввод) 4. Ситуации, когда ''визуальный'' поиск эффективнее текстового (поиск среди большого числа объектов в результате ошибочного дизайна или требований пользовательской области) |
О пользователях дистрибутива
... а также обо всём, чего четыре, о том, что такое fun, о гибких конструкторах, оболочках, Пути Unix, полушариях и
Примечание: эта лекция читалась ровно две пары. Отчего так вышло -- ума не приложу...
Четыре категории пользователей
Пользователи ''дистрибутива'' (а не отдельного ПО)
- Системные администраторы (ADM)
- Разработчики ПО (DEV)
- Постановщики задач и наладчики бизнес-процессов (условно "системные интеграторы") (INT)
- Любознательные пользователи и повышающие квалификацию (a.k.a. Just For Fun) (JFF)
Четыре категории пользовательских задач
- Собственные/Чужие (кто пользуется решениями задач)
- Компьютерные/Некомпьютерные (лежит ли результат труда пользователя в компьютерной сфере)
|
Собственные |
Чужие |
Некомпьютерные |
ADM |
INT |
Компьютерные |
JFF |
DEV |
Четыре категории требований к инструментариям
- Собственные задачи -- гибкость
- Чужие задачи -- готовые решения типовых задач
- Компьютерные задачи -- программирование
- Некомпьютерные задачи -- констрцктор в некомпьютерной объектной области
|
Программирование |
Конструктор |
Готовые решения |
RAD; дисциплины и среды программироания: Java, RR, Zope; IDE; ACE |
Пакеты Прикладных Программ |
Гибкость |
Си :), языки прогр. общего назначения; системные и интерфейсные библиотеки |
|
Гибкий конструктор: The UNIX way
Требования к интерфейсу управления системой (т. е. к 
"гибкому конструктору решений"):
Интерфейс -- это средства, позволяющие человеку управлять системой
Абстрактный "конструктор" |
Интерфейк командной строки |
Набор "деталей" |
Запуск процессов |
"Крепёж" |
Взаимодействие процессов по данным, IO |
Взаимодействие процессов по управлению, IPC |
|
"Терминология" |
Пространство имён -- filesystem ("всё -- файл") |
"Язык описания" |
Shell: |
Диалог с пользователем, интерпретатор командной строки |
|
Управление процессами и файлами, оболочка |
|
Формализация созданных решений задач, ЯП |
|
"Наглядность" |
Информационное пространство -- manpages (документированность) |
"Умопостижимость" |
"Человекоприемлемость", config files ("всё -- текст") |
Требование многопользовательской системы: масштабируемость интерфейса
- Минимизация аппаратных требований (текстовый в/в, терминал)
Недостаток: эксплуатируется "научный" (дедуктивный, "от законов к решению задачи") стиль мышления, только отчасти -- "инженерный" (фактологический, "в сундуке есть все решения задач"), и совсем никак -- "сюжетный" (точное воспроизведение действий по принципу совпадения "персонажей, предметов и обстоятельств").
Костыль: т. н. "интуитивно понятный интерфейс" эффективно рассчитан на сюжетный стиль мышления, но не может претендовать на роль "гибкого конструктора"
Что не умеет Shell и когда это нужно?
- Сетевое взаимодействие (какой-то новый тип конструктора?)
Самодокументированность (use the rource, Luke)
Ввод, а не выбор (create, not search)
Преимущество выбора перед вводом
- Многократные действия (экономия времени и снижение вероятности ошибки)
Непрофессиональные действия (интерфейс отражает легенду, а не действительные элементы управления)
- Сложные действия, умолчания, прочий искусственный интеллект (легко реализовать сценарием на shell, но от пользователя потребуется именно ввод)
Ситуации, когда визуальный поиск эффективнее текстового (поиск среди большого числа объектов в результате ошибочного дизайна или требований пользовательской области)