Remote Pair-Programming

AgileApprenticeshipDesign processSoftwareTestingThoughts

Seems like Pair Programming is “all the rage” lately in my circles. I haven’t exactly done it before but after hearing about the success and rapid knowledge growth amongst those that pair program…I was almost dying to try it! Especially after i saw David Chelimsky and Corey Haines at WindyCityRails in Sept 2009. I saw them pair and do BDD with Rspec/Cucumber and it was so fascinating, It was like I was watching a ballet as they hopped from RSpec to Cucumber and back and forth. I was like, wow…I wish I was that good! I would have paid good money for a recording of that so I could watch it again and again! I see Corey Haines traveling around pairing with people too. Some people get together and play cards, but Corey gets together to code!

So ok, I like code, I like people, I want to try it! I live a little south of Chicago so its a long commute and it seemed everyone was so busy to pair in person when I asked. I asked on Devchix mailing list for suggestions on how to do pairing online. I had found a few, and the group had some good suggestions. I even had a volunteer to try it with me! This week aimee and I set a few hours aside to try it and see if we could do it!

This article was also sort of “paired” as it was written from my perspective with input and suggestions from aimee!

We asked on Devchix mailing list for suggestions on how to do pairing online. I had found a few, and the group had some good suggestions. I even had a volunteer to try it with me! This week aimee and I set a few hours aside to try it and see if we could do it!

After introductions on Skype we set about getting a shared environment in which to code together. Ideally, we wanted some kind of desktop sharing so we could run tests, console and editor.

We had heard of a few tools and got suggestions from the devchix list:

IChat desktop sharing – we couldn’t get this to work, we did different things and it would appear to connect but then it failed. I tried to mess with settings for Sharing on mac, but nothing doing.

Rio seems to be a library to make collaborative apps, not to use in a pair programming environment.

BeSpin was hard to use.. we couldn’t figure out exactly how to use it. It almost seemed to offer to import the git repository we were working on, but then it said it only supports Subversion and Mercurial, not git.

SubEthaEdit worked but we would have to open each file individually and share each file… unless I was missing something. This would be fine for collaborating on a single file but then we could not share the test runs, terminal commands or view the browser together.

Etherpad – we didn’t end up trying this but I have used it before to debug some code or try out ideas with a friend. They recently got bought by Google, so it would be interesting to see what they do with it. This would suffer the same limitations as SubEthaEdit in that it’s just a text editor.

GoToMeeting (which is $40-50/month) its a little steep for the open source work I want to do. But people say it works really well.

VNC and Unix Screenaimee had used this successfully before but since we weren’t on the same network, just our laptops at home, we weren’t sure it how we could make it work easily.

Then we came to TeamViewer which worked brilliantly! We shared desktop and I could type in aimee’s console window, see the tests running and type in textmate. Even with aimee on her Dvorak keyboard and I on Qwerty! I could type fine but couldn’t copy/paste with keyboard shortcuts so I used the mouse to copy/paste and it worked fine.

All in all, it was an awesome experience and I picked up on a few tidbits of knowledge from aimee on git, and rake! I had some bits of code from another project i was able to quickly copy/paste and get us rolling. We had a few discussions about coding style as we went.

Since aimee was more familiar with the codebase, she mainly wrote the behavioral specs and I wrote the code to satisfy them. We plan to switch around next time, when we pair on a different project that I’ve been developing for a while.

Book Review: "Refactoring in Ruby"

BookDesign processEventsIntroductionsRubyTestingTips and Tricks

“Refactoring in Ruby” written by William C. Wake and Kevin Rutherford.
Published by Addison-Wesley

This is more like a “workbook” then a “how to write awesome code” book. You can download the code from github and you will find tests/specs for the exercises.

The book is arranged in three parts, The Art of Refactoring, Code Smells, and Programs to Refactor.

There are explanations of “code smells” which are one characteristic of code that could be improved. Some of them are long parameter lists, unnecessarily complex, global variable, feature envy sections, etc. One thing I find interesting is the “How did it get this way?” section. It gives some insight into the thought process and reasoning behind the smell. I think this is good, as programmers our ego may be rather miffed to hear “This code stinks” but with some reasoning, it makes the pain less and I think firms up in our minds when this happens again, to do it this other way. I always want to know why when someone says I could do such and such thing better.

In addition to the code smell examples there are three programs to refactor in the end of the book. In a conversational tone, it walks through and gives some hints on what needs refactoring. Its almost as if you had a pair programming buddy working with you and identifying in small chunks what can be improved. This is definitely something I want to work through more carefully.

