月別アーカイブ: 2014年8月

IOモナドに汚染される感覚。

 IOモナドに汚染される感覚。実用的なプログラムには必ずI/Oがある。必ずある。にもかかわらず純粋関数型言語であるHaskellにおいてIOはモナドとして表現されている。モナドが絡むと面倒が一気に増えるように感じる。実際増える。ディレクトリ一覧を操作したいだけなのにIOモナドが付いてまわる。乱数を使いたいだけなのにIOモナドが付いてくる。現在日時を使いたいだけなのにIOモナドがひっ付いてくる。IOモナドを扱う関数を呼ぶ側にも必ずIOモナドを扱わせないといけない。コマンドラインパラメタにはIOモナドが付いてくるのでプログラムのmain側には必ずIOモナドがありるが、そこから呼ばれる関数にはIOモナドがある必要はない。しかし例えば乱数を使うとなるとその関数を含めそこからmainまでの全ての階層の関数にIOモナドを付けなくてはならない。これがIOモナドに汚染される感覚となる。IOモナドを封じ込める方法はあるようなのだが邪道とされている。困ったもんだ。モナドの何が面倒かって、mapでなくmapMを使わなくてはいけなくなる。ロジック的には普通にmapで表現できるはずのことがmapMでないと表現できなくなる。これって関数型言語一般の問題じゃないですよね。純粋関数型言語だからこその問題ですよね。しかもIOモナドはHaskell特有の機能。簡単な問題を面倒臭く解くことになっちまう。

 例えば指定したディレクトリ以下のファイルリストを得るコードで再帰の時にmapMを使う。ロジック的にはmapで十分な部分なのだがIOモナドのおかげでmapMになってしまっている。普通にmapで書くべき部分でmapMなんて取って付けたような変な名前の関数を使うのはなんというか気色悪い。モナドを導入して得たものは参照透過性。参照透過性や正格性がどれだけ大切かわからないが、Haskellでは数千行が限度で、数万行は書けない、仕事には使えそうにないと感じた。IOモナドに汚染される感覚のせいである。

 なんというかひどいツンデレですね。汚れ仕事は全部モナドに丸投げ。

 ちなみにPythonもインタプリタのまま(コンパイラでのチェックなし)では数万行は書けないと感じる。ScalaはJavaやC/C++/C#と同じように数万行は普通に書ける。不純な(^^;)言語なのでモナドが漏れだすこともない。


PCブラウザ型EPUB Reader 「AH Reader Preview 2」

ブラウザベースのEPUBリーダーを企業・団体向けに提供開始

WindowsとMac OS X用で使えるEPUBリーダー「AH Reader Preview2」を開発・限定公開しました。

ビジネス文書EPUB化普及促進に。ブラウザベースのEPUBリーダーを企業・団体向けに提供開始のご案内

数多くのEPUB リーダー アプリが出回ってはいますが、PC用のブラウザ型リーダーの数は限られるうえ、業務用となると、あるのかないのかさえ分かりません。ユーザーが個人的に業務に使用してはいても、提供側は「業務用」とは銘打っていないものの方が多いかと思います。

さて、このEPUBリーダーは、GoogleのChromeまたはChromiumベースのChrome互換ブラウザに拡張機能として組み込んで使う「Chromeアプリ」です。Googleといえば、すでにIDPFが配布しているReadiumがあるではないか、と思われますが、AH Reader Preview2は、業務用なので、Readiumと異なる大きな特長があります。

メモ機能

iOSではiBooks、Androidでは、Google Playブックスで利用するようなメモ機能(テキスト)が使えます。
PC用ブラウザ型EPUB リーダーでは珍しいのではないでしょうか。既にEPUB リーダーを駆使・活用している方にとっては「あって当然」の機能ではあるので、「ようやく」といえるかもしれません。

EPUB閲覧中、貴になったところにメモを挿入できます

本EPUBリーダーは、Chromeストアから限定配布するほか、関心をお持ちの方に直接提供致します。

提供方法等、その他詳細な機能確認、制限については、CAS-UBブログ内「ビジネス文書EPUB化普及促進に。ブラウザベースのEPUBリーダーを企業・団体向けに提供開始のご案内」でご確認ください。


DITA 1.3 – Troubleshooting

2015年第1四半期目標のDITA1.3ですが、やはり目玉としてはトラブルシューティング記述の強化でしょう。いろいろなところから早く実装して欲しいという声が上がっていたものです。

まず新たな情報タイプ(トピック)としてのトラブルシューティングは当然として、その他にも既存のtaskトピックの中にトラブルシューティングをちょこっと書けたり、それからnote要素のtype属性に”trouble”という属性値が追加されるみたいです。

今までだってトラブルシューティングは(それなりに)書けたわけですが、こうしてセマンティックにきちんと記述できるようになるということは、後々のコンテンツ再利用にはうれしいですね。


DITA 1.3 – Branch filtering

DITA1.3の仕様がもうほぼ固まっているようですね。2015年第1四半期目標のようです。

https://www.oasis-open.org/committees/download.php/53798/Master_Presentation_14.pdf

これを見るとずいぶんと盛りだくさんの機能拡張が行われるようです。
個人的におもしろそうだなと思ったのは「Branch filtering」という機能です。

<topicref href=”parent.dita”>
 <ditavalref href=”conditions.ditaval”/>
 <topicref href=”child.dita”/>
 <topicref href=”child2.dita” audience=”abc”/>
 <topicref href=”child3.dita”/>
</topicref>

こんな感じで使うようです。

今まではDITAVALはビルド毎に1つしか指定できなかったと思うのですが、このサンプルを見るとどうやら部分的に別のコンディションを当てることができるみたいですね。
たとえば、グローバルフィルター(既存のDITAVALの機能)でLinuxに関する記述はすべて出力するように設定しておいて、今回追加されるBranch filteringの機能で、出力する情報をLinuxの特定のバージョンのものだけに(部分的に)絞り込む、というような使い方を想定しているみたいです。

まあ、きっとトピックの再利用性は高まるでしょう。使いこなせれば、ですけど…