[ UO ] テイム成功/命令成功率計算ツール for テイマー

テイム成功率・命令成功率と必要スキル値を計算するツールです。この系統のツールもどっかで見たんだけど、それも Java が必要でページ開くのも重かったんだよね。なにより、Windows XP には標準では Java は走らないので、使いたい場合は Java VM を入れなきゃならない。Java アプレットって起動に時間がかかるから嫌いなんだよ。

軽くて Java VM みたいな余計なランタイムを必要としないツールがあったらな、ということで自分で作ってみました。

動物 Cat Dog Gorilla Rabbit Jack rabbit Tropical bard Chicken Raven Magpie Mountain Goat Rat Skittering Hopper Ferret Squirrel Sewer Rat Mongbat Sheep Cow Goat Pig Eagle Timber Wolf Bullfrog Hind Slime Corrosive Slime Horse War Horse Pack Horse Pack Llama Ridable Llama Forest Ostard Desert Osterd Boar Giant Beetle Giant Rat Polar Bear Black Bear Walrus Llama Cougar Brown Bear Deathwatch Beetle Alligator Scorpion Grey Wolf Panther Snow Leopard Great Hart Giant Spider Grizzly Bear Snake White Wolf Gaman Bull Giant Ice Worm Mongbat(Strong) Hellcat(small) Frost Spider Giant Toad Frenzied Ostard Lava Lizard Bake Kitsune Dire Wolf Ridgeback Imp Drake Hell Hound Predator Hellcat Predator Hellcat Leader Dragon Swamp Dragon Fire Beetle Rune Beetle Kirin Nightmare Unicorn White Wyrm Hiryu Lesser Hiryu Cu Sidhe Reptalon Fire Steed		テイムスキル値	ロアスキル値
テイム成功率	命令成功率

使い方

1. テイムがいくつ必要なのか知りたい

テイムしたい動物を選んでから、目標のテイム成功率を入力して実行ボタンをクリックしてください。または、目標の命令成功率とロアの値を入力してから実行ボタンをクリックしてください。

2. ロアがいくつ必要なのか知りたい

まず操作したいペットを選択してください。それからロアと目標の命令成功率を入力して実行ボタンをクリックしてください。

3. テイム成功率を知りたい

テイムしたい動物を選んでから、テイムスキルを入力してください。最後に実行ボタンをクリックします。なお、ロアもセットで入力すると命令成功確立も表示します。

4. 命令成功率を知りたい

命令したい動物を選択してください。テイムとロアのスキル値を入力してから実行ボタンを押してください。

5. 続けて計算する前に

前の値が残っていると正常に動作しません。続けて使用する前にリセットボタンをクリックしてください。

計算について
テイム成功率を Rt, テイムスキルを St, その動物をテイム可能な最低のスキル値を Mt とするとテイム成功率は次の式で表せます。 なお、テイム成功率にはロアは影響しません。

Rt = 0.2{ 10St - ( 10Mt + 249.0 ) } + 50

命令成功率 Rc を求めるのは、ちょっと複雑です。 まず最初にキャラクターのテイムスキル値 St とロアスキル値 Sl からスキルポイント Ps を求めます。 次に、スキルポイントと命令難易度を比較した値 Dc を求めます。

Ps = ( 40St + 10Sl ) / 5
Dc = Ps - 10 Mt

ここ分岐です。Dc < 0 のときは、ベースコントロールポイント Bc を式１で求めます。 0 < Dc のときは、ベースコントロールポイントを式２で求めます。

式１: Bc = 14Dc + 700
式２: Bc = 6Dc + 700

ベースコントロールポイントをチェックして補正します。0 < Bc < 200 のときは Bc = 200 に、Bc > 990 のときは Bc = 990 とします。それ以外のときはそのままです。 補正したものを最終的なコントロールポイントとします。 コントロールポイントを 10 で割ったものがコントロール成功率です。この補正があるため、命令成功率はスキルがどんなに高くても 99% が上限となります。

テイムスキル値を計算する方法は 2 種類あります。一つ目はテイム成功率から逆算する方法。前述の Rt についての式を St について解くと以下の式を得ることができます。

St = { 5( Rt - 50 ) + ( 10Mt + 249 ) } / 10

もう 1 つは、命令成功率とロアから逆算する方法です ( あんまり考えたくなかったけど ) 。 この場合は成功率 20% 以下とそれ以上で計算方法が異なります。20% 以下の場合は式１変形することで、それ以上の場合は式２から逆算します。

式１より
St = { ( Bc - 700 )/ 14 + 10Mt - 2Sl }/ 8

式２より
St = { ( Bc - 700 )/ 6 + 10Mt -2Sl }/ 8

ロアは命令成功率から逆算します。

Bc < 200 のとき式１より
Sl = { ( Bc - 700 )/ 14 + 10Mt - 8St }/ 2
200 <= Bc のとき式２より
Sl = { ( Bc - 700 )/ 6 + 10Mt - 8St }/ 2

更新履歴
2006.09.08
いろいろ機能を強化。いっちばん最初の設計はダメダメだと思って作り直したのが、この拡張前のコード。でも、じつは作り直したほうがダメダメで、いっちばん最初の設計のほうが拡張性に優れていたというオチでした。無理やり拡張したのでインターフェイス関数(だったもの)がすごいことになってます。次に拡張するときはリファクタリングじゃなくて、スクラッチから書き直す必要があるでしょう。

謝辞
データはウルティマオンラインパラリシャンを参考にさせていただきました。サイトを運営しておられる鮎渡様に感謝いたします。ありがとうございました。

わたしが携帯デバイスに求めるもの

わたしが携帯デバイスに求めるものは以前のエントリで書いたとおりだ。高望みしすぎだとか思う人もいるやも知れないが、わたしはそうは思わない。わたしは上手くかけなかったのだが、わたしが書きたかったことを実に上手くまとめている記事を見つけたのでそれから引用したい。

パソコンでやりたいことは、人それぞれで違うし、その時々でも異なる。そのそれぞれ時々に柔軟に対応できるからこそ、汎用機としてのパソコンの意義がある。だから、いつでもどこでも常に携帯し、ぼくらのわがままに応えてくれるパソコンが欲しい。

( 山田祥平のRe:config.sys 冒頭より引用 )

これは何もパソコンに限ったことではなく、携帯電話など多くの「道具」に関してもいえることだと思う。わたしにとっては、ネットに繋がったりメールを送受信できるだけでは意味がないのだ。ネットに繋がるのは前提条件でしかない。これだけでは不十分で、乗り換えようという気は起こらない。わたしは携帯で Web メールを使おうとしたが、できなかったことがある。これでは困るのだ。Web サイトにアクセスしたが、そこで使われている画像が大きすぎて表示できないということもあった。これでも困る。結果としてわたしにとって今使っている携帯電話機は「持ち運びできる情報機器」ではなく、ただ単に「小さくでどこでも電話がかけられる機械」になってしまった。

「必要な情報を必要なときに利用できること」
わたしにとってはこれが「持ち運びできる情報機器」と思える条件なのだ。
そしてそのために必要なのが前にあげた6個の項目だった。

もちろん、Type-U も条件に合致するし買い替えには VAIO Type-U と W-ZERO3 のどちらにしようか迷ってはいる。が今のところは W-ZERO3 の方が優勢だ。スペックや遊びやすさでは Type-U が圧倒的に上。各種 SDK がフルで使えるし、DirectX9 も使えるので事実上アプリケーションを選ばないし、どんな拡張だってできる。しかしそれを隠してしまうほどの欠点がある。そう、価格の高さがそれだ。Type-U の価格は19万。一方で W-ZERO3 は5万あればおつりが来るようだ。ポータブルデバイスで20万はかなりきつい。また、都心部でホットスポットのカバーエリアが多くないことを考えると、エアエッヂなどの通信ユニットが別途必要になると考えられる。幾つものユニットをごちゃごちゃと持ち歩かなきゃいけないんだとするとノート PC もってモバイルアクセスするのと大して変わらないような気もするんだよね。

W-ZERO3 を触ってみて満足できなかったら Type-U を選ぶという流れになると思う。
今はとにかく実際に触って操作してみたい。

[ hardware ] W-ZERO3 が面白そう

