Любопытная статья исследователей из университета “University of California Santa Barbara” PDF тут.

Исследователи перехватили контроль над ботнетом Torpig и ковыряли его 10 дней, пока владелцы не накатили обновление и не вернули управление себе. За это время стало понятно какого вида информацию он собирает, как он это делает, как защищается от перехвата управления и на какое поведение юзеров он рассчитан.

Авторы утверждают что Torpig это одно из самых продвинутых crimeware на сегодняшний день. У него самая лучшая программная архитектура, самые остроумные способы воровства данных, самая лучшая топология управления. Также Torpig наносит самый большой финансовый ущерб.
Оценка экономической эффективности $3-300 млн в год. Из упражнений спамеров, ботнеты похоже становятся серьёзным бизнесом.

Работает это всё следующим образом

Инсталяция

Взламываются популярные сайты и вставляется ссылка на специальный JavaScript. Браузер скачивает и выполняет вредоносный JavaScript, код в котором пытается залинковать свою dll в проводник (explorer.exe) используя известные уязвимости самого браузера, его плагинов или ActiveX объектов. Уязвимости перебираются по кругу пока одна из них не сработает. Дальше все операции выполняются как будто бы самим explorer.exe - вполне себе уважаемым процессом. Теперь загружается драйвер ядра, который подменяет оригинальный disk.sys на себя и затирает Master Boot Record (MBR)
Всё, шаг №1 выполнен - руткит Mebroot поставлен. Фокус тут в том, что после перезагрузки Mebroot выполняется самым первым, раньше чем загрузится OS и остается практически невидимым для антивирусного ПО.

Сам по себе Mebroot ничего плохого не делает, но это только платформа для других модулей которые и делают всяческие гадости. Итак, сразу после перезагрузки, каждые два часа Mebroot соединятеся с Mebroot C&C server и качает модули, например Torpig. Все соединения шифруются. Теперь и шаг №2 выполнен - Torpig установлен.

Torpig вставляет линкует свою dll в Service Control Manager (services.exe), проводник и 29 другиз популярных программ, например браузеры - IE, Firefox, Opera, FTP клиенты - CuteFTP, LeechFTP, e-mail клиенты - Thunderbird, Outlook, Eudora, мессенжеры - Skype, ICQ и такое прочее. Теперь Torpig может просматривать все данные которые эти программы манипулируют, выделять интересные куски, например логины с паролями. Каждые 20 минут Torpig закачивает всё что он там насобирал на сервер.

Топология управления

Тут интересное архитектурное решение, если адрес этого C&C сервера известен и более менее постоянен, то его легко можно отфильтровать тем самым нейтрализовав утечку данных. Исторически ботнеты это делают следующим образом - имя домена статично и не меняется, но очень часто меняются IP серверов куда замаплена DNS запись - это делает блокировку по IP не эффективной. Недостаток тут очевиден - статическое доменное имя. Mebroor и Torpig вместо этого генерируют доменные имена по специальному алгоритму, если домен заблокирован, не отвечает на запросы по ботнетовскому протоколу или не существует - генерируется следующее имя и так до победного конца.
Тут надо помнить, что регистрация домена стоит денег, но владельцам ботнета нет необходимости регистрировать все имена - достаточно удерживать контроль над хотя бы одним из доменов который сгенерируют боты. В этой силе кроется и слабость. Если алгоритм известен и предсказуем, нужно зарегистрировать следующий домен которому подчинится ботнет.

Именно так авторы статьи и перехватили управление. На 10 дней.

К чести оригинальных программистов ботнета следует заметить, что эти 10 дней не прошли даром. Они поменяли алгоритм генерации доменных имен, усложнили и внесли недетерменизм. Это сразу сделало перехват управления экономически не выгодным, например новая версия Conficker генерирует 50,000 доменных имен в день, если все их регистрировать это выливается в большие расходы - $91 - $182 млн.

Остроумные способы воровства данных

Тут старый добрый фишинг поднятый на новый уровень. В своём конфигурационном файле Torpig читает имена банковских сайтов. Если юзер посещает такой сайт, Torpig вставляет HTML форму прямо в страницу сайта. Это происходит прямо в DOM-e браузера. Определить это очень трудно - URL сайта верный, стили и картинки соблюдены, и даже SSL тут не спасёт. Все сертификаты верны. Пользователя просят якобы подтвердить свою личность введя номер карты, налоговый номер и прочее.

За 10 дней, Torpig наворовал 300ооо логинов с паролями, 1600 номеров кредитных карт и 8300 логинов в онлайн банкинг. Всего в забеге участвовало 180ооо инфицированных хостов.

Саму цетовую схему взял тут. Недостаток оригинального файла - это полный export всего подряд, а нужно всего только цвета поменять.

Объясняет, как latency коррелирует с прибылью, почему сайты вообще медленно грузятся в браузере и рассказывает как это можно исправить. Утверждает он следующие интересные вещи:

Влияние latency на доход

Google: +500 ms  -20% traffic
Yahoo: +400 ms  -5-9% full-page traffic
Amazon: +100 ms  -1% sales

На конференции Velocity 2009 докладчикам от  AOL, Google, Microsoft и Shopzilla задали вопрос “почему это важно - уделять внимание производительности?”

• Microsof (Bing): увеличение времени отклика на 2 секунды это -1,8% запрос/пользователь и -4,3% дохода с пользователя
• Google: увеличение времени отклика на 400 ms это -0,59% запрос/пользователь
• AOL: 25% падение количества page hits при удвоении времени отклика
• Shopzilla: Ускорение с 7секунд до 2х дало +25% page hits, +7-12%  дохода и 50% экономия на железе

Почему сайты медленно грузятся?

Согласно Souder-а причины могут быть следующие:

• Тормозит back-end
• Тормозит front-end
• Тормозит интернет

Steve говорит, что 80-90% всего времени тратится на front-end и соответсвенно оптимизировать надо как раз эту часть в первую очередь. И дешевле всего и эффект виднее.

Как исправить

Вот его 14 правил:

1. Делать меньше HTTP запросов
2. Использовать CDN
3. Не забыть про Expires
4. Использовать Gzip компрессию
5. Все стили на верх страницы
6. Все скрипты - вниз
7. Избегать CSS expressions
8. Выносить JS и CSS во внешние файлы
9. Уменьшать DNS lookups
10. Сжимать JS
11. Избегать redirect-ов
12. Выкинуть повторяющийся JS
13. Не забыть про ETags
14. Сделать AJAX контент cacheable

Сама презентация поясняет основные приёмы ускорения загрузки страниц:

• сначала грузим только то, что надо для отображения станицы, затем всё остальное
• 6 способов загрузить JS и чем они отличаются
  XHR Eval, XHR Injection, JS in Iframe, JS DOM Element, JS Defer, document.write Script Tag
• как прятать от пользователя что мы ещё не все загрузили (индикатор загрузки в браузерах)
• несколько неблокирующих способов грузить JS
• способы вызова/инициализации JS со страницы, он называет это “coupling techniques”
  hardcoded callback, window onload, timer, degrading script tags, script onload
• какие домены лишние, а какие наоборот надо добавить в round-robin DNS
• почему для статики HTTP 1.0 лучше чем HTTP 1.1
• фокусы с flush() на разных языках
• эффективные и не эффективные CSS

Область практической применимости очевидна и огромна. “Deployed Software” это коммерческий софт. Утверждается, что лучше всего работает в кластерах, уязвимости обнаруженные на одном из хостов, автоматически накатываются на все остальные.

