Archives

Wireframe, Throw & NodeJS API

~ AirCrew ~ Leave a comment

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

~ AirCrew ~ 1 Comment

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

~ AirCrew ~ Leave a comment

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

~ AirCrew ~ Leave a comment

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.