Trial Software without the Download

I came across a rather innovative concept yesterday: try before you buy, without the download!

OK, I know what you're thinking. Why am I so excited about this? That's how all SaaS software works, right. But here's the innovative part: it's a database system, mongoDB.

I've tested out a lot of software, so it's no wonder my computers always start to get a little bogged down over time. That's because, for the most part, I have to download the software, install it, and use it for a long enough period to get acquainted and figure out if it does what I want. Sometimes that means downloading 3 or more competing products, setting them up, and quickly dispatching the ones that are useless.

Since moving to the Mac, this is a lot easier since "installation" is typically just drag-and-drop (at least for the good software). But systems for developing software, such as databases, command-line shells, etc. are all a little more invasive. This is probably because they're not made for the average person, so the companies or open source organizations don't spend a lot of time making installation easy.

Microsoft has been using virtual machines for some time now to allow potential customers to try their more massive suites. They've used both a Citrix-like environment, where folks can sign up for a couple of hours on a server that's running at Microsoft, and a downloadable VM. The downloadable VM works well because it's running locally and it's usually not restricted to such a short timeframe. However, the hosted approach is better because it doesn't require a 4GB download, even if the response times are a bit sluggish and you're limited on what you can do in that shared environment. There is a minor download for the browser-based VM player, of course, but that's minor and pretty easy to install.

The interesting thing about the mongoDB trial is that there is absolutely nothing to download. Click on the "Try It Out" link and it drops down what looks like a terminal shell window. When I saw that, I was sold. Then, you can start with "help" or "tutorial" and actually use the software as if you were connecting to a DB. I figured I could at least take the time to go through the tutorial and get acquainted before deciding whether I would download the executables and install them on dev box.

This type of interface works really well for something that is shell-like. In fact, I've seen other sites with "test it out" text editors for testing client-side JavaScript functionality. But this is a bit more exciting because it's a lot more complex than just some client-side JavaScript. You can store objects, there's a near-complete JavaScript engine built-in as well -- primarily because the real shell for the DB system uses JavaScript -- and you can test out a bunch of the features of the DB.

The trial doesn't include every bit of the DB, but it does have a pretty solid feature set for getting a quick picture of how you'd use the system. I'm not sure I'll use the DB at this point, but the tutorial gave me enough information to download it and try it out for a while. I'd say it did its job.

Dots for Tots for the iPad

I've just finished up my second iPad app. Once available, it should be available from iTunes as Dots for Tots.

The idea for Dots for Tots came from one of the books by Glenn and Janet Doman, How To Teach Your Baby Math. We really liked the idea of giving a sense of numbers to our son, Isaac, by showing him several dots on a page. The problem is coming up with the flashcards! So, we decided it was time to build an iPad app.

We actually had this idea with the iPhone, but the problem is screen size. A child (especially a really young child) just can't see well enough for 100 dots to appear on that small of a screen. However, when the iPad came out, and we saw how others were creating flashcards apps for it, we thought this was the time to break out the idea again.

With the experience of building the Coupons app, it only took about two weeks of total development time for this app.

Of course, I'm still learning new things about iOS app development. This app brings sound into the mix, plus switching orientation from portrait to landscape. Oh, and I had to use the shake feature, which is surprisingly easy to implement!

We want the app to do so much more, and eventually it will integrate with MultiPaaS to store settings and child progress, but that's a ways off. The next version will probably add basic math functions (i.e. add, subtract, multiply) to the mix.

We'll have a lite version out shortly after the full version is approved.

Here are several screenshots of the application in action:












Other screenshots:

iPhone App Approved!

I got a nice call from Apple after my latest rejection, and we worked through the issues and I resubmitted the app with new icons. I was very impressed that they called us, especially since we're such a small operation.

As of today, MultiPaaS Coupons is up on the App Store.

I'm just happy that I was able to build the app and get through the process to get it up on the App Store. It took a few times, but now I know better what works and doesn't work.

Second Rejection of MultiPaaS Coupons iPhone app

We just received another application rejection. The first one was due to the use of an undocumented API, used to terminate the application cleanly. I can understand that one, even though they didn't give us a documented API to handle terminating the application in a standard way. Instead, they expect us to use exit()!

Anyway, so here is an excerpt from the e-mail we were sent:

Your application, MultiPaaS Coupons, cannot be submitted to the App Store because it uses a standard Recents button for an action which is not its intended purpose.

The first frustration is that they could have found this during the first pass! Why didn't they send me both problems at once if they were so worried about it? My guess is that they just have multiple people handling these applications and the first one didn't think it was a problem.

Anyway, this is my response:

