カラクリサイクル

『輝かしい青春』なんて失かった人の雑記

今まで使ってきたノート系サービスなどの雑感

ここ最近、僕個人の印象として、

Web, Desktop or Mobile で情報をまとめたノートが取れる

みたいなサービスが最近増えてきた感があって、かつ、自分も色々とそう言ったモノを使ってきた中で、

あ、これはこの用途に向くけど、この用途には向かないな……

という感じが掴めてきたんですが、今日はその辺りの雑感を、 各アプリケーション毎の批評も含めて書いてみたいと思います。

各アプリケーションの雑感

Evernote

  • 僕が最初に使ったノート系アプリ。今はアカウントを消してもう何年も触ってない
  • 僕が使ってた当時は、Web だろうとアプリだろうと重かった
  • で、ノートの同期も重くて、正直使いモノにならなかった印象が残っている

Simplenote

  • 僕が Evernote から乗り換えた先。当時としては割と先駆者だった様に思う
  • プレーンテキストを管理する、という意味では割と良かった
  • ただ、今となってはあんまり積極的に使うか、と問われると疑問符が着く

wri.pe

  • 僕が Simplenote から乗り換えた先。だった様な気がする。今は触ってない
  • @masuidrive さんの個人開発者系サービス。なので @masuidrive さんが SPoF となり得る
  • 機能的にはシンプルで良かったんだけど、今となってはちょっと機能が足りない感じかも

esa.io

  • 基本的に有料の情報共有サービス。トリがかわいい
  • 機能的には満足だったが、ページのレンダリングが遅かった記憶
  • それも有ってか、色々と利用サービスのリストラしてた時に解約して以後は触ってない

Vim

  • 一時期、本当に Vim でメモ管理をしていた。が、途中で色々面倒になったので止めた
  • 基本的に全部自前でプラグインとか追加しなければ快適にならなかったので、その辺りがちょっと……
  • とは言っても、今でも開発エディタは基本的に Vim です。IDE とか苦手です

Scrapbox.io

  • 僕の WYSIWYG エディタへの偏見を打ち砕いてくれたサービス
  • 基本的には脱構造化文書指向のサービスであり、構造化された文書を扱うには向かない
  • 考え事をアウトライン的に書き出すツールとして非常に優秀だが、だいぶ使い方を選ぶ感じもある

kibela

  • Cookpad社の情報共有ツールにヒントを得て作成されたサービス。@gfx さんとかが在籍
  • N高 での学習ノートにすべく、試しアカウントを取ったのが使い始めた理由
  • しかしながら使ってみた感想としては、esa.io をマイルドにした感が否めない

Boostnote

  • 本当に快適に使える Markdown + Code Snippet がメイン Evernote という趣きのアプリ
  • GPLv3 のオープンソースアプリケーションで、モバイル版も有る (こちらは MIT-licensed)
  • マネタイズをどうするつもりなのか疑問だったんだけど、最近は Web サービス版を作ってるっぽい

以上を踏まえて

まあ、これ以外にも Qiita とかはてなブログとかも使ってた事は有るんだけど、 Qiita は SNS で、はてなブログはブログサービスなので、ここでは触れていません。

それで、上記の 各アプリケーションの雑感 は、僕が各アプリ・サービスに触れた順にならんでいて、 下へ行くほど最近の (Web) アプリケーションになるんですが、ここまでサービスなりを使ってみた感じとしては、

  • Scrapbox.io が非構造文書に、Boostnote が構造化文書を扱う上で、一つ頭抜けている印象
  • 次に kibela と esa.io は横並びみたいな印象で、最近出てきた kibela の方が無難かな、という感じ
  • そしてその下に simplenote と wri.pe が続いているんだけど、wri.pe の方は個人開発としてはスゴい

という感想です。

まあ kibela とか esa.io は使い勝手が非常に普通で、オールマイティな情報共有サービスとしては使い勝手は良いんでは? と思うんだけど、Scrapbox.io と Boostnote が特定の用途に特化した形で一つ頭抜けて使い勝手が良く、 その影響で kibela とか esa.io の印象が薄くなっている感が有ります。

ただ、Scrapbox.io と Boostnote はその利用体験が良い分、どちらについても、

うーん、ちょっと場面を選ぶ感じも有るなー

という印象で、具体的には、

  • Scrapbox.io
    • 非構造化された情報を扱うに非常に長けており、アウトラインエディタとしても優秀
    • ただ、Scrapbox はその設計思想の違いから、構造化された情報管理はそもそもお呼びではない
  • Boostnote
    • Markdown + Code Snippet を記述する上では非常に快適 (ただしモバイルは未だ試してない)
    • ただ、機能的には充実しているか、というと、未だ発展途上かな、と言う印象

という感じです。

