開発環境 on 或る阿呆の記

LAN内のGiteaをCloudflare Tunnel経由で公開する

Tue, 11 Nov 2025 00:00:00 +0900

LAN内でええやんと思っていたのだが、色々と面倒臭くなったので、結局外部公開する。例によってCloudflare Tunnel経由で……。

環境

M2 Pro Mac mini, Intel Mac mini 2018
macOS 14.7.7 (Sonoma)
gitea 1.24.5 (via brew)
brew services start giteaで起動

構成

graph TD
cfi(Cloudflare)
cfi --> cf
subgraph LAN
cf(Cloudflare Tunnel)
gitea(Gitea)
end
cf -->|プライベートIP| gitea

Giteaから見るとリバースプロキシを噛ませたような感じになる。

手順

サインアップの禁止

あわせて読みたい

Gitea on Macのサインアップ（登録）を禁止する

/gitea-on-mac-signup/

既存リポジトリを最新に反映する

remoteと差分があると面倒くさくなるので、できるだけ最新を反映しておく。

Web画面の設定

Cloudflare TunnelでWebの外部公開用のサブドメインを作成する。

app.iniの[server]より以下となるようにする。

項目	値	説明
`PROTOCOL`	`http`	CloudflareがHTTPSを終端
`HTTP_ADDR`（または`DOMAIN`）	`127.0.0.1`	Giteaが実際に待ち受けるアドレス
`HTTP_PORT`	`3000`	内部ポート（自由）
`ROOT_URL`	`https://git.example.com/`	外部公開URL

https経由ではこれでできる。

（やるなら）sshの設定

sshを使う場合、Cloudflareでssh用の別口のサブドメインを作成し、ssh over httpsでアクセスする。Web用の設定と併せて以下のような感じになる。

[server]
PROTOCOL = http
DOMAIN = 127.0.0.1
HTTP_PORT = Web用ポート
ROOT_URL = https://Web用ドメイン
DISABLE_SSH = false
START_SSH_SERVER = true
SSH_DOMAIN = SSH用ドメイン
SSH_PORT = 22
LFS_START_SERVER = true
LFS_JWT_SECRET = hoge
OFFLINE_MODE = false

サーバーは再起動する。

クライアント側でover httpsをとなるように ~/.ssh/configに以下を入れる。

Host SSH用ドメイン
 ProxyCommand cloudflared access ssh --hostname %h
 User SSHユーザ名

既存のリポジトリでremote変更

現在の設定の確認。

git remove -v

これを置き換える。Web画面からリポジトリを見て、ssh用のcloneコマンドから以下のように置き換え。

git remote set-url origin SSHユーザ名@SSHドメイン:user/repo.git

動作確認。

git fetch origin
git push origin main

リモートにコミットがあってマージするなら git pull --rebase origin master、強制的に上書きするときはgit push -f。

Gitea on Macのサインアップ（登録）を禁止する

Wed, 29 Oct 2025 13:05:37 +0900

大した内容ではない。GiteaをずっとLAN内で運用していたが、やはりそれだと不便なので外部公開の必要を感じた。とはいえお一人様なのでサインアップはさせたくない。ので、設定するだけ。

環境

M2 Pro Mac mini, Intel Mac mini 2018
macOS 14.7.7 (Sonoma)
gitea 1.24.5 (via brew)
brew services start giteaで起動

手順

まず現状を確認する。右上に登録がある。

これを殺す。とりあえずサービスを止める。

brew services stop gitea

app.iniを書き換える。brew servicesを使っている場合はps axでわかるとおり以下となる。

58271 ?? S 0:00.75 /opt/homebrew/opt/gitea/bin/gitea web --work-path /opt/homebrew/var/gitea

そんなわけで以下を編集する。

emacs /opt/homebrew/var/gitea/custom/conf/app.ini

そうしたら[service]セクションより以下の項目を操作する。

[service]
DISABLE_REGISTRATION = true

いけたらサービス再起動。

brew services start gitea

Web画面を確認する。

右上から「登録」が消えていることを確認。これでOK。

Homebrew環境におけるGiteaのエクスポート：brew services start giteaとgitea webの違いがわかる男

Fri, 12 Sep 2025 00:00:00 +0900

なんか色々躓いたので、復元は後日にして、今回はエクスポートについてのみ。なんか色々ハマった。

具体的には、最初に gitea web で動かして、その後 brew services start giteaのほうがいいやんけと思ってそっちにしたんだが、その後バックアップ手順を確認しようと gitea dumpしたら、なぜか最初に gitea web で作ったほうがバックアップされる。よく見たら実行プログラムのパスが違っており、それによって読み込まれる設定ファイルが違ったと思われる。

環境

M2 Pro Mac mini, Intel Mac mini 2018
macOS 14.7.7 (Sonoma)
gitea 1.24.5 (via brew)
brew services start giteaで起動

giteaが分裂した。

公式: Backup and Restore | Gitea Documentation

公式にあるとおり、エクスポートはコマンドが用意されており、 gitea dump -c /path/to/app.iniに尽きる。ただここで問題は、 gitea のパスとコンフィグファイルのパスである。

たとえばコイツを見てくれ。コイツをどう思う？

> ps aux | grep -i gitea
user 19745 0.7 0.5 412867040 168992 ?? S 7:38PM 0:00.56 /opt/homebrew/opt/gitea/bin/gitea web --work-path /opt/homebrew/var/gitea

> which gitea
/opt/homebrew/bin/gitea

すごく……パスが違います……。

giteaコマンドは /opt/homebrew/bin/giteaなんだが、brewで起動する giteaは /opt/homebrew/opt/gitea/bin/giteaという。

ただ、こいつらはバイナリとしては同じ臭い。

> ls -la /opt/homebrew/bin/gitea 
/opt/homebrew/bin/gitea@ -> ../Cellar/gitea/1.24.5/bin/gitea
> ls -li /opt/homebrew/Cellar/gitea/1.24.5/bin/gitea
251898619 -r-xr-xr-x 1 user admin 107386178 Aug 14 01:34 

