пятница, февраля 26, 2010

C++0x: Делегирующие конструкторы (Delegating Constructors)

Еще одна приятная фича C++0x, которой лично мне очень не хватало - делегирующие конструкторы. Дальше я кратко изложу вот этот документ: Delegating Constructors (revision 3)[pdf].

Бывает так, что классу нужно несколько конструкторов, и тогда бывает удобно из одного конструктора вызвать другой. А сделать этого нельзя. Сейчас это решается функциями инициализации. Это несколько неинтуитивный способ и у него есть недостатки.
Пример кода с функцией инициализации.

class X {
void CommonInit();
Y y_;
Z z_;
public:
X();
X( int );
X( W );
};

X::X() : y_(42), z_(3.14) { CommonInit(); }
X::X( int i ) : y_(i), z_(3.14) { CommonInit(); }
X::X( W e ) : y_(53), z_( e ) { CommonInit(); }


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

Начинающие программисты часто не знают, что вызвать один конструтор из другого нельзя и пишут что-то вроде такого:
class X {
int i_;
public:
X();
X( int );
};
X::X() { DoSomethingObservableToThisObject(); }
X::X( int i ) : i_(i) { X(); }


Этот код компилируется, но делает совсем не то, что хотел программист.

Чего будет в С++0x: один конструктор, он называется "делегирующий конструктор", сможет вызывать другой, "целевой конструктор".

Пример кода:
class X {
int i_;
public:
X( int i ) : i_(i) { }
X() : X(42) { } // i_ == 42
};


Сильно лучше, чем было, но я нашла один существенный минус. Если делегирующие конструкторы образуют цикл, то результатом будет undefined behavior. Диагностику новый Стандарт не требует.

Также см. Стандарт C++0x, 12.6.2.

вторник, февраля 16, 2010

Выступление Эда Катмулла, президента Пиксара

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

Я нашла это выступление по ссылке с блога Джеффа Атвуда Coding Horror. Фраза, которую выделил Джефф: Если у вас есть хорошая идея и вы отдаете ее посредственной команде, они ее испортят. Если у вас есть посредственная идея и вы отдаете ее хороший команде, они ее починят. Или выкинут и придумают новую.

Сначала я хотела как обычно привести ссылку на речь и кратко перессказать о чем там. Но потом я поняла, что перессказать не получится и перевела все целиком. Выступление по духу напомнило мне книгу Founders at work. Но если в случае Founders at work перевести ничего нельзя, потому что копирайты, то тут все лежит в открытом доступе и можно переводить. Перевод чуть подсокращенный, я выкинула несколько незначащих фраз, чтобы текст легче читался.

Итак, само видео, есть субтитры:


Ссылки по теме:
Founders at work
Своя компания
Перевод выступления Кармака на Quakecon 2004

Перевод:

Эд Катмулл, Пиксар: Не давайте кризису расти

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

Я хочу начать с двух вопросов. Первый: "Почему успешные компании терпят неудачи?". Я вырос рядом со всей этой индустрией компьютеров, видел эту поразительную революцию, и видел как компании приходят и уходят. Две из них особенно мне запомнились.

Одна из них - Evans & Sutherland, которая находится в Солт Лейк. Это была одна из передовых компаний компьютерной графики, они лидировали. У них было больше знаний и опыта, чем у кого-либо. Они были в прекрасном положении, они могли взять свои знания и выйти на новый уровень как компания. Но они приняли определенные решения, в результате которых они потеряли свое лидерство. Новая компания вышла вперед, это была Silicon Graphics, основанная Джимом Кларком, который, между прочим, работал раньше в Evans & Sutherland. И SGI быстро продивнулась. Они делали графические станции, которые использовались по всему миру для различных задач по визуализации. Для них было написано много софта. На их машинах произошла революция в компьютерной графике и индустрии развлечений. У них было все. Но они сделали две серьезные ошибки. При этом были люди, которые говорили им: "Это очень плохая идея. Не надо так делать". Тем не менее, они сделали, что сделали, и они потеряли лидерство. Они уступили лидерство компании NVidia. Это компания, между прочим, была создана бывшими сотрудниками SGI. Они сделали много замечательных вещей. И они до сих пор лидеры, вместе с ATI.

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

