Jul 22 2009


Teaching retrospectives by example: NFJS Salt Lake City

Want to learn about agile retrospectives? Participate in one! At the No Fluff, Just Stuff software symposiums, I am doing a talk on retros where we begin by doing a retrospective on the conference itself.

At the Salt Lake City show this weekend, we had eight participants for the retrospective. NFJS talks are ninety minutes long, so we took the first sixty minutes to run a retro on the conference. Given that we only had a day of experience to retrospect on, and that we were not a cohesive team but were "thrown together" by people selecting the talk, I wondered if we would have enough to talk about. This turned out to be a non-issue, as everyone threw themselves in with gusto. We could have easily gone longer, and as facilitator I had to enforce the timebox on each phase.

Setting the stage

As an icebreaker, we did a variant of the Checkin exercise from the Agile Retrospectives book, using the question "If this conference was a movie, what movie would it be?" Answers included:

  • Driving Miss Daisy
  • Casino Royale
  • El Diablo
  • Lord of the Rings
  • Serenity

We had a few laughs, and the exercise broke the ice. However, nobody referred back to the movies in later exercises, so we will all just have to wonder if NFJS folk are orcs, reavers, outlaws, chauffeurs, or Quantum.

Gathering data

Next, we performed the Team Radar activity. After a few minutes of brainstorming, the team came up with eight possible topics to rate and discuss: prescriptiveness, (topic) diversity, relevance, scheduling, comfort, inspiration, food, timeframe. In order to hit the timebox for the retro, we agreed to use dot voting to select only four of these topics for further discussion.

Each attendee then ranked the four topics on a scale from 1 to 10, resulting in these averages:

  • 6.9 (topic) diversity:
  • 7.9 relevance
  • 5.9 scheduling
  • 7.4 inspiration

There were no major outliers on any of the scores. Overall, these scores are pretty high for a group who is taking seriously the challenge of finding things to improve.

Generating insights

Given the small group size, we elected to have a free form discussion to generate insights. Some of the ideas included:

  • Happy to see non-Java languages such as Clojure, Groovy, and Scala.
  • Would like to see even more non-Java, but ...
  • ... very happy that the Java topics were directly applicable to attendees jobs.
  • The agile talks were developer-focused, would like see more holistic talks.
  • For inspiration, the cornerstone is the first day keynote. Keynote was good, but could have been more novel.
  • Half of the participants had been to multiple NFJS conferences. The feeling of "it blew my mind" was still there, but not as strongly as in the past. Suggestion was made that this was the attendees changing over time more than the conference.

SMART goals are hard ...

The initial discussion of possible SMART goals attacked the lowest-scored item from the Team Radar: scheduling. How can the topics in a multi-track event such as NFJS be better organized so that participants are excited about every talk they attend? After a few minutes talking about track definitions, topic tags, website improvements, etc., we agreed it was a hard problem that was not going to yield a SMART goal in the time we had.

...Until you focus on the people

And then, by focusing on people instead of technology, we came up with two ideas that could significantly mitigate the scheduling problem:

  • Make it socially acceptable to walk out of a talk. Half of the participants said that, given a specific invitation to do so, they would have ducked out of at least one talk after they had seen the first few minutes and understood the agenda. So, at the next show, we request that all speakers choose a point 5-10 minutes into the talk to, well, invite people to leave. Keep count of the number of people who take the offer to decide whether this should become a standard practice.
  • Provide easy-to-find video on the NFJS website so that attendees can get to know each speaker before the show.

I brought the second idea to the conference organizer, Jay Zimmerman, immediately after the talk. He laughed because he is already doing it, building a collection of five-minute videos introducing the NFJS tour speakers. If only all SMART goals went so smoothly!


