Greg Crisp

Every iPad and iPhone has a unique identifier, or UDID (Unique Device IDentifier), a 40 character string that is hard-coded to each, individual device.

It looks something like this:

a004e3409a473b2034d899d246...

Since the early days of iPhone development, it’s been common practice for developers to use the UDID to associate devices with end-users, and for use in analytics, security, etc.

In the latest, major release of the iOS SDK (5.0), Apple has deprecated the API call an app uses to get the UDID from the system ( [UIDevice currentDevice].uniqueIdentifier ).

From The Wikipedia:
Deprecation – “In the process of authoring computer software, its standards or documentation, or other technical standards, deprecation is a status applied to features, characteristics, or practices to indicate that they should be avoided, typically because they have been superseded.”

Unlike some other vendors, Apple tends to promptly remove deprecated APIs from their SDKs, so it’s a good idea to move your app off of them quickly lest it break in a future iOS update.

Recently, Apple has started rejecting apps that access the UDID call:

- (NSString *)appUniqueId
{
  static NSString * const APP_UNIQUE_ID_USERDEFAULTS_KEY = @"AppUniqueIdUserdefaultsKey";

  // Do we already have a unique id for this app?...
  NSString *uniqueId = [[NSUserDefaults standardUserDefaults] objectForKey:APP_UNIQUE_ID_USERDEFAULTS_KEY];

  // ... if not, create it...
  if( uniqueId == nil )
  {
    CFUUIDRef uuidRef = CFUUIDCreate(kCFAllocatorDefault);
    uniqueId = (NSString *)CFUUIDCreateString(kCFAllocatorDefault,uuidRef);
    CFRelease(uuidRef);
    [[NSUserDefaults standardUserDefaults] setObject:uniqueId forKey:APP_UNIQUE_ID_USERDEFAULTS_KEY];
    [[NSUserDefaults standardUserDefaults] synchronize];
    [uniqueId autorelease];
  }

  return uniqueId;
}

Unlike the UDID, the app-specific unique identifier will reset if the app is ever deleted and re-installed on the device, so if you’re app relies on the same identifier for security, you’ll have to account for this case.

Enjoy!

Here’s a test: Take 12 random stills distributed evenly across the span of a movie and give them to someone in a random order. Ask that person to sort them based on their sequence in the movie.

Whether or not someone puts them together in the correct order is essentially random.

Unless… that person has seen some or all of that movie before.

Wireframes:

• High-level user interface designs for a proposed software product.
• Potentially, though not necessarily, sequentially-oriented screen shots of specific parts of a computer system.
• Marketing material

This is the same for software development. Give a software developer some wireframes with maybe a day to review them, plus about 1.5 hours of overview of the material by someone who helped create it. Throw in a rapidly produced requirements specification for good measure. It is likely you will at this point assume a great deal of knowledge on the part of the developer, and expect them to deliver a high-quality product in a predictable time frame.

This seems to be the management practice common today in software production, and it results in problems.

An example of a brick layer seems useful:

A brick layer of any experience will be able to give you a predictable estimate for building a wall, given the length, width, and the height of the proposed wall. It’s a linear problem, and the experienced brick layer has built many a brick wall before in his career.

A software developer can also be highly predictable, provided they’ve done enough of this type of project before. If you come to them with a project with typical requirements for bit-plumbing, that project requires a known technology stack (E.g. Apache, Tomcat, Java, MySql, Hibernate, Spring, and/or Struts), you have the data model largely done, and you know all the use cases, she can probably give you a fairly predictable estimate.

However… throw in requirements to use proprietary and poorly documented frameworks or components, restrict the use of well known technologies, have poorly specified or incomplete user stories, structure your build environment in such a way that builds are slow, long, and recur often, and your project’s predictably drops towards zero.

Worse still, give an inexperienced, junior developer primary responsibility for significant architectural or design decisions. They just haven’t made enough mistakes or had enough decisions blow up in their faces to recognize the bad ones.

“Recognition (re+cognition) is a process that occurs in thinking when some event, process, pattern, or object recurs.” – from The Wikipedia

Prescience: The ability to see and predict the future.

It’s common sense. Prescience is about recognizing patterns and altering your behavior to flow with them. Recognition requires recurrence, and something must occur before it can recur. You have to have experienced the occurrence in order to recognize the recurrence, and the act accordingly to achieve the outcome you desire.

Experience in the business of executing software projects created a higher degree of reliability in estimates and success. Lack of experience produces the opposite.

The kung fu disciple to his master:

“What is the meaning of it all?”

The Master strokes his long, white beard and responds:

“Who cares? There may be no meaning in any form we can comprehend. What we seek to understand is not the meaning of existence, but its nature.

“Now, fetch me some fish heads!”

Previously, I discussed The Delivery as one, small part of product management, and the need to plan a product’s life cycle past its birth, all the way to its eventual shutdown. These are things I don’t see included in the typical plan for high tech products.

From my previous post: “In any IT group, software development shop, or product development team that ever had a successful product, the ACTUAL ‘maintenance cycle’ is much longer than the other 4 ‘cycles’ [of the software development life cycle] combined.”

I want to see product plans that incorporate higher-order cycles of development and evolution. This is not a foreign concept, though not as practiced in life as it should be. There is an existing concept that defines it: Long-Term Planning.

The 29th Law of Power states: “Plan All the Way to the End”.

A complete product plan includes not only birth, but life, and the eventual death. The time when the last server is turned off, and any clients still in the wild begin failing with “cannot connect” errors when launched (though with proper long-term planning, customers might see a more informative and friendly version of that message).

Have no misunderstanding: this level of planning takes longer to complete. It’s not the sort of thing you bang out in a Gantt Chart over a long weekend. It takes time, iteration, and the creation of lots of scenarios for failure and success. Getting it even close to right takes a level of prescience few have at their disposal.

Depending on available capital, it may be unreasonable to invest the time needed to do it fully, but some level of long-term planning is important if you want to see any success beyond the accidental. It may not be full, long term planning, but its better than short term thinking. Let’s call it “Longer Term Planning”. It needs to include the following at a minimum:

1. What the product should do to provide enough value that people might actually want it
2. When you’re going to ship it, and the steps you must take to get it ready to ship
3. How you’re going to sell it, collect revenue for it, and get it into your customers’ hands
4. How you’re going to deal with foreseen and unforeseen problems that will arise after you ship it
5. What you’re going to measure (a.k.a. metrics) to determine if the product is successful (i.e. profitable), and how you are going to collect the data for those metrics
6. What you’re going to improve after you ship it so that more people will want to buy it
7. How you’re going to deal with the probability that too few people will want it, which may involve improving it, or shutting it down
8. Which steps you will need to take to shut it down in the end, either due to failure, or due to the need for the product to go away in favor of something better/faster/stronger
9. What you’re going to do about those customers who still want it after you shut it down, which may include politely telling them: “Thanks for the business, and the money, now please seek fulfillment elsewhere.”

“But Greg”, you say, “My widget is the hottest thing since sliced bread. It’s the Coca-Cola of the 21st century! It will never go out of style, so I need not waste my valuable time planning for its demise.”

Good luck with that. Maybe you do have the next killer app, that will be successful for years to come. It’s still a good idea to plan for cycles in your product’s life span. Business ebbs and flows. Fashion progresses, sometimes not in a tasteful direction. And the success of a product is more influenced by the execution of those who make it than by its degree of hotness. So consider that maybe, just maybe, your hot new widget is the “New Coke” of the 21st century. Remember what happened to that?

The Delivery. Alternately known as “going live” and “shipping it”. The act of completing a product and making it available to the intended user, if such a thing as “complete” is even possible in modern, technology-based goods and services.

