FUNKATRON

The standard line about the history of Punk is that it was a reaction to the excesses of modern rock, particularly progressive rock of the time. The reality is undoubtedly more complex, but I suspect there is some truth to that. Rock n roll did seem to be the realm of Golden Gods in the late 60s and 70s, inaccessible to average folk. The contrast between bands like Rush and Black Flag –– both supposedly playing “rock” –– was extreme.

For fun, let’s take a look at Rush drummer Neil Peart’s drum kit:

Now, here’s Black Flag playing in LA in 1979:

You can fit the entirety of Black Flag in the space of Neil Peart’s drum kit. And they would still play awesome shit and rock you the fuck out.

In the past few years, the PHP Zeitgeist seems like it’s been moving in the Neil Peart direction. Lots of work by lots of smart people is going into complex, verbose solutions. Lots of files, lots of nested directories, and lots of rules. I frequently see PHP libraries/components that look like this:

All that, just to start your application.

It doesn’t mean this approach is bad, per se. But when I see it, I have a visceral negative reaction. My brain screams

FUCK.

THAT.

SHIT.

I can’t do it. I don’t want it. And I don’t think we have to do it this way to do cool things and build awesome stuff.

The approach I’ve been taking lately is to start with as lightweight a foundation as possible, in the form of a “microframework.” A few of these exist for PHP (of course), including Slim, Epiphany, Breeze, Limonade, and others. For additional functionality, I pull in lightweight libraries that help me accomplish only the tasks I need. Clarity and brevity are my top considerations.

My other big consideration is the commitment I make when I use code I didn’t write. Typically I don’t have time to do a full code audit on libraries, so there’s a level of trust that goes with it. And each dependency means more trust. Not just that there aren’t bugs (I expect that if they’re anything like me), but security issues – both whether they exist, and how they will be handled. Will an announcement go out to a mailing list? How long will security fixes be provided that don’t break backwards compatibility? Will I have to upgrade all my dependencies if I upgrade to the next PHP point release? And all of that assumes the author will have the time and motivation to provide prompt fixes. If they don’t, you’ve just added a bunch of technical debt to your codebase.

Finding lightweight libraries that don’t pull in lots of additional code dependencies is much harder than it should be. Mostly I think that’s attributable to PHP devs being more interested in framework-specific development. Some work is being done to make mature frameworks less monolithic, and many devs on Twitter have recommended Symfony components as an option. Unfortunately, I think my definition of “lightweight” is not the same as theirs.

Here’s the cloc output for a git clone of the symfony2 HTTP Kernel component:

Mon Dec 26 19:42:23 EST 2011
coj@PsychoMantis ~/Sites > cloc HttpKernel
      94 text files.
      93 unique files.
      12 files ignored.

http://cloc.sourceforge.net v 1.53  T=0.5 s (164.0 files/s, 18736.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             72           1175           3440           4290
Bourne Shell                    10             56            155            252
-------------------------------------------------------------------------------
SUM:                            82           1231           3595           4542
-------------------------------------------------------------------------------

Here’s the same for the Slim framework:

Mon Dec 26 19:42:27 EST 2011
coj@PsychoMantis ~/Sites > cloc Slim
      54 text files.
      51 unique files.
      13 files ignored.

http://cloc.sourceforge.net v 1.53  T=0.5 s (82.0 files/s, 17752.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             31            660           4473           3280
Bourne Shell                    10             56            155            252
-------------------------------------------------------------------------------
SUM:                            41            716           4628           3532
-------------------------------------------------------------------------------

and the Epiphany framework:

Mon Dec 26 19:42:30 EST 2011
coj@PsychoMantis ~/Sites > cloc Epiphany
      83 text files.
      70 unique files.
      31 files ignored.

http://cloc.sourceforge.net v 1.53  T=0.5 s (102.0 files/s, 5246.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             40            218            309           1632
Bourne Shell                    10             56            155            252
HTML                             1              0              0              1
-------------------------------------------------------------------------------
SUM:                            51            274            464           1885
-------------------------------------------------------------------------------

When there are more files and lines of code in your component than in my entire base framework, I can’t call it “lightweight.”

