From 92b54aacc0de5446dd5497c39897b0bbff72e626 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Wed, 13 Jun 2018 09:54:12 +0200 Subject: Rebuild using Asciideck --- articles/cowboy-2.0.0-pre.4/index.html | 113 ++------ articles/cowboy-2.0.0-rc.1/index.html | 68 ++--- articles/cowboy-2.0.0-rc.2/index.html | 42 +-- articles/cowboy-2.0.0/index.html | 57 +---- articles/cowboy-2.1.0/index.html | 50 +--- articles/cowboy-2.2.0/index.html | 51 +--- articles/cowboy-2.3.0/index.html | 18 +- articles/cowboy-2.4.0/index.html | 36 +-- articles/cowboy2-qs/index.html | 191 ++++---------- articles/dont-let-it-crash/index.html | 137 ++-------- articles/erlang-scalability/index.html | 155 +++-------- articles/erlang-validate-utf8/index.html | 284 +++++++++------------ articles/erlang.mk-and-relx/index.html | 139 ++++------ .../index.html | 21 +- articles/erlanger-playbook/index.html | 86 ++----- articles/farwest-funded/index.html | 30 +-- articles/gun-1.0.0-rc.1/index.html | 45 +--- articles/index.html | 89 +++---- articles/index.xml | 145 +++++------ articles/january-2014-status/index.html | 165 +++--------- articles/ml-archives/index.html | 16 +- articles/on-open-source/index.html | 135 ++-------- articles/page/2/index.html | 56 ++-- articles/ranch-1.3/index.html | 109 +++----- articles/ranch-ftp/index.html | 279 ++++++++------------ articles/the-elephant-in-the-room/index.html | 158 ++---------- articles/the-story-so-far/index.html | 246 ++---------------- articles/tictactoe/index.html | 109 +++----- articles/website-update/index.html | 68 +---- articles/xerl-0.1-empty-modules/index.html | 183 +++++-------- articles/xerl-0.2-two-modules/index.html | 224 +++++++--------- articles/xerl-0.3-atomic-expressions/index.html | 171 ++++--------- articles/xerl-0.4-expression-separator/index.html | 64 ++--- articles/xerl-0.5-intermediate-module/index.html | 176 +++++-------- 34 files changed, 1183 insertions(+), 2733 deletions(-) (limited to 'articles') diff --git a/articles/cowboy-2.0.0-pre.4/index.html b/articles/cowboy-2.0.0-pre.4/index.html index 57e493e3..4eb8dee9 100644 --- a/articles/cowboy-2.0.0-pre.4/index.html +++ b/articles/cowboy-2.0.0-pre.4/index.html @@ -69,105 +69,44 @@

-

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:

-
-

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:

-
+

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:

+ +

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:

diff --git a/articles/cowboy-2.0.0-rc.1/index.html b/articles/cowboy-2.0.0-rc.1/index.html index 03f722c6..d34de49d 100644 --- a/articles/cowboy-2.0.0-rc.1/index.html +++ b/articles/cowboy-2.0.0-rc.1/index.html @@ -69,62 +69,26 @@

-

Cowboy 2.0.0-rc.1 has been released!

-

This is the new recommended version of Cowboy. -Its API should not change before release. While -you probably should not use it in production yet, -many do successfully. Use at your own risk.

-

The plan is to have a new RC version every couple -weeks until the summer ends or later if there are -still blocking issues open. Only issues that can’t -be fixed without making breaking changes to the -interface may block the release.

-

Numerous changes were made since Cowboy 1.0. The -one most people care about is probably HTTP/2, but -it’s most likely not the only one worthwhile. The -full list of changes (excluding types) can be found -in the user guide chapter -Migrating from Cowboy 1.0 to 2.0.

-

As this is not the full release just yet, please pay -extra attention to details and report anything -suspicious you find.

-

There are still some tests failing. Most of those are -related to standards that are not being followed perfectly -just yet. Some of those will probably not be fixed before -Cowboy 2.0 is released. They are edge cases and should not -prevent interoperability.

-

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/

-

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

-
    -
  • -

    -https://git.ninenines.eu/cowboy.git -

    +

    Cowboy 2.0.0-rc.1 has been released!

    +

    This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk.

    +

    The plan is to have a new RC version every couple weeks until the summer ends or later if there are still blocking issues open. Only issues that can't be fixed without making breaking changes to the interface may block the release.

    +

    Numerous changes were made since Cowboy 1.0. The one most people care about is probably HTTP/2, but it's most likely not the only one worthwhile. The full list of changes (excluding types) can be found in the user guide chapter Migrating from Cowboy 1.0 to 2.0.

    +

    As this is not the full release just yet, please pay extra attention to details and report anything suspicious you find.

    +

    There are still some tests failing. Most of those are related to standards that are not being followed perfectly just yet. Some of those will probably not be fixed before Cowboy 2.0 is released. They are edge cases and should not prevent interoperability.

    +

    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/

    +

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

+ +

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

+ diff --git a/articles/cowboy-2.0.0-rc.2/index.html b/articles/cowboy-2.0.0-rc.2/index.html index 02af2eed..1e009267 100644 --- a/articles/cowboy-2.0.0-rc.2/index.html +++ b/articles/cowboy-2.0.0-rc.2/index.html @@ -69,41 +69,19 @@

-

Cowboy 2.0.0-rc.2 has been released!

-

This is the new recommended version of Cowboy. -Its API should not change before release. While -you probably should not use it in production yet, -many do successfully. Use at your own risk.

-

This new version contains fixes for the following -issues:

-
    -
  • -

    -HTTP/2 server push was using the wrong header - compression context. -

    +

    Cowboy 2.0.0-rc.2 has been released!

    +

    This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk.

    +

    This new version contains fixes for the following issues:

    +
    • HTTP/2 server push was using the wrong header compression context.
      • -
    • -

      -HTTP/2 flow control could end up queueing data - in the wrong order when resuming the sending of - data. -

      +
    • HTTP/2 flow control could end up queueing data in the wrong order when resuming the sending of data.
      • -
    • -

      -The shutdown timeout was not implemented - and request processes could be killed too quickly. -

      +
    • The shutdown timeout was not implemented and request processes could be killed too quickly.
      • -
-

What else is new in Cowboy 2.0? Check the -rc.1 announcement.

-

Please test this new release candidate and provide -feedback! The best place to provide feedback is via -tickets. Do not hesitate to open a ticket or bring -an existing ticket to my attention to get it resolved -before 2.0.

+ +

What else is new in Cowboy 2.0? Check the rc.1 announcement.

+

Please test this new release candidate and provide feedback! The best place to provide feedback is via tickets. Do not hesitate to open a ticket or bring an existing ticket to my attention to get it resolved before 2.0.

+ diff --git a/articles/cowboy-2.0.0/index.html b/articles/cowboy-2.0.0/index.html index 61ef2dae..bd4ee760 100644 --- a/articles/cowboy-2.0.0/index.html +++ b/articles/cowboy-2.0.0/index.html @@ -69,54 +69,25 @@

-

Cowboy 2.0.0 has been released!

-

This is the new stable version of Cowboy. There -are no new releases planned for the 1.x version -of Cowboy.

-

The highlights from the release are:

-
    -
  • -

    -HTTP/2 support! -

    +

    Cowboy 2.0.0 has been released!

    +

    This is the new stable version of Cowboy. There are no new releases planned for the 1.x version of Cowboy.

    +

    The highlights from the release are:

    +
    • HTTP/2 support!
      • -
    • -

      -Websocket compression! -

      +
    • Websocket compression!
      • -
    • -

      -Much simpler, cleaner interface. No more weird - errors just because you discard the Req object. -

      +
    • Much simpler, cleaner interface. No more weird errors just because you discard the Req object.
      • -
    • -

      -A new low-level interface that receives all events - from every set of request and response. This - replaces the awkward hooks from 1.0. -

      +
    • A new low-level interface that receives all events from every set of request and response. This replaces the awkward hooks from 1.0.
      • -
    • -

      -A much more detailed manual ! -

      +
    • A much more detailed manual !
      • -
-

A more complete list of changes can be found in the -migration guide: -Migrating from Cowboy 1.0 to 2.0.

-

There are two planned feature releases after 2.0. -Some features were temporarily removed and will be -added back in 2.1. In 2.2 new features will be added -to allow users to support the gRPC protocol. Full -details in tickets.

-

Feeling good about this release? Send money one-time -or monthly via BountySource. -Thanks in advance!

-

As usual, any feedback is appreciated, and any issues -should be reported by opening a ticket. Thanks!

+ +

A more complete list of changes can be found in the migration guide: Migrating from Cowboy 1.0 to 2.0.

+

There are two planned feature releases after 2.0. Some features were temporarily removed and will be added back in 2.1. In 2.2 new features will be added to allow users to support the gRPC protocol. Full details in tickets.

+

Feeling good about this release? Send money one-time or monthly via BountySource. Thanks in advance!

+

As usual, any feedback is appreciated, and any issues should be reported by opening a ticket. Thanks!

+ diff --git a/articles/cowboy-2.1.0/index.html b/articles/cowboy-2.1.0/index.html index 69036c0e..7246b0c3 100644 --- a/articles/cowboy-2.1.0/index.html +++ b/articles/cowboy-2.1.0/index.html @@ -69,48 +69,22 @@

-

Cowboy 2.1.0 has been released!

-

This release focused on adding features that were temporarily -removed during the 2.0 release process:

-
    -
  • -

    -The client TLS certificate can now be obtained. -

    +

    Cowboy 2.1.0 has been released!

    +

    This release focused on adding features that were temporarily removed during the 2.0 release process:

    +
    • The client TLS certificate can now be obtained.
      • -
    • -

      -The 100 Continue response is now sent automatically - again when necessary. -

      +
    • The 100 Continue response is now sent automatically again when necessary.
      • -
    • -

      -NEW: It is now possible to send informational - responses (1XX) directly from user code via the - cowboy_req:inform/2,3 functions. -

      +
    • NEW: It is now possible to send informational responses (1XX) directly from user code via the cowboy_req:inform/2,3 functions.
      • -
    • -

      -NEW: cowboy_rest handlers can now switch to any - other type of handler from almost any callback. This - is especially useful to switch to cowboy_loop to - stream the request or response body. -

      +
    • NEW: cowboy_rest handlers can now switch to any other type of handler from almost any callback. This is especially useful to switch to cowboy_loop to stream the request or response body.
      • -
-

A number of bugs have also been fixed. A more complete -list of changes can be found in the migration guide: -Migrating from Cowboy 2.0 to 2.1.

-

The next release will see the added support for trailers, -which are necessary for implementing the gRPC protocol.

-

You can donate to this project via -BountySource -because I need to eat snacks when I write code. -Thanks in advance!

-

As usual, any feedback is appreciated, and any issues -should be reported by opening a ticket. Thanks!

+ +

A number of bugs have also been fixed. A more complete list of changes can be found in the migration guide: Migrating from Cowboy 2.0 to 2.1.

+

The next release will see the added support for trailers, which are necessary for implementing the gRPC protocol.

+

You can donate to this project via BountySource because I need to eat snacks when I write code. Thanks in advance!

+

As usual, any feedback is appreciated, and any issues should be reported by opening a ticket. Thanks!

+ diff --git a/articles/cowboy-2.2.0/index.html b/articles/cowboy-2.2.0/index.html index 06608ccc..8272096d 100644 --- a/articles/cowboy-2.2.0/index.html +++ b/articles/cowboy-2.2.0/index.html @@ -69,49 +69,20 @@

-

Cowboy 2.2.0 has been released!

-

This release focused on adding features required for writing -gRPC servers and on completing test suites for the core -HTTP RFCs.

-
    -
  • -

    -The cowboy_req:stream_trailers/2 function has been - added. It terminates the streamed response by adding - some trailer field values. This feature is required - for gRPC. -

    +

    Cowboy 2.2.0 has been released!

    +

    This release focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs.

    +
    • The cowboy_req:stream_trailers/2 function has been added. It terminates the streamed response by adding some trailer field values. This feature is required for gRPC.
      • -
    • -

      -The max_skip_body_length option was added. It controls - how much of the request body we are willing to skip - to get to the next request for HTTP/1.1 keep-alive - connections. -

      +
    • The max_skip_body_length option was added. It controls how much of the request body we are willing to skip to get to the next request for HTTP/1.1 keep-alive connections.
      • -
    • -

      -The CONNECT and TRACE methods have been disabled - entirely. They are currently not implemented and - their behavior is very specific (unlike most other - methods) so it is safer to prevent their use. -

      +
    • The CONNECT and TRACE methods have been disabled entirely. They are currently not implemented and their behavior is very specific (unlike most other methods) so it is safer to prevent their use.
      • -
-

Many bugs have also been fixed. A more complete -list of changes can be found in the migration guide: -Migrating from Cowboy 2.1 to 2.2.

-

The next two releases will tentatively focus on improving -the support for cookies and CORS, but I’m open to suggestions. -If there is a pain point in Cowboy 2.2 I would love to hear -about it.

-

You can donate to this project via -BountySource -because I need to eat snacks when I write code. -Thanks in advance!

-

As usual, any feedback is appreciated, and any issues -should be reported by opening a ticket. Thanks!

+ +

Many bugs have also been fixed. A more complete list of changes can be found in the migration guide: Migrating from Cowboy 2.1 to 2.2.