I once attended a seminar by Edward Tufte, who pointed out that the technology industry is one of only two that refers to its customers as “users”. This is no coincidence, as many in the trenches of the technology product world have about the same level of caring for their customers as those who work in that other industry.

So many in this business are focused on the “end goal” of The Delivery, yet they fail to miss the point: The Delivery is not the end, it is the beginning. The Delivery is the birth of the product. A successful product has a life beyond delivery, and perhaps even a death.  All of this is what most in the technology business call “Maintenance”.

All that development work you did…

• …on your localhost Web server…
• …in your Integrated Development Environment (IDE)…
• …downloading test code onto demo devices…
• …working with contrived test data (probably skinny test data at best)…
• …probably with less than 2.5 end-users ever in the system concurrently…

…that was like the nine months we all spent in our mamas’ bellies. The real, interesting stuff begins after The Delivery, when you ship.

IDE (Integrated Development Environment):

1. “a software application that provides comprehensive facilities to computer programmers for software development.” – from The Wikipedia
2. Code that helps a human make more code
3. Something that sounds like a birth control device that is uncomfortable when inserted

It is after delivery that you get real people in front of your web site who aren’t aware that if they hit control and the Q key, it will kill their browser before they can save a copy of the document they just wrote. It is after delivery that you get real people holding your device that don’t intuitively understand the big, round circle at the bottom of the screen is what they should press to get back to the home page. It is after delivery that you get real people in your system who don’t know which buttons not to push to prevent your application from failing horribly with a great, big dialog asking if the evidence of your feeble coding skills can be mailed to the OS vendor, where the systems geeks will laugh in derision at someone stupid enough to try to dereference a null pointer without first checking it.

Software Development Life Cycle (SDLC):

1. “a structure imposed on the development of a software product.” – from The Wikipedia
2. A hypothetical five-phase process theoretically used when building software. The phases are typically some semblance of: a) Requirements gathering, b) Design, c) Development, d) Testing, and e) Maintenance.
3. A process created in an idyllic time when people had the illusion that software products are ever truly completed.

In all of the “five phases” diagrams I’ve ever seen, the ever-present Software Development Life Cycle (SDLC), there has been one serious flaw. A flaw in understatement of the full product cycle. Every SDLC diagram I’ve ever seen has maintenance as a small, sliver of an afterthought, taking place shortly after the typically under-estimated “Testing” phase. Others are worse, and don’t include “maintenance” as part of the main cycle, but instead as a separate thing, existing outside of the ‘core’ SDLC. In any case, the PLANNED ‘maintenance cycle’ is typically at best 25% of the overall timeline, and often diminished to as little as 10% of it.

In any IT group, software development shop, or product development team that ever had a successful product (meaning: people actually used it continuously over an extended period), the ACTUAL ‘maintenance cycle’ is much longer than the other 4 ‘cycles’ combined. The maintenance cycle typically also includes several mini-cycles of product development, where new features are added and bugs are fixed. This is true of any product that does not fail in the marketplace, and even of some that do.

What sort of things might you uncover after your product ships? Here are some real-world examples:

• The registration process you spent days designing on the white board turns out to be too complicated. No one gets to the point where they actually put in their payment info.  Or they do put it in, but fail to notice the last “Place order” button, so it never gets processed.
• Your junior developer chose to use their own regular expression to validate email addresses (instead of a standard one).  People whose email addresses have a dot (‘.’) in them before the asperand (‘@’) cannot sign up for your service.
• The Javascript you were getting from your ad vendor in development looks completely different from what you get from their production servers.   Your parsing code made flawed assumptions based on this, and your ads disappear.
• Someone has a contact in their buddy list that has a funky character in the name.  This character, while handled by your message routing software, causes your database server to crash horribly when that customer imports their buddy list from the old service.
• The software that manages your online gambling system has an off-by-one error.  This results in several million dollars in money going to players, when it should have gone to the house.
• An engineer who left the project failed to check for a null pointer before dereferencing its object, causing the system to crash the app server every 7th or 8th time someone logs in. [One of my personal favorites. - G]

