2012年04月30日

Excelキャプチャツール Ver 2.0のリリース

以前、バージョン1.2としてリリースする予定であったExcelキャプチャツールを、バージョン2.0としてリリースしました。

1.1をベースにしながらも、大幅に実装を共通化したり、Windows 7でも満足する結果(GetDCExでは半透明部分が黒くなるのでやめた)になるよう、変更しました。

使い勝手が変わってしまいましたが、それでも便利ではなかろうかと思いますので、もし利用したい方は、このページからダウンロードください。

ライセンスはいつもどおり、Apache License 2.0です。
posted by Kiruahさん at 15:03| Comment(0) | TrackBack(0) | アナウンス

2012年04月09日

InternetExplorerの古いバージョン(6とか7)から9へそのままHTMLを移行した場合の差異

分かっていた以上に、InternetExplorerのバージョンの違いによって挙動が変わってきており、少々びっくりしました。
まず6と7ではタブが追加されましたので、単純に同一ウィンドウのタブではセッションが共有されてしまうことがあるのもびっくりした記憶があります。
理由はタブが違うだけではクッキーは共有され、クエリ文字列ではなくセッションキーをクッキーに持たせたためだからなのですが。。。
私がまだまだ絶賛開発中のjcwebの中ではセッション情報はページ単位にJavascriptに持たせるようにしようとしています。
そして、毎回セッションキーは使い捨てです。つまり、毎回サーバー側でセッションキーをアクセスさせるたびにワンタイムパスワードのように発行します。
初回はサーバから送られてきたセッションキーをクライアントはそれをAjaxのPOSTパラメータに詰めないといけないという仕様です。
そして帰ってきたレスポンスに新しいセッションキーがあり、次はそれをPOSTパラメータに詰めるということを繰り返します。

この話はまぁ、置いておいて。
ここではよくあるような違いではなく、あまり気づきにくい所を紹介したいと思います。

スタイルシートを利用していない箇所にて、以下のような状況が発生しています。

1. font-sizeを指定しており、互換モード以外の場合、フォントサイズがIE9では大きくなっています。
font-size: small; と指定していた場合、これはIE9では、IE6のfont-size: medium; と同程度の大きさで表示されます。
よって、文字サイズが大きく表示されます。smallやmedium、bigなどで指定している場合は順次大きさがずれています。

2. 行間が小さくなっています。
これはフォントサイズが大きくなっているため、あまり感じにくい面もありますが、特に指定していない場合

3. legendタグのデフォルト色が水色から黒色になっています。

4. 文字の大きさの変更の影響を受けてか、テキストボックスの大きさ、余白も少し変わっています。
これは気づきにくいですが、比べてみると全体的に前よりもアンバランスな見た目に見えます。

また、別途気付いた点があれば随時追加していきたいと思います。
posted by Kiruahさん at 21:00| Comment(0) | TrackBack(0) | ノウハウ

2012年04月08日

相手を思いやることが重要なのではなく、相手の立場になることが重要なのです

新しい年度、今年も新人も会社にたくさんきたようです。
素直におめでとうと思います。

さて、少し関係がないのですが、新人にもやっぱり、優秀な新人、そうでない新人といたりします。
ましてやコンピュータ業界では、できる新人の中にもいくつか分類があります。

・話が得意で営業向きな方(こういう方は後からコミュニケーションで悩むことも多いようですが)
・技術だけが得意な方(こういう方も後から悩むことも多いです)
・どっちも得意な方(こういう方は両方評価されないか、どちらかしか評価されません)
・うまく立ちまわるのが得意な方(こういう人が出世します。が、下から使えないと言われる率も)

ここで一つ、こういう会話があったとします。

Aさん「Bさんはコンピュータに詳しくて本当にすごいよね」
Bさん「そんなことないよ〜」
Aさん「Bさんはだって、コンピュータに詳しいから、勉強しなくても研修の内容ができるから羨ましい。私はついていくだけで精一杯」
Bさん「私はたまたま知ってただけだよ。皆もすぐに頑張れば追いついちゃうと思うよ」
Aさん「スタートからこんなに差がついてたら、ずっと負けちゃうよ。これからもずっと教えてね」
Bさん「そんなことないと思うよ、勉強すれば。でも了解」
Aさん「勉強はやってるんだけどね〜。今週も土日は飲み会なんだ」
Bさん「へぇ〜、友達多くて羨ましいね。いいなぁ。私は今週も家でパソコンで遊ぶだけだからね」
Aさん「パソコンが趣味っていいよね」
Bさん「いいでしょ〜」

どちらがどちらとは言いませんが、実はこれはある一方からもう片方への嫌味の言葉です。
また、突っ込みどころ満載なのは、私の語り方が下手だということでご了承くださいませ。
さらに言えば、私の卑屈感も出ていますが、こちらもご容赦くださいませ。


言いたいことはそんなことではなく、上の「実はこれはある一方からもう片方への嫌味の言葉です。」に対して、何も思わなかった方もいるでしょう。。。

人はそんなに表面だけでは分からないものです。心情、その時の心境、状況、ましてや過去、それが例え10年以上もの友人関係で会ってもわからないことが多いです。それだけ人間は嘘ではなく、隠しているのでもなく、伝わらないものがあります。

これは、状況によっては両方共嫌味を言っています。

片方は、
「何もしないでもコンピュータが最初からできて、研修もできて、きっと仕事ができるんだろうね。あなたにはどうせ、研修が分からない私の苦労は分からないくせに。最初からできる人は苦労がなくていいね。仕事も楽で。でも、コンピュータばっかりで私生活つまらなそう。まぁ、オタクだからコミュニケーション能力はない人だよね。」と思っているかもしれません。

もう片方は、
「幼い時から頭が悪い子と言われ、何も認められず、そう言われ続けてきた。毎日少しでもその状況を変えたいと、努力して、何でもなぜなのかを考えて、教えてもらわずに生きてきた。やっとその中で少しは自分でも好きなものを見つけて、頭が悪い中でもじっくり時間をかけて理解してきた。だから、私ほどに努力しなくても、簡単に同じステージに今いるあなたが私にはとっても羨ましい。遊んでなければすぐに負けるし、遊ばなければいいのに。」と思っているかもしれません。

どっちもどっちです。
そして、どっちの状況も変わるものでしょう。未来もまた分からないものです。


これだけでも人間関係なんて、推して知るべしなんて簡単に言えないぐらい複雑なもので、分かり合えないことも多いです。それが例え、「こいつはいいやつだ」なんて思える人間どうしてあったとしてもです。

余談です。プロジェクト管理なんかは特にそう。今の管理は人はあくまで頭数。工数だけがモノを言う。誰が作るか関係ない。作る人が決まった後で倍率を単純に決める。そんな程度です。
そこには、どういう手順で、またどういう人を割り当てて、何を知ってもらいたいか、どういう教育を裏でやっていくかは作戦としては全くないのが、IT業界の今のプロジェクト管理に見えます。
できればいい、たしかにそのとおりです。でも、何ができればいいのかは、もっと考えたいと思います。そう、人とはそんなに簡単なものではないのだから。何をやりたいのかをきき、それにできればあわせて、考えたりチャレンジする場面も用意したWBSを作ってあげたい。
いつも、WBSを作る前に色々な人に何を考えているか聴いてまわります。それでもうまくいかないぐらい、何でも難しい。


いつもですが、言いたいことが感情的すぎてまとまりがないのですが、人は相手の立場も状況も過去も何も分かっているわけではないのです。
相手を思いやっている、相手に優しくしてあげるのではなく、それでも私はできるだけ、相手になったつもりで行動できるよう、これからも切磋琢磨していきたいと、改めて考えました。

HUNTER☓HUNTERで素敵な言葉があります。「その人を知りたければ、その人が何に対して怒りを感じるかを知れ。」

