Don’t Bet Against Language Features

Remember when all the blogs in PHP land were telling you to use single quotes because double quotes are slow? I was a heavy PHP user at the time, and man I sure do. The advice was actually factually correct at the time, but has long been fixed in PHP, and it would never have mattered in your application anyways. I have seen this scenario play out again – this time with JavaScript Promises.

Be wary anytime you hear something along the lines of “use X instead of Y, because Y is slow” – where Y is a built-in programming language feature. This argument crops up from time to time, but it is almost always a complete non-issue in the long run. Continue reading

Fixing Homebrew on OSX 10.10 Yosemite

If you upgraded to OSX 10.10 Yosemite, and now have a broken homebrew, fear not

  • the homebrew team has already fixed this!

Luckily, the steps to fix it are fairly simple.

First, update homebrew via git:

cd /usr/local/Library git pull origin master

Next, use homebrew to update and clean your installed packages:

brew update brew prune brew doctor

Now you should be all set!

Footnote:

I originally found (and tweeted about) this article when searching for a fix, but ran into more issues after editing the brew.rb file, and eventually came to the solution of updating homebrew itself after seeing that the homebrew team had fixed the issue themselves.

Hiding Variables From PHP’s var_dump()

NOTE: This post is irrelevant for PHP 5.6+: a new __debugInfo() magic method has made its way into PHP 5.6, so use that as the best solution to this issue.


A common problem I have in PHP is that when I deal with larger objects with multiple dependencies or circular references, var_dump() becomes effectively useless. Often times it spits out huge numbers of objects that were set as a dependency on the object I wanted to inspect that I didn’t even know were there. Even worse, there are often circular references and other things that get in the way. The signal-to-noise ratio is way off the charts.

Playing Hide-and-seek with var_dump()

So is there a way to effectively “hide” a variable from functions like var_dump, print_r, and var_export? Turns out, there is – but it does come with some serious trade-offs.

The first thing you need to know is that there is no way to hide an object property. Object properties will all be dumped, no matter the scope – public, protected, or private.

The trick (or hack, if you will) relies on using a very handy but little-used feature of PHP: static variables. No, not static class properties – static variables. You may have seen them, or even used them yourself a time or two:

<?php
 function connection() {
     static $connection;
     if ($connection === null) {
         $connection = new DatabaseConnection();
     }
     return $connection;
 }

Basically our connection function acts as a kind of factory. The $connection variable here is cached between function calls so that the object is only ever created once, and then simply returned on subsequent calls. The static declaration before our variable tells PHP that this variable will maintain its value within the current execution scope, much like a static class property maintains its value across multiple object creations.

That’s Great, But Now Your Dependecy Is Hard-Coded

The more experienced coders among you may have noticed that using this approach, we can no longer use constructor dependency injecton. At least – not exactly like we used to.

Remember when I said solving this problem comes with some serious trade-offs? Okay, stay with me here. We can still use dependency injection.

The main design trade-off you will have to make if you want to use this approach is that you will have to create a single method that is both a getter and setter for each object dependecy you want to inject. This is best illustrated by example:

<?php
 function connection(DatabaseConnection $newConnection = null) {
     static $connection;
     if ($newConnection !== null) {
         $connection = $newConnection;
     }
     return $connection;
 }

Okay, so now we have modified our function to be both a setter and a getter. We can now use this function to set our dependecy upon object creation, and to get the connection we need to use in place of the typical object property.

Using Dependency Injection In An Object

So now, instead of setting an object property and using that object property for our dependency like so:

<?php
 class DoStuff {
     protected $connection;

     public function __construct(DatabaseConnection $connection)
     {
         $this->connection = $connection;
     }

     public function someQuery()
     {
         $this->connection->query("SELECT ... blah blah blah");
     }
 }

We can remove the object property and replace it with our new method, and use our connection method as a setter in the constructor (while still using dependecy injection), and then use our connection method anywhere we need it as a getter.

