Haseman on Mobile

Over at DaringFireball.net, John Gruber has written an exciting two-part Call-To-Arms to the Android platform.  He contends, and I would agree, that there are a large number of disgruntled iPhone users out there, longing for an unlocked, tightly designed, badass mobile platform.  While we both see a possible way for Android to compete with the iPhone, we, sadly, differ on its chances to overtake it.  I say this with a lot of sadness, as I would love to sell many more copies of my book.

Who’s your daddy?

One of the truly sad things about technology is its lack of idealism.  While there are teeming throngs that have worked countless hours to make Linux the wup-ass system it is today, the sad fact is, that while powerful, it is still a second rate consumer product.  I say this with all due respect, as I run Ubuntu on one of my laptops but, let’s be honest here, it’s no OS X. (Please send all ‘Linux is teh awesome, you suck’ hate-mails directly to the trash folder of my email address, thanks)  The real question, in this case, becomes, can Android be less like Linux and more like Windows?  The answer, and I look forward to being really wrong about this, is No.  It isn’t, and it can’t be windows.  Why?  Because Google isn’t making any money from it.  Sure, they use it to drive their web-services platform, but they lack the hunger, drive, and downright evilness of a Microsoft, Sun, and especially Apple.  In the end, their problem lies, not in their stunning technical ability, but in their attitude.

What Hardware?

I’m not sure if you’ve picked up a G1, or a myTouch, but, to be blunt, they suck.  The myTouch is very much an improvement, but not enough of one.  The problem with the hardware is twofold.  First, the margins on cell phone design and management are so narrow and the technical turnover so high that no one has an incentive to produce an amazing design.  I’ll give you an example: aside from the iPhone, when was the last time people were actually excited about a phone hardware design?  The RAZR, (curse their stupid lack of vowels) and look what happened to Motorola when they tried to bank on the design.  Further, even if you put together a badass looking Android phone, the fact remains that 1 in 3 handsets never see the light of day.
The obstacles start to pile up when you think about it.

1) Design turnover is high (50% of Americans replace their phone each year)
2) Designing a phone is EXPENSIVE.  Further, millions of dollars must be spent in debugging and building software for each device. (I know this one from personal experience, I’ve done it)
3) 2/3’s of your designs never see the light of day.
4) Assuming a phone makes it to market, you have to sell several million of them to cover all the money lost on your previous attempts.

These are the obstacles that Samsung, LG, Moto, and everyone else have to content with on a regular basis.  What does this lead to?  A field that requires mediocrity.  You must design for the least common denominator, cut corners, and employ the cheapest programmers you can find.  Every time I think about it, it amazes me that there are any actual mobile phones at all.

Yea, well what about Apple?

“Alright Dr. Downer-Pants”, you say, “how the hell does apple pull all this off then?”
Good question.
First, Apple makes it work because they control everything.  The operating system is hacked by people who sit next to the guys making the hardware.  Normally, if you’re writing software and you have a question about the hardware, it takes between a week to two weeks to answer your question.  Further, apple requires no other company, aside from the FCC and AT&T to approve of their platform.  Any other company has to run the gauntlet of intergration with any number of 3rd party developers.  These are hurdles that Apple doesn’t have to jump, so their costs, time to market, and drag on innovation is all insanely compressed.
Second, Apple has the marketing power of an entire first world country.  For Gods sake, reading the press releases after the first iPhone was announced you’d think the Lord himself had ridden against a plague of nazi zombies on the Rapta-dactle of doom.
Third, these things (well, mostly the second) allow Apple an unprecedented amount of leverage over AT&T and any other carrier they want to work with.  This allows them to require massive subsidies and back-payments.

So it’s Hopeless?

Of course not.  Android, really, needs only one killer hardware design to take off.  The question really becomes, who’s going to push for it and how?  Every manufacturer under the sun is pushing out their own Android devices.  If Motorola can see half the success they achieved with the Razr, it would, I think, present a quantum leap for the industry.  Which, as every other technical talking head will remind us, what’s good for Android is good, competition wise, for iPhone users as well.

In the end, making a device that can compete with the iPhone is, for the reasons I’ve outlined above, almost impossible.  However, it only has to happen once.

My latest article over at devX.com

any good programmer knows that the best time to enter a market is before a killer application makes its debut, rather than when the market is already proven. With that in mind, DevX will publish a two-article series to set you on the path to building your own Augmented Reality engine on Android. Building an AR application requires a dash of math and four technological pieces. This first article covers the first two pieces: the camera and the compass; the next article will cover the other two: the accelerometer and GPS.

Link

