среда, 22 июля 2009 г.

Новости из Франкфурта

Пришли новости из Франкфурта – Concept’ы убрали из черновика стандарта, при том, что идея Concept’ов была, так сказать, блокбастером этого стандарта. Зато должны теперь успеть в срок со стандартом.

Зато мелких изменений очень много; и судя по тому как легко эти изменения будет использовать, – влияние на C++ они окажут как бы не большее чем Concept’ы.

Официально о Concept’ах – “этой особенности языка надо ещё выстоятся”… Похоже не совсем знают, как адаптировать к другим “плюшкам” в срок. Это было видно ещё раньше – стандартная библиотека в версии на сентябрь не включала в себя шаблоны с применёнными к ним Concept’ами.

В большинстве применений Concept’ы позволяют просто получать более читаемые ошибки для template’ов на соответствие некоторому интерфейсу, но насколько же с ними было бы удобно это делать:

Для меня введение Concept’ов (в виде automatic "concepts", на котором настаивал
Страуструп) позволяло перейти к питонообразному подходу при работе с шаблонными
функциями и классами. – Получать такие же значащие сообщения об ошибках можно и
другим способом – хоть через попытки приведения к некоторому интерфейсу или
родительскому классу. Но всё таки отношения вида “работая с этим шаблоном вы
обязуетесь, что ваш объект соответствует некоторому интерфейсу и
обладает некоторыми свойствами”, удобней чем “работая с этим шаблоном вы
обязуетесь, что ваш объект реализует некоторый интерфейс”. Т.к. в 1-м
случае набор функций в интерфейсе можно получить от различных источников
наследования, а во втором случае надо наследоваться от обязательного интерфейса,
что порождает ненужную связь в архитектуре, да и усложняет работу вцелом.

Так что, ждём этого стандарта и готовимся к следующему, в котором Concept’ы уже надеюсь будут.

Ссылки по теме:

Саттер: http://herbsutter.wordpress.com/2009/07/21/trip-report/

Страуструп: http://www.ddj.com/architect/218600111?pgno=1

среда, 15 июля 2009 г.

4 уровня компетентности

