arc90 blog

Flying Virgin America

jesse@arc90.com (Jess Eddy) — Wed, 23 Jul 2008 14:35:00 -0500

I recently flew to L.A. We all know ticket prices are at an all time high and the standards for service in general are very low, so with this in mind, I was extremely delighted to find a reasonably priced ticket on Virgin America Airlines, which is considered a “premiere airline.” I'd never flown Virgin before so I was very excited.

Online Experience

My first discovery was the great interactive experience on their Website. This informative site outlines all the cool perks that Virgin provides--like mood lighting and plug-in ports for all your little gadgets including a laptop. I’d been scrambling to find a way to charge my computer on the plane and had even considered buying an extra battery until I found this out. Problem solved.

Check-In

Checking myself in was a breeze--a true sign of a good user experience. Unlike the large kiosks you usually find for self check-in, Virgin has a table with four sleek touch screen monitors. The interface for this process is great—it’s nice to look, easy to use, and very quick. Checking in is a five-step process and there's a nice little indicator of this on the screen so you know where you are in the process at all times. As my ticket is being processed, the interface communicates the current time and indicates that I have 40 minutes left until boarding. Thank you interface! My boarding pass then prints and is spit out through a tiny slit that is integrated into the table itself, which is very cool. Additionally, it’s the smallest pass I've ever seen and yet it still contains all the necessary information. No folding required—it’s no larger than my wallet, so I just slip it into my back pocket.

The Plane

Now the fun really begins. As I walk into the plane, I can see the mood lighting and it's a little like walking into a nightclub. There's jazzy-techno music playing, which in a restaurant wouldn’t be cool, but in this case, on this plane, it is very much cool. The seats look like expensive, converted executive office chairs from the front and iMacs from the back. They are very comfortable!

In Flight Experience

I find my seat and sit down. In front of me is my very own touch screen monitor, which is actually a media center, called "Red." Red is Virgin's interactive environment and it's in Beta. Like the self check-in interface, Red's interface is also a great experience and has a ton of options. I can watch TV, multi-lingual TV, music videos, premium television (episodes of 30 Rock, Dexter, etc.) and movies (which you have to pay for), and even a section just for kids. Between boarding and taking off, I made an entire playlist and didn't take out my iPod even once during the flight. You can also play games and chat with other people on the plane through an instant messaging system! The remotes accommodate for this perfectly with their three main facets: one side for traditional controls like volume adjustments and channel changing, and the other for gaming and texting, along with an integrated credit card reader which I used to pay (Virgin is a cashless airline) for my yogurt parfait. Meals are not served on the plane, but you can order food, snacks and beverages from your seat using Red, along with all the free items like coffee, juice and soda, etc. Ordering anything with Red is like building an order on Amazon: you shop, compile, checkout, and pay (or not pay, if ordering free items).

Google Maps is also integrated into Red so you can always see your location (Missouri), as well as air speed (514 mph), distance to go until you reach your location (1,415 miles), altitude (36,163), and outside temperature (-51 degrees Fahrenheit). Communication on the plane is great and the in-flight introduction is done through the interface by a very entertaining, illustrated video. There were no awkward live demonstrations of how to apply an oxygen mask and I actually paid attention.

Virgin is definitely doing something right and it's hard to believe other airlines haven't caught on yet. The utilization and emphasis Virgin puts on design and technology is awesome. Granted, the novelty might wear off if you're a frequent customer, but it sure makes downgrading to another airline an ugly thought!

Charles, SSL, and you

chrisl@arc90.com (Chris LoSacco) — Tue, 22 Jul 2008 12:37:17 -0500

Is Charles messing with your SSL traffic? You can fix it by telling Firefox (or, shudder, IE) that the Charles SSL proxy is a valid certificate provider. Here are the instructions:

http://www.charlesproxy.com/wiki/ssl_certificates

We're Looking For The Lone Wolf McQuade Of PHP Development

rich@arc90.com (Richard Ziade) — Fri, 18 Jul 2008 10:51:59 -0500

Yeh, this is partly an excuse to throw down this kick-ass image but so what: we're looking for someone who can slay large swaths of software requirements with the sawed-off shotgun that is PHP/MySQL.

Ok, I'm gonna stop the analogy here. Seriously, if you're well-versed in PHP, MySQL, frameworks (like Zend) and possess front-end/Ajax/JQuery/JSON/XML skills, don't hesitate to hit us up with your resume/portfolio/friendly cover letter.

Arc90 is a product and consulting firm based in New York City and we're looking for someone to help us build great software experiences. It's a loose, creative and intellectually challenging environment. If you think you've got the goods ("goods" being coding skills and copious amounts of chest hair), don't hesitate to contact us.

Use grep? Try ack!

chrisd@arc90.com (Chris Dary) — Thu, 17 Jul 2008 12:23:39 -0500

For you command line addicts like myself.

I find myself using grep constantly to search within files. Most often in the format 'grep -r "phrase" * | grep -v .svn' To search subdirectories, and then filter out any subversion files. Which sucks.

I recently stumbled upon 'ack', which is a similar search function, but with a whole lot more features, and way faster by default.

