PHP Without PHP—Automattic

Take a simple PHP trick and follow it on a huge tangent to the philosophy of good web architecture.

Presentation was given as Flash Talk at Automattic Meetup in Seaside on September 2010. Presentation originally a long form, but in the spirit of things, I have cut it down.

Automattic is the company I work for. The company is distributed worldwide and once a year we gather at a remote location and meet face-to-face. This year, all the employees are taking a little time during the meetup to compose and give at least one presentation for each other, talking about any subject we are passionate about.

This is based on a PHP Advent article I wrote almost two years ago and formed a low key presentation I used to give in 2009 at conferences. I thought it’d be nice to give a more “traditional” PHP talk—but one which I felt the audience at large could relate to—at the meetup

I hope you enjoy it.

Update

Learning Programming Part 2: Programming Frameworks

A selection of programming language textbooks ...
Image via Wikipedia

(Full disclaimer: I work at Automattic and am a speaker at PHP conferences.)

A couple days ago, Gina Trapani posted an interesting article on learning to program.

This reminds me that some people may take the wrong points away in my last article on the subject, the priority shouldn’t be what language you should learn, but rather, what is going to get you motivated to learn. PHP is a popular language because it naturally invites “immersion” style learning, not because it makes a good teaching language—which it doesn’t. That is, assuming the thing you are immersing in is “building a website”. As I like to say:

PHP is the shortest distance between two points on the web.

In the comments, I wrote:

After [the first] chapter, I’d say [PHP and MySQL Development]offers the most “immersion” gratification (at the least cost) than any other language’s textbook. The chapters are easy and by the end of it you have an eStore written and working from scratch. What do you get at the end of the Learning Python book? And how easy was each subsequent chapter? I’d say much less and much harder.

[Unfortunately,] it’s that first chapter that does the first timer in.

Continue reading about More about learning web programming after the jump.

Autoloading and Lazy Loading

Two and a half years ago, when first wrestling with the Tagged codebase, I asked Andrei about replacing all my PHP includes with __autoload. I was told under no uncertain terms to not do this.

I did it anyway.

It’s not that Andrei is wrong in his admonition. Far from it! For reasons that I don’t quite care to know, there are caching and lookup optimizations that APC cannot do when it has to switch context to run __autoload. But the problem in practice was two-fold:

  1. The company was bug-driven and the easiest way to eliminate an “Undefined class” error was to go into the preinclude script and include it. Voilá! problem solved at the expense of code bloat. (This bug happens often when deserializing nested objects from cache.)
  2. There are slowdowns when you use include_once where include would do, or when you don’t use the full path in your include, or when you construct your full path from symbols. How many of us do this? Heck, I’m still trying to get used to the idea of include_once and require_once. Ahh the days when I’d have to write symbols with every include file!
  3. More to the previous. If you have deep dependencies and don’t use a FrontController pattern, you’re going to have to use require_once() which will get executed multiple times. An __autoload only gets executed once.

At a certain point, optimization gives way to convenience and practicality.

For Tagged, this was that PHP would allocate 12MB/80ms to say “hello world”, 20MB/465ms to display the homepage, and 22MB/1965ms/1207ms to return my profile page

After the rewrite it takes 0.3MB/3ms to say hello world and 3.7MB/109ms to return my profile page.

Continue reading about lazy loading after the jump

My monkey typing resonates

“We’ve all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true.”
—unknown

Chimp typing

Your humble author at work writing this article.

I love to quote people quoting me. I do this by creating a vanity feed— I like to look at it as stalking myself. Skimming my vanity feed last night, I read this:

Terry Chay once said something that resonated with me — one of the few things, actually — and it was something like this: complex > complicated, and that simple does not necessarily mean “not complex”. The point is that you can have a complex implementation that covers many use cases, without the implementation being complicated, and with the API still being relatively simple.
Matthew Weier O’Phinney

Only a few? Geez. I’m (almost) hurt. Next time, I see you, I’m going to call you Matthew O’Phinney.

For reference, here is the talk where Matthew is referring to, along with other previous references.

Since, like Matthew I work on a framework, I thought some of you might find this simple/simplistic complex/complicated distinction resonates with you as you write code.

I can’t claim credit for this idea. It comes from a different monkey, well before the internet:

“Everything should be made as simple as possible, but no simpler.”
Albert Einstein

PHP without PHP

Original article posted to PHP Advent 2008. Happy Christmas!

Take a simple PHP trick and follow it on a huge tangent to the philosophy of good web architecture.

It’s an honor to be asked to share my ideas with the PHP community. When Chris and Sean asked me to write an entry for the Advent Calendar, I had to accept. Like last year, this article will be quite long. If you need something short and sweet like the other advent entries, you can just read the first section. But if you read it all, there might be a worthwhile concept buried in this logorrhea.

Continue reading about My PHP advent article after the jump

Challenges and Choices (Making Frameworks Suck Less Part 2)

As promised, as the election is over, I will get back to blogging non-political things.

And hey, I haven’t posted a continuation of my web frameworks presentation yet!

Good thing too because, if you don’t know, I’m giving a talk on that tonight at CBS Interactive (CNET) in San Francisco. Come see it or watch online at 7:30PM Pacific.

Software is about making choices

"Making Frameworks Suck Less" 2

Challenges and Choices

So the second thing is Challenges and Choices. When I wrote my Rant on Rails, some people jumped on me, but I don’t think they gathered the basic assumption I was coming from.

It is not so much an assumption as a fact: when you develop software, it is about making choices. It is about tradoffs. You can do “A” but you can’t do “B.” You can’t have both A and B. I know it sounds like it’d be great and I’d like to have my cake and eat it too, but really, I’d rather be playing Counterstrike—I only have so much time to devote to writing software, that software can only execute so many times, things like that. I can’t make something do everything.

One example of that is in design patterns.

Continue reading about More part two after the jump.

Another (PHP) Framework

Last month I read Adam’s call OSCON papers. I mention this today because I have to submit something this weekend, but I remember reading something funny.

As usual, they’re desperate for PHP papers. In fact, the only thing they won’t take is a paper about your database abstraction layer or “Yet-Another-CMS“. I find this amusing and true. There are way too many PHP Frameworks out there. Sure PHP-Nuke/PostNuke/XOOPS are great for making a website if you don’t know PHP or have design sense, but knowing any PHP is worse than useless—the more PHP you know, the more offensive they become.

Continue reading