вторник, 25 декабря 2007 г.

Форма и содержание

Наверное, сейчас уже никто толком не скажет, кто и когда придумал метафору формы – как прототипа экранного окна. Возможно, эта идея неотделима от идеи самого окна, а она, как известно, в научном и техническом мире витала и обретала различные представления не один десяток лет. Так или иначе, попытки визуально проектировать интерфейс с помощью форм я увидел впервые году так в 1990, когда приходил к отцу на работу посмотреть на персональные компьютеры IBM PC/AT 286 «Компан». Это был Clarion версии 2.0. Он был оснащен так называемым скриндизайнером, который позволял с помощью мышки, достаточно быстро и споро создать под ДОС псевдографический пользовательский интерфейс для разрабатываемой базы данных. Как сейчас помню - сижу, расставляю мышкой ключики у полей, не очень понимая, для чего все это нужно, перемещаю окошки, как вдруг слышу сзади голос начальника отдела автоматизации: «Ну что, сидишь, ерундой маешься? Займись-ка лучше делом!» И достает из конвертика пятидюймовую дискету с надписью «Будокан». Конечно, обучение Clarion на этом закончилось, но всё равно, те деньки я вспоминаю с воодушевлением. Потому что были ещё Арканойд, Метал Мутантс и многое другое. =)
Что касательно Clarion-а, то он до сих пор весел, здоров и замечательно себя чувствует. Возможно, появление Foxpro, Delphi и других подобных систем и подпортило ему жизнь, но уже тогда в нем был заложен очень большой потенциал, который помог Clarion дожить до .Net 2.0. Удивительное дело, но, похоже, сама судьба помогла Брюсу Берингтону, основателю компании HBO и разработчику Clarion в его начинаниях. Ища наиболее перспективные пути развития своего продукта он наткнулся на компилятор от небольшой и почти неизвестной компании JPI, которую создал Нильс Йенсен – один из основоположников Borland. Компилятор этот был непростой. Основанный на Борландовских разработках, он был переработан командой Йенсена так, что для всех поддерживаемых языков (а их было немало – Модула, Паскаль, Си и Си++) компилятор генерировал совместимый двоичный код. Поэтому, в рамках одного приложения можно было использовать любой из этих языков без особых проблем. Так что пятнадцать лет спустя переход на .Net, заключаю я с некоторой долей иронии, является скорее способом остаться в рамках мейнстрима, нежели технологическим шагом вперед. =)
Но оставим Clarion в покое, в конце концов, речь сейчас идет не о нем, а о формах. Именно о них, родимых, я и хотел поговорить. Несомненно, сама парадигма форм в Delphi была сильнейшим стимулом к переходу на это средство разработки. Достаточно просто просуммировать время, потраченное на невизуальное создание окон в Windows, что хочется забыть эти пустые хлопоты, как страшный сон. Но технологии не стоят на месте, достоинства стерлись бытом, а недостатки стали все четче проявляться и мозолить глаз. Прежде всего, это раздельное хранение класса формы и её инициализации в двух разных файлах Pas и Dfm. Почему был выбран путь отделения формы и модуля? Наверное, в 1994 году не хватало технологий, производительности, ещё чего-то? Может быть, тогда существовала какая-то очередная иррациональная мода, которая может заставить разумных людей делать безумные вещи – например, покупать ужасные по реализации, но раскрученные пиаром технологии или затыкать XML-ем любую дыру. К сожалению, достоверные причины мне неизвестны (к тому же, вряд ли можно создать архитектуру, прожившую в IT сфере более десяти лет и удовлетворяющих всех и вся). Но все-таки хранить настройки формы в отдельном файле от класса – это очень неудобно. При этом происходит неоправданное размазывание логики приложения. Часть кода в модуле, часть в форме. Хотим мы что-то изменить, поиском прошли, да и не нашли часть инициализации. Где-то поменяли, где-то забыли. В таких условиях я часто склоняюсь к тому, что некоторые настройки формы и компонентов на ней вообще лучше писать в коде, чтобы получить гибкость в управлении изменениями (согласитесь, что не всегда удобно открывать монстрообразную среду, чтобы внести пару простейших изменений в код). Ну и сравнивать две версии проекта приходится тоже дважды – в модуле и в форме. Еще одной шероховатостью, связанной с разделением данных, является необходимость инициализации компонентов из потока в методе Loaded (и установка соответствующего состояния), которая, конечно, досконально описана, разжевана и не вызывает проблем у опытных разработчиков, но рождает некоторое недоумение в глазах новичков. А что ж делать? Система-то уже построена, надо как-то с ней жить. И для нивелирования недостатков её архитектуры появляются семиногие подпорки: в новых версиях Delphi встроенный рефакторинг, который учитывает особенности такого разделения кода и проводит изменения не только в тексте модуля, но и в дизайнере. А для старых версий – есть различные эксперты, реализующие отсутствующую функциональность. Да и если проследить историю развития Delphi, то от версии к версии можно заметить, что механизм обслуживания такой дуалистической архитектуры совершенствовался, развивался и улучшался, давая больше сервисных функций (читай – подпорок).
Другая засада – это невизуальные компоненты на форме. Порой проект разрастается до таких размеров, что под невизуальными компонентами уже не видно визуальных. И первые приходится постоянно перекладывать с места на место, чтобы добраться до вторых. Правильное решение этой проблемы – создание Datamodule, если быть до конца честными, тоже подпорка из разряда: «О как удачно все получается!».
Конечно, если опытный разработчик начинает новый проект, он знает обо всех этих заковыках, и его код будет максимально приспособлен под такие особенности среды. Как говорится: «все правильно сделал!», т.е. с оглядкой на такой вот небольшой бардачок в сердце технологии.
«Что делать» давно знают и разработчики Delphi, и её пользователи. Готовые решения есть прямо тут, в Delphi для Net. Загляните в Winforms и увидите простую и элегантную реализацию хранения и инициализации формы в коде класса. Ненужные постоянно методы скрыты фолдом, страшный LiveSource для надежности можно вообще выкинуть и заменить простым Include с автогенерацией. Что касается невизуальных компонентов, то в Winforms для этого есть специальный отсек. Компоненты форму не засоряют, расположены упорядочено, есть скроллер, можно ещё контекстный поиск добавить. Красота. И сделать такой отсек для VCL ветки продукта на вскиду не составит проблем, так как это просто интерфейсное решение.
В заключение хочу сказать, что на мой скромный взгляд эти изменения нужны. Может быть, они не такие необходимые, как поддержка Unicode и 64 разрядной архитектуры, но они помогут сделать Delphi лучше. Да, возможно, не все старые проекты будут работать как надо, но это все решается. Скорее всего, конечному пользователю даже думать над совместимостью не доведется – старые формы смогут работать параллельно с новыми. Компоненты, если они написаны правильно, тоже не придется переписывать. Кое-что надо будет почитать, появятся дополнительные настройки, но это не такая уж большая проблема. В конце концов, мы уже десять лет живем с OldCreateOrder под боком, и по моим сведениям, никто от этого ещё не умер…

