Successfully Adopting Pair Programming

In 3.5 years as a consultant I spent more time talking (with clients) about pair programming than any other topic. In general, client developers had never properly paired and had no desire to do so. To make matters worse, the business predominantly thought two developers on one machine was a waste.

Despite the prejudices, usually by the time we left a client the business and developers had become pro-pairing.

Successfully adopting pair programming can be hard, but it's also entirely possible if you leverage the lessons I've learned.

This article assumes you have done some pairing and are looking to help your organization adopt pairing where it makes sense. The advice can be helpful for people in various roles; however, it is written mostly for developers or team leads looking to introduce pair programming to their teams.

This article makes no attempt to address whether you should or should not be pairing. There are benefits and drawbacks to pair programming (like most things), and I think there is already decent information available covering that topic. Discussing the pros and cons of pairing would take away from the focus of this article: If you already believe in pair programming, how can you successfully introduce it to your team?

read article at : http://www.infoq.com/articles/adopting-pair-programming

Remote Lazy Loading in Hibernate

Lazy loading in Hibernate means fetching and loading the data, only when it is needed, from a persistent storage like a database. Lazy loading improves the performance of data fetching and significantly reduces the memory footprint.

When Hibernate initializes the data object, actually it creates a reference (of the data) to the data object and doesn't load the data as such. Hibernate then intercepts the method calls to this reference and loads the actual data. In order to intercept and load the data, Hibernate requires the data object be associated with a Hibernate Session.

Problems might arise when these "lazy loaded" data objects (containing the reference) are transferred to other application layers, especially to remote client. These objects get serialized/de-serialized on their way to the remote client and there by detaching itself from the Hibernate Session. Accessing this detached reference will always lead to some exception.

What if these lazy loaded objects can still maintain their references even at the remote client layer (where there is no Hibernate Session) and still be able to lazy load data? This is quite possible and this concept of lazy loading data even from a remote client is called remote lazy loading.

In this article we'll discuss the solution by extending Hibernate's lazy loading framework. We'll use 3.2.x version of Hibernate library.

countinue here : http://www.theserverside.com/tt/articles/article.tss?l=RemoteLazyLoadinginHibernate

Prime guidelines for Test Driving

• Do. Not. Skip. Refactoring.
  
• Get to green fast.
• Slow down after a mistake.

Let’s go through these guidelines one by one, examining what makes them so
important that they made it to our short list.

Do. Not. Skip. Refactoring.

If you haven’t yet considered tattooing the word refactor on the back of both your hands, now would be a good time to do that. And I’m only half joking. The single biggest problem I’ve witnessed after watching dozens of teams take their first steps in test-driven development is insufficient refactoring.

Not refactoring mercilessly and leaving duplication in the code base is about
the closest thing to attaching a time bomb to your chair. Unfortunately, we are
good at remembering the “test” and “code” steps of the TDD cycle and extremely proficient at neglecting a code smell that screams for the missing step.

Thus, I urge you to pay attention to not skipping refactoring. If you have some-
one to pair with, do so. Crosscheck with your programming buddy to spot any
duplication you may have missed. Bring Fowler’s Refactoring book with you to the toilet. Learn to use your IDE’s automated refactorings. It’s good for you, the doctor said so!

I apologize if I’m being too patronizing, but following the TDD cycle all the
way is important. Now that we’ve got that in check, there are two more guidelines for us to go through. The first of them relates to the code step of the TDD cycle get to green fast. Let’s talk about that.

Get to green fast

As we test-drive, we’re basically aiming for the simplest design we can think of for the problem at hand. We don’t, however, go for the simplest design right off the bat in the code step. Instead, we should strive to get back to green fast. The code step is where we get to that green bar with as few edits as possible. The refactoring step is where we perfect our design.
You might want to read the previous paragraph out loud. Don’t worry about
others looking at you like you’re a freak. You’re just pointing out facts.
Speaking of facts, it’s more than likely that you will make one or two mistakes
in your career even after adopting TDD. Our third guideline tells us to slow down once the proverbial smelly substance hits the fan.

Slow down after a mistake

It is common for developers practicing TDD to start taking slightly bigger and bigger steps as time goes by. At some point, however, we’ll take too big a bite off our test list and end up reverting our changes. At these points, we should realize that the steps we’re taking are too big compared to our ability to understand the needed changes to our implementation. We need to realize that we must tighten our play. Small steps. Merciless refactoring. It’s that simple. Walking to the water cooler might not be a bad idea either.

These guidelines are certainly not a complete reference to successful test-
driving. Practices and guidelines don’t create success. People do. Having said
that, I hope they will help you find your way to working more productively and
to avoiding some of the pitfalls I’ve seen many people stumble into as beginning TDD’ers.

read more : http://www.manning.com/koskela/