Latest Twitter updates

This is still experimental and aggregates the most recent updates from my Twitter feed.

Please wait while my tweets load

If you can't wait - check out what I've been twittering

I’m really sad to see that Google continues its approach of tolerating — and thus, in my view, encouraging — when people build sites that break the Web’s architecture. First, we had this hashbang mess (tl;dr version: Ajax/JS-only sites suck, long version here), now the Google crawler will issue POST requests (no kidding).

Sure, there are worse things happening in the world, but from a REST perspective this is so utterly, totally wrong that it makes me really mad. A GET request is the only thing a crawler should ever issue if it intends to conform to the architecture of the Web, as these requests are safe. Issuing POSTs just because so many people don’t understand the distinction between GET and POST (or use crappy web frameworks that don’t) just means that even more people will do so. In the end, everyone will have to use heuristics to find out what can be called safely, and what can’t — effectively trading specified behavior for the typical kind of crap that you usually only get when something evolves without any architectural vision.

Google’s very core business was enabled by the Web’s architecture, now they’re slowly helping to ruin it.

“Do no evil” my ass.

Benefits of Structure

| | Comments (0)

Whether it’s some project-internal documentation, a public presentation, training material or any other kind of technical content, I find it amazing how often the very simplest advice could help the authors improve their work dramatically: Add some structure.

I’ve just seen yet another document where the authors describe their outline in the introduction, and then proceed to ignore it; where random bits of information are inserted in the middle of a section they clearly don’t belong to; where a topic is picked up, dropped, picked up again, and finally left hanging in some state of limbo.

I find that structuring your thoughts is the very first thing you should do when you create content for others to consume. If you don’t do this before you start writing, at the very least have the courtesy to do it before you hand it over to anybody else to look at. I find this just as obvious as making sure there are no spelling errors. Apart from making it a lot easier to make others understand what you were thinking, it helps you think in the first place.

The Second International Workshop on RESTful Design (WS-REST 2011) aims to provide a forum for discussion and dissemination of research on the emerging resource-oriented style of Web service design.

Background

Over the past few years, several discussions between advocates of the two major architectural styles for designing and implementing Web services (the RPC/ESB-oriented approach and the resource-oriented approach) have been mainly held outside of the research and academic community, within dedicated mailing lists, forums and practitioner communities. The RESTful approach to Web services has also received a significant amount of attention from industry as indicated by the numerous technical books being published on the topic.

This second edition of WS-REST, co-located with the WWW2011 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.

In addition to presentations on novel applications of RESTful Web services technologies, the workshop program will also include discussions on the limits of the applicability of the REST architectural style, as well as recent advances in research that aim at tackling new problems that may require to extend the basic REST architectural style. The organizers are seeking novel and original, high quality paper submissions on research contributions focusing on the following topics:

  • Applications of the REST architectural style to novel domains
  • Design Patterns and Anti-Patterns for RESTful services
  • RESTful service composition
  • Inverted REST (REST for push events)
  • Integration of Pub/Sub with REST
  • Performance and QoS Evaluations of RESTful services
  • REST compliant transaction models
  • Mashups
  • Frameworks and toolkits for RESTful service implementations
  • Frameworks and toolkits for RESTful service consumption
  • Modeling RESTful services
  • Resource Design and Granularity
  • Evolution of RESTful services
  • Versioning and Extension of REST APIs
  • HTTP extensions and replacements
  • REST compliant protocols beyond HTTP
  • Multi-Protocol REST (REST architectures across protocols)

All workshop papers are peer-reviewed and accepted papers will be published as part of the ACM Digital Library. Two kinds of contributions are sought: short position papers (not to exceed 4 pages in ACM style format) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages in the ACM style format) describing novel solutions to relevant problems. Technology demonstrations are particularly welcome, and we encourage authors to focus on "lessons learned" rather than describing an implementation.

Papers must be submitted electronically in PDF format.

Easychair page: http://www.easychair.org/conferences/?conf=wsrest2011

Important Dates

  • Submission deadline: January 31, 2011, 23.59 local time in San Francisco, CA
  • Notification of acceptance: February 15, 2011
  • Camera-ready versions of accepted papers: February 28, 2011
  • WS-REST 2011 Workshop: March 28, 2011

Program Committee Chairs

  • Cesare Pautasso, Faculty of Informatics, USI Lugano, Switzerland
  • Erik Wilde, School of Information, UC Berkeley, USA
  • Rosa Alarcon, Computer Science Department, Pontificia Universidad de Chile, Chile

Program Committee

  • Jan Algermissen, Nord Software Consulting, Germany
  • Subbu Allamaraju, Yahoo Inc., USA
  • Mike Amudsen, USA
  • Benjamin Carlyle, Australia
  • Stuart Charlton, Elastra, USA
  • Duncan Cragg, USA
  • Joe Gregorio, Google, USA
  • Michael Hausenblas, DERI, Ireland
  • Ralph Johnson, University of Illinois, USA
  • Rohit Khare, 4K Associates, USA
  • Yves Lafon, W3C, USA
  • Frank Leymann, University of Stuttgart, Germany
  • Ian Robinson, Thoughtworks, UK
  • Stefan Tilkov, innoQ, Germany
  • Steve Vinoski, Verivue, USA
  • Jim Webber, NEO4J
  • Olaf Zimmermann, IBM Zurich Research Lab, Switzerland