Many column inches have been devoted to defining the ‘good’ programmer.  We programmers read such stuff because we’re all paranoid that we fall under the ‘bad’ or ’stupid’ programmer.  We all, if we read up on the art of making software, like to think of ourselves as members of the elite few.  I have a news flash for you: you’re probably not. (but then, neither am I)

You cannot define what a ‘good’ programmer is without first examining the environment in which this programmer will be producing code.

Just as different martial arts have advantages and disadvantages based on the battlefield, programmers, given a set of skills and abilities, will have an environment in which they will excel.  The art of finding ‘rockstar’ programmers is less about tricky math problems (above a certain point) and more about matching their particular quirks (we all have them) with an environment that allows them produce.

For the sake of expediency, I’ll break down programmers into Cooks and Bakers.  This is absolutely an arbitrary distinction.  There are more interesting ways to bisect the programming world, but this one makes for a quick explanation.

Cooks are the creative ones.  They enjoy the big pictures, they like putting things together (especially in the early stages).  They struggle to remember small minute details like thread timing and tend towards simple, crippling, off-by-one-type errors.  Give them a blank page and they’re make you a mural…just don’t expect every building to be exactly to scale.  In the later stages of a project, they make for amazing problem solvers but will often cause more bugs on the way to a solution.  Cooks, sadly, are the most common type of programmer out there. (I say ’sadly’ because I’m a cook more than a baker)

Bakers, on the other hand, revel in the details.  Give them a comprehensive specification and they’ll be a hog in a manure farm.  They often miss the big picture, frequently say ‘but that’s not in the spec’ and often struggle with the blank page.  They hardly ever make mistakes of omission but the mistakes that they do make tend to be large in scale an very difficult to fix.  Hard core bakers are rare, which is good as they often fight with each-other.  But at any successful company you’ll always find one.

You wouldn’t wear Japanese samurai armor to fight trench warfare.  In the same way,  you shouldn’t ask engineers to work exclusively with what they’re bad at.

There’s more than style to consider.  If you’re a contractor and you’re working on a project you won’t have to maintain, there’s no incentive to write clean ledge-able, extensible code.  On the flip side, if you’re on salary, you work on long lived libraries or applications you better be or work with a baker.

With this in mind, I would offer the following hypothesis:

A ‘good’ programmer has two traits, which, interestingly enough, haven’t anything to do with the ability to bang out code:

1) They can communicate.  They build trust, hit their deadlines (or give you plenty of warning when one will be missed) and don’t hide their shortcomings.

2) They are adaptable.  They may have a preferred working style and project type, but they’re willing to work outside their comfort zone.  They know the rules, but, when the situation calls for it, they abandon them with alacrity.

That’s it.  If, in defining what makes a great programmer, you list a series of programming habits and skills, you’re only defining a programmer who works well in a particular environment.  I’ve seen programmers blow a simple linked list reversal in an interview and then turn around upon being hired and blow my mind.

Building a good team is less about complex logic problems and obscure programming knowledge and more about building a group of people that complement each other.  When you interview your next potential teammate, make them write some code, and then take the time to figure out how they work.

First, let me say, thanks to everyone that helped out or swung by to chat with us during iPhone Dev Camp.  It was a pleasure to meet all of you, and if you email me I promise I’ll get back to you as soon as I can.

Let me now address the burning question of: “What the hell are you guys doing?”

The answer, at least right now, is writing this blog and trying to keep up with our day-jobs.  But that’s now what you care about.

The iPhone ARKit

Our long term plan is to make ARKit as similar to MapKit as we can get away with.  You should be able to pass it a list of geographic points and it’ll call back out to you for instructions on how to draw the view.  Our library will handle, based on the location of the objects you specify, using CLLocation objects, where on the screen the view should be drawn on any given paint loop.

Further, we hope that, someday, we’ll be able to draw a MapKit view when the phone is parallel to the ground, and the ARKit view when the device is held up in the air.  This will, of course, be a feature that can be turned on and off from the outside.

For now, we’re jamming on fitting the package into what resembles a MapKit API.  We would LOVE to have help going forward, but right now, at least while we get things organized, we’d appreciate it if you gave us a few days to catch our breath.  The app was a pretty heavy hack-job for the demo, however, if you absolutely must start working on your ARKit powered application _right now_ I’d suggest building it as a MapKit application and then sucking in our API when it’s in good shape.

Please feel free to mail me if you have questions.  My address is: haseman [at] wanderingOak dot net.

What a weekend.

Wednesday of last week I turned to my co-worker Zac White and asked if he’d thought about a project for us to do over the course of iPhone Dev Camp.  When he paused for just a little too long I made a suggestion.

“Let’s make an Augmented Reality library and give it away.”

