眠る開発屋blog

HTMLで会計系のシステムのフロントエンドをがりがりコーディングしていて。
そういうば、その昔似たようなシステムをMSAccessで作ったのですが、やっぱりフロントエンドの開発効率自体はHTMLなんかよりMSAccessのほうが段違いにいいのね。

.NETとかだったらHTMLでもラクなのかな。
クエリーで取得できたデータを画面に記述する処理とかめんどうでめんどうで仕方ない。
ある程度、ライブラリ化すればラクになるんだけど、多分それでMSAccessと同程度の開発効率になるのではないでしょうか。

Webにするのは、運用する際の制約条件が幾つかあるからなのかな。
DBサーバのポートを開けておく必要もないから、セキュリティも確保できるし。

遅かれ早かれRIAの時代･･･クラサバ復活すると思うんだけど。
まぁMetaFrameとかシンクライアントでもいいんだが、フロントエンドにもっと効率のいいソリューションが選択されるようになればなぁ。

っていうか、MSAccessにWebサービス対応してほしい。
まぁ今でも一応出来るみたいだけど、もっと効率いいやつがほしい。
Microsoft Access 2002 から XML Web サービスを利用する

イマイチ効率悪いなぁ、と感じてしまうのは、それってつまり、
RDB => RPC的扱い => RDB的表現
だからなんだろうねぇ。

KLabの個人情報探索・監査ツール「Pポインター」

へぇーって感じ。

ところで個人情報保護施策ってこんな感じなのかしら。

1.個人情報収集の際の情報ポリシーの提示。
2.情報アクセス者の設定。
3.個人情報の破棄など管理方法の設定。
4.情報アクセスへのロギングを行うスキーマの構築。
5.社員教育

5が一番のハードルなのかしら。
社員にとってみれば以前よりも何かと不便になるのは明らかだし。

でも実際に取引条件のひとつにPマークやISMSの取得を挙げているところもぼちぼち出てきているしなぁ。

Javaのゲーム用ライブラリ、
GOLDEN T GAME ENGINE(G T G E)

どうなんだろう、使えるのかな。
スプライト機能とかあるっぽいけど。
ライブラリ自体、機能が絞られていて、割とシンプルっぽい感じ。

とりあえず気をつけておこう。
ここから引用。

こういうのが出てくるとメジャーになっただねー、なんて思う。

>
ここ に発見時のやりとりが書いてあった。

「spoolcll.exeってlegitimateなの？それともウイルス？ 」
「なんかわけのわからないサイトへアクセスしてるんだけど」
「びっくり！ぐぐったけど何も出てこないよ」
「MicrosoftにもSymantecにもKasperskyのもMcAffeにもなかった」
「正しくファイル名うった？」
「スパイウェアじゃないの？」

あ、超意訳ってやつですよ、これ。

D言語の本（Ｄ言語パーフェクトガイド）を買ってきてパラパラと読んでます。
C++から多重継承の派生系と考えた方がよさそうだ。ポインタもあるし。

連想配列があるのは便利だなぁ。
あと大きな点は開発者用の仕組み･･･契約プログラミングとかアサーション、単体テスト、バージョン管理･･･が言語仕様として取り入れられていること。
Ｊａｖａ然り、これって最近の潮流なのかもしれないね。
そのうちロギングとかパーシステント、セキュリティとかの仕組みも取り入れられた言語も出てきたりして。

ただいつまで「コード」なんだろうか。
もうそろそろビジュアライズされた実感的によく分かる開発言語みたいなものが出てきてもいいのになぁ、なんて。

っていうかハンガリアン記法って今は結構否定されているのか。
どうやらＣ＃でもあまり推薦されていないようだし。

大きなものをいきなりガツンと作るよりかは、小さなものをコツコツ作っていき、トライ＆エラーできた方が質の高いものが出来ると思います。

まぁそれを前提条件として、じゃあ小さくコツコツを妨げるものは何か。
新旧システム刷新による移行時の混乱が大きいのかな。

「人間が混乱する」「システムが混乱する」の２つが定義できそう。

・人間が混乱する
移行時には異なる操作体系をもったものを同時に扱う必要があるので混乱する。
・システムが混乱する
早い話新旧システムのデータ移行、インフラ移行をどうするか？ってこと。