そして、僕の中の印象を総合すると、

  • 個人的なメモ管理等では、用途に応じて Scrapbox.io と Boostnote を使い分ければ良い
  • 複数人で使う場合には、ホワイトボードにメモ紙貼り付ける感じで使うなら Scrapbox.io を選ぶ
  • コンピューターにあまり聡くない人とも情報共有するなら kibela か esa.io
  • 家族間の情報共有などの少人数なら kibela の無料枠が使えそう

と言う感じになりますね。はい。

以上

なんかサクっと書くつもりがガッツリ書いてしまいました。そして、もうそろそろ風呂へ入て寝ろと言われました (親に) 。

ま、今回の記事を書いてみた感想としては、基本、どのサービス等に対しても、

お互いに切磋琢磨してその価値を高めて行って欲しい

と願っていますが、使う側としては、割と容赦が無い感じに 優れたモノを使えればそれで良い 、と言うのが僕のスタイルっぽいので、 まぁ、こういう比べてみる系の記事だと、辛口になるよなぁ 、という印象が拭えない感じです。個人的には。

あとはまぁ、なんだ、この手のサービスって、割とこう、会社として開発されている様なモノだと、

  • 気が付くと消滅しているか
  • どこかに買収されているか
  • あるいはしぶとく生き残っているか

の三択なので、

ま、頑張ってください

という感じに僕はなるんですが、これを素で言っちゃうと、

多分、引かれるか、反感を買うかのどちらかなんでは?

とは思わなくも無いんですが、まあこれが僕の正直な感想ですね。本当、容赦も無い感じなんですが。


ま、と言うことで、サクっと書くつもりが 3000 字超えになった今日の話はこれで以上です。

もうそろそろ寝ます。おやすみなさい。

ここ最近の様子

についてサラっと。

とにかく学習・学習・学習である

基本的には、午前中に頭を使う数学を、午後からは割とラクそうな教科をやってたりする。

それで、数学に関しては今現在中学校レベルの復習をしていて、基本的な式の解法なんかの理解は問題ないんだけど、 その解法を使った計算に関してはめっちゃ躓いていたりする。

と言うのも、僕の場合、これまでの病歴も絡んでいるのだけれども、

様々な要因により、脳内のワーキングメモリが少ない

と言う状態が有り、脳内にスタック出来る変数の数が少ないため、 脳内のワーキングメモリの容量を要求される、暗算などにめっちゃ苦労する、 と言う状態になってたりする。

これは具体的には、

  1. 例題を見る
  2. 式を書き写す (この時点でも稀にミスってる)
  3. 式を解く
  4. 何かしらの情報が飛ぶ (符号とか乗算し忘れとか)

という感じになっている。

つらい (数学が)

メンタルの調子の方が微妙に安定しない

まぁ、これは数学で消耗している、と言うのも有るんだけど、大抵の場合、午前中に数学などで脳をフル活用した結果、 午後からは気力が切れてきて、夕方ぐらいからは行動に支障が出る場合もある、と言う感じ。

僕個人としては、折角 N 高生になったのだから、N 予備校なども活用して、 色々な事にチャレンジしたい! ……と思ってるんだけど、いかんせん、 午前中の学習で気力 (と言うか行動ポイント) が尽きているため、学習などが出来ないと言う。

もどかしい (体調が)

実はひっそりとプログラミング言語の作成にチャレンジしている

が、実際には何も進んでなくて、そもそもの Syntax Parser を作る時点で躓いている。

それで、一体どんな言語を作ってるのかっていうと、これは、

既存の言語である Nix expression languag の Standalone な runtime 環境

を作ろうとしていたりします。

ま、これを作ろうと思った理由としては、単純に、

Nix expression language で実用的なプログラミングしたい!

というだけなんですが、今現在のところ、 Nix expression language って、その言語機能単体では、 標準入出力とか、引数の解釈とか出来ないっぽいので、その辺りをカバー出来る runtime を作れたらなー、 というのが、おおよその理由です。

ただし、前述の通り、そもそもパーザを書く時点で詰ってるので、まーこれ何時になったら出来るのやら、って感じですが。

難しい (パーザが)

以上

と言う事で最近はそんな感じで生活している、と言う話でした。はい。

Web Application に HTML を用いなければならない、と言う前提は実はない

主に、mizchi さんの、

と言う記事と、そのブコメである

を読んで思った事を書きます。

我々には XML が有るじゃないか!

上記の記事に対するブコメで、

そもそも HTML を Web Application を作るのに使ってるのが間違い

という様なコメントをいくつか見かけて、

あれ、そもそも HTML 無しで Web Application って作れたんだっけ?

と言う感じになって調べてみたんですが、色々見て周った結果、

XML + CSS + xhtml:script と言う辺りを使えば、 別に HTML を使う必要な無いんじゃね?

と言う結論になりました。

