SpringSource travesty!

Or Not? It Depends! There was a lot of speculation and outcry at the initial announcement. Just read theserverside fireside chat. Both Rod Johnson and Mark Brewer from SpringSource dropped by to provide some explanation. I am still hungry for explicit details.

1. How IP of the enterprise supported changes be handled or if there will be a difference at all?
2. Will there be tags made as point releases are made to the paying customers? I would really, really, really hate to go off the trunk only.
   
3. How transparent will the changes made to support paying customer be? Will there be a jira link, release notes, some sort of description of the change? That would be crucial when building of the trunk. Personally I do not have bandwidth to monitor FishEye.

I do not think that this is a sell out by SpringSource but I am biased. I have spent the last 5 years using Spring Framework. Now I can hardly write an "enterprise" app of any size without it. I got lazy about looking for an alternative because Spring is so damn good.

I am yet to see a huge issue with announcement outside of inconvenience. Most of the customers that I work with pick a version and stick with it for a while. Lets say they have 2.5.2 and it will take an act of deity to move them to 2.5.5 unless it it the next major internal release.

So lets wait and see. If SpringSource does pull an Ext, there is a solid foundation that can still be forked and developed by the community. I really hope it will never come to that.

Further reading:

1. SpringSource manifesto
2. Rod on Open Source contibutors
3. Rod on Enterprise Open Source (Presentaton Slides from Emerging Technology for Enterprise Conference 2007)
4. Craig Walls thoughts
   

Quick thought on Google BigTable

We just had one of the internal geek fests at my much heralded employer. Eric presented on Google App engine. Very interesting. One observation that I came away on BigTable and transactions through data store api. That is ALL of the entities that you want persisted in transaction in AppEngine must belong to the same Entity Group.
Translate that to Java and DDD -> Aggregate Roots. The root entity could be an aggregate root and should be persisted as a whole. Interesting way to partition data. Have to play with Python and AppEngine.

So why "It Depends™"?

What's in the name? Let me start with a story.

I once worked for a client. You know the type. The one with huge "NIH" (not invented here) syndrome. The one where "open source" is a curse word. Thankfully there are a number of very bright and gifted people working there trying to bring about a change. But no matter how great those folks are, the story is not about them.

While there, we were looking into introducing Spring Framework as a back bone of future architecture. Every one who worked with Spring knows that there are number of ways of doing anything with it. Fried, broiled, baked, shaken, not stirred... After a while I had a standard response to each question that client asked: "It Depends...". My coworker, very funny guy by the way, soon added a "TM" to the phrase and mentioned that all usage of the phrase cost 10c payable immediately.

So that is the story. But that got me thinking. And the thought was: There isn't a golden hammer in software engineering. And this engineering thing is a big misnomer. Working with software is more like art vs. production line and model T. There are no preset measurements on parts. No stringent requirements. "This procedure must be completed in 101.23 lines of code". There is a final product that should do X. And how it does it - who cares!!! End user does not. As long as it does what the user wanted, performs well, delivered on time. It must be maintainable and bug free to be viable as a product going forward. That is where art comes in and "It Depends™" takes root.

How to solve a problem always depends on the context of a problem and surrounding problem domain. Who in the right mind would use a JSF + WebSphere Portal + DB to display a static html page? But some companies do that, because that is the stack they use for web based deployments. There are tons such examples out there. No need to look further than last project you or I worked on. Oh do I have some stories to tell about those :) Maybe next time.

Hello World!

I guess I should start with an introduction and a reason for you, dear reader to stop by back here and read the musing of another deranged blogger with Pinky and Brain aspirations.  So here we go.

Hello and Welcome!

My name is Dmitry Sklyut and I am a software developer/architect living a peaceful life in suburban Philadelphia.  I work here (and just in case:  "The opinions expressed on this blog represent my own and not those of my employer unless specifically stated in section 42 of ...” You get the picture...).  I work mostly with Java since around 1999, but was paid to write PowerBuilder (Remember Data Window??? Sight...) and MUMPS (don't ask) among other more standard things.

I am very into Spring Framework for its simplicity and productivity gains.  Been using it since version 1.1.  I like and use a lot of other open source technologies from Hibernate to Tomcat.  Lately I got very interested in OSGi.  Mostly for its ability to build modular applications and secondly for the deployment aspects.  On my plate is a shelf full of books to read, languages to learn and technologies to explore.

I did start writing a blog a while back but that went by the way of Dodo Bird.  This is my second attempt of providing some consistency to the endeavor.   This attempt has been triggered by my last project and I will blog about it later.

What type of content can you expect?  Technical, computery, and programy type of a stuff.  I will try to minimize the rambling.  Politics will not be discussed here, except in context of where to put the brackets in the code :)

So welcome again and stay tuned.