The Ruby Craftsman
My earliest memory of using a computer was a computer running DOS. To login my dad had made the password the numeric part of our address so I would memorize it. I remember one game that was side scrolling game where a kid was bouncing on a pogo stick.
I’m going to be talking about the global state in the context of a web request. When a request comes in it will be running within a thread. That thread exists for the life of the request. If you want to store some state in the context of that thread you can use thread local variables.
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.
subscribe via RSS