パスワードを忘れた? アカウント作成

airheadさんのトモダチの日記みんなの日記も見てね。 ログインするとコメント表示数や表示方法をカスタマイズできるのを知っていますか?

12767962 journal
Windows

airheadの日記: memo: Windowsサウンド不調 2

日記 by airhead

症状:一切の音が出ない。音量コントロールいじった時の確認音も出ない。メディアプレーヤー再生でエラー。これはどれほど関係しているのかわからないが、Webストリーミング再生では、ブラウザとサイトの組み合わせによってエラーが出る。

解決法:ドライバを入れなおす。普通過ぎてちょっと恥ずかしい。同時にメディアプレーヤやブラウザの症状も回復したので、やはりサウンドドライバが原因だったのかもしれないが確証はない。

ただしIEだけは、他が復調後も「ほぼ」復調といったところ。YouTubeを再生できるようになり音も出るが、しばらくすると固まることがある、らじるらじるでは相変わらず再生ウィンドウ開いた時点で固まり、再生までこぎつけない、といった具合。サウンドドライバ以外に原因があるのか不明。また気が向いたときに調べてみようと思う。

以下、未解決時の症状を残しておく。

  • 環境: Foxconn安マザーのオンボードサウンド、Windows10 64bit。
  • ハード関連:スピーカーは生きてる。出力ジャックも問題なさそうだ。シャットダウンして完全に電源断の後、再起動しても治らない。
  • デバイスドライバ関連:
    • デバイスマネージャでは正常。dxdiag.exeでも正常。イベントログに関連してそうなものは見当たらない。
    • サウンドのプロパティ-サウンドタブ最下段のテスト再生でも音は出ない。Windows起動音のような長めの音でも再生アイコンの右向き三角に変化がないので、再生に失敗しているっぽい。
    • サウンドのプロパティ-再生タブ-スピーカーから、スピーカーのプロパティ-詳細タブのテスト再生でも音は出ない。それに加えてこちらでは「[エラー] テスト トーンの再生に失敗しました。」というポップアップが出る。(以下どうやっても音は出ないので、その旨は省略する)
  • メディアプレーヤ関連:
    • WMP12:ライブラリ-音楽からアルバムを開いて再生ボタンを押すと、メディアリスト1曲目のトラック番号の左に、赤丸に白バッテンのアイコンが出る。同アイコンはプレイリストの1曲目の曲名左にも出る。次再生を示す右向き三角は2曲目へ移る。再生ボタンは再生待ち状態で、この間1秒未満。コンテキストメニューでファイルの場所を開くことはできる。
       ボタン連打でアルバム最後までバッテンアイコンがつくと、「ファイルの再生中に Windows Media Player に問題が発生しました。」というポップアップが出る。Webヘルプボタンを押すとページWindows Media Player のエラー C00D11B1に行けるが、役立つ情報はない。ExplorerからメディアファイルをWMPで開くと、即刻同じポップアップが出て再生に失敗する。Webヘルプのページも同じ。
    • Grooveミュージック:アルバムを開いて再生ボタンを押すと、1曲目から次々とトラック番号の左に丸に感嘆符アイコンがついていき、最後まで行くと「再生できません。 / このアプリを引き続き利用するには、最新バージョンをインストールしてください。 / これに関するヘルプを見る / この問題について、Microsoftにフィードバックを送信します。 / 0xc1010003 (0x80040154)」というポップアップが出る。
       一旦そのポップアップが出ると、再度再生を試みても今度はポップアップが出なかったりする。だがいろいろ試してみたところ、リピート再生の指定やトラック数の多いアルバムの再生など、20~30曲連続で再生に失敗するとほぼ確実にポップアップが出るようだ。たまに勝手に閉じてしまうが、クラッシュやフリーズに関するWindowsからの通知はない。
    • 映画&テレビ:再生しようとすると「再生できません。 / このアプリを引き続き利用するには、最新バージョンをインストールしてください。 / 0x80040154 / フィードバックの送信」というポップアップが出る。0x80040154というIDなど、基本的にGrooveミュージックと同じ内容。
  • Webストリーミング:(関係あるのかわからないが、Twitterなどで話題になってないところを見ると、ここだけの問題のように思われる)
    • YouTube:FirefoxやChromeでは音が出ないだけで映像は再生されるが、EdgeやIEでは「エラーが発生しました。しばらくしてからもう一度お試しください。(再生ID:...) 詳細」という砂嵐背景のエラー表示になる。
    • radiko.jp:Chromeでは再生中のようなボタン表示になるが、FirefoxやEdgeではバッファ中を示す再生ボタン点滅のまま。IEではページ表示自体進まず白紙のままで「radiko.jpは応答していません。」とのエラー表示。
    • らじるらじる:Chromeでは再生中のようなボタン表示になるが、FirefoxやEdgeではバッファ中を示す再生ボタン点滅のままで、しばらくすると再生ボタン位置に「コネクション・エラー」と表示される。IEではページ表示は完了するものの再生(ポップアップ)ウィンドウの「同意して聞く」ボタンを押しても無反応。ポップアップウィンドウを閉じると親ウインドウも開き直しになり、「このWebページに問題があるため、Internet Explorerのタブを開き直しました」とのエラー表示。
  • (書きかけ。もう寝る 05/03 00:15 / そういやBIOS見てなかったです。明日見よう。今度こそ寝る 00:30)
12759031 journal
日記

airheadの日記: word: Take Me With U

日記 by airhead

