Setting up your dev environment and intro to developer concepts


There are many options out there for a browser. The majority of people out there just use the browser that came on their computer because they don't know any better. But now that you are getting into development you do. All browser are not created equal. If you are writing and testing code you should use either

  • Google Chrome
  • Mozilla Firefox
  • Chrome Canary. Google Chrome Canary has the newest of the new Chrome features. Be forewarned: it's designed for developers and early adopters, and can sometimes break down completely.

So the reason you would use one of these is because or their debugging tools; meaning you have the ability to peer into the web page in a super efficient way to either see how it is working or why its broken.

Remember it is important to regularly view the code you write in multiple browsers. Different browsers will show your content in different ways. It will even prevent you from using the same HTML, CSS, and JavaScript features. The advanced browsers are known as evergreen browsers. They will self update with out a major press release or marketing version. Anyone who has ever worked in the web still gets shivers when they hear the name IE6.

For this course you will be developing in Google Chrome. We will not be addressing supporting non evergreen browsers.

Setup Chrome

  1. Download Google Chrome
  2. Install it with all the default settings
  3. Open Chrome
  4. Install plugin Web developer
  5. Install plugin Wappalzyer
  6. Install plugin Clear Cache

Chrome Dev tools

There are entire courses out there strictly teaching people how to use the chrome dev tools. Opend the dev tools by right clicking on a web page and selecting Inspect. We will only really be using two of these resources: Elements, Console, and maybe Device Mode.

That's it for now, but don't worry you will get a lot of time with this.

Choosing an editor

A text editor is not the same as a word processor. A word processor allows you to independently apply styles to text like italics, bold, underline, size, and font. Word processors were designed to create content to be read by people. It like looking at a website. You see the result of the formatting to make content easier to read.

A text editor is specific for writing code. It can apply formatting based on file extension; you cannot just randomly make a word large or big or red. You can write upper and lower case letters, numbers, and symbols. The default font is always set to a monospaced font (each character is the same width). This really helps visually align your code.

A text editor is not the same as and IDE (integrated development environment). An IDE is more of a toolbox while a text editor is more of a tool. IDE can really help with testing and compiling code but that comes at a price. A lot of times you will have to buy an IDE and they have the potential to use a lot of your system resources and they can run on the slower side. Some languages require an IDE. These languages are monolithic and rarely have the coolest tech available.

A text editor is usually a pretty fast application. When I said its more of a tool than a tool box you have to know that its a super tool thanks to the extensibility of the tool. You can install all sorts of plugins that will give your editor more power.

Editors are very personal, and each persons editor of choice is always the best. If you have one, I will not try to change your mind. But know that if you use the one I use (bc its the best) I will be able to help you write code in a very efficient way.

Some Editors

  • Sublime Text
  • Visual Code
  • Notepad++
  • VIM
  • Emacs

I use because its pretty. It is the first editor I used where i did not want to immediately change the colors. But truly atom is one of the more extensible editors out there. It was also built using html, css, and javascript. You can inspect this by opening the Developer Tools: View > Toggle Developer Tools menu, or by using the cmd-alt-i or ctrl-alt-i.


  1. Download Atom
  2. Install Atom with all the default options
    1. Windows note: You may need to rename the downloaded file to have a .exe extension
  3. Open Atom

Configure Atom

Atom has a ton of configurations that can be installed. We are going to install a few that will help us get started.

Snippets | Keymap MAC | Keymap WIN | Config


  1. Open the Atom menu and select Preferences
  2. Click Open Config Folder
  3. Replace the content in each file with the appropriate content from above
  4. Close the config window


  1. Open the File menu and select Settings
  2. Click Open Config Folder
  3. Replace the content in each file with the appropriate content from above
  4. Close the config window

Code Quality Tools

Atom allows its functionality to be extended the the installation of Packages. Packages can be used for many things, but our main use for them now is to aid in the writing of clean and syntactically correct code.

  1. We need to open our Atom Settings again (you just did that).
  2. Click Packages
    • These are the packages that are already installed in our editor
    • Each one of them has settings that you can go into but for the core packages is usually good to leave them alone
  3. Click + Install and lets install these packages
    • editorconfig
    • linter
    • linter-standard-js
    • linter-htmlhint
    • linter-stylelint

OS Tweaks

