Sweet Stout Journal - Wrap Up @7brewing

In this post, I'll wrap up the brew day with notes, recipe and final results.

After a somewhat turbulent brew day yesterday, I have a beer that is bubbling away this morning.

I encountered a few snags along the way.  First was the stuck or pinched filter in my mash tun.  Once I opened up the filter the wort was flowing quite nicely.  It may have been assisted by the high volume and temperature which increased the overall wort viscosity.  Once the filter was corrected, the wort start to flow freely.

While chilling, the exit hose from the copper chiller come loose from the fitting.  I then had to turn off the water and reattach the hose back to the fitting and then hook it all back up.  Once that was fixed, the temperature of the beer dropped pretty quickly.  It seems that the water temperatures from our city water are dropping with the shorter days and cooler temperatures.  I managed to cool the wort to about 68 degrees.  This was well within the range for pitching the yeast.

The recipe I brewed yesterday, originated from this Northern Brewer recipe.  The recipe was tailored to a brew house efficiency of 80%.

Mash Water (All City Water)

Total grain (lbs) : 8
Target Mash Water Volume: 2.5 gallons
Final Mash Water Volume: 3.75 gallons
Sparge Volume: 4 gallons
Mash Temperature: 152 degrees

Grain Ingredients
7 lbs Marris Otter (Pale Malt)
0.5 lb Carafa III
0.5 lb Chocolate Malt

Boil Additions
0.7 lb Milk Sugar (Lactose)
1 oz Willamette (hops)
Total Wort to Kettle: ~6.25 gallons
Total Wort to Fermenter: ~5+ gallons

Here are the original gravity (OG) and final gravity (FG) readings according to BeerSmith v1.4 and measurments.
OG estimated : 1.053
OG for style: 1.044 - 1.060
OG actual: 1.056
Actual brew house efficiency: 85%

FG estimated: 1.014
FG for style: 1.012 - 1.024
FG actual : TBD

If the FG comes in at 1.014 as estimated, this beer should have about 5.48% alcohol.  Not a very big beer, but still comes in above a session beer.  I anticipate it will be a very tasty beer.  I hope to introduce the milk stout for the first time to several people and spark some intrigue in this beer and style.

Thank you for reading along.
- Matt

Please follow any of the references throughout this series of posts for definitions to the terms and information that went into this brew.

• pitching the yeast - http://www.homebrewtalk.com/wiki/index.php/Pitching_the_Yeast
• session beer - http://beeradvocate.com/articles/653
• wort - https://www.google.com/search?q=define+wort
• Sweet Stout Journal - Mash @7brewingco - http://mhorner.blogspot.com/2012/09/sweet-stout-journal-mash-7brewingco.html
• Sweet Stout Journal - Post Mash @7brewingco - http://mhorner.blogspot.com/2012/09/sweet-stout-journal-post-mash-7brewingco.html
• Brewing with Denny - http://hbd.org/cascade/dennybrew/
• BeerSmith.com - http://beersmith.com/
• BeerSmith.com Podcast # 39 - http://beersmith.com/blog/2012/05/31/advanced-home-brewing-with-gordon-strong-beersmith-podcast-39/
• Original Sweet Stout recipe from Northern Brewer - http://www.northernbrewer.com/documentation/allgrain/AG-SweetStout.pdf
• Wynkoop Brewing Company - http://www.wynkoop.com/

Sweet Stout Journal - Post Mash @7brewing

Next we'll move to the post mash step.  But first, a little nugget of information.

Earlier this week I listened to the BeerSmith.com podcast #39 with Gordon Strong.  Gordon discussed the water conditioning and addition of darker malts to the mash.  He pointed out the idea that darker malts do not require a mashing step as it does not require any enzymatic conversion and provides a charring or burnt flavor to the beer.  

Why do I mention this?  Well, as much as I would have liked to try this during this brew, I came to the realization that I need to understand first how to bring my water temps up for a mash out step.  I am using a cooler configuration like the one detailed by Denny here, BREWING WITH DENNY.  I suspect that I could use the sparge water to bring my total volumes up while increase the mash temps.  However, I didn't want to necessarily alter my brewing process this time without doing the necessary research.  I am detailing the idea here for future reference, more so than anything and potentially generate some conversation.

