Steve Vinoski’s Blog

The May/June issue of my Internet Computing column, “The Functional Web,” is now available. This one’s called “Scala and Lift — Functional Recipes for the Web” (PDF) and I had the great fortune of writing it together with Debasish Ghosh.

I’ve admired Debasish’s blog for awhile now, as he’s always exploring interesting angles and features of different functional programming languages and techniques. I emailed Debasish completely out of the blue and asked if he’d be interested in writing something together, and he jumped right in.

If you ever get a chance to work with Debasish, I highly encourage it. He made the whole task quite easy because he cranked out the first draft so quickly, and as we iteratively edited the column, he turned each draft around literally overnight. He and I live on opposite sides of the world, which worked out well because it allowed one of us to write and edit while the other slept. Meeting deadlines is key to delivering this column on time for each issue of IC, and so I really appreciated Debasish’s attention to our schedule. The fact that he writes well, as you can see in his blog, didn’t hurt at all either. :-)

Given their collective richness, it’s hard to cover both Scala and Lift in a single column, but I think we managed to describe the important issues and features. As always, if you have any feedback on this column, post it here in a comment or email me.

A couple months ago I wrote that my Internet Computing column, “Toward Integration,” was going to end. Indeed it did, but I’m very pleased to report that I’ve replaced it with a whole new column entitled “The Functional Web.”

The inaugural column is imaginatively titled “Welcome to ‘The Functional Web’” and it provides the background for what I plan to cover in the column going forward. All signs indicate that functional languages are garnering significant interest these days. At QCon last week, for example, it seemed like everyone was talking about them, and Real World Haskell didn’t just win a Jolt Award for nothing. Most of my work these days involves web development with Erlang, and given my general interest in functional programming, the combination of these two areas seemed like the perfect direction for a new column.

If you’re a functional programmer working in the web space and have a knack for writing, drop me an email. If you’ve got a good proposal, I’d be happy to either co-author something with you or have you serve as a guest columnist for an issue.

Finally, I’d like to thank the readers of “Toward Integration” very much for sticking with me for the past seven years. That’s a long time, but rest assured your many positive comments and your feedback kept me going — I deeply appreciate it. I really hope you’ll join me for “The Functional Web” and that you’ll keep that excellent feedback coming — it’s going to be interesting and I guarantee we’re all going to learn a few things along the way.

My first Internet Computing column of 2009 is now available. It’s entitled “New Year’s Integration Resolutions” and it offers advice pertaining to areas of integration and distributed systems where over the years I’ve seen various companies and individuals, including myself at times, repeat the same common mistakes. I give the advice in the form of some suggested new year’s resolutions, hence the title.

Something to note about this column is that it completes 7 years of “Toward Integration.” That’s a long time, trust me. :-) Two years ago I stopped working on middleware and integration as a full-time role, so it doesn’t really feel right anymore for me to still be doling out advice on those topics, and I’ve definitely used up all the residual topics I had left. What this means is that this is the final “Toward Integration” column you’ll ever see.

Whether that’s good news or bad news depends, of course, on whether you liked or disliked “Toward Integration.” :-) I generally received positive feedback over the years on all the columns, but I know there are some out there who disagreed with some of them. That’s perfectly normal, of course. Regardless of which camp you fall in, if you ever sent me considered feedback on any of the columns, I really appreciate it.

But then again, I should be clear that it’s not truly the end; I’ll be starting a new column on a new topic in the magazine’s next issue. I don’t yet have a new title for the column, and in fact it may not be as focused as “Toward Integration” generally was. But I’ll need to come up with a new title soon, since I have only about two weeks left before I have to submit the first issue of the new column to my editor.

My Nov./Dec. Internet Computing column is now available. It’s entitled “RESTful Web Services Development Checklist“ and as its name implies, it covers some of the primary areas developers need to focus on to write good RESTful web services. These areas are:

• Resources and their URIs
• Applications and Hypermedia
• Representations and Media Types
• Methods
• Conditional GET