わたしは6年前に買った携帯電話を今でも使い続けてる。わたしは Mailing も Browsing も基本的に PC が中心だ。PC なら5秒で入力できることでも携帯電話だと30秒以上かかることだってあるし、携帯でしか見れないメールなんて不便でしょうがない。わたしにとって携帯電話はあくまで通話するための道具 ( それと目覚まし時計＋電話帳メモ ) だったので6年前の機種でも不満は無かったのだ。

まわりからは「よくそんな時代遅れ使っているね」といわれたけど、わたしが自分で使う道具を選ぶときの規準は新しいかどうかじゃない。自分の用途を考えたときそれに適合していて、ついでにあったらうれしい機能がついているかどうかなんだ。今まではその条件に合うものが無かったし、特に不便は感じてなかったから機種交換をしなかっただけ。

しかし、DoCoMo が提供している 2G 世代のサービス “Mova” は2012年以降は使えないという話を聞いた。DoCoMo の広報からも「これまで当社社長の中村が発言してきた通り、2012年までにPDCの新規受付は終了させる方向で検討は進めている。ただし、具体的な時期については何も決定していない」というコメントが出るなど、買い替えを検討したほうがいいかもしれないと思うようになった。そこで、買い替え候補を探してみることにした。

さて、わたしが求める携帯の条件をリストアップしてみた↓

• QWERT キーボードが付いている
• PC との連携が楽
• もちろん PC や peripheral device と接続だってできる
• SMTP といった標準規格に基いた Mailing ができる
• フルブラウザ搭載
• 自分で機能の拡張ができる
• 生活防水仕様も付いてたらいいなぁ

上の6個は必須だけど、無理とも思える条件がいくつも並んでいるじゃないか。「多機能な携帯」ではなく、「通話もできる PDA 」あるいは「どこでも通話もできるパソコン」といった方が適切な気がする。

具体的には、出かけた先で突然情報を調べたくなったとか、突然思いついたことをすぐにメモしたい ( わたしはよく突発的にアイディアを思いつくんだけど、すぐに忘れるんだ ) とか、出かけた先で面白そうな Web サイトの情報をみて後で読むブックマークに入れたいとか、そんな要求に応えてくれるものを探していたんだ。

と、ここまで考えて、以前見たときはさらっと流してしまった B3 Annex さんのエントリと ITMedia の記事を思い出した。

W-ZERO3[es] これならほとんどの条件をクリアしている。特に、他では無理な「自分で機能の拡張ができる」ことに驚いた ( え？なんでこれが重要かって？ わたしがプログラマだからだよ。ほしい機能が無かったり不満があるなら自分で作ればいいのさ。) .NET Compact Framework が入っているらしく、これなら CPython に比べてサイズがより小さい IronPython も使えそうだ。が、ちょびっと記憶領域が少ない気が・・・。さらに調べるとより高機能な W-ZERO3[WS004SH] という機種を見つけた。こちらなら不要なアプリを削除すれば180MB は確保できそうだ。IronPython ( 1.5MB ) にいくつかの Framework を足すこともできるし、MinGW32 を入れることもできそうだ。

NCF ( .net compact framework ) をつかった開発については、Microsoft のサイトにかなりの情報があるから開発の手助けになりそう。気になる .NET Framework 2.0 との違いについては主な違いの一覧が MSDN Japan の中に記載されていた。さらに、デベロッパー製品開発統括部 Blog には Windows Mobile 5.0 PocketPC の開発についてとても役に立つ情報が載っている。PocketPC SDK のほかにエミュレータまであるらしい。

いままでは、わたしにとって携帯電話は「電話機＋目覚まし時計」でしかなかった。W-ZERO3 は実用的であるだけでなく、遊べる道具にもなりそうだ。実機を触ってみてから購入するかどうか決めたいと思う。

Reference

W-ZERO3[es] クイックインプレッション
( b3 Annex, 2006/07/15 )

[es] の狙い、そして次なる W-ZERO3 の構想
( ITMedia, 岩城俊介, 2006/07/20 )

メモリ増強、電子辞書標準搭載 -ウィルコム、W-ZERO3 のハイスペック版
( ITMedia, 2006/06/22 )

Windows Mobile 5.0 PoketPC
( ディベロッパー製品開発統括部 Blog, 2005/11/02 )

.NET Framework と異なる点
( MSDN Japan, Topic Version 7.1.2298.1803 )

[ UO ] 攻撃速度シュミレータ

他のサイトで見つけたんだけどそのツールは Java アプレットで Java VM 必須。 Java ランタイムが無い環境では動作しません。そこで、ランタイムなんぞ必要としない、 環境にも依存しない攻撃速度シュミレータを作ってみました。JavaScript を使用していますので、 JavaScript を ON にしてくださいね。現在のところ、IE6 SP2 と Firefox 1.5.0.2 で動作確認をしています。

武器選択	スタミナ	速度増加	攻撃速度
----Archery---- Bow Composite Bow Crossbow Elven_composite_Longbow Heavy_Crossbow Magical_shortbow Repeating_corssbow Yumi ----Fencing---- Assassin_Spike Dagger ElvenSpellblade Kryss Leafblade Sai War_Cleaver DoubleBleadStaff Kama Lajatang Lance Pike Pitchfork Short_Spear Spear Tekagi WarFork ---- Mace ---- Club Diamond_Mace Hammer_Pick Mace Wand Scepter Smith's Hammer War_Hammer War_Mace War_Axe Black_Staff Gnarled_Staff Quarterstaff Shepherd_Crook Tetsubo Wild_Staff Nunchaku Tessen ---- Sword ---- Axe Battle_Axe Double_Axe Executionar_Axe Hatchet Large_Battle_Axe Ornate_Axe Pickaxe Two-Handed_Axe Butcher_Knife Cleaver Skinning_Knife Wakizashi Bardiche Bleaded_Staff Bokuto Halbard Scythe Bone_Harvester Broad_Sword Crescent_Blade Cutlass Daisho Elven_Machete Katana Longsword No-Dachi Radiant_Scimitar Rune_Blade Scimitar Viking_Sword		％

使い方

1. 攻撃速度を求める場合

武器を選んでキャラのスタミナと速度プロパの値を入力して「計算する」ボタンを押してください。攻撃速度の部分に計算結果が表示されます。

2. スタミナを求める場合

武器を選んで、速度プロパと目標の攻撃速度を入力。スタミナ欄は空欄のままで「計算する」ボタンを押してください。スタミナ欄に目的の攻撃速度を実現するために必要なスタミナが表示されます。undefined と表示された場合は、どう考えても実現不可能なスタミナであることを表します。

3. 速度増加を求める場合

武器を選んで、スタミナと目標の攻撃速度を入力。速度増加欄は空白のままで「計算する」ボタンを押してください。

4. 続けて計算する前に

前の値が残っていると正常に動作しません。続けて計算する前にリセットボタンを押してくださいな。

計算について

まず、基礎速度 b からスタミナに基いた短縮が行われます。このときに短縮される時間はスタミナを S とすると

0.25 * ( S / 30 )

マジックプロパティの速度増加 m による補正値は

100 / ( 100 + m )

最終的な攻撃速度 d は

d = { b - 0.25 * ( S/30 ) } * { 100 / (100 + m ) }

スタミナは上記を S について変形すると

S = [ b - d / { 100 / (100 + m ) }] * 120

速度増加 m について変形すると

m = [ 100{ b - 0.25( S/30 ) }] / d - 100

あとは端数切捨て処理とかエラー処理を追加して実装しています。 余談ですが、「連想配列なんて作らなくてもよかったじゃん」と select obj 書くときに気付きました。コードではかなり無駄がありますが訂正が面倒なので見逃してください。

これから

UO では、実際には、攻撃速度は 0.25 秒刻みで変化します。しかし、このツールではガウス関数は実装していないので 1.31 とか出てきます。そのうちに直す予定。このほかにバグを見つけた場合はコメントでお知らせくださいな。できる限り修正したいと思います。

謝辞

このツールを作成するに当たって、ウルティマオンライン パラリシャン と Ultima Online ～素晴らしき毒の世界～ にあるデータを参考にさせていただきました。素晴らしいサイトを運営されている鮎渡様と Gray@Izumo 様に感謝いたします。ありがとうございました。

2006.07.22

