Phly, boy, phly
the weblog and site of Matthew Weier O'Phinney

After working on some OO classes yesterday for an application backend I'm developing for work, I decided I needed to create a BREAD class to make this simpler. You know, Browse-Read-Edit-Add-Delete.

At first, I figured I'd build off of what I'd done yesterday. But then I got to thinking (ah, thinking, my curse). I ran into the BREAD concept originally when investigating CGI::Application; a number of individuals had developed CGI::Apps that provided this functionality. I'd discarded them usually because they provided more functionality than I needed or because they introduced more complexity than I was willing to tackle right then.

But once my thoughts had gone to BREAD and CGI::App, I started thinking how nice it would be to have CGI::Application for PHP. And then I thought, why not? What prevents me from porting it? I have the source...

So, today I stayed home with Maeve, who, on the tail end of an illness, evidently ran herself down when at daycare yesterday, and stayed home sleeping most of the day. So, while she was resting, I sat down with a printout of the non-POD code of CGI::App and hammered out what I needed to do. Then, when she fell asleep for a nap, I typed it all out and started testing. And, I'm proud to say, it works. For an example, visit my development site to see a very simple, templated application in action.

I just read coverage of a panel of programming luminaries on Salon; the topic of discussion was about the state of programming. In the course of the discussion, the subject of Open Source came up. Several of the luminaries -- which included architects of the Mac OS and Windows, as well as others -- derided the community for basically reinventing the wheel, and wheels that need to be re-thought entirely anyways. One questioned, "Why is hte idealism just about how the code is shared -- what about idealism about the code itself?"

Andy Hertzfeld (who helped develop the original Mac OS) was sitting on the panel, and jumped in. He has been working with Eazel and Chandler in recent years, and thus has an inside view of open source. His initial comment: "It's because they want people to use the stuff!" Basically, they program Windows- or Mac-like interfaces because then people will be willing to try it out. They program office suites because people "need" an office suite to be productive. Such offerings hook them into the OSS movement.

Another participant, Dan Bricklin (of VisiCalc, a pioneering spreadsheet program) shared an anecdote from Bill Gates. Evidently, Gates gave an interview (with Lammers -- look up this person) in which he explained that his work on MS's BASIC compiler was done by looking at how other programmers had accomplished the task. In his own words, "The best way to prepare is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating systems."

So basically, Gates was an early adopter of OSS methodologies... Interesting to see that today he's so protective of MS code. Guess money might do that to you.

I was lamenting at work the other day that now that I've discovered OO and templating with PHP, the only major feature missing for me is a way to easily document my programs. I'm a big fan of perl's POD, and use it fairly extensively, even for simple scripts -- it's a way to provide a quick manual without needing to worry too much about how to format it.

So, it hit me on the way home Friday night: what prevents me from using POD in multiline comments of PHP scripts? I thought I'd give it a try when I got home.

First I googled for 'POD for PHP', and found a link to perlmongers where somebody recounted seeing that exact thing done, and how nicely it worked.

Then I tried it.. and it indeed worked. So, basically, I've got all the tools I love from perl in PHP, one of which is borrowed directly from the language!

I've been researching and coding for a couple months now with the decision that I'd rewrite the family website/portal using mod_perl with CGI::Application. I still like the idea, but a couple things recently have made me rethink it.

For starters, the perl DBI is a bit of a pain to program. At work, I've become very accustomed to using PEAR's DB library, and while it's in many ways derived from perl's DBI, it's much simpler to use.

Then there's the whole HTML::Template debacle. There's several ways in which to write the templates, but they don't all work in all situations, and, it seems they're a bit limited. We've started using PHP's Smarty at work, and it's much more intuitive, a wee bit more consistent, and almost infinitely more extendable. I could go the Template::Toolkit route for perl, but that's almost like learning another whole language.

Then, there's the way objects work in perl versus PHP. I've discovered that PHP objects are very easy and very extendable. I wouldn't have found them half as easy, however, if I hadn't already been doing object oriented programming in perl. One major difference, however, is how easy it is to create new attributes on the fly, and the syntax is much easier and cleaner.

Add to that the fact that if you want to dynamically require modules in perl, you have to go through some significant, often unsurmountable, hoops. So you can't easily have dynamic objects of dynamically defined classes. In PHP, though, you can require_once or include_once at any time without even thinking.

The final straw, however, was when I did my first OO application in PHP this past week. I hammered it out in a matter of an hour or so. Then I rewrote it to incorporate Smarty in around an hour. And it all worked easily. Then I wrote a form-handling libary in just over two hours that worked immediately -- and made it possible for me to write a several screen application in a matter of an hour, complete with form, form validation, and database calls. Doing the same with CGI::Application took me hours, if not days.

So, my idea is this: port CGI::Application to PHP. I love the concept of CGI::App -- it's exactly how I want to program, and I think it's solid. However, by porting it to PHP, I automatically have session and cookie support, and database support is only a few lines of code away when I use PEAR; I'll add Smarty as the template toolkit of choice, but make it easy to override the template methods to utilize . I get a nice MVC-style application template, but one that makes developing quickie applications truly a snap.

This falls under the "right-tool-for-the-job" category; perl, while a wonderful language, and with a large tradition as a CGI language, was not developed for the web as PHP was. PHP just makes more sense in this instance. And I won't be abandoning perl by any stretch; I still use it daily at work and at home for solving any number of tasks from automated backups to checking server availability to keeping my ethernet connection alive. But I have real strengths as a PHP developer, and it would be a shame not to use those strengths with our home website.

We're starting to use OO in our PHP at work. I discovered when I started using it why I'd been having problems wrapping my head around some of the applications I've been programming lately: I've become accustomed in Perl to using an OO framework. Suddenly, programming in PHP was much easier.

There's a few things that are different, however. It appears that you cannot pass objects in object attributes, and then reference them like thus:

    $object->db>query($sql)

PHP doesn't like that kind of syntax (at least not in versions 4.x). Instead, you have to pass a reference to the object in the attribute, then set a temporary variable to that reference whenever you wish to use it:

    $object->db =& $db;
    ...
    $db = $object->db;
    $res = $db->query($sql);

What if you want to inherit from another class and extend one of the methods? In other words, you want to use the method from the parent class, but you want to do some additional items with it? Simple: use parent:

    function method1()
    {
        /* do some pre-processing */

        parent::method1(); // Do the parent's version of the method

        /* do some more stuff here */
    }

Update:

Actually, you *can* reference objects when they are attributes of another object; you just have to define the references in the correct order:

    $db =& DB::connect('dsn');
    $this->db =& $db;
    ...
    $res = $this->db->query($sql);

I've tested the above syntax with both PEAR's DB and with Smarty, and it works without issue.

Last night, I created my first RAID array from the commandline. It was quite simple, I discovered.

1. Create your partitions using fstab. Remember, primary partitions must be created before extended partitions.
2. Look in /proc/partions and note the new partition IDs.
3. Edit /etc/raidtab and create a new RAID array. If unsure of the syntax, look up the Linux Software RAID HOWTO for more details.
4. Type mkraid /dev/md?, where ? is the id of the RAID device you just entered in /etc/raidtab.
5. Format the new RAID device with your favorite filesystem, assign it a mount point, and start using it!

I was impressed with how easy it was; the choices that the Anaconda installer present for creating a RAID array made it seem like the underlying process must be difficult, when in fact it may have been almost the same complexity if not easier.