JacobWeisenburger

import { z } from 'zod'

function safeParseJSON ( string: string ): any {
    try { return JSON.parse( string ) }
    catch { return string }
}

function searchParamsToValues ( searchParams: URLSearchParams ): Record<string, any> {
    return Array.from( searchParams.keys() ).reduce( ( record, key ) => {
        const values = searchParams.getAll( key ).map( safeParseJSON )

baetheus

This implementation can now be found in production here

Widdershin

In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.

After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.

But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.

And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?

In dark rooms, in hushed tones, we speak of colours.

Willmo36

import * as T from "monocle-ts/lib/Traversal";
import * as R from "fp-ts/lib/Record";
import { pipe } from "fp-ts/lib/function";
import { Lens } from "monocle-ts";

type Person = {
  age: number;
  hairColor: string;
};

benawad

" Specify a directory for plugins
call plug#begin('~/.vim/plugged')

Plug 'neoclide/coc.nvim', {'branch': 'release'}
Plug 'scrooloose/nerdtree'
"Plug 'tsony-tsonev/nerdtree-git-plugin'
Plug 'Xuyuanp/nerdtree-git-plugin'
Plug 'tiagofumo/vim-nerdtree-syntax-highlight'
Plug 'ryanoasis/vim-devicons'
Plug 'airblade/vim-gitgutter'

effe-megna

import { Monad2 } from 'fp-ts/lib/Monad'
import * as RD from "@devexperts/remote-data-ts"
import * as T from "fp-ts/lib/Task"
import * as TE from "fp-ts/lib/TaskEither"
import * as E from "fp-ts/lib/Either"
import { pipe, pipeable } from "fp-ts/lib/pipeable"
import { sequenceT } from 'fp-ts/lib/Apply'

declare module 'fp-ts/lib/HKT' {
  interface URItoKind2<E, A> {

gcanti

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) {

AndyShiue

I think I’ve figured out most parts of the cubical type theory papers; I’m going to take a shot to explain it informally in the format of Q&As. I prefer using syntax or terminologies that fit better rather than the more standard ones.

Q: What is cubical type theory?

A: It’s a type theory giving homotopy type theory its computational meaning.

Q: What is homotopy type theory then?

A: It’s traditional type theory (which refers to Martin-Löf type theory in this Q&A) augmented with higher inductive types and the univalence axiom.

ibraheem4

Installing Postgres via Brew

Pre-Reqs

Brew Package Manager

In your command-line run the following commands:

1. brew doctor
2. brew update

ChrisPenner

Today we'll be looking into Kmett's
[adjunctions](http://hackage.haskell.org/package/adjunctions) library,
particularly the meat of the library in Data.Functor.Adjunction.

This post is a literate haskell file, which means you can load it right up in
ghci and play around with it! Like any good haskell file we need half a dozen
language pragmas and imports before we get started.

> {-# language DeriveFunctor #-}
> {-# language TypeFamilies #-}