С Новым Годом!

[life.cinema] Очередной кинообзор (2013/12)

Подошло время очередного, заключительного в этом году кинообзора.

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

Смерть на похоронах (2007 г). Очень понравился.

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

Из пекла. Крепкая криминальная драма. Может быть несколько растянутая, я бы ее минут на 15-20 подсократил.

Попали! Хороший пример того, как можно снимать классные комедии на зомби-тематику.

Неблагоприятные кварталы. Сильный криминальный фильм. Да и по сюжету закручен весьма прилично.

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

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

Грязь. Ощущение действительно такое, как будто в грязи вываляли.

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

[life] Утащу фрагмент чужого диалога из чужого блога к себе

Приведенный ниже фрагмент взят из ЖЖ elena-v-m. Это часть общения группы фотографов с преподавателем мастер-класса, Георгием Пинхасовым (выделение курсивом в последнем абзаце мое):

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

- Семинаристы - Хорошо. До встречи

- Георгий - Снимайте много. Тут же очищайте от ненужного.
Релакс, вы спокойны, контролируете всё вокруг.
И в "решающий момент" огнём неожиданных инстаграм, как кот Картье-Брессон.

- Семинаристы - Будем стараться

- Георгий - Потом объясню.
Коты не стараются...
А просто охотятся.
Главное лениво.
Иногда дерзко.
Как ловелас.
Добыча не любит суеты.
Ей нравится один жест.
Лёгкий уверенный, как в калиграфии.

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

[life.photo] Дабы окончательно проснуться :)

Давно не постил фотографий, а тут вот карточка в тему, из совсем-совсем недавнего.

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

[prog] Mxx_ru 1.6.2 и одна дикая идея на счет систем сборки С/C++ проектов

На днях сделал релиз Mxx_ru 1.6.2 с поддержкой нового тулсета: vc12 (это компилятор из состава MSVS 2013). Загрузить новую версию можно посредством RubyGems:

Для новой инсталляции:
gem install Mxx_ru

Для обновления уже установленной версии:
gem update Mxx_ru

Либо же можно скачать gem-файл с RubyForge, а затем установить Gem локально:
gem install Mxx_ru-1.6.2.gem

Проект Mxx_ru жив, в смысле постоянно и активно используется. На его развитие, правда, сил уже не остается, все время отнимает SObjectizer.

Но вот размышляя о том, куда можно было бы двигать Mxx_ru будь такая возможность, пришла в голову забавная и дикая идея. Навеяна она новой make-подобной системой сборки Ninja. Ее разработали в Google при работе над Chrome и ее целью является максимальная скорость обработки make-правил. При этом правила для ninja не пишутся вручную, а генерируются автоматом из других, более высокоуровневых систем описания проектов, вроде GYP или CMake.

Так вот моя идея состоит в том, чтобы из описанных в Mxx_ru правил строился C++код для управления компиляцией проекта. Этот C++код компилируется в exe-шник и именно этот exe-шник запускается и затем управляет всем процессом сборки. Выигрыш здесь в том, что если проекты модифицируются не часто (а именно так в большинстве случаев и происходит), то данный exe-шник будет компилироваться лишь эпизодически. А в большинстве случаев будет достигается скорость анализа зависимостей, недостижимая для инструментов вроде Mxx_ru и SCons.

Над реализацией этого дела я пока не думал. Вероятно, тут есть свои подводные камни. Но, если когда-нибудь дело дойдет до Mxx-2.0, нужно будет достать эту идею из запасников :)

[life.photo.humour] Классный однострочник про фотографов

Ты настоящий фотограф, если прогноз погоды для тебя выглядит как 1/60s f2 ISO200 вместо "дождливо".

Найдено здесь.

[life.cinema] Терпения при просмотре х/ф "Сталинград" хватило на 19 минут 38 секунд

Еще до выхода "Сталинграда" в прокат было подозрение, что фильм окажется фигней. После рецензии Гоблина стало понятно, что в кинотеатр на него идти не стоит. Но после появления фильма в Интернете желание составить свое собственное мнение о фильме толкнуло таки на суици попытку просмотра. Ну, чтобы не получилось "Пастернака не читал, но осуждаю".

При просмотре оказалось, что ранее прочитанные или увиденные мной разгромные рецензии на фильм "Сталинград", слишком добрые и мягкие. Очень удивлен тем, что кто-то смог эту картину досмотреть до конца. Мое терпение лопнуло на 19:38.

Непосредственно последней каплей стала сцена с освобожденным в захваченном доме артиллерийским корректировщиком. Которого командир разведчиков чуть не застрелил без суда и следствия со словами "Да ты переправу просрал!". И застрелил бы, если бы не был урезонен своим подчиненным(!) -- мол, наш радист погиб и рация разбита, а этот живой и рация у него работает. Т.е. рядовой разведчик соображает и ориентируется в ситуации лучше, чем его командир. При этом особенно пикантен гнев командира разведчиков в отношении корректировщика. Ведь разведчикам был дан приказ помешать немцам взорвать нефтехранилище. А они приказ не выполнили и непосредственная вина невыполнения приказа лежит как раз на командире.

При этом интересен диалог корректировщика и командира разведчиков: "А вот ты чего за фрукт?" -- "A говорил уже, корректировщик, офицер". Офицер? Это что за звание? Мне, крайне далекому от армии человеку, не понятно, почему корректировщик не представился как-то так: "Лейтенант Такой-то. Часть такая-то." И почему командир разведчиков не представился в ответ таким же образом. Возможно, потому, что сценарист фильма еще дальше от армии, чем я.

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

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

Конечно же, нельзя обойти вниманием персонаж рассказчика всей этой истории. Действия фильма про Сталинград начинаются в 2011-м году в Японии, где российские спасатели помогают справляться с последствиями цунами. Один из них, седой, но явно крепкий и бодрый мужчина, начинает свой рассказ о пяти отцах. Но, похоже, у сценаристов трава была просто улет гуманитарное образование и даже с элементарной арифметикой они не в ладах. Основные события фильма, включая зачатие рассказчика, происходят в ноябре 1942-го. Следовательно, появиться на свет рассказчик должен был в начале осени 1943-м. А в марте 2011-го ему должно было быть 67 лет. Шестьдесят семь, мать его, лет! И он "в поле" руководит действиями небольшой бригады спасателей. Признаться, о российском МЧС я намного лучшего мнения.

Но все это цветочки. О которых в той или иной степени мне было известно, просто я не представлял, насколько на самом деле все плохо. Однако, один маленький, но очень важный момент перечеркнул любые надежды на достойное содержание фильма. Одна короткая фраза:

Это было в Сталинграде, осенью 1942-го года. Русские переправлялись через Волгу.

Русские! Повторю еще раз: русские! И еще раз, поскольку нужно: русские!

Не "Наши". Не "Советские войска". Даже не "Красная армия".

Русские.

Такую фразу мог себе позволить какой-нибудь учитель истории где-нибудь в Австралии или в Сальвадоре, рассказывая ученикам про события Второй Мировой: "С 1941-го по 1945-й русские воевали с немцами. В Сталинграде осенью 1942-го русские переправлялись через Волгу..." Это было бы уместно, т.к. для них мы все русские.

Но чтобы так позволил себе сказать русский человек, живущий в бывшем СССР, чьи отцы, деды и прадеды своей кровь заплатили за его жизнь?!!! Не может нормальный русский так сказать. Воевал тогда Советский Союз. Сражались и умирали люди многих национальностей. Индеец из джунглей Сальвадора может сказать про них "русские". А мы должны говорить "наши". Это наши переправлялись через Волгу. Это наши отстояли Сталинград. Это наши победили в Великой Отечественной!

А эта оговорка Бондарчука все расставляет по своим местам. Поскольку это и не оговорка. Это предательство.

Резюмирую. Данный фильм еще раз напоминает о том, что СССР был побежден в Холодной Войне. И даже через двадцать лет после поражения, здесь хозяйничают победители. Пусть не своими руками, а руками своих прихвостней вроде Федора Бондарчука. И фильм этот, будучи явно антисоветским и антироссийским, еще один плевок победителей в души побежденных. Причем, что самое подлое, сделанный одним из побежденных.

[life.photo] Ссылки на англоязычные обзоры Nikon Df

Три фотографа, которых я регулярно читаю, опубликовали свои обзоры крайне неоднозначной новой полнокадровой камеры Nikon Df:

Обзор Кена Роквелла. Хвалебный. Впрочем, по-моему, данный товарищ либо скатывается временами в неадекват, либо же просто публикует проплаченные обзоры. Подчеркну, что это мое личное мнение, но сам я поправку "на ветер" в случае Роквелла делаю обязательно.

Большой и всесторонний обзор Зома Хогана (Thom Hogan).

Не такой большой и, в основном, негативный отзыв Минг Зейна (Ming Thien).

