Louis Salin's Blog

I don't just code

2010-03-07T16:16:00Z

I have an obscure, personal blog to which I fled back to recently. I posted the following entry:

Well whadaya know? I'm having existential doubts these days. There's a battle that rages inside of me every time I get a little bit of free time: what should I spend my precious little time on? Until recently, I had been trying to get an enterprise-y application going, but it filled me with dread. Every line of code had to be extracted from my body with forceps, put into place and tested. It was a fine equilibrium, a delicate balance that I maintained by making myself believe that this is what I wanted to do. It was more that just something to do on a rainy day; it was more than just a reason to go out and hang out in a coffee shop all afternoon on Sundays. It was what I wanted to do. But I hated it. Well, most of it.

Anyway, that balance tipped over when I lost control of the app. Slowly, I stopped unit testing features. Then I simply started hacking it without too much thought or process. I started drifting. Thoughts would come and distract me. What is the next big thing? How can I become hugely successful and never have to worry about money again? Should I remain a Windows developer, forever branded as a .Net guy, or should I venture to the free ecosystem that is Linux? What about Mono? Oh, I could write server apps with Mono! But what about Lisp? I've always wanted to learn Lisp! I could write a Command & Query type application and start with the Login system and write it in Lisp. Or even better yet, I should write a .Net version of Common Lisp, just like that dude that wrote Clojure on top of the JVM. And of course, it would have to be done entirely by using the command line and VIM... Is there a book on Amazon for VIM?..

And on, and on, and on it would go. Every Sunday. Torture. I would power on my laptop and sit transfixed in front of the monitor, my hands calmly positioned over the keyboard. There would be a shell prompt and a VIM window open, waiting. Oh, the possibilities! And yet, I couldn't come up with anything to do. Eventually, I'd give up and log on to twitter, facebook, news.ycombinator, arstechica, slashdot, news.google, nytime, programmer-looking-for-a-problem-to-solve-that-wont-bore-him-to-death.com... I'd then slam shut the laptop lid and be in a funky mood all day. Hell, that's exactly what happened today. Again!

Except that today I decided it was all over. I would stop wasting the rest of my life pursuing something I'm starting to feel weak at. Focus on my strength. That's what I need to do! But then I read a blog post about using object databases and cracked open my Common Lisp book. Damn it! I feel excited about programming again. It makes me feel like getting my laptop down from the shelf where it's quietly sitting and hack on something.

Why?

I'm clearly passionate about something! I just can't put my finger on it. So here's what I'm going to do. I'm gonna blog about that until I figure out what it is. Yeah. Blogging. That's so 2005! It's so not the next big thing.... oh... here I go again!

It's only been a month, and already my mind is on something else. You guys have read my posts, or if you haven't, go check my post history. I'm all over the place! Why the hell did I want to learn Lisp? Why go away from what I know best? I think we all want to do something significant in life. We all want to get better. But in my case, I clearly need some focus. Instead of learning something new and obscure (and hard!), why not get better at what I already do? I'll admit it: I'm not a spare time or weekend coder. I can't do it. I don't pull the all nighters. I don't stay up until 2am at night. I actually try to get between 8 and 9 hours of sleep every night because that's what makes me feel great during the day. This sort of balance is what I need. When I try to focus too much on code, I end up developing this allergic reaction that causes the kind of posts I just showed you. It's not fun. Yet, I envy all of you who do code all the time. I feel that not doing it slows me down on my journey to become a better programmer.

I suppose the journey is what's important. The important thing is that we go forward. The pace doesn't matter. As for me, I'm not forcing myself to code anymore. I'm enjoying my time with my family and feel I'm a better developer at work because of it.

Fun with Mono.Cecil

2009-11-25T22:35:00Z

During the past couple of days, I took it upon myself to automatically generate documentation about our "Scriptable" methods. These methods are used to provide an entry point into our Silverlight application for our automated acceptance test suite. Since we do not run our tests from the browser, which is currently the only way to go with an out-of-box tool, we decided to write our tests with RSpec, in Ruby, by using Watir to start up a web browser and connect to our application. Since Silverlight is inaccessible through the DOM, our scriptable methods are the only way we have access to our controls. I've talked about this whole process in the past.

Basically, a scriptable method is a method that has a ScriptableMemberAttribute on it. The Silverlight plugin takes those methods and makes them accessible through Javascript, which is how we can call them from our Ruby test suite. Most of our views and controls have a bunch of of those and things have gotten a bit out of hand. One of the things that really slows us down while writing tests is just figuring out how to get access to a certain control. For example, starting from the main view, what is the path of scriptable methods that you must take to get to the latest error message? It might be: Main View -> Sidebar Control -> Menu Item #6 -> Error Message Panel. If you don't know your way, you have to set breakpoints in your code and manually, through trial and error, figure out how to get to where you want to go.

Enough! Now, we have a crude, basic, version 1 Html Scriptable Method Generator 3000 (tm)!

First thing that had to be done was load up our web client assembly and reflect on it. I quickly hit a wall when the Microsoft reflection utilities would refuse to load it up. I realized that it was a Silverlight library that I was trying to load and that I would have to create a Silverlight solution instead of a regular, normal CLR solution. You see, there is a difference between the two .Net runtimes. A normal CLR application cannot reflect upon a Silverlight library, which is compiled using the Core CLR. (I also wrote about this in the past)

Darn!

Thankfully, however, somebody suggested on stackoverflow.com to use Mono.Cecil instead.

Mono.Cecil is a library that allows you to reflect on assemblies, basically. But it can do much more. As my colleague Gabriel has blogged about, it can allow you to inject CIL code into a compile library. It will even let you inspect all you anonymous methods in your code. Is it hard to use? Nope! Just download the dll, add it to your project references and you're good to go. Windows or Linux, Monodevelop or Visual Studio; it just works (tm).

