моделирование, это всегда хорошее решение, но плохая задача.
Ситуация:
В корне сервера, с 6 паравиртуальными машинами xen (которые лежат в отдельной fs), заканчивается свободное место. При том, что вчера там было минимум 30Г свободного места. Что характерно — /tmp и /log — тоже живут в отдельных fs.
Показания df — места нет.
Показания du — больших папок/файлов в корневой fs не существует. Темные лошадки — как обычно какието девайсы из /proc.
Проверка fsck.reiserfs ошибок не выявляет.
Сисадминская задачка с подлячком, хехе. Освобождаю пару метров в корневой fs и пытаюсь запустить одну из виртуальных машин. Машина стартует со скрипом, беспрерывно выплевывая в свою консоль матюки на модуль, связанный с системными часами. Системные часы — это не связанно с местом на диске, правильно?
Самое время подумать о жизни, и о том — “какого хера”. И пусть весь мир (почта, днс, файловый сервер, веб сервер, сервер авторизации и север БД) подождет.
Но. Задаюсь вопросом: а вот куда ложатся эти беспрерывно выплевываемые, как из пулемета, матюки от 6 машин, на ошибку с системными часами? Судя по скорости — 30Г там набрать — без проблем. Известно куда ложаться — в /proc. Но /proc место на диске не жрет, вроде бы. А оказывается жрет.
Ровняю проблему с часами, методом поиска сообщения об ошибке в гугле, и поскольку время дорого, и влом выискивать по /proc эти файлы — перегружаю сервак. Прощай 180 дней uptime, ну и хрен с ним. Все работает, 30Г — как с куста.
З.Ы. У
xenвообще частенько возникают разнообразные проблемы с системными часами. Издержки паравиртуализции.
Идея следующая — взять pypy, скомпилировать его с помощью pycow и посмотреть что получится. Результатом должен полный набор стандартных библиотек python которые можно будет запользовать как для sculpt так и для pycow .
Единственное что сдерживает — непонятка с алгоритмом работы import. В том плане что ни в sculpt, ни в pycow import не реализован вообще.
И это обоснованно — потому что действительно неочевидно — как организовывать import в удаленный клиент. Плодить кучу файлов и переспрашивать их с помощью XmlHttpRequest — плохо, потому как много запросов. Упаковывать весь python в один файл — тоже ни разу некомильфо, потому как получится один большой файл, в котором будет много лишнего.
Вроде бы все готово. Для компиляции осталось пару строк функции компрессора, которая является просто враппером для pycow.
pycow_compressor/__init__.py
from django.conf import settings
from pycow.pycow import translate_string
def pycow(*args, **kwargs):
try:
return translate_string(args[0], warnings = False)
except:
if settings.DEBUG:
raise
else:
return ""
Итого, для прозрачной компиляции python->javascript из шаблонов нужно:
- Использовать python2.6
- Установить django-compressor
- Задать в
settings.pyтакую настройку(там еще добавлена настройка для clevercss) - Скачать и установить в проект собственно компилятор pycow
- Скачать и установить в проект файл pycow_compressor/__init__.py, содержащий указанный выше код (и небольшие дополнения, описанные ниже;) ).
После этого, в базовом шаблоне пишется следующее:
{% compressed “py” “pycow_file”%}
В остальных, унаследованных/включенных шаблонах подключaются .py файлы:
{% compress “py” “media/pycow/somepage_script.py”%}
Которые (алллилууйя-братья-и-сестры-не-забудьте-пожертвовать-нашей-церкви-в-кассе-на-выходе!) будут спакованы и скомпилены в один .js файл и выданы в страничку как тег <script> в том месте, где находится {% compressed "py" "pycow_file"%}
Небольшие дополнения
Если сравнить код указанный в начале поста, и код находящийся по ссылке, можно увидеть что они отличаются. Отличие обусловено тем, что без импорта жить плохо, а в pycow этот вопрос не решен вообще.
Хотелось бы, но модифицированный pycow компрессор тоже ничего ниоткуда не импортирует. Он расширяет класс компилятора таким образом, чтобы идентификаторы, которые были указаны командой import, считались классами и инициализировались с конструкцией new. Таким образом, становится возможным корректно использовать ранее загруженные в браузер классы (например классы эффектов mootools).
Ок. Компилятор выбран. Однако, это только половина задачи. Вторая половина задачи выходит из того факта, что, если я хочу подключать .py файлы из шаблона — мне нужно кеширование и компиляция кода в зону static. Я совсем не хочу, чтобы при каждом рендере шаблона вызывался довольно тяжелый компилятор. Кроме того, для установки сервера в productive режим, у меня на руках должен оказаться работающий набор скомпилированных скриптов. А еще, я хочу не думать о том, что библиотеки могут загружаться на страницу позже кода. Сопроводительные задачи должен решать робот. Для этой цели собственно и был написан django-compressor.
Вообще, django-compressor довольно спорный tool. Спорный с точки зрения необходимости — гораздо правильнее строить приложение так, чтобы задачи которые решает компрессор, вообще не вставали. Гораздо правильнее использовать CSS для стилей, и скрипт для клиентской части. Но питон силен именно тем, что позволяет быстро делать прототипы. А в прототипе главное не оптимальность. В прототипе главное — быстро и эффективно перейти от этапа создания среды для эксперимента, к собственно эксперименту. Компрессор был написан какраз исходя из того, что сначала должен быть создан прототип, и создан он должен быть быстро.
Про компрессор
Если коротко, то компрессор действует следующим образом — он берет все, что находится между тегами {% compress "group_name" %}{% endcompress %}, и переставляет “это все” в то место, где находится тег {%compressed "group_name" "compiler_name"%}. Перед подстановкой проверяется наличие контрольной суммы в кеше компрессора, и на этом основании принимается решение — нужна ли компиляция с использованием компилятора compiler_name или можно просто вернуть содержимое файла (или путь к файлу) соответствующее контрольной сумме. Компрессор умеет разбирать наследование шаблонов, инклуды, блоки и переменные. Поэтому можно спокойно выстраивать удобную для себя структуру шаблонов, не оглядываясь. Содержимое нескольких тегов {% compress %} будет встречаться в на странице в том же порядке, в котором происходил рендер.
Компилятор задается в settings.py как элемент словаря COMPRESSOR_COMPILERS следующего вида:
"pycow_file":{"result_wrapper":"""<script type="application/javascript" src="%(rendered)s"></script>""",
"returns_url":True,
"extension":"js",
"compiler":"pycow_compressor.pycow"},
Здесь result_wrapper определяет, какой текст будет окружать результат компиляции. returns_url определяет что надо возвращать — путь в кеше к скомпилированному файлу или содержимое скомпилированного файла. extension определяет какое расширение указывать для скомпилированных в кеш файлов. compiler определяет где взять функцию для компиляции.
Вторым аргументом для функции компилятора будет передан контекст. Так что, если внешний компилятор умеет работать с контекстом — можно приютить и его. Обращаю внимание — контекст будет закеширован после первой компиляции. Отслеживать и кешировать изменения переменных контекста я считаю избыточным. Поэтому, изменения в контексте не будут отражаться в скомпилированном файле, но для верстки стилей с использованием clevercss - сойдет.
Это какбы все. Следует еще добавить, что в реальном мире, никто не захочет держать клиентский (или еще какой) код внутри шаблонов, поэтому есть тег {% compress_file "group_name" "file/path" %}, который позволяет вынести код в отдельный файл. Путь считается относительным к корню проекта.
Производительность компрессора
Особо не вникал, т.к. это утилита времени разработки. Сравнение времени рендера шаблона в 10 строк без компрессора и с ним дало отличие в 4 раза — с 0.018 до 0.056 секунд. Очевиден выиграш в количестве запросов к серверу, но за все надо платить.
Для моих мозгов сложные синтаксисы — это вообще беда. Потому, что на какомто этапе обдумывания будущего решения, часто случается так, что я понимаю, что не очень осознаю суть задачи и начинаю “ввязываться в бой с наличными силами”. То есть экспериментровать, писать в режиме “что вижу, то пою”. Питон позволяет такой подход (в разумных пределах) т.к. всегда можно без ущерба для психики, вернуться, пересмотреть/отрефакторить/выделить важное и выкинуть ненужное.
По правде говоря — меня раздражают почти все синтаксисы, кроме питонического. Во всех остальных языках, которые я щупал, визуальная сложность написанного кода растет по экспоненте от сложности задачи. В результате, программист, и так пригруженный сложностью задачи, оказывается под завалами собственного кода. А если мысль пошла извилистым, ну да, может не очень правильным путем — последующее распутывание превращается в редкое извращение, на которое скорее всего забьешь.
Выбор средств
Вообщето, задача компиляции python в js изначально выглядит не особенно сложной. Между этими языками много общего. Однако, если в голову приходит мысль насчет компиляции одного языка высокого уровня в другой язык высокого уровня — стоит как минимум проверить гугл, а как максимум — расслабится и перестать заниматься мечтательством. Несмотря на это, поверхностный осмотр гугла предоставил на выбор целых три варианта:
pyjamas
Выглядит привлекательно. Сначала. Пока не распакуешь и не осознаешь. Может быть, он неплох для создания десктопов, я не пробовал. Мне, для создания удаленных псевдодесктопных приложений, вполне годится Mozilla XUL. А для написания средних и малых web решений pyjamas вообще непригоден. Да, он способен превратить каждый браузер в отдельный сервер приложений. Наверно, если изгольнуться — туда можно вставить коннектор работы с БД, или SASL авторизацию. Однако, если перефразировать Петра Первого: “Клиентская станция перед лицом начальствующим должна иметь вид лихой и придурковатый дабы разумением своим не смущать сервер” (кажется, до меня ктото уже так перефразировал). Стремление сего фреймворка накрыть одной компиляцией все аспекты, включая генерацию html и css, слабо коррелируют современными моделями веб приложений.
Skulpt
Вот это то, что я называю “pythonic way”. Это мощная идея. Это будет “окно в браузер” для python. Он станет мостиком, который наконец заставит Mozilla, а потом и остальных, включить поддержку python в стандартный пакет. Но. Это все же еще не python:
>>>print type(object)
error:trying to str() undefined (should be at least null)
Но и не javascript (mootools загружен страницей)
>>>a = Fx.Morph()
завис .....
В общем вывод следующий: отслеживать, возможно поучаствовать, при наличии времени, но пока сыроват.
pycow
В одном из мануалов амбициозного пакета “PyGoWave”, который собирается стать провайдером Wave для всея питонщиков, было показано, как легко и красиво, некий pycow превращает python в javascript. Пакет содержит два простых и однозначных метода — translate_string и translate_file. Работает так, как заявлено, весит немного. Использует прозрачную модель объявления классов и базируется на стандартном модуле ast из python2.6. Использует кроссбраузерную библиотеку mootools. То что надо для web проектов, не претендующих на мировое господство.
Есть в debian/lenny такой недостаток — отсутствие python2.6. Вроде ерунда — 2.6 есть в “experimental”. Чтобы сделать его по умолчанию, не вводить python2.6 при каждом запуске, и избежать “расслоения” уже работающего софта — нужно еще пройтись по этому руководству. И что? Правильно, встанет следующая проблема, особенно актуальная если у вас на этом сервере уже крутятся работающие сервисы. Проблема называется “Глобальные библиотеки”. Стандартные и не очень.
После смены python по умолчанию, придется еще сидеть над логами всех сервисов, ничего не упустить и установить нужные библиотеки. Даже если служб меньше десятка — вялотекущая ловля граблей может происходить несколько недель. Ни сна, ни покоя, тем более, что в самом “experimental” библиотек под 2.6 не так уж много. Устанавливать глобальные библиотеки из distutils опять таки — некошерно. Глобальными библиотеками на productive сервере должна заниматься система контроля дистрибутивов ОС, это мое мнение.
На этом этапе рассуждений, мой переезд в 2.6 имел все шансы прекратится, если бы не тот факт, что 2.6 полностью совместима с 2.5. Значит достаточно переспросить у 2.5 где он берет свои глобальные библиотеки и запихнуть эти библиотеки в PATH для 2.6.
Для таких задач есть специальный пусковой файл /etc/python2.6/sitecustomize.py — этот файл выполняется при каждом запуске python.
В него (с Богом, помолясь) добавляется такой потенциальный генератор граблей:
import pickle
import commands
libs2_5_cmd = 'python2.5 -c "import sys; import pickle; print >>sys.stdout, pickle.dumps(sys.path)"'
try:
py2_5_libs = pickle.loads(commands.getoutput(libs2_5_cmd))
sys.path.extend(py2_5_libs)
except Exception, e:
import warnings
warnings.warn("Attempt to load libs from python2.5 failed with error \n%s\nDebug file '%s' to resolve this"%\
(e, __file__))
Во избежание, пути для 2.5 добавляются в конец. Если верить в то, что приложения будут добавлять свои локальные библиотеки в начало — проблем быть не должно.
С этого момента все библиотеки под Python2.5 будут находится интерпретатором Python2.6, и можно начинать не торопясь принимать взвешенные решения.
– Раз-два-раз, яйцетряс, проверка связи, проверка связи.
Работет. Отлично работает. После установки, пропадают остатки желания городить свой блог :) Этот уже не догнать, в одиночку. Да и незачем.
Остается только склепать свою тему. Скорее всего, это будет надстройка над andreas08, с подключенными компрессорами для Clevercss и Pycow.
Потом — вглубь, прицеплять RDFa разметку.
Еще одно направление — глобальные словари ссылок, основанные на том же RDF. Чтобы, например, Mozilla рендерился в ссылку на сайт mozilla.com, но Mozilla Dev(elopment) — в ссылку на MDC. Можно конечно регекспами сделать (наверно даже уже сделал ктото). Но у регекспов, для решения массивных задач есть недостаток — прозрачная и одновременно гибкая архитектура слабо реализуема. По крайней мере мне ничего не придумывается. Хотя из меня архитектор то — не очень…
