[prog.thoughts] Развернутый ответ SleepyDrago по поводу наезда на Boost-оводов

Как уже не раз бывало, начал писать ответ в комментариях, но текст получился слишком большим для комментария, поэтому появилась данная заметка. Итак:

2Евгений:
наезды на бюст не понятны. Они нам ничего не должны ;)
Я вот могу сказать что я рад что я вообще не смотрел на bjam, несколько spirit'ов, кучу мета-, boost.preprocess и кучу мелких. Ну и ? это не значит что кому-то оно не пригодилось. Более того я рад что ничего не знаю про poco,ace, rubygems :)
а из комментария jazzer'а мне понятно что я ничего не узнаю про этот риппл ))

ps Про bjam например стало очевидно когда те, кому надо билдить много, померяли и обсудили его перформанс.

Ну на меня иногда находит... Ведь C++ совсем не плохой язык. Какие-то вещи на нем делать намного приятнее, чем на Java, скажем. Но, поскольку мне приходится работать на C++, то жалко смотреть на то, что он уже довольно сильно ушел от мейнстрима. Т.е. продуктов на нем делается много, но вот молодых программистов, которые бы умели программировать на C++ становится все меньше и меньше. Такое впечатление, что многие просто не хотят связываться с этим старым монстром.

А ведь ситуацию можно есть не исправить, то хотя бы улучшить. Да, проблемы языка никуда не денутся. Все равно ноги будут отстреливаться, а C++ные программисты будут проводить ночи в поисках запорченных указателей. С этим ничего не поделать (кроме как выправлением кривых рук). Но вот работу с библиотеками улучшить можно. Сейчас чтобы поставить OpenSSL нужно взять Perl, выполнить по инструкции настройку OpenSSL, потом скомпилировать, потом прописать пути. А если приходится работать с разными компиляторами на одной платформе – то проделывать это несколько раз. Установка Boost-а – своя история, установка Qt – своя. И т.д.

И это не касается языка (т.е. язык накладывает свои ограничения, но это уже просто исходные условия для решения задачи) – это касается инструментов, которых почему-то нет. Хотя лично мне они нужны. И, думаю, нужны они не только мне. Ну а если инструмент нужный, то должен же он когда-то появится.

А теперь представим, что какие-то инструменты для дистрибуции C++ных библиотек появились. Штуки три. От Васи Пупкина, Джона Смита и Кумара Гашишовава. О каждом из которых знает человек двадцать-тридцать друзей и коллег авторов данных инструментов. Какие шансы у этих разработок, даже если они удобны и качественно сделаны, стать настоящим мейнстримом в C++ коммунити? Очень маленькие, имхо.

Совсем другое дело, если бы велосипед по дистрибуции библиотек появился в составе Boost-а. Это как iPhone от Apple – как телефон фигня, зато какой ажиотаж! Еще пример: я слышал, что многим не нравится qmake из Qt. Но им пользуются, поскольку это штатный инструмент для Qt.

Так вот, если бы Boost выпустил что-то вроде RubyGems для C++ – это было бы очень и очень знаковое событие. Что радует, Boost-оводы сами осознали необходимость такого инструмента. Кроме того, Boost-оводы позиционируют себя как активные развиватели C++ – это же их цель – отбирать новые библиотеки для включения в следующий стандарт C++. Ну так почему бы не заложить в стандарт и систему пакетов/библиотек для C++ (тот же RubyGems уже входит в стандартную комплектацию Ruby 1.9)?

Т.е. Boost действительно никому ничего не должен. Но я не вижу другой настолько же авторитетной консолидирующей организации в C++ коммунити, которая бы смогла такой инструмент протолкнуть в жизнь. Разве что Qt, но Qt – это вообще отдельный континент на планете C++, со своими законами и целями. То, что хорошо для Qt-шников не обязательно хорошо для остальных C++ников.

Ну а коль уж Boost-оводы начали делать ryppl, то хотелось бы, чтобы он подошел не только Boost-оводам. Но и всем остальным C++никам, которые не хотят или не могут использовать Boost, или же ведут свои проекты совсем по другим правилам, чем Boost. А у меня сложилось впечатление, что этого-то и не будет. Пока все похоже на bjam.

