09 | 2017/10 |  11

  1. 無料サーバー

User forum-FC2BLOG-Info-Edit Template-Post-Edit-Upload-LogOut

CSSやJavascript自習の苦闘史を綴っていきたい。恐縮ですがJavascriptを有効にしてご覧ください。
2005年12月から社会問題も掲載!


スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

CATV 160MB コースに変更した

料金的に安くなるので CATV 回線に変更した

私は長い間 NTT Bフレッツを使用してきた。しかし、偶々 CATV 160MB コースを選択する機会があり、検討した結果その方が安くなるため、6 月 9 日に大凡 7 年ぶりにネット回線契約を見直した。

そこで早速通信速度の変化・向上を計測してみた。このエントリイはその過程をまとめたものである。

まず最初に何も設定を弄らずに回線速度を計測したところ、その結果は以下のようになった。

下り受信速度: 82Mbps(82.8Mbps,10.3MByte/s)

上り送信速度: 4.1Mbps(4.17Mbps,522kByte/s)

診断コメント: 160Mコースの下り平均速度は47Mbpsなので、あなたの速度はかなり速い方です!おめでとうございます。(下位から90%tile) 80Mbps以上出ており、超高速です。心よりお祝い申し上げます。

Windows 7 における RWIN 値

以上の結果にはさしあたり満足した。これまでの B フレッツでは 30~40 Mbps だったので、倍以上高速になったのだから。

しかし、当然のことながら欲が出た。もっと高速化できるのではないかと。

そこで、MTU や RWIN 値を変更するべく、最初は以前から使用していた通信環境設定アプリ EditMTU を使用して、闇雲に MTU や RWIN 値を弄ってみた。 EditMTU ダイアログに Vista や 7 設定タブがないことには気がつきつつも、XP タブで良いだろうと勝手に判断して作業したのである。

ところが、Comfortable PC で改めて調整してみようとして、そのアプリから提供されるコメントを見て知った───Vista 以降では RWIN 値設定そのものが無効であることを。

RWIN 自動チューニングレベルを変更してみた

そこで、Confortable pc 上で、RWIN 値の自動チューニングレベルを弄って速度計測結果を較べてみた。

既定値 normal を最大値となると思われる restricted に変更して計測し直してみた。

ところがその結果、何と 50 Mbps 程度に低下してしまったのである。

そこで色々な Web サイトで 7 の回線速度チューニングに関する情報を探ってみた。Hiroのパソコン何でも実験室 Windows7 ネットワークチューニング RWIN調整 autotuninglevelの設定変更 などが参考になったので、早速手探りでチューニングを試みた。

▲ToTop

結局 normal が最も速かった

RWIN 自動チューニングレベルを normal、heighly restricted、restricted と変更して速度計測を行ったところ、結局デフォルト値である normal の場合が最も高速になることが判明した。

また、RWIN 自動チューニングレベルの変更に当たって、netsh interface tcp set globalコマンドも用いて、コマンドプロンプトから設定変更を試みた。この方がダイレクトな操作感があり、何をどう変更しているのか一目瞭然なので、以後はコマンドプロンプトから操作した。

netsh コマンドを使用することにより、RWIN 自動チューニングレベルの変更は、再起動の必要性がないことも分かった。

つづく

スマホ(Android 携帯)の個人情報漏洩と今後の Android の行方

事件

アンドロイド携帯の個人情報漏洩が世間を賑わしている。アンドロイド携帯は、2011年度上半期国内出荷スマホの8割を占める(朝日新聞2012/1/14付け朝刊)らしいから、影響は深刻である。

同時に、2011年度末の国内携帯出荷台数では、既にスマホが従来型ケータイを凌駕する見通し(2012/1/28朝日新聞:「2011年度末にはスマホの出荷量が従来型の携帯を上回り、全携帯端末の56%を占める、2300万台の出荷量になると予想されている。」)なので、影響は甚大でもある。

それにしても住所、氏名、電話番号がいとも容易く漏洩していた事実には驚かされる。iPhone の場合同様の「事件」は起きていないが、今後の保証がある訳ではない。Apple 社のアプリ審査を信頼するしかないのだから。

そこで、グローバルスタンダード化したスマートホンの有り様、今後の行方について考えてみたい。

ケータイからスマホへ

2007年に発売された iPhone がスマートフォンに革命をもたらし、ガラパゴス携帯と称される日本のケータイにも大きな打撃を与えたことは疑いようがない。私は2007年の iPhone 登場段階で、これが在来のスマホと携帯の有り様を一新する画期的な発明であることを予想した(anything from here iPhone熱狂 in America. そして日本では?)が、現実にその通りの展開となりつつある。

また、後発の Android スマホが、かつて Windows が Mac を凌駕したように、iPhone を大きく上回って市場を制覇するであろう(anything from here iPhone vs Android の行方)とも予想したが、こちらも予想通りの展開となっている。

iPhone が切り開き後発 Android 端末が市場を爆発させた「キーボードレスタッチパネルスマートフォン」(KLTS)は、数年後には日本のみならず世界的にもケータイの大半を占めるシェアを獲得することは間違いないだろう。それ故に、セキュリティ対策や個人情報保護問題は KLTS の有り様の根幹に関わる極めて重大な問題であって、今回の事件は、Google 社製 OS :Andoroid のプライバシーポリシイの是非や顧客情報管理のあり方を鋭く照射している。

それにしても何故 Android スマホがそれほど売れるのか?

日本の通勤車内でも最近はスマホを操っている人を多く見かける。中には自慢気に iPad を操っている人も少数いるが、新聞を読んでいる人は更に少数派と言える程だ。そして車内スマホの多くは iPhone ではなく Android 端末である。

2011年度上半期の国内出荷スマホの 8 割もが Andoroid 端末であることは驚きだが、これ程までに日本で Android 端末が発売されるのは以下のような理由によると思われる。

  • 赤外線通信、お財布、ワンセグ受信などのガラパゴス携帯固有の機能を搭載している機種が多々あること
  • 画面サイズ、厚み、横長比等において多様性に溢れていること
  • 高解像度デジカメ機能を搭載した機種があること
  • 以上から iPhone に較べて選択肢が多様であること

つまり、日本固有のガラパゴス携帯文化の継承性が Android 端末の魅力となっているのだ。欧米諸国では Android 端末の 寡占状況は日本ほど極端ではないのではない(GoogleのAndroid、世界スマートフォン市場でシェア過半に――Gartner調べ - ITmedia ニュース によれば、世界のスマホ市場における Android シェアは 2011年第3四半期において、52.5%である。)ことがこれを証左している。

因みに、日本における Android は 2011年3月時点で iOS を凌駕したようだ。(Android:iOS=4,601万人:3,906万人───調査リポート:国内スマートフォンシェア、AndroidがiOS抜く 市場は1000万人規模に - ITmedia プロフェッショナル モバイル

▲ToTop

基幹的なアプリでも情報が漏洩する Android

「 Android の情報流出リスクが高いアプリと対策まとめ - NAVER まとめ」 によれば、情報漏洩に注意すべきアプリとして、Google Calendar、Google Contacts、Picasa Web Albums がリストアップされている。驚くべきことに、これらは皆スマホの基幹的なアプリであり、Google 社純正アプリである。

つまり、Google 社自身がプライバシー漏洩に一躍駆っていると言っても過言ではない。

しかも、以下のように余りにも無防備なのだから更に驚愕を覚える。

  1. 公衆無線LANを介して他人が簡単に情報を見られてしまう
  2. カレンダーや連絡先の個人情報にアクセスできる
  3. 理論上すべてのGoogleサービスに対し、なりすましが可能
  4. HTTPを介して暗号化されないまま送信されている

まるで垂れ流し状態、暴露放題だ。これでは Android は全く信頼に値しない OS であると言っても過言ではないのではないか!

更に、Andoroid のバージョンアップ履行や公衆無線 LAN 不使用によって回避できるとはいえ、以下のサイトで述べられているように99.7%の Android 端末から情報漏洩の虞があるのだから事態はますます深刻である。

99.7%のAndroid端末に情報漏えいの危険、ドイツの研究者が指摘 -INTERNET Watch

Google 社に奢りはないか?

数年前に NHK が Google 社の躍進ぶりを特番で報じたことがあった。その中で検索結果ランキングが Google 社により意図的に操作されていることを臭わす事件が報じられ、検索結果にリストアップされなくなった会社の訴えと、それへの Google 社の反論が紹介された。

注目すべきはその G 社の反論内容である。検索結果に「リストアップされなくなった会社の Homepage 内容がリストアップに値しないから表示しないのだ」───このような趣旨の反論が展開されたのだ。この主張は G 社が自己をまるで Web サイトの価値を判定する神のごとき存在として、定立していることを意味している。

この反論には呆れかえり、奢りを感じたことは言うまでもない。今を時めく IT 最先端企業に、実は成り上がり者的な悪臭が漂っていることにがっかりしたことを、今でも鮮明に覚えている。

「2011年12月17日以降に日本で起きた有料アプリ購入者の詳細情報漏洩は、(ウィルスによるものではなく)システムの不具合が原因だそうで、2012年1月12日迄に修正された」(朝日新聞2012/1/13夕刊)そうだが、「詳細部分を除く住所やメルアドが有料アプリ提供業者に提供される仕組みは今後も続く」(朝日新聞2012/1/14)のだから、安閑とはしていられない。

そしてこの個人情報は Google 社によって一元的に管理されているのだから、G 社の姿勢によって情報流出はいかようにもコントロール出来る訳で、G 社はアップル社のようにアプリ提供業者に流す情報を販売数に限定すべきだろう。

▲ToTop

今後の Andoroid

Android の問題はシステムの不具合に起因する情報漏洩に留まらない。言わずもがなのウィルスの存在である。無審査アプリを認めている無政府性がウィルスを野放しにしているだ。

一方で、Apple 社の iPhone アプリ審査基準が不明瞭との指摘もあり、審査=是と単純化することは出来ないものの、ウィルスの蔓延を手をこまねいて放置するのもおかしい。現状のままではセキュリティ対策アプリ業者を喜ばすだけであって、決してユーザー本位の姿勢とは言えまい。

勿論、無料アプリなのだからそこまでの責任はない、との主張は身勝手すぎる。世界標準化しつつある故に、無料であっても社会的責任を果たすべきだろう。

このままウィスル蔓延が放置され続け、OS やシステムに起因する情報漏洩が繰り返されるとすれば、Andoroid の命運は尽きてしまうかもしれない。

そしてスマホの行方

スマホは今後も成長し続けるだろう。そして近い将来ケータイはスマホに駆逐される。

その時でも iOS の無料化は行われないだろうし、iPhone の閉鎖性も変らないだろう。他方、Android は無料のまま推移するだろうし、おそらくAndroid アプリの審査制度は膨大な費用が掛るため発足しないだろう。

このような見通しに立つ時、急成長した Android 端末は、「奢れる者久しからず」、「栄枯盛衰」の喩えのように一過性のものとなってしまうかもしれない───と推測してもあながち間違いではない。

Windows 7 と XP のデュアルブートを行う

職場の或るシステムが 7 では動かないため、やむを得ず 7 と XP のデュアルブートを設定した。

今回初めてマルチブートにチャレンジしたのだから苦労するだろうとは思っていたが、特に、7 をインストールすると、一般的には隠れパーティションが自動的に作成されてしまうことについて、事前に知らなかったこと、また、パソコン起動の過程(BIOS→MBR→PBS→OS)について知識としては知っていたものの、具体的にそれらを操作したことはなかったこと───などから、設定開始から成功に至までに一週間以上を費やす羽目となってしまった。

このエントリイは、その苦労の中で得た教訓をまとめるものである。

なお、今回お世話になったサイトについては、以下に逐一紹介しながら謝意を表すこととしたいが、さしあたり総合的な情報を掲載してくれている次の3つのサイトに多謝を表したい。

Windows 7 インストールによるパーティション構成

Windows 7 を新規インストールすると、これまでの Windows とは異なって、ハードディスクには隠れパーティションが「一般的に」自動的・強制的に作成される。ここに「一般的に」とは、私の自宅 PC がそうであったように「既存のアクティブなプライマリパーティションが存在する場合は、或いは既にプライマリパーティションが存在し、既存のパーティションに Windows 7 をインストールする場合は、新規にシステムパーティションが作成されない」からだ。(※ Windows 7のインストールにおけるパーティション構成とデュアル/マルチブート。このサイトには隠れパーティションが作成される場合とされない場合の法則性が詳細に述べられている。)

今回マルチブート設定を行った職場の PC の場合、XP インストール済みの状態から 7 にアップグレードしたのだが、このために HDD は一旦初期化された。つまり「既存のアクティブなプライマリパーティションが存在せず、かつ、Windows 7/2008 R2を空き領域にインストールする場合で、Windows 7/2008 R2をインストールするパーティション (ブートパーティション) の他にプライマリパティションを作成する余裕がある場合は、新規に100MBサイズのプライマリパーティションが作成されて、そのパーティションがシステムパーティションにな」ったわけだ。(同上より引用)

隠れパーティションについては以下のサイトも参考になる。

Vista 使用時点迄は、隠れパーティションと言えばリカバリ領域くらいしか知らなかったし、実際に目にする隠れパーティションもそれだった。

しかも、自宅の PC では偶々 7 用の隠れパーティションが作成されなかったため、7 独自の隠れパーティションについて知る由もなく、一般的なケースに対する認知が遅れてしまった。このことが、マルチブートを実現する上で災いしてしまった。

▲ToTop

マルチブートを実現したハードディスクのパーティション構成

一般的に、マルチブートを実現するハードディスク環境は、複数のハードディスクに OS をインストールする場合と、1の HDD 内の異なるパーティションに OS をインストールする場合とに大別されるが、今回行ったのは後者のケースだ。しかも、後発の OS を後からインストールしたのではなく、逆に 7 を先行してインストールし、その後同一の HDD の異なるパーティションに XP をインストールした。

7 インストール後・XP インストール前のパーティション構成は以下のようになっていた。4 つの領域が存在していたが、そのうち partition 1 と partition 2 がドライブレターが割り振られていない隠れパーティションだった。2 つも隠れていたのである。

このパーティション構成は、XP にダウングレードされた PC を 7 にアップグレードした時点で作成された物であり、機種は富士通の ESPRIMO D5290 である。

  • partition 1 …… プライマリパーティション、リカバリ領域(8GB)
  • partition 2 …… プライマリパーティション、システム領域(100MB)
  • partition 3 …… プライマリパーティション、Windows 7 ブート領域(70GB)
  • partition 4 …… プライマリパーティション(70GB)、データ領域

このケースで XP 用のパーティションを作成するために、MBR の制約から partition 4 を拡張パーティションに変更し、その中に 2 つの論理パーティションを設けた。

具体的には、partition 4 を データ領域とする D ドライブと、XP インストール用の E ドライブとに分けて、データ領域は 2 つの OS から共用することにした。こうして実質的なパーティション数は5となった。

  • partition 1 …… プライマリパーティション、リカバリ領域(8GB)
  • partition 2 …… プライマリパーティション、システム領域(100MB)
  • partition 3 …… プライマリパーティション、Windows 7 ブート領域(70GB)C ドライブ
  • partition 4 …… 拡張パーティション(70GB)
  • partition 5 …… 論理パーティション、データ領域(30GB)D ドライブ
  • partition 6 …… 論理パーティション、Windows XP ブート領域(40GB)E ドライブ

このようなパーティション構成にしたのは、どちらの OS を使用する場合でも、データを可能な限り D ドライブに置くルールを統一的に適用するためだ。更に言えば、必要となる限りの同一のアプリケーションをそれぞれの OS にインストールして、プロファイルやテンプレートなどを共用しよう、と考えたのである。

蛇足ながら、7 用にインストールしたアプリケーションの内、XP 側からはショートカットを作成するだけで共用出来るものもあるのではないか(registryを使用しないアプリケーションは明らかにそれが可能なはずだ)、とも考えており、その際でもデータが D にあった方が管理しやすいと思っている。職場ではこれまで所謂 D ドライブ主義を強調してきた経緯もあるので、「データは D ドライブ」を通したいのだ。

マルチブート設定に当たって

MBM (Multiple Boot Manager) は使用しなかった。Windows だけのマルチブートであって、Linux 等の他の系列の OS は職場の PC では全く使用しないからだ。

次に、コマンドプロンプト内での bcdedit によるブートメニューの設定には、「落とし穴」があって使いにくいので、最終的にはフリーソフト EasyBCD のお世話になった。

落とし穴とは、bcdedit のコマンド記述におけるドライブレターやディレクトリ指定が、結構間違いやすいということだ。(次項で述べる)

まして隠れパーティションをそのままにしてマルチブートを構成しようとすると、当該パーティションにドライブレターが割り振られない状態での作業となるため、そこで行き詰まってしまう。

そこで、実際には隠れパーティションにドライブレターを割り当てて作業を行った。

▲ToTop

bcdedit 操作における落とし穴(間違いやすい箇所)

bcdedit の操作方法は多くのサイトで紹介されているが、要点が明らかにされているサイトは少ない。何が問題か、以下に示してみたい。

以下の例は、e ドライブにインストール用 Windows 7 DVD があり(1行目)、システムドライブが c(3行目)、そのルートに ntldr ファイルが存在している(4行目)場合の記述である。

この場合のポイントはピンクで示した 2 箇所だ。

  1. e:\boot\Bootsect.exe /NT60 All
  2. bcdedit -create {ntldr} -d "Windows XP Pro SP3"
  3. bcdedit -set {ntldr} device partition=c:
  4. bcdedit -set {ntldr} path \ntldr
  5. bcdedit -displayorder {ntldr} -addlast

第1のポイントは、XP 用の ブートローダーである ntldr ファイルが、どのドライブ(=パーティション)に存在しているのか、それを指定する 3 行目だ。

隠れパーティションが存在せず、C ドライブに Windows 7 がインストールされているならば、上の例のように partition 指定は c で何ら問題はない。しかし、隠れパーティションが作成されている場合には(Windows 7 インストール済みの PC を購入した場合、おそらく隠れパーティションが存在しているはずだ。それが基本的な仕様なのだから。)、これにマルチブート用の XP をインストールすると ntldr ファイルは隠れパーティチョンに置かれ、決して c ドライブには存在しない。つまり、上の 3 行目のような指定は間違いになる。

Web サイト上の bcdedit に関する記述は、おしなべて partition=c: と記されており、異なる表記は皆目見付けられなかった。システム領域を隠れパーティションとするインストールが一般的なのに、相変わらず Vista 時代の C ドライブ主義的な記載が横行していることは残念なことだ。

隠れパーティションにはドライブレターを使った指定は行えない。隠れパーティションにドライブレターを振って隠蔽状態を変更するか、あるいは、partition=\Device\HarddiskVolume2 のように指定しなければならない。

そのことに触れたサイトは殆どないのだ!───とサイトに恨み言を言ってみても始まらないが、7 に対応したマルチブートコンテンツがもっと流布して欲しいと願うのは、私だけではないだろう。

なお、上記の Volume 指定で何故 Volume1 ではなく Volume2 なのか?───それはリカバリ領域がディスクの最初に配置されている場合の対応だからである。隠し領域の2番目がシステム領域になっているために、volume2 と指定しなければならないのである。

こうして隠れパーティション(システム領域とリカバリ領域)の存在が、ネットで数多く紹介されている「partition = c:」という指定方法を無効にさせてしまうのだ。ネットの限界というか、もっと親切な指定方法が記述されていれば、苦労は半減していただろう。

2 つ目のポイントは、4 行目の ntldr の在処を示すディレクトリ指定である。今回の作業では、4 行目の指定方法では「アプリケーションが存在しない」との警告が発せられ、XP を起動出来なかった。行き詰まってしまって EasyBCD に頼って初めて ntldr ファイルのディレクトリ指定は、path \ntldr ではなく path \NTL\ntldr でなければならないことが分かったのである。

何故、ルートディレクトリィではなくNTLディレクトリィ内に ntldr ファイルが格納されてしまったのか、その経緯は皆目分からないが、ここでもネット検索結果が災いしてしまって、調整に膨大なエネルギーを費やすことになってしまった。因みに、マルチブートを扱った Web サイトの中で、ntldr がルート以外のフォルダ内にある場合の指定方法に言及しているものは 1 つも見つけられなかった。

EasyBCD を使うメリット

EasyBCD を使う上で、EasyBCD - Windows Vista 以降のOS のブートマネージャーを編集するツール:MikasaPHP が多いに参考になったので謝意を表しておきたい。

システム領域の NTL フォルダの中に ntldr があると何故分かったのか?───それは行き詰まってしまってやむを得ず EasyBCD の自動指定を援用したからである。そもそもシステム領域のルートディレクトリにもntldr が存在していたからこそ、それを使って XP が起動出来ると思い込んでしまい、全く起動出来ないまま原因解明に多大な時間を費やして来た。それでも埒があかないので、EasyBCD のお世話になったのだが、何故システム領域内に二重に ntldr が存在することになってしまったのか、その原因は分からない。

ブートメニューの自動登録

EasyBCD の Add New Entry 項目において、XPを選択し、Automatically detect connect drive をオンにして XP ブートメニューを追加したところ、\NTL\ntldr が取得されたのだ。

つまり、EasyBCD を使ってディレクトリを自動選択させたことにより、 bcdedit では出来なかった適切な指定を実現することが出来たのだ。

WIndows7 インストール直後メモ(1) スリープからの自動復帰を止めさせた

1/13 追記:イベントビューアーからも原因が特定出来た

以下に述べるように、手作業的試行錯誤の結果スリープ状態からの自動・強制復帰問題は解決したが、或るサイト(こちら:Windows7の勝手にスリープから復帰・起動する問題その3(解決糸口の探り方編))にイベントビューアーで原因を特定する方法が述べられていたので、それを参考に早速ビューアーでチェックしてみた。

その結果、見事に( って当たり前だが(苦笑) )以下で特定した問題が原因であることが再確認された。

そもそも、最初からこの方法で原因を特定すれば苦労はなかった。職場のPCでスリープに入れない問題が発生しているので、早速イベントビューアで原因を特定してみるつもりだ。

ハイブリッドスリープは結構な機能だが...

Vista で2年余り使い続けた PC の OS を、この正月休みに 7 に新規アップグレードインストールしたことは前のエントリイで触れた。

このエントリイでは、各種アプリのインストールが約7割方終わり、愈々各種アプリケーションを使い始めたその直後から、困り果てていた或る問題が解決したので、その顛末を綴っておきたい。

問題とは、スリープに入れないことだ。今回それが、「一応、さしあたり」解決したのである。

ハイブリッドスリープは 7 で初めて導入された機能だ。それはスリープと休止状態を兼ねた、それ故にハイブリッドなスリープ、またはハイブリッドな休止状態である。しかし、これに対応していないハードが結構存在していて、それが混乱の元となっているのだ。

【例1】
例えば、職場のカードリーダー/ライター(日立製)の場合(これは個人認証に使っているため、業務上使用しないわけにはいかない代物だ)、スリープには入れるものの、眠りから覚ますことが出来ない。PC を覚醒させるには、当該カード読取/書込装置を USB ポートから物理的に取り外してから覚醒操作をするか、数秒電源ボタンを押し続けてから強制シャットダウンして、通常の電源オン操作を行って再起動するしかない。

【例2】
自宅の PC の場合、結論を言えばネットワークアダプタの電源遠隔操作機能を停止させないと、スリープに一旦入るものの、10 秒ほどでスリープから自動的・強制的に復帰してしまうことを止めることが出来なかった。

なお、遠隔操作を停止した操作説明図は以下の通り

deviceManager deviceManager

2 番目の図の「このデバイスで、コンピューターのスタンバイ状態を解除出来るようにする」をオフにしたのだ。その後ハイブリッドスリープに入らせてみたところ、これまでのように強制的・自動的に目覚めることはなく、所定通り、キーボード操作によって PC をハイブリッドな眠りから目覚めさせることに成功したのだ。(後述するように、マウス操作によってはスリープから復帰出来ないように、デバイスドライバ設定を変更した。)

▲ToTop

原因究明に"あくせく"

ネット検索を掛けた結果、usb ハードディスクとの相性問題や、電源タップ上での電源コードの接続問題(連動機能のあるタップかどうか)など、物理的な問題が原因と思われたので、タップを取り替えたり、差し込む位置を変えたり、usb ハードディスクを全て切り離してみたり、色々と試してみた。しかし、それらの全てにおいて、スリープ状態からの 10 秒程度での自動的・強制的な復帰を止めることが出来なかった。

昨晩と今晩、合計 2 時間以上要して試行錯誤したが、結局解決策を見いだすことが出来ないまま、時が流れたのだ。

そこで、どうにも分からないので更に検索を掛けたところ、デバイスドライバを弄って、各デバイスからの電源管理機能を変化させることによって、スリープ問題から脱出出来た、との情報を入手出来た。それがこれだ。→ MacBook (Pro)でWindows Vistaのスリープ時のトラブルを回避するには - パソコンよろずQ&A

このサイトの中程に、「スリープに移行できない・勝手に復帰してしまう問題を解消するには」なる項目があり、そこでデバイスマネージャ上で、デバイスの電源管理機能を変更して解決した例が解説されていた。

即座に「これだ! 」と感づき、怪しいデバイスを全てチェックし、1つずつ影響を調べてみることにした。

▲ToTop

電源管理を行えるデバイスはかなり多く存在しているが...

実施に影響を与えていると思われるものは殆どなく、デバイスドライバ一覧のチェック開始から数分後に辿り着いた犯人とおぼしきもの、それがネットワークアダプターだった。

それにも電源管理タブがあり遠隔操作が可能となっていた。直感的に、これが原因かもしれない、2年半前に購入した PC なのでハード的に、あるいは BIOS が、ハイブリッドなスリープには対応していないのかもしれない。遠隔操作( Wake On 操作)は全くしないのだから、デバイスのこの機能を止めても何の支障もない。ならば、とりあえず、さしあたり遠隔で可能となる Wake On 機能を止めてみよう!───と判断したのだ。

そして実際、ネットワークアダプタの Wake On 機能を停止したところ、全く問題なく眠りには入れたし、自動的/強制的に目覚めてしまうこともなくなったのだ。

以上、試行錯誤の結果ハイブリッドスリープのエラーから脱出出来た、簡単なメモである。

付記:マウスからは復帰出来ないようにした

マウス操作によってスリープ状態から復帰出来てしまうと困ることがある。

物が一寸マウスに触れただけで、あるいはマウスを一寸動かしただけで、PCの眠りを覚ましてしまうことがママあるからである。起動するつもりはなかったのにマウスが動いたためPCが起動してしまった、と言う事例には事欠かないのではないかと思う。

だからデバイスドライバのチェック序でに、マウスによる電源管理機能をオフにしたのである。その結果電源ボタン以外はキーボードからのみ復帰が行えるように改善されたのだ。

OS を Vista から 7 にアップグレード

このエントリイはいわば備忘録である。

今回 OS をアップグレードした PC の環境

アップグレードの経緯を記す前に、どんな PC でそれを行ったのかをまとめておく必要がある。そうしないと第三者には、このエントリイが閲覧に値するのかどうかさえ分からないだろう。

  • 導入時期:2008年8月中旬
  • PC:Dell XPS420
  • 内蔵HD:750GB( C:80GB、E:15GB、D:残り の 3 パーティション分割)
  • CPU:Core(TM)2 Quad CPU Q9450 @ 2.66GHz
  • Memory:4GB
  • OS:Vista
  • インストールされたアプリ数:219(App2Txtにて取得した数)
  • その他:アップグレード直前に C ドライブをイメージバックアップ済み

以上の PC において、OSを 7 にアップグレードしたのだが、CPU は幸いにも XP Mode 導入条件をクリアしていた。また、D ドライブには各種の My データファイルやATOK 辞書バックアップが収められていたが、それは 7 移行後も利用するためにそのままとした。

上書きではなく新規インストールを行わざるを得なかった

発売から 1 年余経過した 2010 年 12 月下旬、やっと Windows 7 に乗り換えた。正月休みを利用して作業しようというわけだ。

XP の時も Vista の場合も、プリインストールされた新規購入パソコンで導入したので、別の OS がインストールされた手持ちの PC の OS アップグレードは初めてのことだ。

さて、手持ち PC のアップグレード前の OS は Vista だったので、上書きインストールも可能であった。そして実際その選択肢を選んだ。

しかし、インストール前の互換性チェックにおいて、幾つかのデバイスドライバに互換性がないとの判断が、Windows 7 DVD から返され、結局上書きインストールは出来なかった。

各種 Web サイトから得られる情報に拠れば、そもそも上書きインストールはすべきではない、とは判断していたが、200 を越えるアプリの再インストールは余りに面倒に思われたので、試しに上書きしてみたい、と易きに流れたのだが、まさかデバイスドライバに蹴られるとは思いもしなかった。そんなことはインストール時に当然自動的に解決してくれる筈だ、と高を括っていたのだ。

結果的には、上書きインストールに拠る混沌状態に陥ることを避けられたわけではあるが、どうもスッキリしない。その後のゼロからのアプリインストールは、予想したとおり余りに退屈で、膨大な手間暇が掛る味気ないものだったのだから。しかも 7 インストールは 1 時間程度で終わったが、その後数日が経過した今日に至るまで、予定したアプリのインストールはいまだに 8 割程度しか終わっていないのだから。

Windows 7 のインストールに係る Web サイトの多くには「上書きインストールを行うと障害が出る可能性が高い」と記述されている。だから、新規インストールにならざるを得なかったこと、膨大な手間暇を掛けてアプリを順次インストールせざるを得ないこと───これらは上書きインストールによる障害を回避する適切な選択肢だったのだ、と自分を納得させ、慰めるしかない。

各種のユーザーデータフォルダを D ドライブに移行する

Vista 導入時にもかなり悩んだことであるが、今回もユーザーデータフォルダの扱いには相当迷った。そして、最終的に C:\Users フォルダ全体を D:\Users に移行した。さんざん(と言っても 3 日程度であるが)迷った挙げ句に決行したのだ。

Users フォルダ全体を D ドライブに移行する前には、「せめても」と思い、ドキュメント、ミュージック等々の個々のユーザーデータフォルダはその全てを D ドライブに移行した。しかし、その時点ではまだユーザーフォルダ自体は C ドライブに残していて、ユーザーフォルダの全てを D ドライブに移すかどうか迷い続けていた。

実は一度は、ユーザーフォルダ全てを D ドライブに移してみたのだが、敢えなくそれが失敗し、Windows 7 が起動しなくなってしまった。その結果は惨憺たるもので、結局、Windows 7 を 再度インストールする羽目になってしまった。受けた心的ダメージはかなり大きかったことは言を待たない。

そもそも、Vista でも個別のデータフォルダは全て D ドライブに移行して使っていた。そして、7 への OS アップグレード後も、D ドライブは以前のまま残しておいたので、それを継続して使用することが出来る。だから、尚のこと、個々のデータフォルダは D ドライブに移すことが得策であり、また当然のことであるが、C ドライブのイメージバックアップを行う場合においても、データフォルダは C ドライブにないに越したことはない。

だから個々のデータフォルダを D ドライブに置くことは必要不可欠でもあった。

▲ToTop

ユーザーフォルダ全体をDドライブに移行する!

しかし、個々のデータフォルダだけを D に移行してもまだ、AppData フォルダや Application Data フォルダ等の Windows システムに関わるフォルダは、相変わらず C ドライブに残っており、これではいかにも「中途半端」である。

だからこそ、Users フォルダ全体を、つまり個々のデータフォルダだけではなく、システムに関わるフォルダやレジストリデータを含むユーザーデータを、しかも全てのユーザーを包含している Users フォルダ全体を、D ドライブに移してしまうことが論理的にはスッキリする。

そして、Users フォルダ全体を D ドライブに移行する方法に係る Web サイトも幾つか存在している。

当初は、これらに記されている方法に従って作業出来なくもない、と思われた。

また既に廃刊となってしまった『PC Japan 2008年4月号』の 「特集1:Xp/Vista 高速化マニュアル」でも、特定のユーザーフォルダの D ドライブへの移行方法について簡単に既述されているので、それに従って作業出来なくもないと思われる、

しかし、私にとって何よりも重要なことなのだが、どうしてそのようにすれば可能となるのか、その理屈がどこにも書いてないのだ。それ故に納得しきれないし、現に闇雲にトライして一度は失敗してしまった。

もう二度と失敗したくないからこそ、確実に理屈を理解し終えてから、ユーザーフォルダ全体を D ドライブに移行しようと考え、改めて、registry 構造とそのファイルについて学習し直し、ついに、完璧に C ドライブの Users フォルダ全体を、D ドライブに移行することに成功したのだ。

この場を借りて上記 Web サイト作者の方々に多謝を表しておきたい。

「Virtual PC + XP Mode + 統合環境ツール」の需要の強さ

NEC 製の職場の或るシステムは Vista でも 7 でも動かないらしい。つまり、XP 下でのみ動く。

しかし、XP のサポートが今度こそ打ち切られるであろう 2014 年 4 月を 3 年後に控えて、全てのパソコンは可能な限り早期に 7 に移行すべきだし、職場の IT 環境管理部門もそれを認めざるを得なくなっている。昨年 10 月下旬以降、もはや XP プリインストール PC は入手出来ないし、勿論パッケージで XP を入手することは遙か以前から出来なくなっている物理的環境がそれを後押ししている。

それでも尚、借金苦に溺れている日本国政府ではまだ XP が全盛らしいが、あちこちの会社・自治体・団体において、Windows 7 への移行は地デジ同様に「押しつけられた環境」ながらも、静かに、しかし広く浸透しつつあると思われる。

となれば、7 で動かないソリューション、アプリ、グループウェア等々の「資産」を活用する必要が、広く社会的に涌起っていることもまた、間違いない。

だからこそ、Microsoft 社はこのような背景を当然視して、Windows 7 に「Virtual PC + XP Mode + 統合環境ツール」を搭載出来るようにした───このことは火を見るより明らかだ。

MS 社の「Virtual PC + XP Mode + 統合環境ツール」に関するサイトを見ても、Windows 7 においては、これまでの「ソフト資産」の活用に配慮したことが、得意げに述べられていることはその証左だ。

だからと言うわけでもないが拙 PC にも仮想マシンを導入した

Users フォルダ全体を D ドライブに移行した直後だけに、心なしか不安がなかったわけではないが、6 日帰宅後に必要なダウンロード、インストール、設定、ウィルスソフトのインストール、ATOK インストール等々を履行し、仮想マシンである Virtual PC 内にインストールした XP Mode の設定を終えたのだ。

ここではその過程を詳らかにするつもりはないが、結構ドラスティックな作業だけに、数回の再起動を繰り返す度に、次は起動してくれるかどうか一抹の不安につきまとわれながらの作業とならざるを得なかった。

それでも兎に角、現在は Users フォルダ全体の D ドライブへの移行と、バーチャル PC・XPモード・統合環境ツール の導入が成功裡に終わったことに胸をなで下ろしている。

▲ToTop

デバイスドライバーのセットアップにおける注意点

既述の通り、上書きインストールを試みたが、デバイスドライバの互換性問題でその実行を妨げられた。

だから、新規インストールした時には、各種デバイスドライバは全てユーザーが自前でインストールしなければならない、と考えた。それが論理的帰結というものだ。

こうしてプリンタ及びスキャナのドライバはネットで探して 7 対応版をダウンロード・インストールした。

次には、ディスプレイ、音源ボード、USB 3 対応ボードなどの、我が PC に内蔵されているハードウェアのデバイスドライバをインストールしようとしたのだが、これらの一部がネット検索を掛けてもなかなか特定出来ない。製品マニュアル等を見ても尚、どのドライバが適正なのか判断出来ないケースが出てきたのである。こうして、またしても作業は渋滞を強いられた。

ところが、偶々なのだが Windows Update を弄っていると、何と更新リストにディスプレイや音源ボード等のハードウェアのデバイスドライバがリストアップされているではないか!

インストール時には蹴ったのに、インストール後には自動アップデートリストにノミネートするなんて、理屈が通らない! だったら上書きインストールの際に更新するようにプログラムすれば済むことだ!───と、Windows 7 インストール DVD の不合理な対応に思わず怒ってしまったのだった。

▲ToTop

プリンター・スキャナードライバーのインストールとセットアップにおける留意点

流石の WindowsUpdate もこれらについては何も教唆してくれない。自前で用意しインストールとセッティングを行わねばならない。

幸いどこのメーカーでも最新のそして 7 対応のドライバは Web サイトから入手出来るので手間はたいしたことはない。

しかしユーティリティとなると話は別である。それは一般に各社サイトからダウンロード出来ないことが多いからである。仮にバージョンアップ版は掲載されていても、元となる本体は購入時に付属していた CD からインストールしなければならない。

各社メーカーのプリンタもスキャナもおしなべて、ドライバ以外のユーティリティを満載していることが多く、購入時に付属している CD からドライバと一緒にこれらをインストールすることになる。

つまり、購入時の CD がないとユーティリティはインストール出来ないことになる。

これが味噌なのだ。流石にOSやアプリのCDあるいはDVDはきちんと管理していても、デバイスドライバはネットからダウンロード出来る事が分かっているので、プリンタやスキャナの CD はついなおざりになりがちだ。今回もそれらを探すのに苦労してしまった。3 年以上前に購入した製品の CD の在処が直ぐには思い出せなかったのだ。

雑誌付録の DVD を溜め込んできたため、これらと一緒にファイリングしていたプリンタやスキャナの CD が埋もれていて見つけられなかったのである。

教訓として、今後は付録と製品の DVD や CD は別々にファイルリングすることにした。

アプリインストールにおける注意点

Vista 上で使用してきたアプリの全てを 7 上でも使用しなければならない訳ではない。

また使用したい訳でもない。

しかし、自分のパソコンの使い方から必須のアプリは相当存在している。

既述のように Vista 上での「プログラムの追加と削除」(正式名称は忘れた。これは XP における呼称だが意味は分かるはず)にリストアップされたアプリが 219 もあったが、つまりその全てを 7 上でインストールしなければならない訳ではないが、相当数のインストールは不可欠となる。

定番の MS-Office、Acrobat 等の一般的なアプリは当然インストールしたし、相当数のフリーウェアも必要な物は順次インストールしている。

問題となったのは、仮想 DVD アプリ Daemon Tool 等の 7 非対応アプリと、管理者権限で実行する必要があるアプリの内、PC 起動時に走らせたいアプリだ。

以下に発生した問題を羅列して記録に留めておく。

  • Damon Tool をインストールしたところ 7 が立ち上がらなくなってしまった。結局 OS の再インストールに追い込まれてしまったのだから、致命的な事件であった。
  • Ultimate Defrag、Auslogics Registry Defrag、CLCL や whinshot 等の「管理者として実行する必要がある」アプリのスタートアップ登録が、これまでのスタートアップフォルダにショートカットを登録する方法では実現しなかった。
    これらについてはタスクスケジューラに登録することによってのみ、PC 起動時に走らせることが可能となった。

以上から以下の教訓が得られた。

  1. 7 対応が確認されていないアプリを無闇にインストールすべきではない。慎重にも慎重な対応が必要であり、可能な限り非対応アプリはインストールせず、必要な機能を有する 7 対応の代替アプリを探すべきだ。
  2. スタートアップアイテムの登録方法が変わったことについて、事前の調査が足りなかった。しかし、これは致し方ないことだ。そんなことは想定出来ないのが普通だと思われるからである。

▲ToTop

信じ難い IE の Javascript インタープリタの挙動

animatedPopup も makeTableContents も IE では動かない。

その他各種の jQuery plugin を作ってきたが、それらの多くが IE で動かない原因をずっと解明できないまま、時は空しく流れ去るばかりだった。IE 用にはお粗末なデバッガーしかないので、動かない原因がなかなか特定出来ないでいたのだ。

しかし、未だに相変わらずトップシェアを占めている IE で、目次作成プラグインなど全てのエントリイにおいて活用させたいものが動かないのは、ブログ製作のあり方として耐え難い。そこで、Firebug Lite や IE 8 の開発者ツール、あるいは DebugBar を駆使して、前から見当を付いていた " 怪しげな箇所 " を部分に細分化し、時には一行ずつ、場合によっては一文ずつ、一式ずつテストしてみた。

そしてやっとのことで、余りに<お粗末な> IE 固有のエラー発生原因の いくつかが究明できた。以下そのお粗末さを明らかにしておきたい。

なお、今回特定した問題はいちがいにバグとは言い切れないかもしれない。

余りにお粗末なインタープリタ

それは「 論理積演算子 」&& に関わる。この演算子のオペランドは左右とも「式」が許されているのに、IE では左側のオペランドが特定の或る式の場合には、「 式なのにエンドマークの;がないからエラー! 」 と判断するのである!

例えばこうだ。

 1: $("body").mousemove(function(e){
 2:   if (e.pageX-$(window).scrollLeft()<10 && $contents.is(":hidden")){
 3:     direction = false;
 4:     displayJumpList(e.pageY);
 5:   }
 6: });
 7: $(window).scroll(function(){
 8:   if (!$contents.is(":hidden") && Math.abs(initScrollTop-$(window).scrollTop())>20){
 9:     slideFuncOut.call($contents);
10:     initScrollTop = $(window).scrollTop();
11:   }
12: });

上のコードの 2 行目と 8 行目を比較すると、前者では&&演算子の左オペランドは比較式で、右オペランドは jQuery インスタンスメソッド、つまり関数呼び出し式である。他方、後者ではそれが逆となっており、左側に jQuery インスタンスメソッドがあり、右側には比較式がある。

さて、IE で、これらの 2 つの if 文のどちらが正常に働き、どちらがエラーとして認識されてしまうか、お分かりになるだろうか??

結論を言えば、Firefox、chrome、safari (いずれも windows 版)ではいずれの行も問題なく作動するし、IE に最も近い Opera でさえ問題はない。しかし、独り IE だけが 8 行目の && 演算子の左側オペランドにセミコロンがないからエラーとして評価してしまうのだ。

『Javascript 第 5 版』によれば「 関数呼び出しは厳密には式であるが、Web ブラウザを制御する副作用があるので文の仲間に入る 」。

つまり、IE のインタープリタは、「 関数呼び出しは厳密には式であるが、副作用を伴う文の仲間に入るからセミコロンが必要だ 」と判断するわけだ。

一方他のブラウザのインタープリタは、関数呼び出しは副作用を伴うが厳密には式なので、セミコロンは求めない、ということになる。

お粗末なインタープリタに対する 1 つのささやかな対策

2 行目は問題なく作動することが確認されている。しかし 8 行目はエラー。───ではオペランドの順番を変えてみたらどうか?───こう思い付くまでにさほどの時間は掛らなかった。

2 行目に準じて 8 行目の && 演算子のオペランドの左右を次のように入れ替えるのである。

8: if (Math.abs(initScrollTop-$(window).scrollTop())>20 && !$contents.is(":hidden")){

つまり、左オペランドには比較式を置き、jQuery インスタンスメソッド呼び出し式は右オペランドに移すのだ。このように入れ替えてから、開発者ツール等で試したところ、エラーはあっさり消え去り、問題は解決してしまったのだ。

構文ミスでも、記述ミスでもないこのような記述を、敢えて「 文だからエラー 」として認識してしまうとは、余りにお粗末ではないか。

因みに、次のように括弧で括って明確に式であることを明示してみたところ、これもエラーにはならなかった。しかしこの方法は可読性が低下するので決して好ましい方法ではないだろう。&& 演算子が登場する度に、関数呼び出しオペランド部分を一々括弧で括るなんて、余りに手間が掛りすぎる!

8: if ( (!$contents.is(":hidden")) && Math.abs(initScrollTop-$(window).scrollTop())>20 ){

2 つ目は mousemove メソッドの呼び出し元に関する問題である

最終的には 2 行目の mousemove メソッド呼び出し元は、body 要素としたが、コード作成時から最終改訂の直前までは、window としていた。そして $("window").mousemove(function(e){・・・}) で IE 以外のブラウザは意図を解釈してくれた。しかし IE だけはうんとも寸とも言わないのだ。

確かに、マウスは body 要素の上、あるいは中で動くのだから、mousemove イベントの呼び出し元は body であるべきだろう。それが論理的である。しかし、マウスは window の上あるいは中で動いていることもまた真なのだから、window が起動元であっても mousemove メソッドは作用すべきだと思われる。

独自仕様を乱発してきた IE はその裏で余りに厳格な解釈を行っている

上の 2 つの事例から言えることは、そういうことである。余りに厳格な解釈によりエラーを乱発するのだ。「 仕様だから仕方がない 」という立場もあるかもしれないが、インタープリタは運用上のスマートさも兼ね備えるべきだ。

次に想起されることはこうだ─── || 演算子は IE で正常に働くのだろうか?

こちらは<予想を裏切り>、他のブラウザと同様に正常に機能した。

8: if (!$contents.is(":hidden") || Math.abs(initScrollTop-$(window).scrollTop())>20){

上の 1 行では&&演算子の左側オペランドは関数呼び出し文であるが、実行してもエラーははき出されないのだ。このことから言えることは、「 IE のインタープリタには一貫性がない 」ということだ。

余りに厳格な解釈を行うと思えば、論理的一貫性を欠く。───それが IE の Javascript インタープリタなのだ!

【 結論 】&& 演算子における IE 対策

  1. && 演算子の左側オペランドに関数呼び出し文を置かないようにする。
  2. どうしても左側に関数呼び出しを置かざるを得ない場合には、&&演算子の左側オペランドを一括りの ( ) で括って、IE が文としての厳格な解釈を適用しないようにするのが得策だ。

目次の仕様を変更───必要に応じて簡単なマウス操作で見え隠しする

新しい目次作成+頁内ジャンプ プラグインの設計

結論を言えば、上の関連エントリイリストに記した 2 つのプラグインの統合を行いました。

No.782 の目次自動作成プラグインは、ページトップの近くに、常時固定的に表示する目次を自動的に作成するものであり、No.793 は頁内移動を容易に行うためのものです。

これらを暫く使ってみた結果、統合して 1 つのプラグインにまとめた方が使い勝手がよいことに気づきました。

目次として自動登録するのは h4 タグです。そして、頁内ジャンプは主に目次項目を使用するものでした。つまり共通の対象を操作するわけです。ならば統一できるし、その方が効果的に使えると考えたのです。

また、頁内ジャンププラグインは敢えて animatedPopup プラグインを利用していますが、ここで目的とする機能は重いプラグインを使わなくても、もっと軽快に達成できるのではないか、否、達成すべきだとも考えました。

こうして 2 つのプラグインを統合した軽快な目次作成+頁内ジャンププラグインを完成させました。

仕様

以下のように、必要に応じて目次を表示させ、また不必要になったら消えるようにしました。目次内の項目をクリックすると当該箇所にジャンプすることは言うまでもありません。

  1. 目次は固定的には表示させず、必要に応じて表示/隠蔽するようにしました。
  2. エントリイ頁が開かれた時には、画面上部の中央部分に目次が表示されます。その時目次を使いたくなければ、目次ボックスの文字以外の箇所をクリックするか、あるいは window をスクロールすれば目次を消すことが出来ます。
  3. 一旦消えた目次を見たくなった場合には、マウスカーソルをその時々の window 左辺付近に近づけると、その時のマウスカーソルの位置に応じて、目次が右にスライドしながら表示されます。つまり、スクロールの有無や多寡に関わらず、時々の window 左辺にマウスカーソルを近づけると、window 左辺に接して目次を表示するようにしました。この「 浮動的に 」表示/隠蔽する目次がこのプラグインの最大の特徴です。
    なお、ジャンプしたくない場合には、既に触れたように一寸頁をスクロールさせれば目次を隠蔽出来ます。
  4. 目次内の任意の文字列をクリックすると、当該箇所にジャンプします(スクロールします)。その際には、既述のように、LI タグに登録したイベントハンドラーによって目次は隠蔽されます。
  5. このプラグインは起動元を特定する必要がありません。$() を起動元にしても起動できますし、起動元は何であっても構いません。なお、背景色を変えて起動したい場合には、$().makeTableContents("specified color") と指定すれば良いだけです。

▲ToTop

コード

■ slideSide

上下方向の slideToggle , slideUp , slideDown インスタンスメソッドに準じて、横方向のスライドメソッド slideSideToggle , slideSideOut , slideSideIn を以下のように作りました。duration、easing、complete callback 関数 の初期値も指定していますので、引数を指定せずに起動すれば、継続時間は slow を、easing 関数は swing を、アニメーション終了後に起動する関数は無指定を、それぞれ指定することになります。

この横方向スライドメソッドは、縦方向の Up/Down メソッドと共に、かなり使い回すことの出来る汎用的なものとなるでしょう。

$.fn.slideSideToggle = function(duration,easing,callback){
  this.animate({width:"toggle", marginLeft:"toggle", marginRight:"toggle",
    paddingLeft:"toggle", paddingRight:"toggle"},
    duration || "slow", easing || "swing", callback || function(){});
}
$.fn.slideSideOut = function(duration,easing,callback){
  this.animate({width:"hide", marginLeft:"hide", marginRight:"hide",
    paddingLeft:"hide", paddingRight:"hide"},
    duration || "slow",easing || "swing", callback || function(){});
};
$.fn.slideSideIn = function(duration,easing,callback){
  this.animate({width:"show", marginLeft:"show", marginRight:"show",
    paddingLeft:"show", paddingRight:"show"},
    duration || "slow",easing || "swing", callback || function(){});
};
■ makeTableContents
 1:$.fn.makeTableContents = function(color){
 2:/* $.fn.makeTableContents(color)メソッド
 3: * color:目次の背景色を指定すれば、default:"navy"を変更可能
 4: * 起動方法:$().makeTableContents("specified color") or $().makeTableContents()
 5: * release:2010/12/4
 6: */
     // エントリイモードではない時には何もしない。
 7:  if (!/.+blog-entry.+html/.test(location.href)){
 8:    (function(){return false;})();
 9:  } else {
10:    $(function(){
         // entry_body に h4 タグがなければ何もしない。
11:      if (!$("h4","div.entry_body").length) {return (function(){return false;})();}
         // もし既に目次がある場合にはこれを削除する。
12:      if ($("#tablecontents").size()) {$("#tablecontents").remove()};
         // ローカル変数定義
13:      var $contents, bgColor = color && typeof color==="string" && color|| "navy",
14:          initScrollTop = $(window).scrollTop();
         // 目次タグ要素の作成
15:      $contents = $("<ol id='tablecontents' title='目次が消えた後でも、
           マウスカーソルを window 左辺に近づけると再度表示させることが出来ます。
           <br />また、window をスクロールすると目次を隠蔽することが出来ます。' />")
16:        .css($.extend({}, // 初期値(opts) と引数を統合
17:          $.fn.makeTableContents.opts, bgColor!==null ? {background:bgColor}:{})
18:        .prependTo($("body"));
         // entry_body 内の h4 毎に目次項目を作るイテレート処理を行う。
19:      $("h4","div.entry_body").each(function(i){
20:        $(this).wrapInner("<a id='tablecontents"+i +"'></a>");
21:        $contents.append("<li><a href='#tablecontents"+i+"'>"+$(this).text() +"</a></li>");
22:      });
23:      // 目次の幅は 400 px またはそれ以下とする。
24:      var cW = Math.min($contents.width(),400),
25:          cH = $contents.css({width:cW}).height(), // 目次の高さ
26:          oW = $contents.css({width:cW}).outerWidth(), // 目次の幅外寸
27:          direction = true; // direction : true -> up down, false -> side
         // 上下方向/横方向の方向別の 3 つの slide メソッドの選択指定
28:      var slideFuncToggle = function(){
29:        return direction ? this.slideToggle("slow") : this.slideSideToggle();
30:      };
31:      var slideFuncOut = function(){
32:       return direction ? this.slideUp("slow") : this.slideSideOut();
33:      };
         // このプラグインでは使用しないが、一応定義しておく
34:      var slideFuncIn = function(){
35:        return direction ? this.slideDown("slow") : this.slideSideIn();
36:      };
37:      // 目次(=ジャンプリスト)表示関数
38:      var displayJumpList = function(top){
39:        cPopCSS = !top ? { // top 値がゼロの時
40:          top : $(window).scrollTop()+160,
41:          left : (($(window).width()-oW)/2),
42:          height : cH,
43:          overflow:"auto"
44:        } : { // top 値がゼロではない時
45:          top : top,
46:          left :$(window).scrollLeft(), // 画面左端に配置
47:          height : cH, // 高さを変化させないために
48:          overflow:"auto"
49:        };
           // css 値を設定してから slide メソッドを呼び出す。
           // 高さを指定して横方向アニメが起きた時に高さを変化させないようにする。
           
50:        slideFuncToggle.call($contents.css(cPopCSS));
51:      };
         // 目次各項目への click イベントハンドラーの登録
52:      $("li",$contents).each(function(){
53:        $(this).click(function(){
54:          slideFuncToggle.call($contents); // 目次を隠蔽する
55:        })
56:      });
57:      displayJumpList(); // 頁オープン時に目次を表示する
58:      $("body").mousemove(function(e){ // mouseが動いた時
           // マウスカーソル X 位置が window 左辺から 10px 以内にあって、
           // かつ 目次が表示されていなければ
59:        if (e.pageX-$(window).scrollLeft()<10 && $contents.is(":hidden"){
60:          direction = false; // 横方向を指定し
61:          displayJumpList(e.pageY); // 目次を top:マウスカーソル Y 座標に表示する
62:        }
         // window scroll イベントハンドラーの登録(目次の隠蔽)
63:      })
64:      $(window).scroll(function(){
           // 目次が表示されていて初期スクロール Top 値と
           // 今行ったスクロール後の Top 値が 20 px 以上差がある場合には
65:        if (Math.abs(initScrollTop-$(this).scrollTop())>20 && !$contents.is(":hidden")){
66:          slideFuncOut.call($contents); //目次を隠蔽する
67:          initScrollTop = $(this).scrollTop()// 現在値を初期値とする。
68:        }
69:      });
37     });
70:  return this;
71:  }
72:};
73:// 目次の CSS 初期値設定
74:$.fn.makeTableContents.opts = {
75:  position:"absolute",
76:  zIndex:"1010",margin:0,padding:"0.5em 0.5em 0.5em 2em",
77:  border:"2px ridge white",textAlign:"left",lineHeight:"1.1em",
78:  background:"navy",display:"none"
79:}

jQuery.width()/height() メソッドの挙動を改めて解読する

問題の単純化のために、まず jQuery(・・・).width() メソッドに着目して分析を進め、一通りの作業を終えた後に、jQuery(・・・).height() メソッドにも言及することにします。width メソッドに付いて言えることは、本質的にそのまま height メソッドにも妥当するからです。

位置指定要素と通常配置要素の表示描画状態における幅

下の例でブロックボックス要素の描画幅について比較してみました。

このボックスは、まず position 属性を順に、無指定、relative、absolute、absolute と指定した 4 つの div 要素( 全て横幅は無指定で、class 名を target786 としました)を作り、それらの中にそれぞれ文字列を配した上で、それを包含する div 要素を offsetParent 要素として作成し配置したものです。最も外側の offsetParent たることを期待されている div 要素には、そのために position : relative が指定されています。ここに position:relative 指定した要素の top 値と left 値は共にゼロとしています。

なお、.target786 DIV 要素の offsetParent のコンテンツ領域を明示するために、このコンテンツ領域を padding、border 及び margin 値を全てゼロとした div 要素で囲み、pink 背景色を指定しました。

更になお、.target786 DIV 要素の margin 域を明示するために、.target786 DIV 要素を包含する padding、border 及び margin 値を全てゼロとした div 要素を配置し、その背景色を茶色としました。

この pink の背景領域は以下の要素を包含する要素のコンテンツ領域である。
これは通常配置されたdiv要素内に配置された文字列である。
これは相対配置されたdiv要素内に配置された文字列。
これは絶対配置されたdiv要素内に配置された文字列である。
これも絶対配置div要素内に配置された文字列

上の例で直ぐ分かるように、静的配置及び相対配置要素の横幅に注目すると、中のコンテンツサイズ(この場合文字列)に影響されず、margin、border、padding 及び内容が offsetParent 要素のコンテンツ領域横幅一杯に展開されています。(※ target786 DIV の上下の margin は相殺されている。)

一方、絶対配置要素の場合の横幅はそのコンテンツ幅に左右され、かつ margin 値を含まない固有の値となっています。(固定配置の場合にも同様に当該要素のコンテンツ幅によって決まる固有の値となりますが、固定配置の例はここでの例示には馴染まないので省略しました。なお、固定配置の場合にはその包含関係に関わらず offsetParent は body 要素となります。)

以上の position 指定による表示幅の違いから、或る要素のコンテンツの横幅を知ろうとすれば、そのコンテンツを絶対配置すれば計測できることが分かります。

そして、一般に要素は margin、border 及び padding の各値を有していますので、要素の幅にはコンテンツ幅、padding 辺幅、border 辺幅及び margin 辺幅があり、これらの計測のために次の 4つの jQuery インスタンスメソッドが定義されています。それは jQuery(・・・).width()、jQuery(・・・).innerWidth()、jQuery(・・・).outerWidth()、jQuery(・・・).outerWidth(true) です。

さて、絶対配置要素の幅がそれを包含する offsetParent サイズに依存せず、当該要素固有の値になることを利用して、当該要素の算出スタイル値を算出することが出来ます。jquery.js では swap メソッドがそれです。次に、swap メソッドを使う jQuery(・・・).width() メソッドの実行過程を具に追いかけ、コンテンツ幅を取得する方法を跡付けてみます。

▲ToTop

jQuery(・・・).width() メソッドはどのようにして対象要素のコンテンツ幅を測るのか?

以下のような複雑な過程を経て、対象要素 elem の算出スタイル width 値が算出されます。

  1. width インスタンスメソッドの定義
    width インスタンスメソッドは jquery.js ver1.42 の 6019~6074 行で定義されていますが、window や body を除く一般の要素の横幅計測は 6067 行の jQuery.css(elem,type) メソッド呼び出しを通して行われます。( jQuery().width() メソッドの場合には type 値は "width" となります。)
  2. display 属性値が none でない時
    1. 呼び出された jQuery,css クラスメソッドでは、elem.offsetWidth がゼロでなければ、つまり display 属性値が none でなければ getWH() 関数を実行し、この関数の中から、jQuery.curCSS クラスメソッドを呼び出します。
    2. この jQuery.curCSS クラスメソッドを呼び出し時には、第 3 引数が true に指定されるので(#4475~4481)、style 属性の有無に拘わらず、強制的に elem 要素の算出スタイル width 値が計測されます。なお、上で見たことから容易に分かるようにこの算出スタイル width 値は、当該要素が静的又は相対配置されている場合には offsetParent のコンテンツ幅となり、絶対又は固定配置されていれば、当該要素のコンテンツ幅となります。
  3. display 属性値が none の時
    1. 他方、elem.offsetWidth がゼロの場合(つまり、display 属性が none の時)には、jQuery,css クラスメソッドは jQuery.swap クラスメソッドを呼び出します。
    2. swap メソッドは style 属性の一部を一時的・強制的に入れ替えて算出スタイルを算出する関数で、position 値を absolute に、visibility 値を hidden に、display 値を block にそれぞれ入れ替えてから、getWH() 関数を呼び出して算出スタイル width 値を算出し、その直後に一時的に入れ替えた style 属性値を元に戻します。
      ここで注目すべきことは、絶対配置指定を行い、display を block に指定してブラウザに当該要素を描画させつつ、可視属性を hidden としていることです。これによりブラウザ上の当該要素の表示状態を全く変化させることなく、つまり表示させていない状態(display:none)を実質的に変化させることなく、算出スタイル値を測定しています。
      こうして swap メソッドと getWH 関数の巧みな組み合わせによって、要素のコンテンツ幅計測が行われていることが分かります。
【結論】
  1. 測定対象要素の position 指定値とその表示有無( display属性値 )によって、jQuery(・・・).width メソッドで測られる幅の値は異なります。
  2. 対象要素を表示状態( display:none 以外 )にして width インスタンスメソッドを適用すると、対象要素を包含するブロック要素のコンテンツ横幅から、当該要素の左右の padding 幅、当該要素の左右のボーダー幅及び左右のマージン値の 3 つの合算値を差し引いた値が計測されます。この値は必ずしも当該要素のコンテンツそのものの幅と同一ではありません。算出される値は当該要素がボックスとして取り得る最大のコンテンツ幅となります。
  3. 対象要素を非表示(display:none)にして width インスタンスメソッドを適用すると、当該要素の左右のパディング幅や左右のボーダー幅及び左右のマージン幅は無視され、対象要素のコンテンツ横幅が計測されます。

画像のようなインラインブロック要素を包含するブロック要素に jQuery(・・・).width() メソッドを適用して得られる値は何を指すのか?

これまで、要素を非表示状態にして width インスタンスメソッドを適用すれば、当該要素のコンテンツ幅が測られることを見てきました。

では、コンテンツがインラインブロック要素の場合で、その包含ブロック要素を非表示状態にして width メソッドを適用した場合、計測される値は何を指すのでしょうか?

img HTML タグには width や height だけではなく、W3C 非推奨ですが border、vspace、hspace 属性が設定出来ます。また span 要素でインラインブロック要素を包含して margin を設定することさえ可能です。そして実際多くの Web サイトでこれらの非推奨属性が未だに多用されています。このようなインラインブロックを包含するブロック要素に width メソッドを適用した場合の値について調べます。

(このように恰もブロック要素のように余白などが設定出来ることが、まさにインラインブロックと呼ばれる所以です。)

結論は自明です。インラインブロック要素の場合、余白やボーダー迄を含めてコンテンツなのですから、それは画像の幅+画像の左右の padding 幅+画像の左右のボーダー幅+画像の左右の margin 幅の合計値となります。なお、注意しなければならないことは、ここで言う padding、border、margin はインラインコンテンツを包含するブロック要素のそれらではありません。画像に固有に設定されている padding 等を指します。

以上のことを以下の例示で検証します。

この下の画像は id 名 img1-786 の div 要素の中に配置しましたが、インライン要素である画像タグには width="450px" 指定の他に、vspace="5px"、hspace="10px"、border="4px"等を指定してあります。

この div 要素に width() jQueryインスタンスメソッドを適用して「コンテンツ幅」計測を行ってみます。ここでは対象とする div 要素が表示されているため一寸工夫が必要です。具体的には div 要素の clone ノード( CNと呼ぶ )を作り、その display 値を none とした上で jQuery(CN).width メソッドを適用するのです。

その結果は、画像の直下にリアルタイムで表示するように script を組み込みました。

さて、div 要素に width メソッドを適用して得られた値 478px は、画像の幅を超えています。これは容易に検証できますが、width:450 + hspace:10*2 + border:4*2 に他なりません。つまり、インラインブロック要素自身の幅とボーダー幅とパディング幅の合計値となっています。

なお、ここでも IE だけは正しく作動しませんでした。Firefox、Chrome、Opera、Safari (全て Windows 版)では全て 478px となりましたが、IE8 の場合 478px ではなく 458px となってしまいます。余白幅が加算されないのです。その理由と IE7 や IE6 の場合どうなるかは検証に値する問題でもないでしょう。無視します。

こうして、インラインブロック要素を包含するブロック要素に jQuery(・・・).width メソッドを適用すると、インラインブロック要素のコンテンツ幅+余白+ボーダー幅の合算値が取得できること、並びに IE の場合には hspace を無視するバグがあることが検証できました。

jQuery(・・・).height() メソッドについて

これまで width メソッドについて述べてきたことはそのまま、height メソッドにも妥当するはずです。何故ならばこれら二つのメソッドは全く同一の jquery.js コードを利用するからです。

そのことを明らかにするために上の写真の、今度は高さを測って実証してみます。

既にコンテンツサイズ計測用の clone ノードは display:"none" 状態で作成済みなのでこれを再利用します。

リアルタイムに script で計測し、計測結果がこの下に表示されますが、画像そのものの高さが 301px であるのに対して display:"none" 状態の clone ノードに対して height メソッドを適用した結果は、予想通り 319px(301+vspace 5*2 + border 4*2。但し IE では vspace 値を拾わないので結果は 309 pxとなる。)となっています。

また、width メソッドで言及した結論は、 height メソッドについてもほぼ同様に以下のように主張出来ます。

【結論】
  1. 測定対象要素の position 指定値とその表示有無によって、jQuery(・・・).height メソッドで測られる高さの値は異なります。
  2. 対象要素を表示状態にして height インスタンスメソッドを適用すると、対象要素の offsetParent のコンテンツ高さから、当該要素の上下のパディング幅と上下のボーダー幅を差し引いた値を計測します。この値は基本的に当該要素のコンテンツ高さに等しくなります。
  3. 対象要素を非表示(display:none)にして height インスタンスメソッドを適用すると、対象要素のコンテンツ高さを計測します。
  4. width メソッドにおいては、display 値が block と none の場合とでは結果が異なることがあるのに対して、height メソッドでは、display 値に左右されずに同一値となります。

Windows XP PCのパーティション変更を無料ソフトで実行した

それはある人のパソコンのメンテナンスから始まった

3年半前に購入された DEEL Inspiron 1150 ( OS は Windows XP )が A さんから B さんへと譲渡され、B さんが使うための環境を構築し直した。ここではその際に行った、無料ソフトを使ったパーティションサイズ変更について、感謝と驚愕を込めて記しておく。

3.5 年は PC にとっては一昔も二昔も前であり、1150 NotePC ののハードディスク容量は、今から見れば余りに小さすぎるが、当時では決して過小ではなかった 60 GB 。このことは、僅か 3.5 年の間に、いかに PC の物理的環境条件が激変したかを示す、端的な材料と言えるだろう。

さて、当時の 60GB HD は 2 つのパーティションに区切られていて、C:20GB、D:残りとなっていた。

しかし、Cドライブが 20 GBというのは、現在から見れば余りに過小すぎる。

XP のサポート打ち切り期限迄まだ4年強が残されている現時点において、例え Vista や 7 に乗り換えないとしても、20GB の C ドライブでは、ここににアプリをインストールする限り、今後のアプリケーション追加は絶望的である。

アプリを D ドライブにもインストールしてしまう方法もあるが、万が一の故障時を考慮すると、C ドライブには OS とアプリだけを、ユーザーデータは基本的に D ドライブに、と使い分けたい。そうすれば、C ドライブのイメージバックアップを取る習慣をつけさえすれば、いざ起動しなくなった場合には、イメージファイルをリストアすることによって、リカバリーに比べれば、遙かに容易で、時間も掛らない方法で復活することも出来る。

かくして、C ドライブの拡張(= D ドライブの縮小)を行うことにした。

Easeus Partition Master でパーティションサイズを変更

Easeus Partition Master は、無料ソフトでありながら、OS では決して出来ない高度なディスクメンテナンスを可能とする極めて優れたアプリケーションである。これを使えば、現在あるデータを一切消去することなく(注)、C 及び D ドライブのサイズを変更することが出来るのである。

注 正確に言えば「パーティションサイズを縮小する場合、当該パーティションに、縮小する容量を上回る空き容量が存在していれば、当該パーティション内のデータは一切消去されない」。

今回行ったサイズ変更は、C:20GB、D:40GB弱 → C:30GB、D:30GB弱 への 、D ドライブから C ドライブへの 10GB の移行である。

勿論、パーディションサイズを変更する前に、念のために、C ドライブのイメージバックアップを取っておき、万が一パーティションサイズ変更途中でおかしくなってしまって、Windows が起動しなくなったとしても、Cドライブが復活できるよう保険を掛けた。

また、D ドライブについては、A さんのデータが 10 GB 程あったが、これは 外付け HD に待避させた上で、A さんのユーザープロファイルを削除した。これにより D ドライブのデータは、パーティションサイズ変更途中で、仮に消えてしまっても支障がないようにしたのだ。

以上の準備の後に、初めて Easeus Partition Master を使ったパーティションサイズ変更を決行した。

そして極めて驚異的であったのだが、何と10分足らずで、一切のデータ消失もなく、パーティションサイズ変更が完了したのである!!!

ハードディスクの根源的なメンテナンスが、これほど容易に、これほど短時間に、そしてこれほど完璧に、無料ソフトで出来てしまう───最近、自然災害も含めて驚くべきことは多々あったが、個人的には「これほど驚愕したことはない」と言って良いだろう。

EASEUS Partition Master のパーティションサイズ変更過程画像

Easeus Partition Master が紹介されているサイト

まだまだ健在の Windows XP のログインユーザー名の変更について

以下の記述は XP 用であるが Vista でもおそらく 7 でもそのまま当てはまるだろう、と推測される。

或る事情から職場の Windows XP-PC のログインユーザー名を変更する必要に迫られた

ログインユーザー名として name1st を設定していて、何らかの事情によってその名称を変更せざるを得なくなったとする。

この場合、単に見かけ上の名称を変更することは容易い。コントロールパネル → ユーザーアカウント から「アカウント名の変更」を行うだけである。

しかし、この行為は表面上のことであって、レジストリ情報や Windows に登録済みのアカウント名そのものを変更するものではない。コントロールパネル → ユーザーアカウント から「アカウント名の変更」を行って、name1st を name2nd に変えたとしても、それはいわばあだ名を付ける行為に過ぎず、本名は依然と変わらないのだ。 name2nd でログインしたとしても、Windows は あくまでも本名の name1st がログインしたと認識する。

「あだ名を付けても、本名が変わらない」と言う意味は次の通りだ。

Windows のユーザーアカウントを作成し、一度ログインすると、Documents & Setting 内にユーザーアカウント名のフォルダが作成され、その中に各種の所定のフォルダが作成される。

これが本名であって、「コントロールパネル → ユーザーアカウント → アカウント名の変更」によって見かけ上のアカウント名を変更しても、 Documents & Setting 内の本名が変更される訳ではない。この変更はあくまでも見かけ上に過ぎないのだ。

ログインユーザー名を変更し、かつ以前の設定を全て引き継がねばならない

さて、今回偶々あだ名ではなく本名を変更する必要に迫られた。同じ Lan 内にある異なるパソコンで同一のログインアカウント名が使用されていることが、或るシステムのユーザー認証において支障を生じたのである。同一 Lan 内で同一ユーザー名で、同時に複数のパソコンにログインしている状態が、ユーザー認証上妨げとなったのである。

そこで複数のパソコンに登録されている同一名のログインユーザー名を、全く重複がないように変更しなければならなくなったのである。

しかし、重複を避けるためとはいえ、これまで営々と設定し続けてきた環境を変えることは忍びない。当然、これまでと全く同様に使うことが出来、かつログインユーザー名が Lan 内で重複しないようにしなければならない。

▲ToTop

問題はかなり根深い

環境を全く変えずにログイン名を変えることは、相当大変な作業を強いる。

本名を変えることは、事実上異なるユーザー名を作ることに等しく、新しいログインユーザー名を作ってログインすれば、当然これまで築き上げてきた環境とは無関係に、新しいユーザーアカウントの元での新規のまっさらな環境が構築されてしまう。

そこでグーグったところ、当然のことであるが、このようなケースへの対応策が、Microsoft 社のサイトに掲載されていた。( Windows XP でユーザー プロファイル名を変更する方法

その作業は大変手間が掛るものであり、内容は以下のようであった。

  1. name1st でログインした状態で、新規の name2nd アカウントを作る。
  2. 一度ログオフした後に、今作ったアカウント名 name2nd でログインする。いわば name2nd アカウントによる初期状態の Windows 環境を作る。
  3. 再度ログオフしてから、name1st でもなく name2nd でもない、第三の管理者権限のあるユーザーアカウントでログインする。Administrator または name3rd によってログインするのだ。
  4. そのユーザー名によって Windows が立ち上がったら、name1st のユーザープロファイルを name2nd プロファイルに複写する。
  5. name1st の元でインストールしたアプリケーションの設定情報や、作成したデータが収められている各種フォルダは、このプロファイル複写によって複写されるわけではなく、別途これらの複写が必要となる。
  6. それでもなお、完全に以前の環境は復元されない。各アプリケーション毎のオプションで設定してある各アプリの設定情報は、個別に複写、呼び出し、あるいは新規に設定し直す等の作業を行わねばならない。

つ づ く

▲ToTop




・・・・・

jquery.js による要素位置の測定と適正な配置 (1) はじめに

jQuery インスタンスメソッドである jQuery().offset や jQuery().position の解読を行おうと思い立って、jquery.js コードを睨み続けた結果、改めて offsetTop、offsetLeft について検討を加える必要があると思われました。

偶々、W3C による CSSOM View Module Working Draft が 2009年8月4日に公表されていたこともそうする必要性を高めました。 ( CSSOM View Module 作業草案 )、

たとえ「作業草案」とはいえ、拠って立つことのできる offsetTop/Left プロパティの定義として受け止めることの出来る内容となっています。こうして、この定義によって各ブラウザの差異を検証出来ることも、offsetTop/Left について再考するきっかけとなりました。

CSSOM View Module 作業草案 2009/8/4(以下「CSSOM VM草案」) における offsetParent、offsetTop/Left の定義

※ 以下は意訳であり、レイアウトボックスに関する名称は下図に拠り一部日本語化しました。

A.offsetParent の返値
1. 次の場合には null を返す。
  • A の中に CSS layout box が全くない場合
  • A がルート要素(HTMLタグ)の場合
  • A が body 要素の場合
  • A の position 算出CSSスタイル値が fixed の場合
2. A が map 要素内の area 要素の場合には、直近の祖先 map 要素を返す。
3. 次の場合には A の直近祖先要素を返す。
  • 直近祖先要素の position 属性が static ではない時
  • 直近祖先要素が body 要素の時
  • A の position 算出CSSスタイル値が static で、かつ祖先要素が td, th または table の時
A.offsetTop の返値
  1. A が body 要素の場合か、A に CSS layout box がない場合には、ゼロ
  2. A の offsetParent が null か body の場合には A の top border 辺の y 座標値
  3. 初期包含ブロックの原点を基準(つまり document 座標)として、A の border 辺の y 座標値から、offsetParent の padding 辺の y 座標値を減じた値
A.offsetLeft の返値
  1. A が body 要素の場合か CSS layout box がない場合には、ゼロ
  2. A の offsetParent が null か body の場合には A の left border 辺の x 座標値
  3. 初期包含ブロックの原点を基準(つまり document 座標)として、A の border 辺の x 座標値から、offsetParent の padding 辺の x 座標値を減じた値

CSSOM VM草案 における offsetTop/Left 定義の要点

上の CSSOM VM 草案の定義で押さえておかねばならないことは、第一に document.body.offsetTop/Left の返値を常にゼロと定義したことです。つまり、body 要素に margin、padding あるいは border があろうがなかろうが、それらとは無関係にゼロとしたことが重要な点です。

別のエントリイ(offsetLeft,offsetTop,offsetWidth そして offsetHeight──静的配置要素の絶対位置を確実に取得する方法について)で詳細に述べたように、FireFoxは、その最新版(Ver 3.5.7)においても body 要素に border が存在する場合には、document.body.offsetTop/Left は何とボーダー幅のマイナス値を返してしまいます。これは CSSOM VM 草案を待たずとも、奇妙な仕様と言わざるを得ません。

因みに、Windows 系の他のブラウザ(IE8、Opera10.10、Chrome 3.0.195.38、safari4.0.4)の標準モード及び後方互換モードでは、Firefox のような奇妙な演算は起こらず、たとえ body 部に border が設定されていたとしても、document.body.offsetTop/Left は全てゼロを返します。Firefox だけが「マイナス border-width」 という奇妙な値を返します。

第二に、確認を含めて押さえておくべきことは、分かりやすく記述すれば A.offsetTop/Left の値は、A.offsetParent 要素のパディング辺と A.offsetTop/Left が起動された A 要素の border 辺との間のピクセル数になる、と定義されていることです。

この点では msdn の エレメントの大きさと位置を測定する に掲載されている図は、明らかに間違っています。(その図では、A.offsetParent のパディング辺から A のパディング辺までの距離を A.offsetTop/Left としています。これは 10 年以上前から掲載されている図ですが、当時の IE 5 あたりの、今日呼ぶところの互換モード仕様に基づくものと解釈することも出来ない、誤った図になっています。)

以上の 2 点は、offsetTop/Left を理解し、使いこなす上で極めて重要な基礎的なことであり、コード作成上 offsetTop/Left を使用して要素位置を知り、その結果を踏まえて何らかの要素を配置する場合には、ブラウザ固有の「偏差」(バイオス)によってずれが生じないように留意する必要があります。(ここでは敢えて「バグ」と言う表現は使わないことにします。何故ならば、CSSOM View Module はまだ作業草案段階であって、勧告に至っていないからです。)

HTML文書内の要素位置取得方法の要点

はじめに

要素の正確な位置を知りたい場合( 絶対配置、相対配置又は静的配置のいずれの場合においても )、あるいはそれを踏まえて適正な位置に任意の要素を配置しようとする場合、ブラウザ毎に個別に対応するのは大変な手間となります。そこで様々な W3C 勧告が作られ、それを基準としてブラウザが作られてきました。しかし、未だに各ブラウザごとに固有のバグがあるため(特に IE では多数のバグがある)、バグ対策が不可欠となります。

また、IE で初めて採用され、その後各ブラウザが採用した、offsetParent や offsetTop/Left プロパティは、要素の位置を知るために非常に有効な読み取り専用プロパティですが、現時点では標準的仕様さえ存在しないため、利用に当たっては適正な個別対策が必要となります。

jquery.js における要素位置の把握方法の概要

jquery.js では、要素のドキュメント上の絶対座標を取得するメソッドとして jQuery().offset() を、また基準要素( つまり offsetParent 要素 )からの相対座標を取得するメソッドとして jQuery().position() を、それぞれ用意しています。また、これらのメソッド内で jQuery.offset オブジェクトの各プロパティが利用されます。(jquery.js ver 1.3.2 #4172~4197)

以下にこれらのコード解読を行いますが、その前に、jquery.js の位置算出方法の特徴に触れておきたいと思います。注目すべきことは 2 つあります。

第一に、getBoundingClientRect() メソッドという、余り見かけないメソッドを使うことによって、位置取得コードを非常に簡単にしていることです。このメソッドは(おそらく)全てのブラウザで同一の値が得られるので、クロスブラウザ対策が不要なのだと思います。

第二に、getBoundingClientRect() メソッドに対応していないブラウザへの対策として、良く行われているようなブラウザ判別法を採用していないことです。

よく見かけるコードでは、ブラウザ毎や描画モード毎に条件分岐させて、それ毎のプロパティ値を取得します。しかし、jquery.js はそのような伝統的手法を採用しません。

まず、位置算出対象とする HTML 文内に、Javascript コードによって visibility:hidden; position:absolute 状態の複数の要素( 要素 A 及びその offsetParent となる B 要素など )を挿入します。これによって、ブラウザ毎に位置算出値が異なる可能性を持った要素を作ります。

次に、A や B の offsetTop や offsetLeft 値を取得し、それが正しい値とならない場合にのみ、ブラウザによって描画され適用されたスタイル値( 算出スタイル値 )を取得して、正しい値を求めるのです。

このように CSS 算出スタイル値、つまり実際に描画された状態における CSS 値を利用することで、ブラウザのバグや固有のプロパティ仕様を「あるがままに受け入れ」、結果としての要素位置を算出している訳です。

なお、Windows 系の主要ブラウザ( IE、Firefox、Opera、safari、Chrome )では、標準モードでも互換モードでも、全て getBoundingClientRect() メソッドをサポートしているので、offsetParent/Top/Left プロパティを利用する位置算出コードは利用されないことになります。

もう一つ、コード解読を行う前に、 IE の名誉のために是非とも触れておかねばならないことがあります。

上に述べた jquery.js で定義された メソッドやオブジェクトにおいて、要素位置取得用に利用されるメソッドとプロパティ ── getBoundingClientRect()、offsetParent、offsetTop、offsetLeft ── は、全て IE が最初に実装し、他のブラウザも追随して採用した、という事実です。

Netscape Navigater が初めて採用し、しかし他のどのブラウザも採用しなかった layer オブジェクトとは対照的に、当時の IE4 や IE5 が意欲的に定義し、採用した所謂 DHTML モデルが、今日主流となっている W3C 勧告の DOM や CSS に至る起爆剤となったことは、過去において、IE が勝手な仕様を作り続けてきたことが混乱を招来してきたとしても、記憶に留めておくべき重要な事実でしょう。

Windows 7 / Vista に GodMode なる特殊フォルダ機能が!

なるほど、あらゆる管理機能にアクセスすることの出来るフォルダが作成できる!

新規フォルダを作りその名前を GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} とするだけの簡単な操作で、コントロールパネルに似た特殊フォルダが作成され、その中には膨大な数の Windows 管理機能のショートカットリストが格納されるのだ。

名称がいかにも誇大妄想的とはいえ、これはなかなか使えるかもしれない。

詳細はこちらの記事 「Windows 7」の管理機能を集約--「GodMode」の存在が明らかに - OS/プラットフォーム - ZDNet Japan に掲載されている。

今年のIT技術で注目すべきことは?

PC Online 記事に見る今年の動向予測から抜粋すると・・・

Microsoft と Google の2強と iPhone 一人勝ちの2009年で更に勢いを得た Apple。これらの3社がそれぞれに OS、クラウド、スマートホンにおいて仕掛ける様々な展開がまず注目される。

Windows 7 は一気に普及し、定着していくだろうし、Chrome OS が無料で登場すれば確実に台風の目になるだろう。iPhone は強固な牙城を築いた日本の「ケータイ」の有り様を変えつつあるが、Apple 社は次の一手(ディスプレイの更なる大型化やiPhone 技術を活かしたタブレットPCの投入など)を打ってくるかもしれない。

クラウドコンピューティングもますます進行し、もはやクラウドを使っていることさえ意識しないようになるかもしれない。

ハードにおいては、何と言っても USB 3.0 の普及が注目される。今年の年末商戦段階では、パソコンの標準インターフェースとなっているだろうし、ハードディスクや DVD プレーヤ、そしてその頃には標準装備となっているであろう Bluray ディスクドライブも USB 3.0 接続が当たり前になるだろう。

SSD (フラッシュメモリドライブ) の低廉化も注目に値する。裏返せば価格低下が進まなければ、ブレイクスルーしないだろう。

そんなこんなの 2010 年に期待するものは?

クラウドコンピューティングに関する危惧

クラウドコンピューティングは、安心して使えるとはどうしても思えない。民間企業に全てを委ねてしまうクラウドには、どうしても合点がいかないのだ。

「データをクラウドに蓄積することは銀行にお金を預けることと同様に安心して良いのだ」との意見もある。確かに「信用」の問題なのだが、一企業の都合でどうにでもなってしまうかもしれないクラウドには、どうしても不安を拭いきれない。

そんなことを言っても、そもそも 1 つのクラウドサービスである無料 Fc2 ブログを 5 年以上使い続けて、その恩恵にどっぷりと浴しているのに「自己矛盾も甚だしい」と切り替えされるとにべもないのだが・・・

個人ユースで代表的はクラウドサービスは、Web メール・ブログ・掲示版・SNS などだろう。

特に Gmail サービスは無料で 7 GB ものにディスクスペースが使えることから、全てのメールを Gmailに統合して一元管理する方法があちこちで紹介されている。しかし私はその方法を選択することには二の足を踏み続けている。

例えば、5年以上使い続けてきたある掲示版が昨年末に閉鎖された( kidd.jp )。そしてその閉鎖を知ったのは、迷惑記事投稿が度重なるので、記事削除を行うために偶々 kidd.jp/bbs にアクセスした際であった。管理のためにアクセスして初めて 2009 年で閉鎖されることを「知った」のだ。

閉鎖に際してメールによる閉鎖通知が来るでもなく、掲示版データのバックアップなどに関する案内がユーザーに送られるでもなく、「会社の都合」により一方的に閉鎖されたのである。

こうした事例1つをとっても、クラウドは根本的に信頼できないと思うのだ。

つづく

jQuery プラグイン としてアニメーションポップアップ : animatedPopup を自作した。

このエントリイの改訂履歴など
  • 初稿:2009/04/19
  • 完結:2009/04/23
  • 第 1 回改訂:2009/04/25 right、bottom 指定をやめ全て left 又は top に統一した。
  • 第 2 回改訂:2009/04/26 画像も表示できるように引数処理を修正した。またポップアップ表示ボックスの色味を自在に操れるように引数を1つ追加した。これらによりこのプラグインの使いやすさが向上した。
  • 第 3 回改訂:背景やボーダーの色が思うように変化しないバグを修正
  • 第 4 回改訂:全面的改訂を断行。その内容は別のエントリイ → 自作プラグイン-アニメーションポップアップを全面改訂 にまとめました。これに伴いここで説明するプラグイン名を animatedPopupOld に変更しました。

残念ながら IE ではここで説明するプラグインは動きません。

その理由は IE8 のエラーメッセージに拠れば「 jquery.js のアニメーション関連コードに問題有り 」と表示されます。他方、Firefox、Opera 及び Windows 版 safari では問題なくこのページのアニメーションが表示されます。IE 8 で動かない理由は解明できていません。IE でも動くように改訂したいのですが、原因が解明できないため対応策が見つかりません。

ここで言う Animated Popup とは

ポップアップ表示をアニメーションメソッドを使って行うことを意味しています。例えば極小の点から一定の幅と高さを有する表示ボックスをズームポップアップし、それを消すときにはズームアウトするような、そんなポッップアップです。

Windows Vista でウィンドウ開閉時に行われるような、あのようなズームイン/アウトをポップアップ表示/隠蔽にも取り入れてみたいと思い立ち 4月11日頃に作成を開始しました。

何はさておき、その実例を示すことが先決でしょう。

下のボタンをクリックするとあるいはその近傍に、あるいは画面中央に、あるいは画面右下に、あるいは指定してある位置 {left:100px,top:200px} に、ポップアップがズームイン/アウトされます。表示する際のポップアップサイズは順に300、350、400、500px に、またアニメーションに要する時間はそれぞれ 1200、600、1600、2000 ミリ秒に設定してあります。

 クリックした位置の傍にポップアップ表示します。

クリックすると画面の中央にポップアップ表示します。

クリックすると画面の右下にポップアップ表示します。

クリックすると指定してある位置にポップアップ表示します。

クリックすると画面の中央に或るサイトの或る写真をポップアップ表示します。写真出典元は フォトライブラリ です。

▲ToTop

Animation と Easing

Easing は Animation 動作速度を変化させる「加速度メソッド」のことで、元々 Flash ツールである Acrion Script の Tween クラスの加速度メソッドとして誕生したようです。(半可通の知識しか持ち合わせていないので「ようです」としておきます。)

この Easing 関数が jQuery プラグインとして提供されているので、早速それを導入し、このページでは敢えて動きの激しい easeOutElastic を使用しました。本来、文字を表示するには変化の激しい elastic は相応しくないでしょうが、Easing を初めて使用した記念として「激しい」ものを選択してみたのです。

因みに、George Smith 氏により提供されているプラグイン「Easing Plugin」は 10 種類あり、各々に3つの効果(easeIn、easeOut、easeInOut)を持たせて Easing 関数が定義されているため、都合 30 種類の easing 関数があります。→ Plugins | jQuery Plugins

その Easing の各々の動きの違いを示したサイトとして興味深いのは、flash ムービーですが easing_demo が実に分かりやすく有益です。これによりそれぞれの Easing がどんな挙動をするのか一目瞭然に理解できます。easing 関数内の代数式がグラフ化されていることも非常に有益です。

そこで、このデモサイトをまねて、このページ上で実現しているアニメーションポップアップに対して 32 種類(jquery.js にビルトインされている linear と swing の 2 種類を追加したため 32)の Easing 効果を適用するリストボックスを設置してみました。easing_demo に比べて文字表示の場合には各 easing の差異がわかりにくいのですが、まあそれはご愛敬ということで...。

下のリストボックスの説明
  • アニーメーションポップアップの表示位置は 「 画面中央 」 としました。
  • Easing に要する時間はそれぞれの関数の差異が分かり易いように長めに設定しました(2秒)。
  • jquery.js に組み込まれている linear と swing の 2 つの Easing 関数もリストアップしたので都合 32 種類の easing 関数が登録されています。
  • 別の easing 関数を選択する前に表示されているポップアップを隠蔽する必要はありません。自動的に前の表示を消して、新たな表示を行います。
補足:上の リストボックスに係るスクリプトの説明

このページのソースコードを表示すれば分かることですが、jquery.js を使って初めて form を扱ったので、記録を残すために敢えてここに記します。

■アイテムが選択された際の処理を行うスクリプトコード
$("#sel707").change(function(){
 var index = this.selectedIndex,
   selEasing = this.options[index].value,
   txt="これは easing 関数: "+selEasing+" を使って<br />表示/隠蔽するアニメーションポップアップです。";
 $(this).animatedPopupOld(txt,["c","c"],2000,selEasing,{width:"400px"});
});
html説明
selectタグに id="sel707" と size=10を、最初の option タグに非選択属性 disabled="disabled" を、二番目の option タグに初期値 selected="selected" を設定しました。
Javascript 説明
  • 要点は selectタグの jQuery インスタンスに change イベントを登録することです。
  • まずリストボックスから選択されたアイテムのインデックス番号を変数に代入し、その値を使って options 配列から選択されたアイテムの value 値を取りだし、最後にポップアップ文を構成します。
  • 以上の僅か 3 つの変数を定義するだけで準備は完了。後は適切な引数付きで animatedPopup メソッドを登録するだけです。

以上の簡単なコードによって、リストボックス内の項目が選択されたその瞬間に発生する change イベントにより、イベントハンドラーが起動されて必要な処理を行います。

▲ToTop

作成した Animaeted Popup の仕様

  • 作成した Animaeted Popup は jquery.js のプラグインとして組み込める形式としました。
  • Animaeted Popup の呼び出しは次の書式で行います。jQuery(expr) はjQueryインスタンスならば何でも構いません。
    jQuery(expr).animatedPopupOld(contents, layout, duration, easing, options, options2);
  • <引数の説明>
     * contents: Strings in Animated Popup
     * layout: displaying position of Animated Popup
     *         text,ex. ["c","t"] (It means :left="center",top="top")
     *         or object,ex.{left:"100px",top:"200px"}
     *         or {left:"center",top:"100px"}
     * duration: durating time of animation(msec), ex.500 or "slow" etc.
     * easing: easing name (text), ex."easeInOutQuad","easeOutBounce",..32通りの指定が可能
     * 但し 32 種類を利用するには Easing Plugin をインクルードする必要があります。
     * このサイトで利用している jquery.js には Easing Plugin を組み込み済みです。
     * options: Add CSS Object to Popup DIV, ex.{width:"400px",・・・}
     * options2: Add CSS Object to Popup DIV's CLOSE Bar, ex.{background:"midnightblue",・・・}
     * 全ての引数にはデフォルト値が設置済みなので、複数の任意の引数が省略され
     * ても誤動作しません。
     * 何も引数がない場合、その旨を表示する animatedPopupOld を画面中央に表示します。

▲ToTop

作成した Animaeted Popup の Javascript コード

コードは長めになりました。説明を含めて 190 行あります。

ここでその全てを掲載しブロックごとに解説を加えることとします。

animatedPopupOld プラグインの全コード
  1:(function($){
  2:$.fn.extend({
  3:animatedPopupOld: function(contents,layout,duration,easing,options,options2){
  4:/*
  5: * <Example of Implementation>
  6: * jQuery("p").animatedPopupOld("And I love you so. Yesterday. Yellow Submarine.",
  7: *   ["c","b"],800,"swing",{width:"300px"})
  8: *
  9: * <arguments explanation >
 10: * contents: Strings in Animated Popup
 11: * layout: displaying position of Animated Popup
 12: *      text,ex. ["c","t"] (It means :left="center",top="top")
 13: *      or object,ex.{left:"100px",top:"200px"}
 14: *      or {"left":"center","top":"100px"}
 15: * duration: durating time of animation(msec), ex.500 or "slow" etc.
 16: * easing: easing name (text), ex."easeInOutQuad","easeOutBounce",...
 17: * options: Add CSS Object to Popup DIV, ex.{"width":"400px",・・・}
 18: * options2: Add CSS Object to Popup DIV's Title DIV, ex.{background:"midnightblue",・・・}
 19: *
 20: * <history>
 21: * released 2009/4/22 ver0.1
 22: * update 2009/4/25 ver0.2, 2009/4/26 ver0.3
 23: */
 24: var jQInst=$(this), winWH = {width:$(window).width(),height:$(window).height()},
 25:  errFlag,lcr,tcb,xName,yName,m=[],addValue={x:0,y:0},isImg,
 26:  mousePos={left:0,top:0},xCenter=$(window).width()/2,yCenter=$(window).height()/2;
 27:  // CSS 既定値は width 値が contents により変わるので、関数化しインスタンス毎に設定する。
 28: var defaultCSS =function(){
 29:  isImg = contents.match(/.*((<img.+src.+)|(<object.+)|(<embed.+)).*/i);
 30:  return {
 31:   "color":"white","font-weight":"bold","margin":0, "padding":"19px 5px 5px 5px",
 32:   /* 画像の場合ここで width を決めては駄目*/
 33:   "width": (isImg && isImg[1]) ? null : "300px",
 34:   "background-color":"royalblue", "border":"5px plum ridge", "text-align":"center",
 35:   "display":"block","visibility":"visible"
 36:  }
 37: }
 38: /* ポップアップに使用するCSS値を設定する*/
 39: var popupCSS = $.extend(true,defaultCSS(),options || {});
 40: /* closeBar CSS値も容易に変更できるように設定する */
 41: var closeBarCSS = function(){return $.extend(true,{
 42:  "position":"absolute","zIndex":"1001","text-align":"center",
 43:  "opacity":0.75,"top":0,"left":0,"width":"100%","cursor":"pointer",
 44:  "font-size":"small","lineHeight":"1.2em","background-color":"midnightblue"
 45: },options2 || {})};
 46:
 47: // bind onmousemove event on document
 48: mousePos.oX = 4; mousePos.oY = 16; //マウスカーソルからの離隔距離
 49: $(window).mousemove(function(e){
 50:  mousePos.left = (jQuery.browser.msie ? window.event.clientX - document.body.clientLeft : e.clientX) + mousePos.oX;
 51:  mousePos.top = (jQuery.browser.msie ? window.event.clientY - document.body.clientTop : e.clientY) + mousePos.oY;
 52: });
 53:
 54: // error 処理関数(後に拡張できるように関数にしておく)
 55: var errFunc = function(){ errFlag=true; return function(){return}}
 56:
 57: // animatedPopupOld の配置位置算出関数
 58: var getPos = function(layout){
 59:  if (layout && layout.constructor!= Object && layout.constructor!= Array ){
 60:   alert("配置は2つのテキスト:例 \"Center\",\"Top\" 、または\nオブジェクト形式:例 {left:\"10px\",top:\"100px\"} で指定してください。");
 61:   errFunc()();
 62:  }
 63:  var setPos = layout;
 64:  if (setPos.constructor==Array) {
 65:   var chk1 = /^((l.*)|(c.*)|(r.*))/.exec(setPos[0].toLowerCase());
 66:   var chk2 = /^((t.*)|(c.*)|(b.*))/.exec(setPos[1].toLowerCase());
 67:   if (chk1 && chk2){
 68:    lcr = chk1[2] && "left" || chk1[3] && "center" || chk1[4] && "right";
 69:    tcb = chk2[2] && "top" || chk2[3] && "center" || chk2[4] && "bottom";
 70:    xName = (lcr!=="right") ? "left" : "right";
 71:    yName = (tcb!=="bottom") ? "top" : "bottom";
 72:   } else {
 73:    if (!chk1 && !chk2) {
 74:     alert("左右上下 \""+ setPos[0] +" , "+ setPos[1] +"\" 共に指定が間違っています。\nやり直してください。");
 75:    } else if (!chk1 && chk2){
 76:     alert("左右の指定 \""+ setPos[0] +"\" が間違っています。\nやり直してください。");
 77:    } else if (chk1 && !chk2 ){
 78:     alert("上下の指定 \""+ setPos[1] +"\" が間違っています。\nやり直してください。");
 79:    }
 80:     errFunc()();
 81:   }
 82:  } else if (typeof setPos!=="string" && setPos.constructor==Object) {
 83:   for (name in setPos){
 84:    name=name.toLowerCase();
 85:    if (name=="left" || name=="right") {xName = name;lcr=name}
 86:    if (name=="top" || name=="bottom") {yName = name;tcb=name}
 87:   }
 88:   if (xName==null || yName==null){
 89:    alert("left、right、top、bottom 以外の\n指定は無効です。やり直してください。");
 90:    errFunc()();
 91:   }
 92:   // 位置指定値が "left" のように文字で為されたときの対応
 93:   if (!setPos[xName].match(/\d+/))
 94:    m[0] = setPos[xName].toLowerCase().match(/^(left|center|right)$/);
 95:   if (!setPos[yName].match(/\d+/))
 96:    m[1] = setPos[yName].toLowerCase().match(/^(top|center|bottom)$/);
 97:   if (!setPos[xName].match(/\d+/) && m[0]===null || !setPos[yName].match(/\d+/) && m[1]==null){
 98:    alert("配置指定値が間違っています。\nやり直してください。");
 99:    errFunc()();
100:   }
101:   addValue={
102:    x :( m[0] ? ((m[0]==="center") ? xCenter :0) : parseInt(setPos[xName])),
103:    y :( m[1] ? ((m[1]==="center") ? yCenter :0) : parseInt(setPos[yName]))
104:   };
105:  } else if(layout){
106:   alert("配置指定が無効です。やり直してください。"); errFunc()();
107:  }
108:  var obj={};
109:  obj[xName]= ((lcr==="center") ? xCenter : 0) + addValue.x;
110:  obj[yName]= ((tcb==="center") ? yCenter : 0) + addValue.y;
111:  return obj;
112: };
113:
114:$(function(){
115: // popup 表示用の div 要素タグの作成
116: if (!$("#dispElem").size()) {
117:  $("<div id='dispElem'></div>").css({
118:   position:"absolute",display:"none",zIndex:"1000"
119:  }).appendTo(document.body);
120: }
121: var disp=$("#dispElem");
122:
123: // Popup 隠蔽用×タグの作成
124: if (!$("#xMark").size()){
125:  $("<div id='xMark'>CLOSE</div>").append("<div style='width:13px;float:right;margin-top:-1em;'>×</div>").appendTo(disp);
126: }
127: var xMark = $("#xMark").css(closeBarCSS());
128:
129: // STEP1:*************** 表示前に popup エレメントの高さを測定する
130: var getElemWH= function(){ // 表示 popup サイズ算定
131:  // popup 表示前に横幅と文字数に応じた高さを計測する(非表示描画で測定)
132:  contents = contents || "ポップアップする内容が指定されていません。<br />やり直してください。";
133:  disp.html(contents).css($.extend(true,popupCSS,{"visibility":"hidden","height":null}));
134:  if(isImg && isImg[1]) disp.css("width",null);
135:  return {
136:   iW: popupCSS.width=(options && parseInt(options.width) || defaultCSS().width && parseInt(defaultCSS().width) || disp.width()),
137:   iH: popupCSS.height=disp.height(),
138:   oW: disp.outerWidth(),oH: disp.outerHeight()
139:  }
140: }
141:
142:  // 幅/高さが極小の要素 css 値を設定する。これにより拡張/縮小を演出する。
143:  // またここで初めてスクロールされていた場合の変動値を配置px値に追加する。
144: var shrinkCSS=function(){
145:  var scrLeft=$(window).scrollLeft(),scrTop=$(window).scrollTop(),
146:   obj={"width":"1px", "height":"1px", "border":"0px", "padding":"0px","margin":"0px"};
147:  if (!layout){
148:   obj.left=mousePos.left+scrLeft+"px";
149:   obj.top=mousePos.top+scrTop+"px";
150:  } else {
151:   var pos = getPos(layout);
152:   if (errFlag) return;
153:   obj.left=((xName=="left")-(xName=="right"))*pos[xName]+
154:    (xName=="right")*winWH.width + scrLeft+"px";
155:   obj.top=((yName=="top")-(yName=="bottom"))*pos[yName]+
156:    (yName=="bottom")*winWH.height + scrTop+"px";
157:  }
158:  return obj;
159: }
160:
161: var hideElem = function(e){ // popup 要素をアニメーション隠蔽する
162:  disp.empty().animate(shrinkCSS(),{queue:false,duration:duration,easing:easing});
163: }
164: var animaElem = function(e){
165:  $(":animated").queue('fx',[]).stop(); // 登録済みのアニメを全て削除停止する
166:  var doneShrink = shrinkCSS(); // この関数内で1回だけ起動する
167:  if (errFlag) return;
168:  // STEP2:***************
169:  var elemWH = getElemWH(); //エレメントサイズ計測実行
170:  if (!layout){ // 画面からはみ出さないように CSS 値を調整
171:   if (winWH.width < mousePos.left+elemWH.oW)
172:    popupCSS.left = winWH.width + $(window).scrollLeft() - elemWH.oW +"px";
173:   if (winWH.height < mousePos.top+elemWH.oH)
174:    popupCSS.top =  winWH.height + $(window).scrollTop() - elemWH.oH +"px";
175:  } else { // popup をセンター配置する場合の CSS 設定
176:   popupCSS.left = parseInt(doneShrink.left) -
177:    ((lcr==="center" || m[0] && m[0]==="center") ? Math.round(elemWH.oW/2) : (xName==="right") ? Math.round(elemWH.oW) :0) +"px";
178:   popupCSS.top = parseInt(doneShrink.top) -
179:    ((tcb==="center" || m[1] && m[1]==="center") ? Math.round(elemWH.oH/2) : (tcb==="bottom") ? Math.round(elemWH.oH) :0) +"px";
180:  }
181:
182:  // STEP3:*************** 極小要素を指定されたアニメーション起動位置に配置
183:  // dispElem の幅と高さを1pxにして所定位置に配置する(但し非表示描画)
184:  disp.empty().css(doneShrink);
185:  // STEP4:*************** 表示アニメーション
186:  disp.html(contents).append(xMark.css(closeBarCSS()))
187:   .css({visibility: "visible",display:"block"})
188:   .animate(popupCSS,{queue:false,duration:duration||"slow",easing:easing||"swing"});
189:  // STEP5:*************** × クリック時に隠蔽アニメーションを起動する。
190:  // ここで隠蔽関数を起動するようにしておかないと、複数回ボタンがクリックされた
191:  // 場合に隠蔽操作ができなくなる。理由は未解明。
192:  xMark.click(hideElem);
193: }
194: jQInst.click( errFlag ? function(){errFlag=false; $(this).unbind("click");} : animaElem );
195:}); // End of "DOMReady function"
196:} // End of "animatedAlert function"
197:}); // End of "Extend function"
198:})(jQuery);

▲ToTop

animatedPopupOld プラグインの解説

その意味や役割から幾つかのブロックに分けて解説します。

第Ⅰブロック(#1-22)

まず最初のブロックは、このメソッドの引数を定義しそれらを解説している部分です。

無名関数による起動と DOMReady 関数の利用(#1、#100)

このプラグインでは、一般的方法に倣って全体を無名関数で括り、即実行するようにしました。またポップアップ表示やポップアップ消去のための絶対配置 div 要素を追加し、かつそれらに様々なメソッドを適用する必要があることから、必要最小限の範囲を DOMReady function で括りました。

$.fn.extend クラスメソッドの利用(#2)

これにより、jQuery インスタンスのメソッドとして animatedPopupOld 関数を登録します。

animatedPopupOld 関数の引数(#3-18)

引数は6つあります。第一引数はポップアップボックス内に表示する文字列で、第2引数 layout は様々な方法でポップアップ位置を指定できるよう工夫し、第2引数を指定しない場合には、起動元 jQuery インスタンスが指し示す要素の近傍にポップアップするように設計しました。

第5及び第6引数も工夫しました。extend メソッドの2つめの使い方、つまり「 オブジェクト拡張 」を利用して、popup 要素のデフォルトCSS を設定しておくと共に、options で自在にそれを変更できるようにしました。幅や色、ボーダーの色と幅等々気分自由に変更することが出来るようにすることが目的であり、それを達成しました。

なお、この方法は jquery.js の Ajax ブロックで採用されていますのでそれを参考に考案しました。

▲ToTop

第Ⅱブロック(#24-45)

このブロックは、ローカル変数を定義している部分です。

■変数定義部分(再掲)
 24: var jQInst=$(this), winWH = {width:$(window).width(),height:$(window).height()},
 25:  errFlag,lcr,tcb,xName,yName,m=[],addValue={x:0,y:0},isImg,
 26:  mousePos={left:0,top:0},xCenter=$(window).width()/2,yCenter=$(window).height()/2;
 27:  // CSS 既定値は width 値が contents により変わるので、関数化した。
 28: var defaultCSS =function(){
 29:  isImg = contents.match(/.*((<img.+src.+)|(<object.+)|(<embed.+)|(<iframe.+)).*/i);
 30:  return {
 31:   "color":"white","font-weight":"bold","margin":0, "padding":"19px 5px 5px 5px",
 32:   /* 画像の場合ここで width を決めては駄目*/
 33:   "width": (isImg && isImg[1]) ? null : "300px",
 34:   "background-color":"royalblue", "border":"5px plum ridge", "text-align":"center",
 35:   "display":"block","visibility":"visible"
 36:  }
 37: }
 38: /* ポップアップに使用するCSS値を設定する*/
 39: var popupCSS = $.extend(true,defaultCSS(),options || {});
 40: /* closeBar CSS値も容易に変更できるように設定する */
 41: var closeBarCSS = function(){return $.extend(true,{
 42:  "position":"absolute","zIndex":"1001","text-align":"center",
 43:  "opacity":0.75,"top":0,"left":0,"width":"100%","cursor":"pointer",
 44:  "font-size":"small","lineHeight":"1.2em","background-color":"midnightblue"
 45: },options2 || {})};
jQuery インスタンスの取得(#24)

まず最初にこのプラグインの呼び出し元となる jQuery インスタンスを取得します。

DOMReady 関数内で jQuery インスタンスを呼び出そうとしたのですが、関数内では this は window オブジェクトを参照してしまうため、前もってここで取得しておくことにしました。

表示中の window の幅と高さの取得(#24)

これは jquery.js で定義されているクロスブラウザな便利なメソッドをそのまま活用しました。

これらの値を取得する意味は、画面の中央や左や右にピタリと寄せて配置する場合に利用するためです。

ポップアップ窓のデフォルト CSS 設定(#28-37)

ボーダーやパディング、そして色と背景色──これらの初期値を定めておかないとその都度思案し確定し指定しなければなりません。これはいかにも面倒なので既定値を設定しました。options で特に指定しなければ既定値が適用された popup 窓が表示されるわけです。

実は画像や動画にも対応させるために、最終段階でこのブロックを大きく改変しました。

#29 では正規表現を利用して img タグ、object タグ、embed タグ、あるいは iframe タグ文字列が第一引数 contents に含まれるかどうかをチェックします。そしてそれらのいずれかが含まれる場合には、デフォルト値としての画像サイズを設定しないこととしました。(#33)

これは引用先のCSS設定を反映する場合があったので、敢えて width 値を定めずにおいて、引用先サイトの padding 設定値なども反映した outerWidth 値を取得するためです。

実際に表示するポップアップ窓の CSS 値の指定(#38-39)

これには extend メソッドの2つめの機能である"ボブジェクト拡張"を利用しました。

optionsで任意の CSS 値を与えれば、デフォルトCSSを上書きしてユーザーの要望通りの表現を実現することが出来ます。また ||{} により options が指定されなかった場合にデフォルト値を利用するように工夫しました。

ポップアップ窓上辺の CLOSE バー CSS 値の指定(#40-45)

これも extend メソッドの"ボブジェクト拡張"を利用しました。

options2で任意の CSS 値を与えれば、デフォルト値を上書きしてユーザーの要望通りの表現を実現することが出来ます。また ||{} により options2 が指定されなかった場合にデフォルト値を利用するように工夫しました。

その他の変数(#25-27)

重要な役割を果たすローカル変数をここで定義しました。

addValue は配置位置がピクセル指定された場合のそのピクセル値を格納します。

mousePos はイベント発生要素の近傍にポップアップを配置する場合に必要となるマウスカーソルの現在値を所得するための変数です。

xCenter、yCenter は画面中央に配置するために必要な値で、それぞれ横方向の画面中央位置、縦方向の画面中央位置を取得します。

▲ToTop

第Ⅲブロック:マウス move イベントの登録とエラー対応(#4752)

第2引数 layout を指定しない場合に、マウスカーソル近傍にポップアップさせるためには、マウスの動きを常に Javascriptが 「監視」 しその位置を取得していなければなりません。そのためのイベント登録を行う部分です。これにより document の任意の箇所においてマウスカーソルの動きを常駐監視し、その位置を取得することになります。

 47: // bind onmousemove event on document
 48: mousePos.oX = 4; mousePos.oY = 16; //マウスカーソルからの離隔距離
 49: $(window).mousemove(function(e){
 50:  mousePos.left = (jQuery.browser.msie ? window.event.clientX - document.body.clientLeft : e.clientX) + mousePos.oX;
 51:  mousePos.top = (jQuery.browser.msie ? window.event.clientY - document.body.clientTop : e.clientY) + mousePos.oY;
 52: });
 53:
 54: // error 処理関数
 55: var errFunc = function(){ errFlag=true; return function(){return}}

ここでも IE が、IE だけが特殊な方法を採用しており、そのために面妖な設定をしなければならないのはユーザーにとって不幸なことです。早く IE のユーザー比率が低下することを願ってやみません。IE8 の登場によりその願いはまた叶うことなく先送りされてしまいましたが、中長期的には IE 固有の仕様は消え去る運命にあることは間違いないでしょう。

実際、後のエントリイで触れましたが、IE8 では少なくともスタイル設定に関しては Web 標準準拠に切り替わりました。これは 1 社だけで頑迷に固執し続けてきた奢りが、10年来のブラウザ戦争の中でやっと崩れ去ったことを意味しており、記念すべき歴史的事件と言って差し支えないでしょう。

#54 のエラー対応は「関数を返値とする」特殊な関数を利用します。これにより返値は return 値を有する関数となるので、errFunc()() のようにして、返値である関数を呼び出し先で実行することによりトップレベルにおいて return 値を返すことが可能となります。

ここに最初の括弧は errFunc 関数を実行するため、2つめの括弧は errFunc 関数の返値としての関数を実行するためです。#61 など随所で活用しています。

▲ToTop

第Ⅳブロック:ポップアップ配置位置の設定メソッド(#57-112)

このブロックはたった1つのメソッド登録ですが長大になりました。しかし、様々な指定方法に対応するために必要不可欠な部分であり、長くなってしまったのはエラー処理をふんだんに盛り込んだためでもあります。

#59-62 は最初のエラー処理です。

不適切な layout 指定があった場合の警告表示とコード進行停止を指定しています。

#64-82 は layout が配列だった場合の処理です。

#65-72 で、left、le あるいは l だけでも受容するように指定文字を簡略化できるように工夫し、所定の文字が与えられた場合には、それらを left、center、right、top、bottom の文字列に変換しています。

lcr には left、center、または right の文字が入力され、tcb には top、center、または bottom が代入されます。

また、xName には left か right が、yName には top か bottom が代入されます。

#73-81 は配列指定が適切ではなかった場合のエラー処理です。

#82-107 は layout がオブジェクト指定された場合の処理です。

#83-87では layout オブジェクトを走査して、配置指定に係る定義値を取得し、変数に代入します。捜査の結果必要な文字がなければ #88-91 でエラー処理します。

#92-100 は 配置指定が px 値ではなく "center" などの文字列で行われた場合の処理です。

#93-97 で配列 m に横方向と縦方向の配置指定文字列を代入し、layout が適切な指定でなければ、#97-100 でエラー処理します。

#101-107 では縦横方向の配置指定値を取得します。

二項演算子を活用して、センター配置か否か、及び px 指定値がある場合の2つのケースから値を取得します。

エラー発生時には空オブジェクトを返すようにしました。

#108-110 ではここ迄の処理で確定した配置用変数を活用して CSS 値を設定します。

センター配置の場合のみ画面中央位置を取得し、その他は指定されていればピクセル値を代入します。

▲ToTop

第Ⅴブロック:ポップアップ用 div 要素の作成(#111-134)

ブラウザにとってポップアップ用要素が用意できなければ何も始められないため、これ以降は DOMReady 関数で括ります。

popup 表示用の div 要素タグの作成(#115-120)

2回目以降の animatedPopupOld 起動時に dispElem が重複設置されないように 116 行でこのノードの存在確認を行います。もし存在すれば、改めて変数 disp に当該ノードを参照する jQuery インスタンスを登録します。

存在しない場合には、タグ要素を CSS 設定値を含めて作成し、その後に jQuery インスタンスを作成し変数に代入します。

この CSS 設定では絶対配置、非表示、レイヤー順を指定し、ポップアップを自在に配置できるように、また body 部に追加した時点ではそれが表示されないよう準備します。

popup 隠蔽用×印タグの作成(#123-127)

ポップアップ用 div 要素の右上にこのポップアップを隠蔽するためのバツ印を用意しました。ここでも二重登録しないようにこの要素の存在確認を行います。

更に×印だけではマウスカーソルをその位置にフィットする手間が面倒なので、隠蔽クリックを受け入れる箇所を点から線に拡張して、タイトルバー形式にしました。

▲ToTop

第Ⅵブロック:アニメーション用の諸関数定義(#129-193)

ここ迄でアニメーションポップアップのための準備が終わりました。愈々、動きのあるポップアップ表示や隠蔽操作のための関数を定義します。

ポップアップする要素の高さのサイズを測定する getElemWH 関数

まず第一引数 contents が未指定の場合の対応を 132 行で行いました。未指定の場合には所定の文章( || の右側の文章 )を用意しておき、これを animetedPopup 関数を使ってポップアップします。

文字列をポップアップする場合特に、その要素サイズを「表示前に」如何にブラウザに知らせるかが課題となります。文字列の文字数が固定されていても、文字の横幅は一定ではないので内容によってはサイズは変わりますし、一般にポップアップ表示を行う文字列は長さは不定・可変です。そのためブラウザは、幅が指定されていなければ表示領域一杯の幅が指定されたものと見なし、或いは要素の幅が指定されている場合にはその幅で要素を表示しますが、ブラウザはこれらのいずれの場合においても、要素表示前にはその要素の高さを認識しません。

別のエントリイで不定型ボックスサイズを表示する前にブラウザに認識させる方法について詳細に触れましたが、このプラグインで採用した方法は、自前で考案した透明化してサイズを測定する方法ではなく、jquery.js で利用されている visibility 属性を利用する方法を採用しました。

jquery.js で採用している表示前サイズ計測方法は、1. position : absolute、2. display : block、3. visibility : hidden とすることにより、「絶対配置のブロック表示状態にしてそれを表示させない」状態を作るものです。(jquery.js: css 関数内の #773 で呼び出される #735-748 の swap 関数)

なお、このプラグインで実際に必要となるのは outerHeight と innerHeight なのですが、この際無意味ですが4つのサイズを測定しておくようにしました(苦笑)。

またinnerHeight については、代入式を iH のプロパティ値とすることにより、同時に 2 つのプロパティに値を取得させました。

ポップアップボックスの拡張/縮小を演出する shrinkCSS 関数

アニメーションを演出するために幅と高さが極小のスタイル値を設定します。これによりアニメーションの始点と終点の位置と要素の表示状態を取得します。

またアニメーションの始点/終点を取得するためには、縦横のスクロール状態を Javascript インタープリタに認識させなければなりませんから、この関数内でスクロール値を取得します(#145)。

後述するように、クリック時のイベントハンドラー内から、shrinkCSS 関数を呼び出して、そのときのスクロール値を取得します。

次にこの関数内から #151 で getPos 関数を呼び出していますが、これにより画面内の左右上下中心のどの位置に配置するか、あるいはマウスカーソルの近傍に配置するかを確定します。

エラーフラグが立っている場合にはコード進行を止めます。(#147)

#153-156で right や bottom 指定された場合に left や top に変換しています。

right / bottom 指定された値をleft / top に変換する計算式は、最後の最後まで苦労を重ねました。getPos 関数からの戻り値は、right / bottom 指定のママですが、#153-156 においてこれらを left / top に変換します。この結果 shrinkCSS 関数からの戻り値は left / top のみとなります。

popup 要素をアニメーション隠蔽する hideElem 関数

これはいわば逆アニメーションで、animaElem 関数で表示したポップアップを縮小しながら隠蔽します。最初にコンテンツを削除してから shrinkCSS 関数をよびだし、かつこのアニメーションを待ち行列に登録しないよう queue 値を false にします。

なお、shrinkCSS 関数でエラーが発生する可能性がありますが、hideElem 関数は、必ずanimaElem 関数が走行した後にしか起動されず、animaElem 関数内において shrinkCSS 関数にエラーが発生した場合の処理は記述されています。エラー発生時には hideElem 関数呼び出しまで到達しませんので、当該関数ではエラー処理を必要としません。

アニメーションポップアップ表示を行う animaElem 関数

ここでは次のような様々な処理を行っています。1.登録アニメーションの削除と停止(#165)、2. この関数内で一回だけ shrinkCSS 関数を呼び出し、結果を変数に記録(#166)、この返値が空の場合の処理(#167)3.画面からポップアップをはみ出させない処理(#170-174)、4.画面センターに配置する場合、あるいは right / bottom が指定された場合の、ポップアップサイズと表示位置の調整(#176-180)、4.アニメーションの始点設定(#184)、5.アニメーション表示(#186-188)(ここでも隠蔽処理同様に待ち行列には登録しません。)、そして 6.ポップアップ窓の隠蔽ハンドラー呼び出しです(#190-192)。

ここでの要点は以下の点です。

  • ポップアップ要素を画面外にはみ出させない処理のために必要となる要因は、画面サイズ、スクロール値及びポップアップ要素のサイズです。
  • アニメーション待ち行列の扱いは、全てのアニメーションを非登録としました。当然ですが登録してしまうと、二度目以降の animatedPopupOld() 起動時において、最初以降から直前までの以前に利用したアニメーションが順次起動してしまうためです。
  • 179行で、duration や easing が指定されなかった場合のデフォルト値を設定しました。
  • ポップアップの隠蔽はクリックイベントを登録して行いますが、表示関数の中から行うようにしました。連続してクリックしてポップアップさせた場合に、クリックしてもそれを消せない場合が発生したためです(原因は不明)。

▲ToTop

第Ⅶブロック:クリックイベントの登録(#190)

最後の処理です。要素タグへのクリックイベント登録では、エラー発生時に登録済みクリックイベントを削除するようにしました。ここで最初にして最後ですが errflag 値を利用します。

イベントハンドラー内で使用した $(this) は click が jQInst のメソッドですから、jQInst を参照します。

IE8 RC版導入

IE8 のリリース候補版がダウンロード開始 2009/01/27

米マイクロソフトのIE開発チームは1月26日、次期 Web ブラウザのリリース候補版となる「Internet Explorer 8 Release Candidate」(IE8 RC)のダウンロード提供を開始したと発表した。───IE8のリリース候補版がダウンロード開始 - @IT

上記エントリイで紹介されているように、先週月曜日に IE 8 RC 版が提供開始された。

概要紹介はこちらのサイト( 次期ブラウザー「IE8」製品候補版を高速レビュー:ラボラトリー )にある。

早速インストールしたが、まだベータ2 との機能上の相違は未確認だ。

しかし、これまでベータ 2 で おかしかった Javascript の動作が正常となったことは喜ばしいことだ。

このブログでは ajax 通信を利用して、任意エントリイの「以前、最新及び以降」の各10エントリイタイトルリストを取得しているのだが、これが IE8 になってからうまく作動しなかったのだ。

他のブラウザ(Firefox、Opera、safari 及び Google Chrome)では問題なく作動するのに、IE8 だけ、ajax通信の進行が途中で止まってしまっていたのだ。

▲ToTop

果たして IE8 正式版はいつ? またブラウザ戦争の行方は?

今年に入って Windows 7 のベータ版ダウンロードが開始されたことは記憶に新しい。(1/8~2/10)

IE8 は Windows 7 の正式発表と同時に正式発表か?──との情報もあるようだが、急速にテンポアップしてきた感のある Windows 7 の登場と歩調を合わせることになるとすれば、来年初めくらいには正式版が登場するのかもしれない。

しかし、その正式版登場がいつになろうとも chrome 登場によって途端に激化しつつあるブラウザ戦争の勝利者になれるかどうか、予断を許さないだろう。

何故ならば、Google Maps やオンラインオフィスソフトの提供によって一躍脚光を浴びているJavascript インタプリタの実行速度において、勝敗は既についているからである。

すなわち、chrome や firefox の Javascript 実行速度は IE8 のそれを遙かに凌駕しており、その速度差が逆転するとはどうしても考えられないからである。

実際IE 8 RC 版になってもその実行速度は相変わらず chrome や firefox の足元にも及ばないからだ。

それにも拘わらず、未だにIEは 6 7 8 のそれぞれのバージョンが広く利用されており、それらをトータルした市場占有率は日本では相変わらず 7 割台を確保している。極めて遅いがシェアの高いブラウザIE───その牙城が突き崩されるほどのプレゼンスを chrome または firefox は示せないでいることも確かだ

それでも尚、激化しつつあるブラウザ戦争にここ数年間は目を離せないことは言うまでもない。

例えば、こんな記事もある。既にIEが Firefox に逆転されている!

▲ToTop

【PDC2008】情報──Windows 7でVistaの不満点は着実に改良される?

Vista で最も不評な UAC が Windows 7 で調整可能になる?!

何が悪いかと言って、特定の仕様がこれほどOSの欠点として問題視されたことは、これまでになかったではないだろうか?言わずもがな!、悪名高き 「 UAC 」 である。

それが Windows 7 では 「 緩和 」 されるようだ。

ベータ版を出し、発売前にユーザーの声をそれなりに聞いたはずなのに、結局発売してからでなければ問題性に気がつかなかったとは、マイクロソフトの殿様商売ぶりを象徴していると言えよう!

さて、UACの具体的な改善策は以下のようになるようだ。

Windows Vistaから搭載されたユーザーアカウント制御(UAC)。……悪意あるソフトウエアが自動実行されるのを防ぐために搭載されたものだ。いちいち確認画面が表示されて煩わしい半面、この機能をオフにするのも不安ということいで、Vistaユーザーからは不評だった。

いわば、その中庸策として登場したのがUACの調整機能である(図3)。確認画面を表示するレベルを4段階に調整できるようになった。例えば、下から2番目にしておけば、Windowsの設定を変更するときには確認画面が出ないようになる。

出典:【PDC2008】Windows 7で着実に改良されているVistaの不満点:ニュース

▲ToTop

ユーザーを振り回すのはやめてくれ!

マイクロソフト社は仮にも世界一のソフトウェア会社である。Windows は文字通りの意味で世界を席巻し、確たる地位を築いた。

なればこそ、その地位に胡座をかいている今の状態は許し難い。

だから声を大にして叫びたい───Vista の失敗を償う唯一の道は、Vista ユーザーへの Windows 7 の無償アップグレードしかない!!

少なくともUAC緩和策は Windows Update で Vista ユーザーに無償提供すべきだ。それが謙虚な「お詫びの印」というものではないだろうか!

Gyao Reader の進化について

Gyao サービス登場から暫くしてこのソフトが登場した(2006/7/18 Ver0.0.0 公開)。当時はまさに Gyao Reader の名の通り、Gyao サービスをより便利に閲覧するためのリーダーだった。しかし、動画共有サイトの爆発的な増加を背景にそれは次々と進化を遂げてきた。

まず、対応サイトを、Yahoo 動画、Biglobe 動画、歌ブログ、ニコニコ動画、YouTube、veoh、GUGA、PANDORA.TV、MySpace 等々、次々と増加させ、再生可能なコーデックも FLV だけではなく MP4 にも対応した。更に、AVI、WMV、3GP への変換機能を搭載し、最近ではパケット解析による動画ダウンロードにも対応した。

かくして、Gyao Reader は今や all-round な動画再生・ダウンロードツールへと昇華しつつある、と言えるだろう。

さて、21世紀になってから日本でもブロードバンド通信が急速に一般的になったこと、TV 番組のアップロード・ダウンロードに係る著作権問題への対応がこれまではフリーであること───この2つの客観的条件が今日の乱立する動画共有サイトを花開かせた。

同時に、それと並行して、動画再生・ダウンロードツールが百花繚乱に登場・機能アップし、Gyao Reader も漸次多機能化してきたわけだ。

以下に著名なツールを概観してみる。

クラウド( または SaaS )の威力とマイクロソフトの模倣的行動

クラウド( または SaaS )とは

昨日の NHK 番組『クローズアップ現代』において「 クラウド 」が取り上げられていた。

「雲」とはいったい何なのか? IT 関係の事象を指していることは直ぐに分かったが、その全容や本質は番組だけでは十分に理解できなかった。それにも拘わらずインパクトは大きかった。

そのインパクトの内容と大きさに触れる前に、まずクラウドの概要を引用からまとめておくことが必要だろう。何故ならば、それは個人ユーザーにとって余り聞いたことのない呼称であり、故にそれを知っている人は、 IT 関係に携わっている人やネットワークソリューションズマニア等、相当限定されると思うからだ。

  • 提唱者は Google のエリック・シュミット CEO だそうだ。
  • ソフト開発もハードの調達もシステム運用も一切必要ない。すべてはインターネットという“雲”にアクセスするだけ。
  • クラウド・コンピューティングでは、企業システムを構成するあらゆる要素をインターネットの“向こう側”に置き、ユーザーはそれらをサービスとして活用する。
  • ソフトウェアがパッケージとして販売された時代とは異なり、クラウドコンピューティングを支えるのは広告だとシュミット氏は言う。「クラウドコンピューティングと広告は手を取り合って進む。これは新しいビジネスモデルで、広告がけん引して、ソフトウェアイノベーションのための資金を提供している。」
  • そして、Googleに刺激されて、巨人 Microsoft も動き出した。本格的なインターネットサービス時代の幕開けを思わせる。クライアント/サーバーからのパラダイムシフトである。
  • クラウドにコンピューティングは錚錚たる企業が名を連ねている。Google、Salesforce、IBM、Amazon、etc.
  • 消費者市場において Web 2.0という言葉が一世を風靡したが、クラウドは企業市場における Web 2.0といっても良い。

クラウド( または SaaS )の衝撃

次に、クラウドのインパクトを列挙してみる。

  1. クライアントパソコンには、基本的にブラウザ以外のアプリケーションは不要である。
  2. PCにアプリケーションをインストールしない分だけ、PC管理コストが圧縮される。
  3. 各種ビジネスシーン(営業、経理、庶務等々)に対応したソリューションが提供され、しかもそれが処理能力の高いサーバーで処理されるため、極めて効率的な業務遂行が可能となる。(『クローズアップ現代』が取り上げていた例は Salesforce 社のクラウドだったが、同社のサーバーは Super Computer だそうだ。)
  4. 社内・組織内の情報の共有化が真の意味で可能となる。
  5. 大企業はもとより中小企業にとっても利用価値が高い。それは基本的にユーザー数に応じた利用料金しか発生しないためだ。
  6. それ故に利用者の増減に機敏に対応出来る。
  7. しかし!。顧客情報も戦略情報もありとあらゆる情報が全てサーバーに置かれることなら、データセキュリティ上根本的な問題がある。事実、情報漏洩事件も起きている。
  8. ...

ここで思い起こされるのは Web 2.0 だ。例えば Gmail では、全てのデータが Google社の サーバーに置かれ、ユーザーはブラウザ以外のアプリケーションをインストールすることなく、E-mail 機能を利用している。

こうした関係性が組織・企業とサーバー管理会社との間で確立するのがクラウドと言えるだろう。

自然界の雲は天気に左右され誕生し消失するが、クラウドにおいても、利用する団体及び個々の利用者は、サーバーの信頼性を神頼みするしかない。情報の紛失・漏洩・破損等々の全責任はサーバー会社にあるが、被害を被った場合の回復は相当の賭と言えよう。

実際、多くのオンライン・ストレージ・サービス(またはインターネットファイル共有システム)では、突然のファイル消失事件が少なからず発生しているし、消失したファイルが回復しなかった例も報告されている。

つまりクラウドは諸刃の剣だ。それでも余りに効率的、経済的、効果的に利用できるが故に、今後ますます伸張するのかもしれない。

▲ToTop

またしても模倣のマイクロソフト!

MS-DOSがマイクロソフト純正ではないことはよく知られた事実である。Windows95ではインターネット接続はおまけ的扱いだった。IEは Firefox や Opera に Javascript 動作の余りの遅さで大きく水をあけられ、やむなくIE7、IE8と矢継ぎ早にバージョンアップを迫られた。鳴り物入りで登場した Vista は早くも短命に終わろうとしている。

そして同社は今度クラウドに参入するらしい。

商機を観て乗り遅れんとばかりに参入するその体質は一向に変わっていない、といっても過言ではない。

しかしだからこそ、牽引者、トップランナーには成れなくなってきているのだろう。

「栄枯盛衰、奢れる者久しからず」───故に、Google 社にもいずれは斜陽の時代がやってくるだろうが、まずはマイクロスフと社の「傾き」が先行するようだ。

Vistaの普及度合いを MyBlog へのアクセス解析から知る

Fc2 アクセス解析によりこのブログへの OS 別アクセス数を分析してみた

2008年10月のアクセス全てを対象として OS 別の内訳を調べたところ、下図のような割合となった。

OS 別アクセス数・割合図

概観するとマックは 4 %弱で圧倒的に Windows が多くその約 8 割は XP で占められている。一方Vista は 16 %に過ぎない。

ここにも発売後 2 年弱の年月が経過しているにも拘わらず、Vista の普及が遅々とした歩みとなっている一端を垣間見ることが出来る、と言えるだろう。

因みに私の勤務先でも、組織として Vista には対応していない。現状では Vista に対応出来ない社内システムが多数存在している。そして少なくとも年内は Vista は一切使用できない環境となっている。仮に Vista PC があったとしても、社内システムの殆どが利用できないのである。

このような会社、行政機関、団体はおそらく極めて一般的なのではないだろうか?!

そしてそのことは個人宅におけるPC買い換えやOS入れ替えを限りなく抑制するだろう。

かくしてマニアは別として、大半の PC 所有ユーザーは Vista への乗り換えを思い切る積極的理由が見あたらないと思われる。

▲ToTop

いかにも使いにくい OS は早く消え去るべきである

ユーザーに多くの負担を強いる OS は決して歓迎されないし、長命ではないだろう。Vista はおそらく短命で終わらざるを得ないだろう。Windows Me がそうであったように、不完全な OS として歴史に刻まれるのではなかろうか?

とはいえ、では次なる OS は期待できるのだろうか、という疑問が必然的に湧いてくる。

幾つかの報道によれば、Windows 7 は Vista ベースの OS だと言われているので、根本的な改善とはならない可能性も捨てきれない。

もしそうなれば、OS とアプリケーションの独占的地位を欲しいままに享受してきたマイクロソフト帝国の崩壊への序曲が奏でられないとも限らない。

否、OS 激動の序奏はもう始まっているのかもしれない。携帯OSアンドロイドはその象徴的な狼煙なのかもしれない。「携帯を制する者が PC を制す」───そんな段階へと階梯が築きだされたのかもしれない。

 90%近いシェアを握っているインターネットエクスプローラの描画エンジンを利用したタブbrowser。沢山のタブbrowserがあるが、多機能、カスタマイズフリー、スクリプト利用等で一日の長がある。Gekkoエンジンへの対応も行われ、IEからの自立独立の方向に向かっている。2005年7月にはIE7が登場する見通しの中で、今後の発展が望まれる。

 多様なCSS作成支援機能を備えた、タグ入力式 HTML&CSS作成支援エディタ。スキンデザインもすっきりしている。テキストエディター上で作成するよりも確実で安全にタグ打ちが出来る。
文字コードを選べないのが欠点。

 StyleNote同様のタグ入力式 HTML&CSS 作成支援エディタ。長年使用してきたが現在StyleNoteに乗り換えつつある。

 クリップボード履歴情報を活用する為のソフト。画像まで履歴を取ってくれるのが嬉しい。このソフトを使わない日は絶対ない程に重宝し、愛用している。

 起動中のウィンドウの「コピーできない」説明文などの文字列を取得し、コピー可能な文字データにするツール。何かと便利。

 ストリーミングデータを保存することが出来るソフト。動画利用には不可欠なソフトだ。

 無料ながらレイヤー機能を有し、スクリプトによる拡張も可能な、sleipnir作者が提供している優れもの画像編集ソフト。

 画面キャプチャソフトと言えばこれに勝るものなし、ではないだろうか? 様々な取得方法を有しており、ブログ作成にもHomepage作成に不可欠だ。Jtrimと並んでWoodyBellsの作品。

 複数ファイルの同時編集は出来ないが、透過pngも作れる画像編集ソフト。
(以下当該サイトから抜粋)初心者にも簡単に操作が出来るフォトレタッチソフトです。多くの加工機能で画像に様々な効果を与えることができます。非常に軽快に動作するため、ストレスなく操作できます。

 Animation Gifファイルを作れる無料ソフト。

 キャプチャソフト。画面内にサイト全体が表示しきれない場合でも、これを使えば全体をキャプチャすることが出来る。

 画像処理。画像のフォーマット変換のみならず、色数やサイズ、圧縮率の変更まで一括処理できてしまう『BatchGOO!』は、大量の画像をまとめて処理したいときに大変便利なソフト。BMP, TIFF, JPEG, PCX, PNG の相互変換をはじめ、色数・サイズ・解像度の統一、JPEG圧縮率の調節など、ホームページ用の画像や携帯電話用の壁紙を揃えるのに抜群の相性を見せる。(Vectorの当該ソフト紹介頁より抜粋引用)

 名前から直ぐに想像が付くように画像のサイズを測るためのソフトだ。Homepage作成には欠かせない。2カラム、3カラムのレイアウトを行う場合に大変重宝する。

 ランチャーソフトは沢山あるが、中でもこれが一押しだ。2年以上使ってきたがその操作性には毎日満足している。これを使い始めてからデスクトップには一切のアイコンを表示することをやめてしまった。

 AdobeReader7によって、起動時間が長すぎるという長年のユーザーの不満はある程度解消した。そのためこの高速化ソフトは存在価値が低下してしまったかもしれない。AdobeReader6迄はこのソフトによる起動高速化で恩恵を受けてきた。

 IE専用が難点だが、様々なサイト内でIDやパスワードを入力するのに重宝するソフト。コンテキストメニューから簡単に起動できるのがGood! sleipnir等のIEの描画エンジンを利用しているブラウザでも使える。

 利用しているパソコンの諸元値を取得するには、このソフトがベストだ。インストール済みソフトの一覧が取得できるのも嬉しい。

 WMPは機能が豊富なだけ重い。RealPlayerも同様だ。そこでMedia Player Classicを使いたい。動作が軽快なだけではなく、対応しているファイル形式もすこぶる多く、これひとつで、wmvもrmも表示できてしまうのだから凄い! 数多あるMedia Playerの王様と言えるだろう。

 自宅でPCを起動しているときには必ず起動しているメディアプレーヤー。何かと過剰なWinampよりも、起動も速くスキンはシンプルだ。

 DivX, Xvid, Mov, Vob, Mpeg, Mpeg4, avi, wmv, dv, などの動画をDVD-Video形式に変換できるフリーソフト。クリックするとDVD関連ソフト紹介サイト=「DVDなToolたち」なるHomepageが開きます。

----------
201206171119
201201250903
201101310155
201101130146
201101050059
201012082037
201012041751
201009052249
201003220156
201002280222
201001130001
201001060743
201001041159
200904060045
200902020127
200811060017
200810181153
200810170136
200810150002
FC2 Management
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。