sixtyPercent: Cochlear Implants, Aviation, Technlology, and Philosophy 2007/01
Review of the Nokia E61
I got a new phone a couple of days ago -- a Nokia E61 "smartphone" -- here is a random collection of some of my thoughts after two days of use.
First off, I should point out that I didn't buy the phone through a cellular carrier, but rather I got it "unocked" from Expansys (Mobile Planet in the US). I just popped in my T-Mobile USA SIM card, and it worked right away. Nokia has a nice web site that will additionally send some more carrier-specific configuration information via an SMS, and in addition, since the E61 has WiFi, you can do that same thing via the internet on your phone. In any case, getting the phone up and running on T-Mobile for voice and data services was pretty painless.
The E61 more or less does everything -- it make calls (of course), is a competent PIM, has a very good web browser, plays music, has five or six different email options (both personal and corporate), plays videos, has games, is a note taker, speech synthesizer, world clock, book reader, VoIP client, reads -- edits -- and prints office documents and on and on and on. In short, it's really a full productivity computer in many ways. It is not designed to be a primary productivity computer of course, but rather an in a pinch or on the go productivity tool.
I'm happy to report that pretty much everything works as claimed -- thanks in no spall part to the very capable Symbian OS. I'm not happy to report that though everything works the end product is a user interaction disaster. If you read this blog, you probably know a bit about me -- I'm a computer professional, and have spent a decade working at Apple and Palm. I'm pretty familiar with all of the technologies in the E61, but I'm amazed at how much difficulty I'm having making the product work smoothly. I'm not running into bugs (as far as I know) -- just running headlong into what is obviously an software stack riddled with poor design choices and the unmistakable evidence of committee design. Somewhere along the way to producing the E61, too many product managers spent too much time in too many meetings with too many carrier people. I've been in exactly this situation, and it is amazingly easy to forget the end users' needs. When a cell phone company refers to a customer they are usually not talking about you and me -- they mean Vodaphone and T-Mobile, etc. I'm under no illusion that Apple's forthcoming iPhone will cure cancer and stop global warming, but I do hope it will seriously kick Nokia's ass back into focusing on the needs of their real customers.
Here's some of the most exasperating examples: As I said above, the web browser is actually quite capable. It renders pages much like I'd see on a desktop computer, and even has a nice overview mode for seeing the whole page and then zooming in to read some detail. Unfortunately, it takes eight key clicks to switch to page overview mode (and then just one click to go back to the zoomed in view). I knew this couldn't be right -- there had to be a shortcut key to do this, as the feature is so useful, but there's no "key equivalents" listed on the menus. After consulting the manual, I found what I needed -- press "8" -- which you do by pressing and holding the numeric shift-key while pressing "B". Why can't this be discoverable on the device?
Far far worse is the way the E61 in specific and Symbian OS in general treat data access. Nokia comes from the thick specification manual world of Networks and Carriers -- not the wild west of WiFi. When I turn on my MacBook, it connects to any known available wifi network without my interaction at all. If it can't find a know network, but it can find an open network, it offers to connect to that. On the E61, I have to define "Access Points" and "Access Point Groups" -- the former a named specific instance of a wifi networks, and the latter specify an ordered collection of data access methods. Hold on we're not done yet. When connecting to the Web, I must specify which Access Point or Access Point Group I want to use -- if I'm in a new open wifi area I must add the Access Point to my list. But wait -- click on a streaming media link in the browser, and the Real Player is (nicely) launched, and then you must re-specify which Access Point to use to access the stream. The Real Player doesn't seem to support the concept of Access Point Groups (and neither do many of the other apps on the E61), so you have to pick the right individual Access Point. By this point you're ready to throw the phone at the wall.
And on and on. Settings for various things are poorly organized; streaming media is handled through three different applications ("Real Player", "Mus. Player", and "Gallery", and yes, the application is labeled "Mus. Player"). Flash is installed, but doesn't work with the browser -- apparently it's only for "mobile Flash application" -- cool, but there is no Java application icon on the device, yet I know the phone runs Java apps -- the inconsistency is just stupid and confusing. The main screen of the phone is called -- get this -- "Active Standby Mode". (!). I poked around the phone for 30 minutes trying to figure out how to change the application shortcuts on the main screen -- it turns out you have to hit "Menu > Tools > Settings > Phone > Standby mode > Active standby apps.", and then choose from a small window that shows a long list of all applications and some bookmarks. Some -- not all.
In the end, I have a lot of sympathy for the folks at Nokia -- I know some of them, and I know they're probably trying to build great products against the usual pressures of budgets, schedules, partner agendas, carrier needs, and so on. But those things are all the kind of excuses that can kill a company by a death of a thousands cuts. Make no mistake -- the E61 technically accomplishes pretty much everything listed on its data sheet, and is probably currently as good as it gets on a smart phone. But from an actual end-user's perspective it's a piece of poorly designed, barely usable garbage.
The E61 is a good example of the phone evolving to become a true general purpose computing device -- in both good and bad ways. I support my less technically-savvy friends and family members on their computers, I can see that in Nokia's vision of the future I'll have to add their phones to my list too. Thanks a lot.
by David Creemer : 2007/01/27 : Categories technology (permalink)
Millions of dynamic web application hits a day with open source
At my day job, our traffic has grown quite a bit over the last few months, and we're now serving web pages to hundreds of thousands of visitors per day. When we designed our basic system architecture, we planned for this and more traffic, and I'm happy to say that our design seems to be scaling well, using a modest hardware investment.
In many ways, our application is a "traditional" three-tiered web application -- front-end web-servers connected to mid-tier application servers connected to back end databases. Our front-end essentially consists of a web server (lighttpd), content cache (Squid), and load-balancing proxy (HAProxy). Lighttpd, though not without its warts, is a reliable very fast webserver. All of our static web content is server by lighttpd, and the source data fits within the OS's page cache. We've seen peaks of more than 1000 requests / second handled by the front end without any trouble. Any complete page that can be cached for a reasonable amount of time is requested through the Squid cache. All requests that need to go to the middle tier -- both cache misses and completely dynamic pages are routed through the HAProxy load balancer. HAProxy is a very, very nice product -- it handles millions of requests/day, proxying to and monitoring the next tier, and reporting and allowing configuration of everything anyone could want -- all without placing much of a load on the CPU. We used to use Pound for this task, but switch to HAProxy to fix some timeout issues. Pound worked OK, but HAProxy provides a much greater level of monitoring and control.
Our application server middle tier consists of -- well -- our application servers, written in Python. What makes this layer interesting from a systems-architecture perspective is its statelessness. Client sessions are not stored in this tier, and so we can add appserver capacity by simply adding more application servers to our cluster. The application servers are managed as a unit, so things like pushing software releases can be accomplished with a single click. The application server's main function is to process web requests and return result pages (and AJAX page content). Much of this result data is aggressively cached in a shared memcached pool -- all of the application servers share the same pool and can therefore benefit from the work of their peers.
Finally we come to the back-end database. We run PostgreSQL on x86_64 Linux, and I'm very pleased with it's performance. As our load has grown, we have migrated to a more capable database configuration. We're currently running our primary database on an 8-CPU, 32GB Penguin Computing server, with lots of very fast disks. We work hard to minimize our database load, and our current system should handle our load well through at least the next 5x growth in traffic. In the grand scheme of things, RAM is pretty cheap -- even 32GB, and our system has room for another 32GB. With some help from Varlena LLC we learned about many of the ins and outs of the Slony replication system, and replicate our database in near-real time to both a co-located backup system as well as an offsite backup, which we also use for analytics.
The whole thing is monitored with Munin using and a collection of standard and custom plugins, and the system sends us SMS notifications of anomalous events. Putting together the whole system has been a ton of fun. I'm especially happy that we here able to do it entirely with open source software, contributing fixes and enhancements as we go along.
by David Creemer : 2007/01/23 : Categories technology python (permalink)