PS. Чувствую себя обязанным ответить на вопрос “А самому слабо?” Честно скажу – слабо. Я пытался изобрети такой велосипед. Но на его воплощение в жизнь не было ресурсов. Оказалось проще воспользоваться средствами Subversion, о чем я рассказал когда-то в статье. С тех пор именно этим способом мы и пользуемся. Даже сторонние проекты в репозитории укладываем и стараемся адаптировать их к нашей системе сборки (ACE, POCO, PCRE, Crypto++, libcurl и пр.). Но все это не работает, когда приходится публиковать SObjectizer и сопутствующие ему библиотеки. Пока мы мало их публикуем и эта проблема не сильно меня волнует. Но теперь появляются ресурсы для дальнейшего развития SObjectizer и проблема вновь оказывается актуальной. Нужно что-то искать или делать. Может быть, будем что-то делать. Но это уже не только от меня зависит.

[prog] ACE обновилась до версии 5.7.8

Вышла новая версия библиотеки ACE – 5.7.8. Из основных изменений:

• В реализации ACE_Atomic_Op для типов short, unsigned short, long, unsigned long, int, unsinged int и bool теперь используются GCC-шные атомарные операции. Что увеличивает скорость работы ACE_Atomic_Op до семи раз.
• Фреймворк ACE Service Configurator выполняет сперва команды из svc.conf, а уже затем заданные в командной строке. Т.о. аргументы командной строки могут изменить настройки, заданные в svc.conf.
• ACE_Dev_Poll_Reactor теперь выполняет диспетчеризацию нотификаций только в одной нити за раз. Что делает поведение различных Reactor-ов более однообразным.

Плюс еще несколько улучшений и багфиксов.

Соответственно, до версий *.7.8 обновились TAO и CIAO.

Скачать можно отсюда: http://download.dre.vanderbilt.edu/

Disclaimer: мопед не мой, я только дал объяву.

[work] Работа в Гомеле: одно место для C++ программиста, одно для технического писателя

Если вы ищете хорошую работу в Гомеле, то попробуйте свои силы у нас. Я ищу C++ разработчика и технического писателя.

В качестве C++ разработчика разыскивается толковый и ответственный программист, способный к обучению и самостоятельной работе. Это может быть как начинающий C++ программист (тогда речь будет идти о стартовой зарплате в $400), так и опытный C++ программист (тогда размер оплаты будет стартовать с $1000), так и не очень опытный, так и очень опытный C++ программист – тут уж разговор будет идти о несколько других деньгах.

То, что мы хотим видеть в идеале, описано здесь: [work; prog.c++] Ищу людей в свою команду (С++ программистов, в Гомеле). Но, если вы по каким-то критериям не попадаете в идеал, то это не повод не попробовать :)

Порядок остается прежним: вы присылаете резюме, я вам отсылаю тестовую задачу, вы присылаете решение, мы проводим собеседование.

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

Зарплата технического писателя будет стартовать с рубежа в $300-400, по результатам собеседования и испытательного срока.

Порядок для получения работы на должность технического писателя следующий: вы присылаете свою резюме к которому прикрепляете небольшой (на 2-3 страницы) документ. Этот документ и будет тестовым заданием. Документ должен содержать два раздела – первый раздел о том, какими проектами вы занимались в последние полгода, а второй раздел о том, как выглядит ваш обычный рабочий день. Получив от вас резюме и этот демонстрационный документ, мы проводим собеседование.

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

Так что присоединяйтесь! ;)

Координаты для связи: eao197 на intervale тчк. ru и, обязательно, копию на eao197 на gmail тчк. com (чтобы спам-фильтр не заблокировал ваше письмо).

[prog.sobjectizer] Первые наметки к sysconf_3

При разработке SObjectizer-приложений, одной из самых востребованных SObjectizer-овских библиотек оказалась библиотека sysconf. Эта библиотека позволяет собирать приложение из различных DLL как из кирпичиков. Благодаря этому при разработке нового проекта прикладная функциональность разрабатывается в виде новой DLL (нескольких DLL), к которой добавляется еще 5-10 уже готовых, написанных и протестированных ранее компонентов. Например, компоненты для логирования, сбора и распространения мониторинговой информации, организации коммуникационных каналов, маршрутизации сообщений в распределенных приложениях и пр.