Имхо, эти обзоры подтверждают мое собственное впечатление. Nikon мог бы сделать правильный ход, создав новую камеру на базе 16Mpx матрицы от D4. Но он все испортил создав какой-то странный и непонятно на кого расчитанный гибрид олд-скул дизайна и современной начинки. Как по мне, фотолюбители (а камера явно не профессиональная), делятся на простые категории: богатые (которые покупают Leica); небогатые, но с претензиями (которые раскупают Fuji X100/X100S); прагматичные и требовательные (пользователи цифрозеркалок и беззеркалок Nikon/Cannon/Pentax/Olympus/Sony и т.д.); все остальные (которые пользуются цифромыльницами и камерофонами).

Такое впечатление, что Nikon хотела попасть в категорию пользователей "с претензией", но не имеющих денег на Leica. И которым аппарат с внешним видом Nikon Df нужен как солидно и красиво выглядящий аксессуар. А не как камера для активного использования.

Мне же остается пожалеть, что Nikon вместо Df не сделал адекватную замену для D700. Мне не нужен D800E с его 36Mpx. Но вот 16Mpx в том же корпусе с теми же контролами и настройками, да по цене ровно между D610 и D800 -- вот это было бы самое то.

Кроме того, похоже, уже очевидно, что гонка мегапикселей должна закончится. Для большинства пользователей, подозреваю, даже 24Mpx -- уже слишком много. Так что пора производителям переходить к эволюционному развитию своих камер. Например, оставляя внешний вид и базовую функциональность неизменной, но обновляя начинку: устанавливая лучший сенсор, новый, более быстрый процессор, добавляя какие-то средства для первичной обработки и публикации фотографий и т.д.

PS. И таки да, DX формат в ближайшие годы никуда не уйдет :)

[prog.c++] GCC под Windows: удивлен скоростью работы std::mutex/std::condition_variable

В стандартную C++11 входят базовые средства для поддержки многопоточности: std::thread, std::mutex и std::condition_variable (подробнее см.здесь). Но т.к. под Windows я пока пользуюсь MSVS2010, где эти штуки не реализованы, то единственный доступный вариант для работы с std::thread -- GCC, благо в версии 4.8.* это все уже есть (может были и в более ранних, я не исследовал этот вопрос, т.к. имел возможность сразу взять 4.8).

В случае GCC под Linux-ом никаких проблем с использованием thread из C++11 нет. Там все работает с максимальной скоростью. А вот под Windows с использованием GCC все гораздо хуже.

Я использую не родной вариант MinGW, а его порты: TDM-GCC и MinGW-w64. В них реализация std::thread под Windows доступна. При этом для MinGW-w64 есть два варианта: win-thread и posix-thread, так вот std::thread работает только в варианте posix-thread.

Проблемы с производительностью проявились на небольшом синтетическом тесте, который я использовал для своих экспериментов. В начале в тесте использовалась библиотека ACE, но затем захотелось попробовать std::thread.

Исходный текст теста приведен в конце поста под катом. Самое важное, что хоть там и используется очередь сообщений, в которой std::mutex/std::condition_variable задействованны для обеспечения thread safety очереди, но вся работа происходит на одной рабочей нити. Т.е. фактически этот тест показывает накладные расходы на работу внутренностей очереди (и, в том числе, накладные расходы std::mutex).

Так вот под MinGW (как в варианте TDM-GCC, так и MinGW-w64) тест показывает скорость приблизительно в 330K сообщений в секунду. Тогда как вариант с ACE показывал около 6.8M сообщений в секунду. Самое смешное, что тот же тест с использованием std::thread на Linux под управлением виртуалки так же оказывался значительно быстрее: порядка 5.2M сообщений в секунду. Под виртуалкой!

Вероятно, дело в реализации std::thread в libc++, которая идет с этими вариантами GCC. Подозреваю, что она базируется на коде для POSIX Threads, а сами POSIX Threads имитируются через WinAPI. Отсюда и такая низкая производительность. Причем, забавно, тот же тест под Cygwin GCC работает чуть быстрее -- порядка 1.3M msg/sec. Но все равно это далеко от производительности кода, который напрямую использует WinAPI.

В поисках других сборок GCC под Windows нашел еще один интересный дистрибутив: nuwem-mingw. В его основе лежит WinGW-w64, но с win-threads вместо posix-threads. Поэтому в чистом виде мой тест на сборке nuwem-mingw не проверишь. Зато в nuwem-mingw включено еще много чего, в том числе и скомпилированный вариант Boost-1.55. Это дало возможность адаптировать код теста под Boost и проверить его скорость. Результат получился таким же, как и с ACE: около 6.8M msg/sec.

Вот такие дела. Все проверялось на 2-х ядерном Pentium 1.4GHz, 4Gb RAM, Win7 64bit. Версии GCC во всех случаях были 4.8.2, тест собирался в 64-битовом режиме.

Update. Скомпилированный в режиме x86_amd64 компилятором из MSVC2013 Express показывает результат в два раза худший, чем nuwem-mingw с Boost-ом: порядка 3.5M msg/sec.

PS. Кстати, еще один интересный момент. У меня есть два варианта TDM-GCC: основной 64-битовый и точно такой же, но 32-битовый. Так вот 32-х битовый вариант оказался компилировать тест указав, что не знает функцию std::stoul. Хотя точно такой же 64-битовый TDM-GCC собрал код без проблем. На эту же функцию ругнулся и GCC из Cygwin-а. Все остальные варианты, включая GCC на Linux-е, успешно std::stoul проглотили. В общем, C++ скоро четвертый десяток разменяет, а приключения все те же :)

PPS. В Boost-е обнаружились такие нужные мне сейчас вещи, как spin-lock-и и lock-free очереди. Как бы я не превратился со временем в пользователя Boost-а :) Кстати, кто-нибудь проверял масштабируемость таймеров в Boost.Asio? Можно там создавать таймера в количестве тысяч/десятков тысяч штук?

[blog] Happy Birthday My Blog - 5!

Ну вот и первый маленький юбилей моего блога: пятилетие.

Нельзя сказать, что время прошло незаметно. И что первую запись я писал чуть ли не вчера. Нет. Как будто позавчера :)

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

Сейчас забавно вспоминать, но когда все начиналось, я думал, что через год-полтора стану популярным блоггером. Не в ТОП-10 Рунета, конечно, но пару тысяч подписчиков соберу. Очевидно, что этого не произошло. Более того, отрезвление наступило весьма быстро. Все оказалось очень просто и цинично: хочешь быть популярным -- работай над этим. Публикуй материалы, которые будут интересны многим читателям. Пиарь свой блог тем или иным способом. Будь на виду, напоминай о себе.

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

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

Ну да ладно. Вернусь к пяти годам. Большой срок. Старые читатели могли проследить по блогу важные изменения в моей жизни. Так, серьезно заниматься дартсом и фотографией я начал уже будучи блоггером "со стажем". И, полагаю, мои заметки в хронологическом порядке позволяют отследить прогресс на этих поприщах. Ну или отсутствие такового :)

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

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

Так что, если оглянуться назад, пять лет -- это очень немалый срок. Я рад, что у меня это получилось. И приятно осознавать, что еще полно сил и желания продолжать ведение блога. Чем собираюсь заниматься и дальше. Так что не переключайтесь! ;)

В завершение хочу искренне поблагодарить всех своих читателей. В особенности тех, кто подписался на блог (через RSS или Google+). И еще больше тех, кто находит время и желание оставлять комментарии к моим заметкам. Честно скажу, без вас я бы давно забросил это занятие. Так что огромное вам всем спасибо!

[prog.thoughts] Подводные камни при проектировании на конкретном примере

Описанный ниже пример, хоть и относится к SObjectizer, я вынес в блог в качестве демонстрации того, с какими неожиданными открытиями можно столкнуться при проектировании ПО. Как пример непредсказуемости и недетерминированности процесса разработки ПО. В особенности когда речь идет о разработке чего-то нового, а не очередного повторения ранее многократно проделанного. В общем, хочу показать, почему опытные ПМы умножают названные разработчиком сроки на Пи ;)

Текста довольно много, поэтому упрятано под кат для тех, кому это действительно интересно.

[management.book] Адизеc: Идеальный руководитель. Почему им нельзя стать и что из этого следует.

Только что закончил чтение очередной попавшей мне в руки книги Ицхака Адизеса: "Идеальный руководитель. Почему им нельзя стать и что из этого следует".

Думаю, что лучшей рецензией будет вот такая незамысловатая информация: читать "Идеального руководителя" я начал сразу же после "Стилей менеджмента". Но закончил только что. Для совсем не толстой книжицы в 260 страниц потребовалось два месяца. Что очень много. А все потому, что книга совершенно не интересна после прочтения "Управления жизненным циклом корпорации" и "Стилей менеджмента". В ней очень мало чего-то нового и интересного, а первая половина так вообще чуть ли не сплошная копипаста из двух вышеупомянутых книг. В итоге, читал через силу, заставляя себя все-таки ее закончить.