With it, I only need to type 'ack "phrase" *' to get the same result. Neat!

Some reasons to use ack:

Ignores subversion directories by default.
Color highlighting of matches.
Full perl regular expression search capable
type specific filtering with --php, --perl, etc
Regular expression based file matching

It's neat. Check it out: http://petdance.com/ack/

Extending Column Background Color--without Images!

alexg@arc90.com (Alex Gutierrez) — Thu, 10 Jul 2008 13:30:00 -0500

Lets go straight to the HTML:

item 1
item 2
item 3

My title
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

and its corresponding style:

* { margin: 0; padding: 0; }
body { text-align: center; /*Hello IE*/ }
p { padding-bottom: 1em; line-height: 1.4; }
#canvas { width: 49em; margin: 0 auto; text-align: left; background-color: #F0F0F0; }
#right { float: right; width: 25%; }
#right ul { margin-left: 2em; }
#left { margin-right: 25%;background-color: #FFF; }

Explanation: Use the id "canvas" to assign the right column color. Then give id "left" a background color of white. Click here to view an example.

From Faceless to Family

jennifere@arc90.com (Jennifer Epting) — Thu, 03 Jul 2008 10:13:06 -0500

We released our first product--the lovely Kindling--to public Beta early last week. Preparing Kindling for public consumption (even the Beta phase) was a test of our imaginations. We were constantly evaluating who would use the application, what they would want answers to in the FAQ section, how they would react to a video explaining the app itself.

Once Kindling was ready to be released, my most immediate responsibility was to extend a few exclusive invitations and then take control of the tidal wave of invite requests that came pouring in. One by one, they crowded into my inbox, and on that first day, one by one, I responded back.

I'm not entirely sure what people think happens once they submit their name for a Beta invite. I suppose they assume their information is sent to an almighty database, which then electronically generates an invite code and sends them a confirmation email. Lest you believe otherwise, here at Arc90, all Kindling requests are processed by human hands--and lovingly cared for by yours truly.

And truth be told, I think of this huge document of names and group descriptions as a funny sort of family. For the past week, I have paid more attention to this group of people than I would a newborn baby, because--in effect--Kindling is a newborn. And for all the time and energy my colleagues and I have invested into its conception, it feels a little scary (and oh so exciting!) to watch a large group of users interact with it for the first time.

In releasing Kindling to public Beta, you--our customers--have become a real, tangible presence in our lives (mine especially). You're Dan with 25 members in your group of lawyers or Lisa who runs a Yoga studio. Even by only having your names and group descriptions, I now consider you part of the family and don't think I'm not wondering how you're getting along with your Kindling instance. I get a real kick out of imagining you in your office implementing new ideas, all because of this cool little app we released last week. Because to me, that's one of the most compelling reasons to work in this industry--the ability to put useful work into the world.

I suspect that this feeling will wear off as the number of requests grows higher (and certainly as my experience with releasing products increases) but for the moment, the fact remains that I'm thinking about our Beta users, cheering them on when their usage stats go up, and worrying about them when their stats take a dip. I have a secret dream of sitting down and having coffee with all those people who've requested an invitation. Or inviting them to Thanksgiving. You know, either way.

Fixing the Can't move '.svn/tmp/entries' to '.svn/entries' error

javierj@arc90.com (Javier Julio) — Wed, 02 Jul 2008 20:07:09 -0500

I'd been having trouble deploying the latest version of a Flex Module due to an SVN error I had never come across before. I was trying to update the svn:externals property with a new URL but once I saved my change I would get the following error in Terminal:

Can't move '.svn/tmp/entries' to '.svn/entries': Operation not permitted

