サーバーサイドエンジニアの技術メモあれこれ

調べたことのメモがき。その他雑記もちょろちょろと。ゆるくやってます。

英語メモ

What is 英語?

書くまでもないとおもうので割愛。参考文献は以下。めっちゃよい。

www.youtube.com

メモ

5つのルール

  1. 主語 -> 「〜は」を入れる
  2. be動詞 -> イコールで訳す
  3. 一般動詞の後に名詞 -> 「~を」や「〜に」を付ける
  4. 余り物or前置詞 + 名詞 -> ()でくくって適当に訳す
  5. 文章中に2度目の主語・動詞 -> []でくくって名詞っぽく訳す。「を」がつきがち

目的語について

・動詞のあとに名詞が来ることが多い。 ・「誰に」「何を」と書きたい場合もある(第四文型)

動詞+ing

動詞を動詞以外の品詞にしたいから付ける。動詞が1文に2個出てくるのはまずいので無理やりingを付けて品詞を変える感じ。
分詞構文だとか考えなくて良い。

名詞

〜すること

形容詞

〜している

副詞

適当に訳す。

仮定法

意図的に時制を間違えて冗談を言う手法。
個人的には過去形を距離形と捉えて事実から距離が離れている、と考える方がわかりやすい。

不定

ing見たく名詞形容詞副詞のパターンがあって訳しにくい。

不定詞は構造で訳す

ルールに従って構造をつかむことができれば大体訳せる。ふんわり和訳はやめる。

名詞的用法

・主語だから名詞!
・目的語だから名詞!

その他(形容詞的用法、副詞的用法)

どうせ後置修飾だから前に出た何かを修飾してるんだろ、という前提のもとで、前側にある修飾対象を探す。
引っ付きそうなものを見つけたら適当に訳す。

疑問詞

・疑問詞は質問の目印。すぐ和訳を考えない ・主語になる場合とならない場合がある. 両方対応できるように軽く読み流して主語動詞を見つける ・疑問詞の元の位置を探す。

前置詞はイメージで攻略すべし

to

toは矢印。感覚的な記号のようなもの。
物理的な方向の矢印、意志の目的地への矢印の二種類がある。

as

asはいくつかある中でこれ!と決めるイメージ。 ああ、なんか指定してるんだな、と考えればOK。 個人的にしっくりくるのは「論点」って考え方。
As a child = 子供の頃(いくつか時代があるなかで子供の頃をピックしてる).

as ~ as ~の場合、as 論点 as 内容と言う感じでasで二つの要素をピックアップしてると考えるとよさそう.
as soon as possibe = 論点は「速さ」、内容は「可能な」= 可能な速さで = できる限り早く.
I can speak English as well as Japanese. = 論点は「程度(肯定的な意味合いで)」、内容は「日本語」 = 日本語ぐらいには英語も = 日本語だけでなく英語も.
may as well = 論点は「程度(肯定的な意味合いで)」+ may(かもしれないよ) = 肯定的な程度かもしれない = その方がいいかもしれない.
might as well = 論点は「程度(肯定的な意味合いで)」+ might(かもしれないよ+自信なさげ、後ろ向き) = どちらかと言えば肯定的な程度かもしれない = その方がマシかもね

even

強調

though

ギャップの存在を示す

ever

everはat any timeである

「全期間で」「あらゆる」みたいな感じの修飾語。前方向や横方向への「広がり」をイメージする。

never

not + 動詞 + ever => 全期間で + 〜していない => 決して〜ない

whoever

who + ever => 誰か + あらゆる => 誰でも 選択肢がめちゃくちゃ広がっていることをイメージする

forever

for + ever => 期間 + 全期間 => 永遠に

whichever

which + ever => どれか + あらゆる => どちらでも

however

how + ever => 方法 + あらゆる => どんな方法であれ(しかしながら)

ever more

時間的な広がりを捉えて「どんどん」みたいな感じ

k8sメモ

What is k8s

kubernetesのこと。

kubernetes.io

メモ

イベントドリブンオートスケーリング

以下を使って達成するらしい

keda.sh

yamlの管理

以下をつかってうまいこと共通化するのがメジャー

kustomize.io

Pod

k8sにおける最小の実行単位で、1つ以上のコンテナをまとめて管理・実行する入れ物
Pod単位でスケジューリング・ネットワーク・ストレージなどの管理を行う。
Podはあくまで実行単位なので、Podに対して細かい調整を随時入れることは考えず、使い捨て。生成するPodの運用はDeploymentにて行う。

Goメモ

What is Go?

go.dev

メモ

標準入出力

var N int
fmt.Scan(&N)

fmt.Println(N)

配列入出力

A := make([]int, N)
for i := 0; i < N; i++ {
    fmt.Scan(&A[i])
}

for i, v := range A {
    if i > 0 {
        fmt.Print(" ")
    }
    fmt.Print(v)
}

