01 | 2010/02 |  03

  1. 無料サーバー

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

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


スポンサーサイト

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

まだまだ健在の 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




・・・・・

スポンサーサイト

PC Japan がついに休刊・・・廃刊への第一歩か?

2010年3月号をもって休刊だそうだ。

定期購読してきたこの雑誌がついに休刊となる。

そもそも、最近の各号は二番・三番煎じの記事が多く、いい加減ウンザリしていた。だから休刊と知っても驚くには値しない。

私事であるが気に掛るのは 1 年の定期購読を前払いで契約しているので、休刊となった今、残りの号数分に相当する返金がきちんと行われるかどうかである。

休刊であって廃刊ではない...のだろうか?

それにしても、いきなりの廃刊ではなく休刊としたのは様子見なのだろうが、果たして再刊される可能性があるだろうか?

3 月号巻末には次のように記されている───「インターネットの普及とパソコン市場の成熟に伴い、月刊誌としての使命を終えたとの判断に至りました」。

だとすれば休刊は筋が通らない。論理的必然性をもって廃刊すべきではなかろうか?

休刊はスケベ心が見え見えの中途半端な措置でしかない。

jquery.js を利用した Ajax 通信の一例(改訂版コードについて)

コード改訂に至る経緯

約 2 年程前に上記関連リストに掲載したエントリイを投稿しました。

そこではjquery.js の Ajax コードを活用する一例として、今閲覧しているエントリイの直前 10 エントリイ、直後 10 エントリイ及び最新の 10 エントリイの、それぞれのタイトルを Ajax 通信で取得してみました。

その後ずっとそれを使い続けてきたのですが、あることからコードを見直す必要に迫られ、今回改めてコードを全面的に見直し、要所をいくつか改訂しました。

改訂を思い立ったのは、直前/最新/直後エントリイタイトルの表示位置が、ブラウザによっては、どうも思ったように描画されていないことに最近気がついたからです。(セットしてから 2 年も経っているのに今更かい?!(^^;; )

IE と Firefox では意図したとおりになっていたのですが、safari や chrome ではずれていたのです。

そしてその原因は、自作コードにおける offsetParent に対する曖昧な対処方法であろう、と推測できました。

しかし、これだけのことでは 2 年前のコードを改訂する動機として弱すぎました。2 年も経つと自作コードであっても可読性はかなり低下するので、思い出す時間と、当時の到達点まで改めて登る努力が必要となります。

重い腰を上げたのは、先月に解読した jQuery(~).offset メソッドや jQuery(~).position メソッドを、今後様々に活用したいと思ったからです。このブログ内で、これらのメソッドや Animation に関するメソッドを活用して、様々な実験を行いたいと思っているのですが、そのためには HTML 要素の位置が正確に把握できなければなりませんし、CSS の決まり事をしっかり押さえなければなりません。

こうして 「offsetParent の扱いを曖昧にしたままでは適切な実験が行えない」 と判断し、曖昧なコードを改善しなければならなくなったのです。

▲ToTop

今回の作業(コード改訂作業を含む)の苦労談(戒めのためのメモ)

1. offsetParent 問題

今年 1 月迄はこのブログの container 要素 には position 指定を行ってきませんでしたが、今回の一連の改訂作業を通じて container 要素には position:relative を指定しました。(※ このブログの container要素は body 要素直下にあり、ブログタイトルや時計、カレンダーそしてエントリイ等を包含する要素 )

その container の中に Javascript コードによって、10項目ずつの以前 / 以後 / 最新エントリイタイトルを表示する 3 つの要素( 以後「popup要素」と呼ぶ )を絶対配置するのですが、container の親要素及び祖先要素に position 指定をしていない状態では、W3C 勧告に従えば、popup 要素の offsetParent は body となります。

しかし、IE( ver 8 の標準モード以外の IE )では、祖先要素に明示的に width や height 値が指定されている要素があると、それが offsetParent となってしまいます。そしてこれまで position 指定をしていなかった container には width が指定されています。この結果 IE 7 以前で閲覧すると、popup 要素が container 内に意図したとおりに表示されていたのです。

他方、safari や chrome では、popup 要素の表示位置が意図した位置から「ずれて」いました。W3C 勧告に従っているこれらのブラウザでは、container 要素内に置かれた popup 要素の offsetParent が body となっていたために、思惑と異なってずれていたのです。(但し、同じように W3C に従っているはずの Firefox では、IE 同様に container 内に収まっていました。その理由を未解明です。)

さて、このようなブラウザによる「ぶれ」を放置したままでは、要素を自在に配置することは出来ません。当然画面内で要素を任意の位置に移動させるアニメーションも思うように操れません。

しかし、offsetParent や offsetTop、offsetLeftプロパティは、ブラウザによって解釈が異なる場合があるだけではなく、そもそも W3C 標準ですらありませんHTML要素の位置取得 - Rails で行こう!)。そのためそのまま使うだけでは、クロスブラウザ対応にはなりません。そこで利用したいと考えているメソッドが、jquery.js の offset と position インスタンスメソッドです。

