Clojure

Впечатления о ClojureScript

2012-05-26T11:59:00.000+03:00

На прошлой неделе решил наконец ознакомиться с ClojureScript по-подробнее. До этого я смотрел презентацию Рича Хикки и некоторые другие скринкасты, успел "пощупать" ClojureScriptOne и почитать пару статей о том, как он (ClojureScript) крут. В общем, никаких особых сложностей с ним я не ожидал, поэтому начавшиеся приключения стали для меня откровенным сюрпризом.

Во-первых, мне не удалось создать browser-connected repl, соединенный со своей html-иной. Я выполнял простые туториалы шаг за шагом, и на этапе соединения у меня ничего не получалось. Тогда я запустил проект samples/repl, входящий в поставку ClojureScript. И все было хорошо до тех пор, пока я не попытался соединиться с веб-страницей. В результате, при помощи Дэвида Нолена и еще нескольких разработчиков ClojureScript выяснилось, что документация чуть-чуть не соответствует. После моих гневных отзывов её (документацию) наконец поправили, а я напишу здесь русский вариант туториала о том, как начать работать с ClojureScript.

1. Качаем с гитхаба последнюю версию ClojureScript.
2. Настраиваем emacs:
a) Создаем файл browser-repl.sh с правами на выполнение:
#!/bin/sh

if [ "$CLOJURESCRIPT_HOME" = "" ]; then
CLOJURESCRIPT_HOME="`dirname $0`/.."
fi

