An Opinion? Well, if you ask...

Criteria for Innovative Success

2009-06-18T06:34:00.000-07:00

I've got this in my head and want to write it down. I'm still tweaking it, and would like feedback.

Criteria for Innovative Success:

1a) A Shared Vision of Success
1b) Willingness to drive towards that Vision
2) Reflective Problem Solving Staff

A Shared Vision is, well, shared. Everyone involved should be able to articulate it, write/draw it on a single white board.

I split 1) into two parts, or more specifically added the second part. I think that just having a vision isn't sufficient, the will to see it through and cut away what's not helpful is critical. I suppose the metaphor for 1b) would be chipping marble away to make a sculpture.

"Reflective Problem Solving" is a phrase I got from "Managing to Learn" by John Shook. I've got more to say about this book and will review it when I can, but having a team of people who refectively problem solve is very different than a team that does what it's told.

In my experience at the Lean Kanban conference I concluded that a Kanban board with WIP limits is a "concrete reflective tool". I'm now on the hunt for "concrete reflective" tools and ideas, with a strong belief that such tools will be adopted by more teams than abstract or prescriptive tools.

Presenting at Austin JUG tonight, Kanban

2009-05-26T13:54:00.000-07:00

Update: The presentation went well, lots of good questions and conversation.

Link to the slides: http://gistlabs.com/john/pubs/2009/05/AJUG/

I'm presenting at the Austin Java Users Group tonight, on Kanban.

The slides will get posted there and on my company website, http://gistlabs.com, shortly.

Setting up our Kanban board

2009-05-19T08:35:00.000-07:00

Last week one of my clients and I set up a Kanban board for the team. We did it as a physical board, and we're backing each card with an issue in a tracker.

We plan to use the issue tracker for these purposes:

generate a Cumulative Flow Diagram (perhaps scripting an export to CSV or Excel)
searchable index of activity
release management tracking
conversation (comments, emails, checkins) for details larger than a notecard

Here's what the board looks like:
Some details (that are hard to read):

A Prioritized Queue on the left, highest priority on top
Three workflow/VSM steps: InProgress, Review, Deployment
Review is for developer peer review, and Staging (on QA for general review)
Deployment Ready is available for production deployment, Deployed is recently deployed.
Three swimlanes: two for development activities, one for IT operations support.

This is the current prototype for the cards:
Some of the tools that we use include sticky post-it notes and Stikky Clips. (Note: We found the Stikky Clips at a teacher supply store, not a big office supply store.)

My Lean Kanban trip report is...

2009-05-11T14:21:00.000-07:00

Posted up on the Agile Executive Blog.

See the whole post here: http://theagileexecutive.com/2009/05/11/john-heintz-on-the-lean-kanban-2009-conference/

Back from the Lean Kanban Conference

2009-05-11T12:07:00.000-07:00

I'm back and planning on posting to my blog more. I've been posting on Twitter (http://twitter.com/jheintz) fairly regularly now. Some stuff just doesn't fit within 140 characters...

The Lean and Kanban conference was awesome: both humbling and inspiring. My trip report will show up on The Agile Executive blog (http://theagileexecutive.com/) soon... I'll post a direct link.

Below is a summary of my twitter activity, just to get warmed up.

@TheOtherAlistai @RonJeffries Iteration is like metronome, Kanban is like multiple rhythms, from #lk2009 (must find who said that...)2:42 PM May 9th from Tweetie
RT have a YouTube link for this eating style ;) -- @jeremiahakin: Langston eats apples like mr peepers from Saturday Night Live9:36 PM May 8th from Tweetie
#lk2009 So long, Miami, and thanks for all the fish!3:02 PM May 8th from Tweetie
@agile_exec Picked up a Lean Kanban Conference preceesings book for Israel... Who really should have been here! #lk20091:10 PM May 8th from Tweetie
@alshalloway great conversation about how/why Kanban removes fear/impedemnts to individual learning, must blog! #lk200912:37 PM May 8th from Tweetie
@agilemanager why is introducing Kanban easier than Scrum? I'm suggesting Kanban provides concrete reflection tools, lowers barrier #lk20098:36 AM May 8th from Tweetie in reply to agilemanager
Err, I meant tuning WIP and workflow is easy for people that wouldn't normally contribute to retrospective #lk20098:26 AM May 8th from Tweetie
Tuning WIP limits and workflow on the board is low resistance, even fir people that normally would say a think in a retrospective #lk20098:24 AM May 8th from Tweetie
I said concrete introspection is maybe the reason kanban is different. Just telling people to reflect doesn't just work. #lk20098:22 AM May 8th from Tweetie
I said concrete introspection, I mean that most people won't retrospect. Getting more people thinking in the biz is the real win. (hypothes)8:21 AM May 8th from Tweetie
Laribee just compared Kanban boards to the RESTful web metaphor... #lk20094:40 PM May 7th from Tweetie
Any good survey of online kanban tools? #lk200911:20 AM May 7th from Tweetie
Any good summary of online kanban tools? #lk20911:03 AM May 7th from Tweetie
Alisson Vale contract agreements: problem solving, support, improvements for sustainability, new value #lk200911:02 AM May 7th from Tweetie
Alisson Vale defined four (social?) contracts with customers #lk200911:00 AM May 7th from Tweetie
Alisson Vale "long term relationships require long term contracts" #lk200910:58 AM May 7th from Tweetie
@carlacorkern Chaka what? :) I'm at the learning gemba, not vegetarian.10:42 PM May 6th from Tweetie in reply to carlacorkern
@dennisstevens I'm not sure TWI is right either, but I have a strong hunch that is has wisdom for teaching knowledge workers. #lk20094:12 PM May 6th from Tweetie in reply to dennisstevens
#lk2009 link to TWI resource: http://delicious.com/jheint... training within industry is a WWII management system that influenced Lean.4:05 PM May 6th from Tweetie

