Lambdajam Talks

| Comments

Earlier this year I spoke at Yow! LambdaJam about RAFT and Erlang. I thought I should link to my talk descriptions and slides here.

On the first morning of the conference I spoke about the RAFT distributed consensus algorithm and how it could be implemented in Erlang/OTP. The slides are here with the video to follow sometime later. I was very happy with how the talk went despite many pre-conference nerves and will surely be submitting something next year.

In the final workshop slot of the conference I presented an Erlang workshop on building a Webmachine system for shortening urls. The source code on github here.

Yow! LambdaJam is a great conference that brings together the functional programmers from across Australia. I personally had a great time and would encourage anyone who is interested in functional programming to come along next year. We had talks on Erlang, Haskell, Idris, Scala and Clojure. I’m hoping next year we see something on OCaml and F#.

Ember.js and Google Analytics

| Comments

Update

As iStefo pointed out in the comments the code I gave has a bug in it. The observes('currentPath') on an application controller doesn’t fire when you transition between paths in the same route. eg ‘/lesson/1/activity/1’ to ‘/lesson/1/activity/2’

A better approach is to add the code to your router.

1
2
3
4
5
6
7
8
9
10
App.Router.reopen

  didTransition: (infos) ->
    @_super(infos);
    return unless window.ga
    Em.run.next ->
      ga('send', 'pageview', {
         'page': window.location.hash,
         'title': window.location.hash
      });

Matthew Beale also pointed out below that there may be a new API coming on the router to achieve the same result. PR#3452 and PR#3453


Original

Single Page Javascript Applications and specifically Ember.js applications don’t always expose the right information to Google Analytics. Usually you’ll see 100% traffic to / and nothing else.

What I wanted to be able to see what areas of the site people were using in real time. A bit of searching led to various solutions with this post having the most upto date solution. Working in Ember you quickly become wary of older solutions posted and start filtering search results based on time. Hopefully now that 1.0 is out the correct solutions will start bubbling to the top of Google searches.

