20190601

stupid computer tricks

objective: rapid prototyping of localnet web services.

constraints:

  • single php file, index.php
  • really obvious path of execution
  • jquery, bootstrap and domchanger for the frontend
  • generate html tags in php using jsonml-like array shortcodes
  • easy paths to generalization and publishing release versions

index.php

here is some pseudo-php:

class PageController { 
    public function main() { 
       // handle a web request
    }
}
function url($path,$internal=true) { 
    // generate an internal url
}
// more utility functions
$x = new PageController();
$x->main();

everything else in the webroot can be expected to be a static file.

within the server configuration, having mod_rewrite enabled or not is a matter of coding discipline when coming up with url() calls. the typical apache2 configuration to get rewrite pointed at the server may look something like this:

<Directory /home/mike/sites/dev.internal.localnet/mantis299/>
 RewriteEngine On
 Require all granted
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteRule ^ /index.php?path= [L]
</Directory>

this tells apache to load the requested files, and otherwise pipe all other urls through /index.php in the webroot specified by the directory.

individual page controllers can probably be made with utility functions like base_controller($setup,$validate,$submit), with a body that looks something like:

function base_controller($setup=function() { }, $validate=function() { }, $submit = function() { }, $view = function() { }) {
    $context = $setup($_REQUEST);
    if($validate(&$context)) { $submit(&$context); }
    return $view($context);
}

public frontend

in the rest of the site, there are no php executables of any sort, but data for the user-agent to pick up and process. the directory structure would look something like

media/js - javascript library files
media/js/site.js - sitewide javascript utility library
media/js/page - page-specific javascript files
media/js/page/index.js - page-specific javascript file for /
media/js/page/user_login.js - page-specific javascript file for /user/login
media/css - css library files
media/css/page/ - page-specific css files, like the ones in /js/page/
media/css/site.css - sitewide javascript utility library

for the purposes of rapid prototyping, the javascript and css utility libraries should accumulate well-encapsulated and frequently-used features implemented in the page-specific javascript.

de-prototyping

when it comes to moving something from a prototype to a production-ready release, one of the steps is to get the environment around the project under control. with explicit referencing, a work breakdown structure of changes to implement becomes a matter of starting at main() and then working one’s way down the call tree to any other method or file that’s relevant to the task at hand.

when a prototype is built, it may be necessary to move the database connection strings or any other private materials to outside of index.php. perhaps include them in the web server configuration as environment variables accessible from within index.php.

another important consideration is version control history. while prototyping, one might leave all sorts of secrets lying around in the file, which may get picked up by version control and preserved for posterity. starting the release version with a new repository might be worthwhile.

neato links

https://patents.google.com/patent/US6285999B1/en – the patent for the low-cost starting point of a major search engine has expired. it may now be worth the effort to release a subscription-only pagerank-based search engine.

https://www.ebay.ca/sch/i.html?_nkw=control+unit – ebay sells used control units

Author: Mike Godfrey

tech in halifax ns

Leave a Reply

Your email address will not be published. Required fields are marked *