1980円ソフトのソースネクストが東証マザーズに上場、上場予定日は12月20日

まじっすか、新興市場、ＩＰＯ北風ぴーぷーのこの時期に（＞＿＜！）

ここのニュース
ソースネクスト、マザーズに上場へ
http://www.itmedia.co.jp/news/articles/0611/17/news072.html

によると（以下斜体は上記ニュースより引用）

1980円ソフトのソースネクストが東証マザーズに上場する。同社は以前、旧ナスダック・ジャパンから上場直前に承認を取り消されたことがあった。

　東京証券取引所は11月17日、ソフト販売・ソースネクストのマザーズ上場を承認した。上場予定日は12月20日。証券コードは「4344」。


ウィリアムのいたずらの、今使ってるノートパソコンに入っているウィルスチェッカも
ソースネクストの「ウイルスセキュリティ」です

それはいいんですけどお。。
今っすかあ。。。
まじっすかあ。。。
新興市場、北風ピープーですよ。。
ジャスダック市場なんか、年初来安値を更新っすよ（＞＿＜！）
さらにＩＰＯも、このまえ上場した、あおぞら銀もぱっとしないし。。。

まじっすかあ、今上場するんですかあ。。。（＞＿＜！）

10月26─31日の料金も０円、ソフトバンクモバイル。でも料金０円と書いてないのは。。

ここのニュース
ソフトバンクモバイルが新プラン契約者に対し10月26─31日の料金を非請求
http://today.reuters.co.jp/news/articlenews.aspx?type=marketsNews&storyid=2006-11-17T074117Z_01_nTK2997044_RTRJONT_0_CnTK2997044-1.xml&src=rss&rpc=112
によると（以下斜体は上記ニュースより引用）


ソフトバンクモバイルは１７日、新料金プランの契約者に対し、１０月２６─３１日の料金を請求しないと発表した。システムトラブルで契約業務が遅延したことへの「おわびの措置」だという。


ほー、じゃあ、10月26─31日の料金も０円ってことね。
これは、予想外だ。。
でも、０円って書かないわけね。学習したのね。。
多分理由は。。。

国際通話料や国際ショートメッセージ、コンテンツ情報料、契約手数料などは除く。

やっぱ、０円ではない例外があるのね。それがソフトバンククオリティー

BREWで複数画面を開発する場合の方法論（その１８：Ｅｘｃｅｌで自動生成－その３：第二弾仕様）

　シリーズBREWで複数画面を開発する場合の方法論のつづきです。
　条件付書き出しについて、いままで、シリーズ仕様書からプログラムソースを生成する方法でやってきたので、それを使って、部品まで、書き出そうという話なのですが、今回は仕様です。

　なお、以下に出てくる第一弾とは、ここにかいてあるもののことです。

---

■仕様

●雛形ファイル
　第一弾の以下のファイル
　　　　アプリ用ソースファイル(app_c.txt)
　　　　アプリ用ヘッダファイル(app_h.txt)
　　　　画面用ソースファイル(gamen_c.txt)
　　　　画面用ヘッダファイル(gamen_h.txt)
　　　　バージョンファイル(version_h.txt)
　に加え、以下の画面ファイルを付け足して、
　　　　各画面（部品追加）ヘッダ(gamen_b_c.txt)
　　　　各画面（部品追加）ソース(gamen_b_h.txt)

　これらを、後述するExcel仕様書ファイルと同じフォルダに置きます。

---

●Ｅｘｃｅｌ仕様書ファイル
　　画面一覧シート（１シート）と、各画面シート（画面数分）の両方を記述します。

＜画面一覧シート＞
　　画面一覧シートが、以下のようになっているので

　黄色の部分を記入します。

＜各画面シート＞
　各画面のシートが、以下のようになっているので

　画面数分、該当画面の内容を記入します。

---

●実行と結果

　画面一覧シートの「ドキュメント作成」をクリックすると、
　各画面のシートの部品部分（５行目以下）に記入がなければ、
　　第一弾と同じく、initAppDataで-1で終了する画面ソースとヘッダを

　各画面のシートの部品部分（５行目以下）に記入してあれば、
　　今回の雛形を使って画面部品まで入れて、画面ソースとヘッダを

　作成します。

---

■実現するためにやること
　第一弾のときは、固有のプログラムであるinitAppDataで、
　作業一覧シートの雛形ファイルの桁に
　　　アプリソース
　　　アプリヘッダ
　　　バージョン
　　　各画面ヘッダ
　　　各画面ソース
　を書き出していましたが、この「各画面ヘッダ」と「各画面ソース」を

　各画面のシートの部品部分（５行目以下）に、記入がなければ、
　　　従来の「各画面ヘッダ」と「各画面ソース」を出力（変更なし）

　各画面のシートの部品部分（５行目以下）に、記入があったら、
　　　今回作成した「各画面（部品追加）ヘッダ」と「各画面（部品追加）ソース」を出力

　するようにすればいいです。

---

で、具体的な修正内容は、またこんど

銀行のATMから情報を盗めるソフトを、ウクライナでは売っているらしい！？

ここの記事
mp3プレーヤーを使ってATMから情報を盗み出したギャング団
http://gigazine.net/index.php?/news/comments/20061117_atm_mp3/


によると、（以下斜体は上記サイトより引用）

ATMの電話回線のソケットを分岐させ、流れているトーン信号（ファックスが出しているような音だそうです）をmp3プレーヤーに記録させるというもの。そして記録した音声をウクライナで購入した非合法ソフトウェアを用いて解析することで、クレジットカードのIDとパスワードを割り出し、カードのクローンに成功したとのこと。


