「誤りとはいえない」は「現時点で誤りといいきれる根拠がない」と解釈すべきであって「誤りではない」とは別だと思う (現実的に「誤りである」が示せるケースがごく少数であるという点は別の話として)
「誤りとはいえない」は「現時点で誤りといいきれる根拠がない」と解釈すべきであって「誤りではない」とは別だと思う (現実的に「誤りである」が示せるケースがごく少数であるという点は別の話として)
あるいは極端な例としては「昔は誤りとされていた用法だが広く普及しすぎて当然のように使われるようになった用法」とかも「誤りとはいえない」と表現することがあるだろうし
抵抗器のカラーコードで思い出したけど、コンデンサの容量の表記が たとえば 123 だったら 12×10^3 なの、ちょっと嫌い。
そこ指数表記するなら 1.2×10^3 とかの方が自然じゃんと思ってしまう (文化圏の違い)
ぱっと見で10倍違う値を読み取って、「いやまて、これ直観的でない表記だったはず……」と調べ直すようなことを毎回やっている
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
爪の先ほどの大きさのチップ抵抗なら、視力が悪かろうが色覚特性が人と違おうが関係ないわけで、やはり世界はバリアフリーの方向へ進んでいるといえる (????)
このアカウントは、notestockで公開設定になっていません。
MIL論理記号 - Wikipedia
https://ja.wikipedia.org/wiki/MIL%E8%AB%96%E7%90%86%E8%A8%98%E5%8F%B7
このアカウントは、notestockで公開設定になっていません。
たぶん大半の人は抵抗器に触れる機会はなくて、理科の実験で触る抵抗っぽいものは意味敵には抵抗器ではなく負荷だから四角で書いていて……みたいなアレで四角の方が伝わりやすそうというのは昔からあった
そういえば昔は線が交差するところも素通しではなくピョンと弧を描いて飛び越える感じで書いていた気がするんだけど、いつのまにか結合部分の点の有無で区別するようになっていて、あれもちょっと戸惑ったな
回路記号:配線と接続 Wiring and Connection
http://www.ele.kochi-tech.ac.jp/tacibana/etc/analog-intro/wiring.html
昔は図1の (d) みたいなのが普通だった気がするんだけど、いつのまにか (a) が主流になっていて
FGOの新しい人の露出が激しくてラストオリジンかよって言われてラストオリジンのプレイヤーが乳と尻が小さいって言う様式美が発生したらしい
普通のリード付いたカーボン抵抗をジャラジャラ入れられて分類できるソリューション,なんかあるんかな やっぱチャックつき袋?
https://mastodon.cardina1.red/@lo48576/105039898958195950
昨年「来年こそ使おう」と思っていた素材画像を今年も使い損ねたことに気付いた顔をしています
ファームウェアを一定のバージョンにアップデートするとヒューズを焼き切るなどの不可逆な痕跡を残すことで exploit 目的のダウングレードを阻止するなどの手法があるらしく、ほぇ〜となりました
Nintendo Switchの13.0.0はeFuse焼かないバージョン | 大人のためのゲーム講座
https://gamegaz.com/2021091834116/
このアカウントは、notestockで公開設定になっていません。
nginx で
location /foo/ {
set $backend "backend";
proxy_pass http://$backend:12345/;
}
のように traliling slash を付けているはずなのに、 /foo/bar へのリクエストが backend:12345/bar でなく backend:12345/ に飛んでしまう。何故だ……
proxy_pass で変数使うのやめて http://backend:12345/ とダイレクトに書いたらちゃんとパス含めてリダイレクトされるようになった……何だこれ
/good/foo にアクセスするとバックエンドの /foo にアクセスが飛ぶが、 /bad/foo にアクセスすると何故かバックエンドの / にアクセスが飛ぶ。 nginx 1.21.3。
nginx 意味わかんねえ、なんだこれ!
@orumin 私もその仕様を期待していたんですが、ホスト名に変数 ($backend 等) を使うとそもそも trailing slash の有無に関係なくリクエストのパス部が全て捨てられるという最悪仕様に遭遇したという話です……
@orumin proxy_pass で :9100/ しているので /good/foo や /bad/foo は :9100/foo にアクセスが飛んでほしかったんですが、 $backend:9100/ していると絶対に $backend:9100/ 自体にしかリクエストが飛ばないみたいで……
原因がわかったところで ansible による nginx 設定自動生成を見直す必要があって、正規表現で後ろのパスを全部マッチさせて proxy_redirect http://$backend:9100/$1; するか、あるいは潔く単一ファイルだけリダイレクトできればよしとするか……
ちなみにバックエンドをわざわざ変数にしているのは、こうしないと起動時に一度だけ解決された IP アドレスを使おうとするからで、それではバックエンドが docker で管理されていて reverse proxy より後に起動させたり IP アドレスを変化させる可能性があるので困る。
そこで 127.0.0.11 の Docker の DNS を使ってアクセス毎に名前解決をさせている
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
> When variables are used in proxy_pass:
>
> location /name/ {
> proxy_pass http://127.0.0.1$request_uri;
> }
>
> In this case, if URI is specified in the directive, it is passed to the server as is, replacing the original request URI.
これか!
本来は末尾で path 系の変数を使ったとき重複させないためのルールっぽいけど、ドメイン部分の置き換えのみを意図して使った場合にも同ルールが適用されていると……完全に理解したわ
Nginx: Everything about proxy_pass - DEV Community
upstream
https://dev.to/danielkun/nginx-everything-about-proxypass-2ona
わかったうえで upstream と variable による proxy_pass の違いを調べようとしたら、あっという間に説明が出てきた……どうしてこう……
nginxのupstreamコンテキストで有償のresolveオプションを使わずに動的にDNS解決する - Qiita
https://qiita.com/minamijoyo/items/183e51a28a3a9d79182f
upstream context では resolver を使えないから変数使ってたのね、了解
nginx proxy の名前解決問題、ファイナルアンサー? | 1Q77
https://blog.1q77.com/2016/03/nginx-resolving-proxy-upstream/
location でのマッチ段階でキャプチャするよりは rewrite を素直に使った方がきれい、了解
理解したことしかブログに書かないから、読み返しても誤字と不自然な表現の発見くらいしか得るものがない (?)
ちなみに小文字の r が勃起している人を横から見ている図だと覚えるといいです (は?)
このアカウントは、notestockで公開設定になっていません。
ゲーム条例を巡り2つ目の裁判に 弁護士費用の返還など求め住民が提訴 香川 | KSBニュース | KSB瀬戸内海放送
https://news.ksb.co.jp/article/14463143
pixivのブックマークに関する負荷対策をしました - pixiv inside https://inside.pixiv.blog/2021/10/21/154500
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
20分ごとに load avg. が 0.4 くらいまで跳ねていて、これたぶん Thanos がメトリクスを object storage にアップロードしている瞬間っぽいな
普通に鯖立てて放置してたらこういうの絶対気付けなかったし、なるほど監視ソリュッションすごいですね