HugoでIEの条件付きコメントを使う

Tags: Hugo webdev

Internet Explorerでこのブログの表示を確認していた際、IE8互換モードに切り替えると、なぜか指定したはずのスタイルがいくつか無効になっている。あれーもしかしてこれはIE8でHTML5のタグを認識しないことに起因する症状かな、でもhtml5shivを入れているからその点だいじょうぶなはずなんだけど……などと思いながらHTMLソースを見ると、html5shivを読み込んでいる<script>タグの行がごっそり消えていた。

ちょっと調べてあっさり解決。Hugoのテンプレートエンジン(というかGo言語のテンプレートライブラリ)は、デフォルトではHTMLコメントを削除した形でHTMLを出力するとのこと。これが原因で、ヘッダー部分のテンプレートに埋め込んでいたIEの条件付きコメント(<!--[if lt IE 9]><![endif]-->)が消えていたのでした。以下の公式ドキュメントの記載通りに記載して、無事修正。

Internet Explorer conditional comments using Pipes

By default, Go Templates remove HTML comments from output. This has the unfortunate side effect of removing Internet Explorer conditional comments. As a workaround, use something like this:

{{ "<!--[if lt IE 9]>" | safeHTML }}
  <script src="html5shiv.js"></script>
{{ "<![endif]-->" | safeHTML }}

そもそも今どきIE8向けの対応なんてしなくてもいいのでは、という気持ちもあるけれど、ブログのような文字ベースのコンテンツであれば、レガシーなブラウザであっても読むだけならできるので、ツールやライブラリの選択もやや保守的な方向に倒している(Bootstrap 3とかjQuery ver.1系とか)。さすがにWebアプリ的なコンテンツを作るとなると、古いブラウザは考慮しませんけどね……。


Twitter OAuthの操作の権限はもう少し細分化できませんかね

Tags: webdev

Twitter API 1.1での評判の悪い制限事項や各種リミットが、少しは改善されたりするんでしょうかねえ。なんにせよ、開発者にとって良い方向に進んでくれるとありがたいのですが。


個人的にTwitter APIで個人的に最も不満に思っているのは「OAuthでできる操作の権限が大雑把すぎる」という点。本件、すでに語り尽くされている感もあるが、簡単に説明すると、TwitterのOAuthの権限は以下の3段階しかなく、不要な権限がセットでついてきて痛くもない腹を探られてしまうというお話。

  • Read only (読み取り専用)
  • Read and Write (読み取りと書き込み)
  • Read, Write and Access direct messages (読み取りと書き込みとDMのアクセス)

最も典型的なケースを例にすると、例えば「(認可を得たユーザーのアカウントで)単にツイートだけ行いたい」というアプリ(Webサービス)を作りたい場合、「Read and Write (読み取りと書き込み)」レベルの権限が必要になるが、この権限には以下の3つの操作が含まれている。

  • ツイートする
  • 新しくフォローする
  • プロフィールを更新する

(アプリ認可画面の例)

このように、「ツイートする」操作の権限がほしいだけなのに、「新しくフォローする」だの「プロフィールを更新する」といった穏やかでない操作の権限も押し付けられてしまう。その結果、ユーザーがアプリ認可の画面を見て「なんでツイートするだけのアプリでこんな権限が必要なの……?」と疑問に思い、下手をするとトラブルの火種になったりする。

実際、この仕様に端を発する騒動はTwitter上で定期的に起きていて、「○○というアプリ、必要以上の権限を要求していてすごく怪しい! 危険です!! 拡散希望!!!」みたいなツイートを見かけるたびに「またか……」とげんなりした気分になる。1


この問題が不幸なのは、ユーザーとしてはアプリ認可の際に権限を気にかけるというのはまったくもって正しい態度であり、Twitterが出しているアプリ認可画面で「新しくフォローする」「プロフィールを更新する」と書かれている以上、ユーザーとしては実際にそういったことが行われている(可能性がある)と判断するのはまったくもって妥当な推論であるということ。もちろん、現状のTwitter OAuthまわりの事情を知っている開発者なら「これは仕方ないんですよ……」ということは分かっているけど、一般ユーザーにこのあたりを理解してよというのは無理がある。2

また、アプリ認可画面にて(開発者側からは3段階の指定しかできないにもかかわらず)許可される操作が箇条書きで細かく列挙されている点も、不要な誤解を招く一因となっている感がある。3 あの画面を見れば、いかにも個々の操作の権限が個別に指定できるように見えるわけで、あたかもアプリ開発者が意図的に「新しくフォローする」「プロフィールを更新する」の権限を有効にしているかのように見えてしまう。

