技術ノート

えやみぐさ: 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が必要なのが難しいところなので、抵抗あったのだけれど、まあ便利なので仕方がない。 ...

構成 音声合成ソフト（A.I. VOICE、ガイノイドTalk、VOICEVOX） AssistantSeika 偽装ちゃん NiconamaCommentViewer 初回設定手順 上記ソフトウェアをダウンロード・インストール 音声合成ソフトを起動、起動完了を待つ（AssistantSeikaのドキュメントを参照して各ソフトが動作する状態になっているか、設定を確認） AssistantSeikaを起動、製品スキャンを実行、スキャン完了を待つ（1つ以上の音声合成ソフトが認識されていることを確認） 偽装ちゃんの実行ファイルFakeChan.exeをBouyomiChan.exeという名前でコピー BouyomiChan.exeから偽装ちゃんを起動 NiconamaCommentViewerを起動 メニューから「設定」を開き、「読み上げ」タブを開く。「コメント読み上げを使用する」にチェックを入れる。 設定項目から「棒読みちゃん」を選択し、「棒読みちゃんの場所」に先ほどコピーしたBouyomiChan.exeのパスを設定 適当な放送を選び、URLから放送番号（lv***という文字列)をコピー（URL全体でもOK）、NiconamaCommentViewerの放送番号入力欄に貼り付ける、「接続」ボタンを押す 2回目以降の手順 音声合成ソフトを起動、起動完了を待つ（AssistantSeikaのドキュメントを参照して各ソフトが動作する状態になっているか、設定を確認） AssistantSeikaを起動、製品スキャンを実行、スキャン完了を待つ（1つ以上の音声合成ソフトが認識されていることを確認） BouyomiChan.exeから偽装ちゃんを起動 NiconamaCommentViewerを起動 放送番号を入力、「接続」ボタンを押す 「読み上げ ON/OFF」ボタンが緑色（ONというラベル）になっている場合、押して灰色（OFFというラベル）にする

管理者PowerShellに以下を貼り付ける。 notepad C:\WINDOWS\system32\drivers\etc\hosts

管理者cmdで実行する。 ; ファイル mklink C:\link C:\original ; ディレクトリ mklink /D C:\link C:\original

コントロールパネルを開く。 「表示方法」が「カテゴリ」の場合、「日付、時刻、数値形式の変更」を開く。 「表示方法」が「小さいアイコン」の場合、「地域」を開く。 または、「ファイル名を指定して実行」から、intl.cplを実行する。 「追加の設定」を開き、「日付」タブを開く。 データ形式、短い形式、の欄にyyyy/MM/dd dddを入力して適用する。 https://laboradian.com/show-day-of-week-on-taskbar-win10/ https://atmarkit.itmedia.co.jp/ait/articles/1404/25/news058.html

psql --user myuser postgres ALTER ROLE myuser WITH PASSWORD 'new_password'; https://www.postgresql.jp/document/13/html/sql-alterrole.html https://www.postgresql.org/docs/13/sql-alterrole.html https://stackoverflow.com/questions/12720967/how-to-change-postgresql-user-password

psql --user myuser postgres ALTER DATABASE mydatabase RENAME TO new_mydatabase; https://www.postgresql.jp/document/13/html/sql-alterdatabase.html https://www.postgresql.org/docs/13/sql-alterdatabase.html https://www.postgresqltutorial.com/postgresql-rename-database/