ところで、W3C 勧告には至っていませんが、offsetParent などについては 「 CSSOM View Module 」という草案が存在しています。そして、jquery.js はそれに準拠するよう配慮されています。

そこで、Ajax コードを改定する前に、まず container 要素に position:relative を指定し、当該要素内に配置される要素の offsetParent が container 要素になるようにしました。これにより CSSOM View Module( W3C Working Draft 04 August 2009) に従って、要素を配置する前提条件が整うことになります。

こうしておいて、jquery.js の offset と position インスタンスメソッドを活用して、 CSSOM View Module に従って、どのブラウザでも同じ位置に要素を配置することを目指します。但し、この問題はエントリイを改めて述べます。

▲ToTop

2. Ajax 通信が終わったことを Javascript インタープリタに知らせる方法

案の定、Ajax 通信コードの改訂作業には時間が掛りました。

久しく Ajax コードを弄っていなかったため、コード内での Ajax 通信独特の「時間差」への配慮も、最初は全く忘れていました。また jqquery.js における Ajax 通信処理の理解が半可通であることも思い知らされました。そこで、自戒を込めて再学習した jquery.js の Ajax 通信コードの要点を整理しておくこととします。

2 年前に完成を見て、つい数日前まで使ってきた従前バージョンの get3modeEntryTitles.js では、setInterval タイマー関数と jQuery.active プロパティ( このプロパティは Ajax 通信の終了を記録する flag の役割を果たしている )を組み合わせて、Ajax 通信の終了を Javascript インタープリタに認識させていました。

しかし、今回改訂した最新の get3modeEntryTitles.js では、ajaxStop イベントハンドラーを使って同じ処理をさせることにしました。この方がコードがすっきりするし、そもそのそのような用途として開発された Ajax イベントハンドラー関数を利用しない手はないからです。

3. 先行する Ajax 通信による取得値を利用する後発 Ajax 通信の起動タイミングの設定

後発 Ajax 通信が先発 Ajax 通信結果を利用する場合、後発 Ajax 通信の開始タイミングがコードの正否を分けます。

勿論、単に後発通信コードを先発通信コードの後に記述するだけでは、何の解決にもなりません。先発通信結果を利用するのですから、それが終わらない限り後発通信を開始してはいけないのに、単にコード記述上前後の順番通りに書くだけでは後発通信は成功しません。

コード進行速度は Ajax 通信速度を遙かに上回るので、先行通信が終わらないうちに後発通信が開始されてしまい、後発通信は必要な情報を先発通信から取得できないからです。

そこで改訂版では、setInterval 関数を起動して、後発通信で使用する先発通信結果の変数が存在するまでループさせ、その存在を確認できてから後発通信を開始するようにしました。

改訂前は jQuery.active 値がゼロになるまでタイマーを繰り返し起動していたのですが、必要な変数の存在確認の方が直接的・具体的であり、可読性も高まります。

▲ToTop

改訂した get3modeEntryTitles.js コード

HTML 文や CSS 文は、jQuery Ajax を活用したエントリイタイトルの各種取得法──集大成! に掲載したものを大部分踏襲しました。但し、CSS 文において visibility 属性の使用はやめ、display属性で統一することにしました。今回 faseIn/Out メソッドによって popup 要素の表示/隠蔽を行うように変えたのですが、これは jquery.js の 各種 animation メソッドは、表示/隠蔽の切り替えに display 属性を利用しているためです。

