Mike Blonder: Thoughts on Technology, and the Web

Dynamic pages (really just one HTML page that is filled with information as per an immediate request from someone at your site) is the approach most widely used for

• web sites that require regular updates, or for
• web sites that are produced by personnel who may be heavy on images and words, but light on computer programming

These dynamic pages are supported by databases. Most of the publishing work is actually done on the database side through commands written in Structured Query Language (SQL). These commands are embedded within the scripts that are invoked through tags on the dynamic HTML page.

I don't like this approach for several reasons and have chosen to go a different way with Best Plain Web Pages. The reasons are as follows:

• Security: business customers typically use a database for other reasons. The same SQL calls can run on the customer database that is not facing the web, but may be accessible through a back door. Better not to have tags calling scripts with SQL calls.
• Long URLs: Since the pages are dynamically published, information from different tables and/or rows of the database may be required to publish the same one page. The page address is written to reflect the various actions taken to publish the page, resulting in a long page address. Long URLs are not friendly for Search Engines.
• So-called Short URL schemes don't work well: systems developers at the various Nuke Content Management Systems (CMSs) like PostNuke, have spent lots of time trying to modify the .htaccess file that the Apache WebServer uses to set up the browser for the page address with limited if any success. My experience has been that the number of Page Not Found errors (404 codes) goes up dramatically which, once again, negatively impacts on Search Engine rankings.

Best Plain Web Pages uses scripts that 1) do not run on the client site and 2) produce static HTML pages. I think this is a much better way to go. The scripts we use are written with Open Source components like VIM and Python. Any large-scale changes that we need to make on client sites are effected with VIM functions like argdo, or with tried and true simple programs including SED.

I'm happy to say that our primary client maintains very high Page Rankings for a site in a very competitive consumer market. Long live static HTML.

© Mike Blonder, 2006, All Rights Reserved

Think long and hard prior to scheduling linux migrations (for example, upgrading hardware, changing databases, changing web servers, etc). You must understand that planning this type of move includes many more steps than a comparable move for systems built on the Microsoft® Windows® platform.

I am in the process of upgrading hardware for two of my linux servers (both machines running Novell SuSE, versions 10.0 and 9.3) to Intel® Core Duo® hardware, complete with SATA drives and, for one machine, a GForce 7600 graphics card with an NVidia chipset. The upgrades have not been finished. I have hit lots of bumps, as follows:

1. The SuSE YaST installation program will not run (out of the box) on the hardware platform. I am working on a fix with SuSE, but why should I need a fix?
2. I had to remove the GeForce card. SuSE has problems with the NVidia chip set so, to minimize issues, I removed the card rather than attempt the total install with the card in the motherboard
3. Despite using the "tried and true" disk utility application "DD" to image the drive prior to migration, I neglected to open the image prior to the migration and, murphy's law being what it is, the image failed to open properly after the fact. Fortunately, I have the physical disk as well as archives of the critical files.
4. Had my schedule required static page production (check out bestplainwebpages.com for further info on what I do) I would have lost 4 production days this week. Fortunately, I am doing much more with scripts this week.
5. I have been without my MySQL database for 4 business days awaiting completion of the migration
6. I spent 3.5 man days on this "cost" project with no billable result

Given the above, it makes much more sense to design linux systems migrations from the ground up prior to embarking on same. The modus operandi must include

1. Verifying that the shrink wrap version of the Linux Distribution of Choice works with the intended hardware out of the box
2. Creating all images and ensuring quality by successfully opening all images on fall back hardware that will be available, post migration, should there be problems with the new hardware
3. Restricting the timeframe for the migration to after hours

Images are critically important in a Linux environment as, via an image, one has the best shot at preserving file permissions along with data and, thereby, ensuring that stuff works post migration. As well, if any applications have been compiled, imaging the applications within the disk context (complete with all file dependencies in place) is dramatically easier than recreating the dependencies, permissions, etc. after the fact.

© Mike Blonder, 2007, All Rights Reserved

Life is getting tough for open source. I purchased two bare-bones Intel motherboards complete with Core Duo chips and had the worst time getting the SuSE Linux Distribution (first 10.0 and then 10.2) to run on the platforms. The problem is that the new hardware had some radically different features, specifically a controller located off the motherboard, not supported by the Linux kernel included with SuSE Linux 10.0.

"Not supported" is decidedly bad news for open source. Intel is the largest chip manufacturer and, possibly, the largest manufacturer of motherboards for personal computers. The kind of headache that I experienced trying to install the distribution on the platforms is certainly not the kind of headache that the average user will tolerate.

My initial attempts were met by dark monitors, and repeated failed installations that bounced me back to manual installation screens. Error messages were weird: "Image Not Found" despite the fact that the factory disks were loaded in the Sony DVD/CD Reader Writer that I purchased with each of the systems. My calls to support did not produce a fix. I was pleased, however, to see that the typical brush off from SuSE technical support for folks with older copies of the operating system was not the order of the day. Support was willing to work the problem(s) through, but was at a loss to offer a working remedy.

When I loaded the DVD into our Mac Mini and FTP'd over to the Mac I was able to install the operating system on both of our systems. But, as of yet, I have not gotten the faster of the two boxes (2.4 Ghz processor, 2GBs memory, etc) to work with the Sony Drive and the Operating System.