I got an invite for Atom yesterday. I spent a few hours using it, as opposed to Sublime Text 2, my current editor of choice. Here are the features that I consider that my editor must-have and how Atom handles them.
Last Saturday I had the pleasure to attend LA Ruby Conf for the first time. The conference has two days of workshops, which I did not attend and one day of single-track talks.
I had a great time and think the organizers did a great job. The talks were varied and interesting, with enough breaks to also take advantage of the “hallway track”. It’s always great to talk to the other developers.
Confreaks taped videos of the talks, but they are not yet available.
See you next year, @larubyconf
It turns out that she misspoke in the original Ruby Rogues Podcast Episode and has since revised them to be:
- No More Than:
- 100 lines per class
- 5 lines per method
- 4 (or even better 3) parameters per method (each hash key counts)
- 1 instance variable per view
- 2 class names per controller (1 business object, 1 presentation object)
The main difference from the previous rules, as mentioned on the podcast is that each controller can know about 2 class names: This is pretty significant. I have been trying to adhere to the original rules for a long time. However, no matter how hard I tried, I could not get a controller action that just talked to 1 object, because that meant coupling the view to the business object, which just felt wrong. In the end, I just let it be and created a business object, which was later decorated by another object for the view. After hearing Sandi’s revised rules, I feel vindicated!
This reminds me of the dispensation: You can break any of the rules, as long as someone else on the team agrees.
Code draws code like it
I really enjoyed hearing Sandi talk. The SDRuby taping is not yet available, but it looks like Sandi gave the same talk elsewhere.
Recently I came across a spec that didn’t seem to be executing the assertion block passed in to the raise_error expectation. Leaving the bare essentials for the example:
1 2 3 4 5 6 7 8 9
We raise an exception, assert that it was raised and the try to assert something about the exception. In this example,
1.should == 2 should clearly fail. However, when we run this:
1 2 3 4
It would seem that the block is never being executed.
I love DelayedJob. It’s my go-to-gem for background processing in Rails, mainly because it works with whatever
data store your project already has in place. No need to bring a different dependency just for background processing. However, using
Delayed::Worker in threads is problematic.