Are you using BDD, RSpec and Cucumber?

I want to share a story with you that's three months in the making.

In August of 2008, I attended the Agile 2008 conference in my hometown (well almost hometown... go Mississauga) of Toronto. I attended many great talks, met lots of interesting people, spent $150 on books and sat in on 4 great sessions. One of the best sessions I attended was Aslak Hellesoy's talk about Behavior Driven Development (BDD).  I was actually hoping for a tutorial style seminar on "This is how you use RSpec...", but what I got was far better than that.  We were lucky to see the grand debut of Cucumber.  If you haven't heard about Cucumber, then check it out!  It's a story testing framework built using Treetop and allows for more concise and expressive user story testing.  In fact, it has now replaced the Stories Specs in RSpec. 

(Useless Fact of the day:: Aslak named the framework after a sandwich his girlfriend was eating while he was writing the framework).

That night, I went home and tried playing with the framework.  Since he had given us essentially an alpha build that day, I ran into a few gem dependency problems that stopped me from moving on that night, but I vowed to get more information the next day.

I must have been wanting to learn this very much since the next morning, I without realizing sat close to Aslak in a fantastic session about Agile lessons and decided to introduce myself after the talk.  Aslak, like most in the ruby community, was very friendly and humble.  We spoke for a few minutes about the conference and Rails in general and then I brought up my questions about Cucumber.  Being a great author and maintainer, Aslak asked if I would pair with him to go over my concerns.  I though this was great so we grabbed a coffee and he started showing me the ins and outs of Cucumber and the overall BDD philosophy.  We wrote a few features together and he introduced me to the power of Webrat for testing views and controllers.  I was really starting to get the idea and when we were done I felt confident that I could apply BDD to my code in several projects.  

However, I fell into a common testing Anti-Pattern... I didn't do it! I told myself I would do it on the next project... and then the next etc... This continued until well, yesterday!  I have a great idea for a new crowd sourcing application and before I could even name it I was starting to write code... untested code!  Then I suddenly stopped in my tracks and had a Eureka moment!  The reason I hadn't used Cucumber or RSpec that much in projects was because I was scared!  I was actually scared of how much work it would take to learn and master it. When I realized this I realized how wrong that belief was. There had been lots of times when I had started learning something new and with some persistence and hard work I got it!  Since I am all about intentions, I decided to set an intention for this project.  I intend to not to write a single line of production code until it is backed up by Features and Specs.  I will work from the outside in and apply the principals I have learned so much about

So... where do I begin??  The documentation of course!  I breezed through the Cucumber Wiki at Github and started writing my first feature.  I got that feeling of excitement that I had that night when I first tried it.  Each letter I typed was reinforcing the fact that my production code was going to be better and better!  I loved the feeling. However, I noticed my myself thinking and feeling "Am I doing this right?  Is this how I should write it?  What If they use this feature as an anti-pattern"  Let's face it!  Testing has been said to be hard, so each time you try and do it you are bringing those beliefs and baggage with you... or at least I was. So what to do...  First of all, I pushed those out of my mind.  Remembered that I am a smart, resourceful person and kept hacking.

I know that Aslak hangs out in the #cucumber channel on irc.freenode.net from time to time, so I decided to go to the source! Upon entering the room I was a little disappointed that Aslak wasn't there, but recognized David Chelimsky so figured I would ask a question.  David is also an author of RSpec and an authoritative voice in the testing community, so who better to ask! David was so helpful and spent over 30 minutes with me helping me understand the connection between Cucumber and RSpec.  I also learned that he, Aslak, Dave Astels and the RSpec team are writing a Pragmatic Programmer book on BDD, RSpec and Cucumber.  While this is not the first Pragmatic Programmer book on unit testing, it is the first Pragmatic Programmer book to focus on Ruby on Rails testing. I can't wait for it to go Beta!  It's amazing how nice and open people are if you are willing to listen and learn from them.  So if you are really stuck, use IRC and ask insightful questions.  Don't go there to post anything, read the forums, read the docs, try it yourself and if you get stuck... head over to IRC to learn from the source.

Anyway long story short... for those with the same testing woes that I had here is my advice. JUST DO IT!  Drop out of your comfort zone and start writing Features and Specs TODAY!  Not tomorrow, TODAY.  Try it on a smaller project where you have full control so that when you have to use it at work or for something bigger, you know what you are doing and feel more confident selling it to peers or to yourself again. 

