A chess set, won

John and I have been playing chess since he was four.  I've made it a point over the years never to take it easy on him.  Ever.  In the early games, he really took losing to heart and Rebecca would shake her head disapprovingly at the heartless... er, competitive... way I played, so I made a deal that the day he wins, he gets my chess set.  

Tonight, at seven years of age, he has caused me to be in the market for a new chess set.  He beat me, and I didn't even see it coming.

I always knew the day would come but, for some reason, I assumed it'd be gradual, perceptible, and, frankly, years away.  I was focused on bringing my Queen to cover the eighth rank while he was seemingly goofing around with some pawns, then, in a swift Qg7->Qa1 it was done, "got you Daddy."  He says that a lot though, so it took a while for it to slowly sink in.  Sadness, pride, happiness, deflation, humility... he won. Fair and square, he won and got himself a pretty decent chess set tonight.  

I'm so happy for him and look forward to many more games on his "new" chess set...

Our last first tooth loss...

When John lost his first tooth, it was pure excitement.  With Grace, there's excitement too, but accompanied by a tinge of sadness that this will be our last first tooth loss in our family.  I suppose it's the same with all the "firsts" but with this coming on the heels of our last first day of kindergarten, I suppose it's sinking in more.  I'm so happy to watch her grow, but I do wish she'd slow down just a bit...

Enlightened corporate leadership

In a world where corporate leadership is dominated by a pursuit of growth and profit, it's encouraging to see some examples of enlightened leadership.  I initially came across this post from Tim O'Reilly saying,

"It was at this time that I formulated an image that I've used many times since: profit in a business is like gas in a car. You don't want to run out of gas, but neither do you want to think that your road trip is a tour of gas stations."

 He references a Huffington Post article in which Steve Jobs has this gem:

"My passion has been to build an enduring company where people were motivated to make great products," Jobs told Isaacson. "[T]he products, not the profits, were the motivation. Sculley flipped these priorities to where the goal was to make money. It's a subtle difference, but it ends up meaning everything."

And back to Tim O'Reilly,

"What's so great about the Apple story is that Steve ended up making enormous amounts of money without making it a primary goal of the company. (Ditto Larry and Sergey at Google.) ...  Making money through true value creation driven by the desire to make great things that last, and make the world a better place - that's the heart of what is best in capitalism. "

This sort of thinking is also represented clearly in the book Firms of Endearment.  The world would be a better place if more business leaders would focus their corporate energy into something they are deeply passionate about and allow profit and growth to be a nice side effect.  Who knows, maybe Jobs' legacy will be to inspire a generation of leadership that has the courage and confidence to passionately believe in what their doing and stop with the "growth/profit as a primal focus" meme.

Boots

If you've been fortunate enough to take a SERE course there's an excellent chance you've had Rudyard Kipling's poem Boots branded on your mind.  It's a special poem to SERE graduates.  But simply reading it's words isn't particularly satisfying, you've likely yearned to hear it in a particular audio form.  I don't know if this is the exact audio but with it's emotion and poor audio quality, it's close enough.

This reading makes the Library of Congress' National Jukebox project worth every penny to me! (actual poem starts at ~34 seconds)

PicasaUploader to Facebook Problems

So, this is semi-tested theory that hasn't let me down so far.  I use the PicasaUploader App in Facebook to get my pictures from Picasa to Facebook's Photos with frustrating intermittent success.  Sometimes it would go through the process perfectly and others it would never open the browser to do the last step that confirms the upload.  After playing around a while, it seems that <= 9 pictures is the key.  Try uploading 10 or more and it fails, but 9 or below is fine.  I dunno, it sounds arbitrary and strange, but this has worked so far for me.  I post this here in case someone else is having similar problems maybe they'll find this and confirm it.  YMMV.

First class link relations

The original proposal had link types:

"it is useful for the system to be aware of the generic types of the links between items (dependences, for example)... without imposing any limitations." ... "Note that each link has a type ("includes" for example)..." (1989)

and later, it was made clear that link relations should be first-class - peers to the target itself - or, first-class link selection criteria:

"In this way, link relationships in HTML, and in future XML hypertext languages, should migrate to becoming first class objects." (1999)

I suppose that migration is finally upon us?  RFC 5988 - Web Linking

