Tags: debugging

10

sparkline

Wednesday, August 15th, 2018

Google AMP - A 70% drop in our conversion rate. - Rockstar Coders

Google hijacking and hosting your AMP pages (in order to pre-render them) is pretty terrible for user experience and security:

I’m trying to establish my company as a legitimate business that can be trusted by a stranger to build software for them. Having google.com reeks of a phishing scam or fly by night operation that couldn’t afford their own domain.

Tuesday, August 7th, 2018

Console methods

Whenever I create a fetch event inside a service worker, my code roughly follows the same pattern. There’s a then clause which gets executed if the fetch is successful, and a catch clause in case anything goes wrong:

fetch( request)
.then( fetchResponse => {
    // Yay! It worked.
})
.catch( fetchError => {
    // Boo! It failed.
});

In my book—Going Offline—I’m at pains to point out that those arguments being passed into each clause are yours to name. In this example I’ve called them fetchResponse and fetchError but you can call them anything you want.

I always do something with the fetchResponse inside the then clause—either I want to return the response or put it in a cache.

But I rarely do anything with fetchError. Because of that, I’ve sometimes made the mistake of leaving it out completely:

fetch( request)
.then( fetchResponse => {
    // Yay! It worked.
})
.catch( () => {
    // Boo! It failed.
});

Don’t do that. I think there’s some talk of making the error argument optional, but for now, some browsers will get upset if it’s not there.

So always include that argument, whether you call it fetchError or anything else. And seeing as it’s an error, this might be a legitimate case for outputing it to the browser’s console, even in production code.

And yes, you can output to the console from a service worker. Even though a service worker can’t access anything relating to the document object, you can still make use of window.console, known to its friends as console for short.

My muscle memory when it comes to sending something to the console is to use console.log:

fetch( request)
.then( fetchResponse => {
    return fetchResponse;
})
.catch( fetchError => {
    console.log(fetchError);
});

But in this case, the console.error method is more appropriate:

fetch( request)
.then( fetchResponse => {
    return fetchResponse;
})
.catch( fetchError => {
    console.error(fetchError);
});

Now when there’s a connectivity problem, anyone with a console window open will see the error displayed bold and red.

If that seems a bit strident to you, there’s always console.warn which will still make the output stand out, but without being quite so alarmist:

fetch( request)
.then( fetchResponse => {
    return fetchResponse;
})
.catch( fetchError => {
    console.warn(fetchError);
});

That said, in this case, console.error feels like the right choice. After all, it is technically an error.

Monday, April 30th, 2018

Apart From Code

A good developer…

  • debugs
  • follows the KISS principle (and respects YAGNI)
  • knows how to research
  • works well with others
  • finds good developer tools
  • tests code

Friday, July 21st, 2017

Patterns Day 2017: Rachel Andrew on Vimeo

Rachel’s fantastic talk from Patterns Day. There’s a lot of love for Fractal specifically, but there are also some great points about keeping a pattern library in sync with a live site, and treating individual components as reduced test-cases.

Patterns Day 2017: Rachel Andrew

Sunday, April 10th, 2016

A debugging thought process

Remy walks us through his performance debugging routine …and now Una must write him a song.

Friday, January 22nd, 2016

The Art of Debugging

I was just helping out with some debugging at work and it reminded me of this great talk/post by Remy:

  1. Replicate: see the bug
  2. Isolate: understand the bug
  3. Eliminate: fix the bug

Monday, November 16th, 2015

Online regex tester and debugger: JavaScript, Python, PHP, and PCRE

Regular expressions are my kryptonite. I’m rubbish at them and I can never keep the vocabulary in me head.

Mark recommended this tool so I’m going to give it a go the next time I have to resort to regex.

Friday, January 2nd, 2015

Taking Chrome DevTools outside of the browser. — Kenneth Auchenberg

Kenneth has isolated Chrome’s dev tools into its own app. This is a big step towards this goal:

Why are DevTools still bundled with the browsers? What if clicking “inspect element” simply started an external DevTools app?

With DevTools separated from one specific browser, a natural next step would be making the DevTools app work with other browsers.

Wednesday, March 7th, 2012

Adobe Shadow | preview mobile web - Adobe Labs

Adobe have launched their version of Weinre, the tool that allows you to refresh and debug iOS and Android browser views from your desktop computer.

Friday, October 17th, 2008

paulhammond.org: Conditional classnames

Here's a handy little trick from Paul: use conditional comments to add a class to your BODY element, allowing you to target IE without a separate stylesheet.