親愛なる殿下へ

私はまだ死にたくないし、死を恐れながら生き続けて、最期までジタバタしするのが私にふさわしいと思っています。いま私の国で起こっていることも、いろんなことを考えさせます。しかし貴方がまだまだいろんな所へ連れて行ってくれると思っていた私の、いまの気持ちは、

I don't care, pretty baby,
just take me with U.
Take Me With U / Prince

な感じです。悪戯が過ぎますよ、殿下。

12717407 journal
数学

airheadの日記: memo: 円周率の語呂合わせ 9

日記 by airhead

私が憶えていた円周率の語呂合わせは下のようなやつ。小数点以下30桁までで、得られる円周率は真の値よりわずかに小さく、その差 1e-30 未満。

みひとつ よひとつ いくに むいみ いわくなく みふみやよむ じむしさんざん やみになく
3.14159 26535 89793 23846 26433 83279 ...

一方で、観測可能な宇宙の直径は約 8.8e26[m] らしい。ちょうど 8.8e26[m] だったとして、上の記憶法で宇宙一周の長さを出したときの誤差は 8.8e-4[m] = 0.88[mm] 未満となる。意外と身近な長さにびっくり。今後「宇宙を救うために一周する紐が要るから、長さを計算してくれ」とか頼まれることがあっても、まあ2、3mmオマケしておけばなんとかなるだろう。

というか、さっき思いついたからといって、わざわざ15時まで待って投稿するほどの話じゃないな。

12537223 journal
日記

airheadの日記: memo: ギターマガジンをスキャンする

日記 by airhead

ギターマガジンをスキャン中。100冊以上あるのかな。最初は楽勝かと思ってたが、結構しんどくなってきたので、息抜きにメモ。

スキャナはHPの複合機、ソフトはIrfanView。本はばらさず、グレースケール300dpiでスキャン、PNGでページあたり5.5~6.0MB。ページ替えなどテキパキやって1ページ20秒ぐらいか。同じくカラーだと10~11MB、スキャン時間も倍ぐらいかかるので、カラーページもほとんどグレースケールで。リンダ・マンザー作「ピカソ・ギター」の写真はさすがにカラーで取っといた。

譜面中心、GM Selectionsは全部取っとくつもりだが、Feartured Guitaristsや特集は8割程度。取り上げる程かなと当時も疑問だったバンドとか、二三年おきに出てくる運指トレ特集とか、もういいや。インタビューのみとか、後半ページの連載セミナーはいらない。買いだした頃のように隅々まで熱心に読むことはないし、取っといても結局読まないだろう。興味があればテーマごとにまとめた教則本でも買ったほうがいいような気がする。で、1号あたり60ページぐらい。

手に取って読んでるうちは大して気にならなかったが、印刷の傾きがひどいページが多い。ほとんどが時計回り、角度にして最大でも1度ぐらいだが、その場合8分音符主体の2小節進むと五線譜の線1本分下がっていたりする有様で、画面越しでは相当気になる。スキャンしているのは中綴じの本の前半が主だが、開いて左側のページのほうが大きく傾いてるページが多い。一貫して癖があるのならまだいいが、ときどき大きく傾いたりほぼ水平になったりしている。製本について詳しいわけじゃないが、これぐらい普通で全然問題にならない、のだろうか。

綴じ部分で破れて表紙外れかけのやつは、まずスキャンする記事のない裏表紙側の根元上下をバインダークリップで固定すると楽。気づくまで時間がかかったが。

それにしてもCHARと布袋寅泰の登場回数の多さよ。あくまで印象だが、数号おきに布袋CHAR布袋CHAR渡辺香津美って感じ。そういえば『クロスロード』のリフとか『天国への階段』のイントロ+ソロとかにしても、もう5回ぐらいスキャンしている気がする。『ハイウェイ・スター』は2回ぐらい? 意外だ。

12032558 journal
スポーツ

airheadの日記: memo: メッツ&パイレーツの野球バンザイ 7

日記 by airhead

本題ではないのでプレーの説明は省くが、きっかけは「チャック・タナー・プレー」だった。ずいぶん前のことだが、アメリカでもそう呼ばれているのだろうかと疑問に思って、いろいろ検索してみたことがあった。なかなかそれらしいものが見つからないので、当時広島にいたブラウン監督とリブジーとの間ではそれで通じていただけだろうか、などと思い始めたさなか、新聞記事アーカイブサイトでおかしな試合の記事を見つけた。

そのときは登録せずに試し読みできたように思うが、現在はクレジットカード番号も登録せねばならず、トライアル期間が終わると有料プランに移行で解約には手続きが必要と面倒なことになっているので、今回確認はしていない。だが確か、そのAP通信の配信記事は次のような書き出しだったと思う。

9人の男たちが内野を守った。打者毎に外野手は守備位置を交換した。回が進むにつれ、試合は奇妙な方向へ転がって行った。

外野手を一人内野に回すのは最近の日本のプロ野球でも何度かあったように思うが、「9人内野」ともなると漫画『ONE OUTS』のエピソード以外では聞いたことがない。それ以外にも様々なことが起こったこの試合を記録しておこうと思う。日本球界に縁のあった人も案外いたので、人名はなるべく日本語版Wikipediaにリンクするようにした。1985年4月28日(日)、シェイ・スタジアムで行われたメッツ-パイレーツ戦である。

