An update on Java Persistence API 2.0

The Java™ Persistence API (JPA) was first introduced in Java Platform Enterprise Edition (Java EE) 5 as part of the Enterprise JavaBean™ (EJB) 3.0 family of specifications Since that time, JPA 1.0 has proven to be a very popular persistence framework. Even though this first specification was very complete and functional, there is always room for improvement. The next iteration of the JPA specification (JPA 2.0) is currently under development via JSR 317.

The JPA expert group is working hard to finalize the JPA 2.0 specification. Public Final Draft #2 of the specification was recently made available, and the final JPA 2.0 specification is planned to be available by November 16, 2009.

A single Comment Line column cannot do justice to all the new features in the JPA 2.0 specification. Instead, brief introductions will be made via this article followed by information to help you go experience these features firsthand via Apache’s OpenJPA project.

read more : An update on Java Persistence API 2.0

How TDD and Pairing Increase Production

"Test-driven Development" and "Pair Programming" are two of the most widely known of agile practices, yet are still largely not being practiced by many agile teams. Often, people will cite being "too busy" to adopt such practices as TDD and pairing; in essence, implying that striving for high code quality will reduce productivity. Mike Hill explains how this logic is seriously flawed.

Mike tells us, essentially, that one must "go better" if they want to "go faster"

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