Питання Хейлмейера, Пірса і відповіді наших розробників

При заявці на гранти, при презентації проектів інвесторам і начальникам часто рекомендують підготувати відповіді на набори типових питань. З використанням комбінації опитувальників Пірса і Хейлмейера проведено анкетування розробників 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 make it?
Чому це важливо?
Why is it чи варто?
Які ризики і прибуток?
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 Як це було зроблено до тебе? Enter тільки в кодуванні 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.

Я використовую вихідний код офіційних ореп 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 Що ти намагаєшся зробити? По можливості просунутися у використанні мовного інструментарію Форт для створення програмного коду для Колібрі ОС.
2 Чому це важливо? Форт найбільш близький ідеям, закладеним в основу дизайну Колібрі. Наприклад, до ефективного використання асемблерного шару, як дає максимальний результат при мінімальних діях, при цьому залишаючись простим і добре керованим, і масштабованим інструментальним засобом.
3 Чому саме ти працюєш над завданням? Тому, що це мені цікаво і розробники, які створили основний доробок у цьому напрямку, не активні на форумі (наприклад Михайло Максимов в даний момент відпрацьовує свої інші ідеї: з відомого це створення прототипу ОС з Форт ядром wiki.forth.org.ru, використовуючи існуючий сторонній Форт код ru.wikipedia.org/wiki/Open_Firmware та ін) До слова сказати, був навіть варіант збірки ядра Колібрі ОС c Форт всередині і певна полеміка на форумі цього варіанту.
4 Як це було зроблено до тебе? Змінювати в базі зробленого коду SPF4 для KOS знадобилося не багато. Доопрацювати якісь моменти і перевірити, наприклад, проходження тесту на ANSI сумісність.
5 У чому були обмеження попереднього підходу? Вони і зараз в чомусь існують. Наприклад, поки Форт для Колібрі не компілює автономних виконуваних файлів, як це існує для SPF4 в Windows і Linux, але це не обмежує його використання як скриптової мови і при певних діях, все ж можна зробити і автономні додатки, інакше це був би не Форт.
6 Що нового в твоєму підході? Про новизну застосування Форт в КОЅ, якщо питання торкається це, можна сказати наступне. Форт дозволяє мінімальними засобами взаємодіяти з API КОЅ, створюючи корисний код. Можна його порівняти в загальних моментах з мовою «калькуляторного» типу, що увібрали простоту, гнучкість і розширюваність. Крім того, можливо, він може виявитися корисним при створенні інструментарію роботи з базою асемблерного коду KOS. (будь-то засоби моніторингу і управління кодової базою KOS) та інструментальних середовищ програмування мікроконтролерів. Вважаю, що все-таки асемблерний код хоч і унікальний до застосовуваному процесора, але також існує «надассемблерное» розуміння загальних моментів по переносимості ассемблерних рішень розрізняються між обчислювальними архітектурами.
7 Чому ти думаєш, що твій підхід буде успішним? З моменту винаходу Форт він ніколи не був осторонь від використання в промисловості і вже неодноразово довів спроможність ідей, закладених в основу і навіть породивши велике сімейство конкатенавных мов. Мабуть найвідомішим з яких можна вважати PostScript — невтомний труженник «поліграфічного фронту» і його «нащадка» PDF. З країн, сучасних мов можна привести Factor і 8th. В деякому числі промислового обладнання можна так чи інакше зустріти Форт. Наприклад, вже є ПЛК (програмований логічний контролер) ForthLogik c Форт мовою, роботи Strobotics програмуються на Форт подібному мовою, велика кількість приладів Nasa запрограмовані на Форт і використовують апаратні Форт процесори RTX2000. На «всіх» існуючих обчислювальних архітектур (процесори, контролери) існують вже реалізовані FVM (Форт обчислювальні машини) або можливість, використовуючи сторонні мовні засоби (асемблер, Сі), портувати один з варіантів FVM і далі, використовуючи, наприклад, симбіоз з базою існуючого Сі коду створювати ефективні гібридні рішення.
Колібрі при цьому виступає як ефективний засіб повнофункціонального використання Форт можливостей.
8 Які частини проекту можуть стати проблемами? Загальна проблема створити засіб рівня ФреймВорк для зниження порогу освоєння Форт інструментарію та популяризації для використання дітьми (щось на зразок Scratch або запустити у KOS такий проект github.com/phreda4/reda4) і напрацювати методологічний базис. У рамках, наприклад, Windows, Linux є певні Форт IDE і їхній підхід може бути адаптований (перенесено) у рамках KOS.
9 Скільки часу займе проект? Планування строків реалізації задуманих ідей завжди невдячна справа, але особистий досвід підказує, що значущі результати зазвичай з'являються від 1 року при планомірній роботі над проектом, оскільки необхідно «взаємопов'язані» багато різнорідних рішень.
10 Які етапи проекту? Як таких етапів проекту немає, оскільки, крім цього інтересу, існують і інші, можливо і близько перетинаються з цим проектом. Наприклад, якийсь час назад спробував один з варіантів генерації мінімального розміру виконуваного файлу для KOS з Форт подібного мови ForthEC (базис реалізований на Euphoria).
11 Які тести проводиш? Основні тести — це перевірка працездатності та стабільності створюваного коду.
У статті можуть з'явитися результати опитування ще 2-3 розробників, які живуть у далекому зарубіжжі…
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.