Библиотека sysconf была самой первой написанной для SObjectizer-а библиотекой, ее первая версия, sysconf_1, появилась летом 2002-го года. Вторая версия, sysconf_2, если мне не отшибает память, была написана через год. С тех пор sysconf_2 плавно эволюционировала и добралась до версии 2.4.2.

Думаю, что теперь пришло время для создания третьей версии sysconf-а. Чтобы устранить проблемы, которые были заложены в sysconf_1 и sysconf_2 при рождении.

Во-первых, нужно устранить объявление coop_handler-ов и coop_factory в виде глобальных переменных. Поскольку:

• это ведет к проблемам. Т.к. действия по регистрации coop_handler/coop_factory выполняются в конструкторах глобальных переменных во время инициализации загруженной DLL, то это может приводить к тупикам. Поскольку не рекомендуется из DllMain выполнять взаимодействие с другими нитями приложения;
• затрудняет процесс обработки sysconf-скрипта. Sysconf сейчас вынужден загрузить DLL, потом перейти в режим ожидания сообщений от конструкторов coop_handler/coop_factory, а потом возобновить свою работу с точки останова;
• затрудняет процесс создания GUI-инструментов, которые бы показывали состав компонентов в DLL и позволяли пользователю запускать/останавливать компоненты.

Пока идея заключается в том, чтобы DLL экспортировала специальную функцию, возвращающую описания всех coop_handler/coop_factory из DLL. Тогда sysconf после загрузки DLL находит эту функцию через GetProcAddress, вызывает и получает готовое описание. Данное описание будет использоваться sysconf-ом для формирования списка доступных компонентов. Так же это описание смогут использовать внешние GUI-инструменты для отображения данной информации пользователю.

Предполагается, что данная функция-описатель будет возвращать ссылку на статические описания. Т.о. не будут возникать тупиковые ситуации при загрузке DLL, т.е. никакой сложный код в DllMain запускаться не будет.

Во-вторых, нужно упростить формирование sysconf-скриптов. Сейчас, чтобы создать sysconf-скрипт для нового приложения, приходится прибегать к технике copy-paste. Т.е. находится какой-нибудь подходящий, написанный ранее для другого проекта скрипт и он модифицируется для нужд нового проекта. Что не есть хорошо, поскольку это и ошибками черевато, и временами ведет к загрузке совершенно ненужных для конкретного проекта DLL.

Текущая идея состоит в том, чтобы для каждой sysconf-овской DLL разработчиком был создан некий файл описания (например, с жестко заданным именем module.sysconf). В этом module.sysconf будут описаны все coop_handler/coop_factory из DLL и, возможно, какая-то дополнительная информация (например, зависимости от других модулей). Думаю, будет удобно, если и упомянутая раньше функция, возвращающая sysconf-у описание DLL, будет генерироваться в compile-time из module.sysconf.

В sysconf_3 будет включен инструмент (желательно с GUI), который просканирует все имеющиеся в проекте module.sysconf файлы и выведет пользователю их список с дополнительной информацией. Пользователю останется только отметить нужные ему компоненты и инструмент сам сформирует sysconf.cfg с учетом зависимостей выбранных модулей.

[prog] Ten years from now – предсказания Бертранда Мейера о будущем программирования

Автор языка программирования Eiffel, Бертранд Мейер, опубликовал слайды своей презентации “How you will be programming in 10 years” с конференции ACM Symposium On Applied Computing. Позволю себе процитировать один из слайдов. Итак, каким же будет программирование через 10 лет (стр.9):

1. We will still be using O-O languages
2. Professional programming will be far more rigorous
3. Verification will be integrated in the development process
4. Every program will have a Web interface
5. Concurrency will be ubiquitous
6. More reliance on objective assessment
7. Software engineering: not just process but technology

Или, в моем приблизительном переводе:

1. Мы все еще будем использовать объектно-ориентированные языки.
2. Профессиональное программирование будет намного более суровым.
3. Верификация будет частью процесса разработки.
4. Каждая программа будет иметь Web-интерфейс.
5. Конкурентное программирование будет повсюду.
6. Большую роль будут играть объективные оценки.
7. Разработка программ будет не просто процессом, а технологией.

