Skip to main content


Calculate how long your code takes

///put whatever you want here
//returns time it took to run code

Install the latest version of node

nvm install node # "node"

5 ways to make an API call in code

How to use a package from git repo as a node node_modules

Upgrading npm dependencies

Functional Programming

Notes: use function based programming (input → output), always make sure they're pure, avoid iterative functions and use higher order functions instead, make sure your data is immutable, use persistent data structures for efficient immutability ("structural sharing"),

Generating tokens

12 digit Client-ID

import {v4 as uuidv4} from 'uuid'

const {customAlphabet} = require('nanoid')
const alphabet = '0123456789abcdefghijklmnopqrstuvwxyz'
const nanoid = customAlphabet(alphabet, 12)
const accct = `AC${nanoid()}`

console.log('API-Key: ', uuidv4())
console.log('Client-ID: ', accct)
// Copy Paste above to the customer

A word on TimeZones

You usually don't need to worry about time zones. Your code runs on a computer with a particular time zone and everything will work consistently in that zone without you doing anything. It's when you want to do complicated stuff across zones that you have to think about it. Even then, here are some pointers to help you avoid situations where you have to think carefully about time zones:

  1. Don't make servers think about local times. Configure them to use UTC and write your server's code to work in UTC. Times can often be thought of as a simple count of epoch milliseconds; what you would call that time (e.g. 9:30) in what zone doesn't (again, often) matter.
  2. Communicate times between systems in ISO 8601, like "2017-05-15T13:30:34Z" where possible (it doesn't matter if you use Z or some local offset; the point is that it precisely identifies the millisecond on the global timeline).
  3. Where possible, only think of time zones as a formatting concern; your application ideally never knows that the time it's working with is called "9:00" until it's being rendered to the user.
  4. Barring 3, do as much manipulation of the time (say, adding an hour to the current time) in the client code that's already running in the time zone where the results will matter.

All those things will make it less likely you ever need to work explicitly with time zones and may also save you plenty of other headaches. But those aren't possible for some applications; you might need to work with times in zones other than the one the program is running in, for any number of reasons. And that's where Luxon's time zone support comes in.