First Off, What Tools Do We Include?
The first thing I had to figure out what exactly what tools I should include. Here is the list I finally came up with:
- Coding Environments
- Command Line Tools
- Code Repositories
- Task Runners
- Error Linting and Debugging
For the most part I had a pretty good idea of what to include from the beginning. However, it did take a while to figure out the best order. I’ll discuss that at the end, but first I thought I’d share a bit about the specific tools I chose from each type of tool.
When I taught at Treehouse I used Sublime Text for all of the WordPress Development videos. However, since then, Atom, from Github, came out and I have grown to like it for it’s sleek feel and powerful extensions.
In my informal surveying of WordPress developers, most folks use one of these two coding environments. However, a few folks do use IDEs (Integrated Coding Environments) and I knew I had to include one in the course.
In my course I primarily use Atom with a number of my favorite packages installed. I do not really go into Sublime Text because it is so similar to Atom and because my course advisor, Wes Bos, has a book on Sublime Text. I go into WebStom a bit to show what an IDE can offer and then refer people to Know the Code from course advisor Tonya Mork, who gets deeper into developing with an IDE.
Command Line Tools
One of the most important lessons I learned from doing the Week of REST Bootcamp with my friends at Human Made was that it is important to cover basic command line skills before getting into using other tools: navigating directories, understanding how commands and options work, etc. So I do a bit of that to start.
When it comes to accessing the command line in the course I like to use Atom with the Terminal Plus Package. However, I highly recommend folks check out the free Command Line Power User Course from Wes Bos for tips on how to use iTerm on the Mac with ZSH, Z and other goodies. Although I do not explain how I do it in my course, I do have a customized command prompt 😉
In the course we use NPM quite a lot and really try to get folks used to using it as part of their development flow. I do not go into Github too much, just enough to clone repositories and manage your own projects a bit. From there I recommend folks checkout the official Try Git interactive tutorial.
Task Runners help you run and manage other command line tools. Three options clearly stood out for talking about in this course: Grunt, Gulp and Webpack.
In terms of what the task runners are doing, it generally breaks down to some combination of bundling files, minifying, linting, watching for file changes, and running a local server with live reloading on file changes.
Error Linting and Debugging
I love error linting tools 🙂 Something about knowing as I code if I’m making any mistakes saves some time, particularly searching for those silly misspellings and similar type things. I explain the relationship between JSLint, JSHint and ESLint and show how you could use each with our task runners. In terms of what to choose, I generally agree that ESLint is a good way to go.
For debugging I show how you can use Chrome Developer Tools to insert breakpoints and walk through your code for debugging, although we also get plenty of experience using console.log for simple stuff. Although I don’t go into depth with it, I do mention that you can also do this internally with WebStorm.
At first I thought to use Jasmine since it was one of the older and simpler testing frameworks. However, a lot of folks like Mocha. In the end, I decided to go with Tape, in part due to JS education guru, Eric Elliot’s, article on why he uses Tape over Mocha and in part because I felt it was the simplest of the bunch for someone new to testing.
In Part II of the course I will mention a few other testing frameworks as well, since some framework communities have preferred testing frameworks.
Now, What Order to Teach All of This?
In the end I settled on the order above for covering these different tools, however, it took me a while to settle on this order.
Earlier on I had covered Linting quite early and tried to save Git till the very end. I also did not have command line tools in it’s own section originally and just talked about it in the Coding Environments section.
In fact, originally most of these sections were part of one big Task Runner or Coding Environments section since you commonly use most of these tools through your task runner or coding environment.
Learning about Tasks Runners before learning about the other tools does not give you much to do with a Task Runner, though. For that reason we start off with a basic configuration for the Task Runners with a number of tools that we don’t get into until later sections.
This follows a teaching convention of dropping folks into a working project that might not make sense on a micro level but is helpful for understanding macro concepts. Ultimately I felt this approach worked better than trying to talk about each tool individually before combining them in with a task runner, especially since it would mean running all the tools just from the command line to start, which is not really a common practice.
Did I Miss Something? Have Opinions Otherwise?
For this reason I rely a lot on people in the community who work with these tools regularly and encounter limitations and strengths of these (and other) tools in different types of environments and projects. So, if you have thoughts on these different tools, as well as ones that I did not mention, please leave a comment and share your experience!