Почему я начал с этого вопроса, потому что в то время мы пытались понять как наладить работу. Мы основали компанию. Это сложно.
Я думал "Если мы когда-нибудь будем успешны, как уберечь себя от попадания в ту же ловушку, в которую попадают другие компании? И дело вовсе не в том, что они сбиты с толку чем-то, что возникло вдруг внезапно, неожиданно. Все эти вещи, они довольно очевидны. Они пропускают очевидные вещи.

Второй вопрос возник за обедом с главой одной студии, пару лет назад. Он сказал тогда: "Наша главная проблема не найти хороших людей, а найти хорошие идеи".

Это интересная фраза. После этого я не раз давал выступления и задавал этот вопрос аудитории, спрашивал их, согласны ли они с ним. И я обнаружил, что в каждом случае аудитория разделялась пополам. Это удивительно. Было неважно, были ли это студенты, профессиональные управленцы, художники, школьные учителя... - они все так разделялись. Часть думала, что это правильно, часть думала, что это неправильно.
Так, позвольте мне вернуться к этому второму вопросу позже. А сейчас давайте вернемся в 91 год, когда нашей компании было около пяти лет и когда мы проходили через череду испытаний, через которые проходят все, кто создает свою компанию. У нас наконец появился шанс, мы начали сотрудничать с Диснеем, делать свой первый комьютерно анимированный мультфильм "История игрушек". В то время мы сделали несколько правильных вещей. Художники и технари работали в приятельской атмосфере. Они общались друг с другом. Они считали друг друга специалистами мирового класса. Система компенсаций была одинаковой. Им было разрешено жениться друг на друге [смех в зале]. Если были проблемы, а проблемы были всегда, люди могли свободно приходить и рассказывать о них. Все проблемы решить нельзя, но важно знать о них.

Еще у нас была такая вещь, которую мы называли "интеллектуальное доверие". У нас была группа людей, которые очень хорошо умели рассказывать истории. Они были не только веселые и сосредоточенные и хорошие рассказчики, они полностью доверяли друг другу. И очень часто они были, как это говорится, "грубо откровенны", но только они не думали об этом как о грубой откровенности. Они думали, что это была "необходимая откровенность", и все остальные воспринимали это так же. Это никогда не было проявление эго или желание унизить кого-то. Это всегда было о фильме. Поэтому можно сказать что-то неприятое и это всегда будет воспринято правильно. Такой уровень товарищества в ключевой группе людей - это настоящее золото. Потрясающие люди, до сего дня они остаются такими же. То есть вот это у нас было правильно.

У нас был процесс просмотра фильма, который состоял из нескольких пунктов, которые Jonda переняла у Диснея плюс еще некоторых, которые использовали ILM и Lucas Film. Но это была уникальная комбинация. В процессе разработки мы отсматривали материал каждый день. Это неожиданно для большинства людей.

Большинство, вы можете это себе представить, даже если вы не особенно хорошо рисуете, да даже и если хорошо рисуете... Допустим, вам надо собрать анимацию или нарисовать что-то и показать это известному аниматору мирового класса. Вы не захотите показывать что-то, что выглядит недостаточно хорошо. Вы покажете это чуть позже, когда все сделаете правильно. И все дело в том, чтобы прекратить так себя вести. Мы показываем каждый день неготовую вещь. Если все делают это каждый день, то смущение преодолевается. А когда нет смущения, вы более креативны. И это не очень очевидно, но это сильно помогло нам во всем. Показывайте работу, когда она еще не готова. Еще одно преимущество такого подхода в том, что когда работа закончена, то она закончена. И это может показаться глупым, но многие люди над чем-то работают и они не хотят показывать это еще, скажем, две недели, пока не закончат, только дело в том, что оно никогда не будет идеально. Они никогда не закончат. Нужно проходить через этот итеративный процесс. И надо это делать чаще, чтобы изменить динамику.

Также, когда мы начали работать над этим фильмом, мы привели новую группу людей, потому что у нас были художники, были технари, но мы никогда до этого не делали фильмы. Так что у нас никогда до этого не было производственных менеджеров. Они за всем следили, проверяли, что материал дошел куда нужно. Ведь там было, буквально, миллион вещей. Много чем надо управлять, по поводу много чего беспокоиться. Для этого нужны люди с особым типом мышления и опытом работы. Эта новая группа приехала из Лос-Анджелеса. Мы закончили работу над фильмом и фильм стал очень успешным. Более успешным, чем кто-либо мог себе представить. Отличный старт в области компьютерной анимации. Мы строили компанию, мы стали публичными через неделю после выхода фильма. Это было самое больше IPO того года, по-моему. Мы хотели, чтобы люди видели наш продукт до того как они инвестируют. И все прошло отлично.

