2021-09-02

最近おもしろかった漫画( 7月~)

これは何？

概要

ざっくり7月〜で読んだ本、一旦書き出して振り返ってみる Primeの特典とかkindle unlimitedで読んだ本で特に印象に残らなかったものは省いている

八百森のエリー 1~5

野菜市場の仲卸の漫画、仲卸って流通の間に挟まっているなにか、みたいな認識だったけど色々やってるんだなぁみたいな気持ちになった。野菜界における「重版出来」的ポジションの漫画、雑誌移転により一瞬止まっていたぽい

ブラック・ラグーン（１２）

最初に読んだのは高校生の頃だろうか、久々に新刊が出て懐かしい気持ちになった。 "ブラック・ラグーン"であることに間違いはないが、なんか雰囲気が変わったというか馴染みの定食屋でいつも頼むメニュー的な？。作品の年齢より作者の年齢の方が早く進みますからね... BUMP OF CHICKENで言うとユグドラシル以降という感じ。

山賊ダイアリー

一度猟に行って見たいなぁと思ってはいるが銃の免許をとるのは（面倒さの）ハードルが高い脱サラして猟師なった人のエッセー的な漫画なのでイメージがつきやすくて良いね

来世ではちゃんとします 7

あずまんが形式の（今時４コマで話が進むのが当たり前なので今更こういう言い方はしないのだろうか？）"""現代的な価値観の"""恋愛漫画登場人物は多いが話が独立しているので読みやすい

クマ撃ちの女

なんかちょっとDirtyな部分も描かれているが、実態はもっとDirtyなのかもしれない。取材漫画的な感じだけど、どこまで事実なんだろう

ランウェイで笑って（２２）

