2012年10月08日

思考力を身につけることはできるのか? (1/4)

思考力、論理力(ロジカルシンキング)、整理術等、考える力を身につけるための本は多いです。
ですが、これらの本を読んで理解し実践できる人間は、概ね最低限の能力を有している場合が多く、最低限の能力を有していない方は、これらの本を読んでもさっぱり実践できないことが多いと思います。

本に記載されていることが間違っているわけではありませんが、できない場合は、「なぜできないのか」、「できるようにするには」の実践がないことも大きな障壁でしょう。通常はこのような本には、「こうすればいい」が書かれていますが、それを実践できるなら実践できています。つまり、最低限の能力として形容した能力(よく地頭とも言われますが)がなければ実践できず、ある人は本を読んでも実は知らず知らずに実践できていることも多く、理論を得られますが、実際はほんの少しの向上にしかならないことが多いです。


問題なのは、その最低限の能力を有していない場合です。


彼らはそもそも、考えるということをしていないのです。最低限の能力とは、考えられる力ではなく、考える力でもなく、考えるという行為ができるかどうかです。その結果答えが出る/出ない以前に、考えると言う行為ができない人は、たった少しの意味不明なものがあると、全てが意味不明に連鎖的に陥ります。そして、分かっている部分から少しでも読み取ろうという意識さえなくなり、完全に放棄します。その結果、何が分からないか分からないという状況になります。

彼らは少しでも理解できないものがあっただけで、全てを理解できないものとし、少しでも理解しようという気持ちさえなくなるのです。そんな彼らは「全て自分が分かる言葉に置き換えてほしい」という、自分の能力がどの程度かも表現せず、ただただ自分のレベルに合わせるように要求をはじめ、最悪の場合、最終的にはその要求を満たさない相手が悪い、理解させようとしていないというように考えはじめます。
そして理解しようという気持ちは何もなくなり、放り出してしまいます。

最低限の能力と言いましたが、能力以前の単純に心構えの問題ともいえます。
考える力がある人間は理解できない部分を無視して理解できたところだけを読むか、理解できたところや前後の文脈から何とか理解できない部分を推し量ったり、補間しようとします。その結果、100点はとれなくても十分な合格点にその場で至るケースが多いです。合格点には至らなくてもある程度の情報を得たり、後から十分情報を補間できます。つまり、理解することを諦めていないのです。

単純に理解を諦めている節が多いのは事実に考えます。長時間考えているように見えますが、実際は眺めて単に答えが実は隠れていないか、観察や調査、整理、推測ではなく、そのものずばり、答えそのものを表面的に探しています。結果なければ、それ以上の観察や調査、推測を行うことなく、断片的に理解したこともまとめず、「全て理解できない」よって「分からない」に至ります。この全て理解できない状態を、分からないと形容するがゆえに、思考力がない、論理力がない、整理できない、考えられないに結び付けられて能力が判断されます。

先にあげた書籍は、この理解を諦めない人のために書かれた本です。
その理解できる部分から理解できない部分を理解できた状態にするための手法が紹介されています。そのために、どのように観察するのか、どのように調査するのか、何をどのような方法で分類・整理するのか、どうやって理解できない部分を推測したら良いか、その方法が記述されているのです。つまり今まで合格点にならなかった「理解できなかった個所」を、あらゆる方法論を用いて合格点になる推測等の結果「理解できた個所」にするための所作と心構えに近いことが書かれています。その前提はやはり諦めない人間です。そして、その所作と心構えをある程度持った人(これが最低限の能力があると形容されたもの)が読むために、さらに能力向上につながります。なぜなら、自分に足りないものを本から推測等ができるからです。その所作と心構えを持たない人は、どんなに読んでも何も得られません。おそらくその本を読んでも、理解も共感も何もないため、結局自分には理解できないとなります。最後には自分に足りないものを推測することもなく、本を閉じるでしょう。

結果、思考力は身に付かない人には身に付かないまま、鍛えられないままとなってしまいます。ですが、思考力というが身に付かないというのは本を読む、上記のような忍耐力みたいなものがあるかどうか、それ以前のように考えられます。

