RESTful Web Services Example 3.19 - SHA1 Signing

The Amazon S3 examples explained in Chapter 3 of the RESTful Web Services book have a top-down order: the first examples explain the high-level workings of the system, while the final ones explain details such as request signing etc.
Since in this conversion notes I assume you are familiar with Richardson & Ruby’s book, I will start from the bottom and climb my way up to the most high-level examples.

For these reason I’ll start with a helper method that is used to sign the HTTP requests: #signString:.

If you load the package RWS-gc.10 from the RWS repository, you’ll see a new class called S3Object:

Object subclass: #S3Object
    instanceVariableNames: 'publicKey privateKey'
    classVariableNames: 'AmazonHeaderPrefix InterestingHeaders'
    poolDictionaries: ''
    category: 'RWS-Examples'

This class plays the same role as the Ruby S3::Authorized module. All the Squeak classes in the examples will be subclasses of S3Object.

S3Object has two instance variables to hold the public and private keys that Amazon has assigned to you when you signed up for its Amazon Web Services program.
It also has two class variables that hold useful constants. These class variables are initialized in the S3Object class>>initialize method:

S3Object class>>initialize
    InterestingHeaders := #('content-type' 'content-md5' 'date').
    AmazonHeaderPrefix := 'x-amz-'

The example I’ll show here is the #signString: method. This method computes a base64 encoding of the HMAC-SHA1 digest of its argument.

signString: aString
    | hmac digest |
    "Signs a string with the client's secret access key, and encodes the
    resulting binary string into plain ASCII with base64.
    Code taken from RESTful Web Services. Copyright © 2007 O'Reilly Media, Inc.
    All rights reserved. Used with permission."
    hmac := SHA1 new hmac.
    hmac key: privateKey asByteArray.
    digest := hmac digestMessage: aString asByteArray.
    ^ Base64MimeConverter mimeEncode: (ReadStream on: digest)

The Smalltalk code is similar to the Ruby source, but with a couple of lesser differences.
The first is that Squeak’s HMAC class requires instances of the ByteArray class instead of plain strings, due to the multilingual support built into the latest version of Squeak. The second difference is that Squeak’s base64 requires a stream instead of a String or a ByteArray, as per the standard Smalltalk idiom.

In the next post, I’ll show another helper method, canonicalStringFor:path:headers:expires:.

#squeak is getting crowded

I usually hang out on Squeak’s IRC channel on the Freenode network, to chat with other Squeak developers and to occasionally help the newcomers.

Lately, with the Summer of Code and the new Squeak book, there’s been a constant influx of new people in the channel.

So today, a little time before dinner, I suddenly realized that there were more than 60 people on the channel:



I believe it’s a new record ;-)

RESTful Web Services - Preparing for Chapter 3

In a couple of days we’ll move to the examples in Chapter 3 of Richardson and Ruby’s book.
Before that, we need to add a couple of package to our image. These packages are the Cryptography Team Package and Steve Waring’s HTTP Client, both available on the Squeak Map.
We’ll also need either a working account for Amazon’s S3 service, or a working Park Place server.

The Cryptography Team Package

The Cryptography Team Package is one of the three crypto packages available on Squeak Map. It is the product of the work of Squeak’s Cryptography team, headed by Ron Teitelbaum.

In order to install it, just open the Squeak Map Package Loader tool, select the package and then select Install from the menu.

Steve Waring’s HTTP Client

The other package we’ll need is an HTTP 1.1 Client originally created by Steve Waring’s for Dolphin Smalltalk and ported to Squeak by Brent Vukmer and others. We’ll use it for Chapter 3’s example instead of the CurlPlugin, since the latter doesn’t expose some libCurl APIs that we need.

To install this package, use the Squeak Map Package Loader as for the previous package. The name of this package is HTTP Client.

Edit 10/Oct/2007: Unfortunately, this HTTP Client does not support all the features needed for the Squeak versions of the Chapter 3 examples, so it won’t be used at all; CurlPlugin will be used instead. See this post for more information.

Once we have installed these packages, we’re ready for Chapter 3’s first example: an Amazon S3 client.

The Paolo Fresu Angel Quartet - Metamorfosi

Uno degli ultimi ingressi nella mia collezione è un CD del 1998: Metamorfosi del Paolo Fresu Angel Quartet.



Al quartetto base, composto dal leader Paolo Fresu, dal chitarrista Nguyên Lê, dal contrabassista Furio di Castri e dal batterista Roberto Gatto, si unisce per alcune tracce il suono della fisarmonica di Antonello Salis.

Il quartetto si è sciolto da tempo, sostituito dal più recente Devil Quartet, ma si è riunito di nuovo quest’estate in occasione della XX edizione del festival Time in Jazz di Berchidda, dove ho avuto modo di apprezzarlo.

Il disco ha confermato le mie impressioni positive. In particolare mi sono piaciute le tracce The Open Trio, Pong e Don’t Ask, rispettivamente a firma di Fresu, Lê e Gatto.

Of Trucks and Numbers

While chatting with some acquaintances today, I found out that not many people are familiar with the concept of truck number.

The truck number of a software developement project may be informally defined as “the number of team members of your project that have to be run over by a truck in order to have your project going to the dogs”.

Obviously, “being run over by a truck” is just a cheeky figure of speech; in reality it may be a developer resigning with no advance notice, or with sudden, serious health problems, etc. So the Truck Number is really one of the measures of risk associated with your project’s personnel.

As Cockburn and Williams notice, the worst truck number your project can have is “one”: if, for example, you have only one person with deep knowlegde of a vital subsystem, or only one who knows the in-and-outs of your architecture, your project is in serious trouble if you suddenly lose this person.

So, as a measure of risk mitigation, you should strive to have the highest truck number possible. Cockburn and Williams propose Pair Programming as a solution to this problem, but other solutions may be equally valid: daily meetings, better documentation, etc.

Update: the first definition I wrote wasn’t so clear, so I re-wrote it.

Michael Brecker - Pilgrimage

Nei mesi estivi ho comprato un certo numero di CD. Tra questi, uno di quelli che mi ha colpito di più è stato Pilgrimage, l’album postumo di Michael Brecker.



Conoscevo questo sassofonista solo di nome, ma dopo aver letto un articolo commemorativo su Jazzit mi sono incuriosito e ho acquistato questo suo ultimo CD, uscito postumo. Sono rimasto molto colpito sia dal sax di Brecker, che dalla bellezza e vitalità delle sue composizioni, eseguite dall’ottimo ensemble riunito da Brecker apposta per questo album.

Per una recensione di questo album fatta da qualcuno che se ne intende sul serio di queste cose, vi rimando a questo articolo su allaboutjazz.com.

Why Jazz Programming?

Maybe some of my 7 readers (source: Google Analytics) are wondering why this new name. The reason is simple: the old name was fun and cheeky, but it didn’t really describe what I’d like this blog to be. So I chose the new name basing it on what my two main interests currently are.

Furthermore, I think there are some analogies between Jazz and Software Engineering, especially Agile Methodologies. The first that come to my mind are:

• both a jazz player and an agile programmer can do well in solo, but give thier best in a group/team.


• both a jazz player and an agile programmer look at each session as a chance for improvement.


• both a jazz player and an agile programmer strive continuosly for improvement.

If any of you has other analogies, why not leave them in a comment?