And remember the BDD Pipeline as passed on by David Chelimsky to me yesterday afternoon...

Features > Steps > Specs > Implementation > Specs Pass > Steps Pass > Features Pass > Reliable, Maintainable, More Thought Out, More Beautiful Code.

Start testing your code today!  Start using BDD or Shoulda do something to make your code better each day!  Make it an intention.  Write it down! Set your mind to it.  The only thing you have to loose is brittle code.

Kent

P.S. - Great intro talk about BDD and RSpec at InfoQ.  

P.P.S. - Also check out Obie Fernandez's The Rails Way with a great set of chapters looking at testing and BDD.

Crowdsourcing goes public

Let me start by sharing a story with you ...

Imagine that you have a problem, a huge problem! Your problem is that you need to give millions of people from all walks of life original high quality media each day. Sounds easy enough right?

Now imagine you have over 100 different news sources with thousands of pages of new content each day. Since you are very smart, you realize that you can't do this yourself. So, you hire a fantastic team of editors to help you. After a week or two you are happy, but you have only made a dent, your content is biased and shallow. You are trying to drink from a fire hose, there is too much information! Not only that, but there are lots of duplicate content and a whole bunch of crap and spam too! It becomes harder and harder for you to generate quality content with each passing day since content is being created exponentially and new sources are being added on a daily basis.

What can you do??

If this problem sounds familiar and sounds like it's been solved... it has. It was solved by Kevin Rose and everyone else over at Digg. They realized quickly that the hierarchical days of pushing media down the pipe was not going to scale for this and future generations. So what did they do? They gave away a certain degree of control and made everybody a contributor, editor and reader. They utilized the concept of crowdsourcing and changed the way a generation processed media.

Crowdsourcing is a very powerful and profound way of looking at problems. I will go out on a limb and say that I believe many of the hardest problems can only be solved using these kinds of methods. This goes back to Carl Jung's idea of the Collective Unconscious, human beings have an amazing way of sharing information. One day we will learn how to disseminate knowledge from the void but until then, the Internet is the next best thing.

I had a great talk today with a smart guy from Bean Bucket and we agreed that it's time to take these ideas and apply them to lots of different fields. I have one in the works that's been on paper for about 2 weeks, in TextMate for about a week and will be online in a few days.

Stay tuned... and get ready to count.

Looking for Common Threads

So I recently purchased and am in the process of listening to an audio series called the All Stars of Traffic. The series is dedicated to giving listeners a handful of strategies and tactics for driving traffic to your website. Overall this is a really good series since it opened my eyes to the power of AdWords and valid keyword SEO research, for that alone it was worth the money. In fact, I will probably go ahead and do a lot of the stuff they suggested in the next few weeks. However, there are still so many tactics that I can't help but feel are a fancy word for SPAM.

What I like to do when I am learning something new is get as much information that I can from different sources and look for the common threads. I believe this to be the single most powerful way to understanding the truth in any field. If you have different people, from different walks of life all telling you something different, but then... each of them gives you the same piece of advice. Each source has the same message. Each source says something that while different, is so similiar you can bet that its right, or better yet, more right than any of the alternatives.

In this case it was the Nike slogan. Just Do It!. It's the simplest and hardest thing to do in life... get up and do something rather than continue doing what you are doing. I'll bet if you spent enough time looking at most of our problems, you could pin them down to this idea. We love to listen but are afraid to act. We want to be driven but don't always like the drive. We are perfectly content to think that for some reason someone is smarter than us and there is no point in us doing it since someone will probably do it better anyway. And it can go on like this! So how does this relate to getting traffic to your website, it's simple... Do Something About it!. Don't do it tomorrow or the next day do it now! As my Dad always told me playing Hockey, You can't score if you don't shoot! and it's so true. You can't bring people to your site without a website, you can't bring to your website if they don't know about, you can expect them to know about unless you tell them about it. So let's all agree that we are going to take some inspired action and start doing things today, rather than waiting for tomorrow.

Windows Mobile Phone Factors

So how does one go about designing great software when the underlying tools leave much to be desired?

Don't worry, it was a rhetorical question.

Recently, I have been working on Friend Forecaster and its corresponding Windows Mobile software, aptly names, Friend Forecaster Mobile. Friend Forecaster will receive a proper introduction in due time, but essentially Friend Forecaster is a context aware application that tells you who you might see from your social network based on your location. What makes the project unique is that we are designing this software for senior citizens with Mild Cognitive Impairment, therefore our designs need to accommodate a typically older adult than most current cell phone applications.