We voted up/down/neutral on whether the retro was worth the time, with all participants voting "up." The discussions helped each of us clarify our own perspective on the conference. Also, we were happy to have found easy-to-implement recommendations to improve the conference experience. After the retro, we had twenty minutes to discuss how to run a similar retrospective for an agile team, and some of the attendees are planning to try it with their own teams. As facilitator, I was pleased with the retro, and I am looking forward to taking this idea to other cities over the remainder of the year.


  • The Agile Retrospectives book includes dozens of retro exercises, and guidelines for when different exercises are appropriate. It is one of the books we recommend to team members on our projects.
  • Check out the agile talks at an NFJS event near you.

Jul 21 2009


Insurance on Rails

We've had several customers lately stuck in the same boat: they exist in a conservative industry (insurance), they have a large set of fixed costs for their IT needs (AS400s), and it has been years since they've been able to add new features to their software (COBOL.NET never took off). These are exactly the kinds of teams and problems that have resisted new technologies in the past; the inertia of the current system and its sunk costs were just too high. Incremental changes didn't seem cost effective, or even possible. That is no longer the case.

Working with these customers, we've been able to take advantage of Ruby on Rails and agile development processes to leapfrog their existing infrastructure and several generations of intermediate enhancements to bring them to a modern infrastructure with newfound opportunities for feature enhancement. The key is to leverage the real value of Rails (simplified, productive development environment and cheap, easy deployment) while simultaneously avoiding the siren song of Web 2.0 (flashy UIs, needless frivolity, the urge to redesign everything).

Focus on Core Values and Return on Investment

In order to succeed at one of these leapfrog projects, you have to focus on the core business strategy. We have been lucky enough to work with customers who understood this to the bone: first, do no harm to your existing users. Next, quickly eliminate needless costs. Then, and only then, start dipping into that well of pent-up feature demand. Without a deep commitment to this set of values, such a project is likely to suffer from cost overruns, angry users, and lost revenue. In other words, the 75% scenario for corporate IT investments.

Don't Fix What Ain't Broken

Insurance companies with green screen apps may have difficulty adding new features to their applications, but they generally don't have disgruntled users. That's the dirty little secret of our industry; green screen apps are usually pretty darn fast. They aren't simple, though. They are designed for trained users, users who have long since added their app usage patterns to their muscle memory. Anything that causes them to have to think about how to use the application is going to up the GrouchyMeter(tm) another notch. So when a company sits down to think about how to bring the app into the modern world, they should be thinking about the infrastructure, and what additional features a new infrastructure might be enabling. The only time they should be considering modifying the current user experience is if they have historical feedback about necessary changes.

The worst thing you can do to an account representative, billing clerk, claims processor, etc., is slow them down at their required data tasks. You can make it twice as bad if you do it just to make the application "prettier". So our customers resisted the urge to "bring in the designer" and "make the app more Web 2.0". The focus was on recreating the green screen experience through the browser, including field layouts and keyboard shortcuts, in order for the experience to be as close to identical as possible. Clearly, we don't force it to look exactly like the green screen application. It should use modern web design sensibilities as much as possible. Just don't upgrade for the sake of upgrading.

Rails brings simple Ajax and JavaScript integration (and testing) to the table, making it simple to focus on the user experience and the back-end processing at the same time.

Cost Savings

Next, focus on the cost savings inherent in the new effort. In the case of our customers, this came down to two items: the ongoing hardware and maintenance costs of the AS400s and the payroll costs of the programmers knowledgeable enough about RPG/COBOL keeping the system alive. As a team, we kept our focus on recreating existing functionality in the new architecture, using standard web development techniques, Ajax, and some custom JavaScript to keep the user experience as close to the original as possible. The only new features added at this stage were infrastructure upkeep features, like automated deployment via Capistrano, and database upkeep tools for dealing with their new open source relational database. Nothing in the historical backlog of user requests was addressed at this point; that came later.

By switching over to Rails, they were able to replace the expensive monthly maintenance of their AS400s with commodity servers running an open source OS (Linux, natch). What's better, they have offloaded the actual hardware maintenance entirely to a hosting company, thus enabling them to refocus parts of their IT staff on higher value tasks than mainframe upkeep.

