わたねこコーリング

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

CDN 版 Vue3 で問い合わせフォームのサンプル作った

先月書いた「petite-vue で問い合わせフォームを試作してみた」の外部仕様を流用して、Vue.js 3.4 (CDN 版)でも同じことをやってみたです。

Vue.js って、Options API で書くぶんには Vue CLI ベースでも CDN 版でもプログラムコードに大して違いは無いのですが、Composition API だとビミョーに違う書き方を要求されます。前回も書いたように個人的事情として、Vue CLI でガッツリ SPA を書くというよりは、既存サイト(往々にしてレガシー)の一部だけ U/I リッチなページを追加するというような泥臭い案件が多いので、所謂「ちょい足し」な Vue.js 開発時に「ここどう書くんだっけ?」と調べ直したりしなくて済むように、ボイラープレート的なものを身近を置いといたほうがイイな、と思った次第です。こちらからお試し頂けます。こんな U/I です。

「ちょい足し」と言っても、少し作り込むとコンポーネント分割したくなるので、それを想定したファイル構造になっています。テンプレートをバッククオートリテラルで JS コードと一体化させて SFC っぽくしてますが、CSS はどうにもならないのが「ちょい辛」ですね。何か裏技でも無いもんでしょうか。あと、CDN 版だと defineModel() が使えないらしく、v-model なコンポーネントを書くときにコードが煩雑になってしまうのもちょい辛でした。

コード一式は Github に置いてあります。

github.com

「THE BEST OF NON STANDARD」プレイリスト、作りました

先だって Spotify を散策していたら、'80年代に愛聴していた「ノン・スタンダード」レーベルのカタログがここ数年でリマスターされて出揃っているのを知りました。

当時は電子楽器の急速な進歩と低価格化が著しく、少し足を突っ込んでいた自分にもエキサイティングな時代でした。YMO 「散解」後の細野晴臣さんがプロデュースを仕切った「ノン・スタンダード」レーベルの作品の数々は、そんなシーンの船頭役のような存在で、少なからず自分にとって音作りの指針になっていたかと。レーベルの詳細については下記を参照して下さい。

ja.wikipedia.org

1985年に、このレーベルの中間発表のような感じでリリースされたコンピレーション「THE BEST OF NON STANDARD」は、レーベルの指向性がよく分かる一枚で、ヘビロテで聴いていたのですが、Spotify には無いようなので、それぞれのアルバムからトラックを集めてプレイリストに再構成してみました。

以下、このアルバムに収録されたアーティスト達についてちょっとだけコメントを(アルバムタイトルのリンクは Amazon 商品へのアフィリエイトリンクです)。

  • 細野晴臣 - レーベルの主要人物でありながら自分名義のアルバムは「S・F・X」と「銀河鉄道の夜(同名アニメ映画のサウンドトラック)」だけですが、御本人のアーティスト性は同時並行で進められていた「モナド」で爆裂しています。この時代の細野さんの仕事量、マジパねえっす。
  • WORLD STANDARD - 鈴木惣一朗さん主催の無国籍志向なユニットで、アコースティックの比重が大きいのにも関わらず、このレーベルのカラーを代表するようなサウンドだったと思います。
  • Shi-Shonen - '84年のリアルフィッシュ「天国一の大きなバンド」がそりゃあもう大好きで、その中心人物の戸田誠司・福原まりさんが別ユニットやるって聞いたら無関心でいられる訳ないですやん。'86年の「2001年の恋人達」は捨て曲無しのマイ超名盤なので、ぜひ聴いてもらいたいです。
  • Urban Dance - 成田忍が在籍したグループで、レーベルで最も尖った立ち位置を担ってたのでは。個人的にはちょっとアグレッシブすぎて苦手だったですケド。後期には Boowy っぽいサウンドに収斂してしまってたりってのが、方向性の落とし前というか行き先として興味深いです。
  • コシミハル - シューベルト等を取り上げたコンセプチュアルなアルバム「ボーイ・ソプラノ」ですが、Tr-2 で細野さんが名曲を提供していたりして、何げに捨て置けないです。
  • Mikado - キッチュでキュートなフランスの男女ユニット。時代にフィットしていたぶん風化も早かったですが、今は三回りくらいして逆に新鮮かも。
  • ピチカートV - このグループによる「What's new, pissicato?」だけ Spotify に音源が無くてプレイリストに収録できませんでした。やっぱりボーカルが野宮真貴に替ってからのブレイクが印象的な彼らですが、佐々木麻美子のノン・スタンダード時代が自分は大好きで、アルバム「Pizzicatomania!」収録の「From Party To Party」は今聴いてもキュン死です。この頃は「テクノ・フォーク」というキャッチフレーズでプロモートされてた気が。実際、S&G「59番街橋の歌」なんてカバーしてますしね。非公式ですけど、ここで聴かれます。