Тут нужно пояснить, что Мейер разделяет нынешнее программирование на три категории:

• от случая к случаю (casual): разработка простых веб-сайтов, Excel-евских документов и пр.;
• профессиональное: Ынтерпрайзные системы, моделирование, системы мягкого реального времени и пр.;
• критически важное: системы управления транспортом, системы жизнеобеспечения, системы жесткого реального времени и пр.

Так что, похоже, слова Мейера не касаются большого числа PHP и Ruby-On-Rails программистов, создающих Web-сайты за 3-4 дня. Вот какими он видит профессиональных программистов в будущем (все та же стр.9):

- Higher level of qualification (более высокий уровень квалификации)
- Apply verification techniques routinely (применяют верификацию программ в повседневной практике)
- Not mathematics PhDs (не имеют ученых степеней в математике)

Ну и в продолжение недавних дебатов о роли и месте IDE – слайд, который демонстрирует, во что превратиться разработка по мнению Мейера. Не сложно заметить, что специализированная IDE занимает в ней центральное место (тогда как разработчик в прямом смысле слова находится в стороне):

[work] Хотите получать в Гомеле $1000+ за C++?

Если вы хорошо владеете C++ и хотите получать в Гомеле достойную зарплату, то приглашаю вас в свою команду.

Высылайте мне свое резюме (eao197 собака intervale точка ru и копию на eao197 собака gmail точка com), я пришлю вам условие (несложного) тестового задания. Через два дня вы должны прислать его решение на C++ в виде исходного текста. Если ваше решение засчитывается, вы приходите на собеседование.

Подробное описание вакансии и рекомендации по написанию резюме здесь: [work; prog.c++] Ищу людей в свою команду (С++ программистов, в Гомеле).

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

[life.cinema] Очередной кинообзор

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

---

Отсмотренные фильмы

Кандагар. Мне не понравился. Фильм держится только на актерах и операторской работе. Сюжета в нем нет. И, говорят, показанное в фильме не очень соответствует действительности, что так же не добавляет фильму симпатий.

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

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

Репортаж 2. Неплохой фильм. Не такой забористый, как первая часть, но зато здесь все концы срослись – стало понятно, что от чего и почему.

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

Перси Джексон и похититель молний. Красочная и качественно снятая по мотивам древнегреческих мифов сказочка для детей младшего школьного возраста.

Паранормальное явление. Это не такое сильное разочарование, как Ведьма из Блэр, но все равно хорошее подтверждение того, что хорошая вещь дешевой быть не может. Фильм снят за $15K и это видно. Даже в сюжете. По ходу фильма не столько пугаешься разным проявлением демона, сколько поражаешься тупости и нелогичности действий главных героев.

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

Остров проклятых. Очень серьезный фильм. Еще за 20 минут до его завершения я ожидал фокуса, похожего на то, что было в "Играх разума". Что-то похожее и случилось. Но потом пошла такая чернушная трагичность, что лично у меня возник вопрос – зачем вообще такое было снимать. Так что фильм, не смотря на всю его качественность, мне не понравился.

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

Повелитель бури. Сам я в армии не служил, на войне не был. Но почему-то не верится мне, что при разминировании снайпера будут что-то долго кричать подозрительному арабу, а не пристрелял его сразу же. И не верится мне, что попав под обстрел и потеряв половину своих группа спецназовцев трусливо заляжет в канаве и не будет выглядывать оттуда. Ну и весь фильм из таких вот моментов, про которые думаешь “да не может быть!”

О чём говорят мужчины. Хорошая и добрая коммедия. По своему уровню на две, а то и больше, головы выше всяких "самых лучших фильмов" и "наших раш". Посмотрел с удовольствием.

---

Об Оскаре 2010-го

В марте 2010 невозможно обойти стороной вручение Оскара фильму “Повелитель бури”. Сам фильм мне не понравился. После просмотра стало понятно, что ему был вручен Оскар только за то, что сняла его бывшая жена Кэмерона. Решение настолько же непонятное и парадоксальное, как и присуждение Нобелевской Премии Мира Бараку Обаме.

---

О фильмах, снятых “от первого лица”

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

---

О неграх и политкорректности

