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

[prog] MxxRu обновился до версии 1.5.5 и поддерживает теперь Ruby 1.9.2

Нашлось время и желание таки побороть изъятие из $: текущего каталога в Ruby 1.9.2 – это сделано в MxxRu 1.5.5. Сделано все просто – в начале всех верхнеуровневых MxxRu-файлов задействована инструкция $:.unshift(‘.’). Так что теперь под Ruby 1.9.2 мои старые проекты собираются так же, как и под предыдущими версиями Ruby.

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

PS. Попутно обновил и RuCodeGen до 0.3.2 поскольку там при обработке встроенных скриптов была та же самая проблема под Ruby 1.9.2. Теперь же RuCodeGen при запуске ruby для обработки встроенного скрипта передает ruby аргумент –I. (т.е. принуждает Ruby искать rb-файлы так же и в текущем каталоге).

четверг, 20 октября 2011 г.

[life.sport.darts] Таки можно обыгрывать n01 на четвертом уровне ;)

Раз уж я начал сегодня хвастаться достижениями, да и прет почему-то сегодня изрядно, то продолжу. Сыграл сегодня 3 сета (до 5 побед в каждом) с n01 на четвертом уровне. Выиграл 2-1 (5-4, 1-5, 5-3). Но если бы решился сыграть еще несколько сетов, то продул бы их все обязательно – уж больно сильное напряжение, после трех сетов уже ноги подкашивались и руки стали чугунными :)

Конечно, реваншем за прошлый разгром это назвать нельзя. Но хоть какой-то прогресс. Хотя бы проблесками :)

[life] Услышал интересную фразу

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

А оно вам надо или это от цены зависит?

Ёмко сказано, имхо.

[life.sport.darts] Прошлая неделя была неделей больших checkout-ов…

В последнее время закрытия от 100 до 120 очков случаются более-менее регулярно – раз в один-два дня. В принципе, закрывать 104, 105, 106, 112, 113 или 115 не так уж и сложно – нужно всего лишь одно утроение (как правило, это T20 или T19). А вот checkout-ы от 120 очков или даже 110 очков происходят крайне редко. Ведь для них нужно либо два утроения, либо же попадание в Bull.

Поэтому прошлая неделя была для меня чрезвычайно уникальной – я умудрился сделать закрытия в 130 (20+T20+Bull), 136 (T20+T20+D8, но осталось за кадром), 138 (T20+T20+D9), 149 (T20+T19+D16) и 150 (T20+T20+D15):


130

138

149

150

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

А сегодня, во время “перекура”, внезапно случился мой новый личный рекорд – закрытие 158!

Приятно. Предыдущее мое наивысшее достижение – 157 – продержалось почти полгода (170 не считаю, поскольку это было не в игре “501”, а в “170”). Надеюсь, это продержится гораздо меньше – еще предстоит покорить 161, 164 и 167 :)

Кстати говоря, больше всего удовольствия я получил от 149 – тяжело было после T20 переключиться на T19, а потом попасть в D16. Удалось сделать его просто потому, что сам не верил, что попаду в нужные сектора.

PS. Что интересно: 4 из 6 последних больших checkout-ов были сделаны дротиками Марка Уолша, обзор которых я постараюсь написать на выходных.

вторник, 18 октября 2011 г.

[life.cats.photo] Маленькие впечатления от выставки кошек

На минувших выходных в Гомеле проходила выставка кошек. Поскольку дочка сходит от кошек с ума, то сводили ее посмотреть. Заодно посмотрели и сами. Чтобы не тратить трафик тех, кому это не интересно, несколько снимков под катом.

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

[prog] Склерозник: подсчет числа единичных битов в N-битовой последовательности

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

Hamming weight из Wikipedia.

Fast Bit Counting (форматирование в примерах кода “поплыло”, но при желании разобраться можно).

Bit Twiddling Hacks (пожалуй, самое внушающее собрание).

PS. Поскольку мне эффективность в данном случае не сильно нужна, то я, пожалуй, обойдусь простым использованием std::bitset::count(), хоть стандарт и не оговаривает требований по эффективности ее реализации.

[prog] Нашел интересное в очередном потоке сознания Стива Йегга

Есть такой известный (надеюсь, в узких кругах) блоггер – Стив Йегг (Steve Yegge). Читать его высерпотоки сознания мне довольно тяжело – слов много, живым английским в достаточной степени я не владею, посему крупицы смысла в потоках словесных кренделей вылавливать непросто (хотя ему можно почти все простить за замечательную заметку Execution in the Kindom of Nouns). Аналогичная история произошла и с его недавним опусом Stevey's Google Platforms Rant – очень много слов о совершенно не интересующей меня проблеме – способности или неспособности Google к созданию платформ.

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

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn't do this will be fired.

7) Thank you; have a nice day!

Что в моем вольном переводе будет выглядеть приблизительно так:

1) Все команды начиная с данного момента должны предоставлять данные и функциональность своих компонентов посредством сервисов со специфицированными интерфейсами.

2) Компоненты должны взаимодействовать друг с другом посредством этих интерфейсов.

3) Не должно быть никаких других форм взаимодействия: ни непосредственной линковки, ни прямого чтения хранилищ данных другой команды, ни модели разделяемой памяти, ни каких “черных входов” или чего-то подобного. Единственная разрешенная форма коммуникации – вызовы интерфейсов через сеть.

4) Без разницы какая технология будет использоваться. HTTP, CORBA, Publisher-Subscriber, слабанная на коленке – все равно. Безосу это по барабану.

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

6) Любой, кто не будет выполнять вышеозначенного, будет уволен.

7) Всем спасибо и хорошего дня!

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

Было это в 2002-м году.

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

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

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

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

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

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

[life.photo] Осень в нашем парке

Были сегодня в центральном парке Гомеля. От прогулки осталось несколько снимков, которые можно увидеть в этом альбоме и под катом.