RIA Religion

Also via Stefan Tilkov on RIA Religion:

I would have to say that I am a into Pragmatic Neo-Desktopism.

It is new age and makes me feel like a better person. I yell at my cat for pawing incessantly at the door of his litter box at 4AM much less ever since I adopted this religion.

As I explore this new religion I have noted that all of my REST blog friends have a different view. This makes me nervous.

Anyhoo, I have said this before, but I like evolution and revolution. There is nothing like competition to push things forward. I think the following:

• "RIA" is a stupid acronym/name. It is a great example of why I refuse to play the acronym game in naming projects. Give me a proper name and a cool obscure code name any day.
• RIAs will meld back into the browser at some point because the browser will respond to the new fangled RIA bits (sorry Ajax is a hack is a hack is a hack)

And when this is done, we will rince and repeat and everyone will get excited and mad all over again, but along the way things will get a little cooler and a little better.

Hallelujah great Neo-Desktop-deity!!!

REST dirty hands

Via Stefan Tilkov who quotes Sanjiva Weerawarana:

IMO the real underlying problem is that as long as programmers expect to write a class and flip a switch to get a service or one or more RESTful resources then we have nothing really but RPC masquerading as something else. Both resource and service advocates would be well-off in trying to move the developer community to get past the “class is all I need” stage. If REST is successful in getting developers to get their hands dirty more power to it.

I say this all the time. I wish more people would listen to me!

People get caught up in automation and false simplicity. And then they are trapped, but it is too late. And then they go off searching for the next "simple" thing that will damn them. Odd really.

Nice REST post

Joe Gregorio: RESTify DayTrader.

Why build a RESTful web service for DayTrader? Because I frequently hear that REST can't be applied to complex situations. I also want to use the example as motivation for talking about some of the idioms that are available to handle more extensive requirements.

Reunion

I was in Indianapolis, IN and and Loveland, OH last week for work.

This happily coincided with my reunion at the University of Dayton.

It is nice to take a step back from your life once in a while and go back in time. Life goes by so fast.

I can't say enough about the education I received there. And I met some lifelong friends. I was very impressed with all the improvements that they have made there since I have been gone.

I managed to stay out until 4AM Friday and 3AM Saturday. And I consumed some Milwakee's Best (aka "The Beast"). It was nice to see just how far my beer taste has come :)

Anyway, after a lot of driving yesterday and a long flight home it is great to be back in Portland with my beautiful wife & daughter.

WADL - Or Maybe Not

I have changed my mind on thinking that WADL Gateway Drug.

Dare Obasanjo has a great post on it. It pushed me over the edge.

If it was the only way to convince someone to not go the WS-* route, I'd go for it. But too much madness can result from it and it is just much simpler to avoid this for now anyway.

Here was the clincher for me from Dare's post:

Another word that is often abused in the SOAP/WS-* world is contract. When I think of a contract, I think of some lengthy document drafted by a lawyer that spells out in excruciating detail how two parties interact and what their responsibilities are. When a SOAP/WS-* developer uses the word contract and WSDL interchangeably, this seems incorrect because a WSDL is simply the XML version of OMG IDL. And an IDL is simply a list of API signatures. It doesn't describe expected message exchange patterns, required authentication methods, message traffic limits, quality of service guarantees, or even pre and post conditions for the various method calls. You usually find this information in the documentation and/or in the actual business contract one signed with the Web service provider. A WADL document for the REST Web service will not change this fact.

The Myths of Innovation

I am reading The Myths of Innovation. I felt somewhat obligated because the name of our team is "Premium Innovation". I would hardly compare us to Xerox PARC, but we generally roll as Scott Berkun describes (although we have a long way to go).

If I feel frisky when I am done, I will do a proper review, but I like this quote from a section called "Ideas and Filters".

. . . Instead of binary switches – open vs. closed, creative vs. routine-- we want a sliding scale of openness that we can control. If you want new ideas, you have to slide toward openness, turning some filters off, exploring thoughts you'd ordinarily reject off-hand. Do this until some interesting ideas are found; then, gradually turn more filters on until you're left with a handful that are both good and practical for the problem at hand. Choosing which filters to apply when has much to do with successful innovation; it's not just having an open mind, it's also knowing when to postpone certain judgments, and then when to bring them back in. If a mind is always open, it never finishes anything; if a mind is never open, it never starts.

It reminds me a lot of Lean thinking. Specifically, set based design.

Why I have a blog

I haven't started using Twitter yet. But I saw this post from James Governor. It describes (at least in part) why I maintain this blog and why I read blogs.

James says: I can afford to drop a few percentage points of my own IQ because of the quality of insights the network brings me. It is like parallel processing. My chip can be lower power, fewer MHz, because this is a clustered, virtualised architecture. I am less intelligent but better connnected. Its a trade off I am more than willing to make.

Is REST Winning?

Stefan Tilkov brings a more rounded view than I have been bringing in simply declaring victory. Really rather silly of me.

The other shoe drops - And then there was light.

Well, Burton Group delivers the knockout punch IMHO.

What a difference a year makes.

Welcome Anne Thomas Manes. Anne is wicked smart - that is a fact.

May 09, 2006: I'm one of the folks responsible for mixing the Kool-Aid. I presented at the W3C Workshop on Web Services (representing Sun). I participated in numerous standardization efforts at W3C, OASIS, WS-I, uddi.org, and JCP. I have a vested interest in making sure that WS-* succeeds.

May 30, 2007: If you're ready for REST I suggest you jump on board right away and get ahead of the curve," she said. "You'll have to train your developers in REST principles. You'll probably want to adopt one of the new frameworks or help build one yourself to help your developers implement RESTful applications. You definitely need to provide guidance to your people. What you want to do is work to the point where REST becomes the default for all your distributed applications."

I certainly disagree with her time lines, but am glad she has seen the light on REST.

I'm very excited about the post WS-* world. It is settled - to my delight, much sooner than I predicted. This only reinforces my feeling that we are at a major strategic inflection point.

Wow.

What's next?

Via Mark Baker who really does deserve a trophy or some such.

Update Fixed date.

XML Code Gen & Service Description Langauge

Stefan Tilkov talks about Runtime Interface Dependency.

. . . while my application code may be tolerant to at least some changes, the generated infrastructure code isn’t

+1 for WS-DuckTyping.

I realize that my WADL Gateway Drug logic is therefore fairly twisted given my own experience with the over dependence/brittleness that results from code gen. My idealist side agrees that it isn't necessary. My "I wanna see this happen" side appeals to it because the current state of the WS-EnterpriseProgrammer thinks in a service description language way. I just want to throw them a bone. I'm not sure this is wise or what.

There are some good comments in Stefan's Does REST Need a Service Description Language? post.

My favorite:

peter: I’m very interested in how a “typical” REST development process looks like (if such a thing exists). Up till now I have to stick to WS-* at work. How would a cross project interaction work in the REST world? What does the service provider project team give to the service consumer project team? Just a set of URIs? How do they implement the REST service clients? Manually, using CommonsHTTPClient with an XML Mapping framework of choice? Do I stress the toolsupport too much?

stefan: "Do I stress the toolsupport too much?"

Yes, I think you do — after all, do you hand over a WSDL without any accompanying documentation when you use WS-*? Chances are you provide the other team with some documentation, either inline or separate, that they have to read before using your service. A great way to document your resources is to return HTML when someone does a GET …

CommonsHttpClient is a good choice. Whether or not you need an XML binding framework is orthogonal.

peter: Yes, you’re right. WSDL is not enough as documentation for the service consumers. Usually we provide the complete client api :) Which was not the intention from the beginning. But most colleagues ask for example code in their preferred language and not an interface description. Then we come to the question why we used WSDL in the first place? There is one thing were it really works. I use soapUI a lot for testing. Point it to your SOAP Service, append “?wsdl” and let it generate a sample request.

I think that Mark Baker sums it up concisely:

Cut the cord already! RPC is dead. You’re not in Kansas anymore.

Google GData

If widespread use of REST & Atom at Google don't convince you that perhaps that WS-* stuff doesn't have such a bright future, then perhaps enthusiastic nodding from a prominent MSFT blogger will.

Take a good hard look at GData. It is well documented and comes with clients for everything besides Erlang.

Via Tim Bray

LINA - now that is what I'm talkn' about!

With LINA, a single executable written and compiled for Linux can be run with native look and feel on Windows, Mac OS X, and UNIX operating systems.

I am encouraged by Adobe Apollo for the same reason that LINA looks promising:

Tools like this could give us cross platform desktop applications and bring Linux to the masses.

LINA of course is FOSS - yay on that.

If LINA goes anywhere, Adobe will open Apollo. For all I know, this is already the plan.

More please.

Via Planet Intertwingly, via Allison Randal (O'Reilly)

WADL Gateway Drug

Stefan Tilkov responds to Aristotle Pagaltzis who thinks REST doesn't need a service description language:

In principle, I agree; for pragmatic reasons, I believe efforts like WADL make sense, if only to have an answer to one of the most obvious questions for new REST converts :-)

+1 to that.

Take a gander at the spec. I tear up just looking at it. It is beautiful compared to WSDL - just beautiful.

I think that the risk with any service description language is that people take it too far and become overly dependent on it. Generating code from them tends to do this. But then again, code gen can be helpful. You just have to know when you have taken something too far and not be afraid to press the eject button to dumb it back down.

I think that REST client developers at the very least will want schema definitions of what to expect in request/response payloads. IMHO WADL does a good job of not taking things too far. As I said, compared to WSDL it is a thing of beauty. It is so simple when the only option is HTTP (i.e., compared to the absolute insanity of protocol agnosticism).

If you aren't going to use WADL, you are going to have to document the service in prose or some such. WADL at the very least seems to be a really concise way to document things.

Update Somebody should give Mark Baker a trophy or something. I still will take WADL any day over WSDL, but Mark is probably right. Still, I'll take baby steps if that is what it takes.

Update 07-JUN-2007 I have been convinced that a service definition language is not good idea right now.

Lift on Scala & the Functional JVM

Tim O'Reilly mentions Lift on Scala.

Pretty wild.

There really are a crap load of Java APIs out there. Like it or not, Java owns the enterprise today. Maybe adding functional foo on top of Java is a good compromise. One could then have the joy of functional programming and use said crap load of Java APIs.

Is the JVM the way forward? Or will something deep in its belly only allow this approach to go so far?

What kind of mind bending errors do you have to acclimate too etc.?

Via Zack Urlocker

Update: Good Article: First Steps to Scala One reason you might want to use Scala is that it allows you to increase your productivity compared to Java while leveraging JVM execution speed, your existing investments in Java code, knowledge, and the vast array of APIs available for the JVM. It has the conciseness of a dynamic language like Ruby or Python, but it is statically typed, like Java. Another reason is that Scala comes with an Erlang-like Actors library that greatly simplifies concurrent programming, but runs on the JVM.

Cyclocross Forest Park

I spent a couple hours today on my bike in Forest Park.

Pretty brutal climb for a cyclocross poser like me.

It was a great ride.

I love the sound of your tires on a dirt road digging in yet slidding a wee bit as you climb and turn. Wicked cool.

Large Application Architecture vs. Integration Architecture

One topic that I see a lot of people struggling with is the difference between large application architecture and integration architecture. I struggle with this too.

Much of the commentary out there is regarding what I consider integration architecture. Topics like REST, Atom, XMPP, the dreaded WS-*, MQ Series, ESBs, application grids, etc.

You don't read as much about large application architecture. I think this is true because so much of the world today is dominated by integration. Most often teams don't have the opportunity to build something from scratch. Instead they are building things like web front ends to 30 year old mainframes. Things tend to get very fuzzy. You typically end up with a big ball of mud architecture.

I think the risk here is that there is indeed a difference.

Much of my time the last few months has been spent looking at building a new very large application. A large application has many different moving parts. This is similar to integration, but subtly different.

A key concept for me has been defending the core of the large application. XML everywhere makes zero sense in the core of a large application. Yet we see this in evolution strategies because different platforms are coming together (e.g., web and mainframe). Hammering a database on every page turn is bad - you have to be careful to seperate transient/active state from steady state/long lived storage. Also a large application needs to scale and is by definition then distributed. It can be very confusing.

For me, things like JavaSpaces and application grids make a lot of sense for large application architecture because they don't bork a large application into an integration effort.

But at least some of these technologies are also useful in an integration effort.

I realize that I am just blathering here. I think the only way to make sense of this is to separate the two concepts as best you can. The integration architecture should be the interfaces you expose and events you generate from various large applications or sub-systems. The application architecture should be dedicated to defending the conceptual integrity of that application / sub-system & pushing the integration to the edges.

Fried Cheese Curds

Wow.

I spent the week in Wausau, WI for work.

We had fried cheese curds as an appetizer every night.

These must be awful for you.

But they are incredible.

Sconi is pretty great all around.

OR - Not

Data management professionals need to start treating their data models and database schemas as ongoing projects of real value to the organization, which need constant ongoing maintainence and evolution. They need to stop treating a legacy schema as some immutable holy text handed down by God. Database refactoring is possible and practical (hat tip to Scott Ambler).

Gavin King of Hibernate / JBoss Fame sums up why I avoid all OR tools including Hibernate. What if I want to use the full features of my database and write some real queries and not get "certified" in your OR tool? Sure databases should be refactored, but it sounds like he is nicely describing the trap of OR tools: bow to the OR tool - just make it easy, don't resist! And watch the insanity slowly begin . . .

Hibernate and their ilk impose all sorts of crap on you, get their hooks in you, and slow bleed you to death.

In experience hands, they are fine - great, got, been there, done that.

I just don't see what is so wrong with JDBC (Spring JdbcTemplate if you are feeling frisky).

He goes on:

Relational databases are an integration technology, not just a persistence technology. And integration is important. That's why we are stuck with them.

Sad, true in some places, but we certainly don't want this to be the case right?

People are spazing out the most the last year or two about iBatis - apparently less invasive. I'm sure it is. I looked at it a year ago and indeed it looked less evil. I'm just too jaded I guess ... and I just don't get what is so wrong with writing JDBC.

Via Buko Obele

Signs of Life @ Apache River

It is encouraging to see a spark on Apache River list.

I'd love to see a come back.

Tuple Spaces are addictive.

Strategic Inflection Point

More and more it feels like we are at a fairly sizable inflection point when it comes to application development and integration.

I remember reading Only the Paranoid Survive by Andy Grove when it came out in 1996.

Intel has the preface on their website. Here is a quote on what he calls "strategic inflection points":

Strategic inflection points can be caused by technological change but they are more than technological change. They can be caused by competitors but they are more than just competition. They are full-scale changes in the way business is conducted, so that simply adopting new technology or fighting the competition as you used to may be insufficient. They build up force so insidiously that you may have a hard time even putting a finger on what has changed, yet you know that something has. Let's not mince words: A strategic inflection point can be deadly when unattended to. Companies that begin a decline as a result of its changes rarely recover their previous greatness.

