О важности выполнения плана проекта

План программного проекта - это:

• чертовски
  
• важная
  
• штука.
  

Говоря об этом, я имею в виду следующее. Если план проекта изначально не составляется, и разработка ведется исключительно на основе некоторого видения (зафиксированного документально или устно), а также оперативных (текущих) рассуждений/собраний, то на самом деле к менеджменту не может быть никаких претензий, поскольку его нет. Ведь нельзя преъявлять претензии к тому, чего в действительности не существует? По-моему, так.

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

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

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

Подведем итоги:
1. Добейся утверждения заказчиком своего плана
(Если ты не можешь этого сделать, то ты нихера не стоишь как менеджер)
2. Умей отстоять утвержденный план.
(Если ты не можешь этого сделать, то ты нихера не стоишь как менеджер)
3. Добейся от команды выполнения плана.
(Если ты не можешь этого сделать, то ты нихера не стоишь как менеджер)
4. Если ты, менеджер проекта, не выполняешь свой план, то лучше убей себя сам.

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

О вреде табуляции в середине строки

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

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

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

int    n;
double d;

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

Так вот, неужели кому-то действительно трудно понять, что это - полная хуйня не лучший способ написания кода?! Давайте разберем этот пример подробнее. Пусть размер табуляции - 4 символа, позиции табов обозначим точками. Итак:

.   .   .
int     n;
double  d;

Очевидно, что для того, чтобы выровнять этот код, кодеру пришлось после слова "int" нажать кнопочку Tab два раза, а после слова "double" - один. Недоумок!

Что теперь произойдет, если на этот код посмотрит другой кодер, у которого размер табуляции - 2 позиции (ну, например, из-за низкого разрешения монитора)? А вот что:

. . . . .
int   n;
double  d;

Код "пополз". Ну, теперь всем понятно, в чем дело?!!!! При разных размерах табуляции код, отформатированный с помощью табов в середине строки, ползет и становится очень плохо читаемым.

А как надо было сделать? Смотрим сюда:

int     n;
double  d;

В чем разница? В том, что здесь после слова int кодер не два раза нажал на таб, а пять раз нажал на пробел. А после слова double он нажал на пробел два раза. Такой код будет выглядеть одинаково при любой установленной ширине табуляции.

Вывод - НЕЛЬЗЯ нажимать кнопку Tab в середине строки. Однако, можно и НУЖНО нажимать кнопку Tab в начале строки, о чем речь пойдет дальше.

UPD 25.06.06: А лично я всегда пишу так:

int n;
double d;

Да-да, выравнивать середины строк - идея от лукавого. Ну, скажем, возникнет необходимость поменять тип переменной d с double на float..

От лукавого, говорю :)

UPD 5.07.06: Да, все вышеказанное верно лишь для моноширинных шрифтов. Если кодер грезит об использовании пропорциональных шрифтов, то ему будет полезно ознакомиться с вот этой методикой.

Свет

В прошлом посте речь шла о материалах и их свойствах – ambient, diffuse и specular. Как оказалось, теми же самыми свойствами обладает и свет. Этот факт сводится к тому, что у света также имеется три составляющих. Diffuse-цвет света, взаимодействуя с diffuse-цветом материала, определяет свойства рассеивания света по данному материалу. Specular-цвет света, взаимодействуя со specular-цветом материала, определяет вид блика, или светового пятна. Есть еще ambient-цвет света – но это отдельная песня, в которой поется об общем цвете сцены. Например, закат часто красит все вокруг в багровые тона – это потому, что у закатного солнца багровый ambient.

Нет, на самом деле все, конечно же, обстоит не так, и я сторонник того, что Господь не придумал факультетов. Багровый ambient – это всего лишь жалкая попытка нас, нервически дергающих ножкой, смоделировать закат на экранах наших мониторов. Так будет правильней.

Говоря о том, что что-то там с чем-то взаимодействует, я имею в виду вот что. Разные материалы при освещении одним и тем же светом ведут себя совершенно по-разному. Например, светлая сосна, если светить на нее, будет освещаться в целом равномерно, а, скажем, темный орех будет иметь характерное круглое световое пятно. Это говорит о том, что материалы по-разному реагируют на свет. Можно рассматривать аддитивную модель взаимодействия, когда, например, diffuse-цвет света складывается с diffuse-цветом материала, что дает результирующий цвет в освещенной точке. Из имеющих названия бывает еще модулятивная модель. А вообще говоря, модель взаимодействия компонент материала с компонентами света называется blending, и их бывает много разных типов.

В нашем проекте мы, разумеется, не обращаемся напрямую к OpenGL API, а используем opensource-3D-движок OGRE (http://www.ogre3d.org/). Когда он рендерит сцену, внутри него происходит деление материала на т.н. illumination passes. Грубо говоря, ему удобней просчитывать освещенность в несколько проходов: в первом (ambient pass) считаются ambient-компоненты материалов, полученные в результате освещения источниками света, находящимися в сцене; во втором (per-light pass) – diffuse и specular-компоненты; в третьем проходе (decal pass) обрабатываются текстуры. Кстати, это верно только для непрозрачных материалов; всякие там стекла на проходы не делятся, да и рендерятся они совсем по-другому, поскольку необходимо рисовать на экране также то, что находится за ними.

Напоследок – несколько картинок:

Сцена после ambient-прохода

Сцена после всех проходов

Сцена после всех проходов + наложение теней

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

О свойствах материалов

Почти всю свою жизнь я считал, что свойства материалов в окружающем нас мире сводятся к паре «цвет/текстура». И в самом деле – казалось мне – если, например, стену покрасить краской, то она приобретет определенный цвет; если же ее оклеить рельефными обоями, то она станет обладать некоторой текстурой. Работая над проектом codename Sweet Home в BeLight Software, мне пришлось познакомиться с представлением материалов в OpenGL, которое, как оказалось, разительно отличается от моего [убогого] представления.

Так вот, первым свойством материала является т.н. ambient color. Ambient – это, попросту говоря, цвет материала, который мы наблюдаем в отсутствие текстуры и [выраженного] освещения – например, в пасмурный день. Вторым свойством назовем diffuse color – этот параметр определяет то, как свет рассеивается по объекту с рассматриваемым материалом. Кроме ambient и diffuse есть еще такой specular color – мы можем наблюдать его, когда свет светит так ярко, что дает блик на поверхности, а specular color как раз и есть цвет этого блика

Совсем непонятно, ага? У меня пример есть, вот он:



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

А что мы скажем теперь? Specular-цвет у материала, примененного к шарику, желтый – это видно на блике. Когда блик заканчивается, начинается власть diffuse-цвета. Как это легко видно, здесь он красный, что и придает красноту всей освещенной поверхности шарика. В тени шарик черный как жопа у негра что-то очень-очень черное – это потому, что у этого материала ambient-цвет такой… ну, вы поняли ;).

Что, еще не все? Ах, на рисунке еще какой-то self illumination есть? И тоже черный? А каким же ему быть, если self illumination, или emissive – это цвет самосвечения объекта. Ну, например фосфор в часах светится ночью зелененьким, потому что у него self illumination зеленый. А shininess, раз уж на то пошло, – это степень четкости блика. Чем shininess больше, тем блик меньше и границы его четче (характерно для металлов). А чем он же меньше, тем блик размазанней (характерно для матовых поверхностей).

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

С шариком вроде все. В следующий раз остановимся на лампочке.