回を追って記していこう。1回表パイレーツの攻撃。先頭のジョー・オーソラックがヒットで出塁するも盗塁失敗、続くジョニー・レイもヒットで出塁するも牽制死、ビル・マドロック三振と、三人で終わってしまう。その裏メッツの攻撃。先頭のウォーリー・バックマンは一飛に打ち取られるも、そこから単打・四球・四球で満塁としたところでダリル・ストロベリーの6号本塁打、彼にとってはメジャー昇格後初の満塁弾が飛び出す。後続は抑えられて4対0。

あまりにも対照的な1回の表裏である。NYタイムズ紙の記事では日曜日の試合とストロベリーの名とデザートとを掛けたのだろうか、「Super Sundae started sweetly」とも書いているが、試合の雲行きはすぐに怪しくなっていく。1回の後続だけでなくその後もメッツからのヒットが出なくなってしまうのだ。5回裏には四球とエラーで二死一三塁のチャンスをつかむが、結局追加点は奪えない。一方のパイレーツは2回表にジョージ・ヘンドリックの本塁打で1点返すと、6回表には一死からマドロック、 ジェイソン・トンプソンの連続二塁打でもう1点、三振を挟んでトニー・ペーニャの本塁打で、ついに4対4の同点に追いつく。その後も連続単打で攻め立てるも、代打ジム・モリソンが遊飛に倒れてこの回は同点どまり。

こう書くとパイレーツがめげずにヒットを重ねていくうちについに追いついたようにも見えるが、そういうわけでもない。3回から5回まではパイレーツにもヒットが出ていないし、両軍とも時々四球やエラーで走者を出すものの、まるで活かせていない。6回裏をメッツが当たり前のように三者凡退すると、両軍ともこの調子で…いや、7回表マドロックが単打で出塁している。だが、それだけだった。何事もなく7回が終了し、8回などは両軍で示し合わせたかのようなチャンスの潰し方をしている。表のパイレーツの攻撃。四球、6-4-3の併殺、四球、左飛でチェンジ。裏のメッツの攻撃。四球、遊ゴロで一死二塁、敬遠、遊ゴロで二死二三塁、敬遠、左飛でチェンジ。

9回表パイレーツの攻撃。先頭のラファエル・ベリアードが単打で出塁したところで事件が起きる。次打者ダグ・フロベルへの投球前、一塁手キース・ヘルナンデスの、バントに備え本塁方向へチャージしかけた後に牽制球を受けるため一塁に戻るという一連の動作でボークを取られ、走者二塁へ。一塁手に対してのボークという判定にメッツ側が納得するはずもなく、以降メッツからの提訴試合として続行となった。直後の連続四球で無死満塁となったところでジェシー・オロスコが救援登板する。レイを三振、マドロックをショートライナーで二死までこぎつけるが、次打者トンプソンの打席で捕手ゲーリー・カーターが投球を後逸してしまう。ここで三走ベリアードが本塁突入を試みるもカーターが見事なバックハンドフリップで送球、カバーに入ったオロスコにボールが渡ってタッチアウト、無得点。やはりヒットは続かない。

9回裏メッツの攻撃。この回は7番から始まり、9番の投手オロスコにも打順が回る。打順としては最悪だが、一死からラファエル・サンタナがエラーで出塁、一気に二塁まで進む。さらにオロスコの二ゴロの間に三塁に進み、二死ながらもサヨナラのお膳立てができた。しかし1番バックマンが遊ゴロ、延長戦へ。ちなみにメッツは満塁弾の後、一本のヒットも放っていない。

10回表。二塁打と敬遠で一死一二塁のチャンスを作るも次は7番。ここからパイレーツは代打策で勝ち越しを狙う。7番への代打シクスト・レスカーノは右飛。続く代打ビル・アルモンが左前打を放つも、本塁を狙った二走ヘンドリックがタッチアウト。これは両軍合わせて7人目、パイレーツだけでも4人目の代打にしてようやく出たヒットだが、それも実らなかった。この後11回裏まで両軍とも三者凡退を重ねる。

12回表に入り、メッツ監督デイビー・ジョンソンが動く。前の回7番まで打順が巡ったことを踏まえて、7番に投手トム・ゴーマンを入れ、9番にラスティ・スタウブを入れて右翼に就かせた。この時スタウブは41歳で23年目の大ベテラン、もともと上手くない守備に就くのも83年6月22日以来、ほとんど2年ぶりだった。冒頭に記した、打者毎に守備位置を交換した外野手とは彼のことで、この後右打者のときは右翼、左打者のときは左翼に就いた。『Amazing Mets Trivia』なる本の彼の項でも採りあげられ、「ともに守備位置を入れ替えた外野手は誰でしょう?」とある(答え:この時点で左翼のクリント・ハードル)。ゴーマンがパイレーツの攻撃を封じると、試合の流れにも微妙な変化をもたらしたようだ。

12回裏メッツの攻撃。先頭の8番サンタナが単打。メッツ打線としては1回の満塁弾以来のヒットで出塁すると、入ったばかりのスタウブが二塁打を放ち無死二三塁、打順は1番バックマン。何ともあっさりと、絶好のサヨナラ機が訪れる。これに対しパイレーツ監督チャック・タナーの執った策が、スクイズに備えて全ての外野手を内野に配置するという「9人内野」である。残念ながらこの隊形がどの打者まで続いたのか記事やボックススコアには詳しく記録されていないが、バックマンが歩いて無死満塁、レイ・ナイトを6-2-3の併殺、カーターを遊飛と、この絶体絶命の状況を切り抜けてしまった。

