Now that I’m starting a new iOS development project, I’m trying to have close-to-complete test coverage of critical parts of my code. I’m using XCTest pretty extensively, and found that I needed to test a rather complicated private method that is critical to my app’s user experience. This post shows you how I did it.
I love word games. I’ve played Scrabble on my iPhone more than 1200 times. Then, a couple of weeks ago they changed their user interface. Now I’m afraid I’ll never play it again. In this post I’ll tell you what I don’t like about the changes, and how I plan to avoid similarly alienating users of my own apps.
Happy with my experience with a custom WordPress installation for this blog, I decided to try using the blogging platform for the TaskForest website. The two main reasons were the ease of creating RSS feeds and the ability for users to comment on posts or articles. After a few days of tinkering around, I’ve come to the conclusion that, at least for TaskForest, WordPress would cause more problems than it would solve. Here’s how I came to that conclusion:
The #grid website has a great tool for web designers -it “inserts a layout grid in web pages, allows you to hold it in place, and toggle between displaying it in the foreground or background.” Go to their website and have a look. It’s pretty impressive. Simple, but impressive. I think I’m gonna give this a shot for the next web site I design. I think it would be really useful in development, not as much in a production environment.
In yesterday’s article about Google Buzz, I guessed that “the problem was that the population for whom the system was designed wasn’t necessarily the only population actually using the system.” I gave Google the benefit of the doubt:
I am certain Google tested their application thoroughly. They’ve been known to do extensive usability tests for the seemingly tiniest of changes to their web site. But even the most well-implemented tests are incomplete if they’re not performed on a statistically representative sample of the audience.
But today, the BBC reported that Google has admitted that they only tested Buzz internally, and bypassed their regular rigorous testing procedures — possibly in an attempt to get it out the door as soon as possible. I’ll let the pundits decide if it did more harm than good to the firm, but it’s a warning to other software developers: skipping testing can lead to embarrassing failures.
In the first few days after the release of Google Buzz many people (including myself) criticized Google for exposing their users’ private information. This was a couple of weeks after Apple got a lot flak for their unfortunately-named iPad, and the same week that we heard reports of a woman who broke up with her boyfriend after finding some suggestive text messages on his cell phone - messages that came pre-loaded on the phone. I think that all these cases were not caused by a lack testing, but by testing the wrong audience. Let’s examine these three cases and see what we can learn from them:
I came across some comments made about an open source program that I had written in perl. The user was complaining about how he couldn’t get it to install. The reason was that the program relies on other modules from the archive of open source perl software known as CPAN (Comprehensive Perl Archive Network), and one of them failed to install.