■改訂した get3modeEntryTitles.js コード
/*
 * fileName : get3modeEntryTitles.js
 * released : 2008/03/01
 * verup : 2008/07/04, 2008/08/08, 2008/08/17, 2010/02/14, 2010/05/15
 */
  1:// 個別エントリイ表示モードでない場合には、何もしないでコード進行を終える。
  2:if (location.href.indexOf("entry")==-1) (function (){return;})();
  3:else{ //個別エントリイ表示の時
  4:(function($){
  5:  var now=function(){return +new Date;};  // 現在時刻取得
  6:  $.tr={ //所要時間計測・待機起動回数記録用 jQuery 拡張オブジェクト
  7:    start:now(),
  8:    registerEvent:"",
  9:    ajax:{ recent:{},before:{},after:{} },
 10:    end:"",
 11:    setEndingCnt:0,waitRecentAjaxCnt:0
 12:  };
 13:  var loading="<div id='loading' class='ta_c'><img src='http://blog-imgs-31.fc2.com/h/k/o/hkom/loading_16.gif' alt='' border='0' width='16' height='16' /> Now Loading...</div>";
 14:  $(function(){
 15:    $("#container").append(
 16:      "<div id='popup_before' class='popup'>" +loading+"</div>",
 17:      "<div id='popup_recent' class='popup'>"  +loading+"</div>",
 18:      "<div id='popup_after' class='popup'>"  +loading+"</div>"
 19:    );
 20:
 21:    // イベント発生要素に沿って popup 要素を配置する(表示へ別メソッドで行う))
 22:    var $popup = $(".popup"),$navi=$(".navi_container"),left,top;
 23:    // 各 popup の縦位置(ナビゲブロックの高さだけ下に)指定
 24:    top = $navi.position().top + (parseInt($navi.css("marginTop")) || 0)+ $navi.outerHeight();
 25:    $popup.width(600);
 26:    var space = $("#container").innerWidth()-$popup.outerWidth();
 27:    // 各 popup の横位置指定
 28:    $.each( ["before","recent","after"] ,function(i,item){
 29:        left= !i ? 0 : i===1 ? space/2: space;
 30:        $('#popup_'+item).css({left:left+"px", top:top+"px"});
 31:    });
 32:
 33:    // 前・最新・後リストの表示/隠蔽イベントハンドラー
 34:    $.each( ["before","recent","after"] ,function(i,item){
 35:      $("#"+ item + "EntryTitle" ).hover(
 36:        function(){  $('#popup_'+item).fadeIn(); },
 37:        function(e){
 38:          var itsIdName = e ? e.relatedTarget.id : window.event.toElement.id;
 39:          if (itsIdName.indexOf("popup") < 0)
 40:            $popup.fadeOut();
 41:        }
 42:      );
 43:    });
 44:
 45:    // 表示された popup の hover イベントハンドラー
 46:    $popup.hover(
 47:      function(e){if (!$(this).is(":hidden")) return;},
 48:      function(e){ $(this).fadeOut(); }
 49:    );
 50:  });  //End of $(function(){})
 51:
 52:  // variable
 53:  var html = {recent:[],before:[],after:[]}, getStr={recent:0,before:0,after:0},
 54:    lastNo, regExpr,thisEntryNo, complement,itval,border={before:0, after:0},realElm = {before:0,after:0},flagStopHandler = false;
 55:
 56:  // 最近のタイトルを取得する関数を定義
 57:  var makeRecentEntryList = function (limit){
 58:    var No, subject, date, iter=0, ret=[], $chd;
 59:    var target ={    //数字は xml ファイル内で登場する順番
 60:          link:[],    //0
 61:          title:[],    //1
 62:      //  description:[],  //2
 63:        //  content:[],    //3
 64:          subject:[],    //4
 65:          date:[]      //5
 66:      };
 67:    $.ajax({
 68:      url: /http:.+fc2\.com\//.exec(location.href)[0] + "?xml" || null,
 69:      type: "GET",
 70:      dataType: "xml",
 71:      global:false,
 72:      success: function(xml){
 73:        var tmpStr = '<div>'+decodeURI(encodeURI("最新のエントリイ情報がありません。"))+'</div>';
 74:        if (xml==undefined || xml==null) {getStr.recent = tmpStr; return;}
 75:        $.tr.ajax.recent["start"]=now();
 76:        $.each(target,function(key){
 77:          $.each($("item",xml), function(i,n){
 78:            $chd = $(n).children();
 79:            ret[i]= [$chd.eq(0), $chd.eq(1), $chd.eq(4),$chd.eq(5)];
 80:            target[key].push( ret[i][iter].text() );
 81:          });
 82:          iter++;
 83:        });
 84:        for (var i=0; i < limit; i++) {
 85:          No = /entry-([0-9]+)/.exec(target.link[i])[1];
 86:          i==0 && (lastNo = Number(No));
 87:          subject =" , " +target.subject[i];
 88:          date =" , " +target.date[i].substring(0,10);
 89:          html.recent.push( "<li><a href='" + target.link[i] + "' target='_blank'>" +  target.title[i] + "</a> (No." + No + subject + date + ")</li>");
 90:        }
 91:        $.tr.ajax.recent["end"]=now();
 92:        getStr.recent =  "<div class='ta_c'><em>Recent " + limit + " Entries</em></div><ul class='ml_1_5'>" + html.recent.join('') + "</ul>";
 93:      }  //End of success()
 94:    });  //End of ajax()
 95:  };  //End of makeRecentEntryTitle func
 96:
 97:  // 前後のタイトルを取得するための準備を行う
 98:  var makeEntryList = function(beforeafter,limit){
 99:    var thisHTTP, getEntryNos=[], thisURL=[];
100:    regExpr = /(http:.+entry-)([0-9]+)/;
101:    thisEntryNo = Number(regExpr.exec(location.href)[2]);
102:    thisHTTP = regExpr.exec(location.href)[1];
103:    border[beforeafter] = Math.min(limit+1, beforeafter == "before" ? thisEntryNo :(Number(lastNo)-thisEntryNo+1) );
104:    if (border[beforeafter]==1) thisURL.length=0;
105:    else {
106:      for (var i=1; i < border[beforeafter]; i++)
107:        thisURL.push(thisHTTP + (thisEntryNo - (beforeafter == "before" ? i : -i)) +".html" );
108:    }
109:    // 準備完了! Ajax 通信開始
110:    getTitlesByAjax.call(this, beforeafter,thisURL);
111:  };
112:
113:  // Ajax 通信により前後のエントリイタイトル等を取得する関数の定義
114:  function getTitlesByAjax(tense,thisURL){
115:    if ( thisURL.length != 0 ) {
116:    $.each(thisURL,function(i,aryitem){
117:      $.tr.ajax[tense][i]={};
118:      $.tr.ajax[tense][i]["start"]=now();
119:      $.get(aryitem,function(data){  //data は thisURL[i] の html テキスト文
120:        regExpr = /<title>(.*)<\/title>/;
121:        var titleStr = regExpr.exec(data)[1].substring(19);
122:        if ( /\S+/.test(titleStr)){  //空白だけのタイトル名は補足しない。
123:          ++realElm[tense];
124:          html[tense][i] = "<li><a href='" + aryitem + "' target='_blank'>" + titleStr +" (EntryNo." + /entry-([0-9]+)/.exec(aryitem)[1] + ")</a></li>";
125:        }
126:        $.tr.ajax[tense][i]["end"]=now();
127:      },"text");
128:    });
129:    }
130:  };
131:
132:  function ajaxStopHandler(){
133:    flagStopHandler = true;
134:    $.each(["before","after"],function(i,tense){
135:      if (realElm[tense]==0)
136:        getStr[tense]="<div class='ta_c'>"+ (tense=='before' ? "Before " : "After ") + "Entry "+ decodeURI(encodeURI('はありません。')) + "</div>";
137:      else {
138:        complement = (border[tense]-1 -realElm[tense]!==0) ? 
139:          " ( " +decodeURI(encodeURI('欠番があります。')) +" )" : "";
140:        getStr[tense] = "<div class='ta_c'><strong>"+ (tense==='before' ? "Before " : "After ") + realElm[tense] + " Entries" + complement +"</strong></div><ul style='margin-left:1.5em;list-style-type:disc'>" + html[tense].join('') + "</ul>";
141:      }
142:    });
143:    var beforeTime= realElm.before!==0 ? "<li>以前タイトル取得 Ajax 通信所要時間: "+ ($.tr.ajax.before[realElm.before-1].end-$.tr.ajax.before[0].start)/1000 +" 秒</li>" : "";
144:    var afterTime= realElm.after!==0 ? "<li>以後タイトル取得 Ajax 通信所要時間: "+ ($.tr.ajax.after[realElm.after-1].end-$.tr.ajax.after[0].start)/1000 +" 秒</li>" : "";
145:    var AjaxLog ="<ul style='margin:0.5em;border-top:white dotted 1px;padding:0.5em 0.5em 0 1em;list-style-type:circle'>"+
146:      "<li>クリック後 Ajax 通信開始迄の所要時間: "+($.tr.ajax.recent.start-$.tr.start)/1000 +" 秒</li>"+
147:      "<li>最新タイトル取得 Ajax 通信所要時間: "+ ($.tr.ajax.recent.end-$.tr.ajax.recent.start)/1000 +" 秒</li>"+ beforeTime + afterTime +
148:      "<li>このプロジェクト全体の所要時間: "+ (($.tr.end=now())-$.tr.start)/1000 +" 秒</li></ul>"+
149:      "<div style='text-align:right;margin:-2em 1em 0.5em 0'><button style='display:block;margin:-1em 0 0 auto;width:16em' title='このボタンをクリックするとここで行った Ajax 通信に関するこのブログのエントリイが開きます。' onclick='this.blur();window.open(\"http://hkom.blog1.fc2.com/blog-entry-626.html\",target=\"_blank\")'>この Ajax 通信や所要時間について</button></div>";
150:    $(function(){
151:      $("#popup_before").html(getStr.before + AjaxLog);
152:      $("#popup_after").html(getStr.after + AjaxLog);
153:      $("#popup_recent").html(getStr.recent + AjaxLog);
154:    });
155:  }
156:
157:  $(document).ajaxStop(function(){
158:    ajaxStopHandler();
159:  });
160:  // 前後及び最新のタイトルリスト作成
161:  makeRecentEntryList(10);  //最近リスト取得実行
162:  makeEntryList("before",10);  // 以前エントリイ
163:  function nextAjaxTimer(){
164:    $.tr.waitRecentAjaxCnt++;
165:    // makeRecentEntryList により lastNo 値を取得するまでは起動しない。
166:    if (!!lastNo) {
167:      if (ival) {clearInterval(ival);ival=null;}
168:      makeEntryList("after",10); // 以後エントリイ
169:    }
170:  };
171:  var ival = setInterval(nextAjaxTimer,100);
172:})(jQuery);
173:}

