theAdmin.orgGrowing a simple software business

The Joel Test is a great way to quickly test a software development team’s performance, even if you are the only developer. I’ve been the sole developer for Little Stream Software for over a year now, so I think it’s a good time to rate how I’ve changed since my “programmer as a cog in the machine” days.

1. Do you use source control?

Yes. In fact I’m advocating using good (Subversion) and great (Git) source control systems to my customers.

2. Can you make a build in one step?

This would depend on the project. The majority of the Ruby on Rails projects are built/deployed in one step but most of my PHP projects take several steps. The biggest hurdle is that several of my customers don’t see much benefit from automation, which is a failure to educate on my part. I know one project where I spent a considerable amount of time automating the testing and database changes (think rake db:migrate) and now it’s used by all the developers and on the production systems. Easily hours of time saved with no errors.

Overall though, I would say no I cannot make a build in one step.

3. Do you make daily builds?

Since Ruby and PHP don’t need “builds”, I’m considering builds to be a fresh checkout and smoke test of the application. I used to use CrusieControl.rb to run smoke tests but I’ve neglected it for awhile. No, I don’t make daily builds.

4. Do you have a bug database?

Yes, Redmine is perfect for that.

5. Do you fix bugs before writing new code?

It depends on the customer. Some customers acknowledge a bug’s existence but they decide it isn’t worth fixing. So I get a yes for effort and a “sometimes” in practice.

6. Do you have an up-to-date schedule?

Yes, on every project I set a deadline even if my customer doesn’t have one. This constrains me and lets me focus on getting the work done.

7. Do you have a spec?

Yes, I create a minimal spec for every project. Sometimes it’s vague; when the customer isn’t sure what they want and need flexibility. Sometimes it’s very detailed; when it’s creating a public API, major integration point, or requires a fixed priced and fixed scope bid.

8. Do programmers have quiet working conditions?

Yes, since I work from home I can control the amount of noise where I work. I tried to work in a coffee shop but it’s way to loud for me to get into the zone.

I’d really like to watch a programmer who in a coffee shop and see how much work they actually get done.

9. Do you use the best tools money can buy?

This is a tough question. For me a tool needs to be useful and the user needs to be knowledgeable enough to use it to it’s full potential. Eclipse is a wonderful tool for many people but in my hands it’s just a pretty text editor because I don’t have the knowledge to take advantage of it.

If I have the choice, I use the best tools available to me (Ruby on Rails, git, Emacs, Linux, Rake) but some projects require worse tools. These tools are not inherently worse but in my hands they don’t help me as much as my best tools.

Yes, I use the best tools I have access to and try to increase my knowledge of them frequently.

10. Do you have testers?

No, since I’m the only person I don’t have testers. I’ve checked out a few freelance testers but most of them only caught obvious bugs and I didn’t see much value from them.

11. Do new candidates write code during their interview?

Yes, if I hired anyone I would require them to write code or provide examples of their work.

12. Do you do hallway usability testing?

Yes, when I’m working on a team with other developers I try to make them use my code. I especially use this on integration points and I’ve had some great results so far.

Summary

So I scored 9 points out of 12 (1, 4, 5, 6, 7, 8, 9, 11, 12) which means I have “serious problems” according to Joel. I don’t agree with the summary because my “team” is only me but I do see a lot of room for improvement. I can increase my performance by adding some more automation to my work, specifically:

• Create build files to build and deploy a project in one step.
• Fix CrusieControl.rb and add all my projects to it.

So how am I doing compared to the “programmer as a cog in the machine” days? Lets just say they would be happy to get 9 points.

Eric

I’ve been using Prototype as my main JavaScript library for a couple of years now. I never made the conscious choice to use it at first, it was bundled with Ruby on Rails and I slowly gained experience with it as I used Rails. Recently I’ve been doing more non-Rails applications with Prototype and have been having difficulties keeping the JavaScript maintainable and easy to understand. I’ve tried looking at several different ways to improve the code but they all called for some complex boilerplate or advanced JavaScript hackery.