I tried running an svn cleanup command but no luck. After digging through Google I came across an excellent post (it's in Spanish) with a command to run that prevents the above error. Basically on the directory I was trying to run the svn propedit svn:externals . command, all I had to was run the following command first: chflags -R nouchg ./

After that I could update the svn:externals property without any errors. The blog post suggests that the issue could be with how Windows changes certain file attributes with later on updating on Mac OSX. Makes sense for me since I develop on Mac while the developer who originally made changes to the working copy is on Windows.

Also I want to note that I've noticed others were getting the same error but instead of it saying "Operation not permitted" it would say "Permission denied" which I myself have not come across. I'm not sure if the same command will solve that problem.

Netflix Demonstrates Customer Relationship Mastery

avif@arc90.com (Avi Flax) — Mon, 30 Jun 2008 19:34:31 -0500

Everyone makes mistakes. It's what you learn from them, and how you deal with them, that matters.

Two weeks ago, Netflix decided to discontinue one of their features: Profiles. I was annoyed by this, but not enough to make any noise about it, or even tell Netflix. Truth is, I assumed that the decision was final, and that nothing I could say would matter. Well, Netflix proved me wrong, and has once again demonstrated their dedication to customer satisfaction, by reversing their decision in response to customer feedback.

I just found this message in my inbox:

The tone of the message is perfect, just perfect. I'm very impressed, and I sincerely hope that we at Arc90 can do half as well in our customer interactions - particularly if we're ever as big as Netflix.

Enabling A Drop Shadow On A Flex Container

javierj@arc90.com (Javier Julio) — Thu, 26 Jun 2008 10:30:00 -0500

To set a drop shadow on say a VBox or HBox component you simply set the boolean property dropShadowEnabled to "true" -- but this is not enough to make the drop shadow appear. An example:

To have the drop shadow appear (with its default shadow color) you need to specify a value for borderStyle since the default is none. Setting the borderStyle property doesn't necessarily mean you have to display a border, but it is needed for the drop shadow to appear. So if the border is not desired, simply set the style property borderThickness to 0. An example:

The above sample will display a drop shadow for the HBox component without a visible border.

In praise of System.Object

joelp@arc90.com (Joel Potischman) — Wed, 25 Jun 2008 12:15:00 -0500

In this Quick Tip, I show you how to make a method that deals with System.Object parameters more type-safe by converting it to use generics. Last year I had written a wrapper class to talk to the ASP.NET caching system for me. It returned cached objects as System.Object for maximum flexibility. The client would cast to the desired type, but it always bugged me, because it wasn't very type-safe. Consider the following chunk of code:

It will compile just fine, but it will blow up when I run it, because silly me, WhenDidIDoThis contains a DateTime, not an integer. It's far safer to rewrite my code to use generics:

Hmm. Actually, that same logic error still compiles just fine, but hey, at least my code now signals its intent more clearly. The bigger problem is now I'm getting a compiler error elsewhere. Let's see why.

Ah, that comparison with default(T) fails with the compiler error Operator '==' cannot be applied to operands of type 'T' and 'T' because T can be literally any type, including one that doesn't implement IComparable. Sure I could restrict my class to only accept IComparable types (public static T Get<T>(string key) where T : IComparable), but then my caching code is less universal. Or I could figure out a type-agnostic way of seeing if I got a cache hit without relying on IComparable. Yeah, that sounds like time well-spent.

So after a fair bit of work, my code is really no more type-safe than before, and I've either added complexity or limited its reusability, or more likely, both. And all because I wanted to replace my embarrassing System.Object parameters with sexier generic equivalents.

This class worked perfectly for every single use-case in every single project I've added it to over the past year (at least 10 so far). It doesn't matter that it ignores every single advance in the .NET languages and framework since 1.0. It doesn't matter that the other classes tease it for its positively Luddite reliance on System.Object. What does matter is realizing that a lot of the time in development, "good enough" isn't just good enough, it's actually pretty great. In hindsight, that's a much more valuable Quick Tip.

Introducing Kindling, the first product from Arc90

tim@arc90.com (Tim Meaney) — Tue, 24 Jun 2008 10:10:10 -0500

Ideas are everywhere, but how do I find them?

It’s been often said that the best ideas come from within an organization, as the people closest to the action are best positioned to see untapped value. However, in practice some businesses seek new ideas, whether they be process changes or the next product line, from the outside - from hired consultants or strategic management firms.

For those that do seek this out from within, often the problem is actually tapping into this potential wealth of ideas. If there was only a tool that allowed all members of an organization or community to submit, discuss, refine and vote on ideas? The net effect of all of this activity would be a well-vetted list of ideas, those that by the nature of being exposed and vetted have the support of the group.

Kindling, a new product by Arc90, is just such a tool. The product has been within our company for over a year, as well as by a handful of organizations during our private beta, and is available today, as we widen our scope to a public beta. More on that below, but first, since when is Arc90 a product company? As cryptic as our web presence might be, it is pretty clear that Arc is a services company, so how did we get here?

An evolution into product

A year or so ago, the management at Arc90 made a strategic decision to diversify our business by pursuing product development. As a services company we had been functioning as if we were building product, because we were building product - product used exclusively by our clients! Very rarely could our work be considered custom software. There’s both cause and effect in play here, as we tend to think in a way where we look at the problem at hand, abstract it one or two levels up, and then create software that speaks to the larger issue. We also only hire people that think that way, perpetuating the trend. This is how we keep ourselves interested in, and passionate about, our clients’ business.

Besides our inherent product disposition, we also seek control over our future. A simple truth exists about the services business: no matter how good the work is that you deliver to clients, you can never fully control your own destiny. A client, very pleased with our work, could fail, or get sued, or experience a change in management, or undergo a strategic change in direction.

Services companies attempt to get around this inherent challenge through diversification - ‘let’s get additional services clients!’ But that’s the rub for a company like Arc90 - we do our best work, and frankly usually only take on work, when we’re operating at a strategic level within an external organization. And those relationships are hard to find. We could take less desirable (as we define it) project work, but then not only would we not be controlling our destiny, but we’d be doing work that doesn’t suit us. And since this is our company, we’re just not going to choose to do that.

For those reasons, we made the decision which we are now executing on - diversify into product. Teams within Arc have been working on a few product efforts which are at various states of readiness. And so, as I mentioned above, I’m very pleased to announce that our first product is ready.

Kindling, an idea management and collaboration tool

Kindling is a web-delivered application which allows the members of an organization or community to create, discuss, refine, and vote on ideas. All of this activity naturally results in a listing of refined, quality, popular ideas. “Bad” or “unpopular” ideas will filter out of view, and “good” and “popular” ideas bubble up to the top. From there, decision-makers can approve or reject ideas and the cycle continues.

A key aspect of Kindling’s value is the scarcity of votes available to everyone using your group’s Kindling. Fewer votes means more value for each one, so people will use them to support the ideas they feel strongest about. That decision-making process, as played out over the group, will result in the best ideas gaining the most support.

Why would the people in my community or organization participate in Kindling? People participate in Kindling to see their ideas get acted upon, and to help support and refine other good ideas. Group or community decision-makers participate in Kindling for the same reason, as well as to identify and implement the group’s ideas. There’s a strong incentive here for decision-makers to participate in Kindling, as who besides members of the organization or community would have or recognize good ideas?

Kindling’s thoughtfully designed interface and experience make this process fun and engaging. I see this play out in Arc90’s Kindling, where there are usually a few new ideas and lots of new commentary around existing ideas every day. To illustrate, here’s an idea from our Kindling (note the date):

Kindling works for us, and we think it’ll be useful for others. If you find this interesting, head over to kindlingapp.com and request an invitation to join the public beta. The beta program is free with no obligation to subscribe once we launch the paid version (but you'll receive reduced pricing if you're in the beta program), and you’ll have the chance to provide feedback and participate in the refinement of the product as we prepare it for public availability.

Stay tuned to this blog for updates on Kindling, as well as our quest into product.

Building RESTful Web Apps with Groovy and Restlet, Part 2: Resources

avif@arc90.com (Avi Flax) — Fri, 13 Jun 2008 15:02:00 -0500

In Part 1 of this series, we set up a development environment for our apps, and created and tested a simple “Hello, world” example. In this installment, we'll make our app more realistic and useful.

If we revisit the current makeup of restfulapp.groovy, we see that there are two elements: the class RequestHandler, and the line which creates and starts an HTTP server. RequestHandler has only one method: handle(), which is called for every request. handle() checks whether the request method is GET, which is the only method supported by the app at this stage, and responds with “Hello, world!” if it is, and with an error response if it isn't.

It works, but there's definitely some key elements missing from the picture at this point – namely resources and representations. While our RequestHandler is indeed responding to requests and is therefore doing actual work, it's not particularly RESTful. There's no clear resource specified, and no representations of the state of that resource transferred back and forth. So that's what we'll add to the app now.

Let's update RequestHandler so it's no longer a generic “request handler” class, but instead models a resource. I'm not going to go into REST theory here to discuss what a resource is; if you could use a primer see your favorite REST tutorial or reference, or refer to the relevant section of The Dissertation.

So what resource should our class model? For the purposes of this article, we could choose almost anything. But we'll want something that'll allow us to demonstrate some important RESTful concepts, and to build something that resembles real-world resources in transactional software systems.

How about a mailbox? It's a good candidate because it has state of its own, which would be retrieved with GET, might support both PUT to update its own state, and POST to accept entities for processing, and maybe even DELETE. It also might have “child resources“: messages.

Let's try changing the name of RequestHandler to MailboxResource and see what it looks like:

class MailboxResource extends Restlet
{
    void handle(Request request, Response response)
    {
    	if (request.method == Method.GET)
		{
			response.setEntity("Hello, world!", MediaType.TEXT_PLAIN)
		}
		else
    	{
    		// The request method is not GET, so set an error response status
			response.setStatus(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED)
			response.setAllowedMethods([Method.GET] as Set)
    	}
    }
}

Next, let's change the handling of GET to return a meaningful representation of the current state of the mailbox:

	if (request.method == Method.GET)
	{
		response.setEntity("access: closed; messages: 0;", MediaType.TEXT_PLAIN)
	}

OK, it's primitive. But it's a plausible representation of the current state of the mailbox – and that's all we need at this point.

Next, let's add support for PUT, which a client might use to update the open/closed state of the Mailbox, and POST which a client might use to put a message into the Mailbox.

A first attempt to do so might look like this:

		switch (request.method)
		{
			case Method.GET:
				response.setEntity("access: closed; messages: 0;", MediaType.TEXT_PLAIN)
				break
			
			case Method.PUT:
				if (request.attributes.access)
				{
					this.access = request.attributes.access
				}
				else
				{
					response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "The request representation must include the parameter 'access'.")
				}
				break
			
			case Method.POST:
				if (request.attributes.messageContent)
				{
					createMessage(request.attributes.messageContent)
				}
				else
				{
					response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "The request representation must include the parameter 'messageContent'.")
				}
				break
							
			default:
				// The request method is not allowed; set an error status
				response.setStatus(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED)
				response.setAllowedMethods([Method.GET, Method.PUT, Method.POST] as Set)
		}

