Я надеюсь, вы помните, что этот блог является площадкой для обкатки всяких новых и интересных1 технологий. И некоторое время назад я пришел к мысли, что тех архитектурных решений, которые я заложил в первую версию блога, мне не хватает. Что из этого следует? Конечно, нужно сделать новый сайт. Первая версия делалась с целью получить приемлемый результат минимальными усилиями, новую я хочу с делать с учетом ошибок первой и лучшего понимания общей идеологии. И именно к этому я приступил пару недель назад.
Очень постараюсь не лениться и представлять своего рода отчеты о проделанной работе. Собственно, следить за разработкой (если есть такое желание) можно на GitHub. Для этого там была создана ветка dev.
В ближайших планах рассказать вам об интернационализации (i18n), сериализации/десериализации в json и создании снаплетов. Что из этого интереснее? Еще есть хорошая тема «Template Haskell, или что я был бы не прочь увидеть в других языках.» В любом случае, если вам хочется узнать подробнее, а я всё никак не разрожусь текстом, — не стесняйтесь указать на это в комментариях или письме.
Забыл сказать, что пока переделка касается только серверной части. Javascript останется таким, как есть, разве что адаптируется под новые возможности.
В первую очередь для меня.
Многие знают, что Subversion хранит историю в виде списка разниц-дельт между различными версиями файла. Это и понятно: обычно изменения в файлах происходят не глобальные и небольшое описание разницы будет занимать значительно меньше места. Но тут возникает вопрос, как сервер извлекает информацию из истории. Можно предположить, что самая свежая версия файла хранится целиком, а предыдущую можно получить, применив изменения (reverse-patch) к самой свежей версии. Но что делать, когда нужно посмотреть вариант, который был 100500 ревизий назад? Не зависнет ли сервер на этом действии? Кроме того, при таком подходе во время сохранения нужно изменять 2 файла: записать новый целиком и заменить старый на дельту.
Или еще вариант: делать всё в обратную сторону. Т.е. хранить не последнюю ревизию, а просто разницу. Тогда запись значительно упрощается, но вместе с тем чтение файлов с длинной историей превращается в ад. Я бы навскидку предложил добавить какие-нибудь контрольные точки, например, каждые 128 ревизий держать целую версию файла. Это не должно сильно увеличить время записи, но вместе с тем время поиска возрастет в разы. Кстати, примерно так поступают кодировщики видео, что обеспечивает возможность перемотки.
В любом случае, вариант, воплощенный на самом деле, во много раз лучше. Он называется skip-deltas. Приведу картину из документации.
0 <- 1 2 <- 3 4 <- 5 6 <- 7
0 <------ 2 4 <------ 6
0 <---------------- 4
0 <------------------------------------ 8 <- 9Например, нам нужно записать ревизию 60. 6010 = 1111002. Правую 1 заменяем на 0 и получаем ревизию, относительно которой нужно построить разницу, т.е. 1110002 = 5610. Ревизия 0 для всех файлов одинаковая и соответствует пустому файлу. Вот и получаем быстрый доступ к любой ревизии на репозитории практически любого размера.
Конечно, такой подход требует несколько большего места для хранения, ведь разница между файлами будет больше. Но это необходимая плата за скорость.
Если кто вдруг не знает, Google Closure сильно полагается на JSDoc-комментарии при компиляции и статическом анализе JavaScript-кода. При этом используется не совсем стандартный синтаксис этих комментариев. По крайней мере набор проверяемых инструкций сильно расширен. Кроме того, введена целая система описания типов, которая лучше отражает динамическую структуру JavaScript. Для тех, кто работает с Google Closure с завидным постоянством, всё это не представляет никакой проблемы. Но для тех, кто, как я, возвращается к нему лишь время от времени, периодически приходится заглядывать в руководство. И в помощь таким людям (и не в последнюю очередь себе) я сделал совсем небольшую шпаргалку, чтобы распечатать и повесить на стену перед глазами. Надеюсь, кому-нибудь пригодится.
Скачать pdf (65 Кб, 1 стр.)
Возможно, я ее когда-нибудь расширю, когда придумаю, чего туда добавить, а пока принимаю комментарии, предложения и благодарности.
И еще немного музыки.
Вы наверняка слышали эту традиционную американскую рождественскую песню. Красивая, запоминающаяся мелодия. А если не слышали, то еще не поздно наверстать упущенное. Различных вариантов на YouTube не просто много, а очень много, поэтому пришлось постараться, чтобы выбрать какой-нибудь один.
Решил я посмотреть, кто же автор этого шедевра. И внезапно оказалось, что автор — дружественный украинский народ, а адаптировал мелодию для хора украинский композитор и дирижер Леонтович Николай Дмитриевич. А вот остальной мир знает эту песню благодаря Питеру (Петру) Вильховскому, американскому композитору украинского происхождения, который написал английскую версию текста. Поэтому иногда эту песню называют Ukrainian Christmas Carol.
Кстати, сама мелодия по-украински называется Щедрик. Вот такие сюрпризы иногда могут скрываться в музыке.
Открытие дня: оказывается, Motown — это не название стиля музыки, а название лейбла, на котором записывались множество исполнителей со схожим звучанием (Motown records). А еще это неофициальное название Детройта (Motown = Motor + town).
Новое слово — portmanteau. Означает слово-чемодан, слово-бумажник, слово, образованное из двух других. Льюис Кэрролл любил такие. Например, хливкие = хлипкие + ловкие (slythy = slimy + lithe). Или вот примеры из настоящего языка: smog = smoke + fog, motel = motor-way + hotel. Motown — это тоже portmanteau.
Ну и напоследок немножко мотауна для поднятия настроения: