A Rails like framework for Clojure.(github.com)
github.com
A Rails like framework for Clojure.
http://github.com/macourtney/Conjure
5 comments
All these Rails clones! They think they can just ape Rails' idioms and then they'll have the power of Ruby's metaprogramming at their disposal and -- oh, wait.
rails is a pretty mature framework these days, and it's got tons of plugins that are actually easy to use. It's a pretty steep road to get something up to those standards. When I need something that has everything already neatly solved and ready for cranking out stuff fast -- I always chose rails.
I'm currently trying to learn clojure and enjoying it immensely. It's a lot like ruby (powerful and fun) but with easier syntax and it's way faster. Looking forward to read through the conjure source.
One thing that bugs me with most of the clojure web frameworks that I have looked at is that they a. use ant instead of maven and b. don't provide a canned method to generate a war file. I don't like the advice "just leave a screen with slime and emacs running on your server". It runs on the JVM for crying out loud -- a little more enterprise is appropriate :)
I'm currently trying to learn clojure and enjoying it immensely. It's a lot like ruby (powerful and fun) but with easier syntax and it's way faster. Looking forward to read through the conjure source.
One thing that bugs me with most of the clojure web frameworks that I have looked at is that they a. use ant instead of maven and b. don't provide a canned method to generate a war file. I don't like the advice "just leave a screen with slime and emacs running on your server". It runs on the JVM for crying out loud -- a little more enterprise is appropriate :)
"just leave a screen with slime and emacs running on your server"
Another way to do it is just load the swank jar on your server (the server side of slime). In your server startup, include a call to (start-swank). Then you can connect via slime whenever you want using M-x slime-connect, and you don't need emacs + screen to stay running.
I've only learned the JVM as part of learning clojure. What advantages would a .war provide?
Another way to do it is just load the swank jar on your server (the server side of slime). In your server startup, include a call to (start-swank). Then you can connect via slime whenever you want using M-x slime-connect, and you don't need emacs + screen to stay running.
I've only learned the JVM as part of learning clojure. What advantages would a .war provide?
Advantages:
Easy to get a server running: just install tomcat or jetty on your production machine, sftp the war file and it automatically deploys.
Init.d scripts are tricky to write and get right, by using a tested script from a distro things tend to work out of the box.
Monitoring -- easy to hook in some monitoring script that can reboot tomcat or jetty should the server stop responding.
Techops generally know how to deploy a .war file -- I would not feel comfortable telling someone to learn lisp just to deploy a webapp.
pretty interesting with swank -- need to look into that.
Easy to get a server running: just install tomcat or jetty on your production machine, sftp the war file and it automatically deploys.
Init.d scripts are tricky to write and get right, by using a tested script from a distro things tend to work out of the box.
Monitoring -- easy to hook in some monitoring script that can reboot tomcat or jetty should the server stop responding.
Techops generally know how to deploy a .war file -- I would not feel comfortable telling someone to learn lisp just to deploy a webapp.
pretty interesting with swank -- need to look into that.
The war file and swank shouldn't be mutually exclusive, I just haven't bothered with a .war because by default Compojure starts Jetty itself, and I didn't want to bother with compiling the .war and restarting the server to test changes. Once you get addicted to reloading code from your IDE, you don't want to go back. :-)
> What advantages would a .war provide?
Deployment. If you have a procedure in place that handles versions of the server side code using .war files then you can simply give the sysadmins a new war to deploy and that will be that.
It's convenient because it is just a single file, if you want to roll back just move the old war file in to place, do 10 seconds of housekeeping and you're back up. Not that anybody ever had to revert to a previous version of their production code, of course. But in that hypothetical case...
Another advantage would be if you've automated your deployment across a large number of servers using this method. Update the master, send the signal to 'fetch and deploy' to the rest of your servers and that's it.
Deployment. If you have a procedure in place that handles versions of the server side code using .war files then you can simply give the sysadmins a new war to deploy and that will be that.
It's convenient because it is just a single file, if you want to roll back just move the old war file in to place, do 10 seconds of housekeeping and you're back up. Not that anybody ever had to revert to a previous version of their production code, of course. But in that hypothetical case...
Another advantage would be if you've automated your deployment across a large number of servers using this method. Update the master, send the signal to 'fetch and deploy' to the rest of your servers and that's it.
Out of interest, what's the advantage to being "more enterprise" in this case? Having a webserver with a working REPL seems like a rather useful thing to have.
Yes, that is very useful, in a way that's not normally possible with java.
But it is very nice to just give a .war file to techops. They know what to do with it, and how to keep such an application running and reboot it should it be needed. It's nice to not have to write custom init.d scripts.
But it is very nice to just give a .war file to techops. They know what to do with it, and how to keep such an application running and reboot it should it be needed. It's nice to not have to write custom init.d scripts.
"One thing that bugs me with most of the clojure web frameworks that I have looked at is that they a. use ant instead of maven ..."
Wouldn't it be better still to use something that is, and uses, Clojure?
One thing (among many) that I like about using JRuby is that I can use Ruby for config files and admin tasks. It may be a JVM language but I shouldn't have to use Java tools for routine tasks.
Wouldn't it be better still to use something that is, and uses, Clojure?
One thing (among many) that I like about using JRuby is that I can use Ruby for config files and admin tasks. It may be a JVM language but I shouldn't have to use Java tools for routine tasks.
Yes it would be better. The 2 key issues that maven solves for me is depencency management (specify which version of jar you need) and a consistent build enviroment across projects. Maven sucks in a lot of aspects mainly because it's rather opaque compared to ant -- hard to know what it actually does.
Providing a maven build will make it trivial for anyone with maven installed to build a project, making it easier to adopt clojure project in an organization that uses a lot of java.
Providing a maven build will make it trivial for anyone with maven installed to build a project, making it easier to adopt clojure project in an organization that uses a lot of java.
"Providing a maven build will make it trivial for anyone with maven installed to build a project, making it easier to adopt clojure project in an organization that uses a lot of java."
No doubt true, but the other side is that folks like me who barely know what Maven is, and would prefer to not do a lot of Java, are put off from trying Clojure (or certain Clojure tools and libs) because it appears too married to Java tools.
Sort of like telling people that to use Rails they first need to use autoconf or something because Ruby is C under the hood.
No doubt true, but the other side is that folks like me who barely know what Maven is, and would prefer to not do a lot of Java, are put off from trying Clojure (or certain Clojure tools and libs) because it appears too married to Java tools.
Sort of like telling people that to use Rails they first need to use autoconf or something because Ruby is C under the hood.
I understand what you mean and I can respect not wanting to dig too deep into java, we are talking about two different things here I think development and deployment. autoconf is great for someone who just wants to install something from source as simple as possible, it is also consistent across projects, making it a nobrainer to install with. I would love to have a simpler environment in clojure, it not even trivial to start the repl.
This one uses the build tool called "lancet", which is created throughout Stuart Halloway's Programming Clojure.
Exactly what I was thinking.
Rails is a Ruby framework, Django is a Python framework. Each one uses the strengths and idioms of its implementation language to be and become better.
These ports don't make sense. Clojure is not Ruby, there will always be a disconnect between Clojure as a language and a framework ported from Ruby.
These ports don't make sense. Clojure is not Ruby, there will always be a disconnect between Clojure as a language and a framework ported from Ruby.
...or Rails in Clojure will turn out even better than the original. It is not as if Clojure lacks the meta-programming power has made Ruby Rails so elegant.
http://github.com/danlarkin/madison is another interesting project. I believe the intent is to port Django to Clojure.
...but last commit was in April.
Yeah, Dan hasn't touched it much last I saw. I was interested early on as I had spent a bit of time in Django (not a ton) but was more interested in Clojure web dev. But due to it's lack of movement I haven't bothered.
I may take a look at this one but I dunno, I don't have the ties to Rails to give that appeal.
I may take a look at this one but I dunno, I don't have the ties to Rails to give that appeal.
Conjure seems to be in early dev stage. It'd be a good idea for it to be packaged with bleeding edge of the clojure rt instead of 1.0.
None the less, it looks very promising.
None the less, it looks very promising.
Although Clojure is an excellent tool, keep in mind it is still in early development.
It can be used to publish simple websites pretty elegantly, but for now it is relatively "low level"- I would say it still has a ways to go before being "Rails like."
It can be used to publish simple websites pretty elegantly, but for now it is relatively "low level"- I would say it still has a ways to go before being "Rails like."
Aside from having access to all the Java web frameworks, Clojure has Compojure and Conjure on the higher level and Ring (equivalent to Python's WSGI and Ruby's Rack) for lower level.
I wouldn't discount Clojure as not ready for complicated web applications based on it's young age; Java servlets can be written in Clojure. Not that Java servlets are great, but they are widely used for non-trivial web sites.
Clojure is great at removing the ugliness of some Java APIs, I recall that Compojure is built atop servlets.
I wouldn't discount Clojure as not ready for complicated web applications based on it's young age; Java servlets can be written in Clojure. Not that Java servlets are great, but they are widely used for non-trivial web sites.
Clojure is great at removing the ugliness of some Java APIs, I recall that Compojure is built atop servlets.
Compojure is built on top of Ring, but can wrap a Ring "handler" function in a Java servlet.
This functionality has been merged into Ring 0.1, so you may now be able to wrap a Conjure application into a Java servlet as well.
This functionality has been merged into Ring 0.1, so you may now be able to wrap a Conjure application into a Java servlet as well.
Oops- Accidentally wrote Clojure instead of Compojure.
Clojure is already pretty mature- Compojure is still the part that's excellent but still low level.
Clojure is already pretty mature- Compojure is still the part that's excellent but still low level.