

How a Clojure pet project turned into a full-blown cloud-computing web-app - budu
http://www.slideshare.net/smartrevolution/how-a-clojure-pet-project-turned-into-a-fullblown-cloudcomputing-webapp

======
jimbokun
The part about how so much of web application development is just translating
data from one format into another, and how objects just get in the way of that
process, really struck home with me. With Google's key value store mapping
directly to Clojure structs, which are then handed off to the HTML generation
code or converted into JSON, it's clear that including a step to map to
objects somewhere in there is totally superfluous. Which is exactly what I
find in developing web applications in Java on a daily basis.

------
asolove
It would be awesome if they posted this in a real text format rather than lots
of slides with (sometimes) very small text. I highly recommend the read, very
interesting.

Their blog has an excellent article ([http://www.hackers-with-
attitude.com/2009/08/intertactive-pr...](http://www.hackers-with-
attitude.com/2009/08/intertactive-programming-with-clojure.html)) on using
Clojure interactively with GAE.

------
gcv
Can someone with recent GAE experience comment on how well it works these
days? Any glaring problems, particularly with the JVM implementation? I plan
to launch a Clojure web app in the next few months, and I'd love to avoid
maintaining servers.

~~~
nwinter
I'm on the Python end, and it's gotten a lot more stable and faster since it
launched. A lot more features, too. A lot of the workarounds that we did early
on to fix headaches and failure cases just aren't needed any more, so it's
much closer to the abstraction we signed up for.

That said, if your site is always going to be small, you'll be able to do a
lot of database queries much faster with MySQL, Redis, or what have you than
with App Engine. The scalability wouldn't matter, so if you don't want to
worry about database limitations, then it's a point against.

~~~
anamax
> That said, if your site is always going to be small, you'll be able to do a
> lot of database queries much faster with MySQL, Redis, or what have you than
> with App Engine.

If your site is small enough, you may be able to host for free on AppEngine.
Even if it's not that small, AppEngine doesn't charge for availability, just
for usage. In other words, you don't pay for idle time.

~~~
nwinter
That is a plus. You can go very far within the free quota limits.

Another thing I forgot to mention is that if you want to use an external
domain (clojuresombrero.com instead of closuresombrero.appspot.com), and you
want users in China to be able to access it, then you need to run everything
through a reverse proxy or they'll hit the Great Firewall block.

------
moe
I'm regularly curiously peeking at the functional languages but I must say
those slides did not convince me much - perhaps just bad choice of examples.

E.g. on slide 79 the sight of generating HTML through a DSL horrifies me.
Littering the code with presentation details like that leads to maintenance
hell.

Likewise in the comparison of slide 83 vs 85 I frankly don't see any
difference between python and lisp in terms of verbosity.

So whatever point the author was trying to make - didn't work for me.

~~~
flogic
Having done the DSL templatng route in Perl, it's not really that bad. Really
there isn't much difference between having the templates in a template
language or a first class programming language. I can see it getting bad if
you're not disciplined and mix you app logic with you display logic. But it's
not really all that bad. I did it so I could use closures and what-not in my
templates. Worked out well. Makes the higher level templates more readable.

~~~
moe
Well, I commonly use template inheritance (in jinja) to great effect and can
think of dozens little reasons why having the HTML in separate files makes a
lot of sense (i18n, re-use, designers editing them, testing outside the app
etc.).

I also found the code presented in the slide especially scary because it was
intermixed with Lisp brackets and such. I imagine it would be a major pain to
rearrange something in there, don't even want to think about exploratory
programming in that style...

That's not to say it can't be neat in little one-off scripts - but for
production code I'd be extremely wary of that technique.

~~~
swannodette
Again you don't need to do it that way in Clojure. And in fact Enlive put
solutions like jinja, mako, etc to shame:

    
    
      (defn viewc [params session]
        (let [navs (if (= (:action params) "reverse") (reverse navs) navs)
             [nav1 nav2] navs]
          (base {:title "View C"
                 :main (three-col {:left nav1
                                   :right nav2})})))
    

