Igor Katkov

Обнаружил интересный hack (?) который даёт ответы на вопросы:
Как автоматически выделять самые интересные статьи из RSS потоков?
Как понять какие статьи пользуются популярностью а какие нет?
Как получить feedback от пользователей которые читают сайт через RSS?

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

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

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

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

Read the rest of this entry »

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

Read the rest of this entry »

Arielle Nadel решила сделать 365 ежедневных фотографий, но не себя, а маленького робота, куклы Danbo.

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

Вот здесь полная галерея
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

Read the rest of this entry »

Замечательный сайт дающий ответ на вопрос “Should I be worried about scaling?” -
http://shouldibeworriedaboutscaling.info

Если кому было мало distributed cache-й, Microsoft строит свой – Velocity.
Релиза ещё нет, есть только несколько Community Technology Preview, но работы ведутся ударными темпами. У проекта есть
блог http://blogs.msdn.com/velocity и
форум http://social.msdn.microsoft.com/forums/en-US/velocity/threads

Трудно сказать зачем они это затеяли, может потому, что они всегда так делают, но вероятнее всего 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

Правильный real-time мониторинг системы, дело не такое простое, как может показаться на первый взгляд.

Самый распространенный пример – измерение времени отклика сервера на запрос. Допустим у нас всё есть:
- сервер для каждого запроса вычисляет 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

В последнее время, кого не послушай, все свои компьютерные кластеры строят на сommodity hardware. Кто ещё не построил – тот собирается. Вот что Yahoo!, примерно, понимает под этим термином:

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” класса) детали. Если кластер состоит из десятков, сотен или тысяч машин, дешевые комплектующие выходят боком. Более частые поломки – выше затраты на обслуживание. С другой стороны, машины класса “база данных”, то же не самый лучший выбор – отношение цена/производительность у них так себе. И даже тот факт, что их надо будет меньше что бы построить кластер с заданной производительностью, компенсируется тем, что выход из строя одного такого хоста окажет больший эффект на всю систему в целом.

В январе 2007, двое убеленных сединами, RDBMS специалиста, David J. DeWitt и Michael Stonebraker опубликовали страшную вещь. А они действительно убеленные сединами,  и действительно специалисты, так вот, они покусились на святое, на MapReduce – см. “MapReduce: A major step backwards” В статье они критикуют MapReduce вообще и называют его шагом назад по сравнению с RDBMS. Само собой, в коментах молодые герои их смешали с говном. Впочем были и аргументированные ответы – см. “Databases are hammers; MapReduce is a screwdriver” И тут Девиду и Майклу показалось мало, они публикуют статью-ответ на всю критику сразу см. “MapReduce II”. Все эти статьи очень интересное чтиво, включая коментарии.

Рекомендую.