Примерно в это же время, возможно, немного позже, нам нужно было начинать работу над новым фильмом. У вас не может быть всего один продукт. Нужно еще. И мы очень беспокоились по поводу "синдрома второго продукта" где вы делаете все то же самое, что и в первом, только больше и перегораете. Когда команда заканчивала работу над Историей игрушек, мы начали ставить их на другой проект. Мы встретились с художниками и сказали "Это было здорово. Давайте сделаем еще фильм." Мы встретились с технарями и они сказали "Отлично, мы готовы". Потом мы встретились с производственными менеджерами. Они сказали "Чего? Нам здесь не нравится, мы уходим". То есть мы пропустили эту проблему. Они чувствовали себя людьми второго сорта. Я походил и поспрашивал художников и технарей. И да, действительно, они считали менеджеров людьми второго сорта. [смех в зале]. Все правда. Они считали, что менеджеры только мешают. Это была серьезная проблема.

Первый вопрос был "А в чем собственно проблема?". Тут я хочу вернуться к основным вещам. Создание фильма - это очень организованный процесс. И, поскольку очень много вещей происходит одновременно, вы можете легко потерять над этим контроль. У нас была жесткая иерархическая структура. Ответственные люди хотели, чтобы информация шла только по правильным каналам. И она шла либо вверх по иерархии, либо вниз по иерархии. И этот контроль над потоками информации всех раздражал. Но все же контроль должен быть. Ключевой момент - и мы это тогда поняли - был в том, что мы перепутали организационную структуру с коммуникационной структурой, очень частая ошибка, которая случается во многих компаниях. Эти структуры различаются. Да, вы должны быть организованы, должен быть порядок. Вы можете потерять контроль. Но должна быть возможность общаться кому угодно с кем угодно в любое время. Идея в том, чтобы пойти можно было к кому угодно. Поставьте в известность менеджера, если вам нужно к кому-то пойти. Политика открытых дверей означает, что вы можете пойти к главе компании. Но для нас политика открытых дверей значит, что можно пойти к кому угодно. Это очень важно. И когда мы сломали старую практику, все сильно изменилось.

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

Другой, сложный для меня вопрос "Как мы упустили эту проблему?" Мы сделали фильм, я хорошо проводил время и я ничего такого не ждал. Я думал, что у нас все хорошо, открытые двери и все такое. Совсем не заметил. Частью проблема была из-за того, что несколько человек пришло в сложившуюся организацию. И они приняли такое положение дел. Они отчитывалась перед продюсерами. И если им чего-то не нравилось... это работа всего на четыре месяца, надо ее закончить и двигаться дальше. Зачем им жаловаться. Надо просто отработать. Но, с другой стороны, им очень нравилось работать над передовым фильмом. Творить историю - это волнительно. Им это нравилось. Им нравилось работать с Джоном Лассетером. И я понял, что из-за того, что им многое нравилось, они были готовы смириться с тем, что им не нравилось.