CLJSC_CP=''
for next in lib/: lib/*: src/clj: src/cljs: test/cljs; do
CLJSC_CP=$CLJSC_CP$CLOJURESCRIPT_HOME'/'$next
done

java -server -cp $CLJSC_CP clojure.main -e \
"(require '[cljs.repl :as repl])
(require '[cljs.repl.browser :as browser])
(def env (browser/repl-env))
(repl/repl env)"

б) Прописываем в .emacs настройки для inferior-lisp'a:
(setq inferior-lisp-program "~/clojure/clojurescript/browser-repl.sh")

Здесь "~/clojure/clojurescript/browser-repl.sh" -- естственно, путь к созданному на шаге 2а файлу browser-repl.sh.

3. Добавляем clojurescript/bin в $PATH.

4. Заходим в каталог clojurescript/samples/repl, компилируем исходники: cljsc src/ > main.js

Файл main.js будет позднее использоваться в index.html

Обратите внимание на содержимое файла test.cljs. Он содержит такую строчку:
(repl/connect "http://localhost:9000/repl")
Именно она позволяет затем соединиться с Emacs-ом.

5. Файлы index.html, main.js и каталог out необходимо захостить на каком-нибудь веб-сервере. Я, например, просто создал каталог Tomcat7/webapps/my и сложил туда все это барахло. В моем случае страница index.html стала доступна по адресу localhost:8080/my/index.html.

Внимание! Хостить страницу обяхательно, просто открыв её как файл с диска вы не сможете к ней подконнектиться из Emacs-а!

6. Запускаем Emacs, выполняем команду M-x inferior-lisp.

7. Вводим следующие команды:
(require '[cljs.repl :as repl])
(require '[cljs.repl.browser :as browser])
(def env (browser/repl-env))
(repl/repl env)

8. Загружаем/обновляем index.html в броузере. После этого repl в Emacs-е должен заработать. Например, вычисление (+ 1 1) должно выдать ответ 2. Если это произошло -- вуаля! у вас веб-консоль прямо в Emacs-е!

В моем примере index.html содержит следующий фрагмент:

      <div id="dates">
 <div>23.05.2012</div>
 <div>25.05.2012</div>
 <div>27.05.2012</div>
 <div>28.05.2012</div>
 <div>29.05.2012</div>
      </div>

Таким образом, команды на скриншоте изменяют размер шрифта и цвет текста первой даты.

Вообще, документация на ClojureScript достаточно бедная. Поэтому, вместо того, чтобы искать блог-посты и туториалы по использованию ClojureScript, я просто стал читать его исходники. Рекомендую для этого воспользоваться инструментом Marginalia. С Leiningen 2 это вообще просто.

1. В .lein/profiles.clj добавьте плагин lein-marginalia

{:user {:plugins [ [lein-marginalia "0.7.0"]
[lein-pprint "1.1.1"]
[lein-swank "1.4.4"]]}}

2. Создайте новый проект: lein new clj-docs
3. Скопируйте в катлог cljs-docs/src содержимое каталогоа cljorescript/src.
4. Выполните команду lein marg, и в каталоге docs будет создан файл uberdoc.html, который слева содержит комментарии к исходнику, а справа -- сам исходник.

Еще стоит ознакомиться с Google Closure API -- тоже полезное подспорье в работе с ClojureScript.

Ну а в целом, ClojureScript мне очень понравился, и я надеюсь использовать его дальше в своих проектах.

Гусеничный Lisp-трактор

2012-05-08T16:55:00.001+03:00

Просматривая записи Казимира Майорника, нашел у него очень любопытную статью. Это всего лишь забавный эксперимент, показывающий, как при помощи лисповой парадигмы "код-как-данные" можно реализовать циклическое выполнение кода без циклов и рекурсий. Никакой практической ценности в этом нет, просто красиво смотрится. Я написал что-то похожее на Clojure, но несколько усовершенствованное. В моей версии алгоритм выглядит так.

1) Список f содержит всего одну функцию. Её и запускаем первой.
2) Первая функция передает свой код в update.
3) Update "препарирует" код, находит номер текущей итерации, инкрементирует его и собирает такую же функцию, как ей передали, но с новым значением итерации.
4) Первая функция получает вторую функцию и добавляет её в конец списка f. Если список f содержит более трех элементов, то первый элемент списка f удаляется. Таким образом, в списке f содержится не более четырех элементов.
5) Первая функция запускает вторую функцию и завершается.

Выглядит и впрямь, как гусеничный трак :-)

(defn update [func]
  (let [p (nth func 2)        ;; Получить список (println (str "Hi for the " 1 " time!"))
        n (nth (second p) 2)  ;; Получить 1 из списка
        ;; Создать список (println (str "Hi for the " 2 " time!"))
        new-p (cons 'println (list (map #(if (= n %) (inc n) (identity %)) (second p))))]
    ;; Заменить в теле функции (println (str "Hi for the " 1 " time!"))
    ;; на (println (str "Hi for the " 2 " time!"))
    (map #(if (and (seq? %) (= (first %) 'println)) new-p (identity %)) func)))

(def f (ref ['(fn []
                (println (str "Hi for the " 1 " time!"))
                (let [func (last @f)
                      ;; Обновить список функций f
                      ;; Удалить первую функцию, если список f содержит больше трех элементов
                      new-f (if (> (count @f) 3)
                              ;; Добавить обновленную функцию в конец списка
                              (conj (vec (drop 1 @f)) (update func)) 
                              (conj @f (update func)))]
                  (dosync (ref-set f new-f))
                  ;; Выполнить последнюю функцию списка
                  ((eval (last @f)))))]))

((eval (last @f)))

CEDET 1.1, Emacs и Java

2012-05-07T15:03:00.002+03:00

Недавно вышедший Cedet 1.1 добавляет долгожданную поддержку импорта символов из jar-ок. Теперь Emacs предоставляет поддержку автодополнения кода java примерно на том же уровне, что и современные IDE.

Например, у нас есть класс My1:

Он используется в My2:

Обратите внимание, как flymake параллельно скомпилировал файл и подсветил ошибки. Если набрать “my.” и выполнить функцию semantic-ia-complete-symbol-menu (у меня она замаплена на Ctrl-Space), то Emacs выдаст такую подсказку:

Аналогично можно запрашивать подсказку по членам системных классов. Например, для StringBuilder:

Правда надо учитывать, что, во-первых, импорты “звёздочкой” не срабатывают, системных классов semanticdb-javap тоже не знает. Поэтому, если необходимы подсказки, то импорт классов из неймспейса java.lang нужно делать явно, как в моем примере.

Для того, чтобы заработали показанные выше механизмы, необходимо следующее:

установленный пакет flymake;
установленный пакет auto-complete;
скачанный CEDET 1.1;
Ну и конечно же, последний Emacs и java.

Конфигурация CEDET в .emacs :

(load-file "~/cedet/common/cedet.el") ;; Подгрузить cedet

(global-semanticdb-minor-mode 1) ;; Инициализировать semanticdb

;; Загрузить поддержку авто-дополнения

(semantic-load-enable-gaudy-code-helpers)

(custom-set-variables ;; Инициализация переменных, указывающих, где

;; установлена java

. . .

'(cedet-java-jdk-root "/opt/jdk")

;; Сюда нужно добавить все jar-ки, из

;; которых необходимо импортировать символы

'(semanticdb-javap-classpath '("/opt/jdk/jre/lib/rt.jar"))

. . .

)

Конфигурация flymake:

(require 'flymake)

(add-hook 'java-mode-hook 'flymake-mode-on)

(defun my-java-flymake-init ()

(list "javac" (list (flymake-init-create-temp-buffer-copy

'flymake-create-temp-with-folder-structure))))

(add-to-list 'flymake-allowed-file-name-masks '("\\.java$" my-java-flymake-init flymake-simple-cleanup))

Конфигурация auto-complete:

(require 'auto-complete-config)

(add-to-list 'ac-dictionary-directories "~/.emacs.d/ac-dict")

(ac-config-default)

Итоги за месяц

2012-03-29T11:59:00.000+03:00

Давно не писал сюда из-за нехватки времени. Но вот, наконец, я достаточно освободился, чтобы набросать пару строк в блог.

Со времени последней записи у меня произошло много интересных событий, и многое можно было бы описать здесь, т.к. почти все так или иначе связано с Clojure. Наиболее интересное, на мой взгляд, -- это первое в моей практике применение Clojure на коммерческом проекте. О нем вкратце и расскажу.

Проект, который я делал с начала февраля по середину марта, -- андроид-приложение для планшетов. Оно предназначалось для дистанционного обучения какой-то фигне сотрудников какой-то компании. Технических сложностей там никаких нету, писать здесь не о чем, за исключением достаточного большого объема работы: необходимо было реализовать 22 формы со всякими разными украшениями. Дополнительная сложность -- необходимо написать еще и JSON веб-сервис, который может отдавать запрашиваемые данные и сохранять у себя ответы пользователей на опросы и тесты.

Дедлайн был очень жесткий: 12 марта. На мой взгляд, при таких объемах и сроках проект должен делать не один человек, а как минимум трое.

Во-первых, мне удалось уговорить заказчика разрешить писать веб-сервис на Clojure вместо java. По моим прикидкам, это сэкономило бы мне неделю работы. Для заказчика были крайне важны сроки, и он позитивно воспринял мое предложение, но поинтересовался: какие минусы у clojure? Я честно сказал, что этот язык просто менее распространен, чем java. Все остальное -- то же, что и у java. Например, готовый сервис мы захостим под Tomcat в виде war-файла. Заказчик согласился с этим риском, заметив, что если вдальнейшем будет необходимость, то тогда вебсервис можно будет переделать на java. Забегая вперед скажу, что необходимость не возникла :-)

Я воспользовался библиотеками noir1.3-alpha10, cheshire, sqlkorma, lobos и очень быстро показал работающий сервак. Функциональность в сервак я добавлял в процессе работы над клиентской частью по мере необходимости. Поскольку я пользовался связкой Emacs+Slime, рабочий код я получал очень быстро. А время, которое я тратил на разработку очередной функции сервака, в среднем равнялось нескольким минутам.

Основное время, конечно же, занимала Android-часть, причем в основном -- настройка внешнего вида формочек. Android -- неплохая платформа для пользователя, но очень сырая и недоделанная для разработчика. В отличие от ябловодов, нам, андроидам, нет возможности пользоваться WYSIWYG-редактором для построения GUI. А редактировать гигантские простыни xml-кода вручную -- сомнительное удовольствие...

Решение нашлось довольно быстро. Я разработал небольшой DSL на основе Clojure и Hiccup. С применением этого DSL формочку я целиком описывал на Clojure, а потом генерил из неё связку xml и java-кода (при этом генерился весь MVC на форму). В среднем, количество кода в DSL и количесство сгенеренного xml+java кода соотносились как 1:3 или 1:4, что уже очень неплохо. Еще один важный бонус, который я получил от этого DSL -- возможность использования нормального вменяемого языка для описания UI вместо XML. Появилась возможность выносить общую функциональность в функции, делать циклы и т.д. Понятно, что большинство повторно используемых компонент оформлялись как отдельные виджеты; но там, где для этого не было необходимости -- я просто объявлял функцию на Clojure. Еще важное замечание: код в стиле Hiccup читается гораздо проще, чем xml.

Дальше развивать свой DSL у меня уже не было времени, а повторяющийся код, который я не мог обобщить, все равно встречался. Например, код для работы с БД и вебсервисом состоял по большей части из извлечения-записи в хеш-таблицы по ключам, соответствующим именам полей в БД. Здесь мне на помощь пришел Emacs. Буквально пара десятков строк кода на elisp-е, и весь оставшийся boilerplate-код на java генерил Emacs.

Надо сказать, что в сроки я уложился, но с учетом, что в конце проекта на 2 недели мне дали в помощь товарища. Думаю, получилось очень даже хорошо.

Деплоймент Clojure под Tomcat

2012-02-19T11:35:00.000+03:00

Не так давно я взялся за небольшой проект с клиент-серверной архитектурой. JSON веб-сервис мне позволили реализовать на clojure, что я очень быстро и сделал при помощи библиотек: Noir, Lobos, Korma и Cheshire. Но зато была масса непоняток с деплойментом этого готового сервиса на хостинг. Во-первых, по непонятной причине, оригинальный сервер, поработав какое-то время, попросту отваливается. Я до сих теряюсь в догадках, что заставляет его так капризничать. Понятное дело, что я решил задеплоить всё на Tomcat.

Мне не удалось нигде найти нормальной инструкции о том, как деплоить noir-приложение под томкат, так что я решил восполнить этот пробел.

Данная инструкция рассчитана на веб-сайт, разработанный на clojure при помощи фреймворка Noir (опробовано на noir 1.3.0-alpha10).

1) Добавьте [lein-ring "0.5.4"] в :dev-dependencies вашего файла project.clj.
Внимание! [uk.org.alienscience/leiningen-war "0.0.13"] – это не то же самое, что lein-ring. Плагин lein-ring умеет создавать ring-handler для noir-приложения и запаковать все в war-ку. А плагин leiningen-war только создает war-ку, а ring-handler-а не создает.

2) В файле project.clj укажите ваш ring-handler и пространство имен для ahead-of-time компиляции.
:ring {:handler MyProject.server/handler}
:aot [MyProject.server]

3) Создайте ring-handler в server.clj:
(:require [noir.server :as server])
. . .
(def handler (server/gen-handler {:base-url "/myproject"}))
Внимание! Обязательно нужно указать :base-url, иначе редиректы и линки задеплоенного в томкат приложения будут указывать не на localhost:8080/myproject/, а на localhost:8080/ . Эпик фейл будет фееричный!

4) Уберите такую загрузку вьюх: (server/load-views "src/MyProject/views/") из файла server.clj. Вьюхи нужно загружать явно:
(:require [noir.server :as server]
. . .
[MyProject.views.pages])
Если этого не сделать, то после упаковки в war-ку и даже jar-ку, ни один ваш маршрут работать не будет.

5) Все линки и формы, если вы их генерите из hiccup, нужно создавать функциями:
(hiccup.form-helpers/form-to [:post "/myurl"] ...)
(hiccup.page-helpers/link-to "/myurl" …)
Если этого не сделать, то они будут вести на localhost:8080/ вместо localhost:8080/myproject.

6) Создайте war-ку командой lein ring uberwar.
Внимание! Команда lein ring uberwar поставляется с lein-ring-плагином, и в нашем случае она работает. Команда lein uberwar поставляется с плагином leiningen-war, и здесь она не работает. Так что этот плагин вообще лучше не использовать с noir.

7) Скопируйте war-ку в webapps томката и переименуйте её в myproject.war.

Теперь, после запуска томката, по адреусу localhost:8080/myproject будет ваше приложение.

Noir benchmark

2012-01-22T18:01:00.000+03:00

Решил немного потестить простое веб-приложение, описанное в предыдущей статье. Тесты проводились на ноутбуке Acer Aspire 5745G (Intel Core i5 2.26Ghz, 4Gb). Обнаружил следующее.

Во-первых, при запуске сайта командой lein run запускаются два java-процесса. Первый, занимающий 28.8Mb -- видимо служебный, т.к. никакие его характерстики за время работы приложения не менялись. Второй, сходу запросивший 76.7Mb, -- само веб-приложение. Я создал два типа сущностей: mypage и mypage2 с CRUD-действиями для них, не используя БД. Т.е. скорость обработки запроса целиком зависила от скорости работы java-машины и не зависела от скорости ввода-вывода или поиска данных в таблицах. При обращении к различным действиям сущности mypage объем потребляемой памяти возрос до 90.3Mb. При обращении к mypage2 -- до 93.5Mb. При повторном обращении к этим же сущностям потребление памяти никак не поменялось. При перезапуске приложения цифры изменились до 96Mb и 99Mb.

Интересно взглянуть на производительность веб-приложения под нагрузкой. Я создал скрипт, делающий 70000 таких запросов:
wget http://localhost:8080/mypage
wget http://localhost:8080/mypage/848867
wget http://localhost:8080/mypage/edit/996283
wget http://localhost:8080/mypage/527997
wget http://localhost:8080/mypage/edit/410389

Сущности с указанными айдишниками, естественно, существовали в приложении. Эти 70тыс. запросов jetty обработал за полчаса, отдавая, таким образом, примерно 2333 динамических страницы в минуту или примерно 39 в секунду.

Самым интересным для меня в этом эксперименте стало потребление памяти и процессорного времени.

Сначала jetty затребовал 92% процессорного времени, но его запросы довольно быстро сократились до 40%. Затем, довольно медленно, и они стали снижаться. К концу эксперимента jetty потреблял всего 4% процессорного времени.

Аналогично, запросы памяти сначала были немалыми. Довольно быстро jetty "откушал" 232.8Mb, после чего потребляемая память стала уверенно снижаться, остановившись на отметке 84.6Mb.

Надо еще учитывать, что нагрузка на сервер была ограничена возможностями консоли, в которой работал wget, ведь его вывод на экран тоже занимает какое-то время. Но, по крайней мере, верхнюю границу запросов процессора и памяти мы получили. Нижняя, естественно, достоверной не является.

Такое снижение потребляемой памяти и процессора стало возможно благодаря run-time оптимизациям java-машины (в Sun некогда здорово над этим поработали). Вот и скажи теперь, что java -- медленная...

CRUD на Clojure средствами Noir

2012-01-08T12:22:00.001+03:00

Давно собирался рассказать немного о Noir – классном веб-фреймворке для Clojure. Наконец, у меня появилась возможность написать большой туториал по применению Noir, что я с удовольствием и сделаю :-)

Есть ли вообще необходимость в самоучителе по Noir? Не очень существенная, если честно. На сайте фреймворка (webnoir.org) более чем приличная документация: раздел для быстрого старта, несколько обучалок по использованию Noir и даже индекс API. Мой туториал, возможно, будет вам полезен, если вы, зная Clojure и разобравшись более-менее с Noir, все еще не очень представляете себе архитектуру своего будущего приложения.

А задуматься над архитектурой придется. Noir очень сильно отличается от всех известных мне фреймворков. При своем минимализме он оставляет выбор конкретных библиотек за пользователем – такая свобода может привести к неверному их использованию. Насколько этот выбор широк можете судить хотя бы по статье с обзором разных компонентов для каждого из уровней веб-стека на clojure.

Давайте посмотрим, на что похоже приложение Noir. Если вы проследовали инструкциям из Getting Started на сайте webnoir.org, то у вас уже установлен leiningen-плагин для Noir. Создадим новый проект командой lein noir new optimalist. У него очень простая структура.

resources – содержит каталог public со статическим контентом (css, javasript, images);

src – каталог с исходниками;

test – тесты;

project.clj – описание проекта и версий подключаемых библиотек.

Исходники содержаться в двух каталогах src/optimalist/views и src/optimalist/models. Никаких вопросов не вызывает? А как насчет src/optimalist/controllers? Такого каталога нету, т. к. самописных контроллеров здесь не предусмотрено. Это, конечно, у многих может вызвать разрыв шаблона: как вообще программировать MVC без C!

Автор Noir Крис Гранжер очень подробно обосновал свое представление архитектуры. Исторически сложилось, что бизнес-логику обычно помещали в контроллер. Но со временем её все больше и больше выносили в отдельные компоненты, контроллер стал совсем тоненьким и, откровенно говоря, ненужным. Функции маршрутизации берет на себя фреймворк, так что в Noir (да и в других современных веб-фреймворках) строгой необходимости в отдельных контроллерах попросту нету. Единственное, что всё еще делает контроллер – это указывает, какую страницу рендерить в ответ на запрос пользователя. Раз уж код контроллера такой маленький, то Крис Гранжер попросту решил перенести функции контроллера на уровень View.

Если сравнивать такой подход с другими фреймворками, то, пожалуй, Крис – один из первых, кто открыто решился заявить о ненужности контроллеров. Например, в практике программирования Ruby on Rails всё еще считается правильным всю бизнес логику вынести на уровень модели, а контроллеры сделать маленькими и легковесными. Это очень упрощает тестирование. Но это половинчатый подход: выбросили бы контроллеры да и дело с концом! Скажем, в JSF2.0 примерно так и обстоят дела. Вся бизнес-логика находится в Java-бинах, вызываются они с уровня View напрямую, минуя слой контроллера. Маршруты привязываются к страницам обычно централизованно в специальном файле конфигурации.

Поскольку каталог models пустой, давайте взглянем повнимательнее на содержимое каталога views.

В файле common.clj создается специальная функция layout. Она задает общий шаблон страницы, заголовки и структуру html-файла.

В файле welcome.clj при помощи defpage задается маршрут «/welcome» и функция, которая сгенерирует ответ на запрос пользователя по этому маршруту. Как видно из кода, функция вернет строку приветствия. Шаблон html-страницы создается при помощи библиотеки Hiccup. Она позволяет писать html-код прямо на языке clojure при помощи родных для clojure структур данных: векторов и мапов.

Hiccup очень удобен тем, что позволяет производить любые манипуляции с шаблоном прямо при помощи Clojure. Заметьте, такой подход вообще не встречается среди мейнстримных фреймворков. Что в ASP.NET, что в J2EE для разметки страницы применяется свой собственный DSL, построенный на базе XHTML. Как, например, сделать повторяющийся фрагмент страницы на JSF2.0, на которой еще есть экшены? Правильно, с применением ломика и какой-то матери. В ASP.NET с этим, вроде, несколько проще, но подход такой же: xml-теги. Ну и скажите мне, как программисту Java, почему я не могу использовать Java для изменения шаблона веб-страницы? Как ни крути, но даже Java... хотя нет, уж лучше этот долбаный XML, чем веб-страницы на Java...

Короче, в Noir используется hiccup, а hiccup позволяет писать html-страницы на clojure в декларативном стиле.

Вручную hiccup-код имеет смысл писать только для страниц очень небольшого размера. Если вам досталась от дизайнера монстрозная страница в десятки килобайт кода – конечно, такое поделие переписывать на hiccup не стоит. В этом вам поможет clj-tagsoup. Просто вызовите его функцию parse с указанием html-страницы и сохраните полученный hiccup-код.

Почти все руководства о веб-фреймворках в виде первого учебного приложения предлагают свой вариант блога. Давайте и мы сделаем свой простой блог при помощи Noir. Переименуем welcome.clj в article_pages.clj (а также namespace) и напишем код первой страницы блога – списка записей. Еще я немного изменил список импортируемых библиотек.

(ns optimalist.views.article_pages
  (:require [optimalist.views.common :as common]
            [noir.response :as resp])
  (:use [noir.core]
        [hiccup.core]))

(defpage articles "/articles" []
         (common/layout
           [:p "List of articles"]))

Обратите внимание, что маршрут «/articles» – именованный. В будущем я смогу получить его при помощи (url-for articles).

Запустите веб-приложение командой lein run и откройте его по ссылке localhost:8080/articles. Разумеется, вы увидите текст «List of articles». Но пока что еще не работает корневой маршрут: localhost:8080/. Давайте добавим для него определение маршрута.

(defpage "/" []
  (resp/redirect (url-for articles)))

Как видите, здесь объявляется неименованный маршрут «/», и вместо ответа на него сервер редиректит на страницу articles.

Следующая проблема: как вывести список каких-либо элементов? Поскольку код шаблона мы пишем на clojure, то воспользуемся функцией for:

(defpage articles "/articles" []
  (let [data [{:id 1, :title "First title", :body "First body"}
              {:id 2, :title "Second title", :body "Second body"}
              {:id 3, :title "Third title", :body "Third body"}]]
         (common/layout
          [:p "List of articles" [:br] [:br]
           (for [item data]
             [:div
              (:title item)
              [:br]
              (:body item)
              [:br][:br]])])))

Пока что все достаточно просто, не так ли? Страница articles покажет нам следующий текст:

List of articles

First title
First body

Second title
Second body

Third title
Third body

Теперь данные нужно перенести в отдельный файл. Создадим в каталоге models файл article_model.clj, добавим туда код:

(ns optimalist.models.article_model)

(def *data*
  (ref
   [{:id "1", :title "First article", :body "Lorem ipsum dolor sit amet."}
   {:id "2", :title "Second article", :body "Lorem ipsum dolor sit amet."}
   {:id "3", :title "Third article", :body "Lorem ipsum dolor sit amet. "}
   {:id "4", :title "Fourth article", :body "Lorem ipsum dolor sit amet."}]))

(defn fetch-list []
  @*data*)

Воспользуемся этой моделью. Чтобы импортировать модель, добавим в секцию require такую строку: [optimalist.models.article_model :as article-model]; а код функции articles перепишем таким образом:

(defpage articles "/articles" []
  (common/layout
   [:p "List of articles" [:br] [:br]
    (for [item (article-model/fetch-list)]
      [:div
       (:title item)
       [:br]
       (:body item)
       [:br][:br]])]))

Вообще такая организация кода всё еще не очень удобная. Что если будет несколько страниц с похожим функционалом? Нам придется выносить hiccup-код в отдельные модули чтобы сделать его reusable. Давайте сделаем это сразу. Создатим файл view/article_templates.clj и вынесем туда генерацию httml.

(ns optimalist.views.article_templates
  (:use [noir.core]
        [hiccup.core]))

(defn show-list [articles-list]
   [:p "List of articles" [:br] [:br]
    (for [item articles-list]
      [:div
       (:title item)
       [:br]
       (:body item)
       [:br][:br]])])

В модуле article_pages.clj необходимо добавить строку [optimalist.views.article_templates :as article-view] в секцию :require. А страница articles тогда будет выглядеть так:

(defpage articles "/articles" []
  (common/layout
   (article-view/show-list (article-model/fetch-list))))

Следующая наша задача – добавить к элементам списка ссылки на действия. Лично я – большой любитель технологии REST, о которой узнал из Ruby on Rails. Наши четыре действия над сущностью create, read, update, delete подразумевают наличие семи маршрутов:

Маршрут	Метод	Описание
/articles	GET	Список записей
/article/:id	GET	Просмотреть одну запись
/article/edit/:id	GET	Показать форму редактирования записи
/article/update/:id	POST	Изменить запись в соответствии с указанными данными
/article/delete/:id	POST	Удалить запись
/article/new	GET	Показать пустую форму для создания записи
/article/create	POST	Создать запись в соответствии с указанными данными

Вообще в REST должны использоваться методы не только GET и POST, а также PUT (для создания новой записи) и DELETE (для удаления). Но то ли браузеры не понимают этих методов, то ли веб сервера, но факт остается фактом: использовать мы можем только GET и POST. В Ruby on Rails для обхода этого ограничения создается скрытое поле. И если указывается метод PUT или DELETE, то на самом деле используется POST с пометкой в скрытом поле, что это все-таки PUT/DELETE.

Разные методы отправки запроса нужно использовать не только для красоты. По сети ползают роботы-индексаторы, которые пытаются перейти по ссылкам на другие страницы. Представьте, например, что на вашем сайте кнопка DELETE сделана при помощи обыкновенной ссылки (запрос методом GET), и робот решит по ней перейти. Робот ведь не знает, что эта ссылка приводит к какому-то разрушительному действию, правда? Вот для этого-то все запросы, как-нибудь изменяющие сущность, должны быть отправлены методом POST.

Итак, первая ссылка, которую я хотел бы добавить к списку сущностей – маршрут /article/:id для просмотра записи.

Вначале в article_pages добавим страницу:

(defpage view-article "/article/:id" {id :id}
  (common/layout
   "View article"))

Она пока ничего не делает, но зато её сразу же можно протестить в браузере по маршруту /article/1. Заметьте, что в определении страницы задан хеш параметров {id :id}. Это деструктуризаця параметров запроса, и делает она именно то, на что похоже: создает локальную переменную id, значение которой будет получено из части маршрута :id.

Теперь добавим ссылку на эту страницу в функции show-list

(defn show-list [articles-list]
   [:p "List of articles" [:br] [:br]
    (for [item articles-list]
      [:div  (:title item) [:br]
       (:body item) [:br]
       [:a {:href (url-for (str "/article/" (:id item)))} "View"]
       [:br][:br]])])

Функция url-for умеет создавать абсолютный URL по заданным параметрам. Параметром может быть как текстовая строка с маршрутом, так и сам именованный маршрут. И хотя предложенное выше решение – вполне работоспособное, но оно все-таки не оптимальное. Что если вы решите изменить URL в странице view-article? Тогда вам придется искать все места, где вы на него ссылаетесь, и править маршруты вручную. Лучше использовать именованый маршрут следующим образом:

(url-for optimalist.views.article_pages/view-article {:id (:id item)})

Здесь optimalist.views.article_pages/view-article – полное имя именованного маршрута. Необходимо писать его целиком, т. к. в файле article_templates.clj ничего не известно о aricle_pages.clj. И импортировать article_pages.clj мы тоже не можем, т. к. там уже есть импорт article_templates.clj, и мы получим циклическую зависимость. Поэтому, все-таки, придется писать целиком.

Второй параметр – хеш значений, которые будут переданы в генератор маршрута. Поскольку наш маршрут выглядит как «/article/:id», то ему нужно передать хеш {:id <значение>}.

Вообще, конечно же, такая запись жутко громоздкая и неудобная. Поэтому в начало файла article_templates.clj, после объявления неймспейса, добавим алиас:

(alias 'article 'optimalist.views.article_pages)

Теперь генерацию ссылки можно переписать таким образом:

(url-for article/view-article {:id (:id item)})

Это уже значительно лучше, но все еще пока не идеально. Элементов типа «ссылка» у нас будет достаточно много, особенно, если много разных сущностей. Но типов ссылок всего несколько: new, view, edit, delete, back. Мы могли бы сделать более абстрактный механизм генерации ссылок, который инкапсулирует в себе всю внутреннюю структуру вектора [:a …], в том числе и надпись на ссылке. Создадим файл views/helpers/widget.clj:

(ns optimalist.views.helpers.widget
  (:require [noir.core]))

(defmacro view-link [page id]
  `(vec [:a
     {:href (noir.core/url-for ~page {:id ~id})} "View"]))

Теперь его можно подключить в article_templates.clj, добавив строку [optimalist.views.helpers.widget] в секцию :use. А вместо записи [:a {href … } «View»] вставим вызов макроса: (view-link article/view-article (:id item)).

Макрос здесь нужен из-за параметра page – символа, к которому привязан именованный маршрут. Конечно, его можно было бы передавать закавыченным, но это не очень-то красиво.

Сам макрос пока-что не слишком удачный. Что если нам понадобится добавить еще несколько похожих ссылок? Copy-paste – не наш метод, поэтому немного расширим наш язык для данного конкретного случая.

Это очень интересная технология, описанная Полом Грэмом в книге «On Lisp», и называется она «bottom-up programming». Идея заключается в том, что вы не только пишете свое приложение, используя Lisp, но и изменяете Lisp, чтобы легче было писать ваше предложение. Снизу, в язык вводятся новые конструкции, упрощающие реализацию приложения. Сверху, приложение описывается при помощи ваших новых конструкций, что делает код значительно короче. Отсюда и bottom-up programming.

Новые конструкции, которые мы вводим в язык, называются утилитами. Давайте добавим две таких:

(defmacro common-url [page id]
  `(noir.core/url-for ~page {:id ~id}))

(defmacro common-link [url text & params]
  `(vec [:a (merge {:href ~url} ~@params) ~text]))

Первый макрос просто инкапсулирует знание о том, как создавать URL. Теперь нам не надо заботиться о том, чтобы дописывать noir.core к url-for, а также создавать хеш для единственного занчения id.

Второй макрос создает html-ссылку с заданным текстом на указанный URL. Необязательный параметр params – это возможные параметры самой ссылки. Например, если нам потребуется задать обработчик onclick, то мы сможем сделать это через params.

Перепишем текст генерации ссылки с применением двух новых утилит:

(defmacro view-link [page id]
  `(common-link (common-url ~page ~id) "View"))
  
(defmacro edit-link [page id]
  `(common-link (common-url ~page ~id) "Edit"))

Итак, на данный момент, у нас есть список записей и ссылка на просмотр каждой записи. Давайте теперь реализуем функцию view-article:

(defpage view-article "/article/:id" {id :id}
  (common/layout
   (article-view/show
    (article-model/fetch id))))

Чтобы она заработала, нужно в article_templates добавить функцию show:

(defn show [article]
  [:div
   [:h1 (:title article)]
   [:div (:body article)]
   [:br]
   [:a {:href (url-for article/articles)} "Back"]])

В article_model необходимо добавить функцию fetch:

(defn fetch [id]
  (first
   (filter #(= id (:id %)) @*data*)))

На этом, пожалуй, все сложности и закончились. Дальше, по накатанной. Проект целиком вы можете найти здесь, а вот как выглядят два основных файла проекта.

article_pages.clj

(ns optimalist.views.article_pages
  (:require [optimalist.views.common :as common]
            [noir.response :as resp]
            [optimalist.views.article_templates :as article-view]
            [optimalist.models.article_model :as article-model])
  (:use [noir.core]))

(defpage "/" []
  (resp/redirect (url-for articles)))

(defpage articles "/articles" []
  (common/layout
   (article-view/show-list (article-model/fetch-list))))

(defpage view-article "/article/:id" {id :id}
  (common/layout
   (article-view/show (article-model/fetch id))))

(defpage edit-article "/article/edit/:id" {id :id}
  (let [item (article-model/fetch id)]
    (common/layout
     (article-view/form (url-for update-article {:id id}) "Update" (:title item) (:body item)))))

(defpage update-article [:post "/article/update/:id"] {:keys [id title body]}
  (article-model/update id title body)
  (resp/redirect (url-for view-article {:id id})))

(defpage new-article "/article/new" []
  (common/layout
   (article-view/form (url-for create-article) "Create")))

(defpage create-article [:post "/article/create"] {:keys [title body]}
  (article-model/create title body)
  (resp/redirect (url-for articles)))

(defpage delete-article [:post "/delete/:id"] {id :id}
  (article-model/delete id)
  (resp/redirect (url-for articles)))

article_templates.clj

(ns optimalist.views.article_templates
  (:require [optimalist.views.helpers.widget :as widget])
  (:use [noir.core]
        [hiccup.core]))

(alias 'article 'optimalist.views.article_pages)

(defn show [article]
  [:div
   [:h1 (:title article)]
   [:div (:body article)]
   [:br]
   [:a {:href (url-for article/articles)} "Back"]])

(defn list-item [item]
  (let [id (:id item)]
    [:div [:div (:title item)]
     (:body item)
     [:form {:id (str "form-" id) :method "POST", :action (url-for article/delete-article {:id id})}
      [:div
       (widget/view-link article/view-article id) " | "
       (widget/edit-link article/edit-article id) " | "
       (widget/delete-link id)]]
     [:br][:br]]))

(defn show-list [articles-list]
  [:div
   (for [item articles-list] 
     (list-item item))
   [:a {:href (url-for article/new-article)} "New"]])

(defn form [url button-text & [title body & rest]]
  [:form {:method "POST", :action url}
   [:input {:name "title", :type "text", :value title}]
   [:br]
   [:textarea {:name "body"} body]
   [:br]
   [:input {:type "submit", :value button-text}]
   [:br]
   [:a {:href (url-for article/articles)} "Back"]])

my-project.el

2012-01-02T12:20:00.000+03:00

При использовании Emacs мне очень сильно не хватает какого-нибудь простого средства управления проектами. Наиболее важные для меня функции:
1) Быстрый поиск по файлам проекта с автодополнением имени;
2) Запуск etags только по файлам проекта;
3) Поиск по содержимому файлов проекта.

Среди опробованных стандартных решений не нашлось ни одного, подходящего для меня. Поэтому я решил написать свой плагин, которым и хочу здесь поделиться.

Вот как я объявляю проект:

Эта функция создает проект "My", в котором объявлен корневой каталог проекта, несколько артефактов, расширение файлов с исходниками, по которым будет работать etags; в опции find-filе задаются маски файлов для быстрого поиска; в опции exclude указываются строки, при наличии которых файлы исключаются из поиска. Последняя опция удобна тем, что помогает исключить из результатов поиска различные автоматически генерируемые файлы или файлы из каталогa .svn.

Быстрый поиск хотелось сделать как в TextMate. Что-то похожее в Emacs реализуется средствами IDO, но работает не совсем так, как надо. Во-первых, IDO подглючивает при большой вложенности каталогов и большом количестве файлов; во-вторых, find-file ищет от текущего каталога. Если вы находитесь в самой глубине вашего проекта, то для поиска файла в другом каталоге, нужно будет выходить на несколько уровней выше. Я сделал функцию поиска, которая работает от корня проекта и выводит в подсказку весь список всех файлов проекта.

Если набрать дополнительно несколько букв имени искомого файла, IDO поможет отфильтровать список.

Еще одна не очень удобная для меня функция Emacs -- поиск по содержимому файлов. Для этого используется стандартная функция find-grep.

Как видите, при запуске этой функии Emacs выдает подсказку по параметрам команды find, которые нужно заполнить вручную. Самое отвратительное в этом -- это необходимость вручную указывать имя корневой дирректории и шаблона имени файла.

Я сделал свою версию этой функции. Вначале, она спросит, по каким файлам проекта искать.

Затем предложит ввести искомый текст.

После этого откроет новое окно с результатами поиска.

Результаты поиска -- список файлов. Он кликабельный; при нажатии на любую строку мышкой или клавишей Return, файл откроется в этом же окне.

Возможно, мой плагин кому-то покажется полезным. Если у кого-нибудь будет желание -- пишите, попробуем вместе допилить его до production-уровня.

Emacs для разработки на Java

2011-12-18T18:51:00.000+03:00

Меня, как и многих других Java-программистов, сильно не устраивает наша основная IDE: Eclipse. Несмотря на то, что это хорошая IDE, в ней есть серьезный недостаток: крайне убогий текстовый редактор. Он работает по тем же принципам, по которым работают все текстовые редакторы во всех крупных IDE уже лет пятнадцать. Еще во время учебы в школе, когда я программировал в свое удовольствие на Delphi 3.0, уже тогда у меня была IDE по своему функционалу ничуть не уступавшая сегодняшнему Eclipse. И, откровенно говоря, это здорово раздражает: языки развиваются, а инструменты редактирования -- нет.
Сегодня мне от IDE нужно очень многое: и контекстно-зависимый рефакторинг, и автоматическая генерация кода, и умное дополнение. Но самое главное, чего мне не хватает: полная автоматизация всей рутины. Java -- язык крайне многословный. Чтобы реализовать самую небольшую часть функционала зачастую приходится писать массу повторяющегося кода. Даже несмотря на ООП, т.к. не все удается решить наследованием и полиморфизмом в том виде, в котором эти механизмы реализованы в Java.
Уже несколько месяцев я пользуюсь Emacs для написания Java-кода. Это просто потрясающий текстовый редактор! Его так легко расширять новым функционалом, что я делаю это не задумываясь!
Сегодня у меня автоматизированы все повторяющиеся операции. Например, чтобы добавить в код всего одну локализованную строку, необходимо отредактировать минимум три файла: 1) файл Messages.properties, где ключу нужно сопоставить текст; 2) файл Messages.java, где нужно объявить функцию, достающую текст по ключу из файла properties; 3) в файле с описанием UI нужно вызвать этот созданный метод из класса Messages. Как же меня раздражало раньше, когда я делал это вручную! Описываешь формочку из десяти элементов, каждому нужно задать title. И, вместо того, чтобы задумываться над задачей, приходится отвлекаться на поиск этих долбаных Messages.properties и Messages.java и писать туда код богомерзким копи-пейстом! Сейчас мне для этого досточно одного клавиатурного сочетания, и Emacs всё сделает за меня сам. Может быть, я стал слишком ленивым? Знаете, все-таки, это неповторимое ощущение, когда кто-то пишет твой код за тебя!
И так во всём. В каждом проекте есть свои повторяющиеся заморочки. Писать для этого плагин Eclipse -- слишком уж сложно. Вы пишете свои плагины Eclipse для каждого проекта? И я -- нет. Я пишу плагины Emacs.
У Emacs, конечно, есть свои проблемы. Например, достаточно больная тема -- это именно разработка на Java. Все существующие решения для Emacs или безнадежно устарели давно (JDEE), или устарели и больше не поддерживаются совсем недавно (malabar-mode). Емаксеры обычно пишут на C/C++, Java у них не в почете. Но есть один плагин, который закрывает практически все мои потребности в IDE. Это emacs-eclim.
На самом деле, этот плагин -- надстройка над другим замечательным проектом: eclim, который умеет интегрироваться с Eclipse. Разработал Eclim в 2005-м году американский программист Эрик Ван Девостин (Eric Van Dewoestine) для своих нужд. Он хотел сделать интеграцию Eclipse и GVim. Затем опубликовал исходник, и другой программист, Ивес Сенн (Yves Senn), разработал аналогичный плагин к Emacs.
Emacs-eclim умеет практически всё то же самое, что и Eclipse: контекстно-зависимое дополнение кода, рефакторинг (переименование классов, пакетов и т.д.), подсветка ошибок после компиляции, автоматизированый импорт классов, автоматическая реализация интерфейсов и т.д. На изображении показано, как выглядит моё рабочее окружение Emacs.

Мне удалось побеседовать с Эриком об Eclim. Ниже -- перевод моего небольшого интервью, оригинал которого -- в конце статьи.

Я: Привет, Эрик! Расскажи немного о себе. Сколько тебе лет, чем занимаешь, где живешь?
Эрик: Мне 33 года, я работаю программным инженером, живу в Лос Анжелесе, занимаюсь в основном веб-разработкой. Еще со школы я пользовался Java, типичным JEE-стеком и т.д. Но примерно лет пять назад я переключился на python, в основном на Python/Django. Вообще, я довольно открыт к различным языкам программирования, хотя и не пробовал ruby до сих пор.
Я: Ага, понял. Так что же тебя заставило разработать eclim? Если программируешь на Java, то у тебя полно чудесных IDE.
Эрик: В школе (судя по всему, имеется в виду "высшая школа". -- примечание автора), когда я проходил курс по структурам данных с применением С++, все наши лабораторные работы должны были компилироваться и запускаться на Solaris. Поэтому я пользовался vi для всего моего кода. После того, как я достаточно "вьехал" в vi, заметил, что стал гораздо более продуктивным.
Я: Но Java... Для неё же в самом деле нужны IDE для управления проектами, контекстно-зависимого автодополнения и рефакторинга...
Эрик: Потом я перешел на Java и пользовался Borland-ом какое-то время еще в школе, затем попробовал Forte (позже переименованный в NetBeans), т.к. мне нужна была бесплатная IDE. Еще через несколько лет я открыл для себя GVim (vi + подсветка синтаксиса и прочие "плюшки") и сразу же стал им пользоваться. Как ты заметил, GVim-у не хватает многих возможностей IDE.
Я: Так что ж ты не воспользовался Eclipse или NetBeans?
Эрик: Потому что у них слишком сложный интерфейс текстового редактора по сравнению с GVim. А я тратил намного больше времени на набор текста, чем на использование инструментов IDE.
Я: Какие особенности IDE тебя раздражали больше всего?
Эрик: У них нету режимов (имеются в виду режимы редактора vim: режим вставки, навигации, визуальный режим и т.д. -- примечание автора). Сегодня почти у всех программ есть специальные режимы (vim, vimperator, irsii, readline + много инструментов командной строки). Я обнаружил, что когда убираю пальцы с home row (строка на клавиатуре, где находятся клавиши asdfghjkl. -- примечание автора) сразу же падает моя продуктивность.
Я: Ага, ОК. Значит, были две основные причины, из-за которых те не пользовался IDE:
1) IDE не позволяет управлять курсором из home row;
2) отсутствие режимов, как в vim.
Кстати, примерно поэтому же и я не пользуюсь IDE. Есть еще одна причина для меня: для IDE очень сложно писать свои плагины :-)
Эрик: Да, это основные причины, по которым я предпочитаю vim. Действительно, входной порог в написание плагинов для IDE слишком высокий, особенно для Java IDE.
Я: Мои друзья, использующие GVim или Emacs, обычно также используют и IDE. Что думаешь про такой способ?
Эрик: Я предпочитаю использовать один интерфейс для разработки. Мне уже приходится переключаться между командной строкой, редактором и броузером (иногда и другими инструментами). Так что добавить еще и IDE -- это не самый лучший выбор.
Я: ОК. Тебе помогали в разработке Eclim? Как отреагировало коммьюнити на твой проект?
Эрик: Это был сольный проект. Я начал его как proof of concept и продолжил наращивать функционал. У меня было пару коллег, которые в самом начале пробовали Eclim, вот, пожалуй, и всё. Что до реакции коммьюнити... Я никогда не анонсировал Eclim и не пиарил его. Я обнаружил, что те, кому была нужна функциональность вроде Eclim, так или иначе найдут его. С годами (а я начал Eclim в 2005-м) я видел весь спектр мнений по поводу Eclim. Я никогда не ожидал, что он подойдет каждому, так что несколько негативных комментариев не сильно меня удивили. В конце концов, я написал Eclim для себя, а то, что он пригодился другим людям, -- просто дополнительный бонус.
Я: А ты всё еще пользуешься Eclim-ом? Ну просто если ты кодишь на python, то зачем тебе Eclim и Java?
Эрик: Я добавил в Eclim поддержку разных языков, включая python, так что я использую Eclim каждый день. И, конечно же, я прдолжаю разрабатывать Eclim :-)
Я: О, это отличная новость! Потому что я нахожу возможности Eclim фантастическими: контекстно-зависимое дополнение кода, подсветка ошибок компиляции и т.д.
Эрик: Всегда приятно слышать, что Eclim нравится людям! :-)
Я: Ну а каких возможностей в Eclim не хватает? Что бы ты хотел туда добавить?
Эрик: У меня огромный todo list, в котором пунктов намного больше, чем я когда-либо смогу выполнить. Я получаю от пользователей разные запросы и стараюсь приоритезировать их в зависимости от того, насколько запрошенная функциональнасть нужна мне или другим людям.
Я: Можшь назвать три главных по приоритету пункта?
Эрик: Исправление ошибок почти всегда выходит на первое место, так что главный приоритет теперь -- несколько ошибок из создания проектов в CDT (C/C++). Второй приоритет -- несколько фич (сигнатуры методов и классов + документация для запрошенного элемента (как во всплывающей подсказке Eclipse), перенос поддержки python из rope (библиотека для python) в pydev. Остальное -- это множество мелких исправлений и дополнений. Думаю, нужно еще упомянуть то, что я заканчиваю мои scala- и android- ветки.
Я: что было самым сложным для тебя в Eclim? Тебе кто-нибудь помогал впоследствии или только слвлаи запросы на функциональность?
Эрик: Самое сложное для меня -- это Eclipse API (там полно недокументированной функциональности) и поиск способов хоть как-то заставить этот API работать.
Я: Да, там отстойный API. Я тоже пробовал в нем разобраться, но быстро оставил эту затею. Так что насчет коммьюнити? Тебе кто-нибудь помогает сейчас?
Эрик: Eclim хотсится на github, но до сих пор никто не выступил как крупный контрибютер. Так что сейчас я до сих пор единственный разработчик с правами коммита. У меня было несколько pull request-ов или патчей, но они довольно мелкие. Думаю, самое сложное для других программистов -- это Eclipse API. Сообщения об ошибках и активность в e-mail рассылке, также, как и обсуждения в IRC носит эпизодический характер.
Я: ОК, понял. Я уже почти закончил свой список вопросов, остался последний.
Эрик:...так что, конечно, есть коммьюнити пользователей Eclim, но разрабатываю Eclim в основном я сам.
Давай, жги :-)
Я: Единственная причина, по которой я перешел с Vim на Emacs, был VimScript. Emacs Lisp показался мне гораздо мощнее. Что скажешь об этом?
Эрик: Я никогда не пользовался elisp-ом, так что не могу ничего сказать о нем. Думаю, VimScript с версии 7.0 (когда в него добавили списки, словари и прочие фишки) вполне годится для использования, хотя он все еще далек от идеала. Думаю, наибольшая проблема в том, что я и другие пытаются писать сложные плагины и встречаются с тем фактом, что vim -- однопоточный, и не может нормально общаться с долго работающими процессами (netbeans интерфейс к vim не решает этой проблемы). Слыхал, что у с этим Emacs дела намного лучше.
Я: ОК, спасибо за твое время и особенно за Eclim! Мне действительно нравится Eclim, и это мой главный инструмент в работе!
Эрик: Спасибо, я очень рад слышать, что Eclim делает жизнь проще.

Оригинал:

<dbushenko> could you please tell a bit about you? How old are your, where do you live and what do you do?
<ervandew> I'm 33, a software engineer living and working in Los Angeles working primary on web based platforms. Out of school I was using Java using the typical JEE stack, etc. but about 5 years ago I switched to python, primarily django based.
I'm pretty open language wise, but I haven't dabbled much in ruby yet.
<dbushenko> aha, I see
but what did make you to start eclim?
bcs if you program in java
you have many wonderfull IDEs
<ervandew> While in school I was taking a data structures class using c++ where all our submissions had to compile and run on the a solaris box, so I picked up vi to write all my code.
After getting past the learning curve I quickly found myself more productive.
<dbushenko> but java... it really needs some IDEs for better project management, context-sensitive autocompletion and refactoring...
<ervandew> I later moved to Java and used Borland for a bit while still in school and switch to Forte (later renamed to NetBeans) since I wanted a free IDE.
<ervandew> A few years later I discovered gvim (vi + syntax highlighting and other goodies) and switch almost immediately.
<ervandew> As you mentioned though gvim was missing all the IDE goodies.
<dbushenko> and why didn't you just switch to eclipse or netbeans?
<ervandew> Because their editing interface was some cumbersome when compared to gvim, and I spent way more time typing than using the IDE's additional tools
*so cumbersome
<dbushenko> which features of the IDE's editor did you hate most?
<ervandew> That they are all modeless. Today almost every program I use has modes (vim, vimperator, irssi, readline + many command line tools)
I find taking my finger off the home row results in an immediate drop in productivity.
<dbushenko> aha, ok...
so there were two major reasons:
1) IDEs didn't allow to browse with the home row
2) absence of vim-modes
right?
btw, this is mostly the same reasons for me, but I have one more: IDEs really hard to extend with your own plugins :-)
<ervandew> yeah those are the core reasons I prefer editing via vim
true, extending an IDE typically has a higher barrier to entry, especially java IDEs
<dbushenko> My friends who also use gvim or Emacs usually try to use both: an editor and an IDE. what do you think about that way?
<ervandew> I prefer to use one interface for my coding. I already have to switch between a terminal, editor, and browser (sometimes other things) so adding an IDE to the mix is not ideal for me.
<dbushenko> ok, next:
did anyone help you with eclim when you've started it? and what was the communitiy's response to it?
<ervandew> It was a solo project. It started as a proof of concept and grew from there. I had a couple of coworkers that were early adopters but that was about it.
As far as the communities response...
I never went out and announced eclim or marketed in any way. I figured if people wanted something like it, they would find it and I'd let word get out organically. Over the years (I started writing eclim in 2005) I seen various response all along the spectrum. I never expected eclim to be for everybody so the occasional negative comment doesn't surprise me. Ultimately I wrote eclim for myself, helping other people is just an added bonus.
<dbushenko> and do you still use eclim for your needs? I mean, if you code mostly python, do you still need eclim and java?
<ervandew> I've added support for various languages into eclim including python so I still use it every day and I of course use eclim to continue my work on eclim :)
<dbushenko> oh, this is great news! :-)
bcs I've found that eclim is fantastic:
it has context-sensiteve autocompletion, compilation errors, etc.
<ervandew> It's always good to hear that people find it useful :)
<dbushenko> but what features does it lack? what do you think you would like to add to it soon?
<ervandew> I have a huge todo list with far more on it that I could ever actually get done. I get various requests from users here and there and I try to prioritize features based on whether I'd use it or if other people would find it useful.
<dbushenko> can you mention 3 highest priorites from your todo list?
<ervandew> Bugs almost always come first, so the highest priority are a couple CDT (c/c++) project creation bugs, but features wise: method/class signature + docs for the requested element (like a hover type info), moving python support from rope (python library) to pydev. Those are two big ones. The rest of my high priority stuff is a lot of small things to help solidify eclim and work out kinks on other platforms or configurations.
I suppose I should also mention finishing up my scala and android branches
<dbushenko> what was the most difficult to you while developing eclim? do people commit to the project or just send you bug reports and features request?
<ervandew> the most difficult thing was wrapping my head around the eclipse APIs (they don't document most of the parts eclim has to hook into) and finding ways to get some features to work in a headless environment since a lot of things are closely tied to the UI
<dbushenko> yeah, it's a crappy API! I tried to used and gave it up completely!
so what about community? is it involved into the project now?
<ervandew> Eclim is hosted on github and no one has stepped up as a large contributor so I'm currently the only one with commit rights to the repos. I get the occasional pull request or patch, but they tend to be few and far between. I think the biggest barrier being those eclipse APIs. Issue reports and email activity is bursty, as is activity on the eclim IRC channel.
<dbushenko> ok, I see...
and I've already finished my list of questions. the last one:
<ervandew> So there is definitely a community of users, but on the development end it's primarily just me
fire away
<dbushenko> The only reason to me when I switched from gvim to Emacs was VimScript. Emacs Lisp seemed much more powerfull to me. what is your attitude to Emacs Lisp comparing to VimScript?
<ervandew> I haven't used elisp so I can't comment on that. I think vim script post 7.0 (where lists, dictionaries, and other features were introduced) is livable but far from ideal. I think the biggest issue that myself and others attempting to write complex plugins face is the fact that vim is single threaded and has no good way to interact with long running processes (the netbeans interface in vim doesn't solve that problem).
I've heard that emacs shines in that area
<dbushenko> Ok. Thanks for your time and especially for Eclim! I really love Eclim, it's my major tool for my job!
<ervandew> My pleasure, and again I'm happy to hear eclim has helped make life easier :)

Впечатление о встрече разработчиков Scala #7

2011-12-11T15:07:00.001+03:00

Вчера, в субботу, выступал с докладом на 7-й встрече любителей функционального программирования. Тема конференции -- "Инструменты, упрощающие разработку программ".
К организации встречи подошли довольно серьзено. Во-первых, мне удалось уговорить выступить с докладом Алекса Отта. Тема его доклада -- "Emacs -- универсальный комбайн". Было очень интересно послушать про Emacs от настоящего мастера ФП и знатока Emacs.
Во-вторых, мы с Алексом специально для встречи написали небольшое пособие по программированию Emacs. Компания Epam помогла нам его опубликовать и даже предоставила дизайнера, который красиво оформил обложку и текст. Спасибо тебе, Руслан!

На фотке -- я и Алекс Отт презентуем пособие "Программирование Emacs для редактирования и рефакторинга кода". Пособие, кстати, раздали бесплатно всем желающим. И много еще осталось. У меня на руках еще 4 штуки лишних, могу подарить.
Электронную версию пособия можно взять здесь.
Свой доклад я посвятил программированию Emacs под свои задачи. Моё личное мнение: Emacs надерет задницу всем текстовым редакторам и IDE только если вы сами будете его программировать для себя. В своем докладе я показал, как разрабатывать скрипты на Emacs Lisp и как автоматизировать нудную рутинную работу. Видео моего выступления можно посмотреть здесь.
Вопросов по программированию Emacs было много, так что мне явно удалось заинтересовать ребят этим текстовым редактором. Спасибо Василию Ременюку за организацию встречи Scala #7 и возможность выступить с докладом о Emacs!

Scala, подвинься!

2011-12-01T22:33:00.000+03:00

Буквально на днях зарелизилась офигеннейшая библиотека Avout. Авторы библиотеки -- небезызвестная clojure/core. Эта маленькая конторка, основанная Ричем Хикки, занимается исключительно разработкой и поддержкой кложуры. Так что библиотека Avout -- самая что ни на есть true-реализация Distributed Software Transactional Memory!
Вообще-то стоило бы привести здесь примеры исходников... Но именно для avout я этого делать не буду. Дело в том, что он настолько прост в освоении, что диву даёшься! Еще ни разу не встречал RPC или MQ, освоить которые было бы настолько легко. Лично у меня всё завелось и заработало спустя 10 минут после того, как я открыл Emacs. Одним словом, впечатления от avout -- самые положительные!

Типы в языках программирования

2011-11-30T13:35:00.001+03:00

Недавно Алекс Отт делал объяву о том, что вышла книга "Типы в языках программирования". Доставить в Минск её было непросто: на ozon.ru она стоит в районе 2000, цены в магазинах -- 1100-1300 (в росс. рублях) плюс доставка -- короче сложно, долго, дорого. Я сделал запрос на oz.by, и через два дня они дали ответ: книгу привезут в Минск! Заказать её можно здесь за 482574 бел.руб., что в долларах составляет примерно 56$ или примерно 1756 росс. руб.

Scala.by #7 (updated)

2011-11-22T12:39:00.001+03:00

10-го декабря выступлю с докладом на встрече любителей функциональщины (scala.by). Рассказывать буду о том, как запрограммировать Emacs под себя. Главная тема доклада: автоматизация кастомного рефакторинга.
Участников встречи ждет небольшой подарок: пособие по программированию Emacs, которое мы вместе с Алексом Оттом готовим специально для встречи.

Текст пособия уже практически готов и завтра отправится к дизайнерам на оформление.

Предварительная версия содержания:

1. Введение (зачем программировать Emacs).

2. Коротко о GNU/Emacs (где хранятся файлы настроек, как изменить значения глобальных переменных, как выполнять команды, как получить справку по функциям и переменным, что такое буфер, какие режимы бывают и т.д.)

3. Основы Emacs Lisp (что такое префиксная нотация, формы, как писать программы на Emacs Lisp, как их компилировать и выполнять, какие бывают типы данных, что такое символы и как они отличаются от переменных, как объявлять функции и какие бывают управляющие конструкции; манипуляция списками; ввод-вывод)

4. Примеры elisp-скриптов (автоматизированный импорт Java-класса в программе на Clojure; генерация геттеров/сеттеров в Java-классе; автоматическая генерация и инициализация полей Java-класса в Android-приложении; преобразование html-файла в haml-формат; автоматическое создание конструктора для неизменяемых Java-объектов)

5. Справочник часто употребимых функций (перемещение курсора, получение позиции, управление регионом, поиск текста, работа с буфером, ввод данных с подсказкой)

6. Пакеты для разработчика (краткое перечисление с описанием наиболее полезных расширений Emacs)

7. Литература (а также -- полезные
ссылки)

Генератор кода

2011-10-20T16:40:00.004+03:00

Работая java-программистом остро ощущаю нехватку средств метапрограммирования. Макросов не хватает катастрофически, а средства интроспекции не позволяют добиться той же гибкости и производительности. На днях, разрабатывая очередную формочку для android-приложения, окончательно ощутил себя обезьяной. Не выдержал и сделал маленький генератор кода для быстрого построения простых DSL-ов.

Пример приведу из Java/Swing. Чтобы реализовать MVC для нужно иметь три класса (и, соответственно, три файла для них); класс-контроллер должен их всех проинициализировать и подписать View на события от Model. В Model нужно держать набор данных и аксессоров к ним. В View, помимо самих компонентов, нужно иметь еще и метод, обновляющий их содержимое, когда изменяется модель. Вопрос: что из перечисленного действительно должен делать программист? Если формочка одна – то можно все и вручную сделать, но если формочек 10-20, то конкретно задалбывает писать все это вручную. Поэтому я сделал вот такой генератор кода.

Вот, что нам известно по ТЗ об очередной формочке, для которой делаем MVC. Форма состоит из двух полей (Text и Number), одноименные данные содержатся в модели. Их же из модели и нужно вытягивать, если она изменяется.

Генерим код следующим образом (файл scripts/mvc.clj):

(def *controller* "MyController")

(def *view* "MyView")

(def *model* "MyModel")

(def *view-components* [{:name "Text", :type "JTextField", :sync true}

{:name "Number", :type "JTextField", :sync true}])

(def *model-data* [{:name "Text", :type "String"}

{:name "Number", :type "int"}])

(defn process-view []

(eval-template "templates/View.soy"

{:vname *view*

:cname *controller*

:mname *model*

:components *view-components*}))

(defn process-controller []

(eval-template "templates/Controller.soy"

{:vname *view*

:cname *controller*

:mname *model*}))

(defn process-model []

(eval-template "templates/Model.soy"

{:name "MyModel"

:data *model-data*}))

(write-text (process-view) "MyView.java")

(write-text (process-controller) "MyController.java")

(write-text (process-model) "MyModel.java")

Шаблоны приводить не буду, они есть в проекте генератора. Сгенерированный файл MyView.clj:

package swingtest;

import java.awt.event.ActionEvent;

import java.awt.event.ActionListener;

import java.util.Observable;

import java.util.Observer;

import javax.swing.Box;

import javax.swing.JButton;

import javax.swing.JFrame;

import javax.swing.JTextField;

public class MyView extends JFrame implements Observer{

private MyController _Controller;

private JTextField _Text;

private JTextField _Number;

MyView(MyController controller) {

_Controller = controller;

initLayout();

}

protected void initLayout() {

setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

setBounds(100, 100, 200, 100);

Box box = Box.createVerticalBox();

// Initialize your class here...

}

@Override

public void update(Observable o, Object arg) {

MyModel model = (MyModel)o;

_Text.setText(String.valueOf(model.getText()));

_Number.setText(String.valueOf(model.getNumber()));

}

Как видно из кода, сгенерен класс MyView, который содержит указанные поля и даже умеет автоматически обновлять их значения, когда меняется модель.

Класс модели:

import java.util.Observable;

public class MyModel extends Observable {

public void updateModel() {

setChanged();

notifyObservers();

clearChanged();

}

/* Accessors */

