Blogging

技術ノートチャンネルには「具体的な解決策が見つかったものを報告・共有する記事」を載せたかったかもしれない。 わかりませんでした。いかがでしたか？　を避けたい。 でも、具体的な解決策がわからないんだけど、これどうしたらいいのか悩んでる、ということを共有する記事もほしい。 Twitterに投げるには分量が多いとか。 未解決タグを付ける方法はありそう？ でも20%くらい解決したんだけど…みたいな場合に中途半端な未解決タグが付きそう。 前の記事を参照して、解決策1個みつけたわ、みたいな記事があってもいいと思うんだけど、それが100%の解決策でなかったりする場合にベストアンサーではないよねみたいなことがある。 質問IDでも振って紐づけるか？？？ この記事にリンクしている記事一覧とかあればそれでいいのか？（実装が面倒かも？） まあタイトル詐欺しなければどういう運用しても別にいいのでは… 記事が増えすぎて質が落ちる・埋もれるかもしれんという問題はあるかも？ 先にJoplinとかScrapboxとかである程度整理してからの方が雑記事になりにくそう。 そういうのを作業ログチャンネルに入れたかったんだけど、なんだかんだそのレベルの文章をアップロードするのは面倒くさい。 記事としてのまとまりが悪くなりがちな気がする（話題があちこち飛んだり、矛盾した考えがあったりする）。 JoplinとかScrapboxに書くのがちょうどいい？　うーん。 https://blog.aoirint.com/entry/2022/pip_compile_metadata_generation_failed/ 上を書くにあたって、Joplinに下書きして、記事としてまとめたものを公開して、下書きをScrapboxに公開する、とバージョン違いのコピーが3個できた。 Joplin: コンセプトがはっきりしないMarkdownの下書き ブログ: 一応方針を固めたもの、Markdown Scrapbox: Joplinの下書きをScrapbox書式に修正したもの これがこういうバージョン違いなんですよ、ということを説明するDBがほしくなる。 バージョンの同期とか面倒だし、あんまりいろんなところに分散させたくないな、とは思うんだけど、いきなりScrapboxに書くのは軽重問わずセンシティブな情報が事故で公開されるということが起きそうで怖い。 でも正直、バージョン管理とか面倒なことを考えているのは無駄な気もする。 記事を書くモチベーションを上げたいんだけど、それとは関係ないのではと思った。 今回については、はじめは自分用のメモのつもりで書いていたけど、Joplinだとどんどん新しいノートが増えて埋もれるし、あんまり検索にヒットしなくて公益性があるなと思ったから記事化した。 埋もれることについては、だいたいキーワードを総当たりの文字列検索でなんとかなるんだけど、ちょっとしたメモ書きは整理するのが難しいし、Joplin上には1700ノートくらい、Evernoteにはツイートとかも保存しているから42000ノートくらいあって、この中に埋もれさせるのは微妙な感じがする… それよりも、SSGに10分かかるのが微妙。 あと、noindexした記事がGitHubの公開リポジトリを通じてGitHub Searchにひっかかったり、Googleにインデックスされる可能性があったり、いまの実装だとnoindexなのにサイトマップに送信されてしまったりが微妙。 雑記チャンネルは、検索性・一覧性を悪くするためにわざとタイトルを付けなかったり、複数の内容を1記事に収めたりしていたんだけど、古いやつをちょっと分割してみた。 粗探しをする人とかエゴサーチャーとか正義の晒し屋とか伝書鳩とかに見つかりにくくしたいんだけど、ある程度こなれてきたらいいのかなとちょっとだけ思った（麻痺）。

インストール 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

https://hexo.io/docs/#Installation npm install -g hexo-cli $ hexo help Usage: hexo <command> Commands: help Get help on a command. init Create a new Hexo folder. version Display version information. Global Options: --config Specify config file instead of using _config.yml --cwd Specify the CWD --debug Display all verbose messages in the terminal --draft Display draft posts --safe Disable all plugins and scripts --silent Hide output on console For more help, you can use 'hexo help [command]' for the detailed information or you can check the docs: http://hexo.io/docs/ hexo init <folder>は空のディレクトリに対して実行する必要がある。 いったん仮のディレクトリを作ってからコピーする。.github、.gitignoreファイルがあるのでコピー忘れに注意。 ...

