Effective Browser JavaScript Debugging

How to effectively debug your web application is increasingly becoming a critical skill for any web developer, especially with the rise of ever-more complicated JavaScript applications with code transpiling and obfuscation. I wanted to teach the other developers at my company how to do this to be more effective at work, and developed it into a full talk that I have given at many conferences all across the world. My local user group OKC.js was the first time this talk was recorded and made available online. Please check it out:

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

Stronger Encryption and Decryption in Node.js

If your encryption method produces the same encrypted result given the same original text input, your encryption is broken. Yet this is what I see in most other examples around the web on how to do encryption in Node.js. Strong encryption should always produce a different output, even given the same exact input. Continue reading

Return Field Errors in Your JSON Error Response

While developing the new Job board for Techlahoma (soon to launch), I decided to customize the JSON error response to include a field_errors key with a dictionary of the field names submitted, and the error message that maps to that field. This allows me to more easily create in-context error validation feedback for users without having to implement additional client-side validation. A huge win for productivity, and a really nice feature for anyone implementing the JSON API. Continue reading

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 🙂

Titanium Proxy Objects With JavaScript Call and Apply

Sometimes language and platform abstractions bite you. They can seem pretty straightforward and “just like the real thing”, but sometimes they have odd behaviors that don’t quite work the way you expect.

Dynamic method invocation with .call() and .apply()

The .call() and .apply() functions are something you will use a lot if your code involves a lot of dynamic arguments, such as building an array of arguments that then need to be mapped to actual ordered function arguments in a function or method call.

Since Titanium runs native JavaScript with the V8 engine bundled in your app, you will naturally find yourself attempting things like this:

var args = [sql].concat(params);
var db = Ti.Database.open('dbname');
var rs = db.execute.apply(db, args);

But if you run that, and you will be presented with the head-scratching error:

invalid method 'execute:'

Although the error is pretty confusing – you know there is a method named execute on the db object – there actually is a good explanation for this behavior.

Titanium Proxy Objects

What intiutively seems to you like a normal JavaScript variable here – db – is actually a proxy object created and returned by Titanium with the Ti.Database.open call. Titanium also returns proxy objects for pretty much every other component that has a native counterpart they are bridging over to behind the scenes. This black magic is fundamental to how Titanium works internally.

The Solution

Although the main Titanium proxy object explanation suggests creating a wrapper object for the method call, that’s actually not necessary at all, and creates a lot of extra work, as well as many additional lines of code.

The best solution is to use a bit of JavaScript meta programming and call the apply method directly from the Function prototype:

var args = [sql].concat(params);
var db = Ti.Database.open('dbname');
var rs = Function.prototype.apply.call(db.execute, db, args);

This is a nice one-liner that achieves the same end result, is much easier to undertand, and does not require a wrapper object or another layer of indirection to achieve.