вторник, 4 декабря 2007 г.

Центральное бюро качества

Сегодня я немного порассуждаю о QualityCentral. Первые его росточки появились в уже далеком теперь 2001 году. Тогда Джон Кэстер, будучи архитектором комьюнити сайтов компании Борланд, поведал миру о том, что, не смотря на наличие и продуктивную работу ньюсгрупп, назрела острая необходимость в реализации удобной системы бэктрекинга для программных продуктов компании. Так и появился QualityCentral, вслед за своим собратом Codecentral-ом. Идея, надо сказать, была очень нужная, верная и востребованная. Формализованная система гораздо точнее и лаконичней групп новостей, где информацию, размазанную по десяткам топиков, приходилось выуживать по крупицам. Сказано – сделано (хотя нельзя утверждать, что это было сделано быстро). В течение двух лет появился win32 клиент, а за ним и полноценная Web версия. Сделано было все на продуктах Борланд, использовалась очень модная и перспективная на тот день технология веб – сервисов с полным описанием интефейсов - этакое ненавязчивое приглашение к сотрудничеству. Сподобился ли кто написать на эту тему какую-нибудь программу и зачем вообще это может быть нужно – мне не известно… Так или иначе, комьюнити оценило простую возможность обратиться к разработчикам с наболевшими вопросами в рамках унифицированного интерфейса, и сервис получил большую популярность.

