When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com, example2.com, and example1.com/images on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
| library(idbr) # devtools::install_github('walkerke/idbr') | |
| library(ggplot2) | |
| library(animation) | |
| library(dplyr) | |
| library(ggthemes) | |
| idb_api_key("Your Census API key goes here") | |
| male <- idb1('JA', 2010:2050, sex = 'male') %>% | |
| mutate(POP = POP * -1, |
| /* SudokuValidator(sudoku) | |
| * | |
| * @param sudoku a multidimensional array containing the sudoku puzzle | |
| * | |
| * @public property sudoku the sudoku grid | |
| * | |
| * @public method validate(num) num is the squared value or max value of sudoku number | |
| for example: 9(result of 3x3 grid) or 4 (2x2). | |
| */ |
| " Break away from vi | |
| set nocompatible | |
| " Map Leader to space | |
| let mapleader = "\<Space>" | |
| let g:mapleader = "\<Space>" | |
| " Basic Stuff | |
| set number |
You've been tasked to build a RESTful API that will help serve and manage data of coffee at a warehouse. Another team will be depending this API in building a front-end application to interact with it.
Draft a routes overview table or list of how you plan on designing your API and submit it to the senior developer for confirmation.
An example can be found on buzzword-bingo: https://github.com/devleague/Buzz-Word-Bingo/blob/master/README.md
We'll be depending on you to build a well-designed RESTful API for our front-end team to work with. Good route naming conventions will be key in providing a simple yet effective API for others to work with.
| # as super user after pointing domain to server. ref: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04 | |
| cd /usr/local/sbin | |
| wget https://dl.eff.org/certbot-auto | |
| chmod a+x /usr/local/sbin/certbot-auto | |
| certbot-auto certonly -a webroot --webroot-path=/usr/share/nginx/html -d [[site.com]] -d www.[[site.com]] | |
| openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048 | |
| # as root, edit the nginx config for the site you just set up | |
| vim /etc/nginx/conf.d/[[site.com]].conf | |
| # when editing the file, just follow all the directions to comment and uncomment TLS-related config |
| const express = require('express'); | |
| const path = require('path'); | |
| const bodyparser = require('body-parser'); | |
| const passport = require('passport'); | |
| const LocalStrategy = require('passport-local').Strategy; | |
| // const cookieParser = require('cookie-parser'); | |
| const session = require('express-session') | |
| const RedisStore = require('connect-redis')(session); |
Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt.
These are all general purpose hash functions, designed to calculate a digest of huge amounts of data in as short a time as possible. This means that they are fantastic for ensuring the integrity of data and utterly rubbish for storing passwords.
How? Basically, it’s slow as hell. It uses a variant of the Blowfish encryption algorithm’s keying schedule, and introduces a work factor, which allows you to determine how expensive the hash function will be.