We tossed around a few other ideas, but in the end, we settled on what would later be called the iPhone ARKit.  Or, if you parse the text in your head  like I do, “iPhon Ear Kit”

As we piled into my car to drive down on Friday night we started laying down the design and architecture for our library.  It would be powered by ponies, cure cancer, and feature a trebuchet that could launch a medium sized grapefruit into low orbit.  We would later revise our specification to include launching a watermelon.

I’d love to say that Friday night, immediately on arrival, was when the kit got started, but Friday was a time to drink, talk to people who are smarter than I am, listen to BT fiddle with his laptop on stage for an hour, and drive home.  So really, Friday was a chance for us to create the XCode project…and for me to remember that Objective C was designed by space aliens who hate us C/C++/Java people. (I’m learning, cut me some slack)

Saturday was when things actually started to take shape.  We’d decided we would approach the problem from two sides.  Zac would take the harder job of building the ARViewController, the object that renders the X/Y of an array of views given the Spherical coordinates of Distance, Bearing, and Inclination.  I, on the other hand, would write the code to convert Latitude and Longitude points into the aforementioned spherical system.   Luckily for me, a little work with Google provided most of the pseudo code I would need to get my piece working and a little debugging got me the rest of the way.

Just before lunch on Saturday, Christopher Allen announced, from the stage, “There is a team here somewhere who’s working on a library for Augmented reality…” I lept from my chair and yelled…and nearly before I could sit back down we’d picked up Charles.  Charles had enough energy for 3 people and helped out with just about everything.  Soon thereafter we picked up Sid. Sid seemed to have a magical knack for running his video camera at the right time…much to my chagrin (as you’ll see later) and had experience in finding homes for open source projects.

As our team came together it became excruciatingly clear just how excited everyone at the conference about the prospect of an Augmented Reality toolkit.  I say excruciating, because as time passed my role morphed from engineer and task-master to defensive lineman.  Person after person would swing by our table and ask ‘are you the AR guys?’  At which point I’d leap from my seat, before they could distract anyone else, and have a really interesting conversation about how they wanted to eventually use the library we would be making.

It was during this time that I think I really got iPhone Dev Camp’d.  It was filled with busy, helpful, smart people who want nothing more than to make millions of dollars for Steve Jobs…..*cough* I mean contribute an interesting application to the world at large.  Joking aside, I met a tremendous number of interesting people over the course of the weekend.  My wallet is still full of their business cards and I’m afraid I have no idea who’s face goes with who’s card.  Sorry everyone!

It was also during this time that we picked up our clean-up hitters, Arshad and Kevin.  Arshad had the second most Obj-C experience amongst us and the two of them would come to provide the demo application that made our presentation as wupass as it was.

Lunch came and went and as it got dark I started getting a little worried…I was still struggling with the geographic calculations and Zac was still trying to normalize his accelerometer data.  It was then, encouraged by Charles, that I disregarded the instinct that every engineer has and asked for directions.

Taking the stage I mumbled/shouted (something that defies the laws of physics unless you have a microphone): “Uhm…Hey, I’m Chris with the AR team, it uh…turns out that math is hard and we’re not very good at it.  Are there any math or 3d graphics guys out there that could give us a hand?”

Two of them were at the table before I got back.  With their help Zac got his sensor data behaving itself and I sorted through my problem with the bearing calculations (it turned out to be a problem importing the .c file I’d written the helper functions in) a few hours later and we had a Working Demo! (I don’t have a video of it, but here’s what we had running Sunday afternoon)

We had SOMETHING to show, and it was then that the project looked like it was actually going to work.  There was still a lot to do, but we were most of the way to something……. it wasn’t watermelons in space…but it was almost as cool.

Saturday night was a chance for Zac to pull in my helper functions and for me to look up the lat/lon locations for all the iPhone dev camp satellites.  (there were a lot) and go to bed.

Sunday Sunday Sunday!  We cleaned up, added the geo-location information, debugged some angle calculation problems and fretted about how the presentation would go.  Just as I was putting the last touches on the Keynote slides, Arshad piped up, “I think I can show this ghost thing during your demo if you want!” At which point he and Zac bent over and they cranked out all the remaining X-Y translation problems with a little “EXTREME” pair programming.

With that, it was time to give our demo.  I overcame my jitters and we stumbled up on stage to give a talk which was twittered by Robert Scoble thusly: “Cool iPhone augmented reality toolkit just demoed to cheers.”

Here’s a link to a video from the stage

One hour, and many twitter messages later….the winners were announced.  We’d taken the award for Best Open Source application.

While I hate watching videos of myself, Sid, bless his cotton socks, made a 10 minute documentary about us that you can find here …

That, was what happened, this one time at iPhone Dev Camp.