blog

Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that, I really do. For me practicing TDD in a rails environment is much harder than when I work on my OSS libraries. There are many reasons why TDD in Rails is just a bit harder than it could be but that’s a big, separate subject. In this post I want to explain that TDD can be fun! ...

Code metrics and code metric tools can be both helpful and harmful. The difference between the two is learning to interpret the results and use the feedback to improve yourself and your code. I have a lot of experience with code metric tools. Over the last couple of years I’ve used them on a daily basis. Tools measuring simple things like test coverage, lines of code [LoC] per class/method, naming, and column length along with more advanced measurements for code complexity, churn, and mutation coverage. This experience has taught me a lot about code quality and object-oriented design. I believe that the lessons learned and the time spend refactoring my code have made me a better programmer. As is usually the case, nothing’s perfect and I have noticed that I encounter very specific pitfalls along the way. Here’s some of them and how I deal with them. I hope that my experience can help you when you face the same problems. ...

I don’t have exact numbers but I believe TDD isn’t really popular amongst rails developers. This shouldn’t be a surprise given that the two of the most complex elements in the rails stack, models and controllers, are very convoluted concepts and are simply hard to test. When you’re building a typical rails application most of the business logic lives in the active record models and controllers. Testing controllers in rails is a bit cumbersome but I still encourage people to write tests for them. What about active record models? How do you test them? Is it actually possible to test-drive active record models? ...

I was wondering what do we, rubyists, think about dependency injection these days as I remember some discussions about it which were mostly lots of post-java-trauma type of criticism. I had this blog post in the back of my head for a long time but knowing that this subject was sort of…explored already, I decided to see what google has to say before writing it. So I typed “ruby dependency injection” and got this: ...

Last two years have been pretty intensive for me. I became a husband, a father, a co-founder of Powow and during that time I tried to contribute as much as I could to OSS. I was mostly focused on Virtus and Ruby Object Mapper which consumed a lot of my time and energy. I thought I could go on but I was mistaken. I’ve burned out and decided to take a break from my OSS activities and focus on my family and daily work. ...

I’m happy to announce that after 1486 commits Virtus 1.0.0 has been released. It comes with a lot of neat changes, improvements and new features. Here’s a quick summary of my favorite additions and changes. No more “include Virtus” That’s right. With 1.0.0 including Virtus module is deprecated. Instead you should use something called “custom extension builder”. It’s really cool, check this out: # for classes class User include Virtus.model # attributes go here end # for modules module CommonAttributes include Virtus.module # attributes go here end The reason for this change is that your classes and modules won’t be polluted with Virtus namespace…but that’s not everything… ...

Last Friday we finally released the first version of Ruby Object Mapper. It’s a big step for the project as we’ve established foundation of the whole system. There are many missing features, crucial ones, like support for RDBMS, server-side generated keys or a full-blown Unit of Work but…we’ll be adding those in the upcoming future releases. With the foundation in place it’ll be much easier for us to continue working on ROM so you should see frequent releases from now on with important additions. ...

When working on DataMapper and its libraries we put a lot of effort into testing. Our libraries must have 100% code coverage and even that is not enough. What we want to achieve eventually is full mutation coverage. What is that? If you’ve ever heard or used Heckle then you’re probably familiar with the concept and you can skip the first part of this post and read about mutant. Code Coverage vs Mutation Coverage If your library has 100% code coverage and you think you did a great job then I have some bad news for you. You did a decent job but there’s a big risk you missed a lot while writing your tests and there are bugs that sooner or later users of your library will discover. Sometimes it’s not a big tragedy, you’ll get a bug report, you’ll fix the bug and everybody’s happy. On the other hand there’s a risk your code base is big enough that bugs that are found too late might be really difficult to fix. This can even require a bigger refactoring just to fix something. That’s one of the reasons why mutation testing can you help you in catching bugs early enough and making sure your code is going in a good direction. ...

...

You think you’ve done everything with Ruby? How about subclassing Module? It’s an interesting technique that I’ve been experimenting with lately. One of the downsides of using modules in Ruby is that a module doesn’t have a state. When you mix it into another class you’re basically copying methods from one place to another. What if extending an object with new methods requires a state? Where would you put that state? ...