Hotkeys for Omnifocus/Firefox

2009-01-06T10:58:00.000-08:00

Until I get a chance to try out this integration for Firefox and Omnifocus (http://forums.omnigroup.com/archive/index.php/t-4510.html) I wanted to make a record of the hot keys I'm using right now.

Goal: Get a link to the current page I'm viewing in Firefox into a new task in Omnifocus.

Steps:

Command-L to get the browser location URL highlighted.
Command-C to copy that location.
Control-Alt-Space to open a new Omnifocus inbox item.
Type a short description of the new task.
Command-' to open the entry field for the notes. (This is single quote, not back tic.)
Command-V to paste the previously copied URL.

It works, avoids using the mouse, but that is too many steps.

My best code review

2008-12-05T19:11:00.000-08:00

In 1998 (or maybe 1999?) I was a fairly junior developer, but fortunate to be working under a really smart mentor (Aamod Sane).

Among many things that I'm grateful for was his relatively constant practice of helping me through constructive code reviews.

The one that sticks out, the one that changed my view of how to write my own code, started out with me excited with finishing the code and a few tests for some now forgotten task.

After reading through it myself to hopefully avoid really stupid mistakes ;) I kind of ran down the hall to get the attention of my supervisor/mentor.

Once he finished what he was doing we started walking back towards my workstation.

[...this is where it starts to get interesting...]

On the walk back towards my machine I was nervously and rapidly telling him what, why, and how the code does what it's supposed to.

[Me doing all this quick overview talking was important actually...]

We sit down at my machine, swivel the monitor over, and he start reading.

He....
sighs.

Then....
shakes his head.

Really. That's what happened.
Yes, you know what I felt like. ;)