Documentation is spread out a bit everywhere, but I found this to be really helpful to start with: the Mono.Cecil FAQ. Additionally, Google will help you find a bunch of usage examples. I would post some code, except that I didn't do anything that you can't find in the FAQ that I linked to above. The scriptable doc generator loops over all the methods that have a ScriptableMemberAttribute on them, using the main view as a starting point, and generates a tree where each node is a scriptable method, it's return type and a sub-tree of child scriptable methods. Using that tree, the generator creates an Html file for each class that has scriptable methods and lists all of those methods in an unordered list.

I plan on making this better in the future by adding links and collapsible tree views. It'll also be very cool to add it to our continuous integration system to update a wiki site whenever a build is finished. And ultimately, I hope this makes us much, much faster in writing our tests. Eliminating waste is always the ultimate goal.

The Passionate Programmer Book Review

2009-11-15T22:19:00Z

Earlier this year, I've been given the chance to read any book of my choice from the Pragmatic Programmer bookshelf and write a quick review. Being so focused right now on figuring out where I want to go with my career, I thought I'd give The Passionate Programmer a try. I mean, who doesn't want to be passionate about their job? Loving what you do makes it fun and this is the key to a very successful career! I don't think I can do it justice until I've tried to put into practice most of what the author is preaching in the book, so here is a quick and dirty review of the book. (spoiler: I liked the book!)

The author, Chad Fowler, didn't get his start by getting a degree in computer science. Yet, he has accomplished more in his career than most software developers will ever do in their lifespan. So he must be doing something right, no? Well, the book might not teach you how to be passionate about anything. However, it will give you great pointers to make a great career out of software programming, which might make you passionate about the whole thing, I guess.

The book is divided into five independent parts, each of which you need to give serious thought to if you're ever going to become great at what you do, and remain great. In each part are multiple, small chapters of about two to three pages long, that will give you some hopefully valuable insight about growing you skills, finding mentors, pleasing your managers, how not to panic in dire situations and being careful about market changes, among many, various others topics. All in all, there are 53 "tips" in the book and I must say that most of them are very useful.

I would've wished that not all of those tips be written as if it was a recipe for success. Every single one ends with a "Act on it" section with exercises that are bound to put some of us out of our comfort zone. But maybe that's a good thing! Any day, I can open up the book and re-read one of the tips that I know I should be working on. There is no doubt in my mind that I can become a remarkable programmer by working on my weaknesses, and Chad covers most of them in his book.

This isn't a book that you'll read cover to cover. The optimal way to get through it, in my opinion, is to read it one chapter or two at a time and quickly put into practice what was read before progressing any further. Incidentally, this makes the book a very easy read; you could be spending only 15 minutes every night reading this book. But to make it effective, you'll need to actively put it into practice. I know I will. And I know I'll probably end up re-reading it a couple of times.

I have read the 7 Habits of Highly Successful People and Who Moved My Cheese and Chad's book reminded me of them. Because of that, I can only recommend this book to all my peers, unless you are already at the top of your game. Then maybe you should write your own book too! Oh wait, that's one of the tips in The Passionate Programmer!

Gtk# for .Net Developers, part II

2009-10-16T02:41:00Z

In the first post in this series we went over the details of creating a new desktop application using Gtk# using MonoDevelop. The main reason for doing that was to get acquainted with the IDE and the way it creates and manages the Gtk# code for us, behind the scene. This time, we'll stay strictly on the front side, using MonoDevelop's tools to create a simple UI with a simple layout and place buttons and labels on the screen. Nothing too complicated, really.

I'd like to point out that there are some excellent tutorials out there that you can check out, including:
- a tutorial that is very similar to what this series is about, except without using MonoDevelop
- the tutorials on the mono project's own website

