ページ

2008年9月30日

会社の中の鉢3

会社の中の鉢2

会社の中の鉢 1

ケータイ小説を読む

世間では「あたし彼女」というケータイ小説が流行っているらしいです。いろんなところでほめられたりけなされていたりします。けなしている人も,全部読んだ訳ではなさそうです。こういうものは全部読んでからじゃないと語るべきではないと思っているので,全部読みました。会社のTさん(女性)もまだ,半分ぐらいしか読んでいないそうです。anakaさんに至っては5ページぐらいらしいです。勝った。

読んでみて,これはこれでありなんじゃないかな?ただ,小説と言われると違和感があるけど,新しいジャンルとしてならいいかも。まあ,これを全部読んだので多分,もうケータイ小説と言うものを読まないとは思いますが。ちなみに,そこそこ面白かったです。昔,「サラダ記念日」と言う本があって,そのときも,いいと言う人と悪いと言う人がいましたが,まあ,似たような感じかな?昔の僕であれば,悪いと言っていると思いますが,今はあまり否定しません。凄くほめている人もいますが,それはどうかな?

で,性的な話が多いとか言う人もいますが,どうなんでしょう?学生のころ好きだったホイットマンの方が凄いぞ。じゃなくって,それにくれべたら,まあ,かわいいものでしょう。

まあ,好きになれない人は好きになれないだろうな・・・。

2008年9月29日

Dual Core Atomのべアボーン

サーバが壊れてからいまだ傷心中ですが,Dual Core Atomがでて,べアボーンもでました(ASCII.jp)。べアボーンじゃなく,製品でも気にしないのですが・・・。適当に見積もるとすべて合わせて3万5千円からから4万円ぐらいで作れるようです。

必要な機能の一つが,ファイルのバックアップ用のサーバ(TimeMachineのような世代管理は必要ない)なので,そこそこの容量のディスクが必要です。バックアップと言ってもデジカメの写真とiTunesの音楽たちぐらいなんですが。
それ以外のデータはAppleのMobile Meの中にいます。いいのか?

それから,Webサーバです。とりあえず,static fileがフィードできればいいですが,tracと過去のblogは復活したいです。データはほとんどがPostgreSQL(tracのデータもね)に入っているのですが,Atomってどれくらい速いのでしょう?前のサーバが超低電圧版PentiumM 900Mぐらいだったので,スペックアップになる?

それからAtom 330って64bit?まあ32bitでも気にしませんが。

と言うことで欲しいのですが,うーん,もう少し安くなんないかな?

2008年9月25日

Concurrency Utilitiesは面白い

はじめに言っておくと,僕はJavaが嫌いです。でも,仕事ではJavaを使って開発しています。
そんなJavaですが,ServletでWebアプリケーションを作っていると,至る所にマルチスレッドの罠が待っています。そもそも,Servletがマルチスレッドで動くと言うことを分っていない人が多いですが,その次に,どう変数を守るか,ということが大事になってきます。もっともグローバルな変数を使うなということはもっともですが,それだとパフォーマンスがでなかったり,不便すぎたりと,問題があります。

会社のまっちゃんが「Concurrency Utilityのすすめ」「パート2」と言うドキュメントを見つけてきました。なかなか面白いです。Java固有のお話もありますが,マルチスレッドの問題点は言語を問わず共通の問題を抱えています。それに対しておもしろいアプローチです。まあ,単に僕がjava.util.concurrentパッケージを知らなかっただけですが。まあ,ロックをいかに局所化してブロックしないようにするか,と言う話です。

まとめると,「スレッドは体によくない」と言うことです。

2008年9月24日

煙がでないさんまの塩焼き

