Размышлизмы eao197: 11 июля 2010 г.

суббота, 17 июля 2010 г.

[prog.memories] 5-я часть пути к отладчику, с отладчиком и…

Продолжение (предшествующие части: первая, вторая, третья и четвертая).

В КБ системного программирования, где я работал до 2001 года, наша команда пыталась создать свою собственную, объектно-ориентированную SCADA-систему (подробнее эту историю я когда-то описывал в белорусской “Компьютерной Газете”). А SCADA – это реальное время, а реальное время – это вообще отдельная песня.

Изначально лично мне реальным временем заниматься не приходилось. Сперва я отвечал за хранение описаний элементов SCADA-проекта (агентов, в нашей тогдашней терминологии) и измерительной информации. Затем за векторный графический редактор. Хотя общее представление о реальном времени все-таки приобрести пришлось. Что и пригодилось, когда мы в 2000-м взялись за разработку кроссплатформенной версии своего SCADA Objectizer-а.

Хорошо, что к тому времени о том, что такое отладчик, я практически и не вспоминал. Поскольку, по моему глубокому убеждению, отладчик и реальное время – вещи совершенно несовместимые. Помню, делал я диспетчер таймерных событий. Заводится, скажем, на каждую секунду по 200 событий. А срабатывают, например, только 195 из них. Или все 200, но одномоментно. Или вообще весь таймер на очередном тике зависает. И как это дело отлаживать? Дебаггером в пошаговом режиме? Если кто-то хочет попробовать – желаю удачи :)

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

Уж не знаю, каким образом эта OS-9000 к заказчику попала, но нам она была передана в самой минимальной комплектации. Базовая версия ОС, какой-то допотопный C++ компилятор + uEmacs в качестве редактора. И пара отксерокопированных толмудов по самой ОС на английском языке (очень поверхностных и бестолковых, как оказалось). Естественно, никаких отладчиков и в помине не было.

Дальше больше. Нам потребовалось принять какое-то архитектурное решение для своей системы. А достаточной технической информации и знаний у нас не было. Поэтому поручили двум людям написать по тестовому примеру. Одному что-то под названием, кажется, trap handler (специальная процедура, запускаемая ОС при обнаружении сбоя в процессе). А второму – этим счастливчиком был я – тестовый драйвер. Под неизвестную систему с минимумом информации на руках. Пришлось написать. :)

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

Вообще, весь тот сумасшедший проект под OS-9000 удалось вытянуть именно за счет того, что у всей команды к тому времени был очень большой опыт работы с “черными ящиками” – когда не имеешь возможности увидеть то, что творится внутри.

Потом я от систем реального времени ушел очень далеко. Да и место работы сменил. Основными платформами для меня стали Windows и Linux. Не было больше экзотических средств разработки – Visual C++ под Windows и GNU C++ под Linux-ом. Тем не менее, отладчиком я все равно не пользовался.

Сначала это было, наверное, из каких-то принципиальных соображений. Вроде того, как в 1992-м я не мог обходиться без отладчика, так в 2001-2003 я не мог пользоваться отладчиком – религия не позволяла: ну как же, я же под OS-9000 реальное время без отладчика запускал, а здесь что, без отладчика не смогу, что ли? :)

Потом все-таки стало приходить понимание, что особой доблести в отрицании отладчика нет. Когда приложение стабильно падает при одних и тех же условиях, почему бы не посмотреть точное место слома в отладчике? Во многих таких случаях он помогает. Хотя и не всегда. Но, когда отладчик не помогает, ничего страшного не происходит. Просто нужно достать из своего арсенала другой инструмент, более мощный :)

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

Продолжение следует.

пятница, 16 июля 2010 г.

[prog.memories] 4-я часть пути к отладчику, с отладчиком и…

Продолжение (вот первая, вторая и третья части).

Где-то в 1995-м меня угораздило вляпаться в разработку собственной объектно-ориентированной БД. Естественно, хотелось сделать все “по взрослому” – чтобы СУБД была кроссплатформенной. Под Windows и OS/2 она затачивалась изначально. Но хотелось большего – Unix-а.