Additionally, they can plan ahead for a smaller investment in programming talent since Rails developers and Linux sysadmins are cheaper than RPG/COBOL programmers and AS400 administrators, respectively. This means that we helped them achieve both an immediate cost savings, and a projected accelerated cost savings by shifting the infrastructure over the course of a single project.

Feature Enhancement

Finally, with a modern software architecture in place (with access to things like continuous integration, unit testing, etc.), the teams can finally begin addressing the years worth of pent-up feature demands. By conscientiously avoiding new feature development until after the existing functionality was deployed and usable, the teams were able to make new feature development decisions funded by the immediate and projected cost savings of the new system. Instead of agonizing over feature requests in the face of a vague notion of costs, they could spend the new savings more concretely on advanced features.

Once again, choosing Rails had an immediate impact on our customers. We were able to address several ancient feature requests quickly and inexpensively, because while they didn't fit particularly well in an old green screen style application, they were perfectly suited to modern web applications, and of course, we find Rails to be the most productive environment for quickly building web applications.

The Technical Tools for Succeeding

Over several of these projects, we've identified a set of core technical themes that have helped the efforts succeed.

  • On day one, watch somebody use the existing application. For an hour. Understand what they are accomplishing with the application, and what the application does not do. Plan to provide the former. Stop thinking about the latter.
  • On day two, start migrating the existing data. Do not wait for this; legacy mainframe applications tend to have legacy database schemas. Rails in particular has some built-in assumptions about schema. Either the data is going to need to be changed, or your code will. Repeat this often; your schema will evolve over time, and you need to continue to ensure a clear path for the existing data to land in the new structure.
  • In week one, get a real user interacting with the application. They'll tell you immediately all the things you will never learn on your own: "The last step should be instantaneous. This is taking 10 seconds or more.", or "When I tab out of this field, this other field should be filled in. I never want to look at that field, it should be automatic.", etc. Do not wait until "the system is done" to do this.
  • Pick a good JavaScript keybinding library. Get one that works with your chosen JavaScript library, and that is snappy and responsive.
  • Do NOT bind asynchronous remote server calls to keyboard events. The point of using the keyboard is fast navigation; making a roundtrip to the server will always be slower than the user expects. As much as possible, cache the data you need to respond to keyboard events locally.
  • Target a single browser if you can. Most legacy mainframe apps have a limited user base, and the client can reasonably control expectations about usage scenarios. Pick a good, modern browser, like Firefox 2.0+, and develop against that. Treat further browser support as a feature enhancement, for shipping after the first deployment.
  • Benchmark your chosen server configuration against the original mainframe application as early as possible. We've never had an admin tell us that the new version was slower, but the political fallout of shipping an application where that is true would be catastrophic. So benchmark early and often.
  • Get a realistic set of test data. Bear in mind that most legacy mainframe applications have massive amounts of data. They've been operating for 20 or 30 years in some cases; even at a million records a year, you have 30 million records. Often, much more. Don't assume your application is going to perform correctly because your 100 rows of test data fly through the app. Find out how much data there is in the production database, and drive your app against that iceberg as early as you can.

It Doesn't Take Bionic Legs

Teams with legacy hardware and software infrastructure shouldn't be waiting around in fear of incremental change anymore. Modern, open source development tools and deployment environments are easy enough to migrate to that it now costs more to continue supporting the existing legacy system. As long as your team keeps a laser-like focus on achieving equivalency before enhancement, there is no good reason against moving forward. Don't just sit around on a pile of 1975---the tools are available to modernize your codebase and move your organization ahead.

Jul 14 2009


"Project Zeus" -- How to Build a Cloud

Technical excellence, code ninjitsu, and pizza-fueled all-nighters. This is the very picture of what it must mean to build something awesome in software. Our collective fevered imaginations run to 4am Halo battles mixed with marathon code sessions, cheap beer with amazing algorithms, bean-bag-chair-naps with the very latest in technologies and platforms. When deadlines are close, and when the technology challenges are large, it means another marathon game of Wizards and Martyrs.

