Всё своё ношу с собой

Отвлечёмся от IT-тем :-) Что-то я себе Анатолия Вассермана в миниатюре стал напоминать. По количеству носимых с собой вещей.

Куртка:

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

Джинсы:

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

Рюкзак:

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

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

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

No Comments

сумасшедший алгоритм

Уже 3-й день размышляю над алгоритмом следующей задачки.

Дано:

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

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

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

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

, ,

No Comments

… И получился GFS :)

Доделал «сырую» реализацию тех самых функторов из предыдущего поста. Умеем хранить элементы размером до 2^{62} = 4611686018427387904 = 4 эксабайт. Максимальное количество элементов точно не определено, но примерно равно 2^{200} и изменением буквально десятка байт кода может быть увеличена до примерно 2^{450}. Правда, при этом увеличивается фактический размер ключей и чуть-чуть падает скорость.

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

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

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

, , ,

No Comments

Функционалы против классов

Товарищ (RedChrom) задал вопрос, что я использую больше при разработке на Окамле. Не особо задумываясь ответил, что фифти-фифти. Потом сделал простой grep на свои исходники, и выяснил, что на 80% всё-таки модули и функторы. Причём, объекты и классы по большей части в очень старых исходниках. Сейчас 100% функторы.

Read the rest of this entry »

, , ,

1 Comment

О материальности мыслей

Год бредил идеей съездить куда-нибудь в заполярье. И вот, буквально за 3 дня поступили предложения:

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

,

No Comments

JavaScript: безопасный код

Давно собирался написать нечто подобное, да всё руки не доходили. Толчком послужил краткий пост на аналогичную тему у моего знакомого.

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

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

Read the rest of this entry »

, , , ,

6 Comments

Цинично о посещении Шевчука

Сходил на ДДТ. Впервые в жизни был на выступлении лирической группы. Если на Soulfly океан драйва (и соответствующий отрыв), на Пикнике достаточно много интеллекта (пафосно хлопаем после каждой песни), то тут я совсем не понял, как развлекаться. По заявлениям множества участников, драйва было много. Но, видимо, не для любителя “чего-нибудь потяжелее” :) Для себя сделал вывод, что Шевчука надо слушать либо в наушниках, либо узким кругом.

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

, ,

No Comments

Губительный телефон — 03

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

Read the rest of this entry »

,

No Comments

Накаячились!

Видео с кипящими чайниками на борту каяков. Мероприятие состоялось на р.Хара-Мурин, порог Лангутайский.

Get the Flash Player to see this player.

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

, , , ,

No Comments

Про офис ISPsystem

Уже давно собирался описать весь тот бардак, который у нас происходит, да всё руки не доходили. И вот, это сделали за меня! Как миним треть сказанного по этой ссылке можно приписать к нам: http://x.lenta.ru/facts/

,

No Comments