Contact

I had the great pleasure of being invited to co-author one of Steve Vinoski's Functional Web columns -- a big deal for me, as Steve is sort of a childhood hero for me (well, not really, but his technical writings on all things CORBA hugely inspired me when I started my career). The article's topic is node.js, one of the most fascinating and disruptive approaches to network programming I've seen in quit a while. Checkout the PDF of the article.

Please note: The IEEE holds the copyrights on these works. This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author’s copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Apple Killing Java?

| | Comments (10)

I got alerted to this earlier today by my good friend Hendrik Schreiber, who develops awesome software for Mac OS X using Java: It seems Apple has killed Java on future OS X releases.

I can understand this, to a certain degree -- for Apple, Java is no longer a platform they want anyone to write apps in, so why waste engineering dollars to support it? On the other hand, there are tons of Java developers who use Macs, as shown by the Mac market share on any Java-centric conference in the last few years -- it's anything between 20 and 75%, with something as high as 90% among speakers. Of course it's going to hurt Apple if all of these folks switch to a different platform, and I do believe it might even be significant considering the network effect (as many of them, including me, were Mac OS X evangelists). I also know that in our company, innoQ, roughly 40 of our 50 developers are Mac OS X users, and it's likely none of them will be anymore two or three years from now. Given an average lifetime of 2 years per 2500 € box, that's about 50k we'll invest somewhere else. I suspect the same will be true for many other shops who use Java and other JVM languages (mostly JRuby in our case).

It's entirely possible the Apple folks have considered this, and come up with more reasons to drop Java than to sustain it. And of course it might all be a misunderstanding, or they might change their mind again, as it happened with other things, such as the App store rules. I just wouldn't bet on it.

From a personal perspective, it sucks very, very much. But hey, they are very good reasons for using Linux too, right?

It's no secret that I've become I big fan of Clojure in the last year or so. I've done three talks, collaborated on a series of print articles (part 1, 2 and 3) and an online article to promote it as much as I can, and I think I made up with enthusiasm for my lack of practical experience. But I'm definitely not experienced enough with the language to do a multi-day workshop that would stand up to some tough questions. On the contrary, in fact I'd love to attend an advanced workshop done by some really smart folks who have more than introductory-level knowledge.

So I got in touch with two of the most respected Clojure folks in Europe, Christophe Grand and Lau B. Jensen, and asked them whether they'd be interested in doing one of their conj-labs trainings in Germany. And they agreed in exchange for my promise to help them a little with regards to marketing it around here. Which I've gladly agreed to do :-)

So, mark the date: From 26 to 28 October, Frankfurt will be the place to learn about one of the coolest programming languages on the planet. What are you waiting for? Find out more, register now, and please help spread the word.

(Next up: A bunch of good reasons in German to use to help convincing your boss, if you happen to have one – stay tuned.)

InfoQ has put up a video of my QCon London presentation. Too bad the animations in the slides aren't included -- spoils some of the fun.

I recently thought about what to expect in a web framework that claims to have "REST support", and came up with a list of questions that one should ask to see whether such a claim is justified:

  • Does the framework respect that an HTTP message does not only consist of a URI? I.e., is dispatch done at least based on the HTTP verb, the URI, the Content-type and Accept headers?
  • Can I easily use the same business logic while returning different content types in the response?
  • Is there support for checking for conditional requests?
  • Are ETags calculated automatically if none are set by the backend logic?
  • Can I (as a framework user) easily read all HTTP request headers?
  • Can I easily set all HTTP response headers?
  • Can I use custom HTTP verbs?
  • Is it obvious and easy how to return correct status codes with responses, and does the framework use them correctly (if it does so at all)?

Update: Two aspects added due to feedback by Erik Mogensen and Mike Amundsen:

  • Is there an easy way to produce links that "point back" resources identified by whatever means the framework exposes (such as some form of routing)?
  • Are resources identified and requests dispatched to code by the full URI, or is there an artificial distinction between the path and query parameters?

Along the same lines, here are some questions where a "Yes" indicates that a framework doesn't do things the way they're supposed to be done:

  • Are GET, POST and other requests to the same URI dispatched to the same business logic by default?
  • Am I required to use "extensions" (e.g. ".xml", ".json") to get different representations of the same resource? (Supporting this optionally is OK.)
  • Are there method names in the URI?

Finally, I wonder whether there's any justification for a web framework to support "REST services" as an addition instead of the default, but I'm reluctant to put this into the second list.

Suggestions for extending the list are welcome.

Together with Mathias Meyer and Markus Völter I recently recorded a SoftwareArchitekTOUR podcast on NoSQL data stores; heise.de has put it online now. It was great to have Mathias on the show, not only did he clearly know three times more about the topic than Markus and I combined, he also added a nice additional dialect to our portfolio …

InfoQ Interview

| | Comments (4)

At QCon London, Sadek Dobri interviewed me on REST – this was a nice chance for me to voice my current thinking about most, if not all things RESTful. InfoQ has put the video up online.



These are the most current entries; check out the archives for more.