Об Unix-е в то время я имел очень смутное представление. В университете с Unix-ом нас не знакомили (у ребят, которые учились на год старше, был семестр, когда им преподавали Unix на больших машинах – или ЕС-ках, или СМ-ках, а у нас этого курса уже не было). Поэтому мое изучение Unix-а происходило в буквальном смысле “методом тыка” – поспрашивал у знакомых, есть ли у них дистрибутивы каких-нибудь Unix-ов. У одного нашелся CD с RedHat Linux 5-какой-то там. Я взял этот CD, установил с него Linux на рабочий компьютер (наверное, с десятой попытки) и начал разбираться…

Собственно, цели стать Unix-программистом у меня не было. Мне нужно было скомпилировать под Unix-ом свою СУБД и убедиться, что она работает. Поэтому и изучение Linux-а шло именно в этом направлении: сначала освоил man и info, потом g++, ну а с make я уже был знаком. Дело шло довольно быстро и вскоре мои исходники стали компилироваться, а некоторые тесты даже запускаться.

И тут встал вопрос: а как же под Linux-ом, в котором и вменяемой графической оболочки (вроде нынешних KDE и Gnome) тогда не было, отлаживать программу? Знающие люди подсказали магическое имя – GDB. Запустил я его и офигел. Конец XX-го века на дворе, а тут приходится возвращаться к временам MS-DOS 1.0, а то и раньше! :) Меня, на тот момент, убежденного виндузятника, очень сильно напрягала необходимость отлаживаться в тогдашнем GDB. Ведь даже Borland-овский Turbo Debugger времен 1989 года казался намного более совершенным и уж точно гораздо более удобным, чем GDB. В общем, плюнул я на GDB и сколько не программировал с тех пор под разными Linux-ами и прочими Unix-ами, никогда им не пользовался.

Т.о. к 1996-1997 году сложилась интересная ситуация: при работе под Windows можно было свободно пользоваться отладчиком, но особой пользы от него не было; под OS/2 у нас вообще не было отладчика, а под Linux-ом отладчик был, но работать с ним не хотелось.

А тут и следующий технологический вызов подоспел. Те, кому довелось попрограммировать в середине 90-х, наверняка помнят, какой шум был вокруг технологий “клиент-сервер”. Я даже книжицу от Novell-а какую-то приобрел, которая была посвящена разработке клиент-серверных систем (сама книжка бестолковая была, но самое ценное в ней – это примеры кода для разных операционных систем). Ну и на волне всеобщего энтузиазма по поводу клиент-сервера мне захотелось сделать из своей встраиваемой СУБД настоящую клиент-серверную. Чтобы был автономный процесс-сервер, а клиенты подключались к нему по TCP/IP. Ну а раз захотелось, то пришлось сделать.

И вот тут-то проблема отладки всего этого хозяйства – многопоточного сервера СУБД и клиентов, которые могли работать на разных машинах и под разными ОС – встала в полный рост. Например, работает на одной машине под OS/2 сервер БД, к которому подключено три разных Windows-приложения с других машин. При очередном запросе падает сервер, и тут же какой-то из клиентов. За что хвататься, как искать причины? А иногда сервер начинал глючить после обработки нескольких десятков тысяч запросов. А иногда сервер падал после того, как клиент к нему десять раз подключится, выполнит пару тысяч запросов и отключится. Отладчик и в обычной многопоточной программе бесполезен, а уж в таких ситуациях тем более.

Поэтому где-то к 1999-му году я уже полностью излечился от дебаггерной зависимости, приобретенной в годы программирования под MS-DOS. И уже в следующем году это дало очень важные результаты, поскольку довелось прикоснуться к реальному времени и операционной системе OS-9000.

Продолжение следует.

[comp] 22-дюймовый экран с MultiTouch от 3M

