mac上でダブルクリックでPySimpleGUIを用いたGUIアプリケーションを起動する方法
下記のポストに引き続き、PySimpleGUIに関するポスト。
macでは .command という形式で .sh ファイルを作成することで、ダブルクリックでそのシェルスクリプトファイルを実行することができる。
この仕組を応用して、ファイルをダブルクリックすることでPySimpleGUIを用いたGUIアプリケーションを起動してみたのが今回の備忘録となる。
実行するPySimpleGUIアプリケーションについて
実行するPySimpleGUIアプリケーションについては、前回のポストにも書いたテーマカラーの一覧を表示するものとする。
下記のコードを display-theme.py として保存する。
import PySimpleGUI as sg sg.theme_previewer()
このコードを実行すると下記のような画面が立ち上がる。
.commandファイルを作成してみる
では、実際に.commandファイルを作成してみる。
直接下記のように.command ファイルを作成しても良いし、
vim display-theme.command
一旦 .shファイルで作成してから下記のように .command に変更しても良い。
mv display-theme.sh display-theme.command
記載するシェルスクリプトの内容
# .commandファイル実行時カレントディレクトリがrootになっているため、 # 下記のコマンドでファイルが存在する場所に移動する cd `dirname $0` # Pythonスクリプトを実行 # 一応正常に実行されたか、実行結果をechoで出力させている python display-theme.py echo $? # いずれかのキーを押すことでターミナルが閉じる # これをつけない場合、ターミナルは瞬時に閉じるため、正常に実行されたかを確認するためにも一応挟んでおいた read a
以上の内容でシェルスクリプトを作成したら、下記のように実行権限を付与する。
chmod u+x display-theme.command
ちなみにこの段階でファイル構造は下記のようになっている。
. ├── display-theme.command └── display-theme.py
あとはFinderから直接この .command ファイルをダブルクリックすればテーマカラー一覧が表示されたGUIアプリが立ち上がる。
実際のコードをGitHubにも置いた。
PySimpleGUIを触ってみた備忘録(ボタンの配置とログ出力のサンプル、テーマカラーについて)
PySimpleGUIというPythonでかんたんにGUIを作れるライブラリを触ってみたので備忘録。
目次
- 目次
- PySimpleGUIとは？
- PySimpleGUIはライセンスが LGPL3.0 なので商用利用などで実行バイナリを配布する場合は注意が必要
- PySimpleGUIで作成したログ表示サンプル
- PySimpleGUIのテーマカラーについて
- FindElementに関するWarning
- Effective Python良かった（余談）
PySimpleGUIとは？
2018年に作成された比較的新しいライブラリで、tkinter, Qt, WxPython, RemiなどのGUIフレームワークを、よりシンプルなインターフェースに変換して利用できるライブラリ。
つまりGUIフレームワークのラッパー的な立ち位置となる。
ラッパーという立ち位置からも想像できるようにPySimpleGUIを使えば、GUIフレームワークを使ってゴリゴリUIを作成するよりもかんたんにGUIが構築できる。またpip経由でインストールが可能、というのも楽なポイント。
勿論、UIを作る用途によっては適さないシーンもあるようなので、作成するUIにそこまでこだわりはなく、ある程度工数をかけずにPythonでGUIを構築したいという用途が一番マッチするような印象。
実際インストールはかんたんで、下記のようにpipインストールし、
pip install pysimplegui
公式ページにある、かんたんなサンプルを入力することで問題なくGUIが立ち上がった。
import PySimpleGUI as sg sg.theme('DarkAmber') # Add a touch of color # All the stuff inside your window. layout = [ [sg.Text('Some text on Row 1')], [sg.Text('Enter something on Row 2'), sg.InputText()], [sg.Button('Ok'), sg.Button('Cancel')] ] # Create the Window window = sg.Window('Window Title', layout) # Event Loop to process "events" and get the "values" of the inputs while True: event, values = window.read() if event == sg.WIN_CLOSED or event == 'Cancel': # if user closes window or clicks cancel break print('You entered ', values[0]) window.close()
なお、筆者の環境はM1 Macであり、Pyenvを用いた上で構築している Python 3.9.6 で動作している。
※m1 macでのpyenv環境構築については下記に書いたので興味ある方はぜひ
GUI周りだし何かしらエラーで立ち上がらないだろうな、と期待していなかったが、いちおう問題なくGUIは立ち上がったので、これは良いかもと思った次第。
PySimpleGUIはライセンスが LGPL3.0 なので商用利用などで実行バイナリを配布する場合は注意が必要
ここで余談を挟むが、最近はVBAからPythonへの移行が増えてきているらしい。
もともとVBAで書かれていた業務アプリをPythonに移植するような感じだ。
そんな流れでかんたんなGUIを構築する際のライブラリとしてPySimpleGUIが用いられている例をいくつか見つけた。
たしかに今回触ってみたが、サクッとGUIを構築できたので、これは便利そうだと思った次第。
ただし注意点があり、PySimpleGUIはライセンスがLGPL3.0のため、例えばPySimpleGUIを含んだ状態で作成した実行バイナリを配布する場合は、ソースコードを公開しなくてはならない点に注意が必要となる。
ソースコード公開を回避するためには下記のような手段を取るなど一応回避手段はあるようだが、一度ここらへんは利用を始める前に検討してみたほうが良いだろう。
(下記の手段を取る場合はユーザのPCにPython環境を構築する必要がある)
なお、実行バイナリを配布して利用してもらいたいケースでは残念ながらPySimpleGUIは使えないので、代替案としてtkinterなどを利用することになるかと思われる。
ちょうど今tkinterを使ったGUIプログラミングについてをあれこれとまとめているので興味ある方はこちらも参照してみてください。
PySimpleGUIで作成したログ表示サンプル
今回はひとまずボタンに対応する処理を動かすのと、処理の中のログを表示する窓を作ってみることにした。
また、ログの内容をクリップボードにコピーする機能と、クリアする機能も合わせてつけてみた。
サンプルのコード量としては大したことないので、たぶん私が浅い知識で解説を挟むよりも、直接コードを見てもらったほうが分かるかと思う。
PySimpleGUIをインストールした環境で、下記のコードをコピペして実行してもらえれば、こんなウィンドウが立ち上がるかと思う。
なお、今回テーマカラーは適用していないが、テーマを指定したい場合は4行目のコメントアウトを外して、対応したカラースキームの文字列を入力すれば適用される。
テーマカラーについては少しだけこのあとに書いている。
import PySimpleGUI as sg # テーマカラー # sg.theme("Default") # メインのコントロールエリア control_layout = [ [sg.Button("Test Log Output")], [sg.Button("Close")] ] # ログの表示・操作エリア log_layout = [ [sg.Button("Copy"), sg.Button("Clear")], [sg.Output(size=(100, 5), key="-OUTPUT-")], ] layout = [ [sg.Frame("Log", log_layout)], [sg.Frame("Main Control", control_layout)] ] # ウィンドウを作成 window = sg.Window("PySimpleGUI Log Sample", layout) # このループ内でイベントと入力値の処理を行う while True: event, values = window.read() # ウィンドウを閉じたときはここの処理が動く if event == sg.WIN_CLOSED: break # Closeボタンを押したときはここの処理が動く # ここではサンプルとして分けているが、上の処理と同じなのでif文はまとめてOK if event == "Close": break if event == "Test Log Output": print("Push [Test Log Output]") if event == "Clear": window.find_element("-OUTPUT-").Update("") if event == "Copy": window.find_element("-OUTPUT-").Widget.clipboard_append(window.find_element("-OUTPUT-").Get()) sg.popup("Log copied to Clipboard.") window.close()
今回、律儀に if だけで区切って書いているが、elifなどで分岐させてもよいのかもしれないし、実際にそうやってサンプルを書いている方もいたので、それで良い気がする。
実際に起動すると、print関数で出力されるログがログ出力用エリアに出力されるのが分かると思う。
また、今回
event, values = window.read()
の values の値を使っていないが、これはまた別にサンプルを書いてみようと思う。
(PySimpleGUIを少しずつ理解していこうと思う)
PySimpleGUIのテーマカラーについて
PySimpleGUIには様々なカラースキームが用意されており、それらの一覧は下記のコードを実行することで確認できる。
import PySimpleGUI as sg sg.theme_previewer()
これを実行すると、下記のようなウィンドウが立ち上がる。
ここで利用したいテーマカラーを sg.theme("利用したいテーマ") に入力すれば適用される。
FindElementに関するWarning
今回のサンプルを実装する上で下記のようなwarningに遭遇したので、書いておく。
FindElement という対応するkeyを取得するための関数があるが、これを使うと下記のようなwarningが出る
UserWarning: Use of FindElement is not recommended. Either switch to the recommended window[key] format or the PEP8 compliant find_element warnings.warn('Use of FindElement is not recommended.\nEither switch to the recommended window[key] format\nor the PEP8 compliant find_element', ** Warning - FindElement should not be used to look up elements. window[key] or window.find_element are recommended. **
エラーメッセージの通りで、FindElement ではなく find_elementを使うことでwarningは消える
下記の通り。
if event == "Clear": window.FindElement("-OUTPUT-").Update("")
下記のようにすることでwarningが消える
if event == "Clear": window.find_element("-OUTPUT-").Update("")
以上のようにまだ少ししか触れていないが、特に面倒なエラーにも遭遇せずに扱えたので、第一印象は良さそう。
引き続き、少しずつ触っていってみようと思う。
Effective Python良かった（余談）
ずっと家で積ん読していた Effective Python を読んだら、すごくかゆいところに手の届く内容だった。
こういうときPythonだとどう書くのが良いのか？スレッド処理はどうする？などなど、普段からコード書きながら感じていた疑問が、氷が溶けるように本を読み進めていく中で溶けていくのを感じた。
しかも今試しにチェックしてみたら、第2版がでていて、内容をパワーアップしているよう！
個人的に買ってよかったPython本の一つです。
Google Search Consoleで2021年9月17日までのデータしか表示されなくなっている件についてと、秋の訪れとCaramel Shipについて
現在Google Search Consoleでは2021年9月17日までのパフォーマンスデータしか表示されなくなっている
現在Google Search Consoleでは2021年9月17日までのパフォーマンスデータしか表示されなくなっているが、これはGoogle Search Console側の問題であるようなので、特にユーザ側が気にする必要はなさそう。
原因としては内部的な問題と表現されており、パフォーマンスデータに遅延が生じている、とコメントされていることから、しばらく待てば9月17日医工のデータも表示されるようになりそう？
なお、これらの問題はレポート上の問題であるようで、サイトのクロールインデックスやGoogle検索結果のランキングには影響しなさそうだ。
Googleからのアナウンスは下記のリンクから確認が可能
秋の訪れ
せっかく数日ぶりにブログを書いたので、もう少し書く。
最近は蝉の鳴き声も沈まり、ようやく秋の訪れを実感する頃合いとなった。
日差しは強いがよく晴れた日か、シトシトと世間が静まり返るような雨の日かのどちらかが続いてるような気がしている。
いずれにせよ、本格的に秋の季節がやってきつつあるということである。
最近、Caramel Shipで１曲、新しい曲を書いたのだが(まだ完成に向けて作業中である)、一緒に音楽を作っているデスモンドとは好きな季節が秋という共通項があり、ようやく辛い暑さの時期が過ぎようとしてくれていることにお互い喜びあった。
なお、Caramel Shipには Farewell, Summer という曲がある。タイトルのとおりな雰囲気をまとっている曲だが、ちょうど今ぐらいの時期に聴いてみるのもありかもしれない。
というわけで、Apple Musicのリンクを貼っておきますので、よろしければ聴いてみてください。
(Apple Musicだけでなく、他のサービスでも配信しています)
Caramel Shipの「Marjoram」をApple Musicで
ちなみに Farewell, Summer はデスモンドが来日にしているときに滞在中のホテルで一緒に顔を突き合わせてアレンジを練った曲である。
最近はコロナの影響もありお互いに顔を直接合わせるという機会もなくなってしまったが、また直接一緒に曲作りができれば良いなと思う。
今作っている曲も完成したらぜひ聴いてみてください。
カセットテープによるリリース
そういえば、Rebuildのこのエピソードでカセットテープに関する話題が出ていたが、Caramel Shipでもカセットテープによるリリースを行っていた。
「お、我々もやっているやつだ！」
とポッドキャストを聞きながら思った次第である。
カセットテープについては上に実際の写真が載っています。こんな感じでリリースしていました。
(いまはデジタルオンリーだったかな？)
Create React Appで作成したアプリケーションに対してTestCafeでのE2EテストをGitHub Actionsから動かす
Create React Appで作成したアプリケーションに対して、E2EテストをTestCafeで実装した。
ローカルでE2Eテストを動かす分にはさほど難しくはなかったが、GitHub Actions で動かす際にはハマったりすることが多かったので、一旦このように書けば動く、というコードをこちらに載せることにした。
将来、自分がサクッとTestCafeによるE2EテストをGitHub Actionsで動かすためのメモ的なニュアンスとなる。
なお、GitHub Actionsで動かす際にハマったあれこれについては、後日備忘録にまとめてこちらに別途残しておこうと思う。
TestCafeによるテストコードについて
TestCafeによるテストコードの内容だが、別途 yarn start で立ち上げたローカルアプリに対してテストを実施するという構成となる。
yarn start でローカルサーバを立ち上げた状態から下記のように localhost:3000 にアクセスしてテストを行う。
import 'testcafe'; import { Selector } from 'testcafe'; fixture('Getting Started').page('http://localhost:3000'); test('Test', async (t: TestController) => { ・ ・ ・ });
GitHub Actionsのymlファイル
下記がGitHub Actionsのためのymlファイルとなる。
ubuntu-latest環境、かつNode.jsのversionが 12 , 14 で動く形となる。
name: Target Multiple Node.js Versions
on: [push]
jobs:
build:
name: Run Tests Across Node.js Versions
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12, 14]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node-version }}
- uses: actions/checkout@v2
- name: Server start
run: |
yarn
yarn start &
- name: Run TestCafe Tests
uses: DevExpress/testcafe-action@latest
with:
args: "chrome:headless e2e/test.ts"
ここで軽くコードについて書いておくと、ローカルで立ち上げたサーバにアクセスするために yarn start &しているが、ここが yarn start の場合、次に進まない状態となってしまっていた。
yarn start & としてバックグラウンド実行することにより、後続のテストコマンドを実行させている。
このやり方が正しいのかは分からないが他に動かし方が分からなかったのでこうしている。
(もしもっとこうしたほうが良いよ、という方がいましたらコメントお待ちしています)
UbunutとWindows環境でテストを行いたい場合
Windows環境のテストなども試みたりしたのだが、windows側でのテストはまだうまく動かせていない。
ただ、下記のように書くことでOS環境ごとの実行を振り分けることができたので、こちらもメモとして残しておくことにする。
name: Target Multiple Node.js Versions and Operating Systems
on: [push]
jobs:
build:
name: Run Tests Across Node.js Versions and Operating Systems
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [12, 14]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node-version }}
- uses: actions/checkout@v2
- name: Server start(ubuntu-latest)
if: ${{ matrix.os == 'ubuntu-latest' }}
run: |
# osが ubuntu-latestの場合にのみ実行される処理
yarn
yarn start &
- name: Server start(windows-latest)
if: ${{ matrix.os == 'windows-latest' }}
run: |
# osが windows-latestの場合にのみ実行される処理
# ただし、まだうまく動かせていないのでrun以下の処理は割愛
- name: Run TestCafe Tests - os:${{ matrix.os }}, node-version:${{ matrix.node-version }}"
uses: DevExpress/testcafe-action@latest
with:
args: "chrome:headless e2e/test.ts"
macOS環境でのテストについて
GitHub Actions でmacOS環境でのテストを動かしたい場合、より手間がかかりそうな印象。
自分は試していないが、下記の公式ドキュメントに記載があり、参考のコードも載っているのでmacOSでテストをしてみたい方は要チェック。
Github Actionsでは、macos-latestとして「System Integrity Protection」を有効にしたmacOS Catalina 10.15の仮想環境を使用しています。この設定が有効な場合、TestCafeでは必須となる画面録画の許可が必要になります。そのためTestCafe では、macos-latest での GitHub Actions を使ったテストをローカルで実行することができません。ただし、ブラウザをリモートで接続すれば、macOSの仮想マシンでもテストを実行できます。
マクドナルドのサイドメニューをチキンマックナゲットにしたら、食後独特の胃の重さがなくなったことについて
今日は個人的にライフチェンジングと書くと大げさだろうが、マクドナルドを食べる際に意識するようになって大きく改善されたことについて書いていこうと思う。
なお、このブログ内での記述はあくまで個人の感想によるものであり、またマクドナルドのポテトをdisる気はまったくない。
(この時点ですでにネタバレ...)
ただ、これほどまでに変わるものかと自分的には結構大きな発見だったので、ここに書いておくことにした。
繰り返すがマクドナルドのポテトも好きだし、disる気はサラサラない。
はじめに
マクドナルドは好きで時々食べる。
以前まで私の定番はビッグマックだったが、今ではサムライマックの炙り醤油風ダブル肉厚ビーフにその座は譲られた。
醤油ベースのタレが食欲をどこまで刺激し、あっという間に食べてしまう。
さらにはサイドメニューの定番として今まで君臨していたポテトも、チキンマックナゲットにその座を譲った。
ポテトは今でも好きだが、甘めのマスタードソースをつけたチキンマックナゲットもこれまたたまらないのだ。
ここ最近は意識的にタンパク質を取るようにもしているので、そういう点からもチキンマックナゲットには追い風が吹いていた。
そしてサイドメニューをチキンマックナゲットに変えたことによって、意図せず体に変化が生じたことに気づいた。
マクドナルドのサイドメニューをチキンマックナゲットにしたら、食後独特の胃の重さがなくなった
というわけで、本題である。
今までの人生で一つちょっとした悩みがあった。
マクドナルドのジャンキーなテイストは大好きで定期的に食べたくなるのだが、食後には必ず "ジャンキーなものを食べてしまった感" が胃のあたりに残るのだ。
これは胃もたれほどまでは行かないが、不快ではないというと嘘にはある微妙なラインでの不快感だ。
今になって思えばポテトフライによる油の摂取によるものなのかもしれない。
この微妙な胃の重さだが、サイドメニューをチキンマックナゲットに変えた途端、なくなった。
これは自分でも驚いたことだが、例えば日中にマクドナルドを食べた場合、その日１日はマクドナルドを食べたあとの独特の感覚が体を支配していたが、それが殆どなくなってしまった。
「あれ、今日の昼間何食べたっけ？あ、マクドナルドだ。」
という具合に、自然と体に溶け込んでいる(気がする)。
個人的にこの変化は大きく、今ではサイドメニューは必ずチキンマックナゲットだ。
また、あまり胃のあたりが重くならないゆえに、以前よりもマクドナルドを食べる頻度は増えているような気もする。
不快感があとに残らなければこれほど「ジャンキーなものを食べたい欲」を満たしてくれる食事はない。最高だ。
この自分の発見をどこかに残しておきたくて、この日記に書いておくことにした。
最初にも書いたがマクドナルドのポテトをディスる気はないし、今でも好きだし、なんなら子供が食べるときにちょっともらったりもする。
が、チキンマックナゲットをサイドメニューに選んだ際の食後の胃の軽さは、かなり良い。
また、チキンマックナゲットをはさみつつ、サムライマックをかぶりつくあの快感も病みつきになる。
(そしてアイスコーヒーでぐっと流し込むのだ。かー、快感！)
以上、最近の発見でした。
GitHubのREADMEで画像サイズを指定する方法
ちょっと苦労したので備忘録として残しておきます。
前提条件
- あくまで自身の備忘録として残しているので、網羅的な内容ではない
- GitHubのissueに画像をアップロードして、そちらの画像をREADMEから参照からする際にこの指定方法を用いている
- GitHub Flavorにおける指定方法である可能性もあるが、他のmarkdownで指定できるかまでは試していない。
参照したページ
下記のページを読んで色々試したりしていました。
image resize in github flavored markdown. · GitHub
結論
<p align="center"> <img src="画像URL" alt="altテキスト" width="指定したい幅(例: 400px)"> </p>
※ちなみに p タグに付いている align="center" は text-align:center;と同じもの。
今回の内容からは外れるので、割愛します。
このようにして width="横サイズ" を指定するすることで、GitHubのREADME上で表示させたときにいい感じに表示してくれます。
ちなみに height="縦サイズ"も指定できるのですが、こちらを指定すると、例えばスマフォ表示時など画面幅が狭まったときに、比率がおかしくなります。
(縦に伸びてしまう)
E2E テストフレームワークのTestCafeを始める前に聞かれる、TestCafe Browser Toolsの権限許可について
E2EテストのフレームワークであるTestCafe。
数年前からTestCafeが良い、という話を時折耳にする機会があった。
https://testcafe.io/testcafe.io
今までなかなか触れる機会がなかったが、ちょうど今Reactでオセロを作っているので、それのE2EテストをTestCafeで書いてみようとしてセットアップしたところ、微妙につまづき？というか一応備忘録として残しておきたい内容があったので、こちらに書いておく。
目次
書いていたら思いのほか長くなってしまったので、目次をおいておく。
- 目次
- Error: Cannot find module '@babel/plugin-proposal-private-methods'
- TestCafe Browser Toolsに画面収録の許可を与えてやる必要がある。
- "TestCafe Browser Tools"が"Google Chrome"を制御するアクセスを要求しています
- あとがき
Error: Cannot find module '@babel/plugin-proposal-private-methods'
ひとまずプロジェクトに対して下記のようにインストールを行って、
yarn add -D testcafe
簡単なサンプルコードを書き、実行してみようとしたところ、下記のようなエラーが出てきた。
ちなみにテスト実行のアプリは Create React Appで作成したアプリだった。
Error: Cannot find module '@babel/plugin-proposal-private-methods'
エラー表示の通り、 @babel/plugin-proposal-private-methods がないということだったので、下記のように対応して完了。
yarn add -D @babel/plugin-proposal-private-methods
上記事象について細かく調べていないが、上記プラグインが必要になるテストコードを書いていたからかもしれない。
なので、TestCafeを試した方全員に出てくるものでもなさそう。
TestCafe Browser Toolsに画面収録の許可を与えてやる必要がある。
上に書いた問題も解決し、再度実行しようとしたところ、今度はTestCafe Browser Toolsに画面収録の許可を与えてほしいというダイアログが現れた。
TestCafeがそう言うなら...と何も考えずに許可をしようとしたが、一応日本語の紹介記事などを見てみると、これについての記述がパッと見、見つからず不安になった。
色々と調べてみると、最近のバージョンでは許可を求められるようになったらしい。
TestCafe requires screen recording permission on macOS (v10.15 Catalina and newer) to perform test actions, take screenshots and record videos. When TestCafe starts the first time, macOS asks you to allow screen recording for TestCafe Browser Tools.
日本語訳が下記
TestCafe は、macOS (v10.15 Catalina 以降)でテストのためのアクションを実行したり、スクリーンショットを撮ったり、ビデオを録画したりするために、画面収録の許可が必要となります。TestCafeを初めて起動したとき、macOSはTestCafeブラウザツールの画面収録を許可するように尋ねます。
というわけで、最近(でもないが)は許可を求められるらしい。
「システム環境設定」→「セキュリティとプライバシー」→「プライバシー」→「画面収録」を開き、アプリケーションリストの「TestCafe Browser Tools」にチェックを付けてやる。
"TestCafe Browser Tools"が"Google Chrome"を制御するアクセスを要求しています
これで再度実行してみると、今度は下記のようなダイアログも出てきた。
"TestCafe Browser Tools"が"Google Chrome"を制御するアクセスを要求しています。制御を許可すると、"Google Chrome"の書類やデータにアクセスしたり、そのアプリケーション内で操作を実行したりできるようになります。
OKを選択してやることでTestCafeが無事に起動し、他のサイトでも紹介されているようなイケてる画面が出てきたりしてテストが実行される。
というわけで、とりあえずテストのセットアップは完了したので、後日TestCafeでテストを書いていってみようと思う。
あとがき
この文章を書き終わって公開ボタンをおそうと思った瞬間、そういえば前にもTestCafeについて書いていたことに気づいた。
許可を求められることについても書いていたようで、自分の記憶からTestCafeがきれいに抜け落ちていたことに驚愕している。
来年にもまた「今回始めてTestCafeを触ってみようと思う」的な文章を書いていたら、いよいよヤバいなと思う今日このごろである。
TestCafe + Create React App + GitHub Actionsについて書いた
Create React Appで作成したアプリケーションに対して、TestCafeのテストを書き、さらにGitHub Actionsで動かす際の備忘録についてこちらに書いたので、併せてリンクを貼らせていただく。
GitHub Actions で動かす際にはハマったりすることが多かったので、一旦このように書けば動く、というコードを載せている。
