Как я и предполагал, создание JavaScript backend-а для cl-closure-template (моей Common Lisp реализации Closure Template от Google) оказалось делом тривиальным и я уложился в 150 строк кода. Чуть интереснее обстояло дело с тестами, для генерируемого JS. Писать их руками очень не хотелось, но ведь по сути, тесты для CL backend-а и JS backend-а должны быть одинаковы, ведь делает же код одно и тоже, и тестировать его надо одинаково, так родилась мысль использовать общий набор тестов и для CL и для JS версии. Можно было подумать, над какими-нибудь своими макросами для тестов, но всё оказалась проще: для тестов я использую LIFT, который сохраняет всю информацию о тестах в свойствах символов, а это позволило в несколько десятков строк кода полностью автоматизировать процесс создания тестов для JavaScript на основе тестов для Common Lisp. Собственно, я сначала сделал эти тесты, после чего разработка backend-а и стала действительно тривиальной (поправил код, переключился в браузер, посмотрел что не так и т.д.). Сейчас оба backend-а проходят все тесты, так что счёл возможным поставить метку "version-0.1" - можно использовать :) Итого, длительность разработки - 7 дней.
P.S. Интересное наблюдение, SLOCCount оценивает мою работу в 40 000$ (за 7 дней, кто б мне так платил ;)),а оригинальную версию почти в 500 000$. При этом, оригинальная версия пока несколько превосходит мою по функциональности (см. подробности в предыдущем сообщении), но при этом в расчёт стоимости моей версии входят тесты, которые по объёму, но не по сложности написания, составляют почти половину кода. Таким образом, немного поколдовав с калькулятором, можно говорить, что экономически использование Common Lisp примерно в 10 раз более выгодно, чем использование Java, вот как :) ...Ну, конечно, можно сделать и какие-нибудь другие выводы, но мне нравится этот :)
понедельник, 16 ноября 2009 г.
Подписаться на:
Комментарии к сообщению (Atom)
ну теперь-то надо анонс давать!
ОтветитьУдалитьНе, надо ещё один прост написать о том, зачем это вообще надо :) Сейчас малого положу и сяду писать :) и может и какой-нибудь хелловорд придумаю....
ОтветитьУдалить@Alex Ott
ОтветитьУдалитьГотово, анонс есть ;)
Отличная работа с closure-templates! Спасибо!
ОтветитьУдалитьА почему javascript backend столько избыточного кода генерит? Почему бы не заюзать soyutils.js из гугловской реализации или свой аналог?
@Alexey
ОтветитьУдалитьДа, я видел, что кода много лишнего, но для моих задач (внутренние корпоративные проекты) это особо не существенно, поэтому я особо не вникал в чём там дело. Возможно, в parenscript. А если выставлять сервис на основе этих шаблонов в интерент, то я планировал использовать Closure Compiler, так что тоже проблем быть не должно.
Мои потребности в данном сервисе пока удовлетворенны, а я считаю что любой код должен быть мотивирован (иначе будет слишком сферическим), поэтому над этим и не работаю.
Но, в любом случае, если у вас есть потребность - патчи приветствуются ))