This code would work, as long as we implemented the field this.access set on line 10, and the method createMessage(), called from line 21. But as you can see, our once-svelte method is getting fairly unwieldy, and at this point we're still only doing very basic processing for our requests. You can imagine that once we need some more complex processing, our method could become impossible to work with.

OK, no problem, we all know what to do in situations like this: create class methods to handle each of our allowed HTTP methods. After which, MailboxResource might look something like this:

class MailboxResource extends Restlet
{
    void handle(Request request, Response response)
    {
		switch (request.method)
		{
			case Method.GET:
				handleGet(request, response)
				break
			
			case Method.PUT:
				handlePut(request, response)
				break
			
			case Method.POST:
				handlePost(request, response)
				break
							
			default:
				// The request method is not allowed; set an error status
				response.setStatus(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED)
				response.setAllowedMethods([Method.GET, Method.PUT, Method.POST] as Set)
		}
    }

    void handleGet(request, response)
    {
	    response.setEntity("access: closed; messages: 0;", MediaType.TEXT_PLAIN)	
    }

    void handlePut(request, response)
    {
		if (request.attributes.access)
		{
			this.access = request.attributes.access
		}
		else
		{
			response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "The request representation must include the parameter 'access'.")
		}    	
    }

    void handlePost(request, response)
    {
		if (request.attributes.messageContent)
		{
			createMessage(request.attributes.messageContent)
		}
		else
		{
			response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "The request representation must include the parameter 'messageContent'.")
		}    	
    }
}

