Practical PHP and MySQL

I'm taking a summer course in Building Data Driven Websites - not that I thought I'd learn much in such a course at SCILS, but I'd like to graduate on time, and need the credits, and Bill Crosbie is just the type of rare teacher that can keep even me awake and interested. Our book is Practical PHP and MySQL: Building Eight Dynamic Web Applications (Amazon by Jono Bacon. Now, I know it's not a real book like, say, ESA3 by Frisch, which has a healthy web presense. But this thing is all code and doesn't even have a web site, let alone easy code downloads!

The book does come with a heavily customized Ubuntu LiveCD. However, when I popped it in my OpenSuSE workstation, I couldn't really make much out of the CD - there was certainly no easy-to-find "this is the code" directory. Well, after some exploring, I mounted the SquashFS filesystem and poked around a bit. Strange... seems to only have one real user (root) and, though they claim this is a fully-functional LAMP server, no Apache or MySQL. Really weird. Well, after poking for a few minutes, I found the holy grail - /root/.bash_history was intact! Just a quick look through it with less and I found what I was looking for: /opt/lampp. It appears that the install is actually ApacheFriends' LAMPP, or XAMPP for Linux (gotta wonder if the guy writing this book doesn't even know how to install Apache... I'm sure XAMPP for Linux is more bloated than a customized build of Apache/MySQL/PHP from source, especially since it's only being used to host 8 sample projects, so a lot could be left out).

Anyway, it appears that LAMPP is running in a chroot'ed environment. The actual sample code is rooted at /opt/lampp/htdocs/sites. It seems that all of the PHP files are also owned by root and chmod'ed 777! And the top-level index.php file makes use of absolute links, so obviously he never thought that someone may want to copy the sample code and use it on a real box.

I just can't imagine someone who's a beginner with Linux, let alone a Windows person, trying to get this source code onto a machine where they can actually play with it. And... to make the situation worse... the LiveCD has vi and vim, but no Emacs!!!! Eeeek!!

For anyone who needs it, I have the archive available on my site. For non-*nix people, you'll need Gzip or an equivalent program to extract it.

Update, Eventum/MySQLTicketing Integration

Well I know I haven't updated in a while. I have a whole bunch of links that I'd like to comment on, but things have been horribly busy. You can find the links in my "1-toblog" folder on del.icio.us (prefixed with "1-" so it shows up at the beginning of my bookmark menu).

In monitoring land, I've paused my Hyperic HQ VM as I wasn't too pleased with how the features panned out. I was invited to beta test Groundwork Open Source 5.2b, but I'm not crazy about the open-ness of a non-public Beta, and am honestly not that intrigued by the small feature set (though, admittedly, they do need more documentation on the F/OSS version). I'd still like to try them all, especially Zenoss Core, but I'm pretty busy with class, and things are heating up at work and with a few consulting projects.

In my "spare time" (read: staying up until 5 AM and somehow still getting up for work at 9) I've been working on something that's been bugging me for a while - getting Nagios to automatically open and update tickets in Eventum, the ticketing system that I (and MySQL) use. The general idea is to use a "glue" script, written in PHP (Eventum's native language). It will (hopefully) keep track of which hosts/services it has opened tickets for (and what the ticket ID is), and decide from that whether to open a new ticket or, if one already exists for that host/service, update it. It should also handle changes to assigned user/group, update categories, priorities, etc. This will all be based on a DB table that maps problem severities and hosts/services to the users, groups, categories, and priorities that they should be assigned.

The biggest problem is that I'm not a whiz at object-oriented PHP, and like any good OO program, Eventum is broken down into dozens of objects, classes, and files. With the help of the Xdebug debugging extension for PHP, which prints full debugging output including stack and function call traces, I've been able to *finally* - after about four hours of work - write a simple little 15-line script that uses ONLY existing Eventum classes, unmodified (except for a separate init.php with some stuff commented out), which gets a list of users assigned to an issue. From here, it shouldn't be difficult to get full issue information and then, hopefully, add and update issues.

I have a basic description of the project on my wiki, and the current (development, so could be broken) source code in CVS, which can be seen through ViewVC on my site.

Stay Tuned!

Poor PHP

Well, as mentioned below, today I was doing a little research. On the futility of a Computer Science major. Specifically, on the fact that the overwhelming odds are that in a career in IT, system administration, or even web programming, I'll probably never apply 90% of what I learn in CS courses.



So, I went looking for online certificate programs, knowing that most of the vendors' programs run $500 or more just for testing. I came by eCertificates.com. And this brings me to another topic... I clicked on the "Software Programming" category, and was surprised to see no PHP test. On a hunch, I looked under "Web Design", and sure enough, there it was.



I know this is a common misconception, and I know that because it plays so well with the web, and Apache, PHP has been pigeonholed as a web language. Maybe I'm just crazy, or maybe it's just because I know PHP better than anything else. But PHP is NOT a web programming language. It is a programming language that happens to work very well with web applications.



Using fread() and fwrite() I can slam together a command-line menu-based PHP script for administration quicker than I could write the def's for a Python script. I've done it, I have a number of PHP CLI-based scripts running on my machines. Database access with PHP is a no-brainer. And one day, when I get around to reading my "ancient" pile of books and learning NCurses, PHP will be right there with me.



So I guess it is just a fact of the modern web mentality. But PHP has myriad uses aside from web applications and web content handling. Sure, my web site is written in it. But one of my backup scripts is, too. And more importantly, if I'm working with a database that already has a PHP-based web frontend, PHP seems like the natural choice for a CLI-based administration backend.