Enter the user_default module. Any function defined in the user defined user_default module or in the Erlang defined shell_default module will be allowed to run without typing in the module name. One of these functions that you may use often is the c(module\_name). function. First start by creating a directory for your utility modules. I like having it in the ~/.ebin/ diretory. Now add that direcory to the code path by opening or creating the file ~/.erlang and inserting this line:

code:add_pathz("/Users/username/.ebin").

Create your user_default.erl file and but in the following:

-module (user_default).
-export ([sync/0]).

%% Compiles all files in Emakefile and load into current shell.
sync() ->
  make:all([load]).

Then compile it with erlc user_default.erl and start an Erlang shell. Now inside a project you can run sync(). and it will recompile and load you project.

For those interested I will put up my ~/.ebin code up at github.com/JonGretar/erlang_user_utilities. Please fork and make your own changes and share with the world.

EDIT: Some people prefer installing using RVM(Ruby Version Manager). I personally am a source guy but feel free to check the comments below for the RVM install info and skipping to the Rails part.

EDIT 2: Rails is now available as a pre-release gem and the rails installation step here is out of date.

There are many tutorials out there on how to install Ruby 1.9 but most of them involve installing the binaries with a "*19" suffix leaving you with 2 names for ruby. One called ruby and other called ruby19. I really dislike this methods as I see multiple ways how that can be annoying. I prefer my Ruby being called ruby so I usually install it in some directory that I can easily switch to by adding or removing a directory from the path.

So lets start by creating that installation directory. I also give my user the ownership of it. That may not be a smart idea for a production machine but as this is your local dev machine it's just handy that you never have to think about privileges when installing gems and so on:

sudo mkdir -p /opt/ruby19
sudo chown $USER /opt/ruby19

Now lets get the latest Ruby source and install to our new Ruby directory:

cd ~/Temp  
curl ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p376.tar.gz | tar zx
cd ruby-1.9.1-p376
./configure --prefix=/opt/ruby19 --enable-shared
make && make install

All done. Now you should have ruby 1.9 set up and all you need to do is add it's bin directory to the path with the command export PATH=/opt/ruby19/bin:$PATH and you should be set to go. For convenience I usually open up ~/.bash_profile and insert to it the line:

alias ruby19ify="export PATH=/opt/ruby19/bin:$PATH"

That way whenever I open up a new terminal it will be using the default Ruby 1.8 version. But to switch to 1.9 i just run the command ruby19ify and my terminal session will use our custom ruby version and the 1.9 gem scripts. If you wish to fully switch to the new version simply add this to the path permanently. Check your Ruby install by running the command ruby -v and you should be greeted with:

ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-darwin10.2.0]

Now before we install Rails we should update RubyGems to the latest version with the command:

gem update --system

While we used the Temp directory for the Ruby source files we really want to put the Rails source to your code directory as you are going to want to update this on a regular basis. The installation is dead simple:

cd *SomePlaceYouStoreCode*
git clone git://github.com/rails/rails.git
cd rails
git submodule init
git submodule update
rake install

Now every time you wish to update Rails(do it at least weekly) you simply cd to the source directory and perform the following commands:

git pull git submodule update rake install

And you should be set. Check that you have Rails 3 with the command rails -v, install your gems such as sqlite3, and start hacking away at rails. If you either successfully or unsuccessfully install a gem help other by reporting it at http://isitruby19.com/ as needed. If it fails then check the source code and see if you can't assist the community by fixing it. Do a few of those and, who knows, you might end up as a Ruby superstar like Ryan Bates or Geoffrey Grosenbach.

Remember that there are some big changes in Rails 3 that you need to be aware of. You may for example be surprised if you open up config/environment.rb as it is all but empty now. Gems are now set up using the Gemfile file in the root and there is a new file called config/application.rb for your configuration that are not environment bound. For a great collection of Rails 3 info visit the RailsNotes site.

And remember. Fork and Patch.

One thing that may interest you are the httpd_global_handlers. They are the little handlers for example behind the /_all_dbs and /_utils paths and more. You can also use them to easily make our own resources and in fact it is by far the simplest way to create a REST resource I know of. So if you are working with json resources it me be worth simply adding a handler in CouchDB rather than making it seperatly using webmachine or other technology. In fact here is an example of how making a resource for the computers environment variables. (Hey it could happen you needed that.)

Well thats easy. We import a few helper functions from couch_httpd that will handle returning JSON data back to the client. We make a method that takes a #httpd record as a variable and if its path has one part we return all environment variables but if it has 2 parts we return the value of that specific one. In fact in creating this resource there are only a handful of lines that I would even call "my code".

Compile this and put in CouchDB's code path. To use it we just open up local.ini and define our new handler and map to '/_env'.

[httpd_global_handlers]
_env = {my_httpd_handlers, handle_env_req}

Now just restart and go to http://127.0.0.1/_env and http://127.0.0.1/_env/HOME to see the result. For more complete examples of using handlers just go the the couchdb source and view the couch_httpd_misc_handlers.erl file.

2008 was a good year for me and my education as a developer. I got to know Erlang at the middle of the year and by the end of the year I was almost exclusively coding in Erlang. I have also started learning some standard C for playing with Arduino. I also learned the basics of Emacs and so far I like it though I still use Textmate for many things. And I started using Git and Github. I was to begin with skeptical about it and the fact that Linus Thorvalds was a bit of a dick when talking about it didn't help. But once I tried it I found it to be very productive and combined with GitHub it's quickly revolutionizing open source development in the world.

I became a contributor to the Nitrogen Web Framework. I have many ideas for it and hope to add many things to it. Nitrogen is at a very exciting stage as we are finding the path we want to take and can make many choices at this stage.

Is started playing with a little project I call CouchMail. It's basically a quick ugly hack to research gluing together a mail server with Nitrogen, Cappuccino, Mochiweb and finally CouchDB for data storage. If this works out ok I may consider writing a real application from scratch from what I learn.

I forked CouchDBX and completely rewrote the UI. I like my changes as they remove CouchDB from the desktop and you don't have to know about it until it is needed. I have most of the new code needed for CouchDB 0.9.0 ready so it should come out as soon as the new CouchDB is released.

ErlangXcode is an attempt to make Apple's Xcode 3 IDE be a kick ass Erlang IDE. A lot of the basic syntax is there with some, like records, still to be implemented. Also a basic build system in place and compilation errors show up in-code. I had to take a bit a break from it before going nuts though. Xcode's plugin system is 100% undocumented and there is no way do debug anything. What you have to do is to make small changes, compile and then reboot Xcode. There are no errors. The code just works, quietly doesn't work or it crashes Xcode. Hopefully I will quickly have energy to deal with it again soon. I did however start a little wiki project at google code documenting the xcode plugin system.

Finally there is a little project I started in the middle of the year called AstAssist. It's in a bit of a pause at the moment but basically it is an Erlang based system for Asterisk management. It's a complete solution for configuration, monitoring, event parsing, fastagi and so on. I have some of the basics done and hope to continue later in the year.

Well.. That's the bullet points. Hope some or all of these will become something amazing in 2009.

I'm going to mention the two of the most interesting web frameworks out there. They choose a very different path and I would call both of them production ready. As they are both projects in active development you might have a problem with a new release breaking a few things.

Nitrogen

Nitrogen is the new kid on the scene but has quickly become my favorite framework. Unlike most frameworks it's event driven. I enjoy it even more than Rails at the moment. It's dead simple to get started in and very powerful. It's in very active development and new and cool features are added almost weekly. The last new feature added was the simplest but one of the most powerful Comet implementation out there.

ONe of it's drawbacks is that there is no routing system in it. Paths are defined by the module names. So web_index.erl becomes /web/index or /web and web_blog_comment.erl becomes /web/blog/comment. Some might find this a bit limiting.

There are many cool features planned and one of the most interesting is implementing Erlangs power to be a distributed web frameworks. Thus solving many of the problems of scalability that many other web frameworks have

Pros:

• Dead simple.
• Nice bindings system.
• Kick ass Comet support.
• Interesting future ideas.

Cons:

• No routing at the moment.
• A little too simple on the template side.
• Really young so no real documentation yet.

Erlang Web

I have not much experience with Erlang Web but many seem to have started using it. It's and MVC framework built on OTP principles and uses many standard Erlang practices. It's template system on first view reminds me a bit of good old WebObjects. Currently it supports INETS and Yaws but not MochiWeb at the moment.

Pros:

• Very Flexible.
• Powerful template language.
• OTP Principles.

Cons:

• Could be simpler.
• Needs way better documentation.

Template Languages

Sometimes you may just want something simpler. Just a little template engine on a custom built web server to show some dynamic data. Or for use in your own web framework. Here are 2 notable template engines.

HERML

HERML is an erlang implementation of the HAML markup language. It's quick and simple but remember that this skips HTML altogether so it might not be for everyone.

ErlyDTL

ErlyDTL is an erlang implementation of the Django Template Language. I personally found DTL to be Django's most anoying feature but as many people like it it's best to mention it.

NOTE: This tutorial is very very old and uses early versions of both Nitrogen and CouchDB and many things here may not work as advertised.

Hey. Today I'm going to show you how to create a really, really simple blog in a few minutes using the Nitrogen Web Framework and the CouchDB document system. I presume you have basic erlang skills but this should be simple for anyone. I also presume you have already seen the Nitrogen Screencasts and are familiar with the basic behavior of Nitrogen.

Ingredients

Here is what yo will need:

• Nitrogen
• CouchDB (or CouchDBX)
• Ecouch
• Extra Files

I assume that Ecouch and Nitrogen are set up in the library path (see here for installation info). If you need any further help on this see this post

If you are using Mac OS 10.5 I recommend you use my implementation of CouchDBX to get you started quickly.

First we create a new project in a location of your choosing with the command

nitrogen create myblog

In there you will see a basic project to get started with. Now unzip the Extra Files and copy the files to your project. You will see a basic template I have set up for you at wwwroot/template.html. You will also see the module json_obj wich I savagely stole from the StickyNotes tutorial. It's basically a module that will assist you dealing with JSON data in Erlang. As JSON's data types are incompatible with Erlang it's best to grab help wherever you can.

First we will need to start ecouch. Open up src/myblog_app.erl and modify start() to start up ecouch before nitrogen

start(_, _) -> 
  application:start(ecouch),
  nitrogen:start().

To start the development server open up a terminal to the project root, type in "./start.sh" and visit the website http://localhost:8000. You should see a nice website with the body "web_index body.". Whenever you change the code in the project you will have to recompile with the command "sync:go().".

CouchDB

First thing we want to do is create the database and our view. Open up CouchDB at http://127.0.0.1:5984/_utils/, create a new database and name it "myblog". Next we are going to need a convenient view for Nitrogen. We are going to create a really simple view that returns a simple array with first the title and then the body. This makes it easy for us when we need to map the data later in Nitrogen as you will see later. We are also going to use the field timestamp as a key so the data is in time order.

To do that we select "Custom Query" under "Select view". Expand the "View Code" flap and replace the map function with the following.

function(doc) {
  emit(doc.timestamp, [doc.title, doc.body]);
}

Select "Save As" and save as the design document: "nitrogen" and view name: "flat".

The Model

We could call the data from the pages themselves but I prefer to create a little model class to seperate the logic. Create the file blog_posts.erl inside src and export get_posts/0 and add_post/1. First create the get_post/1.

get_posts() ->
    {ok, Return} = ecouch:view_access("myblog", "nitrogen", "flat"),
    RawRows = json_obj:get_value("rows", Return),
    F = fun(X) ->
            json_obj:get_value("value", X)
    end,
    Rows = lists:map(F, RawRows),
    lists:reverse(Rows).

First of all we made a call to CouchDB using ecouch requesting the nitrogen/flat view for the myblog database. Now as Erlang has incompatible types to JSON there is a lot of ugly extra data in the raw return which looks like this

{obj,[{"total_rows",2},
          {"offset",0},
          {"rows",
           [{obj,[{"id",<<"b8ffeaa68f2fd4010a105ddc56460466">>},
                  {"key",123},
                  {"value",[<<"The Title">>,<<"TheBody">>]}]},
            {obj,[{"id",<<"53b075b3633f8d8b3654576806ef18b3">>},
                  {"key",321},
                  {"value",[<<"Another Title">>,<<"Another Body">>]}]}]}]}

Now thats not very pretty is it so we use the json_obj module to query the value of "rows" so we don't have to parse this data by hand. We then make a fun that does the same thing for the "value" field of a row and use the map function to call it on each of the rows. We then reverse the list so the latest post is first. After doing all this the result of the function would be as following:

[ [<<"Another Title">>,<<"Another Body">>], [<<"The Title">>,<<"TheBody">>] ]

