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.

Patent Tactic

I like this tactic against patent liars.

I would refer these software engineers to IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices.

Perhaps a more prominent website of names, links to prior art, claimed patent is a good idea?

Depending where the OSS patent fight goes, this may be a necessary tactic.

Update 29-JAN-2007 Via Simon Phipps look like this has been fixed. Yay. Also, looks like there is an EFF Patent Busting project. Haven't looked very closely at it, but looks like what I was blathering about. This + blogs is probably plenty.

Yet another example of why blogs are great IMHO. When every body has a printing press the walls start falling down. Yay.

Perhaps I overestimated?

Even though the writing has been on the wall for years on WS-*, I predicted that it would take another 2 years before the industry echo chamber acknowledged this.

Is a Gartner Group VP (Nick Gall) a good enough shot across the bow? To many people, Gartner is a fairly credible information source.

Or maybe they are like Burton Group where they have some analysts that love it and some that hate it so in the end it is a wash (no offense Pete)?

I can only hope that this is the card that starts the house of cards falling down.

Via Bill de hOra

Update Saw this over on Simon Phipps. Obviously over the top - too funny though. Gartner certainly won't think this is true. I will have to defer to the Enterprise Architecture: Thought Leader on this topic. BTW that is a pure bold blog name ;).

I think analysts play an important role in the industry. I do think that you have to be a free thinker though and take what they say (and what anyone else says - especially me!) with a grain of salt. And who can honestly argue that transparency is a bad thing?

Best TheServerSide Post EVER

This is the best TheServerSide post/thread I have ever seen. I have been reading TheServerSide for years and years. Not as much the last couple of years, but I still check in on it 1x ever couple weeks or so.

On a side note, we spoke with Cameron Purdy briefly today. We really wanted to tell him that we were looking at NCache, but I didn't have the guts.

I did, however, open and close the call with "peace". I just couldn't resist. I'm sure he gets that a lot - oh well, he made his choices on that a long time ago ;)

Blog Arrival

Well, it appears that my blog "has arrived".

I have many more readers then I had 1 year ago.

I must have hit some threshold where I am worthy of being blog spammed.

I'll drink (my delicious cappuccino made with delightful Luccaffe espresso) to that.

But it is pretty annoying. I will hold out on moderating until the spam reaches an unbearable threshold.

Software Architecture - Zoom In Zoom Out

We have been very busy designing and skeleton-ing out a large system.

It is difficult because there are so many components, so many services to integrate with, and so many potential knobs to turn. This is not a web app and a database. This is a biggin. Getting the partitioning in the right places is crucial.

When I am in the details I panic that I can't see the forest from the trees.

When I am at 20,000 feet, I panic because modeling and hand-waving doesn't cut it.

The only solution of course is to alternate between zooming in and out like this until you are done.

I got a third of the way through my Masters of Software Engineering at OMSE before I "paused" to join an OSS ESB startup (now defunct). I learned a couple of things there - one topic that I retained and applied is Views.

I went back to this today because I had the "too much detail panic". I came across and ordered Software Systems Architecture which looks quite good. Take a gander at the Quick Reference Card (requires you to give up an email address).

I like the looks of it because it builds on the "views" concept and gives some more detail (i.e., perspectives). Anyway, unless someone comes up with a better idea, I will just create the hierarchy with the viewpoints and perspectives in our wiki and then I think I will feel better zooming in and out as I will have some structure and cross reference. Perhaps it will start to become paint by numbers at some point.

Let me know if you have other ideas.

So I'm not a courier - SO WHAT!?!?

Portland is a bike town. It wins awards for bike friendliness and what not.

There are also lots of couriers. Lots of them are rather insane and ride on their tricked out fixed gear bikes. These things are sexy bikes - flat out. You have to be either stupid or have insanely strong legs to be able to ride one of these things.

Anyways, as I consistently note, I am wershed up. These dudes aren't. They are cool - Portland gromit cool. If I was cool again, I'd be one of these dudes.

They also have tricked out back packs - you know the kind - all messengered out.

So as you know, I walk to work - it rocks. I recently bought a tricked out messenger bag. It's orange, ginormous and pure bold. And it is water PROOF not water resistent (when you live in Portland, you care about these things).

If you aren't pure bold enough for a messenger bag they have all sorts of other not messing around bags that may be to your liking.

This will conclude the 2007 Portland Snow blog series. I will return to tech blather next time.

Snow results in Chili. Chili results in Hot Sauce. Hot Sauce Results in . . .

Alright so I'm a B-player on hot sauce tolerance, but I still like it.

You need to try this particular hot sauce and you don't have to be some sort of hot sauce meat head to like it.

