Архитектура ОС Singularity (отзыв на статью)

Прочитал отчет Microsoft Research «Проект Singularity: обзор». Появился ряд мыслей, которыми хочется поделиться.

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

Пример проектирования: шифрующая папка на "рабочем столе"

Приведу пример на «цепочку действий» из моей практики. Думаю, он будет интересен.

Ситуация: Для одного из заказчиков была написана программа – аналог PGP. Она позволяла шифровать и дешифровать файлы, создавать и удалять ключи. Отсутствовала только одна необходимая «фича»: Заказчик хотел иметь на «рабочем столе» папку, в которую он бы мог при помощи мыши перемещать файлы и другие папки. Перемещенные элементы должны были автоматически шифроваться.

Для реализации шифрующей папки к проекту подключили меня.

Идеальный программист

Вот уже длительное время я наблюдаю за теми программистами, которые добиваются успеха в аутсорсинге. Оказывается, наиболее успешны не те разработчики, которые умеют качественно спроектировать приложение. Наибольшего успеха в аутсорсинге добиваются программисты, которые умеют быстро разрабатывать прототипы.

Разработка технологической платформы для игр в условиях временного прессинга

Что такое "технологическая платформа"? Многие, знакомые с областью разработки игр, скажут, что это - графический движок. Предполагается, что если есть инструмент для работы с 3D-объектами, текстурами, камерами, 2D-графикой, то написание игры - дело несложное.

По мнению автора данного блога, это не так. Технологическая платформа должна предоставлять технологию создания игры. Она может включать в себя разные инструменты, но главное - это наличие технологии, заточенной под определённый класс игр.

При разработке одной игры для девочек для консоли Nintendo Wii автор вместе с коллегами разработал довольно простую технологическую платформу. Используя её, обученный программист мог создавать черновой вариант мини-игры за 3 дня. Потом ещё 2 дня уходили на доделку HUD'а и вставку звука. Итого, создание мини-игры занимало 5 человеко-дней.

Полученным в результате данного проекта опытом я поделился на КРИ 2010. Послушать выступление и посмотреть презентацию можно здесь.

Отзыв на книгу "Шаблоны интеграции корпоративных приложений"

Прочитал книгу:

Хоп, Грегор, Вульф, Бобби. Шаблоны интеграции корпоративных приложений. : Пер. с англ. – М.: ООО «И.Д. Вильямс», 2007. – 672 с.: ил.

Книга вышла в серии “A Martin Fowler Signature Book” и посвящена шаблонам интеграции корпоративных приложений.

В настоящее время для интеграции корпоративных приложений используются 4 техники:

1)      Передача файла (File Transfer).

2)      Общая база данных (Shared Database).

3)      Удаленный вызов процедуры (Remote Procedure Invocation).

4)      Обмен сообщениями (Messaging).

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

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

Почему надо проектировать "от обязанностей", или сколько функций выполняет чашка?

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

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

Один из коллег в личной переписке на это возразил:

1. Если задумываться о назначении чашки, то будет сложно налить в чайную чашку кофе, а в кофеную – чай.
2. Гораздо проще снабдить обычную чашку двумя интерфейсами – "налить кофе" и "налить чай".

В качестве возражения на это замечание коллеги мне бы хотелось сказать вот что...

О том, как путают функциональный подход к проектированию с процедурным программированием

Обсуждая с коллегами подходы к проектированию программ, нередко натыкаешься на скепсис по отношению к функциональному подходу. Не смотря на то, что возможности подхода продемонстрированы на конкретных примерах:

Пример 1. Проектирование графического редактора

Пример 2. Проектирование программы для метеостанции

ряд коллег считает, что функциональный подход обладает недостатками, которые значительно сужают его область применения. При этом, как это часто бывает, недостатки объектно-ориентированного подхода не замечаются или попросту игнорируются.

Какие же недостатки приписывают функциональному подходу?