Идея такова:
это самое “Deployed Software” постоянно мониторится на подозрительную активность, например переполнение буферов, подозрительные передачи управления и прочее некорректное поведение. Это само по себе не новость, обычно после обнаружения такой активности приложение прерывается, при повторении - блокируется.

Тут на самом деле две проблемы:

• Если система high availability - ни о каком прерывании или блокировках не может быть и речи.
• Скорость латания дыр в коммерческом софте не велика - буквально через месяц программисты выпускают патч.

Новость тут в том, что ClearView, так называется система, обещает чинить баги и устранять уязвимости в реальном времени без рестартов и человеческого вмешательства.

ClearView сначала собирает статистику поведения во время нормального выполнения, они называют это “инвариантами выполнения”, затем отслеживает активность, при обнаружении подозрений автоматически патчит бинарный код пытаясь восстановить “инварианты выполнения”. Умеет сама тестировать различные варианты исправлений, накатывать и откатывать заплатки. Т.е. фактически пытаться держать систему в устойчивом состоянии, фильтруя input или блокируя и исправляя код.

P.S.
Ещё два шага и программы будут писать сами себя.

Плакат “50 лет космических исследований” от National Geographic. Масштаб не соблюден, траектории не соблюдены, зато видно что исследовалось чаще. Десяток к солнцу, десяток к внешним планетам, и совсем мало в дальний космос. Успехи и неудачи, 200 экспедиций, 50 лет исследований на одной картинке.

Большая картинка здесь

В июле этого года 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

Discipline is the
bridge between goals
and accomplishments

Набрано было стилизованным под готику шрифтом. Девушка читала курс органической химии.

Дисциплина это конечно наше всё, но каким же надо быть лодырем, что бы сделать себе такое напоминание…

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

Жили были item-ы и было у них sequential numeric id.

То, что оно sequential - это тяжелое наследие царского режима, потом пришли большевики, но ничего сделать было уже нельзя.

#0

И вот, при Николае-батюшке, было это autoincrement поле в MS SQL, item-ы получали id при вставке и никто горя не знал. Очевидно для того, что бы узнать это id на клиенте надо вставлять item-ы один за другим.

#1

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

#2

Нагрузка возросла - сделали вставку item-ов сразу пачками, а генерацию соответсвенно тоже поменяли, что бы генерировать сразу на всю пачку за один запрос. Стандартная hi-lo процедура (см ниже). Скажем, если вставляется 10 записей - один запрос на генерацию 10 ids.

#3

Нагрузка возросла - сделали пре-генерацию id наперёд блоками и кеширование этого блока на клиенте. Скажем, если вставляется 10 записей - один запрос на генерацию 1000 ids. 10 используются сразу, а 990 ждут следующего раза.

При порядка 700 витках (threads), которые всё время пишут в базу, эффект поразительный.

А вот если бы сесть и подумать, можно было бы сразу с последнего пункта начать…

hi-lo cхема выглядит так:

Таблица в БД

CREATE TABLE IDTable(
TableName varchar(255) NOT NULL,
NextID bigint NOT NULL,
CONSTRAINT IDTable1_PK PRIMARY KEY CLUSTERED( TableName ASC)

SQL запрос на генерацию примерно так

DECLARE @LocalTempTable  table(id int)
DECLARE @NEXTID INT
DECLARE @CNT INT

BEGIN TRAN
SELECT @NEXTID = (SELECT NextID FROM IDTable WITH (UPDLOCK) WHERE TableName = @@TABLENAME)
SET @CNT = 0
WHILE(@CNT < @@COUNT)
BEGIN
INSERT INTO @LocalTempTable(id) VALUES(@NEXTID + @CNT)
SET @CNT = @CNT + 1
END
UPDATE IDTable WITH (UPDLOCK) SET NextID = @NEXTID+@CNT WHERE TableName = @@TABLENAME
COMMIT
SELECT id FROM @LocalTempTable

Где TABLENAME это имя последовательности, а COUNT это размер пачки.

Самый интересный фокус тут это SELECT … WITH (UPDLOCK). Клиенты делают запросы указывая размер пачки, а потом либо тратят ее всё как в случае #2 либо кешируют часть про запас, как в случае #3.

Некоторые размер пачки хранят прямо в таблице, отсюда и название. У этого подхода есть одно достоинство - можно централизованно управлять сколько ID создать. Но это же одновременно и недостаток - часто нужно здесь создать1000 штук, а тут только 10.

Вот тут есть не плохой обзор доступных способов получения ID

Обычные распределённые системы, RDBMS и J2EE контейнеры, целостность ставят во главу угла. Все эти фокусы с блокировками и распределенными транзакциями даются дорогой ценой. Эта цену большие распределенные системы платить не готовы, им нужно прежде всего availability. Поэтому Google, Amazon и некоторые другие крупные компании построили свои собственные инфраструктуры.

Werner Vogels, Amazon VP & CTO, популярно объясняет почему двух фазный коммит это плохой выбор если нужно строить scalable систему. Он ещё, ведет блог All things Distribtued для тех кому интересно.

Для того что бы система расширялась нужны асинхронные, stateless сервисы, а целостность приходится компенсировать сложными согласованиями-компенсациями в случае ошибок. Ну и конечно, модель данных оказывает существенное влияние на производительность. Чем проще - тем быстрее. Тут можно вспомнить про Dynamo от Amazon и MapReduce/BigTables от Google.

CAP Theorem-а утверждает, что система может удовлетворять не более двум требованиям из трех: целостность (consistency), доступность (availability) и терпимость к разделению (partition tolerance).

Где:
целостность (consistency) - гарантирует, что все клиенты всегда прочтут одинаковые данные, в не зависимости к какому узлу в кластере они обратились. Операция записи атомарная для всех узлов.

доступность (availability) - гарантирует, что в в случае любого (разумного) отказа, клиенты все равно смогут получить доступ к копии их данных.

терпимость к разделению (partition tolerance) - гарантирует, что система остается работоспособной даже если авария сети приведет к образованию двух или более под-кластеров.

У этой теореме существует формальное доказательство. Работа 2002 года, ссылается на публикации конца 80-х начала 90-х.

Она, прямо как в блокадный Ленинград, открыта только пару месяцев в году, когда лёд станет толще 70см, достаточно толстым для больших, многотонных грузовиков.

Эти большие, многотонные, грузовики везут шины

и кузова для ещё больших грузовиков

А фотографии прекрасны конечно, восходы, закаты, -40С…

На сайте National Geographic есть небольшой ролик

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

Сайт с разбором-пояснениями.

Рекомендую.

News of Jackson’s death spread quickly online, causing many websites to experience technical difficulties under the unanticipated swell of users. Google announced technical difficulties after a sudden swell in searches for “Michael Jackson” led the company to believe it was under attack from hackers, while social networking site Twitter reported a crash after record numbers of users used the site to spread the news of Jackson’s death.[175] Wikipedia experienced technical difficulties, and crashed at 3:15 PDT reportedly due to excessive edits and user overload.[167]

wiki

Я тоже сначала думал что нас в Viigo атакуют. Трафик обычных запросов прыгнул на 15% в течении 10-20 минут. Трафик запросов к рекламным банерам - на 40%. Целый час потратил, что бы понять кто все эти люди и откуда они взялись. Мысль про Джексона приходила в голову, но я ее отмёл как несостоятельную.

Если бы мне кто-то сказал, о таком несколько дней назад, я бы не поверил…

…мне всегда претила одна только мысль о том, что я должен, как робот, встать в 7 утра, отправится в скучный и унылый офис, просидеть там штаны до 6 вечера, а потом уставший пойти домой. Это же скучно, чем бы вы не занимались.

как же я рад, что у мне интересно и не скучно то, чем я занимаюсь. И даже немножко жалко тех людей которые убивают часть своей жизни просиживая штаны.

«Вы — руководитель проекта, который начинается с завтрашнего дня и заканчивается ровно через год. Все планы утверждены, команда подобрана, роли определены. И вдруг… Становятся известны результаты проведенного маркетингового исследования, которые говорят о том, что конкурирующая компания планирует выпуск такого же продукта с той же функциональностью, но месяцем раньше. Ваш топ-менеджмент настаивает на завершении проекта тремя месяцами раньше.»
Из ограничений: нельзя уменьшать функциональность и качество, увеличивать объём ресурсов и стоимость.

Что должно сразу приходить в голову хорошему руководителю проекта?
Ему должны сразу приходить идеи и идеи во множестве.
Например

В конечном счёте всё равно либо придётся вносить изменения в функциональность (не обязательно в сторону ухудшения, но однозначно в сторону уменьшения трудоёмкости), либо находить «из воздуха» дополнительные ресурсы (не те, за которые платит компания): увеличение рабочего дня на энтузиазме (что плохо), привлечь десяток студентов-программистов на практику, организовать юзабилити-конкурс на лучшее решение сложной задачи и т. п. Так или иначе, за эти ресурсы просто заплатят другие: сотрудники, студенты, участники конкурса.

Или вот

1) вторым быть проще (не помню, где читал)
2) вы не уточняете, увеличивать стоимость чего нельзя. если речь идет только о разработке, то можно увеличить маркетинговый бюджет
3) есть утопические варианты вроде саботажа =)
4) группировка функциональности и запуск «облегченной» версси продукта за 6 месяцев, и выпуск полной за 12.

