Appropriate ness (part deux)

I recently did a design review where there was an issue surrounding their choice of 'data storage implementation'. I use quotes because to me as a web developer, any data belongs in a database.

The issue arose over the fact that for this application written for the Java environment, they didn't need to store anything but usernames and passwords. They planned on using JDBC and having just one users table.

Like I said -- all well and good by me. I'm more used to having more tables and more relations between my data, but again it seemed most natural to me.

The surprise came when someone suggested that they just use a plain text file. If they were only going to store limited amounts of data and very very limited associations, why not just plain text?

Maybe this seems obvious to those who have had this experience before (or more than once), but it seemed so obvious to me that it was obscured. After the fact, it was indeed the right choice. Case to point: 1) Java has built in I/O operations 2) Their I/O operations would not (conceivably) cause any buildup and (most importantly) 3) JDBC is yet another thing to implement and (potentially) cause errors in their system.

Call me crazy but that Occam's Razor is either a natural talent or a life-long quest. For me it seems the latter.

So here's to other people's insightful (yet sometimes humiliating) comments that make our lives that much less complicated.

Appropriate ness (Appropriation?)

I recently did a constraint-satisfaction problem (CSP) in LISP to solve sudoku puzzles. I finally was able to visualize the recursive pattern and (to me) it looked alot like the stock market circa 1998-2005 -- up-down-up-down-down-up-up-down-down-down-down-up-up-down-up-up...

This actually reminded me of Matt Zandstra's book PHP 5 Objects, Patterns, and Practice. I read this at a time in my life where I had (naively) written an architecture for a system (in PHP5) which was quickly becoming unmanageable. This book helped me collect my thoughts about how to re-collect my code.

One of the things that I found very interesting which had never blipped on my radar was the idea of the appropriate throwing, catching, handling, and re-throwing of exceptions. Matt Zandstra emphasized that exceptions are powerful error-recovery tools -- but that they need to be handled at the appropriate level in your application: that model-level exceptions must be caught and handled (hopefully recovered) in the model and -- only when necessary -- passed controller. Heaven forbid if they propagate to the view.

Chris Snyder's book Essential PHP Security chimes in with the idea that often errors which occur at lower levels can cause security breaches. How many sites have you visited that have said "Cannot select `id` from table `users` with value ....". So if i just tweak this input-field...

So think about exceptions and their course through your application -- are there some which are relevant only to the model? Or are some worthy of propagating all the way up to your controller? Who owns that exception? Where does the buck stop?