Hearing a lot about jQuery and how easy it is to maintain, I decided to take a hard look at it. Several people have already recommended that I take a look at jQuery and was recently involved on a project that (mis-)used jQuery. Not wanting to be left in the dark anymore, I decided to take a look at jQuery on one of my larger JavaScript projects.

After using jQuery for a few days, I’m already hooked on three features:

1. jQuery makes it really easy to wrap all your code in a namespace. Namespacing your JavaScript is important so you will not collide with other libraries or developers. By default you can put everything in the jQuery namespace, but it’s easy to extend jQuery to create your own namespace. I’ve been creating Prototype classes for this but they have a really dense syntax and are not commonly used.

2. jQuery allows you to chain function calls. This means you can call a function on an object and then call another function on the object again. This allows you to pipe data through an object easily and reads a lot like Ruby. A great example I found on the jQuery wiki was hooking up a global Ajax indicator. This is a portion of a website that shows the user that something is happening in the background whenever an Ajax process is underway (like GMail’s red loading section)

   
   jQuery("#loading").bind("ajaxSend", function(){
       jQuery(this).show();
   }).bind("ajaxComplete", function(){
       jQuery(this).hide();
   });
   

   Looks like a normal function but if you break it down, it’s a one liner chained together.

   
   jQuery("#loading").bind("ajaxSend", function(){ jQuery(this).show(); }).bind("ajaxComplete", function(){ jQuery(this).hide(); });
   

3. The third benefit jQuery has is it’s plugin system. I’ve only explored it a bit but I see a huge community built up around third party plugins. I’ve always had issues with Event listeners with Prototype but I was able to just download a plugin that did the heavy lifting for me and let me move on to a more important part of the application. It will also help maintainance by being able to build custom plugins for each application.

I hate to echo what everyone else is saying but if you are doing a lot of JavaScript development, take a look at jQuery. There is also a project attempting to replace all the Rails Prototype/Scriptaculous helpers with jQuery versions. I’m not ready to rewrite all my Prototype code yet but I’m seriously considering using jQuery for all new development.

Eric

I’ve just released an update to Timesheet plugin for Redmine.

Changes

There are a few minor updates in this release, I fixed one bug in the calendar popup and have redesigned the form to use the screen real estate better.

• Feature #710: Wrap all common elements in fieldsets
• Feature #1223: Cleanup the Filter UI to not use as much screen space.
• Bug #1267: No action taken on selection of date

You can see more details on the Activity and Roadmap pages.

Upgrade

As part of my infatuation with git, this project is now hosted on GitHub.

Zip

1. Download the latest zip file from https://projects.littlestreamsoftware.com
2. Unzip the file to your Redmine into vendor/plugins
3. Restart your Redmine

Git

1. Open a shell to your Redmine’s vendor/plugins/timesheet_plugin folder
2. Update your Git copy with git pull
3. Restart your Redmine

SVN

To migrate from the svn copy to the git copy you will need to remove the plugin and reinstall it. Just remove the vendor/plugins/timesheet_plugin directory and follow the directions below.

Install

If you are installing a fresh copy, follow these steps:

1. Download the plugin. There are three supported ways:

   • Downloading the latest archive file from Little Stream Software projects

   • Checkout the source from Git

     cd vendor/plugins/ && git clone git://github.com/edavis10/redmine-timesheet-plugin.git timesheet_plugin

   • Install it using Rail’s plugin installer

     script/plugin install git://github.com/edavis10/redmine-timesheet-plugin.git

2. Install the plugin as described at http://www.redmine.org/wiki/redmine/Plugins. (this plugin doesn’t require migration).

3. Login to your Redmine install as an Administrator.
4. Enable the “Run Timesheet” permissions for your Roles.
5. Add the “Timesheet module” to the enabled modules for your project.
6. The link to the plugin should appear on that project’s navigation.

What’s next

Since I don’t have the time to add a bunch of new features, I’m going to work with the Redmine core developers and try to migrate the Timesheet plugin’s features into the Redmine core.

Help

If you need help you can leave a comment here or enter an issue directly into my bug tracker.

Eric

RailsConf 2008 is over and I’ve had some time to rest and recollect my thoughts on the sessions. Below is a quick summary of the main ideas I picked up in each session.

Friday 5/30/2008 (Day 1)