インストール Docker Hub公式のDockerイメージが公開されている。 Mediawiki - Official Image | Docker Hub 事前準備 docker-compose.yml version: '3.8' services: mediawiki: image: mediawiki:1.37 restart: always ports: - '127.0.0.1:8000:80' links: - database volumes: - ./app/images:/var/www/html/images # After initial setup, download LocalSettings.php to the same directory as # this yaml and uncomment the following line and use compose to restart # the mediawiki service # - ./LocalSettings.php:/var/www/html/LocalSettings.php # - ./app/extensions:/var/www/html/extensions # This key also defines the name of the database host used during setup instead of the default "localhost" database: image: mariadb:10.7 restart: always volumes: - database-data:/var/lib/mysql environment: # @see https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/DefaultSettings.php MYSQL_DATABASE: my_wiki MYSQL_USER: wikiuser MYSQL_PASSWORD: example MYSQL_RANDOM_ROOT_PASSWORD: 'yes' volumes: database-data: nginx設定ファイル (/etc/nginx/sites-enabled/wiki.example.com.conf） server { server_name wiki.example.com; 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; # auth_basic "Authentication Required"; # auth_basic_user_file /path/to/.htpasswd; location / { proxy_pass http://localhost:8000; } } 手順 docker-compose.yml、nginx設定ファイルを作成 必要に応じてsudo certbot --nginxでHTTPS対応 添付ファイルのアップロード先ディレクトリを作成 mkdir -p app/images docker-compose up -dでMediaWikiを起動 起動時にwikiexamplecom_mediawiki_1 is up-to-dateのようなログが表示されるので、isより前のMediaWikiコンテナ名を控える ブラウザから初期設定 設定ファイルLocalSettings.phpをコピー sudo docker cp MediaWikiコンテナ名:/var/www/html/LocalSettings.php ./LocalSettings.php 拡張機能をコピー sudo docker cp MediaWikiコンテナ名:/var/www/html/extensions ./app/extensions docker-compose.ymlを開き、./LocalSettings.php、./app/extensionsのコメントアウトを解除 コンテナを再作成 sudo docker-compose up -d --force-recreate 拡張機能のインストール インストール手順 拡張機能の配布ファイル（tar.gz）をサーバにダウンロード 配布ファイルを展開 展開した拡張機能ディレクトリをapp/extensions以下にコピー（app/extensions/Mathのように） Dockerコンテナ内では/var/www/html/extensions/Mathのように配置される LocalSettings.phpにwfLoadExtension( '拡張機能ディレクトリ名' );のように追記 wfLoadExtension( 'Math' ); wfLoadExtension( 'SyntaxHighlight_GeSHi' ); 「メンテナンス：再起動」を実行 「メンテナンス：データベース構造の更新」を実行 数式（Math） Extension:Math - MediaWiki Download MediaWiki extension - MediaWiki シンタックスハイライト（SyntaxHighlight） Extension:SyntaxHighlight - MediaWiki Download MediaWiki extension - MediaWiki 設定 ロゴを変更 ロゴ変更 LocalSettings.php ## The URL paths to the logo. Make sure you change this from the default, ## or else you'll overwrite your logo when you upgrade! #$wgLogos = [ '1x' => "$wgResourceBasePath/resources/assets/wiki.png" ]; $wgLogos = [ '1x' => "$wgResourceBasePath/images/logo.png" ]; ロゴ変更 手順 LocalSettings.phpを編集 ロゴ画像をapp/images/logo.pngに配置 「メンテナンス：再起動」を実行 既定のタイムゾーンを変更 Manual:Timezone - MediaWiki タイムゾーン変更 LocalSettings.php # Time zone #$wgLocaltimezone = "UTC"; $wgLocaltimezone = "Asia/Tokyo"; タイムゾーン変更 手順 LocalSettings.phpを編集 「メンテナンス：再起動」を実行 メンテナンス 再起動 sudo docker-compose up -d --force-recreate データベース構造の更新 Manual:update.php - MediaWiki sudo docker-compose exec -u 1000 mediawiki php maintenance/update.php

Ubuntu 20.04にアップデートしてから、ネットワーク設定の変更時（接続のON/OFFなど）にSystem policy prevents control of network connectionsと表示され、認証を要求されるようになりました。 ここまではまだいいのですが、認証が表示されるたびに数秒間デスクトップがハングする状態になっていて、ストレスでした。 Keyringのロックを解除するときも数秒間ハングするので、似た原因がありそうです。 ひとまず、設定変更時の認証を要求されないようにして、ハングを防ぐことを試みました。結果として試みは成功し、ハングを回避できるようになりました。 https://unix.stackexchange.com/questions/534469/system-policy-prevents-control-of-network-connections https://code.luasoftware.com/tutorials/linux/ubuntu-prompt-system-policy-prevents-modification-of-network-settings-for-all-users/ /etc/polkit-1/localauthority/50-local.d/50-allow-network-manager.pkla [Allow Network Manager all Users] Identity=unix-user:* Action=org.freedesktop.NetworkManager.settings.modify.system;org.freedesktop.NetworkManager.network-control ResultAny=no ResultInactive=no ResultActive=yes systemctl restart network-manager.service

https://qiita.com/yakitatata/items/b2203f90defcad68bb9f NVIDIAドライバのrunfileをダウンロードする（インストール済みのバージョンと合わせる）。 ドライバ: https://www.nvidia.co.jp/Download/Find.aspx?lang=jp ディレクトリに展開する。 chmod +x NVIDIA-Linux-x86_64-495.29.05.run ./NVIDIA-Linux-x86_64-495.29.05.run -x sudo chown -R root:root NVIDIA-Linux-x86_64-495.29.05/ sudo mv NVIDIA-Linux-x86_64-495.29.05 /opt/ /etc/ld.so.conf.d/nvidia-32bit.conf 32bitライブラリの入ったディレクトリをldに読み込ませるようにする。 /opt/NVIDIA-Linux-x86_64-495.29.05/32 再起動する。 sudo ldconfig sudo reboot