秋と言えばさんまです。秋のさんまはおいしいです。今日はお昼にさんまの塩焼きを食べようとしましたが,残念なことに売り切れでした。悲しいです。家でさんまの塩焼きを作ろうとするとすごく煙がでて作れないと思っているそこの奥さん,フライパンで簡単に作れます。

  1. さんまを買ってくる(目が充血していない人がいいですよ)
  2. 洗ったさんまを拭いて水気をとる
  3. 塩を表と裏に適量かけてあげる
  4. さんまを真ん中ぐらいに頭としっぽにわけてまっぷたつにきる(フライパンにはそのままでは入らない)
  5. フライパンに油を引いて,ついでにニンニクもいれてあげる。(最近ニンニクを入れ忘れることが多いですが,大丈夫です)
  6. 中火で中に火が通るまで頑張ります。そのあと,反対側を焼きます。
  7. 中まで火が通ったら出来上がり。
ちなみに,急いでいるときは,強火で表面がいい色になるまで焼いて,レンジでチン!

2008年9月22日

おれおれきんぴらごぼうの作り方

なぜか、突然、料理講座です。とりあえず、僕は料理が作れると言うことの証明です。第一回目はきんぴらごぼうです。

  1. ごぼうを5cmぐらいの長さで細長く切って、水に浸す。気が向いたら水を取り替えてあげる。水に浸すことを「あくをぬく」ことだと信じて疑わない。
  2. 人参をごぼうと同じようにきる。
  3. あくがぬけた気分になったら、ごぼうの水をきる
  4. フライパンに油をひいて、塩を少々入れる。一度別の料理で塩を入れ忘れたことがあるので、塩だけは最初に入れるようにしています。
  5. フライパンを暖める
  6. 暖まったと思ったら、ごぼうと人参をいれて、七味唐辛子を入れる。うちは子供がいるので、最近はいれてないです。
  7. 強火で適当にいためてあげる。火のそばにいるとあつくなるので、僕は一分か二分ぐらいでしびれを切らしてこの作業はおわりにします。
  8. 醤油を適当に、みりんと酒を少々入れます。
  9. 水気がなくなるまでいためればできあがり。気分によってはごまをいれてもいい。最後にごま油で香りづけしてもよい。
あとは、食べるだけです。適当すぎるレシピです。そんなものです。

2008年9月17日

iPhoneのアンテナの数

iPhoneを買った直後は,家の中でアンテナは1本か2本しか立っていませんでした。電話はできるのでアンテナの数は重要ではありません。その後のファームウェアのアップデートなどで圏外になって,家ではiPhoneを電話として使用できなくなりました。iPhoneが悪いのかSoftBankが悪いのかは分りません。3Gの携帯を買った直後も圏外だったので,我慢できます。と言うか、ほとんど電話しないんですが。

そして,iPhone2.1。今まで圏外だったiPhoneのアンテナがすべて立っています。圏外から一気にアンテナ前回だと,うさんくささを感じてしまいます。でも,圏外だと電話できませんでしたが,今は電話機としても使えます。マジックです。

2008年9月16日

密かにNetBookとか言うものを検討しているのだけれども・・・

密かにNetBookと言うものを検討しています。検討しているだけで,買うかはまだ分りません。何に使うのかあまり決まっていません。

検討している製品と言うかメーカはDellとAcerとAsusです。まあ,有名どころです。もうすぐDual CoreのAtomがでるらしいので,それが乗っている製品がでるまで我慢するかもしれません。

さて,基本性能はどれも大して変わらないと思うので,とりあえずは気にしません。で,everseさんがDellのキーボードは変なところにキーがはみ出していると言っています。そんな馬鹿なことしないだろうと思って調べてみると,これ。はみ出している・・・。キーピッチはある程度までならなれますが,キー配列が標準じゃないキーボードは,ブラインドタッチできなくて,そのうち使わなくなるので,却下です。

Acerはタッチパネルの横のボタンがいけてないけど,許容範囲内。EeePCは調べてみないと・・・。

NetBookは欲しいような,いらないような・・・。MacBook Airを買えばいいような気もする今日この頃。結局MacBookが重すぎると言うことで・・・。

