[work.management] Еще раз про процессы, с чужими примерами

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

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

Работа в штабе Навального — вступление

Работа в штабе Навального — первая неделя

Думаю, что тем, кто интересуется проблемами управления творческими коллективами, станет понятна разница между тем, что делал Максим Кац и тем, чем приходится заниматься, скажем, при разработке ПО. Далеко не у всех производителей ПО есть такое количество однотипных проектов, при котором эффект от тщательно организованных административных процессов будет очень заметен. Полагаю, что у многих производителей собственного ПО в работе совсем не много проектов (вряд ли счет идет на сотни или даже десятки в год). И каждый из этих проектов может настолько сильно отличаться от других, что процедуры и стиль работы одной проектной команды может совершенно подходить другой команде. Поэтому есть большой вопрос, а имеет ли смысл вводить какие-то жесткие административные процессы, описывающие стадии проектов, списки участников каждой стадии, перечень входных и выходных артефактов для каждой стадии и т.д. и т.п. А если даже такие процессы необходимы, то они очевидно будут разными для крупных аутсорсеров со штатом в 10+ тысяч человек (задачей которого является способность пропускать через себя максимально возможное количество проектов) и мелкого производителя 2-3 программных продуктов (задачей которого является продвижение и совершенствование собственных разработок).

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

[prog.thoughts] Презентация о современных сборщиках мусора и мысля после нее

Ссылку на презентацию "Modern Garbage Collection in Theory and Practice" нашел в G+ ленте Сергея Теплякова. Вот слайды этой презентации:

A History of Modern Garbage Collection Techniques from Sasha Goldshtein

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

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

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

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

[life.photo] Ностальгируя по золотой осени - 2

За окном опять сырость, серость и унылость. Поэтому просто для поднятия настроения и напоминания, что бывало и по-другому:

2/50mm, ISO 200, f=5.6, 1/400

---

Мои фото есть и на zeissimages.com

[prog.c++] Зафиксирована версия SObjectizer-5.2.2

Версия 5.2.2 фреймворка SObjectizer зафиксирована в svn-репозитории на SourceForge в виде тега.

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