Компания 3M анонсировала свой 22-х дюймовый экран с поддержкой возможности MultiTouch (с отслеживанием чуть ли не 60 одновременных нажатий). Вот их красочный рекламный ролик:

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

Т.е., наверное, для каких-то специфических областей (видеомонтаж, обработка изображений, игры) это будет востребовано. Но вот в “офисных” задачах – вряд ли. Имхо, конечно.

Но смотрится прикольно.

четверг, 15 июля 2010 г.

[life] Не могу не препостить байку о поимке фарцовщиков КГБ-шниками

Лично меня порвало:

Историю эту мне поведал участник событий, старый гебист Юрий Тарасович.
30 лет назад. г. Львов.
В центре города, напротив театра Заньковецкой, есть трамвайная остановка
трех или четырех маршрутов. Хоть трамваи ходят каждые две минуты, все
равно людей собирается на остановке всегда минимум человек двести...
короче идеальная точка для фарцовщиков. Среди людей их сразу не
вычислишь, а чуть кто вспугнет, они сели в трамвай и были таковы...
менты их ловили годами, но получалось хреново... форцы вычисляли их
быстрее и сваливали.
И вот когда секретарь обкома Секретарюк, увидел на своем внуке
"вранглера", которые тот купил за 180 рэ, дед был в шоке.
позвонил в кгб, и дал команду.. - Чтоб сегодня же поймали всех!!!
Хоть это не дело гебистов, но что делать. Все же в кгб тогда дураков
почти не держали. Они приехали на место. была зима мороз. вычислять
нужно быстро, иначе фарцовщики вычислят засаду.
Не буду томить, кагэбэшники вычислили их за пол минуты и сразу взяли
всех. 10 человек из 200 стоящих на остановке...
Секрет в том, что все фарцовщики стояли на картонках... холодно однако

Рассказчик: grubas

Найдено здесь.

[prog] Scala 2.8.0 Final

Состоялся релиз Scala версии 2.8.0. С чем всю прогрессивную общественность и поздравляю (глядя на все со стороны)! :)))

Даже не знаю, должно ли меня радовать то, что я почти угадал со сроками выхода финального релиза Scala 2.8.0 или нет. Нужно будет посмотреть, сколько багов будет исправлено в Scala 2.8.1 :)

[prog.memories] 3-я часть пути к отладчику, с отладчиком и…

Продолжение (первая и вторая части).

Первый опыт программирования под Windows сумел слегка нарушить зависимость от отладчика, приобретенную за время работы под MS-DOS-ом. Хотя, в последствии, удалось перебраться на более мощные компьютеры, где можно было уже вести всю разработку прямо в Windows (тогда это была Windows 3.11). Но асинхронная природа Windows-приложений, написанных на голом WinAPI, все равно существенно снижала ценность отладчика.

Время шло, где-то в 1995-м стало понятно, что 16-ти битовый Windows 3.11 – это уже вчерашний день. Будущее было за 32-х битовыми версиями Windows. И мы начали потихоньку к этому делу готовиться. Сначала с помощью Win32s, затем с первыми публичными beta-версиями Windows 95 и, наконец, с Windows NT 3.5. В составе Borland-овских компиляторов (вроде бы, начиная с версии 3.1) был отдельный 32-х битовый отладчик TDW32. Я не помню, чтобы приходилось им часто пользоваться – вроде бы связка из Win32s и TDW32 была не очень надежной и стабильной вещью.

Стоило нам добраться до настоящего Win32 (под Windows 95 и Windows NT 3.5/3.51), как захотелось познакомиться с многопоточностью. Казалось, что это сложно :) Но я ошибался. Написать многопоточное приложение для Win32 оказалось не сложно. Сложно было его отлаживать. Режим пошаговой отладки, к которому я привык в MS-DOS, в многопоточной программе был бесполезен в принципе. Ну то есть вообще.

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

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

