GitLabはTiddlyWikiの救世主になり得るか？
突然だが2020(令和02)年10月24日、TiddlyWiki（ティドリーウィキ）の無料ホスティングサービスとして稼働していた、TiddlySpotが消滅したようだ。
WHOISで「tiddlyspot.com」を調べると、ドメイン自体は生きている。
よって、一縷の望みを託し、ドメインオーナーによって再び復活する可能性が完全にゼロと断言は出来ないものの、恐らくきっと多分、perhaps, may be, 復活は無いだろう。
上記HTMLのソースを確認すると、「description」メタタグにこんな文言が記されている。
The owner of this domain has not yet uploaded their website.
テキトー訳：
このドメインの所有者はまだウェブサイトをアップロードしていません。
つまり、今までTiddlySpotにホスティングしていたTiddlyWikiは永遠に失われたまま、1バイトたりとも復活はしないと思われる。
つД｀)･ﾟ･｡･ﾟﾟ･*:.｡..｡.:*･ﾟ
今現在、TiddlyWikiユーザがどれだけ存在し、かつ、どれだけの人がTiddlySpotにTiddlyWikiをホスティングして利用していたか、私には知る由もない。
しかしながら、私のように運用していたTiddlyWikiを突然失い、途方に暮れている人は、全世界でかなりの人数に上るのではないか？と思う。
ネット（今や「クラウド」）の常だが、「いつサービスが停止、または終了するか分からない」という、潜在的なリスクが突然顕在化し、今回のTiddlySpotの消失により、結果として運用していたTiddlyWikiをバックアップするヒマも猶予もなかった（特に私の場合は）。
ヒドイ話ではあるが、これは今も昔も変わらない「ネットの常識」なのであって、「いつまでも あると思うな 親とクラウド」という話でしかない。
TiddlySpotの仕打ちは言語道断でヒドイと思うが、それとTiddlyWikiが超絶使えるシステムであるという話とは全然別なのであって、今や「どうやってTiddlyWikiを運用するか？」というフェーズに移行している状態だ。
ちなみに以前、私はメインサイト「SEの良心」において次の記事を書き、TiddlyWikiの運用を模索したことがある。
結論から言えば、GitHub（ギットハブ）ではGitHub Pagesを含め、無料でサイトの公開範囲を限定することが出来ないため、個人が利用するメモ（＝TiddlyWiki）の内容を、ネットという衆人環視に等しい環境で野放しにオープンにはしたくない。
よって、技術的に「オープンなTiddlyWikiとして運用は可能」なものの、私個人の用途としては却下している。
そこで、以前からCI/CD（Continuous Integration／Continuous Delivery＝継続的インティグレーション／継続的デリバリ）環境がデフォで、GitHubとは違って「DevOps（デブオプス）」（＝システムの開発者と運用者が協業して効率化する仕組み）が前提になっている、GitLab（ギットラボ）を「今こそ使うべきかにゃー？」とか思った。
個人が使う、「デバイスを問わずいつでも・どこでも使えるメモ帳」としてのTiddlyWikiに「DevOps」は明らかにオーバースペックでしかないが、GitLabはGitHubと違い、プライベートリポジトリが無料で使え、GitLab Pagesの公開範囲を限定することが出来るのが大きい。
簡単に言えば、TiddlyWikiをプライベートリポジトリとしてGitLabで構成し、GitLab Pagesで公開すれば、「自分だけのメモ帳」として「TiddlySpotの代わりに使えるんじゃね？」という発想である。そして、実際にはそのように運用が可能だ。
私は自分で独自ドメインを持っているし、レンタルサーバも身銭を切って借りているため、TiddlyWikiを自分のドメイン配下（サブドメイン）に置き、レンタルサーバで公開してTiddlyWikiのセーバー部分をPHPで自作すればいいや、と開き直って考えていた。
TiddlyWiki公式が紹介している、10年以上前のPHPコードを参考にすれば、レンタルサーバにTiddlyWikiを保存するのはそれほど難しい話ではないし、一番実用的かつ安全だと思っている（それは今でもそう思う）。
それに、.htaccessでBasic認証をすればアクセス制限は簡単に実装出来るし、それで十分にこと足りるからだ。
しかし、誰もが身銭を切ってレンタルサーバを維持しているワケではないし、最小限のコスト（金銭的にも限りなくゼロ）でいながら、最大限の効果が欲しいのは、何も私だけではあるまい。
そこで、無料ストレージサービスから、無料レンタルサーバも含め、色々と検討した上で、やはり手順的にGitLab Pagesで検証するのが「手始めには良い」と結論した。
しかし、あえてムチャクチャに非IT系の一般人をdisらせて貰えるならば、「ロクに欲しいと思う情報すらググれないような情弱パンピーに、GitLabは無理」である。
一般人でなくとも、そもそも「ロートルSEにはGit自体が無理」だとも言える。それがGitLabでPagesをCI/CDで自動構築し、Webサイトを構築するだなんて、恐らく理解の範囲外だろうと思う。
私も色々と調べながら検証して知ったが、GitLabとそのPagesに関して、知らない人が理解出来るレベルで詳しく解説し、Webサイトの構築ノウハウを説明しているサイトや記事は少ない。しかも、それがTiddlyWikiとなると皆無である。
実際にGitLab PagesでTiddlyWikiは簡単に公開出来るし、プライベートなページとしてアクセス制限も可能だ。
しかし、GitLab Pagesでは次の点がイマイチである。
・CI/CDでDevOpsが前提であるので、サイトの公開とその反映がトロい
・プロジェクト（リポジトリ）全体での利用制限なので、Basic認証ほど手軽かつ即効性がない（GitLabからサインアウトしてもしばらくアクセスが可能）
一旦GitLab Pagesでプライベートなプロジェクト（リポジトリ）を作成し、TiddlyWikiを公開して自分以外（メンバー以外）にアクセス制限をかけてしまえば、上記の点はそれほど気にはならない、とも言える。
むしろ、GitLabを使うチームや、サークル内で利用する「小規模なWiki」としてTiddlyWikiを活用したい向きには、かなり有用であるだろう。
そういったニーズがなくもないと思ってGitLabで検証してみたが、最終的にはNetlify（ネットリファイ）でTiddlyWikiを運用することになると思う。
これからNetlifyでの検証も行うし、その手順やノウハウは、私のメインサイト「SEの良心」で記事にするつもりだ。
なお、取り急ぎ「SEの良心」ダウンロードページにて、最新のTiddlyWiki Ver5.1.22に日本語プラグインをインストールした日本語版と、日本語化した上にMarkdownプラグインをインストールしてマークダウン記法に対応した日本語版（マークダウン記法対応）を公開した。
GitLab PagesおよびNetlifyでのTiddlyWikiの公開・運用方法の解説記事は、順次作成する予定でいる。
いいなと思ったら応援しよう！
