Skip to main content

Basics

Calculate how long your code takes​

console.time('⏰')
///put whatever you want here
console.timeEnd('⏰')
//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​

https://www.twilio.com/blog/2017/08/http-requests-in-node-js.html

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

https://medium.com/pravin-lolage/how-to-use-your-own-package-from-git-repository-as-a-node-module-8b543c13957e

Upgrading npm dependencies​

https://www.carlrippon.com/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"),

https://www.youtube.com/watch?v=e-5obm1G_FY&ab_channel=JSConf

https://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming

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.