Размышлизмы eao197

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

[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-ом воспользоваться.