пятница, марта 31, 2006

Обсуждение Windows Vista на блоге Mini-Microsoft

То, что выход Windows Vista задерживается, не стало ни для кого большой неожиданностью, я думаю.

Сегодня муж мне подкинул ссылку на пост на блоге Mini-Microsoft: Vista 2007. Fire the leadership now!. Пост был опубликован 21 марта и с тех пор бешеными темпами расползается по блогам. Интересен не столько сам пост, а сколько комментарии к нему. Люди, которые заявляют, что они работают в Микрософт программерами, тестерами, рассказывают как на самом деле обстоят дела с Windows Vista. Анонимность, по их словам, они вынуждены сохранять, чтобы их не уволили. Так что проверить на самом ли деле они работают в Микрософт, нет никакой возможности. Любой может туда что-нибудь написать.

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

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

Какие проблемы возникли с Windows Vista? Это проблемы не являют собой ничего нового. Обычные проблемы большой компании. Неповоротливый менеджмент, размытая ответственность. Если что идет не так - виноваты работники нижнего звена.

Мнение тестера, работающего в Микрософт около трех лет:

"Давайте взглянем на великие менеджерские решения в одном из подразделений. Не такая уж и важная группа: просто группа по совместимости с приложениями (Да и кого действительно волнует совместимость с приложениями? Подумаешь, у пользователя не заработает какая-то программа..)

В течение 18 месяцев были сокращены тестеры. Было 50, стало гораздо меньше дюжины. И... наняли менеджеров проектов. Было уменьшено количество тестов. Было принято решение - все тесты должны быть автоматизированы. (Совершенно игнорируя тот факт, что человек взглядом может поймать больше за меньшее время). Наняли немного разработчиков, чтобы написать код автоматического тестированя. Наняли еще немного менеджеров. Саутсорсили часть работы в какие-то компании непонятно куда. (Вы когда-либо попробовали перевести/понять баг, написанный не тестером, а его лидом, по записям тестера?). Меньше тестеров, с меньшим опытом, не обученные и просто тормозные.

Итого: совместимость с приложениями клиентов менее 40% - тщательно скрываемая информация.

Если автоматизация такая великая вещь, то почему оно не нашло больше багов, чем пяток тестеров в лаборатории на другом конце планеты?

Предвижу, что через некоторое время, после нового проницательного взгяда на числа будет сказано, что совместимость на самом деле более 75%. Нет, я сказал 75? Имел в виду 85. В конце концов это будет 95.6."

Еще несколько высказываний:
"Надо избавиться от 90% Процесса между написанием кода и его включением (check in)."

"Я один из тех тестеров, что были "перемещены" примерно месяц назад. [...] После 11 месяцев тестирования я сделал потрясающие открытие: даже если тесты не проходят, код все равно одобряется и принимается."

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

В 2006 все изменилось. [...] Цемент бюрократии проник на все уровни. Сложно поверить, сколько боли в заднице стоит что-либо сделать. Если очень нужно, чтобы какой-то баг был исправлен, твоя команда должна выдержать небольшую битву, чтобы поднять его приоритет. Но Господь помоги тебе, если это баг в другой команде и ты зависишь от фикса."

Начинают увеличивать рабочие часы. Кто-то работает по 16 часов, кто-то:
"Я три недели работаю с 9 до 9. [...] Оно просто не готово. [...] Если выпустить к Рождеству то, что у нас есть, это будет катастрофа, мало того что поздно. Если ты опаздываешь, ты теряешь несколько сотен миллионов на продажах - может быть. Если тот мусор, что крутится у меня сейчас, который дико мигает картинкой, так, что у меня болит голова, не может найти драйверы, теряет виндовые сообщения и посылает email'ы без моего ведома - если это выйдет, фиксить это станет гораздо дороже, кроме того покажет всему миру, что мы некомпетентны.
[...]
Вы спросите меня, почему твой кусок не был готов вовремя? Потому что все работают в одном направлении, концентрируя усилия вокруг майлстоунов. Тесты не запускаются, баги так и лежат [...]. Да, это моя вина, что я не кричал раньше, но нас таких как минимум двое, потому что я не писал Висту в одиночку."

