Cell Phone Pricing, Entitlement, and iPhones

So, here's a big old rant. Without links. It contains far too many switches of grammatical style (second to third to second to third). And it stems out of comments I found myself leaving on various blogs as people were bitching about AT&T's upgrade pricing for iPhone 3GS models for existing 3G owners.

I'm amazed at how many people are caught off-guard by the fact that it costs full price to upgrade from an iPhone 3G to the new 3GS. And full price is exactly where iPhone prices where when they first came out and we enjoyed HONEST pricing - $499, $599, and $699.

The US carriers shot themselves in the foot a long time ago with their whole 'free phone when you sign up!' plan, as Americans now expect that the world owes them a free or cheap phone along with their free or cheap lunch and free or cheap gas and free or cheap air travel.

I loved that when the iPhone first came out, it was expensive. Expensive, but fair (until they knocked $200 off the price suddenly, but then gave all early adopters $100 back). Even Steve Ballmer laughed "no one's going to pay $600 for that when there's an HTC Touch Diamond available for $200"... Wrong. The HTC Touch Diamond (or whatever fancy model was around at the time) really cost $900+ new. Few US carriers offerred it, particularly at the so-called 'subsidized' rate. But people see that $199! price tag in the cell phone store window and thinks that's what all high end phones cost, when in fact, that's about how much the LOW end phones actually cost.

I had hoped that the original iPhone would usher in an era of honest pricing, as well as an era of not needing the painfully slow in-store activation process that existed at that point. It was so cool to just pay for your iPhone, go home, and activate it (once the activation server issues got balanced out).

I think that Apple was really trying to change the cell phone industry, or at least make it a bit more like the regular Computer and Gadget industry. But alas, they weren't successful. They caved in with the 3G and went to subsidized pricing and in-store activation.

Anyways, so many people are gasping at the full-price option. I saw one comment saying "AT&T may not be in a recession, but I am, I'm not paying for this!"

But he was willing to pay $199 for a product he technically does not NEED.

If he is in a recession, he should be trying to get the most value out of what he already has, which is the iPhone 3G. And that's still a damn fine device. In fact, with the free OS upgrade in a week, it will be even better!

The iPhone is meant to last two years. When Apple talks about their subscription-based accounting model for iPhones, it's because they break the price out across two years. You're paying, say, $599 up front for a two year subscription that includes all new functionality that future firmware options might bring. (It's a weird accounting rule, but it makes some sense - enabling MMS can be seen as a value-adding feature; so if it's not enabled initially but six months or a year down the line, does that change the value of the phone for the people who bought it before it was enabled? Does it change its relative cost to Apple? Same phone, semi-major new feature that was not initially advertised... It's weird. But I'm not an accountant). Anyways, as I understand it, Apple is just now able to take full account of my original iPhone purchase that I made two years ago.

And yes, I bought my iPhone when they were full price. And that made me think more about upgrading. I decided that I wanted to get full value out of my phone, regardless of what came out next. When the 3G came out, I decided it wasn't enough of an update. Sure, I wanted it. But I definitely didn't need it. (Technically, I don't need an iPhone, but hell if I'm going to give it up!) 3G speeds? Would be nice, but EDGE is OK here, and much of my time is spent at home or work where I have Wi-fi anyways. GPS? Would be nice, but triangulation works well enough for my needs.