Отсюда

Intro session - Todd Lipcon, Cloudera
Voldemort - Jay Kreps, Linkedin
Cassandra - Avinash Lakshman, Facebook
Dynomite - Cliff Moon, Powerset
HBase - Ryan Rawson, Stumbleupon
Hypertable - Doug Judd, Zvents
CouchDB - Chris Anderson, couch.io
VPork - Jon Travis, Springsource
MongoDb - Dwight Merriman, 10gen
Infinite Scalability - Jonas S Karlsson, Google

Начинают появляться слайды и видео докладов. Кому интересно - могут пройти в закрома. Хорошее место Silicon Valley, всё самое интересное происходит там. В Торонто какие-то убогие сборища в последнее время происходят только. Вот Microsoft рассказывает про OpenSource. Молодой человек на главной странице, очевидно, олицетворяет target группу.

Ссылается на работы Lamport-а 1978 года, это тот самый кто придумал такие алгоритмы для distributed computing как Vector clock и Paxos. Довольно странно читать научные работы 30-ти летней давности и отчеты о самых свежих, bleeding-edge, программных разработках, которые эти самые работы используют. То ли програмная индустрия безнадежно отстаёт от учёной мысли, то ли учёная мысль вырвалась вперед.

Вот и Last.fm присматривает key-value storage для себя
http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/
пишет Richard Jones, бывший Last.fm CTO. Коментарии к посту тоже интересны.

The law of big numbers insures that all probabilities becomes certanties.

А вот тут видно как пчела держит в лапках шарик пыльцы

Очень удобно, никаких дополнительных программ, только браузер. Перед инсталляцией нужно не забыть поставить PHP development module

apt-get install php5-dev

А потом обернуть нужный код в

xhprof_enable();

<some code is here>

$xhprof_data = xhprof_disable();

и готово.

Я для удобства обернул вообще все вызовы, и отдавал ссылку на страницу с собранной статистикой прямо в HTTP header. Выглядело вот так

// start profiling
xhprof_enable();

<some code is here>

// stop profiler
$xhprof_data = xhprof_disable();
include_once $XHPROF_ROOT . "/root/xhprof/xhprof-0.9.1/xhprof_lib/utils/xhprof_lib.php";
include_once $XHPROF_ROOT . "/root/xhprof/xhprof-0.9.1/xhprof_lib/utils/xhprof_runs.php";
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_foo");
header("x-company-name-profile: http://xhprof.company-name.com/index.php?run=$run_id&amp;source=xhprof_foo");

xhprof.company-name.com прописал в hosts на своём компьютере. А на сервере добавил в конфигурацию Apache виртуальный хост

<VirtualHost *:80>
    ServerName xhprof.company-name.com
    DocumentRoot /root/xhprof/xhprof-0.9.1/hprof_html
    <Directory /root/xhprof/xhprof-0.9.1/hprof_html>
        AllowOverride All
    </Directory>
</VirtualHost>

Любопытно конечно сравнить с другим профайлером - XDebug

Если я правильно понимаю результаты с официальной страницы Kestrel даёт  227.5 транзакций в секунду на 2.5GHz 2008 model Macbook Pro.

В то время как ActiveMQ даёт 2000 транзакций в секунду на более медленном Intel Celeron 2.4 GHz.

И я даже не буду вдаваться в размеры самих сообщений, потому что сравнение будет ещё больше в пользу ActiveMQ.

И какой смысл в существовании Kestrel?

“…One of the most important changes they introduced to improve performance in the last nine months is moving from a Ruby messaging middleware to a custom build JVM-based messaging middleware written in Scala.”

говорит Evan Weave

А вот и оригинальная презентация

Плохое решение

Multipart/mixed MIME messages.

Так как HTTP протокол полон приятных сюрпризов, то есть ещё один способ втиснуть несколько request-ов в один, и соотвественно несколько respons-ов тоже, в один. Всё, что надо сделать - это указать “Content-Type: multipart/mixed”. А затем аккуратно перечислить все что надо. Разделительные символы прилагаются.
Вот пример

POST /batch-proxy HTTP/1.1
Host: example.org
Content-Type: multipart/mixed; boundary=batch

-batch
Batch-Operation: POST /my/resource1
Host: example.org
Content-Type: application/xml
<?xml version="1.0″?>
<entry xmlns="...">...</entry>

-batch
Batch-Operation: DELETE /my/resource2
Host: example.org
If-Match: "ABC123XYZ"

Выглядит замечательно, не так ли? Снимается проблема ~37% overhead в трафике, так как можно текст передавать как текст, а двоичные данные как двоичные данные. Правда на этом достоинства и кончаются. А проблемы всё теже самые, и не REST и security hole, и не прозрачность в общем, смотри выше по списку.

Кроме того, надо помнить, что MIME был создан для передачи 8-битного текста через 7-ми битный SMTP. Да в нём есть много интересного, но HTTP не является MIME совместимым протоколом. Есть тонкие различия вызванные в основном тем, что HTTP оптимизировался для передачи данных через двоичные соединения + обратная совместимость, а у MIME были совсем другие проблемы - вроде ограничения на максимальную длинну строки в e-mail. Всех желающих углубится в эти различия приглашаю ознакомится с секцией 19.4 RFC2616

На практике всё это означает, что клиенту и серверу нужно иметь качественный парсер MIME сообщений. Не просто продвинутый HTTP клиент, но и такой довольно экзотический парсер. По этому пути пошли ребята из Microsoft построив свою ADO.NET Data Services Framework а также в Google - batching для GData. Если вам такой путь приемлем - то для Java есть бесплатный mime4j, а для .NET есть комерческий Mime4Net.

