Rmenuの帳票はTeXを使用します
TeXは宣言型言語 TeXは組版のためにソースを記述し、DVIに変換する。 DVIは、プリンタへの出力書式である。 DVIは、pdfへの変換が容易です。 TeXは、SQLに良く似ていると思う。 SQL文を作成し、サーバーに問い合わせると結果の表が返ってくる。 TeXファイルを作成し、platexコマンド、dvipdfmxコマンドを実行することにより。 結果のpdf書類が作成される。 書類の中に、データベースと連携した値、文字列、画像などが組みこめれば、レポートになる。 手続き型言語と宣言型言語ではインピーダンスミスマッチがおこる。 レポート帳票は、顧客毎にケースバイケースの要望。 人の個性、気分、お国柄、法改正により様々に変動する。 「O/R インピーダンスミスマッチ」なんてレベル話ではない。 Rmenu（Rubyフレームワーク）では、これらのミスマッチを取り持つために、Jsonファイルを利用している。 Rmenuは、下地忠史氏が考案し長年利用してきた手法を組み込んだフレームワークです。 2002年に特許も公開されています。 動的データ処理システムhttp://www.j-tokkyo.com/2002/G06F/JP2002-182937.shtml Rmenuの開発は、2011-11頃から、システム記述言語にruby、データベースサーバーにMySQL、PostgreSQL、 帳票処理にTeXを使用する。 Webアプリとして利用するため、Rubyを次のような構成で利用できるように開発が進められています。 １．WEBrick + Rack ２．Apache + CGI ３．Apache + Passenger + Rack ４．Apache + Tomcat + JRuby + Rack Rmenuは、全く新しいシステムとして開発されたものではありません。 下地氏の考案した、動的データ処理システムは、 汎用機での分散バッチ → ハイパーカードMAC → Webtribe → Bmenu → Rmenu のように ユーザーの要望、環境の変化に対応しつつ、利用されてきた手法です。 Webtribeはjava、Bmenuはphp、Rmenuはrubyをシステム記述言語として開発されました。 現在は、日本語処理の文字コードもUTF8で統一することが、目的のひとつです。 下地氏は、この手法で40年電算器業界で活躍してこられた方です。 Rmenuの開発は、オープンソースソフトとして公開することを目的に 2011年11月頃開始しましたが、動的データ処理システムの手法は長い間、 基幹業務の現場を熟知した作者が利用してきた実績ある手法です。 動的データ処理システムとは、ユーザがプログラムを行わないシステム。 入力パネル、データベース、データ処理、帳票出力といった機能を プログラミングすることなく構築する。データ管理システムです。 ユーザサイドでのプログラミングも勿論可能ですが、 できる限りプログラミングをしないことを目指しています。 プログラミングをせずにシステムを構築するための手法として、 モデル・ドリブン・アーキテクチャがあります。 この手法は、基幹業務を、問題領域としたドメイン固有言語 （domain-specific language、DSL）による解決手法をとります。 下地氏は、よく「疎結合」というキーワードを唱えられます。 フレームワークの構成手法が、モザイクアートのような小さなモジュールの集まりで構築されます。 縦糸、横糸の平面的な組み合わせではなく、多次元に関連しているインターフェースです。 基本仕様は、JSONファイルに定義されファイル自身が、ドメイン固有言語です。 基幹業務に必要な機能追加があれば、仕様を追加、処理モジュールを拡張できるようになっている。 JSONファイルも、最小単位の機能別に分割されて定義されています。 JSONファイルは、システムへ作業のリクエストをしレスポンス得るための仕様定義書です。 システム側は、JSONファイルを順に読取、順次処理、明細データ等のループ処理を行います。 冗長なようですが、CRUD処理に対して、それぞれにJSONファイルを定義します。 この手法は、特許公開されている「動的データ処理システム」の実装例です。 JSONファイル、プログラミングされたモジュールが疎結合により、機能を実現するため その内容に初めて接すると、「何を意味しているのかわかりません。」 複数のシステム間でコマンドやデータをやり取りするために最も適しているのは プレーンなテキストでしょう。 JSONファイルに仕様を定義、データセットとして利用する、 ほとんどの言語においてJSONは単純な処理で書き出しや読み込みができる。 それぞれの言語仕様により、演算のためメモリ上にテーブルのレコードデータが 読み出される。 メモリ上で処理されたデータが、テーブルに書き戻される。 演算のための入出力コストがプログラミングする上で最も大きい。 電卓のように、電源を入れてやりたい計算だけが直ぐにできればどんなに幸せなことか。 システム、言語、OSが違えば、入出力の方法がすべて異なる、積み木崩しの繰り返し。 どのようなシステムでも、同じ手法で簡単に入出力する方法が現場では必要であった。 どのシステムでも共通なのは、テキストファイル。 テキストファイルに、インタプリタのような言語の文法を持たせすぎると、 すべてのシステム上でインタプリタを構築する必要が出てくる。 極限まで、プログラミングを最適化するためには、記号化・モデル化が必要である。 RequestとResponse、InputとOutputのための最低限の制御情報をJSONファイルに定義する。 同じようなテキストファイルであるXMLも利用できるが、 パーサー作成の容易さ、容量の小ささでJSONに軍配が上がった。 以上、下地氏と居酒屋で酒を酌み交わしながら話したことを記す、正確性は保証しない
