あんパン

こしあん派

Raspberry Pi Zero WHのGPIO経由でシリアルコンソール起動

自分向けメモ。ピンの配列とかすぐに忘れそうなので。

適当なUSBシリアル変換ケーブルを購入しておく。自分が買ったのはこれ。FTDIとついているものを買いがち。

GND, TX, RXを接続する。TXはRaspberry Pi上のRXに刺すし、RXはRaspberry Pi上のTXに刺す。ピンアサインはGPIO Zeroっていうツールのpinoutコマンドを使うといいぞと公式のドキュメントに書いてある。

www.raspberrypi.com

$ sudo apt install python3-gpiozero

でインストールして

$ pinout

でかっこいい感じに表示してくれる。

さきほどのドキュメントでは

TX (GPIO14); RX (GPIO15) https://www.raspberrypi.com/documentation/computers/os.html#more

と書いてあるので、GPIO14にケーブルのRX, GPIO15にケーブルのTXを刺せばOK。baud rateはデフォルトでは115200なので*1

$ sudo screen /dev/ttyUSB0 115200

で接続できる。ユーザ名とパスワードを入力してログイン。screenを終了したいときはctrl-a + k。

CloudFront FunctionsでカスタムドメインへのHTTPリクエストを自分のdotfilesのリソースにリダイレクトする

タイトルだけだとどういうことか分かりづらいのだけど

$ bash -c "$(curl -fsSL https://dot.masawada.me/install)"

のように1コマンドでdotfilesをインストールしたい。この install ファイル自体もdotfilesに含めたものを利用したい、という話。自分の場合 install ファイルは以下に置いている。

github.com

https://github.com/masawada/dotfiles/blob/main/install のrawファイルは https://raw.githubusercontent.com/masawada/dotfiles/main/install で配信されるので dot.masawada.me/$PATHraw.githubusercontent.com/masawada/dotfiles/main/$PATH にリダイレクトできればいい。これをCloudFront Functionsで実現する。

いくつか方法を考えたところ、カスタムドメインが絡んでいる(証明書を設定できる必要がある)ので、実現方法は以下のいずれかになろうと思う。いずれもCertificate Managerで証明書を取る前提。

  • ALBのListenerでリダイレクトを仕込む
  • API Gateway経由のLambdaでリダイレクトを仕込む
  • CloudFront Functionsでリダイレクトを仕込む(この記事の方法)
    • 亜種としてLambda@Edgeもあるけどあまりに素朴なJavaScriptで済むのでわざわざ採用する理由がない

ALBはやりたいことに対してお金がかかりすぎる。API Gateway + Lambda案も考えたけど /install だけでなく /scripts/os_install みたいなエンドポイントでもリダイレクトしてほしいので、ちまちまマッピングするのはだるそうだなあと思い、CloudFront Functionsで済ませることにした。というか単純にCloudFront Functions使ったことなかったので純粋な興味というのが大きな理由ではある。

ちなみにこれまではCloudFrontのoriginをS3に設定して、S3側でリダイレクトを設定していた。S3にはリダイレクトを仕込む機能があり、これで無理矢理GitHubにリダイレクトすることができる。

docs.aws.amazon.com

CloudFront Functionsがある今はこんな無理矢理なことをしなくても実現できるのでそうする。具体的には以下のような感じでStackとCloudFront Functionsの定義を書く。

gist.github.com

CloudFront Functionsで渡ってくるeventの構造は以下のページに詳細が書いてある。のでこれを読みながらちまちま書いていけば完成する。

docs.aws.amazon.com

CloudFrontなのでoriginは必ず設定する必要があって、ここでは空のS3 bucketをoriginとしている。CloudFront Functionsで全てのリクエストが捻じ曲げられるのでS3に何かを置いても特に意味はない。

あと注意点としては、このStackを初期化する際に渡すCertificate Managerの証明書はus-east-1にある必要がある。CDKは(というかCloudFormationでは)素のままではクロスリージョンで参照を渡すことができないので、証明書もCDKで発行する場合はこのStackもus-east-1で構築する必要がある。

とはいえひととおりをCDKで素朴に組めて結構便利だと思う。

プロフィールページをAstro + GitHub Pagesで作り直した

以前から https://masawada.me で運用していたプロフィールページの配信構成を変更して、ついでにHTMLとCSSの組み立てをAstroに依存するようにした。といっても見た目は極力変えずそのままにしたし、凝ったことはしていない。

左が移行前、右が移行後

github.com

リソースが散逸している旧AWSアカウントから整理された新AWSアカウント群への移行を少しずつ進めていて、その一環。以前はGitHub Pagesに独自ドメインのHTTPS対応がなかったのでCloudFront + S3の構成をとっていた。いまはLet's Encryptで独自ドメインの証明書を勝手にとってくれるので、GitHub Pagesから配信したほうが良いという気持ちになった。

ペライチなのでHTMLもCSSも手打ちで1枚ペロッとあるだけで良くはあったのだけど、もともとejsとかscssとか使って頑張って組み立ててたところからすると後退する感があったのと、いろいろ組み合わせて作ってもしばらく放置すると何がしたかったのか分からなくなるので、何らかのツールを導入しようと考えていた。とりあえず最新にアップグレードすればなんとかなるみたいな状態にしたかった。でもNext.jsは重たすぎるしなあと思っていたところ モダンで早い静的サイトジェネレータ Astro の始め方 - A Memorandum を読んでAstroを知ったので、これを試してみた。しっくりこなくてもどうせ2,3時間で式年遷宮できる規模感なので、えいやっと移行した。

astro.build

AstroはKey Featuresとして Zero JS, by default を推していて、特に凝ったことをしない場合はビルド後のファイルにJSが一切含まれない。またJSXっぽい雰囲気でテンプレートを書ける .astro ファイルに一緒にstyleを書いておくとファイルごとにスコープ化されたりして、おもてなしがある。動きのないペライチのページを作るには丁度良いツールだと思う。

デプロイのドキュメントが充実していて、GitHub PagesにデプロイするGitHub Actionsも公式で用意されている*1

GitHub Pagesはブランチにpushしないとダメだと思っていたけど今年の夏にGitHub Actionsから直接デプロイする機能がbetaで足されて便利になっていた*2。Astro公式のGitHub Actionsもこれに近いことをやっていそう。

結果数時間で作り直しが終わり、ついでにFont Awesomeを最新にしたりWebで配信する画像をwebpするなどができた。PageSpeed Insightsでも満点を取れているので満足感がある。

PageSpeed Insights

ちょっと凝ったことするならNext.jsに行きたくなりそうだけど、そうでなければAstroは便利だと思う。


追記。そういえば .astro って拡張子でシンタックスハイライトされないの嫌だな〜と思ってたけどVimでは vim-astro ってやつを入れるといい感じになったのを書き忘れていた。vim-plugを使っているなら

Plug 'wuelnerdotexe/vim-astro'

でインストールできる。

筋の良い解決方法に辿りつくためには

ということを以前考えていたので、やや加筆しつつここにメモ。

筋の良い解決方法に辿りつくためには

  • 仕様を十分に理解できている
  • 選択肢が十分に洗い出されている
  • それぞれの選択肢について、実現する上での制約が洗い出されている
  • それぞれの選択肢について、メリット/デメリットが十分に洗い出されている

の4状態を辿ればよくて、これができるとあとは決めれば良い状態になる。このフェーズは上から順に辿る必要がある。なぜなら上の状況が変わると下の判断に影響が及ぶため。それぞれが十分に行われていないと大きな手戻りが発生してしまう。

これはタスクの大小問わず、日々の暮らしのうちおおよその課題には適用できると思う。

仕様を十分に理解できている

仕様が与えられたらすぐさまその実現方法を考えようとなってしまいがちだが、まずは立ち止まって仕様を理解することに注力する。以下のようなことを気にかけておくと良い。

  • そもそも仕様に不備はないか?
  • 仕様で実現したいことは別の形で実現できるのではないか?
  • 仕様に書かれている中で曖昧な点(書いた人と認識がズレそうな点)はないか?

次のフェーズで選択肢を列挙するにあたって、全く無意味なものを出すのを防ぐことができる。また、全く無の状態から列挙するのは大変なので、とっかかりを見付けるためにも役立つ。 3つめのフェーズとやることは微妙に被っているけど、おおざっぱに枝刈りする意味でまず最初にやっておけるとよい。

選択肢が十分に洗い出されている