Clearly, I'm wrong. Maybe some products succeed when built using that model, but the reality is very different. The most important features of a successful development effort are: simplicity, pragmatism, flexibility, constraints, the willingness to work with instead of against the landscape, and most importantly, trust. This is the story of "Project Zeus", and how Contegix and Relevance worked together to build something cool.

The Problem

Contegix is moving into the cloud. They are already the best in the biz for managed hosting with their attention to customer service and technical competence. Now they are applying that excellence to cloud services. With 100% network and power uptime SLAs coupled with their legendary service, the platform should be a real home run.

Contegix chose to build on top of VMWare's ESX, vSphere and vCenter technologies. They needed a development partner to build the customer layer, where individual users could control all this kick-ass technology and bend it to their will. The system needs to be fast, stable, usable, and done. Perhaps most of all, it has to live peacefully with the ecosystem of apps Contegix already uses to help their customers.

The Solution

Relevance places extremely high value in the twin properties of simplicity and elegance. By simplicity, we mean the code should focus on the core values of the proposed system and leave out extraneous, minimally valuable fluff. The smaller the codebase, the better. By elegance, we mean that the code itself is easy to understand, readable and extendable by other developers. It should tell its own story, without needing one of us to stand over the monitor drawing air diagrams of complex interactions.

When the team began working on the project, it became quickly obvious that at its heart, "Project Zeus" is a messaging system. There is a web-based user experience, but the grand majority of the work being done is asynchronous communication between the user and the VMWare infrastructure assembled by Contegix. Which means our solution needed to focus on:

  • a lightweight web application for direct communication with the user
  • a messaging infrastructure for passing commands and results between the user and vCenter
  • a robust engine for manipulating vCenter to perform the user requested tasks which needed to be:
    • fault tolerant (we are dealing with cloud resources, here)
    • easily monitored for responsiveness, error rates, etc.
    • easily extendable as new features are designed and developed

Contegix has an existing investment in Java-based infrastructure and has built a reputation for hosting and managing Java solutions over a long history. They also have a keen interest in any technology that gets the job done. And it turns out that simplicity and elegance are at the top of their priority list, too.

The Messaging Infrastructure

This was easy. We chose ActiveMQ: an open source, proven, Java-based message queue. We love and trust open source, and the Java-based solutions are robust, well-tested and fit in well with the existing Contegix management infrastructure. It's also compatible with the popular Stomp protocol, so by adapting our system to Stomp we have the flexibility to swap out different queues if the need arises.

The Back End

We decided on JRuby for the back end implementation. vCenter exposes all of its functionality via a SOAP interface. There are two good wrappers for it already: a command-line Perl wrapper, and a Java proxy. For purposes of monitoring and process management, we decided that the Java proxy was the best way to go. Having made that decision, we knew our solution would have to run on the JVM. With JRuby, we could easily interact with the VIJava proxy for vCenter and still take advantage of the productivity and low-ceremony that Ruby provides on the back-end. Couple that with standard Java monitoring tools and we have an ideal solution for our asynchronous processing engine.

The Web Application

This also turned out to be an easy choice. There are no direct connections between the web interface and the backend; everything travels through the message queue. For scalability purposes, the web application and backend application will exist on separate servers. We had no limitations on what we could choose as our technology platform. Therefore, we went with the most productive, simplest platform we can think of: Rails 2.3.2 via Passenger.

The only special need is the inclusion of a Ruby Stomp client for interacting with the Java-based message queue. For this piece of the stack, we decided to use RosettaQueue as our messaging gateway library - this wraps the Stomp client, provides a clean interface for message consumers and publishers, and also provides clients for AMQP and beanstalkd if the need arises. We rolled RosettaQueue into the back-end as well, to keep things simple and consistent between the front-end and back-end wherever our code has to interact with the messaging system.

