I spent most of my time at The Office today working on the web-based security cam for our data center [1]. The actual camera is working fine and the images are accumulating on a server—the stuff I was working on today involves browsing the ever accumulating pictures.
The first major decision I had to make (and this is a project I've been working on for the past couple of weeks) is whether to generate static pages (as the images are mailed in) or do a completely dynamic site. There are arguments for both ways; the pages won't change all that much—during the day only the main index page for the current day, then at midnight the index page for the current month, then once a month the current page for the year and while I personally like this idea (a form of early binding if you will) there are a few downsides: one) it's even more files to store and two) if there's ever a design change, all the pages will have to be regenerated.
A dynamic site, however, only requires a few additional files for the program, and changes to the site take effect immediately, but the page(s) have to be built (and built and built) for each request, which involves quite a bit of disk I/O (Input/Output) (to get image filenames namely).
I ended up going the dynamic route—Smirk wants to store the images for as long as possible so the less overhead (in this case, static web pages) the better. Also, it's not like we have to support heavy network traffic—only one, maybe two people at a time may be viewing these, and only if there's a problem with missing tools.
Also, since Smirk is a fan of PHP [2] (Why? I don't know … ) so I figured this would be a good chance to get a feel for programming in that … language.
I do not like it, Sam I am. I do not like PHP and ham.
The whole global variable thing I'm ambivilent about. PHP is unusual (for the languages I've used) in that you have to declare which variables are global every time you use them, like:
>
```
$g_base = "/some/random/path";
function display_file($template)
{
global $g_base;
for ($this->m_i = 0 ; $this->m_i < count($this->m_files) ; $this->m_i++)
load_template($g_base,$template);
}
```
(why yes, I am using objects in PHP [3], and yes, the looping variable is part of the current object so I can support templates, but that's not important right now)
Unlike most languages I've experienced, if you do:
>
```
$g_base = "/some/random/path";
function display_file($template)
{
for ($this->m_i = 0 ; $this->m_i < count($this->m_files) ; $this->m_i++)
load_template(**$g_base**,$template);
}
```
the language looks first to see if $g_base is defined within the function, and if not, looks to see if it's been defined outside of the function and if so, uses that. PHP, on the other hand, will just assume you want a new local variable named $g_base and not even bother looking elsewhere, hense the need to declare $g_base as being global within display_file().
Not something I'm used to.
But I can see why it's done that way and can't really argue with it, but I keep forgetting about that, expecting PHP to handle lexical scoping [4].
I also find the gratuitous use of dollar signs annoying, but at least PHP uses it in a consistent manner:
>
```
var $scalar;
var $array = Array();
var $hash = Array();
$scalar = 0;
$array[0] = 1;
$array[1] = 2;
$hash ['brownies'] = "are good";
$hash ['hashish'] = "is illegal";
```
unlike Perl, where the declarations of scalars, arrays and hashes use different symbols:
>
```
my $scalar;
my @array;
my %hash;
```
so I would expect Perl to work like:
>
```
$scalar = 0;
@array[0] = 1;
@array[1] = 2;
# NOTE---Perl uses {} instead of [] for hashes!
%hash{'brownies'} = "are good";
%hash{'hashish'} = "is illegal";
```
but nooooooooooooooooooo! It's back to the dollar signs:
>
```
$scalar = 0;
$array[0] = 1;
$array[1] = 2;
$hash{'brownies'} = "are good";
$hash{'hashish'} = "is illegal";
```
But I come to bury PHP, not Perl.
The biggest sticking point I have with PHP (and I have the same issue with Perl as well) is the lack of type checking—a variable could be a number, or a string, or an array, or an associative array (aka hash table) or a pterodactyl. This means you can do stuff like:
>
```
$fourscore = "80"; //note-this is A STRING
$seven = 7; //note-this is A NUMBER
$yearsago = $fourscore + $seven; //Do you get 87 as
//A STRING or as
//A NUMBER? It's BOTH!
//It's Hiesenburg programming!
//Wheeeeeeeeeee!
```
But something like:
>
```
$bills = Array(); //note-this is AN ARRAY
$account = 400; //note-this is A NUMBER
$money = $account - $bills; //What now?
```
will most likely blow up.
At run time.
And while it's clear what's wrong with the code above, it's not quite so clear in the following:
>
```
$bills = get_the_bills();
$account = 400;
$money = $account - $bills;
```
Hope get_the_bills() returns something that can be subtracted from a number. Or was it sum_the_bills() that returns the number? (certainly ignore_the_bills() is not the right thing, although that is tempting, and I'm digressing).
I suppose I'm too used to strongly typed langauges where the compiler nickel and dimes you to death about types so I don't have to keep all those details in my head (the computer is more capable of keeping track of details like so I don't have to).
So I'm having to constantly remind myself that $g_baseobj->m_subobj is a “month object” (not a “day object”) in this portion of the code, and that find_entry() returns a number (the index into an array), not the entry itself (although perhaps I could rename that function find_index() instead … ).
Object support in PHP isn't that bad—certainly nicer than Perl, but again, the serious lack of type checking makes it difficult to track down problems, and the error messages it gives could be more informative (“Okay, it's nice that I didn't call parent::init() with the correct number of parameters, but which call to parent::init() was incorrect—who or where was the call made from you XXXXXXX piece of XXXX?”).
It's always nice to know that “PRINT debugging” will always be alive and well.
[3] http://www.php.net/manual/en/ref.classobj.php