И это фундаментальная проблема компаний. "Успех скрывает проблемы". Это случается со многими из нас в нашей жизни со здоровьем. Когда мы здоровы, мы не обращаем внимание на вещи, которые вредны для нас, наше хорошее здоровье позволяет нам это не замечать. Годами спустя так уже не происходит, но мы привыкли. Такое же случается и с компаниями. Это случается с правительствами тоже. Когда вы здоровы, у вас есть ресурсы, вам можно не обращать внимания на проблемы. И когда я смотрю на эти компании, на SGI и т.п. они были очень сильны. У них были проблемы, но они не обращали на них внимания, потому что они почивали на лаврах. У них было все хорошо. Успех не дал им копнуть глубже и найти проблемы. И хотя я был в курсе этой проблемы, я тоже попался. То есть просто знать об этом недостаточно. И следующим шагом для нас был - мы тогда делали Bug's Life - мы стали делать продолжение Истории игрушек. Логика, которая пришла от Диснея была такая: если у вас есть успешный фильм надо продолжать работу, чтобы герои не забывались. То есть нужен простой такой сиквел. Мы наняли двух аниматоров, дали им режиссировать картину, собрали команду и начали делать фильм. И сразу же у нас начались проблемы. И она была в том, что одна группа у нас делала второсортный сиквел. А другая команда - команда А - работала над Bug's Life, там были лучшие люди и настроение было "мы должны соответствовать Истории игрушек". Это все было не очень хорошо. Два стандарта качества под одной крышей? Это плохо для души. Нам не следовало думать, что нормально делать то, что не замечательно. И довольно быстро мы это прекратили. Мы решили показывать Историю игрушек в кинотеатрах. И мы решили сделать ее первоклассной. Когда вы только начинаете делать фильм, он выглядит не очень хорошо. Когда вы складываете все вместе, когда у вас есть фильм, если фильм хороший, то работа практически сделана, так? Но когда вы только начинаете, у вас ничего не готово. И тут вам придется многое преодолеть. Отсматривать каждые шесть или три месяца. При этом вы хотите видеть движение вперед. Иногда вы делаете шаг назад, но в целом вы должны двигаться вперед. Мы же топтались вокруг чего-то низкокачественного. Слишком много вещей пошло не так. Режиссеры не справлялись, у продюсеров были проблемы и в целом команда не была особенно работоспособной. И я пошел к Джону, который в то время работал над Bug's Life и сказал "У нас проблема". И он ответил "Не волнуйся. Доверяй процессу. Все будет хорошо." Но оно не стало хорошо.

В 1998 году работа над Bug's Life была закончена. Потом был мировой тур и Джон поехал в этот тур. Но он знал, что когда он вернется, он должен будет разбираться с проблемами Истории игрушек 2.

На момент его возвращения История игрушек 2 должна была быть закончена через девять месяцев. То есть сроки уже были довольно жесткие. Итак, он вернулся. Посмотрел первую Историю игрушек перед тем как придти на работу из своего тура по Европе, пришел посмотрел текущую версию. Вошел и сказал. "Ты прав, у нас серьезная проблема". Дальше мы взяли нашу первоклассную команду и поставили их на проект. Мы пришли к Диснею и сказали "Фильм недостаточно хороший. Нам придется его выкинуть и все начать сначала". И ответ был "Ну нас самом деле он лучше чем вы думаете. Мы думаем, что он достаточно хороший и, что гораздо важнее, уже слишком поздно. У вас в буквальном смысле нет времени чтобы его переделать." И мы ответили "Он недостаточно хороший и мы знаем, что времени нет, но мы все равно его переделаем". И мы вернулись. Джон велел команде хорошо отдохнуть на выходных и вернуться на работу второго января. И потом мы начали работать. У нас оставалось восемь месяцев.

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

Над проектом работала женатая пара, дело было в июне, то есть летом. Отец должен был отвезти ребенка в детский сад, но забыл. Он пришел на работу, а ребенка оставил в машине. Становилось все жарче, мать начала его спрашивать про ребенка. Они поняли в чем дело, выбежали, ребенок был без сознания. Ребенку приложили лед и все закончилось хорошо. Но это был один из тех случаев, когда нужно задаться вопросом "Почему это случилось? Мы слишком тяжело работаем?". То есть когда я говорю о "тяжелой работе", она действительно было тяжелая. Фильм был закончен вовремя и был очень успешен. Многие думают, что он лучше первого. Но мы вынесли из этого несколько уроков.

Первый из них, из тяжелой и интенсивной работы мы поняли как лучше работать, чтобы предотвратить RSI. Мы наняли на полный рабочий день эргономиста и медсестра приходит дважды в неделю. В офисе постоянно находится массажист. У нас ограничено число часов, которые человек может работать. Мы установили несколько правил и заставили людей их соблюдать. Пилатес, йога, футбол - все, чтобы люди находились в хорошей физической форме. Люди поняли, что их хотят здесь видеть надолго. Что я тут хочу сказать. Такие программы, конечно, стоят денег. Но и люди стали гораздо меньше болеть. Страховая компания снизила расценки и в итоге мы остались в плюсе. Я это все говорю, потому что есть люди, которые говорят, что они не могут себе это позволить. Я же хочу сказать, что это можно и нужно себе позволять.

