суббота, 9 апреля 2011 г.

[prog] И еще раз на тему MxxRu и Ruby 1.9.2

Разработчики Ruby сделали странную штуку при выпуске версии 1.9.2 – изъяли текущий каталог из путей поиска подгружаемых через require rb-файлов (грубо говоря, в $: текущего каталога уже нет). За каким хером им это вообще понадобилось я понять не могу. С какого бодуна можно было решиться на нарушение совместимости с предыдущими версиями Ruby – тем более. И ладно бы они это сделали при выходе версии 1.9.0. Тогда еще было бы понятно. Все таки совсем новый релиз почти совсем новой версии (переход от 1.8 к 1.9 был более революционным, чем от 1.6 к 1.8). Но такой хитрый финт ушами при смене версии с 1.9.1 на 1.9.2 – это, мать их, сильно.

Что обидно: портировать сами исходники MxxRu и тесты на Ruby 1.9.2 оказалось совсем не сложно. Достаточно было в нескольких местах в require передавать не простое имя файла, а результат работы File.expand_path над этим именем. Так что MxxRu 1.5.4 уже в репозитории и под Ruby 1.9.2 работает. Но новая проблема вскрылась в проектах, которые MxxRu используют. Например, есть проектный файл:

require 'mxx_ru/cpp'

require 'oess_1/util_cpp_serializer/gen'

require 'aag_3/defs/version'

MxxRu::Cpp::dll_target {

   required_prj "oess_1/defs/prj.rb"
   required_prj "oess_1/stdsn/prj.rb"
   required_prj "so_4/prj.rb"
   required_prj "mbsms_2/prj.rb"

   target "aag.defs" + Aag_3::VERSION
   implib_path "lib"

В нем первый require загружает файл из самого MxxRu, поэтому отрабатывает нормально – MxxRu лежит в специальных путях поиска, контролируемых RubyGems. А вот в двух следующих обращениях к require задаются имена файлов относительно текущего каталога – т.е. относительно корневого каталога проекта. И вот тут-то наступает приплыздец: Ruby 1.9.2 не желает их находить.

При этом заставлять пользователей MxxRu править свои успешно работающие проектные файлы – не вариант. Так же, как и заставлять их делать какие-то специальные настройки для Ruby (вроде указания –I. в RUBYOPT). Нужно, видимо, докручивать что-то в самом MxxRu – вплоть до перехвата и собственной реализации require :)

На эту тему вспоминается совсем свежая история с проектом ACE – при выпуске версии 6.0.0 разработчики ACE удалили заголовочный файл OS.h, который был всего лишь скопищем #include-ов для файлов OS_NS_*.h. Да вот только разумность такого удаления для пользователей ACE оказалась далеко не очевидной. Настолько далеко, что своими вопросами “Какого хера?!!!” они вынудили вернуть OS.h при первом же обновлении ACE 6.0 – ace/OS.h is Back!

PS. Чем больше программирую, тем больше убеждаюсь, что совместимость – это очень и очень важная штука. Может быть одна из самых важных. Если не самая.

пятница, 8 апреля 2011 г.

[prog] MxxRu обновился до версии 1.5.3

Выпустил MxxRu 1.5.3. В этой версии добавлен тулсет vc10 для Visual C++ 10.0 (хотя ничего специфического по сравнению с vc9/vc8 в нем нет, работа с манифестами полностью сохранена).

Сделана первая попытка поддержки Intel C++ для Windows – новый тулсет icc_win. В моем распоряжении был только Intel Parallel Studio 2011, поэтому проверялся тулсет только на этой версии в паре с Visual C++ 10.0. Фактически, icc_win – это прямая калька с vc9, только имена компилятора, линкера и библиотекаря изменены. Linux-овой версии Intel C++ у меня нет, поэтому пока и нет планов на реализацию icc_linux.