Вот, закончил. Еще раз убедился в мысли, что внимательного и вдумчивого прочтения заслуживает только "Управление жизненным циклом корпоации". Там описывается все, что нужно. Остальные дополнения к ней (как то "Стили менеджмента" и "Идеальный руководитель") -- это откровенная попытка подзаработать на той же самой теме, не сильно утруждаясь написанием совершенно новой книги.

[life.wow] Батюшки, какие говносрачи провоцирует BadComedian вокруг фильма "Горько"

На "Тупичке Гоблина" уже больше 1000 комментариев.

На странице самого шоу на carambatv.ru количество не указано, но очень много.

Блин, с чего это? Неужели не хватает чувства юмора посмотреть на свое кривое отражение в зеркале? Нужно обязательно изойти на говно обзывая тех, кому фильм понравился, тупым быдлом?

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

Может кто-то еще помнит, что в советские времена во многих дворах типовых 5-ти или 9-этажек был свой малолетний дурачок. У нас, например, был в прямом смысле дурачок, умственно отсталый парень, который в свои 15 или 17 лет по развитию был на уровне нас -- тогдашних 6-7 летних пацанов. Понятное дело, что мы над ним, бывало, и смеялись, и подшучивали, а может иногда и обижали. О чем становилось известно родителям и за что мы потом получали взбучку. Но вот что начинало твориться, когда над ним пытался подшутить кто-нибудь чужой, пришлый из соседнего двора! Бабульки на скамейках поднимали жуткий вой. А если поблизости были ребята постарше или кто-то из простых работяг, то могли чужака и поджопниками отоварить. Ибо нефиг. И это правильно. Пусть он сирый и убогий, но свой и нам рядом с ним жить.

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

Так что не фиг. Не нравится фильм -- не смотри. Да и время на написание говнокаммента в говносраче можно потратить на что-нибудь более полезное.

[prog.c++] Начато наполнение Wiki-раздела для SObjectizer на SourceForge

Польза от программного инструмента, не имеющего хорошей документации, невысока. Поэтому при развитии SObjectizer-а мы все время уделяли этому вопросу большое внимание. Пока комментарии и документация к SObjectizer писались на русском языке, с этим было более-менее нормально. После перехода на английский язык ситуация ухудшилась. Чтобы ее исправить мы будем использовать Wiki-раздел, который предоставляет сервис SourceForge.

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

В связи с этим у меня просьба ко всем интересующимся проектом SObjectizer: не стесняйтесь задавать вопросы, критиковать и предлагать что-либо. Если вы будете говорить о том, что бы вы хотели узнать о SObjectizer, о том, что вам не понятно про SObjectizer, а так же о том, что вам не нравится в SObjectizer или же вы хотели бы видеть в SObjectizer, то нам будет проще довести проект и его описание до ума.

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

[life.photo] Интересный большой обзор Zeiss Otus 1.4/55mm

Фотограф Ming Thein опубликовал большой и интересный обзор нового супер-пупер объектива от Zeiss: Otus 1.4/55mm. Обзор состоит из двух частей: первая и вторая. Много слов на английском, много фотографий. Так что если есть терпение и желание, то очень рекомендую.

Photo by Ming Thein

Судя по тому, что я слышал о Otus 1.4/55 -- это просто выдающийся объектив, аналога которому для 35-мм цифровых зеркальных камер пока не было. Да и по цене он заметно выделяется. На B&H Photovideo его продают почти за $4000. В России он должен появится в конце декабря с ценником в районе 150т RUB. Цена, по сравнению с аналогами от Nikon/Canon (а так же Sigma/Tamron/Tokina/Samyang и пр.), очень приличная. Хотя, если сравнить с ценами на похожую по своим характеристикам оптику от Leica, то получится не так уж дорого.

Но цена ставит крест на моем личном интересе к этому объективу. Имхо, покупка такого стекла обычным фотолюбителем -- это как приобритение фермером Ferrari в деревню: проблема не в ее стоимости, а в том, что в деревне Ferrari бесполезна. Точно так же и с этим объективом. Для раскрытия его потенциала нужна соответствующая камера. Cейчас у Nikon-а это разве что D800E (стоимостью ~$3000) или D3x (стоимостью ~$7000). Такие камеры дают RAW-файлы большого размера. Для их обработки нужна соответствующая вычислительная мощь, объемные диски и backup-устройства, а так же очень хороший монитор, а лучше два монитора. Т.е., если подсчитать, во что выльется остальное оборудование, способное вытащить максимум из Otus-а, то стоимость самого Otus-а не будет составлять и 50% от всего этого хозяйства (скорее, речь будет идти о 10-15-20%). Чтобы вкладывать такие деньги в фотооборудование будучи фотолюбителем, а не профессиональным фотографом, нужно быть либо сильно ударенным на всю голову ну очень сильно увлеченным этим делом, либо же иметь в собственности нефтяную скважину маленьких свечной заводик, доходы от которого можно было бы пускать на фотооборудование.

Так что Otus 1.4/55mm, при всех его достоинствах, это прекрасный рабочий инструмент для успешного профессионального фотографа. Либо же фетиш для очень богатого фотолюбителя. Для остальных категорий есть другие варианты. Пусть не такие выдающиеся в оптическом плане (хотя далеко не у всех есть даже 24Mpx камеры, способные раскрыть потенциал хорошей оптики), зато гораздо более доступные по цене.

Ну а вообще, сейчас стало появляться все больше и больше примеров снятых Otus-ом фотографий. Их можно найти, например, на Flickr. Или на ZeissImages. И вот что я могу сказать про свои ощущения: довольно часто говорят о 3D эффекте, который дают объективы Zeiss. Полностью поддерживаю это мнение, но на "обычных" объективах (вроде Makro-Planar 2/50 или Planar 1.4/85) это проявляется не всегда. А вот на снимках, сделанных Otus-ом этот эффект очень заметен. Картинка действительно выглядит объемной. Разделение планов, особенно тех, которые находятся вне зоны фокуса, просто поразительное. Инженеры и ученые из Zeiss-а не зря едят свой хлеб. Респект и уважуха.

PS. На днях я стал обладателем интересного 40mm-объектива, который по своей картинке отстает от Zeiss-ов не так уж и сильно. А стоит в разы дешевле. Вскоре я расскажу о нем подробнее.

[prog.c++] Состоялся релиз SObjectizer Assembly 201312

Декабрьская сборка SObjectizer и его подпроектов зафиксирована в виде тега и доступна для загрузки с SourceForge.

Главное в этой сборке -- это SObjectizer версии 5.2.3 и адаптированные к этой версии подпроекты. Плюс небольшие улучшения и исправления в so_sysconf.

В декабрьскую сборку входят следующие версии SObjectizer и библиотек:

• so-5.2.3.1;
• so_5_transport-2.2.2;
• so_log-2.2.1;
• mbapi-3.2.3
• so_sysconf-4.2.2.

Данный релиз доступен в виде трех архивов:

• so-201312-00.7z содержит исходные тексты только SObjectizer-а и его подпроектов. Необходимый для SObjectizer-а ACE нужно скачивать и устанавливать вручную;
• so-201312-00+ACE.7z содержит и SObjectizer с подпроектами, и архив с ACE 6.2.3;
• so-201312-00--doc-html.7z содержит сгенерированный Doxygen-ом API Reference Manual.

Для компиляции нужен Ruby и Mxx_ru (для полной сборки всех подпроектов, примеров и тестов потребуется так же RuCodeGen и ClsRuby, которые так же распространяются в виде Ruby-новых gem-ов). Данная версия проверялась под GCC 4.8.1/4.8.2, а так же VC++ 2010 (в 32-х и 64-битовых вариантах).

---

Ну вот как-то так. Второй релиз в виде сборок получился в ожидаемый срок. Надеюсь, что и последующие релизы так же пойдут.

PS. Буду очень признателен за распространение этой новости (например, в виде +1 в Google+).

[life.sport.darts] Вернулся с Финала Кубка РБ с серебряной медалью парного турнира

Вчера в Минске состоялся Финал Кубка РБ по дартс 2013-го года. Кубок РБ -- это пять промежуточных отборочных этапов, проходящих в течении всего года. На этапах Кубка спортсмены зарабатывают рейтинговые очки. По заработанному рейтингу ведется посев участников на Финале Кубка. В личном турнире ТОП-8 игроков начинают свое участие в Финале Кубка не сразу. Сперва проходят игры группового этапа среди всех остальных игроков, потом по два лучших игрока из групп участвуют в стыковых матчах для выхода на восьмерку лучших игроков по итогам года. Только после этого начинается полноценная олимпийка с 1/8 финала. Аналогичным образом проходит турнир и в парном разряде, только там есть ТОП-4 лучших пар, которые ждут, пока на них выйдут четыре пары, прошедшие групповой этап и стыковые матчи Финала Кубка.

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

