おふとんの中から

その辺に転がってるエンジニアの備忘録

引っ越しした(ほぼ1年前)

ゆいなです。

去年はアドベントカレンダーも書いてなかったので今更ながらのあけましておめでとうございます。今年もよろしくお願いいたします。

すごい今更すぎるんですが、2023年5月頃に引っ越ししました。(愛知→岐阜)
引っ越しした理由は色々とありますが、追々ブログ書くつもりでいます。

もともと住んでいたのは初めての一人暮らしあるあるの1Kのお部屋。
割と1部屋が広めだったのと名古屋へのアクセスも抜群だったので、引っ越しもしなくていいかーとなりまして、 なんだかんだ7年程同じ部屋に住んでました。

ただ、コロナ禍突入でリモートワークと出勤の平行からフルリモートワーク中心になってからは、 生活と仕事のスイッチがし辛いなという悩みもありました。
コロナ禍の中で今の会社に転職からの完全なるフルリモート化したこともありまして、更に悩みが顕在化していました。

引越し先では仕事・作業用の部屋を確保したので、この悩みも解消。
岐阜に来てしまったので、名古屋へのアクセスは悪くなりましが、元々車移動メインだったのであまり関係なし。
住居周りが一面のクソミドリで雨の時期はカエルの鳴き声ゲコゲコ、 夏場は草刈り機のエンジン音が至る所からしてますが、それも個人的には全然OKな環境音なので問題なし。
カエルの鳴き声なんかは元々のアパートでもしてましたし、その中で安眠してたまである。

割と新し目のアパートなので、無料インターネット付き物件でした。
無料インターネットだと速度が出ないとか色々と問題が出ることが多いですが、 中身はフレッツだし、常時200Mbps以上は出るしで特に問題なかったので、そのまま活用することに。

てことで個人的には快適に過ごせてます。

なんやかんやで転居は2回目。

1回目は実家→一人暮らしだったので、家電家具類はすべて一人暮らし先で購入したり、配送してもらったり。
運ぶものはPC関係と服くらいだったので、実家の車を使って引っ越しができました。

今回はすべて手元にある上での引っ越しだったので、初めて引越会社を使って引っ越し。

なんだかんだ荷物多いかなとおもいきや、少ない方だったらしいです。
まあ業者に頼まず、自分の車でタイヤ等の車のパーツ類とかスキー板運んでるのでその部分も入れたら多いかもしれない。

大手にお願いしましたが、自分でほぼほぼ梱包しましたし、引っ越しの金額もだいぶ安く済みました。

ってことで引っ越しして岐阜にいますよというご報告でした。

AT限定を解除した

ゆいなです。

ブログちゃんと書いていこうと言いつつ色々プライベートも忙しくてネタが溜まっており・・・
ぼちぼち記事書いていこうと思います。

ということで今回は車のAT限定の解除をした話を書いていこうかと

なぜAT限定解除したの?

諸事情により、MT車を動かせるようにしておく必要が出てきたのが理由。
正直周りにMT車乗りが多くて、ちょっと憧れてたりはあります。

どんな感じで限定解除するん?

限定解除をするには2つの方法が。

  • AT限定解除の講習を行っている自動車学校で講習を受けて検定に合格する
  • 運転免許試験場の技能審査を直接受ける

今回私は自動車学校に通って限定解除する方法を取りました。

自動車学校に通う場合は最短4回の教習と卒業検定の合格が必要です。

教習どうだった?

そもそも教習通う上で不安がいくつかありました。

  • クラッチ操作自体の不安
  • 教習所のお作法全然思いだせなくて不安
  • そもそも4回で卒業検定に辿り着けるかの不安

抱えた状態のまま実車の教習に。

教習で利用した車はデミオセダンの教習車。 どうやら日本国内では教習車専用だそうな。
https://kuruma-news.jp/post/142960

教習車の時点で6速MTでびっくりした。5MTかと思ってた・・・

教習の最後の方まで半クラの感覚がなかなか掴めず、毎回のようにエンストを繰り返してました・・・
S字クランクは初回から全然問題なし。最初の免許取ったときもノリと勢いでずっとノーミスだったのであまり心配はしてなかった。
坂道発進が一番の鬼門と言われていたけれど、ミスったのは教習中1回だけだったかも。

いろいろと不安はあれど、なんとか4回教習と卒業検定一発合格という結果に。

卒業検定は本来3速までつかうのだけど、裏技的に2速までで誤魔化しました

最後の最後まで断続クラッチとシフトダウンがとても苦手な状態で進んでしまったのはあり、 今後MT車乗れるときに練習しないとなーという感じ。

自分の車MT車に乗り換える予定はないので、なかなか練習する機会はなさそう・・・

はてなブログをgithub管理できるらしいので試してみた

ゆいなです。

年明け早々、冬休みの課題的に行ったことの話を。

githubでCodespacesという機能がリリースされて話題になったのは記憶に新しいかと思います。
https://github.com/features/codespaces

IDEも使えるようになり、クラウド環境のみでの開発というのも現実的になってきました。

VSCodeが使えることがポイントとなり、ブログの投稿から記事管理までをgithubでもできるように環境を構築してみました。

これまでのブログ管理

私の場合は、VSCodeを利用してMarkdownで記載し、Googleドライブに下書き記事を保管。
投稿前にGoogleドライブから記事をコピペしていました。 あまりはてな側で直接記事を書いていない感じです。

この方法の場合、投稿した記事のログは残せますが、Googleドライブにアクセスする手間もあり面倒に・・・

結果ブログ更新をサボる人になっていた

これからのブログ管理

githubリポジトリにプログ記事を保存。
記事を書く時は、codeSpaceからVSCodeを開き、テンプレートを使ってブログ記事を書く。
書き終わったらPRを作成し、mainブランチにマージすればブログの下書き投稿まで行えるように。

下書き投稿まで行ったら後ははてなのページに行き、予約投稿設定をするだけです。

もしはてなブログ側で記事を修正した場合も修正が1日1回Githubリポジトリ反映されるように設定しています。

この仕組みを実現するため、以下を利用させていただいています。 https://github.com/yammerjp/gimonfu

これでブラウザさえあればブログ記事を書け、投稿までが行えるようになりました。

今年はもっとブログ書いていけるようにしたいなぁ。

GolangのGenericsがやっぱり便利だった話

ゆいなです。

この記事はGo Advent Calendar 2022の25日目の記事です。

UtilityFunction系がGenericsの登場によりだいぶスッキリしたことに感動したので、Genericsのおさらいも含めて書いていこうかなと思います。

GoのGenericsとは

go1.18(2022/3/18)にリリースされた機能。

Genrics自体は、引数の型の情報を引数として渡すなどを行い、あらかじめ特定のデータ型に決め打ちせずに処理内容を記述することができるものです。

まだGoのgenericsは他の言語に比べてそこまで自由度は高くないです。
そのため今回のケースは主にキャストを減らす目的で利用しています。

キャストを減らす目的の利用

これまでUtilityとして型キャスト類をすべてfunctionとして型ごとに定義して利用していました。

func GenPtrBool(b bool) *bool {
    return &b
}

func GenPtrString(s string) *string {
    return &s
}

func GenPtrInt64(i int64) *int64 {
    return &i
}

こちらを以下の書き方で1つに纏められるようになりました。

func GenPtr[T any](v T) *T {
    return &v
}

これだけでもだいぶすっきり。

配列をユニークな値にするような処理もGenericsを使うことで型ごとに定義する必要がなくなり、コード自体の見通しがよくなりますね。

1.18から使えるようになったGenericsを利用して皆様どんどんコードの見通しを良くしていきましょ。

AWS SES+SNSによるNotification受け取りをGolangで実装する

ゆいなです。

この記事はGo Advent Calendar 202120日目の記事です。

AWS SES+SNSによるNotificationの受け取りをGolangで実装する機会があったのですが、日本語で解説がある記事がなかったので、あとの人のために残しておこうと思います。

そもそもなんでこの組み合わせなの?

AWS SES+SNSによるNotificationの受け取りは主にメールのバウンス管理で使われます。
今でこそ、AccountレベルのsupressionListがありますが、以前はそれすらもなく全てSESを使うユーザーが実装する必要がありました。

SES+SNSは最小構成でバウンス管理を実装するための仕組みになります。

今回はSNSから特定のエンドポイントへ通知を送信し、エンドポイント側が何かしらに使える状態に持っていくところまでをやっていきます。

で、どうやったの?

AWS設定周り

基本的にはSESからメールバウンスや苦情のリクエストをSNSに流すのは、画面ポチポチで設定可能です。
今回はNotification受け取りに絞るため、設定に関する説明はAWSのマニュアルに任せましょう。
https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/configure-sns-notifications.html

SNSからエンドポイントに送信するのもSNSサブスクリプションをごにょごにょすればすぐに作成できますが、エンドポイントを実装するまでは待ちましょう・・・。

エンドポイント実装

今回のメインはエンドポイント側の実装です。

エンドポイントに何が入っているかについては以下のAWSの記述を見ると大体書いてあります。
https://docs.aws.amazon.com/ja_jp/sns/latest/dg/sns-http-https-endpoint-as-subscriber.html

今回controllerはAWSで提示されているリクエストを受け取れるように実装します。

また、SNSからの初回のsubscribeリクエストも同様のリクエストでくるため、こちらも処理する必要があります。

SNSからの通知の場合、単純にリクエストを受け取って処理してしまうだけではNGです。
メッセージが本当にAWSから送信されてきたものなのかを確認する必要があります。
MessageにはSignatureがついているので、署名が正しいことを確認してから処理をする必要があります。 署名検証については後述。

最終的にNotificationを受け取った後はMessageの中身を再度unmarshalして、必要な値を取得して開ければ問題ないはずです。
Messageの内容の定義についてもAWSのドキュメントにあるため、参照すれば大丈夫。
https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/notification-contents.html

署名検証

署名検証についても検証方法のドキュメントは提供されています。
https://docs.aws.amazon.com/ja_jp/sns/latest/dg/sns-verify-signature-of-message.html

一部の言語のSDKでは検証するメソッドが提供されているようですが、GolangAWS SDKでは提供されていません。
また、AWSGolangSDKでは提供する予定がないようです。
有志で作成されたヘルパー等はありますが、多くは使われていないですしそのままコード化できそうです。

ということでAWSから提示された検証方法をそのままコードに落としました。

SNSNotificationPayloadにunmarshialしている前提のコードですが、ほぼAWSから案内されている検証方法通りです。
追加でバリデーションは入れていますが、URLが正しいか等の検証になります。

おわりに

今回はいつものブログ以上に超真面目な記事になりましたが、普段はちゃらんぽらんなのでそんなに真面目な人だと思うでないぞ・・・?