What's the point of highlighting story point "velocity"?

I see story points as an early estimation of relative complexity of a given software development task.

Part of the purpose of using story points instead of "ideal man days" is that the team can avoid getting too bogged down in how long it will actually take to achieve.

Keeping a record of these early estimates is fair enough, but is there really any point in using them as a significant indicator of the team's achievement from iteration to iteration?

What can the team do when they see the story point count is a little low so far in the current iteration?

• Arbitrarily re-prioritise stories?
• Cut corners by compromising on quality?
• Work some extra time without pairing?
• Save time in meetings by not having a say?

Estimates have some usefulness, but it is my assertion that they are counter productive as an indicator of progress mid-iteration.

What prevents Tomcat from shutting down?

Every now and then I come across a web application that won't shut down cleanly.

./catalina.sh start

works fine for starting up a Java process with the web application running in the Tomcat servlet container, but 

./catalina.sh stop

leaves the Java process running.

• Checking the catalina.out log file reveals that the Tomcat system has attempted to shut down.
• Http requests to the port(s) that Tomcat has been listening on indicate that the system is no longer accepting requests.
• Repeat attempts at ./catalina.sh stop indicate that Tomcat is no longer listening on the shutdown port.

In my experience, without fail, the underlying cause of this problem has been a non-daemon thread which has been started by a web application that has not been configured to should be shut down when Tomcat is shut down.

If you are not totally familiar with how the application hangs together, you may need some hints about where to look for the offending code.  Triggering a thread dump of the Tomcat process after the shutdown has failed should reveal a list including some non-daemon threads.  The names of the threads should give an indication of whether it is a JVM thread, a Tomcat thread, or a thread that has been started by the application.

Once you have established where the threads are being created, it is time to consider where and how to stop the threads.  Depending on the nature of the functionality being provided by the code, you may need to wait for the current processing to complete before terminating - otherwise the application would have used a daemon thread in the first place.

Dependency injection frameworks, such as Spring, will typically include shutdown hooks for any resources that they have responsibility for creating.

MongoDB Java driver randomness - it's only logging, but

I saw a number or people on Twitter yesterday posting a link to some "interesting" code in MongoDB's Java driver github.

The strange code located inside some exception handling included the following:

                if (!((_ok) ? true : (Math.random() > 0.1))) {

                    return res;

                }

I know my own code isn't always a shining example to be held up as the one true way of doing things, but seriously doubt that I have ever produced something as inexplicable as that.

I briefly tried to trace back the history to determine how long this has been around and whether there is a meaningful commit comment, but was in the middle of other more important things (lunch) and gave up.

The latest theory I have heard is that the code was introduced as an approach to reduce the amount of noise in logging of the exception.  I don't expect to see this recommended as a pattern any time soon.

MongoDB Lightning Talk

My employer recently hosted a gathering of their IT teams from around the world for a two day conference in Madrid.  It was a good opportunity to meet colleagues that I had previously only dealt with by phone and email in a relaxed social setting.

In a moment of madness I volunteered to give a presentation about a topic that I have been dabbling with in recent months - MongoDB.

My agile style of preparation - "delay commitment until the last responsible moment" - could easily have been mistaken for procrastination.  I'm not sure if I would recommend sitting on a sofa watching old episodes of Miami Vice with the laptop drifting in and out of sleep mode as being optimal for all.

Without further ado, here is a high level view of some of the content that I blended together:

• What is MongoDB?
• Non-Relational JSON Document Store
• Dynamic Schema
• Embedding of Documents and Arrays
• Comparison with relational database (Table -> Collection, Row -> Document etc.)
• How to Organise Data
• Entity -> Document
• Embedding vs Referencing
• 16MB document size limit
• Indexing
• How to Query
• Example of find
• Example of insert
• Example of aggregation framework
• What is MongoDB being used for?
• E-commerce
• Analytics and Reporting
• Content Management
• CoreMedia Elastic Social
• Logging
• Language and Framework Support
• Listing of languages and frameworks
• Drivers have semantics to fit with the style of the language
• Replication
• Configurable tags - usable within write concerns
• Configurable delay
• Sharding
• Distribution of writes
• Shard key selection importance
• Scatter-gather for reads not satisfiable by a single shard
• Gotchas
• Database level locking
• Default settings not suitable for all
• Application needs to check for result of operations

Online training - lectures

I've recently started an online course to learn a bit more about MongoDB.

The lectures are made available by youtube clips, which is good when I have time at home and there is nothing interesting on t.v.  I think it could be better if I could download the videos and watch them on my iPad during my commute to and from work.

Something like a podcast would deliver the same content, but not have the ability to reinforce the learning with the mini quiz that follows some videos on the current online system.

Comparing Java web application runtime environments

In a recent project the developers in my team have encountered some unexpected differences in behaviour at runtime.  What works fine in one environment could result in a server error in other - supposedly equivalent - environments.

The code and configuration of the web application should in theory be the same, so I'd like to have a way of checking what is actually different under the hood at runtime.

My initial thoughts are that the following will be relevant:
 - environment variables
 - JVM properties
 - loaded classes (or packages)

Exposing the data is one aspect, but in order for this to be useful beyond a one off check it would be good to have a way of quickly highlighting any differences between the output from two setups.

If the data is all key-value pairs then I expect the detecting of differences to be trivial.

UPDATE:
The problem JSPs turned out to be including some expression language syntax.