В 1995-1999 годах я работал в двух местах одновременно. На первом месте работы я программировал под Windows. А вот на втором месте – под OS/2. Отличная была система. По надежности, отзывчивости и ресурсоемкости давала фору всем тогдашним Windows-ам. Только вот с софтом для OS/2 было гораздо хуже. В нашем распоряжении был какой-то Borland-овский C++ный компилятор под OS/2 и Borland-овский же отладчик. Так вот, этот отладчик был единственной полуосной программой, которая умудрялась повесить OS/2. Никто это не мог сделать, а вот Borland-овский отладчик мог. Причем в совершенно случайных местах. Можно было пять раз подряд загрузить в него одну и ту же программу и протрассировать один и тот же фрагмент кода. А на шестой точно такой же операции отладчик подвешивал всю систему. Или не на шестой, а на шестнадцатой. Или на первой.

Плюс к тому, в OS/2 были свои специфические ошибки, которые сильно портили кровь, но обнаружить которые с помощью отладчика не удавалось. Например, когда в Presentation Manager создавалось фреймовое окно (с заголовком, меню и рамкой), то требовалось, чтобы в ресурсах приложения была иконка с точно таким же идентификатором ресурсов, как и меню. Забыл добавить в ресурсы иконку – окно не создавалось. Пытаешься прогнать свой код под отладчиком, видишь ошибочный код возврата от PM-ной функции, но понять, чего PM-у не хватает, не можешь.

Затем мы вообще, если не ошибаюсь, перешли с Borland-овского компилятора на Watcom-овский. В котором отладчика под OS/2 не было вовсе (по крайней мере в нашем дистрибутиве Watcom 11). Так что году в 1997-м произошел откат к методике разработки под Robotron 1715 – компилятор есть, а отладчика нет :) Хотя к тому времени это уже вообще не было проблемой. Поскольку к этому времени я уже познакомился с Linux-ом и начал работать не просто с многопоточными, а многопроцессовыми приложениями…

Продолжение следует.

среда, 14 июля 2010 г.

[life.sport.darts] Пара интересных видеороликов о технике броска в дартс

Случайно нашел на YouTube ролики с замедленным показом броска Фила Тейлора:

и Джона Парта:

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

Может себя во время броска заснять, чтобы технику подкорректировать? ;)

[prog.memories] 2-я часть пути к отладчику, с отладчиком и…

Продолжение, начало было вчера.

В конце 92-го, начале 93-го довелось приобщиться к программированию под Windows. Тогда еще к Windows 3.0 и 3.1.

Сразу же пришлось отказываться от привычного стиля работы. К тому времени я уже плотно пересел на Borland C++ 2.0 – все делал в этой IDE: и исходный текст набирал, и компилировался, и отлаживался. В Borland C++ 2.0 был включен Windows SDK, поэтому с помощью Borland C++ можно было писать программы под Windows. Чем мы и попытались воспользоваться.

В нашем распоряжении были только слабенькие 286-ые IBM AT-шки с 1Mb памяти (640Kb из которых было доступно для MS-DOS-а, а еще 384Kb т.н. расширенной памяти под DOS-ом можно было задействовать через пляски с бубном). Так вот оказалось, что если в Borland С++ под DOS-ом запустить компиляцию даже простенького Windows-приложения, то Borland сначала долго-долго компилировал исходники, а затем приступал к линковке, окончания которой мы так никогда и не дожидались. Помогало вот что: в самой начале линковки процесс построения проекта прерывался, затем запускался вновь – на этот раз сразу начиналась линковка, без компиляции. В таком случае линковка заканчивалась успешно и, что удивительно, быстро.

Понятное дело, продолжать работать в IDE Borland C++ 2.0 было нельзя. Поэтому пришлось осваивать компилятор и линкер командной строки, изучать утилиту make и редактор MultiEdit (вот тут уж точно, не было счастья, так несчастье помогло – MultiEdit на много лет стал моим рабочим редактором). Набор исходного текста программы шел в MultiEdit-е, из него же запускалась компиляция через make. Все происходило гораздо быстрее, чем в Borland C++.