First before transferring the first runnings to the brew kettle, I have to heat 4 gallons of sparge water to complete the rinsing process of the mash.  

4 gallons of sparge water heating.

It's time to start transferring to the boil kettle after 60 minutes of mashing.  The color should be fairly dark.  

The drain and filter I have is beginning to slow down during run off.  It seems to be pinched or clogged with and requires a little finagling to move the wort from the mash tun.

I ended up pulling the filter out and jamming the end of a wooden spoon down the filter to re-expand it. This simple fix actual increased the flow considerably from a slow trickle to only being held up by the diameter of the valve and drain tube.

Before

After

Now the wort is on to boil.  I have added 1 ounce of Willamette and 0.70 pounds of lactose.  Another topic on the podcasts from BeerSmith.com discussed timing of hop addition.  The discussion lead to adding the hops pre-boil to give the beer a much smoother less harsh bittering taste.  I decided to give this a try and see what the results of that modification would be to my beer.

I'll complete the boil process, chill it, transfer to the fermentation and finally pitch the yeast.  My next post will detail the recipe, today's results and wrap up of the whole brew.  Thanks for reading along.

Sweet Stout Journal - Mash @7brewing

Today, I am brewing up a Sweet Stout or Milk Stout.  A Sweet Stout is a dark beer with a bit sweetness that is added by lactose or milk sugar. The lactose provides an amount of unfermentable sugar or sugar that is not metabolized by the yeast.  This sugar is left over at the end of the fermentation process and contributes to a unique sweetness in the beer.

The first milk stout I tasted was produced by Wynkoop Brewing Company during a business trip out to Denver in 2010 or 2011.  I was intrigued by the sweetness and immediately thought "I need to brew this".  I like varieties of hoppy and malty beers, but the sweetness of the milk stout is quite different and done right can have a very smooth flavor.

First tip of day:  Pay attention to the water temperatures.  For 3 out of the last 5 brews, I have started with overheating the mash water.  This not only requires returning the water to the target temperature but adds an unnecessary amount of time to the brewing process.

Working with small volumes of mash water makes it challenging to maintain temperature for mashing in.  Starting with 2.5 gallons of water heated to 164 degrees, I mashed in 8 pounds of grain.  After mashing in I took a temperature reading of the mash and found the mash was at 146 degrees.  A full 6 degrees below the target mash temperature of 152 degrees.

(Excuse the photo quality from my iPhone 3GS.  My iPhone 5 is on order.)

I made a first attempt to bring the temperature up by adding .5 gallons of water heated to about 190 degrees.  This raised the mash temperature to about 148 degrees.  Typically, I have not checked the mash temps before setting up for the 60 minute mash.  This could alter the flavors of the beers I generally brew and points to the idea that better control over the mashing process.

I added another .75 gallons of water heated over 180 degrees and got within my target.

Mash Water
Total grain (lbs) : 8
Target Mash Water Volume: 2.5 gallons
Final Mash Water Volume: 3.75 gallons
Mash Temperature: 152 degrees

To meet volumes to the boil kettle, the sparge water will be adjusted by 1.25 gallons.

Sencha Touch And Restful Models (My Solution)

For those that have been sitting on the edges of their seats waiting for this post, here it is. Finally!

To start off, let's here is a list of my goals.

• Establish an automated method for retrieving a child model from a RESTful service.
• Reduce the application code to manage multiple result sets of slight variation.
• Reduce the code complexity for working with RESTful services and Sencha Touch.
• Simplify the development experience with Sencha Touch and model associations.

The pattern that I immediately see with any RESTful service is an initial subset of data that contains a URI.  To understand the full data set for the same RESTful service, a client would navigate the URI to retrieve the rest of the service details.  We end up with something like this.

{ id: 0, uri: 'makers/0' }

Once the uri of the makers Model is expanded, you should see something like this which contains a model of Chevrolet that I have owned.

{ id: 0, name: 'Chevrolet', models: [ { id: 0, maker_id: 0, name: 'S10', year: '2003', uri: 'cars/0/0' }, ... ] }

Inside the models array, there are potentially multiple records that will next need to be expanded. The complicating factor is the need to navigate and further expand the data sets that you see once the user requires more information. In the above example data set, I have chosen these fields to show on the initial view. I have identified these fields to display to the user to present them with enough information to make their next choice.