void evt_some_info( const so_5::rt::event_data_t< msg_info > & evt ) {    ... // какие-то действия в результате которых выясняется,    // что сообщение должно быть отослано другому агенту...    m_other_mbox->deliver_message(          // Посредством копирования экземпляра.          new msg_info( *evt ) ); }

То теперь можно отослать именно тот самый экземпляр сообщения:

void evt_some_info( const so_5::rt::event_data_t< msg_info > & evt ) {    ... // какие-то действия в результате которых выясняется,    // что сообщение должно быть отослано другому агенту...    m_other_mbox->deliver_message(          // Отсылается тот же самый экземпляр.          evt.make_reference() ); }

Метод шаблонного класса event_data_t<MSG>::make_reference() возвращает экземпляр умного указателя smart_atomic_reference_t<MSG>. Этот экземпляр может быть либо передан в deliver_message() сразу, либо же можно сохранить его и отослать сохраненный экземпляр сообщения позднее.

Данную функциональность (т.е. возможность перепосылки того же самого экземпляра сообщения) я хотел реализовать еще в SO4. Но там это было несколько сложнее, т.к. необходимая системная информация (включая счетчик ссылок на сообщение) хранилась внутри SO и пользователю не показывалась. В SO5 же введен специальный базовый тип message_t, от которого должны наследоваться все классы сообщений. Служебная информация, включая счетчик ссылок, находится в message_t. Поэтому в появляется простая возможность сохранить его или же отослать другому получателю. Для этого нужно всего лишь получить умный указатель на экземпляр сообщения (т.е. объект smart_atomic_reference_t, возвращаемый методом event_data_t::make_reference()).

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

Класс smart_atomic_reference_t в SO5 -- это интрузивный умный указатель, использующий atomic-counter-ы из библиотеки ACE (он похож на boost::intrusive_ptr, но т.к. Boost в SO5 не используется, то в SO5 на основе ACE сделан собственный вариант).

---

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

[prog.c++] В склерозник: список online C++ компиляторов

Нашел вот тут: Online C++ compilers

На всякий случай продублирую у себя:

LiveWorkspace (Clang 3.2, GCC 4.6.3 - 4.7.2)
gcc.godbolt.org (Clang 3.0, GCC 4.5.3 - 4.8.0 prerelease, Intel ICC 13.0.1)
Rise4Fun (Microsoft VC++ 2012 and November 2012 CTP)
Stacked-Crooked (GCC 4.7)
ideone.com (GCC 4.3.4 and 4.5.1)
Upd2. Coliru (GCC 4.8.1). Позволяет так же запускать скомпилированные приложения.
Upd3. Wandbox. Умеет целую кучу языков (в том числе кучу разных версий GCC+возможность задействовать Boost).
Upd4. cpp.sh. GCC и, похоже, с возможностью запуска скомпилированной программы.
Upd5. webcompiler.cloudapp.net. Visual C++ от самой компании Microsoft.

Только что попробовал gcc.godbolt.org -- здорово, понравилось. Разобрался, почему GCC отказывался компилировать код, который успешно съедал MS VC++.

Upd.compileonline.com (GCC 4.7.2). Поддерживает не только разные варианты C++, но и кучу других языков. Позволяет так же запускать скомпилированные приложения -- в настоящий момент превратился в ресурс <CodingGround>, где есть online IDE для кучи разных языков программирования.

PS. Из оригинального списка удалил Comeau Test Drive, т.к. у меня он сегодня выдавал ошибку об отсутствии соответствующего CGI на сервере, что намекает...

[life.photo] Nikon Df: ожидаемого лично мной чуда не произошло :(

Итак, Nikon официально объявил о выходе своей новой полнокадровой камеры Nikon Df. Информация о ней доступна на официальном сайте Nikon.

Я надеялся, что это будет первая топовая модель беззеркалки от Nikon (т.е. достойный ответ Olympus OM-D E-M5/E-M1 и Sony A99/A7/A7r). Не случилось. Похоже, что это обычная цифрозеркалка, с сенсором от Nikon D4 и возможностями Nikon D610.

Nikon позиционирует ее как камеру для путешествий -- она самая легкая и компактная среди никоновских полноформатных цифрозеркалок. По мнению Nikon она наиболее подходит для съемки статичных сцен -- ну а что ей еще снимать, если изменение ISO или выдержки делается с помощью механических контролов? Но, при стоимости тушки в районе $2700 (по информации dpreview), лично мне хотелось бы иметь более универсальный аппарат за такие деньги (больше мегапикселей хотя бы, ведь для пейзажей, которые можно увидеть в путешествиях, это будет совсем не лишним). Да и небольшой размер корпуса для зеркалки, на которую иногда нужно цеплять приличного веса и размера оптику это очень сомнительное достоинство. Можно даже не говорить за телеобъективы и взять хотя бы отличный Zeiss-овский портретник 1.4/85 или же новые Zeiss-овский Otus 1.4/55 и Nikon-овский 58/1.4: нацепи любой из них на камеру с маленьким корпусом и держать аппарат в руках будет неудобно. Мне зачастую и D700 кажется недостаточно большим (а такого же размера и камеры D300 и D800).

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

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

[life.wow] Смелость дизайнеров вызывает уважение

Фрагмент с картинки титульной страницы одного популярного японского сервиса:

[life.work.humour] Любителям резать косты посвещается

Эта картинка растиражирована по всему Интернету, данную копию я нашел здесь.

PS. Для не владеющих английским, надпись на фотографии: всегда есть кто-то, кто сделает это дешевле.

[prog.c++] В интересном порядке попались на глаза ссылки

На днях в интересном порядке попалось на глаза несколько ссылок, касающихся тонкостей C++ (и C).

Сначала это была презентация Deep C (and C++) (о которой я уже писал года полтора назад).

А затем ссылки на три записи в блоге LLVM, касательно оптимизации кода и взаимного влияние на это такой штуки, как undefined behaviour: What Every C Programmer Should Know About Undefined Behavior: #1, #2, #3 (ссылки были найдены здесь).

Интересное чтиво. Для действующих С++ (и C) разработчиков к прочтению обязательно, имхо.

Так же захотелось взять за правило бить по рукам тех, кто слишком много знает про особенности компиляторов и полагается в своем коде на тонкости стандарта. Чем проще и однозначнее код, тем меньше геморроя будущим поколениям. Хотя, конечно, полезно знать, чем отличается инициализация статической локальной переменной от автоматической. Но все же лучше, когда человек явно пишет static int i = 0, чем static int i. А еще лучше, когда статические переменные вообще не используются ;)

[life.sport.darts] Что-то меня сегодня прорвало - 2 :)

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

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

А несколькими сетами раньше случилось еще одно памятное для меня событие. Сделал седьмой шаг на пути к мечте. Т.е. открыл лет семью точными попаданиями в T20: 180+180, на остатке в 141 первым попал в T20, но второй ушел просто в 19, а не в T19.

На этот небольшой шаг мне потребовалось больше полутора лет.

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

[life.photo] Зачем новыми фотокамерами управлять как старыми механическими?

Небольшой пост из разряда "Из непонятого". Через несколько дней Nikon собирается анонсировать свою новую фотокамеру Nikon Df (см. здесь или здесь). На опубликованных видеороликах видно, что новая камера оснащена органами управления, похожими на те, что были на старых механических камерах. Например, есть отдельный диск для изменения выдержки.

Не понимаю я приверженности производителей камер ретро стилю. Сначала Fuji со своим Fujifilm S100. Теперь вот еще и Nikon.

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

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

PS. Ну и чтобы два раза не вставать :) DxOMark опубликовал анализы тестов новых полнокадровых беззеркалок Sony: A7 и A7r. Не могу не отметить, что Nikon D800/D800E все еще впереди планеты всей ;) Кстати, еще из непонятного: Sony на A7/A7r отказалась от использования своего байонета от серии Alpha (совместимого с Minolta-овским, если я правильно помню). Тем самым оставив свои новые камеры без огромного парка старой оптики (как Sony-вской, так и, что более важно, качественной Minolta-овской и Zeiss-овской). Странное решение.