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

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

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

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

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

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

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

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

На 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-тесты к своему коду — окунувшись хоть на немного в процесс тестирования, разработчик изменяет свое мышление. В лучшую сторону. Даже простая мысль "как я буду тестировать этот код" ставит разработчика на ступеньку выше тех программеров, которые не задумываются об этом.

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

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

Сегодня гоняли тесты компонентов и обнаружили в логах "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() — функции инициализации объекта. Но дело-то уже не в ошибке.

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

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

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

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

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

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

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