Webmaster: Larry Leroy Wolfe

Design Expertise: Software

build things to last a long time....

 

 

 

 

 

 

 

Below are sample source code files I included here to apprise you of my level of expertise in software engineering. For a resume style of Software Engineering Expertise, go here:Resume_Software

For illustrative examples of actual work that I have done, continue reading down below.


Best practice tip:

Put your screen resolution into the widest pixel resolution possible because many of the below sample text files have very long lines exceeding standard screen resolution widths. The widest screen resolution will save you from having to scroll right and left as you read this source code. And if you are using Netscape Navigator, which I do, hit the {CTRL}-+ key iteratively to increase the font size in your browser as you read my below discussions.


 

#1 Sample php source file using a "*.txt" extension to allow you to use your browser to view this=> DWSOSpMBI.txt

DISCUSSION of Sample #1:

The foregoing sample source code was designed inside the Zend Studio IDE and really looks better in that IDE. However, to allow you to see the source php code using your browser, all of this file's original color coding has been reduced to black font only. IF you have a php ZEND STUDIO IDE, or a really good text editor such as this one which I use produced by JGSoft called EditPadPro {http://www.editpadpro.com/} then rename this file to have a php extension [For Zend IDE php editing and debugging ] instead of the txt extension [for Text Editor] shown in the above sample filename. Then fire up your Zend IDE php Editor and/or the JGSoft EditPadPro text editor to examine this code as if you were preparing to design or debug php source code. The rich color coded mechanism used by Zend Studio IDE and by JGSoft Text Editor makes source code production and debugging so much easier. And, of course, being able to collapse and expand functions, or to use the Zend Studio IDE to access live databases used in the source code, makes design and debugging of php source code so much more efficient.

This sample source code php software will give you an idea of my style of documentation as well as my level of expertise using sophisticated php syntax.

END of DISCUSSION of Sample #1

 


 

#2 Sample Borland/Paradox scripting language source file also using a "*.txt" extension => RV_Gen01.ssl.txt

DISCUSSION of Sample #2

This sample source code was written years ago as part of a comprehensive Document Management System called "LibMan". With this sample you can see how I use sophisticated Enter Procedure Initialization , or "EPI" for short, convention. By this convention, thousands and thousands of lines of source code were kept reasonably coherent over the years even when doing major revisions. While a performance penalty existed when PC clock speeds were 33MHz when I first began developing my software on 80486 platforms then considered state-of-the-art, I always knew those performance penalties would vanish and that eventually, the robust diagnostics and trace capabilities of my software would greatly add time saving benefits orders of magnitude beyond the initial time investment to code the sophisticated procedures. This sample source code is fully functional and is used to generate any size random variable sequences using a variety of mathematical radix strategies. File management safety, as well as password strong coding strategies are easily selected in a GUI form window.

END of DISCUSSION of Sample #2

 


#3 Sample Borland/Paradox Form Procedure source file also using a "*.txt" extension => FDesc001.txt

DISCUSSION of Sample #3:

Originally part of my File Describer Main form Window. This procedure allowed external borland scripts to inter-communicate with this internal form procedure by usage of paradox database external Global Params Array [GPA] table databasing techniques that I developed in the absence of pass-by-reference script function capability of Borland/Paradox scripting language. No matter what variable or type, the GPA table was used as a database communication technique to allow inter-script memory storage so that all of my scripts and form procedures could inter-operate after initializations completed. Using any of the following data types.

Alpha ; Number ; ShortInt ; LongInt ; BCD ; Date ; Time ; TimeStamp ; Memo ; Memo ; Graphic ; OLE ; Logical ; Binary ; Bytes

This level of extent of data type exchange is common now in many advanced procedures using sophisticated pass-by-reference memory references in php functions. But back in the 1990's, there was no way to pass this level of data types between borland scripts and procedures. So I developed an elegant param entry and param decodation algorithm shown in this file and used in all of my scripts and procedures that required variable exchanges. Even now, with local and global pass-by-reference memory array passing capability in php, I still use this GPA convention to allow php scripts to intercommunicate on the server and on the client computer itself also running server software. And by use of remote procedure calls [RPC]'s, the server-client interconnection is made coherent via this Global Param Array [GPA] convention even with large elapses in time between php script executions. I find this technique superior to using session cookies because of better security protocols I designed into the overall virtual hosting OS architecture.

With today's clock speeds in the 3GHz range, compared to 3000 milliseconds of sluggish processing delays on the old 33MHz 80486 platforms, the overhead of my software architecture completes in less than 25milliseconds. Back then I knew the sluggishness of so much overhead and frequent database interaction was a penalty. But I also knew that computing in the 1990's would be much different in the 2000's. And faster in the future. So I built in rugged diagnostics and rigid architectural structures to ensure that my software could be used decades from now. I'm now nearly completed with re-porting this architecture from this old, antiquated Borland/Paradox scripting procedural language, to robust, readily available php scripting and databasing (using MySQL, now, but provisioned and coded to use any of many popular databasing technologies other than MySQL). My server ware, client-ware Operating System architecture is quite comprehensive, robust, and designed for fault tolerance even when it is expected to encompass future technologies and future techniques not now invented. For client side applications, I elected to use the FLASH Engine because Borland/Paradox placed a prohibition on their "runtime" engine to expressly prohibit free use of their "engine" in applications that were dedicated to "general document management". By Corel/Borland's short sightedness, I knew they doomed themselves to a declining presence in the world wide web which is now exponentially exploding the total number of documents created, stored, and re-transmitted around the globe. Voluminous numbers of web documents being produced now, require some form of Library Management that subsumes all document types whilst being totally independent of the Operating System of a specific server-client platform.

This is what my Library Management, or "LibMan", architecture sought to accomplish. But I soon discovered that I needed a rugged, reliable, server side, platform independent OS behind it too. So I designed an independent OS to do just that.

END of DISCUSSION of Sample #3


#4 Sample php MySQL source file which defines my Operating System's Database Inventory => 0_dbSERVERDBCFG_dbSFX__SERVERDBMSuite000.txt

DISCUSSION of Sample #4:

This sample shows how I define database inventories used in my OS. IT also shows functions used to, similarly, compile table related arrays also extensively inventoried in my OS. The table arrays show that I use not only the primary table name, but also allow for logical-table-connect-info to be used by downstream processes desirous of knowing if table connections exist, or not, as well as allowing for table-counter-info to be tabulated, and finally, to allow for the usage of table aliases and table passwords.

Aliases provide greater, abstracted, security. Especially so when comprehensive diagnostic error messages, trace diagnostic sequences, and etc are used in my operating system to convey info over the internet, by email, or to online diagnostic files. Such info is needed by the relevant troubleshooter performing his IT function as either an end user or as an IT support staff on the server side. But because hackers also intentionally cause errors in order to generate these info related results, additional security precautions in my OS error messaging technique can be accomplished by ensuring that the OS architecture, itself, can be "randomized" even if it is an open source scripting language such as is php MySQL Hackers intentionally cause errors so that they can exploit the error messaging capability frequently built into sophisticated operating systems.

