ということで「最近の労働。① ～ジェバる」に続く。
空気を読めて仕事のできる人になるにはどうしたらいいか？
最近「自分には無理なんじゃないか」と思うことをどうしてもやらなければならないことが増えたので、真剣に考えるようになりました。社内のジェバンニと呼ばれて「ジェバる」を流行語にするために
まず何を言われても分かる知識。
知識あっての経験。
その２種類が圧倒的に足りないなと思いました。
CLRレベルの知識なんてほとんどないし、実装に溺れてるような状態。
実装をこなすだけならそれこそ１晩どころか、１５分でできることもたくさんあります。
だけどその積み重ねの結果できたアプリケーションで、積み重ねた知識とはまた別に知識を求められることもよくあるわけで。
経験があれば当たりをつけて、「もしかしたらこのあたりのこと？」と資料を漁って学ぶことも簡単なのかもしれないですが、如何せん「どの知識を探せば実現できるんだろう」と思うことの方が多く、勉強するのは楽しいんだけどそれじゃ間に合わない…という悲しい実装もなかなか多いです。
知識があってこその経験、経験あってこその知識、でもどっちがどう自分に蓄積されているんだろう？っていうのはまだ実力が足りなくて図れないわけで、思うようにジェバれないわけで（くどい）
今までは実装のために知識を詰め込む感じだったですが、整理して記憶して、以前にどう使ったかを覚えておくことが大切だなと感じました。
資料を作ること、一度覚えたことを忘れないこと、問題点も記憶すること。
そういう整理にこのブログが役に立ったらいいなと。
■最近覚えた内容
・ASP.NETでBODYでjavascriptを使う。
どっちかというとDHMLで擬似Flashみたいなのをやってみたいんですが。
ASP.NETで遷移先の画面でどうしてもキャッシュを読み込みたくないため、遷移にjavascriptを使いました。
A.aspxにアクセスして認証を通ったらB.aspxに遷移するとき、B.aspxのキャッシュを読み込むのが不都合だったのです。
ただ認証をはさむため、認証結果がOK→B.aspxへ、認証結果がNG→エラー.aspxへという実装をすると、エラーへはResponse.Redirectで問題ないんですが、B.aspxへキャッシュを読まずに遷移をするためにはonloadでjavascript関数を実行する必要があり。
どのオブジェクトのonloadにするか散々迷ったんですが、Pageオブジェクトはrunat="server"にできないっぽく、HTMLの<body>をサーバオブジェクトとして使うことにしました。
[HTML]
<body id="BodySrv" runat="server">
[javascript] ＊BODYの外に書いておいたほうがいい
<script type="text/JavaScript"><!–
function replace(url){
location.replace(url);
}
//–></script>
[C# code]
System.Web.UI.HtmlControls.HtmlGenericControl Hg
= (HtmlGenericControl)this.FindControl("BodySrv");
Hg.Attributes.Add("onload", "replace(‘" + 遷移先URL + "’) ");
こうすると、Bodyの読み込みが終わるまで「認証中…」とA.aspxの画面に表示させることができ、B.aspxに遷移したときはキャッシュを読み込みません。
個人的にBODYタグがサーバオブジェクトになるというのが衝撃的なほど便利！
これを使うと、セッションにModeを格納しておいて、セッションから読み取ったModeにあわせてBODYのスタイルシートを切り替える、なんてことができるのがすごい。
苦労してBackground-ImageだけをStyleで切り替える必要がない。
そんなにレベル高い話ではないんですが、静的なデザインサイトをDBから読み出して動的に作らなきゃいけないときはかなり便利でした。
ただ、A.aspxにアクセスするときキャッシュを読んでしまい、１度しか使えないアドレスからのアクセスなどに不都合があった場合は、A.aspxのCSに
[C# code]
Response.Cache.SetCacheability(HttpCacheability.NoCache);
を書いておくとA.aspxで必ず認証が行われます。
キャッシュを読まれるとデバッグでブレイクポイントに止まらないのでわかりやすいです。
・PostgreSQL 思ってなかったto_date()の変換
とあるストアドがうまく作用しないよーという調査結果。
DBに入っている日付を検索対象として、その期間に含まれているデータを検出する簡単なストアドだったんですが。
to_date(text, text)の関数を使って見事に失敗しました。
to_date(date型, ‘YYYYMMDD’)で正常に変換するのかと思いきや、謎の日付に変換されました。
date型になっているものは念のためにダブルキャストをかけていたんですが、うまくキャストされません。
text型じゃないdate型からto_dateを使おうとしちゃったときは気をつけろ(´･ω･`)
・DataViewとDataViewRow
DataSet+DataTableを使ってADO.NETでWindowsFormsのグリッドにバインドすると簡単にグリッド表示ができますが、グリッドのソートを行うと正常に対応しません。
ソートされたグリッドの表示と、実際のDataTableのソート順が違うからです。
ソートされた内容はDataViewで対応させることができます。
DataViewはDataTable.DefaultViewでオブジェクトとして取得できます。
DataViewと実際のDataTableを対応させるときは、DataViewRowから取得します。
DataViewRow.RowでDataTable.DataRowの内容を取得できます。
なんでC#のコードを書かないのかというと、VB.NETで開発しているからです＿|￣|○
私はC SharperなのでVB.NETを使うといきなりプログラム言語が不自由に＿|￣|○
VBからC#にうまく翻訳できない(´･ω･`)
ちなみにこんなのも使っていました
TrueDBGridヤバイ
AfterSortイベントのe.Conditionからソート句の文字列をまるごと取れるので便利です。
ただしソート後のイベントなので、ソート前の状態の選択列を取得しようとしたりするときは、ソート前の文字列を取っておいて比較しなくてはならないので微妙です。
もっとたくさんやったんだけど、最近はこんなところ。
ネットワークが好きなのでネットワークの勉強もちょこちょこしてるんですが、ネットワークコマンドを覚えたりルーティングの基本を覚えないとわからないところが･･･。
ルーティング、全くわかりません。スイッチつかってサブネット作ってでもそれって何？状態。
アーキテクチャに非常に弱いのもダメダメなところか。
今壁にぶち当たってるのは、「ASP.NET用のサーバで、すべてのセッションから一意に参照できるオブジェクトは存在するのか？存在するならどうやって実装するのか？」ということですね。
各セッションに情報を持たせて画面ごとにオブジェクトを動的生成するアプリケーションがあるのですが（というか普通はそういう作りだと思うんだけど）、重くなってきたらしく、サーバにメモリ２G積んでいても足りないと思うのでメモリにデータを展開しないで済む方法を探しています。
シリアライズが関係するのかもと勝手に思っているのですが、SessionStateModeはInProcなのでどうなのとか。
サーバキャッシュしてもメモリに展開されたらダメかも（上司談）なので、どこをどう調べるべきかいまいちわかりません。
描画に時間がかかる（生成件数が多い）ところ、作成に時間がかかるところ、検索に時間がかかるところ、それともサーバのスペック？LANのトラフィック？と問題の切り分けもなかなかうまくいかず。
(´･ω･`)うーんどういう実装をすればいいなだ
と来週からまた悩まなければ。
「＠ITとかでたたかれるように質問しといて」って笑顔で言い放つ上司、それ笑えませんから((( ；ﾟДﾟ)))
とりあえず最近の労働はそんな感じでした。
はやくジェバンニになりたーい（なれるか）
低気圧ボーイ 