Skip to content

Instantly share code, notes, and snippets.


Nadeem Bitar shinzui

  • Los Angeles / San Francisco
  • Twitter @shinzui
View GitHub Profile
shinzui /
Created Apr 8, 2021 — forked from mtesseract/
Working around Haskell's namespace problem for records

The Problem

Defining records in Haskell causes accessor functions for the record's fields to be defined. There is no seperate namespace for these accessor functions.

The Goal

Be able to

  • use records in Haskell, which share field names.
  • use lenses for accessing these fields
View Optics
shinzui / Pubsub.hs
Created Dec 4, 2020 — forked from jamesthompson/Pubsub.hs
Example pub/sub grpc interface with fused-effects
View Pubsub.hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DerivingStrategies #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE InstanceSigs #-}
{-# LANGUAGE KindSignatures #-}
shinzui / Environment.hs
Created May 25, 2020 — forked from clementd-fretlink/Environment.hs
Env var parsing with free applicatives
View Environment.hs
#!/usr/bin/env stack
-- stack --resolver lts-14.20 --install-ghc runghc --package either --package free
{-# LANGUAGE DeriveFunctor #-}
module Main
import Control.Applicative.Free
import Data.Bifunctor (first)
import Data.Either.Combinators (maybeToRight)
import Data.Either.Validation
View Perf

Modern applications

Most JavaScript developers love making modern applications, with our new language features and latest libraries making our life easier, but has any one ever actually wondered if this ever impacts our users.

We are dealing with abstractions, abstractions are trying to cover a general use case which could not be conforming to yours. Some are over-engineered in ways one can't possibly comprehend, use cases that will never be reached by middle sized applications. Some of these over

shinzui /
Created Aug 12, 2019 — forked from gelisam/
A list of every data exchange formats I could find

At work, I just spent the last few weeks exploring and evaluating every format I could find, and my number one criteria was whether they supported sum types. I was especially interested in schema languages in which I could describe my types and then some standard specifies how to encode them using an on-the-wire format, usually JSON.

  1. Swagger represents sum types like Scala does, using subtyping. So you have a parent type EitherIntString with two subtypes Left and Right represented as {"discriminator": "Left", value: 42} and {"discriminator": "Right", value": "foo"}. Unfortunately, unlike in Scala in which the parent type is abstract and cannot be instantiated, in Swagger it looks like the parent type is concrete, so when you specify that your input is an EitherIntString, you might receive {"discriminator": "EitherIntString"} instead of one of its two subtypes.
  2. JSON-schema supports unions, which isn't quite the same thing as sum types because
title author
Oleg Grenrus

After I have improved the raw performance of optika – a JavaScript optics library, it's time to make the library (feature-)complete and sound. Gathering and classifying all possible optic types, gives us a reference point

shinzui /
Created Mar 31, 2019 — forked from sync/
Hooks reason graphql
module MemCache = {
type t;
[@bs.deriving abstract]
type config = {initialState: Js.Json.t};
type conf = Js.Json.t;
[@bs.module "graphql-hooks-memcache"]
external _createMemCache: config => t = "default";
View p2.csv
propertyId agentId
132 50000
99 50001
105 50002
120 50002
58 50003
46 50005
65 50006
66 50006
118 50011
View p.csv
buyerNeedId agentId
293 2324
313 1531