Для тех, кто не хочет возится с MIME есть уж совсем плохое решение

Совсем плохое решение

XML/JSON mark-up
Берем и решаем задачу в лоб. Конвертируем всё в текст, для разметки используем XML или JSON.
Пример с JSON

POST /batch-proxy HTTP/1.1
Content-Type: application/json
Accept: application/json
X-HTTP-Method-Override: BATCH
[
 {
   "method" : "PUT",
   "url" :  "http://someserver.com/some/resource/url",
   "body" : "<request body goes here>",
   "If-Match" : "xxxxxxxxxxx"
 },
 {
   "method" : "GET",
   "url" : "http://someserver.com/some/resource/url2"
 },
]

Пример с XML

POST /batch-proxy HTTP/1.1
Content-Type: application/xml
Accept: application/xml
X-HTTP-Method-Override: BATCH
<?xml version='1.0'?>
 <batch xmlns:b='http://batch.someserver.com/schema'>
  <b:request verb='put' uri= http://someserver.com/some/resource/url'>
   <b:headers>
    <b:header name='Content-Type' value='text/xml; charset=UTF-8' />
    <b:header name='Content-Length' value='XXX' />
   </b:headers >
  <b:body>
    <![CDATA[ ... ]]>
  </b:body>
 </b:request>
 <b:request verb='get' uri='http://someserver.com/some/resource/url2'>
  <b:headers>
   <b:header name='Accept' value='text/xml' />
  </b:headers >
 </b:request>
</batch>

Очевидно, что XML намного более избыточен, но решение следует принимать на основании доступности того или другого парсера. Ответы сервера выглядят точно также.

Таким образом:

• Каждая операция состоит из “конверта”, который содержит HTTP заголовки и тело запроса
  • “method” and “url” обозначают соотвественно HTTP verb и URL операции
  • “body”, обязательное только для POST и PUT, содержит данные которые были бы переданы в стандартом теле HTTP request/response
• Произвольные HTTP заголовки тоже могут быть указаны как в request так и в response

А вот так например может выглядять response содержащий двоичные данные

200 OK
Content-Type: application/json; charset=UTF-8'
[
 {
  "code" : 200,
  "Content-type": "application/octet-stream",
  "Content-transfer-encoding": "base64",
  "body": "PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R=="
 }
 {
  "code" : 200,
  "Content-type": "application/octet-stream",
  "Content-transfer-encoding": "base64",
  "body": "PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R=="
 }
]

Что же плохого в этом решении? А все из списка приведенного в самом начале статьи. Всё что ни возьми - всё и плохо, и не REST. И тем не менее этот подход является самым простым для реализации. А простотой не стоит пренебрегать.

Есть несколько приёмов которые помогут предложить пристойные ответы на список недостатков. Можно

• запретить запросы ко внешним серверам
• запретить рекурсивные запросы к самому себе
• ограничить количество запросов в пакете
• ограничить общее время выполнения всего пакета и высылать на клиент HTTP error code 206 - Partial Content, в случае превышения
• прекращать выполнение всего пакета после первой же ошибки
• использовать протокол HTTP 1.0 при исполнении запросов в пакете
• декларативно отказаться от атомарности операций
• декларативно отказаться от оптимизации порядка или распаралеливания выполнения запросов
• принимать только операции типа GET

«Идеальное» решение

HTTP 1.1 протокол изначально поддерживает приём-передачу нескольких request-response. Для этого нужны persisted connections, pipelining и chunking см ниже.

Клиент открывает соединение, пишет туда request-ы, читает respons-ы. Кроме очевидных требований о поддержке этих persisted connections, pipelining и chunking на сервере и клиенте, есть ещё одна неприятность -  протокол требует, что бы клиент выслал заново все свои запросы сделанные в рамках этого pipelined соединения если оно прервётся в середине сеанса. А для того, что бы эту перепосылку можно было сделать без опаски, все запросы должны быть idempotent, т.е. только GET, HEAD, OPTIONS, PUT и DELETE. Это решение действительно очень хорошее с точки зрения REST - URI уникально адресуют ресурсы, HTTP headers означают правильные вещи и обрабатываются правильным образом, все транзитные сервера видят HTTP метод и могут, что-то правильное по этому поводу предпринять.

Однако, это «идеальное» решение существует главным образом на бумаге. Persisted connections не поддерживают мобильные устройства. Не все HTTP клиенты умеют читать chunked responses и использовать pipelining, привет AJAX рещениям. Да что chunked responses - для многих библиотек послать PUT запрос - уже проблема. Финальным аккордом тут является отсутствие поддержки метода POST в HTTP pipelining.

Раз «идеальное» решение не подходит, вернёмся к идее тунелирования HTTP протокола внутри HTTP.

Что такое persisted connections, pipelining и chunking:

Persisted connections

По умолчанию все соеднинения в HTTP 1.1 постоянные. Сервер не закрывает соединение сразу после обработки запроса тем самым позволяя клиенту использовать это соединение опять и опять. Если клиент желает получить несколько ресурсов с одного и тогоже сервера получается большой выигрыш в производительности. Вместо того, что бы открывать несколько соединений, все запросы пройдут по этому единственному каналу. Как клиент так и сервер могут оборвать этот канал с помощью HTTP header «Connection: close». Интересно, что запросы-ответы не обязаны быть строго последовательными, другими словами, клиент не обязан ждать ответа на первый запрос, а может сразу делать следующий и следующий, это становится возможным благодаря

Pipelining

Клиент посылает серию запросов, а сервер возвращает ответы в том порядке в котором были получены запросы. Часто бывает, что содержимое ответа генерируется динамически и сервер не знает точную длину которую следовало бы поместить в HTTP header Content-Length. Это нормально, в HTTP 1.1 в отличие от HTTP 1.0 заголовок Content-Length не является обязательным.

Так как Content-Length не передаётся, то нужен какой-то механизм, который бы сообщил клиенту, где кончается один response и начинается следующий. HTTP 1.1 решает эту проблему с помощью

Chunking

В случае динамических ресурсов, когда response не содержит Content-Length, он содержит Transfer-Encoding: chunked. Само же тело содержит куски с указаннием длины индивидуального куска. Кусок нулевой длины отмечает конец respons-а. Тут, пользуясь случаем, передаю привет IE6, который виснет, если ему этот последний кусок не передать.

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

Что же делать? К сожалению существует только плохое решение и очень плохое.



продолжение см часть III “Плохие” решения

Если вы разрабатываете REST API, то рано или поздно к вам придут ваши клиенты с просьбой сделать пакетную обработку. Сделать так, что бы сервер приимал произвольный набор запросов одним пакетом и отправлял назад все результаты тоже одновременно. Это касается не только GET запросов, а любых методов - PUT, POST, DELETE и т.д. Ответы тоже будут разные, и будут содержать различные типы данных - например текст в различных encoding-ах и charset-ах, или двоичные данные в произвольном формате. В общем случае, скажут они, было бы полезно уметь обрабатывать пакеты любых HTTP запросов, в том числе запросы к внешним серверам которые необходимо исполнить последовательно с запросами к серверам из локальной сети.

С первого взгляда это кажется замечательной идеей. Клиент делает единственный POST запрос, получает единственный ответ и здорово экономит на сетевых задержках. На самом деле, здесь столько подводных камней, что вы сможете пожалеть что вообще с этим связались. Но выбора обычно нет. Что же тут плохого? Посмотрим сначала на

Религиозные проблемы REST

