#!/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..." |
Inspired by dannyfritz/commit-message-emoji
See also gitmoji.
Commit type | Emoji |
---|---|
Initial commit | 🎉 :tada: |
Version tag | 🔖 :bookmark: |
New feature | ✨ :sparkles: |
Bugfix | 🐛 :bug: |
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:
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.
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:
- 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
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
RestFul API를 사용하며 json을 많이 사용하게 됨에 따라 요즈음의 request의 Content-Type은 대부분이 application/json인 것이 많다.
아니면 파일 첨부를 위해 multipart/*를 사용한다. application/x-www-form-urlencoded는 form에서 default로 사용되는 것 이외에는 사실 잘 사용하지 않는 편으로 보인다.
요새 자주 사용하지 않지만, 하지만 여전히 application/x-www-form-urlencoded를 사용하는 경우가 존재한다.
Content-Type이 다름에 따라 뭐가 달라지겠느냐 하겠지만 다른 점이 분명히 있다.
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
// 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. | |
// |