A year ago this week, I first picked up Brian Marick‘s Everyday Scripting with Ruby and gave it a whirl. This week saw me branching out past automating web application checking to creating my own Ruby application.
I haven’t been a code monkey in many a moon, but my company’s recent innovation week gave me the perfect opportunity to try an alternate role. I anticipated either glorious success or failure – and as a tester I’m seasoned at failing gloriously so I was set to be happy whatever the results.
This time around, anyone in the company could propose an idea, perhaps even customer requests of suitable scope. The projects had to be related to our core business but the Lab Days crew encouraged us to try new teams or even new team roles.
Getting to hear and understand ideas from of our team and our customers. Small things that are annoying, new things that will open the door for a myriad of other possibilities and things I never would have thought would complement our existing solutions are all displayed during Lab Days. — Concetta
Since I had only a week of development time available, I chose a project with limited scope: a small utility that would detect information in the data warehouse and email an interested party about it. I planned to develop the simplest thing that could possibly work, which was important working as a team of one. I did not have any software developers to help me with structuring the program, though I did describe my plan to my regular product team folks, who also estimated that it would achievable.
Test-driven development was one of my goals for this project and this was my first time trying it as a programmer. Granted, I have been writing RSpec stubs for my web automation for a year, but I didn’t have to build all of that from scratch on my own. This time around, I began as usual for a story in our Scrum sprints by writing out the tests that I knew would indicate success before delving into the code mines.
As a result of coding solo, I spent quite a bit more time evaluating and troubleshooting Ruby gems than I would otherwise. While this was frustrating at times, I had a chance to form a better impression of the Ruby community and the problems they were trying to solve, gleaned from the gems tailored to different purposes. As it turned out, there aren’t a lot of Rubyists working with MSSQLServer in a Windows environment, as I was trying to do. I even went down the rabbit trail of evaluating Rails development until self-taught MVC under a tight deadline sounded questionable to me.
Undeterred, I dug up some promising leads and made some experiments, most of which failed. I learned a lot of ways not to solve my problem! However, for success you only need one and I found a way. Once I was able to communicate with my data and my email, all that remained was the business logic. Granted, by this time I was halfway through my week, but I had my infrastructure and I had my tests as goals.
I began with familiar code structures I’d used formerly in pseudocode, Visual Basic, and Java. However, I knew Ruby had its own interesting expressions, as I had noticed while studying my pickaxe. At this point, I decided to learn a bit more about the Ruby idioms and so cracked open an ebook version of Why’s Poignant Guide. This made for an entertaining intermission and pointed me in the right direction to enhance my code to be Ruby-style. I’m sure my Rubyist friends would still cringe, but I wasn’t expecting to have production-ready results as a Ruby newbie.
One-by-one my tests went from red to green. All of this gave me much more confidence that my changes were stable, which turned out to be essential. The morning of the competition presentations, I discovered a fatal flaw in my project: although it worked as designed, the data warehouse SLA for the data I was analyzing had a lag of 24 hours rather than the real-time I had anticipated. With the help of some coworkers in the know, I went to the source and found the real-time data. Fortunately, this last minute coding was an alternate implementation of the database interface and did not affect my program’s overall structure. Here here for modularity and DRY principles!
Out of time but satisfied with my progress, I was able to live demo the first solution against the data warehouse. However, I knew that what I really wanted was an end-to-end test from the source application all the way through to the email account, so I continued working and completed that while the competition voting period was still open. While I didn’t get a chance to present my enhanced code to the group, I had the satisfaction of knowing that my tracer bullet had found its target. And what’s more I had a backlog of enhancements needed for production-readiness prepared for the next iteration – if there is one. Anticipating that this project will become a product in the future, I also completed a proof of concept using tests against an API for the source data that’s in the works, applying some of my learning from Alex Kell‘s recent interface testing presentation to the Agile Atlanta group.
While my project did not find a place in the innovation week competition winners circle, I felt like a winner for having the drive and execution to complete even a small application on my own. Since I learned more about my company’s product suite, data warehouses, interface testing, Ruby, and TDD through RSpec in the process, I call the experiment an unquestionable success. I carry forward all these skills to my day-to-day work and can plan my usual testing with much more context.
So while Ruby and I are still in the early stages of our relationship, I think our first anniversary together was a shining moment.