Jazz Programming

ECMAScript 4

2007-11-06T09:07:00.000-08:00

ECMAScript is the standardized form of the language known as JavaScript. In its current incarnation, it is a nice little prototype-based object language that unfortunately is plagued by some warts (peruse this blog post to read about some of them) and by DOM implementation riddled with bugs and security problems. This, according to Douglas Crockford, makes it “the world’s most misunderstood programming language”.

The guys at Ecmascript.org are actively working on a new revision of the standard, and have recently published a new proposal for ECMAScript, edition 4, complete with a reference implementation. This new proposal looks like a 180° turn from the current language, moving to a class-based object orientation paradigm, with multimethods, optional static typing, etc.

The proposal has been well-received by programming-languages researchers and aficionados, such as those at Lambda the Ultimate. But many others, such as Dave “Smalltalk” Thomas, have voiced their opposition to this new standard:

Just browsing through the wiki shows a language which has prototypes, classes, multi-methods?, static types, dynamic types, etc, etc. This reminds an old guy like myself of other large design by committee languages such as PL/I, Algol 68 and ADA. These ambitious efforts all had smart people involved in the design and implementation but were unfortunately far too complex and came to the market too late. JS is intended to be a language for the people, not another language that only technical wizards can understand. If you are an Ajax developer or care about dynamic languages I suggest that it is time for you to speak up and help put ECMAScript 4 on a much less ambitious path than is currently being charted. Less is truly more when it comes to languages.

My friend Riffraff has too a good critique of the proposal:

The second system syndrome is that evil effect that often happens when redesign a small, working system so that it becomes a huge leviathan built by piling new features over new features.

Today I was reading the overview of ECMASCript 4 from ecmascript.org, and I got this very bad feeling that maybe the fourth version of ES, is suffering of an extremely strong case of this problem.*

To make things worse, it looks like there’s some sort of fracture in the ECMAScript 4 working group, with Adobe and Mozilla on one side, and Microsoft and Yahoo! on the other.

In my opiion, all of this doesn’t bode well for the new language. Are we going towards another browser war?

HttpView2 1.1-beta

2007-11-06T00:12:00.000-08:00

Yesterday I released a first beta version of HttpView2. This is the first development release of HV2 since Goran published version 1.0 in November 2004.

HttpView2 (aka HV2) is a little, lean web framework for Squeak. Since Goran, the original author, has given me complete development freedom, I’m steering HV2 away from being a framework for web applications and towards being one for RESTful web services.

Highlights of this new development release include:

a new, generic Canvas system

a new XHTML Canvas system, inspired by Seaside’s one.

HTTP responses are now accessible from the various View methods

source code reorganization

HV2 1.1 is available on Squeak Map. If you have any bug reports, or you’re interested in helping, drop me a line in the comments.

RESTful Web Services Example 3.4 - Obtaining a list of buckets

2007-10-31T23:03:00.000-07:00

Example 3.4 of the RESTful Web Services deals with obtaining a list of buckets (think of them as top-leve directories). This first version of the code will return a collection of strings, each one being the name of a single bucket. This is done by sending #getBuckets to an S3BucketList instance.

If you load the latest code (RWS-gc.25) from the RWS repository you’ll see many new changes. The ones we’re interested into are the S3Authorized class and the S3BucketList class.

The former is a class extracted via refactorings from the S3Object class, while the latter allows you to get the list of your buckets.

Take a look at S3BucketList>>getBuckets. The method is defined as:

S3BucketList>>getBuckets
    | doc |
    "Fetch all the buckets this user has defined.

    Code taken from RESTful Web Services. Copyright © 2007 O'Reilly Media, Inc.
    All rights reserved. Used with permission."

    "GET the bucket list URI and build an XML DOM tree from it."
    doc := XMLDOMParser 
            parseDocumentFrom: (self get: Host) contents readStream.
    "For every bucket, collect its name"
    ^ doc // 'Bucket' / 'Name' collect: [:each | each contentString]

As you may see, the Smalltalk code is shorter than the corresponding Ruby code. That’s because we used Pastell, an XPath-like DSL for navigating XML DOM trees, instead of using a separate XPath library.

The first line of code creates a DOM tree from the XML document obtained by sending #get: to itself. #get: is one of the new messages added in the previous post.

In the second line, the DOM tree is sent a #// message. This message selects all the descendant nodes of an XML node whose name matches the argument of the message. In this example, the result of this message send will be a collection of nodes whose tag is 'Bucket'. This collection is a special subclass of OrderedCollection that can understand the Pastell messages, called PastellCollection