www.youtube.com

petite-vue で問い合わせフォームを試作してみた

petite-vue

Vue.js のサブプロジェクトで petite-vue ってのを見つけたので、使ってみたという話です。

github.com

petite-vue は README にあるとおり、Vue.js のサブセット的な小規模実装で、プログラムサイズはわずか 6KByte 程です。小型軽量なリアクティブ系 F/W では Alpine.js が有名ですが、その 1/7 程度ということになります。当方事情として既存ウェブサイトにフォームページを追加するような小規模開発案件がよくあるので、そんな時のフロントエンド用途に向いているのではと思い、試してみることにしました。

という訳でお題は、企業や団体のウェブサイトに必ずある類型的な問い合わせフォームのフロントエンドサンプルです。以下のような、極力シンプルな仕様とします。

  • フォーム→確認表示→送信結果、という表示遷移。
  • フォームでは、「個人情報の取扱いに同意する」をチェックしないと確認表示に進めないようにする。また、全項目を必須入力項目として扱う。
  • 確認表示ではフォーム項目の入力漏れだけをチェック。入力漏れがあるとフォーム送信に進めないようにする。
  • 送信結果に遷移すると同時に、フロントエンドから API にフォーム入力内容を送信して受付チケット番号を受け取り、これをメッセージ表示する。
  • API プログラムは、受信したフォーム入力データは保存処理等は行わずに読み捨て、数秒間スリープしてからチケット番号をレスポンスするだけのダミープログラム(PHP)で OK。
  • ページデザインは Tailwind CSS を使用。

以上を実装してみたのがこれ↓。

labo.mariyudu.net

ビジネスロジックは Global State Management (@vue/reactivity)に集約し、画面やパーツもウザくならない程度にコンポーネント分割してみました。

使ってみて気になったのは、

  • コンポーネントの親子間通信が用意されていないので、ストアに直アクセスする等、どうしても密結合な実装になりがち。本例では、コンポーネントのパラメータにイベント処理のコールバック関数を指定することで、無理やり v-model っぽいインターフェースにしてますw
  • コンポーネント単位でファイル分割(所謂 SFC)が出来ないので、コードが増えると見通しが悪くなる。

くらいですかね。ただ、これが気になるようなら素直に Vue.js を使い、petite-vue は小規模かつ使い捨てなプロダクトに限定して使うと割り切れば、気にする程でも無いかもしれません。総合的には結構イケるのではないかと思いました。コード一式は Github に置いてあります。

github.com

【2024.3.1 追記】コンポーネント$template には <template> の id 以外にもバッククオート括りでテンプレートリテラルが指定できることが判ったので、JS コードとテンプレートを合体させて、SFC 的にファイルをコンポーネント単位で分割しました。

2023年第4四半期 プライムビデオで観た音楽系コンテンツ

2024年は元旦から大変なことになってしまいましたが、いかがお過ごしでしょうか。わたねこも例年通り昨年最終四半期に観たアマプラ音楽系コンテンツのログでスタートです。ネタバレ御免と頭を下げつつ、今年も良い年になればと。

ブライアン・ウィルソン/約束の旅路 (字幕版)