private String _Text;

private int _Number;

public String getText(){

return Text;

}

public void setText(String value){

_Text = value;

}

public int getNumber(){

return Number;

}

public void setNumber(int value){

_Number = value;

}

Модель не только содержит указанные данные, но также и готовые аксессоры к ним.

Clojure Killer App (updated)

2011-10-11T09:07:00.005+03:00

Для каждого языка программирования обязательно нужна хотя бы одна технология, которая сделает его (язык) популярным. Для Java -- это J2EE, для Ruby -- Ruby on Rails, для Python -- Django. Все это так или иначе связано с вебом. Поэтому, когда появился Clojure, многие ждали, что появится и качественный фреймворк для разработки сайтов на Clojure. Однако, сегодняшний уровень развития web-технологий для Clojure пока что не производит впечатления. Может быть потому, что Clojure предназначен быть номером один в несколько других областях?
19 сентября Nathanmarz открыл исходники проекта Storm, проекта, используемого в Twitter для анализа потоков твитов. Storm -- детище Backtype, недавно купленной Twitter-ом. У Backtype есть еще несколько открытых проектов, среди которых -- Cacalog (Clojure-обертка над Hadoop) и ElephantDB.
И Hadoop, и Storm -- технологии, позволяющие легко параллелить вычисления на кластере. Главное отличие между ними в том, что Hadoop выполняет конечные map/reduce задания, в то время, как Storm способен обрабатывать бесконечные потоки данных. Hadoop -- это технология пакетной обработки данных, а Storm -- обработки в real-time.
Storm почти целиком написан на Clojure. 98% функционала Storm -- это Clojure. Правда, если посчитать процент кода на Clojure и процент кода на других языках -- то здесь Clojure займет около 50%. Остальной код -- это привязки к прочим языка программирования, таким как Java и Python.
У Storm-а несколько своеобразная терминология. Минимальными структурными единицами проекта на Storm являются источники (spout) и фильтры (bolts). Термин bolt сложно перевести на русский язык более-менее правильно, но его суть в том, что bolt преобразовывает поток данных из источника в другой поток данных. Так что воспользуемся значением глагола to bolt -- просеивать через сито. Хотя как знать, может Nathanmarz имел в виду именно фонтан (spout) и молния (bolt) -- это я пока что не успел выяснить.
Источники и фильтры объединяются в топологию, про которую подробнее стоит почитать здесь.
Ниже -- пример очень простого приложения на Storm.