We do a lot of things with files that normal users don't need to see. A lot of files on your computers are hidden to prevent people from breaking stuff. Its required that we see these files. It is also super important that we show file extensions too.


  1. Open your terminal
  2. defaults write AppleShowAllFiles TRUE
  3. Open Finder and Finder Preferences
  4. Click the Advanced tab
  5. Check Show all filename extensions


  1. Open your Explorer
  2. Press the alt button to bring up your menu options
  3. Open the Tools menu and select Folder Options
  4. Click the View tab at the top
  5. Under the Advanced settings there is a option for Hidden files and folders, select Show hidden files, folders, and drives
  6. Uncheck Hide extensions for known file types
  7. Click the Apply to Folders button
  8. Click Ok

Using your Terminal or Command Line

When most people think of programming a picture of the terminal may pop in ther head. It has the potential to be an intimidating tool but as a developer you will discover that you will not be able to live with you, and you will also realize it's not difficult to use at all.

Open your console. This is going to be a hands on exercise


  1. Mac: cmd + space Terminal
  2. Get your current directory pwd
  3. Get the name of the logged in user whoami
  4. List the content in your current directory ls
  5. Change you directory to your Desktop cd Desktop
  6. Make a new directory called New mkdir New
  7. Navigate into that directory cd New
  8. Create a new file called echo hello > test.txt
  9. Open this directory in Finder open .
  10. Go to the immediate parent directory cd ..
  11. Close the terminal exit


  1. Win: Start > Run Command Prompt
  2. Get your current directory cd
  3. Get the name of the logged in user whoami
  4. List the content in your current directory dir
  5. Change you directory to your Desktop cd Desktop
  6. Make a new directory called New mkdir New
  7. Navigate into that directory cd New
  8. Create a new file called echo hello > test.txt
  9. Open this directory in Explorer explorer .
  10. Go to the immediate parent directory cd ..
  11. Delete the New directory rd New
  12. Close the terminal exit

Version Control

Version control is a technological solution for being human. How many of you have ever deleted or changed something that you regret? We all have. Programmers don't just write code, we have this nasty habit of changing code. Unfortunately, no programmer is perfect, and sometimes, mistakes are made. Version control gives us the ability to go back to an older version of a file. It also allows us to see the changes that have occurred to a file over time.

There are many version control systems out there. Often they are divided into two groups: centralized and distributed.

Centralized version control systems (CVCS) are based on the idea that there is a single central copy of your project somewhere (probably on a server), and programmers will commit their changes to this central copy. Examples: CVS, Subversion, and Perforce.

Distributed systems (DVCS) do not necessarily rely on a central server to store all the versions of a project's files. Instead, every developer a copy of a repository and has the full history of the project on their own hard drive. This copy (or clone) has all of the metadata of the original. Examples: Git, Mercurial, Bazaar or Darcs.

<! data-preserve-html-node="true"--image-->

Read More


Git is a distributed system. Conceptually, most other systems store information as a list of file-based changes. You think of the information they keep as a set of files and the changes made to each file over time.

<! data-preserve-html-node="true"--image-->

Instead, Git thinks of its data more like a set of snapshots of a miniature filesystem.
<! data-preserve-html-node="true"--image-->

Most of the interaction you have with git will be on your own local computer. Git can operate completely independently of a network connection; it doesn’t need to go out to the server to get the history and display it for you. This is accomplished by having a local git repository/database. You work with it and when you are ready, you can sync up with a git repository on the internet.

There are 3 states of a file in git: committed, modified, and staged.

  • Committed: The data is safely stored in your local repo/database.
  • Modified: You have changed the file but have not committed it to your database yet.
  • Staged: You have marked a modified file in its current version to go into your next commit.

<! data-preserve-html-node="true"--image-->

The basic Git workflow goes something like this:

  1. You modify files in your working directory.
  2. You stage the files, adding snapshots of them to your staging area.
  3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.


GitHub is a code hosting platform for git that promotes collaboration. It lets you and others work together on projects from anywhere. You can create projects for just about anything. I use GitHub to hold the code my projects, to let me contribute to the code on other projects, to keep track of my computers configuration files, and to even plan events.

You will use GH to keep track of every piece of code you write in this class. By the end of this session you will have put a ton of content into your own personal repository.

GitHub Setup

  1. Go to GitHub
  2. Sign up
  3. EXERCISE: Learning GitHub

GitHub Issues