Теперь о фильме, которые не получался. Что именно там не получалось? Дело в том, что сценарий был все тем же. Игрушка, которую украл Коллекционер, эта игрушка должна сделать свой выбор. Но это был не фильм. Потому что когда выходит мультфильм сделанный Пиксаром и Диснеем, вы знаете чем все кончится, что Вуди останется со свой семьей. Если вы знаете чем все закончится еще до того как начали смотреть, у вас нет фильма. Надо убедить людей, что там был настоящий выбор. И когда люди стали его переделывать они добавили песню Джесси о том, что она выросла и пошла дальше. И это было ее послание Вуди. Она говорит "Возможно, тебе нравилось как дела обстояли раньше, но жизнь продолжается. Она меняется. И этому нельзя противиться." И это ведь так и есть, правда? Мы все это знаем. И принимая все это во внимание, мы понимаем, почему выбор, который он должен сделать, такой тяжелый. И все то, что мы добавляем в фильм, связано с принятием этого решения, зритель оценивает это и это помогает ему насладиться фильмом. Это то, что отличает фильм от дешевого сиквела.

Итак, я вернулся к первому вопросу - что важнее? Хорошие идеи или хорошие люди? Ответ предельно ясен: идея осталась той же. Если у вас есть хорошая идея и вы отдаете ее посредственной команде, они ее испортят. Если у вас есть посредственная идея и вы отдаете ее хороший команде, они ее починят. Или выкинут и придумают новую.

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

В то время у нас был отдел разработки и его структура была такая же как и у большинства других студий. Группа людей, которые ищут идеи, из которых можно сделать фильмы. И после этой истории мы пришли к выводу, что тут мы думаем неправильно. Цель разработки - это не найти хорошии идеи. А создавать команды людей, которые хорошо работают вместе. Это изменило наше представление о фильмах. И до сих пор наш отдел разработки очень любят режиссеры, потому что он как группа поддержки. Это не кто-то, кто говорит режиссеру что делать. Это не ворота. Это группа поддержки. Режиссеры - потому что у нас студия с фокусом на режиссеров - это те люди, которые ответственны за фильм, а все остальные их поддерживают. Как мы оцениваем прогресс разработки. Это то, насколько хорошо команда работает вместе. Потому что поначалу фильмы, которые они делают - это каша. Это как обычно в жизни. Первый блин комом. Однако после первого вы учитесь. Единственная ошибка - это если вы не извлекаете из этого уроки. итак, наш критерий оценки "Насколько хорошо эта команда сработана?". И это нас никогда не подводило. Когда команда хорошо работает, они преуспеют. Если нет - они не справятся.

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

Но, к сожалению, люди любят копировать неправильные вещи. Люди действительно копируют вещи. Это странно, потому что копированиие, в некотором смысле, это форма обучения. И вы говорите "Я посмотрю что сделали другие и я это скопирую". Но во многих смыслах, это поверхностный подход. Вот, например, многие любят делать ремейки фильмов. Но они всегда делают ремейки хороших фильмов и редко у них получается сделать это действительно хорошо. И при этом есть тысячи фильмов с хорошей идеей, который просто плохо сделаны. Нужно делать ремейки плохих фильмов. Или вот как с другими продуктами. Лучшие продукты - это не те, которые просто копируют чужие хорошие продукты. Они находят то, что не работает, и чинят это.

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

Мы установили правило делать постмортемы после каждого фильма, пытались делать глубокий анализ. Первые постмортемы были очень хорошие. Мы очень старались, чтобы люди чувствовали себя спокойно, что никто будет наказан за то, что обозначил проблемы и все много чему научились в итоге. Но потом люди начали заниматься профанацией. Они понимали, что это важно, что надо их писать, но им не нравилось этим заниматься. Почему им не нравилось делать анализ. Они уставали работать над одним и тем же три года, и им не хотелось больше об этом думать. Кто-то пытался оправдываться. Кто-то считал, что цель этих собраний - поднять дух команды. "Посмотрите что мы сделали!" То есть это не анализ. И нам надо было это преодолеть, потому что если ты не делаешь глубокий анализ, то ты начинаешь идти по легкому пути. потому что, повторюсь, когда у вас все хорошо, фильм вышел, вам хочется на этом остановиться, наслаждаться ситуацией и не копать глубже.