これがまた試合の流れを変えたのか、13回以降、両軍ともに凡打の山を築くことになる。唯一、12回裏のお返しとばかりに泥臭い展開になったのが、14回表パイレーツの攻撃。この回は9番、とはいってもスタウブと同じく投手野手の打順を入れ替えての途中出場の、フロベルから上位に巡る打順となる。単打・犠打・単打で一死一三塁としたところで、3番マドロックは三ゴロ、フロベルが本塁を突くもタッチアウト。4番トンプソンの打席でゴーマン暴投で二死二三塁、トンプソン歩いて満塁とするも、そこまで。5番ヘンドリックのファールフライを捕手カーターが(おそらく観客席に身を乗り出して)好捕しチェンジ。その裏の14回裏から17回裏までは、両軍ともに交代もほとんどない。ベンチ入り選手を使い切る寸前での我慢比べだったのだろう、ともにヒット1本ずつという苦行になってしまう。

こうして迎えた18回表、パイレーツの攻撃。流れの変化が不意に訪れる。12回表にマウンドに登ってから無失点を続けていたゴーマンは、二死一塁で久々の代打を迎えた。投手ながら打撃の良さでしばしば代打起用もされていたという、リック・ローデンである。右打者ローデンを受けてスタウブは右翼に就くも、ローデンの放った緩い飛球が右翼線を襲う。一走の長駆ホームインもあり得る場面で「俊足とは言ってもらえないだろうけどね、全力で走ったよ。彼が打った瞬間、絶対に捕ってやるって思った(スタウブ)」。お粗末守備で2年ぶりに守ったスタウブがパイレーツの久々の得点機を、膝下の高さに差し出したグラブで見事に摘み取ってしまったのである。

18回裏メッツの攻撃。両監督とも、この回を最後の山場と見ていたようだ。攻撃が始まる前、タナー監督は守備要員・位置の変更を告げた。先頭のカーターが四球で出塁すると、ジョンソン監督は代走ムーキー・ウィルソンを告げた。ストロベリーが満塁弾以来のヒットで無死一三塁として、6番ハードル、7番は7回零封のゴーマンに打順が巡る。ここに代打を送るべく、ジョンソン監督はジョージ・フォスターに準備をさせていた。「最後の切り札は切ってたよ(ジョンソン)」。というのも、ここでゴーマンに代打を出しても試合を決めきれなかった場合、2日前の同カードで先発し9回完投(完封)していたロン・ダーリングを登板させざるを得なかったのである。

だがまずは6番ハードルだ。彼の放った打球は一塁手トンプソンの正面を突いた。そしてそのまま、トンプソンの股間を抜けていった。メッツが相手でこの大事な場面に痛恨のトンネルエラー、どこかで聞いたような話である。それはさておき三走ウィルソンが還り、ゲームセット。メッツ 5-4 パイレーツ、勝:トム・ゴーマン、敗:リー・タネル、試合時間5時間21分。36,423人の観客をも巻き込んだ大苦行大会は、何ともあっけなく終わった。

ボックススコアで見ると凡打の山の貧打戦にも見えるが、その裏側には両軍の粘りの投球とそれを支えた好守備があり、良い意味での珍采配があった。間違いなく野球の酸いも甘いも詰まった一戦であり、記事で展開を追っていくだけでも面白い。その中でも多くの分量を割かれている12回から出場した殊勲の2人、ゴーマンとスタウブについて、その後も含めて触れておこう。

ゴーマンは6番手として登板し、試合終了までの7回打者25人を無失点に抑えた。彼の個人成績を見ると83年からリリーフ陣の一角に定着していたようだが、この年限りでメッツを去っており、その後フィリーズ、パドレスでの2年間でも目だった成績を残せていない。この登板は彼のキャリアの最後の輝きの一つになってしまったのかも知れないが、記録は残るものだ。2001年、メッツに在籍していたディッキー・ゴンザレスが6回2/3無失点の好リリーフで勝利投手になったときにも「85年のゴーマン以来」と引き合いに出されている。一方のスタウブ、彼のハードルとの守備位置交換は結局11回にも及んだ。一番打球がこないだろう場所へと動かし続けていたところ、ついに難しい打球が飛んでくるも好捕。スタウブの85年の守備機会はこの1回だけで、この年限りで引退した彼の最後の守備となった。

話はそれるが、これについても触れないわけにはいかないだろう。苦労の末に勝利してナ・リーグ東地区首位に並んだメッツだったが、翌日29日のNYデイリーニューズ紙の一面では、ア・リーグ東地区最下位のヤンキース絡みの話題の、オマケ扱いになってしまっていた。NYタイムズ紙によれば大観衆が声援を送るものの「無料のチョコサンデー(おそらく満塁弾のこと)」以外で一番盛り上がったのは、試合中の場内に伝えられたこの速報へのブーイングだったという。

ちょうど同じ28日、ヤンキースのオーナー、ジョージ・スタインブレナーが監督のヨギ・ベラをわずか16試合で解任、ビリー・マーチンを後任としたのである。前日には監督解任を決めていたというスタインブレナーがGMに伝えたのは16試合目のホワイトソックス戦4回途中、1-1の同点の時点とのことだが、ヤンキースはこの試合にもサヨナラ負けして同カード3連敗、10勝16敗で最下位をひた走っていた。