В целом система работает не плохо, но есть всё-таки некоторые странности, которые хотелось бы отметить, тем более, что они постоянно мозолят глаза и уже начинают трепать нервы. Первое, что замечаешь – это топорный дизайн, который действительно мешает жить. Многие программисты в плане дизайна совсем не требовательны, и аскетичное убранство QC даже можно было бы считать достоинством, если не откровенные ляпы, которые просто мешают работе. Вот взять, например, самый популярный топик по 64 битному компилятору. Как говорится, оцените своими глазами: идиотский алигн, отсутствие внятного цитирования, висячие строки, мягко говоря загадочная реализация ниток ответов, не говоря уже про отсутствие банальной расцветки синтаксиса. А на дворе-то - 2007 год, и даже самый захудалый форум может показать это дело в разы лучше. Как можно продуктивно работать над решением проблем, если даже к форматированию кода – основе стиля программирования Delphi – QC относится по меньшей мере наплевательски? А раскраска статуса… Это было сделано для самоуспокоения что ли – открытые issue – зеленым, а закрытые – красным? Меньше красного, больше зеленого! Проблема должна мозолить глаза, а не успокаивать. Но на QC все по-другому! Или вот – абсолютно не ясно, как в этом интерфейсе можно найти, например, все нерешенные проблемы. Или это ещё один удобный повод их не решать?

Вообще, заход на ресурсы Борланд для меня – моральное испытание. Может у меня с инетом что, может меня не взлюбили в Америке (хотя скорость 4 мегабита/сек – сайты гугла открываются со свистом)? Общее ощущение от веб итерфейса QC - все работает медленно и неспеша. В целом, антураж такой, что энтузиазма не вызывает. Ресурс на троечку.

К слову сказать, клиент для Windows имеет больше возможностей, но напоминает поделку студента 2-ого курса, недавно освоившего Delphi. Такой разваливающийся UI можно назвать не иначе как отпиской. И ещё нужно некоторое время, чтобы привыкнуть к его спецэффектам. А мне казалось, что у ресурса с таким помпезным названием, как QualityCentral качество должно переть изо всех щелей. Что, опять не завезли?

вторник, 27 ноября 2007 г.

Так что там с нашим хэлпом?

Заметка была написана давно, да как-то не было времени выложить сюда. Актуальность её несколько утрачена, но, тем не менее, опубликую - не пропадать же добру =)

До третьего Update хелпом от 2007 – ой Delphi пользоваться было очень тяжело. Сейчас в нем многое поправили, но все – равно, нет-нет, да и наткнешься на липовую ссылку или отсутствие раздела. Хотя больше всего претензий вызывает скорость работы. Понятно, конечно - в деле используется более прогрессивная оболочка от Майкрософт с возможностью онлайн поиска, настраиваемым дизайном и интеграцией в инфраструктуру MSDN. Однако и ресурсов лопает этот Document Explorer от души. Вот специально запускаю его, потыкал пару кнопок, поискал пару топиков – почти 60 метров ОЗУ (Рам + виртуалка) и 25 потоков. «Наше прогрессивное средство не для слабаков!», - решил Майкрософт. «Ага!» – согласился CodeGear. – «И устанавливаться этот хелп должен также прогрессивно долго!». Действительно, пожалуй, самой длительной операцией при инсталляции Delphi теперь является установка, регистрация и настройка хелпа. Так долго, что можно поседеть и состарится. Зачем явился миру новый формат справки для Delphi - понятно. Не один десяток компаний пошел ко дну, отказавшись смотреть в рот Майкрософт. Но слепое следование мэйнстриму всегда имеет две стороны – либо мегамонстр все равно пропихнет свое детище, как было с IE, или комьюнити проигнорирует неудобные ему инновации, как произошло, например, с RAMBUS. Эх, знать бы прикуп…

