Notes on Erlang QuickCheck - Part 2

Yesterday I had the pleasure of spending a few extra hours with John Hughes. As usual, it has been an impressive learning experience, so I decided - once again - to share some of the highlights from our discussions. We modeled one of our internal Erlang applications, using a Quickcheck statem. The application was relatively small (i.e. <1000 LOC), it offered a pretty straightforward API and its code was already covered by a fair amount of unit tests, with code coverage surpassing 90%. As already happened to someone else, I didn’t expect to find too many bugs, if not in...…

> read more...

Notes on Erlang QuickCheck

A few days ago I had the chance to spend some time with John Hughes, one of the creators of the Erlang Quickcheck. We looked at some of our APIs and went through some of our QuickCheck models. It has been an incredibly helpful learning experience, so I thought to share some of the highlights from our discussions to a broader public.

> read more...

Rebar and the Developer Shell

In some cases (e.g. during development) it is helpful to symlink applications into a release, rather than copying them. I believe relx has a dev-mode option for that. In rebar-based projects, what I end up doing in most of the cases is to add something like this into a Makefile:

> read more...

Welcome to the World of Erlang SSH

I’ve been playing around with the Erlang SSH application lately and I’ve noticed some weird behaviours which I decided to report here for future reference. The general impression that I got from the application - and from its coursins such as crypto, public_key and ssh - is that it does not reflect the usual OTP quality standards and that it should be used with care. Misleading error message on ssh_sftp:start_channel/1 in case of missing shell When starting a SFTP channel towards a system where user does not have a shell (i.e. it has /bin/false or equilvalent assigned in the /etc/passwd...…

> read more...

Skerleton: bootstrap Erlang Projects in Seconds

Every time you create a brand-new Erlang project, some manual steps are required. Most of the times, this means fetching rebar via wget, copying and pasting a rebar.config from a previous project, making a bunch of new directories, creating an empty release, and so on and so forth. To ease the above, I created a simple skeleton project that you can use to bootstrap your new Erlang projects. Here is a quickstart on how to use skerleton. You can find the skerleton source code on GitHub. Create a new project based on skerleton and bootstrap it git clone https://github.com/robertoaloi/skerleton.git my_app...…

> read more...

Killin' them softly (by name)

Sometimes is useful to kill an Erlang node by name. The task involves several manual steps, Here is a little helper which you might find helpful. Remember that if you want to kill all Erlang nodes running on a system rather than a specific one, you can simply do: killall beam.smp …

> read more...