Here are some tips I've learned to build more readable, flexible acceptance tests for iOS devices using Frank and Cucumber. See the full article on the Cyrus Cylinder:
The Cyrus Cylinder: Improve Your iOS Frank Cucumber Acceptance Tests
Here are some tips I've learned to build more readable, flexible acceptance tests for iOS devices using Frank and Cucumber. See the full article on the Cyrus Cylinder:
The Cyrus Cylinder: Improve Your iOS Frank Cucumber Acceptance Tests
Posted at 11:06 AM in Agile, Ruby, Testing, Writing | Permalink | Comments (0) | TrackBack (0)
My first experience with Extreme Programming (XP) was in 2000 after reading the "Extreme Programming Explained" book by Kent Beck, and it got me pretty excited about building software in a new, collaborative way. After taking "The Art of Agile" course* by James Shore and Diana Larsen last year, I felt a sense of excitement similar to when I learned about XP over 10 years ago. The course refreshed me on the principles, values, and practices followed by high-performing Agile teams, and re-energized my pursuit of building great teams that deliver valuable software. But the course wasn't just a refresher, it also contained new material that I felt made it relevant for today's market:
I took this course with my entire company -- yes, that means all forty-some people at Cyrus Innovation, from software developers to operations and sales folks, with experience levels ranging from new to Agile and Extreme Programming to seasoned practitioners. We gave the course excellent reviews across the board; everyone walked away with something they could use immediately on their teams. As a team member, it felt great to have a shared group experience and consensus about the fundamental way we work.
So here's the "Hair Club for Men" moment -- we at Cyrus Innovation like this course so much, and felt it was so valuable to us as a company, that we decided to partner with James and Diana to offer this course again to the public in New York. It was a fun course, memorable, and interactive - including a fully immersive series of four iterations building a real software product. I think this course could be valuable to people who are just learning about Agile software development and to folks with experience looking to get reinvigorated about Agile and XP. And taken as a team, I think there are huge benefits in the form of shared context, vision, and momentum that can translate immediately to new or long-lived teams and projects.
For more details, check out artofagilenyc.com.
* Technically it's two courses in one week: "The Art of Agile Planning" and "The Art of Agile Delivery".
Posted at 03:39 PM in Agile | Permalink | Comments (0) | TrackBack (0)
If you're like me, you might be looking for more ways to get feedback about your software's continuous integration build process. Here's one of my favorites: the BuildBunny plug-in for TeamCity will send build status announcements to a Nabaztag rabbit.
Version 0.3 has just been posted (look for it on the Downloads page). This release include several little enhancements to the plug-in, including a patch I contributed that enables you to specify a different Text-To-Speech voice to use for the announcements. To me, the U.S. voices are the lowest fidelity, while some of the U.K. voices are much easier to understand. I like "UK-Leonard" and "UK-Penelope".
If you want to find a list of all the voices supported by your rabbit, you can send it a message using its API. Check for action 9 - "Get a list of all supported languages/voices".
A few months ago I read that Violet, the Nabaztag creator, had filed for bankruptcy. Anyone know what's going on with them?
Posted at 07:01 PM in Agile | Permalink | Comments (0) | TrackBack (0)
There’s a lot of Spinal Tap activity these days, which is no
surprise given that the rock “mockumentary” This
is Spinal Tap celebrates its 25th anniversary this year. The recent “Unwigged and Unplugged”
tour featuring Michael McKean, Christopher Guest, and Harry Shearer playing Spinal
Tap and other songs has just been released on DVD. Spinal Tap re-recorded several of their songs with several
celebrity guests and released the “Back from the Dead” album.
While listening to the Keith Emerson-featured “Heavy Duty”, I started thinking about some lessons we can learn from Tap in the software world:
1. What the customer asks for isn’t always what they want. (a.k.a. “the Stonehenge principle”) As famously demonstrated when the band provided the specifications to the stage prop for their epic Stonehenge, the customer wasn’t happy when they got exactly what they asked for. When building software, we need to listen to the customer describe what they want, then deliver frequently and get feedback to make sure they get what they need.
2. Experiment, but avoid the Jazz Odyssey. Experimentation is a good thing; it leads to innovation, productivity improvements, and insight into difficult problems. But self-indulgent experimentation without focus is counterproductive. Here I’m thinking of technical design and refactoring experiments/spikes – make sure you have an objective so you’ll finish having learned something.
3. The performance is best when the band is together. Nigel Tufnel and David St. Hubbins fought frequently, but productively resolving the conflict and channeling that energy led the band to write and perform at their best. Derek Smalls acted as the facilitator (“lukewarm water” to Nigel’s fire and David’s ice), a role that is needed to help software teams stay together. As Esther Derby and Diana Larsen taught me at the Secrets of Agile Teamwork workshop, this facilitator role doesn’t always have to be one person – it can rotate, as can many of the other roles of Agile Leadership.
4. Good tools go to eleven. Spinal Tap required special amplifiers to create their distinctive sound that gave them the title of “England’s Loudest Band”. While the movie example is a gag, I can identify with the reverence that Nigel displays when describing his favorite amp. For me, I get that same feeling when using IntelliJ IDEA – it continues to delight me after all these years of day-to-day use. The lesson is simple – good tools make us more productive.
5. “Have a good time, all the time”. This rock & roll philosophy offered by keyboardist Viv Savage is important to remember. Many of us got into software development because it was fun, but it’s easy to forget when we get stressed out by some deadline or difficult bug. Brian Marick mentions joy as one of the key values of great teams, and I agree – I’ve done my best work when I was having a good time.
What about you? Have you got any favorite Spinal Tap-isms that apply to software development?
Posted at 02:44 PM in Agile | Permalink | Comments (1) | TrackBack (0)
Here are the resource and reference links for the Agile 2009 talk "Agile AJAX: The Google Web Toolkit Experience" that Paul Infield-Harm and I are presenting.
Source code for the Book Stack demo presented in the talk is available on github:
http://github.com/pinfieldharm/Agile-2009-GWT-Demo/tree/master
"Google Web Toolkit: Your Shortcut to Ajax Web Applications" by Daniel Wellman
An overview of GWT, appeared in Better Software magazine in October 2008.
"Reveling in Constraints" by Bruce Johnson, GWT Tech Lead. acmqueue, Vol. 7 No. 6 - July 2009
Explains why the GWT team chose Java and how GWT solves common AJAX development problems.
The Tutorial on the Google Web Toolkit project page is an excellent way to tour the framework
Matt Raible's (of AppFuse fame) comparison of GWT, Dojo, YUI, and Ext JS
A balanced discussion at Stack Overflow about GWT pros and cons
"GUI Architectures" by Martin Fowler, which include the Supervising Controller and Passive View variations.
"The Humble Dialog Box", by Michael Feathers is one of the original papers on designing testable GUIs.
"Presenter First", by Atomic Objects is a pattern similar to MVP used for building GUIs test-first.
"Google Web Toolkit: Writing Ajax Applications Test-First" by Daniel Wellman
Explains the different ways to test GWT applications, including an example of using Model-View-Presenter. This article was also adapted and included in the GWT documentation as Testing Methodologies Using Google Web Toolkit.
Matt Raible's blog "Testing GWT Applications" lists many online articles for GWT testing.
My blog "Mocking GWT Widgets with GWTMockUtilities" explains how to write plain ol' JUnit TestCases when you need to mock GWT widgets, instead of requiring a GWTTestCase.
Google Testing on the Toilet: Testing GWT without GWTTestCase from August 8, 2009 provides more information on MVP in GWT.
My other blog posts on GWT
onGWT is a news site with frequent updates
Google I/O 2009 Session Videos contain a lot of useful tips about GWT
Google Gin provides Guice-style dependency injection for client-side GWT code.
Posted at 12:39 PM in Agile, GWT, Presentations | Permalink | Comments (0) | TrackBack (0)
Paul Infield-Harm and I will be presenting a talk entitled "Agile AJAX: The Google Web Toolkit Experience" at the upcoming Agile 2009 conference. We'll provide a brief introduction to GWT, talk about how GWT fits (or doesn't) with Agile development practices, and discuss how to tell when GWT might be appropriate for a project.
We're looking forward to the conference and hope to see you there!
Posted at 10:19 AM in Agile, GWT | Permalink | Comments (0) | TrackBack (0)
I've started a blog on the StickyMinds website; I'll try to post a new entry every week on topics which include software development, process, and testing.
This brings up the question: "How do I decide which site to use for any given blog post?" My current strategy is to post the more code and tool-specific items here (such as GWT, Scala, etc.) and post the rest at the StickyMinds blog site. I'm sure this will change, so watch this space.
Thanks to Joey McAllister and the folks at StickyMinds for this great opportunity.
Posted at 10:18 AM in Agile, Testing, Weblogs, Writing | Permalink | Comments (0) | TrackBack (0)
Brian Marick recently gave a keynote at the Agile Development Practices conference; he's posted the text of the speech on his blog. It's called "Seven Years Later: What the Agile Manifesto Left Out", and is a good read about the start of Agile and where teams need to improve.
James Shore posted an entry on his blog entitled "The Decline and Fall of Agile" which gives a similar description of some of the problems many teams trying to adopt Agile have experienced. Scrum in particular gets a heavy knock, and I've seen similar results in my experience -- a team starts with Scrum and makes significant improvements in their process and planning, but the vast amount of technical debt and bad code drags the project down like a boat anchor.
Both are excellent posts and well worth reading if you're interested in Agile.
Posted at 08:55 PM in Agile, Weblogs | Permalink | Comments (0) | TrackBack (0)