[die_sekte]

Well, Clojure has Compojure & Ring (like Sinatra & Rack on Ruby). Pretty well made, but without batteries, and the documentation sucks massively (I've resorted to reading the source). Also, pretty much everything is still in beta and APIs change frequently.

For CL, Scheme, Arc, ..., I have no idea.

[brehaut]

I recently rebuilt my site[1] in Clojure. Ring at the bottom layer (basically a given). Beyond that I'm using Moustache[2] for routing, Enlive[3] for templating and Clutch[3] to talk to CouchDB. I had previously tried with Compojure and Hiccup.

The hardest parts were learning enlive and moustache. Enlive is incredibly powerful and very clever, but can be a bit overwhelming for clojure noobs. You definitely want to check out David Nolen's tutorial[5] for it. Aside from that, #clojure and the ring google group are full of wisdom.

Deployment wise, I build the site with a basic leiningen[6] uberjar and run it from an ssh, background it and disown it. yeah, thats terrible, but im lazy and nobody visits my site anyhow ;) Caveat here: Clojure 1.2 has a small bug with interned keywords[7] that will knock my site over in a couple of days if i forget to start it up with the default JVM profile. the -server profile fixes the trigger issues

Aside from that, I have an nginx gateway server that handles serving my media, nowww redirection and proxies all dynamic requests through to the jvm. the site itself hosts a jetty HTTP server via ring to handle all the requests.

The 'hardest' part of getting started with clojure vs say Python+Django or Ruby+Rails is that there is a lack of 'get you going' magic / tools like scaffolds or djangos admin. Once you get past that though, it is a very enjoyable platform inspite of the API changes.

[1]: http://brehaut.net

[2]: http://github.com/cgrand/moustache

[3]: http://github.com/cgrand/enlive

[4]: http://github.com/ashafa/clutch

[5]: http://github.com/swannodette/enlive-tutorial/

[6]: http://github.com/technomancy/leiningen

[7]: http://www.assembla.com/spaces/clojure/tickets/444?comment=9...

[ynniv]

run it from an ssh, background it and disown it

Ack! GNU screen will change your life.

[ http://www.emacswiki.org/emacs/GnuScreen ]

[nakkiel]

You mean SAVE his life.

[sandGorgon]

how do you handle schema changes ?

Another clojure web framework - Conjure - has rails like migrations.

What do you do ?

[brehaut]

First up, i'm using CouchDB, so my data is pretty fluid. Everything is organized as a set of 'fragments' which have a variety shapes; its duck-typed data basically. I havent looked at clojure's SQL stuff at all so i cant answer there.

Working with these fragments is real simple. Clutch deserializes the JSON from various couch views into native clojure data structures (maps, vecs, etc). From there i just use multimethods[1] to work out how to handle each fragment at various points (url generation, various aspects of the templating etc). I should note that cgrand created a great little macro for me to make working with enlive and multis easier, http://gist.github.com/432752

The hardest part about migrating the nominal schema is changing the JS for the views. Clutch does support running a clojure view server for couch which i think would actually alleviate a lot of my pain points but I wasn't on the ball when i got started. I store all my views in little JS files in the project and have some shamefully rough clojure scripts to update the views in the DB.

Migrating existing data (which i've only had to do once) is a simple case of writing a map (and or filter) function and running it over all the content and doing a bulk update with couch.

I havent had to do much migration though because i largely ported over my established python/django project.

hopefully that answers your question?

[1]: http://clojure.org/multimethods

[sandGorgon]

well it was incredibly informative (thanks!), but you do not have the problem of schema changes.

In a traditional DB, one needs to manage addition and deletion of columns, during the development of a project. And one needs to be able to synchronize these database schema changes with the rest of the team. And it is nice to have these as incremental (yes there is the obvious waste of creating a column in one migration and dropping it in the other) Migrations also allow you to do stuff like add indexes etc to your tables and is not just a one-to-one mapping of your objects to the DB.

Which is why migrations (Rails and Django's South) are so extremely helpful during development.

One of the things I that was for something like Linq (Scala has something called squeryl) and you could have your database created from your objects - not optimal, but enough to start with.

FWIW, ease of managing incremental schema is why Drupal (using drush and "Drupal Features" ) is one of the better PHP frameworks.

[aguynamedben]

all of this sounds fine and dandy, but is http://brehaut.net web scale?

[brehaut]

Nah, id need mongo or dev null for that. i havent got to those yet