The Lost Art of Simplicity – My Take on Josh Holmes’ Brain

1 Comment

Any time someone stands up and says "y'all are doing it wrong" I take notice.  Then I usually lose interest.  But if that person starts to resonate with my own experiences, particularly my own frustrations, then I start to take it seriously.

I have been following Josh Holmes for a little while and he has a talk he started last year called the Lost Art of Simplicity.  I took notice. But I never lost interest. His basic spiel is that we developers make complex solutions for simple problems. Nothing surprising right? Except that he attributed it to ego.  Ouch.  But is that true? Have you ever met a software architect?

That might be a bit of an unfair statement to make but I think there's some truth to it.  And if it's not ego, then it WILL be pride. How do I know?  Because I'm just as guilty. There's nothing more satisfying to a software architect than people looking at your solution and not understanding it, then you explaining how it is a work of art, slowing showing them the beauty of your solution and them finally going "Man, that is COOL!" while secretly they fear actually having to implement it.

But as bad as I have been in my own designs I can say for certain that I have seen this problem many, many times when I worked in Zend Services.  Sometimes people would build these massive applications, find out that the performance sucked, call us up to tune PHP, or hopefully Zend Server (for various reasons I won't go into here) and then be frustrated when I would tell them that their problem is not PHP, their configuration or their tuning.  Their architecture was sucking the life out of the CPU.  And why? For no apparent reason beyond someone who decided upon building a structure that would make their CS professor proud.  I have a news flash for those people. Computers are best used when they are used to solve a problem, not to get you a good grade. Why is this?  Because the problem that's being solved is probably costing money. Do people really spend millions upon millions of dollars on "Enterprise" software because they have money to burn, or to stoke the ego of a software architect? No!

As you might be able to see, this is an issue I have an opinion on. And it is also why Josh's talk resonated with me.

Another part of his talk that resonated with me is when he said that the code you write will still be used in 30 years.  I heard that and I laughed to myself because I was thinking that nobody in the audience believed him.  However, having written a book on the subject, kindof, The IBM i Programmer's Guide to PHP, I have seen this first hand. The people that the book is targeted at are people who have been working with RPG for 20 and 30 years and are now wanting to move onto the web. We in the web world have been a bit spoiled.  We LOVE to rewrite software.  But at some point we need to move on and work on the next problem.  Once that happens, your code may not be changed for a very long time.

Don't believe me? PHP has been around for about 15 years or so.  I have, in my travels, run into code that was originally written for PHP 3 in 1998. This was last year, which makes that code base 12 years old.  I have also run into code written in 2000. That makes that code base 10 years old. With these two examples we're halfway to the 20 years that Josh mentioned. And let me tell you as well, the people who wrote that code wished that they had adopted the art of simplicity much earlier on.

So what's to be learned then? Follow Henry Ford's advise maybe: "Nothing is particularly hard if you divide it into small jobs". Small jobs are simple jobs.  They are manageable, easily repeatable and, by definition, cannot be complex.  Because if they are, they are no longer small.

Best Practices – Part 2

Leave a comment

I just got out of Matthew and Lorna's tutorial on Best Practices and my mind is swimming with all of the things I want to try.  So, pretty much a normal day for me.  Part 1 can be found in the related links on the right hand side.

Part 2 is basically more of the same; a list of all the things you're not doing but probably should.

Let's start with documentation.

End User Documentation

The purpose of end user documentation is to provide a narrative for developers.  In other words, the purpose of providing end user documentation is what is demonstrating how to interface with the software you are writing.  It will often describe architecture, theory and design patterns that you used to implement various parts of your software.  Even though documentation is a very important part of the overall process it is often one that is not often properly done.  Or even partially done.  Part of that might be due to the fact that deciding on the tools to use can be a difficult decision to make.  So here are a few options that you have


If you don't know what a Wiki is by now you're probably been under a rock for the past 10 years.  The basic concept of a Wiki is that it is a community forum where people can edit information.  It is generally easy for others to contribute but is generally un-distributable.  Meaning that besides the HTML interface of the rendered Wiki code you don't really have any ways of distributing it in an alternate format such as PDF or CHM.  Other problems are that it is difficult to translate, since it is fairly free-form and it is usually unversioned.


We may not often think of straight HTML as a documentation format but it can be.  It is easy for people with any web background and can be distributed but is difficult to offer in other formats such as PDF and CHM.  Since it's more structured than a Wiki it can be translated but will run into several of the same problems.

Docbook XML

Docbook was the favorite.  This was easy to say because Matthew said "It's my favorite".  If you are familiar with XML you are already familiar with Docbook, though there are some specific tags and attributes that you need to use.  I found some information on Docbook Stylesheets that might be interesting to highlight some of those.  Some of the benefits of Docbook are that it is reasonably easy to understand and because Docbook is really just an intermediate language you can use it as the glue between various documention formats.  Because it is in a highly structured format it can be both easily translated and it also supports versioning.  One thing to note is that because code can mess up the XML format that most of your code examples should most likely be written within CDATA tags.

The thing to note is that most people can't read XML directly, so you need to render it in the format.  One of the options you have is the PHP Docbook renderer.

Additional documentation

Documentation doesn't necessarily mean "documentation".  Documentation can be a myriad of other things.  It can be

  • Tutorials
  • Installation instructions
  • Examples
  • FAQs
  • Forums
  • User contributed

Lorna said something interesting that I thought was pretty important.  "If you don't know where to get started with an open source project, work on examples."  In other words you know the software, but you don't want to break something so you're unsure as to where to start.  Want to know where to start?  Examples.  There you go.

Be a User-Contributor

  • Answer forum questions
  • You don't need to be an expert
  • Hang out on the IRC channel
  • Help wirth project docs
  • Blog
  • Don't think of yourself as a consumer

The one here that I found the most interesting was that you don't need to be an expert.  Talking to the "experts" can be a little daunting.  They're the experts!  No they're not!  My definition of an expert is someone who knows enough to know they're not an expert. 


Why test?

  • Makes future maintenance of the code easier
  • Defined expectations
  • Test known behaviors
  • Identify early when changes in code break existing behaviors
  • Quantify the quality of your code
  • Code Coverage (not the best metric, doesn't tell the quality of the test)
  • Self-documented behaviors via unit tests

What is not testing?

  • Reloading – In other words, hitting F5
  • Var_dump()

What is testing?

  • Reproducible
  • Automatable

Test Driven Development

Test driven development is a methodology that I have become a recent convert to… big time.  Every customer I have talked to about it has become believers in test driven development.  Zend Framework uses test driven development.  I won't go into how to do it, though I did do a video on it that you can check out.

A couple of things to note about test driven development.

  • Write code to make the tests pass
  • Allows for playing with the API's before you've committed to coding them
  • Often hard to get into the rhythm; once you do it's hard to quite

I would like to spend more time on the subject but that's all I have time for.


I was hoping to end this with part 2 but there's still a lot to cover (Matthew and Lorna had a lot of information).  So I will work later on to finish up with part 3.

Introduction to MongoDB


Today was the first day of the TEK conference tutorials.  These are generally about 3 hours in length and dive into a given topic a little deeper than what you would typically get in a session. The biggest problem is that you can usually only go to one.  Theater hopping, in this case, means that you end up getting less entertained.

There were 3 topics that were given.

  1. Building a Zend Framework application
  2. Converting Your MySQL App to NoSQL with MongoDB
  3. Bad Guy For a Day: A Websecurity hands-on tutorial

While I had previously said I was going to go to the web security one I somehow found myself in the MongoDB tutorial with Kristina Chodorow.  I'm actually kind of glad that I did.  Kristina went through a LOT of information very quickly and gave me a lot to think about and research in the coming days, weeks and years.  It took only about 37 minutes for her to convince me I needed to look at MongoDB seriously.

If you are new to MongoDB, the easiest way to define it is an associative array on a ginormous amount of steroids.  That is a very, very dumbed down definition but that's how you can start.  The feature set contains Document-oriented storage, Replication & High Availability, Auto-Sharding, Querying, Fast In-Place Updates, Map/Reduce and GridFS.  I am currently most interested in the document oriented storage and map/reduce.

The reason I am interested in Document-oriented storage is because as you scale with the amount of data, having perfect relations will become hard and harder.

The reason I am interested in Map/Reduce is because everyone else is talking about it.  I don't do a lot of large data set processing, but if I HAD to I want to know what I need to do.

So, what I could do is go through all of the things that Kristina talked about.  However, then I would miss the talk that Matthew and Lorna are giving.  So what I'm going to do is give you the basics.

First of all, go to the MongoDB website and download a copy.  I am running on Windows right now so I downloaded the Windows version.  I unzipped it on to Desktop, opened up a command shell and started up mongod.exe from the command line.  But prior to starting I needed to create a /data/db directory so Mongo had a place to store its data.  Then I started it.

Starting Mongo

Then what I did was go to the Mongo site and download the PHP driver.  I'm using Zend Server for PHP 5.2 (because I was waiting for the 5.3 download and conference Wifi connections are never good).  So I just copied the NTS Mongo PHP extension and pasted it into the #zendserver/lib/php_ext directory.  From there I opened up the Zend Server extension page and enabled it, restarted and I was ready to go.

Enabling Mongo

At this point, I assume, Mongo DB was running.  So I created a test script and created a new Mongo connection.

$drv = new Mongo();

I ran the script and there were no errors so I was good.  So, the first thing I did was went through the Quickstart guide. The first thing I did was populate the DB with a little bit of data.


So far so good.  The next thing is to try and get that data into PHP.  For that I wrote a very, very simple script.

$drv = new Mongo();
$db = $drv->mydb;

foreach ($db->things->find() as $doc) {

Make sure that you compare the structure between the data I entered and the PHP code I wrote.  My $db is "mydb", compared to "use mydb" in the console.  My table (or collection as it is actually called) is "things". To iterate over the data I need to select my database, select my collection and find() the items on there.  When I run this code I get

array(2) { ["_id"]=> object(MongoId)#6 (0) { } ["name"]=> string(5) "mongo" } array(2) { ["_id"]=> object(MongoId)#7 (0) { } ["x"]=> float(3) }

That's about where I will leave it today.  I am completely new to MongoDB but I was able to get it up and running in about 10 minutes.

There is a lot more to do, but this is enough to get you started.

Best Practices – Part 1

Leave a comment

I am in the middle of Matthew Weier O'Phinney and Lorna Jane Mitchell's talk on PHP Best Practices and after the 3 pages of notes I took in the first hour I wanted to get some things down on virtual paper before getting too far into it.  There is a lot of information that they're giving out.

Source Control

The first thing they talked about was Source Control.  Unfortunately, I was doing my writeup on MongoDB and I missed a bunch of stuff.  That said, there were two things that I had time to write down.

The first thing was "If you are not using Source Control, START!"  I have to agree.  It'd be silly if I disagreed.  The only real question is which source control to use. For that there was a list provided from Wikipedia that gave a comparison of different version control systems that looked pretty useful.

Coding Standards

The next section that they started talking about was that of Coding Standards.  There are a few ways that you can know if you don't have a coding standard.

  1. You reformat it
  2. Code you wrote 6 months ago looks different from today
  3. Modifying old code introduces syntax errors

When trying to determine whether or not you need a coding standard ask your self the following questions.

  1. Can you read your own code
  2. Can others read your code
  3. Can you read someone else’s code
  4. Can you switch between code bases easily

Coding standards assist in the maintainability and collaboratibity of your code.  What this means is that you can have more people working on your code.  Code is structured predictably.  When something is predictable it is easier to have someone new work on your code.  Coding standards decentralize who can work on code.  In other words, when you're on vacation and you don't want to be bothered by some emergency code change that needs to be done you can simply pass it off to someone else who can get working on it faster than you can get to a computer.  And really, after having several umbrella drinks on a Caribbean beach somewhere, would people really want you working on code?

One of the statements  I really appreciated was the statement; "Don’t write your own coding standards!!!  There is nothing special about your code."  When I was working in Zend's Services department I would work hard to encourage customers to embrace some kind of coding standard.  I didn't care which, but they had to chose one.  OK, well, that's not entirely correct.  I told them to use the Zend Framework coding standards because they have already born themselves out in the real world.  But the Zend Framework coding standards were no different from the PEAR coding standards (which ZF stole from) which was no different from the Horde standards (which PEAR stole from).  In other words, the problems that people were trying to solve did not change.  There were some updates made to handle some new cases, but for the most part, the coding standards have been relatively static.

Design Patterns

Design Patterns for me are a bit of a double edged sword.  On one hand they solve a very useful purpose.  They provide common solutions to common problems.  The problem is that there are so many problems that need to be solved that there are, in my mind, too many design patterns.  In other words, because there are so many potential gloves to fit the hand people sometimes worry too much about getting the exact right design pattern.

That said, Design Patterns have a great use if you don't become too overburdened by them.  Lorna did a great job about describing some of the more pertinent.  but she also said something important; "don't invent reasons to use design patterns".


  • Has methods to create and return objects
  • May return different objects
  • May use complex logic to work out the returned object


  • Can be a singleton but not a requirement
  • Register them here but access them elsewhere


  • “Adapts” a specific interface to fit something else
  • Allows the class wrapped by the adapter to exist independently from the component

Root cause analysis – Client got a bit of knowledge!


  • Wraps another class in order to modify its behavior
  • Target class doesn’t change
  • Decorating class often implements the same interface
  • Can be visually decorative, but not always

This one was the most interesting to me because you don't see it much in PHP applications, but the example that Lorna showed looked eerily similar to Swing layouts.  The example looked something like this.

interface LabelIterface
    public function render();

class BasicLabel implements LabelInterface
    public function render()
        return $this->lable->render();

class LabelNewLineDecorator extends BasicLabel
    public function render()
        return $this->labout->render() . "n";
class LabelStarDecorator extends BasicLabel
    public function render()
        return '** ' . $this->labout->render();
class LabelHyphenDecorator extends BasicLabel
    public function render()
        return str_replace(' ', '-', $this->labout->render());

You have some basic functionality, but it is easily extendable.  It "decorates" the original class.  Neat.


  • Watches for changes in another object
  • Responds to those changes
  • Target class is aware, notifies observers

I was thinking about this and this sounds a lot like the Zend Framework plugin and action helper functionality. 

Matthew and Lorna are getting up and running again so this is where I'll stop.  Nevertheless, I made a really good call in attending the Best Practices talk.

TEK-X – What I’m excited about

Leave a comment

This year wil be my first time going to TEK-X and I will be attending as a member of the press.  Therefore, I need to write press-like things.  Lucky for you, I really don't know how to.  Instead, I will be talking for the next week about experiences, observations and such.  But since I'm writing this from my office and not Chicago it is clear that I am not there.  So what I wanted to do was write about some of the features that I am excited to see. 

First of all the tutorials.  Thankfully the tutorials I most want to see are not going to be overlapped.  In the morning is Bad Guy For a Day: A Websecurity hands-on tutorial.  While I know a lot about the best practices on security (I am usually pretty good about finding back ways into protected functionality), I wouldn't necessarily call myself great at it.  So I want to brush up on that.  The next tutorial is PHP Best Practices.  Again, I'm pretty good at it, but I know that Matthew's better and I'm looking forward to hearing Lorna Jane.  Putting my reporter hat on for a second, did anyone else notice that it's the only talk with two people with three names?  Weird.

From there I'm actually quite interested in hearing Josh Holmes' talk The Lost Art of Simplicity.  I, for one, think that modern software is often too complicated.  I've reverse engineered several Java applications (and PHP applications for that matter) where I've asked myself "why in the world did they do that?"  So I think that hearing Josh's take on it will be interesting.

The list of talks can be found on the TEK website.  There are a few talks that I will be particularly interested in attending.  Hopefully there are no conflicts.

Anti-spam and anti-gaming

This one, by Eli White (former colleague of mine), interests me because e_schrade is a massively popular web site and I have the same problems.  Well, no.  Actually, when people are gaming a site they are often trying to trick the site into posting their information, usually in a scripted manner.  So what this really is about is combatting rudimentary AI via Turing tests. I hold no ill-will against robots, as a rule.  However, they must be stopped!

Domain NoSQL: Next Generation Play-Doh

I'm not really a buzz-word kind of guy, but if Matthew's talking about it, I want to hear it.  Also, with the amount of data being stored increasing exponentially traditional relational storage mechanisms are not going to be sufficient.  In fact, they only work when you know what the relationship is.  Jeff Jonas, who is one of those guys who is so smart you feel smarter just by being in the same room, often talks about data finding relationships to other data, instead of the developer defining the relationship. Managing and storing that data will likely not be done in a traditional RDBMS.

Graphs, Edges & Nodes: Untangling the Social Web

Graph Theory is something that has recently become interesting.  This is for the same reason that NoSQL is becoming interesting. This is all about finding relationships.  While the talk will be using an RDBMS example I am hoping that it can be applied to very large storage structures as well.

Building Real-Time Applications with XMPP

Messaging, and not a bigger DB, is key to building highly scalable applications.  Massive scalability is something that really interests me because it is an easy problem to solve, but a very difficult problem to manage. While this is going to be talking about real time messaging I am pretty sure that this talk will, due to the relationship to scalable computing, be pertinent to that.

The Art of Message Queues

Going back to the XMPP talk, messaging queues are something that PHP developers do not do well.  However, as scalablity requires increase and integration with larger systems increases, PHP developers will need to get much better at queuing parts of their application.  I've written several blog posts on the topic of the Zend Server Job Queue.  Message queues are a little different but a different part of the same puzzle.

Data Visualization: Turning Numbers into Stories

One of the reasons I will be going here is because I do a fair amount of work with Ryan Stewart of Adobe and the guy knows his stuff. PHP developers often work in the realm of "boring HTML".  Flash/Flex does some really, really cool things and I want to see more of them.


Those are the ones I want to see.  Make sure to Like us on Facebook because I should be doing blog posts each day, maybe even several each day, and you can easily find them there.