Tag: programming

MySQL Miscellanae

Inspired by a Slashdot book review of High Performance MySQL.

I've often suspected that I'm not a SQL guru... little things like being self taught and having virtually no resources for learning it. This has been confirmed to a large degree at work, where our DBA has taught me many tricks about databases: indexing, when to use DISTINCT, how and when to do JOINs, and the magic of TEMPORARY TABLEs. I now feel fairly competent, though far from being an expert -- I certainly don't know much about how to tune a server for MySQL, or tuning MySQL for performance.

Last year around this time, we needed to replace our MySQL server, and I got handed the job of getting the data from the old one onto the new. At the time, I looked into replication, and from there discovered about binary copies of a data store. I started using this as a way to backup data, instead of periodic mysqldumps.

One thing I've often wondered since: would replication be a good way to do backups? It seems like it would, but I haven't investigated. One post on the aforementioned Slashdot article addressed this, with the following summary:

  1. Set up replication
  2. Do a locked table backup on the slave

Concise and to the point. I only wish I had a spare server on which to implement it!

Continue reading...

Cgiapp Roadmap

I've had a few people contact me indicating interest in Cgiapp, and I've noticed a number of subscribers to the freshmeat project I've setup. In addition, we're using the library extensively at the National Gardening Association in developing our new site (the current site is using a mixture of ASP and Tango, with several newer applications using PHP). I've also been monitoring the CGI::Application mailing list. As a result of all this activity, I've decided I need to develop a roadmap for Cgiapp.

Currently, planned changes include:

  • Version 1.x series:
    • Adding a Smarty registration for stripslashes (the Smarty "function" call will be sslashes).
    • param() bugfix: currently, calling param() with no arguments simply gives you a list of parameters registered with the method, but not their values; this will be fixed.
    • error_mode() method. The CGI::Application ML brought up and implemented the idea of an error_mode() method to register an error_mode with the object (similar to run_modes()). While non-essential, it would offer a standard, built-in hook for error handling.
    • $PATH_INFO traversing. Again, on the CGI::App ML, a request was brought up for built-in support for using $PATH_INFO to determine the run mode. Basically, you would pass a parameter indicating which location in the $PATH_INFO string holds the run mode.
    • DocBook tutorials. I feel that too much information is given in the class-level documentation, and that usage tutorials need to be written. Since I'm documenting with PhpDoc and targetting PEAR, moving tutorials into DocBook is a logical step.
  • Version 2.x series:
    Yes, a Cgiapp2 is in the future. There are a few changes that are either necessitating (a) PHP5, or (b) API changes. In keeping with PEAR guidelines, I'll rename the module Cgiapp2 so as not to break applications designed for Cgiapp.

    Changes expected include:
    • Inherit from PEAR. This will allow for some built in error handling, among other things. I suspect that this will tie in with the error_mode(), and may also deprecate croak() and carp().
    • Changes to tmpl_path() and load_tmpl(). In the perl version, you would instantiate a template using load_tmpl(), assign your variables to it, and then do your fetch() on it. So, this:
      $this->tmpl_assign('var1', 'val1');
      $body = $this->load_tmpl('template.html');
                      
      Becomes this:
      $tmpl = $this->load_tmpl();
      $tmpl->assign('var1', 'val1');
      $body = $tmpl->fetch('template.html');
                      
      OR
      $tmpl = $this->load_tmpl('template.html');
      $tmpl->assign('var1', 'val1');
      $body = $tmpl->fetch();
                      
      (Both examples assume use of Smarty.) I want to revert to this behaviour for several reasons:
      • Portability with perl. This is one area in which the PHP and perl versions differ greatly; going to the perl way makes porting classes between the two languages simpler.
      • Decoupling. The current set of template methods create an object as a parameter of the application object - which is fine, unless the template object instantiator returns an object of a different kind.
      Cons:
      • Smarty can use the same object to fill multiple templates, and the current methods make use of this. By assigning the template object locally to each method, this could be lost.

        HOWEVER... an easy work-around would be for load_tmpl() to create the object and store it an a parameter; subsequent calls would return the same object reference. The difficulty then would be if load_tmpl() assumed a template name would be passed. However, even in CGI::App, you decide on a template engine and design for that engine; there is never an assumption that template engines should be swappable.
      • Existing Cgiapp1 applications would need to be rewritten.
    • Plugin Architecture: The CGI::App ML has produced a ::Plugin namespace that utilizes a common plugin architecture. The way it is done in perl is through some magic of namespaces and export routines... both of which are, notably, missing from PHP.

      However, I think I may know a workaround for this, if I use PHP5: the magic __call() overloader method.

      My idea is to have plugin classes register methods that should be accessible by a Cgiapp-based class a special key in the $_GLOBALS array. Then, the __call() method would check the key for registered methods; if one is found matching a method requested, that method is called (using call_user_func()), with the Cgiapp-based object reference as the first reference. Voila! instant plugins!

      Why do this? A library of 'standard' plugins could then be created, such as:
      • A form validation plugin
      • Alternate template engines as plugins (instead of overriding the tmpl_* methods)
      • An authorization plugin
      Since the 'exported' methods would have access to the Cgiapp object, they could even register objects or parameters with it.