Идем дальше. Замечательная фенечка «Фильтр». Казалось бы, выбираем нужный раздел, например, Language Delphi и получаем справку по Delphi… и С++. Тоже самое – если выбрать фильтр с С++. Ясно, конечно, откуда ноги растут. Справку от седьмой версии никто не переписывал – просто преобразовали в новый формат, как смогли и прикрутили к новому интерфейсу. Со времен семерки утекло много воды, кое-что изменилось, кое-какие классы и разделы добавились, но там вообще полный мрак: многие ссылки не работают, описание скудно или просто отсутствует, некоторые топики присутствуют в хелпе декларативно, для галочки. Технический писатель к ним даже не подступался. Только пронесся тупой генератор, подгоняемый переменной цикла, и создал несколько дежурных разделов и замечательное по своей информативности примечание: «Это класс TSuperpuperClass». Как будто я и сам этого не вижу =).

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

Из положительного следует отметить то, что было устранено ошибочное открытие нескольких файлов справки, когда они скушивали всю оставшуюся не тронутой BDS (ну, вы понимаете) физическую память, и работать было просто невыносимо. Также, судя по логам, пофикшено много других ошибок в документации. Но, как любит поговаривать Билл Гейтс – «Нам ещё есть над чем работать».

Есть в планах у CodeGear и желание русифицировать хелп, как это сделано для немецкого, французского и японского. Может быть это и нужно, но для начала хотелось бы привести хелп в разряд «достаточно хорошего», если не выходит сделать просто хороший.

Внимательный читатель спросит: «так в чем же соль этого затянувшегося эссе?» Мораль проста: опять приходится шаманить. Кто-то, использует сразу два хелпа. Старый – от семерки, если хочет найти что-то быстро. Новый, если старый не помог. Кто-то молчаливо терпит или юзает что-нибудь экзотическое типа PDF или HTML - хелп. Ну и самый правильный способ втихаря предлагает сам CodeGear для тех, кто не согласен с мейнстримом и ведет себя вызывающе. Это стандартный chm файл для Delphi 2007. Дешево и сердито. И как вы сами можете посмотреть – первое место в рейтинге по скачиванию (не считая интерактивного туториала пятилетней давности). Ну и стоило ли городить огород?

P.S. С момента написания заметки произошли изменения - появилось обновление хелпа, которое можно скачать тут

вторник, 20 ноября 2007 г.

НедоUML (Часть 2)

Первая часть


Теперь по поводу того, как надо делать UML редакторы. Эталоном, на мой взгляд, является PowerDesigner компании PowerSoft, который потом удачно прикупила Sybase, но видимо не полностью, так как аналогичный по функциональности продукт под названием QDesigner настойчиво продвигал молодой паблишер Quest Software. Сейчас QDesigner претерпел сильные изменения и называется Toad Data Modeller. Самым главным недостатком PowerDesigner-а является его заоблачная цена. Еще одно средство, которое набирает популярность – Visual Paradigm. Несомненно, очень интересная разработка, как в плане интерфейса, так и возможностей, но мне этот редактор показался очень вычурным. Это мешает работе. Что качается Rational Rose, то последний раз я её видел в 2006 году и тогда она была всё такой же страшной и неудобной, как и год до этого, и два и десять... Может уже что-то поменялось?

Так вот, все эти продукты много чего умеют, в том числе и генерировать код из/в модель. И хотя, конечно, до удобства LiveSource им далеко, зато они это делают легко, непринужденно, а главное – правильно (если их соответствующим образом поднастроить). К сожалению, про Delphi они почти ничего не знают. Вот, помню, давным-давно шестая версия PowerDesigner умела не только генерировать скрипт для БД, но и многооконный интерфейс среднего пошиба в виде исходных кодов на Delphi. Этот код, на удивление, всегда успешно компилировался и превращался в замечательный инструмент (как я его называю – дбтыкалка) для проверки идей разработчика и заполнения БД. Но, на дворе уже 12 версия Powerdesigner-а, из которой все это убрали волевым решением (точнее, убрали ещё в седьмой версии). Зато её теоретически можно научить многим другим премудростям, в том числе и генерировать Delphi код из модели и обратно, как это происходит с другими, более популярными языками. Насколько мне известно, Delphi.xol для PowerDesigner-а так пока никто и не реализовал (хотя это не так уж и сложно). Лучше дела обстоят у Rational Rose – там имеются решения, по большей части «самиздат», но пригодные к работе. Однако, я хочу оставить все эти гипотетические возможности, которые каждый сам для себя или для своей организации может реализовать, и поговорить о вполне реальном средстве, которое неожиданно появилось в Delphi 7, и также неожиданно пропало в последующих версиях. ModelMaker – простой способ ощутить, что ты уже можешь воспользоваться благами цивилизации, как и разработчики на других языках. Средство, конечно, не идеальное, но на безрыбье…