Тут мы поняли, что нужно поменять работу над постмортемами. Мы попросили людей выбрать пять вещей которые они бы сделали снова и пять вещей, которые они бы больше не стали делать. Мы так сделали для баланса, на самом деле нас интересовали только то, что они бы делать не стали. Еще один важный момент - получить как можно больше информации о процессе. Когда ты добываешь факты, это стимулирует дискуссию. А эти дискуссии очень ценны. В большинстве случаев получается, что две трети были сделаны правильно, одна треть неправильно. Вы никогда не знаете заранее, как именно все сложится, но в целом одну треть вы сделаете совершенно неправильно. Это нормально, зато две трети было сделаны правильно.

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

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

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

Когда я только начинал работу с Пиксаром, я был технарем. И мне пришлось быстро учиться бизнесу. Я не пошел в бизнес-школу, я просто прочел много книг. И, по большому счету, я ничего из них не узнал. Тогда я подумал, возможно, мне нужны их краткие содержания. Есть такой сервис с кратким содержанием бизнес-книг. И читая эти краткие содержания я вдруг понял, что они все ни о чем [смех в зале]. Я подумал "Как так? Неужели в этих книгах не было содержимого?" А так оно и было. "Неужели нельзя взять эти вещи и сжать их, не потеряв смысл?" - видимо нельзя.

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

Каждый продукт, который мы делаем, должен быть незаурядным, что означает, что мы не можем повторяться. И для меня это важно. Потому что многие в Голливуде этого не понимают. Если что-то успешно - если у вас есть Звездные войны, Шрек, неважно "Давайте сделаем это снова!", да? Мы пытаемся сделать снова все то же самое. Но нельзя думать так о любых продуктак. Все ново и оригинально. И поэтому наши подходы при работе с этим, при решении проблем, должны быть нетривиальны. Секрет в том, чтобы копать глубже и глубже и понимать при этом, что мы всегда упускаем что-то важное.

Позвольте мне вернуться к первому вопросу. Почему успешные компании терпят неудачи? Почему Золотой Век не длится вечно? Я верю, что организации, организации состоящие из людей, принципиально нестабильны. Чтобы они не развалились вам нужно постоянно работать. И сыпаться они начинают медленно. Большинство людей это не замечает, их успех ослепляет их. Они не видят что все посыпалось. Сыпется все медленно, но потом наступает быстрый коллапс. Нужно делать постоянные оценки. Надо уметь смотреть правде в глаза. Я упоминал Кассандру из греческой мифологии. Она проклята, она видит правду, но никто ей не верит. Я не думаю, что греки тут правы. Я думаю, что прокляты были люди, которые не слушали ее. Мы должны искать правду постоянно. Когда мы слышим что-либо, проверяйте "а это правильно?". Я думаю, что в производстве фильмов - в нашем процессе - у нас бывают различные кризисы, но есть два фундаментальных типа кризисов.

Первый - это когда вам не нравится то, что вы видите. Вам приходится вносить изменения. Факт внесения изменений не есть кризис сам по себе. Это просто работа. Кризис состоит в том, что есть много людей с различными интересами. И когда вы пытаетесь реорганизовать работу, люди начинают конфликтовать друг с другом. И это тяжело. Здесь замешаны эмоции. Но вы делаете это, и ваш фильм получается лучше.

Второй тип кризиса - это когда вы выпускаете фильм, а людям он не нравится. Тут уже поздно что-либо делать. Разница между этими двумя кризисами в том, что первый мы придумываем себе сами. И это важно.

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

пятница, февраля 12, 2010

As seen by...

Программисты на разных языках глазами коллег. Боян, но прикольный...

четверг, февраля 11, 2010

Как выключить Google Buzz

Вопрос, который сегодня волнует миллионы людей - как же отключить Google Buzz? Это очень просто. Внизу Gmail'ового интерфейса, рядом с копирайтами, есть неприметная строчка "turn off buzz". Нажмите на нее. Если когда-нибудь вы решите, что Buzz вам все-таки нужен, то все можно легко включить обратно. Потому что вместо строчки "turn off buzz" на том же самом месте у вас будет "turn on buzz".

Updated: в комментариях справедливо заметили, что это отключает Google Buzz не до конца. Вот тут статья с описанием более тщательного удаления, спасибо Юрию: Buzz off: Disabling Google Buzz