完結しちゃいましたねぇ(ﾆﾁｬｧ（略カエルDXの絵

よかったですね

違国日記

普通の（ここでの普通さとは社会性の高い人間が自己を正当化する上で使うもの）女子高生が、非健常者の（ここでの健常者は自己の健常さを自己の定義する健常性から定義するもの）家で、"""コミュニケーションの仕方"""を学ぶ

これは結構良くて〜なんか距離感的な〜（言語野が壊れた）

東京入星管理局

設定が飛ばしすぎてて難しいけど、スピード感ある

サイバネ飯

上と同じ作者、こっちの方が好き

読切いろいろ

山本先生いいですね〜

昭和元禄落語心中

シュッと読む分には面白いが、が、作者の嗜好との違いによる引っ掛かりが。ネタバレになるんで書かないが、「腐系の方ってこういうことするよね〜〜？？」ってなるアレ。わかりますよね？

メイドインアビス（１０）

新刊が1年ペースなので、また1年待たねばならんのか... 出てくるキャラクターが可愛いので好きです。あと作者とのシナジーがある。

JKハルは異世界で娼婦になった

異世界転生俺TUEEメタ作品、テーマであるところの娼婦が生かせてないように感じた。倉科遼っぽく書いてもウケないのはわかるが。

Artiste

いい人が出てくるいい話、料理漫画ではない、好き

衛府の七忍

誤チェストでごわす、の本

１０巻読んでもどういう世界観なのかわからない

この世界は不完全すぎる（４）

SAOの世界でデバッガが閉じ込められてしまいました、みたいな話。職業柄、親近感があるのでいいですね

葬送のフリーレン（５）

この漫画読んで最初に思ったこととして「こういう叙事詩？的な漫画って増えてる感じするよな〜メタが進んでる的な〜」今の時代に物語を描きたくても例えばタイの大冒険みたいに「魔王を倒す過程を描きます」を描いてもウケないのはわかる。傘でアバンストラッシュしたよね？みたいな前提で話を作ってるよね。

AV男優はじめました

そもそも自分は業界の話みたいなのが好きなんすよね〜映像作品とかだとドキュメンタリしか見ないし、その中で汁男優からAV男優やります！っていうのは新しいかなって

BEASTARS　２２

なんかこういう設定の作品って多いよね？共存できない存在が頑張って共栄する的な

この作中でいう草食動物や肉食動物は我々の世界でいうソレらと実は違ってメタファー的な存在なんだけど、現実世界の存在とメタファー存在の境界を曖昧にぼかしていることにより作品への没頭感というか親しみやすさを与えているのがすげーうまいなって思った。作者の性癖が強く出ているが、その点も曖昧にしちゃってるんで凄いですね、パワープレイしていますね。

抜刀（１）

なんか荒いけど攻めてて面白いが次の巻は買う決断に至らなかった、続きが気になるかというと？

2021-07-28

運用中のS3を暗号化する話

概要

"""社会"""にはいろいろあるので、運用中のS3を暗号化しました

HERPの話です。採用してます。

careers.herp.co.jp

ざっくり以下の内容（+ S3 Bucket Key）をやった、という感じです

Encrypting objects with Amazon S3 Batch Operations | AWS Storage Blog

制約と方向性

ここでいう暗号化はSSE(Server Side Encryption)です

AWS Key Management Service (SSE-KMS) に保存されている CMK でサーバー側の暗号化を使用してデータを保護する - Amazon Simple Storage Service

S3の暗号化はオブジェクトごとなので、暗号化済みオブジェクトとそうでないものが混ざったBucketに対して権限さえ適切であれば問題なくR/Wすることができます。

ちなみに鍵の指定方法として

Amazon S3 が管理する暗号化キー
AWS 管理の CMK
カスタマー管理の CMK
持ち込みの暗号化キー

がありますが、今回はカスタマー管理のCMKにすることにしました。SSE-KMSです。

カスタマー管理のCMKはクロスアカウントできるとか、キーロテーションの期間を変更することができるとかのメリットがあります。

なので、今回の適切な権限はアプリケーション側が使用している権限に以下が追加されることを想定しています

        {
            "Action": [
                "kms:GenerateDataKey",
                "kms:Decrypt"
            ],
            "Effect": "Allow",
            "Resource": [
                "なんか鍵"
            ]
        }

2020年ごろに S3 バケットキーという感じの機能が追加されて、R/WのたびにKMS使用コストがかかっていたのが不要になるのでそっちを使います

Amazon S3 バケットキーを使用した SSE-KMS のコストの削減 - Amazon Simple Storage Service

KMS キーポリシーが適切なPrincipalに対して kms:Decrypt が許可されているのを確認します。クロスアカウントでなければ問題ないはずです。

余談ですが、Principalが s3.amazonaws.com でなくていいんすね。ここら辺のPrincipal感覚はあまりわかっていないですね。

フロー

というわけで、以下のフローでやります

アプリケーションに上記の権限を足して、デプロイする
BucketのSSEを有効にする
暗号化されていないものを暗号化する

BucketのSSEを有効化

terraformの擬似コードですが、以下のようになります

resource "aws_kms_key" "this" { }

resource "aws_s3_bucket" "this" {
  bucket = "example"
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        kms_master_key_id = aws_kms_key.this.arn
        sse_algorithm     = "aws:kms"
      }
      bucket_key_enabled = true
    }
  }
  versioning {
    enabled = true
  }
}

暗号化されていないものを暗号化する

Objectを再Putすると暗号化されます。最近はs3 batchと呼ばれる便利なものがあるのでそれを使います

inventory 設定

s3 batchを実行するためにkeyのリストが必要なので s3 inventoryを使います。

s3 inventoryの実行結果を保存するBucketを用意します。

