Retrospective

I just finished work on Dashboard, the content management system for musicians that I’ve been working on for the last month. It took a little bit longer than I had planned on, but overall the project went well. I learned a lot. This was my first real Ruby on Rails project that I worked on all by myself. Before this all I had done was work on the IRPA cms. Here is a list of things I learned as well as things that just went well.

Pat on the Back

CRUD: In my quest to learn how to set up a many-to-many relationship I came across David Heinemeier Hansson’s keynote from RailsConf, which I have already told you about, and I came to learn a new way of structuring code.

file_column, acts_as_paranoid, foreign_key_migrations, and artist_location are the plugins I used on this project that I had never used before. Some required a little more work to get working, but they are were all very helpful in building the features of the project.

Migrations are something I had never used before, simply keeping my schema in a single sql file, but now I would never build a Rails app without them. I’m not sure I used them the most efficiently, as I had some problems adding and dropping columns in later migrations and often refactored everything into the original. This was fine for development, but it would be unnaceptable for making changes on a production application.

Working with a client on a daily basis was a new, and exciting, experience. This really was an agile process as I would begin each day by working on a feature, by the time I had finished working on it, the client would be online and I could show it to him and get feedback on it while, or before, I worked on the next feature. Aside from a few design flaws, for which we were both responsible, everything went smoothly and quickly.

I ran my own SVN server and used this religiously, committing every little feature I added before working on another. With 76 revisions, it made it easy to save myself when things went awry. This also made it easy to install the latest version, and keep it updated, on the client’s server.

Room for Improvement

Not everything went perfectly though and there are things I plan on doing better next time.

Design flaws and misunderstanding were the cause of a few headaches. I spent two days refactoring code because I had written my routes incorrectly and then we changed how something was organized. If I hadn’t written the routes incorrectly the change would have taken 5 minutes, instead it took most the day. However, because of this refactoring, I fixed the routing problem.

It was greating using plugins and outside libraries to accomplish stuff, it saved countless hours, but not all of them are easy to install and use. Documentation on some of them is minimal or nonexistant, and none of them have “enough” documentation. However, the people in #rubyonrails, and especially technoweenie the author of several plugins, were very helpful. Installing RMagick and configuring it with file_column was a breeze on Windows. I was impressed and very surprised. Installing ffmpeg and all of its dependencies however was a nightmare. It certainly was not ever meant to be installed on windows and I spent most of the day trying to figure out what dependencies I was supposed to install, and where to install them (Program Files was a bad place due to the space). Then once all of this was installed I had to build ffmpeg. This wouldn’t surprise anyone installing it on Linux, but this is Windows. Even after I got it completely installed I still had problems with it and even now it doesn’t work perfectly.

Project management should have been better. I used my wiki to write down design ideas, list required features, and keep track of bugs. Wikis really weren’t designed to do this and after using Trac, which is wonderful, it was unpleasant. I have recently installed ActiveCollab on my webserver and will be using it in the future.

I’m not sure what sort of documentation I needed to add to my code. Most rails code is fairly well self-documented. If you don’t know what the show() method in the ArtistController does, then you need to learn about Rails, not read the documentation. But I did have some unique methods in Application.rb and it might have been useful to document some other unique things I did.

I’m ashamed to admit this, but I didn’t do any formal testing. Rails comes with functionality for testing and it is supposedly very easy and it is something every programmer should do, but I didn’t. I was learning so many other things that it didn’t feel worthwhile for this project. I’m still not sure how useful it would have been. I guess we’ll see how bulletproof my code is over the next few weeks as the client plays with it. I plan on reading the testing chapter in my Agile Development book and using it in the next project.

Wrap Up

Overall, I enjoyed working on this project. I look forward to seeing what some artists do with the front end and seeing how popular it becomes. One of the most exciting things about it, is that a lot of the code is very similar to what I needed to write for ShowCase, so I will be copying a lot of that over. Look out for a ShowCase update soon.