I disagree with this assessment. There are two standard Tab Bar buttons that use the exact same image: Recent and History. The only difference between these two buttons is the words that are used. The only commonality between those two terms is that both are based on time (the icon itself is a very simple clock) and they happen to both be periods in the past (one recent, one further in the past).

MultiPaaS Coupons uses a similar image to these (again, a simple clock), but uses a different word, "Expiring". Again, the concept is temporal in nature so it should not be confusing to users. The only difference is that it represents a concept in the near future, i.e. "soon". Therefore, it is perfectly reasonable, according to the specification at least, to reuse the icons for the same purpose. The usage should be obvious because different words are used.

In the case of coupons, "Expiring Soon" means that these coupons are really important, similar to "Recent" items in other applications. Conceptually "Expiring" is more closely related to "Recent" than "History" is, yet "History" uses the same icon as "Recent". It should not be confusing to users to see an icon of a clock and think "oh, these are coupons that are important because of something based on time."

In fact, because the icon is a simple clock, anything temporal in nature is fair game from a user interface perspective. If the icon were more complex (such as a clock with some annotation indicating the past) then it would be appropriate to limit it in some way.

I completely agree with standards and not confusing the user, but let's not go overboard and reserve a simple iconic symbol like a "clock" to always mean "recent". Let's give our users a little more credit than that.

Regards,
Michael

P.S. Is this the only problem with the application? Or, are there other problems that you will find later? It would take much less actual time to get the application into the App Store if we could get more than one problem at a time. This is the second problem the team has found and it could have been found at the same time as the other one and therefore we could have had this conversation earlier while I was fixing the other issue. Thanks for understanding!

We'll see what they say about the response, and I'll work on another icon just in case, because whether it's fair or not, they have all the power, and they can choose to wield it at will.

Update 6/1: Got a nice call from Apple today about my iPhone app. The guy was really helpful, and he encouraged me to resubmit with new icons. Actually, I was impressed that they called at all, so I've resubmitted with all new icons. We'll see what happens next in the saga! Eventually I'll need to update my screenshots, but not tonight.

First iPhone App

I finished development on my first real iPhone app this weekend! The application is very simple and is an extension of our MultiPaaS Web Application. The first app is an iPhone version of Coupons. Here are my impressions of the process and development experience.

The coding itself took only about 100 to 120 hours of total time, or somewhere between 2-3 weeks of full-time work. That was spread over about a month and a half of real time, mostly during the evenings. Working that way makes things take longer because of the context switch involved to get back into the mindset of the code (not to mention the activation energy!) Also, since I hadn't built anything in Objective-C or Cocoa before, I was learning a couple of very interesting technologies at the time. Overall, I think it's pretty reasonable to be able to build an app for a platform in such a short amount of time, and it says a lot for the framework and support that's available.

Speaking of support, I bought a book on iPhone development to help me build this app, and it promptly sat on my bookshelf for the past couple of months. I just don't learn that well from books — I'd much rather get in and start coding. I'll probably use it for some nice leisurely bedtime reading, and then I'll learn some of the right ways to do things!

The resources I did end up using were all online. The iPhone Developer's Guideand the iPhone Dev Center in general helped immensely. Plus, Xcode has the entire set of documents for iPhone development built in — rather typical for an IDE — so I did most of my library learning through there. And Google, of course. Most of the time I would just search for the answers, and most of the time, somebody had done it before.

For example, I used a modified version of Matt Gallagher's OrderedDictionary in the code, which was very helpful. Yes, I could have written my own version, but his was pretty good and only required a bit of modification for my own purposes.

By far the easiest part of the application to build was the UI. Not just the UI display development using Interface Builder, but the UI* classes are pretty easy to understand. In contrast, the most interesting and challenging part was the interaction with the MultiPaaS web site. And, surprisingly, once I used it for a little while, Objective-C turned out to not be so bad. There were many parts that frustrated me, such as the bracket notation and the lack of true encapsulation, but overall it wasn't bad. After all, it's just another programming language, and they all have their warts.

To elaborate a bit on the interaction with MultiPaaS, there were a couple of parts that I needed to work with. First, MultiPaaS is built on Google Web Toolkit (GWT) for its browser-based view and all of the remote calls with the server. That remote protocol is rather complex and not something I really wanted to reproduce within iPhone. However, I wanted to be able to reuse the methods that were exposed. Therefore, I decided to change the base class for the RPC implementations to provide a REST-based API as well. This proved to work out really well, especially since I already had a generic method to generate and parse XML for Java objects. The worst part was reproducing the Java beans in the iPhone app — now I have two copies of the same classes. Then I needed a way to convert from XML to Objective-C classes, and that's not something I found on the internet.

