Erlang is a language that has been and is used for various types of applications. Unfortunately many developers don’t feel comfortable with the functional programming paradigm that Erlang is built upon. To help you get started on your way as a to-be Erlang developer here are some tools that may help you:

• why erlang? reasons to use the language and runtime environment for your projects
• Learn you some Erlang (for Gread Good): a very good (and fun) way to learn Erlang
• try-erlang: an in-browser interactive tutorial to Erlang
• edoc: generates HTML documentation from .erl source files, comes with standard distribution
• eunit: unit testing framework, comes with the standard installation of Erlang
• common test: also ships with standard installation
• rebar: a popular build tool for erlang programs developed by Basho
• sinan: an alternative to rebar with a stronger focus on OTP
• kerl: manages installations of Erlang/OTP, like RVM does for Ruby
• EXPM: a package index and manager for Erlang (supersedes agner)
• dialyzer: a static code analysis tool (standard dist)
• meck: a mock library for Erlang, works perfectly with eunit
• lager: a logging framework developed @ Basho, Lager is cool!
• erldocs: a nicer manual than the original docs, you can find it on erldocs.com
• debugger: built-in graphical debugging tool, just start it with debugger:start/0
• observer: a graphical node and application process tree viewer, also built-in, start it with observer:start/0 (supersedes appmon)
• pmon: a built-in graphical process manager, run it with pmon:start/0
• cowboy: a fast and easy to use web server
• et: built-in and easy to use event tracer for Erlang: Using the Event Tracer tool set in Erlang, Making Sense of Erlang’s Event Tracer
• yaws: a high-performance web server primarily suited for dynamic content
• erlang-history: adds history to the erlang shell
• vmstats: monitor Erlang VMs via statsderl
• Elixir: a functional and meta-programming aware language that runs on the Erlang VM
• Web frameworks: a list of web frameworks for Erlang
• Spooky: a RESTful request handler for Erlang
• Erlang Programming Rules

I’ll write separate articles for each of the tools in the future, this post will just be a pointing in the right direction for lost Erlang developers Please, if you know any other helpful tools, don’t hesitate to post it in the comments and I will add them to the list. I know that this is just a very small overview, but these are all tools that helped me get a better Erlang developer, either by using them and/or by reading their code.

Happy Erlang’ing

JS-assessment is a test-driven approach to learn the basics and also some more advanced best practices in JavaScript. You can get it from Github. It runs a small HTTP server on node.js that you will use to run the tests.

All you have to do now is to write some small lines of code, so that the tests will run successfully and show green. The approach will also work perfectly as a coding dojo kata. Repeat it regularly and track your progress.

Definition

