Rails on the Run

Rails experiments by Matt Aimonetti

Browsing Posts tagged tools

In my last post I talked about freelancing. Somebody asked for more details about my “agile tool set” so here I am trying to explain more in details what tools I use.

Environment

mb
Most of my work is done on my 13.3″ sexy black macbook

Tiny and powerful, this laptop is a key element to my productivity. Because of it’s size, I take my MB everywhere. However when at home, the macbook is hooked up to my 22″ LCD screen.

chair I also recently acquired a great office chair that seriously makes a huge difference.

Wilson probably didn’t that in mind when he asked about my tool set, however a great work environment will help you working better, seriously!

Software

In the list of more traditional tools, I use Lighthouse quite a lot. Check this old post to know why I chose to use lighthouse.

Iterations, user stories and acceptance criteria are managed in Lighthouse.

gdocs
However, most of my clients have a hard time defining user stories. To help them in this process, we often end up using Google docs.
GDocs comes handy when a client tries to describe a feature and he ends up telling me: that’s too complicated to explain, I’ll write a document and email it to you.

That’s usually a sign that the client can’t break the feature in small chunks or that there’s some confusion somewhere.
Few hours later, I receive a long Word document or Excel Spreadsheet explaining in details how things are intended to work. After a quick import in Google Docs I use my favorite feature: “Insert Comments”

Here is a screenshot of a comment I made on a client’s document:
comment

GDocs lets you have multiple people editing the same document at the same time. While I’m adding the comments, my client answers them and tries to clarify the document. The client can save any revision he wants and export it back to MS Word if he really wants.

I then extract user stories directly in Google Docs. Often the client quickly understands how things work and will write the user stories and acceptance criteria himself. People are familiar with the page format and often feel more comfortable in this environment. I personally move the user stories in Lighthouse and we then only deal with lighthouse (until a new set of feature requires a virtual drawing board)

Communication

I have a daily standup with each client. You have a variety of alarm system you can use to make sure you are not running late. I don’t have any preferences, but setting up a cellphone reminder can be handy if you have a tendency to forget.

To call my clients I use a VOIP service. Actually I have 2 VOIP services, one for my home line and I use Skype for work. (different providers)

skype provides me with a local phone number, voice mail and unlimited calls in the USA and Canada for something like $90/year.

Skype is also great for video conferences or simple conference calls with many people. Clients know that they can ping me via Skype if they need to. (only during work hours) (I use skype with a Bluetooth headset so I can move around when I talk :) )

Time tracking

I tried different solutions but I wasn’t pleased. I couldn’t find a simple solution properly handling time tracking and invoicing.
I ended up writing a custom solution perfect for my needs: when you want something done right, do it yourself :)

pt

I have simple ajax timers I can start and stop easily (I’m planning on writing a widget too).
Finally, the app generates PDF invoices (using logo etc..) which makes my life easier when it’s invoice time :)

Payment

checkout
Talking about invoices. I generate invoices once a week and the payment request is made via Google Checkout. Google doesn’t charge for transfer fee until the end of the year. Clients might be used to paying by check but seriously it’s a real pain. Checks take forever to arrive, they take forever to clear and banks mess up way too often. I personally prefer to manage my finances online and I think the small fee is worth it.

That’s all I can think of for now. Feel free to let us know what great tool you use.

-Matt

lighthouse logo is one of my favorite web application of the moment. It got publicly released last April (2007) by the activereload ninjas.

Since then, they also released warehouse

but I’ll keep that for another post.

I’ve been using Lighthouse for a little while and I have to admit that I was a bit confused at first. I’d like to share with you why I’m really pleased with Lighthouse and why I think you should consider using it too.

You have probably figured out, I’m a little biased. So let me give you my conclusions right away.

The 2 things that threw me off when I switched from trac to Lighthouse were:

  • the lack of integration with Subversion
  • the weird way of organizing tickets

SVN integration:

So, no Lighthouse doesn’t have a repository browser, you would need to use warehouse, trac, retrospectiva or another tool. I personally don’t think there’s a real need for such a tool, but others might disagree. However, Lighthouse has a subversion beacon(Beacons are services that can be used to interact with Lighthouse). You can really easily install the beacon on your subversion server and committing code will leave a comment in your ticket, add a tag, change the status etc.. check this video to see how it works. That’s something I never did with Trac and I spent a lot of time editing tickets to mention the changesets related to issue related in the ticket.

SVN integration conclusion: better than expected

Organizing tickets:

I like having my tickets well organized. When i switched to Lighhouse and I only had tags to organize my tickets, I felt a bit lost. Actually Lighthouse doesn’t only have tags, it also has milestones. My milestones are usually really simple: iteration 1, iteration 2, iteration 3, investor demo 1, iteration 4, beta etc… Milestones aren’t used to classify tickets but to give them a deadline. So I was still facing an issue since I wanted to organize and prioritize all my user story tickets, bug reports, feature requests etc… using tag is ‘ok’ but finding your tickets later on is a pain. I decided to do something I’ve been doing with trac for a while: adding a keyword in the topic line. For instance I would create a new ticket like that [bug] a user can’t use utf-8 characters in his name. It worked ok but I was still missing something. What I didn’t know was that Rick and Justin already thought about that and came up with a simple/cool solution: ticket bins. Basically, a ticket is just a pool of tickets sharing the same criteria. Creating a ticket bin is dead simple, search for tickets, save the search criteria. That’s it.

ticket bins

I could now start using my critical, essential, nonessential tags and create bins for them. What I love with bins is that they are not folders. A ticket can be inside many bins. For instance, my critical UI open bug will be in my current bugs bin, critical bugs bin and in my UI bin. (I don’t actually have a current bugs bin, but you see my point.)

User stories/bug reports/new features can all be entered via the same interface and you don’t have to worry since they can be easily sorted using your ticket bins.

Organizing tickets conclusion: awesome


What about Basecamp?

Basecamp is great but even DHH says it is not meant for managing development projects. It’s really meant for marketers and managers, in other words: my clients. But you still need a good way of tracking your code, Lighthouse isn’t perfect and I wish it had a better support of user stories but it’s by far the best tool I found so far. Regarding the lack of user stories/criteria support, maybe I’ll just write my own application and use their beacon interface to integrate both apps together…