Assimilation: A Review of iPhone 4

On my birthday, September 9, I walked into an Apple store and asked to be assimilated.

It was a truly magical event.  As I walked down the long hall of aluminum, surrounded by cheering Geniuses in their blue shirts, my heart beat furiously.  Soon, oh so soon, I would have within my possession the grail of all phones, the beautiful and sleek iPhone 4, that phone which makes all other phones seem as pale imitations of phonedom.  I approached the counter, stated my case, laid out my credentials, was judged worthy (after a slight Apple network hiccup) and proceeded out the door carrying the fabled device.  The universe was right and good, a thing of majesty and beauty.

If you've never been in an Apple store, you may scoff at this account, but I tell you, this is exactly what Apple is trying to foster in their stores.  A land of sleek industrial design which seeks to pull you, atom by atom, into a world where the coveted fruit of their hard work is your only goal, idolized and adored by you to the exclusion of all else.  They go a long way to accomplishing that goal.  Hold fast your soul should you ever tread these hallowed halls!

It's been a week since I purchased said device, so I'd like to give you my impressions.

Syncing and Upgrading

I brought my iPhone 4 to work, hooked it up to my computer and synced everything that had been on my tired and worn out iPhone 3G.  Apple has really nailed it, here.  It was a painless process.  In less than half an hour, I was holding a device that seemed identical in OS to my iPhone 3G (besides hardware differences, mind).  It was faster, sleeker, but every single piece of data had transferred.  I was almost disappointed that I wouldn't have to crawl through the depths of the device to set anything up.

Design


It is truly a sleek device.  When I got my iPhone 3G, i thought I had never seen a more beautiful piece of hardware, but the 4 makes the 3G/3GS design seem cheap and plasticy, utterly devoid of inspiration.  This glass and aluminum idol is a thing of utter beauty to behold, I have to say.  All other phones come up short, so far as I can tell, in comparison.

That's not to say that it's without flaws.  Being all glass on front and back, it makes it hard to hold.  Often when I'm talking, I feel the phone start sliding around in my hand.  I keep having to rearrange my grip to keep it from sliding out of my fingers.

I'm also extremely nervous about it, in general.  I know that the glass is hardened, but I can't help but be concerned that I'm going to shatter it.  In fact, when I went into the Apple store, the geniuses at the bar were mulling over an iPhone 4 with a shattered back.  These things can be broken, and I'm much more cautious about using this phone than I was about my 3G.  When I used to place my 3G in my pocket, I would always put the glass against my leg, hoping to protect it to some degree.  No matter how I put my iPhone 4 in my pocket, some glass is going to be exposed to the outside of my pocket.

I've also noticed some slight hairline scratches on the back of the device already.  As I've stated, I've been extremely careful with it, so that just goes to drive home the point even more:  despite hardened glass, it should be handled delicately.

I've already put my order in for my free case, and I can't wait for it to get here.  I'll feel a bit better about things when I finally have this thing at least moderately protected.  Such a shame, though, to cover up a beautiful device.

Speed


Compared to my 3G, this thing is a rocket!  There is now very little lag in the OS.  I can move between apps quickly and things like diving into the texting client take only a fraction of a second.  On the 3G, this was a particularly onerous task, taking up to a minute to fully load.  It's nice to have a usable phone again.

Antenna and Reception


I've experienced the death grip one time and one time only.  My hands were slightly damp from washing them and when I held the phone in my left hand the cell radio suddenly went into searching mode.  If I really squeeze down with the death grip (holding the phone in the left hand with the black bar on the lower left of the phone in the palm) I can see some signal attenuation, but by and large it has not been a problem.

I also experienced another issue I've never seen with my 3G.  Over a period of about 15 minutes, while driving down the road, every call I made dropped suddenly.  The person I was calling wondered just what the heck was going on, as I kept dialing and redialing them.  Whether this was due to the phone or the network, I can't say, but that never happened with my 3G.

Other than those two times, the reception has been fabulous.  Call clarity and quality are awesome.  Folks are telling me I sound better.  The noise cancelling mic is truly awesome.  This is a great phone to make calls on.

Pictures and Video