View my screencast to see this in action.

You can download the code to my solution from my github project, RestModel.  The implementation with some examples and unit tests are all included.  Please leave a comment if you have any questions or need assistance with setting this up and running with it.

Sencha Touch And Restful Models (The Problem)

This is the first of a couple posts that will discuss Sencha's Touch framework and the concept of using Rest.  The final post will present a solution and examples of this implementation while showing what I have created and learned along the way of solving this problem.

One of the features I have been thinking about with regards to Sencha Touch is having the ability to retrieve additional information while leveraging the very useful and powerful Model implementation. In the context of the Model implementation while using Restful services, the data should in the most strict form contain a URI.  This URI should be a reference to additional information.

In my instance, I am using a phone form factor to frame this problem.  In the context of a phone-based web application, the application should contain just enough information to render the screen useful.  Any additional information that needs to be given to the user should be done on-demand.  For example, a list of car makers shouldn't include a list of all of the cars ever made by the maker.  When the user selects the maker, then a list of cars should be provided to the user.  That should be done following a new request for information.

The on-demand retrieval of information is a convenient and arguably a core feature of restful services.  In the phone form factor, the ability to see the separation of the data requirements for the screen and utilization of the on-demand concept is very easy to see.  Taking the request model to a full-sized browser becomes a bit more tricky depending on the design of the screen and how the data is presented to the user.  For simplicity, we'll stick with the phone to simplify the concept and see some examples.

Hopefully the following pictures will illustrate this a little more obviously if I haven't portrayed the intent.

In it's most basic representation, there is a parent model with a child model.  The child model has enough details to create the proper linking between the parent and child.  Furthermore, it contains an URI property that will assist in retrieving additional information regarding the child object.

After some triggered action, likely a user driven action, the URI is expanded and additional information is "automagically" expanded into the model.  Now any interactions with this model will have the properties, prop1, prop2, and prop3 available for the selected child record.











In the next post, we'll see the implementation that I came up with, view some examples and discuss the project a little more in-depth.

For my solution, see my post Sencha Touch and Restful Models (My Solution).

Sencha Touch Debugging

I will start by prefacing this post with it is often very frustrating to try to debug Sencha based frameworks.  My particular gripe in this case is with Sencha Touch 2.0.  I am working on a little project to get more familiar with Sencha Touch.  The project is hosted on github if you want to look on and see what I am doing.  (Maybe you can shed some light on my stupidity.)

NOTE: This is not a post on how to debug Sencha Touch.  My intention is to document what I am seeing and hopefully find someone with similar issues or with a solution.  Check back later for the resolution, as I am sure it will be something ultimately simple.

My issue at the moment is the Observable mixin.  I have a controller, MlbSchedule, that is watching an event fired by the TeamList.  The event, itemtap, is caught by the MlbSchedule controller.  Then the method drillInOnTeam is then called.  So far so good.