Granted, I'd still feel the pull of the 3G - it has better built in speakers and a louder ring, as well as a properly-flushed headphone jack. As a musician who loves playing with some of the music apps available on the iPhone, all of those would be nice. The only thing that really is tough about my first-gen iPhone is that it's a 4GB model (it's all they had in stock the day I bought mine). I thought "I enjoy my 1GB shuffle, 4GB should be fine!" but I constantly run into that wall. But still, I've managed to get by.

It just didn't feel worth it to jump up and buy a whole new phone over relatively minor improvements, especially when the battery and everything else were holding up fine. I've only had one relatively bad drop (which just scuffed up the case a little), no water incidents... It's still in excellent shape.

When Apple did the surprise price cut on the initial iPhones (dropping 8GB from $599 to $399, and dropping the 4GB altogether), a lot of people bitched. I didn't understand this. I'm kindof glad they did - hey, we get $100 to spend at Apple store! But still, they were the ones who felt that the product that they were buying was worth $599. And it's a luxury item, not a necessity. If you NEED a cell phone and have little or no money, there are plenty of other options. But the way that people got upset was baffling. I can understand saying "oh goddammit" and moving on, just accept that I paid more.

A few months ago, Louis CK had a terrific rant about how we live in amazing, amazing times, and nobody is happy. And it was a rant about how people (particularly Americans) feel like they are entitled and owed so much, for free, and right now!

We are not owed or entitled to ridiculously discounted cell phones without strings attached. We are not entitled to ridiculously cheap air fare without having to put up with some minor irritations (honestly - SLC to JFK in five hours for less than $150? How can you complain about that?).

I hope that AT&T does not back down from their full-priced iPhones for current 3G owners. The AT&T contract has long been set up so that you only get special pricing after 18 months, which is a reasonable amount of time. If nothing else, it should prevent people from just throwing away whatever perfectly good thing they have for something that they don't particularly need. If it's something that you really need, you should be willing to pay full price. If you can't pay full price, wait for it to go on sale or be otherwise available at a discount. If you can't pay full price and can't wait, it's probably not the product for you.

Unless you're a developer. In which case Apple really needs to improve its developer program to provide developers with either discounted live phones, or usable test hardware (my understanding is that Apple does not provide this, leaving developers to use their primary phone as their test phone).

Ramping Up, Again

Ramping up, again, for the first time for the last time. Maybe.

Update on Tuesday, February 24, 2009 at 01:12PM by Jeff Shell

Ha! Well, I said I was ramping back up, yet here we are... Nothing new. I couldn't get MarsEdit to connect properly, and I was hoping to use that for writing. And right now, I have nothing to say.

Well, I'm sure I have something to say, but I can't think of it. Back to doing some analysis and design, Jacobson style.

Trying Django, looking at Seaside

As I mentioned earlier, I've long admired Django from the outside. Today I finally gave it a real try, going through the main tutorial. It's a bit of fresh air from where I've been buried. I'm not sure where to go from here though. That's no fault of Django's, per se. I just don't have any ideas about what I'd like to do with it - a problem which has held me back from investigating many web frameworks.

I don't have any deep thoughts at the moment. I'm just burnt out on Zope 3. But there really is no other framework which could do the kind of work we do with it. I've just been using it now for so long, but have had little opportunity lately to do anything... fun? Not many chances to innovate on new things with all of the projects we're doing. Just not enough time. Or at least, not enough time to do them as well as I'd like, but my standards are getting higher and higher.

I've been needing to bust out and just use something new for once. Django and Seaside are at the top of my list. Django because it has quite nice docs, a great podcast, and is stable. And I generally like its style. The last time I tried some of the other Python web frameworks, I got too frustrated too easily.

Pragmatically, I admire Django. But ideologically, I love Seaside. I'll have to see how it is to move beyond the basic little 'counter' example. I've installed the GLASS virtual appliance to try playing with an object database since, well, hey! That's what I'm used to using!

Leaps and Pains (or - changing development/deployment and scm tools to more closely realize the component architecture dream)

A year or more ago, I was really struggling with zc.buildout, a Python based tool for building out "repeatable" deployments. Buildout makes setuptools actually usable, particularly for development and deployment of web apps, although there are many other uses.

Buildout keeps everything local, allowing one app to use version 3.4.2 of one package while another app can use 3.5.2. But more than just being an 'egg' / Python package manager, it can do other tasks as well - local builds of tools (from libxml to MySQL and more), again allowing one app to build and use MySQL 5.0.x and another app to use 5.1.x; or just allowing an app to be installed onto a new box and get everything it needs, from web server to RDBMS to Memcached and beyond. We don't use all of these features (yet), but it's a nice dream.

Already it's very nice to be able to make a git clone of a customer app, run buildout, and then start it up. Buildout will put setuptools to work to ensure that proper versions of dependent components are installed (and, quite nicely, it's very easy to share both a download cache and a collection of 'installed eggs' - multiple versions living side by side, with individual buildouts picking the one they desire).