• Очевидно, что URI этого прокси одинаков для пакетов любых запросов - на вход поступауют произвольные запросы, на выходе мы имеет произвольные ресурсы. Значит этот URI перестаёт уникально идентифицировать ресурсы которые этот прокси обрабатывает
• Требуемая операция содержится не в HTTP verb, а в теле запроса. И несмотря на то, что POST request вроде как является non-idempotent & non-safe - внутри может быть что угодно - как набор совершенно безобидных GET запросов, так и действительно non-idempotent POST запросы, а может быть и вовсе некоторая смесь из них. Только клиент и сервет знают, что же там такое внутри. HTTP метод перестал быть понятным для всех транзитных серверов, таких как HTTP прокси и кеши
• В зависимости от набора запросов в пакете, сервер может создать новые ресурс(ы), обновить или удалить старые, или просто вернуть запрошенный ресурс. Некоторые из этих запросов могли завершиться с ошибкой, а другие были успешными. Передать эту информацию обратно клиенту в HTTP header нелегко, значит она будет втиснута в body ответа. Значит response тоже перестал быть прозрачным для всех транзитных серверов

Ну вот и всё, что бы из REST сделать SOAP больше ничего не нужно. На самом деле, стало даже хуже, чем если бы SOAP использовалось с самого начала - транзитные сервера теперь не знают у каких request/response HTTP headers значат то, что написанно в спецификации, а у каких уже ничего не значат.

Существуют также и

Прочие недостатки пакетирования запросов

Каким бы образом это решение не было бы сделано, результат будет являться тунелированием HTTP протокола внутри HTTP протокола. Задумайтесь на секунду, что это значит.

• Клиенты должны понимать все тонкости HTTP, и не только на этапе создания пакета запросов, но также они должны иметь обработчики ошибок, повторов и т.п. Они должны уметь обрабатывать все фокусы HTTP протокола - chunked и gzipped ответы. Перенаправления и HTTP headers
• Транзитные сервера перестанут кешировать, исчезнет поддержка ETag, If-Modified-Since и т.п. А умные load-balancer-ы перестанут load balance-ить
• Сломается “conversation pattern” если таковой будет подразумеваться конечным сервером.
• Огромная дыра в security, привет системным администраторам
• ~37% overhead в трафике из-за преобразования двоичных данных в текст, а также неизвестный CPU overhead на сервере и клиенте что бы эти данные кодировать-декодировать
• Поддержка атомарности выполнения всего набора запросов
• Определение порядка выполнения запросов в наборе

На самом деле, если заглянуть в спецификацию протокола HTTP 1.1 то можно увидеть, что существует «Идеальное» решение


продолжение см часть II “Идеальное” решение

Но любим мы его не только за это. Любим мы его за живописание быта тех дней. Художник не разменивался по мелочам и рисовал только про пьянки и про индейцев. Строго говоря он писал только четыре типа картин:

1. Перевернутые сани
2. Бухие французы
3. Охотники с добычей
4. Индейцы на привале

Krieghoff, конечно, был настоящим мастером, вариаций этих четырёх тем он наплодил изрядно.

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

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

Каждый человечек отлично прописан во всех деталях, включая емкости с алкоголем.

А вот, извольте, французы напились и не заплатили за платную дорогу. Мальчик кричит им вслед непечатные слова, а инвалид смотритель даже порывается догнать.

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

Интересно, картины Krieghoff были настолько популярны, что раскупались как горячие пирожки, а в 19-том веке даже был черный рынок поддельных картин. Быть может это объясняет однообразность сюжетов. Официальная критика объясняет тематику нарушения закона - буйным духом художника.

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

Одна эта экспозиция стоит похода в AGO.

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

Так вот сегодня, этот телефон меня уведомил, что он тут себе скачал новую прошивку и собирается перегрузиться. Спрашивал, не против ли я это сделать прямо сейчас, или может на потом отложить…

Это просто финиш, наверно настольные офисные телефоны это последние устройства перед холодильниками от которых я жду такого.

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

Главным назначением этих танкеток считались подрыв фортификационных сооружений, разведка системы ПТ огня, расчистка минных полей и борьба с танками.

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

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

Goliath широко использовались на Восточном фронте. Боевое крещение танкеток пришлось на Курскую битву на северном фасе во время проведения операции “Цитадель”. Их использовали для проделывания проходов в минных полях, разрушения долговременных огневых точек и укреплённых городских зданий, а также других препятствий. Пытались пустить Goliath и против танков. Однако затея практического успеха не имела из-за уязвимости машины. Ее 5-мм листы из мягкого железа пробивались винтовочными пулями, а кабель управления нередко повреждался взрывом мины или снаряда. Эффективность танкеток оказалась низкой. Емкости аккумуляторных батарей хватало только на 5 - 8 минут движения. Малая скорость движения затрудняла их использование против подвижных объектов, малый клиренс, снижал проходимость на местности. По оценке специалистов “попасть такой торпедой под движущийся танк трудно даже с расстояния 100-150 м”. Для инженерных же целей заряд танкетки был слишком мал. Танкетки применялись ограниченно.

В свете инструментации кода, мониторинга и сбора статистики не смог пройти мимо довольно интересных средств визуализации. Нельзя сказать, что такого раньше совсем не было, можно только сказать - что такого качество, даже за деньги, ещё поискать надо. Итак, о Google Chart API,  Google visualization API и о том, как сложно сделать простую вещь.

В декабре прошлого, 2007-го года, Google открыл доступ к своему Chart API. Идея очень простая - специально сконструированный URL возвращает картинку. Использование бесплатно, упоминают некий предел в 250ооо вызовов в день (~3 в секунду) после которого надо договариваться с гуглом отдельно.

Вот пример -

http://chart.apis.google.com/chart
?chxt=x,y,r,t
&cht=lc
&chd=s:cEAELFJHHHKUju9uuXUc
&chco=76A4FB
&chs=200x125

Типов графиков много, есть даже такие экзотические как этот

или этот - географические карты

Графика с временной линией нет, к сожалению. Для того что бы отобразить процесс надо самостоятельно заниматься группировкой.
Другая понятная, но не очевидная вещь - данные заполняют всё пространство графика и соответственно растягиваются/сжимаются в зависимости от того сколько их там:

Идеальная замена генерации графика внутри браузера средствами JavaScript. Нагрузку перенесли с сервера на клиент, и теперь ещё раз с клиента на сторонний (Google) сервер. Не ясно, насколько забота о нагрузке клиента актуальна сегодня, но в 2006-том, когда я последний раз этим занимался, было очень актуально.

В этом месте опытные товарищи должны были вспомнить о практическом ограничении длины URI в HTTP. Так как данные передаются прямо в URL - то запихнуть туда можно их вполне ограниченное количество. См предложенные способы кодирования входных данных.

Особенно опытные должны были также подумать о интернационализации. Тут всё плохо - поддержки нет, даже если вы не забудете сделать urlencode текста набранного не латинскими буквами.

Для публичного сайта, или стартапа какого - это просто клад. С коммерческим применением не всё ясно - можно ли себе позволить полагаться на внешний сервис? Как быть если сервис завтра исчезнет? Что если данные по которым это всё генерируется - private? и т.д.

С архитектурной точки зрения - сервис просто конфетка - яркий пример того, как сложно сделать простую вещь.

На этом дело, впрочем, не закончилось, и спустя полгода, весной 2008-го Google выпускает Google Visualization API. Теперь визуализация ещё сложнее - DHTML и flash. Правда и возможности шире. Вот пример - выглядит просто потрясающе

