mca blog

it's official! i've signed to do a new book for O'Reilly. the working title is "Programming the Web with Cloud9" and it covers the Cloud9 browser-based IDE for building Web apps.

i've been using the IDE for several months (actually put myself on an "all c9, all the time" regime for a while) and have really been impressed. in fact, over the last sveeral weeks i've actually been bummed out when i ran into a few cases where i actually needed to use my local workstation to handle a task instead of relying on "C9 and the Cloud" to do it all. hey, it happens[g].

hardware, software, wetware

while the main focus of the book is the Cloud9 editor, it will also cover other 'cloud-based' developer tools including CouchDB, github, and Heroku and more. in addition to the actual software and hardware, i am also digging into the 'wet-ware' aspects of cloud-based programming. this includes how cloud-based dev tools affect teams, collaboration, project schedules, code quality, etc. along the way, i will have the chance to meet and interview some very smart people who are active in shaping the future of this kind of Web developer's experience.

the journey begins

i'll officially kick off the start of the new project w/ a trip to Node Summit in San Francisco next week. if you're in the area, i'd love to meet you and get your opinions/predictions regarding these (and other) 'cloud-based' development tools. who knows, maybe some of your comments will end up in the book!

over the last couple months, i've been experimenting with a "new" development stack; what i call a "cloud stack." this development environment consists of a set of independent, but complimentary tools and services - all available via the Web. they make up a "full stack" for web development that is, IMO, quite enjoyable to work with. even better, i find it a very productive environment, too.

hello, cloud

i've noticed that, along with the rise of "the cloud" as an infrastructure model, there is also a corresponding development model. this model provides a cloud-based environment that includes editing, debugging, testing, source control, project mgmt, and deployment; all accessible from nothing more than a modern (i.e. HTML5-compliant) browser.

and, just as the process of virtualizing the hardware stack has acted as a distruptive technology for the back office, this emerging virtual programming environment will, i suspect, prove to be just as disruptive, too.

my current cloud stack of choice

here is my current toolkit for cloud-stack development:

Cloud9

i've really enjoyed using the Cloud9 browser-hosted code editor over the last few months. very similar (in some ways, related) to Mozilla's Bespin/Skywriter project, C9 is (for me at least) living up to the copy on it's home page: "Cloud9 is a state-of-the-art IDE that runs in your browser and lives in the cloud, allowing you to run, test, debug, and deploy applications from anywhere, anytime."

Node.js

i started using Node.js just about a year ago for a couple experiments; i've continued to enjoy working with it ever since. it's nice that Cloud9 supports runtime-debugging of Node.js, too. like the web site sez: "Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices."

CouchDB

along w/ using Node.js, i've started using Apache CouchDB as a data store. from the site: "Apache CouchDB is a document-oriented database that can be queried and indexed using JavaScript in a MapReduce fashion." right now i am testing two CouchDB providers: Cloudant and IrisCouch; both seem very solid.

Github

i've used a number of git-based repos lately, but continue to rely on github as my "go-to" source control tool. it helps that the Cloud9 editor also uses git locally and will let you clone any project from github easily. forking and code review are another thing that make github very enjoyable to use.

Heroku

i've recently started using Heroku as a deployment target for my completed Node.js projects ("Agile deployment for Ruby, Node.js, Clojure, Java, Python, and Scala."). again, it's easy since Cloud9 supports git-based deployment to Herkou directly from the editor interface. it took a bit of "tweaking" to get my git master properly 'prepped' for Heroku, but once that's done, incremental updates are a snap.

one of the nicer aspects of the above stack is that you can get started with each of them at no charge. IOW, it's essentially free to experiment. not bad at all.

the bigger picture

so far, this is the stack that works for me. there are a number of other products/services out there that i haven't yet tried, but basically it boils down to the same general programming set: editor/debugger, storage, source control, and deployment. i've left out things like testing and other helpers as i am just getting around to exploring those tools, too.

but, regardless of the details, i think the pattern is clear; there are quite a number of options for putting together your own 'cloud-stack' development environment. and i suspect this kind of environment will grow popular in time. along the way, i bet we'll see other (major) vendors make offerings in this space, too. when that happens i suspect the market for this kind of work will continue to grow and get even better.

have you assembled a 'cloud-stack' programming environment? if yes, let me know. i'd love to hear about other experiences.

Here is one way I talk about HTTP and Fielding's REST model:

the way of HTTP

HTTP was designed to favor long term (measured in years/decades) run-time stability over ease of implementation. to do this, it relies on some very simple (but powerful) constraints:

• every machine that operates over the WWW is constrained to a very tiny executable interface (what we know as the HTTP verbs). The details of this restricted interface are documented in a protocol that rarely changes over time and even when it does change, great pains are made to ensure these changes do not invalidate past implementations.
• every message sent over that interface consists to two basic parts: control data as a set of name-value pairs (HTTP Headers) and a single self-describing message body. This body can be "described" as 1) a structured document (text/html), 2) a binary image (image/png), 3) a list of arguments (application/x-www-form-urlencoded), etc. in HTTP the message contains not just data, but also instructions on how to operate on the data and what program-flow options are valid at that particular point in time. The list of "understood" message formats are publicly registered w/ the IANA today and is meant to evolve relatively easily over time in ways that do not "break" existing implementations.
• everything of importance is reachable using a universally understood address (URI). the list of addresses, while based on standards, is essentially unlimited and implementors are free to mint new ones as often as they wish and/or abandon existing addresses at any time.

the other way

implementing solutions under these constraints is usually quite different than what most programmers/architects learn in school. most training is "the reverse" of the above rules. Such that:

• the list of verbs in the interface is unlimited and their details (arguments, etc.) are subject to change. most implementation effort is focused on defining , documenting, and maintaining this variable interface.
• the program flow is found in code rather than in messages. usually in multiple place (clients and servers).
• the list of 'addresses' is constrained to the name of the executable programs themselves which do not change as often as the interface

why the differences matter

Fielding's dissertation, while focused on the details of identifying and documenting arbitrary styles of software architecture for distributed systems, still does a very good job of documenting a single example (or 'style') of software architecture that is closely aligned with the HTTP constraints listed at the top of this post. Fielding named his example "REST".

history has shown that the HTTP protocol is a very flexible protocol and that not all implementations need to follow the example provided by Fielding in order to meet the needs of users. for example, RPC over HTTP works just fine for many cases; esp. those that do not require system stability on the scale of years/decades.

however, the more important it is for the solution to continue to operate (and evolve) over an extended period of time, the more useful are the additional constraints Fielding identified in his example and the more important it is to optimize for run-time stability over ease/speed of initial implementation.

"What is surprising about the Shaw et al. model is that, rather than defining the software's architecture as existing within the software, it is defining a description of the software's architecture as if that were the architecture."

Roy T. Fielding

"If you think the menu 'is' the meal, you'll have to eat your words."

Alfred Korzybski

valuable guidance when designing a Hypermedia API (emphasis and brackets "[]" mine):

Think of each action by the user [of your API] as an attempt to step in the right direction; an error is simply an action that is incompletely or improperly specified. Think of the action as part of a natural, constructive dialog between the user [and/or user-agent] and the system [your API]. Try to support, not fight, the user's responses. Allow the user [and/or user-agent] to recover from errors, to know what was done and what happened, and to reverse any unwanted outcome. make it easy to reverse operations; make it hard to do irreversible actions. Design explorable systems [APIs].

Donald A. Norman in The Design of Everyday Things, 1990.

designing (and implementing) Hypermedia APIs is more than simply exposing server-side operations to clients (users, user-agents, etc.). instead, good Hypermedia APIs include the proper amount of affordances and constraints which allow users|user-agents to successfully interact with servers in order to complete one or more tasks in an effort to accomplish a pre-determined goal.

usability (in all its commonly-known forms and interpretations) is an essential aspect of Hypermedia. usability is, in the end, an essential aspect of all systems; esp. 'complex' ones.

how usable is your API?