I could go one, but you get the point. Many of these would never have been found in a lab. Ideally, they should have been found during product testing, but the level of effort to test this extensively is often cost-prohibitive in the typically rushed product development timeline. It was only by shipping product, and getting it into the hands of real people using it in real ways that these bugs were uncovered. Rather than worrying about it, plan for it. Plan for the full life of your product, not just its gestation and birth. Expect that you will uncover new problems when you ship, and have an adaptive plan to deal with them. More on that soon.

Now, stop wasting time reading blogs, close your web browser, and go make something. Then ship it! Get it into the hands of your customers.  Then make it better, for as long as people want to buy it.

A year in the Gregorian calendar is just as good as any other, arbitrary measure of time invented by mankind for structuring your life, so here we go…

“My resolution for 2009: To whack the BS and valueless distraction from my life with a very large set of loppers, metaphorically speaking.”

2007 was a disaster. I changed my industry focus away from Telecom, which put my career and life in moderate turmoil. I lost thousands on a couple of bad real estate investments, got months behind on debt, and nearly filed for bankruptcy. November and December of that year were largely sleepless for me.

The nice thing about hard times is that you learn a lot about yourself, life, and what’s important. I learned a lot in 2007.

2008 was largely about recovering from 2007. I maintained steady utilization in my consulting business, closed out the last, lingering investment property, and got my life largely in order, while re-establshing some old friendships. I also worked on building new relationships, some of which washed out in the process, but a few have potential. I’m re-learning that it’s better to fast-fail a situation rather than have it linger in limbo for months, wasting time and energy for naught. A partnership that is not mutual, with a partner that cannot carry their own weight, traveling under their own steam, is no partner worth having.

I’ve also been working on being more genuine in my communications with those around me. We’ll see how that works out long term, since many seem to have a hard time with extremes of truth and openness. I’ve turned down work that I can’t do, which in the past I would have tried to do and failed. Committing to something that cannot be, or that you have no ability to deliver, is not fair to either party. Letting someone know up front that I can’t meet their expectations has been the most fair to both, as the other party is not expecting me to meet a commitment that can never be met.

When you aren’t certain which direction to go, any path will do. But once a direction is established, you should pursue that with all deliberate speed.

Strategically, 2009 is to be about cutting the crap, building relationships with those who will be a positive influence on my life, and removing or minimizing the influence of those who can’t or won’t add value, or frankly, really just need to grow up a bit. I’m looking for associations that will be open and mutual, neither party accepting commitments they can’t make, withholding the truth of what they want as an end-goal, nor being non-geneuine with their communication and availability.

See also: Trust, Performance and the Sharing of Time

Pragmatically speaking, I will be maintaining my consulting business in web content management for the forseeable, while also spinning up a new line of business focussed on iPhone development and consulting. I’ve done mobile device development on and off for years, and did a lot of C and C++ stuff earlier in my career, so its sort of like coming home, but to a redecorated house with all new appliances. It’s the first thing I’ve felt really passionate about in a while. More to come on that later.

I expect anyone to call me on any of this, should I fail to live up to my stated ideals. I promise to listen with an open mind.

Value is incompatible with Free. What can be the commitment to Free? If something is Free, then little or no value can be placed on it. As a customer, Free is worth every dollar you pay for it. As a vendor, the value of Free is inversely proportional to every dollar it costs you to deliver it.

The two sides of a transaction are: The Customer and the Vendor. The Customer wants VALUE in a product or service. The Vendor wants to get paid for the product or service they provide, so that they can continue to provide it, and to generate a profit as a reward for the product of their creation.

