david rasch -- technology. business. life. » PHP

Gallery 2.2–Multisite and Multiroot

drasch — Tue, 25 Sep 2007 02:48:54 +0000

Recently I tried to use the Gallery Multiroot module/plugin to setup a new site based upon an existing Album in our gallery. Since we started sorting albums chronologically, we wanted to sort out the Dachshund photos separately. To do this, I used the Multiroot feature. Unfortunately, I couldn’t get this to work as I’m already using the Multisite plugin to host several Galleries off of my web server. The magic touch was to use the following file, the first line is key and had to be added to make things work in the Multisite configuration.

define('GALLERY_CONFIG_DIR', "/var/virtualwww/gallery.raschnet.com");  //I had to add this line

require('/usr/local/share/gallery2/embed.php');
$ret = GalleryEmbed::init(
    array('embedUri' => '/',
          'g2Uri' => 'http://gallery.raschnet.com/',
          'apiVersion' => array(1, 2)
    ));

if ($ret) {
    print '' . $ret->getAsHtml() . '';
    return;
}

$gallery->setConfig('login', true);
$gallery->setConfig('defaultAlbumId', 28426);
$gallery->setConfig('breadcrumbRootId', 28426);

GalleryMain();

Now live: DRNA Gallery

Blog Tweaks

drasch — Sun, 23 Sep 2007 02:38:28 +0000

Made some tweaks to the blog:

using tags instead of categories google ads amazon wishlist I learned lots more about widgets integration with . . . → Read More: Blog Tweaks

PHP on the Backend (part 2)

drasch — Tue, 08 May 2007 23:34:02 +0000

To run the class I posted yesterday, I typically use a class called DaemonRunner. This class sets up for proper signal handling, and ‘executes’ the class extended from Daemon.

declare(ticks=1);

class DaemonRunner {
    public static function exec($className) {
        $argv = $_SERVER['argv'];
        $daemon = new $className($argv);
        $daemon->init();
        while (!$daemon->isDone()) {
            $daemon->run();
        }
        $daemon->shutdown();
    }
}

The first statement is a PHPism. This allows PHP to check for signals every 1 tick. A tick is simply a low-level PHP interpreter step. The way I’ve setup my daemon and signal handling by default, the PHP will finish its current iteration and then quit when receiving a signal. This ensures that the database, and whatever background stuff aren’t left in inconsistent states. As with anything, you’re free to modify, extend, or otherwise alter this behavior.

PHP on the Backend

drasch — Tue, 08 May 2007 00:55:39 +0000

PHP (or any language for that matter) can just as easily be used as a daemon as on the web. This can be especially useful when solving problems that can’t “complete” in less than 500 ms which one shoots for on the web. As you write an application to handle things such as those mentioned below, be sensitive to the processing, disk space, and time needed to process these requests in planning how to handle these. As an example jobs of a small size might be handled inline by the code that handles the form submission, but for larger jobs it queues them for background processing.

great for background/async processing of:

photos
movies
reports
imports of data

advantages:

use the same codebase as your app
use the same expertise on your team of programmers

challenges:

signals
one thread
memory (this will have to be a whole separate article)
starting and stopping

A typical Daemon class I use:

abstract class Daemon {
    protected $done = false;

    public function __construct($argv) {
    }
    public function init() {
        pnctl_signal(SIGTERM, array($this, "onSignal"));
        pnctl_signal(SIGINT, array($this, "onSignal"));

    }
    abstract public function run();
    public function shutdown() {}
    public function isDone() {
        return $this->done;
    }
    public onSignal($signal){
        switch ($signal) {
             case SIGTERM:
             case SIGINT:
                $this->done = true;
                 break;
             default:
                 // handle all other signals
        }
    }
}

As you can see, we’ve started to tackle some of the challenges here. The idea is to handle signals, specifically I usually care about SIGTERM (default when using ‘kill’ on *nix) and SIGINT (from pressing Ctrl-C). Both will cause the program to exit gracefully.

I’ll be posting the class I use to run Daemon’s tomorrow.

TriPUG and MySQL Talk on Memcache and PHP

