The Ruby Craftsman
Rails ActiveRecord ORM is a great abstraction on top of SQL, but littering it throughout your code can lead to issues. The amount of methods from inheriting from AR is extensive and many of those are added at run time after a round trip to the database. So it is best not to add to this API with your own decorator methods or business logic. Anything you add to AR should follow it’s responsibility of querying the database. I would like focus on how to narrow the API, but also extend behavior.
In my experience TDD is a guiding principle that produces better code that is a joy to write. There are several arguments for why the tradeoffs are not worth the benefit; I would like to address some of them here.
End-to-end testing, if you let it, will suck the life out of you. Tools like Capybara and PhantomJs provide an easy way to test from the user’s prospective. When I started using these tools initially I didn’t like how long they took to run. I thought then that if we could just make these tools faster they would be the best option to test a web app. Then I ran into other issues where sometimes these tests would be unreliable, failing at random times, making me feel uncertain of whether it was just the test’s flakiness or the new feature I had just added. So I would end up adding
sleepto give them a better chance of passing and sometimes I would end up deleting them because they were wasting my time.
When invoked with a block, yield all permutations of length n of the elements of the array, then return the array itself.
I have been discovering a new design pattern that leads to well designed interface and loosely coupled test. This design, as with many patterns, is not best in all cases but I found it very helpful on multiple occasions. I find the cases where it works best is when there is a deterministic algorithm.
subscribe via RSS