From the Wikipedia article on Value: “Value is linked to Price through the mechanism of exchange. When an economist observes an exchange, two important value functions are revealed: those of the buyer and seller. Just as the buyer reveals what he is willing to pay for a certain amount of a good, so too does the seller reveal what it costs him to give up the good.”

There is lots of talk presently about sustainability and sustainable business models. No business is sustainable when it produces nothing of value. Nothing of value can be produced without the expense of resources, either time, money, or both. This is the basic truth of thermodynamics. Those resources must come from somewhere. If you can get what you need to produce your product via altruism, more power to you. But the classic model for a sustainable business is to produce a product whose value is enough that customers will pay for it, and pay enough cover the costs of production, plus some profit for the producers, which is their motivation to produce it.

Thermodynamics is defined, in it’s simplest form, by three “laws”. I once heard them paraphrased very well:

• Law 1- You can’t win.
• Law 2- You can’t break even.
• Law 3- You can’t get out of the game.

Free products are, by necessity, the first dropped from the line when business goes south. When times get tight, the easiest cost to cut is the one that has no negative effect on the bottom line. “You can’t compete with free” has a double meaning. Free can be easier to “sell”, but selling something for free doesn’t generate any value to the seller. In fact, it generates cost. It’s hard to compete with other’s who are offering a competitive product for free, but it’s also hard to compete effectively when you’re giving away a product that is costing you to produce and support.

I recently read comments bitching about AT&T’s plan to charge $30/month for access to the upcoming tethering feature for the iPhone. Everyone was so incensed that AT&T was going to charge extra for the service, despite the facts that they charge the same, extra amount for other devices, and that typical laptop-based data usage is significantly larger per session than mobile phone data usage. How dare they want to re-coop the cost of the network build out required to support their service, and maybe make a little profit. Those Capitalist Bastards!

We’re starting to see a number of the “Web 2.0″ free services either close down, or get acquired by other companies, presumably for their technology, since it’s hard to valuate a company that has no revenue. Restating the obvious, this is basic stuff. A business that makes no money cannot survive.

My prediction for the Web 3.0 business model: Direct revenue. Charge a reasonable price for a service that provides value to the customer. Let the freeloaders go to those competitors still trying to monetize their services without charging for them, and cost them the resources you will save. It’s better to have 1000 paying customers than 100,000 users that are just costing you money.

Is it ironic that, in my treatise against free, I am referencing a free service? Ah, but is Wikipedia really free? I assure you, a site with Wikipedia’s magnitude and traffic costs considerable money and time to host and support. Perhaps you’re not paying for it, but someone is.

Trust is one of the most difficult things to earn from another human. Perhaps THE most difficult thing.

Trust is made or lost purely in one’s actions. What brings trust from another? Consistency in your actions. And agreement between your words and your actions.

Trust is not a judgement on relative good or evil. I can see someone as “good”, yet not trust them. The most religious person can justify any action if they believe God is on their side. I can have complete trust in someone I consider to be evil. I trust them to do evil things. At least there is a foundation for predictability.

Siona: “Do you know why I trust you, Nayla?”

Nayla: “Have I ever given you cause to do otherwise?”

Siona: “That’s not a sufficient cause for trust.” …

Nayla: “Then why DO you trust me?”

Siona: “Your words and your actions always agree. It’s a marvelous quality.” … “Everything is based on performance. That is all I measure.”

- From God Emperor of Dune, by Frank Herbert

The passage above is the most eloquent, concise art I’ve found on the subject. When someone consistently acts in a fashion that agrees with their words, it builds trust.

When a person’s actions do not agree with their words, trust erodes. How can one trust words when actions taken by their speaker are not compatible?

Observing how one person interacts with another can tell you a lot about truth and trust. Whom we choose to spend personal time with is a barometer of our true feelings for those people, and also for our true feelings about ourselves. To hear someone speak poorly of another on one hand, yet spend large amounts of personal time with them, is an inconsistency between their words and actions.

