目次
前のページ
2011-04-18 難しい見積もり
2011-04-21 情報の扱い
2011-04-22 「戻る」ボタン自由自在
2011-05-31 Smalltalk,Squeak, Etoys, and Scratch!
2011-06-06 PC購入
2011-06-08 ひきつづき新PCの話題
2011-06-16 続々・新ＰＣのこと
2011-07-08 obsmtp.com
2011-08-24 クラウド
2011-08-24 Picasa WEB
2011-08-30 ブログパーツラッパー
2011-09-05 メールアドレス隠蔽の戦略
2011-09-26 節電終了
2011-09-28 Location ヘッダと 302 ステータス
2011-10-07 PHP でデーモンを作る。
2011-11-16 tcc
2011-11-17 バックアップとデフラグ
2011-11-24 デフラグ考
2011-11-25 しつこくデフラグ話
2012-01-23 ゲームボーイの CPU
次のページ
長年プログラマをやっているが、見積もり作業と言うものが難しい。
…というか、プロとしてこんな事を言うのはどうかと思うが、はっきり言ってやり方がわからない。
プログラマではない方には関係のない話と思うが、暇ならお付き合いを。
プログラマで独立したいと思っている人は、他山の石として読んでいってください。
独立プログラマの仕事と言うのは、まず相手から「こんなプログラムが欲しい」と依頼されるわけだ。
この時点で、要求は漠然としている。場合によっては、自分が何を求められているのかすらわからないことがある。
でも、相手は言うのだ。「どれくらいで作れますか？」と。
ここで「どれくらい」には２つの意味がある。日程と金額だ。
この２つは無関係ではないが、独立している。でも、相手はそのことすら知らない。だから「どれくらい」という曖昧な言い方になるのだ。
自分が似たようなものを作ったことがあるなら、ある程度勘が働く。
でも、そればかりではない。そういう時は、細かな作業工程を想像し、積み重ねて概算を出さなくてはならない。
ところが、ここで矛盾が生じる。相手が依頼している内容が漠然としているので、細かな作業工程など出せないのだ。
かくして、まずは作業内容確認のカウンセリングから入ることになる。
本当に欲しい機能はなんなのか。どういう状況で使おうと思っているのか。必須機能はどれで、あれば便利だと思っている機能はどれなのか。
大抵はお客様は何らかの業務で思い悩み、コンピューターの力を借りれば解決できるのではないかと考え、どうすれば良いのかの方策を考えてから「プログラムは作れるか」と相談に来る。
しかし、プログラムの専門家ではない人が考えた「理想のプログラム」は、実現不可能な要求を盛り込んでいることが多い。
そこで、依頼以前の、業務の何で思い悩んでいるのか、と言うところにまで立ち戻って話をして、本当に必要としているプログラムはなにか、と言うところから一緒に考えなくてはならないのだ。
ともかく、いよいよ作られるプログラムの「要求仕様」が固まったとしよう。
この時点で、要求仕様は実現可能であることが前提だ。
「いい人材を見分けるプログラム」なんてものは実現不可能だが、アンケートや簡単なゲームを通じてなら、適正を見極めることができるかもしれない。
そういう、具体的方法論にまで踏み込んだものが「要求仕様」だ。
さて、これが「どれくらいで」作れるかを答えなくてはならない。
でも、これが実のところ、不可能なのだ。
個人で仕事を始めてから、初期の頃には荒見積もりを出すことの難しさに悩んでいた。
結局決めかねて「いい加減な嘘をついて」それらしい見積書を作るのだが、良心の呵責があった。
でも、プロジェクト進行について書かれた専門書なんかでも、この「荒見積もり」は不可能だ、と言うことが明記されているのね。
だから、大企業でもそれらしい嘘をつく。
作業に入る前に工程表を作ることなんてできない。
これは、プログラムに限らない。単純プロジェクトならともかく、ちょっと複雑なプロジェクトでは、全てそうなのだ。
特に、誰も経験したことがないはじめての作業を行う時には、工程表なんて絶対にまとめられない。
でも、それでは困る。見通しがたたなければお客様は発注はできないし、結局は自分にも仕事が来ず、お金が入らないのだ。
だから、嘘でいいから工程表を書く。それらしく書く。
まず、思いつく限りの細かい工程に全体を分解する。次に、それぞれの工程が「順調に行けば」どれくらいの時間で終わるかを見積もる。
ここでの見積もりは、間違えたって構わない。
初めての仕事だから難しそうだ、と思っていたものが案外簡単だったり、過去に似たものを作っているからすぐできるだろう、と思っていたものが、前提条件の違いで想像以上に苦しんだりする。
作業工程はできるだけ細かく分解しているが、実際に作業してみると想像外の作業が発生したりもする。
でも、細かな作業工程の個々の見積もりが間違っていたとしても、全体を通せば平均化される、と期待して見積もる。
ともかく、一度全体を「順調に行けば」どれくらいの時間で作れるか、を算出することが重要だ。
順調に行った場合の時間見積もりが出たら、これを１０倍する。
…いきなりそんな、１０倍なんて乱暴な。
そう思う人も多いだろう。当然だ。
僕も独立した頃は、何倍かに見積もらなくてはならないことはわかっていたが、何倍にするのが妥当なのかわからなかった。
３倍？ ５倍？ でも、経験則から言えば、５倍くらいの見積もりでは苦しいばかりで割に合わない。
答えは、ちゃんと古い本に書いてあった。「人月の神話」に、少なくとも９倍せよ、とある。
理由は簡単。
まず、技術者は、作業見積もりを出す時に技術面の難題を中心に考える。
実際には、難題以外にも、細かな作業が多数ある。それらは、難しくはないが時間がかかる作業だ。
そして、実はこうした作業の方が全体の中での比率は多く、難題部分に多くの時間が取られたとしても、その２倍は「簡単な部分」の作業に必要なのだ。
だから、簡単な部分も作るためには、時間を３倍して考えなくてはならない。
次に、技術者は技術面以外の事を考えない。
技術的に動くプログラムができたとしても、実際にはそれを「使いやすく」まとめる作業も必要だし、マニュアルなどを整備して、誰が見ても使える状態にする作業がある。
これらの、プログラムの本質ではない作業は、実のところプログラム本体の作業よりも長い時間…２倍はかかる。
だから、「動くプログラム」を「製品として使えるプログラム」にするのには、時間を３倍して考えなくてはならない。
結果、最初の見積もりの少なくとも９倍が、実際に作業に必要な時間だ。
僕は、計算のしやすさもあって１０倍を目安に考えている。それが、先に書いた１０倍の意味だ。
「人月の神話」では古すぎる、今はもっといい算出方法があるはずだ、と言う人もいるかもしれない。
でも、比較的新しい「デスマーチ」にも、今でもこの方法が有効だと書かれていることも追記しておく。
（デスマーチも、すでに古典ということにされてしまっているらしいが…）
本質的な問題として、作業工程を見積もる方法なんてない、確度の低い見積もりに安全係数（ここでは１０倍）を掛ける方法以外ないのだ、と知っておかなくてはならない。
初めて見積もりを書く、駆け出しの独立プログラマーは、ここで安全係数を掛けない見積もりを出して、全然割に合わない仕事をしたりする。（自分の過去の失敗談だ (^^; ）
作業時間が算出できれば、金額も算出できる。
１日は８時間労働、なんらかの専門家の日当は通常５万円なので、単純に計算すればよい。
１週間は５日間なので、それで計算すれば納期も算出できる…
ことになるが、それは少し伸ばした方が良い。
1.2倍にするか、1.5倍か、思い切って２倍か…は、人による。僕の場合、複数の仕事を同時に抱えることもあるので、先方に納得してもらった上で２倍の日数をもらっている。
しかし、実際にはこの日数は「保険」でもある。
先に書いたように、作業に入る前に作業工程を見積もることが、そもそも不可能なのだ。
最初に見積もった作業工程を１０倍することで、「想像外の作業」の発生は大体吸収できる。
でも、それらの想像外の作業が困難の連続になったとしたら？ ここで、納期を長めに取ることに意味が出る。
もし困難が多ければ、長めにもらっていた納期日数の中で収拾がつけばよい。
長めにもらった分については、金額を発生させていない。だから、ただ働きだ。
しかし、それは自分が見積もりを失敗した結果なのだから、甘受しなくてはならない。
逆に、想像以上に仕事が早く終わる場合がある。それは自分が優秀なのだから、お金は有難く頂戴すればよい。
いずれにせよ、見積もりと言うのは「お客様にとっての」保険に過ぎない。
見積もりで出した日数内に終わり、金額も見積もりどおりなら何の問題もないのだ。
余りにも困難で当初の納期に間に合わないとか、十分実現可能と思っていた要求仕様が、実は矛盾があって作成不可能だった、と言う場合もある。
そういう時は、問題の発生がわかった時点で、すぐにお客様に連絡。丁寧に事情を説明すれば、普通は納得していただける。
追加作業が必要だから金額を上げて、については了承されない場合が多いが、矛盾があるから仕様を変更したいとか、納期に間に合いそうもないから一部機能をカットしたい、など、交渉の方法はいくらでもある。
工程表を最初に作り、あとは何の状況も説明せず、では、最後になって「言っていたことと違う」という論争になりかねない。
できることなら、定期的に現在どの作業を行っていて、どこまで出来ているかを報告するのがよいだろう。
全体に遅れているのなら、素直に早い段階で「遅れています」と言われていたほうが、納期が来てから「出来てません」といわれるよりも良い。
完成していなくても、途中経過を時々見てもらうのも効果がある。
思ったものと違っていた、など早く気がつけば修正も楽だし、それがお客様側からの要望で当初予定とは違う修正になる場合は、追加料金をもらえる場合だってある。
途中からの修正の場合、実は遅れている工程がある場合には、その遅れ分も「修正に必要な時間」に内緒で入れ込んでしまって納得してもらう、というようなテクニックもある。
…と、急にプログラマーの仕事の一端を書いてみたが、これはプログラマに限った話ではない。
最初に書いたとおり、ちょっと複雑で、誰もやったことがないようなプロジェクトであれば適用可能な話なのだ。
東京電力が、福島第１原子力発電所の事故を収拾するための工程表を発表した。
早速、遅すぎるとか、本当にこの通りに実行できるのか、等といった批難が相次いでる。
先に書いたとおり、やったことがない作業の工程表など作れない。実行期間の正確性など、保証出来るわけがない。
しかも、今回の作業工程表は、実際のところ作業内容すら見えていないのだ。
「漏水を止める」と言っても、どこから、どのように漏水しているかもわからない。
つまり、プログラムで言えば要求仕様もまとまっていない段階で作られているのだ。
それでも、作ったことに意義はある。それは、作成依頼に対する「荒見積もり」と同じで、ある程度の概要を示すことが出来るからだ。
今後、作業が遅れそうなら、素直に遅れると、理由を説明して発表すれば良い。
もちろん、未知の作業に対して十分な余裕は見積もって工程表を作っているだろうから、前倒しになる作業もあるだろう。
実際に作業をされる方々には、幾多の困難が予想される。
見守るしかない我々としては、作業が前倒しになったり、遅延したりするのに一喜一憂していてはいけない。
作業工程表とは、もともと「その通りには行かない」性質のものなんだと理解しておくことが重要だ。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
spam に困っている人は多いと思う。
あれは食べ過ぎると太るしね。スパむすびおいしくて困っちゃう。
…というボケは置いといて、いわゆる「迷惑メール」のことね。
ホーメルフーズ社は、同社の商品である肉の缶詰は SPAM 、迷惑メールはspam と書けと言っているので、ここでは「spam」の話をする。
最初のボケを書いたせいで、何の話かわからなくなってしまった。
えっと、つまり「情報の扱い」の話をしたい。
spam を分類するのにベイジアンフィルタが有用だ、というのは多くの人が聞いたことある話だろうし、既に使っている人も多いだろう。
ベイジアンフィルタって何？ と言う人でも、Gmail を使っていれば自動的に適用されているし、メーラーに内蔵されているような場合もある。
あれがベイジアンフィルタなんて呼ばれていること自体、確率を真面目に研究している人からは怒りの対象らしいし、そうでなくてもよく使われている「確率式」が、素人目に見てもおかしなものだったりするのだが、ともかく実用上は動作している。
＃一応、仕事でベイジアンフィルタ自作してみたりもしたことをお断りしておく。
ところで、ベイジアンフィルタは、メールが「何かである確率」を出してくれるに過ぎない。
普通は、spamである確率を出す。これは学習型フィルタなので、学習次第でどんな確率でも出せる。
友達から来たメールである確率、会社から来たビジネス文書の確率、似たような「おすすめ商品のお知らせ」でも、自分が好きそうな商品か否かで分類することだって可能だろう。
でも、それはあくまでも確率だ。明確に分類できているわけではない。
そこで、ある程度の確率のところに線を引き（閾値と呼ばれる）、それを超えた場合に「spamである」などと断定する。
ここで問題になるのが、今回のテーマである「情報の扱い」だ。
閾値をどこに引くのが適切なのか？
spam である確率が 0% であれば、spam ではないだろう。
100% であれば、誰がなんと言おうと spam である。
では、60% なら？ 70% 、80% では？
どちらかといえば spam 寄りなのだから、spam として扱うべきだろうか？
実のところ、spam 扱いしてもよいのは、spam である確率が 90% 以上など、飛びぬけて高い場合のみである。
なぜなら、spam 扱いするということは「見ないで捨てる」可能性が高くなるからだ。
メールを見た結果、spam を見つけてうんざりする方が、重要なメールを見ないで捨ててしまうよりも良い方法なのである。
spam に限らず、膨大な情報を処理し、一部だけ抽出して後は捨てる、と言うことは日常で普通に行われている。
この際、情報を捨てた結果どうなるか、拾った結果どうなるか、情報の中身に応じてよく考えた上で扱いを決めなくてはならない。
５年間しまいこんであった箪笥の中の服を整理するのであれば、基本的に捨てる、という方針で臨むことが正しいだろうし、癌検診の医師は少しでも異常があれば拾って再検査に回す、という方針で臨むことが正しいだろう。
情報の扱いとは、画一的に方法が決まるものではない。
正解はないが、その状況によって正しい方法を熟考し続けないといけない性質のものである。
と、急にこんな事を思ったのは、携帯に溜まった緊急地震速報の履歴を追ってみたから。
…なんだ、また大震災がらみの話か、とお思いの人もいるだろう。申し訳ない。
2010年9月29日の17時00分に、関東地方の携帯電話向けに緊急地震速報が通知された。
福島県で地震発生、との内容だった。
＃改めて確認したら、福島だったのね…。後知恵だが、予震だったのだろう。
これ、FOMA が「普及期」に入ってからは初めてだったこともあり、結構話題になった。
僕も初めて受信したので驚いた。
でも、実際には大きな揺れは観測されなかった。
これは「速報」という性質上仕方のないことだったと思う。
地震、という、生命を脅かす危険のある情報の扱いとしては、僅かでも確率があるならば、拾った方が良い情報なのだ。
福島で地震があった、と言うのは事実だ。その地震から僅かな時間で、地震の影響範囲を計算し、影響が強いと予想される範囲に対して警告を行う。
しかし、この範囲は「予想」でしかない。結果論として、関東で揺れはほぼ観測されなかった。
関東で観測されなかったとしても、福島で大きな地震があった、という事実は変わらない。
なのに当時、「誤報だ」として気象庁が叩かれた。マスコミに叩かれたのみならず、政府にも見直しを命じられ、実際に「速報をあまり出さないように」システムが改変された。
その結果どうなったか。
2011年3月11日の震災本震発生時には、東北地方のみが通知範囲とされた。
関東北部は、緊急地震速報の想定する「震度３以上」を観測したが、通知範囲外だった。
ちなみに、この２日前の 3月9日午前11時45分にも、宮城で震度５弱を記録しているが（これも予震だったのだろう）、緊急地震速報はでていない。
（関東に、ではなく、警報そのものが出ていない）
生命にかかわる情報は、誤報といわれようがなんだろうが、通知しなくてはならない。
昨年９月の緊急地震速報を、誤報だと叩いた人間は（マスコミに限らず、全ての人は）深く反省しなくてはならない。
この震災で、ネットワーク化された地震計などの設備が損傷し、復旧に至っていないため、十分なデータが得られない状態が続き、緊急地震速報に「誤報」が多くなっている。
…と、少なくとも公式には、気象庁はそう説明している。
ネットワークが寸断されたのも、地震計が壊れたのも事実だろう。
そのためにデータが十分でなく、予想が難しくなっているのも事実だろう。
しかし、それは単純に「誤報が多い」ことには繋がらない。
単にデータが足りないだけなら、緊急地震速報の発報が行われない、となることの方が多いはずだ。
（緊急地震速報は、速報性を重視しているため、最初の１つの地震計の揺れで発報する。しかし、近隣の地震計が揺れなければ、即座にキャンセル報が出される。つまり、ネットワークが寸断されれば、キャンセルだらけになるはずだ）
現在の状況では、強い余震が警戒されている。しかし、観測体勢が十分ではなくなっている。
となれば、システムのパラメータを改変して、情報の扱いを「疑わしければ拾う」側に寄せてあるのではないか、と推測する。
つまり、気象庁が言うように、単純なシステムの不具合ではなく、不具合を修正できない状況下においても、最悪の事態を防ぐ方向で、わざと誤報を増やしてある、ということだ。
これは推測に過ぎないが、情報の扱いとしては正しい。
先日、緊急地震速報が発報された直後に twitter を（厳密に言えば buztter を）見ていたら、「誤報が多いので、通知しない設定に切り替えた」と言う人が沢山いた。
これは、情報の扱いとして正しくない。
緊急地震速報は天気予報のような「予報」ではなく、確実にどこかが揺れたことの「速報」だ。
たとえ速報値による推測が間違っていて、自分が住んでいる地域が大して揺れなかったとしても、軽く見てはならない。
次の警報では、致命的な揺れがくる可能性がある、と常に警戒していないといけない。
どんな状況においても、情報を正しく扱うことは、自分の身を守る第一歩だ。
…と、強く思っているからなのだが、誰が読むかもわからない日記に、最近「情報の扱いの話」ばかり書いている気がする。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 自体：事態の表記違い、他ページも含めて指摘ありがとうございます。修正しました。 (2015-04-07 12:03:02)【校正エージェント】 「…なんて呼ばれていること事態、」 (2015-04-05 10:52:01) |
WEB の CGI プログラミングの話。
単に WEB ページを見せるのではなく、わざわざ CGI を使用している場合は、状況によって表示する内容が刻々と変化することが多い。
この「刻々と」は、つまり「ユーザーの操作によって」の意味である。
ユーザーの操作は積み重なっていくが、データが少ないうちは、URL にデータを入れ込んで置けばよい。
ところが、データが多いとそれは無理となる。
この場合、サーバ側にデータベースなどを持ち、URL には、そのデータベースのアクセスに必要な最小限のデータだけを持っておくことになる。
この場合、問題となるのは、ブラウザの「戻る」ボタンを押されることだ。
データベースには常に最新のデータしか保持されていないのに、ユーザーが閲覧するページには古いデータが残っている状態となり、データの不整合を起こすのだ。
多くの CGI プログラマーが、頭を悩ましている問題である。
解決策の１は、戻るボタンを押したらエラーを出すことである。
データベースには、常に更新されるチェックデータを用意しておき、URL の一部としてこのチェックデータを入れておく。
最新のページからアクセスがあった場合は、URL に入っているチェックデータと、データベースのチェックデータが一致する。
しかし、一致しなかった場合は「エラー」とする。
これで、戻るボタンが押されることでデータの不整合がおきる、と言う問題を回避できる。
めでたしめでたし。
…この方法の問題点は、WEB ページにとって「お客様」であるユーザーに、非常な不便を強いることだ。
ブラウザの「戻る」ボタンは、非常に使われる頻度の高い機能である。
使わないつもりでいても、うっかり押してしまうこともある。
そして、エラーが表示されるのだ。
これはページを見てくれる人を追い返すには十分。
最悪の解決方法である。
解決策の２は、戻るボタンを消してしまう方法。
JavaScript を使用して新しい window を開く時に、ツールバーを「表示しない」ようにすれば、戻るボタンは消えてしまう。
消えれば押されることもないわけで、解決。
…これも、解決策１とたいして変わらない。
うっかりエラーがでて最初からやり直し、という最悪の事態にはならないが、「戻る」ボタンが使えないという不便を強いることに違いはない。
それどころか、「戻る」以外の機能も全部巻き添えで使えなくしているわけで、ユーザーに大変な不便を強いることになる。
解決策３は、Javascript で戻るボタンを無効化する方法。
<script>
history.forward();
</script>
を全てのページのヘッダ内に書いておくだけ。
これは、「履歴の次のページにすすむ」というプログラムである。
通常のアクセスであれば、これが実行されても「次のページ」は存在しないため、何も起こらない。
しかし、戻るボタンが押されて開かれたページでは、次のページが存在するため、より新しいページに進む。つまり、最新ページが常に表示された状態で固定される。
結果、戻るボタンは表示されているが、機能的には無効化されている。
ユーザーの不便は最小限かもしれないが、「戻る」という重要な機能を失っていることに変わりはない。
以上３つの解決策が「悪い解決方法」なのは、戻るボタンの歴史的意義を理解していないためである。
WWW 開発以前にも、ハイパーテキストは存在した。
そして、ハイパーテキスト研究の重要問題の一つが、「迷子問題」と呼ばれるものだった。
ハイパーリンクは、テキストに対する説明や、関連話題として示される。
そこで興味を持ってリンクを辿るうち、元のテキストに帰る方法がわからなくなる。
…単純に言って、これが迷子問題である。
これに対する初期の解決策が、「戻る」ボタンであり、現在ではハイパーテキストの閲覧に必須と言ってよいほどの機能となっている。
だから、戻るボタンの機能を無効化してはいけないのだ。
無効化することは、つまり「テキスト閲覧お断り」を表明しているに近い。
閲覧して欲しいからページを作っているはずなのに、本末転倒である。
昔を懐かしむわけではないが、携帯電話向けに策定された HDML では、「戻る」ボタンに自由な機能を割り振れるようになっていた。
先に書いたように、「戻る」ボタンはハイパーテキストの閲覧に必須の機能であり、無闇な書き換えは推奨されない。
しかしまた、HDML では「戻る」は、直前に閲覧したページに戻る事を意味しなかった。
複数のページを「機能的なひとまとまり」として定義する方法があったため、「戻る」ことにより機能を途中で抜け出したり（機能に入る前のページに戻る。時には数ページ前となる）、正常に完了した機能のページは「戻る」の対象から外されたりした（完了した機能内のページには戻れず、その機能の前のページに戻る）。
つまり、HDMLにおいては「戻る」とは、直前のページではなく、ユーザーが「戻りたい」と思う場所に適切に戻るための機能だったのだ。
そして、この方針に従う限り、「戻る」ボタンによって新たなページを読み込むことも許容されていた。
戻るボタンの機能を書き換えるとき、機能を「無効化する」ような書き換えを行うのではなく、WEBページ提供側に対しても、閲覧側に対しても許容できる箇所に戻るように気を使わなくてはならない。
というわけで、今回仕事で必要だったので開発したテクニック。
戻るボタンの機能を書き換え、指定された特定ページに進ませる。
注意点として、先に書いたように、閲覧者が違和感を感じないようなページ遷移にすること。
少なくとも、戻る機能を書き換えたことで袋小路に迷い込んだり、来たこともないページに飛ばされたりするのはよくない。
仕掛けとしては、解決策３で示したスクリプトの拡張にすぎない。
解決策３では、「次のページがある（戻るボタンで戻った）ときは、強制的に次のページへ」進むようにしていた。
これを、「戻るボタンで戻ったときは、最新のページで指定された URL へ」進むようにする、というだけ。
とはいえ、単純ではないので、まずは説明から。
まず、問題なのは「最新のページで指定された URL 」という部分。
基本的に、JavaScript はページ（ドキュメント）の中で完結して動作するため、変数などでデータを受け渡すことはできない。ページ遷移が行われれば、変数が破棄されるのだ。
そのため、最新のページで指定された、という「指定 URL データ」をどう渡すのかが問題となる。
とりえる方法は幾つかあるが、ここでは window.name を使う。
window.name は、ドキュメントの入れ物である「ウィンドウ」の特定に使われるものであり、ページ遷移してもデータが破棄されない。
これは、ページ間のデータ受け渡しに使用できる。
つまり、最新ページでは、読み込まれた際に window.name に、「指定 URL」を書き込む。
「戻るボタン」で戻られたことを検出した際には、この指定 URL に飛ぶようにプログラムを書く。
これで、「戻るボタンを押したら指定 URL に進んだ」ことになり、目的は達成できる。
しかしここで別の問題が発生する。「戻るボタン」で戻られたことは、どうやって検出するか？
JavaScript にできることは、「ページを表示する際にプログラムを実行する」ことだけで、その表示理由が、読み込まれたからなのか、戻ってきたからなのかは判らない。
ここでもまた、window.name が活躍する。
ページが読み込まれる毎に増加する値を JavaScript 内に用意しておき、プログラム実行の最後に、window.name の中にも書き込むのだ。
window.name への書込みよりも以前に、この値を比較すれば、プログラムの実行理由が判る。
・JavaScript 内部の値よりも、window.name の値のほうが古い
→ページは新たに読み込まれ、表示された。
・JavaScript 内部の値よりも、window.name の値のほうが新しい
→「戻る」ボタンによりページが表示された。
単純に増加していればよいので、unixtime でも十分だし、アクセスカウンタがあるならその値を利用しても良い。
基本戦略としては、以上で終わり。非常に単純な話だ。
プログラム的には、window.name は１つしかなく、書き込みたいデータは２つあるので、文字列の連結・分割が必要となる。
カウンタは数値、url は文字列だが…両者とも「空白」（ASCII 20h）は含まない、という決まりがあるので、空白で分割できるようにするのが、おそらく一番簡単だろう。
プログラムは以下のようになる。
（CGI 側で、$time $backurl の部分に、適切な値を埋め込んで JavaScript プログラムを生成すること。
$time は unixtime 、$backurl は、戻るボタンが押されたときに進みたい URL が設定されている）
var p = window.name.split(' ');
if(p[0]>=$time) location.href=p[1];
window.name="$time $backurl";
たったの３行だ。解決策３の中央の１行の代わりに入れること。
（つまり、script タグで囲んでヘッダ内部に入れること）
実は、これだけでは FireFox で動作しない。
FireFox では、「戻る」ボタンで戻ってきた際には、JavaScript が動作しないためだ。
JavaScript が動作しない理由は、「最初に表示された時に JavaScript によって変化したデータを保持している」ためである。
再表示の際には、すでに JavaScript プログラム適用済みのデータを表示して高速化しているのだ。
しかし、onUnload という機能が設定されている場合は、この限りではない。
onUnload は、ページの表示を終了する時に JavaScript を動作させるための仕組みである。
この機能が設定されているということは、ページのデータは「再表示するのに適切でない」可能性があるため、初期状態のページから再度 JavaScript を起動させる。
というわけで、FireFox 対策に、次の１行を挿入する。
window.onunload = function(){}
以上の合計４行で、事実上「戻る」ボタンの機能を再定義したことになる。
window.name は、便利なので様々な Hack で使用される。
そのため上のテクニックが利用できない場合には、代替手段として以下のような方法もとれるだろう。
・Cookie を利用する。
ページ間のデータ通信さえできればよいので、Cookie を使ってデータを保存しても良い。
ただし、セキュリティのためにブラウザが Cookie を受け取らない設定になっていたり、プログラムがガジェットとして Frame 内で動作したりする場合に使用出来ないこともある。
また、JavaScript で Cookie を扱うのは「可能だが結構面倒」なので、プログラムが無駄に長い。
var p = document.cookie.split(';');
var v;
for(var i in p){
if(p[i].replace(/^\s+/,'').substr(0,2) == 'c='){
v = p[i].replace(/^\s+/,'').substr(2,999).split(' ',2);
}
}
if(v[0]>=$time) location.href=v[1];
document.cookie="c=$time $backurl";
・webStorage を利用する。
webStorage は、新時代の Cookie である。
Cookie の欠点がいろいろと解消されている一方、使用できるブラウザが限定される。
var p = sessionStorage.c;
if(sessionStorage.c>=$time) location.href=sessionStorage.u;
sessionStorage.c=$time;
sessionStorage.u="$backurl";
自分は仕事の都合でこの方法を編み出したのだが…仕事上の制約でいろいろ使えない機能もあったので、代替手段も一緒に開発することになってしまった。
基本戦略さえ理解してしまえば、他にも代替手段はあるのかもしれないが、自分は３つの方法を編み出した時点で「仕事上問題がなく使える技術になった」ので、ここで終了となった。
以上。
せっかく考えた技術なので、誰にも教えないで内緒で使いたいところだが、どうせ JavaScript なので、ソースを見られてしまえば何をやっているか一目瞭然なので公開した。
以上の話、３月１１日の日記に書こうと思って準備中だった原稿である。
その後、なんとなくアップロードするタイミングを失っていたのだが、今思い出してファイルを見直したら、書き終わっていたようなのでアップする。
推敲中だったと思うのでどこかおかしいかもしれないが、何を書き直そうとしていたのかも忘れた。
地震直前に書いていた、なんてことは忘れていたのだが、ファイルのタイムスタンプを見たら、作成が3/11 13:00:13 、最終更新が 3/11 14:13:05だった。
閲覧する方にはどうでもよい話だが、僕にとっては妙に心に残ったので、ここに記しておく。
後日追記
デモページを作ってみました。
戻るボタンの機能を書き換えているところを、実際に体験できます。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
altoの紹介（うわっ、1999年に書いた記事だ）の時に書いたが、Smalltalk というプログラム言語がある。
今では当たり前になった「オブジェクト指向プログラミング」の思想を実現した、最初の言語だ。
プログラムを簡単にする方法として、アラン・ケイは「オブジェクト指向」という基本的アイディアを示した。
Smalltalk は、これを「実験的に」実装したものだった。
実験してみたら、アイディアの不備もわかる。さらに良いアイディアも出る。
Smalltalk は、「言語」と言っても、OS に相当する部分を含む。
アプリケーションも全て Smalltalk で書かれている。
ライブラリ（オブジェクト）なども全て Smalltalk で書かれている。
インタプリタ言語なので、OS 部分のソースを読んで、自分で手を加えることも可能だ。
言語の仕組みそのものである「処理系」は Smalltalk では書かれていないものの、Smalltalk で書いたものを別のコンパイル言語に「コンバート」し、コンパイルすることで処理系を作ることが出来る。
つまるところ、Smalltalk を覚えた人間は、Smalltalk の全ての動作に手を加えることが出来る。
不備のあったアイディアや、後から出てきたアイディアは、どんどん Smalltalk に反映されていった。
Smalltalk は拡張を繰り返しながら充実し…現代的なオブジェクト指向言語に「必要な要件」は、大体このときに出揃っている、と考えても良い。
（後に C++ が導入したアイディアや、別の言語が導入したアイディアもあるが、それらは実のところ「些細な」問題だ）
Smalltalk は、実にすばらしいものだった。
…というか、アラン・ケイとその周辺が「すばらしい」と喧伝した。実際はどうだったか知らない。
だって、長い間非常に高価な商用システムしかなくて、一般人が触れる機会なんてなかったもの。
一般人は、Smalltalk のアイディアを C 言語に持ち込んだ「C++」でオブジェクト指向を勉強するくらいしかなかったけど、これは余りすばらしいとは思わなかったな。当時は。
もちろんオブジェクトが作れることは便利なのだけど、Smalltalk のようなエレガントさ…誰にでも使える単純明快さは、C++ にはなかった。
アラン・ケイと仲間たちは、Apple が販売していた商用の Smalltalk-80 をベースにして、新しい「フリーの」Smalltalk を作り上げた。
これが、Squeak 。
無料で配られているけど、Squeak というのは「商品名」だ。言語としては、Smalltalk になる。
（アラン・ケイが作った Squeak と言う言語、という書かれ方を散見するが、微妙に間違っている）
Squeak が作られた目的は、子供向けにプログラミングの教育を行うためだ。
ここはちょっと説明が必要。
そもそも、Smalltalk のアイディアの一部は、Logo から来ている。そして、Logo は「実用にする」言語ではなく、子供の教育のための言語だった。
だから、アラン・ケイも Smalltalk を子供たちに使わせた。
そして、子供にとってわかりにくい部分などを「言語の欠点」として修正した。
この過程で、Smalltalk は「使いやすさ」を獲得していった。
Squeak は、これを再びやるための環境だった。
…先に挙げた alto の記事では、最後に Squeak を紹介して終わっている。
しかし、アラン・ケイたちは、すぐに Squeak では十分でない事を知る。
コンピューター自体が珍しく、触っているだけで子供たちが熱中した時代なら Smalltalk があれば十分だったかもしれない。
でも、今の時代はコンピューターゲームなんて当たり前だし、複雑なプログラムを楽しもう、なんてことは難しいのだ。
そこで、EToys が作られた。
(商標の問題で、Squeak EToys と呼ばれることもある。表記も eToys だったり etoys だったり、かなりいい加減。）
実のところ、EToys は Smalltalk 上で動作するアプリケーションだ。
現状では、Smalltalk のフルセットに EToys がインストールされた形で配布されている。
EToys では、環境を起動するといきなり自動車の絵が動いている。
そして、それを動かすプログラムも表示されている。
プログラムの数値部分を適当にいじると、車の動きも変わる。
とりあえず「テレビゲームにしか興味がない」ような子供でも、引き込むための「掴み」の部分を持っているわけだ。
EToys はよくできていて、あらかじめ命令が書かれた「タイル」を並べるだけでプログラムを組むことが出来る。
タイルは人間にわかりやすいように書かれていて、多言語化もされている。
つまり、英語環境で組まれたタイルでも、日本語に変換して表示できる。
EToys は、「タイルで作られたプログラムを実行するアプリケーション」ではない。
タイルで作られたアプリケーションを Smalltalk に翻訳し、出来上がった Smalltalk プログラムを実行するアプリケーションなのだ。
だから、タイルで組んだものを Smalltalk のプログラムとして表示することも出来る。
アラン・ケイたちは、どうも Smalltalk の入門用として EToys を作ったようだ。
先に書いたように、Smalltalk は OS 部分を含む。
そして、Smalltalk は、世界で最初の GUI OS と言っても良い。
…つまり、操作方法が非常に古臭い。
EToys も、独自の古臭い GUI 作法で動いている。
Windows の操作に慣れている人でも、最初は戸惑って何も操作できないだろう。
Scratch は、アラン・ケイとは別のグループ(MIT)が、EToys と似たようなものを作ろうとして、Squeak をベースとして作り上げた環境。
別々に活動しているが、お互いに良い影響を与え合っているようだ。
EToys は、タイルでプログラムを組む、というわかりやすい方法を導入してはいるが、これは「キーボード入力の手間を省いた」程度の話で、実のところそれほどわかりやすくはなっていない。
Scratch では、タイルの形を工夫している。
プログラムの主要な流れである「連接」は、ジグソーパズルのような凹凸があるタイルで表されている。
また「繰り返し」や「条件分岐」は、 匚 のような形のタイルの中に、他のタイルをはめ込む形で表現される。（中にタイルを入れると、左の縦棒部分はどんどん延びる）
秀逸なのは、「永久ループ」の下には「連接」のための凹凸がないこと。
これによって、永久ループの下に命令を組むことは出来ないことが、視覚的に表現されている。
（詳しくは、この日記に付けられた画像を見てください）
他にも、条件式を入れる部分は六角形になっていて、条件式のブロックは六角形で表現されるとか、数値部分は長丸になっているとか、「そこにしか入らない」ことが視覚的にわかりやすい。
そして、形だけでなく色でも表現されているので、たくさんのブロックをつなげても構造がわかりやすい。
また、Scratch は、「現代的な」GUI 作法に従っている。
初めて遊ぶ子供でも、普通の GUI に慣れてさえいれば、それほど戸惑わない。
最も特徴的なのは、Scratch で作ったプログラムの発表の場を設けていること。
作ったプログラムは、すぐに WEB にアップロードでき、WEB 上の Java で動作する「Scratch インタプリタ」によって、誰でも見ることが出来る。
（習作で作ったゲームを発表してみた。…Java で動くと遅くてつまらないな…）
それどころか、ソースをダウンロードして「リミックス」を発表することもできる。
面白いプログラムは、複数の作者の手によって、どんどんバージョンアップされる。
これは、子供にとっても刺激的なことだろう。
もちろん、Scratch はいいことずくめではない。
タイルによるプログラムは、EToys よりも「簡略化」されている。
これは、わかり易さを目指してのことだろうが、表現力を削いでいる結果にもなる。
特に、初心者にはわかりにくい「オブジェクト指向らしさ」をなくしてしまっているのが難しいところ。
ハードルが下る一方で、ゲームなどを作り始めるとすぐに足枷になる。
インスタンスの生成も、メソッドも、パブリックなプロパティもないのだ。
大域変数はあるし、全てのオブジェクトに対する「メッセージ送信」と、「メッセージ起動されるプログラム」は作れるので、メソッドとプロパティの代用は出来る。
でも、インスタンス生成がないのは辛い。
Scratch では、画面に対する「描画」は、基本的にオブジェクトを定義することで行う。
つまり、インスタンスが生成できない、というのは、キャラクターが自由に表示できないことと同義なのだ。
これはゲーム作成の上では、かなりの足枷だ。
じゃぁ、足枷を感じたら別の言語に乗り換えられるか、というと、これも難しい。
EToys なら、Squeak に乗り換えやすいのだが、Scratch は「完全に閉じている」ために乗り換えられないのだ。
Scratch はプログラムの入門用言語としてよくできているが、将来を保証することは何も考えられていない。
と、急にこんな比較を始めたのは、子供に何かやらせてみたいと思ったから。
長男が小学校から帰った後、少しつまらなそうなので。
いろいろ検討して、Scratch を遊ばせて見た。
最初に用意されているサンプルキャラクター（スプライトオブジェクト）である「猫」に命令を出してみる。
最初はマウスカーソルを追いかけるプログラムを作って遊ぶ。
なんとなく理解したようで、いろんな部分の数値を書き換えて遊んでいる。
一気に 100000000 ドットとか動かして、画面の端にぶつかって震えるのを見て笑ったりしている。
でも、大人には無意味に思える事を試して笑うことが大切。
そうやって意味を覚えていくんだ。
自分で背景やキャラクターを描ける事を教えたら、背景をぐちゃぐちゃ描き始める。
最初は無意味だったが、やがて迷路のようになり、その中の一箇所に「花」を描いた。
僕がこれを受けて、迷路の壁は越えられないが、矢印キーで自由にキャラクターが動かせるプログラムを作る。
Scratch では「キーが押された」時に起動するプログラムを指定できるので、非常に簡単。
「常に」動いているプログラムに、「壁がなければ進む」ことだけ指定しておいて、矢印キーの各キーに、それぞれの方向を向かせる、たった１タイルのプログラムを割り振るだけ。
（日記に付けられた画像はこのプログラム）
最後に、「花」を切り出して新たなスプライトを作り、キャラクターが衝突したら音を出すプログラムを仕込む。（スプライトの衝突は、１タイルで簡単に検出できる）
なんとなく、花まで行くとゴールしたような感じになった。
花の上を歩くと、音が激しく鳴り続けるのを聞いて、長男はゲラゲラ笑っていた。
プログラムが楽しい、と思えればそれでいい。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
PC を買い替えました。
今まで使っていたマシンは、2004年4月に購入したものだったので、７年間も使っていたことになります。
…今の PC で、７年前っていうと…えーと、とにかく、あれですよ。
ムーアの法則的には、２４倍くらいの性能になっているはず。
日記には書いていなかったようだけど、今年の頭に Atom525 を使ったサーバーを立てました。
（仕事のプログラム試験用だったが、現在は試験用と外部向けの２つのサーバーを仮想化して同居。節電のため）
この際、Atom525 の性能を調べたら、使っていたメインマシンの CPU (Pentium4 Prescott)より性能が高くて驚きました。
つまり、そのくらい古いマシンを使ってたんです。
でも、プログラムを組む作業って、エディタさえ動けばいいから、非力でも特に問題ないのね。
妻の使っていたマシンのほうが幾分か新しかった（とはいえ、やはり Prescott）のだけど、妻は絵を描くのが仕事なので、非力であることに問題が出ていました。
で、妻がマシンを新調したいというので、一緒に自分のマシンも買うことにしました。
まず必要用件調べ。
自分は…エディタが動けば十分。でも、家族ビデオを気軽に見るためのコンバート作業ができるとありがたい。
家族ビデオ、ハイビジョンの「テープ」で撮っています。いまどき珍しいやり方で、あまり圧縮されていないデータが入っている。
そのため、NAS に置いたままではデータ転送速度が間に合わず、気軽に見られない。
これを、画質は落ちてかまわないので、気軽に見られるデータを作りたい。
というわけで、動画圧縮専用機能を持っていて、「画質を問わなければ」速いという、第２世代 Core iが候補。
CPU 性能自体は非力でよいので、Core i3 で。ゲームもやらないので、内臓グラフィックで十分。
DELL 値段で、Insprion 620 がハイビジョンモニタつきで 79,800円。それにします。
妻用の PC 。絵を描いているけど、ツールがちょっと古いものを使っていて、マルチスレッド対応ではない。
というわけで、シングルコア性能が高いほうがいいです。
そして、値段は抑えたい。
ちょうど、DELL が１世代前の機種を安売りしていました。Inspiron 580。第１世代 Core i5 で、ハイビジョンモニタつきで 59,800円。
Inspiron 620 の Core i3 は動作周波数は 3.1GHz 。Inspiron 580 の Core i5 は 3.2GHz のうえ、ターボブーストが利きます。
なので、シングルスレッド性能で見れば、580 のほうが安いのに性能が高い。…はず。
数日たって、DELL からお詫びのメールが来ました。
「Inspiron 580 は、注文殺到のため受け付けられなくなりました。キャンセル扱いとさせていただきます」
あらら。それは困った。
その日のうちに、直接電話が来ました。
「もしよろしければ、580 の値段で 620 を提供させていただきますが、どうでしょうか？」
シングルスレッド性能は落ちるけど、全体性能は上がるはず。願ってもない話です。
というわけで、家に 620 が２台届いたのでした。
価格的には、１台 69,800円になったことになります。
先週金曜日（６月３日）に到着し、週末は子供の相手で忙しかったので、現在仕事環境セットアップ中です。
長年愛用した PS2 キーボード（１０年前に Win マシンを自作したときに購入したやつだ）がつなげなくなってしまい、本体付属の DELL キーボードを使用しているのですが…なんというか、微妙に隣のキーを押してしまうこと多し。
キーボードは馬の鞍だとは、よく言ったものだ。
実のところ、新しいマシンに一番期待しているのは「省電力」だったりします。
Pentium4 Prescott は、あまりにも電力食いで問題が多発し、 Intel がマルチコア戦略に方針転換するきっかけを作った CPU ですからね。
省電力が呼びかけられている夏前に PC を買い替えたのも、多少は電気食いの Pentium4 を意識してのことでした。
関連ページ
メインマシンに Win 再インストール【日記 18/12/20】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
一昨日書いたが、７年ぶりにメインPCを新調した。
この間も、サーバー買ったりいろいろしていたので、７年間何も買わなかったわけではないけどね。
とりあえず仕事の環境は整ったので、やってみたかった試験をいろいろ。
一昨日の日記に「ムーアの法則的には２４倍くらいの性能になっているはず」と書いたが、この根拠は、
・１８ヶ月ごとに性能が倍になる、と言われている、いわゆる「ムーアの法則」について、
・７年なら84ヶ月。18ヶ月を単位とすれば、4.6 単位となり、１単位で性能が２倍なので、
・2の4.6乗はおよそ 24。２４倍の性能のはず。
という推定による。
実際には、「性能が倍」の変わりに「値段が半分」という選択もできる。
実際、７年前に買ったマシンは当時の最高スペックで、今回は安いマシンを買ったので、性能が２４倍とはいかない。
また、開発サイクルは「18ヶ月」を意識して行われているはずなので、4.6を乗数としてよいか不明。
整数で 4 と考えれば、１６倍の性能になっているはず。
でも、書いてしまったので気になって調べてみた。
参考は、CPU 性能比較表のページ。
明記されているように、CPU の性能を単純に数値化したもので、必ずしも実情を反映していない、という前提の下で。
えーと、７年間使っていたマシンの CPU は、Pentium4 の 3.0 GHz。
参考にしたページでのスコアは、1011 だ。
現在の最高性能である、Core i7-2600 だと、スコアは 16357。おぉ、だいたい１６倍になっている。
ちなみに、購入したマシンは Core i3-2100 。スコアは 7204。非常に安かったが、これでも今までのマシンの７倍の性能だ。
実際には、動画向けの「専用用途」機能を持っていたりするので、もっと高機能だということになる。
で、先の日記に書いたとおり、自分はほとんど「エディタ」しか使用しない。
主に PHP のプログラムを書くが、そのプログラムが動作するのは、実験用のサーバーの上だ。
（Atom を使用したサーバーを組んでいる。家庭内サーバーなので省電力重視なのと、高負荷となる仕事環境のことを考えると、あえて低性能のマシンを使用したほうがよいため）
気になるのは、７倍も性能のある CPU で、力を無駄遣いするのではないか、ということ。
電力チェックまではやっていないが、CPU 負荷を表示するガジェットを入れてみた。
ほとんどすべての時間、半分の周波数で動いている。それでも負荷は 5% 程度。
今までのマシンが常に最高周波数で動き続けていたことを考えると、きっと省電力になっているのだろう。
…まだ電力までは測っていない。（電力測定機器は持っているが）
じゃぁ、どの程度の負荷まで耐えられるのかが気になった。
以前から気になっていたが、前のマシンでは非力すぎて遊べなかった、SEGA Saturn Emulator を入れてみる。
過去の日記にも何度か、それとなく書いているが、過去に Saturn の…厳密に言えば、アーケード向け筐体である ST-V のプログラマをやっていた時期がある。
残念ながら自分が作ったゲームはほとんど家庭用移植されていないが、たったひとつだけ、移植されたものがある。自分の名前もスタッフロールに入っているので、これを遊んでみるのが目標。
結果から言えば、なにも問題なく動く。
というか、これでも CPU 性能に余裕がある。動作周波数は最高まであがったが、負荷は 40% 程度だった。
プログラマブルな LSI を多数搭載し、あまりにも変態でエミュレーション不可能といわれていたのに、すごいもんだ。
…というか、「動くよ」という報告は友人から以前に受けていたのだが、自分の PC の性能が低くて遊べなかっただけ。
まぁ、これで Saturn 実機が壊れたとしても、自分の子供に、自分の作ったゲームを見せられる。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
６月６日の日記に、新PCを２台購入したことを書いた。
ここで、妻はあえて１世代前の CPU を選んだら、売り切れてしまったために、最新 CPU のマシンが届いたと書いた。
DELL のオペレータの口調から、僕の選んだマシンと同じもの…と思っていたのだが、昨日になって違うことが判明。
i5-2300 のマシンでした。４コア４スレッド、ターボブーストあり。
自分のは i3-2100。２コア４スレッド、ターボブーストなし。
まぁ、ターボブーストに関しては効いた状態で同じ動作周波数なので、「コアが増えた分電力が厳しくなり、普段はクロックが抑えられている」とも考えられる。
妻の良く使うアプリケーションはシングルスレッドなので、使わないコアはほとんど休んでいて、いつでもターボブーストが効く状態だと思うが。
ちなみに、８日の日記で書いた CPU 性能比較で言えば、i3-2100 が 7204 、i5-2300 は 9654 だ。
ハードディスクも、僕のマシンは 500GB で、妻のは 1TB。
他には特に違いはない。
実は、「売切れてしまったマシン」は、一世代前の i5 で、HDD は 1TB だった。
つまり、お詫びのしるしとしては、「CPU を i5 のまま最新にしたが、値段は旧機種のまま」ということだったのだろう。
妻の仕事は絵を描く事で、僕の仕事はプログラムを書くこと。
なので、今までも妻のマシンのほうが良いものを使っていた。
しかし、安くしてもらったマシンのほうが性能が上って、ちょっと気持ちとしては複雑だな (^^;;
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
家庭内サーバーの設定で、すこし「はまった」ので、同じ悩みを持つ方のためにメモしておく。
妻が仕事で必要なソフトを PC にインストールしたのだが、ユーザー登録メールが待っても来ない、という。
調べたら、mail server の s25r で tarpit されていた。
…同じ悩みの方向けなので専門用語が出てきて申し訳ない（笑）
s25r とは、相手のメールサーバーのホスト名を見て、ホスト名だけで「SPAM っぽい」と判断する、ある意味乱暴なやり方。
もちろん、そんな乱暴な判断でメールを削除してはならないので、SPAM っぽいときは、「保留」する。
保留とは、応答時間を引き延ばして散々待たせた挙句、「いまサーバーが忙しいから、後でもう一回送って」と相手に頼むのだ。
SPAM 業者は、存在するかどうかもわからないアドレスに向けて、多くのメールを効率よく送信するために、独自のソフトを使用していることが多い。
その「効率の良さ」は、アドレスが存在しないらしい、とわかったときには、さっさとあきらめることも含まれる。
応答時間が遅い場合も、さっさとあきらめる。ましてや「後でもう一回」なんて頼まれてもやらない。
これによって、正規のメールは届くが、SPAM は拒否することが出来る。この「後で送って」方式を tarpit と呼ぶ。(Tar pit とは、タールの沼の意味。動こうとしても遅くてしょうがない、ということだ）
さて、それはともかく、世の中に五万とある s25r + tarpit 方式のフィルタによって SPAM を排除していたのだが、これによって必要なメールも来なくなっていた。
基本的に害はない方式のはずなのに、なぜだろう？ とログを見る。
obsmtp.com というところからアクセスがあり、tarpit されていた。
この、obsmtp.com は、ユーザー登録を行った企業とは関係のないドメインだ。
そして、s25r で「SPAM っぽい」と判断されるようなホスト名がつけられていた。
はて？
この、obsmtp.com とはなんだろう？ なんの権限で、ユーザー登録を依頼した企業のメール送信を代行しているのだろう？
ネットを調べても情報がない。見つかる情報は、obsmtp.com からのメールを s25r が SPAM と認識して捨てた、というログを公開しているページや、obsmtp.com が正体不明だ、と言うような呟きばかり。
obsmtp.com によって特定の相手にメールが送信できなくなった、という相談もあったな。
（とんちんかんな答えしか出ていなかったが）
よく情報を読むと、ネットで見つけたメールログの中に obsmtp.com by postini という文字列が見つかった。
by postini ? postini によるもの、と言う意味かな？
今度は postini で調べたらすぐに答えがわかった。
obsmtp.com は、postini という会社によって運営されている、企業向けのメールサーバーサービスだ。
大規模な分散サーバーを持ち、多くのメールを扱っても負荷が少ない。
それどころか、受信メールにウィルスなどの添付がないか検査してくれるし、SPAM も排除してくれる。
そして、送受信したメールをすべて保管しておき、いつでも検索可能にしてある。
なるほど、企業向けには必要そうなサービスだ。
ただ、困ったことに、メールの再送は「大規模な分散サーバー」のどこから送ってくるかわからないようだ。
tarpit の仕組みでは、一度送られてきた IP アドレスを覚えておき、短時間でまたアクセスしてきた際には正規のメールサーバーであるとみなす。
分散サーバーにより毎回 IP アドレスが変わると、tarpit でまたされ続け、メールが届かないことになる。
この postini と言う会社は、現在 Google の傘下に入っている。
妻がユーザー登録しようとした会社は、どうやら postini と契約しており、企業として obsmtp.com をメールサーバーとして使っているようだ。
s25r は、ホスト名によって SPAM の可能性を判別する。
これは実は、「大企業はメールホストに変な名前をつけない」という経験則によるものだが、postini は分散サーバーを作るために、サーバーに機械的な「変な名前」をつけている。
この「変な名前」の判断規則は、正規表現によって記述される。
そして、通常の s25r 実装プログラムは、正規表現を調整して、特定ドメイン名に無条件に許可を出す方法も持たせてある。
（いわゆる「ホワイトリスト」）
というわけで、obsmtp.com を許可する。
調査中に、google.com からのメールも postini の技術を使って送られているらしいと知ったので、google.com にも許可を出す。
obsmtp.com は、全体が「正規のメールサーバー」なので、tarpit したとしても、あきらめずにメールを送ってくるから、許可したことによるデメリット（SPAM の増加）はない。
遅延をなくす、再送によるマシンパワーの浪費をなくす、といったメリットはある。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 追記。tarpit と書いた概念に、greylist が混ざっていた。tarpit は遅延応答、greylist は再送要求で、違う手法。組み合わされることが多いので、混同していました。 (2011-07-12 10:13:35) |
クラウド、と言う言葉が嫌いだった。
ここ数年、ＩＴ業界（って言い方も嫌いかな。パソコン業界です）でブームになっている語句である。
そろそろ一般にも浸透したかもしれないが、相変わらず何のことやら、の人も多いだろう。
クラウドって言うのはつまり、ちょっと前なら SaaS と言われたものであり、さらに前は ASP と呼ばれていた。
何で呼び方を変えたかと言うと、流行させようとして失敗したからだ。
失敗した、とみなされたものからは、急に人々の関心がなくなる。
すると、名前を変えて「新しい概念です」と宣伝するのだ。
thin-client も ASP や SaaS の概念の一分野であり、Java もそのための技術だった。
さらにさかのぼれば、X 端末や大型コンピューターの時間貸しに行き着く。
…なんだ、結局昔からあるものなんじゃん。
それを、「新しいものでござい」と宣伝する態度が気に食わないから嫌いだったのだ。
で、自分の仕事はと言えば、事実上 WEB CGI プログラマーである。
これは ASP の、SaaS の、クラウドの片棒を担いでいるのだ。
事実、重要顧客である、とある会社のとある部署は、最初は ASP 事業部だったのが SaaS 事業部に変わり、現在はクラウド事業部になっている。
まぁ、自分が嫌いなのは「新しいものだとごまかして宣伝する態度」なのであって、技術の使い方に文句は無いのだが。
実際には、名前が変わるたびに多少概念が異なってきているので、「ごまかしている」だけではない。
ASP のころは、WEB 側を perl でこなし、クライアント側を JavaScript で、と言うのが流行だった。
SaaS と言われ始めたのは、WEB 2.0 とか言われて、WEB 側が LAMP (Linux + Apache + Mysql + PHP) 、クライアント側が JavaScript 、と言うのが流行した。
現在のクラウドは、SaaS の延長上にある。しかし、JavaScript の性能は段違いに上がったし、クラウドという概念には、アプリケーションサービスだけでなく「ストレージ」や、「ホスト貸し」も含まれる。
で、やっと今回の本題だ。
特定用途データストレージとしての、Picasa web のお話。
（ここまで、前ふりが長すぎ！ と自分でも思う）
震災直後の日記に多少書いたが、家の中で RAID-NAS を使用し、さらに週に一度自動的にバックアップを取っている。
この NAS には、家族の写真・ビデオが詰まっている。
他にも仕事の資料とか入っているけど、こちらはメインではない。
デジタルの恐さは、壊れてしまうと膨大なデータが一瞬で無に帰すことだ。
プリントされた写真なら、簡単に「すべてが一瞬で無くなる」事はないのに。
家族写真などがなくなるのは困るので、対策したい、と考えたのはかなり昔のこと。
最初は DVD にバックアップをとっていた。
でも、これは実に不便。気軽に写真を見ることができずに死蔵するのみ。
行き着いた対策が、NAS で共有しつつ RAID でエラー対策。かつ、定期バックアップで操作ミスによる消去対策、だった。
導入して３年ほどたつ。
バックアップ体制としては満足していたが、写真を気軽に見るための「共有」体制としては多少不満があった。
特に、ビデオを見る方法には困っていた。
話は多少前後するが、ビデオを気軽に見るために、PC買い替え時には、動画の再圧縮性能も考慮してマシンを選んだりもしたが、なにかと面倒で再圧縮はいまだやっていない。
そして、震災。
被災地で、町が丸ごと流される映像を見て、「家の中だけで万全のバックアップを整えても足りない」と痛感した。
となると、クラウドだ。どこかにストレージを借りてバックアップを取るのがよいのだろう。
しかし、「万が一のため」に支払う保険料金としては、ストレージの代金は高すぎる。
震災後すぐに、調査を開始した。
無料で使えるものを探すと、せいぜい 5G 程度。それ以上のものもあるが、スピードが遅いと不評だったり、しばらくアクセスしないと消えてしまうなどの制限があったり。
自分は写真整理を Picasa でやっていたので、PicasaWeb を試してみた。
1G までは無料。写真を縮小してアップロードする機能が Picasa にあるので、640x480 に制限してアップしてみたが、１年半分くらいしか入らなかった。容量的にも、画質面でも、バックアップとするには足りない。
「いつかよいものを見つけなくては」と思っただけで、このときの調査はコレで終了。
最近になって、Google + がサービス開始。
Picasa web は Google + の一部として組み込まれ、写真共有のためにさらなる便宜が図られた。
容量は相変わらず 1G まで。
でも、800x800 以下の写真や、15分以内の動画は容量に含めず。
これが、Google + の会員になると、2048x2048 まで許可される。
試しに残り容量を見ると、640x480 の写真を 1G 分アップしてあったのに、0 になっている。
すぐに、Google + のアカウントを申請した。
基本的に招待制だが、申請しておけば「空きがある」時に、直接 google から招待がくるから。
で、先週。
大学の後輩から、google + に招待を受けた。
喜んで登録させてもらい、試す。
おぉ、これはすばらしい。
単に容量の問題だと思っていたのだが、容量が大きくなることで、それまで見えていなかったものが見えてきた。
具体的に言えば、ここ数年解決できずにいた問題、「家庭内で気軽に写真が見れるようにすること」「気軽に動画を見られるようにすること」「バックアップを取ること」がまとめて解決してしまった。
えーと、詳しく書くと長くなりすぎるので、ここで一度きる。
だから、前振り長すぎるんだって＞自分
関連ページ
Google drive バックアップと同期【日記 19/06/12】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
前の記事の続きです。
家族写真・動画を保存する構造を数年間模索していたのですが、気軽に見る方法がなくて、死蔵するばかりになっていました。
震災を機に、家庭内だけでどんなにデータが壊れない構造を作ってもダメだ、と痛感しました。
で、Google+ と Picasa WEB の組み合わせで全部解決した、すばらしい！ というわけで詳細。
まず、Picasa (WEBではなく、アプリケーション)で写真管理します。
この写真自体は、NAS 上においてあります。
動画なんかも NAS 上にあり、一応 Picasa で見られるのですが、ネットワーク速度の問題で実用ではありませんでした。
（置いてあるデータが .m2t …DV テープ式ハイビジョン画像のデータなので。一番圧縮率が低い（＝画質はよいがデータが大きい）データ形式です。）
一時期、写真の共有のために、別のマシンにも Picasa を入れて同じディレクトリを参照する…ということをやったのですが、これはダメです。
Picasa は、写真データディレクトリとは別の場所（ローカル）に、写真を管理するためのデータを大量に作るので。
で、Picasa WEB へは Picasa から一括アップロードします。
データ同期を使うと、Picasa を起動するごとに時間をかけてデータの差分を探そうとするので遅くて仕方ありません。
アップロード時のオプションは、1600ドットに縮小、です。
バックアップ目的なので、共有は限定公開にします。
元の画質のままのバックアップではないですが、「家が流されるほどの大災害」を憂慮してのバックアップなので、そのときには 1600ドットでもないよりまし、コレで十分です。
元画質のままバックアップすると、1G 以上の分については 2048 ドットに自動的に縮小されることになっているのですが、この方法はうまくいかないようです。
（友人の報告なので、自分では確認していません。詳細後述。）
写真は、手元のマシンで圧縮されてからアップロードされるので、回線速度が遅くてもそれほどまたされません。
でも、動画は元データのままアップロードされ、Picasa web 側で再圧縮されます。
なので、非常に遅いです。反面、CPU パワーは使用しないので、バックグラウンドで気長に続けます。
Picasa web の制限は、１アルバムの写真は１０００点まで。アルバムは１万点まで。
Picasa 側では、アルバム＝ディレクトリ、と考えていいです。
最大に詰め込めば１０００万枚の写真がおけるわけですが、実際には１アルバムはせいぜい１００点、多くても３００点程度ではないかと思いますので（自分の場合はそうです）、最大件数は置けないでしょう。
それでも、家族写真をおくには十分すぎる容量です。
アップロードしたら、家の中で気軽に見たい場合は、Picasa WEB 側のデータを見ます。
家庭内にある NAS は、ローカル接続なので速いのですが、置いてあるデータも元データなので大きいです。
それに対して、Picasa WEB の写真は、すべてが適切に圧縮されていて軽いです。回線速度が落ちても、トータルでこちらのほうが速い。
以前は、速度を上げるために NAS の中にオリジナルデータと圧縮データを作って…などと考えていたのですが、Picasa WEB を使うことで NAS に余分な容量を使うことも無く、動画圧縮のための CPU パワーも必要なく（アップロード時間はかかるけど）、家の外にバックアップもできて、すべてが解決しました。
というわけで、以前は「クラウド」と言う言葉が胡散臭くて嫌いだったのに、初めて「クラウド、便利じゃん」とか思った次第。
注意点：
Picasa WEB 、長年運用されているのに、細かなバグがいっぱいあります。
google としては無料サービスだし、あまりなおすつもりは無いみたい。
まぁ、無料なんだしそんなものだ、と受け入れましょう。
以下、遭遇したバグ。
▼名前タグが無駄に増える
２台のマシンで Picasa を使用してみたことがあるので、それが原因だとはわかっていますが…
同じ名前の人が多数に増えてしまいます。
消しても消えません。
「名前なし」さんの増殖っぷりには困ります。
基本的には google コンタクト、で人名が管理されているので、こちらで「統合」すればよいのですが、実は Picasa web 独自の人名管理もあります。
さらに、google + で導入された「プロフィール」に登録された自分の名前も、別人に扱われるようです。
邪魔な人名が増えて、しかもバグで消せなかったりするのが邪魔で仕方ありませんが、現状解決手段なし。
▼2048ドットの写真
2048 ドット以下は容量にカウントされず、容量があふれると、以降の写真は自動的に 2048 ドットに縮小される、と説明されているのですが、容量があふれるとアップロードできなくなるそうです。
（友人の報告なので未確認）
調べてみたところ、どうやら「自動的に縮小」が嘘のようです。
WEB インターフェイスでアップロードすると縮小されるけど、それ以外の手段（各種アプリ。Picasa も含まれる）でアップロードすると、自動縮小されないらしい。
Picasa に「2048ドットでアップロード」のオプションをつけて欲しい、と言う声も海外では上がっているそうですが、こちらも放置されたままだとのこと。
▼その他
操作中に画面がおかしくなる、というのはたびたび出くわしました。
細かなおかしな点はあるみたいだけど、それほど害は無いです。
ちなみに、Picasa WEB 側で操作すればスライドショーの機能があります。
家族で見たりするには、こちらがオススメ。
動画も自動的に再生し、終わったら次の写真に移ります。
Google + 側の「アルバム」機能で見ると、スライドショー機能は無いのですが、前後数十枚の写真のサムネイルが下に並びます。
…それぞれ便利なのだけど、機能統合しようとか思わないのか。
関連ページ
Google drive バックアップと同期【日記 19/06/12】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
たびたび話題にする政府の節電サイトで、ピカチュウが電力使用状況をお知らせするブログパーツを配布している。
株式会社ポケモンは、「節電＝電気ポケモン」ということで、節電の呼びかけにずいぶんとピカチュウを出して協力している。
実情は知らないけど、たぶんお金はもらっていないのではないかと思う。
だって、今年の夏のヨーカドーのポケモンラリーは規模縮小していたもの。
イベントを軽めにしても費用を捻出して協力しているのだろう、と想像。
まぁ、それはさておき、本題はブログパーツである。
すでに自分の Windows7 のデスクトップには、東電電力使用状況というガジェットが置いてある。
これはシンプルながら十分な機能を持っており、何の問題も無い。
でも、コレの代わりに、ピカチュウのブログパーツを置けないだろうか？
置けたとしたら…はっきりいって邪魔なだけも気もするが、子供が横から覗き込んだときにウケルかもしれない。
で、調べてみたら、「ブログパーツラッパー」というガジェットを作っている方がいた。
（上から順に見ていって、８番目のソフトである）
これ、いわゆる「ブログパーツ」をデスクトップガジェットとしてデスクトップに置けるようにするもの。
おぉ、なんだ。ちゃんとあるじゃん。と思って使ってみる。
…おしい。
一度表示したっきりで終わりである。
電力状況は「刻々と変化」するのだが、まったく更新されない。
ブログパーツは、WEB ページの端に貼り付けられ、ページ移動の際には破棄・更新されるものである。
だから、ブログパーツとしては更新機能が無くても、結果的に最新情報が表示されることになる。
しかし、ブログパーツラッパーはその点に対する考慮が無かった。
一度は、この時点で使用をあきらめた。
で、３日ほど前、急に思い出して、作者さんに連絡してみた。
「リロード機能つける気は無い？」って。
作者さんから丁重な返事が来た。
今すぐのバージョンアップ予定は無いが、次にバージョンアップするときには考慮します、とのこと。
そうか。すぐには予定が無いか。まぁ、フリーソフトだし、暇が無ければ更新できないのは当然だ。
自分だって暇が無ければ、この日記すら更新しない（笑）
じゃぁ、いま少し暇があるから、自分で改造してみよう、と思ったら、想像以上に簡単だった。
ガジェットの中身が JavaScript なのは知っていたけど、本当に簡単な構造なのね。
というわけで、完成した「パッチ」が以下のもの。
作者さんにはパッチ及びパッチ当てしたソースを送付したが、公開許可などは得られていないので、
パッチ部分のみの公開とする。
パッチを当てるのは、単純作業だがコンピューターの使い方がわかっていなくてはできない作業でもある。
パッチの当て方がわかる人だけが使用し、わからない人はあきらめるように。
このパッチは僕が勝手に作ったもので、作者さんに送付はしたが、次バージョンに取り入れられる保証も無い。
間違っても、作者さんにバージョンアップ願いなどを出してはならないし、作者さんにこの件で質問を送ってもならない。
▼BlogPartsWrapper.html に対する変更
11a12,13
> var Reload = "0"; //更新間隔(分) 0 のときは更新しない
>
29a32
> System.Gadget.Settings.writeString("Reload", Reload);
36a40
> Reload = System.Gadget.Settings.readString("Reload");
50a55,56
> var rel = parseInt(Reload);
> if(rel) setTimeout("window.location.reload()",rel*60*1000);
▼settings.html に対する変更
12a13
> Reload.value = System.Gadget.Settings.readString("Reload");
36a38
> Reload.value = nChk(Reload.value,"0","0","999");
40a43
> System.Gadget.Settings.writeString("Reload", Reload.value);
55a59,60
> 更新間隔：<input type="text" size="5" maxlength="3" id="Reload"/>(分)<br>
> （更新間隔を 0 にすると、更新を行いません）<br>
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
後日追記
この日記に書いた内容、バージョンアップして詳細を別ページに書きました。
WEB でメールアドレスを公開しながら、スパム用のメールアドレス収集ボットには見つかりたくない。
でも、ボットではなく人間に対しては、できるだけ使いやすくしておきたい。
…非常にわがままな要求です。
誰でも使えるように公開しておいたら、ボットにも公開されるのは当然のこと。
でも、現実問題として「ボットに見つからないようにしながら、使いやすく公開したい」需要はあるのです。
というわけで、仕事上のクライアントから相談を受けました。
いままで、自分の（この）WEBサイトでは、画像でアドレスを公開していましたが、これだけでは要求を満たせないのは事実。
で、研究して作ってみました。
「たぶん」スパム収集ロボットには収集できない。
でも、人間の使い勝手は「わりと」よい。
（範囲選択してコピー、ができないのが残念）
以下のフォームで、javascript 部分を生成できます。
表示されているメールアドレス部分は画像なので、そこは自分で作ってください (^^;
（あとに作り方の参考を書きますので、読んでね）
以下、技術話。
メールアドレス収集ボットは、HTML ファイルを取得して、その中から「メールアドレスらしい部分」を探し出し、収集します。
HTML ファイルの中から、なので、そのままのテキストではなく html エンティティにすればよいとか、mailto: リンクを url エンコードすればよいとか、javascript でリンクタグを生成すればよいとか、外部ファイルにメールアドレスを入れて link タグで読み込ませればよいとか言われるけど、それはダメ。
だって、いまどきブラウザもオープンソースの時代だから。
ブラウザがページを最初に開いたときに、エンティティを解釈したり、url エンコードを解釈したり、javascript を実行したり、外部ファイルを読み込んだりするところまでやらせて、出来上がった「表示直前の」データを取得すれば、メールアドレスはばれてしまう。
Javascript でリンクタグを生成するのではダメ、というのは、こちらのページで実験することができます。
残る方法は二つです。
1) 画像で表示する。
クリックしてもメーラーは開かないし、コピーもできない。
メールが欲しいからメールアドレス公開しているのに、メールしようと思っても「長いアドレスを手で間違えずに入力しないといけない」という、事実上メールを送ることを拒否した状態になってしまう。
2) メールを送ろうとした瞬間に、Javascript でアドレスを生成する。
これなら「表示直前のデータ」にもアドレスが入りません。
でも、それは「表示できない」ことを意味します。
メーラー起動しない場合、メールアドレスが存在していることを教えられません。
もちろん、Javascript が実行されない環境の人にもメールアドレスを教えられません。
1 は、メールアドレスは教えられるがメーラーに渡すことができない。
2 は、メーラー起動はできるが、メールアドレスを人間に見せられない。
というわけで、２つの方法は綺麗に補完関係にあります。
なので、組み合わせれば問題なし！ …といいたいところだけど。
OCR の噂。
いまどき、OCR ソフトもオープンソースで存在します。
メールアドレスを画像化しても、OCR してアドレス収集するボットがいる、と言う噂もあります。
でも、これは OCR の癖を知っていれば対処可能。
人間にも読みにくい画像にしてしまえば、OCR はまず読めない。
いや、そこまでしないでも、「人間には読めるのに OCR はできない」画像を作るのは難しくない。
今作るメールアドレス画像は、「クリックすればメーラーが起動する」ことを教えるためのもの。
ならば、普通のリンク部分と同じように、アンダーバーをつけてはどうでしょう？
これだけで、文字の区切りが不明瞭になり、OCR には非常に読みづらくなります。
フォントも、読みづらくない範囲でデザイン性が高いものを使うと、なお OCR されにくいでしょう。
作り方は、別に特別なソフトはいりません。
WEB でメールアドレス公開したい、と悩んでいる人なら、HTML くらいは書けるはずだし、簡単な画像加工ツールくらい持っているでしょう。
なので、メールアドレスをリンク状態にしたタグを書いて、ローカルでブラウザに表示させます。
font タグで face="～" を使えば、フォントも変えられます。
どうせアルファベットなので、フリーのフォントは山ほど配布されています。
あとは 画面キャプチャして、適当に切り出せば終了。
出来上がったら、本当に OCR できないのか確認しましょう。
WeOCR Projectといものがあり、WEB ブラウザから画像をアップロードすると、OCR 結果を返してくれるサーバーがたくさん集められています。
検索すると、サーバーのアドレスとともに、どのような OCR エンジンを使用しているかも教えてくれます。
複数のエンジンで読み込ませてもうまく認識できない「メールアドレス画像」であれば、ボットに収集される可能性は低いと考えてよいかと思います。
WEB 上にも、メールアドレスの画像化をしてくれるサービスがいくつかあります。
E-Mail Icon Generator （有名ドメイン専用）
最初に設置した Javascript のタグ生成器が生成するタグの説明。
img タグ１つ。ただそれだけです。
src 部分には # と書いてありますが、これをご自分のメールアドレス画像の url に変えてください。
style 指定は、この画像上でマウスカーソルを「クリック可能」を意味するものに変えるように指示しています。これで、一見普通のリンク文字と変わらないように見えます。
で、クリックすると onClick に書かれた Javascript が起動し、暗号化（簡単なシーザー暗号ですが）されたメールアドレスを復号して、メーラーを起動します。
暗号化された文字の「エスケープ」は考慮していません (^^;;
メールアドレスに $ 9 ; | } ~ などが入っていたりすると、ちょっと困ったことになるかもしれません。
（暗号化された文字が、特別な意味を持つものに変わるため）
大切なのは、この方法が「それほど有名にならないこと」。
有名になるとボット作成者に対処されますからね。
自分がボット作者なら、明らかにメールアドレスを隠蔽している部分のタグを見つけ出して、そこの Javascript だけ実行させてみます。
そういう意味では、「img に付いた onClick で、最後が location.href に代入しているもの」は明らかに怪しい。
なので、別案も示しておきます。
・img タグに直接 onClick を指定するのではなく、周囲に別のタグをつける。
a タグで href に mailto: だけ指定すると、Javascript を使えない/使わない環境の人でも、とりあえずメーラー起動してくれます。
（この場合、onClick の最後に ;return!1 をつけること。そうしないと、href が優先的に動作します）
・もちろん、a タグではなく form でも 、div でも span でも font でも、どんなタグでもよい。onClick が付けばなんでも。
・onClick が怪しまれるかもしれないので、onMouseDown でも onMouseUp でもよい。
（厳密に言えば、クリックとは「ボタンが離されたとき」に完了するので、onMouseUp のほうが違和感は少ないです。）
・location.href=d するのではなく、clipboardData.setData("Text",d) する。
こうすると、メーラーを開くのではなく、アドレスをクリップボードにコピーします。
（ただし IE 限定）
・onClick などのイベント属性と Javascript プログラムがセットになっていると、「メーラーを起動している可能性が高い」などと判断しやすいかもしれません。
なので、プログラムを関数にして、別の箇所に置く。これだけでもボットを出し抜ける可能性はあります。
（もっとも、対応付けは難しくないので、自分がボットを作る立場なら検査させるかも知れません）
Javascript プログラムは近年多用されている傾向にありますし、場合によってはゲームなどが動作してしまうため、ボット作成側も「何でもかんでも動作させてみる」というわけにも行かないでしょう。
なので、ある程度の「きめうち」が予期されます。
対策する側としては、きめ打ちされない程度に方法が分散し、撹乱できればよいわけです。
同じことは、表示画像に使用するフォントに対してもいえます。
皆が同じフォントを使っていれば、すぐに対処されちゃう。
この日記の冒頭に示した画像では、Monotype Corsiva フォントを使用しています。
（日記執筆時…画像は後で変えるかもしれない）
このフォントは、読みにくくない程度に装飾が施され、なかなか OCR しにくいように思います。
Windows 標準フォントで言えば、Mv BoliとかSegoe printとか、結構いいかもしれません。
MacOS 標準フォントだと、Apple Chanceryあたりかな？
究極は、自分の手書きを画像化することか…
でも、OCR できないことを目指しすぎて、人にもわかりにくくなっちゃだめ。微妙なところです。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
電力使用制限令自体は、９月９日に終了している。
が、我が家としては政府の節電サイトの景品欲しさに、もう少し節電していた。
それも、電力使用量のお知らせが着たから終了。９月は35％の節電だった。
これで、サランラップがもらえる。かもしれない。
節電を終了したからどうするか、と言ったところで、別に無駄に電気を使おうとは思わない。
もともと、我が家では節電を心がけてはいたのだ。
…３ヶ月で、27%、38%、35% も節電できていて「心がけていた」も無いものだが、本当だ。
湯沸しポットは３年以上使っていないし、電気掃除機も年に１～２度しか使わない。
今回の節電は、仕事で必要なサーバーを停止して、２台使用しているのを仮想化して１台にまとめた効果が大きい。
２４時間運用していたのを、２台から１台に半減させたのだからね。
でも、これによって２台でお互いにバックアップを取り合う体制も停止していた。
仕事で使っているのに、バックアップが無いのは、本来はダメなのだ。
この点、「無理して節電していた」ので、節電終了で早期に復旧。
あと、７年前の PC を買い換えたのも大きいと思う。
こちらは、節電終了してもそのままなので、今後も家計費節約になるでしょう。
でも、以前は PC のバックアップも、夜中に自動的にとっていたのだよね。
これも復活させないといけないけど、新マシンにバックアップソフトを入れたりといった体制作りはまだできていない。
こちらはそのうち設定する予定。
バックアップは壊れてからでは遅いので、こまめにとらなくては。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
16年 箱根小涌園ユネッサンに行きたい人へのまとめ(1/3)
16年 箱根小涌園ユネッサンに行きたい人へのまとめ(2/3)
16年 箱根小涌園ユネッサンに行きたい人へのまとめ(3/3)
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
仕事で、とあるサイトに接続する必要があった。
一般的なサイトではなく、仕事上の機密情報を扱うサイトだ。
サイト管理者から渡された「証明書」をインストールしていないとアクセスできないし、セキュリティを固めるために、いろいろな細工が施してある。
ActiveX を使用しているので、IE でしかアクセスできない。
必要だからアクセスしたいのに、なぜか Windows7 + IE9 でアクセスできない。
証明書の確認までは行くのだが、その後「Internet Explorer ではこのページは表示できません」となる。
とりあえず、非常用のノートPC で XP + IE8 でアクセスできたが、いろいろと不便。
Windows7 + Chrome で試すと、アクセスできる。
もっとも、アクセス後 ActiveX が使えないので何もできない。
しかし、証明書のインストールに失敗しているわけではなさそうだ、ということは確認できる。
IETester を入れてみて、IE7 でアクセスしたがやっぱりダメ。
FireFox + IETab2 、というのも試してみたが、これは単に IE9 を Tab 内で開いているだけなので当然ダメ。
いったい、何が原因で動かないのか。
とりあえずアクセスできる chrome と、IE9 の違いはどこにあるのか。
chrome で Javaコンソールを開き、アクセスして、ネットとのやり取りしたデータを覗く。
IE9 で開発者ツールを開き、アクセスして、ネットとのやり取りしたデータを覗く。
…比較して、違いに気がついた。
chrome では、認証フォームの内容を POST すると、HTTP ステータス 302 が帰ってきてリダイレクトして、次のアクセスは GET になっている。
IE9 では、同様にリダイレクトして、次のアクセスは POST 、しかも「中断」と表示されて実際のアクセスが行われていない。
何でこんなことになるんだ？ と、HTTP の仕様を確認してみる。
もし 302 ステータスコードが GET や HEAD 以外のリクエストのレスポンスとして受信されたら、リクエストが発行された時点の条件から変わっているかもしれないため、ユーザエージェントはユーザに確認されなければ、リクエストを自動的にリダイレクトしてはならない。
…POST アクセスから、302 でリダイレクトしちゃいけないんだ。恥ずかしながら、知らなかった。
しかも、
注: RFC 1945 や RFC 2068 では、クライアントはリダイレクトするリクエストのメソッドを変えてはならないと明確に述べられている。
POST でアクセスされたのに、リダイレクトで GET に変えちゃいけないんだ。これも恥ずかしながら、知らなかった。
参考までに、僕は恥ずかしながら知らなかったが、2006年ごろからこの手の問題を指摘している人はいたようだ。
古くて新しい問題なんだな。
というわけで、わかったのは、「サイトのつくりが悪い」ということ。
アクセスできないのが当然の作り方をしているのだ。
IE9 が悪いのではなかった。濡れ衣だ。ごめんよ。
IETester も、「見た目」を確認するためのツールなので、HTTP アクセスは OS 標準(今回は IE9)のプログラムを使用しているのだろう。
とはいっても、現実問題として 302 のときは GET に切り替えてアクセス、というブラウザがほとんどで、正しく仕様に従ったのは IE9 が初めて、ともいえる。
実のところ、302 でなく、303 を返せばいいらしい。
この場合は、GET でリダイレクトされなくてはならない、と決まっているから。
ただし、ブラウザが HTTP 1.1 を理解できないと、303 は使えない。
…いまどき、1.0 のブラウザなんて無いでしょ？
2014.6.12 追記:
HTTP/1.1 の新仕様である RFC7230～7239 が作成されました。
POST 302 からの GET リダイレクトは、「それが可能なように実装されているブラウザがあまりにも多い」ことから、違反ではなくなりました。
ここに書いてある情報は古くなりましたが、日記なのでそのまま残しておきます。
…それにしても、また後出しで「IE は標準と違う」ことにされるのは、マイクロソフトがちょっとかわいそう。
翻って、自分の仕事の話。
PHP で作っているプログラムで、Location なんてしょっちゅう送っている。
そして、PHP では Location を送出すると、暗黙のうちにステータスコード 302 を返す。
…これ、問題あるね。PHP の仕様がバグっている、ということだ。
もっとも、ステータスコードは指定できるので、直前が POST のときは、明示的に 303 にしなくては。
ただし、303 と 302 は意味が違うので、単に POST アクセスからリダイレクトしたい、と言う理由で使うのは間違い。
ちゃんと意味を理解して使わないと。
HTTP 1.1 が前提であれば、307 というのもある。
こちらだと、POST アクセスの次は、POST で返してくれるそうである。
ただし、この場合も「自動的にリダイレクトしてはならない」という、302 と同じ制約は付く。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
PHP でデーモンを作ろうとして、少しハマった。
同じことで悩んでいる人がいるかもしれないので、簡単に記しておく。
作ろうとしたのは、デーモンの「親」が、多数の「子プロセス」を作って、同時並行処理する、というもの。
なにぶん PHP だから、ひょんなことで終了する可能性がある。
だから、子プロセスが終了したら、親は再び子プロセスを起動する。
万が一親プロセスが死んだら…これは、deamontools を使っているので気にしない。
親プロセスが子プロセスの終了を待つには、pcntl_wait する。
親プロセス自身が TERM や HUP シグナルを受け取ったら、子プロセスを全部安全に終了させてから親が終了しなくてはならない。
これには、pcntl_signal を使う。
pcntl_wait は、
この関数は、子プロセスが終了する・ カレントのプロセスを終了させるシグナルが送信される・シグナル処理関数を コールするシグナルが送信される のいずれかが発生するまでカレントのプロセスの実行を中断します。
…と、関数リファレンスに書いてある。
つまり、子プロセスが（１つでも）終了するか、親プロセスにシグナルが来るまでは pcntl_wait で止まっている、ということだ。
pcntl_signal は、シグナルを受け取ったときに処理する関数（コールバック関数）を登録する命令なのだが、
PHP 4.3.0 以降、PCNTL はシグナルハンドルコールバックの仕組みとして ticks を使用しており、これは以前の仕組みよりずっと高速です。
…と、関数リファレンスに書いてある。
ticks というのは、PHP の命令と命令の隙間だ。厳密に命令と対応しているわけではないが、ともかく「PHP 内部の処理が終わって、スクリプトの命令を読み込むとき」に ticks が発生する。
そして、PHP のバージョン 4.3.0 以降は、この ticks でシグナルを受け取る、というのだ。
…あれ？
pcntl_wait は、命令中でもシグナルを受け取る、といっている。
pcntl_signal は、シグナルは命令の間で受け取る、といっている。
この矛盾に気づくまで、思ったように動作しないでかなり悩んだ。
実際には、pcntl_wait 中は、シグナルを受け取ることができない。
だから、親の動作が「子プロセスの終了を待つだけ」であっても、pcntl_wait で停止してはいけない。
おそらく、4.3.0 以前は、pcntl_wait はシグナルを受け取っていたのだろう。
幸いなことに、pcntl_wait には「停止せず、子プロセスが終了していないなら 0 を返す」というオプションがある。
これを使って、シグナルを待ちながら子プロセスの終了も待つ、というメインループを作ったら、シグナルを受け取れるようになった。
さらに言うなら、ticks を使ってシグナルを受け取ろうとすると、どこで割り込みが発生するかわからず危険な上、命令ごとに割り込みを処理しようとするので遅いようだ。いいことがひとつもない。
ticks ごとの割り込みは declare 命令を使って制御するが、それ以外に pcntl_signal_dispatch を使うことで、シグナル処理の明示的なタイミングを指示することもできる。
こちらを使ってみたら、安全なタイミングで処理できるし、速度も速くなった。
…しかし、PHP って deamon 作るのに向いている言語ではない。
そんなことは最初からわかっているが、今回はどうしても PHP で書かれたライブラリを使用する必要があったのだ。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
その昔、Turbo Pascal というプログラム言語があった。
…この言い方はちょっと違うか。
Pascal というコンピューター言語があって、その処理系の製品として、Turbo Pascal があった。
Pascal というのは、もともと教育用に考えられた言語だ。
といっても、わかりやすくなっているけど非力、というようなことはなくて、非常に強力。
祖先は ALGOL で、C と同じ。だから、プログラムの組み方も C と似ている。
違うのは、C はハードウェアを直接叩けて、システムクラッシュさせるのも自由気ままにできるのに対し、Pascal はハードウェアをできるだけ隠蔽するように作られているので、システムクラッシュが起こりにくいこと。
隠蔽する、というのは手間がかかることなので、パフォーマンスは C が上。
プログラムを組む上でも、Pascal は「比較的厳密な」文法を求められるのでバグが出にくい反面、いちいち入力が面倒くさかった。
趣味のプログラマーにとってはバグなんて多少出てもいいし、厳密に書かないと動かないのは面倒くさいので嫌われた。
そんなわけで C 言語が幅を利かせるようになり、「類似言語」であった Pascal は下火になるのだが、Pascal 自体が非常に強力な言語であった、という事実は変わらない。
強力さのひとつに、言語設計のうまさがある。
プログラムは、必ずボトムアップで書かなくてはならない。
わかりやすく言い換えると、関数は定義してからでないと使えない。
「とりあえず関数の呼び出しを書いといて、あとで関数の実体を書く」は、原則として許されない。
これによって、関数が呼び出されるときには、すでに関数の定義が終わっている。
同様に、変数も使われる前に定義されている。
C言語では、どこで関数が定義されているかわからないので、コンパイル時に少なくとも２回はソースを読まなくてはならない。
１回目で定義を全部把握して、２回目で実際のコンパイルを行う。
でも、Pascal の設計では、１度ソースを読めばコンパイルが完了できる。
で、冒頭の Turbo Pascal。
「Turbo」と名づけただけあって、コンパイルが速かった。
…「速い」なんてもんじゃない。コンパイルしていることに気づかなかった。
なにせ、Turbo Pascal には専用のエディタがついていて、エディタの上で F5 キーを押すと、プログラムを実行できるのだ。
BASIC のような、インタプリタ言語の感覚でプログラムを組むことができた。
これはつまり、エディット中なのでメモリ上に入っているソースをそのままコンパイラに渡し、コンパイラは１パスでコンパイルを行い、生成後のバイナリはメモリに載せたまま実行していた、ということだ。
ディスクアクセスがないので、非常に速い。
Turbo Pascal を作った Borland 社は、C 言語のほうが人気が出たために Turbo C も作った。
でも、こちらはいまいち。当時のほかの C 言語処理系よりも高速にコンパイルができたが、C 言語の仕組み上ファイルを多数読み込まなくてはならず、コンパイルも１パスではできず、「インタプリタ感覚」とはいかなかった。
大学のとき、アルバイトしていたゲーム会社で、グラフィックデータの整理を任されたんで、Turbo C を借りて２～３日でツールを作って、大量のデータ整理が簡単にできるようにしたっけ。
バイトの仕事として雑用を任せたら、汎用のツールを作ってしまったので驚かれて…社長から、大学辞めて働かないかと誘われました。
腕を認められたわけでうれしかったけど、大学やめる気はなかったので、翌月にバイトやめて逃げ出してしまいました。
今ではそれなりに有名な会社だけど、社長元気かな。
と、ここまでは長すぎる前フリ。
Turbo C Compiler のコマンド名は tcc だったけど、今回の話のテーマは、同じ tcc というコマンド名を持つ、Tiny C Compiler 。
2004 年には最初のバージョンがでているようなので（もっとも、2002 年には otcc という名前で前身となるプログラムがある）、ここで取り上げるのも「いまさら」なのだろう。
僕は３年位前に tcc の存在は知っていたのだが、Tiny と名前についているくらいなので、「コンパイラの作り方の教科書に出てくるような、C 言語のサブセット」だと思っていた。
実際、otcc はサブセットだったらしいのだが、tcc は ISO の規格にのっとった、フルセットの C 言語になっている。
そして、tcc がすごいのは、Turbo C 並にコンパイルスピードが速いこと。
ファイルを多数開くのは C の特性上仕方がないが…１ファイルで完結する短いプログラムであれば、TurboPascal並と言って差し支えないだろう。
この速さを活かして、ソースをコンパイルして、バイナリをファイルに吐き出さないでメモリ上においたまま実行、ということができる。
つまるところ、C 言語をインタプリタ言語のような気楽さで使えるのだ。
もっとも、生成されるソースコードの品質は低い。
速度を活かして開発して、出来上がったら GCC などで最適化したバイナリを作る、というのが正しい使い方なのだろう。
というわけで、早速インストールしてみる。
Unix (僕の場合、Linux の CentOS 5.5）にインストールするには、ソースを展開して、
./configure
make
make install
で終わり。
この場合、GCC でコンパイルされる。
せっかくなので、コンパイル時間を計ってみる。
time make
とすればよい。
make するたびに、make clean して元の状態に戻し、３回計って平均を取ってみた。
real 0m19.858
user 0m18.955
sys 0m0.689
重要なのは、user の値。0分18秒955。
出来上がったバイナリサイズは、331769 byte。
さて、次に、出来上がった tcc で tcc 自身をコンパイルしてみる。
./configure -cc=tcc
あとは同じでよい。同様に３回やってみて平均。
real 0m0.395
user 0m0.318
sys 0m0.047
速い。59倍速。こんなに速すぎると測定誤差もあるだろうから、何倍、に意味はなさそうだけど。
出来上がったバイナリサイズは、410056 byte。
バイナリサイズは２割り増しだ。
gcc と違って最適化がされていない（もしくは甘い）ので、コンパクトさで２割違う、ということだ。
続いて、tcc でコンパイルした tcc で、tcc をコンパイル。
これで、tcc が生成したバイナリの速度品質がわかる。
real 0m0.777
user 0m0.649
sys 0m0.052
遅い。先ほどの倍以上の時間がかかっている。
gcc と違って最適化がされていないので、速度で２倍違う、ということだ。
出来上がったバイナリサイズは、411324 byte。
…あれ？ tcc コンパイル、という点で同じなのに、さっきと違う。
よく見たら、tcc をコンパイルすると、tcc が使用するライブラリも一緒に生成されていた。
つまり、最初に tcc でコンパイルをした際、使用されたライブラリは gcc でコンパイルされたもので、これが最終的なバイナリにも含まれていた、ということ。
２回目の今回、ライブラリも tcc でコンパイルされたものとなったので、これが本当の「tcc でコンパイルされた」サイズ。
念のため、もう一度 tcc でコンパイル。
real 0m0.763
user 0m0.635
sys 0m0.075
速度はほとんど変わらず、誤差範囲。
出来上がったバイナリのサイズも先ほどと同じで、念のため diff したが、完全に同じものだった。
というわけで、結論。
tcc のソースをコンパイルする、という限定的な条件の試験だが、以下の結果が得られた。
tcc の生成バイナリは、gcc の生成バイナリよりも、コンパクトさで２割、動作速度で２倍程度劣る。
しかし、tcc によるコンパイル自体は、gcc よりも 20倍以上速い。
余談だけど、tcc 作った人は、FFmpeg とか、QEMU とか、A PC emulator in Javascript とか作った人と同一人物。
FFmpeg といわれてもわからなくても、携帯動画変換君や MEncoder 、VLC Player など、数え切れないほどの「動画関連ソフト」が、内部に FFmpeg を持っている、と説明すれば、すごいソフトであることが理解されるでしょう。
また、QEMU も、Xen や kvm など、Linux に組み込まれた「仮想化技術」のコアになっています。
A PC emulator in Javascript は、その名のとおり、QEMU を Javascript で実装してみた、という実験です。
リンク先に進むとわかりますが、Linux が起動し、tcc でソースをコンパイルできる環境が整います。
これ、「そんな感じに見えるフェイク」ではなくて、本当に動作する Linux なんですね。
chrome とか、最近のブラウザ使えば、ベースマシンの CPU 速度が遅くても、それなりの速度で動作します。
あと、2009 年時点での、円周率の計算桁数で世界記録保持者でした。２兆７千億桁。
先日、日本人が１０兆桁計算して、現在はこれがトップですが。
なんか…すごいなぁ。「面白がって」プログラムを作っている感じが、すごくする。
そして、その面白がりが非常に有用で、世界を変えるほどの力を持っている。
本当のハッカーって、こういうことなんだろうな。
後日追記 11.11.18
本文中に書いた「大学時代にバイトしたゲーム会社」ですが、それなりの規模になって某人気ゲームシリーズなどを作っていたのですが、５年ほど前に廃業しているようです。
ネットで調べて知りました。
関連ページ
スーパーファミコンの発売日(1990)【日記 13/11/21】
ニクラウス・ヴィルト 誕生日(1934)【日記 16/02/15】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
夏の電力逼迫状態を抜けたときに、毎日の PC 運用を元に戻さなくては、と書いた。
具体的には、メインマシンのバックアップを定期的に取ること。
以前は、深夜に自動起動して、ディスク丸ごとバックアップを取っていた。
でも、震災後は電力の無駄遣いを少しでも減らそうと、これを停止していた。
仕事で使っているマシンなのに、バックアップしないことにも問題がある。
以前のマシンは、７年前の XP マシンだった。
動作が重いため、バックアップだけでなく、深夜にデフラグも行っていた。
使っていたソフトは、Paragon Backup & Recovery と、MyDefrag 。
共に、無料だが評判の良いソフトだ。今度もこのソフトを入れるつもりでいた。
１０月下旬の話。
まずは、Paragon を導入。バックアップを取る。
バックアップを取って安心したところで、各種デフラグソフトや、無駄なファイルをクリーンアップするソフトを試してみる。
…あれあれ？ インストール＆アンインストールを繰り返すうちに、なにかおかしくなったらしい。
システムの休止状態が利かなくなった。
（Windows 7 のデスクトップの休止が出ない問題ではない。休止はあるが、使えない。
もっというと、コマンドラインで休止状態に入ろうとすると、dll が読み込めなかった、というエラーになる）
システムの復元を試してもだめ。
DELL マシンにプリインストールされている、「出荷状態に戻す」ツールを使う。
これは、データファイルは保護したまま、OS を初期化してくれる優れものツール…だったはずだが、戻らず。
まぁ、大丈夫。
こんなときのために、システムを丸ごとバックアップしているのだ。
あわてず騒がず、Paragon で Recover モードを使用。
…起動ディスクに対してリカバーはできません、といわれる。まぁ、それもそうだろう。
USB 起動メモリを作成して、そこから起動。
…NAS に入れてある、バックアップデータが見えない。
Paragon は NAS へのバックアップに対応しているが、Recover には対応していないらしい。
…NAS のバックアップを取ってある USB ディスクを接続。
今度はバックアップファイルが見れた。しかし、なぜか内蔵ハードディスクが見えない。
見えない先に対してリカバーはかけられない。
結局、リカバー断念。
Windows7 のクリーンインストール。
というわけで、Paragon は自分の中での信用を大きく落とした。
念のため書いておくが、NAS を使わなければ問題ないと思われる。
でも、それは面倒くさいから、僕はこの際 Paragon を使わないことにする。
クリーンインストールからリカバーしてみたら、データさえあれば案外なんでもなかった。
以前は、仕事柄変なソフトをいっぱい使っていたのだ。だから、インストールが面倒だった。
変なソフトってのは、携帯電話向けの開発ツール。
ところが、今は携帯電話の性能が上がり、事実上 PC と同じになってしまったため、専用ツールはほぼ不要。
だったら、必要なデータだけあればよい。
しかも、自分の場合重要データは Linux マシン上や、NAS 上においてあるものが多いから、本当に少しのファイルをバックアップしてあればよい。
というわけで、BunBackup を導入。
以前から名前は聞いていたが、「わずかなファイルを確実にバックアップしておきたい」という用途には最適のツール。
設定は多少やっかい。オプションが多すぎて、作者もそれを気にして「無用なオプションの隠蔽」を心がけているのだが、結果として機能はあるのに隠蔽されて見つからなかったり、余計な混乱を招く。
設定さえ終了すれば、非常に軽快な動作で安心感がある。
SandyBridge の Core i3 マシンで使っていますが、バックアップ中も作業をそのまま続けられます。まったく問題なし。
クリーンインストール直後なので、Defrag は必要ない。
でも、「転ばぬ先の杖」で探してみた。
というか、クリーンインストール前にいろいろ試していたのだな。
MyDefrag は、非常にきっちりデフラグしてくれるので以前は重宝していたが、いかんせん遅い。
遅いから作業中に使いたくなくて、深夜に使っていた。でも、これは電気の無駄だろう。
というわけで、SmartDefrag を使用してみた。
このソフト、評価真っ二つ。
ソフト紹介ページなんかの評価は、「動作が軽い」として各種の賞を受賞していたりする。
確かに軽い。デフラグがあっという間に終わるし、バックグラウンドで動作させても気にならない。
一方、デフラグ好きの人は、動作の軽さは評価ポイントにならない。
SmartDefrag は、デフラグの効果がほとんど出ない、というので評価が悪い。
しばらく使ってみて理由がわかった。
SmartDefrag のアルゴリズムは、「１日に５０のデフラグが起きるなら、１００個だけ解決しよう」というような考え方で作られている。
常駐していて、ほっとけば勝手にバックグラウンドでデフラグする。
でも、ある程度デフラグしたら、それでおしまい。徹底的にきれいにしようとはしない。
だって、常駐していて頻繁にデフラグするのだから、あとでまたきれいにすればいいじゃん。
「完全最適化」オプションでデフラグをかけても、同じような考え方。
あまり時間をかけないように、適当なところで切り上げる。
「完全最適化」は、ある程度デフラグをかけてあるディスクで、使用頻度の高いファイルを高速なエリアに少し移動する程度、という考え方。
でも、それでいい。
バックグラウンドでの動作が気にならない程度に軽いのであれば、時間をかけて少しづつきれいにして、ある程度きれいになったらその状態を維持する、という方法で問題はない。
ちなみに、家にある非常に古い XP マシンにも入れてみたが、そのマシンでもバックグラウンドで動いてもそれほど問題がないほど軽い。
５年程度使ったマシンなので、１度の「完全最適化」ではデフラグ効果はあまり出なかったけど、そのうちきれいになるだろう。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日デフラグツールを選定した話を書いたので、デフラグについて書いておこう。
デフラグについて、するべきだ、という意見と、するべきでない、という意見の２つが、ネット上で流布している。
どちらの意見がすぐれているか、ということはさておき、まずは前提となるデフラグから書いておこう。
ファイルは、ハードディスク上に記録されている。
この記録は、OS が適切に管理してくれている。
昔のコンピューターは、この「適切さ」に難があった。
たとえば、ファイルは必ず「連続したエリアにおかれなくてはならない」という OS があったのを、僕は知っている。
この場合、扱っているファイルが大きくなってくると、別の専用ツールを使って「ファイル位置を移動して、空き領域を確保する」必要があった。
今の OS は、そんな面倒なことはない。
ファイルが大きくなってきて、ほかのファイルとぶつかりそうになると、離れた場所でも構わないので空き領域を見つけて続きを書き込む。
飛び飛びにファイルが記述されることになるが、OS はその位置を把握しているので、ユーザーが気にする必要はない。
ただ、ひとつだけ難点がある。
ハードディスクは、「物理的に」動作しているのである。
連続した場所に書かれた情報は、連続して読むことができる。しかし、離れた場所にある場合は、探しに行く必要がある。
この、探しに行く時間というのは、ほんのわずかである。しかし、コンピューターの電子的な動作からすると、非常に長い時間なのだ。この時間を無駄にすることになる。
この、「非連続にファイルが記録される」ことを、「ファイルの断片化（フラグメンテーション）」と呼ぶ。
これを解消するのが、デフラグである。
（「デ」は、除去する、元に戻す、などの意味の接頭語。バグ取りをデバグ、というのと同じ）
話をまとめよう。
昔のコンピューターでは、ファイルの容量が増加すると、定期的に専用ツールで空き領域を確保する必要があった。
今のコンピューターではそんな面倒はないのだが、無駄を減らしたければデフラグツールを使って、デフラグをする。
「しなくてもいい」ことはありがたいが、気にする人にとっては、結局昔と変わっていないという、ただそれだけのことである。
先に書いたように、ファイルが断片化したからといって、アクセスにかかる時間の増加はわずかである。
普通に使っていて、あまり気にする必要はない。
でも、デフラグには別の効用もある。
その効用を説明する前に、ハードディスクの「記録方法」の話をしておこう。
古いハードディスクは、「角速度一定」という方法で記録されていた。
ディスクを放射状に区切り、記録のための区画とする方法だ。
これだと、外周は区画が大きくなり、内周は区画が小さくなる。
塗られている磁性体の密度は外周も内周も同じなので、内周の記録密度が全体の設計に影響を及ぼす。
外周には記録密度に余裕があっても、その余裕を捨てていたのだ。
古い話だが、Old Macintosh の 3.5inch ディスクは「線速度一定」だった。
これは、外周を読むときは遅く、内周を読むときは速くディスクを回すことで、磁性体に対するヘッドの速度を一定にする方式である。
ヘッドから、一定の速度で信号を読み書きすると、読み書きの区画は放射状には配置されなくなる。
しかし、記録密度としてはどの場所でも一定となり、無駄は生じない。
この方式、フォーマットしたりするとディスクの速度が明らかに変わっていくのが音でわかって面白かったのだが、ハードディスクほどの高回転になると、「回転速度が安定する」のを待つ必要があり、無駄が多いので採用されなった。
（ちなみに、CD や DVD はこの方式だ。速度が遅くてよいメディアでは有効な方式である）
現代のハードディスクでは、記録密度一定方式がとられている。
回転数は変えないが、外周と内周で、ヘッドからの読み書きのスピードを変えるのだ。
記録されたメディアだけを見れば、線速度一定と変わらないように見える。
しかし、回転数は常に一定なので、回転の安定を待つ必要はなくなり、速度を上げられる。
この場合のデメリットは、内周と外周で読み書き速度が明らかに異なることだ。
内周のアクセスは、外周に比べて３倍も遅いことになる。
ここで、ふたたび話は「デフラグの効用」にもどる。
現代的には、デフラグとは「断片化の解消」ではなく、むしろ「頻繁に使われるデータを外周に集める」作業となっている。
もともと、多くの OS でディスクは外周から使っているため、特に初期状態ではほとんどのファイルが外周に集まっていることになるが、しばらく使ってからだと「最近作ったファイルほど内周に」入っている状態になる。
これを外周に出すことができれば、ディスクアクセス速度が体感できるほどあがることになる。
（先に書いた３倍は、読み書き速度のみ。実際には読み書き前のシーク速度の問題もあるし、ソフトウェア的なオーバーヘッドもある。でも、1.5倍速になれば体感できるほどの速度と考えてよい）
デフラグしたほうが良い、とする人々は、明らかに体感速度が上がることを最大の理由とする。
また、測定方法で大きな誤差はあるものの、速度は定量的に測定できるため、科学的なデータも伴う。
一方、デフラグしないほうが良い、とする人々の意見も、無視はできない。
デフラグによる最大のデメリットは、ディスクに対して明らかな負荷をかけることだ。
多くのデフラグソフトで、デフラグの「程度」を選んでデフラグを行うことができる。
単にデフラグを行うだけ、から、よく使うファイルを外周に集める、という作業まで。
デフラグという作業は、結構「場当たり的」なものである。
A というファイルをデフラグするために、後ろにある B というファイルの一部を移動した結果、今度は B にフラグメント（断片化）が生じるかもしれない。
A も B も C も…すべてのファイルが、同時に最短の手数でデフラグできれば良いのだが、そのような計算は複雑すぎて現実的ではない。
これに、さらに「よく使うものを外周に集める」なんて条件をつけると、計算の複雑さは破滅的なことになる。
結果として、一般的なデフラグ作業は、場当たり的に作業を繰り返し、無駄が生じても時間をかけることで全体の作業を終わらせている。
特に、長年使い続け、１度もデフラグをかけていないディスクに対して、「最大効果の」デフラグをかけた場合、ディスクを動かし続ける時間は非常に長くなる。場合によっては１日かかっても終わらない。
ハードディスクは、読み書きがないときは回転速度を落としていることが普通である。
これは、回転することで周囲の空気を巻き込んで渦を作り、空気の摩擦（と圧縮）で熱を持ってしまうためである。
理想を言えば回転を完全にとめてしまえば良いのだが、そうすると次にアクセスが発生したときに回転が安定するまで待つ時間が長くなるため、よほどのことがない限り、適当に速度を落として待機している。
逆に、アクセスし続けると、熱を発生し続けることになる。
そして、磁気記録媒体にとって、一番の敵は「熱」なのだ。
キュリー点を越えると磁性体は完全に磁性を失うが、そこまで行かなくても熱によって磁性は「減衰」するためである。
デフラグによって長時間ディスクが回され、それによって発生した熱によって、ディスクが破壊される、というのは現実味のあるシナリオだ。
これが、デフラグはしないほうがよい、とする人々の最大の論拠だ。
こちらは、可能性を指摘するだけで科学的根拠がない。というか、あげようがない。
実際、ハードディスクが「壊れる」というのであれば故障率を出さなくてはならないが、数千台を使うような実験は実際問題として難しい。
google は、「ハードディスクの故障率と温度は関連性がない」というレポートを出しているが、これは十分に空冷された状況での温度が前提である。
メンテナンスが不十分で、空気流入口にホコリが詰まったような古い PC で、ハードディスクをフル稼働すれば前提となる温度を簡単に超えてしまい、google ですらも「故障しやすい」と認めている温度に突入する。
科学的論拠がないのは弱いところだが、まったくの言いがかりでもない、というところか。
「するべきでない」派の人には、機械を動かせば当然金属疲労を起こして壊れる、という主張をする人もいる。
でも、これはあまり問題でないというか、言いがかりに思える。
ハードディスクの故障のほぼすべては、データが読み出せなくなる、というものだからだ。
この理由は二つで、磁気が弱まってしまったか、物理的にディスクに傷がついたかだ。
金属疲労でヘッドを動かすアームが折れる、というようなトラブルはまず起こらない。
磁気が弱まる理由は、先に挙げた熱もあるが、「記録してから時間がたった」というものも多い。
単に時間がたっただけで、ディスクは（というか記録は）壊れるものなのだ。
「するべき」派の人には、デフラグすることで再記録が行われ、記録が長持ちするようになる、という効用を上げる人もいる。
でも、じつはハードディスクは「読み出した際に、記録が弱まっていれば自動的に書き直す」機能を持っている。
だから、デフラグしたからといって記録が長持ちするようになるわけではないし、そもそも長期間ほったらかしのデータは、断片化を起こすわけもないので、デフラグ時にもほったらかしだったりする。
…などなど、デフラグを「するべき」「するべきでない」の双方に、ほかにもいろいろな主張があるが、怪しいものが多い。
さて、デフラグはするべきか、否か。
自分の答えは、もちろん「するべき」である。だから、先に書いた日記で、デフラグソフトの選定顛末を書いたのだ。
デフラグを「するべき」派と、「するべきでない」派の論争は、ちょっと両極端すぎるように思える。
デフラグというのは、一種のソートアルゴリズムだ。
ソートアルゴリズムはよく研究されているが、どんなアルゴリズムを使用しても、最大の効率を上げるのは「データがすでにソートされている場合」であることがわかっている。
なにもすることがないのだから、当然だ。
デフラグもソートアルゴリズムなのだから、「すでにデフラグされていれば、最大効率」である。
次に効率がよいのは、「ほとんど」デフラグが終わっている場合だ。
つまり、マシンが古くなって、動作が遅くなってきたからデフラグを行おう、では遅すぎる。
そのときには、デフラグをしなくてはならないファイルがあまりにも多すぎて、ハードディスクに大きな負荷をかけることになってしまう。
その負荷の大きさゆえに故障した、という例を持って「デフラグはしないほうがよい」というのは、極端すぎる意見だ。
でも、実は「デフラグをするべき」という人々の中にも、「デフラグ中の並び替え動作を見ているのがすき」という人たちがいる。
こういう人たちは、時々しかデフラグしない。だって、頻繁にやると、すぐにデフラグが終わってしまってつまらないから。
半年に一回とか、一年に一回とか、断片化を十分溜め込んでから、一気にきれいにする。
これだと、デフラグが好きだといっても、やっぱりディスクに負荷がかかる。
まぁ、気持ちはわかるし趣味なのでとやかく言うことではないのだけれど。
（まったくの余談だが、そういう人たちを満足させる、「わざとディスクを断片化させる」ツールまで存在する。
実際には、デフラグツールを評価する前に、十分に断片化状態を作り出すために作られたツールなのだけどね。）
僕が使うことにした、Smart Defrag 2 では、バックグラウンドで毎日勝手にデフラグを行う。
１回あたりの所要時間は、３分程度。しかも、バックグラウンドで動作しているのが気づかない程度の低負荷で実行している。
この程度の負荷でディスクが熱を持って壊れる、とは思わない。
もしこれで壊れるのなら、普段使いでも壊れるだろう。
週に一度、最適化を行って外周によく使うデータを集めるようにしてある。
これも、かかる時間は１０分以内だ。
Smart Defrag ではなく、MyDefrag でも、実行モードとして「Daily Defrag」「Weekly Defrag」「Monthly Defrag」などを用意している。
デフラグ後の状態としては、MyDefrag のほうが評判がよいので、こちらを使うのもよいと思う。
ただし、デフラグ中の動作は、SmartDefrag よりも重いし、時間も長くかかる。
さらにいえば、自動実行させる設定も面倒だ。
いずれにせよ、デフラグツールを作成する側としては、デフラグとは「毎日でも行うもの」であることを前提に考えているのだろう。
最後になるが、断片化している状態、については、どのデフラグツールも見解が一致している。
１つのファイルが分断して記録されていれば、それは誰が見ても「断片化」なのだ。
しかし、断片化「していない状態」については、見解が分かれるようだ。
たとえば、MyDefrag では、頻繁に更新されるデータファイルの後ろは、若干の「空き」があるのが正しい状態だ。
こうしておけば、ファイルが更新されても、デフラグを起こさないから。
でも、できるだけ多くのファイルを外周に詰め込む、という考えを持つと、わずかな「空き」は罪悪である。
ファイルが連続して入っていないということは、これも「断片化」の一種なのだ。
そのため、MyDefrag がきれいに詰め込んだ状態を別のソフトで見ると「デフラグが必要」といわれてしまったりする。
ここら辺になると、宗教論争。
宗教なのだから、自分が信じたデフラグソフト１種類だけを使って、ほかは寄せ付けない、浮気しない、という態度が必要。
もっとも盲信していると、よりよいソフトが出た時に気づかないことになってしまうので、時々世間を知るのはよいように思う。
僕は、以前は MyDefrag を使っていたけど、Windows7 再インストールを機に Smart Defrag2 に乗り換えました。
関連ページ
古くて非力なマシンをLinuxBeanで再生してみた【日記 15/10/23】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
別に誰に向かって書いているわけでもないんだけどさ。
2ch なんかのデフラグ関係の話題を読んでいると、デフラグ「すべき」派も「すべきでない」派も、ちゃんと理解しないで言っている節が感じられるもので、ついつい書きたくなってしまう。
Linux にはデフラグが必要ない、という人がいるが、そんなことはない。
デフラグツールなんてなくても、全ファイルを別のディスクにコピーすれば同じこと、という人がいるが、そんなことはない。
現代的な意味において、デフラグは「断片化の解消」よりも、「より高速な外周に、よく使うデータを集める作業」だということは、前回の日記に書いた。
Linux の ext3 は、ファイルの断片化を起こしにくい構造をとっている。これは事実。
でも、それは「ファイルの間に十分な隙間を開ける」ことで行われている。
もし断片化がおきそうなら、より大きな隙間を探してファイルを移動するので、ディスク容量に余裕があるうちは断片化は起こらない。
結果として、外周部分でもデータはスカスカ。使う頻度も特に考慮されない。
ext3 がデフラグを起こしにくい、ということをもって「Windows の NTFS は設計が悪い」という人もいるが、断片化を問題とするか、速度の速い外周を活かそうとするかの思想の違いであって、善し悪しではない。
NTFS では、外周を有効に使う代わりに、断片化を起こしやすい。
そこで、OS自体にデフラグを効率的に行うための仕組みを設けている。
だから、システムを起動して作業をしながらでも、バックグラウンドでデフラグができる。
実はこれはすごいことで、DOS 時代の（Windows98までの時代の）FAT では、システムを停止しないとデフラグできなかった。
おかげで、Windows にはシステム標準でもデフラグがついているし、市販ソフトも、フリーソフトもたくさんある。
一方、Linux にはこのような仕組みはない。
外周は有効に使えないし、断片化が起こってしまった際に解消する仕組みもない。
システムを起動したまま、どころか、停止したとしてもデフラグするためのツールは準備されていない。
ext3 の上位互換である ext4 には、デフラグのための仕組みが備えられた。でも、デフラグツールは開発中で、まだ提供されていない。
（開発途中版を使うことはできるけど、大事なファイルシステムに、バグがあるかもしれないデフラグツールを使いたい人はいるだろうか？）
なので、Linux ユーザーがいう「デフラグの必要がない」は、やりたくてもできないだけ。
外周を十分に使えないから、NTFS よりも遅い。
もっとも、NTFS を長年デフラグなしで使うと、断片化によって極端に性能劣化する。
ext3 ではそのようなことは起こりにくい。（起こりえない、ではない）
で、Linux ユーザーの窮余の策としては「ファイルを全部別ディスクにコピー」だ。
これでデフラグと同じ効果がある、とする。
Windows ユーザーでも、デフラグするとハードディスクの寿命が縮む、と信じている人は同じことを言う。
でも、この方法は、断片化解消にはなるけど、よく使うファイルを外周に再配置することにはならない。
最初に書いたように、現代的な意味でのデフラグの肝は、外周を使う再配置にある。
だから、ディスク丸ごとコピーではデフラグの代わりにならない。
ちなみに、ディスクを丸ごとコピーすれば、ディスクは動作し続けて熱を持つ。
デフラグがハードディスクに悪い、というのであれば、丸ごとコピーも同じようにハードディスクに悪い。
（もっとも、デフラグよりもアクセス時間は短いはずだ。その意味ではハードディスクへの悪影響を最低限に抑えられる。
理由は、「空の領域に移す」という、究極的に広い作業領域が与えられている上、断片化の解消だけが目的で、再配置が行われないから。）
ちなみに、僕 Linux 使ってますよ。盲信者ではないだけで。
ところで、断片化していなければ読み込み中のシークが発生しない、というのは真実ではない。
不良セクタがあれば、それはハードディスク最内周に準備された「代替領域」に書き込まれるから。
不良セクタの存在は、ハードディスク内で解決されてしまうので、OS からは見えない。
「連続領域に並べた」と思っていても、実は断片化している、という状態になるし、この際「外周に配置した」つもりでも、実は内周に置かれていたりもする。
もっとも、通常のセクタと比較して、不良セクタの存在する割合は非常に低いので、「確率問題として」普通は無視する。
SSD に関しては、はっきり言って知らん。僕は SSD 使ってないので。
XP では、SSD を HDD とみなして動作していたので、デフラグしないと性能劣化した、という。
（SSD の扱えるデータブロックよりも、一般的な HDD の扱うデータブロック（セクタ）のほうが小さい。
このため、SSD の１ブロックに、HDD の数ブロックを同居させることになる。
ここで「断片化」がおきていると、１ファイルの書き換えに際して、関係ないファイルも一緒に処理しなくてはならなくなり、結果的に速度が低下する。）
Windows7 では、SSD はちゃんと SSD と認識して動作する。
XP で見られた「HDD のまねをするため」の無駄はカットされ、SSD の性能を十分に引き出す。
デフラグ、もはや過去のものだ。
デフラグとは、HDD に対して必要なテクノロジーであって、SSD の性能を十分に引き出せるのであれば、不要だ。
つまり、３回にもわたってデフラグ話書いたけど、僕が貧乏人でいまだに HDD メインで使っているから、と考えてください。
関連ページ
古くて非力なマシンをLinuxBeanで再生してみた【日記 15/10/23】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
うかつな事に、１年近く前に「ゲームボーイシリーズが CPU に 8080 を採用」と書いてしまった。
その後、WEB 上の各種ソースをあたるも、みな「Z80」と書いてある。
おかしいなぁ、自分の記憶では、大学時代にバイトしていた会社で閲覧した任天堂公式資料に「8080カスタム」とあった気がするのだが。
（もっとも、社外秘の資料なので当然現在持っていないし、古い記憶なので思い違いかもしれない）
しかし、探せばあるもので、ゲームボーイ（以下 GB と書く）の CPU を詳しく解説した資料があった。
家には Z80 の資料はある。これで比較できる…
と思ったけど、それじゃ片手落ち。8080 も調べなくては。
で、調べたら、8080 と Z80 の機械語コードを、対比させて網羅しているページがあった。
これで比較ができる。
えーと、比較しながら、8080 / Z80 / GB CPU の動作詳細をまとめた資料を作ったのだけど、公開はしないでおきます。
長いばかりでつまらないから。知りたい人は、上のリンクを読んで自分で調べてね。
概要だけまとめます。
まず、GB CPU Manual は良い資料なのだけど、冒頭のほうにある CPU 機能のオーバービューは結構間違えているので注意するように。
後ろの CPU 命令の詳細資料は、ほぼ正しいと思われるけど、CB prefix 系の、BIT SET RES 命令のオペコードなどは間違えているようだ。
（疑問があったのでほかのソースも当たって判断）
で、8080 と Z80 と GB CPU の違いを、GB 主体で書くと次のような感じだ。
・Z80 で追加されたレジスタは、GB CPU には存在しない。
・当然、上記レジスタに関連する Z80 の追加命令は GB CPU には存在しない。
・Z80 で追加された命令のうち「ED prefix」系の命令は GB CPU には存在しない。
ED prifix 命令には、I/O命令、16bitメモリロード命令、16bit キャリー付加減算命令、割込み制御命令、Aレジスタの符号反転、メモリ 4bit ローテート命令、ブロック転送命令、ブロックサーチ命令が含まれる。
以上は、「Z80 で追加されたものは、GB CPU にはない」と言う話だ。つまり、単に 8080 互換。
・8080 から存在し、Z80 で拡張された「レジスタ交換命令」は、GB CPU には存在しない。
・8080 から存在し、Z80 で拡張された「I/O命令」は、GB CPU には存在しない。
・8080 から存在し、Z80 で拡張された、６個の「フラグ」を整理統合。
8080 由来３個(Z C H)、Z80由来１個(N)の４つになった。
整理されたフラグを使用した「条件ジャンプ命令」（8080に存在）は GB CPU には存在しない。
以上は、「8080 に存在したものが存在しない」と言う話だ。8080 のサブセットになった。
Z80由来のフラグ(N)が増えたが、実はこのフラグを使用する命令は、Z80 では増えていない。
そのため、GB CPU でもフラグが増加したにもかかわらず、命令は増えていない。
じゃぁ、なんのためにこのフラグが用意されたのか、という理由は次で述べる。
・Z80 で拡張された「CB prifix」系の命令（ビット操作命令）は、GB CPU にすべて存在する。
ビットテスト、ビットセット、ビットリセット、シフト、ローテートが含まれる。
（8080 には、A レジスタのローテートのみ存在した）
・Z80 で拡張された「相対ジャンプ命令」は GB CPU にほとんど存在する。
ただし、相対ジャンプと同時にカウントを行う「ループ命令」は存在しない。
・8080 では BCD 演算補助命令が加算時しか使用できなかった。
Z80 では、同命令の動作が変更され、加算だけでなく減算でも使用できるようになった。
GB CPU では、Z80 と同様の機能が存在する。
（先に説明した、Z80 でフラグが増加したのに命令が増えていないのは、この命令の動作変更のため）
以上が、「Z80 で拡張されたものが存在する」と言う話だ。
Z80 での拡張を含むので、GB CPU は Z80 のサブセット、と言えなくもない。
しかし、Z80 と比較した場合、「存在しない命令」がはるかに多く、8080 と比較した場合「追加・削除された命令」がわずかにある程度だ。
これで Z80 相当、と呼ぶのはつらい気がする。
GB CPU には、独自の拡張命令もある。
まずは、スタックポインタ（SP レジスタ）の演算命令。
8080/Z80 とも、スタックは「特別なもの」扱いなので、直接演算命令を用意していない。
１つづつの加算・減算程度はできるが、それ以上に複雑なことをするには、別のレジスタの仲介が必要で面倒だった。
GB CPU ではこれが改められ、スタックポインタも普通のレジスタの一種にしている。
直接読み出しができるし、直接加算ができる。
そして、「SP からの相対位置で」示されるアドレスからの読出しができる。SPレジスタ相対アドレッシングだ。
2017.3.27 追記
この部分、勘違いしてた。コメント欄で教えてくださっていた方がいたのに、気づくのが遅れました。
追加命令 LD HL,SP+n を勘違いしたのだけど、これは「SP に n を足した数値を HL に入れる」だった。
つまり、SP 相対アドレスを HL に取り出す、アドレス計算命令に過ぎない。（68000 や x86 の lea に類似）
元はこの後「ローカルスコープが作れるようになる」と書いていたが、上記のように勘違いなのでできない。
とはいえ、HL にアドレスを取り出したら、次は LD A,(HL) のようにしてメモリ内容にアクセスしたくなる。
すぐ下に書くが、HL によるアクセスは強力に拡張されているので、やはりローカルスコープを作り出す目的かもしれない。
メモリと A レジスタ間での読み書き命令も拡張された。
8080 の A レジスタと、アドレス直値で指定されたメモリとの読み書き命令は、「HL で示したアドレスに読み書きした後、HL を増減」という命令に変更された。
ポストインクリメント/デクリメント・アドレスレジスタ間接アドレッシングだ。8080 相当の CPU に付加するには、かなり強力な機能。
元の命令は、なぜか違う命令コードになったが、ちゃんと残っているのでご安心を。
また、アドレス FF00 に 1byte 数字、もしくは C レジスタの内容を足したアドレスに読み書きする命令も作られた。
これは、ファミコンで慣れた 6502 の０ページアドレッシングがほしかったのだろう。便利だからね、あれ。
と同時に、Z80 に存在する I/O 命令相当のこともこなしている（だから、Cレジスタでアドレス指定なのだろう）。一石二鳥の拡張命令だ。
（GB では、FF00 からの領域に、I/O と CPU 内部 RAM が配置されている）
レジスタの上位 4bit と下位 4bit を交換する、と言う命令もある。Z80 の 4bit ローテート命令とも動作が違う。
普通のローテート４回と同じだが、ゲームなので高速性が求められるだろうし、4bit 単位と言うのは、実際よく使うのだ。
携帯ゲーム機用らしく、省電力のための拡張命令も２つある。
ひとつは、8080 から存在する「CPU 停止命令」だ。本来の命令は、プログラムの実行が停止するだけで、CPU の機能自体はすべて動き続ける。
GB CPU では、CPU と ROM へのクロック供給を停止し、本当に CPU を止めてしまう。
ゲームは画面書き換えの 1/60 秒（以下、1インタと表現）を単位として動いている。
だから、すべての処理は１インタ以内に終わらせないといけない。
処理が「一番重いとき」でこの時間に間に合わせるのだから、通常は 0.8インタとかで終わらせていて、残りの時間は１インタのタイミングが来るのを待っている。
普通なら、「待っている」ためのプログラムを作る。何もしないでタイミングを待ち続けるループ。
これ、何もしていないけど、CPU としては動いているので電力を消費する。
ところが、GB CPU では、先に書いた CPU 停止命令がある。「何もしない」時に停止させてしまう。
停止した CPU を起こす機能もちゃんとあって、これが「画面書き換えのタイミング」に設定されている。
「画面書き換え待ち」という、本来やりたいことはちゃんと実現されているうえ、CPU を停止させることで電力消費を抑え、バッテリーを長持ちさせる。
（先に書いたように、処理が 0.8インタで終わるのであれば、CPU はゲーム時間の２割も停止し、その分省電力にできる）
この機能を CPU に追加させる、というのは、携帯ゲーム用に開発された CPU としては素晴らしい着眼点だ。
もうひとつは、「システム停止命令」だ。これは新設された命令。
GB の画面表示回路への通電を切った上、上に書いた CPU 停止状態に入る。いわゆる、サスペンドモードだ。
CPU 停止状態は割り込みがかかると終了するのだが、通常一番使われるのが、上に書いた通り画面書き換えタイミングの割り込みだ。
ところが、システム停止中は画面表示が停止しているため、これらの割り込みもかからない。
サスペンドモードは、ボタンを押すことで終了する。実は、GB では、ボタンはI/Oポートにつなげられているが、押すことで割り込みを発生することもできる設計なのだ。
割り込みの話ついでに、「割込みルーチンからの復帰」命令。
8080では、割り込みからの復帰は「サブルーチンからの復帰」命令で行う。割り込みというのは、強制的なサブルーチン呼び出しのことだからね。
Z80 では、割込み復帰命令と言う専用の命令が作られた。しかし実は、この命令の動作は「サブルーチンからの復帰」とまったく同じなのだ。実際、多くのシステムで、割り込みからの復帰にサブルーチンからの復帰命令を使って構わない。
じゃぁ、割り込みからの復帰命令っていうのは何なのか、って説明はややこしいので省略。
GB CPU では、割り込みが起こったときの CPU の動作が 8080 や Z80 とは違う。だから、サブルーチンからの復帰命令で戻ると、その後の動作がおかしくなる。そのために専用命令が準備された。動作が Z80 と異なるだけでなく、命令コードも違う。
GB CPU Manual では、この命令は「Z80 の命令コードを変えて残された命令」という扱いになっているが、これは GB CPU 独自の拡張命令と見たほうがよいだろう。
（アセンブラのニーモニックは RETI で同じだけど、これは RETurn Interrupt の意味にすぎない。Z80 と同じ命令だとする根拠としては弱すぎる。）
で、散々比較して思った。
元ゲームプログラマとしては、この CPU がゲーム向きに巧妙にカスタマイズされているのが、よくわかる。
特に、消費電力を抑える仕組みとか、割込み処理の変更とか、地味だけどよくできている。
GB CPU を作ったのはシャープ（LR35902という型番がついている）。
ザイログと仲がよく、Z80 のセカンドソース品も作っていたし、Z80 を使用した PC もたくさん出していた。
シャープは任天堂とも仲がよかった。
ファミコンは 6502 だったが、次のゲーム機ではぜひ Z80 を、と薦めたのではなかろうか。
でも、Z80 でアセンブラをやったことがある人ならわかると思うが、Z80 の拡張命令には、遅いものが多い。
便利でいいのだけど、速度が重視されるゲームではあまり使えない。
だから、ゲームを作るときは、ほとんど 8080 相当の命令しか使わないのだ。
Z80 の拡張部分は、CPU の回路を複雑にしているだけで、ゲームを作る場合にはほとんどが無駄。
その一方、ゲームにほしい割込み処理とかは貧弱で、まともな処理をしたければ周辺 IC を追加しないといけない。
回路規模が小さくなれば、CPUサイズも小さくなり、コストは下がる。周辺 IC が不要になれば、コストも下がるし機械も小さくできる。
「おもちゃメーカー」である任天堂が、携帯機を設計しているのだ。コストやサイズは気になるところだ。
だから、シャープの思惑通り Z80 を採用する交換条件として、大幅に機能を削り、CPU 単体で割込み処理などを行えるようにするカスタマイズを依頼したのではないだろうか。
この場合、任天堂の目指したのは「8080 カスタム」だろう。公式資料にそう書いていたとしても、おかしくはない。
むしろ、Z80 と書いてしまうと、機能を削除した部分が貧弱になったと批判されかねず、「8080 に機能追加した」としたほうが、いろいろな意味で穏当であっただろう。
一方、実際の回路は、シャープがザイログからライセンスを受けた Z80 の回路から、大幅に削除、追加して作られたはずだ。
というか、シャープはおそらくインテルのライセンスは受けていないので、政治的な理由で「8080互換」は謳えない。
だから、シャープの立場で言えば「Z80 カスタム」と言うのが正しい。
つまり、技術面では 8080 カスタムと呼ぶべきで、政治面では Z80 カスタムと呼ぶべき。
どちらで呼ぶかは、個人の感性（信条の）問題だ。
ところで、最初に「WEB 上の各種ソースをあたるも、みな「Z80」と」と書いた。
wikipedia にも、そう書いてある。（ゲームボーイだけでなく、シリーズ機種すべて、Z80 扱い）
ふと思ったが、wikipedia は、「印刷資料」を基に記事を書かないと、独自研究扱いなのではないの？
Z80 って書いてある印刷資料、どこかにあったのかな？
でも、日本の wikipedia は間違いだらけだから、と思って、英語版記事を見た。
そうしたら、Z80 とは書いていなかった。
「8080 に酷似した、SHARP の 8bit カスタム LR35902」とした上で、「Z80 の追加命令のいくつか、特にビット操作命令が存在する」と説明している。
事実をそのまま書いた冷静な記事。
主に日本語版の wikipedia に疑念を抱いて、Z80 なのか 8080 なのか躍起になって調べたのだが、日本語版の wikipedia の内容が「根拠なく書かれていた」と言うだけの話でした。
翌々日追記
海外でも、ゲームボーイの CPU は「GBZ80」と呼ばれることが多いようです。
で、技術系の解説サイトを見るたびに、「GBZ80 と呼ばれてるけど、8080 のほうが近いから」と断っていることが多いです。
上に書いた wikipedia での CPU 解説も、一部分のみ翻訳したけど、「Z80 じゃないから」と念を押すような文面でした。
こちらのサイトでは、「アセンブラはZ80構文を使うことが多いけど、同じじゃないから」という表記も見られます。
…つまり、「アセンブラがザイログ表記で書かれることが多いから、Z80だ」と考える人が多いのですね。
言語と CPU アーキテクチャは無関係なのに。
そういえば、自分のページに情報くれた方も、「ニモニックがZ80」だったから、Z80だと思っていた、と書いていました。
ザイログニーモニックは Z80 の全命令を網羅したものですが、その中には 8080 の命令セットも含まれるので、ザイログニーモニックで 8080 のプログラムを書くことも可能です。
「CPU メーカーがニーモニックを決定する」のであれば、ザイログのライセンスしか受けていないシャープとしては、ザイログニーモニック互換にするのが最も順当な方法となります。
さらに、ゲームボーイ発売時は Z80 プログラマが多数いましたので、8080 相当の機能しかないとしても、そのアセンブラに「普及言語」としてザイログニーモニックを選ぶのは、自然な流れであったのだろう、と思います。
しかし、ザイログニーモニックだから Z80 だろう、という類推をする人が多いのは、心情としても理解できます。
これで、なぜ Z80 と勘違いされるのか、という疑問が解けた感じ。
もうひとつ、Z80 は知っているけど 8080 は知らない人も多いようです。
この人たちに、「むしろ 8080 に近い」という言葉はまったくの無意味。
Z80 のほうが有名だから、と言う理由で「Z80 カスタム」と信じ込んでいます。
こちらの書き方をしているページは、技術を知らないのにスペックを書きたがる人に多いみたい。
正確さを必要とする wikipedia などでは、この書き方はどうかと思いますが…
いずれにしても、自分としては「Z80 カスタム」と思われている傾向について、調査を通じて納得ができました。
ゲームボーイの CPU は Z80 と言い切っていたり、リコーが Z80 をカスタムしたものと言っている人を見ても、寛容な気持ちでいられそうです。
2013.9.10追記
CPU 停止命令の説明がわかりにくかったことに気づき説明追記。（日記なのに後で書き変えてます）
補足説明なので元の記事と内容はかわりません。
最後に書いた、リコーがZ80をカスタムした…と書かれていたページは、修正されていました。
この日記を参考にしたことが明記してあり、お礼までされてしまった。
晒しネタに使って申し訳ありませんでした。
2014.11.8追記
コメント欄で誤りの指摘があり、修正しました。
僕の勘違いが２つ、意図が伝わっていないのが２つ。意図が伝わりにくい部分は加筆しています。
Twitter で「呼び方としては Z80 の機能削減と呼んでも良いのではないか」と僕に訊ねてきた方がいらっしゃいました。
僕がこのページを書いた意図は、書いた当時「Z80」だと言い切る方が多かったため、そうではないと伝えるためでした。
内容が正しく理解されていれば、それをどのように呼ぶかは個人の自由かと思います。
現状、Wikipedia で「Z80」となっていた部分も、「Z80カスタム」などに改められ、どう変わっているか明記されたようです。
CPU に関しては Wikipedia の英語版の表記が正確なので、日本語版でも英語翻訳するのが望ましいようにも思いますが、「カスタム」であることが伝われば嘘ではないでしょう。
このページを書いた当初の目的は果たせたかな、と思っています。
関連ページ
スーパーファミコンの発売日(1990)【日記 13/11/21】
別年同日の日記
16年 iOSでtextのコピー・ペーストができないバグの回避
申し訳ありませんが、現在意見投稿をできない状態にしています。 【名無し】 追記に「「ローカルスコープが作れるようになる」と書いていたが、上記のように勘違いなのでできない。」とありますが、GBZ80はSPへ -128～+127 の直値を加算する命令があり、ローカルスコープを作ることが目的のそれと思われます。 (2017-05-05 18:51:46)【あきよし】 気付くの遅れました。指摘ありがとうございます。全くその通りで、勘違いしたようです。本文修正しました。 (2017-03-27 15:32:30) 【雷更新世】 SP相対の読み出しはできないようです。「LD HL,SP+disp8」(表記は多種あるが機械語F8)がHLにSP相対の「アドレスを」ロードする命令なのを誤ってSP相対読み出しのように書かれている記述を見かけましたが、それではないでしょうか。 (2017-02-11 21:21:45) 【nasi】 wikipediaは「印刷」資料を基に記事を書かないといけないということはないのではないかと思います。ウィキペディアに執筆してよいかどうかの基準は「真実であるかどうか」ではなく「検証可能かどうか」です。つまり、私たちがウィキペディアで提供するのは、信頼できるソース（情報源）を参照することにより「検証できる」内容だけだということです。 (2016-07-20 16:29:46) 【名無し】 ご対応ありがとうございました。ローカルスコープを作りやすくする改良についてですが、ゲームボーイのCPUでは肝心のローカルスコープへのアクセスを行う命令(Z80でのインデクスレジスタ相対を扱うような命令)が強化されなかったので実際さほど便利にはなってないところが残念なところではありますね。 (2014-11-08 22:50:49) 【あきよし】 ご指摘いただいた内容を元に、内容修正しました。SPの扱い変更は少し詳細に踏み込み、ED系は「符号反転」に修正、フラグの扱いも少し踏み込んで書きました。（技術詳細を書きたいわけではなく、わかりやすい解説としたいため、踏み込み不足はご容赦を…） (2014-11-08 06:41:07) 【あきよし】 ご指摘ありがとうございます。実はZ80にはそれほど詳しくなく、SPを読み出す命令が無い、は誤りと後に知りました。が、ここでの主眼は「SP相対アドレッシングなど、ローカルスコープを作りやすくする改良が入っている」ことでした。 ED系に関しては指摘の通りの勘違いです。 フラグは、GBCPUに残されたNフラグのことを書いたのですが、意図が伝わりにくかったようです。 (2014-11-08 06:06:30) 【名無し】 「8080/Z80 とも、スタックは「特別なもの」扱いなので、演算命令を用意していない。」とのことですが、SPへの演算命令は8080のDAD SPやINX SP/DCX SPが存在します。HLにオフセットを代入したのちDAD SPを行えばGBのCPUに新設された「SPに直値を加えた結果をHLに代入する」命令と同等のことができるので、記事中で書かれていた「ローカルスコープ変数」は8080の頃から実現は可能です。 (2014-11-07 18:29:54) 【名無し】 「Z80由来のフラグが増えたが、実はこのフラグを使用する命令は、Z80 では増えていない。」とのことですが、ブロックサーチ命令等、P/Vフラグへの結果を見なければいけない命令は8080からいくつか追加されています。 (2014-11-07 18:24:00) 【名無し】 「ED prifix 命令には～Aレジスタビット反転命令～が含まれる。」とありますが、Aレジスタのビット反転命令は8080の頃から1バイト命令で存在します。Z80で新設された「Aレジスタの2の補数を求める命令」と勘違いされてるのでは? (2014-11-07 18:21:32) |