Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chaoticset (2105)

  (email not shown publicly)
AOL IM: chaoticset23 (Add Buddy, Send Message)
Yahoo! ID: illuminatus_foil (Add User, Send Message)

JAPH. (That's right -- I'm not Really Inexperienced any more.)

I'm not just here, I'm here [], and here [] too, I ramble randomly in my philosophical blog [] and my other blog []. Soon I'll come in a convenient six-pack.

Journal of chaoticset (2105)

Saturday November 10, 2001
03:41 PM

Design Flaw

[ #1228 ]
I have been working under the assumption that I'm essentially living a lie. I have been working under the assumption that there is a huge general consensus about how to design a program, and I didn't know it, and therefore that made me less qualified to write this cart script.

In order to edify myself and gain some sort of working knowledge of what I was doing, I made a trip to Borders today and hunkered down with six or seven books that purported to be about software design.

They were, mostly, but what shocked me was that there are actually SEVERAL apparent consensuses...consenses...consensi? Whatever. Each one listed several different approaches, explaining vectors, etc., in a way that made my eyes and head hurt.

Except the ones on XP, which I found fairly readable. Oddly enough, I realize that what I'm doing roughly approximates it already, minus the 'design' step. (I have been charged with not considering design before, and I'm guilty.) This time around, with my database of functions, I have a rough idea of what's in each thingy and what it'll do.

I had already been using constant test cases. (I made sure my data for the stock file creator had a few cases of everything in it, so as to show me what was broken if there was anything.) I don't have anybody to program *with*, so it's certainly not XP...but that's not the point.

Validation is a thing humans seek out from time to time. Validation, in terms of your actions and how you're undertaking them, usually isn't available; sometimes, the next best thing is to find someone who does know what to do and how, and get their advice.

The NEXT best step is to find out that there's very little validation out there, and people pretty much just figure out what and how the hard way and try to learn from the last time.

I guess this falls into the last category; there's not any great consensus on it, so it won't be a huge problem if I just do it the way it works, and try to improve how I do it.

I came in fully hoping to spend $30 on a book that gave me basic principles of software design.

I came out with a bottle of their caramel syrup, the stuff that makes the caramel mocha coffee there so caramel-y. It was around $9. It was worth every penny, and it's helped immensely.

Oh, and I have a reason I'm here, too.

I started putting the code together. (Maybe I should point this out to myself in the future: Iterate through a little design, a little code, a little spent several days designing decent functions, and figuring how the program will mesh, but you don't know if those functions will run...and you need to find out. Then more design, to clean up those holes in your code (notably the table-builder, which has been blank since I started the database).)

I figure it'll be complete enough for a test run through Apache by the end of the day. (Good thing, too, because the SO is going to be hungering for the machine by then.)

More when that happens.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.