まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:doc

業務の中でワードドキュメント(.docx)でレポートを書く必要がありました。

個人的にワードはあまり得意ではありません。フリーレイアウトで書きにくいし、読みやすいとも思えないし(こっちはワードでよこせと言ってくる側の責任だけど)、もう少しましなツールはいくらでもあるし、、、 僕自身はどうしても.doc/.docx 形式のファイルを開かなければならない時にだけ(ファイルをダブルクリックした結果として)ワードを使っていて、自分からワードで書くことはほとんどないのでした。

でも年に一度くらい、今回のように「ワード」指定でドキュメントを請求されることがあります。そんな時に便利かも、と思えるツール pandoc に出会ったので、その紹介をします。

pandocドキュメントのフォーマット変換ツールです。マークダウンをはじめとするテキストドキュメントを別の各種フォーマットに変換してくれます。この pandoc がマークダウン(.md) -> ワードドキュメント(.docx) の変換に対応していることを知り、早速使ってみました。


インストール

pandoc は多くのシステムの一般的な方法で導入できます。Ubuntu であれば apt-get コマンドを実行します:
$ sudo apt-get install pandoc

他システムの場合は適当にググって調べてください。


使い方

シンプルな使い方は以下のように(出力ファイルフォーマットを拡張子で指定して)実行します:
$ pandoc xxx.md -o xxx.docx  (マークダウン方式の xxx.md を、ワード形式である xxx.docx に変換)

試しに先日のブログを書いた際に作成した Github のリポジトリREADME.md をこのツールでワード変換してみました:
$ pandoc README.md -o README.docx

結果、こんな感じ↓のマークダウンファイルが・・・
2018071801

2018071802

↓こんな感じのワードファイルに変換されてました:
2018071803

2018071804


テーブルとかもちゃんと再現されてますね。細かく変換スタイルを指定することも可能なようですが、ワードのためにそこまで時間を使いたくないあまりこだわるわけではないので、これで充分。


しばらくはマークダウンで編集して、マークダウンでレビューとかもして、最後の最後にワードに変換して仕上げ、みたいな感じで使うことになりそうです。

 

IBM Bluemix から提供される各種 API の使い方をリファレンスで調べていると、確かにドキュメント化されてはいるのですが、具体的にどう使えばいいのか? と悩むことはないでしょうか?

例えば、このリンク先には Watson の Speech To Text サービス内の /v1/sessions/{$sessionid}/recognize 関数の使い方についての説明が書かれています:
http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/apis/#!/speech-to-text/recognizeSession

2015072101


このページを見て、具体的にどのようなエンドポイントにどのようなヘッダとパラメータでアクセスすればよいか、わかりますか? 分かる人はすぐに分かると思いますが、ちょっとクセのある書き方なので、具体的な指定方法がイメージしにくいかもしれません。その確認の意味も込めて説明します。

まず、上記ページの "Parameters" にはこのように書かれています:
2015072102


この表の "Parameter" と "Parameter Type" と書かれた2列に注目して、この2列だけを取り出してみるとこのようになります:
ParameterParameter Type
Content-Typeheader
session_idpath
bodybody
continuousquery
max_alternativesquery
time_stampsquery
word_confidencequery
inactivity_timeoutquery
Transfer-encodingheader
X-WDC-PL-OPT-OUTheader


"Content-Type" パラメータのタイプは "header" ということになっています。これが何を意味するかというと、「Content-Type を HTTP ヘッダで指定する」ということを意味しています。Transfer-encoding や X-WDC-PL-OPT-OUT も HTTP ヘッダとして指定する必要がある、ということになります。

次に "session_id" パラメータのタイプは "path" です。これは「API エンドポイントの URI を指定する際のパスの一部として session_id を指定する」ということです。実際、この API のエンドポイントは /v1/sessions/{$sessionid}/recognize であり、この {$sessionid} 部分に session_id を指定することになるので、確かにパスの一部に session_id を指定していると言えますね。

そして body パラメータタイプは body 、つまり body に相当する情報をポストの本文として指定することが想定されている、ということになります。

最後に continuous や max_alternatives パラメータのタイプは query です。これはエンドポイントのクエリーとして、例えば /v1/sessions/{$sessionid}/recognize?continuous=true&max_alternatives=5 のように指定することを意味します。


以上をまとめると、リファレンスのパラメータータイプはこのように理解すればよい、ということになります:
(1) path はエンドポイント URI の一部に埋め込む形で指定
(2) query はエンドポイント URI のパラメータとして指定
(3) header は HTTP ヘッダとして指定
(4) body はポストの本文として指定

この記述ルールがわかっていると Bluemix の API リファレンスも読みやすくなりますね。


このページのトップヘ