Technology Director, Perficient, Inc. (PRFT)
Ken Sipe is a Technology Director with Perficient, Inc. (PRFT), IBM's largest service partner, where he leads multiple teams in the development of solutions in the SOA, Web 2.0 and portal domains, on both the Java and .Net platforms.Ken was the founder of CodeMentor, where he was the Chief Architect and Mentor, leading clients in the execution of RUP and Agile methodologies in the delivery of software solutions. He is a former trainer for Rational in OOAD and RUP, and a CORBA Visibroker trainer for Borland. He continues to enjoy providing training and mentoring in all aspects of software development.
Ken has a deep need to be highly diversified. Ken often works with IT executives on high-level strategic roadmaps, currently geared around service oriented architectures (SOA). Ken also likes to keep his hands "dirty" in the code, which has him on a regular basis, pairing or otherwise producing code. Ken is regularly requested by clients that know him to "rescue" projects, either through the streamlining of processes or the rapid production of code.
Ken is a certified JBoss developer and is a frequent participates on open source projects. Ken is currently interested in the growing maturity of SOA solutions in the open source space, such as the ESB solutions like ServiceMix and Mule, or rules engines such as JBossRules.
Ken's Thoughts
Wednesday, May 14, 2008
JSR-286 has been signed off! Here comes Portal 2. I don't know of any implementations yet... so we are still waiting to play with it.
Portal 1 Challenges
There are a number of pain points of portal development which include:
What's new in Portal 2
First, Portlet to portlet communication is not as cumbersome and isn't limited to some session hacking. The specification provides 2 mechanisms for communication at the server tier.
Second, resources are finally part of the picture. In the portal 1 days, you would often need to access a resource outside the portlet... well this request didn't have any portlet details, such as window state or portlet perferences and worse... it didn't run under the security of the portal.
Now resources are obtainable within the context of the portal. To a certain extent this provides us now with the ability to do ajax style development which wasn't possible before.
Next, there is the standard web page needs which have been addressed. For instance, because a portlet doesn't own the page, it really can't participate in provide header information... until now. There are multiple respond phases now... one for the header and one for markup. This provides the ability for a portlet to participate in the creation of the page header. Additionally access to cookies and other web oriented needs have been opened up.
On top of this their are portlet filters and portlet url listeners...
If it is not too late... the portal world is about to get a breath of fresh air. Take a look at the specification, it is worth a look if you are in this space. Perhaps when the reference implementation is out... and I have time I'll create a demo of a few things... of course I'll need to include some of the latest spring stuff in the mix. It looks like Spring 3.0 intends to have Portal 2.0 support. As I scan around on the web... it looks like liferay is portal 2 ready... maybe it is time to switch back :)
Portal 1 Challenges
There are a number of pain points of portal development which include:
- Accessing resources... this is an issue with security mainly
- Portlet to portlet communication through the server framework
- Ajax communication.
What's new in Portal 2
First, Portlet to portlet communication is not as cumbersome and isn't limited to some session hacking. The specification provides 2 mechanisms for communication at the server tier.
- Events
- Public Parameters
Second, resources are finally part of the picture. In the portal 1 days, you would often need to access a resource outside the portlet... well this request didn't have any portlet details, such as window state or portlet perferences and worse... it didn't run under the security of the portal.
Now resources are obtainable within the context of the portal. To a certain extent this provides us now with the ability to do ajax style development which wasn't possible before.
Next, there is the standard web page needs which have been addressed. For instance, because a portlet doesn't own the page, it really can't participate in provide header information... until now. There are multiple respond phases now... one for the header and one for markup. This provides the ability for a portlet to participate in the creation of the page header. Additionally access to cookies and other web oriented needs have been opened up.
On top of this their are portlet filters and portlet url listeners...
If it is not too late... the portal world is about to get a breath of fresh air. Take a look at the specification, it is worth a look if you are in this space. Perhaps when the reference implementation is out... and I have time I'll create a demo of a few things... of course I'll need to include some of the latest spring stuff in the mix. It looks like Spring 3.0 intends to have Portal 2.0 support. As I scan around on the web... it looks like liferay is portal 2 ready... maybe it is time to switch back :)
Wednesday, May 14, 2008
My daughters and I have a phrase we've picked up from some where... probably a movie, but I don't remember which one, which is "you don't even know, you don't even know". We use it liberally to describe a situation where people are talking about stuff they clearly know nothing about, yet they are sharing their opinion about it anyway. It seems strange that this happens... and frankly it happens all the time.
So while speaking in Denver between sessions I attended a great session by Jared Richardson. We got into a discussion on developer perceptions on agile practices such as pair programming, etc. When it occurred to me that this was it... so often developers dislike pairing when they haven't practiced it. They claim they don't have time to write unit test or integration tests... but they haven't attempted it.
It appears that Agile in some circles is getting a bad name... but most of the time it is based on the opinions of someone who thinks they know what the outcome will be... they have thought it through in their head and have come to a conclusion, which has become their opinion on the matter. Sometimes this is further justified through their comments "well I heard that so and so had issues... blah...blah". Sometimes it comes in the early onslaught of pain... either it is new, or their some affect of team storming. The reality is that often new agile teams run a little slower upfront, but end up significantly ahead of non-agile teams. The pain is worth it! (at least from my experience)
So as a community let's make an agreement. If you ain't done it, you can have an opinion... but it doesn't count :) If you think it won't work or if you heard it won't work... you don't even know what you don't even know!
Knowing comes through experience! and as GI Joe says "Knowing is half the battle".
So while speaking in Denver between sessions I attended a great session by Jared Richardson. We got into a discussion on developer perceptions on agile practices such as pair programming, etc. When it occurred to me that this was it... so often developers dislike pairing when they haven't practiced it. They claim they don't have time to write unit test or integration tests... but they haven't attempted it.
It appears that Agile in some circles is getting a bad name... but most of the time it is based on the opinions of someone who thinks they know what the outcome will be... they have thought it through in their head and have come to a conclusion, which has become their opinion on the matter. Sometimes this is further justified through their comments "well I heard that so and so had issues... blah...blah". Sometimes it comes in the early onslaught of pain... either it is new, or their some affect of team storming. The reality is that often new agile teams run a little slower upfront, but end up significantly ahead of non-agile teams. The pain is worth it! (at least from my experience)
So as a community let's make an agreement. If you ain't done it, you can have an opinion... but it doesn't count :) If you think it won't work or if you heard it won't work... you don't even know what you don't even know!
Knowing comes through experience! and as GI Joe says "Knowing is half the battle".
Wednesday, May 14, 2008
Well I will be speak this year at OSCON on July 25, 2008 speaking on Spring 2.5 . It will be fun to see how I take my 1:30 hour talk which I usually run over time on and deliver it in :45 mins.
Friday, April 25, 2008
I mentioned earlier that I would blog on this subject from my India trip. So I had a very unusual situation in Bangalore. One of the attendees (Madhu) who attended the Jax conference requested that I visit his company during my stay in Bangalore. This became difficult based on a number of reasons, which resulted in Madhu and 10 of his co-workers coming to my hotel. The lobby was too noisy, so we ended up upstairs in my hotel room. The picture below is just half of us that are sitting around a bed talking tech.

