Skip to content

Instantly share code, notes, and snippets.

View larrylv's full-sized avatar

Larry Lv larrylv

View GitHub Profile
@enricofoltran
enricofoltran / main.go
Last active April 1, 2024 00:17
A simple golang web server with basic logging, tracing, health check, graceful shutdown and zero dependencies
package main
import (
"context"
"flag"
"fmt"
"log"
"net/http"
"os"
"os/signal"

FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.


Effective Engineer - Notes

What's an Effective Engineer?

@yang-wei
yang-wei / decode.md
Last active April 2, 2024 20:18
Elm Json.Decode tutorial and cheatsheet

When receiving JSON data from other resources(server API etc), we need Json.Decode to convert the JSON values into Elm values. This gist let you quickly learn how to do that.

I like to follow working example code so this is how the boilerplate will look like:

import Graphics.Element exposing (Element, show)
import Task exposing (Task, andThen)
import Json.Decode exposing (Decoder, int, string, object3, (:=))

import Http
@vkostyukov
vkostyukov / statuses.md
Last active February 13, 2024 21:39
HTTP status codes used by world-famous APIs
API Status Codes
[Twitter][tw] 200, 304, 400, 401, 403, 404, 406, 410, 420, 422, 429, 500, 502, 503, 504
[Stripe][stripe] 200, 400, 401, 402, 404, 429, 500, 502, 503, 504
[Github][gh] 200, 400, 422, 301, 302, 304, 307, 401, 403
[Pagerduty][pd] 200, 201, 204, 400, 401, 403, 404, 408, 500
[NewRelic Plugins][nr] 200, 400, 403, 404, 405, 413, 500, 502, 503, 503
[Etsy][etsy] 200, 201, 400, 403, 404, 500, 503
[Dropbox][db] 200, 400, 401, 403, 404, 405, 429, 503, 507
@henrik
henrik / 1-progressive_downloader.ex
Last active December 4, 2020 05:41
Example of progressive downloading with HTTPotion, showing percentage and downloaded bytes as you go.
defmodule ProgressiveDownloader do
def run do
url = "https://ia600308.us.archive.org/2/items/HealthYo1953/HealthYo1953_512kb.mp4"
HTTPotion.get url, stream_to: self, timeout: :infinity
receive_data(total_bytes: :unknown, data: "")
end
defp receive_data(total_bytes: total_bytes, data: data) do
@henrik
henrik / deploying_phoenix_on_dokku.md
Last active April 14, 2024 00:32
Deploying Elixir's Phoenix Framework on Dokku.

Deploying Phoenix on Dokku

Worked 2015-09-08 for Phoenix 1.0.1 on Dokku 0.3.25.

These instructions assume you've set up Dokku. If not, go find a tutorial for that part. My notes for setting it up on Digital Ocean.

On your local machine, in the app's repo

Create a Dokku app:

@PurpleBooth
PurpleBooth / README-Template.md
Last active May 6, 2024 07:22
A template to make good README.md

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

@zchee
zchee / actionlist.vim
Last active April 19, 2024 13:22
IdeaVim actionlist
--- Actions ---
$Copy <M-C>
$Cut <M-X> <S-Del>
$Delete <Del> <BS> <M-BS>
$LRU
$Paste <M-V>
$Redo <M-S-Z> <A-S-BS>
$SearchWeb <A-S-G>
$SelectAll <M-A>
$Undo <M-Z>
@ohanhi
ohanhi / frp.md
Last active May 6, 2024 05:17
Learning FP the hard way: Experiences on the Elm language

Learning FP the hard way: Experiences on the Elm language

by Ossi Hanhinen, @ohanhi

with the support of Futurice 💚.

Licensed under CC BY 4.0.

Editorial note

@evancz
evancz / Architecture.md
Last active December 21, 2022 14:28
Ideas and guidelines for architecting larger applications in Elm to be modular and extensible

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

  1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo