nDiki : HTML

HTML5 がついに W3C の勧告(Recommendation)になっていた

HTML5 がついに W3C の勧告(Recommendation)になっていた。

014年10月28日(アメリカ)： ワールド・ワイド・ウェブ・コンソーシアム(W3C)は、ウェブページやウェブアプリケーションを構築する際に使用されるフォーマットHTMLの第5版であるHTML5を勧告として公開し、オープン・ウェブ・プラットフォームの礎を築きました。-- http://www.w3.org/2014/10/html5-rec.html HTML5勧告–オープン・ウェブ・プラットフォームの重要なマイルストーンを達成

これでようやく安心して仕様をもとに言及できるな。

HipChat で first name だけを表示するようにする

HipChat は first name と last name を要求するところがイケてないので last name を LEFT-TO-RIGHT OVERRIDE (LRO) U+202D にした。

IM によって入力方法が違ったりして U+202D の入力方法を覚えていないので HTML ファイルに書いたのを Web ブラウザで表示させてコピー&ペーストして入力。

Naney ‭!

と HTML ファイルに書いて Web ブラウザで「Naney !」と表示されているところを範囲選択しコピーし、そのあと HipChat の full name のところにペーストする。そして「!」をバックスペースで削除して保存。

サイト訪問者と運営者とのチャットを簡単に設置できる Zopim が面白い

最近はチャットでユーザーサポートを提供しているサービスが増えてきている。自分も過去チャットのサポートで解決が迅速に進んだ経験があってチャットサポートについては肯定的である。最近のチャットサポートはどうなっているのだろうと自分でも試してみたいと思い、人気が高そうな Zopim を実際に設置して試してみることにした。なお Zopim はカスタマーサービス・プラットフォームを提供する Zendesk に去年買収されている。

• Zopim

簡単に登録と設置ができた

実際にこのサイトのページの右下に出ているのがそれ。

上記のページの「SIGN UP」か「TRY ZOPIM」ボタンで登録ページへ。Name (後で変更できる) と、Email Address (後で変更できる)を入力してサインアップ。メールアドレス確認メールが届いたらそこのリンクから残りの登録ステップ済ませる。

あとはダッシュボードの「ウィジェット」のところにある HTML コードをページの HEAD 要素の中に追加すれば設置 OK。

HTML コードは PC 向けサイトでもスーマートフォン向けサイトでもどちらでも使えるのでサイト側では意識しなくて良い。 Bootstrap を使ってデザインした両対応しているページでも、Zopim もアクセスしてきたブラウザに合わせて機能してくれる。日本語も問題なく使えている。

「設置してみたのでテストしてみて」と言ったら一気に5人チャットがきて、慌てて返信してみたりした。実際にはリラックスして訪問者とやりとりするのが良さそう。

使って感じた点

• 設置
  • 簡単。
• 訪問者に対して
  • スマートフォンからの訪問者ともチャットできるのが良い。
• サイト運営者にとって
  • iOS アプリ・Android アプリがあって、どこでもチャットサポート対応ができる。スタートアップなサービスなど、いつでもユーザーのフォローを出来るようにしたいというフェーズに良さそう。
  • Google Analytics のリアルタイムのように、サイト訪問者の状況がリアルタイムに分かるのが面白い。
  • 1箇所からしかログインできない(Web 版とモバイルアプリで同時にはログインしておけない)という点は注意。

Zopim Lite パッケージは無料なので立ち上げたばかりのサービスや、Blog などに設置してみるのに良いと思う。

• Zopim

(画像は https://zop.im/press-kit より。)

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 ファイルに変換できるようにしておかないとなあ。