Everything else is just a normal Rails application, hosted via Passenger and the MRI. Since Contegix has a long history hosting Rails applications for their customers, they were perfectly happy with this solution for the web application.

The Result

So far, the results have been remarkably pleasing. We went from initial architectural decision to working demonstration in an extremely short period of time. Contegix is remarkably pleased with both the velocity of the feature development and the overall simplicity of the system. They can easily see how to manage the system once it is fully deployed, and how we can come back and extend it as user feedback is collected. Contegix is well on their way to a late summer roll-out with a feature-set and experience that is equal or better than any of its competitors.

Jul 08 2009


Triadic Programming

Since the Cold War, the secretive Dyadic Society has been stealthily sapping the strength of the software development community. Haven't heard of them? That just proves that they exist! To conceal the truth from programmers, the Dyads promote their ideology through proxies, using content-free blanket terms such as "best practices" and "design patterns."

You can fight the Dyads by avoiding so-called "best practices" such as

  • polymorphism via classes and methods
  • error handling via throwing and catching exceptions
  • thread-safe code via objects and locks

Notice the dyads: throw and catch, class and method, object and lock. In this keynote, you will see what the Dyads fear most: a set of Triadic techniques that break the Dyadic chokehold on developers everywhere:

  • polymorphism via structures, functions, and multiple dispatch
  • error handling via signals, handlers, and restarts
  • thread-safety via immutable data, references, and transactions

Remember: threedom is freedom.

Jul 07 2009


Relevance Agile Bibliography

You can't learn agile development by reading a book. But reading a few books, in parallel with training and trying out the techniques, helps a lot. These references constitute Relevance's recommended reading list for doing Agile development.

Our customers and students frequently ask us how they can learn more about how we work. We believe that Agile is not a process or method, but rather an attitude of constant reflection and improvement. Our favorite books and papers are about how to see, understand, and react to what's happening on our projects.

Three Essentials

Almost all technical books are about particulars: particular processes, platforms, techniques, or tools. These three books, though, are about the essence: the essence of programming, projects, and people. Other books may offer more immediate, concrete recommendations for your current situation. However, these books are the foundation. If you understand them, everything else will make more sense, and you will be able to make more effective use of more specific recommendations. We don't see these three books becoming dated anytime soon.

The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas. If there's only one book that every working programmer should read, this is it. "PragProg," as it's known, is about the essence of programming: what programmers really do, and how to get better at it.

Agile Software Development: The Cooperative Game (Second Edition) by Alistair Cockburn. This book is an awesome exploration of how to think about process and software, and how to adapt your process to the needs of your organization and project. This book attempts to get to the bottom of how software projects work and the factors that make them succeed or fail.

Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco and Timothy Lister. This book is aimed at software projects, but the focus is the human element: people and teams. Just as good and relevant today as when it was first published in 1987.

Software Development

The Mythical Man-Month: Essays on Software Engineering (Anniversary Edition), by Fred Brooks. This is the all-time classic about software project management. It predates Agile methods by a long time, but it's still packed with wisdom and insight, including compelling analyses of some of the problems with traditional development processes.

Patterns of Enterprise Application Architecture by Martin Fowler. Yes, it's a patterns book, but don't let that scare you away. It discusses the patterns in use by Rails, Django, JEE, and the tradeoffs and reasoning behind them. Whatever architectural style you usually prefer, this book provides a valuable dose of context by explaining the situations where that style may not be appropriate, and showing you a number of useful alternatives.

Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister. Methodology failure is just one of many kinds of risk your projects face. Unfortunately, most Agile books don't give risk management the attention it deserves. This book explains how and why to take risk seriously and manage it carefully. It's an excellent primer on risk analysis and how to plan for failure. (It also includes one of our favorite quotes: "Risk management is project management for grownups.")

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. We've known for years that a clean, expressive domain model that reflects the terminology of the problem domain makes every part of the development process easier. Eric Evans' book does a great job of explaining why that's true, and how to achieve a good domain model.