<?php
 class DoStuff {
     public function __construct(DatabaseConnection $connection)
     {
         // Setter
         $this->connection($connection);
     }

     public function connection(DatabaseConnection $newConnection = null)
     {
         static $connection;
         if ($newConnection !== null) {
             $connection = $newConnection;
         }
         return $connection;
     }

     public function someQuery()
     {
         // Getter
         $this->connection()->query("SELECT ... blah blah blah");
     }
 }

And there we have it. We get the same functionality with a little bit more code, except now our dependent object is completely hidden from var_dump, because it is not an object property. It’s just a variable inside a method, which no PHP inspector function will display.

Benefits To This Approach

  1. The dependency is completely hidden from var_dump, var_export and print_r. This results in nice and clean debugging dumps without any large dependency graphs or circular references.
  2. Your database and service credentials are safe. Related to #1 – this is such a huge benefit by itself that is has to have its own point. How many times have you dumped the contents of an object only to see a database connection dependency or API service dependency also dump out all your connection information, usernames, passwords, and API keys? Hopefully this never happens in production, but even in development, this is irritating.
  3. Save time and hassle. Sometimes dumping an object’s contents can be unexpectedly gigantic. In these cases, most of your time spent debugging is scrolling through pages and pages of junk you don’t need to find the one piece of information you’re actually looking for. This can be very frustrating, especially if you’re in an edit-debug cycle where you are repeating this multiple times in quick succession.

Drawbacks To This Approach

So… trade-offs, right? Here are the main ones I have seen:

  1. You have to use a combined getter/setter method. This is because the static variable’s scope only exists inside the method it is defined in. I personally like single-word combined getter/setter methods, because they simplify and reduce the surface area of your object’s API, so this may not even be a drawback to you.
  2. The object reference will now be static. This is probably okay for most objects you pass that are setup once and remain constant, like a DatabaseConnection object would be, but it won’t be okay for other scenarios, like a collection of result objects or anything else that may change for each new object instance you want to create.

    (Update: I previously said the object reference won’t change (mutate) anymore once set with this method, but my tests on that were flawed.)

  3. The code might be confusing. Simplicity has a lot of value. This approach does add a little bit of complexity to the code, and may be a little harder to understand and debug, especially for beginners. It’s likely that people will see this code and say something like “Why don’t you just use an object property?”, because what it is doing is not immediately obvious.

If you are using this approach and can think of any other benefits or drawbacks, let me know and I will update this post. Hiding variables from var_dump and other similar functions is something I really wish was built-in PHP.

UPDATE: I have been informed that a new __debugInfo() magic method has made its way into PHP 5.6 – this is exactly what I was looking for, so now you just have to upgrade when PHP 5.6 has a stable release 🙂

Valitron: The Simple Validation Library That Doesn’t Suck

Valitron is a simple, minimal and elegant stand-alone PHP validation library with NO dependencies. Valitron uses simple, straightforward validation methods with a focus on readable and concise syntax.

Why Another Validation Library?

Valitron was created out of frustration with other validation libraries that have dependencies on large components from other frameworks unrelated to validation like Illuminate Validation (laravel 4) requiring  Symfony HttpFoundation, pulling in a ton of extra files that aren’t needed for basic validation. It also has purposefully simple syntax used to run all validations in one call instead of individually validating each value by instantiating new classes and validating values one at a time like Respect Validation requires you to do. Valitron also has a focus on being concise – validation rules are just a single line per rule, and can include multiple fields in an array. This is handy, because in most use cases, a single validation rule – like “required” will be applied to many fields, so it doesn’t make sense to start with the field first like Fuel Validation does.

In short, Valitron is everything you’ve been looking for in a validation library but haven’t been able to find until now: simple pragmatic syntax, lightweight code that makes sense, extensibility for custom callbacks and validations, good test coverage, and no dependencies.

Usage Example

