5 ms·

How a Clojure pet project turned into a full-blown cloud-computing web-app

95 points by budu 17y ago

budu 17y ago
All I wanted was a Pepsi.
ryandvm 17y ago
Forget how they did it. After looking at the first 20 slides, I'm more interested in getting in on the closed beta.
- icey 17y ago
  https://the-deadline.appspot.com/login?continue=%2Flist%2F https://the-deadline.appspot.com/login?continue=%2Flist%2F
RyanMcGreal 17y ago
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.
- zeynel1 17y ago
  I liked the slides. And what they are doing.
- brown9-2 17y ago
  It help translates the speech into something for readers (like us) to be able to follow along with later on
  - RyanMcGreal 17y ago
    Then post it in simple HTML on a web page.
    - svv 17y ago
      Just scroll to the bottom of the page -- the transcript is right there below the comments.
asolove 17y ago
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-programming-with-clojure.html http://www.hackers-with-attitude.com/2009/08/intertactive-pr...) on using Clojure interactively with GAE.
gcv 17y ago
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 17y ago
  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 17y ago
    > 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 17y ago
      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.
- deleted 17y ago
  [deleted]
- va_coder 17y ago
jimbokun 17y ago
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.
mark_l_watson 17y ago
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 17y ago
  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 17y ago
    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.
moe 17y ago
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.
- swannodette 17y ago
  Python templating solutions are also broken. They mix markup and logic. You could do everything described in the slides and use something like Enlive instead which cleanly separates markup and presentation logic. Most of the fancy features in popular templating solutions is just function composition in Enlive. Being a competent Lisp, macros can take things to a whole other level. 83 and 85 are the least interesting slides. How could instance instantiation be made much more succinct than that? Having developed web apps in Python (CherryPy, Django) a lot of boilerplate could be eliminated just by having access to macros.
- flogic 17y ago
  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 17y ago
    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.
tel 17y ago
fla;dr? http://www.slideshare.net/smartrevolution/how-a-clojure-pet-project-turned-into-a-fullblown-cloudcomputing-webapp#text-version http://www.slideshare.net/smartrevolution/how-a-clojure-pet-...
proemeth 17y ago
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.

95 points by budu 17y ago

budu 17y ago

All I wanted was a Pepsi.

ryandvm 17y ago

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

icey 17y ago
https://the-deadline.appspot.com/login?continue=%2Flist%2F https://the-deadline.appspot.com/login?continue=%2Flist%2F

RyanMcGreal 17y ago

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.

zeynel1 17y ago
I liked the slides. And what they are doing.
brown9-2 17y ago
It help translates the speech into something for readers (like us) to be able to follow along with later on
- RyanMcGreal 17y ago
  Then post it in simple HTML on a web page.
  - svv 17y ago
    Just scroll to the bottom of the page -- the transcript is right there below the comments.

asolove 17y ago

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-programming-with-clojure.html http://www.hackers-with-attitude.com/2009/08/intertactive-pr...) on using Clojure interactively with GAE.

gcv 17y ago

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 17y ago
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 17y ago
  > 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 17y ago
    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.
deleted 17y ago
[deleted]
va_coder 17y ago

jimbokun 17y ago

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.

mark_l_watson 17y ago

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 17y ago
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 17y ago
  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.

moe 17y ago

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.

swannodette 17y ago
Python templating solutions are also broken. They mix markup and logic. You could do everything described in the slides and use something like Enlive instead which cleanly separates markup and presentation logic. Most of the fancy features in popular templating solutions is just function composition in Enlive. Being a competent Lisp, macros can take things to a whole other level. 83 and 85 are the least interesting slides. How could instance instantiation be made much more succinct than that? Having developed web apps in Python (CherryPy, Django) a lot of boilerplate could be eliminated just by having access to macros.
flogic 17y ago
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 17y ago
  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.

tel 17y ago

fla;dr? http://www.slideshare.net/smartrevolution/how-a-clojure-pet-project-turned-into-a-fullblown-cloudcomputing-webapp#text-version http://www.slideshare.net/smartrevolution/how-a-clojure-pet-...

proemeth 17y ago

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.