This is what a "template" looks like in Enlive. Enlive actually can extract
HTML fragments out of a _pure_ HTML file and manipulate them. This means
designers can work in pure HTML and the coder can manipulate those HTML files
at will w/o putting any code into the markup.

~~~
moe
Well, thanks for providing a peek, although I'm still not sure I could bear
that syntax. I just find it very hard to parse (" _})})))_ ", seriously?), but
perhaps that gets better with age/familiarity.

The "can extract fragments from pure HTML" part certainly sounds interesting.
But still I have to wonder how well that scales to complex templates. I mean,
mixing logic into templates is ugly, but the alternative - completely
separating the interpretation from the template - doesn't seem so rosy to me
either. During a bigger re-arrangement I imagine it could become quite nasty
to re-sync the new template version with what the code expects?

I assume the above "template interpretation code" was for quite a trivial
thing. What would it look like for complex stuff? (70 chars of closing
parentheses? ;-) )

~~~
swannodette
Yet you're are okay with the following? :)

    
    
      {%for x in foo%}
      <div id="cool">{{x.bar}} {{x.baz|pluralize}}</div>
      {%endfor%}
    

It's just different flavors of line noise. At least with Emacs you have
paredit to manage code structure for you, no need manually track parens/braces
at all.

~~~
moe
_Yet you're are okay with the following? :)_

Quite frankly; yes.

Not pretty in any way but I guess 15 years of familiarity play their part and
I have never had a big problem with that particular concept (it just works
well for me in practice).

However, to each their own. Looking forward to see how compojure adoption will
play out, perhaps at some point I'll just "get it" and wonder how I ever
worked without it. ;-)

------
mark_l_watson
Great set of slides - I wish I could have heard the talk live. I did add his
company's blog to my RSS/Atom feed.

I would like to spend more time with both Clojure and AppEngine and the slides
were some motivation. I am still a little skeptical however that Clojure base
web apps will ever have the traction of Rails (I had a 5 hour sprint today to
add two major features to a customer's rails web app: would have taken a long
time to do with server side Java; I would guess that Clojure would split the
difference).

I've bought 3 Clojure books, and I would by a 4th if the author of these
slides would write a web app specific Clojure book.

~~~
jcromartie
I have to say that languages that favor immutable data structures and
functional style are great for web dev. From what I've done in
Clojure/Compojure compared to my experience in Rails, it's great not having a
billion implicit magical parameters to each function (aka instance methods and
magic instance/class methods that may not exist or be documented). You can
really fit a lot of a functional web app in your head. Rails just spills all
over the place and you slip on it and end up with stitches.

~~~
mark_l_watson
Thanks, that sounds right. That said, I have 3+ years invested in Rails, so it
is difficult to make a commitment to another stack. I am doing a small (non
web app) project with Clojure right now, which is fun and educational.

------
proemeth
Nice remark on how the need for a "powerful" IDE is a code smell. The need for
the IDE reveals that some abstraction the language should provide but isn't
has to be handled by something else. No such problem with macros.

------
ryandvm
Forget _how_ they did it. After looking at the first 20 slides, I'm more
interested in getting in on the closed beta.

~~~
icey
<https://the-deadline.appspot.com/login?continue=%2Flist%2F>

------
budu
All I wanted was a Pepsi.

------
RyanMcGreal
I'm interested in the project, but the author's decision to write out his
lecture notes on a series of 110 slides is a bit off-putting.

~~~
brown9-2
It help translates the speech into something for readers (like us) to be able
to follow along with later on

~~~
RyanMcGreal
Then post it in simple HTML on a web page.

~~~
svv
Just scroll to the bottom of the page -- the transcript is right there below
the comments.

------
tel
fla;dr?

[http://www.slideshare.net/smartrevolution/how-a-clojure-
pet-...](http://www.slideshare.net/smartrevolution/how-a-clojure-pet-project-
turned-into-a-fullblown-cloudcomputing-webapp#text-version)

