Markdown記法を使いこなしたい

最近、公私ともにプロジェクト管理にredmineを使うことが増えてきた。
redmineは、便利なツールだが気になるのが、記述に使っているtextile記法。以前は、tracやpukiWikiを使っていたこともあり、なにかツールを替える都度に新しい記法を覚えるは面倒くさい。ましてや、最近はプログラムでhtmlタグを書くのも色々と簡易的な記法が増えてきて、それはそれで便利だがちょっと、もう少し統一してもらっても良いような気がする。
また、昔からExcelやdocでドキュメントを作ることも嫌いだった。やむを得ず作る時もあるのだが、普段使いではない。textで書いて置けば検索が楽だし、ポータビリティも良いではないか。
なにが、言いたいのか。つまり、一つの記法で全てに対応出来ないだろうかと言うことだ。
表:アプリケーション毎に異なる記法

| case     | style     |
|----------|-----------|
| redmine  | textile   |
| sphinx   | markdown  |
| trac     | trac      |
| pukiWiki | hatena    |

方針として できる限りmarkdownで書く。pandoc コマンドで様々な形式に変換する。 とした。

• テキストファイル(生)を見た時に、普通の人が一番判りやすそうなのは、markdown形式だと感じたので、これを基準にする。
• pandocコマンドは、各OS向けにインストーラがそろっているし、変換のバリエーションが多く、導入しやすそう。

pandocの本家サイトはここ
pandocをインストールしてみた。早速、テストしてみる。

Markdown記法で書かれたサンプル

各書式の記述は、いろいろと方言があるようだ。本家の説明が一番良いだろう。

本家の各書式説明
markdownの文法
Markdown記法は結構、書き方が乱暴でもなんとかなりそうな感じ。h1タグはh1.や#でも良いし。
ex)samle.txt

今日行うべきテスト
===============

準備すること
----------
#. テスト要件のヒアリング
#. テストデータの作成
#. テストケースの作成

テスト環境
---------
* ユニットテスト
* 統合テスト
* 自動化スクリプト

### 気になること ###

テスト  備考
------ ----- 
テスト１ テストサンプル
テスト２ テストサンプル
テスト３ テストサンプル

<pre>

    | file | ----- lan ------- | server | ------ (wifi) -------- | client | 

</pre>

html, textile, rst 形式に変換する

markdown形式のファイルをhtmlに変更する。

$ pandoc sample.txt -s -t html -o samle.html
// -s standalone オプション header情報とかつけてくれる。
// -f (from)元の形式 defaultは、markdown形式か？あるいは自動判別か？
// -t (to)変換先の形式
// -o (out)出力先ファイル

redmineとかで利用するためにtextile形式に変換したり、sphinxで利用するためにrst (reStructured Text)に変換したりする。

$ pandoc sample.txt -t textile -o sample.textile
$ pandoc sample.txt -t rst -o sample.rst

おまけ:: S5形式でプレゼンテーションスライドを作成する

S5とは、A Simple Standards-Based Slide Show System で、要するに htmlとjavascript,cssで作成されたhtmlドキュメントだ
S5の本家サイト

$ pandoc sample.txt -s -i -t s5 slide.html
// -i list itemを順番に表示させてくれる

プレゼンテーションファイルは上記の通りで変換出来るが、補助スクリプト(javascriptとかcssとかテンプレート)を入手しなくてはならない。

1. 上記のs5本家からS5本体をダウンロード
2. 解凍して、最初の階層にあるuiフォルダを上記のslideファイルと同じディレクトリにコピーする
3. ディレクトリ名は、s5に変える （あるいはslide.htmlの中の指定フォルダをいじる)

これで、プレゼンテーションが完成。上記のファイルをプレゼンテーション
なんか、最後の図とか表示されないし、使い方をもう少し研究しなければならないが

---

課題が残った

ここまで来ると、何でもやりたかったのだが、色々制約や勉強しなければならないことが多い。

• pdfツールも同梱(markdown2pdf)が、日本語は通らないらしい
• texも使えるが、TeXはすっかり忘れてしまった
• epubも出来るらしい (いや、これは形式の問題より内容を充実させないと哀しい電子書籍になってしまう)
• 画像の扱いについて研究しなければ
• markdown形式では、inline htmlでのtable形式がダメのようだが....
• サンプルの記述がおかしいかったので、修正 (2012/5/27)

WebSocketのRFCを一寸だけ訳す

HTML5と共に気になる技術があります。WebSocket。TCPソケット通信をHTTPプロトコルの下で実現する技術であり、試みだと想像しています。XMLHttpRequestを利用するAjaxは、ドキュメント全体の更新で高負荷となるHTTPと異なり、初めて観た時に革新的だった。でもプログラムレベルでは、やっぱりなじまない。もう少し、他の部分とは独立的にTCP送信を実装したいもんだと、WebSocketに期待しています。
そのWebSocketですが、RFCが公開されていたので、さわりの部分だけ訳してみました。

