nDiki : HTML

reveal.js 3.1.0 用にサンプルスライドファイルを作り直し

ちょっとしたプレゼンテーションスライドはもっぱら reveal.js を使っているのですが、今日公式ページを見たら reveal.js 3.1.0 が出ていました。自分は reveal.js 2.6.2 を使っていたのですが、これを機会に reveal.js 3 に乗り換えるようと思います。2.6.2 と 3 系は一部互換性がないところがあるとのことなので、確認しつつテンプレート用途的な自分用サンプルを改めて作り直しです。

reveal.js を共有しないサンプルに変更

2.6.2 の時は

• www.naney.org 上の固定されたパス上に reveal.js が展開されている。
• スライド Markdown ファイルを HTML ファイルと同じサイトに置く(ので Markdown ファイルと HTML ファイルを分離できる)。

前提でサンプルを作りました。しかしやはり「reveal.js リリースファイルを展開したディレクトリにサンプル HTML ファイル1つを置くだけ」で済むようにしておいた方が便利そうです。なので

• 参照は相対パスにしておく。
• 自分でカスタマイズしたスタイルやスクリプトもサンプル HTML ファイルに埋め込んでおく。
• (サンプル)Markdown データも直接 HTML ファイルに書いておく。

ことにしました。ということで以下が自分用の新しいサンプルです。

• Naney の reveal.js 3.1.0 サンプル 2015年8月9日版

reveal.js 3.2.0 に追従

プレゼンテーションスライドを久しぶりに作るのに reveal.js が 3.1.0 から 3.2.0 になったので、テンプレート用途に使う自分用サンプルを作り直しました。

といってもスライド HTML 側違いは、末尾の dependencies を指定しているところで highlight.js の指定方法が変わったぐらいです。

• Naney の reveal.js 3.2.0 サンプル 2016年2月4日版

初全ツイート履歴ダウンロード

自分の Tweet は API で取ってきておおむね nDiki の記事にまとめてあるのですが、使い始めの頃はそんなことをしていなかったので手元にデータとして取ってありませんでした。公式機能で全ツイート履歴ダウンロードができるのは知っていましたがそのうちと思いつつずっとやり忘れていたので、ようやく腰を上げて全ツイート履歴リクエストを設定からしてみたところ、ほどなくして準備完了のメールが届きました。

ダウンロードした ZIP ファイルの中をみると、予想していた通り人間用に HTML ファイルがありました。そしてそれ以外に CSV 形式ファイル・JSON 形式ファイルが含まれていてきちんと利用しやすい形になっていて良くできているなと感心してしまいました。良いですね。

きちんと README.txt をみてみたら HTML ファイル (index.html) は JSON 形式ファイルを読んで表示するページになってました。なるほど。API のレスポンス仕様と同じ JSON 形式をエクスポートデータにしているのですね。

Markdown で書いているノートを Web ブラウザで見るのに MkDocs を使う

ノート/メモははライティングアプリ Ulysses を使い Markdown で書いていて、検索・閲覧・整理も Ulysses で基本済ませています。ただいくつかの良く参照するファイルはブックマークやハイパーリンクから Web ブラウザでさっと表示させたかったりします。なので以前は Plack::App::Directory::Markdown を使った自作 PSGI アプリケーションを使ってました。

