Это маяк у Cleveland Harbor West Pierhead на озере Эри. А вот так он выглядит в обычное время:
PS. Снимок найден в очередном выпуске WSJ’s Photos of the Day.
пятница, 17 декабря 2010 г.
[work] Быть начальником? Глубокое погружение vs быстрое переключение
Первая часть заметок под общей темой “Почему я не хочу быть начальником?” (следующая часть здесь)
Сегодня речь пойдет о двух вещах, которые, как мне кажется, являются двумя сторонами одной и той медали.
Итак, сторона первая. Что требуется от хорошего инженера-программиста? Принимать правильные технические решения. Для чего зачастую приходится очень глубоко погружаться в проблему и очень долго, тщательно и всесторонне рассматривать различные способы ее решения, чтобы затем остановиться на каком-то одном. Погружение может потребовать изучения большого количества материалов (например, штудирование нескольких талмудов с документаций и стандартами). Кроме того, дело может свестись не к выбору какого-то готового решения, а к рождению собственного варианта.
Помню, как в 97-м или в 98-м пытался решить проблему эволюции схемы данных в своей объектно-ориентированной БД. Т.е. пользователь сначала описывает схему БД на языке описания данных, затем наполняет БД данными, затем описывает новую схему на том же языке, а сама БД определяет, как схема изменилась и как следует преобразовать данные. И чтобы пользователю не приходилось вручную вписывать инструкции вида alter table… add… или alter table… drop column… Просто БД должна была сравнить две схемы и сама решить что к чему.
Я рожал такое преобразование около месяца. Занимаясь, по сути, только им. На все остальное не оставалось сил. В мусорку отправилась толстенная пачка бумаги формата A4. Но алгоритм таки был получен, реализован и протестирован.
Вот это, я считаю, и является главной добродетелью хорошего разработчика – погрузиться в задачу так, чтобы ничего больше не существовало вокруг, и сделать в конце-концов конфетку. Чтобы у самого была 100% уверенность в том, что лучше ты бы уже не смог.
А с чем сталкивается начинающий начальник? С тем, что ему не дают возможности отрешиться от внешнего мира и уйти в себя чтобы что-то там родить. Не до того. То один подчиненный что-то спросит. То второй просит принять окончательное решение в каком-то споре. То начальство просит высказаться по какой-то проблеме. То пятое, то десятое. Причем, с увеличением количества подчиненных и числа проектов промежутки между “внезапными вбрасываниями” не то, что стремятся к нулю, они грозят стать отрицательными! :)
Т.е. от начальника требуется умение очень быстро переключаться между разными проблемами и быстро принимать решения, способность делать выбор даже при огромном недостатке информации.
На мой взгляд, здесь проявляется главное отличие “заточенности” мозгов инженера и руководителя. Инженеру нужно уметь вобрать в семя максимум наиболее подробной и точной информации, чтобы затем упорядочить и отсортировать ее. Тогда как руководителю нужно суметь обойтись минимумом (зачастую поверхностной) информации.
Ну а теперь сторона вторая. Хочу приплести аналогию с легкой атлетикой, где есть спринтеры и стайеры. Такое деление возникло не случайно, это следствие особенностей организма – кто-то способен на короткие, требующие мгновенного высвобождения энергии нагрузки, кто-то на длительные, выматывающие. И в истории спорта (особенно современного) вряд ли найдется много примеров, когда успешный спринтер после побед на 100-метровках переквалифицировался бы в успешного стайера и побеждал бы в 5-километровом стипльчезе.
Что-то подобное, имхо, прослеживается и в разработке ПО. Только я бы это аналогию развернул, подозреваю, неожиданным образом. Я думаю, что программисты – это спринтеры. Работа программиста – как серия 400-метровок – напрягся (погрузился в задачу), расслабился (доделываю предыдущую задачу и присматриваюсь к новой), напрягся (погрузился), расслабился…
Тогда как начальники – это стайеры, бегуны на длинные дистанции с препятствиями – бежим, бежим, прыгнули, бежим, бежим, еще раз прыгнули, опять бежим, бежим, прыгнули снова, опять бежим, снова бежим… И так из проекта в проект.
Ну а теперь к сухому остатку всего вышеизложенного потока сознания: переход от разработки к управлению разработкой – это как переквалификация из спринтеров в стайеры. Хорошо, если возможности организма (мозгов) позволяют это сделать.
[work] Почему мне не хочется быть начальником
Данной заметкой я планирую открыть цикл постов, в которых постараюсь описать почему мне не нравится руководить (в моем конкретном случае разработкой ПО). Непосредственным толчком к этому стал комментарий ув.тов.имя в теме “А где (и кому) нужны мастера на все руки?” Хотя, положа руку на сердце, это проявление душевного эксбиционизма публичная попытка ответить самому себе на вопрос “Если ты такой умный, то почему ты не миллионер?”
Или даже не так. Есть замечательное изречение:
Кто хочет – ищет возможности.
Кто не хочет – ищет причины.
Так вот, быть начальником я никогда особо не хотел. Посему ищу причины, по которым у меня такого желания нет.
На эту тему можно сказать много слов, но писать большую статью не хочется из-за недостатка времени. Поэтому я попробую сделать ряд заметок, в каждой из которых будет обсуждаться только один из аспектов. Приблизительный состав (он же план-график) намечается такой:
- спринтер vs стайер или глубокое погружение vs быстрое переключение;
- организованность (читай тотальный контроль за подчиненными и за собой);
- подчиненные – они тоже люди (индивидуальный подход, кнут и пряник, хвали публично, ругай лично и другие совершенно невероятные для аутично-шизоидного интроверта вещи);
- разное отношение к доработкам
- индивидуалист vs командный игрок;
- политика и торгашество.
Это темы, на которые я могу потрындеть прямо сейчас, с ходу и без подготовки. Возможно, со временем будут появляться еще какие-то темы – тогда я их буду включать в этот список.
В общем, вот такие планы. Если кому-то интересно, то stay tunned… ;)
четверг, 16 декабря 2010 г.
[prog] Описание нововведений Scala 2.8: The Architecture of Scala Collections
Продолжается серия статей с описанием новых возможностей Scala 2.8. На этот раз статья внутренности библиотеки коллекций и контейнеров Scala: The Architecture of Scala Collections.
Ранее были опубликованы статьи:
[prog] Релиз POCO 1.4.0
Состоялся релиз версии 1.4.0 библиотеки POCO.
Среди основных новшеств разработчики называют поддержку Visual Studio 2010, 64-битовую сборку под Windows, поддержку Windows Embedded CE и улучшения в поддержке iOS. Плюс большое количество исправлений и добавлений, подробности которых можно посмотреть в CHANGELOG.
PS. Судя по прошлому опыту работы с POCO, я бы подождал выхода 1.4.1 или 1.4.0p1.
среда, 15 декабря 2010 г.
[life.sport.darts] Небольшой лытыбр
Распродал практически весь свой арсенал. И Target-овские Aviator-ы, и Unicorn-овские Andy Hamilton Maestro. Все-таки дротики Andy Hamilton-а оказались для меня слишком скользкими. И если дома, разогревшись, они держались в руке более-менее нормально, то вот в офисе, в весьма прохладном коридоре, часто выскальзывали.
Остался с Target-овскими Silica Apollo, которые мне когда-то не очень понравились. Причем задержались они у меня только потому, что слишком дорого мне обошлись (более 40GBP с учетом замены иглы), а задешево продавать я их не хотел. И вот теперь, благодаря собственному скупердяйству, вновь привыкаю к новым старым дротикам :)
Пока впечатления неплохие. За прошедшее время у меня изменился хват, поэтому сейчас мне их держать гораздо удобнее, чем два месяца назад. Результаты, правда, пока не очень хорошие и я основательно подрастерял форму, в которой был когда ездил в Минск, но до суперфинала нашего офисного турнира еще есть неделя, так что надеюсь на лучшее.
В начале декабря, когда стало у меня копиться неудовольствие от дротиков Andy Hamilton-а, заказал себе 22-х граммовые 90% дротики McCoy Stealth. 
Но из-за всех приближающихся праздников посылка все никак не дойдет до Беларуси и, вероятно, идти будет еще долго. Так что, подозреваю, когда она дойдет, я уже буду плотно сидеть на Silica Apollo. Или же буду ждать новых дротиков с нетерпением ;)
Кстати о дротиках McCoy. Раньше я о них вообще не слышал. И что за фирма их производит не знаю. Сайт Real McCoy Darts пока находится на реконструкции. А сами дротики есть в наличии далеко не во всех магазинах.
Однако, если посмотреть на форму и вес моделей дротиков McCoy, то можно заметить, что они практически копируют лучшие модели от Unicorn-а и Target-а. Но по гораздо более привлекательным ценам. Так что я бы рекомендовал обратить на них внимание – может оказаться, что очень хорошие дротики обойдутся всего лишь в 10-12GBP (а не в 20-40GBP как в случае “больших” брендов).
Ну и на последок о главном. С завтрашнего дня стартует Чемпионат Мира по дартс в рамках PDC. Программа уже определена. Сайт bet365.com обещает прямые трансляции. Так что на ближайшие пару недель я по вечерам буду совершенно потерян для общества :)
[prog] Вышла версия 6.0.0 библиотеки ACE
Как и обещали разработчики ACE месяца полтора назад, состоялся релиз версии 6.0.0 библиотеки ACE. Список изменений, правда, не сильно впечатляет:
- изменен формат строки, формируемой ACE::timestamp(). Если раньше она возвращала значение вида "Day Mon dd hh:mm:ss yyyy", то теперь она возвращает строку “yyyy-mm-dd hh:mm:ss.mmmmmm” в соответствии с ISO-8601. Соответственно, изменится вид даты-времени при работе с ACE_Log_Msg и спецификаторе %D;
- полностью удалена поддержка GCC версий ниже 3.0;
- в build-систему ACE добавлена поддержка пользовательских файлов rules.private.GNU, которые, буду найденными в процессе build-а, теперь подключаются файлом $ACE_ROOT/include/makeinclude/rules.local.GNU.
Вот, собственно, и все. Ну плюс несколько багфиксов.
Зачем нужно было обзывать новую версию 6.0.0 – не знаю. Когда руки дойдут ее пощупать – тоже не знаю.
Скачать новую версию ACE (а так же обновленные версии TAO, CIAO и DAnCE) можно отсюда: http://download.dre.vanderbilt.edu/previous_versions/
[prog.work] Вот так бывает в оффшоре
Вчера друг рассказал две истории из его большого опыта работы в крупной оффшорной конторе. Обе о том, с каким трепетом некоторые заказчики (а они же являются владельцами производимого оффшорщиками кода) относятся к результатам работы разработчиков.
История первая. Делается незначительный рефакторинг некоего второстепенного и совершенно не публичного класса – какой-то метод переименовывается, какой-то удаляется, а на его место добавляются пара новых методов. Изменения фиксируются в репозитории. Спустя пару часов от заказчика приходит письмо с просьбой объяснить, зачем и почему были сделаны такие изменения.
Увидев мои круглые глаза друг рассказал еще более замечательный случай. Его коллега руководил проектом для другого заказчика и был вынужден тратить по четыре(!) часа в день только на объяснению заказчику причин внесения в код тех или иных изменений.
Ну что тут сказать… Маразм крепчал, конечно. Но, с другой стороны, как даму обедают, так ее потом и танцуют. Вот хотят танцевать именно так – что остается делать? Поэтому от оффшорных контор лично я стараюсь держаться подальше. Имхо, если уж разрабатывать софт на дядю, то там, где этот дядя сам является владельцем разрабатываемого софта. И живет с этого софта. А не с проданных жопочасов.
вторник, 14 декабря 2010 г.
воскресенье, 12 декабря 2010 г.
[life.photo] Несколько снимков Andrew Zuckerman
На неделе набрел на рассказ о серии фотографии Creature от Andrew Zuckerman. После чего зашел на сайт самого Andrew Zuckerman. И выбрал из серии Creature несколько других снимков (они под катом). Хотя там есть что посмотреть и в остальных сериях. Кроме серии Creature я лично рекомендовал бы посмотреть серию Bird.