18 декабря 2007 г.

MDA: ловушка для разработчиков

Основной смысл MDA (Model Driven Architecture) заключается в том, чтобы вся разработка программного обеспечения выполнялась на уровне модели. То есть, грубо говоря, разработчик вносит все изменения в продукт посредством рисования квадратиков, стрелочек и прочих графических элементов. А дальнейшее преобразование из схемы в конкретную реализацию для конкретной платформы должно выполняться некими автоматизированными инструментами практически без вмешательства человека.

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

Частично эта проблема решается путем спекуляции терминами типа "самодокументирующийся код", хотя на самом деле, самодокументирующийся код — это миф. Однако, я признаю, что с помощью жесткого(!) контроля над соблюдением стандартов кодирования, возможно попытаться свести к минимуму проблемы документирования изменений.

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

Теперь вернемся к MDA. Как правило, для моделирования структуры и поведения ПО обычно используется язык UML или подобные ему. На текущий момент существует довольно много инструментов, которые позволяют сгенерировать из UML-модели некий код на каком-нибудь языке программирования. И уже довольно много команд используют эти инструменты для разработки своего ПО. Это, конечно, еще ненастоящий MDA, но суть не в этом.

Суть в том, что при использовании UML-моделей проблема отсутствия документирования изменений никуда не уходит. Но в отличие от текстовых файлов, сравнение двух UML-моделей превращается в нетривиальную задачу.

Да, некоторые UML-инструменты позволяют выполнять сравнение моделей и представлять результат в каком-то читаемом виде. Однако, каждый производитель пытается сделать это своим неповторимым способом, и на сегодняшний день работоспособность, мягко говоря, оставляет желать лучшего. И что, на мой взгляд, более важно, совместимость UML-инструментов различных производителей практически равна нулю. Даже стандарт XMI каждый производитель умудряется трактовать по-своему, хотя сама цель существования стандарта — облегчить импорт/экпорт UML-моделей между инструментами различных производителей.

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

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

29 ноября 2007 г.

Двойная загрузка grub

После установки Linux с загрузчиком grub захотелось сделать возможность двойной загрузки — Linux и Windows XP с разных физических дисков (hd0 и hd1, соответственно). В доках по установке Ubuntu и Gentoo был обнаружен пример текста grub.conf для загрузки Windows с одного из логических разделов:

title=Windows XP
rootnoverify (hd0,5)
makeactive
chainloader +1

Попытки прикрутить к grub такой вариант успехом не увенчались. Как выяснилось, причина в том, что операционные системы находятся на разных физических дисках. Для того, чтобы все работало корректно нужно добавить вызовы map в код загрузки:

title=Windows XP
rootnoverify (hd1,0)
makeactive
map (hd0,0) (hd1,0)
map (hd1,0) (hd0,0)
chainloader +1

Теперь все работает правильно :) Кстати, в процессе также обнаружил, что в Ubuntu 7, в отличие от Gentoo, можно вызывать root (hd1,0) вместо rootnoverify (hd1,0).

3 ноября 2007 г.

Клиент довольный, оптимизатор — богатый…

Просто не могу не дать ссылку :) С удовольствием бы разместил статью здесь полностью, но автор-то не я... Читал, много смеялся, долго думал.

Клиент. Разнообразие видов.
Для начала: по степени «образованности» в нашем деле:

1. Слышавший – этот, сука, прикольный. Он непременно хочет Тиц, позиции в любимой им Нигме и гарантии от черных методов, причем говорит о последних с придыханием и понижающей интонацией. Два часа презентации на тему поискового маркетинга и 15 испорченных листов флипчарта приводят его в полуобморочное состояние, очнувшись от которого, он переходит в третью группу. Никакой благодарности к просветителю при этом не испытывает и редко возвращается к нему в качестве клиента, мучаясь от стыда из-за собственной дремучести.
...

Читать статью полностью

30 октября 2007 г.

FarManager теперь будет Open Source

Ну, все, о чем мечтаешь и надеешься, рано или поздно сбывается :) Вот, и Far, после стольких лет использования под лицензией xUSSR, теперь стал свободным ПО — повод для маньяков-программистов полазить по исходному коду, а для Far'а — довольно реальный шанс стать более качественным (и современным) продуктом. Судя по комментариям на форуме, желающих поучаствовать довольно много :)