Two wheels at last!

Me:  "It's your decision, but you just road with the training wheels barely touching.  I think you're ready."
Grace:  "K.  Let's do this.  Daddy, go get your tools and take 'em off!"
Me:  "Yes ma'am"

She then walked the bike mid-way down the street and boldly road all the way up on two wheels her first time.

REST and self-descriptiveness

The REST Architectural Style has this constraint called the Uniform Interface. The Uniform Interface Constraint itself decomposes into four constraints and one of those, the self-descriptive messages constraint, decomposes into at *least* three other constraints. The analysis of what system properties are evoked was done at the highest level - the Uniform Interface Constraint. So, what happens when you modify one of the sub-sub constraints? Who knows, as with all the constraints, you should probably *think* about it with "your eyes wide open"*....

if you don't see a movie below, open outside your reader:)

* an unfindable Roy quote

RESTFest 2010

I just returned from RESTFest 2010 in Greenville, S.C (on a side note, I wasn't thrilled about the location at first, but I should say, the people in Greenville, S.C. are great and the downtown area rocks - I never imagined I'd say such a thing about Greenville, but... there it is... it rocks - if you have a chance to work or visit, take it!) - it was great to see the Raleigh crew again and meet some new folks. Starting with Mike's thorough Hypermedia Workshop the first day and some great extended and lightening talks Saturday.

There was Apache CouchDB well-represented with some cool presentations and hacking, some really bizarre stuff (I'm thinking Events:), and everything in between. I don't do .Net development but if I did, I'd be pretty excited to get my hands on the coolness that Glenn presented on that platform. Anyway, many thanks to Ben and Mike for all their hard work to pull this thing together... Here's everyone that made it all the way to the end:



And a HUGE thanks to all the great sponsors. They were:

• github
• CouchOne
• Microsoft
• O'Reilly
• gnoso
• telerik
• pluralsight
• Devexpress

Our first toothfairy visit...

... will be tonight!  John's been wiggling that tooth for weeks now and just came excitedly up the stairs to proclaim his loss.  He's real happy and immediately wanted to eat foods of different textures to see how they feel:)

Health through good-for-you food

Science and the medical community are finally catching up to our elders and "raw foodies" who have, for years, claimed that eating your [natural non-GMO] vegetables will keep you healthy.  I can't remember it now, but I watched a convincing movie several years ago where a collection of last-resort cancer patients went into seclusion on a raw food diet and most (if not all) returned cancer free.

I have to say, that the secondary benefit of healthy eating might be reducing obesity, gave me a "duh!" reaction.  Anyway, ridiculously interesting, you really should watch it.

Happy SysAdminDay Infra

Happy Sysadmin Appreciation Day to the Apache Infra team!  Thanks so much for all you do to keep us safely and securely computing.  We enjoy the fruits of your ridiculous talent and tireless labor, you guys rock!

Architecture of Governance Structures

When working on complex problems it's easy to get bogged down by stuff that just doesn't matter. In software, we address this through architecture. We define, up front, properties we'd like to see in the end system. Then, we carefully begin adding constraints that will evoke those system properties. Over time, we learn that we can snapshot certain coordinated constraints and refer to them by a simple name - as an "architectural style."

For example, we might endeavor to have a system that evokes the properties of re-usability, simplicity, and evolvability and this might lead us to a design based on the Pipe-and-Filters Architectural Style which is a set of contraints (e.g. Uniform Interface) known to positively effect those properties. But you can learn more about that reading Roy's dissertation.

Like software architecture, within organizational governance it's easy to get bogged down by stuff that just doesn't matter. This typically leads to more bureaucracy. I'm interested in thinking about applying the same architectural techniques to defining an organizational governance structure.

For starters, we'd need to think about the properties that are important to the organization. For this experiment, I'll use an organization with wide familiarity - the Apache Software Foundation. So let's define some [subset of] organizational properties that are important to the ASF:

• Participatory (Pa) - the characteristic of affording the opportunity for broad participation.
• Stability (S) - the characteristic of the organization and it's product to be viable over a long period of time.
• Protectiveness (Pr) - the characteristic of being protective of volunteers and end-users from liability.
• Frictionless (F) - the characteristic of achieving goals while minimizing friction.
• Modifiability (M) - the ease with which a change can be made to the organization and/or its products.
• ...