Definitely easier to read, but still fairly verbose. That switch statement is looking kinda dumb at this point; it's not doing much.

So let's use some dynamic Groovy magic to get rid of it:

    void handle(Request request, Response response)
    {
    	def allowedMethods = [Method.GET, Method.PUT, Method.POST] as Set
    	
    	if (request.method in allowedMethods)
    	{
			def handleMethodName = "handle" + request.method.name.substring(0, 1).toUpperCase() + request.method.name.substring(1).toLowerCase()
			this."$handleMethodName"(request, response)
		}
		else
		{
			// The request method is not allowed; set an error status
			response.setStatus(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED)
			response.setAllowedMethods(allowedMethods)			
		}
	}

OK, now we're getting somewhere! Easy dynamic method invocation – pretty cool.

Thing is, our handle() method is at this point barely doing anything – just figuring out whether the requested HTTP method is allowed, and calling the appropriate class method if it is, or returning an error if it isn't. We shouldn't have to implement this standard logic in every single one of our resources, that'd be pretty redundant.

Thankfully, the developers of Restlet realized this, and they created a very useful class which takes care of much of this sort of overheard for you. It's named, simply, Resource.

Let's convert MailboxResource to extend Resource. We'll do this in a few steps, to illustrate some of the work that Resource does for us.

Let's start MailboxResource from scratch:

#!/usr/bin/env groovy -classpath org.restlet.jar:com.noelios.restlet.jar

import org.restlet.*
import org.restlet.data.*
import org.restlet.resource.*

class MailboxResource extends Resource
{
	static String access = 'closed'
	static int messageCount = 0

	def MailboxResource(Context context, Request request, Response response)
	{
		super(context, request, response)
		variants.add(new Variant(MediaType.APPLICATION_WWW_FORM))
		modifiable = true
	}

}

// Create a Finder which will create new instances of MailboxResource as needed
finder = new Finder(new Context(), MailboxResource.class)

/* Create a new HTTP Server on port 3000, pass it the Finder,
 to which it will pass all incoming Requests, and start it. */
new Server(Protocol.HTTP, 3000, finder).start()

As you can see, there's a new import on line 5, because Resource is in a Restlet sub-package. Now's also a good time to add some static fields to store the state of the resource, on lines 9 and 10. Normally we wouldn't store state this way; this is just more convenient for now than using a real persistent data store.

Next, you'll see that MailboxResource now has a constructor. This may seem like annoying overhead, but trust me, it'll be worth it. For example: the framework will pass the request and response to the constructor, which passes them to the super constructor, which stores them in class fields. This means there's no more need to pass the request and response around to every method – we can just refer to this.request and this.response.

There's some other good things going on in the constructor. On line 15 we add a Variant to the variants collection; this is used for HTTP content negotiation – which Resource does for you. That's right – one of the trickiest aspects of implementing a sophisticated RESTful web app, and you get it for free just by using Resource. Good deal! I'll demonstrate content negotiation in a later article in this series.

The last line of the constructor sets the resource as modifiable; by default instances of Resource only allow GET; setting modifiable to true allows PUT, POST, and DELETE.

We don't want to allow DELETE for now, so let's add this method:

	def boolean allowDelete()
	{
		return false
	}

It's time to add our request handling logic back into the application. Let's add this method:

	def Representation represent(Variant variant)
	{
		def form = new Form()
		
		form.add("access", access)
		form.add("messages", messageCount as String)
		
		return form.webRepresentation
	}

Notice that the new method isn't named “handle” or “handleGet”; instead it's represent(). There are many good and useful reasons for this, but I'm not going to go into all of them at the moment. I'll just point out one for now: after processing a PUT or POST request, a common behaviour is to return a representation of the new, altered, state of the resource. So it's not only when responding to GET that we need to construct a representation of the resource; it's also frequently needed for other methods. Therefore, a specific method for this need makes a lot of sense.

