.Net Ramblings

The SSL certificate for my Heroku app is expiring in a few days, and I wanted to see if I could use Dreamhost for Heroku’s SSL certificate.  I had previously used GoDaddy, but their certificates cost $49 whereas Dreamhost only cost $15 for a year.

I tried finding documentation online as to whether a Dreamhost certificate will work with Heroku, but I wasn’t able to find much, so I gave it a try myself.

And it turns out that a SSL certificate from Dreamhost does work with Heroku.

Here are the basic instructions for updating a Heroku’s SSL cert with one from Dreamhost.

1. Login to Dreamhost’s web panel and purchase an SSL certificate for your domain
2. Once the SSL certificate has been granted, you can access it from the Web Panel
   1. Menu -> Domains -> Secure Hosting
   2. Find the certificate under ‘Secure Certificates’ section
   3. Click on the ‘View’ link to the right of the certificate
   4. Click on the ‘Keys’ tab to see the certificate and private key
3. There are 3 parts to the certificate: The certificate itself, the private key, and the intermediate certificate
4. Open a text editor and copy the contents of the Certificate to the file
5. Then copy the contents of the Intermediate Certificate and paste it to the end of the file
   1. Make sure there is a blank line between the Certificate and Intermediate Certificate
6. Save the file as domain.pem
7. Copy the contents of the Prive Key and save it to a separate file named private.key
8. Now you’re ready to upload the certicate to Heroku
9. If you already have a certificate on your Heroku app, you will need to remove it by running heroku ssl:clear
10. To add the certificate run heroku ssl:add domain.pem private.key

By default factory_girl determines a factory’s class by its name. So if factory is named :user, then it instantiates the User class.

This doesn’t work well if the class is in a namespace. For example, Factory.define :user will not work for a User class in the Admin namespace. You will get the following error:

NameError: uninitialized constant User

To fix this, you can just pass in the optional :class argument to define: Factory.define :user, :class => Admin::User

I’ve been developing in rails for 8 months now, and so far I have been able to find a gem for just about everything I need, but today I came across a requirement that I could not find a gem for, so I am embarking on creating my first gem to contribute back to the open source community. More specifically, I am creating a rails railtie that version 3 of rails introduced.

I am calling the gem person_search and it will help find people based on their name. Doing a simple search for ‘Paul’ using ActiveRecord isn’t a big deal, but the benefit person_search will provide is that it also takes into account common nick names, so when ‘Katie’ is searched for, it returns ‘Katie’ and also matches on ‘Katherine’, ‘Kate’, and ‘Katy’.

Another feature person_search will provide is parsing full names so that a search for ‘Bill Clinton’ will return a match on ‘Clinton, Bill’ and ‘Bill Jefferson Clinton’.

The project is hosted on github at https://github.com/paulyoder/person_search and I’ll be sharing my experience of creating it on this blog.

For most of my development career I have been a .Net developer. And I have enjoyed the .Net framework and using Visual Studio. And Microsoft has done a good job of continually updating the language and providing more value. Today I couldn’t imagine programming without generics (.Net 2.0), lambda expressions (.Net 3.5) or optional parameters (.Net 4.0).

But now I have found something that has ruined my .Net career: Ruby.

Ruby has opened my eyes to the true fun that is possible with coding. With Ruby I no longer have to monotonously write plumbing code that’s only needed to setup basic communication.

Here’s an example of what I’m talking about. The examples below compares the amount of code that is needed to create a domain object and connect it to a database. The .Net version is using Fluent NHibernate while the Ruby version is using ActiveRecord

.Net

public class Person
{
   public virtual int Id { get; set; }
   public virtual string FirstName { get; set; }
   public virtual string LastName { get; set; }
   public virtual DateTime Birthdate { get; set; }
   public virtual string Phone { get; set; }
}

public class PersonMap : ClassMap
{
   public PersonMap()
   {
      Table("people");
      Id(x => x.Id).Generate().Natively();
      Map(x => x.FirstName);
      Map(x => x.LastName);
      Map(x => x.Birthdate);
      Map(x => x.Phone);
   }
}

Ruby