As someone who reads blogs and maintains this blog, I feel these more than I used to. These points come and go. There are small ones and big ones. I feel like we are at a major one right now. The biggest I have ever felt. Maybe it is just because I am passionate about some of the issues that are at a cross-roads right now - maybe it is just me. But I can't help but feel like it is more than that. Patrick Logan and I discussed it momentarily at work a few days ago. We didn't get into details, but he feels it too.

A couple topics that I am interested in that tell me things are changing. There will be many winners and many losers. If you are affected by these topics, I suggest you start paying attention, because your world is changing:

1. Open Source Software is a major threat to commercial proprietary vendors. These vendors are starting to lash out in strange ways. Will it only be MSFT that lashes out? Where will this go? Why now - what was the tipping point? This? The fact that OSS has come this far - that executives get it? That the partner pull-through proprietary platform is threatened (i.e., no apps no platform)?
2. WS-*, an enormous industry initiative is an utter failure. REST wins, wow.
3. People are drifting from MSFT Office in favor of the web and experiencing a whole new level of collaboration and knowledge management.
4. J2EE is spent - Spring has $10MM to spend.
5. Cambrian Explosion of Web UI Change (Flex, Silverlight, JavaFX) - where will it lead?
6. The google-ization of the data center.

I could go on, but don't want to lose you. These are the ones I personally feel the strongest

OSS Middleware License Sort

I spend a lot of time on next generation architecture. This includes technical analysis, POC work, pilot projects, and then taking the tech mainstream. I am most interested in architectures that are simple that will result in far fewer defects than what we have today (e.g., excessive mapping, translation, co-mingling various state etc.).

I have stated my license preferences before.

They remain the same. I am not opposed to commercial proprietary software if it brings tremendous value to the table and simply can't be done without a more flexible & innovation friendly licensing alternative.

But in terms of middleware, I have come to a recent conclusion. I sort based on license type. I no longer look at commercial proprietary middleware. I have had too much angst in the past due to it and the commercial oss middleware today is fantastic.

For next generation middleware, I see no reason to perpetuate the inferior commercial proprietary model.

All FOSS projects are not alike of course. You have to be very diligent in accessing the accessing the health of the community etc.

WS-LastYear

Wow.

I can't decide if this thread feels like yesterday or 10 years ago.

We'll have to see what the outcome is of the TeleBriefing, but wouldn't it be nice if the other shoe fell and we could just move on?

The shoes of course have been dropping left and right, but far too many people still haven't noticed and are uneducated with regards to the misery that awaits them.

It is going to take long enough for all the ancillary - it provides enough business value so suck it up and integrate with it WS-* COTS products to wash through the IT ecosystem once we all agree that it is WS-Over.

So can we WS-WrapItUp already?

Overheard in Portland

Extremely funny - even if you don't live here..

Many Flavors of Grid Computing

Good post: Nikita Ivanov: What is Grid Computing.

Mobile Code

It bends your brain a bit at first. And J2EE ClassLoader hell didn't help on the FUD front, but the future is not only about mobile data (ala SOA), but also mobile code.

GridGain does mobile code.

And it looks a wee bit more approachable than PreferredClassLoader.

MSFT Patent Links

Matt Asay: Some of the best thoughts on Microsoft's patent poll tax

Eben Moglen Video Goodness I love listening to him speak.

Jonathan Schwartz: That's not a genie any litigator I know can put back in a bottle.

I have to say, that Fortune magazine article was some pretty bad PR.

Viva FOSS! Viva Freedom! Viva Transparency! Viva free thinking clever people that do stuff!

$10MM for Spring

Funding.

Emerging from the Google OSS Grid Haze

Looks like GridGain is emerging from their semi-silence:

GridGain Systems announced today availability of the first public release of GridGain project, an enterprise open source grid computing platform for Java. This release culminates 18 months of development and presents a software product with unique set of grid computing features, open source LGPL licensing and clear focus on high-performance Java-based development.

"Almost two years ago we set out to develop a technology that would change the enterprise Java grid computing landscape in much the same way Spring and JBoss have changed the J2EE market through simplification and focusing on a developer. Today we are releasing our project that is based on proven professional open source model, business and community friendly LGPL licensing, and the host of unique grid computing features", said Nikita Ivanov, founder of GridGain project.

Tangosol (now owned by Oracle) and others gave us the Java "Data Grid". Perhaps GridGain can give us the "Compute Grid" part. This is what we struggled with in looking at data grid/caching technologies - you still needed the compute part somewhere. Tools like Tangosol excelled in bridging the gap between J2EE performance problems due to data latency issues. But that is only 1/2 of the problem in terms of application grids. You still need to be able to easily add compute nodes to be able to scale.

Without a compute grid, you need to rely on things like JMS or other bits of J2EE. This is of course fine in an evolution approach - just doesn't seem to fit right in a new large system (at least for me).

Could this be an application grid without the Jini/JavaSpaces baggage? Don't know - certainly borrows some Jini features (code mobility). They know how to document things and have a roadmap and bits so that is a start ;) Message to Apache River: see I'm not kidding, the clock is going tick, tick, tick - the future is coming.

This should be interesting to watch.

GridGain

GridGain smartly pays Google so they show up when you google "oss grid". Otherwise, they only show up on the second page and I wouldn't have seen it today.

I read about it for 30 minutes and didn't run away screaming. Looks like a pretty young product. I'm also a bit afraid of AOP, but I'm a simpleton. They also use Spring - see it is everywhere. But they are FOSS and run on JBoss so hey - maybe it isn't bad.

Anyways, thoughtful people that seem to know some stuff and know how to try to start a community by documenting things fairly well. They also seem to be disatisfied with highfalutin grids that talk big, but don't deliver. We can all relate to that.

Anybody know anything about it?

Spring is everywhere

First GigaSpaces and now Appistry.

Spring is nice and everything, but I don't quite get how/why it fits here. It particularly doesn't make a ton of sense to me with massively dynamic & distributed technologies like Jini/JavaSpaces and Grid. Class loaders anyone?

Perhaps it makes things more approachable. It certainly doesn't make things more open. I choose open over approachable.

Grid & the Web vs. JavaSpaces

Some of the grid computing concepts look awful similar to JavaSpaces. And the community appears to be thriving (as opposed to Jini/JavaSpaces which is not).

There are some OSS projects and a number of commercial vendors. Done properly, you can use many different languages and platforms (as opposed to just Java with JavaSpaces).

Perhaps it is better? Simpler or more complicated? Not as good, but good enough? What about associative memory? Grid + REST + XMPP + Atom? Something else? More locked in or less?

I do love the promise of the tuple space. I hope some day it makes it into the mainstream. I no longer think it will any time soon, sadly. There are forces out there that I do not understand that will continue to relegate it to the niche category of "high performance computing". Until there is a thriving community around it, few will embrace it. I hope this changes. I certainly will be watching.

5/13/2007 9:45 PST Updated some links.

Portland, Oregon == Weird

Thank goodness it is weird here.

Every time I leave I want to come home.

I was even in San Francisco last week and felt the same way. Hopefully Portland stays this way.

Nice

This just in from the nicest person I know (my mother):

Part of a prayer I read this morning:

............"that I will be well in my own soul and part of the world's healing this day." Amen

The Challenges of Latency

Nice article on latency by Dan Pritchett.

The web has created an interaction style that is very problematic for building asynchronous systems. The web has trained the world to expect request/response interactions, with very low latency between the request and response. These expectations have driven architectures that are request/response oriented that lead to synchronous interactions from the browser to the data. This pattern does not lend itself to high latency connections.