What is written here is not novel (if you'll pardon the pun!) I'm just taking a shot at it from a different perspective. If you've written desktop applications on Windows, most of what you'll read here will be very familiar. Just reading the tutorials above will teach you what you need to know. I hope, however, to save you the few minutes or hours that you will spend figuring out the few features that are not as well documented.

That being said, let's get started!

I'd like to add two buttons to our application. One that will close the main window, and the other one that will change the text on a label that sits somewhere around the center of the window. For this, we will use Gtk's excellent abilities at layering and positioning controls (or widgets, remember?) on the screen. We'll stack the buttons on the right hand side of the window and center the label in the remaining empty space. Open up the project that we created in the last post and open up the MainWindow.cs file. At the bottom, you'll see that you can view this file in two ways: view the source code, of view the designer. Select the designer view.

The first thing we need to do is add a container, which is a type control that is used by Gtk# to define your UI layout. There are a few that are available to us right out of the box and what we want is something that will allow us to have the buttons on the left and an empty space on the right. Open up the toolbox tab on the right and take a look at was is in the containers list:

Drag an HBox onto the main window:

An HBox is a container that is used to layout your UI in any number of vertical columns. As you can see, the default amount of columns is three. However, we only need two but fortunately, adding and removing columns is easy enough. Right click on any columns and select the delete option in the context menu.

You can edit the properties of any widget or container from the properties tab on the right. Select and rename the HBox by using the combo box right above the UI builder window, then open up that properties tab:

We are now ready to stack our buttons. Go back to the toolbox and drag a VBox to the leftmost column:

As you can see, VBoxes and HBoxes are exactly the same, differing only in their alignement. Just like with the HBox, we have one too many rows in our VBox so go ahead and remove one. Then, drag a button from the toolbox into each of the remaining rows:

It's interesting to see how the buttons are automatically stacked at the top of the window. The reason why is that you can specify how widgets are packed inside a container. Select a button and go take a look at its properties. Expand the Box Child Layout category. In there, you can adjust the pack type and the position of the widget. The pack type tells Gtk# to put that button either at the start or at the end of a container. By selecting end, the selected button would be put at the bottom of the screen. You can also change the position of the button. Gtk# will then put it at position x, starting from the top or bottom, depending on the selected pack type. Note that the position is 0 based. Go ahead and play with those and see what happens. You can also play with the pack type and positioning of the VBox itself!

Alright, let's rename those buttons.

I'd like to quickly mention that in the Common Widget Properties categories, you'll surely use the Sensitive property. In .Net talk, it means Enabled. Yes, Sensitive == Enabled. It took me a while to find that one!

Open up the Button Properties category and change the name and label of the buttons. Name one "Quit" and the other "Change Text". Did you happen to notice the Button Type property? I've never played with it, but having the ability to put images and text on a button right out of the box is pretty sweet!

Now, go and drag a Label widget from the toolbox into the empty remaining space in the window. Great, it's centered vertically, but not horizontally. Open up its properties and in the Box Child Layout section, unselect Auto Size and then check the Expand and Fill check boxes. There, it's centered now. Go ahead, compile and run the app and bask in the glory of having done something with Gtk#!

Have you basked in the glory? Good. Now we really should think about making those buttons do something. You might have noticed the Signals tab when looking at a widget's properties. This is where we hook up a method in our class to an event, called signals.

The screenshot above shows the signals that are available for a button widget. Go to the Clicked signals and enter in "OnClicked" in the textbox next to it. Then, go back to the source code for our MainWindow class. You should see a new OnClicked method that has been created for you. Edit the method and add the following code:

   1:  protected virtual void OnClicked (object sender, System.EventArgs e)

   2:  {

   3:      centerLabel.Text = "Clicked!";

   4:  }

This will simply change the text on the label that we put in the center of the screen. If you didn't name your label widget "centerLabel", just use whatever name you chose in the code. Run the app, click on the button, and the text will change! A small step for man, a giant step for humanity... or something like that!

Finally, go back to the signals panel of the Quit button and add a Clicked signal. In your method, enter the following line:

   1:  Application.Quit();

which will close the app.

That's it for this post. Nothing special was presented, really. The main thing I wanted to showcase is the the layout capabilities of Gtk#, which is what I found to be highly refreshing, coming from a Windows Forms world. In the next post, we'll check out the code that was generated for us in the background while we were draging and dropping widgets on the screen.

Thanks for reading!

Mono, open source and Azure

2009-10-10T16:16:00Z

I've got this theory and it seems like all the pieces kinda fit together: Microsoft building an open standard CLR, Novell building Mono so that .Net apps can run on multiple platforms, Microsoft slowly warming up to open source and dynamic languages with Iron Ruby and the CodePlex foundation, and Microsoft's new Azure cloud services. Now, how could Microsoft think it can compete in the cloud services arena when so many big players are already entrenched and actively building up their technologies?

There's only one way. They need leverage. They need us, .Net developers. Microsoft has known for a long time that the future of computing involved the Internet but has failed to develop a technology that would make them leaders in the same way Bill Gates recognized that micro-processors were going to be the next big thing back in the, er... what, early 80s?

With cloud services popping up left and right, Microsoft probably thinks that this is it! It might be too late, but they have no choice. The threat of the Internet browser being the OS of the future is looming over them and they can't ignore it, lest they become one of those old dinosaurs that die with their obsolete technologies. So Azure is coming and Microsoft will try to stay young and hip and hang out with the young ones.

But it's got one advantage that the others don't. There are a lot of .Net developers in the world and finding a way to get them to develop on Azure, along with the monthly bills, might very well make Microsoft relevant again. But can it do more than that? Well, what if Linux developers could write .Net applications? What if Ruby enthusiasts could write .Net applications? What if Python developers could write .Net applications? With Mono, the DLR, IronRuby and IronPython, Microsoft can very well convert a lot of developers to its new platform.

And that is why I think Mono developers are safe from litigation from Microsoft. It benefits the behemoth not to turn those people away. Everyone that is somehow linked to .Net is a potential for extra monthly revenue, and who would purposefully slash away at their potential market? I think Microsoft has come to realize that with the current state of the web, it has lost its monopoly on everything except corporate IT, and even that under threat. IE won't save them, ASP.Net won't save them, SQL Server won't save them. Azure just might, though, if Microsoft plays its cards just right.

Gtk# for .Net developers

2009-09-30T01:18:00Z

This is going to be my first post in a series about my experience using Gtk#, a choice I made a few months ago when I decided to build my next .Net app on Linux and Mono. I've always thought that Mono was worth exploring and as I've mentioned before, the experience has been very easy going so far.

The wikipedia entry on Gtk# says that it is basically a set of .Net bindings for the GTK+ GUI toolkit, which stands for GIMP ToolKit. GTK+ was created specifically for the UI of the GIMP, the most popular open source raster graphics editor. Since then, GNOME, a widely used window manager that runs on top of X11, also started using this library for its UI and by extension all software written for GNOME also uses GTK+.

If you would like to follow along and try out the code examples in this series, it would be easier to install Mono on your Linux distribution of choice, or install Gtk# and Mono on your Windows machine, which you can download from here. All of my examples have been created with MonoDevelop and I encourage you to try it out, simply because of its UI builder. Using Visual Studio will work, but to take advantage of having all your UI Gtk# code generated for you, MonoDevelop is a must.>

Differences between WinForms and Gtk#

I assume that most of you, just like myself, come from a .Net background with a lot of experience building Win Forms or (gasp!) Web Forms. As I learn more and more about Gtk#, I discover new tricks and tools that I suddenly wish I'd have know about in the past. As WinForms developers, or even web developers in a Windows world, we are very much isolated from different technologies that exist outside of Microsoft's ecosystem. So for me, discovering and using Gtk# seemed like a bit of fresh air sprinkled with some wonderment!

So let's see what is different between WinForms and Gtk#.

The main difference is that WinForms use a static layout scheme, whereas Gtk# layouts grow and shrink automatically as you re-size the window, which has technically always been a pain to do on a WinForm application. I mean, how many of you have used SQL Server in the past and just stood there in puzzlement over why the dialog boxes were not resizable, forcing you to scroll down or to read a 100 pixel wide textbox with at least 200 characters in it?. How much time have you also spent trying to make your apps resize gracefully?

Gtk# controls, which are called widgets, must be part of a container and will either fill up the container's space or make the container shrink to fit the widget. Containers can be embedded within other containers too, which allows you to layout your UI before adding the widgets in. All of this will be demonstrated in further articles, but my point right now is that all of this is baked into Gtk#. You don't have to worry about it. And the best thing is that it works great and is really intuitive.

Simple example (click me button and text box)

Let's start by creating an empty Gtk# application which, once compiled and lauched, will result in the typical empty window:

Now let's take a peek at the code that was generated to make this happen:

   1:  using System;

   2:  using Gtk;

3:

   4:  namespace Gtk

   5:  {

   6:      class MainClass

   7:      {

   8:          public static void Main (string[] args)

   9:          {

  10:              Application.Init ();

  11:              MainWindow win = new MainWindow ();

  12:              win.Show ();

  13:              Application.Run ();

  14:          }

  15:      }

  16:  }

First, a quick work on the Gtk namespace. I named my project "Gtk", which doesn't seem to cause any namespace name clashes. However, it might confuse you into thinking that you have to use the same namespace for things to "just work". You don't. So please disregard it.

Pretty standard stuff, except maybe that the Application class doesn't seem to be connected to the main window. The main window needs to be shown *and* the application needs to be ran. Application.Init is first called with no arguments. You could pass in the program name and the program arguments if you'd like, but the default "empty" application doesn't seem to need to. Then, the main window is instanciated and shown on the screen. Finally, Application.Run starts the main event loop. You will see later that when closing the main window, a call is made to Application.Quit. That is how the main event loop exits and you app is freed from memory.

Now let's take a look at the MainWindow class:

   1:  using System;

   2:  using Gtk;

3:

   4:  public partial class MainWindow: Gtk.Window

   5:  {

   6:      public MainWindow (): base (Gtk.WindowType.Toplevel)

   7:      {

   8:          Build ();

   9:      }

10:

  11:      protected void OnDeleteEvent (object sender, DeleteEventArgs a)

  12:      {

  13:          Application.Quit ();

  14:          a.RetVal = true;

  15:      }

  16:  }

MainWindow is defined as a TopLevel window, which is almost always going to be the case, unless you want a popup. Specifying the TopLevel type make Gtk# connect the window to the OS or window manager. The Build method takes care of visually creating the UI. It has been defined elsewhere, thanks to the fact that MainWindow is a partial class. This just smell like code generation! We'll take a look very soon. But first, I want to mention that the OnDeleteEvent method is responsible for terminating the Application's main event loop.

Alright, let's look at the other part of MainWindow. To see it right click on the project in the solution explorer, go to display options and check "Show all files". A gtk-gui folder will appear in the solution explorer. Once expanded, it will reveal three files: MainWindow.cs, generated.cs and gui.stetic. Open up MainWindow.cs:

   1:  public partial class MainWindow {

2:

   3:      protected virtual void Build() {

   4:          Stetic.Gui.Initialize(this);

   5:          // Widget MainWindow

   6:          this.Name = "MainWindow";

   7:          this.Title = Mono.Unix.Catalog.GetString("MainWindow");

   8:          this.WindowPosition = ((Gtk.WindowPosition)(4));

   9:          if ((this.Child != null)) {

  10:              this.Child.ShowAll();

  11:          }

  12:          this.DefaultWidth = 400;

  13:          this.DefaultHeight = 300;

  14:          this.Show();

  15:          this.DeleteEvent += new Gtk.DeleteEventHandler(this.OnDeleteEvent);

  16:      }

  17:  }

Yuck, ugly code! Obviously, this code has been generated (you might have to compile the solution first.) Here is where the Build method is defined. It is a virtual method that can be overriden in subclasses, which I have found to be very useful when creating different views that can be displayed in an application I'm building. Here, the title, position and default size of the window are specified and the DeleteEvent is set to call the OnDeleteEvent method we say earlier.

What about the Stetic.Gui.Initialize call? Well, by default, MonoDevelop utilizes Stetic as the Gui designer for your applications. As you lay out your widgets and containers, the gui.stetic file that was mentioned earlier is built. It is simply an xml file (oh, noes!) that holds every possible detail about your UI. Let's take a quick look:

   1:  <?xml version="1.0" encoding="utf-8"?>

   2:  <stetic-interface>

   3:    <configuration>

   4:      <target-gtk-version>2.12</target-gtk-version>

   5:    </configuration>

   6:    <import>

   7:      <widget-library name="glade-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f" />

   8:      <widget-library name="../bin/Debug/Gtk.exe" internal="true" />

   9:    </import>

  10:    <widget class="Gtk.Window" id="MainWindow" design-size="400 300">

  11:      <property name="MemberName" />

  12:      <property name="Title" translatable="yes">MainWindow</property>

  13:      <property name="WindowPosition">CenterOnParent</property>

  14:      <signal name="DeleteEvent" handler="OnDeleteEvent" />

  15:      <child>

  16:        <placeholder />

  17:      </child>

  18:    </widget>

  19:  </stetic-interface>

Our MainWindow is defined on line 12 and looks awefully like the ugly generated code from above. What happens is that as you build your UI with MonoDevelop, the stetic file is generated. When you compile your application, the ugly partial MainWindow class is automatically re-generated and then compiled.

So there it is, our first empty window application.
Next time, we'll go in a add... a button! See you then!

Querying Rally with ruby

2009-09-25T22:03:00Z

I've had the opportunity to play around a bit with the Rally REST API to automatically generate acceptance test stubs at work recently. For those of you who don't know, Rally is a bug/feature tracking software that allows you to write stories and test cases, along with tracking hours spent implementing all of these. Usually, a product manager will create stories ahead of time and developers then bring the story to life, after which acceptance tests have to be written and passed.

So we decided to generate empty test stubs for each and every test case that didn't have a test already, which will save a ton of time to all the developers. Moreover, since Rally is integrated to TeamCity, we would know instantly which tests have been implemented, and which ones haven't, the moment we kick off our acceptance test job.

Should you want to do something similar, or simply query Rally, I hope the following code will help you with that.

First things first, though. You will need to install the ruby gem rally_rest_api (here's the documentation). In a command prompt, type in:

gem install rally_rest_api

Then, start up your favorite ruby editor and start coding! The first thing we did was to put a wrapper class around the gem's RallyRestAPI class:

   1:  class MyRally

   2:    def initialize

   3:      @rally = RallyRestAPI.new(:base_url => "https://rally1.rallydev.com/slm",

   4:                                :username => "your_username",

   5:                                :password => "your_password")

   6:    end

7:

   8:    def get_stories(project_name)

   9:      query_results = @rally.find(:project) {equal :name, project_name}

  10:      project = query_results.results.first

11:

  12:      query_results = @rally.find(:hierarchical_requirement, :fetch => true) {equal :project, project}

  13:      query_results.map do |story_result|

  14:        puts "fetching story #{story_result.formatted_i_d}"

  15:        Story.new(story_result, self)

  16:      end

  17:    end

18:

  19:    def get_test_cases_for_story(story_result)

  20:      test_case_query_result = @rally.find(:test_case, :fetch => true) {equal :work_product, story_result}

  21:      test_case_query_result.map do |test_case_result|

  22:        puts "--fetching test case #{test_case_result.formatted_i_d}"

  23:        TestCase.new(test_case_result)

  24:      end

  25:    end

  26:  end

In the initialize method, the RallyRestAPI object is instantiated with your credentials, which will allow it to make the proper service calls to the Rally server. Then, the get_stories method takes a project name as a parameter and will find all the stories belonging to that project in Rally.

Note that the @rally.find call on line 9 takes both parameters and an optional block. If you wanted to, you could yield to the caller inside the block instead of having to pass in the project name to the get_stories method. That would allow you to specify any extra constraints at the moment you call get_stories. For example, instead of writing:

   1:  my_rally.get_stories("Sharks with laser beams")

you could write:

   1:  my_rally.get_stories do

   2:    equals :name, "Sharks with laser beams"

   3:    greater_than :priority, "Fix Immediately"

   4:  end

which allows you to be more specific in your querying without having to create a new method for each and every single combination of constraints you need to query your stories.

Back up in the code, the first thing the script does is to find the actual project. Then, it uses the project to find all the user stories that have been defined for it. The result set that is returned by the Rally API is mapped to an array of Story object, which have been implemented as a wrapper around the returned data. Finally, the test cases are fetched in the same manner, for each story, and mapped to a TestCase object.

Here is the code for the Story and TestCase classes:

   1:  class Story

   2:    attr_reader :formatted_name

3:

   4:    def initialize(story_result, rally)

   5:      @formatted_name = "#{story_result.formatted_i_d[5..-1]}_#{story_result.name.underscorize}"

   6:      @test_cases = rally.get_test_cases_for_story(story_result)

   7:    end

8:

   9:    def to_s

  10:      str = @formatted_name + "\n"

11:

  12:      @test_cases.each do |test_case|

  13:        str += "  name: #{test_case.name}\n"

  14:        str += "  id: #{test_case.id}\n"

  15:        str += "  pre_conditions: #{test_case.pre_conditions}\n"

16:

  17:        if test_case.steps != nil

  18:          test_case.steps.each { |step| str += "    - #{step}\n"}

  19:        end

20:

  21:        str += "\n"

  22:      end

23:

  24:      str += "--------------------------------\n"

  25:    end

  26:  end

   1:  class TestCase

   2:    attr_reader :name, :id, :pre_conditions, :steps

3:

   4:    def initialize(test_case_result)

   5:      @name = test_case_result.name.underscorize

   6:      @id = test_case_result.formatted_i_d[2..-1]

7:

   8:      pre_conditions = test_case_result.pre_conditions

   9:      @pre_conditions = test_case_result.pre_conditions.clean_up unless pre_conditions == nil

10:

  11:      @steps = test_case_result.validation_input.clean_up unless test_case_result.validation_input == nil

  12:    end

  13:  end

The astute reader (I've always wanted to say that!) will have noticed that we use obscure methods like underscorize on the story and test case names. These have been added to the String class for our own particular reasons which, in this case, require all the words in the names to be separated with underscores.

That's pretty much as far as we went with the API so far, and I hope it'll help any of you who use Rally as well! Have a great weekend!

Do you plan your work?

2009-09-22T19:19:00Z

Just last week, a coworker and I started working on a defect. It was easy enough, really. Fixing the problem involved performing two distinct operations that were *almost* independent of each other. The work was easily divided between the two of us and so, before getting started, we quickly discussed the issue at hand and then we both went back to our cubicle to get started. It was only later that our boss came by and asked us what our plan was.

I was speechless. A plan? We... er... I... I gave up. We had no plan, whatsoever. He told us to get together and come up with a plan for fixing the defect.

Planning what needed to get done and doing some design up front immediately put into light some complications we might run into and allowed us to synchronize our efforts better. Both my co-worker and I knew where and how we'd depend on each other's work and found out how we'd hopefully never have to wait for the other to complete a task.

This was an eye opener for me. How many times in the past have I gone straight into coding without doing any sort of planning? Sure, we write stories and scenarios. But what I'm talking about is workflow planning: figuring out what needs to get done, in what order and by whom. And something funny happened: even though this is a small scale example, by planning and doing some design up front, we kind of unknowingly did some risk analysis. We discovered some potentially problematic areas and took that into consideration when giving our boss our time estimates for the defect.

Of course, we ended up being completely wrong on a few things... But at least we gained some experience in the process.

I know that I, for one, will try to do that more often.

Learning how to walk with Mono

2009-05-26T01:01:00Z

I started experimenting with Mono this week. The reason is simple enough: somebody wants me to write a small application that will run on their Windows box. The problem is, I own a Mac and a Linux powered laptop (yes, taking the Vista sticker off was a exercise in patience that left a lot of residual glue on the laptop...) Mono is a perfect solution for writing .Net software on Linux that will run on Windows.

The Setup

I run OpenSuse 11.1 because I figured I might as well go with the distribution that was created by the people who are currently behind Mono: Novell. Also, at the time of this writing, I have Mono 2.4, which is .Net 3.5 compatible, and Monodevelop 2.0 installed. As a bonus, I realized today that NUnit was also installed: version 2.4.8.

The Solution

Creating a new solution with Monodevelop is pretty straightforward.

As you can see, it's fairly similar to the Visual Studio experience. I selected the Library type of project and named it MyTest. After clicking the Forward button, Monodevelop asked me if I wanted to add packaging, unix integration or other little nifties to my project. I graciously declined.

The above image depicts what you get when you create a new, empty library project. Eager to get on my way, I coded one of the simplest class I've ever coded:

1:

   2:  using System;

3:

   4:  namespace MyTest

   5:  {

   7:      public class MyClass

   8:      {

   9:          public string MyString { get; set; }

  10:          public MyClass()

  11:          {

  12:          }

  13:      }

  14:  }

And I then set out to write a test using Scott Bellware's SpecUnit. First, I added a NUnit library project to my solution, which I called MyTest_spec.

This created a simple, empty project with everything you need to use NUnit and write some tests. The interesting thing I discovered is that Monodevelop includes its own Reflector utility. Going to the references of my NUnit project and double-clicking on nunit.framework, I got this:

Which is how I figured out I was using version 2.4.8. You can drill down into the assemblies and click on methods. I guarantee it; you will see code! Anyway, here's my test code:

1:

   2:  using System;

3:

   4:  using MyTest;

5:

   6:  using NUnit.Framework;

   7:  using SpecUnit;

8:

   9:  namespace MyTest_spec

  10:  {

  11:      [TestFixture()]

  12:      [Concern("MyClass")]

  13:      public class when_changing_the_string_of_my_class : ContextSpecification

  14:      {

  15:          [Observation]

  16:          public void should_persist_the_new_string()

  17:          {

  18:              myClass.MyString.ShouldEqual("Hello, world!");

  19:          }

20:

  21:          protected override void Because ()

  22:          {

  23:              base.Because ();

  24:              myClass.MyString = "Hello, world!";

  25:          }

26:

27:

  28:          protected override void Context ()

  29:          {

  30:              base.Context ();

  31:              myClass = new MyClass();

  32:          }

33:

  34:          protected MyClass myClass;

  35:      }

  36:  }

Please note that Monodevelop default to using the .Net 2.0 framework. You will have to change this to .Net 3.5. Right-click on each one of the projects of your solution, select Options and go to Build/General. Change the runtime version to .Net 3.5, like shown below:

I've got my class, I've got my spec. Now I need to run the tests and see if this whole thing works on Linux! So I compiled... And BAM! I got an error. The compiler complained that SpecUnit was expecting the 2.4.6 version of NUnit. The problem is, as you've seen higher in this post, I was using nunit-2.4.8. I went back online and downloaded the SpecUnit code, thinking I'd recompile it with the 2.4.8 dlls of NUnit. I found the solution file (SpecUnit was created with Visual Studio, so I was looking for a .sln file) double-clicked on it and crossed my fingers... It worked! Monodevelop loaded the entire SpecUnit solution! All I had to do then was to replace the nunit.framework references with the newer ones from the 2.4.8 version, which were conveniently located with all the other regular .Net references. Recompile and voila! A brand new SpecUnit, ready to roll!

To tell you the truth, I wasn't expecting Monodevelop to load a .sln file. Later, reading the feature list of Mono and Monodevelop, I saw that Monodevelop fully supports MSBuild and even defaults to it. Nice! Embrace, extend, and... er... isn't that was Microsoft is supposed to do? Interesting to see somebody else doing it!

I replaced the old SpecUnit reference with the new one, compiled... And BAM! Another error! This time, the compiler was not too happy with my use of the extension method ShouldEqual, which was otherwise recognized correctly by the editor. However, the compiler kept complaining. After double-checking that all my projects were compiling for the .Net 3.5 framework, I googled the problem and found out that you have to include System.core in your references, which is not automatically done by Monodevelop. And that did the trick, the solution compiled!

I just had commited a heresy. I had just put a DLL on my pure, pristine Linux system. A DLL! No, even worse: two DLLs! I grapsed for something to hold on to. When the oily feeling that tainted my soul finally subsided, I ran the test:

It passed!

Now, this is really cool! I look forward to doing more with Mono. Hopefully, more and more developers will start using it. So far, the experience has been good, but I miss ReSharper and the ability to run tests from within the IDE. Monodevelop allows us to write plugins, so anybody up for a a R# clone on Monodevelop?

Thanks for reading.

Yield, I thought I knew you!

2009-05-19T13:30:00Z

The yield keyword, in whatever language, has a special meaning to me. First introduced in threading, it was used to yield the execution of the current thread and let the next one go. The concept fit in my head very nicely. After all, we have yield signs on the road everywhere, instructing us to give priority to other cars, bikes or pedestrians. Making the switch to a threading environment was pretty straightforward.

Then came Ruby.

Ruby's usage of the yield keyword is to execute a block that was given to a method. For example:

@words = ['hello', 'world', 'how', 'are', 'you', 'doing?']

  

def reverse_words

  @words.each do |word|

    yield word.reverse

  end

end

  

reverse_words {|reversed_word| puts reversed_word}

When calling the method reverse_words, you need to supply a block that will be called back from within the method. This is accomplished by using the yield keyword, where reverse_method calls your block and gives it a reversed version of each word in the words array.

Again, the usage of yield here still makes sense to me. The method is yielding to the caller's block of instructions.

But C# also has the yield keyword! And I thought I knew what it did until I stumbled upon the following code at work:

public static IEnumerable<EditModeSpec> PreviewInFormAndEditInAnswer(bool ...

{

    yield return VisibleWhen(FormMode.Any, FormStatus.Any); 

    yield return InteractableWhen(FormMode.Create, FormStatus.Any);

  

    yield return EditableWhen(FormMode.Answer | FORM_MODE_REVIEW_ANY, ...

    yield return EditableWhen(FormMode.Answer, FORM_STATUS_NOT_SUBMITTED, ...

    yield return EditableWhen(FormMode.Answer, FormStatus.Approved, ...

  

    yield return EditableWhen(FormMode.Answer, FormStatus.Scheduled | ...

    yield return EditableWhen(FormMode.Answer, FormStatus.Approved, ...

  

    yield return EditableWhen(FormMode.Answer, FormStatus.Submitted, ...

}

Woa! What is going on here?

The above method returns an IEnumerable type. Because of the yield statement, the values inside that enumerable type will be calculated only when they are accessed the first time. Basically, "yield" delays the execution of the returned values. Whenever I decide to loop over them, all those returned statement would be executed at that point and their result stored inside the returned enumerable type.

So in C#, yield means something somewhat different. Yield, I thought I knew you!

So, what's up doc?

2009-05-19T00:45:00Z

I started blogging last July because I felt I had to get out of the rot I was in. Stuck in the middle of nowhere doing Classic ASP forms on top of a database, I knew I was missing the boat. I knew .Net, but my skills dated from the days of C# 1.1. What's more, their was virtually no developer community where I was.

Nowadays, my life has morphed into the exact opposite. I live in Austin, TX. The community here is amazingly vast, smart, and varied. My job has me work with IoC containers, unit tests, automated UI acceptance testing. This is a dream come true! Except that I have slowed down on the blogging.

Of course, I have excuses! I work hard and my work is fullfilling my need for knowledge. Blogging is not the learning medium that it was for me just a few months ago. In this new situation, I find that I have lost my voice. But no worries, I am fully aware of the fact and I spend the bigger part of my days trying to catch up.

Of course, I could also get up from my ass, dig deep and just do it.

Thanks for reading, I promise I'll be back soon.

Poll, Don't Wait for your Silverlight Applications

2009-04-15T19:52:00Z

Did you ever write code like the following pseudo-code for your Silverlight acceptance tests?

browser = Watir::IE.new

browser.goto("http://myserver/page.aspx")

  

sleep 10

  

screen = browser.get_screen

screen.enter_user_name("user")

screen.enter_password("password")

screen.click_login

...

(Before diving into the code, please note that most method calls done on the browser object are methods that are defined in our Silverlight application, but made available as scriptable methods. We encapsulated their usage so as to make them easy to read. Normally, they would be called as you call a javascript function.)

In the above snippet, we first get a new instance of an Internet Explorer process by using Watir, a ruby library that allows us to connect to a browser and interact with the DOM Then, using that process, we navigate to the page that we want to test and we wait for 10 seconds for the Silverlight app to finish loading. Yes, even though Watir can tell us when the page has finished loading, it unfortunately doesn't mean that Silverlight is also up and running. So we have to wait a bit. Here, 10 seconds is a wild guess that should cover most scenarios. If we underestimate and start testing too early, the test will fail. Anyway, once we’re good to go, we get the current screen using a scriptable method in our main Silverlight class and use the object it returns to enter a user name and password and to simulate a click on the login button, also through scriptable methods.

Did I mention how useful scriptable methods are? Hmmm, yes. Yes, they are.

The problem with that code however, is that it will take a minimum of 10 seconds to run. You might want to go ahead and reduce the sleep instruction down to 5 seconds and find out it works anyway. But when you proudly show it to your boss the next day, your email software starts archiving your thousands of deleted email and slows down your computer just enough that the page takes slightly longer than 5 seconds to load, resulting in an exception raised while trying to enter the user name. Then you’ll give your boss the usual excuse: “It worked yesterday!” Yeah, right!

Pausing your acceptance tests seems to be the norm in the industry as a mean to let your application do its work before you send it the next command. We don't have a choice; acceptance tests are asynchronous because the test process is separate from the application process. The amount of time you have to wait between instructions will vary from computer to computer, depending on the hardware or other factors, like network latency. You also want your tests to run on all the developers' machines so that they can verify that their piece of code didn't break a test. So the waiting time needs to be high enough that the slowest machine in your department will be able to run it. Unfortunately, it means that a lot of people with faster boxes will end up wasting their time while waiting for the tests to complete. And who knows, maybe you have, hmmm, 30 tests that they have to go through? That’s five minutes, right there!

So much for green-red-refactor!

Polling

We haven't completely solved the problem yet where I work, but we are well on our way to do so. We have introduced a way for the testing process to poll the application in a way that allowed us to re-write the code snippet above like this:

def app_loaded?

    $browser.run_script("isAppLoaded")

end

  

def wait_for_app

    while !app_loaded?

        sleep 1

    end

end

  

$browser = Watir::IE.new

$browser.goto("http://myserver/page.aspx")

  

wait_for_app

  

screen = $browser.get_screen

screen.enter_user_name("user")

screen.enter_password("password")

screen.click_login

...

What’s happening here is that when we load the web page and call the wait_for_app method, the test script will pause for a second, then execute the isAppLoaded() javascript function, located in page.aspx or in any javascript file include with the page. Based on a variable that is initialized to false but set to true after Silverlight successfully made a call to a web service, isAppLoaded() returns true only after we are certain the application is fully loaded.

This was easy part… We now are faced with the prospect of removing all our pauses that we inserted between all our test instructions and using a polling technique instead. For example, when we click on the login button, we need a way for the application to let page.aspx know that it is done processing that command. This is one of the challenges waiting for us. Polling the app to discover when an operation has completed successfully or not is not obvious.

Build polling into the architecture

We are lucky. Our codebase was built using SOLID principles. This means that there is one class responsible for executing commands it knows when they are done with their tasks. So it shouldn't be too hard to implement polling in our case.

My guess is that someone could use a Message Bus system, or something similar, to centrally deal with all the calls made from the UI to the application layer. This way, polling, and much greatness, would be accessible to the developers.

Oh yeah, and all your wildest dreams will also come true. Really!

Using SVN's latest revision in your TeamCity build

2009-03-30T20:06:00Z

Continuous integration is a fun beast to deal with. Sometimes irritating to set up but it feels great once it's running properly, like walking barefoot on the grass!

My team has recently moved from Cruise Control.Net to TeamCity for our continuous intergration process and I have been put in charge of taking our nAnt scripts and converting them to a rakefile. This was easily done except for one little hick-up... TeamCity checks out the code for you at the beginning of the build process, without all the .svn folders. This means that we don't have access to the "svn log" command to get the head revision number like we used to when checking out the code manually with nAnt.

After digging and searching, I found out about a powerful feature of TeamCity: setting and environment variables. It turns out that TeamCity gets the latest revision number from svn when getting the latest and greatest copy of your code and makes it available to you through the system variable "build.vcs.number":

You can then use that variable to label you build number when you edit your general settings:

Finally, TeamCity makes that build number available to you in you nAnt scripts, or any other scripts by setting a special shell environment variable that you can pick up at your leasure. In my case, using Ruby, all I had to do was:

build_number = ENV['BUILD_NUMBER']

The environment variable set by TeamCity are accessible just under the system variable ones:

Now that I know about all of this, I'm wondering what else I can do with this feature. Because you know, you can set your own properties and I really like how TeamCity helps you share them across multiple tools.

.Net libraries in Silverlight

2009-03-09T22:08:00Z

This past week has brought it's fair share of action to my life, with my new job in a new city! So far, I like everything about it, even though my appartment is empty and my family hasn't moved in just yet. At work, the software that my company produces is a full blown Silverlight web application and it looks very, very sleek. My boss didn't waste time and assigne to me my first task: eliminate the special testing assembly that we were using to run our specs. Let me explain why.

Silverlight applications, being that they run in the browser, use a subset of the CLR to run, called the Core CLR. There are multiple reasons for that, including a different security paradigm and shorter download time. When you create a Silverlight application, it runs on top of the Core CLR. This is important, because it forces you to use libraries that have been built on top of the Core CLR also. You cannot reference a regular .Net library in your Silverlight application, it won't let you.

So then, you need a way to test the silverlight classes that you code. What we had done was to create a separate project using the regular CLR and link in all the silverlight classes. Then, in the code it self, we would use preprecessor directives to ignore the silverlight specific code:

#if !SILVERLIGHT_FOR_TEST
    (silverlight only code)
#else
    (non silverlight code)
#endif

Compiling the project with the compilation symbol SILVERLIGHT_FOR_TEST set would make the compiler ignore all our silverlight specific code and allow the rest to be compile against the regular CLR. That allowed us to run tests. But maintaining two seperate projects was a pain.

The first thing I did was find a version of NUnit that had been compiled against the Core CLR. You can find it here, at the bottom of the article. Next, I found out that Rhino Mocks had also been compiled against Silverlight's Core CLR. You can find the binaries here. Using those libraries, I was able, with a few modifications, to get rid our our test project and run our specs directly against our main Silverlight application.

Tomorrow, I'll write a bit more about my current task: develop a way to test the UI with IronRuby from within the app. Woa, there! Now, that is cool stuff!! Thanks for reading, and thank you very much to all the developers that have ported NUnit and Rhino Mocks to Silverlight!

[To be continued...]

Stubs and application scaffolding

2009-02-19T20:35:18Z

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.

- Martin Fowler

I had an Ah-ha! moment a couple of days ago. I was using a stub to bypass my repository class, and thus costly database calls, when I realized that I could use that technique during the development of my app itself rather than strictly in the test code. It was one of those magical moments where you suddenly remember certain key elements all at the same time, just like if the planets had aligned. I recalled that one lean principle calls for delaying important decisions for as long as possible. I also remembered that a lot of agile practitioners create their domain model before they create their persistence layer or their database schema.

Ah, that’s how you do it! I used to start with my database schema since I would need data to test my application. Not so. Just create a stub instead! Stub out a repository class that will give you what you want. So here I am, quietly writing my app, when suddenly I need to authenticate a user! Oh, no. The authentication module hasn’t been written yet and the User class is still a figment of my imagination. Hmm, let’s write something down real quick.

public class User

    public string UserId { get; set; }

    public string HashedPassword { get; set; }

Now I need a way to load an “existing” user to memory. I like to have a Find() static method in my entity classes to do that. This way, I would simply need to write:

User user = User.Find("louis");

which I find to be very readable and self-explanatory.

This Find() method would access a repository class which would return a user object with the user id “louis”, or throw some sort of UserNotFoundException if it couldn’t find it. I know that eventually, the repository will make calls to the data abstraction layer to get the data it needs, but in the mean time I want to concentrate on how the object is used, not how it is persisted. Obviously, the User class cannot know anything about existing users, so it needs to delegate that responsibility to the repository class:

public class A_UserRepository : IUserRepository

    private User _louis = new User("louis") { Name = "Louis" };

    private User _cara = new User("cara") { Name = "Cara" };

    private Hashtable _usersByUserId = new Hashtable();

    public A_UserRepository()

      _usersByUserId["louis"] = _louis;

      _usersByUserId["cara"] = _cara;

    public IList<User> FindUserByUserId(string userId)

      IList<User> rList = new List<User>();

      if (_usersByUserId.ContainsKey(userId))

        rList.Add(_usersByUserId[userId] as User);

      return rList;

When I wrote that, I started missing the fixture functionality that users rSpec enjoy in the Ruby world. A fixture is simply the data that would be loaded into an object. That data is kept in a separate file and loaded automatically by rSpec to populate test objects. There might be a way to do the same in C#, but since this example is fairly simple, I didn’t take the time to research this.

Anyway, you’ll notice that my temporary repository implements the IUserRepository interface. This is because I know I’ll eventually need to use a real repository. If all my classes use IUserRepository objects, it will be easy to replace one with the other down the line. But how will my user know which repository to use? The static method Find() sure did not specify how to do that. Let’s see, how does it look when I write:

User.FindByUserId(new A_UserRepository(), "louis");

Not too bad. Check out the signature of the method.

The method signature tells me that it’s going to find a user with a IUserRepository, which I’ll now have to provide. In the future, when I’m ready to plug the User class with a real, manly repository, I’ll simply have to pass it as a parameter to the method instead of my stub, without having to change the User class, like so:

User.FindByUserId(new A_Real_Manly_UserRepository(), "louis");

So there you have it, a way to use scaffolding in order to concentrate on building your domain model first, without having to bother yourself with how to construct your data access layer logic yet.

I’m also happy to have shared some code for the first time with you guys!