Вопросы Хейлмейера, Пирса и ответы наших разработчиков

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

C использованием комбинации опросников Пирса и Хейлмейера проведено анкетирование разработчиков KolibriOS по активно развивающимся направлениям: поддержке файловых систем, файловому менеджеру Eolite, драйверам для видеокарт, языку программирования Forth, интегрированной среде разработки для ЯВУ, портированию браузера Netsurf. Подробности под катом.

Популярный наборов вопросов для разработчиков называется «девять вопросов» Хейлмейера. Джордж Хейлмейер возглавлял Агентство по перспективным оборонным научно-исследовательским разработкам США (DAPRA) в 1975-1977 годах и был в руководстве многих компаний. Сам список был обнародован только в начале 1990-х годов в двух публикациях. Первая версия содержала 8 вопросов (не было вопроса про потребителя), во второй статье Хейлмейер утверждал, что придумал его более 17 лет назад (эта версия содержала 9 вопросов), поэтому его история неясна.

Например, после его ухода из DAPRA в конце 1970-х годов там использовались похожие вопросы (соответствующие 5 вопросам в опроснике Хейлмейера) без ссылки на Хейлмейера. Набор вопросов имеет разные вариации, уточняющие и расширяющие его. Например, на сайте DAPRA другая формулировка вопроса о потребителе, чем в публикации 1993 года. На современном этапе DAPRA модифицировала его в список DARPA Investment Criteria, в котором есть вопрос «Какова стратегия выхода DAPRA из этого проекта в случае неудачи?». В целом опросник в значительной мере ориентирован на перспективы научного исследования как будущего бизнеса, поэтому посвящен инвестированию денег и получению прибыли.

Недавно я нашел список вопросов от другого известного учёного Джона Пирса, занимавшего руководящие должности в технических компаниях. Этот набор вопросов я назвал опросник Пирса и он ориентирован на ученых, которые занимаются исследованиями без оглядки на финансовую составляющую. Любопытно сравнить их, а затем с помощью комбинированного опросника провести анкетирование наших разработчиков по разным направлениям.

Сопоставление вопросов, ответы на которые должны быть готовы дать разработчики, представлено в таблице.

Вопросы Хейлмейра (~1975)	Вопросы Пирса (1969)
Что вы пытаетесь сделать? Сформулируйте свои цели без использования жаргона. What are you trying to do? Articulate your objectives using absolutely no jargon.	Какую конкретную вещь я надеюсь сделать? What particular thing do I hope to accomplish?
	Почему (именно) я работаю в этой области (над этой задачей)? Why am I working in this field?
Как это сделано сейчас и в чем ограничения текущего подхода? How is it done today, and what are the limits of current practice?
Что нового в твоем подходе и почему ты думаешь, что он будет успешен? What's new in your approach and why do you think it will be successful?	Насколько я уверен в успехе? Am I likely to succeed?
Кто потребитель? Who cares?
Если ты успешен, то какие будут изменения (в твоей научной области, на рынке)? If you're successful, what difference will it make?	Почему это важно? Why is it worthwhile?
Каковы риски и прибыль? What are the risks and the payoffs?	Где успех может случиться или не случиться? (проблемные места в проекте) Where will success take or leave me?
Насколько это дорого? How much will it cost?
Сколько времени это займет? How long will it take?
Каковы промежуточные и финальные экзамены для проверки успеха? What are the midterm and final «exams» to check for success?	Как узнать, что я успешен или не успешен? How will I know whether or not I have succeeded?

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

Результаты опросов представлены по порядку, в котором были получены ответы.

Первым отозвался pathoswithin.

