[life] День на природе

Вместо эпиграфа старый анекдот:

Выходит геймер на улицу, присаживается на скамейку, оглядывается вокруг. И говорит сам себе:

-- Жизнь – почти как компьютерная игра. Простенький сюжет. Конец предсказуем. Но графика просто отвальная. И главное – никакого тебе 3Dfx!

Вчера весь день провел на природе – у нас состоялось корпоративное мероприятие под условным названием “День здоровья”. Человек тридцать выбрались за 50 километров от Гомеля на берег Днепра. Было здорово.

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

В подобных выходах на природу мне больше всего нравится заниматься костром. Вот и вчера я активно рубил и таскал дрова. Сегодня болят практически все мышцы и стертые руки.

Попробовал приготовленный на костре глинтвейн. Отличная штука.

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

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

In vino veritas. Особенно четко это проявилось ближе к вечеру, когда я с бутылочкой испанского вина сидел над обрывом на корнях сосны. Чистый воздух, свежий ветер, яркое солнце, красивые места вокруг. Ради этого стоит вкалывать. Чтобы время от времени вот так сидеть на крутом берегу на рекой. Чтобы вокруг был чистый воздух, свежий ветер, яркое солнце. На трезвую голову почему-то это не так ярко воспринимается. Может быть бренные мысли мешают отрешиться о сиюминутной мишуры.

Ну и в качестве вещественных доказательств еще несколько фотографий.

Это берег слева от лагеря:

А это общий вид обрывистого берега, на котором мы были (снято где-то с полукилометра от лагеря):

Такие тучки начали собираться перед нашим отъездом:

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

Пару слов о библиотеке асинхронных агентов от Microsoft

В новой версии Visual C++ 2010 будет содержаться нативная библиотека для работы с агентами. Давно пытался на нее посмотреть плотнее, но все не получалось. Совсем недавно в MSDN Magazine была опубликована статья Solving The Dining Philosophers Problem With Asynchronous Agents, в которой данная библиотека рассматривается на примере реализации задачи обедающих философов.

Курил я эту статью долго. Перечитывал раза четыре, как минимум. Сначала долго въезжал в то, что же там описано. Потом долго решал, что же я могу об это всем сказать… Сказать могу, как оказалось, немного. Либо статья плохая, либо пример выбран неудачно, либо сама библиотека того…

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

Кстати, оказалось, что еще и код примеров очень трудно читать из-за использованного в нем стиля именования. То классы с большой буквы называются, то публичные члены классов, то методы классов, то пространства имен. Плюс еще объемные лямбды загромождают код ненужными низкоуровневыми подробностями. Павбывавбы.

Тем не менее, было интересно посмотреть, как возможности C++0x позволяют записывать действия агентов в виде лямбда функций. Нужно обязательно поиметь это в виду для SObjectizer 5.

Boost needs reviewers или “У соседа корова дохнет. Пустячок, а приятно”

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

Цитаты из свежего письма в списке рассылки “Boost Announce”:

As always, we need experienced review managers. The review queue has
been growing substantially but we have had few volunteers, so manage
reviews if possible and if not please make sure to watch the review
schedule and participate.

We are also suffering from a lack of reviewers. While we all
understand time pressures and the need to complete paying work, the
strength of Boost is based on the detailed and informed reviews
submitted by you. A recent effort is trying to secure at least five
people who promise to submit reviews as a precondition to starting
the review period.

На мой взгляд, начинает проявляться изначальная проблема организации Boost-а: сбора разнородных библиотек под одну большую крышу. Это не правильная политика. По двум причинам (как минимум):

1. Сам механизм отбора базируется на механизме добровольного review. За развитием Boost-а следят далеко не все практикующие программисты, а только небольшая их часть, которым это интересно. Среди этой небольшой части есть только часть тех, кто принимает участие в review. Ну и еще вопрос о том, насколько заинтересованы именно они в этой конкретной библиотеке.
2. Попавшие в Boost библиотеки оказываются, я бы сказал, лучше распиаренными, чем их аналоги вне буста. Поскольку “Boost – это бренд” и сейчас многие программисты в поисках подходящего инструмента сначала заглядывают в Boost, а уже потом смотрят вокруг.

Из этих двух причин проистекают различные следствия.

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

Далее, вошла в Boost библиотека и что потом? Пока автор библиотеки имеет желание и возможность ее развивать и поддерживать – она будет жить. А потом? Откуда возьмется новый доброволец, который будет занимается ей дальше? Если речь идет о какой-то очень востребованной и безальтернативной библиотеке (вроде Boost.Multindex), то желающие найдутся. А если это какой-нибудь FiniteStateMachine или Spirit?