ModelMaker Code Explorer уже заслужил свое почтение у многих пользователей Delphi, как замена стандартному эксплореру кода. На мой взгляд, он кажется аляповатым, но по функциональной части он очень хорош, а это главное. Так вот, Code Explorer – это небольшая часть ModelMaker-а, который представляет собой условно интегрированный в IDE Delphi эксперт, позволяющий разрабатывать ПО более продуктивно, т.е. с помощью всех тех средств, что предоставляет нам UML. Подробно описывать все баги и фичи продукта я не стану. Отмечу лишь самые сильные и слабые, на мой взгляд, стороны эксперта для версии 8.20. Итак, плюсы:
1) Все работает.
2) Все работает быстро.
3) Код, который получается в результате генерации – хороший код. Меня он устраивает. Есть кое-какие шероховатости, но главное, см. пункт 1.
4) Реверс работает практически идеально. Если не использовать новомодные фичи в виде новых конструкций языка, появившихся с поры Delphi 7, все очень четко и безглючно. (В девятой версии, судя по документации, новый синтаксис уже поддерживается)
5) Перед генерацией кода происходит проверка на изменение исходного файла с тех пор, как из него извлекли данные в модель. Из опыта работы могу сказать - тоже очень надежная вещь.
6) Visual Difference мне показалась даже лучше, чем в Starteam и новой Delphi.
7) Подробные и проработанные редакторы методов, свойств, полей.
8) Внятная система управления модулями и классами.
9) В диаграммах правильно работает скроллер с комбинациями Shift + колесо и Ctrl + колесо.

Есть и недостатки:
1) ModelMaker – не полноценный эксперт Delphi с доступом к редактору и коду, а некая отдельная программа. Соответственно, писать в нем код человеку, привыкшему пользоваться подсказками, автозаполнением, фолдиногом и другими прелестями среды очень затруднительно. Есть выход – структуру классов проектировать в MM, тела методов писать в Delphi, благо процесс переключения достаточно быстр и легок.
2) Загадочное расположение редактора кода. В ModelMaker он выделен в виде отдельной закладки. Пусть так. Но когда я нажимаю на метод, и появляется редактор метода – логично бы было бы показать тело метода именно в этом окне на одной из закладок. Это же так просто, понятно…, но недоступно - форма модальная – извольте вначале её закрыть, и вот тогда у вас появится шанс увидеть реализацию нужного вам метода!
3) Идея с защищенным и автогенерируемым кодом логична, но выполнена как-то неубедительно. Много путаницы, зачастую возникает дублирование кода. Опять же эти маленькие окошки со скроллером. Тут надо что-то менять.
4) Окно для документации объектов не масштабируется, в результате чего документацию приходится писать узенькой полосочкой. Как в газету «Известия».
5) Визард интерфейсов хорош, но интуитивно не понятен.
6) Макросы очень просты, а генерируемый ими текст не понимается парсером, в результате чего этот текст (чаще всего примечания) начинает блуждать по исходному коду модуля.
7) Редактор диаграмм угловат, странно масштабируется и вообще, сильно ограничивает творческую мысль. Первое ощущение от программы – тебя посадили в рамку и поделили на квадраты – столько там всяких сплиттеров и окон.
8) Layouters даже не вызывайте. Разрабатывал какой-то вундеркинд – имбецил. Согласитесь, что это довольно странное сочетание для человека. Не верите, что такие существуют? Тогда смело нажимайте. Особенно прекрасен Interactive Visualizer.
9) Не всегда ясно, методы какого класса в данный момент отображаются в списке c драматическим названием «Members». Тут, конечно, обычная интерфейсная путаница. Я даже думаю, что правильнее было бы назвать пункт №9 короче: путанный интерфейс.
10) Делегаты стоят особняком, у них не парсятся параметры, хотя это может быть и не столь принципиально.
11) Не очень очевидные настройки визуализации диаграммы. В свое время пришлось попотеть, чтобы настроить отображение классов так, как мне хочется. Хотя там столько всяких настроек… Вот, наверное, поэтому и попотел.
12) Идиотская реализация пиктограммы интерфейса на диаграмме. Не, ну действительно идиотская. Говорят, в девятой версии они поправились, рисуя прямоугольник, а внутри уже пиктограмму. Если это так, то это хорошо.