What I find odd, is that not all the code smells have code examples. The inspiration for the book I think is the Martin Fowler book “Refactoring Improving the design of Existing Code” which has examples for every code smell. Maybe Ruby smells less than Java? Or those fixes are really trivial? I don’t know. Overall, this is a great book and is certainly worth the price and investment and you will be a better programmer because of it!

Google Web Toolkit, 2.0


Our life basically lives on the web, the web is the platform! One of the advantages of creating your web application in GWT is it is pure html/javascript/css and the user doesn’t need to install a plugin to use your app! It is easily viewed on most smart phones as well. It compiles to each browser making it more efficient than using alot of if/else statments to build code for the particular browser you are using. It standardizes the method you use to make your app, no more studying the nuances and ripping your hair out over tiny browsers quirks. GWT 2.0 which is scheduled for release this fall has some great new features that I am finding to make GWT more flexible and easy to maintain.

Get GWT Trunk
The 2.0 features talked about here are in trunk and building it yourself is fairly straight forward.

  1. If you don’t already have it, get the latest version of eclipse – Galileo, with the Google plugin.

  2. Checkout the source code
    Follow the instructions on the GWT homepage, its pretty good.
    Make sure you have ant installed. It takes awhile, i think maybe 20 mins or so on my macbook.

  3. Setup the API directory in the Preferences for GWT
    In eclipse, add the new version of GWT library.

    Go to Eclipse > Preferences.
    Find the Google Web Toolkit on the left. Click add, add the path to the compile files like so:
    I named it “trunk”

  4. Create project
    Create a new Web Application Project, select “trunk” (or whatever you named it in the previous step) as the version of GWT to use.

The most interesting things in 2.0 is the UiBinder and UiHandler.

Using UiBinder
Usually for each element on the page you need to do something like this

CheckBox box = new CheckBox("this is the label for the checkbox");
box.setFormValue = "3";

Panel verticalPanel = new VerticalPanel();

If you have alot of elements on the page, that comes out to alot of java code. And you might start wondering if you are writing a Swing app or a web app?!?

in UiBinder, we can can put it in a XML file like:

<ui:UiBinder xmlns:ui=''
    <g:CheckBox ui:field="rubyCheck" formValue="ruby">Ruby</g:CheckBox>

Typically any attribute you can use in the java code like setName, setFormValue, setStyleName you can add right in the xml as attribute=”"

You can reference your objects from the xml like so:

public class LanguageList extends Composite {
  interface MyUiBinder extends UiBinder<Widget, LanguageList> {}
  private static MyUiBinder uiBinder = GWT.create(MyUiBinder.class);
  @UiField CheckBox rubyCheck;
  public LanguageList() {
      // bind XML file of same name to this class
      // use rubyCheck as if you had defined it already with new

Note you have to bind the xml to the java code with:

  interface MyUiBinder extends UiBinder<Widget, LanguageList> {}
  private static MyUiBinder uiBinder = GWT.create(MyUiBinder.class);

This process is called deferred binding. This may be familar to java programmers already but My background is LAM(P|P|R) programming so I am still trying to fully understand it myself! GWT homepage explains it here:

Using UiHandler

Typically, event handlers are written as such:

// add button and handler to alert the values of checkboxes
button.addClickHandler(new ClickHandler() {
   public void onClick(ClickEvent event) {
     String output = "";
     for(CheckBox box : boxes) {
       if (box.getValue()) {
           output += box.getFormValue() + ", ";
     Window.alert("You checked: "+ output);

Instead of having the click handler specified in the java method, you can attach it via an annotation:

  void doClick(ClickEvent event) {
      String output = "";
         for(CheckBox box : boxes) {
          if (box.getValue()) {
              output += box.getFormValue() + ", ";
      Window.alert("You checked: "+ output);

Sweet, huh? I think it cleans up the code nicely and gets the job done!

Go compile the Trunk version of GWT and give it a try!

If you want to see the full source for a simple gwt app before and after UI Binder, I have a write up here with links to sources on github here.

Resources for learning gwt that I found helpful:

GWT Homepage

GWT Can Help You Create Amazing Web Apps

GWT Best Practices

OnGWT – various blog posts about GWT

Book Review, "Pro Active Record"


Published by Apress
By Kevin Marshall, Chad Pytel, Jon Yurek
Book Info
Sample Chapter: Ch. 01 – Introducing Active Record
Table of Contents

Years ago when I was in PHP Land (now I travel quite a bit more! haha), I strugged for months with how to write a good ORM . It was tough, because I wanted to abstract the “boring logic” of retrieving records from a database without writing SQL but still remain flexible enough. I never really came up with a good model. I used the DAO from “extreme php” library which I think was a knock off from java. It was ok, but I still didn’t feel like I had “arrived”.

When I discovered Ruby on Rails, I found ActiveRecord. Ahh HA! Finally, this is what I was looking for. At first I thought it was part of Rails, but its not. Its a standalone library and you can use it with straight up ruby scripts.

I got a review copy of “Pro Active Record” some time ago and read it some when I got it, then some later, and now I am going to officially write up a review!

If you do anything with Active Record, get this book. The things that are briefly mentioned in most Rails books are described in detail in this book.

Chapter 1 – Introducing Active Record

Most of the time, the first chapters of a book are boring to me. I don’t need another “History of the Internet” or how “HTML was developed” … blah blah. But this one, the story is only 1 page. And it actually has some introductory scripts on using Active Record, so you can see right away how it works. It also explains the benefits of MVC and why ORMs are good. Some people still don’t get it!

Chapter 2 – Active Record and SQL

This chapter helps you translate the “sql in your head” to how to write it with Active Record. I’ve used Active Record so much that now I have forgotten most of my SQL, which is kind of embarrassing. :) I now find writing sql tedious and boring! I would have actually called this chapter “Demystifying Active Record” since it explains why all the dynamic finders work. You’ll also find transactions and locking explained here.

Chapter 3 – Setting up Your Database

Migrations! The Awesome Thing that can turn into a nightmare for large rails projects with multiple developers…. definitely have to decide on some best practices with your team on this one. The chapter has only one thing to say about this — assume any checked in migration has already been run by your team and the migration should not be edited and checked back in! You’ll have to make another migration file with your changes.

Nola's Note: When you make a migration, test it both UP and DOWN!! Here's what I do --
write a migratiion
rake db:migrate (go up to the version with new code)
rake db:migrate VERSION=n-1, (go to version before the latest)
rake db:migrate (back to lastest)
rake db:migrate VERSION=0 (back to blank db)
rake db:migrate (back to latest)

Just to be sure its all good — even on a new database!

Chapter 4 – Core Features of Active Record

Now is the fun stuff – Callbacks. This is magic. This makes Active Record so flexible, and is one thing I could never figure out how to do with my PHP ORMs. I use call backs to set defaults for fields. If its just a straight default, then I set it in the database but if I need to make a decision, (if this field then this field..) then I can use it in a callback.

Associations – at first this is very confusing! I don’t know how many times I got “has_many” and “belongs_to” mixed around in the beginning.

Validations – Awesome. I had to do some ruby code without a database and I really really really missed the validations. It took me like 5x longer than it should! Understanding all of these validation methods will make your life so much more enjoyable. I really really hate doing boring, repetitive stuff…it seems so wasteful to me.

Chapter 5 – Bonus Features

Everybody likes a bonus and this isn’t even the last chapter of the book.

Java people will like the Active Record Observers — seems a little AOP to me (aspect orienteted programming) and something I probably have neglected to use to their fullest extent.

Acting up — Learn how to “save time” with the “acts_as” magic: List, Tree, Nested Sets. If your data needs these structures, you got it made. I can imaging how much longer it would take to write this stuff in perl or php.

Composed of – I haven’t used this, but this looks like a good way to make sensible objects out of database tables. There is quite a bit of explanation and examples of this, it will come in handy.

There are a few other in depth explanations of things, such as method_missing which is how alot of the magic happens. Rock on.

Chapter 6 – Active Record Testing and Debugging

Ahh yes, Testing. My favorite subject. My friends who know how much I love testing say I am sick. I must have an inner need to PROVE I am right or something, haha.

The chapter goes into depth about using test_unit with Active Record, sadly no RSpec. But, it does go into all the error messages that Active Record throws so you can write good try/catch blocks and make very exact error messages (probably best logged for the admin rather then displayed to the user!)

Chapter 7 – Working with Legacy Schema

Here’s how you work with that old database that just won’t die… or that management won’t let you totally redo. Active Record follows some of the principles of Rails “convention over configuration” … relying on table and column naming conventions to figure out how to build your object….but still giving you a way out if you want your tables singular and your primary id field called “myawesomeid” instead of “id”

I’ve used some of these things on an older database and it was possible! Not too bad if thats what you have to work with.

Some people find this annoying "oh gosh! my library can't make decisions for me! OMG! That sucks" .. to that I say, "Umm ok. But if you follow these conventions then I can come into your project and know exactly what is going on" ... like with web standards, we all harp on how IE and FF do things differently, yet people want to bellyache about Active Record preferring to have plural names and id field called "id". Right.

Follow the dang convention and find something worth complaining about to complain about. :)

Chapter 8 – Active Record and The Real World

This chapter goes into depth about the library and encourages you to go read the Active Record code. Always a good idea to know what it is you are using :) I’ve actually learned ruby better by reading source code. The chapter walks you through basic structure of the files. Very cool.

I used to work at a place that didn't like any "outside code" because they were afraid "OMG ... it will send our passwords to Russia!" ... ok, well I am not an idiot. I read over any code that I use that I didn't write. I look at the tests to see if I am using it right. I even RUN the tests so I can be sure its working as advertised.

Alternatives to Active Record – with EXAMPLES! If something about Active Record doesn’t set too well with you, take a look at the alternatives. Sometimes I look at the alternatives and decide that the first wasn’t so bad after all. You’ll find examples of DBI, Og, ActiveRelation.

Finally a section on Q and A finishes up this book. The Appendix has a complete reference of ActiveRecord methods to make this book a well rounded reference, tips, documentation and very handy to have at your desk!

Book Review: Pro Drupal Development


Book Site | Sample Chapter: The Theme System | Table of Contents

Many of you are aware of my current total infatuation with Ruby, and that I’ve used PHP for about 6 years and at one point decided I hated PHP…until, I needed it for a quick one-off page and then realized that PHP had its place. Then again, I was totally frustrated with Ruby when making my moms bakery site and then turned to Drupal and Gallery (another fine PHP project), which saved my bacon and I got a website and photo gallery up in a weekend. So, PHP and I have had our moments but I’m not abandoning it!

Drupal powers some big sites, its not just for joe smoe’s blog. This is an interesting page about Is Drupal Right For You? and if you are wondering if its something that would even work for you.

I was excited to get my hands on a review copy of Pro Drupal Development. Its no secret that coders hate documentation and Drupal has one of the most complete online documentation I’ve seen for an Open Source project, but its almost too hard to find what you need amongst so much. The Pro Drupal Book is a godsend for the drupal programmer, new and experienced alike. I wish it was written a year ago!

The book starts off with a quick overview of how Drupal is structured and defines terms such as hooks, node and blocks in just 10 pages. Chapter 2 is a A step-by-step tutorial with making a module. That is a great idea to start off quickly writing code. It get the reader involved and hands on. I really tire of books that have to start off with the history of the internet, html and how things have evolved. Get to the code dangit!! Kudos to the Authors for that! Chapter 3 gets into module specific settings, like how to get your module to show up on the admin page and storing user settings that your module needs.

After you’ve had some experience with the code then the book goes into details on the specific parts of Drupal:

  • Menu System
  • Databases
  • Users
  • Nodes
  • Themes
  • Blocks
  • Form API
  • Filter System
  • Searching and Indexing
  • Files
  • Taxonomy
  • Caching
  • Sessions
  • JQuery
  • Localization
  • Using XML-RPC

Drupal is a pretty amazing framework, when I read the code I say “why didn’t I think of that?” … the module and hook system is genius.

Then some more general topics:

  • Writing Secure code
  • Development Best Practices
  • Optimizing Drupal
  • Installation Profiles

One of the chapters I skipped ahead to read was The Form API. In my years of PHP I’ve often tried to come up with a framework for doing forms and I wanted to see how they did it. This chapter follows a tutorial style as well. The Form API allows you to define fields, their label, their value, description. Some frameworks take the template approach, where you hammer out your HTML. Some are more configuration based like Drupal making a multi-dim array with keys and values. I can see advantages to both. There is a hook function for validation which allows you to write your validation checks.

PHP gets a bad wrap for security, partly because its pretty easy to learn PHP and newbies don’t always realize what they are doing. There is a chapter devoted to security and includes even some things I didn’t know about — encoding mail headers. The Form API is very secure,  one thing it does is check values that come from dropdowns were actually in the options and it wasn’t something that the hacker made up.

Developer Best Practices are great for the new developer, it talks about using cvs, tags, branches. It talks about how to create and apply patches (hint – you can contribute back to drupal). That is awesome. Alot of open source projects are like “HELP us, submit patches!” and the new user is left with

Caching is another interesting chapter. You will learn  how caching works and how Drupal Core uses it. There is a Cache API that has methods for module creators to make their modules faster.

JQuery … I am not sure if I like it or not, but its part of Drupal 5! I skipped ahead to this chapter to see what its all about. There is a javascript hook built into Drupal making it easy to add, thats pretty cool.

One thing I found lacking in the book is anything about Testing. There are few pages on debugging and some modules to help with testing, but I would like to see more. At least some talk about selenium, which is great for a site made with any framework/cms.

Over all, Thanks APress for another great book!