カテゴリ:
久しぶりの投稿です。実は,5月末に第二子が誕生しまして,ドタバタしてなかなかブログを書けませんでした。

母子共に健康です。既に退院しています。
元気な男の子が誕生しまして,当初は女の子ではないかと思っていました。
というのも,私の父親の兄弟の子供で,女の子がいるのは私の父親のみでしたので,女の子だろうと。
ところが男の子でした。まあ,男女関係無く元気に育っていただければそれだけで満足なんです。

さてと,出産当日ですが,前日に充電していたビデオカメラ。当日に試し撮りしてみようと電源ON。
あれっ,画面が真っ暗。当然ながらレンズキャップも取り外しているし・・・・・・。
当日になって故障かよ・・・・・・。使えないなぁVictor。
いや,Victorが悪いのではない。放置していた私が悪いのだ。10万円以上もしたカメラだからね。何とか修理して使えるようにしないとな。まだモトは取ってないし。

義妹のビデオカメラを拝借し,それにて録画開始。出産直後の我が子をしっかりと録画しましたよ。

それにしても,胎児の成長やら新しい命の誕生のメカニズム。医療技術等が発達して解析されているとはいえ,まだまだ謎が多いんじゃないかな。というか,まだ人間の体内メカニズムすら100%解析されていませんからね。

子供が生まれると,各種手続きが必要になる。児童手当やら乳幼児医療手当て等は全て申請。
でもさ,行政って不思議だよね。全てにおいて申請。申請。申請しなければ何も貰えない。

医療機関にて誕生→担当行政課に連絡→各種手当て自動申請

と,ネットワーク化されていないんだよね。このあたりが古いと思う。縦割りって言うんだっけ?
税金をあれだけたくさん吸い上げているのに,こういったちょっとした仕組みすら整備されていない日本はダメだね。

衆議院選挙やら郵政問題,正直国民にとってはどうでも良い事。そんな事でお祭り騒ぎするよりも,もっと検討して解決しなければならない問題・課題がたくさんあるだろうて。

まっ,このブログに書いたところで変わるわけでもない。

ん?外でドンパチ花火?(イベントがあるときの音だけのやつね)が上がった。
どこかの学校で運動会かな?
1

カテゴリ:
今の開発環境には,SQL Server 2000 が4台あります。
とあるSQLを実行したのですが,4台中1台のみSQL実行エラーとなる。

何故だ!何故なんだ!SQLは同じだし,テーブル構造も同じ。なのにたった1台だけエラーとなってしまう。

そのエラーとなるサーバ。
テーブルを参照する際に,「hogehoge.dbo.hogeTBL」とフルパスを設定している。
クエリアナライザで,データベースを「hogehoge」と指定してSQLを実行するとエラーとはならないが,「master」と指定してSQLを実行するとエラーとなる。

原因を探ると,どうやらそれはSQL Serverの「サーバー照合順序」が関係するのではないかとの結論に達した。

4台のうち3台は「Japanese_BIN」,残りの1台は「Japanese_CI_AS」。

その1台の「master」のサーバー照合順序は「Japanese_CI_AS」,「hogehoge」のサーバー照合順序は「Japanese_BIN」。
つまりは,直接データベース「hogehoge」を指定すれば「Japanese_BIN」となるが,「master」のままだと「Japanese_CI_AS」→「Japanese_BIN」となるのであqsws@@dそいれあr@じゃせふじこ

まて,今まで他の案件や改修で,こういった状態でテストしてきたんだよね。何故不具合が出なかったの?

今回,たまたまSQLのSELECT句内に不等号を使う式があり,それでエラーとなったわけだが,つまりは今までそういった処理が無かったってことなんだね。

本番環境が「Japanese_BIN」なら今回の不具合は発生しない。
本番環境をまだ確認したわけではないが,仮に「Japanese_CI_AS」だったら事態は深刻。上長に相談しなければならない。
→本番環境は「Japanese_BIN」でした。一安心。

