API, Makefiles, Enviroment Variable, Envigy and Yeoman.

Summary

  1. API – flight files
  2. Makefiles
  3. Enviroment Variable
  4. Envify
  5. Yeoman

Session

1. API – flight files

Started talking about what an API Application Programming Interface means and talked about some sites where I can get the files I need for my project.

Sites:

2. Makefiles

Fixed a problem that was getting confused the command dist with dist/ adding a % symbol.

dist: dist/js/main.browserify.js

dist/js/main.browserify.js: dist/% $(BROWSERIFY_DEPENDENCIES)
echo "Generating browserify file…"
browserify
-g [envify –VERSION $$(make version)
–BUILD_DATE $$(date -u +%Y-%m-%dT%H:%M:%SZ)]
lib/index.js > $@
echo "Done!"
dist/%: $(PUBLIC_DEPENDENCIES)
echo $*
mkdir -p dist
cp -av public/* dist/

Remark: pay attention to the use of $@ that uses the name of the task

3. Enviroment Variable

This was the main subjet of the session. We talked about how the Enviroment Variables are always in capital letters (that is a convention) and how we can change them or use them for our profits.

We can use our NODE_ENV so we can know the mode we are and use it, like the following example:

if (process.env.NODE_ENV !== “production) {
console.log(“Show only when not running in prod”);
}

Those are variables that affect to the hole system or the process where they are encapsulated.

Per example, we used the following command:

$ NODE_ENV=production make temp

Changing the Environment_variable to show it at the task on make. Really useful if we use this as an restriction tool.

For a more permanently way, we settled the variable on the .Bash_profile

export NODE_ENV="developer";

Then we executed the following commands:

# update the file
$ source .bash_profile
# printed out the value of the variable.
$ echo $NODE_ENV

4. Envify

We had to install Envify to use it at the Makefile like shown on point 2.

5. Yeoman

This is a scaffolding tool that allows you to select the latest trends on scaffolding for the desired tools that you are going to use.

Homework.

  • Show the project of track maps.
  • Think about a pseudoname for posting all this online.
Thanks for your time @AirCrewMentor, it was a really great session.

Make Dependencies & Sequences

Summary

  1. Using Dependencies on Make.
  2. Make: sequences

Session

Please @AirCrewMentor check this post to see if I got the process right. Any tuto for make that I could follow?

1. Using Dependencies on Make.

We created Dependencies so make can keep track of the files that are being modified and act only at the ones that have been modified.

In this example, when we run Make dist the order followed would be this:

  1. Go to dist/ and it would create the dir and it would copy from public/ all the files that were modified, this is what public dependencies specifies.
  2. dist/js/main.browserify it would be run only if on of the files on the Browserfy Dependencies has been modified.

BROWSERIFY_DEPENDENCIES = $(wildcard lib/*.js package.json node_modules/*/package.json)
PUBLIC_DEPENDENCIES = $(wildcard public/**)

dist: dist/js/main.browserify.js

dist/js/main.browserify.js: dist/ $(BROWSERIFY_DEPENDENCIES)
echo "Generating browserify file…"
browserify lib/index.js > dist/js/main.browserify.js
echo "Done!"
dist/: $(PUBLIC_DEPENDENCIES)
mkdir -p dist
cp -av public/* dist/

2. Make: sequences

Since the commands with slashes doesn’t appear on bash when tabbing with make written, we create a dist: dist/js/main.browserify.js that will concatenate all the commands with their dependencies.

At dist/js/main.browserify.js: dist/ $(BROWSERIFY_DEPENDENCIES) before running the proper commands it would run the dist/ command, later will check the BROWSERIFY_DEPENDENCIES and proceed with its commands.

Homework.

  • Back to the code.
  • Show some work
Thanks for everything @AirCrewMentor like always it is amazing learning something new every session.

JSHint, Project structure, move with Git and Our path…

Summary

  1. JSHint
  2. Project structure.
  3. Move files with Git.
  4. Our path…

Session

1. JSHint

We talked about the importance of using JSHint and @AirCrewMentor shared his usual .jshintsc configuration.

So at the root folder of every project the file .jshintsc must be created to establish the styling rules.

I was using the package installed on sublime JSHint for it but AirCrewMentor said that it is better to use the Bash line command, so we used npm to install jshint and after that we were able to use the command jshint lib/ or the desired folder to link.

Created the make lint at the makefile

lint:
jshint lib/

The importance to use the command, is because using an add-on in sublime is cool, but I need to get a good base on writing code on my own and if someday I go into an interview maybe I wont have sublime or my computer, but I would be able to use the bash.

2. Project Structure.

We talked a little bit about this in a previous session, but never got into it. This time AirCrewMentor wanted to start giving the proper structure to our code.

We can see the following typical structures:

  • app/ (or lib/ or src/) depending on if it’s an app or actually a library.
  • here goes all our files we are going to code ourselves.
  • Usually the main file is called index.js and if this is the case, it is automatically collected.
  • public/
  • Here we would put all our pictures, html, css, js(vendor) that we are going to need for our code to run.
  • dist/
  • Here is were we’ll put the final result of our JS code in a preferably single file (minified version)
  • test
  • our files for test
  • node_modules
  • libraries installed.
  • root
  • At this level we are going to have the following files:
  • .gitignore
  • .jshintrc
  • Gruntfile.js
  • Makefile
  • package.json
  • readme.md

3. Move files with Git.

Usually when a project is committed, we need to move and rename the files with git command, so it keeps the history of changes on the file. Otherwise it would appear like a file deleted and a new file without history.

$ git mv js/format_money.js lib/
# here we moved the file and renamed.
$ git mv js/main.js lib/index.js

4. Our path…

Now I need to choose a personal project were I can find motivation and dedication, because before starting something more serious I need to get experience coding with sublime and iTerm.

I need to choose a project that keeps me up at nights

HomeWork

  • Propose some projects that keep me up at nights
  • Finish the NodeJS course
  • Write the Wireframe for the tracking project AirCrewMentor proposed.
Thanks for your time @AirCrewMentor , I’m loving it.

Wireframe, Throw & NodeJS API

Summary

  1. Wireframe
  2. Throw
  3. NodeJS API

Session

Interesting session where we finally fixed the mocha test with some hacking by @aircrewmentor and talked a little bit about Wireframe.

1. Wireframe

This is the way of writing down what the client or ourselves are expecting or want from a web page.

So this is the concept web page with all the functionalities that we need to get to it.

Usually in companies with some size there is a department responsible for this function. It basically consist in asking the client what does he/she want from the web page.

Hear what is the blue sky for the client.

Later we have to bring him/her to the ground of reality and show what his page will do. (or pass a gross bill for the blue sky).

2. Throw

We learned how to “Throw” an error so it is displayed on the terminal when running mocha or at the console.

if (!keyValue) {
throw new Error('Could not find DOM element ' + key + 'Message');
}

3. NodeJS

We went over the API to use the function fs.readFile and we use it in a synchronous way. where we had to include a callback in mocha.

So we used it to include our HTML in our tests.

before(function(done) {
global.document.body.innerHTML = fs.readFileSync(__dirname + '/../index.html');
testBrowser.jQueryify(function(err) {
calculateMortage = require('../js/calculate_mortage.js');
done(err);
});
});

Homework.

  • I have to write the Wireframe for our new project with an testable scaffold.
  • Do an small course for NodeJS.
  • I already started with CodeShcool
As always, thanks @aircrewmentor  for your time. Looking forward…

Stack trace & Fake Browser

Summary

  1. Stack trace
  2. ~~Fake Browser~~ Headless browser

Session

This session was really interesting, we didn’t cover a lot of points, but we focused on an important subject, as it is the testing area and reading the messages that the console was giving us back as a result of the test mocha passed.

1.Stack trace

This is what is called when we track from an error given to the code were the error is happening.

Here we can find the Wikipedia definition and I found a github project called StackTraceJs

Bassically we can say that Stack trace is:

navigate from the stack trace in the Run tool window to the source code that causes problems

We saw that the module lodash wasn’t loading, so we had to require('lodash') at the file itself. So we fixed the formatMoney function.

2.~~Fake Browser~~ Headless browser

To avoid the errors we saw document is not defined we installed the package Jsdom Test Browser so we had a ~~fake Browser~~ Headless browser running, now the error was that the function was getting some information from the HTML document and the document that was being passed by the jsdom-test-browser was empty, it wasn’t passing our markdown document.

So we interrupted the session at this point. We’ll continue with it next day.


Homework.

New Project – Track Line Map

We are going to develop a map where selecting a flight we can see it’s path drawn on the map.

The main goal is to draw the line given a coordinates in a map.

For it we are going to use the open source project for maps Leafletjs

A good way to explore what other developers have coded in a very succinct way Codepen we can search for similar projects like flights or map

As always, @aircrewmentor thanks for your help and your time. Looking forward to share more together.

Lodash, Async & Testem

Summary

  1. Polymorphism
  2. typed languages
  3. Dynamic languages
  4. variadic function
  5. Function signature
  6. JVM bytecode
  7. Lodash (better than underscore )
  8. Async
  9. Testem

Session

######1 Polymorphism

AirCrewMentor gave a little introduction about the Polymorphism code where we can bassically summarize that the same function name can be used in several functions and depending on what arguments and types you pass to the function, one version or other is activated.


######2 typed languages

In 2000 Microsoft created C# (C sharp) to compete with Java. In this languages the every variable or agument got its type defined, so if you are passing a wrong type of argument to a function or variable, the program wouldn’t compile, so this is really good to avoid bugs but it got no flexibility.

var totalPrice = 0;
var int totalPrice = 0;
totalPrice = “foo”;
// never compile

######3 Dynamic languages

Luckly for us, the dynamic languages like JavaScript are winning the battle but this means the number of bugs that can appear are higher.


######4 variadic function

This point I didn’t get it right, we’ll come over it again. @AirCrewMentor


######5 Function signature

The function can be differenced by the arguments it accepts, this is also known as function signature.

function calculateMortgage(deposit, monthlyIncome, interest, term, expenses)
// this would be the signature:
(deposit, monthlyIncome, interest, term, expenses)
// here we would have the same function with the Javascript type defined
// (javascript init type? @AirCrewMentor) that is used at the
//["Demandware gate community"](http://codingconnect.demandware.com)
function calculateMortgage(int deposit, int monthlyIncome,
double interest, int term, int expenses)
// this would be the signature:
(int deposit, int monthlyIncome, double interest, int term, int expenses)

“Demandware gate community”


Homework.

I have to rewrite the function formatMoney with lodash to accept argument and have a default value

formatMoney(123, options)
formatMoney(number, options)

Learn a real library that I would be using with real code projects.

If I have time left, I should learn how to test the UI that is harder than the mocha test we’ve been doing.

thank’s for your time @AirCrewMentor this was a really condensed session. 🙂

Git, Grunt, Browserify & MAKE

Summary

  1. Git (Branch, rebase, interactive mode…)
  2. Grunt (install grunt-cli locally)
  3. Browserify
  4. dist directory
  5. Makefile (Usual start)
  6. Test Fixture

Session

I am going to try to keep this summaries shorter and I am going to try a new format.


####1. Git

We talked about the options of Git with branches so I could save a middle done
work and nobody needs to see it.

For that I hace to find out about the following commands:

$ git rebase
$ git branch
$ git rebase interactive mode
Git is really large, but branches are essential.

####2. Grunt

I had to install grunt-cli at my package.json npm install grunt-cli --save-dev
first I’ve checked the version with which grunt


####3. Browserify

It is important to define relatives $PATH at our files so at the package.json we
updated it and gave indications for the relative path of the command Browserify with:

./node_modules/.bin/browserify
Check were the commands are located if we want them to properly work.

####4. Dist/

The browserify file should go into a dist directory.

All build artifacts go into the dist/ folder.

They should be automatically generated by a command like make dist

Usually this folder is served from the server to the browser in gzip format.

tarball == tar.gz

tar -zcvf folder/ name.tar.gz

gzip

compression algorithm

AirCrewMentor likes to run all the test on the dist/ folder.

the dist/ folder is where the final project goes.

####5. Makefile

At the make file, AirCrewMentor always include this 3 lines, we need to be sure about the path and that they are using bash, they could be using other ones (sh, zsh)

SHELL = /bin/bash
MAKEFLAGS += --no-print-directory --silent
export PATH := ./node_modules/.bin:$(PATH):./bin

####6. Test Fixtures

When we have multiple test we put the files into the folder called test.

To run it we use the make test or mocha test

To run multiple sequences of a test, we can use test fixtures that is a JSON file with all the possible data we are going to need to run it.

{“input”: [params here], “output”: “123 $”}

For the fixtures we are going to include a folder called “fixtures” inside test.

At the test file we need to pass a function to generate a closure, because when the mocha test starts, looses the environment and it would only pass one test, it wouldn’t itinerate trough all the fixtures we have ready. @AirCrewMentor

An example:

for (var i = 0; i < fixtures.length; i++) {
it("should generate " + fixtures[i].output, checkFixtures(fixtures[i]));
}
});

function checkFixtures(fixture) {
return function() {
expect(formatMoney.apply(null, fixture.input)).to.be(fixture.output);
};
}

Here we used the apply method


Evolution.

AirCrewMentor seemed happy with my evolution, I am at the last chapter of the book.

Homework

  • Group Testing files.
  • Add Fixtures
  • Refactor the format_money to accept objects on function.
options = {number: 123456, places: 3, symbol: “$”, thousand: “,”, “decimail: “.”};

formanMoney(options)
Thanks AirCrewMentor  for your time. You are amazing.