Но все это делалось под DOS-ом, поскольку в самом Windows провести компиляцию не удавалось – мало памяти, жуткие тормоза. Поэтому компилировались в DOS-е, потом запускали Windows и свою программу.

Но запустить программу мало, нужно ее еще и отлаживать. Тут мы использовали автономный Borland-овский Turbo Debugger for Windows (tdw.exe). Интересная штука – запускалось оно как Windows-приложение, но сразу же переходило в текстовый режим. А при необходимости возвращала пользователя в Windows. Работало все это не быстро, экран моргал ужасно, и иногда повешивал все. Но самым страшным оказалось не это.

Страшнее всего оказался поток Windows-сообщений, с которым нужно было что-то делать. Когда мы начинали программировать под Windows, в нашем распоряжении не было каких-либо объектных библиотек вроде MFC (даже Borland-овский OWL попал в наши руки позже, вместе с Borland C++ 3.1, если не ошибаюсь). А это значит, что все у нас строилось через WndProc с большим switch-ем внутри.

Вот тут то пошаговая отладка оказалась не то, чтобы невозможной, а очень неудобной. Функцию WinMain можно было протрассировать только до начала цикла сообщений. В WndProc же отладчиком можно было попасть только установив там очку прерывания.

Но если поставить точку прерывания на входе в WndProc, чтобы затем обработку сообщения протрассировать – и тут же тебя затопчет толпа самых разнообразных сообщений WM_*, о которых ты и знать не знал. В TDW можно было фильтры для сообщений настраивать, но это было мутное дело, да и повторять его приходилось при каждом запуске отладчика. А еще и ряд действий выполняется через Callback-и – т.е. в одном месте ты что-то из Windows вызывал, а спустя какое-то время сама Windows твою функцию вызвала. Нужно помножить все это еще и на изрядную неспешность тогдашних машин и получится, что отладчик вовсе не ускорял отладку, а только усложнял ее.

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

Так начались первые шаги в сторону от отладчика. Пока еще маленькие и робкие :) Со временем довелось пересесть на более мощные машины и более современные средства разработки (Borland C++ 3.1 и Borland C++ 4.01/4.5). В каком-то из них, кажется, уже был встроенный в IDE отладчик, работающий в графическом режиме. Хотя помощь от него при программировании под Windows (из-за особенностей самого программирования через WndProc) все равно была меньше, чем от отладчика под DOS-ом.

В общем, где-то в районе 1994-95 отладчиком я все еще пользовался регулярно, хотя и в меньшем объеме, чем в 1992-1993-м. А потом мне довелось перебраться под Win32 с реальной многозадачностью, плотно попрограммировать в OS/2 и поэкспериментировать с Linux-ом…

Продолжение следует.

PS. Перечитываю свой текст и ловлю себя на мысли, что меня обязательно спросят: “А зачем нужен был весь этот мазохизм с Windows на 286-х в 1992-93?” Была у нас тогда уверенность в том, что времена MS-DOS-а и самодельных пользовательских интерфейсов и самописных драйверов для принтеров уже прошли. Будущее за Windows-программированием. И что техника не всегда у нас будет такой допотопной. Так в принципе и вышло.

вторник, 13 июля 2010 г.

[prog] Google App Invertor in Action – визуальное программирование для Android

Это демонстрация нового проекта GoogleLabs под названием App Invertor.

Лично мне цветные элементики Button.Click и Sound.Play понравились – симпатишно :)

[prog.memories] Путь к отладчику, с отладчиком и от отладчика

По следам обсуждений моих сообщений (первое и второе) на board.rt.mipt.ru захотелось растечься мыслею по древу и рассказать, почему я очень редко пользуюсь отладчиком и успешно отлаживаюсь с помощью printf-ов. Но тема это большая, а начинать ее нужно с воспоминаний о том, как я начинал программировать и в какие предметные области меня забрасывало. Поскольку битьё определяет сознание и выбор стиля разработки очень сильно определялся средой разработки. Поэтому начну с воспоминаний.

Мое приобщение к программированию началось где-то в 1988-89 годах, когда у нас в 9-м классе ввели в школьную программу предмет “Информатика”. Самое смешное то, что на тот момент ни в одной окрестной школе не было дисплейного класса. Т.е. изучая первый год информатику, мы вообще ни разу не видели компьютеров. Программировали (как бы смешно это не звучало) на бумаге на русском алгоритмическом языке.

В следующем году в одной из школ дисплейный класс таки оборудовали. Аж 10-ю или 12-ю компьютерами БК-1001, объединенных в сеть под управлением ДВК. И раз в неделю наш класс ездил в ту школу, чтобы потратить 45 минут на “теоритическое” занятие и 45 минут на работу на компьютерах. Такое разделение было необходимо, чтобы разбить класс из 25 человек на две группы – пока одна группа сидит в дисплейном классе, вторая занимается “теорией”, потом группы меняются.

На БК-1001 было, если не ошибаюсь, 16K памяти и зашитый в ПЗУ Basic. Никакого отладчика, понятное дело, не было. Если программа почему-то не работала, то она не работала и увидеть, что происходило у нее внутрях, нам не представлялось возможным. Так что самые первые навыки отладки программ без отладчика стали формироваться еще в школе, когда я даже не успел еще в полной мере заразиться программизмом.

В университете получилось интересно – на нашем математическом факультете было две кафедры, занимающихся программированием: МПУ (математические проблемы управления) и ВМП (вычислительная математика и программирование) и студентами специальности 22.04 “ПО ВТ и АС” занимались именно они. Кафедра МПУ считалась более “программистской” и я хотел попасть туда. Но как-то получилось, что меня приписали к кафедре ВМП. Что было не очень радостно, поскольку МПУ-шникам давали машинное время в университетском ВЦ на IBM-совместимых компьютерах (на десятке кое как работавших Искр и нескольких IBM XT и IBM AT). А нам, ВМП-шникам предстояло первый семестр работать на Robotron 1715. И это, я считаю, оказалось судьбоносным событием.

Во-первых, на Robotron-ы, в отличии от Искр и IBM-ок, никто не претендовал. В начале и середине семестра дисплейный класс Robotron-ов всегда был полупустым. Чем мы и пользовались, просиживая в нем иногда целые дни на пролет (забивая на остальную учебу). Именно тогда я подсел на программизм как наркот на иглу :)

Во-вторых, на Robotron-е было всего 64K памяти и два 5” дисковода. Средой разработки у нас был слегка допиленный преподавателями Turbo Pascal 3.0. Хотя средой назвать это было сложно. Был редактор и была возможность запустить компиляцию. По-моему, даже место синтаксической ошибки редактор не показывал. Нужно было самому бегать по тексту и искать нужную строчку.

Отладчика, естественно, так же не было. Более того, работающую программу нельзя было прервать по Ctrl+C. Если программа зависла – значит зависла, нужно было перегружать компьютер. Поэтому мы с самого начала были приучены к тому, что в программе должны быть встроены какие-то меры воздействия на нее – опрос клавиатуры, например. Если программа обнаруживает нажатие клавиши, то она либо завершает свою работу, либо приостанавливается.

Это в корне отличалось от того, что я видел в параллельной группе, работавшей на Искрах. Помню с каким недоумением я смотрел на своих однокурсников, которые все поголовно двигали какие-то цветные полоски по экрану нажимая F8/F9. Попросив одного из них рассказать, что они делают, я был шокирован той дисциплиной разработки. Парнишка написал кусок программки и сразу же запустил ее со словами “Сейчас посмотрим, работает ли она!” – для меня это было дико. Программа, естественно, не заработала, а подвисла. Его это совершенно не растроило, он сразу же нажал Ctrl+C и вылетел в отладчик. Посмотрел значения переменных, прошелся пошагово по нескольким местам и исправил ошибку. Для меня это стало если не шоком, то откровением.