We discussed a number of technical details... it started with a discussion around ORM tools and the problem they had mapping to a complex and highly normalized data store. They were creating a web admin tool which for simplicity sake I'll characterize as a content management system (CMS). In this space they don't know all the "columns" of data to store. The columns or metadata is stored in a row of a table, then there is an association table which associates the column to a 3rd table, the table of values. They didn't have to get to far in the description for me to know exactly what they were talking about. I have seen it before a number of times... it is the kind of thing a really out of touch architect, or a green DBA would suggest. I shared some horror stories of my past to try to sway them from this approach. I then discussed all the negatives to this approach.. such as:
While I was speaking at JAX on the topic of Spring and JPA, an attendee reflected on Ted Newark's article relating ORM to Viet Nam. I was amazed!! People around the world are reading Ted's Blog...
So as we were sitting around the bed discussing alternatives, I mention Ted's article which I just re-read that week ... of course I had to explain a little history regarding the meaning that Viet Nam has for most Americans. We got to the point were I was describing how a project gets so far done the road and the team has invested so much, that when anyone suggests that we are tapped out and need to rethink the projects technical approach management comes in with statements like "Come on guys, we have so much invested. Can't you just get it to work". At this point they were all smiling, looking at each other and someone spoke up and says that is exactly where we are at... to which I said "Welcome to Viet Nam" :)

We discussed a number of technical details... it started with a discussion around ORM tools and the problem they had mapping to a complex and highly normalized data store. They were creating a web admin tool which for simplicity sake I'll characterize as a content management system (CMS). In this space they don't know all the "columns" of data to store. The columns or metadata is stored in a row of a table, then there is an association table which associates the column to a 3rd table, the table of values. They didn't have to get to far in the description for me to know exactly what they were talking about. I have seen it before a number of times... it is the kind of thing a really out of touch architect, or a green DBA would suggest. I shared some horror stories of my past to try to sway them from this approach. I then discussed all the negatives to this approach.. such as:
- No indexing
- No join capabilities
- Very complex queries
- Did I mention no indices? This data structure just isn't tunable.
While I was speaking at JAX on the topic of Spring and JPA, an attendee reflected on Ted Newark's article relating ORM to Viet Nam. I was amazed!! People around the world are reading Ted's Blog...
So as we were sitting around the bed discussing alternatives, I mention Ted's article which I just re-read that week ... of course I had to explain a little history regarding the meaning that Viet Nam has for most Americans. We got to the point were I was describing how a project gets so far done the road and the team has invested so much, that when anyone suggests that we are tapped out and need to rethink the projects technical approach management comes in with statements like "Come on guys, we have so much invested. Can't you just get it to work". At this point they were all smiling, looking at each other and someone spoke up and says that is exactly where we are at... to which I said "Welcome to Viet Nam" :)
Thursday, April 17, 2008
I will be speaking on Spring 2.5 at OSCON 2008 this year! The next tid bit of fun will be fitting my 1 1/2 hour talk into a :45 minute talk... should be fun.