Posted by Serge Beaumont around lunchtime: June 19th, 2009
Yesterday I gave a presentation on the Integrating Agile conference on the answers I have found in what I consider to be the Big Black Hole of Scrum: the Product Owner role. Based on the feedback I want to blog about this subject, and unblacken the hole a bit… 
Edit: the link to the second post in the series turns out to be buried too much at the bottom, so I’m adding it at the top: See Flow to Ready, Iterate to Done
The Definition of Ready
I give CSM trainings with Jeff Sutherland, and about half a year ago he had put something in his material called “the dynamic model of Scrum”. The essential feature was the addition of a READY state opposite the DONE state. The idea here is that a team needs to be in a stable, known situation to be able to perform well. It immediately struck a chord with me: I had seen so many teams thrash because the Product Owner could not give them a clear objective, the READY state was exactly the goal to work to. But what was it really, and how do you get there? By now I think I’ve got some good answers to these questions.
Posted by Jeroen Borgers at around evening time: June 15th, 2009
Last week I blogged about setting your performance goals: defining your requirements. This time I’ll blog about the importance of a Proof of Concept for performance.
The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.
(more…)
Posted by Vincent Partington around lunchtime: June 13th, 2009
Last week my colleague Albert Sikkema blogged about using UUIDs as primary keys. Interesting stuff, thanks again, Albert! This week I will continue the JPA implementation patterns series by discussing the relative merits of field access vs. property access.
The JPA specification allows two ways for the persistence provider to access the persistent state of an entity. The persistence provider can either invoke JavaBeans style property accessors (getters and setters) or access the instance fields of the entity directly. Which method is used depends on whether you have annotated the properties or the fields of an entity.
(more…)
Posted by Jeroen Borgers at around evening time: June 10th, 2009
Last week I blogged about how performance problems manifest themselves: frustration, loss of revenue and disruption of development; and how adding hardware is a questionable solution. This week I’ll blog about the first step to assure web performance.
It can be a valid choice to run the risk of performance problems in production and deal with them in a re-active manner. However, it is usually wiser to be pro-active and prevent them. This approach brings more certainty, peace of mind and also saves money. It consists of seven steps. Step 1: Define performance requirements.
(more…)
Posted by Sonny Gill just before lunchtime: June 8th, 2009
The last blog post, Understanding Google Wave, discussed the architecture and technical underpinnings of Google Wave. In this post, we will look at different ways of developing with Google Wave.
(more…)
Posted by Sonny Gill mid-morning: June 8th, 2009
(This blog post gives an overview of the architecture and technical concepts in Google Wave. If you are interested in how to use Google Wave in your applications, see Developing with Google Wave)
At Google I/O 2009, Google unveiled Wave. Wave is a new way of thinking about online conversations.
Consider the following situations -
- You write a blog post. Somebody comes around and posts a really insightful comment. Now, you or the comment author want to convert that comment into an independent blog post.
- You have been having a long email discussion with a colleague. Now you would like to invite another colleague to the same. She will need to know the context of the discussion and how it evolved.
- You email a few colleagues a draft of an article for review. They all email their comments back to you. A lot of them are suggesting the same changes without realizing that they have already been addressed.
With the tools we are using today such as email, blogs, IM etc., all of the above will require some kind of tedious copy – paste, and manual tracking of the changes being made.
Is there a better way?
The Google Wave model tries to provide a better way (more…)
Posted by Maarten Winkels in the late afternoon: June 6th, 2009
Say you want to build a web application and you want to use Seam for integrating standard technologies like JSF and EJB. Furthermore, you want to use the power of Maven to build your project for different environments, on different systems (like you continuous build system) and use its’ rich reporting features to get an overview of the code quality of your project. And of course you want to use a good IDE, like Eclipse with JBoss tools to aid you in development. How does one go about setting up all these things?
(more…)
Posted by Albert Sikkema at around evening time: June 3rd, 2009
Continuing Vincent Partington‘s blog series about JPA implementation patterns, I would like to add the following
The default way in JPA for primary keys is to use the @GeneratedValue annotation with the strategy attribute set to one of AUTO, IDENTITY, SEQUENCE, or TABLE. You pick the most appropriate strategy for your situation and that’s it.
But you can also choose to generate the primary key yourself.
(more…)
Posted by Jeroen Borgers at around evening time: June 2nd, 2009
Last week I blogged about the increasing load at web shops and the increasing challenges for developers and operators. The question to be answered was stated as: how can we prevent performance and availability problems; how can we assure that a web site is always quick and available? In this blog I’ll describe some of the forms in which I found performance difficulties to present themselves. (more…)
Posted by ShriKant Vashishtha mid-morning: June 2nd, 2009
One of the key USPs of pair-programming is – it provides value which is more than simple typing. That includes ACTIVE participation in code-review, knowledge sharing on continual basis, frequent design discussions with minimal distractions etc. If you primarily focus on knowledge sharing, pair-programming essentially provides true form of knowledge sharing as instead of looking at some bulky heartless documents you sit together with a person who has already worked on the subject and can have conversations and design discussions.