もっとも、これは 技術的には可能だろう と言う範囲でしか無いんですが、セマンティック Web という文脈を排除した Web Application を作る のであれば、 別に HTML 文書 をリッチなアプリケーション UI を作る土台として使う必要はなく、UI には オレオレ定義な XML を CSS で肉付けし、 後の動的な要素でスクリプトが必要になる部分にだけ xhtml:script 要素を引っ張ってこれさえすれば、モノは作れる、と僕は思います。

とは言え、これがすべてのブラウザ環境で動くかどうか、については 試した事も無い ので、 実際に実用出来るかは不明 (特にモバイルなど) ですが、まあ、XML 規格的には可能っぽい事だけは確か です。はい。

Web Application 開発に本当に必要なモノ

それで、ここまでの話を考えていた過程で、

そもそも Web Application を実現する基盤として 本当に必要なモノ とは何だろうか?

と言う事に思いを巡らせていたのですが、僕が考えるに、Web Applciation に本来必要なモノというのは、恐らく、

  • UI を定義し表示するための Renderer
  • UI の動作を実装するための Runtime
  • 上記二つを安全に実行するための Sandbox

の三つで、これらを実現できる環境さえあれば、別に HTML をWeb Application 実行基盤として利用する必要はない、 と僕は思う訳です。

ただ、現実問題として、上記の三つを満たし、かつ、すべてのブラウザ環境や、あるいはクローラーが解釈出来る共通言語的な基盤、 と言うのが、実際には HTML ぐらいしか存在しない、というのが、今の Web の現状な訳で、 その辺りについては、まあ、なかなか一朝一夕に解決するのは難しいよね、と僕は思います。

また、僕がもし、今の Web の現状に合わせて XML ベースの UI 記述環境を定義するであれば、

  • UI のレイアウト定義に CSS を用いる
  • XML から直接 Javascript なり WebAssembly なりを関連付けて実行出来る様にする
  • DOM Alternative っぽいので XML Tree を出力出来る様にする
  • そして上記以外の xml 要素とか Scripting API は極力定義しない

という感じにするかなーと言う感じですね。はい

Web Application を解釈するだけのブラウザは実現可能か

で、話としては最後で mizchi さんの記事の最初の方に戻るんですが、mizchi さんの記事の中で、

(Web ブラウザの開発への) 参入障壁が大きく民主的ではない

という問題提起があるのですが、これについて Web Applciation という文脈 において思うのは、 先に示した、

  • UI を定義し表示するための Renderer
  • UI の動作を実装するための Runtime
  • 上記二つを安全に実行するための Sandbox

の三つを満し、かつ、

  • Desktop
    • Windows
    • macOS
    • Linux
    • *BSD
  • Mobile
    • Android
    • iOS
    • Windows Phone

という、現在メジャーな環境で動く環境をモノが必要になってくると思うんですが、 Desktop 環境と Android はまだ良いとして、 iOS とか、 外部リソースを解釈して実行するランタイム系のアプリは確か Reject されていたハズ……なので、 現実にその手の何かを作るのは、まあ難しいような気がします。特に iOS だとね。

あと、この手のヤツって、やってる事、したい事自体としては、既存の Product に例えると、

Qt を Web で実現したい!

みたいな話なのでは……と思ってしまったので、まー現実的には色々厳しいよね、と思いました。

以上

なんと言うか、ここまで書いてて、

なんかこれ、車輪の亜種の再開発みたいな話だなぁ……

と思いますた。

ま、話も長くなって来たし、今日は外出する予定もあるので、今回はこの辺りで失礼します。

Vim の Plugin 管理を vim-plug ベースに戻した

と言う話。


僕は以前、NixOS を使い出した辺りから vim の plugin 管理は NixOS 側 (正確には nixpkgs) で管理していたんですが、 Windows とか macOS 等のシステムが nixpkgs で管理されてない環境で、 nixpkgs とそれらの環境用の plug.vim の二重管理になってたんですが、

まぁ、正直二重管理は面倒だよね

って事で、vim の plugin に関しては、nixpkgs 側から vim-plug 側に戻しました。

で、まぁそれはそれで良かったんだけど、NixOS (nixpkgs) だと、

  • スクリプト言語で書かれていて、かつパッケージが提供されてないツール

のシステムへのインストールがめっちゃ面倒で、この辺り、どうしたモノかなーとか考えています。

と言うのも、NixOS ってシステムのパスがかなり特殊で、フツーのファイルツリー構造を想定したソフトウェアとか、 パッチ当てたり、あるいは configure フラグ弄ったりしないと、そもそもコンパイル出来ない場合も結構有るので、 まぁスクリプト言語を $HOME 以下でコンパイルして……っていうのが、中々し辛いんですよね。

まー default.nix の設定でフツーのファイルツリーを用意して……言うのも出来なくは無いんですが、 まあそれもそれで色々と面倒……というか、今一つやり方が判ってない部分も有るので、 本当、この辺りどうしたもんかなぁ、と思ってます。はい。