(ns storm-test.core
  (:import [backtype.storm StormSubmitter LocalCluster])
  (:use [backtype.storm clojure config])
  (:gen-class))

(defspout number-spout ["number"]
  [conf context collector]
    (spout
     (nextTuple []
                (Thread/sleep 100)
                (emit-spout! collector [17]))
     (ack [id])))

(defbolt neg-bolt ["neg"] [tuple collector]
  (let [result (- (.getInteger tuple 0))]
    (emit-bolt! collector [result] :anchor tuple :p 2)
    (ack! collector tuple)))

(defn mk-topology []
  (topology
   {1 (spout-spec number-spout)}
   {2 (bolt-spec {1 :shuffle} neg-bolt)}))

(defn run-local! []
  (let [cluster (LocalCluster.)]
    (.submitTopology cluster "test" {TOPOLOGY-DEBUG true} (mk-topology))
    (Thread/sleep 1000)
    (.shutdown cluster)))

Функция run-local! создает фиктивный кластер на одном компьютере, позволяющий просто запустить программу локально. На этот кластер подается топология, созданная функцией mk-topology.
В функции mk-topology вызывается topology с двумя параметрами: словарем источников и словарем фильтров.
Запись {1 (spout-spec number-spout)} означет, что создается spout с айдишником 1 при помощи функции number-spout.
Аналогично, запись{2 (bolt-spec {1 :shuffle} neg-bolt)} означает, что создается bolt с айдишником 2 при помощи функции neg-bolt, будет получать данные из источника 1.
Функция number-spout создает spout, который 10 раз в секунду способен выдать вектор с одним единственным данным. Предполагается, что данные spout должен получать из внешних источников, например, очередей сообщений, таких как Kestrel. Здесь же для наглядности я просто передаю число 17.
Функция neg-bolt получает данные из number-spout и отдает их же, но со знаком "минус". Параметр tuple -- это объект класса Tupple, умеющего извлекать типизированные данные из внутреннего массива.
Файл проекта project.clj выглядит так:

(defproject storm-test "1.0.0-SNAPSHOT"
  :description "My first Storm project"
  :aot :all
  :dependencies [[org.clojure/clojure "1.2.1"]
                 [org.clojure/clojure-contrib "1.2.0"]]
  :dev-dependencies [[storm "0.5.3"]])

Запускать проект нужно через lein repl следующим образом:

> (use 'storm-test.core)
> (run-local!)

Короче, думаю, час Clojure настал.

Updation: Выяснил у Nathanmarz-а насчет терминов. Вот что он пишет:
"Spout" is meant to mean "source of streams", like how a water spout
is a source of a stream of water.
"Bolt" is meant to refer to lightning, as in a "storm" is composed of
"lightning bolts".

Таким образом, думаю, стоит переводить термины следующим образом:
spout -- источник
bolt -- молния.

Древний артефакт

2011-10-05T12:33:00.000+03:00

На днях мне попался в руки древний артефакт. Это потрясающая вещь неизвестного (почти) происхождения и предназначения. Я натурально чувствовал себя археологом, когда запускал эту штуку. Думаю, Шлиман испытывал похожие ощущения, когда раскапывал Трою...
Методом проб и ошибок удалось выяснить про артефакт следующее:
1. Это имплементация Common Lisp'а, не исключающая своего внеземного происхождения.
2. Работает он исключительно на платформе другого лиспа, что объясняет странные изображения Уробороса на артефакте.
3. Результатом выполненения lisp-программы является java-код, вполне осмысленный и читабельный.
4. Расшифровка сопровождающих артефакт манускриптов показала наличие прозрачной интеграции с существующим java-кодом.

Из личных впечатлений. Если артефакт покажет свою стабильность, то, вполне возможно, это тот самый Святой Грааль, который я уже давно ищу. Ведь работать хочется на лиспе, а приходится на java...

Элитные языки программирования

2011-10-03T13:22:00.003+03:00

На этот пост меня подвигли рассуждения Майкла Фогуса (автора "The Joy of Clojure") о том, что такое "программерская элита".
Фогус очень разумно объясняет, что не язык программирования является признаком "элитности" программиста. Даже Java может казаться сложной и непонятной тем, кто ее не знает. И даже Haskell будет простым и удобным тем, кто разобрался с этим языком.
Более того, действительно крутые программисты, с которыми Фогусу довелось иметь дело, работали даже с таким позорным убожеством, как С++, и тем не менее умудрялись быть очень-очень продуктивными.
Элитными могут быть, пожалуй, только программерские задачи, решить которые может лишь очень малый процент программистов. Т.е. не мега-навыки делают программиста "элитой", а, в первую очередь, крайне сложные проблемы, которые этот программист решает. Само собой, для решения сложных задач нужно иметь уровень профессионализма намного выше среднего, а также подходящие инструменты.
Выбор языка программирования для решения нетривиальных задач -- это уже следствие сложности самих задач. Язык программирования тогда "подходит" для задачи, когда упрощает ее решение, а не тогда, когда конкретный программист знает язык лучше или любит его больше. Clojure -- один из таких языков. Его "функциональность", макросы, гомоиконный синтаксис, STM, REPL, Swank -- все это предназначено для упрощения решения именно сложных задач.
Впринципе, согласен с тем, что написал Фогус. Clojure не просто располагает к экспериментированию, а прямо навязывает такой "экспериментаторский" стиль разработки. Вспомните, как нас учили программировать в школе и универе? Задачи часто решались на бумажке, нередко рисовали блок-схемы алгоритмов. Везде, где я работал, любили UML и много "планировали" перед тем, как приступить к кодированию. В Clojure -- все наоборот. Думать заранее, конечно, тоже нужно, но конспектируется "планируемое" решение не в блок-схемах или псевдокоде, а прямо на Clojure.
Т.е. вначале может и возьмешь бумажку с ручкой, но уже через минуту думаешь: "Какого чёрта?", открываешь Emacs, Slime REPL и пробуешь все уже там. Заработало? Сохраняешь в файл с исходником. Не заработало? Пробуешь дальше, не перезагружая программу. Все вычисленные данные, все переменные -- все остается; прямо в работающей программе можно переопределить любые функции и значения. Создается ощущение, что попал не просто в debug-режим, а будто только в таком режиме и работаешь.
На днях я экспериментировал с алогритмом Support Vector Machine, хотел научить классификатор по набору прилагательных от личать хорошие отзывы от плохих. С ресурса kinopark.by скачал все комментарии ко всем фильмам и рассортировал на два кластера: положительные отзывы и отрицательные (суммарно получилось окло 18Мб чистого текста). Выбрал все прилагательные (без окончаний) из каждого комментария; каждый комментарий закодировал дескриптором, содержащим 1 или 0 для каждого прилагательного из всего множества. Получился вектор размерностью около 10000. Вот такие-то вектора и скармливал классификатору на обучение.
Все это я делал только исключительно на Clojure. Все это, включая загрузку и разбор страниц с комментариями, заняло около 300 строк кода. За все время мне ни разу не потребовался дебаггер, и даже в голову не пришло писать unit-тесты (зачем, ведь функция каждый раз "пробуется" в REPL-е перед попаданием в исходник). И я не могу себе представить инструмента, более удобного для таких задач, чем Clojure.

Использованные библиотеки:
1.clj-http;
2.clj-tagsoup;
3.libsvm.

Генерация Html в стиле Clojure

2011-09-22T23:40:00.000+03:00

Недавно прочел очень интересный ~~срач~~ спор о том, как вообще true-программеры генерят html. Я даже не ожидал, что могу не знать такого интересного способа, хотя он лежит буквально на виду.
Основные тезисы дискуссии ниже (оппонента так затроллили, что он от стыда удалил все свои комменты, и теперь там по сути одна гневная проповедь weavejester'a).

1. Html и css -- дизайнерам, код -- кодерам. И смотри не перепутай, Кутузау!
Weavejester: "The problem with using HTML templating languages is that they quickly become impractical as the complexity of the page increases. Maintaining a file that's a mishmash of HTML from a designer and code from a developer is, in my experience, far more trouble than it's worth."

2. Html только для контента, весь look-n-feel делает CSS.
Weavejester: "Secondly, I'm of the opinion that if the presentation of your HTML page cannot be easily changed through CSS alone, then your HTML is probably not well-designed. Rather than trying to construct HTML purely based around a particular presentation layout, perhaps a better approach would be to construct the HTML independent of the presentation, and then to iteratively tweak this purely semantic structure into something that can be easily altered by CSS into the desired design.
...
That's not to say all our HTML is perfectly formed straight off the bat. Far from it. But when we find a part of our design can't easily be altered by CSS alone, we try to fix the HTML so that it can be. Eventually one gets to the point where the HTML rarely needs to be altered, except when new content or features are added."

3. Дизайнер делает только layout. Весь контент, все внутренности html-а делает программист.
Weavejester: "I don't disagree that the UI can change; I'm just of the opinion that written correctly, you can (more or less) isolate the content from the presentation. If anything, it's easier to change a set of well defined functions, or a file of CSS, than it is to alter a clunky mashup of HTML and inline code."
vagif: "...designers make changes to html as opposed to developers by saying that they are familiar with html and have the necessary tools.
But this is awfully wrong. When you change html it is either look'n'feel (colors,background,fonts,layout,icons,banners,etc) or structural change (add / remove some elements like buttons, dropdowns, edit boxes etc.)
In first case it is never continuous work. You usually decide and finish look'n'feel as one unit of work, and then just utilize the result of designer's work by wrapping it in libraries/templates/includes so developers would not waste their time to deal with those settings in each particular page.
Structural change on the other hand is where the actual bulk of changes happens. And it is NEVER a designer's work, but always a developer's. SO i was very surprised when you told that your designers often change things "in a middle". What the heck do they change ? Color schemes ? new banners every week ? you could not decide upon the layout of your web site, so you change it that often ?"

4. True-way: дизайнер делает html-страницу, программер преобразовывает ее в набор функций, генерирующих этот самый html. После этого программер может редактировать полученный результат как код, а не как html.
Weavejester: "As a developer, I'd much rather the designer send me a file of HTML I can convert into a concise set of functions."

То есть я в корне неверно воспринимал hiccup! Этот движок темплейтов не используется для генерации страницы вручную. Дизайнерское поделие переводится в формат, который воспринимает hiccup, а затем программер может его редактировать как код, а не как html! Вот уж действительно true-разделение логики и представления!

Пример:

(ns webtest.core
  (:require [pl.danieljanus.tagsoup :as ts]
            [hiccup.core :as h]
            [clojure.contrib.duck-streams :as io]))

(def data (slurp "data/data.html"))
(def parsed (ts/parse-string data))
(def generated (h/html parsed))

(io/spit "data/output.html" generated)

В файле проекта должно быть:

(defproject webtest "1.0.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.2.1"]
                 [org.clojure/clojure-contrib "1.2.0"]
                 [clj-tagsoup "0.2.6"]
                 [hiccup "0.3.6"]])