№	Опросник 1	Pathoswithin (дисковая подсистема)
1	Что ты пытаешься сделать?	Добавить ввод пути к файлу в юникоде, исправить баги.
2	Почему это важно?	см. ответ на вопрос 5
3	Почему именно ты работаешь над этой задачей?	Потому что я один работаю над дисковой системой.
4	Как это было сделано до тебя?	Ввод только в кодировке cp866, много багов в драйвере ext fs.
5	В чем были ограничения предыдущего подхода?	Были полностью недоступны файлы с любым нестандартным символом в имени, вроде № или тире.
6	Что нового в твоем подходе?	см. ответ на вопрос 10
7	Почему ты думаешь, что твой подход будет успешен?	Потому, что других подходов нет.
8	Какие части проекта могут стать проблемами?	Запуск программ и подключение библиотек.
9	Сколько времени займет проект?	Стандартный срок для некоммерческого проекта, где-то от одного дня до бесконечности.
10	Каковы этапы проекта?	Адаптировать драйвера файловых систем для получения пути в кодировке UTF-8, а всё остальное — для его генерации.
11	Какие тесты проводишь?	Запуск системы. Достаточно одной ошибки…

Вторым ответил Punk_Joker.

№	Опросник 2	punk_joker (файловый менеджер)
1	Что ты пытаешься сделать?	Превратить Eolite в действительно удобный и функциональный файловый менеджер.
2	Почему это важно?	Потому что повседневное использование ПК практически не мыслимо без работы с файлами, а файловый менеджер — это тот инструмент, который позволяет делать это удобно.
3	Почему именно ты работаешь над этой задачей?	Потому что в проекте не так много программистов, и большинство заняты ядром и драйверами ОС.
4	Как это было сделано до тебя?	см. ответ на вопрос 5
5	В чем были ограничения предыдущего подхода?	Сейчас есть два графических ФМ. Это KFM, но он двухпанельный, что не всем нравиться или удобно, и он уже морально устаревает. И fNav — вполне неплохой ФМ, но имеет закрытые исходники, и потому развивается крайне медленно. Ну, конечно, есть консольный FAR — пожалуй, самый функциональный ФМ на данный момент, но он опять-таки двухпанельный, и плюс ко всему не графический, что для многих является недостатком.
6	Что нового в твоем подходе?	Происходит наращивание функционала с переписыванием тех участков программы, которые не дают добавить те или иные возможности или мешают сделать это максимально эффективно. Я просто продолжаю работу над Eolite так, как это делал Leency.
7	Почему ты думаешь, что твой подход будет успешен?	—
8	Какие части проекта могут стать проблемами?	Пожалуй, это внедрение поддержки масштабируемых шрифтов, поскольку Eolite, как и другие программы в Колибри, заточены под старый системный шрифт фиксированного размера.
9	Сколько времени займет проект?	Неизвестно.
10	Каковы этапы проекта?	Сейчас это внедрение поддержки Unicode и масштабируемых шрифтов.
11	Какие тесты проводишь?	Функции файлового менеджера различны и для них нужны разные тесты. Например, при реализации рекурсивного копирования проверялось число файлов и каталогов в дереве, и длина пути, при котором Eolite может упасть или некорректно выполнить операцию.

Третим ответил Serge, у которого на Хабрахабре ник ion2.

