Stuart Halloway

By Stuart Halloway

Git is not the next step in evolution of centralized source control, following in the footsteps of cvs, svn, etc. These tools provide centralized history of deltas, where git provides distributed history of trees of content. In this talk, you will see the advantages of the git approach:

Incredible speed. Local, disconnected operation. Source control workflow customized to your team. Centralized, distributed, or layered, you can build it with git. Cheap and easy branching, tagging, and merging. Editing and refactoring your commits.

You have probably heard about git by now, perhaps something along these lines: "Git is a version control system, and it is more powerful that Subversion in every way. You don't even have to be online to commit!"

This is true, but it undersells git. Git is not the next step in evolution of centralized source control, following in the footsteps of cvs, svn, etc. These tools provide centralized history of deltas, where git provides distributed history of trees of content. In this talk, you will see the advantages of the git approach:

• Incredible speed.
• Local, disconnected operation.
• Source control workflow customized to your team. Centralized, distributed, or layered, you can build it with git.
• Cheap and easy branching, tagging, and merging.
• Editing and refactoring your commits.

The git community prefers power to ease of use, and so git's user interface and documentation can be intimidating. You will learn the straight and narrow path for common, day-to-day git operations. You will also learn git's underlying data model, and get a quick introduction to more advanced concepts like submodules, cherry-picking, and bisection.

As a final bonus, you will see how to use git on an existing subversion project. You can use git as your svn client, and the rest of the team can stay on svn and not even care.

By Stuart Halloway

In this talk, we will explore and compare four of the most interesting JVM languages: Clojure, Groovy, JRuby, and Scala. Each of these languages aims to greatly simplify writing code for the JVM, and all of them succeed in this mission. However, these languages have very different design goals. We will explore these differences, and help you decide when and where these languages might fit into your development toolkit. For more information see http://blog.thinkrelevance.com/2008/9/24/java-next-overview.

As we reach the middle of our second decade of Java experience, the community has learned a lot about software development. Many of our best ideas on how to use a Java Virtual Machine (JVM) are now being baked into more advanced languages for the JVM. These languages tend to provide two significant advantages:

• They reduce the amount of ceremony in your code, allowing you to focus on the essence of the problem you are solving
• They enable some degree of functional programming style. Think of it as a dash of verb-oriented programming to spice up your noun-oriented programming.

In this talk, we will explore and compare three of the most interesting new JVM languages: Clojure, Groovy, JRuby, and Scala. Each of these languages aims to greatly simplify writing code for the JVM, and all of them succeed in this mission. However, these languages have very different design goals. We will explore these differences, and help you decide when and where these languages might fit into your development toolkit.

By Stuart Halloway

Over the last few years, we have taken dozens of projects to 100% coverage, and there are still plenty of things that can go wrong. We will look at examples the various problems, and show how to prevent them from infecting your project.

With an expressive language such as Groovy or Ruby and with modern test practices, 100% C0 test coverage is readily achievable. But 100% coverage is meaningless without other supporting habits and practices. Over the last few years, we have taken dozens of projects to 100% coverage, and there are still plenty of things that can go wrong.

We will look at examples of each of these problems, and show how to prevent them from infecting your project:

* Fragile mocking
* Pair bravado
* The ugly mirror
* Parallel abstraction
* Overspecification
* Underspecification
* Invisible code
* Misplaced exemplar

By Stuart Halloway

The rise of Ajax and Rich Web Applications, plus the success of dynamic languages, has caused people to revisit the JavaScript language. Now that we take JavaScript seriously as a language, it is time to get serious about the quality of JavaScript code, through refactoring. In this talk, we will test and refactor a real-world jQuery plugin.

As we refactor a real-world jQuery plugin, you will learn how to

• test JavaScript code with Screw.Unit, Smoke, and blue-ridge
• write covering tests for existing code
• perform common refactorings such as extract method and "use the right tools"
• rethink refactoring in light of functional programming style
• think about when and how refactoring shades into breaking changes and redesign

By Stuart Halloway