• Joel Spolsky keynote - The UI should help the user.
• Entrepreneurs on Rails - Work will always come in feast or famine cycles. It’s how you learn to deal with it that will determine your success.
• Hosting and the Woes - Caching is the key. Modern servers are powerful enough to handle a large load with some basic optimization and common sense.
• Faster better ORM with DataMapper - DataMapper shows that the Rails way is not the only way, we have the freedom to choose what tool will work best.
• The Profitable Programmer - You only have to spend one day a week to work on your idea. That’s how Peepcode was started.
• Microapps for Fun and Profit - Take a day off and build an application. Nothing is better for a developer than to create something new and show it off to the world.

Saturday 5/31/2008 (Day 2)

• Jeremy Kemper Keynote - Rails is improving at an impressive rate with the community support.
• Using Git to Manage and Deploy Rails Apps - Git is flexible and stupid simple once you get the underlying concepts. I’ve seen wikis and backup systems using git as the file storage.
• Advanced RESTful Rails - Sometimes the relationship between data should be the resource, not just the data itself.
• Lightning Talks - Didn’t really get much from the Lightning talks.
• Integration Testing with RSpec’s Story Runner - Doing full stack testing is really useful to check the interactions between discrete components but it isn’t easy or maintainable.
• Meta-programming and Ruby Internals for Rails Programmers - A deep understanding of your runtime environment will make you a better programmer.

Sunday 6/1/2008 (Day 3)

• “Design Patterns” in Ruby - Many of the “Design Patterns” in other languages can be trivially implemented using Ruby’s built in language constructs.
• Advanced Mongrel: Handlers and Plugins - Since Mongrel is written in Ruby, it can be easily extended using Ruby. This is an easy way to bypass the Rails stack.
• Oh the Fail I’ve Known - Failure is the best teacher so we all need to hurry up and fail our first 50 times.
• Building an App in 48 Hours, A Rails Rumble Case Study - 48 hours is a long crunch time and near the end many bad mistakes are made, predominately around testing.
• Rails Core Panel - Releasing Rails is taking longer to because testers are waiting for a release but the core needs edge tested more before hand.

I’ll be digging into a few of these topics over time. I’m looking to do some more with Microapps, Git, and meta-programming.

Eric

I went to two tutorial tracks yesterday, Refactoring Your Rails Application and Refactotum: Contributing to Open Source.

Refactoring Your Rails Application

Refactoring Your Rails Application was good presentation by Zach Dennis and Drew Colthorp. It was great to see how some advanced Rails developers do some advanced refactorings but I got lost as they rushed through the examples. I’m still on a 1.6 GHz Pentium M so RSpec doesn’t run as fast as on the shiny MacBooks. I think the best benefit is the 70 page PDF they sent out that has details about doing several more refactorings. I’ll be using it later to clean up some of my old code.

Refactotum: Contributing to Open Source

I really enjoyed this session. I didn’t know going into it but a Refactotum is basically a large peer programming event where code is written for Open Source projects. So for about half the session the presentors talked about using several tools to check Rails code for areas that need improvement and used the other half to go around and help everyone try to create a patch for an Open Source Rails project. One thing I really learned was: you don’t have to contribute by sending in a new feature or bug fix, often some additional unit tests or refactoring is a much needed contribution.

Some tools they talked about:

• RCov
• Flog
• tarantula
• Git - Not Ruby specific but works great will all Open Source projects.

Friday Schedule

Today’s schedule is going to be a lot more busy, since this is the first day of the real conference. If you are going to any of the events or sessions below, check for me there:

• 9:15am - 10:15am Joel Spolsky keynote
• 10:45am - 11:35am Entrepreneurs On Rails
• 11:45am - 12:35pm Hosting and the Woes
• 1:50pm - 2:40pm Faster, Better, ORM with DataMapper
• 2:50pm - 3:40pm The Profitable Programmer: Creating Successful Side Projects
• 4:25pm - 5:15pm Microapps for Fun and profit
• 7:40pm - 8:00pm Ruby Heroes Award Ceremony
• 8:00pm - 9:00pm David Heinemeier Hansson keynote

Eric