I just came across a post that the author had found when he came across some interview questions. I remember when they were all the rage in the early to mid 90’s. I’ve had them asked to me as well as the Kobayashi Maru type. The thing is, I don’t personally find them valuable in determining the suitability of a candidate. A history of shipping products, a general grasp of programming languages, and the ability to fit into the style of the team have always been enough for me to figure out if someone will be successful. Maybe I’ve just never been at a company where the puzzle type questions are an indicator of a quality hire. I’ve always worked on applications and not platforms, so maybe platform companies feel differently.

The next time I’m on the receiving end of a puzzle question I will consider asking the interviewer what he/she hopes to learn about me from the question. I’m not militant enough about those questions to end the interview, but I harbor a secret fantasy where I stand up, say, “I’m not a good fit for a team that asks puzzle questions,” and proceed to end the interview.

I was a big fan of O’Reilly’s “Ebook Deal of the Day.” O’Reilly would pick an ebook from their catalog and sell it for $9.99 for the day. It was a great way to entice me to buy an ebook (I bought 4 or 5), it also trained me that a good deal on an ebook is $9.99. Now O’Reilly has changed their daily deal to typically be a 50% discount. Since the change I’ve bought zero of the deals and find it highly unlikely that I will in the future. This partially due to my perception that these deals aren’t so great anymore, but it really comes down to the fact that few O’Reilly ebooks are worth more than $9.99 to me.

O’Reilly used to be the goto name for technical books. Now I go first to the Pragmatic Programmers and Apress. O’Reilly puts out the encyclopedic overviews of a technology. The other two are more focused on using the technologies in practice. O’Reilly books don’t offer me more than concepts and big ideas that are quite easy to find on the web. The Pragmatic Programmers and Apress walk you through projects and techniques, some of which you may be able to find with some digging, but which work better when gathered and presented in a cohesive way.

I still follow the O’Reilly “Ebook Deal of the Day” imaging that one of the books will be a must-have, but I’m much more diligent about checking Apress’s Deal of the Day or informIT’s.

Fred Wilson is a well known venture capitalist who coined the term “Freemium” which is a business model where you offer basic services for free and make money through selling advanced services. His latest post is how Android will own the market in a few years because of its low price point.

I don’t follow VC blogs anymore because I have no interest in venture backed startups, but there is something very interesting in the comments for independent software developers in the mobile space. When talking about making money in the Android ecosystem here is Fred Wilson’s response:

we are not talking about selling software here

we are talking about web services, which are largely monetized with advertising

The takeaway is that if you want to sell software then the Android space is not the place to be. Building a company by selling software requires organic growth. This is antithetical to the current climate of VC business models. The current model is that you need a large and ever expanding user base with the potential for monetization (Facebook, YouTube, Skype, Flikr, del.icio.us). That monetization may never occur (YouTube, Skype, Flikr, del.icio.us), but the potential is there. You sell that potential to Google, Microsoft, or someone else with deep pockets and that’s where the VC and founders make their money. The business for the VC was in monetizing the company transaction not an actual product or service.

Hey, if that’s the way you want to play, I have no qualms. I’m just trying to highlight to developers and people interested in selling software on mobile devices that the iOS and Android ecosystems are two different beasts. If you want to develop a high quality app that you can charge money for, then you’ll have more success on iOS. If your application or service is geared more towards a free app with advertising then you’ll probably find more success on Android.

Just before I left work yesterday, I got an email with my acceptance to the Google App Inventor Beta. I was pretty excited because I have an idea for a very basic app that I want to release for iOS and Android so I can compare market sizes, downloads, propensity to purchase, etc. I’ve hesitated starting any Android development, because I work enough in Java at my bill paying job, and I saw that UIs are built using XML. App Inventor looked like it might be the ticket. You get to drag UI elements onto a workspace and then add behaviors to them. These behaviors aren’t added with code, but with visual elements. The app I intended to build at its core is a list of audio files and when you click one it plays. I figured this would be in App Inventors sweet spot.

Setup and Installation

The first instructions is make sure you have Java 6 installed and configure to run in the browser on the Mac. I hadn’t looked at the Java Preferences in a while so I didn’t realize some of the configurations existed but this wasn’t problematic. Google nicely has a page that verifies you have things setup properly. Next you have to have Java Web Start setup properly and again they have a nice page to help you verify the setup. Now my Mac is good to go.

Next were the instructions on to how to setup my phone for development. I was a little worried that I might be required to have my phone around for development, but I later came to find that there is an emulator included. I didn’t find this out until after my experiment but it didn’t really affect my judgement positively or negatively.

Web App for App Development