"Это объявление совсем не сюрприз для людей, работающих в Микрософте. Сюрприз то, что это такая небольшая задержка.
Вообще мы не верим, что Vista выйдет в январе 2007 или даже в марте 2007. Любой, кто имеет к этому хоть какой-то доступ, знает какой франкенштейн монстр NT находится внутри. [...]Релиз откладывается из-за багов, но исправление этих багов создаст только еще больше багов. [..]
В какой-то момент мы будем вынуждены что-то сделать и я знаю, что по крайней мере некоторые в моей команде согласны со мной. Мы должны будем все это выкинуть и начать заново. Это то, что Apple сделала с OSX, да, это было болезненно, но это сработало. Нам следовало это сделать в 2000. Сейчас еще более очевидно, что мы должны были это сделать. Начать заново, а уровень совместимости запускать поверх. Apple это сделала, почему мы не можем?
ЕСЛИ мы вообще сможем выпустить Висту - это будет чудо.
[...]
Просто представьте чего мы могли бы достичь, если бы были свободны кодить от всего сердца и создать действительно продукт нового поколения. Просто представьте чего мы могли бы достичь, работая в Apple."

"В Микрософт не доверяют больше своим инженерам. Все измеряется настолько, насколько это возможно и время инженеров упаковано настолько, насколько это возможно."

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

Расстроенные разработчики рассказывают друг другу анекдоты на злобу дня.
-What's the difference between OS X and Vista?
-Microsoft employees are excited about OS X...

$100 million dollar question:
-Why is it that Apple can do it, but we cannot?
-I think 'we' have the wrong 'Steve' leading us...

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

Ссылки по теме:
Microsoft's Not So Happy Family - обсуждение всего происходящего на slashdot.org
Частичный перевод обсуждения Microsoft's Not So Happy Family на slashdot.org

четверг, марта 30, 2006

Статьи по использованию потоков в играх

Нашла на сайте Intel Game Demo Contest небольшую подборку статей по использованию потоков в играх. Я было заинтересовалась самими этими соревнованиями, но участвовать в них, к сожалению, могут только жители США.

четверг, марта 23, 2006

Теория отрисовки графов

Это продолжение рассказа об отрисовке графов. Начало можно найти тут: Нарисовать граф красиво.

Когда берешься за отрисовку графа даже сложно с ходу сообразить, а с чего начать-то? Что неудивительно, потому что задача отрисовки графов не такая уж и простая. Сначала надо определиться что понимается под словами "нарисовать красиво". Всякие разные исследования по этому поводу приходят к следующим, не таким уж и неожиданным выводам: Если вершины друг на друга заползают, если ребра пересекаются, то человеку с этим сложнее разобраться, нежели когда не заползают и не пересекаются. Некоторое влияние на восприятие графа оказывает и количество изгибов ребер, но уже в меньшей степени. Кроме красивой отрисовки нужно еще, чтобы результирующий граф уместился на какой-то площади, обычно это лист бумаги, A4, ну или больше...

Книга по отрисовке графов, которую везде рекомендуют - это Graph Drawing Algorithms for the Visualization of Graphs.

Ее авторы, Иоаннис Толлис (Ioannis G. Tollis), Джузеппе ди Батиста (Giuseppe Di Battista), Питер Эйдс (Peter Eades) и Роберто Тамассия (Roberto Tamassia)- известные специалисты в области теории отрисовки графов. На их сайтах есть ссылки на различные материалы и на их работы по отрисовке графов. На сайте Тамассии есть введение в теорию отрисовки графов (.pdf). Толлис и Тамассия являются главными редакторами журнала Journal of Graph Algorithms and Applications, на сайте которого есть статьи в электронном виде, в том числе и статьи по отрисовке графов.

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


Но можно растянуть узлы по вертикали и/или горизонтали, тогда ограничение на степень графа при ортогональной отрисовке отпадет. Но и сам алгоритм при этом усложняется.

Интересный метод, которых годится для любых графов. Ребра представляются в виде пружин, нужно уменьшить эенергию системы. (Картинки из Tutorial on Graph Drawing)




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

Картинка из статьи On automated graph layout

Но он годится только для направленных графов и не расчитан на отрисовку графов, содержащих циклы.

Отрисовать граф в трехмерном пространстве несколько сложнее. И методы тут применяются соответствующие.
Например вот такой: отрисовать граф в гиперболическом пространстве. Гиперболическая геометрия берет постулаты Евклида, убирает пятый, и предполагает, что через точку можно провести более одной прямой, паралелльной данной. В работе Graph visualization and navigation in information visualisation об этих методах говорится буквально следующее. "Гиперболические отображения окружены чем-то вроде тайны, потому что очень немногие люди, занимающиеся визуализацией информации, действительно понимают математику гиперболической визуализации.". Нехалявный метод, короче. Когда речь идет об этом методе тут же дают ссылку на работу Тамары Мунцнер (Tamara Munzner). На сайте есть описание и готовая реализация с исходниками H3Viewer.


