Thoughts from an iPad

Ronnie Evans:

When initially hearing Oliver Tank’s music it’s easy to picture him as a suave, posh gentleman who spends his days strolling the beaches of Sydney in a white tuxedo, flocks of ladies fighting to stand in his shadow. On the contrary, what you’ll discover is a young college student who divides his time partying, hanging with mates and making records in his bedroom. His lifestyle is unbelievably laid back, and both his lackadaisical attitude and style of living are paralleled in his music.

As a follow up to my previous post on Oliver Tank, this article provides some great insight to his lifestyle and the ambience surrounding his music.

His music, as he calls it, is comprised of “fairly accessible tracks in terms of listening to them, but disguised with more unusual instrumentation.” His ultimate goal is to make something original, yet not so far off that people can’t relate to it while also maintaining a personal interest in the product. His EP, Dreams, garners an almost overwhelming sense of introspective seclusion, achieving Oliver’s goal of originality while striking to the core of each listener’s either subconscious or as in most cases — uncomfortably vivid emotions. […] There is a feeling of calm that loiters in the shadows of the album, meandering in and out of each track with a subtle ambivalence. Built around chimerical harmonies, gentle beats and a shockingly refreshing use of auto tune, the EP manages to shout complexity while delivering itself with a marvelous simplicity

Just like last time: I couldn’t have said it better myself. I can’t wait for what he comes up with next.

There’s a fine line between originality and accessibility. The key is too get as close to that line as possible, but never cross it.

The runner discovers tranquility on the road, forgetting the pain. The writer gives in to the joy of playing with words, moving past the aggravation. The entrepreneur finds purpose in making something, and stops noticing the long days.

You can spend your life fretting about how healthy, interesting, or successful you are. In fact, a whole industry depends upon this, and is eager to help you make plans to change.

On the other hand, you might consider simply finding what you love, and letting the rest take care of itself.

Whisper words of wisdom, let it be.

John Gruber:

Maybe the answer to the iOS address book situation is to require the user to grant explicit permission through a dialog box, but it’s not a slam-dunk decision. Every dialog box has a cost.

That’s one answer, sure. But I think you’re solving the wrong problem. I think theres an inherit flaw in how all of the APIs come together and the assumptions developers are allowed to make when it comes to privacy.

Marco:

When implementing these features, I felt like iOS had given me far too much access to Address Book without forcing a user prompt. It felt a bit dirty. Even though I was only accessing the data when a customer explicitly asked me to, I wanted to look at only what I needed to and get out of there as quickly as possible. I never even considered storing the data server-side or looking at more than I needed to.

When I had to access the address book I felt the exact same way. Most users, however, don’t care. Going back to Apple’s basic concept: it just works. Location, unlike address book, is time-sensative. There is a specific time associated with the location. Depending on how wide of a span worth of data you have, the creepier you can be (e.g. calculating speed, possible routes, destinations, etc). He goes on:

But Apple can, and should, assure users that no app can read their contact data without their knowledge and explicit permission. I don’t know why this hasn’t always been required, but it probably isn’t a good enough reason to justify the erosion of user trust in iOS apps that this could cause.

Come on. I’ll meet you half way: give users an option to decide this on an app-by-app basis, but not by default. A little toggle in Settings.app to lock down the address book with a bunch of on/off toggles for each app that pop-open below.

And he goes on:

Apple needs to change the Address Book API to require user permission first, like Core Location and Push Notifications do. I don’t care how many applications break as a result.

Consider this from a development perspective, oh mighty developer. Every application that uses a single ABAddressBookRef or any related function breaks. Except wait, they linked to AddressBook framework. So when AddressBook framework can’t talk to Apple’s hooks, AddressBook framework causes your app to crash. The only way to see this is to update your dev tools and realize none of the function hooks exist anymore. Or maybe they do exist, but Apple is blocking the thread so that it can popup the UI alert. The only way this is possible is to deprecate AddressBook framework as is, for the whole course of iOS 5.1, or even iOS 6. And provide the new alternative as the “go to” method. In iOS 7, they can finally remove it. Alright, sounds good. 2 years later.

John Gruber:

It’s always shocking when you actually run out of battery on the iPad.

He goes on to say that even when you get the 20% warning, it’s not as much a warning as a friendly heads up. Something like this might affect you in the future.

I couldn’t agree more. When I use my iPad it shocks me how long it can last before I need to plug it in. It’s really amazing, too. I notice I usually plug my iPad in every other time I plug my iPhone in. And I plug my iPhone in maybe every other day. So with that logic, my iPad can last around 4 days, sometimes 5, depending on usage. I always cycle my batteries – I’ll never leave a device plugged in overnight, with the exception of calibrations (such as the first charge, etc).