Надо сказать, что хотя результат незначительно отличался по размеру, в броузере сгенерированная html-страница выглядела абсолютно идентичной оригиналу.

Впечатления о встрече разработчиков Scala

2011-09-12T10:58:00.001+03:00

В субботу выступал на небольшой встрече разработчиков Scala. Если в общем и целом: все было здорово, мне очень понравилось. Отдельное спасибо Василию Ременюку за классную организацию встречи. Было все, что нужно: удобное помещение, проектор, ноутбук и даже автомат с бесплатным кофе.

Аудитория собралась образованная. После доклада о возможностях Lisp-а меня еще долго держали вопросами, причем не только грамотными, но и очень каверзными.

Правда, как ни странно, хотя я и попытался разжевать во всех подробностях, что такое лисп и как он используется, все равно в разных вариациях услышал вопрос: "Ну нафиг нам твой Lisp со всеми этими скобочками? Есть ведь JetBrains MPS, Xtext, antlr, бла-бла-бла..."

У меня встречный вопрос: а что вы чаще используете, паттерны или MPS? В Lisp-е я не задумываясь, влегкую, введу новые операторы, сделаю библиотеку паттернов и других общих архитектурных фрагментов; все будет DRY, никакого копи-пейста. И это будет все тот же самый язык, на котором написан основной код проекта.