2012年10月07日

責任を取るということは、どういうことなんだろうか?

「責任はどうやって取るつもりか?」

こう聞かれても、責任のとり方なんて簡単にはわからないと思いませんか?
・会社をやめればいいのか?
・謝ればいいのか?
・給料が下がればいいのか?
・始末書を書けばいいのか?
・それとも損害賠償すればいいのか?

そして、責任を取らなくてもいいということも分からないと思いませんか?

それらはつまり、責任とは何か?責任の所在はどこなのか?明確では無いから発生しているようにも思えます。

私は上司の立場にはありませんので、最終の責任のとり方というのは会社を辞めることまでであって、それより上の損害賠償等の責任は、よっぽどのことをしないかぎりは発生しないでしょう。でも通常は、プロジェクトにおいても仕事においても、何かあったとしてもそこまで責任をとるということは発生しません。

同時に責任と反対の無責任もどういう状態なのか分からないと思いませんか?

会社では「あの人は責任を取らない」とよく思います。それは私が勝手に思っていることです。
でも、よくよく考えると、じゃぁ何をしたら責任をとったことになったのか、それを考えていなかったように思います。

社会人でも、会社員としても、役職なしの社員、主任、課長、部長、さらに上の立場、
次に役員の立場、執行役員や監査役、社長や副社長、さらに上の立場、
株式会社においては、株主もいます。

会社内の役職員における立場もあれば、プロジェクト上のプロジェクトマネージャー、プロジェクトリーダー、サブリーダー、営業、いろいろな役回りもあります。

それぞれの責任範囲とは一体何なのか?
そして、それぞれどこまでの権限があるのか?
お金はどこまで使えるのか、何を決定でき、何を決定できないのか?
何かあったらどうするのか、誰にエスカレーションしていくのか?
そして、失敗した時はどうしたらいいのか?

「そんなことは言われなくても当たり前のように分かっていろ」と言われるのかもしれません。
それは私が不勉強なのだと思います。でも、それはあくまで暗黙的です。

定義すればするほど、逆にがんじがらめになるとも言えます。それが身動きを取れなくしてしまう。なければ、ある程度状況や行間を読んで行動し、補間できる場合もあるので定義しないと言えます。

責任というものを考えて行動するのは非常に難しいです。

が、一つだけ誰でもできることは、「無責任ではいけない」「これは私が責任を持って最後まで面倒を見る」という心がけは持てると思います。最低限、「自分には責任はないから」という考えを持たないようにしたいと考えました。

2012年07月17日

Struts1のhtml:checkboxではまりました。。。2

ちなみにですが、Struts1のActionFormにはresetメソッドをオーバーライドすることで、一応はチェックボックスを一度初期化することができます。

よって、ブラウザからリクエストを受けたタイミングで一度チェックボックスの変数のみfalseにし、もしブラウザから値が送信されていればtrueに変更することで、チェックボックスの状態を扱うことはできます。
実装するとすると以下のようになろうかと思います。

・ActionForm

package com.sample;

public class Form extends ActionForm {

/** チェックボックス */ // ここはhtml:checkboxのproperty属性名と一致
private boolean check1 = false;

// setter/getterは省略

public void reset(ActionMapping mapping, HttpServletRequest request) {

check1 = false;
}
}


ですが、画面の仕様やフォームの仕様というものは変更されることがあります。
ActionFormは普通には画面の入出力情報を保持している入れ物と考えておくほうが非常に分かりやすく、その中に例外的にresetメソッドが実装されている状態ですと、仕様変更時にresetメソッドの実装修正が発生してしまい、バグに繋がる恐れがあります。

一応、もし実装と設計とそれぞれの相関を完全にデータとして保持し、影響調査により修正すべき箇所を洗い出すことができるならば、resetメソッドは有効に働くでしょう。

ですが、私の個人的な意見としてはresetメソッドやActionFormにはvalidateメソッドを実装できますが、それらはActionFormでオーバーライドしないほうが良いのではないかと考えています。
できる限りそうでない方法を検討し、各クラスや成果物の責務を明確かつシンプルにしておくことを心がけるべきだと考えています。