2008年9月13日

iPhone 2.1

iPhone 2.1になりました。アップデートされました。時間帯が「日本」から「クパチーノ」に変わっていました。僕は巡礼に行くつもりはないので、日本のままでいいです。

それ以外は・・・。よくわかりません。撮った写真の位置情報は常に北緯の西経になるというやつはなおっているんでしょうか?

2008年9月12日

Python Code Reading 04

Python Code Reading 04に行きました。僕が参加したのは今回が2回目です。お題はstringモジュールのTemplateでした。感想は、うーん、やっぱり使わないや。

メタクラスを使っていて面白くはあるんですが、なんとなく、メタクラスを使ってみたいから使ってみました。的な感じがします。多分、僕がTemplateクラスを拡張して何かをしてみたいとは思わないからかもしれません。

それから、知らない人(多分)が一杯きていました。

2008年9月10日

型なんて飾りです

僕は牛乳が嫌いです。だからCappuccinoは飲めません。でも,会社の若き魔法使いさんは僕の横でCappuccinoを飲むと言う暴挙にでました。

CappuccinoはObjective-JをコンパイルしてHTMLとJavaScriptを吐き出すものだと思っていたら,コンパイルと言うか,そのような変換はしないようです。基本的にはJavaScriptで[]の中と@のブロック(?)の中で,Objective-J固有の特殊な処理が実行されるようです。

若き魔法使いさんは次のコードを試してみました。


@implementation X : CPObject {
    CPString value;
}
- (void)setValue: (CPString) v {
    value = v;
}
- (CPString)getValue {
    return value;
}
@end

function main() {
    var x = [[X alloc] init];
    [x setValue:"a"];
    [x setValue:1];
    alert([x getValue]);
}



文字列のフィールドに数値を入れてみたそうです。普通に動くそうです。Objective-Jでは型なんて飾りです。まあ,Objective-Cも似たり寄ったりですが。

お預けになったMacBook

モデルチェンジするとささやかれていたMacBookですが,9/9に新しいやつがでればいいなー,と期待していました。まあ,MacBookでもAirでもどっちでもいいのですが。でも,新しいiPod nanoでした。いろいろ変わったところがあるのかもしれませんが,「デブnanoは流行らなかったのでもとに戻ったんだ」と。Touchはスピーカがついていてちょっとうらやましいです。うちのTouchにもスピーカがついていれば子供のけんかが少し減るのに・・・。

さて,そろそろと言うか,年末ぐらいまでに新しいノートPCが欲しいとおもっていたのに,MacBookはでませんでした。まあ,すぐに必要と言う訳ではなく,年末までにでればいいので,気長に待つだけです。でなければ,Airか,NetBookを買っちゃうかもしれません。

その前におうちのサーバを買いたいけど,Dual CoreのAtomがもうすぐです。

2008年9月9日

SproutCoreに興味があるんだけど・・・

僕は牛乳が嫌いなので,Cappuccinoは飲みたくありません。で,Dojoもいいんですが,SproutCoreも面白そうです。多分,MobileMeのUIを悪くないと思っているせいかもしれません。

SproutCoreとCappuccinoはよく似ています。CappuccinoはObjectiveJというObjectiveCの親戚を作ってHTMLとJavaScriptを生成する変態的な仕組みです。SproutCoreはちゃんとHTMLとJavaScriptで書きます。
でも,ドキュメントを読んでもよくわかりません。Railsっぽいからでしょうか?会社の隣にすわっている19才魔法使いの藤田さん(まっちゃんと同じように凄いエンジニア)もSqroutCoreがいいと言っていたので,きっといいものなのでしょう。

CappuccinoとSproutCoreの二者択一であれば牛乳を使っていないSproutCoreのほうがいいのかな?

2008年9月8日

Cappuccinoは面白そう