ЗЫ. Интересно, сколько их будет через пару-тройку месяцев? ;)

27 октября 2007 г.

Восхитительное чтиво

Сегодня ковырялся в Сети в поисках наилучшего перевода на русский язык сказки "Алиса в Стране Чудес". И совершенно случайно наткнулся на незнакомый мне доселе текст "Восемь или девять мудрых слов о том, как писать письма". О, какое удовольствие я получил от прочтения этой небольшой, но очень интересной статьи!.. :)

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

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

Я советую всем, кто еще не знаком с этим текстом, обязательно прочитать. Хотя бы как художественное произведение :)

24 октября 2007 г.

Искусство интервью от gamedeff

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

Читать статью на blog.gamedeff.com

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

23 октября 2007 г.

Команды bg, fg и jobs

До недавнего времени, если приходилось работать в unix или linux и редактировать несколько текстовых файлов, я открывал несколько gvim или открывал несколько терминалов и редактировал в каждом по одному файлу. Мне также приходилось использовать несколько терминалов, например, чтобы выполнять редактирование и сборку программы.

Но, как говорится, век живи, век учись. Так уж получилось, что последнее время пришлось много работать по ssh на удаленных серверах. А там и редактирование, и сборка, и запуск... В общем, несколько терминалов с ssh открыть, конечно, можно, да только слишком уж неудобно. Пришлось читать букварь :)

21 октября 2007 г.

Райкконен рулезз!

За многие столетия люди так и не решили, что же хуже — переезд, пожар или нашествие татаро-монголов. Мне самому принимать решение по этому вопросу как-то совсем не хочется :), но за последние полгода переезжать пришлось аж два раза... Врагу не пожелаешь. Но, к счастью, уже все позади, а уходящая неделя еще и пестрела радостными (для некоторых) спортивными событиями...

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

На самом деле тактика (или стратегия?) ферров была предсказуема, хотя и была на грани дисквалификации за командную игру — на старте они дружно взяли Хэма в коробочку и не дали ему вырваться вперед... А как выходил Кими из последнего питстопа? Это просто песня. Ну кто же, ну кто же, гадали комментаторы, окажется на трассе впереди — Кими или Масса? Кими или Масса?.. "И все-таки Кими, ну надо же!! " А ведь Массе было достаточно просто слегка снять ногу с педали газа и пропустить вперед своего соратника по команде, претендента на чемпионский титул... Ну да ладно.

А вот то, что происходило с Хамильтоном, действительно было чем-то невероятным. Множество ошибок и какие-то странные проблемы с машиной, из-за которых он откатился на самое последнее место... Просто какое-то чудо! Наверное, слишком много людей не хотели, чтобы он стал чемпионом. Я, например, радовался бы даже победе Алонсо ;)

Но все хорошее рано или поздно заканчивается. Но лишь за тем, чтобы через какое-то время начаться снова. Сезон закончен. Жду следующей весны :)

16 октября 2007 г.

QtAda: поддержка Mac OS + скриншоты

Теперь библиотека QtAda поддерживает Mac OS X помимо MS Windows и Linux.

Кроме этого, появились первые скриншоты. Вот, например, один из них:


P.S. Плохо, что сайт библиотеки в сыром состоянии. К сожалению, ссылка download с сайта работает неправильно. Поэтому скачать последнюю версию библиотеки QtAda всегда можно с http://sourceforge.net/project/showfiles.php?group_id=193547.

10 октября 2007 г.

О пользе тренингов

Некоторое время назад мне казалось, что различные IT-семинары — пустая трата времени для опытного разработчика. Я имею в виду не конфереции, где народ общается между собой, а именно профильные семинары, где читают лекции по конкретной узкоспециализированной тематике. Мне казалось, что такую информацию можно получить самостоятельно, главное — уметь читать документацию, умные книжки... Ну, и форумы, конечно. Куда ж без них? :)

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

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

Я забыл о своей досаде минут через десять после начала семинара. Странно, лектор рассказывал уже давно известный мне материал, но выбирал при этом такие яркие и понятные примеры, что некоторые возможности UML вставали передо мной в новом свете.

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

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