Не смотря на то, что замечаний гораздо больше, чем достоинств, хочу отметить, что ModelMaker на голову выше Torether с точки зрения качества работы. На моей памяти MM падал пару раз с акцесс виолейшон, но почти без последствий (это, наверное, потому что я часто жму ctrl+s). А если привыкнуть к особенностям, то работать на нем будет легко и просто. Большинство замечаний, как вы уже, наверное, заметили, связаны с нескладным внешним видом и разваливающимся UI. Понимаю, что многие к такому уже «пригорели». Но все равно, это безобразие надо переделывать. Слава богу, из кустарей уже вылезли, деньги зарабатываете – сделайте уже человеческий интерфейс.

Ещё одно чудо, которое спасло меня от досрочной кончины – Eco3Modeller. Эта штука всё тех же создателей, сделанная на основе ModelMaker замечательным образом заменяет Together при создании ECO проектов. После её установки все вопросы стабильности редактора диаграмм пропали, остались одни ответы. Хотя и сам Галилео версии 2006 не назовешь эталоном стабильности. Но об этом, может быть, в следующий раз.

Что-то как-то получилось очень дифирамбно для компании “Modelmaker tools”… Ну а что делать? Родной-то продукт – слабенький. Вот так я вижу это дело.

вторник, 13 ноября 2007 г.

НедоUML

Иметь в IDE встроенный UML редактор, да ещё с такой фичей как LiveSouce ™, ®, © - верная приманка для новой армии поклонников. Все-таки на дворе не девятнадцатый век, пора уже прощаться с банальным набиванием кода и подниматься на новый уровень абстракции. К тому же у нас есть устоявшееся стандартизированное средство – UML, достаточно формализованное по части диаграмм классов, чтобы из этого можно было сделать автоматизированную систему с двухсторонними преобразованиями. Что ж, дело хорошее! К тому же у нас уже есть решение – Together, опробованный в деле UML редактор, с возможностью генерации кода для Java – чего огород-то городить? Портируем и поехали… Только что-то не приехали никуда. Даже не отъехали. Тут прямо и встали. Вот сейчас передо мной D2007 Update3, но это творение всё ещё глючт. Разнообразно, с выдумкой, с душой, так сказать. Работать с ним можно, но сложно. А ведь Тогезер был и в 2005, и в 2006. И там было это настолько тухло, что опытные люди сразу же отключали «Живые исходники», чтобы они случайно не умертвили их код. Ещё во времена BDS 2006 я читал историю одного разработчика, который описывал свои мытарства с Тогезером. Так вот, он утверждал, что в принципе работать можно – нужно только аккуратно делать действия A, B, C и особенно внимательно действия D и E. А в случае ошибки или падения среды – восстанавливаться из истории по таким-то признакам. Ребята, ну это несерьезно. Мы же пишем большие приложения, и на возню с кривым инструментом у нас попросту нет времени. К тому же, без возможностей LiveSouce сам Together превращается в рядовой UML редактор, коих на просторах Интернета десятки, если не сотни. Можно выбрать что-нибудь и получше.

«Хорошо», - скажете вы, - «Отключили, да и дело с концом. Писали классы руками, безо всякого там UML и дальше проживем». Ан нет, это только начало… Есть такое модное слово – «Рефакторинг». Помните, как раньше говорили:
- Пасматри, какую фигню ты написал! Переписывай, нафиг, заново!
А теперь это называется рефакторинг. Так вот, рефакторинг-то без модели не работает. Можем название идентификатора поменять, переменную добавить, найти проявление идентификатора в коде, но если что-то посерьезнее… Но формально рефакторинг есть…

