|
ソースその2です。
その1はこちら。
|

- >
- コンピュータとインターネット
- >
- コンピュータ
- >
- ソフトウェア
こんにちは、ゲストさん
[ リスト | 詳細 ]
|
ソースその2です。
その1はこちら。
|
|
ソースその1です。
その2はこちら。
|
|
前の続き。
さて、いきなり言い訳ですが、
天の孔雀、Ruby結構初心者(10月中旬に始めた、かつ11月は何もやっていない、12月に再開)のうえ、
その他のコミュニティに積極的に参加中ゆえ、
なんだかもう、レシピに書いてあることしかできませんでした。残念。ゲソゲソ〜orz
とりあえず、IPAのフォントをインストールして、
サンプル通りのソースを書いておきました。
と、いいつつ、サンプルとは異なるところがあります。
tableを表示する際の横幅に関する引数です。
つまり、サンプルにあるような、
:width => {0 => 100, 1 => 120}
のような形式で指定すると、ランタイムエラーが発生します。
ここだけは注意しましょう。
出力した結果はこんな感じです。
いや、Rubyは触れば触るほど面白くなりますね。
ほんとうはJSON形式のデータをPDF出力するようなライブラリをつくろうとしたのですが、
それにはあと1週間くらい必要ですね。
年内はかなり忙しいので、ちょっと無理そう…
|
|
なるものに参加しました。
本の紹介
ここでは、このレシピにある135「PDFを作成したい」について紹介します。
帳票ソリューションというのは、
開発者にはそのニーズというのが分かりにくいです。
しかし、国家への申請とか、SOX法対応などで、
各種の取引や記録などを容易には修正のできないけど容易にデータを再生できるフォーマットで
保存するというニーズがあることは確かです。
そのフォーマットの代表格がPDFです。
で、RubyでPDFを出力しようじゃなイカ?
というわけでございます。
天の孔雀さん(a.k.a mike_neck)の実行環境
その1
その2
RubyでPDFを出力する場合、
Prawnというgemを利用します。
これのインストール方法は次のような感じです。
実行環境その1
実行環境その2
…Linuxで自前ビルドするとzlibがなくてgemがまともにきどうしないらしい。
そのあたりはこのへんを参照して修正して、いざインストール。
インストール完了。
|
|
SQLite本体のコードが67ksに対して、テストコードが4m5678ksらしい。 679倍の規模のテストがあるわけで、SQLiteプロジェクトの品質に対する熱意がよくわかる。 天の孔雀はかつて回帰テストの自動化をするためのプロジェクトに参画することがあったが、回帰テストをコーディングするためには、たしかにかなりの労力が必要であることはその時に分かった。ただ、残念ながらそのテストコードはMSVBScriptのスキルが必要であったが、そのプロジェクトにいる人が皆COBOLな人たちで、なんでわざわざVBScriptを覚えて、テストコードを書かなければならないのか理解してもらえなかった。彼らの言い分としては、これらの画面の仕様は自分たちの頭の中に入っており、テストコードを記述しなくても、何を試験すればいいのか分かっている、ということだった。 ちなみにCOBOLプログラムを検証するVBScriptのコードの規模は同等の規模であった。残念ながら、私はプロジェクトを離れたため、テストコードを記述する人がいなくなってしまったが、今でもこのCOBOLプログラムは人力によってテストが行われているらしい。一応、テストスクリプトを最短で作成する方法を記述したドキュメントは残したのだが、COBOLの世界からは出ることはなかったようである。 巷には特定の開発言語のプログラミングに関する書籍は大量に溢れているが、テストに注力して書かれている書籍はかなり少ない。そうとうニッチな本である。言い換えるとプログラマの人々はテストの重要性を理解しながら、テストを効率よくやるということには目がいかないのではないかと思う。それは要求された仕様をどのように実現するかということだけに思考が向かっており、仕様が満たされているかどうかを検証することはあとで考えればいい、みたいな風潮があるのかもしれない。
そう、そういえば同じ部署で以前、天の孔雀に少し火が付いているプロジェクトで、手が足りないので結合試験を一週間で実施してほしいというオーダーが下されたことがあった。一応、引き受けてはみはしたものの、設計には何のかかわりもない私には、残念ながら実施することができなかった。テストの目的が不明、テストの対象となるドキュメントが未整備、実装だけに特化している設計書、これらからテストを導き出すには到底無理であった。その他の要因にもより、(天の孔雀は口が悪く思ったことはすぐ口に出すので、これがプロジェクトの一部の人にはムカつかれたのであろう、私に対して苦情が何件も届いたらしく、部署のトップマネージメントは私をいい加減にしてくれと言ってテンションをさらに下げたので、)私は一週間後に「無理です」と言って断ってしまった。 テストは理想的に言えば、設計を行ったものがテストを作成することが望ましい。設計とは何の関係もない人にテストを無茶振りするのはマネージメントの失敗としか言いようがない。逆に言うと、設計の段階で試験をどのように実施していくことがイメージ出来ていなければ、システム開発はどつぼに嵌まるのは間違いない。
だから、SQLiteのテストコードの多さは、このプロジェクトがテストをどう考えているかを如実に表す数値であり、これこそ品質を大事にするという考え方の物的証拠なのだと思う。 また、テスト工程というのはテスト実施→バグ発生→故障票記入→再現確認→プログラム改修→構成管理→再リリースという手順があるだけに、意外と生産性が低くなりやすい。プロジェクトによってはテストの生産性がコーディングよりも高めで設定されている場合もあるが、むしろテストの生産性は低いと考えたほうが現実的なのかもしれない。実装の生産性に対してテスト工程の生産性は半分くらいと考えたほうが適切かもしれない。しかし、大抵のプロジェクト計画ではテスト工程の生産性は実装の生産性よりも高く見積もっているところがほとんどであろう。だが、もう一度SQLiteのテストコードの規模を見れば、テスト工程のほうが実装工程よりも作業量が多いというのはあながち嘘とは言い切れない気がする。
そこで、天の孔雀としては、設計の成果物として、テスト項目票を入れるというのがいいのではないかと考える。また、フレームワークの設計などで、極力POJOを使うようなアーキテクトを採用したりするのも方策の一つなのではなかろうか。な〜んて、適当なことを考えながら、『現場で使えるソフトウェアテストJava編』を読みつつ、今日は眠ることにする。 |
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |