Исправление Kroz, (текущая версия) :
но awesome продолжит выполнять свою основную функцию. Плохо, неюзабельно, но будет. ☺
Притча, рассказанная одним преподом в универе:
Поручили инженерам сделать водопроводный кран. Одни заказчики поручили сделать кран который дает много воды. А вторые заказчики поручили сделать кран, который приносит много денег. Инженеры почесали в затылке, и сделали кран, который дает воды, не то чтобы много, но и не мало, ну и денег приносит средненько. И отдали это заказчикам. Итог: набили морду и те и другие.
Мораль: Если делаешь что-то, делай это хорошо. Или не делай вообще.
Для простых вещей он простой. Сложное приходится делать лютыми хаками. Никакого противоречия здесь нет.
Это противоречит лучшим практикам.
Есть два подхода к программным решениям:
1. Разделяешь на простое/сложное, простое делаешь максимально простым (опции в конфиге), сложное - даешь мощный хоть и сложный инструмент. Цель: минимальный порог входа для новичков.
2. Даешь один инструмент конфигурации (язык) который умеет всё, и не требует «лютых хаков». Да, простое будет сложнее, но зато то, что обычно сложно, будет проще. Цель: максимальная конфигурабельность доступная пользователям.
Соответственно, с самого начала ты должен определить что тебе важнее: простота или конфигурабельность, а далее следовать этому принципу.
Примеры первого подхода:
- в Винде простые вещи делаются чекбоксами в Control Panel. Сложные - магией в реестре.
- в KDE простые вещи делаются чекбоксами в System Setting или в соотв. конфигах, сложные - виджетами на Python или WinScript на JavaScript.
- в FireFox/Chrome простые вещи делаются чекбоксами в настройках или в соотв. конфигах, сложные - плагинами на JavaScript.
Пример второго подхода:
- в Линукс практически всё настраивается конфигами в текстовых файлах. Это сложнее чем GUI чекбоксы в Windows/Mac, но зато сделать можно намного больше.
- В nftables всё конфигурится нетривиальными конфигами, но зато сделать можно много чего.
Исходная версия Kroz, :
но awesome продолжит выполнять свою основную функцию. Плохо, неюзабельно, но будет. ☺
Притча, рассказанная одним преподом в универе:
Поручили инженерам сделать водопроводный кран. Одни заказчики поручили сделать кран который дает много воды. А вторые заказчики поручили сделать кран, который приносит много денег. Инженеры почесали в затылке, и сделали кран, который дает воды, не то чтобы много, но и не мало, ну и денег приносит средненько. И отдали это заказчикам. Итог: набили морду и те и другие.
Мораль: Если делаешь что-то, делай это хорошо. Или не делай вообще.
Для простых вещей он простой. Сложное приходится делать лютыми хаками. Никакого противоречия здесь нет.
Это противоречит лучшим практикам.
Есть два подхода к программным решениям:
1. Разделяешь на простое/сложное, простое делаешь максимально простым (опции в конфиге), сложное - даешь мощный хоть и сложный инструмент. Цель: минимальный порог входа для новичков.
2. Даешь один инструмент конфигурации (язык) который умеет всё, и не требует «лютых хаков». Да, простое будет сложнее, но зато то, что обычно сложно, будет проще. Цель: максимальная конфигурабельность доступная пользователям.
Соответственно, с самого начала ты должен определить что тебе важнее: простота или конфигурабельность, а далее следовать этому принципу.
Примеры первого подхода:
- в Винде простые вещи делаются чекбоксами в Control Panel. Сложные - магией в реестре.
- в KDE простые вещи делаются чекбоксами в System Setting или в соотв. конфигах, сложные - виджетами на Python или WinScript на JavaScript.
- в FireFox/Chrome простые вещи делаются чекбоксами в настройках или в соотв. конфигах, сложные - плагинами на JavaScript.
Пример второго подхода:
- в Линукс практически всё настраивается конфигами в текстовых файлах. Это сложнее чем GUI чекбоксы в Windows/Mac, но зато сделать можно намного больше.
- В nftables всё конфигурится нетривиальными конифгами, но зато сделать можно много чего.