This is enough to get the experiment going. Now, we can begin adding constraints and reason about their effect on the organizations governance goals.

1. Open mailing lists. Open mailing lists shall be used to facilitate communication and decisions. By channeling communications over asynchronous medium we maximize participation (Pa). We further maximize participation by being volunteer friendly - they can get to it when they get to it. It enhances stability (S) by being both openly archived and self-documenting. It moderately evokes modifiability (M) allowing anyone to participate in decisions and direction of the project.

2. CLA/CCLA/Grants. All contributors must agree to grant copyright/license to the ASF. This has a positive effect on long-term project stability (S) and modifiability (M). The great positive effective also negatively impacts wide participation (Pa).

3. Release Process. All projects must have formal releases following a process that ensures license compatibility, export controls, etc. This has a positive effect on protectiveness (Pr) by ensuring that software release to the public is done under the Corporate entity (ie. the Foundation).

4. Decision making. When coordination is required, projects use simple, pre-defined voting procedures. These are simple votes (+1, 0, -1) for pre-defined approval types (e.g. lazy consensus, consensus, etc.) for pre-defined actions (e.g. releases, major code shift, new committer, etc.). Having a transparent decision making process limits friction (F). It also has a positive impact on long-term stability (S), participation (Pa), and modifiability (M).

5...

Hopefully that's enough to convey the idea. Once the properties are fully enumerated and the constraints fleshed out, we might dub this coordinated constraints the "Apache Organizational Style." I'm sure the analogy and, therefore, the framework breaks down somewhere, but it seems a better fit than the typical adhoc adaptiveness that many organizations currently suffer. I think the key value that this brings is focus. Every proposed governance change would need to be reasoned about through the lens of desired organizational properties. It also forces the organization to think about what properties it really thinks are important.

Textual Weather

I've been annoyed for years at the increasing trend towards graphics-only weather forecasts. With 24 hours in a day, how can a single picture with two numbers be particularly helpful? Anyway, I finally realized how to get a nice text forecast in the Mac Dashboard - I know, I'm a little slow.

In Safari, navigate to weather.gov.

Enter your zip code in the left side.

Now, scroll down and look at the bottom right, and click on "Text Only Forecast".

No go to File->Open in Dashboard...

Highlight the middle text section, and click "Add..."

That's it, that's my not-so-new tip of the day. Now, if I could only get it in a fixed-width font:)

Article:Using DNS for REST Web Service Discovery

I'm not sure if it's a "Good Thing To Do" or not, but it is interesting. Personally, I haven't seen the "service discovery" problem first-hand - I've long thought it a problem manufactured by vendors to sell their ESB-ish wares... I'll definitely be watching to see how the comments on this one play out:)

Article:Using DNS for REST Web Service Discovery: "Service Discovery is an essential aspect of service orientated architecture because it avoids early binding of clients to particular service instances. In this article, Jan Algermissen explains the need for discovery of RESTful services, and explains how the existing Domain Name Service (DNS) standard can be used as a widely-deployed and scalable solution. By Jan Algermissen"

Green escalators...

I'm at a conference watching empty escalators roll constantly and I'm thinking what an incredible energy waste. Ironically, the first speaker of the morning touted the "green-ness" of the Raleigh Convention Center.

My first inclination was that escalators should come with sensors that would detect an approaching person and start it rolling and continue rolling until they are detected to have left the disembarking area.

After further consideration, given that we have an obesity epidemic accompanying our energy challenges, the best thing for our energy and our health would be to just turn them off entirely...

WWW2010 WS-REST Workshop

Day 1 of WWW2010 is complete. I spent the day in the WS-REST Workshop. The day, for me, started out a bit sketchy. Sam's talk was ridiculously interesting, but only tangentially related to REST. Most of the others were solid, predictable and safe. The couple presentations that did approach the edge of our current understanding of REST were, well, bizarre and, arguably, an impedance mismatch for the style itself.