First of all, what exactly is a DSL, what does the term domain-specific language stand for? The best way to explain this is by naming the opposite of it, which you already know because you do use it everyday: General-purpose programming languages. Whether it’s PHP, Ruby, C(#), Java, … you can do just about anything with them, that may be developing applications for the web, mobile devices or whatever. But what if you have a specific problem, a problem that has been solved like a thousand times before? For many problems like these, programming languages have been invented that perfectly fit the problem’s domain and make it easy to solve it.

Martin Fowler describes DSLs like that:

Domain-specific language: a computer programming language of limited expressiveness focused on a particular domain.

He further names a distinction between internal and external languages which means:

1. internal DSLs are built in a specific language and work only for that language
2. external languages which then need a full parser in the language you want the DSL to use in

Examples

external DSLs

SQL is an external DSL and it’s domain should be clear to anyone that ever used it: (relational) data. Another example you all should know is Cascading Stylesheets and it’s domain is to style the representation of Markup, mostly used for HTML. Have you ever used a build system like make, rake or ant? These are all external Domain-specific languages which all define a set of commands. Redis (an in-memory database system) and the maintainer of the project, Salvatore Sanfilippo even defined the first of the project’s goals in the Redis manifesto as follows:

A DSL for Abstract Data Types. Redis is a DSL (Domain Specific Language) that manipulates abstract data types and implemented as a TCP daemon.

internal Domain-specific languages

I am pretty shure you already used some of the above examples, but what about internal languages? Have you ever come across one? I am sure you have, here are some examples for you:

Sinatra is a Ruby micro HTTP framework (I already blogged a tutorial series about Sinatra) that defines a set of commands that help you to build more or less simple web applications or REST services. It’s domain is HTTP and if you take a look at it, you will find that it’s pretty close to the HTTP specification. Have you ever heard of Erlang?  It once was an internal DSL at Ericsson, where they used it to build highly concurrent telecommunication applications. Later they open sourced it and now you can use it to build just about anything. It evolved from an internal Domain-specific to a general-purpose language. And JavaScript once has been a DSL to develop interactive web application frontends, but node.js took it out of the browser and made it a general-purpose language.

What can we learn from DSLs when building APIs?

Have a look at the above examples and you’ll notice that they all share a few principles:

• define a rather small set of commands
• ease of use
• just fit the domain’s needs – no more, no less

And I think this essence should also apply if you build an API, no matter if it’s external (say for example a REST interface) or internal. You should always keep it simple and easy to use and don’t confuse the user of your API with domain-unrelated things.

First of all if you don’t know it yet: there are several implementations of Ruby interpreters out there: the best known is MRI (Matz-Ruby-Interpreter), it’s the first implementation and written in C, then there’s Ruby Enterprise Edition, an improved version of the MRI. JRuby runs on the Java Virtual Machine, Rubinius is also written in C, but younger implementation, IronRuby runs on the .NET platform and MacRuby runs, well, only on Macs (who would’ve guessed it?).

Setup rvm

Installing rvm is a simple task, all you have to is that:

bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

This will install rvm in your $HOME directory and you should add the following line to your .bashrc (or in your .zshrc if you use the awesome zsh)

source $HOME/.rvm/scripts/rvm

Installing rubies

Now you have rvm on your system, but you don’t have any Rubies in it. rvm list known will give you a list of all Rubies that are available. Start with installing the default Ruby, type rvm install 1.9.3 followed by rvm default 1.9.3. Now if you do ruby -v, you should see the 1.9.3 version. If not, start a new shell session, the rvm script must be loaded for the session first.

To switch to another Version or platform, you need the use command: rvm use jruby will switch to the latest JRuby version that you installed.

ruby gems

You already may have noticed that all the Rubies are installed in your $HOME directory, in the folder .rvm. All gems that you install will be put in this directory, there’s a gems folder for every Ruby that you installed via rvm there. So you need to install gems for every version that you want to use.

Rvm has a lot of functions that go beyond the scope of the article, you could run rake tasks on multiple Ruby versions in one step, install a gem on multiple platforms, run your unit tests on 1.8.7 and 1.9.3 in one step (rvm 1.8.7,1.9.3 do rake task) and much more.
You should definitely check out the documentation.

Playing around with different interpreters and building libraries that run on many Ruby platforms is fun with that wonderful piece of software. Have fun!

1. daemons are long running processes,
2. they run in the background,
3. you can’t interact with them via a TTY
4. originated from the Unix world
5. a common convention is to put a trailing “d” on their name, e.g. httpd

These are the more obvious attributes of a daemon, but there’s a little more to say especially about 2. Let’s start PHP in the terminal and put the process in the background:

php -a &

Now if you look through the processes on your system with ps -fax | grep php you will see something like that:

The first number is of no interest for us, but the second and the third are. These are the process ID (pid) and the parent process ID (ppid) of our little PHP process. As you can see the parent process is (in my case) 480 and if you do another grep’ing for 480 you can see that this is the shell where you’ve typed php -a & in. What happens if you log off the shell? All child processes of the shell will die, so will your PHP process.

But daemons should not die when a user logs off, they should run forever! If you go the tree of processes up on your system you might find a process that has the ppid 1. It’s the first process that is started when your OS starts and the last one to exit. So we should run our daemon as a child of that process.

Preconditions

Before we can implement our first daemon make sure you have the pcntl extension for PHP installed. Most Unix-based programming languages have the necessary functions implemented in the core, but not PHP. Just search for pcntl in your package manager and install the package.

Our first daemon: mattd

It does nothing, except printing dots to /dev/null, but that shouldn’t matter. It’s a demonstration daemon. Here’s the dump, I’ll go through it and explain what and why we need each line of code in it and what it does:

These are the steps we need to do in the daemon:

1. fork a new child process
2. pcntl_fork() returns two times, the PID of the parent process and with a 0 for the forked child process
3. so there are two ways the code runs from here, one is the parent, the other is the child process (if forking was possible)
4. the parent immediately exits (it’s ppid is the shell you started the daemon from)
5. the child goes in the else branch
6. a daemon has now working directory, so reset it to /
7. close all the file descriptors that are bound to the shell used, that is STDIN/OUT/ERR
8. start a forever-running loop that does something useful

As I said before we need to run our daemon as a child of the pid 1. We can do this by forking and the exiting the parent process. The then new process runs as a child of our php process first but as this process exits, it has no parent anymore.
But having no parent is not possible, so it will get the new ppid 1.

Daemon != Cronjob

Typically, PHP developers are more familiar with developing cronjobs than with daemons and although both are used for similar tasks, they don’t share a common idiom. The main difference is that cronjobs are mostly long-running processes whereas daemons are forever-running processes.

The other thing is that cronjobs are always started in the context of a shell. Daemons don’t run in any context, their parent process ID is always 1, the first process started on the system. You can easily test this: create a small PHP script that has an endless loop in it and put it in your crontab. Now wait until the script gets started and do ps -fax | grep you_cronjob and you’ll see that your cronjob has a PPID other than 1.

That’s it for now …

A short disclaimer to the end: I have not tested this daemon in production nor will I. I am just keen to learn what goes on in the background of Unix programs and I love to share my knowledge to my readers. If I am wrong and you know better, please leave a comment here, thanks