Friday, December 29, 2006

2007 Predictions

I promised last week to post some predictions for 2007.

Here goes . . .

  1. Even the day coders will run screaming from WS-*. The battle is won; we night coders killed it because we didn't want to be controlled by vendor-pires and it is fundamentally flawed technology. Sadly, even though I believe that it is dead, it will take 2 more years before the industry echo chamber comes to terms with it. Software vendors who are heavily invested in WS-* will spend 2007 doing two things: one last gasp at making WS-* happen and quietly writing their Plan B MRDs.
  2. REST usage will increase in lieu of WS-*, but it won't unseat messaging and other middleware.
  3. People will settle down a tad about Ajax. It's great and all, but I've been seeing more and more botched impls. Like just about everything, its just a tool not a dogma.
  4. XML will finally be considered one tool in the tool chest just like every other technology. Development teams will only use XML where it actually adds value and not force it into places where it does not belong.
  5. The virtualization march will continue.
  6. Distributed Cache and JavaSpace usage will accelerate as more people grok the power of this architecture style.
  7. Apache River will breathe new life into Jini/JavaSpaces. Both will see lots of new interest and implementations. 2007 will be a "rebuilding year" (as they say in sports) - 2008 will be the big year for a Jini/JavaSpaces come back. Someone from Sun will formally apologize to all the people maimed by J2EE in 2009 and acknowledge that they should have marketed Jini as a service technology from the beginning (ok just kidding that isn't going to happen).
  8. The Open Source patent war will begin in earnest.
  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.
  10. Even more smart people will start blogs or at least start reading blogs which result in even more transparency and open collaboration between software vendors, customers, and consultants and ultimately better software, more innovation, and less waste.
Alright, that is all I have . . . mostly just a bunch of blather, sorry. I am very excited about 2007. Should be an exciting year to say the least.

Thursday, December 28, 2006

SBA & EDA Lessons Learned

I am still getting my head around SBA (Space Based Architecture)/distributed caching patterns.

I have a ways to go, but the more I read about it (blogs, docs, specs, etc.), talk about it with my insanely smart co-workers, and do stuff with it (hands on) the more I like it.

Like most humans, my mind works quickest when I can associate concepts. As I have mentioned before, I see a lot of parallels between SBA and EDA - specifically Message-Centric EDA. Last Spring, I did a series on lessons learned from an implementation of what I consider Message-Centric EDA. I'm going to pick out a few notable differences that I have noticed so far that makes SBA extremely appealing to me.

  1. Content Based Routing
    Content Based Routing, Itinerary Based Routing, any service orchestration you can think of other than frightening things like BPM/BPEL are all achievable with SBA. And its done by using the state of your objects, not Topics, XML and all the complexity and angst that comes with it.
  2. Choose Topics over Queues
    SBA wins hands down. Instead of mapping your system into using Hierarchical Topic Names including event types and states you put objects into the space and the state of the objects drives the service orchestration (take, notify, etc.). It's insanely simple. This eliminates 2 mappings: system state to Hierarchical Topic Names and Object to XML (and back). In a large system, this results in heaps and heaps of complexity eliminated.
  3. Persistence
    No XML shredding in SBA, the space fits the transient data solution I mentioned. It can be configured to be persistent/reliable & in some implementations mirrored, clustered, etc. Getting relational databases out of the transient state business is great for simplicity / flexibility / maintainability / scalability. Again, one less mapping to deal with - only persist to long term storage at well defined states (again based on your objects, not a serialized XML version of them).

SBA basically turns messaging patterns upside down. The patterns are similar, just simpler in SBA. At first look, the SBA versions seem better. Perhaps the grass is greener, perhaps not.

The right answer is probably all of the above / both SBA and EDA. The really hard part is figuring out where to use which in building loosely coupled cohesive systems.

Update 29-DEC-2006 I was inspired thinking about this further on the walk to work this morning . . . I mention complexity and mapping above. Things like object to XML (and back) (OX), system state to hierarchical Topic names (and back), object to relational db (OR), Object to XML (Castor, JAXB, etc.), XML to relational db (XML shredding). Why do you care about all this? I'll tell you why you do. Not having this cruft in your system results in:

  1. Hundreds of conversations and meetings that you will not have sorting this mapping out
  2. Many design decisions / design details you won't care about
  3. Thousands of unit tests you won't write
  4. Hundreds of defects that you won't file, ponder, fix, and unit test

Update 07-FEB-2007 Appeasing the "then" vs. "than" police.

Update 22-JUL-2007 As this page is linked to from a Wikipedia page on Space Based Architecture, and gets a fair amount of referrals, I think that I have a responsibility to temper my original comments with what I believe today. I continue to have high hopes for Tuple Spaces, JavaSpaces, and SBA. In my opinion, however, there are not enough viable alternatives today. This is very important to me. I am watching with great interest what will happen with Apache River prior to making any further investment in this technology.

Apache River

Apache River is a new Apache podling (incubated project).

This should be fun to watch.

2007 is going to be fun I think.

"River" is a good enough name - I like it, but then again, I love rivers

Powerbook Rot

Jon Udell complains about Powerbook Rot.

Sadly, I have experienced the same thing with mine.

I drive mine pretty hard because, well, it's a laptop. And my 20 month old daughter pokes at it - maybe that is my problem.

My biggest beef is the power cord. I am on my second one ($100 or so) and it is cracked with electrical tape all over it (fire threat) and barely works. I have to keep one hand on it half the time. Lame. They brag about the magnetics, but I think it isn't durable enough. Next beef is the battery - they go to crap pretty quickly. I think this is just laptop batteries in general though.

Anyway, in general I love OS X. It is the only thing to have your family on. I just think there is some room for improvement around durability. How sweet would a ruggedized Powerbook be? Maybe they have those somewhere.

Annyway . . .

Wednesday, December 27, 2006

First Turducken

I had my first Turducken Christmas Eve.

It was delicious.

Here is a picture of it.

Yes this is ridiculous, but don't knock it until you try it.

We didn't do the hard work of assembling it. We just bought it at my wife's childhood butcher (and now my sisters) and baked it. The truly experienced apparently deep-fry them.

Friday, December 22, 2006

2007 Predictions Starting

Here come the 2007 predictions. Who doesn't like these? Perhaps we need another round of blog tag on that ;)

Patrick Logan has one that I'd like to see come true. I'd at least like to see a good hard look at it. I've lived web services, ESB, EDA, and they all have their issues. I'm sure Jini/JavaSpaces has its as well, but perhaps the best of all of them is the right fit (ok REST not web services).

As the industry comes to term with the failure of WS-* we can either start over and reinvent things again or perhaps take a look back at some of the technology that should have been front and center to begin with.

I will post my prediction next week.

VMWare for OS X

The virtualization march continues . . .

VMWare has an OS X beta.

Saw this on Matt Raible's blog.

Monday, December 18, 2006

Jini Red Pill

My point is, that all this JBI/BPM/Web Services/'Lets Ra-ra-ra about RoR' is what you get and what you accept when you take the Blue Pill, so the thing is why don't you have a go with something different, could be anything (for those that have never tried Jini but have even a slight interest in SOA, have a look it doesn't bite). Follow your enthusiasm, you'll never know where it might take you. Take a chance - take the Red Pill

I like all references to the (now) eternal Red Pill. I loves the Red Pills. They keep me spry and handome.

I also like all things and people that are wise enough to diss JBI/BPM/Web Services in one sentence. Now that is a skill.

Mind you I have heaps to learn about Jini and JavaSpaces. Just saying I like this sentence.

All I know is WS-* is dead, REST doesn't cut it for (a lot of) the stuff I do, and I know enough already about the problems with ESBs and Messaging. I want some new problems to deal with. Or at least I want to fix a couple problems. No idea where it will go at this point.

I will say that I am going to be really pissed at Sun if Jini does turn out to be great. I mean I lived through 5 years (5 years!!!) of J2EE - all of it - even CMP!! If Jini is heaps better and Sun put me through that misery just because they totally botched the marketing campaign around Jini then I'm going to be a little upset.

Sunday, December 17, 2006

Blog Tagged

Patrick Logan blog tagged me.

You are supposed to share 5 little known things about yourself.

Update 15-DEC-2006 Patrick Logan wondered why I didn't take the time to explain my nickname, "fuzzy" and "panic" (i.e., Panic From Fuzzy). So I'll work it into my five things. Just a warning - it isn't very exciting.

Here are my 5:

  1. Probably the best thing that ever happened to me was being "held back" (i.e., failed) the first grade. I was just a late bloomer. But who knows what would have happened if I continued on when I wasn't quite ready. I give my parents *a lot* of credit for letting me fail at lots of things when I was young. They also encouraged me to pick myself back up. Based on my experience, I think the best thing parents can do is let their children fail. It teaches them resilience. If they don't fail when they are young they will not know how to deal with things that are hard when they are in the real world. If they aren't failing once in a while, you aren't doing your job as a parent.
  2. In high school I played hockey, tennis, and soccer (for 1 year). I liked hockey best. I quit soccer to play hockey more (I had some catching up to do). I was an average player. Getting up for 5:30 AM ice time was very good for teaching me work ethic. I received the nickname "Fuzzy" on my high school hockey team. No particular reason - you know how nicknames sometimes just stick. My Dad calls me Fuzzy and me friends from college and high school do as well. I basically stopped it once I entered "the real world", but it has seen a resurgence since I named my blog this (go figure).
  3. I attended The University of Dayton. It is a Catholic school. The brothers there are Marionist and their philosophy is to "Promote quality education of the whole person". This worked well for me. I studied a lot, but also "socialized" a lot. I really enjoyed my years at UD. Today I am not that into organized religion. But I am still a spiritual person. I need to figure out what to do about this in the next year or two as my child grows. I want her to be spiritual too. I might go religion shopping or I might just go to a Catholic church.
  4. I got a C in my first computer science class. Programming was very hard for me at first. You may laugh, but the concept of loops *blew my mind*. I remember sitting in my professor's office telling him how hard I was working (I was) and having him say that computer programming isn't for everyone and maybe I should hang it up. My resilience kicked in here and I eventually got it. I am very glad I stuck with it because I really love what I do for a living. The term "panic" came from UD. My friends and I were very into lingo (using clever word plays etc.). For whatever reason, the word "panic" was used often. I still think that it is a very versatile word and that it is applicable to heaps of "real world" situations.
  5. I love the outdoors. I hike and fly fish as much as I can (less since I had a child 1.5 years ago). My favorite activity is definitely fly fishing. I stop thinking about work related stuff for hours on end when I go fly fishing
Here are my 5 tags: Sarge Dodge, Mike Dierken, Matt Asay, markg, Kris Tuttle

Friday, December 15, 2006


So we have some killer jobs opening in Portland, Oregon and Indianapolis, Indiana if you are interested.

The job description is a wee bit enterprisey, but that is just how our CTO talks. He's a great dude and isn't enterprisey to a fault. Very empowered place to work. Come join the fun. Let me know if you are interested (mherrick66 AT yahoo DOT com).

Basically you need to be a digital assassin, a leader, play exceptionally well in the sandbox with all kinds and have communication skills. You know commodity type skill set ;)

You know, like nunchuck skills, bowhunting skills, computer hacking skills..

Update 18-DEC-2006 To apply online go here. It is req# 27179BR. For the Portland job, you need to have some mainframe experience (e.g., VSE, iSeries-AS400, zSeries-MVS). You also have to have IT portfolio management experience. This job has a range of levels that you can be hired in as depending on your experience.

Technologist/Architect Job Description

Serves in multiple leading architectural roles across multiple projects and domains. Role is for the highest level professional ranking within IT. Must be capable of handling an aggressive and challenging workload at the highest levels of quality and throughput.

Responsible for developing business systems plans, roadmaps, and strategies that drive the delivery of software solutions which provide competitive advantage in the three to five year time frame. Works with solution delivery teams to provide direction, guidance, and hands-on mentoring. Reviews and develops architectural models and solution artifacts at both conceptual and detailed levels. Analyses highly complex enterprise wide system, technical, process and product issues to develop strategic direction and transformation plans -- participates in and is responsible for effective execution.

In-depth knowledge of business operations, objectives and strategies; in-depth understanding of global business and technology trends and the financial services industry. Experienced in applying best practices of architecture governance, methodology, and agile methods at both project and enterprise levels. Leads projects of strategic impact. Drives end-to-end life cycle improvements in IT processes.

Must have superior verbal and written communication skills, and have demonstrated application at all levels of business, systems, and executive interaction. Role requires extensive development of materials ranging from proposals, strategies, standards, architecture assessments, research papers, and presentation materials for diverse audiences.

Generally, the following minimum requirements apply: 15 years of related experience; Bachelors or Masters Degree in Computer Science or similar; current mastery of multiple architecture specializations (i.e. information, data, application, solution, integration, or enterprise architecture); current experience and mastery of IT concepts, strategies, software engineering, and modeling techniques.

Candidates will be required to demonstrate proficiency via sample written exercises, modeling scenarios in one or more disciplines, and potentially analytical and/or software engineering tests.

Range of technical skills required include: Information Management (governance, strategy, meta data processes); Data Management (logical data modeling, enterprise warehousing, business intelligence, object-relational modeling); Enterprise Architecture (business and technical reference models, solution architecture, legacy systems modernization, business process modeling); Software Engineering (full lifecycle development, including management, compliance, UML modeling); Network and Infrastructure Architecture; Enterprise Application Integration (mainframe architecture, J2EE middleware, ERP implementation); Enterprise Program and Portfolio Management.

Thursday, December 14, 2006

Jini/JavaSpaces & Distributed Caching

We are taking a gander at some space / cache technology and looking at ideal ways to do service orchestration with it in the architecture.

I am fortunate enough to work with Patrick Logan and he has some good questions. He worked for Gemstone a while ago so he knows their are opportunities to hurt oneself if one chooses unwisely.

I like JMS enough, but it has its issues. If there is a better, simpler way to do service orchestration I'm all ears.

Master/Worker with spaces might work. What else?

I like location transparency. It’s neat.

Update 27-DEC-2006 Just tickling your RSS reader - some good comments on this post. Please chime in if you have an opinion. I am becoming fascinated with this topic. There are a lot of parallels between SBA/distributed caching and EDA service orchestration models. I'm spending some time getting my hands dirty trying to get my head around it better.

Wednesday, December 06, 2006

OSDL Layoff

OSDL had a layoff the other day.

I have gotten to know a number of these fine people. They have been very good to me. I wish them luck. There are some good people left - Mike Temple and Tom Hanrahan certainly know stuff.

I also wish Stuart Cohen luck in his new venture. I certainly share his enthusiasm for it . . . its just a tough nut to crack (speaking from experience).

Not nearly as complicated as sharing code amongst your peers via some predatory vendor (and only having access to the binaries - not the source), but large companies have a hard time groking this. And there are forces that don't want this to happen.

We just need some more success stories . . .

Linux has won - some people just don't get that yet, but it won. Open Source still needs defenders and custodians like OSDL. Patents are obviously the next battle. Diane M. Peters knows a lot about that.

So I don't know if this is bad news or just a blip. My gut says its a blip. Times are changing . . . Linux won - old structures require change.

OSS is crawling up the stack . . . if Stewart has his way, the last big $$ maker will fall next. And then everyone will have to compete on business value rather then intellectual property lock in.

Wouldn't that be nice?

Thursday, November 23, 2006

SBA trumps EDA?

We are taking a look at some architectures for a next generation of a critical system at work.

I am a fan of EDA - Event Driven Architecture. I posted about it a bit here.

Its nice and all, but it is not without its problems. It certainly has a role to play in any architecture. But the last time I built one, I ran into some problems as detailed in my series linked to above.

Does SBA (Space Based Architecture) simplify things even more? For one thing, it minimizes "legacy" XML which is certainly a good thing. And the location transparency is mind boggling. Makes things like Sonic's shared subscriptions look quaint.

Just when you were happy that web services are finally dead, there is another shift. And if you are still talking about web services, well . . . sorry.

Wednesday, November 22, 2006

FUD Based Business Models

What a waste of time.

Something tells me that getting this clause adopted to GPL won't be as hard as GPL v3. I dislike FUD based business models. Around and round we go ...

Tuesday, November 21, 2006

Mother's Uncle George Stalk

My mother's Uncle George passed away a few weeks ago. He was an American hero (a retired Colonel). I only met him a couple times, but remember him fondly.

Check out the beautiful day at Arlington National Cemetary November 15.

Picture taken by my Uncle Michael.

Sunday, November 19, 2006

Eye Twitch

I first remember getting the eye twitch in college during final exams.

Its back!

I get this every time I work too hard. Its pretty annoying. It's as if I have a short circuit or something!

I suppose it is one way for my body to tell me to get more sleep :)

Thursday, November 09, 2006

Wikis & Blogs heart Firefox 2.0

It spell checks!

That is what I'm talking about!

Good bye document paradigm! Good bye!!!!!

Herro collaborative editing!!!!

Monday, November 06, 2006


As if I wasn't busy enough I am now insanely busy.

What is it they say . . . "If it doesn't kill you it makes you stronger"??

I sure hope so . . .

Nothing that OCD usage of a wiki can't solve I hope.

Tuesday, October 31, 2006

Vacation, Ken Kesey

I am back from a much needed vacation.

Had some fun playing frisbee on the beach with a friend I have known since I was 5. Our digital camera got canned before the vacation. My wife thought it made a fine toy for our 1.5 year old daughter. The camera didn't think so. We were reduced to using a disposable camera so no pics. My friend also has a young daughter so he also goes to bed at 10 PM. But we were pretty cool in college.

I'm not done yet, but I started reading Sometimes a Great Notion by Ken Kesey. Good book so far. The book is based in Oregon, which I of course like. Kesey spent a lot of time in Oregon and was an interesting dude to say the least. Figured I needed a break from technical, business, and political books. I guess I should wait until the end, but so far I see the link between Kesey and Jack Kerouac .