А вы такое сможете со своей Java, C#, С++, даже с использованием этих дополнительных утилит? И даже если сможете, то почему не делаете?

Тут нет никакой загадки: любой external DSL всегда по определению сложнее в реализации и поддержке, чем аналогичный embedded. И чем сложнее DSL, тем заметнее разница в сложности реализации всей инфраструктуры external DSL (парсер, набор синтаксических правил и т.д.) и embedded DSL, для которого ничего дополнительно приделывать не нужно.

Спасибо всем присутствовавшим, мне было интересно с вами пообщаться. Надеюсь, я заинтересовал вас языком Clojure, и через какое-то время появится наша Belarussian Clojure Users Group.

Материалы моего выступления доступны здесь.

Clojure vs Scala - anecdote

2011-09-07T10:21:00.002+03:00

В связи с моим предстоящим выступлением на встрече разработчиков Scala решил ~~накинуть говна на вентилятор~~ перевести появившийся недавно Clojure use case. Оригинал появился сегодня рано утром и взят отсюда.

"Хотелось бы немного поделиться нашим опытом из World Singles...
В ноябре 2009-го мы начали разрабатывать на Scala. Нам нужен был очень длительный процесс, который публиковал бы большие тома изменений из нашей БД пользователей в виде XML-пакетов, опубликованных в кастомном поисковом движке. Отобразить пол дюжины таблиц из БД на XML было довольно сложно, и компания уже перепробовала несколько решений с разным успехом. Я предложил Scala, основываясь на производительности, конкурентности, типобезопасности и краткости (особенно учитывая, что XML -- родная структура данных в Scala).
Мы использовали публикующие демоны на Scala в продакшене больше двух лет. В основном, они работали неплохо, однако при высокой нагрузке часто выкидывали исключения Out of Memory. После длительного ковыряния в коде, мы пришли к выводу, что это происходило благодаря (по крайней мере, частично) дефолтной реализации акторов в Scala. Scala должна скоро объединиться с Akka, и, так или иначе, мы раздумывали о миграции на Akka...
Но после того, как мы начали использовать Clojure в этом году (после экспериментов с Clojure с мая этого года) выяснилось, что довольно просто реализовать Clojure-версию нашего Scala-кода.
Чтобы по-новой создать публикующего демона, потребовалось около 15-ти часов работы, после которых стали проходить все наши функциональные тесты. Теперь мы запускаем полный тест, публикующий более 300 000 профайлов за раз. Scala-код вылетает с OoM-исключением уже на 50 000 профайлов (иногда даже меньше). А Clojure-код вышел сухим из воды и спокойно работает на таких нагрузках. Теперь мы собираемся заменить наш Scala-код на Clojure-код в следующем продакшен-билде.
Другая интересная особенность заключается в том, что Scala-код занял около 1000 строк (примерно 31k символов). Аналог на Clojure занял всего 260 строк и 11.5к символов. Ни тот, ни другой исходник не содержит большого числа комментариев (кгмм... я не горжусь этим, конечно, а просто показываю, что ни в одном из исходников нету лишнего текста, мещающего сравнивать их по объему). В сравнении также не учитывается код юнит-тестов, так что мы сравниваем чистый продакшен-код. Clojure-код написан по тем же принципам, что и Scala-код, в основном с теми же самыми функциями (Scala-код был написан в функциональном стиле), с небольшим рефакторингом для извлечения helper-функций и повышения модульности и упрощения поддержки.
В результате, понятное дело, мы берем в продакшен Clojure-код и полностью отказываемся от Scala.
Слава Ричу Хикки и Сlojure/core-команде за разработку такого великолепного языка общего назначения, решающего большие задачи! Спасибо вам!"