В личном турнире я начинал с самого начала. Даже был посеян всего лишь на третьем месте в группе, поскольку в 2013-м смог принять участие лишь в двух этапах Кубка и выступил там не лучшим образом. Группа у нас подобралась ровная и, я бы сказал, весьма сильная для отборочного этапа: Евгений Козлов (Борисов), Николай Шмаков (Гомель), я и Антон Румянцев (Минск). Поэтому все игры у нас проходили бодренько и шустро, никто на удвоениях не зависал, а неудачные закрытия тут же наказывались соперником. В итоге из группы вышли Николай Шмаков и я -- Гомель рулит! :)

В сложном и нервном стыковом матче я воспользовался плохими закрытиями Паши Якимова и выиграл 4:2. Чтобы сойтись в 1/8 с ТОП-овым игроком Александром Глобажем. С которым я, так уж получалось, играл часто и, за исключением одного случая в далеком 2011-м, всегда проигрывал, обычно со счетом 0-4. В этот раз я вел 3:1. В пятом леге при остатке 174 я смог сделать набор в 134 очка, чтобы оставить 40 и не закрыть D20 в следующем подходе. За что и был наказан, сначала 2:3, затем 3:3. А в решающем леге мы устроили такой цирк и лотерею, что словами трудно передать. Я просрал несколько подходов на D5, затем на D2, затем на D1. А Саша аналогичным образом поступал на D5 и D2. В итоге удача улыбнулась ему и я в очередной раз проиграл, но уже со счетом 3:4.

В парном же турнире для меня все обернулось намного интереснее и веселее. Незадолго до финала сыграть в паре мне предложил один из ТОП-овых игроков, Дмитрий Бех. А сильный игрок в паре -- это очень важно. Понятное дело, что такой возможностью я не мог не воспользоваться и согласился. За счет большого парного рейтинга Дмитрия, наша пара оказалась 4-ой в ТОП-4 по итогам отборочных этапов Кубка (тут помогли еще и полученные мной очки за 3-е место в парном турнире на 4-м этапе Кубка с Игорем Роговым). Т.е. мы должны были начинать играть уже ближе к концу игрового дня, т.к. после двух первых этапов парного турнира игрались два первых этапа личного турнира, а лишь затем проходили 1/4 и 1/2 финалов парного турнира. Такой поздний старт не прошел для ТОП-овых пар даром. До полуфинала парного турнира смогла добраться всего одна пара -- мы с Димой.

1/4-я финала сложилась для нас крайне тяжело. Мы играли против Юры и Виталия Навойчиков. Дело дошло до решающего лега. Вспоминая 1/4 не могу не отметить отличную игру Виталия Навойчика. Юра, как обычно, играл очень сильно. А вот Виталий показал, наверное, лучшую игру из того, что я видел за последний год-полтора. Так что победа, хоть и была вымученной и незрелищной, далась нам крайне тяжело.

В 1/2 финал был, на мой взгляд, чуть более простой матч. Но не потому, что наши противники, Виталий Тапунов и Дмитрий Гореньков, были слабее нас или братьев Навойчиков. Скорее сказалось то, что мы после своего первого матча чуть подуспокоились, стартовый мандраж прошел. А вот наши соперники, видимо, от давления возможности выхода в финал, нервничали больше. Что не давало им быстро закрываться (при весьма хороших и стабильных наборах), чем мы и пользовались -- 4:0, хотя счет не отражает реального соотношения сил.

Финал я вообще не могу назвать финалом. С моей стороны это было простое и, как можно более быстрое, отбывание номера. После 1/2 финала нам пришлось ждать больше часа финального матча. Начался он в 20:20, а на 20:45 были заказаны такси, чтобы успеть на поезд в 21:35. Ну, понятное дело, мне не улыбалась перспектива не попасть на этот поезд. И еще больше я не хотел, чтобы из-за меня на него опоздали мои коллеги из Гомеля. А в таком состоянии нельзя играть против очень сильной пары Андрей Понтус и Иван Кляхин. С ними нужно сражаться спокойно, размеренно, никуда не торопясь. В итоге разгромный проигрыш 1:5, но мы хотя бы смогли взять один лег уже при счете 0:4.

В общем, на 90% своей серебряной медали я обязан Дмитрию Беху. Но, надеюсь, что в 1/4 и 1/2 я не сильно портил игру, т.к. у меня случались и наборы, и закрытия.

Данный турнир оказался для меня турниром несостоявшихся 100+ закрытий. Два раза срывался шанхай на 20-м секторе (T20+20+промах по D20). Два раза срывалось 105 очков -- в первый раз T20+5+промах по D20, во второй раз 20+T15+промах по D20. И еще один раз сорвался 115 -- T19+18+промах по D20. Причем в D20 я таки попадал и не один раз. Хотя один сотенный checkout я все-таки сделал: в 1/2 финала парного турнира списал ровно 100 очков через T20+D20. Ну и еще запомнились закрытия в 88 очков в личной встрече против Антона Румянцева (20+T18+D7) и 82 очка в 1/4 парного турнира (25+17+D20).

Похоже, начали сказываться результаты тренировок и регулярных поездок на турниры в последнее время. Все-таки без соревновательной практики никуда, игра против n01 не может заменить борьбы с реальным соперником, особенно на олимпийке, где проигрыш означает выбывание из турнира. Так что буду продолжать тренироваться. Следующая цель -- участие в турнире памяти Дубограева в январе 2014-го.

А вообще, играйте в дартс -- это здорово!

[life] Когда читаю материалы putnik1 по Украине...

...Возникает ощущение дежавю. Когда-то что-то подобное я у него уже читал. Когда начиналось все в Ливии в 2011-м. Тогда тоже были материалы в стиле "ситуация сложная, но власть все делает аккуратно и правильно, но уж очень серьезные силы задействованы...", но в целом заметки о Ливии, на начальном этапе развития событий, пока я их читал, несли оттенок оптимизма. Закончилось же все известно чем.

Похожие ощущения есть и сейчас. По аналогии напрашивается вывод, что добром нынешние события на Украине не закончатся. Что очень и очень грустно. Во-первых, украинцев жаль просто по соседски, гражданскую войну в каком бы то ни было виде никому не пожелаешь, тем более живущим рядом братьям-славянам. Во-вторых, если понятно кому удастся устроить заваруху на Украине, то аналогичные попытки обязательно будут предприниматься и в отношении Белоруссии, и России. А это мне уж точно на фиг не надо. Так что грустно.

PS. Если кто не в курсе, речь идет о ЖЖ Льва Вершинина: putnik1.livejournal.com.

[prog.os] Вынесу из комментариев: зачем и для чего нужны облачные ОС

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

Облако -- это куча серверов, отданных под выполнение какой-то задачи (какого-то приложения, вроде blogger-а).

Поскольку приложение не может крутиться на голом железе, на серверах (на каждом из серверов) должна быть развернута ОС. В случае традиционных ОС обозначаются две проблемы:

1) сложность администрирования и настройки. Т.е. каждый сервер должен быть правильно сконфигурирован, на него должен быть залит необходимый промежуточный софт (jvm, http-сервер, sql или nosql сервер, какой-нибудь mq). Должны быть определены юзвери, каждому из которых должны быть даны соответствующие пароли и явки имена, пароли и права доступа...

2) оверхед во время исполнения приложения. Традиционная ОС выполняет свой код в kernel space, а код приложения в user space, переключение контекстов -> лишние расходы. Плюс, запущенное в облаке приложение традиционная ОС рассматривает просто как какое-то приложение. Соответственно, какого-то специального тюнинга сервисов ОС под это приложение нет.

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

Так же должны снизиться накладные расходы на работу приложения. Т.е., в облачной ОС базовые сервисы ОС работают в том же адресном пространстве, что и само приложение. При этом нет накладных расходов на переключение контекстов, не нужно поддерживать жесткую вытесняющую многозадачность, нет необходимости обеспечения безопасности (например, при каком-то "системном" вызове не нужно проверять дескрипторы безопасности, права пользователя, от которого приложение запущено, уровни привилегий и доступность ресурса для этого уровня/пользователя) и т.д. и т.п.

Так вот, вся эта кухня с объединением ядра ОС и модулей приложения в один образ уже давно была разработана и опробована на ОС РВ. Но явно пока не востребована в облаках.

[prog.os] Анонсы "облачных" ОС. А куда смотрят производители ОС РВ?

Пару месяцев назад на глаза попался анонс "облачной" ОС под названием OSv. Идея там была простая: зачем держать на облачных серверах традиционную ОС, если можно поверх железа запускать гиппервизор, на нем тонкую специализированную прослойку OSv, внутри которой будет работать JVM с пользовательским приложением? Довольно подробно эта мысль освещается в презентации по OSv, если кто еще не видел, то рекомендую. А последний слайд, для наглядности, я размещу прямо здесь:

Вчера увидел анонс еще одной облачной ОС -- MirageOS. Разрабатывает ее, похоже, та же команда, что и Xen. Идея, как я понимаю, в MirageOS практически такая же, как и в OSv. Но, если OSv затачивается на запуск базирующихся на JVM приложений (не только Java, но и JRuby, Jython, Clojure), то в MirageOS основным языком является OCaml.

Разработчиков MirageOS я могу понять. У них сильна вера, что если взять "правильный" язык, и все сделать "правильно" с самого начала, то получится хорошая и удобная экосистема, в которой разработка и обслуживание приложений будет проще, удобнее, безопаснее и дешевле. В принципе, я сам придерживаюсь такого же взгляда на SObjectizer. Но очень явных и впечатляющих успехов на этом поприще добилась Apple со своей экосистемой из MacOS/iOS, Objective-C, и собственными сервисами вроде iTunes.

Так что подход разработчиков MirageOS/Xen мне понятен. Но более симпатичен, все-таки, взгляд на вещи команды OSv. Какую бы удобную и уютненькую домашнюю атмосферу не предоставляла бы MirageOS, но необходимость использования OCaml... Тогда как в OSv можно задействовать уже имеющиеся наработки на Java/Ruby/Python/Clojure и даже что-то на C.

Но вот что вызывает в связи с этим всем мое недоумение, так это отсутствие новостей о попытках выйти на рынок "облачных" ОС производителей специализированных ОС, таких как ОС реального времени. Когда в конце 90-х годов я работал в КБСП в отделе, связанном с системами АСУТП, довелось узнать, что помимо традиционных и хорошо известных всем ОС (вроде Windows, OS/2, Linux, Free/Net/OpenBSD, Solaris, HP-UX и т.д.) существуют мало кому известные, заточенные под задачи реального времени, специализированные промышленные ОС. Вроде QNX, OS-9000, VxWorks и пр.

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

Так вот для меня непонятно, почему производители таких ОС не пытаются влезть в нишу облачных систем. Ведь у них уже есть годами отшлифованные наработки (по тому же сетевому стеку, например). Плюс, большинство из них поддерживает POSIX, а некоторые, наверняка поддерживают и довольно свежие версии GCC. Так что портирование приложений на такие платформы вряд ли потребует серьезных трудозатрат.

Хотя, может я просто не слышал о таких попытках, а на самом деле они есть. Все-таки от "облаков" я очень далек, многого не знаю. А может дело намного проще: все упирается в деньги. Ведь специализированные ОС РВ -- это коммерческие продукты. А не OpenSource разработки, вроде Linux-а. Если облачному провайдеру нужно поставить ОС на несколько тысяч серверов, а каждая инсталляция обойдется ему в какую-то сумму лицензионных отчислений, то вопрос в пользу бесплатного дистрибутива Linux или FreeBSD будет решен сам собой :)

С другой стороны, может разработчики ОС РВ вовремя не заметили тренда. А может, как в случае купленой BlackBerry и находящемся сейчас в непонятном статусе QNX, у них есть совсем другие проблемы...

PS. Кстати говоря, не так давно узнал, что PalmOS довольно долго не была полноценной ОС, а базировалась на базе ядра ОС AMX от KADAK Products Ltd. И отсутствие реальной многозадачности в первых версиях PalmOS было вызвано такой банальной причиной, как условия лицензирования AMX: Palm просто не купил соответствующий модуль AMX! Между тем, AMX RTOS вполне себе живет и здравствует до сих пор.

[prog.c++] Qt 5.2: Digia оправдывает свой производственный план

Этот пост как некое дополнение к анонсу релиза Qt 5.2. В конце 2012-го или в начале 2013-го мне довелось пообщаться с представителем Digia по поводу планов относительно Qt на мобильных устройствах. Digia планировала к концу 2013-го сделать полную поддержку Android и бета-версию поддержки iOS. Похоже, план они перевыполнили. И поддержка Android, и поддержка iOS заявлена как production ready. На iOS, конечно, нашлись свои заморочки из-за дебилизмаособенностей Apple, но все равно это большое дело. Респект.

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

[life.wow] на работу...если там нужно работать

Ввязался в обсуждение темы дистанционного образования на Тупичке Гоблина. Один из моих собеседников выдал фразу, всей глубины и значимости которой я пока осознать не могу :) Но, похоже, она достойна отдельного внимания:

Ну и в догонку: мало кто возьмет на работу тупо из-за того, что кто-то окончил хороший университет с хорошими рекомендациями, если там нужно работать.

[prog] Подход к выбору сторонних библиотек внушаить

Найдено вот здесь:

У нас в компании принята политика выбора библиотек.
1. Обязательно open source под либеральной лицензией (GPL идет лесом сразу, проприетарщина допустима только при наличии саппорт контракта не менее чем на срок жизни проекта с прибитым гвоздями SLA или при наличии исходников)
2. Библиотека в обязательном порядке проходит acceptance review при котором проверяется качество кода, вменяемость разработчика, политику патчей, активность комьюнити, покрытие тестами, систему сборки и т.п. По результатам AR может быть три вердикта: "в топку", "берем" и "берем под свою ответственность". Последнее означает что мы посылаем разработчика в пень и форкаем проект в свою инфрастркутуру, налаживаем систему сборки, тестирование и т.п. В некоторых проектах наши люди становятся основными контрибуторами и эти проекты фактически переходят под наш контроль.
3. Если библиотека признана годной, то она проходит compatibility review на котором проверяется насколько архитектура библиотеки совместима с нашими проектами. Часто при этом пишутся тесты на типичные сценарии из наших проектов. Обычно этим занимаются интерны/джуниоры под наблюдением старших. Если уж они способны справится с библиотекой, то и нормальные разработчики смогут.
4. Если оба ревью пройдены библиотека считается разрешенной к использованию. Библиотеке назначается внутренний мейнтейнер который собирает ее в пакет, следит за обновлениями, отправляет патчи, общается в списках рассылки, рекомендует или наоборот запрещает переход на новые версии. Как правило этим занимается тот же человек что проводил AR, но иногда на эту роль мы берем на контракт разработчика библиотеки.

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

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

Для статистики: протокол прошли >100 библиотек из них разрешены к использованию 32 из них активно используются 12. Включены в инфраструктуру компании и опубликованы — 5.

Внушаить! Правда, очень хочется узнать, что за язык разработки, что за прикладная область, ну и что за компания. А то как-то сомнения гложут... :)

Этот фрагмент я нашел в обсуждении предпочтений между написанием своих библиотек или использованием чужих. Довольно давно я сам пришел к выводу, что в долгосрочной перспективе разработка своей библиотеки оправдана, если со временем эта библиотека превращается в самостоятельный продукт (не важно, OpenSource или закрытый коммерческий). Тогда развитие библиотеки и потраченные на нее ресурсы оправдываются (либо окупаются в случае коммерческого продукта, либо стоимость сопровождения снижается в случае OpenSource при наличии сторонних контрибьюторов). Если же библиотека так и остается внутренней разработкой, то со временем поддерживать ее становится все сложнее и дороже.

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

При этом под "библиотекой" я понимаю нечто большее, чем собственную реализацию CRC32, оформленную в виде повторно используемого внутреннего компонента.

[prog.c++] Зафиксирована версия SObjectizer-5.2.3 "Мижирги"

Очередная версия SObjectizer -- 5.2.3 -- зафиксирована в svn-репозитории на SourceForge в виде тега. Изменений по сравнению с предыдущей версией 2.2.2 довольно много, полная совместимость не сохранена. Но изменения внесены существенные, так что на такой шаг мы пошли сознательно.

Релиз версии 5.2.3 разбит на два этапа. На первом этапе зафиксирована вся функциональность и оформлен тег 5.2.3.0, но в нем нет подробных описаний новвоведений в doxygen-документации. Это описание будет создаваться параллельно с переводом других SObjectizer-подпроектов на версию 5.2.3. И затем будет зафиксирован тег 5.2.3.1, в котором функциональность останется точно такой же, но зато появятся подробные описания в doxygen-представлении. И в декабрьскую сборку SObjectizer, я надеюсь, войдет именно версия 5.2.3.1.

Под катом же краткое описание того, что было сделано в 5.2.3, несколько слов о том, что будет в развитии SObjectizer дальше и разъяснения по поводу необычных названий релизов SObjectizer (таких так Ушба, Джимара, Тетнульд и Мижирги).

[prog.management] Немного буржуинской статистики об успешности IT проектов

LinkedIn подкинул ссылку на статью "The Cost of Optimism and The Sorry State of Project Management", в начале которой был вот такой фрагмент с цифрами:

The Standish Group, which analyzes IT projects, reported that only 29% of IT projects succeeded, down from 34% at the turn of the century. Cost over-runs from original budgets averaged 56%, and projects on average took 84% more time than originally anticipated.

