Куртка:

• Левый карман: левая тонкая флисовая перчатка, кедровая шишка для поедания
• Правый карман: пара к перчатке, жевательная резинка, шапка (”уши”), сигареты
• Внутренний карман: телефон (*), mp3-плеер (*), зажигалка

Джинсы:

• Левый карман: немного денег
• Правый карман: ключи, 2-я зажигалка. В маленьком кармане справа до сих пор периодически обнаруживаю резинки для волос

Рюкзак:

• Большое отделение: ноутбук с блоком питания, мышка, веб-камера, внешний HDD с блоком питания, флейта, иногда различные документы, иногда флиска
• Малое отделение: запас полиэтиленовых мешков, минимальная велоаптечка (заплатки, клей, многоразмерный ключ, выжимка для цепи), книжка с рассказами Рэя Бредбери (уже 2 месяца не могу дочитать), иногда скалолазная обвязка, мешочек с магнезией и скальные тапки
• Большой карман: флешка, USB bluetooth, спички одного формата, спички другого формата, 3-я зажигалка, фонарик(*), деньги, петарды ( :-) ), ручка, карандаш, маркер, кредитка, паспорт, маленькая записная книжка (надо купить новую), блок питания к телефону, переходник USB-microUSB, варган, иногда губная гармошка
• Малый карман №1: минимальная аптечка (пластырь, бинт, йодный карандаш и по мелочи)
• Малый карман №2: наушники для компьютера, иногда совсем не понятная мелочь.

(*) — удалено в связи с покупкой правильного смартфона.

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

Дано:

1. Есть кластер. В кластере живёт несколько узлов. В узле живёт несколько веб-серверов. В веб-сервере живёт несколько аккаунтов. В аккаунте живёт несколько сайтов.
2. Для каждого сайта известна текущая нагрузка. Соответственно, известна нагрузка для каждого из аккаунтов.
3. Известно количество сайтов в каждом из аккаунтов.
4. Для каждого аккаунта сказано, на скольких минимум узлах (не веб-серверах) он должен присутствовать. Пусть это будет μ.
5. Для каждого аккаунта известно, какие веб-серверы обрабатывают его в данный момент.

Задача состоит в том, чтобы перераспределить аккаунты по веб-серверам так, чтобы

1. Аккаунты с максимальной нагрузкой присутствовали на максимальном числе узлов. Ну и соразмерно все остальные.
2. Каждый аккаунт представлен минимум на μ узлах.
3. В пределах одного узла каждый аккаунт представлен лишь один раз.
4. Текущая нагрузка наиболее равномерно распределена между всеми узлами (или с каким-то коэффициентом — не суть).
5. Сайты максимально равномерно распределены между всеми веб-серверами, чтобы минимизировать объём памяти каждого из процессов веб-серверов.
6. Сделать это всё так, чтобы изменения коснулись по возможности минимального количества веб-серверов, чтобы затем минимум их пришлось заставить перечитывать конфиг.
7. Делать это каким-то хитрым алгоритмом т.к. простой перебор на потенциальные десятки тысяч сайтов может отожрать немало проца и памяти…

Понятно, что идеально соблюсти все условия не получится. Соответственно, надо либо расставить приоритеты условиям, либо ввести коэффициент максимальной допустимой погрешности решения. Решение вырастает весьма объёмным даже для простого перебора. Мне страшно представить о часе, когда надо будет искать более изящные решения.

Реализованы функторы: Sized (заодно храним фактический размер записи), Splitted (правильнее было бы назвать Striped), Distributed (записи раскидываются по нескольким нижележащим хранилищам), COW (обеспечение почти полной атомарности для всяких сложных хранилищ, типа Splitted, за счёт copy-on-write).

Каким-то сумасшедшим performance пока похвастаться не могу (около 12000 килобайтных выборок в секунду, в случае использования хранилища FileSystem), реализация всё-таки ещё сырая.

