Вопросы Хейлмейера, Пирса и ответы наших разработчиков
При заявке на гранты, при презентации проектов инвесторам и начальникам часто рекомендуют подготовить ответы на наборы типичных вопросов. C использованием комбинации опросников Пирса и Хейлмейера проведено анкетирование разработчиков KolibriOS по активно развивающимся направлениям: поддержке файловых систем, файловому менеджеру Eolite, драйверам для видеокарт, языку программирования Forth. Подробности под катом.Популярный наборов вопросов для разработчиков называется «девять вопросов» Хейлмейера. Джордж Хейлмейер возглавлял Агентство по перспективным оборонным научно-исследовательским разработкам США (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 | Какие тесты проводишь? | Основые тесты — это проверка работоспособности и стабильности создаваемого кода. |
В статье могут появиться результаты опроса еще 2–3 разработчиков, которые живут в дальнем зарубежье…
Комментарии (1)
20 августа 2016 в 22:58
0↑
↓
Опросники 3–4 явно не в порядке, возможно, стоит увеличить ширину вопросов?
