Disqus - Latest Comments for Scott Becker

Re: And one hour later, I got an iPhone

Scott Becker — Mon, 16 Jul 2007 00:52:29 -0000

Yep, the integration and sync with the Mac is super sweet. How could you not be sold? :)

Re: Damn luck! Do it with the ADS Podcast.

Scott Becker — Mon, 29 Oct 2007 14:29:25 -0000

Subscribed!

Re: Adobe PR’s greatest nightmare…

Scott Becker — Sun, 17 Jun 2007 19:07:42 -0000

If the answer was simply "No," that would be one thing. But saying "I can't talk about that," when it comes to Apple, most likely means - yes, but we're going to delay gratification and let the hope and anticipation build to fever pitch. Even with a little thing like Flash.

Delayed announcements and secrecy is part of the Apple mystique. They simply understand the human emotion of material want. The status of an object for the period of time when you desire it and can't yet have it is as good or better as once you actually own it.

Leaving some of the details fuzzy lets it be up to the customer's imagination - where they will invent in their mind the greatest product ever invented.

And unlike other companies who can't help bragging about unfinished goods, Apple has discipline.

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

Scott Becker — Thu, 13 Nov 2008 14:17:00 -0000

@Dan – “We need to stop making new libraries and new tools.”

Yeah! Lets get back to Java, or ASP, or COBOL. It worked well enough! ....umm, what?!

I get what you mean, you don’t want to have to keep learning new tools. But then why even go through the effort of learning Ruby or Rails, or etc etc. At some point you had to stop going down the previously comfortable road and learn those.

For me, BDD has obvious benefits. Clarity of intent. Readability. This speeds up maintenance down the road.

As to one-assertion-per-test (or spec), thats just a design goal, not a requirement. But I’ve seen what packing multiple assertions into one test looks like, and it ain’t pretty. You get assertions that have nothing to do with the name of the test, and later on you come back and wonder why, but too bad, because you can’t go back and ask either yourself or your co-worker or whomever it was what they were thinking 6 months ago. Make your test do one granular thing, and you can easily understand why. Especially if you write the test first. This is do-able in Test::Unit, but I think the nested contexts make this a lot easier and more DRY.

Good post though, it’s good to occasionally step back and consider why.