I became interested in Ken Kesey after watching The Net: The Unabomber, LSD and the Internet. I think "The Net" is worth a look, makes you think. I knew about Kesey before, but didn't know his LSD experiments created the Internet (joke, but watch the documentary - warning sub-titles)

Sunday, October 22, 2006

Espresso I love you

I love espresso.

Portland is the epicenter for coffee Or at least one of them.

Check out this article from the Willamette Week:

Bean Town Thanks to a gang of coffee fanatics, Portland is the center of a new microbrew revolution.

That is what I'm talkn' about!!

Coffee is a big part of the Portland culture and I love it! At work, our team rips a trip across the street to our local independent coffee shop, J Cafe, at least 1x a day. We alternate paying. This is basically our Scrum stand-up meeting "if you will". We mix in cheap jokes and walk around the block and also talk about our projects. I dig this.

Each morning, I fire up my Francis! Francis! espresso machine and pull 4 shots. 2 for me and 2 for my lovely wife. Before long, our 1.5 year old will get in on the fun ;)

I am a b player barrista at best. No c player. I use "e.s.e. pods" (easy serving espresso). They work pretty well. I have been buying cases of Illy for a couple years. I just realized that e.s.e. is a coffee industry standard. I'm going to check out some of the other brands available at PodMerchant. Illy will be tough to beat though.

If you come to Portland, you must go to Stumptown. Best coffee ever flat out.

Yes, at this moment I am "over served" on espresso. Yes that is why I am blogging about it. SO WHAT!?!

Thursday, October 19, 2006


I have been using Ubuntu pretty regularly for almost a month now.

Far and away the best desktop Linux experience I have ever had.

It isn't MAC OS X, but its pretty good. Especially since its free.

Very impressive.

Wednesday, October 18, 2006

The Freedom to Fork - Hard Lessons for Compiere

I saw over on Matt Asay's blog that Compiere has been forked.

I do not know their founder personally (Jorg Janke), but I have met him a number of times in the past. I'm sure he doesn't remember me. I remember talking to him 1.5 years ago when he moved to Portland about VCs. He was moving into the same incubator as my previous employer here in Portland (an OSS ESB company that failed). He said something like, "they will take your left arm". Well, I don't know about that, but either he was too worried about losing his "left arm" (and neglected the most crucial part of OSS - community), OR they did take his left arm and he can no longer code like the dickens (they probably started talking to VCs six months ago and got very distracted by that and moving to SF - silly idea when you have a thriving international community and you are already in one of the most OSS friendly cities in the world!?).

Now I have no idea what the truth is here.

Just yesterday, however, I was on a 6:30 AM ccall extolling the virtues of the "freedom to fork". This crucial aspect of OSS gives the community incredible power over the software it invests in. This is software the way God intended it to be. It is separation of powers just like (we think/hope) our democracies work.

I hope that Compiere Inc. turns this around - it isn't too late. But it better shell out some of that $6M to make amends with its #1 asset - the community that is invested in it. Hey Larry Augustin is on the Compiere board! I just listened to a fantastic talk of his last week at GOSCON. Here is the summary:

One of the hardest parts of utilizing Open Source is building true community involvement. The benefits of Open Source only accrue when an outside third party community participates. This talk will describe various ways to help engage a community around your Open Source project.

Larry, give Jorg the presentation quick!

Tuesday, October 17, 2006

Utility Computing & Open Dater

Man, utility computing is really going nuts lately. Check out Sun (via Tim Bray): Sun's Shipping Container.

At OSCON, Tim O'Reilly talked a lot about Open Dater. At the time I remember being slightly annoyed because he talked about it a lot.

But as the months have gone by since OSCON, I have thought about it several times so he certainly got my attention.

Anyhoo, cool shipping crate, very cool shipping crate.

Monday, October 16, 2006

Celtic Wisdom

My mother is a voracious reader. She is into Celtic Christianity. I'm not terribly religious (in an organized way anyhow), but I dig the stuff she tells me about Celtic Christianity. It is apparently more in tune with nature which suits me fine.

Take this quote, for example from a book she read named Anam Cara: A Book of Celtic Wisdom

There is a lovely anecdote from the Munster region about a man who had died. As the Soul left the body, it went to the door of the house to begin its journey back to the eternal place. But the Soul looked back at the now empty body and lingered at the door. Then it went back and kissed the body and talked to it. The Soul thanked the body for being such a hospitable place for its life journey and remembered the kindnesses the body had shown it during life. page 209

She read that to me when she was in town. I thought about it a couple times since she left so I had her look it up for me. I figured it was worth sharing. Profound eh?

Sunday, October 15, 2006

Fall Salmon

We went to the Salmon Festival at Oxbow Park yesterday.

Pretty cool.

They had all sorts of exhibits and some traditionally cooked salmon (yum).

I didn't catch any of the fish on film, but here is my curly-haired-daughter watching them. Every minute or so you would see a giant Chinook take a tear up the river.

Friday, October 13, 2006

Bradley C. Wheeler

Bradley C. Wheeler is a pretty impressive dude.

Quite an Open Source visionary "if you will". He is the founding force behind community source.

He gave the closing keynote at GOSCON today. He gave by far the best presentation I saw. And he has a certain irreverent zip to him that I relate to.

He also announced that the much anticipated Kuali 1.0 was released today. Pretty brave seeing its Friday the 13th. If you are in the market for a university ERP system, you may test drive it here. Hopefully it will be as successful as Sakai.

You may think that its easy to pull this type of thing off in academia, sure didn't sound like it was. But it is now because they have established the model. And there is major corporate involvement. This is not communism. As Brad said, this is creative destruction - exactly what capitalism is all about.

If they can build these things with OSS, what can't be built with OSS?

Wednesday, October 11, 2006


I attended an OSDL "Face to Face" meeting today here in Portland.

I could only attend part of it, but it was pretty interesting. I've been a believer in OSS for a long time. I see only a bright bright future for OSS. To put it short, OSS allows us all to accelerate innovation. We can take code that works and keep building up higher and higher in the stack. We don't have to keep re-implementing the same thing over and over again. We are only beginning to learn how powerful this concept is. There is a lot to come.

I'm going to GOSCON tomorrow and Friday.

Only thing not so fun about attending these conferences is I have to catch up on heaps of work at night. Oh well.

Monday, October 02, 2006


Good article on sprawl. Compares my town with a town in Arizona.

My mother is in town and is sitting next to me with her own PowerBook - she forwarded me the article.

She likes Solitare in Dashboard, email, the web, and genealogy (she has a 700MB Pages document with our family history going back to Bluetooth in Denmark - how big is your biggest Pages document?).

Anyways, I'm glad I don't live in sprawl hell. I love urban living. I love walking to work. Once we move from our condo a key requirement is that I must at least be able to bike to work.

But then again, this article reminds me just how complicated the world is.

Well worth a read I think.

One note on Pages - I think all word processors just suck and exist solely to torture us. She has shown me some doozy defects in her 700MB document.

Wednesday, September 27, 2006

Little Jars of Formaldehyde

So we were talking at work today about virtualization and clouds of computing and clouds of data (like Amazon/Google style).

I mentioned the other day the whole envelope thing. Like how in the future perhaps applications will just be deployed with everything they need wrapped around them (OS). You just deploy them to your cloud of computers. They can be x86, RISC, whatever you like. The OS can be whatever you like.

Patrick Logan called these applications from the future "little jars of formaldehyde".

How great is that!?

If he made that up, wow.

This would solve all sorts of problems. ALL SORTS OF AWFUL AWFUL AWFUL PROBLEMS!!!

Sure it might bring a few along with it, but SO WHAT!?

Sunday, September 24, 2006

Cyclocross Bike?

So I have to convince the Mrs., but I really want a bike. I haven't had one in long time.

I walk to/from work every day. One of the better things ever invented. But I want to mix it up with biking as well. Portland is rather bitchn' for biking.

I also want to take this bike up to Forest Park and other tame "mountain bikeish" places. Let's be honest here, I'm washed up. I won't be jumping anything anytime soon.

I test drove a Lemond Poprad today.

And a co-worker & friend of mine Ed recommends these as well:

Surly certainly wins my heart with clever lingo (and the word "surly" is quite versatile):

. . .What does all this mean to you? Options, kid, that's what. Get yer freak on. Gears? Great. Single speed? No sweat. Commuter? Touring bike? Grocery getter? Bring it on. Or, build it as a bonafide 'cross bike and race it. It likes it.

Silly System Beep

Only Ubuntu/Debian complaint so far (or from Ubuntu: linky):

Not to worry, quick google search fixed it within 5 minutes.

Too funny (from the link with the fix):

If you’re like me, you start getting real annoyed, real fast at the system beep that insists on beeping far to often. This system beep emits not from your laptop speakers, but from that deep, dank recesses of ancient pc technology that is a little speaker designed only to beep annoyingly. Short of ripping it out, here’s how to disable it.

Do you have any idea how busy I am Hans Brix!?!

Virtualized Ubuntu

So that was the easiest thing I have ever done.

I settled in to beat my laptop into submission to run Ubunto on Vmware this morning. I figured it would take all sorts of angst.

"It just worked."