原文は、ここです。
http://tools.ietf.org/html/rfc6455

いやあ、酷い和訳です。あくまで自分の勉強のためなので、決して訳を鵜呑みにしないように。そもそも、日本語になっていないような気もするし、概要と導入部の最初の節だけなので、具体的な内容には乏しい。

ウェブソケット プロトコル

概要
ウェブソケット・プロトコルは、管理された環境で委託されたコードが動いているクライアントと、そのコードが通信を受け取っているホストとの双方向通信を可能にします。
セキュリティモデルは、ウェブ・ブラウザに一般に使われている原初的なセキュリティモデルです。プロトコルは、T通信を開始時の通信確定手順と、それに続くTCP層の基本的なメッセージ・フレーム群で構成されています。
この技術の狙いは、サーバとの双方向通信を必要とするブラウザベースのアプリケーションに、XMLHttpRequest、iframe、ロング・ポーリングのような複合的なHTTP接続に頼らない、機構を提供することです。

1. 導入（イントロダクション）
1.1. 背景
歴史的に、クライアントとサーバ間の二方向の通信を必要とするウェブアプリ（チャット、ゲームとか）は、更新確認のため、上位への通知を送信する間、(ドキュメントの表示のためのHTTPではない）別のHTTPコール(RFC6202)を使ったサーバへのポーリングを多用してきた。

この結果は、様々な問題を生むことになる。
* サーバは、それぞれのクライアントと、クライアント数だけのTCP通信を強いられる。ある通信は、クライアントに情報を送り、またある通信は送られてくるメッセージを受け取るために。
* 通信の成立は、非常に負荷が高い。それぞれのクライアントーサーバ間メッセージは、(そのための）HTTP headerをメッセージ毎に持っている。
* クライアントサイドスクリプト(Ajaxのような)は、送信結果を結びつけるために、送信と受信の管理（マッピング）を強いられる。

より単純な解決は、双方向の流れをまとめた一つのTCP接続を使うことであるべきだ。これが、ウェブソケットプロトコルの提供するものだ。WebSocket APIを組み込むことで、ウェブプロトコルは、ウェブページから、遠隔地のサーバへの双方向通信を実現するため、HTTPポーリングに代わる別の手段を提供する。
同様の技術は、様々なウェブ・アプリケーションで使われることが可能だ。ゲーム、リアルな証券情報ニュース、複数人による同時編集アプリ、リアルタイムな情報発信機能を提供するユーザインターフェースなどなど。

ウェブソケット プロトコルは、現存する基盤（プロキシ、フィルタリング、認証）からの利便性を得るために、トランスポート層でHTTPを利用している現存の双方向通信技術を捨て去ることができるように設計されました。

== このあたり、全くお手上げ ==
そのような（現存の）技術は、効率と信頼性のトレードオフのもとで実装されている。なぜなら、HTTPは、本来、双方向通信に利用されることを意図していなかったからである。
ウェブソケットは、その目的を、既存のHTTP基盤のもとで、既存のHTTP双方向通信技術に割り当てている（？）。それは、80ポートや443ポートで動作することで、HTTPプロキシや媒体（それが、現在の環境への特殊な使用を意味することであっても）をサポートすることだ。
「 The WebSocket Protocol attempts to address the
goals of existing bidirectional HTTP technologies in the context of
the existing HTTP infrastructure; as such, it is designed to work
over HTTP ports 80 and 443 as well as to support HTTP proxies and
intermediaries, even if this implies some complexity specific to the
current environment.」
== ここまで ==

しかし、設計では、ウェブソケットをHTTPのみに制限していないし、将来の実装では、全体のプロトコルを再構成する事無く、専用のポートのもとで、より単純な通信確定を使うことが出来る。
最後の点は、重要である。なぜなら、双方向のメッセージ通信の際の交信パターンは標準的なHTTP交信にぴったりとはあっていないし、いくつかのコンポーネントの一寸変わった取込を実現できるからだ。

新しいブログを始める

プログラムの勉強の記録を残しておきたく、ブログを始めることにした。日常のことは別のブログがあるので、ここは技術オンリの予定。

bloggerの用意したテンプレートには良いものが無かったので、bTempleteからシンプルでコードを書いたときに見栄えがしそうなものを選んで、テンプレートファイルをアップした。
調整したことは次の点。

• id=topbanner のタグ内のimgタグを削除。
• Google adsenseなどの不要なガジェットを削除。
• ソースコードをハイライト表示してくれるwidgitの導入。
• bloggerの共有ボタンが見えない点を修正。テンプレートをいじりまくった後、ここを参照して修正
  
• (2011/5/8) IEやFirefoxでは画像が潰れることが判明。理由がわからないので標準のテンプレートに変更


• (2011/5/8) preタグのborderやpaddingがIEやFirefoxでは上手く行かない。試行錯誤で修正

まだ、いろいろと調整しなければいけないし、リンク切れもあるが、徐々に修正していくことにする。まずは Let's show time !