Monday, August 20, 2007

The Road Not Taken

I'm sad that Kenn Hussey has left IBM.


I'm also sad that Wassim Melhem is leaving too.


Both will be working at Embarcadero. My sadness is somewhat tempered by fact that they will be working on technologies that involve EMF, so I expect that I will continue to work with them both.

All this makes me introspective and brings to mind one of my favorite poem's by Robert Frost titled "The Road Not Taken," which of course calls for a gratuitous photo I took on Saturday.


Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth.

Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same.

And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I--
I took the one less traveled by,
And that has made all the difference.

Thursday, July 26, 2007

Looking for Sexy Graphics?

Now that I have your undivided attention, let me further shock you with a graphic scene of the activities that are taking place in my own backyard!


On a related note, many of us building sexy user interfaces are often on the lookout for cool icons and of course we drool when we see all the lovely graphics that are in Eclipse. Bugzilla 170720 discusses the desire for there to be a central place to beg, borrow, and steal such graphics as well as a place to ask for help creating new icons that will fit cohesively within Eclipse's overall look and feel. Interested parties are invited to get involved in fleshing out a proposal for getting this initiative off the ground using the wiki at http://wiki.eclipse.org/Eclipse_UI_Outlet.

Saturday, July 21, 2007

PDE Does the Community Garden

We had an unexpected royal visit from the King of PDE in the community garden today. Wassim's been all over the world but has never looked finer than he does here. Could it be the stunning surroundings?

He's taken a sudden interest in modeling these days. I wonder if it had something to do with my inspiring blog? I'd like to thing so. In any case, I gave him a copy of the old EMF book before he embarked on his journey home...

Saturday, July 14, 2007

A Community is a Garden

To understand how a community is a garden, we need to relate their models in a way that demonstrates their similarity. But how is it that two seemingly incomparable things can nevertheless be seen as manifestations of an underlying unity? By modeling them of course. Modeling is all about representing the essence of something. To model something you must capture the important things about it in a logical structured way. Without such structure there is only chaos, with perhaps unrealized potential. So we create mental models of a community and a garden to draw analogies between their structures. I'll talk more about those models themselves later, after the topic at hand.

How is it that a community is a garden? And I'm not just saying that a community is like a garden, I'm saying it is one. They're each organic processes involving a balance of individual forces that are self perpetuating and hence self serving, against the unstoppable forces of the all encompassing ecosystem. In each there is the aspect of the whole being greater than the sum of its parts, i.e., there is a surprising new model that one would not have expected given just the parts on their own. And there in lies the true beauty of each.


Although beauty is in the eye of the beholder, diversity is a key component of the beauty of each. Its the interaction and interplay of the participants that provides the richness.


Just as an acre of grass, while an improvement over an acre of concrete, isn't a very beautiful garden, a community without diversity is similarly impoverished. Each needs nurturing and tending while at the same time they have a life of their own that can be influenced, but not necessarily controlled.

In each, weeds often spout and must be rooted out if they are not to undermine the landscape. But what is a weed? A weed in the garden is technically just a plant in the wrong place, i.e., it's not just an ugly plant, those are easy to spot, it's more subjective about whether that plant is serving its intended role. For example, I like grass in my lawn, but not in my beds. Similarly weeds in a community are hard to define, but we usually recognize them when we see them and we should root them out. Though we might want to leave just a few. After all, Monarch butterflies need milkweed and I like Monarchs a lot. This pretty Mystic Merlin was added to my weed list last year after if turned out to be all too good at popping up everywhere. It's back!


I love my garden and I'm very fond of the Eclipse community. I tend them both to see if I can make them even more cool where lots of other cool things can happen, things that have nothing directly to do with me. When I share my garden with others, its value grows and there in so do I.


We are all gardeners of the planet earth and we should remember that this ecosystem is greater than us and will continue to be here even long after we're gone. We should also remember this in our communities: we grow value by contributing and we can collectively produce a great deal of value by each contributing just a little.

So we've compared out mental models of gardens and communities to see, from the vantage point of our lofty soapbox, that indeed, they are manifestations of an underlying unity. It's clear that we use models for everything, whether or not we're conscious of that fact. It's how we think. It's how we produce the answer when we asked, what's the model of model? Well, a meta model of course, we declare triumphantly, proud of our ability to spout technobable on demand, in a service oriented, fully Web 2.0 enabled, standards compliant way. (Hey, we think to ourselves, just try to contradict me if you can pin any of that down to some concrete model.) And when asked, the model of a meta model is? Err, a meta meta model?

So why doesn't all this just turn into never ending meta nonsense? Because a meta model is a model and hence can even be its own meta model. Ecore, a model that describes models including itself, is a particularly relevant such unity point because an interesting aspect of models of models is that they are, in important ways, all very much alike. Just as a garden and a community are completely unrelated things that are analogous, so to Ecore, XML Schema, Java interfaces, and UML2 class diagrams are analogous self describing meta models, where Ecore is arguably the simplest. And the mapping between them is of significant technical value, not just of philosophical interest. EMF delves deeply into that mapping and derives most of its value from that. EMF is like my garden and I am happy when others share my garden and my community, because I feel valued when others derive value from the things I do. This ability to convert self serving behavior into a positive contribution is what I believe to be a principle that helps drives open source communities.