これも同じ事を言いたいのかなぁとか、勝手ながらに解釈したりしています。
posted by Kiruahさん at 09:00| Comment(0) | TrackBack(0) | 日記

2012年04月05日

フレームワークが提供するロギング機能について

特にJavaについてですが、フレームワークが例えあったとしてもパフォーマンス上もしくはコーディング上、さらにはこういうものだという思い込みもあって、各クラスにログ初期化コードをそれぞれ記述しているのではないでしょうか。

例えば、Apache commons-loggingであれば、

public class Sample {

private static final Log LOG = LogFactory.getLog(Sample.class);

/**
* 業務処理
*
* @throws Exception システム例外
*/
public void process() throw Exception {

}
}


これはとても最適なコードのように見えます。初めてSampleクラスが初期化された際に、たった一度だけログ出力用のインスタンスが生成されます。

ですが、これらが各業務プログラムに乱立すると、どのクラスだけをログ出力したいか、簡単かつ詳細に定義できないことが多いのです。
例えばこのクラスが共通クラスであり、APサーバ上の共通libに配置しなければならない場合、このクラスは全てのWebアプリケーションから透過的に扱われることになります。
では、AというWebアプリケーションサーバではこの機能はログ出力したいけれど、BというWebアプリケーションではこの機能はログ出力したくない場合はどうしましょうか?

そもそもそんな需要はない?
性能を測定したいとか、障害が発生したとか、そういうこともないシステムならいいのでしょうが、実際にはそんなことはありません。

ログの制御は、log4jやLogBackを普通に使うのではなく、多少コストがかかったとしてもフレームワークが担い、ログインスタンスを業務処理に引き渡すべきです。
そして、フレームワークはシステムをわざわざ停止させなくとも、あるタイミングから業務処理を呼び出す時に引き渡すロガーの内容を、性能計測用、障害検出用、通常運用用と動的に切り替えられる仕組みを持つべきです。

ある1プロセスで、EAIアプリケーションのように複数のデータ転送を行う場合、例えば複数のサイトにFTPやDB、MQに接続する複雑なシステムの場合、縮退運転でサービスを停止させられない場合、これらにおいて、フレームワークがログ出力を動的に制御する機構を備えていることはとても保守運用者を安心させます。

残念ながら、未だにログ運用まで考慮できたフレームワークは見たことがありません。あくまで作る側の視点での出力です。それは、NTTデータのフレームワークですらできていないと言えることなので、絵に描いた餅という意見と言われても仕方ないのかもしれません。。。

少なくとも私は過去の案件において、フレームワークでログ制御を実施したことがあります。その際は通常何も問題がなければ実は動作しているかどうかも分からないぐらい何もログを出力しないシステムでした。つまり、起動しましたというログしかでません。

でも、実行中フレームワークが呼び出した第一階層の業務プログラムはフレームワークがログ機能を完全に制御し、まだ業務プログラムが扱う値はセッションのように値を保存することを前提とさせたため、障害が発生した場合(つまり例外が発生した場合)、拡張したロガーがどのプログラムで、どこまで処理してどういう異常終了したか、またその時の持ち回り変数の値は何だったかを全てダンプ出力するようにしました。

通常、障害がなければ何も出ませんが、障害があるときだけ、メモリの内容をほぼ吐き出し、ロジック上のスタックトレースや例外メッセージだけでなく、フレームワークがどこまで制御していたかまで出力することを実装したことがあります。

これは有識者が見れば、すぐに原因が分かるレベルでしたが、さすがに運用保守の人間では難しすぎたため、今では反省しています。(とはいえ、運用保守の人間が見るログと解析する人間が見るログ、統合運用監視システムが見るログはそれぞれ別で、それぞれに応じて出力内容を制御したりしましたが。。。あと、出力順にも優先度があったりなど)