If it had just ended there it would have been like any other awful code review (see http://www.osnews.com/story/19266/WTFs_m)

So, finally, the really good conclusion.

Before he left he said this to me:

Just make the code look like what you just told me.

That walk between machines earlier when I rambled my way through telling him what the code did was actually a fairly clear description of things. The code I had actually written was really detailed, messy, and all together just "code".

After the advice of my mentor, I looked at the code with fresh eyes and I could see better method names, better looping patterns, and just better ways to "tell the story" of what I was trying to do.

Now, I try to write my code so that it "reads" like a good story. Sometimes I do a really good job, and other times not so much, but I have a clear goal that I'm shooting for.

My Favorite Inverview Question

2008-08-27T12:23:00.000-07:00

In a recent discussion interview questions came up, here's my favorite one.

To set some context this question is designed to gauge the abstract and critical thinking of a generally inexperienced developer. I don't usually use this for very experienced developers, but may if I think I'm getting shallow or suspicious answers.

Here's what I start with:

I'm friendly but not at all helpful while I do this.

I draw it out by hand on a whiteboard or on paper
I verbalize the relationships
I offer to explain the notation and meaning of "is-a"
I ask them to think out-loud
I hand them the writing instrument

Then I just ask the candidate for their impressions of the model.

What's good? What's bad? What would you change?

A few obvious things that the candidate should work their way around to:

A "Deer" is an animal also.
A "Cow" could be "Food" for a "Tiger".

After watching them squirm for a while, I then make one addition to the original model. I add a single method/operation to the "Animal" class.
Again, I ask them for their impressions.

If they don't get to it themselves I make sure to ask the following questions:

What happens if a "Deer" is passed to the eat method of a "Cow"?
How would you change the model to handle or avoid that problem?

Enjoy!

Comments, REST, Interactions, and Extensible Hypermedia

2008-01-16T12:23:00.000-08:00

This post is to mostly keep track of the numerous blog threads going on about IDLs and schemas for REST. I find myself with more to say that wit to organize it... :(

First my summaries of opinions, then links to my comments here and there.

Some of my opinions on a RESTful Client Engine, and what types of server-side changes would NOT break a client:

URIs are discovered (except the first)
Server-provided data extensions (hidden fields with defaults in a form) are treated like "does not understand" but still submitted properly
Changes to which HTTP verb are used. The server can swap PUT for POST without issue (verb is discovered in form not spec'ed in a schema)
Changes in state path. "checkout" could directly be a single form with POST, a GET link to a single for with POST, a POST to a form with reliable PUT semantics, .......

Links,opinions on the changing landscape of content (and predictions of the future of hypermedia content):

Sam Ruby's suggestions for HTML5 Distributed Extensibility is a fabulous starting point.
URI Templates, HTML Forms, XForms, Web Forms, WADL
XSD is being extended to better support versioning
Data schemas designed for extensibility should allow everything possible to be optional
Microformats enable opportunistic clients to machine process
GRDDL leaps from microformats, xml, some json up to RDF
HTML+Microformats can do a ton of this already, but with no machine processable anything
Prediction: in 10 years all of this this will have exploded/merged into one or a few really cool and evolvable data/interaction schema systems

References to programming and type systems that address these issues more appropriately than any IDL (as far as I can get into them so far... :)

from Stu Charlton comes a reference to interaction machines
from Todd Hoff comes a reference to two NASA reference on Mision Planning and Closed Loop Execution and Recovery
papers from Luis Caires, for example Spatial-Behavioral Types, Distributed Services, and Resources
(forget where I found this material from... can't understand it yet...)

The following is a guide to my recent comments on these threads from around the web:

Subbu says:

Should this idea be extended to the rest of non-user facing resource-oriented applications? I don't think so. Here is why.
The idea of hypermedia embedding all the action controls necessary to interact with the server works well for an arbitrary number of universal clients interacting with a given server. In this case, the server offering a set of resources specifies all the ordering/interaction rules within the representation. Most application clients, on the other hand, interact with more than one server, and the ordering constraints can not be set by any given server. The clients know how to compose applications out of resources offered by various servers, and each client needs to be able to exercise control over composition. To be able to exercise such a control, client applications can not be universal, and the benefits that John lists above cannot be completely realized.

My comments is that clients should be opportunistic: if they understand some shared semantic (like a RESTful shopping API or task manager) then they can automate some interactions.

On JJ Dubray's blog I make several comments.

In response to "REST creates strong coupling", I say:

JJ is ignoring the shared definitions of MIME types
The globally shared "Provider external" (Pe) semantics in REST are (URI, GET representation, hyperlinks)
in WS-* the Pe globally is 0 (zero), only particular shared uses have a shared semantic.

In response to "REST and inter-actions", I say (and say and say):

For me REST in the enterprise isn't about scalability, but rather independent evolution and support for partial failure.
In maybe 10 years there will be an XML schema language that properly supports versioning and extensibility

In Steve Vinoski's blog on "IDLs vs Human Documentation" I comment that:

I side with Patrick Mueller: there is something of value in more than just prose to document RESTful systems
Hypermedia MIME types are _more_ than just a data schema (embedded forms to signify actions)
A list of RESTful interactions that _shouldn't_ break a programmed client (listed below)

Premature Conclusions with Services and REST

2007-12-17T20:52:00.000-08:00

Damn, I wish we were at a white board. Oh well.

JJ, you've drawn a lot of conclusions from talking with a few people in the REST community. I think you've gotten ahead of yourself.

To defend the "REST community": What we are talking about isn't where most of the value is. Not yet anyway. Maybe someday this issue will really be an issue, but right now just GETing info with declarative representation data is so unusual that we're on the fringe.

Really, I believe this on the internet at large and in many organizations as well (enterprisey doesn't even get funny when sharing a database is so common.) . How much value does a definition language really have? Well, some. Just like I appreciate static languages for documentation and _some_ checking, having a WSDL or something is useful. None of the things being thrown around for "interface definition language" are much more useful than being able to organize documentation, generate code (a bad idea), and create pictures (sometimes useful for humans). That last point, the human part, is where you started this conversation... Let's not pretend that WSDL allows machines to process things for us.

To your recent post. I don't have much time tonight, but hear is my reaction.

Shared Understanding.
This isn't actually denied by the REST. It's just relegated to the media type.

The "contract" that is specific to a particular domain in a RESTful system is buried in the Representation. That means a) we all collectively don't know much about it, b) every system can use the standard VERBS to explore and partially integrate. The first point means we need to have this very conversation, but the value of that struggle is more common ground between all services.

Result Sets aren't Resources
Huh? Why not? I'll need to read up on the posts, but everything interesting is a resource. I don't understand why you conclude this.

Some of your recent posts have indicated what I think may be a confusion regarding the "uniform interface" and resources. Not every resource must support and expose each method. Part of the discovery of REST is learning (at runtime) what methods are available for each resources. Results sets don't need to expose PUT.

How many people are in this discussion?
Not many, I'm afraid. You're assuming that people won't discuss these issues with you, but it's probably that it doesn't matter to most of the RESTful systems out there.

As an example: the Amazon service exposed this weekend. It is people (not machine processes) that are writing the wrapper layers around the new API. It almost doesn't matter what they had exposed it in, people need to spend thought understanding it and wrapping it. Then, other people, need to consume the wrappers to write applications.

Had Amazon used some magically fantastic definition language it wouldn't change but a part of the total human/computer processing cost and value proposition. Again, I think there is value in understanding and exposing that fantastic definition language. I'm not assuming it will magically compose my systems. (I'm not necessarily claiming you make that declaration either, but the value you place on the formality seems too strong. I will read your book on composition to really understand what you are saying.)

REST and actions
There is something critically important about the distinction between "action interfaces" and "document exchange". You took Subbu to task for trying to remove actions, but I think there is a truly subtle reason that REST motivates that thinking.

I'm not sure I can express it well, but this is my intuitive view:

contract negotiation is an (endless?) cycle of document exchange
reserving a _good_ hotel room is an cycle of question/answer...
bartering is a cycle of bid exchange
resolving a speeding ticket is ...

what these real ways of getting things done tell me is that an interface contract doesn't model the real world.

REST models "action" as one or more transfer of document representation. That is more like the world than interface actions.

REST and versioning.
Really bad at versioning? Seriously? If you'd said "efficiency", or "tool support", or "machine clients" I'd be right there saying "Yeah, maybe this would improve that..."

Versioning is hard because something wants to change - and the rest of the system isn't yet ready to change as well. REST has from the beginning been about supporting that change (across organizations, and between the client and server). The very reason that interface definition languages are so hard to reconcile with REST is because of the radically different view on how to support evolution.

(I'm posting this without all the links...)

Shared Understanding and/or Evolvability

2007-12-12T09:42:00.000-08:00

(This is belated and too short. All you fast-typing bloggers out there can just be patient :) Sorry for the delay!)

How do distributed systems both cooperate and evolve?

That is a subtly different question than JJ asks:

when no human is in the loop, you need a shared understanding between the resource consumer and the resource (provider)

The only viable choices JJ then describes (WSDL or WADL) do indeed provide a partial solution to coding shared understanding, but not evolution.

The short (flip?) answer to my leading question is to create a new media type that describes the semantics necessary for both consumers and providers to communicate.

In the case of exposing a Job Application Service as a RESTful provider that could mean the following:

for a human provide an HTML response representation with forms for review, cancel, submit interview.
for a machine provide an XML or RDF (or something) response representation.

That machine representation must have a lot of things going for it. It must provide just enough shared information to do useful things, but not prevent service evolution. In particular, the response must:

provide links/conformance to some shared schema type(s) (to share semantics)
be extensible (in the "does not understand" sense)
the shared schema can't pre-define URIs
the shared schema can't pre-constrain all of the transition paths

That last one is really fuzzy, but I'm trying to express the idea with my "signposts" metaphor. Getting something done (i.e. changing the state of something) isn't alway a single step, and how many steps have to be followed isn't a very stable property. In the case of job applications, getting from "offered" to "accepted" might take a few loops in the 1.1 release of the service, or maybe the "review" state gets split into 2 steps, what happens then?

The current conception of "shared understanding" is "shared interface". In the Job Application example that means the client service is encoded to expect after "Submit Review" that the service moved the job app to "reviewed". If the client service instead was coded to have a pair of (current job app data, desired state) when the service changed to a 2-stage review process the clients would likely continue to work:

Client: Get job app 123
Service: job app 123, submitted, "Submit Review", "Cancel"
Client: "Submit Review" for job app 123
Service: job app 123, review1, "Submit Review", "Cancel", "Reject"
Client: "Submit Review" for job app 123
Service: job app 123, reviewed, "Submit Interview", "Cancel", "Reject"

Understanding how to encode an imperative SOA static model to a conversational document interchange is not really that well understood yet (certainly to me). I think someday it will be, but right now there is just the quotes from the REST thesis I commented on and a reference to "data reactive programming" from Roy Fielding, and I just found Mimosa.

Just need to make sure of something about the Job Application Service example: is this service the provider or consumer of the lifecycle of a job app? It clearly has an internal state machine for job apps, but what other machine process does that get shared with?

[1] Some discussion (still searching for link...) hinted that WADL could be simply returned like an HTML Form, and not used to statically generate code. I think avoids the coupling of code-gen, but I'm not sure how it solves the problem of shared understanding either.

Passing and Returning Nulls

2007-11-29T14:38:00.000-08:00

Several blog posts about handling null values caught my attention.

The pair of posts from Marty Alchin on "Returning None is Evil" and "Except the Unexpected" offer these opinions:

most methods can return null
Java has lots of APIs that silently return null (java.util.Map.get(Object key))
returned nulls are annoying and hard to debug
exceptions should be preferred when a non-null value isn't available
always consider when/how nulls should(n't) be used

Cedric Otaku in "It's okay to return null" chimes in with these valid points:

don't return exceptions unless something really is exceptional
use the Null Object pattern if you need it

Neither of those suggestions (exceptions or Null Object) really work out well for my taste. I really don't like these bad choices:

Write clear and direct code -- that neither shows where nulls could be hiding nor handles them well when they occur
Write lots of verbose if/then/else and try/catch blocks to deal with nulls everywhere

So what to do? Borrow a construct from somewhere else of course!

In the Scala programming language I was introduced to the Option class. I'm pretty sure that is comes from Haskell and other places, but I'm not really researching it.

An Option is like a list of zero or one elements; either a Some with a value, or a None.

Functions that return or receive "optional" things use an Option wrapper to both document that fact and promote cleaner code constructs. Here is an example.

Normal Java code with an override variable:


String overrideMessage;
final String defaultMessage="Howdy";

public String sayHello(String name) {
  String s=null;
  if (overrideMessage!=null)
      s = overrideMessage;
  else
      s = defaultMessage;

  return s+" "+name;
}

Yuck! Now let's uses Option to clean up that method:


Option<String> overrideMessage=none();
final String defaultMessage="Howdy";

public String sayHello(String name) {
  return overrideMessage.or(defaultMessage)+" "+name;
}

Much nicer. The Java version can accept alternate values (with the or() method) but not code blocks to execute like the Scala version can (unless Java gets closures...). The Scala version can participate in list comprehensions and all sorts of other things, but I'm not not talking about those things now.

Here is the full version of my Option port to Java:


public class Options {

  /**
   * An Option can be either full (Some<T>) or empty (None).
   * Instead of passing/returning nulls use an Option
   */
  public abstract static class Option<T> {
      public final boolean some;
      public final boolean none;
   
      private Option(boolean some) {
          this.some = some;
          this.none = !some;
      }
   
      abstract public T val();
   
      public T or(T defaultResult) {
          if (some)
              return val();
          else
              return defaultResult;
      }
  }

  /**
   * Placeholder for empty
   */
  public static class None<T> extends Option {
      private None() {
          super(false);
      }
      public T val() {
          throw new NullPointerException("Can't dereference a None value");
      }
  }

  /**
   * A Holder for some value (never null)
   */
  public static class Some<T> extends Option {
      private final T val;
      private Some(T val) {
          super(true);
          this.val = val;
      }
      public T val() {
          return val;
      }
  }

  /**
   * Use this when not sure if value is present or null
   */
  public static <T> Option<T> option(T value) {
      if (value==null)
          return none();
      else
          return some(value);
  }

  /**
   * Use this to wrap a non-null value
   */
  public static <T> Some<T> some(T value) {
      return new Some<T>(value);
  }

  @SuppressWarnings("unchecked")
  private final static None NONE=new None();

  /**
   * Use this when you don't have a value
   */
  @SuppressWarnings("unchecked")
  public static <T> Option<T> none() {
      return NONE;
  } 
}

Using a lazy proxy to avoid Spring dependency cycles

2007-11-27T11:58:00.000-08:00

Ever gotten a dependency cycle in your Spring configuration?

How about using the Hibernate Annotations and @Configurable together?

Hibernate will instantiate a single instance of each Entity class and ask for the default key value.
But when the first instance is instantiated @Configurable will try to Spring configure that instance.
It that Entity depends on anything that leads back to Hibernate... Bang!

I like this quote from Rod Johnson: "Ouch: this is nastier." That about sums it up. Oh, and that quote is from 2004.

I created a LazyProxyFactoryBean to allow me the chance to not break the cycle, but at least lazy resolve it. Combining a Spring FactoryBean with a dynamic proxy does the trick. Hope this can help someone else out there.

Here is a failing example with cycles:


<bean id="serviceA" class="com.ServiceA">
<property name="serviceB" ref="serviceB"/>
</bean>

<bean id="serviceB" class="com.ServiceB">
<property name="serviceA" ref="serviceA"/>
</bean>

Here is a modified version with a lazy proxy inserted (notice that proxy property is a value, not a ref):


<bean id="serviceA" class="com.ServiceA">
<property name="serviceB" ref="serviceB"/>
</bean>

<bean id="serviceB" class="com.ServiceB">
<property name="serviceA" ref="serviceAProxy"/>
</bean>

<bean id="serviceAProxy" class="com.LazyProxyFactoryBean">
<property name="serviceA" value="serviceA"/>
</bean>

Finally, here is the source code:


import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
import org.springframework.beans.factory.FactoryBean;
import org.springframework.beans.factory.FactoryBeanNotInitializedException;

public class LazyProxyFactoryBean implements FactoryBean, BeanFactoryAware {

private String beanName;
private BeanFactory beanFactory;
private Object proxyObject;
private Object realObject;

public LazyProxyFactoryBean() {
}

public Object getRealObject() throws Exception {
 if (this.realObject == null)
  this.realObject = this.beanFactory.getBean(this.beanName);

 return this.realObject;
}

public Object getObject() throws Exception {
 Class[] ifcs = getProxyInterfaces();
 if (ifcs == null) {
  throw new FactoryBeanNotInitializedException(
    getClass().getName() + " does not support circular references");
 }
 if (this.proxyObject == null) {
  this.proxyObject = Proxy.newProxyInstance(getClass().getClassLoader(), ifcs,
   new InvocationHandler() {
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
     try {
      return method.invoke(getRealObject(), args);
     }
     catch (InvocationTargetException ex) {
      throw ex.getTargetException();
     }
    }
   });
 }
 return this.proxyObject;
}

public Class getObjectType() {
 return beanFactory.getType(beanName);
}

public boolean isSingleton() {
 return false;
}

public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
 this.beanFactory = beanFactory;
}

protected Class[] getProxyInterfaces() {
 Class type = getObjectType();

 if (type != null && type.isInterface()) {
  return new Class[] {type};
 } else if (type != null) {
  return type.getInterfaces();
 } else {
  return null;
 }
}

public void setBeanName(String beanName) {
 this.beanName = beanName;
}
}

Notes from NetObjectives Lean Webinar

2007-11-27T11:04:00.000-08:00

These are notes from a NetObjectives Webinar on "Using Lean Thinking to Align People, Process and Practices".

This was a really succinct presentation that still covered a lot of ground. If you register it is still available for free viewing!

Lean Software Development:

Focuses on the ability to add value quickly now, while improving the ability to add value quickly in the future.

Edwards Deming:

Plan-Do-Check-Act (PDSA)
System of Profound Knowledge

Gary Hamel. "Management Innovation" in Harvard Business Review. Feb 2006

Only after American carmakers had exhausted every other explanation for Toyota's success - an undervalued yen, a docile workforce, Japanese culture, superior automation - were they finally able to admit that Toyota's real advantage was its ability to harness the intellect of 'ordinary' employees.

Lean - A New Paradigm

Engaged, thinking people

Referenced "Software by Numbers" (better graphics...)

Just In: REST can't handle state!!

2007-11-20T07:47:00.000-08:00

Or, maybe Jean-Jacques Dubray, Ph.D. doesn't understand hypermedia. :(

In his post on the states and transitions of a resource he claims that REST has no way to let a client know what state transitions are available for a given resource....

Um, what is hypermedia?

Distributed hypermedia provides a uniform means of accessing services through the embedding of action controls within the presentation of information retrieved from remote sites.

This quote is just the introduction to hypermedia and REST, but we already have an answer.

Action controls are embedded. Action controls are embedded.

Embedding the action controls means

The client doesn't need to have generated (and hard-coded) client stubs.
The server can change it's rules and expand available states as needed.
The client does need to process a generically extensible content type.

That last point isn't free or trivial, but it enable the first two.

Perhaps more directly on point is this quote from 5.3.3 Data View:

The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations.

Jean-Jacques' answer to how to share types, constraints, correct states, and transitions is not suprisingly: a schema and a business interface. Let's take those four goals one at a time:

Types: definitely covered by IDL (until the systems changes then you need to tell everyone to re-compile...)
Constraints: Not even covered a little by todays SOA technologies. Until there is an OCL or Catalyis (or Z or ...) model that get's compiled with WSDL the best a schema and business interface will have for constraints is a few lines of prose... (in )
States: WSDL is not much help, maybe you can infer the states from the operation names? SSDL I think actually does cover this...
Transitions: Same as states; how do we deduce which operations are transitions?

I really can understand the challenge and barrier to hypermedia state control with generic clients. Machine processing and interoperability in this context is unfamiliar: an "engine ... choosing from among the alternate state transitions" is very declarative and make a historically imperative programmer (me!) feels out of control.

Static class diagrams (WSDL) and code-generation are so much more in my control and experience. If only they worked for distributed systems without so many negatives...

The complete ignorance of hypermedia and FUD in the blog posting compelled me to respond and put my $.02 in.

Glassbox 2.0 RC1 is available!

2007-11-19T08:41:00.000-08:00

The 2.0 release candidate for Glassbox Troubleshooter has been released!

Glassbox is an open source Java monitor and troubleshooting application:

Easy to deploy to many app servers (deploy the war, click "Install", restart server)
Lightweight monitoring: only instruments key layers for efficiency
Extensible monitors (in XML or code) to domain-specific operations for better reporting

For more information I would recommend browsing the slides I presented at the Dallas JUG, or watching Ron Bodkin Google Tech Talk on Glassbox.

How am I related to this? I'm a committer for the project and have been most responsible for the automated installation support.

Presenting at New England Software Symposium

2007-09-13T15:43:00.000-07:00

I'll be in Boston this weekend presenting at the NFJS New England Software Symposium

I'm presenting on

Glassbox
Adding Behavior to Java Annotations
REST: The basics, and not so basic

Glassbox Presentation at Dallas JUG (yesterday)

2007-09-13T15:37:00.000-07:00

I gave a presentation on Glassbox yesterday at the Dallas Java users group (JavaMUG)

Here's a link directly to the presentation entry: Dallas JUG Glassbox presentation

At some point a PDF of the slides will be posted there. These slides are a reconsolidated and personalized version of what Ron Bodkin gave in the Google Video Glassbox presentation.

Glassbox is an Open-Source Automated Java Troubleshooter and Monitor. I'll post a link to the slides when it's available.

Train-Wreck Management

2007-08-12T14:49:00.000-07:00

Wow, this is a well organized essay by Mary Poppendieck.

Train-Wreck Management

The essay explains a bit about how a train accident in 1841 leads to the Prussian army becoming a model for today's organization chart!

Here's a quote that might make you look around your environment and feel an eary sense of historical dread...

Problems are caused by people who don't do their job well, so finding someone to blame is the first step to correcting problems.

I recommend anything on the website, and the books they've authored as well.

What I'm Reading

2007-08-10T11:46:00.001-07:00

I try not to post my own blog entries that just point to other blog entries - unless I have something to say that adds to the original.

On my blog page I have a readling list widget, but here is a link in case anyone is interested and hadn't noticed it before:

What I'm Reading

SOA Integration: RPC and Constraints

2007-08-03T13:10:00.000-07:00

DevHawk responded to my hard work post. Most important responses first.

Beer.

Let's have a beer together someday and you can make up your own mind! I try to have formed my own opinion on some topic, but don't take my view so imortantly that other people are wrong. The back-and-forth of ideas during a technical discussion is a fun way to spend a few hours.

DevHawk said:

I might be going out on a limb here, I'll bet the core of John's problem with SOA is how toolkits like WCF all but force you to build RPC style services that can easily be modeled as method calls. That's certainly one of my problems with SOA.

You're right, that is something that causes me grief. When I see a WSDL with endless request/response operations I first think:

That's going to cause some scalability/extensibility/versioning problems.
It would be easier to build this design in CORBA[1]

Also, your quoting from Tim Ewald was spot on. 10 years of SOAP and most systems just are just strongly coupled RPC.

Also, I agree that all the tools (and examples and sample code and ...) nearly universally pushes a view of Web Services that is really just RPC.

[Note: I just switched from SOA to SOAP to WS. I'm trying to formulate another post that will articulate what I think distinguishes those from each other. Right now I'm just rambling...]

There is one other thing about SOA that drives me bonkers. I'm hooked on architecture by constraint - limit the system in certain key areas to promote certain use and benefits. The four tenets of SOA don't do it to me at all.

Tenet 1: Boundaries are Explicit
(Sure, but isn't everything? Ok, so SQL based integration strategies don't fall into this category. How do I build a good boundary? What will version better? What has a lower barrier to mashup/integration?)

Tenet 2: Services are Autonomous
(Right. This is a great goal, but provides no guidance or boundaries to achieve it.)

Tenet 3: Services share schema and contract, not class
(So do all of my OO programs with interface and classes. What is different from OO design that makes SOA something else?)

Tenet 4: Service compatibility is based upon policy
(This is a good start: the types and scope of policy can shape an architecture. The policies are the constraints in a system. There not really defined though, just a statement that they should be there.)

Ah, I feel better getting that out.

I asked "Where are the SOA Mashups?" and DevHawk responded:

That's easy! They're inside the firewall where you can't see them! ;)

I'm so glad I procrastinated writing this because now I can just refer to this InfoQ article. Gregor Hohpe's comment is pretty much my definition of mashup.
The project you describe is an integration, but multi-schema, star-integration with a huge effort doesn't fit my definition of mashup.

[1] Yes, I'm serious! I used OmniORB with Python to build systems for about 2 years. I think CORBA with C++ might be more work than most WSDL based systems, but this was a very efficient development environment for strongly typed interfaces.

REST, Serendipity, and Hard Work

2007-08-01T18:48:00.000-07:00

DevHawk found my comment on the "SOA in the Real World" book. DevHawk writes:

Yeah, I'd rather not have to think about integration before hand either. On the other hand, I want integration that actually works. It sounds like John H. is suggesting here that REST somehow eliminates the need to consider integration up front. It doesn't.

I didn't mean to imply that building RESTful system would lead to magical integration without any hard work. I can see how that came across in my post, and I guess I got the reaction I asked for ;)

Let me try again...

I want to build systems using tools, techniques, designs, and architectures that maximize my investment in effort and work to produce value. If I put one unit of effort into building something, and I get more (or many more) than one unit of value for my effort, then I'm working in a high-leverage environment.

REST uses constraints to encourage integration. If I pay the cost of building a RESTful system (uniform interface, single naming system, resource-based design, representation transfer, ...) then any other system can leverage my system - for at least some minimum degree of use. That is serendipity. This is the fundamental reason that mashups on the web can exist.

Where are the SOA mashups?

I think related to that question, DevHawk further says:

...enterprises aren't interested in unexpected or serendipitous reuse. They want their reuse to be systematic and predictable.

I think we disagree here. Enterprises think they want systematic and predictable systems, but I suspect this is the equivalent of developers wishing distributed object systems worked despite latency and partial failures. I'm not suggesting enterprise systems should set "not predictable" as a goal, but I do think that trying to make things too predictable often leads to fragile systems.

Disclaimer: I've only read the first chapter of the book.

Here are some more quotes.

This one leads into the first chapter:

“SOAs are like snowflakes – no two are alike.”
- David Linthicum
Consultant

I'm assuming it's included not as a supporting opinion, but the first chapter doesn't do much to disprove it! Obviously if this is true then every bit of integration will have to be fought for, bit by little tiny bit. When everything is different there are no high-leverage environments for integration.

This next quote is why I don't feel (at least the first chapter) does much to discount the previous quote:

For the purposes of this book, we will define SOA as:
A loosely-coupled architecture designed to meet the business needs of the organization.

That loosely-coupled looks good. Loosely-coupled systems should be easier to integrate (as opposed to highly-coupled systems anyway).

How does an SOA become loosely-coupled? The four tenets of services or the summarized SOA process (expose, compose, consume) listed in the first chapter don't tell me anything yet.

Building systems is hard, building RESTful systems is also hard. The question of serendipity is this:

If I build an application with constraint A instead of constrain B, will I get more integration and value elsewhere the total system?

The constraints that define REST, and inspire the Web, have a significant track record for enabling integration. Are they the only constraints that can lead to value? No, absolutely not.

Can some of the constraints of REST be applied to SOA? Absolutely. I think an asynchronous, message-passing architecture with a uniform interface would be astoundingly interesting! I'm not the only one: see MEST, AMPQ, and Erlang.

SlideShare slides on Web App Scalability

2007-07-26T14:21:00.000-07:00

These look very interesting, enjoy: Web App Scalability Slides.

MySQL, Digg, Twitter, Vox, LiveJournal, ...

Integration Forethought over Afterthought?

2007-07-25T18:49:00.000-07:00

DevHawk linked to a post by John Evdemon announcing an e-book from Microsoft on SOA.

From the SOA in the Real World book page:

SOA is an architectural approach to creating systems built from autonomous services. With SOA, integration becomes forethought rather than afterthought.This book introduces a set of architectural capabilities, and explores them in subsequent chapters.

Now, I haven't read the book, so take this with appropriate disclaimers of ignorance.

I, for one, would rather build on an architecture that promotes integration as an afterthought, so I don't have to think about it before hand!!!

This post to rest-discuss by Nick Gall quotes some important thinkers. Here is the relevant section:

Unexpected reuse is the value of the web
Tim Berners-Lee
Two of the goals of REST: independent evolvability and design-for-serendipity
Roy T. Fielding
Engineer for serendipity
Roy T. Fielding

Writings on Scalability Topics

2007-07-10T11:49:00.000-07:00

I suggest reading these blogs.

Jeff Darcy (Canned Platypus) has an great blog, and also this article on High Performance Server Architecture. The article talks about the performance and scalability implications of

Data copies
Context switches
Memory allocation
Lock contention

Dan Creswell (author of Blitz JavaSpaces) has collected a Distributed Systems Reading List. The list include references to key papers from Google, MySpace, eBay, Amazon, and also some distributed theory papers.