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.

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

ErlangX is basically an installation of the Erlang/OTP system. Basically it is installed in 2 locations. in /Library/Frameworks/Erlang.framework we have the standard Erlang installation with the standard libraries. In /Library/Erlang/lib there are a few other popular libraries preinstalled for you. In there would also go other libraries you would like to install system wide.

Erlang will also look into the directory /Users/USERNAME/Library/Erlang/lib/ for modules if it exists. These are for libraries you want only accessible to a single user.

Even though ErlangX is installed into /Library/Frameworks/Erlang.framework it is not yet set up as a real Cocoa framework. There are 2 reasons for this location. One is that other systems such as Ruby and Python are set up this way. The other is forward compatability. The intention is to create a real Cocoa framework out of this to help with the creation of Erlang ports or other Erlang related software in Objective-C. This is however not the first priority.

ErlangXCode is a plugin enabling the use of XCode as an IDE for Erlang development. It's all early work. Creating the XCode addons would not be possible without the amazing effort of Damien Bobillot who painstakingly found out how the XCode API works and shared it with us. If you install ErlangXCode without the ErlangX runtime install you have to make sure that erlc is available in /usr/local/bin. To see the basics of what I have currently you can check out this screencast(sorry about the watermark).

Now. As I have spent pretty much only 3-4 hours on this and most of it went into finding out how the XCode plugin system works there is a lot of things that need fixing. Syntax highliting is in early stages and a lot is missing. You can help by downloading the source and commiting to me changes or just editing the files installed in /Developer/Library/Xcode/Plug-ins/Erlang.xcplugin and sending me the changes. All help is much appreciated.

You can download the first test here. Although it should work fine be warned that this is an early test and some things may not work as advertised.

Well before you start any real software development in Erlang you really should start by reading the Programming Rules and Conventions on Ericsson's website. This should be your bible. Go ahead and read it now. Don't worry I'll wait.....

Back? Good. Now we can start this tutorial.

Housekeeping

We start by creating a directory for our application. In that directory we create the subdirectories doc, ebin and src. Now we create a file in the project root called Emakefile to ease the compilation of the software. Open up Emakefile and add the following:

{'src/sysinfo_server.erl', [{outdir, "ebin"}]}.

This basically lists our modules for compilation and tells Erlang to put the finished product into the ebin subdirectory.

Iteration 1: A Basic Server

Now lets take a look at the src/sysinfo_server.erl file. First declare the exports and add the start functions.

-module(sysinfo_server).
-export ([start/0, start/1, accept_connection/1, responder_loop/1]).

start() ->
    start(8023).

start(Port) ->
    {ok, ListeningSocket} = gen_tcp:listen(Port, 
       [list, {packet, 0}, {active, false}, {reuseaddr, true}]),
    accept_connection(ListeningSocket).

In start/1 we open up the socket using gen_tcp:listen/2 with the first parameter the port we want to use followed by the tcp options. I will not go in to details for the options but you can read about them in the gen_tcp module. We then pass the created socket to the the accept_connection/1 loop that handles accepting incoming connections.

accept_connection(ListeningSocket) ->
    {ok, Socket} = gen_tcp:accept(ListeningSocket),
    spawn_link(?MODULE, responder_loop, [Socket]),
    accept_connection(ListeningSocket).

Here we take the socket and wait for a connection to it with the command gen_tcp:accept/1. Thing to remember about gen_tcp:accept/1 command is that it waits forever for a connection and does not execute the next line until that connection is created. When we get the connection we use spawn_link/3 to create a seperate process running the responder_loop/1 loop that will handle all the communication to that client. The function then calls itself and waits for the next connection. Always keep this part simple. This way if something fails it will fail in responder_loop/1 thus only failing the single socket but our loop that accepts new connections is unlikely to fail and other socket continue to communicate. Lets now get to the responder loop.

responder_loop(Socket) ->
    case gen_tcp:recv(Socket, 0) of
        {ok, "exit\r\n"} ->
            gen_tcp:send(Socket, "Exiting \r\n"),
            gen_tcp:close(Socket);
        {ok, Other} ->
            gen_tcp:send(Socket, Other),
            responder_loop(Socket);
        {error, closed} ->
            ok
    end.

