本当は怖い情報科学

「マイページURLの有効期限はメール配信後１週間です」の怪

一応、世間で言う修士1年生でありまして、人のすなるしうかつというものをしてみているわけです。

で、某マ○イナビなどの就活サイトなんかに登録すると、山のようにメールが届きます。それらを9割方、読みもせずにフィルタで受信トレイスキップというのが常道であるわけですが、寒い夜だったのでなんとなく読んでいると･･･

あなた専用のマイページURL：https://job13.xxxxxx.jp/13/pc/auto?a=xxxxxxxxxxxxxxx

↑上記マイページURLの有効期限はメール配信後１週間です。

というのが目に入ります。

( ﾟдﾟ )?

というのが正直な状態であるわけでして、「マイページURLの有効期限が一週間って？」となりました。

いや、まぁだいたい事情はわかります。要するにメールからのサイト訪問率を測定するためにトラッキングIDを設定しているのでしょう。でも、トラッキングURLを一週間で削除する上に、本来ｺｿｰﾘとやればいいトラッキングの事情で「有効期限は一週間です」などと明示的に煽るというのはどういう事情だろうなぁと面白く思ってしまいました。

ちなみに、まず事実の観測として一週間を過ぎたメールのリンクをクリックするとどうなるのかというと、単純にトップページにリダイレクトされます。なおさら、注意書きでわざわざ「有効期限は一週間」などと締め切りを切る必要性が薄れます。

きっとデータ容量を節約したいのだろうなぁと言う事情はわかります。

どれくらい節約したいのかを計算してみました。

まず、マ○イナビの学生会員数がどれくらいなのかと言いますと、これは広告主向けページを見ればすぐに書いてあるわけで、68万人だそうです。そして、データ量に関して計算をすると、16文字のトラッキングIDとメールID、それとプライマリキー用のIDを併せて48バイトですね。おっと、日付も必要なので、DATETIMEで8バイト、つまり56バイトとします。これを会員全員に毎日1通ずつ配信すると考えると、一週間で約254MB、18ヶ月で約19GBとなります。

ちなみに、18ヶ月というのは、10月から就職戦線が始まるとして翌年度の3月までという計算です。

確かに、古いデータを消したくなる気持ちもわかります。たかがトラッキングIDのために19GBというのはさすがに無駄ですね。しかし、かといって一週間の254MBをシコシコ削除する必要があるのか･･･？というのは疑問ですね。そうとうDBに余裕が無い環境なのでしょうか？あるいは、クラウド（）環境で、DBに従量制で課金されるのでしょうか。

いずれにしても、古いトラッキングIDを消して回るcronを書いているマ○イナビの技術者の方の努力に思いを馳せると涙チョチョ切れ、もう少しまともに活用しようかなぁと思う次第です。

Permalink | コメント(0) | トラックバック(0)

海外に持って行ける電源タップって

海外に出張するとき、意外と困るのが電源ソケットの「数」です。電圧については、最近の電子機器（PC、携帯電話、etc.）はほとんど〜240Vの電圧での使用に対応しているので問題ありません。あとはソケットの形を調整するアダプタさえもって行けばいい･･･のですが、そこで使いたくなるのが延長タップ（いわゆるエンチョコ）なんですよね。少なくとも、PC・携帯・現地用のローミング機器の3つは最低限ほしい。まぁアダプタを3つとかもって行けばいいのですが、それも何となくアホらしいし･･･

というわけでタップなのですが、よく見てみると、ほとんどの製品は対応電圧が 〜125V とかなんですよね。恥ずかしながら電気工学的なことはﾊﾟｯﾊﾟﾗﾊﾟｰなので、これを200Vや220Vで使ったときにどうなるのか、ということが想像できません。単純な機器だし大丈夫だろうと思ったり･･･。いや、問題は電流量(?)なので、単純に規格上限ワット数の半分（200Vだから）を超えないように気をつければよい･･･？と思ったりするも確証が持てないんですよね。

じゃあ海外対応のタップを探せばいいじゃないかってわけで探したんですが、

• 海外対応
• 旅行に持って行ける程度に小さい

という2条件を満たすのは

SANWA SUPPLY RW47BK ゴーコンタップ(ブラック)

これくらいしかない･･･のかな？

Permalink | コメント(0) | トラックバック(0)

固有値ソルバの初歩の初歩、ヤコビ法を書いてみた

数値計算

行列の固有値を求めるアルゴリズムとして一番初歩的なのが、ヤコビ法です。実対称行列の固有値を求めるためのアルゴリズムで、実対称行列の固有値は実数であることから実装も簡単です。

理屈としては、

1. 対角行列の固有値は対角成分そのもの
2. 直交行列 を用いて と書けるとき、との固有値は一致する

という2つの定理を使って、適当な直交行列を準備して次々とAを変形していって、最終的に対角行列にできれば固有値が求まる、という寸法です。詳細は数値解析入門 を参考にしました。三角関数を使って直交行列を巧妙に作ることによってAの非対角要素を次々と０に消し去っていくのが鮮やかですね。