データベース「master」の再構築をすれば良いようだが,ユーザ情報等が消えるようだ。
と,他の方々も使っているこのサーバー。使えなくなることは避けたい。
ということで,とりあえずその場しのぎではあるけど回避方法。
Japanese_BINのデータベースを新規作成し,通常ログインするユーザーのデフォルトデータベースをその新規作成したデータベースとする。
こうすることで,Japanese_BIN→Japanese_BINと照合順序は変更されないので無問題で処理される・・・・・・。と思う。

担当の方には,「あくまでもその場しのぎの方法。根本的な解決ではない。」事を伝えておいた。
今の作業が落ち着いたら,サーバー再構築だな。OSから。
1

カテゴリ:
既存プログラムを元に新規プログラムを作っているわけですが,解析した結果,とんでもない処理をしているんですね。
当記事のタイトルにもあるとおり,Session変数の無駄遣いです。

帳票を出力する際,データベースからデータを抽出し,そのデータを基にXMLを作成しているのですが,なんとそのXMLのソースがファイルではなくてSession変数,つまりはサーバー上のメモリに展開しているのです。
メモリ上なのでプログラムが終了すれば跡形も無く消えるわけで,デバッグを難しくしている。
Session変数は,接続するクライアント毎に設定されるわけで,接続するクライアント数が多ければ多いほどSession変数も増える。
クライアントが少なければそれほどサーバーの負荷とはならないけど,エンドユーザーの環境はWebサーバーに各クライアント端末が接続して作業を行うわけで,クライアント端末は10台以上です。
サーバー側もラックマウントのサーバーですけど,積んでいるメモリにも限界があるだろうし,何故こんなつくりにしたんだろうかとつくづく疑問に思う。
せめてHDDにファイルを作成し,それを帳票側プログラムで読み込むとかすればよいものを。
先に投稿した記事にもあるけど,1プロシージャが3,000行もあるなんて異常だし,いったい誰がこんなつくりにしようと決定したのだろう。作った人の脳を見てみたい。

作り直したいけどそうはいかず,インターフェースは保持したまま行うしかない。
1

カテゴリ:
普段愛用しているSoftBank携帯911Tが壊れました。
電源が入らなくなりまして,どうしようもありません。

幸いにも,嫁が以前に使っていたVodafoneブランドの携帯電話があまっていたので,それにUSIMカードを挿入して代替としています。
(こういう緊急時にSoftBankやdocomoは楽ですよね。auはUSIMカード入替だけでは使うことはできませんから)

何故電源が入らなくなったか。原因はまったくわからない。
ネットで調べてみると,どうやら911Tで同じような現象に遭遇している方が多々いるようです。

とりあえず今度の土曜日にショップにもって行きますが,修理となった場合,内臓の電話帳やらデータフォルダのデータが消えてしまうみたいで,それが一番痛いですね。バックアップも何もしていないし。

というか,auを使っていた時に電話が故障するなんて一度も無かったんだけどさ,SoftBankのブランドというか品質がダメなのか?

まあ,いまさらグダグダ言っても仕方が無いので,修理に出します。

カテゴリ:
何故にあんなに早起きなんだろうか。
時刻は午前5時。突然急所に衝撃が走る!
何事だと思いきや,どうやら我が子が私の上にダイブし,足が急所に直撃したようだ。
当然ながらその時点で眠気が飛び,目が覚めてしまう。

私も昔はそうだったのだが,何故休日に子供は早起きをするのだろうか。
休みでうれしくて興奮する?いや,まだ私の子供はそんな事をわかる年頃ではないのだが。

でも,休日に早起きするとなんだか得した気分になりますね。
なんだかんだで「(休日専用の)子供の目覚まし時計」には感謝しています。
どうせなら平日も起こして欲しいのですけど,平日は平日で二度寝する(笑)

まっ,良いですよ。元気に育ってくれればね。それくらいは我慢しますって。

カテゴリ:
青森をはじめ厳冬期を迎える地域の人達は,車を駐車させる際にパーキングブレーキ(サイドブレーキ)を使わない人が多い。ATならシフトレバーを[P]にいれ,MTなら[1]か[R]に入れておくわけです。
これは,パーキングブレーキが凍結(正しくは,パーキングブレーキのワイヤーが凍結)して解除できなくなる恐れがあるからです。