Также я открыл для себя еще неизведанную мной область под названием OCL (Object Constraint Language). Раньше использовал этот язык только для описания простеньких условий и ограничений в UML-модели. Как оказалось, OCL имеет в своем арсенале довольно удобные средства, которые позволяют не изобретать велосипеды при построении модели предметной области.

Например, в OCL существуют предопределенные свойства для ассоциаций — xor и ordered. Свойство {xor}, соединенное с двумя (и более) ассоциациями, указывает на то, что в любой момент времени жизни модели существует только одна из указанных ассоциаций. А {ordered} позволяет указать для ассоциаций один-ко-многим, что множественность объектов является упорядоченной.

Я привел в качестве примера эти свойства потому, что именно их наша маленькая команда пыталась в свое время "изобрести", несмотря на прочитанную спецификацию UML 2.0. А ведь достаточно бы было пары простых семинаров "Introduction to UML", чтобы в наших головах все стало на свои места.

В общем, я теперь думаю, тренинги по специальности нужно проходить регулярно. Как по новым темам, так и по уже давно знакомым — это полезно :)

9 октября 2007 г.

"Маразм крепчал"

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

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

Или, например, приходит ко мне друг. Я ему: "Смотри, какой я диск сегодня добыл! Послушай, какая музыка, какие пассажи! Ты только послушай!..." Друг завтра расскажет на работе, что слышал у меня классный диск... Через некоторое время мне придет повестка в суд, что я устраиваю публичные прослушивания, и что это нарушает закон об авторском праве... Бррррр! Абсурд.

Лично я — "за" соблюдение авторских прав. Но, похоже, что кто-то совсем не знает меры.

29 сентября 2007 г.

Самые злодеистые злодеи

Упоминание в статье Джеймса Баха компьютера HAL 9000 — полноправного персонажа "Космической Одиссеи 2001" — сподвигло меня на небольшой экскурс по Википедии, который в конце концов привел меня к списку самых-самых "хороших" и "плохих" персонажей в американском кино. Так сказать, TOP 50 для тех и других. Список, правда, 2003 года, но я на него набрел только сейчас.

Список "хороших", в общем-то, ничего особенного из себя не представляет. Разве что стоит отметить номер 39 — собака Лесси. В принципе, вполне положительный персонаж, тут ничего не возразишь :) Да, еще у меня вызвало недоумение отсутствие персонажей, которых играл г-н Б. Уиллис — он столько раз в фильмах спасал Америку мир, но не удостоился даже последнего 50-го места... Неблагодарные! :)

А вот список самых злодеев меня изрядно повеселил :) Ну, Фредди Крюгер, Джокер и Дарт Вейдер — эти, конечно, вполне полноправные члены списка злодеев. Человек (просто Человек) из фильма "Бэмби" — тоже злой. Но, правда, непонятно, почему только из "Бэмби" — имхо, тогда во всех фильмах о животных человек — резко отрицательный персонаж :) Также есть марсиане из "Войны миров" (конечно, очень злые, людей жрут :) ), Чужой из фильма "Чужой" (еще бы, урод еще тот!), уже упомянутый компьютер HAL и даже... Акула из фильма "Челюсти"! 8-() Имхо, вырисовывается отличная картинка фобий :) Прям, бери список и бегом к психоаналитику :)

Отдельно нужно сказать о Терминаторе. Он, конечно, злодей по-любому — все-таки машина-убийца. Но вся загвоздка в том, что его играл любимый всеми Щварцнеггер, который к тому же в этом же 2003 году стал губернатором. Поэтому его включили в оба списка :)

Чего я, наверное, никогда не пойму, так это критерии оценок злодеев. Почему, например, HAL 9000 страшнее Чужого, а акула злодеистее марсиан?.. :)

28 сентября 2007 г.

QtAda 0.2.0

Сегодня вышла новая версия библиотеки QtAda — 0.2.0.

На подробный отчет у разработчиков времени пока нет, но мне дали эксклюзивный анонс, который я и публикую :)

1) Добавлена поддержка около десятка классов вокруг QTextEdit, им теперь можно пользоваться.

2) Добавлен работающий пример main_windows/dock_widgets.

3) Исправлено множество потерь памяти. Заодно оптимизировано создание, копирование и освобождение временных объектов. Как результат, на 27% уменьшилось количество выделений и освобождений памяти под временные объекты.