すげー、手口もすげーけど、そんなソフトが売ってるのもすごい
っていうか、ＡＴＭに流れる信号って、（ＳＳＬみたいに）暗号化されてないの？
この犯罪があった国だけの話なのかなあ。。？？

JAVAでＡＰＩが変わったことを示し、コンパイルで落ちないためのDeprecatedとその限界

　昨日書いた、構成管理とテスト・バグ修正段階における依存性の問題と解決法について、依存性の問題を書いた。

　それは、

・誰かがメソッドを変更してしまわざるを得ない状況（仕様変更、バグ修正などで）で、
・関係者全員が修正したと思ったら
・通知忘れがあって、修正してない人がいる＝＞コンパイルエラー

って言うような話。
（ここで、スタブを作り忘れたとか、そーいうのはさすがに。。。　＾＾；）

　で、このような話は、Ｊａｖａの１．５の場合、アノテーションがはいって、そこで、Deprecatedがはいったので、この問題は、解決された。って、主張するかもしれない。

　でも、そーは、いかないかもお（；＿；）。

　ということをちょっと、書いてみます。

---

■意識あわせ：アノテーションにDeprecatedを入れるとは

　依存性の問題が起きるときには３つあって

１．いままであったメソッド、クラスが変更された（引数も、その型も含む）
２．あらたなメソッド、クラスが追加された
３．いままであったメソッド、クラスが削除された
　　　（publicがprivateで見えなくなるのも含む）

　ま、編集はふつう、追加（挿入含む）、変更、削除の３種類なんで、プログラムの編集における依存性の問題も、この３種類といえる。

　で、追加される場合は、新規に作ればいいだけだからいいんだけど、１のように変更されたり、２のように削除された場合、連絡忘れがあると、その人は、前のＡＰＩで呼び出すので、前のＡＰＩがなくなると、コンパイルできなくなる。

　このため、変更削除する場合は、すぐにしないで、Deprecatedアノテーションをいれて、前のメソッドを残しておけば、コンパイルのときに、教えてくれるという話。
（警告がでるだけで、コンパイルは終了する）

くわしくは、ここ
Deprecatedアノテーション
http://www-06.ibm.com/jp/developerworks/java/041001/j_j-annotate1.html#IDADUOXB

Deprecatedという言葉は、Javadocで、コメントに@deprecatedと書くのでおなじみかも。。
これも、おなじいみ、つまりこのＡＰＩは使うな！という意味です。このコメントをJavaDocで処理するコメント内で書くと「推奨されていません」とJavadocにかかれるというもの
詳しくは、ここ

---

■これでできること、困ること

　まず、これをやったほうがいいかどうかといえば、やったほうがいい。

　ただし、アノテーションは、バージョンによってはない(1.5から入ったと思う）。
　Javadocに入れるのは、開発時には、効果があるが、仕様変更で、使わなくなった場合、連絡ミスで、連絡が行っていない人が、Ｊａｖａｄｏｃをみて気づくことは、まずない
（前の例で言うと、Ａ、Ｂ、Ｄさんが変更に対応する必要があるのに、ＡＢさんしか連絡が行っていない場合、ＡさんとＢさんは、関連したＪａｖａｄｏｃを見る可能性はあるが、Ｄさんは、変更があること自体を知らないので、その部分のＪａｖａｄｏｃは、何も変わってないと思って診ない可能性は高い）

　また、アノテーションにいれても、再度コンパイルしないと、ワーニング表示されない。
　ということは、Ｄさんが、この部分はできていると思って、再度コンパイルしない場合（というのはＩＴ２で問題が起きたときにはよくある。で、ＩＴ２で仕様変更したり、ＡＰＩを変えるバグが出ることは、最近は良くある）、気づかない。

　なので、構成管理で全部を再コンパイル(javac）したときだけしか、これに気づかないことがあり得る。そーすると、構成管理の人は、これをチェックして、バグ票にあげる？（あげないと、言っただけでは、問題が起きてるように見えないので、あとまわし、ほかのバグを先に直される可能性が多い）
　うーん、１個や２個ならもちろんＯＫだけど、こんなのが１００個や２００個もでちゃったら（＞＿＜！）構成管理の人が書くの？
（エラーメッセージのＡＰＩ修正のように、直すのは一部、１箇所なんだけど、多くの人に関係がありすぎて。。。ということはあり得る）

　でも、この方法を逆につかって、Deprecatedアノテーションをいれて、コンパイルエラーをみて、どこまで影響があるか？ってみる方法はアリだと思う。

---

■これを防ぐには。。。

　これを防ぐには、テストのときに、実行したら気づくようにすればいいんだけど、
　じゃあ、そーするために、

　古いインターフェースにはいったら、画面表示する？
　　っていっても、画面表示できないところもアル

　ログに書く？
　　っていっても、ＩＴ２ぐらいになると、すごいログがでるので、すべてのログは見ない
　　（というか、見れない）
　　　
　RuntimeExceptionを発行して、おとすか。。
　　って言っても、それは最上位でcatchしてて「システムエラーです」って出るだけかも？

　っていうことになる。ただ、RuntimeExceptionで落とすっていうのは、「システムエラーです」しか出してなくても、ログで何か書き出せばいいっていうことはある（その場合、ログに最後に書かれた部分だけをみればいい）。

　なんで、これが有力かなあ。。

---

　この問題と、追加の問題をあわせて考えたものが、この前書いた、窓口を絞るという方法と、引数をエンベロープに入れるって言うことになるんだけど、今度はこの場合、バグが見つからないというリスクを抱える。そのため、リグレッションテスト（回帰テスト）が重要になるってことなんだけど。。。まあ、その話は、そもそも、窓口を絞るって、どうやるのか？っていう話からになって、長い話になるので、今回はここまで。