Вот еще статья для вдумчивого чтения: How to Do Everything in Google Buzz (Including Turn It Off)

понедельник, февраля 08, 2010

Heap corruption и работа с дебажной кучей

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

Основная мысль - дебажная куча отличается от релизной, чтобы облегчить отладку. И, если в дебаге произойдет порча памяти, то ее можно отловить. Visual Studio выдает в таком случае окно с сообщением и пишет в Output что-то вроде


Heap corruption at address.
HEAP[MyProg.exe]: Heap block at 0AC6A400 modified at 0AC6A6EC
past requested size of 2e4

Итак, в чем состоят отличия и каким образом отлавливаются ошибки. Давайте я пример приведу, с примером удобнее.
class CBase 
{
public:
int BaseI;
int BaseJ;
};

class CDerived : public CBase
{
public:
int DerivedI;
};

int main()
{
CBase *pBase = new CBase;//(1)

pBase->BaseI = 3;
pBase->BaseJ = 4;//(2)

delete pBase;//(3)

return 0;
}


Как будет выглядеть память в точке (1). (Чтобы вывести окно с памятью, выберите Debug->Windows->Memory->Memory1).

0x00984ED8  cd cd cd cd cd cd cd cd fd fd fd fd 00 00 00 00


У меня экземпляр класса CBase расположился по адресу 0x00984ED8. Оба int'а, а это восемь байт, заполнены значением 0xCD, Clean Memory. Это значение по умолчанию.
Дальше четыре байта 0XFD, Fence Memory, она же "no mans land". Это такой заборчик, которым обрамляется свежевыделенная память. Перед адресом 0x00984ED8 стоят точно такие же четыре байта.

Точка (2).
0x00984ED8  03 00 00 00 04 00 00 00 fd fd fd fd 00 00 00 00


Мы записали значения 3 и 4 и они идут одно за другим. Младший байт идет первым, потому что я работают с little endian платформой.

Точка (3)
0x00984ED8  dd dd dd dd dd dd dd dd dd dd dd dd 00 00 00 00

Память после удаления заполняется значениями 0xDD, Dead Memory. После вызова функции HeapFree() будет заполнена значениями 0xFEEEFEEE.


Давайте теперь сымитируем багу и посмотрим как Visual Studio ее поймает. Это реальная бага, я ее упростила до синтетического примера. На самом деле кода было больше и он был размазан по нескольким функциям.


CBase *pBase = new CBase;//(1)

pBase->BaseI = 3;
pBase->BaseJ = 4;//(2)

CDerived* pDerived = static_cast<CDerived*>(pBase);

pDerived->DerivedI = 7;//(3)
delete pBase;


Итак, мы стали приводить по иерархии с помощью static_cast'а, вместо dynamic_cast'а. Что в итоге получили. В точках (1) и (2) программа выглядит все также. В точке (3) мы полезли в чужую память и затерли забор.
03 00 00 00 04 00 00 00 07 00 00 00 00 00 00 00


После попытки вызвать delete pBase мы получим сообщение об ошибке, потому что забора нет, а это означает, что мы лазили в чужую память.