Regarding the “Applications and Hypermedia” area, I feel Roy Fielding’s pain that many efforts labeled as being RESTful seem to completely ignore the hypermedia constraint. I believe many developers tend to miss this constraint because they’re so used to using libraries and frameworks that offer lots of entry points, and having knowledge of those entry points in the client normally isn’t that bad since the client and library/framework are tightly coupled into the same address space anyway. In a distributed system, though, this definitely does not hold true; when the client knows a bunch of entry points into the service, it ties the client to that service and inhibits their independent evolution.

Anyway, please read the column and let me know what you think, and thanks again to Stefan Tilkov for his helpful review of the draft.

Coincidentally I also feel Roy’s pain when it comes to writing about REST. He states:

I don’t try to tell them exactly what to do because, quite frankly, I don’t have anywhere near enough knowledge of their specific context to make such a decision.
…
So, when you find it hard to understand what I have written, please don’t think of it as talking above your head or just too philosophical to be worth your time. I am writing this way because I think the subject deserves a particular form of precision. Instead, take the time to look up the terms. Think of it as an opportunity to learn something new, not because I said so, but because it will do you some personal good to better understand the depth of our field.

Exactly.

Obviously, Roy is the ultimate REST authority, given that he defined it, so I’m not at all claiming to be anywhere near as authoritative about it as he is, yet I’ve also experienced what he says above. For example, consider this informal review of my columns I received a few months ago in a comment on someone else’s blog:

The articles of yours that I’ve read are…amorphous to me. They speak in generalities. I haven’t read an article where you sit down and write the same service using both REST and RPC and compare the two. When you speak in generalities, we can’t objectively evaluate any of the specific trade-offs between approaches… Arguments that happen at too abstract a level can’t go anywhere, because our positions aren’t specific enough for anyone to evaluate anybody else’s claims.

In other words, “since your columns don’t do my thinking and experimentation for me, they’re useless to me.” Hmm. Maybe I’m just old school, but I’d much rather understand mathematics than require someone to hold my hand while I blindly punch buttons on a calculator. In other words, as the old proverb goes, I’d much rather try to teach you to fish so you can feed yourself. As I state in this new column:

Whether developers of RESTful HTTP-based services write their code in IDEs or with simple text editors, and regardless of which programming languages they use, they must understand REST and HTTP fundamentals to succeed.

My latest Internet Computing column has been available since last Friday. It’s entitled “RPC and REST: Dilemma, Disruption, and Displacement” (PDF, HTML) and like my previous 2008 columns, it explores another angle of the “RPC vs. REST” debate.

Since previous columns have covered many of the technical angles, this time I present the debate from the technology adoption angle. As the abstract for the column says, many technologists tend to treat such debates as if they’re purely technical, but of course they’re never that black-and-white. What’s often behind some of the raging “technical” debates we’ve all seen or experienced is simply the difference between the arguing parties in their relative positions along the Technology Adoption Lifecycle curve. Nobody would be surprised at a disagreement over technology between someone classified as an early adopter or visionary (from the far left of the curve) and someone classified as a technology skeptic (from the far right), yet we always seem surprised when two people whose preferences aren’t too far apart on the curve — from the opposite edges of the mainstream band in the middle of the bell curve, for example — don’t see eye to eye, despite the fact that this sort of scenario is quite common. Even small differences in goals for adopted technologies and desired risk/reward trade-offs, along with the inevitable hidden and unstated assumptions resulting from such factors, can cause vigorous debate about what technology or approach is best for a given situation.

When it comes to published explanations of how innovation works and how technologies move along the adoption curve, my favorite author by far is Clayton Christensen. IMO all developers should study and learn from his books, specifically The Innovator’s Dilemma, The Innovator’s Solution, and Seeing What’s Next. All are amazingly insightful works that will open your eyes to how real-life markets react to technological change and advancement.

In this column I try to view and classify the “RPC vs. REST” debate based on Christensen’s theories about innovation and technology adoption. I hope you find it interesting, and as always, I welcome all constructive comments.