Disqus - Latest Comments for Jaime Bellmyer

Re: Dan Manges - Misunderstanding the Law of Demeter

Jaime Bellmyer — Thu, 25 Sep 2008 15:05:21 -0000

I was having trouble wrapping my head around the "why" to the Law of Demeter at first. I'll post my thoughts here in case they help someone else.

Bottom line: as soon as you refer to self.customer.wallet, you have forced the paperboy to know and abide by the inner workings of the customer. What if you want to change that someday? Maybe our customer wants to write a check. Heck, maybe he wants to check his wallet first, and write a check if he doesn't have the payment in cash!

Coding customer.pay(amount) means never caring how the customer will choose to pay in the future. You access the customer interface (the pay method) and go about your happy life. This code is tons more maintainable, because changing how a customer pays doesn't affect any other models that require payment.

Re: Rails 2.0 Timestamps | ruby on rails blog

Jaime Bellmyer — Thu, 05 Jun 2008 20:10:21 -0000

The timestamp columns created are actually 'created_at' and 'updated_at', both datetime fields. The suffix '_on' denotes a date field, and the suffix '_at' denotes a datetime field. Thanks for the blog!

Re: 2008/10/24/railsrumble-contest-apps/

Jaime Bellmyer — Sun, 09 Nov 2008 11:55:52 -0000

Thanks for mentioning Poolr! I was the lone Rails developer on our team, although we had an amazing graphic artist, as well as a member who did some great research and even pitched in on the CSS. I like your ideas for the site, and we'd certainly like to help manage carpools, not just play matchmaker :)

We'll be launching the fuller, production version early next year. Still looking for the best city to launch with! We're also looking to develop an office version in parallel that will be open-source, for companies to support the carpooling efforts of their employees.

Re: A critical look at the current state of Ruby testing

Jaime Bellmyer — Mon, 10 Nov 2008 21:11:00 -0000

I certainly don’t pretend to be in the same class as a lot of gurus that have added their two cents to this post. That being said, I have yet to hear the magic word, “moderation”.

Contexts don’t make you nest 10 layers deep. You do. I’d rather have the ability to nest a little, because it’s one of the things I love about Shoulda and RSpec. Same goes for one assertion per test. Alex nailed it – tests should be atomic. Test as narrow a case as possible, but use all the assertions required to ensure that test passes.

As contractors, we have a myopic view. Of course we’re stuck learning multiple frameworks. We have to be able to jump into someone else’s code, and that means maintaining a wider skill set than those who work with the same applications long term.

So if that’s part of the argument for Test::Unit, then factor it out. Because it’s not a barrier to entry to any person, team or company looking to adopt Rails. I’d say ALWAYS start with Test::Unit, because it’s the foundation before you decide you need something fancier.

Perhaps the greatest time-waster for me personally has been attempting to keep up with what we “should” be doing each week :) Maybe the great lesson in this post transcends testing: find what works, be aware of what’s new, and only adopt what improves your process.

Wow, I’m one preachy bastard.