The list of nodes is sent another Pastell message, #/. This message selects all the child nodes whose tag matches the argument of the message. In this example, when sent to the PastellCollection instance returned by #//, it returns another PastellCollection whose elements have a 'Name' tag. We can retrieve the actual names of this elements by collect:ing their contentStrings.

In the next two examples, we’ll see how to model a single bucket as a Squeak object, and how to modify S3BucketList>>getBuckets in order to make it return a collection of objects instead of strings.

RESTful Web Services - A Better HTTP interface

2007-10-29T10:04:00.000-07:00

Before moving to the remaining Amazon S3 examples from Chapter 3 of the RESTFul Web Services book, let’s take another look at the code. The previous examples were strongly inspired by the corresponding Ruby examples. This, paired with the use of the libCurl bindings, has led to code which is brittle and hard to modify.

As an example, let’s consider the code for S3Object>>open:method:headers:. This method requires the HTTP method in order to compute the correct signature for the request, but then ignores it by sending request download, which is the message used to send a GET request. A possible solution for this is to use a case-like solution in order to send the right message; the code would then become something like this:

(method asLowercase == 'put')
    ifTrue: [request upload]
    ifFalse: [request download]

Now, this isn’t just ugly, it’s plain bad OO code. This means we have to look for another solution.

The solution that I’ve chosen is based on the pattern used for Seaside’s and HV2’s Canvas systems. It involves having an S3Request object that wraps a Curl instance and provides a simple interface. S3Request has different subclasses for the various HTTP methods: S3GetRequest, S3PutRequest etc.

The code for S3Request and its subclasses may be found in package RWS-gc.20 from the RWS repository. S3Request is defined as:

Object subclass: #S3Request
    instanceVariableNames: 'headers url request contents'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'RWS-Examples'

I won’t provide a detailed explaination for this class, save for the #send message:

S3Request>>send
    request := Curl new.
    request url: url.
    headers keysAndValuesDo:
        [:key :value |
        request addHeader: key, ': ', value].
    request onHttpHeaders.
    self perform.
^ request

#send creates a new Curl object, sets the headers and url for the new request, then sends a #perform message to itself before returning the Curl object. #perform is an abstract message implemented by the various subclasses of S3Request. For example, S3PutRequest>>perform looks like

S3PutRequest>>perform
    contents ifNotNil: [request contents: contents].
    request upload

This is a simple and elegant solution to our problem that, while adding 5 new classes to the system, keeps the overall complexity of the code to a much lower level.

In order to use this new API, I’ve added some more messages to the protocols of S3Object. If you browse the latest versions of this class, you’ll find many methods such as #get:headers:, #put:contents:headers: etc. This methods replace the #open:method:headers: message and its variants.

In the next post, we’ll see how to interact with the Amazon S3 service. Meanwhile, I suggest you go over Chapter 3 of Richardson and Ruby’s book in order to get yourself acquainted with S3’s lingo.

KomHttpServer 7.0.5

2007-10-26T12:17:00.000-07:00

In the past days I’ve become one of the mantainers of KomHttpServer, Squeak’s native HTTP server. I’ve just released a new version (available on Squeak Map) that includes various bug fixes, and HTTP 1.1 compliant status codes (plus some WebDAV ones, too).

I’d like to thank Goran, Ron, Philippe and all the others for the work they’ve done on Kom’s source code.

Vito Di Modugno Organ Quartet plays Haitian Fight Song

2007-10-24T15:32:00.000-07:00

Charles Mingus’ Haitian Fight Song (and its later variant II B.S.) is one of my favourite jazz pieces. And the organ, especially the Hammond organ, is one of my favourite musical instruments. So I was very pleased to find on Youtube a version of Haitian Fight Song played by the Vito di Modugno Organ Quartet. Here is it, for your hearing pleasure:

Miles Davis - So What 1958 & 1964

2007-10-23T13:44:00.000-07:00

Looks like I’m not the only one with a blog who’s interested in Jazz and programming. Patrick Logan just published a wonderful post about Miles Davis’ So What So What is a track from the Kind of Blue album, and Patrick compares two different versions of it: the first one from 1958, the second one from 1964. It’s difficult to say which one I prefer.