Valitron is made to setup all your validation rules on the fields you need, and then run all the validations in one call. This is better than validating the fields one-by-one, because that approach causes a lot of “if” statements and branching logic that doesn’t make the resulting code any better than doing the validations by hand (which obviously sucks).

<?php
$v = new Valitron\Validator($_POST);
// Input array
$v->rule('required', ['name', 'email', 'date_start']);
$v->rule('email', 'email'); // Email uses filter_var
$v->rule('dateAfter', 'date_start', new \DateTime()); // After today
if($v->validate()) {
     echo "Yay! We're all good!";
     print_r($v->data());
} else {
     // Errors
     print_r($v->errors());
}

More usage examples and documentation can be found on the Valitron GitHub Page. Valitron is on Packagist, and can be installed via Composer.

Introducing Bullet: The Functional PHP Micro-Framework

Bullet is a new PHP micro-framework with a unique functional approach to URL routing that allows for more flexibility and requires less verbosity than the more typical full route+callback approach found in other micro-frameworks.

The Problem with Independent Scope

The main problem with most micro-frameworks and even full-stack MVC frameworks that leads to code duplication is that the callback or method executed to perform the action and respond to the URL route lives fully within its own scope. This means that you are forced to repeat a lot of setup code across URL route handlers that load the same resource, authorize it, etc.

Some typical micro-framework code might look like this:

<?php
// View single post
$app->get('/posts/:id', function($id) {
     $post = Post::find($id);
     check_user_acl_for($post);
     // ...
});

// Delete post
$app->delete('/posts/:id', function($id) {
     $post = Post::find($id);
     check_user_acl_for($post);
     $post->delete();
     // ...
});

// Edit post
$app->get('/posts/:id/edit', function($id) {
     $post = Post::find($id);
     check_user_acl_for($post);
     // ...
});

You may be able to move the ACL check to a middleware layer or “before” hook if the framework supports it, but there is always a certain amount of duplicate code you will either never be able to get rid of, or have to jump through hoops to get rid of (like adding more abstraction or re-checking the current URL, etc).

The Benefits of Shared Scope

Bullet uses a unique nested callback style that splits the URL by directory separator and only handles a single part of the URL at a time with it’s own callback. At first blush, this approach might seem like more work, but the key to how Bullet works is that nested closures – by definition – can use variables defined in the scope of their parent. This leads to some pretty powerful and profund capabilities that can only be done using the same nested closure style that Bullet uses.

Continue reading

Handling Exceptions in Gearman Tasks (Even Background Ones)

I recently had some issues with Gearman tasks throwing exceptions and killing the whole Gearman daemon. This made it nearly impossible to trace errors back to their origin, because the logged exception stack trace didn’t provide much useful information, because it just logged where it failed in Gearman – not the actual file and line of code that was doing the work. I dug into the code and started trying things like GearmanClient::setExceptionCallback and running the tasks, but since the tasks were being run with addTaskBackground instead of just addTask, the callbacks were never getting executed, and I still was not able to do anything to handle exceptions for the jobs that were being run (and they were still killing the Gearman daemon). Clearly, I was going to have to get a little more creative.

The only other place to add code that will catch exceptions for all jobs run is in the GearmanWorker::addFunction method. So I looked at the following one-liner for adding named job callbacks:

<?php
$worker->addFunction($name, $task);

And replaced it with a closure that uses a try/catch and then logs any exceptions to Exceptional so we can see the full stack trace and exact point of failure for any job – even background jobs:

<?php
$worker->addFunction($name, function() use($task) {
     try {
         $result = call_user_func_array($task, func_get_args());
     } catch(\Exception $e) {
         $result = GEARMAN_WORK_EXCEPTION;
         echo "Gearman: CAUGHT EXCEPTION: " . $e->getMessage();
         // Send exception to Exceptional so it can be logged with details
         Exceptional::handle_exception($e, FALSE);
     }

     return $result;
});