Версия 1.5.3 протестирована только под Ruby 1.9.1. С Ruby 1.9.2 бороться пока времени не было. Так что после портирования на Ruby 1.9.2 выпущу следующую версию MxxRu. Но когда это будет пока не знаю :(

Взять новую версию MxxRu можно либо вручную с RubyForge, либо выполнив команду gem install Mxx_ru (для обновления с предыдущих версий следует выполнить gem update Mxx_ru).


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

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

четверг, 7 апреля 2011 г.

[prog] Походил по грабелькам при обновлении Mxx_ru

Давно не брал в руки шашек занимался своими Ruby-новыми проектами. Сегодня попробовал сделать коммит новой версии Mxx_ru в svn-овский репозиторий на RubyForge. Не прошла аутентификация. Там для коммитеров доступ осуществляется через svn+ssh. И вот ssh меня не пускает. Стал разбираться.

Во-первых, svn слишком большой диагностики не дает. Пишет что не получилось и все. И советует из опций ssh в svn-овском конфиге флажок –q убрать. Хотя его там отродясь не было. Опция ssh в конфиге закомментирована была:

[tunnels]
# ssh = $SVN_SSH ssh

Зато, если преобразовать ее вот к такому виду:

[tunnels]
ssh = $SVN_SSH ssh –v –v

то процесс подключения к серверу и взаимодействия с ним очень подробно отображается в stderr. Ключик –v для ssh вообще очень пользительная штука :)

Правда, по-началу, подробная диагностика от ssh причину проблем не показывала. Видно было, что мой ключ найден, но не видно было, чтобы ssh пытался его применить. К счастью, в Google я не забанен и поиск помог найти причину: если права доступа к ~/.ssh/identity даны не только владельцу, то ssh этот ключ молча игнорирует (по крайней мере, при уровне логирования debug2 ssh на этот счет не ругается).

Я пользуюсь ssh-ем из cygwin-а. И после смены рабочей машины содержимое ~/.ssh восстановил из архива. Видимо, не в cygwin-овском shell-е, а в Window-ом. Поэтому права на доступ к файлам ключей были даны всем. И это ssh-у не нравилось. Пришлось вспоминать параметры к chmod :)

Но и после chmod-а по ssh-у подключиться удалось не сразу. Точной причины я не понял. Мне показалось, что дело в несовпадении протокола SSH-протокола. У меня ssh по умолчанию он пытается использовать SSH v2. А на стороне диагностируется версия 1.99. После того, как я в /etc/ssh_config задал для узла rubyforge.org использование версии 1, сразу же удалось подключиться и залогиниться.

Еще года четыре назад я был с ssh-ем если не на “ты”, то хотя бы на довольно панибратском “вы”. А вот глядишь, прошло несколько лет и без man-ов с гуглем уже и старых настроек восстановить не могу :(

После того, как разобрался с svn-ом, начались приключения с ruby, rake и RubyGem-ами. При попытке заставить rake создать результирующий gem-файл, стал получать ошибку:

rake aborted!
193: %1 is not a valid Win32 application.   - c:/ruby19/lib/ruby/1.9.1/x64-mswin64_80/zlib.so

Windows у меня 64-битная. И Ruby 1.9.1 так же 64-битный. В нем изначально с дополнительными DLL-ками проблема была. Например, zlib.dll не было. Пришлось разыскивать где-то на стороне. Уже не помню где, но разыскал. А тут вдруг какая-то новая беда с zlib-ом. Причем не понятно, в чем именно проблема.

Пришлось ставить 32-битовую версию Ruby 1.9.1. В ней, правда, так же zlib.dll не оказалось. Но у меня с собой, что называется, было :) Поэтому все заработало. Только вот не могу понять, почему в официальные сборки ruby, которые лежат на ruby-lang.org, не входит тот же zlib.dll изначально? В каком-то стороннем One-Click Installer-е zlib есть, а в официальной сборке нет. Может это наследие Unix-овых корней ruby, где дистрибутив без уже установленного zlib еще поискать нужно?

По ходу дела наткнулся еще на одну неприятную штуку. В поиска решения проблемы с zlib.so поставил себе и Ruby 1.9.2. Попытался прогнать Mxx_ru-шые тесты. Но обломался. Мои исходники рассчитаны на то, что поиск подключаемых через require файлов происходит и в текущем каталоге. А вот в Ruby 1.9.2 эту фичу уже отключили. Зачем не понятно. Но понятно, что под Ruby 1.9.2 нужно будет Mxx_ru адаптировать отдельно :(

Да, и еще оказалось, что на ruby-lang.org 64-битовых Windows-сборок последней версии Ruby 1.9.2 нет. В общем, приключения продолжаются :)

