#!/usr/bin/env bash | |
#title : updateSonarProps.sh | |
#description : | |
# This script parses the project's name and version from its package.json and automagically | |
# updates the version and package name in the SonarQube configuration properties file. | |
# It can be used as a pre step before running the sonar-scanner command | |
# It also creates a backup of the props file with suffix *.bak | |
#prerequisites : NodeJS based project with package.json, sonar*.properties file in the cwd | |
#author : Christian-André Giehl <christian@emailbrief.de> | |
#date : 20180220 |
// TODO: Add pagination | |
function getCountries(str, p) { | |
let accum = 0; | |
https.get(`https://jsonmock.hackerrank.com/api/countries/search?name=${str}`, (resp) => { | |
let data = ''; | |
resp.on('data', (chunk) => { | |
data += chunk; | |
}); |
- You need to have the latest version of Node. Preferably, you're using 9.8.0, but the latest LTS should work as well.
- You should have
npx
installed usingnpm install -g npx
. - Install the React Developer Tools.
When you're developing in Node.js, you're likely to run into these terms - "monolithic" and "modular". They're usually used to describe the different types of frameworks and libraries; not just HTTP frameworks, but modules in general.
- Monolithic: "Batteries-included" and typically tightly coupled, it tries to include all the stuff that's needed for common usecases. An example of a monolithic web framework would be Sails.js.
- Modular: "Minimal" and loosely coupled. Only includes the bare minimum of functionality and structure, and the rest is a plugin. Fundamentally, it generally only has a single 'responsibility'. An example of a modular web framework would be Express.
In software development, the terms "tightly coupled" and "loosely coupled" are used to indicate how much components rely on each other; or more specifically, how many assumptions they make about each other. This directly translates to how easy it is to repla
Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
Promises
Challenge 1
Let's start by reviewing asynchronous functions! Using setTimeout, print the string 'Hello!' after 1000ms.
Challenge 2
Create a promise. Have it resolve with a value of 'Resolved!' in resolve after a delay of 1000ms, using setTimeout. Print the contents of the promise after it has been resolved by passing console.log to .then
Challenge 3
Create another promise. Now have it reject with a value of "Rejected!" without using setTimeout. Print the contents of the promise after it has been rejected by passing console.log to .catch
Challenge 4
Promises are asynchronous and we're now going to prove that they indeed are! Create a promise and have it resolve with the value of "Promise has been resolved!" Then uncomment the code at bottom of Challenge 4. What order do we expect "Promise has been resolved!" and "I'm not the promise!" to print? Why?
- Does the code work?
- Description of the project status is included.
- Code is easily understand.
- Code is written following the coding standarts/guidelines (React in our case).
- Code is in sync with existing code patterns/technologies.
- DRY. Is the same code duplicated more than twice?
function Foo(who) { | |
this.me = who; | |
} | |
Foo.prototype.identify = function() { | |
return "I am " + this.me; | |
}; | |
function Bar(who) { | |
Foo.call(this,"Bar:" + who); |
People
:bowtie: |
😄 :smile: |
😆 :laughing: |
---|---|---|
😊 :blush: |
😃 :smiley: |
:relaxed: |
😏 :smirk: |
😍 :heart_eyes: |
😘 :kissing_heart: |
😚 :kissing_closed_eyes: |
😳 :flushed: |
😌 :relieved: |
😆 :satisfied: |
😁 :grin: |
😉 :wink: |
😜 :stuck_out_tongue_winking_eye: |
😝 :stuck_out_tongue_closed_eyes: |
😀 :grinning: |
😗 :kissing: |
😙 :kissing_smiling_eyes: |
😛 :stuck_out_tongue: |