The Deadline: A Novel About Project Management by Tom DeMarco. Politics, intrigue, risk management, romance, kidnapping, schedule chicken, and spies. What more do you need to know?

I.M. Wright's Hard Code by Eric Brechner. This book deals specifically with the agile project manager role. Most importantly, it describes how to be a better manager in the "servant/master" model; rather than dictating to the team what to do, the manager sets direction and removes obstacles. That style works well in general, and especially well on an agile project. (Also, it has valuable tips on how to interact with other teams that are working on your project.)

Agile Methods

Extreme Programming Explained: Embrace Change (Second Edition) by Kent Beck. A concise and clear explanation of traditional software methodologies and why they are broken, and why XP works and is better. The first edition is rather detailed and prescriptive, focused on developers. The second edition has a higher-level viewpoint and is a bit more relaxed.

The Buzz About Bees: Biology of a Superorganism by Jürgen Tautz. Some people are unsure about agile methods because they don't feel comfortable with the idea of emergent behavior (i.e., simple, localized rules that result in complex, apparently organized large-scale effects). This book is an excellent explanation of that idea, with many insights that apply to human organizations.

A Simple Model of Agile Software Processes --or-- Extreme Programming Annealed by Glenn Vanderburg. This paper explains how a collection of focused practices, with very little overall coordination or up-front planning, can reliably lead to good results. Although the paper deals explicitly with Extreme Programming, the core idea---that agile processes consist of nested, optimized feedback loops at various scales---applies to other agile processes as well.

Agile Estimating and Planning by Mike Cohn. Agile teams still estimate costs, make plans, and set schedules. But we do it a bit differently. This book by Mike Cohn explains how an agile team sets plans, and how to change your thinking about plans and the ways that they help you.

Reflection and Responsiveness

Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. Kevlin Henney likes to say that some programmers with ten years of experience seem to have had the same year ten times. Some teams are like that, too. Experience isn't very valuable if you don't learn from it, and we've found that you can't just take that for granted. Retrospectives are wonderful for making sure you learn the right lessons from both your mistakes and your successes. This book can show you how.

Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald Weinberg. Even if you're not a consultant, this book is well worth reading. It's all about how to see problems, identify solutions, and communicate successfully within an organization. It's about effecting change from a position of very little power. Who hasn't needed to do that?

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam. This book is about thinking visually about processes and problems. It's also a great way to learn about low-cost, high impact techniques like paper-prototyping and ad hoc data visualization.

Personal Development

The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler. There's debate about whether agile development requires exceptional developers. But it's absolutely clear that having good developers helps a lot. Chad has written a wonderful book that can inspire you and others on your team to improve your craft and polish your skills. The entire team will benefit.

What Did You Say?: The Art of Giving and Receiving Feedback by Charles N. Seashore, Edith Whitfield Seashore, and Gerald M. Weinberg. Agile processes are all about efficient feedback, and feedback between and about people is an important part of that. But giving personal feedback is hard, and receiving it is even harder. This book can help you get better at giving feedback constructively and reacting to it positively. Unfortunately it's out of print, but of course used copies are available on Amazon or Alibris.

Beyond This List