№	Опросник 3	Serge (мультимедиа, драйверы видеокарт)
1	Что ты пытаешься сделать?	Сейчас я занимаюсь несколькими проектами, но все они так или иначе связаны с видеоплеером Fplay и Mesa3D.
2	Почему это важно?	1.Очень сложно представить современную десктопную систему без поддержки мультимедиа. 2.Это очень мощный локомотив для развития ядра в целом. Решение такой, на первый взгляд, тривиальной задачи, как воспроизведение звука, привело к радикальным изменениям в ядре. Я надеюсь, в лучшую сторону.
3	Почему именно ты работаешь над этой задачей?	Мне всегда было интересно работать непосредственно с железом. GPU в этом плане наиболее интересны. Все эксперименты очень наглядны.
4	Как это было сделано до тебя?	Этот вопрос скорее к разработчику очередного файлового менеджера.
5	В чем были ограничения предыдущего подхода?	см. ответ на вопрос 4
6	Что нового в твоем подходе?	см. ответ на вопрос 4
7	Почему ты думаешь, что твой подход будет успешен?	см. ответ на вопрос 4
8	Какие части проекта могут стать проблемами?	Сложностей очень много. Если со стеком драйверов для Интел всё обстоит хорошо (портированы драйвер ядра, 3D драйвер Mesa и декодер видео для libVA), то для АМД работает только драйвер дисплея — смена видеорежимов и аппаратные курсоры. 3D драйверы r600 и RadeonSI зависят от LLVM. Это 18+ Мб двоичного кода. LLVM, конечно, очень интересная вещь, но я не верю, что в АМД не могли сделать шейдерный компилятор без неё. В Интел, кстати, пытались применить LLVM, но потерпели неудачу. Я этому рад. Меня немного напрягает использование таких монстроподобных библиотек в 3D стеке. Хотя у Интел тоже не всё замечательно. Основной код 3D драйвера написан на С. Шейдерный компилятор на С++. Всё это слинковано в один бинарник. С код вызывает С++ код. Что будет, если тот выбросит исключение? Я не знаю.
9	Сколько времени займет проект?	Это бесконечный процесс. Инженеры делают новое железо, программисты новый код. Если инженеры не успевают, программисты переписывают старый. Все при деле. Если сравнить драйверы из Линукс 3.4 и 4.4 — это две очень большие разницы. Регулярно переделывают API. Когда я слышу разговоры «сейчас мы сядем, всё спроектируем, а потом напишем замечательный код», я вспоминаю разработчиков DRM. Я использую исходный код официальных оpen source драйверов для Линукс. Его пишут штатные сотрудники компаний и иногда привлечённые со стороны из старой гвардии разработчиков с x.org. А если сравнить исходные коды драйверов от Интел и АМД, то драйвер АМД написан лучше. Намного лучше. Это такое олдскульное ООП со структурами и указателями на функции и макросами для лучшей читабельности. Код для каждого поколения собран в отдельном файле, набор функций одинаков, отличаются только имена. Если изучить radeon_asic.c, станет ясно, как эволюционировала архитектура от R100 до Kaveri. Такой код намного проще и портировать и сопровождать. В противовес файлах у Интел настоящий винегрет из кода разных поколений. 470 килобайт и 16500 строк в intel_display.c имхо уже далеко за пределами разумного.
10	Каковы этапы проекта?	Начиналось всё в 2006 году. Это был ассемблерный драйвер для ATI R300-R500 на основе неофициального драйвера из Линукс. Так в Колибри появились аппаратные курсоры. В 2008 АМД повернулась лицом к open source и появился официальный драйвер radeonhd. Это был userspace драйвер, но в Колибри он работал в ядре, поддерживая железо, начиная с R500+. Поддержку старых чипов в АМД посчитали неактуальной. Создатели старого драйвера с ними не согласились и, используя ATOMBIOS, сделали поддержку новых видеокарт. В результате у АМД было два open source драйвера. Наконец, после долгих споров разработчики Линукс решили, что GPU является важным ресурсом и управлять им должен драйвер ядра. Так появился drivers/gpu/drm/radeon, который стал основой для драйвера atikms в Колибри. В 2012 был портирован драйвер i915 и, после экспериментов с I915_GEM_EXECBUFFER, в конце 2013 3D драйвер для Mesa. Последней была сделана поддержка VAAPI и аппаратное декодирование х264 в Fplay и вывод картинки в формате NV12. Сейчас я ищу утечки памяти в связке libva-mesa-libdrm-ядро. Они не критичны, но портят настроение. В ближайших планах полноэкранный режим и переключение страниц, потом pthreads и обновление Mesa. В перспективе — LLVM и radeonsi и r600.
11	Какие тесты проводишь?	Много различных тестов с длинными логами драйвера и библиотек. Трассировка поиска дисплеев и переключения видеорежимов. Логи драйвера при горячем подключении дисплея. Трассировка менеджеров памяти в драйвере и libdrm. Трассировка создания и удаления текстур. Очень много разной трассировки. Обновление драйвера ядра на ближайшую следующую версию требует минимум от десяти до двадцати запусков на железе. Портирование Mesa потребовало около двухсот прогонов. + Тесты на старом железе R300 R500 R700.

Четвертым отозвался Kopa, у которого на Хабрахабре ник FForth.

