Friday, March 31, 2006

Football season is starting

Here in the United States of America, football is soccer. Soccer season is starting tomorrow when the Columbus Crew travel to Kansas City.

The Crew were a horrible team last season finishing with one of the worst records in the league (Major League Soccer). The organization replaced the coach mid-season and moved the assistant coach up to interim head coach. Soon after the season ended, the head office hired Sigi Schmidt to take charge as head coach. Sigi's arrival has been met with mostly positive praise and enthusiasm. Some players from the old regime were either traded or waived to make room for some developing players and some existing MLS players.

The game this Saturday should mark the return of goalkeeper Jon Busch to the lineup after a season ending injury last season. Backing up Busch is veteran and quality goalkeeper Johnny Walker and developmental player Bill Gaudette.

In front of Busch will be returning starters Chad Marshall and Frankie Hejduk and host of newcomers like Marcos Gonzalez, Rusty Pierce (MLS veteran), Tim Ward and Joel Kitamirike. Defenders Robin Fraser and the often-injured Stephen Herdsman retired.

The Columbus midfield and forward were probably the areas in most need of work from the 2005 season. Gone are defensive midfielder Simon Elliot, left siders David Testo and Chris Wingert, the aging but still potent Chris Henderson, the off-and-on Mario Rodriguez, and contributing forwards Cornell Glen and Edson Buddle. Returning are Kyle Martino (this might be a make or break season for him), promising young talents Eric Vasquez and Danny Szetela, and forwards Knox Cameron and John Wolyniec. Midfield improvements came in the form of Ritchie Kotschau, senior international Sebastian Rozental then promising youngster and MLS experienced Eddie Gaven (traded for Buddle). Two draft picks fill out the forward spots.

A couple of question marks for the team are the returning utility player Duncan Oughton (still injured and questionable) and Pickerington (central Ohio) native and ex-Crew player Chris Leitch.

There will be a new coach, new starting eleven, and hopefully a new (and championship centered) attitude. Hopefully this will bring some much needed wins to the Columbus soccer team that seems to be stuck in “average” throughout their existence. I have to realize, however, that we are relatively young in some places and there might not be results for the first couple of matches. Most every other team in the league has improved as well (a few seem to have made questionable lineups).

The feeling the in locker room seems to be (and was stated by Jon Busch as) championship, not rebuilding. I can live with rebuilding. Sigi might be a good coach but he likely isn't a miracle worker.

Bring it on. Lets go Crew.

Fun with HTML, CSS and various browsers

So, I'm screwing around with some HTML attempting to determine my preferred way to render forms. I coded the HTML with inline style (all one document). The CSS is version 1 compatible. For text inputs and option selects I tried playing with widths on label tags, putting labels in their own div tag, etc. What seemed to be the most compatible was using the ol'reliable table tag, placing the labels inside th cells and the input/selects inside of td cells. It's a couple of characters more than a div tag, but should render in simple browsers. Radio buttons and check boxes seemed to fit well in ordered lists (with a list-style of none). Textarea tags stand on their own.

I tinkered with the CSS to get things to line up nicely. All sizes (except for borders) use em units.

The first problem I noted was Firefox did not apply formatting to tags inside of a td cell tag. I remember this from the Netscape 4 days back in the age of dinosaurs when I first learned this stuff. To get an element inside a table to format you need to use a selector like form table tr td { formatting; } because any formatting done in the body (like font: small;) must be repeated in the td.

I kept the HTML and CSS as plain and simple as possible; check out the results:

The normal font rendering for Firefox is smaller than IE and Opera's. Also, the 1em; margin on the ul tag seems double the size on Firefox compared to both IE and Opera. Opera renders it's default font much larger than the others. Firefox and IE allow font sizing:

"The nice thing about standards is there are so many to choose from..."

Friday, March 24, 2006

Silence is painful

Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste... Must... not... talk... about... fiscal... waste...

Wednesday, March 22, 2006

Blog of the Dead, still typing...

I now have about forty-six pages of blog entries spanning thirty-nine days for my "Blog of the Dead". The "Blog of the Dead" is a writing project I've been casually working on since December of last year. It is a journal of events wrapped around the George Romero zombie movies; i.e. as if the dead were coming back to life. I think the goal is to get about three "blog" months written before publishing it, giving me a buffer when summer arrives and I really don't feel like writing much anymore. Since the "blog" will parallel our timeline, there will be gaps during summer anyways. Most of the writing is confined to the early days of the event, then a few major events from week to week before things get boring. It's hard to imagine someone like me putting pen to paper to reiterate scarce details about daily life when you and a couple of other people are the only people left on the planet. Survival can be boring.

