О культуре

«Единственная проблема Microsoft в том, что у них абсолютно нет вкуса…. …они не привносят в свои продукты культуру» С. Джобс

Черт! Как это одновременно и банально и актуально!

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

Рубрика: Uncategorized | Оставить комментарий

itow

Отличный вопрос для собеседования:

«Напишите реализацию функции, преобразующую целое число типа int в строку в формате Unicode.»

Тонкость в том, что алгоритм практически ничем не отличается от преобразования в ASCII строку, но, чтобы это сообразить, надо хоть немножко знать Unicode.

Рубрика: Uncategorized | 1 комментарий

swprintf %s

swprintf(ws, size, «%s», string);

Течет память, в размере длины строки, если строка string имеет размер больше 30К. Обнаружено на embedded linux (с ядром 2.6.18), но, как оказалось, проблема существует и в самых последних версиях, например в Ubuntu 11.04 со всеми обновлениями.

Рубрика: Uncategorized | Оставить комментарий

Две ошибки стоимостью в два дня отладки

Недавно я допустил сразу две ошибки, непростительные для человека, утверждающего, что его опыт в С++ приближается к 10 годам. Стоило мне это двух дней отладки.
Вот первая ошибка:
// создаем массив векторов
std::vector<std::vector<SomeStruct> > theVector;
std::vector<SomeStruct> emptyVector;
for (int i = 0; i < 100; i++)
  theVector.push_back(emptyVector);
Я рассуждал примерно так: vector — это объект, хранящий указатели на область памяти, где фактически хранятся данные. Но, для пустого вектора, эти указатели будут равны NULL. А значит, мы можем многократно копировать пустой вектор. Но STLport не был бы STLport’ом, если бы все было так просто. Оказывается, vector в одном из полей хранит указатель на самого себя. И инициализируется этот указатель во время работы конструктора. Поэтому правильно создавать вектор векторов так:
// создаем массив векторов
std::vector<std::vector<SomeStruct> > theVector;
for (int i = 0; i < 100; i++)
  theVector.push_back(std::vector<SomeStruct>());
Теперь о второй ошибке. 
std::vector<SomeStruct>& v = theVector[index1];
// поработали немного с этим вектором, потом понадобился другой
v = theVector[index2];
Все, приплыли! Так делать категорически нельзя! Только я это понял через день отладки, когда заменил ссылки на указатели, которые почему-то :) работали правильно:
std::vector<SomeStruct>* pv = &theVector[index1];
pv = &theVector[index2]; // а вот так делать можно!
Важное отличие ссылки от указателя заключается в том, что в ссылочную переменную адрес объекта заносится один и только один раз — при ее инициализации. Все! Любые другие присваивания ссылочной переменной — это присваивания объекту, хранящемуся по этому адресу. Но с точки зрения синтаксиса, правая и левая части выглядят одинаково в обоих случаях, однако действия, выполняемые при этом, принципиально разные. Все зависит от того, находится ли слева от левой части тип данных или нет.
Рубрика: Uncategorized | Комментарии (3)

Опасные ситуации

Нейл: Какие тяжелые проблемы были обнаружены на Земле, до того, как экспедиция отправилась в космос?

Делиман: На Земле обнаружили много проблем, даже еще в Wind River. Я бы не сказал, что все они были тяжелыми, хотя некоторые были нетривиальными.

Много лет назад, когда Stardust был еще на Земле, обнаружилась проблема с компиляторами. Она заключалась в неправильном использовании одного из регистров, когда значение, хранящееся в нем перезаписывалось до того, как оно было сохранено в постоянной памяти. Это могло привести к тому, что вся система превратилась бы в очень дорогой генератор случайных чисел — явно не то, что мы ожидаем от космического корабля. Компилятор исправили, целое множество версий, которые уже использовались, пришлось пересобрать при помощи исправленного компилятора и разослать исправления всем пользователям.

Нейл: Это было самой трудной проблемой, с которой вы столкнулись при подготовке экспедиции?

