Sometimes there is an urgent need popping up in the middle of an investigation of what is happening with your application server – e.g., a process is showing up, but refuses to serve network connections. There could be thousands of reasons why it is stuck, but one of the most common and a classic problem is deadlocked threads, i.e. threads that didn't share some of the resources on start-up correctly.

Suppose that weeks of developing business processes, building user interface and integrating Siebel with other systems are gone at last; implementation can be considered completed, and users have started to work with Siebel. There are no fatal bugs, nor annoying performance issues. Still, there can be something left to improve, specifically ergonomics of your Siebel implementation – and, possibly, efficiency of users' actions and operations in Siebel.

On one of my recent projects I’ve been asked to describe how our Restful API can be consumed by a third party service. In a SOAP world this task usually boils down to providing a WSDL, which can simplify understanding of exposed API, and can also be used for generating API clients in a most standardized manner.

In my previous article I described some basic tricks that are helpful for working with property sets. Here I am going to describe a few more tricks, which are still simple enough to quickly incorporate those in your daily routine. For doing something more complex, you can consider scripting, just as we did when we decided that workflows with huge number of steps are quite difficult and time consuming to develop and maintain.

When practicing any of the agile software development methodologies – despite an inherent flexibility of those – it is rather important at least to start with a “by the book” approach. This means that when you roll out your agile processes, you try to implement each and every aspect of it, even if that seems useless or not required in your particular situation. Only then you can see from experience that something needs to be tailored – and a retrospective is a powerful tool to facilitate that kind of team learning.