Ahh... Much Nicer.

We also need to create the data so we add the add_post/1 method.

add_post({post, Title, Body}) ->
    JSONTemplate = {obj, []},
    WithTitle = json_obj:set_value("title", list_to_binary(Title), JSONTemplate),
    WithTitleAndBody = json_obj:set_value("body", list_to_binary(Body), WithTitle),
    Complete = json_obj:set_value("timestamp", calendar:time_to_seconds(now()), WithTitleAndBody),
    ecouch:doc_create("myblog", Complete).

This does not need much explanation. We start by creating an empty JSON object so that we can use the json_obj functions on it. We then add the Title and Body parameters to the object and create a timestamp as well. Finally we ask ecouch to create the document.

The Index Page

Now edit the file called src/pages/web_index.erl and edit the function body() to look like this.

body() ->
    Data = blog_posts:get_posts(),
    Map = [titleHeader@text, bodyLabel@text],
    #bind { id=simpleBinding, data=Data, map=Map, body=[
        #panel { class="post", body=[
            #h2 { class="title", id=titleHeader },
            #panel { class="entry", body=[
                #label{ id=bodyLabel }
            ]}
        ]}
    ]}.

The main thing here is the data binding. We first take the output from our model and bind it to Data. As you remember the output of the model is a list of lists. Then we create the Map to describe how the elements of those lists should should bind to the page elements. So we are saying that the first element should bind to the "text" variable on the element with the id "titleHeader". We then use the #bind record, which is a sort of a for loop, and feed to it the Data and the Map.

You should now be able to sync and go see the webpage. Of course you can not see anything yes as we have yet to create any data.

The Create Page

Next create a new page using the command nitrogen page /web/create in your project root. Open up the newly generate src/pages/web_create.erl and replace body():

body() ->
    Body = [
        #label { text="Title:" },
        #textbox{ id=titleTextBox, class="create_title", next=body },
        #label { text="Body (HTML Allowed):" }, 
        #textarea{ id=bodyTextArea, class="create_body" },
        #br {},
        #link{ id=commitButton, text="Submit", postback=commit }
    ],

    %% Validations
    wf:wire(commitButton, titleTextBox, #validate { validators=[
        #is_required { text="Required." },
        #min_length { length=2, text="Title must be at least 2 characters long." }
    ]}),
    wf:wire(commitButton, bodyTextArea, #validate { validators=[
        #is_required { text="Required." }
    ]}),

    %% Render
    wf:render(Body).

Next up add a new event() just above the line that says ´event(_) -> ok.´

event(commit) ->
    [Title] = wf:q(titleTextBox),
    [Body] = wf:q(bodyTextArea),
    blog_posts:add_post({post, Title, Body}),
    Message = wf:f("Post ~p created. <a href=\"/web/index\">click here</a> to see it.", [Title]),
    wf:flash(Message);

There is nothing really complicated here as we have made most of the work already in the model. We set up a textfield and a textarea. We then bind the commitButton the generate the commit event. We then set up Validations so we can't submit empty data.

The commit event takes the value of the titleTextBox and bodyTextArea and sends it's data to blog_posts:add_post/1. It then formats a nice message and flashes it to the user.

Now sync and visit the page. Enter the create page and try submitting empty field. Then fill in the data and add a few posts. Visit the Index page to view your posts.

Conclusion

Even though this is not a very thorough nor complex tutorial it really shows how easily you can use together these two projects and create something really powerful with little code.

If you hit a problem please check my completed code here

I have been playing with Jan's CouchDBX a bit and thought someone might enjoy what I did. CouchDBX is a nice little Mac OS X tool to run CouchDB without the need to set up Erlang or anything.

There are 3 major changes that I did. First of the UI is gone and everything is now in a status bar menu. Should make for quicker access to it and also stay out of the way. There is also a new transparent log window if you need to see what is happening on the Erlang level. The third an most important change is that CouchDBX now stores it's database in ~/Documents/CouchDB. Before the database was inside the Application bundle itself and all the data disappeared every time you downloaded a new release of CouchDBX.

I have not renamed it or anything in case Jan would like to incorporate these changes to the original code or something.

EDIT 26. Nov: There was a serious error in my old version that made the javascript engine not run correctly. This has now been fixed and you need to redownload.