Marie Sharp - Belize. The one I have is the "Habanero Pepper Sauce - HOT". It is a mix of carrots and habanero and it is delightful.

I oddly had chili with lunch that was average to poor. My beautiful wife then happened to make chili for dinner that was good to delicious. I added some of this sauce to it and it became delightful.

I got a tip on this sauce from the best butcher in Portland a few years ago and am on my third bottle.

Walking to work in the snow in Portland

It snowed a whopping 4-5 inches in Portland yesterday from 5-8 AM.

In a city that does not have many snow plows, this is a problem.

Luckily for me, I walk to work so it was no problem.

Our office shut down at 12:30 PM - this was nice I was able to get things done. The problem with snow days in corporate America is that none of the deadlines move.

I grew up in Michigan - it took over a foot of snow to make anyone even think of shutting school down etc.

I was blathering about this to my co-workers when Ed pointed out that I now get cold when it is less than 50 degrees. In true Portland form, I wear a ski hat if it is less than 50 degrees. And sometimes when it is over 60 degrees. I guess 6 years in Portland has an affect on you. I wish I could say "You can take the boy out of the Midwest, but not the Midwest out of the boy". Or something like that. But at least on this front, it appears that I am being assimilated. Oh well.

SOAP over JMS

Hey, looks like SOAP really does work over any protocol. Well over JMS anyway (not really a protocol). Saw this here and here. I'm sure all of these vendors (I know Sonic does) provide their own proprietary SOAP to JMS mapping. I suppose there is some value in them mapping it the same way.

The chances of me using this? Zero.

With SonicMQ, however, I have happily used their RESTish HTTP Adapter that just maps destination names into the URL & looks for HTTP Headers for any messaging specifics. Want to check for a message? Check the response queue via a different HTTP GET. Certainly not perfect, but can be useful when working with a technology that does not have a richer client available.

I took a quick scan of this document & remembered a Tim Bray post from last year.

I guess I won’t offer any further commentary on the contents of this document. I can’t help but feel for the H/I/I/M staff who are going to have to do the work, and am reminded of Fritz Lang’s immortal Metropolis, where Maria says: “Nobody cared about the slaves who died laboring to raise the Tower of Babel.”

Not sure if they already are (don't see any of their names listed), but it would be nice if these vendors got involved in AMQP. That seems to have some promise.

Why AMQP? Though many networking protocol needs have been addressed, a large gap exists in common guaranteed-delivery messaging middleware. AMQP fills that gap...

What is AMQP? AMQP enables complete interoperability for messaging middleware, both the networking protocol and the semantics of broker services are defined in AMQP.

AMQP Model The AMQP model explicitly defines the server's semantics because interoperability demands the same semantics for any server implementation.

Wire-level Format To enable technology-neutral interoperability, AMQP defines an efficient wire-level format with modern features.

Distributed Caching != JavaSpaces

I have been talking about distributing caching and JavaSpaces lately.

While you can use JavaSpaces as a caching technology because a JavaSpace keeps stateful objects (Entries) in memory and can be persistent (i.e., survive a failure), it isn't necessarily the best alternative.

Conversely, while you could use a distributed cache as a service orchestration engine because it has an eventing model in it & you could hack master/worker on top of it, it probably isn't the best choice.

The combination of a good distributed cache and a good JavaSpaces implementation, however, may be a good combination.

There certainly is overlap & you have to be fairly deliberate in figuring out which tool you want to use for certain things, but it seems achievable.

A distributed cache is likely the best place to store reference data, hard to query data (e.g., from a mainframe), user session data, etc. where a JavaSpace is probably the best place to store transient conversational service state.

It is the combination of these technologies that allows you to avoid the dreaded work in process database.

More importantly, both technologies use Java POJOs rather then XML so you can avoid a lot of mapping complexity (certainly not all) within the core of a large application.

Anyway, I still have a lot to learn, but am beginning to settle on this distinction.

Mobile Code vs. Mobile Data

As I am trying to learn more about Jini and specifically mobile code, I came across this blog post at discipline and punish.

For almost a decade now we've been steadily marching towards mobile data. For many, distributed computing is summed up by the motto: it's just data. But it's interesting to note that, with the (re)(re)emergence of Grid Computing, mobile code is poised to make a comeback. While mobile data allows for a lot of dynamicity in the consumer-side, it's mobile code that lets you deal with major dynamicity on the service-side. When you have dozens (or hundreds, or thousands) of nodes constantly coming and going then highly mobile services really start to pay off. The JINI guys are certainly on to something and question of which approach scales better is far from settled. I suspect in the future we'll rely heavily on both distributed computing styles.

Sounds about right.

Also Dan Creswell is helping to educate me - thanks Dan!

JavaSpaces sans Jini

Apologies to my new Jini friends. I am a neophyte.

I work with and have spoken with a number of people who say things like, "I LOVE the concept of JavaSpaces - I just don't want to bring all of Jini with it".

What they are really saying is they love JavaSpaces - TupleSpaces really, they just can't stomach the mobile code bit. These are not stupid people. Honestly, this includes me a lot of the time.

Most of these people lived through J2EE and wouldn't bet their job on auto-deployment of a .war file or .ear file work - why should we think something more complex (downloading the code) will not result in panic? I remember talking to BEA about their auto-deployment - some engineer said they had something like a 120 page spec on this functionality alone (and it still didn't work).