フィードバックをもとに速度増加の逆算機能を追加。Mikokoさんありがとうございました。ただ、速度プロパは 5% 刻みで表示されますが、内部的に ( つまり強度による計算で ) 6 ～ 9% が付いたときに実際にゲーム画面で表示されるのが 5% なのか 10% なのかわからないので、そのままで出力しています。切り上げ、切捨て処理についてご存知の方はご一報ください。

2006.07.22

桁落ちを考慮していない部分があったのでそれを修正。

2006.09.09

たぶん切り捨て処理だろうということでそれ実装。速度を0.25秒刻みで表示するようにしました。

[ Hardware ] Conroe の欠点は致命傷になりうるか

PC Watch のベンチマーク速報にあるように、パーソナル向け CPU では現状でトップクラスの演算能力と省電力性を併せ持つ Intel の新CPU Conroe。多くのサイトでその圧倒的ともいえる性能がレポートされているが、しかし、完全というわけではなく欠点もあるようだ。Conroe がもつ欠点。それは 64bit 処理が苦手ということだった。

こちらの結果には Conroe で同じアプリの 64bit 版と 32bit 版を実行させたときの結果が公開されている。 AMD 系 CPU では 64bit 版を実行することでパフォーマンスが向上する一方で、Conroe ではほぼ変わらないか逆に低下してしまっている。

なぜ 64bit ソフトウェアを実行すると性能が低下してしまうのか。これについては 後藤氏が考察を述べている。それによると、64bit を実行するとパフォーマンスが低下する主な要因として次の2つが考えられるという。

1. Macro-Fusion が有効にならない
2. REX プリフィクスのために命令デコード効率が落ちる

さて、ここで考えたいのは Conroe は欠陥品で買うに値しないものなのかということだ。わたしは一部の特殊な用途を除けば、PC に乗せるプロセッサとして Conroe は間違いなく優れていると思う。いまある CPU の中からどれを選ぶかと訊かれたとしたら、用途を考えれば、わたしは迷うことなく Conroe を選ぶ。

CAD や 3D グラフィックスなどの巨大なデータを扱うなら 64bit のパフォーマンスは重要なファクターになるだろう。実際これらの分野ではアプリケーションの 64bit 移行が、他の分野に比べて早い。それと、巨大なデータベースを処理しなければならないサーバにも Conroe は向いていないだろう ( というか頻繁に更新が行われるような DB鯖に PC 向け、それももともとはモバイル向けに作られた石を乗せるなんてことはないだろう )。

しかしながら、上記を除いて、つまりほとんどの分野では 64bit はまだそれほど必要とされていないのではないだろうか？比較的多くのユーザがいて、かなり重いソフトが多いと思われるゲームですら 32bit がほとんどで 64bit 化はさっぱり見えてない気がする。というか 64bit ネイティブのゲームなんて見たことが無い。WOW64 をサポートする Windows XP 64bit Edition が正式にリリースされたにも関わらずだ。

2年。64bit が本格的に普及するまでにはあと2年はかかるんじゃないかって思う。Conroe の 64bit パフォーマンスは 32bit で実行したときと比較して遅くなるというもので、テストスコアを見る限りは我慢できないほど遅いというわけではないようだ。32bit から 64bit への移行期に選択する CPU としては悪くは無い選択肢だと思う。
それに、CPU は2～3年で交換するものだしね( ←これが本音 )。

Reference

「Core2 Extreme x6800」＆「Core2 Duo E6700」ベンチマーク速報
( PC Watch 編集部, 多和田新也, 2006/07/14 )

Conroe 登場間近！予想通りの爆発的高性能に影を落とす盲点とは？
( 月刊アスキー編集部, 野口岳朗, 2006/07/14 )

64bit は苦手な Core Microarchitecture
( PC Watch 編集部, 後藤弘茂, 2006/07/18 )

INTEL CORE MICROARCHITECTURE( Yoshishin, 2006/03/23 )
Core MA について IDF 関連の資料を基に解説しています。

難しいセキュリティ

Microsoft がセキュリティ向上のために公開した暗号化ソフト Microsoft Private Folder ( 通称 MPF ) が公開から2週間経たずに公開終了となったらしい。なぜこんなに短期間で？例のごとく ( IE のベータ版か、OS のサービスパックのベータ版を思い浮かべてほしい ) バグてんこ盛りだったのか？

パスワードを忘れて大事なファイルを復号できなくなった人多数

なんと、これが公開停止の理由だという。パスワード管理がまるでできないユーザからの責任転嫁が大量にあったようだ。そんなことあるかと思うことなかれ。ユーザアカウントなどの管理をした経験がある方なら、たぶん納得したんじゃないかと思う。「**日以内に仮パスワードを変更して本パスワードを設定しないとログオンできなくなるよ」という最初の説明を無視するのは序の口。なかには、自分が毎日使う PC のログインパスワードを忘れてしまうツワモノもいらっしゃる。ジョークでも誇張でもないよ。そう、一般ユーザはパスワードを頻繁に忘れるんだな。

プログラマやシステム管理者から見れば信じられないかもしれないけどね。一般ユーザって「人間の記憶はとても曖昧で不安定なもの」っていう認識が低いんだ。これを知っているか知らないかの差はかなり大きい。「プログラマやシステム管理者と一般ユーザはまったく別の生き物」という認識が、MPF を開発したプログラマには無かったのかもしれない。

パスワードは長く複雑なものほど破られにくくなるけど、同時に管理もたいへんになるよね。EFS ( Win2000/XP が自前で持っているファイル暗号化機能 ) のように回復エージェントを設定しまうとセキュリティレベルは低下してしまう。だからといって救済機能を削除してしまうのは今回のような事態を招いてしまう。セキュリティレベルと利便性のトレードオフの問題は実に難しい。より安全で便利だといわれる生体認証にも一長一短があるし、この問題は当分解決しそうに無い。

Reference

Microsoft Kills Off 'My Private Folder' App
( Mark Hachman and Natali T. Del Conte, 2006/07/14 )

Microsoft Private Folder1.0 早速見捨てられる
( CNET Japan, danjo, 2006/07/17 )

[ python / VS2005 ] VS2005 に IronPython を統合する方法

このエントリは aaronmar 氏の Blog "Aaron Marten's WebLog" にある、VisualStudio2005 に IronPython を統合する方法を解説したエントリ "A bit more on IronPython" を日本語に翻訳したものです。原文にもありますが、動作保証は一切ありませんしクレームも一切受け付けません。トラブルが発生しても原著者 aaronmar 氏にクレームを送るようなことはしないでください。

IronPython を VisualStudio2005 に統合するにはどうしたらいいの？
最初にこちらから VisualStudio SDK の最新版をダウンロードしてください。ダウンロードするためには VSIP のメンバーに登録する必要がありますが、参加者レベル ( 訳注: 原文は affiliate level ) ならば無料です。また、VSIP ライセンスに同意する必要があります。