resource "aws_s3_bucket" "s3-batch" {
  bucket        = "example-s3-batch"
  force_destroy = true
  policy        = <<EOF
{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect": "Allow",
      "Principal": {
          "Service": "s3.amazonaws.com"
      },
      "Action": [
          "s3:PutObject"
      ],
      "Resource": [
          "arn:aws:s3:::example-s3-batch/*"
      ],
      "Condition": {
          "ArnLike": {
              "aws:SourceArn": "arn:aws:s3:::*"
          },
          "StringEquals": {
              "aws:SourceAccount": "${アカウントID}",
              "s3:x-amz-acl": "bucket-owner-full-control"
          }
      }
    }
  ]
}
EOF
}

s3 inventoryの設定は以下のようになります

resource "aws_s3_bucket_inventory" "auth" {
  bucket                   = aws_s3_bucket.this.bucket
  name                     = "exapmle"
  included_object_versions = "All"
  optional_fields          = ["EncryptionStatus"]//, "BucketKeyStatus"
  schedule {
    frequency = "Daily"
  }

  destination {
    bucket {
      format     = "CSV"
      bucket_arn = "arn:aws:s3:::example-s3-batch"
    }
  }
}

このコメントアウトされているBucketKeyStatus部分はBucket Keyで暗号化されているかのステータスが取れるので本当は欲しいんですが、terraformのaws providerで対応されていないのでterraformでやりたければ諦める必要があります。（今週末時間があれば修正したいな...）

inventory結果

24~48時間程度たつと、結果がexample-s3-batchに保存され始めます。 Dailyでどのタイミングのリストかわからないので、余裕を持つ必要があります。 X日にSSEを有効にしていた場合、X+2日の日付のを使うぐらいがいいんじゃないでしょうか。

s3 batch

s3 batch実行用のRoleを作ります

Granting permissions for Amazon S3 Batch Operations - Amazon Simple Storage Service

上を参考にしますが、ブログ用に書き直すがめんどくさかったので、サンプルのコードではs3の任意actionを許可しました。 kmsの権限を足すことを忘れないように

resource "aws_iam_role" "s3-batch" {
  name               = "s3-batch"
  assume_role_policy = <<EOF
{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Principal":{
            "Service":"batchoperations.s3.amazonaws.com"
         },
         "Action":"sts:AssumeRole"
      }
   ]
}
EOF
}

resource "aws_iam_role_policy" "s3-batch" {
  policy = <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:*"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Action": [
                "kms:GenerateDataKey",
                "kms:Decrypt"
            ],
            "Effect": "Allow",
            "Resource": [
                "*"
            ]
        },
    ]
}
EOF
  role   = aws_iam_role.s3-batch.id
}

実行していきます。s3 inventoryから出力されたcsvからs3 batchを積むスクリプトが以下になります。適宜環境変数は埋めましょう。わかりにくいですが、envはs3 inventoryのname属性になります。

manifest_bucket=
env=
target_bucket=
date=

# manifest.jsonにcsvのpathが入っている
target_bucket_arn=arn:aws:s3:::$target_bucket
key=$(aws s3 cp s3://$manifest_bucket/$target_bucket/$env/$date/manifest.json - | \
jq -r '.files[].key')

# Amazon S3 Selectを使って暗号化されていないobjectのpathだけ取得する
# s._4が isLatest s._6がEncryptionStatus
aws s3api select-object-content \
  --bucket "$manifest_bucket" --key "$key" \
  --input-serialization 'CSV={},CompressionType=GZIP' \
  --output-serialization 'CSV={}'\
  --expression "select s._1, s._2 from s3object s where s._4 = 'true' and s._6 = 'NOT-SSE'" \
  --expression-type SQL $env-output.csv

csv_key=$env/output.csv

# なんかs3に上がってないとダメなんでアップロードする

aws s3 cp $env-output.csv s3://$manifest_bucket/$csv_key

etag=$(aws s3api head-object --bucket $manifest_bucket --key $csv_key | jq -r .ETag)