なお、が直交行列であるとは、 の転置行列をと書くとき、 が成り立つ行列のことです。

ソースコードはこちらhttps://github.com/keisukefukuda/numerical/tree/master/eigen_jacobi。

実験してみた結果、行列のサイズが大きくなると収束までの繰り返し回数が非常に大きくなってしまうので、巨大な行列に対してはもっと高度なアルゴリズムを使う必要があります。

次はQR法もしくはHouseholder-Givens法を勉強してみます。

Permalink | コメント(0) | トラックバック(0)

【派閥別】Gitのコミットを間違えたときの対処法まとめ

git

追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自　己　責　任

追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。

gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい

ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。

派閥別 gitでコミットミスった時のまとめ
｜　
├─　一人で使ってるよ
｜　　　｜
｜　　　├─　手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派）
｜　　　｜　　　add忘れなら、必要ファイルをaddした後に
｜　　　｜　　　$ git commit --amend 
｜　　　｜　　　それ以外
｜　　　｜　　　$ git reset --soft  HEAD^
｜　　　｜　　　でコミットがなかったことになる．
｜　　　｜　　　追加でコミットしてしまってから git rebase -i でコミット合体という手もあるけど二度手間。
｜　　　｜
｜　　　├─　手元に変更を取り戻したいよ(2)（commit messageのスペルミスったよ派）
｜　　　｜　　　これも同じで，何もaddしていない状態で一切変更せずに
｜　　　｜　　　$ git commit --amend
｜　　　｜　　　とすれば、直ちにコミットメッセージを変更できる．
｜　　　｜　　　　
｜　　　├─　変更捨てたいよ（なんでコミットしたし派）
｜　　　｜　　　git reset --hard HEAD^
｜      ｜
｜　    ├─　いくつか前のコミットだよ（いまさら派）
｜　　　｜　　$ git rebase -i 
｜　　　｜　　を使ってコミットの順番を入れ替えて、矛盾がないことを確認した上で
｜　　　｜　　$ git reset --soft HEAD^
｜　　　｜　　とかがおすすめ。いきなり消しちゃってもいいと思うけど。
｜      ｜
｜      └─　自分しか使ってない上流にpushしたよ（はぐれ刑事Github派）
｜　　　　　　remoteリポジトリを誰も使っていないことが確信できるなら、
｜　　　　　　$ git reset HEAD^ --hard
｜　　　　　　$ git push origin -f
｜　　　　　　でリモートリポジトリを強制的に編集できる。あるいは
｜　　　　　　$ git push -f origin HEAD^:master
｜
└─　複数人で使ってるよ
　　　　｜
　　　　├─　まだpushしてないよ（間一髪派）
　　　　｜　　一人で使っている時と一緒
　　　　｜
　　　　└─　もうpushしちゃったよ
　　　　　　　　　｜
　　　　　　　　　├─　まだ誰もpullしてないよ（こっそり直しちゃえ派）
　　　　　　　　　｜　　他の人がpullしていないことに確信が持てるなら、
　　　　　　　　　｜　　リモートのコミットを直接削除できる。ただし素人にはお勧めできない。
　　　　　　　　　｜　　通常の手段でローカルのコミットを取り消した後、-f オプションでpushする。
　　　　　　　　　｜　　$ git reset HEAD^ --hard
　　　　　　　　　｜　　$ git push origin -f
　　　　　　　　　｜　　あるいは一行で
　　　　　　　　　｜　　$ git push -f origin HEAD^:master
　　　　　　　　　｜
　　　　　　　　　├─　もう誰かpullしちゃってるよ（恥を忍んで直す派）
　　　　　　　　　｜　　リモートを強制的に変更すると、すでにpullした人からは「あったはずのコミットが無い」
　　　　　　　　　｜　　という事態になるので大混乱を招くから、そのようなことはできない。
　　　　　　　　　｜　　よって、履歴は保持した上で"逆の"コミットを適用する。
　　　　　　　　　｜　　$ git revert HEAD^
　　　　　　　　　｜　　$ git push
　　　　　　　　　｜　　これにより、「元に戻した」という内容の新しいコミットが作られるので、
　　　　　　　　　｜　　すでに誰かがpullしてしまっていても矛盾しない。
　　　　　　　　　｜
　　　　　　　　　└─　さらに誰かが（依存する）変更をpushしてるよ（どうしてこうなった派）
　　　　　　　　　　　　涙ふけよ

実はまだコミットしてないよ（君の居場所はここじゃない派）

addでステージングしたファイルをアンステージングするには、

git rm --cached <ファイル名>

で削除できる.

参考URL：

http://d.hatena.ne.jp/mrgoofy33/20100910/1284069468

http://redtower.plala.jp/2010/09/30/git-git-reset.html

http://hylom.net/2011/03/01/how-to-reset-remote-git-branch/

http://d.hatena.ne.jp/tmtms/20101221/git

http://d.hatena.ne.jp/mumoshu/20090408/1239202846

Permalink | コメント(0) | トラックバック(1)