Т.е. автор статьи ссылаясь на исследования The Standish Group (так же известные как CHAOS Report) говорит о том, что процент успешных IT-проектов снизился с 34% (на рубеже XX-XXI веков) до 29%. При этом не давая ссылки на результат самого исследования. Меня это заинтересовало, поэтому попробовал разыскать данные самостоятельно. Наше PDF-ку CHAOS Manifesto 2013. Она довольно большая, я пока лишь бегло просмотрел первый десяток страниц. Впечатлили несколько табличек, которые я счел нужным привести в данной заметке.

Первая табличка показывает процент успешных/тяжелых/провальных проектов по годам:

Т.е. 29% успешных проектов действительно имели место быть, но это было в далеком уже 2004-м году. В 2012 этот процент вырос до 39. Что, наверное, хорошо. Но, если таки вдуматься в эту цифру, то оказывается, что в бюджет/сроки/скоуп задач вписывается лишь чуть больше одной трети IT-шных проектов!

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

Следующая табличка показывает, во что же обходится исполнение т.н. тяжелых ("challenged") проектов:

Сроки исполнения таких проектов растягиваются на 74%, стоимость увеличивается на 59%, в итоге же пользователь получает лишь 69% ожидавшихся фич. При этом, в 2012-м количество тяжелых проектов составляло 43% от их общего числа.

Ну и напоследок не могу не привести картинку, которая явно показывает то, что было известно давным-давно. А именно: ситуация с маленькими проектами намного, очень намного лучше, чем с большими:

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

Конечно, подобные отчеты The Standish Group ни в коей мере не являются истиной в последней инстанции. В Интернетах полно критики подобных отчетов (начиная тем, что в CHAOS Report используется очень ограниченное понятие "успешности" проектов и заканчивая закрытостью используемых при формировании CHAOS Report данных). Тем не менее, CHAOS Report показывает то, что разработчики ПО в той или иной мере постоянно видят вокруг: превышение сроков -- обычное дело, успешные проекты -- редкость, для получения приемлемого результата приходится пахать и пахать.

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

[comp] Windows-ультрабуки с 3200x1800px экранами

Я надеялся, что где-нибудь через полгода-год после появления MacBook-ов с Retina-экранами, последует ответ от других производителей. И что ноутбуки с разрешением больше 1920x1080 под управлением Windows станут широкодоступны 2012-м. Но ждать пришлось гораздо дольше.

Зато на днях я узнал, что появились ультрабуки еще более впечатляющими экранами с разрешением 3200x1800. Например, это Lenovo IdeaPad Yoga 2 Pro, Samsung ATIV Book 9 Plus, и несколько моделей от Fujitsu (Lifebook U904/T904, Lifebook UH90). Может есть и у других производителей, я большого поиска не делал.

Внушаить. Ультрабук от Lenovo -- Yoga 2 Pro -- произвел впечатление. Как раз такой и нужен для повсеместного таскания с собой. И поработать на нем можно (речь про модель с 8GiB RAM и 256GiB SSD), и на диване как с планшетом поваляться. Причем именно на примере этого ультрабука я понял, зачем ноутбукам тачскрин нужен. Плюс ко всему, Yoga 2 Pro уже продается в Москве (например, в Нотике).

В общем, жизнь не стоит на месте, процесс идет. Может через пару месяцев и матовые дисплеи с таким разрешением появятся.

[life.sport.darts] Winmau анонсировал свою 2014 Collection

Один из крупнейших дартс-производителей, Winmau, разместил у себя на сайте описание новинок 2014 года. На dartscorner.co.uk они уже доступны для предзаказа. На puredarts, как обычно, появятся чуть позже (но, наверняка, по более низким ценам). Для интересующихся под катом кратко про то, что привлекло мое внимание.

[prog.c++] Идея по поводу реализации selective receive в SObjectizer

Одной из характерных особенностей обработки сообщений в Erlang является механизм selective receive. Т.е. в выражении receive..end программист может указать сообщения, которые он хочет обрабатывать. Все остальные сообщения, которые не попадают под критерии в receive, остаются в очереди процесса. И становятся доступными при запуске нового выражения receive с другим набором критериев (см. например, фрагмент книги Programming Erlang, раздел 8.6). В SObjectizer же никакого selective receive нет: в каком бы состоянии агент не находился, ему будут доставляться все сообщения, если агент в своем текущем состоянии не обрабатывает какие-то из них, то необработанные сообщения будут для агента потеряны навсегда.

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

Сейчас проблема в том, что когда для агента есть заявка на обработку сообщения, заявка сначала изымается из очереди, затем передается агенту. Агент проверяет, может ли сообщение быть обработано в его текущем состоянии. И, если не может, то заявку агент уже не может вернуть в очередь обратно.

Исправить это можно двумя способами.

Первый способ состоит в том, чтобы отвергнутые в текущем состоянии сообщения сохранялись в локальной очереди состояния агента. А когда состояние меняется (т.е. вызывается метод agent_t::so_change_state), все накопившиеся сообщения одной операцией ставятся в начало текущей очереди агента. Т.о., когда рабочая нить агента обратится к голове очереди за новым сообщением, там будут стоять "старые" сообщения, доступные для повторной передачи агенту.

Второй способ состоит в том, чтобы заявки брались не из головы очереди, а из позиции, на которую указывает некоторый курсор. Первоначально курсор указывает на начало очереди. Заявка, на которую указывает курсор, отдается агенту, а агент возвращает признак, была ли она обработана или же должна остаться и ждать еще. Если заявка обработана, заявка удаляется и курсор остается на том же самом месте. Если заявка не обработана, то курсор сдвигается на одну позицию дальше, к следующей заявке (если таковая есть). При смене состояния агента (т.е. при вызове agent_t::so_change_state) курсор автоматически передвигается на начало очереди и процесс повторяется вновь.

Т.е. появляется реальная возможность сделать selective receive. Какой именно из способов будет выбран -- пока не понятно. Нужно будет посмотреть на различные варианты реализации очередей заявок (поскольку текущая версия уже требует пересмотра и выбор нового способа хранения очереди заявок можно будет делать с учетом selective receive).

Поскольку на основе SObjectizer уже реализована куча агентов, которые не используют selective receive, вероятно, нужно будет явно разделить состояния агента, в которых selective receive не поддерживается (старый класс state_t), и на состояния, в которых selective receive поддерживается. В коде это может выглядеть так:

using namespace so_5::rt; class my_agent_t : public agent_t    {    private :       // Состояние для обработки всех сообщений.       state_t st_normal;       // Состояние для обработки только части сообщений.       state_with_selective_receive_t st_wait_reply;    public :       my_agent_t(          so_environment_t & env )          :  agent_t( env )          ,  st_normal( self_ptr() )          ,  st_wait_reply( self_ptr() )          ...          {}       // Какое-то событие, которое срабатывает в st_normal.       void       evt_do_some_request( const event_data_t< some_signal > & )          {             // Инициируем запрос, а ответ ждем в специальном состоянии.             so_change_state( st_wait_reply );             m_receiver->deliver_message( new some_request(...) );             ...          }       void       evt_wait_response( const event_data_t< some_response > & evt )          {             // Возвращаемся в нормальное состояние...             so_change_state( st_normal );             // ...и обрабатываем ответ             ...          }    ...    };

Т.о. для версии 5.3 подбирается интересный список фич. Например, описанный только что selective receive. А так же, описанный чуть ранее, механизм синхронного взаимодействия агентов. Плюс, надеюсь, при работе над 5.3 получится уделить самое пристальное внимание вопросам производительности. Однако заняться всем этим получится не раньше января 2014. Поскольку сейчас полным ходом идет работа над версией SO-5.2.3, в которой уже добавлены интересные полезные фичи и этот процесс еще не завершен. Так что релиз сборки 201312-00 может стать пусть небольшим, но шагом вперед.

[life.photo] Carl Zeiss Jena Biometar 2.8/80mm в деле

Несколько месяцев назад приобрел себе раритетный среднеформатный пленочный PENTACON Six с объективом Carl Zeiss Biometar 2.8/80mm. Толкнули меня на покупку две причины. Во-первых, ну просто очень красивая вещь, сейчас выступающая как декоративный предмет :) Во-вторых, в комплекте шли макрокольца (они же extension tubes), так что была мысль попробовать этот объектив в макросьемке (ведь виньетирование у объективов от среднеформатных камер на 35-мм фотоаппаратах должно быть минимальным).

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

Выглядит итоговая конструкция с Nikon D700 + все макрокольца + объектив весьма внушительно:

Итоговый масштаб, если и не 1:1, то очень близко к этому. Правда, глубина резкости минимальна до смешного. Фокусировать можно только на самом близком к объективе расстоянии, ни о какой бесконечности и речи нет.

Получается же как-то так:

Еще несколько фотографий под катом. Не знаю, каково будет мнение опытных фотографов, но лично мне нравится, особенно когда выводишь фотографии на большой Full HD экран.

[prog.c++] Пример сохранения ссылок на внешние объекты внутри класса