元 Rolling Stone 編集者による密着インタビューが中心のドキュメンタリー。ずっと精神疾患を患っていた(る?)ブライアンですが、張り付いたような表情で誰とも目も合わせようしない年老いた彼の映像は見ていて辛いし、'80年代以降の不遇なプライベートにフォーカスした箇所は尚更。ゲスト出演スプリングスティーンの「辛い人生を送ってきた人は幸せになるべきだ」という発言に禿同。もっと'60年代の BB5 映像の割合を増やして欲しかったです。

モダンライフ・イズ・ラビッシュ〜ロンドンの泣き虫ギタリスト(字幕版)

レコ屋で出会ったティーンのバンドマンと JD の、十年間の長い春ストーリー。デジタルと大資本が嫌いで拘りばかりが先行して行動力も甲斐性も乏しいという、典型的だめんずのギタリスト君が恋人に愛想を付かされて初めて自己変革に乗り出し、目出度く元の鞘に収まるというお話。最後はちゃんと別れてそれぞれ成長するほうが苦くて良い映画になったんじゃないかって気が。2000年以降の英ロックシーンは良く知らないけど、ブラーやレディオヘッドくらいなら守備範囲内なので、あちこちに散りばめられた薀蓄は何となく分かります。ヒロインがもうちょっと可愛いかったらなぁw

青のオーケストラ [全24話]

オーケストラの指揮者と演奏者が表現を創り上げていく過程には以前から興味がありました。なので、幼少期からバイオリンの英才教育を受けてきたゲゲゲの鬼太郎みたいな髪型の主人公が入学した高校のオーケストラで、「優れたソリスト≠理想の合奏者」というギャップに陥るシーンは期待どおりだったんですが… その後は音楽とはそれ程カンケー無い所で悩んだりキャッキャウフフしたりするライトな青春ドラマですたw 登場人物も皆アク抜きされたみたいな薄味善人で、放映局が NHK だからってそこまで真面目かっ。シーズン2があってもこりゃ観ないかなーという所感ですが、原作読んだらまた印象が変わるのかしら。

マーク・ボラン:名声への運命

グラムロックの雄なのにデヴィッド・ボウイと比べてあまりストーリーが語られない(気がする)マーク・ボランのドキュメンタリー。ピークが過ぎた後にパンクの若手と呼応していた事など、「へー」な情報もあったけど、いかんせん50分という短さに加えて機械翻訳が酷すぎで残念な一作ですた。

チャプター27(字幕版)

ジョン・レノン殺害犯、マーク・チャップマンがハワイからニューヨークに降り立って犯行におよぶまでの3日間を描いたドラマ。これを観たからといって動機がすっきり解明されるという訳でもなく、それなりに誠実で行動力もあるが分裂症気味で視野狭窄なチャップマンの面倒臭い人物像が示されるだけ。タイトルは犯行時に読んでいた「ライ麦でつかまえて」の最終章(26章)の続き、という意味合い? しかし、主役のジャレッド・レトは細身のイケメン俳優な筈だけど、このぽっちゃりオタク体型への役作りはすごいw

ConoHa VPS V2 と V3 のパフォーマンスを比較

ドル高圧力に耐えかねて、プライベート用のサーバを AWS EC2 から ConoHa VPS に移行したのが二ヶ月ほど前のこと。それが先日、コンパネをいじっていたらメニューの一番下に「バージョン切替」というボタンが出来ていて、「ナニコレ?」とポチってみたら「新バージョン(Ver.3.0)と旧バージョン(Ver.2.0)の管理画面を切り替えることができます」とのダイアログ。

実際に切り替えしてみたらサーバリストに契約中のものが表示されなくなったので、先だって立てたサーバは Ver.2 だったようです。調べてみたら 12/22 までのリニューアルキャンペーンが行われているので、ここ暫くの間にサービスがメジャーアップデートされたってこと? アナウンスメールも来てないし、聞いてないぞそれ。