Now I’m off to make my first app and whoa, I am presented with a web app. This makes sense as this is Google, but this makes no sense to me because that means I am now required to be connected to the Internet to do development. I know I am connected to the Internet a large percentage of the time, but I have a productivity trick where I turn off wi-fi so I’m not distracted by email, Facebook, Twitter, et al. App Inventor prevents me from ever using this trick or going anywhere without an Internet connection to development work. Big swinging strike one.

The web app portion of App Inventor allows you to place UI elements like buttons, images, labels, etc. and to import content like audio and image files. Since I need to make a list of items I went looking for a UI element that would display a list. There is no list view element. The closest thing is a “ListPicker” that, when clicked on, displays a list of items that you can select from. The supported UI elements don’t lend themselves to making much more than a form submission app. Strike two.

A Second App for Development

After you’ve “designed” your UI you need to hookup the behaviors. This is done by launching the “Blocks Editor” which uses Java Web Start to start a desktop Java application. This is pretty weird, but Apple does the same thing with the current incarnation of its development tools (XCode 4 fixes this) so I can’t ding Google for it. Things get really weird for your typical developer when you find out that you don’t define behaviors with code but with little graphical widgets. You hook up these little blocks to define what happens when you do something like clicking on a button. There are widgets for conditional logic and for defining and setting variables.

I’ll admit it, I was tempted to dismiss this out of hand. I don’t believe in visual programming for serious development. But I stopped myself. The app I’m writing isn’t complicated and should actually be in the sweet spot for visual programming. Check swing.

Experiment in Visual Programming

Since I couldn’t find a proper list, I decided to first try playing a sound with a button. Things would get ugly if I had to use buttons for the final UI, but for getting my feet wet it would do. So I dragged out a button.click block and connected a sound.play block, fired up the app, click on the button, and voila, the sound plays. Then I clicked on the button and while the audio that was playing kept going, it started playing the same sound again. I kept pushing the button to see if I could crash the app, but I just succeeded in making a bunch of noise. Okay my first bug. My first instinct was to pull out the “if then” block and then check to see if the sound was playing before I started playing it again. Well, the “sound” block has no notion of being played, you can play, stop, pause, and resume, but how are you supposed to know which of those to do unless you know the current state of the sound. I looked at some of the documentation and it seemed that I would need to create a global variable (yeah, I should have stepped away as soon as I saw that was a fundamental programming concept) that kept the state of the sound. While I got this to work and did prevent duplicate sounds from being played, because there is no callback mechanism, I couldn’t tell when the sound had stopped playing so while the global variable might say the sound is playing, it could have already stopped playing. Strike three!

Done with App Inventor not with Android

While it was a short-lived experiment, about an hour and a half, I’m happy that Google made it easy for me to fail fast. If I had invested anymore time before running into these limitations I would have been very unhappy. I don’t think I’ll ever bother with App Inventor as I fully expect it to go the way of “Google Wave.” Google likes to do these experiments and see where they go. It seems like the developer loses interest in short order and enhancements rarely come.

I was holding out hope that App Inventor would allow me to keep from diving fully into Android development. But now that illusion has been shattered and I’ve already moved on and downloaded the SDK. Going forward, I plan to continue documenting development and business differences between iOS and Android.

The answer is, of course, no? I won’t bring up the “A” word, but the choice of handset operating system is neither commanded nor prohibited in Scripture. In fact, at the LCMS National Convention I ran into plenty of pastors with Android phones. And, yes, even I, a qualified “Apple Fanboy” have an Android phone (HTC Hero).

So why aren’t Concordia Publishing House (CPH) and others (myself included) writing apps for the Android? I’ve seen plenty of requests on FaceBook and Twitter asking for apps to be written for Android. So there is most certainly a need to be filled. Well, I won’t presume to speak for CPH, but I think I can shed some light on their thought processes as I explain my rationales.

Allocation of Resources

Every developer has a limited number of resources so has to decide what platform(s) to develop for. In the case of iOS vs Android the installed base of iOS devices more than doubles Android devices in the US and is almost 4x the number worldwide (intomobile). In addition to that, amount people spend on iOS apps dwarfs what people spend on Android apps (GigaOm). Based on these simple numbers it’s quite easy to choose what platform to develop for.

Ease of Development

I’ve done some cursory research into Android development and it is not very developer friendly at this point. UI layout is done in XML (text) files. Just think of trying to arrange your living room furniture by writing down the coordinates of your sofa, TV, etc. Also the number of widgets available for free is rather limited. Think wood crate furniture with anything more sophisticated needing to be hand crafted. The current state of Android development is like stuff I was doing 10+ years ago.