To make your Ember.js application more visible to Google Analytics you need to expose the value of your application state. I’m using the hash scheme (eg #/album) so whatever is after the hash in the url shows where a person is in the application.

First you’ll need to have the Google Analytics Javascript library loaded, I’ve been using the more recent analytics.js library which has a different API to the older ga.js library. After you’ve followed Google’s instructions the library is available at ga.

Next you want to observe whenever the hash path changes within your app. The code below assumes you’re using hashes rather than HTML5 pushState.

1
2
3
4
5
6
7
8
9
10
App.ApplicationController = Em.Controller.extend

    routeChanged: (->
        return unless window.ga
        Em.run.next ->
            ga('send', 'pageview', {
                'page': window.location.hash,
                'title': window.location.hash
                });
    ).observes('currentPath')

The routeChanged function gets called when currentPath changes; it checks whether ga is defined and if it is it sends a pageview event with the current value of location.hash. The Em.run.next is there to make sure all the routing has occured and the hash value is final before using it.

page and title are just strings so you could provide meaningful formatting based on what your application does. The next obvious step is to add event tracking to really see how people interact with the app.

Erlang Hot Code Loading

| Comments

Nearly every posting about Erlang that you come across mentions the hot code loading feature, aka dynamic code loading. But so far I have had problems finding a simple example of how to add this to my code. So here is one.

Copy this code into an editor. I’m using Emacs here, so all instructions use it’s keybindings.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
%% A process whose only job is to keep a counter.
-module(counter).
-export([start/0, codeswitch/1]).

start() -> loop(0).

loop(Sum) ->
    receive
        {increment, Count} ->
            loop(Sum+Count);
  {print} ->
      io:format("Sum is ~p~n", [Sum]),
      loop(Sum);
        {counter, Pid} ->
            Pid ! {counter, Sum},
            loop(Sum);
        code_switch ->
            ?MODULE:codeswitch(Sum);
  M ->
      io:format("Unhandled message ~p~n", [M])
    end.

codeswitch(Sum) -> loop(Sum).

Compile and start a new erlang shell, Ctrl-C Ctrl-K.

Now we want to start a new process running this code. Startup and enter the following code into the erlang shell.

1
2
3
4
5
Erlang R15B (erts-5.9) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9  (abort with ^G)
1> Pid = spawn(fun() -> counter:start() end).
<0.37.0>

Send the process a message to make sure it’s alive and working.

1
2
3
4
5
3> Pid ! {increment, 3}.
{increment,3}
4> Pid ! {print}.
Sum is 3
{print}

Now that we have the first version of the process running, add a new clause to the receive like so.

1
2
3
4
5
6
7
8
        {print} ->
      io:format("Sum is ~p~n", [Sum]),
      loop(Sum);
  {reset} ->
      loop(0);
        {counter, Pid} ->
            Pid ! {counter, Sum},
            loop(Sum);

Compile this version, Ctrl-C Ctrl-K and send a message to the process that only the new version can handle.

1
2
3
6> Pid ! {reset}.
Unhandled message {reset}
{reset}

So we are still running the previous version of the code.

1
2
3
4
5
6
7
8
9
10
6> Pid ! code_switch.
code_switch
7> Pid ! {print}.
Sum is 3
{print}
8> Pid ! {reset}.
{reset}
9>  Pid ! {print}.
Sum is 0
{print}

The ‘code_switch’ message makes the process load the new version of code. So using this you can upgrade the running process without losing state. Cool.

Getting Started With Sinan

| Comments

Background

When I started with Erlang I used a simple Makefile to call erlc and pretty much did things by hand. After a number of years in the wilderness I found out about rebar from Basho and started using that to compile my code. Everything was good, rebar knew how to compile OTP apps and pull down external dependencies. Except when I needed to generate releases. It’s not necessarily straight forward to get rebar to build you a nice release, not that it’s impossible it’s just not as simple as I’d like.

Enter Sinan, the somewhat forgotten erlang build tool.

Sinan is a build tool designed to build Erlang/OTP projects, releases and applications. It claims to be more OTP than rebar and uses the OTP metadata artefacts to build your project with little configuration needed.

Let’s see how well it delivers on the promise.

Sinan From Scratch

First you’ll need Erlang installed, which your friendly local package management tool should provide. I’m using Homebrew on OSX so I just did:

1
2
3
4
5
6
7
$ brew install erlang
...
$ erl -v
Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1>

Linux should be similarly straight forward and Windows well you’re on your own.

Grab sinan from the downloads page on github, I’m using version 4.1.1. Put it somewhere on your PATH, I’ve got mine in ~/bin which is on my PATH, and chmod +x it so it’s executable.

Now for the fun bit, type sinan gen and fill in the details.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Please specify your name
your name> Tim McGilchrist
Please specify your email address
your email> timmcgil@gmail.com
Please specify the copyright holder
copyright holder ("Tim McGilchrist")>
Please specify name of your project
project name> sinan_demo
Please specify version of your project
project version> 0.0.1
Please specify the ERTS version ("5.9.1")>
Is this a single application project ("n")> y
Would you like a build config? ("y")> y
Project was created, you should be good to go!

From that Sinan has generated a project, filling in your details, with an OTP application and some build configuration. Your directories should look something similar to this.

1
2
3
4
5
6
7
8
9
10
11
12
sinan_demo
    ├── config
    │   └── sys.config
    ├── doc
    ├── ebin
    │   └── overview.edoc
    ├── include
    ├── sinan.config
    └── src
        ├── sinan_demo.app.src
        ├── sinan_demo_app.erl
        └── sinan_demo_sup.erl

It includes all the standard directories you’d expect plus a sinan.config file.

First a little diversion, we need to add a line to the sinan config file, which tells sinan to include the erlang runtime system when it generates a release. Open sinan.config and add {include_erts, true}. as the last line. It should look like this:

1
2
3
4
5
6
7
8
9
10
{project_name, sinan_demo}.
{project_vsn, "0.0.1"}.

{build_dir,  "_build"}.

{ignore_dirs, ["_", "."]}.

{ignore_apps, []}.

{include_erts, true}.

Back to making our generated code runnable.

By default the generated supervisor doesn’t point to a valid module so you’ll need to remedy that before trying to startup the application. Create a new file called sinan_demo_server.erl in src and drop the following code in.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
-module(sinan_demo_server).

-behaviour(gen_server).

%% API
-export([start_link/0, add_one/0, total/0]).

%% Callbacks
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
         terminate/2, code_change/3]).

-record(state, {count}).

%%%===================================================================
%%% API functions
%%%===================================================================

start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

total() ->
    gen_server:call(?MODULE, total).

add_one() ->
    gen_server:call(?MODULE, add).

%%%===================================================================
%%% Callbacks
%%%===================================================================

init([]) ->
    io:format("starting~n", []),
    {ok, #state{count = 0}, 0}.

handle_call(add, _From, State) ->
    NewCount = State#state.count + 1,
    NewState = State#state{count = NewCount},
    Reply    = {ok, NewState},
    {reply, Reply, NewState};
handle_call(total, _From, State = #state{ count = Count }) ->
    {reply, Count, State};
handle_call(Msg, _From, State) ->
    {reply, {ok, Msg}, State}.

handle_cast(_Msg, State) ->
    {noreply, State}.

handle_info(_Info, State) ->
    {noreply, State}.

terminate(_Reason, _State) ->
    ok.

code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

It’s a pretty standard OTP gen_server application with 2 API methods. add_one/0 adds 1 to the counter and total/0 returns the value of the counter. The record definition setups up the state record for this server with just a count attribute. The 2 API functions use the gen_server:call/2 method to hit the OTP callback for handle_call/3.

Next we need to fix the supervisor so it starts the correct module. Change sinan_demo_sup.erl so it looks like the code below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
start_link() ->
    supervisor:start_link({local, ?SERVER}, ?MODULE, []).

%%%===================================================================
%%% Supervisor callbacks
%%%===================================================================

%% @private
-spec init(list()) -> {ok, {SupFlags::any(), [ChildSpec::any()]}} |
                            ignore | {error, Reason::any()}.
init([]) ->
    RestartStrategy = one_for_one,
    MaxRestarts = 1000,
    MaxSecondsBetweenRestarts = 3600,

    SupFlags = {RestartStrategy, MaxRestarts, MaxSecondsBetweenRestarts},

    Restart = permanent,
    Shutdown = 2000,
    Type = worker,

    AChild = {sinan_demo_server, {sinan_demo_server, start_link, []},
              Restart, Shutdown, Type, [sinan_demo_server]},

    {ok, {SupFlags, [AChild]}}.

The 2 changes we have make is to start_link/0 so we can call the server directly, and fix the child spec so it starts our new module.

Now we need to add the sinan_demo_server module to sinan_demo.app.src so we know about it when generating the OTP application. Just add it to the list of modules like so:

1
2
3
4
5
6
7
8
9
10
11
12
%% This is the application resource file (.app file) for the,
%% application.
{application, sinan_demo,
 [{description, "Sinan demo application."},
  {vsn, "0.0.1"},
  {modules, [sinan_demo_app,
             sinan_demo_sup,
             sinan_demo_server]},
  {registered,[sinan_demo_sup]},
  {applications, [kernel, stdlib]},
  {mod, {sinan_demo_app,[]}},
  {start_phases, []}]}.

Compile with sinan build and hopefully everything works.

From here you’ve got a few options to get your application running, but the easiest is just to use the sinan shell and start your application from there.

1
2
3
4
5
6
7
8
9
10
11
12
13
$ sinan shell
Eshell V5.9.1  (abort with ^G)
1> application:which_applications().
[{parsetools,"XLATETOOLS  CXC 138 xx","2.0.7"},
 {syntax_tools,"Syntax tools","1.6.8"},
 {compiler,"ERTS  CXC 138 10","4.8.1"},
 {getopt,"Command-line options parser for Erlang","0.4.2"},
 {erlware_commons,"Additional standard library for Erlang",
                  "0.6.1"},
 {stdlib,"ERTS  CXC 138 10","1.18.1"},
 {kernel,"ERTS  CXC 138 10","2.15.1"}]
2> application:start(sinan_demo).
ok

We’ve started a shell and checked what applications are started with application:which_applications(). Now start the demo application with:

1
2
3> application:start(sinan_demo).
ok

Now lets test that we can call the application.

1
2
3
4
4> sinan_demo_server:add_one().
{ok,{state,1}}
5> sinan_demo_server:add_one().
{ok,{state,2}}

As you can see it’s calling the server and incrementing the call count.

The next step is to create a release, which is as simple as running sinan release

Sinan has created a number of new directories under _build

1
2
3
4
5
6
7
8
9
10
11
$ tree -d _build/
    _build/
    `-- sinan_demo
        |-- bin
        |-- erts-5.9.1
        |-- lib
        |   |-- kernel-2.15.1
        |   |-- sinan_demo-0.0.1
        |   `-- stdlib-1.18.1
        `-- releases
            `-- 0.0.1

The bin directory is still there from last time but now we have an erts, lib and releases directories. erts is there because earlier we asked sinan to include an erlang runtime, so you can copy everything under _build/sinan_demo to another machine without erlang installed and run this application. The limitation being that the CPU and OS needs to match the machine you’ve built on. lib includes all the applications you asked sinan to include, they’ll match what you have in your collective .app.src files. releases contains configuration files specific to a particular release of the application.

Starting the release generated is as simple as

1
2
3
4
5
6
7
8
9
10
$ ./_build/sinan_demo/bin/sinan_demo
Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]

starting
Eshell V5.9.1  (abort with ^G)
1> application:which_applications().
 [{sinan_demo,"Sinan demo application.","0.0.1"},
  {stdlib,"ERTS  CXC 138 10","1.18.1"},
  {kernel,"ERTS  CXC 138 10","2.15.1"}]
2>

We’ll leave it there for now, but if you’re curious like me you’ll probably have a bunch of questions of where to take sinan next.

Next time I’m going to cover:

But if you’ve got other suggestions please leave them in the comments.

WebMachine Talk

| Comments

I finally posting my slides for the WebMachine talk I gave at ErlSyd.

The content was fairly general WebMachine and REST stuff, going into how to setup, build and structure a WebMachine application.

I’m planning on putting together something more detailed in the future, as the current WebMachine resources are rather spartan. The plan is to do an extended series of posts or a github/ebook site ala learnyousomeerlang.

Again the slides are up on github @ github.com/tmcgilchrist/webmachine_talk/.

Riak, Ruby and Ripple Talk

| Comments

I recently presented a talk to RoRo Sydney, the local Ruby UG, on Riak and Ripple.

The content was more on the general side of things, with my purpose being to introduce the core Riak ideas and give some Ruby code for interacting with Riak.

The slides are up on github @ github.com/tmcgilchrist/riak_ripple_talk/.

Git Rebase Workflow

| Comments

New gist for using a rebase workflow with git.

Again probably not interesting to everyone but it gives the bare bones of what you need to do.

Thoughts on GNU Hurd

| Comments

After reading a recent article about GNU Hurd on hacker news I’m struck by the thought that GNUs development of Hurd is a perfect example of a failed software project.

There was an initial great idea to build a microkernel based OS with all these cool features. But what crippled the project was a combination of:

Despite all this the idea of a Hurd system is still attractive to many and personally I look upon it with some nostalgia. I was completely obsessed by operating systems and coding them around 2000.

I’d love to see a successful Hurd project running on something like L4. But would such a system gain enough interest in the current open source environment. If Hurd was available before Linux it seems like it would have taken off and they could have rode the wave of open source enthusiasm. Now it seems to me that the space is pretty full and a new os has little opportunity to gain real market share. Surely Linux and *BSDs are good enough for people interested in a Hurd system.

Anyway this is all irrelevant until they have something working that people can run, even in a limited sense. Debian has a port but it seems progress is slow.

Why people dont consider gnu projects? Poor public image, it doesn’t appear fun to work on gnu. Look at the buzz around rails for how to manage your public image. Restrictive coding standards and legal hassle.

Original link

Site Update

| Comments

I’ve been rather lax in my updates of late so here is a new site and a status update all rolled into 1.

So a few updates for those interested.

I attended both YOW! and Erlang Factory Lite in Brisbane late last year, and had an absolute blast. Met lots of cool people and got inspired to do more this year. The only downside is I have far too many things I want to do and only limited time.

Went to the YOW! workshop “REST in Practice: A Tutorial on Web-based Distributed Systems” by Jim Webber, and got a great new perspective about RESTful architectures along with some gentle ribbing about the deficiencies of Rails due to me being the only Ruby/Rails guy in attendance.

Shout out to OJ for organising the Erlang Factory Lite. He’s talking at Erlang Factory in San Francisco about Riak, so go along and say hi.

I’ve been wanting to update my blog for a while so I bought a domain name or two and converted the site off Wordpress. For now it’s living on github pages and is very much a work in progress. More updates and features to come.

Other than that I’ve been hard at work on a few Ruby and Erlang projects, and am excited to be attending more Sydney user groups. This month I was at RoRo and there is an Erlang group starting up next month which I’ll be at.

Git and Mercurial Workflow Gist

| Comments

Just added some gist notes on my git and mercurial workflow.

Switching between the two does my head in sometimes.

Probably not that interesting for git or mercurial experts but just something to jog my memory when I have to switch. I’ve got them taped to my desk right beside my note book of Emacs keybindings.

Git & Github Gist

Mercurial Gist