でも,ここで疑問に思う。パーキングブレーキを使わないのは冬季だけならまだしも,通年使わない人が多いのです。冬季期間は上述したとおり凍結するおそれがあるので使用しないのは理解できますが,凍結の恐れが無い冬季以外でなぜ使わないのだろう……。

自動車教習所でそう習うのでしょうか。
仮にそうだとしたら,そう教える自動車教習所が信じられません。

ATにパーキングブレーキは不要という考えを持っている方も多いが,不要ならメーカーが装備しないわけであって,必要だから装備されている。

[P]はギアがかみ合ってロックするだけで,タイヤそのものを制動しているわけではない。パーキングブレーキは,タイヤ(ブレーキ)を制動する。

ちなみに,私の車はMTですが,冬季もパーキングブレーキを使用します。
だって,凍結するのってワイヤー内部に水分が入って,それで始めて凍結の恐れがあるわけですが,そう簡単に水分は入らないし。

北国の常識=北国以外の非常識

ちと言い過ぎかもしれないが,車に関しては私はそう感じる。

1泊2日のお仕事です。

カテゴリ:
昨日〜本日にかけて,泊りがけの仕事でした。
同じ青森県内なのですが,翌日,すなわち本日は朝一で作業現場に入らないといけない。
本社から車で2時間以上かかり,前日の作業が遅くなることが考えられたので宿泊となりました。

ビジネスホテルに泊まるのは久しぶりです。
東横インに泊まったのですが,このホテルはペイチャンネル,すなわち有料放送が無いのですね……。DVDやらISOイメージやらを持ってくればよかったよ。

そして,昨日は22時30頃までの作業,翌日は意外とすんなり作業完了。それでも朝8時に入って16時30分頃までかかりましたが。

そして帰路です。
青森県には八甲田山がありまして,この山は今の時期,残雪があります。
この時期,山道を通るのはなかなか勇気がいるのですが,ライブカメラを見る限りでは雪が無かったので山道走行が決定。

八甲田山録


まだ雪が残っています。
というか,青森県は,4月26日に降雪がありましたよ。

と,仕事が一段落し,帰宅。勝利の美酒を味わっています。
1

カテゴリ:
今年に入ってからYahoo!カードを作った。
Yahoo!カードSuicaにしようか迷ったが,今住んでいる地域での駅はSuicaが使えないし,モバイルSuicaがあるから良いかなと思っていたわけです。
(でも,モバイルSuica年会費よりもYahoo!カードSuicaの方が年会費安いのね)
カード到着後,モバイルSuicaにYahoo!カードを登録しました。

で,ETCカードも無料ということで同時に申し込んだわけですが,なんとそのETCカードに年会費が発生するとあったよ!

1年間でYahoo!カードを30万円以上使う(=3,000ポイント以上獲得する)(除くキャッシングや年会費,Edyへのジャージ)人は,ETCカードの年会費が無料との事。

独身時代だったら,おそらく年間30万円は使っていたでしょう。(1ヶ月当たり25,000円だから,携帯電話料金やプロバイダ料金,電気代やガス代等でそれくらいは行く)

だが,結婚してしかも子供が居る。年収もも青森にきてから地域格差なのか200万円以上ダウンしてるしな。
そんな状況で年間30万円以上も使うか?いや,使わないだろう。

ということなので,解約することとした。ETCカードは,先日出光カードまいどプラスを作ったときに同時に申し込んで,それがあるので無問題。

高速道路を頻繁に使うようになったら,またYahoo!ETCカードを申し込む事とする。
1

カテゴリ:
少々愚痴っぽくなってしまう。

