Skip to content

Instantly share code, notes, and snippets.

View sftblw's full-sized avatar

Ch. (Chanwhi Choi) sftblw

View GitHub Profile
@shams-ali
shams-ali / docker-compose-wait-for-db.sh
Last active November 1, 2022 19:03 — forked from mvargeson/docker-compose-wait-for-db.sh
wait for db container to be available before starting server
#!/bin/bash THIS WORKED
bash -c 'while ! </dev/tcp/db/5432; do sleep 1; done; nodal db:bootstrap && nodal s;'
#THIS WORKS ONLY IF NETSTST INSTALLED
while ! nc -w 1 -z db 5432; do sleep 0.1; done
#ANOTHER WAY
until nc -z postgres 5432; do
echo "$(date) - waiting for postgres..."
@parmentf
parmentf / GitCommitEmoji.md
Last active May 12, 2025 06:48
Git Commit message Emoji
@dayvonjersen
dayvonjersen / README.md
Last active April 19, 2018 00:03
script to update Gogs (gogs.io)

This is a custom script for updating my install of gogs

This script is not officially endorsed by anyone

Use this script at our own risk, etc, etc


My install may differ significantly from your own, so here are some points of note:

@srl295
srl295 / node-leapseconds.md
Last active May 21, 2021 07:12
FAQ on leap seconds

What are Leap Seconds? What impact do they have on applications?

Leap seconds are seconds added or removed from UTC (Coordinated Universal Time) to keep it in sync with the Earth's rotation. If leap seconds were not added or removed, then UTC would drift from TAI. You can read much more about leap seconds on Wikipedia.

Because they are based on astronomical observations, leap seconds are scheduled and not predicted, or predictable. One has been scheduled for June 30th, 2015. What this means practically is that 23:59:59 will be followed by 23:59:60 before going on to 00:00:00. Leap seconds can be added (positive) or removed (negative). A negative leap second would mean that 23:59:58 would be followed by 00:00:00.

@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
@staltz
staltz / introrx.md
Last active May 12, 2025 23:22
The introduction to Reactive Programming you've been missing
@jays1204
jays1204 / postbodyEnc.md
Last active September 24, 2023 04:50
Http Method는 POST, Content-Type이 application/x-www-form-urlencoded인 경우 body를 encoding하는게 맞을까?

요즘의 Request

RestFul API를 사용하며 json을 많이 사용하게 됨에 따라 요즈음의 request의 Content-Type은 대부분이 application/json인 것이 많다.

아니면 파일 첨부를 위해 multipart/*를 사용한다. application/x-www-form-urlencoded는 form에서 default로 사용되는 것 이외에는 사실 잘 사용하지 않는 편으로 보인다.

요새 자주 사용하지 않지만, 하지만 여전히 application/x-www-form-urlencoded를 사용하는 경우가 존재한다.

Content-Type이 다름에 따라 뭐가 달라지겠느냐 하겠지만 다른 점이 분명히 있다.

@chanks
chanks / gist:7585810
Last active January 10, 2025 03:03
Turning PostgreSQL into a queue serving 10,000 jobs per second

Turning PostgreSQL into a queue serving 10,000 jobs per second

RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.

On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.

So, many developers have started going straight t

@dmur
dmur / MIT LICENSE
Created July 19, 2012 21:46
Attractively wrapped 80-col MIT license
// Permission is hereby granted, free of charge, to any person obtaining a
// copy of this software and associated documentation files (the "Software"),
// to deal in the Software without restriction, including without limitation
// the rights to use, copy, modify, merge, publish, distribute, sublicense,
// and/or sell copies of the Software, and to permit persons to whom the
// Software is furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//