+

The next two releases will tentatively focus on improving the support for cookies and CORS, but I'm open to suggestions. If there is a pain point in Cowboy 2.2 I would love to hear about it.

+

You can donate to this project via BountySource because I need to eat snacks when I write code. Thanks in advance!

+

As usual, any feedback is appreciated, and any issues should be reported by opening a ticket. Thanks!

+ diff --git a/articles/cowboy-2.3.0/index.html b/articles/cowboy-2.3.0/index.html index 439241cc..91b6e3c3 100644 --- a/articles/cowboy-2.3.0/index.html +++ b/articles/cowboy-2.3.0/index.html @@ -69,18 +69,12 @@

-

Cowboy 2.3.0 has been released!

-

This release focused on adding support for the functions -from the sys module for introspecting Cowboy processes.

-

Many bugs have also been fixed. A more complete -list of changes can be found in the migration guide: -Migrating from Cowboy 2.2 to 2.3.

-

You can donate to this project via -BountySource -because I need to eat snacks when I write code. -Thanks in advance!

-

As usual, feedback is appreciated, and issues -should be reported by opening a ticket. Thanks!

+

Cowboy 2.3.0 has been released!

+

This release focused on adding support for the functions from the sys module for introspecting Cowboy processes.

+

Many bugs have also been fixed. A more complete list of changes can be found in the migration guide: Migrating from Cowboy 2.2 to 2.3.

+

You can donate to this project via BountySource because I need to eat snacks when I write code. Thanks in advance!

+

As usual, feedback is appreciated, and issues should be reported by opening a ticket. Thanks!

+ diff --git a/articles/cowboy-2.4.0/index.html b/articles/cowboy-2.4.0/index.html index cae198b2..2c035ff8 100644 --- a/articles/cowboy-2.4.0/index.html +++ b/articles/cowboy-2.4.0/index.html @@ -69,34 +69,14 @@

-

Cowboy 2.4.0 has been released!

-

Numerous HTTP/2 options have been added to control -the HTTP/2 SETTINGS and general behavior of HTTP/2 -connections. The options for initial window sizes, -maximum frame sizes or compression table sizes -might be of interest for optimizing the performance -of HTTP/2 connections.

-

Experimental support for Websocket over HTTP/2 was -added. Note that browsers do not currently support -it. The only browser with partial support is Google -Chrome 67 (dev build) started with a specific flag. -As a result it’s disabled by default in Cowboy too.

-

All of Cowboy’s RFC7540 tests and all of the h2spec -test suite cases now pass. There are still parts -that are not implemented (the priority mechanisms -for example) and edge cases that are not covered, -however, so the HTTP/2 support can still be improved.

-

A complete -list of changes can be found in the migration guide: -Migrating from Cowboy 2.3 to 2.4.

-

You can donate to this project via -BountySource. -These funds are used to pay for additional servers for -testing. A new server was added this month and allows -me to test with additional Linux distributions Alpine, -CentOS and Debian. Thanks in advance!

-

As usual, feedback is appreciated, and issues or -questions should be sent via Github tickets. Thanks!

+

Cowboy 2.4.0 has been released!

+

Numerous HTTP/2 options have been added to control the HTTP/2 SETTINGS and general behavior of HTTP/2 connections. The options for initial window sizes, maximum frame sizes or compression table sizes might be of interest for optimizing the performance of HTTP/2 connections.

+

Experimental support for Websocket over HTTP/2 was added. Note that browsers do not currently support it. The only browser with partial support is Google Chrome 67 (dev build) started with a specific flag. As a result it's disabled by default in Cowboy too.

+

All of Cowboy's RFC7540 tests and all of the h2spec test suite cases now pass. There are still parts that are not implemented (the priority mechanisms for example) and edge cases that are not covered, however, so the HTTP/2 support can still be improved.

+

A complete list of changes can be found in the migration guide: Migrating from Cowboy 2.3 to 2.4.

+

You can donate to this project via BountySource. These funds are used to pay for additional servers for testing. A new server was added this month and allows me to test with additional Linux distributions Alpine, CentOS and Debian. Thanks in advance!

+

As usual, feedback is appreciated, and issues or questions should be sent via Github tickets. Thanks!

+ diff --git a/articles/cowboy2-qs/index.html b/articles/cowboy2-qs/index.html index d1424cfc..c34acbd9 100644 --- a/articles/cowboy2-qs/index.html +++ b/articles/cowboy2-qs/index.html @@ -69,155 +69,56 @@

-

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}.
+
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.

-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.

diff --git a/articles/dont-let-it-crash/index.html b/articles/dont-let-it-crash/index.html index 53226cc3..95da0f88 100644 --- a/articles/dont-let-it-crash/index.html +++ b/articles/dont-let-it-crash/index.html @@ -69,118 +69,31 @@

-

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.

+

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.

+ diff --git a/articles/erlang-scalability/index.html b/articles/erlang-scalability/index.html index 2df4fd1c..df467034 100644 --- a/articles/erlang-scalability/index.html +++ b/articles/erlang-scalability/index.html @@ -69,140 +69,43 @@

-

I would like to share some experience and theories on -Erlang scalability.

-

This will be in the form of a series of hints, which -may or may not be accompanied with explanations as to why -things are this way, or how they improve or reduce the scalability -of a system. I will try to do my best to avoid giving falsehoods, -even if that means a few things won’t be explained.

-
+

I would like to share some experience and theories on Erlang scalability.

+

This will be in the form of a series of hints, which may or may not be accompanied with explanations as to why things are this way, or how they improve or reduce the scalability of a system. I will try to do my best to avoid giving falsehoods, even if that means a few things won't be explained.

NIFs

-
-

NIFs are considered harmful. I don’t know any single NIF-based -library that I would recommend. That doesn’t mean they should -all be avoided, just that if you’re going to want your system to -scale, you probably shouldn’t use a NIF.

-

A common case for using NIFs is JSON processing. The problem -is that JSON is a highly inefficient data structure (similar -in inefficiency to XML, although perhaps not as bad). If you can -avoid using JSON, you probably should. MessagePack can replace -it in many situations.

-

Long-running NIFs will take over a scheduler and prevent Erlang -from efficiently handling many processes.

-

Short-running NIFs will still confuse the scheduler if they -take more than a few microseconds to run.

-

Threaded NIFs, or the use of the enif_consume_timeslice -might help allievate this problem, but they’re not a silver bullet.

-

And as you already know, a crashing NIF will take down your VM, -destroying any claims you may have at being scalable.

-

Never use a NIF because "C is fast". This is only true in -single-threaded programs.

-
-
-
+

NIFs are considered harmful. I don't know any single NIF-based library that I would recommend. That doesn't mean they should all be avoided, just that if you're going to want your system to scale, you probably shouldn't use a NIF.

+

A common case for using NIFs is JSON processing. The problem is that JSON is a highly inefficient data structure (similar in inefficiency to XML, although perhaps not as bad). If you can avoid using JSON, you probably should. MessagePack can replace it in many situations.

+

Long-running NIFs will take over a scheduler and prevent Erlang from efficiently handling many processes.

+

Short-running NIFs will still confuse the scheduler if they take more than a few microseconds to run.

+

Threaded NIFs, or the use of the enif_consume_timeslice might help allievate this problem, but they're not a silver bullet.

+

And as you already know, a crashing NIF will take down your VM, destroying any claims you may have at being scalable.

+

Never use a NIF because "C is fast". This is only true in single-threaded programs.

BIFs

-
-

BIFs can also be harmful. While they are generally better than -NIFs, they are not perfect and some of them might have harmful -effects on the scheduler.

-

A great example of this is the erlang:decode_packet/3 -BIF, when used for HTTP request or response decoding. Avoiding -its use in Cowboy allowed us to see a big increase in -the number of requests production systems were able to handle, -up to two times the original amount. Incidentally this is something -that is impossible to detect using synthetic benchmarks.

-

BIFs that return immediately are perfectly fine though.

-
-
-
+

BIFs can also be harmful. While they are generally better than NIFs, they are not perfect and some of them might have harmful effects on the scheduler.

+

A great example of this is the erlang:decode_packet/3 BIF, when used for HTTP request or response decoding. Avoiding its use in Cowboy allowed us to see a big increase in the number of requests production systems were able to handle, up to two times the original amount. Incidentally this is something that is impossible to detect using synthetic benchmarks.

+

BIFs that return immediately are perfectly fine though.

Binary strings

-
-

Binary strings use less memory, which means you spend less time -allocating memory compared to list-based strings. They are also -more natural for strings manipulation because they are optimized -for appending (as opposed to prepending for lists).

-

If you can process a binary string using a single match context, -then the code will run incredibly fast. The effects will be much -increased if the code was compiled using HiPE, even if your Erlang -system isn’t compiled natively.

-

Avoid using binary:split or binary:replace -if you can avoid it. They have a certain overhead due to supporting -many options that you probably don’t need for most operations.

-
-
-
+

Binary strings use less memory, which means you spend less time allocating memory compared to list-based strings. They are also more natural for strings manipulation because they are optimized for appending (as opposed to prepending for lists).

+

If you can process a binary string using a single match context, then the code will run incredibly fast. The effects will be much increased if the code was compiled using HiPE, even if your Erlang system isn't compiled natively.

+

Avoid using binary:split or binary:replace if you can avoid it. They have a certain overhead due to supporting many options that you probably don't need for most operations.

Buffering and streaming

-
-

Use binaries. They are great for appending, and it’s a direct copy -from what you receive from a stream (usually a socket or a file).

-

Be careful to not indefinitely receive data, as you might end up -having a single binary taking up huge amounts of memory.

-

If you stream from a socket and know how much data you expect, -then fetch that data in a single recv call.

-

Similarly, if you can use a single send call, then -you should do so, to avoid going back and forth unnecessarily between -your Erlang process and the Erlang port for your socket.

-
-
-
+

Use binaries. They are great for appending, and it's a direct copy from what you receive from a stream (usually a socket or a file).

+

Be careful to not indefinitely receive data, as you might end up having a single binary taking up huge amounts of memory.

+

If you stream from a socket and know how much data you expect, then fetch that data in a single recv call.

+

Similarly, if you can use a single send call, then you should do so, to avoid going back and forth unnecessarily between your Erlang process and the Erlang port for your socket.

List and binary comprehensions

-
-

Prefer list comprehensions over lists:map/2. The -compiler will be able to optimize your code greatly, for example -not creating the result if you don’t need it. As time goes on, -more optimizations will be added to the compiler and you will -automatically benefit from them.

-
-
-
+

Prefer list comprehensions over lists:map/2. The compiler will be able to optimize your code greatly, for example not creating the result if you don't need it. As time goes on, more optimizations will be added to the compiler and you will automatically benefit from them.

gen_server is no silver bullet

-
-

It’s a bad idea to use gen_server for everything. -For two reasons.

-

There is an overhead everytime the gen_server receives -a call, a cast or a simple message. It can be a problem if your -gen_server is in a critical code path where speed -is all that matters. Do not hesitate to create other kinds of -processes where it makes sense. And depending on the kind of process, -you might want to consider making them special processes, which -would essentially behave the same as a gen_server.

-

A common mistake is to have a unique gen_server to -handle queries from many processes. This generally becomes the -biggest bottleneck you’ll want to fix. You should try to avoid -relying on a single process, using a pool if you can.

-
-
-
+

It's a bad idea to use gen_server for everything. For two reasons.

+

There is an overhead everytime the gen_server receives a call, a cast or a simple message. It can be a problem if your gen_server is in a critical code path where speed is all that matters. Do not hesitate to create other kinds of processes where it makes sense. And depending on the kind of process, you might want to consider making them special processes, which would essentially behave the same as a gen_server.

+

A common mistake is to have a unique gen_server to handle queries from many processes. This generally becomes the biggest bottleneck you'll want to fix. You should try to avoid relying on a single process, using a pool if you can.

Supervisor and monitoring

-
-

A supervisor is also a gen_server, -so the previous points also apply to them.

-

Sometimes you’re in a situation where you have supervised -processes but also want to monitor them in one or more other -processes, effectively duplicating the work. The supervisor -already knows when processes die, why not use this to our -advantage?

-

You can create a custom supervisor process that will perform -both the supervision and handle exit and other events, allowing -to avoid the combination of supervising and monitoring which -can prove harmful when many processes die at once, or when you -have many short lived processes.

-
-
-
+

A supervisor is also a gen_server, so the previous points also apply to them.

+

Sometimes you're in a situation where you have supervised processes but also want to monitor them in one or more other processes, effectively duplicating the work. The supervisor already knows when processes die, why not use this to our advantage?

+

You can create a custom supervisor process that will perform both the supervision and handle exit and other events, allowing to avoid the combination of supervising and monitoring which can prove harmful when many processes die at once, or when you have many short lived processes.

ets for LOLSPEED(tm)

-
-

If you have data queried or modified by many processes, then -ets public or protected tables will give you the -performance boost you require. Do not forget to set the -read_concurrency or write_concurrency -options though.

-

You might also be thrilled to know that Erlang R16B will feature -a big performance improvement for accessing ets tables -concurrently.

-
-
+

If you have data queried or modified by many processes, then ets public or protected tables will give you the performance boost you require. Do not forget to set the read_concurrency or write_concurrency options though.

+