Слышал много разговоров о том, что в США пышным цветом цветет политкорректность, уже давно проникшая в кино. Мол, нельзя делать положительных героев сплошь белыми, а отрицательных – сплошь неграми. Обязательно в число героев нужно взять негра, еще лучше сделать его самым главным героем.

Вот фильм “Инкассатор”, похоже, является очень тонким стебом над всей этой политкорректностью. Главный положительный герой там негр. Т.е. формально все требования негласной голливудской цензуры соблюдены. Но главный герой при этом такой мудила, что он воспринимается скорее главным отрицательным героем. По его вине погибли все его несостоявшиеся подельники, сгорело (как я понял) 40 миллионов долларов, тяжело ранен полицейский, набили морду младшему брату героя, уничтожили две инкассаторские машины… Зато он честный, отказался от совершения преступления. Такой хороший, умный, со всех сторон положительный. Но лично у меня появились мысли о том, а не является ли тупость отличительной чертой какой-нибудь отдельной расы? ;)

[prog.flame] Нецензурный поток слов в адрес проекта Девида Абрахамса под названием ryppl

В комментариях к предыдущей заметке ув.тов.Sanik дал ссылку на анонс, сделанный Девидом Абрахамсом в предверии BoostCon. Мол, на конференции мы представим новый тул (http://www.ryppl.org/), который революционным образом изменит подход к разработке не только Boost-а, но и OpenSource вообще.

Глянул только что на описание этого ryppl-а. В результате чего родился следующий нецензурный поток.

[prog.thoughts] О C++ных библиотеках вообще, и о Boost-е в частности

Попрограммировав недавно на Java, я понял “в чем сила” Java – в IDE и библиотеках. Поскольку IDE без библиотек мало чего стоит, то получается, что самым главным достоинством Java является огромное количество готовых библиотек. Но не только наличие, а еще и простота, с которой сторонние библиотеки подключаются к Java-проектам. Берешь jar/zip файл, прописываешь его в CLASSPATH и все. А с использованием Maven2 даже об этом думать не нужно – достаточно включить упоминание нужной библиотеки в список зависимостей проекта и сам Maven2 скачает ее, установит и пропишет в CLASSPATH (eao197: впрочем, Maven2 видел очень издалека, поэтому могу идеализировать).

Нам, C++никам, такая простота подключения чужой библиотеки даже не снилась. И это не есть хорошо. Следует что-то подправить в консерватории и идущий ниже текст будет описанием моих мыслей о том, “как нам реорганизовать Рабкрин”.

Прежде всего, в C++ не будет такой легкости подключения скомпилированных версий библиотек, как в Java. Все-таки, в Java стандартизированный байт-код, а в C++ множество несовместимых между собой компиляторов на разных платформах. Более того, скомпилированные даже одним компилятором, но с разными опциями, obj-файлы нельзя безопасно использовать в рамках одного проекта.

Поэтому напрашивается первый вывод: C++ные библиотеки должны распространятся в виде исходных текстов.

Конечно, есть множество закрытых библиотек, разработчики которых никогда не захотят открыть исходные тексты. Ну да и фиг с ними, не о том речь. Речь о библиотеках общего назначения – для работы с датой/временем, регулярными выражениями, таймерами, сокетами и другими видами IPC, FTP/HTTP/SMTP/POP3/IMAP и пр. транспортами и т.д., и т.п.

Раз C++ные библиотеки распространяются в виде исходников, значит пользователю придется их компилировать. А раз так, то все библиотеки должны поддерживать какую-то единую систему настройки и сборки на машине пользователя.

Единая система сборки должна быть кроссплатформенной и легкой в изучении/использовании. Исключительно Unix-овые Autotools, а так же заточенные под конкретный компилятор и make-утилиты Makefile идут в топку. Лично мне хотелось бы, чтобы build-tool сам управлял сборкой (как делает SCons), но вполне бы устроил меня и генератор проектных файлов вроде CMake или MPC.

Но всего этого мало. Еще нужна система дистрибуции библиотек и отслеживания зависимостей между ними. Что-то вроде Maven2-репозиториев или RubyGem-ов. Например, я публикую в каком-то репозитории свои проекты cpp_util-2.5.0 и cls-3.1.0, причем cls-3.1.0 зависит от cpp_util-2.5.0. Если кто-то захочет использовать cls-3.1.0, он автоматом должен получить и cpp_util-2.5.0.

Все три составляющих я считаю очень важными. Но самым важным из них является как раз система дистрибуции. Имхо, без нее нельзя будет заниматься разработкой небольших, заточенных под конкретную задачу, библиотек. Например, если мне нужен генератор UUID, то я хочу получить только маленькую библиотеку с минимальным списком зависимостей, а не полутора мегабайтную POCO, десяти мегабайтную ACE или тридцати мегабайтный Boost.

Ну а раз Boost был помянут, то пора вставить ему очередной пистон. Как по мне, сама организация Boost-а напрочь убивает идею маленьких предметно-ориентированных библиотек. То, что процветает в Ruby и Java, в C++ усилиями Boost-оводов становится невозможным. Например, вам нужна библиотека для UUID? Нет проблем – берите Boost. Недорого, всего 30Mb каждая версия. Не хотите столько таскать со своим проектом? Нет проблем – в Boost-е есть bcp, он вам вырежет только то, что нужно. Ах, со временем вам потребовалось еще и filesystem? Ну что же, вновь берете bcp в зубы и старательно выпиливаете из Boost-а UUID вместе с filesystem.

Может быть для старых пользователей Boost-а это и выглядит нормальным. Но для меня это дикость. Если бы Boost изначально не был одной большой помойкой (в самом хорошем смысле этого слова), а состоял из модулей с отслеживанием зависимостей между ними, то ситуация для пользователей вроде меня была бы проще и удобнее. Скажем, есть модуль Boost.Config. От него зависит модуль Boost.Uuid. Если мне нужен только Boost.Uuid, то я скачиваю именно его и получаю в нагрузку только Boost.Config. Когда со временем мне понадобится Boost.Filesystem, я возьму просто Boost.Filesystem и все, т.к. Boost.Config у меня уже есть.

Естественно, у каждого модуля в Boost-е есть свой набор версий. Для каждой версии указывается, с какими версиями зависимостей он был протестирован. Опять же, Boost-оводы имеют возможность выпускать согласованные обновления. Например, все модули версии 1.47.0 взаимно совместимы друг с другом. При этом какая-то библиотека может иметь собственную историю развития до следующего большого релиза. Скажем, пока Boost.Config остается на версии 1.47.0, какой-нибудь Boost.Asio может развиться до 1.47.0.154 за счет баг-фиксов.

Такая схема позволила бы решить еще одну проблему, с которой Boost-оводы начинают сталкиваться: отказ авторов библиотеки от ее дальнейшего развития. Блин, ежу было понятно, что в мире OpenSource никто не обязан тянуть свой проект оставшуюся часть жизни. Написал несколько версий, потом обстоятельства изменились – забросил нафиг. Кому нужно, тот подхватит и продолжит, или же напишет что-то свое, еще лучшее. Это нормальный процесс. Посему модель развития Boost-а нужно было выбирать так, чтобы это учитывать. Если бы Boost проектировался не как одна большая помойка (опять же в лучшем смысле этого слова), а как репозиторий множества версий частично связанных друг с другом библиотек (внимательно смотрим на RubyGems и CPAN), то все бы решилось автоматически. Забросил автор какой-нибудь AnotherBoostLibrary ее развитие на версии 1.48.0 – ну и пофигу. Вот она такая библиотека, версии 1.48.0. Работает она в ваших условиях – отлично, берете и используете. Не работает – не берете, либо допиливаете, либо форкаете и переделываете.

Кстати, возражения о том, что разрозненные версии – это плохо, что здорово, когда все централизовано тестируется и обновляется, и тому подобные попытки защитить Boost-овскую централизацию, идут лесом. В мире Ruby децентрализация и зависимости между библиотеками отлично работают. В мире Java все это так же работает. Мир C++ ничем не хуже. В нем так же сработает. Нужно только понять, что монстры вроде Boost-а, ACE или Qt – это не выход.

Хотя на счет Qt… А не забить ли на все большой болт и не пересесть ли полностью на Qt4? Вдруг там все хорошо? ;)