https://hub.docker.com/_/wordpress docker-compose.yml version: "3.9" services: wordpress: image: wordpress:5.8.2-apache restart: always ports: - "${SERVER_PORT}:80" environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: wordpress volumes: - wordpress:/var/www/html db: image: mariadb:10.7 restart: always environment: MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress MYSQL_RANDOM_ROOT_PASSWORD: '1' volumes: - db:/var/lib/mysql volumes: wordpress: db: .env SERVER_PORT=127.0.0.1:8000

https://js.wiki/get-started 無料とは思えない多機能っぷりなWikiインフラ「Wiki.js」レビュー、自前でホスト＆外部サービスと連携可能 - GIGAZINE メモリ消費量 $ docker stats CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS e225b6b77209 wikijs_wiki_1 0.01% 127.6MiB / 7.681GiB 1.62% 13.1MB / 22.7MB 44.5MB / 1.45MB 11 13d085313406 wikijs_db_1 0.00% 44.57MiB / 7.681GiB 0.57% 6.64MB / 4.09MB 4.27MB / 102MB 8 初期状態で150-200MiB程度の消費量と思われる。 下記の環境をサーバとして、別端末からNATループバックによる接続を試したところ、ページ遷移時のロードや記事の保存に少しだけ時間がかかるように思われたが、Wikiサイト自体がなかなか開かない、というような重さではなかった。 CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz Memory: 8GB Storage: SSD OS: Ubuntu Desktop 18.04 docker-compose.yaml version: "3.9" services: db: image: postgres:13-alpine environment: POSTGRES_DB: wiki POSTGRES_PASSWORD: wikijsrocks POSTGRES_USER: wikijs restart: unless-stopped volumes: - db-data:/var/lib/postgresql/data wiki: image: requarks/wiki:2 depends_on: - db environment: DB_TYPE: postgres DB_HOST: db DB_PORT: 5432 DB_USER: wikijs DB_PASS: wikijsrocks DB_NAME: wiki restart: unless-stopped ports: - "127.0.0.1:8000:3000" volumes: db-data: https://hub.docker.com/r/requarks/wiki https://hub.docker.com/_/postgres 基本的に初期設定で問題ない。 ...

Python製のドキュメント生成ツール。 Python 3.8.5 Sphinx 3.4.2 Sphinx · PyPI pip3 install Sphinx reST（reStructuredText） SphinxではデフォルトでreStructuredTextというマークアップ言語を使う。 https://www.sphinx-doc.org/ja/master/usage/restructuredtext/basics.html https://atom.io/packages/language-restructuredtext 既存Pythonプロジェクトにドキュメントを追加する setup.py などが存在するPyPIパッケージプロジェクトを想定する。 プロジェクトのルートに docs ディレクトリを作成し、 インタラクティブツール sphinx-quickstart を実行する。 mkdir docs cd docs/ sphinx-quickstart Separate source and build directories (y/n) と聞かれるので、 y 。 プロジェクト名、著者名、言語などを答える。 source ディレクトリ、 build ディレクトリ、 Makefile が生成される。 make html 以上のコマンドで build/html ディレクトリにHTMLが生成される。 python3 -m http.server -b localhost -d build/html などで確認する。 次はPythonモジュールのdocstringからドキュメントを自動生成する。 Sphinx でPythonのAPIドキュメントを自動作成 - Qiita python書くなら絶対に使いたい2つのドキュメント生成ツール - Qiita #!/bin/bash SCRIPT_DIR=$(cd $(dirname $0); pwd) cd "${SCRIPT_DIR}" sphinx-apidoc -f -o "./source/api" "../mymodule" make html docs/mkdocs.sh を以上のように作成し、実行する（TODO：Makefileへの入れ込み）。 ここでは、以下のように docs ディレクトリと並んで、パッケージとして提供するPythonモジュール mymodule のディレクトリがあることを想定している。 なお、 docs/source/conf.py は設定ファイルであり、 例えば html_theme = 'sphinx_rtd_theme' のような設定を追加し、 pip3 install sphinx-rtd-theme してから make html することで、Read the Docsスタイルのドキュメントを生成できる。 ...