Github uses a concept of issues. The purpose of issues is basically calling out something thats broken or needs to be done. Issues are not a part of git; they are purely a GH feature.

You now know enough to be dangerous, so be careful and stay tuned for more

Building a seed project with Webpack, ReactJS, and ES6: Part 2 Setting up Webpack


Ok so hopefully you read or already knew the topics presented in the part 1 post of this series. We basically went over a super basic setup of folder structure for the seed project we will be creating.

For this post we will be picking up where we left off in part one; use this repo to align yourself. We are going to be installing Webpack and setting up a build process. Our build process will eventually transpile our ES6 code, processing images, applying styles, and including a an additional library. Right now it is just going to bundle some stuff together and use an html template to create static source code.

Main Topics


Supporting Topics

NPM | Linting | Semantic Versioning



Webpack is a module bundler that will create static assets. Basically we can create our project how ever we want then use Webpack to build a static site. This makes it easy to deploy but can be hard to debug.

Basic Install

Open your project in your IDE of choice and also open your project's root directory in your terminal. We are going to be using npm a lot in this post. You will have to have node/npm installed in order to do this. You can verify npm by running the following in your terminal:

$ npm -v

Hopefully you will see a version printed out. If not you may not have node installed. Follow these instructions for installation.

Ok so let's get this started. First we are going to install Webpack and we are going to use a flag telling it to save this as a project development dependency. It is a development dependency because it is not needed to run the application, but it is to work on it. You will also have to install webpack globally in order to use the command line tools.

seed-project $ npm install webpack --save-dev
seed-project $ npm install -g webpack

If you get an error trying to install globaly you may need to change some permissions. Some people would recommend using sudo for global installs but I would rather just give myself ownership of thise directories:

seed-project $ sudo chown -R yourUser ~/.npm
seed-project $ sudo chown -R yourUser /usr/local/lib/node_modules
seed-project $ sudo chown -R yourUser /usr/local

This creates an entry in package.json. Open that file and take a look. You will notice webpack listed as a key on an object. The value is the version of webpack we are using. It is using a caret range meaning it will allow changes that do not modify the left-most non-zero digit. Ideally this 3 part identification follows this pattern [major, minor, patch]. In a perfect world, this would be safe but it does assume the author of the package will only release breaking changes in a major version. That is rarely true so I advise against using caret ranges and using exact version installs. The easiest way to resolve this is to manually delete the caret from the package.json file.

It also copied the webpack code locally to this project and put it in the node_modules directory. Every installation we do with npm will by default place content in this directory. You may remember in the previous post we created a file to ignore content from our git repo. Our node modules are folders we do not want versioned. They already are so no need for us to do it too.

Setup Webpack Config

Next we need to create our configuration file that will instruct webpack what to do.

seed-project $ touch webpack.config.js

Open this file in your editor and add the following code.

// webpack.config.js
var path = require('path')