This is my first blog post from this environment.

My last workstation Linux install was not so kind. I ran Gentoo. It took 10 days. It really wasn't Gentoo's fault though. I had a very new laptop that had some very new hardware. I did like Gentoo lots. I remember begging X to work. Finally I found some guy on the Gentoo forums (fantastic) that had my same rig and had a x config that had the magic bits.

I'll let you know how the virtualized Ubuntu works.

Perhaps I'll start pronouncing "Ubuntu" correctly now ... nah it is just too much fun for me to pronounce it my own way: "UM-BOOOONtooo".

25-SEP-06 - Updated with proper spelling of "Ubuntu" - man I can't spell or say it!! I'm stupid stupid STUPID!

Saturday, September 23, 2006

Virtualization Aha!

We had a visitor from our Belfast, Ireland office yesterday named Iwan. We took him out for a beer after work and discussed all sorts of things.

One topic was virtualization. Among other things, Iwan is involved in infrastructure - he commented that for several years he has had to tell development teams "no" when they asked for a server because they already had too many under utilized machines and were running short of space and $$. But sharing environments comes with all sorts of truly awful wasted energy in coexistence.

He said that virtualization has allowed him to say "yes" to all sorts of requests.

We talked about shipping applications with the OS included in an "envelope". That basically just turns everything upside down.

I don't have a lot of experience with virtualization although people on my team do. I've followed the blog discussions and excitement around virtualization and agreed in general that it is a good. I just didn't feel any excitement about it personally.

I don't know what was said in our conversation last night that pushed me over the edge to have the "aha" moment, but I had one. "Aha!" moments are great. I've been having more then my fair share of them lately. We are living in truly amazing times.

I look forward to future beers (both virtual and real) with my new friend Iwan.

Saturday, September 16, 2006

Great Sofware Estimating Book

Wow, I picked up a great book today at Powells Technical. Software Estimation: Demystifying the Black Art by Steve McConnell.

We are doing a fair amount of estimating at work right now. We had a long meeting discussing an estimate for a project with heaps of unknowns. We put a decent plan in place for refining it next week on our own, but this book will help a lot I think.

I took a course at OMSE that covered a bit of estimating, but it was far too academic. I flipped through the book from the class I took and while it had some good ideas, it wasn't practical enough. McConnell's book touches on some of the academic approaches, but is very concise and has heaps of practical advise. The best part is it is broken down into 118 "tips" that are the heart of the book. I won't give too much of the book away, but the first tip sums up what is typically the crux of the problem:

Distinguish between estimates, targets, and commitments.

And Steve gives a suggested reading path for people who "need to create an estimate right now" (i.e., me and my team).

I like this book because it is focused on one thing (software estimating) - one absolutely critical thing.

We need more books like this. We can't just have the Mythical Man Month to turn to.

Thursday, September 14, 2006

OSS Derivatives

My friend Alok pointed me at this article by r0ml (Robert Lefkowitz) from over a year ago. I saw r0ml speak at OSCON this year. He is Not. Dumb.

I think that this is about as precise of an answer as you are going to get that will appease those that see OSS as an economic threat (comical).

I guess that this makes it a bit more tolerable that many commercial OSS vendors are pricing their software by the processor. I find this annoying because it means I have to count things and keep spreadsheets. I generally hate this type of friction - who doesn't. I still think that there must be a better way to price OSS. Perhaps they just aren't profitable?

You will likely have to read the article to "get" this quote, but here is r0ml:

. . . Those who have suggested that open source and free software is somehow not capitalistic, destroying the value of software and other such assertions, have missed this alternative explanation. It is just as likely that the free and open source software folk have stumbled across the financial engineering insight that a significant portion of the value of software is the embedded "derivatives"--options or warrants--on future maintenance and enhancement. Whether one believes that software has intrinsic value is related mostly to one's view on the correct value to use for volatility in calculating the option value. Larger values of volatility mean the software itself is worth less. Smaller values of volatility reduce the option price, and the software is intrinsically worth more.

Therefore, the major difference in worldview between open source advocates and proprietary software license advocates is explainable as a differing opinion on the correct value of the volatility of maintenance and upgrade pricing. People who believe that the pricing on maintenance is stable and unlikely to change see greater intrinsic value in the software. People who fear that the pricing is subject to large fluctuations see no intrinsic value in the up-front license; stripped of the options, the license value approaches $0.

For the open source movement, perhaps a better way to position the change that OSS is making is this: we're converting warrants on future maintenance and enhancements into options, which means that instead of having a sole supplier (warrants), we have created a third-party market (options) of these derivatives.

How capitalistic is that?

Tuesday, September 12, 2006


+1 for Tim Bray On Innovation.

But fortunes are made, and industry titans are built, where management isn’t really looking, almost always. The big pieces of innovation come out of garages and low-rent offices in lousy locations, and they’re produced by small groups without much management backing. It can be done at big companies (the business personal computer at IBM, Java at Sun) but then it’s always in an off-the-mainstream skunkworks. Nobody—I repeat, nobody—is smart enough to predict where the next big strategic innovation is going to come from. So if you “narrow your innovation focus”, you’re almost guaranteed to miss it. The best approach, I think, is a combination of conscious focused incremental innovation—kaizen—combined with a structure that’s loose enough that when someone wants to hide in a corner and try something crazy, you don’t get in the way too much.

My team has yet to deliver on our name, but with Magnum P.I. code names, an active WIKI, a great coffee shop across the street (J Cafe), a celebration of brains, dissent, decisions, stoofs, and quirkiness I think we are on our way.

Thursday, September 07, 2006


Yeah, Open Source Software is just Freeware. Weird commies in their underwear slanging out code for free because ... well who knows. And some academics too. That is all.

Nothing to see here. Just move along please ... MOVE ALONG.

I saw this a month ago, but someone on my team (biggest scariest smartest Viking you ever saw) forward it around again yesterday.

If anyone pours FUD on your Open Source parade, bang them on the head with this.

Um k, a couple excerpts for those afraid of clicking:

Open source is so pervasive that IDC declares in this study that open-source software represents the most significant all-encompassing and long-term trend that the software industry has seen since the early 1980s. IDC analysts also believe that open source will eventually play a role in the life-cycle of every major software category, and will fundamentally change the value proposition of packaged software for customers.

Wait, it isn't just build vs. buy? Yep-um-no.

As business requirements shift from acquiring new customers to sustaining existing ones, the competitive landscape will move towards costs savings and serving up sustaining innovations to savvy customers, along with providing mainstream software to new market segments that are willing to pay only a fraction of conventional software license fees," Picardi added. "Open source software is ultimately a resource for sustaining innovators.

Wednesday, September 06, 2006

8 Years of Episodes to Mine

Yeah so, if there was any doubt, we will be mining the 8 years of Magnum P.I. episodes for our project code names. Everybody likes witty code names - EVERYBODY.

Oh, you are using some stupid acronym for your project that everyone hates? Well, as Sarge would say, "you made your choices".

I am quite pleased with this - Magnum P.I. was a great show.

8 years of episodes! That is 8 years of characters! And 8 years of other mindless fun-facts that are at our disposal.

Oh and if you thought you were cool using mountains or rivers or something lame like that for your code names, well, you aren't. You are, admittedly better then the acronym crowd.

Fittingly, our first code name is "Magnum".

Saturday, September 02, 2006

Panic in a WIKI

We are in total brainstorm panic mode at work lately.

A very high level of thinking and learning occurring for the people I work with and me. You know that feeling. When you are full of stress because you have so much to do, but you don't really care because it is so exhilarating?

We are essentially living in our WIKI all day.

It is the most efficient way I have ever had a panic like this before.

We used WIKIs before, but it wasn't like this. The pace wasn't like this.

As an example, yesterday we had to get a slide deck together quickly. I just went into the WIKI and outlined it. And then over the course of the day the presentation magically appeared. It went through many revisions in near real time. It needs a little polish, but all the meat is there now.

If we had tried to meet about this for 1 hour, emailed it around, etc. it wouldn't have worked.

Anyway, been a WIKI fan for a while, but had no idea it could handle panic like this!

Friday, September 01, 2006

Give it a REST

Mark Baker interviewed by Stefan Tilkov.

I get tired of blathering on about WS-*, REST, et. al. but am sure glad Mark still has his mojo. Seriously, where does he get that mojo?

Saturday, August 26, 2006

Team Name

Our team at work finally has a name.

Naming groups of people in large organizations is not pleasant.

You go through acronym gymnastics trying to make clever things work. We had one acronym based name that someone's wife pointed out could also be spelled O-FACE (Office Space reference). We tried to use a metaphor, but sadly, those are hard to get past HR.

Our team is a bit of a Skunk Works, but we didn't want our name to make it appear like we aren't focused on providing business value.

Our name is:

Premium Innovation

That is about as much zip as you are going to get past upper management and HR at my company. For those not in the insurance industry, 'Premium' is synonymous with 'Revenue'. So it is a bit of a double entendre. We are focused on writing software and implementing systems that will have a very high impact on the bottom line. Putting the word 'premium' in the name is supposed to convey that. The second meaning means that we are premium software/system engineers (of course!). The 'innovation' bit is of course corporate, but it is better then "solutions" or something. And the truth is, we are going to be doing a lot of innovating (or at least that is the plan).