It doesn’t mean that stuff is bad, in the grand scheme of things. It doesn’t mean it has no value or is the wrong approach for many. But it’s the wrong approach for me, for sure. And I don’t think I am alone.

I don’t want to be the prog rock superstar, writing a pretentious rock opera. I want to play shitty power chords in a punk rock band that plays shows in a VFW lodge with no stage, and leaves you so fucking pumped that you go out and form your own band. That’s the coder I want to be.

I don’t want to be Neil Peart. I want to be Gregg Ginn.

So I wrote this. A “micro PHP manifesto,” if you will. I plan to use it to guide my PHP dev. Maybe you will find it useful as well.

I am a PHP developer

• I am not a Zend Framework or Symfony or CakePHP developer
• I think PHP is complicated enough

I like building small things

• I like building small things with simple purposes
• I like to make things that solve problems
• I like building small things that work together to solve larger problems

I want less code, not more

• I want to write less code, not more
• I want to manage less code, not more
• I want to support less code, not more
• I need to justify every piece of code I add to a project

I like simple, readable code

• I want to write code that is easily understood
• I want code that is easily verifiable

One of the coolest things about working on Gimme Bar has been the opportunity to build a platform. While most folks interact with our service via the web site, the site is just one application built on top of the Gimme Bar content collection and curation system. Our web site interacts with the system via our HTTP API, which is open to everyone, not just our internal team. That means that anyone can build applications on top of our platform to suit their own needs or interests.

To demonstrate this, I built GimmeMe, a simple tumblelog-type web app that’s powered by Gimme Bar. It uses methods in our API that don’t require authentication, so you don’t need to register with us to use it. And it’s a drop-in, set-one-option-and-go install, so you don’t need to fiddle with a bunch of stuff to use it (but you can if you want).

I have a running demo on my web server at http://funkatron.com/GimmeMe. It shows the 50 most recent pieces of content I’ve grabbed with Gimme Bar.

Installation

To install the web app yourself, you’ll need a web server with:

• PHP 5.2.x or above
• APC 3.0.8 or above

Install as follows:

1. Download the source code as a .zip or .tar.gz from the project’s download page
2. Decompress the files somewhere under your web server’s document root
3. Edit the $config['username'] value in index.php 4 .Optionally set the $config['gb_addthis_pubid'] value to include AddThis widgets, if you’re into that kind of thing
4. Load the appropriate URL in your web browser to view the install on your web server

The Code

If you’re a developer type, you’ll probably want to poke around the source code in the GitHub repo. The main work is done by libs/GimmeMe.php, which handles grabbing data from the API, caching it, and rendering the HTML.

In GimmeMe::getAssets(), we load the data using the GET /public/assets/:username method. This returns a JSON object with an array of asset data in the records propert. We decode the response JSON into a PHP object (the $assets variable), and add a couple properties that we’ll use in the HTML template. Then we cache the object in APC, and return it. Next time around, if the cached object has not expired, it will just pull it from APC and return it, so we don’t make more requests to the API than necessary.

The GimmeMe::render() method loops through the assets we retrieved and makes each one into a GimmeAsset object. GimmeAssets are view objects used by the Mustache templating library to encapsulate display logic, so we set up special methods or data massage in there. After we set those up for each asset, the entire data structure is passed to the Mustache library for rendering, using the ‘page’ template defined in templates\templates.php.

Right now I also am including a a simple router class at vendors\Router.php. We’ll need this for stuff that would involve different URLs, like paging back through assets or loading single-asset pages, but I haven’t quite gotten that far.

---

I’d be remiss in not mentioning http://hereslookingathue.com/, a collection of beautiful imagery collected and organized by Gimme Bar user hereslookingathue. It’s another cool example powered by our public API methods.

Hopefully this gives you a taste of what’s possible with the Gimme Bar API. Most read-only things, like embeddable widgets or reposting tools, would be easy to do with just the public API methods. Beyond that, the vast majority of our system is exposed through the public API, so powerful collection, replication, and organization applications can be built.

If you have questions or comments, please hit us up on Freenode at #gimmebar-api, or email us at api@gimmebar.com.

Photo by rovingI