知人は,典型的な地方のDQN女。
でき婚からはじまり,今はその夫とは別居状態。
でき婚を悪いとは言っていないが,所詮それがきっかけで結婚したわけだ,相手の良し悪しを知らないうちにな。ふっ,結局別居かよ。とっとと離婚しちまえ。
知人には子供は二人居る。その子供がダメだ。子供だからというレベルではない。仕付けがなっていなく,特に食事時のマナーは最悪。
食事前「いただきます。」,食事後「ごちそうさまでした。」が言えない。言わない。
私の子供のほうがまだしっかりしているぞ。自分の席でしっかりと「いただきます。」「ごちそうさま」が言えてるのだからな。

車の運転もDQNそのもの。
シートベルトを着用しない。着用しない理由を聞いたら「面倒だから。」
そうか,面倒か。

 事故って車外に放り出されて車の下敷きになって死んでしまえ!
 脳挫傷で死んでしまえ!
 全身打撲で死んでしまえ!

違反となるから着用するのではなく,万が一の時に自分のみを守る為の物なんだけどな。
ちなみに,知人はシートベルト未着用で2回ほど検挙されていますが,長距離移動時以外は未だに未着用。学習能力=ゼロ。青森県警に通報してしまおう。
片手運転の常習犯でもある。右腕をハンドルの中央,左手は肘掛へ。
そんな状態で隣に乗る知人母とおしゃべりに夢中。今までよく事故を起こさなかったな。
正直,知人の運転する車には乗りたくない。見ていて怖いのではない,イライラするからだ。
まっ,所詮「井の中の蛙,大海を知らず。」状態。首都圏で運転したら事故を起こすのは間違いない。

お金が無いといいながら,10,000円以上もするカバンや服を通販で買う。
いったいいくつのカバンがあるのだろうか。というか,使えるカバンが1つあれば事足りるじゃないか。
常に携帯電話でネットしている。お金が無いなら,そういったところでコストダウンをしろよ。
私だって携帯電話をパケット定額上限まで使いたい。が,可能な限り使わないようにしているのだよ。

知人は「機能美」という言葉を知らない。知らないが為に,最新のデジカメをデコしてしまった。
呆れて物が言えない。
デコを否定するつもりは無いが,義妹のデジカメのデコは,誰が見ても「やりすぎ」状態。

他にも色々と言いたいことはあるが,強く文句を言えないのが現状。
私の子供の面倒を見ていただいたりしているので,「その点」は感謝しているが,それだけの事。

知人には一度,普通の会社で勤務していただきたい。
社会的な常識が欠如している,義妹は。

ダメだしされてもそれを肥しに反省しようとせず,怒りにしか変わらない。
1

カテゴリ:
今の仕事で,既存プログラムをベースとして新規にプログラムを作っている。プログラム本数は,おそらく3本程度になるでしょう。

で,ベースとなるプログラムを見てみた。
約3,000行でした。プログラムソース全てではなく,とある1プロシージャ内の行数が^^;
約3,000行あるプロシージャが2つもある。これの解析は大変だぞ。

その3,000行の内訳を見てみよう。
コーディング規約なのか,修正/改修の度に古い処理をコメントとして,その前後に新しい記述+修正日付等のコメントがある。
この様なコメントが半分を占めているので,有効な(生きている)記述は1,500行くらいか。
(1プロシージャが1,000行を越えている時点で異常なんだけどな)

なんでこんな作り方をしたのか,製造元(提供元)に問い詰めたい。激しく問い詰めたい。
後々に修正等が入るのがわかっているのだから,1つのプロシージャで全ての処理をやろうとせず,外出しとしてくれよ。
手を入れた箇所ではなく,手を入れたプロシージャでテストをしなければならないので,影響範囲がでかすぎるのだよ。

そして,上述したような修正履歴記録方法だと,どんどんソースが肥大化していくわけです。
ちなみに言語はVisual Basic 6.0。私の記憶が正しければ,VB6での1プロシージャの最大サイズは,コメントを除いて上限64KB。
このサイズを超えるとコンパイルが不可能となる(経験有)。

幸いにも,現時点でコンパイルは通るが,とにかくこの作りをどうにかしないと。どけんがせんといかん。

来週で終わるかなぁ。というか終わらせないといけないんだけど。

あぁ,どこからかデスマのテーマが・・・・・・。

このページのトップヘ

見出し画像
×