License 2 Code

A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon more and shouts, “Excuse me, can you tell me where I am?” The man below says “Yes, your in a balloon that’s hovering over thirty feet above this field.”

“You must work in information technology.” says the balloonist. “I do,” replies the man, how did you know?” “Well,” says the balloonist “everything you have told me is technically correct, but it’s of no practical use to anyone.” The man below says “You must be a corporate manager.” “I am,” replies the balloonist, “how did you know?”

“Well,” says the man, “you don’t know where you are, or where you’re going, but you expect me to be able to help. You have the same problem you had before we met, but now it’s my fault.”

HA Ha, ha… (sigh)

From the Pretty Good Joke Book.

InfoQ has a great format for video/podcast content - recordings synced with transcriptions or slides. I started watching Joshua Bloch’s Javapolis presentation on API design. “But I don’t design APIs or frameworks…” Um, do you program? Bloch starts with the adage that thinking in terms of API design improves code quality - “Good code is modular - each module has an API”.

I have found this to be extremely true, and the more I’ve learned about API design, the more my own code quality has improved. Learning the principles of design-by-contract for example, had a tremendous impact on my code. A longer summary is in order once I can digest the entire presentation.

There is an incredible amount of content online like this these days - ninja-quality speakers, slide-sets included. Makes one think you could assemble your own mini-conference (minus the networking of course) in your pajamas. Anyone up for an API design discussion session over beers after watching this?

*bonus - a great interview/concurrent transcription with DHH on the future of Rails.

After slaving away for hours over submissions of all quality, the editorial board has updated SOAFacts with a number of independently verified nuggets.

Duncan Cragg just finished part two of the REST Dialogues. So, the stage has been set. You can get a resource by using HTTP GET at a URI and you can suggest a change to a resource by POSTing the updated version of the retrieved resource. We’ve got alot of power here and the next article will focus on Business Functions. Now we’re going to get to the heart of the issue.

At the same time, Pete Lacey has written a very funny faux-dialog titled “The S Stands for Simple“. I absolutely loved this article. I’ll bet that you’ll continue to think back to this article as your write your next SOAP-enabled service.

A few funny excerpts:

SOAP Guy: Sure thing. First, SOAP stands for Simple Object Access Protocol.

Dev: So it’s simple?

SG: Simple as Sunday, my friend.

…

SG: Sure thing. First there’s the SOAP envelope. It’s pretty simple. It’s just an XML document consisting of a header and a body. And in the body you make your RPC call.

Dev: So this is all about RPCs?

…

SG: No. SOAP doesn’t really use HTTP response codes.

Dev: So, when you said SOAP uses HTTP, what you meant to say is SOAP tunnels over HTTP.

SG: Well, tunnel is such an ugly word. We prefer to say SOAP is transport agnostic.

…

SG: Remote procedure calls! Serialized objects! Where did you get the impression that SOAP was about RPCs? SOAP is all about document-based message passing, my friend.

Dev: But you just said…

SG: Forget what I said. From here on in we pass around coarse-grained messages—you like that term, coarse-grained?. Messages that conform to an XML Schema. We call the new style Document/Literal and the old style RPC/Encoded.

…

SG: Sorry to hear that, buddy. On the bright side, nobody uses the Doc/Lit style anymore. In order to get transport independence back we’re all using wrapped-doc/lit now. Doesn’t that sound cool: wrapped-doc/lit?

It’s a good 5-min read, don’t pass up the opportunity.

After wrasslin’ with a simple Eclipse plug-in project, I was struck that if:

IDEA is OSX,

and JBuilder is Windows,

then Eclipse is Debian Linux.

Let’s hope…

White Spy has been bringing the REST content to l2c, so when someone recommended this imaginary interview with an eBay architect on REST vs. SOAP, I had to read through. Interesting treatment, great way to draw out the differences.

Suggest an interview you’d like to see at l2c and we’ll see if we can swing it.

Bookpool in in the midst of their 50% off O’Reilly book sale. Kind of buries O’Reilly’s own ‘hey java is now open source so we’ll give you 40% off our ten crappiest java titles’ sale. (Link only provided so you can see the list of ten).

Buy hey, at least O’Reilly pocket refs are 50% off in PDF format here. Good deal.

Well, it finally happened. Java is now open source under the GPLv2.

http://www.sun.com/software/opensource/java/

I feel this will have a very substantial impact on the Java community and that this impact will be positive:

• Specifically, I believe bug fixes and features will be added to the JDK at a faster rate.
• Additionally, I believe additional “usages” of Java will be enabled by this (e.g. being able to natively compile a Swing app).
• Finally, I believe this will substantially improve Java’s adoption (in part due to inclusion in Linux distros).

