Nine Nines

The elephant in the room

Sun, 26 Mar 2017 00:00:00 +0100

Have you ever tried telling someone why they should use Erlang? You boast the smaller code size, the auto healing mechanisms, the distribution and they seem really excited. They wonder why they never heard about Erlang before. And then you show them what the code looks like. All excitement goes away. The smiles disappear. Their face starts becoming really serious.

You lost them. You know you lost them. They comment on the syntax, or perhaps you do, already admitting defeat. It’s unlike anything they have ever used before. And they will most likely end up not using it.

What about people who already know what the syntax looks like? As soon as you mention Erlang, the topic of the syntax comes in. It’s like nothing else matters.

Perhaps the topic of syntax didn’t come up. But they’re still not going to try Erlang because of it.

You’re probably not having these kinds of interactions at Erlang conferences. This doesn’t happen with people who are already somewhat interested in, or need, the features that Erlang provides. With them the syntax is at worst a minor inconvenience.

This happens because most developers are familiar with syntaxes that look nothing like Erlang. To be clear, I include language features and other concepts like objects as part of "syntax" here. Familiarity is a very important factor to drive adoption.

You can see an example of that in the Elixir world, where the majority of people come from Ruby or already knew and liked Ruby. The 2016 survey tells us that 59% of Elixir developers were using Ruby primarily before. That’s in large part because of the syntax. They will deny it of course and find other reasons. And yet, we don’t see such a strong adoption of Erlang from Ruby developers, before or after Elixir appeared.

Side note: have you ever wondered why the Elixir community is, I quote, much friendlier than the Ruby community? Despite having much of the same people?

Before we continue, let me be clear. I love the Erlang syntax. It is simple and explicit. It is powerful, especially when dealing with binary data. It has very few quirks. It has little to no ambiguity. It’s great. Except for persuading people to use it.

Over the years I have been writing Erlang, I have seen very few people point out that the syntax slows down adoption. We have no problem with it, so why would others? At the same time, people coming to Erlang come to solve a real problem they’re having, so the syntax is fairly secondary. Even if they hate it at first, they know they can solve their problems despite the syntax.

You don’t build a popular product or language by solving people’s problems though. In general you end up solving some problems and creating new problems. No, you build a popular product by convincing people to use it. And you make them stay with your product by making them commit to using it.

Take MongoDB for example. It didn’t become popular by working, or even by being practical. It wasn’t performing its primary function and was losing people’s data. That didn’t stop it from becoming popular. Smart people would knowingly use a database that was losing data. Think about that for a minute.

MongoDB of course had a huge marketing machine, and they focused on that. They helped organize many meetups all over the world, complete with various swag items given for free, including a small handbook about MongoDB. All people had to do was show up.

They didn’t go tell people to look at all the weaknesses their product had. They focused on the strengths. On what would convince people to try it. They would go to meetups, discuss with others, commit to try it (or try it at meetups directly), and by doing so sell MongoDB to themselves.

How do we get people to meetups though? That’d be the first step: you need to catch their attention. I believe MongoDB did this using benchmark results. Ironic isn’t it? MongoDB gets fast benchmark results because they lose data, and this gets everyone to buy into the product.

The key points to remember about this are:

catch people’s attention
show your product’s strengths
make people take a commitment

Once they commit to something, you win. Everyone will not end up ultimately using your product of course, but it’s at the very least become a consideration. It’s on their mind. Their resolve will be stronger when they ultimately try it and inevitably run into issues.

Erlang’s syntax is a weakness. Almost nobody looks at the Erlang syntax and falls in love with it at first sight. No, it takes time to learn it and understand how good it is. You need to sell Erlang to people without showing the Erlang syntax. If you do show it, then you need to hide the parts that feel alien. Function calls are OK. Recursion, not so much. Maps are OK. Records, not.

Avoiding code is not always possible when you try to sell it, especially to developers. You can however prepare them to accept the alien syntax by admitting that the syntax is not perfect before you show it. You can do this while praising it at the same time. For example, "the syntax is a little out there, but it matches the concepts perfectly, it will all make sense when you start learning".

This might not be the best introduction. Someone will need to A/B test it to find the one that gives the best results. But that should give you ideas.

When something terrible happens, mentioning that this isn’t the end of the world before you tell others what happened will soften their reaction. When someone breaks your favorite item and cries over it calling themselves stupid, it’s harder to get mad at them, compared to the same event with no emotional reaction.

Our behavior is largely dependent on what’s at the top of our mind, so it’s up to you to take advantage of this to make your case in the best conditions.

Next time you try to make someone use Erlang, remember that you should aim for getting a spoken commitment out of them, if possible before you show the syntax. If that’s not possible, then prepare them to accept the flaws or the weirdness before they see them.

Don't let it crash

Sun, 22 Jan 2017 00:00:00 +0100

We have a specific mindset when writing Erlang programs. We focus on the normal execution of the program and don’t handle most of the errors that may occur. We sometimes call this normal execution the happy path.

The general pattern behind writing only for the happy path, letting the VM catch errors (writing them to a log for future consumption) and then having a supervisor restart the processes that failed from a clean state, has a name. We call it let it crash; and it drives many of our design decisions.

It’s a really great way to program and the results are fantastic compared to most other programming languages. And yet, let it crash barely convinced anyone that they should use Erlang. Why would that be?

You may already know that Cowboy is capable of handling at least 2 million Websocket connections on a single server. This is in large part thanks to the capabilities of the VM. Still, 2 million is good, much better than most other servers can do.

Cowboy is not just a Websocket server; it’s also an HTTP and HTTP/2 server, and it handles many related features like long polling or the parsing of most request headers.

Can you guess how large the Cowboy codebase is, without looking at the source?

Do make sure you have a clear answer in your mind before you go check.

Good, you are back. Now what were the results? If I am correct, you overestimated the size of Cowboy. Cowboy is in fact about five thousand lines of code. You probably thought it was at least ten thousand. About eighty percent of readers will have overestimated the size of Cowboy. And you did only because I mentioned it can handle millions of Websocket connections.

Numerous studies show this effect. Just mentioning the large number already prepared your mind to think in that direction. Repeating the number made you focus even more on it. Then the question asked for a number, which ended up larger than the reality.

The same effect can be applied to negotiation for example. You generally want to start by giving your offer (and not let the other party initiate) and you want to give a really large number first. You can also prepare your customer by mentioning an even larger number in the previous discussion.

And it’s not just numbers either. An experiment showed that just by looking at an image of clouds, customers of a pillow store were buying pillows more comfortable (and more expensive) than those who didn’t see that image.

This is the power of associations. It is covered in much larger detail in the books Influence and Pre-suasion. I highly recommend reading those and applying what you learn to your daily life. I’m definitely not a professional psychologist so take this post with a grain of salt.

When selling Erlang, whether we are selling it to a customer or trying to convince a developer friend to start using it, we often talk about how Erlang lets you sleep at night, that it is auto healing and always gets fantastic uptimes.

And then we talk about let it crash.

And we describe what it means.

We might as well just say that Erlang crashes a lot and then take the door. It would have the same effect. It doesn’t even stop at programs crashing. You know what else crashes? Cars, planes, trains. Often with disastrous consequences. Is that really the message we want to convey?

They even printed it on a t-shirt! Keep calm and let it crash. It’s the kind of t-shirt you probably shouldn’t wear in an airport, and for good reasons. A few people did, then realized what they were wearing and were not too smug about it.

And yet this is how we sell Erlang.

A better way would be to focus on the positives, of course, but also to make sure that those positives are phrased in a way that prevents bad associations to be formed in people’s minds.

Instead of let it crash, you can say that Erlang has auto healing mechanisms. Healing is a good thing and accurately describes what happens in the system.

Should you need to go into more details, you will probably want to avoid recover from crashes and instead say recover from exceptions. Exceptions are a pretty neutral word and, should you explain what you mean by that, you can talk about exceptions that occur for reasons unrelated to Erlang, like hardware failure or network instability.

The trick is to always use positive words and phrases to describe Erlang, and to use external factors to explain how Erlang deals with failures. Never mention the failures internal to Erlang systems unless you are asked specifically, in which case you can say that the auto healing applies to all exceptions.

The let it crash philosophy is great when learning Erlang or when writing fault-tolerant systems. But it’s not going to convince anyone to use it unless they were already looking for it.

Do you like this post? Tell me on Twitter. I might make more.

Cowboy 2.0 pre-release 4

Tue, 03 Jan 2017 00:00:00 +0100

Cowboy 2.0.0-pre.4 has been released!

This is the new recommended version of Cowboy. While I would not recommend putting it in production just yet, I do recommend you start writing new applications with this Cowboy version.

The most significant changes in the pre-release are:

A new architecture: there now is one process per connection and one process per request. This was done because HTTP/2 allows running requests concurrently.
Stream handlers. Every request, response and data goes through stream handlers. They are meant to replace hooks and more. They will be documented in a future pre-release. Check cowboy_stream and cowboy_stream_h if interested.
Numerous changes to the cowboy_req interface. This is very close to final. Check the manual for what changed.
The Req object is no longer passed in Websocket callbacks.
It is now possible to send frames directly from websocket_init/1.
SPDY support was removed, now that we have HTTP/2.
Update Ranch to 1.3. We still depend on Cowlib master for the time being.
A much improved manual.

The manual received a lot of love. It now has one page per function with a detailed description, arguments list, return value, changelog and examples. It also links to the other relevant manual pages: https://ninenines.eu/docs/en/cowboy/2.0/manual/

I am quite proud of the manual right now. While more improvements can be made, what we have now is way better than before. Feedback for further improvements is welcome!

This is a significant step toward Cowboy 2.0. Almost all the breaking changes are in. A few more pre-releases are planned and will be released on a weekly basis (with exceptions).

Cowboy is now tested and supported with Erlang/OTP 18.0 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.

Cowboy is now available from four locations:

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

Cowboy 2.0 will be released once all the breaking changes are completed and the temporarily removed features are added back.

Thanks for your patience. I know it took a long time.

Half-price on all donations because I need a new hat:

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!

Donate to Loïc Hoguin because his work on Cowboy and Erlang.mk is fantastic:

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

Feeling generous? Love reading?
Crowdfund my salary or buy The Erlanger Playbook

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; Changelog; Future additions
Erlang: Building blocks; Patterns
Workflow: Think; Write; Stay productive
Documentation: On documentation; Tutorials; User guide; Manual; README files
Design: RESTful APIs; Lessons learned
Code: Starting a project; Version control; Project structure; Code style; Best practices; Special processes; IOLists; The process dictionary
Tests: On testing; Success typing analysis; Manual testing; Unit testing; Functional testing
Selling Erlang: On persuasion; Don’t let it crash

Read a preview: Special processes

The book is currently 180 pages long. 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 content regularly until I run out of things to say. 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.