Kudos to Amtrak for having free Wi-Fi. But the network quality is dependent on a mobile data connection, which varies throughout the trip. Meanwhile, I also have tethering on my phone.
One might guess that the connection quality would be pretty much identical between the two, since they both rely on similar or the same networks over . . .
I just read Uncle Bob's Test Induced Design Damage?.
I keep fearing the day when Rails messes up and becomes too complicated or poorly maintained or something else, but that hasn't happened. It’s really an impressive solid project that solves common problems and steadily integrates popular solutions to new problems with each . . .
And never, ever use ActiveRecord filters.
Rails controllers are a mess.
An ongoing discussion in the Rails community is how, when, and if to test controllers (and how impossible is is to write tests for controllers that are both thorough and not completely isomorphic with implementation).
There are many dimensions to this problem, and it touches a lot of the . . .
Ruby development is hurtling along these days. In 2012 1.9 finally became the norm, and in 2013 we got both 2.0 and 2.1. All of these versions brought small but steady feature improvements.
Here are some thoughts on how I would like the language to change, possibly appropriate for Ruby 3 or Ruby 4.
Methods consistently as . . .
In episode 87 of the fantastic Ruby Rogues podcast, Sandi Metz shares these programming rules:
- Your class can be no longer than 100 lines of code.
- Your methods can be no longer than four, maybe five lines of code.
- You can pass no more than four parameters and you can’t just make it one big hash.
- Your Rails . . .
We would like our tests to not inappropriately cross over layers of the system (such as accessing the database), and we would like our tests to not be dependent on implementation. Unfortunately, these two concerns are often at odds with one another.
Let's say you are testing this method:
class Foo def bar Bar.find( . . .