tech

Setting up an iPad in 2012

Setting up an iPad in 2012:

My mom says that all her friends who have iPads had to go to the Apple store to get them set up. I’m not surprised. I can’t imagine how it could be otherwise.

[Sadly, I think this is a question of market. My parents are constantly frustrated by not knowing how to do things on their iPad. But I wonder whether Apple cares. Well, no, I don’t wonder, I don’t think they care. I think they’ve written them off. But the real failure here (even if I’m right about Apple ignoring the grandparent demographic) is that it also applies to people who do not share the same experiences that leads to these things feeling easy. Apple shouldn’t need to help so many get going with their iPads. No?]

Source: Scripting News

d: Personal events

For a long time now I’ve been interested in “eventing” systems. This system needs to tell another (or many) what’s going on (“Hey, I’m done processing that data”). It’s a a way of decoupling the systems so that one system isn’t “waiting” for another system.

Now think about twitter in its best case (from this perspective). A bunch of people listen to me. I send a message. And those folks can act on the message or not.

What if that sort of eventing were built into everything? What if we agreed about expected actions triggered by an event? (You event “go” and I event “where” every time I care to.)

Other folks are working on and thinking about this. I don’t always agree with the model because I think the basic interaction is far simpler. If I need a delivery service I don’t send out a bid, because it probably doesn’t matter enough to save a few cents on a single transaction. Most likely, simplicity (excellent delivery record, easy to drop off, and then reasonable cost are more likely, until I’m shipping many items.) But that’s a nit. And a lot of this can happens today, all that’s not the way the systems are thought about. And that changes everything.

Switching to NoSQL

OmniTI ~ Seeds ~ Winter ~ 2012:

It’s not that switching to NoSQL is a bad idea necessarily; there are some things that RDBMS software can’t do as well as a more dedicated solution. But, if you think that switching to NoSQL will just let you hand-wave away all of the challenges of running a database, you are terribly misguided. If you’re a DBA and you are worried about a future with NoSQL, take heart; study your product less and focus on these key architectural design points more. Those skills are critical now, and they will remain so in the future, NoSQL or not.

[Lots of good points.]

Amazon DynamoDB: First Look

Amazon DynamoDB: First Look:

NoSQL has, as a category, crossed the chasm from interesting science project to alternative data persistence mechanism. But while NoSQL tools like Cassandra and Riak are available in managed form via providers like Joyent and Heroku, DynamoDB is, in Popescu’s words: “the first managed NoSQL databases that auto-shards.”

It is also possible that SSD pricing contributed directly to the launch timing, with pricing for the drive type down to levels where the economics of a low cost shared service finally make sense.

SSDs

One underdiscussed aspect to the Dynamo launch is the underlying physical infrastructure, which consists solely of SSDs. This is likely one of the major contributing factors to the performance of the system, and in some cases will be another incentive to use Amazon’s platform as many traditional datacenters will not have equivalent SSD hardware available to them.

[A good analysis.]

Amazon DynamoDB

Amazon DynamoDB:

Amazon DynamoDB is a fully managed NoSQL database service that provides fast performance at any scale. Today’s web-based applications often encounter database scaling challenges when faced with growth in users, traffic, and data. With Amazon DynamoDB, developers scaling cloud-based applications can start small with just the capacity they need and then increase the request capacity of a given table as their app grows in popularity. Their tables can also grow without limits as their users store increasing amounts of data. Behind the scenes, Amazon DynamoDB automatically spreads the data and traffic for a table over a sufficient number of servers to meet the request capacity specified by the customer. Amazon DynamoDB offers low, predictable latencies at any scale. Customers can typically achieve average service-side in the single-digit milliseconds. Amazon DynamoDB stores data on Solid State Drives (SSDs) and replicates it synchronously across multiple AWS Availability Zones in an AWS Region to provide built-in high availability and data durability.

[Hmmm. I like some of the aspects of this… still digging’ into the details.]

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.]

iOS Multitasking in Detail

iOS Multitasking in Detail:

I received a lot of feedback on my recent post on iOS multitasking. I’m sorry I can’t respond to everyone who emailed – there were dozens. I thought it would be worthwhile to look at the process in more detail. I used Instruments (part of the Xcode package) to inspect the free memory on the iPad as I ran and suspended various apps.

If I can summarise my point: killing apps manually is fine as a troubleshooting step but it shouldn’t be part of your daily routine.

[It’s worth checking out the video he posted. ]

Source: Fraser Speirs

DOS Attacks and DNS: How to Stay Up If Your DNS Provider goes DOWN

DOS Attacks and DNS: How to Stay Up If Your DNS Provider goes DOWN » blog.easydns.org – Happenings and observations:

On the DNS side of things there are a few steps you can take to either not go down, even if your DNS provider does, or to make any impact minimal.

[Also…]

easyRoute53: Nameserver Integration and DNS Management Layer for Route53:

So we’re happy to announce easyRoute53, which is now available under beta.

All service levels support easyRoute53, even if we are just going to act as your Registrar, with no DNS hosting component here (you can then use the DNS editor to manage your Route53 data).

[Noted.]