06 | 2007/07 |  08

  1. 無料サーバー

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

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


遅々として進まないprototypeの学習

現状

これまで見よう見まねで書いてきた「普通の」Javascriptコードに較べて、コンストラクタやクラスの定義におけるコードは勝手が違って手こずっています。

オブジェクト指向をマスターしようと思い立ち、コンストラクタ関数を理解し、さてprototypeオブジェクトに取り込もうと意気込んだまでは良かったのです。

そしてprototypeをマスターする方法を探している内に、prototype.jsの存在を知り、これを理解する過程を通じてprototypeオブジェクトの理解ができると考え、prototype.jsの解読に取組み始めました。

prototypeオブジェクトがどの様な機能を有しているのか、と言う点については直ぐにすっきり理解できたのですが、いざ自分でオブジェクト指向なコードを書こうとすると、なかなか先に進まないのです。進めないのです。

何故すんなりオブジェクト指向なコードが書けないのか?

これまでは常にウェブ頁内の様々な要素を対象としてコードを書いてきました。そこで登場するthisは要素を指すキーワードでしかなかったから、thisが何を指すのか悩まされることはなかったのです。また常にウェブページ内の要素が対象だったために、抽象的な概念であるクラスなるものを考える必要もありませんでした。オブジェクトを作成してからそれをウェブページ内の特定の要素に結びつける苦労もありませんでした。

こうした経緯から、オブジェクト指向なコードとは無縁だったわけで、「全くの新境地に踏み込んだことに戸惑っている」わけです。

しかし、いつ迄も戸惑っているだけでは先に進めないし、ウェブ頁と無縁なコードをいくら書き進めても、実質的に意味がありません。そもそもウェブ頁を色々コントロールするためにJavascriptを使おうとしているのですから。

そんな訳で、引き続き学習を進める以外に、現状を打開する道はない──ということになるのですが・・・。

prototype学習メモ:this を理解する

thisとは何か?

直前のエントリイでいきなりprototype.jsを題材にしてthisを理解しようとしました。しかし、それは方法として間違っていたようです。

クラスというJavascriptには存在しない概念を、恰も存在するかのように設定するのがprototype.jsだということを、真正面から受け止めていなかったからです。prototype.jsで定義されるvar Classも明らかにオブジェクトですが、それはnew演算子で生成されるオブジェクトとは異なるレベルの、特異なオブジェクトと理解すべきなのでしょう。コンストラクタ関数の定義で定立される左辺のvar ○○と同等のオブジェクトがClassのようですから...。

そこで方向を変えて、改めてthisについて考えてみることにしました。

或る書籍(「まるごとJavaScript & Ajax ! Vol.1」)に「thisは(或る)関数オブジェクトを呼び出した時に、その関数オブジェクトを格納したオブジェクトを指す」という説明がありました。様々な書籍でthisの解説を探ってみましたが、この定義が最も分かりやすい表現でした。(Javascript第3版(日本語訳)の説明は非常に分かりにくいものでした。「コンストラクタは(new演算子によって)新たに生成された空のオブジェクトへの参照を特殊なthisキーワードの値として受け取る」)

つまり、「或る関数が呼び出された場合において、当該関数内に記述されているthisは、当該関数を格納していたオブジェクトを参照する」と表記するのが適切かと思います。正しく理解される日本語は難しいものですね。

prototype学習メモ:基本をしっかり知るために愚直に

遅々として進まないprototypeの学習──キーワード:thisが難しい

遅々として進まない原因はJavascript半可通なるが故です。これまではあちこちのサイトや本でゲットしたコードを、このブログ用に微修正してコードを書いてきました。つまりオブジェクト指向風のコード記述は一切行わず、必要に応じて関数を作り、イベントハンドラーはその殆どをHTML要素内に記述してきました。

その際、当初はキーワード「this」の扱いに苦慮しましたが、html要素内にイベントハンドラーを記述する古典的な方法を採用する限り、「this=当該イベントハンドラーを属性として有する当該要素」であり、それ以外の意味はないので、一度慣れてしまえばthisの利用は容易なことでした。

ところが、コンストラクタ関数とprototype Objectを活用してコードを書こうとすると、途端にこの「this」が重くのし掛かってきました。

コンストラクタ関数やprototype オブジェクトでは「this」を効果的に利用しない限りコードは殆ど記述出来ないので、thisについて半可通なままで先に進めないことを痛感したのです。

因みに prototype.js では、随所に沢山の「this」が登場します。

prototype.jsの根幹を為す Class Object の定義において早くも this が2回登場するし、thisを拘束するために便利な bindメソッドを利用しようと思えば、当該定義においては関数自身を指すthisについて、しっかり理解しない限り思うようにはいきません。

簡単なコードからthisを理解する

実際にコードを分析することが好ましいので、prototype.jsの学習を兼ねて、そこからthisキーワードが含まれているコードを抜粋して、考察を加えることにします。まずは何はさておき、次のClass定義から。

var Class = {
  create: function() {
    return function() {
      this.initialize.apply(this, arguments);
    }
  }
}

いきなり大変難しい構文です。Classと言う名のオブジェクトを、createなるプロパティ名と或る関数をプロパティ値として設定し、しかもその関数の返値として別の関数自体を設定しています。

ここにthisは2回使われています。これらのthisが何を意味するのか理解したいと思います。

まず最初のthisです。───未完───

18日のユニークビューが1000台を突破!

それは記念すべきことです

昨年末に200台を突破、つい先日500台を突破したと思ったら、18日は何と1,100越えを記録しました。このユニークビューの急増現象はどうしてなのか、それをアクセス解析を通じて調査してみました。

その結果、あるサイト(カトゆー家断絶)からの訪問者が激増したためであることが判明しました。

カトゆー家断絶はカウンター数8千万overのサイト、このサイトからのアクセスだけで、18日に600over/日を記録していたのです。

そして上記サイトを訪問させていただいて、標準のブラウザを徹底してSleipnir2に設定するエントリイにアクセスが集中しているらしい、と言うところまで突き止めました。

その後19日のアクセスは400台にダウンしましたので、ユニークビュー1000オーバーは「真夏(ではないなぁ(苦笑))の夜の夢」となったようです。しかし、カウント数を得る為にエントリイを投稿している訳ではないので、結果を目的とする必要はないから、一喜一憂するほどのことではないでしょう。

何はともあれ多くの方に閲覧してもらえることは嬉しいこと!

そうなのです。ある意味ではマニアックなこんな拙ブログでも毎日数百人の方々が閲覧してくださっている、ということはそれだけで励みになります。拙文でも、見ず知らずの方々に目を通してもらえるということは嬉しいことです。

そんな訳で1000カウントオーバー記念として、このエントリイを書いた次第です。

Prototype.js学習によって、これまでの我流Javascriptコードの拙さを痛感させられた

それは衝撃の連続だった(苦笑)

3277行(prototype.js Ver1.5.1.1)の全行を見て痛感したのです。そこにはこれまで我流で頭を痛めてきて、一定の解決に至ったものの、決して美しくなく、また合理的でもなかったMyコードの各種課題の全て───イベントObject関連の各種コード、要素属性取得・マウス位置取得コード、配列に係るコード等々───が、極めて包括的・根源的なコードで記述され、解決されているということを!

これをベースとして、複数のLibraryが登場し、Javascript Librariesの中で圧倒的な人気を博しているのも頷けます。All about等で話題となっている後発のYUIとの比較なども興味深いところです。

更に、こうした Library全盛の今日にあって、この8月に日本語訳が出版される、『Javascript第5版』(原著は昨年8月に出版済みらしい)に興味津々です。Javascript1.5に準拠した詳細な解説を今から心待ちにしてます。なお、第3版和訳では、おかしな日本語が散見されましたが、今度はそのようなことがないと良い。のですが・・。

全面的にMyCodeの修正をしていきたい

prototype.jsを学びつつ、その神髄を理解し、MyCodeを全面的に見直してみようかと思い始めています。

MyCodeの全体をprototype.jsの全面採用Codeに書き換える道もありますが、しばらくは部分的な改変を重ね、一歩ずつ修正していくことにしようと思います。「千里の道も・・・」ですから。

prototype.jsの最初の関門はClass定義にある

prototype.jsでClass.create()はどう使われているか?

3277行に及ぶprototype.js(ver1.5.1.1)の中でClass.create()は16回使われています。次の16個のClassオブジェクトが定義されています。

  • PeriodicalExecuter、
  •  
  • var Template、
  •  
  • ObjectRange、
  •  
  • Ajax.Request、

  • Ajax.Updater、
  •  
  • Ajax.PeriodicalUpdater、
  •  
  • Insertion.Before、

  • Insertion.Top、
  •  
  • Insertion.Bottom、
  •  
  • Insertion.After、

  • Element.ClassNames、
  • var Selector、
  •  
  • Form.Element.Observer、

  • Form.Observer、
  •  
  • Form.Element.EventObserver、
  •  
  • Form.EventObserver

これらの16個のオブジェクトが何故Classとして定義されなければならないのか、他のオブジェクトとどのような差異をもたせたいためにClassとして定義されたのか、それが分からないのです。

オブジェクト指向で、敢えて問題を複雑にするメリットは何?

var myObj = {};

たったこれだけでObjectは生成出来てしまうのに、どうしてClass定義が必要なのでしょうか?

あるいはコンストラクタ関数を

var myObj = function (a, b){this.a=a; this.b=b;}

または、

function myObj(a,b){this.a=a; this.b=b;}

のように定義すれば、これでObjectの初期化が可能なのに、どうしてClassを定義する必要があるのでしょう?

以上の極めて初期的な疑問をまず解決したいと考えています。

最初のボタンを掛け違えてしまうと、prototype.js の理解は決して深まらないでしょうし、今までのJavascriptコード利用がそうであったように、取りあえず動けばよい、とばかりに半可通のままでそれを使いたくないからです。

Javascript2 ではClassが導入されるらしい

待望されているJavascript2がいつ登場し、例えばFireFoxに搭載されるのか知らないのですが、近々登場するであろうJavascript2ではClass概念が導入されるようです。そうだとするとClassを使いこなせるようになっておいた方が、後々Javascript利用上の応用度、自由度は間違いなく高まると思われます。

そこでまず、オブジェクト指向なJavascriptについて記述されているWebサイトを探してみました。

上記のサイトを概観しても、Class定義を敢えて行う必要性についてはピンと来ません。Class 定義の必要性が十分理解できないのです。

上記Webサイトの2番において、Class定義のメリットについてさらっと触れられていますが、あっさり過ぎて、敢えてClass定義を利用する意義や重要性の認識は深まりません。

まだまだ道は遠い!

▲ToTop

何と16日のユニーク閲覧者は555!

関連エントリイリスト in this Blog

7月16日のユニーク閲覧者数が何と555!

数日前から閲覧者数が増加していることは把握していました。しかしこれまでの数ヶ月間ずっと200台だったユニーク閲覧者数が突然一昨日あたりから急増し始め、ついに昨日7/16には555人となったのです。

トータルアクセス数では914回と一千の大台に近づいてしまいました。

こんな拙ブログの何がそれ程の閲覧者を獲得しているのか? アクセス解析を見ても決して特定のエントリイに集中してアクセスされている訳ではないのです。

7月の約2週間の検索ワードを調べてみると、相変わらず「Yahoo解約」関連検索結果としての閲覧がダントツで多く、これにDRM解除が続いています。今盛んにエントリイしているJavascript関連の検索語による訪問は決して多くはありません。最も多いoffsetParentで検索して閲覧してくれた方でも、7月中のユニーク訪問者数累計=4,164人(参考:6月-6015人、5月-5199人、4/22~30で1147人)の内、わずか26人に過ぎません。

つまり今集中して書いているJavascript関連のエントリイが注目を浴びている訳ではなく、以前に書いたいくつかの話題が関心を集めているようです。

ちょっと残念ですが,それでも沢山の方々に閲覧されていると言う事実は、大変嬉しいことです。

そして大いに励みになることでもあります。引き続き頑張りたい、との決意を新たにしている今日この頃です。

閲覧者の皆さん、ありがとうございます。

prototype 学習、否オブジェクト指向Javascriptコードの学習を何から始めるか?

Ajax Libraryを概観し、いくつかの書籍を読みました

そこで思い付き、到達した学習方法をまとめておきたいと思います。

何度も書いているとおり、Libraryをそのままincludeして利活用する方法はとりたくないのです。そうすれば少なくとも Libraryの利用方法は分かるでしょうし、それだけでも一定の価値と意味はあります。しかし、それではJavascript本体のObject指向的なコード記述方法、つまりJavascriptそのものを十分には理解し得ないと思うのです。

愚劣ではあっても、丁度鉛筆でなぞる奥の細道のように、たとえ一字一句転写することになったとしても、オブジェクト指向的なJavascriptコードを自分で納得して書いてみるべきだと考えるのです。

まず Event Object の拡張を行ってみたい

イベントObjectは、Javascript本体に装備されているObjectの中でも大変分かりにくいものです。おそらく、今でも私は十分にそれを理解仕切れてはいません。

だからこそ、Event Object(以下EO)への理解をきちんとしたものにするためにも、EOの拡張にチャレンジしてみる必要があるし、もしかしたらprototype.jsで実装されているEOを更に拡張することが出来るかもしれません。

prototype.jsにおけるEvent Objectの更なる拡張について
例えば、prototype.jsにおけるEOの拡張は、まだ勧告に至っていないW3CのDOM Level 3で規定されるはずのキーボードイベント監視や、イベント発生元要素の取得、左クリックされたか否か、マウス位置取得、デフォルトアクションの停止、リスナーの停止、Listenされているかいないか、リスナー履歴(Cache)取得などです。

ここで欠落しているのはイベント発生先要素の取得、及び当該イベントのリスナーが設定されている要素の取得などです。

▲ToTop

次には訪問履歴(どのサイトから来てくれたのか)の取得です

アクセス解析を一々見なくても、document.referrerプロパティを活用して、訪問前サイトのリストを作成してみたい。単に今のこのブログに装備されていないから、オブジェクト指向Javascriptの練習台とし、取り組んでみたいというのが動機ですが、リファラー履歴をエントリイに取り込むということは、当該エントリイが表示される際に取得できるdocument.referrerの値を累積していくことであり、同じサイトから来てくれた場合のリストアップをどうするか、自サイト内のindex頁からの訪問も取得するのか、不定期に閲覧されるその都度、取得されるreferrer値をどのようにして累積するか、等の問題があり、結構挑戦し甲斐のある課題なのではないか、と考えています。まだ分からないこともありますが、チャレンジしてみようと思います。

幸いなことに、最近はユニーク訪問者数が200カウント台から300、日によっては400オーバーに乗ることもありますが、どんなルートから訪問してくれたのか、知っておくことは意義があると思うのです。

また、その情報が訪問者にも見えることにも意義があるはずです。リファラーはある意味で重要な関連情報ですから。

このリファラー履歴を各エントリイの末尾に掲載出来たらいいな、と考えた訳です。もしかしたらFC2のプラグインツールで既にあるかも知れないが、敢えて自前で作ってみようと思います。

Javascript prototype DOM──最近読んだ書籍リスト

関連エントリイリスト in this Blog

経緯

これまでの1年間以上は『Javascript第3版』と『Javascript & DHTMLクックブック』(共にO'Reilly社刊)の2冊を、Javascript学習上のいわば Bibleとして利・活用してきました。

本の表紙写真。本の表紙

しかし、prototypeの学習を始めた結果、これらの書籍の価値そのものへの絶大な信頼は低下することはないものの、それらの内容が今日ではないことに改めて気がついたのです。

前書は200年12月に日本語版初版がだされたままで、手元にあるのも初版ですし、後書も今から3年以上前の2004年1月に日本語版初版が刊行されています。共に翻訳書ですから原書はもっと早い時期に刊行されている訳で、「秒進分歩」のIT界においては、共に大昔の書籍と言わざるを得ません。

しかも、今を時めくAjaxは、これらの書籍が刊行された後に一世を風靡し始めました。Ajaxは2005年2月18日にJesse James Garrettにより名付けられたものですし、数あるLibraryの中で最も利用され、かつ先駆けとなったprototype.jsが登場したのも2005年でした。

むしろ強調すべきことは、これらの名著2冊の内容が今日的でないことに、今更気がつくこと自体が問題なのでしょう。つまり、私の「時代」へのキャッチアップが余りに遅れていた、と言わざるを得ません。

この度購入した4冊の書籍

上記2冊のBibleに埋没している状況から、今日的水準にキャッチアップしようとしている今、どうしてもネット検索から得られる情報だけでは不十分で、整理された一定のまとまった情報がどうしても必要です。つまり書籍が必要です。

そこで何冊かの本を急遽購入して乱読してみました。ここではそれらの書籍リストをまとめておきます。

  • DOMに関するまとまった書籍は読んだことがなかったので、この際改めて体系的に学習しようと思い立ち、購入しました。期待に違わない内容に満足しています。

  • おそらく何かの雑誌に連載された記事を集約した書籍と思われますが、体系的な学習のためよりも How To 本としての利用が向いていると思います。

  • 掲載ライブラリ数14(勿論prototype.jsもYahoo!UIも取り上げられている。)は圧巻です。こんなことやあんなことが出来る、と言うことを知るには最適ですが、初心者向きではなく理解している人の実用書と言うところでしょう。

  • 左記のリファランスを購入したにも拘わらず購入したのは、単に例題の列挙ではなくその説明があると思ったためでした。しかし、ほんの障りだけの内容でちょっとがっかりしています。

なお、これらの書籍を購入するに当たり、Amazon.comの「中身検索」が大変役立ちました。ネット内で立ち読みが出来るようになったのは大歓迎です。Googleによる「立ち読み」も、著作権問題を孕みながら、つい最近日本語版が利用できるようになったようですが、立ち読みできる書籍がまだまだ限定されているのが残念です。(立ち読み可能書籍数は今後急速に拡大するでしょうけど・・・)

prototype.jsを概観して思ったこと

今までのJavascriptへの取組み方を変えるべきだ!

ブログ作成上で遭遇した個々の課題に対応して、あちこちのサイトを調べながら独自にコードを書いていく───この3年弱の私のJavascript学習は、こうして遅々たる歩みを歩んできました。

しかし、Ajaxライブラリイズをざっと概観し、2冊の書籍を購入し、prototype.jsに関するいくつかのサイトを探訪して気がついたのです。それらのJavascript Librariesは、悉く包括的で、汎用的なコード体系で構成されており、これまでの私のJavascript学習方法のままではいけない、と。そして、もっと先端的情報に接し、かつそれをキャッチアッップしつつ、自己の糧とし、同時に活用するようにしなければならない、と思い始めたのです。

これまでの私のJavascript学習は、いわば「時代に数年遅れて」歩んでいたのでした。

しかし、様々なlibrariesを利用するだけでは、真にマスターすることは出来ない

必要なLibraryをIncludeして、如何に活用するか───それを考えることも楽しいと思う。しかし、それではJavascriptの神髄を理解することにはならないし、それはJavascriptそのものを理解する最善の道でもないだろう、と思います。

だからといって、折角ある素晴らしいLibraryを活用しないのも、おそらくは愚行だと思われます。

そこで、例えばあるLibraryをIncludeして利用しつつ、独自にprototypeオブジェクトを作成していったらどうだろう、と思い始めました。

利活用すると同時にオリジナルのprototypeコードも書く。あるいは比較的小さなLibraryを「分析解剖」しながら、prototypeの深奥を深めていく。こんな方法で学習を進めようかと考え始めているのです。

prototype.js 学習Memo : 関連ウェブサイトリスト

関連サイトリスト(2007/7/15-)

prototypeの学習方法を改める!

作業のパースペクティブ───学習方法の改訂

つい数日前迄は次のように考えていました。

───絶対配置div要素objectを用意し、それを自在にコントロールするコードを書くことを目的として、そのprototype Objectに次々とメソッドやプロパティを追加する。それを他者のライブラリを転用するのではなくゼロから独自に行う───。

しかし、それは全く無謀な学習方法であることを直ぐに悟らされました。歯が立たないのです。prototype Objectは簡単に胸襟を開いてくれるほど、単純でも底の浅いものでもありませんでした。

もっとも、それはprototype Objectの概念や利用方法が難解だからではなく、まだまだ私がJavascriptの半可通であることに由来しているのですが...。

次に、もうすぐ第5版が刊行されるらしい『Javascript第3版』に掲載されている、DynElをベースとして学習を進めようとしたことも、大きな過ちでした。何故ならば、それは対象とするbrowserが余りに古すぎたのです。NN4とIE4ですから。それらは今や"太古の"遺物でしかありません。

そして第三に、何よりも致命的だったのは、今をときめく各種のAjax libraryこそ、学習素材として最高であることに、もっと早く気がつくべきでした。

どのライブラリを学習素材にするか?

07/1/23 午前9時現在、"Open Space"によれば、次の19種類のライブラリが知られているようです。

Ajax library 一覧

Behaviour、bytefx、glayer.js、GreyBox、Highslide、JKL、jQuery、Lightbox、LITBox、MiniAjax、moo.fx、prototype.js、PrototypeWindowClass、reflection、Rico、script.aculo.us、SimpleJS、ThickBox、YahooUI

※ 上記リストは Ajax (JavaScript) Library Reference (Ajaxライブラリリファレンス) から入手しました。

このリスト外にも・・・

dojo.js,wrapScroll等々多数あるようですが、現時点ではそれ以上知りません。

さて、これらのライブラリの中からどれを学習素材として選択するのか、それが問題です。まさか全部に目を通すことは出来ないし、また不必要でしょう。そこでそれぞれの機能を概観した上で、総合性や関連サイトの多さからprototype.jsを選択することにしました。YUIも魅力的ですが、prototype.jsの歴史的意義に敬意を表したいと思います。

株式会社ガイアックスの 天野 仁史 氏は次のように書いてます。([ThinkIT] 第1回:Prototype.jsを使う準備など。)

  • 現在のJavaScriptの発展はPrototype.jsがあってこそだ、と言っても過言ではない・・。
  • Prototype.jsは、JavaScriptの最高のツールであり、最高の教材でもあるのです。あなたも、Prototype.jsを「使い」Prototype.jsを「読む」ことによってJavaScriptハッカーになりませんか?(2007/3/14)

ライブラリを使いこなすことよりも、その学習を通じてJavascriptへの理解を深めたい

各種ライブラリを使いこなす術に関するサイトは沢山存在しているようです。だからそれらを利用して、目的を達するための使い方をマスターすればよい、との利用方法もあるでしょう。

しかしそれではJavascriptへの理解は十分に深まらないでしょう。理解し納得してから、必要ならばライブラリを利用する───そんな風に学習を重ねたいと思っています。

とはいえ、挫折してしまって「何よりもまず使うことが先決」との結論に頓挫しない保証はありませんが・・・(^_^;)

prototype Test(我流失敗作)─── 要素を移動する

このエントリイはprototype Object コードを書いて取りあえず何かできないか、私でも可能なことはないか、との思いから書いたものです。

このため、不十分な点が多々あり、今では、愚劣にもいきなり我流でprototype Objectのコードを書き、それを公開してしまったことを「後悔」しています。

それでも1つの愚かしい記念として意味があるので、このままにしておこう、と思います。(苦笑)

 

閲覧された方には、大変ご迷惑をお掛けしました。

9日未明に、templates(HTML内)に気づかぬうちにたった一箇所のミスを行ってしまった(一箇所だけ"が多かった)まま、確認しないで就寝してしまい、10日未明に再び開いたところtop頁が開けないので、吃驚して調査しました。

その結果上記のことが判明し修正した次第です。

9日に閲覧してくださった方々には、大変ご迷惑をお掛けしました。

深くお詫びします。

次なる課題はprototypeである

prototypeこそ合理的なJavascriptコードを記述するキーワード

ではないか、と最近思えてきた。

少なくとも、各種のネット上から得られる有名なコード(群)においては、それらの殆どがprototype Objectを利用している。TigraMenu、YUI、Tween等々、総合的なコードには悉くprototype Objectが使われている。だからこそ、それらを理解し使いこなすためにはprototypeについて熟知する必要がある。

しかし・・・。その概念はプログラムの素人には難しく、これまで何度かチャレンジしようとしたが、歯が立たなかった。

この間、今年に入ってからの約半年の間、特に体調が悪化したこの春以来、コード作成くらいしか休日に出来ることがなくなったので、Javascriptへの理解がかつてよりも深まってきた。

そして色々とコードを書き、修正し、Javascript解説本(といってもO'Reilly社刊本だけだが)を読み漁る中で、全く歯が立たない状態だったかつての状態から、ぼんやりとしていた霧が晴れ、先が見通せるようになり、ついにprototypeについて、一通り理解する段階にまでステップアップすることが出来た。

問題はその活用にある

しかし理解できたことと利用できることとでは、おそらくは天地の開きがある。

コンストラクター、インスタンス、プロトタイプ、クラス、クラス変数、クラスメソッド等々、理解出来たものの、それらを利用してみなければ、理解の程さえ図ることが出来ないだろう。

ということで、このブログ上でprototype学習過程を綴ってみようか、と思っている。

確かに、素人の愚昧なチャレンジを敢えて綴ることに、おそらく社会的意味はない。つまりは自己満足であり、自己陶酔に他ならないが、それでも敢えてそうしようと思う。

何故ならば、そうすること(自己の対象化、客観化)こそが、真の理解への賢明な道の一つだからである。

browser毎に異なるwindow.innerWidthについて

FireFoxやOperaとIEとではwindow.innerWidthの定義が異なる

主としてSleipnir2でブラウジングしているので、今までそのことに気がつかなかった。

偶々、 Cross-Browser.com - xClientWidth サイトでFFの場合のwindow.innerHeightに関する修正行(if(document.height>window.innerHeight) window.innerWidth -= 16;)をみて、初めてそのことを知った次第である。

その差異とは、IEはスクロールバーを含まない内寸を与えるが、FFとOperaはスクロールバーを含む値としてwindow.innerWidthが定義されているということである。

早速我がscriptにCross-Browser.comの方法を取り入れたことは言うまでもないが、Operaの場合にはFFの方法が使えない、ということを本日発見した。具体的にはOperaにはdocument.heightが定義されていない、否正確に言えば、(FFではそれが可能であるが)宣言されていないdocument.height値を取得することが出来ないのだ。

そこで document.heightの変わりにdocument.body.offsetHeightを使うことで問題に対処した。

また、Operaのスクロールバーは幅が18pxある。最終的には次の式でwindow.innerWidth値を修正した。

if(document.body.offsetHeight>window.innerHeight)window.innerWidth-=18;

マウスイベント座標などの各種座標テスト

このエントリイは2006年12月19日に投稿し、2007年7月8日及び同年9月15日に加筆改訂したものです。改訂内容は文字色を変えて示します。

エントリイ内JavascriptExercise

1-4 マウスイベント発生位置情報の取得

何らかのマウスイベントに対応して、或る位置に或るボックスコンテンツを表示したい需要はかなり高い。その場合には当然、その表示位置、サイズなどを指定する必要がある。かくしてイベント発生位置、表示コンテンツの幅と高さ、ボーダー、パディング、文字と背景の色等の属性をまとめてJavascriptで設定してみることにする。

そこでまずイベント発生位置、windowサイズ、screenサイズを示す各種プロパティ値を取得し、このエントリイ内に表示してみる。

なお、これらの情報と表示するボックスコンテンツを任意の指定する位置にfloat表示してみたい。但し、このことはまだ実現していない。当面、位置情報はエントリイ表示内の所定の位置に固定表示される。

その後9月15日にドラグ&ドロップ可能とした。

マウスイベント発生位置情報

Windows内の任意の位置でマウスを動かす(onmousemove)と、下表内に当該マウスイベント発生に係る各種位置情報が表示されるようにした。

また、位置情報がonmousemoveイベントによって変化した場合には、当該セルの背景色を瞬時に淡いピンクに変更するようにjavascriptで設定し、マウスの動きによって何が変わったのかが分かるようにした。

使い方は簡単だ。(以後文字色が変わっている箇所は2007/07/08に加筆した箇所を示す)

IEの場合には、この下のマウス位置監視開始をクリックするとmouseの動きを関知してイベントハンドラー関数が起動し、その他のbrowserの場合には何もしなくてもmouseを動かすと。body上のどの部分で発生したonmousemoveイベントであっても、そのイベント発生位置をJavascriptで常時監視しており、その取得値をリアルタイムで表内に表示する。IEの場合のみ、監視を止めたければ、先ほどのボタンがマウス位置監視停止に変わっているのでこれをクリックすればよい。


このボックスはドラッグ&ドロップで移動可能です
諸元
クライアントX座標
クライアントY座標
スクリーンX座標
スクリーンY座標
スクロールX量
スクロールY量
page上のX絶対座標
page上のY絶対座標
Window Inner幅
Window Inner高さ
Window Outer幅
Window Outer高さ
スクリーン有効幅
スクリーン有効高さ
スクリーン上の有効X値
スクリーン上の有効Y値

コメント

  1. IE7標準モード、FF標準モード、Operaで確認済み。その他では動作を未確認であり、Safariなどでの表示は保障出来ません。

  2. cancelBubble がうまくコントロールできないため、昨日(2006/12/21)迄はこのエントリイを単独またはこれを含む月別・検索結果として複数エントリイ表示した場合には、onmouseover時のPopup表示が予定している位置に表示出来ないでいた。Popup表示もまたこのエントリイのマウスイベント座標取得と同様に、onmousemoveイベントよって駆動しているが、どうやっても、onmousemoveイベントがこのエントリイからmyblogブログ全体に伝搬しないのだ。

    しかし、22日未明に、このエントリイ内のイベントハンドラー関数内に、Popup表示のための位置取得関数を外部Javascript文から、複写して記述してscriptを起動させることにより解決した。

  3. 外部script内に document.onmousemove=func; が設定されており、常時マウスの動きを監視するようにしてある。その上でこのエントリイで document.onmousemove=dispPos; を設定してしまうと、後からセットされたこちらの設定により前のイベントハンドラーが否定されてしまう。そこでこのエントリイでは document.body.onmousemove=dispPos; とすることにより問題を解決した。

IEとその他のbrowserで操作方法を変えた理由は以下の通りである。

月別表示や検索結果表示の際、このエントリイに記述したonmousemoveイベントがその他の同時に表示されるエントリイ上にも波及してしまう。伝搬を阻止しようとしてみたが出来なかった。

この結果、それらの複数エントリイ表示モードの場合読み込みに莫大な時間が掛かってしまい、使い物にならないことが本日判明したので、対策を講じる必要に迫られた。

しかし、IEでは成功したもののその他のbrowser(テストしたのはFFとOpera)ではIEと同じようにonmousemoveイベントの監視開始指示を与えると、documentがリロードされ初期化されてしまうため、目的とする監視状態に入れなかった。Ajaxを活用すれば可能なのかも知れないが、今はその知恵がない。

このため思い通り動いてくれるIEにおいては監視開始・停止ボタンを設け、IE以外ではそれらをやめ従来どおりいきなり監視を行うモードのままとした。(Javascriptでユーザーエイジェント情報を取得し、場合分けした)

以上の結果、IE以外では何ら改訂されず集合表示モードの時には、引き続き読み込み完了に膨大な費やしてしまう迷惑を掛けることになる。今回、こうした中途半端な改訂となったのは忸怩たる思いであるが、今の私の知識ではどうしようもない。

頁読み込み完了フラグを設置

その必要性は月別表示や検索結果表示モードで発生した

頁全体が読み込まれないと、否正確に言えば「popup表示用の要素がdocument内に存在し、かつその読み込みが完了しないと」popupイベントはエラーとなってしまう。そして先に書いたようにグループ表示モードの時のid重複を避けるため、popup表示用要素はHTML内に配置せず、Javascriptによって追加(append)する方法に切り替えた。

その結果ページの読み込みが完了しない限りpopup表示用の要素はページ内に存在せず、従ってpopup設定箇所にマウスオーバーした場合にはエラーが出てしまう。

つまり、頁完了まではpopupイベントを発生させないようにしなければ、利用者に迷惑を掛けてしまう。エラーが発生しないようユーザビリティを向上させるべきだ。

こうしてエラー対処を講じることとなった。

body部のonloadイベントハンドラー内にpopup関数を書き込む方法もあるが、それではonloadイベントが多数になりすぎる。そこで頁読み込み完了を示すフラグを立てる方法を採用することにした。

その方法は一般的なのかどうか分からないが、簡潔で気に入った

採用した方法は『Javascript第3版』(David Flanagan著)p.233に記載されている方法だ。onloadイベントハンドラ内に「window.loaded = true;」なるフラグを設定し、複数存在しているpopup関数の冒頭にこのフラグの真偽を確認する文を挿入して、window.loaded ==falseだったらreturnしてしまい、popup表示関数を停止してしまうのだ。

これによりpopupに係るエラーは出なくなった。

なお、この方法の素晴らしさはその汎用性にある。つまり、読み込み完了前に呼び出される可能性のある関数の全てにおいて、その1行目でflag値の真偽をチェックさせるようにすれば、関数内変数等の未定義エラーを避けることが出来るからである。

Ajaxなり、event.js(doxdesk.com: software: event.js)を使う選択肢もある

しかしそれらの方法は、今の私のJavascriptに関する知識では理解を超えるので、今回は原始的方法に拠らざるを得なかった。

popup要素をJavascriptで挿入、HTMLからは削除

それは複数エントリイ表示において支障が出たことから始まった。

月別表示、検索結果表示など複数のエントリイを1のページに表示することはよくあることだ。

ここにおいてHTMLテンプレート内でpopup用のdiv要素を設置してある場合(例えば、<div id="balloon"></div>のように設置した場合)、当該ページ内に同一名のidを持つdiv要素が表示されたエントリイ数だけ複数出来てしまう。この結果idの競合が起こってしまい、popup表示が思うようにいかない場合が発生したのである。

そこで・・・前から思っていたことなのだが・・・、Javascriptで挿入するようにすれば、複数エントリイ表示の場合でも、popup用の要素は1つしか存在しないように出来るので、その方法に変更することとした。

要素の挿入はDOMの一般的な方法であるappendChildを使ったが、今後のためにもエントリイ内に記録しておきたい。なお、balloonAppend関数はbody部onloadイベントハンドラー関数として埋め込んで起動している。

popupをフェードイン表示に(不透明度変化を導入)

それは透明化・不透明化関数の練習のためでもあった

透明化・不透明化はこのブログを設立した頃にはまだ、IEでしか出来ない状況だった。あるいはIE以外のbrowserにおけるその実現方法が分からなかった。

しかし、今回別件(要素の高さ取得)で要素の透明化の必要に迫られて調べてみたところ、IEだけではなくMozilla系、safari、Operaでもそれが可能であることを知った。(これはこれまでも何度も触れてきたWebサイト:youmos - 新しいWebビジネスや技術アイデアを活性化するWebマガジンのお陰である。ほぼ毎日新しいJavascript素材や海外の貴重なサイトの紹介が更新されているが、改めて深甚の感謝を献げたい。)

この結果望んでいた透明化・不透明化コードを書くことが出来たのだが、 Smooth Scroll を実現した今、改めて「ソフトなWeb表示の変化」に興味を抱いた。

一方、アメリカを熱狂させたらしい iPhone の紹介動画をいくつか見て、Apple社がそれで実現しているSmooth Scrollやソフトな表示の変化に、改めて強い関心を抱いた。

かくして、随所に設置しているmouseover時に表示されるpopupについて、それを表示する際に透明化から不透明化への変化を持たせたい、と思い始めた。

既にこのサイト上でそれを実現しているので、随所で表示されるポップアップが「ほゎ~っ」と表示されることはここで触れるまでもないだろう。

▲ToTop

ここでは、実現に当たっての苦労談を綴っておきたい

要素の透明化・不透明化について(検索キーワードは"Javascript opacity")検索すると沢山のサイトがヒットする。日本語サイトだけでも約50万件(2007/07/07_0100am時点)がリストアップされる。

そのヒットリストの上位5Webを覗いてみると先ほど触れたyoumosもあるし、数年前にも見かけた内容が、画像のフェードイン・フェードアウト - e-Webに収録されている。All AboutのYUIモーションopacity,Easing... - [JavaScript]All Aboutは、流行のAjaxを使った例として興味深い。

透明化・不透明化はsetTimeout関数を使用することになるが、その例を色々さがしてみても、殆どが setTimeout("function()",msec) のようにfunctionに引数を取っていない。その場合functionの対象要素や必要な引数は皆global変数として定義し、function()の外で値を設定する方法をとっている。しかしこの方法は一つや二つの要素を対象として利用する場合には支障がないが、沢山の要素を対象としてsetTimeout関数を使おうとする場合、引数として対象オブジェクトや透明度の数値をセットしたくなるのだ。何故ならばそうした方が汎用的な関数として利用しやすいからである。

名著『Javascript & DHTMLクックブック』(著者Danny Goodman)には、setTimeout内の関数に引数がある場合のコードの綴り方が書いてあるが(p.95)、何故そうするのか説明がなく応用を利かせることが難しい。

ところで、e-Webの方法はIE限定であるが、youmosで紹介されているスクリプトを使えば、FF、Opera、safariに拡張できるものであり、貴重な点はsetTimeout関数内に引数を取っている点である。その方法を採用すればおそらく巧く動くだろうと思う。但し、name属性はXHTMLでは非推奨なのでidを活用することになるだろう。しかし、よく考えれば透明化・不透明化のsetTimeout関数内で、getElementByIdで対象を取得するのは無駄に時間を要すると思う。だからこそ、最善の方法はAjaxを勉強してマスターする道もあるか、とまで考えたが、当面その時間が取れそうもない。かくして、id属性を活用するe-webの方法は採用せず、setTimeout関数内の関数に引数を取らない方法で透明化・不透明化を行った。

YUI(Yahoo! User Interface Library)を分析してみたが、理解には時間が掛かりそうだ

その上で、Ajaxマスターへと進むのがこの際の最善の道ではないかと思い、yuiをダウンロードしその内容を調査してみた。しかし、それらは余りに沢山のコードからなっており、内容を理解して使いこなすには膨大な時間が掛かりそうだ。YUIの内容を理解しないまま使えるだけ使う道もあるが、そのようなことはしたくない。

だからといって、たかが透明化・不透明化を行うために全てのYUIを理解するには、その内容はかなり膨大で難解である。

しかし、透明化・不透明化については、id指定した要素をsetTimeout関数を使って操作する点は変わらず、膨大な内容を理解してから使うほどのことはない、と言うのが結論である。

▲ToTop

iPhone熱狂 in America. そして日本では?

まずは、本家本元のサイトで iPhone の概要を

Apple - iPhoneに、大特集が組まれている。写真やtour videoも満載で、同社の意気込みと「爆発的」売れ行きぶりを反映していると言えるかも知れない。


それにしてもiPhone heroとは自画自賛も極まれり!

同社サイトの動画を見ればその全貌をツアーで見ることが出来る。キーボードレスでタッチパネル形式で全機能を使用できるそれは、まさしく革命的であり、ユーザーの待望ぶりも頷ける。

▲ToTop

iPhone「ついに」発売!───2007/6/29。Apple社発のスマートフォンはiMac、iPodに次ぐ第三のビッグビジネスたり得るのか

と言ってもそれはアメリカでの話。その熱狂ぶりはWindows95発売時を思い出させる。

報道に曰く

  • 「ほかの携帯はクズだ。いくつかの携帯を使ってきたが、高いやつでもだめ。こいつは違う」とシカゴ在住のアルバート・リビングストン氏(62)。「これは最新のオモチャで、私は62。オモチャを買うための時間はあまり残されてないんだよ」
  • サンフランシスコのアップルストアで発売初日にiPhoneを手に入れた女性は、「今まで手に入れたなかで一番クールな機器。全体的にすごい。残念な点もなくはないけど、電源を入れた瞬間から満足しているわ」と興奮気味。
  • 「Appleは、実にエレガントなハードウェアとソフトウェアの統合を行う能力を活用し、その領域を広げようとしている」と市場調査会社Gartnerのアナリスト、マーク・マクガイア氏。「iPhoneはAppleにとって、次のビッグビジネスだ」
  • Appleの株価は1.2%上がり、122ドル4セントとなった。ジョブズ氏が1月にiPhoneを発表してから30%以上も値を上げたことになる。AT&Tの株価は1.9%上がって41ドル50セント。
  • 多くのアナリストは、iPhoneが大人気になれば、来年にはApple株価がさらに30%上乗せされると予測している。ただし、現在の株価は高い期待値を織り込み済みだと警告する向きもある。
  • 今年、米国ユーザーはインターネットでiPhoneに関する情報を求めて、約686万の検索を行ったという。調査会社の米comScoreが6月29日に発表したiPhoneに関する検索動向データによる。
  • 「私も列に並んで買うつもりだ」と言うのは、ブロードバンド普及促進団体 Internet Innovation Alliance (IIA) の創設者で共同会長の Larry Irving 氏だ。「勢力図を一変させる iPhone の登場に、業界は対応せざるをえなくなるだろう。Apple が言うように、本格的な Web を携帯電話で体験できることは、非常に大きな魅力だ」と、Irving 氏は取材に対して語った。
  • 「iPhoneは電話、Webブラウザ、メディアプレーヤーを融合したもの。テクノロジーの権威はこの製品を「ブレイクスルー」デバイスとして称賛するが、キーボードの代わりになめらかなタッチスクリーンでの操作が必要で、低速なインターネット接続に消費者は苦労するかもしれないとの疑問も持っている。」(~ ITmedia News:iPhone、ついに販売開始――購入者、アナリストの声
  • 「また時代が変わる、次の時代がきちゃった、ということ。今後は携帯もPCも、これが中心。アップルがまた新たな基準を作ってしまった」 「IBMがコンピューターをつくり、アップルがパソコンをつくった、あの時以来の興奮だと思う。つまり、マウスとかアイコンが誕生して以来のインターフェースの革命とも言えます」 吉川欣也(よしなり)さん(39)asahi.com:iPhoneの実力はいかに。シリコンバレーでコミミ記者が試してみた - コミミ口コミ

▲ToTop

確かに・・・

マウスを登場させ、iPod で世界を席巻したApple社ならではの素晴らしいInterfaceだ。まるで本をめくるように指先で画面をタッチして全てを操作できること自体、画期的だ。パーソナルユースのタッチパネル情報端末が、電話であり、動画を見ることが出来、e-mailも使えてWWWブラウズ迄出来、ポケットに入るサイズというのだから、上のユーザーの"過激"とさえ思われる反応も頷ける。発表から半年、強烈に待望された感激の製品だろう。

マニュアルレスで使いこなせてしまうのではないか、と思わせるほどの直感的操作体系だし、本体を90度回転させると自動的に静止画も動画も回転してくれるなんて、余りにできすぎていると思えるほどだ。

これぞ待ちに待った携帯電話、否携帯端末であり、SONYのwalkmanがかつてそうしたように、おそらく世界の携帯市場を席巻するだろう。

日本ではいつ?

アジアでは2008年に登場か? しかし、固有の閉じた携帯電話体系(欧米と日本では携帯電話との通信の方式や課金システムが異なる)が発達してしまったこの日本では、2008年中にも発売されないかも知れない。iPhone 文化においては最後発の世界の孤児になってしまうのかも知れない。あるいは固有の携帯文化が崩壊する程の衝撃として登場するなんてこともあり得るのか?──否、それはないだろう。となれば固有の携帯電話との併存という、ダブルスタンダードを強いられるのだろうか?

しかし理想的な携帯端末が登場してしまった今、またしても日本企業の追いつき狂騒が始まるだろうし、Word/Excelを今後購入しないと言い切った国策の行方と相まって、ここ1,2年はIT文化に大きな変動があるかもしれない。

▲ToTop

国がWord/Excelの新規購入を行わない、と決定───本気か?!

まずは驚きのそのニュースから

中央省庁で使う文書作成などのコンピューターソフトについて、国は、特定の製品ばかり購入するのは公平性に欠け公共機関として認められないとして、1日から、マイクロソフト社の「ワード」など標準的な規格と互換性のないソフトを原則として新たに購入しないことになりました。

コンピューターソフトは、メーカーが異なると文書やデータを十分に読み込めないいわゆる互換性のない製品が少なくありません。このため同じソフトを買い続けることになりますが、国は、こうした購入のしかたは公平性に欠け公共機関として認められないなどとして指針を作り、1日から運用が始まりました。指針では、新たに購入するソフトはISOなどの国際的な規格や国内のJIS規格に基づいた製品を優先するとしています。最も広く使われているマイクロソフト社の文書や表計算のソフト「ワード」や「エクセル」は、現段階ではこうした規格に沿っていないため、業務に支障がある場合などを除き原則として今後購入できなくなります。マイクロソフト社は、ワードやエクセルについても国際規格として認めるよう引き続き働きかけたいとしています。(NHKWebサイトより引用)

なおGoogle Newsを見たが、トップ頁にも検索を掛けても、NHK以外のニュースソースは見あたらなかった。(7/1 23:45現在)

さて、ガセネタとは思えないから、おそらく真実だろう。しかしそれは遅きに失したと言えないだろうか?既に沖縄のある自治体では、財政事情もあってWord/Excelの購入と使用を禁止しているそうだが、その自治体担当者が「これまで国から「Word /Excel で資料を提出せよ」と指示されてきたので対応に苦慮してきた」との談話が報じられた。(1日午後8時45分からのニュース報道)

既に、Windows2000が出た頃からだろうか、MS-Officeをpre-installしたPCが市場を席巻し、その結果国産ソフト一太郎は急速にシェアを奪取されてきたことは周知の事実だ。pre-install自体に対して何ら規制することなく、また問題があることを主張することもなく、大半の自治体と民間企業でMS-Officeの独占状態が一般化してしまった今になって、今更何を言っているのか!───との思いがまず湧いてきたのは当然のことだ。そして誰しも、「今更何を!?」と訝るのではないだろうか。

MS-Office互換無料ソフト(Open.Org)が改良を重ねられ、かなり使い物になってきたとはいえ、独占状態を問題にするならば、何故今なのか?、「公平性に欠け公共機関として認められない」状態は今日までなかったとでも言うのだろうか?! 規制時期を根本的に疑問に思う。

今後もこれまでの状態が続き、独占が更に加速されることは間違いないから、いつでも遅くはない、とでも言うつもりだろうか?

▲ToTop

Windows95発売から10数年───これまで国は何らかの独占・寡占対策を講じてきたのか?! OS・アプリケーションに対する国策はあったのか?

その筋の情報に決して詳しい訳ではないから断言は出来ないが、この10数年間アメリカにおいてはMicroSoft社の横暴に対して複数の裁判闘争が行われたことを聞いているが、この日本では事実上野放しだったのではないだろうか? 国産のOS(BTRON)も結局見捨てられたし、10年前においては唯一奮闘していると言えた国産ソフト一太郎も、「市場原理」のままに放置されたではないか。(別に一太郎が良い、と言うのでは全くない。OSやアプリケーションに対する国策の有り様が問題なのだ。)

対米追随外交の中で、CPU、OS、アプリケーションの全てでアメリカの独占に対する対抗策を放棄しておいて、今更・・・?!、と思う。

食糧自給率について、欧米諸国ではそれぞれに自給率を高め、維持するべく国策として農業保護施策を講じているのに、日本ではこの自給率も市場原理が優先されて他国の為すがままに低下させてきた。

よく言われる理念なき外交、外交無策が日本外交の大きな特徴だが、マイクロソフト社と米国政府が黙っているとは思えないWord/Excel拒絶宣言は、外交上一体どう位置づけるのだろうか?

OpenOffice.Org2.1を使い始めるのか?

今後はWord/Excelを購入しない、ということは、大半がoffice2003以前であろうMS-Officeを使い続けるか、あるいはOpenOffice.Org2.1を使い始めるのか、あるいは国産ソフトに回帰するのか? 今後の対応策・選択肢は報じられていないから、どう考えているのか分からないが、他方で経費削減効果も期待されているようだから、本気で事を進めるつもりならば、旧バージョンのMS-officeを使い続けか、またはOpenOffice.Orgへの斬新的移行を進める可能性が高いと考えられる。(中国では外交政策上Open.Officeの利用を国策としているらしいが、先見の明があった何て、今更言えることではない。)

また、提出するデジタルデータについて、利用アプリケーションを事実上指定してきた国が、今後は自治体や民間企業に対してどうするつもりなのか? この7月1日から新規購入を行わない、とのことなので当面は大きな支障はないだろうが、仮に今回の国の宣言が文字通り数年間実行されるならば(果たして本当に実効性があるのか甚だ疑問に思うが・・・)、Officeソフト市場への影響及びOpen.org界への影響、ひいては社会的影響(自治体や民間企業で利用するOfficeソフトも影響を受けざるを得ない)は共に甚大となるだろう。今回の国の決定は、外交問題にもなりかねない、極めて大きな社会的・国際的影響のある「事件」と言える。

▲ToTop

マイクロソフトは? アメリカは?

まずマイクロソフト社は既に行動に出ているらしい。「国際基準に合致すればよい」のだから、Word/Excelの国際基準化(これは、アメリカ固有の基準を「グローバルスタンダード」の名の下に他国に押しつけ続けているアメリカの戦術に他ならない。因みに今回の国の決定は、皮肉にもグローバルスタンダードによるアメリカへの反撃だから、アメリカの自縄自縛とも言える。)を必至になって謀ろうとするだろう。

そして米国政府もそれを事実上強力にバックアップするだろう。それが自国の利益と考え、かつ自国の利益だけを優先する国だから。

無料ソフトの拡大やネット上で利用できるアプリケーションの伸張が背景にあるだろう。

今回の国の決定の背後には、Linuxの浸透、Open.orgの通奏低音、Googleが先導してきた無料ソフトの拡大、そしてWebアプリケーションの伸び、オンラインOfficeアプリケーションの登場と拡大等があると思われる。つまり、マイクロソフト社の製品に依存しなくても、業務遂行が可能となる「かもしれない」環境が整い始めたことも影響している、と言えるだろう。

ユーザーサイドからの理想を言えば、いつでも、どこからでも無料でアクセスできる、使い物になるオンラインofficeアプリケーションがあれば、高価なofficeソフトを購入する必要はないのだが、そうした環境は何時になったら実現するのか、全く分からない。資本主義経済の中でそうしたことが実現できるのかも分からない。

広告表示が必須の無料ソフトばかりが蔓延っても迷惑千万でもある。

はっきり言えること

今回の国の決定は、どれほどの社会的・国際的影響をもたらすのか全く未知数である。しかしはっきりしていることは、それが爆弾であって、反撃は疑う余地がないこと、他方で、officeソフトの有り様に一石を投じた意義が社会的に広く認識されることがあれば、今回の決定に最低限の意味はあること、この発表が「業務に支障があるから」等として、実行に移されないようなことがあれば、他国からますます外交政策上の蔑視を受けるであろうこと、最後にMS-Officeの国際基準化が図られてしまうかもしれないこと、である。

▲ToTop

Smooth Scroll の導入

それはSONYのHomepageを見て以来、ずっとやりたいことだった。

SONYのWebサイトでは既に数年前にSmooth Scroll(それをそう呼ぶと言うことを知ったのは今日であるが)を実現していた、と記憶している。その方法として window.scrollTo(x,y) メソッドを使っていることは疑いようもなかったが、どの様すれば Smooth Scroll が実現できるのか、それ以来、時々ふと思案したりしていた。(因みにSONYのWebsサイトからjsファイルはダウンロードできるが、Smooth Scrollを実現しているコードは見つけられなかった。)

スクロール済み座標値のその大きさに応じて、加速度的にスクロール速度を減らせば良いのだから、例えば何らかの幾何関数を使うのか、とまず考えた。しかし、それで加速度的にスクロール速度を減速できるだろうか?、否、setTimeoutに設定する時間間隔を加速度的に減らしていけば次第に動きは遅くなるが・・・とも考えた。入浴中にサインカーブを思い浮かべながらどうすれば良いのだろう、と考えたりもした。

そして今晩。

通常配置要素のoffset値取得問題が解決したので、次の課題としてSmooth Scrollを実現しようと意気込み、その方法を探るためにグーグったら、数日前に触れたあの「youmos」サイトがTopにヒットした。ここならば間違いなく欲しいものがあるだろうと期待して覗いてみたところ、期待に違わず、まさしくそこにはあるべき回答が存在した。感謝!youmos! Smooth Scroll して画面の上に戻るJavaScript - youmos

しかし、idを設定した要素に適用するのでは困る・・・

そこをクリックすれば「ページトップに戻る」仕掛けは多くのサイトで採用している。拙サイトでも随所にそれを設けているが、これまではいきなりページトップにジャンプする(window.scrollTo(0,0)メソッドに等しいAタグを用いた)原始的・古典的方法を採用していた。

だから、やっと欲しいものを手にした子供のような心境で、youmosで紹介されていた方法を早速検討したことは言うまでもない。

さて、それはHTML内の必要な要素内にその属性としてonclick="イベントハンドラー関数"を設置するのではなく、script内で全てを処理する手法によって書かれた素晴らしいコードなのだが、致命的だったのはid名を振った要素を対象としてイベントハンドラーを設置する仕様だったことだ。

「ページトップに戻る」機能は一つのページに複数設置することが多い。その全てに固有名とならざるを得ないidを振るのはいかにも面倒だ。願わくば同一の性格を有する(class名を振った)複数の要素に対して一律に必要な仕掛けを設置できることが好ましい。

▲ToTop

そこで固有のclass名を振った特定要素群に対して、ページトップにスクロールするイベントハンドラーを設置することにした

しかし、getElementById(ID)に類する「getElementsByClassName(CLASSNAME)」なるメソッドはDOMには存在しない。だからこそ、目的を達するための関数があれこれと作成されている。特定要素群に対して「ページトップへ戻る」イベントハンドラーを設置するには、まず特定のclass名を付した要素集合を、設定対象として取得できなければならない。Smooth Scroll実現のためには、まず適切な「getElementsByClassName()」関数をゲットしなければならない。

そしてそれもグーグって最適解を見いだした。

それはRobert’s talk内のThe Ultimate getElementsByClassName - Robert’s talkである。

それは「Ultimate」を自称するにふさわしい素晴らしいものだ。何故ならばDocument全体を対象にするだけではなく、対象要素群をページの任意の一部の任意のタグ名に絞り込むことが出来るからである。そのためここ:The Ultimate getElementsByClassName - Robert’s talkでダウンロードできるgetElementsByClassName関数は引数を3つ持つ。ページ内の任意の要素の塊、その中の任意の要素、そしてクラス名である。

このUltimateなgetElementsByClassName関数は、Document全体を走査する同目的の関数が多い中で、秀逸のものと言えるだろう。但し正規表現に係るバグが有るためそのままでは支障を来す場合がある。この点については後述する。

なお、グーグったもう一つの成果としてgetElementsByClassNameがFirefox3から実装されるらしいことが分かった。

Gecko に Web Applications 1.0 の getElementsByClassName メソッドが実装されました (Bug 357450)。Firefox 3 から使用可能になります。document.getElementsByClassName で文書全体から、または element.getElementsByClassName である要素の子孫要素から、特定のクラス名を含む要素を探し出すことができます。───getElementsByClassName on Gecko: Days on the Moon

▲ToTop

次に問題となるのはFc2ブログ固有の問題だ。

Fc2ブログではブロック変数を用いることにより、windowでload時の動作において、表示するContentsに応じて様々な使い分けが出来るため、Javascriptによるwindow.loadは使いにくい、という問題がある。

だからJavascriptコード内でwindow.loadはしないこととした。

また、特定のclass群を頁トップへのSmooth Scroll起動のイベントハンドラー設置対象にするためには、id要素を対象にした場合に較べてコードは複雑にならざるを得ないが、やむを得ず必要な改変を行った。

更に問題としたのはカクカク感の解消である。

オリジナル版のようにタイマーを使った使用にすると、たとえそれが1mm秒の設定であっても、どうしてもタイマー起動時にカクカクと動作することは否めない。そしてこれが気にくわない。もっとスムースにスクロールして欲しいのである。その名もSmooth Scrollなのだから・・・。

そのため、タイマーを使わずにSmooth Scrollを実現する方策を模索した。具体的にはふさわしい関数がないものかと検討を重ねた。

なかなかオリジナルで使われていた比較的単純な関数(y-y/const)より以上に適切なものを見いだせなかった。途中で投げ出して昨日(1日夜)は、結局タイマー仕様に戻してしまった。ところが、カクカク感が解消されない問題はずっと引っかかり続け、7/2にまたタイマーを使わない計算式に戻した。その時使用関数は、何とオリジナルそのものであり、constをあれこれ入れ替えてみて、一定値=80を選択して最終決着とした。

しかしどうも気にくわないので、エクセルで適当に表を作成しその近似曲線を求めて新たな関数を設定することにした。その関数を適用して現在はBackScrollしている。

スクロール速度はパソコンの性能や好みに依存するから、そもそもどのようなスクロールが「Smooth Scroll」と感じられるか、最も心地良いか、決定的に個人に依存するだろう。しかし私はこれが良い。

まだ問題はあった───それはゲットしたgetElementsByClassNameにバグがあったのだ。

class名は一般に複数指定されている場合がある。class="name1 name2"のようにだ。

ゲットしたUltimate getElementsByClassName には、複数名対応を考慮している式があるのだが、残念ながらそれが間違っている。

そのため、そのバグフィックスを考慮しなければならなかった。

なお、どこをどう修正したのかは下記のコード説明で行うことにする。

▲ToTop

任意のclassに適用するSmooth Scrollの完成

こうしてこのエントリイにも実装している頁トップへのSmooth Scrollを実現した(そのコードは以下の通り)。

またテンプレート(HTML及びCSS)においても、「頁トップへのSmooth Scrollイベントハンドラー設置箇所」に対して必要な修正を加えたので、過去にさかのぼって全てのエントリイに対して、Smooth Scrollを設置することが出来た。(こうしたことが出来るのも、テンプレートのテンプレートたる所以であり、ブログテンプレートの大きなメリットだ。)

▲ToTop

 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が開きます。