AccuRadio に嵌る

その存在は既に 20 世紀に知っていたが...

そうなのである。知ってはいた。休日にたまに聴くこともあった。

しかし、ユーザーインターフェースが独特で、一般的なマルチメディアプレーヤでは聴くことが出来ないことが、ずっと災いしてきた。

常にブラウザ上でしか聴けない、ということは軽快に使えないことを意味する。

故に、その存在を顧みないまま 10 年以上が過ぎ去った。

きっかけは iPhone だった

iPhone には幾つかのインターネットラジオアプリがあり、SHOUTCast、iCarRadio はiPhone 購入時にインストールしたが、AccuRadio の iPhone アプリの存在は知らなかったし、探そうともしなかった。(有料アプリ: Radio や ooTunes Radio-Recording and Alarm Clock は当面お呼びではない。)

どんなきっかけで AccuRadio の iPhone アプリを見つけたのは記憶は定かでないが、兎に角見つけて以来、通勤途上で毎日それを聴いているのである。

そして AccuRadio の「素晴らしさ」である

まず、沢山のジャンルに分類されたチャンネルとそのサブチャンネルの数の多さに圧倒される。そして、細分化されたサブチャンネルが、特定の気分や雰囲気に浸りたい時にはぴったりなのだ。

iTunes や Win amp でも沢山のジャンルがあり、そのサブチャンネルも沢山ある。古典的と言っても良いインターネットラジオ局 SHOUTCast も、数千のチャンネルがある。

