Do you have an annoying bug that only seems to show up on a staging environment or worse, production? Did you just get rolled onto a project and have to set up an entire Expression Engine or WordPress environment for a simple task? Are you finding broken APIs blocking you from continuing development?
These are common events that happen to us all, and if we aren’t careful, they suddenly become expensive time-sucking problems. We can try our best to use “prettifying” tools to look at production code, take time configuring a new CMS, or test code in production. All of these sound awful, but we are all guilty of them. We all agree that we shouldn’t do it, but what can be done? There are a lot of different ways to approach all these problems, but I am here to introduce you to a tool that has solved all of them for us. Meet Charles.
Hi Charles!
Charles is a web-debugging proxy tool that allows us to intercept communication between our computer and the outside world. Think of Charles as your personal spy or your browser’s Network tab come to life! Charles lets you:
See all the people requesting information from you.
See all the people you are getting information from.
Alter information going either way.
This may seem odd or even pretty unhelpful. After all, who cares about proxy tools besides network admins, right? Wrong. We care. Let’s walk through those problems we were running into and see how Charles can save us time and sanity! If you haven’t done so, I would recommend installing Charles. Otherwise, you are just be depriving yourself of joy.
Bug Squashing
Let’s start with a bug in production. Even though we do our best and are diligent, sometimes weird bugs pop up through new user paths, unthought of use cases, and other difficult-to-reproduce scenarios. When it does happen, we need to fix them—and quick! For example, let’s say that the “Navigation” dropdown on sparkbox.com suddenly stopped opening, leaving the site near impossible to navigate! Charles can help you debug that! Usually, this means cloning down a repository, setting up the environment, getting an updated copy of any databases helping run it, etc. After all, debugging production code (uglified, minified, etc.) is a huge pain. This takes a lot of time, and worst of all, it may have prevented us from creating more features or working on other projects!! Instead of panicking, let’s use Charles to fix our problem fast!
First thing is to make sure that we have a local copy of the JS that seems to be breaking the site.
That would mean you either save the production file down (not recommended, but it works!) or pull the repository and run the build task (which will give you all the benefits of normal development).
Now that we have it, let’s use Charles to map our local copy of the JS to sparkbox.com’s.
With our local JS file being served, we can now use
debugger,console.log(), oralert()to help us narrow down the problem!After some quick detective work, we can see that a function call was misspelled, breaking the expected interaction!
With the bug found and the patch created, we can make a PR and push it up to production after review! Crisis averted! Now that we have seen how we map local assets, let’s take a look at how this can save us time when we are being rolled onto a project.
Rolling Along
In this next scenario, let’s pretend that we were asked to change all the typography on Sparkbox’s Foundry. Sure, we could play with it in browser, but good luck remembering all the changes we make! Even worse, we would need to use a database dump for the latest content, set up an Expression Engine instance, make a local dev server... all just to make some straight-forward CSS changes! Sure, a lot of those steps can be automated, but unfortunately, not every project’s setup can be automated or is set up to build that way. Instead of going through all those steps, let’s just use our normal development environment and leverage production to help test!
First, we pull down the repo,
npm install, etc., to get everything up and running.Next, we can local map our compiled CSS to production’s using Charles.
Then, we can make changes, use SASS mixins,
@extends,$variables, and everything else we normally use locally.
Just by leveraging production, we no longer have to stand up CMS instances to make trivial changes. This allows us to roll people on and off projects for small sets of tasks that do not require any data changes and cuts down on the hours required to set up their environment! Basically, we are saving people time and our clients money. This is huge.
API Medic, Stat!
We can local map files and re-use environments for their data. That’s cool, but what happens when the API you are consuming suddenly breaks? Or what do you do when you are having to wait for a field to be added to the response you are getting? Welcome to the Web’s equivalent to “I’m waiting for it to compile.” For this completely not contrived example, we will take the Pokémon API. We have been waiting for a new caught boolean field to be added indicating that we have caught this Pokemon. However, it doesn’t appear this is going to be added anytime soon. Rather than waiting around for the field to be added to the versioned API, let’s use Charles to stub it out for us!
Let’s start recording the traffic with Charles to receive the API call.
After we find it, Map the response to a locally stubbed out version.
Check if the response has been loaded in browser.
Now, let’s use
fetchto ensure that our response can be used!
Isn’t this awesome?! We no longer have to wait for API updates to keep building out a feature! We are talking about some serious time savings here!
At Your Service
These use cases may seem a bit contrived, but the more you use Charles, you will find its usefulness and how it saves you some huge headaches! Whether it is local mapping, API mocks, or many of Charles’ many other features, it’s well worth the time getting to know him and integrating Charles in your regular development!