And it works beautifully. Now all the jobs are run, the Gearman daemon is never killed by a PHP process, and all the exceptions are logged with full granular details that makes it easy to troubleshoot and fix any errors.

Count the Number of Object keys/properties in Node.js

When using the excellent formidable library to handle file uploads, I needed to get a count of the number of files unloaded in a multi-part form. Javascript arrays have a .length property that you can use, but objects do not. I instinctively typed:files.length

Which returned undefined. So if there is no length property present, an easy way to count the number of keys or properties of an object in ES5-compliant javascript environments like Node.js is to use the Object prototype directly:

Object.keys(files).length

A little more typing, but it is fast, efficient, and most importantly: already built-in.

Protected vs Private Scope: Arrogance, Fear, and Handcuffs

The age old private vs protected debate has been re-ignited in the PHP community recently following the decision of Doctrine2 and Symfony2 to make all class methods private until there is a very clear and proven reason to change them to protected or public. The intention is a good one – to ensure they are providing a clear and stable API through intentional and known extension points that they can better test and support. Fabien (the creator of Symfony) points to this benefit in an article of his own explaining the thinking behind the decision. The primary started point of Fabien’s article and the driving thought behind this whole change and philosophy is (emphasis his):

Having a few well defined extension points force the developer to extend your library the right way instead of hacking your code.

The problem is that this kind of thinking is a slippery slope that kills the spirit of programming. It alienates the more pragmatic developers within communities. Telling other developers that you are going to force them to work with your code in some pre-determined "right way" is an incredibly arrogant statement to make. more Instead of letting the codebase grow organically and be modified or extended at will, you handcuff developers and send them a different message. Allow me to re-phrase it using my own words:

I know the right way to use this code and I have thought of all the possible use cases. If you don’t agree, then you have to prove me wrong and wait until I either agree or figure out a better right way for you.

This is the real message developers hear when internal code is private scope or marked with the final keyword – a message that they have arbitrarily limited power and ability to make changes where they need to. But it doesn’t stop there.

When you take the position that all methods should be private unless proven otherwise, you plant a seed of fear in the developers that use your code. Fear that whenever they may have to veer off the beaten path to meet a project requirement they won’t be able to. Fear that they might miss deadlines waiting for the "right way"  to enable the functionality they need. Fear that they might have to modify or hack the actual file or class they need to change the behavior of to achieve the functionality they want within the project deadline because they are not able to extend it.

Using private scope removes the fun from programming and kills the hacking spirit by creating fear through the knowledge that you will not have the ability to make changes anywhere in the codebase you need to when you need to. You are no longer in control of your own code. You were forced to submit to a nanny state mentality by sacrificing your freedoms to modify the code for the promise of future stability and safety. That’s not a fun place to be when you’re on the receiving end, and it’s not a policy I would ever consider enforcing with my own code. I sincerely hope this line of thinking does not proliferate within the PHP community and infect other projects.

Zero to App in Two Weeks with Titanium

Like any web developer who has been sitting on the sidelines watching this mobile explosion happen in front of my eyes, I was eager to find a way to jump in. Up until about a month ago, I was still evaluating various different mobile development platforms – Titanium, PhoneGap, and Rhomobile, trying to decide which one I wanted to use to make my first mobile app. My only selection criteria was that the platform would have to be able to produce both iPhone and Android apps with the same code, because I wanted to be able to develop and release both an Android and iPhone apps without having to learn two completely different programming languages and development environments, and without having to do everything twice.
Continue reading

Practical Uses for PHP 5.3 Closures

Closures are a new language-level feature that has been added to php 5.3, along with namespaces, late static binding, and a slew of other new features, patches, and updates. If you’re like me, you might be wondering what the practical uses for these new features are before you can rightly justify diving in and using them in new or existing projects. I experimented a lot with closures and possible uses over the past few weeks, and came up with some compelling reasons to start using them.

Continue reading