Exactly - I've lived with async systems for some time so my mind thinks this way naturally. I'm constantly amazed at how many programmers just don't get async. There has been progress in the last year or so, however. I'm a little shaken on this topic at the moment though. I am sick to tears of JMS and love the richer async patterns in JavaSpaces, but am faced with walking away from it as the lack of a thriving community has me rattled. What are other ways to accomplish JavaSpaces like styles without JavaSpaces? Hmmm?

I recently read an article where the recommendation was to delay horizontal data spreading until you reach vertical scaling limits. I can think of few pieces of worse advice for an architect. Splitting data is more complex than splitting applications.

This is where all the bodies are in busted distributed systems. It is so easy to make decisions for the short term that make your first (or next) release easier. The problem is these decisions are almost impossible to unwind.

I have much to learn in this area.

Determining whether the passive data center is truly ready to take traffic can only be done by sending traffic to it. This is difficult to do in an active/passive design without impacting customers. Active/active has an inherent self-proof of suitability for managing traffic.

Again, more effort in the short term because you have to actually make it work for real. I've seen many active/passive rigs where everyone knew that if there was a real DR incident that it wouldn't fail over properly. Active/Active really means that you can sleep at night ... it is the TDD equivalent for DR. Also everyone feels bad for the passive servers. I mean what did they do to deserve a life of just sitting there depreciating? I have also said that passive servers are either in purgatory or maybe that is what server heaven is - it is all pretty strange when you think about it.

Ahem Where are the Jini/JavaSpaces Bits?

Nice overview of JavaSpaces.

I likes it. I wants it. Really I do.

JavaSpaces is some of the best tech. I've had the opportunity to work with. Build a Generic Worker and tell me you disagree I dare you.

But, there is something wrong - I'm sure it is coming real soon now - that is what we keep hearing, but where are the bits? Where is the roadmap?

I said it a while ago. But the clock is going tick tick tick. It is May - it became a poddling in December/January. 5 months ... no bits, no roadmap?

One commercial proprietary vendor, a partially retired Pragmatic Dictator FOSS impl. and a very quiet maybe FOSS Apache project does not a thriving community make.

What gives? Does Sun want this to happen or do they want it to die? I just don't understand. I mean to offense - I'm new. But the current state of the community makes it very hard to want to invest in this technology - no matter how much potential it has.

I'm going to JavaOne a bit and am going to try to find out. I'll let you know how it goes.

Angry Pilgrim

Mark Pilgrim lit me and others up with some un-constructive criticism. I guess I do that occasionally so if I can dish it out I can surely take it :)

He raises some good points - concerns that I share.

We *reluctantly* looked into Flex a few months ago. We did this after trying numerous Ajax frameworks. We were not interested in a widget here or there that did some Ajax booya. We wanted to build a full blown RIA app for a very complicated system.

After suffering through severe pain in trying to get Ajax frameworks (choose any one you like) to work with Firefox, IE 5, 6, and 7 we threw our hands up.

We heard good things about Flex so we tried it.

We weighed the pros and cons of its openness (at the time it was just shared source equiv.) and decided to proceed further. Since then, they have opened up Flex - or stated the intent to under the MPL license. We were very happy to see this development.

Flash - is of course still proprietary. Mark is focused on this. He raises good points - concerns I share in a style try not to.

Adobe is showing a good direction towards opening things up further. I'm hopeful that some day Flash will be open.

In the meantime, our business has competition and we seek to beat it with the best systems we can build. We weigh the pros and cons, make our choices, and live with the consequences. Just like Google Finance and YouTube (properties owned by Mark's employer that both use Flash) do.

Patents - OSS

I'm no lawyer, but this US Supreme Court Ruling sounds good. Via Matt Asay.

MSFT and Adobe

Well, jeeze, this is going to get interesting, isn't it?

I'm looking forward to hearing more details on "Microsoft is expected to show a new friendliness to the open-source community by unveiling plans to release the source code to a part of its Silverlight technology at MIX 07 next week, according to sources familiar with the company's plans."

Will this be shared source or open source - like with non-MSFT committers and what not?

Update: So I read through a bunch of stuff and I still don't quite "get it". Multi-platform means Winders and OS X? Em, I thought MSFT sold Linux now? No Linux? But Flex runs on Winders, Linux, Solaris, and OS X? Also, didn't find any details on the OSS details - anyone see any?

Just Noting a Political Prediction

Momentary topic change from my enlightening tech commentary/blather. No need to get all bent out of shape on me. I'm neither a Demican nor Republicrat. I don't like either.

Saw this article today on Fred Thompson. I'd just like to note that I told my wife 8 years ago that I thought Fred Thompson would be U.S. President some day and she remembers. So before he declares he is running, I reiterate my prediction - if only so that I can say, "yeah I called that 10 years ago" if he wins. I don't like any of the candidates so far and find it appalling that the election is already in full swing. Not sure if I'll like Fred Thompson or vote for him, but sounds like he'll be a force to be reckoned with. I mean come on - how is Hillery going to compete with: "He plays President Ulysses S Grant in the film, Bury My Heart at Wounded Knee, which opens next month."

I think it is safe to say that it will be good to have a change. But I say that after every election and then nothing changes - just different people blathering.

Quote that I agree with from the article:

"The president Americans want is, in fact, the guy they see on Law and Order: wise, thoughtful, deliberative, confident without the cockiness of George W Bush, urbane yet country. Fred Thompson communicates all those virtues."

I don't care what your politics are - I just think this is the truth.

And I don't care what anybody says, I liked Reagan.

Adobe OSS Flex

Adobe taking Flex OSS the other day made my day.

Here is a good video interview with Adobe product management.

The future is coming!!

It should be very interesting to see the impacts of this.

We started working with Flex a few months ago after trying every viable Ajax RIA framework. We were very reluctant to do this at first as Flex was propietary. There were just too many "pros" to using Flex over any Ajax framework, however. We estimated the cost of development and maintenance of Flex vs. Ajax to be massive. So we went with it anyway.

But now that it is OSS, dang!

Update Changed "We estimated the cost of development and maintenance of Flex & Ajax to be massive." should read: "We estimated the cost of development and maintenance of Flex vs. Ajax to be massive."

Browser with a run-time

Update Mark Pilgrim readers let me defend myself :)!!!

I'm with Patrick on this one.

Mark's tried and true "just leverage the web" argument doesn't seem to apply. Mark is one of my favorite bloggers and I typically agree with him.

Then again, the Adobe person's "“One word; branding”" doesn't really make any sense to me.

Flex and Apollo are compelling because they are essentially a browser with a real run-time in them. Ajax is neat and a great way to incrementally add booya to your in-production-today-built-on-Struts web app (or whatever your equiv is). But Ajax isn't a run-time and most of us don't really want to write our app N times for N different browsers/versions.

But happilly, "in the future", we have greener pastures to look forward to. We can like "do stuff" and not like "bleed to death" doing it.

And guess what? It will run on Winders, Linux, and OS X. And you will write it one time. And test it one time.

Like what Java was supposed to do but wasn't on the desktop and you only get 10 years before people say, "times up, what's next?".

Lean book

I'm wrapping up Implementing Lean Software Development.

I highly recommend it.

The Poppendiecks rock.

It is pretty hard to argue with much of anything they say.

Here is a good video of Mary presenting to Google if you don't have time to read it - it will give you a taste of Lean SW Dev.

Funny Comment

Noticed a funny comment on this post:

Leus said...