Едем дальше. ECO! Наконец-то работоспособная реализация MDA со всей своей привлекательностью, правда под дотнет (это, впрочем, не недостаток сам по себе, просто фича). Будущее уже здесь! Персистентмапперы, хэндлы, автоформы… Хочешь – WinForms приложение, хочешь – веб. Все настраивается, база данных сама жужжит, ни о чем не спрашивает. Контролы любые используй, не как в дедушке BOLD-е. Красотыщща! Все бы ничего, только вот где мы рисуем наши модели? Правильно, в Тогезере! Нет, ну может для академического обучения школьницы 12-ти лет это самое то, но писать рабочий проект с конкретными сроками и реальными деньгами на ЭТОМ может только очень, очень самоуверенный человек. И не то, чтобы ECO плохо работает, просто Тогезер глючит. Ещё раз: ГЛЮ-ЧИТ.

Чтобы быть объективным, скажу, что мне нравиться в Тогезере.
1) Возможность добавлять объекты диаграммы шорткатами. Это действительно удобно для человека, который пришел не рисовать три прямоугольничка со стрелочкой, а разрабатывать систему.
2) Live Source. Это замечательная вещь, если бы она работала так, как надо.
3) Продуманное автоматическое размещение объектов диаграммы (Layout). Не во многих средах такое встретишь.
4) Аудиты и метрики. В универсальных средах они не так развиты в силу универсальности этих сред, поэтому это скорее маааленький плюс.
5) Генерация документации и экспорт её в html. На уровне других продуктов.
6) Возможность добавлять свои собственные свойства к объектам диаграммы. Хотя реализовано это простовато - нет никаких шаблонов для однотипных данных. Что уж говорить про отсутствие элементарного Description у объекта диаграммы.

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

В заключение первой части хочу отметить, что на мой взгляд (по информации из форумов), проблемы генерации исходного кода и соответственно reverse engineering этого кода в модель отмечались по большей части для Delphi, нежели для C#. (для версии BSD2006)

(продолжение следует…)

среда, 7 ноября 2007 г.

Вешалка или инсталлятор?

