my iPad in $10 and 10 days

I’ve now had my iPad for 10 days and spent $10 setting it up to be functional.  Or $610 if you count the iPad itself and the case.

Why I bought the iPad

I wanted to be able to read technical documents from the park.  The files could be PDFs, ZIP or HTML.  I will have many other uses for it as time goes on.  And already have – like checking my twitter and my e-mail from the couch!  My experiences so far have been mostly around being able to accomplish the original goal though.

What applications I downloaded right away

  1. GoodReader $0.99 – A much better PDF reader than the built in one.  Turning pages is harder than it needs to be, but the GoodReader team is working on a fix.
  2. iUnarchive $2.99 – To unzip files.  Works exactly as one would expect.
  3. DropBox free – A great way to get files from your computer to the iPad.  Just drop them in a folder on “main computer” and download from the iPad.  Only trick is to remember to choose as favorite so available offline on the iPad.
  4. Twitterrific $4.99 (ad supported version is free) – Twitter client.  The cute tweet noise for new tweets will get old fast.  I’ll turn that off once I get tired of it’s cuteness.

Total – $9.76

Thanks to my friends at JavaRanch for recommending these (and more applications) to greatly cut down on research time.

What I learned

A few “less than obvious” things I learned in the first 10 days:

  • Double tap to see menu when GoodReader in full screen mode
  • I still need to figure how to take notes while reading

Other setup

I was surprised by how little setup I had to do to get up and running.  I was able to create my iTunes account and activate in the Apple store so I didn’t need to waste time downloading it at home.  The only setting change I made was to password protect the iPad.

Speaking of the Apple store, it was a little odd that on Wednesday they told me there was a wait list and they couldn’t possibly estimate how long it was.  (implying weeks/months.)  The following day, I got a call my iPad was there.

Finally – my impressions

  1. The iPad is great.  It lets me read PDFs and zip files of text or Java code outside away from my laptop.  (It’s awkward using a laptop outside.)  I had no problem reading outside.  Even in the sun, I used the iPad case as a sun visor to protect the screen.
  2. I still need to find out if there is a way to easily take notes while reading.  Not just PDFs, but any application.  It’s a pain when looking at a zipped file because it doesn’t retain where you are when you get back.  I’ve resorted to paper.
  3. I haven’t missed the 3g I decided not to get one bit.  A surprisingly large number of places have free wifi.  And DropBox caches my documents for offline use very well.
  4. I can touch type alphabetic text on the iPad!  I type about twice as slow on the iPad than on a real computer.  But that’s much better than my hunt and peck speed!
  5. Special characters like the pipe are hidden well.  To get to them, you have to choose the numeric keyboard (obvious) and then the “#+=” button (not obvious)
  6. I have a lot more to explore.  I am happy with the iPad meeting my initial purposes and looking forward to it meeting even more.

Apple should Develop a Flash Compiler

One interesting solution to the continuing public battle between Apple and Adobe over Flash support on its mobile platform would be for Apple to release its own Flash compiler, one that would allow a developer to create Flash applications without ever purchasing an Adobe product. Before you laugh, hear me out.

Neither company is open
What bothers me about the whole public fiasco is that both companies have been arguing that they support open formats – Apple in its preference for HTML5 and Adobe in its desire to publish its own applications freely to the iPhone – while both basing their own technology on extremely proprietary and closed formats, as seen in Apple’s recent closing of the iPhone and Adobe’s tight control of its Flash product.

The truth is, neither company wants their products opened for the world to use, but both companies demand the other open their platform. If Adobe was really serious about Flash as a ubiquitous platform, then they should donate Flash to a standards community that would open it to the world. Likewise, if Apple wanted anyone in the world to be able to develop on the iPhone, they would have created it as such and declared it an open standard.

Unfortunately, I agree with Apple
While I personally would love to develop iPhone applications using Adobe’s Flash-to-iPhone compiler (I really would!), I fully support Apple’s right to close the platform. Above all else, mobile platforms must be secure and Adobe’s iPhone compiler seriously threatens that security. The iPhone, like many other mobile platforms, is not open for the world to develop on, nor should it be.

There are many whispers that the government is investigating anti-trust violations over Apple’s blocking of Adobe’s iPhone compiler, but that would be ridiculous, since Apple does not have a monopoly on smart phones. In fact, the Android recently surpassed the iPhone in sales, leaving Apple in third place among smart phone manufacturers. Apple would have to be in first place with a clear monopoly on the market before I would support any government intervention telling Apple what it can and cannot do with its mobile platform.

Apple’s Flash Compiler
Since Adobe believes it has the right to freely develop on the iPhone while at the same time arguing Flash should be supported everywhere, one interesting twist would be for Apple to develop its own Flash compiler and even run-time. That would very likely upset Adobe and lead to a very interesting argument over proprietary platforms. Adobe could claim only they have the right to develop Flash applications, something Apple currently asserts over its iPhone application. On the other hand, Apple could claim that if the Flash platform is everywhere then it should be open for anyone to develop applications on, something Adobe likewise states about the iPhone platform.

And as an added bonus, Apple could develop this compiler as an iPad/iPhone application!

dbunit vs recreate schema

As I continue looking at writing integration tests for the back end of JavaRanch’s JForum install, I faced the decision of how to guarantee a clean database.  A previous post on the topic covers how to clone a postgresql database via the command line.

I was originally thinking about using dbUnit to import data.  I may still do that if I find myself needing a lot of data.  However, I realized it was more important to be able to recreate the table structure each time.  Our database schema changes regularly as we enhance tables and I don’t want people to have to update the exported dataset. The concept is to have the test create the schema/tables/data from scratch each time it runs.

Some interesting things in this infrastructure:

  1. JUnit suite wide setup – I had so much to say on this topic that I wrote a separate blog post on it.
  2. Main method – The main method is interesting because it provides the starting point. It sets up the database (more on that later) and kicks off all the JUnit tests. It uses the JUnit runner to benefit from JUnit’s reporting mechanism. I also added logging for the database setup in case it took a long time on someone’s machine. This turned out not to be a problem. At the moment, I’m leaving it “just in case.”
    public static void main(String[] args) throws Exception {
    long start = System.currentTimeMillis();
    long end = System.currentTimeMillis();
    System.out.println("Done setting up database in " + (end - start) + "ms.  Now running tests.");
  3. Pointing to a test database– Many developers, including myself, have test data in their “jforum” database and wouldn’t appreciate the integration tests mucking around with it. As a result, the integration tests use a special “jforum_integration_test” database. This database has its schema recreated each run of the test. Conveniently, JForum has a property for the database name that all the code uses. Having the code update this in setup is sufficient.
    SystemGlobals.setValue(ConfigKeys.DATABASE_CONNECTION_DBNAME, "jforum_integration_test");
  4. Tear down first
    A common pattern when integration testing is to call tear down before setup. Tear down drops the “public” schema. (which is where postgresql stores everything) Setup creates the schema and loads the DDL/SQL. This is done in a DatabaseController class to keep the All_XXX_Tests class uncluttered. For example:

    conn.prepareStatement("DROP SCHEMA public CASCADE;");
  5. Running a DDL file – This is a blog entry in and of itself. Which is good because I made it on

I’ve been using this test structure for a couple weeks now. It has served the purpose well and I expect it to live on. A nice side effect is that we find out very quickly if the DDL is incorrect in SVN!