Однако, когда во втором семестре мы пересели с Robotron-ов на IBM-ки, старые привычки у нас еще остались. Поэтому поначалу я отладчиком пользовался не часто. И заметил вот какую штуку – чем больше обдумываешь проблему, тем меньше времени тратишь на ее решение за компьютером. В том числе на и отладку.

Но, поскольку в конце первого курса до благ цивилизации в виде Turbo Pascal 5.0 и Turbo C 2.0 (а впоследствии и Turbo C++, Borland C++) мы уже дорвались, то замечательный борландовский Turbo Debugger плотно укоренился в наше сознание и способ программирования. Если раньше для меня было диким входить в отладчик ни разу не прогнав программу, то впоследствии я пришел к тому, что даже первый запуск программы я делал сразу в пошаговом режиме отладчика. Так что на отладчике мы в свое время сидели очень плотно.

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

А еще мы пробовали делать какую-то графику. Тяжело было отлаживаться Debugger-ом в этом случае. При переключении из исходника на вывод программы экран жутко моргал. Да и, помнится, не во всех графических режимах Debugger мог корректно сохранять нарисованную программой картинку. Еще, помню, были попытки писать свои резидентные программы под MS-DOS. Там тоже были какие-то сложности в использовании Debugger-а. Так что волей-неволей приходилось сталкиваться со случаями бессилия и бесполезности отладчиков. Что дико ломало, но и заставляло выкручиваться, вспоминая уроки БК-шек и Robotron-ов.

А потом, в конце 92-го и начале 93-го мне довелось столкнуться с MS Windows…

Что-то я уже много написал, а еще рассказывать и рассказывать. Так что продолжу я в следующий раз.

[work.wow] Ох*енная оценка успешности чужого проекта

Не могу не утащить к себе на память (выделение жирным мое):

The Elder Scroll — целый сериал от Bethesda Softworks. Многие наверное сейчас играют в ихний Fallout 3, но он провальный по большому счёту! Хотя компания получает не хилые прибыли от него!

PS. О вменяемости персонажа, написавшего такое можно судить вот по этому “откровению”.

понедельник, 12 июля 2010 г.

[life.sport.darts] Работа встала: прибыла очередная посылка из Англии

Недели три назад решил поменять себе дротики. Стал замечать, что если я пытаюсь бросать как бы “навесиком”, то точность попаданий увеличивается. Но вот форма моих Gripper-ов, на мой взгляд, не очень удобна для таких бросков – длинный прямой цилиндр оказывается слишком чувствительным к различного рода огрехам при броске.

Поэтому захотелось попробовать дротик каплеобразной формы. Выбрал себе очень недорогой вариант – 85% Nodor NR-1206 весом 26 грамм

+ еще кучу всякого расходного материала.

Сегодня посылка пришла (очень быстро, всего 2 недели). Так что работа приостановилась :)

(я специально разместил рядом свои “старые” Unicorn Gripper I 25g и новые Nodor NR-1206 26g, чтобы была видна разница)

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

Так что будем тренироваться. Если дело пойдет, то можно будет приобрести что-нибудь подороже, попопсовее и полегче (все-таки, боюсь, 26 грамм – это занадто). Вроде такого:

или такого:

Коллега приобрел себе очень неплохие недорогие дротики с 90% содержанием вольфрама:

Всего за 8 фунтов. Я попробовал – не хуже моих Gripper-ов, даже держать удобнее. Так что если кто-то ищет себе недорогой вариант, имеет смысл обратить внимание.

Кстати, сделал для себя вывод – алюминиевые хвостовики – не есть хорошо. Да, они не ломаются так быстро, как пластмассовые. Зато они могут гнуться. Изогнется такой при выпадении/отскоке и все, дротик уже не будет лететь так, как надо. И не всегда сразу обращаешь внимания на изогнутость хвостовика. Пластиковые же не гнутся, просто сразу ломаются и все. Так что пока буду пользоваться именно пластиковыми хвостовиками.

PS. И еще раз скажу свое “фи” продавцам дартса на просторах СНГ. Продавать латунные дротики Harrows Voodoo (ценой ~7 фунтов с VAT) в Гомеле за 90000BYR (~20 фунтов)… Или Nodor NR-1800 (ценой в ~26 фунтов без VAT) в России за 3990RUR (~85 фунтов)… Бизнесмены хреновы!

[work] Мой софтосписок

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

Основная рабочая среда у меня – Windows. Поскольку работаю я на ноутбуках, а ставить Linux на ноутбуки я зарекся еще лет пять назад. Проекты под Unix-ы я портирую либо в виртуалках, либо на тестовых серверах, на которых, по моему мнению, Linux-у как раз самое место (в отличие от Windows). Посему все используемые мной приложения виндусовые, либо портированные под Windows.

Итак, вот что мне необходимо на моем рабочем (ну и не только рабочем) ноутбуке:

7-Zip	Потихоньку становится основным архиватором.
Adobe Reader	Ну тут понятно, куда же без хорошей читалки PDF-ов.
Auslogics Task Manager	Хороший Task Manager, показывает в том числе и кто столько трафика поглощает.
Bitwise Tunnelier	Как альтернатива putty.
CPUMon	Отличный индикатор загруженности процессора и расхода памяти.
Chrome	Альтернативный браузер.
Cygwin	Без ряда Unix-овых утилит просто невозможно работать. А cygwin – это очень удобный способ их получать и поддерживать в актуальном состоянии.
Far	Без него как без рук.
Gizmo	Для монтирования ISO-шек в файловую систему.
ImgBurn	Писалка для дисков.
InfanView	Для мелкой обработки фотографий.
Java SDK	Временами приходится использовать ;)
Lingvo	Без словаря нельзя. Я использую очень старую, 8-ю версию, поскольку очень стабильно работает и проблем никаких нет.
MS Office	Приходится держать, поскольку очень многие признают только .DOC, .XLS. .PPT и .VSD файлы.
MS Visual Studio 2003	До недавнего времени основной C++ инструмент для Windows-проектов.
MS Visual Studio 2008	Постепенно переходим с 2003-ей на 2008-ю студию.
MSDN	Без документации никуда.
MikTeX	Основной инструмент для написания внутренней документации.
Mozilla Sunbird	Пытаюсь вести учет делам, запланированным событиям и пр.
NOD32	Антивирус, корпоративный выбор.
Opera	Основной браузер + мой постоянный почтовый клиент (за 9-ть лет использования в нем накопилось несколько десятков тысяч писем).
Perl	Для конфигурирования некоторых проектов, например, OpenSSL.
Psi	Клиент для корпоративного Jabber-а.
Python	В основном для docutils и построенного на нем rest2web.
RAdmin Viewer	Для доступа к удаленным серверам по Windows.
RapidSVN	Для просмотра Svn-овских репозиториев.
Ruby	Второй основной язык программирования :)
SMPlayer	Альтернативный медиапроигрыватель.
SUPER	Мощный преобразователь аудио-видео-форматов.
Skype	Для общения :)
Subversion	Корпоративный (да и личный) CVS.
The KMPlayer	Основной медиапроигрыватель (в том числе и аудиоплейер).
ViM 7	Основной редактор.
Virtual Box	Виртуалка для Linux-ов.
WinDjView	Читалка книг в формате DjVu.
WinRar	Ранее был основным архиватором.
Windows Live Writter	Писалка для блога.
Wireshark	Основной инструмент вправления мозгов техническим спецам крупных контор :) Ну и вообще незаменимая в некоторых вещах штука.
XnView	Просмотр и простейшие манипуляции с фотографиями.

Это все, что нужно инсталлировать. Еще есть куча каких-то мелких утилит, путь к которым у меня автоматом прописывается в PATH или которые вообще используются от случая к случаю. Например, putty и doxygen лежат в общем скопище разных полезных утилит. А VirtualDub живет в своем подкаталоге, куда я захожу вручную, если мне приходится VirtualDub-ом воспользоваться.