Here we take the data from gen_tcp:recv. The data includes the return character so we need to include that. If it matches "exit\r\n" we close the socket after sending a message back. Otherwise we echo the data back with gen_tcp:send/2 and recurse. Lets try it out by building the code and running it. Enter the following into the terminal at the project root.

bash$ erl -make
bash$ erl -pa ebin -run sysinfo_server start

Now using a telnet client telnet to localhost at port 8023. You should be able to get echoed back all that you type and type exit to break the connection. Close the server by typing in q(). in the erlang shell.

Iteration 2: Improving the server

First thing we are going to do is add a function that helps us to get the environment variable. As it is not a part of the data communication and might be a reusable function we decide to put it into it's another module called sysinfo_tools.erl. Start by adding it to the Emakefile by adding an identical line to what defines sysinfo_server.

{'src/sysinfo_tools.erl', [{outdir, "ebin"}]}.

Now create src/sysinfo_tools.erl and add the following.

-module (sysinfo_tools).
-export ([get_env/1]).

get_env(Var) ->
[CleanVar|_Rest] = string:tokens(Var, "\r\n\t "),
case os:getenv(CleanVar) of
  false -> "No Such Env";
  Result -> Result
end.

This is pretty simple. We take the input Var and remove all unwanted characters from it. We then call the os:getenv/1 function to retreive the environment variable. If it does not exist we return the value "No Such Env" or just simply return the value. no magic here so now we can get to the interesting part.

Now lets turn back to src/sysinfo_server.erl

First step is adding a function to assist us with sending data to the client. We want to run it with a list of strings and at the end it prints out a nice prompt for the user. So add this function.

send_lines(Socket,[]) ->
    gen_tcp:send(Socket, "\r\nEnvGet> ");
send_lines(Socket,[First|Rest]) ->
    gen_tcp:send(Socket,First),
    gen_tcp:send(Socket,"\r\n"),
    send_lines(Socket,Rest).

send_lines/2 takes a socket and a list as parameters. It prints out the first element and loops back with the rest. Finally when the list is empty it prints out a prompt and exits. Lets put it in use by changing accept_connection/1 so it looks like this.

accept_connection(ListeningSocket) ->
    {ok, Socket} = gen_tcp:accept(ListeningSocket),
    send_lines(Socket, ["Welcome to the EnvGet Service", 
        "Available commands are: list, get <env> and exit"]),
    spawn_link(?MODULE, responder_loop, [Socket]),
    accept_connection(ListeningSocket).

Now we want to add the list and get commands along with changing the code to use send_lines/2 so that the respoder loop looks like this.

responder_loop(Socket) ->
    case gen_tcp:recv(Socket, 0) of
        {ok, "get "++Var} ->
            Result = sysinfo_tools:get_env(Var),
            send_lines(Socket, [Result]),
            ?MODULE:responder_loop(Socket);
        {ok, "list\r\n"} ->
            Result = os:getenv(),
            send_lines(Socket, Result),
            ?MODULE:responder_loop(Socket);
        {ok, "exit\r\n"} ->
            send_lines(Socket, ["Exiting"]),
            gen_tcp:close(Socket);
        {ok, _Other} ->
            send_lines(Socket, ["Unknown Command"]),
            ?MODULE:responder_loop(Socket);
        {error, closed} ->
            ok
    end.

Well. First we take a look at the get command. Here we try to match a string that starts with "get " and add the rest to the variable Var. We then call our handy sysinfo_tools:get_env/1 function that gets the data for us. Next we try to match the command "list". We call os:getenv/0 and pass it on to the user. Since os:getenv/0's output is a list of strings we don't put brackets around like usually.

Now. Let's compile and run.

bash$ erl -make
bash$ erl -pa ebin -run sysinfo_server start

Try it out by telneting to locahost:8023 and trying out the commands "list" and "get HOME". It should work like a charm.

Well. Done for now. We would propably want to add a lot more before production. Like code reloading so the server doesn't have to go down for upgrades but that is a job for a later tutorial.

download the code if you have any problems.