Что будет происходить, когда в Boost будут предлагать включить альтернативные варианты уже имеющихся в нем библиотек? Вот сейчас есть Boost.Range. Хотят еще добавить какой-то RangeEx. В чем смысл существования под одной крышей обоих Range?

До каких пределов будет увеличиваться размер Boost-а? Сейчас его tar.bz2 архив занимает порядка 30Mb. Что будет дальше – 50Mb, 100Mb? И это при том, что в 1.5Mb архиве POCO практических инструментов для решения моих насущных задач оказывается больше, чем в 30Mb Boost-е.

Что, в конце-концов, представляет из себя Boost – это полигон для отбора новых библиотек в стандарную библиотеку будущих версий C++ или же это собрание production ready компонентов для использования в промышленной разработке? Если честно, то я не представляю, как оба эти качества могут объединяться в одном проекте.

А что, на мой взгляд, могло бы стать альтернативой Boost-а?

Во-первых, унифицированная кроссплатформенная система сборки C++ проектов. Тот же Scons. Ну или CMake. Хотя и мой Mxx_ru был бы не плох ;)

Во-вторых, унифицированная система дистрибуции C++ных библиотек. Аналог RubyGems. Т.е. нужен тебе C++ный компонентик (C++ный кирпичик -- C++ brick), скажем RangeEx, ты делаешь:

cppbrick install RangeEx --version ‘>1.3.0’

и получаешь компонент RangeEx с последней стабильной версией, номер которой больше 1.3.0.

В-третьих, централизованное хранилище доступных C++ компонентов. Аналог RubyForge. Кроме того, что это хранилище будет использоваться для загрузки нужных пользователям C++ компонентов, на нем еще будет вестись статистика использования компонентов. И данная статистика как раз будет одним из критериев определения востребованности и качества компонента.

В-четвертых, централизованная система тестирования компонентов. Например, когда новая версия компонента публикуется в хранилище, разработчик компонента указывает, какие версии сторонних компонентов ему нужны. Скажем, RangeEx версии 1.3.5 нуждается в Config 3.4.* и IteratorTraits 2.0. После публикации хранилище производит автоматическое тестирование RangeEx 1.3.5 с соответствующими версиями Config и IteratorTrais. И отчет тестирования публикуется вместе с описанием компонента. Чтобы потенциальные пользователи могли его увидеть. Можно пойти и еще дальше. Когда разработчик IteratorTraits публикует новую версию, которую он объявляет совместимой с версией 2.0, хранилище может автоматически протестировать ее со всеми компонентами, которые зависят от IteratorTrais 2.0. После чего отчеты тестирования могут быть отправлены как разработчику IteratorTraits, так и разработчикам использующих IteratorTraits компонентов.

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

Что еще важно, так это то, что я получаю возможность выбрать для себя только то, что нужно мне здесь и сейчас. И получить только это. Если мне нужен 100Kb RangeEx для которого потребуется 1Mb Config и 500Kb IteratorTraits, то я получу только 1.6Mb зависимостей для моего проекта. А на 30Mb, как сейчас.

Вот как-то так.

Интересный взгляд на причины развала СССР

В блоге “Блоге разнузданного гуманизма”. Цитата:

…Нас часто критикуют за то, что мы слишком обеляем СССР, и пишем, что он был лишен недостатков. Это не совсем верно – просто мы в основном касались сравнительной характеристики СССР и современной России, которая своему предшественнику по большинству позиций проигрывает.

Если же оценивать не относительно, а абсолютно, то у СССР среди имеющейся кучи недостатков был один, который ее добил. Это – система воспроизведения «элиты».

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

Во время СССР, особенно кроме последних лет, было устройство, когда начальство работало много. И детей воспитывали их жены. Жены были в основном, как и сама элита, из простых. Или переехавшие крестьяне, или их дети. И у них, этих деревенских жен, чье хорошее положение никак не было связано с из личными заслугами, отношение к происходящему было самое простое – крышу сносило напрочь. И детишек они воспитывали в соответствующем духе. А потом, когда чадо вырастало, его надо было поступать, устраивать, отмазывать… Особенно если оно глупое и убогое, ведь болезных детишек охраняют больше всех…

…То, что произошло в конце 80х – начале 90х, было банальной контрреволюцией. Или почти банальной, так как обычно в результате контрреволюции к власти приходит бывшая элита. В этот раз к власти пришли дети элиты, которые идентифицировали себя не со своими отцами и дедами, а с теми, против кого те воевали, и захотели в новой свободной демократической России завести старые порядки, стать барами…

Интересный взгляд. Раньше я с таким не встречался.