Fri, 25 Dec 2009 14:07:00 GMT

Fear of Committing

When I worked at my last company we used CVS. The central repository was holy and no one could commit changes until they had been reviewed. This led to a fear of committing. What that means is that developers would develop entire features without version control as a backup and a way to undo mistakes. If you went down one path and then decided it wasn't a good idea, you had to manually back out your changes. Also, with such large change sets, developers were almost certain to have conflicting changes. That meant merges were necessary, which could lead to more errors.

Not too long ago, I went to a talk about Git. Git is very different from CVS and even its successor Subversion. Git is distributed. What that means is that everybody has their own copy of the repository. If you want to commit you can. You no longer need to fear committing to the repository because you own it. That means you can commit more often. Git also tracks your history and keeps it intact between repositories. So if you've committed 50 times and another person pulls from your repository, they get all 50 commits. Compare that with CVS or Subversion, where everything is committed as one big change and it will become apparent why Git is much better at handling merges.

A lot of people will tell you Git is fast and Git is distributed. However, those answers are vague and don't describe why it is worth abandoning what you currently have. I think better selling points would be that Git allows developers to use their version control and makes merging the job of the version control rather than the developer. Those are what sold me.

Sun, 11 Oct 2009 17:42:00 GMT

Software That Talks

The other day in my Data Communication and Networks class my teacher asked us a very uninteresting question. What is necessary for a network application? The students in the class suggested a connection, a protocol to communicate, and data to transfer. The teacher said yes to each of those and then he opened up Firefox and downloaded a file. He asked us why does Firefox show a progress bar? Because network latency isn't zero.

He intended to teach us an important lesson about not assuming that communication is not instantaneous. However, every story has more than one moral and the one I got from his lecture was that software needs to communicate with the user. Why does Firefox show a progress bar? Because otherwise the user wouldn't know that something is going on, they would assume it was broken, and they wouldn't have faith in it.

Developers have the tendency to think of their software as a tool to accomplish a job. I think a better mindset would be to anthropomorphize your software. Pretend it is another person; one that your users will interact and communicate with and that will talk back. When I ask a person to do something I expect them to acknowledge what I said, give me feedback on what I asked them to do, and to tell me when they are done. If you treat your software like it is another person you begin to put constraints on it that you might not have done otherwise.

Thu, 10 Sep 2009 20:29:00 GMT

Where to Start?

When you run a race the rules are simple. You start at the start line and you finish at the finish line. Your only goal is to get from one point to the other. Software development is nowhere near as simple.

Yesterday an underclassmen friend of mine asked, "I want to build an application, where do I start?" Being in his position at one time, I can see where he's coming from. You have no defined start line or finish line and there are an innumerable amount of paths you could take. Schools do a very excellent job of showing you how to get between two points that they specify, but in the real world those points aren't nearly as well defined. That is why software development is more than just coding. Software development is about defining the constraints of the race and then, running the race.

Every project starts with a problem that needs to be solved. It is necessary to translate that problem into a set of goals. Once you have defined what your goals are, you have established a finish line. To pick your start line, select the most important goal that is the core of your project. For example, if you're creating a to-do list application, the most important feature is obviously the ability to create a list. Something like search may be nice, but it isn't critical. To build the path between start and finish, keep selecting a new start line after each goal is completed. Every goal is in essence its own race. Each race can be broken down into smaller goals. By breaking a project down into its most basic elements, it becomes much simpler to build than when thinking of the project as a whole.

Fri, 28 Aug 2009 23:09:00 GMT

Creating a Rails App (Ritter2 Part 1)

Note: This guide assumes you already have Ruby, Rails, and MySQL set up. For an excellent guide on how to do so look here.

Create a Project
This will be the first part in my series on how to create a Twitterish Rails application. The steps here are for creating this application, but they can also generally be used for any Rails application. Just about every Rails application has the same basic setup. The first thing you want to do is actually create your application. On the command line type:
rails -d mysql ritter2
That will generate all of the basic files you need for your application. I specified that I wanted to use MySQL as my database. The default for Rails is SQLite.

Start Your Application
At this point you have a working Rails site, but it doesn't do much. Go into your ritter2 folder and enter the following command:
That will start up an instance of your application, which you can access at http://localhost:3000. Nothing too exciting here, except that you have a running server in two commands. Go ahead and kill the server with Crtl-C.

Setup a Database User
Now we're going to setup the database for our Rails application. The first thing I always do is generate a new user for my Rails application to use. You can do that with the following:
mysql -u root -p
You will be prompted for your MySQL root password. After that you can enter the following commands:
grant all on *.* to  "ritter2"@"localhost" identified by "ritter2";

Setup Rails Communication to the Database
Now we need to tell Rails how to connect to the the database. We do that in the database.yml file in the config directory of our application. Open that up and put in the username and password for each database. Here's an example:

Create the Database
Now we want to tell Rails to create the databases. To do that run the following command from the application root:
rake db:create:all
That will create your databases for you.

In the next part of this series I will go through some of the key aspects of setting up authentication for a Rails application.

Sun, 23 Aug 2009 20:21:00 GMT


Once upon a time I wrote a Rails application called Ritter. It was for my Principles of Information Systems class and in my opinion exhibited everything that class was about. It is a twitter clone (approximately) smashed together with my alma mater, RIT. Anyways, the reason I bring this up is because I'm planning on writing a series of articles on how to write a similar application.

If you want to see a live demo you can check it out here.
The source code is available on github.