White doom

A guy in at work had a great line about all the local weather forecasters predicting four to eight inches of white doom (snow). "It seems like the more money they computers the worse they get at telling the weather." This makes reference to other entities that have spent outrageous amounts of money on computers and technology without seeing an improvement in the ability to do one's job. "They have double dual dipshit Doppler and street level bullcrap but they get in wrong every time."

I knew when they were forecasting four to eight inches of snow that central Ohio would be lucky to get a cumulative four to eight inches of snow for the entire months of March (and April).

Personally, I don't give a crap about who has the best Doppler radar or who can zoom in closest to a street. To be blunt, I want to know: roughly what the temperatures are going to be like for the week, when we will be getting precipitation and with the 24 hour range what type of precipitation and how much we will probably get.

A hot weather chick wouldn't hurt either.

Wednesday, March 15, 2006

Journey through the "blog-o-sphere"

Sometimes I get bored at home or work and take a trip through the "blog-o-sphere" starting with this blog then using the next blog button to randomly go about. My latest travels through the "blog-o-sphere" found the following:
  • twelve foreign blogs in languages other than English
  • six spam blogs
  • three blogs with two posts or less, one containing 'hi' and nothing else
  • one female blogger's blog containing pictures of hot, oiled-up men she drools over and wants to make babies for
  • one gay male blog complete with the dude face down on bed with bare ass and nutsack exposed to the world
  • one blog that was CSS and image overkill, almost seizure inducing
  • a "bitch" blog, that was well written and recently active and commented upon
  • last; the blog that uses javascript to kill the blogger toolbar at the top so you can't continue to the next random blog
One readable blog out of over sixty-five...

Sometimes I wonder why in the hell I even bother to publish this blog. I don't need it to keep in touch with friends and relatives; that's what the phone, messenger and eMail are for. I wonder if it is more therapeutic than anything else... Does anybody read my blog? Do I give a s-word if anybody reads my blog? Do I need pictures of hot, oiled-up women that I drool over and want to make babies with? Should I expose my nutsack to the world? Who gives a f-word..?

Friday, March 10, 2006

Woo hoo! 100th post

Figures I would waste the 100th post on humor. Not that there is anything funny about political correctness, but...

How to Speak About Women and be Politically Correct

  1. She is not a BABE or a CHICK - She is a BREASTED AMERICAN.
  2. She is not a SCREAMER or MOANER - She is VOCALLY APPRECIATIVE.
  3. She is not EASY - She is HORIZONTALLY ACCESSIBLE.
  4. She is not DUMB -She is a DETOUR OFF THE INFORMATION SUPERHIGHWAY.
  5. She has not BEEN AROUND - She is a PREVIOUSLY ENJOYED COMPANION.
  6. She is not an AIRHEAD - She is REALITY IMPAIRED.
  7. She does not get DRUNK or TIPSY - She gets CHEMICALLY INCONVENIENCED.
  8. She does not have BREAST IMPLANTS - She is MEDICALLY ENHANCED.
  9. She does not NAG YOU - She becomes VERBALLY REPETITIVE.
  10. She is not a SLUT - She is SEXUALLY EXTROVERTED.
  11. She does not have MAJOR LEAGUE HOOTERS -She is PECTORALLY SUPERIOR.
  12. She is not a TWO-BIT WHORE - She is a LOW COST PROVIDER.

How to Speak About Men and be Politically Correct

  1. He does not have a BEER GUT - He has developed a LIQUID GRAIN STORAGE FACILITY.
  2. He is not a BAD DANCER - He is OVERLY CAUCASIAN.
  3. He does not GET LOST ALL THE TIME - He INVESTIGATES ALTERNATIVE DESTINATIONS.
  4. He is not BALDING - He is in FOLLICLE REGRESSION.
  5. He is not a CRADLE ROBBER - He prefers GENERATIONALLY DIFFERENTIAL RELATIONSHIPS
  6. He does not get FALLING-DOWN DRUNK - He becomes ACCIDENTALLY HORIZONTAL.
  7. He does not act like a TOTAL ASS - He develops a case of RECTAL-CRANIAL INVERSION.
  8. He is not a MALE CHAUVINIST PIG - He has SWINE EMPATHY.
  9. He is not afraid of COMMITMENT - He is MONOGAMOUSLY CHALLENGED
  10. He is not HORNY - He is SEXUALLY FOCUSED.

