This post originated from an RSS feed registered with Ruby Buzz by James Britt. Original Post: Per HAppS Feed Title: James Britt: Ruby Development Feed URL: http://feeds.feedburner.com/JamesBritt-Home Feed Description: James Britt: Playing with better toys Latest Ruby Buzz Posts Latest Ruby Buzz Posts by James Britt Latest Posts From James Britt: Ruby Development

HAppS looks quite the coolness :

HAppS is a framework for developing Internet services quickly, deploying them easily, scaling them massively, and managing them ziplessly. Web, persistence, mail, DNS and database servers are all built-in so you can focus on app development rather than integrating and babysitting lots of different servers/services (the Haskell type system keeps everything consistent).

Adverbly upbeat, there are a number of nice ideas in HAppS. Check this out:

Coming Soon: No need for server architecture (thanks to Amazon) We are almost done with changes to the back end of HAppS so that apps will be able to run unchanged on Amazon’s S3 and EC2. The result will be massive scalability and superior reliability without you having to lift a finger or walk into a data center.

Sweet.

I managed to get HAppS (yes, that’s the official capitalization) built on Ubuntu after many false starts and multiple Googles. The trick for me was to get a basic install using apt-get, then use that to build the current source, adding in the missing packages as I went.

One thing I discovered in my adventures was SQL Unnecessary In Haskell’s HAppS (there’s a Reddit thread on that article here).

Anyway, Happs does away with the database completely. Not only that, it does away with the Web server as well. The Happs philosophy says a server should be built in. Happs Web apps compile to binaries, which store serialized state in memory and on the filesystem. State is written to the filesystem first and stored in memory second. This, of course, enables failover.

There’s some related discussion that refers to Rails and how it treats SQL, but it brought to mind one of the reasons I like “Nitro”http://www.nitroproject.org/ , which that it (well, Og, really) puts the focus on objects, not (as in ActiveRecord) on tables.

Using Rails’ migrations you can skip most SQL, but the syntax is still all about tables and columns. With Og-enchanted models in Nitro, you can just write:

class Article
  attribute_accessor :title, String
  attribute_accessor :body, Text
# ...
end

and presto!, persistence and retrieval is taken care of. (Plus, you can look at your model source code and actually see what its attributes are.)

Now I need to get a first-hand look at The Haskell Way.