Графики эти не просто интерактивные, данные могут быть подгружены динамически - тут надо либо самому их отдавать особым образом (JSON, CSV) смотреть как именно, либо закачать в документ Google Spreadsheets. Там целое локальное API смотреть API вокруг этого наворочено.

Любопытно, что мелкий временной процесс и тут не просто отобразить, самый мелкий шаг этого графика - 1 час. Если со статическими графиками ещё можно было что-то придумать - то тут уже всё - никак нельзя.

Кроме такого выдающегося контрола, есть таблицы с сортировкой по клику, интерактивные столбики, пироги и географические карты смотреть что ещё есть . Везде JavaScript и Adobe Flash т.е. решения довольно тяжеловесные, что не умаляет конечно, простоту анализа отображенных данных.

Отличная демонстрация на живом бизнес примере - Google Analytics практически полностью построен на этих графиках.

Всё опять совершенно бесплатно. Никаких ограничений вроде 250ооо вызовов, только Google Term of Service

Меня не отпускает ощущение, что легко визуализировать только относительно статические данные, а с динамикой придётся либо основательно повозиться (JavaScript code) либо устроить себе агрегирующий код на сервере, с которого и кормить цифрами эти контролы.

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

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

Может в образовании дело - Жанат самокритично пишет

Мои университеты — работа на базаре. Окончив школу, я пошел работать на рынок «Тастак» помощником кладовщика.

А может в отсутствии опыта… “Путь безнадежного” я осилил лишь страниц на 20.

Официальная аннотация гласит:

За рекою Юбен лежат Дикие земли, где нет торных путей, и всякий странник избирает свою тропинку – в надежде остаться в живых. Потому что немногие выбирались оттуда целыми, а выбравшиеся рассказывали страшное. Только о месте, называемом Каменный лес, не рассказывал никто… никто оттуда не возвращался. Кто пойдет в вечную ночь Каменного леса по собственной воле? Морган и Тури, которым просто нечего терять, ибо на руках их – кровь, за спиной – смерть, и никто не пощадит тех, что имели несчастье родиться оборотнями…

На самом деле, в мире двух солнц, что уже само по себе необычно для фэнтези, два (sic!) главных героя идут с одного края карты на другой. Качественно так идут, с приключением, с фатализмом, с друзьями и предателями. Книга предсказуемо заканчивается, когда кольцо брошено в Ородруин каменный трон захвачен. Даже жалко, что нет никакого продолжения, приквелов и сиквелов.

Другой интересный фокус - у книги два автора - женщина и мужчина и главы соответственно чередуются, как солнца в этом мире - одна глава от Васильева, следующая от Ли и т.д. Получается очень складно, Васильев пишет за мужского оборотня, Ли - за женского. От главы к главе меняется стилистика, теже самые события пересказываются ещё раз, но уже с другми деталями и всё такое прочее.

Замечательно! Рекомендации лучших собаководов.

Download audio file (melnitsa-mokosh.mp3)

А вот справка, для тех, кому слово мокошь ни о чём не говорит,  Мокошь - славянская богиня коша или хорошего урожая. Она же почитается как богиня удачливой судьбы с рогом изобилия в руках. Мокошь покровительствует домашнему хозяйству и семейному очагу и счастью. Как бог Перун является покровителем мужчин, Мокошь оберегает всех женщин. Богиню представляют женщиной с большой головой и с длинными руками, по ночам прядущей в избе. И у славян не принято оставлять на ночь в избе пряжу из опасения, что ее опрядет Мокошь. Мокошь окружают Беригини, и близок богине бог Переплут.
Славяне представляют Мокошь богиней, прядущей нить судьбы.

Paul Tyma, автор, конечно немножко обманщик - он сам себе заказчик и волен менять условия как ему вздумается, но в остроте ума ему не отказать.

Paul Tyma два раза молодец - вместо того, что бы письма форвардить куда скажут - он только показывает их на своём сайте, крутит рекламу и в ус себе не дует.

На таких как Paul Tyma надо равняться!
Java guy, работал в Google, теперь трудится как CTO в компании которая делает известный обфускатор кода - Dotfuscator для .Net

Тут Paul в третий раз молодец - для Java разве продашь что-то? так, срам один, а на любителях Microsoft и заработать не грех.

Есть набор юнит тестов (nunit) на C#, которые на самом деле не юнит, а вовсе даже acceptance/functional tests. Есть также желание их запускать через web. Нету только возможности. В стандартной поставке nunit есть GUI runner, есть консольный runner, а вот ASPX runner-a нету.

Покопавшись в интернете я нашёл некий runit 2.4.2, даже вместе с исходниками. Как и следовало ожидать, работать он отказался. Сначала жаловался на несоответствие assembly-ей, потом, после пересборки из исходников стал имитировать работу, рисовать web интерфейс, но тесты всё равно не запускает. Говорит - TestFixtureSetUp exception и всё тут. Пол дня воскресенья убил, уже наверно мог своё написать… Сдался, выкинул runit, а проблема всё равно осталась.

Можно конечно в CruiseControl.NET подцепить, как проект без исходников и артефактов, но как-то оно там не к месту вроде…

В общем рынок поразительно пуст - для functional tests предлагаются монстры вроде QEngine, QTP и прочего. На другом конце спектра питоновский twill. А по-середине - ничего нет. А делов-то! REST API протестировать, куда уж проще.

Справедливости ради, стоит заметить, что с Java было бы ничуть не легче. Я поначалу нашёл замечательный RestClient (с исходниками) Обрадовался ужас как, думал - вот оно торжество разума над Microsoft, даже поучаствовал в коллективной разработке и дописал command line interface туда. Но по зрелому размышлению, если отринуть красивое GUI, это ничуть не лучше nunit тестов, а даже и хуже:

• программистам придётся писать на Java, в то время как основной проект на С#
• web gui все равно нет
• дебага нет, статической проверки ошибок нет, IDE нет
• добавил туда поддержку JSON (30 минут) код теста с assert-ами разросся, начал добавлять поддержку XML посмотрел на размер тестов, ужаснулся

В общем так и докатился до nunit тестов.

Как народ функциональное тестирование REST API организует - ума не приложу, похоже никак, или на коленке пишет что-то своё.

И себе тоже добавил. Интересно мне оно не самой сетью, а просто аватарами людей которые меня читают, хотя Google обещает там всякие блага.

Я, конечно, не ожидаю что там будет сколько-то серьёзное количество людей, так за шесть с половиной лет в ЖЖ я нажил аж 88 френдов, но всё равно интересно попробовать.

На главной странице сайта есть блок с кнопкой Join.

Выглядеть оно обещает вот так

Народ на форумах вроде не жалуется. Надо как руки дойдут попробовать. К сожалению AppManager уже всё равно куплен.

Эта фотография Путина, британского фотографа Platon, вошла в лучшие фотографии 2008 года, по версии журнала American Photo. На сайте Word Press можно послушать как она была снята. Довольно любопытно.

А вот ещё одна замечательная фотография, тоже одна из лучших за 2008 год, на этот раз фотографа из Торонто - Mark Zibert

Почти все фотографии в подборке журнала заслуживают восхищение. Это же какие глыбы эти фотохудожники, какие матёрые человечища!

Вот 5-ти минутное среднее

а вот 30-ти минутное

Выглядит оно так

Это просто праздник какой-то! Лучший book title этого года

мы в этот магазин ходим уже 3 года. В приципе не мудрено запомнить, но всё равно удивительно. Может потому что преимущественно по-ночам ходим почему-то. Ну мы с Олей всегда только под вечер вспоминаем, что о! еды то надо было купить.

