ドキュメント・ファイル管理についての所感とか近況の整理とか

考えたこと・連想したことを、論理の破綻を放置してとりあえず書き出してみる。 データセット、保存したイラスト、素材、ゲーム録画ファイル、編集プロジェクト、電子書籍や資料のPDF。 こういった、ありふれたファイルの管理がすごく苦手だなと思った。 プログラムのソースコードならば、gitで管理せよ、で済ませることができる。これは5年以上使っているので、それなりに慣れているつもりだ。こちらは問題ない。 一方で、10年以上やっているはずの通常のファイル管理はすごく苦手だ。あるいは、苦手になってしまった。 この原因は、以下のようなものかもしれない。 どこにいてもファイルにアクセスできるようにしたい。すべてのファイルのバックアップをとりたい。 すべてのファイルをアップロードする。オンラインストレージ上にファイルがあふれる。 すべてを同期してはローカル容量が不足するので、複雑な同期設定が必要になる。あるいは、同期設定を前提とした複雑なディレクトリ構造にせざるを得なくなる。 ファイルの管理ができない。 物理的な移動なしでファイルにアクセスできるようにするというのは、利便性という面で間違っているとは思っていない。 まあコロナ禍以降、外出の減少によって意味は薄れているかもしれない。 GitHubやニコニコ動画などのWebサービスがどこからでも使えるように、自分のファイルをどこからでも使えるのは便利なはずだ。 実際にどれだけこの利便性を享受しているかというと、怪しいところではあるのだが、これを掘り下げるべきだろうか。 実際にそのすべてを使うかどうかはともかくとして、100MBを越えるファイルやファイル群を扱うことはままある。 これをSaaSでぽこぽこ扱っていたら、料金がすごいことになる。 そのために、自宅でNextcloudをホストして、8TBのオンラインストレージを確保している。 ほぼすべてのPCがデュアルブートになっている。 巨大な単一のオンラインストレージがあることで、どこにどのファイルがあるか、という管理をする必要がなくなる。 このファイルはあのPCの中のあのOSにしかない、ということがなくなる。どの環境に保存したかを覚えておく必要がなくなる。 一方で、何の目的にも、どの環境を使ってもよくなる。 それならば、一番スペックが高く、最も自分の目的で処理上のパフォーマンスを発揮できる環境ばかり使うようになる。 2021年まで母艦のUbuntuばかり使っていた。 一方で、2022年からWindowsでしか動かないVOICEROIDを使い始めたので、それを理由にWindowsをメインに使うようになった。 プログラムを集中して書くときはWindows環境は処理上のパフォーマンスが悪いので、Ubuntuに切り替える。 それでも最近では、Windows環境を使ってもいいんじゃないかと思ってきている。 いまのところプログラムを書く目的が例外ではあるが、環境によって目的を分ける、目的によって環境を分けるということができていない。 すごくファイルがごちゃごちゃしてしまう。 いまはある程度整理した・整理するようにしたけれど、Twitterで見かけた画像とか自分で撮った写真をフラットな単一ディレクトリに保存していて、1ディレクトリに何千とか何万とかのファイルがあった。 同期の仕様とかアプリの仕様とか保存時の手間とかでそうするのが楽だったのだけれど、とてつもなく扱いにくい。 同じことがメモアプリにも起きている。Twitterでファボしたツイートを、IFTTTでEvernoteに自動保存するようにしていて、数万件のツイートが単一のノートブックに保存されている。また、訪れて何か得るものがあったURLをすべてPocketに送っていて、数十万件のURLが分類されることなくフラットに保存されている。Joplinでは、InboxやArchivesというノートブックが、ほぼ分類上の意味を持たずに数百件・数千件のノートが保存されていたりした。これはさすがに整理したが、整理したことの恩恵をあまり受けた記憶がない。これでは整理した意味がなかったのではないかとも思っている。 巨大な単一のオンラインストレージがある環境で、目的意識をもつことは難しいのか? 最近は、「数字_大分類/数字_小分類」というようなディレクトリ名をつけて分類している人を見かけたので、試しに真似てみている。Joplinでは、これ以前に同様の分類をしたけれど、恩恵を受けられているかは怪しいのだが、ファイルシステムでは違う結果が得られるのではないか、と思った。 この方法をとると、このディレクトリをファイラーで開いている、その間はこの作業をしている、というフレーム・目的意識を持つことができそうだと思った。 最近、Workspaceという同期ディレクトリを作った。この中で番号付けし、分類したディレクトリ構造を作っている。Documentsも考えられるが、特定のOSでしか意味がないファイルなどOS依存の構造をもっているため分けている。 こういう取り組みはこれまでに何度もやって、使わなくなって破綻していた。 なぜ使わなくなったかというと、分類されていないために使いづらかったからだと思っている。 これまでは分類はいずれ破綻する、という想定のもと、分類しないことにしていたのだ。分類が破綻したり再分類が必要になるとパスが変わってしまう。様々な環境に同期する都合上、パスが変わることは問題にならないのではないかとも思うのだが、パスが変わるのはあまり気分がよくなかった。 GitHub上のリポジトリも200以上あるが、最近他の人を参考にwebサイト管理用のリポジトリをorgに分割した以外に分類はしていない。 分類しないことによって、思考の枠組みがなくなってしまったのではないか。 永続化の目的でしかオンラインストレージを使わなくなってしまったのかもしれない。 何か作業をすることが減ってしまった。ひたすら永続化し続ける。その状態をなんとかしたかった。価値のある作業をするようにしたかった。 根源には、いろいろなことに対するモチベーションがすごく落ちているということがあるのかなと思った。 それになんとか対処したいというのが、ファイルの管理ができないという問題意識につながっている。 ある意味では、テスト前に部屋の掃除をしたくなるとか、新しい文房具セットを買ってみたくなるとか、というのと同じなのだと思う。つまり意味がない。 すごく飽きっぽいのかなと思っている。飽きっぽさはずっとありそう。簡単に触れるところだけ触って、深淵には立ち入らない。すごくそれが好きだ、ということがない。なんとなく触って、飽きて終わってしまう。そういうことばかりなのではないか? 日記を書くのが無理だ。なにか印象的なことがあったときに、その感想を書くくらいはできる。それに何時間もかけることもできる(逆にかかってしまう、のだが)。だけれど、日記を書くためにいろんなことをしてみるとか、感性豊かにするとか、そういうことはできない。書くことがないから書けない。 絵を描くのが無理だ。なにか好きなものがあったときに、突発的に下手な絵を描くことはできる。それに何時間もかけることもできる。けれど上達するために継続して少しずつ絵を描き続けることができない。 プログラムを書くのが無理だ。なにか必要なスクリプトがあったときに、一回きりあるいは変えずに使い続けるだけのスクリプトを書くことができる。それに何時間もかけることもできる。けれど価値あるプログラムを計画して書くことができない。アイデアもないし、アイデア出しもしていない。作業中のPRも放置してしまっている。 動画を作るのが無理だ。一応の撮れ高があったときに、一回きりで十時間前後かけて動画を作ることはできた。けれど新しくネタを考えたり、ブームに乗ったりしていない。一応まとめればほかに1本作れそうなのに、30秒のクリップとかいって、まとめる時間をかけなかった。 この文章だってそうだ。 自宅のインターネットがたびたび不安定になる。 これもプライベートネットワークにストレージを置きたい理由ではあるのだけれど、そうはいってもインターネットにつながらなければどうせ作業が難しいだろう。インターネットを経由すると遅い、というパフォーマンスは理由になるかもしれないけれど、それが問題になるほど重いファイルをやり取りするかというとしない気がする。出先で使いたい場合にモバイル回線の容量をあまり使いたくないというのはあるかもしれないけれど、転送速度制限がかかることをあんまり気にしたことがない気もする(もともと遅いのでは)。 オンラインストレージ以外に、ファイルが添付できるWikiも考えられるけれど、サイズの上限は数MBあるいは数十MBで、おそらくセキュリティや濫用防止の目的でファイルの種類も制限されることはままある。 これは可能性があって、ファイルにそれを説明する文書を添付できる。オンラインストレージはこれが難しくて、ただファイルをおくだけで、まともに分類できていなかった。なにも禁止されてはいないのだけれど、おそらく面倒くさいからだ。NextcloudにはディレクトリのREADMEを作る機能があったりするけれど、まあブラウザ上で見ることになるし取り回しは悪い。 結局、これまでもできたところでやらなかったのだから、Wikiもまともに作るわけがない…。ファイルサイズの制限とか、ストレージ肥大化とかは問題にならなくて、やらないのは面倒だからなんだろうなという感じがする。 ドキュメントを書くのもすごく下手だ。 画像とテキストを組み合わせたいとか、いろいろ難しい。 またEvernoteを有料契約してしまったけれど、あまり使えている気もせずに、こういうメモをScrapboxに書き出している…。 技術記事を書いても論理破綻とか脱線とかしかしないんじゃないかと思っている。 イーブイを肉じゃがに進化させたけど、エナドリも飲んだし砂糖が多すぎるかもしれない…。 上に行ったり下に行ったりして文章を書くと絶対流れが破綻する。 先にプロットを決めて書くといいと思うけど、それが面倒くさい。 プロットを作った時点で満足するか、途中で脱線してプロットが破綻する。 結局ほかにやらないとならないことがたくさんあるのがよくないんだよな 誰かと時間を約束しても守れる気がしない