To Johnny Prewitt:

John, every time you repeat the phrase "stable and engineering driven environment," God kills a kitten.

Please don't do it again.

10:05 AM

CSI Portland

Nice to see Stuart Cohen's new venture announced. Here is the Collaborative Software Initiative website.

For once, I knew about this and even the name! for 2 months and kept my promise and kept my mouth shut. Of course I have been so busy the past two weeks that I went completely dark and am just seeing it now.

Good luck Stuart! I'd love to see this take off. Can't help but think I played a role in inspiring it :)

Update 22-APR-2007 I wrote this when I was totally fried from a busy week and travel. Now that I read it with a rested mind, I'm even more excited.

Here are some excerpts from the press release:

Former Open Source Development Labs (OSDL) CEO Stuart Cohen today launched a new company that will solve shared enterprise IT problems by bringing together companies to develop software at half the cost of outsourcing. The company, Collaborative Software Initiative (CSI), is pioneering a market-changing process that applies open source methodologies to business communities facing similar IT challenges.

CSI is initially working with industry leaders HP, IBM and Novell to help vertical industries identify and scope projects where collaboration among industry peers can meet requirements quicker and with less expense.

Government and industry standards are driving much of today's software development, prompting IT managers to outsource fundamental projects that require too much time and money. CSI offers a better way, based on more than 10 years of proven methodologies in open source development. This approach, called Collaborative Software, is software developed or acquired by a variety of like-minded companies at a fraction of internal development or outsourcing costs. For applications that don't enable competitive advantage or are associated with non-value added activities such as compliance, Collaborative Software allows business managers to maintain individual control and direction over a project while accelerating compliance, reducing costs and consolidating project timelines.

"Free and open source software principles are carrying the software market forward and putting older, largely proprietary, ways of doing business to the test," said Eben Moglen, chair of the Software Freedom Law Center and pioneer in the FOSS movement. "By adapting these principles to collaborative computing among industries, the CSI is formalizing an important step in the FOSS evolution."

Looks like my 2007 predictions are trending well :)

Specifically, point #9: Community Source Software will slowly start to take off in industry verticals as more executives grok the possibilities and come to terms with the fact that they are already sharing industry vertical software with their competitors; they just don't have access or any control of the source code. Look for a success or two in 2007 which will set the stage for a pandemic by 2009.

Visualize a Ginormous Standard Free Simple World

Saw this on Bill de hOra.

Visualize legacy WS-*. And ginormous industry encompassing standardization efforts for that matter. Could this be it? Could it be the last gasp of this madness? CORBA, J2EE, WS-*, and onto a path of more simple sanity? One can dream.

I continue to be shocked that even today, 6-7 years into WS-* that people still think it is the next thing. I am befuddled by this.

I have been a consultant, software vendor, and IT dude (customer). I haven't been an analyst. I agree with Bill here:

What has happened with WS-* promotion, and what is happening with SOA is bad for the industry, bad for shareholder value. Customers will come to reject the vendor/analyst/consultant triumvirate if it comes to appear to be nothing more than a racket. In effect, that would be a rejection of the entire market. This helps no-one, least of all customers, dependent as they are on software and related services.

Update Patrick Logan and James Robertson say it better than I do. Especially - James. He captures what I loathe the most about the echo chamber and how it defines what is mainstream. It makes very well paid smart people stop thinking - stop innovating - stop looking for a better way. Instead they pick the safe route - whatever the echo chamber is saying - even though it has the highest chances of failure. I hope I never become this - if you aren't risking something you will never get anywhere. And you will be a part of what I think is the typical customer's biggest problem - the lack of the will to innovate and succeed.

Push vs. Pull Systems

Interesting post by Dan Creswell who links to John Hagel.

Update Also see this earlier post by Dan.

I liked this table in the paper.

Talks about Lean based pull systems in manufacturing applied to systems. H.o.t.

Push Programs	Pull Platforms
Demand can be anticipated	Demand is highly uncertain
Top down design	Emergent design
Centralized control	Decentralized initiative
Procedural	Modular
Tightly coupled	Loosely coupled
Resource centric	People centric
Participation restricted Few participants	Participation open Many diverse participants
Efficiency focus	Innovation focus
Limited number of major re-engineering efforts	Rapid incremental innovation
Zero sum rewards Extrinsic rewards dominate	Positive sum rewards Intrinsic rewards dominate

Our Crazy Fugger

Patrick is our resident Crazy Fugger.

I understand him a little more each episode.

I agree with Edward Povazan: A whole parallel computing universe that I, having been on a C/C++/Java path, would not have been exposed to.

I don't know Smalltalk, but have had several enlightening conversations on it with Patrick. If history had played out a little different, we might all be building with Smalltalk.

For me, exploring JavaSpaces has been a bit like what I hear Edward saying - there are whole other worlds out there in software. Some good bits / some bad bits to be sure, but some of the things that didn't catch on in the mainstream certainly should have. There were reasons to be sure - some of them self-inflicted, but the calculus of what technologies make it and which ones fail is far from meritocratic.

Update: Fixing capitalization of Smalltalk from SmallTalk after being vigorously scolded by Patrick :)

Rubber Match

This week is the rubber match between the Space Men and the Flex Men at work.

We've covered a lot of ground in this phase of the project. A lot of it was fighting learning curves and getting infrastructure stood up. We spent a lot of time using Lean set based decision making on what technology we wanted to use. This was good in that we are more confident in our decision, but bad in that it cost time. The good news is we wouldn't have picked the technology we ended up with if we had used a traditional "place your bets early" approach. So it worked. Yay.

It is inevitable yet annoying that the first rev. of any piece of software has to pay the first rev. tax of standing up infrastructure, figuring out methodology, forming/storming/norming/hopefully-performing, and learning rapidly in general.

The team makes its choices (as Sarge would say) and lives with the repercussions. We made a lot of good choices luckily, but we certainly made some bad ones. The bitch of it is you never really know which choices were good and which choices were bad unless they were very right or very wrong. You are always left wondering what if we did this - what if we did that?

And so it goes - here comes the rubber match between the Space Men and the Flex Men. I am using this phrase incorrectly, but I felt like using it anyhoo, so so what!?. It really is the integration week. When we take a lot of reasonably well tested Jini/JavaSpaces code (unit, integration, and FIT) and try to integrate it with Flex code.

For better or worse, we split our small team into two - one focusing on the backend JavaSpaces side and one focusing on the Flex UI side. This was mostly due to fighting learning curves, but was also due to working styles and geography. We wanted to try a lot of things and splitting the team at the time seemed to be a way to cover the most ground with technology and methodology. We'll never know if this was a good decision. But we made our choices.

A team where everyone is skilled in all areas of the system is obviously best. But you can't just wave a wand and make this happen. You have to get there iteration by iteration choice by choice.

Wish us luck this week - the rubber match is going to hurt! :)

FIT Wiki = H.O.T. - & JBoss Rules + JavaSpaces = Smiles

Patrick and I had a rather long pairing session today.

We beat our rules module into submission. Turns out that JBoss Rules and JavaSpaces are a pretty good match.

Towards the end of the day, we had the unit tests passing and the integration tests passing. Then it was time for the FIT tests. They busted us proper. Our co-worker Ed was pretty pumped about this. Getting busted when you think you are done by tests you wrote at the outset of a development effort is a great thing. For us, it is one less thing that we will find out when we plug in Flex to our Jini/JavaSpaces back-end. That rocks.

And our FIT tests are plugged straight into our wiki. It is h.o.t.