ヤンキースの話で締めるのもどうかと思うので、メッツ-パイレーツ戦に話を戻して、LAタイムズ紙の記事にならってチャック・タナーの試合後の談話で締めよう。30年前の試合を調べなおす気になったのも、これにシビレたからだし。

常に楽観的なパイレーツ監督チャック・タナーは、.224のパイレーツ打線が18本のヒットを重ねていたことを頼みの綱にしていた。

「あれこそ、ひっくり返さにゃならん試合ってやつだな」と彼は言う。「うちはバットが振れていたしね。事が起こる兆しってやつだ。ケチが付いたとしたら、あのスタウブのキャッチだけだろうな。俺はヒットになるって確信したんだけどなあ。あれはまったく、大したキャッチだった。もしこれがワールドシリーズだったら、30年は語り草になっただろうよ。」

6341790 journal
変なモノ

airheadの日記: memo: 「アップルの内部文書」なるもの 1

日記 by airhead

 米アップルが2007年1月にスマートフォン「iPhone」を発表する以前、韓国のサムスン電子とLG電子の携帯電話端末のデザインを参考にしていた事実が米裁判所が公開したアップルの内部文書で明らかになった。米裁判所はこの文書が存在しているにもかかわらず、サムスンがアップルのiPhoneを模倣したと判決している。今後欧州や他の国々での訴訟にどんな影響を与えるか注目される。

 4日に公開されたアップルの内部資料は「3GSM展示会分析」と題するもので、アップルは2006年初めにスペインで開かれた国際見本市「3GSM」に出展されたサムスン電子、LG電子、ノキア、モトローラ、ソニーエリクソンの製品のデザイン、機能を詳細に分析する内容だ。対象品目はサムスン電子「F700」、LG電子「プラダ・KE850」、モトローラ「モトQ」、ノキア「N77」などだ。その翌年、アップルはiPhoneの初代モデルを発表した。

「iPhoneはサムスンのデザインを参考」 アップルの内部文書、裁判所が公開 (朝鮮日報日本語版)

ここに書かれている「アップルの内部文書」は、合衆国連邦地裁カリフォルニア北地区でのアップル対サムスン裁判で裁判所提出された、被告サムスンの証拠 NO. 2627.001-051 と思われる(朝鮮日報の画像は同証拠26ページの一部をモノクロにしたもののようだ)。これがなかなかスゴイ。

表紙(1ページ)左上にアップルロゴがあり、社名 Apple Inc. および機密扱いを示す表示はない。表紙を除く全てのページでは左下にアップルロゴ、右上に「CONFIDENTIAL(機密)」、右下に「Apple Confidential(アップル外秘)」とある。3ページには機密扱いについての注意書きがあり、それっぽいイラストが入っている。個人的にはなんだかこのイラスト、アップルらしくない/大企業の重要文書らしくないように思えるが。

すべてのページに「3GSM World Congress 12-15 Feb 2006 Barcelona」と開催期間が入っている(「月日,年」とする米国で一般的な日付表記順ではない)。が、3GSM World Congress 2006 の開催期間は Feb 13-16, 2006 同2007 は Feb 12-15, 2007 だった。GSMArena.comによる2007のレポートのタイトルにあった単純な編集ミス 「3GSM Barcelona 2007 live coverage GSMArena team, 12 - 15 Feb 2006.」 を丸写ししただけのようにも思える。

内容は技術系メディアが報じるレポートの要約といった域を出ず、機密扱いにする必然性は見られない。9,10ページ全面を占める、荒くて何のプレゼンだかよくわからない画像は、PDFからコピーしてみればわかるが180x135ピクセルの小さなもの。出処は分からないが、どこかのウェブサイトの記事内のサムネイル画像っぽい。