• Download
• My Source

-module(knockknock).
-compile(export_all).

start_joke() ->
    register(person_1, erlang:spawn(knockknock, person1, [])),
    register(person_2, erlang:spawn(knockknock, person2, [])),
    person_1 ! start_joke.

relay(Person, Message) ->
    io:format("------- ~p -------~n", [Message]),
    Person ! Message.

person1() ->
    receive 
        start_joke ->
            relay(person_2, "Knock, Knock");
        "Who's There?" ->
            timer:sleep(100000),
            relay(person_2, "Java")
    end,
    person1().

person2() ->
    receive
        "Knock, Knock" ->
            relay(person_1, "Who's There?");
        "Java" ->
            relay(person_1, "Ha Ha")
    end,
    person2().

Enter the ERL_LIBS environment variable. Set that to a directory and all the subdirectories of it that include code will the added automatically to the code path. To add it open up the file /etc/bashrc and add the following:

ERL_LIBS=/Library/Erlang/lib
if [ -d $HOME/Library/Erlang/lib ]; then
  ERL_LIBS=$HOME/Library/Erlang/lib:$ERL_LIBS
fi
export ERL_LIBS

This way all libraries under /Library/Erlang/lib and /Users/JoeUser/Library/Erlang/lib will be added to Erlangs code paths. The libraries will be in priority before the system libraries but after the -pa code paths. Now you can add things like Mochiweb, Eunit, Nitrogen and more under the /Library/Erlang/lib directory.

You could also put this in the file /usr/local/bin/erl

Sproutcore

Lets start by creating the Sproutcore application. I will not go into detail into the Sproutcore code as JavaScript and Sprutcore are way beyond a single tutorial.

sc-init mochi_contacts
cd mochi_contacts

Inside mochi_contacts we find a nice little framework for our application. Lets start by creating our model with the command. "sc-gen model mochi_contacts/contacts". Then we edit our model at clients/mochi_contacts/model/contacts.js and add the following code.

resourceURL: 'contacts',
properties: ["guid","fullname",'email','mobile'],

commitChanges: function(){
    if(this.get('fullname') == '') this.set('fullname', 'Unnamed');
    this.commit();
}

This is pretty straight forward. resourceURL defines the location of the data source. In this case it would be http://localhost/contacts/. In properties we define the keys we want to read from that resource. The commitChanges function then makes sure we have the fullname property defined and commits the changes to the resource.

Next up is our master controller. The master contoller handles our list view at the side. Create it with the command "sc-gen controller mochi_contacts/master SC.CollectionController", open up the file clients/mochi_contacts/controller/masterController.js and add the following.

allowsEmptySelection: false,
allowsMultipleSelection: false,
canEditCollection: true,

addContact: function(sender){
    var content = this.get('content');
    var contact = MochiContacts.Contacts.newRecord({
        fullname: "Unnamed"
    },MochiContacts.server);

    contact.commitChanges();
    this.set('selection',[contact]);
},

delContact: function(sender){
    if(!confirm('Are you sure?')) return;
    var sel = (this.get('selection') || []).clone() ;
    var idx = sel.get('length') ;
    while(--idx >= 0) {
        var contact = sel.objectAt(idx);
        contact.destroy();
    }
},

Not much to see here. Just basic functions for creating and deleting contacts from the list and 3 properties for defining the behaviour of the list view.

So now we need a second controller that will handle the form itself. Create it with the command "sc-gen controller mochi_contacts/detail SC.ObjectController" and put the following inside clients/mochi_contacts/controller/detailController.js

contentBinding: 'MochiContacts.masterController.selection',
commitChangesImmediately: false

Wow. Even less we do here. We simply bind the content of the controller to the currently selected object of the master controller. We then define that we dont want the changes to be posted automatically because we will add a button to do that.

Now we have to define the view. Open up clients/mochi_contacts/english.lproj/body.rhtml and remove everything. Replace with the following:

<% content_for('body') do %>

