| Aside from my early-years experience with QuickBasic (some of which can be sampled below, as well as on the Diplodocus Game Design page), I started my IT career and learned MS Access database-management using Visual Basic, and cgi-programming using Perl, both of which went into the fabrication of this website. | | First is an MS Access database, with extensive functionality and features to make it as efficient as possible. From the start, my plan was to use this database to track my CD collection, but throughout the years I occasionally revisited it to add new tables and features. The most extensive re-design came in 2006 with the addition of cosplaying- and convention-management into the database structure. | | This database has a feature that lets me dump the entire data into text files. These files are then uploaded to the server where my site is hosted, and where I've built an exact duplicate database structure as my MS Access one. This duplicate database is in MySQL. |
| _________________________________________________________________ |
| I then run a script I wrote to flush all the data from the MySQL database, and re-load it using the text files. Instantly, my website is updated with new data, without having to change a line of code. | | New pictures and other documents are uploaded to the domain as well, and don't require any code changes, either. Each picture has a database record providing the code with all the information it needs to automatically add it to the website's appropriate galleries. Each one of those records also has a date field, which is what the "Recent Additions" sections of the main page rely on. When something is older than a few weeks, it automatically disappears from those sections. | | As for the website itself, it's written in Perl, with frequent SQL interaction with the database. Other than the one-liner "index.html" file that kicks off the site's main script, there is not a single static HTML page throughout the entire site. Everything is dynamic cgi. Some areas also have highly complex JavaScript and CSS. |
| _________________________________________________________________ |
| The site does not rely on cookies. To maintain information from screen to screen, like the identify of the user and other form elements, it writes what it needs into temporary "context" files on the server. The name of that context file is always passed to each new page (either through a URL, or a hidden form element) and the page's cgi program opens the file and loads its contents into memory. | | The entire website uses only a single cgi program, called "kintaro.cgi" (named after Kintaro Oe from GoldenBoy, becase the script takes on the many different jobs the site asks of it). That script performs the nitty-gritty details every page needs, like parsing the URL's query string, loading the context file, authenticating, etc. | | kintaro.cgi then passes the page's particular request to the "yukinojo.pl" script (named after Mihoshi's navigational robot in Tenchi Muyo, because it takes any of the site's requests and fetches the matching code). To keep yukinojo.pl's size manageable, some of the code for certain pages was put in its own file. |
| _________________________________________________________________ |
| Very often, kintaro.cgi, yukinojo.pl and the other scripts will call upon often-used functions, which are stored in the "mousse.pm" library (named after the hidden weapons specialist in Ranma ½, because its job is to always have the necessary piece of code up its sleeve). | | In my second IT job, we had a reporting library which could easily generate a report given a few parameters, even nested reports. I inspired myself from that technique to write "robo.pm" (named after the robot in Chrono Trigger, because it's an automated process that obeys the parameters it's given). | | And that is how the Musical Otaku is put together! |