But it was not easy to get to this golden land. Prior to using Buildout, we'd check our code out of our CVS repository. Our customer apps were just another Python package, nothing special (not an application, and - more importantly - not packaged up in 'distutils' style). As we started to make more and more reusable parts, we had to do a lot of checkouts; and so I wrote a tool to help automate this checkout process. It would also check out other third party code from public Subversion repositories; all because it was easier to check out a particular tag of 'SQLAlchemy' or 'zc.table' than to try to install them into a classic-style Zope 3 'instance home'.

But it was getting harder and harder to keep up with other packages. We couldn't follow dependencies in this way, for one thing; and it required some deep knowledge of some public SVN repository layouts in order to get particular revision numbers or tags.

'Buildout' promised to change all of that, and offer us the chance to use real, honest-to-goodness distributed Python packages/eggs. But getting there was so very hard when there are deadlines beating you down.

I took a lot of my frustration out on both Setuptools (which is so goddamn woefully incomplete) and Buildout. But the fault was really in ourselves... at least, in a way. As mentioned above, it was easier to just checkout 'mypackage' into $INSTANCE_HOME/lib/python/mypackage than to figure out the install options for distutils/setuptools. As such, NONE of our code was in the Python 'distutils' style. We put some new packages into that style, but would still just check out a sub-path explicitly with CVS just like we were doing with public SVN code.

Part of the big problem that we had which made it so difficult was that we had hung onto CVS for, perhaps, too long. And doing massive file and directory restructuring with CVS is too painful to contemplate. But moving to Subversion never seemed worth the effort, and so we held on to CVS. But I knew I'd have to restructure the code someday.

Fortunately, Git arrived. Well, it had been there for a while; but it was maturing and quite fascinating and it offered us a chance to leapfrog over SVN and into proper source code management. Git is an amazing tool (perhaps made more so by being chained to CVS for so long), and it provided me with the opportunities to really restructure our code, including ripping apart single top-level packages into multiple namespaced packages (ie - instead of 'example' being the root node with 'core' and 'kickass' subpackages, I could split that into 'example.core' and 'example.kickass' as separate packages and Git repositories while keeping full histories).

For a while, I used Git with its cvsimport and cvsexportcommit tools to clean up some of our wayward branches in CVS, while starting to play with Buildout. I was still struggling to get a Zope 3 site up and running using our frameworks. And here... well, the fault was partly in ourselves for having to go through fire to get our code into acceptable 'distutils' style packages, which made learning Buildout all the more hard. But the available documentation (comprehensive, but in long doctest style documents) for some of the Zope 3 related recipes was very difficult to follow. Hell - just knowing which recipes to use was difficult!

But after many months of frustrated half-attempts, often beaten down by other pressures, I opened a few different tabs for different core Buildout recipes in my browser and furiously fought through them all... And boom! Got something working!

Unfortunately it was one of those processes where by the time I got out of the tunnel, I had no idea how exactly I had made it through. One of my big complaints as I was struggling was the lack of additional information, stories of struggle and triumph, etc. And there I was - unable to share much myself! I can't even remember when I was able to break through. It's been quite a few months. Just a couple of weeks ago we deployed our last major old customer on this new setup; and we can't imagine working any other way now.