<% split_view :workspace, :class => 'sc-app-workspace footer', 
    :direction => :horizontal do %>  
  <% view :sidebar, :outlet => true do %>
    <% scroll_view :master_list, :outlet => true do %>
      <%= list_view :list_view, 
            :outlet => true, 
            :content_value_key => 'fullname', 
            :content_value_editable => false,
            :can_reorder_content => true,
            :bind => { 
              :content => 'MochiContacts.masterController.arrangedObjects', 
              :selection => 'MochiContacts.masterController.selection' 
            }
            %>
    <% end %>
  <% end %>

  <%= split_divider_view :outlet => true, :width => 5 %>

  <% view :detail_view, :outlet => true do %>
    <table class="card-detail">

      <tr>
        <td><label>Full Name:</label></td>
        <td>
          <%= text_field_view :outlet => true, :hint => "Full Name",
            :bind => {
              :value => 'MochiContacts.detailController.fullname'
            } %>
        </td>
      </tr>

      <tr>
        <td><label>Email:</label></td>
        <td>
          <%= text_field_view :outlet => true, :hint => "email@email.com",
            :bind => {
              :value => 'MochiContacts.detailController.email'
            } %>
        </td>
      </tr>

      <tr>
        <td><label>Mobile:</label></td>
        <td>
          <%= text_field_view :outlet => true, :hint => "555-0000",
            :bind => {
              :value => 'MochiContacts.detailController.mobile'
            } %>
        </td>
      </tr>

      <tr>
        <td colspan="2" class="buttons">
          <%= button_view :outlet => true, 
            :title => "Cancel",
            :action => 'MochiContacts.detailController.discardChanges',
            :bind => {
              :enabled => 'MochiContacts.detailController.hasChanges'
            } %>
          <%= button_view :outlet => true, 
            :title => "Save Changes", :default => true,
            :action => 'MochiContacts.detailController.commitChanges',
            :bind => {
              :enabled => "MochiContacts.detailController.hasChanges"
            } %>
        </td>
      </tr>
    </table>

  <% end %>
<% end %>

<% view :footer, :class => 'sc-footer sc-square-theme' do %>
  <div class="left">
    <%= button_view :outlet => true, :label => '+', 
        :action => 'MochiContacts.masterController.addContact' %>
    <%= button_view :outlet => true, :label => '-', 
        :action => 'MochiContacts.masterController.delContact' %>
  </div>

<% end %> <!-- footer -->

<% end %>

In here we have defined the views and bound their properties to the controllers.

Next we connect the contollers to the model. We do that inside clients/mochi_contacts/main.js by replacing the line MochiContacts.server.preload(MochiContacts.FIXTURES); with the following commands:

var contactList = MochiContacts.Contacts.collection();
contactList.refresh();
MochiContacts.masterController.set('content', contactList);
MochiContacts.server.listFor(contactList);

Before we move to the Erlang part we have to edit sc-config. As javascript request are bound to it's own domain we have to proxy the request by adding this as the very last line:

proxy '/contacts', :to => 'localhost:8808', :cookie_domain => 'localhost'

Now you should be able to start the server with the command sc-server and take a look at the result in http://localhost:4020/mochi_contacts.

The Format

The format SproutCore uses for REST calls are:

• CREATE = [POST]http://somesite/resource/create
• READ = [GET]http://somesite/resource/list
• UPDATE = [POST]http://somesite/resource/updateGUIDNUMBER
• DELETE = [POST]http://somesite/resource/DESTROYGUIDNUMBER

The Post values for CREATE and UPDATE methods are like:

"records[0][mobile]" = "555-1234"
"records[0][email]" = "sam.jones@example.com"
"records[0][fullname]" = "Sam Joness"
"records[0][id]" =  "@658"

The body expected to return for the READ method is in JSON format and looks like:

{"records": [
    { 
    "guid": "@570",
    "type": "Contacts",
    "fullname": "Frank Smith",
    "email": "frank.smith@example.com",
    "mobile": "555-4433"
    },{
    "guid": "@658",
    "type": "Contacts",
    "fullname": "Sam Jones",
    "email": "sam.jones@example.com",
    "mobile": "555-1234"
    }],
"ids": ["@570", "@658"]
}

Each record needs to have guid and type must be the name of the model it belongs to. ids must be a list of all the guid keys.

For mochijson2:encode/1 to be able to create this from an erlang term the format of the erlang term would be:

{struct,[{<<"records">>,
          [{struct,[{<<"guid">>,<<"@570">>},
                    {<<"type">>,<<"Contacts">>},
                    {<<"fullname">>,<<"Frank Smith">>},
                    {<<"email">>,<<"frank.smith@example.com">>},
                    {<<"mobile">>,<<"555-4433">>}]},
           {struct,[{<<"guid">>,<<"@658">>},
                    {<<"type">>,<<"Contacts">>},
                    {<<"fullname">>,<<"Sam Jones">>},
                    {<<"email">>,<<"sam.jones@example.com">>},
                    {<<"mobile">>,<<"555-1234">>}]}]},
         {<<"ids">>,[<<"@570">>,<<"@658">>]}]}

The Mochiweb Server

Knowing the expected formats it should be easy to write a mochiweb server to handle this. This is my version. Possibly one of my worst Erlang code but after spending way to much time figuring out mochijson2 I'm just putting this out there. (How about some documentation mochiguys? ;)

-module(web_server).
-include_lib("stdlib/include/qlc.hrl").
-export([start/0,stop/0,dispatch_requests/1]).
-record (contacts, {guid, type, fullname, email, mobile}).

start() ->
    mnesia:create_schema([node()]),
    mnesia:start(),
    try
        mnesia:table_info(contacts, type)
    catch
        exit: _ ->
            mnesia:create_table(contacts, 
                [{attributes, record_info(fields, contacts)},
                {type, set},
                {disc_copies, [node()]}])
    end,
    mochiweb_http:start([{port, 8808},{loop, fun dispatch_requests/1}]).

stop() ->
    mochiweb_http:stop().

dispatch_requests(Req) ->
    Path = Req:get(path),
    Method = Req:get(method),
    Post = Req:parse_post(),
    io:format("~p request for ~p with post: ~p~n", [Method, Path, Post]),
    Response = handle(Method, Path, Post),
    Req:respond(Response).


handle('GET', "/contacts/list", _Post) ->
    F = fun() ->
        Q = qlc:q([ build_struct(C) || C <- mnesia:table(contacts) ]),
        Q2 = qlc:q(
            [ list_to_binary(C#contacts.guid) || C <- mnesia:table(contacts) ]),
        Records = qlc:e(Q),
        IDs = qlc:e(Q2),
        Struct = {struct, [{<<"records">>, Records},{<<"ids">>, IDs}]},
        JSON = mochijson2:encode(Struct),
        list_to_binary(JSON)
    end,
    {atomic, Result} = mnesia:transaction(F),
    {200, [{"Content-Type", "text/javascript"}], Result };

handle('POST', "/contacts/create", Post) ->
    Guid = proplists:get_value("records[0][_guid]", Post),
    FullName = proplists:get_value("records[0][fullname]", Post),
    Email = proplists:get_value("records[0][email]", Post),
    Mobile = proplists:get_value("records[0][mobile]", Post),
    F = fun() ->
          mnesia:write(#contacts{
            guid=Guid, type="Contacts", fullname=FullName, 
            email=Email, mobile=Mobile}) 
    end,
    mnesia:transaction(F),
    {200, [{"Content-Type", "text/plain"}], <<"Created">> };

handle('POST', "/contacts/update"++Guid, Post) ->
    FullName = proplists:get_value("records[0][fullname]", Post),
    Email = proplists:get_value("records[0][email]", Post),
    Mobile = proplists:get_value("records[0][mobile]", Post),
    F = fun() ->
          mnesia:write(#contacts{
            guid=Guid, type="Contacts", fullname=FullName, 
            email=Email, mobile=Mobile}) 
    end,
    mnesia:transaction(F),
    {200, [{"Content-Type", "text/plain"}], <<"Updated">> };

handle('POST', "/contacts/destroy"++Guid, _Post) ->
    F = fun() ->
          mnesia:delete({contacts, Guid}) 
    end,
    mnesia:transaction(F),
    {200, [{"Content-Type", "text/plain"}], <<"Destoyed">> };

handle(_, _, _) ->
    {404, [{"Content-Type", "text/plain"}], <<"Unknown Request">>}.

build_struct(Record) ->
    {struct, [
        {<<"guid">>, list_to_binary(Record#contacts.guid)},
        {<<"type">>, list_to_binary(Record#contacts.type)},
        {<<"fullname">>, list_to_binary(Record#contacts.fullname)},
        {<<"email">>, list_to_binary(Record#contacts.email)},
        {<<"mobile">>, list_to_binary(Record#contacts.mobile)}
    ]}.

Just compile this and start with web_server:start().

Download the source