<<< Previous speaker next speaker >>>

Neal Ford, ThoughtWorks

 Neal  Ford

Neal Ford is an senior application architect at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery.

He is also the designer and developer of applications, instructional materials, magazine articles, courseware, video/DVD presentations, and author of the books Developing with Delphi: Object-Oriented Techniques, JBuilder 3 Unleashed, and Art of Java Web Development.

He is also the editor and a contributor to No Fluff, Just Stuff Anthology : The 2006 Edition and No Fluff, Just Stuff Anthology Volume 2: The 2007 Edition. His primary consulting focus is the building of large-scale enterprise applications. He is also an internationally acclaimed speaker, having spoken at numerous developers conferences worldwide. Check out his web site at www.nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.

Presentation: "Meta-programming Ruby for fun and profit"

Track: Railing

Time: Monday 14:40 - 15:30

Location: Musikhuset Nr. 222

Presentation: "Real-world Refactoring"

Time: Wednesday 13:20 - 14:10

Location: Store Sal

Abstract: 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.

Presentation: "Building DSLs with External Workbenches"

Track: DSL

Time: Wednesday 15:40 - 16:30

Location: Lille Sal

Abstract: A new abstraction style of software development is on the horizon: building Domain Specific Languages with language workbenches (like Intentional Software, JetBrains MPS, Textual Modeling Framework, and others). The interesting aspects of this development style aren't the tools themselves, but the ways in which projects built by composing languages differs from our current perceptions of development. This talk highlights several of these paradigm shifts and what it takes to build software in an environment where building new languages is easy. In the context of real project delivery, I discuss language composition, type systems, debugging and tracing, and other practical considerations for the use of language workbenches. This talk highlights how using DSLs as an abstraction mechanism allows more effective project delivery.

Workshop: "Domain Specific Languages"

Track: Tutorial

Time: Sunday 09:00 - 16:00

Location: Kammermusik


Domain Specific Languages (DSLs) are an old technique in software development that's getting a recent resurgence in interest. Most developers run into them regularly - as XML configuration files, regular expressions, query languages or build scripts. However they haven't been given the attention they deserve and there is very little information out there to help developers build them effectively. We find that few people have done much to build their own DSLs and even fewer have a broad appreciation of the various techniques involved.

This tutorial is a step towards closing this gap. We'll begin by introducing the three main categories of DSLs: External, Internal, and Language Workbenches. We'll talk about the advantages of DSLs and the problems in using them, so that you'll appreciate what the different styles look like and when you might want to build them. In the second part we'll go into more details on techniques of working with each of the three styles, to get you started on your own work.

We are currently working to develop a coherent pedagogic framework (if you'll forgive a pretentious name) for DSLs, this tutorial is an opportunity to catch up with our work. However it does come with a caveat: we are still very much in the middle of the process of capturing and organizing this knowledge. As a result we won't be describing a finished body of knowledge, but rather one that is still evolving.