4) Но самое главное - это введение поддержки MS Windows! Инструкция в файле INSTALL.Windows. Работа с библиотекой под Windows требует установленных MinGW и MSYS.

Кстати, на днях ожидается появление бинарного дистрибутива библиотеки для Windows. Ждем! :)

http://qtada.sourceforge.net

Искусственный разум: кто нажмет "reset"?

Автор: Джеймс Бах (James Bach)
Оригинал: "The Future Will Need Us to Reboot It"


Я немного читал о Технологической Сингулярности. Интересная идея, придуманная людьми, которые никогда не занимались тестированием. Идея представляет из себя примерно следующее. Технологический прогресс не стоит на месте, он все время движется вперёд. В один прекрасный момент будет создан Искусственный Интеллект (ИИ), который сможет превзойти по способностям человеческий разум. С этого момента, который и называется Сингулярностью, будущее больше не будет нуждаться в человечестве... Начнется новая эра, новый виток эволюции — эра транcгуманизма.

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

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

В качестве примера можно привести Google Grid, показанный в видео "Epic 2014". Один из основных моментов этого видео — некий "алгоритм", который автоматически создает новости, используя отрывки информации, найденной в сети. Системы, генерирующие текст, существуют уже сегодня. Например, Racter, которому уже 25 лет. Разумеется, гугловцы думают о создании чего-то более продвинутого, но тут есть небольшая проблема. Создание осмысленного текста — это не просто манипуляция словами, не копирование случайных словосочетаний и перемешивание их в случайном порядке. Человек, пишущий для других, представляет себе своего читателя и его мир, ставит целью донести информацию и придумывает способ сделать это. Написать — означает выразить точку зрения. Добиться этого в автоматически сгенерированных текстах пока еще не удалось. Поэтому людей дурачат, предлагая суррогат вместо осмысленных текстов.

Я думаю, единственный способ создания настоящего искусственного разума — попытаться обеспечить такие условия для отдельных его свойств, при которых может произойти самообразование какой-то более высокоуровневой сетевой субстанции, подобной скоплению нейронов. Но мы никогда не узнаем может ли эта субстанция называться разумом, кроме как после длительного тестирования. Причем процесс тестирования будет очень долгим, нетривиальным и полным ошибок, ведь чем сложнее программа, тем больше в ней ошибок. Очень похоже на компьютер HAL 9000 из "Космической Одиссеи 2001" — может быть, он действительно умен, а может быть, он сошел с ума и все время врет. Никто не знает. Вызывайте тестеров.

(Когда в фильме HAL заявил, что компьютеры девятитысячной серии никогда не ошибались, у меня так и зачесались руки нажать ему на "reset".)

Вы не согласны? Вы соберете триллионы простейших компонентов и предоставите природе сделать из этого "разум"? Да, именно так и работает эволюция, и посмотрите, сколько ошибок! Посмотрите, насколько длителен этот процесс! И как мало разумного при этом создается! Если элементарным компонентам поставить задачу создать интеллект, почему мы считаем, что результат будет положительным?

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

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

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

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

Публикуется с разрешения автора.

24 сентября 2007 г.

Причины быть тестером

На Real World Software Development опубликовали с заметку "10 Reasons Why It's Better to Be a Software Tester". Хорошая идея, но, на мой взляд, слишком уж размазано получилось. Описанные 10 причин могли бы быть сокращены до 3-4 пунктов. А так — выглядит попыткой высосать из пальца недостающие причины, чтобы дотянуть до круглого числа 10.

Вообще, тон статьи кажется слишком уж деструктивным. Ведь, цель тестировщиков совсем не "break the software developer's code". У команды тестировщиков должна быть общая цель с командой разработчиков — добиться выпуска качественного релиза, найти и исправить максимум ошибок до того, как эти ошибки обнаружит заказчик. Это выгодно всем — и тестировщикам, и разработчикам, и даже заказчику, как бы смешно это не звучало :) Поэтому, цель - это сотрудничество, а не война с разработчиками.

