Creating new classes in Java is easy... but classes you create have a lot of inherited behavior that may or may not be what you need. There are also a lot of useful capabilities in the standard Java libraries that you may want to give your objects. Unfortunately, developers transitioning from other languages often don't discover these language features until some related problem bites them. The concepts here aren't sexy, but you will probably learn something that will make you go want to fix code in your current project.

In this session we will cover: - Reasons for and pitfalls when implementing your own equals() and hashCode() methods - Best practices for object construction (Factories and Immutability) - Useful toString() idioms - Serializable, Externalizable, and custom serialization techniques using the 'hidden' methods of Serializable - Clonable, shallow and deep copies, and why Clone() is evil. - Comparators and the Comparable Interface - Finalize(), and why not to use it - Your class's 'Class' object: opening the door to reflection. - Leaky references to 'this' - Guidelines for building objects in inheritance hierarchies - Many other useful practices and idioms - Tools to help you find and fix problems like these

For several years, I was a member of a team of people caught in the middle of a 200+ person software development company, with senior management wanting "buzzword compliant process improvement" such as CMMI, and engineers wanting more ?agile? solutions (and people on both sides confusing Agile with ad-hoc). We were responsible for sorting it all out. Reconciling this was a herculean effort, and can be a source of lessons learned for your own process improvement efforts. Are you trying to be more agile in your organization? Are you expecting it to be harder than it needs to be because of political and bureaucratic forces beyond your control? Do you have to "educate" your senior management to protect them from buzzwords? Come learn from my successes... and mistakes.

Introducing change into a large organization can be difficult, even when everyone is in agreement. By starting with 'the quick win' and fixing some real pain in your organization, you can begin to get people moving in the right direction. In this talk we will look at the kinds of quick process wins that are possible, and how to introduce new ideas into a large organization.

Most software engineers hate metrics... Why? Because we know the work we do is hard to quantify – any measurement of 'software engineering' is like trying to tell how tall someone is by how much they weigh... There may be some correlation, but there is so much deviation as to make the answer practically meaningless. As a result, we often see metrics used to justify improper conclusions. There are plenty of good metrics though, and plenty of ways to use them effectively.

In this presentation we will analyze what makes a 'good' metric, why some metrics are 'bad', and how you can use them to make meaningful measurements of your projects. We will look at several methods for gathering metrics too, including some open source tools you can put to use immediately.

Internationalization and Localization in Java is easy, right? Everyone knows you just store your strings in some resource bundles, set the locale, wave your hands a little bit, and your application is good-to-go. Right? Maybe not... Java provides some great utilities to get started, but leaves you needing more when it comes to things like screen layout, cultural sensitivities, semantic differences in translation, use of color and iconography, and other issues.

This presenter spent 9 years developing applications for the U.S. State Department that have been deployed in dozens of countries and languages. While some aspects of internationalization and localization are trivial, there are plenty of issues that are not. If you have an application that you expect to localize into other locales, there will be information here that is invaluable to you. This talk is entertaining for the war-stories alone! No other no-fluff presentation will feature pictures of the presenter waiting in line behind a herd of sheep to cross a pontoon bridge into Bosnia.

Capistrano (formerly Switchtower) is a tool originally written to help automate application deployment for Ruby on Rails. It does this well, but it has grown up into a tool capable of much, much more. It can be used for deploying Java applications, updating server configurations acrtoss an enterprise, administering netwoeks, backing up files, and all sorts of other activities. Any activity you might do from the command line, you can now do simultaneously across large numbers of machines, with all machines succeeding (or rolling back in case of failure) together.

In this talk I discuss the fundamentals of capistrano, use the built-in tasks to deploy a rails application, demonstrate the capability of performing custom tasks across several computers simultaneously (thanks to several virtual machines), and show how applications can be rolled back in case of problems. Capistrano isn't perfect though; we will also discuss best practices, limitations, and lessons learned.

Capistrano requires a POSIX-compatible shell and SSH on the machines it is going to control; as a side-benefit, we will also learn about CYGWIN, an open source tool that provides these capabilities (and lots lots more) to Windows environments.

How many times have you started a new project only to find that several months into it, you have a big ball of code you have to plod through to try to get anything done? How many times have you been the ?new guy? on an established project where it seems like the code grew more like weeds and brambles than a well-tended garden? With a few good structural guidelines and several tools to help analyze the code, we can keep our project from turning into that big ball of mud, and we can salvage a project that is already headed down that path.

This talk will talk about everything from build processes, teamwork, and project structure through versioning, release plans, upgrde strategies, package dependencies, and more. Using real-world scenarios from two projects with 12-15 people working together over a 5-year time span, this presentation will offer advice based on multiple successful deliveries of real software.