You might also be thrilled to know that Erlang R16B will feature a big performance improvement for accessing ets tables concurrently.

+ diff --git a/articles/erlang-validate-utf8/index.html b/articles/erlang-validate-utf8/index.html index e8abf3a7..48df613b 100644 --- a/articles/erlang-validate-utf8/index.html +++ b/articles/erlang-validate-utf8/index.html @@ -69,191 +69,159 @@

-

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.
+
// 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
+#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
-};
+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];
+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);
+  *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.

+
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.

+ diff --git a/articles/erlang.mk-and-relx/index.html b/articles/erlang.mk-and-relx/index.html index 4309e0a3..a124ca18 100644 --- a/articles/erlang.mk-and-relx/index.html +++ b/articles/erlang.mk-and-relx/index.html @@ -69,118 +69,69 @@

-

Building OTP releases has always been a difficult task. Tools like -Reltool or Rebar have made this simpler, but -it’s no panacea. This article will show you an alternative and -hopefully much simpler solution.

-

There is two steps to building a release. First you need to build -the various OTP applications you want to include in the release. Once -done, you need to create the release itself, by including the Erlang -runtime system alongside the applications, a boot script to start the -node and all its applications, and some configuration files.

-

Erlang.mk solves -the first step. It is an include file for GNU Make. Just -including it in a Makefile is enough to allow building your project, -fetching and building dependencies, building documentation, performing -static analysis and more.

-

Relx solves the second -step. It is a release creation tool, wrapped into a single executable -file. It doesn’t require a configuration file. And if you do need one, -it will be a pretty small one.

-

Let’s take a look at the smallest Erlang.mk powered -Makefile. There is only one thing required: defining the project -name.

-
-
-
PROJECT = my_project
+
PROJECT = my_project
 
-include erlang.mk
-

Simply doing this allows you to build your application by typing -make, running tests using make tests, and -more. It will even compile your .dtl files found in the -templates/ directory if you are using ErlyDTL!

-

Let’s now take a look at a simplified version of the Makefile for -this website. I only removed a few targets that were off-topic.

-
-
-
PROJECT = ninenines
+
PROJECT = ninenines
 
-DEPS = cowboy erlydtl
-dep_cowboy_commit = 0.8.5
-dep_erlydtl_commit = 4d0dc8fb
+DEPS = cowboy erlydtl
+dep_cowboy_commit = 0.8.5
+dep_erlydtl_commit = 4d0dc8fb
 
-.PHONY: release clean-release
+.PHONY: release clean-release
 
-release: clean-release all projects
-        relx -o rel/$(PROJECT)
+release: clean-release all projects
+	relx -o rel/$(PROJECT)
 
-clean-release: clean-projects
-        rm -rf rel/$(PROJECT)
+clean-release: clean-projects
+	rm -rf rel/$(PROJECT)
 
-include erlang.mk
-

You can see here how to define dependencies. First you list all -the dependency names, then you have one line per dependency, giving -the repository URL and the commit number, tag or branch you want.

-

Then you can see two targets defined, with release -becoming the default target, because it was defined first. You can -override the default target all, which builds the -application and its dependencies, this way.

-

And as you can see, the release target uses -Relx to build a release into the rel/ninenines/ -directory. Let’s take a look at the configuration file for this release.

-
-
-
{release, {ninenines, "1"}, [ninenines]}.
+
{release, {ninenines, "1"}, [ninenines]}.
 
-{extended_start_script, true}.
-{sys_config, "rel/sys.config"}.
+{extended_start_script, true}.
+{sys_config, "rel/sys.config"}.
 
-{overlay, [
-        {mkdir, "log"},
-        {copy, "rel/vm.args",
-                "releases/\{\{release_name\}\}-\{\{release_version\}\}/vm.args"}
-]}.
-

The first line defines a release named ninenines, which -has a version number "1" and includes one application, also -named ninenines, although it doesn’t have to.

-

We then use the extended_start_script option to tell -Relx that we would like to have a start script that allows -us to not only start the release, but do so with the node in the -background, or also to allow us to connect to a running node, and so on. -This start script has the same features as the one tools like -Rebar generates.

-

The rest of the file just makes sure our configuration files are -where we expect them. Relx will automatically take care -of your sys.config file as long as you tell it where to -find it. The vm.args file used by the extended start script -needs to be handled more explicitly by using an overlay however.

-

How does Relx find what applications to include? -By looking at the application dependencies in the .app -file of each OTP application. Make sure you put all dependencies in -there, including library applications, and Relx -will find everything for you.

-

For example, this release includes the following applications. -Only what’s strictly required.

-
-
-
compiler-4.9.1  crypto-2.3     kernel-2.16.1    ranch-0.8.3    syntax_tools-1.6.11
-cowboy-0.8.5    erlydtl-0.7.0  ninenines-0.2.0  stdlib-1.19.1
+{overlay, [ + {mkdir, "log"}, + {copy, "rel/vm.args", + "releases/\{\{release_name\}\}-\{\{release_version\}\}/vm.args"} +]}.
-

The sys.config file is standard and -well documented. -The vm.args file is just an optionally multiline file -containing all the flags to pass to the Erlang VM, for example --name ninenines@127.0.0.1 -heart.

-

Building OTP releases has always been a difficult task. Until now.

+

The first line defines a release named ninenines, which has a version number "1" and includes one application, also named ninenines, although it doesn't have to.

+

We then use the extended_start_script option to tell Relx that we would like to have a start script that allows us to not only start the release, but do so with the node in the background, or also to allow us to connect to a running node, and so on. This start script has the same features as the one tools like Rebar generates.

+

The rest of the file just makes sure our configuration files are where we expect them. Relx will automatically take care of your sys.config file as long as you tell it where to find it. The vm.args file used by the extended start script needs to be handled more explicitly by using an overlay however.

+

How does Relx find what applications to include? By looking at the application dependencies in the .app file of each OTP application. Make sure you put all dependencies in there, including library applications, and Relx will find everything for you.

+

For example, this release includes the following applications. Only what's strictly required.

+
compiler-4.9.1	crypto-2.3     kernel-2.16.1	ranch-0.8.3    syntax_tools-1.6.11
+cowboy-0.8.5	erlydtl-0.7.0  ninenines-0.2.0	stdlib-1.19.1
+

The sys.config file is standard and well documented. The vm.args file is just an optionally multiline file containing all the flags to pass to the Erlang VM, for example -name ninenines@127.0.0.1 -heart.

+

Building OTP releases has always been a difficult task. Until now.

+ diff --git a/articles/erlanger-playbook-september-2015-update/index.html b/articles/erlanger-playbook-september-2015-update/index.html index 4aa732b7..54949c1b 100644 --- a/articles/erlanger-playbook-september-2015-update/index.html +++ b/articles/erlanger-playbook-september-2015-update/index.html @@ -69,19 +69,14 @@

-

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!

+

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!

+ diff --git a/articles/erlanger-playbook/index.html b/articles/erlanger-playbook/index.html index 490f06e5..c02c7fc9 100644 --- a/articles/erlanger-playbook/index.html +++ b/articles/erlanger-playbook/index.html @@ -69,87 +69,47 @@

-

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 -

    +

    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 -

      +
    • Erlang: Building blocks; Patterns
      • -
    • -

      -Workflow: Think; Write; Stay productive -

      +
    • Workflow: Think; Write; Stay productive
      • -
    • -

      -Documentation: On documentation; Tutorials; User guide; Manual; README files -

      +
    • Documentation: On documentation; Tutorials; User guide; Manual; README files
      • -
    • -

      -Design: RESTful APIs; Lessons learned -

      +
    • Design: RESTful APIs; Lessons learned
      • -
    • -

      -Code: Starting a project; Version control; Project structure; Code style; Best practices; Special processes; IOLists; The process dictionary -

      +
    • 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 -

      +
    • Tests: On testing; Success typing analysis; Manual testing; Unit testing; Functional testing
      • -
    • -

      -Selling Erlang: On persuasion; Don’t let it crash -

      +
    • 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.

+ +

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.

+

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!

+

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!

+ diff --git a/articles/farwest-funded/index.html b/articles/farwest-funded/index.html index 584858a2..2a60af86 100644 --- a/articles/farwest-funded/index.html +++ b/articles/farwest-funded/index.html @@ -69,27 +69,15 @@

-

This was a triumph! I’m making a note here: HUGE SUCCESS!!

- -

It’s hard to overstate my satisfaction. Thanks to everyone who -made this possible.

-

If you have backed this fundraiser, and haven’t provided your -personal details yet, please do so quickly so that your rewards -can be sent!

-

I am hoping that we will be able to make good use of all that -money. The details of the expenses will be published regularly -on the 2013 Fundraiser wiki page, -giving you full disclosure as to how your money is used.

-

It will take a little time to get things started, we are in -summer after all! We will however act quickly to make the -prototype easy enough to use so that the paid UI work can -begin. This is also when user contributions will be welcome.

-

You can see the Roadmap -to get more information on the current plans. This document will -get updated as time goes on so check again later to see if you -can help!

-

Look at me: still talking when there’s open source to do!

-

Thanks again for all your support. I really appreciate it.

+

This was a triumph! I'm making a note here: HUGE SUCCESS!!

+

It's hard to overstate my satisfaction. Thanks to everyone who made this possible.

+

If you have backed this fundraiser, and haven't provided your personal details yet, please do so quickly so that your rewards can be sent!

+

I am hoping that we will be able to make good use of all that money. The details of the expenses will be published regularly on the 2013 Fundraiser wiki page, giving you full disclosure as to how your money is used.

+

It will take a little time to get things started, we are in summer after all! We will however act quickly to make the prototype easy enough to use so that the paid UI work can begin. This is also when user contributions will be welcome.

+

You can see the Roadmap to get more information on the current plans. This document will get updated as time goes on so check again later to see if you can help!

+

Look at me: still talking when there's open source to do!

+

Thanks again for all your support. I really appreciate it.

+ diff --git a/articles/gun-1.0.0-rc.1/index.html b/articles/gun-1.0.0-rc.1/index.html index f0b4664b..9521c7ea 100644 --- a/articles/gun-1.0.0-rc.1/index.html +++ b/articles/gun-1.0.0-rc.1/index.html @@ -69,41 +69,16 @@

-

Gun 1.0.0-rc.1 has been released!

-

Gun is an HTTP/1.1, HTTP/2 and Websocket client -for Erlang/OTP.

-

Gun provides an asynchronous interface and will -keep the connection open to the server, reconnecting -as necessary.

-

Gun has existed for many years as the test client -for Cowboy and is now mature enough to receive a -proper version. Gun is battle tested by customers -and other users but is not the most well tested -client there is.

-

This release candidate differs from previous tags -in the way Websocket-related messages are handled: -the gun_ws_upgrade message is now gun_upgrade, -and the gun_ws message has an extra element. The -dependency on Ranch has also been removed. In -addition some undocumented features have been -modified; they will be documented in future -releases.

-

I have given the Cowboy treatment to the Gun manual: -a separate page per function call with all kind -of useful information, including examples. Since -Gun provides an asynchronous interface, each message -also has a separate manual page. Check it out: -https://ninenines.eu/docs/en/gun/1.0/manual/

-

Gun 1.0 will be released once customers projects -are updated and I confirm everything works as intended.

-

You can donate to this project via -BountySource. -These funds are used to pay for additional servers for -testing. A new server was added last month and allows -me to test with additional Linux distributions Alpine, -CentOS and Debian. Thanks in advance!

-

As usual, feedback is appreciated, and issues or -questions should be sent via Github tickets. Thanks!

+

Gun 1.0.0-rc.1 has been released!

+

Gun is an HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP.

+

Gun provides an asynchronous interface and will keep the connection open to the server, reconnecting as necessary.

+

Gun has existed for many years as the test client for Cowboy and is now mature enough to receive a proper version. Gun is battle tested by customers and other users but is not the most well tested client there is.

+

This release candidate differs from previous tags in the way Websocket-related messages are handled: the gun_ws_upgrade message is now gun_upgrade, and the gun_ws message has an extra element. The dependency on Ranch has also been removed. In addition some undocumented features have been modified; they will be documented in future releases.

+

I have given the Cowboy treatment to the Gun manual: a separate page per function call with all kind of useful information, including examples. Since Gun provides an asynchronous interface, each message also has a separate manual page. Check it out: https://ninenines.eu/docs/en/gun/1.0/manual/

+

Gun 1.0 will be released once customers projects are updated and I confirm everything works as intended.

+

You can donate to this project via BountySource. These funds are used to pay for additional servers for testing. A new server was added last month and allows me to test with additional Linux distributions Alpine, CentOS and Debian. Thanks in advance!

+

As usual, feedback is appreciated, and issues or questions should be sent via Github tickets. Thanks!

+ diff --git a/articles/index.html b/articles/index.html index 4df97ede..b3128c02 100644 --- a/articles/index.html +++ b/articles/index.html @@ -75,9 +75,9 @@

Gun 1.0.0-rc.1 has been released! - Gun is an HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP. - Gun provides an asynchronous interface and will keep the connection open to the server, reconnecting as necessary. - Gun has existed for many years as the test client for Cowboy and is now mature enough to receive a proper version. Gun is battle tested by customers and other users but is not the most well tested client there is.

