プログラミング：その他

ローマ字も標準化してくれないかな

シャノン — Tue, 05 Aug 2008 19:06:00 GMT

マイクロソフト製品ならびにサービスにおける外来語カタカナ用語末尾の長音表記の変更について

マイクロソフトが長音の表記ルールを変更したというニュースはまだ記憶に新しいところです。
俺はこの件についてはコメントを差し控えます。

ところで、マイクロソフトはアメリカの企業ですから、ローマ字表記なんて使わないでしょうが、日本でシステム開発をしている皆さんはどうでしょう？　変数名やコントロール名にローマ字表記を使っているでしょうか？

全部英語にするという人もいるかもしれません。
が、英語に不慣れな我々がやると、ましてや業務固有の用語などは、どうにも不自然な訳になってしまいがちです。
そのため、俺はローマ字容認派です。

日本語（漢字かなカナ混じり）で名前をつける人もいるかもしれません。
やめろとは言いませんが、俺は嫌です。
IMEをONにしないとインテリセンスさえ出ないのはものすごくイライラします。
まぁ、えっと…何て言うんでしたっけアレ、ローマ字タイプでインクリメンタル変換してくれるやつ…が搭載されればいいのかもしれませんが、難しいかもしれませんね。

閑話休題。

ローマ字の難点は、表記のゆれがあることです。
例えば、「状態」は「Zyoutai」か「Joutai」か。「Jyoutai」なんてのも見たことがあります。
「調査」は「Tyousa」「Chousa」「Cyousa」のどれでしょうか。
「開始」は「Kaisi」でしょうか、それとも「Kaishi」でしょうか。
長音は省く場合もあります。「東京」が「Toukyou」ではなく「Tokyo」になるように。
これらはあらかじめ決めておかないと、プログラミング段階になって混乱します。

こういうのも、どこかが指針を作ってくれないかな、と思うんですけど…そう思いませんか？

ぐぐっても出てこなくなったなぁ…

シャノン — Fri, 18 Jul 2008 18:52:00 GMT

VB6の資料orz

何の冗談でしょうか？

シャノン — Tue, 10 Jun 2008 19:12:00 GMT

VB6なんですけど。

グリッドコントロールを使わないで、ラベルと Line で擬似グリッドを実現するってのは…。

フォーカス制御も全部自前。データバインドなんてありません。ADOっておいしいんですか？
サーバ側プロセスが DB からデータを取ってきて、それをソケット経由で受け取って、クライアント側でゴリゴリ編集して、サーバ側プロセスにソケットで送り返して、サーバ側プロセスが SQL 組み立てて DB に書き込みます。

「うわぁ、プログラムってここまでひどく書けるんだ…」みたいな感じがしてきました。

…逃げていいですか。

続・何年かぶりにVB6

シャノン — Fri, 06 Jun 2008 17:27:00 GMT

久しぶりにVB6をさわったら、既定のインスタンスが大好きになってしまいそうです。どうしよう。~~これが恋？~~
コメントにしたら長くなりそうなので~~円取り立てました~~エントリ立てました。

いわゆる業務アプリ開発において。
画面がいくつかあるとします。
画面遷移図が木構造になっておらず、AからB、BからC、CからAという遷移が可能だとします（BとCを通ってAに戻るイメージです）。
木構造ならモーダルフォームで楽が出来るのですが、このように輪になっているとそれはできません。
こういう場合、次に表示する画面を毎回 new するわけにはいかないので、一度作った画面のインスタンスは、遷移元画面クラスの外に置かなければなりません。
既定のインスタンスは、それを暗黙のうちにやってくれるものと言うことができます。

VB6.0 で「Form の既定のインスタンス」を防ぐには?

防ぐなｗ

このような、正当な方法を利用するメリットはいくつかあります。

インスタンスを生成することで、初期化が保証される
スコープを狭めることができる (例のコードでは Command1_Click プロシージャ内でのみ有効)
結果、他の場所から勝手に呼び出されてしまう心配がない
外部のどこから操作されているのか明確になる
別のインスタンスを作って複製可能

