Maven 2 is out for quite some time now. This week I decided to try to migrate a project we work on to maven 2. Here’s a part of what I ran into while migrating to maven 2:
Filed under: General, Java, Maven
2 Comments
One of the main concerns of a good ORM, in addition to identity and scope handling, is collection mapping. Hibernate has a lot of ability in this area. In this blog I’ll show a variety of collection-mappings.
Filed under: Hibernate, Java
5 Comments
Non-invasive Audit logging
Which developer hasn't worked on a project where, at some point in time before the final delivery, some guy from maintenance wakes up and asks the development team whether they can perform audit logging... Specifically he wants to have a "detailed log". It should contain the IPAddress of the user, his login name, and some information about which actions he performed and what the results were...
(more...)
Filed under: Java
2 Comments
The Software Development Process (SDP in short) defines the way business ideas are put into software practice. It covers the entire process from requirements definition through to using the software in production. Many projects simply fail because of the fact that the business and software development processes are not aligned. It is a known fact [Standish98] that the most important factors that make or break a software development project are:
1. User Involvement,
2. Executive Support and
3. Clear Business Objectives.
These factors are more important than an experienced Project Manager. This is clearly evidence that stakeholders outside the IT department should be represented in the Software Development Process. To emphasize this even more, research has shown that 45% of all features implemented are never used at all. Therefore we can’t stress the simple point enough:
The software development process should resemble the business process.
Often this is not the case and the SDP has remained a mere IT asset or, even worse, a pure development instrument that has originated from team or developer preference, theory or vendor promotion. This can seriously hurt business as projects are more likely to fail with an inadequate process, and if they succeed they may be twice as expensive as needed.
Filed under: Agile, Articles, General
No Comments
At my current project we have a very detailed analysis model. Actually, detailed doesn't begin to describe it. the model describes over 200 classes. One of the many problems with such an extended analysis model is that there is no room for the developers to interpret the business model and figure out the technical design that fits it best. Implementing the classes that the analysis model describes with their properties and associations is complicated enough, and then the operations and services that are based on these classes will still need to be designed and implemented. This leads to developers simply typing out the classes as the Analysis model describes them.
One striking example is where a many to many association acquires attributes. Let's look at an example.