2004-03-06
_ BIOSアップデート
Athlon2600+(FSB266)結局購入！
なかなか売ってなかったんですがドリームステーションというお店でありました。
送料とか全部いれて￥13500くらい。
たまたま札幌のお店で、「送料北海道は半額！」とあってラッキーでした。(^^)
届く前にまずBIOSアップデート。
ついでに設定をしなおしたら、どうやら今までFSB200MHzで動いてた様子。
がーん！！
266MHzに直してpov-ray走らせてみると確かに速くなっとる！
たぶんファン交換した後高負荷時に落ちるようになったときに
「安定設定ロード」ってBIOS設定した時からだろうなぁ。。。
気がつかないもんなのね。。。
そんなわけでG5よりも良いスコアを出してしまったAthlon1800+でした。
ってことは1500Dualもあやしいなぁ。1つしかCPU使ってないのかも。。。
_ いがデスクトップ機の履歴
そんなわけで2年前に組み立てたAthron1800マシンが
「まだまだいけるわい」
と存在感を示した週末の１日、今までのマシンの変遷を思い返しました。
■1998.Endeaver Pen2-333 memory64MB?
大学編入学時（3年）に初めて自分で買ったマシン。
確かディスプレイ付きで20万円以上。高かったなぁ。。。
win95、98の時代。
最速CPUはぺん2-450MHzだったかな？
ビートマニアが流行ったときでBM98でよく遊びました。
あとはエミュゲーム。
このころは将来情報技術者になるなんて思いもしなかったなぁ。
昔からコンピュータは好きでしたが。
■2001.Duron800MHz Memory128MB(PC100)
M1のとき。初の自作機。
このころはメモリがすごい勢いで値下がりして、結局128MBで500円まで落ちた気がします。
最速CPUはAthlon1.4GHzとか。ぺん4よりもAthlonが速い時期ですね。
このマシンもマザーが8000円、CPUが5000円、メモリ1500円、ケース3000円という超廉価機。
研究室で日常使用機として活躍しました。
実験解析でNGraphをよく使いました。
OSはwin2000、そういえばデュアルブートでRedHat7を入れたのを覚えてます。
LINUXに初めて触ったのはこのときかな。
卒業頃にwinXPが出て、修論発表が終わったあとにインストールしました。
現実逃避し放題で楽しかった。（笑）
同時期に自宅にあったEndeaverが壊れ、何も画面に表示されなくなりました。
Duron700+Memory128MBという似た構成でマザーごと交換しました。
私生活としては大学で液体ヘリウムコンテナを運ぶ日々で観光客に写真を撮られてました。
きっと中身牛乳だと思われてる。
■2002.Athlon1800+ Memory512MB(DDR PC2100)
就職してすぐに組み立てました。
今のwinメイン機です。
２年間経ったけどあんまり古く感じないです。PC進化がゆるやかになったんですね。
最速CPUはぺん4-2.4GHzかな。
音声デジタル出力がついたのが私には大きな進化で、
5.1chアンプにつないで映画の予告編を楽しんだりしました。
■その後の彼ら
Endeaverは途中で壊れて、中身がDuron700に変わりました。
しかし今でもLinuxマシンとして大活躍してます。
Duron800機は去年弟にあげました。きっと現役でしょう。
Athron1800+機は2004年3月Athlon2600+へCPU換装予定。
CPU換装ってのがPC進化の緩やかさを物語ります。
CPU以外で特にネックになっている所がないからです。
メモリはDualチャネルPC2100なので4.2GB/sec、Athlonには十分な帯域。
HDDもATA100/133なので特に問題無し。
HDDが速くても60MB/secくらいでしょうからRAIDにしない限りネックにならないでしょう。
アクセススピードはこの2年で進化しましたね。
(途中で容量足りないので増設。やっぱり新しい方が速い。)
GBEtherが普及するとPCIじゃつらいですね。
でもPCI-Express載ってるWin機ってまだないのかな？
最近のマザーはLANだけ別口にして対応してますね。
そんなわけでLonghorn登場までがんばれるか、ちょっと楽しみです。
2006-03-06
_ [music] ドリカム
昨晩、TVでドリカムライブの裏側というような番組が。
上原ひろみというJAZZピアニストと共演。
10代でチックコリアと共演しているのはすごいなー。
リハーサルの演奏がすごかった。
JAZZとPOPの融合って好みです。
吉田美和のパワフル差も生きるし、洒落ている。
もっと曲流せ！！と思うことしきりでした。
ぜひライブCDを出して欲しいなぁ。
それにしてもドリカムのカリスマ性ってすごいですね。
見ているだけで元気になります。
ニューアルバムも買わねば。
2010-03-06
_ [ruby] Coffee.rb 開催とt-wada先生のrspec入門
前から「入念に準備する大規模な高専カンファレンスもいいけど、
もっと気軽に勉強会したいよね。」と思ってたし、
高専カンファレンスの発表でも話していたので実践してやってみました。
珈琲でも飲みながらのんびりと準備もなしで手軽に、
ということで Coffee.rb と名前を付けてまず第1回を開催してみることに。
ネタは @mitaku さんが東京Ruby会議03でやりたいと言っていた
t-wada先生の「RSpec の入門とその一歩先へ」の写経をしてみることに。
場所は@kei_sさんにお願いしてサイジニアさんをお借りしました。
同僚の @_h_s_ さんをRuby道にそそのかすために誘ったら釣れたので4人でスタート。
基本ルールはこんな感じ。
・独り言推奨（そこからツッコミに発展とか、発見とかあるので）
・なんかあればIRCとかtwitterでURLとか共有
twitterでrspec記事を写経してるよと書いたら、
t-wada先生からこんな発言が。
( ゜д゜) (つд⊂)ゴシゴシ (;゜ Д゜)
ってことでレッドとグリーンを司る大召還獣t-wada先生の招聘に期せず成功。
さらに@lchin さんも釣れちゃって、あわわわ な会場。
6人に増員されて第1イテレーションを写経していると、
t_wada:「第2イテレーションできたよ」
βテスター参加祭りキター。
そのほかにもRubyでのデフォルトinitialize メソッドへ引数渡す時の挙動が
1.9.2最新と古いのだと違うね、という話になって
コミッターのみなさんのtwitterで話が始まり、
頭の上を矢がびゅんびゅん飛び交うのを塹壕から眺めたり。
すごく勉強になりました。
先生がいない状態でもみんなで話しながらやると知らないことをいろいろ発見できるのに、
先生に直接すぐに聞ける贅沢。
全員で会話できる6人って人数はちょうどよかったかも。
ってことでついうっかり勉強会開催すると
すごい召還獣を呼べちゃったりすることもあるので、
みなさんうっかり気軽に開催しちゃうといいと思います。
Coffee.rb はこれからもゆるさを売りに続けていきたいです。
入りたいという奇特な方はこちらからどぞー。
2014-03-06
_ omniauth-identity
OmniAuth、twitter認証やfacebook認証が簡単に作れて便利ですね。omniauth-identity gem を使うと自前のパスワード認証も簡単につくれます。AsciiCast に解説もあっていたれりつくせり。
メールとパスワードの入力Webページは omniauth-identity が自動でつくってくれて便利ですが、APIからユーザーを作りたい場合にコントローラでどうすればいいのか調べたのでメモ。難しいことは何もなく、Identityモデルでpassword に代入する際にpassword_digestを計算して入れてるだけだった。
なので、
i = Identity.new(name: "igaiga", email:"igaiga@example.com", password: "igaigapass")
これでpassword_digest が代入されてる。あとは i.save! すればOK。
実際にやってるのは omniauth-identity gemの以下。
OmniAuth::Identity::SecurePassword::InstanceMethodsOnActivation#password=
def password=(unencrypted_password)
@password = unencrypted_password
if unencrypted_password && !unencrypted_password.empty?
self.password_digest = BCrypt::Password.create(unencrypted_password)
end
end
ところで、saltはないんですね。最近の認証システムにはsaltないなー、と思って調べてみた。
ここに詳しく書いてある。簡単に言うとこんな感じ。
- BCrypt::Password.create(unencrypted_password) をつかっている。
- これはsaltを保存しなくてよい仕組み。（中で自動生成）
- そもそもsalt は何のためにあるかと言うと、攻撃者が総当たりで攻撃したときに時間がかかるようにするため。
- 暗号化された文字列が流出したときの話
- paswordとsaltを1つずつずらして暗号化して・・・を繰り返させる
- そこで、攻撃者が計算するときに(saltがあったときよりも)十分に遅ければ、別途saltを保存しなくても良いはず
- 普通のhash(MD5とか)は遅くは設計されてない。速く計算されてしまう。
- bcrypt は暗号化計算が十分に遅い。秒間450個のパスワードしか生成できない。(MD5だと約140,000個)
なるほど。どれどれ。
require 'bcrypt'
start = Time.new
100.times { |i| BCrypt::Password.create(i) }
finish = Time.now
p "#{finish - start} sec"
実行させたら100個暗号化するのに 6.247545 sec だった。確かにかなり遅くできてる。
3/7 追記： Omniauth-identity、ascii cast に従ってname, emai, password_digestを作ったけど、表示しなければname要らないか。
_ いじゅみ [MacOS X(10.3？？)には、タイムサーバとの同期があったと記憶しています。 それに慣れてしまってたので、Wi..]
_ いが [私の知ってる範囲では、 osxは10.2ではもうタイムサーバ同期機能がありました。 ＃でも時系列ではWinXPよりも..]