Делиман: Было две проблемы: на Mars Pathfinder приоритеты обрабатывались в обратном порядке, а на MER была проблема с файловой системой. Обе были решены одним из наиболее талантливых инженеров, с кем мне когда-либо приходилось работать. Я думаю, что лучшее что сделал Гленн Ривз (эксперт в ПО полета для экспедиции Mars Pathfinder) — это объяснил что было неправильно и как это было исправлено (http://research.microsoft.com/~mbj/Mars_Pathfinder/Authoritative_Account.html) (Замечание: Майк, который часто упоминается в этом документе — это Майк Джонс из Микрософт, Майк Делиман — cотрудник Wind River).

Нейл: Очевидно, что у вас был сумасшедший дом, когда один из аппаратов стал неуправляемым на несколько недель. Что произошло и почему потребовалось так много времени на устранение неполадок? Было ли это той проблемой, которую легко исправить как только установишь причину? Или же это была действительно сложная ситуация, требующая много усилий для ее устранения?

Делиман: Это было точно непростая задача обнаружить, что произошло в данном случае и исправить ситуацию.

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

Хотя я напрямую не был связан с исправлением данной проблемы, я помогал команде насколько мог. Например, меня позвали на помощь буквально через 20 минут после приземления Оппотьюнити на Марс. Здесь потребовалось исследование исходного когда и общение с экспертами из трех временных зон: Япония, Калифорния и кратер Гусева (место, куда приземлился Спирит), а также приходилось постоянно иметь при себе все необходимые данные. Я работал в выходные, просыпался по три раза в день, чтобы связаться с необходимыми людьми, прерывался только чтобы поесть, поспать, принять душ и позаботиться о своих собачках.

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

Нейл: Оказал ли космический корабль какое-либо влияние на операционную систему? То, что вы изучили, работая с НАСА и лабораторией реактивных двигателей, как-нибудь отразилось в исходном коде?

Делиман: Некоторые вещи, которые мы исправляли для космических экспедиций, оказались и в базовом пакете. Например, вместе с несколькими инженерами из поддержки Wind River, мы исправили некоторые математические функции для космических кораблей; полученные подпрограммы были настолько же точны, как и версии стандарта IEEE 754, но работали немного быстрее.

Нейл: Как вы думаете, НАСА когда-нибудь перейдет на операционные системы с открытым исходным кодом для своих космических экспедиций?

Делиман: Я бы не исключал такой возможности, но дело в том, что когда ты работаешь с аппаратурой, стоимостью милиарды долларов и тратишь на это множество человеко-лет, ты хочешь работать с тем, что ты хорошо знаешь. Например, посмотрите на процессор Rad6000. Это 32-битный чип, который работает на частоте 20 мегагерц, и который был вершиной технологической мысли где-то в 1990-х годах. Он может использовать ограниченный объем памяти, и эта память является довольно медленной по сегодняшним меркам. Это в лучшем случае реликвия, по сравнению с сегодняшними процессорами, которые работают в сотни раз быстрее.

Однако, даже несмотря на его старый дизайн, Rad6000 хорошо изучен и использовался во многих успешных космичеких экспедициях и используется до сих пор. Такое успешное прошлое создает хорошую репутацию, которая в свою очередь превращается в веру. Если вы доверяете основной платформе, находящейся в сердце спутника, вы чувствуете веру в то, что спутник сможет достигнуть своих целей.

Рубрика: космос | Оставить комментарий

Жесткие ограничения

 Нейл: Были ли какие-нибудь особые архитектурные проблемы или сложные требования при разработке операционной системы или приложений для MER? Приходилось ли прибегать к каким-либо уникальным техническим приемам по причине того, что целевая платформа — это космический корабль, скажем, особым подходам к удаленной отладке?

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

В лаборатории реактивных двигателей нашли методы получения отладочной информации от системы, когда создавали Mars Pathfinder. Это было сделано благодаря гибкости операционной системы и знанию того, как работает система (прикладной двоичный интерфейс для процессора — ABI). Чтобы этого достичь, лаборатории потребовался доступ ко всем исходным кодам и возможность компилировать систему из них самостоятельно. Это ключевой момент — он дает команде инженеров возможность исследовать абсолютно все компоненты системы. Вообще говоря, программное обеспечения, поставляемое Wind River, не было предназначено для этого. Мне пришлось потрудиться, пока я добился, чтобы ПО, поставляемое для MER можно было использовать так, как это было необходимо для нас, включая полную перекомпиляцю своими силами при необходимости.

Нейл: Как много кода было написано в лаборатории реактивных двигателей по сравнени с тем, что было написано в Wind River?

Делиман: Операционная система и ее ядро занимают менее 2 мегабайт; весь остальной код, а также данные в конечном счете превышали 30 мегабайт.

Нейл: Какие инструменты вы использовали при написании кода для космического корабля?

Делиман: Самыми распространенными "инструментами", на мой взгляд, являются инженеры. У каждого специалиста есть своя предпочитаемая платформа (Sun или PC), редакторы (vi, Emacs, собственный или еще какой-либо) и методология.

Нейл: Насколько контроль качества кода, который отправлялся в НАСА отличался от того, что получали остальные заказчики?

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

Нейл: НАСА повторно тестирует все, что получает от поставщика ПО?

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

Нейл: Чем операционная система, поставляемая в НАСА, отличалась от того, что получали остальные клиенты?

Делиман: В случае с MER, она была уникальной. Было внесено много исправлений и дополнений для телескопа Спитцер (также известного как космический инфракрасный телескоп — SIRFT); другие расширения были разработаны, чтобы минимизировать число изменений в операционную систему. Эти изменения включали в себя вычисления тригонометрических функций с повышенной точностью, улучшенную подсистему ввода-вывода, и исправляли несколько ошибок. Все эти расширения были внесены в ветку, предназначенную для MER. Этот код был затем модифицирован, чтобы скомпилировать его с новейшими версиями компиляторов (включая обновленный front-end для С++), заново протестирован и отправлен команде MER. [Подробную информацию относительно телескопа Спитцер можно найти здесь http://www.spitzer.caltech.edu/]

Код для MER также был адаптирован для сборки его на стороне клиента, не используя инфрмаструктуру Wind River. Это очень нестандартная практика.

Нейл: Были ли вопросы относительно безопасности ПО, предназначенного для космоса? Кто-нибудь пытался "взломать" его?

Делиман: Проблема заключается в том, что единственным способом связи с космическим кораблем являются антенны НАСА. Довольно трудно создать антенну, размером с футбольный стадион, на заднем дворе, не привлекая к себе внимания.

Нейл: А что, если другая страна попытается взять контроль над кораблем? Много стран, дружествнных и не очень, обладают большими телескопами. Кто-нибудь беспокоился насчет взлома космических кораблей со стороны государств-изгоев?

Делиман: Насколько мне известно, некоторые станы шпионили за космическими экспедициями при помощи прослушивания сигналов, их декодирования и, возможно даже, организации помех. Это было особенно актуально во время холодной войны. Но в нашем случае это не военная экспедиция и результаты будут публично доступны — в большинстве случев вскоре после поступления данных на Землю. Единственным мотивом "взломать" космический корабль может быть простая злоба. Но все равно, необходимо много ресурсов чтобы взломать такой аппарат и это будет очень заметно. Здесь используется множество соглашений: радиочастоты, скорости передачи данных и прочие факторы, которые делают практически невозможным взлом космического корабля. Даже если вы обладаете всей необхоимой информацией, вы должны быть в состоянии точно ориентировать вашу антенну на корабль.

Сегодня общественность не считает космические экспедиции чем-то выдающимся. Но на самом деле, такие экспедиции далеко не тривиальны, и даже простейший запуск требует совместных усилий сотен, если не тысяч специалистов, выполняющих свою работу настолько безупречно, насколько это возможно. Я был поражен преданностью и профессионализмом каждого члена команды MER где-бы они ни находились: в НАСА, в корнелльском университете или в цеху, производя подшипники или подушки безопасности. Без такой самоотдачи экспедиция не была бы столь успешной. Я думаю, можно сказать, что любой космический проект столь же напряженный. В каждом проекте, связанном с космосом, в котором я принимал участие, были такие же преданные сотрудники, которые решали казалось бы неразрешимые проблемы, чтобы достичь цели экспедиции.

Нейл: Какие специальные трюки применялись чтобы справиться с проблемами в ПО, которое находится в нескольких световых минутах отсюда?

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

Последняя глава: "Опасные ситуации"

Рубрика: космос | Оставить комментарий

Написание кода для космических аппаратов

 

Нейл: Ваша основная задача в проекте MER заключалась в портировании VxWorks на процессор Rad6000, верно? Работали ли вы также над приложениями для MER? Какие были типичные обращения за поддержкой? Не могли бы Вы привести пример такого обращения из НАСА на этом этапе?

Делиман: Моя основная задача заключалась в обновлении и поддержке программного обеспечения и расширении его, как того требовала команда MER. В январе, когда марсоход Спирит испытывал проблемы с файловой системой, меня вызвали, чтобы помочь диагностировать проблему, а, так как мы лучше в этом разбирались, то и помочь охарактиризовать ее точный тип и масшабы. Если на пальцах, то у нас было два набора блоков памяти для хранения данных: очень большой объем памяти для долгосрочного хранения (flash память) и набор небольших участков в оперативной памяти для временного хранения (они использовались для кеширования данных, пока те не будут перенесены на flash-память). ПО, которое управляло маленькими блоками памяти могло запросить дополнительные блоки при необходимости; в конечном итоге, в системе попросту закончилась доступная память и весь процесс, управляющий блоками памяти аварийно завершился. В результате проявился ряд других проблем, которые и привели к череде перезагрузок системы.

Нейл: Чем осложняется написание кода для космических аппаратов?

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

Нейл: Насколько отличается отладка ошибок на земле и в космосе?

Делиман: На земле Вы используете все, что есть под рукой, включая отладочные инструменты (WinView, дампы памяти, отладчики, работающие с исходным текстом и т.д.) Находясь на разных планетах, приходится в основном думать о проблеме и запускать тесты на том, что есть в лаборатории, чтобы посмотреть, удастся ли воспроизвести симптомы.

Нейл: Можете ли Вы привести пример проблемы, с которой пришлось столкнуться в проекте MER? Как Вы исправили проблему — загрузили исправление или целиком новую версию опреационной системы или приложений?

Делиман: В случае со сбоем файловой системы на Спирите (управление памятью), команда из лаборатории реактивных двигателей еще до инцидента поняла, что здесь может возникнуть проблема. Они приняли наилучшее решение из возможных, отправив на марсоход подпрограммы, для удаления старых файлов, освобождая тем самым место как в долговоременном хранилище, так и в наборе маленьких блоков. Но на следующий день, команда обнаружила, что не все подпрограммы отработали как следует. Их должны были обновить в День 19 (19-й день нахождения на Марсе). К сожалению, в День 18, случилась эта неполадка.

Первое что мы сделали, это диагностировали и классифицировали эту проблему насколько это было возможно, затем протестировали способы ее воспроизведение и предотвращения. Мы обнаружили, что некоторые условия тестирования в лаборатории не соответствовали в точности тому, что происходило на Марсе. Команда создала набор изменений, на основе различий между лабораторией и условиями на Марсе и теми наработками, которые мы сделали для предотвращения такой ситуации в будущем, а затем послали их на оба марсохода (Спирит и Оппотьюнити). Эти изменения касались, в основном, приложений. Надо сказать, что проблема частично заключалась в неправильной настройке — система чрезвычайно сложная и есть масса компонентов, которые необходимо настраивать, чтобы они правильно работали в специфических случаях. Все настраиваемые компоненты работали в точности так, как они были настроены.

Нейл: Как различия в космическом аппаратном обеспечении влияют на то, что программы "видят" или делают?

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

Нейл: Похожа ли защита космического корабля от воздействия окружающей среды на защиту процессора или здесь есть различия?

Делиман: Защитить космический корабль намного проще, чем процессор. Защита процессора может длиться годами и потребует неоднократного тестирования и переделывания, прежде чем удастся получить процессор, который будет одновременно устойчив к радиации и функционален. Это дорогостоящий и длительный процесс. Этим объясняется, почему процессоры, предназначенные для работы в космосе, отстают по своим характеристикам от обычных процессоров. Например, современный "космический" процессор — это чип на основе PPC750, который работает на частоте 130 MHz, тогда как обыкновенный PPC750, работает на частоте более 1 GHz.

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

Нейл: Какие типы программного обеспечения являются ключевыми для операционной системы на космическом корабле?

Делиман: В случае с марсоходами, здесь были программы трех категорий. Первая категория — это программы, разработанные для того, чтобы корабль взлетел с Земли и долетел до Марса; вторая категория — программы, обеспечивающие мягкую посадку на Марсе; и, наконец, третья категория программ была посвящена роли робота-геолога и достижению основных целей проекта: поиску признаков существования воды.

Нейл: Как происходило программирование для космического корабля?

Делиман: Во многом также, как и для любых других целей — были написаны технические требования, спецификации и планы тестирования, затем было написано само программное обеспечение и протестировано, исправлены обнаруженные проблемы, и в конце концов, оно начало работать. В случае со спутниками, хочется быть особенно осторожным при проектировании и разработке ПО и очень аккуратным при тестировании, чтобы сделать его как можно более надежным еще до запуска. После того, как корабль отправился в полет, уже практически невозможно посмотреть, как работает ПО на реальной системе.

Следующая глава: "Жесткие ограничения".

Рубрика: космос | Оставить комментарий