+Gun is an HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP. +Gun provides an asynchronous interface and will keep the connection open to the server, reconnecting as necessary. +Gun has existed for many years as the test client for Cowboy and is now mature enough to receive a proper version. Gun is battle tested by customers and other users but is not the most well tested client there is.

Read More @@ -94,8 +94,8 @@

Cowboy 2.4.0 has been released! - Numerous HTTP/2 options have been added to control the HTTP/2 SETTINGS and general behavior of HTTP/2 connections. The options for initial window sizes, maximum frame sizes or compression table sizes might be of interest for optimizing the performance of HTTP/2 connections. - Experimental support for Websocket over HTTP/2 was added. Note that browsers do not currently support it. The only browser with partial support is Google Chrome 67 (dev build) started with a specific flag.

+Numerous HTTP/2 options have been added to control the HTTP/2 SETTINGS and general behavior of HTTP/2 connections. The options for initial window sizes, maximum frame sizes or compression table sizes might be of interest for optimizing the performance of HTTP/2 connections. +Experimental support for Websocket over HTTP/2 was added. Note that browsers do not currently support it. The only browser with partial support is Google Chrome 67 (dev build) started with a specific flag.

Read More @@ -112,9 +112,10 @@

Cowboy 2.3.0 has been released! - This release focused on adding support for the functions from the sys module for introspecting Cowboy processes. - Many bugs have also been fixed. A more complete list of changes can be found in the migration guide: Migrating from Cowboy 2.2 to 2.3. - You can donate to this project via BountySource because I need to eat snacks when I write code. Thanks in advance!

+This release focused on adding support for the functions from the sys module for introspecting Cowboy processes. +Many bugs have also been fixed. A more complete list of changes can be found in the migration guide: Migrating from Cowboy 2.2 to 2.3. +You can donate to this project via BountySource because I need to eat snacks when I write code. Thanks in advance! +As usual, feedback is appreciated, and issues should be reported by opening a ticket.

Read More @@ -131,8 +132,8 @@

Cowboy 2.2.0 has been released! - This release focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs. - The cowboy_req:stream_trailers/2 function has been added. It terminates the streamed response by adding some trailer field values. This feature is required for gRPC. The max_skip_body_length option was added. It controls how much of the request body we are willing to skip to get to the next request for HTTP/1.

+This release focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs. +The cowboy_req:stream_trailers/2 function has been added. It terminates the streamed response by adding some trailer field values. This feature is required for gRPC. The max_skip_body_length option was added. It controls how much of the request body we are willing to skip to get to the next request for HTTP/1.

Read More @@ -149,8 +150,8 @@

Cowboy 2.1.0 has been released! - This release focused on adding features that were temporarily removed during the 2.0 release process: - The client TLS certificate can now be obtained. The 100 Continue response is now sent automatically again when necessary. NEW: It is now possible to send informational responses (1XX) directly from user code via the cowboy_req:inform/2,3 functions. NEW: cowboy_rest handlers can now switch to any other type of handler from almost any callback.

+This release focused on adding features that were temporarily removed during the 2.0 release process: +The client TLS certificate can now be obtained. The 100 Continue response is now sent automatically again when necessary. NEW: It is now possible to send informational responses (1XX) directly from user code via the cowboy_req:inform/2,3 functions. NEW: cowboy_rest handlers can now switch to any other type of handler from almost any callback.

Read More @@ -167,9 +168,9 @@

Cowboy 2.0.0 has been released! - This is the new stable version of Cowboy. There are no new releases planned for the 1.x version of Cowboy. - The highlights from the release are: - HTTP/2 support! Websocket compression! Much simpler, cleaner interface. No more weird errors just because you discard the Req object. A new low-level interface that receives all events from every set of request and response.

+This is the new stable version of Cowboy. There are no new releases planned for the 1.x version of Cowboy. +The highlights from the release are: +HTTP/2 support! Websocket compression! Much simpler, cleaner interface. No more weird errors just because you discard the Req object. A new low-level interface that receives all events from every set of request and response. This replaces the awkward hooks from 1.

Read More @@ -186,9 +187,9 @@

Cowboy 2.0.0-rc.2 has been released! - This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. - This new version contains fixes for the following issues: - HTTP/2 server push was using the wrong header compression context. HTTP/2 flow control could end up queueing data in the wrong order when resuming the sending of data.

+This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. +This new version contains fixes for the following issues: +HTTP/2 server push was using the wrong header compression context. HTTP/2 flow control could end up queueing data in the wrong order when resuming the sending of data.

Read More @@ -205,8 +206,8 @@

Cowboy 2.0.0-rc.1 has been released! - This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. - The plan is to have a new RC version every couple weeks until the summer ends or later if there are still blocking issues open. Only issues that can’t be fixed without making breaking changes to the interface may block the release.

+This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. +The plan is to have a new RC version every couple weeks until the summer ends or later if there are still blocking issues open. Only issues that can't be fixed without making breaking changes to the interface may block the release.

Read More @@ -223,7 +224,7 @@

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.

+You lost them. You know you lost them. They comment on the syntax, or perhaps you do, already admitting defeat.

Read More @@ -239,8 +240,8 @@

-

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 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.

Read More @@ -257,9 +258,9 @@

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.

+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.

Read More @@ -276,8 +277,9 @@

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.

+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.

Read More @@ -294,9 +296,9 @@

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.

+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.

Read More @@ -313,8 +315,8 @@

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 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.

Read More @@ -331,9 +333,9 @@

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.

+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.

Read More @@ -350,9 +352,10 @@

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:

+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

Read More @@ -369,8 +372,8 @@

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.

+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.

Read More @@ -402,7 +405,7 @@

-

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.

+

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.

Read More @@ -419,7 +422,7 @@

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.

+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.