Еще есть странный пункт номер 6 - "You don't need to deal with marketing gurus changing requirements". Ха-ха. Как будто тестировщиков вовсе не касается что изменяется в требованиях, кем производятся изменения и с какой целью это делается? Например, в моей практике был случай, когда упущенный контроль проектного лидера над процессом постоянных изменений в требованиях привел к тому, что команда тестирования узнавала об изменениях только тогда, когда приступала к тестированию нового release candidate. В результате, тестировщикам приходилось напрямую общаться с заказчиком, чтобы выяснить, что и зачем было изменено в требованиях.

Конечно, описанный случай — это не проблема тестировщиков или разработчиков. Это, скорее, проблема управления. Но даже при более правильном управлении, изменения в требованиях часто либо вообще не отражаются в документации, либо документируются настолько скудно, что приходится прилагать усилия, чтобы получить дополнительную информацию. А от кого можно получить такую информацию? Только от заказчика, от этих самых "marketing gurus"...

Но на самом деле с двумя пунктами не могу не согласиться.

"You get to touch more areas of the application than the developer" Как это не печально, но это правда. Я все чаще сталкиваюсь с ситуациями, когда область знаний и опыта представителей команд тестирования гораздо больше, чем у обычных разработчиков. Сложно сказать, с чем это связано. Думаю, не последнюю роль в этом играет отношение к тестерам, как полу-программистам...

"If you do make the switch to software developer, you will be 10 times better than the software developers that have not been testers" Да! Да! И еще раз — да! Проверено неоднократно. Это одна из причин, почему я обеими руками за то, чтобы разработчики сами создавали unit-тесты к своему коду — окунувшись хоть на немного в процесс тестирования, разработчик изменяет свое мышление. В лучшую сторону. Даже простая мысль "как я буду тестировать этот код" ставит разработчика на ступеньку выше тех программеров, которые не задумываются об этом.

Мне кажется, что именно эти две причины нужно выписать золочеными буквами и поставить на первые два места. Остальные пункты можно выкинуть :)

R2-D2 — незаменимая помощь настоящему джедаю

Для поклонников фильма "Звездные войны" и для всех прочих, у кого с чувством юмора все в порядке, фирма Hasbro создала робота R2-D2, очень даже настоящего, только маленького :) Студия Болотова протестировала первый экземпляр, завезенный в Россию. Да уж, ребята порезвились вволю :)

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

Прикольно бы было законнектить такое чудо и автомобиль — посадить робота где-нибудь в районе багажника и рассекать по городу... Что отличает настоящего джедая от нормальных людей? :) Правильно, R2-D2, катающий за ним тележку по супермаркету ;)

15 сентября 2007 г.

Я — Кобол

Прошел смешной тест "Which Programming Language Are You?" Выяснилось, что я — Кобол :)

You are COBOL. You are very business-oriented. You make conversations longer than they should be, and people easily grow bored by ou.
Which Programming Language are You?

11 сентября 2007 г.

El Café

Навеяло тут кофе :)

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

В ботанике растение кофе — оно. Мужской род не делает напиток из зерен кофейного дерева более благородным, чем, скажем, напиток из бобов какао.
...

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

Кроме этого, мужской род "бедному напитку" достался совсем не от устаревших форм. Скорее, наоборот. Дело в том, что обычно слова, заимствованные из другого языка, заимствуют и род. А слово "кофе" в европейских языках имеет как раз мужской род. На испанском, например, это звучит как "el café" — с артиклем мужского рода. Более того, слово "какао" раньше тоже имело мужской род в русском языке. По той же причине — это слово в иностранных языках тоже мужского рода. А вот почему оно сейчас среднего рода — это вопрос... Ответ, на мой взгляд, довольно прост. Потому, что нам так удобно.

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

ЗЫ. Удивительно, что "такси" до сих пор "оно", а "пони" — "он". Если продолжать мыслить по этой же логике — должны быть "они" :)

10 сентября 2007 г.

Почему Java