He goes on to talk about his previous assessment of LTE. Again, I agree completely agree with his reasoning. Why else is there no iPhone-size Android device with LTE? I think the LTE chips are too big, which is why Android phones are so big, and their battery life is horrible.

Performing manual, repetitive tasks enrages me. I used to think this was a corollary of being a programmer, but I’ve come to suspect (or hope) that this behaviour is inherent in being human.

I couldn’t agree more. It’s human nature to do things as easy as possible. In the case of a developer, you have one more huge tool in your toolbox, and repetitive tasks on computers are the worst kind of repetitive tasks. My advice: automate the shit out of everything.

It already starts with the teaching of arithmetic. Instead of teaching 2 + 3 = 5 , the hideous arithmetic operator “plus” is carefully disguised by calling it “and”, and the little kids are given lots of familiar examples first, with clearly visible such as apples and pears, which are in, in contrast to equally countable objects such as percentages and electrons, which are out. […] The educational dogma seems to be that everything is fine as long as the student does not notice that he is learning something really new; more often than not, the student’s impression is indeed correct.

(Emphasis mine)

It’s hard to say whether this is a problem, or a solution. I think we’re not introducing these topics (such as calculus) early enough, and therefore when they are introduced, say during your senior year, they seem almost scary. We’re giving students an impression that these topics are super hard, when in fact something like a limit is a fairly simple concept.

So is the problem that we’re trying to relate it to something we already know, or that we’re building it up to be more difficult than it is? I might argue both.

Some more interesting quotes from this link:

If we push a little harder we expect to do a little better. Very often the behaviour is not only a continuous but even a monotonic function: to test whether a hammer suits us over a certain range of nails, we try it out on the smallest and largest nails of the range, and if the outcomes of those two experiments are positive, we are perfectly willing to believe that the hammer will suit us for all nails in between.

It is possible, and even tempting, to view a program as an abstract mechanism, as a device of some sort. To do so, however, is highly dangerous: the analogy is too shallow because a program is, as a mechanism, totally different from all the familiar analogue devices we grew up with.

In what we denote as “primitive societies”, the superstition that knowing someone’s true name gives you magic power over him is not unusual. We are hardly less primitive: why do we persist here in answering the telephone with the most unhelpful “hello” instead of our name?

Unfathomed misunderstanding is further revealed by the term “software maintenance”, as a result of which many people continue to believe that programs —and even programming languages themselves— are subject to wear and tear. Your car needs maintenance too, doesn’t it? Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs “because PASCAL was not maintained”.

When all is said and done, the only thing computers can do for us is to manipulate symbols and produce results of such manipulations.

After all, it is no longer the purpose of programs to instruct our machines; these days, it is the purpose of machines to execute our programs.

Computing science is —and will always be— concerned with the interplay between mechanized and human symbol manipulation, usually referred to as “computing” and “programming” respectively.

No endeavour is respectable these days without a TLA (= Three-Letter Acronym), I propose that we adopt for computing science FMI (= Formal Methods Initiative), and, to be on the safe side, we had better follow the shining examples of our leaders and make a Trade Mark of it.

Amazes me that people will actually spot these subtle differences in the first place, assuming they didn’t get a special tip-off.

Well to be fair, they probably did get a tip-off. Either that or the person who mentions it designed it.

The only logical reason for you to take my knife from me is that you think I’m a terrorist. You’ll smile and shake your head at the dopey terrorist, and you’ll go tsk tsk, and then you’ll let me through to board my flight.

So, TSA, answer me this: why are you allowing suspected terrorists onto planes?

The problem with this is that you’ll never get your answer. I actually just wrote a paper about this in my current issues class. The TSA is one of America’s many security theaters. Perceived security, to make us feel safe. Because that’s all that really matters.

However, consider that someone who was a terrorist stole that knife from you. Then he is able to get on the flight without any issues, and maybe cause an even bigger panic than before. Food for thought.

Big problems are problems for a reason – they are problems that are hard to solve. If there was an easy solution, one of the thousands of ambitious, smart engineers out there would have solved them by now. So instead of solving big problems, the smartest, most creative brains in Silicon Valley are building apps to help us organize group lunches, share funny photos, or aggregate daily deals. I’m sorry, but these aren’t the big problems. In fact, most of these new startups are creating more problems than they solve.

Maybe the problem is that they can’t tolerate big problems, they can’t bother working on them. They want to be ignorant of the existence and play with cute scripts that create new problems. But don’t worry, I’m just sure someone else will solve them.

One of the examples brought up is dealing with medical records and how every time you go see a doctor you spend 30 minutes filling out the same paperwork. Luckily some startups are working on these “big problems”. I think they’re on the right track, too.