We also have put JBoss Rules to work with JavaSpaces. It works quite well because it is POJO based and the compiled rules can just be put into the space as Entries. If that isn't h.o.t. I don't know what is. We have a generic worker that takes Entries out of the space & reads the appropriate rules files. It just asserts the Entries directly into the rules engine (they are POJOs too - Entry is just a marker). No XML marshalling / mapping madness etc. Just objects - neat!

JBoss Rules is not as sophisticated as some commercial proprietary rules engines, but appears to be more than adequate for lots of things.

Yay.

Oracle buys Tangosol

Wow - that was fast.

This was discussed a while back on this TheServerSide thread.

I sure hope Oracle invests in the product and doesn't slow bleed it or margainalize it. Of course that never happens.

I stand by my comment from February (link above) on why commercial proprietary software is at the bottom of my preference list.

. . . Back to GigaSpaces and Tangosol. They both have compelling technology, but both are small vendors. Where will this technology go? Will someone buy it to kill it? Will they buy it to grow it? Will they remain independent? Who knows. If it were open, well it doesn't quite matter. I can happily pay them now and perhaps someone else later - or no one if I can support it myself.

Pair Programming

So I have been a long time doubter of pair programming.

I just spent 2 - 1/2 days pairing with this man.

I have to say - I really enjoyed it. Part of it is that I just love slinging code and I became a technical manager of sorts (in addition to remaining a technologist dude) 7 months ago. Pairing is a great way for me to get my code fix. Even after 7 months of not slinging heaps of code, certain corners of my brain started turning off. It was great to dig back in and light those corners back up. I even came up with a good idea to simplify something and received my "space man merit badge".

Our small team has been experimenting with pair programming for those that want to. It has been very successful.

I think that some of it is the fact that we are dealing with so much new (at least to us) technology. Pairing is (obviously to me now) a great way to spread knowledge, learn, etc.

I certainly don't think that 8 hours of pair programming every day is appropriate - at least for me or probably most people. But it is clearly a great thing to do *at least* a couple times per week or some such. I guess it depends on your role etc.

Anyways, I love it when a long standing belief / opinion of mine changes. It helps me know that I am pushing myself outside of my comfort zone and pushing myself. One thing is obvious (or should be) about the world we all live in now. Those that stop learning are toast. If you aren't learning new things (e.g., about your domain, techniques (e.g., agile, lean, xp, etc.), technology, negotiating/people skills, hospitals/manufacturing) you are going to hit a wall. It is amazing how comfortable you get with this concept once you sign up with life-time learning. I am constantly amazed at how many people don't view the world this way.

Bike Pics

Is this bike h.o.t. or what!?!? I just rode it home from the bike shop. It is wicked fast.

I deserve it I think. At least that is what I keep telling my lovely wife.

Walking to work every day is great - it probably has kept me from having a heart attack this past year!

But, I need something more and bombing around on this bike is it. I hate the gym and such and don't play hockey or anything any more. Maybe I should start playing tennis again too.

Yay.

Java 7 - See Patrick

See Patrick, there is hope for Java besides just JavaSpaces.

Via Buko Obele

New Cyclocross Bike

I finally have pulled the trigger on a new cyclocross bike.

I went to River City a few times this past week. On Saturday, I brought my friend/co-worker Ed came with me to help pick it out.

I ended up getting a Gunnar Cross Hairs.

My brother-in-law works for SRAM so I wisely got their bits on there. The River City dude said that the SRAM bits have been getting good reviews so I'm excited.

I also got some tricked Chris King hubs / wheels.

I'm pretty excited to pick it up this week - they are building it now.

Spring in Portland

Well, it has been Spring now in Portland for at least 2 weeks.

It really is shocking to me still - after living in the Midwest previously my entire life, how early Spring comes and how long Spring stays here. I was reminded of this by my mother today. She said the snow has almost melted in Grand Rapids, Michigan (where I grew up). I was like, "that's nice - we have had pink flower trees for 2 weeks!".

These pink trees are everywhere here - they just start going off. For me, when I see the pink trees, I know that I'm going to be ok. Because it is no joke, it does rain here - a lot. But compared to what!? It rarely gets below 40F here and there is no snow, sleet, etc. And the sun peeps through at least a bit most days.

I guess if you compare it to San Diego, the weather is not great. But I like seasons. The weather in the Pacific Northwest is my favorite.

I took the picture below in 2002 - my first "it is going to be ok because of the pink trees moment". The picture doesn't do it justice - these trees are everywhere and there are other flowers etc.

Hopefully Spring will come to you soon too.

It will be ok - I promise.

Deschutes Fly Fish Day

I finally got to go fishing today. I wish I could do it more. Portland is great - you can get to the Deschutes in a little over 2 hours. The trout are native (called Redside trout) and are great fighters. Nothing like seeing one of them nail your dry fly. I caught three.

I went solo so I didn't take any pictures of the trout. But I did take pictures of some deer on a cliff looking at the river at dawn, a hawk, and the Deschutes river canyon in general.

Below the pictures I included some stuff on the symbolism of deer that my mom sent me last summer when we saw another deer family. Makes me feel bad for liking venison.

Update 12-MAR-2007 My mom read this blog post and sent me stuff on symbolism of the hawk! Work has been crazy busy & stressful and recently a bit sad/disappointing so it's nice to see there are some good signs out there. I added it beneath the symbolism of the deer.

Deer Family (you probably have to click it to see them - it was cool - I need a telebooya lens)

Symbolism of the Deer Deer blend very well with their environment but are very sensitive to every sound or movement. Often twins, even triplets, are born in the spring. Does and bucks live in separate groups until the mating season. The white-tailed deer are moderately gregarious, and family members forage food together along with other family groups, giving the appearance of a large herd. People with Deer Medicine are often described as being swift and alert. They are intuitive, often appearing to have well developed, even extrasensory perceptions. Sometimes their thoughts seem to race ahead, and they appear not to be listening. Deer's medicine includes gentleness in word, thought and touch, ability to listen, grace and appreciation for the beauty of balance, understanding of what's necessary for survival, power of gratitude and giving, ability to sacrifice for the higher good, connection to the woodland spirits, alternative paths to a goal . The gentleness of Deer is the heart-space of the Great Spirit which embodies His love for us all. Deer teaches us to find the gentleness of spirit that heals all wounds, to stop pushing to get others to change and to love and accept them as they are. The only true balance to power is love and compassion.

The Deer. Hunting prey animal, sacrificial and sometimes mentioned as "first helper" in a few emergence stories, also family protection and of course speed.

Deer - Love, gentleness, kindness, gracefulness, sensitivity, purity of purpose, walking in the light, swift, nimble, meek, gentle, meditation, love, longevity, wealth.

Deer and Stags represent swiftness, gentleness, grace and balance. They teach us the ability to listen and to sacrifice for the greater good

Symbolism of the Hawk Air Animal Totems have a penchant for assisting us in matters of higher knowledge. Air being the most ethereal of elements, it's understandable that the creatures who inhabit it are able to lend the best understanding of its invisible ways. Closest to the heavens, air animals are our best allies as they herald our desires to the Great Spirit.

Air animal totems are also symbols of strength (both physical and mental) and sovereignty. Very important traits, particularly when we are experiencing new transitions or surroundings in our lives.

If air animal totems are catching your attention, you should feel very heartened by their presence. Allow their spirit to boost your confidence, and remind you that the ultimate power is within this present, unseen moment. Air animals are good omens, and their appearance is like a wink from God.

The hawk is the great messanger and observer of the sky.