Коллега на работе сказанул: «Google BigTable что ли сделал?». Я подумал, и решил, что нет, это Google FS :)

Сейчас развлекаюсь написанием универсального интерфейса к разным хранилищам (в первую очередь, это FS, memcached, memcachedb) с записями вида key+value. В качестве основы, создал универсальный интерфейс:

module type STORAGE =
        sig
                type t
                type storage_descr_t
 
                val init: storage_descr_t -> t init_result
 
                val get: t -> Key.t -> get_result Lwt.t
                val get_list: t -> Key.t list -> get_result Lwt.t list
 
                val delete: t -> Key.t -> delete_result Lwt.t
 
                val set: t -> Key.t -> ?value_size:value_size -> value -> set_result Lwt.t
                val add: t -> Key.t -> ?value_size:value_size -> value -> add_result Lwt.t
                val replace: t -> Key.t -> ?value_size:value_size -> value -> replace_result Lwt.t
        end

Написал модуль FileSystem, реализующий такой интерфейс. Поскольку файлы могут быть (условно) бесконечного размера, это стало самой простой реализацией интерфейса. Но не всё в жизни так легко. Например, memcached имеет максимальный размер пары key+value где-то в районе 64KB. А хочется в нём хранить побольше. Да и файловые системы бывают дурные. Напрмер, не позволяют создавать файлы больше 512MB. Поэтому на основе FileSystem (ключевое слово import) был написан маленький модуль FileSystemSized, который помимо value пишет в файлик размер value. Штука, на первый взгляд, бесполезная. Но идём дальше. Создаём функтор Splitted, который принимает модуль с интерфейсом STORAGE и делает модули с тем же уже знакомым нам интерфейсом STORAGE. Этот функтор хитрый: он знает, какого максимум размера value может хранить переданный ему модуль. Если в одну запись не влазит — он бьёт value на кусочки, для каждого кусочка генерит свой уникальный ключ, и таким образом пишет. В первом кусочке он сохраняет реальный размер всего value. Вот зачем нам нужен был модуль FileSystemSized. На основе этого функтора получается чудесный модуль FileSystemSplitted. По образу и подобию можно сделать MemcachedSplitted. Или даже FileSystemSplitted_and_again_Splitted, только я не придумал зачем :)

Мыслим вперёд. Ключ у нас — строчка строгой длины, с равной вероятностью имеющая в первом/втором/третьем/… байте любое из значений 0..255. На основе первого байта ключа, мы можем раскидать пары key+value на 256 физических хранилищ (ну, или меньше, как захочется). Назовём такой функтор Distributed, и он тоже будет создавать модули с интерфейсом STORAGE. Получается изумительная картинка:

(* Создаём уже знакомый нам модуль для хранения больших значений
   в маленьких файлах.
*)
module FileSystemSplitted = Splitted(FileSystemSized)
 
(* Каждое значение хранится в одном файлике, но файлики раскидываются
   по разным директориям.
*)
module FileSystemDistributed = Distributed(FileSystemSized)
 
(* Каждое значение пилится на части, части раскидываются по разным директориям.
   С remote mount, получаем хранилище бесконечного размера для почти
   бесконечного количества значений.
*)
module FileSystemDistributedSplitted = Splitted(FileSystemDistributed)
 
(* Каждое значение хранится в одной директории, но там оно пилится на части.
   Директорий для хранения может быть несколько. Хранилище получается тоже
   бесконечным, но наполняется не так равномерно.
 *)
module FileSystemSplittedDistributed = Distributed(FileSystemSplitted)

Как видите, с помощью фактически одного интерфейса и двух функторов, получаем невероятное, лютое количество вариантов хранилища. Даже круче, чем в GlusterFS или GNU Hurd. А ведь мысль можно продолжить ещё дальше, дописав функторы Raid0 (писать значение в несколько хранилищ), Clustered (создаётся на основе списка хранилищ, умеющих только читать и списка хранилищ, умеющих изменять), Flock (за счёт некоторого performace degradation, делать exclusive lock на записи)… чем я и занимаюсь :) Замечу, что всё это в функционально чисто, без side-effects (они есть только на уровне хранилища) и безумно типобезопасно.