• howm + Markdown + Plack
• Text::Markdown::Discount でテーブルや ``` や自動リンクなどの拡張を使う
• 社内でも動かしている PSGI アプリケーションに OpenID 認証をつけた
• Markdown ビューアを OpenID Connect を使って Google アカウントで認証できるようにした

が、セットアップしたり保守したりという手間を今とれないなと思って、 Markdown ビューアを探してみたところ MkDocs が良さそうなので試してみました。

• http://www.mkdocs.org/ (公式サイト自体が MkDocs で作られているのでどのような表示になるか確認できます)

MkDocs を Homebrew で入れてみる

MacBook Pro に Homebrew で入れて動かしてみます。

 $brew install MkDocs
 $mkdir -p ~/var/mkdocs
 $cd ~/var/mkdocs
 $mkdocs new local
 $cd local
 $mkdocs serve

で Web サーバが立ち上がるので http://127.0.0.1:8000/ にアクセスすると ~/var/mkdocs/local/docs/index.md の内容を HTML に変換したものが表示されます。お手軽! 設定変更は ~/var/mkdocs/local/mkdocs.yml できます。

• 設定ファイルの書き方

あとは docs の下に Markdown ファイルを置いておけば Web ブラウザで閲覧できます。docs の下に既存の Markdown ファイルノートディレクトリへシンボリックリンクを作ればそれらも辿って表示されます。

pip で入れ直す

試していてブラウザでのレンダリング表示が重いなと思って HTML ソースを見たら同じ JavaScript ファイルを何十回も読み込んでいて何か変ぽかったので Homebrew のをやめて pip で入れなおしました。どちらも現在 mkdocs 0.17.2 ですが pip で入れた方は問題なかったのでこちらを使うことにします。

 $brew uninstall mkdocs
 $brew install python
 $pip2 install mkdocs

MkDown は静的サイトジェネレータで、プレビューサーバは補助的機能ですがまずまず使えそうです。

GitHub Flavored Markdown ファイルの Web ブラウザでのプレビューに Grip を使う

「Markdown で書いているノートを Web ブラウザで見るのに MkDocs を使う」とつぶやいたら @bsdhack 氏が Grip を紹介してくれました。

私はgithubなどのmdファイル(https://t.co/nyoqRnjsN7)を読むために python製の grip 使って↓なスクリプトを書いて使ってます。

grip --export ${1:-README.md} - | w3m -T text/html

— Mitzyuki IMAIZUMI (@bsdhack) 2018年2月28日

さっそく試してみました。

 $pip2 install grip

でインストールしたら Markdown ファイルを指定して Grip を起動します。

 grip index.md

Grip が http://localhost:6419/ で Web サーバとして立ち上がるので Web ブラウザでアクセスすると index.md の HTML 変換されたものを見ることができます。なお

 grip -b index.md

とすれば起動と同時に Web ブラウザで開いてくれます。URL でパスを指定すればそのまま同じ/サブディレクトリにある Markdown ファイルもプレビューできるので、ハイパーリンク付けをしておくことでドキュメント群をブラウジングすることもできます。なるほどお手軽で便利。 GitHub 上とほぼ同様の見慣れたデザインになるのがいいですね。

そもそも Grip は「GitHub Readme Instant Preview」で GitHub 上での表示確認のためのツールで、 GitHub の REST API を使ってレンダリング結果を生成しているので当然といえば当然だったりはします。

ただそのかわり GitHub の API を使うので

• オフラインでは使えない(オフラインレンダリングは開発中)
• 外部サービスを使って変換させたくないドキュメントには使えない

と場合によっては不便な部分があります。なお後者については GitHub Enterprise があるなら Grip でそちらを指定するとう手もあります。

GitHub に push する前にチェックしたい時はもちろん、それ以外でさっと Web ブラウザで見てみたい時にも便利なツールですね。

• https://github.com/joeyespo/grip

Ulysses で TextBundle を使うのどうなのか調べてみた

Markdown 形式ファイルと、そこから参照されている画像ファイルを1つにまとめて管理する形式として TextBundle がある。ライティングアプリ Ulysses が対応しているのでちょっといじってみた。

• http://textbundle.org/

TextBundle は package format と compressed format がある。 package format は macOS のパッケージの形になっていて、 textbundle という拡張子をつけたディレクトリの中に info.json と text.* (Markdown なら text.md)、それからテキストファイルから参照しているファイルを asserts/ サブディレクトリに置くという仕様である。macOS の Finder からは1つのファイルのように表示される。

TextBundle を使うメリット

メリットは以下。

• テキストファイルと参照されている画像ファイルを一緒に管理できる(ばらけないで移動したりできる)。
• TextBundle に対応していないテキストエディタでも text.md を簡単に開いて編集できる。

TextBundle を使うデメリット

非対応アプリケーションから使う場合にデメリットを感じる。

• 非対応アプリからみると TextBundle 毎にディレクトリがあることになるので、ディレクトリだらけな感じになる。ドキュメント毎にディレクトリを開いて中のテキストファイルにアクセスする必要がある。
• Markdown ファイル名が text.md 固定なので、ファイル名だけでは区別できなくなる。

Ulysses for Mac の場合

Ulysses は TextBundle に対応しているので通常の Markdown ファイルと同様1つのシートとして自然に扱える。

普段 Ulysses for Mac では Dropbox の中のディレクトリを外部フォルダとして指定して使っているので以下、外部フォルダの時の話し。

Ulysses の外部フォルダ上の Markdown ファイルに貼った画像をエディタ上でプレビューできるのは現状 TextBundle だけ。エクスポート時も TextBundle 内の画像ファイルは書き出されれるけれど、(相対パス・絶対パス問わず)ファイル名で参照しているものは書き出されない(http/https な URL で指定した画像は HTML でエクスポートする際は画像が貼られる形になるが PDF ではだめ)。Ulysses だけを使って画像を扱いたいなら TextBundle を使う以外選択がない感じだ。

Ulysses 上で TextBundle なシートを保存するたびに参照されている画像ファイルを残して他は assets/ から消されてしまう。なので assets/ の下に画像作成に使ったソース・ファイル(マインドマップファイル)を一緒に置いておくおような管理はできない。そもそもテキスト編集で間違えて画像参照を消して保存実行してしまうと、画像ファイルだって消えてしまうので、画像ファイルだってオリジナルを別で保存しておく必要がある。

TextBundle は使うのは控えた方が良さそうだ。

階層が深くなった TaskPaper ファイルはアウトライナー無しではもはや読み書きできない

事業方針について TaskPaper で要素を分解しながら考えていたらかなり深いツリーになってきた。アウトライナーなら折り畳み・フォーカス・検索でのフィルタリングなどの機能があるおかげで大きなツリーでも難なく考えを広げたり整理してまとめたりをできるので楽しい。

TaskPaper ファイルはテキストファイルで他のテキストエディタでも閲覧・編集できるのが良いところなんだけれど、ある程度大きくなるとアウトライナーの助けがないともはや読み書きが難しくなるんだよね。

誰かと共有するのにせめて折り畳みのできる HTML ファイルに変換できるようにしておかないとなあ。

Web 日誌 / Web 日記を書き始めてから20年

途中ブランクがあったりするけど、書き始めてからついに20年だ。

いつ始めたか?

個人 Web サイトを作り始めたのが1995年か1996年ぐらい。それから数年経った1999年1月19日にコンピュータ日誌として日付ベースの記事を書き始めた。

当時既に Web 日記を書いている人はいたが、まだ HTML ファイルとして直接書いている人も多かったんじゃないかな。自分は当時マクロプロセッサ m4 を通して静的 Web ページを生成していたので、当初 Web 日誌も m4 マクロで生成していた。

ハイパー日記システムが公開されたのが前年の9月、 tDiary が SourceForge.net に公開されたのは3年後の2002年2月20日であった。その翌年の1月16日にはてなダイアリーベータ版がリリース、さらにその翌年日記機能をもつ mixi がオープンとなる。

そこそこ早い時期から Web 日記 (Web 日誌)を書いていたんじゃないかな。

20年続けて得られたものは?

20年続けて得られたものは以下だな。

• 自分の20年の情報が蓄積されたパーソナルナレッジベースとなった。自分の過去の何かについてはサイト内を Google 検索すればたいがい探せてしまう。
• パーソナルナレッジベースについての知見を得た。
  • 特に個人の情報は「いつ」のことかが重要。
  • 「システムの寿命よりもデータの寿命を特に重視して設計されていなければならない」「ノート・日記はテキストファイルに」「ファイル名中の日付を先頭にする」
• ちょっぴり人の役にたった。
• ちょっぴり収入になった。

20年続けて失ったものは?

一方失ったものは時間。公開している以上、下調べしたり文章を整えたりするのにある程度時間がかかり1週間に数時間は費やしている(1日分で数時間の場合もザラ)。Web 日記を書いていなければ数千時間、他のことができていたであろう。

あ、もちろん無駄な時間だったとは思ってはいない。調べたり考えたり内省したり、日記を書き続けたから今の自分がいるんだよね。

続ける?

Web 日記は趣味だからね。

[ コンピュータ日誌 ]

HTML ページ中の mermaid 定義を自動的にクライアント側で SVG 変換し表示させる

6月上旬に使い始めた Markdown エディタ Typora で mermaid を使いダイアグラムを作成してみたらなかなか良かったので、先日 mermaid のデータから画像を単独で生成できるよう CLI を入れてみた。しかしやはり都度画像ファイルに変換して管理するのは面倒。ちょっとしたノートを置いておくスペース nNote では事前に画像ファイルに変換しないで直接ページ上に書かれた mermaid ダイアグラムを SVG 変換して表示されるように設定してみた。

• https://mermaidjs.github.io/

mermaid.min.js を Web サーバに配置し、ページの下部に以下が含まれるようにフッタファイルを編集。

 <script src="/path/to/mermaid.min.js"></script>
 <script>mermaid.initialize({startOnLoad:true});</script>

これでページ中に

 <div class="mermaid">
 graph LR
     a --- b
     a --- c	
 </div>

のようにダイアグラムの定義をmermaid クラスの要素の中に書いておくと、ダイアグラムの SVG 要素が生成し置き換えてくれる。表示は以下のような感じ。

画像ファイルの管理から解放されるのでいろいろ捗って嬉しい。

とりあえず nNote 全フッタで mermaid.min.js を読み込むようにしちゃったけれど 8.0.0 ので 1.11MB ありダイアグラムの無いページで読み込ませるのはちょっと忍びない。 mermaid ダイアグラムの定義がある時だけ読み込むようにした方が良いね。

HTML ページ中の Graphviz 定義を自動的にクライアント側で SVG 変換し表示させる

昨日 HTML ページ中の mermaid 定義を自動的にクライアント側で SVG 変換し表示させるようにしたらいい感じなので、勢いで Graphviz の DOT 言語で書かれたグラフ定義も Viz.js を使って SVG 変換できるようにしてみた。

• https://github.com/mdaines/viz.js

mermaid では HTML ページ中の mermaid クラスをもつ要素を SVG 要素に変換するコードが入っているのだけれど Viz.js にはそれは無さそう。なので mermaid の実装を参考に dot クラスの要素を変換するようにしてみた。

 <div class="dot">
 digraph {
   graph [rankdir = LR];
   a -> b;
   a -> c;
 }
 </div>

と書いたら以下のように変換される。

mermaid よりずっとメジャーな Graphviz (互換)が使えるとさらに捗って嬉しいぞ。

Viz.js は mermaid よりさらに大きいので、さすがに全ページで読み込ませるのはまずい。なので Viz.js と mermaid についてそれぞれの定義があった場合のみ動的ロードするようにしておいた。

で、まずます動くようになったのでちょっとしたノートを置いておくスペース nNote だけでなく nDiki でも動くように設定しちゃった。Viz.js や mermaid が使えなくなった時のことを考えて記事の寿命が長い nDiki の方では多用はしないつもりではある。