Кстати да, блин, еды надо было купить, только что вспомнил, хорошо что час ночи и бежать никуда не надо.

Первая книга, которая в общем то и к сериалу не относится - вообще замечательна. Это “Торговый баланс”. Чрезвычайно рекомендую! В оригинале называется “Balance of Trade” by Sharon Lee, Steve Miller.

Насколько первая книга интересна - настолько вторая нет. Вероятно Sharon Lee дорвалась. Новелла повествует о тяжелой и не простой жизни лесбиянки. Её жизненом пути из грязи в князи, страшных злодеях и добрых принцах. Всё это происходит на фоне звездолётов, узко лучевой связи и межгалактической торговли - действительно тщательно описанного мира и вплетено в канву дальнейшего повествования.

Вот обложка оригинального издания. Тут более уместно смотрелась бы дама в кринолине в объятиях полу-обнаженного тарзана. В общем типичная обложка дамского романа.

Позже, я прочёл, что г. Шарон Ли, работает в редкой литературной области - сплав Romance и SF. Ну прям война и мир - если “мир” пропускать, то войну читать интересно.

Казалось бы - если вторая книга такое никудышное чтиво, не стоит читать дальше. Но я стал и был вознаграждён! Следующие две книги “Агент перемен” (Agent of Change) и “Лови день” (Carpe Diem) столь же интересны как и первая книга. Замечательная вселенная, погони, перестрелки, Точильщики. Да, есть любовная линия, куда без неё, но довольно органично. Название книги - “Лови день” тоже выбрано очень удачно, в оригинале вообще - “Carpe Diem”, что ещё лучше.

Дальше снова следует “мир” - книга “Местный обычай” (Local Custom) - о том какие женщины бывают дуры если хотят. Ну это, конечно, исключительно с мужской, шовинистической точки зрения. Длинная тягомотина, заканчивающаяся свадьбой.

Ну и так далее.

Интересна также вселенная - три человеческой рассы: Земляне (в оригинале Terrans), Лиадцы (Leadens), Икстранцы (Yxtrangs) + нелюди упоминающиеся всколзь. Якобы происходят из одной рассы, но все об этом забыли. Интересно как переводчики будут выкручиваться, если терранов уже перевели как землян, а прото-рассу наверняка надо будет землянами назвать. Лиадийское общество - это кринолины, подковерных игры, дворцовые перевороты, сто сорок видов поклонов и неприменная вежливость. Для того что бы лицемерсто могло быть поднято на новые уровни (sic!) автор даёт им множество “модальностей” в языке. Существует официальный язык и язык которым разговаривают не официально. Существует модальности разговора старшего с младшим, нанимателя с рабочим и так далее. Любопытно, что в оригинале два вида языка называются Tongue - High tongue vs. Low tongue. До этого я знал только одно употребление этого слова в переносном смысле - Mother tongue. С модальностями никаких сюрпризов - это modes. Хотя я был готов к чему то вроде Tenses. Очень всё интересно описанно.

Как и полагается, у такой вселенной есть фен-сайты и даже статья в википедии.

Заявлен как pop/pop-rock. Где там rock, я сказать не берусь. Иногда грустная, иногда радостная музыка. Но скорее минирное настроение у всего альбома.

Grace заявляет, что наша жизнь это Hall of Mirrors, и мы жнём то, что сеем.

«Тоска — это то, что испытывает человек, который что-то хочет, но не знает точно, что именно, а знает только, что это недостижимо» А.Вержбицка

перед тем как посмотреть - не вытерпел, стал читать книжку, на которой фильм основан - Анатолий Азольский “Диверсант”. Тяжелое чтиво. Я такого тяжелого про Великую Отечественную и не читал никогда. Никаких сюрпризов нет конечно, и всё я вроде знал из истории. Но одно дело знать, а другое - герою сопереживать.

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

Ну и что бы два раза не вставать, напишу про прочие книжные разочарования.

Роман Злотников “Прекрасный новый мир” (Грон-4). Как видно по обложке - очередная говнокнига про всезнающего и всё умеющего Главного Героя (ГГ) в фентезийном антураже. ГГ перешёл на новый уровень (родился в новом мире) и вступил в нелегкую борьбу с другим профессионалом оперативной работы. Если первые книги ещё можно было читать - то это всё, финиш. Читать скучно, можно пропускать страницами. Картонные персонажи, лубяные декорации. Пишут, что Грон-5 на подходе. Чудеса - может Злотников генератор текста раздобыл где-то?

Снова Злотников, “Принцесса с окраины галактики”, такая же говнокнига, но теперь антураж космический. Продолжение про “людей капониров” и “куклусов”. Качество плохое. Русская идея прёт из всех щелей, рюриковичи, берсеркеры, какая-то рыбалка с роботами, дружеский секс. В общем - отказать.

И когда я уже запомню, что Злотникова читать не надо?

Зорич, “На корабле утро”.

И вновь Россия 27 века – могучая космическая сверхдержава, ведущая победоносные войны…Продолжение про конкордию. Снова русская идея. Но качество лучше. Даже есть кикие-то приключения. Читать можно, но предыдущие книги мне понравились больше. Без них не стоит ничего.

Воронин, “Живой щит”.

Книжка начинается как космическая опера, продолжается как фентези, а заканчивается инопланетянами. Ерунда.

Особенно запоминается своими масштабными роялями в кустах, персонажами из русских сказок, вроде леших, и скачками сюжета.

Пехов, “Искра и ветер”

брильянт среди россыпи говнокниг. Не то, что бы Пехов меня поразил своим инобытием логоса или там повествование играет на тайных струнах души, нет. Но язык хороший, события в наличии, главные герои приключаются по карте. Достойная книга в серии. Читать однозначно.

Дал Оле почитать - все четыре книжки проглотила в один присест. Хвалила.

В очередной раз пытался осилить Гришковца. То, что раньше казалось таким трогательны и “своим в доску” - эти бесконечные самокопания и перебирания мелких воспоминаний - теперь кажутся заезженными и надуманными. Оказывается у него, Гришковца, все книги/пьесы в таком стиле. Пытался смотреть по телевизору запись театральной постановки - скукотища ужасная. Я и не осозновал раньше насколько я привык пропускать абзацы, если книжка становилась скучна. Тут конечно не пропустишь. Представил себя в сидящем в партере. Пожалел зрителей и выключил телевизор.

Родина должна знать своих героев - вот они книги, которые я пытаюсь иногда осилить в метро - “Асфальт”, “Как я съел собаку” и “Одновременно”

Пытался читать “Санькя” Захара Прилепина, сдался в самом начале - такой из этого романа веет чернухой и безысходностью. Эта “мужская проза”, вероятно для самых суровых челябинских сталеваров. Всё плохо, денег нет, все болеют или уже умерли.

Также пытался читать “Козлёнок в молоке” Юрия Полякова. Это тоже образчик “мужской прозы”, но перегиб в другую сторону. Книга повествует о тяжелых и не простых буднях советских литераторов. Ебля на квартире, 4-ка жигулевского, декламация сочинений среди станков на заводе “Электролит” и сложные взаимоотношения с женщинами. И всё вроде ничего - только не трогают меня проблемы литераторов, да ещё советских, а кроме этого в той части книги, что я успел прочесть больше ни о чём и не повествуется.

Начал читать “Россия которой не было” Бушкова. По рекомендациям. Автор раскрывает своб точку зрения на историю России. Интересно, но не захватывающе. Надо наверно быть историком, что бы оценить по достоинству построения автора.