The "Kirkpatrick Model" by Donald L. Kirkpatrick gives four levels of (increasing) competence:

  • Unconscious Incompetence = you don't know that you can't do it well.
  • Conscious Incompetence = you know you can't do it well.
  • Conscious Competence = you do it well, and you think about the work as you do it.
  • Unconscious Competence = you're so successful it's "automatic" -- you do it well, without thinking about it.

    Красиво сказано… На текущих задачах скорее на 3-м уровне со значительным сдвигом в сторону 4-го. Хотя управленческая часть работы - это скорее 2-й уровень и может изредка 3-й.

  • четверг, 9 июля 2009 г.

    Python декораторы

    Казалось бы всё просто: декораторы – это просто статические фукции.

    Но ведь это функции, а в функции вполне можно передавать различные параметры… Причём не обязательно это должны быть константные значение либо имена типов (как пользуются декораторами почти везде). В декоратор можно передать значения считаные из файла настроек; главное, чтобы значение было определено до того как объявляется применение самого декоратора к функции. Для примера декоратор @measures получает на вход 3 разных значения, а значит функции linerFib, linerFib1 и stubFib будут “обрамляться” разными строками.

      1: teststring = 'test1'
     2: teststring1 = 'test2'
     3:  
     4: ...
     5:  
     6: @measures(teststring)
     7: def linerFib( n ):
     8:     fn = f1 = f2 = 1
     9:     for counter in xrange(2, n):
     10:        fn = f1 + f2
     11:         f2, f1 = f1, fn
     12: return fn
     13:  
     14: @measures(teststring1)
     15: def linerFib1( n ):
     16:     fn = f1 = f2 = 1
     17:     for counter in xrange(2, n):
     18:         fn = f1 + f2
     19:         f2, f1 = f1, fn
     20: return fn
     21:  
     22: teststring1 = 'test xxx'
     23: @measures(teststring1)
     24: def stubFib( n ):
     25:     return 5

    Но если бы всё только этим и ограничивалось… Самое интресное наступает, когда понимаешь, что декораторы могут возвращать и лямбда-функции. А ещё интересней становится, когда доходит что через лямбда-функцию можно вернуть не результат самой декорируемой функции, а экземпляр объекта, в котором есть метод __call__() , который и будет возвращать результат декорируемой функции. Да - это кажется перебором с вложеностью матрёшек, но вот с логической точки зрения провести разделение подготовки к вызову декорируемой функции и пост-обратотку её результата кажется довольно аппетитным… Т.е. можно провернуть следующее:

     1: class Drawer(object):
     2: def __init__(self, func, test):
    # подготовка и инициализация для вызова декорируемой функции
     3:     self.func = func
     4:     self.test = test
     5:  
     6: def __call__(self, *args):
    # сам вызов
     7:     print self.test
     8:     return self.func( *args )
     9:  
     10: def measures(test):
     11:     return lambda func: Drawer(func, test)

    Да, в большинстве случаев это будет довольно избыточно, но когда хочешь выводить график декорируемой функции в pygame, при этом не смешивая вывод результата на экран и расчёты и обработку результатов функции, то такие матрёшки становятся вполне удобными.

    вторник, 30 июня 2009 г.

    Защитное программирование

    Чтобы не забыть и чтобы было куда посылать...

    Часть мыслей честно утащена у Эккеля и других авторов, здесь сведено в одну таблицу и отражена суть что и где применять. Вопрос “когда применять” не рассматривается, ибо не корректен – применять надо всегда.

    Есть 3 вида конструкций для защитного программирования: исключения, assert’ы и проверки. Применять при:

      Исключения assert’ы логические проверки
    взаимодействия с внешними системами и сторонними модулями да нет да
    создание новых объектов да нет нет
    своя логика нет да да
    проверять юнит тестами поведение? нет да да
    оставлять в релиз версии да ? да

    Взаимодейстие с внешними системами/модулями – не известно, что там может произойти, как организован код сообщающий о ошибочных результатах и насколько безопасно сторонний код написан, потому лучше закрыть try/catch блоками для безопасности. Иногда для проверки результата действий может хватить и кода ошибки. Хотя проверять, что тебе отдали валидные данные, всё равно надо.

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

    Своя логика – проверять что ты ничего вредного или чудного не передаёшь внутрь.

    С юнит тестами связан следующий момент: 
    все три конструкции должны проверять только важное на данном этапе, а не всё подряд – иначе это может привести к сложностям при написании юнит тестов. Подробней смотреть link.

    Оставлять в релиз версии – а вот тут есть разные мнения. Начиная от сравнения “ходить по суше в спасжилете, а перед выходом в море снимать его” и заканчивая “не нужно нам неконтролируемое падение системы”. Пмм, на этапе тестирования лучше иметь ассерты – более заметны, а соответственно лучше стимулируют исправление; а вот на этапе установки у заказчика лучше иметь логические проверки с логированием.

    пятница, 26 июня 2009 г.

    Новый Qt

    Вышел новый Qt/Qt Creator...

    По функционалу стремительно догоняет Visual Studio/Eclipse/NetBeans. А учитывая возможность интеграции в 1-е 2 упомянутых продукта, то появляется реально хорошая альтернатива Visual Studio и Eclipse при кросплатформенной разработке на C++.

    LGPL как базовая лицензия очень большой плюс для корпоративных кастомеров, по сравнению с предыдущей лицензионной политикой и текущей политикой от Майкрософта.

    Навязывание MVC/MVP как базового шаблона при построении архитектуры уже даёт большой плюс в усилении скилов сообщества разработчиков.

    А наличие биндингов для явы и питона ещё и приманивает соседей :)

    Интересно, ещё у кого-то остались сомнения о полезности покупки TrollTech Nokia'ей?

    среда, 10 июня 2009 г.

    Оценки времени выполнения задачи

    У Брюса Эккеля в его "Философии C++" натолкнулся на замечательную оценку времени необходимого для выполнения задачи:

    "Прикиньте, сколько времени потребует ваш проект, затем удвойте это число и прибавьте еще 10 %. Скорее всего, ваше внутреннее ощущениевас не подводит; вам действительно удастся получить нечто работоспособное за это время. Еще столько же времени уйдет на то, чтобы привести это «нечто» к более или менее приличномувиду, а последние 10 % уйдут на шлифовку и всякие мелочи...

    В последнее время мнение автора по этому вопросу изменилось. Удвоение и прибавление 10 % дает довольно точную оценку (при небольшом количестве непредсказуемых факторов), но чтобы уложиться в это время, необходимо прилежно работать. Если вы захотите сделать программу элегантной и получить удовольствие от своей работы, лучше умножать на 3 или на 4."

    Собственно это классическая оценка с помощью числа Pi : "возьмите вашу оценку времени выполнения задачи и умножьте её на Pi, при этом Pi в зависимости от опыта может колебаться от 1,5 до 4"... :) Просто не ожидал её встретить у “самого Брюса”.

    Хотя для понимания откуда берётся это Pi в реальной оценке, лучше посмотреть следущее сообщение с rsdn.ru. Оно как-то более точно позволяет оценить время на выполнение задачи. Сам уже начал пользоваться этими пунктами :)

    Теперь разберем из чего состоит задача.
    1. Если код незнакомый, знакомство. Понимание через отладку. Если нужно рефакторинг. Понимание через рефакторинг.
    2. Проектирование нового функционала. Подробное. А не в уме, как на совещании было.
    3. Подготовка кода к внесению изменений. Опять рефакторинг.
    4. Собственно кодирование. Говорит неделя, ну так 40 часов и запишем. И это только на пункт 4. А вы говорите 16-32.
    5. Интеграция с остальным кодом. Это то что в пункте 3 делали, но теперь уже начисто.
    6. Тестирование (в это время можно программеру дать другое задание), либо дать на проверку код
    соседа, попросить отревьювить код и т.д. Опять же старые баги есть наверно.
    7. А теперь откровение. Оказывается после тестирования надо баги поправить. Иначе зачем тестировать-то. А потом снова на тестирование и снова баги.

    Ну допустим у меня один баг в неделю на 20 коммитов. Но это в неторопливой обстановке. А ктоме того еще штук десять в неделю "not a bug" и половинка "a change request"

    Далее пункты выполняемые совместно с остальными:
    8. Покрытие тестами.
    9. Документирование.
    10. Коммуникации с коллегами по работе, совещание.
    11. Коммуникации с начальством, отчеты, совещания.
    12. Чтение проф литературы, блогов, RSDN и т.д.
    13. Перерывы на отдых, чай, сигареты (кто курит), поболтать на различные темы.
    14. Обязательно поболтать с любимой/любимым по ICQ.

    А теперь начинаем думать. Я тут 14 пунктов перечислил, а программист (и я тож из таких) думает только про пункт 4.
    Причем если вам пункты 12 - 14 не нравятся, то программистам, да и вообще здоровым людям, они необходимы. За пункт 14 вообще перегрызу горло

    C++0x и NetBeans

    Не совсем понравилось экпериментировать с возможностями нового стандарта С++ на Eclipse, а потому до сих пор искал альтернативу. Реальных причин для отказа было 2, хотя уже сейчас могу придумать значительно больше:

    1. Неудачно выбраный порт с GCC: зачем выбрал Cygwin до сих пор понять не могу. Наверное сыграл инстинкт пользователя :), который долго воспитывали в Windows - "больше весит - значит лучше".
    2. Глюки. Как-то непривык при входе в отладку простого приложения наблюдать креш среды разработки.
    Ну и немного смущала заторможеность реакции среды на действия и слабая подсветка синтаксиса и подстановок по сравнению с Visual Studio/Visual Assist.

    Сейчас вроде бы нашёл альтернативу, где смогу вволю поэкспериментировать. Инструкция для тех, кому, возможно, будет интересно поиграться с C++0x на NetBeans в Windows.

    1. Скачать и установить NetBeans IDE у кого эта IDE ещё не стоит или добавить плагин C++ в уже установленую NetBeans IDE (http://www.netbeans.org/)
    2. Скачать MinGW порт c GCC версии 4.4. Выбрал MinGW, потому что он действительно min - весит меньше, а работает быстрее. На официальном сайте MinGW к сожалению последняя стабильная версия GCC ещё 3.4.5, кандидат 4.3., а нам нужна 4.4, в которой и сделана основная реализация фич из C++0x. Можно с взять с http://www.tdragon.net/recentgcc/ уже собраное с windows installer, а можно в классическом unix-way собрать самому из исходников - тут уж у кого как душа поёт.
    3. Также необходимо скачать и установить MSYS последней версии - сайт MinGW тут уже сможет помочь. Необходимо это, потому что NetBeans не дружит с MinGW make идущим в MinGW по умолчанию, да и на сайте MinGW настоятельно рекомендуется использовать make из MSYS.

    Теперь займёмся настройкой IDE:

    1. Запустить NetBeans IDE
    2. Выбрать Tools/Options/C++
    3. на закладке Build Tools настроить
    4. mingwsettings.JPG
    5. На закладке Code Assistance для C Compiler и C++Compiler надо нажать Reset settings для того, чтобы NetBeans IDE подхватило последнюю версию g++, а не расположеную в корне инсталяции MinGW. Почему не подхватить эти пути сразу - не знаю, наверное надо выделяться как-то на фоне Microsoft.
    6. migwincludes.JPG

    Общие настройки IDE закончены - остались только изменения в проекте.

    Теперь заголовки версии 4.4 подключаются в проект, но почему-то вся функциональность будущего стандарта не работает. Причина в том, что GCC требует включать эту поддержку дополнительной опцией, что в целом разумно, т.к. C++0x это ещё не утверждённый стандарт и работа с ним чревата изменениями, а потому строить production код на нём вряд ли кто-то будет. Выбрать настройки C++ проекта, перейти на группу C++ Compiler и поставить ввести "-std=gnu++0x" в Additional Options.

    среда, 13 мая 2009 г.

    Мысли о фишках C++0x

    Прочитал тут материалы проходящего БустКона и подумалось:

    Сейчас много идёт обсуждений о том, что будет реализовано в новом стандарте: лямбды, статические ассерты, концепты, аспектное программирование, rvalue references, variadic templates, новое поведение цикла for  и т.д. и т.п.

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

    • auto типизация - не морочим голову с тем как же пишется определения возвращаемых итераторов и лямбд, и смерть применению auto для локальных переменных;
    • списки инициализации - наконец-то простое заполнение контейнеров;
    • лямбда-функции и новое поведение for/for_each - перестаём ломать голову с функторами в обощённых алгоритмах;
    • строгая типизация enum - нет извращениям в преобразованиям к целочисленным типам и назад при работе с enum;
    • shared_ptr - garbage collector уже рядом.

    Эти "мелочи" за счёт своей легкости применения и чрезвычайно малого порога вхождения окажут наибольшее влияние на пишущих на C++. А вот тяжеловесные "новости" окажут очень слабое влияние - просто потому, что их будут применять чрезвычайно редко. Вон аспекты уже года 4 есть в C# - а как много людей пишет с их применением? Так что простота продолжит управлять миром.

    Вот если бы работу с шаблонами сделать ещё проще, то с помощью вариативных шаблонов, можно было бы грохнуть, наконец, макросы, несущие функциональную нагрузку окончательно. А сколько они крови попили...

    PS

    Вот интересно, как концепты уживутся с range'ами, которые начинает продвигать Александреску?

    вторник, 5 мая 2009 г.

    книга "My Job Went to India"

    Закончил чтение "My Job Went to India" Chad Fowler.

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

    А глава "If You Can’t Beat ’Em" достойна отдельного упоминания, т.к. показала причины проблем комуникаций с заказчиками в offshore программировании - честно говоря не ожидал такого хорошего разбора полетов. Сколько же наступал на эти грабли...

    Может кризис сказался, может мое общепасмурное настроение, но впечатление осталось депресивное от книги. Хотя книги в целом из серии обязательных к прочтению. Жаль что её перевод выйдет не скоро, а если и выйдет, то будет классическим тяп-ляпским.