ふむふむ？

インスタンスを生成することで、初期化が保証される
- 既定のインスタンスを使うと初期化されないんですの？
  既定のインスタンスのメソッドを最初に呼んだ時に Initialize が走るって書いてありますやん。
スコープを狭めることができる (例のコードでは Command1_Click プロシージャ内でのみ有効)
- それじゃ狭すぎて困るんです。遷移元画面よりも広いスコープが必要なんです。
結果、他の場所から勝手に呼び出されてしまう心配がない
- それはそうかも。
外部のどこから操作されているのか明確になる
- どこかで一元管理しているなら別として、遷移元画面で new しているような状況では、そんなに変わらないと思いますが。
別のインスタンスを作って複製可能
- 実のところ、同じ画面のインスタンスをいくつも作る必要がある場合というのは、そう多くないものです。

画面管理クラスをちゃんと設計して、遷移元画面から直接次の画面を Show しないように作るのが正道かもしれませんが、理想と現実は得てして異なるものです。
# 100以上のフォームを、「動かなくてもいいから、とりあえず今日中に画面遷移だけでもするようにしてくれ」って昼過ぎに言われてもね…。

何年かぶりにVB6

シャノン — Fri, 06 Jun 2008 13:50:00 GMT

フォームの既定のインスタンスって超便利じゃね？　ね？

自動販売機の中の人も大変だな…

シャノン — Wed, 04 Jun 2008 15:47:00 GMT

「クラスの設計は直感的に、シンプルに」と、よく言われます。
「迷ったら、自動販売機を設計しているつもりでやれ」という言葉もあります。

ですが、最近の自販機はそうも言ってられません。
当たりくじ機能がつくくらいならまだしも、Suicaに対応してみたりtaspoに対応してみたり。
あちこちに、機能をフックできるポイントを設けておかないと大変そうです。

…それはそれで面白そうですね。

JavaScriptわかんねｗｗ

シャノン — Thu, 15 May 2008 22:58:00 GMT

テラカオスｗｗｗｗ

MS、テスト環境の改良でソフト開発を迅速化を目指す

シャノン — Fri, 18 Apr 2008 15:50:00 GMT

MS、テスト環境の改良でソフト開発を迅速化を目指す

なんかMicrosoftが新しいことをはじめたらしいです。

Microsoft，「Office」関連のプロトコル情報を開発者向けコミュニティで公開

シャノン — Wed, 09 Apr 2008 11:02:00 GMT

いよいよ出てきましたね。

ニュースにはリンクがありませんが、MSDNを見ると、トップに階層が追加されているので一目瞭然ですね。
正式版公開の際には変わるかもしれませんが、とりあえずここです。
本家MSDNフォーラムでは既に活発な議論が交わされているようです。

今後が楽しみですね。

プログラムに文字列を埋め込むな

シャノン — Fri, 04 Apr 2008 11:44:00 GMT

プログラムを設計する際の基準のひとつに、「変更可能性」がある。
頻繁に変更される可能性がある部分と、あまり無い部分は分けて作れ、ということだ。
そして、プログラムの「見た目」というのは、最も変更頻度の高い部類に入る。
一般的に言って文字列というのはロジックじゃない（SQL文なんかはロジックだが）から、広義には「見た目」のうちに含まれる。
ということは、画面レイアウトと同じくらいの変更頻度はあると思っておくべきだ。

余談だが、ここは数値のマジックナンバーと大きく違うところだ。
マジックナンバーも埋め込んではならないとよく言われるが、盲目的に切り出すのは正しくない。
数値はロジックの一部を構成し得る。その数値が変わるとロジックが成立しないような、変更可能性が極めて低い（数値が変わる時はロジックごと変わる）ものや、名前を与える必要が無いほどに意味が自明なものもある。
そうしたものはむやみに切り出すとかえってわかりにくくなる。