суббота, 1 октября 2011 г.

[life.sport.darts] Фотографии большой коллекции дротиков и не только

В одном из англоязычных форумов, посвященных дартсу, наткнулся на персонажа, в подписи сообщений которого дана интригующая ссылка: My Darts Collection, 325 Sets of Darts. И действительно, стоит сходить по ней – там несколько десятков страниц с фотографиями совершенно разнообразных дротиков и прочих вещей, связанных с дартсом.
Особенно интересны фотографии, под которыми есть подписи с небольшими историями. Как, например, вот этот снимок. Оказывается, именно эта модель дротиков стала предтечей весьма удачных, на мой взгляд, дротиков Марка Уолша (которые сейчас выпускаются Target-ом).
Кроме исторического интереса эта коллекция, как оказалось, имеет и практический: например, здесь мне удалось увидеть модель McCoy’s Tankbuster Taper в нормальном виде (а не как маленькую превьюшку в online-магазине).
В общем, я посмотрел с удовольствием. Посему и рекомендую.
Но! У меня, конечно, в руках побывало намного меньше, чем 325 комплектов. Тем не менее, сколько-то побывало. Почти о всех этих моделях я писал. И под катом разместил что-то вроде оглавления своих обзоров.

пятница, 30 сентября 2011 г.

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

Пришло время очередного кинообзора. Как обычно фильмы перечислены в порядке убывания их ценности (с моей точки зрения).

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

Добыча. Отличный фильм.

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

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

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

Восстание планеты обезьян. Красиво сделанная сказочка.

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

Машина времени в джакузи. Добрая сказка для взрослых.

Погоня. Не очень динамично на мой взгляд и совершенно неправдоподобно. Зато гламурненько.

Тор. Красочная, наивная детская сказочка.

четверг, 29 сентября 2011 г.

[life] Практически к анонсу Amazon Kindle Fire увидел жизненную антирекламу электронных читалок

Утром ехал в маршрутке. Одна дамочка достала из сумочки Amazon Kinldle (которая маленькая с клавиатурой). Я еще поразился, какая симпатичная и тонкая штука. Позавидовал, понятное дело.

И тут увидел, как хозяйка сего чудного гаджета читает его. Держа экран не далее чем в 10 сантиметрах от глаз. Когда маршрутку качало на ухабах, она едва не протыкала экран носом.

Жуткое зрелище. Понятное дело, что зрение ей посадила вовсе не читалка. Но все равно картина сия подействовала как мощная антиреклама. И когда придя в офис я узнал про выход Kindle Fire, то даже не заинтересовался. Ну планшет и планшет. Ну и фиг с ним.

[prog.flame] Еще на тему спекуляций вокруг сравнения языков программирования

Небольшое добавление к разговору о спекуляциях вокруг языков программирования, начатом в комментариях к одной из предыдущих заметок. Вот на какой момент я бы хотел обратить внимание: мне на глаза практически не попадались серьезные сравнения языков между собой применительно к какой-нибудь серьезной задаче. То, что приходилось видеть – это либо какие-то мелкие эксперименты (на программах не более 50KLOC, а то и меньше), либо же последствия т.н. big rewritting, когда какую-то систему переписывали с нуля на другом языке.

Понятное дело, что мелкие эксперименты вообще не репрезентативны. То, что 50 студентов на Ruby завершили мелкую задачку в среднем на 15% быстрее, чем другие 50 студентов на Java, и на 30% быстрее, чем еще 20 студентов на C++ – это несерьезно. Поскольку тратили он на разработку по 12-20 часов каждый. Что это такое по сравнении с разработками, в которых только фаза проектирования, в которой задействованы отнюдь не студенты, может растягиваться на месяцы?

Со случаями big rewritting так же все не столь однозначно. Потому, что:

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

Кроме того, такие вещи, как big rewritting встречаются не так уж и часто. Иногда и не давая ожидаемого результата. И, в любом случае, являются очень дорогими мероприятиями. Поэтому-то чаще дешевле сопровождать старую систему, чем переписать ее с нуля.

К чему я это все? А к тому, что объективные сравнения преимуществ одного языка над другим еще нужно поискать. Вместо этого мы, программисты, пытаемся придать видимость объективности нашим собственным пристрастиям. Мол, если мне удобнее что-то делать на C++, то C++ в этих задачах лучше. Хотя кто-то может с точно такой же уверенностью утверждать подобное для Java или Haskell.

Единственный более-менее объективный критерий – это статистика использования того или иного языка в различных нишах. Например, так уж исторически сложилось, что COBOL-а и Java в махровом Ынтерпрайзе больше. А C++ больше на десктопе (особенно на WIntel-е). А Lisp-а в форумных флеймах ;) Значит ли это, что невозможно проникновение языков в “чужие” ниши? Отнюдь. И на Java пишут десктопный софт, а на C/C++ критически важные задачи для банков.

Так что возможно, в принципе, все. Другое дело, в что это обойдется. Практика показывает, что нарушение традиций обходится недешево (народная мудрость о мочеиспускании против ветра возникла не на пустом месте). И вот с этим-то приходится считаться. А разговоры о том, что Haskell позволяет сделать что-то лучше, чем C++ (Java, C#, …) – это все форумный трындеж. Посему хочу в завершении процитировать комментарий ув.тов.Леши Сырникова:

На мой взгляд, языки надо сравнивать исходя из потребностей и целей программиста, который на них пишет и задач проекта. Хочешь зарабатывать бабло - есть привязанные к одной платформе и произовдителю Java и C#, хочешь кроссплатформенное решение - C++. Нужен веб - есть php и RoR (первый более стабилен в API, второй позволяет проще писать крупные проекты) плюс полугиковский Django. Хочешь чего-то написать для себя - выбирай, что нравится.

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

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

вторник, 27 сентября 2011 г.

[prog] Релиз POCO 1.4.2p1

Состоялся релиз версии 1.4.2p1 библиотеки POCO.

Релиз содержит исправления нескольких проблем, которые были созданы в 1.4.2, но которых не было в предшествующих версиях. Данный релиз рекомендуется всем, кто использует у себя классы Poco::SharedLibrary или Poco::ClassLoader. Более подробную информацию можно найти в CHANGELOG.

понедельник, 26 сентября 2011 г.

[prog] Вспомнился случай, когда хотелось иметь горячую замену кода

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

Есть в нашем SMS-шлюзе специальный компонент под названием send.bufferizator. Его задачей является сглаживание резких пиков в количестве исходящих сообщений. Например, происходит какое-то событие и генерируется пачка сообщений, объем которой многократно превышает разрешенную пропускную способность. Скажем, клиенту разрешено 100 sms/sec, а он однократно сгенерировал 500, а затем в течении 5-10 секунд больше ничего не отсылает. В такой ситуации send.bufferizator вбирает в себя всю пачку и отдает ее содержимое не превышая разрешенной скорости – т.е. эти 500 сообщений выйдут из send.bufferizator-а в течении 5 секунд по 100 в секунду.

Данные внутри send.bufferizator хранятся в ОП, не в БД. Хранение в долговременной памяти не нужно, т.к. наш протокол обмена сообщениями устроен так, что операция отсылки является безопасной (идемпотентной, если употребить умный термин) – до тех пор пока шлюз не пришлет подтверждение клиент может (и должен) повторять попытки отсылки. Поэтому, если send.bufferizator по какой-то причине перестает работать, то теряется содержимое его очередей. Но это не страшно, т.к. никаких подтверждений мы клиенту не отсылали и клиент вновь повторит их отправку. Тем не менее, при больших скоростях send.bufferizator может содержать у себя по несколько тысяч сообщений, поэтому прерывать его работу не очень хорошо.

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

Проблема оказалась любопытная – при обработке одной из ситуаций я лишний раз декрементировал текущий показатель нагрузки и, поскольку это был unsigned int, значение переходило через ноль и получалось 0xffffffff. Из-за чего send.bufferizator считал, что нагрузка сейчас многократно превышена и новые сообщения должны приостанавливаться пока она не снизится. А снизится она, понятное дело, не могла.

Лекарство, как и во многих других случаях – “выйти и зайти”, т.е. рестартовать компонент. Однако, ошибка в коде оставалась, я ее быстро исправил. Но для обновления всех компонентов пришлось делать их рестарты, естественно, с потерей текущего содержимого ОП. И вот это был тот самый случай, когда горячая замена только кода работающего модуля, без потери его текущих данных, пришлась бы очень кстати. Т.к. тогда этот bugfix прошел бы вообще никем не замеченный.

Мораль сей басни такова. Если кто-то считает, что некая фича является бесполезной потому, что он не имеет перед глазами примеров ее применения, то это не значит, что фича действительно бесполезная. Скорее это просто отсутствие примеров здесь и сейчас. Но, в свою очередь, наличие примеров не делает фичу очень полезной и очень востребованной ;)

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

PPS. Когда-то на глаза попадалась статья Practical Dynamic Software Updating for C в которой описывалась технология накатов бинарных обновлений на работающий C-шный код. Правда, не могу судить о том, насколько все это жизнеспособно и применимо. Так же не знаю и о дальнейшей судьбе данного исследования.

PPPS. Не могу отказать себе в удовольствии с сарказмом пройтись по цитате, которую thesz вырвал из доклада “Running a startup on Haskell”: Deploying our code is a simple matter of redirecting a symlink, then bouncing the server. Downtime during a deploy is a fraction of a second. Ну прям бином Ньютона ребята выдумали, никто кроме хаскелистов до такого додуматься не смог бы, поэтому этим нужно непременно хвастаться! Хотя такому приему уже сто лет в обед и его переизобретает, имхо, любой разработчик, которому приходится плотно сталкиваться с проблемой развертывания бинарников.

воскресенье, 25 сентября 2011 г.

[life] Понравилось определение искусства

Майкл Фриман, “Искусство цифровой фотографии: Секреты мастерства”:

Искусство – это результат в меньшей степени, нежели намерение.