Ext.define("MlbSchedule", { extend: 'Ext.app.Controller', mixins: ['Ext.mixin.Observable'], ... initializeListeners: function() { var tList = this.getTeamList(); tList.on("itemtap", this.drillInOnTeam); }

drillInOnTeam fires an event teamSelected, which does nothing more than pass the record along.  The intent here is to send the record out to the listener to transfer control to the next controller that is set to handle the selection of the item in the list.

drillInOnTeam: function(dataView, index, target, record, event, options) { console.log(this.fireEvent("teamSelected", record)); }

The application, app.js, initializes the listener attached to the MlbSchedule controller as follows.  There are no errors at this point and everything appears to be in good working order.

initializeListeners: function() { var mlb = this.getController("MlbSchedule"); mlb.on("teamSelected", this.showTeamNews, this); }

Now, when clicking the row list item, everything fires except he method showTeamNews is never executed.  I am not at a loss.

How do you debug this?  I can step through the various steps of the fireEvent method.  Is there a better approach?

[SOLVED]
It turns out that the event teamSelected was being fired off of the TeamList instance instead of the MlbSchedule instance.  (face palm)

initializeListeners: function() { var tList = this.getTeamList(); tList.on("itemtap", this.drillInOnTeam, this); }

Something so inane.  I don't know how Sencha can correct this sort of developer stupidity.

However, the garbage man showed up as I was writing this post.  I had not put the trash out yet and chased him down and even assisted in loading all the garbage from my current home project into the truck.  This is a good reminder that sometimes the simplest solution is to walk away.

Sencha Touch vs jQuery Mobile: High Level Review

With the advent of the iPhone and later Android based phones, the need to build applications that conform to the profile of these devices has become a very popular and important job.  With the addition of the tablet based devices based on the operating systems in these leading platforms, this need has grown further.  The time and energy required to deliver a mobile application is multiplies for each device platform.  Mobile web applications can address this problem to some extent.

This research topic will be looking at Sencha Touch (ST) and jQuery Mobile (jQM).  The goal is to understand how the two stack up.  In the end hopefully it will be clear which is a more powerful framework based on tangibles and some intangibles.

Admittedly, I have a bias in having experience with Sencha frameworks, specifically ExtJS 3 and 4.  Their Touch framework is new to me.  I have only dabbled in jQuery in the past and the extent by which I used it was rather limited.  However, in terms of some of the enterprise level features, ExtJS has been a more powerful framework.

Sencha Touch Website - v2.0 Beta 1

jQuery Mobile Website - v1.0.1

Device support is important to some.  For my purposes, I am mostly concerned with targeting the iPhone and Android-based phones.  This will simplify the rest of the research, however it's important to note the device support today by each framework.

• jQM, lists support for iOS, Andriod, BlackBerry, bada, Windows Phone, palm webOS, symbian, MeeGo.  See the full report on Browser Support.
• ST v1.1.1 supports, iOS, Android and BlackBerry.  While v2.0 is in beta, the support for Android versions 3.x is labelled as "fundamentally broken, and do not plan to officially support it in Touch 2." [Raising The Bar].  Issues with transitions in the ICS browser have been raised with Android development and appear to have been resolved.

ST v2.0 Beta 1 Kitchen Sink

jQM v1.0.1 Pages & dialogs screen

These screenshots give a general feel for the default look and feel of the both frameworks.  ST tries to mimic the look of the iOS styling whereas jQM uses a theme similar, but varies drastically from the iOS look.  These themes apply the same on an Android based device (tested in an Android Emulator).

jQM is based off of the popular framework jQuery.  This is prevalent in the script loads as well.  Among the javascript files loaded, are jquery-1.6.4.min.js and jquery-mobile-1.0.1.min.js.  This results in a payload of 32111 and 24840 bytes respectively gzipped or 56.9 KB.  

ST on the other hand loads one file with ExtJS framework requirements in addition to the Touch framework.  The total payload 28658 bytes, or 28.6 KB.  A 28.3 KB larger smaller download.  This is a minimal factor as long as caches are utilized properly and occurs on a occasional basis per user.  In slow network situations this could leave a user less frustrated.

Both frameworks pay some lip service to PhoneGap.  A solution that may be a very valuable and easy way to deploy an application to a large customer base while having complete control over the user experience for deploying updates.  A huge drawback to native applications is the platform dependent implementation.  While these javascript-based frameworks are still very new and maturing they do provide relatively good experiences compared to the native based application.  For more information on PhoneGap, please review the documentation provided by the two frameworks or visit http://www.phonegap.com.

Anyone who has done a any amount of studying iOS application development will now that it follows the MVC pattern very religiously.  I won't discuss the details of MVC here but you can read up more on the pattern on Wikipedia.  One of the feature additions in ExtJS 4 was full scale MVC support.  The model was formalized and additional classes were built to support the concept of view and controller.  After doing some work with iOS, I found that I actually appreciated that concept very much.

With that, I would personally look to building new web-based applications following that pattern.  ST is based on ExtJS 4 and brings the MVC pattern to the table.  A cursory search on the google machine, I could not find a concise document on using jQ or jQM to implement MVC based applications.  I think this is knock on the framework and may for some be a deal breaker.

I was also more impressed with the transitions by ST.  I have an iPhone 3GS running iOS 5.0.1.  Anyone running this combination will feel the pain I do on occasion with regards to performance (small price to pay for some of the adds).  The transitions were seamless and very smooth.  With jQM, I found that transitions were not as good.  Here is a set of screenshots of what I am referring to.

The first screen shot appeared after clicking the "Page & dialog" option on the front demo page of jQM.  A page load occurred, the first screen shot appeared and then after enough time to capture the image the second screen shot appeared.  Now, I am not sure if this an intended feature.  What I will say, from a expectation level as User evaluating this demo, I did not expect this transition.  I suspect that the demo application is formed in a way to easily adapt into a tablet/large form factor and adjusts down to the resolution of my iPhone.  That is my uneducated guess.

With these very basic criteria, ST seems to be a better fit for greenfield web application development.  Developer experience with jQuery or ExtJS may be another deciding factor.  As stated earlier, I have more experience with ExtJS.  I feel that it would be a smaller learning curve to learn the ST framework, understand the documentation styles, and implement the application and features necessary to build an application.

REST - Taking a Closer Look (Citations)

There was an abrupt end to my posts regarding REST.  This in part due to a goal change and feeling like I didn't have to much more to really dive into at this time.  I wanted to make sure I give credit where due and provide the resources I used very heavily in reference to my earlier blog posts.

Each of the following links were used in some way throughout my research.  Please visit these links for further reading.

Grails Screencast : http://grails.org/screencast/show/31
REST Wikipedia article : http://en.wikipedia.org/wiki/REST
HTTP v1.1 Specification : http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
POST Tunneling : http://stackoverflow.com/questions/1101888/is-there-any-reason-not-to-use-http-put-and-delete-in-a-web-application

REST - Taking a Closer Look (Part 7)

We are going to take a little detour and look at the method values available.  These values have very defined intentions for use and how they should be treated on the response side of the transaction.  The w3.org has documented eight different methods in the HTTP v1.1 specification.

• OPTIONS
• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE
• CONNECT

It seems that all communication is now expected to work through the GET and POST methods.  The GET is intended for retrieving data with potential for cache.  The POST is intended to push data onto the server.  These two methods are very common and do not require a lot of discussion.

OPTIONS Method

The OPTIONS method intends to determine what options are available to the client.  This may be useful in the cases of determining a user has access to specific resources on the server.  The w3.org HTTP v1.1 specification has this to say about OPTIONS.

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

Responses to this method are not cacheable.

In the Book example I have been working through, I could it being used to determine if a user has read-only access or may have create, update and delete privileges as well.  The client application could be formed in a way to respect the response of an OPTIONS request to provide certain features to the user based on their authorizations.

HEAD Method

HEAD, is header that I have only read about and never use in practice.  The definition as defined by w3.org from the HTTP v1.1 specification is,

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

Two things come to mind.  Checking the end point is valid and exists, pushing data to the server without sending a response to the client.  Now these two are likely very useful in certain conditions.

My extinct is to avoid HEAD whenever the User's experience is at stake.  Another words, if there is a need to make a request to the server to gather information.  It does not seem practical or feasible to make a HEAD request first to determine if the end point is valid and contains fresher data than the browser's cache.  The result would be in certain situations an additional request to retrieve the data.

I can see this being used in a CDN type implementation, where the delivery nodes are responsible for checking for updates periodically.  In this instance that User is waiting for the response and additional requests.  The node can make requests more often to check staleness using HEAD and then make a GET request to retrieve an update when necessary.

Another useful condition may be to push user activity information to the server.  In this case, the response codes should indicate whether the user is still allowed to access the system.  Otherwise, if the system is dependent on the client pushing data or communicating on a regular basis to avoid a session disruption from the server side.

PUT and DELETE Methods

The PUT and DELETE methods are primarily used in RESTful services.  They are used to indicate the action of updating or deleting some data.  I have already worked through the PUT and DELETE methods in a previous post.  Check it out for what I have discovered there

TRACE Method

TRACE is a method intended for testing and debugging purposes.  The method indicates that the server should do nothing more than reflect the request data back to the client.  HTTP v1.1 identifies this as,

The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.

This is useful to identify how a request may be processed on the way through all of the various hops between the client application and the server.  If there are no hops between the client and server there is likely going to very little change of the request on the way through to the server.  I have never used this in practice, but I am intrigued to learn more about it and how I may be able to utilize it.

CONNECT Method

This method appears to be reserved but not implemented.  So there is not much to say about it, except it may be used with SSL tunneling.  See the w3.org's HTTP v1.1 specification for more details and updates to the specification.

Java SE for Embedded and Plug Computers

Wednesday night I attended the WJUG meeting on Java SE for Embedded devices.  The presentation was given by Jim Connors of Oracle and previously Sun prior to the buyout.  Jim showed the power of Java SE for embedded devices how there is very little to change in the development process.

During his presentation he showed a hockey scoreboard implementation that he built.  The scoreboard was using a JavaFX front end on his Windows laptop.  He showed that with a similar implementation using jcurses he could show the scoreboard through putty.  The data regarding penalties, time, and period were all managed by the application running from a full-sized laptop.

He showed there was an important distinction between the Java SE platform and Java SE for Embedded.  First off, the size of the embedded jre was reduced by nearly half.  This was to accomodate the size constraints of the flash drive with the device.  Secondly, there are specific builds for each embedded based device.  The download site for Java SE Embedded has several to choose from and may have the binaries for most devices available on the market.

The embedded space will likely grow into a larger market.  It seems reasonable that Developers and IT shops alike should start to take notice.  The advantages of this platform are low cost and low power consumption.  Both making it an easy adoption for any hosting environment.  Jim had two Global Scale devices on hand.  They have two devices that are priced at $99.

In wrapping up the presentation, he showed a web farm with six nodes.  The first node was the load balancer running Apache Tomcat with mod_proxy.  The last five nodes were responsible for handling the traffic.  The advantage of this implementation is the cost.  These machines may not be that powerful today, but there is growing demand for smaller more powerful and ecological embedded type devices.  Did I mention that these devices only run on 5W of power.  Slap an external hard drive on this machine and suddenly you have a lower powered server that can handle a reasonable amount of traffic.

Check out Jim's blog of tomcat micro cluster to see it in action.  It's very cool and as Jim put it, inspired by the old days of google and their first rack mount systems.

REST - Taking a Closer Look (Part 6)

In my last post, I talked a bit more about the PUT and DELETE methods of a request.  I raised a concern regarding the Grails and it's support for PUT and DELETE due to my inabilities to make a PUT request from a form.  After further investigation, I found a reference in the HTML5 changelogs posted on June 24, 2010 indicating that PUT and DELETE methods were removed from the specification.

As expected, the following code works without any issues.

jQuery.ajax({ url: "http://localhost:8080/research-grails-rest/book/delete/2", type: "DELETE" });

This further proves the point that only the form submission using these methods are affected.  This restriction may not be an issue for applications that are primarily Ajax driven.  However, I have read in several API docs now something similar to this from the jQuery Ajax documentation.

"The type of request to make ("POST" or "GET"), default is "GET". Note: Other HTTP request methods, such as PUT and DELETE, can also be used here, but they are not supported by all browsers."

The trend in several stackoverflow articles is a POST tunneling concept.  Essentially, instead of using the PUT or DELETE methods, send everything over POST.  Then specify through a hidden form input or HTTP header the correct method.  This resolves the problem for form submissions and lack of browser support.

With that resolved, it is time to look closer at more complex structures.  My next post will be centered around understanding how the state of a collection of books is transferred.  After that investigating how to perform operations against that collection.

Citations from stackoverflow.com regarding POST tunneling:

• Are the PUT, DELETE, HEAD, etc methods available in most web browsers?
• Is there any reason not to use HTTP PUT and DELETE in a web application?

REST - Taking a Closer Look (Part 5)

In this post, we'll take a closer look at the update process using PUT with the Grails project.   REST defines updates as a HTTP PUT method.

First we need to make a few adjustments to the code to make the update operation respond to the PUT method and alter the edit form to ensure it is sending in a method of PUT.

Alter the allowedMethods array to recognize PUT for the update method.

Alter the form method to ensure it sends PUT as the method.

Now that we have ensured the method is set to PUT on the form and the controller will accept PUT as the method from the client let's test.  (After selecting a specific book, click the Edit button along the bottom of the view.)  Altering some data and clicking the Update button we should be in business to see the transaction.  The following screenshot details the HTTP headers transferred during the state transition.

Here we can see that the request was actually done using POST.  Internally within the request parameters a PUT method is specified.  This is detailed further in the Grails 2.0.0 documentation.

Issuing a request with a method other than GET or POST from a regular browser is not possible without some help from Grails.

This doesn't seem to be consistent with the REST architecture or the HTTP v1.1 specification.  Grails is also blocking a method of PUT coming from the browser with a 405 - Method Not Allowed response.  Requests made with cUrl go through without error.

$ curl --request PUT http://localhost:8080/research-grails-rest/book/update/1 --verbose
* About to connect() to localhost port 8080 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
> PUT /research-grails-rest/book/update/1 HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: localhost:8080
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
< Server: Apache-Coyote/1.1
< Set-Cookie: JSESSIONID=F91DEA3433A1F745B249C0F7E3E9988E; Path=/research-grails-rest/; HttpOnly
< Location: http://localhost:8080/research-grails-rest/book/show/1
< Content-Length: 0
< Date: Tue, 24 Jan 2012 10:45:05 GMT
<
* Connection #0 to host localhost left intact
* Closing connection #0

The response location,  http://localhost:8080/research-grails-rest/book/show/1, indicates the controller received the request correctly and performed the update.

What am I trying to get at?  One concern I have is support by most/all browsers for the HTTP v1.1 specification.  Another concern is around the heavy handiness around the method support on Grails part.  I concede I am now Grails expert and there may be a very simple solution to this.  I haven't found it yet if there is.  Furthermore, quick check of delete operation from the browser blocks the DELTE method even after altering the allowedMethods.

So what have we learned?  The PUT and DELETE methods have special considerations when involving the Grails built views.  It may be worth approaching another framework to interact with the REST services provided.  However, the controller has tightly integrated the responses on each call with the next view.  I think this is intended due to the nature of Grails application development.

REST - Taking a Closer Look (Part 4)

In the previous posts, we've discussed the general project, defined the concept of REST and taken a look at the list, show and save operations.  Now, let's talk a little shop and dissect the concept of REST a bit further.

REST has some very important design concepts that need to be leveraged to be successful.  First, a rich and easy interface.  This is important for two reasons.  Building a client implementation around a set of REST services can focus on user experience and ignore the data needs.  That is to say, the data is well-defined and the developer building the client can rely on those services to provide specific data.  The application will be built around that data without intermixing the client specific code.

The second important reason is, a developer can build any client around a set of REST services.  Why?  The data has no complicating details blurring the line between the user experience and the data.  In doing so, it makes it more adaptable to move from a purely web-based client to say a mobile web client.  Later, moving to a native client or game console becomes a reality.  Later on down the road, the REST API is published and developers are developing custom applications, much like Twitter, Amazon and others.

Another idea I have read about but do not fully understand is the concept of idempotent resources.  Idempotent is defined as an element multiplied by itself remains unchanged.  The simplest case I can come up with is 1.  1 multiplied by 1 is still 1.

So how does this apply to resource in your system?  Making a request to the same URI should result in the same operation time and time again.  In other words, creating an entry for a book with the same title should result in the same book being created or denied every time.  Only one book is created with that title.  Both PUT and DELETE methods are idempotent.  The GET method is also idempotent given that there are no lasting changes on the resource being requested.  POST is an update operation and can result in attributes of a given resource being altered.  It does not qualify as an idempotent method.

Now, we have defined why REST has good qualities. It provides a rich and easy interface to resources or decouples the client from the data, in doing so, making the data and services scalable.  We have cleared up the concept of idempotent and what that means to a resource in our system.

It is important to remember that REST isn't a specification like SOAP.  It is merely a suggestion of an architectural design around how to serve data.  There are goals within the design to decouple data from the client so that these services are scalable, reliable and well-defined for future client implementations.

REST - Taking a Closer Look (Part 3)

In the previous posts, we've discussed the general project, defined the concept of REST and taken a look at how the list or read operation.  Now as promised in REST - Taking a Closer Look (Part 2) we'll look at the POST method or create operation.

After clicking the 'Create Book' button, a form for the attributes about the book is displayed.  After entering the required values, we can click the 'Create' button.

Create Book Form

After clicking the 'Create' button the new book properties will be sent to the server and stored in the database.  The following screenshot details the request/response transaction from the browser with the client.  

Save Book Transition

The important pieces to note are:

• Request URI is http://localhost:8080/research-grails-rest/book/save.
• Request method is POST.
• Response status code is 302.
• Response location is http://localhost:8080/research-grails-rest/book/show/1.

The rest of the request and response headers are standard protocol speak.  The ones identified above indicate exactly how the data was saved and how the following response to the show state.

We have now seen three URIs in the transition between book listing, saving and showing a book.  The list operation is done with the GET method and the URI was formed as, http://localhost:8080/research-grails-rest/book/list.  The save operation is done using the POST method and the URI was, http://localhost:8080/research-grails/rest/book/save.  Lastly, the show operation also used a GET method, however specified an id to identify one of the items in the collection like so, http://localhost:8080/research-grails-rest/show/1.  

What we have seen so far is the basic blocks to working with a single resource.  Later we'll dig in further to understand the request model for updating, deleting and multiple items in the collection.  Next we'll take a closer look at REST and put a little more definition around what it is.

REST - Taking a Closer Look (Part 2)

First goal is understanding the request model as stated in my previous post REST - Taking a Closer Look (Part 1).  For this portion of the exercise, I will start take a closer look at the Book implementation.

The book model is simple concept and one that we would recognize from our daily lives.  A book has basic properties,

• title
• description
• author
• ISBN

What is REST?  REST is representational state transfer (see Wikipedia for more details).  More or less, it's a software architecture by which we transfer state from one place to another.  In terms of the web, transferring state of resources from the client (browser) to the server (web server->database).  I strongly suggest reading the Wikipedia entry, as it has some very useful and important details on implementation and separation of concerns.

REST sets out to model the concept of CRUD operations (Create, Read, Update, Delete).  It mimics these operations by using POST to Create, GET to Read, PUT to Update, DELETE to, well, Delete. 

With a simple understanding of REST, let's look a little closer at a Book implementation.  Initially, you'll want to see a list of books that are available.  We would model a URL using the guidance of REST like this.

GET http://localhost:8080/research-grails-rest/book/list

This URL has no unique pieces to it.  The resource is defined by book and the operation is defined by list. As a result, all defined knowledge of the representation of a book will be listed.  We can say this about any resource that is available in the system that provides an authorized list operation.  Within the context of the Grails application, all of the work is done on the server and returned in an HTML page.  However, in an Ajax based client, the list operation would return all of the data as a data structure and decouple the operation from the client view.

Screenshot: Result of book/list.

As a part of the architecture, the GET request could be marked as cacheable.  In other words, the browser could use a copy of this data from it's local cache rather than making a request to the server.  The resource, book, would have to mark the list operation as cacheable and provide a timeframe in which that cached data is considered fresh.  Once that cache entry is considered stale by the browser or by revalidation by the server, a new version of the resource will be made available to the end user.

For a simple operation like, GET, this about the extent of it.  In the next post, I will discuss the POST method (Create).

REST - Taking a Closer Look (Part 1)

One of the challenges that I have found in regards to REST is really understanding how it used in practice.  Looking across the internet, there appears to be a vast amount of documentation that talks about the basics.  I have two goals for gathering a better understanding of REST.  First, understand the request model which is well documented all over the internet.  The best way learn something is by doing.  Secondly, look at how more complex operations are constructed and how they impact the design of application.

To frame this out, I am working with Grails and building on top of the implementation discussed in the screencast, Jump Into Grails 2.0.  My experience with Groovy is limited, but I have a good background in Java which I am hoping to leverage in learning/understanding Groovy.  The screencast takes an approach of building a basic application in Grails encompassing the following,

• Setting up application configuration and plugins
• Building basic model, view and controller implementations of 
• User
• Role
• User Role mapping
• Discuss Unit testing - in my opinion very handy and largely automated
• Building a new model, view and controller of a Book.

I don't intend to reproduce the screencast here.  However, as part of this first part I would like to make sure there is enough understanding about the Grails project and how it is built for those looking to understand and answer the same questions I am setting out to answer.

For complete source, access the git repository through git : git://github.com/mhorner/research-grails-rest.git or view it at https://github.com/mhorner/research-grails-rest.