Tutorial

TUTORIAL: Debugging Blanket Errors

Note: this post is an extension on my earlier debugging guide: JavaScript Debug Chart, the second in a series about debugging.

Sometimes, your browser will give you an error so unspecific, you’ll want to throw tomatoes at it. For example: “TypeError: Undefined is not a function”.  This happened to me the other day while working on an exercism.

No matter what I did, it seemed like the error stayed the same and my frustration level grew. And tools like repl.it and JS Hint weren’t helpful; they just gave me the same error as the console with no explanation.

A few days later, I’ve now fixed my code and wanted to post some lessons learned for those in a similar situation, because If you’ve already ruled out everything you know, blanket errors like this one may need their own debugging process.  Here are a few steps to get you started:

1. What did you last work on?

If your code was working 5 minutes ago, you are the culprit.  Try undoing or going back to an earlier git version.

2. De-nest.

You’re going to have to pull your code down to the smallest building blocks so that you can examine each piece and see where the code is going wrong.  You can test smaller code chunks individually in repl.it, using repl’s console to plug in variables.

3. Re-organize.

If you’re working with a number of interdependent functions, it’s likely that one of your functions or variables is simply defined too far down in your code, causing the browser to throw an “undefined” error.  Look through and make sure each variable, function, script is defined before it is called.

Advertisements

TUTORIAL: JavaScript Debug Chart

As a new coder, I found the process of debugging overwhelming.  There were so many resources out there, so many possible errors, and always the likelihood that my error was being caused by multiple issues at once.  At that point, my default response to an error was to just ask for help from another coder.  I thought, “Shouldn’t there be a systematic way for me to do this myself?”

Enter the JavaScript Debug Chart, built from my own experiences of what resource works for different types of errors.  Many thanks to Zeke Nierenberg for his thoughts on structuring and publication. This table includes the resources that have been most useful to me in fixing simple javaScript.  I hope many others can benefit from this resource!jsdebugger2

TUTORIAL: Converting existing code to MEAN app

When my FullStack TA’s advised me not to try to convert my quiz application (using Angular and Angular Local Storage) into a MEAN app (MongoDB, Express, AngularJS, Node), I wanted to know why.  Why couldn’t I just generate an app using a MEAN app generator, then plunk my HTML’s, CSS’s, and JS’s in and wire it together?
 
I decided to try it and see how far I could get.  I used daftmonk’s generator-angular-fullstack, which includes yeoman, grunt, and passportJS, and began adding my quiz app files.  From this experience, I’ve derived some best practices to keep in mind when performing this conversion:
 
1. Don’t delete anything you can’t replace.  MEAN apps from a generator are very tightly wired.  Every file is there for a reason, and each one is linked to others through source hyperlinks, the gruntfile, angular routing, SASS routing, and possibly express routing.  Don’t delete any file unless you have opened it and feel confident that you can re-wire the app.
 
2. Try not to move things.  See #1.  Because of #1, you can have problems if you move files.  Your gruntfile and other routes expect each thing to be in a certain place.  One of the most interesting errors I had from this was when my console said there was an error with my app.js, and when I clicked on the words ‘app.js’, it showed me my index.html file.  The browser had been told that my app.js would be in a certain place, and when the app.js was not there, it grabbed another file and tried to read it as a script.  For every file I moved, I probably spent an hour fixing routes, reworking functions, and debugging strange errors.
 
3. The ‘Find in Files’ function in Sublime is your new best friend.  You are going to need to search for many, many terms to make sure that your app, route, and module names are all up to date.  You’ll find Sublime’s cross-file search indispensable.  Learn the shortcut: command-shift-F.
 
4. Look through your gruntfile.  Grunt is doing a lot of things for you behind the scenes.  For example, it will be combining all of your SCSS files and rendering them as one CSS file, which means that your views will all be modified by multiple SCSS files unless you make a change.
 
5. Learn your homonyms.  Within your application, you’re going to have several files with the same name.  You may have a few app.js files, a couple of index.js, a couple of route.js… take a look at your files with the same name and understand why some are intended for the front end (angular routes, for example) and some for the back end (express routing, passport).  It may be useful to draw a map of your site routes and decide whether to route each transition through the front end or through the back end.
 
I learned a lot through this project, but if I were doing it again, I would probably find a way to create a MEAN app by hand instead of using a generator.  On the positive side, I now have a better sense now of how the various files work together to create a fantastic app.