I made a list of 20 things I might want out of a monorepo tool for a Design System to use as a basis for comparing some of the options including Lerna, Northbrook, and Rush.
var fs = require("fs"); | |
var path = require("path"); | |
var cheerio = require("cheerio"); | |
module.exports = (mypath) => { | |
var inputFile = fs.readFileSync(mypath, "utf8"); | |
var $ = cheerio.load(inputFile, {xmlMode:true}); | |
// defines the selector |
Why should programmers care about Monoids? Because Monoids are a common pattern that shows up over and over in programming. And when patterns show up, we can abstract them and leverage work we've done in the past. This allows us to quickly develop solutions on top of proven, stable code.
Add Commutative Property to a Monoid (Commutative Monoid) and you have something that can be executed in parallel. With the end of Moore's Law, parallelism is our only hope to increasing processing speeds.
What follows is what I've learned after studying Monoids. It is hardly complete, but hopefully will prove to be helpful as an introduction for others.
import * as t from 'io-ts' | |
import * as React from 'react' | |
import { render } from 'react-dom' | |
type Field = t.StringType | t.NumberType | t.BooleanType | |
interface Form extends t.InterfaceType<{ [key: string]: Field }> {} | |
const toReactElement = (f: Form | Field): React.ReactElement<any> => { | |
// f is a tagged union | |
switch (f._tag) { |
#pragma once | |
#define DYN_ARR_OF(type) struct { \ | |
type *data; \ | |
type *endptr; \ | |
uint32_t capacity; \ | |
} | |
#if !defined(__cplusplus) | |
#define decltype(x) void* |
Questa non è farina del mio sacco, io ho solo copia incollato la discussione. Kudos to Giulio Canti
@vncz ho un consiglio su come procedere a strutturare un programma funzionale, con me ha funzionato bene, vediamo se funziona anche per te
In linea teorica e generale procedo così
- dominio
- firma del programma
- firme delle operazioni di base
TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.
If you've got a bit of time to watch a presentation on it, I highly recommend this talk: https://www.youtube.com/watch?v=pYeekwv3vC4 (Note that other topics are largely skimmed over, such as CSRF protection. You should learn about other topics from other sources. Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO.)
A related topic: Don't use localStorage (or sessionStorage) for authentication credentials, including JWT tokens: https://www.rdegges.com/2018/please-stop-using-local-storage/
The reason to avoid JWTs comes down to a couple different points:
- The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions
/*Stolen from http://aleclownes.com/2017/02/01/crt-display.html*/ | |
/*This adds a "crt scanlines" effect to the screen*/ | |
.crt-scanlines::before { | |
content: " "; | |
display: block; | |
position: absolute; | |
top: 0; | |
left: 0; | |
bottom: 0; |
- "primitive":
boolean
,number
,string
,symbol
,null
,undefined
- "object" aka "non-primitive": any "custom object" (e.g.
{ foo: 1 }
) or function
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#Data_types
(In JS, people mistakingly think of primitives as "object"s, but in strict JS terminology, they're not.)