- Brian Sletten
- Ken Sipe
- Matthew McCullough
- Neal Ford
- Venkat Subramaniam
- Laurie Williams
- Nathaniel Talbott
- Kevin Smith
- Brian Sam-Bodden
- Johanna Rothman
- Christopher Redinger
- Bob Payne
- Russ Olsen
- Andrea O. K. Wright
- Joe O'Brien
- Carl Lerche
- Rich Kilmer
- Yehuda Katz
- Stuart Halloway
- Chad Fowler
- Esther Derby
- Rick DeNatale
- David Bock
- Clifford Berg
Principal Consultant, CodeSherpas Inc.
David Bock is a Principal Consultant at CodeSherpas, a company he founded in 2007. Mr. Bock is also the President of the Northern Virginia Java Users Group, the Editor of O'Reilly's OnJava.com website, and a frequent speaker on technology in venues such as the No Fluff Just Stuff Software Symposiums.
In January 2006, Mr. Bock was honored by being awarded the title of Java Champion by a panel of esteemed leaders in the Java Community in a program sponsored by Sun. There are approximately 100 active Java Champions worldwide.
In addition to his public speaking and training activities, Mr. Bock actively consults as a software engineer, project manager, and team mentor for commercial and government clients.
Estimating is regarded as little little more than 'educating guessing', but so much can hang on the quality of those estimates. With good estimates we can set clear expectations for project delivery, but with bad estimates we can run over schedule and over budget, or worse. We often estimate when we know the least about the work that needs to get done - so how can we make the best of what is potentially a bad situation?
In this session we will look at how successful agile teams estimate the scope of work at the beginning of a project, estimate the amount of work that fits into any one iteration, track the work through the iteration, and the 'burn down' through the end of the project. We will look at 'low ceremony' estimation techniques like planning poker, trim down 'high ceremony' techniques like Wideband Delphi, and look at "FET+", an estimation technique originally developed as a foil for a CMMi effort.
With a little effort, a little planning, a little tracking, open communication, and some good metrics, estimation does not have to be a 'crystal ball' activity.
Agile development teams should always be looking for ways do develop software better, and the iteration is the perfect tool for doing so. Each iteration we can tweak, tune, adjust, and readjust our practices. So how does an agile team decide what to tweak? This is the purpose of the Agile Retrospective.
On one end of the spectrum we have the 15 minute "what works and what didn't" meeting, and on the other hand we have the "offsite summit" looking at the entire project timeline, from the first handshake with the client to the deployment of maintenance releases. Where do these kinds of meetings fit in the Agile project lifecycle? What kinds of things can we expect to learn? Are there any topics off-limits to the critiquing eye of improvement? How do we keep the focus on the software and not the people? Will we have to manage personnel conflict?
In this session we will learn how to run an agile retrospective while keeping focus on the goal: uncovering better ways of developing software.
Capistrano is the de-facto tool used to deploy Rails applications, but it is useful for so much more. In this talk we will publish a real website from scratch, with consideration for real world stuff like safeguarding passwords, turning on and off application monitoring, multiple machine deployments, and general system administration tasks.
In addition to a real deploy in-session, we will look at the real deploy scripts for several real-world, large websites involving multiple machine architectures, minimal (sub second) downtimes, and different server configurations.
(including side processes like backgroundrb and ferret)
Most developers who adopt Rails deploy their first application and see it get rushed under heavy load... thus the rumor that 'Rails doesn't scale'. Well, Rails does, you just have to know a few things
We will touch on a lot of things in this talk - measuring performance tuning your browser experience query tuning caching - built-in and plugins architectural modifications and more
Rails may be the framework that turned many of us on to Ruby, but if you are using it for all of your server-related Ruby projects, you probably have a hammer and are seeing every problem as a nail. There are a number of smaller, tighter solutions to problem in this space, including GServer (built into the Ruby libraries), StaticMatic and Webby (tools for generating a static site, but with all the templating goodness), Sinatra, a small server with an awesome DSL for restful web services, and Rack, an easy way to get content published as a web service.
We will spend a little bit of time of each of these, seeing how you can use each for a project where you might have previously considered Rails.
There are a lot of things we can measure about our source code, but what about the "project as a whole" and its overall health? Are there ways of measuring the effectiveness of our processes? Are there things we can measure that would point to project automation wins? Is there a way to measure team 'morale'?
While we can gather a lot of metrics from automated source inspection tools, those can make us focus on the wrong "problems to solve"... There are a lot of personal, team, and project-level things we can measure and tune that can lead to big wins. Using advice from an obsessive-compulsive numbers collector, the Personal Software Process, Scrum, the Pomodoro Time Management Technique, and Personal Kanban, we will discuss ways of effectively measuring aspects of our team and our productivity, and actions we might take based on what we learn.