drasch — Fri, 04 May 2007 01:03:45 +0000

Memcache is an extension written by Danga for simple Key/Value pair caching for use with your favorite programming language. In this talk I demonstrate how to install, integrate, and leverage Memcache in PHP (using MySQL for a database). I build a sample application, demonstrate less than desirable performance and finally, return performance with a 100x improvement.

The whole talk and its supporting files can also be downloaded.

ditched the Zend Framework

drasch — Tue, 20 Mar 2007 01:41:00 +0000

I’ve ditched the Zend Framework on a project. In it’s place, Symfony has allowed me to recreate all the work with the Zend Framework over several months in a matter of 4 hours.

The Zend Framework proved to be:

too piecemeal
incomplete – arguably this is represented by the version number; but this applied to both individual components being incomplete and the lack of a complete offering for a whole application
in flux – changing each time we updated such that it was difficult to get the newer components without breaking lots of our code
too rigid – we found it far too rigid and requiring much code diving, without much direction, to redirect some of the logic especially in the Controller framework

All in all, Symfony has proved very easy to use, and has many facets and components I haven’t yet even been able to take advantage of.

Zend Framework and PDO_MYSQL

drasch — Wed, 07 Feb 2007 03:35:58 +0000

I’ve been working with the Zend Framework a bit and in working with MySQL through PDO_MYSQL. I’ve run into a few problems trying to use parameters of queries.

I’ve narrowed the issue down to PDO itself and not the Zend Framework.

$dbh = new PDO("mysql:host=localhost;dbname=db","user","pw"); $query = "insert into silo_test_data (record_id, fieldname, value) values (3,'stufftest', :value )"; $handle = $dbh->prepare($query); $handle->execute(array(":value" => 'crap')); $dbh = null;

The value gets inserted into the database as an empty string, or sometimes some low-value bytes. I’ve managed to work around this temporarily thanks to some help from this post. By setting PDO to emulate prepared statements, everything seems to work okay.

$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

The problem is, the Zend framework encapsulates the actual db connection and connects lazily. So, for now I’m running a query and then set the parameter on the encapsulated connection object.

$db_connect = array( 'host' => $config->db->hostname, 'username' => $config->db->username, 'password' => $config->db->password, 'dbname' => $config->db->database ); $db = Zend_Db::factory('PDO_MYSQL', $db_connect); $db->query('select 1');//HACK HACK HACK HACK to initiate connection. Can't I make this a plugin? or extend the class? $db->getConnection()->setAttribute(PDO::ATTR_EMULATE_PREPARES, true); Zend::register('db',$db);

don’t eat paste (learning PHP part iii)

drasch — Tue, 17 Oct 2006 03:26:44 +0000

Hi, David. This is an interesting approach, but I think it’s a solution to a slightly different problem than teaching someone PHP. Instead, it’s a solution to teaching someone the basics of building a web app and you just happen to use PHP to teach those concepts. A perfectly worthwhile and desirable goal, but different.
…

David Sklar

I agree and disagree with some of the points Sklar (sorry, two David’s makes this confusing) goes on to make. If I may paraphrase, Sklar is raising a point which competes with that raised by Ben in our initial discussion. My initial suggestion in the discussion with Ben indicated that books should start by teaching PHP on the command-line and slowly build up to constructing a very lightweight MVC framework and example application. One of Ben’s chief, and valid, concerns equated selling books about PHP with convincing readers or page-flippers that the book would teach them to build web pages in the first few chapters. Or that individuals might be turned off if they weren’t creating XSS attacks willy-nilly by chapter 3. I think the counter to this that Sklar raised is that by hiding the framework you turn off the people who don’t feel they’re really getting their feet wet with PHP. They feel that by using your framework they aren’t learning the ‘real guts’ of the language.

This clearly relates directly to some of the arguments Sklar makes that other languages face this challenge as well, but PHP perhaps more so than others. PHP digs its own hole here because unlike a .NET, Java, or a ColdFusion, PHP has built its name on easy to learn and get going. You can pay $4.99/month and get a server running PHP in 10 minutes. Writing an application in any of these other platforms can take orders of magnitude longer to setup, there’s an expectation of barrier to entry for learning, and often you have to buy pieces of it like an IDE. Sklar indicates that it’s important to strike the balance between “a way to do things” and “the way to do things”.

