Day: January 14, 2012

Can I ask Siri if any alarms will ring in the next two hours?

[The short answer is no, at least for now. It’s not as simple as looking at your schedule, because you can set reminders to ring hours or days before an event. It needs to be calculated. Siri could be given the power to do this and would make it easy to know if you should shut off your phone during a performance, or just mute it or add a “Siri, mute alarms for the next three hours.” command.]

★ On the Behavior of the iPhone Mute Switch:

Daniel J. Wakin, reporting for the NYT:

The unmistakably jarring sound of an iPhone marimba ring
interrupted the soft and spiritual final measures of Mahler’s
Symphony No. 9 at the New York Philharmonic on Tuesday night. The
conductor, Alan Gilbert, did something almost unheard-of in a
concert hall: He stopped the performance. But the ringing kept on
going, prompting increasingly angry shouts in the audience
directed at the malefactor.

[Snippage -Ed]

I think the current behavior of the iPhone mute switch is correct. You can’t design around every single edge case, and a new iPhone user who makes the reasonable but mistaken assumption that the mute switch silences everything, with an alarm set that he wasn’t aware of, and who is sitting in the front row of the New York Philharmonic when the accidental alarm goes off, is a pretty good example of an edge case.

Whereas if the mute switch silenced everything, there’d be thousands of people oversleeping every single day because they went to bed the night before unaware that the phone was still in silent mode.

[Part of the problem here was that the marimba sound was apparently the culprit which would cause a lot of performers and conductors to pull up short. But also, while I agree that the phone does the right thing (tricky though that is) it makes me wonder how many people know that the alarms are not silenced when you mute the phone? I’d bet a lot.

Plus check this:

If this is not possible, you’ll want to set the ringer to mute, set the system audio to zero, launch Siri and lower the volume to zero, disable all alarms, and review the Settings > Notifications items in the Notification Center to switch off audio. There’s probably some items Auntie is missing here, but she trusts her nieces and nephews will refine this list in the comments.

[snippage -Ed.]

For those rare occasions where you really need to bypass these design choices, powering the iPhone down will keep it from embarrassing faux pas.

A suggestion I can get behind.]

Source: Daring Fireball

Your tests are lying to you

Your tests are lying to you:

Well designed code is easy to test. As a rule of thumb, anytime I get over about two or three lines of setup code for testing a method, I normally take a step back and ask myself if this method is doing too much.

Test speed

The other advantage of running tests purely in isolation is that they’re fast. Very fast. When I’m coding Rails apps these days, thanks to advice from Corey Haines I’m running a spec_no_rails folder which runs independently from the rest of my Rails app. Rails apps by default epitomise this problem: default model tests exercise the whole system from the database up. By running your tests independently you’re not having to clean the database or start Rails each time you run your tests, which means that much of your interesting code can be tested in under a second. Gary Bernhardt has more information on how to set this up in his excellent Destroy All Software screencast series.

[One thing not mentioned here is a pet peeve of mine. I see a lot of tests where the dev is testing implementation rather than input and outputs. To me, checking how something was implemented is not relevant. That the method returns the expected results for a given input is. “Implementation tests” also causes a great deal of test rewrite when refactoring.]