From jetty to war?
Ok, I've got a simple web application that works running on embedded
jetty using the ring jetty adapter. I would now like to deploy it in
an infrastructure that will restart it if it dies, the system reboots,
etc. I've already got tomcat doing most of that, so the obvious choice
is a WAR file. Trouble is, trying the obvious thing from the
documentation doesn't work. The examples I find on the web all either
fail the same way, don't build (given that this is all new and still
rapidly evolving software, understandable), or involve using another
level of software. I chose ring because it looked like I could use
ring handlers in a number of different web servers without that extra
level.
Ok, this is the working serlvet.clj file: It picks up the handler from
x10.core, and then runs that:
(ns x10.servlet
[:use [x10.core :only (handler)]
ring.adapter.jetty
ring.middleware.reload ring.middleware.stacktrace])
(def app
(-> #'handler
(wrap-reload '(x10.core))
(wrap-stacktrace)))
(defn boot [] (run-jetty #'app {:port 8088}))
The goal is to get the same handler running in a server framework.
I'm trying tomcat via a WAR file: based on the ring documentation, I
added war.clj (this is just the latest variant):
(ns x10.war
[:use [x10.core :only (handler)]
ring.util.servlet])
(defservice handler)
Then added ring/ring-servlet to the project.clj :dependencies, an
:aout pointing x10.war, and build it using leiningen-war. Deploying
the resulting war file gets tomcat log messages about not being able
to create a SESSIONS.ser file, and a web page complaining that "The
requested resource (/x10/) is not available."
I did try building/deploying the compjure war example, and that at
least shows me the static page, so I believe the tomcat install is
correct.
Anyone got pointers to how to generate a WAR file for a simple
application, or suggestions on how to fix war.clj? Anything else you
might need to see to fix this?
Alternatively, instructions for deploying the same handler on either a
stand-alone (instead of an embedded) jetty, or on httpcore?
Thanks
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
i dont see a gen-class your snippet:
(ns mywebapp.firstservlet
(:use [ring.util.servlet :only (defservice)])
...
(:gen-class
:extends javax.servlet.http.HttpServlet))
(defservice app)
WEB-INF/web.xml:
firstservlet
mywebapp.firstservlet
firstservlet
/*
On Nov 1, 8:09 pm, Mike Meyer wrote:
> Ok, I've got a simple web application that works running on embedded
> jetty using the ring jetty adapter. I would now like to deploy it in
> an infrastructure that will restart it if it dies, the system reboots,
> etc. I've already got tomcat doing most of that, so the obvious choice
> is a WAR file. Trouble is, trying the obvious thing from the
> documentation doesn't work. The examples I find on the web all either
> fail the same way, don't build (given that this is all new and still
> rapidly evolving software, understandable), or involve using another
> level of software. I chose ring because it looked like I could use
> ring handlers in a number of different web servers without that extra
> level.
>
> Ok, this is the working serlvet.clj file: It picks up the handler from
> x10.core, and then runs that:
>
> (ns x10.servlet
> [:use [x10.core :only (handler)]
> ring.adapter.jetty
> ring.middleware.reload ring.middleware.stacktrace])
>
> (def app
> (-> #'handler
> (wrap-reload '(x10.core))
> (wrap-stacktrace)))
>
> (defn boot [] (run-jetty #'app {:port 8088}))
>
> The goal is to get the same handler running in a server framework.
> I'm trying tomcat via a WAR file: based on the ring documentation, I
> added war.clj (this is just the latest variant):
>
> (ns x10.war
> [:use [x10.core :only (handler)]
> ring.util.servlet])
>
> (defservice handler)
>
> Then added ring/ring-servlet to the project.clj :dependencies, an
> :aout pointing x10.war, and build it using leiningen-war. Deploying
> the resulting war file gets tomcat log messages about not being able
> to create a SESSIONS.ser file, and a web page complaining that "The
> requested resource (/x10/) is not available."
>
> I did try building/deploying the compjure war example, and that at
> least shows me the static page, so I believe the tomcat install is
> correct.
>
> Anyone got pointers to how to generate a WAR file for a simple
> application, or suggestions on how to fix war.clj? Anything else you
> might need to see to fix this?
>
> Alternatively, instructions for deploying the same handler on either a
> stand-alone (instead of an embedded) jetty, or on httpcore?
>
> Thanks
> --
> Mike Meyer http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail -www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
my short-time experience with implementing webapps on a clojure-base is: i feel like in the very early days of java-servlet-api and j2ee. productivity way way way behind springframework or grails i don't even want to think about doing something sophisticated like security-integration. and of course this is not surprising because everything is new and much things are built up from scratch. esp. when it comes to build and webapp-deployment i feel a mismatch that hurts. (this is an average java-programmer with 2+ years experience in implementing webapps with springframework and grails) thanks & have a successful time -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
fanvie, two comments: 1. It will get better over time, of course, as standard practices for Clojure shake out. 2. You don't need 99% of the special crap that Spring/Grails gives you. Clojure's abstractions are smaller, yes, but the're just as powerful, and give you more control, in a more standardized way, then Spring does. A couple of examples: A. Beans & wiring. Spring adds a lot of value in Java - the whole problem they solve, however, is completely irrelevant in Clojure. Instead of stateful or singleton beans, just use a namespace filled with functions. Equally as versatile, equally as configurable, much less mental and typographical overhead, and all within the language itself without requiring extra config. If you want another layer of indirection between your caller and callee, it's trivial to def that out, too. B. Security integration. Spring gives you elaborate security-filter- chains that manage request and session scoped authorization and user objects, all of which wrap the basic servlet API. Clojure, with stateless first-class functions, makes this far simpler. In Ring, for example, all your security functions can be implemented as middleware that just throws a :user onto the request map. I've done it - it's literally easier to write a Clojure middleware function that handles authentication from scratch than it is to figure out how to wire in whatever spring security filter you need. And all the code you need to write is actually 100% relevant to your authentication logic. To my mind, this is a vast improvement over Spring, where the few nuggets of actual logic are lost in a sea of Java filters, wrappers and xml configuration files. The same holds true of most other Spring/Grails idioms, such as MVC, JDBC access, AOP, etc. On Nov 1, 5:34 pm, faenvie wrote: > my short-time experience with implementing webapps on > a clojure-base is: > > i feel like in the very early days of java-servlet-api and j2ee. > > productivity way way way behind springframework or grails > > i don't even want to think about doing something sophisticated > like security-integration. > > and of course this is not surprising because everything is > new and much things are built up from scratch. > > esp. when it comes to build and webapp-deployment i feel a > mismatch that hurts. > > (this is an average java-programmer with 2+ years experience > in implementing webapps with springframework and grails) > > thanks & have a successful time -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Tue, Nov 2, 2010 at 12:49 PM, Luke VanderHart wrote: > fanvie, two comments: > 2. You don't need 99% of the special crap that Spring/Grails gives > you. Clojure's abstractions are smaller, yes, but the're just as > powerful, and give you more control, in a more standardized way, then > Spring does. I'll take exception to this comment. I think calling what grails as a framework provide you as "special crap", is at best, a disservice to grails as well as other web framework. At the end of the day, people want to deliver a solution for a problem they are working on. Not focusing on "oh look, shiny technology and abstractions" There is value in being able to define a domain object, and right off the bat have ORM taken care of for you, tables created, controllers setup with CRUD/webservice/scafold. and then grails war to produce a complete single war file to deploy to any java application server. Not everyone "needs" it, but that doesn't make it crap. --- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Luke, I must agree with Wilson, other frameworks have some advantages presently over Clojure for certain tasks. We use RAILS and JRuby to create CRUD GUIs with ActiveScaffold. Our controllers are typically 20 lines or less of configuration statements... We do not need to maintain HTML templates either. When I looked at Grails 18 months ago it was requiring more code lines than Rails for our purpose but this has certainly improved somehow overtime. Hard to beat Rails now. We will build some prototype with Conjoure in the next year or so to see how it fares compared to RAILS. We are testing a web app to display the medical record in a read only fashion and we used Compojure coupled with Spring and Hibernate. It will be in beta testing next week. It has to support 100 users. Using Hibernate was a logicial choice. We still use Spring but only to wire low-level stuff (like the ORM and factoring some objects interfacing with libraries). Spring does a good job at this and we do not write tons of XML lines or even code to get this to work. Luc P. Wilson MacGyver wrote .. > On Tue, Nov 2, 2010 at 12:49 PM, Luke VanderHart > wrote: > > fanvie, two comments: > > 2. You don't need 99% of the special crap that Spring/Grails gives > > you. Clojure's abstractions are smaller, yes, but the're just as > > powerful, and give you more control, in a more standardized way, then > > Spring does. > > I'll take exception to this comment. I think calling what grails as a > framework > provide you as "special crap", is at best, a disservice to grails as well as > other web framework. > > At the end of the day, people want to deliver a solution for a problem they > are > working on. Not focusing on "oh look, shiny technology and abstractions" > > There is value in being able to define a domain object, and right off the bat > have ORM taken care of for you, tables created, controllers setup > with CRUD/webservice/scafold. > > and then grails war to produce a complete single war file to deploy to any > java application server. > > Not everyone "needs" it, but that doesn't make it crap. > > --- > Omnem crede diem tibi diluxisse supremum. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Tue, Nov 2, 2010 at 10:49 AM, Luke VanderHart wrote: > fanvie, two comments: > > 1. It will get better over time, of course, as standard practices for > Clojure shake out. > 2. You don't need 99% of the special crap that Spring/Grails gives > you. Clojure's abstractions are smaller, yes, but the're just as > powerful, and give you more control, in a more standardized way, then > Spring does. Given other responses, I'd like to chime in with some agreement with Luke. I think it's important to be aware of what frameworks do for you, and what they don't do. It can be very easy, in a framework like Rails, to get a simple UI for doing basic CRUD operations on a single table, and for indicating basic relationships in the model. And someone's written a little HTML here and there to save you a little effort in the view. But what frameworks *don't* give you is a solution to the particular problem you're working on, and while it seems at first like they've already written 80% of your app, you'll quickly find that it's really a lot closer to 8% -- and the easy 8%, at that. For anything more complicated than a grocery list, the differences between frameworks is dwarfed by the application-specific logic of your project. I'm always amused when people try out some framework by making a blog, "proving" their framework is better because they could do it in 20 lines of code instead of 30. Beware frameworks that claim to be "easy." It usually means that the complexity lurks somewhere else. -- Chris Riddoch -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Ahem.. Your comment misses the point. We chose RAILS because it met 90% of our needs... not because of some claims it would solve any problem. We then selected RAILS over Grails then based on the time it required us to code, the # of code lines was a very good measure then to make our final selection between these two. This is why we use a mix of RAILS, Clojure and Spring. We chose the components best fitted to do specific things in our design. We did not choose a buzz word and then tried to make everything a nail so we could use a single hammer. For the medical record read-only view we did in Compojure/Clojure to extract a tree like model from the database and do html rendering with hiccup. Why ? because it was a perfect match for Clojure's abilities and it's very concise code-wise. There are around 50 tables to grab to display a medical record. Rails would have been too complex to implement over this since we only need to provide a read only view. Choosing between frameworks or making them coexist requires some knowledge about them, then you can have a selection process and see were you can apply them. Doing the reverse is non sense (choosing a framework based on some hyped reviews and then use for every need). BTW, we are driving interactions between several services in an hospital here, you can bet it's a bit more complex than a grocery list :) I totally agree that Clojure is a better tool to create abstractions, however we need to deliver now something that works today in the real world. Reusing what is available if it eases the pain to deliver is common sense. We cannot rewrite the whole universe in Clojure in one year. That's a fact. It's improving but will take some time to cover a number of areas. None of the above choices we made are static in time. They will change as things evolve over time and yes we tend to favor Clojure as much as possible to replace the other frameworks when an alternate solution is ready. We do not necessarily wait for prime time here, we are willing to push things in production that are not yet polished but not at the expense of increased delivery times and efforts. And again no we are not in the retail business at all :))) Luc P. Chris Riddoch wrote .. > On Tue, Nov 2, 2010 at 10:49 AM, Luke VanderHart > wrote: > > fanvie, two comments: > > > > 1. It will get better over time, of course, as standard practices for > > Clojure shake out. > > 2. You don't need 99% of the special crap that Spring/Grails gives > > you. Clojure's abstractions are smaller, yes, but the're just as > > powerful, and give you more control, in a more standardized way, then > > Spring does. > > Given other responses, I'd like to chime in with some agreement with > Luke. I think it's important to be aware of what frameworks do for > you, and what they don't do. It can be very easy, in a framework like > Rails, to get a simple UI for doing basic CRUD operations on a single > table, and for indicating basic relationships in the model. And > someone's written a little HTML here and there to save you a little > effort in the view. > > But what frameworks *don't* give you is a solution to the particular > problem you're working on, and while it seems at first like they've > already written 80% of your app, you'll quickly find that it's really > a lot closer to 8% -- and the easy 8%, at that. > > For anything more complicated than a grocery list, the differences > between frameworks is dwarfed by the application-specific logic of > your project. I'm always amused when people try out some framework by > making a blog, "proving" their framework is better because they could > do it in 20 lines of code instead of 30. > > Beware frameworks that claim to be "easy." It usually means that the > complexity lurks somewhere else. > > -- > Chris Riddoch > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Tue, Nov 2, 2010 at 7:26 PM, wrote: > Doing the reverse is non sense (choosing a framework based on some hyped > reviews and then use for every need). ... > We cannot rewrite the whole universe in Clojure in one year. That's a fact. > It's improving but will take some time to cover a number of areas. We seem to be in a similar position. We have a large CFML web application using frameworks that were decided before I joined the project. I initially introduced some Scala to handle some performance-critical XML transformations. Now I'm looking at the long-term roadmap for what we need to continue to grow our business and I'm prototyping sections of the application in Clojure but we're a bit hamstrung by some restrictions in the frameworks that were chosen (mainly the ColdBox MVC framework - CFML itself is not a problem) so until I can break some dependency chains, I can't move Clojure into production. But that will happen fairly soon (this past weekend I rewrote one core low-level component in Clojure to get us a step closer). I expect we'll stay with CFML for application views - CFML is a great HTML templating language - and we'll switch to a much simpler CFML MVC framework to replace ColdBox (FW/1 - which I wrote and published last year) so the controllers will stay in CFML. But the model will slowly migrate entirely to Clojure over time I expect. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Ok... Fair enough. Most of my comment related to Spring, not to Grails. Grails has other issues which I won't get into here. I have nothing but respect for Rails, and I look forward to the day when Clojure has a comparable system. On Nov 2, 2:32 pm, Wilson MacGyver wrote: > On Tue, Nov 2, 2010 at 12:49 PM, Luke VanderHart > > wrote: > > fanvie, two comments: > > 2. You don't need 99% of the special crap that Spring/Grails gives > > you. Clojure's abstractions are smaller, yes, but the're just as > > powerful, and give you more control, in a more standardized way, then > > Spring does. > > I'll take exception to this comment. I think calling what grails as a > framework > provide you as "special crap", is at best, a disservice to grails as well as > other web framework. > > At the end of the day, people want to deliver a solution for a problem they > are > working on. Not focusing on "oh look, shiny technology and abstractions" > > There is value in being able to define a domain object, and right off the bat > have ORM taken care of for you, tables created, controllers setup > with CRUD/webservice/scafold. > > and then grails war to produce a complete single war file to deploy to any > java application server. > > Not everyone "needs" it, but that doesn't make it crap. > > --- > Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart wrote: > I have nothing but respect for Rails, and I look forward to the day > when Clojure has a comparable system. I sort of have to ask "why?" - what's wrong with using Rails on JRuby for the front end and Clojure for the model? Why are folks so insistent on monolingual systems? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Sean Corfield wrote .. > On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart > wrote: > > I have nothing but respect for Rails, and I look forward to the day > > when Clojure has a comparable system. > > I sort of have to ask "why?" - what's wrong with using Rails on JRuby > for the front end and Clojure for the model? > > Why are folks so insistent on monolingual systems? No idea at all why it's so obsessive :), if a tool offers more comfort than another, well I'll choose the first one. Maybe because I am aging (not sure yet if it's a symptom of a disease or some form of wisdom :). The idea is to not let earlier choices fossilize but keep looking on better alternatives as time passes by. Luc P. > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies, Inc. -- http://getrailo.com/ > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
most companys i know - i have come around a lot last years - clearly prefer spring to grails because: 1. the integration-aspect is much more important for them than partial productivity win or promise. 2. java is established in their tech portfolio groovy is not clojure is completely out of scope for them. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
I have no problem at all with polyglot systems. That said, Clojure, as a general-purpose programming language, is in my subjective opinion superior to Ruby. Furthermore, there is nothing special about Ruby that makes it particularly suited to webapps (MVC webapps, perhaps, but MVC is not the only paradigm) As such, I expect and would welcome an eventual Clojure web framework with the same level of polish and stability as Rails. I don't mind polyglot programming, but one-language programming is easier. Plus, I just like working in Clojure. I don't think that's unreasonable, is it? Development platforms are not a zero-sum game. Just because I work on/prefer a Clojure framework to a Ruby one doesn't mean I'm trying to insult or belittle Rails. On Nov 3, 1:43 pm, Sean Corfield wrote: > On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart > > wrote: > > I have nothing but respect for Rails, and I look forward to the day > > when Clojure has a comparable system. > > I sort of have to ask "why?" - what's wrong with using Rails on JRuby > for the front end and Clojure for the model? > > Why are folks so insistent on monolingual systems? > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies, Inc. --http://getrailo.com/ > An Architect's View --http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
> Why are folks so insistent on monolingual systems? This was/is one of the original selling points and philosophies of Rails - a monolingual system should mean less context switching, less glue code for things to talk to each other, fewer bugs and mistakes stemming from uniformity of language, and better "flow" to the programming. Thanks, Peter -Original Message- From: lprefonta...@softaddicts.ca Sender: clojure@googlegroups.com Date: Wed, 03 Nov 2010 13:52:13 To: Reply-To: clojure@googlegroups.com Subject: Re: From jetty to war? Sean Corfield wrote .. > On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart > wrote: > > I have nothing but respect for Rails, and I look forward to the day > > when Clojure has a comparable system. > > I sort of have to ask "why?" - what's wrong with using Rails on JRuby > for the front end and Clojure for the model? > > Why are folks so insistent on monolingual systems? No idea at all why it's so obsessive :), if a tool offers more comfort than another, well I'll choose the first one. Maybe because I am aging (not sure yet if it's a symptom of a disease or some form of wisdom :). The idea is to not let earlier choices fossilize but keep looking on better alternatives as time passes by. Luc P. > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies, Inc. -- http://getrailo.com/ > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Wed, Nov 3, 2010 at 10:59 AM, wrote: > This was/is one of the original selling points and philosophies of Rails - a > monolingual system should mean less context switching, less glue code for > things to talk to each other, fewer bugs and mistakes stemming from > uniformity of language, and better "flow" to the programming. Well, that's one of the selling points of any full stack framework in any language (and, as you can probably guess, I don't buy it :) My experience is that full stack frameworks get you quickly to a part-way solution but the closer you get to your full solution, you harder you have to work against the framework to make progress. A discussion about frameworks came up on one of the XP lists a while back and the feeling was that micro-frameworks are much better - more agile - than full-stack frameworks, and that's something I agree with. Anyway, I think we're a long way off topic for the OP / question now... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Sean Corfield wrote .. > Why are folks so insistent on monolingual systems? We're facing that now, and with a mono-lingual system, you know everyone can contribute to any part of the project. If different parts are in different languages, then people working in one area won't necessarily be able to help with other parts should they need the help. Of course, what you're calling "insistent" is just people wanting to the frameworks to exist so they *can* do that, not really insisting that some current system be monolingual in spite of that lack. Even the above (admittedly minor) advantage to monolingual systems is enough to justify wanting those frameworks even while you're building multilingual systems. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Wed, Nov 3, 2010 at 3:31 PM, Mike Meyer wrote: > We're facing that now, and with a mono-lingual system, you know > everyone can contribute to any part of the project. If different parts > are in different languages, then people working in one area won't > necessarily be able to help with other parts should they need the > help. Solution: don't have monolingual programmers on your team :) I do understand the forces at play here. I've worked with a lot of monolingual teams and seen these same discussions about wishing we had framework X from language Y. I just cringe at the work invested in recreating all these frameworks in so many languages - especially when we're (nearly) all on the same JVM and we _could_ leverage these other languages / frameworks as-is. It just seems like so much wasted effort :( I'll shut up about this now... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
btw.: me too has great respect for ruby/rails one of the nice aspects of clojure is, that multiple currents and flavours of modern programming accumulate/reconvene in there. like evolution. diversity is good. it produces its own power and controversy. my fazit: clojure has great potential for webapp-development. but atm many libs/tools are in an early state or missing. this situation will improve/clear up over the years ... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Wed, 3 Nov 2010 16:26:13 -0700 Sean Corfield wrote: > On Wed, Nov 3, 2010 at 3:31 PM, Mike Meyer > wrote: > > We're facing that now, and with a mono-lingual system, you know > > everyone can contribute to any part of the project. If different parts > > are in different languages, then people working in one area won't > > necessarily be able to help with other parts should they need the > > help. > Solution: don't have monolingual programmers on your team :) What, we shouldn't hire Americans? :-) That only helps if everyone actually knows all the languages involved (we're looking at Ruby, Python and I'm trying to make a case for Clojure - but the critical language for my part of it is going to be XPath and/or XQuery). Finding good people is hard enough that wanting them to be good in three or four languages is enough to break the camels back. If you've got time to cross-train them - then you don't need > I do understand the forces at play here. I've worked with a lot of > monolingual teams and seen these same discussions about wishing we had > framework X from language Y. I just cringe at the work invested in > recreating all these frameworks in so many languages - especially when > we're (nearly) all on the same JVM and we _could_ leverage these other > languages / frameworks as-is. It just seems like so much wasted effort Except (in least in this case) some of the languages aren't on the JVM. In fact, I'm starting to get pressure against Jython and Clojure because of the legal mess that's starting to embroil the Java world. Way off topic, but anyone got any advice on *that*? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Wed, Nov 3, 2010 at 8:51 PM, Mike Meyer wrote: >> Solution: don't have monolingual programmers on your team :) > What, we shouldn't hire Americans? :-) Normally that joke is aimed at Brits like me :) > That only helps if everyone actually knows all the languages involved Well, smart people pick up new languages pretty easily and you don't need _experts_ in all those languages to make it work. > Except (in least in this case) some of the languages aren't on the > JVM. In fact, I'm starting to get pressure against Jython and Clojure > because of the legal mess that's starting to embroil the Java > world. Way off topic, but anyone got any advice on *that*? That's an interesting one. In my opinion it's a very paranoid (and uninformed) company that actually thinks they need to worry about *JVM*-based languages. There are multiple JVM implementations and none of the important ones are the subject of litigation. If you're not building Java-based apps for Android, why would they care? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Nov 3, 2010, at 11:43 AM, Sean Corfield wrote: > Why are folks so insistent on monolingual systems? Business reasons. Two languages means staffing expertise in both languages, either people who know both and cost more, or two people who cost less. In compsci terms, it's another dependency, which increases vulnerability. And Clojure and Ruby are quite different in syntax, features and general attitude about the world. Finally, while Clojure is great, it is not accepted enough yet to be able to easily find people who know it, who are good, and who are available. (All up-and-coming languages have to deal with this. The solution is to be dramatically better at solving certain problems, aka having a killer app. Ruby's killer app was/is Rails. When you are 10x more efficient at solving a problem, the bean counters wake up.) I don't even like having to use Javascript, or even HTML or CSS. I do so because it's the only way, really. I wish I could do everything in one great language. Which leads me to faenie's earlier comment: On Nov 1, 2010, at 3:34 PM, faenvie wrote: > my short-time experience with implementing webapps on > a clojure-base is: > > i feel like in the very early days of java-servlet-api and j2ee. That's my feeling too. Clojure is very impressive, but I think the ecosystem needs some maturing, more like e.g. jRuby. I'd like to see Clojure have a Pythonesque (batteries included) core library (not bifurcated as with clojure-contrib) that allows you to do the vast majority of what you'd want to do without additional libraries; and a gem or CPAN-style repository of modules. On a simpler level, I'd like it to Just Work Without Hassles. Install Clojure, write script, run anywhere without complex commands, twiddling with the environment, etc. For me, getting simple Clojure programs to work was difficult, not because I wrote them wrong, but because I had to deal with the idiosyncrasies of the JVM way of doing things. It's still a great start and I am eager to see how Clojure develops over the coming months and years. steven -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Steven Arnold wrote .. > On Nov 3, 2010, at 11:43 AM, Sean Corfield wrote: > > > Why are folks so insistent on monolingual systems? > > Business reasons. Two languages means staffing expertise in both languages, either > people who know both and cost more, or two people who cost less. In compsci terms, > it's another dependency, which increases vulnerability. And Clojure and Ruby > are > quite different in syntax, features and general attitude about the world. Finally, > while Clojure is great, it is not accepted enough yet to be able to easily > find > people who know it, who are good, and who are available. (All up-and-coming languages > have to deal with this. The solution is to be dramatically better at solving certain > problems, aka having a killer app. Ruby's killer app was/is Rails. When you > are > 10x more efficient at solving a problem, the bean counters wake up.) Having expert people mastering several tools in any project increases the like hood of being on time and within budget. The "blue collar" approach where one person knows only one thing and were you try to build "teams" to create software does not work within the scheduled time and budgets. We see this here everyday here, we have government driven projects following a Taylor style approach to software projects and they never get anything done on time and on budget. They do not even approach their target ROI by a significant factor. Private businesses do not go very far on this track given that their resources are limited but they have their own significant rate of failures. I drove a business creating custom software components for several customers in different markets for 7 years and we were 4 times faster than our customer's staff. We mastered multiple languages and frameworks and we were not dividing responsibilities between a bunch of individuals according to these artificial barriers. We were not afraid of putting forward creative solutions to their specific needs for the same reasons. Using a single hammer to solve any given problems is an error. You are better with a swiss knife. The super all purpose hammer maybe on its way but its not there yet Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Nov 5, 2010, at 10:20 AM, lprefonta...@softaddicts.ca wrote: > Having expert people mastering several tools in any project increases the like > hood of being on time and within budget. I agree partially. Given unlimited resources, it would be great for all the people on the project to have a mastery of all the tools used in the project. But resources are never unlimited, and therefore compromise is always necessary. I bet your organization was a small, focused team of experts -- a sharp tool for specific jobs -- not a large consulting organization with hundreds of employees and dozens of major projects. The primary point I was making was that each new technology introduces overhead in development, maintenance and operations. Therefore it should be included only if the benefit is compelling when compared to the change in costs associated with a team who can develop, maintain and operate a system that uses the technology. If a team like yours introduces a new technology, eventually the customer will have to maintain and operate it without your staff of top-notch experts to hold their hands. And I guess you guys weren't cheap in the first place. As they say, fast delivery, low cost, high quality -- pick any two. You were high quality and fast delivery. As far as failed projects go, in my experience, most failed projects fail not because the team is not good enough to deliver -- although this is possible -- but because of poor project leadership, poor executive support, requirements that shift too much, or disinterested or distant customers. These are essentially business reasons, not technical reasons. steven -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Steven Arnold wrote .. > > On Nov 5, 2010, at 10:20 AM, lprefonta...@softaddicts.ca wrote: > > > Having expert people mastering several tools in any project increases the > > like > > hood of being on time and within budget. > > I agree partially. Given unlimited resources, it would be great for all the people > on the project to have a mastery of all the tools used in the project. But resources > are never unlimited, and therefore compromise is always necessary. I bet your > organization was a small, focused team of experts -- a sharp tool for specific > jobs -- not a large consulting organization with hundreds of employees and > dozens > of major projects. That's why the large consulting organizations typically fail... I could give you around 2 billion$ worth of failed projects in the last 5 years driven by the big consulting firms here without having to dig very deep. I am not talking about the success of these big organizations (bill until the customer budgets are exhausted). I am talking about the success of the projects themselves. I can assure you than up here these large organizations are healthy. Not true about their customers budgets... but that's their business model. > > The primary point I was making was that each new technology introduces > overhead > in development, maintenance and operations. Therefore it should be included > only > if the benefit is compelling when compared to the change in costs associated > with > a team who can develop, maintain and operate a system that uses the > technology. Exactly what I have been saying earlier in this thread. Pick the proper tool... if a project was developed faster with it then guess what, the maintenance cost will be following the same trend. > If a team like yours introduces a new technology, eventually the customer will > have to maintain and operate it without your staff of top-notch experts to > hold > their hands. And I guess you guys weren't cheap in the first place. As they > say, > fast delivery, low cost, high quality -- pick any two. You were high quality > and > fast delivery. Yep but we were not either cheap or charging high fees. We used to sell fixed cost projects. Real fixed cost, not the "let's go in at cost + 3% and then lets make our bread and butter on change requests". And we were not trying to pull the customer out of is comfort bubble technology wise. However we were proposing original designs with the then trendy technologies that our customers embraced at the time. We knew more about their business and the software tool they used than their employees. That's what I call being a consultant, bringing some expertise and real solutions to the table, not just merely occupying a seat. > > As far as failed projects go, in my experience, most failed projects fail not because > the team is not good enough to deliver -- although this is possible -- but > because > of poor project leadership, poor executive support, requirements that shift > too > much, or disinterested or distant customers. These are essentially business reasons, > not technical reasons. These are valid reasons.. after the failure. The early detectable reason why projects are doomed to fail is that many projects are huge in scope and timeline and are not sliced to deliver some ROI fast enough. Customers are not getting usable components delivered in the near future. They just get vague promises that something will be delivered in x years. Nothing tangible there just vapor ware. And by the way can you pay me now since we completed 30% of the analysis... you can guess what is the ROI of such a delivery mile stone, it's worth about as much as toilet paper in terms of ROI. Given the pace of technology, user expectations, ... we should aim at short development cycles. Exactly the opposite of what occurs in these huge projects. We worked on projects worth more than 1 million dollars on several occasions but we never submitted proposals to bite the bullet at once. We focused on ROI milestones ... for the customer's sake. Luc > > steven > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Fri, Nov 5, 2010 at 2:42 PM, wrote: > Customers are not getting usable components delivered in the near future. > They just get vague promises that something will be delivered in x years. > Nothing tangible there just vapor ware. That's more than Half-Life fans are getting from Valve -- they won't even give a "vague promise that something will be delivered in x years"! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Ken Wesson wrote .. > On Fri, Nov 5, 2010 at 2:42 PM, wrote: > > Customers are not getting usable components delivered in the near future. > > They just get vague promises that something will be delivered in x years. > > Nothing tangible there just vapor ware. > > That's more than Half-Life fans are getting from Valve -- they won't > even give a "vague promise that something will be delivered in x > years"! > Agree but each user did not have to pay 10,000$ each BEFORE the first alpha release :))) oups ! Luc P. > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Wed, Nov 3, 2010 at 20:51, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > > Finding good people is hard enough that wanting them to be good in > three or four languages is enough to break the camels back. If you've > got time to cross-train them - then you don't need > > I've regularly found that the multi-disciplinarian programmer is far more adept at solving issues in a creative manner than the "I've a skilled hammer and I'll wield it in the direction of any nail"-mono-linguistic programmer. Perhaps that is just an artifact of working in startups though. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Nov 5, 2010, at 12:42 PM, lprefonta...@softaddicts.ca wrote: > That's why the large consulting organizations typically fail... I agree with most of your points. So let me address the one point which was the original subject of the thread... >> The primary point I was making was that each new technology introduces >> overhead >> in development, maintenance and operations. Therefore it should be included >> only >> if the benefit is compelling when compared to the change in costs associated >> with >> a team who can develop, maintain and operate a system that uses the >> technology. > > Exactly what I have been saying earlier in this thread. Pick the proper > tool... > if a project was developed faster with it then guess what, the maintenance > cost > will be following the same trend. I once had a very senior database developer take a set of requirements and deliver to me a solution that used a specialized database framework called Queues. Work was prepared, placed on the queue in the database, and a client later took the work off the queue and performed it. It took a few weeks to deliver the solution. It did everything it was supposed to do. But then the need changed slightly. We needed to resumbit work sometimes, or a portion of the work. We needed some work to be more important than other work. We wanted to tune the submission of work so we didn't pile up on a resource that was obviously not functional (e.g. a server that was straining or completely down). It turned out that for many reasons, the Queues framework was simply not designed to handle these variations on our original problem. After spending a lot of money and time trying to force the solution to work, we ended up throwing the whole thing away and using a simple table to store our work. Queues caused the product to be delivered perhaps 50% faster. But maintaining the product was a nightmare. Our database developer was a very senior resource. He had spent his entire career mastering the toolsets he used to deliver the product I asked from him. But it took all the cleverness of this senior resource to create a solution. The rest of my team were not as versed in that database platform and its frameworks as this developer. We did not have enough cleverness on the team to maintain the very clever tool he had created. This is why the proliferation of toolsets, including languages and major frameworks, is at best a necessary evil. Additional technologies add overhead and they add risk. This is why people want to keep the technology stack short and sweet. This is why speed of development does not trump everything else, and why speed of delivery is not a perfect corollary to ease of maintenance or operation. steven -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Fri, Nov 5, 2010 at 12:41 PM, Michael Ossareh wrote: > I've regularly found that the multi-disciplinarian programmer is far more > adept at solving issues in a creative manner than the "I've a skilled hammer > and I'll wield it in the direction of any nail"-mono-linguistic programmer. > Perhaps that is just an artifact of working in startups though. Possibly. I've worked in a variety of organizations from small startups to large corporations (such as insurance companies). In the smaller companies, developers have to wear more hats and it's common for a web developer to know HTML, JavaScript, SQL, **insert scripting language** and often shell scripts and / or other tools to help automate tasks. I don't see much difference between that and **insert multiple languages**. My exposure to the Agile world also leads me to believe they favor multi-disciplinary developers for productivity - and they certainly favor small teams of more experienced / expert programmers over large teams of less capable programmers. They also seem to be suspicious of frameworks because the more a framework seems to do for you, the less Agile it is likely to be if your requirements change (Steven's post about the Queues framework reinforces this argument). Interesting to see different people's opinions here - and to know that I'm not alone in my thinking (although I may well be in the minority). -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Fri, 5 Nov 2010 13:42:44 -0700 Sean Corfield wrote: > On Fri, Nov 5, 2010 at 12:41 PM, Michael Ossareh wrote: > > I've regularly found that the multi-disciplinarian programmer is far more > > adept at solving issues in a creative manner than the "I've a skilled hammer > > and I'll wield it in the direction of any nail"-mono-linguistic programmer. > > Perhaps that is just an artifact of working in startups though. > > Possibly. His comment is generally true, at least so long as the languages are really different. The obvious solution in one language may be non-obvious in a second, but have advantages over the obvious solution in the second language. A programmer skilled in both languages is more likely to see that "creative" solution than one who only knows the second language. > I've worked in a variety of organizations from small > startups to large corporations (such as insurance companies). In the > smaller companies, developers have to wear more hats and it's common > for a web developer to know HTML, JavaScript, SQL, **insert scripting > language** and often shell scripts and / or other tools to help > automate tasks. I don't see much difference between that and **insert > multiple languages**. This affect only works if the languages are sufficiently different to have different "obvious" solutions for a large number of problems. This is why people recommend learning a LISP even if you'll never use it - it will expand the way you look at problems. In your case, you have a markup language instead of a programming language, a database language, and a handful of scripting languages. Depending on the scripting languages, that's more like an expert in C++, C# and Java - basically three iterations of the same language - than an expert in (for example) C, Python, and Scheme. When it comes to multi-language projects, if you project is all Python, then someone who knows C/Python/Scheme and someone who knows Java/Python/Clojure are probably equivalent candidates. If your project is Java/Python, then the second one would be a good fit, and the first somewhat questionable (at the very least, they'll need time to come up to speed on Java). So even if you restrict yourself to multilingual programmers, multiple implementation languages cuts down on the pool of qualified people. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Fri, Nov 5, 2010 at 3:20 PM, wrote: > Ken Wesson wrote .. >> On Fri, Nov 5, 2010 at 2:42 PM, wrote: >> > Customers are not getting usable components delivered in the near future. >> > They just get vague promises that something will be delivered in x years. >> > Nothing tangible there just vapor ware. >> >> That's more than Half-Life fans are getting from Valve -- they won't >> even give a "vague promise that something will be delivered in x >> years"! > > Agree but each user did not have to pay 10,000$ each > BEFORE the first alpha release :))) That much is true. That's probably what saves Valve from the end of a lynch mob's rope. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Fri, Nov 5, 2010 at 2:33 PM, Mike Meyer wrote: > This affect only works if the languages are sufficiently different to > have different "obvious" solutions for a large number of problems. > This is why people recommend learning a LISP even if you'll never use > it - it will expand the way you look at problems. True, and why for years I've recommended to the CFML developers I interact with that they should learn languages like Prolog and Haskell rather than Java. Now I have the luxury of recommending they learn Clojure so they can stay within the JVM :) FWIW, my constant tweets and blog posts about Clojure have encouraged a number of them to try Clojure but most of them don't yet see a use case for it (because a lot of their apps are UI intensive and mostly just do CRUD behind the scenes - which CFML is very good at, especially now it has Hibernate ORM built-in). > So even if you restrict yourself to > multilingual programmers, multiple implementation languages cuts down > on the pool of qualified people. True dat... I know a lot of languages but Python is not one of them so I'd be no use for that hypothetical job (and why I was bummed when my former boss at Macromedia went to Linden Labs - because they required developers to know Python and I wasn't qualified to work for her :( -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
You'll learn Python quickly enough anyhow. Python is not very hard. 2010/11/5 Sean Corfield > On Fri, Nov 5, 2010 at 2:33 PM, Mike Meyer > wrote: > > This affect only works if the languages are sufficiently different to > > have different "obvious" solutions for a large number of problems. > > This is why people recommend learning a LISP even if you'll never use > > it - it will expand the way you look at problems. > > True, and why for years I've recommended to the CFML developers I > interact with that they should learn languages like Prolog and Haskell > rather than Java. Now I have the luxury of recommending they learn > Clojure so they can stay within the JVM :) > > FWIW, my constant tweets and blog posts about Clojure have encouraged > a number of them to try Clojure but most of them don't yet see a use > case for it (because a lot of their apps are UI intensive and mostly > just do CRUD behind the scenes - which CFML is very good at, > especially now it has Hibernate ORM built-in). > > > So even if you restrict yourself to > > multilingual programmers, multiple implementation languages cuts down > > on the pool of qualified people. > > True dat... I know a lot of languages but Python is not one of them so > I'd be no use for that hypothetical job (and why I was bummed when my > former boss at Macromedia went to Linden Labs - because they required > developers to know Python and I wasn't qualified to work for her :( > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies, Inc. -- http://getrailo.com/ > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over Esperanto? Perguntas sobre o Esperanto? - http://demandoj.tk -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
On Sat, Nov 6, 2010 at 5:59 AM, iko...@gmail.com wrote: > You'll learn Python quickly enough anyhow. Python is not very hard. I generally pick up new programming languages pretty quickly. I started my (working) life as a compiler writer and spent three years prior doing research into functional language design and implementation back in the early/mid-80's. My point was that they had a requirement for Python programmers - not someone who could learn Python on the job. It's rare that you get hired, not knowing a company's primary language, and be expected to learn it quickly enough to be productive. I've dabbled with Python but certainly not enough to put it on my resume. It's an OK language but not one that excited me so the situation really was hypothetical - much as I'd like to work with my former boss again, I'm not sure I'd want to be working in Python day in, day out. Languages are very subjective and, of course, preferences can change over time. After my FP work in the 80's, I became a fairly hardcore C programmer, then moved to C++ in '92, then jumped to Java in '97. I nearly took a full-time role doing Prolog in the mid-90's (the company structure sucked but the technology was very appealing). Over the last five years there have been a lot more languages to play with - which I like - but for me, everything has to interop. I may go back and investigate Jython at some point but don't have a use case right now. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