結局 V2 と V3 の違いはよく分かりませんでしたが、サービスの基本形は従来とさほど変わらないようなので、実際にサーバを立てて両者の基本性能を比較してみることにしました。私が立てたサーバのタイプは「メモリ 1GB/CPU 2Core」(Ubuntu 20.4 LTS)なので、これと同様のものを。V3 でサーバ追加しようとしたら Ubuntu に 22.04 LTS が追加されてますね。今どき 20 系はちょっと古いんでね? と思ってたのでこれは嬉しい。折角なのでこちらを選択してポチッとして、さてリモートログイン。

まず lscpu で両者のプロセッサを確認。

v2:~$ lscpu
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
Address sizes:                      46 bits physical, 48 bits virtual
CPU(s):                             2
On-line CPU(s) list:                0,1
Thread(s) per core:                 1
Core(s) per socket:                 1
Socket(s):                          2
NUMA node(s):                       1
Vendor ID:                          GenuineIntel
CPU family:                         6
Model:                              85
Model name:                         Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz
Stepping:                           7
CPU MHz:                            2095.078
BogoMIPS:                           4190.15
Hypervisor vendor:                  KVM
Virtualization type:                full
L1d cache:                          64 KiB
L1i cache:                          64 KiB
L2 cache:                           8 MiB
L3 cache:                           32 MiB
NUMA node0 CPU(s):                  0,1
(後略)
v3:~$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         40 bits physical, 57 bits virtual
  Byte Order:            Little Endian
CPU(s):                  2
  On-line CPU(s) list:   0,1
Vendor ID:               GenuineIntel
  Model name:            Intel Xeon Processor (Icelake)
    CPU family:          6
    Model:               134
    Thread(s) per core:  1
    Core(s) per socket:  1
    Socket(s):           2
    Stepping:            0
    BogoMIPS:            4000.00
(中略)
Virtualization features: 
  Virtualization:        VT-x
  Hypervisor vendor:     KVM
  Virtualization type:   full
Caches (sum of all):     
  L1d:                   64 KiB (2 instances)
  L1i:                   64 KiB (2 instances)
  L2:                    8 MiB (2 instances)
  L3:                    32 MiB (2 instances)
(後略)

なるほど、プロセッサは Xeon Gold 6230 から Icelake に変わったと。最近のプロセッサ事情には疎いので、性能的にどう違うのかはよく分かりません。なので、sysbench でベンチマーキング。

v2:~$ sysbench cpu run
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:   681.13

General statistics:
    total time:                          10.0012s
    total number of events:              6814

Latency (ms):
         min:                                    1.32
         avg:                                    1.47
         max:                                    7.86
         95th percentile:                        1.58
         sum:                                 9991.04

Threads fairness:
    events (avg/stddev):           6814.0000/0.00
    execution time (avg/stddev):   9.9910/0.00
v3:~$ sysbench cpu run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  2500.00

General statistics:
    total time:                          10.0010s
    total number of events:              25007

Latency (ms):
         min:                                    0.40
         avg:                                    0.40
         max:                                    1.73
         95th percentile:                        0.41
         sum:                                 9995.00

Threads fairness:
    events (avg/stddev):           25007.0000/0.00
    execution time (avg/stddev):   9.9950/0.00

すごいです。「CPU speed」は約3.7倍の数値。ではメモリ操作は?

v2:~$ sysbench memory run
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Running memory speed test with the following options:
  block size: 1KiB
  total size: 102400MiB
  operation: write
  scope: global

Initializing worker threads...

Threads started!

Total operations: 32082406 (3207346.87 per second)

31330.47 MiB transferred (3132.17 MiB/sec)


General statistics:
    total time:                          10.0002s
    total number of events:              32082406

Latency (ms):
         min:                                    0.00
         avg:                                    0.00
         max:                                    6.21
         95th percentile:                        0.00
         sum:                                 4801.21

Threads fairness:
    events (avg/stddev):           32082406.0000/0.00
    execution time (avg/stddev):   4.8012/0.00
v3:~$ sysbench memory run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Running memory speed test with the following options:
  block size: 1KiB
  total size: 102400MiB
  operation: write
  scope: global