Find out why Clojure is Java.next:

• Clojure provides clean, fast access to all Java libraries.
• Clojure provides all the low-ceremony goodness you know and love from dynamic languages such as Ruby and Python.
• Clojure includes Lisp's signature feature: Treating code as data through macros.
• Clojure's emphasis on immutability and support for software transactional memory make it a viable option for taking advantage of massively parallel hardware.

Clojure is a dynamic programming language for the Java Virtual Machine, with a compelling combination of features:

• Clojure is elegant. Clojure?s clean, careful design lets you write programs that get right to the essence of a problem, without a lot of clutter and ceremony.
• Clojure is Lisp reloaded. Clojure has the power inherent in Lisp, but is not constrained by the history of Lisp.
• Clojure is a functional language. Data structures are immutable, and most functions are side-effect free. This makes it easier to write correct programs, and to compose large programs from smaller ones.
• Clojure simpli?es concurrent programming. Of course, Java itself has pretty good concurrency support. But, there is wide agreement that lock-based concurrency is dif?cult to use correctly. Clojure provides alternatives to lock-based concurrency: software transactional memory, agents, and dynamic variables.
• Clojure embraces Java. Calling from Clojure to Java is direct, and goes through no translation layer.
• Unlike many popular dynamic languages, Clojure is fast. Wherever you need it, you can get the exact same performance that you could get from hand-written Java code.
  

By Stuart Halloway

In this talk you will learn to write correct concurrent programs in Clojure, without the complexity of managing Java locks. You will learn how:

• Software transactional memory (STM) manages coordinated, synchronous changes to shared state.
• Agents provide a more decoupled model, where independent tasks proceed asynchronously.
• Vars manage thread-local bindings, which are useful for a variety of tasks not normally associated with concurrency.

Concurrency is a fact of life, and increasingly a fact of software. There are several important reasons that programs need to do more than one thing at a time:

• Expensive computations may need to execute in parallel on multiple cores (or multiple boxes) in order to complete in a timely manner.
• Tasks that are blocked waiting for a resource need to stand down and let other tasks use available processors.
• User interfaces need to remain responsive while performing long running tasks.
• Operations that are logically independent are easier to implement if the platform can recognize and take advantage of their independence.

In this talk you will learn to write correct concurrent programs in Clojure, without the complexity of managing Java locks. You will learn how:

• Software transactional memory (STM) manages coordinated, synchronous changes to shared state.
• Agents provide a more decoupled model, where independent tasks proceed asynchronously.
• Vars manage thread-local bindings, which are useful for a variety of tasks not normally associated with concurrency.

Prerequisite: Programming Clojure

By Stuart Halloway

Teams adopting agile should begin at a tactical level, but they shouldn't end there. The Agile Manifesto operates at many different levels. Learn to apply the principles of agile at a strategic level. Otherwise you can have a great agile ground game and still lose.

Many programming teams now embrace agile at the tactical level, which is the right place to begin. Applying the ideas in the Agile Manifesto, good teams embrace practices like

• story point estimation
• burndown tracking
• technical expertise
• behavior-driven development
• daily standups
• pair programming
• continuous integration
• spiking
• refactoring
• customer always available
• well-understood roles

The Agile Manifesto can be applied at a strategic level, too. However, the tensions are different. Feedback cycles are longer, objectives and results are less clear, and roles and relationships are unknown or changing. In this talk you will learn how to apply agile at the strategic realm, using practices like:

• measure the immeasurable
• pair everything
• choose meaningful standards
• build for tomorrow (but not next year)
• retrospect well
• spot the trends
• use the right medium
• want to succeed (not as obvious as it sounds!)

With the right practices in place, agility can help you choose objectives, as well as attain them.

By Stuart Halloway

If an iteration is the heartbeat of an agile development process, then Iteration Zero (IZero) creates the heart. While you can (and should) retrospect and adjust throughout the software lifecycle, few things are as valuable as a good start. In this talk, you will learn how we run Iteration Zero at Relevance.