2022年5月9日 · aoirint

複数の音声ストリームを持つ動画ファイルを簡単に編集する方法がほしい

OBSには、音声を複数のストリームに分けて録画する機能がある。 Shotcutを使って編集しているのだけれど、複数の音声ストリームをうまく扱えないでいる。 1つの動画アイテムに対して、全部のストリームを混ぜるか、もしくは1つの音声ストリームを選ぶことはできるけれど、音声ストリームを選択して混ぜることができない。 動画アイテムを複製すればできるはずだけれど、そういう想定なのかな・・・? → 音声を分離したあと、音声を複製して、それぞれストリームを選択すればいいのかもしれない。 ffmpegは、mapオプションを使って複数のストリームを持つ動画ファイルを扱うことができる。 そこでffmpegを使って、音声なしの動画ファイルと、各音声ストリームを別々に取り出した音声ファイルに分割するのを試してみた。 以下のようなシェルスクリプトを作った(映像:NVENC H.264、音声aacのmkvファイルを想定)。 #!/bin/bash INPUT=$(realpath "$1") #OUTDIR=$(realpath -- "$(dirname "${INPUT}")") OUTDIR=. FILENAME=$(basename -- "${INPUT}") EXTENSION="${FILENAME#*.}" BASENAME="${FILENAME%%.*}" mkdir -p "${OUTDIR}" ffmpeg -i "${INPUT}" \ -map 0:v:0 -vcodec copy "${OUTDIR}/${BASENAME}_video.${EXTENSION}" \ -map 0:a:1 -vn -acodec copy "${OUTDIR}/${BASENAME}_app.m4a" \ -map 0:a:2 -vn -acodec copy "${OUTDIR}/${BASENAME}_mic.m4a" \ -map 0:a:3 -vn -acodec copy "${OUTDIR}/${BASENAME}_meta1.m4a" \ -map 0:a:4 -vn -acodec copy "${OUTDIR}/${BASENAME}_vc.m4a" splitAudioTrack myrecording.mkv これを使って、Fallguysの60fps, 15分程度の録画ファイルを分割してみたけれど、ストレージが録画用のHDDなのが悪いのか、変換に実時間程度かかってしまうことがあった (ffmpegは、Windows 10上でWindowsバイナリとWSL2上のLinuxバイナリをそれぞれ試したけれど、速度はほぼ同じだった)。 場合によって、4倍速から7倍速で分割できることもある。Windows Defenderとか、Search Indexerとかが悪さをしているのかもしれない。 FPSも、実際に60フレームを正確に掴めてはいないと思うし、容量や処理時間と映像品質の間でコスパが悪いと思うので、30fpsに落とすと速くなりそうではある。 1度分割すれば好きな動画編集ソフト上で、各ファイルをトラック(レイヤー)に配置して好きにできるけれど、分割に時間がかかるのはうれしくない…。 分割ファイルができることによって容量が2倍になるのもうれしくない…。 ...