しかし、AccuRadio のサブチャンネルは作曲家別、プレーヤー別などの、他のラジオ局にはない分類となっていて、これが素晴らしいのである。

現在は、iPhone でも自宅 PC でも、専ら Classic ジャンルのサブチャンネルを聴いているのだが、その音に浸っていると心地よい別世界へと誘われる思いがする。

Navigate Bar に係る Ajax Javascript コードを見直した。

Navigate Bar を改善した

ここで言うところの Navigate Bar とは、各エントリイ最上部付近に表示している

「 直前のEntry(4) | ホーム(5) | 直後のEntry(6) 」

のことである。

「改善した」と言ってもそのバーの見た目は全く変えていない。

このバーは、3 つの文字列の上にマウスカーソルを載せると、直前の 10 本の記事タイトル、最近の 10 本の記事タイトル、あるいは直後の 10 本の記事タイトルを、それぞれの文字列に対応して表示するためのものだ。そして、この表示に jquery.js の Ajax 関係コードを利用していることは改めて触れるまでもないだろう。

今回その表示 / 隠蔽方法を jquery.js で提供されている fadeIn / Out メソッドに変更したのであるが、変更はそれだけではない。

記事リストの表示位置は以前と全く変えていないが、その表示/隠蔽コードを全面的に見直し、エントリイ番号 750 ~ 754 において解読した offset、position、innerWidth/Height、outerWidth/Height メソッドを積極的に利用するように改訂したのだ。