As I have mentioned in previous posts, Window Mobile developers are blessed with a great set of tools from Microsoft. Microsoft Visual Studio makes so many things very easy and makes other things really hard. For example:

Easy

• Making a user interface without writing lots of layout code
• Deploying your application to different platforms
• Refactoring
• etc...

However, Windows Mobile itself makes some things very hard.

Hard

• Making an interface for someone who has never used a cell phone.
• Dealing with accessibility concerns
• Easily skinning buttons or other UI elements to make them look more custom.
• etc.

My list is by no means exhaustive, but in my opinion it's right on track with Microsoft's Pre-Vista mentality. Make it work! We'll worry about how it looks later.

This is all well and good since Windows Mobile is primary designed and used by the business world, but when you are trying to think outside the box, Microsoft seems to want to shove you back in.

Take for example their default menu bar at the bottom of each screen.

Look how small it is!

It is very hard tapping these buttons without using a stylus! You eventually get it and you learn how to manipulate your finger to do it, but this is basic interaction we are talking about.

So what can we do about it?

Well, there are a few options. You can go to places like Codeplex or Code Project and try to find some custom controls that do the job for you. The disadvantage with this is that using custom controls that you didn't write or that you don't understand is not advised.

A simpler option is to remove the default MenuBar control that gets generated for you, and replace it with your own. You can then make your own custom control or you can copy over the code for each form. Its best to keep your code as DRY as possible so creating a custom control is the best way to go.

Basically, all you have to do is increase the height of the MenuBar. The default size is around 10-15px depending on what brand of Windows Mobile you are using.

I have done user testing with a variety of users and it looks like the magic size is 30-35px. I haven't formalized a click test because I don't think its really necessary at this point, but a good heuristic should be to make those bottom buttons between 30-35px high.

One final heuristic is to make sure you use ALL of the space at the bottom of the screen. As you can see, I decided to make Friend Forecaster a full screen application which means it doesn't have a top NavigationBar, I did this to maximize screen space and also because our use cases don't need that kind of functionality. However, as soon as you add a visual element that occupies a fixed height, like a button... make sure you use all available height!

By default Windows Mobile will let you have one MenuBar button on either side while leaving the other side blank! Why would you do this! Use the entire space! If you only have one button, then make it fill the length of the screen!

I know what you must be thinking... Kent, all of this breaks the Soft Key interaction technique. You are right... it does. But we are living in a Touch Based world, and the need for Soft Keys is decreasing. It's very easy to map the functions of the Soft Keys to the bigger buttons, but in my experience there is no need.

Anyway, I hope this helps future Windows Mobile 6 software designers some time since users will bring this issue up within a week of testing. Let's hope that Microsoft delivers on their Windows Mobile 7 promises, and maybe we will never have to worry about this again.

The ball is in their court. Until then, the iPhone and Android will continue to eat away its precious market share.

Thank you

Beta books are awesome

I feel like I spend more money on Beta books than real books.

For those of you not familiar with the Pragmatic Programmers they have a great concept called "Beta Books". When they have a book idea, instead of sitting on it for a year and half before it's completed, they give it to the world in Beta form. The idea is simple enough: A good book, like good software, needs time to iterate in order to make it better. Beta books normally come out months before the actual release date and the authors and community of Beta readers start a dialogue. It's all very Agile. Readers can do simple things like point out typos and grammar problems, or more ambitious readers can critique the actual content, suggest better ways of implementing something or suggest additional content. In fact, if you look through some of the Pragmatic Programmer Forums you can see that some books went through significant changes before going to the presses. This process is fantastic and provides a better product in the end.

The latest in this series is a real gem, Cocoa Programming: A Quick-Start Guide for Developers.

I love this book for a lot of reasons but the main one has to be that I read and followed through the entire Beta Book (around 100 pages) in two nights. I wasn't rushing, but I moved through it quickly. I was excited to read more. I wanted to learn more! The idea of the book is to give programmers with no Objective-C or Cocoa experience a Feet First look at the language and more importantly, the tools that Mac OSX provides for building awesome Cocoa and iPhone applications. (Not totally true, because of the Apple NDA, they can't give much detail about the iPhone SDK, but most of the Cocoa topics apply so it's all good).

Daniel Steinberg does a really good job at getting you excited about the language and frameworks really early on. In true Agile form, you make little things that work throughout each chapter. In fact, your first project is to build a Web Browser. Yes... a browser. Granted, this is no Chrome or Safari but suddenly seeing how you might build your own robust one is not so far off. The book also encourages the courageous and inquisitive programmer to explore more advanced topics that he doesn't feel necessary to cover due to the scope of the book. All in all, this Beta book is shaping up for a great finish. I can't wait to re-read it as the iterations are released.

Thanks to Pragmatic Team for once again delivering books that I actually want to read!

Kent

Serving .cab files using Google

After spending some time trying to get nginx to serve up .cab files I found a really cheap, really easy alternative, Google Sites.

Google Sites is a great way to easily and quickly publish content to net for your users to download. For my Masters thesis, I am developing a mobile application that is currently being targeted at the windows mobile platform.  As much as I dislike many aspects of this platform (see my other posts). I really like how easy it is to deploy your application using the built in tools.   Microsoft has fantastic documentation for deploying your windows mobile application using the built in tools, however that is only half the battle.  Unless you want to send this file via email to all your users, they need a way to download it fom the web.

I tried getting the cab file up there in a few ways.  My application is written in Ruby on Rails and I am using a newly popularized rails server stack that sits on nginx.  Problem was the documentation for nginx isn't stellar for anything other than serving rails or django.  I had trouble configuring the mime types to server up the cab files consistently.  Cab files are really just a different form of compression like .rar or .zip but it wasn't recognizing it the way I wanted to.

Then it hit me!  Use Google Sites!

That's exactly what I did.  I posted the file that way and directed my users to that link on their mobile browsers.  Once they click it the file downloads and installs from there.  Google Sites also tracks versions of the same file which for me was perfect since the application is changing on a weekly basis.  I've been using it on the past couple of builds and it's been great!  Thank you Google for another fantastic service.

Kent

SqlCe Connection String

I am leaving this post for the generation of Windows Mobile programmers, who like me spent over 45 minutes trying to find how to get the connection string work for SQLCE 3.5 using the .Net Compact Framework.

I don't know why this information is so cryptic, or why I felt like Indiana Jones when I uncovered the truth!

Of Course its so simple!

Why didn't I find this sooner?

How come this wasn't in the first line of documentation?

If you are reading this post with earnest and eager anticipation like a child ready to devour an unopened present, then you will be saying the same thing in several minutes. Read on, read on.

Basically, unless you do some digging you will find that Microsoft did something less than obvious when setting up Database Connections using Visual Studio and a Mobile Device. You would expect to be able to use relative paths for everything right? It makes sense that if you create something in a given project, then to reference it you would use a relative path right? Well, you are clearly wrong! You have to use different paths depending on whether you are developing or deploying! Don't ask me why but you do!

I will not try and re-invent the wheel and give you all the details on how to set up the connection using Visual Studio since Sam Allen has done such a job of doing so here, http://dotnetperls.com/Content/SQLCE-Database-Use.aspx.

I ran into a few problems since Sam made a few assumptions that didn't work out for me and might cause some problems for others as well. He suggests using the system properties object like so,

Properties.Settings.Default.datanameConnectionString;


However, this doesn't always work depending on how you have your environment configured and when starting a Smart Device Project, you might not have access to this.

So really what you are looking for is something like this,

string conString = @"C:\work\projects\vsproject\database.sdf";
using (SqlCeConnection con = new SqlCeConnection(conString))
{
con.Open();
}


Problem is, Visual Studio assumes you know that all of the files for your Smart Device Project are copied to the Device you are deploying to. The default location is in the Program Files directory of your device. Okay, this sounds easy enough! Yet, if you read the documentation you will see this sprinkled around,

string conString = @"My Device\Program Files\SmartDeviceProject\database.sdf";


This does not work! It might have worked with .Net 2.0 or Visual Studio 2005, but it doesn't work with the newest software. Good news is that there is an easy fix! All you have to do is remember that Mobile Devices have a root directory '\'

So here it is! Are you ready? It's been a long journey but I was happy to go along with you.

SQLCE 3.5 Connection String for a Windows Mobile Device Project is...

string conString = @"\Program Files\SmartDeviceProject\database.sdf";


Where SmartDeviceProject is the name of your Project and database.sdf is the name of your database!

I hope this helps!

Good night,

Kent