gooの「不正ログイン被害のご報告とパスワード再設定のお願い」

Ｇｏｏの画面を開くと、ちいさく

不正ログイン被害のご報告とパスワード再設定のお願いスタートページに設定

とでている。

これをクリックすると、

不正ログイン被害のご報告とパスワード再設定のお願い
http://help.goo.ne.jp/help/article/2037/

にいく(以下太字は、上記サイトより引用）

ポータルサイトgooにおきまして、
2013年4月2日（火）午前11時30分頃、サーバの異常が検知されたことから詳しい調査を行ったところ、
特定IPアドレスからgooIDに対する機械的な大量アクセス行為(ブルートフォースアタック）があり、
約30,000アカウントに対して不正なログインが行われた可能性があることが判明いたしました。

下記のとおり、詳細についてご報告申し上げます。

【被害規模について】
・約3万アカウントに対し、不正ログインされた可能性があります。
・登録情報ページ（お客様の「氏名」「性別」「郵便番号」「住所」「電話番号」　「eメールアドレス」などが
登録されているページ）へのアクセスは現時点では確認されておりません。
・決済利用について現時点では確認されておりません。
決済用パスワード、口座番号やクレジットカード情報ページヘのアクセスについても確認されておりません。
・gooメール受信箱ヘのアクセスについて現時点では確認されておりません。


で、一部の人に、「ログインロック」がかかっているらしい。

Githubを使って、ソースを公開するのにチャレンジ！ その１：まずは登録してみた

　コンピューター業界において、世界一即戦力になる男(女）を証明するには、
　サイトを作るだけじゃなくって、
　Githubを使って、ソースを公開することですよね！
　イケてるソースを公開すればもちろんのこと、そうでなくても、プログラミング能力は証明できそう

　ということで、Githubを使って、ソースを公開するのにチャレンジ！

　今回は、「まずは登録してみた」

---

■まずは、登録する


https://github.com/

を、Chromeなど、モダンブラウザ（つまり、ＩＥ６，７とかじゃないもの）で開くと

のような画面が出るので、
右側に、ユーザー名、メールアドレス、パスワードを

なかんじで入れて、下の「Sign up for free」をクリックする。

すると、

な画面が出てくる

---

■ＧＩＴのセットアップ

そこで、Set Up Gitをクリックすると、

な画面になる。

いろいろ書いてあるが、まあ、「Download Github for Windows」を
やればいいんだろうということで、これをクリック

Chromeにダウンロードされたら、クリックして実行
すると、こんなダイアログがでる

インストールをクリック

なかんじで、インストールがはじまり、終わった

終わった後、スタートボタンをクリックすると

なかんじでＧｉｔｈｕｂが入っているし、
デスクトップにもGithubのショートカットができている

---

■Ｇｉｔｈｕｂにログイン

で、気づいたら、うしろに、こんなものが

どうやら、ログインするらしいというので、
e-mailアドレスとパスワードを入れてLoginをクリックする


Configureになったので、名前とメールアドレスを入れてみる

リポジトリにきたが・・・

・・・あ～、まだ登録するものが、なにもない・・・（＞＿＜！）

---

ということで、今日はここまで。
登録するものができたら、この先を進める予定

おサイフケータイようやく世界へ

サムスンが乗り出すことで

スマートフォンを使った非接触決済サービスが世界中で離陸する

ことになるそうです。
ただし

沈黙を続けるアップル

・・・

おサイフケータイようやく世界へ
http://business.nikkeibp.co.jp/article/topics/20130328/245804/

（太字は上記サイトより引用）

要求工学とシミュレーションと人工知能

【問題です】
受付会場は２０人の人を待たせることができます。
今、１時間に５０人の人が来て、
受付するのに、一人３分かかります。
受付箇所を、会場にいくつ設置すればよいですか？

---

　このような場面は、まあ、ありえるだろう。
　人を「アクセス」、受付するのをＷｅｂサービスに変えると
　(単位は変更するものとして）ロードバランスの問題にもなるし・・・

　で、この問題を解こうとしたとき、
　待っている時間を求めているわけではない点に注意。
　待っている時間なら、待ち行列問題なのだが、
　ここで問題にしているのは、

　　　「２０人までは待たせられる」

　と、人を問題にしている。

---

　こういうようなとき、ざっくりとした数字が知りたければ、
シミュレーションしてしまうのが早い。こんなかんじ。

・エージェントを５０個用意する
　　（エージェントクラスのインスタンスを作成し、
　　　初期化して、それをエージェント配列に入れる）


public class Agent
{
	int	sts;		//　０：行く前、１：待ち、２：受付中、３：処理後
	int	start_time;	//　受付会場に行く時間
	int	process_time;	//　処理時間

	public Agent()
	{
		sts		=	0;
		start_time	=	0;	
		process_time	=	0;
	}
}
	

・各エージェントに対して各０～６０までの範囲の乱数を発生させ、セット。
　　　start_timeに値をセットする

・１分刻みでループさせ、

　　まず、全エージェントに対して、各々、以下の処理をする
　　　　エージェントのステータス(sts)が「行く前」０で
　　　　　　もし、「受付会場に行く時間」になっていたら
　　　　　　　「受付割り振り」を行い
　　　　　　　　　割り振れたら、ステータス(sts)を「受付中」(2)に
　　　　　　　　　割り振れなければ、ステータス(sts)を(1)に
　　　
　　　　エージェントのステータス(sts)が「待ち」（１）だったら
　　　　　　　「受付割り振り」を行い
　　　　　　　　　割り振れたら、ステータス(sts)を「受付中」(2)に

　　　　エージェントのステータス(sts)が「受付中」（２）だったら
　　　　　　　　処理時間に１を足し、
　　　　　　　　処理時間が、規定の処理時間（今回は３）になったら
　　　　　　　　　　ステータスを「処理後」（３）にする

　　　　エージェントのステータス(sts)が「処理後」（３）、
　　　　及び上記の条件に引っかからない場合は、なにもしない

　　全エージェントの結果を見て、「待ち」の数が、規定値（今回は２０）を
　　超えていたらアウト

上記の一連のシミュレーションを数千回、数万回繰り返し
（ても、時間はそんなにかからない。なお、乱数は、当然変える）
結果をみてみる

そして、「受付割り振り」のときに、受付箇所を１つ、２つ、３つ・・・
と増やしていき、上記のシミュレーションを行い、アウトにならない
受付件数を探す。

---

ということで、要求仕様を固めたり、プロジェクトの進捗予測をするのに、
シミュレーションを利用したほうが早く済むことがある。

・あるアプリの帯域を考えたいとき、
　　このアプリがどれくらい流行るか予測し、
　　それを元にシミュレーションして、帯域を決める

・複雑に絡み合うＤＢのレスポンスを見たいとき

・プロジェクトの工程を予測したいとき、
　　クリティカルパス以外で問題が発生したら、どうなるか

などなど・・・

とくに、今回の待ち行列は簡単だが、
たとえば、「事前受付している人」と「招待券を持っている人」で分けるとか言う場合、
計算でやったら複雑になるが、受付の判定部分をちょっと変えるだけでシミュレーションできる
この手のシミュレーションは、「マルチエージェント シミュレーション」という分野で
人工知能などでは、良く行われるのだが、
ソフトウェア工学、要求工学の世界では、「日本では」あまり行われていない。

今後、行われていくのかな？

---

Ｐ．Ｓ　ちなみに、「受付割り振り」はこう作る

・上記シミュレーションでエージェントを発生させるが、

　そのとき、受付も、必要個数発生させ、リストに入れる



public class Uketuke

{

	int	sts;	//	0：処理前　１：処理が始まった

	int	no;	//	現在処理しているエージェント番号



	public Uketuke()

	{

		sts	=	0;

		no	=	-1;

	}

}





・「受付割り振り」では（引数として割り振りたいエージェント番号をもらう）

　　　　上記で発生させた各受付に対して、

　　　　　　　　もし、stsが０なら、

　　　　　　　　　　noにエージェント番号を入れて割付ＯＫを返す

　　　　　　　　もし、stsが１なら、

　　　　　　　　　　noのエージェントのエージェントを取り出し、

　　　　　　　　　　　そのエージェントのステータスが「受付中」だったら

　　　　　　　　　　　　　割付ＮＧを返す

　　　　　　　　　　　そのエージェントのステータスが「処理後」だったら

　　　　　　　　　　　　　(前のエージェントの処理は終わった＝現在ヒマなので）

　　　　　　　　　　　　　noにエージェント番号を入れて割付ＯＫを返す

　　　　割付ＯＫの受付があったら、割付成功、すべて割り付けＮＧのとき失敗（待ち

　　　　　　　　　　　　　

　　　　　　
また、「事前受付している人」と「招待券を持っている人」は、

・エージェントのクラスに

　　　　int kind;  // 0:事前受付している人、１：招待券を持っている人

　を追加し



・初期化するときに、０～１の乱数を発生させ、

　　たとえば、事前受付する人が４０％の場合、

　　乱数の結果が0.4以下なら、事前受付（kind=0)、それより大なら招待券（kind=1)

　　とする



・「規定の処理時間」の判断を、前のシミュレーションでは一律３だったが、

　　　事前受付の人(kind=0)は、事前受付の時間数

　　　招待券の人(kind=1)は、招待券の時間数

　として処理終了を判別する。

PressmanのSoftware Engineeringを超訳ななめ読み その５－１章のこり

みんなから、無慈悲な稲妻を受けないために、
大事そうなところを、超訳＆ななめ読みしている

PressmanのSoftware Engineeringを超訳ななめ読みする

前回までで、第１～３章をやったことになる（ここまでが、第一部）
ただ、１章は初めの部分だけで、１．１以降については触れていないので、
今日は１章の残り

---

■１．１　ソフトウェアの特徴

「１．１．１　ソフトウェアの定義」
　ソフトウェアは磨り減らないなど、ハードのバスタブ曲線と比べて、ソフトウェアの故障率はどうなるかなどを示しています。

「１．１．２　ソフトウェアの適用ドメイン」

「１．１．３　レガシーソフトウェア」
　レガシーシステムについて

---

■１．２　独特の特徴をもつＷｅｂアプリ
　その特徴について説明

■１．３　ソフトウェア工学
　　ＩＥＥＥの定義

　　ソフトウェア工学の階層

　　　　　　　　　ツール
　　　　　　　　方　法　論
　　　　　　　プ　ロ　セ　ス
　　　　　　品質　に　フォーカス
　　なかんじ

---

■１．４　ソフトウェアプロセス
　以下の５つのプロセスを一般的に考えている
　　　コミュニケーション
　　　プランニング
　　　モデリング
　　　構築
　　　デプロイ

---

■１．５　ソフトウェア工学の実践

１．５．１　実践のエッセンス
　　・問題を理解する
　　・ソリューションを計画する
　　・計画を実行する
　　・結果を評価する

１．５．２　一般的な法則
　　第一法則：存在する理由
　　　　それは、お客様に価値を提供するか
　　第二法則：ＫＩＳＳの法則
　　第三法則：ビジョンを維持する
　　第四法則：あなたが作ったものが、他の人に使われる
　　第五法則：未来にオープン
　　第六法則：再利用にむけて計画する
　　第七法則：考えろ！

---

■１．６　ソフトウェアの都市伝説（神話）
　マネージャー、顧客、実践の都市伝説特集

■１．７　どうやってはじめる。
　１．８　まとめ
　などなど

　これで１章おわり