これによりコードがすっきりしたことは言うまでもないが、一連の位置・サイズ関連メソッドの利用実績を重ねることに意義があった。

そして案の定、実際に利用してみて貴重な成果を得ることが出来た。

変更結果

こちらのエントリイをご覧ください。「jquery.js を利用した Ajax 通信の一例(改訂版コードについて) 2010/02/15(No.762)

IE における jQuery("A").css("marginTop") 返値の特異性

或る HTML 要素 A ( この要素は position:absolute ; に指定されていると仮定する)の margin-top 値を、スタイルシートにおいて margin-tpo:0; に指定したと仮定する。すると、誰しもその場合には jQuery("A").css("marginTop") は ゼロを返すと予想する。実際 Firefox ではきちんとゼロを返す。

ところが IE8(標準モードで描画した)では、何と auto が返される。これは明らかなバグであるが、このことによって、Navigate Bar に関するコードのエラー原因がなかなか掴めず、エラー箇所の特定にこの土日を費やしてしまったのである。

またしても IE 対策に時間が割かれ、恨めしい思いだけが残ったのだ。

IE よ。Microsoftよ。いい加減にしてくれ!!!!──と絶叫したい。バグを知らなければ満足に利用できない代物は、ユーザーフレンドリィではないし、いくら無料の製品とはいえ、欠陥品と言えるのではないだろうか?!!

Fc2 ブログのファイル上書きアップロードについて(続編)

どうやら改善が図られたようだ

Fc2 ブログのファイルの上書きアップロードは相変わらず正常に機能していない ← こちらのエントリイで、「相変わらず」上書きアップロードが出来ないことを嘆き、抗議的記事を書いた。

しかし、その後使っていてどうやらやっと改善が図られた模様なので、Fc2 社の名誉のためにもその旨を報告するエントリイを、敢えて記述することにする。

改善の内容

ここ数日、ファイル上書きアップロードを複数回使ってみて、上書きアップロードの不備改善は次のように図られた、と言えるのではないかと思う。

  • 上書きアップロードをしようとすると、かなり五月蠅くて適わないのだが、「上書きしますか?」と確認するダイアログが表示される。
  • 上書き結果は即座には反映されず、一定の時間が経過してから反映される。
  • その反映時間は数分なのか、数十分なのか確定的には分からないが、経験的には数分と言えるようだ。

今更であるが...IE8 の Web 標準 ( W3C ) 準拠モードと 2 つの互換モードについて(メモ)

IE はまだ存命す

インターネットエクスプローラ(以下 IE )の性能と評判の悪さはよく知られているところである。他方、それにも拘わらず IE のシェアが恐ろしく鈍い速度でしか低下しない。( それでも一時の「 80 %以上 」という異常な状況は改善され、確実に低下していることは喜ばしい。)

IE7 登場前の一時期には、評判の悪い IE 6 が改善されぬママ長い間「放置」されていたことから、「 MS 社はブラウザ開発から撤退か? 」の観測も流れたことがあった。しかし幸か不幸か、IE 7 が登場してしまい、その後現時点の最新バージョンである IE 8 迄登場してしまった。かくして撤退観測は願望的予測として裏切られてしまった。