Thursday, March 09, 2006

PHP and OCI, objective thoughts

I've been playing around with PHP and it's built in functions that use OCI to connect to and retrieve data from Oracle instances. There are (of course) about fifty different ways of going about this depending upon how you break down units of work, determine what goes into an object (if anything), how to best template the rendered output, etc. I decided to logically break code down into four logical sections (for specific database code):

  1. connection and global
  2. prepare statements and bind variables
  3. parse, execute and fetch
  4. render

Everything starts with a controller script; the code that initializes global entities, defines functions and classes, and handles session control (probable through one or more require_once() included files) before dispatching requests to other handlers. This "framework" assumes read-only querying of data using one or more query executions.

Connection and Global

Database connection code can be moved into a separate include_once() file. This file would set connection and schema variables as global variables, make the connection, and handle errors for the connection. I create empty named (associative) arrays for bind variables and result sets and make both global.

Prepare Statements and Bind Variables

The controller script would set up bind variable values in the global named array. Since a single controller can fetch numerous data models and render multiple views they are built into a named array. This named array will contain the script name (also used as a value in the result set named array), the SQL statement, and a comma delimited list of variables that need bound. Data models can be split into separate include_once() files if necessary.

Parse, Execute and Fetch

For each item in the named array created in the last step, execute an oci_parse() followed by oci_bind_by_name() for each bind variable. Once parsed and bound, oci_execute() and if successful, oci_fetch_all() into the named result set array. Since this block of code would be reused by numerous controllers (like the connection code), move it into a separate include_once() file.

Render

At this point we assume all SQL scripts have executed successfully and all resulting rows have been fetched into the result set named array. At this point the controller can delegate processing to a main view script (template) and additional view rendering script. This code is independent of database work but needs to be mentioned.

Some might notice there are no "objects" in use here (yet). The named arrays could be considered "cheating" around use of objects. Theoretically I could make each "query" or "request" an object; create an array of objects instead of a named array inside of an array. Then again, I could create a "transaction" class that would handle the multiple instances of the requests. Or should I create a "database" class, partner it with the "transaction" class that contains multiple "request" instances?

This is one of the things that drives me nuts about object oriented programming. As a "legacy" computer geek I grew up programming linear BASIC and machine code on a Commodore 64. I moved on to other various assembly code on different processors before graduating to "legacy" coding in COBOL and mainframe assembler. My life was linear but highly modular code. There are more times than often I wonder to myself what makes object oriented programming more efficient or better than "legacy" coding. Objects seem to have their place where an object can be strictly defined as a complete and independent unit. A text box is a good example of an object; it has specifically defined properties and methods, it's code can be reused and extended - it makes sense to me. When it comes to data objects I start wondering "why".

Using a "student" as an example for a data object; does the "student" object contain numerous objects like a "student ID" object (that contains presentation and validation) or is the "student ID" a property even though a lot of it's code can be used elsewhere beyond a normal "string". Is a student an extension of a base object of "person"; student and faculty have common attributes. Is the data object simply a representation of a table or can it be more than on table with one to one and/or one to many relationships? If it simply a representation of a table then isn't retrieval of a large set of objects horribly inefficient (say for example you need 1000 instances of object x that relate to one or more instances of object y; do you retrieve the set of 1,000 instances then make 1,000 additional requests for related data?).

There are probably a number of people that would disagree with my hard-coding of SQL in my script (or separate file). I have seen data dictionary models built within PHP that are used to dynamically generate SQL. I dislike this approach. Having worked with SQL on all of the major platforms (Oracle, SQL Server, DB2) and other platforms (MySQL, Datacom DB) I have learned there are enough differences in each SQL to make the hand-coding (and tuning) of code worth the time and trouble. In some cases (with an ERP, for example) you do not control table design and relationships. If I know a table function written in PL/SQL combined with a few optimizer hints will increase throughput by four hundred percent do I take that knowledge into account? Or do I keep the SQL template'd and generic and take the performance hit at the cost of hardware upgrades? (I've seen CASE generated SQL and when compared to hand-tuned SQL you exponentially lose response; which impacts the entire system).

I'm realizing I could go on all day and should probably wrap this up. More thoughts later, perhaps.

Thursday, March 02, 2006

Internet is up... :)

Initially they thought I was back up, cancelled my ticket and were off to other things but I had them come back. A coupler was going bad and there was corrosion on the connectors in the unit outside my house.