В июле этого года Google запустил like/unlike в Google Reader. Человек читает статью – она ему интересна – человек отмечает ее как “понравилось”.

Всем читателям этого RSS потока видно, кому понравилась эта статья и сколько их. Задумывалось, что счастливые юзера будут кликать на имена, проверять что там эти люди ещё расшарили интересного и находить себе компанию по интересам.

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

Этакий digg или stumbleupon в миниатюре и совершенно бесплатно.
Ну а теперь как это сделать

Здесь и далее я буду использовать термин RSS как собирательный образ для всех синдикативных протоколов.

Широко известный факт, что Google Reader отдает нормализованные, агрегированные им RSS потоки. Надо только сформировать правильно URL:

http://www.google.com/reader/public/atom/feed/<url encoded feed URL>

Например для http://www.engadget.com/rss.xml это выглядит как

http://www.google.com/reader/public/atom/feed/http%3A%2F%2Fwww.engadget.com%2Frss.xml

Заглянув в source агрегированного Google Reader RSS/Atom потока видим такие теги

<gr:likingUser>00319180390340199299</gr:likingUser>
<gr:likingUser>09803098588727110477</gr:likingUser>
<gr:likingUser>09419458535147286956</gr:likingUser>
<gr:likingUser>01041706060102840430</gr:likingUser>
<gr:likingUser>16152963933826181588</gr:likingUser>
<gr:likingUser>02215958792577066354</gr:likingUser>

Это ID юзеров которые отметили статью как “понравилось”. Можно даже воспользоваться Social Graph API и посмотреть кто же эти люди такие. Или можно посмотреть что эти люди расшарили. Что бы понять как это работает смотрите src линков.

Так как все эти <gr:likingUser> теги видны всем без авторизации то можно автоматически отфильтровывать статьи с низким порогом “понравилось”. Можно вычислять точно количество “понравилось” и делать далеко идущие выводы.

Прямо в RSS потоке Google Reader отдает не более 100 user ID. Но если нужно знать точное число можно сконструировать URL вида

http://www.google.com/reader/api/0/item/likers?i=<gr:original-id>&output=<json|xml>

и пересчитать их всех. Например: JSON, XML

Хорошо работает для популярных, англоязычных RSS. Чем меньше аудитория тем разумеется хуже работает crowd-sourcing.

Если вы слышали про все те проблемы с которыми столкнулись ученые CERN пытаясь запустить Большой адронный коллайдер то вам в голову наверняка приходили такие же мысли как и некоторым учёным – виноват парадокс путешествия во времени.

Большой адронный коллайдер запустили 10 сентября прошлого года, была ещё большая шумиха о возможных весьма неприятных далеко идущие последствиях. Коллайдер сломался 9 дней спустя и с тех самых пор учёные из CERN мучаются, пытаясь поставить его обратно на адронные ноги. Ожидается, что он заработает в следующем месяце, а пока множество теорий пытаются объяснить многочисленные неудачи. Из совсем свежих – арест физика который якобы работает на Аль-Каиду.

Согласно одной из этих теорий, бозон Хиггса отправился обратно во времени что бы предотвратить свое собственное рождение. Идея была рождена даже до того, как сломался Большой адронный коллайдер, и отлично подходит для объяснение почему постройку Superconducting Supercollider в США отменили в 1993 году после того как миллиарды долларов были уже потрачены.

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

Авторы говорят буквально следующее – “Мы предполагаем, что все машины созданные для воспроизводства бозона Хиггса будут иметь плохую судьбу”

Вопрос стоит достаточно серьёзно – неудача с получением бозона может cкомпрометировать всю стандартную физику элементарных частиц.

Само собой, другие уважаемые физики считают, что эта идея совершенно безумна. С другой стороны, если коллайдер сломается опять, наверняка все больше людей начнут разделять точку зрения этой теории. Великий физик Нильс Бор однажды сказал – “Мы все согласны что ваша теория совершенно безумна. Вопрос о том, достаточно ли она безумна, чтобы оказаться еще и верной”

по мотивам Wired

Вроде ничего особенного, но какая композиция! какой свет! какие идеи!

Вот здесь полная галерея
http://www.flickr.com/photos/bunnyrel/sets/72157615647396658/

Three Friends, Beijing, 1989

Don Hong-Oai studied with the famous 104-year-old master, Long Chin-San in Taiwan. Here he learned to work in a Chinese “pictorial” style, using several negatives to compose a picture and perfecting his landscape work. He was honored by Kodak, Ilford and at Fotokina in West Germany and is a member of the International Federation of Photographic Art in Switzerland and the Chinatown Photographic Society

