Not at all. If that was the impression I gave I think I did a poor job of communicating. I have gripes, definitely, but I had a lot of fun doing it. And, platform wise, this app wouldn't even be possible on the iPhone or Pre. (I am thinking about porting to Android, though, if their user numbers pick up).
I would have loved to know some of the stuff I know now before I started, and help from RIM on the look and feel, but that's about it.
Very true. I wanted to talk about that in the article but had no way to quantify the impact. It's definitely worth noting, though. Thanks for bringing it up.
I set up this forum post as a placeholder where I'll post an analysis this weekend (if you want to bookmark or subscribe to it). It's locked so you don't have to worry about errant notices.
Ssshh. Pay no attention to the man behind the curtain.:)
In all seriousness, while marketing was the goal I wanted it to be a mutual exchange. (I actually mention that in my conclusion). I hope that there's no less value in it as a result. (I did try to mention the actual product as little as possible)
Much more on the "This will be fun... Oooh, money" side.
Well, and a lot of "#@$&* why is there no app to do podcasts on BlackBerry?". (Commuting sucks without podcasts, imo).
The interesting part is most of the costs are up front. I took two weeks off of work to write the initial version, and after that I've been tweaking it nights and one or two weekend days (two at first, maybe half of one now).
In hindsight I should have tracked my time better, but I'd estimate I spent just over 250 hours in code, and I probably spend about 6 hours a week doing support these days (much less earlier), so about 400-450 hours to this point. That works out to be somewhere between $45-50/hour.
But... the majority of the work is done at this point and I'm still bringing in an additional $1k/week with the ongoing sales, so the picture is getting continually better. It'll be interesting to see how long it keeps up. This slashdot article (and the waves it makes) will likely be the last bit of marketing hoorah I can get out of this app, so while I'm hopeful, I'm not optimistic. As I said in the article, marketing is really really important. (Well, until the App World gets some marketing of its own, I suppose).
Regardless of how it turns out, it was still a lot of fun. And my users seriously rock.
I think RIM really needs to get on it. Not having a unified look and feel in only going to hurt the platform in the long run. (Not that I care, personally)
Whoops, oversight on my part. Total sales stand at 2382 copies as of the data in the article (at an average net of $8.50 per sale I've made just over $20k). Thanks for pointing that out. I'd update the site but I'm afraid to break at the moment.
But that only works until they want to install itunes for linux or some other app, which will require privilege escalation, which is pretty much exactly where windows 7 is at right now. (Vista was an attempt to get there, but a poor one).
Sure, until several million parents and grandparents are using linux on their netbooks, then you need AV and anti-spyware just like on windows.
Linux is probably more secure from a remote attack perspective, but spyware and most malware aren't worms, they're a symptom of non-techies using computers. No OS can protect a user from himself.
Right now web apps are king because they're always only the nearest computer away, and work on almost everything.
We're getting close to devices that provide the same functionality in a mobile form factor. Once everyone has an iphone like device that has a standard development environment we'll likely see a resurgence of local apps. But that's probably a years away at best.
Right now, you can either develop for the web, which will work everywhere, or write one app in Win32/.Net, one in Objective C for Mac, one in Java with Blackberry specific apis, one in Objective C for iPhone, one in [whatever palm is up to], one in.net for winmobile, etc, etc etc.
The only reason client side apps were ever written was because you could be fairly sure windows was your target, or it simply wasn't feasible to centralize and so you forced a standard environment.
There's no single platform anymore, and probably won't be for a while (and when it comes it'll look a lot like a web browser), so the only viable option is web based.
Does it suck? Yes and no. It's definitely better than debugging an app on 40 different platform/cpu/os version combinations.
There's a *lot* of time at sea when cruising, especially on a trip like this. What's the difference between that and sitting on campus? Below I made a comment that specifically recommends against worrying about it in port.
The ship is a definitely a totally new and cool environment... for the first week or so. Then it's just your new home, and at home, I'd really like internet.
Speaking from experience, we hated going this route. You end up spending all of your time in ports searching for internet, which is really the last thing you want to be doing in some exotic foreign city:)
Plus, we've discovered that it's nearly impossible to research ahead of time, the language barriers alone make googling for it really hard.
My wife and I love cruising, but she runs her own business and can't be away from email for that amount of time. Thankfully there are options now:)
Most ships these days have cell towers on the ship connected by satellite that usually provide GPRS data (and it looks like the SAS one does as well). The problem is they're considered international roaming, which costs tons of money. However, T-Mobile has an unlimited international 'email' option for blackberry for $20/mo that we've discovered includes BIS traffic through the web browser and even tethering (though we've heard conflicting reports about tethering, we've never been charged for it while at sea). There's always Mobi-shark for routing laptop traffic through the BIS, if tethering is a problem.
So we either tether to her laptop, or just use blackberry and a wireless keyboard and end up with a reasonable means of staying connected (granted, at dial-up speeds). Of course there's also the expense of the blackberry and monthtly plan, but that's only going to add ~2% to the cost of the semester.
There's also the option of paying for the wifi access on a per-minute basis. The latency sucks, but if you're using a fat email client (thunderbird, etc) it only takes us 1-3 minutes to sign in, send and receive messages, and sign out. On commercial cruises they charge somewhere around $.50/min, so when there's cabin based wifi we generally opt for that route, since it's way less hassle than the cell option, we don't have to worry about T-Mobile changing their policies on what's included, and $1.50 a day is not a huge price to pay relative to the cruise.
If they're limiting your email to text based only with no attachments, it's probably at their computers (since I'm not sure how they'd restrict you to that on theirs), which means your options for doing funky encoding stuff to get around it will likely be limited. If not, and you can use your own computer, there are tons of ways to convert anything to text (after all, that's what your email client has to do to send attachments, too). The downside is the receiving end would have to be smart enough to know what you're sending.
What part of that solution required ditching all of your perfectly good XP machines? Seems like a huge waste of money to me. Especially given that VMWare player is free.
When I first downloaded Chrome I tested dom manipulation with it (with one of our internal DOM heavy apps) and the same operation takes ~4x the time in Chrome as it does in FF.
If I get some time I'll put together a benchmark of it, but to give a rough idea this is inserting ~2000 elements in various places using a combination of innerHTML and insertChild.
FF is probably not the fastest, but it's definitely not slower than chrome with DOM manipulation.
I am noticing a consistent trend in Mozilla trying to one-up the competition in their benchmarks, while ignoring the real-world problems of their products. Bad for their users, but in the long run, bad for Mozilla as a company and initiative as well.
The others do the exact same thing. Chrome did it in the same manner (completely ignoring DOM in their benchmarks).
It doesn't work by using totally throw away data, only *new* data is thrown away. For example, going to google in incognito mode sends my real google tracking cookie to google (and the same for other sites).
This is probably to keep ads working, but totally nerfs the feature. I don't really care if my local computer keeps track of what I've browsed, I want to ensure that nefarious sites aren't getting my session cookies.
It definitely feels different, but DOM performance seems pretty poor (testing on DOM heavy internal apps). Poor to the point that an operation that isn't specifically laggy in IE/FF pops up an unresponsive notice in Chrome (though it eventually finishes).
Anecdotal for sure, but to me it doesn't really help to speed up JS if DOM is the bottleneck in the first place (as it is in other browsers as well).
Slashdot Mirror
Depends largely on the game, I think. As far as I know there's no graphic or 3d acceleration available on any of the BlackBerry devices.
Not at all. If that was the impression I gave I think I did a poor job of communicating. I have gripes, definitely, but I had a lot of fun doing it. And, platform wise, this app wouldn't even be possible on the iPhone or Pre. (I am thinking about porting to Android, though, if their user numbers pick up).
I would have loved to know some of the stuff I know now before I started, and help from RIM on the look and feel, but that's about it.
-Marcus
Very true. I wanted to talk about that in the article but had no way to quantify the impact. It's definitely worth noting, though. Thanks for bringing it up.
-Marcus
A couple of people have asked for that via email.
I set up this forum post as a placeholder where I'll post an analysis this weekend (if you want to bookmark or subscribe to it). It's locked so you don't have to worry about errant notices.
-Marcus
Ssshh. Pay no attention to the man behind the curtain. :)
In all seriousness, while marketing was the goal I wanted it to be a mutual exchange. (I actually mention that in my conclusion). I hope that there's no less value in it as a result. (I did try to mention the actual product as little as possible)
-Marcus
IIRC the only podcasts apps created for iPhone by third parties were all rejected by the app store.
Much more on the "This will be fun... Oooh, money" side.
Well, and a lot of "#@$&* why is there no app to do podcasts on BlackBerry?". (Commuting sucks without podcasts, imo).
The interesting part is most of the costs are up front. I took two weeks off of work to write the initial version, and after that I've been tweaking it nights and one or two weekend days (two at first, maybe half of one now).
In hindsight I should have tracked my time better, but I'd estimate I spent just over 250 hours in code, and I probably spend about 6 hours a week doing support these days (much less earlier), so about 400-450 hours to this point. That works out to be somewhere between $45-50/hour.
But... the majority of the work is done at this point and I'm still bringing in an additional $1k/week with the ongoing sales, so the picture is getting continually better. It'll be interesting to see how long it keeps up. This slashdot article (and the waves it makes) will likely be the last bit of marketing hoorah I can get out of this app, so while I'm hopeful, I'm not optimistic. As I said in the article, marketing is really really important. (Well, until the App World gets some marketing of its own, I suppose).
Regardless of how it turns out, it was still a lot of fun. And my users seriously rock.
-Marcus
I think RIM really needs to get on it. Not having a unified look and feel in only going to hurt the platform in the long run. (Not that I care, personally)
Whoops, oversight on my part. Total sales stand at 2382 copies as of the data in the article (at an average net of $8.50 per sale I've made just over $20k). Thanks for pointing that out. I'd update the site but I'm afraid to break at the moment.
Seems so. It's going to be *really* hard for this to live up to the hype it's going to generate.
Actually in the article he specifically points out that it is a physical problem that doesn't depend on any external factors.
After all of the blocks have been used the first time a new physical delay is introduced: the need to erase old blocks.
Infinite recursion hurts my brain.
But that only works until they want to install itunes for linux or some other app, which will require privilege escalation, which is pretty much exactly where windows 7 is at right now. (Vista was an attempt to get there, but a poor one).
Sure, until several million parents and grandparents are using linux on their netbooks, then you need AV and anti-spyware just like on windows.
Linux is probably more secure from a remote attack perspective, but spyware and most malware aren't worms, they're a symptom of non-techies using computers. No OS can protect a user from himself.
OS X isn't free either.
Right now web apps are king because they're always only the nearest computer away, and work on almost everything.
We're getting close to devices that provide the same functionality in a mobile form factor. Once everyone has an iphone like device that has a standard development environment we'll likely see a resurgence of local apps. But that's probably a years away at best.
Right now, you can either develop for the web, which will work everywhere, or write one app in Win32/.Net, one in Objective C for Mac, one in Java with Blackberry specific apis, one in Objective C for iPhone, one in [whatever palm is up to], one in .net for winmobile, etc, etc etc.
The only reason client side apps were ever written was because you could be fairly sure windows was your target, or it simply wasn't feasible to centralize and so you forced a standard environment.
There's no single platform anymore, and probably won't be for a while (and when it comes it'll look a lot like a web browser), so the only viable option is web based.
Does it suck? Yes and no. It's definitely better than debugging an app on 40 different platform/cpu/os version combinations.
There's a *lot* of time at sea when cruising, especially on a trip like this. What's the difference between that and sitting on campus? Below I made a comment that specifically recommends against worrying about it in port.
The ship is a definitely a totally new and cool environment... for the first week or so. Then it's just your new home, and at home, I'd really like internet.
Speaking from experience, we hated going this route. You end up spending all of your time in ports searching for internet, which is really the last thing you want to be doing in some exotic foreign city :)
Plus, we've discovered that it's nearly impossible to research ahead of time, the language barriers alone make googling for it really hard.
My wife and I love cruising, but she runs her own business and can't be away from email for that amount of time. Thankfully there are options now :)
Most ships these days have cell towers on the ship connected by satellite that usually provide GPRS data (and it looks like the SAS one does as well). The problem is they're considered international roaming, which costs tons of money. However, T-Mobile has an unlimited international 'email' option for blackberry for $20/mo that we've discovered includes BIS traffic through the web browser and even tethering (though we've heard conflicting reports about tethering, we've never been charged for it while at sea). There's always Mobi-shark for routing laptop traffic through the BIS, if tethering is a problem.
So we either tether to her laptop, or just use blackberry and a wireless keyboard and end up with a reasonable means of staying connected (granted, at dial-up speeds). Of course there's also the expense of the blackberry and monthtly plan, but that's only going to add ~2% to the cost of the semester.
There's also the option of paying for the wifi access on a per-minute basis. The latency sucks, but if you're using a fat email client (thunderbird, etc) it only takes us 1-3 minutes to sign in, send and receive messages, and sign out. On commercial cruises they charge somewhere around $.50/min, so when there's cabin based wifi we generally opt for that route, since it's way less hassle than the cell option, we don't have to worry about T-Mobile changing their policies on what's included, and $1.50 a day is not a huge price to pay relative to the cruise.
If they're limiting your email to text based only with no attachments, it's probably at their computers (since I'm not sure how they'd restrict you to that on theirs), which means your options for doing funky encoding stuff to get around it will likely be limited. If not, and you can use your own computer, there are tons of ways to convert anything to text (after all, that's what your email client has to do to send attachments, too). The downside is the receiving end would have to be smart enough to know what you're sending.
For wikipedia, I'd say take a copy with you.
What part of that solution required ditching all of your perfectly good XP machines? Seems like a huge waste of money to me. Especially given that VMWare player is free.
Apples to oranges, but maybe:
http://en.wikipedia.org/wiki/Oil_shale_reserves#North_America
I call BS.
When I first downloaded Chrome I tested dom manipulation with it (with one of our internal DOM heavy apps) and the same operation takes ~4x the time in Chrome as it does in FF.
If I get some time I'll put together a benchmark of it, but to give a rough idea this is inserting ~2000 elements in various places using a combination of innerHTML and insertChild.
FF is probably not the fastest, but it's definitely not slower than chrome with DOM manipulation.
I am noticing a consistent trend in Mozilla trying to one-up the competition in their benchmarks, while ignoring the real-world problems of their products. Bad for their users, but in the long run, bad for Mozilla as a company and initiative as well.
The others do the exact same thing. Chrome did it in the same manner (completely ignoring DOM in their benchmarks).
The incognito mode isn't really useful either.
It doesn't work by using totally throw away data, only *new* data is thrown away. For example, going to google in incognito mode sends my real google tracking cookie to google (and the same for other sites).
This is probably to keep ads working, but totally nerfs the feature. I don't really care if my local computer keeps track of what I've browsed, I want to ensure that nefarious sites aren't getting my session cookies.
It definitely feels different, but DOM performance seems pretty poor (testing on DOM heavy internal apps). Poor to the point that an operation that isn't specifically laggy in IE/FF pops up an unresponsive notice in Chrome (though it eventually finishes).
Anecdotal for sure, but to me it doesn't really help to speed up JS if DOM is the bottleneck in the first place (as it is in other browsers as well).
Not really, blackberry seems pretty good at it.