Working around envers

When using envers for in our implementation, on the simplistic implementation, it does not provide much information on what the transaction is about. To get around this, we had no choice but to input the transactional information at the action level. This will also allow all information to be in a transaction table, in this case the "MA_Transaction".

The transaction table shall also be audited to tag the revision number to it, when envers audits it. This finally "MA_Transaction_AUD" table will contain the revision + Transaction, giving a consolidated table of all transaction information.

The key thing to note is that both the entity persistence and the transaction persistence have to be done within one transaction to ensure that the revision is properly replicated in the "MA_Transaction_AUD" table.

Though, this design is not a clean and straightfoward one, this was necessary to get this it working the way we need to, when we were supposed develop an enquiry facility.

How envers can work for you

Recently, i was using envers as a quick method to perform logging for my application. I have some positive and negative thoughts at this method.

It works in the following way:

Advantages

• Simple to implement transactional information.
• Audit Reader to query the audit records to find entity at a particular revision

Disadvantages

• Creates multiple Audit tables
• Very hard to document function that has modified the entity
• Need 2 Audit Reader queries to retrieve the before and after values
• Need to query all entities when trying to find out which table each revision has impacted.

Scrum (Software Development)

SCRUM is a methodology that is used by a team to manage development of features for a product, or generic software development.

In the scrum development process, it involves people of 3 main roles. Scrum Master(coordinator) , Product Owners (stakeholders/customers) and Team (analyst, designers, developers, testers).

It starts from the Product BackLog Listing, i.e. a documents that contains all features, enhancements, wishlist. That defines what are the necessary features are to be developed. This list have to contain rough estimates of the time required for development of these features. It should also contain the rough business value of the feature. It will give the product owner an idea/gauge of how must business value it will provide versus the 'cost' of developing the features. Allowing these features to be rated and prioritized in order.

A features of the highest priority in the Product Backlog, will be chosen by the product owner in a sprint planning meeting. The team will then decided how much can be accepted to be completed during this sprint. A sprint is typically a timed period when the team will develop the promised features. During this time, feature will be defined in detail of how the team will implement the features in a sprint backlog. Features will then be broken down into tasks, and small chunks of less than 16 hours of work each. These tasks are also ranked in the sprint logs by priority. The interesting thing is that the tasks are not assigned out. The team members will picked from this list based on priority and skill set for the task.

During these sprints, it relies on verbal communication, cross disciplined collaboration between the team. Hence the team needs to be on location to perform these sprints. Also a daily scrum needs to be held on the same time and location daily for a short 15 minutes period. Everyone in the team will answer the following questions:

• What have been done yesterday
• What will I do today
• Is there any problems preventing me from completing my job today

When there are problems encountered by the team, the scrum master is to help facilitate and resolve any problems that are raised and get back to the team members.

A burndown chart needs to be maintained, showing the work left from the sprint backlog that the team can visually see to be aware of the progress to completion.

"A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements." - so very true

The process of selecting features from the product backlog for each sprint process will be iterated until the product backlog has been completely cleared.