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

Моделировать пришлось связанные колебания маятников. Первый вариант программы я наскоро набросал на Delphi — для университетской конференции этого хватило. А затем была подготовка к такому же мероприятию, но уже между университетами. Поскольку времени хватало, я взялся переписать программу на FASM, заодно сохранив совместимость программы с Windows 95/98. Через несколько месяцев получилась вполне приличная 3D-модель с управлением параметрами системы, скоростью и направлением течения времени, возможностью подключать модели других физических процессов и прочими вкусняшками.

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

А полгода спустя ранним утром я, как обычно, шёл на первую пару. Мысли огромным роем носились в голове, сменяя одна другую. И вдруг я понял, в чём заключалась моя ошибка. Дождаться вечера, чтобы проверить догадку, было нелегко.

Поскольку в основном программа работала с вещественными числами, регистров общего назначения хватало с запасом. Чтобы подсократить размер экзешника, в самом начале программы я обнулял регистр EBX и использовал его везде, где это возможно, вместо константы 0. Всё тот же STDCALL этого не запрещает: вызываемые функции значение этого регистра сохраняют, так что оказалось действительно удобно. Есть только одна проблема: внутри себя функции WinAPI этот регистр активно используют, а соглашение вызова не обязывает их восстанавливать его значение перед вызовом callback-функций.

Моя ошибка оказалась в том, что в оконной процедуре (а с точки зрения User32.dll она как раз и есть callback) я забыл прописать явное обнуление EBX. На тех компьютерах, где программа работала корректно, мне просто везло: значение регистра оставалось нулевым. На остальных же системах там оказывалось ненулевое значение, которое успешно использовалось вместо всех нулей во многих процедурах программы. Одна строчка кода, два байта в экзешнике — полгода спустя они обрели своё место в коде, но было уже поздно.

Обнуляйте переменные и регистры — и будет вам счастье!

Занимаюсь проверкой кода для игры. Не выспался, ибо много работал.

Еду на работу в авто. Пробка. Мимо проезжает какой-то огромный дядька на огромном мотоцикле. Первая мысль: «Какой-то придурок масштаб неверно выставил».

Большинство людей, когда им нечего делать, находят себе какие-нибудь развлечения: кино посмотреть, музыку послушать или в игры там поиграть. У меня же, как у программиста, свои «игры» и «развлечения»: эмулятор DOS на КПК и мечта детства написать гибридную программу, которая бы одинаково работала и под DOS, и под Windows. Писал я её на ассемблере, долго и по чуть-чуть. Но вот настал момент, когда программа была почти готова, и осталось только написать простенький мини-драйвер под Windows, который будет перенаправлять вывод программы в окно.

Ну, скомпилил модуль. Запустил — программа падает с фатальной ошибкой. Ничего страшного, я к этому уже привык. При написании программ на асме иначе просто не бывает. Ошибка в одном бите — и программа уже фатально падает. Но именно этот стиль написания программ, привитый с детства, когда ты видишь программу насквозь и чисто интуитивно чувствуешь, где кроются ошибки, очень помогает в моём ремесле.

Загружаю старый добрый TD32. И тут происходит это… Знаете, как выглядит самый страшный ночной кошмар любого программиста? Самый страшный кошмар программиста — это когда прога падает при простом запуске, но при попытке отладить её ошибка мистическим образом испаряется! При запуске под отладчиком программа преспокойно работает. Я начинаю судорожно анализировать ситуацию: что такого я мог накосячить, что прога отказывается работать под «голой» виндой?

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

Оказывается, перед тем как приступить к написанию модуля, я на всякий пожарный решил перечитать статьи по некоторым функциям API, причём не где-то на левых сайтах, а непосредственно в MSDN. Там я обнаружил весьма интересную информацию: оказывается, функция регистрации класса окна возвращает идентификатор этого самого класса, так называемый атом, который можно использовать вместо имени класса при создании окна. Конечно, как ярый фанат оптимизации (не зря же на асме пишу), я именно так и сделал. Зачем заставлять ОС делать лишние телодвижения? Ведь она же всё равно этот самый идентификатор будет искать по имени. Я это сделал и преспокойно забыл.

Вернул идентификацию класса окна по имени — всё заработало. Тут всё встало на свои места. Оказывается, никакой магии в том, что ошибка мистически пропадала в отладчике, нет. Эти самые атомы работают только под Win95/98.

А весь фокус с исчезновением в том, что древний TD32 работал в режиме совместимости с Win95. Но ни в одной справке про это нет ни единой строчки! Даже в официальном MSDN. Там прям так и написано: можете использовать либо имя, либо идентификатор.

Вот мне и вам урок на будущее: меньше доверяйте документации Микрософта и не изобретайте велосипеды. Пишите так, как пишут все, и будет вам счастье.

Сегодня увидел в тексте коллеги строчку:

void Try { …

Отличная иллюстрация выражения «бесплодная попытка».

Писал я скрипты для SMS-рассылки (курсы валют, погода и т. п.). Так вот, в процессе тестирования вбил свой номер, чтобы видеть, что и как приходит. Дописываю, с радостным видом запускаю на рассылку и начинаю тихонько офигевать.

При более подробном просмотре кода оказалось, что я просто не там поставил скобочку. На мобильник ушло порядка 600 SMS. После удаления первой полусотни я понял, что так дело не пойдёт. Пришлось звонить оператору и объяснять техсаппорту, что, где, с каких серверов и каким образом почистить очередь.

Недавно прочёл в книге по психиатрии:

Зацикленность мышления является результатом тяжёлого расстройства психики.

Одним из признаков прогрессирующей шизофрении является расстройство логики, выраженное в определении значения слов, используя эти же слова. Например: «Шкаф — это деревянный предмет, представляющий собой специальный шкаф».

Вроде всё правильно. Но вот только оба пункта очень напомнили мне обычный цикл и рекурсию в программировании. Поневоле задумаешься — а не психи ли поднимали компьютерную индустрию?

Я уже давно выяснил, что программисты и прочие IT-специалисты делятся на две категории: одни работают на кофе, другие — на пиве. Неправильная заправка программиста приводит к полной потере работоспособности. Если заправить «кофейного» программиста пивом, он сразу перестанет соображать. Если заправить «пивного» программиста кофе, он тут же уснет.

Я отношусь к пивным программистам. Если у меня впереди бессонная ночь написания кода, надо купить две-три бутылки пива. Тут главное — быть аккуратным и знать дозировку, так как при превышении необходимой нормы программирование будет послано лесом, а бренное тело — в магазин за добавкой. Но растянутые на всю ночь три бутылки пива творят чудеса. Код пишется намного быстрее и лучше. В итоге я экономлю два-три часа времени, чтобы хотя бы чуть-чуть поспать.

Позже я узнал, что у этого явления есть название — «пик Балмера». Ещё позже я узнал, что «пик Балмера» — это миф. Но мне это не мешает им пользоваться, как и многим другим.

Не надо спорить о национальных напитках айтишников. Это всего лишь топливо, как дизель или бензин.

Давным-давно, в далёком восьмом классе, желая писать игры, я пошёл на курсы программирования.

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

И я вдруг понял, что прошли мои лучшие годы. Счастливое, беззаботное детство, когда все ошибки были времени компиляции.

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

Весь код в две строчки с кучей логических операций. Комментарий: «Оно правда работает, не надо так на меня смотреть».

Цитата из файла items.xml игры Jagged Alliance 2:

0

Nada

Nothing

JA 2 programmers are the best there are... oh.. well maybe not since this message should never come up...