ちなみにですが、StrutsのJavadocでも理由はいくつかあげられていますが(チェックボックスを初期化するのが必要なら仕方なしとして)、オーバーライドしないことを推奨しています。特にセッションスコープに格納しつつ、複数画面で使いまわす場合には要注意です。

一応、忘れていないですよっていう意味も込めての補足で記載しました。
posted by Kiruahさん at 22:41| Comment(0) | TrackBack(0) | ノウハウ

2012年07月14日

Struts1のhtml:checkboxではまりました。。。

久しぶりにStruts1を見ました。。。理由はまぁ色々とありまして。。。

元々StrutsでCheckboxをどういうふうに処理すべきかなんていうのは覚えておりません。
ただ、ブラウザはWebサーバーにチェックされていないCheckboxについては値を送信しないことは知っていましたが、実際jcwebを使うとJavaの中から直接Checkboxの状態を取得できてしまいますし、仕事ではCheckboxはあまりつかわないようにしていたので考えたことがありませんでした。(これはダメですね。。。しかもJSFの他のOSSライブラリを使っていたり)。

で、聞いた話によると、どうもうまくStruts1でCheckboxは未だ難しいようです。
具体的には以下の場合です。
・2画面の画面遷移であり、共に同じActionFormを使う
・1画面目でとある条件(DB検索した結果を入れるだけですが)を満たすと、チェックを画面につけた状態にする
・そうでなければチェックしていない状態にする
・チェックがついている状態で表示された場合、チェックを外してサブミットしても、チェック状態と同じ状態でブラウザから値が送信されてくる

環境としては以下です。
・Windows 7 (無関係でしょうが)
・IE9
・JDK6 (無関係でしょうが)
・Tomcat 7.0.29 (無関係でしょうが)
・Struts 1.3.10
・画面はJSP (無関係でしょうが)


実際に私もデバッグしてみると、valueの値が送られるとかそういう感じでもなく、checkedの属性があればon、なければoffが送られるような感じの挙動でした(忙しかったのでcheckedの値とvalueの値がどうこうまでの検証まではしていません。ごめんなさい。)。
なので、特効薬としてこんな感じにしました。

・struts-config.xml







・ActionForm

package com.sample;

public class Form extends ActionForm {

/** チェックボックス */ // ここはhtml:checkboxのproperty属性名と一致
private boolean check1 = false;

// setter/getterは省略
}

ポイントとしては、型は必ずbooleanを使うところです。

・JSPの中身(抜粋)


チェック
送信



JSPについては、実は以下の実装の方がいいのかもしれません。ifで書いてますが、論理否定に変えた方が美しいでしょう。

・JSPの中身(抜粋)


チェック
送信


あとは、onclickの箇所を別functionにするとか、どのブラウザでも確実に動作するためにjQuery化するとか、色々と工夫の仕方はあるでしょう。

ちなみにですが、SyntaxHighlighterを使っておりますが、勝手にタグ部分が大文字になっております。ソース上は全部小文字で記述しておりますのでご注意ください。


なんとなくやってみて、なんとなく動作したものなので、もっといいやり方があればご教授ください。
posted by Kiruahさん at 19:23| Comment(0) | TrackBack(0) | ノウハウ

2012年07月12日

クラウドつながり。私が本当に使えると思うクラウドはSIer開発案件向け。

SIerは顧客にクラウド環境を売っています。
売れているかどうかはおいておいて。。。

社内ではよく、サーバーリソースが足りないとか、検証環境が足りないとか聞きます。
そして性能検証したい環境なんて、テストが終われば用済みであったりします。
逆に開発中は大規模にリソースが必要です。

また顧客の保守環境は、リリース前はきっちりとしておきたいけれど、リリースが終わればしばらくは縮退したい。でも保守期間中はきっちりと保存したいという要望があります。

そうです。これこそクラウド環境はもってこいの内容だと思いませんか?

ですが、弊社ではやっと考え始めた節がありますが、まだまだ本格的にどうにも使いにくいものです。
もっとメリットを前面に出して、いかに案件のコストが減るのかを明確にして、さらにSourceForgeやGithubのような機能や営業支援機能、営業情報管理、リリース管理、不具合管理、課題管理、ライブラリ管理、バージョン管理、Wiki、ブログ、掲示板、アラート機能、マニュアル、ドキュメントやソース全文検索機能、ナレッジベースとその統合化、構成管理、プロジェクト管理(コスト管理、スケジュール管理、メンバー管理、等など)、ユーザー管理、認証管理、テスト管理、承認管理、ビルドサービス(CI的なものなども)をあわせて、社内で売上を立てる部署を作るべきだと私は考えています。

今、その方向で何かできないか、実はこっそり考えています。

2012年07月11日

クラウドは失敗してもらいたい

今やどこでもクラウド、クラウドと言われています。
私が一番最初にクラウドという言葉を聞いたのは、2008年ぐらいに品川で行われたガートナー社の講演の中です。当時はまだ、クラウドという言葉がバズワードレベルで紹介され、これから定義をしていくという感じでした。

当然ガートナー社ですので、要は「ブームはこれから自分たちが作るものである」と言っても彼らにはいいのかもしれません。ただ、単純に当時、社内へその話を持って帰った時の上司達の反応は、「クラウドって何?」でした。私は「単純にいえば、仮想化です。ネットワークの先にあるサーバーリソースを隠して、使いたい時に使えるようにして、自社データセンターがなくてもコンピュータ資源を使えるようにするようです。」と話したら、「そんなのいらない」という回答を上司から得た記憶があります。

そんな弊社も今や、国内に何箇所もデータセンターを持ち、そしてクラウドサービスもやっています。一応は名も売れているようです。例に漏れず上司たちはクラウド、クラウドと叫んでいます。

今、クラウドは旬な状態から枯れる位置に移動しようとしています。

ですが、私が言いたいことは、そんなことではありません。


クラウドのメリットやデメリットは色々と営業として語られてきています。
でも、メリットの中には耐障害性だとか、運用コストが安くなる可能性があるだとか、そういう話があがります。もちろん、パブリッククラウドからプライベートクラウド、併用等も含め。。。

正直なところ、そんな話、今となってはウソでしかないのではないかと考えています。
あらゆるメリット・デメリットを検証してもし尽くせないのですが。。。ここで2つ見てみます。

1. データセンターを持つわけではない、DRやBCPサイトを別のクラウドセンターに用意すれば業務継続性に強い

これは本当にそうでしょうか?自社内においてもネットワークの切断があれば、社内システムは使えないわけです。それがさらに社外に及ぶネットワーク切断が発生する可能性があるわけです。
今ではSalesforceは日本にもデータセンターがありますが、一時はオンライン障害が発生するまでは日本にデータセンターはありませんでした。SaaS環境の上で営業売上を分析するシステムを構築していたとして、さて大地震で海外につながるあらゆるネットワークケーブルが切断されてしまったらどうしますか?衛星回線でも使いますか?衛星回線は高価です。常時のコストは安くとも、障害があった時の代替案としてはコストがかかり過ぎます。

結局どこにセンターを置いたとしても、TCP/IPとインターネットによるネットワーク網が冗長であることがどれほど謳われたとしても、SIerレベルではそれを営業が「本当に大丈夫なんです」と話すのはウソです。「100%大丈夫」はありえません。
私が社内でよく切り出す話題に、「伊豆半島にしか本社、支社がない会社があって、弊社の東京データセンターを利用している会社があったとき、決算期に富士山が爆発して伊豆半島だけ分離して流されたらどうしますか?」とインフラ担当者に聞くと、彼らは「そんなこと起きないよ」と返します。

SIerが考えている想定はつまりはその程度なのです。
SIerにとっては伊豆半島が離れることはないし、まじめに考える必要もないし、本当に離れてしまっても自分たちが困ることがないからまじめに考えないのです。