Hawk - Nobility, recollection, cleansing, observer, clarity, discrimination, inspiration, intuition, victory, healing, visionary power, and guardianship.

The hawk is the great messenger and observer of the sky. Hawks are fearless birds who will even face off with poisonous snakes if necessary. Hawks' piercing shriek tears through the air. In its shrill cry lies an important message which represents illumination. Hawk teaches us to scope out the situation and focus on our talents, trying to draw them out. Hawk learns to see the big picture in order to understand the past, present, and future. Hawk asks us to be observant of surroundings so we won't get distracted from our path by others. It also reminds us not to get caught up in minor annoyances so we can maintain our inner balance.

Software License Categories & My Preferences

I wish all software was FOSS. But this is not the case. I deal with many flavors of software licensing. Here are the categories that I am aware of in the order of my preference (1-3 are interchangeable). Am I missing any?

1. Commercial Open Source

   Must meet requirements of the OSI OSS Definition. Just has a commercial entity behind it that offers support etc.

2. FOSS - Free Software

   Must meet requirements of the OSI OSS Definition. May have a commercial entity behind it, may not, key is that it is free or can be free

3. Community Source

   Examples include Sakai and Kuali. I am convinced/hopeful that this will be the next big thing for vertical industries as I predicted.

4. Developer Source

   This DOES NOT meet the OSI OSS Definition. But it sure beats the heck out of commercial proprietary. Examples of this model are Caucho, Some Jive Software products - including their new Clearspace (some of their products are FOSS), and Atlassian. Although I'd prefer FOSS, these are typically very innovative and open companies (e.g., publicly accessible enhancement requests/defects/forums) who take their customers very seriously. Typically customers of these companies are fanatical about using these products. I think that the fact that getting access to the source upon purchase sans escrow account is a big statement - it says that the company is proud of their code and has no problem with you seeing it and extending it as you wish.

5. Shared Source

   This is a MSFT thing - better than nothing I suppose. I want to be able to see the source.

6. Shareware

   If it's proprietary it might as well be free.

7. Commercial Proprietary + Escrow

   If it is proprietary, I might as well have the source in escrow so if you go out of business I am not completely screwed. I hope you included a build script and instructions . . .

8. Commercial Proprietary

   This is of course my least favorite. As Matt Asay says:

   Let us be clear. Whatever the merits of proprietary software, they are purely vendor-favoring. There is no customer reason to make software proprietary. None. There is no customer benefit that attaches to proprietary software. There is only a vendor's ability to temporarily monopolize a piece of software and thereby profit from it.

Cygwin, Rake, Flex, Bleh & Work Instructions

Cygwin makes Windows barely workable. If it wasn't for the insanity of the backslashes, spaces in directories, equality of upper and lower cases, etc. Just how many months of an average developer's life is spent on this type of minutia? Class paths, environment variables, blah blah blah. On *nix of course, it all just works.

I spent too many hours yesterday trying to beat Cygwin and Rake into submission. All because of the horror of backslashes etc.

Cygwin mostly works, but there are always corner cases. Well Flex seems to be one of them. I am by no means a Cygwin expert - perhaps I should learn more.

Anyways, here is a tip. Don't even try to feed the Flex compiler (mxmlc) path names like /cygdrive/c/flex_2_sdk_2 or path it any config file references using this style.

You must instead do things like:

export FLEX_HOME="C:/tools/flex_sdk_2"

Anyways, no big deal of course.

This type of panic is only typically an issue when you are dealing with a new tool. This is why I love the project "Work Instructions" wiki page. This is the step by step instructions for the new developer (or you when you get a new machine) that tells you exactly what to do to get productive quick. Even better - a team starter VmWare image or some such.

Cappuccino Milk Frother

Some day I am going to drop like 5-10K on an uber espresso machine.

As I have little spare coinage these days, that day is a long, long way off.

I currently have a FrancisFrancis !X5. It is ok. It makes espresso fine, but its milk steamer is pretty weak. I'm of course comparing it to what you would find at a proper coffee shop.

As I don't have the coinage now to upgrade to anything that would be significantly better, I went searching for a cheap alternative.

I found something that suits me and the Mrs. (I make the coffee around here) just fine.

It is no frills, but it works better than my crappy X5 steamer and is easy to clean. And it is dirt cheap. You can find them at various places imagine - I don't even remember where I got mine. But it looks like this. Mine looks like the one that is second from the left. The one to the right of it looks good too.

iGel

More panic than usual at the panic factory.

We have had some methodology panic. Not so much disagreements, but more:

em, we have to release this in a little bit and we have to collaborate more so we better agree on how we are going to work together now so we can deliver and not look lame/dumb/hand-waver-ish

type of stuff. We are transitioning from doing a lot of throw away semi-functional POCs where collaboration was optional to building 1 skeleton system where we must collaborate heavily or we will slip.

These types of transitions are tough. But if they don't kill you, they only make you stronger.

You can be on the best team in the world (I actually think I am on one of them - no joke) and until you have been through the ringer and shipped something with that team, it doesn't matter much what you have done before with other teams. You have to make it work with this team. It can be hard to get the rhythm building - especially when so much has to be bootstrapped to get that first story tested and working.

I have been using Scrum for quite a while - at least 5 years on and off (mostly on). I like it because it is easy. The teams I have been on that have used it were always successful enough - mainly because all Scrum really says is you have a backlog, a sprint/iteration planning meeting, a daily scrum meeting, a sprint retrospective meeting and you have short iterations where you can course correct.

Within Scrum I have been a part of various analysis approaches. I have been a programmer / analyst and have been on teams that have had dedicated analysts who do insanely large Use Cases. Now I am on a team with 1 analyst who just churns out epics /stories like they are going out of style. She "gets it". I like people that "get it". I have been helping here prioritize / size the backlog lately.

On this project we are amping it up a bit and embracing things like Epics, stories, heavy TDD (Test Driven Development), and gasp ... a little pair programming (strictly voluntary for us). It really helps when you have an iGel Ninja around. You don't even have to listen to him talk - you just watch his hands and you understand (mostly). Come to think of it, we have 2 - we also have an Irish one. He isn't so much with the hands, but when he is the smoothest swearer I have ever met. It doesn't offend anyone when he does it even if it is a f-bomb. Dropping an occasional f-bomb is crucial to iGel success IMHO.

I have tried and failed too many times to count at TDD. But this time I am on a team that has the will and desire to succeed. I know many of the things that make it fail or rot on the vine. It basically comes down to discipline and no broken windows.

Our wiki is quite helpful in all of this as usual. I would jump out the window if someone took the wiki away.

Flex Links

A couple pro Flex links I liked below. I don't have much to say lately. Too much panic I suppose. You can find anti Flex links on your own. I wasn't convinced by them. For me to go with a commercial proprietary product I have to really like the vendor and the product has to be trending towards openness. I am not an Open Source zealot. Anyhoo, time will tell. I do think that it is exciting that user interfaces are poised for a new round of innovation. I likes the innovation.

Flex vs. Ajax Revisited

10 Reasons We Love Flex 2

How truly open is Flash? Do we need "Open Flash"?

New The Shins

I have been listening to the new The Shins, "Wincing The Night Away" all day. My bro-in-law Kevin gave it to me.

It just hit me that this album is as good as their previous albums.

Not an easy feat (spoken from someone who took harmonica lessons from a Franciscan nun - so I know a lot about this). ;)

I love that moment when it hits you that you really like something.

Sometimes it feels like it is random the things we remember our parents saying. I distinctly remember my mother saying to me, "You have to celebrate and embrace joy wherever you see it." Her point of course was that there is so much in the world that is hard, sad etc. and you should cherish the joyous parts. I only remember her saying that once, but I have thought of it thousands of times since then.