So there you have it.

Please don't ridicule the name - I simply can't bare it after going through 20 different ones the past month! ;)

Now of course there must be an acronym - this is corporate America. Don't quite know what it will be ... PI (like 3.14)? P.I. (Magnum!). PIT (Premium Innovation Team).

Time will tell ...


I'd just like to point out that Rainbow Sandals kick butt.

I prefer Double Leathers.

I'm going to go creep around my neighborhood wearing mine. They are 3 years old and they are magnificent.

Thursday, August 24, 2006


Last week I caught this redside Trout on the Deschutes

It was pretty wild - we fished this back eddy and didn't see much. As we hiked out we were on a ledge and had a great view above the river. Below we could see 2 large trout. I hiked back down with our guide, Jakob Lund and my dad and our guide to the Warm Springs reservation (Toot) stayed above.

My dad and Toot told us where the fish was and I casted to it. The fish started moving up river and we thought he was gone. But then he circled back and swam towards me. With my dad and Toot's frantic directions from above I saw the fish. I casted to it again and he slurped up my dry fly. He put up a good fight and we released him after this pic.

Lots of fun.

Sunday, August 20, 2006

Elemental Links - New Age Analyst

Brenda Michelson is starting her own analyst firm: Elemental Links .

I don't know her personally, just a blog colleague. I stumbled across a good paper on Event Driven Architecture (EDA) that she wrote a few months ago and I started reading her blog.

I really dig the fact that she is going to be a "transparent" analyst.

I have always been troubled by the transparency problem with IT Industry analysts. It is far too easy for analysts to have conflict of interest problems when they have clients on both sides of the fence. This is a problem when readers of the research do not know which vendors are also clients of the analyst / who funded the research they are reading (and perhaps basing vendor short lists on thinking that it is objective).

Kudos to Brenda for being transparent. We won't have to guess what her natural biases are (after all, we all have them). I hope that this becomes the norm with IT Industry analysts.

And Brenda, please make a point to always review an OSS alternative when researching software (given your track record in this area, I doubt this will be a problem). And if you don't think there is a credible OSS alternative, state why. This is another curious issue with non-transparent analyst firms. Too often viable OSS alternatives to proprietary software are not reviewed or even mentioned in research.

This is not an endorsement by my employer, but my personal view. Vendors are NOT free to quote with attribution to my employer.

Wireless Addiction

I'm with Roger Simon sadly. The house we rented in Sunriver (and all the others apparently) had a wireless network.

I also had my Blackberry "for emergencies".

The good news is I didn't get too behind on email. That is the bad news too.

With WiFi, wireless will be everywhere. Someday soon, it will be next to impossible to "disconnect".

Roger says it well:

But I fear for our future. As information intrudes everywhere, it will become harder and harder to find peace - unless we find it in ourselves... not always an easy thing.

Although I love technology and love the "connected" world, I liked the physical boundaries that used to exist when it came to vacation.

Friday, August 11, 2006

On a Bender

I'm going dark for a while ...

I'll be in Bend.

I will be kicking it with the family, having cold ones, mountain biking, hiking, fly fishing, and trying to resist learning more about Ruby.

Thursday, August 10, 2006

Open-Source people in their natural habitats

Tim Bray knows stuff:

I think Carr’s problem is that he doesn’t actually see Open-Source people in their natural habitats; he was at OSBC but not OSCON. The practice of OSS software has two drivers that matter: the community of peers, and the urge to scratch a technical itch. If you don’t understand that, you’ll never understand anything important about OSS.

I very briefly met Tim at OSCON.

I made a "I really respect your music" type comment to him. He was all, "hey thanks - who are you?".

The "I really respect your music" line originated in college. I was studying in Europe and attending a Phish/Santana show in Rome. Phish opened for Santana. When Phish finished their set, they came and hung out with the crowd (mostly a bunch of American college idiots like myself). Trey Anastasio (then Phish's lead singer) came by and I said, "Hey man, I really respect your music." (like a total blubbering idiot). Trey responded:

7 second pause, "hey, um ... thanks?". And then he left.

I have a way with words, what can I say.

Tuesday, August 08, 2006

Are Standards Becoming Barriers to Innovation?

+1 for Stefan Tilkov who +1's Sam Ruby.

Stefan Tilkov says:

The industry as a whole has become so dependent on abstractions that they’re used without regards for their benefit.

Sam Ruby says:

The link is the glue that holds the web together. It is what differentiates the web from protocols like ftp that merely serve as access methods for documents. The very notion of a link has become practically inexpressible and virtually unthinkable in the vernacular of SOA.

And I say, "standards" are becoming the enemy. They used to be the best option out there to defend against lock in. Now I fear that (at least in the integration space) standards are being abused to create barriers to entry and barriers to innovation. Every 6 months there is a new consortium, a new set of specifications, a new media blitz. Perhaps I’m just jaded or naive, but I believe in the future where open systems result in ex post facto standards. Standards should result when there is a ground swell of support from integration practitioners for some person’s or vendor’s open innovation – not from some theoretical agreement from vendors.

09-AUG-06 Updated with fixed name for Stefan Tilkov :O)

Saturday, August 05, 2006

Stumptown within 100 yards

There is new coffee house within 100 yards of my humble abode that serves Stumptown Coffee

I am an espresso addict and Stumptown is pretty much unbeatable in terms of "for shits-sake that is good" coffee.

This tricked-out coffee house named "Sip & Kranz" just opened. They:

  1. Have Stumptown Coffee
  2. Were professionally trained by Stumptown barristas
  3. Have a kids room for my darling daughter to play in while I take espresso baths
  4. Have Icelandic decor
I had my first cappuccino there this morning and it was as good as at a real Stumptown.

Needless to say, I'll be making many many stops there on my walk to work going forward.

Oh look, a better review then mine.

What does this have to do with EDA or Open Source you ask? What do you think gives me the fuel to yammer on about that stuff. Espresso is extremely important.

Monday, July 31, 2006

Later Bendy

Had a cold one with my original boss at LM. He is off to start his own digital textile printing business.

He was one of my favorite managers because he trusted me and turned me loose to do stuff. And he is smart & really engaged. I like the smart ones, mostly ...

Anyway, will miss you Bendy.

Good luck in your endeavor. Hope you sent that email ...

Sunday, July 30, 2006

Ruby Blocks

I commented on how I think Ruby Blocks are pretty sweet to my friend Erik and he responded:

come on dude, you sure you wouldn't rather type:

File f = null;

    f ="/tmp/bs");
catch(IOException ioe)
    if(null != f)
        catch(Exception e)