Эта работа лежит и в основе упомянутого мною ранее Walrus'а.

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

Метод "Рыбий глаз" (Fisheye distortion) деформирует отображение графа таким образом, чтобы вершины, находящиеся в фокусе внимания были лучше видны.

Картинка из статьи Graphical Fisheye Views of Graphs

Для трехмерных случаев проблема с загораживанием хорошо решается с помощью прозрачности. Интересное применение прозрачности в работе The Information Cube.



Много работ посвящено отрисовке графов файловых систем, так как эта задача возникает довольно часто.
Файловая система силиконовских станций была показана в фильме "Парк Юркского периода" с помощью 3D File System Navigator. Это одна из первых отрисовок графа в 3Д получившая широкое распространение.



Очень красиво выглядит файловая система, отрисованная в виде дерева. Ветки и листья на деревьях расположены таким образом, чтобы они были освещены как можно больше. То есть, если смотреть со стороны солнца, их лучше всего видно. В работе Botanical Visualization of Huge Hierarchies листьев нет, листья они заменили фруктами. Ну это они называли это фруктами, на самом деле это такие, довольно абстрактные фрукты.

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


Ссылки по теме:
Graph Drawing на wikipedia.org
Links about Graph Drawing
Advances in the Theory and Practice of Graph Drawing статья Роберто Тамассия об отрисовке графов
Толковый словарь по теории графов
"Опрокинутый мир", Кристофер Прист - научно-фантастический роман о тяготах жизни в гиперболическом мире

Книги по теме:
Graph Drawing: Algorithms for the Visualization of Graphs
Drawing Graphs : Methods and Models (Lecture Notes in Computer Science)
Planar Graph Drawing (Lecture Notes Series on Computing)
Graph Drawing and Applications for Software and Knowledge Engineers

четверг, марта 16, 2006

Статья о том, как человек написал RPG за неделю

Статья How To Build a Game In A Week From Scratch With No Budget на gamedev.net начинается словами "An RPG in a week, starting from scratch? How hard could it be?". Джэй Барнсон (Jay Barnson), автор статьи, действительно написал RPG за неделю. Но тут требуются небольшие уточнения. Это очень и очень простенькая 2D RPG. И выглядит она так.


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

Для написания Джэй использовал язык Питон, никакие сторонние движки он не использовал.

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

Получившаяся игра Hackenslash! доступна для скачивания вместе с исходниками.

воскресенье, марта 12, 2006

Робот RiSE


Робот, еще более мерзкий, чем BigDog. Похож на насекомое, умеет забираться на деревья. Как и BigDog'а, его надо смотреть в движении, чтобы проникнуться. Насладиться зрелищем можно тут: видео.

Нашла по ссылке с jwz.

суббота, марта 11, 2006

Права доступа при наследовании

С правами доступа при наследовании довольно легко запутаться. Мало того, что для данных и функций класса в С++ есть целых три уровня доступа: private, protected и public, еще ведь можно и само наследование сделать private, protected и public. Самым загадочным их них является protected-наследование. Запутаться во всем этом зоопарке очень просто, поэтому я аккуратно расписала где какой уровень досупа получится при каком наследовании. Известно, что private можно опускать при описании классов, private ставится по умолчанию. Но я не стала этого делать, чтобы было нагляднее.

Я беру базовый класс, CBase и смотрю какие из его данных видны его наследнику, наследнику наследника, и какие видны извне.


class CBase
{
private:
int privateBase;
protected:
int protBase;
public:
int pubBase;
};

Ни один из наследников не сможет доступиться к private-данным CBase. Как у них сложатся отношения с остальными данными зависит от того, как они были отнаследованы.

private наследование
Те данные, что в CBase были protected и public, стали private в CDerived.

class CDerived : private CBase
{
//унаследованные данные класса
//недоступно:
// int privateBase;
//private:
// int protBase;
//private:
// int pubBase;

public:
void updateDerived()
{
//privateBase=0; //нельзя доступиться
//к private данным CBase
protBase=0;
pubBase=0;
}
};

class CDerived1 : public CDerived
{
public:
void updateDerived1()
{
//privateBase=1; //нельзя доступиться
//к private данным CBase
//protBase=1;//protBase недоступно,
//потому что CDerived использовал
//private при наследовании от CBase
//pubBase=1; //pubBase недоступно, потому что
//CDerived использовал private
//при наследовании от CBase
}
};

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