In addition, I didn't want to call MultiPaaS for every UI interaction on the iPhone since that would degrade the user experience considerably. Instead, I wanted to cache all of the data locally. I chose Core Data for this so that I could query the data, update it quickly, and even allow the user to store new coupons within the application's cache. That was also easier than I expected.

After development was complete, it only took a couple of attempts to get it into the App Store. Into, mind you, not approved yet, though hopefully that process doesn't require too much effort. I had already had to go through the hurdle of getting into the App Dev program so that I could test the app on my iPhone, so getting a distribution certificate proved to be fairly painless.

Speaking of getting into the App Dev program, don't try to do so as a Sole Proprietorship. They won't take it, even with a Texas Retail license. In the end, since I don't want to pay for incorporation fees at the moment, I had to put everything under my name. When there's enough interest, we may incorporate, but until then, we've been down that road before, and it's not really fun.

Here are a few screenshots of the upcoming app:


I'll add a link when it's available on the app store.

Symbolic Links are awesome!

OK, so I've known about symbolic links for a long time, but still, they just do the right thing 99% of the time, which is just awesome.

I recently bought a Drobo to store all of the data that has been maintained on our very power-hungry server at home.

This weekend I spent some time copying files from the server, but I also wanted to set up a Time Machine backup of my iMac (which is directly connected to the Drobo). However, I didn't want my own time machine (on the local disk) to take up all the space. I did some searching and found lots of ways to limit the space needed on a networked drive, but nothing much for a local drive. That is, until I found this blog.

The gist is that you need to create a sparse bundle disk image and put it at the root of your Drobo volume. If you don't put it at the root, it just won't work. This is because Time Machine will look for a file named MachineNetworkName_MACaddress.sparsebundle (e.g. mymachinename_a1b2c3d4e5f6.sparsebundle) at the root, and if it doesn't find a sparse bundle with that name which it can mount, it reverts to using the file-based approach of a local drive. Also, the sparse bundle can't be encrypted because then Time Machine can't mount it. What I also found odd is that you can't mount the image and point to it as the Time Machine disk; instead, Time Machine has to be pointed to the Drobo volume.

So, after some trial and error finding out all of the things that won't work, I got the sparse bundle approach to work, and truth be told, it works great. Time Machine mounts the image and backs things up great. I don't know for sure that it will limit the size to what I gave it (1TB), but I'm hoping it will, and it seems like it should given the fact that the image has only 700GB or so free.

But there was this niggling detail I didn't like: the image was at the root of the drive. That's just dumb. I want the image to be somewhere else in the directory structure of the Drobo. I'm anal that way, and I'm ok with that. So, I decided to just check to see if a symbolic link would work. And it did!

For those of you unaware of the power of a symbolic link, it's file in one directory that really just points to another file or directory somewhere else. The beauty is that it can point to a directory on your local system or even a mounted volume. It's brilliant for so many things, especially when you have multiple hierarchies for things. It's similar to a shortcut in Windows, but much more powerful since the applications on your system don't need to know anything about them: the symbolic link just looks like the file it's pointing to. In Finder, these look like Aliases, but that's OK, I know what it is underneath.

Now I can have my Time Machine image in a logical place, and a simple little symbolic link at the root. Still annoying that I need that, but I'll live with it.

Now, if only I'd thought to use symbolic links when setting up my iTunes library against a mounted volume. That would have saved me a ton of time since I now have to point all of those Media share references to a local volume. Maybe a symbolic link in the Volume directory will work. I'll have to try it out.

Reality Sets In

I just finished reading a book of short stories by Stephen King, Just After Sunset. I wouldn’t say they were all short exactly, but definitely shorter than a novel or even a novella, especially one of Stephen King’s.

Anyway, Stephen King definitely has a way of weaving a tale that can make you laugh, cry, and scare you at the same time.

I’m not a huge fan of the horror genre, or even fantasy in general (though I did love Tigana, but I’ll have to cover that at a different time), but I’m always a fan of a story that makes me think. It is rare for him to fail to make me think. It may be something as simple as a character byplay that excites the anthropologist in me. Or a riddle contest with an intelligent machine to pique my scientific mind. Whatever it is, he just seems to pick the right words for the occasion.

The word of his I’m fixated on at the moment is “thinness”. He has an idea that sometimes reality is a bit thin in parts. And it makes a lot of sense. How often have we just gone through the day, or even just a drive to or from work that you don’t remember — because you were in another world. But not really, right? But what is real. I don’t mean in the the existential sense, but rather in the conscious sense. Your reality is your own perception, and when your mind is in another place — not on the task at hand — you, the essence of you, are not doing the task at hand. Oh sure, your body is, but you — and the consciousness that defines you — aren’t.