Доклад про Clojure

2011-09-05T10:56:00.000+03:00

В эту субботу, 10.09.2011, впервые буду делать доклад по Clojure на небольшой коференции.

Тема доклада: "Предметно-ориентированные языки и Lisp как средство их построения".

Приходите, и вы узнаете:
1. Что такое предметно-ориентированные языки (Domain Specific Languages);
2. Зачем, когда и как применять DSL;
3. Что такое Lisp и зачем в нем столько скобочек;
4. За что лисперы презирают паттерны проектирования;
5. Почему почти невозможно похвастаться перед лиспером возможностями своего любимого языка программирования.

Приглашаем всех желающих!

Clojure: The Phantom Menace

2011-08-11T09:37:00.001+03:00

Еще буквально пару месяцев назад ситуация с веб-разработкой на Clojure была едва ли не плачевной. Чтобы разработать довольно простое приложение на Clojure нужно было здорово постараться, т.к. не было единого веб-фреймворка вроде того же Ruby on Rails.
Однако, оказывается, Clojure развивается просто стремительно. Не так давно появился фреймворк Noir, ориентированный на веб-разработку; недели две назад вышел ClojureScript; с месяц назад хостинг Heroku объявил о поддержке Clojure. Смесь получилась ядерная.
Во-первых, Noir -- достаточно модульная штука, которая позволяет пользоваться любимыми технологиями, Google Closure Templates, и забыть про ненавистный hiccup, используемый по-дефолту.
Во-вторых, Noir предлагает более удобный DSL для маршрутизации, по сравнению даже с Compojure.
В-третьих, это не любительская поделка, а небольшой стартап. Есть даже готовое приложение в продакшене, выполненное именно с применением Noir.
Можно также найти и вменяемое руководство по размещению приложения Noir на хостинге Heroku.
Еще недавно стала доступна библиотека Pinot, упрощающая использование ClojureScript на клиентской части. Один из очень приятных её бонусов: Ajax из коробки.
Конечно, до того же Ruby on Rails или Python Django еще далеко. Но это ничего, с такими темпами через год-другой Clojure станет очень серьезным конкурентом рубистам.

Clojure в production

2011-08-05T10:03:00.001+03:00

В последнее время наиболее интересная для меня тема -- кто, как и зачем использует Clojure в реальных проектах. Хотя это язык общего назначения, не все типы приложений пишутся на нем так же легко, как на других языках. Зато кое-какие задачи решаются значительно легче, чем на тех же Java и Ruby. Ниже -- вольный перевод поста о том, как используют Clojure в одной из платформ для сайтов знакомств.

"Я работаю на компанию знакомств по интернету. У нас была платформа, разрабатывавшаяся более десяти лет (до того, как я присоединился), и чтобы написать новую версию с нуля, мы потратили более восемнадцати месяцев. Сложность платформы такова, что конкурентное выполнение кода -- большая проблема, так что я хотел получить более чистый код и простую конкурентность -- функциональное программирование с неизменяемыми данными прекрасно для этого подходит. Изначально я предложил Scala для кое-какой низкоуровневой инфраструктуры с неизменяемыми данными и конкурентностью на акторах. Проблема Scala в том, что это типичный "compile-deploy-debug-edit" язык, поэтому разработка шла довольно медленно (быстрее, чем на java, но все же это тот же "compile, deploy, restart, test, rinse, repeat" язык); система типов Scala сложна для понимания средним программистом. В конце-концов выяснилось, что Scala не очень хорошо подходит для нашей команды, так что я решил поискать другой функциональный язык на jvm. Оказалось, что Clojure подходит идеально: он динамически типизирован, у него есть REPL для исследования, он легко вызывается из java; предлагает неизменяемые данные, безопасные в конкурентном выполнении, а также изменяемые данные в безопасном окружении (STM).
Мы переписали наш низкоуровневый управляющий код, применив Clojure, так что теперь мы могли использовать его из других языков. Затем мы разработали маленький простой псевдо-ORM на Clojure, чтобы заменить некоторые из наших библиотек и позволить прозрачно менять RDBMS на NoSQL используя простые структуры данных: словари (maps). Мы поставили наш Clojure-код на production пару недель назад, и он доказал свою гранитную стабильность (пара ошибок была, но они были в нашем коде, не в Clojure!). Мы только что добавили пул соединений (всего пара строк на Clojure).
Думаю, что со временем количество нашего кода на Clojure будет расти. До сих пор наш опыт показывает, что код на Clojure проще раз в десять, и это чистый, простой, тестируемый код, который намного легче написать и использовать повторно.
А как вы используете Clojure?"

Lisp в мэйнстриме

2011-08-03T16:25:00.001+03:00

Love5an в своем блоге поднял важную тему о применимости лиспа для повседневных задач. Главный вывод из его статьи: в лиспе мало библиотек, по сравнению с мэйнстримными языками, поэтому разрабатывать с его помощью обычные приложения сложно. Эта мысль перекликается с тем, о чем я писал в предыдущем посте, где искал идеальные задачи для лиспа.
В принципе, я абсолютно и полностью согласен с love5an'ом: используя только лисповую инфраструктуру сделать настольное или веб-приложение довольно -- задача трудоемкая.
Но не с Clojure! Оговорюсь: не используйте различные обертки над библиотеками java, используйте ифраструктуру java. Ring, Compojure, etc -- все это довольно бедные библиотеки, которые не идут ни в какое сравнение с тем же j2ee. Seasaw хоть и скрывает частично Swing, но не заменит ее полностью. Можно продолжать долго, так что если знаете java -- то просто используйте java API напрямую, Clojure это позволяет.
Если обращаетесь к java API -- не используйте Emacs, возьмите IDE. Это действительно удобнее, т.к. IDE умеет делать интеллектуальное автодополнение кода. Самое лучшее, что я видел для Clojure, это Idea+LaClojure. Community-версия Idea бесплатна, так что скачать эту IDE легко.

Конечно, учитывая динамичность Clojure, интеллектуальное автодополнение не настолько точное, как для той же java, но, тем не менее, тоже значительно облегчает работу. По крайней мере не нужно постоянно обращаться к документации за элементарными вещами.
Чисто для эксперимента решил попробовать написать UI для простого настольного приложения.

С применением LaClojure+Idea это оказалось почти так же просто, как и на обычной java.
Таким образом, Clojure совмещает простоту и практичность Java с мощью и выразительностью Lisp-а.