среда, 6 апреля 2011 г.

[life.humour] Вот так пошутишь про йогу, а оно почти правдой окажется

Из топика раздела rsdn.humour “Однострочные улыбки”:

Как йоги делают клизму? Садятся в лужу и делают глубокий вдох

А ведь если заменить “вдох” на “выдох”, то данное утверждение окажется весьма близким к действительности :)

Есть в йоге такая штука, как “наули”:

После освоения которой особо продвинутые йоги могут рискнуть освоить “басти”:

Техника выполнения: Сесть в водоем (ванну) по пояс. Сидеть лучше на корточках. Расслабить мышцы тазового дна, выполнить брюшной жгут - вода вследствие создавшегося вакуума в кишечнике начнет стремительно заполнять его. Наберите воды сколько можете - и выпустите. И так до чистой воды. Если трудно расслабить анус, то йоги рекомендуют пользоваться трубочкой (в Индии йоги используют бамбуковую трубочку. У нас можно просто подобрать подходящую из подручного материала). Пользуясь трубочкой, некоторые йоги умудряются вытягивать воду из небольшой посудины или ведра, тогда нет необходимости садиться в ванну или водоем. Йоги утверждают, что при выполнении этого упражнения создается мощный энергетический поток снизу вверх, что на физическом теле можно отследить как поднятие воды вверх по кишечнику.

(взято здесь, “брюшной жгут” – это наули и есть)

Так что действительно, в каждой шутке есть всего лишь доля шутки :)

PS. В молодости пытался осваивать йогу, по книгам. И если с асанами и пранаямой дело шло более-менее нормально, но когда добрался до глав, посвященных очистительным процедурам вроде басти, то решил, что пора завязывать :)

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

вторник, 5 апреля 2011 г.

[prog.question] Нужны ли манифесты для VisualStudio 2010?

Пришло время добавить в Mxx_ru поддержку VisualStudio 2010. И встал вопрос: а нужны ли C++ным программам, скомпилированным VS2010, манифесты?

Манифесты были введены в VS2005 как очередной изврат Microsoft-а. Поскольку в MS решили, что негоже разрешать приложениям укладывать C/C++ runtime dll-ки прямо в свой каталог. Пришлось добавлять поддержку манифестов в Mxx_ru.

Теперь, насколько мне известно, в VS2010 отказались от ограничений по распространению C/C++ runtime dll. Можно их просто кинуть в каталог с программой и все будет работать так же хорошо как и в старой-доброй VS2003. Но поддержка манифестов в VS2010 оставлена (и инструмент mt есть, и файлы-манифестов он в приложение встраивает).

Вот я и в размышлениях: нужно ли в toolset-е Vc10 в Mxx_ru оставлять поддержку манифестов (например, для совместимости с тулсетами Vc8 и Vc9) или же нет.

Может кто-нибудь подсказать, обязательно ли использование файлов-манифестов при сборке C/C++ приложений в VisualStudio 2010?

понедельник, 4 апреля 2011 г.

[prog.work] Вновь о теме KPI для программистов

Сегодня получил очередной комментарий к довольно старой теме “Интересная дискуссия о KPI для программистов”:

Любой человек "очкует" когда его пытаются оценить. У программистов это явно выражено. Да, программирование сродни хотьбе по лабиринту, я соглашусь с этим. Но а что. работа менеджера по продажам не сложна? А работа врача? Почему-то для продавцов можно KPI разрабатывать а для программеров нет.

Я руковожу программистами и знаю как это непросто. Но я уверен, что "неоценивать" работу разработчиков нельзя. Должны быть критерии.

Вообще, судя по статистике, с поисковых сайтов по запросу “KPI программиста” ко мне в блог заходит изрядное количество посетителей (в Yandex-е по этой фразе я вообще затесался на третье место среди результатов, что свидетельствует, имхо, о крайней нераскрытости темы). Посему я решил дать ответ на комментарий в виде отдельной заметки.