Things are Changing

But Android has some positives. It is gaining is popularity and had greater unit shipments than the iPhone in Q2 2010 (ZDNet) and App Inventor and Google’s developer friendliness will surely make the development situation better.

Somethings Won’t

That being said, Google is unlikely to do anything that would improve the market for apps. Why? Because Google isn’t in the business of selling apps, Google is in the business of selling ads. They want apps to embed ads as the mechanism for monetization. Additionally, Google hasn’t been able to address piracy on Android devices (AndroidHeadlines). They actually don’t have any incentives to put much effort in anti-piracy. If piracy is rampant, then the only way for developers to make money is to embed ads.

Like I said, I won’t presume to speak for CPH, but it is quite clear to me that now and into the near future developing for the iOS is the platform to develop for if you have limited resources and want to try to make money by selling your apps.

I would like to see a lot more iPhone apps that entertain, encourage, and educate from a confessional perspective. To that end, I would like to encourage anyone who’s interested to start developing some apps and I’d be willing to help to the best of my abilities. One book I can recommend on the subject that I just finished reading is Tapworthy: Designing Great iPhone Apps. It’s not an iPhone programming book, it’s about how to design the look and feel of and interaction with an iPhone app. It’s the first technical book I’ve read from cover-to-cover in a while.

I read an article on the state of testing in Cocoa. The author, Alex Vollmer, paints a pretty dismal picture of BDD in Cocoa community and I’d have to agree with him. In my decision to use Ruby over Python for my web apps, I mentioned that BDD (Cucumber and RSpec) and the Ruby testing culture was a major reason I went with Ruby. I would really love to see that aspect come over to the Cocoa community. Alex believes that snobbery and elitism are dominant attitudes that prevent the community from adopting testing practices from other environments. I haven’t dealt with the Cocoa community at large, so I can’t comment on the snobbery and elitism, but I do know that XCode and the various Cocoa frameworks didn’t grow up in a BDD world and the fact that the community didn’t grow up with BDD, like Ruby and Rails, makes it a lot harder to inject.

I know there’s been some work to use Cucumber with the Simulator, but that requires you to drop out of Xcode. I’ve gone down this path before, I don’t want to switch between editors and shells for my development environment. I want to see Cucumber and RSpec equivalents that can be run from within XCode. For me, it was running those two in combination while going through The RSpec Book that was my aha moment for BDD and I think it would be the same for the entire Cocoa community.

While tracking down a memory leak in my latest app, which looks to be a known problem with the simulator, I ran into someone suggestion to run the “Build and Analyze” (B&A) command from the Build menu in Xcode. Being an Xcode novice, I had never tried this before. Well, I would just like to thank Apple for including this feature because it helped me to fix an intermittent crashing problem, better understand Objective-C reference counting, clean up my code, and just have a better sense of satisfaction about my code.

Coming from the Java world, B&A seems to be a lot like Coverity which can do static analysis on your code except B&A is a lot faster. I’m not sure how often I’ll run B&A, but it seems like a good idea to clean the project and run B&A after every feature and/or major code restructuring. If you’re not already using B&A regularly I highly recommend you do so.

If you’re a tech person, you probably have and buy lots of books. Since getting the iPad, I’ve been buying more eBooks if they are priced reasonably. Reasonably to me means they are less expensive than their paper counterparts as I can sell the paper version if it isn’t up to snuff or I no longer need it. I subscribe to O’Reilly’s eBook of the day feed to get a daily $9.99 special.  These are typically good books, but not in an area in which I’m interested (Windows, Apache, Mathematica, etc). But today’s deal is $9.99 for any eBook. I had a little trouble finding a title that I really wanted, but decided on Version Control with Git. So if you’re into eBooks or want to try one out at a reasonable price, head on over to O’Reilly’s website.

I saw that Google annouced Google TV. The idea of searching my recorded shows and other sources to find programs to watch is kind of interesting except I have enough trouble keeping track of the 2 remotes and now I have to keep a keyboard laying around to watch TV? The final pitch was an integrated full browser where you could check the web and update your status. So this was the kiss of death in my mind. TV is a common experience and the web is an individual one. If I try to update my status on the TV while my wife is watching American Idol I’m a deadman. That’s how TV works at our house. We have one TV and we watch it as a family.

But I’m starting to wonder if we are an outlier. I mean I’ve heard of people that have no TV’s and they certainly are unusual, but could the 1 TV family be almost as rare? If the TV is a personal device, then Google TV has a shot. If TV is still a shared experience, then it’ll suffer the same fate as WebTV and similar attempts at combining the TV and the Internet.