beacon
Lately my blog has been devoid of the deep technical content implied by my host name; I assure you it has not been from lack of interest. In the last two months, I've published three articles on IBM's developerWorks, each exploring a different aspect of Project Zero and REST. Check it out:
- Title: Extend Project Zero's scripting platform with Flickr APIs
Abstract: The Flickr photo sharing service is one of today's most popular Web applications. It provides a robust hosting service with slick social networking capabilities that make uploading, organizing, and finding photos very simple. That's all very cool, but from a developer's perspective, the most interesting thing about Flickr is its public API for reading and writing photo data. You can send API requests over HTTP using any programming language you wish, and many open source projects have sprung up to encapsulate this API for various languages. In this article, you'll learn how to "Zero-ize" the Flickr API by providing a Groovy binding that is easily reusable in your Project Zero applications. When you're done, you'll be able to read and write photo data from your Groovy scripts in just a few lines of code.
Reader's Digest Version: You want to use the Flickr API in your Java applications, but everywhere you turn there's a factory pattern or a glorified HttpURLConnection. You have started building Flickr URLs with StringBuilder, laboring under the strain of append() and hard-to-read query strings, when you receive the tragic news: you have died of dysentery. Game over.
Fortunately, Groovy scripting lets you use all of your Java skillz while shaking off the cruft that was keeping you down. This article creates a set of Groovy scripts for invoking the Flickr API and shows how to share the scripts throughout your Zero applications; it ends by showing you how to generate one of those ubiquitous photo collages so that your site will look exactly like every other site on the Internet. - Title: Manage an HTTP server using RESTful interfaces and Project Zero
Abstract: WS-* users and REST users have an ongoing debate over which technique is most appropriate for which problem sets, with WS-* users often claiming that more complex, enterprise-level problems cannot be solved RESTfully. This article puts that theory to the test by trying to create a RESTful solution for a problem area that is not often discussed by REST users: systems management. In a previous developerWorks tutorial, I showed how to create a Web services interface for managing HTTP server products; the tutorial used concepts from WSDL and the WS-* standards to define the management interface and software from Apache Muse and Apache Axis to create the management application. For this article, I use Project Zero and REST design principles to recreate the interface and function of the original application and determine if REST is a valid option for this enterprise project.
Reader's Digest Version: Human sacrifice! Dogs and cats living together! Mass hysteria!
It's almost unthinkable: creating a fair and level comparison of WS-* and REST based on experience working in both worlds. Well, I went ahead and thought it, and then I wrote it down so everyone could share my completely non-hysterical evaluation of REST as a foundation for remote systems management tools. - Title: Add Ruby templating to your Project Zero applications
Abstract: Ruby users, take note. You can now do everything that Groovy and PHP users can do when creating Project Zero applications! In a previous article, we showed how to augment Project Zero to provide support for the Ruby scripting language. The code that we wrote enabled Ruby users to transfer their scripting skills to the Zero platform and take advantage of its unique programming model. Of course, scripting isn't the only way that Ruby is used to create applications - programmmers who use the Ruby on Rails framework also mix Ruby in HTML templates similar to JSP and PHP. These templates, called RHTML files, are very useful for creating dynamic user interfaces, and this article will show you how to extend our Ruby support to include them.
Reader's Digest Version: Remember the first time you saw Back to the Future? As the movie ends, Marty has just discovered that his father isn't a sucker anymore, his sister is popular, his brother has a job, and something he's done has warranted his parents buying him a brand new 4x4. When Jennifer struts in a few minutes later, you undoubtedly thought, This was a killer movie. And you were right.
But then, out of nowhere, Doc screeches into Marty's driveway in a beat-up De Lorean and tells the two teenagers that their future is in shambles and they have to go to the future to prevent a certain tragedy. No way! The movie closes with the De Lorean lifting off the ground and flying into 2015. Wow! Robert Zemeckis just turned your expectations upside-down, and now you can hardly wait for Back to the Future II. Do you remember that?
Well, if you're like most people, you had the exact same response when you read this last abstract and realized that my Ruby on Zero article has its own Part II; you thought the first article was great, but now that you've gotten a taste, you can't imagine life without Part II and its Mr. Fusion-fueled RHTML files.
Having explored over a dozen topics related to Zero and REST, it's clear to me that one of Zero's greatest strengths is how flexible it is; in other words, Zero does not get in my way as I try to bend it to meet the needs of my project. Most of the time I don't have to do any bending at all, but sometimes I do, and rarely is something so hard that it's deemed impossible or not worth the trouble. If the Zero platform is successful, this will certainly be one of the reasons: it provides you with many tools and conventions for getting things done, but it doesn't force you into absolutes or some kind of software design religion.
Labels: narcissism, programming, zero
posted by Dan at
3:50 PM
0 Comments:
Post a Comment
<< Home