All we need to do now is implement PUT and POST. Here's PUT:

	def void storeRepresentation(Representation representation)
	{
		def form = new Form(representation)

		if (form.getFirst("access"))
		{
			access = form.getFirstValue("access")
			response.entity = represent()
		}
		else
		{
			response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "The request representation must include the parameter 'access'.")
		}
	}

And as you can see, the HTTP method PUT is handled by a method named storeRepresentation(). This is because Restlet attempts to model REST semantics in its API. The framework passes the request representation into the method, because it is the main input of the operation.

On line 3 we see another useful Restlet class: Form. As you might guess, this is convenient for working with web forms.

Finally, let's add support for POST:

	def void acceptRepresentation(Representation representation)
	{
		if (access != 'open')
		{
			response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "A message can only be put into the mailbox if it is open.")
			return
		}

		def form = new Form(representation)

		if (form.getFirst("message_content"))
		{
			messageCount++
			response.entity = represent()
		}
		else
		{
			response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "The request representation must include the parameter 'message_content'.")
		}
	}

Normally, an operation like this would create a sub-resource, and the URL of that resource would be returned as a response header, along with the response status 201 Created. This will be illustrated in a later article in this series.

And that's it, we're done with our first Resource! We just need to make one last change to our script to make it all work; we need to change the last line to:

// Create a Finder which will create new instances of MailboxResource as needed
finder = new Finder(new Context(), MailboxResource.class)

/* Create a new HTTP Server on port 3000, pass it the Finder,
 to which it will pass all incoming Requests, and start it. */
new Server(Protocol.HTTP, 3000, finder).start()

I'll explain the Finder class in a later article.

As the comments indicate, a new instance of MailboxResource will be created for every single HTTP request. At first this might seem inefficient, but it means that every Resource class is inherently threadsafe – no small value there. And it's still plenty fast: my ab script from Part 1 now yields 688 requests per second.

Tests!

Let's update testfulapp.groovy to test our new resource:

#!/usr/bin/env groovy -classpath org.restlet.jar:com.noelios.restlet.jar

import org.restlet.*
import org.restlet.data.*

client = new Client(Protocol.HTTP)
mailboxResourceUrl = "http://localhost:3000/mailbox"


/*** Test 1: at first, access to the mailbox should be closed ***/
response = client.get(mailboxResourceUrl)

assert response.status.code == 200
assert response.entity.mediaType.equals(MediaType.APPLICATION_WWW_FORM, true)
assert response.entityAsForm instanceof Form
assert response.entityAsForm.getFirstValue("access") == "closed"


/*** Test 2: we shouldn't be able to post messages when the mailbox is closed ***/
form = new Form()
form.add("message_content", "whatever")
response = client.post(mailboxResourceUrl, form.webRepresentation)

assert response.status.code == 400
assert response.isEntityAvailable() == false


/*** Test 3: change the mailbox access to "open" ***/
form = new Form()
form.add("access", "open")
response = client.put(mailboxResourceUrl, form.webRepresentation)

assert response.status.code == 200
assert response.isEntityAvailable() == true
assert response.entityAsForm instanceof Form
assert response.entityAsForm.getFirstValue("access") == "open"

messageCount = response.entityAsForm.getFirstValue("messages") as Integer


/*** Test 4: we should be able to post a message now that the mailbox is open ***/
form = new Form()
form.add("message_content", "whatever")
response = client.post(mailboxResourceUrl, form.webRepresentation)

assert response.status.code == 200
assert response.isEntityAvailable() == true
assert response.entityAsForm instanceof Form
assert response.entityAsForm.getFirstValue("access") == "open"
assert response.entityAsForm.getFirstValue("messages") as Integer == messageCount + 1


/*** Test 5: change the mailbox access to "closed" ***/
form = new Form()
form.add("access", "closed")
response = client.put(mailboxResourceUrl, form.webRepresentation)

assert response.status.code == 200
assert response.isEntityAvailable() == true
assert response.entityAsForm instanceof Form
assert response.entityAsForm.getFirstValue("access") == "closed"


println "\nAll tests passed successfully!\n"

That's all, folks!

And that's it! We've now used Restlet to implement a truly RESTful resource. And we used some Groovy goodness as well: switch, Groovy Truth, dynamic method invocation, casting, and more.

I hope this second installment in the series has been interesting and valuable for you, and I look forward to your feedback, comments, critiques, and constructive criticism.

Coming up in Part 3: Routing. And it'll be shorter than this monstrosity, I promise.

Full source of `restfulapp.groovy`

#!/usr/bin/env groovy -classpath org.restlet.jar:com.noelios.restlet.jar

import org.restlet.*
import org.restlet.data.*
import org.restlet.resource.*

class MailboxResource extends Resource
{
	static def access = 'closed'
	static def messageCount = 0

	def MailboxResource(Context context, Request request, Response response)
	{
		super(context, request, response)
		variants.add(new Variant(MediaType.APPLICATION_WWW_FORM))
		modifiable = true
	}
	
	def boolean allowDelete()
	{
		return false
	}

	def Representation represent(Variant variant)
	{
		def form = new Form()
		
		form.add("access", access)
		form.add("messages", messageCount as String)
		
		return form.webRepresentation
	}
	