'Git' and 'Buildout' have both been incredibly empowering. What was most difficult, for us, was that it was very difficult to make the move in small steps. Once we started having proper distutils style packages in Git, they couldn't be cloned into an instance home as a basic Python package (ie, we couldn't do the equivalent of cvs checkout -d mypackage Packages/mypackage/src/mypackage and get just that subdirectory). And we couldn't easily make distributions of our core packages and use them in a classic Zope 3 style instance home (I did come up with a solution that used virtualenv to mix and match the two worlds, but I don't think it was ever put to use in production).

So it was a long and hard road, but the payoffs were nearly immediate: we could start using more community components (and there are some terrific components/packages available for Zope 3); we could more easily use other Python packages as well (no need to have some custom trick to install ezPyCrypto, or be surprised when we deploy onto a new server and realize that we forgot some common packages). Moving customers to new server boxes was much easier, particularly for the smaller customers. And we can update customer apps to new versions with greater confidence than before when we might just try to 'cvs up' from a high location and hope everything updated OK (and who knows what versions would actually come out the other end). Now a customer deployment is a single Git package - everything else is supplied as fully packaged distributions. It's now very hard to 'break the build' as all of the components that are NOT specific to that customer have to come from a software release, which requires a very explicit action.

Giddy-up 401, File Uploads, and Safari

I've recently been doing some work to support ZODB 3.8 BlobFiles in our Zope 3 based sites and applications. Doing this brought me back around to seeing some behavior I've seen in the past and probably learned to ignore: uploading a large file from Safari using a basic HTML form (with proper encoding type, POST, etc) seems to take inexplicably long. Even worse - once behind Apache, you might not get an expected response, if any. You might get a 'timed out' response, unsure if the app server has everything and will finish the request/response cycle on its own.

It turns out that Safari does not eagerly send along authentication information along with each request when logged in with Basic Auth. When it does, it seems to have a very short time window.

So say you're logged in to your application with basic auth (for better or worse). The normal pattern is that when encountering an unauthenticated situation, Zope will challenge with a 401 status code and the WWW-Authenticate header (or something like that - I'm away from all specs right now). If you're not logged in, then you get the basic auth dialog box and send along the credentials. If you are "logged in", then the browser doesn't ask for credentials again, but just sends them along.

The downside is that this causes a request to be repeated. And if you just tried uploading a 5 MB file, then that whole file has to be re-submitted to make the full request.

It's the right thing to do with the basic (ha!) information at hand - trying to post all of that data in a single request. But Safari should recognize that it's submitting to the same server (if not the same URL!) and should automatically include the auth headers. Safari seems to do this, but only on requests in very short windows.

Firefox, on the other hand, seems to have a much longer window in which it will send the credentials along automatically on the first request, instead of waiting for the challenge.

I don't know how other browsers do it. I'm not sure what the spec says, if anything. Glancing at O'Reilly's "HTTP - The Definitive Guide" didn't seem to give any indication of whether it's better for the client to assume that it should send the authentication tokens along with each request back to the same server, or if it's better for the client to hold off on constantly sending that info along unless challenged.

Most of the time this doesn't really seem to matter - it's not something end users typically see as it goes by fast enough to rarely be noticed. Of course there are other ways of getting credentials (cookies, sessions, subdomain/remote ip mapping, etc) which we often use on the main public-facing side of our sites. But for content management and admin, Basic Auth is such an easy fallback, especially in a framework like Zope (1, 2, or 3) which has long had a strong security story and would automatically handle this crap for you way back in the days of Bobo (1996, if not earlier).

It's just an annoyance. Glad I nailed it down to this: uploading large files with Safari (I think IE is, or was, similar) to basic-auth protected sites often can time out because the browser posts once, gets the 401-Unauthorized challenge, and does the post again - this time with the auth info.

Solutions:

• don't use basic auth for sites that expect moderate to heavy uploading via forms.
  