HEAP CORRUPTION DETECTED: after Normal block (#68) at 0x008D4ED8.
CRT detected that the application wrote to memory after end of heap buffer.


Еще различия между дебажной и релизной кучами приводят к тому, что программа начинает себя вести по-разному в дебаге и в релизе. Простой пример - дебажная "падает", релизная нет. Очень может быть, что "падение" - это не падение вовсе, а как раз сообщение о порче памяти. Почитайте повнимательнее, что там в окне написано.
Также народ жалуется, что дебажная версия работает сильно меденнее релизной. Причиной этого в том числе может быть дебажная куча. В интернетах пишут, что можно ее в дебаге отключить то ли с помощью переменной окружения _NO_DEBUG_HEAP, то ли NO_DEBUG_HEAP, в единицу ее надо выставить. Я пробовала ее отключить, куча осталась дебажной.

Ссылки по теме:
Win32 Debug CRT Heap Internals
Inside CRT: Debug Heap Management
Memory Management and the Debug Heap (MSDN)
Приведение типов в C++

пятница, февраля 05, 2010

среда, февраля 03, 2010

Немного про биопринтеры, технологическую сингулярность и трансгуманистов

Презентация биопринтера, т.е. принтера, на котором можно печатать человеческие органы, произвела сенсацию на TEDMED в конце прошлого года. Полный ролик выступления Энтони Аталы (Anthony Atala) TED'овцы выложили совсем недавно.

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

Вот полный ролик с TED'а.


Интересно, реальность гораздо интереснее фантастики. По крайней мере, я никогда и нигде про биопринтеры не читала.

Это было вступление для привлечения внимания, дальше - немного о популярных теориях нашего будущего, которое наступает со страшной силой и к которому ведут изобретения вроде показанного биопринтера.


Технологическая сингулярность

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

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

Ребята они задорные, мне нравится их искренность, энтузиазм и вера в светлое будущее. Однако, у них популярна идея смены парадигмы, которая состоит в том, что чем больше людей верят в технологическую сингулярность, тем быстрее она наступит. Поэтому они активно пиарят идеи трансгуманизма и не всегда у них получается вовремя остановиться. Пиар бывает разный. Например, они проделывают огромную работу для распространения информации о научных достижениях, что есть хорошо. Правда, слова действуют на людей гораздо хуже, чем красивые картинки, тот же фильм "Аватар" сделал для пиара идеи загрузки сознания больше, чем все трансгуманисты вместе взятые. (Хотя, вряд ли Камерон ставил себе такую цель :-)).

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




Рэймонд Курцвейл (Raymond Kurzweil). Самый известный трансгуманист, о нем даже фильм сняли. Странен. Автор многочисленных футурологических книг.



Элизар Юдковски (Eliezer Yudkowsky). Автор термина "дружественный искусственный интеллект" (Friendly artificial intelligence, FAI). Основатель коммьюнити-блога Less Wrong.



Майкл Аниссимов (Michael Anissimov) - автор блога Accelerating future, много ездит с лекциями



Обри ди Грей(Aubrey de Grey) - геронтолог. Активно призывает к борьбе со старением.

Про борьбу со старением чуть подробнее...

Имморталисты
В последние несколько месяцев российские имморталисты развернули кипучую деятельность по саморекламе. Вернее, один имморталист, Михаил Батин, а потом к нему в блог подтянулись еще люди.

Много пишут про то, что исследования в области борьбы со старением проводить надо и пытаются переубедить тех, кто думает иначе. У меня сомнений по этому поводу нет, поэтому едем дальше. (У кого есть - посмотрите доклад Обри ди Грея).

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

Я там побывала, послушала. Нормальные ребята, адекватны. В отличие от большинства трансгуманистов, которые только рассказывают про то как оно будет, они более целеустремленные. Занимаются финансированием исследований в области борьбы со старением. Активно пиарятся, чтобы сформировать "социальный заказ" на эти исследования и тем самым привлечь больше денег. Мне этот пиар не очень нравится, но, с другой стороны, я понятия не имеют как формировать социальные заказы и ничего лучше предложить не могу.

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

В целом, по поводу старения. Мне незамутненное мнение неспециалиста. Даже если удастся придушить причины, ведущие к старению, мы воткнемся в новые проблемы и в лучшем случае здесь стоит говорить о продлении жизни и улучшении качества жизни. То есть иммортализм - это такая линия горизонта, которая все время отодвигается по мере приближения к ней. Однако исследование причин старения - это лучшее понимание природы человека и различных заболеваний. Лечение заболеваний типа болезни Альцгеймера имморталисты рассматривают как побочный результат своей деятельности, но для меня он самый что ни на есть основной. Короче, я двумя руками "за".



Ну вот и всё на сегодня, как говорится. Я специально описала все очень кратко, если вам интересно - ссылок я привела достаточно, найдете что почитать :-). В дальнейшем я буду делать посты про всякие интересные штуки, идти они будут под тегом future.

понедельник, февраля 01, 2010

Visual Studio 2010 доступна для скачивания

Visual Studio 2010 Express и бета полной версии уже некоторое время доступны для скачивания. Будут работать до 30 июня 2010. Там есть некоторые фичи из С++0x.

По ссылке отсюда.

Пост "CAP-теорема Брюера"

Муж опубликовал пост про CAP-теорему Брюера. Звучит она примерно так:

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

Дальше он рассказывает, что из этого следует. Очень рекомендую.