# s3 batchのJobを積む
aws s3control create-job \
    --region ap-northeast-1 \
    --account-id "$AWS_ACCOUNT_ID" \
    --operation "S3PutObjectCopy={BucketKeyEnabled=true,TargetResource=$target_bucket_arn}" \
    --manifest '{"Spec":{"Format":"S3BatchOperations_CSV_20180820","Fields":["Bucket", "Key"]},"Location":{"ObjectArn":"arn:aws:s3:::'$manifest_bucket/$csv_key'","ETag":'$etag'}}' \
    --report "Bucket=arn:aws:s3:::$manifest_bucket,Prefix=s3-batch-reports,Format=Report_CSV_20180820,Enabled=true,ReportScope=FailedTasksOnly" \
    --priority 42 \
    --role-arn "$ROLE_ARN" \
    --client-request-token $(uuidgen) \
    --description "$env" \
    --no-confirmation-required

operationのoptionに BucketKeyEnabled=true が含まれているんですが、S3 Bucket Keyが有効である場合このオプションなしで動くと思っていたんですが、つけないとダメでした。

このオプションなしだとS3 Bucket Keyなしで暗号化されます。

最初、kms のkey policyのPrincipalにs3 batchが含まれていないことが原因かと思ったのですが、そこそこ試した結果kmsのkey policyは関係ないと判断しました。

AWS 有識者の情報をお待ちしております。

確認

暗号化されているか確認するために後日再びS3 Selectを使って確認します

select s._1, s._2 from s3object s where s._4 = 'true' and s._6 = 'NOT-SSE' の結果が空であれば全ての暗号化が完了しています。現状Objectを上書きする運用をしていないので、今回s._4を見る必要がない気はします。 BucketKeyStatus を有効にしてあれば、s._7 も確認すると S3 Bucket Keyが使われているか確認することができます。

再掲

careers.herp.co.jp

上記の内容はConsoleをぽちぽちしていてもできると思いますが、HERPでは仕事の完了の定義の中にコード化することを含めています。

2021-07-11

OSSへの貢献

