忙しさにかまけてのメンテサボってしまってましたがまた今年度も始まりましたです。
いろいろな思いや技術ネタもあるにはあるのですが、ちょっと考えさせられる状況を
見てしまったので僕の意見を書かせていただきます。
元記事はコチラとコチラですが事態は収束したようなのでTBは控えさせていただきます。

僕の母はCAMUSさんと同種の病気です。正確に言うと「有毛細胞性白血病」と言い、
CAMUSさんとは異なるものですが、慢性の括りで一緒に紹介されることが多いです。
僕は当人ではないので本当の気持ちを代弁しても、どんなに良く理解できていようが
当人の思い以上のことは語れないので、周りで暮らす人として感じたことを書かせてもらいます。

どんな病気なのか、治るのか、どんな治療法があるのか、医者から言われた以上のことを
知らないとき、藁が必要になります。藁は家族や友人の支えかもしれませんし、
客観的な事実をまとめた本、場合によっては宗教もあるかもしれません。
母はパソコンも触りませんが、父や友人とよく相談したりしているようで、
これが大きな支えになっていると思います。
だから、しかし、これといった情報収集も口コミ以上のことはしていません。

できないから？必要ないから？違うと思ってます。
ウチの母の場合(多くの慢性の方にもいえるのかな？)、急変しないかぎりほぼ普通の生活ができます。
なので元気なときにはネットでも公共の相談所でもいろいろと藁を得る手段はあると思います。
パソコンのことで言えば、息子はIT戦士なわけで頼ろうと思えば頼れます。

冷静に見れば、なりふり構わずそこにある藁を掴めばいいじゃん！ってことになるんでしょうが、
そうしない訳はもっと深いとこにあると思います。
まず実はつい最近まで僕は正式な病名を知りませんでした。これはおそらく親心からか、
「心配かけたくない」「負担になりたくない」って思いがもとで隠されていたわけです。
息子としては複雑ですが、親としても複雑で、「頼れるもんなら頼りたい」って思いも確かにあるようです。

もちろん僕はうっすらと気づいた時点でググってみたり本屋に行ったりして、
「多くの客観的事実」を手に入れました。そして、日本国内では100～200人ぐらいの症例しかないこと、
欧米では逆に割と症例が多いこと、欧米では治療法もあり成功例もあるが国内では実績が非常に少なく、
検証もあまりなされていないことを知りました。ほとんどは医者の言うことの裏づけです。

こうした事実を突きつけられ、じゃあ治療するかというとそれも難しいところがあります。
治療のリスクとその見返りがまったく読めないことへの不安が非常に大きいんです。
事実そう言っていますし、医者も微妙な返事しかしません。

現在、基本的に不治の病気ですが、先にも書いたとおり症状が暴れさえしなければ(合併症が一番怖いところです)、普通の生活なわけです。
入院中は「こんな思いはもう嫌だから本格的に治そうみよう」って思いにもなるかもしれませんが、
普通の生活しているときに「よし、元気になったし治そう！」っとなれるでしょうか？
治療をすることで当然大きな副作用があるかもしれませんし、
闘病となって長くかかるかもしれない、
そして治らないかもしれない、
ネガティブ要素がたくさんあると思います。

多分こう書いても当事者にならないと伝わらない面もあるかもしれませんが、
そうなんだなって思っていただければと思います。
こうして考え、思い、悩んでいくと、藁が凶器に見えたりすることもあります。
CAMUSさん曰く、「余裕が無い」わけです。
もしかしたら当人は気づかないうちに余裕が無い言動をすることもあるでしょう。
家族の、僕のつまらない一言で母はナイーブになったり、何の変哲も無い普通の会話に
つっかかたりするときも有ります。
周りが気を付けているつもりても配慮が足りないときも有りますし、当人も自分の精神状態に気づいていても抑えられないときがあります。
こういう余裕が無い状態で、まさに今回の発端となった元記事のようなものを見た日には、、、

僕は発端となったBlogのオーナーの記事内容自体にはそこまで言うつもりはありません。
それが許されるシチュエーションもあるでしょう。
ご自身の会社の同僚や友人との会話の中でそれが許されるのなら問題ないと思います。
ネットでもそのコミュニティに閉じた話なら、「嘘だったのかー」で済むかもしれません。
その人の「ヒトトナリ」を良く知っている人なら許せる場面もあるでしょう。
閉じた中でも「駄目だよ」きっちり忠告してくれる人がいれば、それはご自身の経験となり、
次へつなげていくことができます。
現実社会で言えば親友や家族のような人がそうであるように。