Видно местами, что снималось как сериал, а не художественный фильм, но всё равно - Замечательно всё! Снято очень красиво, это наверно операторская работа называется - молодец оператор. И костюмер тоже молодец. Очень жалко, что только 10 серий. В интернете как водится ругают, за историческое правдоподобие. Но и хвалят тоже.

Надо теперь первые 4 серии 2003 года выпуска посмотреть.

Обложка книги

Чайна Мьевиль, “Вокзал потерянных снов”. Какой замечательный стимпанк! Давненько такой качественной книги не читал. Даже жалко что кончилось.

Потом оказалось:
что автор книги, Чайна Мьевиль (China Miéville) и сам похож на панка,
что автор вовсе не из Израиля, а совсем даже из Лондона, причём тогда шекели в книге не совсем понятно,
что роман получил премию Артура Кларка

Решил по горячим следам почитать ещё чего-то стимпанковского.

Обложка книги

Прочёл “Сумерки” Глуховского, ему же принадлежит авторство “Метро 2033″.

Я сначала долго откладывал. Особенно смущал кремль на обложке,
- Ну зачем там Кремль? говорил я себе, Кремлёвская тематика в книгах у меня ассоциируется только с “Записками кремлёвских жён” и кремлёвскими диетами.
- Вероятно там что-то посредственное - приходил я к заключению.

Оказалось - ничего подобного. Хорошо написанно, заявленно как “мистика” и действительно “мистика”, но всё равно читать интересно.

Как затягиевает! Как затягивает! И заканчивается правильно.

Обложка книги

Позарился на мастистого писателя, всё никак не забуду “Остров Крым” Василия Аксенова, да и другие книги тоже были знатные. А вот “Москва Ква-Ква” видимо не для меня был написан, что-то там такое есть, обращенное к людям по-старше, а я этого не вижу. Для меня там сплошная антисоветчина…

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

Краски осени

На длинных выходных, по случаю Thanksgiving day, совершили путешествие на Bruce Peninsula и обратно

Краски осени	Высокие скалы	Водопад Eugenia Falls
Вот она я! Вид с постоялого двора
Оля на краю земли	А я на море!	Осень
Свет и тень Кирпичные утёсы
Каменный пляж Чистая вода
Неразлучная парочка Маяк
Ассоль куда-то отлучилась	Эй, на корабле!	Копки-баранки
Тянем-потянем!	Вечер трудного дня

Пользуйтесь, кому надо.

Украина : Политика Заголовки Полные новости
Бизнес Заголовки Полные новости
Киев Заголовки Полные новости
Мир Заголовки Полные новости
Россия Заголовки Полные новости
Мир о нас Заголовки Полные новости

Исходный код вот тут korrespondent.net.php и тут korrespondentnet-politics.php

Надо будет, что-то Губермана почитать, как-то он мимо меня прошёл совершенно…

Обложка книги

В который раз, встречая в хит-парадах и всяческих топах, эту книгу, поражаюсь, что же все эти люди в ней нашли? Пишут, что это европейский бестселлер г.Я.Вишневского

Классик личного брэндинга Томас Гэд отмечает, что для эффективного самопродвижения личность должна развиваться в четырёх направлениях:

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

Мне кажется эти мысли достойны того, что бы стать личными планами.

Любопытно также, что направления развития приведены в порядке возрастания сложности реализации. Первые цели три легко объяснимы и успешность их достижения будет прямо отражаться на благосостоянии, но мысль о “более высоких целях” достаточно туманна в разрезе IT.

Очевидно, что это не маркетинговые девизы и лозунги коорпораций, это что-то во что надо верить и чего планомерно добиваться. Но какая “особая миссия” может быть у “обычного профессионала”?
Впрочем, для некоторых этот вопрос уже решён.

Садок вишневий біля хати

Салун

Движение по реке вполне себе оживленное, кто домой, кто на работу, а кто и бутылки сдавать

Движение на реке

Береговая охрана

Что делает такой большой корабль в такой в принципе небольшой реке, я представить себе не могу.

Download audio file (artvertepcom-tsejdoschnadovgo.mp3)

Громадные ливневые капли падали в воду порождая вереницы брызг, летящие со всех сторон. Выбор, в принципе, был не велик - либо стоять высунув голову высоко над водой под холодным проливным дождём, либо спрятаться по подбородок в воду и полностью зажмуриться от брызг. Я сбегал за очками и купался в очках, забавный наверно был вид.

Это был наверно третий или второй раз в жизни когда я купался под дождём. Так что - запомнится надолго. Тем более что дождь подтопил и залил палатку с вещами и у Оли утонули телефон и Pocket PC. Мокрыми и полуголыми ехали в машине обратно.

А сегодня я чистил VS и заметил, что действительно MS любит мальчиков.

смеха ради прошёл тест.  Полгода наверно не брал в руки шашек, а серьёзно так и никогда не брал. Если бы в гугль подсматривал наверно ещё бы круче сдал

Настоящие имена компаний изменены, но при желании узнаются. Сохраню пожалуй себе на случай если пропадёт статья.
Жизнь внутри пузыря

Стали стучать задние тормоза. Хотел съэкономить на дилершипе -  съездил к reputable mechanic - те взяли $40 и ничего не нашли! Замечательные у вас тормоза, сказали, совсем новые. Вот гады. Никому нельзя верить.

Первый день на железнодорожном вокзале совсем рядом возле города Нью Йорк.

тот же вокзал с местными жителями

А это уже и сам славный город Нью Йорк вид с туристического автобуса

Широко всем известное здание Империал которое на сегодняшний день самое высокое в Нью Йорке после разрушения Торгового центра 2001 году.

так выглядит средняя улица Нью Йорка (остров Манхетен)

Так как в городе очень тесно то парковки там двух этажные иногда бывает и три этажа

Хорошо что светофоры высоко весят а то бы мы головой их задевали с нашего автобуса

А здесь не объявления написаны а уголок мира. Все кто за мир написали здесь как могли.

Дождик сопровождал нас в путешествии очень часто. Благодаря обширным ремонтам в городе мы всегда могли найти вот такое место что-бы переждать дождик.

А это славно известная площадь Таймс. От большого количества рекламы очень трудно оторваться.

Та же площадь но вечером.

Самое грязное и ужасное метро в мире. Не приятное на вид и на запах.

Это финансовый центр города.

Это узенькая улица между высотными офисными зданиями. Чувствуешь себя как в ущелье.

Говорят если подержать этого быка за яйца будет удача. Посмотрим.

набережная с видом на офисные здания

Это я после долгих гуляний по городу

Это Игорёк на Times Square

Обворожительный вид на ночной Нью Йорк с высоты 86 этажа Империал здания

Я с балалайкой

Если внимательно присмотреться видно статую Свободы на горизонте

Чем дальше Нью Йорк тем красивее он смотрится. Вид c кораблика.

Статуя свободы. Я раньше думала что она больше.

Я и статуя Свободы

Игорек со статуей Свободы. Так как кораблик не стоял на месте ему достался только вид сбоку.

Это мы на втором острове Бруклин. Это тоже часть города Нью Йорка. В центре видно мост Манхетен а под аркой моста видно Империал здание.

Песня на стихи Маяковского “Лиличке”, посвященного Лиле Брик.
Я впечатлён, похоже Сплин и Маяковский идеально друг другу подходят…

Download audio file (Splin-Mayak.mp3)


Выбирать музыку по обложкам - так приятно, всё время присутсивует некая интрига,  и к тому же быстро