Feature Flow – Increasing velocity using Kanban
Posted by Machiel Groeneveld around lunchtime: May 28th, 2009
A few months ago I was joined a software development team that had some problems getting their process right. The team was doing Scrum by the book, apart from regular production releases they were doing it all: sprints, planning, retrospectives, Scrum board etc. This team didn't need too much explanation of Scrum so I could dive into development straight away, or so I thought. They struggled with getting the sprints right, their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.
(more...)
JPA implementation patterns: Bidirectional associations vs. lazy loading
Posted by Vincent Partington at around evening time: May 25th, 2009
Two weeks ago I blogged about the use of the Service Facade and Data Transfer Object pattern in JPA application architecture. This week I will move from the high level perspective and discuss an interesting interaction I discovered between the way bidirectional associations are managed and lazy loading. So let's roll up our sleeves and get dirty in this next installation of the JPA implementation patterns series. 
This blog assumes that you are familiar with the Order/OrderLine example I introduced in the first two blogs of this series. If you are not, please review the example.
Consider the following code:
OrderLine orderLineToRemove = orderLineDao.findById(30); orderLineToRemove.setOrder(null);
The intention of this code is to unassociate the OrderLine with the Order it was previously associated with. You might imagine doing this prior to removing the OrderLine object (although you can also use the @PreRemove annotation to have this done automatically) or when you want to attach the OrderLine to a different Order entity.
If you run this code you will find that the following entities will be loaded:
- The OrderLine with id 30.
- The Order associated with the OrderLine. This happens because the OrderLine.setOrder method invokes the Order.internalRemoveOrderLine method to remove the OrderLine from its parent Order object.
- All the other OrderLines that are associated with that Order! The Order.orderLines set is loaded when the OrderLine object with id 30 is removed from it.
Web performance in seven steps
Posted by Jeroen Borgers at around evening time: May 25th, 2009
By Jeroen Borgers
More and more Internet users buy in web shops these days. Research shows that the part of European Internet users that buys on-line has grown from 40% in 2004 to 80% in 2008. Additionally, large web retailers in The Netherlands see their revenue grow just as if the recession has never materialized. Business seems to be flourishing. (more...)
Augmented Distributed Agile Teams – The Need of Local Retrospective
Posted by ShriKant Vashishtha around lunchtime: May 21st, 2009
World is becoming a global village especially in form of communication and the dissemination of information. In context of current economic turmoil and lack of enough trained software professionals locally, distributed Agile is becoming a norm for software project execution.
Earlier, most of the times, entire distributed software project used to be executed completely at offshore because of time-zone differences and communication issues. Now because of communication revolution, you see a new trend where software companies like to extend their teams (augmented Agile teams) with different vendors. Recently while working in such a project from a distributed location, we realized the need of local retrospective.
JPA implementation patterns: Service Facades and Data Transfers Objects
Posted by Vincent Partington at around evening time: May 11th, 2009
In my previous blog on JPA implementation patterns, I touched upon the subject of the DTO and Service Facade patterns. In this blog I will explore why we would even need such patterns and put these patterns and the DAO pattern into the broader context of JPA application architecture.
If there is one thing that I learned when implementing JPA for the first time is that some of the "old school" enterprise application architecture patterns still apply, even though some people have proclaimed them to be no longer necessary:
- The DAO has been declared dead because you might just as well invoke the EntityManager directly. It provides a nice enough interface and switching from JPA to a different persistence implementation is not something the DAO abstraction would make much easier.
- DTO's have been deemed superfluous because you can also use your domain objects directly in the presentation layer. This is made possible by a combination of the open EntityManager in view pattern, tag libraries to display your domain objects in JSP's and data-binding utilities to map HTTP request parameters back to domain objects.
- And finally Service Facades also seem to have gone out of fashion. Instead you can have the controller directly invoke the services it needs or, even simpler, directly contain the business logic.
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)