I’ve struggled with this all my life. It’s difficult to know how a particular message will be interpreted by another. People can be complex in their patterns and diversity.

Meme: “any idea or behavior that can pass from one person to another by learning or imitation.” – Wikipedia

This is something toward the true nature of “trust”: Being able to reliably predict how another will react to a particular meme of information. Is it safe to expose that person to that particular idea? A single thought can make someone’s day, or ruin a life. The difference often depends on their readiness to understand. You don’t want to tell someone a thing that will (proverbially) make their head explode. It’s not helpful, to them nor to you, to expose someone to information which they are not yet prepared to know.

Reading that terrain is one of “those” skills. Just when you think you have some mastery, a whole new level of awareness dawns. And you learn how little, in fact, you really know after all.

So, why bother at all? Because when there is trust, their can be openness. With openness, there is the opportunity to truly share time with another being, to experience their unique thoughts, feelings, and patterns. And that has its own rewards.

This post was originally titled “Two Weeks with the iPhone”, but as noted previously, I was sick last week and didn’t have the mind power to do it justice. So, with another week, and more usage under my belt, I might also call this post my Ode to My Happy, New, Digital Pal. Here we go…

I’ve been a Blackberry user for five years, across three different devices, including the old two-way pager. I’ve been interested in the iPhone since its release, but without real Exchange support, the first iPhone was not an option. Then it became a personal challenge to keep my Blackberry alive as long as possible. When the click-wheel finally augured in, it was time to make the switch.

It hasn’t been a huge transition. I’m using the iPhone for most of the same things I used my previous Blackberry:

• Email and text messaging
• News from the web, mostly from Digg and Google
• Local listings and traffic information
• Phone calls

Here are my experiences and impressions so far, the good, the bad, and the ugly.

The Good

• The screen: It’s really beautiful, and large. Most of the surface area of the device is screen, vs. less than half on the Blackberry.
• The screen: The touch-screen is what makes makes it possible to be large, since now surface area is required for input devices. Sadly, the lack of tactile feel is the primary reason for The Bad (see below).
• Slim and light: The new iPhone is much thinner and lighter than any phone or PDA device I’ve previously owned.
• The Google Maps app: The addition of the GPS on the Google Maps app makes this much improved. Traffic data is also much improved.
• Full-on web browser: Though not as useful as a full-size browser on a laptop, I can make use of many more “real” web sites than on the Blackberries I’ve owned.
• Social Networking apps: I’ve added the apps for Facebook, LinkedIn, and Twitter. It’s very nice to have access to this stuff without need of a full laptop.
• Built-in iPod: This comes in handy every now and then, though so far I’ve made minimal use of it.
• At long last, I have a phone with a camera built in. I missed a couple of photo ops the first week, but now I’m making better use of it.
• Did I mention the screen?

The Bad

• The On-Screen Keyboard: I’ve become very proficient at touch-typing on the Blackberry keyboard. The tactile feedback makes it easy, or at least possible, to figure out when your on one key or another. Not so with the on-screen keyboard on the iPhone. It’s been one of two things that’s made the experience inferior to the Blackberry. The other being…
• No Cut-and-Paste: Every computer system I’ve used since at least 1990 has had cut-and-paste built in. Most of the mobile phones I’ve used, including the ones that simply make calls and do text messages, have had cut-and-paste. The Apple Newton, also a touch-screen device, from 14 years ago, even had cut-and-paste [ouch!]. So why can’t the iPhone do it? The only reasonable thing I can speculate is: Apple hasn’t decided what the right gestures should be. I hope the figure this out soon.

The Ugly

Actually, it’s a very pretty phone. Until you touch it. After only a day, both the screen and body became noticeably smudged with fingerprints. Plus, the surface is very slick, and wanted to slip out of my hand. This was easily fixable with a protective sleeve (see below), and it still looks very nice.

A Few Nitpicks