[work.humour] О менеджерах и выжженном мире Австралии

Слава Костин (пожалуй, самый ответственный из виденных мной проджект менеджеров) опубликовал у себя в блоге выдержки из статьи «101 способ понять, что ваш проект обречён». Одна из них меня не могла не зацепить:

29. Разработчики используют vi в качестве IDE

Я уже было стал придумывать свой “ответ Чемберлену”, но по счастливому стечению обстоятельств, наткнулся на блог http://haritonoff.livejournal.com/, точнее на замеку “Про Сахул; окончание”. Ответ уже был там, да еще какой:

Первые австралийцы же взялись за дело круче и сразу принялись за ландшафт – такие уж у них были методы охоты… они оставались таковыми до последнего времени – загонная охота с поджиганием растительности. Огонь, охватывая обширные территории, выполняет сразу две задачи: он выгоняет животных, которых можно убить, или сам убивает их; и превращает густые кустарниковые заросли в открытые участки, по которым легче передвигаться. Английский исследователь Чеслинг писал: "Юленгоры (племя) поджигают лес во время охоты. Они не могут пройти мимо сухой травы и не поджечь ее. У них вошло в обычай сдирать с деревьев полосу волокнистой коры… скручивать ее в жгут и идти с ним как с тросточкой, поджигая зажженным концом сухую траву вдоль дороги. К октябрю, когда ветер стихает, пожары успевают уничтожить перегной. Теперь жгучее солнце завершает разрушительную работу – страна превращается в груду пепла. В декабре ветер меняет направление; сильно насыщенный влагой, он дует с северо-запада, потоки дождя заливают страну… рыхлая почва, песок, зола, перегной – все смывается в болота или уносится в море".