	def void storeRepresentation(Representation representation)
	{
		def form = new Form(representation)

		if (form.getFirst("access"))
		{
			access = form.getFirstValue("access")
			response.entity = represent()
		}
		else
		{
			response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "The request representation must include the parameter 'access'.")
		}
	}
	
	def void acceptRepresentation(Representation representation)
	{
		if (access != 'open')
		{
			response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "A message can only be put into the mailbox if it is open.")
			return
		}
	
		def form = new Form(representation)

		if (form.getFirst("message_content"))
		{
			messageCount++
			response.entity = represent()
		}
		else
		{
			response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST, "The request representation must include the parameter 'message_content'.")
		}
	}
}

// Create a Finder which will create new instances of MailboxResource as needed
finder = new Finder(new Context(), MailboxResource.class)

/* Create a new HTTP Server on port 3000, pass it the Finder,
 to which it will pass all incoming Requests, and start it. */
new Server(Protocol.HTTP, 3000, finder).start()

Using ColdFusion and LCDS in AIR-powered Flex Applications

javierj@arc90.com (Javier Julio) — Thu, 12 Jun 2008 10:30:00 -0500

Previously, I've discussed how to use ColdFusion Components (CFCs) in AIR-powered Flex applications but I never got a chance to follow up on how to use CF8's integrated LiveCycle Data Services ES in AIR.

I've figured out that all I need to do is specify a ChannelSet component that is reused in both the Consumer and Producer. Since I was developing locally, I set up my AMFChannel to use my local server. You can see in the following example:

I know there are other channels, such as RTMP, but I have not used them yet. Since I was learning how to use CF/LCDS in AIR, I used it in an AIR version of a simple Chat application. I was quite impressed how easy this was to do. By simply setting up the ChannelSet, I had a working LCDS powered AIR application.

Layers of Java Logging

dougb@arc90.com (Doug Burns) — Wed, 11 Jun 2008 10:30:00 -0500

The Java Logging API is great for tracking the internal workings of your application, both during development and after it goes to production. The API is based on a highly flexible configuration model that gives you complete control over what gets logged and where it gets logged.

I recently started using the API after some time away, and it took a bit to get reacquainted with some of its concepts. In my first few attempts, I ended up with either all logging statements output or none, when what I really wanted was output from only a few specific classes.

I think my problem stemmed from confusion between the various ways to filter output. In the end, I found it easiest to think of the API as two separate layers - a filtering layer that answers the question "What should be output?" and a handler layer that answers the question "How should it be output?"

Below is an example configuration divided into two sections. Although they both end up in a single logging.properties file, I've broken them up to demonstrate the concept of separate layers. In the first, I define a default filter level for the entire application, as well as custom filter levels for select packages and classes.

Filter Layer

# Set the global filtering level to INFO. By default all statements below the
# INFO level will not be logged.

.level = INFO

# Set the filtering level for a few packages to ALL. This overrides the
# global level, so all statements in these packages will be output.
# This is good for limiting output to a section of code you're currently
# working with.

com.arc90.package1.level = ALL
com.arc90.package2.level = ALL

# Set the filtering level for a few individual classes. Again, this overrides
# less specific settings. In this case, all statements of level FINE and 
# higher in ClassA will be output, and all statements of level FINER and 
# higher in ClassB will be ouput.

com.arc90.package3.ClassA.level = FINE
com.arc90.package3.ClassB.level = FINER

Next, I'll define the handlers that will be used. In addition, I'll specify filters for the handlers themselves. This performs high level filtering on the final output from the filtering layer. Here, I say that I want only INFO level and higher statements sent to the console, and all statements sent to the log file. The important thing to remember is that these levels apply to the output from the filter layer only - if statements were already filtered out in that layer, they will never make it this far.

Handler Layer

# Specify the handlers to be used. Multiple handlers can be specified
# in a comma separated list.

handlers = java.util.logging.ConsoleHandler,java.util.logging.FileHandler

# Specify the formatters that will be used for each handler

java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

# Specify the log file location for the FileHandler. In this case the log will
# be written to my home directory, in a file named example.log.

java.util.logging.FileHandler.pattern = "%h/example.log"

# Finally, specify the filtering level for each handler

java.util.logging.ConsoleHandler.level = INFO
java.util.logging.FileHandler.level = ALL

Thinking of the Java Logging API this way has helped to clear things up for me, and I hope it will for others as well. If you haven't used the API, you can try it out for yourself by dropping the above text into a logging.properties file (make sure there aren't spaces at the end of the lines or it won't work), which must be palced into your JVM's lib directory or a path specified as a -Djava.util.logging.config.file VM argument. Finally, just add some logging statements to your Java code and you should start seeing output to the console and the log file.

Deposit-friendly Development

joelp@arc90.com (Joel Potischman) — Wed, 11 Jun 2008 10:05:33 -0500

Yesterday I had to deposit a check. My bank, Chase, has begun rolling out new "deposit-friendly" ATMs that require neither envelope nor deposit slip for check-only deposits. The process is shockingly simple. Here's what I had to do:

Select Deposit from the on-screen menu
Insert the endorsed check into a slot, just as I would insert a dollar bill into a vending machine
When I saw an image of the check on-screen, enter its amount [2008/07/02 UPDATE - It gets even better. I discovered today that it actually OCRs the check amount! After I inserted a handwritten check this morning it magically asked me to confirm whether the amount it read on it was correct. It was! I deposited two other checks and it asked me to enter the check amount, indicating that it couldn't read the amounts or it didn't have a high degree of confidence in its scan, so it didn't waste my time asking me to confirm them. I assume OCR would work nearly 100% of the time on machine-generated checks.]
Repeat for any additional checks
Press Done
Get receipt showing an image of my check(s)

Here's what I DIDN'T have to do:

Fill out a deposit slip, which means I didn't need to...
Find a working pen, which I would need if I could...
Remember my checking account number, which I never do, so I used to have to...
Wait in line for a teller to give me my checking account number, before I could...
Check the under-copies of the deposit slip to make sure nobody leaned hard and smushed their deposit info down into my slip or surreptitiously wrote in their account number to scam me into depositing my check into their account. (And to think some people trust paper.)

Chase saw a process where a machine that is already operating in a high-security and high-knowledge context asked me to write down the account number it already knows on a piece of paper it can't read and seal it into an envelope it can't open. What a wonderfully archaic set of steps to get rid of!

For me the customer, life is now clearly simpler, but what about the poor machine? Like all banks, Chase is very comfortable with ATM software and hardware, but surely the addition of machine-reading and imaging each check makes the ATM vastly more complicated and error-prone, yes? Well, no. Every check in the U.S. banking system has the issuing bank's routing number, account number, and check number printed along the bottom in a standard Magnetic Ink Character Recognition (MICR) format designed for accurate high-speed scanning. Banks have been whipping checks around and reading those numbers all day every day for decades. And the check image I saw onscreen and printed on my receipt? They've been doing that for years as well. When's the last time you got actual cancelled checks back in your statement? What might seem like an incredibly complex and high-risk project for you or me was to Chase essentially sticking together a few very familiar Lego pieces they'd used a million times.

Any time you see a business process that asks for information it either already knows, already should know, or can easily find out for itself, there is an opportunity for vastly improving the user experience. When you further see that you can do so with technologies you already live and breathe, to me it reads like the story of the perfect development project. Let's review:

First, there was a clear customer benefit: Customers will spend a lot less time doing tedious and error-prone steps that do not benefit them.
Second, there was a clear client benefit: Bank staff will spend a lot less time looking up account numbers, opening envelopes and deciphering handwriting on incorrectly filled out deposit slips, and making sure the ATM kiosk is stocked with envelopes and deposit slips. Chase will also spend a lot less money buying and almost immediately disposing of NINETEEN MILLION deposit envelopes a year.
Lastly, from an IT standpoint, the requirements are clear and the risk is low: Get rid of all that paper by gluing together all these things we already know very well.

Dare I say it, this project sounds fun! Unfortunately, not all IT projects are such no-brainers. It's not uncommon for a project to be approved with only two of those three stars, or sometimes even one. Maybe it benefits the client and the customer, but it's going to be a huge and risky endeavor to implement. Maybe it will be a huge pain to implement and actually infuriate the customers, but the cost savings make it worthwhile ("Your call is important to us. Please listen carefully as our menu items have changed").

In my experience, the one-star and two-star projects tend to come from an incomplete understanding of the business problem, either by IT or frequently from the business itself. Sometimes clients don't really know what they want. Sometimes they're too close to the action to think long-term. Sometimes they don't understand technology at all. And sometimes we in IT just don't ask, because we're too busy trying to keep production up and running while watching Twitter feeds of the iPhone 3G announcement. I'm just saying.

No matter how it happens, if you simply treat isolated problems as isolated technology projects, you'll get paid for your work, and life will go on. However, a deeper relationship with your client lets you do so much more. Understanding your client's business plans and long-term goals lets you and your client both see the big picture. You'll be surprised to see how this wider worldview leads to a more holistic approach to these seemingly tactical technical problems ("the ATMs fill up with deposit envelopes by 11:30. Make it hold more.") When you do that, you'll see that those one and two star problems can often be rearranged into three star solutions that make everybody happy. Sometimes so happy that they're inspired to stay up late writing paeans to something as mundane as a deposit-friendly ATM.

arc90 blog

Flying Virgin America

Charles, SSL, and you

We're Looking For The Lone Wolf McQuade Of PHP Development

Use grep? Try ack!

Extending Column Background Color--without Images!

My title

My title

My title

From Faceless to Family

Fixing the Can't move '.svn/tmp/entries' to '.svn/entries' error

Netflix Demonstrates Customer Relationship Mastery

Enabling A Drop Shadow On A Flex Container

In praise of System.Object

Introducing Kindling, the first product from Arc90

Building RESTful Web Apps with Groovy and Restlet, Part 2: Resources

Tests!

That's all, folks!

Full source of restfulapp.groovy

Using ColdFusion and LCDS in AIR-powered Flex Applications

Layers of Java Logging

Filter Layer

Handler Layer

Deposit-friendly Development

Full source of `restfulapp.groovy`