CDerived dd;
//dd.privateBase=3; недоступно
//dd.protBase=3; недоступно
//dd.pubBase=3; недоступно


protected наследование
Редкий зверь. Встречается в тестах и на собеседованих. Удачных способов его применения в реальной жизни мало.
Те даннные, что в CBase были protected и public стали protected.

class CDerived : protected CBase
{
//унаследованные данные класса
//недоступно:
// int privateBase;
//protected:
// int protBase;
//protected:
// int pubBase;

public:
void updateDerived()
{
//privateBase=0; //нельзя доступиться к
//private данным CBase
protBase=0;
pubBase=0;
}
};

class CDerived1 : public CDerived
{
public:
void updateDerived1()
{
//privateBase=1; //нельзя доступиться к
//private данным CBase
protBase=1; //а тут уже все в порядке,
//в CDerived они стали protected
pubBase=1; // что значит, что наследник имеет
//к ним доступ
}
};

Доступ извне

CDerived dd;
//dd.privateBase=3; недоступно
//dd.protBase=3; недоступно
//dd.pubBase=3; недоступно


public наследование
protected и public данные из CBase остаются, соответственно protected и public.

class CDerived : public CBase
{
//унаследованные данные класса
//недоступно:
// int privateBase;
//protected:
// int protBase;
//public:
// int pubBase;

public:
void updateDerived()
{
//privateBase=0; //нельзя доступиться к
//private данным CBase
protBase=0;
pubBase=0;
}
};

class CDerived1 : public CDerived
{
public:
void updateDerived1()
{
//privateBase=1; //нельзя доступиться к
//private данным CBase
protBase=1;
pubBase=1;
}
};

Доступ извне

CDerived dd;
//dd.privateBase=3;
//dd.protBase=3;
dd.pubBase=3; //pubBase остался с уровнем доступа public,
//к нему теперь можно доступиться.


Ссылки по теме:
Inheritance — private and protected inheritance. Глава из C++ FAQ Lite.
What is protected inheritance?

понедельник, марта 06, 2006

Женские гэджеты

Скоро праздник, в Интернете проводятся всякие разные акции этому посвященные, какие-то удачные, какие-то не очень.

Ну а я напишу о женских гэджетах.

Хотя большинство гэджетов нельзя разделить по половому признаку, есть вещи, которые девушкам ну совершенно неинтересны.



А вот редкому мужчине понравится флешка с виде помады.



Или плеер в виде пудреницы. Кстати, это пудреница мощная вещь. Она и видео умеет крутить.


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

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





Специально для поклонниц iMac, накладные ногти.


Чудесная вещь, веб-камера с зеркальцем.


Когда в морозные зимние вечера от холода пальцы примерзают к клавиатуре даже и не подумаешь, что где-то на свете есть перчатки с подогревом, которые питаются от USB разъема.


Еще такое, одежное.


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

Не знаю насчет Рунета, но вот на английском есть куча сайтов, посвященных именно женским гэджетам. Вот несколько ссылок, на них еще есть ссылки на подобные, там долго можно бродить.
Shiny Shiny. A girl's guide to gadgets
Podgadgets. Personal tech + innovative style for women
Boing Boing. A directory of wonderful things - это не о только о женских гэджетах и вообще не только о гэджетах, но все равно любопытно.

Ссылки по теме:
Лучшие друзья девушки

воскресенье, марта 05, 2006

Робот BigDog


Робот BigDog разработан BostonDynamics по заказу американских военных. Может тащить на себе 40кг груза, преодолевать небольшие возвышенности. Если его несильно пнуть, удерживает равновесие. 1 метр в длину, 70 см в хм... холке, весит 75 кг. Задумывался он как робот, который заменит мулов при передвижениях солдат. Почему его тогда так назвали, интересно. Работает на топливе. Он может сам идти по простому пути, а можно его контролировать удаленно.
На сайте есть видео.






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

Нашла по ссылке с jwz: creepy 4-legged robot. Там один из комментирующих рассказывает, что был в этой компании на собеседовании. Приходит, а там этот робот бродит по этажу...

Ссылки по теме:
Ролики про робота по имени TempBot

среда, марта 01, 2006

SNAil-based data transfer Protocol

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

Нашла по ссылке с Boing Boing: Data transfer via snail is faster than ADSL and pigeons.