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.