nDiki : HTML

HTML (HyperText Markup Language)

関連情報

Perl モジュール

  • HTML::PopupTreeSelect
    • ディレクトリツリーなどのツリー構造のノードを選択させるウィンドウをポップアップさせるためのモジュール。
  • Template Toolkit

HTML への変換

スポンサード リンク

2015年8月9日 (日)

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 ファイルに書いておく。

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

スポンサード リンク
[ 8月9日全て ]

2016年2月4日 (木)

reveal.js 3.2.0 に追従

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

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

[ 2月4日全て ]

2017年9月29日 (金)

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

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

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

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

[ 9月29日全て ]

2018年2月26日 (月)

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

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

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

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

MkDocs を Homebrew で入れてみる

MacBook ProHomebrew で入れて動かしてみます。

 $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 は静的サイトジェネレータで、プレビューサーバは補助的機能ですがまずまず使えそうです。

[ 2月26日全て ]

2018年2月28日 (水)

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

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

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

 $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 ブラウザで見てみたい時にも便利なツールですね。

[ 2月28日全て ]

2018年10月13日 (土)

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

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

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 は使うのは控えた方が良さそうだ。

[ 10月13日全て ]

2018年11月1日 (木)

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

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

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

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

[ 11月1日全て ]

2019年1月19日 (土)

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

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

いつ始めたか?

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

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

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

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

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

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

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

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

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

続ける?

Web 日記は趣味だからね。

[ コンピュータ日誌 ]

[ 1月19日全て ]

2019年6月25日 (火)

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

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

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 要素が生成し置き換えてくれる。表示は以下のような感じ。

graph LR a --- b a --- c

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

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

[ 6月25日全て ]

2019年6月26日 (水)

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

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

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

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

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

digraph { graph [rankdir = LR]; a -> b; a -> c; }

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

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

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

[ 6月26日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.085262s / load averages: 0.87, 1.13, 1.05
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker