Цитата: Papadimoulis

Alex Papadimoulis о разработке корпоративного ПО (" Avoiding Development Disasters")

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

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

Грамотно спроектированная система, созданная на протяжении последних восьми–десяти лет не требует масштабной модернизации.

Использование OSS в своих разработках

В очередной раз пересортировывал гигабайты статей и заметок, собранных на моем жестком диске, и наткнулся на текстовый файл с некоторыми правилами использования Open Source Software в своих разработках. Думаю, здесь этой заметке самое место.

Когда ваш продукт обязан быть Open Source

- если вы изменяли чужой GPL-код или исправляли в нем ошибки;
- если расширяли функциональность GPL-кода добавляя свой код;
- копировали фрагменты кода из GPL-продуктов в свой код;
- использовали заголовочные файлы из GPL-кода;
- статическая линковка вашего кода с GPL-кодом или LGPL;
- динамическая линковка с GPL-библиотеками или LGPL;


Когда ваш продукт не обязан быть Open Source

- при использовании GCC для компиляции вашего кода;
- при использовании открытых стандартов (HTTP, TCP/IP, SOAP, POSIX и т. д.);
- при взаимодействии вашей программы с OSS с помощью командной строки, пайпов или сокетов;
- при использовании архитектуры ПО, изолированной от OSS.

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

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

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

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

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

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

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

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

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

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

Двойная загрузка 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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".)

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

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

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

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

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

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