My Job this Semester

So far this semester, I've basically just been posting about the traveling I did this winter. But there has been stuff going on here at the school in spite of my silence about it.

The school's current website for the department of foreign affairs is awful. In addition to the fact that it's just plain ugly, it's composed entirely of static html pages--which is a royal pain to maintain. Since I have a computer science background, the school asked me if I'd be willing to create a new website for them while teaching fewer classes. I don't enjoy teaching very much (at least not when I teach the same lesson nine times per week), so I was more than happy to make that swap. Originally, I was only going to teach 2 classes (for 4 hours per week), but one of the English teachers had to go home to be with her sister (who was just diagnosed with cancer), so I wound up with 4 classes (for 8 hours per week). I still spend lots of time with students (which is what I enjoy about being here), and my classes are more enjoyable since I teach fewer of them, and the rest of the time I spend working on the website.

I know I've got a few readers who are also computer programmers, so I thought I'd talk about the website project for a bit. If you're not the technical type, feel free to stop reading here, as the rest of this probably won't make too much sense to you.

My previous programming experience is almost entirely in building desktop database applications (that's what we developed at Intuitive Manufacturing Systems, my former employer). I've developed a grand total of one web application. I took a class in college called "Web Application Development using C#." The resulting stock quote website is still online. (But I hesitated to post a link to it because it's so embarrassing. Also, some parts no longer work due to upgrades to some of the software on the server, including MySQL). Web development is not my forte--but I figured it was time to start getting better at it, since the web is taking over more and more of the computing world.

All of my development work the past 3 years has been done using .NET. I like .NET, and I like it a lot. If I could have used Visual Studio 2005, I probably would have used ASP.NET for this project. However, the only version of VS that I own is VS .NET 2002 (using .NET 1.0. It's not even .NET 1.1!). I know they have free "express" versions you can download from the Microsoft website, but to download them you have to have Windows XP Service Pack 2 installed, which in turn requires a "genuine windows" validation check. You've probably heard about how rampant software piracy is in China, and I'm using a computer provided by the school....so you do the math. After getting used to new .NET 2.0 features like generics, there was no way I was going back to .NET 1.0. So I decided to rule out using ASP.NET.

Instead, I decided to use a very new framework: Ruby on Rails. It's the "new kid on the block", so to speak, but so far I've found that it's been deserving of the accolades it's received. In no particular order, here are some of the things I like and dislike about Ruby on Rails:
  • I like that Rails uses the MVC (Model-View-Controller) design pattern. This is a proven design pattern that works well for nearly all business applications (we never called it this, but I realize now that we used it at Intuitive, too). Rails is opinionated in that it essentially forces you to use this pattern. This is a good thing for 99% of the websites being built. For the occasional website that doesn't need this pattern, Rails probably isn't the right choice. But I love how it's baked right into the framework.
  • I like that Rails has unit-testing built right into the framework, and has some great assertions designed specifically for unit testing web applications.
  • I dislike that Rails uses a dynamic scripting language (Ruby). I'm used to static, compiled languages such as VB.NET, C#, C++ and Java. It still seems weird that there is no compile step. It's nice not to have to declare the types of all my variables, but this is also really annoying when I'm looking at some of the framework code and I have no idea what types the variables are (and consequently, what methods the objects have).
  • I like that Rails uses a dynamic scripting language (Ruby). Yes, I just said I dislike this. But I'm learning to like it, too. Rails does lots of things that are "magical", for lack of a better word--things that are virtually impossible in a statically typed language like any of the .NET ones (technically, they probably are possible, but they would be incredibly difficult--you'd have to do tons of crazy reflection and add lots of methods at runtime). For example, your model object dynamically generates attributes ("properties", in .NET-speak) for each of the fields of the database table the model is based on. You can call Person.find_by_name("Myron") and even though this method doesn't exist when it is called, the model object will generate it because their is a name field in your Person table. You can declare "has_many :orders" on your Person model, and suddenly you will have an orders method that acts as an array of order objects, as well as a whole bunch of corresponding methods to work with this association. It's really, really cool--but also a bit difficult to work with first, because looking at the code for the base Model object doesn't tell you what methods it has--instead it has an implementation of the "method_missing" method that adds the necessary methods as they are called.
  • I like how Rails gives you "scaffolding" for use during development. Using one line of code, Rails will generate the necessary pages to do the basic CRUD operations (create, read, update, delete). This isn't intended for use in production applications, and the idea is that you'll change all that code, but it's nice to have that there to start with. It makes incremental development very easy.
  • I like how integrated the AJAX support is. Yesterday I was able to add a drag-and-drop sorting feature to the administrative interface for the photo album portion of the website. This was absolutely a piece of cake. I have no idea how you'd do this with ASP.NET.
  • I dislike the lack of a good IDE. Maybe I'm just an intellisense addict, but a good IDE does wonders for my productivity. I've been using an IDE called RadRails (based on the Java Eclipse IDE) but it doesn't have good intellisense support. And I think this would be tremendously difficult to do, given the dynamic nature of Rails. As I mentioned before, rails sometimes adds methods to your objects at run time when you try to call them and they are missing (by implementing "method_missing"). I can't think of an easy way for an intellisense engine to be able to figure out all the methods that can be added.
  • I dislike the lack of a debugger. Rails comes with a command line utility for use in debugging (you add breakpoint statements to your code, and then run the utility--when it hits the breakpoint, the utility takes over control, and you can inspect variables). However, this is broken with the current release. I've gotten very used to having a debugger, and it's certainly been difficult at times troubleshooting issues without being able to step into the code. Instead, I've had to do things like raise exceptions to see a stack trace, or add logging statements to see variable values at various points in my code. Who knows, maybe it's been good for me to have to do without a debugger, in order to expand my programming skills.
Overall, I'd recommend Ruby on Rails to anyone starting a new web application project. It works best when you can create your database schema to conform to certain expectations Rails has (although all of those can be overridden). I don't think it would work very well for a legacy application.

Hopefully, I should be able to deploy the website soon, and I'll be sure to post a link to it when it's up.
blog comments powered by Disqus

About Me

Husband and father, musician, software engineer at SEOmoz, open source developer specializing in Ruby and Rails, world traveler and Christian.