№	Опросник 4	Kopa (язык программирования Forth)
1	Что ты пытаешься сделать?	По возможности продвинуться в использовании языкового инструментария Форт для создания программного кода для Kолибри ОС.
2	Почему это важно?	Форт наиболее близок идеям, заложенным в основу дизайна Колибри. Например, к эффективному использованию ассемблерного слоя, как дающему максимальный результат при минимальных действиях, при этом оставаясь простым и хорошо управляемым, и масштабируемым инструментальным средством.
3	Почему именно ты работаешь над этой задачей?	Потому, что это мне интересно и разработчики, создавшие основной задел в этом направлении, не активны на форуме (например Михаил Максимов в данный момент отрабатывает свои другие идеи: из известного это создание прототипа ОC с Форт ядром wiki.forth.org.ru, используя и существующий сторонний Форт код, как ru.wikipedia.org/wiki/Open_Firmware и др.) К слову сказать, был даже вариант сборки ядра Колибри ОС c Форт внутри и определённая полемика на форуме этого варианта.
4	Как это было сделано до тебя?	Менять в базе сделанного кода SPF4 для KOS потребовалось не много. Доработать какие то моменты и проверить, например, прохождение теста на ANSI совместимость.
5	В чем были ограничения предыдущего подхода?	Они и сейчас в чём-то существуют. Например, пока Форт для Колибри не компилирует автономных исполняемых файлов, как это существует для SPF4 в Win и Linux, но это не ограничивает его использование как скриптового языка и при определённых действиях, всё же можно сделать и автономные приложения, иначе это был бы не Форт.
6	Что нового в твоем подходе?	О новизне применения Форт в КОS, если вопрос затрагивает это, можно сказать следующее. Форт позволяет минимальными средствами взаимодействовать с API КОS, создавая полезный код. Можно его сравнить в общих моментах с языком «калькуляторного» типа, вобравшим простоту, гибкость и расширяемость. Кроме того, возможно, он может оказаться полезным при создании инструментария работы с базой ассемблерного кода KOS. (какие-то средства мониторинга и управления кодовой базой KOS) и инструментальных сред программирования микроконтроллеров. Считаю, что всё-таки ассемблерный код хоть и уникален к применяемому процессору, но также существует «надассемблерное» понимание общих моментов по переносимости ассемблерных решений между различающимися вычислительными архитектурами.
7	Почему ты думаешь, что твой подход будет успешен?	С момента изобретения Форт он никогда не был в стороне от использования в промышленности и уже неоднократно доказал состоятельность идей, заложенных в его основу и даже породив большое семейство конкатенавных языков. Пожалуй самым известным из которых можно считать PostScript — неутомимый труженник «полиграфического фронта» и его «отпрыска» PDF. Из развивающихся современных языков можно привести Factor и 8th. В некотором числе промышленного оборудования можно так или иначе встретить Форт. Например, уже есть ПЛК (программируемый логический контроллер) ForthLogik c Форт языком, роботы Strobotics программируются на Форт подобном языке, большое количество приборов Nasa запрограммированы на Форт и используют аппаратные Форт процессоры RTX2000. На «всех» существующих вычислительных архитектурах (процессоры, контроллеры) существуют уже реализованные FVM (Форт вычислительные машины) или возможность, используя сторонние языковые средства (ассемблер, Си), портировать один из вариантов FVM и далее, используя, например, симбиоз с базой существующего Cи кода создавать эффективные гибридные решения. Колибри при этом выступает как эффективное средство полнофункционального использования Форт возможностей.
8	Какие части проекта могут стать проблемами?	Общая проблема создать средство уровня ФреймВорк для снижения порога освоения Форт инструментария и популяризации для использования даже детьми (что-то вроде Scratch или запустить в KOS такой проект github.com/phreda4/reda4) и наработать методологический базис. В рамках, например, Windows, Linux есть определённые Форт IDE и их подход может быть адаптирован (перенесён) в рамках KOS.
9	Сколько времени займет проект?	Планирование сроков реализации задуманных идей всегда неблагодарное занятие, но личный опыт подсказывает, что значимые результаты обычно появляются от 1 года при планомерной работе над проектом, т. к. необходимо «взаимоувязать» много разнородных решений.
10	Каковы этапы проекта?	Как таковых этапов проекта нет, т. к., кроме этого интереса, существуют и другие, возможно и близко пересекающиеся с этим проектом. Например, некоторое время назад попробовал один из вариантов генерации минимального размера исполняемого файла для KOS с Форт подобного языка ForthEC (базис реализован на Euphoria).
11	Какие тесты проводишь?	Основные тесты — это проверка работоспособности и стабильности создаваемого кода.

