Switching from Middleman Back to WordPress

After a little over 2 years on Middleman, I decided to move my blog back to WordPress. Middleman – and static blogs in general – are a good idea in general (especially for security and performance), but I found it more difficult to write and contribute to my own blog on a regular, ongoing basis. This was especially noticeable after I started working for NetSuite instead of contracting, because I was no longer doing all of my work on my own personal laptop everyday. Continue reading

Countism

Countism App Icon

Countism is a mobile app idea that I have been working on and thinking about for a long time. Even though I have been thinking of the idea for a while and even did some initial work, I did not plan to actually build and release the app – that was always a question that was up in air. My initial work was really just experimental to see if it was something I could build easily enough to make it worth the effort, and to see if my idea would be viable in app form.

Continue reading

SoundingBoard

I just re-launched SoundingBoard as a new blog to help non-technical people learn how to evaluate their app ideas.

During my time running Brightbit (a web development studio), I met with a lot of people about their app ideas. Some were bad and crazy, but most of the ideas I heard were good ideas that just lacked the critical thinking steps necessary to determine basic viability or technical feasibility. 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.

An API is a Competitive Advantage

In this increasingly inter-connected world, APIs are becoming more and more important as time goes on. This is especially true if you have a business that requires integration of some sort, like metrics, notifications, integrated access to other systems (like telephony), payments, etc.

Companies like Stripe, Amazon, and Twilio have embraced the API-first approach, and in many ways embody and epitomize this movement as a whole.

Beyond Just Having An API

Just having an API is the obvious requirement for basic integrations. Going further than that, however, is the thought that your API can actually be a key point of differentiation from your competitors. Using this strategy (creating a robust, easy-to-use API) can be especially effective when you are going up against entrenched competitors, or when you are trying to make something that is traditionally very hard, easy.

Stripe And The Payments Industry

Ask any developer about online payment gateways, and they are likely to mention Stripe. Why? Because it was clear from the start that they really cared about devleopers, and put high priority in their API. Not only just creating an API – because every online payment system has an API – but in creating a very good API that is robust, simple, well-documented, and easy to use.

In contrast, many of Stripe’s competitors are using SOAP APIs or an emulation of the Authorize.net API. The API documentation typically exists only in PDF form, and it’s something that is mailed to you by the sales department. You’re lucky if you can find it on the website. Sales first and developers second is pretty much the exact opposite approach that Stripe took by focusing on developers and integrations first.

Here an example from the Stripe documentation – it’s just a simple cURL call to charge a card, and returns a simple JSON response:

curl https://api.stripe.com/v1/charges \
    -u sk_test_BQokikJOvBiI2HlWgH4olfQ2: \
    -d amount=400 \
    -d currency=usd \
    -d card=tok_14i9vP2eZvKYlo2Cdr4h0oHs \
    -d "description=Charge for test@example.com"

Stripe did several things right here:

  • Provide a simple API with good documentation
  • Provide a fast on-boarding process with no red tape (rare for credit card processors)
  • Support subscription charges with no additional fees (also rare)
  • Target and market to developers
  • Good design and nice, clean merchant interface

Stripe’s success is a combination of the above reasons as well as many other factors, but without a doubt their core product and main competitive advantage is their API. It shows in their overall developer experience, and has played a large role in their success in stealing market share from entrenched competitors like Authorize.net.

Amazon and the Public Cloud

For many, Amazon is synonymous with cloud computing. Many web hosts selling vitrualized servers came and went before Amazon got into the game, but no one besides maybe DigitalOcean has had a similar level of success doing so.

From the start of Amazon Web Services, Amazon made it clear that they were a platform for developers to build on top of, and provided an API from day one. So while many other virtual hosting providers existed, Amazon EC2 was one of the only ones that developers could use to provision whole new servers with automated scripts and zero manual intervention. The availability of APIs to provision servers lead to the creation of businesses built on top of Amazon’s infrastructure, like Heroku – who probably wouldn’t exist without Amazon’s APIs.

Rackspace, a much larger web host and significant competitor, didn’t launch a public API until years after Amazon did, but it was already too late, and they gave up significant market share to Amazon and Google Cloud Engine. Amazon’s API was its killer feature, and key differentiator. And we all know how well that has gone for them.

Twilio And Telecommunications

Twilio is a good example of a company using APIs to make something that is normally really difficult very easy. Now you don’t have to worry about which cell phone network the number you are texting belongs to, what country it is in, etc. Just integrate with the Twilio API, and you know it’s going to work.

For Twilio, their API is their entire business. There is no Twilio without an API, because if Twilio was just a web form that sent a text message to any given number – even if it still smoothed over all the carrier and location differences – it would not acheive the goal of automation, and thus would defeat the purpose.

In the years since Twilio launched, countless companies have relied on it for things like 2-factor authentication and phone number verification via SMS. Twilio can even power your entire phone system through tools like OpenVBX, all with a collection of REST APIs.

The Bottom Line

If you don’t have an open REST API that is easy to use, you will lose market share to a competitor who does. It’s time to start taking your API very seriously. An API is a competitive advantage.

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 🙂