I’m just getting started with Cloud Foundry. So I grabbed Springs samples and compiled hello-spring-mongodb doing “mvn package” and then “vmc push -no-start”. That got me:

Would you like to deploy from the current directory? [Yn]: The input stream is exhausted.<br /> /Library/Ruby/Gems/1.8/gems/highline-1.6.1/lib/highline.rb:601:in `get_line'<br /> /Library/Ruby/Gems/1.8/gems/highline-1.6.1/lib/highline.rb:622:in `get_response'<br /> /Library/Ruby/Gems/1.8/gems/highline-1.6.1/lib/highline.rb:216:in `ask'<br /> /Library/Ruby/Gems/1.8/gems/vmc-0.3.10/lib/cli/commands/apps.rb:369:in `push'<br /> /Library/Ruby/Gems/1.8/gems/vmc-0.3.10/lib/cli/runner.rb:426:in `send'<br /> /Library/Ruby/Gems/1.8/gems/vmc-0.3.10/lib/cli/runner.rb:426:in `run'<br /> /Library/Ruby/Gems/1.8/gems/vmc-0.3.10/lib/cli/runner.rb:14:in `run'<br /> /Library/Ruby/Gems/1.8/gems/vmc-0.3.10/bin/vmc:5<br /> /usr/bin/vmc:19:in `load'<br /> /usr/bin/vmc:19

Probably that’s not what it should look like on a Mac, so I’m investigating the cause. Do shout out if you have an idea. I’ll update with my progress.

Update, question posted at http://support.cloudfoundry.com/entries/20072196-beginner-question

Wow, I remember back in 1998, me and another photo enthusiast were discussing DSLRs vs digital film. I was holding out on DSLRs until there was a camera that could fit my lenses and was as good as the Canon 500N I had at the time. Turned out I’d be waiting a while, the first one I got (matched the requirements!) was the Canon 20D. Anyway, my friend showed a links on Slashdot and a few papers on “Digital Film”, and I had to agree: that was probably a much better fit for the time.

Well, digital film didn’t materialize, until now (or rather, soon) hopefully: Tom’s guide has an article where they describe Park Hyun Jin’s concept:

While in my mind the right time was 1998 and the wrong time is 2011, I would still love a “roll” for my analogue camera, and I might even get a few more old systems for the pure joy of using them

Fair warning: This is speculation on my part

Fact 1: The Intel desktop chipset Z68 will be released in a week or two to the general public.
Fact 2: Apple cares about user experience
Fact 3: Intel has given Apple preferred access to its components before

The iMac, Apple’s Desktop offering, is long overdue. I had my bets for a refresh in February, that never happened. In March it would be logical to release an update with Sandy Bridge and Thunderbolt. That in itself would he a huge gain.

The Intel Z68 chipset will allow Apple to let the user have a small SSD drive for caching, so that all frequently run program data will be there. That’s not that different from what Samsung (and I’m sure others) already do on regular hard drives: keep a small bit of SSD for caching so that data that is frequently accessed is faster available than it would be reading from a drive. Except for this: the SSD drives used with the Z68 would typically be 64GB or around there.

Toms Hardware has a nice benchmark of using this chipset with SSD drives and whether larger drives make a substantial difference: http://www.tomshardware.com/reviews/z68-express-lucidlogix-virtu-ssd-caching,2888-4.html

Adding this would make the iMac the fastest Mac there is, at least when it comes to user experience, another blow to the Mac Pro for sure. It should also have a refresh, poor thing.

So while this is just speculation on my part, I think it makes sence, timing wise and logically. And, I really need a new Mac, so with the speculation about a special happening on May 3rd, with Apple Store employees being required to be present there, an iMac happening after “let’s get back to the Mac” makes very much sense to me.

PS, Apple, please allow me to add 64GB of RAM this time

Update: Yes, I was right on this one!

One thing that I seem to forget from project to project (after all, you only need to take care of this once pr project) is that a deployed Spring project is two parts: model, business and controllers is one part, views are another.

This means that in your web.xml you’re likely to have two parts defined, the org.springframework.web.context.ContextLoaderListener servlet which contains model, business and controllers, and the org.springframework.web.servlet.DispatcherServlet that contains your view resolvers and views.

This distinction is important, if nothing else than because it’s easy to set the url-pattern for the view servlet too broad, for instance to /*, and this will surely mingle your requests so that you don’t really know if it goes to the controller or to the view resolver.

These days I’m heavily looking into the NoSQL space, and I’ve currently limited my learning to the document space of CouchDB, MongoDB, key/value space of AWS SimpleDB and Cassandra, and the Neo4J graph space. For the projects I’m involved in I’m most excited about Couch & Mongo, even though I’d love to host it in the AWS space and therefore should be looking at SimpleDB.

If you’re exploring this space as well, I’d love to hear from you and your thoughts. Many more posts are bound to come