概要 新しく静的サイトジェネレータでブログ環境を整備した。 細かい使い方には触れないが、構成を書いておく。 静的サイトジェネレータとCI/CD 静的サイトジェネレータ 静的サイトジェネレータというのはSphinx（Python製）とかJekyll（Ruby製、GitHub Pages標準らしい）とかHugo（Go製）みたいなやつで、 MarkdownだとかreStructuredTextだとかのファイル群からHTMLを生成するツール。 Sphinx Jekyll Hugo Miyadaiku MiyadaikuはPython製の静的サイトジェネレータ。 Flaskで使うテンプレートエンジンのJinja2が使えることが特徴みたい。Jinja2はDjangoのテンプレートエンジンに似ている。 テンプレート上でどんな変数が使えるかはMiyadaikuの領域なので、ドキュメント（とサンプルテンプレート、ソースコード）を見ていくしかないかも。 github:miyadaiku/miyadaiku pypi:miyadaiku GitHub Actions GitHub上のリポジトリに対してpushやPull Requestがなされた時に事前に指定した処理を実行することのできるGitHubの機能。 Jenkinsなどに近そう。また、GitLabにも同様の機能があったはず。 GitHubのサーバで動く仮想環境上でDockerのような使い方でテストケースの実行やリリースファイルのビルド、サーバへのデプロイ、 つまりCI（Continuos Integration、テストやビルドの自動化）/CD（Continuous Delivery、デプロイの自動化）を設定できる。 Pull Requestなどへの自動ラベル付けやSlackへの通知なんかも設定することがあるのかな。 この設定はYAMLファイルとしてGitリポジトリ内に保存しますが、秘密鍵/トークンなどの情報を参照するための機能もあるみたい。 バージョン管理システム的な点ではGitは分散型なので文書自体の分散バージョン管理はできるが、 GitHubが落ちたら解消するまで（手元にリポジトリがあっても）GitHub ActionsによるCI/CDができないのが難点な気がする。 GitHub Status 考えていること レンダリング後のHTMLファイルの分離 Markdownを書いている時に見えるところに（レンダリング後の）HTMLファイルを置きたくない。 できれば何も考えずに（Markdownで書いた）メモファイルを置くのに使っていた適当なディレクトリの上でコマンドを実行したら HTTPサーバを介して（オプションで指定したテーマなどで）いい感じにレンダリングしてくれるようなものがいい （HTMLファイル自体にファイルシステムからアクセスできる必要はない）と思っていた。 このHTMLはMarkdownファイル群とレンダリングのオプションだけでいつでも生成可能なので、 レンダリング後のファイル自体が見えなければ、後からこのファイルを何かの間違いで編集してしまって正規性（再レンダリングしても差分がない状態）が崩れてしまうことがない。 それからMarkdownファイルをGitで管理する場合、レンダリング後のファイルの差分には実質的に意味がないので、（見える）commitに含めたくない気持ちがある。 この部分は適切に.gitignoreやCI/CDを設定すれば大抵の静的サイトジェネレータで実現可能だろうと思う。 今回はGitHub Actionsを使って、GitHub上の仮想環境にリポジトリから文書を読み込んでHTMLを自動生成し、文書と履歴を共有しない別ブランチ（gh-pages）に自動でcommitされるように設定する。 GitHub Actionsを動かすには.github/workflows以下にYAMLファイルを配置する。例えばこのような感じ。GitHub Pagesへのデプロイ（gh-pagesブランチの更新）にはgithub:peaceiris/actions-gh-pagesを使っている。 # deploy.yml name: Deploy # Controls when the action will run. Triggers the workflow on push or pull request # events but only for the master branch on: push: branches: [ master ] # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" build: # The type of runner that the job will run on runs-on: ubuntu-latest # Steps represent a sequence of tasks that will be executed as part of the job steps: # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: # Version range or exact version of a Python version to use, using SemVer's version range syntax. python-version: 3.x - name: Install dependencies run: pip3 install -r requirements.txt - name: Run miyadaiku-build run: miyadaiku-build --output public . - name: Deploy uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public name、runのところをコピーして増やせばコマンドを増やすことができる。 ...