The resources listed here are great places to start. We also offer training on agile practices. But there's a lot of other relevant literature. In fact, as a couple of the examples here demonstrate, there's a lot we can learn about software development by reading about other fields, and even about other species. (Our friends the Pragmatic Programmers once gained valuable insights about software development by reading about training in the nursing profession and U.S. Marine Corps warfare doctrine. And we've been learning a lot lately by reading about music theory, cognition, the practice of medicine, and the history of bridge engineering.)

Furthermore, things are still changing. This bibliography will probably look very different in five years or so. (In fact, you can probably think of good resources we've missed. Tell us in the comments!) We learn new things about programming, and about software teams, every year. Sometimes it may seem like we have it all figured out, but more often we suspect that our whole industry is still fumbling in the dark, only gradually coming to understand the fundamentals of software development.

We intend to keep reading and discovering, and you should too. It takes a long time to get really good at software development, and there's always room to improve. Read at least a few books on software development each year. Also, seek out some good blogs or online magazines that discuss these topics. There is a rich and fascinating dialogue happening all the time in the community of software developers. You owe it to yourself---and your team, and your employer---to be a part of it!

Jul 03 2009


Clojure in the Field

Clojure is getting a lot of positive buzz, but what is it like building and shipping a real application? In this talk, we will cover the good, the bad, and the ugly of commercial Clojure development, including:

  • BDD meets FP: how we adapted spec and test practices for functional code
  • To wrap or not to wrap: working with Java libraries
  • The learning curve: training a team of non-Clojurists on Clojure
  • What you will wish for: third-party libraries you should know about, plus some that don't exist yet
  • Good names or die: living without object context
  • Shipping it: how to manage staging and deployment of Clojure code

Experience with Clojure is useful but not a prerequisite; we will introduce the key concepts as we go.

Jun 17 2009


Focus, focus, focus

We've been doing technical training a long time, and we've discovered a general rule of thumb: the fifth day of a five-day class is generally worthless. Students are burned out, concentration has waned, and that is coupled with the fact that the last day is usually the most complex topics. All of which, taken together, means that information is just not usefully transmitted on the final day.

The other major issue is the length-of-course to primariness-of-focus ratio. Some technologies are complex enough to warrant long courses on the merits of the technology alone, but are not the main job of anybody on the team. Neal Ford once described these as "condiment technologies". Maybe Ruby, or Java, or C#, or Clojure is your hotdog; these technologies are the mustard. Even if the mustard is really really really good, nobody wants to spend a week eating just that.

We're trying to address this through the introduction of our new one-day training classes. The idea is to harness the power of programmers to focus insanely well for a short period of time. Instead of fighting against ADD all week, let's harness the obsessive power of the programmer's mind and hit one topic, really hard, for one day. We think that the energy expanded will have a higher return for the students, and the information will be retained and used.

Our first offering in this space is our jQuery course. jQuery is a perfect candidate due to its nature:

  • it's a library, not a language. While it has general purpose features, the programmer will be presumed to understand them before attending the class.
  • it has a limited application scope. It is used to build interactive web pages (DOM interaction, Ajax, general JavaScript extenstions)
  • it has some deeply interesting technical aspects. Is it a monad? How does it embody the ideas of functional programming? Is it different from raw JavaScript?

We think training courses like this are going to be more effective for a variety of technologies that programmers are being exposed to these days. Instead of making one massive course that programmers will have a hard time sitting through and concentrating during, pick one interesting topic and hammer it mercilessly for 8 hours. Sound familiar? That's pretty much how we work around here. And it plays into our other belief about technology training: it should be about inspiration and getting launched, not about exhaustive minutia. One day on jQuery is plenty to get productive and be inspired.

Jun 05 2009


Refactoring JavaScript, 2009 Edition

I am off to Dallas this morning to give an all-new version of the Refactoring JavaScript talk. This year, we will be looking at testing and refactoring jQuery plugins, using Screw.Unit, Smoke, and blue-ridge.

You can grab the slides here, but as usual the slides tell only a little of the story. Instead, grab the project itself, and use git's local history to start at the beginning and watch the refactorings step-by-step.

Jun 04 2009


Introduction to jQuery

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.

Along the way, 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

May 27 2009


Rifle-Oriented Programming with Clojure

If you come to Clojure from an object-oriented background, you may not know where to start. It is sort of like looking at a rifle for the first time and asking "But where do I put the arrows?"

Clojure solves the traditional problems of OO (and then some!) but it does it in different ways. To learn how to translate your arrows (encapsulation, polymorphism, and inheritance) into bullets, check out my new article in the May issue of NFJS, the Magazine.

Also: I'll be spending the summer on the NFJS circuit, talking about Clojure, Git, and other good things. Come see us.

Popular Tags