それでもクラウドって障害に強いのでしょうか? その強さを一度定量的に示してみてくださいとSIerに聞いてみれば分かります。弊社も若干某米国のサーバーにのっているクラウドもありますが、そのサーバーまでの地面に埋め込まれた回線数を全て把握していて、1時間で全て回答できないでしょう。もしできるようであれば、弊社を利用してくださっても問題ないかもしれません。。。


2. コストが安くなるという宣伝文句に騙されていませんか?
これはつまり、逆に言えば、今のコストは高くしているのですよと言われていることと等しいです。
安くなる=そこに弊社の中で営業努力やコストカット、効率化があって安くなっているという事実はありません。
遅ればせながら参入したから営業的に、クラウドにすると他社より安くしますよという言葉は言います。が、これは営業努力の結果でしょうか?

おもしろいことにSIerの素晴らしいところは、自社の顧客の業務をシステム化し、そして業務上発生するデータはデータベースにのせることはできるのですが、自分たちの業務はデータベースに表現できないと言うのです。また、他業種は自分たちがコスト削減や効率化をシステム化することで実現しているのに、私たちはそんなことを推進しているわけではありません。

同じ仕事、同じお金を稼ぐ作業、同じ何かをデータ化する作業。何が違うのか?

言いたいことは簡単です。クラウドだからコストが安いというのはウソなのです。
どちらにしてもデータセンターは運用しなくてはいけないのです。ただ、クラウドとしておけば、顧客がサーバーを使う際のSIer内のCPU時間やメモリ、運用コストを効率良く分配できそうだと考えているだけです。ただし、当然SIerの視点では正しい考え方です。
でも、顧客の決算期などの最繁期なんて業種が同じだったらどこの会社もほぼ同じ時期でしょう?
だから、データセンターで監視しする運用コストはそんなに変わらないはずなのです。。
ちょっとだけシステム化されているだけ。要は客寄せパンダのためのコスト表が提示されているのです。


さて、話題を変えさせてください。

今や禁止用語に近くなったP2Pという技術があります。また、P2Pとは少し違いますが、SETI@homeなんていうものもあります。

これらに共通して言えることは、みんなのPCを少しずつリソースを共有して、何か大きなことをしようというものです。
P2Pでは悪いイメージが先行していますが、業務で暗号化して利用してしまえば複数の社内PCに対してデータを社員が利用しているPCのほんの50GB(最近はHDDに500Gとか積んでいるので問題ないでしょう)を利用させてもらって、社内の業務情報を複数箇所に分散させて保存させるなんてことは考えたことがありますか?

ちょっと特殊なアプリケーションですが、業務の計算を社内に出社しているコンピュータを利用してその空きCPU時間を利用させてもらって業務計算させるということは考えたことはありますか?最近はデュアルコアどころか、クアッドコア(4コア)のCPUを積んでいたりします。
SIerで開発をやるようなところではなく、WordやExcel、PPT、ネットが見れてちょっとしたアプリが使えればいいような業種であれば1コア分を使わせてもらっても影響はそんなにないと思いませんか?

自社の社員のPCをクラウドのようにディスクスペースとCPUコアを分散して使う。
その社員が日本全国にいて、10支店ぐらいあって、500人いて、毎日彼らは出社してくるわけです。閑散期も最繁期も。そして、最近はWake On LANがありますので、夜間バッチ中にリソースが足りなくなるようであれば、パケットを飛ばして社内のPCを立ち上げることもできます。
CORBAなんて技術もHadoopなんて技術もあるので、社内の全部のPCを使えばいろんなデータをバックアップしながら複数人で分散し、いろんな社員のPCのCPUタイムを使えば十分なことができます。

ただし、前提として中小企業ではこれらは難しいかもしれません。。でもクラウドなんてものをやってみようなんて言うところは案外大企業が多いです。


言ってしまえば私の話なんて極論です。でも、自社の社員のPCに暗号化されているデータと、どこかのSIerという会社が「暗号化してますよ」といっているセリフ。私だったら前者の方が安心します。
耐障害性も、社内のLANが有効で社内のPCがしっかりワイヤーで固定されていたら、火事や津波ではダメかも知れませんが、外部とのネットワークが切断されていても社内のPCだけで業務を継続できませんか?