アプリ開発者側として対策できることがあるかというと、なかなか難しそう。アプリの説明にて「アプリ連携の画面では“新しくフォローする”や“プロフィールを更新する”といった操作が許可されると表示されますが、実際にはそのような動作は行いません」といった注意書きを書きたくなるが、これはあまり筋がいい対応ではないように思える。アプリ開発者側が「システム側ではこう言っているけど、実態は違うので無視してください」みたいなことを言うのは、かつての「オレオレ証明書」の問題を思い起こさせる。ユーザーが信用するべきなのはあくまでTwitter側が出す説明文だけ、というのがあるべき姿であり、アプリ開発者側の出す説明文の方を信用するような風潮が蔓延するのはあまりよろしくないし。

結局のところ、本件、Twitter側で権限を細分化してもらう以外に根本的な解決策がなさそう。せめて、現状の「Read and Write (読み取りと書き込み)」から「Read and Tweet (読み取りとツイート)」みたいに一部だけ分離するだけでもいいので、対応してくれませんかねえ……。


  1. 実際問題、騒動の要因となっているアプリがあやしい動作をしていそうな事例も多いものの、「必要以上の権限を要求」しているかどうかというとたいていはそんなことはなく「(Twitterの現状の仕様上)必要最小限の権限」である場合がほとんど。
  2. まあそうは言っても、「不要な権限を得ている」と「不要な権限を使っている」の間には相当な距離があるわけで、騒ぐ前にもう少し慎重になってほしいとは思う。
  3. とはいえ、ユーザーにとっては許可される操作が箇条書きで列挙されている方がどう見ても分かりやすいので、文句は言えない。昔のアプリ認可の画面では「アクセスしたり、データーを更新」といった抽象的な表現だったとのことで、それと比べると、現在の表現の方が圧倒的に正しい。

Markdeep: アスキーアートで図を描けるMarkdown拡張

Tags: webdev

MarkdeepとはMarkdown拡張の一つで、その最大の特徴は“diagram”のサポート。

百聞は一見にしかず。アスキーアートで描かれた図を含んだMarkdownが……、

……こんな感じのSVG画像を交えてレンダリングされる。

うーん、どうなんでしょ。一目見て、「もしかしたら便利かも?」と「いやーこれはないわー」の感想が両方同時に出てきた。Hacker Newsでのコメントをざっと眺めてみても、評価が分かれているという感じ。

「テキストから図を生成する」というアプローチは昔からいろいろあって、例えばdot言語で書かれたテキストからグラフ1の画像を生成するGraphvizあたりが代表格だろうか。他にも、昨今のMarkdown等の軽量マークアップ言語の隆盛を受けてか、Markdown等に組み込んで図を出力できるようなライブラリもいろいろあるようだ。ちょっと調べた感じでも、いくつかよさそうなものが見つかった。

この手のソリューションは、だいたいどれも以下の様な性質を持っていて、一般的な「マウスでお絵かき」的アプローチに対するアドバンテージとなっている。

  • 使い慣れたテキストエディタで効率的に図表作成ができる。
  • 肝となる情報だけテキストに書けば、細かい見た目のあれこれはプログラム側がよろしくやってくれる。
  • テキストなので、プログラムでの自動生成も簡単。
  • テキストなので変更箇所の差分が取りやすく、バージョン管理システムとの相性がいい。

一方、このMarkdeepの場合は元データがアスキーアートそのものなので、図を描くのも編集するのも大変そうだし2、変更箇所の差分も分かりづらいだろうし、上記に挙げたテキストで書く(描く?)利点がほとんどないように見える。否定的な反応が多くなるのもうなづける。

しかしながら、このMarkdeep、自分としてはちょっとだけ惹かれるものがある。それは、Markdeepの「図表の元データはアスキーアート」という仕様が、個人的にMarkdownで一番好きな点である「元データが生テキストとしても見やすい」という性質とマッチしているからだと思われる。

前述のライブラリにせよGraphvizにせよ、図表の元データとなるテキストデータは、それぞれのツールが個々に定義したローカル記法で書くことになる。だいたいどのツールでも単純かつ直感的な表記で書けるようになってはいるものの、知らない人が前提知識なしに単独で元データだけを見て、何が書かれているか(何が描かれるか)を理解するのはなかなか難しい。その点、Markdeepの図表の元データの「読みやすさ」は群を抜いている。3

とは言ったものの、このMarkdeepを有効に活用できそうなユースケースがあるかというと、あまり思いつかない。「何らかの理由でプレーンテキストでドキュメントを書かざるをえない制限下において、図を入れざるをえないケース」において、Markdeepのdiagram形式に沿ったアスキーアートで描いておけば、資産として活用の幅が広がる(かも?)、といった感じか。うーん、やっぱり微妙かなあ……。


  1. ここで言う「グラフ」は棒グラフとか円グラフとかのグラフ(チャート)ではなく、「有向グラフ」とか「無向グラフ」とかのグラフ。
  2. エディタによっては、アスキーアートを描くための機能とかプラグインとかもあったりするらしいですが。他にもasciiflowなんてサービスもある。
  3. その分、「書きやすさ」は大きく犠牲になっているわけですが……。