Only Me

Man-made Lake, Guangdong, 1986

Pine Peak

Winter Fog

After Prayer, Vietnam, 1973

Трудно сказать зачем они это затеяли, может потому, что они всегда так делают, но вероятнее всего Microsoft продолжает строить свой software stack для Azure. Velocity = memcached, Dryad = Hadoop + Hive/Pig и т.д.

Но интересно не это, интересна архитектура проекта – наворотили знатно. Velocity умеет всё, умеет как memcached быть простым key-value со стандартным алгоритмом consistent caching и LRU вытеснением – так MS позиционирует Velocity для Web. А может быть сложным кешем с репликацией и гарантированной availability, со сложным routing, с transparent in-process cache с автоматическим обновлением локальных даных, умеет уведомления о изменеии состояния данных, умеет тэги и т.д. такое Velocity MS готовит для enterprise.

В общем, всё о чём можно только мечтать – Velocity умеет. На довесок – REST API, несколько видов упраления памятью, несколько видов блокировок (sic!), кворумы в репликации, failover, горячее добавлеие новых узлов.

Я просто терясь в догадках, зачем кешу всё это. Тут не хватает только disk persistence что бы построить non-sql DB который заткнёт за пояс всё что есть на сегодняшний день.

Замечательная PowerPoint презентация об архитектуре проекта – Project “Velocity”: Under the hood
И статья в MSDN http://msdn.microsoft.com/en-ca/library/cc645013.aspx

Самый распространенный пример – измерение времени отклика сервера на запрос. Допустим у нас всё есть:
- сервер для каждого запроса вычисляет execution time, складывает в счётчик
- сервер умеет отдавать значение счётчика по внешнему запросу
- есть monitoring сервер который собирает значения каждый poll interval, хранит, агрегирует и рисует графики

Решение в лоб – измерять мгновенное значение счётчика – особого смысла не имеет, при poll interval в одну или пять минут, мы получим мгновенное значение производительности системы измеренное по последнему запросу. Если все 5 минут до этого исполнялись запросы по 2секунды или больше, а последний был легкий на 20ms мы увидим только 20ms. Или наоборот.

Стандартное решение – скользящее среднее по последним N запросам. Решение работает замечательно, пока N запросов выполняются за время меньшее poll interval. Если нагрузка падает, получается вот такое вот:

Между полночью и 4-мя часами утра либо не было запросов вовсе, либо было меньше N. Значение скользящего среднего не менялось и создаётся обманчивое впечатление, что сервер обрабатывал все запросы за 6ms.

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

Картина видна гораздо лучше. Видно где были запросы, а где не было.

Модификация довольно простая. Кроме параметра N – размера окна для скользящего среднего. Вводится ещё один параметр – T, время забывания (expiration time), все значения в окне, старше T не учитываются при подсчёте среднего.

Выбор T (ms) для данного значения poll interval (ms) – это другая интересная проблема.
Если T << poll interval, (много меньше) будут потерянные значения
Если T >> poll interval, (много больше) будет график #1
В первом приближении, можно принять T = 2 * poll interval

Processor – 2 quad-core Intel Xeon 2.5GHz CPUs
Memory – 8 GB ECC RAM
Storage – 4×1 TB SATA disks
Network – Gigabit Ethernet

Это конфигурация Hadoop-узла в 4000-ном кластере на сентябрь 2008 года. Характеристики этого самого “сommodity hardware” конечно меняются со временем, но картина становится более-менее понятной.

Что бы примерно прикинуть сколько это стоит – вот голые факты – мы в Viigo за один такой хост платим $1132 USD в месяц. Fully managed hosting @ RackSpace. Free incoming traffic. Годовой контракт. Конечно, если бы мы эти хосты там арендовали сотнями, то цена пошла бы вниз.

“Commodity” не означает “самое дешевое”, дешевые хосты зачастую собраны из самых дешевых комплектующих, которые выходят из строя чаще чем более дорогие (но всё равно “сommodity” класса) детали. Если кластер состоит из десятков, сотен или тысяч машин, дешевые комплектующие выходят боком. Более частые поломки – выше затраты на обслуживание. С другой стороны, машины класса “база данных”, то же не самый лучший выбор – отношение цена/производительность у них так себе. И даже тот факт, что их надо будет меньше что бы построить кластер с заданной производительностью, компенсируется тем, что выход из строя одного такого хоста окажет больший эффект на всю систему в целом.

Рекомендую.