私は本当にクラウドが顧客が本当に期待する当たり前品質を満たせるのか、甚だ疑問です。
目先のコストだけで流行にのっているだけに見えます。それはSIerや顧客共にです。
今はまだ何も起きていないから、良い方にも悪い方にもどうとでも言えます。
でも、SIerの責務はどうとでも言えることを言うことでも、100%であるかどうかを検証もせず答えられもせず、「大丈夫です。」と言うことでもないと、私は考えます。


お客様の皆様にはどうか、本当にどうやって自社の資産を守っていけばいいのか、単純にSIerの営業トークを聞くだけでなく、疑って、検証して、こういう場合はどうなのかを問い詰めて、その上で答えを出して欲しいと切に思います。

-----
2012/07/13 分かりにくい表現を修正しました。

2012年07月10日

今、いろいろと作りたいもの

最近、とても物欲が強いのか、いろんなものが欲しくなってきてしまっています。困ったものです。そのほとんどはしかも、ほぼ実在しないような代物です。
今はすぐに作れるものなので、現在作成中のものは、javaの特殊なクラスローダーです。
すでにplay frameworkで実現はほぼできているのですが、ソースをコンパイルすることなく利用できるスクリプト言語みたいに利用できるjavaのクラスローダーを作りたいと思っています。

どうしても大企業病なのか、新しい言語は誰も習得できませんので、既存のgrooovyみたいなものが使えればいいのですが、そうもいきません。
そして結局コンパイルでデプロイミスも多く発生しています。
なので、デプロイはソースにして、あとからでも差分比較できるようにしたいといつも思っています。

また、それだけでなく、シェルスクリプトなどの運用コマンドやインストーラーなど、あらゆるものをjava一本にして行きたいと考えています。exewrapというものもあり、とても便利なのですが、今のところはWIndowsのみですし。。。
その一環でjcwebもまだ途中ですが開発しています。

道のりは遠いですが、何とか一本化できるよう、頑張りたいところです。
posted by Kiruahさん at 01:00| Comment(0) | TrackBack(0) | 日記

2012年07月09日

家族で東北に旅行へ行ってきました

今回は土日で家族で中尊寺、十和田湖、松島方面へ一泊二日で弾丸とラベルしてきました。
弾丸とはいえ、ちゃんとしたツアーです。最初は新幹線でしたが、途中からバスでいろいろと周ってきました。
東北地方は大学院時代に米沢に勉強に行ったぐらいしかなかったのでとても楽しかったです。

ちょっと初日はお天気が悪かったのですが、翌日は晴れてとても良かったです。
とても楽しい旅行でした。またツアーででも今年か来年にいけたらいいですね。
楽しみです。
posted by Kiruahさん at 21:17| Comment(0) | TrackBack(0) | 日記

2012年07月04日

kommons-lib 0.27に入れる予定の簡単な機能

現在kommons-lib 0.27を時間をかけて準備中です。
やはりteterの精度がよくなく、新規で作り直しているところです。
ただ、あまりにリリース時期が伸びており、また、poi2ccでもリリースして修正すべき不具合もみつかっているために、teterを省略してリリースしようかとも考えているところです。

どうでもよいのですが、どう考えてもやっぱいteterは「チーター」とは呼べないのでスペルを変えてしまいました。。。

さて、今回は少々話が代わり、kommons-lib 0.27に入れる予定の機能のうち、ブログで紹介するのにちょうど簡単なちょいプロみたいなものがあったので、早めに紹介しようと思いました。

本当に大それた機能ではありません。kommons-libを利用していますが、ファイル入力処理を記述すると以下のようになります。ただし、close処理は省略しています。


FileInputStream fis = null;
InputStreamReader isr = null;
BufferedReader br = null;

try {
fis = new FileInputStream("ファイル名");
isr = new InputStreamReader(fis);
br = new BufferedReader(isr);

String text = null;

while ((text = br.readLine()) != null) {
// text処理
}
}....(省略)