The camera on this device is amazing.  The stills it takes are phenomenal and with the addition of HDR photos in iOS 4.1 you can really get some amazing shots.  The flash also adds a new dimension lacking in the previous models.  I am starting to think that I might be able to leave my point-and-shoot behind in favor of my phone, and that's an awesome thing, indeed.

This is a silly little picture of a kids toy, but it really serves to illustrate how sharp these photos are.  This was taken with the flash.

But as good as the stills are, video is even better.  The 720p video this iPhone takes is smooth like butter.  The details are crisp and there's almost no jelly-vision, even if your hands aren't too steady when you're filming.  Add in the capability (at the premium app price of $4.99) to edit movies on the device with iMovie, and you really have an awesome deal.

Here's a movie shot with my iPhone, put together with iMovie.  It's of my son's soccer practice.  Such a simple little thing, but it really is an amazing to have done this on a phone.  (Looks like Blogger really compressed the mess out of the movie, here's the original on YouTube)

Conclusion


This is truly an awesome device.  Despite some minor complaints, it is both beautiful and functional.  I will be able to leave behind both my Flip and my point-and-shoot.  I can edit video on it and upload that video to YouTube without a problem from the device.  It's snappy and runs iOS flawlessly.  Upgrading from a previous iOS device is painless.

Truly, I can't recommend this phone more.

Double Fisting It on AT&T

I have recently had to severely analyze my motivations for which phone I will get next.  Included in this analysis were factors such as work getting me a development phone, would I stay with AT&T and would I leave the iPhone behind.

In answer to my last post, whether I would shift with the wind on which platform I wanted to commit to, the answer is both yes and no.  When I watched WWDC I became very excited about the iPhone 4.  What a gorgeous piece of hardware, and iOS has already proven to be a capable OS so I had no concerns there.  In short, there was much that was attractive to me about the iPhone 4.  Add in the capability to take slick 720p videos and edit them on-device and it seemed like a no-brainer.

Then, antennae-gate hit.  It quite literally paralyzed me where I stood.  Could it be true, the vaunted iPhone 4 was a deeply flawed device?  Would simply holding the phone render it useless as a phone?  The echo-chamber of the gadget media covered the story in excruciating detail.

As it turns out, it's not such a bad flaw, only showing up in low signal-strength areas.  Further, Apple is giving out bumpers with every iPhone 4.  The bumper mitigates the problem completely.  While I can't say that I love the thought that some high-end gadget has a design flaw which necessitates a case, the benefits of having an iPhone 4 greatly out-weigh the downsides.  Simply put, Apple has put out another superb machine for indoctrinating the masses and across the board all the pundits that have obtained one say it is a beautifully useful device.

So, with the iPhone 4 back in the mix as a viable alternative (meaning I couldn't simply dismiss iOS and switch to Android), which phone would I get.  Ironically, work and AT&T provided the answer.

Work has agreed to the necessity of development hardware and is allowing us to choose which device we would like.  We have to provide the service, should we want it, but by and large the choice of phone is ours.  The development team all agreed that Android was the way to go, as it is likely our customer will have Android phones at their disposal.

Providing the service became a bit of a sticky wicket, though.  Did I really want another device, one that could be taken away at any time, and have to provide at least $40/month in service for it (on Verizon or AT&T)?  Did I want to switch to a lower tier provider like Sprint or T-Mobile?  Heck, did I want to carry around two devices with two numbers?  All of these questions came to mind, and I researched them to death.

Turns out that Sprint and T-Mobile both have great plans which roll data into the plan.  On AT&T and Verizon, you have to pay ~$30 for data per smartphone and there is very little way around that.  However, the savings I would get on Sprint or T-Mobile weren't that much greater than what I have now.  If the answer had been that I could have my cost on my mobile bill go down $50/month, it would have been a no-brainer, but that is not the case.

Adding to the complexity is the decision I made to have both major phone OSes at my disposal.  I would like to have my hand in both Android and in iOS, with an eye towards developing in both.  This requirement ruled out Sprint, but due to rumors did not rule out Verizon.  However, the modus operandi of AT&T provided a clear-cut answer.

AT&T is a GSM carrier.  That means that the service each phone has is dependent on which SIM card is in the phone at any given time.  As long as I kept my iPhone plan/SIM, which provides data, SMS and phone service, I can switch my SIM into a different phone and still have all of that service, as well as keeping the same number.  It's a beautiful solution.  I could get both an iPhone 4 and an Android device and, depending on the necessity of the day, switch my SIM around to carry which phone I needed.

Now, I have to find the right Android device on AT&T.  A Nexus One would suffice, but I will have to go to Ebay for one of those, so I may wait around and see what percolates out in the next few months.  Regardless, I believe I will be able to carry both OSes, and this makes my geeky heart very happy.

Wherever the Wind Blows

Just recently I spent a couple of days watching the Google I/O 2010 keynotes live.  The first half of the second keynote was dedicated solely to Android 2.2 (codename Froyo, which is short for Frozen Yogurt) and man, I'm incredibly pumped about it.  Despite the fact that I don't have an Android phone, nor am I likely to get one anytime soon.

It did get me thinking, though, about whether or not I will upgrade my iPhone come June 7 when the new iPhone is released.  It certainly has put a lot of hesitation in my mind.  Some of that hesitation is due to my frustration with the iPhone.  I recently decided that I would finally take the plunge and spring for the iPhone dev kit.  I amped myself up to start writing nifty apps on the iPhone and was completely gung-ho about the whole process.

Only to find out that the only way to write apps on for the iPhone is on a Mac...  This caused me much angst.

Enter Google I/O (and some Engadget reviews about the EVO and Incredible) and the wind started to shift.  By the end of the second keynote, I was committed to being an Android convert (with the added bonus that I could leave AT&T far behind).  However, there was a question niggling in the back of my mind:  Would my lust for a new iPhone reassert itself as I avidly watch the WWDC, where Apple will launch its new iPhone?

As any good fanboy will do, I decided to seek out as much information as I could about Froyo and the current batch of devices everyone is talking about.  I turned to Mashable, Engadget and Ars, reading the same stories hashed and rehashed.  I downloaded all of the pertinent Engadget podcasts.  I devoured this info.

And, hidden in there, I found an interesting tidbit of info:  A lot of these guys which are touting Froyo as the next coming of the mobile Jesus are reluctant to release their firm grasps on their iPhones.  In fact, during the Engadget show, an audience member asked a panel of Engadget editors if they would be willing to leave behind their iPhones for an Android device.  The answer, across the board?  "No."

Here is an interesting perspective.  Has Apple done such a good job that even those that don't want to be indoctrinated are truly indoctrinated?  It's quite clear that the iPhone is the phone to beat.  This shows up whenever the latest, greatest phone is reviewed.  The question is always, is it an iPhone killer?  The answer every time so far is, "No."  In short, even though the pundits are crying out for a changing of the guard, they are unlikely to get one anytime soon.

Even though the wind is blowing towards Android right now, will it be blowing that direction in two weeks?  I actually doubt it.  Don't get me wrong, Android is a worthy platform.  I want to develop for it.  It has some many things that make it ideal for our projects (more on that in another post).  It has strengths which are only now being developed and which, when they come to fruition, will be amazing.  But, for now, in the words of Paul Miller from Engadget, "Now is the best time to wait."

So, I leave an eye to WWDC.  Will I be able to stomach another two years of AT&T and Apple (I highly doubt that Verizon will get an iPhone this time around)?  Will I find some way to secure the development environment which I so crave for iPhone OS devices?  An answer of yes to either of these two questions will indeed commit me to another tour of duty with an iPhone.

What Should be Next for Enterprise Mashups?

My friend over at JackBe, Chris Warner, recently sent me an email asking me what the next 2 to 3 years should hold for Enterprise Mashups. JackBe, in case you don't know, is the creator of the Enterprise Mashup software Presto.  We've used Presto on a project and it's a wonderfully crafted piece of software with many, many possibilities in front of it.  Presto has, at its heart, the creation of mashups, those elusive but so useful beasts which give you all kinds of new-fangled views into your data.

This is a topic I've spent a little bit of time thinking about, fancying myself to be at least a passable user and creator of mashups.  I'm going to change up the question a bit, though, and delve into territory that is slightly afield.  So, I propose these related questions:  Just what the heck are Enterprise Mashups?  And, what's next for them?

Any Ol' Programmer
Let's be honest, any programmer can get out there and create a mashup with a little elbow grease.  The technology is there such that, with a little bit of web service lifting and a little bit of UI know-how you can create fantastical mashups that will make everyone sit up and take notice.  What's more, if you do it right, your own mashup can, in turn, become a data source for someone else to consume.  It's a bit like Sir Elton John says, that whole Circle of Life thing.

But, that's just the problem, isn't it?  We're not all programmers, now, are we?  Not all of us even have access to programmers (or, as we like to style ourselves now-a-days, "software engineers"), so it's not like we can ask someone else to do it for us.  And, most important of all, programmer time is expensive.  If you do have access to a programmer and task them with spending hours creating your pet mashup, you're likely to get a whack on the wrists from the company dumby stick.  So, what use are mashups to the common-day man?  They're nice to look at, but not really practical beyond that.

Enter the Enterprise
No, not the ship, though that would be cool.  The Enterprise is (or should be) all about putting a useful tool into the hands of someone other than an engineer.  To a certain extent it's about lowering the technical barrier of entry.  Any programmer should be able to put a mashup together, but that doesn't mean that they are easy.  There is a lot of wiring together and hacking things up that takes place.

Enter the folks at JackBe, handing us Presto.  With software like Presto it's possible for someone of a less technical bent, someone that's not a programmer, to put together a mashup that's useful.  This Enterprise tool takes some of the difficulty out of the creation.  And that, in a nutshell, is what the Enterprise should be about.

What's Next?
Even though products like Presto lower the barrier of entry, there is still a long way to go.  Presto shines at doing the actual mashing, wiring the data together to get the new view.  But, one area where Enterprise Mashup software needs to tread next is into more robust presentation of that new view.

One thing that mashups excel at is the creation of data.  One thing that data desperately wants to do is be visualized.  There are so many tools out there for visualizing data, but most of them have a similar dilemma to non-enterprise mashups:  it takes specialized skills to use them.  Enterprise Mashups need to tread here, next, lowering the barrier of entry into rich presentation of the data that mashups are so good at generating.

To Infinity...
From there, well, who knows.  I'd like to see tools which are good at creating not just a good presentation but actual interaction, all done so that the common layman can create them with minimal know-how.  I've blogged before about how it's important for people like analysts to be able to do at least some kind of rudimentary software development.  I see that Enterprise Mashups can fill this role once they come to full maturity.  It's a big area, one that needs more exploration, and I'm quite happy that I get a peek into it at the ground floor.

Social Media: Capturing Knowledge in a Self-Organized Way

It's the early 80s and you sit at your terminal with a stack of papers, a document holder and a keyboard. Your mission: Enter as many of the paper forms into the terminal as possible. Exciting work, isn't it?

The problem is that this is not an inaccurate way to view data entry today. Granted, a lot of the brute force work has been done and legacy systems exist from which to pull data. Further, the forms are now entered directly into the system as opposed to copied from paper, but as regards entering novel data the situation has changed little.

The other major problem is that this type of raw entry, which is generally entering data into a form, only captures defined phenomena. The data that is being entered, especially into a form, is often classified and defined in advance. There is no elasticity to what can be captured.

This is problematic in that you must have a clear picture of what you are capturing in advance. For hard problems and complex situations you very rarely know much, if anything, in advance. If your only valid form of capturing data is via traditional predefined methods, such as forms, then your ability to capture data, and eventually knowledge, is vastly compromised.

This revelation is nothing new, of course. People have been trying to innovate data entry and knowledge capture for several decades. But, what other types of data can be captured and how?

The Army is asking this exact question, if indirectly. In reading several SBIRs the concept of capturing the knowledge inherent in soldiers heads is coming to the forefront. It is being recognized that not only do experts have valid perspectives and answers, the boots on the ground do, as well (keep in mind, this is probably not a new perspective in the military, but is one that I have seen in several SBIRs recently). Beyond that, though, they are starting to explore how to bring that knowledge into existing systems.

The how of this is a serious question. Computer systems today are clearly defined and generally purposeful to a single end. Human thought, on the other hand, is often multi-purposed and the field of understanding human thinking (philosophy) has been around for as long as humans and has yet to reach one shared conclusion on how we think. Even if we could get some Matrix-like data jack implanted into soldiers heads could we really transfer the knowledge as it is represented inside their brains into a computer system?

Perhaps we need another way of gathering data since it would seem that direct access to the human mind would avail us little. There is a new(-ish) movement which is providing an answer: social media.

Probably one of the most useful aspects of social media is how important and interesting knowledge percolates to the top. This is done in various ways. For instance, if I see an interesting tweet on Twitter, I will retweet it. If I read something worthwhile on Facebook, I may comment on it or repost it. It's this interaction with the content that causes the interesting bits to rise to the top.

The exciting thing, at least from a systems perspective, is that this is self-organizing behavior. It is through the interaction of the components of the system (here, the components are the people) that the interesting bits are being obtained. While it may be difficult to capture human thought and knowledge in its native form, it's not as difficult to capture the important pieces as they are being defined by the social system already.

Further, the nature of social media, in that it tends to interact in bite-sized, discrete pieces, means that the computer system needs not have much understanding of what it is capturing at all. The knowledge is already distilled into its core component, often with attribution, and the computer system merely need remember it. It can be stored without pre-defined labels and fields.

The thing which the computer system must crucially provide is a robust search capability. Whether this search capability is enacted after the fact, or whether there is a component of the system which searches as knowledge comes in is immaterial. As long as the system can search through the knowledge is what's important.

Eventually, this captured knowledge can be used and reused as more people interact with it. Each interaction would in essence refine the knowledge, making it more useful to the computer system and the people in general.

Git vs. SVN (I know, right, another one?!?!)

I've been endeavoring to set up a code repository (or even a document repository, if that need should arise) and have been weighing the merits of both Git and SVN.

At the very heart of the comparisons lies the manner in which Git and SVN operate. SVN is a central repository. When you "checkout" a file in SVN, you get only the most recent version. Should you need to do backwards comparisons you must communicate with the server for this. You get no history, either. SVN relies on the availability of the central repository to operate.

Git, on the other hand, is fully distributed. There is generally a "blessed repository" from which everyone will start and ultimately commit to, but when you "clone" that repository you get a full copy of it. Backing up a Git repository with many contributors is actually trivial as there are countless copies of that repository floating around.

Branching

Another major difference revolves around branching. In Git, branching is a way of life (as is the subsequent merging of branches). You want to develop a new feature? Branch on your local box and work on it there, then merge it back into your local main repository before committing back to the blessed repository.

This is not so in SVN. Branching is not done as often (nor as easily). Branching must occur in the central repository and is not a way of life. In this area Git outshines SVN.

Client Tools

One area where Git does not outshine SVN is in the client tools. SVN has been around forever (in digital terms). There are very elegant clients for SVN (such as TortoiseSVN) which allow for an incredible ease of use when working with repositories. Further, most modern IDEs have SVN repository manipulation as a core capability. There are several options for working with SVN in Eclipse, for instance, one of which is core to Eclipse itself.

Git, on the other hand, is young. The tools out there are not nearly as elegant nor are they as wide-spread. What's worse, Git is incredibly Linux centered. There are two Windows clients for Git (with the advent of JGit, that will climb to three), all of which require one to work with the command line. Some GUI projects, such as TortoiseGit, are in the works but will not be ready for prime-time for a while. The last issue here is that there is only limited integration with IDEs. With time, these situations will change, but for now it is a major draw-back to adoption by those other than the most determined.

Ease of Setup

To the end that I would like to work with both systems I decided to set up both on our Windows Server 2003 server. I chose to use Cygwin and OpenSSH, along with Gitosis (a Perl mod for Git), for Git. I used Shannon Cornish's tutorial to set things up (along with a little help from scie.nti.st on matters Gitosis). This turned out to be a rather easy and relatively painless way to go about things.

The basic gist is that you install Git when you install Cygwin then install and setup OpenSSH (by far the most difficult part). At this point you can connect to the server using SSH and clone any repository you would like. Installing Gitosis on top of things (recursively using Git, no less, which is so cool in my book) allows you to use public/private key pairs to authenticate users. You can then use Git to clone the control repository of Gitosis and admin the system remotely. Very elegant and one which doesn't require the anticipated user to have to input a password or create an account on the server.

Setting up SVN was more difficult. The differences, though, are myriad. While the above Git scheme works on SSH the method I chose to use for SVN works over HTTP/HTTPS, which has advantages all of its own. I worked off of several tutorials, but the most significant was this tutorial.

The real difficult part here is that you have to rely on Apache. It seems a bit overkill to have to install Apache and get it running in order to serve up your repository, but this is the accepted way of doing things. Once you have it running you must still log into the server to create a username/password combo for any user that wants to use the system, and you must also log in to the server in order to administer the repository.

The Best of Both Worlds

I have to say that the thing which gets me most excited about Git is the notion of branching it carries with it. I really like the thought of creating a local branch for every new feature. It seems natural to me.

On the other hand, I don't think that I want to saddle everyone else around me with command line tools and vi if they want to work with our repositories. So, can a compromise be made?

In fact, it can! Git has the wonderful ability to clone and commit to SVN repositories. The real details are outlined here by Clinton R. Nixon. In this way, I can take the pain of the command line on myself without foisting it on anyone else, but I also get all of the wonderful features Git brings with it.

Conclusion

In light of all of this, we will be hosting our repositories using SVN. However, I will be keeping an eye towards the maturity of the Git clients. If they should ever advance to the level where any "power user" can attain them, then we very well might switch.

A Thought on Environments: Portability

My friend asked me yesterday what I thought of the Kindle. My response was that I was a fan of actually holding a book, feeling the paper, reading in a full fidelity mode. I spoke of how tired my eyes could become from reading on a screen all day. I made a decent case for not adopting the Kindle.

Then, on a whim, I checked out the Kindle app for the iPhone and immediately found myself sucked in.

The first thing that did it was the free availability of a book that we have all been discussing here at the office, Bertrand Russell's "The Problems of Philosophy". Turns out that it is a "classic" and Amazon offers many of the classics for free. I have now downloaded 10 free classics for my iPhone Kindle app and am well on my way to finding book reading Nirvana.

Free content put the hook in my mouth, but what set it was the concept of WhisperSync. WhisperSync is a service that Amazon offers which will sync your content between devices. Now, this is not just the raw content, this is the detailed content, the state content.

For instance, let's say that I am on page 50 of "The Problems of Philosophy" on my iPhone. Further, let us say that I have a Kindle at home on which I do the bulk of my reading. As I read on the iPhone, the Kindle app updates the state for that book. When I get home and fire up my (physical) Kindle my place in the book comes right up (in computer terms, the state is restored). No futzing around with finding my place, everything is just magically the same.

This got me thinking about the synchronicity of environments. In our research the environment you work in is of paramount importance. That environment can be unique to you, or you can share it with others. Everyone can have their own, if necessary. The environment is at least partially reflected in software.

One thing Dr. Sousa-Poza and I talk about a lot is the ability to "save" environments. Environments should be transportable and shareable. If you need to see what I see then you should be able to load up a copy of my environment, see things just as I see them with the data I've been using. What's more, your environment should be able to subsume my environment! Environments should be nestable yet discrete.

WhisperSync brings an interesting possibility to my mind. Shouldn't the environmental changes that I enact on one device translate to another device? What if I access my environment from my iPhone and then switch to my laptop or a web browser? Shouldn't the environment be exactly the same?

This necessitates two things: A place of storage (centralized or decentralized, makes no difference) that all environments have in common and the ability to capture state.

Ideally, the system would operate like this (from the 10,000 foot view):

1. I access my environment and make some change to its state.
   
2. That change is transmitted to the "server" which keeps track of environment state. ("server" is in quotations as a means to capture an idea. It need not be an actual server. It might be better to think of it as a state oracle)
   
3. I switch to a different device.
   
4. As I start up my environment on the new device the state is restored from the "server".
   
5. I continue my work.

Such a system would be truly powerful from a portability standpoint. I could do my work wherever I needed to be and have that work mirrored wherever I go. I could work from multiple devices and not lose a thing.