わたねこコーリング

野良プログラマ発、日々のアウトプット

Nuxt で Vuetify のロケールを設定する

自分プロジェクトで Nuxt いじりするのが楽しい連休二日目です。という訳で表題どおり、Nuxt.js プロジェクトで U/I に Vuetify を選択した時、ロケールを指定して日本語化する設定という小ネタです。nuxt.config.js に言語ファイルの import とロケール設定を追記すれば良さげ。以下、追記後の git diff です。

$ git diff nuxt.config.js 
diff --git a/nuxt.config.js b/nuxt.config.js
index e21aabd..f74933b 100644
--- a/nuxt.config.js
+++ b/nuxt.config.js
@@ -1,4 +1,5 @@
 import colors from 'vuetify/es5/util/colors'
+import ja from 'vuetify/es5/locale/ja'
 
 export default {
   srcDir: "./client/",
@@ -54,6 +55,10 @@ export default {
 
   // Vuetify module configuration (https://go.nuxtjs.dev/config-vuetify)
   vuetify: {
+    lang: {
+      locales: { ja },
+      current: 'ja',
+    },
     customVariables: ['~/assets/variables.scss'],
     theme: {
       dark: true,

2021年上半期 プライムビデオで観た音楽系コンテンツ

ここ5年ほど週末の夜は安ワイン片手にプライムビデオという、ネイティブ・ウィズコロナな Mariyudu です。おつまみはロルフのベビーチーズが美味いでし。

さて、映画は全然詳しくないのですが、音楽成分多めだと何やら一家言めいたことが書けそうなので、今年1〜6月に観た音楽モノを備忘録的に書き留めておきます。ネタバレとかを気にしない大雑把な性格なので、その辺にナイーブな方はご注意を。

バンドスラム

青春映画としては直球じゃないけど、ミニシアター系と括るにはオープンで小難しくない。主人公がバンドメンバーじゃなくてマネージャー兼プロデューサーってヒネリがイイですね。ハッピーになれます。

ジャージー・ボーイズ(字幕版)

「君の瞳に恋してる」のオリジネイター、フランキー・ヴァリフォー・シーズンズの伝記映画。成功者の例に漏れず、米芸能界という超モンスターなスターシステムに引き裂かれていく様がやるせないです。監督はクリント・イーストウッドなのですな。

ジャージー・ボーイズ(字幕版)

ジャージー・ボーイズ(字幕版)

  • ジョン・ロイド・ヤング
Amazon

グレン・ミラー物語(字幕版)

なにせ'54年作なので寝てしまうかもと思ってたけど、昨今の作品のように凝った展開がある訳でも無いのに普通に楽しめました。戦前〜戦後という時代背景の濃さ故ですかねー。プライムのラインナップには古い映画も多いのだけど、音楽モノが意外に多いという発見も。

グレイトフル・デッドの長く奇妙な旅 [全6話]

自分には長い間、気にはなるけどのめり込むことが出来ないビミョーな位置にいるバンド、グレイトフル・デッド。そんな彼らのドキュメンタリーを観て、バンドの成り立ちや経過、デッドヘッズ達との関係等については理解が深まった気がするけど、デッドをさらに好きになる・なろうという気持ちはやっぱり起こらなかったです。やっぱりこのバンドは不思議だ…

ロケットマン (字幕版)

当初、エルトンの代表作「君の歌は〜」をそれ程良い曲だとは思ってなかったのだけど、後年にデビュー作から通して聴いた後でようやく文脈が腑に落ちたことを思い出します。という訳で複雑この上ないパーソナリティとバックボーンを背負った孤高のポップスターの半生を描いた作品なのですが、ミュージカル仕立てもそれほど濃くはなく、観やすかったです。期待していたジョン・レノンとのコラボに関しては言及なし。普通なら死後に明かされるようなスキャンダラスなあれこれが、本人生存中の大放出。やっぱり凄いスターですわ。

ニューオリンズ(字幕版)

WWI 真っ盛りな1917年、ニューオーリンズを舞台にしたジャズと恋のお話。サッチモビリー・ホリデイの出演で有名な'47年の作品ですが、今回初めて観ますた。この年はジャズのレコードが初めてリリースされた年だそうで、劇中には「ジャズ」の語源誕生のシーンも。奏でられる音は原初のディキシーランドジャズにしては洗練されすぎな気もしますが、ヤボは言いっこ無しと自分に言い聞かせながら楽しんだ90分でした。

ニューオリンズ(字幕版)

ニューオリンズ(字幕版)

  • ルイ・ア-ムストロング
Amazon

ましろのおと [全12話]

二十歳過ぎの頃に初代高橋竹山のレコを買って以来、津軽三味線は好きなジャンルです(郷里が青森県だし)。なので、わりと期待して観始めたけど、けど、けど、うーむ… 要するにこういうノリというかリズムを楽しむには老いすぎたってことでしょうな。太棹の歴史や薀蓄がもっとたくさん盛り込んであったらおっさんでもイケたかも。ちなみに原作漫画は読んでません。

【AWS CLI】ELB ターゲットグループの EC2 インスタンス一覧をワンライナーで表示する

数十程の EC2 インスタンス群をロードバランサ(ALB)経由でサービス提供しているのですが、インスタンス管理で「あれ? このサーバってどのサービスで使ってたんだっけ…」ってなった時に、コンソールからロードバランサのターゲットグループをひとつずつ確認するのは大変なので、AWS CLI, jq, bash を組み合わせて [ <ターゲットグループ名>, <インスタンスID>, <ポート番号> ] という構造のタブ区切りデータを出力してみた、ていう小ネタでつ。(註 : AWS-CLIJSON 形式出力設定になっている前提です)

パイプ連結が結構長いので、ひとつずつ順を追って。まず、アカウント内の ELB ターゲットグループの一覧は describe-target-groups で得られるので、jq でフィルタリングして [ <ターゲットグループ名>, ターゲットグループARN> ] という構造のタブ区切りデータに変換するにはこんな感じ。

aws elbv2 describe-target-groups | \
jq -r '.TargetGroups[] | [.TargetGroupName, .TargetGroupArn] | @tsv'

次に、指定ターゲットグループに紐付いている EC2 インスタンスを列挙するには describe-target-health というターゲット毎のヘルスステータス表示コマンドでできそう。これを jq でフィルタリングして [ <ターゲットID>, <ポート番号> ] という構造のタブ区切りデータに変換するにはこんな感じ。

aws elbv2 describe-target-health --target-group-arn <ターゲットグループARN> | \
jq -r '.TargetHealthDescriptions[] | [.Target.Id, .Target.Port] | @tsv'

以上を組み合わせて、 [ <ターゲットグループ名>, <インスタンスID>, <ポート番号> ] という構造のタブ区切りデータを出力するようにしたのが、これ↓。シェルの箇所は読みやすいように複数行化してます。

aws elbv2 describe-target-groups | \
jq -r '.TargetGroups[] | [.TargetGroupName, .TargetGroupArn] | @tsv' | \
while read NAME ARN
do
  aws elbv2 describe-target-health --target-group-arn $ARN | \
  jq -r '.TargetHealthDescriptions[] | ["'"$NAME"'", .Target.Id, .Target.Port] | @tsv'
done

文字通りのワンライナーなら、こう↓(長っ

aws elbv2 describe-target-groups | jq -r '.TargetGroups[] | [.TargetGroupName, .TargetGroupArn] | @tsv' | while read NAME ARN; do aws elbv2 describe-target-health --target-group-arn $ARN | jq -r '.TargetHealthDescriptions[] | ["'"$NAME"'", .Target.Id, .Target.Port] | @tsv' ; done

最後に grep に繋げてインスタンスIDでフィルタをかければ、どのターゲットグループで使われているのか一発です。イエーイ。

Chrome 拡張機能 ModHeader で HTTP ヘッダを自在に書き換える

ウェブ開発も最近は Node.js 一辺倒になってしまった在宅野良ブログラマ Mariyudu です。プログラム内で URL のオリジンを参照してごにょごにょしたりすることがたまにあるんですが、curl -H "Host: my-web-develop.net" http://localhost:3000/ 的なことを Chrome にさせたいと思ったら意外に情報が無かったので、今回使ってみた ModHeader の話を。

ModHeader は HTTP ヘッダの内容を操作する Chrome 拡張機能です。つまり、上記ユースケースのように http://localhost:3000/ へのリクエストの際に任意の値をセットした Host ヘッダを付与できるということです。以下、今回行った手順です。

  1. Chrome ウェブストアから ModHeader をインストール。
  2. デフォルトだと他のウィンドウ・タブでも Host ヘッダが書き換えられてしまい嬉しくないので、設定から「サイトへのアクセス」を「クリックされた場合のみ」にしておく。>
    f:id:mariyudu:20210409154149p:plain
    ModHeader 設定
  3. URL バーの ModHeader アイコンをクリックして、本ユースケース用のプロファイルを作成。といっても下図のようにプロファイル名とリクエストヘッダの Host をセットしておくだけ。>
    f:id:mariyudu:20210409160632p:plain
    プロファイル作成
  4. 開発中のウェブプログラムを起動しておいて、Chrome にて新しいウィンドウ(またはタブ)を開いて、URL に http://localhost:3000/ を入力してアクセスします。この時点では未だ Host ヘッダ設定は効いていません。
  5. そのウィンドウで、URL バーの ModHeader アイコンをクリックするとページをリロードしちゃいなよユー、って言っているので言う通りにすると、設定した Host ヘッダが適用されるようになります。それ以降はそのウィンドウからのアクセスでは、Host ヘッダ書き換えが適用され続けます。>
    f:id:mariyudu:20210409154334p:plain
    プロファイルを適用させる

便利です。これで Vue.js や Express でのローカル開発はもちろん、リモートホスト開発での hosts を書き換えてテストしてたような案件もラクラクだにゃー。

Amplify プログラムで、Storage (S3) に保存したファイルを複製する

AWS Amplify 上でウェブアプリ(Vue.js 製)を開発しているのですが、バックエンドの Storage API を使って S3 に保存したファイルを複製しようとして、「あれ? StorageClass にゃコピー用メソッド無いねぇ。どうするん?」ってなった時の話です。

結果、別途 aws-sdk の S3 クライアント使えってことらしいです(当たり前か)。本件ユースケースは、マルチユーザ型(Cognito で認証・認可管理)のフォトアルバムサービスのようなサービスの開発をイメージして頂ければわかり易いかと。なので、Auth API で得たクレデンシャルを S3 クライアント生成時に与えてやるのがミソですな。Vue.js の単一ファイルコンポーネント内で処理を行う場合は、こんな感じです。

<script>
import aws_exports from '@/aws-exports'
import { Auth } from "aws-amplify"
import AWS from 'aws-sdk'

export default {
(中略)
  methods: {
    // S3 上のファイル src を dst にコピーする
    duplicateS3File: async function (src, dst) {
      try {
        const credentials = await Auth.currentUserCredentials();
        const s3 = new AWS.S3({
          apiVersion: '2006-03-01',
          region: 'ap-northeast-1',
          accessKeyId: credentials['accessKeyId'],
          secretAccessKey: credentials['secretAccessKey'],
          sessionToken: credentials['sessionToken']
        })
        const params = {
          CopySource: `${aws_exports.aws_user_files_s3_bucket}/public/${src}`,
          Bucket: aws_exports.aws_user_files_s3_bucket,
          Key: `public/${dst}`
        }
        await s3.copyObject(params).promise()
        return true
      }
      catch (error) {
        return false
      }
    },
(後略)
  }
}
</script>

S3.copyObject() のパラメタは何だか分かりづらいですが、これは以前 PHP プログラムで同様のことをやって経験済みだったので悩まずに済みました。

【Spotify】 Covers of "Crystal Silence" by Chick Corea on Acoustic Guitar

ジャズの巨星、チック・コリア氏が去る2月9日に79歳で亡くなったとのこと。私の年齢では、フュージョン・ブームの頃に「リターン・トゥ・フォーエヴァー」あたりの名盤から入り、追ってマイルス・バンド時代を追体験したり、というコースでした。

アコギ好きとしては、ラリー・コリエルを始めとした多くの名ギタリストがカバーしている「スペイン」が直ぐに思い浮かぶのですが、ふと上記「リターン〜」収録の名曲「クリスタル・サイレンス」もアコギに合いそうなのに、カバーは聴いたことが無いなぁ、と。そう思いながら Spotify で探してみたら、それなりの数があったのでプレイリストに集めてみました。

デヴィッド・グリスマン&マーティン・テイラーのデュオ以外は初めて聞く名前のプレイヤーばかり。多くの名曲・名演を残してくれただけでなく、こんなふうに未知の音楽に出会えるきっかけまでもらっちゃって、ありがとう、チック・コリア。どうか安らかに。

EC2 で WordPress サイト立ち上げるなら Bitnami AMI が手っ取り早い

仕事で「ウェブサイトをいっこ作るのでサーバセットアップよろ〜、WordPress 付きで」な流れになり、「WordPress すか… そろそろ SSG にしません?」等と言いたいのをぐっと飲み込んで、AWS コンソールにログイン。従来は「チュートリアル: Amazon Linux による WordPress ブログのホスティング」 あたりの手順に従って、手作業でいちからインストールや設定を行ってたのですが、Btinami 提供の WordPress 入り AMI が無料で使えることを知ったので、それを試してみることにしました。結果、とても使い勝手が良く、作業時間を大幅に短縮できました。

手順は Btinami サイトの「Get Started With Bitnami AMIs From The AWS Console」で説明されていますが、現状と食い違う箇所も少しあったので、当方で行った作業手順を備忘録的に記しておきます。

まず、予め AWS コンソールにログインしてから(もちろん EC2 でインスタンス生成できる権限のユーザで)、Btinami サイトにある各リージョン毎の AMI 一覧にアクセス。

f:id:mariyudu:20201212140644p:plain

ここから、アジアパシフィック(東京)の AMI ID をクリックすると、EC2 コンソールのインスタンス生成ページに遷移するので、あとは普段のようにインスタンス生成を行います。後でリモートログインして細かい設定等したい人は、セキュリティグループ設定で ssh ポートのインバウンドを忘れずに。

インスタンス起動が完了したら、ブラウザで http://<このインスタンスのパブリックIP>/ にアクセスして、WordPress 画面が表示されるのを確認。

f:id:mariyudu:20201212140822p:plain

ん? なんか Btinami の説明ページと違う画面だけどまいっか(ランダムに違うテーマが適用されるんですかね?) さらに http://<このインスタンスのパブリックIP>/wp-admin アクセスで、WordPress 管理画面が表示されるのも確認。

f:id:mariyudu:20201212140941p:plain

管理画面でログインするには、インスタンス起動時のシステムログからアカウント情報を得る必要があります。EC2 コンソールにて当該インスタンスについて、アクション > モニタリングとトラブルシューティング > システムログを取得 と進んで末尾付近にある下図のような箇所を探します。

f:id:mariyudu:20201212141414p:plain

ここで明示されているユーザ名とパスワード(上図だとユーザ名:user, パスワード:n********4)で、管理画面からログインできるのを確認します。

さて、WordPress の設定はサイト運営者の仕事なのでここまでにしておいて、カスタマイズ時に PHP ファイル等の書き換えや転送が出来るよう、ssh 周りの確認を。インスタンス生成時に指定したキーペアを使って、ssh ログインできるのを確認。ユーザ名は bitnami 固定です。

$ ssh -i my-keypair.pem bitnami@xxx.xxx.xxx.xxx
(中略)
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
       ___ _ _                   _
      | _ |_) |_ _ _  __ _ _ __ (_)
      | _ \ |  _| ' \/ _` | '  \| |
      |___/_|\__|_|_|\__,_|_|_|_|_|
  
  *** Welcome to the Bitnami WordPress 5.6-0                       ***
  *** Documentation:  https://docs.bitnami.com/aws/apps/wordpress/ ***
  ***                 https://docs.bitnami.com/aws/                ***
  *** Bitnami Forums: https://community.bitnami.com/               ***
(後略)

ログインできました。ストレージのサイズはデフォルトの10GBで十分だったみたい。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
(中略)
/dev/xvda1      9.7G  2.9G  6.4G  32% /
(後略)

ホームディレクトリはこんな構成。

$ ls -l
total 4
lrwxrwxrwx 1 bitnami bitnami  17 Dec 10 14:16 apps -> /opt/bitnami/apps
-r-------- 1 bitnami bitnami 424 Dec 12 03:35 bitnami_credentials
lrwxrwxrwx 1 bitnami bitnami  27 Dec 10 14:16 htdocs -> /opt/bitnami/apache2/htdocs
lrwxrwxrwx 1 bitnami bitnami  12 Dec 10 14:16 stack -> /opt/bitnami

WordPress カスタマイズ時には ~/apps/wordpress/htdocs/ 以下をいじれば良さそう。

$ ls -l apps/wordpress/htdocs/
total 220
-rw-rw-r--  1 bitnami daemon   405 Feb  6  2020 index.php
-rw-rw-r--  1 bitnami daemon 19915 Feb 12  2020 license.txt
-rw-rw-r--  1 bitnami daemon  7278 Jun 26 13:58 readme.html
-rw-rw-r--  1 bitnami daemon  7101 Jul 28 17:20 wp-activate.php
drwxrwxr-x  9 bitnami daemon  4096 Dec 10 14:14 wp-admin
-rw-rw-r--  1 bitnami daemon   351 Feb  6  2020 wp-blog-header.php
-rw-rw-r--  1 bitnami daemon  2328 Oct  8 21:15 wp-comments-post.php
-rw-r-----  1 bitnami daemon  4268 Dec 12 03:34 wp-config.php
(後略)

~/apps/ に phpmyadmin というディレクトリがあったので、調べたら(↓) phpMyAdmin も ready-to-use で、ポートフォワード経由でちゃんと使えました。すごいなぁ。DB アカウントは wp-config.php を参照。

docs.bitnami.com

そんな訳で、WordPress サイトを30分程で用意することができました。今回は調査に時間を費やしたので、次回からは10分以内でできちゃうかと。こうまで便利だと他のアプリコンテナ版も試してみたくなりますな。

尚、AWS には Lightsail という、この手順以上に簡単に WordPress サイトを作れるサービスがあるのですが、ネットワーキングまわりで既存リソース(ELB とか)を共有する等の小回りが効かない部分があり、「さてどうしようか…」と調べていて、この AMI を見つけたことも付記しておきます。