> ls -la /opt/homebrew/opt/gitea/bin/gitea
/opt/homebrew/opt/gitea/bin/gitea*
> ls -li /opt/homebrew/opt/gitea/bin/gitea
251898619 -r-xr-xr-x 1 user admin 107386178 Aug 14 01:34 /opt/homebrew/opt/gitea/bin/gitea*

なので、実行プログラムのパスで、読み込まれる暗黙のコンフィグパスが異なったものと思われる。brewで起動した方は、–work-pathを指定しているね。ここにコンフィグファイルもある。

パスの違いがわかる男

ということで、work-pathも踏まえて、dumpのコマンドは以下となる。停止できるなら停止したほうが安全だね。

brew services stop gitea
gitea dump -c /opt/homebrew/var/gitea/custom/conf/app.ini
brew services start gitea

ファイル名に日付けを入れるなら

gitea dump -c /opt/homebrew/var/gitea/custom/conf/app.ini -f gitea-backup-$(date +%Y%m%d-%H%M%S).zip

こいつをunzipすると以下のような感じだ。

gitea-backup-YYYYMMDD-HHMMSS.zip
├── app.ini # 設定ファイル
├── data/ # アプリケーションデータ
│ ├── attachments/ # 添付ファイル
│ ├── avatars/ # アバター画像
│ ├── gitea.db # データベースファイル
│ └── ...
├── repos/ # Gitリポジトリ
│ └── user/repo.git/ # 実際のGitリポジトリ
└── gitea-db.sql # データベースダンプ

このうち、app.iniは違うマシンでやるときにはゴチャゴチャと手動調整しないといけなくなると思う。ネットワーク環境とか、リポジトリのパスとか、環境によって変わるはずなので。特にMacからLinux……とかやるとね。

所感

サクッとできるだろうと思ったら思いのほか躓いた。LLMは永遠に存在しないパスを教えてくれるので10倍疲れた。インフラ周りになると途端に無能になるLLMさんェ……。それでもいるだけマシだろうと言われたらそうかもしれないんだが、昔は検索したら同じようなところで躓いた人の記事が出たもんだけどなぁと思ってしまう。

まぁ今回は brew services あんまり使ったことなかったから、それでちょっとハマったよね。自分でplist作ったら問題なかったんだろうけど。

今回はMacかつHomebrew経由特有の問題があったので、Dockerコンテナなら環境の共通化は多少できると思う。けど、ネットワーク環境とかはやっぱり違うだろうし、 app.iniは同一マシンでの復元以外は基本的に編集しないといけないんじゃないかな。となると、編集項目が1箇所でも5箇所でも、編集しないといけない時点で大して変わらないし、Docker使うと docker-compose.ymlの管理もあるから、どっちがいいかはちょっとわかんないね。

疲れたので、復元はまた後日。

<関連記事>

あわせて読みたい

脱GitHubに向けて：Giteaを試し始める on Mac

/github-gitea-1/

脱GitHubに向けて：Giteaを試し始める on Mac

Wed, 03 Sep 2025 17:22:19 +0900

最近のMSはまたMSになってきたので、GitHubもいつどうなるかわからない、ということで、コード管理をセルフホストにしていきたい。

環境とインストール

ひとまず手元のMacで動かす

M2 Pro Mac mini
Intel Mac mini 2018
macOS 14.7.7
gitea 1.24.5 via Homebrew

インストールは「Installation | Gitea Documentation」色々あるわけだが、楽なのでbrew install。もしVPSでやるときは、Linuxなのでまた考える。でも別に家のMac miniでいい気もしている。Dockerは特に使う必要性を感じなかったので使わない。データベースでSQLite以外使うならコンテナでまとめてやったほうがいいかなと思う。今回はデータベースもSQLiteでファイル管理するつもりだし、無駄にオーバーヘッド作る必要もないかなって。

（2025-09-11）この記事を書いた時はDockerいらんかなと思ったんだけれど、バックアップ/復元まで考えたときに、パスなど環境の差分がけっこうしんどい感じだった。Dockerのほうがその点は吸収できそうだが、ただ結局IPアドレスやポート番号など、差分はやはりあるし、docker-compose.ymlの管理もあるので、どちらが良いかは一概には言えないかなぁという感じ。

公式: Gitea Official Website

セットアップ

インストールしたら brew services start gitea で開始する。これはつまりgitea webをしてそれ用のplistも作って登録する感じなんだが、わざわざ自分で頑張る意味もないので、Homebrew勢は黙ってstart gitea。

そしたら、 http://<サーバのIPアドレス>:3000 にWebブラウザでアクセスして初期設定をする。

データベースはSQLite3にする。ファイルで管理したいから。
- Homebrewだとファイルパスの初期設定は /opt/homebrew/bin/data/gitea.db になるようだ
リポジトリのルートパス（リモートリポジトリのデータの実体）、LFSファイルパス（Large File Storage……でかいファイルは別におくようだ）はひとまず初期値で続行
サーバードメインはLAN内の固定したプライベートIPアドレスを割り当て
HTTPポートは3000使いたくないので変更
内部でしか使わないのでベースURLはサーバードメインとポートそのまま
オプション眺めたが、ひとまず初期値で続行

新しいURLで入り直すと、初期画面がある。

右上の登録から最初のユーザを登録する。これが管理者になる。

試す

リポジトリの作成とpull/push

とりあえずリポジトリを適当に作って試す。まずWeb画面上でリポジトリを作成する。宗教上の理由によりブランチ名をmain->masterにし、それ以外は初期値でGo。リポジトリはできた。

クローンする。

git clone http://<サーバアドレス>:<ポート>/<リポジトリ名>

cloneは可能。移動してpushまで試す。

(master)> touch hoge
(master)> git add hoge
(master)> git commit -m "first commit"
(master)> git push

user名とパスワードを求められるが、入力すればとおる。ふむ。