The world around us defines a basic reality, and everybody experiences the same world. However, not everybody experiences that world in the same way. Our brain fools us a lot of the time. It’s really great at filling in any missing gaps. If we had to pay attention to every single pixel of our visual input, every frequency change of our auditory system, or the nerves on just the tips of our fingers — much less all of our skin — we’d get nothing meaningful done. So, our brain cuts down on the noise, breaks down the important things, and gives us a movie to watch.

There’s a hell of a lot more going on around us than our conscious mind can see, so for us, our conscious reality is thin. If we think of it as bandwidth, we have a pretty high bandwidth of sensory input, but our consciousness — the movie-watcher — gets only a tinny picture. Its bandwidth is thinner.

Now imagine a world where the picture and sound start out with limited bandwidth. It’s really not hard to imagine: watch a VCR tape or some old Super-8 film. It’s amazing what we used to live with, when today we have the Flip HD camcorder that fits in the palm of your hand and can store up to 120 minutes of 720p video. The resolution gets higher, so our mind doesn’t have to fill in so many gaps. The picture inside our head gets thicker and richer and more real.

This is especially true as our devices get better as well. The iPhone brought a very high resolution screen to a small device. This doesn’t seem like it makes much of a difference, especially when our fingers aren’t getting any smaller, so it’s not like we can fit more on the screen, no matter what the resolution. Plus, a better resolution doesn’t mean you can make the type smaller – then people can’t read it! But what a better resolution can do is make the experience feel better. This is because even if we wouldn’t be able to read smaller type, our eyes can pick up subtleties that our conscious brain doesn’t even notice. Again, it means that our brain doesn’t have to fill in as many gaps, so we don’t have to concentrate so hard on the details.

I was really hoping the iPad would make a big leap in the experience of computing on a handheld device. But the resolution just isn’t there. They should cram more pixels in to make a 3D-like interface really feel awesome, even if you can’t do anything more with those pixels than eye candy. It’s the richness – the thickness – of the experience that matters. Apple usually gets this, but I think they’ve pushed it out a bit early.

One more observation and then I’ll shut up. If you listen to music today and compare it with the past, it seems much more there than before. Part of it may be the media, but a lot of us listen to music on MP3 players that don’t have the digital clarity of a CD. A lot of it has to do with style – the Beatles have a different sound than bands today. But even the simpler sounds of today are richer. Even more of that has to do with audio equalization – the soft and loud parts of the song are equalized more closely together. Some people say that it muddles the sound, but our ears and brains can distinguish very slight variations in amplitude, and it does so even better when there isn’t a really loud sound next to a really soft sound. Therefore, to our ears, it is a richer experience.

With a richer experience from a richer input – visual, aural, tactile – comes a reality that is experienced in a richer way by our conscious brain, especially when the original was recorded months or years before and all we have to begin with is a reproduction. When much of our life is spent working at a computer, watching television and movies, or chatting on the phone with family and friends, the better we can make those experiences, the better our reality is.

A long time ago, we spent a lot of time in reality – working fields and hunting for food, communicating with our loved ones face-to-face. Now, most of our time is spent with the virtual systems we have in place. Once we make those systems good enough, reality will truly set in.

Consumer/Producer

My how times change. It's been forever since I've sat down and written anything much longer than 140 characters. Even if it's just to introduce a video or pictures of my son, it's still not very long.

I'm going to remedy that. I've been in consume mode for far too long, it's time for me to produce.

Article: Why Do Men Have Nipples?

Why Do Men Have Nipples? Good question! A NY doctor, Billy Goldberg, has decided to answer that question and more in a book with the above title, subtitled "Hundred of Questions You'd Only Ask a Doctor After Your Third Martini." I would love this book. Some of the questions are probably quite silly, but that's ok.

When I was a kid, I used to ask too many Why? questions, so my folks bought me the book, Why Things Are, probably so I would stop asking them. That book is now a bit outdated, but it's still cool. Ever since, I've loved reading about random stuff; the mind, biology, nature, etc.

Article: Has the notebook-to-handheld conversion begun?

Has the notebook-to-handheld conversion begun? Boy, don't I wish!

Apparently some senior executives are starting to trade in their laptops for a desktop and a smart handheld device, a la Pocket PC. Since most senior execs don't do much except read e-mail and talk to each other, I guess that works for them. I'd be hard-pressed to show up at a client site and start coding on my phone. Talk about your reality check ("How big is that screen anyway, 300x400?")

However, if they give me VR goggles, light-based keyboards and VR gloves, I might think about it. At least with goggles you can get 1024x768...of course, they're a fortune, but hey, who's counting costs here? Seriously, though, the input and visual components are what need the most work.

I think technology will eventually get there. I remember when my dad bought his first PC, and it had less processing power and RAM than my phone now has. And that was only about 15 years ago.