辞書型

// 空の map を作る(ゼロ値では使えない)
m := make(map[string]int)

// リテラルで初期化
m2 := map[string]int{
    "apple":  5,
    "banana": 3,
}

make を使わずに var m map[string]int とすると m は nil で、読み込みは可能なものの書き込みが禁止されている。このため、m["key"] = 1 をするとパニックになるので初期化が必要。

for文

実はGoではさまざまなパターンを使い分けできる。

C ライク(3要素)

for i := 0; i < 10; i++ {
    fmt.Println(i)
}

条件のみ(while)

i := 0
for i < 10 {
    fmt.Println(i)
    i++
}

無限

for {
    // done := true
    // if done {
    //     break
    // }
}

range(foreach)

for i, v := range A {
    if i > 0 {
        fmt.Print(" ")
    }
    fmt.Print(v)
}

ラベル付き制御

ラベルがついている反復まで一気に飛ぶ。
基本的には多重ループから脱出するときに使うはず。

Outer:
for i := 0; i < 3; i++ {
    for j := 0; j < 3; j++ {
        if i*j > 2 {
            break Outer
        }
        fmt.Println(i, j)
    }
}

並列処理関係

goroutine

channel

nilチャネル/close済みチャネル

nilチャネルは「送受信準備が永遠に完了しないチャネル」. close済みチャネルは「立ち入り禁止のふだが明確に建てられているチャネル」.

nilがわかりにくいが、送信してもいいのか?受信できるのか?を誰も自信を持てない状態。= 永久に準備完了と結論がだせない。

select/close

func fanIn(ch1, ch2, ch3, ch4, ch5 <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for {
            select {
            case v, ok := <-ch1:
                if !ok { ch1 = nil } else { out <- v }
            case v, ok := <-ch2:
                if !ok { ch2 = nil } else { out <- v }
            case v, ok := <-ch3:
                if !ok { ch3 = nil } else { out <- v }
            case v, ok := <-ch4:
                if !ok { ch4 = nil } else { out <- v }
            case v, ok := <-ch5:
                if !ok { ch5 = nil } else { out <- v }
            case <-time.After(time.Second * 5):
                fmt.Println("timeout")
                return
            }
            // 全部のチャネルが nil になったら終了
            if ch1 == nil && ch2 == nil && ch3 == nil && ch4 == nil && ch5 == nil {
                return
            }
        }
    }()
    return out
}

defer close(out)によってブロックを抜けるとともにcloseしている。
Go 言語仕様上、select に書ける case に上限はない。
受信チャネルを閉じたあとに nil にすると、その case は永遠に実行対象外になり、他の case だけを見続けられる。
case <-time.After(...) や default: を混ぜて「5秒待っても来なければ打ち切る」「何も来なければスキップする」など柔軟に制御可能

selectとgoroutine

select利用版

func mainLoop(sensor1, sensor2 <-chan Data, userCmd <-chan Command) {
    for {
        select {
        case d := <-sensor1:
            handleSensor1(d)
        case d := <-sensor2:
            handleSensor2(d)
        case cmd := <-userCmd:
            if cmd == Quit {
                return
            }
            handleCommand(cmd)
        }
    }
}

無限ループでselectを囲って何かしらの条件を通ったタイミングでforを離脱する作りはとてもよくやるので覚えておくと良い。

select未利用版

func mainLoop(sensor1, sensor2 <-chan Data, userCmd <-chan Command) {
    go func() { // センサー1専用
        for d := range sensor1 {
            handleSensor1(d)
        }
    }()
    go func() { // センサー2専用
        for d := range sensor2 {
            handleSensor2(d)
        }
    }()
    // ユーザーコマンドはメインで
    for cmd := range userCmd {
        if cmd == Quit {
            return
        }
        handleCommand(cmd)
    }
}

それぞれのゴルーチンがsensor変数における受信をfor rangeループで監視し続け処理している。
sensor自体がcloseされたタイミングでfor rangeループを抜けてゴルーチンが終了する。

context

contextは文脈。複数ゴルーチンが同じ文脈の処理を行う際に利用するイメージ。

キャンセル: 「処理がもう不要だから止めてくれ」という合図を複数の goroutine に伝える。
タイムアウト/期限: 「〇秒以内」「〇時まで」という制約を一括で管理できる。
値の伝達: リクエスト ID やユーザー情報などをスレッドローカルっぽく渡せる(ただし乱用は非推奨)。

HTTPリクエストの内部処理とかがわかりやすい。例えばcontextで設定しているタイムアウトに到達したら全てのgorutineを切り上げてエラーレスポンスを返すイメージ。(timeの方のタイムアウトはgorutineそれぞれの処理のタイムアウト設定って感じ。)

ElasticSearchメモ

What is ElasticSearch

www.elastic.co

メモ

データ投入

こちら参考に最新バージョンのやり方で