Read More diff --git a/articles/index.xml b/articles/index.xml index 23e4a6f1..ddd42bf6 100644 --- a/articles/index.xml +++ b/articles/index.xml @@ -18,9 +18,9 @@ https://ninenines.eu/articles/gun-1.0.0-rc.1/ Gun 1.0.0-rc.1 has been released! - Gun is an HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP. - Gun provides an asynchronous interface and will keep the connection open to the server, reconnecting as necessary. - Gun has existed for many years as the test client for Cowboy and is now mature enough to receive a proper version. Gun is battle tested by customers and other users but is not the most well tested client there is. +Gun is an HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP. +Gun provides an asynchronous interface and will keep the connection open to the server, reconnecting as necessary. +Gun has existed for many years as the test client for Cowboy and is now mature enough to receive a proper version. Gun is battle tested by customers and other users but is not the most well tested client there is. @@ -30,8 +30,8 @@ https://ninenines.eu/articles/cowboy-2.4.0/ Cowboy 2.4.0 has been released! - Numerous HTTP/2 options have been added to control the HTTP/2 SETTINGS and general behavior of HTTP/2 connections. The options for initial window sizes, maximum frame sizes or compression table sizes might be of interest for optimizing the performance of HTTP/2 connections. - Experimental support for Websocket over HTTP/2 was added. Note that browsers do not currently support it. The only browser with partial support is Google Chrome 67 (dev build) started with a specific flag. +Numerous HTTP/2 options have been added to control the HTTP/2 SETTINGS and general behavior of HTTP/2 connections. The options for initial window sizes, maximum frame sizes or compression table sizes might be of interest for optimizing the performance of HTTP/2 connections. +Experimental support for Websocket over HTTP/2 was added. Note that browsers do not currently support it. The only browser with partial support is Google Chrome 67 (dev build) started with a specific flag. @@ -41,9 +41,10 @@ https://ninenines.eu/articles/cowboy-2.3.0/ Cowboy 2.3.0 has been released! - This release focused on adding support for the functions from the sys module for introspecting Cowboy processes. - Many bugs have also been fixed. A more complete list of changes can be found in the migration guide: Migrating from Cowboy 2.2 to 2.3. - You can donate to this project via BountySource because I need to eat snacks when I write code. Thanks in advance! +This release focused on adding support for the functions from the sys module for introspecting Cowboy processes. +Many bugs have also been fixed. A more complete list of changes can be found in the migration guide: Migrating from Cowboy 2.2 to 2.3. +You can donate to this project via BountySource because I need to eat snacks when I write code. Thanks in advance! +As usual, feedback is appreciated, and issues should be reported by opening a ticket. @@ -53,8 +54,8 @@ https://ninenines.eu/articles/cowboy-2.2.0/ Cowboy 2.2.0 has been released! - This release focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs. - The cowboy_req:stream_trailers/2 function has been added. It terminates the streamed response by adding some trailer field values. This feature is required for gRPC. The max_skip_body_length option was added. It controls how much of the request body we are willing to skip to get to the next request for HTTP/1. +This release focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs. +The cowboy_req:stream_trailers/2 function has been added. It terminates the streamed response by adding some trailer field values. This feature is required for gRPC. The max_skip_body_length option was added. It controls how much of the request body we are willing to skip to get to the next request for HTTP/1. @@ -64,8 +65,8 @@ https://ninenines.eu/articles/cowboy-2.1.0/ Cowboy 2.1.0 has been released! - This release focused on adding features that were temporarily removed during the 2.0 release process: - The client TLS certificate can now be obtained. The 100 Continue response is now sent automatically again when necessary. NEW: It is now possible to send informational responses (1XX) directly from user code via the cowboy_req:inform/2,3 functions. NEW: cowboy_rest handlers can now switch to any other type of handler from almost any callback. +This release focused on adding features that were temporarily removed during the 2.0 release process: +The client TLS certificate can now be obtained. The 100 Continue response is now sent automatically again when necessary. NEW: It is now possible to send informational responses (1XX) directly from user code via the cowboy_req:inform/2,3 functions. NEW: cowboy_rest handlers can now switch to any other type of handler from almost any callback. @@ -75,9 +76,9 @@ https://ninenines.eu/articles/cowboy-2.0.0/ Cowboy 2.0.0 has been released! - This is the new stable version of Cowboy. There are no new releases planned for the 1.x version of Cowboy. - The highlights from the release are: - HTTP/2 support! Websocket compression! Much simpler, cleaner interface. No more weird errors just because you discard the Req object. A new low-level interface that receives all events from every set of request and response. +This is the new stable version of Cowboy. There are no new releases planned for the 1.x version of Cowboy. +The highlights from the release are: +HTTP/2 support! Websocket compression! Much simpler, cleaner interface. No more weird errors just because you discard the Req object. A new low-level interface that receives all events from every set of request and response. This replaces the awkward hooks from 1. @@ -87,9 +88,9 @@ https://ninenines.eu/articles/cowboy-2.0.0-rc.2/ Cowboy 2.0.0-rc.2 has been released! - This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. - This new version contains fixes for the following issues: - HTTP/2 server push was using the wrong header compression context. HTTP/2 flow control could end up queueing data in the wrong order when resuming the sending of data. +This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. +This new version contains fixes for the following issues: +HTTP/2 server push was using the wrong header compression context. HTTP/2 flow control could end up queueing data in the wrong order when resuming the sending of data. @@ -99,8 +100,8 @@ https://ninenines.eu/articles/cowboy-2.0.0-rc.1/ Cowboy 2.0.0-rc.1 has been released! - This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. - The plan is to have a new RC version every couple weeks until the summer ends or later if there are still blocking issues open. Only issues that can&#8217;t be fixed without making breaking changes to the interface may block the release. +This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. +The plan is to have a new RC version every couple weeks until the summer ends or later if there are still blocking issues open. Only issues that can&apos;t be fixed without making breaking changes to the interface may block the release. @@ -110,7 +111,7 @@ https://ninenines.eu/articles/the-elephant-in-the-room/ 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. +You lost them. You know you lost them. They comment on the syntax, or perhaps you do, already admitting defeat. @@ -119,8 +120,8 @@ Sun, 22 Jan 2017 00:00:00 +0100 https://ninenines.eu/articles/dont-let-it-crash/ - We have a specific mindset when writing Erlang programs. We focus on the normal execution of the program and don&#8217;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 have a specific mindset when writing Erlang programs. We focus on the normal execution of the program and don&apos;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. @@ -130,9 +131,9 @@ https://ninenines.eu/articles/cowboy-2.0.0-pre.4/ 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. +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. @@ -142,8 +143,9 @@ https://ninenines.eu/articles/ranch-1.3/ 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&#8217;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. +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&apos;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&apos;s state. @@ -153,9 +155,9 @@ https://ninenines.eu/articles/ml-archives/ 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&#8217;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. +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&apos;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. @@ -165,8 +167,8 @@ https://ninenines.eu/articles/website-update/ 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 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. @@ -176,9 +178,9 @@ https://ninenines.eu/articles/erlanger-playbook-september-2015-update/ 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. +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. @@ -188,9 +190,10 @@ https://ninenines.eu/articles/erlanger-playbook/ 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: +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&apos;t let it crash Read a preview: Special processes @@ -200,8 +203,8 @@ https://ninenines.eu/articles/erlang-validate-utf8/ 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 &lt;bjoern@hoehrmann. +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 &lt;bjoern@hoehrmann. @@ -219,7 +222,7 @@ Sat, 23 Aug 2014 00:00:00 +0100 https://ninenines.eu/articles/the-story-so-far/ - 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&#8217;ll be an article that&#8217;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. + 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&apos;ll be an article that&apos;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. @@ -229,7 +232,7 @@ https://ninenines.eu/articles/cowboy2-qs/ 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&#8217;t need to call functions to do everything anymore. +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&apos;t need to call functions to do everything anymore. @@ -239,8 +242,8 @@ https://ninenines.eu/articles/january-2014-status/ I will now be regularly writing posts about project status, plans and hopes for the future. - Before that though, there&#8217;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&#8217;t benefit the open source projects. And that didn&#8217;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. +Before that though, there&apos;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&apos;t benefit the open source projects. And that didn&apos;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. @@ -249,10 +252,10 @@ Thu, 27 Jun 2013 00:00:00 +0100 https://ninenines.eu/articles/farwest-funded/ - This was a triumph! I&#8217;m making a note here: HUGE SUCCESS!! - It&#8217;s hard to overstate my satisfaction. Thanks to everyone who made this possible. - If you have backed this fundraiser, and haven&#8217;t provided your personal details yet, please do so quickly so that your rewards can be sent! - I am hoping that we will be able to make good use of all that money. The details of the expenses will be published regularly on the 2013 Fundraiser wiki page, giving you full disclosure as to how your money is used. + This was a triumph! I&apos;m making a note here: HUGE SUCCESS!! +It&apos;s hard to overstate my satisfaction. Thanks to everyone who made this possible. +If you have backed this fundraiser, and haven&apos;t provided your personal details yet, please do so quickly so that your rewards can be sent! +I am hoping that we will be able to make good use of all that money. The details of the expenses will be published regularly on the 2013 Fundraiser wiki page, giving you full disclosure as to how your money is used. @@ -261,8 +264,8 @@ Tue, 28 May 2013 00:00:00 +0100 https://ninenines.eu/articles/erlang.mk-and-relx/ - Building OTP releases has always been a difficult task. Tools like Reltool or Rebar have made this simpler, but it&#8217;s no panacea. This article will show you an alternative and hopefully much simpler solution. - There is two steps to building a release. First you need to build the various OTP applications you want to include in the release. Once done, you need to create the release itself, by including the Erlang runtime system alongside the applications, a boot script to start the node and all its applications, and some configuration files. + Building OTP releases has always been a difficult task. Tools like Reltool or Rebar have made this simpler, but it&apos;s no panacea. This article will show you an alternative and hopefully much simpler solution. +There is two steps to building a release. First you need to build the various OTP applications you want to include in the release. Once done, you need to create the release itself, by including the Erlang runtime system alongside the applications, a boot script to start the node and all its applications, and some configuration files. @@ -271,9 +274,9 @@ Mon, 25 Mar 2013 00:00:00 +0100 https://ninenines.eu/articles/xerl-0.5-intermediate-module/ - Today we will start the work on the intermediate module that will be used to run the code for the expressions found in our file&#8217;s body, replacing our interpreter. - This is what we want to have when all the work is done: - xerl -&gt; tokens -&gt; AST -&gt; intermediate -&gt; cerl Today we will perform this work only on the atomic integer expression however, so we will not build any module at the end. + Today we will start the work on the intermediate module that will be used to run the code for the expressions found in our file&apos;s body, replacing our interpreter. +This is what we want to have when all the work is done: +xerl -&gt; tokens -&gt; AST -&gt; intermediate -&gt; cerl Today we will perform this work only on the atomic integer expression however, so we will not build any module at the end. @@ -283,9 +286,9 @@ https://ninenines.eu/articles/xerl-0.4-expression-separator/ As promised we are adding an expression separator this time. This will be short and easy. - In the tokenizer we only need to add a line recognizing the comma as a valid token. - , : {token, {',', TokenLine}}. Then we need to change the following lines in the parser: - exprs -&gt; expr : ['$1']. exprs -&gt; expr exprs : ['$1' | '$2']. And add a comma between the expressions on the second line: +In the tokenizer we only need to add a line recognizing the comma as a valid token. +, : {token, {',', TokenLine}}. Then we need to change the following lines in the parser: +exprs -&gt; expr : ['$1']. exprs -&gt; expr exprs : ['$1' | '$2']. And add a comma between the expressions on the second line: @@ -295,7 +298,7 @@ https://ninenines.eu/articles/erlang-scalability/ I would like to share some experience and theories on Erlang scalability. - This will be in the form of a series of hints, which may or may not be accompanied with explanations as to why things are this way, or how they improve or reduce the scalability of a system. I will try to do my best to avoid giving falsehoods, even if that means a few things won&#8217;t be explained. +This will be in the form of a series of hints, which may or may not be accompanied with explanations as to why things are this way, or how they improve or reduce the scalability of a system. I will try to do my best to avoid giving falsehoods, even if that means a few things won&apos;t be explained. @@ -305,8 +308,8 @@ https://ninenines.eu/articles/xerl-0.3-atomic-expressions/ We will be adding atomic integer expressions to our language. These look as follow in Erlang: - 42. And the result of this expression is of course 42. - We will be running this expression at compile time, since we don&#8217;t have the means to run code at runtime yet. This will of course result in no module being compiled, but that&#8217;s OK, it will allow us to discuss a few important things we&#8217;ll have to plan for later on. +42. And the result of this expression is of course 42. +We will be running this expression at compile time, since we don&apos;t have the means to run code at runtime yet. This will of course result in no module being compiled, but that&apos;s OK, it will allow us to discuss a few important things we&apos;ll have to plan for later on. @@ -316,10 +319,10 @@ https://ninenines.eu/articles/xerl-0.2-two-modules/ Everything is an expression. - This sentence carries profound meaning. We will invoke it many times over the course of these articles. - If everything is an expression, then the language shouldn&#8217;t have any problem with me defining two modules in the same source file. - mod first_module begin end mod second_module begin end Likewise, it shouldn&#8217;t have any problem with me defining a module inside another module. - mod out_module begin mod in_module begin end end Of course, in the context of the Erlang VM, these two snippets are equivalent; there is nothing preventing you from calling the in_module module from any other module. +This sentence carries profound meaning. We will invoke it many times over the course of these articles. +If everything is an expression, then the language shouldn&apos;t have any problem with me defining two modules in the same source file. +mod first_module begin end mod second_module begin end Likewise, it shouldn&apos;t have any problem with me defining a module inside another module. +mod out_module begin mod in_module begin end end Of course, in the context of the Erlang VM, these two snippets are equivalent; there is nothing preventing you from calling the in_module module from any other module. @@ -328,9 +331,9 @@ Wed, 30 Jan 2013 00:00:00 +0100 https://ninenines.eu/articles/xerl-0.1-empty-modules/ - Let&#8217;s build a programming language. I call it Xerl: eXtended ERLang. It&#8217;ll be an occasion for us to learn a few things, especially me. - Unlike in Erlang, in this language, everything is an expression. This means that modules and functions are expression, and indeed that you can have more than one module per file. - We are just starting, so let&#8217;s no go ahead of ourselves here. We&#8217;ll begin with writing the code allowing us to compile an empty module. + Let&apos;s build a programming language. I call it Xerl: eXtended ERLang. It&apos;ll be an occasion for us to learn a few things, especially me. +Unlike in Erlang, in this language, everything is an expression. This means that modules and functions are expression, and indeed that you can have more than one module per file. +We are just starting, so let&apos;s no go ahead of ourselves here. We&apos;ll begin with writing the code allowing us to compile an empty module. @@ -340,7 +343,7 @@ https://ninenines.eu/articles/ranch-ftp/ Last week I was speaking at the London Erlang Factory Lite where I presented a live demonstration of building an FTP server using Ranch. As there was no slide, you should use this article as a reference instead. - The goal of this article is to showcase how to use Ranch for writing a network protocol implementation, how Ranch gets out of the way to let you write the code that matters, and the common techniques used when writing servers. +The goal of this article is to showcase how to use Ranch for writing a network protocol implementation, how Ranch gets out of the way to let you write the code that matters, and the common techniques used when writing servers. @@ -350,9 +353,9 @@ https://ninenines.eu/articles/tictactoe/ Everyone knows Tic Tac Toe, right? - Players choose either to be the Xs or the Os, then place their symbol on a 3x3 board one after another, trying to create a line of 3 of them. - Writing an algorithm to check for victory sounds easy, right? It&#8217;s easily tested, considering there&#8217;s only 8 possible winning rows (3 horizontal, 3 vertical and 2 diagonal). - In Erlang though, you probably wouldn&#8217;t want an algorithm. +Players choose either to be the Xs or the Os, then place their symbol on a 3x3 board one after another, trying to create a line of 3 of them. +Writing an algorithm to check for victory sounds easy, right? It&apos;s easily tested, considering there&apos;s only 8 possible winning rows (3 horizontal, 3 vertical and 2 diagonal). +In Erlang though, you probably wouldn&apos;t want an algorithm. diff --git a/articles/january-2014-status/index.html b/articles/january-2014-status/index.html index 2c489556..6548a920 100644 --- a/articles/january-2014-status/index.html +++ b/articles/january-2014-status/index.html @@ -69,146 +69,41 @@

-

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.

-
+

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.

-
-
-
+

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.

-
-
-
+

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.

-
-
-
+

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.

-
-
-
+

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.

-
-
+

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.

+ diff --git a/articles/ml-archives/index.html b/articles/ml-archives/index.html index fd96cbc1..1d0862fc 100644 --- a/articles/ml-archives/index.html +++ b/articles/ml-archives/index.html @@ -69,16 +69,12 @@

-

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.

+

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.

+ diff --git a/articles/on-open-source/index.html b/articles/on-open-source/index.html index 08340dfc..e3c476e0 100644 --- a/articles/on-open-source/index.html +++ b/articles/on-open-source/index.html @@ -69,123 +69,24 @@

-

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.

+

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.

+ diff --git a/articles/page/2/index.html b/articles/page/2/index.html index 194f9243..c8629fe5 100644 --- a/articles/page/2/index.html +++ b/articles/page/2/index.html @@ -75,8 +75,8 @@

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.

+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.

Read More @@ -92,10 +92,10 @@

-

This was a triumph! I’m making a note here: HUGE SUCCESS!! - It’s hard to overstate my satisfaction. Thanks to everyone who made this possible. - If you have backed this fundraiser, and haven’t provided your personal details yet, please do so quickly so that your rewards can be sent! - I am hoping that we will be able to make good use of all that money. The details of the expenses will be published regularly on the 2013 Fundraiser wiki page, giving you full disclosure as to how your money is used.

+

This was a triumph! I'm making a note here: HUGE SUCCESS!! +It's hard to overstate my satisfaction. Thanks to everyone who made this possible. +If you have backed this fundraiser, and haven't provided your personal details yet, please do so quickly so that your rewards can be sent! +I am hoping that we will be able to make good use of all that money. The details of the expenses will be published regularly on the 2013 Fundraiser wiki page, giving you full disclosure as to how your money is used.

Read More @@ -111,8 +111,8 @@

-

Building OTP releases has always been a difficult task. Tools like Reltool or Rebar have made this simpler, but it’s no panacea. This article will show you an alternative and hopefully much simpler solution. - There is two steps to building a release. First you need to build the various OTP applications you want to include in the release. Once done, you need to create the release itself, by including the Erlang runtime system alongside the applications, a boot script to start the node and all its applications, and some configuration files.

+

Building OTP releases has always been a difficult task. Tools like Reltool or Rebar have made this simpler, but it's no panacea. This article will show you an alternative and hopefully much simpler solution. +There is two steps to building a release. First you need to build the various OTP applications you want to include in the release. Once done, you need to create the release itself, by including the Erlang runtime system alongside the applications, a boot script to start the node and all its applications, and some configuration files.

Read More @@ -128,9 +128,9 @@

-

Today we will start the work on the intermediate module that will be used to run the code for the expressions found in our file’s body, replacing our interpreter. - This is what we want to have when all the work is done: - xerl -> tokens -> AST -> intermediate -> cerl Today we will perform this work only on the atomic integer expression however, so we will not build any module at the end.

+

Today we will start the work on the intermediate module that will be used to run the code for the expressions found in our file's body, replacing our interpreter. +This is what we want to have when all the work is done: +xerl -> tokens -> AST -> intermediate -> cerl Today we will perform this work only on the atomic integer expression however, so we will not build any module at the end.

Read More @@ -147,9 +147,9 @@

As promised we are adding an expression separator this time. This will be short and easy. - In the tokenizer we only need to add a line recognizing the comma as a valid token. - , : {token, {',', TokenLine}}. Then we need to change the following lines in the parser: - exprs -> expr : ['$1']. exprs -> expr exprs : ['$1' | '$2']. And add a comma between the expressions on the second line:

+In the tokenizer we only need to add a line recognizing the comma as a valid token. +, : {token, {',', TokenLine}}. Then we need to change the following lines in the parser: +exprs -> expr : ['$1']. exprs -> expr exprs : ['$1' | '$2']. And add a comma between the expressions on the second line:

Read More @@ -166,7 +166,7 @@

I would like to share some experience and theories on Erlang scalability. - This will be in the form of a series of hints, which may or may not be accompanied with explanations as to why things are this way, or how they improve or reduce the scalability of a system. I will try to do my best to avoid giving falsehoods, even if that means a few things won’t be explained.

+This will be in the form of a series of hints, which may or may not be accompanied with explanations as to why things are this way, or how they improve or reduce the scalability of a system. I will try to do my best to avoid giving falsehoods, even if that means a few things won't be explained.

Read More @@ -183,8 +183,8 @@

