Nine Nines

Ranch 1.3

Mon, 28 Nov 2016 00:00:00 +0100

Ranch 1.3.0 has been released!

This release fixes a number of long standing issues and adds a small number of features:

The ssl application has been added to the list of dependencies. If you don’t need it, you can remove it automatically when fetching Ranch or when building the release. If you do need it, you will no longer have issues shutting down a node because of Ranch.

The ranch:info/0 and ranch:procs/2 can be used to retrieve information about Ranch’s state. Use it for diagnostic and discovery purposes.

SSL listeners can now be configured without a certificate, for setups that make use of the SNI extension.

Transport options are now a blacklist, meaning all unknown options will be accepted. However Dialyzer will warn if said option is not defined in Ranch’s type specifications. Please send a patch when that happens!

Various bugs have been fixed, including the bug where the number of active connections could become negative. Common errors at listener startup should be easier to read (for example when the port is already in use).

See the CHANGELOG for more details.

Ranch is now tested and supported with Erlang/OTP R16B or above on Arch Linux, FreeBSD, OSX, Ubuntu and Windows 7. Contact me if you can provide permanent access to another platform for the purposes of testing.

Ranch is now available from four locations:

They are updated at the same time so there is no real difference.

The most recent Ranch commit is now always signed. You can import the signing key for Loïc Hoguin with:

$ gpg --keyserver hkp://keys.gnupg.net --recv-key 66CCCC8A

The primary key fingerprint is F19F 189C ECC7 4396 99CE DD7A 6EF7 A770 66CC CC8A.

When verifying signatures in git, the following should appear:

gpg: Signature made Sat 26 Nov 2016 12:58:35 PM CET
gpg:                using RSA key 71366FF21851DF03
gpg: Good signature from "Loïc Hoguin <essen@ninenines.eu>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: F19F 189C ECC7 4396 99CE  DD7A 6EF7 A770 66CC CC8A
     Subkey fingerprint: FEDA 6E41 B390 F745 A385  5CDC 7136 6FF2 1851 DF03

You can safely ignore the warning if you don’t know what it means, as long as everything else is correct.

Mirrors and signature verification will soon be implemented directly in Erlang.mk. In the meantime, you will need to set them up manually.

Most of this work was done to fix issues in RabbitMQ. Paid customers get priority; contact me if you have some issues that need fixing sooner rather than later.

Expect future releases to be announced in this space.

Thanks for reading!

Mailing list archived

Mon, 29 Aug 2016 00:00:00 +0100

The old mailing list archives have been added to the site, mainly for referencing purposes.

The mailing list has been shut down and all personal information has been deleted.

