On Thu, 9 Sep 2010 14:01:19 -0700 (PDT) Luke Renn <[email protected]> wrote:
> On Sep 9, 4:13 pm, Mike Meyer <mwm-keyword-googlegroups. > [email protected]> wrote: > > Here I thought I could save time by choosing a nice, simple example > > application that everyone would understand, rather than spending a lot > > of time explaining (or abstracting out) irrelevant details of some > > real-world application before asking the question about the overhead > > required to deploy java web apps. > The subject of the thread is Simple Things Should Be Simple. Others > in this thread have done a good job attempting to explain that they > are in fact simple so I won't continue. Perhaps you should play > around with ring and/or Compojure a bit and learn yourself. This is > something you would have to do for any serious evaluation anyway. No, they've explained what *they* consider to be simple. That isn't the same thing as actually *being* simple. > I will answer your specific question about deploying applications. Well, part of it, anyway.... > While creating a war file may involve some of what you conceive to be > boilerplate, it does so to simplify deployment of multiple > applications to a single server; which is exactly what you're now > asking about. How does typing the name of the namespace my code lives in three times into the web.xml "simplify deployment of multiple applications"? Clojure got this right - if I need to generate a class, the default name is the name of the namespace, which is right 20% of the time. > Download jetty, copy a war into the webapps directory and start the > server. Done. Don't like Jetty for some reason? Download tomcat, > copy the war to the webapps directory, start server. Done. Want > another app in that server, just copy the war into webapps. I'll take you at your word for it, though it isn't working yet (not sure I managed to correctly change the default port from the one that half the unprived apps in the world use, including calibre, but that's not a java issue). But there's still far more work in generating a war file than in doing the equivalent when it's well-designed. > It's the same with the scripts really. You think project.clj, lein, a > main class and running java -jar myapp.jar is silly when you can just > gcc myapp.c and run it with myapp. Sure, but that only works on a > single platform. The java -jar will work anywhere. You *really* want me to start the parade of variations of that three-line theme that would work on pretty much any platform that a jar file works on? Any interpreted language will do, though primitive platforms might require a wrapper to invoke the interpreter for them. > Like I said, you might think some things are boilerplate or > unnecessary, but they're done that way to provide benefits that are > beyond simplicity. Of course they are. Trouble is, they've ignored simplicity completely in the process. This reminds me of the config system for an ETL I dealt with once: it consisted of about 300 files of a dozen or so lines each (one file for each of the dozen or so processes that ran on each of the 25 or so machines involved). The original developers thought that was simple, but changing the config almost invariably caused something to break. In the second version, I applied a little thought to the configuration process, made the master program smart enough to choose intelligent defaults and count things itself, and reduced the same configuration to a single file - shared across all the machines - of about 30 lines. The new config system could do everything the old one did, but by making the common choices and previously entered values the defaults, it made simple configuration simple. Which meant that changing the config rarely broke things. <mike -- Mike Meyer <[email protected]> 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 [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
