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.

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.

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.

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.

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.)

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.

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.

• Exceptional PHP
• Coding for Success: Writing Software You’ll Be Able To Understand Next Month

Here are some of the books I mentioned…

• Refactoring: Improving the Design of Existing Code
• php|architect’s Guide to PHP Design Patterns
• PHP in Action: Objects, Design, Agility
• Design Patterns: Elements of Reusable Object-Oriented Software
• Implementation Patterns
• Fundamentals of Object-Oriented Design in UML

I’m already looking forward to next year.

I’m still putting the final touches on my slides.

• Exceptional PHP
• Coding for Success: Writing Software You’ll Be Able To Understand Next Month

I’m blogging this from Rob Richards’ Working With Web Services presentation. Oh yeah, I work with Rob. Oh yeah, since, I haven’t posted anything in six months … In January, I moved to San Francisco and started work at Mashery. I realized from talking with Jason last night that I really haven’t mentioned that here. They’ve been keeping me pretty busy, hence the lack of blogging.

php|tek is on twitter. So, I’ve finally signed up there. I don’t get it.

One last thing, Mashery is Hiring good PHP and Javascript programmers.

I am very sad. Two weeks ago, my cousin Sarah had a stroke and died. She was 35, two years younger than me.

As kids, Sarah and I, (along with her sister Rachel) would spend weeks in the summer staying at my grandparents house, playing and doing the things that ten year olds do on a farm. We sat around the campfire at family reunions. We played cards and games, talked and argued. I always looked forward to seeing all my cousins at holidays and family gatherings, but Sarah and Rachel were special then because they were closer to my age.

As adults, Sarah and I also did stuff together on occasion. We still sat around the campfire at the family reunions and visited during the holidays. But, we also went to bars and restaurants, Sarah always knew the best bars. We went to Cedar Point and shared an automobile accident. She would cut my hair and I would fix her computer. But mostly, we just talked. Sarah was just plain easy to talk to and always interesting.

In recent years Sarah moved to Atlanta to build a life for herself there. She opened a salon there and infused it with her character and personality. It was a place where she was at home and happy. I’m sure her clients felt happy and at home there as well. (A client remarks on Sarah’s passing)

But, the most important thing about her move to Atlanta was meeting her husband, Kevin there. I’ve only met Kevin a few times, but the one thing that I know about him is that he made Sarah happy.

I haven’t seen Sarah as much in the last few years. Atlanta is far from Michigan and she disliked flying. She came to fewer and fewer holiday functions. Despite her many invitations to visit Atlanta, I didn’t go.

That is until September, when I went to the php|works conference in Atlanta. One of the reasons I wanted to go to the conference was to be able to see Sarah. After the conference, I stayed with her for a couple days.

Sarah showed me her Salon and I could see how much she loved it. She introduced me to the dogs that she saved. We went out to eat and visited the local Atlanta attractions. But mostly, we talked. We talked about family, dating, kids and careers. We talked about her writing, the gym she liked, the church she had joined and the things she wanted to do.

Sarah tried very hard to convince me to move to Atlanta. I think she felt that all I needed to do was to move there and I would meet the love of my life and l could live there happily to the end of my days. After all, she did.

There is so much that I still want to do with Sarah. I feel like I’ve always taken it for granted that that she would be around for us to “do that later.” I guess not. I’ll miss Sarah.

Sarah’s obituary.

There are probably more than a few naive programmers who would read results like this and start to avoid these constructs in their own code for performance reasons. These are the same kinds of people obsessing over a few single or double quotes, who eschew “slow” objects in favor of switch statements that are many times slower than the polymorphic method calls they are trying to avoid.

But, that’s not the end of the story. Larry ran his benchmarks using 2,000,000 iterations. The N really matters here. Sure, iterators are slower than arrays, but you aren’t going to be iterating over two million things. I tend to fetch my database records in lots of 25 or 50. You aren’t going to be making two million invocations of __call. But how many will you make? Under what value of N does the performance of these techniques cease to matter? Is it ten, one hundred, one thousand, or ten thousand? You may be surprised at how few calls your program actually does and how little impact it has on performance.

As Wez and Travis point out in their comments, profiling is the way to find out the potential impact and to discover your true N.

Paul M. Jones has a good example of what I’m talking about. There, call_user_func_array appears to be a bottleneck, but it turns out that its the function being called, htmlspecialchars, not the calling process that consumes the balance of the time. In that case, the function was “only” called 300 times. I find that order of magnitude to be fairly typical. Something to be aware of, perhaps, but not something to obsess over.

The scale that Cal is talking about is actually better known as modularity:


| Few large modules ---- Sanity? ---- Many Small Modules |


If you haven’t listened to Alan Kay talk about the benefits of many small modules, you should do so now. Alan Kay coined the term Object Oriented. Love OO or hate OO, if you have an opinion on it, you should know what he was thinking. Hint, it wasn’t C++.

On the other end of the scale, One Giant Function is generally known as Big ball of Mud(PDF) Here is Brian Foote’s presentation on the paper (read the paper first).