ただ、残念ながら特にBlogで閉じたコミュニティなんてそうそう無い気がします。
まして、Doblogの人気ランク上位に名を連ねているというと、不特定多数を相手とした、
きわめて公共性の高いメディアとなるように思います。
例えば某テレビ番組でお笑い芸人のネタが視聴者の反感を買ってなんて事件もありましたよね。

単純に多くの人に見て欲しい、アクセス数を稼ぎたいって気持ちが僕には無いんですが、
そういうモチベーションが少しでも有ってBlogをやっている場合、
配慮というよりは自覚をするべきかなと思います。
良くある反論で「見たいやつだけ見ればいい」的なのがありますが、それならそうとTopに書くべきですし、
該当Blogはそもそもそういう色合い(パルモさんとこみたいな→僕にとってはそう)も見受けられないですし。

ちょっと先回りしすぎなことも書いてしまいましたが、僕が思ったのは以上です。

CAMUSさんへ
ご自身のことなのに、とても客観的にお話いただいて、とても感激しています。
CAMUSさんだって人間です、そちらでは書ききれない以上のことを感じているんですよね。
それを踏み越えてのご忠告、充分大人だと思いますし、っというより大人子供ってこと以上にその勇気と前向きさに乾杯です。

直面した人でなければ分からないことも有るんだと言うことを多くの方にご理解いただきたいと思います。
CAMUSさん、お大事にしてくださいね。
東枕だろーがなんだろーがしっかり寝て、常に体力蓄えておいてくださいね＾＾；
→まるたまさん、すみません。。。

第1戦　スペインGP
～Moto GPクラス予選～
4月9日(土) 25：30～26：45
(野球中継延長の場合、放送時間に変更の場合あり)

第1戦　スペインGP
4月10日(日) 25：30～29：45
(野球中継延長の場合、放送時間に変更の場合あり)
(再) 4月12日（火) 24：30～28：45
(再) 4月15日（金) 24：30～28：45
第2戦　ポルトガルGP
～Moto GPクラス予選～ 4月16日(土) 25：00～26：15


第2戦　ポルトガルGP 4月17日(日) 24：30～28：45

(再) 4月19日(火) 25：30～29：45
(野球中継延長の場合、放送時間に変更の場合あり)
(再) 4月22日(金) 24：30～28：45

第3戦　中国GP
～Moto GPクラス予選～ 4月30日(土) 20：30～21：45

昨日の夜の話。
仕事終わって家に着いたの(0:00)。
コンビニ弁当食べ終わったのが(0:30)。
さーて一服して寝るかーってタバコに火を付け最初の一吸い(0:40)。
息を吸ったその瞬間、左下奥歯に激痛が走る(0:40)

ええ、わかってはいたんです、いつかこの日が来るって。
放っておいた僕がいけないんです。
だからってこんな時間で無くても良くないかい？

ネットで歯医者を調べるも当然こんな時間です。
近所のドンキに1時までやってる歯医者があるらしいけど、もう無理。間に合いません。
寝れずに翌朝近所の歯医者に乱入(翌9:30)

そんな僕の左下奥の親知らず、明日抜きに行きます。
幸い今は痛みはすっかり消えてます。
同時に、痛んでいたときの「さっさと抜いちゃえ！」って思いも消え、
今は明日が不安でしょうがありません。

そんな逃げ出したい気分(翌3:40)

プログラマの「本懐」 ~アーキテクトという選択

『職業としてのソフトウェアアーキテクト』
（マーク・スウェル、ローラ・スウェル著／倉骨彰訳、 ピアソン・エデュケーション）

Effective Java プログラミング言語ガイド
他の情報もまとまってて良いかも。

MergeDocでEclipseのポップアップ表示を日本語化する
これでブラウザとの往復からおさらば

オープンソース何たらBy経産省
仕事だ、兄さん

[TB企画　あなたはMT派、AT派？]
あとで記事書きたい

まるごと　PostgreSQL!　Vol.1

Stowを使ってのパッケージ管理
Stow -- RPMの代わりとなる柔軟で、優れたソフトウェア

