今回のIssueでブログを書いていくシステムは、結構使っている物が多く、しかも自前のサーバーとかPCとかが介在しないあたりがちょっと今風で面白い。 そこでちょっとその辺の事を書いてみる。

まず、書くのに使っているのは、MeatPieDayというAndroidアプリだ。 これはテキストと図を混ぜたノートを気楽に作りたい、と思って作ったアプリ。 ブログなどではどうも図や絵を載せるのが面倒なのにtwitterなどでは気軽に絵を貼れるのはなぜだろう？と考えて自分なりに結論を出したもの。

これ自身は結構気に入っているのだが、これで書いた物を公開する手段がいろいろ悩んでいるところ。 MeatPieDay自体はipynbというJupyterNotebookの保存形式で結果を吐く。 これはgistにとりあえず貼ればキレイに整形してくれる事を知っていたので、それを当てにしてこの形式にした。

ただgistはtypoとか見つけた時に、投稿した物をwebから修正出来ないのと、gistに書いた結果がいまいち流れてしまって蓄積していく対象としてはいまいちだな、と思っていたので、あくまでつなぎ。

将来的にはipynbをブログに投稿するコードを書こうと思っていたのだが、最近勉強会の予習とか論文読みなどの、普段掲示板に書き溜めている物もブログに統合したい、と思うようになった。

そこでMeatPieDayのフォーマット決め打ちのipynbをgithubのissueに投稿するコードを書いた。 これはMpd2Issueという名前のアプリ。

将来的にはなんらかの形でsyncというか、ローカルで変更した物を更新したり、サーバーの変更を取り込んだり、という事をやりたいけど、今は書いた物をただ新規のissueとして投稿するだけ。 アップした物はoctodroidなどのgithubのクライアントアプリで普通に編集している。

画像はimgurにアップしてそのリンクを貼る。 画像の変更はwebからはちょっとやりづらいが、それ以外はこれでもまぁまぁ我慢出来る。

issueからブログを生成する所はまだ書いていないが、github pagesでjekyllを使うつもりでいる。 これは以前Re:VIEWで書いたマークダウンからpdfを生成するのをCircleCIで動かしていた事があったのだが、これがなかなか良かったので、この路線を踏襲したいと思って模索した結果。 CircleCI側ではDockerでいろいろ入れて走らせる感じなので、たいていの物はここで動かせる。

jekyll自体はgithub pagesで使うなら特別な事は何もいらず、普通にgithubにcommitしたら勝手に裏でページが生成されるっぽい。 だから適当なブランチにcount.txtとか作って、公開したい時はこいつを更新する事でCIを走らせてマークダウンをmasterにcommitすればいいかな、と思っている。

このシステムでちょっと面白いな、と思うのは、自分のサーバーみたいなのが一切挟まらない所。 webプログラミングもしていない。 単にissueを取ってきてmdに変換するような、普通のテキスト処理の書捨てコードくらいでシステムが完成する。 それが走るのはCircleCIなので、そのマシンにログインする事すら無い。

djangoとかGAEとかの知識が全く必要無いし、サーバーを持っておく必要も無い。 webを生成しているが、htmlもJSも全く要らない。 webフレームワークとしてはjekyllを使っている、という事になるのだろうが、静的なジェネレータなので何もコードは書かない。大して知識も要らない。

ストレージもissueとgithubのレポジトリにプレーンテキスト。

PCもサーバーも自分の物が無いのに、割と自由に作りたい物が作れている。

プログラミング言語としては、まずAndroid側はKotlin。 CI側はなんでも良いが、golangかRubyかPythonあたりだろう。 自分だったらgoを選ぶかな。

goは別段そんな特別な所がある訳じゃないのだが、こういう時にPythonでは無くgoを選ばせる物があるのは大したものだな、と思う。 個人的にはVS Codeでのgoto definitionの挙動がPythonより軽くてカチッと動く所と、適当にgithubにおいて他のマシンでgo get出来る所が良い。

逆にASP.NETとかC#とかWPFとかPowerShellとかJSとかは全然出番無いなぁ、と思う。別にnode好きならgolangの代わりにnodeは使えるかもしれないが。

一昔前を思い出すと、ノートっぽいアプリを作るとなると、IronPython+WPF+Luceneとか使っていた。 随分も使うテクノロジも変わったものだ。

あの頃はペンで描いた図などを気楽に取り込む、というのを実現する事は自分にはできなかったので、その辺出来る事は増えたと思う。 何より今はスマホで動く。

サーバー側はプログラムレスとまでは行かないけれど、いわゆるラスト1マイル問題みたいな、かつてPowerShellが埋めようとしていた程度のちょろっとしたスクリプトで今回は十分そう。 github pagesとJekyllの組み合わせが筋が良いという事だが、CircleCIの上でDockerが割と気軽に使える、 というのも自分でサーバー持たなくてもやりたい事が出来る理由になっていて、 全体的にはやはり現代的だという事なんじゃないか。

テクノロジースタックも随分昔とは違うよな。Circle CIやDockerが分かって、golangとかでちょろっとしたの書けて、ipynbが間にあって、markdown、、、は前からあるか。

リッチなのはクライアント側であって、サーバー側はちょっとした書捨てスクリプトみたいなので十分対応出来る、というのも、時代は変わったなぁ…と思う。

余談だけど、MeatPieDayは普通に考えればサーバー側にもサービスを作って、そいつとsyncするようなクライアントであるべきと思うのだけど、今回はMeatPieDay自身にはネットワークの機能は持たせていない。 結果として、公開する為に送信したり、サーバー側で変更した物を取り込むのは一手間かかる（今はimport作ってないからそもそも出来ないが）ので、そこはいまいちなんだが。

でもそのおかげで、しばらくgistに投稿するやっつけアプリだけで勉強会の予習とかのノートは公開していけて、ある程度使って有効性が分かった所でissueに置き換えて…と各構成要素が切れていて独立に置き換え出来ているのは、今回ここまで進められたポイントにも思う。

多分ipynbをgistがサポートしていなければ、ここまでこぎつける事はできなかった。 ipynbならどうせそのうちnotebookのフロントエンド作る時に使いまわせるだろう、というのもやる気に結構影響を与えた（そして実際に途中まで作ってあるnotebookのフロントエンドでは使いまわしている）。

今回は実現したい物が大きく大変なのを、簡単に出来そうな問題に分割して順番に片付ける、という事に関しては、なかなか上手く出来てるんじゃないか。 この辺はアイデアを形にする力という奴だと思っている。