If you have any requests or comments on the roadmap, please feel free to contact me.

Continue reading...

New site is up!

The new weierophinney.net/matthew/ site is now up and running!

The site has been many months in planning, and about a month or so in actual coding. I have written the site in, instead of flatfiles, PHP, so as to:

  • Allow easier updating (it includes its own content management system
  • Include a blog for my web development and IT interests
  • Allow site searching (everything is an article or download)

I've written it using a strict MVC model, which means that I have libraries for accessing and manipulating the database; all displays are template driven (meaning I can create them with plain-old HTML); and I can create customizable applications out of various controller libraries. I've called this concoction Dragonfly.

There will be more developments coming -- sitewide search comes to mind, as well as RSS feeds for the blog and downloads.

Stay Tuned!

Continue reading...

Cgiapp: A PHP Class

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.

Continue reading...

B. Gates: Open Source Programmer?

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.

Continue reading...

Scrap that. We're gonna' use PHP

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.

Continue reading...

PHP Class Tips

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.

Continue reading...

HTML::FillInForm

The CGI::Application::ValidateRM module utilizes HTML::FillInForm to fill in values in the form if portions did not pass validation. Basically, it utilizes HTML::Parser to go through and find the elements and match them to values. It's used because the assumption is that you've built your form into an HTML::Template, and that way you don't need to put in program logic into the form.

Seems another good candidate for using FillInForm would be to populate a form with values grabbed from a database... I should look into that as well!

Continue reading...

HTML::Template notes

I've used HTML::Template a little, mainly in the Secret Santa project I did this past Christmas for my wife's family. One thing I disliked was using the normal syntax: <TMPL_VAR NAME=IMAGE_SRC> -- it made looking at it difficult (it wasn't always easy to tell what was an HTML tag, what was plain text, and what was HTML::Template stuff), and it made it impossible to validate my pages before they had data.

Fortunately, there's an alternate syntax: wrap the syntax in HTML comments: <!-- TMPL_VAR NAME=IMAGE_SRC --> does the job. It uses more characters, true, but it gets highlighted different than HTML tags, as well, and that's worth a lot.

And why do I have to say "NAME=" every time? That gets annoying. As it turns out, I can simply say: <!-- TMPL_VAR IMAGE_SRC -->, and that, too will get the job done.

Finally, what about those times when I want to define a template, but have it broken into parts, too? Basically, I want HTML::Template to behave a little like SSI. No worries; there's a TMPL_INCLUDE tag that can do this: <!-- TMPL_INCLUDE NAME="filename.tmpl" -->.

Continue reading...

CGI::Application::ValidateRM and Data::FormValidator

I've been reading a lot of posts lately on the CGI::App mailing list about using CGI::Application::ValidateRM (RM == Run Mode); I finally went and checked it out.

CGI::App::ValRM uses Data::FormValidator in order to do its magic. Interestingly, D::FV is built much like how I've buit our formHandlers library at work -- you specify a list of required fields, and a list of fields that need to be validated against criteria, then provide the criteria. It goes exactly how I would have done our libraries had we been working in perl -- supplying the constraint as a regexp or anonymous sub in a hashref for the field.

Anyways, it looks like the combination of CGI::App::ValRM with CGI::App could greatly simplify any form validations I need to do on the site, which will in turn make me very happy!

Continue reading...