Cappuccinoと言うものがリリースされたらしいです。Objective-CのようなObjective-Jという言語でプログラミングすると280slidesのようなカッコいいプレゼンソフトが作れるらしいです。Objective-Cっていうのは言わずと知れたMacのプログラミング言語で,CocoaプログラマをWebアプリケーションプログラマに仕立て上げる変態的フレームワークです。ObjectiveCがかければ,Macだろうと,iPhoneだろうと,Webアプリケーションだろうと,ほとんど教育なしで何でも作れると言うことです。

でも,僕は使わないでしょう。

2008年9月5日

Google Chromeが凄いらしい件

最近はプロセス間通信のおもしろいことが多いと,勝手に想像しています。
さて,Google Chromeが至る所で話題になっています。テクニカル以外のことはそのうち「あすなろ」に書くとおもいます。Google Chromeが面白いと言うことですが,Google ChromeのDesign Noteがとても面白いです。WebKit(Safariのレンダリングエンジン)とV8のJavaScript engineの組み合わせの話ではなく,プロセス管理の話です。

電車に揺られながら読んだので,すっ飛ばしているところがあるかもしれません。
基本的にタブ一つにつき一つのプロセスで動きます。Chromeを起動した直後は,全体をマネージメントするプロセスと,最初のタブのプロセスの二つが起動します。タブが増えるに従って,プロセスが増えます。どれか一つのタブ(プロセス)が変なことをしても,他のタブが影響を受けることは少ないです。Webアプリを必須のアプリにするためには必要な機能なのでしょう。だって,Wordが落ちたら,一緒にExcelまで落ちたりとかしたら悲しいよね。
さて,今まではWindows一つにつき,一つのプロセスと言う常識でした。アプリケーションのバッググラウンドで複数のプロセスが動くことはありましたが,UIを担うものは一つのプロセスです。でも,Chromeはタブごとにプロセスを割り当てると言うへんな発想です。凄いです。また,タブだけじゃなくって,サイトごとにプロセスを切り替えると言うこともやっているようで,メモリーリークの影響が最小限に抑えられているようです。

で,プロセスを沢山動かすと,プロセスの起動のオーバーヘッドや,プロセス間通信のオーバヘッドでスレッドよりも遅くなるとおもっていましたが,Chromeを使った感触では,速いです。プロセス間通信については,Python2.6のmultiprocessingなど,最近気になることが多いです。

僕は数個のタブを開いただけですが,社内で30個ぐらいタブを開いて実験した人がいます。開いたのは普通のサイトだそうです。プロセスの数を数えると9つぐらいしかいなかったそうです。単純に1タブ1プロセスじゃなく,JavaScriptを使っているかなどで,いくつかの判定基準でプロセスの起動を制御しようとしているのかもしれません。

プロセス間通信の仕組みは,あんまりよくわかりませんでした。なんか大事なことが抜けているような気がする。

2008年9月3日

Google ChromeのJavaScript V8が凄いらしい件

グーグル「Chrome」、JavaScriptベンチマークで競合ブラウザを圧倒」と言う驚きの結果です。グラフを見ると,V8のパフォーマンスが桁が違います。きっと,名前が速そうだからでしょう。このベンチマークはGoogleが提供しているものなので,話半分にきいても凄いですが,JavaでJITが導入されたときや,IBMのJITがCのコードより速くなると言うときのベンチマークを思い出せます。

Design Elementsを読むと面白いところとやっぱりと言うところがあります。基本的に3つのポイントがあって,
  • プロパティへのアクセスを高速化した
  • コンパイルしちゃえ!JITみたいなもん。
  • おれらのがベージコレクションは凄いんだぜ,どうだ!
ということらしいです。最初のプロパティへのアクセスは,プロパティが追加されるたびにクラスをつくってアクセスするらしいです。なかなか富豪的です。同じクラスを何度もインスタンス化すると高速ですが,一度しかやらないと,かえって遅いはず。あとは,各クラスのプロパティへはオフセット(配列)でアクセスするので,辞書やハッシュよりは速いと言うことらしい。