さて、IE 8 の描画モードであるが、これがややこしいことになっている───ということを、恥ずかしながら最近まで知らずにいた。

このブログを立ち上げた時点で、ブラウザの表示は標準と後方互換という2種類のモードがあることを学習し、努めて標準モードで描画されるようなHTML 文を書くように心掛けてきたつもりだ。

そして、一貫して W3C 準拠を拒絶しつづけて来た IE が、IE 8 において遂に匙を投げ、W3C の軍門に下ったことを喜びをもって歓迎した。しかし、IE 8 に描画モードが3つ用意されていることは、寡聞にして知らぬママ現在に至ってしまった。

またまたやってくれた MS 社───ややこしいったらありゃしねえ

以下の記事は、Internet Explorer 8正式版レビュー - @IT に多くを負っている。

W3C 準拠をここ迄遅延させてきた結果、自ら蒔き散らしてきた W3C 非準拠ブラウザが大量に出回り、未だに多くの利用者がそれを使っている異常事態が存在している。

まさか自動車のようにリコールするわけにも行かず、苦肉の策として 3 つのモードを用意せざるを得なかったわけだ。

IE 8 には次のように 3 つの描画モードが存在している。

  • IE8標準モード(IE8標準、完全な標準CSS)
  • IE7互換モード(IE7標準、IE7互換の標準CSS)
  • Quirksモード(IE5標準、MS-CSS 5/6/7対応)

IE 8 には (1) W3C 準拠モード=IE 8 標準モード、(2) IE 7 標準モード、(3) IE 5/6 互換モードの 3 種類が存在している。そして (2) のIE 7 互換モードがこれまでのブラウザにはない第三の選択肢であり、特殊なモードだ。

ここからややこしさが始まる。これらの 3 つの描画モードを指定する IE 8 独自の方法( またしてもやってくれたわけだ。IE 独自がまたまた登場したのだから )が存在するということと、サイト閲覧者が (1)と(2) のモードを IE 8 上で切り替えられる、ということだ。

或る頁を IE 8 で描画した場合、DOCTYPE 宣言内容やその有無によって (1) 標準モードと (3) 後方互換モードを切り替えられるが、(2) のIE 7 標準モードは X-UA-Compatible meta タグを指定するという IE 8 固有の特殊な方法によって指定する。

しかも、(1) の W3C 準拠モードで作成された Web サイトを、IE 8 で閲覧する場合、閲覧者がブラウザ上で容易に (2) の IE 7 標準モードに切り替えることが出来、かつ、二度目以降の当該サイト閲覧時には、以前に同じ閲覧者が指定した IE 7 標準モードでそのサイトが描画されるのである。一旦、IE 7 標準モードに切り替えてしまうと、以後には当該サイトは切り替えられたモードで描画される「出血サービス」迄付いているわけだ。

▲ToTop

meta タグによる 6 種類の IE 8 描画モード指定

meta タグに拠る描画モードの指定は次のように行うそうだが、この value 値がかなりややこしい。
<meta http-equiv="X-UA-Compatible" content="IE=value" />

value には次の 6 つの値のいずれかが指定できる。

edge
最新(IE 9 が登場すればその標準モードで描画し、現時点では DOCTYPE 宣言有無には関係なくIE 8 標準モードで描画する。)
emulateIE8
DOCTYPE 宣言がない場合には後方互換モードになり、ある場合にはその指定に従う。
8
DOCTYPE 宣言の有無に拘わらず常にIE 8 標準モードで描画する。
emulateIE7
DOCTYPE 宣言がない場合には後方互換モードになり、ある場合には、IE 7 標準モードで描画する。
7
DOCTYPE 宣言の有無に拘わらず常にIE 7 標準モードで描画する。
5
今日でいうところの後方互換モードで描画する。

常に IE8 標準で、あるいは IE7 標準で描画する content 指定が用意されているが、これは裏返せば DOCTYPE 宣言を無効化することになる。

W3C 標準準拠を拒絶し続けてきた過去の遺産の「継承性」に責任を負わざるを得ない顛末が、またしても W3C 勧告にはない IE 固有の方法を実装せざるを得ないという、何とも奇怪な対応策を招いてしまったのだ。