2022年4月23日 · aoirint

自宅サーバのWebサービスをVPSで中継するようにした

これまで自宅サーバへの外部からの接続には、 数年前から自宅のグローバルIPアドレスにフリーのドメインを紐づけて使っていたのですが、 3月末に更新を忘れてこのドメインを失効させてしまいました。 自宅サーバでは、主に個人用のWebサービスや身内用のゲームサーバが動いています。 同じドメインを再取得するには追加の料金がかかりますし、(若干用途が規約的に怪しいこともあり)新しくドメインを取り直す気にもなれなかったので、 以前から契約していたVPSをTCP/UDPプロキシとして使ってみることにしました。 この記事では、nginx.confのhttpディレクティブとstreamディレクティブそれぞれについて、拡張子でincludeを切り分けるようにする構成にしています。 基本的には、nginx.confに以下のように記述するイメージです。 http { include /etc/nginx/conf.d/*.http; } stream { include /etc/nginx/conf.d/*.stream; } 関連ツイート https://twitter.com/aoirint/status/1510309731642257408 https://twitter.com/aoirint/status/1511896279731040261 また、この記事の内容には関係ありませんが、envsubstでconfigファイルに環境変数を注入する、nginxのDocker Hub公式Dockerイメージのtemplate機能を使用しているため、 nginx設定ファイルの拡張子がtemplateになっています。 上のツイートに関連して、certbot --nginxで自動生成される/etc/letsencrypt/options-ssl-nginx.confを手動でnginx.confに統合しているので、 以下の設定ではコメントアウトされているincludeがあります。 構成 自宅サーバ側:systemd + autosshによる自動SSH接続&リモートポート転送 VPS側:nginxによるHTTPリバースプロキシ・UDPプロキシ 自宅サーバ側 ~/.ssh/config Host vps* HostName VPS_IPADDR Port VPS_SSH_PORT ServerAliveInterval 10 ServerAliveCountMax 5 TCPKeepAlive yes IdentitiesOnly yes IdentityFile ~/.ssh/vps Host vps-forwarding-homeserver # SERVICE1 RemoteForward 127.0.0.1:VPS_SERVICE1_PORT 127.0.0.1:LOCAL_SERVICE1_PORT # SERVICE2 RemoteForward 127.0.0.1:VPS_SERVICE2_PORT 127.0.0.1:LOCAL_SERVICE2_PORT /etc/systemd/system/autossh-vps.service [Unit] Description=AutoSSH VPS [Service] Type=simple Restart=always User=user Group=user WorkingDirectory=/home/user ExecStart=/usr/bin/autossh -N vps-forwarding-homeserver [Install] WantedBy=multi-user.target VPS側 HTTPリバースプロキシ(SSHポート転送使用): myservice.http.template server { server_name myservice.example.com; client_max_body_size 500M; add_header Strict-Transport-Security 'max-age=15552000; includeSubDomains; preload'; location / { #auth_basic "Auth required"; #auth_basic_user_file /secrets/myservice.htpasswd; proxy_pass http://127.0.0.1:VPS_MYSERVICE_PORT; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; send_timeout 3600s; proxy_connect_timeout 3600s; proxy_send_timeout 3600s; proxy_read_timeout 3600s; #proxy_max_temp_file_size 2048m; } location /.well-known/acme-challenge/ { root /letsencrypt-webroot; } listen 443 ssl; ssl_certificate /etc/letsencrypt/live/myservice.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/myservice.example.com/privkey.pem; # include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; } server { if ($host = myservice.example.com) { return 301 https://$host$request_uri; } server_name myservice.example.com; listen 80; return 404; } UDPポート転送(SSHポート転送不使用): myserviceudp.stream.template server { listen VPS_SERVICEUDP_PORT udp reuseport; proxy_pass HOME_IPADDR:HOME_SERVICEUDP_PORT; proxy_connect_timeout 3600s; proxy_timeout 3600s; #proxy_max_temp_file_size 2048m; }

2022年4月7日 · aoirint

KFCのフリー写真素材

https://twitter.com/kfcarabia/status/1491779797038428161 https://chickenstock.net/ KFC(ケンタッキー)のチキンやハンバーガーなどの写真が公開されている。 自社商品の販促のためにケンタッキーの商品写真を利用している店舗への牽制らしい。 Free of chargeで使える。

2022年3月30日 · aoirint

CDの取り込み

Ubuntu Rhythmboxで取り込む。 ogg形式に変更する。 EasyTagを使ってID3タグ、アルバムアートを設定する。 Windows Windows Media Playerで取り込む。 初期設定が低ビットレートのMP3になっているので、320kbpsのMP3に変更する。 MP3Tag 2.88aを使ってID3タグ、アルバムアートを設定する。 (Windows版EasyTag 2.4.3は日本語が文字化けしてID3タグの書き込みが動作しないことがある)

2022年3月30日 · aoirint

ボイスコネクト2に一般参加してきました

ボイスコネクト:VOICEROID、CeVIO中心の同人即売会。 https://twitter.com/voiceconnect_ad ボイスコネクト2戦利品! — aoirint🎐 (@aoirint) March 27, 2022 参加動機 ボイスロイド文化圏(ソフトウェアトーク文化圏)にこの1年で浸かった VOICEROID劇場・遊劇場・実況、ふにんがす、なのそん、VOICEROID投稿者の生放送、etc Seiren Voiceのデモ体験をしたかった VOICEVOXでお世話になっているヒホさん(ヒロシバさん)の数年来の努力&お仕事の成果を応援したい この文化圏に来た端緒はDeNAの声変換技術の七声ニーナの影響が少なからずある=声変換技術への興味がある 何かしらの同人即売会に参加してみたかった いわゆる同人即売会(コミケとか)に一度も参加したことがなかった(似ているものといえば、技術系の展示会くらい?) 感想 今回の参加体験はとてもよかった。次回もよい体験ができることを願っています。 同じものが好きな人が集まる場所って面白いなと思った。 ヒホさんに挨拶できてよかった(まあ忙しかっただろうし、覚えてないと思うけど…)。 即売会は、同好の士の社交の場という認識を強くした。まあわたしはこの文化圏に対して独自の成果物がある身ではなくファン目線なので、若干肩身が狭いけれど…。 蒲田 Seiren Voice Seirenの列 — aoirint🎐 (@aoirint) March 27, 2022 あとで書く! 収集管理について Todoistのカンバンを使って、ブースの種類別にセクションを分類して、各サークルをサークル名とブース名でタスク化、各頒布物の名前と価格をサブタスク化して管理した。 途中、移動中に間違って操作されて状態管理がめちゃくちゃになったので、なにもわからなくなったけど・・・。 頒布物の収集について SeirenVoiceのデモがなければ参加していなかったと思うし、参加登録も(SeirenVoice発表後の)前日~前々日くらいで2部構成の2部参加だったので、頒布物の収集ははじめからある意味で手に入ったらラッキーくらいのおまけだった。(もちろん好きなので、ほしいことはほしいが)。 まあ次回があるかもしれんし、ワンチャン委託が出る可能性もあるし、Twitterでイラストあげてくれるし…。 これからも手に入ったらラッキーくらいで考えていくといいと思った。 釣銭について 現金は参加の前から、これは交換チケットだな、と思った。 頒布物は、釣銭問題(お釣りが発生すると大量の釣銭の準備が必要または釣銭が不足する)を起こさないためにキリのいい頒布価格になっていることが多いという事前知識はあった。 今回の一般参加にあたっては、100ポイントと500ポイントと1000ポイントの交換チケットがそれぞれ何枚ある、として、各サークルでの収集物と、その支払いに使う券の種類を事前に決めた上で、一切お釣りが発生しないように計画を立てていた。 サークルを巡る順番を厳密に決めること、確実に目的の頒布物を収集すること、は困難で、特に初参加かつ準備時間が限られた自分には不可能だった。釣銭の概念を捨てることで、それぞれが支払いに影響しないという利点を得られるという考えがあった。 釣銭については、前夜にTwitterでサークル参加者の発言を検索して何かお願いが出ていないかも探した。それは特に見つけられなかったが、この頃は銀行の硬貨取り扱い手数料が上がる傾向になっていることを踏まえて、釣銭を発生させないこと、の次に、紙幣が使えるなら紙幣を使うことを計画していた。 まあ最悪、何忘れても参加証(スマートフォン)と財布だけは持って行けよ、というようなツイートもあったので、余裕があるときの気遣いくらいで、気楽に構えることができた。 結果的には、終盤に計画外の追加収集をしたことで1度釣銭を発生させる取引をしたけれど、終盤であったこと、集まりやすいだろう500円の釣銭であったこと、頒布物的に紙幣の支払いが発生するサークルであったこと、から大丈夫だろうと判断した。 小銭の用意について 今回はたまたま500円玉と100円玉の持ち合わせが多くて、1000円札で引き出して、分散させつつちょっと崩すくらいで済ませられた。 まあ銀行で両替するのが安牌だけれど、平日昼間しか取り扱いしていなかったし、手数料結構するしで難しい。 普段の取引は95%くらいキャッシュレスなので、まともに現金を使ったのはすごく久しぶりな気がした。 現金を使うのは、キャッシュレス非対応の自動販売機とか、ごはん屋さんとか、コンビニプリンターくらいか。 次回の参加に備えて、すこしずつ集めていくのが一番いい気がした。 サークルチェック ソフトウェアトーク動画投稿祭応援しまくる祭(ニコニコ公式生放送)

2022年3月28日 · aoirint

ボイコネ2いきたい

ボイコネ2いきたい https://twitter.com/voiceconnect_ad

2022年3月26日 · aoirint

Windows 11 評価版を入手する

以下のリンクから、各仮想化ソフトウェア向けのVMを入手できる。 https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/

2022年3月18日 · aoirint

はてなブログから古い記事を移した

新しい記事 blog.aoirint.com へ投稿しつつ、 古い記事は aoirint.hatenablog.com に残っていましたが、 古い記事を blog.aoirint.com に移しました。 古い記事にはリダイレクトと移動先へのリンクを設置しています。 https://github.com/x-motemen/blogsync blogsyncで記事を取得したあと、以下のようなスクリプトでfrontmatterを変換しました。 以前の移行時の作業ミスでMarkdown記事がHTMLになってしまっていたので、 手動でMarkdownに書き戻しました。 import glob import yaml from datetime import datetime from pathlib import Path import frontmatter as FM for path in glob.glob('**/*.md', recursive=True): if path.startswith('output'): continue print(path) with open(path, 'r') as fp: frontmatter = FM.load(fp) # docs = yaml.safe_load_all(fp) # frontmatter = next(docs) # body = next(docs) body = frontmatter.content print(frontmatter) print(body) title = frontmatter['Title'] if title.startswith('(移動済)'): print(f'Skipped: {title}') continue print(f'Processing: {title}') original_url = frontmatter['URL'] date: datetime = frontmatter['Date'] draft = frontmatter.get('Draft', False) tags = frontmatter.get('Category') category = tags[0] if tags else None new_frontmatter = { 'title': title, 'date': date.strftime('%Y-%m-%d %H:%M:%S'), 'draft': draft, 'channel': '技術ノート', } if category: new_frontmatter['category'] = category if tags: new_frontmatter['tags'] = tags output = yaml.dump(new_frontmatter, default_flow_style=False, sort_keys=False, allow_unicode=True) output_lines = output.split('\n') output_lines.insert(0, f'---') output_lines.insert(1, f'# moved from {original_url}') output_lines.insert(-1, f'---') output = '\n'.join(output_lines) output += f'# {title}\n\n' + body + '\n' dest = Path('output', path) dest.parent.mkdir(parents=True, exist_ok=True) with open(dest, 'w') as fp: fp.write(output)

2022年2月22日 · aoirint

えやみぐさの改修ログ 2022-02-20

えやみぐさ: blog.aoirint.com えやみぐさのGatsby設定ファイルのTypeScript化 レイアウト用の型定義をgatsby-nodeやgatsby-configで利用するために、これらのGatsby設定ファイルをTypeScript化することになりました。 以下の記事が参考になりました。 https://miyauchi.dev/ja/posts/gatsby-typescript/ えやみぐさに「チャンネル」機能を追加 トピックの異なる記事を分離するために、「チャンネル」という単位で記事を分類するようにしました。 これまで、えやみぐさの記事は、カテゴリとタグによって分類していました。 しかし、この2つだけでは、例えば日記と技術記事の記事一覧を分離することができません(RSSや最近の記事一覧で問題になる)。 えやみぐさに異なるトピック・ジャンルの記事を統合するために、既存のカテゴリとタグによる分類を維持し、新しい階層を加えることにしました。 これまでのカテゴリ・タグは、チャンネル別に機能するようにしました。 いまのところ、この記事は作業ログというチャンネルに属しています。 通常の技術ノートに比べて、気軽にページを作ることができるようにと考えています。 あとで内容の一部を技術ノートに移す・写すこともあるかもしれません。 現在の技術ノートはあまり品質がよくない(メモ書きレベル)ので、作業ログに移してもいいかなと思っているのですが、そこそこ記事数があり、 中身を確認しながら再分類するのが手間なのでやっていません。 作業ログは、作業を中断したり、力尽きたりしたりして、中途半端な内容や矛盾した文章が載っていることがあるかもしれませんが、自分用のメモなので気にしないでいきたいと思っています。 えやみぐさの記事管理方法とURLフォーマットについて えやみぐさでは、記事のURLをentry/<作成年>/<slug>というフォーマットにしています。 このフォーマットは、えやみぐさの記事をファイルシステム上で管理しやすくするために選んだものです。 えやみぐさの記事を作成するときは、URLと対応したパスにディレクトリを作成し、index.mdファイルを配置します。 これは、記事に付随するリソース(画像や音声ファイルなど)と記事本体をまとめて管理するためにそうしています。 比較として、entry/<slug>方式では、ふつうに構成すると1ディレクトリにすべての記事ディレクトリを配置することになります。 例えば、2020年には下書きを含めて31件の記事があるのですが、 次の年も同じ数の記事を書いたとすると、計62件、その次の年なら計93件になることが予想されます。 昔書いた記事に補足を入れたいときや、新しい記事を書きたいときに、100件のサブディレクトリがあるディレクトリを操作するのは、 誤操作が起きやすい点、目に入る情報量が多く気が散る点から、望ましくない・苦手です。 entry/<作成年>/<作成月>/<slug>やentry/<作成年>/<作成月>/<作成日>/<slug>も考えられますが、 自分の記事作成ペースと、手作業で管理するのが手間に感じる点から採用しませんでした。 えやみぐさのURL永続性について インターネット上のURLは、永続化することが望ましいという考え方があります。 例えば、ブックマークしておいたページが消えていると困りますし、リンクが貼られているとリンク切れを起こしてしまいます。 記事のURLの永続化には、URLの割り当て方法が関わってきます。 ブログシステムでのURLの割り当て方法としては、 記事タイトルの一部などによる「スラグ」を利用する方法、 DB上の連番IDを利用する方法、 時刻や日付を利用する方法、 ランダムなIDを利用する方法、 が思い付きます。 えやみぐさでは、記事のURLをentry/<作成年>/<slug>というフォーマットにしています。 CMS・Wikiなどでは、URLを永続化するためにリダイレクトが自動で貼られる仕組みが用意されている場合がありますが、 えやみぐさのコンテンツ管理方式(GitリポジトリにMarkdownファイル)では、リダイレクトによってURLを永続化するのは難しく、 実装しても運用するのはそれなりの手間になります(例えば、リダイレクトだけの実体のない記事ページが記事ファイル一覧に含まれる、増え続けるリダイレクトリストの管理など)。 できるだけ記事URLを書き換えないようにしてはいますが、リンクが貼られにくい雑記については、 URL永続性を維持する動機がないので、適当に管理すると思います。 記事のURL名前空間は、チャンネル間で共通にしています(entry/slugのこと)。 えやみぐさでは、チャンネル・カテゴリ・タグのようなタクソノミーは、あとで書き換えることがある、という運用を考えています。 えやみぐさの記事一覧について これまで、えやみぐさのトップページでは、カテゴリの一覧と、各カテゴリの全記事リストを表示する方式をとっていました。 これは、過去に書いた技術記事を素早く参照するためのものでした。 この記事の執筆時点でも、技術記事用のチャンネル「技術ノート」では、同様の方式で記事一覧を表示するようにしています。 えやみぐさのデプロイ自動化について えやみぐさを管理するGitリポジトリは、Gatsbyプロジェクトリポジトリと記事リポジトリの2つに分かれています(submoduleで管理しています)。 記事の可搬性とレイアウト・記事の分離のためにそうしていますが、固有記法を使うこともあるかもしれませんし、 まああまり細かいところは気にしないで運用しています。 えやみぐさのデプロイは、GatsbyプロジェクトリポジトリにpushされたときにはGitHub Actionsが走りますが、 記事リポジトリにpushされたときには走りません。 記事を更新したときには、親のGatsbyプロジェクトリポジトリのsubmoduleを更新する手間があります。 Webサイトのレイアウトを調整すること、記事を更新すること、をうまく共存させながら、この手間を解消したいのですが、 あんまりいい方法が思い付いていません。。。 例えば、記事を書くときにいちいちGatsbyでレンダリングするのは重くて手間なので、Gatsbyプロジェクトをcloneせずに 記事を追加するような運用をしたいと思っていますが、 レイアウトをいじるときには実際の記事があった方がいい、というような感じで、どうしたらいいのかなと思っています。 workflow_dispatchをうまく組めば、片方のリポジトリが更新されたときにデプロイ走らせることはできると思うけれど、 ローカルで動かすときに微妙な気がしている… えやみぐさのデプロイにおける「2重コミット問題」を解消した 「2重コミット問題」:テーマリポジトリと記事リポジトリを分離するため、submoduleを使って管理するとき、submoduleと親リポジトリの2つにそれぞれコミットするのが手間になる問題 API経由でWorkflowを実行する。スコープの広いPATが必要なのが難しいところなので、抵抗あったのだけれど、まあ便利なので仕方がない。 ...

2022年2月20日 · aoirint