訳注：リンク先にはチェックボックスがあります。以前に VSIP のサイトを利用したことがあり、そのときに会員登録を行ったことがある場合は "Yes" を選択してください。初めて VSIP のサイトを利用する場合は "No" を選択してください。また、Microsoft Passport を持っていない場合は作成する必要があります。 すごくめんどうですが・・・ (-_- il|!

どのレベルの VisualStudio が必要なの？ ExpressEdition でも大丈夫？
残念ながら ExpressEdition では無理です。VisualStudio ExpressEdition はアドインやパッケージによる機能拡張をサポートしていないのです。これは Express シリーズの制限の1つです。VisualStudio Standard かそれ以上が必要になります。

VisualStudio SDK をダウンロードしたよ。IronPython を VisualStudio で動かすには、次は何をするの？
Visual Studio SDK をデフォルトのままでインストールしたとしよう。VisualStudio2005 を起動して、↓のパスにあるソリューションを開いてください。

C:\Program Files\Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Samples\IronPythonIntegration

ソリューションを開いたら [F5] キーを押して Build&Debug を行います。こうすることで VisualStudio の "Experimental hive" モードを開始します。デバッガなしの Experimental Hive モードを開始したいときは "devenv/rootsuffix Exp" ( 訳注：英語版VS がないので確認できませんでした。) を実行するかスタートメニューにあるショートカットから起動してください。

ビルドして実行したけど、これからどうするの？
C# を使ったプロジェクトを作成するときと同じようにして IronPython を使った新しいプロジェクトを作成できます。コンソールアプリケーションを作ってしばらく遊んでみるといいでしょう。拡張子 .py が付いたファイルを開くと、コードが見やすくカラーリングされるのがわかると思います。( 訳注: 実際に py ファイルを開いたところ、↓のようになりました。)

もうひとつ、ちょっとクールなアイテムがあります。このサンプルはアウトプットウィンドウやソリューションエクスプローラに似た IronPython Console Window と呼ばれるツールウィンドウを含んでいるのです。IronPython Console Window は "View-Other windows" ( 訳注: ゴメンナサイ。どのメニューか確認できません。) から起動することができます。

このコンパイラはどうなってんの？IronPython バイナリをコンパイルできないよ。
過去数ヶ月にわたって IronPython チームは IronPython.dll にコンパイラとしてのインターフェイスを追加してきました。これはアナタがビルドメニューを選んだときに、IronPython のシステムがコードをコンパイルするために使うものです。コンパイラがどうやって動いているのかということについて完全に理解するために必要なものが、IronPython ランタイムである IronPython.dll にかなり深く食い込んでいるのです。そもそも Python は動的な言語です。IronPython バイナリが実行されると、それぞれの命令文は逐次評価と型のチェックが行われて実行されるのです。

これが意味するとことは、IronPython バイナリの中身の MSIL は C# や VB で作成された一般的な .NET ライブラリとは異なるということです。実際、他のプロジェクトからは使用することはできないはずです。

相互に参照している複数の py ファイルがあるんだ。これはどうやって動かすの？
簡単です。一連のファイルを同じフォルダの中に入れておいてインポートするだけです。たとえばメインのファイルとして program.py というファイルがあり、myModule.py というファイルをインポートする必要があるとします。2つのファイルを同じフォルダに保存しておけば、 program.py ファイルの中に次の1行を追加するだけです。

import myModule

訳注: ファイルが多くなった場合はサブフォルダを作成して、パッケージインポートを行うと楽になります。パッケージインポートについては Learning Python を参考にしてください。

おっと、バグを見つけたんだけど・・・
こちらに英語でフィードバックを送ってください。発見した問題、質問、提案どれでもいいです。わたしたちは ver2.0 に向けて準備をしています。今はバグの修正と提案を受け付けている最中なのです。

Reference

A bit more on IronPython( Aaron Marten, 2006/02/16 )

Extending Visual Studio 2005
( CodeGuru.com, Vijay Mehta, 2006/04/24 )

Learning Python ( Oreilly Japan, 原著:Mark Lutz 訳: 夏目大 )

[ Python ] IronPython β9

Python の .NET 実装である IronPython の開発が CodePlex に移ったようです。
.NET ライブラリ を Python のコードから簡単に使えて、かつ CPython との完全な互換性を目指して開発が続けられているそうです。 ver1.0 の正式なリリースは今年の夏が予定されています。

IronPython beta 9 のダウンロードはこちら。
β9 ではバグフィックスと CPython との互換性向上、パブリック API の最終的な決定に焦点が当てられています。ホスティング API にも変更が加えられており、サンプルコードがリリースノートに書かれています。

あと、こちらに IronPython を VisualStudio2005 に統合する方法が紹介されています。ただし、無保証でありクレームは一切受け付けないと明記されているので自己責任で行いましょう。

Reference

CodePlex: IronPython Project Page( Microsoft, 2006 )

IronPython Beta9 Release Notes( Microsoft, 2006/07/12 )

A bit more IronPython( MSDNblogs, aaronmar, 2006/02/16 )

[ Python ] Installing TurboGears for Windows

最新LL 5大フレームワーク徹底攻略でも紹介されているらしい、Python の Rapid webdev 向けフレームワーク TurboGears のインストール方法です。TurboGears は Rails の Python 版といったところ。TurboGears が何を目的としたフレームワークであるかの詳細は About TurboGears を参考にしてください。

TurboGears には Python 本体が必要になります。TurboGears のインストールパッケージには Python 本体は含まれていないので、TurboGears をインストールする前に Python をインストールしてください。本稿では Python 2.4 がインストールされているものとして進めていきます。

インストール方法

1. 1. まず、ここから ez_setup.py をダウンロードします。別ウィンドウにテキスト表示されてしまう場合は、リンクを右クリックしてから「対象にファイルを保存」を選んでファイルをダウンロードしてください。
2. 2. コマンドプロンプトを起動します。起動したら ez_setup.py を保存したディレクトリに移動してください。
3. 3. 次のようにコマンドを入力していきます。( スペースの関係上改行していますが、改行せずに1行に入力してください。)

   
   ez_setup.py -f
    http://www.turbogears.org/download/index.html
    TurboGears
   

コマンドに間違えがなければ、必要なファイルが自動的にダウンロードされて、インストールされていきます。最後にエラーがあったかどうかが表示されますが、その行が "error: None" となっていればインストールは成功です。

本家にはチュートリアルも用意されています。

Reference

TurboGears.org

TurboGears Installation on Windows( Kevin Dangoor, 2006 )

The 20 Minuts Wiki ( Kevin Dangoor, 2006 )

Creat Great web apps faster ( Kevin Dangoor, 2006 )

[ review ] ヤバい経済学 読了

ヤバい経済学 ( 通称 Freakonomics ) 読了。

世の中にある、多くの人がこうに違いないと信じきってしまっていること -- Steven D. Levitt は通念と呼ぶ --　や、普段あまり気に留めないことを違う角度から見るとどうなるか。実に鋭い考察だ。

たとえば、1990年代初めのアメリカでは犯罪がどんどん増えていた。1980年からの犯罪発生回数をグラフにするとうなぎのぼりといってもいいほどだった。1995年には、犯罪はもっともっと増えるといわれていたが・・・。2000年になるとがっくりと減ってしまった。この理由については、「景気がよくなったから」とか「画期的な犯罪取締り」といった説が広く受け入れられている。しかし、著者はこれに一石を投じたのだ。「データはそんなことは反映していない。もっと別の理由があるのだ」と。わたしはまず驚き、そして納得した。

Don't Politic, Use Data.

本書ではこの姿勢が貫かれている。 "Don't Politic, Use Data." は Google が掲げるイノベーションのための9箇条にもあるデータドリブンの原則をうたったものだが、研究者にとっても必須といえる「お約束」だ。しかし、いざ実践するとなると非常に難しい。妥当性のあるデータを見つけるのも一苦労だし、膨大なデータの山をどの角度から見たらいいものかといつも悩む。

ヤバい経済学を日々のあれこれに応用するとき、少なくとも1つ、いつも底のほうに流れているものがある。それは ( 中略 ) 筋の通った考え方をするということだ。そのために必要なのは、新しい見方をする、新しい理解の仕方をする、新しい測り方をする、そんなことだ。

( 終章より抜粋 )

という著者のデータの集め方、視点の角度の付け方はとても参考になる。

なお、原著は経済学の教科書としても使われるようになり、その補助として Freakonomics Study Guides まで書かれています。筆者 Steven D. Levitt の Web サイトはこちら。 Freakonomics Study Guides は こちら。

貼ってはがせるホワイトボード

ホワイトボードがポストイットに
オフィスの壁などに貼り付けられ、はがして丸めて持ち運べるホワイトボードが登場。いつでもどこでもミーティングが可能になる。

( ITMedia, ニュースより抜粋 )

すごく便利そう。頻繁にミーティングを開くのは同じチームの 4～5人が多いと思うんだけど、その規模のミーティングで会議室予約して～馬鹿でかい会議室に 4～5人 で～馬鹿でかいホワイトボードにちょこっと図版書いて～って会議は効率悪い。会議室が取れなきゃ会議できないなんてこともあるし、それで情報の共有 ( 修正されてないバグはどれか、新しく出てきたバグはどんなのかとか ) ができないまま非効率的な開発になることだってある。

これを使えば、壁際のちょっとしたスペースで即席会議ができる。あらかじめ何枚かに図版を書いておいて、丸めて壁際に運んで、さぁ会議！ってできるのが素晴らしい。会議のほかにペーパープロトタイピング にもつかえるね。

わたし的には A0 版と A1 版 だと大きすぎるかなって思うので、A2 版とか A3 版も用意してほしいです。

Reference

ホワイトボードがポストイットに
( ITMedia, 斎藤健二, 2006/07/06 )

ペーパープロトタイピング 最適な UI を効率よくデザインする
( オーム社出版, Carolyn Snyder 原著, 2004/06 )

あまりにも愚かな認識

率直に言って馬鹿としか思えない。
ITMedia の Alternative Blog 笑門来福のエントリ思考実験：2010年「殺傷ゲーム禁止法」制定を見てほしい。あまりにも酷すぎる。肩書きは CEO らしいが、このような人間が CEO を勤めるような会社で働きたくはないものだ。なぜかって？このエントリを見る限りマスコミに踊らされているとしか思えないからだ。嘆くとしたらあなたの現状認識能力。

ゲームが少年犯罪の増加と結びつきがないことを証明しよう。

まずはこちら ( PDF File ) を見ていただきたい。そして下のグラフは警視庁の2004年度の統計、統計図表第14 より抜粋したものだ。

ゲーム世代は大体1980年代後半からということになるだろう。これを前提に上の図表を考察してみよう。 平野氏が主張する以下の仮設、

私は、若い人たちがこれだけ人の命を軽く扱うようになった最も大きな原因は、家庭でも学校でもなくテレビゲームではないかと危惧している。ゲームの中ではあまりにも安易に人を殺す。しかも、昔のゲームと違い最近のゲームのリアリティの高さといったら、映画かと思うほどのクオリティだ。「リセット症候群」などという言葉もあるが、残念ながら現実の世界ではリセットしても死んだ人は生き返らない。

( 思考実験：2010年「殺傷ゲーム禁止法」制定 第三段落より抜粋 )

これが正しいならば、ゲーム世代が15歳前後になる1995年以上は犯罪件数は増加するはずだ。 それも、最近になるほどリアルになってより犯罪に強く結びつくのだから、どんどん増加する傾向が見られなきゃおかしいよね？

グラフを見てみよう。1995年といえば平成7年だ。おやおや、犯罪件数はそれまでと比べて大きく減少しているじゃないか。これはいったいどういうことだ？それ以降も犯罪件数は増加していない。指数を見ると、むしろ、平成11年以降はさらに減少しているとさえいえる。こりゃどういうことだ？

結論： ゲームは少年犯罪の増加とは関係がない。

さらに、景気あるいは就職率と少年犯罪発生件数の間にも相関がないことがこのグラフから明らかになる。高度経済成長期・バブル期は現在の2倍近く少年犯罪が発生していて、バブルがはじけてからは少年犯罪が少なくなっているからね。なお、犯罪と景気、就職率の間の相関がほとんどないことは Steven D. Levitt 氏の著書 Freakonomics でも明らかにされている。

Dan 氏も書いているけれど、報道機関ってのは世界の出来事をそのまま流したりはしない。大抵はバイアスがかかる。それをそのまま鵜呑みにすることほど危険なことはない。報道機関が流す情報が正しいかどうかは視聴者自身が確かめなきゃならない。特に、何のデータも示さずにしたり顔で語る自称専門家が出てくるとしたら、それは要注意だ。

最後に、氏にはこの言葉を送ろう。

通念は大体間違っている。
データと真正面に向かい合えば、新しい、驚くような発見にたどり着けることが多い。 ( Freakonomics 序文より )

Reference

警視庁 2004年度統計図表14

Freakonomics( Steven D. Levitt, 2006 )

あまりにも痛ましい現状認識が多すぎる
( 404 Blog Not Found, Dan Kogai, 2006/07/07 )

少年犯罪特集( プロファイル研究所,　管理人とまと )

2006.08.14追記
統計データをわかりやすくグラフにまとめ、鋭い考察をしているサイトを見つけました。
反社会学講座第二回 キレやすいのは誰だ

Google: 発明家になりつつある検索エンジン(2)

このエントリはこちらの続きです。

記事の中では、「Google 内部で使われている技術は学術研究を基にしたものが多く、また自分たちで使うものはソフト・ハード両方とも自分たちで開発している。これが Google の基本だ」というようなことが書いてある。この辺からして既存の企業とは違うね。

わたしは何箇所かそこそこ大きな企業で働いたことがあるけど、どこもほとんどが外注だった。ソフトもハードもほっとんど外注。自社のエンジニア使って開発しているものなんて1割あったかどうかじゃないかな。 "Big companies can't do product development. Big companies are good at extracting the value from existing products, but bad at creating new ones." ( Hiring is Obsolete, Paul Graham, 2005/05 より抜粋 ) を地で行っていた会社だからね。

わたしも同感なんだけど、外注ばかりしていてはだめだと思うんだ。コストもあるかもしれないけど、わたしがダメだと思う理由は別のことからだ。それは、「自分たちの開発能力が下がってしまう」ということ。

極稀にいる天才を除けば、プログラミングは自分でコードを書かなきゃ上達しない。上手く動作するコードを書くことはもちろん、上手く設計することだって無理だ。たまに「コードなんて書いたことがなくても設計ごとき誰でもできる。」とかいうアホがいるけど、そういうアホが書いた設計書は -- これに従ったらデスマーチ確定だろうなぁ -- ってくらい酷いものがほとんどだ。

話がずれたから元に戻そう。書かなきゃ上達しないのは当たり前だけどさらに悪いことに、長い間書かないとだんだん下手糞になっていく。最終的には自分たちでは何も創れなくなってしまう。技術力の空洞化という現象が起こってしまうんだ。

一方で、自分でコードを書き続けて、コードを読み続けていると、だんだんと上手になっていく。プログラミングを始めた頃のことを思い出してほしい。きっと "Hello World!" くらいのプログラムしか作れなかったと思う。それでも、「これはどうすればいいんだろう。これは何でこうなるのかな」って自分で考えたり本を読んだり、そして自分でコードを書いてきたからこそ、いま自分が書いているようなコードを作れるようになったんじゃないかな？モノを作るのが好きでそれを続けていれば、少しずつであっても上手になっていくんだとおもう。

そもそも、プログラマってのは “ものづくり” なんだから、自分でモノを作れなきゃ。
あれ？でもそう考えると "A Serch Engine That's becoming an Inventor" ってのもおかしいね。Google はプログラマ ( = ものづくりの人 ) が集まってできた会社なんだから、“ものづくり”の会社になって当然。タイトルのように考えるよりもむしろ、Google という発明家が作った代表作がサーチエンジンと考える方が自然じゃないかな。

そして、プログラミングだけじゃなくて自作も大好きな人たちが集まれば、「CPU も創ってみようか」って思うのも自然な流れかもしれない ( そーいえばCPUの創りかたが机の横の積本になっているなぁ。これも読みたい )。ソフトもハードも、ものづくりが大好きな人たちが集まった Google という会社が次に何を創るのか。わたしは楽しみで仕方がない。

Google: 発明家になりつつある検索エンジン(1)

B3 Annex と MyLife Between Silicon Valley and Javan でも取り上げられていた、"A Search Engine That's Becoming an Inventor" の翻訳です。今回は比較的訳しやすい英文だったかな ( わっかんないところもあったけど )。

Google がシリコンバレーのガレージで卒業研究プロジェクトとして始動したとき、創始者の Larry Page と Sergey Brin は自分たちが使うコンピュータをやっすいパーツで自作した。彼らが組み立てたのは「パーソナルコンピュータ」だったのだ。彼らはコストを抑えたかったし、旧来のメーカーが作るものよりももっと効率のいいコンピュータネットワークを設計できると思っていたのだ。

Google はもうわずかなお金を切り詰める必要なんてなくなった。Google は 90億ドルもの預金をもつ、Fortune 500 の固定メンバーだ。しかし、いまだに Do-it-yourself の精神を貫いている。 Google は今年 15億ドル以上もオペレーションセンターと技術に費やして、独自に設計した膨大な数のサーバーを設置している。

ユーザにより近くなるように、レスポンスをより早くするように、 Google はオレゴン州ザダルスを含めて世界中にデータセンターを建設している。そこでは膨大な消費電力を抑えるための技術も使われている。コンュータが使うソフトウェアも、サーバーと同じく Google が一歩進んだツールを使って自作したものだ。これらは Google がマイクロチップでさえも自作する準備ができたという兆候だ。

「Google は検索エンジンと同じくらいインフラを重視している。Google は想像できそうもないほどのスケールでコンピューティングリソースを開発している。」と Gartner Group のアナリスト Martin Reynolds 氏は語る。 Reynolds 氏は、Google は Dell、Hewlett-Packard、IBM に続く世界4番目のサーバーメーカーだと語る。

Google の最大のライバルである Microsoft や Yahoo も、Google と同じようにソフトを自社開発しているしデータセンターも運営している。しかし、そこで動いているサーバーは Dell や Sun, Racable といったメーカーから購入しているのだ。

「自問自答しなきゃならないことがある。ビジネスの中心に据えていることは何かってことだ。ルータを自作して、世界規模で人気のある Web サイトを作りたいって？両方を行うのはかなり難しいよ。」と Yahoo の運営 ( operation ) 統括責任者 Kevin Timmons は語る。

Google は実際に両方をやろうとしている。多くの点で、Google は卒業研究という "頭脳" を実行する体 ( 多国籍企業 ) に結びつけた。既存のものよりもより多くの情報をより効果的に収集して処理できるネットワークを設計できるコンピュータサイエンティストを集めて成長する組織であること。これが Google の戦術の中枢なのだ。

Reynolds 氏は Google がコンピュータに使うことになるコストは他の巨大インターネット企業の半分程度で、古くからある企業の技術を使っているユーザは 1/10 だろうと見積もる。

Google はコストについてのコメントは避けているが、長所については語ってくれた。リサーチ＆システムエンジニアリング担当副社長の Alan Eustance 氏が3月にアナリストに語ったところによると、「わたしたちと競争する企業がより安くより高速でより規模の大きいシステムを展開できるとは思えない。これがわたしたちに 2～4年分のリードを与えてくれる。」 のだそうだ。

こんな Google ののろけ話をよそに、反論もある。Google の「何でも自家製」主義は非効率的で不必要だ。今は急成長期にあることと広告事業の収益の高さで隠されているけどわがままな道楽に過ぎないというものだ。Google のライバルは自社のネットワークは十分にパワフルで効率的だと主張している。

「Google マジックなんてどこにもないよ。わたしたちは ( Google より ) ほんの少し多く機械にお金を使っている。しかし、同じことをしているし、機械を失うこともない。」 Microsoft の Bill Gates 会長はインタビューに答えて語った。

周知のことだけど、Google はその技術に関しては秘密主義だ。開発したものを新聞に載せたり、他社に特許のライセンスをするときも同様だ。Google と ベンダー共同の公式声明に加えて、契約を結んだ企業は企業のイメージををコンピュータ科学の限界を押し上げるように描かなきゃならないし、( Google の ) コンセプトをかなりの範囲にわたって適用しなきゃならない。

「Google はスーパーコンピュータ研究会から最良のアイディアを持ってきて ( 同社で ) 動いているシステムに組み込んでいる。」 The Google Legacy の著者 Stephen Arnold 氏はこう語る。

Google のイノベーション( 技術革新 ) のあるものは、どんどん増えていく技術コストを少しでも削減するための設計だ。去年、"drive-cooling baffle" という特許 ( 06906920 ) が承認された。これはラックに収められたコンピュータにかぜを通すものだ。

しかし、いくつかのイノベーションは、いくつものプロセッサで行われる並列処理を簡単にするソフトウェアのようにより際立ったものだ。

Urs Hölzle によれば、その中のひとつである MapReduce と呼ばれるプログラムはコンピュータサイエンスの分野で数十年にわたって研究されてきたアイディアを基にしている。「わたしたちを驚かせたものはものすごく役に立って、結局はそれがシステムに組み込まれるんだ」という。

Hölzle 氏が言うには「MapReduce はあまりぱっとしないソフトウェアエンジニアでも膨大な量のデータを扱えるようにするし、インフラを駆使できるようになる」ということだ。

コンサルタントの Arnold 氏はこれらのツールがコスト面で大きな利点をもたらしているという。「巨大な並列処理系のシステムではたらいているエンジニアと会話してみると、コーディングの時間の 30% がどうやってシステムが動いているのかを解明するために費やされていることがわかります。Google はどうやったら面倒で厄介な仕事を減らせて、並列処理アプリケーションをたくさん作り出せるのかを解明したのです。」

Gates 氏も MapReduce がとても素晴らしい技術だと認めたが、Microsoft でも独自の並列処理ソフトを開発していると主張した。Microsoft と Google の新たな技術戦争の始まりだ。

さらに、Google は汎用ツール、汎用システムを開発しているが、これも特定のアプリケーションシステムを開発する多くの企業と異なっている。Google はものすごい資金と多くのエンジニアを導入して、それらのシステムをどんどん組み立てているのだ。それらのツールはライバルと比べてより少ないお金で、より多くのモノを創り、より多くのことを成せるような優位性を確立できるだろう。

「ネットサービス運営において 30% のコスト優位性が得られれば、大きな差になる。」と Norwegian Search Company のチーフエグゼクティブ M. Lervik 氏は語る。

Arnold 氏は、Google の学術的なアプローチの軌跡は創始者たちの卒業研究だけじゃなく日常生活にも見ることができるという。創始者の2人はコンピュータ科学と数学の専門家の家庭出身なのだ。

「1996年から1998年はまだ未熟だった」と、Arnold 氏は Google の創始者について語る。「食卓で両親と会話するときに2人は多くのことを学んだのです。」

創始者の2人が Google を創るまでは、並列処理というのは学問の夢だった。並列処理は PC に使われるような安価な CPU と メモリ、ディスクドライブを組み合わせることで大規模システムの構築を可能にしたのだ。これらの部品は高品質なものはほとんどないし、頻繁に故障した。

Page 氏がパーツは基本的に壊れるものだということを前提に、初期の Google のサーバを設計した。最初彼は、部品をしっかりと止めてしまうのではなくてコルクのベッドの上にただ単に置くだけにした。簡単に組み立てられて、修理にかかる時間を短くするためだ。この方法では不安定であることが判明したので、ベルクロ ( 訳注: ナイロンテープを使った留め具のこと ) で固定することにした。

「わたしたちほど信頼性の低いサーバーを組み立てているところはない。と Hölzle 氏は去年の CERN で語った。Google は信頼性の中核をハードウェアからソフトウェアにシフトさせることでコストを削減しているのだ。ここのハードウェアパーツは壊れたとしても、ソフトが自動的にタスクとデータを他の稼動しているマシンに移行させるのである。

たとえば、Google は GFS: Google File System と呼ばれるシステムを設計した。( 訳注: GFS に関してはここ(PDF file) に論文が公開されています。Radium Software や arai blog でも解説があります。) GFS ではデータのコピーが複数の場所に分散しているので、安いサーバのどれか1つが故障することを危惧する必要はないのだ。GFS は、他の企業のように、常時バックアップを取る必要がないということも意味している。

他に Google　Work Queue と呼ばれるシステムがある。これは膨大なサーバ群に必要に応じてタスクを割り当てる仕組みだ。処理しているタスクが終われば、別のプロジェクトのタスクが割り当てられる。この “仮想化” と呼ばれるコンセプトは巨大なデータセンターを運営する人間の間ではトレンドになりつつある。オペレータは個々のサーバをそれぞれのシステムに割り当てるためのコストも削減したいと思っているからだ。しかし、大抵の企業はコンピュータが何をやっているのかとかをトラッキングするために商用ソフトウェアを購入している。

Google のサーバは安価なパーツでできているので、効率を良くするために、よりいっそう Google のアプリケーションに適合するように毎年変更を加えることができる。現在は AMD の Opteron を利用している。Opteron は Intel の CPU よりも消費電力が少ないのだ。

Google は AMD の最大の顧客だが、AMD の経営に詳しいとある半導体産業の幹部によれば、コンピュータの再販売はしていないという。( 原文は "Google is among Advanced Micro's five largest clients, and the largest that does not make computers to resell, according to a semiconductor industry executive with knowledge of Advanced Micro's business." 訳せません。ごめんなさい (>_<; ) )

同様に Google は Sun とも協業している。信頼性があって高価なシステムで知られる Sun は、倹約と自給自足を重んじる企業とはしっくり合わないように思える。しかし現在の Google の CEO である Eric E. Schmidt は Sun の元幹部である。そして Sun は省電力製に特に優れた CPU を開発しているのだ。

さらに、Google は検索エンジンで使われているサーバよりも信頼性の高いサーバの必要性を必要としている。というのも、Gmail や Google Checkout といったサービスでより重要な情報を扱うからだ。

サーバの向こうには、Google が独自の CPU を開発している兆候が見える。Google は、Alpha チップでよく知られる DEC の関係者を多数雇用している。

「Google の次のステップは半導体開発だ」と技術アナリストの Mark Stahlman 氏はいう。

Hölzle 氏は、Google は特注の半導体設計はあると語っているが、Google で実際に組み立てていることは否定した。Google は、いいものが購入できるなら、ゼロから開発しようとは思わないという。

しかし、と彼は付け加える。Google が自分自身で安くて早いコンピュータネットワークを作っていることこそが Google を最先端に位置づけていると信じている。

「比較的信頼性の低いマシンを大量に設置して、信頼性のあるサービスに添加するのは難しい問題だ。それはわたしたちがしばらくの間は続けていくことだ。」と Hölzle 氏は語る。

Reference

A Serch Engine That's Becoming an Inventor
( NewYorkTimes.com, Saul Hansell and John Markoff, 2006/07/03 )

「グーグル帝国」はマイクロソフトを超える--識者が予言
( CNET News.com, Elinor Mills, 2005/09/22 )

The Google Legacy ( Stephen E. Arnold, 2005 )

Google File System
( Google, Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung, 2003/10 )

[ review ] Python cookbook chapter2

Chapter1 の頭が痛くなる英文にげんなりして読むペースが大幅にダウンしてたけど、なんとか chapter1 読了。とはいっても使いそうにないところは、英文が酷かったこともあって飛ばしたけどね。 もう一度言わせてもらうと、Fred L. Drake, Jr. 氏 ( Chapter1 の編著者 ) の書いた本は読みたくないな (-_- il|!

いまは chapter2 を読み始めたところ。 chapter2 の編集者は Mark Lutz 氏。Learning Python　の共同執筆者の一人だ。Learning Python は結構読みやすいほうだったかな。それもあって期待してた。今のところ ( とはいってもまだ Introduction とはじめの方のレシピをいくつか読んだだけだけど ) は内容もきちんとまとまっていて文章も読みやすいから期待通り。

ファイルの R/W は Learning Python でも、基本的なことは触れられていた。ちょっとしたスクリプトなら Learning　Python でもいいんだけど、特定の情報が書かれた行だけを読み出してその情報にあわせた処理を行うというようなプログラムになると、美しいと思えるコードは書けません。独学で先に進むには、先人たちはどうやっているんだろうってことを教えてくれる本が必要だなって思う。Python Cookbook では、より安全なコードはどうやって書くのかとか特定の行を処理するにはどうしたらいいかとか CRC はどうやって求めるのか etc,,, 実際にどうやって書いているのかが解説されています。

Mark Lutz 氏の著書は、8月に Programming Python 第3版が出版されるらしい。Python 2.5 にも対応しているらしいから、中身を読んでみて得るものが多そうならこっちも購入して勉強しようと思う。近くには洋書を扱っている書店がないので O'reilly 本家か Amazon のサンプル待ちかな。

Google: 新しいサービスが生まれるまで--コアフィロソフィーと全員一致の原則--

BusinessWeek.com に Marissa Mayer 氏の掲載された。 Google ではどうやって新しいサービスを開発しているかが語られている。 いつものように拙い訳ではあるが、翻訳してみました。最後に出てくる "consensus-driven" approach は「全員一致の原則」とでも呼びましょうか。 これは Googleの黄金律 でも触れられていますね。 ただし、大切なことは経営者の意見一致ではなく、チームの技術者の意見一致 でなければならないということでしょう。

いつものように、誤訳の指摘は大歓迎です。
特に今回はかなり訳しにくい部分があったので不安です。
英語に強い方のご協力をお待ちしております m(_ _ )m

• たくさんのアイディアを試せ
• 試験中のアイディアをより洗練しろ
• サービスとは何かを理解しろ

これが Google の信条です、と検索＆ユーザーエクスピリエンス担当副社長の Marissa Mayer 女史は語る。

Google をよく知らない人にとって、サービスを公開したときの Google の株価の 一時的な混乱は全くでたらめに見える。たとえば、去年のブログサーチエンジン ( 訳注: Google Blog Search のこと ) やファイナンスサイトと IM ( 訳注: Google Finance と Google Talk のこと )、それにスプレッドシートサービス ( 訳注: Google Spreadsheets のこと ) だ。そして6月28日には、eBey や PayPal にあるような オンライン決済システム ( 訳注: Google Checkout のこと。2006.7.2現在日本では開始されていません ) も登場した。

Google はインターネット検索エンジンの枠を超えて大成功している。これは明らかだ。 しかし、これまでのところ、検索以外の分野での Google の業績はぬるい ( tepid ) ものがある。 Google は ADD ( 訳注: ADHD のうち多動性を欠いた状態のこと。1つのことに 集中できずに衝動的にあれもこれもと手を出してしまう様を喩えているのだと思います。 なお、日本ではよからぬ誤解を招くこともあるので ADD, ADHD ともに使用しないほうがいい言葉です。) に陥ってしまったのか？それとも狂気ともとれる見かけの背後には法則があるのだろうか？

Marissa Mayer が BusinessWeek の記者 Ben Elginに、 Google が新しいビジネスに挑戦するときの努力について語った。 これはその引用である。( 訳注: 以降、太字が Ben Elgin氏の質問で、 それにMarissa Mayer 氏が答える形になっています )

Google は検索を超えた分野への事業拡大を考えています。 Google がやってきたことにをどう感じていますか？

2～3あるコアフィロソフィーからお話したいと思います。 わたしたちは、有名になることよりもより多くのサービスを開始するべきだと信じています。 本当に功を奏するであろう新しいイノベーションを見つける秘訣は、 5つリリースしてその中の1つか2つは上手くいくだろうと考えることです。 わたしはこの方法で考えてきましたし、( 実際 ) 大きな成功を遂げてきました。 プロモーションは行わずに、わたしたちはプロダクトを公開してきました。 そして、その中のいいプロダクトは成長しています。わたしたちはなるべく早く プロダクトを公開したいと思っていますし、ユーザがそれに対してなんと言うか、 ユーザが追加してほしいと思う機能は何なのかを知りたいのです。そして、 ユーザの声を参考にプロダクトを作って公開します。

わたしたちは、プロダクトは研究所 --Google beta site-- に公開して、 ちょっとした小さなものから口コミで成長させた方がいいと考えています。 そうすることで要望に対応するための時間が取れるのです。 加えて、この方法はいくつかのさらに重要なこと、「このプロダクトは主な 必要性を十分に満たしているか」「このプロダクトの市場の大きさはどのくらいか」 「他と比較して、わたしたちのプロダクトの強度はどのくらいなのか」 といったことを教えてくれるのです。

新しいプロダクトが成功したかはどうやって判断するのか？

まず最初にログを参照します。それからユーザからのフィードバックです。 Gmail は最も広く知られていると思う。規模でいえば Hotmail や Yahoo!メール ほどの大きさはない。実は、前述のイノベーションモデル ( 訳注: 少数のユーザ に公開して、そのフィードバックを元に改善しながら徐々にユーザ数を増やす、 という方法のこと ) に従って Gmail を持ち上げるようなことは禁止したのです。 Gmail をこのイノベーションも出るから開放したら、需要と同じ10倍くらいの 大きさになることは容易に想像できます。現在の10倍の大きさになるとしたら、 それは Hotmail や Yahoo!メールと大体同じくらいの大きさです。このことから、 わたしたちは Gmail は大成功したプロダクトだと考えています。

もしアナタが Google News のようなものを軽くでも見たとしたら、それは実際には結構上手くいっているのです。 わたしたちは Google News を40ヶ国で40以上の言語で提供しています。 これら全ての地理的にも、人口統計的にも異なる地域から集められた PV から、 わたしたちは Google News が実現したことを誇りに思います。 Google News は年々成長しており、成熟したプロダクトの中でももっとも強力なものになっています。 わたしたちはトラフィックが毎年2倍に増えているのを見ているのです。

わたしたちが多くのことを形にするに当たって支えてきた重要な基盤があります。 確かにわたしたちが公開したいくつかのサービスがありますが、 わたしたちは市場のリーダでもなければそうなろうとも思っていません。 わたしたちは多くのプロダクトを放棄することになるだろうと予想しています。 放棄されたプロダクトは思い出されることもなくなるでしょう。 しかし、ユーザはその中の本当に重要な、多くのユーザを抱えていた何かを思い出すでしょう。

Google Checkout のようなカテゴリーキラーとなりうるような 新しいサービスを、報道機関やアナリストが頻繁に報道してしまいます。 Google が市場に革新を起こしたり競争事業者を蹴落とすことについて 人々は Google に過度の信頼を寄せているのではないか？

わたし自身も含まれますが、一般に、人々は短期間を過大評価し 長期的には過小評価する傾向があります。もし彼らが書くヘッドラインを 目にしたとしたら、彼らにはこの種の心理が働いているのです。 PayPal は本当に素晴らしい、十分にこなれたプロダクトです。 そしてわたしたちのサービスがやろうとしていることは何かを実際に観察したならば、 Google Checkout は本当は彼らのやることとは競合しないし 彼らの中枢となるコンピテンシーとも競合しないとわかるでしょう。 つまり、Google Checkout が何を目的にしているのかを誤解しているに過ぎないのです。

Microsoft の Excel のような十分に洗練されたプロダクトを観察してください。 開発サイクルのごく初期の生まれたばかりのプログラムに高い価値をつける ( hold up ) のはかなり無理がありますし、 キラーアプリとなることを期待することも難しい。隙間に入って競争しようと思うでしょうか？ もちろん、完全に成熟した市場に出せるだけの長い時間が取れるならば、可能でしょうけど。

Google の HP はすっきりと整えられている。鋭利なデザインを失うことなく プロダクトが目に付くようにするにはどうすればいいかとか考えが変わることはなかったのか？

ちょっとは変わっていますよ。根本的な部分を変更したり、 全てのプロダクトを HP に並べる準備はまだしていませんね。 でも、サイト案内をどうやって変更しようかということに対するキーコンセプトならいくつかあります。 1つはわたしが "San Angels" or "Los Diego" ストラテジーと呼ぶものです。 アナタが持っている大きなプロダクトをまとめてひとつの大きな possible nucleus にするのです。 たとえばアナタが San Diego と LA を持っているとしたら、それらをまとめてひとつの メガシティにするのです。メガシティは2つが独立して存在するよりも大きく 人々の印象に残るでしょう。

Google News を見るとき、 ユーザは現在の出来事に強い関心があるし、マルチビュー ( それも Blog Search や Google Finance で表示されるような使いやすい ルックアンドフィールを持っていなければなりません ) で見たいと思う ユーザの基本心理を Google は理解している。そう、わたしたちは どうやって機能を持った断片を組み合わせたらいいのかを観察しているのです。 人々にとっては特定の企業のプロダクトを5個も10個も憶えているのは難しいことです。 もしわたしたちがそれぞれのプロダクトをより大きくより意義があるようにしたならば、 わたしたちとユーザの両方により多くの利益がもたらされると考えています。 なぜならばユーザにとってはいくつも完全に憶えている必要はなくなりますし、 わたしたちはトラフィックが増加するからです。

Google の広告はニッチなものなのか？

Da Vinci Code のクエストのようなとても興味深いことがありました。 4月に起こったことです。わたしたちは SONY Pictures と共同研究していました。 わたしたちは SONY が映画に使う広告と同じくらいいいものを創っていました。 Google が創るプロダクトの理解を得ようと思ったのです。 ( 訳注: このパラグラフはかなりいい加減です。どう訳していいものかさっぱりわかりません )

クエストを行う人々のために、毎日異なる Google のプロダクトを展示しました。 ログインして、少なくとも1度はパズルで遊ぶ人々が数百万人いました。 そして、わたしが思うに、10万人以上がそのパズルを解き明かしました。 Google の従業員であったため失格となってしまったのですが、参加者の中には Google の共同創始者の Sergey Brin がいたのです。彼は100,072人目の達成者でした。 彼は予選で失格になってしまいました。

たくさんある既存のサービスをアップグレードしていくに足る規律は Google にあるのだろうか？

CEO の Eric Schmidt と共同創始者の Larry Page は もう少し組織化しなければならないと認めています。 しかし、技術者の心理を理解することもまた重要なのです。 特定の仕事に取り組み続けてうんざりしたので 新しい仕事に移りたいと思っている技術者が何人かいます。 しかし、多くは働き続けてなじんだ場所で、 最善の組み合わせのプロダクトを作りたいと思うのです。 ( 訳注: 新しい未知の仕事にどんどん挑戦したいという少数の技術者と、 なじんだ場所で働き続けたいと思う多数の技術者がいる、ということでしょう )

News チームを指揮する Mike Dixon は "ニュース" ということについて あまり明るくない技術者でした。しかし今では世界中の情報源に驚くほど精通しています。 間違いなく彼は熟達したニュースの利用者となったのです。そして、このことは 質が高く最善の組み合わせのニュースサイトを作るために本当に重要なのです。

Google Maps の技術者についても同じことが言えます。彼らは文字通り 世界中の地図を表示することを研究しました。 彼らは彩色とコントラストも研究しました。 道路名は、地図上の道路を横切る形で表示されるのではなく、 実際には表示される道路の中に表示されます。

PM は Google 内部でもっと力をもつ必要があるんじゃない？

いいえ、そうは思いません。わたしたち ( 訳注: 恐らくPMに相当する人 ) は課題に熱心に取り組んでいる人々がいるチームをまとめています。 面白いことに、わたしたちは詳細設計は決して行わないのです。 「これがわたしが作りたいものだ」といわんばかりの70ページにも及ぶ ドキュメントを押し付けようものなら、創造力を大きく削ぎ落とすことになります。 とあるエンジニアは「あんたは忘れているだろうが、 付け足したい機能があるんだよ」といいました。 アナタは創造力を削ぎ落としたいとは思わないでしょう。 チームが一丸となって作ろうとしているもののヴィジョンを創り上げ、 さらにそれぞれのメンバーの創造力を加算できるだけの十分な余裕を残しておく という "consensus-driven" アプローチがわたしたちの創作意欲をかき立て、 いままでに創ってきたような最高のプロダクトを生み出したのです。

Reference

Inside Google's New-Product Process
( Businessweek.com, 2006/06/30 )

Googleのブログ検索「Google Blog Search」ベータ版公開
( InternetWatch, 三柳英樹, 2005/09/14 )

Google Talk について( Google, 2006 )

米Google、サイト横断的決済サービス「Google Checkout」提供開始
( InternetWatch, 青木大我, 2006/06/30 )
*訳注: 2006/07/02 現在、checkout は日本では開始されていません

Google: Ten Golden Rules
( Newsweek.com, Eric Schmidt and Hal Varian, 2005/12/02 )

[ H/W ]AMD が低価格 Dual Core プロセッサを準備

AMD が Athlon64 X2 3600+ という新しいプロセッサを準備しているみたい。 Athlon64 X2 3600+ のスペックは↓表のようになるようです。 比較として 3800+ のスペックも載せておきました。

モデルNo.	3600+	3800+
動作周波数	1.8 GHz	2.0 GHz
L2 キャッシュ	256 KB / core	512 KB / core

確かな情報ではないけど、出荷予定は第4四半期らしい。

AMD の中ではもっとも価格の低い DualCore CPU になるね。 価格は 3800+ ( 2006.07.02 現在 \34,921 ) の半分程度になる様子。 価格帯からすると PentiumD 805 ( CoreClk 2.66GHz, L2 1MB/core ) と競合するようだ。

Intel の DualCore CPU が \15,000 からあることを考えると、 AMD の DualCore CPU は性能は高いものの価格は高めだった。 Intel の DualCore は安いけど、性能の割りに消費電力と発熱量が大きいとも言えるけど(苦笑)。 L2 cache がかなり少ないものの、今までの半額で Dual Core CPU が買えるようになるのは大きな魅力だ。 どうするかはベンチマークの結果待ちかな。

Reference

AMD prepares low-cost dual core 3600+ processor
( TechSpot.com, Justin Mann, 2006/06/28 )