Channeling Powerbuilder via Flex

I did a little Powerbuilder programming 12 years or so ago. I also at one point (gasp) did some Lotus Domino development. It was even simpler to use and crank out applications with.

As this article describes:

They [Powerbuilder programmers] could do stuff quickly, or using the modern jargon, they were agile programmers without even knowing it.

One of the smartest people I know, my co-worker Erik Onnen recently tried every Ajax framework available and tore his hair out trying to deal with browser issues (don't even think about IE 6). This is not some browser neophyte. He knows JavaScript, JSON, CSS etc. inside and out.

Every Ajax intesive site I have been on besides Gmail locks up, bombs out and as another co-worker of mind (Ed Copony) says, "Ajax apps. make your computer fan go insane".

But I want to build a RIA app! I just don't want all the panic!

4-5 years ago building Flash GUI's was the rage for a bit. I never got a chance to do it & was admittedly against it in general. But suffering through Ajax makes one take another look. It is of course called Adobe Flex today & it seems to have come a long way. Certainly seems like a *productive* way to build RIAs. Sure you have to get past a couple hang ups, but that is life in the big city.

Hmmm, what can you do with Flex + JavaSpaces + Caching ... hmmm ...

REST JSR 311

Yay - should be interesting to see where this goes.

via Dan Diephouse.

Here are some other links: Marc Hadley example

Tim Bray

Steve Loughran begs them to keep it simple

Hopefully the expert group will resist the temptation to trick it out too much & will just keep it simple. I think there are benefits of doing this - will help spread the REST goodness if done correctly. Please oh please have a firm red line between message framing and message body (i.e., don't slow boil REST into insanity by making things "easy").

Good to see that some genuine REST experts are piling onto the expert group. Keep an eye on the big vendors. I'm sure the individuals are fine, but the people behind them who will start asking questions about how to "monetize" it probably are not. That is what got us into the WS-* mess. Standards as a gateway drug to pushing product is the root of all evil.

And we all know that sometimes people join standards committees to subvert them. I'm certainly not saying that this is the case, I'm just saying . . .

I'm crossing my fingers that this will lead to good things.

Hiring Green Beans

Are you a recent graduate or do you know one?

Are they smart?

Do they want an IT job within an information intensive company that never ever runs out of hard problems to solve?

Go here if you want to learn more.

Job Req: 26939BR

Many openings across the country including:

• NH-Dover
• NH-Exeter
• NH-Portsmouth
• OR-Portland
• WI-Wausau
• CO-Denver
• IN-Indianapolis

You do NOT have to have a technical degree. You do have to bring something to the table.

Shallow vs. Deep Entry Models & Mapping

Ok so guess what - JavaSpaces isn't a silver bullet! Shocker.

I am fond of talking of two big problems I have had in the past with ESB style architectures: excessive mapping and issues managing state (active/transient state vs. steady state/long-lived storage).

The mapping you deal with in an ESB includes object to XML (OX) and object to relational (OR) and various object to object mappings. Update (few hours later) - forgot one: And if it is a message-centric ESB, active/transient state to your destination names (e.g., hierarchical Topic names).

It isn't surprising, but I'm finding that all of the same object to object mapping is still there with JavaSpaces + an object to object equivalent of OX.

The ESB systems I have worked on in the past had a canonical message format. All messages that bounced around the ESB conformed to this model. Some of the messages were small validations of particular data (e.g., address scrub). The main work flows, however, were large XML documents loosely following the ACORD XML standard (insurance industry XML guideline).

With JavaSpaces, the patterns you read about use distributed data structures. Instead of having a large Entry in the space you have many that are related to each other. You do this for transactional reasons, serialization reasons, flexibility reasons etc. Some of the objects I deal with are indeed very large. Doing a take on a large object only to navigate the object graph and flip a bit and do another write isn't performant or flexible.

So the "shallow" model (lots of small interrelated Entries) works great for UI input, address validation etc.

But there are also areas of the system (some key work flows) that would benefit from a canonical form - the "deep" Entry model. Rather than having each worker gather all the Entries up to make sense of them, you do this once and then write the deep Entry to the space and let various workers use it to walk it through a work flow.

But now you have to render it back to your UI that expects a shallow representation.

So the deeper I get the more I realize that JavaSpaces do not make the mapping angst I have encountered go away. The mapping is still there. It is certainly improved because it is object to object mapping that is easy to write unit tests for etc., but it is still there. Update (few hours later) And there isn't any active/transient state mapping to destination names so at least one is eliminated entirely :)

These same issues are also present with a distributed caching solution I believe.

Do I have this right or am I missing something?

Transparency

Here is another example of why I think that transparency for analysts should be required. Same thing with political contributions. I don't have any problem with anybody sponsoring any report or anyone contributing anything to a political party. I think that is free speech & I think that trying to control it (e.g., McCain Feingold) is a complete waste of time and just muddles things even more. Just make it black and white and in front of people is all I say.

I don't question the integrity of anyone per say, by making one's constituents known, however, there is a bit of omnipresent sunshine that generally forces people to be more honest and objective.

Until this is dealt with, there will always be people like me snickering about industry reports like this.

Via Simon Phipps. By the way - I don't think this is a problem just with Microsoft. Perhaps Sun could lead the charge on this type of thing by having a policy of having their name on all studies that they fund. Perhaps they already do this?

People are Talking

People are Talking. Talking about JavaSpaces & distributed caching.

As my co-worker Ed would say, the future is coming!! And so when are the big boys going to notice that the future is coming? Hmmmmm.

Perhaps this technology will be in a few Plan B MRDs this year.

Did Cameron really say this:

Our reason for considering the introduction of JavaSpaces into Coherence is to allow programmers to use the spaces model and the JavaSpaces API to code parts of those transactions. While JavaSpaces is not an effective data management API (i.e. it's not good for replacing a database), it is an effective data processing API (i.e. it can easily be used for computational processing in a grid). So Coherence can certainly bring those two concepts together (data managed by a database and processed using a spaces approach).

Peace,

Cameron Purdy Tangosol Coherence: The Java Data Grid

Yes he did! He authenticated it with the "Peace" key!

Should be interesting to watch - perhaps embedding Blitz? Why don't you OSS Coherence while you are at it? People still need support. Look at JBoss.

Whilst

All you have to do is say whilst and you sound smart.

Why is it that Euro English appeals to me and Canadian English doesn't?

I guess it is just really Irish and English - English that I get a kick out of.

The best is how the Irish (at least the Belfastians I work with) say their filler word. Instead of "um" or "ugh" it's "em". To be globerly (neighborly), we here in Portland have started to say "em" as well. We also occasionally throw them a bone and say "dater".

01-FEB-2007 - Update misspelling per email from my dear mother: Subject: Spelling Correction on Your Blog

uh........em...............not "through" but "throw"

em...er....yer mom :)

xxoo

Software Engineering Ethics

I hadn't read the Software Engineering Code of Ethics and Professional Practice since I was introduced to it in grad school (only got 1/3 of the way through - perhaps I'll finish some day).

We were required to sign it. I think that was good.

Anyway, since you probably won't click it, here is the short version. If you want the long version, well click it. And you should sign it too. I'm also adding it to my blog as a link to remind myself to be a good dude. On some days I certainly need a reminder.

Software Engineering Code of Ethics and Professional Practice Short Version Preamble

The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES Software engineers shall be fair to and supportive of their colleagues.

8. SELF Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.