(like in the 1983 movie, War Games, where Matthew Broderick thinks he has exploited the extensive help system to help him hack into the kid's game, "protovision", but he was in actuality hacked into the Help system of a complicated, US Defense Department, WOPR Computer System. Inadvertently preparing to begin global thermonuclear war with himself playing as a Soviet Red against US!)

Knowing how hackers "probe" a complicated OS looking for useful info in error messaging or in online help messaging, I designed additional complexity to confuse even that effort. Requiring automated methods to strip out abstracted aliases and to then replace into the error message, the proper kernel info required by the IT professional doing his diagnostic checks.

For security purposes, I intend to generate random sequence table aliases "on-the-fly" for each and every separately instantiated OS-on-client and OS-on-server instantiation. Doing the same for mnemonic variables used in the scripting based, open source OS. Greatly increasing the security of the OS by making it difficult for hackers to understand what the scripting language was doing if they hacked somebody's server or if they bought my server ware and simply tried to "reverse software engineer" my source code. Yes, I know about Tel Aviv's Zend "scrambling" technologies for php scripting source code. No, I don't trust it completely either in US Defense Related Super Computing.

Passwords are alluded to in this sample source code. But I use a different naming convention other than "password". This sample contains the convention I developed in Borland/Paradox scripting language to manage passwords used by tables therein. I use the convention Security Name Key, or alternatively when abbreviated, SNK_01, to identify large word length (255 alphanumeric chars), radix 62 or greater, random sequences to be used for password management purposes. Even though MySQL did not originally provision for Table Passwords, I knew that eventually they would or that my OS would subsume other database vendor technologies that did. So I built into my OS the password protection architecture in advance when I re-ported from Corel's Borland/Paradox scripting language into the php MySQL scripting language.

This database<->table OS open source architecture greatly simplifies the arduous task of adding, removing, and/or moving table-related-info used by my OS and/or used by the application processes which are not part of my OS but which desire to use many of my robust, fault tolerant, OS features. Downstream processes need not know where these tables are located. They do not need to know what database name contains them. All the downstream processes need to know are the Database "alias" and the Table "alias" for each. Period. SNK_01 technology is handled independently from the php scripting processes requesting table related transactions. If they have security access privileges, then the relevant table or database service request will be granted. If not, then not. Period.

This abstraction technique, while incurring a temporal penalty due to server-side processing delays, assures reduced software lifecycle costs because "alias" and "password" related database<->table transactions are abstracted from the initial, ACTUAL names used to define the database<->table structural pairs.

END of DISCUSSION of Sample #4


#5 Sample which shows how a typical php MySQL table is structured "on-the-fly" => 4_dbTblCFG__dbSfx__djbciwebservopsys01__Tbl__param0g1.txt

DISCUSSION of Sample #5:

This file allows auto-table-creation capability, dynamically (which greatly improves fault tolerance and error correcting recovery common in database<->table lifecycle management), or to allow other table specific, table structure dependent, database commands to be accomplished in downstream php processes. This sample just happens to use the Global Params Array [GPA] memory structure when forming the table structure for a table named param0g1 which emulates GPA because this GPA memory array is frequently passed by reference in many of the php scripts in my operating system as well as passed by database<->table interactivity. The GPA table variation is a special case of all of the tables initialized using this table structure sample code technique

END of DISCUSSION of Sample #5

 


#6 Sample using the php call_user_func_array( x , y ) function => 1_DirLookup_for_Tbl_Structure___Tbl_Name___of_FNK01.html

DISCUSSION of Sample #6:

The sample source code shows how I use indirect indexing to allow my server/client Operating System to quickly identify and use table structure parameters vital for downstream database<->table manipulations [query, copy, delete, etc..]. This file also processes CLONES of template source Table structures. Greatly reducing the total number of structural files required to be stored for each and every clone. This abstraction technique greatly simplifies downstream database related coding since all of the structure related table info has been pre-initialized in the OS for dependent function use. While I initially selected MySQL, the abstraction technique has been programmed to accommodate other database technologies such as Oracle and etc.. The bottom line is that calling procedures and/or functions need only know the Database "alias" and the Table "alias". This Indirect Indexed Lookup procedure will map the aliases to the correct Database and Table. And then it will use memory pass by reference, inside the Global Params Array [GPA] memory reference, any associated commands to be undertaken upon that Table [Create, Query, copy, move, delete, etc..] completely independent from the syntax used by any specific DBM vendor. Returning the results in the same GPA.

END of DISCUSSION of Sample #6


#7 Sample is a commonly used database repository of functions => dbManip01.txt

DISCUSSION of Sample #7:

This sample gives you an idea of the abstraction effort described above, herein, when it comes time to perform database<->table manipulations. From the foregoing examples, and from many other procedures too voluminous to include on this web page, by the time the sequencing arrives in this set of database dependent php functions, GPA has all of the required parameters, or will soon be filled with the required parameters requested by the upstream calling procedure. GPA can and frequently does contain memory arrays, not just scalar memory values. IT is really an interesting and very flexible global variable that is used extensively throughout my OS.

One vital part in my OS is to use comprehensive ENTER PROCEDURE INITIALIZATION [EPI] memory arrays, themselves located inside the GPA main memory array, in order to provide robust, comprehensive, secure and insecure, highly detailed, trace diagnostic capability. As well as to provide varying levels of detail in fault error reporting and/or fault error logging capability. For any and all EPI enabled functions, procedures, scripts, and processes used throughout my OS, either as OS related applications, or as non-OS [i.e end user] applications. Because database manipulations are most frequently used in almost every application, related to my OS, or not, this particular sample shows the EPI technique quite astonishingly. And extensively. Few software developers would go to this much trouble to simply open a database.

I did.

Here's a snippet from this sample file showing this EPI stratagem.

$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcFileName']=$GPA['RO']['File']['Attribs']['PrXEbHP3222gWcC']['Proc']['FileName'];
$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcFileVersion']=$GPA['RO']['File']['Attribs']['PrXEbHP3222gWcC']['Proc']['FileVersion'];
$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcFileReviseDate']=$GPA['RO']['File']['Attribs']['PrXEbHP3222gWcC']['Proc']['FileReviseDate'];
$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcFileReviseTime']=$GPA['RO']['File']['Attribs']['PrXEbHP3222gWcC']['Proc']['FileReviseTime'];
$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcFile_FNK_01']=$GPA['RO']['File']['Attribs']['PrXEbHP3222gWcC']['Proc']['File_FNK_01'];

$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcName']='pConnect_generic_db_func(&$GPA)';
$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcVersion']=2.28;
$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcReviseDate']='[DateType=Full_Little_Endian,Year=2005,Month=01,Day=04]';
$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['ProcReviseTime']='[TimeType=Military,TimeZone=GMT,TimeOffset=(-08),Hour=11,Min=15,Sec=04]';
$GPA['EPI'][$GPA['IDX']['EPI']['ProcDepth']]['Proc_PNK_22']='...{_a_255_char,_alphanumeric_using_radix_62,_or_better,_crypto_ID,_or_PROCESS_NAME_KEY_22_}...';

This and other params not in this snippet, are standardized params used upon entering all EPI enabled functions. They provide during error reporting and trace diagnostics, an incredible level of detail not normally available to end users nor IT staff inexperienced with php Zend Studio IDE trace diagnostics and other advanced php Zend Studio IDE software debugging tools. As you may be aware as an IT professional, much of your time and budget is spent "fixing" poorly written software, and worse, trying to figure out what somebody else intended with poorly documented software.

The OS architecture purposefully added this layer of abstraction so that a wide variety of database vendor DBM's could be accommodated whilst allowing developers to develop their own custom procedures or applications without needing to know which vendor's database technology would be used, nor knowing what database naming conventions were required, with or without passwords, nor knowing where file locations existed on the server or the client. When errors happen, the EPI enabled functions quickly identify where the problem is happening, and usually recommend solutions in fixing the problem. More difficult problems can be found by activating the TRACE DIAGNOSTICS feature used in my OS. All without letting a skilled hacker determined to cause such errors, to even know what is going on because he, like an ordinary end user experiencing genuine software glitch errors, cannot see the error messages on his screen because they have nearly all been trapped and handled by my OS. When you read this sample file, you will see built-in diagnostic capability to recover from many common errors [i.e missing or moved tables, etc...]. Missing tables that are vital to continued error free operation are simply auto-created "on-the-fly" and used downstream as if they were never missing.

Errors that my OS cannot repair nor recover from, use the extensive EPI reporting technique to develop comprehensive, secure and NOT-SECURE, verbose and not verbose, error messaging. The following sample code snippet was extracted from this sample file to show this EPI reporting technique. The term PPC is simply an acronym I developed called PROCESS POINT CODE [PPC]. I use PROCESS POINT CODE [PPC]'s extensively in all of my source software. They are short word length, radix 62, or better, random sequences or crypto-keywords. Every intention is made via PPC sequences to ensure that all php source code files upon the entire web site full of server side php files, have only one file, and only one location inside that file, a guaranteed location of such a PPC identifier that is called out in an EPI diagnostic error message or trace report. PPC identifiers rapidly take the diagnostician directly to the source code area that is calling out the error. While the EPI diagnostic messages generally report the actual filename and report the the actual process name or the actual function name that generated the error, the PPC sequence uniquely identify the exact spot in the specific file where the error is being generated. A file search using this PPC designation code will quickly find the file.

Here's a sample EPI trapped error taken from the above sample file. It is just a code snippet where a particular error had been trapped. IT will open in a separate browser window.

{Code Snippet}

From the above you can see that the EPI reporting technique used in my OS provides very useful information with only a slight overhead penalty in processing delays. Memory usage is greater because the script is loaded into memory, but as delineated above when I first began developing this architecture upon a 33MHz CPU clock speed computer having only 32MegaBytes of RAM memory, I knew memory advances would exponentially happen in shorter and shorter time. So the server's memory usage consumed by large numbers of php scripts being initialized in this manner, can be considered negligible overhead in a few years from now when servers have Terabyte Memory capabilities as a "standard" option. EPI reporting can be further "turned off" to ignore all of this extra coding by simply setting the Global Params Array variable,

$GPA['EPI']['IsAllowed_logical'],

to be FALSE. The total Number of Errors COUNTER, however, will still be incremented upon trapping this error. When this function completes, and program flow returns to the original calling process, this EPI error counter will be checked and if not zero will cause another error counter,

$GPA[CNTR][ERRS][Total]

to be incremented just once, accumulating the first known error sequence generated in this function that may have multiple errors. This is very handy when using built in bootup diagnostic messages as part of the

$GPA['BOOT']['MSG']['Visible_logic']

diagnostic logging feature that is outside the TRACE DIAGNOSTIC scope. BOOTUP messages are periodically posted which contain good or not good messages. The Total Number of Errors COUNTER,

$GPA[CNTR][ERRS][Total]

is incremented when errors occur during bootup.

Because the first error that trips off a cascade of errors, most likely, is the culprit that needs to be fixed, by watching the

$GPA['BOOT']['MSG']['Visible_logic']

enabled bootup messages, with this $GPA[CNTR][ERRS][Total] COUNTER shown to be set to 0 and remaining set to 0 as the code sequences, the first error in the BOOTUP MESSAGING where this counter is greater than 0 will provide good info to quickly identify where the problem area began. The OS has an ability to "turn on" TRACE and DIAGNOSTIC messaging unique to each procedure or function in addition to "turning on" for all EPI enabled functions. Quickly allowing the diagnostician to narrow down the problem area.

This technique has been used in production software for our construction company for years and does exactly what it was designed to do: Make my life simpler when software additions, upgrades, or changes are initiated by me.

To see a sample TRACE RESULTS for a typical "ThisDoc.php" browser output experiencing no errors, CLICK HERE.

 

END of DISCUSSION of Sample #7

END of ALL SAMPLES

 


 

These samples should acquaint you with my level of expertise in software lifecycle issues.

I've been programming ever since the US Navy first taught me in Jan 1975 thru to December 1975 during an Advanced First Term Avionics curriculum of training at Naval Air Station, Millington, Tennessee.

 

 

 

 

 

 

 

I design for fault tolerance.

 

 

 

Privacy Policy | Contact Us | System Requirements| ©Copyright protection notice. All rights reserved.