If you need help with a project, consider either opening a ticket on that project’s issues tracker or going through the community channels (erlang-questions, #ninenines or #erlang on Freenode).

Prefer tickets; often when people have issues it highlights an underlying problem in the project or its documentation.

Thanks.

Website update

Sat, 02 Apr 2016 00:00:00 +0100

Last week-end I updated the Nine Nines website.

I switched to Hugo. The site is now built from Asciidoc documents. You probably saw me switch to Asciidoc for documentation this past year. This is the natural conclusion to that story. The great thing is that with a little bit of Makefile magic I can just copy the documentation files into Hugo and poof, they appear on the website.

I am very happy with that new setup. I can now post my thoughts again. Woo! Expect regular posts from now on. I will try to replace my long series of tweets with posts.

The sections have been rearranged. There used to be a separate training section; now all my services are described in one page. I have also clarified my areas of expertise. There used to be confusion in the past, so now it should be clearer that I am not a distributed systems expert.

On that note, if you are looking for my services right now, I’m not available. I’ll have to work 7 days a week for a while. Try again in a couple months. More on that in a future post.

The documentation becomes a first class citizen. Bullet and Cowlib don’t have proper documentation… yet. I have started working on the Cowlib documentation, and Bullet shouldn’t take too long. All these projects will be documented when Cowboy gets to 2.0, and will all be supported equally. Note that the Cowboy 1.0 documentation still has the old website templates and links. Don’t worry about it.

The mailing lists link has been removed. I did announce a few months back that mailing lists were going to go. They’re still up right now, but not for long. I am planning to put the archives read-only, link to them from a future post and be done with it. If you have a question, open a ticket on Github. Then I can just decide to leave the ticket open if I want to do improvements based on your feedback.

I have replaced most of the "we" by "I". I am a one-man company right now. Have been for a while. Doesn’t make sense to keep a facade. I want to be close to users, not put a barrier between us.

The RSS changed. The old link doesn’t work anymore. The new link is at /index.xml, or /articles/index.xml if you only care about my posts. I guess that’s the one most people want.

I still have some tweaks to do, but it will take a while. My long term plan is to remove Bootstrap, use vanilla CSS and as little JS as possible. The reason for that is that it’s cheaper than upgrading libraries every few years. Life is too short to spend it upgrading JS libraries.

The Erlanger Playbook September 2015 Update

Wed, 02 Sep 2015 00:00:00 +0100

An update to The Erlanger Playbook is now available!

The Erlanger Playbook is a book about software development using Erlang. It currently covers all areas from the conception, design, the writing of code, documentation and tests.

The book is still a work in progress. Future topics will include refactoring, debugging and tracing, benchmarking, releases, community management (for open source projects).

This update fixes a number of things and adds two chapters: IOlists and Erlang building blocks.

Learn more about The Erlanger Playbook!

This is a self-published ebook. The base price is 50€. All proceeds will be used to allow me to work on open source full time.

Thank you for helping me helping you help us all!

Consulting & Training

Wed, 01 Jul 2015 00:00:00 +0100

If you are interested by any of these opportunities, send me an email.

Consulting

You can get me, Loïc Hoguin, author of Cowboy, to help you solve a problem or work on a particular project.

My area of expertise is Erlang; HTTP, Websocket and REST APIs; design and implementation of protocols; and messaging systems.

I can also be helpful with testing or code reviews.

I offer both hourly and daily rates:

200€ hourly rate (remote)
1000€ daily rate (remote and on-site)

For remote consulting, the work can be done by phone, email, IRC, GitHub and/or any other platform for collaborative work.

For on-site consulting, the travel expenses and accomodations are to be paid by the customer. I will also ask for a higher rate if forced to stay on-site for more than a week.

Note that my expertise does not cover all areas where Erlang is used. My help will be limited in the areas of distributed databases, or large distributed systems.

Sponsoring

You can sponsor one of my projects.

Sponsoring gives you:

a direct, private line of communication
the power to make me maintain older versions of my projects (as long as they are sponsoring)
priority when adding features or fixing bugs
advertisement space on this website and in the README file of the project of your choice

Sponsors may choose to benefit from any of these perks.

In exchange sponsors must contribute financially. A minimum of 200€ per month is required. Sponsors may give as much as they want. Payment can be monthly or one-time. Invoices are of course provided.

Erlang beginner training

I would be happy to introduce more people to Erlang. I have a 1-day Erlang training readily available for consumption. The goal of this training is to teach the basics of Erlang systems and programming. It’s a kind of "Getting started" for Erlang.

You can review the training slides.

This training is meant to be given to a large number of people interested in Erlang, as part of a public event, where anyone interested can come.

Another important aspect of this training is that it is meant to be affordable. We want the most people to learn Erlang as possible.

If you have room, think you can gather 20+ people and are interested in sponsoring a training session, then we should talk.

Custom training

I can also provide custom training, tailored to your level and your needs. It can take the form of a class, Q&A or a code review/writing session. I need to know your expectations to prepare an appropriate training.

Custom training rates are the same as consulting rates and the same restrictions apply.

Documentation

Wed, 01 Jul 2015 00:00:00 +0100

Contribute

Do you have examples, tutorials, videos about one or more of my projects? I would happily include them on this page.

Send me an email with the details.

Donate

Wed, 01 Jul 2015 00:00:00 +0100

Like my work? Donate!

You can donate via Paypal to reward me, Loïc Hoguin, for my work on open source software including Cowboy and Erlang.mk.

Public talks

Wed, 01 Jul 2015 00:00:00 +0100

Talk requests

Organizing a conference and in need of a speaker for a talk about Erlang and the Web? Need an introduction to Erlang/OTP for your company? Looking for a cool subject for a user group meeting?

Send me an email with the details.

Slogan

Wed, 01 Jul 2015 00:00:00 +0100

The Erlanger Playbook is now available!
Buy now — Become a Cowboy project sponsor

The Erlanger Playbook

Thu, 18 Jun 2015 00:00:00 +0100

I am proud to announce the pre-release of The Erlanger Playbook.

The Erlanger Playbook is a book about software development using Erlang. It currently covers all areas from the conception, design, the writing of code, documentation and tests.

The book is still a work in progress. Future topics will include refactoring, debugging and tracing, benchmarking, releases, community management (for open source projects).

The following sections are currently available:

About this book; Future additions
Workflow: Think; Write; Stay productive
Documentation: On documentation; Tutorials; User guide; Manual
Code: Starting a project; Version control; Project structure; Code style; Best practices; Special processes
Tests: On testing; Success typing analysis; Manual testing; Unit testing; Functional testing

Read a preview: Special processes

The book is currently just shy of 100 pages. The final version of the book is planned to be between 200 and 250 pages. A print version of the book will be considered once the final version gets released. The printed book is not included in the price.

This is a self-published book. The base price is 50€. All proceeds will be used to allow me to work on open source full time.

You are more than welcome to pay extra by using this second button. It allows you to set the price you want. Make sure to set it to at least 50€ to receive the book.

Make sure to provide a valid email address.

There will be a delay between payment and sending of the book. This process is currently manual.

As the book is a pre-release, feedback is more than welcome. You can send your comments to erlanger@ this website.

The plan is to add about 20 pages every month until it is completed. You will receive updates to the book for free as soon as they are available.

Huge thanks for your interest in buying this book!

Validating UTF-8 binaries with Erlang

Fri, 06 Mar 2015 00:00:00 +0100

Yesterday I pushed Websocket permessage-deflate to Cowboy master. I also pushed a change in the way the code validates UTF-8 data (required for text and close frames as per the spec).

When looking into why the permessage-deflate tests in autobahntestsuite were taking such a long time, I found that autobahn is using an adaptation of the algorithm named Flexible and Economical UTF-8 Decoder. This is the C99 implementation:

// Copyright (c) 2008-2009 Bjoern Hoehrmann <bjoern@hoehrmann.de>
// See http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ for details.

#define UTF8_ACCEPT 0
#define UTF8_REJECT 1

static const uint8_t utf8d[] = {
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 00..1f
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 20..3f
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 40..5f
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 60..7f
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9, // 80..9f
  7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7, // a0..bf
  8,8,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2, // c0..df
  0xa,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x4,0x3,0x3, // e0..ef
  0xb,0x6,0x6,0x6,0x5,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8, // f0..ff
  0x0,0x1,0x2,0x3,0x5,0x8,0x7,0x1,0x1,0x1,0x4,0x6,0x1,0x1,0x1,0x1, // s0..s0
  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1,1,1,1,1,0,1,0,1,1,1,1,1,1, // s1..s2
  1,2,1,1,1,1,1,2,1,2,1,1,1,1,1,1,1,1,1,1,1,1,1,2,1,1,1,1,1,1,1,1, // s3..s4
  1,2,1,1,1,1,1,1,1,2,1,1,1,1,1,1,1,1,1,1,1,1,1,3,1,3,1,1,1,1,1,1, // s5..s6
  1,3,1,1,1,1,1,3,1,3,1,1,1,1,1,1,1,3,1,1,1,1,1,1,1,1,1,1,1,1,1,1, // s7..s8
};

uint32_t inline
decode(uint32_t* state, uint32_t* codep, uint32_t byte) {
  uint32_t type = utf8d[byte];

  *codep = (*state != UTF8_ACCEPT) ?
    (byte & 0x3fu) | (*codep << 6) :
    (0xff >> type) & (byte);

  *state = utf8d[256 + *state*16 + type];
  return *state;
}

And this is the Erlang implementation I came up with:

%% This function returns 0 on success, 1 on error, and 2..8 on incomplete data.
validate_utf8(<<>>, State) -> State;
validate_utf8(<< C, Rest/bits >>, 0) when C < 128 -> validate_utf8(Rest, 0);
validate_utf8(<< C, Rest/bits >>, 2) when C >= 128, C < 144 -> validate_utf8(Rest, 0);
validate_utf8(<< C, Rest/bits >>, 3) when C >= 128, C < 144 -> validate_utf8(Rest, 2);
validate_utf8(<< C, Rest/bits >>, 5) when C >= 128, C < 144 -> validate_utf8(Rest, 2);
validate_utf8(<< C, Rest/bits >>, 7) when C >= 128, C < 144 -> validate_utf8(Rest, 3);
validate_utf8(<< C, Rest/bits >>, 8) when C >= 128, C < 144 -> validate_utf8(Rest, 3);
validate_utf8(<< C, Rest/bits >>, 2) when C >= 144, C < 160 -> validate_utf8(Rest, 0);
validate_utf8(<< C, Rest/bits >>, 3) when C >= 144, C < 160 -> validate_utf8(Rest, 2);
validate_utf8(<< C, Rest/bits >>, 5) when C >= 144, C < 160 -> validate_utf8(Rest, 2);
validate_utf8(<< C, Rest/bits >>, 6) when C >= 144, C < 160 -> validate_utf8(Rest, 3);
validate_utf8(<< C, Rest/bits >>, 7) when C >= 144, C < 160 -> validate_utf8(Rest, 3);
validate_utf8(<< C, Rest/bits >>, 2) when C >= 160, C < 192 -> validate_utf8(Rest, 0);
validate_utf8(<< C, Rest/bits >>, 3) when C >= 160, C < 192 -> validate_utf8(Rest, 2);
validate_utf8(<< C, Rest/bits >>, 4) when C >= 160, C < 192 -> validate_utf8(Rest, 2);
validate_utf8(<< C, Rest/bits >>, 6) when C >= 160, C < 192 -> validate_utf8(Rest, 3);
validate_utf8(<< C, Rest/bits >>, 7) when C >= 160, C < 192 -> validate_utf8(Rest, 3);
validate_utf8(<< C, Rest/bits >>, 0) when C >= 194, C < 224 -> validate_utf8(Rest, 2);
validate_utf8(<< 224, Rest/bits >>, 0) -> validate_utf8(Rest, 4);
validate_utf8(<< C, Rest/bits >>, 0) when C >= 225, C < 237 -> validate_utf8(Rest, 3);
validate_utf8(<< 237, Rest/bits >>, 0) -> validate_utf8(Rest, 5);
validate_utf8(<< C, Rest/bits >>, 0) when C =:= 238; C =:= 239 -> validate_utf8(Rest, 3);
validate_utf8(<< 240, Rest/bits >>, 0) -> validate_utf8(Rest, 6);
validate_utf8(<< C, Rest/bits >>, 0) when C =:= 241; C =:= 242; C =:= 243 -> validate_utf8(Rest, 7);
validate_utf8(<< 244, Rest/bits >>, 0) -> validate_utf8(Rest, 8);
validate_utf8(_, _) -> 1.

Does it look similar to you? So how did we get there?

I started with a naive implementation of the original. First, we don’t need the codepoint calculated and extracted for our validation function. We just want to know the data is valid, so we only need to calculate the next state. Then, the only thing we needed to be careful about was that tuples are 1-based, and that we need to stop processing the binary when we get the state 1 or when the binary is empty.

validate_utf8(<<>>, State) -> State;
validate_utf8(_, 1) -> 1;
validate_utf8(<< C, Rest/bits >>, State) ->
        validate_utf8(Rest, element(257 + State * 16 + element(1 + C, ?UTF8D), ?UTF8D)).

The macro ?UTF8D is the tuple equivalent of the C array in the original code.

Compared to our previous algorithm, this performed about the same. In some situations a little faster, in some a little slower. In other words, not good enough. But because this new algorithm allows us to avoid a binary concatenation this warranted looking further.

It was time to step into crazy land.

Erlang is very good at pattern matching, even more so than doing some arithmetic coupled by fetching elements from a tuple. So I decided I was going to write all possible clauses for all combinations of C and State. And by write I mean generate.

So I opened my Erlang shell, defined the variable D to be the tuple ?UTF8D with its 400 elements, and then ran the following expression (after a bit of trial and error):

16> file:write_file("out.txt",
        [io_lib:format("validate_utf8(<< ~p, Rest/bits >>, ~p) -> ~p;~n",
                [C, S, element(257 + S * 16 + element(1 + C, D), D)])
                        || C <- lists:seq(0,255), S <- lists:seq(0,8)]).
ok

The result is a 2304 lines long file, containing 2304 clauses. People who pay attention to what I say on Twitter will remember I said something around 3000 clauses, but that was just me not using the right number of states in my estimate.

There was a little more work to be done on this generated code that I did using regular expressions. We need to recurse when the resulting state is not 1. We also need to stop when the binary is empty, making it the 2305th clause.

Still, 2305 is a lot. But hey, the code did work, and faster than the previous implementation too! But hey, perhaps I could find a way to reduce its size.

Removing all the clauses that return 1 and putting a catch-all clause at the end instead reduced the number to about 500, and showed that many clauses were similar:

validate_utf8(<< 0, Rest/bits >>, 0) -> validate_utf8(Rest, 0);
validate_utf8(<< 1, Rest/bits >>, 0) -> validate_utf8(Rest, 0);
validate_utf8(<< 2, Rest/bits >>, 0) -> validate_utf8(Rest, 0);
validate_utf8(<< 3, Rest/bits >>, 0) -> validate_utf8(Rest, 0);
validate_utf8(<< 4, Rest/bits >>, 0) -> validate_utf8(Rest, 0);
validate_utf8(<< 5, Rest/bits >>, 0) -> validate_utf8(Rest, 0);
validate_utf8(<< 6, Rest/bits >>, 0) -> validate_utf8(Rest, 0);
validate_utf8(<< 7, Rest/bits >>, 0) -> validate_utf8(Rest, 0);

But also:

validate_utf8(<< 157, Rest/bits >>, 2) -> validate_utf8(Rest, 0);
validate_utf8(<< 157, Rest/bits >>, 3) -> validate_utf8(Rest, 2);
validate_utf8(<< 157, Rest/bits >>, 5) -> validate_utf8(Rest, 2);
validate_utf8(<< 157, Rest/bits >>, 6) -> validate_utf8(Rest, 3);
validate_utf8(<< 157, Rest/bits >>, 7) -> validate_utf8(Rest, 3);
validate_utf8(<< 158, Rest/bits >>, 2) -> validate_utf8(Rest, 0);
validate_utf8(<< 158, Rest/bits >>, 3) -> validate_utf8(Rest, 2);
validate_utf8(<< 158, Rest/bits >>, 5) -> validate_utf8(Rest, 2);
validate_utf8(<< 158, Rest/bits >>, 6) -> validate_utf8(Rest, 3);
validate_utf8(<< 158, Rest/bits >>, 7) -> validate_utf8(Rest, 3);

Patterns, my favorites!

A little more time was spent to edit the 500 or so clauses into smaller equivalents, testing that performance was not impacted, and comitting the result.

The patterns above can be found here in the resulting function:

validate_utf8(<< C, Rest/bits >>, 0) when C < 128 -> validate_utf8(Rest, 0);
...
validate_utf8(<< C, Rest/bits >>, 2) when C >= 144, C < 160 -> validate_utf8(Rest, 0);
validate_utf8(<< C, Rest/bits >>, 3) when C >= 144, C < 160 -> validate_utf8(Rest, 2);
validate_utf8(<< C, Rest/bits >>, 5) when C >= 144, C < 160 -> validate_utf8(Rest, 2);
validate_utf8(<< C, Rest/bits >>, 6) when C >= 144, C < 160 -> validate_utf8(Rest, 3);
validate_utf8(<< C, Rest/bits >>, 7) when C >= 144, C < 160 -> validate_utf8(Rest, 3);
...

I hope you enjoyed this post.

On open source

Fri, 05 Sep 2014 00:00:00 +0100

Last week I read a great article on contributing to open source by Alvaro Videla. He makes many great points and I am in agreement with most of it. This made me want to properly explain my point of view with regard to open source and contributions. Unlike most open source evangelism articles I will not talk about ideals or any of that crap, but rather my personal feelings and experience.

I have been doing open source work for quite some time. My very first open source project was a graphics driver for (the very early version of) the PCSX2 emulator. That was more than ten years ago, and there isn’t much left to look at today. This was followed by a PHP framework (started long before Zend Framework was even a thing) and a few other small projects. None of them really took off. It’s alright, that’s pretty much the fate of most open source projects. You spend a lot of work and sweat and get very little in return from others.

This sounds harsh but this is the reality of all open source projects. If you are thinking of building a project and releasing it as open source, you should be prepared for that. This is how most of your projects will feel like. Don’t release a project as open source thinking everyone will pat you on the back and cheer, this won’t happen. In fact if your project is a too small improvement over existing software, what many people will do is say you have NIH syndrome, regardless of the improvement you bring. So you need not to rely on other people in order to get your enjoyment out of building open source software.

In my case I get enjoyment from thinking about problems that need solving. Often times the problems are already solved, but nevermind that, I still think about them and sometimes come up with something I feel is better and then write code for it. Writing code is also fun, but not as fun as using my brain to imagine solutions.

You don’t need thousands of users to do that. So are users worthless to me then? No, of course not. In fact they are an important component: they bring me problems that need solving. So users are very important to me. But that’s not the only reason.

I got lucky that the Cowboy project became popular. And seeing it be this popular, and some of my other projects also do quite well, made me believe I could perhaps work full time on open source. If I can work full time then I can produce better software. What I had one hour to work on before I can now spend a day on, and experiment until I am satisfied. This is very useful because that means I can get it almost right from the beginning, and avoid the million API breaking changes that occured before Cowboy 1.0 was released.

To be able to work full time on open source however, I need money. This is a largely unspoken topic of open source work. The work is never free. You can download the product for free, but someone has to pay for the work itself. Life is unfortunately not free.

Large projects and some lucky people have their work sponsored by their employers. Everyone else has to deal with it differently. In my case I was sponsored for a while by the LeoFS project, but that ended. I also had the Farwest fundraiser, which was a success, although the project stalled after that. (Fear not, as Farwest will make a comeback as a conglomerate of Web development projects in the future.) After that I set up the sponsoring scheme, which I can proudly say today brings in enough money to cover my food and shelter. Great!

This is a start, but it’s of course not enough. Life is a little more than food and shelter, and so I am still looking for sponsors. This is not a very glorious experience, as I am essentially looking for scraps that companies can throw away. Still, if a handful more companies were doing that, not only would I be able to live comfortably, but I would also be able to stop worrying about the future as I could put money on the side for when it gets rough.

A few companies giving me some scrap money so I could live and work independently is by far the most important thing anyone can do to help my projects, including Cowboy. Yes, they’re even more important than code contributions, bug reports and feedback. Because this money gives me the time I need to handle the code contributions, bug reports and feedback.

If Cowboy or another project is a large part of your product or infrastructure, then the best thing you can do is become a sponsor. The second best is opening tickets and/or providing feedback. The third best is providing good code contributions.

I will not expand on the feedback part. Feedback is very important, and even just a high five or a retweet is already good feedback. It’s not very complicated.

I want to expand a little on code contributions however. Not long ago I ran across the term "patch bomb" which means dropping patches and expecting the project maintainers to merge them and maintain them. I receive a lot of patches, and often have to refuse them. Causes for refusal vary. Some patches only benefit the people who submitted them (or a very small number of people). Some patches are not refined enough to be included. Others are out of scope of the project. These are some of the reasons why I refuse patches. Having limited time and resources, I have to focus my efforts on the code used by the larger number of users. I have to prioritize patches from submitters who are reactive and address the issues pointed out. And I have to plainly refuse other patches.

I believe this wraps up my thoughts on open source. Overall I had a great experience, the Erlang community being nice and understanding of the issues at hand in general. And if the money problem could be solved soon, then I would be one of the luckiest and happiest open source developer on Earth.

Think about it the next time you see a donation button or a request for funds or sponsoring. You can considerably improve an open source developer’s life with very little of your company’s money.

The story so far

Sat, 23 Aug 2014 00:00:00 +0100

As I am away from home with little to do (some call this a vacation) I wanted to reflect a little on the story so far, or how I arrived to Erlang and got to where I am now. The raw personal experience. It’ll be an article that’s more about social aspect, communities and marketing a project than technical considerations. As a period piece, it will also allow me to reflect on the evolution of Erlang in recent years.

Once upon a time-- Okay this isn’t a fairy tale. The story begins with a short chapter in 2010. The year 2010 started with a fairly major event in my life: the US servers for the online game I stopped playing a few months before, but was still involved with through its community, were closing. OMG! Someone found a way to log packets and started working on a private server; meanwhile the JP servers were still up. And that’s pretty much it.

Fast forward a few months and it became pretty clear that the private server was going nowhere considering all the drama surrounding it-- which is actually not unusual, but it was more entertaining than average and the technical abilities of people running the project were obviously lacking so I decided to obtain those logged packets and look at things myself. I didn’t want to do a private server yet, I only wanted to take a peek to see how things worked, and perhaps organize some effort to document the protocol.

There was 10GB of logs. I didn’t have an easy to use language to analyze them, and hex editors wouldn’t cut it for most purposes, so I had to look elsewhere. This was a good opportunity to start learning this PHP killer I read about before, which also happens to feature syntax for matching binaries, called Erlang. To be perfectly honest I wouldn’t have touched the logs if I didn’t have the added motivation to play with and learn a new language.

At the time it was pretty hard to learn Erlang. In my experience there was Joe’s book (which I always recommend first as I believe it is the best to learn the Erlang side of things; but falls a little short on OTP), and there was about 5 chapters of LYSE. There were a couple other books I never managed to get into (sorry guys), and there was also a few interesting blogs, some of which I can’t find anymore. Finally the #erlang IRC community was there but I was strictly lurking at the time.

What a difference compared to 4 years later! (That’s today, by the way!) Now we have more books than I can remember, tons of articles covering various aspects of the language and platform, many targeting beginners but a good number of them also about advanced topics. We even have a free online book, LYSE, with more than 30 chapters covering pretty much everything. Needless to say I never finished reading LYSE as it got written slower than I learnt.

Back to 2010. I wrote a parser for the logs, and aggregated those results into one CSV file per packet type so I could open them in Gnumeric and aggregate some more, but manually this time, and draw conclusions on the packet structures. That was pretty easy. Even for a beginner. Anyone can go from zero to that level in a day or two. Then, having mastered binary pattern matching, I wanted to learn some more Erlang, by making this aggregation faster. What I had done before worked, but I wasn’t going to wait forever to process everything sequentially. So I looked and found a project called plists (still exists, but not maintained AFAIK). I downloaded that project and replaced my lists: calls to plists:. Boom. In just a few minutes all logs were processed, and I had learnt something new.

It is particularly interesting to note that the lack of a package manager or index never bothered me. Neither before nor after learning Erlang. My experience with package managers was mostly related to Ubuntu, a little Perl and Python, and PHP’s Pear. Let’s just stay polite and say it was always a terrible experience. So searching on the Web didn’t feel awkward, because even if I used a tool or website I would have ended up doing a search or two anyway. This is in contrast to the package index feature in Erlang.mk, which is meant to simplify specifying dependencies more than anything: DEPS = cowboy. It does not attempt to solve any other problem, and will only attempt to solve one extra problem in the near future, which is the discovery of packages. So expect some kind of website listing packages soon enough.

I want to use this parenthese to also point out that at the time there was a very small number of projects out there, at least compared to today. While you sometimes hear people complain about lack of certain libraries, it is so much better now than it was before! The situation improves very quickly, so much that it’s not going to be that big an issue soon enough.

Wanting to know more about that game’s protocol, in the year 2010, I ended up starting to write more Erlang code to simulate a server and use the server to query the client and see what was happening, documenting the packets and so on. This eventually lead to a larger project implementing more and more until people got their hopes up for a revival of the game, all the while the now competing original server project died in a stream of drama and technical incompetence. Of course, I ended up doing what any good Internet citizen would do, I crushed people’s hopes, but that’s not important to our story. The important part is that before giving up on this project, I not only learnt a good deal of Erlang and a little deal of OTP (which I did not touch until 6 months after I started with Erlang; see the paragraph about learning material above), but I also had an intriguing idea pop into my mind for what would become my greatest success yet.

The giving up part was not easy. Having had financial difficulties all year 2010 and part of 2009, I resolved to travel back to Paris to try and make it. I ended up sleeping in offices for 6 months, being hosted by a shady person, and hearing my fair share of stories about the dark side of business. While there I also worked for another company with someone who would end up becoming another high profile Erlang developer. The situation slowly improved, I started taking part in the #erlang IRC discussions, giving up my status of lurker and, a few months into 2011, started working on the Apache killer project: Cowboy.

This is the part where I probably should get accused of racism and other fun things, but I never did. And I think that speaks lots about the Erlang community. In all my time writing Erlang code, I can count the number of conflicts I had with other people on a single hand. This is the nicest programming community I have ever seen, by far. And the humblest too. The Erlang community feels like Japan. And I love Japan. So I love the Erlang community. I can’t say this enough. This is something that stayed true for all my time using Erlang, and despite the rise of alternative languages that are not Japan the Erlang community has remained very Japan.

The first published version of Cowboy was written in two weeks. A little before those two weeks, during, and a while after, pretty much everything I said on the Internets was that Cowboy was going to be the greatest HTTP server ever, that the other servers were problematic (and just to be clear, Yaws was rarely if ever mentioned, due to being in a perceived different league of "full featured servers" while Cowboy was a "lightweight server"), and that Cowboy will be the best replacement to a Mochiweb or Misultin application. This, alongside a lot of time spent on IRC telling people to use Cowboy when they were asking for an HTTP server to use, probably made me sound very annoying. But it worked, and Cowboy started getting its first users, despite being only a few weeks old. Of course, as soon as I got my very first user, I started claiming Cowboy had "a lot of users".

Looking back today I would definitely find myself annoying, this wasn’t just an idle comment there. For about a year, maybe a little more, all I ever said was that Cowboy was the best. This probably made me a little dumber in the process (as if I wasn’t enough! I know). Being French, I sometimes would also say things quite abruptly. To stay polite, I probably sounded like an asshole. I learnt to stop being so French over time thankfully.

I think what was most important to Cowboy at the time, was three things. First, it felt fresh. It was new, had new ideas, tried to do things differently and followed "new" old best practices (the OTP way-- which was simply too obscure for most people at the time). Second, it had me spending all my time telling people to use it whenever they were looking for an HTTP server. Third, it had me helping people get started with it and guide them all the steps of the way. Mostly because it didn’t have a very good documentation, but still, hand holding does wonders.

To be able to help people every time they had a problem, I did not spend all my days reading IRC. Instead I simply made sure to be notified when someone said cowboy. The same way many people subscribe to alerts when their company is mentioned in the news. Nothing fancy.

Time went on, Cowboy grew, or as some like to say, completely destroyed the competition, and many people eventually moved from Mochiweb and Misultin to Cowboy. And then Roberto Ostinelli stopped Misultin development and told everyone to move to Cowboy. This is the most humble and selfless act I have ever seen in the programming sphere, and I only have one thing to say about it: GG. Thanks for the fish. He left me with the tasks of improving Cowboy examples, documentation and strongly believed that the Misultin interface was more user friendly out of all the servers. So I added many examples, as many lines of documentation as we have of code, and strongly believe that Cowboy 2.0 will be the most user friendly interface out of all servers. But only time will tell.

With the rise of the project and the rise in the number of users, my previous strategy (completely incidental, by the way, and definitely not a well thought out plan to become popular) stopped working. It was taking me too much time. The important aspects slowly drifted. If I wanted to support more users, I would have to spend less time with each individual user. This was actually a hard problem. You basically have to make people understand they can’t just come to you directly when they have a problem, they have to follow proper channels. It becomes less personal, and might be felt like you don’t care about them anymore. You have to hurt some people’s feelings at this point. It is quite unfortunate, and also quite difficult to do. There is some unwritten rule that says early adopters deserve more, but in the real world it never works like this. So I probably hurt some people’s feelings at some point. But that’s okay. Because even if you make sure to be as nice as possible when you tell people to go through proper channels from now on, some people will still get offended. There’s nothing you can do about it.

From that point onward the important points about the project was getting the documentation done, making sure people knew about the proper channels to get help and report issues, etc. Basically making myself less needed. This is quite a contrast with the first days, but I believe Cowboy made that transition successfully.

Not only did I win time by not having to hold hands with everyone all the time (not that I didn’t like it, but you know, the sweat), but I also won time thanks to the increased project popularity. Indeed, the more users you have, the more annoying guys there are to tell people to use your project and that it’s the best and everything. Which is great. At least, it’s great if you don’t pay too much attention to it. Sometimes people will give an advice that is, in your opinion, a bad advice. And that’s okay. Don’t intervene every time someone gives a bad advice, learn to let it go. People will figure it out. You learn by making mistakes, after all. Use this extra time to make sure other people don’t end up giving the same bad advice instead. Fix the code or the documentation that led to this mistake. Slowly improve the project and make sure it doesn’t happen again.

This is my story. So far, anyway.

Cowboy 2.0 and query strings

Wed, 20 Aug 2014 00:00:00 +0100

Now that Cowboy 1.0 is out, I can spend some of my time thinking about Cowboy 2.0 that will be released soon after Erlang/OTP 18.0. This entry discusses the proposed changes to query string handling in Cowboy.

Cowboy 2.0 will respond to user wishes by simplifying the interface of the cowboy_req module. Users want two things: less juggling with the Req variable, and more maps. Maps is the only dynamic key/value data structure in Erlang that we can match directly to extract values, allowing users to greatly simplify their code as they don’t need to call functions to do everything anymore.

Query strings are a good candidate for maps. It’s a list of key/values, so it’s pretty obvious we can win a lot by using maps. However query strings have one difference with maps: they can have duplicate keys.

How are we expected to handle duplicate keys? There’s no standard behavior. It’s up to applications. And looking at what is done in the wild, there’s no de facto standard either. While some ignore duplicate keys (keeping the first or the last they find), others require duplicate keys to end with [] to automatically put the values in a list, or even worse, languages like PHP even allow you to do things like key[something][other] and create a deep structure for it. Finally some allow any key to have duplicates and just gives you lists of key/values.

Cowboy so far had functions to retrieve query string values one value at a time, and if there were duplicates it would return the first it finds. It also has a function returning the entire list with all duplicates, allowing you to filter it to get all of them, and another function that returns the raw query string.

What are duplicates used for? Not that many things actually.

One use of duplicate keys is with HTML forms. It is common practice to give all related checkboxes the same name so you get a list of what’s been checked. When nothing is checked, nothing is sent at all, the key is not in the list.

Another use of duplicate keys is when generating forms. A good example of that would be a form that allows uploading any number of files. When you add a file, client-side code adds another field to the form. Repeat up to a certain limit.

And that’s about it. Of note is that HTML radio elements share the same name too, but only one key/value is sent, so they are not relevant here.

Normally this would be the part where I tell you how we solve this elegantly. But I had doubts. Why? Because there’s no good solutions to solving only this particular problem.

I then stopped thinking about duplicate keys for a minute and started to think about the larger problem.

Query strings are input data. They take a particular form, and may be sent as part of the URI or as part of the request body. We have other kinds of input data. We have headers and cookies and the request body in various forms. We also have path segments in URIs.

What do you do with input data? Well you use it to do something. But there is one thing that you almost always do (and if you don’t, you really should): you validate it and you map it into Erlang terms.

Cowboy left the user take care of validation and conversion into Erlang terms so far. Rather, it left the user take care of it everywhere except one place. Guess where? That’s right, bindings.

If you define routes with bindings then you have the option to provide constraints. Constraints can be used to do two things: validate the data and convert it in a more appropriate term. For example if you use the int constraint, Cowboy will make sure the binding is an integer, and will replace the value with the integer representation so that you can use it directly. In this particular case it not only routes the URI, but also validates and converts the bindings directly.

This is very relevant in the case of our duplicate keys, because if we have a list with duplicates of a key, chances are we want to convert that into a list of Erlang terms, and also make sure that all the elements in this list are expected.

The answer to this particular problem is simple. We need a function that will parse the query string and apply constraints. But this is not all, there is one other problem to be solved.

The other problem is that for the user some keys are mandatory and some are optional. Optional keys include the ones that correspond to HTML checkboxes: if the key for one or more checkbox is missing from the query string, we still want to have an empty list in our map so we can easily match. Matching maps is great, but not so much when values might be missing, so we have to normalize this data a little.

This problem is solved by allowing a default value. If the key is missing and a default exists, set it. If no default exists, then the key was mandatory and we want to crash.

I therefore make a proposal for changing the query string interface to three functions.

The first function already exists, it is cowboy_req:qs(Req) and it returns only the query string binary. No more Req returned.

The second function is a renaming of cowboy_req:qs_vals(Req) to something more explicit: cowboy_req:parse_qs(Req). The new name implies that a parsing operation is done. It was implicit and cached before. It will be explicit and not cached anymore now. Again, no more Req returned.

The third function is the one I mentioned above. I think the interface cowboy_req:match_qs(Req, Fields) is most appropriate. It returns a normalized map that is the same regardless of optional fields being provided with the request, allowing for easy matching. It crashes if something went wrong. Still no Req returned.

I feel that this three function interface provides everything one would need to comfortably write applications. You can get low level and get the query string directly; you can get a list of key/value binaries without any additional processing and do it on your own; or you can get a processed map that contains Erlang terms ready to be used.

I strongly believe that by democratizing the constraints to more than just bindings, but also to query string, cookies and other key/values in Cowboy, we can allow the developer to quickly and easily go from HTTP request to Erlang function calls. The constraints are reusable functions that can serve as guards against unwanted data, providing convenience in the process.

Your handlers will not look like an endless series of calls to get and convert the input data, they will instead be just one call at the beginning followed by the actual application logic, thanks to constraints and maps.

handle(Req, State) ->
    #{name:=Name, email:=Email, choices:=ChoicesList, remember_me:=RememberMe} =
        cowboy_req:match_qs(Req, [
            name, {email, email},
            {choices, fun check_choices/1, []},
            {remember_me, boolean, false}]),
    save_choices(Name, Email, ChoicesList),
    if RememberMe -> create_account(Name, Email); true -> ok end,
    {ok, Req, State}.

check_choices(<<"blue">>) -> {true, blue};
check_choices(<<"red">>) -> {true, red};
check_choices(_) -> false;

(Don’t look too closely at the structure yet.)

As you can see in the above snippet, it becomes really easy to go from query string to values. You can also use the map directly as it is guaranteed to only contain the keys you specified, any extra key is not returned.

This would I believe be a huge step up as we can now focus on writing applications instead of translating HTTP calls. Cowboy can now take care of it.

And to conclude, this also solves our duplicate keys dilemma, as they now automatically become a list of binaries, and this list is then checked against constraints that will fail if they were not expecting a list. And in the example above, it even converts the values to atoms for easier manipulation.

As usual, feedback is more than welcome, and I apologize for the rocky structure of this post as it contains all the thoughts that went into this rather than just the conclusion.

January 2014 status

Tue, 07 Jan 2014 00:00:00 +0100

I will now be regularly writing posts about project status, plans and hopes for the future.

Before that though, there’s one important news to share.

Until a year ago all development was financed through consulting and development services. This worked alright but too much time was spent doing things that didn’t benefit the open source projects. And that didn’t make me happy at all. Because I like being happy I stopped that for the most part and spent the year figuring things out, experimenting and discussing with people about it.

What makes me happy is answering these "what if" questions. Ranch and Cowboy are a direct product of that, as they originate from the "what if we could have a server running different protocols on different ports but all part of the same application?"; Erlang.mk is a bit different: "this works great for me, what if it could become the standard solution for building Erlang applications?".

When I successfully answer the question, this becomes a project that may end up largely benefiting the Erlang community. I love Erlang and I love enabling people to build awesome products based on my projects. It’s a lot more rewarding than activities like consulting where you only help one company at a time. And it’s also a much better use of my time as this has a bigger impact on the community.

The hard part is to figure out how to be able to spend 100% of the time on projects that you basically give away for free, and still be able to afford living.

The immediate solution was getting work sponsored by the LeoFS project. LeoFS is a great distributed file storage that I can only recommend to anyone who needs to store files or large pieces of data. The sponsorship works pretty great, and spurred development of the SPDY code in Cowboy amongst other things, plus a couple upcoming projects done more recently and getting a final touch before release.

It turns out sponsoring works great. So I’m thinking of expanding on it and hopefully get enough sponsoring for fulltime open source development. So I figured out a few things that can give incentive to companies willing to sponsor.

Sponsors can request that a particular version of Cowboy be maintained indefinitely (as long as they’re sponsoring). This means fixes will be backported. This doesn’t include features although I can take requests depending on feasability.

Sponsors can have a direct, private line of communication, useful when they need help debugging or optimizing their product.

Sponsors can get their name associated with one of the project and get a good standing in the community thanks to this. They would be featured in the README of the project which is viewed by hundreds of developers daily.

Sponsors can be listed on this website. I will modify the front page when we get a few more sponsors, they will be featured below the carousel of projects.

Please contact us if you are interested in sponsoring, and say how much you are willing to sponsor. The goal here is only to have enough money to make a living and attend a few conferences. There’s an upper limit in the amount needed per year, so the more sponsors there are the cheaper it becomes to everyone.

The upper limit stems from the new legal entity that will replace the current Nine Nines. This is mostly to lower the legal costs and simplify the administrative stuff and allow me to dedicate all my time on what’s important. From your point of view it’s business as usual.

Now on to project statuses and future works.

Cowboy

Cowboy is getting ready for a 1.0 release. Once multipart support is in, all that’s left is finishing the guide, improving tests and finishing moving code to the cowlib project. I hope everything will be ready around the time R17B is released.

I already dream of some API breaking changes after 1.0, which would essentially become 2.0 when they’re done. An extensive survey will be setup after the 1.0 release to get more information on what people like and don’t like about the API.

And of course, when clients start implementing HTTP/2.0 then we will too.

Ranch

Ranch is also getting close to 1.0. I am currently writing a test suite for upgrades. After that I also would like to write a chaos_monkey test suite and add a getting started chapter to the guide.

Ranch is pretty solid otherwise, it’s hard to foresee new features at this point.

Erlang.mk

I didn’t expect this project to become popular. Glad it did though.

Windows support is planned, but will require GNU Make 4. Thankfully, it’s available at least through cygwin. Make, Git and Erlang will be the only required dependencies because the rest of the external calls will be converted to using Guile, a Scheme included since GNU Make 4. So it is Guile that will download the needed files, magically fill the list of modules in the .app file and so on, allowing us to provide a truly cross-platform solution without losing on the performance we benefit from using Make.

Also note that it is possible to check whether Guile is available so we will be able to fallback to the current code for older systems.

I am also thinking about adding an extra column to the package index, indicating the preferred tag or commit number to be used. This would allow us to skip the individual dep lines entirely if the information in the package index is good enough. And committing that file to your project would be the only thing needed to lock the dependencies. Of course if a dep line is specified this would instead override the file.

Alien Shaman

This is the two-parts project requested by the LeoFS team. This is essentially a "distributed bigwig". I am hoping to have a prototype up in a few days.

Alien is the part that allows writing and enabling probes in your nodes. Probes send events which may get filtered before being forwarded to their destination. The events may be sent to a local process, a remote process, over UDP, TCP or SSL. Events may also be received by a process called a relay, which may be used to group or aggregate data before it is being sent over the network, reducing the footprint overall.

Shaman is the UI for it. It will ultimately be able to display any event as long as it’s configured to do so. Events may be logs, numeric values displayed on graphs updated in real time, lists of items like processes and so on.

Feedback

That’s it for today! There will be another status update once Shaman is out. But for now I have to focus on it.

As always, please send feedback on the projects, this post, the sponsoring idea, anything really! Thanks.