Эта заметка, как и одна из предыдущих, является иллюстрацией к моим аргументам в большой дискуссии на LOR-е. Очевидно, что у некоторых C++ разработчиков есть предубеждение против сохранения внутри объекта ссылок на внешние объекты. В какой-то степени эти предубеждения оправданы. Но дело, однако, в том, что в таком хитром языке, как C++, нет простых способов обеспечения валидности сохраненной в объекте ссылки/указателя на внешний объект. Даже std::unique_ptr и std::shared_ptr не дают никаких гарантий: объект может быть выделен из пула (возвращается в пул кастомным deleter-ом) и тогда не смотря на unique_ptr/shared_ptr объект может исчезнуть из-за уничтожения пула. Так что бдить приходится всегда. А когда бдишь уже не так страшно хранить в объекте ссылки, а не умные указатели или, уж тем более, голые указатели. Об этом и пойдет речь ниже.

Поскольку это тема специфическая и содержит примеры кода, то она упрятана под кат. Кому интересно, милости прощу.

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

[prog.c++] Почему можно вызывать delete для указателя на const-объект?

До вчерашнего дня был убежден, что язык не разрешает вызывать delete для указателя на const-объект. Оказалось, что ошибался. Вот такая программа успешно компилируется и запускается:

class A {}; void bar( const A * p ) { delete p; } int main() {    bar( new A() ); }

Кто-нибудь может объяснить, почему это возможно? Upd. Спасибо, объяснение получено, см. ниже.

Лично я очень удивлен по двум причинам:

Во-первых, указатель на const-объект, это read-only view на объект. И когда посредством read-only view объект уничтожается вообще, то это, по меньшей мере, неожиданно.

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

Соответственно, я не припомню, чтобы видел где-то в "дикой природе" уничтожение объекта через указатель на const. Если кто-то из читателей видел, то подскажите, где на это можно посмотреть, пожалуйста.

---

А вот и ответ на мой вопрос на stackoverflow.

Это необходимо, чтобы можно было делать так:

void foo() {    const A * p = new const A();    delete p; }

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

template< class T > void some_common_action() {    T * p = new T();    // do something...    delete p; }

Здесь в качестве T для some_common_action может быть как просто A, так и const A. Причем тип аргумента при обращении к some_common_action может выводиться в каком-то другом, возможно совсем нетривиальном шаблоне. Поэтому для шаблонов возможность применения delete к указателю на const выглядит разумной.

Другое дело, что теперь нужно внимательнее относиться к функциям, которые в качестве аргумента принимают const T *. Вдруг ее разработчику взбредет в голову вызвать delete для аргумента. А я ни сном, ни духом :)

[prog.c++] Выражение модели владения через типы аргументов

На прошлой неделе сразу в двух независимых обсуждениях всплыл вопрос модели владения объектами в C++. Даже не столько сам вопрос владения, сколько методы обозначения этого владения посредством типов аргументов для функций/методов/конструкторов. Одно из них -- это большой флейм на LOR-е, касающийся языка D. Второе обсуждение велось в переписке между разработчиками SObjectizer. По итогам обсуждений у меня возникла мысль, что могло бы быть полезным описание моего взгляда на проблему типов аргументов, который сформировался у меня за 20 лет использования C++, набивания собственных шишек, чтения рекомендаций от других специалистов и пр.

Итак, поскольку в C++ нет сборки мусора, то проблема владения объектами является одной из краеугольных для C++. Большая часть страшилок о C++ -- битые и повисшие ссылки/указатели, повторное удаление объекта, обращение к несуществующему еще объекту и т.д. -- являются ее следствиями и проявлениями ошибок при ее решении. Удивительно, но до сих пор приходится читать на профильных ресурсах или видеть в коде подходы к решению этих проблем, характерные для plain C. Тогда как C++ скоро подберется к своему тридцатилетнему рубежу и в нем за это время накопилось достаточно механизмов для более простого и наглядного решения проблемы владения. Ниже я попробую об этом рассказать.

[life.sport.darts] Дошел до 1/8 финала Чемпионата РБ по дартс

На прошедшем вчера Чемпионате РБ по дартс удалось дойти до 1/8 финала. Вообще на Чемпионате сыграл шесть игр, пять из которых выиграл. Похоже, это тот максимум, на который я сегодня способен. Нужно работать над собой и дальше.

Впечатлений довольно много. Тут и трудная победа над Дмитрием Бехом в матче за первое место в отборочной группе. И сокрушительный проигрыш Игорю Подвойскому в 1/8. Есть еще когорта ТОП-овых белорусских игроков, на соперничество с которыми я еще не готов психологически. Игорь Подвойский из их числа. Хотя я старался.

Но самое приятное для меня впечатление -- это приезд на турнир двух игроков из Новополоцка. Прочитав в моем блоге призыв принять участие в Чемпионате Игорь Хламёнок и Сергей Слижиков решились и приехали, не смотря на то, что сделать им это было очень не просто. В общем, почувствовал себя причастным к появлению еще одной точки на карте дартс-движения в Беларуси, значит пишу я здесь про дартс не зря.

[life.cinema] Очередной кинообзор (2013/11)

Подошло время очередного кинообзора. Как обычно, в начале перечислены те фильмы, которые мне понравились больше всего.

Горько! Смешно!

Армагеддец. Хорошая комедия. Первые 2/3 фильма чуть не ржал в голос. Финал оказался несколько не в моем вкусе, но фильма не испортил.

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

Пленницы. Хороший, добротный триллер.

Тор 2. Монументально. Масштабнее, чем первый Тор. Но сказка, она и есть сказка.

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

Малавита. При всей своей добротности и отличных актерах фильм весьма занудный.

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

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

Игра Эндера. Детский фильм. Взрослым смотреть его только в качестве сопровождающих для детей.

Росомаха: Бессмертный. Редкая муть. И экшена в фильме не хватает, чтобы это компенсировать.

Паранойя. Скучный и неинтересный фильм. Не спасает его даже замечательная игра Гари Олдмана и наличие Харисона Форда и Ричарда Дрейфуса на вторых ролях.

[life.sport.darts] Дата проведения Чемпионата РБ по Дартс -- 1 декабря 2013

Объявлена дата проведения Чемпионата Республики Беларусь по дартс 2013 -- это 1-е декабря. Участие в турнире бесплатное.

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

Не суть важно, какой у вас уровень... Не, даже не так. Не суть важно, что вы сами думаете про свой уровень. Соревнования, особенно большие, это совсем другая история. Можно хорошо бросать на тренировках, но разволноваться на турнире. А можно закрываться 45-м дротиком у себя дома, но поймать кураж на соревнованиях и дойти до призов. Конечно, там будут мастера, против которых и 15-го дротика может не хватить. Но лично сыграть против такого, как минимум, очень полезно. Прочувствовать на рубеже, что рядом с тобой пусть и мастер, но такой же человек, что и ты. Он так же волнуется, а может волнуется еще и больше, т.к. выиграть ему важнее, чем тебе. А ведь этим можно воспользоваться. Действительно можно. Когда вырываешь лег, а то и два, у ТОП-ового игрока, то это, если и не окрыляет, то точно поднимает большую волну теплого чувства внутри :) И такие ощущения нигде больше испытать нельзя, только на соревнованиях.

Кроме того, большой турнир -- это большой турнир. У него своя специфика, с ней нужно рано или поздно познакомиться лично. Никакие разговоры и байки "бывалых" этого не заменят. И если начинать участвовать в официальных соревнованиях, то Чемпионат самый лучший для этого момент. В том числе и из-за бесплатного участия. Плюс к тому, игры на Чемпионате, даже на групповом этапе будут до 4-х побед (а не до 3-х, как обычно), так что игровой практики можно хватить даже выше крыши :)

Ну и еще один фактор. Дартс в Беларуси -- это очень маленькое сообщество, размера которого пока недостаточно для регистрации дартса как вида спорта в РБ (тогда как в России он таковым уже давно является). Это не есть правильно, поскольку дартс очень интересная и непростая игра, требующая от игроков как серьезной технической подготовки, так и способности сохранять спокойствие и концентрацию в самых напряженных моментах матча. Для дальнейшего развития дартса нам нужны игроки, старые и новые, опытные и начинающие. Чем больше нас будет, тем интереснее будут турниры, тем быстрее мы будем расти, тем больше и чаще к нам будут приежать сильные игроки из других стран, тем скорее мы начнем составлять конкуренцию на международной арене. И, в конце-концов, у нас появится свой Чемпион Мира. В какой-то Голландии есть, чем же мы хуже? Вот в России, смогли же вырастить трехкратного Чемпиона Мира Анастасию Добромыслову!

Это отнюдь не фантастика. Просто не нужно ждать, что это случится завтра по мановению волшебной палочки. К этому всего лишь нужно спокойно и поступательно двигаться. Небольшими шажками. Начав, например, с того, чтобы собрать на Чемпионате РБ не 50-60 игроков, как в последние годы, а 70-80, еще лучше 100. Чтобы на следующий год было уже 150, а еще через год -- 300. И таки я не рассказываю сказки, просто знаю по себе, как воодушевляет, когда после соревнований, на которых собирается 25-30 человек, вдруг оказываешься на турнире, где рядом с тобой еще 60 дартсменов.

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

Кстати говоря, от неформального дартс-клуба "Интервэйл-Гомель", к основанию и деятельности которого я приложил руку, на Чемпионат собирается поехать восемь человек. Уверен, что найдутся коллективы, которые нас переплюнут :)

PS. Перепосты, +1 и другие способы распространения этой информации всячески приветствуются.

PPS. Какое-то время эта запись будет висеть в самом верху блога.

[prog.humour] Это или явный перебор или совсем уж специфический стеб

Всегда с удовольствием относился к флеймам на тему языков программирования. И немало поучаствовал в таковых. Но даже мне кажется, что не нужно уж настолько серьезно к этому относиться:

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

это просто среда, посредник, medium. и medium is not just a message, it's little more than this.

medium это контекст для метациклического вычислителя этого сообщения, которое вычисляет каждый участнег — и немного по своему.

каждый участнег — такой метациклический вычислитель

знакомься, именно это и есть язык — та конструкция в голове, которая разворачивается у тебя в голове, участнег, читая эти строки.

Ну как, после прочтения метациклический вычислитель не зациклился? ;)

[life.photo.humour] После Samsung Galaxy Camera мир стал другим :)

Сейчас на полном серьезе можно сказать, что чувак рядом со мной звонил по фотоаппарату. Хотя это казалось невероятным еще пару лет назад :)

[prog.flame] Прочел тут "критику" использования IDE

В очередном дайджесте новостей от dev.by проскочила ссылка на перевод статьи с критикой IDE: Культура IDE против философии Unix. Стал читать. По началу был поражен, весьма разумные вещи озвучены в начале статьи. Даже удивился, неужели dev.by хоть что-то путное разместил?

Чуда не случилось. Где-то с середины статьи начинается господство маразма. Сначала автор что-то стал говорить об отношении "один ко многим", т.е. что правильным подходом является работа одного разработчика над несколькими программами. Тут у меня закрались первые сомнения. Но когда автор завел старую шарманку на счет unix-style, тут-то уж все стало на свои места: пионерия на марше.

В общем, первая треть статьи интересна и ее можно прочесть. Дальше можно не идти.

Зато эта статья напомнила, что я ведь и сам далеко не сторонник IDE. И даже на заре своего блогерства описывал причины этого. Перечитал то, что написал почти пять лет назад. Полагаю, сегодня написал бы тоже самое.

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

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

[prog.c++11] std::function и лямбды дают возможность к применению ФПшных приемов

Допустим, нам нужно передать куда-то callback-функцию с тем, чтобы кто-нибудь ее в какой-то момент времени вызвал. Если эта функция не нуждается в специальном контексте, то все просто: достаточно передать простой указатель на функцию. Но такой вырожденный случай не интересен, обычно требуется, чтобы функция была связана с каким-то контекстом. Но как передать этот контекст?

Процедурный подход, практикуемый в C, подразумевает использование дополнительного аргумента для функции. Как правило, этот аргумент имеет тип void* и внутри callback-функции приводится к нужному типу. В качестве примера того, как это делается, если кто-то не понимает, о чем речь, можно посмотреть на POSIX-овую функцию pthread_create.

Объектно-ориентированный подход позволяет избавиться от передачи дополнительного аргумента. Вместо указателя на функцию вводится какой-то интерфейс с виртуальным методом. Пользователь определяет класс-наследник, реализует этот виртуальный метод, создает объект этого класса и передает указатель на него в качестве callback-объекта. Тут необходимый callback-у контекст может сохраняться внутри callback-объекта: ведь это обычный класс, у него могут быть свои атрибуты, конструктор-деструктор и пр. Насколько я помню, этот подход нашел очень широкое применение в Java, где в некоторых фреймворках определялись кучи всяческих Listener-интерфейсов со всего одним методом.

Сторонники Функционального Программирования (ФП), в которых комбинирование функций, являющихся к тому же замыканиями, зачастую насмехаются над C++ и Java разработчиками. Ведь им не нужно городить огород с декларациями интерфейсов и их реализацией. Достаточно просто объявить прототип функции. А потом передать в качестве callback-а лямбда-функцию (или что-то посложнее, вроде результата карринга). Что, действительно, гораздо лаконичнее и понятнее.

Защищаясь мы, приверженцы ОО-стиля, любили говорить, что если где-то ждут функцию с прототипом void(void), то туда можно одинаково легко передать как void say_hello(), так и void format_disk_c(), так и void launch_nuclear_missles(). Но, конечно, тихо завидовали функциональщикам, которые могли писать меньше кода :)

Однако, долго вынашиваемый и не так давно принятый стандарт C++11 дает и нам теперь возможность определять callback-и в почти что функциональном стиле. Ведь лямбда-функции в C++11 являются замыканиями. И сохранить на длительное время нужный контекст внутри лямбда функции можно, например, посредством std::shared_ptr.

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

[prog.management] Еще об управлении и актуальности "Просто сделай как я сказал"

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

...Дело в том, что я пока еще не нахожусь на той стадии управленческого мастерства, на которой без разницы чем управлять, разработкой ПО или производством газировки. И даже не уверен, что такая стадия мастерства существует, хотя этому на курсах MBA и обучают :)

А вот в разработке ПО есть своя уникальная специфика. Молодые разработчики (причем молодые как по возрасту, так и по опыту) имеют очень большую значимость. Они намного лучше ориентируются в самых последних технологиях, намного быстрее все осваивают, очень легко перестраиваются. Опять же, молодые и гибкие мозги позволяют им решать новые задачки (в основном связанные с изучением чего-то нового) гораздо быстрее, чем возрастным программистам. Так же еще специфика конктретно СНГ: у нас мало действующих программистов возраста 45+. Виной тому распад СССР и развал отрасли. Многие молодые люди тогда либо не пришли в профессию, либо ушли из нее. А те, немногие, что остались, благодаря своим способностям давно перешли из разработчиков в управленцы или владельцы своего бизнеса.

При этом у всех молодых специалистов есть два чрезвычайно серьезных недостатка: большое самомнение и оптимизм. Т.е. они готовы браться за любую задачу даже не представляя себе ее сложность. А так же всегда занижая сроки реализации задачи.

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

Общение с молодежью оказывается совсем непростым делом. В подавляющем большинстве случаев люди все-таки вменяемые. Но случаются и тяжелые случаи...

...Я плотно сталкивался со спецификой небольшой, еще только проходящей стадию взросления компании, в которой было полно молодых, очень способных и амбициозных программистов. Это такие условия, в которых что бы ты людям не рассказывал, как бы подробно не объяснял причины, все равно они оставались в разной степени неудовлетворенности. Ну вот слишком это самостоятельный и вольнодумающий контингент -- молодые разработчики :) Поэтому я уверен, что ощущение, что руководство поступает неправильно, у них оставалось все равно. Даже если я и не прибегал к указаниям вида "Просто пойди и сделай так, как я сказал". Хотя, изредка, приходилось поступать именно так.

Собственно, вся упомянутая мной дискуссия -- это наглядное подтверждение тому, что можно потратить много времени и сил на объяснение причин, с которыми тебе приходится считаться. А итог нулевой.

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

Более того, обсуждая те или иные решения, мы, как правило, плотно задействуем "послезнание" (т.е. мы не можем абстрагироваться от знания последствий принятого решения). Даже те, кто принимал решение, могут со временем относится к нему иначе: значимость каких-то факторов оказалась преувеличенной, многие риски не сработали, события развернулись далеко не по самому худшему сценарию и т.д. и т.п. Что уж тут говорить о мнении людей, которым не нужно было это решение принимать, ответственность на них не давила, пусть даже они и находились рядом?

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

[prog.management] Небольшая ремарка про увольнения менеджеров

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

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

[prog.multithreading] Сломавшийся тест показал на просчет в моих предположениях

Многопоточное программирование -- это сложная штука. К этому утверждению можно относиться по-разному. Можно думать, что это преувеличение. И что тщательное отношение к делу, а так же использование "правильных" инструментов (будь то Haskell, Erlang или SObjectizer) полностью снимает сложность разработки многопоточных программ. Или, напротив, можно считать, что это слишком оптимистичное отношение к проблеме и, на самом-то деле, многопоточность -- это архисложно и практически никто не может делать это правильно. Каждая точка зрения имеет право на жизнь, ибо зависит от сложности задач, условий, в которых приходится искать решение, а так же профессионального уровня и величины собственного самомнения ;) Лично я уверен в том, что многопоточность -- это сложная штука. С ней можно справится, но легкой ее уж точно называть не следует.

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