“Now I know how to do SOA right”. Marketing slogan from a test-automation company. You see, since “SOA is a methodology and technique to deliver J2EE, .NET, XML Web Services, Web applications, and anything else that uses a network to provide users with information services” (emphasis added) and “Services are always-on and must work well when many users make requests all-at-once.” SOA is all about performance testing.

Now granted I’m a fan of performance testing, especially when its incorporated into the dev process using tools like JPerfUnit and JMeter, and not done as an afterthought late in the quality assurance cycle. And I’m a fan of the PushToTest model, which is to support the community and user of the open source TestMaker tool. So this post isn’t so much to slam PTT as much as it is to highlight an interesting example of the hype train that is SOA… Read more »

In my research on REST this last week, I’ve seen several comments noting confusion on whether to use PUT or POST. After reading several references (Elliotte Rusty Harold, Sacrificial Rabbit, and Mark Baker) , I loosely paraphrase the rule as:

Use PUT when you know the ID of the resource you are creating or modifying and the operation is idempotent. Use POST otherwise.

In other words, don’t bother with CRUD as an analogy. Instead think:
GET –> View Representation of Resource
PUT –> Create/Modify client-identified Resource
POST –> Create/Modify server-identified Resource
DELETE –> Delete Resource

Updated on 11/4 to add the idempotent piece above.

Stefan Tilkov illustrates a fundamental difference between REST and SOAP with two graphics. REST being resource-oriented and SOAP being service-oriented.

SOAP

REST

The SOAP illustration has fewer classes, but is more obscure because the methods are the services. The REST illustration has more classes, but the operations are more obvious. A counter-argument is that complex services are harder to represent in REST than SOAP. But that’s the point, the resource-oriented architecture has differing constraints due to differing design goals.

Reference: http://www.innoq.com/blog/st/2006/06/30/rest_vs_soap_oh_no_not_again.html

I went to MinneDemo 1 earlier this year and had a great time. I highly recommend you attend if you get the chance.

MinneDemo 2, to be held December 11, 2006 at the Acadia Cafe in Minneapolis, needs YOU to demo your kick-ass software!

We have four great presenters lined up already. We are going to have 6-7 demos this time, so that means we need 2-3 more demos. Please sign up on the wiki page here: http://barcamp.org/MinneDemo

It’s first come, first served, so if there are no more spots, just add your name to the list for presenters at the next MinneDemo and you will get first consideration for a demo then.

http://barcamp.org/MinneDemo

Our new venue not only has great beer (24 kinds on tap) and food, but has a separate theater area for presentations. This means plenty of space for socializing AND watching demos. For more info, check out http://www.acadiacafe.com

Regards,
Luke Francl and Dan Grisby
co-organizers

Elliotte Rusty Harold’s post titled, “Why Rest Failed” starts with an inflammatory title and goes on to assert that rest failed because clients (browsers) don’t support PUT and DELETE - two of the four verbs required for REST. He notes that clients can use the XMLHttpRequest object and that XForms supports these, but not forms in browsers. He’s right on these counts, but he fails to elaborate on his assertion that REST has failed.

Has REST failed? It’s used in the ATOM publishing API, there’s a Java framework (Restlet) to support REST (in it’s infancy), and I often hear it used as a counter-argument to SOA. At the same time, I’m not sure a “faithful” implementation of REST has succeeded to capturing developer’s hearts and minds (by faithful I mean based on the Fielding Dissertation).

Has REST failed? Maybe. But there is sufficient interest in the topic from the tech community to keep it alive. And maybe that’s enough.

Two of my favorite blog aggregators (after Central Standard Tech of course) are the Thoughtworks blogs, and the ObjectMentor blogs. Thoughtworks tends to range a little more afield, but has some strong contributors in Jay Fields, Obie Fernandez, George Malamidis, Neal Ford, and of course Martin Fowler. Lot of Ruby there… The ObjectMentor blogs have less content, but are more focused.

I’ve bemoaned the loss of Software Development magazine. Sometimes a spy in the field has to rely on anything he can get his hands on. Being that SD was free and good made this easy, and kept those bean-counters back at central intel off my back. I always read Robert Martin’s ‘Craftsman’ articles as if he was sending secret coded messages to me:

‘Field agent black - pay attention to my missives, and you’ll be amply rewarded with real software construction nuggets you can apply to stay alive in an ever-more-hostile development environment.’

Characters like the green-but-hungry Alphonse, seductive Jasmine, and the mysterious Mr. C face real-world problems, and describe their solutions in a conversational style complete with real code examples. Ahh pseudonyms, I could so relate!

Thankfully, the entire series is posted here (click the craftsman link). 49 installments in all! Act now before some bean-counter realizes the profit potential of these sold as a single volume. Forget dailylit - start working through the craftsman now.