Пятым отозвался Siemargl.

№	Опросник 5	Siemargl (Интегрированная среда разработки для ЯВУ)
1	Что ты пытаешься сделать?	Я хочу сделать внутри Колибри среду для программирования на C, а возможно и для других языков высокого уровня (ЯВУ), имеющих портированные трансляторы (AFAIK, это Pascal, Oberon, C--, Basic). Не полноценную IDE, но для начала хотя бы интегрировать редактор с компилятором.
2	Почему это важно?	Потому что база готового кода и пишущих на С гораздо шире, чем на других языках. Это и упростит простое выполнение простых задач и популяризует ОС. Также я рассматриваю её применение в учебных целях.
3	Почему именно ты работаешь над этой задачей?	Мне нравится компактные неразожравшиеся программы (и ОС). Потому я подключился к проекту Колибри, и выбрал, на мой взгляд, актуальную и интересную задачу.
4	Как это было сделано до тебя?	Из редактора TinyPad можно вызывать FASM, а TextEdit умеет подсвечивать синтаксис для разных языков.
5	В чем были ограничения предыдущего подхода?	Нет интеграции с компилятором С, да и в целом по нынешним меркам удобства как редакторы для программистов они недотягивают.
6	Что нового в твоем подходе?	IDE для Колибри пока нет.
7	Почему ты думаешь, что твой подход будет успешен?	Ни вижу проблем-стопперов.
8	Какие части проекта могут стать проблемами?	Достаточно тяжелый бутстрап — нужно много чего делать самому. См. этапы
9	Сколько времени займет проект?	Полгода-год, если позволит рабочая занятость.
10	Каковы этапы проекта?	Если вкратце то так выглядит ниже. 1. Технические детали работы системы и С-интерфейсы. Модальные окна, межпроцессный обмен, работа с консолью. Выполнено ~80%, остальное требует завершения проекта по написанию С-оберток для работы с системными библиотеками, которым занимается punk_joker в рамках GSoC. 2. Редактор кода Нужно выбрать решение — или дописать имеющийся редактор, или портировать готовый, или написать еще один (что не очень мне нравится), но требуется основа — С-библиотека виджетов. В настоящий момент помогаю писать примеры и тестировать libGUI библиотеку с идеологией, напоминающей WindowsAPI. Скорее всего допишу некоторые виджеты управления, отсутствующие в системе и системной библиотеке. Также есть мысли перевести на С интересные наработки, уже сделанные ребятами для С--. 3.Интеграция с ЯВУ 3.1 KTCC. Выполнено обновление версии компилятора TinyC для Колибри до текущей 0.26. Дописана/исправлена/протестирована стандартная библиотека. Есть некоторые шероховатости, но в целом готовность 90%. Нужно будет еще по завершению подкорректировать libGUI для совместимости и сделать передачу результата компиляции в редактор. 3.2 Интеграция с С--. Недавно GerdtR сделал порт компилятора и в системе много наработок на этом языке. 3.3 Интеграция с Обероном. Этот порт недавно сделал akron1 и проект живой. 3.4 Посмотреть актуальное состояние других ЯВУ в Колибри, возможно интегрировать и их. 3.5 Сделать библиотеку примитивов для обучения, пока на первый взгляд что-то подобное существовавшему в MSX
11	Какие тесты проводишь?	Всё, что пишется, проходит функциональное тестирование…

Шестым отозвался ashmew2 из далекой Индии.