• Летом на великах по Скандинавии
• Пешком по Норвегии
• Весной дикарями на полярный Урал смотреть северное сияние
• На новый год на машинах до г.Мирного (Якутия). Но тут я больше сам напрашиваюсь.

Как известно, JavaScript — язык c динамической (для классов с утиной) типизацией, с очень плохо развитой системой типов. Стандартный интерпретатор даже в браузерах Mozilla с расширениями разработчика отлавливает минимум ошибок. Практически все эти ошибки — синтаксические. В результате, писать надёжный код на JavaScript предельно сложно. Положение усугубляет фактическая невозможность запуска программы без использования браузера, т.е. нет никакой песочницы для тестов.

В этой статье я попытаюсь описать некоторые технологии, которые помогут знакомому с Ocaml человеку существенно сократить время написания безопасного, стабильного и более-менее компактного JS-кода. Впрочем, описываемые техники есть и для некоторых других языков с развитой системой типов (например, Haskell).

Ocamljs: компилятор Ocaml ⇒ JavaScript

Скачать: http://code.google.com/p/ocamljs/

Всё просто: вы пишете client-side код вашего сайта на Ocaml, а с помощью этого компилятора получаете готовый для использования в браузере JavaScript. Для обеспечения работы, непосредственно к вашему скрипту дописывается около 40KB дополнительного кода. Например. Ни к чему не обязывающий код:

type tree =
	| Leaf of int
	| Node of tree list
 
let l : tree list = []
 
let _ =
	match l with
	| [] -> Dom.window#alert "empty list"
	| a :: [] -> ()
	| a :: b :: [] -> ()
	| _ -> Dom.window#alert "unexpected list"

Компилируем:

ocamljs -o test.js -I /usr/local/lib/ocaml/3.10.2/dom/ dom.cmjsa test.ml

Получаем вот такой код:

// .....
var oc$Dom$ = function () { var window$717 = window;
                            var document$718 = document;
                            return $(window$717, document$718); }();
var oc$1$ =
  function () {
    var l$63 = 0;
    if (l$63)
    {
      var match$71 = l$63[1];
      if (match$71)
      if (match$71[1]) (function () { var v$74 = oc$Dom$[0];
                                      return _m(v$74.alert, v$74, ["unexpected list"]); }()); else ;
      else ;
    }
    else (function () { var v$73 = oc$Dom$[0];
                        return _m(v$73.alert, v$73, ["empty list"]); }());
    return $(l$63);
  }();
var oc$Std_exit$ = (_(oc$Pervasives$[80], [0]), $());
return caml_named_value;
})();

JavaScript compressor

Как я уже сказал, код получается достаточно объёмным. Частично эту проблему решает gzip (при условии, что и сервер, и браузер имеют его поддержку). Однако, код можно существенно сократить за счёт оптимизации по размеру. Для этого есть ряд готовых online-утилит. Используемые техники:

• Удаление комментариев
• Удаление не несущих синтаксической нагрузки пробелов и переносов строк
• Назначение локальным переменным функций более коротких имён
• Вынесение длинных повторяющихся констант в переменную с коротким именем

Наилучшие результаты показывает Packer (http://dean.edwards.name/packer/), однако ocamljs компилирует не полностью корректный код — иногда забывает точки с запятой — поэтому Packer генерирует не работающий код. С учётом некорректности оригинального кода, наилучший результат показал Dojo ShrinkSafe (http://www.dojotoolkit.org/docs/shrinksafe). Рекомендую прогнать код через валидатор (http://jslint.com/), это в любом случае неплохая идея. Пример кода, получающегося с помощью Dojo ShrinkSafe:

// .....
var _213=function(){
var l$63=0;
if(l$63){
var _215=l$63[1];
if(_215){
if(_215[1]){
(function(){
var v$74=_210[0];
return _m(v$74.alert,v$74,["unexpected list"]);
}());
}else{
}
}else{
}
}else{
(function(){
var v$73=_210[0];
return _m(v$73.alert,v$73,["empty list"]);
}());
}
return $(l$63);
}();
var _218=(_(_106[80],[0]),$());
return _9d;
})();