Javaが今僕の中での主流ですが、もともとはDB周りから業務知識は身につけはじめました。
業務知識って言うと横柄だな、要は何も知らない(DBって言葉は知れどもOLTPって？レベル）学生さんは、ちまちまSELECT文を覚え、ACID属性とはとかもっと原始的・歴史的にコダシル(つづり忘れた）とか、階層型、ネットワーク型、ファイル編成などなど、勉強してました。
言語は廃れるかもしれないけれどDB(RDB)はそうそう無くならんぞ、って考えたか考えなかったかは定かではないですが、そんな経歴。

DBネイティブのライブラリ使ってCでクライアント組んで遊んでいたりを経て、JDBCを切り口にJavaの世界に突入。
ええ、最初はやってましたよ
stmt.executeQuery("SELECT * FROM Table;");
ってね。
もちろん超オンコーディング、最後の「;」はDB上がりの人間のこだわりでしょうね。

Javaの世界に入り、Stringクラスにクエリを持つ、そしてクエリ生成クラスなんて作る荒業を覚えてみたり(Cでもやってましたが・・・)。言語的にはCのバックエンドが長かったせいか、はたまた中途半端な経験しか持ち合わせていなかったせいか、ファイルだの文字列操作ってのを極端に嫌ってまして(Cだとほんとめんどくさい、エラー処理とかエラー処理とかエラー・・・)、Javaに入ってその楽さに大感激。文字連結が"+"だけでできるなんて！
さらに進んで設定ファイルとかのPropertyファイル(よくある"name = value"形式のファイル)を知ってそこにSQL書いてみたり。

さて、長くなりましたがココで命題。
SQLはどこに書く？
１．黙って直書き
２．beanに集めて閉じ込めて
３．Stringなどのメンバ
４．外部ファイル

1は冗談で言っているわけでなく、そんな場面も有りかなと。コード追ってけば自然に見えるのがいい。対象のテーブルとかカラムぐらいは変数として持っておいたほうがいい気もするけど。

2はなんか用途が違う気もするけれど、４のインタフェース(Javaのじゃないです)としてはたまにやる。

3が一般的かな？似たようなクエリがたくさんあって、動的にクエリを連結して作るとかだといいのかも。ただ、動かしてみないと分かりづらかったり、DB矢から見れば予期せぬ使いか足されたりするので要注意。こないだ見たソースでは、「String FromStmt」なんてのがあって、そこに必要「そう」なテーブルのJOINがすべて書いてあった。すべてのクエリにこいつがつけてあって、DBではJoinしまくり。必要なくてもとにかくJoin。親の仇かって言うぐらい。そんなこともあります。

4が最近のお気に入り。なんてったってリコンパイル不要。クエリはすべて書く必要があるけれど、DB上がりから見れば何したいかも1ファイルなめれば見えるし。欠点はユーザにも丸見えな点かな。サーバサイドなら問題ない気もするけど。

4って駄目な理由が特に見つからない・・・何か重大な見落としがある気がしてならない。3が多い気がするしなー。
どうなんでしょう？

あ、ORマッピングツールとか使うってのは今回は視野に入ってません。なぜならそっちに手を出すほど余裕が無いので。明快です、はい。

写真は最近便利だなーって思ってるソフトの入門書。いつかなんかの記事書けるといいな。

[関連したBlog]

コメントで書くには長すぎた。。

昨年10月ごろ、うちのプロジェクト （Java系インフラ開発)に汎用機システムの上流設計をいままでやってこられた方が異動してきました。
技術的なバックエンドはコボちゃん、C、sh系などで、正直苦労していらっしゃいました(今もですが)。

TB先の所のように「最短は」みたいな話をすればよかったのでしょうが、よくも悪くも本人任せで、そこは技術者、しっかりとお勉強なさっていました。言語の壁、プラットフォーム(Win、Linux)の壁に加え、Eclipseやナゾの3、4英文字単語(笑)とJavaどっぷりの人でさえ大変な中、その方はボトムアップ的に言語の壁を乗り越えようとしています。

ただ、そんな中でもプロジェクトは進むわけで、システム的な観点では経験豊富なその方はやはりリーダー的な役を任されていまして、これじゃ間に合わんなと。多種多様なコンポーネントを理解するのが先決！ってとこでオブジェクト指向を詳しく知らないとつらいだろうなーと。設計や見積もり、スケジューリングなど、今までは(極端に言えば)言語とは密に関係なくできたものが、単純ステップ換算とかではできない点も難しいなと。どうすればいいのか僕も一緒に悩んでるのですが、時間の制約があるためになかなか解がでませんね・・・。

具体案として今考えてるのは、

１．ためしに作ってみる
Web系だと複雑すぎるのでCUIでいいんですが、Hello worldレベルではなくて少し凝ったものを凝った造りで。要件は「何ができること」ではなく「何を使うか(使えるか)」というSeeds思考的なアプローチ。もちろん使えるものを探すところから修行は始まってます。
外野は「あれ使ってみれば」って無責任な助言。具体的な質問には答えてあげる。
利点はバーチャルなプロジェクトなので思う存分に悩める。ただ、時間、コスト的なプレッシャーから得られるものもあるので本人のやる気に大きく依存します。

２．とにかく設計してみる
実案件ベースで一気にもってく。僕はこのパターンでした。駄目だしは僕らの役目。僕らの修行にもなります。僕のときは技術的に頼れる協力者がいたため、割とすんなりいきました(持ち前の吸収の早さってのもあるかも＾＾；)。難点は実案件ベースでやるには責任が大きいのと時間が限られるため局所的にデスマが発生する恐れがあること。あ、あとそもそも僕らがコメントできるのかと(おい）。

なんだ、一般的な学習法じゃないか？結局それしかないのか、発想が貧困なのか。良い案急募！できればうちのプロジェクトに入ってくれればベスト。中途採用キャンペーンやってるし丁度いいかも(本気)。

写真は去年行ったUSJのジュラ。濡れまくりました。

[関連したBlog]
遅ればせながらBookmarkキャンペーンに参加しておきましょう。
Doblogの今後の発展を祈って。
発祥はCUMBUSさんのところ(該当記事)

話題はそれますが、TB先の下にQRコード(話題の？2次元バーコード)が有るんですが、ためしに携帯でやってみたら認識でけた！モニタ上でも可能なんですねー。認識率さえアップすればRFIDと共存できるんじゃないかな？適材適所ってことで。

今気がついたんだけど、記事作成画面の上にDoblog編集部のお知らせってのが有ったんだ。RSSの静的化ね。おそらくここDoblogだけでなく、RSSサイトはみんな苦労していることでしょう。

日経かなにかの記事で読んだのだけれど、近いうちにSyn Floodならぬ正常アクセスによる洪水が起こるそうな。確かにRSSリーダに代表されるようなクライアントというかコンシューマと言うか一般ユーザPC上の巡回ロボットの存在って想像しただけで恐ろしくないですか？はっきり言って性能要件もなにもあったもんじゃないと思うのですが。下手すればDDOS(Distributed Deny Of Service)ですよ、これ。

最近は聞かなくなったけれどもたとえばFinalFantasyだっけかな？スクエアの予約サイトがアクセス過多でダウンなんて話。上の人がどんなに言ったって、現場レベルでそれを把握し、それを超えるシステム作るってそんな簡単なものじゃないですよね。Web屋ではないので詳しくは無いんですが、きっと最近その手の話を聞かなくなったのは、経験値が上がったのとそれに元ずく一般解が出来上がったからでしょうかね。

おそらくいわゆるショッピングサイトとかを作ってた方(注：過去形です)はCGIやJavaの人であって、当時の人気商売であり、銀行のオンライントランザクションなんかを知らない人が多かったんではないしょうか。

まぁなんにせよ、日本全国のRSSロボットたちのリクエストごとにDBに行かれてしまってはPostgreSQL君はたまったもんじゃなかったでしょうね。もちろんAPサーバ君も。これで大きく負荷は下がるとは思います。これで駄目だったらAPの全面書き換えですね。がんばれ中の人！

補完系
Ctrl-Space
Ctrl-Shift-o
Ctrl-1
Ctrl-m

リファクタリング系
Alt-Shift-T リファクタリング全般のメニュー
Alt-Shift-R 名前の変更
Alt-Shift-L 選択した式をローカル変数に抽出
Alt-Shift-I 選択した変数をインライン化(=代入されている式に展開)
Alt-Shift-M 選択範囲をメソッドとして抽出

[関連したBlog]

ちょっと整理

[参考URL]
■Eclipseのヘルプ
Platform プラグイン・デベロッパー・ガイド
PDE ガイド

■読み物(概念の理解に役立つ)
Eclipse.orgのドキュメント
＠IT 第7回　EclipseによるSWTアプリケーションの作成
ITmedia 特集：Eclipseを築き上げたプラグイン、その開発法まで
IBM Eclipseプラグインの開発

■実際の開発に役立つ
プラグイン開発Tips他
Eclipseプラグイン開発
Eclipseプラグイン開発自分FAQ
Eclipseプラグイン開発
SWTサンプル集
SWT Tips & Samples