いったん作ったディレクトリを削除して、次にssh経由を試す。

ssh鍵

ssh鍵くらいは登録しておく。ここでは既存の公開鍵 id_rsa.pub を使う。

右上のプロフィールアイコンから「設定」
左メニューの「SSH/GPGキー」
SSHの「キーを追加」で id_rsa.pub の中身を登録

そしたら git clone ssh://ほげほげ でクローンする（適当）。入って適当にファイル作ってaddしてpushできるかを確認。特にパスワードを求められずに登録できたらOK。

その後気づいたのだが、Giteaはsshについてだいぶトリッキーなことをしているようで、~/.ssh/authorized_keysにcommandを記述している。で、リモートログインの時に支障をきたす。また、アンインストール時にはここの部分を削除しないといけない。

少しずつ試していく

ということで、今回はさらっと最低限のssh経由のpush/pullをやっただけだが、一応これだけでもローカル内にあるちょっとしたプロジェクトの管理には使える格好だ。とはいえ実際のバックアップ・復元手順なども確認する必要もあるし、GitHub Actionsみたいなことをしたくなったらどうなるんだろう、とかわからないことも多いので、これから少しずつ試していきたい。

Macでキーボードの挙動が変？VivaldiとVisualStudio Code でだけ Cmd + [ がきかない現象

Sat, 15 Mar 2025 09:57:36 +0900

何を言っているのか意味不明だと思うが僕も何が起きているのか意味不明だった。とりあえずなおったのでメモ。

環境

M2 Pro Mac mini
- ただし MBP 2019 でも起きていた
Vivaldi, VSCode

事象

一部のアプリ、具体的はVisualStudioCode、Vivaldiにおいて、Cmdキーを押すと [ キーを認識しないという謎の事象が発生していた。これはMacの再起動などではなおらない。

キーストローク自体はシステム全体では認識されており、Karabinerを使うと押されていることがわかるし、Braveなど別のアプリでは認識されているため、一部のアプリでのみ生じている問題だといえる。

Vivaldiにおいて、実際にDevToolsを起動してキーストロークを検出したところ、 [単体ならば問題ないが、Cmdキーを押した状態だと認識しないことがわかった。VisualStudioCodeも同様の状態だったと考えられる。

原因と対応

なぜ複数のアプリでこんなことになるのか意味不明で、ずっと僕の頭を悩ませていたが、以下の措置を実行したところ、なおった（？）。少なくとも事象は再現しなくなった（削除コマンドなので、一応バックアップはとっておくとよい）。

rm ~/Library/Preferences/com.apple.symbolichotkeys.plist

意味不明だったのでChatGPTに理由を聞いたところ、以下のような回答を得られたが、あまり納得していない。

ChatGPTによる回答

問題が解決したことから、macOSのシステム設定（symbolic hotkeys）が影響していた ことが明らかになりました。com.apple.symbolichotkeys.plist は、macOSのキーボードショートカット設定を管理するファイルであり、これが何らかの理由で Cmd + [ の入力を阻害していたと考えられます。

(ChatGPT) なぜ `com.apple.symbolichotkeys.plist` の削除で解決したのか？

1. `Cmd + [` がシステムレベルのホットキーに誤って割り当てられていた

com.apple.symbolichotkeys.plist には、Mission Control、アプリケーションスイッチャー、ウィンドウ管理などのショートカット設定が保存されている。
何らかの理由で、Cmd + [ がVivaldiやVSCodeでは動作しない形でシステムに割り当てられていた可能性がある。
rm でこのファイルを削除したことで、すべてのショートカット設定がリセットされ、デフォルトの挙動に戻った。

2. 設定が壊れていた / 予期せぬキー競合が発生していた

macOSアップデートや外部アプリの影響で、システムショートカット設定が壊れたり、不要な競合が発生したりすることがある。
特に、VSCodeやVivaldiは標準的なmacOSのUIではなく、独自のキーボードイベント処理を持っているため、壊れた設定が影響を与えやすい。

3. VivaldiとVSCodeで `Cmd + [` が特定の条件で無視されていた

システムの com.apple.symbolichotkeys.plist に Cmd + [ に関する設定が存在し、それが特定のアプリでのみ適用される 形になっていた可能性がある。
defaults read -g で確認できるようなグローバルショートカットではなく、個別のアプリに影響を与える設定だった可能性。

(ChatGPT) この問題の発生原因は？

過去に システム設定でショートカットをカスタマイズ したことがある
macOSのアップデートによる設定変更
外部アプリ（Karabiner、BetterTouchToolなど）の影響
何らかのバグや意図しないシステム設定の競合

いずれかが影響して Cmd + [ が特定のアプリで無効になっていたと考えられます。

(ChatGPT) 再発を防ぐためには？

「システム設定」→「キーボード」→「キーボードショートカット」で、意図しない割り当てがないか確認
影響を受けやすい com.apple.symbolichotkeys.plist のバックアップを定期的に取る cp ~/Library/Preferences/com.apple.symbolichotkeys.plist ~/Desktop/symbolichotkeys_backup.plist
再発した場合は、再度 rm ~/Library/Preferences/com.apple.symbolichotkeys.plist を実行
外部アプリ（Karabiner-Elements, BetterTouchTool, Alfredなど）の設定を見直す
macOSアップデート後にショートカットの挙動をチェック

(ChatGPT) 結論

この問題の根本原因は、macOSの com.apple.symbolichotkeys.plist に Cmd + [ の動作を妨げる何らかの設定が記録されていた ことです。このファイルを削除してリセットすることで、VivaldiやVSCodeで Cmd + [ のショートカットが正常に機能するようになりました。

この現象は比較的珍しいですが、macOSのショートカット設定が予期せず影響を及ぼすことは時々あります。同様の問題が再発した場合は、まず com.apple.symbolichotkeys.plist のリセットを試すのが最も確実な解決策となるでしょう。

所感

特に副作用らしきことも起きていない。事象が再発しなくなったのでよかったが、それにしても意味不明だなとは思っている。

こういうイレギュラーなことにおいて、ChatGPTは無力の極みなので、まともに聞くのではなく、とにかくそれらしい事象を検索させて、可能性がありそうなことを試すしかない。最終的にとりあえずなんとかなったので、よかったのかな。

NotionのMermaid記法でお絵かきするのが良いと伝える動画

Sat, 07 Dec 2024 12:09:35 +0900

姉とNotion談義していた時に、Mermaid記法を普及しようと思った。スクリーンレコードで動画をとって見せてみたが、「何が起きてるのかわからないｗ」と言われて撃沈した。まぁそうか……。

まぁでもせっかく撮影したので、なんとなく雰囲気を察せられる動画として残すだけの記事。

Notion & Mermaid記法の動画

動画は以下。

動画にしてしまうと記事文本文では言うことがない。言わなきゃ気づかないと思うけど、変換候補があれなのは固有名詞です笑

動画もアリか

今さらだけれど動画や音声をアップロードしていくのもアリかなと思った。本当に今さらだけど。

Macで最初に設定していること macOS 14 Sonoma版

Sun, 06 Oct 2024 05:37:03 +0900

自分用のメモ書き。前回からけっこう間がたったけど改訂。Sequoia？知らないな。コードネームどんどん覚えづらいやつにしてくるのなんなんよ。しかしなんだかんだMac使い始めてもうすぐ15年だよ。

Macの購入時とかクリーンインストール時のやることリスト。最近はもうクリーンインストールもあんまりやらなくなったけど。

あわせて読みたい

Macで最初に設定していること(macOS 10.14 mojave)

/mac-init-mojave/

(miniのみ) 外付けSSDを起動ディスクにする

ドケチなのでApple公式のクソ高CTOには付き合わない。以下の記事を参考に、外付けSSDを起動ディスクにする。さすがにラップトップではやらない。

あわせて読みたい

Mac mini 2018に外付けSSDをつけて起動ディスクにした

/mac-mini-2018-nvme-ssd-boot/

Blackmagic Disk Speed Testでベンチとっておく。

環境設定

サードパーティとか使わず、システム環境設定とかいじらないといけないやつ。スマート引用符とか地味に忘れていた。

キーボード、マウス

キーボードでキーリピート速める
キーボードでスマート引用符とスマートダッシュを使わないようにする
- Macで引用符を入力すると勝手に変換されるのをやめたい - ぴよログ
トラックパッドでタップでクリック、ポインタ速度速める
アクセシビリティからトラックパッドの3本指ドラッグ解禁

ネットワーク

ファイアウォールを「入」にする
- インストール時にホームディレクトリの暗号化まで推奨してきたのに、何故FWがデフォルトで「切」なんだ
ファイル共有を「入」にする
（サーバ用の場合）リモートログインを「入」にする
- 他のMacから入るための公開鍵を authorized_keys に登録する
- /etc/ssh/sshd_config をいじって PasswordAuthenticationを no にする

アプリケーションからのインストール

App Storeから

一時期流行りかけたけど、結局あまり定着しなかった。ただいくつかのソフトウェアはこっから入れている。

Xcode
QSpace Pro
- QSpaceからアップグレードする。確かライセンス2台だったので古い機種は削除がいるのかな
- ForkLiftは使いやすかったけどライセンス形態を実質サブスクに移行して許されなくなった
CotEditor
LanScan
Readkit
- ほぼ購読登録ソフトと化している
PopClip
Capo
Whisper Transcription

Webから

結局PCソフトはWebサイトからDLが王道なんだということを、10年かけてわからされた僕たち。

文字入力
- ATOK
- Karabiner-Elements
Web関係
- Brave
- Firefox
- Google Chrome
- DeepL
開発ツール
- Visual Studio Code
- Android Studio
- ChatGPT
- Cloudflare WARP
- Docker Desktop
- Figma
- Postman
- Raspberry Pi Imager
  - まぁ必要になったらでいいかも
- ApplePiBaker
  - ddコマンドよりはまぁ
- AWSCLI
  - いつのまにかbrewで管理できなくなった
- volta
  - いつも忘れそうになるが、うちのnode.jsバージョン管理はvolta
電子書籍
- Calibre
- Simple Comic
  - 2010年で更新止まってるけどMac用の漫画ビューアっていまだにこれが一番なんじゃなかろうか…
  - 検索すると変なサイト出るけど本家は「Dancing Tortoise | Simple Comic」GitHubにソースもある
- Kindle
メディア
- Vox for mac
- Steam
リモート
- Splash Streamer
オフィスソフト
- LibreOffice
ツール
- BetterTouchTool
- Clipy
- Logi Options+
- QR Journal
ファイル
- Adobe Acrobat DC
- Adobe Bridge
- Dropbox
- FreeFileSync
- QSync Client
デザイン
- Affinity Designer, Photo, Publisher 2
- Pixelmator Pro
  - 超解像をAutomatorで右クリックコマンドに組み込めるのが便利なので
コミュニケーション
- LINE
  - しゃーない
- Slack
- zoom
- Zoho Mail Desktop

Homebrewから

必要になった時に都度入れたらいいんだけどさ。

開発
- shellcheck
- emacs
- bash
- fish
  - メイン端末
- git
- poetry
- jq
- cliclick
- lazygit
- lazydocker
メディア
- imagemagick
- poppler
- ffmpeg
- youtube-dl
ファイル操作
- wget
- peco
- zip
- tree
- fzf

細かな設定

ターミナルの設定はなんだかんだ妙にこれで慣れてしまったので……。

NASの設定（「MacとReadyNAS 104の通信速度が遅い時の対処法(SMB)」）
fishの設定
- パスの設定、履歴数など
ターミナルの設定
- monaco 12pt.
- 背景黒
- Optionをメタキー
自分用binディレクトリのソフトリンクとパス設定

テキストで図を書けるWordPressのMermaidプラグインは最高だぜ

Wed, 08 May 2024 17:53:21 +0900

ブログ記事を書いていると、ちょっとした図を書きたくなることがある。だがブログ書きにとって、図は一つの鬼門である。というかめんどくさい。ただただめんどくさい。いくつかのコンポーネントを矢印で繋ぐ程度のしょっぱいシステム図を書くために、編集ソフトを起動し、エクスポートし、アップロードして貼り付けるのは苦行である。そんなことはやりたくない。

できるぞ、Mermaid記法なら。

救いのMermaidプラグイン

Mermaid記法とは図をテキストで記述するもので、図の種類によっては手で頑張って書くより余程楽に書ける。テキストであるため、最近ならばAIに下書きさせることも可能だ。Notionなんかも対応している。というかNotionで図を書く方法は標準的にはこれしかない（Draw.ioがブラウザで使えるエクステンション出していたりするが）。WordPressでもプラグインを導入してMermaid記法に対応することにより、手をキーボードから離すことなくブログで図を書くことができるというわけだ。

graph LR
hoge(Hoge)
fuga(Fuga)
db[(謎のデータベース)]
hoge -->|hogehoge| fuga
hoge -.- db

こんな感じでさらっと図が書ける。描けるじゃなくて書ける。正直これくらいの絵でも、あるのとないのとではわかりやすさが全然違うことはよくあるのだが、そうは言ってもこの程度の絵でも描くのは非常に面倒なので、ブログ記事だとついつい端折ってしまいがちである。でもテキストなら書ける。

Gutenbergとの相性よし

実際これは非常に便利で、手放せないプラグインの一つになった。また、このプラグインはブロックエディターであるGutenbergと非常に相性が良い。

Screenshot

このように/mermaidと記述するだけで、ブロックを呼び出してコードを書くことができる。これがクラシックエディタだとそうはいかない。

Gutenbergは出始めは全文コピペすらままならず阿鼻叫喚で、その時の印象が悪すぎたためにクラシックエディタをずっと使い続けていたのだが、ひたすら改良されていったようで、今はだいぶ使いやすくなった。箇条書きをシフトでインデントできない（スペースでできるけど……）のはなんとかしてもらいたいし、htmlコードのタグも複雑になってしまっている（REST APIで頑張ろうと思った時に壁になりそうなんだよなぁ）が、エディタとして使う分には良いと思う。

記法は覚える価値あり

Mermaid記法はテキストベースであるので、ChatGPTをはじめとする昨今の生成AIとは非常に相性が良い。言えばスニペットを書いてくれる。書いてくれるが、そもそも「編集ソフト起動するのめんどくせぇ」が根幹にあるわけで、当然「AIに聞くのもめんどくせぇ」のである。

したがって、いちいち調べながら書かずに、書きたい図が書ける程度には覚える必要はある。必要はあるが、これは気合いを入れて2,3時間ほどチュートリアルを頑張ればほぼほぼやりたいことはできるようになると思われる。

この知識はずっと使えるうえに実践的なので、学習コストという観点で見たとき、非常にコスパ・タイパに優れる。Mermaid記法はWordPressだけではなく、Notionで使えるし、拡張機能入れればVSCodeでも使える。テキストで書けるということはコード管理することも可能である。まぁあまり複雑な図を書くのには向いていないので、本格的にやるならそれ用のツールを使うべきだけれど、そんな図を書くことばかりじゃない、というか書きたい図の9割はドラフトだと思う。そんな9割の需要をMermaid記法は汲んでくれるのです。

ということで、WordPressでMermaidは最高だぜという記事でした。Mermaid記法は食わず嫌いの人が多いように思うのですが（というか自分がそうだった）、学習する価値はあるので是非やると良いと思います。使う人を増やしたい。自分はプラグインでWP Mermaid Plugin — WordPress.comを使っているのですが、もう一年ほどメンテされてないのですよね。良いプラグインだけれど、インストール数も1000+程度。使う人が増えればお金にもできるだろうしメンテナンス意欲も沸くはず……。

みんなで使おうMermaid。

WordPressでGutenbergを使うようになった

Sun, 22 Oct 2023 14:50:47 +0900

僕はずっとクラシックエディタを愛用していた。普通に文章を書くだけならそのほうが使いやすかったからだ。クラシックエディタが使いやすいというより、Gutenbergが使いづらかったというほうが正確だろう。特に最初の頃、全文コピペすら手間がかかったのには閉口した。箇条書きのインデントの挙動もタブやShift + Tabで思ったように動いてくれず、あまりよくない（これは今もそう）。

Gutenbergを使い始めた

しかし、そんな僕も今はGutenbergをメインで使うようになっている。クラシックエディタは過去記事を編集する時くらいにしか使わない。その時には、クラシックエディタを不便に思うこともある。

いくつかのプラグインが、従来のクラシックエディタよりも使いやすいことがGutenbergを使うようになった大きな理由だ。特にMermaid記法を使えるようになるプラグインは有り難かった。また、このブログは比較的プログラミングのネタもちょくちょくあるから、コードのシンタックスハイライトがやりやすいことも助かっている。Gutenbergのプラグインを使えばビジュアルエディタのままシームレスに作業することができるのは楽だ。クラシックエディタの時はコード部分だけhtmlで記述するなど涙ぐましいことをしていた。ギャラリー機能なんかも、ちょっと画像をリッチに貼りたい時には便利なものだと思った。

ということで、僕程度のブログ書きでも、Gutenbergの機能はちゃんと使ってみるとけっこう便利なものが多い。確かにまぁ、単なるテキストだけで完結しないことも多くなったこの時代、ブロックエディタは必要な進化だったのかなと、ようやく僕も感じるようになった。

クラシックエディタのほうが今なお使いやすい面もある

しかしそうは言っても、ただテキストを書いて、いくつかの画像を添えるだけならば、今なおクラシックエディタのほうが使いやすいこともまた事実だ。だからこそ僕は長いことクラシックエディタを使い続けてきたのだし、今でもクラシックエディタを愛好している人がいることはとても理解できる。

Gutenberg、箇条書きの挙動はそろそろなんとかならんものだろうか。やはりShiftを押したときにはインデントをしてほしい。ネストが深くなった時にあれこれ編集していると、意図しない挙動になることもままある。箇条書きはテキストにおいてはもっともよく使う機能の一つなので、これはけっこうストレスフルだ。

あとあまり使っている人はいないかもしれないのだが、REST APIなんか使って編集しようとした時、Gutenbergは独自のタグが多すぎてとてもついていけない。まぁREST APIユーザはどちらかというとWordPressをバックエンドとして使う人のためのものかもしれないが……。

WordPressの開発はたいへんだろうが、クラシックエディタのほうが明確に良いと言えるユースケースが存在する以上、サポートはまだまだ続けざるを得ないのではないだろうか。

WordPressいいよね……

とは言うものの、基本的にはGutenbergで良いんじゃないの、と思う程度には、Gutenbergも熟れたように思う。あとはもうちょっとMarkdownっぽいコマンドがきくといいんだけどな。Notion並の操作感にならんかな。などと勝手なことを言っているが、WordPressにまったく金を出していない身なので、正直使えるだけでも有り難い。

WordPressの素晴らしいところは、多くのホスティングサービスが存在するところだ。昔は自分でサーバたててブログ運営するのも楽しかったが、今となってはひたすらめんどくさいだけなので、ホスティングサービスが多数存在し、切磋琢磨しているのはただただ有り難い。インストールも楽だ。

僕はカラフルボックスというサービスを使っているのだが、一つの契約に複数のWordPressをのっけることもできるので、だいぶお得だと思う。GUIでサクッと作ったり壊したりできるから、サイトのスクラップ&ビルドも手軽にできる。実際、運用するサイトの数を増やすことができたのはホスティングサービスのおかげだ。まぁ可用性については微妙なところもあるが、99.5-99.9%くらいは出せているようだ。ちょいちょい落ちるけど。とはいえ、自分でPHPとかDBのアップグレードする作業を思えば楽すぎてもう。証明書の更新失敗とかもないし。

これだけ使いやすい体系を世界的に構築したWordPressには、ただただ頭が下がる。WordPressは良いものだ。

NotionはWebブラウザのほうが便利

Wed, 27 Sep 2023 23:18:07 +0900

最近あった良いこととして、会社でNotionを使えるようになったことがある。プライベートでも使っているツールを、チームとして使える経験をもらえたのは良いことだ。また幸いなことに、一定程度の影響力を行使できる立場にあるので、限定的ではあるけれど、Notionをフルに使って開発作業にあたることができている。

デスクトップアプリの出来はあまりよくない

Notionにはデスクトップアプリがある。昔からのPCユーザの感覚だと、専用アプリがあるならそちらのほうがいいに決まっているだろう、と思ってしまうのだが、Notionについては残念な結果だった。

UIなど、何から何までWebアプリ版と同じで、違うところと言えば複数タブが開けるところくらいだと思う。でもタブの入れ替えという基本的なことも出来ず、ブラウザのタブ機能よりハッキリ言って貧弱であるため、これが機能アップとは言いがたい。

あとはまぁスタンドアロンのアプリなので、Dockから多少呼び出すやすくなった。

以上がデスクトップアプリを使って良かったことのすべて。ネイティブのアプリならパフォーマンスなどに期待したいところだが、残念ながら別にはやくなる感じはない。

Webアプリには拡張機能がある

まぁそれでも多少なりともいいところがあるなら使えばいいんじゃないの？という考えもあるかもしれないが、残念ながら（？）Webアプリ版のほうにこそデスクトップ版にはない大きなメリットがある。それは拡張機能だ。

特にsvgを直接編集できるようになるDraw.ioのNotion向けChomeエクステンションはめちゃくちゃ強力だ。

https://chrome.google.com/webstore/detail/drawio-for-notion/plhaalebpkihaccllnkdaokdoeaokmle/related?hl=ja

これだけのためにWebブラウザ版使う価値がある。Notionの絵を描くにはMermaid記法しか使えないという大きな弱点を克服するものだ。プログラマはともかく、ビジネス層にMermaid記法で書いてくれとは言えないからねぇ。まぁそうでなくても、それなりに大きなアーキテクチャ図なんか、Mermaidで描いたらカオスだしね。カオスだった。

あと、個人的に最近使っているタイマーアプリTogglのエクステンションがNotionにも対応しているのがよかった。まだあんまり使いこなせてないけど。

ということで、拡張機能がある分Webアプリ版のほうがNotionについては明確に良い。

Webアプリにネイティブの皮を被せても……

まぁNotionに限らず、一時期からよく見かけるようになったWebアプリをそのまんまネイティブアプリにしたようなやつは、だいたいどれも拡張機能的な理由でWebアプリ版より劣る。アカウントの切り替えとかで多少の優位性があったりするが、それは拡張機能の不足を補えるものではない。開発費の関係でそうなってしまうんだろうなと思いつつ、だったらなくてええわ、というのがイチユーザとしての感触である。

むしろ、なまじっかWebアプリの出来がよいからこそ起きた悲劇なのかもしれない。EvernoteとかWebアプリ酷かったのに無理矢理UI統合して阿鼻叫喚だったからなぁ……今はもうよくなったのだろうか。

そんなこんなで、結局ブラウザ版のNotionを使っている。

久しぶりのGutenberg

Wed, 05 Jul 2023 17:54:58 +0900

いくつかの機能を試すために、久しぶりにGutenbergを起動している。中途半端ではあるがMarkdownも使えるし。

コード

コードの入力がどれだけ楽にできるか。クラシックエディタだと直接htmlを書かざるを得ず苦痛ではあった。

import boto3

def main():
 pass

if __name__ == '__main__':
 main()

テーマ変えたからシンタックスハイライトはされない。確かCDNでなんか入れたんだよな……。もはやそれも面倒くさい……プラグインをそのうちなんか入れよう……。

Mermaid記法

今回Gutenbergを使い始めようと思った理由の一つで、プラグインを入れたらいい感じでMermaid記法のブロックが使えるからだ。

graph LR
test(hoge)
test2(hoge2)
test --> test2

なるほど🤔

まぁ書きやすいといえば書きやすいか。tabキーでフォーカス外れるのはつらいけど……。

数式

まぁ今となってはあまり使うことはないのだが……。MathJaxを使っていたのだが、コードをいじってヘッダに直接つっこんでいたため、テーマを切り替えたタイミングで見事に死んだ。

あわせて読みたい

WordPressの数式表現はMathJaxが一等便利

/wordpress-mathjax/

まぁもう一回コード差し込んでもいいんだけど、、、僕は気づいたんだ。コードの修正は忘れるけど、プラグインを入れたことは忘れないことに……。運用を考えた時、プラグインに頼るほうが楽。

ということでMathJax-LaTeXプラグインを入れさせていただきました。。。既存のコードについて、無事きれいに表示されたのを確認。

そんでショートコードのlatexで囲んだら、インラインで表示される。

[latex]ax^2 + bx + c = 0[/latex]

表示されている。またちゃんと数式使うような仕事をしたいもんだね……。

使えそう

いくつか気になる機能について試してみたが、特に問題なさそう。個人的にはMermaidをブロックで書けるのがけっこうキラーアプリだった。このサイトはテキストがメインだから、クラシックエディタのほうが使いやすかったんだけれど、図示したいことは多いからね。Gutenberg使っていくか……。

GitHubのIssueの初期ラベルについて

Mon, 03 Apr 2023 13:07:10 +0900

GitHubのProjects機能を使ってタスク管理をしようとしている。そこで、Issueのラベルについても今一度整理しておこうと思った。で、ChatGPTに聞いた😂

真面目なことをやる時には真面目に役にたつな。

ラベル一覧

ラベル	意味
bug	バグがあることを示す。修正が必要な問題がある場合に使用される。
documentation	ドキュメンテーションに関する問題を示す。ドキュメンテーションが欠けている場合や改善が必要な場合に使用される。
duplicate	既に報告されている問題と重複していることを示す。同じ問題が複数回報告された場合に使用される。
enhancement	機能の改善や追加を示す。機能を追加することで問題が解決する場合や機能の改善が必要な場合に使用される。
good first issue	初めてのコントリビューションに適した問題を示す。新しいコントリビューターにとって、解決しやすい問題を見つけるのに役立つ。
help wanted	コントリビューターの助けを必要とする問題を示す。問題を解決するための手順が不明確な場合や、コントリビューターに知識やスキルが必要な場合に使用される。
invalid	不適切な問題報告であることを示す。報告された問題が実際には問題ではない場合に使用される。
question	質問に関する問題を示す。ユーザーが質問をしている場合や、問題についての追加情報を求める場合に使用される。
wontfix	問題を修正しないことを示す。問題が修正不可能である場合や、修正することが望ましくない場合に使用される。

ラベルの詳細

よくわからんものについて教えてもらった。

help wanted

help wantedとして、具体的にどのようなIssueがあるか例示をあげてください。

help wantedのラベルは、開発者がコントリビューションを提供するために、外部のユーザーやコミュニティからのサポートを必要としている問題を示すために使用されます。以下に、help wantedとして設定される可能性のあるIssueの例をいくつか挙げてみます。

バグ報告：バグが報告されており、開発者が問題を解決するために外部のユーザーやコミュニティのサポートを必要としている場合。
機能追加：新しい機能の追加が必要で、外部のユーザーやコミュニティのサポートを必要としている場合。
ドキュメンテーション：ドキュメンテーションの更新が必要で、開発者が外部のユーザーやコミュニティのサポートを必要としている場合。
テスト作成：新しい機能や修正のためのテスト作成が必要で、開発者が外部のユーザーやコミュニティのサポートを必要としている場合。
コードレビュー：新しい機能や修正のためのコードレビューが必要で、開発者が外部のユーザーやコミュニティのサポートを必要としている場合。

以上のように、help wantedとして設定される問題は、開発者が外部のユーザーやコミュニティのサポートを必要とする、幅広い種類の問題があります。

Q: そうすると、たとえば、運用やビジネス側の協力が必要なタスクなどはhelp wantedになる可能性が高いですか？

A: はい、運用やビジネス側の協力が必要なタスクも、help wantedとして設定される可能性があります。例えば、開発者が新しい機能を追加しようとしている場合、その機能がビジネス要件を満たしていることを確認するために、ビジネス側の協力が必要になる場合があります。同様に、アプリケーションの運用や監視に関する問題でも、運用チームやインフラストラクチャチームの協力が必要になる場合があります。このような場合、開発者はhelp wantedラベルを設定して、外部のユーザーやコミュニティからのサポートを求めることができます。ただし、help wantedのラベルは主にコード開発に関する問題に使用されるため、他のラベル（例えば、questionやdiscussionなど）も適切な場合があります。

invalid

invalidのラベルは、不適切な問題報告であることを示すために使用されます。以下に、invalidとして設定される可能性のあるIssueの例をいくつか挙げてみます。

開発者が再現できない問題：ユーザーが報告した問題を開発者が再現できなかった場合。問題が解決済みであるか、報告された問題があるわけではない可能性があるため、invalidとしてマークされる場合があります。
ドキュメンテーションの不備：ユーザーがドキュメンテーションに関する問題を報告した場合、報告内容が不十分である場合や、問題が実際には存在しない場合は、invalidとしてマークされる場合があります。
意図的な問題報告：ユーザーが意図的に問題を報告した場合。報告された問題が実際には問題ではない場合や、問題が意図的に作成された場合には、invalidとしてマークされる場合があります。
フィーチャーリクエスト：ユーザーがフィーチャーの追加を要望する問題を報告した場合。これは、既存の機能に関する問題ではなく、開発者が実装を検討する必要がある新しい機能の提案です。この場合、invalidとしてマークされる場合があります。
フォーラムの質問：ユーザーがフォーラムで質問をした場合。これは、Issueとして報告するべきではなく、フォーラムやコミュニティで回答されるべき質問です。この場合、invalidとしてマークされる場合があります。

以上のように、invalidとして設定される問題は、実際には問題ではない、あるいは報告の仕方が適切でない場合があります。ただし、適切な報告の仕方やIssueの種類について疑問がある場合には、開発者とのコミュニケーションが必要です。

good first issue

good first issueのラベルは、新しいコントリビューターがプロジェクトに貢献するための簡単な問題を示すために使用されます。以下に、good first issueとして設定される可能性のあるIssueの例をいくつか挙げてみます。

ドキュメンテーションの修正：プロジェクトのドキュメンテーションが不十分または誤っている場合、その修正を要求する問題。例えば、タイポの修正や文法の改善など。
テストの追加：既存の機能に対してテストを追加する問題。これは、新しい機能の実装よりも簡単で、コントリビューターがプロジェクトのテストスイートに貢献することができます。
バグの修正：プロジェクトで報告された単純なバグの修正を要求する問題。これは、プロジェクトにコントリビュートするために必要な最初のステップの1つです。
コードのリファクタリング：既存のコードのリファクタリングを要求する問題。これは、コントリビューターがコードベースに慣れている場合に実行できる作業であり、プロジェクトの改善につながります。
軽微な機能の追加：小規模な機能の追加を要求する問題。例えば、新しいボタンの追加や、新しいコマンドラインフラグの追加など。

以上のように、good first issueとして設定される問題は、新しいコントリビューターがプロジェクトに貢献するための簡単な問題が多く含まれています。これらの問題は、コントリビューターがプロジェクトに慣れて、より大規模な問題に取り組む準備をするための最初のステップとして非常に役立ちます。

Q: 社内プロジェクトで用いるリポジトリでは、新人のトレーニングに使える問題ですね。

A: はい、その通りです。社内プロジェクトで用いるリポジトリにおいて、good first issueとして設定される問題は、新しいコントリビューターや新人のトレーニングに役立ちます。これらの問題は、より大規模な問題に取り組むために必要なスキルを習得するのに適した、プロジェクトに参加する初心者にとって理想的なものです。

例えば、新人には、プロジェクトの構造やテスト、ドキュメンテーションの仕組みに慣れることが必要です。good first issueとして設定される問題には、既存のドキュメンテーションの修正や、新しいドキュメンテーションの追加、簡単なテストの追加、軽微なバグの修正、小規模な機能の追加などが含まれます。これらの問題に取り組むことで、新人はプロジェクトに慣れることができ、より大規模な問題に取り組むためのスキルを習得することができます。

また、good first issueとして設定される問題は、コントリビューターがプロジェクトに貢献するためのモチベーションを高めることができます。初心者でも解決できる簡単な問題があることで、コントリビューターは自信を持って、より大規模な問題に取り組むことができます。

したがって、社内プロジェクトで用いるリポジトリにおいて、good first issueとして設定される問題は、新人のトレーニングや、プロジェクトへの貢献を促すための重要な役割を果たします。

開発環境 on 或る阿呆の記

LAN内のGiteaをCloudflare Tunnel経由で公開する

環境

構成

手順

サインアップの禁止

既存リポジトリを最新に反映する

Web画面の設定

（やるなら）sshの設定

既存のリポジトリでremote変更

Gitea on Macのサインアップ（登録）を禁止する

環境

手順

Homebrew環境におけるGiteaのエクスポート：brew services start giteaとgitea webの違いがわかる男

環境

giteaが分裂した。

パスの違いがわかる男

所感

脱GitHubに向けて：Giteaを試し始める on Mac

環境とインストール

セットアップ

試す

リポジトリの作成とpull/push

ssh鍵

少しずつ試していく

Macでキーボードの挙動が変？VivaldiとVisualStudio Code でだけ Cmd + [ がきかない現象

環境

事象

原因と対応

(ChatGPT) なぜ com.apple.symbolichotkeys.plist の削除で解決したのか？

1. Cmd + [ がシステムレベルのホットキーに誤って割り当てられていた

2. 設定が壊れていた / 予期せぬキー競合が発生していた

3. VivaldiとVSCodeで Cmd + [ が特定の条件で無視されていた

(ChatGPT) この問題の発生原因は？

(ChatGPT) 再発を防ぐためには？

(ChatGPT) 結論

所感

NotionのMermaid記法でお絵かきするのが良いと伝える動画

Notion & Mermaid記法の動画

動画もアリか

Macで最初に設定していること macOS 14 Sonoma版

(miniのみ) 外付けSSDを起動ディスクにする

環境設定

キーボード、マウス

ネットワーク

アプリケーションからのインストール

App Storeから

Webから

Homebrewから

細かな設定

テキストで図を書けるWordPressのMermaidプラグインは最高だぜ

救いのMermaidプラグイン

Gutenbergとの相性よし

記法は覚える価値あり

WordPressでGutenbergを使うようになった

Gutenbergを使い始めた

クラシックエディタのほうが今なお使いやすい面もある

WordPressいいよね……

NotionはWebブラウザのほうが便利

デスクトップアプリの出来はあまりよくない

Webアプリには拡張機能がある

Webアプリにネイティブの皮を被せても……

久しぶりのGutenberg

コード

Mermaid記法

数式

使えそう

GitHubのIssueの初期ラベルについて

ラベル一覧

ラベルの詳細

help wanted

invalid

good first issue

(ChatGPT) なぜ `com.apple.symbolichotkeys.plist` の削除で解決したのか？

1. `Cmd + [` がシステムレベルのホットキーに誤って割り当てられていた

3. VivaldiとVSCodeで `Cmd + [` が特定の条件で無視されていた