Помните знаменитое выражение Константина Сергеевича: «Театр начинается с вешалки»? А с чего начинается программное обеспечение? Я думаю - с инсталлятора! Новый универсальный инсталлятор Codegear - это специальный продукт компании, призванный вымотать все нервы у благодарных поклонников. Казалось бы, какая забота о пользователе! Всегда свежие, пахнущие компилятором, файлы без прежних глюков, полная автоматизация самого процесса инсталляции, описание происходящего, и даже, вы не поверите, прогрессиндикатор! Так что же всполошило наших толерантных пользователей, мужественно переживших даже Delphi 8 и Delphi 2005, и заставило исписать сотни форумов и блогов в поисках ответов на свои вопросы. Попробую объяснить на примере, хотя и говорят, что примером ничего нельзя доказать или опровергнуть.
Итак, товарищ решил поставить Update 3 на Delphi 2007. Ну что ж – дело хорошее, тем более что всякие модные фичи типа добавления переменных в Var секцию прямо из текущего места кода в его непатченной Delphi не работали. Не говоря уже о диаграммах, которые напрочь отказывались создавать любые объекты, кроме Namespace. Сказано – сделано. Инсталлятор жужжит – удаляет старую инсталляцию, причем полностью, качает что-то из сети, ставит новую. Мы пьем чай, беседуем о хлебе насущном. И тут у нас кончается свет. (Видимо, Чубайс нас за что-то не возлюбил, потому что свет последнее время пропадает достаточно часто). В ответ на это у нас есть аргумент фирмы APC, хорошо зарекомендовавшей себя в борьбе с таким недугом. Но вот беда, такого устройства нет в одном из шкафов сетевого оборудования где-то по ходу наших пакетов из далекой Америки. После этого инцидента у нас на компьютере не осталось ни старой версии, ни новой. Только кэш с недокачанными файлами. Но самое странное – инсталлятор ни в какую не хочет запускаться. Т.е. вообще. Почитали Интернет, узнали, что проблема такая есть, о что ней знают и помнят, скачали майкросовтовскую тулзу, которая завалила остатки инсталла, удалили все из реестра, из prorgam files, из application data своих и общих, вытерли испарину и начали все по новой… Сразу хочется вспомнить певицу Земфиру, громко вопрошающую в куда-то зал: «Почему?...» На-на-на, блин.
Я тоже имел похожий опыт апгрейда с помощью этого инсталлятора. Но у меня все прошло на удивление гладко, только процесс апгрейда растянулся так, что знай я заранее, что это будет так долго, я бы просто пошел домой. Видит бог, я наблюдал за сим действом более 5(!) часов. Это при том, что у меня не самый медленный Интернет. И все это время я не знал, когда этот безумный процесс закончится. Милая программа время от времени показывала подходящий к концу прогрессиндикатор, сбрасывала его в ноль и начинала все сначала. Видели мы такие алгоритмы...
Кто-то может сказать – чего тут разводить пустословие на три страницы? Проблема не стоит выеденного яйца - просто скачайте образ с сайта и ставьте сколько захотите. Ну да, так наверное и надо делать впредь, а не использовать предоставляемые программой возможности. Фигня-то заключается в том, что прежде чем товарищ Исаев вспомнил название этого популярного садового инструмента, он на него наступил. Ну и зачем тогда нужен этот модный инсталлятор (два раза КУ), который делает все неудобно, неоптимально, а порой даже по-идиотски? Зачем сносить рабочий продукт, если ещё ничего нет ему на замену и неизвестно, будет ли? Почему я не могу знать про то, сколько это чудо будет ставить среду и все это время вынужден сидеть без работы? Я уже не говорю про возможность «починить» инсталляцию за счет места на винте пользователя. Иолки-моталки, да если бы программисты были тупыми пользователями, которые не могут сами нажать инсталл-анинсталл, смогли бы они работать на Delphi? Все это напоминает неожиданно проснувшийся в разработчиках инсталлятора «талант суперархитектора», о котором так много говорили большевики, тьфу, Бэк и Фаулер. Потратили бы лучше эти мифические человекомесяцы на создание действительно стабильной и удобной среды. Инсталлятор же должен быть простым и надежным. Все остальные цели, которые вы хотите достичь, не должны идти в разрез с желанием пользователей установить ваш продукт. Потому, что желание пользователя - вещь капризная - может вступить в конфликт с его терпением и одним пользователем CodeGear станет меньше. Оракл уже наступал на подобные грабли со своим OUI, но они большие – им, типа, можно. Из-за какого-то инсталлятора завод не станет менять БД =). Интересно, в CodeGear тоже на это рассчитывают?

вторник, 9 октября 2007 г.

Пишу!

Дисклэймер (т.е. отмазка):

Давно хотел начать писать что-нибудь про Delphi, но все как-то не получалось. Не было, что ли, толчка (в хорошем смысле этого слова). Знаете, как это обычно происходит – пока не наболит, вроде бы и не о чем особенно говорить =). Недостаток общения на тему Delphi скрашивают коллеги, форумы, просмотр теленовостей =). Да и не то, чтобы не о чем писать – чувствуешь, что просто не зачем. Никто тебя не услышит и не исправит любимый баг =). Сразу вспоминается бородатый анекдот про человека, который пришел к доктору и жалуется:
- Меня никто не замечает!
- Следующий!

Так вот тут ситуация другая. Нет у меня много свободного времени, чтобы решать проблемы других людей. Ведь согласитесь, что если у некоторой компании плохо продается продукт по причине каких-то недостатков, так это их, исключительно их проблемы. Мои проблемы возникают, когда я сам, за деньги покупаю их технологию, подсаживаю на неё целое предприятие, а потом ловлю глюки, толкаю, пихаю и тормошу поддержку чтобы она за мои же деньги решила не мои (хотя теперь уже мои) проблемы и заработала ещё больше денег, продавая более качественный продукт =).
Этот блог я назвал delphisex, хотя он мог называться как угодно, например GatesTrouble или OracleNightmare, потому что это проблемы индустрии в целом, а не отдельно взятого продукта. Но писать я буду про Delphi, преимущественно о нем и сателлитах, хотя, думаю, достанется всем. Все, что здесь написано, это только мое мнение, основанное, исключительно на опыте и моем миропонимании. Естественно, наверняка найдутся желающие оспорить это мнение – велкам. Для этого тут все и задумано.

PS. Надеюсь, все это дело не превратится ни в пиар, ни в холивар! =)