そして、フレームワークでログが出せない場合(OutOfMemoryなど)は、APサーバがログ出力します。よって、アプリ用の通知ログ、APサーバのログ、APサーバ自体のプロセス監視、あとは、JMXよりももっと簡単にHTTPでシステムやスレッド(スレッド名を機能名に変更し、問い合わせしやすくしたり)の状態を確認できるようにし、運用監視できるようにしたことがあります(もう2年も前か。。。)。

昨今、正常実行中に無駄にログが出る割に、障害では必要なログが出ないシステムが多いと思います。少しでもそのような状況を改善できないか、模索中です。

2012年04月03日

ExcelハードコピーツールVer1.2の仕様変更について

1.2のリリース候補を利用して、Windows 7やOffice2010、Windows xp、Office2003等でテストを実施した結果、Windows 7のAEROとこのツールの相性はあまりよくないことに気づきました。

特に、ALT+TABを押下しても直前のウィンドウに遷移しないことがあるだけでなく、GetForegroundWindow()→GetDCEx()でデバイスコンテキストを取得し、メモリビットマップに転送しているのですが、そうすると半透明のウィンドウ枠が真っ黒になってしまいました。。。

これはPrintScreenでは発生しないため、GetDCEx以外か何かオプションが増えたりやり方を考えないといけないのですが、Windows xpでも動作させたいため、PrintScreenを押してクリップボードから画像を取得するという、原点の方法に戻そうかなと考えています。

また、設定も複雑ですので、設定画面を別途用意し、また、連続取得機能を用意したいと考えています。

とすると、1.1までと全く違う実装ではないかという反省が。。。

ごめんなさい。作ってみたら甘かったです。
元々は単純に画面のハードコピーを撮りたかっただけなのですが、色々と機能をつけていったら、、、よくばりすぎました。。。
posted by Kiruahさん at 21:42| Comment(0) | TrackBack(0) | 日記

Excel2003からExcel2010に移行するにあたって パート2

以前、「Excel2003からExcel2010に移行するにあたって」にも記載しましたが、Microsoft社にも互換性に関する情報がありましたので、あわせて情報連携と称して勝手ながらリンクしたいと思います。

1. 「Office2010 ホワイトペーパー : 互換性、マクロ、ファイル」のうち、特にマクロ互換性についてを参照ください。
概ねの内容について互換性がありますとありますが、AccessではExcelへのエクスポート機能が無効であったりします。またCommandBarsについて触れられていますが、CommandBarsにはテキストやコンボボックスも貼りつけられたり、縦方向に表示することもできます。そのような実装をしている場合については、検証されていない可能性があります。よくテストが必要だと勝手に考えています。

また、Declare文(つまりはWin32 API等を使う場合)について、32/64ビット版のうまい解決策が掲載されています。これについてはこれから検証してみます。

2. 「Office 2010 アプリケーション互換性ガイド
こちらはテスト計画、テスト方針を検討する上で参考になるかもしれません。ただし、事前に利用しているVBAの機能、ActiveX(COM/DCOM)が分かっており、それらがOffice2010でも動作することがベンダーによって保証されていることが前提と考えるべきでしょう。

問題は、上記では解決できない不具合は諦めるしかないのか?それとも別の実装を検討すべきなのか?です。
工数、つまりお金に関わる問題でもあるため、ここは顧客と相談が必要なのですが、そもそもその相談に必要となる情報を提出しにくいのが難点です。
すでにMicrosoftだからという理由は通用しない世の中だと思います。というか、最初からリバースを許容するライセンスなら、通用しないのは当たり前だったりするのですが。。。
(私ならリバースが許容されているならリバースしてしまいますし。。。)

昔、MicrosoftのSQL Server(正確にはMSDTC経由での複数サーバ間のトランザクション管理で、XIDが重複して採番されるためにSQLServerのトランザクションがゾンビになるという事象ですが)について不具合があった時、MSDNに入っていて会社経由で問い合わせたからだったからか、都合により情報を提出できず、Microsoftの担当の方から「これ以上は無理です」と言われ、「じゃぁ、うちで調べるからリバースしてもいいですか?」と聞いたら、しばらくの後「OK」と言われたのは良い思い出です。
posted by Kiruahさん at 01:00| Comment(0) | TrackBack(0) | 日記