module.exports = {
  entry: './app/index.js',
  output: {
    filename: 'bundle.js',
    path: path.join(__dirname, 'dist')

So lets explain this real quick. We are exporting a configuration object and right now we only have 2 properties in it: and entry point for webpack and an output for our bundled JavaScript file. We can run this right now but it will throw an error as we do not have this file app/index.js. Lets create a place holder file real quick from our terminal.

seed-project $ echo "console.log('this is my app')" >> ./app/index.js

Running Webpack

Ok, time to run webpack. We use the webpack command line interface (CLI) and give it a configuration file. By default webpack will look for webpack.config.js so technically we do not have to pass the file name of our configuration. I have never really liked defaults and prefer to be explicit; it's easier to understand for the next guy.

seed-project $ webpack --config webpack.config.js

Look at your project folder structure; you should now see dist/bundle.js. If you see this, go ahead and high five yourself because you did it right. But what are we going to do with a lone JavaScript file. We need to put this file in an html page and we need that html page in our dist directory. So we could very easily just make an index.html file there and have it load bundle.js. But your project should be smarter than that. The dist directory should be, and eventually will be, able to be completely purged from your project every build. This ensures you don't have any changes local on your computer that are not able to be recreated else where. How many times have you heard "But it works on my computer". This helps to resolve that kind of problem.

Creating an HTML template

For this next part we need another package installed, html-webpack-plugin. This plugin simplifies the creation of html files to serve our webpack bundles. So webpack has a concept of plugins. This allows us to use existing functionality or even write new stuff into our build processes.

seed-project $ npm install html-webpack-plugin --save-dev

We need to create a new file to serve as our template file.

seed-project $ touch index.tmpl.html

Open this file and add some basic html

<!-- index.tmp.html -->
<!DOCTYPE html>
    <title>{%= o.htmlWebpackPlugin.options.title %}</title>

Now go back to webpack.config.js so we can use this plugin in our process.

  • Require this new package
  • Add a new property to our configuration called plugins. Plugins is an array.
  • Create a new instance of our plugin and pass in a configuration for it.

Here is the result:

// webpack.config.js
var path = require('path')
var HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './app/index.js',
  output: {
    filename: 'bundle.js',
    path: path.join(__dirname, 'dist')
  plugins: [
    new HtmlWebpackPlugin({
      title: 'Seed Project',
      filename: 'index.html',
      template: 'index.tmpl.html',
      inject: 'body',
      hash: true

Real quick I'll explain the configuration we are using for this plugin.

  • Title: Sets a property that we use in our template for the title tag.
  • Filename: The name of our file once it is created. This file will be placed in the output path that we created earlier.
  • Template: The template we are using to create the html file.
  • Inject: Determines where we place the script tag for bundle.js.
  • Hash: This gives us the option of adding a random query string to prevent the browser from using cached versions of a file.

There are way more configuration options available. Read about them.


I know by now some of you are judging me personally because of my JavaScript syntax. Yes, I know, I did not use semicolons but that was on purpose. To avoid bikeshedding in all of my blogs I plan to use a style that I cannot control nor manipulate. So I will be using StandardJS; you complain there if you feel the need to. Now let's get on with it. First install standard and a reporter.

seed-project $ npm install --save-dev standard standard-reporter

Now let's run the code linter. What we are going to do is run the standard code rules on all .js and .jsx files in the project, then take the output of that and run it through the the standard-reporter for better formatting and readability.

seed-project $ standard ./**/*.js, ./**/*.jsx, *.js | standard-reporter --stylish

This should pass and basically nothing will happen. You can test a failure by adding a semicolon after the path declaration on line 1 of webpack.config.js. Save the file and then run our last terminal command. You should see an error now. Go ahead and revert that change, save, and run again. Project is now listing and your code will be cleaner. Many IDEs have really useful plugins for StandardJS too.

NPM Script Sugar

Ok so now we have a lot of long terminal scripts that would be really hard to remember. I think it would be great if there was a better way to standardize all of this. There is. So npm is not just a module manager, you can actually create and run bash scripts with it. Go ahead and open your package.json file. We are going to create a npm script for testing our code and building our distribution directory. You should already have a scripts property in your json doc. Here is my file now:

  "name": "seed-project",
  "version": "1.0.0",
  "description": "A web seed project using webpack, react, and es6",
  "main": "./app/index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "html-webpack-plugin": "1.7.0",
    "standard": "^5.4.1",
    "standard-reporter": "^1.0.5",
    "webpack": "1.12.9"

I am going to add three scripts. The first one is called test and it will run our standard code listing task. The next one is called build-dist and it will delete the dist directory then run webpack to create a clean distribution folder. The last one is a compound task that basically runs tasks. It will run the test script and if it passes it will run the dist script. If test fails it will error out the report in the terminal.

  "name": "seed-project",
  "version": "1.0.0",
  "description": "A web seed project using webpack, react, and es6",
  "main": "./app/index.js",
  "scripts": {
    "test": "standard ./**/*.js, ./**/*.jsx, *.js | standard-reporter --stylish",
    "build-dist": "rm -rf ./dist && webpack --config webpack.config.js  --bail -p",
    "dist": "npm test && npm run build-dist"
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "html-webpack-plugin": "1.7.0",
    "standard": "^5.4.1",
    "standard-reporter": "^1.0.5",
    "webpack": "1.12.9"

To execute the dist script do the following:

seed-project $ npm run dist


Awesome! We covered a lot here but this just the tip of the iceberg with Webpack and ReactJS. Stay tuned; the next one will really put some pixels on the page.

Things to come in this series:

  • Installing webpack loaders to for ReactJS, ES6, images, fonts, and styles
  • Building a super tiny ReactJS example to show all the above installs working
  • Using webpack to create a development server with live reload
  • Building a bare bones react flux app structure
  • Maybe some sort of tests
  • Might be cool to get into some sort of app packaging... TBD