| @startmindmap | |
| + Design Methods | |
| ++ Ideate | |
| +++ Brainstorming | |
| ++++_ Hope and Fears | |
| ++++_ Big Ideas | |
| ++++_ Dot Voting | |
| ++++_ Any Ideas | |
| ++++_ Sketch | |
| ++++_ Design Spring |
| // the main app file | |
| import express from "express"; | |
| import loadDb from "./loadDb"; // dummy middleware to load db (sets request.db) | |
| import authenticate from "./authentication"; // middleware for doing authentication | |
| import permit from "./permission"; // middleware for checking if user's role is permitted to make request | |
| const app = express(), | |
| api = express.Router(); | |
| // first middleware will setup db connection |
https://github.com/djvirgen/virgen-acl Simple and elegant, create your own checks. No middleware?
https://github.com/OptimalBits/node_acl Use as middleware, create your own roles and access. Great choice.
https://github.com/tschaub/authorized Similar to connect roles... but a bit more robust? you can create roles and action, and associate many roles with that action
| var toLowerCase = function(str) { | |
| // let result = []; | |
| var result = ``; | |
| str.split('').forEach(char => { | |
| // find current position | |
| let current = char.charCodeAt(0); | |
| if ('A'.charCodeAt(0) <= current) { | |
| if (current <= 'Z'.charCodeAt(0)) { |
| // index.js | |
| const express = require('express'); | |
| // import bcrypt and set the salt rounds | |
| // read about salt in the readme | |
| const bcrypt = require('bcrypt'); | |
| const bcryptSALTrounds = 10; | |
| const app = express(); | |
| const PORT = 3000; |
Zach Caceres
Javascript does not have the typical 'private' and 'public' specifiers of more traditional object oriented languages like C# or Java. However, you can achieve the same effect through the clever application of Javascript's function-level scoping. The Revealing Module pattern is a design pattern for Javascript applications that elegantly solves this problem.
The central principle of the Revealing Module pattern is that all functionality and variables should be hidden unless deliberately exposed.
Let's imagine we have a music application where a musicPlayer.js file handles much of our user's experience. We need to access some methods, but shouldn't be able to mess with other methods or variables.
| # /etc/init/puma.conf - Puma config | |
| # This example config should work with Ubuntu 12.04+. It | |
| # allows you to manage multiple Puma instances with | |
| # Upstart, Ubuntu's native service management tool. | |
| # | |
| # See puma-manager.conf for how to manage all Puma instances at once. | |
| # | |
| # Save this config as /etc/init/puma.conf then manage puma with: | |
| # sudo start puma app=PATH_TO_APP |
| # /etc/init/puma-manager.conf - manage a set of Pumas | |
| # This example config should work with Ubuntu 12.04+. It | |
| # allows you to manage multiple Puma instances with | |
| # Upstart, Ubuntu's native service management tool. | |
| # | |
| # See puma.conf for how to manage a single Puma instance. | |
| # | |
| # Use "stop puma-manager" to stop all Puma instances. | |
| # Use "start puma-manager" to start all instances. |
| ## | |
| # You should look at the following URL's in order to grasp a solid understanding | |
| # of Nginx configuration files in order to fully unleash the power of Nginx. | |
| # http://wiki.nginx.org/Pitfalls | |
| # http://wiki.nginx.org/QuickStart | |
| # http://wiki.nginx.org/Configuration | |
| # | |
| # Generally, you will want to move this file somewhere, and start with a clean | |
| # file but keep this around for reference. Or just disable in sites-enabled. | |
| # |