Ruby likes my garden too, even when it's wet. She actually thinks it's her garden so I humor her. Thank goodness it rained!


Amber, on the other hand, prefers to keep up her appearance.


Neither of them seem to give EMF much thought, though they do turn their heads a funny angle when I explain it to them. Not only do they like the looks of the garden, it apparently tastes great too!


I'll just take their word on that one. :-P

Take away just one lesson: nurture your community as if it were a beautiful garden and you were the head gardener; encourage others to do the same. Your pleasure and work will never end...

Saturday, June 23, 2007

Modeling Generics With XML Schema

Are you feeling curious today? I'll bet you are!



With the introduction of generics to Ecore itself we needed to think about keeping our round trip stories complete so there was a little bit of last minute scrambling to complete the support to make Ecore -> XML Schema -> Ecore and Ecore -> Java -> Ecore both continue to be round trips for all the new constructs we've added.

This schema shows that it's now possible to define your complex types as normal, and to specify their type arguments as well, kind of like having your cake and eating it too:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:tree="http:/www.example.org/tree"
ecore:nsPrefix="tree"
ecore:package="org.example.tree"
targetNamespace="http:/www.example.org/tree">
<xsd:element name="Node" type="tree:Node"/>
<xsd:complexType name="Node">
<xsd:annotation>
<xsd:appinfo
ecore:key="typeParameters"
source="http://www.eclipse.org/emf/2002/Ecore">
<typeParameter name="T"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element
ecore:keys="label"
ecore:opposite="parent"
ecore:type="tree:Node{T}"
maxOccurs="unbounded"
minOccurs="0"
name="children"
type="tree:Node"/>
</xsd:sequence>
<xsd:attribute
ecore:reference="T"
name="data"
type="xsd:anyURI"/>
<xsd:attribute
name="label"
type="xsd:string"/>
<xsd:attribute
ecore:opposite="children"
ecore:reference="tree:Node{T}"
name="parent"
type="xsd:anyURI"/>
</xsd:complexType>
</xsd:schema>

Notice that we use {} as synonyms for <>, since the later requires the use of entities in the XML representation, which tends to make the results quite unreadable. By hey, is XML actually designed to be human readable, or does it favor the machine? Given that a < within quotes could be handled unescaped by a machine without much challenge and yet must be escape to make it even easier for the machine, I'd argue that XML is sadly twisted in favor of the machine.

Converting this XML Schema to Ecore produces this model, which records as EAnnotations just enough information about the schema so that instances can be serialized to conform to it:



Generating the Java for this Ecore model produces the following, which records as @model annotations just enough information to be able to recover the original Ecore model

package org.example.tree;

import org.eclipse.emf.common.util.EList;
import org.eclipse.emf.ecore.EObject;

/**
* @model extendedMetaData="name='Node' kind='elementOnly'"
*/
public interface Node<T> extends EObject
{
/**
* @model opposite="parent" containment="true" keys="label"
* extendedMetaData="kind='element' name='children'"
*/
EList<Node<T>> getChildren();

/**
* @model kind="reference"
* extendedMetaData="kind='attribute' name='data'"
*/
T getData();
void setData(T value);

/**
* @model dataType="org.eclipse.emf.ecore.xml.type.String"
* extendedMetaData="kind='attribute' name='label'"
*/
String getLabel();
void setLabel(String value);

/**
* @model opposite="children" transient="false"
* extendedMetaData="kind='attribute' name='parent'"
*/
Node<T> getParent();
void setParent(Node<T> value);
}


Given the above Java, we can reproduce the originating Ecore and from that we can export the original schema. So in this case, even XML Schema -> Ecore -> Java -> Ecore -> XML Schema is a round trip. The value of this lies in the fact that any of these different forms of the same model can be your starting point and any of the others can be produced from it. Ecore is like the hub in a hub-and-spoke transportation system; every time another two-way spoke is added to the hub, everyone benefits. The UML project provides Ecore importers and exporters to support its own spoke and so the network grows...

It's clear that Ecore, XML Schema, UML, and Java are very different things, but the really useful insight is to see their similarities and then to use those similarities to build tools and runtimes that capitalize on them...

Monday, June 11, 2007

Stop and Smell the Flowers

When the garden is this lovely:


It's time to stop and smell the flowers:


Often it seems there isn't nearly enough time for the important things in life.

Saturday, June 2, 2007

Sneaky Behavior?

This year we started feeding the foxes that regularly visit our back yard, hoping they'll be so well fed, they won't be tempted to eat our dogs. It's very hard to get a picture of these sneaky little guys in action, so we bought a motion triggered camera. The picture quality isn't great, but look who we caught red pawed at the trough:


It turns out there are actually two of these little guys!


And a big one too.


We think the little ones are the babies from last year and are hoping to see new babies from this year out and about soon.

Speaking of apparent sneaky behavior. When the JDJ polls for best Java component closed the other day, I was rather pleased to see that EJB3 was at 583, JSuite at 593, and EMF at 623. Imagine my surprise when the next day the standing was quite different. Despite the polls being closed, JSuite had jumped to 746. That's a surge of 153 votes all in one day. That's quite the voter turnout, especially after the polls were closed! If I'd had my little camera set up at the ballot box, we'd get some really interesting pictures. I'm hopeful that the JDJ auditing process will take note of such irregularities..