この２つに対して、何らかの回答･･･かトレードオフか？･･･が出来れば何とかなりそうな気もしますけど。
っていいますか、「追加」の概念でシステム開発を進めれば案外スムーズに行きそうな気もしますし。段階的システム以降って多くの場合、別に普通にできそうな気がするんだけどもそうならないのはなぜなんだろうね。
社内一斉リプレース！の利点が自分はよく分かってはいないのだが。統合性の高いシステム開発が出来るのか？でも別に基本的なライン（ルールブック）さえ固まっていればモジュール追加でもそれって出来そうなもんだけど。会計処理上の都合なのかしら。

ちょっと感じたことをパラパラと書こう。
全然まとまってないし。そのうちまとめなおすかも。

規模がやや大きくなってくると似たようなコード･･･パラメータの一部だけが違うとか･･･を書くことが多くなることがある。
設計がそれなりに練られていればそうでもないのだが、ベタベタな設計だと、似たようなモジュールが量産されることになる。

ソースを生成するためのツールというか、CVS形式のデータを読み込んで、テンプレート化されたモジュールを一気に作りこむ等そういうツールが欲しくなる。
私感だが、Perlがもっとも適しているような気がする。文字列処理が強力だし、何しろすぐに書けるし。

もし詳細設計まですぐに決まっていて、何も考えずにコードを大量に生産するのがより求められるのであれば、Perlなどを用いて、機械的にコードを生産することをお薦めする。
というか、JavaBeanってたとえばPOJOであろうがベタベタ（setとgetばかり）になってしまう。その為のXDocletなどのツールなんだろうけども。

実はMDAにしても、
「WordをVBScriptで解析し、そこからソースコードを吐き出す」
という仕組みが出来れば、すぐにでもやれるのではないか？とか。

スクリプト系言語についてももう少し。
ルールエンジンなんて発想しかり、どこかで「手続き型コード」というのを求めており、それが手っ取り早く書けるのがスクリプト系言語なんだろうなぁ。

あとAOP実現の為のバイトエンハンスドとか見ると、「スクリプト系だったらソースを正規表現でひっかけて書き換えればいいじゃない」ってなってしまう。
J2SE5のメタデータは便利かな、って思うけど。

個人的にPHP、Perlのイヤな部分って、OOPをやる際の厳密性チェックの緩さなんだけども、そこが今後厳密になっていうのであれば･･･実行時のオプションとか？･･･、スクリプト系のほうがいいのかなぁ。

バイトコード化の利点の一つはソースコードの隠蔽なんだけども、こんだけネットにパブリックドメインでしかも洗練されたソースが溢れているんだもの。今更何を隠蔽しようとするのか？
また、ネイティブコードについても、.NET Framework しかり、年々重要度は低くなってきているというか。

AOPについて。
AOPは横断的関心の分離が肝。
じゃあ横断的関心って何？ってなったときに出てくるのがロギング、トランザクションなどの非機能的要件。
個人的には非機能的要件って例えばAPサーバ側の設定とかそういう形で分離可能だったのかな、って思うけど、同じ言語構造の中でそれらも管理したいのか。
こうすればすごくメリットがあるよ、みたいな部分がいまいち分からない。
C++からJavaが会得できたことって、多重継承の中止による複雑性の排除だと思うのだけども、AOPって実は複雑性を増すだけじゃないのか？シンプルになるのか？

PHP+MySQLで使用できるCMSツール。
XOOPSより軽快らしいけど？

関連サイト
Mamboじゃぱん

ドキュメントを読まない輩 というページより、Googleの検索によりLimitの危うい使用方法が沢山見つかること等に言及して、

システムに携わるものとしては大切な視点だなぁ、と反省しました。
一次情報を確認することが大事なんですね。

とはいうものの、ここ でドキュメント自体の危うさにも少し触れている。

自分がやっていることの意味を正確に把握することが重要。

とあるPJの進捗会議にて。

「これはどうなってるの？遅れてるの？じゃあどうやったら遅れを挽回するの？」

ってさ、まぁPLがPGを責めるわけだが、個人的にはPMが一歩二歩先を読んで、人を増やすなり期間を延長するなり作業の割り当てをやり直したりするしかないと思うんだよ。
思い切って人を変えてみればいいのに。
変えた結果、新しく来た人間がいいか悪いかは完全にバクチだけども。

たとえうまい策とか見通しの言葉をPGから引き出せたとしても、そのうまい言葉通り計画が進むか否かが非常に疑問。
責められて話す時点で言い訳だからね。
説明がうまいことと計画が無事遂行することって全く別問題だから。
そうなると、失敗の可能性が非常に高いといいますか。

前も書いたかもしれないけど、本人の能力への期待がやたらと高いんだよね。
人の能力やモチベーションに期待しないPLほどうまくPJが回ると思うなぁ、常々。