We will be adding atomic integer expressions to our language. These look as follow in Erlang: - 42. And the result of this expression is of course 42. - We will be running this expression at compile time, since we don’t have the means to run code at runtime yet. This will of course result in no module being compiled, but that’s OK, it will allow us to discuss a few important things we’ll have to plan for later on.

+42. And the result of this expression is of course 42. +We will be running this expression at compile time, since we don't have the means to run code at runtime yet. This will of course result in no module being compiled, but that's OK, it will allow us to discuss a few important things we'll have to plan for later on.

Read More @@ -201,10 +201,10 @@

Everything is an expression. - This sentence carries profound meaning. We will invoke it many times over the course of these articles. - If everything is an expression, then the language shouldn’t have any problem with me defining two modules in the same source file. - mod first_module begin end mod second_module begin end Likewise, it shouldn’t have any problem with me defining a module inside another module. - mod out_module begin mod in_module begin end end Of course, in the context of the Erlang VM, these two snippets are equivalent; there is nothing preventing you from calling the in_module module from any other module.

+This sentence carries profound meaning. We will invoke it many times over the course of these articles. +If everything is an expression, then the language shouldn't have any problem with me defining two modules in the same source file. +mod first_module begin end mod second_module begin end Likewise, it shouldn't have any problem with me defining a module inside another module. +mod out_module begin mod in_module begin end end Of course, in the context of the Erlang VM, these two snippets are equivalent; there is nothing preventing you from calling the in_module module from any other module.

Read More @@ -220,9 +220,9 @@

-

Let’s build a programming language. I call it Xerl: eXtended ERLang. It’ll be an occasion for us to learn a few things, especially me. - Unlike in Erlang, in this language, everything is an expression. This means that modules and functions are expression, and indeed that you can have more than one module per file. - We are just starting, so let’s no go ahead of ourselves here. We’ll begin with writing the code allowing us to compile an empty module.

+

Let's build a programming language. I call it Xerl: eXtended ERLang. It'll be an occasion for us to learn a few things, especially me. +Unlike in Erlang, in this language, everything is an expression. This means that modules and functions are expression, and indeed that you can have more than one module per file. +We are just starting, so let's no go ahead of ourselves here. We'll begin with writing the code allowing us to compile an empty module.

Read More @@ -239,7 +239,7 @@

Last week I was speaking at the London Erlang Factory Lite where I presented a live demonstration of building an FTP server using Ranch. As there was no slide, you should use this article as a reference instead. - The goal of this article is to showcase how to use Ranch for writing a network protocol implementation, how Ranch gets out of the way to let you write the code that matters, and the common techniques used when writing servers.

+The goal of this article is to showcase how to use Ranch for writing a network protocol implementation, how Ranch gets out of the way to let you write the code that matters, and the common techniques used when writing servers.

Read More @@ -256,9 +256,9 @@

Everyone knows Tic Tac Toe, right? - Players choose either to be the Xs or the Os, then place their symbol on a 3x3 board one after another, trying to create a line of 3 of them. - Writing an algorithm to check for victory sounds easy, right? It’s easily tested, considering there’s only 8 possible winning rows (3 horizontal, 3 vertical and 2 diagonal). - In Erlang though, you probably wouldn’t want an algorithm.

+Players choose either to be the Xs or the Os, then place their symbol on a 3x3 board one after another, trying to create a line of 3 of them. +Writing an algorithm to check for victory sounds easy, right? It's easily tested, considering there's only 8 possible winning rows (3 horizontal, 3 vertical and 2 diagonal). +In Erlang though, you probably wouldn't want an algorithm.

Read More diff --git a/articles/ranch-1.3/index.html b/articles/ranch-1.3/index.html index 914259e4..43d90a8c 100644 --- a/articles/ranch-1.3/index.html +++ b/articles/ranch-1.3/index.html @@ -69,88 +69,53 @@

-

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:

-
    -
  • -

    -https://git.ninenines.eu/ranch.git -

    +

    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!

+
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!

+ diff --git a/articles/ranch-ftp/index.html b/articles/ranch-ftp/index.html index f5a30f51..58d4b220 100644 --- a/articles/ranch-ftp/index.html +++ b/articles/ranch-ftp/index.html @@ -69,216 +69,155 @@

-

Last week I was speaking at the -London Erlang Factory Lite -where I presented a live demonstration of building an FTP server using -Ranch. -As there was no slide, you should use this article as a reference instead.

-

The goal of this article is to showcase how to use Ranch for writing -a network protocol implementation, how Ranch gets out of the way to let -you write the code that matters, and the common techniques used when -writing servers.

-

Let’s start by creating an empty project. Create a new directory and -then open a terminal into that directory. The first step is to add Ranch -as a dependency. Create the rebar.config file and add the -following 3 lines.

-
-
-
{deps, [
-    {ranch, ".*", {git, "git://github.com/extend/ranch.git", "master"}}
-]}.
-

This makes your application depend on the last Ranch version available -on the master branch. This is fine for development, however when -you start pushing your application to production you will want to revisit -this file to hardcode the exact version you are using, to make sure you -run the same version of dependencies in production.

-

You can now fetch the dependencies.

-
-
$ rebar get-deps
-==> ranch_ftp (get-deps)
-Pulling ranch from {git,"git://github.com/extend/ranch.git","master"}
-Cloning into 'ranch'...
-==> ranch (get-deps)
-

This will create a deps/ folder containing Ranch.

-

We don’t actually need anything else to write the protocol code. -We could make an application for it, but this isn’t the purpose of this -article so let’s just move on to writing the protocol itself. Create -the file ranch_ftp_protocol.erl and open it in your favorite -editor.

-
-
-
$ vim ranch_ftp_protocol.erl
-

Let’s start with a blank protocol module.

-
-
-
-module(ranch_ftp_protocol).
--export([start_link/4, init/3]).
+
-module(ranch_ftp_protocol).
+-export([start_link/4, init/3]).
 
-start_link(ListenerPid, Socket, Transport, Opts) ->
-    Pid = spawn_link(?MODULE, init, [ListenerPid, Socket, Transport]),
-    {ok, Pid}.
+start_link(ListenerPid, Socket, Transport, Opts) ->
+    Pid = spawn_link(?MODULE, init, [ListenerPid, Socket, Transport]),
+    {ok, Pid}.
 
-init(ListenerPid, Socket, Transport) ->
-    io:format("Got a connection!~n"),
-    ok.
-

When Ranch receives a connection, it will call the <code>start_link/4</code> -function with the listener’s pid, socket, transport module to be used, -and the options we define when starting the listener. We don’t need options -for the purpose of this article, so we don’t pass them to the process we are -creating.

-

Let’s open a shell and start a Ranch listener to begin accepting -connections. We only need to call one function. You should probably open -it in another terminal and keep it open for convenience. If you quit -the shell you will have to repeat the commands to proceed.

-

Also note that you need to type c(ranch_ftp_protocol). -to recompile and reload the code for the protocol. You do not need to -restart any process however.

-
-
-
$ erl -pa ebin deps/*/ebin
-Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]
+
$ erl -pa ebin deps/*/ebin
+Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]
 
-Eshell V5.9.2  (abort with ^G)
-
-
-
1> application:start(ranch).
-ok
-2> ranch:start_listener(my_ftp, 10,
-       ranch_tcp, [{port, 2121}],
-       ranch_ftp_protocol, []).
-{ok,<0.40.0>}
-

This starts a listener named my_ftp that runs your very own -ranch_ftp_protocol over TCP, listening on port 2121. -The last argument is the options given to the protocol that we ignored -earlier.

-

To try your code, you can use the following command. It should be able -to connect, the server will print a message in the console, and then -the client will print an error.

-
-
-
$ ftp localhost 2121
-

Let’s move on to actually writing the protocol.

-

Once you have created the new process and returned the pid, Ranch will -give ownership of the socket to you. This requires a synchronization -step though.

-
-
-
init(ListenerPid, Socket, Transport) ->
-    ok = ranch:accept_ack(ListenerPid),
-    ok.
-

Now that you acknowledged the new connection, you can use it safely.

-

When an FTP server accepts a connection, it starts by sending a -welcome message which can be one or more lines starting with the -code 200. Then the server will wait for the client -to authenticate the user, and if the authentication went successfully, -which it will always do for the purpose of this article, it will reply -with a 230 code.

-
-
-
init(ListenerPid, Socket, Transport) ->
-    ok = ranch:accept_ack(ListenerPid),
-    Transport:send(Socket, <<"200 My cool FTP server welcomes you!\r\n">>),
-    {ok, Data} = Transport:recv(Socket, 0, 30000),
-    auth(Socket, Transport, Data).
+
init(ListenerPid, Socket, Transport) ->
+    ok = ranch:accept_ack(ListenerPid),
+    Transport:send(Socket, <<"200 My cool FTP server welcomes you!\r\n">>),
+    {ok, Data} = Transport:recv(Socket, 0, 30000),
+    auth(Socket, Transport, Data).
 
-auth(Socket, Transport, <<"USER ", Rest/bits>>) ->
-    io:format("User authenticated! ~p~n", [Rest]),
-    Transport:send(Socket, <<"230 Auth OK\r\n">>),
-    ok.
-

As you can see we don’t need complex parsing code. We can simply -match on the binary in the argument!

-

Next we need to loop receiving data commands and optionally -execute them, if we want our server to become useful.

-

We will replace the <code>ok.</code> line with the call to -the following function. The new function is recursive, each call -receiving data from the socket and sending a response. For now -we will send an error response for all commands the client sends.

-
-
-
loop(Socket, Transport) ->
-    case Transport:recv(Socket, 0, 30000) of
-        {ok, Data} ->
-            handle(Socket, Transport, Data),
-            loop(Socket, Transport);
-        {error, _} ->
-            io:format("The client disconnected~n")
-    end.
+
loop(Socket, Transport) ->
+    case Transport:recv(Socket, 0, 30000) of
+        {ok, Data} ->
+            handle(Socket, Transport, Data),
+            loop(Socket, Transport);
+        {error, _} ->
+            io:format("The client disconnected~n")
+    end.
 
-handle(Socket, Transport, Data) ->
-    io:format("Command received ~p~n", [Data]),
-    Transport:send(Socket, <<"500 Bad command\r\n">>).
-

With this we are almost ready to start implementing commands. -But with code like this we might have errors if the client doesn’t -send just one command per packet, or if the packets arrive too fast, -or if a command is split over multiple packets.

-

To solve this, we need to use a buffer. Each time we receive data, -we will append to the buffer, and then check if we have received a -command fully before running it. The code could look similar to the -following.

-
-
-
loop(Socket, Transport, Buffer) ->
-    case Transport:recv(Socket, 0, 30000) of
-        {ok, Data} ->
-                        Buffer2 = << Buffer/binary, Data/binary >>,
-                        {Commands, Rest} = split(Buffer2),
-                        [handle(Socket, Transport, C) || C <- Commands],
-            loop(Socket, Transport, Rest);
-        {error, _} ->
-            io:format("The client disconnected~n")
-    end.
-

The implementation of split/1 is left as an exercice -to the reader. You will also probably want to handle the QUIT -command, which must stop any processing and close the connection.

-

The attentive reader will also take note that in the case of text- -based protocols where commands are separated by line breaks, you can -set an option using Transport:setopts/2 and have all the -buffering done for you for free by Erlang itself.

-

As you can surely notice by now, Ranch allows us to build network -applications by getting out of our way entirely past the initial setup. -It lets you use the power of binary pattern matching to write text and -binary protocol implementations in just a few lines of code.

-
    -
  • -

    -Watch the talk -

    +
    loop(Socket, Transport, Buffer) ->
+    case Transport:recv(Socket, 0, 30000) of
+        {ok, Data} ->
+			Buffer2 = << Buffer/binary, Data/binary >>,
+			{Commands, Rest} = split(Buffer2),
+			[handle(Socket, Transport, C) || C <- Commands],
+            loop(Socket, Transport, Rest);
+        {error, _} ->
+            io:format("The client disconnected~n")
+    end.
    +
+

The implementation of split/1 is left as an exercice to the reader. You will also probably want to handle the QUIT command, which must stop any processing and close the connection.

+

The attentive reader will also take note that in the case of text- based protocols where commands are separated by line breaks, you can set an option using Transport:setopts/2 and have all the buffering done for you for free by Erlang itself.

+

As you can surely notice by now, Ranch allows us to build network applications by getting out of our way entirely past the initial setup. It lets you use the power of binary pattern matching to write text and binary protocol implementations in just a few lines of code.

+ + + diff --git a/articles/the-elephant-in-the-room/index.html b/articles/the-elephant-in-the-room/index.html index 8123f821..4a57b018 100644 --- a/articles/the-elephant-in-the-room/index.html +++ b/articles/the-elephant-in-the-room/index.html @@ -69,139 +69,37 @@

-

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 -

    +

    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 -

      +
    • show your product's strengths
      • -
    • -

      -make people take a commitment -

      +
    • 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.

+ +

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.

+ diff --git a/articles/the-story-so-far/index.html b/articles/the-story-so-far/index.html index 8750d6db..4b749e7f 100644 --- a/articles/the-story-so-far/index.html +++ b/articles/the-story-so-far/index.html @@ -69,230 +69,28 @@

-

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.

+

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.