Initializing worker threads...

Threads started!

Total operations: 51360071 (5135146.49 per second)

50156.32 MiB transferred (5014.79 MiB/sec)


General statistics:
    total time:                          10.0001s
    total number of events:              51360071

Latency (ms):
         min:                                    0.00
         avg:                                    0.00
         max:                                    0.84
         95th percentile:                        0.00
         sum:                                 3884.90

Threads fairness:
    events (avg/stddev):           51360071.0000/0.00
    execution time (avg/stddev):   3.8849/0.00

プロセッサの能力向上のせいでしょうか。転送速度が1.6倍に向上してます。次にファイル入出力を。

v2:~$ sysbench fileio --file-test-mode=seqwr run
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      0.00
    writes/s:                     8030.15
    fsyncs/s:                     10278.69

Throughput:
    read, MiB/s:                  0.00
    written, MiB/s:               125.47

General statistics:
    total time:                          10.0098s
    total number of events:              183185

Latency (ms):
         min:                                    0.01
         avg:                                    0.05
         max:                                   11.42
         95th percentile:                        0.08
         sum:                                 9887.20

Threads fairness:
    events (avg/stddev):           183185.0000/0.00
    execution time (avg/stddev):   9.8872/0.00
v3:~$ sysbench fileio --file-test-mode=seqwr run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      0.00
    writes/s:                     10705.59
    fsyncs/s:                     13712.75

Throughput:
    read, MiB/s:                  0.00
    written, MiB/s:               167.27

General statistics:
    total time:                          10.0051s
    total number of events:              244213

Latency (ms):
         min:                                    0.01
         avg:                                    0.04
         max:                                   35.71
         95th percentile:                        0.03
         sum:                                 9918.30

Threads fairness:
    events (avg/stddev):           244213.0000/0.00
    execution time (avg/stddev):   9.9183/0.00

総合的に1.3倍程向上してるようです。最後に MySQL での入出力を。事前の準備(CREATE DATABASE や GRANT 等)については省略します。

v2:~$ sysbench --db-driver=mysql --mysql-user=sysbench --mysql-password=******** --mysql-host=localhost --mysql-db=sysbench oltp_read_write run
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Initializing worker threads...

Threads started!

