Richard Thomas

I’ve received some sad news.  Three weeks ago, A colleague of mine, Richard Thomas, passed away of a heart attack.  Those in the PHP community may have known him by his cyberlot handle or by his phpjack web site.

I worked with Richard for a year and a half.  Richard liked solving problems and was always quick to offer solutions when help was needed.  He was an enthusiastic programmer with good attitude. He was well liked.

Richard enjoyed attending PHP conferences.  Richard was active on the Solar framework, writing articles and contributing code.  We had several conversations about a chat project of his, about writing games and various ideas he had.  

Richard is survived by his wife Lisa and four year old daughter Nicollette.  Donations are being accepted to assist them. Even if you haven’t had contact with Richard, consider making a donation if you’ve done freelance work, as Richard was doing at the time of his death. Donations can be sent to:

Niki Fund, 4818 Davis Place #G, Renton WA, 98055

Richard passed away at his computer, doing the work he loved to do. He was 37 years old.

Looking Towards the Cloud

Some people love their automobiles. They can tell you all all about their technical specifications. They buy upgrades and after market parts. Its a lifestyle and a hobby. I am not one of those people. For me an automobile is purely a means to an end. I am here, I want to be there. Having lived the last year without a car (my truck is in storage and will be for sale soon), I can say I don’t much care whether I get there in my car, or a taxi, or a zip car. This is the benefit of modern urban living, I suppose.

So, just as I look at an automobile as a means to an end, I look at servers as a means to an end. I guess that makes me a Software Guy. I know there are Hardware Guys out there. They’re doing great things and I’m thankful for them. But, for the most part, I am interested in what computers can do for us, not how they do it.

I don’t think I’m alone in my attitude. That’s why I think that computing as a commodity a strong future. We can leave things like data center efficiency to someone else and focus on the things that are really important to us. Oh, if you’re at facebook scale, you’re probably going to have to do serious cross stack optimization. And if you are at the hobby end, current cloud offerings may be pricy.

But, consider this. What can you buy with $100,000 per year? One programmer or 120 ec2 instances. (more with reserved instance pricing.)

Cloud Computing Versus Programming Talent

At a certain scale, cloud computing makes alot of sense. $100,000 is just a number. Oh, I know, you have this guy in Belarus and he works for less. But, the fundamental equation is the same. Programming is expensive and computing power is a commodity. Did I mention I’m a software guy?

Are you interested in how to use PHP in the cloud? Clay Loveless recognized the advantages of cloud computing early, jumping on ec2 as one of the early adaptors. He’s recently written a great Introduction to AWS for PHP Programmers. I’d encourage you to check it out.

ZendCon: Writing Maintainable PHP Code

I’ve finally made it to my first Zendcon. Its nice to see some familiar faces and also nice to put new faces to familiar names.

I gave my maintainable PHP talk this morning. I love doing this talk. Thanks to everyone who attended. I’ve put the slides (pdf) up on my talks page.

Much of the material is based on Test Pattern columns that I’ve written for php|architect. Here are some of the specific columns.

Organizing For Change
This is where I developed the outline for the talk
Dependency Injection
This is a more in depth discussion of code reuse and dependency injection
Modeling Dependencies
This is where I talk about coupling, layered design and abstraction
A Closer Look at Cohesion
This is where I developed my explanations of cohesion and the single responsibility principle
Searching the Code
Good designs are searchable

One thing I like about both writing on and presenting on the same material is that I get feedback from the presentations that I can put back into the writing and vise versa. I’m looking forward to finding some better ways to explain layering and the depend on abstractions principle. If you saw the talk, was there anything you particularly liked or needed work? Leave a comment here or on the joined.in page.

Here are some of the books I mentioned in the talk.

PHP in Action: Objects, Design, Agility
This is a really good next step if you’re interested in maintainable code, testing, and object oriented design.
Refactoring: Improving the Design of Existing Code
This is the classic treatment of Refactoring. Probably everyone considering themselves a professional programmer should read this. The examples are in Java, though.
Working Effectively with Legacy Code
This is a good book if you want to start testing and refactoring in a large system that doesn’t currently have tests. Again, the examples are in Java.

I sat in on the PHP Code Review talk this afternoon. I thought it was a great complement to my talk. I tend to be a bit theoretical and this talk was very practical, but we covered a lot of the same principles. Nice talk. Nice scheduling, Zend.

I’m really looking forward to tomorrow. Unfortunately, I have to go back to work on Wednesday.

php | tek Wrapup

I really enjoyed myself at this year’s php | tek. The conference seemed even better than last year. Here are the slides from my talks…

Here are some of the books I mentioned…

I’m already looking forward to next year.

Closures are coming to PHP

Dagfinn has a post looking at using the new closure feature of PHP 5.3. He compares using foreach for iteration versus array_map. “Interesting,” he concludes, “but not necessarily better than conventional alternatives.”

I agree for that case. Consider instead, a more complicated operation that requires a setup and a tear down after.

 
setup();
operation();
teardown();
 

Now what happens if we need to be able to customize operation? That’s common enough, one way of doing this is to create a template method.

 
class MyExample {
    function operation() {}
    function setup() {}
    function teardown() {}
    function doit() {
        $this->setup();
        $this->operation();
        $this->teardown();
    }
}
 

Now, we can subclass MyExample and override operation() with custom logic. This is well and good, but what the customization we need is fairly small. Creating a new class carries a certain weight. Especially if you are religious about one class per file.

 
class MyExampleExtension extends MyExample {
    function operation() {
        // custom logic
    }
}
 

Plus, you now have to deal with some creational patterns to make sure your custom class is used in the right context.

 
$myObject = $registery->get('MyExample');
$myObject->doit();
 

So, instead of encapsulating the pattern, its also very common to just copy and paste:

 
setup();
custom_operation1();
teardown();
//...
setup();
custom_operation2();
teardown();
 

But that’s not good on the duplicate code front. So here is an alternate implementation, but using a closure anonymous function as a callback.

 
class MyExample2 {
    function setup() {}
    function teardown() {}
    function doit($operation) {
        $this->setup();
        $operation();
        $this->teardown();
    }
}
 

The advantage of MyExample2 is that extending is that the setup and teardown pattern is encapsulated in one spot. You konw that if setup is called, teardown will also be called. But, extending the operation is very light weight.

 
$myObject = new MyExample2();
$myObject->doIt(function () { /* custom logic 1 */ });
// ...
$myObject->doIt(function () { /* custom logic 2 */ });
 

There is another significant benefit to this and that is locality of reference. Here, the custom1 logic and the custom2 logic appears in context, not far away in some custom class or function declaration. So you get encapsulation and reuse for the common code parts, but without the sprawl and overhead of declaring structures that will only be used once in a context far away their declaration.

Closures and anonymous functions decrease the activation energy to write good code.

That’s not to say that closures and anonymous functions can’t be abused. If you keep seeing the same logic over and over in an anonymous block, you should probably give it a name in the form of a class, method or function.