ここで私があまり好きではないのが、whileの中の条件です。条件なのですが代入込みです。
この場合であれば、


try {
fis = new FileInputStream("ファイル名");
isr = new InputStreamReader(fis);
br = new BufferedReader(isr);

for (String text = br.readLine(); text != null; text = br.readLine()) {
// text処理
}
}....(省略)

と、for文にまぜてしまえば、continueを利用しても副作用的なミスは起きにくいでしょう。
ですが、これもまだなんだか好みではありません。
できれば、もっと良い感じのロジックがいいなと思いました。
そこで、Holdというクラスを無駄に作成しました。Holdを利用すると以下のようになります。


try {
fis = new FileInputStream("ファイル名");
isr = new InputStreamReader(fis);
br = new BufferedReader(isr);

Hold hold = new Hold();

while (hold.setEscapedNull(br.readLine()) != null) {
String text = hold.get();
// テキスト処理
}
}....(省略)


正直、無駄が増えたようにしか見えませんね。でも、個人的にはこちらのほうが好きです。単に好みの問題です。ただ、ポイントはHoldは拡張可能です。今現在のHoldクラスはカウンタがついています。よって、


try {
fis = new FileInputStream("ファイル名");
isr = new InputStreamReader(fis);
br = new BufferedReader(isr);

String text = null;
int count = 0;

while ((text = br.readLine()) != null) {
count++;
// text処理
System.out.println(count + ":" + text);
}
}....(省略)

なんていうコードはHoldを利用すれば、

try {
fis = new FileInputStream("ファイル名");
isr = new InputStreamReader(fis);
br = new BufferedReader(isr);

Hold<String> hold = new Hold<String>();

while (hold.setEscapedNull(br.readLine()) != null) {
System.out.println(hold.getCount() + ":" + hold.get());
}
}....(省略)

となります。ここまで来るとだいぶすっきりです。

最後にHoldのソースを記載します。参考までにどうぞ。kommons-libに入りますので、kommons-libと同じApache License 2.0となります。


package com.kiruah.kommon.jvalue;

/**
* 値を単純に保持するための仕組みを提供します。
*


* whileやforのループの中で以下の代入文が記述されることがあります。
*


* while ((v = func()) != null) {
* // 処理
* }
*

* これはwhileの中で代入処理と比較処理を同時に実行しています。意味や可読性、記述性の面で優れていますが、
* Kiruahは処理を分割したいため、以下のように記述させます。
*

* v = func();
*
* while (v != null) {
* // 処理
*
* // 次の処理
* v = func();
* }
*

* このように記述させることのメリットはあまりありません。単に好みです。
* ですが、funcの呼び出しが分断されるため、分断されないようにするため本機能を提供しています。
*

* Hold h = new Hold();
*
* while (h.set(func()) != null) {
* T v = h.get(); // そのままh.get()を利用しても良い
* // 処理
* }
*

* このクラスのメリットはありませんので、記述上同じ好みを持つ方が利用されることを想定しています。
*


*
* @param ジェネリクス型
* @since 0.27
* @author Kiruah
*/
public class Hold {

/** 保持する値 */
protected T value = null;

/** カウント */
protected long count = 0;

/**
* デフォルトコンストラクタ
*/
public Hold() {

}

/**
* 初期値を保持するコンストラクタ
*
* @param value 初期値
*/
public Hold(
T value) {

set(value);
}

/**
* 値を保持します。
*
* @param value 保持させたい値
* @return 保持させた値
*/
public T set(
T value) {

this.value = value;
count++;

return value;
}

/**
* 値を保持します。

* 値を保持しますが、不正な値の場合(例えばファイルリードの終わりがnullとなるようなケース)において、
* nullの場合カウント結果を累積させない場合に利用します。これはnullを利用する厳密なカウントアップ処理の
* 場合に有効に利用できます。
*
* @param value 保持させたい値
* @return 保持させた値
*/
public T setEscapedNull(
T value) {

this.value = value;

if (value == null) {
return null;
}

count++;

return value;
}

/**
* 保持させた値を返却します。
*
* @return 保持させた値
*/
public T get() {

return this.value;
}

/**
* カウント値を返却します。
*
* @return カウント結果を返却する
*/
public long getIndex() {

return count;
}
}

