[prog.flame] Касательно обсуждения моей писанины на RSDN

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

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

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

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

Но что же предпринято для того, чтобы в следующий раз разработчики еще раз не сказали "Да и с Хаскелем как-то не то, мы сделаем это на ..."?

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

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

В-третьих, касательно "Глупость там в основном в абзаце про растаманов программистов из глубинки." Речь вот об этом абзаце:

Не, тут меня занесло. Обычные ПМы, которые знакомы только с MS Project-ом и способны разве что сроки задач в диаграммах Ганта передвигать, а таковых в нерезиновой туева хуча, совершенно точно не будут знать об особенностях разработки на динамически типизированных языках программирования. Прошу прощения, мы тут в себя в провинции привыкли работать иначе, подотошнее, тащетельнее ;)

Я здесь не о программистах говорил, а о ПМах :) И говорил на основании опыта работы с гомельскими ПМами, с которыми мне очень повезло проработать бок о бок много лет, и чей профессиональный уровень я оцениваю как высочайший (виденные мной московские ПМы им и в подметки не годятся). Которые могут не только MS Project-ом пользоваться, но и вникать в тонкости проекта и которым разработчики лапши на уши навесить не смогут при всем желании. Ну и, самое главное, данный абзац является откровенной, наглой и ничем не прикрытой рекламой высококлассных специалистов компании "Интервэйл-Гомель" :) И если их еще не перекупили, то это очень и очень большое везение для владельцев "Интервэйла".

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

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

Заклятие. Чрезвычайно достойный представитель жанра ужастиков.

Город порока. Очень добротно все сделано.

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

Копы в юбках. Не ожидал. Было действительно смешно.

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

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

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

Пипец 2. Не понял ни о чем этот фильм, ни зачем я его смотрел. Но снято все очень профессионально, этого у фильма не отнять.

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

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

Пешка. Очень неплохо. Простенько, но смотрится с интересом.

Странный Томас. Действительно странные впечатления. Мне лично понравилось. Хотя какой-то легкий осадок остался. Только вот не знаю почему.

Репортаж 3 (он же Репортаж со свадьбы). Как по мне, так хорошее продолжение первого, самого забойного, Репортажа. Особенно, если относиться ко всему с юмором и иронией.

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

Кровь. Хорошие актеры и отличная актерская игра. Замечательная музыка. Операторская работа заслуживает отдельных похвал. Но из-за рассказанной в фильме истории сам фильм получился нудным и затянутым.

Штурм Белого Дома. Просто удивительно, как за такие деньги можно было снять ТАКУЮ фигню! Видимо, все ушло на визуальную составляющую. А на сценарий ничего уже не осталось.

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

[business] Интересное из пролога книги "The Living Company"

Читая какую-то статью и переходя по указанной в ней ссылкам, нашел опубликованный в Интернете пролог книги Arie de Geus "The Living Company". Суть в том, что автор книги очень долгое время проработал в Shell. И в начале 1980-х участвовал в проводимом Shell исследовании на тему: что позволяло большим компаниям жить столетиями (при том, что средний возраст коммерческих предприятий редко превосходит 40-50 лет, а гораздо чаще компания прекращает свое существование в возрасте 12.5 лет). В результате проведенного исследования были выделены четыре общих принципа, присущих всем обследованным крупным корпорациям с длительным временем жизни:

1. Восприимчивость компании, ее чувствительность к изменениям окружающей среды, дающие возможность учиться и адаптироваться;
2. Сплоченность коллектива и идентификация всех сотрудников компании как части единого целого;
3. Децентрализация и спокойное отношение к самостоятельности в филиалах, способность выстраивать нормальные взаимоотношения как внутри компании, так и с ее внешними партнерами;
4. Консервативное и спокойное отношение к собственным финансам: без рискованных инвестиций, обеспечение роста и развития за счет собственных средств.

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

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

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

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

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

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

Отсюда простой вывод: если компания хочет выжить, то ей изначально нужно ценить всех своих людей и рассматривать уход каждого из них как ЧП. Если этого не делать, то рано или поздно станет просто не на кого делать ставку. А деньги на покупку "эффективных менеджеров" со стороны закончатся.

---

PS. Эта книга в 2004-м была переведена на русский язык: Ари де Гиус, «Живая компания. Рост, научение и долгожительство в деловой среде». Думаю, что желающие без проблем смогут найти ее русский вариант в Интернете.

[prog.c++] Пример устранения многословности

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

Итак, было:

so_5::ret_code_t so_sysconf_layer_t::run_script(    const std::string & file_name,    so_5::throwing_strategy_t throwing_strategy ) {    return m_so_sysconf_layer_impl->run_script(       file_name, throwing_strategy ); } so_5::ret_code_t so_sysconf_layer_impl_t::run_script(    const std::string & file_name,    so_5::throwing_strategy_t throwing_strategy ) {    bool result = false;    // Последовательность задач.    task_vector_t task_sequence;    result = script::parse_file( file_name, task_sequence );    // Если файл разобран нормально, то    // вставляем всю последовательность.    if( result )    {       m_tasks_handler.m_task_queue->push( task_sequence );       return 0;    }    else    {       return so_5::util::apply_throwing_strategy(          so_5::rc_unexpected_error,          throwing_strategy,          "unable to start so_sysconf by script '" +           file_name + "'");    } }

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

void so_sysconf_layer_t::run_script(    const std::string & file_name ) {    LOCK_AND_CHECK_WORKING_STATE( so_sysconf_layer_t::run_script );    m_data->m_tasks_handler.queue().push( script::parse_file( file_name ) ); }

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

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

Какие-то чудеса сегодня творятся. Впервые сумел выиграть у n01 на шестом (из двенадцати) уровне 8-3 по сетам. При этом впервые в жизни закрыл 164 по рекомендациям классиков: T20+T18+D25. А так же сумел закончить сет со средним набором 93.94 очка (леги в 15, 18 и 15 дротиков).

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

Так же n01 умудрился сделать лег в 10 (десять!) дротиков: 140+180+177 + D2 первым же дротиком. У меня было ощущение, что я проиграл этот лег Филу Тейлору :)))

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

[prog.c++] Пример простого нарушения exception safety

C++ требует очень внимательного отношения к владению ресурсами. Особенно это касается динамически созданных объектов. Особенно в ситуациях, когда могут порождаться исключения (а какой же современный C++ без использования исключений ;)). Вот простой пример ошибки, может возникнуть, когда забываешь про exception safety.

Есть объект, который хранит в себе указатели на динамически созданные объекты. Эти указатели ему передаются посредством метода add. Логика метода add проста: он сохраняет переданный указатель у себя, а уничтожит все полученные таким образом объекты в своем деструкторе. Поскольку логика метода add проста, то и реализация кажется простой:

class some_object_holder_t {    std::vector< A * > m_objects; public :    ...    void add( std::unique_ptr< A > object )    {       m_objects.push_back( object.release() );    } }

Но я вижу в этом простом коде одну проблему: если при работе push_back произойдет исключение (например, не хватит памяти для расширения вектора), то переданный в add() объект не будет уничтожен. Почему? Да потому, что он уже не будет находиться под контролем std::unique_ptr, ведь метод unique_ptr::release() отработает еще до входа в push_back.

Вот и получаем неприятную ошибку на ровном месте. Неприятную потому, что она может очень долго не проявляться (пока при каком-то стечении обстоятельств push_back не бросит исключение). Поэтому написавший такой код разработчик может сам никогда и не столкнуться с ее последствиями.

Если бы метод add был написан вот так:

void add( std::unique_ptr< A > object )    {       m_objects.push_back( object.get() );       object.release();    }

То не было бы нарушения exception safety и, как следствие, очень неприятной и редко возникающей ошибки.

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

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

Один из совсем немногих кадров октября 2013-го:

2/50mm, ISO 250, f=13, 1/80sec.

[comp] Интересная статья "Of Personal Computers and Cameras"

Известный в рядах Никонистов Thom Hogan, бывший компьютерщик и софтварщик, время от времени радует интересными размышлениями. Из последнего очень понравилась статья "Of Personal Computers and Cameras". Очень рекомендую потратить 10-15 минут на чтение оригинала, благо там не очень много слов на английском. И хотя автор делает акцент на влияние происходящего на рынок фотоаппаратов и видеокамер, даже далеким от этих увлечений компьютерщикам и программистам будет интересно прочитать одну из версий того, во что уже сейчас трансформируется такая привычная нам всем вещь, как персональные компьютеры.

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

Apple's announcements may not have seemed like a lot at the user level—some new incremental models, a bunch of software updates—but at the core of all it was a shift that I think everyone in the tech industry probably noted and had a few shivers over. By taking software to free and pushing it further into integration between devices, other software, and even now enabling group editing, Apple actually just made a pretty strong statement that no one else can currently match.

The combination of free OS updates, free basic apps (word processing, spreadsheets, presentations, photo management, music creation, and video editing), coupled with state-of-the-art devices (phones, pads, and all variety of Macs), augmented with content via the App Store, and all tied together through iCloud is something that even Microsoft is going to have a tough time matching, for instance

Речь о том, что анонсированные на днях новые версии iPad и Mac-ов, а так же обеспечение их бесплатными базовыми приложениями (для работы с документами (таблицами, текстами, презентациями), с фотографиями, музыкой и видео), плюс очень тесная интеграция всех устройств и софта между собой, а так же с облачным сервисом iCloud (плюс сюда же App Store и iTunes), создает такое комплексное интегрированное решение, которому пока никто ничего не может противопоставить.

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

Поскольку я очень далек от яблочной продукции, а так же отношусь к категории людей, которые более плотно завязаны на компьютеры, чем обычные пользователи, то мне сложно судить, насколько Apple здесь в лидерах. Но, подозреваю, что сильно впереди остальных. Так же я думаю, что другие крупные игроки уже давно в курсе происходящего и пытаются что-то противопоставить Apple. По крайней мере Microsoft (и в этом смысле приобретение Nokia для них еще более важно) и Google. Хотя позиции Google, который наверняка ничего не зарабатывает на Android-е, здесь, может быть, самые худшие.