than:"/tmp/bs") { |file| //do stuff }

(that's my favorite example btw)

Yeah, so I like blocks better then the above ;)

Saturday, July 29, 2006

Learning Ruby

I am embarrassed to say that I don't know Ruby. I've hacked together shell scripts, done some Perl, but don't yet have any experience yet with Ruby.

Looks like my team may be using a bit of it, so I'm going to start learning it.

Just returned from Powells Technical Books (best bookstore flat out) with a Ruby book. They were all out of them at OSCON, but still happily gave me the OSCON 35% discount. I didn't have my badge from OSCON on me, but I did have a Mozilla Firefox T-shirt on so they believed that I'm a hacker.

Upon the recommendation of my friend Erik, I bought Dave Thomas' Programming Ruby.

I'll let you know what I think as I learn. I know a lot of people who I respect who dig Ruby. I'm assuming I will as well. I doubt I will turn into a Java basher though (like a lot of the Ruby on Rails crowd), but one never knows.

Friday, July 28, 2006

OSCON - Eben Moglen

My friends I was with at OSCON all ditched out on the Eben Moglen keyote at the end of the conference.

Their loss.

Eben is wicked smart and is doing very important work. The OSS community is lucky to have such able & passionate legal counsel.

While I don't always agree with the Free Software Foundation, I'm sure glad they are there.

Thursday, July 27, 2006

OSCON = Exhausted

Well, another OSCON is coming to an end.

It has been great. I am exhausted. If there was any doubt, I am now completely 100% washed up. I went out Monday, Tues, Wed. Last night especially. Monday, went out with a crew to the Portland City Grill. Tuesday, different crew - different restaurant. Last night was insane. Went to the Jive Software, OTBC, OSL party which was insane. Met Matt Raible. That gentleman is insane (in a good way). Also Bill Lynch from Jive. Also insane.

The sessions have been pretty good, although they have the annoying habbit of putting 2-3 sessions I want to attend all in the same time slot & then having none in the next, but all and all good show.

I met / listened to some of my favorite bloggers in sessions:

I was pretty impressed with a Sun session I went to. As I said in May, I think they are starting to come back. Now I have nothing against Ruby, but this session was a breath of fresh air as the Sun dudes were wicked smart and thoughtful. Some in the Ruby crowd (while also smart) are not so thoughtful.

Monday, July 24, 2006


Busy day.

I was at the office at 7:30 AM PST for a ccall and then at OSCON for Businesses Partnering with Open Source Communities: Opportunities, Perils, and Pitfalls at 8:30 AM.

It was pretty good. Didn't tell me anything I didn't really already know, but good reinforcement and looks like the handouts have some good articles I have not read.

It reinforced my belief that industry and acadamia need each other. The presenter, James Howison is doing his doctorate on OSS communities.

After OSCON, I walked to the office and ripped some meetings. For dinner, I hit Portland City Grill for dinner with friends. It was absolutely delightful. We had a wicked view of Mt. Hood and the food was ridiculous.

Looking forward to the Executive Briefing tomorrow.

Sunday, July 23, 2006

Reading Books 2.0

I finally finished reading Charlie Wilson's War.

I generally liked it. I knew that the United States was involved in helping the Mujahideen in Afghanistan during the Cold War, but had no idea just how much. I didn't know how tight we were with Pakistan and how we turned a blind eye to their Nuclear activities. I generally understand the details of "unintended consequences" a bit better now. And I had no idea how much 1 Congressman can get done (for better or worse).

The book reinforced my opinion that the world is insanely complex. It also made me less of a news junkie. Reading a view of history like this and realizing that at the time these events were taking place none of this was public knowledge makes reading the news voraciously seem rather pointless. Don't get me wrong, I'm still paying attention, just not as much.

I'm going to start reading The World is Flat, Release 2.0, by Thomas Friedman next. I used to read Tom Friedman's column every week at the NY Times. I quit at some point - forget if they put it behind a login or I got sick of it or what. And can we please all just shut up about "2.0". Does everything have to be "2.0". I mean come on - enough.

For software related stuff, I'm still reading: Open Sources 2.0 (the sequel to Open Voices)
Producing Open Source Software
and occasionally glancing at Open Source for the Enterprise (don't think it is very good).

Saturday, July 22, 2006

OOPSLA Event Driven Architecture Workshop

Saw this workshop at OOPSLA on EDA here in Portland, OR this fall via Marco on ESP.

I haven't been spending as much time obsessing about EDA as of late. But I still think it has the most promise in terms of enabling wicked cool integration. We just need something like AMQ IMHO.

Anyway, I hope to be there.

Maybe some of my EDA practitioner friends will be too?

Thursday, July 20, 2006

Open Source Transparency

Saw this article by John Udell via Pete Lyons

This is one of the many reasons I dig Open Source:

Open source software development, to a degree unmatched by any other modern profession, offers apprentices the opportunity to watch journeymen and masters at work, to interact with them, and to learn how they think, work, succeed, and fail. Transparency and accountability govern not only the production of source code but also the companion processes of design, specification, testing, maintenance, and evaluation.

Tuesday, July 18, 2006

U.S. Dpt. of Defense and Open Source Software

Saw this via Matt Asay.

Guess who is saying: To summarize: OSS and open source development methodologies are important to the National Security and National Interest of the U.S. for the following reasons:

  • Enhances agility of IT industries to more rapidly adapt and change to user needed capabilities.
  • Strengthens the industrial base by not protecting industry from competition. Makes industry more likely to compete on ideas and execution versus product lock-in.
  • Adoption recognizes a change in our position with regard to balance of trade of IT.
  • Enables DoD to secure the infrastructure and increase security by understanding what is actually in the source code of software installed in DoD networks.
  • Rapidly respond to adversary actions as well as rapid changes in the technology industrial base.

Yes, the U.S. Dpt. of Defense that is who. Now don't you feel silly for believing all that FUD?

Oh wait, there is more to Open Source then cost savings? Wait, now I get it!!

Seriously, this is good news for Open Source.

Monday, July 17, 2006

Blog Policy

I republished all of my posts today in order to bring my blog in compliance with my employer's, (Liberty Mutual, Agency Markets) developing blog policy. I needed to get the disclaimer on all of the pages. Sorry for screwing up your RSS reader.

My blog has been unconnected with my employer until recently when I posted some jobs, which, made it clear who I work for.

I inquired about a blog policy (since one didn't exist) and one is now in the works. In the interim, I received some initial guidelines.

It is your standard stuff:

  • The opinions expressed here represent my own and not those of Liberty Mutual
  • Vendors mentioned are not free to quote with attribution Liberty Mutual

But besides that, I was encouraged to continue blogging. I'm happy about this because I really enjoy doing it. I learn more from reading blogs and maintaining a blog then almost anything. There is something about just writing down your thoughts about complicated things in a public forum that makes you think harder in general. There is a real joy when you see people reading your blog (even though I only get 50 unique readers per day so far except when someone links to me), commenting on posts, and linking to it. I have made a handful of "blog friends" who I really respect. And some of our best candidates for the jobs I posted have come through my blog. I am a huge believer in blogs in general - not just for technology, but for all things. Blogs are driving tons of innovation and progress because they are breaking down traditional walls. That can be dangerous, but there is much more upside then downside. I am glad that I work for a company that cautiously encourages this.


I am looking forward to OSCON next week.

This is far and away the best conference I have attended.

It is also extremely convenient as it is a block away from my office. Last year I was attending OSCON as an Open Source ESB vendor. This year, I'm attending as the leader of a team dedicated to Open Source Software within Liberty Mutual, Agency Markets (large insurance company) - who knew!?

I typically just go to the sessions, but this year I am going to Businesses Partnering with Open Source Communities: Opportunities, Perils, and Pitfalls and O'Reilly Radar: The Executive Briefing

And of course some cool parties ;)

Let me know if you will be in town and I'll buy you a coffee or a cold one.

Saturday, July 15, 2006

OSL Tour

I went down to Oregon State University yesterday and met with Corey Shields - he is the Infrastructure Manager for OSL.

Fairly impressive facility. Very cool to see some of the machines that host Mozilla, Gentoo, OpenOffice and even Also all sorts of crazy machines for testing Gentoo. And a rack full of handhelds for testing those - that was pretty sweet.

They are growing - adding a bunch of racks.

If I had a growing Open Source Project, I'd park it at OSL. These guys know their stuff.

Monday, July 10, 2006

Standards Smanderds

Saw this via darth.

Great question/answer by Sun's Rich Green:

You see a lot of activity among developers happening in open-source projects and outside the standards processes, where most of Java development has historically happened. Is this a good thing? Is this a bad thing for Sun and Java?

Green: Oh, I think it's a great thing. You have to make sure that you don't get too hung up on history being the only way to do things. Standards were a great way of operating in the industry in a pre-open-source-world lifestyle, because they were the only way to gain sort of visibility and normalization or compatibility in products that were available in binary form. Now that things are available in source code form, (there are) different models of innovation and creativity and different notions of what is standard. So we're not trying to control it. We're not trying to say, "If it's not Java, it's not good." You'll see us reaching out to these projects and programs and supporting those things in ways greater than we've done before.

So, I'm just asking ... but in the age of Open Source then why do we need all of these? Why is so much premature standardization happening?

I'm all for standards, but how about we prove things out with Open Source first and then standardize once we have had a chance to beat things up really well?

Saturday, July 08, 2006

Web Services Panicscape Over Under

I commented on this on a couple blogs I read already, but I need to mention it here because I keep thinking about it. I came across it on Brenda Michelson's

Tell me that this isn't insane and has one iota of a prayer of making our lives integrating better.

This is madness.

One of the things I used to like to do was to set over unders for random things I encountered in my daily life - like I'm some sort of booky or something. My friends/co-workers would then place fake wagers on the over/under.

Sadly, I am going to set the over under for WS-* collapsing at 18 months. Too many software companies, integrators, etc. have too much invested ($$ and emotion) and too much to depreciate before we can get out from under this one.

If you are interested in placing a wager, please comment.

You Don't need no stinkn' IDL

Mark Baker says you don't need no stinkn' IDL:

Interoperability requires agreement, and agreement begets commoditization. If all the interfaces are the same, what would you describe?

And I agree.

As I have said before, I worked on CORBA systems at one point and somewhat "dug" the whole IDL thing. My little brain wanted Web Services to work the same way so when I have used web services I have gone the wsdl2java or xsd.exe route in .NET (no idea what .NET is calling it now .... this was a few years ago). I still think that wsdl2java is far less evil then java2wsdl which is just the most ass-backwards thing I have ever heard of, but the whole thing is an entire waste of time and results in entirely too much coupling and misery.

And it's just wasted coupling and wasted misery. Don't you want to spend your energy on better miserable things then this?

Update a half an hour later: Goodness, that brawl on the SOA Mailing list is still going on re: REST vs. WS-*.

In the context of that Stefan Tilkov, makes another good point on this topic:

OK, let's approach this differently, then - what, exactly, is the point of having an interface definition language if you're not generating code from it?

Removing the operation part from the contract (because it's static in case of REST) means you only need to generate code for the different schemas (if you want to, which I'm firmly opposed to). There's tons of tools to do this (e.g. JAXB in Java) supporting XML Schema. Why would you need anything more if you fix the set of operations?

Ah yes code generation. Another thing I used to think was neat. It's pure evile and don't let anybody tell you different.

Friday, July 07, 2006

EDA Lessons Learned - Config Files

See EDA Lessons Learned for the list

EDA is highly distributed.

This results in LOTS of processes and LOTS of config files.

This is another topic you want to think about at the beginning of the project.

We got this mostly right, by having Agent properties (JVM level) and Services properties. Service properties inherit from Agent properties (and can override them). We had some Java classloader problems, however, with Hibernate (not a big fan of ORM period - time savings are a myth - what is so wrong with SQL!? - sorry for the rant) and ended up with a property file on the system classpath. This seemingly small little problem became a total hassle. Last time I checked, it is still setup this way. We have talked a couple times about fixing it, but it keeps just getting talked about. We have talked about it enough to fix it 2X probably. And people trip over it occasionally.

So anyway, not too proud of this - don't do this. Pick a consistent approach and stick to it. If there is a problem, get it fixed right away or it will cause all sorts of little problems.

Deschutes Trout Creek

Since my wife thinks I'm nice, she gave me "a pass" as my friend Erik would say.

I get to hit Trout Creek on Sunday.

Good thing - I'm cooked and need a break.

Here little fishy fishy ...

Wednesday, July 05, 2006

Open Source Jobs Posted

The jobs I alluded to the other day have now been posted. Come be a part of the next wave of Open Source Software!

Here is the HR approved job posting. I wanted to just leave it at "Open Source Stone Killer" to see what we would get, but they wouldn't allow it. ;)


Utilizes expert knowledge of information and processing services to support the delivery of timely, quality software solutions. Develops, enhances and tests highly complex systems and/or software across multiple platforms, applications and projects. Acts as principal project architecture designer for 1 or more project teams. Transforms common system requirements into design for shared and reusable services. Coordinates upgrades and rollouts of larger, more complex scope. Leads projects or subprojects of significant technical complexity.

In this strategic role, you will deliver business value by building systems that meet or exceed business requirements and agreed upon timelines using Open Source Software.

Participate in developing the Liberty Mutual Agency Markets IT Open Source Software strategy.

Partner with the Open Source Community on Linux usage and middleware usage and contribution.

Evangelize lessons learned from Open Source Software community to our distributed developer network.

For these roles, we have the opportunity to hire at two levels: "Principal Software Engineer" and "Technologist".

As a “Principal Software Engineer” on our team, you would utilize expert knowledge of information and processing services to support the delivery of timely, quality software solutions. Develop, enhances and tests highly complex systems and/or software across multiple platforms, applications and projects. Act as principal project architecture designer for 1 or more project teams. Transform common system requirements into design for shared and reusable services. Coordinate upgrades and rollouts of larger, more complex scope. Lead projects or subprojects of significant technical complexity.

As a “Technologist” on our team, you would be responsible for developing clear, comprehensive and integrated technical and product architectures which support the IT infrastructure and provide long-term competitive advantage in the three to five year time frame. Review architectural designs to ensure consistency, maintainability and flexibility. Analyze highly complex enterprise wide system, technical and product issues to develop the strategic infrastructure direction. Investigate and forecast IT trends. Act as migration planning consultant and architecture guide. Lead projects or subprojects of strategic impact.

To be considered as a strong candidate for either role, you will need to have:

Extensive knowledge and experience building systems to support complex business functions.

Experience in financial services industry preferred, but not required.

Extensive knowledge of IT integration concepts including two or more of Portal technology, Event Driven Architecture, Service Oriented Architecture, Web Services, REST, and JMS.

Demonstrable experience with Open Source Software including Linux, Java OSS tools and frameworks and three or more of the following: Tomcat, JBoss, MySQL, PostgreSQL, PHP, Python, Ruby.

Negotiation, facilitation and consensus building skills. Strong oral and written communication skills; presentation skills.

Bachelors or Masters Degree in technical or business discipline or equivalent experience; technical degree preferred.

Generally a minimum of 8 years related experience.


Here is how you apply

  1. Click here
  2. Click on Experienced Hires
  3. Job Category: Information Technology
  4. Job Location City: OR-Portland
  5. External Job Title: Open Source Software Principal Software Engineer

Friday, June 30, 2006

OSS = Synchronized Self Interest

Great quote from Sun's Simmon Phipps:

Instead, the future is in co-operation and in organizations preserving what is ultimately of value to them, he said.

This is not volunteerism, It is directed self-interest, synchronized self-interest, and there is nothing wrong with self-interest.

My new friend, Jason Gilmore sent me a link to the story. This quote inparticular really struck a nerve with a lot of people I shared it with.

Here is the link to Simmon's presentation at OSBC.

I liked this quote as well: Three Golden Rules:

  • Collaborate over what does not differentiate
  • Compete by innovating on the commodity base
  • Contribute!

OSS is pretty mainstream now, but there is a huge third wave coming. It is going to be tough in the future to be a commercial software company I think.

It isn't just about cost savings. It isn't freeware. It is about innovation, agility, flexibility, and attracting talent.

Thursday, June 29, 2006

Complexity and Stockholm Syndrome

What is it about us human beings that we have this bizarre tendency to exhibit behavior consistent with Stockholm Syndrome when we work with technologies that are more complex then they need to be?

I have been guilty of this several times and will no doubt be guilty of it again. For all I know I'm guilty of it right now.

I saw this a lot with EJB. I was certainly guilty of it. Having achieved some success and decent understanding of EJB, I became an ardent defender of it even though it was terrible technology.

I see this same phenomena today with WS-*. I like to think that I learned to spot this trend with EJB and am wiser now, but for all I know I have Stockholm Syndrome with my messaging bias. I don't really think I do because I keep challenging myself to look past messaging in its current proprietary form.

I now think that I also had Stockholm Syndrome when I was an advocate of Rational ClearCase (sorry Sarge). Everyone new to ClearCase runs kicking and screaming from it because it is so complex. Once you suffer through the arduous learning curve, however, it is common to become a ClearCase zealot. I know, I was one for years! I'm dealing with this currently at work. Note to coworkers - I mean to offense by this and this is just my opinion. I think you are used to me by now.

Maybe I am just getting old and dumb and can only handle simple things.

Sunday, June 25, 2006

Insane Week + New Role + Jobs

I had a pretty crazy week. Last Sunday I flew with a crew from work to Indianapolis, IN for some post reorg meetings. The CIO announced his direct reports and the gist of the reorg the week before, but there were a lot of loose ends and various interpretations of the reorg to be worked out.

Talk about long and stressful days - we would get to the office at 7:30 AM and leave at 7:00 PM for dinner where work was discussed further.

The new org. is highly matrixed. This is how we were organized in Portland so I am used to that. Time will tell how it works on a much larger distributed scale.

I did get to go water skiing with some of my work friends one day - that was cool. Although it highlighted the point that I am indeed completely washed up (as if that was still a question) as I couldn't get up on one. I tried 4 times before I through in the towel and went with two.

The new CIO is pretty innovative. He has embraced distributed development and Open Source Software. My new job is leading the charge on OSS within our division. This marks my departure from a "Technologist" into management. This should be very interesting work. I will be working like a dog, however (not really a new thing sadly). I will be hiring a small senior team to get this organization off the ground. I have to put the job reqs together this week and will post links once they are available. But if you have a *passion* for OSS and live in Portland, Indianapolis, IN, or Wausau, WI and want to drive OSS adoption/contribution within a large company, let me know. For this initial round of hiring I am looking for stone killers with demonstrable OSS experience. As usual, communication skills are fairly crucial. If you can't collaborate and communicate effectively, your technical skills are useless to me.

Also, since we are now a distributed organization, there are some more jobs open in Portland, OR. Basically, going forward, most jobs that are open in Indianapolis will be open for staffing in Portland, OR. The opposite will be true for projects based in Portland, OR for Indianapolis and other cities. There are pros and cons to distributed development. It is the way the world is going, however. Our CIO is putting the right infrastructure in place to make this model work. The transition will no doubt take some time, but I am optimistic.

This list will be growing the next few months, but here is a list of the current open jobs (search for Information Technology).

Wednesday, June 21, 2006

Advanced Message Queue Protocol

My friend Erik pointed me at Advanced Message Queue Protocol a year ago, but I assumed it died.

Well, he pointed me at it again and it looks like it may go somewhere.

This would be fantastic. While I love messaging, bridging messaging systems really limits their reach.

I wonder how they are going to get everyone to play along (IBM, Tibco, Sonic, etc.). Hopefully, RedHat's effort will help: RedHat is currently working on an implementation that will be built into the operating system, making AMQ as free and available as SendMail, and accessible from any technology API such as JMS.

If this happens, it would be a major step forward in my opinion and a major enabler for large scale event driven architecture.

Thursday, June 15, 2006

EDA Lessons Learned - Transactions

See EDA Lessons Learned for the list

I'm not doing much (ok any) 2PC (two-phased commit) these days. I used to be pretty hip on XA in the Java world. I still run into people that yell at me about XA. Perhaps I wear size 16 burgundies (clown reference for the un-indoctrinated).

XA is great in theory and fun to drop in meetings (not quite as fun as 2PC), but:

  • Slow (sync to disc)
  • Expensive (resources)
  • Complex
  • Implementations often buggy
  • Not always easy to find XA impls (try VSE mainframe)
It isn't perfect, but pseudo 2PC works pretty well:
  • JMS transaction + JDBC
  • Compensating transaction if necessary
Here is a good write up on the topic.

Tuesday, June 13, 2006

Distributed Development Tools

I am spending a lot of my time working on tool sets lately. I have lots of biased opinions.

My biggest core requirement is distributed development with internal developers and third parties. I want it to be easy. It shouldn't take more then 1 hour for a developer in my office to get at the source code and having it building for a project managed out of another office.

I don't want to bias this (yet) with what I am looking at.

I'd love to hear what others are doing with distributed development and tools.

I am looking for the following tools (mainly):

  • Source Control
  • Defect/Issue/Enhancement tracking
  • Project management
  • Build/Deployment tool (ala CruiseConrol)
  • Requirements Analysis Tool


Huge reorg. went down at my company yesterday.

Things went well for me and the Portland office.

Reorgs cause a ton of stress. Even though it appears that I have an extremely bright future, I am totally fried. The new CIO basically took the place, shook it 11 times, and poured it out.

In all honesty, the new structure looks great on paper, but it is going to be a tough transition.

Anyway, watch this space - we will hopefully be doing a lot of hiring - I'll post opportunities here.

We will continue to work on fairly massive SOA and EDA projects and accelerating OSS adoption, contribution, and other stuff I can't talk about yet.

Monday, June 12, 2006

EDA Lessons Learned - Shared Code

See EDA Lessons Learned for the list

Sharing code between services requires careful thought and planning to avoid too much coupling between service impls. I have seen both extremes - no sharing and uber sharing (i.e., too much).

So my advice is do share code just don’t overdo it.

Some modules that I found useful (in hindsight) to share by user interfaces and various services are:

  • schema (code that validates XML against schema)
  • persistence (consistent way of accessing database)
  • msgmapper (mapping XML to POJOs that you pass into business logic)
  • domainmodel (the most important package/module that most apps don't have)
The obvious issue here is that if you don't share code, you are likely to get the same bug in all your services. To fix it, you have to fix it in each service. But when you do share code between services, then you have dependencies. You can't win. Just quit now ;)

Saturday, June 10, 2006

EDA Lessons Learned - Batch vs EDA

See EDA Lessons Learned for the list

I generally shy away from throwing down phrases like impedance mismatch as they tend to get abused, but no joke - batch and EDA is one.

We deal with this with our large systems (big iron), which are batch oriented.

Bridging the batch world with the EDA world requires careful thought and design. We found it effective to have very clear control boundaries between the two.

We have batch jobs that run in the middle of the night that generate many events. The events are not generated at the same time every night - it depends on how long the batch cycle takes. So basically the EDA side gets huge bursts of events in the middle of the night.

We see the most benefit from Staged Event Driven Architecture when batch jobs produce large bursts of events.

We also have services that want to write to the mainframe when it is in a batch run. The mainframe is unable to accept the writes when it is in this state. The "Rollback and Pause" concept is very helpful in cases like these. Basically, the service (filter in our case) just holds the event by rolling it back to the messaging layer and letting it retry at an interval. Having this logic in a filter rather then the service responsible for writing to the mainframe is good because you don't muddle the service impl. with environmental issues.

Operationally, the batch/EDA impedance mismatch is definitely our biggest challenge. It generally works, but we have our days. Async send from the batch system, clear control boundaries, "rollback and pause", and ErrorQAdmin, make it tolerable.

Tuesday, June 06, 2006

Reading Books

I'm reading a couple books.

On the advice of Sacrificial Rabbit, I picked up a book named, Getting Things Done. Now I generally do "get a lot of things done" - all by myself. But my organization systems have crashed the last few months as I am working on more and more different things all at once. I'm looking for something new and people seem to be into this so what the heck! I'll let you know how it goes.

I also picked up Charlie Wilson's War ... "The extraordinary story of how the wildest man in congress and a rogue CIA agent changed the history of our times". I'm with Don Imus ... it is "The most unbelievable book". And its true! I picked it up at O'Hare for $5. Best $5 I have spent since $.25 draft night that one time in college where things got a bit out of control.

Monday, June 05, 2006

EDA Lessons Learned - XML Aware Analysts

See EDA Lessons Learned for the list

We backed into this by accident, but our business analysts (report into IT) became very "XML Aware" (i.e., understand XML). This is a huge asset IMHO.

In a perfect world, perhaps this wouldn't be necessary, but in the real world, where projects get delayed this is very useful.

In the height of our panic (development) of the first phase of this system, we had services in varying degrees of completeness with scaffolding all over the place. The scaffolding allowed for some semblance of "end to end" testing.

Certain services were considered "code complete" by development. XML Aware testers allowed us to do black box testing against these services. Analyst started writing test cases with expected XML inputs and outputs. This was translated to XPath assertions, which, in some cases were automated (extension to XMLUnit/JUnit). The analysts invariably found defects in the code complete services. If we had waited to do traditional end to end testing, the project would have been even later.

"XML Aware" analysts had the side effect of making the analysis and design better in a major subsequent phase of the project as designers and analysts were competent in EDA style architecture and XML.

If you are lucky enough to have analysts on your team, I recommend getting them down into the weeds a bit and having them learn XML & the concepts of the architecture style you are using. If nothing else, they will ask one "dumb question" that will make you think. If you are lucky, they will start calling b.s. on you at appropriate times ;)

SOA and EDA make sense to everyone in IT from a high level. Spreading the knowledge of how they are implemented in your organization outside of the development team will result in a higher quality impl.

Thursday, June 01, 2006

Want a job in Portland, OR - Java SOA/EDA?

Want a job in Portland, OR - quite possibly the best city on the planet?

We'll even move you here if you can slang wicked code. Sorry, you must have a green card or be a US citizen.

Insurance systems are a lot more fun then you might think. We pay above market, have old school benefits and OSCON is across the street every year.

We are looking for 2 full time senior Java developers. We are starting a series of new projects where we will be doing serious bi-directional integration with an IBM i5/iSeries.

Click here to apply. Job code is 23568BR.

EDA Lessons Learned - Build and SCM

See EDA Lessons Learned for the list

Everyone's favorite topic - build and SCM ;)

SCM is a hot topic within my company right now. For whatever reason, people get very excited/emotional about this topic (myself included). After living with various SCM tools, I prefer simple ones that aren't a barrier to distributed development. I actually used to like ClearCase - a lot. But now I think that it is overly complex and is a barrier to distributed development. ClearCase absolutely must be installed on a LAN for it to work - this forces a replication model for distributed development. This results in too much complexity for my taste and makes it very difficult to truly collaborate at the code level. There are OSS and commercial SCM products that were designed from the ground up to facilitate distributed development. Pick one of them if your developers are all over the world.

These lessons learned are from a large EDA style application, but like many of my lessons learned, it is applicable to a SOA project or any large integration project. I do not (yet) have an approach for company-wide SCM for SOA/EDA. That is certainly more complicated.

I knew a lot of this stuff from previous jobs, but walked into this project as it was in full development. It took *significant* effort to reorganize and fix. Like many things, planning from the beginning would have saved a ton of effort. Here is a list:

  1. Plan the SCM repository carefully

    Don't have too many roots - don't have too few roots. Under the root, service, shared, web directories with modules beneath works well for us.

  2. Branching model

    Choose carefully - here is a good article on branching models. I prefer "branch by purpose" - it keeps it as "simple as possible, but not simpler" as my boy A. Einstein would say.

  3. Keep build simple
    • Developer should be able to run entire build locally easily
    • Developer should be able to build just required modules (i.e., shouldn’t have to run entire thing if just working on 1 service)
    • Developer should be able to make changes to the build (avoid single threading it through the build guy)
  4. Deploy beefy build box

    Buy a nice high end workstation with plenty of memory and 2 very fast processors for a build box. You don't want the build to run on the build guy's local machine. It is much easier to automate from a centralized official build box IMHO. Anyone with access should be able SSH to the build box and launch a build. At a previous job, we even had a web page that allowed developers to launch builds (way to go Sarge)

  5. Write and maintain simple instructions to get new developer’s environment setup
    Shouldn’t take more then an hour
  6. Configuration

    Either keep config files for each environment (e.g., dev, test, prod) under source control and have deploy script use appropriate configs or script the setup of each environment. You don't want to do this by hand. This can be difficult with vendor products that want to invade your entire SDLC. Ensure that your vendors have deployment friendly support

  7. Avoid Maven

    I am not up to speed on the latest version of Maven. I understand it is supposed to be better so take this with a grain of salt. At one point we had competing builds - Ant and Maven. Ant won because it is simpler and more people understand it well. We do use the Maven directory structure, however. I'll leave it at that.

  8. Don't mandate a particular IDE

    Quickest way to piss off developers is to mandate an IDE. The build should never mandate an IDE.

  9. Beware of tools that generate code

    If you must use these tools, at least either check in the results of the generated code (can be very dangerous if the code isn't just POJO style) or script the usage of the tool in the build (and watch your developers start to hate the build). And people wonder why I hate generated code ;).