Federico's talk (no slides) was pretty interesting. He suggested the need to describe and communicate new styles that were based on REST but not exactly REST. More generally, a practical model for visualizing and understanding architecture design rationale. He had a modeling tool (i forget the name) that manages a graph of constraint, rationale, and properties (or somesuch). This is somewhat analogous to the styles->properties mapping in the dissertation itself but instead of talking about styles, talking about the constraints directly. For other reasons, I've come to talk directly about constraints instead of REST too lately. It turns out that frameworks facilitate getting REST wrong just as much as they do getting it right, so instead of talking about a squishy style, I've found it more useful to enumerate the constraints explicitly. Having a modeling approach to reason about all this would be pretty useful.

Being hosted at a conference dominated by academia, potential "research areas" seemed a key focus. Some thoughts that I had during the day...

1) It seems that we need more research on getting from style to architecture. Practically, we end up with an unreasonable delta between where the style leaves off and additional constraints of the architecture. We need a framework for defining, sharing, and reasoning about those extended constraints. This doesn't get highlighted very often primarily because the folks that talk about REST do so from the perspective of a single service rather than an
architecture group constraining a set of services across an enterprise? For example, suppose a particular architectural style gives us 6 constraints and a specific architecture has 3 additional constraints. Those 3 constraints are, typically, hidden as implementation details but they should be highlighted and reasoned about in the same way that the style itself was.

2) Someone mentioned the need for the sales pitch for REST style. In other words, if a simple RPC-style solution could be hacked together in half the time, why spend time designing media types, changing the paradigm, etc. ? Intuitively, it seems that the answer is the system properties evoked by the REST style, but maybe that doesn't resonate with managers, etc.?

3) Media type design. Someone mentioned this too, but it's clearly a theme in the RESTful world. It seems that we have collectively grokked what Roy has given us in his dissertation so far and are all collectively struggling with the variety of media type issues. When to pick one over another; when to create your own; how to create your own; json:link types missing; when to use specific vs. generic representation control data (e.g. /xml or /myformat+xml); etc.

4) Link qualifications. Link relations are clearly the way to assert the semantics of the relationship between the "current" resource and some "target" resource. I think we need some clear way to qualify the "target" resource independent of it's relation to the current. Perhaps there isn't a particularly important link relation but you want to assert some link selection criteria anyway.

5) Transactions, of course, got token mention. Mike(i think) mentioned them as the "third rail" of REST:) I dunno, I don't do services on the wild internet so maybe it's a concern, but I got a gut feeling that we've got some problem-solution force-fit going on here. I see the same thing with messaging too - I haven't seen a lot of valid needs for a composite REST/Publish-Subscribe Style. I like REST. A lot. But there are plenty of other valid architectural styles appropriate to other problem domains.

6) Similar to #1 above where there needs to be a macro discussion of REST for the enterprise, I wonder if there's a place for REST style in the micro. It seems like the same REST principles could be applied to micro application architecture. Something like the Actor model of immutable message passing.

Anyway, my rough notes of Day 1 as I understood it...

Hypermedia constraint check

The Hypermedia Constraint seems to be the toughest one for developers to "get" in a RESTful system.  Most of my architecture documentation/communication effort has been focused on those things that one needs to get it right.  Things like: links in representations, link relations, etc.  Still, all too often, folks get it wrong.  Terribly wrong even.  So, I've thought about a simple check that I could provide as the hint that you're "doing it wrong":

Imagine the URLs to all resources except the static bookmark had a variable number of random numbers somewhere in the path and changed on each request.  Would your client still work?  Would your service's documentation still be correct?

Is it possible to answer yes to both questions and still break the hypermedia constraint?

RFC 5785: Defining Well-Known URIs

This feels like a terrible idea. "Fixed URIs"... it just sounds wrong in a hypertext driven ecosystem. Must be a better way. Why couldn't this be addressed by defining good site-* link relations?

RFC 5785: Defining Well-Known URIs: "

This first piece of the discovery stack was published today as an RFC. RFC 5785 defines a registry for new well-known URIs which will provide a standard location for the host-meta document. This work started a year and a half ago as a well-known document called /site-meta, and slowly evolved into a simple registry. While this isn’t a breakthrough idea, it does codify existing behavior and hopefully encourages people to share ideas, discuss proposals, and reusing existing well-known URIs.

ASF Membership += Me

I've been proud to participate in the Apache community in a variety of roles over the past five years.  I'm surprised and honored to learn that I've been voted in as an ASF member.  Thanks for nominating and voting for me...