• recommend and/or use browsers that send the auth token along more often in the first request.
• provide better interfaces for uploading files; providing better communication with the uploader about status, and perhaps having a better interface into the destination web app. Fortunately there are appear to be some free and open solutions out there already.

Wheee!

App Store - I'm Still Using

There's been a lot of blow-up, again, about the iPhone App Store, now in regards to some podcaster app being rejected for "duplicating functionality in iTunes". Personally, that's a stupid rejection, and it should be corrected. One reason? Just earlier this week (before I heard of this rejected app), I wanted the ability to download a podcast directly on my iPhone. I was about to leave for my morning walk with the dog, and I realized that there was a podcast or two that I had either downloaded in iTunes but weren't sync'd to the phone, or that I just wanted to quickly download to listen to while I walked. I could have plugged the phone back into the computer, but didn't have time to deal with the 'backing up...' step, nor much else. I wanted to start downloading while I finished getting everything together. So - just from myself, I can see the need for this functionality. And "duplicates existing functionality" should not be a valid rejection reason.

But as a purchaser and user, I'm not going to abandon the app store.  The iPhone is just too good, and the software is a big part of that. A big issue, as I see it, is that the iPhone is just so much more powerful than anything else out there. It shares a substantial amount of the core operating system and frameworks with desktop Mac OS X. But that doesn't mean that you could or should be free to write Mac OS X style applications with reckless abandon. Yet people have freaked out about restrictions such as "no background processes" which exist for good reason.

Palm, Symbian, and whatever runs the Blackberry devices have no desktop counterpart. Windows Mobile is a different core operating system, with similar yet different frameworks. But Windows Mobile doesn't seem to exert the same kinds of restrictions that Apple has thus far put on the iPhone. One element that I'm thinking of is that on the iPhone, applications are born to die. The operating system will kill any application that is running rampant with resources and not responding to warnings. Generally, this has worked, even with the issue-laden 2.0.x iPhone OS: applications suddenly die, without much reason, but the OS keeps going. What's special about this? Isn't it unix? Shouldn't it keep going? Well yes, of course; but what you don't have, as an end user, is any kind of Task Manager. "Oh goddammit, Koi Pond is frozen, let me bring up that thing that lets me force-kill it".

Apple's choice is, as far as I can see, that end users should not see anything like that. Whereas I know that Windows Mobile does have a Task Manager.

Apple's design here seems to be enforcing the fact that even though this is based on Mac OS X / Unix, it's still a very different platform. Sure the system can support multitasking, but as a user I'm typically doing only one thing at a time on the touch device. So why allow multi-tasking and put in the drain on system resources, especially when there is no task manager?

I don't see people so incensed at the rules and limits of other mobile platforms... Are they just used to it? Have those platforms been historically so incapable (from a technological perspective) that people just haven't cared? Or have I just never paid attention because they were on platforms I would never have interest in? Because really - until the iPhone, I never expected to see a mobile device I'd want to use. My prior phone (a Samsung something-or-other... generic color flip phone with mobile Java apps) had apps; had an app store (that I avoided like the plague because I didn't know how much it could cost me just to look at the DATA); had me hating all phones and wishing for a mobile phone that did n-o-t-h-i-n-g. The "smart phones"? All enterprisey. The iPhone changed everything.

It changed everything because Apple focused on different things - end user experience, usability, power, and general flexibility. It's a platform that I love. It's a joy to use, especially in comparison with everything that came before. Everything that came before may have been more supposedly "open", more supposedly "developer friendly", but that did not make them any better to use.

Apple needs to improve its process, yes. Apple should lift the cone of silence they still exert over all discussion of the iPhone SDK. And personally, I really think that Apple should provide an alternate avenue for applications to be delivered and installed, perhaps with a "caveat emptor" mode that would protect most casual users, but provide a venue for people to play with ideas and apps that break the iPhone's rules. Personally, I doubt I'd use such apps. I tried jailbreaking my iPhone once. It was fun for a couple of days, but woefully unstable and ultimately not really worth using. Granted, that was in the relatively early days of jailbreaking, it may have improved since then. But I don't really see the point in using it. The App Store is goddamn easy to use; most of the software I've purchased has been good; and it's an unstoppable force. We're only two months in to iPhone 2.x and App Store; we're only a year and two months into having this new mobile platform. And it's been WILDLY successful. And I imagine it's been a bit overwhelming, even for Apple.