№	Опросник 6	ashmew2 (порт браузера Netsurf)
1	Что ты пытаешься сделать?	Пытаюсь создать эффективный и оптимизированный браузер для KolibriOS, который использует все ранее созданные библиотеки, которые у нас есть, так что мы сможем использовать занимающие малый размер библиотеки на ассемблере x86, такие как libimg и boxlib, чтобы не опираться на библиотеки, портированные из других ОС. Также не используем libcurl из-за его большого размера для дистрибутива KolibriOS. Поэтому сетевую подсистему (браузера), работавшую с libcurl, надо написать так, чтобы она использовала библиотеку http от hidnplayr. Код браузера на Си использует newlib вместо menuetlibc и компилируется в собственной системе сборки Netsurf командой make TARGET=kolibri .
2	Почему это важно?	Это будет полноценный небольшой браузер для KolibriOS, потому что ОС нуждается в быстром и развитом браузере, т.к. Интернет-соединения сейчас хорошо работают даже на маленьких устройствах…
3	Почему именно ты работаешь над этой задачей?	Я вовлечен в проект, потому что я твердо верю, что это стоит усилий. Это будет небольшой браузер, написанный на Си, но работающий рука об руку с ассемблерными частями Kolibri. Я надеюсь, что может еще кто-то будет помогать с проектом, так что некоторые задачи из списка TODO могут быть разрешены или начаты. Доставщик по сети (network fetcher) надо оптимизировать.
4	Как это было сделано до тебя?	Это был функциональный браузер, но в состоянии, в котором он не мог быть интегрирован (merged) в официальный транк Netsurf (git). Доставщик по сети (network fetcher) использовал старую библиотеку downloader и поддерживал несколько функций. Система сборки была просто набором объектных файлов .o, которые должны были быть положены вместе и скомпилированы с помощью хака. Это делало поддержку болезненной и тратилось много времени для обратного поиска символов и т.п. Использовался доставщик файлов (file fetcher) Netsurf как доставщик по сети (network fetcher), что не позволяло обслуживать все варианты использования. Разработчики Netsurf не стали бы его интегрировать в их основную систему (сборки релизов) и распространять в таком состоянии.
5	В чем были ограничения предыдущего подхода?	Недостатки системы сборки Старая библиотека downloader Реализация POST/HTTPS Спагетти-код / Сложно поддерживать Не было способа отслеживать свежие обновления Netsurf.
6	Что нового в твоем подходе?	Доставщик по сети (network fetcher) для замены curl, система сборки, лучше написан код, menuetlibc заменена на newlib. Поддержка изображений был интегрирована с использованием библиотек на языке Си, но они могут быть заменены нашей библиотекой libimg.
7	Почему ты думаешь, что твой подход будет успешен?	KolibriOS нуждается в полноценном браузере, который был бы мал по размеру. С момента добавления в образ KolibriOS он может быть легко использован пользователями и баги, и т.п., могут быть исправлены разработчиками. Так как другие браузеры не имеют многих функций, есть хороший шанс, что Netsurf будет внедрен, когда закончу проект.
8	Какие части проекта могут стать проблемами?	Система сборки, особенно компоновка библиотек в KolibriOS с кодом Си в Netsurf — это проблема, например библиотеки графического интерфейса (GUI) и сетевые библиотеки. Сложно отлаживать код браузера в целом. Также, попытки исправить случайные падения занимает время, так как запуска браузера занимает время и исследование причины проблемы занимает время.
9	Сколько времени займет проект?	Он должен быть готов в 2016 (надеюсь) для массового потребления.
10	Каковы этапы проекта?	Это в основном связано с количеством реализованных функций. В начале первым этапом было получить правильно работающую систему сборки. Продолжилось загрузкой по сети и затем исправлением проблем в графическом интерфейсе. Потом начал думать про поддержку изображений, Javascript и оптимизацию (кода).
11	Какие тесты проводишь?	Они связаны с отзывами пользователей. Но я обычно пытаюсь открыть разные адреса (URL), где я могу проверить некоторые специальные аспекты работы браузера. Например, открыть сайт со списком изображений для проверки поддержки изображений. В случае, когда некоторые сайты с изображениями работают, а некоторые другие не работают, проверяю тип изображения. Затем смотрю исходный код, чтобы разобраться, что могло пойти неправильно вставкой отладочных сообщений, перекомпилирую, заново копирую в образ и запускаю вместе с MTDBG.

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