qiita.com

curl -X POST "http://localhost:9200/wine/_bulk" -H "Content-Type: application/x-ndjson" --data-binary @wine.json

検索

curl -X POST "http://localhost:9200/wine/_search" -H "Content-Type: application/json" -d '{"query":{"match":{"description":"渋め"}}}'

マッピング定義確認(みやすい形で)

curl -X GET "http://localhost:9200/wine/_mapping?pretty"

謎解きメモ

コツ一覧

よく使うもの

  • 五十音表(行パターンの他に代表的なのは段パターン、一部切り取りパターン、間確認パターン)
  • アルファベット
  • 調味料さしすせそ
  • 指(親指、人差し指、中指、薬指、小指)
  • 曜日
  • 年号(特に明治、大正、昭和、平成、令和)
  • 十二支
  • 九九
  • 太陽系の惑星
  • いろは歌
  • 色作り(赤と青で紫、等)

よく使う考え方

しりとり
たぬき暗号
隙間を見る
枠の形を見る
重なっている部分を見る
今までの問題で同じ形を探す

ありがちなのは以下。

  • 問題の枠デザイン
  • マス目の一部(数字が割り振られたマス、迷路などで枠の一部の太さが異なるマスを再利用しがち。唐突に四角を埋めろとだけ指示が来たらほぼこれ)
英語↔️日本語で変換
ルール説明箇所にギミック埋め込み

これはほんとによく見る

合体漢字
  • 花 = イサヒ
  • 左 = ナエ
  • 名 = タロ
忘れた頃にシール&トレーシングペーパー
暗黙の前提の破壊

思い込みで決めつけないように。「全て」といった曖昧な表現には敏感になること。例えば「爆弾を全て解除しろ」とだけ言われた時は隠し爆弾が無いかを必ず疑う、みたいな感じ。

物語冒頭の目的確認

本当の目的は何だったか?しれっと言われた指示がなかったか?を忘れないように。「本当にこれでよかったのでしょうか?」と言われないように。ラストの大謎で使わなければならない場合が多い。

イベント整理(主にリアル脱出で)
  • 誰が、どこで、何をした、を余すことなく時系列で整理する。しんどい場合は印象的なイベントだけでも。登場人物の行動から次に取るべきアクションを推定できることもある。

  • どこに、何を聞きに行けるか?も併せて整理する。登場人物の行動と併せることで運営に何を聞くべきかはっきりする場合がある。

勘違いで沼らないために

その時点で使える資料全てに目を通す
  • 慣れていないときは資料に書いてある指示をそもそも見落としていて超簡単な問題で沼ることがある。
問題文を改めて見直す
  • 引っ掛け以前に書いてある大前提の指示を正しく実行できているか?を確認する。たまに抜かしていて必須の情報が抜けていることも。

セキュリティ関連メモ

鍵関係

共通鍵暗号方式

通信相手と自信が同じ秘密鍵を所有して、暗号化と復号化を行う方式。
秘密鍵をセキュリティを担保しつつ配送する必要がある。(鍵配送問題). 暗号化方式としてはAES(Advanced Encryption Standard)だけ覚えておけば良さそう。

公開鍵暗号方式

暗号通信を受け取る側は、暗号化に利用する鍵を全世界に公開し、送信者にその鍵を使って暗号化してもらう。
公開した鍵と対になる秘密の鍵を別途持っておき、受け取ったデータをその鍵で復号する。
公開鍵から秘密鍵を推測することが困難である(計算量的安全性が担保されている)という大前提のもと成り立つ方式。

暗号化方式はRSA暗号(巨大な素数同士の掛け算は割戻が困難という性質を利用したもの。)

注意点

共通鍵暗号方式は現在でもバリッバリに使われている。
共通鍵暗号方式は公開鍵暗号方式よりも軽い計算量で復号できることが多いため、「共通鍵を公開鍵で暗号化して配送し鍵配送問題を回避する」という感じの使われ方が一般的。

電子署名

秘密鍵は復号化のみに使われるわけではない。
秘密鍵 = その人しか持っていないもの = 印鑑と同じような使い方ができる。

つまり、秘密鍵を使って暗号化(印鑑を押)し、その人が持っている公開鍵を使って復号化し検証する(その印鑑が本物か確かめる)、という使い方。
メッセージ自体を暗号化するわけではなく、ハッシュ値を付与するイメージ。送信者の正当性保証だったり送信経路上での改竄検知が目的

電子証明書

電子署名を検証するための公開鍵にくっついてるもの。その公開鍵が誰が公開したものなのかを証明するために利用する。(間違った公開鍵を使ってしまったら通信傍受が可能になるなど重大なセキュリティリスク。).

電子証明書PKI(Public Key Infrastracture)の認証局が発行する。 電子証明書は証明書リポジトリにて管理され、公開鍵やその認証情報がセットになっている。