Не могу объективно сравнивать критерии оценки работы программиста с другими областями деятельности, поскольку мало в них разбираюсь. Не имею понятия о том, как оценивается работа врача (опять же, какого – ведущего прием участкового терапевта или анестезиолога в кардиологическом центре?) И о том, как оценивают агентов по продажам. Слегка наслышан об оценке рабочих на производствах, где есть нормы выработки и нормативы на время производства конкретных изделий по конкретным спецификациям. Так же приходилось слышать об оценке научной деятельности по количеству публикаций статей/монографий и количеству докладов на конференциях (что так же не слишком тепло встречалось самими научными работниками).

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

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

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

Если же все не так радужно и с проектами беда, то нужно ли пытаться решить проблемы начиная с KPI самого нижнего слоя пирамиды – с разработчиков? Рыба известно откуда гниет. И если проект трещит по швам, то может лучше начать с другой стороны? Вдруг это кто-то там наверху выбрал сроки и бюджет из политических, а не реалистических соображений? Или проект был поручен горе-менеджеру, который знает очень много правильных слов и блестяще ораторствует на советах директоров, но не может донести до команды точные цели проекта и конкретные пожелания заказчиков? А если все руководство, включая непосредственно работающих с программистами тим-лидов, супер-пупер профессиональное, то как тогда получилось, что у них в подчинении совершенно бестолковые разработчики, не способные писать нормальный код?

Или может KPI нужен для того, чтобы размер зарплаты и премий рассчитывать? Если у Феди показатели по KPI на 15% выше, чем у Васи, то Федя получит премию, а Вася нет. Уж не в этом ли цель KPI?

Эту цель хотя бы понять можно. Однако, почему такой подход лучше, чем делегирование распределения премиальных конкретному менеджеру или тим-лиду? Тем, что объективнее? Да фигня это все! В управлении субъективизма изначально настолько много, что попытка подвести какой-то формальный базис под распределение премии выглядит… Как трусость она выглядит. Потому что если руководителю нужны какие-то формальные отмазки для ответа на прямой вопрос “Почему мне премию не дали?”, то руководитель этот такой же формальный.

Ну да все это лирика и риторика. Суть-то в другом.

Как ни крути, но руководителю все равно приходится оценивать своих подчиненных. Чтобы решать, кто и чем будет заниматься в очередном проекте. Кому можно поручить самые важные куски, кто будет заниматься рутиной, кто будет гоняться за злобными багами. Очень нужны оценки для предсказания сроков разработки. Поскольку Федя может сделать за месяц, а Вася за полтора. А Гена за две недели, но только если ему задача понравится.

Поэтому руководитель вынужден заниматься оценкой работы своих подчиненных. Пообещал Гена уложиться в две недели, а реально потребовалось три. Значит для его оценок нужно вводить коэффициент поправки 1.5, а то и больше. Уложился Вася в срок – хорошо, на баги затем пришлось десятками ловить, значит в следующий раз за Васей более серьезный присмотр нужен. Федя может сделать все быстро и качественно. Если не забудет и не отвлечется на очередной pet project. Поэтому для Феди нужно выделять по 15 минут в день для раздачи поджопников напоминаний.

Но все это проблемы руководителя. И пусть он сам выбирает для себя критерии, которые считает нужными. Подберет удачно – хорошо. Не подберет, команда перестанет работать, придется выдумывать что-нибудь другое. Нормальный процесс проб и ошибок. Который, однако, должен быть скрыт от программиста.

И именно это является основной мыслью данного поста. А именно:

Критерии оценки работы программиста не должны быть известны программистам.

Только так.

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

Зависит зарплата от количества строк написанного за день кода? Нет проблем – copy-and-paste. И нафиг мне два дня думать, как сделать что-то 10 строчками кода, если я могу за три дня написать то же самое в 1500 стоках говнокода.

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

Оценивается точность предсказания сроков? Отлично, будем их изначально завышать в 2*PI раза.

Почему так? Да потому что так! Я ведь не ящики с места на место таскаю. Мне нужно выдумать что-то, чего нет. Зачастую убив кучу сил и времени на то, чтобы выяснить, что же именно надо. После чего воплощаю это в коде и заставляю работать как нужно. И то, чего изначально не было вовсе, вдруг появляется и, зачастую, работает!

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