Incidentally, just ten days ago in the #verbamanent IRC channel we briefly discussed and compared Davis’ Kind of Blue, Coltrane’s A Love Supreme and Mingus’ The Black Saint & The Sinner Lady. The comparision is a little inappropriate, since Kind of Blue precedes the other two albums by roughly five years, but it’s interesting nonetheless. I’m going to write more about these three albums in another post.

RESTful Web Services - Bugfixing CurlPlugin

2007-10-22T11:36:00.000-07:00

Before moving to today’s example, in which we’re going to start interacting with the Amazon S3 server, I’ll take a diversion to explain why all this lateness. As I wrote in the previous post, this example is so late because of a bug in CurlPlugin that I introduced myself.

The original CurlPlugin didn’t expose at the Smalltalk level the functionalities for setting custom HTTP headers in the request, so I had to add these functionalities to the plugin. When I did that, I overlooked the fact that a Smalltalk string and a C string aren’t implemented in the same way: a Smalltalk string, being a Collection subclass, has an arrayed collection of character elements (either 8-bit or 32-bit wide) and an explicit size attribute, while a C string is a NULL-termined array of char.

This means that since you can’t be sure of the fact that, in the internal representation of a Smalltalk string, the value after the last character of the string will be a NULL, you have to explicitly add one. Since I forgot to do so (by sending a simple #asCString message, provided by CurlPlugin), I introduced a tricky bug in the plugin. To make things worse, this bug showed itself only when the string was longer than usual. So, when adding to the request short headers such as Date: or Content-Type: there were no problems, while the Authorization: header always had some spurious trailing characters.

In order to detect this bug, I had to install a packet sniffer, learn how to use it, and look at what libCurl was actually sending to the server. As it often happens, once the problem was identified, fixing it was a matter of minutes.

Now that the bug is fixed, you’ll have to download the new version of the CurlPlugin. Extract the archive, overwrite the CurlPlugin file in your image directory, file in the new Curl.st file, and you’ll be ready for the next example.

RESTful Web Services Example 3.16 - Signing the request

2007-10-21T12:49:00.000-07:00

After little less than a month, let’s resume with the Squeak Smalltalk versions of the examples of the RESTful Web Services. This latest installment is so late due to a bug that I introduced in the CurlPlugin code when adding a new primitive, and it took me a long while to debug it. The new primitive is needed for the next example in this series.

We already know how to build a canonical string, and how to actually sign it. In today’s example, we’ll see how the request signature is created from the URI, the HTTP method, and the headers.
This is the task of the #signatureFor:method:headers:expires: method and its ilk.

The source for S3Object>>signatureFor:method:headers:expires: is the following:

S3Object>>#signatureFor: aStringOrUri method: method headers: headers expires: expires
    | uri path |
    "Builds the cryptographic signature for an HTTP request. This is
    the signature (signed with your private key) of a 'canonical
    string' containing all interesting information about the request.

    Code taken from RESTful Web Services. Copyright © 2007 O'Reilly Media, Inc.
    All rights reserved. Used with permission."

    "Accept the URI either as a Squeak URI object, or as a string"
    uri := aStringOrUri asURI.
    path := uri query ifNil: [uri path] ifNotNil: [uri path, uri query].

    "Build the canonical string, then sign it"
    ^ self signString: (self canonicalStringFor: method path: path headers: headers expires: expires)

The method is very simple, but there are a couple of observations that may be done.

The first observation is about the uri temporary variable: since the aStringOrUri parameter, as the name says, may be either a string or an URI, we send the #asURI message in order to be sure that uri holds an URI object (this way of ensuring that an object is of the appropriate class is a common pattern in Smalltalk).
Once we are sure we have an URI object, we extract the path from the URI, plus the optional query string (the part of the URI after the ? character).

Finally, we build the canonical string, sign it and return the signature.

The source code for this method is included in the RWS-gc.14 package in the RWS repository. In the same package you will find other variations of the same method:

`S3Object>>#signatureFor:method:headers:`
`S3Object>>#signatureFor:method:`
`S3Object>>#signatureFor:headers:`
`S3Object>>#signatureFor:`

If you browse the source code for these methods, you’ll observe that all these methods send the #signatureFor:method:headers:expires: message with the appropriate default parameters. This is a very common pattern in Smalltalk, but it has one serious flaw, as the sheer number of possible combinations makes this solution unpractical on a large scale. For example, a message with four parameters may have other 14 possible variants, while one with five parameters has 30 possible variants.

This combinatorial explosion is somewhat mitigated by the fact that usually there’s only a restricted subset of sensible and useful variants of a message, but in many cases this is not enough. This is one of the reason why Seaside moved from a builder system to a canvas one for (X)HTML generation.

In the next post in this series, we’ll see how to send a signed request to the Amazon S3 service.

RESTful Web Services Example 3.18 - Building the canonical string

2007-09-24T12:14:00.000-07:00

Today’s RESTful Web Services example is another utility method named #canonicalStringFor:path:headers:expires:. This method builds the string that will be used to sign the HTTP request.

According to the Amazon S3 Developer Guide, the canonical string is composed with the HTTP request method, the request path and some of the headers of the request. I refer you to either the S3 docs or to the RWS book for more information on how the string is built.

The code for #canonicalStringFor:path:headers:expires: is the following:

S3Object>>canonicalStringFor: method path: path headers: headers expires: expires
    | signHeaders canonical param |
    "Turns the elements of an HTTP request into a string that can be
    signed to prove a request comes from your web service account.
    Code taken from RESTful Web Services. Copyright © 2007 O'Reilly Media, Inc.
    All rights reserved. Used with permission."

    "Start out with default values for all the interesting headers."
    signHeaders := Dictionary new.
    InterestingHeaders do: [:header | signHeaders at: header put: String new].

    "Copy in any actual values, including values for custom S3 headers."
    headers keysAndValuesDo:
        [:header :value |
        header isString ifTrue:
            [header := header asLowercase.
            "If it's a custom header, or one Amazon thinks is interesting..."
            ((InterestingHeaders includes: header) or:
                [header beginsWith: AmazonHeaderPrefix]) ifTrue:
                    [signHeaders at: header put: value asString]]].

    "This library eliminates the need for the x-amz-date header that Amazon defines,
    but someone might set it anyway. If they do, we'll do without HTTP's standard Date header."
    (signHeaders includesKey: 'x-amz-date') ifTrue: [signHeaders at: 'date 'put: String new].

    "If an expiration time was provided, it overrides any Date header.
    This signature will be valid until the expiration time,
        not only during the single second designated by the Date header."
    expires ifNotNil: [signHeaders at: 'date' put: expires].

    "Now we start building the canonical string for this request. We start with the HTTP method."
    canonical := WriteStream on: String new.
    canonical
        nextPutAll: method asUppercase;
        nextPutAll: String cr.

    "Sort the headers by name, and append them (or just their values) to the string to be signed."
    signHeaders associations sort do:
        [:assoc | | header value |
        header := assoc key.
        value := assoc value.
        (header beginsWith: AmazonHeaderPrefix) ifTrue:
            [canonical
                nextPutAll: header;
                nextPutAll: ':'].
        canonical
            nextPutAll: value;
            nextPutAll: String cr].

    "The final part of the string to be signed is the URI path.
    We strip off the query string, and (if neccessary) tack one of the
    special S3 query parameters back on: 'acl', 'torrent', or 'logging'."
    canonical nextPutAll: (path copyUpTo: $?).

    param := #('acl' 'torrent' 'logging')
        detect: [:each | path includesSubString: '?', each]
        ifNone: [nil].
    param ifNotNil:
        [canonical
            nextPutAll: '?';
            nextPutAll: param].

    ^ canonical contents

This is quite a long method according to Smalltalk’s standards, but it is a straightforward mapping of the Ruby one explained in the RWS book. Were I to built a real S3 library, I’d probably create something similar to Seaside’s and HV2’s Canvas systems.

The most glaring difference between this Smalltalk code and the Ruby one is how the path is handled. S3 requires you to strip the query string (that is, the part after the question mark) and to attach back one of the S3 query parameters (acl, torrent, and logging) in case it’s part of the query string. Richardson and Ruby use a regular expression to identify these parameters. I chose a simpler method on the account that, according to the S3 documentation, each request may have only one of the three special S3 parameters. So I just look for a string such as ?acl and, if found, I attach it to the canonical string.

Another difference is in how headers are handled. Ruby’s Dictionary class has a #sort_by message that returns a sorted collection over which we can iterate. Smalltalk’s dictionaries don’t have this feature, so I have to send an #associations message to obtain a sequential collections of associations. I iterate over this collection with an unary block that takes a single association as the argument of its #value: message. In this example I split the association into its key and value and put them into two block temporary variables. This is done only for sake of clarity.

In the next example in this series, we’ll see the other two messages understood by S3Object: the one we’ll use for signing the request and the one we’ll use for sending the HTTP request.

RESTful Web Services Example 3.19 - SHA1 Signing

2007-09-22T13:06:00.000-07:00

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

2007-09-21T23:15:00.000-07:00

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

2007-09-21T22:45:00.000-07:00

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

2007-09-20T16:25:00.000-07:00

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

2007-09-19T13:19:00.000-07:00

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

2007-09-17T15:37:00.000-07:00

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?

2007-09-16T14:51:00.000-07:00

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?

An HttpView2 Canvas sample

2007-08-01T14:34:00.000-07:00

Here's a quick example on how to use the new Canvas system of HV2.

First of all, create an new TestView class as a subclass of HVTransientView:

HVTransientView subclass: #TestView
 instanceVariableNames: ''
 classVariableNames: ''
 poolDictionaries: ''
 category: 'Test'

Then, create a default method as follows:

default
 | canvas |
 canvas := self canvas.
 canvas html:
  [canvas head: [canvas title text: 'Test!'].
  canvas body:
   [canvas h1 text: 'A test of HV2''s new Canvas system'.
   canvas p text: 'This is a simple test of the latest HV2 version']].
 ^ canvas

To start the engine, type the following on a Workspace then DoIt:

TestView startOn: 8080.

As soon as the HV2 engine has started, you can point your browser to http://localhost:8080/. Here's a screenshot of what you'll see:.

You should also note that you can omit the ^ canvas expression in the default method. If you do so, HV2 will retrieve the response from the TestView instance itself.

HttpView2 status report

2007-08-01T14:03:00.000-07:00

In the past days, I've continued working on HttpView2.

I've completed support for XHTML 1.1 in class HVXHTMLCanvas . I've also extracted from HVXHTMLCanvas an HVCanvas class that provides support for generic XML documents.

On the other hand, I've decided to scrap the current HVPainter system and punt the new one to the next release of HV2.

The other big change from HV2's current stable release is related to the HTTP response. In the stable release (1.0x), the HTTP response is automatically created from the builder and the user has no control over it. In the current development release, the HttpResponse object has been exposed in the HVTransientView class. The various URL methods may access it, modify the status code, the content type and the contents itself.

With these modifications, HV2 may be used (albeit awkwardly) as a simple engine for RESTful web services.

As soon as Goran, HV2's mantainer, gets back from his vacations we'll publish the new development version on the SqueakMap. Meanwhile, you may find the code on the Monticello repository as version HV-gc.132.

HttpView2's Canvas/Painter system

2007-07-22T16:00:00.000-07:00

Most of my work on HV2 involves the creation of a new Canvas/Painter system. This is heavily inspired by Seaside's Canvas system, but has a couple of key differences.

Seaside's Canvas system is based around three classes.
The first, WACanvas, has the basic infrastructure for producing HTML tags.
The second, WAHtmlCanvas, is a WACanvas subclass that adds support for "static" HTML tags (such as <p>, <div>, etc.).
The last class is the main one you're going to use in Seaside: WARenderCanvas. This is a subclass of WAHtmlCanvas that adds support for the "dynamic" tags of HTML: forms, input fields etc, and is the most integrated with the other parts of Seaside.

I've pondered whether to reuse Seaside's Canvas system or not, and in the end I've decided against it: adapting it to HV2 would entail more work than creating a new system from scratch. Also, having another implementation of a Canvas system allows exploring other possible solutions to the problem of creating HTML from Smalltalk code.

HV2's Canvas/Painter system is similar to Seaside's Canvas one. There's a canvas class, currently named HVXHTMLCanvas, whose purpose is to produce HTML tags on a stream.

The user should use HVXHTMLCanvas directly, but should instead use an HVPainter instance. This painter class delegates most of the work to the canvas, but adds some high-level behavior like autonaming of form fields and automated retrieval of the values of the fields of a POST request.
Here's a snippet from a test application I'm building to test HV2's Canvas/Painter system:

painter form withFieldset: 
 [summary := painter textField
   label: 'Summary';
   value: model summary.
 location := painter painter textField
   label: 'Location';
   value: model location.
 "..."
 description := painter painter textField
   label: 'Description';
   value: model description.
 button := painter submitButton value: 'Save'].
"..."
button ifPressed:
  [model summary: summary value.
  model location: location value.
  model description: description value.
  "..."
  self redirectToDefault].

A nice change from HV2's old Builder system is that the form-autonaming feature of the new Canvas/Painter system may be easily overridden by the user: in the previous system, I could have used

painter textField
 label: 'Summary';
 name: 'summary';
 value: model summary.

to create a text input field whose name would have been 'summary' instead of the name computed by HV2's Painter.

Working on HttpView2

2007-07-22T15:37:00.000-07:00

As you may have noticed, in the past two weeks I've been silent. The reason for this is that I've been working on a couple of Smalltalk projects that have monopolized my attention.

One of these projects is HttpView2, also known as HV2. HV2 is the web framework behind SqueakMap. It's a nice little framework, and is a good complement to Seaside.

I'm actively involved in the development of the next version of HV2. In particular, I'm building a new Canvas/Painter system to replace HV2's current Builder system. I'll write another post with more details on the new canvas system.

I've also been exploring how to restructure HV2 to ease the creation of RESTful web services. I've a couple of ideas in mind: an easier access to the HTTP Response, more specialized View objects for single items and collections, and a few more that I still have to ponder.

The new HV2 version hasn't been released yet; you can grab my latest version of it from this (readonly) Monticello repository.

Birras

2007-07-08T11:28:00.000-07:00

Ieri con un paio di amici siamo andati a Birras, la prima festa delle birre artigianali sarde.

La festa si è svolta in alcuni dei locali del Pozzo Sartori della miniera di Montevecchio.

Erano presenti degli stand per degustare le birre dei sei produttori artigianali al momento presenti in Sardegna. In particolare ho apprezzato la Montevecchio chiara (nota un tempo anche come birra Dolomiti), la Dolmen chiara, la Janas Beer rossa e la Toccadibò della Barley. Non mi ha invece entusiasmato la chiara della Orteip’s Bir, che ho trovato troppo dolce.

Purtroppo al mio arrivo la degustazione guidata era già in corso, e non abbiamo voluto trattenerci fino all’inizio della degustazione successiva. In compenso siamo riusciti a seguire la dimostrazione pratica di homebrewing offerta dagli HomeBrewers Sardi.

Smalltalk & Simple Design

2007-07-05T09:14:00.000-07:00

On the Extreme Programming mailing list, Ron Jeffries and others are explaining and defending why Smalltalk allows simpler designs than other languages.

Go read the whole thread, or start from this message.

RESTful Web Services Example 2.15 - Yahoo! News Search w/ JSON

2007-07-03T14:12:00.000-07:00

The final example from Chapter 2 of the RESTful Web Services book that I'll be converting to Squeak is another version of the Yahoo! Web Search, this time using JSON and, to spice things up a little, the news search service instead of the web search one.

In order to get this example to work, you'll have to install Squeak's JSON package, available from SqueakSource.

Here's the code for the example:

yahooNewsSearch: aString
 | baseURI document term json |
 "Code taken from RESTful Web Services. Copyright © 2007 O'Reilly Media, Inc.
 All rights reserved. Used with permission."
 baseURI := 'http://api.search.yahoo.com/NewsSearchService/V1/newsSearch'.
 term := aString encodeForHTTP.
 json := Curl new getContentsUrl: baseURI , '?appid=restbook&output=json&query=' , term.
 document := Json readFrom: json readStream.
 ((document at: #ResultSet) at: #Result) do:
  [:element |
  Transcript
   show: (element at: #Title) printString;
   cr]

There isn't much to say about this example that hasn't been said for Example 2.1: the document returned from the #getContentsUrl: send is a JSON script that is fed to Squeak's JSON parser. The parser returns a nested structure of Dictionaries and Arrays that can be accessed with the standard at: message. The results are then printed to the Transcript, as usual.

The code for this method may be found in package RWS-gc.8 in the RWS repository.

This post concludes the series of examples from Chapter 3 of the RWS book. In the next posts (coming next week or so) I'll show examples from Chapter 3, including a complete implementation of a Squeak client for the Amazon S3 service.

The Bad Plus - Give

2007-07-02T12:13:00.000-07:00

L’ultima entry nella mia collezione di CD è un album del 2004: Give dei Bad Plus.

Mi piacerebbe farne una recensione, ma decisamente mi mancano le competenze per scrivere un articolo ben fatto sull’argomento. Mi limiterò quindi a suggerire alcune recensioni trovate in giro per la rete: la prima viene dal sito della BBC, le altre sono quelle presenti sulla pagina di Amazon del CD. Aggiungo anche una intervista pubblicata subito dopo l’uscita di quest’album ed un articolo/resoconto di un loro concerto a Roma nel 2005.

Personalmente, posso dire che l’album mi è piaciuto molto, e penso proprio che andrò al loro concerto a Cala Gonone a fine mese.