По ориентировочным оценкам, каждая кочующая группа ежегодно выжигала около 100 км2 лесов, саванн, степей – целенаправленно или невольно. Тысячи таких групп за 20-30 тысячелетий могли многократно – десятки раз! – выжигать растительность на всей территории континента. Влажные леса уступили место кустарникам, саваннам, пустыням. Ничем более не компенсируемые периоды засухи на континенте, потери органики почвами и эрозия не позволили аборигенам самостоятельно освоить сельское хозяйство.

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

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

[life] Настоящий внутренний стержень человека

Отличное определение:

Таки шило в заднице является моим внутренним стержнем, гг =)

Найдено здесь (через здесь).

[work.wow] Афигеть! Практически работа моей мечты! :)))

Не знаю, насколько все это реально и смогут ли эти работодатели найти подходящих людей, но мое внимание к себе они привлекли, однозначно! :) Вот объявление о работе:

Нестандартная challenge компания, делающая революцию в разработке программного обеспечения готова предложить достойные задачи для настоящего Евангелиста-джедая.

Какие задачи:
— Мессианская деятельность, направленная на проповедование парадигм и продуктов, развиваемых компанией, устно и письменно, в России, на Западе и на Востоке через все разработческие комьюнити, конвенты и компании — от мала до велика
— Написание евангелий по продуктам компании, описание чудес, которые новые инструменты творят в процессе разработки
— Вести и поддерживать паству привлеченных девелоперских команд и/или компаний и доносить до них новое Знание

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

Что предлагает компания:
— Всё.
Вот кое-что:
— з.п. которую Вы посчитаете адекватной
— ДМС, включая стоматологию, а также оплачиваемое компанией ДМС для деток
— никаких танцев с бубном по оплате больничного — все оплачивается полностью
— challenge
— бонусы
— обучения
— премии
— драйв
— конечно, помощь в переезде
— и т.д. ...

Кстати, может ли кто-нибудь просветить меня, несведущего, что значит “challenge” в списке “Вот кое-что”?

[life.sport] Закончился очередной биатлонный сезон

Россиянин Женя Устюгов – молодец. Первый полный сезон во взрослом чемпионате и золото Олимпиады. Хотя и жалко его немного – сначала на Олимпиаде не дали ему третьего места в индивидуальной гонке (редиски, два вторых места сделали, почему же третье убрали?!), потом не смог удержать лидерство в гонке за Большой Хрустальный Глобус. Зато заработал Малый Глобус по результатам гонок с массовым стартом.

Наша Даша Домрачева просто молодчина. Стала настоящей звездочкой мирового биатлона – бронза на Олимпиаде и две подряд победы на одном из заключительных этапов Кубка Мира. Если так пойдет и дальше, то она станет не просто звездочкой, а настоящей звездой.