Джонатан Шварц в своем блоге объяснял причины смены биржевого символа, а заодно опубликовал рассказ Джеймса Гослинга откуда же взялось название Java. Мне очень понравилось. Хороший пример коллективного мозгового штурма.
Наш руководитель отдела маркетинга был знаком с одним "консультантом по названиям" (отличный специалист, не помню его имени). На обычную процедуру наименования у нас не было ни времени, ни денег. Он согласился провести нечто весьма необычное, но быстрое и эффективное: мы, всего с десяток человек, заперлись на полдня в комнате, а он взял на себя роль медиатора. Он начал задавать вопросы, например, "Какие чувства это у вас вызывает?" (Воодушевление!) "Что еще вызывает у вас такие чувства?" (Кофе!) Пока в конце концов вся доска не была покрыта более или менее случайными словами. Потом под его руководством мы их отсортировали и в результате составили рейтинг возможных названий. В конце концов в списке осталось около дюжины названий-кандидатов, и мы отослали его юристам. Те пошли по списку, отбраковывая названия до тех пор, пока не нашли то, которое удовлетворяло всем требованиям. "Java" (кофе с о. Ява) была четвертой в списке. Первым шел "Silk". Я его терпеть не мог, но всем остальным это название нравилось. Мне нравилось название "Lyric", третье в списке, но его забраковали наши юристы. Других вариантов не помню.

7 сентября 2007 г.

Пример плохого кода

Сегодня гоняли тесты компонентов и обнаружили в логах "memory allocation error". Ну что ж, надо локализовывать... Анализ логов показал, что проблема возникает в MyClass::onInit. Решили начать с осмотра кода. Код, конечно, упрощен, но основной смысл остался:

bool MyClass::onInit(State state)
{
  if(!someObject.isReady())
  {
    std::cerr << "Can't register SomeObject."
      << std::endl;
    return false;
  }
  return BaseClass::onInit(state);
}

Похоже, что дальше нужно лезть в BaseClass::onInit(), потому как isReady() проверяет состояние объекта... Стоп! А что значит "Can't register SomeObject"? Причем тут регистрация? А ну-ка, что там в isReady()?..

...И обнаружили вот такой шедевр:

bool SomeObject::isReady()
{
  if(tryToRecover)
  {
    deinit();
    state = init(origin);
  }
  else if(!state)
  {
    state = init(origin);
  }
  return state;
}

Ошибка возникала при вызове init() — функции инициализации объекта. Но дело-то уже не в ошибке.

У меня нет слов... Засунуть в функцию проверки состояния объекта вызовы инициализации и деинициализации — это что-то. Я, конечно, понимаю, что это не конец света, но именно из таких мелочей складывается общая некрасивая картина.

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

6 сентября 2007 г.

Великолепная 45-ка

Smashing Magazine опубликовал статью "45 великолепных дизайнов для блогов". Тут даже комментировать ничего не надо, нужно просто смотреть:

Смотреть

Хотя, нет, один комментарий у меня все же есть: умеют же делать, блин :)

4 сентября 2007 г.

QtAda — такого Qt мы еще не видели

Всем хорош язык Ада, да только нет для него нормальных библиотек для разработки GUI. Нормальные — это у которых соотношение времени разработка/геморрой хотя бы 60% на 40%. Так было...

Но вот, небольшая группа энтузиастов, озабоченная этой проблемой, взялась за портирование библиотеки Qt на Ada2005. И у них получилось! :) Что особенно приятно — ребята из России.

На данный момент библиотека поддерживает все фичи Qt 4.3.1. Возможно, релиз еще сыроват, но работа над библиотекой ведется непрерывно. Как бы там ни было, уже в текущей версии есть все, что нужно для разработки полноценного графического Qt-приложения.

Библиотека QtAda - http://qtada.sourceforge.net/

31 августа 2007 г.

Расширяем возможности cleartool, ч. 2

Кроме отсутствия в cleartool команды status, мне совершенно не нравится семантика команды cleartool diff. Действительно, после простой и удобной команды svn diff file.c, предназначенной для просмотра локальных изменений в файле file.c, строка cleartool diff -pre -dif file.c кажется слишком неудобной. И что самое главное — командой cleartool diff нельзя просмотреть изменения в нескольких файлах одновременно.

Но у меня есть волшебный скрипт, который неожиданно оказался вполне расширяемым :)

Итак, мне нужна простая команда diff, которая мне покажет локальные изменения для одного или нескольких файлов. Назовем ее sdiff и добавим в парсер аргументов скрипта:

case "$1" in
  sdiff) shift; sdiff $*;;
  status) shift; status $*;;
  *) $CT $*;;
esac

