Category: компьютеры

фото

"Алгоритм изобретения", Генрих Альтшуллер

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

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

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

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

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

Вторая мысль - о постановке задачи. Утверждается, что правильная постановка задачи это огромная часть работы по её решению и обычно надо решать более широкую задачу, чем ту, с которой пришли. Если лошади скоро завалят навозом Нью-Йорк, то нужно изобретать не способы вывоза навоза, а автомобиль.

Вторая часть книги - описание самого алгоритма. Очень четкое, очень понятное, очень логичное, очень интересное в чтении. К сожалению, алгоритм хотя и составлен в самых общих терминах, всё же ориентирован на материальный мир и, мне кажется, не применим к нашим виртуальным задачам. Значительную часть его, например, составляет таблица вида: "при противоречии между ценой и размером устройства стоит попробовать использовать заморозку, испарение, добавление примесей и разделение устройства на несколько". Вариантов противоречий штук 200, приемов около 40 - работа по систематизации просто титаническая проделана, и если таблица работает, то должна быть жутко полезной в своей области. Кто бы её для нас переписал...

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

В общем, книга хорошая, почти полезная, читать нужно. Если есть или появится адаптация под онлайн - то её просто обязательно.
pochta.ru

Веб-технологии для чайников - 7. Железо.

Заранее спасибо за поправки!

Все наши серверные программы и базы данных должны крутиться на каком-то физическом железе. Принципиально есть две возможности: арендовать какие-то виртуальные ресурсы у хостинг-провайдеров (сколько-то гигабайт дискового пространства, такая-то доля процессорной мощности, столько-то доступной оперативной памяти) или покупать/арендовать собственные сервера. Первый путь очевидно оптимален в случае небольших проектов, второй — в нагруженных. Границу можно крайне условно определить где-то в 100000 обращений в сутки, но условность этой цифры, пожалуй, максимальна из всех возможных.

В случае виртуальных ресурсов все проблемы решает за нас хостер, если же принято решение о собственном/арендованном железе, то лучше представлять себе что это такое. 4 основные компонента сервера это корпус, процессоры, память и жесткие диски. Главная характеристика корпуса — высота при абсолютно стандартизованной ширине (19 дюймов). Высота измеряется целым числом «юнитов», 1 юнит равен 7/4 дюйма, примерно 4.5 см (или как часто шутят, абсолютно точно соответствует старому русскому вершку). Сервера бывают «одноюнитовые», «двухюнитовые» и, реже, большеюнитовые. Чем больше в корпусе юнитов, тем больше в него помещается, но соответственно тем больше он занимает места в стойке провайдера и так или иначе, тем дороже он будет обходиться. Качество процессора определяется тактовой частотой и количеством ядер (чем больше — тем лучше), а так же потребляемым электричеством (чем меньше — тем дешевле). Общепринято, что в большинстве случаев оптимальный выбор это двухпроцессорные модели (а уж каждый процессор может быть многоядерным). Памяти должно быть, чем больше, тем лучше, она достаточно дешева и экономить на ней смысла нет.

Сложнее всего с дисками. Размер жесткого диска последние годы практически никогда не имеет значения, даже самые маленькие из них заполнить довольно сложно (из этого, кстати, справедливо вытекает, что одноюнитовые сервера - правильное решение в подавляющем большинстве случаев), но при этом диски всегда тормозят, и их скорость часто важнее скорости процессора. Сейчас популярны диски двух типов: SAS (быстрее и дороже) и SATA (медленнее и дешевле), апгрейдить один на другой в рамках одного корпуса/материнской платы обычно невозможно. Стандартный способ ускорения дисковой системы — увеличение числа используемых винчестеров, с тем, чтобы на каждом диске лежала какая-то своя часть активно используемых данных.

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