Серебро Сергея Новикова на Олимпиаде – это вообще фантастика! Когда такое еще повторится в белорусском биатлоне? Может уже и никогда.

В мужском Кубке Мира борьба была до самого последнего этапа – у норвежца Сведсена и австрийца Шумана было поровну очков (почти как в прошлом году у женщин – тогда рубились шведка Юнссон и немка Вильхельм). Жалко, последний масс-старт я не видел, но Сведсен там сделал Шумана без вопросов.

Норвежский ветеран, Халвард Ханеволд, впечатлил – в 40 лет выступил на Олимпиаде и выиграл золото в эстафете. А в последнем масс-старте умудрился придти к финишу третьим.

Для легенды современного биатлона, Оле-Эйнар Бьёрдалена, сезон оказался неудачным. Целенаправленно готовил себя к Олимпиаде, но там погодная лотерея пустила всю подготовку псу под хвост – в личных гонках только серебро в индивидуалке (которого Сергей Новиков его чуть не лишил). Зато золото в эстафете.

Ну а больше всего потрясла меня молодая немка Магдалена Нойнер. Такой провальный старт сезона. Казалось, что после двух предыдущих очень успешных сезонов в этом наступил спад формы… Но одно серебро и два(!) золота на Олимпиаде, а потом еще и Большой Хрустальный Глобус по итогам сезона! Причем мало того, что она, по прежнему, очень быстра. Она еще и стреляет все лучше и лучше. Похоже, в женском биатлоне появляется безоговорочный лидер, каким был еще недавно Бьёрдален в мужском. Остается надеяться, что Даша Домрачева с ней еще поборется.

Сезон закончился. Ждем-с следующего.

[prog] Об условиях перегенерации кода из внешних DSL-ей

Некоторое время назад я обсуждал, если не ошибаюсь, с Дмитрием Вьюковым, условия перегенерации исходного кода, который строится из внешнего DSL. Например, есть у вас описание грамматики для yacc/bison – из этого описания вы получаете исходный код на C/C++. При каких условиях полученный исходный код должен быть перегенерирован?

Очевидно – при изменении описания, из которого код строится. Именно такой подход я заложил в свой инструмент RuCodeGen. Там для DSL-ного файла подсчитывается md5-хэш, который хранится в отдельном файле, рядом с DSL-ем. Если DSL-ный файл меняется, то md5-хэш так же меняется, и RuCodeGen понимает, что нужно выполнить перегенерацию.

Но здесь есть одно “но” – перегенерация не происходит, если меняется сам кодогенератор. Грубо говоря, появляется новая версия RuCodeGen, которая генерирует новый код по тому же самому DSL. Значит, генерацию нужно провести заново. Но ведь исходный DSL не изменился. Значит, перегенерация не произойдет.

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

Дима Вьюков озвучивал другой способ: по DSL-описанию код строится всегда. Но фиксируется в результирующих файлах только в случаях, когда новый и ранее построенный код не совпадают. Т.е. изменился DSL – получился другой код – записали новый результат генерации. Или изменился генератор – все равно получился другой код – записали новый результат генерации.

Казалось бы, все классно. Я уже хотел даже заняться разработкой RuCodeGen 0.4, в которой использовался бы именно такой подход… Но наткнулся на интересный недостаток этого способа.

Дело в том, что создаваемый генератором код в моем случае нуждался в отладке. Я вставлял в него отладочные печати и даже менял в нем одни вызовы на другие чтобы посмотреть, что получится. И я мог этот делать зная, что RuCodeGen не перегенерирует ранее созданный код, поскольку DSL не менялся. А вот если бы генератор просто сравнивал новый и старый код (как предлагал Дима), то мои правки сгенерированного исходного текста просто выбрасывались бы.

Такие дела. Так что, похоже, самый лучший способ – это учитывать хэш от исходного DSL и хэш от самого кодогенератора. Если что-то из этого поменялось, значит нужно выполнять перегенерацию исходного кода.

[life.photo] Капли воды от Martin Waugh

Martin Waugh – это фотограф, который специализируется на одной теме – съемке падающих капель воды. Вот некоторые из его работ: