Erlang and Automake

There were some inquiries on the erlang-questions mailing list recently about using Gnu Automake with Erlang. That reminded me to release a build system we've been using for development.

My fascination with build systems predates my obsession with Erlang so it is more general than just Erlang. It is organized around project templates, and there is Erlang project template that has been getting pretty well developed. Every time we figure out a new best practice around Erlang development we incorporate it into the template so that all of our projects benefit. So for instance now we have cover integration, eunit integration, and edoc integration.

It is now available on google code.

New book from Erlang Training

So, the guys Erlang Consulting and Training are making a new book.

and on the erlang-questions mailing list:

On Feb 21, 2008, at 1:50 PM, Francesco Cesarini wrote:
Our main goal is to cover Erlang in depth. Make sure that newbies struggling with recursion can easily understand it or developers being exposed to pattern matching for the first time use it optimally. The contents of the book are pretty much outlined by the introductory Erlang courses Jan-Henry and I have been giving in the last decade, and based on the knowledge and experience gained when teaching. We know [where] students struggle...

On Feb 21, 2008, at 4:29 PM, some guy wrote:
It's just that, no matter how good it is, with Joe's book already out there - it's not going to be a must read for me.

On Feb 21, 2008, at 3:17 PM, someone else wrote:
Another book on just the Erlang programming language would not find a place on my bookshelf.

These responses kind of made me upset.

I applaud Francesco, and Jan-Henry in getting another book out there. Obviously they have learned from their history areas where new comers to erlang have troubles, and they're making a book to plug that hole. They are of course asking you to look back on your experience coming into erlang, think about what concepts you had troubles with and let them know, this would both help confirm the topics for their book, and possibly give them new topics that are perhaps different than they have been exposed to because they come from people
who don't buy erlang training courses.

Just because you don't need the book now doesn't mean you dont' have something to add.

And sure, we all have frustrations about the OTP stuff, it seems like it might be very very good, and then again it seems pretty opaque. I encourage anyone reading this who knows more OTP to publish more stuff about it.

[ I know I'm calling myself RoscoeOTPColtrain, but right now I'm more roscoe than OTP, but perhaps I'll get there. ]

As a scripter in the internet era I've always looked for high level tools that help me build scalable reliable systems as quickly and as error free as possible.

As a manager I've grown to look for tools that help reduce the errors caused by teams of varying skill level trying to make deadlines that have little basis in reality.

I believe erlang is a good fit. As mentioned on erlang questions list It's missing libraries, [ we all should be addressing this. ] it's missing the ability to share code easily amongst the community. [ erlware guys are trying to address this. ] It's missing a lot of depth of documentation especially with respects to OTP.

"see the OTP design principles", is it's own running gag around my office. "Hey, where is the coffee maker?!?" "See the OTP design principles."

Erlang provides some great tools to help regular code monkeys do great things, with less errors. It comes at a cost of learning some interesting programing paradigms which of course seem trivial to elitist programing apes.

So, being a procedural and sometimes OO script monkey for most of my life. [ the joy of programing being denied to me cause I always end up managing. :) ] I found once I bridged the concepts of erlang I totally love it. I feel that there are plenty of others out there who are like me that could also feel the same way.

and last, quoting yarivs "damn, I love pattern matching"

Automatic Node Discovery

One of the first problems we ran into on EC2 was having Erlang nodes find each other. Erlang ships with a node discovery strategy based upon a static hosts file. On EC2, the idea is to start and stop nodes frequently; and EC2 will typically hand out different hostnames each time (I guess that repeats are possible but unlikely). So a static hosts file won't work.

Fortunately Erlang is ready for the set of nodes to change constantly, it is just not spelled out how to find them. I've noticed this about Erlang: often an excellent design is coupled with a simplistic stub implementation. It's the "Tommy" school of software: even the most casual observer is supposed to be able to figure out the next step.

Initially we thought we'd use multicast UDP for discovery, which was extremely easy to do but then we discovered that EC2 does not support multicast. So then I overthought the problem and came up with a discovery protocol based upon using S3 as a blackboard. That worked but was overkill, since just parsing the output of ec2-describe-instances contains all the information needed, plus it allows EC2 security groups to define the Erlang node groups. This is convenient because the EC2 security group(s) can be determined dynamically from the instance metadata.

As an aside, the parsing of the output of ec2-describe-instances is done with a list comprehension and built-in pattern matching only (parse_host_list/2 and parse_host_list/4).

All three strategies are now available on google code. If you're on EC2, ec2nodefinder is the recommendation. Note, you can still in addition use a static hosts file (or any other node discovery strategy), e.g., if you have some non-EC2 hosts you'd like to connect as well.

howdy

we're the dukes. basically 3 guys at a brand new startup (more about that later). we want to have a go with Erlang and EC2 as the two seem to go together pretty nicely. anyway we thought it'd be fun to blog about things as we figure them out, mostly about cloud computing with Erlang, but occasionally maybe about some dramatic startup stuff like not being able to make payroll.

walkenfs on google code

We Dukes are into cloud computing. We especially like our machines to be operationally symmetric so we don't have to think that hard. Erlang makes that easy but unfortunately sometimes we have to deal with software not written in Erlang.

In particular Fess started to put together a monitoring system lately using rrdtool which is great but wants to operate on files. We'd done all this work to make mnesia play nicely on EC2 (more on that later) and suddenly we seemed back at square one. We considered storing data in mnesia and rendering files at the last minute for rrdtool; but then we noticed fuse. Sweet! Now we can store data in mnesia and make it look like a filesystem at the same time.

First we needed Erlang bindings for fuse, so I wrote those. That turned out to involve writing C code, a moderately frustrating experience that served as a nice reminder why we don't call ourselves the "Dukes of C". Once the nasty bits were subdued, writing the actual Erlang code corresponding to a filesystem via mnesia was comparatively quick and painless. I'm still trying to figure out the best way to support posix locking (right now, I'm looking for a satisfying way to have the locks release when an entire node dies unexpectedly), but everything else seems to be working.

It still needs alot of polish. As a filesystem one would expect a mkfs tool and the ability to put entries in /etc/fstab that work. However it's usable as part of an Erlang system right now.