SQL statistics:
    queries performed:
        read:                            35378
        write:                           10108
        other:                           5054
        total:                           50540
    transactions:                        2527   (252.57 per sec.)
    queries:                             50540  (5051.32 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          10.0026s
    total number of events:              2527

Latency (ms):
         min:                                    2.44
         avg:                                    3.95
         max:                                   24.78
         95th percentile:                        5.28
         sum:                                 9992.98

Threads fairness:
    events (avg/stddev):           2527.0000/0.00
    execution time (avg/stddev):   9.9930/0.00
v3:~$ sysbench --db-driver=mysql --mysql-user=sysbench --mysql-password=******** --mysql-host=localhost --mysql-db=sysbench oltp_read_write run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Initializing worker threads...

Threads started!

SQL statistics:
    queries performed:
        read:                            91098
        write:                           26028
        other:                           13014
        total:                           130140
    transactions:                        6507   (650.48 per sec.)
    queries:                             130140 (13009.58 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          10.0016s
    total number of events:              6507

Latency (ms):
         min:                                    1.20
         avg:                                    1.54
         max:                                   10.59
         95th percentile:                        2.00
         sum:                                 9989.15

Threads fairness:
    events (avg/stddev):           6507.0000/0.00
    execution time (avg/stddev):   9.9891/0.00

こちらも2.6倍の向上というご機嫌な結果に。

まぁ単純なベンチマーキングなので、アプリケーションの体感等にどの程度現れてくるかは分かりませんが、これなら V2 ユーザは V3 に移行して損はないようです。ConoHa さんももうちょっと積極的にプッシュしたらエエのでは。

地理院地図の時系列表示で遊んでみたら面白かった

ツイッターか何かで「地理院地図の時系列表示が面白いよ」というのを見かけたので、実際やってみたら本当に楽しめたという話です。

地理院地図とは、国土地理院が運営しているウェブ地図サービスです。ただ地図を表示するだけじゃなく、様々な統計データをオーバーラップさせたり多彩なテーマに沿った表示形態を備えていて、これが無料で使えるなんて凄すぎる多機能ぶりです。ここ↓にその楽しみ方の一端が紹介されています。

www.gsi.go.jp

これを知ってまず思いついたのは、自分が生まれ育ったホームタウンの昔の様子を見てみることでした。とある地方都市にあるその町は、高度成長期に造成された新興住宅地で、道路や施設・店舗が小学校を中心にいかにも計画的に配置されていたことから造成以前は町らしい町が無かったことが窺えます。漠然と原野でも切り開いて作ったのかなーと思っていたので、地理院地図で造成前の様子を確認してみました。

地理院地図のトップページはこんな感じ。

ここで左上「地図」アイコンをクリックして、表示を「写真」にして種類から「時系列表示」を選択します。

最上段にある検索窓から地名等を入力して、マイホームタウンへ。

地図の上にスライダーがあるので、ここから表示させたい年代をクリックします。グレーアウト表示はその年代のデータが無いってことですね。この地点では過去の写真は1961〜1978年の2枚しか無いんですが、まぁ田舎なのでそんなものかも。まず古い1961〜1969年から表示させてみます。

思いっきり低解像度な白黒写真ですが、上下で団地造成前後に撮影時期が分かれているのが面白いです。上側の造成前は人家も疎らでひたすら農地が広がってますね。道すらも造成時に新しく作ったようで、東西を貫く現バス通りさえ無かったのは「へぇー」でした。さて次の年代(1974〜1978)へ。

多分この頃が町にいちばん活気があった時代でしょうか。現在のほうが逆に空き地が目立つのが物悲しいです。ちなみに後から少し調べたところではこの辺、農地以前は名産馬の放牧地だったのだとか。

そんな訳で、ウェブで楽しむタイムトラベルといった趣で楽しい時間でした。皆さんもぜひ。

AWS Parameters and Secrets Lambda Extension の日本語文字化けに対応した話

AWS Lambda 関数に DB 接続アカウント等の秘匿情報を注入したい場合は、やっぱり環境変数とかじゃなく Secrets Manager を使いたいですよね。最近では Parameters and Secrets Lambda Extension という拡張機能が用意されていて、アプリケーションプログラム内で直にシークレットを取得するより低コストに処理できるようになっています。

docs.aws.amazon.com

dev.classmethod.jp

てな訳で、上記を参考に自分もやってみた(ランタイムは Python)のですが、シークレットに日本語を格納していると所謂文字化けが発生してしまいました。例えば nihongo-test というシークレットの値が {"value": "日本語です。文字化けしてませんか?"} だと、

secretId = 'nihongo-test'
headers = {"X-Aws-Parameters-Secrets-Token": os.environ.get('AWS_SESSION_TOKEN')}
url = f"http://localhost:2773/secretsmanager/get?secretId=" + urllib.parse.quote(secretId, safe='')
resp = requests.get(url, headers=headers)
print(resp.text)

というプログラムでの print() の出力は

{"ARN":"arn:aws:secretsmanager:ap-northeast-1:xxxxxxxxxxxx:secret:nihongo-test-PJyzkt","CreatedDate":"2023-10-13T01:06:42.784Z","Name":"nihongo-test","SecretBinary":null,"SecretString":"{\"value\": \"æ¥æ¬èªã§ããæå­åããã¦ã¾ããã?\"}","VersionId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","VersionStages":["AWSCURRENT"],"ResultMetadata":{}}

のような有様に。キャッシュサーバからのレスポンスの Content-Type を確認したら 'text/plain' のみで charset 明示が無かったので、そのへんが原因みたいです。なので、

print(resp.content.decode(encoding='utf-8'))

のように resp.text ではなく、resp.content から body を取得してバイト列→文字列と変換してやれば OK ですた。