They need to improve things, but it will take time. I would rather have Apple be overly restrictive in the beginning and open up more over time than allow "anything goes" and immediately fall into the legacy problems that have plagued Palm, Windows Mobile, and others (including the original Mac). I don't think Apple is trying to be evil. I think that they are being cautious, and they are making some rookie mistakes.

Cappucino / Objective-J

Another release for which I've been waiting: Cappucino / Objective-J. Objective-J is a new language that is to Javascript what Objective-C is to C. For those that don't know, Objective C runs on top of plain old C (ANSI C, I believe) and provides a dynamic runtime and an object-oriented programming model inspired by Smalltalk (message based, with keywords as part of the message).

Objective-J and Cappucino run the web site / application 280 Slides, a PowerPoint/Keynote style presentation tool. With Objective J (the language) and Cappucino (the framework), they were able to deliver a desktop style application on the web, using classes and syntax very similar to desktop application development on Mac OS X / Cocoa.

Which means we now have at least two Cocoa inspired Javascript frameworks, with the other being SproutCore. SproutCore, however, is pure Javascript and doesn't have the Objective J component. Whether we need new languages written in and interpreted in Javascript is something one could put up for debate, but I'm personally quite fascinated by what has been accomplished with Objective J, whereas SproutCore is far less interesting to me in a sea of Dojo, YUI, ExtJS, and so on.

Plus - last time I tried to use SproutCore, it seemed rather tied to Ruby and/or Rails, which immediately put a damper on my exploration of it. It claims to be agnostic, but it then felt like a heavier burden was on me as a Python programmer to figure out how I might try to integrate it into my system.

I don't yet know what Cappucino and Objective J provide and require for development.

Django 1.0

It's been a while in the coming, but it's here: Django 1.0!

Personally, I've never used the product. I've been doing Python web development for a long long long time and have significant investments now elsewhere, but I admire the hell out of Django. The Django project web site is a shining example of what a good site can be. As far as open source projects go, it remains one of the most approachable ones that I've seen. The Django project seems to have been able to attract like minded individuals, and their standards seem to have spread to related projects such as Satchmo. 

It will be interesting to see where Django goes from here. I had my criticisms of earlier versions of the code - I saw bits that reminded me of things we were doing back in old old versions of Zope. Django did a lot of it better, but it seemed that they were going to run into some of the same lower-level source issues that we did. But recent work has cleaned a lot of that up, and their push to 1.0 has been quite amazing to watch: they kept pretty close to schedule and - most importantly - seemed to nip a lot of potential legacy issues in the bud before they became systemic and unkillable legacy issues.

I wish we could get that same team of people working on setuptools...

Plans and Topics

Now that Griddle Noise is in its new home, this is a short list of what I hope to get back to covering:

• Python (of course)
• Zope 3 / Component Architecture
• Buildout, eggs, and the realization of the component dream (almost)
• Git (so great) 
• Object publishing / near direct manipulation 
• etc...  

 

Moving Camp, again

With a fair amount of success, I've pulled in the entries from the old Griddle Noise into a Squarespace account. I've long been dissatisfied with Blogger... It was good enough for a free service, I guess, but I just couldn't take it any more. It was hard to use Markdown, and it was hard to use its "wysiwyg" editor on Safari. Results were unpredictable. So I'm giving Squarespace a try.

Unfortunately, I should have waited until I wasn't so busy at work to do this so I could have more time to compare working in this against some other services (wordpress, etc). But, I've run clean out of time.