June 23rd, 2009

satyr

common lisp @ serious business


Я уже вроде рассказывал, что кое-что на CL мне повезло программировать на "реальной работе" ™ Вкрадце, это некий генератор проектов для внутренних нужд, который по заданному описанию (простенький dsl) генерирует sql-схему базы данных, библиотечку для несложной обработки данных, клиентские биндинги на сях и веб-морду для управления базой. Отдельный упор там на простоту замены бекендов (базы данных, в текущем проекте postgres и mysql, но в перспективе хоть plaintext) и API (сейчас только си, но мало ли потребуется еще что-то, навроде перла).


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


Во-первых, это continuation-based web framework, а это означает, что основные подходы к разработке кардинально отличаются от привычных в вебе. Но зато очень похоже на программирование desktop-ных приложений :) Религия weblocks такова: в процессе можно с чистым сердцем забыть про http (а это значит, что никаких сессий, разборов request'ов и пр.), и практически отстранится от написания html/js, при этом ничем не жертвуя. Чем-то отдаленно смахивает на гугловский GWT, но с CL вместо джавы и call/cc.


Из всего этого получается, что порог въезжания в тему достаточно высок, благо надо многое переосознать. Но имхо оно того явно стоит :) Weblocks -- очень хороший фреймворк, в котором многие недостатки continuation-based фреймворков были исправлены. Например, необходимость постоянной полной перерисовки страницы залечена активным использованием Ajax-a. Javascript-ом подсасывается только те виджеты, которые нужно отрендерить заново. Практически полное сходство с десктопной программой :) При этом (о чудо), веб-приложение будет работать даже с отключенном джаваскриптом и нормально индексироваться поисковиками.


Модного нынче де-факто MVC тут нету, взамен предоставляется другая идеология. Дизайнерам предлагается сосредоточится на CSS (а изменить им в веблоковской странице можно почти все -- каждый минимальный элемен торчит в своем div-e), верстальщикам предлагается выучить CL и писать методы render-widget к виджетам (точнее не так -- CL-программистам выучить html, хотя бы по-минимуму, на уровне CL-WHO). Прослойка для доступа к данным представлена интерфейсом "store" с уже готовыми бекендами для clsql, cl-elephant, prevalence и просто memory. Ну а остаток добра честно пишет программист, комбинируя на странице виджеты и создавая собственно код для обработки.


Из всего вышенаписанного становится понятно, что фреймворк достаточно объемный и сложный. И вот на этом месте моментально появляется большой и толстый минус -- в сети практически нет никакой документации. Единицы туториалов, отзывов, tinaa-описание, кое-что можно нарыть в maillist'e, но на этом все. Поэтому путь для освоения следующий: заценивание экзамплов и чтение кода -- очень много чтения кода, благо он понятный и хорошо прокомментирован.


Сразу могу обнадежить будущих адептов: weblocks -- потрясающая по своей гибкости штуковина. Все задуманные в мозгу идеи сделать МОЖНО, даже если для этого не было заранее подстелено соломки разработчиками фреймворка. Не надо городить никаких workaround'ов, надо просто еще раз поисследовать исходники веблоксов на предмет места, которое надо достаточно стройненько перегрузить. Для примера можно посмотреть как в /snippets реализуются такие мега-модные вещи, как suggest или isearch. Существует даже такой экстремальный маневр: если не удается втиснуть текущее ТЗ в рамки уже существующих инструментов (готовых виджетов или интерфейса store), совершенно спокойно можно на них плюнуть и рядом написать с нуля свои. Практически никаких бонусов weblocks от этого потеряно не будет.


Теперь о еще кой-каких минусах. Их почти нет, но кое-что меня тревожит. Например, это производительность. Я не тестировал все добро на нагрузки, но код фреймворка явно написан в пользу читаемости, а не производительности. С другой стороны, направления действий тут видны достаточно явно: nginx на фронтенд для раздачи картиночек, и различные кэширования данных на разных уровнях, благо это continuation-based, и никаких костылей вроде memcached не нужно. Но есть одна штука, с которой я пока сходу ничего придумать не могу -- как масштабировать приложение на несколько машин. В случае с традиционным request/response + sessions тут все ясно, а как это делать прозрачно в сервере на продолжениях -- понятно смутно. Надо же как-то шарить кучу мелких данных по всему кластеру. Возможно, отца русской демократии спасет некого-рода балансировщик нагрузки на фронтенде, который по id сессии будет раскидывать отдельных пользователей на отдельные самостоятельные сервера.


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