I could just send Dan Creswell an email, but I've heard this comment so often that I figured I would put it out here for all to see. I'm sure this topic has been discussed before - thing is it still is being discussed.

Dan, others, are we neophyte's just wimps for fearing mobile code?

How hard would it be to de-Jini JavaSpaces?

Is this completely out of the question, stupid, etc.?

For JavaSpaces to see a lot of mainstream usage 1 of 2 things needs to happen IMHO:

1. Educate the neophytes on the power of mobile code. Help them not fear it. Help them to convince their infrastructure and security groups that it is viable
2. Create a JavaSpaces sans Jini (really sans mobile code) version

Update 07-JAN-06 PM - I'm hoping that at the very least some education can occur via this post for me and other Jini neophytes. So I started this wiki page at jini.org.

Simplicity & Integrating with Less Code

I have been on a distributed caching & JavaSpaces kick lately due to the reasons listened here.

I was talking to my co-worker Erik yesterday and we concurred that one of our biggest goals is to come up with an architecture that is as simple as possible and requires the least amount of code.

Coming from my experience with SOA of various flavors and EDA, I have been on many projects that wrote way too much code. The more code the more defects. This is what is so appealing to me about JavaSpaces and potentially distributed caching (e.g., memcached, Tangosol Coherence) (or some of both). In the core of an application it is possible to use these layers as your service orchestration tier as well as your transient data store. This is very appealing as you skip a significant amount of OR and OX mapping which saves heaps of time and defects.

The JavaSpaces API itself is extremely seductive. Lifted from here:

• write: Places one copy of an entry into a space. If called multiple times with the same entry, then multiple copies of the entry are written into the space.
• read: Takes an entry that is used as a template and returns a copy of an object in the space that matches the template. If no matching objects are in the space, then read may wait a user-specified amount of time until a matching entry arrives in the space.
• take: Works like read, except that the matching entry is removed from the space and returned as the result of the take.
• notify: Takes a template and an object and asks the space to notify the object whenever entries that match the template are added to the space. This notification mechanism, which is built on Jini's distributed event model, is useful when you want to interact with a space using a reactive style of programming.
• snapshot: Provides a method of minimizing the serialization that occurs whenever entries or templates are used; you can use snapshot to optimize certain entry usage patterns in your applications. We will cover this method in detail in a later article.

With the addition of JavaSpaces05, there is collection based (i.e., bulk) read, take, and write.

The integration patterns possible with this API are very powerful. Master/Worker, distributed, highly scalable data structures, etc.

It appears that with certain distributed caching vendors, you can achieve some semblence of these patterns, although I am not convinced of that yet, and the associative nature of JavaSpaces (i.e., you use templates containing objects with what you are looking for in a space to find it) is just amazingly seductive.

Love it or hate it, JavaSpaces comes with Jini. To a newbie like myself, Jini takes some getting used to. The whole mobile code bit tends to make people who have lived through J2EE classloader hell nervous. But there are those who say it works fine in Jini. It is a different paradigm and this makes people very nervous.

Maybe what is needed is a mix of J2EE (specifically servlet, JMS, JMX MBeans), distributed caching, and JavaSpaces. Maybe you can use JavaSpaces for both caching and service orchestration. Maybe you should use all of Jini. Maybe there is something else.

From previous lessons learned around persistence in EDA, I am 100% convinced that we need some sort of flexible transient data store (no work in progress database - I beg you!). I see that today as being some form of a persistent distributed cache that requires very little if any mapping code. I also have seen the power of asynchronous integration and SEDA and am not about to give up on it. JavaSpaces and Master/Worker appear to give me that. What other ways are there? Maybe things that I would have considered anathema a year ago like sending objects through JMS for the eventing layer isn't really that awful? I do know that I do not want XML at the core of a brand new system again - again way too many defects with mapping etc. Too slow, too lame. Sure, at the periphery to integrate with services that require it, but never again in the core of the system.

Lots of thinking results in lots of blather . . .

Bottom line, I want this to be as simple as it can be and I want to write as little code as possible. Oh and it should scale like the dickens, be simple to specialize, maintain, etc.