The purpose of IZero is to prepare all stakeholders, so that Iteration One can begin normal iteration pace, heading in the right direction. In this talk, we will visit each of the four principles of the Agile Manifesto, and show how to establish them in IZero.

AM #1. Individuals and interactions over processes and tools. In IZero, you should identify the team roles, and find the right people to fill them. You should create places and times (both physical and virtual) to maximize contact and interaction.

AM #2. Working software over comprehensive documentation. In IZero, you establish the practices you will use to create working software, which may include test-driven development, pair programming, continuous integration, code review, various metrics, and more.

AM #3 Customer collaboration over contract negotiation. In IZero, create the shared vision, and commit to keeping it collaborative. Define a flow that will work for all stakeholders, that can take ideas -> planning -> development -> testing -> acceptance.

AM #4 Responding to change over following a plan. IZero sets the initial parameters, but also prepares for change. Decide how to use standups, iteration planning meetings, iteration summaries, and retrospectives to adapt to change throughout the project.

IZero does not have to be a blank slate. Once you have practiced it, you will build up a stock of IZero habits that work for your team, and draw on it for future projects.

By Stuart Halloway

The Agile Manifesto, like any good scripture, admits of many interpretations. There is no one "right path." What works for us may not work for you. At Relevance we have tried many paths, and learned many lessons. Join us to see dozens of ideas that have worked for us, plus some that haven't.

The Agile Manifesto states four key values:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

That manifesto sounds great, but perhaps a little vague. It gets more concrete quickly when you start doing it! In this talk, we will share our experiences, both good and bad, with various practices and problems associated with agile:

• Pairing all the time (except when we don’t)
• Running cross-project retrospectives
• Code coverage standards
• Choosing the sharpest tools
• Fixed-bid projects
• Handling budget problems
• Teaching customers
• Setting the wrong kinds of targets
• Holding all participants accountable
• Forking everything
• Introducing new technologies

Hold on tight to your sacred cows, because no assumption you have about agile will be safe.

By Stuart Halloway

In recent years, the Java community has embraced a variety of new languages that target the JVM, but also offer productivity advantages over traditional Java coding.

One of the most interesting of these languages is Clojure, a "Lisp unconstrained by backward compatibility." In this talk, you will see why Clojure deserves serious consideration as the next big JVM language:

* Clojure provides all the low-ceremony goodness you know and love from dynamic languages such as Ruby and Python.
* Clojure includes Lisp's signature feature: Treating code as data through macros.
* Clojure's emphasis on immutability and support for software transactional memory make it a viable option for taking advantage of massively parallel hardware.

By Stuart Halloway

Agile teams manage change and risk by apapting. But to adapt, you must identify opportunities for change and take them. Retrospectives are a fun, cost-effective way for your team to learn and change.

In this talk, we will begin by conducting a mini-retrospective, so that you get a feel for the basic process. Next, we will review the core principles of a retrospective, and use these principles to compare and contrast a variety of retrospective activities from the book Agile Retrospectives.

Next, we will explore a few retrospective activities in greater detail. These are some of the favorites that we use regularly at Relevance:

• team radar
• prioritize with dots
• learning matrix

Finally, we will talk about how to tune retrospectives to the needs of your team at a specific moment in time. No two retrospectives are alike, and an experienced facilitator adds value by adapting a retrospective to meet the current need.

By Stuart Halloway

jQuery is a powerful JavaScript library for dealing with HTML, events, animations, and Ajax. Unlike many libraries, jQuery puts the browser object model front-and-center through its ubiquitous wrapped element sets. In this talk, you will learn to progressively enhance your web applications the jQuery way: with unobtrusive, functional JavaScript.

In this talk, you will learn how to:

• select and modify elements with jQuery's powerful selectors
• use jQuery's utility functions
• register event handlers, including dynamic ones that track changes to the page over time
• play nice with other libraries with noConflict
• create Ajax requests that return HTML, JSON, and other data types
• breathe life into your interface with effects and animations
• unit test your JavaScript code with Screw.Unit, Smoke, and blue-ridge