• I don’t miss Flash particularly, since it’s mostly used for annoying, animated ads and skip-intros, but it would be nice if the iPhone could play Flash videos as well as it plays Quicktime.
• I miss the blinkenlichten on the Blackberry that lets me know if I have new messages without having to wake up the screen. A cool, throbbing, white LED, like the one on the the Macbook or on the Jawbone headset would be sweet
• The email view would be so much better if it had: a) an “unread only” view for the inbox, and b) a separator between dates in the email list, similar to the list view in the Calendar app.
• [updated] How about a feature where the iPhone turns itself on and off at certain times of day.  This is huge battery saver on the Blackberry, plus it keeps your email from beeping at you all night.

I am very pleased with my switch to the iPhone. I’m slowly getting used to the keyboard, and the lack of cut-and-paste has only been annoying about six times so far. My hope is that this too will get fixed in a future product release.

---

Read on for more about the accessories and applications I’ve chosen for my iPhone, and why…

 

 

 

Accessories

I usually prefer the bare metal, but because of the smudging and slipperiness problems, I opted for a screen cover and protective sleeve.

Screen Protection

The Power Support Anti-Glare Film does a nice job. It comes in a pack of two, and was easy to apply straight and keep the air bubbles out. The matte finish helps with glare, but there is also a glossy version. One bonus: The protector seems to have slightly dampened the touch screen sensitivity, which I found to be a bit too high. With the protector, the finger-flick scrolling goes just the right distance I would expect, an my typing accuracy seems marginally better.

Phone Sleeve

I chose the Incase Cover for the sleeve. I wanted something that to increase the grippiness of the phone, while not adding as little girth as possible. The Incase is as thin as they had at The Apple Store, and it’s very rubbery. It feels very much like my old Newton MessagePad. Also, it should provide some, small protection should the device get thrown or dropped, except in a toilet.

The extra grip of the protective cover keeps the phone in place when I sit it on my truck’s center console, though I suspect this will become less effective over time, when the grip wears off. Because of the friction, it’s much harder to slip the phone into my back pocket. This could be a good thing, since it’s less likely I will sit on it by accident, but it can be a pain to stow the device when I need both hands free.

I’m a little unhappy with the extra thickness of the phone when the sleeve is on. I’m thinking about ordering an Ultra-slim Silicone Case as a replacement.

Hands Free

I’ve been looking for a new Bluetooth headset for a while, and with the new phone, this seemed like a good time to make a choice. I’ve owned several over the years, and they’ve all sucked in one way or another. Either the sound quality sucks, or it’s uncomfortable to wear for any amount of time. Usually they’re hard to wear with glasses. I went with the Jawbone. It works great, has decent sound quality, and is very comfortable to wear, even with glasses, and on long conference calls.

Applications

My goal is to keep my apps to a minimal. Most of what I’m using are the same or similar as apps I had on my previous Blackberry. I’ve tried a few and removed more than one.

These apps have stuck:

• iSSH: I had an SSH app on my Blackberry. Critical for when a server gets jacked and you’re no where near your laptop or a Wifi link. This one has a translucent keyboard option, which gives more screen real estate for terminal output. This would be a great option in other iphone apps.
• Facebook: I’ve been doing the Facebook thing recently. Having it on the iPhone makes it that much easier.
• LinkedIn: Facebook is for fun, and LinkedIn is for business. The LinkedIn app is nice, but it seems to have a bug, or perhaps a feature, that makes it forget my login. This is doubly annoying on the iPhone, since text input is more difficult.
• Twitterific: I use the desktop version of this on my Macbook. The iPhone version can generate Google Maps links based on location data, and auto-post photos from the camera to Twitterpic.
• Texas Hold’em: Also had a Poker app on my Blackberry. The one game I play consistently over time. This one is much prettier, and the ability to swipe the screen at any time to fold your hand is a real time saver.
• PhoneFlix: Seemed to be the most preferred NetFlix app. Nice to be able to add a disc to my queue from anywhere. On the Blackberry, I would have to send an email to myself.
• Discover: I like the simple ability to expose my phone’s stuff via a web interface. The new version seems to allow you to mount it as a network drive.
• iTunes Remote: It’s occasionally nice to be able to control the iTunes music from my couch.
• Weightbot: A weight tracker app with novel uses of the iPhone’s interface widgetry.

