Steve Vinoski's Blog

Yesterday I posted a SHA-256 Erlang module, but I figured since other SHA algorithms are similar, I might as well finish the job. I grabbed the Secure Hash Standard and went to work.

The resulting new module is named sha2 and it implements SHA-224, SHA-256, SHA-384, and SHA-512.

• Code
• Light documentation
• Tests are included in the module but you get the test vectors here
• It’s open source, BSD license

I hope you find it useful.

Sriram Krishnan was recently lamenting the lack of SHA-256 support in Erlang’s crypto module, so just for fun I wrote a simple sha256 module based on the pseudocode in Wikipedia. The tests use the test data from this C implementation.

[Update: I’ve posted a new module that implements more SHA digest variants and so renders this module obsolete.]

If you’re writing RESTful web services, you need to be able to parse HTTP Accept and Content-type headers. The Accept header tells you what media types the client can handle, and Content-type tells you what the client is sending when it invokes PUT or POST.

Several years ago Joe Gregorio wrote a really nice article explaining how to properly handle such parsing, and he implemented his ideas in the form of the mimeparse Python module. Later, others added Ruby and PHP versions.

In my Erlang web services work I’ve been doing just enough to parse my Accept headers, knowing full well my approach had holes in it and would eventually need to be done right. When I recently stumbled on Joe’s article and code, I decided to port it to Erlang and use it. Joe’s code is very clean and has accompanying unit tests, so the port was pretty easy. However, in the process of plugging it into my system I found a reasonably common case where the best_match function would return a wildcard match in preference to an exact match, so I added unit tests for that case and repaired the problem for all four languages.

I also found that Java’s URLConnection class, or maybe it’s HttpURLConnection, sends a plain “*” as a wildcard MIME type, which I don’t believe is legal (please correct me if I’m wrong), but since I figure there’s probably more than a few clients out there based on that code, I modified the four mimeparse implementations to handle that as well, treating it as “*/*”.

All four implementations are available from the mimeparse project home page.

I’ve noticed that frequently in technical discussions, the strongest disagreements seem to come from people with little to no actual experience with the technology they’re arguing against. How can that be? For example:

• Test-First Development. I wish I had a dollar for every time I’ve suggested to a developer that writing their tests before or along with writing their code will make the code not only easier to write but also more robust coming out of the gate, and I get back responses like, “What? That’s crazy! How can you write tests before you have any code? That doesn’t make any sense!” Having an initial reaction like that isn’t such a big deal, as I’ve seen numerous developers who have such reactions actually try the “test first” approach and quickly become strong advocates who wonder how they ever did without it. The point is, though, that they actually tried it. Arguing with them before they tried it always turned out to be a total waste of time. No amount of words seemed to convince them. They had to experience it before they understood it.

• Erlang syntax. Erlang is getting more and more attention these days, and rightfully so, but a typical reaction from those who have written little to no Erlang code is that the language’s syntax is too weird, too hard to read and write, etc. Is the syntax different? Yes. Is it weird or difficult? No, not at all — in fact, it’s actually very simple and regular when compared to popular general-purpose imperative languages. Spend a day or two writing some real Erlang code, and I guarantee you that any initial dislike you might have for its syntax will disappear.

• REST. If you search the blog of any REST proponent, including this one, you’re sure to find all kinds of comments from detractors who argue against REST despite never having used it to develop any real systems. Similarly, the blogs of many WS-* advocates who have never tried using REST contain all kinds of reasons why REST can’t possibly work. Check out the comments in Damien Katz’s recent “REST, I just don’t get it” posting, for example; you have useful ones from those who have obviously used REST and understand its benefits, and then you have other comments that argue against REST while simultaneously showing a great misunderstanding of it. Those detractors would do well to read Bill de hÓra’s excellent response.

Also interesting about these three particular cases is that I don’t personally know of anyone who’s actually tried the approaches and decided against them. In a posting last November, for example, I asked for comments from anyone who had actually tried REST for real and with an open mind, but decided that it was inferior to WS-* and so abandoned it. Either nobody read that posting or no such people exist. I’m fairly confident it’s the latter.

There will always be arguments made by people whose livelihood is somehow threatened by the approach they’re opposing, but I don’t think that’s the source of all the opposing arguments. As developers we can’t possibly try everything, of course, because there just isn’t enough time. It’s inevitable that we’ll sometimes have to resort to researching an approach via only reading, questions and discussion and decide against it without prototyping. But ultimately we developers owe it to ourselves and our employers to keep ourselves objectively informed so that we can take advantage of new approaches whenever appropriate. When a whole bunch of smart developers have success with a particular approach, I don’t see how any responsible developer can actively and vocally oppose it without first objectively trying the approach and experiencing it firsthand.

Joe Armstrong explains the background of the distributed computing capabilities within Erlang.

I find postings like Joe’s highly valuable. Few among us are language designers, so rarely do those of us who aren’t get a first-hand account from someone who is as to why and how something within a given language’s design came to be. Joe describes the distribution primitives that Erlang provides as well as their composability; it might seem simple, but anyone who’s written non-trivial distributed computing infrastructure knows that choosing the right primitives and making the right design trade-offs is anything but simple. This explains why I continue to be so impressed with the design choices and trade-offs Joe and crew made for Erlang — I’ve simply never seen any distributed computing infrastructure so elegant and yet so practical and capable.