Symbian, a post-mortem
docs.google.com
Symbian, a post-mortem
1–10 of 25 posts
Re: Symbian, a post-mortem
#2Interesting: when I visit this doc (on Google Docs), there's a line at the top of the page that says:
"Wow, this file is really popular! Some tools might be unavailable until the crowd clears. [Try again] [Dismiss]"
This strikes me as a strange choice by the Google Docs team; rather than fixing the problem, they just tell you it exists. I mean, this is Google; don't they have lots of bandwidth and server capacity? Why can't they handle traffic spikes? Can anyone here shed some light on this?
Re: Symbian, a post-mortem
#3Fascinating read. I always enjoyed my Symbian phones, since the interface was pretty damn good for the keypad form factor, and I have a big soft spot for sliders; the behind-the-scenes mess that grew out of the late-90s platform tech goes a long way to explain more about why quality apps were so few and far between.
True background multitasking on a phone in 2006 was really fun, though.
Re: Symbian, a post-mortem
#4Interesting: when I visit this doc (on Google Docs), there's a line at the top of the page that says: "Wow, this file is really popular! Some tools might be unavailable until the crowd clears. [Try again] [Dismiss]" This strikes me as a strange choice by the Google Docs team; rather than fixing the problem, they just tell you it exists. I mean, this is Google; don't they have lots of bandwidth and server capacity? Wh…
Probably they have reserved bandwidth for paid Google Apps accounts, and although Google is a computing giant, it's bandwidth is not unlimited. And about fixing it, I don't think this is a bug, it's a feature.
Just my opinion.
Re: Symbian, a post-mortem
#5Interesting: when I visit this doc (on Google Docs), there's a line at the top of the page that says: "Wow, this file is really popular! Some tools might be unavailable until the crowd clears. [Try again] [Dismiss]" This strikes me as a strange choice by the Google Docs team; rather than fixing the problem, they just tell you it exists. I mean, this is Google; don't they have lots of bandwidth and server capacity? Wh…
I don't think it's a matter of bandwidth. The document is being served up just fine; the only feature that seems to have been disabled is real-time commenting.
Google Docs, like most of their applications, is built on a highly available, globally-distributed database. (There's evidence that it was using Megastore as of a couple years ago, and I wouldn't be surprised if it's now been migrated to Spanner.) That lets them scale to effectively infinite numbers of users, but it doesn't solve the problem of handling thousands of concurrent readers and writers all contending for the same individual rows in a multi-TB table, from multiple datacenters around the world.
Re: Symbian, a post-mortem
#6Interesting: when I visit this doc (on Google Docs), there's a line at the top of the page that says: "Wow, this file is really popular! Some tools might be unavailable until the crowd clears. [Try again] [Dismiss]" This strikes me as a strange choice by the Google Docs team; rather than fixing the problem, they just tell you it exists. I mean, this is Google; don't they have lots of bandwidth and server capacity? Wh…
This is pretty normal behaviour in large scale software. We add 'circuit breakers' (usually time, memory and rate based) that prevent denial of service attacks and stop exposed algorithms breaking sensible time limits per request. The last thing you want is one customer causing quality of service problems for another.
Re: Symbian, a post-mortem
#7Interesting: when I visit this doc (on Google Docs), there's a line at the top of the page that says: "Wow, this file is really popular! Some tools might be unavailable until the crowd clears. [Try again] [Dismiss]" This strikes me as a strange choice by the Google Docs team; rather than fixing the problem, they just tell you it exists. I mean, this is Google; don't they have lots of bandwidth and server capacity? Wh…
It's good software engineering.
The reasonable case for multi-person editing of a document is several people at the max editing the document concurrently.
Having thousands of people doing that is not a real-life scenario.
It's better to protect yourself from extremes like that by disabling editing functionality in that case than try to engineer a system that actually allows thousands of people editing a document concurrently (because it would be very expensive in engineering time and especially testing time).
There's literally no business case to be made for supporting thousands of concurrent edits - no one actually needs that functionality.
Re: Symbian, a post-mortem
#8Interesting: when I visit this doc (on Google Docs), there's a line at the top of the page that says: "Wow, this file is really popular! Some tools might be unavailable until the crowd clears. [Try again] [Dismiss]" This strikes me as a strange choice by the Google Docs team; rather than fixing the problem, they just tell you it exists. I mean, this is Google; don't they have lots of bandwidth and server capacity? Wh…
It's good software engineering. The reasonable case for multi-person editing of a document is several people at the max editing the document concurrently. Having thousands of people doing that is not a real-life scenario. It's better to protect yourself from extremes like that by disabling editing functionality in that case than try to engineer a system that actually allows thousands of people editing a document conc…
> It's good software engineering.
> The reasonable case for multi-person editing of a document is several people at the max editing the document concurrently.
On the other hand, I suppose it would be good UI design to not show that warning to everybody who only have read-only access to the document,
Re: Symbian, a post-mortem
#9Great read. I once did a project for S60. Initially I thought to use C++ but its implementation for this platform required to learn a lot of platform-specific quirks. I ended up implementing the project in Python. I'm really happy that I did not waste my time on learning the platform. This rises the obvious question: how to choose a platform that really deserves the effort to study it?
Re: Symbian, a post-mortem
#10This is just from my limited experience trying to develop mobile software around 2002 (J2ME and investigating Symbian) and developing for Android and iOS nowadays.
I developed 3 apps on J2ME at that time and investigated Symbian. The impression I got of Symbian of that time was that it was painful to develop against. J2ME was less painful but very, very limited. Think no animation support, just bitmaps, and I have to write my own game run loop, collision detection, etc.... This was most probably due to the limited hardware of the time but nonetheless, it was primitive.
In comparison, iOS and to a lesser extent Android are basically fully featured OSs with mostly full exposed functionality. iOS gives you core graphics, opengl es, core text, core animation, grand central dispatch, networking, etc... Android gives you views, animation, background tasks, activities, intents, etc...
The distribution model was also broken. If you wanted something distributed, you had to basically go with a carrier. There were attempts at an app store but there were not successful.
Contrast this with the App Store, Google Play, and iOS enterprise development program where you don't have to go begging to a carrier to get your app distributed.
To summarize, Symbian was coming from a previous era and had no chance. If you compare RIM's situation to Nokia's, I bet you will see a similar chart.