Теперь нужно создать функцию sdiff(), которая бы выводила изменения для всех переданных в командной строке имен файлов:

sdiff()
{
  if [ 0 = $# ]; then
    echo "ERROR: at least one argument should be passed."
    exit 1
  fi

  for T in $*; do
    echo "Index: $T"
    echo "---------------------------------------------"
    $CT diff -dif -pre $T
    echo
  done
}

Ну, вот и все. Синтаксис новой команды такой:

ct sdiff pname [pname ...]

где pname — имя файла или директории.

29 августа 2007 г.

Адское программирование

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

Сейчас, вернувшись к C и C++, я часто ловлю себя на мысли, что мне очень недостает адских возможностей. Но, как оказалось, по этому языку скучаю не я один :) Ричард Херрик так соскучился по возможностям языка Ада, что решил создать свою собственную реализацию адских ограниченных типов данных на C++, которую и предлагает нашему вниманию. И на мой взгляд, вполне достойную реализацию. К сожалению, пока речь идет только о целочисленных типах, но лиха беда начало :)

Читать статью "Ada-style Ranged Types in C++"

10 августа 2007 г.

Расширяем возможности cleartool

Так получилось, что по воле объективных причин недавно пришлось сменить систему контроля версий. До этого я использовал Subversion, и, надо признаться, с удовольствием использовал. Еще раньше был CVS, но, мне кажется, это все-таки прошлый век, и Subversion мне нравится гораздо больше. Однако, проблема Subversion в том, что в больших проектах его очень трудно использовать. Частично из-за его ограниченной производительности, частично из-за отсутствия средств автоматизации и интеграции с другими продуктами. И вот, пришлось пересесть за ClearCase, этого необъятного монстра. Говорят, много в нем хорошего, но и плохого — тоже немало. Точнее, не плохого, а неудобного. Хотя, возможно, это просто с непривычки...

В Subversion есть замечательная команда status, которая показывает все локальные изменения, произведенные с репозиторием. И хотя возможности этой команды достаточно широки, в подавляющем большинстве случаев я использовал эту команду, чтобы получить список измененных мной файлов, а также добавленных или удаленных. Обычно это делалось перед занесением изменений в репозиторий. В CVS для этих целей применялась команда update.

Используя cleartool, — консольный инструмент для работы с репозиторием ClearCase, — я обнаружил, что не могу найти простого и легкого способа получить список измененных мной файлов. Возможно, я плохо искал, но перерыв man и документацию по cleartool, я не нашел команды, аналогичной svn status. (Если такая команда все же есть, буду благодарен человеку, который мне ее покажет.)

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

#!/bin/sh

CT=cleartool

show_status()
{
  for T in $*; do
    PRE=" "
    $CT diff -pre -opt "-sta" $T || PRE="M"
    echo "$PRE $T" | tr -s "//" "/"
  done
}

status()
{
  CT_LSCO="$CT lsco -s -cvi -me"
  show_status `$CT_LSCO $*`
}

case "$1" in
  status) shift; status $*;;
  *) $CT $*;;
esac

Файл скрипта я назвал ct (сокращенно от cleartool) и положил в папку $HOME/bin, которая прописана у меня в системной переменной $PATH. Таким образом, я могу вызвать мой скрипт из любой директории.

Итак, зачем это. Скрипт построен таким образом, что все аргументы, указанные при запуске скрипта, передаются команде cleartool. Таким образом, скрипт ct является неким псевдонимом команды cleartool. Например, команда

ct ls -r /vob/myproject/somelib

эквивалентна вызову

cleartool ls -r /vob/myproject/somelib

Однако, ct — это не просто псевдоним, а псевдоним с дополнительными возможностями. Вызвав команду ct status, можно получить список "вычекнутых" из репозитория папок и файлов текущим пользователем для текущего view. Файлы, которые были изменены, будут помечены буквой M, как и при выполнении svn status. Общий формат вызова ct status такой:

ct status [-r] [pname ... ]

где pname — имя папки или файла репозитория (может быть указано несколько имен). Если pname не указывать, команда будет выполнена для текущей директории. Ключ -r переводит команду в рекурсивный режим — команда status будет выполнена для всех вложенных поддиректорий.