課題の解決方法はひとつとは限らない。いろんなパターンを洗い出して一番良いものを選び取ることで、筋の良い解決方法に辿りつくことができる。ここでパターンを洗い出せていないと次以降のフェーズの検討を進める際に選択肢が増えてしまい、十分な検討がなされていないのでまたこのフェーズに戻ってくることになる。4フェーズの中で一番重要なフェーズといえる。

選択肢といっても亜種を何パターンも出しているのでは、結局どれを取っても変わらないことになりあまり意味がない。できるだけ違う経路で同じ場所に辿りつけないだろうか? を考えたいところ。

十分な選択肢を洗い出す決定的な方法はない。本当に他に実現方法はないか? を常に考えておく癖をつけておくとだんだん身についていく。松竹梅で案を出すのが典型的なやりかただと思う。つまりスコープと工数にグラデーション(松から順に小さくなっていく)をつけた3パターンを出すということ。

自信がなければ、次のフェーズに行く前に誰かにレビューしてもらうのも有効そう。

それぞれの選択肢について、実現する上での制約が洗い出されている

これは1つめのフェーズに似ている。選択肢を挙げたけど実は実現不可能な項目が存在しないか? をいまいちど立ち止まって検討したい。最初は見えてこなかったけどここにきて見えた結果実現不可能と判断できることはよくある。具体的にはこのフェーズで以下のような制約が見えたりする。

  • 工数
  • 予算
  • ステークホルダーの利害
  • 他チームとの兼ね合い
  • 関連会社との兼ね合い

これらは典型的な例として挙げているだけで、実際には他にもいろいろあろう。

それぞれの選択肢について、メリット/デメリットが十分に洗い出されている

選択肢を挙げるフェーズの次に重要なのがこのフェーズ。メリットとデメリットを洗い出せていないと、どれを選べばよいのか判断することができない。大抵の場合トレードオフになることが多いので、基本的には以下のような軸で考えて、必要に応じて軸を増やしたり減らしたりする。

  • 技術的な難易度
  • 影響範囲
  • 既存機能との整合性
  • 横展開可能性
  • 負荷
  • 直近何らかの開発で触ることが分かっている場合、その工数を増大させないか
  • 予算

慣れていないと十分にメリット/デメリットを列挙することもできないので、ここでも誰かにレビューしてもらうと良い。

決めるには

ここまできたらあとは決めるだけ。決めるにはどのメリット/デメリットを重く捉えるべきかの認識が重要になる。評価軸が多い場合は表にして点数をつけると判断をつけやすい。

意思決定者が自分ではない場合はここまでのサマリーをまとめて意思決定者に持っていくことになる。持っていく前に、自分の中でどのメリット/デメリットが重要なのかと、その理由を持っておくと意思決定者の判断に役立つので、何も考えずに持っていくよりはある程度考えてから持っていく方が望ましい。


これらのステップは必ずしも一人でやりきる必要はない。最後に意思決定者に持っていく段になって実は前提が違っていて別の案の方が良いですねとなることも往々にして発生しがちだと思う。タスクの性質に応じて相談のタイミングを調整すると良い。

QNAPのNAS上のデータをAmazon S3 Glacierに同期する

masawada.hatenablog.jp

この記事でも書いた通りQNAPのNASにファイルを置くと定時バッチでAmazon S3にアップロードされ、翌日にはAmazon S3 Glacierに移動されるようになっている。なぜ直接Glacierに投入しないかというと、直接Amazon S3 Glacierを扱うのはやや煩雑で、Amazon S3を通して操作できる状態にする方が楽なため。Amazon S3のbucketにライフサイクルを設定することで自動的にGlacierに移動される状態にできる。

以前は手でぽちぽち設定していたのだけど、最近はAWSアカウントを作り直したりIaCでリソース管理するように整備するなどしていて、この設定もCDK化した。具体的には以下のようなStackを書いた。

gist.github.com

NASに設定する用のIAM userとpolicy(とgroup)はIaCで管理しているがkeyなどは管理しない。CDKで発行することもできるが、まさかCloudFormationのコンソールに表示したくはないし、SecretsManagerに保存するとお金(といっても月数十円くらいだろうけど)がかかるのでケチくさく手動で発行している……

あとはQNAPのNASに入っているHBS 3 Hybrid Backup SyncでS3へのアップロードを設定しておけばOK。特に難しいことはない。