When you were hired by your current employer, you may think it's because of your winning personality, your dazzling smile, or your encyclopedic knowledge of [insert technology here]. But it's not. You were hired for your ability to sit and concentrate for long periods of time to solve problems, then placed in an environment where it's utterly impossible to do that! Who decides that, despite overwhelming evidence that it's bad for productivity and people hate it, that you must sit in a cubicle? The furniture police! This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to gird yourself against all those distractions. I talk about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the mid-guided attempts to sap your ability to produce good work. And I give you ways to go on the lam from the furniture police and ammunition to fight back!

When you were hired by your current employer, you may think it's because of your winning personality, your dazzling smile, or your encyclopedic knowledge of [insert technology here]. But it's not. You were hired for your ability to sit and concentrate for long periods of time to solve problems, then placed in an environment where it's utterly impossible to do that! Who decides that, despite overwhelming evidence that it's bad for productivity and people hate it, that you must sit in a cubicle? The furniture police! This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to gird yourself against all those distractions. I talk about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the mid-guided attempts to sap your ability to produce good work. And I give you ways to go on the lam from the furniture police and ammunition to fight back!

Most of the software world has realized that BDUF (Big Design Up Front) doesn't work well in software. But lots of developers struggle with this notion when it applies to architecture and design. Surely you can't just start coding, right? You need some level of understanding before you can start work. This session describes the current thinking about emergent design & evolutionary architecture, including both proactive (test-driven development) and reactive (refactoring, composed method) approaches to discovering design. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping you code in sync with the problem domain.

Most of the software world has realized that BDUF (Big Design Up Front) doesn't work well in software. But lots of developers struggle with this notion when it applies to architecture and design. Surely you can't just start coding, right? You need some level of understanding before you can start work. This session describes the current thinking about emergent design & evolutionary architecture, including both proactive (test-driven development) and reactive (refactoring, composed method) approaches to discovering design. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping you code in sync with the problem domain.

Refactoring is a fine academic exercise in the perfect world, but we don't really live there. Even with the best intentions, projects build up technical debt and crufty bad things. This session covers refactoring in the real world, at both the atomic level (how to refactor towards composed method and the single level of abstraction principle) to larger project strategies for multi-day refactoring efforts. This talk provides practical strategies for real projects to effectively refactor your code.

Refactoring is a fine academic exercise in the perfect world, but we don't really live there. Even with the best intentions, projects build up technical debt and crufty bad things. This session covers refactoring in the real world, at both the atomic level (how to refactor towards composed method and the single level of abstraction principle) to larger project strategies for multi-day refactoring efforts. This talk provides practical strategies for real projects to effectively refactor your code.

Developers from the 1980s would be shocked at how inefficiently developers use their computers because of the advent of graphical operating systems. This talk describes how to reclaim productivity afforded by intelligent use of command lines and other ways of accelerating your interaction with the computer and bending computers to do your bidding. Stop working so hard for your computer!

In The Productive Programmer, I identify 4 principles of productivity: acceleration, focus, automation, and canonicality. This session defines the principles and describes their use, but the primary focus of this talk is on real-world examples of how you can use these principles to make yourself a more productive programmer. Acceleration covers ways to speed up development by taking command of your computer. This includes keyboard shortcuts (including ways to learn them and make better use of them) in both IntelliJ and Eclipse. Focus describes how you can utilize your environment (both physical and computer) to greatly enhance your productivity. Canonicality (the DRY principle from The Pragmatic Programmer) discourages repeating artifacts in projects. This talk shows effective ways to avoid this repetition. I show examples of creating DRY documentation, O/R mapping, database schemas, and development environments. Automation refers to making the computer do more work for you. This talk includes tons of examples, all culled from real-world projects

BRING YOUR LAPTOP WITH YOU, BUT A LAPTOP ISN'T REQUIRED! Reading and hearing about agile practices is one thing, but actually doing it is completely different. This session puts you to work in an agile fashion, applying agile developer practices.

Reading and hearing about agile practices is one thing, but actually doing it is completely different. This session puts you to work in an agile fashion, applying agile developer practices. During this session, we're going to take a problem and iteratively develop the solution, using test-driven development, pair programming, retrospectives, pair rotation, and other agile development techniques. We should be able to get through about 3 20-minute iterations during the 90 minutes, giving you a hands-on feel for real agile development. If you have a laptop, bring it, but only half the class needs one, so if you don't have a laptop, don't let it discourage you. Come see what it's like to work on a real agile project, even if it's just 90 minutes.

Most developers think that "TDD" stands for Test-driven Development. But it really should stand for "Test-driven Design". Rigorously using TDD makes your code much better in multiple ways.

This session demonstrates how stringent TDD improves the structure of your code. I discuss TDD as a technique for vetting consumer calls, using mock objects to understand complex interactions between collaborators, and some discussions of improved code metrics yielded by TDD. This session shows that TDD is much more than testing: it fundamentally makes your code better at multiple levels.

This talk covers language techniques in Java, Groovy, and Ruby on how and why to create DSLs, and also covers the very important topic of implicit context, and how language constructs can allow you to write less verbose and more expressive code.

Domain specific languages have been the Next Big Thing for years now, but they have quietly started penetrating the development world. This talk covers language techniques in Java, Groovy, and Ruby on how and why to create DSLs. This session demonstrates with motivation for converting APIs into DSLs, and various patterns, anti-patterns, and best practices for how to achieve the optimum effect. This talk also covers the very important topic of implicit context, and how language constructs can allow you to write less verbose and more expressive code.

Regular expressions should be an integral part of every developer?s toolbox, but most don?t realize what an important topic it is. Regular expressions have existed for decades, but many developers don't understand how to take full advantage of this powerful mechanism, either through command line tools and editors or in their development.

This session shows how to fully exploit regular expressions. It begins with the basic premise of how regular expressions work, then shows how to take advantage of the RegEx library built into the Java platform. This session shows how to use wildcards, escape characters, meta-tags, character class operators, look-aheads/look-behinds, and how to use the greedy operators effectively. It covers regular expressions from the beginning through to advanced usage, both in Java and in tools that support regular expressions. This session is packed with real examples of regular expressions (including a game show with no fabulous prizes).

Key Session Points:

Ruby is the revenge of the Smalltalkers. Not since Smalltalk has a language had such powerful meta-programming facilities. While this may seem like a minor feature, it turns out that surgical meta-programming allows solutions to problems that are clearer, more concise, more maintainable, and take orders of magnitudes fewer lines of code.

This session shows one of the reasons that JRuby is the most powerful mainstream language today: meta-programming. It shows tons of meta-programming techniques in Ruby, including open classes, the shadow meta-class, defining methods, method_ & const_missing, dynamically adding and removing mixins, and more. And each of these comes with an example that actually makes sense!

Session Topics

• Modules
• Structs
• Freezing
• Messages and Dynamic Invocation
• The Shadow Meta-class
• Code as Objects
• Delegation
• Open Classes
• Aspects
• Missing!
• Const
• Method
• Reflection
• Mixology