IE の各種描画モードによる差異を視覚的に把握するツール

エントリイ冒頭で触れた Internet Explorer 8正式版レビュー - @IT に紹介されている、Expression Web 3 Super Preview for Internet Explorer を使ってみたが、それよりも遙かに優れたツールが Core Services 社から提供されている。 ( Core Services 社は、Javascript デバッグツール Companion J や Web 頁チェッカー DebugBar を提供しているフランスの会社らしい。)

それは IE Tester だ。My DebugBar | IETester / Browser Compatibility Check for Internet Explorer Versions from 5.5 to 8

実際に使ってみたところ、時々「落ちてしまう」基礎的欠陥はあるものの、バージョンによる描画状態の差異を比較するには、十分快適に使えると思われる。

現在閲覧している homepage の描画モードを取得するブックマークレット

エントリイ冒頭で触れた Internet Explorer 8正式版レビュー - @IT に紹介されている、IE の描画モードを取得するスクリプトをブックマークレットにしてみた。

■IE の描画モード取得ブックマークレット
(function(){var renderingMode = document.documentMode;
alert("現在のレンダリング・モードは「" + renderingMode + "」です。");})();

Fc2 ブログのファイルの上書きアップロードは相変わらず正常に機能していない

Done Message「上書きしました」は何なんだ!?

ファイル上書き行為を履行すると、上書き確認ダイアログが表示され、その行為が終わると「上書きしました」と履行済みメッセージがファイルアップロード頁内に発せられる。

にもかかわらず、結局上書きは行われないのだ。

そもそも、上書き確認ダイアログは数日前からやっと表示されるようになった新機能だ。そして数日前には、複数のファイルにおいて、問題なく上書きが出来たことも何回かあった。

しかし、上書き確認メッセージと上書き完了メッセージは表示されるのに、昨日も本日も上書き出来ない。

一体どうなっているのか??

ファイル上書きアップロードは、いつになったら正常に機能するのだろう

この問題は数年前から、FC2ブログ ユーザーフォーラム で相当の数の投稿がやりとりされてきたが、未だに解決しないようだ。

一体何時になったら正常に機能するのだろうか?

基本機能がこのように不十分なまま放置されることは、いかに無料サービスとは言え余りにユーザー軽視ではないだろうか!

DropBox を複数人の、複数のパソコンや iPhone で共用する SFS

その存在は数年前から知っていたが、殆ど利用しなかったのは...

その理由は単純だ。複数の PC や複数の人と共有すべきファイルが余り存在しなかったからである。そのため複数のパソコンでファイル共有する場合には、主に usb メモリ経由で同期化を図ってきた。それで十分だったのだ。

しかし、この度或る事情により、ファイル共有を複数の人と複数の PC や iPhone において行う必要に迫られて、改めて DropBox を利用することにした。

早速自宅 PC 内にストックされているあるフォルダとファイル約 115 MB を DropBox に「入れた」。つまりオンラインストレージに送信したのである。

そしてその子フォルダを持つフォルダを共有化し、複数のメルアドを「招待」した。招待先に自分の iPhone アドレスを含めたことは言うまでもない。

DropBox を介した情報共有はいわばソーシャルフォルダシステム(SFS)と言える

DropBox からの「招待状」は直ぐに届いたので、さっそくこれを承諾した。

すると、数分の内に子フォルダを持つフォルダ内の全てのファイル 115 MB が、iPhone にダウンロードされ、同期が図られた。

こうして、自宅 PC、我が iPhone、我が DropBox の MyFoleder、及びその他の招待者のPC の、都合 4 つ以上の「媒体」に、同一のファイルが保存され、常に自動同期が図られることになったのである。

さて、DropBox を介した情報共有のあり方は、まだ共有する他人は少ないものの、いわばソーシャルフォルダによる社会的情報共有と言うことが出来る───ということに改めて気がついたのである。

SMS に準えて言えば、このシステムは SFS と言える。SDS : ソーシャルディスクシステムと言っても良いだろう。

新しい社会的な情報共有ツールとして、DropBox を積極的に位置づけ利用することが出来る、ということを改めて認識した次第である。

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

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