Искусство программирования для Unix

Искусство программирования для Unix

Вдохновившим меня Кену Томпсону и Деннису Ритчи

Предисловие

Для кого предназначена эта книга

Как использовать эту книгу

Дополнительные источники информации

Соглашения, используемые в данной книге

Учебные примеры

Авторские благодарности

Часть I Контекст

1 Философские вопросы

1.1. Культура? Какая культура?

1.2. Долговечность Unix

1.3. Доводы против изучения культуры Unix

1.4. Что в Unix делается неверно

1.5. Что в Unix делается верно

1.5.1. Программное обеспечение с открытым исходным кодом

1.5.2. Кроссплатформенная переносимость и открытые стандарты

1.5.3. Internet и World Wide Web

1.5.4. Сообщество открытого исходного кода

1.5.5. Гибкость на всех уровнях

1.5.6. Особый интерес исследования Unix

1.5.7. Уроки Unix применимы в других операционных системах

1.6. Основы философии Unix

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

1.6.2. Правило ясности: ясность лучше, чем мастерство

1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей

1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо

1.6.6. Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается

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

1.6.8. Правило устойчивости: устойчивость-следствие прозрачности и простоты

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

1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы

1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить"

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

1.6.13. Правило экономии: время программиста стоит дорого; поэтому экономия его времени более приоритетна по сравнению с экономией машинного времени

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

1.6.15. Правило оптимизации: создайте опытные образцы, заставьте их работать, прежде чем перейти к оптимизации

1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"

1.6.17. Правило расширяемости: проектируйте с учетом изменений в будущем, поскольку будущее придет скорее, чем кажется

1.7. Философия Unix в одном уроке

1.8. Применение философии Unix

1.9. Подход также имеет значение

2 История: слияние двух культур

2.1. Истоки и история Unix, 1969—1995 гг.

2.1.1. Начало: 1969-1971 гг.

2.1.2. Исход: 1971-1980 гг.

2.1.3. TCP/IP и Unix-войны: 1980-1990 гг.

2.1.4. Бои против империи: 1991—1995 гг.

2.2. Истоки и история хакерской культуры, 1961-1995 гг.

2.2.1. Академические игры: 1961 — 1980 гг.

2.2.2. Internet и движение свободного программного обеспечения: 1981—1991 гг.

2.2.3. Linux и реакция прагматиков: 1991—1998 гг.

2.3. Движение открытого исходного кода: с 1998 года до настоящего времени

2.4. Уроки истории Unix

3 Контраст: сравнение философии Unix и других операционных систем

3.1. Составляющие стиля операционной системы

3.1.1. Унифицирующая идея операционной системы

3.1.2. Поддержка многозадачности

3.1.3. Взаимодействующие процессы

3.1.4. Внутренние границы

3.1.5. Атрибуты файлов и структуры записи

3.1.6. Двоичные форматы файлов

3.1.7. Предпочтительный стиль пользовательского интерфейса

3.1.8. Предполагаемый потребитель

3.1.9. Входные барьеры для разработчика

3.2. Сравнение операционных систем

3.2.1. VMS

3.2.2. MacOS

3.2.3. OS/2

3.2.4. Windows NT

3.2.5. BeOS

3.2.6. MVS

3.2.7. VM/CMS

3.2.8. Linux

3.3. Все повторяется

Часть II Проектирование

4 Модульность: четкость и простота

4.1. Инкапсуляция и оптимальный размер модуля

4.2. Компактность и ортогональность

4.2.1. Компактность

4.2.2. Ортогональность

4.2.3. Правило SPOT

4.2.4. Компактность и единый жесткий центр

4.2.5. Значение освобождения

4.3. Иерархичность программного обеспечения

4.3.1. Сравнение нисходящего и восходящего программирования

4.3.2. Связующие уровни

4.3.3. Учебный пример: язык С считается тонким связующим уровнем

4.4. Библиотеки

4.4.1. Учебный пример: подключаемые подпрограммы GIMP

4.5. Unix и объектно-ориентированные языки

4.6. Создание модульного кода

5 Текстовое представление данных: ясные протоколы лежат в основе хорошей практики

5.1. Важность текстовой формы представления

5.1.1. Учебный пример: формат файлов паролей в Unix

5.1.2. Учебный пример: формат файлов .newsrc

5.1.3. Учебный пример: PNG — формат графических файлов

5.2. Метаформаты файлов данных

5.2.1. DSV-стиль

5.2.2. Формат RFC 822

5.2.3. Формат Cookie-Jar

5.2.4. Формат record-jar

5.2.5. XML

5.2.6. Формат Windows INI

5.2.7. Unix-соглашения по текстовым файловым форматам

5.2.8. Аргументы "за" и "против" сжатия файлов

5.3. Проектирование протоколов прикладного уровня

5.3.1. Учебный пример: SMTP, простой протокол передачи почты

5.3.2. Учебный пример: РОРЗ, почтовый протокол 3-й версии

5.3.3. Учебный пример: IMAP, протокол доступа к почтовым сообщениям

5.4. Метаформаты протоколов прикладного уровня

5.4.1. Классический метапротокол прикладного уровня в Internet

5.4.2. HTTP как универсальный протокол прикладного уровня

5.4.2.1. Учебный пример: база данных CDDB/freedb.org

5.4.2.2. Учебный пример: протокол IPP

5.4.3. ВЕЕР: Blocks Extensible Exchange Protocol

5.4.4. XML-RPC, SOAP и Jabber

6 Прозрачность: да будет свет

6.1. Учебные примеры

6.1.1. Учебный пример: audacity

6.1.2. Учебный пример: параметр -v программы fetchmail

6.1.3. Учебный пример: GCC

6.1.4 Учебный пример: kmwail

6.1.5. Учебный пример: SNG

6.1.6. Учебный пример: база данных Terminfo

6.1.7. Учебный пример: файлы данных Freeciv

6.2. Проектирование, обеспечивающее прозрачность и воспринимаемость

6.2.1. Дзэн прозрачности

6.2.2. Программирование, обеспечивающее прозрачность и воспринимаемость

6.2.3. Прозрачность и предотвращение избыточной защищенности

6.2.4. Прозрачность и редактируемые формы представления

6.2.5. Прозрачность, диагностика и восстановление после сбоев

6.3. Проектирование, обеспечивающее удобство сопровождения

7 Мультипрограммирование: разделение процессов для разделения функций

7.1. Отделение контроля сложности от настройки производительности

7.2. Классификация IPC-методов в Unix

7.2.1. Передача задач специализированным программам

7.2.1.1. Учебный пример: пользовательский почтовый агент mutt

7.2.2. Каналы, перенаправление и фильтры

7.2.2.1. Учебный пример: создание канала к пейджеру

7.2.2.2. Учебный пример: создание списков слов

7.2.2.3. Учебный пример: pic2graph

7.2.2.4. Учебный пример: утилиты bc(1) и dc(1)

7.2.2.5. Контрпример: почему программа fetchmail не выполнена в виде конвейера

7.2.3. Упаковщики

7.3.2.1. Учебный пример: сценарии резервного копирования