Loosely Coupled

We're getting close to (finally) deploying our JCAPS rewrite to production. Our final task is to load test and "tune" the application - making sure it will handle the expected production transaction load. Prior to executing the load test, we added logging statements to report on the amount of processing time spent in each JCD (or processing unit for those non-JCAPpers out there). Using this info, we can determine the slow running processes and optimize them. For this optimization we could follow a traditional approach and profile the code, or we could take an easier route and configure JCAPS to throw more resources at the bottlenecks. This second option is done in the JCAPS connectivity map by increasing the maximum number of threads allocated to run the process. Clicking the input line to the JCD to open the properties, you can set the "Server session pool size" in the Advanced tab (NOTE: this setting is only for JCDs listening to JMS queues or topics). I&

Contractors - programming contractors, general home contractors like builders, plumbers or electricians, and even mechanics - have bad reputations. While everyone needs these skilled professionals to complete work where they have little expertise, there an inherent distrust in these relationships. Distrust - where total trust is needed. Many times it's unwarranted because contractors are as honest and hard working as anyone else. So why is it so? I think a number or relatively minor, easily correctable behaviors lead to this perception. Personally, I have changed mechanics more than I care to comment on. Not because I felt they were screwing me necessarily, but mostly because they didn't explain the work they were performing to my satisfaction. This led me to doubt their abilities. The doubt and distrust lead me to look for another mechanic who I have more confidence in. It's too bad. I hate shopping around for new mechanics. At home, we recently added a room to ou

I'm the type of person who constantly looks for ways to improve. No matter how well things go, I'm always striving to "plus" an experience - smooth out the rougher edges to make the next time even better. Sometimes the need to do this drives me a little nuts. It drives my wife really nuts! When things don't go well, this task can be a little overwhelming (and depressing). There are so many areas for improvement, it's hard to know where to begin. I've spent the last year or so, reexamining my software development experience - looking for trends in the tools and ideas that helped the teams I was on to be highly productive (and conversely where the lack of some practices led to a lack of productivity and frustration). Combined with many of the things I've read by Spolsky , Fowler , and the Poppendiecks . I've created a list of criteria I'd consider essential in an ideal software development environment. Talk to the target user

I haven't been doing too much development as I wait (and wait and wait) for our acceptance testing to complete. Here's a quick rundown of what I've been thinking about while waiting for that to complete.... I've been reading and participating in some of the discussions on StackOverflow . It's a great way to get a pulse on what others are thinking about and working on. I've also been able to pick up some things I never knew existed before. I've taken part in other question and answer type sites before and I had my doubts how helpful this would really be... I've been pleasantly surprised. I listened to these great podcasts on alternative energy. Grass as fuel?? Pretty cool. I've been thinking about maybe getting some solar panels for my house. I would never have thought that the Northeast would be a good place for these until I saw a cool episode of Nova sometime back where someone in Mass. had some installed on their house. Now maybe I'