私信電信(https://shishindenshin.vercel.app)、二回目のテーマは「OSSへの貢献」

1

自分は厳格なFreeSoftware 主義者というほど極端ではないかもしれないがそれよりだと思う。

今まで過程を考えると、高校までまわりにプログラミング言語と英語の区別もついてない田舎でインターネットの情報を頼りに勉強するしかなかったので、OSS特にJavaScriptがメインとなっていく。そのうちWebFrontendを特に専門に仕事を始めるがこれもOSS無くして成り立たないわけで(最近はSREをやっているがこちらもOSS無しでは成り立たない)、

そういった環境で生きてきたことからOSSに還元すべきという考えに至るのは当然のように感じる

2

とはいえOSSに貢献するということはめちゃくちゃ難しく感じるが、それは難しく考えすぎているのだと思う。

貢献の仕方として例えば、「GitHubのIssueの中からバグや不足している機能を探してきてPRを作成してmergeする」というものがあるが、このレベルのものはこれが解決しないと業務が進まない事象に直面してようやくできることで、そもそも詳しくないと無理。「なりたい職業？そうですねぇ。不動産収入の不労所得で暮らしたいですねぇ」ぐらい夢。

だからもっと簡単をする、バグ報告とかドキュメント書くとかブログ書くとか勉強会で{発表,参加}するとかtwitterするとか。 OSSの中の再頒布の自由に近いかもしれないけど、情報を頒布して自由な技術を広めるのもは貢献という意味でも価値が高い。それも気力がいる。

だからもっともっと簡単できて、少しでもOSSに対して貢献できるように大事にしていることは

「わからないことを聞く」「聞かれたら答える」

そもそも人が何をわからないかってわかんないんで、自分がわからないこと、という情報を広めるのは大事。それと同様に聞かれたら答える。答えたことをブログに書くとかすればベストだけど、一人増えるだけでも良いかなと。

ヒヤリハットのハインリッヒの法則に近いところはあるかなって思っていて、一件の重要なPRは３００件の"わかんない"からみたいなね。

3

ちょっと別の話にはなるけど、OSSの開発者が十分な報酬を受けていないというのは「まぁそうだよね〜〜」って感じで今の会社の方でもスポンサーするにはしているけど（以下のリンク参照）金額の妥当性みたいなところは難しい

github.com

いろんなOSSにスポンサーしてる時雨堂とかはすごいなって思う

4

ちなみに自分のここ最近のOSS活動は「NixOSをmac book pro(16.1)で動かす」ということをテーマに空き時間にやっているが、去年の冬ぐらいからやっていてあんまり時間を避けていなのはあるが進捗が乏しい

その活動の中で若干反省があって、

とあるドライバのための以下のnixファイルを書いたんだけど、本家の方にPRを送っていなかった。正直自分しか使わないと思っていたのもあるが、完成してから出そうとしていた

github.com

ところが、その後にPRを送った人がいてmergeされていた。

github.com

最終的にこっちの方が良くできているから結果としては問題ないんだが、これは本当に良くなかったなって、もっと行動をちゃんと起こすべきだなって反省している。

5

本当に難しいことはApex Legendsに割いている時間をその活動に日々割くことだ。つまりはモチベーションの維持ということだが。

2021-06-06

実際、競技プログラミングって採用時にどうよ？

私信電信

これは？

私信電信という共著ブログ(?)を友人たちと始めた。

今回「実際、競技プログラミングって採用時にどうよ？」というお題で書く

現状の解説

実際今いる会社ってHRの会社なので、採用側の視点で。

会社の規模はエンジニアが15人ぐらい（全社員で40人中）

採用時のフローは、カジュアル面談→技術面接→社長面接→トライアル（最近はあんまやってない）

ちなみにトライアルは業務委託契約で1~7日ぐらい既存の課題を手伝ってもらう感じで、互いの負担は大きいがミスマッチは防ぐのが目的でやってる（やってた？）

今のところコーディングテストみたいなのは導入してない。

現職であるところの株式会社HERP では全社員で採用に取り組む「スクラム採用」を推していて、エンジニア全員が面接に出たりする。面接も出るけど、最近はカジュアル面談をやることの方が多い。

余談だけど、面談した人の面接は出ないようにしている。以下のような理由。

ジャッジしない体で話を聞いた後にもう一回ジャッジする体で話を聞くのはなんか違う
アニメもそうなんだけど、性格的に2回目はかなり興味が薄れている

そういえば、構造化面接みたいなことは一瞬やろうとしてたけど結局やってなくて、面接の評価が構造化されているわけではないジュニアかシニアみたいな区別は今のところ明確には無くて、業務経験のある「ある程度できる人」を採用する感じになってる気がする

競技プログラミングどう？

競技プログラミング関係なく趣味がエンジニアリングに関係することはかなりプラスよね。土日（平日の夜とかも）の時間の使い方として何かしらやっている人の方が評価されるのはそらまぁ。

競技プログラミングの特性として、コンテストとかへの参加というわかりやすい形で残るのは評価しやすそう。OSSとかに貢献しようとしても土日そのコードを読んでいるだけだと形としてはのこんなかったりするからね。

余談ですが、最近とあるOSSに自分の書いてたコードの上位互換みたいなのがmergeされてて悲しかった（単純にプロジェクトの途中だったのでPRを出していなかった）

これらはあくまでやってるかどうかっていう話なんで、年齢が上がるにつれて可処分時間は減る気がしてて難しい問題ですね、今と比べると大学生のときはめちゃ時間あったので。

とはいえ、転職のために別に趣味でもない競プロやるっていうのはもったいないよね、時間の使い方として。いい会社に入るためにいい大学に入るために勉強するみたいで、つまらん上にけしからんですね。

転職のために、業務委託でやっていた会社のコードをGitHub上にあげちゃうのも、けしからんですね

今後、コーディングテスト（面接）する？

自分はした方がいいと思っている。けど、会社の人材要件定義に合うような問題を作るコストがデカくね？みたいな感じになっててやってない気がする弊社だと、やるとしたらHaskellの型合わせ問題を解くとか特定の言語のサブセットのパーサーを作るとか、フロントエンドだったら簡単なアプリケーションを用意して改造してもらうとかになりそう

既存サービスについて

とはいえ問題を作るのがめんどいので、既存のサービスを使うというのはある。けど、プログラムがほとんどできない人に対しての足切り的な使い方になちゃうんじゃないかな競プロの難しい問題が解ける能力を採用時の評価の上で差をつけれないと思う。

AさんとBさんどっちを取りますか？っていう話になった時に、現状カルチャーフィットの方が重視されてる。

今後応募が増えてきた際に使うことはあるかもしれないけど、必要になるほど応募が来るのか？

採用、募集して〼

careers.herp.co.jp

2021-02-06

CockroachDB壊れちゃった話

概要

社内で使っていたツールのDatabaseに実験用途でCockroachDB(v20.1.3)を使っていた。構成は以下となる。

「AWS EKS1.6上にStatefuleSetで3Podで運用。StorageClassはEBS gp2（kube masterのin treeの中にある実装）のPVでデータを保存」

実はこの構成はそこそこ問題があって、Nodeの入れ替えなどでPodの再配置が起きた際に過去のPVと新しく配置されたPodのAZが一致しないとStatusがPendingになりコンテナが作られない。これはAWSのEBSがAZを跨げないためであるが、 kube1.7以降の環境でVolume Binding Modeを WaitForFirstConsumer にして、CSI Driverがいい感じであればうまく行くという説がある（参照：Storage Classes | Kubernetes）これは、あんまり興味がない点だったので認識が間違っていて嘘の可能性もある。

そんなこんなで、PendingになったPodを動かすためには以下の２通りのオペをする必要がある。

Podを削除して、過去のPVと同じAZに配置されることを祈る
PVかPVCを消すなりして、新しいPodに新しいPVが作られるようにする。

ただ、2のオペレーションをした場合はデータが消えるので、CockroachDBの新規のNodeとしてClusterにJoinすることになる。

経緯

実は詳細な原因が特定できていないので、省かせてもらうがNodeの入れ替え作業中に """いろいろあって"""Clusterが起動しなくなってしまった

以下は現在わかっていること

X日の15:00(JST)ごろに入れ替え作業をして一旦は動いていた

16:00ごろまで以下のログが出始める。

W210126 07:17:43.388615 906 server/node.go:830  [n2,summaries] health alerts detected: {Alerts:[{StoreID:2 Category:METRICS Description:ranges.underreplicated Value:11}]}

上記のWarningが出ている状態でなんらかの原因で再起動がかかり、

server drained and shutdown completed

おそらく正常に終了はしたが、他のPodも以下の状態になってしまう

W210126 07:18:57.177231 201 kv/kvserver/node_liveness.go:488  [n2,liveness-hb] failed node liveness heartbeat: operation "node liveness heartbeat" timed out after 4.5s

17:00(JST)ごろアプリケーションが動いていないことで気づく

エラー内容はこれに近いように感じた。

forum.cockroachlabs.com

色々と修正しようと頑張っている内に以下のエラーを吐くようになった。

W210126 13:32:11.928294 156 kv/kvserver/store.go:1631  [n2,s2,r6/3:/Table/{SystemCon…-11}] could not gossip system config: [NotLeaseHolderError] r6: replica (n2,s2):3 not lease holder; lease holder unknown
W210126 13:32:12.743191 127 kv/kvserver/replica_range_lease.go:554  can't determine lease status due to node liveness error: node not in the liveness table

現在振り返って考えると17:00ごろはなんとかなったかもしれないが、21:00ごろから上のエラーがで始めた時点で厳しい感じがする。（＝よくない操作をした）

データ復旧に関して

CockroachDBは様々な方法でバックアップやデータのdumpができるようになっているが、Clusterが起動している状態でないできない。

上のVersionでは内部のストレージ部分にRocksDBを使っているので（最近のVersionはPebbleになっている）RocksDBと向き合いながら頑張ればデータを復旧できるという説がある。自分の認識では理屈上2Nodeのデータがあればいいはず

今回はデータは捨てる判断にしたが、大事なデータを保存していてバックアップもとっていない人はチャレンジするための資料を置いておく

Goを使ってRocksDBから復旧を試みる

sudonull.com

データ構造に関しては、以下のスライドが参考になる

ccvanishing.hateblo.jp

以下のソースコードのコメントもデータ構造に関してわかるかもしれない

github.com

余談

ちなみにcockroach debug rocksdb でデータを直接操作することができる。

cockroach debug rocksdb scan でK/Vっぽいものを取得できるが、cockroach debug rocksdb get KEY_NAME にscanした結果のkeyを使うことができない。

あまり理解していないが、cockroach debug rocksdb scan は CockroachDBの内部でてくるKey (例：/Local/Store/gossipBootstrap) で、RocksDB側で使われているKeyは別のbinary表現のkeyに変換しているようだ。RocksDBの私が理解していない機能を使っている気がする。

なので、 cockroach debug rocksdb scan と cockroach debug rocksdb scan --hex のvalueを比較することで、同一のkeyを取得することができ、cockroach debug rocksdb get --hex HEX_KEY_NAME でCLIから値を操作することができる。

cockroach debug rocksdb scan はほとんどデータがないはずのDBから数GBのファイルを生成してくるので、地獄みたいな作業になる。

RocksDBの操作はかのブログで雰囲気を察することをお勧めする

www.jianshu.com

2020-10-18

CloudFrontが更新前の証明書を返す

事象

なんか会社のテックブログ的な存在の証明書が切れた？？

.@herp_inc https://t.co/PTPR2HARfi の証明書の有効期限が切れています
— 青木華絵 (@aereal) 2020年10月17日

が、しかし普通に繋がる人もいるようで

f:id:hiroqn:20201018194746p:plain

gyazo.com

しかし私のiPhoneからは繋がらない...

f:id:hiroqn:20201018195343p:plain

上記のブログはCloudFront+S3で構成されているので、AWSの管理コンソールを見に行ったところ、ACMとCFの設定は特に問題はなさそう

どうやら証明書ガチャ（厳密にはCloudFrontのEdgeガチャ）が起きている？？

経緯

確かに、現在の証明書の設定は問題ない、問題はないが実は10/2に証明書の更新に一度失敗している

You have an SSL/TLS certificate from AWS Certificate Manager in your AWS account that expires on Oct 17, 2020 at 12:00:00 UTC. This certificate includes the primary domain herp.co.jp and a total of 2 domains.

で、諸々対応した結果、 10/7に更新された旨の連絡がきて、確かにACM上は更新されていた

This is to notify you that AWS Certificate Manager (ACM) has completed the renewal of an SSL/TLS certificate that certificate includes the primary domain herp.cloud and a total of 2 domains.

対応

これは、CloudFrontの裏側のインスタンスというかエッジロケーション的なSomethingの証明書が更新された場合と更新されていない場合があるぞい、という排中律的な感じがしてきたので裏側をエスパーして対応を考えてみる

まず、Cache Invalidationを /* を対象にやってみる

結果、駄目

次に、同じドメインを対象とした新しいCertificateを作ってCloudFrontの証明書を変えてみる。

結果、会社のメンバーのうち見れてなかった人が「見れるようになった」と報告

う〜ん、直ったんじゃね？

感想

俺たちは悪くないという自信がそこそこあるんですが、AWSさんどうなんでしょう？？？？

これはCFの正常な動作だよ的なことを知っている人がいたら連絡お願いします

2020-09-11

はてなサマーインターン行ってきました

はじめに

まず最初にdisclaimerを書かせてもらうと2015年の話です。この記事はインターンに参加したあと5年の月日が流れた30歳の労働者が書いている。ちょうどはてなインターンが終わって「今から就活だな〜」みたいに考えている人が書いた記事ではない。

なぜ書いたか

事の発端といえば、何の因果か、今ははてなインターンのチームで同じだった id:SWIMATH2 と働いている。

別に急な話ではなくてもう3年以上一緒に働いているのだが、逆に3年働いていると世間話をする機会が出てくる。そこで急に当時のインターンの話になったので過去サイトを見ながらを振り返っていたら、「（インターンの）参加記録を書いてくれると思ってたのに〜」と言われてしまった。

hatenacorp.jp

最初、自分の記事リンクされてね〜〜〜って思ったけどそもそも書いた事実がなかった。疑ってすみませんでした。

そして、懐かしさを感じながら当時のチームメイトのブログを読んだ。

swimath2.hatenablog.com

自信がないからといってはてなインターンに応募しないというのは絶対にやめましょう

結構いいことが書いてあって、普通にいいことが書いてあった。

私は当時に25才だったので少し参加を迷ったりしてはいたんだよなぁ、そういう人間にも参加した方がいいと伝えるためにも今からでも参加記事を書いた方が良いな、という優しい気持ちになった。

　振り返って

振り返ってみるといろんなシーンを断片的ながら結構覚えていた、自分は結構記憶力ある方なんで。ただ、上記のブログを読むとなんか大体書かれてて、当時の自分も書くことないな〜ってなって書かなかったのかもしれない、これはおそらく言い訳だが。

以下インターン良かったことリスト

研修
ペアプロ（これは本当に良いメソッド）
実際のプロダクトへの参加
perlのhash
カマルのカレー
hatena社員の個性(特にid末尾に数字がつく人)

振り返ってみると、やっぱ研修がちゃんとしてるのがすごいんだなぁ。 Perl書いたことがなかったけど、なんだかんだ何とかなる（という気持ちにさせてくれる）というのは研修がよく出来ているということだ。

つまり参加ハードルが実質0なんだよ。あと、5年たっても参加記録を書くというハードルも0だ。

謝辞

当時ののメンターの id:t_kyt id:shiba_yu36に感謝を。

あと過去を含めインターン参加者へ,

時間がたったからと言ってはてなインターン参加記事を書かないのは絶対にやめましょう

そういえば完全に私事だけど印象深いことがあって、当時デパスを飲んでたがなんか覚えてないけどインターン中に飲まなくなった。そのあと今までベンゾジアゼピンは摂取してない。あれは働きながら飲むもんじゃないなって思ったし、今もそう思っている。

これは何？

概要

八百森のエリー 1~5

ブラック・ラグーン（１２）

来世ではちゃんとします 7

クマ撃ちの女

ランウェイで笑って（２２）

違国日記

東京入星管理局

サイバネ飯

読切いろいろ

メイドインアビス（１０）

JKハルは異世界で娼婦になった

Artiste

衛府の七忍

この世界は不完全すぎる（４）

葬送のフリーレン（５）

AV男優はじめました

BEASTARS ２２

抜刀（１）

概要

制約と方向性

フロー

BucketのSSEを有効化

暗号化されていないものを暗号化する

inventory 設定

inventory結果

s3 batch

確認

再掲

1

2

3

4

5

これは？

現状の解説

競技プログラミングどう？

今後、コーディングテスト（面接）する？

既存サービスについて

採用、募集して〼

概要

経緯

データ復旧に関して

余談

事象

経緯

対応

感想

はじめに

なぜ書いたか

振り返って

謝辞

BEASTARS　２２

　振り返って