Например, необходимо получить статус файлов и поддиректорий для папки /vob/myproject/someapp:

$> ct status -r /vob/myproject/someapp

M /vob/myproject/someapp/file.c
  /vob/myproject/someapp/file.h
M /vob/myproject/someapp/main.c
M /vob/myproject/someapp/include/types.h
  /vob/myproject/someapp/include/ext/ext.h

Результат выполнения команды показывает, что из репозитория были "вычекнуты" файлы file.c, file.h, main.c, types.h и ext.h, а изменены только file.c, main.c и types.h.

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

ct ci -c "Some text here." file.c

При обработке аргументов скриптом качычки будут проигнорированы и каждое слово будет восприниматься, как отдельный параметр. Неудобно? Наверное, да. Но лично я не использую такой вариант check in. Я использую вариант с добавлением комментария после ввода команды, поэтому для меня это неудобство проблемой не является:

$> ct ci file.c
Some text here.
.
<Ctrl+E>

26 июля 2007 г.

Ящик без денег

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

Попробовав несколько вариантов, понял, что в этом банкомате денег мне снять не удастся: "В банкомате отсутствует требуемый номинал", невозмутимо сообщала железная коробка с деньгами на все мои попытки снять требуемую мне сумму. "Ну, если денег не даёт, так хоть удовольствие получу", подумал я и приступил к тестированию (да, я ненормальный ;).

Какие у нас есть номиналы, кратные 50 рублям? 50, 100, 500, 1000, 5000. Ну что, поехали? "Снять наличные", пин-код, 50 — "В банкомате отсутствует требуемый номинал". "Снять наличные", пин-код, 100 — "В банкомате отсутствует требуемый номинал"... Уфф... Кнопки тугие, аж пальцы заболели.

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

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

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

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

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

7 июля 2007 г.

Снова о кино

Так случилось, что когда вышли на экраны "Пираты Карибского моря 3", я не смог посмотреть их в кинотеатре, поэтому посмотрел DVD дома на ноутбуке.

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

Я не знаю, в чем тут дело... Видимо, я как-то умею абстрагироваться от смысловой нагрузки (точнее, от ее отсутствия) и просто получать удовольствие от режиссерской работы и игры актеров... А фильм, как я считаю, очень красивый, снят очень хорошо и актерский состав играет просто великолепно, включая второстепенные роли... Да и смысловая нагрузка присутствует, если уж быть до конца честным. Другое дело, что это сказка — ну так сказки не каждому по душе...

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

P.S. Кстати, думаю, что наличие смысловой нагрузки далеко не всегда играет важную роль. Какую смысловую нагрузку несут, например, картины, висящие в Русском Музее?.. Или какая смысловая нагрузка у "Вечной весны" Родена? А?..

6 апреля 2007 г.

K. I. S. S.

Электронный журнал Smashing Magazing собрал список из 50-ти самых простых веб-дизайнов. Однако, "простой" не значит — "плохой" :) Можно смотреть и черпать идеи...

Keep It Simple, Stupid!

17 марта 2007 г.

Задачи на собеседованиях: биты и байты


  1. Написать программу, которая переворачивает порядок бит в байте. То есть, из 0xE2 (11100010) нужно получить 0x47 (01000111).

  2. То же самое, но без использования циклов.

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

24 февраля 2007 г.

Может быть, я — патриот?..

Прочитал сегодня на BBCRussian:
"Кремль не хочет признать поражение и отказаться от разработок в высокотехнологической авиакосмической индустрии, частично из стратегических соображений, а частично из-за того, что не хочет тратить миллиарды на аэробусы и боинги. Российская авиакосмическая индустрия может выправиться только, если получит доступ к западным технологиям".


И мне обидно так стало. Ведь мы можем добиться огромных успехов и у нас есть для этого мозги... Российские разработки могут дать фору некоторым монстрам индустрии. Однако, у нас существует огромное количество людей, для которых "важен не результат, а процесс" (мля, я лично знаком с несколькими индивидумами). Естественно, что у нас проблемы с результатами. Мы ведь деньги за процесс получаем, а не за результат! :(

Мне лично обидно, что из-за этого страдает наша индустрия, а еще обиднее, что страдает авторитет страны. Люди, давайте перестанем воровать!!! Давайте работать!!!