5 things every developer should learn from Rails

I spent the last few weeks working on a Rails project. Although there was a lot to learn, I feel as though I have a decent understanding of Ruby and Rails at this point. I am by no means an expert, but I can do the basics without googling. I figured I would document my thoughts on what every developer should learn from the Rails framework.

  • Gems - Having a package manager to to handle dependencies rocks. In contrast, every single .NET library includes all its dependencies because there is no package manager to make it easy. Hopefully nu can start to fill this void.
  • Generators - Generators save your team time because they aren’t spending time typing out common patterns in a project. Many frameworks like .NET have code generation, but the barrier to entry seems high. Maybe I just haven’t spent enough time out it, but in a few years of programming .NET, I haven’t generated a single class.
  • Conventions - Developers shouldn’t have to ask, Where should this class go?. Conventions should define that, otherwise teams are forced to define their own (which usually leads to a lack thereof except in experienced teams).
  • Database management – In nearly every app I have worked with, schema gen, creation, migration, and testing integration are a pain point. Many libraries like NHibernate have the capability of doing all these tasks, but there is no instruction manual for setting it up. Therefore, most projects don’t manage their database very well.
  • The build, the build, the build – Dependencies, database migrations, multiple environments, testing…need I say more? Having an out of the box build that does more than plain old compilation is a must in any solid framework. Like everything else, tools like MSBuild can do all this but the team is forced to start from scratch.

Where does Rails succeed where many applications and frameworks like ASP.NET MVC fail? Rails succeeds at allowing developers to focus on the application, not the plumbing.

nu – Gems for .NET

Package management has been on my mind for months as one of the greatest short comings in .NET. If you spend two hours using Ruby and gems, you realize how much easier it is than finding the appropriate .NET assemblies to use. It also promotes using open source libraries, instead of re-inventing the wheel.

nu aims to provide this for .NET.

I checked it out tonight. Here is my experience.

First step is to install it, and ruby is the only pre-req. The following commands show how to install and use it.

> gem install nu
> mkdir test
> cd test
> nu install nunit
> nu install nhibernate

Wow, that was easy. nu downloaded nhibernate and nunit, and placed them in the lib folder (including all of NHibernate’s dependencies). By the way, it literally took less than 30s for me to do this.

So what do I think?

  • It is an easy and fast delivery tool.
  • Using Ruby isn’t that big of a deal, but I think that is my opinion, not the community opinion.
  • It is new, so it has a ways to go in terms of functionality in discovery. I can’t hate because at least they have released something and I have just dreamed about releasing something.
  • Build integration (and probably Visual Studio) is going to be key. And by build, I don’t just mean NAnt and UppercuT, but MSbuild too.
  • The biggest hurdle is building a “gem” community in .NET. For some reason, creating a .NET gem seems kind of awkward (even though it isn’t that hard).

When TDD Goes Bad, NUnit wasted 2 hours of my night

[TestFixture]
public class IHateNunit
{
    [Test]
    public void A_list_works()
    {
        IList<string> strs = new List<string>() { "asdf" };
 
        //Double Pass
        Assert.That(strs.Count, Is.EqualTo(1));
        Assert.That(strs, Has.Count(1));
    }
    [Test]
    public void An_array_doesnt()
    {
        IList<string> strs = new string[] { "asdf" };
 
        //Pass
        Assert.That(strs.Count, Is.EqualTo(1));
 
        //#FAIL
        Assert.That(strs, Has.Count(1));
    }
}

First look at NDepend

10-5-2009 7-25-21 PM

Last night, I spent a good amount of time with NDepend on one of my largest projects. I have seen NDepend before, but never used it myself. These are my thoughts on using it, and hopefully the first of many posts about how it has made my projects better.

How to get started?

The first step was selecting all the assemblies to analyze. This actually wasn’t as easy as I thought, but it was really due to my project setup and not NDepend. When you add a Visual Studio solution to NDepend, it will show warnings and errors that it sees from the project DLLs. I had three main issues to solve.

One, I had a few projects unloaded in the solution, which meant they had stale binaries in their build folders. This confused NDepend, so I loaded the projects, rebuilt, and fixed it.

Second, System.Web.Mvc wasn’t found. This was an interesting issue where I had to set “Copy Local” true to the System.Web.Mvc reference. Not entirely for sure why, but it fixed the error.

10-5-2009 7-37-26 PM

Finally, NDepend helped me catch a very odd problem, using different versions of an assembly. I had a few projects referencing a new version, while the other projects referenced an old version. I have no idea how this happened, but I was glad to catch it.

Now, I was ready to analyze.

Where to begin?

NDepend spews out a crazy amount of information. It is really hard to know where to get started. My advice, especially on a large project where you are running NDepend for the first time, close the dependency matrix, graph, and metrics views. Start with the CQL queries.

Why? Because they are easier to understand and have clear solutions (for the most part).

Here is how I immediately improved my project, without reading a single sentence of documentation. First, I looked at the unused types warning. I removed 5 classes that weren’t use, which is probably the most exhilarating feeling.

10-6-2009 10-06-30 AM

I also really liked how it called out generic exceptions being thrown. All too often, developers put place holder generic exceptions in the code, and never get around to creating custom exceptions.
10-6-2009 10-06-43 AM

Lastly, the code quailty queries are awesome. I love seeing warnings for code complexity, large methods, etc. These are the methods that can easily be refactored and make the code base a little easier for everyone to work with. Every query in code quality is solid.
10-6-2009 10-30-56 AM

What didn’t I like?

I think NDepend has a high learning curve. It throws a lot of info at you and you are responsible for figuring it out. During my first look, I didn’t bother with most of the complex functionality. Even with CQL queries, there aren’t easy-to-find reasons why some of the warnings even exist. Here is an example, why is List.Contains() worth warning? I am not entirely for sure, so it makes me less prone to gain any value from this query.

10-6-2009 10-28-32 AM

One thing I quickly realized was I needed an easy way to ignore collecting metrics on certain types. For example, I have a lot of web services with generated code. I wanted to ignore most of these classes for the report. I couldn’t find an easy or quick way to do it.

Final thoughts

The one thing I realized after getting started with NDepend is that it is up to the user how valuable it is. Just like code quality and testing is a commitment, so is using NDepend. It won’t solve all your problems out of the box, but if you want help analyzing your codebase so you can improve it, NDepend is your tool.

For me, I think I can learn a lot from using it, although I should probably start on a smaller project and work my way up.