コンパイルしちゃえ!がベンチマークのあの性能差に繋がっていると思います。Safariは知りませんが,Firefoxとかもコンパイルしちゃえ戦略をとろうとしていたような気がするので,暫くすれば,ここまでの性能差はなくなるかもしれません。

ガベージコレクションはまあ,そんなものです。ガベージコレクションを行なっているときはプログラムがブロックするので,タイミングによってはブラウザが反応しなくなるとかもあるんでしょうか?

V8恐るべし。

2008年9月2日

スレッドとプロセスと

大昔のLinuxはスレッドはプロセスでした。プロセスの生成コストなどの問題があって本物のスレッドになりました。さて,Pythonのスレッドは,ジャイアントロックで,インタープリタ一つに対して本当に同時に実行されるスレッドは一つだけです。yieldを使って擬似的によりマルチスレッドにすることはできましたが,そんな酔狂なことを好んでやるのはTwisted関係者ぐらいでしょう。

Python2.6でmultiprocessingという機能が入ります。これ,面白そうだと書いたのは昨日です。で,本当に面白そうなんです。まあ,カーネルのスケジューラとか好きだったので・・・。で,Pythonとスレッドに関しては,もっとpreemptiveな実装にしようと言う動きがありますが,こちらは,標準ライブラリだけじゃなくって,膨大ないろんなライブラリを書き換えないといけないので,現実的じゃありません。まあ,ほとんどのライブラリがマルチスレッドで動きが怪しかったり,import自体大丈夫なのかとか・・・。
で,2.6のmultiprocessingです。これって,結局,threadでやるとメモリを共有しちゃうから問題だよね,それじゃ,プロセスでやれば?と言うことです。と言うことで,この点だけ見れば,スレッドからプロセスへと,Linuxなどの流れに逆行しちゃっています。
今までのグローバルなロックがいけなかったかと言うと,よほど特殊なCPUじゃない限り問題なかったのです。以前は,なんだかんだ言って,同時に走るスレッドはシステム全体で一個でした。でも,マルチコアになっちゃって,複数のスレッドが本当に同時に走るので,ちゃんとスレッド対応すれば性能が2倍とか数倍になります。で,これをもっとも低コストでやるのが,子プロセスでやることだったのでしょう。

でも,これだけだとそんなに面白くも何ともないです。これがそのうち,一つのPC内じゃなくってネットワーク経由で別のPCのプロセスとイチャイチャすれば,そのうちMapReduceになる?という妄想がわいてくるのです。


2008年9月1日

言語のバージョンアップ

Pythonに限らず、基本的にJavaでもなんでもそうなんですが、僕は言語自体のバージョンアップはあまり興味がありません。もっともそうな理由はいろいろあります。ターゲットとしているOSのデフォルトのパッケージかどうかや、ある程度枯れているかや、誰かと開発する場合はその人がその機能をちゃんと知っているかとか、です。でも、多分、一番大きいのはめんどくさいからです。

さて、最近のJavaのバージョンアップは、割とこじんまりしていて面白くありません。まあ、昔から面白くなかったのですが・・・。それに、その機能、他の言語だと既にあるよとか、あります。Pythonはデコレータとか面白そうなんだけど、自分でデコレータなんて作れないよ!とか、知らずに新しい機能使っちゃったせいで、ちょっと古いシステムじゃそのまま動かない(これ、Javaに多い)とか。で、現実的な程度に古いシステムにあわせるんですが、Python2.6の新機能を眺めていると面白いです。しまった。ポリシーに反して眺めてしまった。multiprocessingのパッケージってわくわく(こういうの、好きなんです!)するけど言語標準にすべきなのか?とか、withって何気に便利だけど、うかつに使っちゃいそうとか。