Код получается практически не читаемым, зато размер сокращается в 2-4 раза.

Быстро сравнить различные компрессоры можно на сайте: http://compressorrater.thruhere.net/

O’Browser: виртуальная машина на JavaScript

Скачать: http://ocsigen.org/obrowser/

Ваш код будет скомпилирован в байт-код, закодированный в UUE. Для вызова кода, достаточно вызвать его в виртуальной машине:

<script src="vm.js" type="text/javascript"></script>
<script type="text/javascript">
  /* <![CDATA[ */
    window.onload = function () {
      exec_caml ("tutorial.exe.uue") ;
    }
  /* ]]> */
</script>

Байт-код получается достаточно объёмным, да и сжатию поддаётся только за счёт слоя gzip. Впрочем, код самой виртуальной машины вполне поддаётся обработке JavaScript компрессоров. Валидность кода получается даже выше, чем у ocamljs. Декомпиляция байт-кода в нормальный JavaScript становится нерешаемой проблемой :)

Вероятно, многие видели, как на выступлениях подобных групп над залом горят зажигалки. Так вот, это оптическая иллюзия. На самом деле, это экранчики фотоаппаратов! :)

Как с сотового набрать 03 я не знаю, позвонил в МЧС (112). Там мне моментально вежливо ответили, что надо набрать 03*. Позвонил.

— Здравствуйте, в роще между Студгородком и Университетским какой-то мужик лежит, ни на что не реагирует.

— Скажите адрес.

— Это роща, у неё нет адреса.

— Ну тогда скажите как доехать.

— [бла-бла-бла]

— Не понимаю…

— У вас карта под рукой?

— Да, ещё раз скажите как доехать.

— [бла-бла-бла]

— Всё равно не понимаю. Оставьте ваш телефон, не занимайте его.

— 223-322-333

Проходит 10 минут, я уже в километре оттуда. Звонок:

— Вы скорую вызывали?

— Да.

— Как доехать?

(устало, в третий раз) — Остановку Политех знаете? — Да. — Трамвайное кольцо знаете? — Да. — Воот, от остановки едете мимо трамвайного кольца до самого верха, до улицы, на которой военкомат расположен. Как доедете до верха, сразу перед вами роща начнётся. Вот по ней пройдёте немного и увидите, прямо на дороге он лежит.

— Назовите юридический адрес.

— Юридический адрес рощи?

— А куда нам ехать?! Скажите юридический адрес!

(начинаю злиться) — Вы сами подумайте, какой юридический адрес может быть у рощи?!

— Тогда ждите нас!

— Извините, но я уже далеко оттуда.

— Тогда идите назад и ждите! Вы понимаете, что несёте юридическую ответственность за вызов? Как мы там в темноте его искать будем?

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

— Вы несёте юридическую ответственность за вызов! Ждите нас!

— Если я через 15 минут подойду — вас устроит?

— Да.

— Досвидания.

Пошёл обратно. По пути (по прошествии получаса-то!) обнаружил, что мужика уже нет. То ли прохожие какие унесли, то ли сам очухался. Лежал лицом вниз. Перезваниваю на 03:

— Здравствуйте, делал вызов в рощу рядом с Политехом, пострадавший покинул место.

— Вызов отменяем?

— Да.

И тут я услышал первое вежливое слово от достопочтимой скорой:

— Спасибо большое за ваш звонок.

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

То же, но в хорошем качестве: kayak2009.avi