ところどころに業界の2006年の実績と2007年の展望がみられる。11ページにはDRMに関する動きについてまとめてあり、Steve Jobsの「thoughts on music」(Feb 6, 2007) が業界内で大議論を呼んだことや、BBCの Feb 15, 2007 の記事のURLまで書かれている。幾つか抜き出して調べただけで全部調べたわけではないが、サムスンを含む出展各社の製品は2007年発表のもののようだ。2006年2月であれば全く現実味のない「Available Q2 2007, price around 450€(2007年第2四半期に販売開始、予価450ユーロ前後」といった表記もあった。

...ええと、とりあえず、1年後を見事に予見したスゴイ文書! さすがアップル!! ということにしておこう!!!

209439 journal

airheadの日記: memo: Windows 7 の 「最近使ったもの」

日記 by airhead

タスクバー(ジャンプリスト)とスタートメニューの「いつも表示」「最近使ったもの」は共通で、アプリごとに下のフォルダ内のファイルに格納されている。

%AppData%\Microsoft\Windows\Recent\AutomaticDestinations
%AppData%\Microsoft\Windows\Recent\CustomDestinations

この2つのフォルダは、ExplolerではRecentフォルダを開いても見えないが、表示が抑止されているだけで特別な属性は付いてない。dirコマンドでは表示される。Explolerでも上記パスをアドレスバーに入れれば表示される。

それぞれのフォルダに入っている以下のファイルがリスト情報を格納している。ファイル名の16進数がキーとなってアプリごとに対応している。「いつも表示」の項目も拡張子automatic...のほうに入っているようだ。拡張子custom...はWin7対応アプリでのリスト拡張のためだろうか(IE8・WMP・Operaなど)。

16桁の16進数.automaticDestinations-ms
16桁の16進数.customDestinations-ms
(Recentフォルダで dir /s *.*-ms で全表示)

ファイルの属性を読み取り専用にすれば、そのアプリのみリスト項目が無効になるようだ。たとえば読み取り専用で自動更新停止、隠しファイルで無効とするほうが合っているような気がするが、隠しファイルにしても動作は変わらないので、意図せぬ動作かもしれない。再ログオンなどでのExplorer再起動は不要。読み取り専用を解除すると無効前のリスト項目が復帰する。無効時の動作は以下のとおり。

  • スタートメニューの場合
    右向き三角ボタンは残るが、押しても何も起こらなくなる
  • タスクバーの場合
    標準メニューの「アプリ名(起動)」「このプログラムを表示しない」「ウィンドウを閉じる」は残るが、「いつも表示」「最近使ったもの」は表示されなくなる

キーとアプリの対応の調べ方は面倒。リストが更新される操作を行って、ファイルの更新日時であたりをつけて、それらしいファイルを別フォルダに移動して、リストの動作を確認、という手順をとった。もっと簡単な方法があるかもしれないけど不明。以下は手元の環境 Windows 7 Pro X64 で確認したもの。

Explorer
  1b4dd67f29cb1962
EmEditor Free (C:\Program Files (x86)\EmEditor\EmEditor.exe)
  84d2723ef5ccceb8

1b4dd67f29cb1962 でウェブ検索したら関連記事が出てきたので、個別の環境に依存しないようだ。標準的なインストールで一定になる実行ファイルのフルパスのハッシュをキーにしている、とかだろうか。

119320 journal

airheadの日記: memo: リングノードベンチマーク

日記 by airhead

リングノードベンチマーク - どう書く?org から。せっかくなので値の受け渡し方法を変えてみたり(list 1-4, 5, 6、doukaku.orgに投稿したのはlist 4)、いろいろな条件で計測してみたりしたところ、ブラウザの傾向が垣間見えて面白かった。調子に乗って、5回計測して平均を取るまでしてしまった。

(07/12 13:30 追記) list 6を追加

n*m = 1000*1000
          list1   list2   list3   list4
---------------------------------------
FF3.5.0
  old      7521    4264    1670    1608
  new      4262    3369    1459    1403
FF3.5.0 safemode
  old      1936    1077    1311    1346
  new      1805     992    1458    1397
Op 9.64    2047     869     767     615
Op 10b     2003     878     709     631
IE 6      19238    5106    5544    5240 [ms]

Window 2000 + Pen4 2.53GHz

Firefoxにおいて、oldとあるのは現在常用しているプロファイルでの、newは新規プロファイルでの実行結果。常用プロファイルはFireBugなどアドオンが数多く入っているが、FireBugを無効にするだけで新規プロファイルとほぼ同等まで改善する(FireBugのページごとのオンオフのUIで無効にするのではなく、アドオンマネージャでFireBugを無効にする必要がある)。FireBugは他のアドオンのエラーを検出することもあるが、そうした動作が影響しているのかもしれない。

セーフモードではさらに速度が向上するが、この理由はよくわからない。通常モードにおいてアドオンマネージャで拡張・プラグインをすべて無効にしても、セーフモードほどの数値は出なかった。

Operaでは、Firefoxの通常モードの倍以上速い数値が出たが、総ノード数を大きくしていくに従ってのオブジェクト生成の速度低下がFirefoxよりも顕著である(下表create)。ただし一旦生成してしまえば、ノードのオブジェクト呼び出しにおける速度低下はまったくといってよいほど見られない(下表call)。

n*m      5e4*20  1e5*10   5e5*2   1e6*1
---------------------------------------
FF3.5.0 new
  create    143     284    1583    3765
  call     1514    1559    1616    1631
Op 10b
  create    210     462    5281   16750
  call      784     772     781     784

list1-4ではノードを配列に格納しているが、配列の大きさによる影響は思いのほか少ないないようだ。list5のように、参照を張ることのみでオブジェクトを維持して巨大配列の生成を回避しても、速度低下を大きく改善することはできなかった。総オブジェクト数に依存しての速度低下だろうが、100万もオブジェクトを生成することはまれだろうし(200-250MBもメモリを消費する)、問題になることは少ないだろう。

書き忘れていたlist 6を追加した。もっとも素直に実装すればこの形になるかと思うが、オブジェクトにプロパティmsgがつき、若干ではあるがlist 3よりも遅くなる。

119318 journal

airheadの日記: code:ringnode benchmark

日記 by airhead

ノードを表すオブジェクトのメソッド (receive) が次のノードのメソッドを呼んでいくと、関数スタックがたまりすぎてしまう。ここでは配達人役の関数sendを用意し、メッセージを引数としてノードのメソッドを呼び、戻り値として次のノードへの参照と次に渡すメッセージ(通常は引数として受け取ったメッセージそのまま)を受け取る形にした。規定周回数に達したらメソッドreceiveはfalseを返し、それを受け取った関数sendは処理を終了する。

list 1-4で、sendに参照とメッセージを返す方法を変えている。list 1ではreceive内で参照とメッセージを束ねたオブジェクトを毎回生成している。

// list 1
var send = function (dest, msg) {
    var relay;
    while (relay = dest.receive(msg)) {
        dest = relay.dest;
        msg = relay.msg;
    }
    return msg;
};

var Node = function () {
    var id = 0;
    return function () {
        this.id = id++;
        this.dest = this;
        this.receive = function (msg) {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            return {dest: this.dest, msg: msg};
        };
    };
}();

var n = 1000, m = 1000;

var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
    ring[i] = new Node();
    ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;

var t = new Date();
var lastMsg = send(ring[0], "read me in turn.");
t = new Date() - t;

alert("elapsed time:\n" + t + "[ms]\n\nmessage:\n" + lastMsg);

list 2ではsend内でオブジェクトを用意しておき、各receiveがそこに書き込むようにして一つのオブジェクトを使いまわしている。

// list 2
var send = function (dest, msg) {
    var relay = {dest: dest, msg: msg};
    while (relay.dest.receive(relay.msg, relay));
    return relay.msg;
};

var Node = function () {
    var id = 0;
    return function () {
        this.id = id++;
        this.dest = this;
        this.receive = function (msg, relay) {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            relay.dest = this.dest;
            relay.msg = msg;
            return true;
        };
    };
}();

var n = 1000, m = 1000;

// 以下list 1と同じ

list 3では各ノードのメソッドreceiveおよび関数から見える変数で受け渡している。この変数をクロージャによりグローバルから隠蔽しようと、関数sendもノードのメソッドにしてしまった。

// list 3
var Node = function () {
    var id = 0;
    var relayDest, relayMsg;
    return function () {
        this.id = id++;
        this.dest = this;
        this.receive = function (msg) {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            relayDest = this.dest;
            relayMsg = msg;
            return true;
        };
        this.send = function (msg) {
            relayDest = this;
            relayMsg = msg;
            while (relayDest.receive(relayMsg));
            return relayMsg;
        };
    };
}();

var n = 1000, m = 1000;

var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
    ring[i] = new Node();
    ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;

var t = new Date();
var lastMsg = ring[0].send("read me in turn.");
t = new Date() - t;

alert("elapsed time:\n" + t + "[ms]\n\nmessage:\n" + lastMsg);

list 3のようにメソッドsendを全オブジェクトに付加しても呼ばれるのは一つだけでメモリ効率が悪いので、list 4ではプロトタイプで付加するようにした。

// list 4
var send;
var Node = function () {
    var id = 0;
    var relayDest, relayMsg;
    send = function (msg) {
        relayDest = this;
        relayMsg = msg;
        while (relayDest.receive(relayMsg));
        return relayMsg;
    }
    return function () {
        this.id = id++;
        this.dest = this;
        this.receive = function (msg) {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            relayDest = this.dest;
            relayMsg = msg;
            return true;
        };
    };
}();
Node.prototype.send = send;

var n = 1000, m = 1000;

// 以下list 3と同じ

list 5。list 1-4で用いたコメントアウト部のコードに替えて前半部のコードを用い、配列生成を回避した。変数n2が次のノード(新規オブジェクト)を参照しても、一つ前のノードにはさらに前のノードからの参照が残っており、オブジェクトが開放されることはなくリングが形成される。

// list 5

var n0 = new Node();
var n1 = n0;
for (var i = 1; i < n; i++) {
    n2 = new Node();
    n1.dest = n2;
    n1 = n2;
}
n1.dest = n0;
n0.count = m;

/*
var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
    ring[i] = new Node();
    ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;
*/

(07/12 13:30 追記) 書き忘れていたlist 6。各ノードにメッセージを保持するプロパティmsgを持たせ、次ノードへのメッセージ伝達はノード自身が行い、メソッドsendは次順のみを管理する。もっとも素直に実装すればこの形になるかと思うが、list 3より若干遅い。(list 3を書き換えて再現したのでメソッド名と動作内容がかけ離れているが、差異がわかりやすいと思い、そのままにしておく)

// list 6

var Node = function () {
    var id = 0;
    var relayDest;
    return function () {
        this.id = id++;
        this.dest = this;
        this.msg = "";
        this.receive = function () {
            if (typeof this.count == "number") {
                if (this.count == 0) return false;
                this.count--;
            }
            relayDest = this.dest;
            this.dest.msg = this.msg;
            this.msg = "";
            return true;
        };
        this.send = function (msg) {
            relayDest = this;
            relayDest.msg = msg;
            while (relayDest.receive());
            return relayDest.msg;
        };
    };
}();

var n = 1000, m = 1000;

// 以下list 3と同じ

112924 journal
JAXA

airheadの日記: memo: Gizmodo vs Goldman

日記 by airhead

2008年末にGizmodoは、Steve JobsがMacworld 2009の基調講演をキャンセル、理由は病状悪化という噂を伝えた。

これにCNBCのシリコンバレー支局長Jim Goldman、即座に反応した。

(要旨)Gizmodoの報道は大チョンボだが、おかげでApple株に赤信号が点ってしまった。好意的に見てもソース薄弱のブログなど忘れてしまえ。Apple社内の複数のソースによると、Jobsの基調講演キャンセルは健康問題からではない。AppleがMacworldに見切りをつけたことの一環だ。

株価操作のためAppleが嘘をついているなら監獄行きの者が出るだろう。私はそんなものを伝えたくないし、もっと差し迫った健康問題そっちのけでくだらない噂を流したくない。Appleから材料が出てきたら私はそれを信じる。一方、ソース無しのガラクタが自社株を台無しにしたって、そりゃそうだと言うしかない。

ところが2009年に入ってすぐ、Jobsが噂を認めるリリースを出す。

さらには、Jobsが6月まで療養を優先するリリースを出す。

するとGoldmanは、今度はAppleに矛先を向けるのである。

私は過去数ヶ月間、Jobsの健康問題を追ってきたが、カルテを見られるわけではないし病状の重さを追っているのではない。ではなく、Appleが出す材料、彼がCEOとして会社を動かせるかどうかの情報に見ることができる、Appleの与信上の責任を追っているのだ。基準はまったく単純、動かせるか否かだ。彼が瀕死でも何とかやっていけているなら、理屈の上ではAppleは、彼の健康にまつわるプライベートな詳細を明かす必要がない。これは法的には申し分ないが、倫理的にはそれほどでもない。Appleがやったのはそういうことだ。

精密検査をやったらホルモンバランスが崩れているのがわかった、それからたった一週間で、健康状態が思っていたより複雑だったとわかった(ので6月末まで療養する)という。疑い深くて悪いが、良く言っても「率直でない」、悪く言えば「誠実でない」ように思える。与信・倫理・財務面での仕打ちに等しい。

実は先週末、Jobsと非常に親しい業界内の重役二人からの情報を受けていた。うち一人は数ヶ月前まで定期的に連絡を取り合っていた人物だ。どちらも他意はなく、Appleの株価操作をもくろむような者じゃない。どうか信じて欲しいがどちらも相当な金持ちだ。驚いたのは、どちらもJobsの健康状態に「深い懸念」を抱いて私に話さずにはいられなくなった、ということだ。一方は長年の付き合いから、Jobsが状況の悪化について「断固拒否」している、という。もう一方は「深い懸念」を抱いており、突然連絡が途絶えてメールや電話などにも返答しなくなったのは「深刻な」状況の現れだ、という。

どちらもJobsの治療について直接知っているわけではないが、それまでの付き合い、Jobsの言っていたこと、最近のJobsの振る舞いから判断をしていると言っていた。

この月曜に私はJobsにこの件について、ごく個人的に記して送った。返答はなかった。Appleの誰かさんから、例の重役たちとJobsの健康問題に関して私が何をやっているのかと訊いてくる電話は受けた。私はこの人物に、Jobs宛ての電子メールを読んだのならわかるはずだと答えた。私はAppleに、我々は更なる情報収集に努めるつもりで、AppleおよびJobsに返答を検討するための機会を与えようと考えていることを伝えた。それが昨日(火曜)の事だ。もう少し時間を与えたかったが。Appleは、同じように近しい社内の者で私に打ち明ける者が出始めたら、彼らや他の者までが私以外の者に対しても話し始める可能性は大いにあることに気付いたに違いない。

我々がAppleの手を動かしていたとは言わないが、ほんの一週前に「これについて、言いたかったこと、そして言おうとしていたすべてのことからすれば言い過ぎてるくらいなので、このあたりで」と簡潔に締めくくる別のリリースを出していたことを考えればなおさら、我々が今夜のリリースにわずかながらも荷担していたと思わざるを得ない。今にして思えば、彼にはもう少し、周りの者が彼に言い出す前に言いたいことがあったのだ。

それはともかく、彼の健康状態は動く標的のようなもので固定しておくのはかなり難しいはずだし、2004年の最初の診断から変化・進行していてもおかしくない。Jobsが変調に気付かなかったと言ったとき、彼はそれが事実に基づいたものとして疑わなかっただろう、と思う。それが最近まで続いていた、精密検査を受けて初めて医師たちが変調に気付いた、そのようにJobsが言うなら私は信じる。Jobsの健康状態がどんなものにせよ変わり続けるものと言うソースがあれば信じてきたし、今も信じ続けている。

私がひどく手を焼いていることは何かといえば、今週これまでに起こったことに他ならない。先週の記述は真実かもしれないが、私は、今週の彼の記述を信じるにあたっては重大な問題を抱えている。そこには不誠実の気配以上のものがある。クパチーノをまっすぐに狙ったメディアミサイルの存在を確認しても、噂の後手に回って掃討するのではなく先んじて公表に努めていて、そのうえでの記述であれば私も信じた、原因はそういったことだろう。すべてに関するAppleの戦略は最初から、妙なものだった。すべての中心にあれほど気まぐれな男がいるとなれば、それほど驚くにはあたらない。

私はもう、白日の下にさらすことがすべての雑菌を殺すと信じるしかない。同社がすべきだったことはただ一つ、最初からすべての者に正直にあれば良かったのだ。我々が知りたいことを語るのではない。ではなく、我々が知る必要のあることを語るのだ。Appleはこの分野の先駆者になり、透明性の新領域に火を点すことになっていたかもしれない。ではなく、別の道を選んだ。そのツケを払うのは、株主、ファン、Appleコミュニティだ。

これはまったく残念だ。私は、Jobsが言うように彼が6月に復帰することを心から願う。しかし現実的になれば、彼が他になんと言おうとも、私はそれを当てにすることができない。

なんというか、苦しい。CNBCのニュースショーでも「健康問題は動く標的のようなもので... 精密検査をしたら...」などと弁明するも、偽Steve JobsをやっていたNewsweekのコラムニスト、Daniel Lyonsに「とにかくGizmodoに謝れよ、視聴者に謝れよ」と叱責され、案の定だがGizmodoにも再度突っ込まれる。

話は若干それるが、Goldmanはその後、Gizmodoのイジられ役になってしまったようだ。

で、6月末。Jobsが肝臓移植手術を受け、復帰も近いと報じられるようになったタイミングで、期待を裏切らない男Goldmanが、今度は手術に投げかけられた疑問を採り上げる――のが表のストーリーの元記事。ところで「Tech Check」か? これ。

typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...