+ diff --git a/articles/tictactoe/index.html b/articles/tictactoe/index.html index 3fd8e6e3..33cc169b 100644 --- a/articles/tictactoe/index.html +++ b/articles/tictactoe/index.html @@ -69,89 +69,60 @@

-

Everyone knows Tic Tac Toe, -right?

-

Players choose either to be the Xs or the Os, then place their symbol -on a 3x3 board one after another, trying to create a line of 3 of them.

-

Writing an algorithm to check for victory sounds easy, right? It’s -easily tested, considering there’s only 8 possible winning rows (3 horizontal, -3 vertical and 2 diagonal).

-

In Erlang though, you probably wouldn’t want an algorithm. Erlang has -this cool feature called pattern matching which will allow us to completely -avoid writing the algorithm by instead letting us match directly on the -solutions.

-

Let’s first create a board. A board is a list of 3 rows each containing -3 columns. It can also be thought of as a tuple containing 9 elements. -A tuple is easier to manipulate so this is what we are going to use. -Each position can either contain an x, an o, -or be undefined.

-
-
-
new() ->
-    {undefined, undefined, undefined,
-     undefined, undefined, undefined,
-     undefined, undefined, undefined}.
-

Now that we have a board, if we want to play, we need a function that -will allow players to, you know, actually play their moves. Rows and -columns are numbered 1 to 3 so we need a little math to correctly -deduce the element’s position.

-
-
-
play(Who, X, Y, Board) ->
-    setelement((Y - 1) * 3 + X, Board, Who).
-

This function returns the board with the element modified. Of course, -as you probably noticed, we aren’t checking that the arguments are correct, -or that the element was already set. This is left as an exercise to the -reader.

-

After playing the move, we need to check whether someone won. That’s -where you’d write an algorithm, and that’s where I wouldn’t. Let’s just -pattern match all of them!

-
-
-
check(Board) ->
-    case Board of
-        {x, x, x,
-         _, _, _,
-         _, _, _} -> {victory, x};
+
check(Board) ->
+    case Board of
+        {x, x, x,
+         _, _, _,
+         _, _, _} -> {victory, x};
 
-        {x, _, _,
-         _, x, _,
-         _, _, x} -> {victory, x};
+        {x, _, _,
+         _, x, _,
+         _, _, x} -> {victory, x};
 
-        {x, _, _,
-         x, _, _,
-         x, _, _} -> {victory, x};
+        {x, _, _,
+         x, _, _,
+         x, _, _} -> {victory, x};
 
-        %% [snip]
+        %% [snip]
 
-        _ -> ok
-    end.
-

Pattern matching allows us to simply draw the solutions -directly inside our code, and if the board matches any of them, then we -have a victory or a draw, otherwise the game can continue.

-

The _ variable is special in that it always matches, -allowing us to focus strictly on the winning row. And because it’s very -graphical, if we were to have messed up somewhere, then we’d only need -take a quick glance to be sure the winning solutions are the right ones.

-

Erlang allows us to transform algorithms into very graphical code thanks -to its pattern matching feature, and let us focus on doing things instead -of writing algorithms to do things.

-
+

Pattern matching allows us to simply draw the solutions directly inside our code, and if the board matches any of them, then we have a victory or a draw, otherwise the game can continue.

+

The _ variable is special in that it always matches, allowing us to focus strictly on the winning row. And because it's very graphical, if we were to have messed up somewhere, then we'd only need take a quick glance to be sure the winning solutions are the right ones.

+

Erlang allows us to transform algorithms into very graphical code thanks to its pattern matching feature, and let us focus on doing things instead of writing algorithms to do things.

+ + + diff --git a/articles/website-update/index.html b/articles/website-update/index.html index bc871131..7730c1e3 100644 --- a/articles/website-update/index.html +++ b/articles/website-update/index.html @@ -69,63 +69,17 @@

-

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.

+

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.

+ diff --git a/articles/xerl-0.1-empty-modules/index.html b/articles/xerl-0.1-empty-modules/index.html index 86d54924..281c134a 100644 --- a/articles/xerl-0.1-empty-modules/index.html +++ b/articles/xerl-0.1-empty-modules/index.html @@ -69,144 +69,95 @@

-

Let’s build a programming language. I call it Xerl: eXtended ERLang. -It’ll be an occasion for us to learn a few things, especially me.

-

Unlike in Erlang, in this language, everything is an expression. -This means that modules and functions are expression, and indeed that -you can have more than one module per file.

-

We are just starting, so let’s no go ahead of ourselves here. We’ll -begin with writing the code allowing us to compile an empty module.

-

We will compile to Core Erlang: this is one of the many intermediate -step your Erlang code compiles to before it becomes BEAM machine code. -Core Erlang is a very neat language for machine generated code, and we -will learn many things about it.

-

Today we will only focus on compiling the following code:

-
-
-
mod my_module
-begin
-end
-

Compilation will be done in a few steps. First, the source file will -be transformed in a tree of tokens by the lexer. Then, the parser will -use that tree of tokens and convert it to the AST, bringing semantical -meaning to our representation. Finally, the code generator will transform -this AST to Core Erlang AST, which will then be compiled.

-

We will use leex for the lexer. This lexer uses .xrl files -which are then compiled to .erl files that you can then compile to BEAM. -The file is divided in three parts: definitions, rules and Erlang code. -Definitions and Erlang code are obvious; rules are what concerns us.

-

We only need two things: atoms and whitespaces. Atoms are a lowercase -letter followed by any letter, number, _ or @. Whitespace is either a -space, an horizontal tab, \r or \n. There exists other kinds of whitespaces -but we simply do not allow them in the Xerl language.

-

Rules consist of a regular expression followed by Erlang code. The -latter must return a token representation or the atom skip_token.

-
-
-
{L}{A}* :
-    Atom = list_to_atom(TokenChars),
-    {token, case reserved_word(Atom) of
-        true -> {Atom, TokenLine};
-        false -> {atom, TokenLine, Atom}
-    end}.
+
{L}{A}* :
+    Atom = list_to_atom(TokenChars),
+    {token, case reserved_word(Atom) of
+        true -> {Atom, TokenLine};
+        false -> {atom, TokenLine, Atom}
+    end}.
 
-{WS}+ : skip_token.
-

The first rule matches an atom, which is converted to either a special -representation for reserved words, or an atom tuple. The -TokenChars variable represents the match as a string, and -the TokenLine variable contains the line number. -View the complete file.

-

We obtain the following result from the lexer:

-
-
-
[{mod,1},{atom,1,my_module},{'begin',2},{'end',3}]
-

The second step is to parse this list of tokens to add semantic meaning -and generate what is called an abstract syntax tree. We will be -using the yecc parser generator for this. This time it will take -.yrl files but the process is the same as before. The file is a little -more complex than for the lexer, we need to define at the very least -terminals, nonterminals and root symbols, the grammar itself, and -optionally some Erlang code.

-

To compile our module, we need a few things. First, everything is an -expression. We thus need list of expressions and individual expressions. -We will support a single expression for now, the mod -expression which defines a module. And that’s it! We end up with the -following grammar:

-
-
-
exprs -> expr : ['$1'].
-exprs -> expr exprs : ['$1' | '$2'].
+
exprs -> expr : ['$1'].
+exprs -> expr exprs : ['$1' | '$2'].
 
-expr -> module : '$1'.
+expr -> module : '$1'.
 
-module -> 'mod' atom 'begin' 'end' :
-        {'mod', ?line('$1'), '$2', []}.
-

View the complete file.

-

We obtain the following result from the parser:

-
-
-
[{mod,1,{atom,1,my_module},[]}]
-

We obtain a list of a single mod expression. Just like -we wanted. Last step is generating the Core Erlang code from it.

-

Code generation generally is comprised of several steps. We will -discuss these in more details later on. For now, we will focus on the -minimal needed for successful compilation.

-

We can use the cerl module to generate Core Erlang AST. -We will simply be using functions, which allows us to avoid learning -and keeping up to date with the internal representation.

-

There’s one important thing to do when generating Core Erlang AST -for a module: create the module_info/{0,1} functions. -Indeed, these are added to Erlang before it becomes Core Erlang, and -so we need to replicate this ourselves. Do not be concerned however, -as this only takes a few lines of extra code.

-

As you can see by -looking at the complete file, -the code generator echoes the grammar we defined in the parser, and -simply applies the appropriate Core Erlang functions for each expressions.

-

We obtain the following pretty-printed Core Erlang generated code:

-
-
-
module 'my_module' ['module_info'/0,
-                       'module_info'/1]
-    attributes []
-'module_info'/0 =
-    fun () ->
-        call 'erlang':'get_module_info'
-            ('empty_module')
-'module_info'/1 =
-    fun (Key) ->
-        call 'erlang':'get_module_info'
-            ('empty_module', Key)
-end
-

For convenience I added all the steps in a xerl:compile/1 -function that you can use against your own .xerl files.

-

That’s it for today! We will go into more details over each steps in -the next few articles.

-
    -
  • -

    -View the source -

    +
    module 'my_module' ['module_info'/0,
+                       'module_info'/1]
+    attributes []
+'module_info'/0 =
+    fun () ->
+        call 'erlang':'get_module_info'
+            ('empty_module')
+'module_info'/1 =
+    fun (Key) ->
+        call 'erlang':'get_module_info'
+            ('empty_module', Key)
+end
    +
+

For convenience I added all the steps in a xerl:compile/1 function that you can use against your own .xerl files.

+

That's it for today! We will go into more details over each steps in the next few articles.

+ + + diff --git a/articles/xerl-0.2-two-modules/index.html b/articles/xerl-0.2-two-modules/index.html index 2dd5f828..f37b899f 100644 --- a/articles/xerl-0.2-two-modules/index.html +++ b/articles/xerl-0.2-two-modules/index.html @@ -69,149 +69,123 @@

-

Everything is an expression.

-

This sentence carries profound meaning. We will invoke it many -times over the course of these articles.

-

If everything is an expression, then the language shouldn’t have -any problem with me defining two modules in the same source file.

-
-
-
mod first_module
-begin
-end
+
mod first_module
+begin
+end
 
-mod second_module
-begin
-end
-

Likewise, it shouldn’t have any problem with me defining a -module inside another module.

-
-
-
mod out_module
-begin
-    mod in_module
-    begin
-    end
-end
-

Of course, in the context of the Erlang VM, these two snippets -are equivalent; there is nothing preventing you from calling the -in_module module from any other module. The mod -instruction means a module should be created in the Erlang VM, -with no concept of scope attached.

-

Still we need to handle both. To do this we will add a step -between the parser and the code generator that will walk over the -abstract syntax tree, from here onward shortened as AST, -and transform the AST by executing it where applicable.

-

What happens when you execute a mod instruction? -A module is created. Since we are compiling, that simply means -the compiler will branch out and create a module.

-

If everything is an expression, does that mean this will allow -me to create modules at runtime using the same syntax? Yes, but -let’s not get ahead of ourselves yet.

-

For now we will just iterate over the AST, and will compile -a module for each mod found. Modules cannot contain -expressions yet, so there’s no need to recurse over it at this -point. This should solve the compilation of our first snippet.

-

The compile/1 function becomes:

-
-
-
compile(Filename) ->
-        io:format("Compiling ~s...~n", [Filename]),
-        {ok, Src} = file:read_file(Filename),
-        {ok, Tokens, _} = xerl_lexer:string(binary_to_list(Src)),
-        {ok, Exprs} = xerl_parser:parse(Tokens),
-        execute(Filename, Exprs, []).
+
compile(Filename) ->
+	io:format("Compiling ~s...~n", [Filename]),
+	{ok, Src} = file:read_file(Filename),
+	{ok, Tokens, _} = xerl_lexer:string(binary_to_list(Src)),
+	{ok, Exprs} = xerl_parser:parse(Tokens),
+	execute(Filename, Exprs, []).
 
-execute(_, [], Modules) ->
-        io:format("Done...~n"),
-        {ok, lists:reverse(Modules)};
-execute(Filename, [Expr = {mod, _, {atom, _, Name}, []}|Tail], Modules) ->
-        {ok, [Core]} = xerl_codegen:exprs([Expr]),
-        {ok, [{Name, []}]} = core_lint:module(Core),
-        io:format("~s~n", [core_pp:format(Core)]),
-        {ok, _, Beam} = compile:forms(Core,
-                [binary, from_core, return_errors, {source, Filename}]),
-        {module, Name} = code:load_binary(Name, Filename, Beam),
-        execute(Filename, Tail, [Name|Modules]).
-

Running this compiler over the first snippet yields the following -result:

-
-
-
Compiling test/mod_SUITE_data/two_modules.xerl...
-module 'first_module' ['module_info'/0,
-                       'module_info'/1]
-    attributes []
-'module_info'/0 =
-    fun () ->
-        call 'erlang':'get_module_info'
-            ('first_module')
-'module_info'/1 =
-    fun (Key) ->
-        call 'erlang':'get_module_info'
-            ('first_module', Key)
-end
-module 'second_module' ['module_info'/0,
-                        'module_info'/1]
-    attributes []
-'module_info'/0 =
-    fun () ->
-        call 'erlang':'get_module_info'
-            ('second_module')
-'module_info'/1 =
-    fun (Key) ->
-        call 'erlang':'get_module_info'
-            ('second_module', Key)
-end
-Done...
-{ok,[first_module,second_module]}
-

Everything looks fine. And we can check that the two modules have -been loaded into the VM:

-
-
-
9> m(first_module).
-Module first_module compiled: Date: February 2 2013, Time: 14.56
-Compiler options:  [from_core]
-Object file: test/mod_SUITE_data/two_modules.xerl
-Exports:
-         module_info/0
-         module_info/1
-ok
-10> m(second_module).
-Module second_module compiled: Date: February 2 2013, Time: 14.56
-Compiler options:  [from_core]
-Object file: test/mod_SUITE_data/two_modules.xerl
-Exports:
-         module_info/0
-         module_info/1
-ok
-

So far so good!

-

What about the second snippet? It brings up many questions. What -happens once a mod expression has been executed at -compile time? If it’s an expression then it has to have a result, -right? Right. We are still a bit lacking with expressions for now, -though, so let’s get back to it after we add more.

-
    -
  • -

    -View the source -

    +
    9> m(first_module).
+Module first_module compiled: Date: February 2 2013, Time: 14.56
+Compiler options:  [from_core]
+Object file: test/mod_SUITE_data/two_modules.xerl
+Exports: 
+         module_info/0
+         module_info/1
+ok
+10> m(second_module).
+Module second_module compiled: Date: February 2 2013, Time: 14.56
+Compiler options:  [from_core]
+Object file: test/mod_SUITE_data/two_modules.xerl
+Exports: 
+         module_info/0
+         module_info/1
+ok
    +
+

So far so good!

+

What about the second snippet? It brings up many questions. What happens once a mod expression has been executed at compile time? If it's an expression then it has to have a result, right? Right. We are still a bit lacking with expressions for now, though, so let's get back to it after we add more.

+ + + diff --git a/articles/xerl-0.3-atomic-expressions/index.html b/articles/xerl-0.3-atomic-expressions/index.html index 5ed954e2..861caedb 100644 --- a/articles/xerl-0.3-atomic-expressions/index.html +++ b/articles/xerl-0.3-atomic-expressions/index.html @@ -69,153 +69,92 @@

-

We will be adding atomic integer expressions to our language. -These look as follow in Erlang:

-
-
-
42.
-

And the result of this expression is of course 42.

-

We will be running this expression at compile time, since we -don’t have the means to run code at runtime yet. This will of -course result in no module being compiled, but that’s OK, it will -allow us to discuss a few important things we’ll have to plan for -later on.

-

First, we must of course accept integers in the tokenizer.

-
-
-
{D}+ : {token, {integer, TokenLine, list_to_integer(TokenChars)}}.
-

We must then accept atomic integer expressions in the parser. -This is a simple change. The integer token is terminal so we need -to add it to the list of terminals, and then we only need to add -it as a possible expression.

-
-
-
expr -> integer : '$1'.
-

A file containing only the number 42 (with no terminating dot) -will give the following result when parsing it. This is incidentally -the same result as when tokenizing.

-
-
-
[{integer,1,42}]
-

We must then evaluate it. We’re going to interpret it for now. -Since the result of this expression is not stored in a variable, -we are going to simply print it on the screen and discard it.

-
-
-
execute(Filename, [{integer, _, Int}|Tail], Modules) ->
-    io:format("integer ~p~n", [Int]),
-    execute(Filename, Tail, Modules).
-

You might think by now that what we’ve done so far this time -is useless. It brings up many interesting questions though.

-
    -
  • -

    -What happens if a file contains two integers? -

    +
    execute(Filename, [{integer, _, Int}|Tail], Modules) ->
+    io:format("integer ~p~n", [Int]),
+    execute(Filename, Tail, Modules).
    +
+

You might think by now that what we've done so far this time is useless. It brings up many interesting questions though.

+
  • What happens if a file contains two integers?
    • -
  • -

    -Can we live without expression separators? -

    +
  • Can we live without expression separators?
    • -
  • -

    -Do we need an interpreter for the compile step? -

    +
  • Do we need an interpreter for the compile step?
    • -
-

This is what happens when we create a file that contains two -integers on two separate lines:

-
-
-
[{integer,1,42},{integer,2,43}]
-

And on the same lines:

-
-
-
[{integer,1,42},{integer,1,43}]
-

Does this mean we do not need separators between expressions? -Not quite. The + and - operators are an -example of why we can’t have nice things. They are ambiguous. They -have two different meanings: make an atomic integer positive or -negative, or perform an addition or a substraction between two -integers. Without a separator you won’t be able to know if the -following snippet is one or two expressions:

-
-
-
42 - 12
-

Can we use the line ending as an expression separator then? -Some languages make whitespace important, often the line -separator becomes the expression separator. I do not think this -is the best idea, it can lead to errors. For example the following -snippet would be two expressions:

-
-
-
Var = some_module:some_function() + some_module:other_function()
-    + another_module:another_function()
-

It is not obvious what would happen unless you are a veteran -of the language, and so we will not go down that road. We will use -an expression separator just like in Erlang: the comma. We will -however allow a trailing comma to make copy pasting code easier, -even if this means some old academics guy will go nuts about it -later on. This trailing comma will be optional and simply discarded -by the parser when encountered. We will implement this next.

-

The question as to how we will handle running expressions -remains. We have two choices here: we can write an interpreter, -or we can compile the code and run it. Writing an interpreter -would require us to do twice the work, and we are lazy, so we will -not do that.

-

You might already know that Erlang does not use the same code -for compiling and for evaluating commands in the shell. The main -reason for this is that in Erlang everything isn’t an expression. -Indeed, the compiler compiles forms which contain expressions, -but you can’t have forms in the shell.

-

How are we going to compile the code that isn’t part of a module -then? What do we need to run at compile-time, anyway? The body of -the file itself, of course. The body of module declarations. That’s -about it.

-

For the file itself, we can simply compile it as a big function -that will be executed. Then, everytime we encounter a module -declaration, we will run the compiler on its body, making its body -essentially a big function that will be executed. The same mechanism -will be applied when we encounter a module declaration at runtime.

-

At runtime there’s nothing else for us to do, the result of this -operation will load all the compiled modules. At compile time we -will also want to save them to a file. We’ll see later how we can -do that.

-
    -
  • -

    -View the source -

    +
    Var = some_module:some_function() + some_module:other_function()
+    + another_module:another_function()
    +
+

It is not obvious what would happen unless you are a veteran of the language, and so we will not go down that road. We will use an expression separator just like in Erlang: the comma. We will however allow a trailing comma to make copy pasting code easier, even if this means some old academics guy will go nuts about it later on. This trailing comma will be optional and simply discarded by the parser when encountered. We will implement this next.

+

The question as to how we will handle running expressions remains. We have two choices here: we can write an interpreter, or we can compile the code and run it. Writing an interpreter would require us to do twice the work, and we are lazy, so we will not do that.

+

You might already know that Erlang does not use the same code for compiling and for evaluating commands in the shell. The main reason for this is that in Erlang everything isn't an expression. Indeed, the compiler compiles forms which contain expressions, but you can't have forms in the shell.

+

How are we going to compile the code that isn't part of a module then? What do we need to run at compile-time, anyway? The body of the file itself, of course. The body of module declarations. That's about it.

+

For the file itself, we can simply compile it as a big function that will be executed. Then, everytime we encounter a module declaration, we will run the compiler on its body, making its body essentially a big function that will be executed. The same mechanism will be applied when we encounter a module declaration at runtime.

+

At runtime there's nothing else for us to do, the result of this operation will load all the compiled modules. At compile time we will also want to save them to a file. We'll see later how we can do that.

+ + + diff --git a/articles/xerl-0.4-expression-separator/index.html b/articles/xerl-0.4-expression-separator/index.html index 1f434d6c..e4dccec9 100644 --- a/articles/xerl-0.4-expression-separator/index.html +++ b/articles/xerl-0.4-expression-separator/index.html @@ -69,58 +69,44 @@

-

As promised we are adding an expression separator this time. -This will be short and easy.

-

In the tokenizer we only need to add a line recognizing the -comma as a valid token.

-
-
-
, : {token, {',', TokenLine}}.
-

Then we need to change the following lines in the parser:

-
-
-
exprs -> expr : ['$1'].
-exprs -> expr exprs : ['$1' | '$2'].
-

And add a comma between the expressions on the second line:

-
-
-
exprs -> expr : ['$1'].
-exprs -> expr ',' exprs : ['$1' | '$3'].
-

That takes care of everything except the optional trailing -comma at the end of our lists of expressions. We just need an -additional rule to take care of this.

-
-
-
exprs -> expr ',' : ['$1'].
-

That’s it.

-

Wondering why we don’t have this optional trailing comma in -Erlang considering how easy it was and the number of people -complaining about it? Yeah, me too. But that’s for someone else -to answer.

-

Another change I want to talk about is a simple modification -of the compiler code to use an #env{} record for -tracking state instead of passing around individual variables. -This will be required later on when we make modules into proper -expressions so I thought it was a good idea to anticipate.

-
+

That's it.

+

Wondering why we don't have this optional trailing comma in Erlang considering how easy it was and the number of people complaining about it? Yeah, me too. But that's for someone else to answer.

+

Another change I want to talk about is a simple modification of the compiler code to use an #env{} record for tracking state instead of passing around individual variables. This will be required later on when we make modules into proper expressions so I thought it was a good idea to anticipate.

+ + + diff --git a/articles/xerl-0.5-intermediate-module/index.html b/articles/xerl-0.5-intermediate-module/index.html index 7bb94d5b..09d6b2d8 100644 --- a/articles/xerl-0.5-intermediate-module/index.html +++ b/articles/xerl-0.5-intermediate-module/index.html @@ -69,136 +69,88 @@

-

Today we will start the work on the intermediate module -that will be used to run the code for the expressions found -in our file’s body, replacing our interpreter.

-

This is what we want to have when all the work is done:

-
-
-
xerl -> tokens -> AST -> intermediate -> cerl
-
-

Today we will perform this work only on the atomic integer -expression however, so we will not build any module at the end. -We have a few more things to take care of before getting there. -This does mean that we completely break compilation of modules -though, so hopefully we can resolve that soon.

-

This intermediate representation is in the form of a module -which contains a single function: run/0. This function -contains all the expressions from our Xerl source file.

-

In the case of a Xerl source file only containing the integer -42, we will obtain the following module ready to -be executed:

-
-
-
-module('$xerl_intermediate').
--export([run/0]).
+
-module('$xerl_intermediate').
+-export([run/0]).
 
-run() ->
-    42.
-

Running it will of course give us a result of 42, -the same we had when interpreting expressions.

-

The resulting Core Erlang code looks like this:

-
-
-
module '$xerl_intermediate' ['run'/0]
-    attributes []
-'run'/0 =
-    fun () ->
-        42
-end
-

The nice thing about doing it like this is that other than the -definition of the intermediate module and its run/0 -function, we can use the same code we are using for generating -the final Beam file. It may also be faster than interpreting -if you have complex modules.

-

Of course this here only works for the simplest cases, as you -cannot declare a module or a function inside another Erlang function. -We will need to wrap these into function calls to the Xerl compiler -that will take care of compiling them, making them available for -any subsequent expression. We will also need to pass the environment -to the run function to keep track of all this.

-

This does mean that we will have different code for compiling -fun and mod expressions when creating -the intermediate module. But the many other expressions don’t need -any special care.

-

Right now we’ve used the '$xerl_intermediate' atom -for the intermediate module name because we only have one, but we -will need to have a more random name later on when we’ll implement -modules this way.

-

The attentive mind will know by now that when compiling a Xerl -file containing one module, we will need to compile two intermediate -modules: one for the file body, and one for the module’s body. Worry -not though, if we only detect mod instructions in the file -body, we can just skip this phase.

-

While we’re at it, we’ll modify our code generator to handle lists -of expressions, which didn’t actually work with integer literals -before.

-

We’re going to use Core Erlang sequences for running the many -expressions. Sequences work like let, except no value -is actually bound. Perfect for our case, since we don’t support -binding values at this time anyway.

-

Sequences have an argument and a body, both being Core Erlang -expressions. The simplest way to have many expressions is to use -a simple expression for the argument and a sequence for the rest -of the expressions. When we encounter the last expression in the -list, we do not create a sequence.

-

The result is this very simple function:

-
-
-
comp_body([Expr]) ->
-    expr(Expr);
-comp_body([Expr|Exprs]) ->
-    Arg = expr(Expr),
-    Body = comp_body(Exprs),
-    cerl:c_seq(Arg, Body).
-

In the case of our example above, a sequence will not be created, -we only have one expression. If we were to have 42, 43, 44 -in our Xerl source file, we would have a result equivalent to the -following before optimization:

-
-
-
-module('$xerl_intermediate').
--export([run/0]).
+
-module('$xerl_intermediate').
+-export([run/0]).
 
-run() ->
-    42,
-    43,
-    44.
-

And the result is of course 44.

-

The resulting Core Erlang code looks like this:

-
-
-
module '$xerl_intermediate' ['run'/0]
-    attributes []
-'run'/0 =
-    fun () ->
-        do  42
-            do  43
-                44
-end
-

Feels very lisp-y, right? Yep.

-
    -
  • -

    -View the source -

    +
    module '$xerl_intermediate' ['run'/0]
+    attributes []
+'run'/0 =
+    fun () ->
+        do  42
+            do  43
+                44
+end
    +
+

Feels very lisp-y, right? Yep.

+ + + -- cgit v1.2.3