posted by Kiruahさん at 01:00| Comment(0) | TrackBack(0) | 日記

2012年07月03日

開発方式、処理方式、開発標準という夢物語

日本のSIerは過去、もしくは弊社では未だに現在進行形で、開発方式、処理方式、開発標準を考えるべきだということが叫ばれています。それがないから開発に失敗すると。
実際のところ、そんなものは弊社では立てられないと心のなかで分かっていながらも、私も「そうだ、そうだ」と叫んでいたこともありました。

そして、今現在進められている案件でもまだ、開発方式、処理方式、開発標準をどうするかだけでなく、各案件で開発方式、処理方式、開発標準が策定されている始末です。つまり、確定していないし、現在進行形でそれぞれの人達がそれぞれ開発方式、処理方式、開発標準を作っているのです。

が、はっきり言えば、日本のSIerが叫ぶ開発方式、処理方式、開発標準(以下、まとめて方式と呼びます)というものはいずれも、中身が無い空虚なものです。これができれば、開発が少しはうまくいく、効率化、省力化できるという夢が語られたりもしましたが、絶対にそんなことはありません。最近はそんな風に考え方が変わってきました。

これら方式とは誤解を恐れずに言えば、究極的に抽象化された、たった一つしか存在しない銀の弾でなければ作る意味はないでしょう。
でも、さすがに作れないため、現在では各プロジェクトごとになんとか銀の弾を作ろうとしています。それすらも結局作れずじまいです。
たったひとつ、全てを抽象化した完全な方式は存在するのでしょうが、存在しても作ることができないでしょう。できて規約までです。

規約はとても有効に働くでしょう。規約は反転すればチェックシートになります。チェックシートはそれを満たせば、成果物が規約の範疇を保証する強力な武器になり、チェックシートに記載された事柄が満たされなければ、突き返すことができる強力な防具にもなります。
そう、開発の現場では、規約とチェックシート、マニュアルやガイドさえあれば、実は十分開発を行うことができます。あえて事前に方式をたてる工数を作っても無意味なことがほとんどです。

それはなぜか。

その理由は案外単純です。方式とはある種現状では中途半端に抽象化されたレベルにしかならないため、実際にしようが固まれば固まるほど、方式の範囲を超えたどうしようも無い例外が発生するためです。結局、最初に立てた方式はなんとなく実現できそうでも、何時の間に苦しまぎれ例外が多くなります。これが後々の保守性を非常に低下させます。

例外ばかりで実装されたシステムほど、どう見たらいいのかわかりません。どう修正したらいいのかもわかりにくいのです。
であれば、中途半端な方式を立てるぐらいなら、まだ何もないほうが工数は無駄になりません。
ただし、もちろん事前に完全に抽象化された方式が立てられ、例外が出ない、もしくは方式に吸収可能なレベルを実現できるのであれば、あったほうがいいでしょうが、ここではそこまでのレベルのものはそもそも作ることができないという立場に立っています。


本当に使える方式を立てるにはどうしたらいいのか。

それは、全ての開発工程を今まで苦労も含めて経験し、そして技術も業務も管理も保守も運用も全て熟知した人間だけが、それらを俯瞰してあるべき姿、つまりべき論を導き出すことができます。

ですが、今現状、弊社で方式を立てようとしている方々は、いかに今わかっている仕様だけで自分の考えている方法論で作るかしか頭にありません。
そうではなく、本当に使う側に立った視点で見ていないのだから、作れないというのが私の意見です。
まずは、本当に各プロジェクトでどういうことがあったのか、分析するところから始め、上から目線をやめ、いろいろな工程の担当者から話を聞き、コミュニケーションを受け、真摯に耳を傾けなければ、真の方式はいつまでも夢物語でしょう。

では、具体的にどうすべきかについては、また順次記載して行きたいと思います。まだ、まとめきれていないので、ちょっと時間がかかりそうですが。