These apps I tried, but promptly deleted, and I don’t see much point linking to them:

• Lightsaber: This was amusing for about 3.2 minutes. Deleted.
• Bubble Wrap: Not as good as the now-classic Virtual Bubble Wrap, and started annoying me to buy the “pro” version very quickly. Gone.
• Crazy Pumpkin: Cute Halloween idea, but amusing for less time than the light saber app, and it displayed a blank screen the second time I ran it. Whacked.
• Safari Bookbag: I like the idea of having my Safari bookshelf readily available, but it doesn’t seem to actually work that way. What it seemed to do, at least for me, was generate PDF’s to download from the Safari website. Kicked to the curb.

Woke up with a nasty head cold today. The Minute Clinic was a quick, no-hassle way to get the care I needed.

The last time I had a cold, I let it go for several days, expecting it to get better on its own. It didn’t. Because of the missed work, it affected two “lines”:

• My client’s time line
• My bottom line

This time, I decided I wasn’t going to waste any time. My doctor is usually pretty good about getting me in on the same day, but his office isn’t open on Sundays, and the last time I went to one of those “Doc-in-a-box” clinics, I had to wait over an hour in an uncomfortable chair, and picked up a secondary infection from the other sick-ies waiting with me.

Today, I decided to try out the latest innovation in medical business practice, and proceeded to the local CVS for a visit with the Minute Clinic.

What is the Minute Clinic? It’s a small medical facility co-located within a retail pharmacy. Generally manned by a Registered Nurse (RN) or Nurse Practitioner, they’re able to treat light-weight illness, administer flu shots, and other nominal medical care needed in [my guess] 80% of the cases that come to a typical doctor’s office.

I suspect the only thing that limits what can be done at these facilities is lack of equipment (I.e. no X-ray or lab on site.)

The operating costs are kept low, using automation in the registration process, and without a full MD on staff. Plus, it can drive new business to its “host” pharmacy, since it’s convenient to pick up your prescription on site.

The experience was wonderful.

They had a bright, touch-screen registration kiosk outside the door. My data was all pushed to the PC where the RN was able to enter my insurance, input all the diagnostic data, and select the recommended medication. There was no paper involved from start to finish, until the receipt was printed. The examination was as thorough as any of the recent exams I’ve had for a cold at my primary doctor, and since I’m not waiting in a room full of other sick folks before hand, it’s probably a lot safer.

I was checked out and on my way in about 15 minutes. Plus, since the clinic is located in a pharmacy, I was able to get my prescription filled on site. A nice business driver for CVS, since I don’t normally get my prescriptions filled there.

What were the downsides? Honestly, I can’t think of any. I got the same care I would have at the regular doctor’s office, it was more convenient and timely, and I didn’t have to wait amongst the heard. And it was a one-stop-shop for care and medication. The one thing that was less integrated than it could have been was that the RN had to pick up the phone and call the pharmacist in the back. Since they’re in the same store, shouldn’t she be able to just push it to the pharmacist’s PC or Blackberry?

I’m pleased to see this sort of innovation in the medical business. As a consultant, my time is valuable and precious, and I would prefer not to spend it waiting for basic medical care. I expect the Minute Clinic and other, similar services to become more common in the coming years.

Today’s post was originally planned to be about my recent switch from Blackberry to iPhone. Because of this cold, my head isn’t in it. I expect to be feeling much better in a couple of days, so look for “Three weeks with the iPhone” next Sunday.