The dilemma lies in choosing whether I ask the reader to take on faith that the framework underlying the first half of the book isn’t worth delving into right now, but is worth understanding later and either using the quick framework or garner enough knowledge of the principles to build your own. Or, do I go back to my original plan of introducing PHP on the command-line as we built up a small framework and graduate up to a web page far later in the book.

I have full confidence that either approach might work. I know universities teach Physics both with and without calculus to which I’m sure the physics professors initially said “you can’t teach physics without calculus, it’s heresy!” But, this day in age there’s only one physics. I know my economics professor told me she didn’t like math, but she managed to teach a great class about economics concepts by moving lines back and forth on graphs.

[tags]learning php, programming, computer science, php, php books[/tags]

Learning PHP sans bad habits

drasch — Fri, 13 Oct 2006 02:53:15 +0000

I’ve received some fatalistic responses to my last installment related to what I see as problems with PHP teachings. In particular, I fear we teach people to write applications in ways that are reckless to the fact that these individuals likely read no more than 1-2 PHP books and move on to start writing their application.

Now I’ll present some solutions I propose to the challenges of teaching PHP without encouraging bad habits from the beginning.

Chapter 1: Intro to PHP syntax using the commnd-line
Chapter 2: Make your first dynamic web page using our small framework (hello world)
The framework handles: data escaping input and output, proper sql injection protection, and data/presentation separation. The student needn’t understand all of this yet, but will be explained.
Chapter 3: Variables & Arrays
Chapter 4: Conditionals, Loops & Functions
Chapter 5: Classes
Chapter 6: Sending/Receiving data on the web.
Chapter 7: How to create additional pages in the framework
Chapter 8: Creating forms
Chapter 9: Dissect the framework input/output, presentation and database aspects
Chapter 10: Show how failing to do these things is insecure
Chapter 11: Create additional views/flow using OO framework
Chapter 12: Create a simple application with 3-4 views

This describes the mostly the PHP aspects of a book. This book could easily use SQLite and save the MySQL for another book where it can be properly introduced. It could also include some MySQL education to increase its marketability. The framework itself sounds like a big undertaking, but in fact it can be kept extremely simple as governed by the examples put forth herein. In addition, the frameworks simplicity will allow it to be dissected later in the book for the education of the reader. Finally, when someone finishes the book (or the worst risk with current books if they don’t finish it, they’ll still have the right ideas and not go willy-nilly writing an application using $_GET and $_POST without thinking twice.

[tags]teaching, learning, php[/tags]

PHP Appalachia

drasch — Sun, 01 Oct 2006 04:26:34 +0000

Brian and I went to PHP Appalachia this Wednesday and Thursday. Different from a traditional conference, the Cherokee, NC KOA served as the main venue for PHP Appalachia. The two of us stayed in a Kabin with a full bed and a set of bunks. All of us hiked, chatted, and met with the other attendees until we left mid-day on Thursday.

We sat around the fire on Wednesday night chatting about PHP when Ben Ramsey and I entered an interesting discussion about PHP’s future and how to introduce newbies to PHP.

I’ll define the sterotype which serves as the premise for this discussion. Most books that introduce PHP, even those which rely on previous programming knowledge begin with an example like this:

print "hello world";

This example will be soon followed within the next 1-3 chapters (sometimes after, sometimes before introducing loops, conditions, and other basic language constructs of PHP) by an example like this:

print $_GET['foo'];

In any/all books it’s far later in the book where Object-Oriented programming is covered. In the coverage of creating forms, handling GET/POST/Cookies/Session there’s relatively little talk of security, escaping, or encodings.

The long and short is that people learn PHP in a way that first teaches them to design web applications in a poorly maintainable, insecure, and generally poor method. With the advent frameworks like the Zend Framework and other MVC-based libraries there’s no need to teach bad habits that result in a bad name for PHP.

[tags]php, books, rant[/tags]