Author Archives: Jeanne Boyarsky

my iPad in $10 and 10 days

Posted on by
Reply

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.

dbunit vs recreate schema

Posted on by
Reply

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();
setUp(args);
long end = System.currentTimeMillis();
System.out.println();
System.out.println("Done setting up database in " + (end - start) + "ms.  Now running tests.");
System.out.println();
JUnitCore.main("com.javaranch.test.functional.All_JForum_Functional_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

Conclusion
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!

GET vs POST and URL security

Posted on by
3

Is GET or POST more secure?  Like many things in computers, it depends!

Who are you trying to secure data against?

  1. The user in his/her browser
  2. People who legitimately see the URL
  3. Hackers

The user in his/her browser
This is the case that is usually discussed.   Some people will naively say they want to “secure” the data by using POST.  That way the user “can’t change the submitted data.”  Of course, this hooey.  Anything on the user’s machine is something the user can see/change.

People who legitimately see the URL
Many people have access to the URL such as in logs.  Having sensitive information in the URLs is a bad idea.  This actually happened recently at JavaRanch.  A user started a thread inquiring about a thread that linked to his but he couldn’t see the protected page.   At JavaRanch, as on many blogs, URLs look like “http://www.coderanch.com/t/493907/Ranch-Office/Could-anyone-enlighten-me-please”.  Luckily we had taken a precaution and used a shorter form of the URL for our private forum.  Otherwise information could leak out!

Similarly, social security numbers and other sensitive information should not be in a GET form submission because the information is then out of your control.  If at all possible, they should be kept on the server and never sent to the user’s machine in the first place.

Hackers
Hackers are a harder case because the hacking can be in multiple places.  For truly secure information, you have to use HTTPS.  For “medium” information, POST is still better than GET because URLs are easier to intercept than whole pages.

Conclusion

As a rule of thumb, POST is going to always be more secure than GET because it removes the “data in the URL” issue.  For some things, neither is secure enough.