class Person << ActiveRecord::Base
end

In this common example, the amount of plumbing code went down from 20 lines to 2 lines. Ruby did the same thing in 10% of the lines that .Net did.

And that’s just one of the many reasons Ruby has ruined me. I won’t go into detail of how simple it is to add external libraries through Ruby Gems and how Ruby has many more great open source projects that are free and easy to use.

I will still be coding in .Net because the place I work is a .Net shop, but you can be sure that I’ll be coding more and more in Ruby during my personal time.

The Single Responsibility Principle states that a class should only have one reason to change. Another possible title for this design principle would be the Single Reason to Change Principle.

Why is it important for a class to have a single reason to change and what are its benefits? One of the easiest ways to enhance the maintainability of a code base is to have it loosely coupled. In loosely coupled code, a change to one feature does not affect any other functionality. It is the opposite of spaghetti code where everything happens in one big method and changing how one functionality works very likely affects all the other functionality. And to get this loosely coupled code, each feature should be broken up into individual classes. If each class implements only one feature, then it only has one reason to change and when you change that feature you don’t have to worry about it breaking anything else in the code base.

A good example of a violation of the Single Responsibility Principle is having data validation and storage in the same class. Take a look at the code below as an example.

public virtual void Save(User user)
{
  if (string.IsNullOrEmpty(user.Name))
    throw new ValidationException("User name cannot be blank");

  using (var conn = new SqlConnection("connection string"))
  using (var command = conn.CreateCommand())
  {
    command.CommandText = "INSERT INTO USERS (Name) VALUES (:name)";
    command.Parameters.Add(new SqlParameter(":name", user.Name));
    command.ExecuteNonQuery();
  }
}

This code violates the Single Responsibility Principle because it performs two tasks: validating the object and persisting the object. These two responsibilities are orthogonal to each other and should be separated out to two classes since neither one affects the other.

Now that I have explained this design pattern, I want to give my opinion on its usage. I believe this principle is good to follow when designing applications but I don’t think it should followed to a T. I say this because I see some people take it too far. For instance, take for example the interface below.

public interface Modem
{
  public void Dial(string phoneNumber);
  public void Hangup();
  public void Send(string message);
  public string Receive();
}

Some would say the methods on this interface need separated out into 2 interfaces, one that takes care of the connection (Dial and Hangup) and another that takes care of the communication (Send and Receive). Personally I disagree. Yes, I can see how some could consider there being 2 responsibilities in this class, but then what is to keep the interface from being broken up into 4 interfaces, one for each method, because I could also see how Dial is a distinct responsibility from Hangup and Send is a different responsibility than Receive.

As far as implementing the Single Responsibility Principle, I personally advocate that there needs to be a sliding scale on how fine tuned the responsibilities are split out.

Before I expound on my position further, I need to introduce a term called responsibility group. A responsibility group is a set of responsibilities that correlate to each other in one way or another. The size of a responsibility group can be anywhere from large to small. The smaller the responsibility group, the more closely each responsibility correlates to each other, and the larger the group, the more loosely the responsibilities correlate to each other.

The smaller the application, the larger the responsibility group should be, and the larger the application, the smaller the responsibility group should be. The graph below shows a visual representation of what I’m talking about.

I advocate this view as a result of my own experience. I volunteer my time at a non-profit organization where I have developed quite a few applications to help automate some of their administrative tasks. Many of these applications are quite small with less than 100 lines of written code. In these applications do I separate out the validation logic from the persistent logic? No, it’s not worth it. If I did I would very likely have more classes than I did lines of code. However, in my open source project (Linq to Excel) I have much smaller responsibility groups since it’s a larger project with many features.

One of the arguments for using this principle is making the code easier to maintain and add enhancements. But with small applications that serve a single specific purpose, it’s quite unlikely that they will change. And even if they do change and enhancements are added, the Single Responsibility Principle with smaller responsibility groups can be implemented by refactoring the code when the enhancements are added.

These are my thoughts and 2 cents worth on the Single Responsibility Principle. I know I do not follow the main stream of thought for this principle so I would love to receive feedback on my ideas on this principle. What is your experience with using this principle?