2012年04月02日

現行からのリプレース案件、マイグレ案件の注意点について

こちらは以前にも似たことを書いたことがあります。

システムの再構築について http://kiruah.sblo.jp/article/45437976.html

今関わっている案件もリプレース案件です。この案件は基本現行をそのままプログラムを変更せず
新しいハードウェアに移行するというものです。
ですが、その中に一部仕様変更を盛り込みたいというものがあります。
私は何度でも言いますが、まずは移行だけをしましょう。
その後に仕様変更を取り込むようにすべきです。

でなければ、

1. バグが現行からなのか、それとも新規に追加した仕様なのかの調査が複雑になります。
2. 工数の計算が複雑になります。なぜなら移行なのか、それとも仕様調査なのか、修正なのかどちらのテストを実施しているのかが曖昧になります。これは工数請負の場合、特にユーザ側に後々不利になります。曖昧さは、こちらのマイナスを別の理由に転嫁できてしまうためです。
3. 若手がいる場合、教育工数が非常にかかります。当然現行の知識を知り、その上で修正分を理解する必要があります。まずは現行を移行しテストさせ理解した後で、変更分を理解させるほうが教育工数が減ります。
4. 経験的にですが、スケジュールの立て方が往々にして曖昧になりやすく、これぐらいで両方できるだろうという程度のスケジュールを構築しがちです。よって、後ほど時間が足りなくなることが多いです。
5. 後戻りが簡単です。移行が完了していれば、最悪仕様変更を取り込んでいないモジュールを使い、現行レベルを維持してリプレース運用は可能です。それが同時に行われた場合、切り離しが必要か、一部機能は問題がないとしても全機能の実装完了が必要となってしまい、ユーザのビジネス機会が損なわれやすくなります。

幸いにして、今の案件は現行調査と実際の修正はフェーズを分けることを全員が認識していたため、まずは現行のリプレースのみが完了しました。
よって、その後に仕様修正分を集約し変更するだけですので、横目に見ても作業は簡単に見えます。

SIerは一気に詰め込んでしまえ!と、何でもかんでも混ぜ込みすぎます。一つ一つを順次やるほうが、後戻りも楽ですし、差分検出、過去からの不具合なのかを明確に順次トレースできます。
やり方、考え方はいつも、「急がば回れ」です。
posted by Kiruahさん at 22:00| Comment(0) | TrackBack(0) | ノウハウ

2012年04月01日

Excelキャプチャツール1.2をテスト中

そんなに必要となる場面もないように思うのですが、
Excelキャプチャツール1.2を実装、テスト中です。
近日中にリリースできるのではないかなと思います。

とりあえず修正点は以下の通りとなります。

・64ビット版ではエラーが出るため、事前に宣言をコメントとして用意しました。
64ビット版用のファイルを用意しても良いと思いますが、そうするとソースのダブルメンテになるので、それを解決できるような仕組みが欲しいです。

・PrintScreenキーによるショットも取得可能に変更にしました。むしろ、スクロール時のショット取得開始キーをShiftからPrintScreenに変更しました。
ショット取得開始キー、手動キーはF3セルの取得タイミングより選択できるようになっています。
CTRLの場合 : CTRL
Shiftの場合 : Shift
それ以外の場合 : PrintScreen

・スクロール終了検出がWordでは甘いことが多かったため、チェックの内容を変更しました。その代わり、少し低速です。。。

・別ショットを選択した場合、全てのショットを取得してから貼り付けるのではなくショットを取得、貼付けを繰り返すようにロジックを分割しました。


使う人も少ないとは思いますが、もう少々お待ち下さいませ。
私はこれなしではもう、Web画面のテストはできないですが。。。
posted by Kiruahさん at 14:02| Comment(0) | TrackBack(0) | 日記