ホームページについての日記

このページについて

このページは、JavaScript+PHPで作っている「ホームページについての日記」をHTML版に直したページです。

GoogleやYahooなどの検索エンジンに拾われてもかまわない内容だけを書いてます。検索エンジンに拾われたく内容は書いてません。

最新のページはあるていど項目別にわかれてます。

２０１２年２月２８日
2009年末に「Selectors API Level 1」のCandidate Recommendationが出ていたが、当時は対応しているブラウザが少なく、IEも8 が対応なため、つかってしまうと可読性を著しく損なう可能性が高かったので使わなかったAPIである。
使わないと忘れてしまうもので、つい先日まで忘れていた。「jQuery」の$関数を見て思い出した。今なら使えるので使ってみようと思う。
「Selectors API Level 1」は、DOMの取得の記述をCSSのセレクタで行うことが出来るAPIです。document.getElementById('abc');などは、document.querySelector('#abc');と書きます。
dquerySelectorは、指定のDOMオブジェクトのなかから一番初めにマッチしたDOMオブジェクトを返します。マッチした場合は、Element ノードを、マッチしない場合、nullを返します。
複数のノードがある場合、querySelectorAllを使います。この場合、Element ノードをセットしたNodeListを返します。アンマッチの場合、空のNodeListを返します。
便利ではあるが、このままでは使いかってが悪い。使いかってが悪ければオブジェクト化してしまえばよいわけだ。querySelectorAllでDOMを取得。NodeListが１件しか無い場合、Element ノードを返す。複数の場合はNodeListを返す。アンマッチの場合、falseを返すような、オブジェクト化してしまう。
そうすると、querySelectorなのか、querySelectorAllなのか、くだらないことで悩む必要がない。使ってみると以外に便利。DOMをTagNameで取得して、getAttributeで属性を拾ってDOMを特定していたのが、CSSのセレクタで取れてしまう。
時代は動いているのですね。
２０１２年３月７日
私はJavaの開発もAndroidの開発もやってません。やってませんが、「Android xslt」なんて検索ワードが多いのでちょとだけ書きます。
JavaでXSLTを使うためには、「javax.xml.transform」がサポートされる必要があります。自分が開発しているAndroidが「javax.xml.transform」をサポートしているか調べてください。
サポートされていればXSLTも使えます。やることはJavaScriptやPHPと同じです。XMLとXSLTを読んで、「transform」すればよいだけです。
JavaScript
var xmlDoc = xmlthttp.responseXML;
var xslt = new XSLTProcessor();
var xsltDoc =  document.implementation.createDocument("", "", null);
var xslthttp = new window.XMLHttpRequest();
xslthttp.open("GET",xslt_url,false);
xslthttp.send(null);
var xsltDoc = xslthttp.responseXML;
// XMLをXSLTでDOM変換
var doc =  xslt.transformToFragment(xmlDoc, document);
PHP
$xml = new DomDocument();
$xml->load($XML_URL);
$xslt = new DomDocument();
$xslt->load($xslt_url);
$processor = new xsltprocessor();
$processor -> importStyleSheet($xslt);
** XSLT変換後のXML_object */
$xml_obj = $processor -> transformToXML($xml);
Android(開発したことがないからこんな感じだと思う)
Source xmlSource = new StreamSource(this.getResources().openRawResource(xmlsource));
Source xsltSource = new StreamSource(this.getResources().openRawResource(xsltsource));
TransformerFactory transFact = TransformerFactory.newInstance();
Transformer trans = transFact.newTransformer(xsltSource);
OutputStream output = new StringOutputStream();
StreamResult result = new StreamResult(output);
trans.transform(xmlSource, result);
この程度のことがきちんと検索出来ないようでは「Androidの開発」なんて無理ですよ。
２０１２年３月２８日
「Web Workers API」がある。JavaScriptでマルチスレッドを実現するAPIです。
制約があります。(自分で確認したもののみ)
使い方は、Workerオブジェクトに実行させたいJavaScriptをセットして、そのWorkerのmessageイベントを起動させます。
そうすると、Workerが実行されてpostMessage()で値を返します。
「生き物検索」で検索データの先読みで使ってみました。検索の体感速度がはやくなりました。
２０１２年４月２日
このページのデータはXMLで構成されています。「目次」や「内容」もXMLでデータを保存しています。
しかし、書きかけのデータの保存・修正する方法がないので、テキストデータを作って貼り付けるなんてことをしていた。まぁ、自分用なのであまり不便はしていない。
なんか面白い方法が見つかったら、この辺の管理も簡単につくりたいなぁ。と思っていた。
HTML5のなかに「File API」なんてものがある。JavaScriptでローカルのファイル操作ができてしまうAPIです。
これ、使えるなぁ。書きかけのデータを、ローカルに保存して、続きはファイルをドロップして展開して書けば良いわけだし。変にファイル管理等しないので仕組みも簡単に作れる。
FirefoxとGoogle Chromeでしか使えないが問題ない。書きかけのデータの保存もできていまいました。
２０１２年４月１９日
最近HTML5でほーむぺーじを作ろうなんてページを目にする。ちょこっと前にあった「とんでも解説」の再来のような気がする。
HTML5でサイトをつくろうってページがある。読んでいるとHTML5に関する部分でおかしいなぁ。と思う部分がある。
HTML5宣言をしておいて、HTML5の要素を使わずdivで代用するのを、「現状では理に適っている」と書いてある。しかし、HTML5の宣言をしたのならば、HTML5のマークアップをするものである。HTML5のマークアップをしないのならば、他のHTMLの宣言をすればよろしい。HTML5の宣言をして、HTML5のマークアップをしないのは「理に適ってない」のである。
マークアップの例もみた、article 要素のなかにheader 要素をつかってます。article 要素は「単独で再配布でき再利用できるよう意図したもの」です。そのなかにheader 要素まで使ってしまうと、このarticle 要素はドキュメントから独立して存在しているように見えます。そうなると、見出し要素は、h1から始まるほうが良くみえます。「単独で再配布できるけど、この文書と関係があるよ」って意味したいなら、header 要素は無いほうが良いと思います。
HTML5はWeb開発者向けの仕様であって、普通の人はあまり使わないものです。CSS3を使いたいだけなら、HTML5である必要はありません。
HTML5はSVGやら、APIやら、Web開発者に優しい仕様ですが、「見れれば良い」人にすすめるものではないです。
私のページは色々なAPIやらSVGやら使ってます。使っていてそんな感想です。
とりあえず、HTMLはどのようにマークアップするのか「意味マークアップ」を調べたほうが良いと思います。
２０１２年５月２８日
過去のアクセスグ1.5年分を集計してみた。
IEの落ち込みが激しい。代わりにAndroidやiPhoneのアクセスが増えている。
いろいろな仕掛けもAndroidやiPhoneを頭においておかないと見れないコンテンツができあがってしまう。
まぁ、「なんとなく趣味」のページ的には喜ばしいことなのだが、HTML5のAPIの対応を調べるのが面倒になってきた。
PC版とスマホ版で使えるAPIの差をなくして欲しいよなぁ。
結局開発工数はあまり変わらずです。
２０１２年６月４日
Android についてXSLTについて検索している人が多い。この際「なんとなく趣味のページ」で集めた情報を書いておく。
Android 2.1-update1: XSLTProcessor,localStorage,GeoLocation,WebWorker,CrossDocumentMessaging
Android 2.2.X: XSLTProcessor,WebWorker,localStorage,GeoLocation,CrossDocumentMessaging
Android 2.2.X Opera: localStorage,GeoLocation,XSLTProcessor,WebWorker,CrossDocumentMessaging
Android 3.X: WebWorker,XSLTProcessor,localStorage,GeoLocation,CrossDocumentMessaging
Android 4.X: WebWorker,XSLTProcessor,localStorage,GeoLocation,CrossDocumentMessaging
Android のWebKitでXSLTを使ったページは3.X以降でないと表示できません。
Android のWebKitでWebWorkerを使ったJavaScriptは使えません。
Chromeは、localStorage,GeoLocation,XSLTProcessor(includeは使用不可),WebWorker,CrossDocumentMessaging
Android の開発でXSLTを使いたい場合、「Android」でXSLTを使って開発したいってことかなぁを参照
２０１２年７月１９日
Googleの検索がhttpsになるそうだ。「https」のGoogleのページから検索結果のページを表示するのに、「http」のGoogleのページを経由するみたいです。
そうなると、「検索ワードがわからない」。最近、約１割のGoogleのページは検索ワードが無かったはこのためだったわけです。
検索ワードは「ウェブマスターツール」で提供する。なので問題はありませんだそうです。
作成者の情報を集めて、リンク集を作って稼いでおいて、製作者の欲しいデータは「ツール」を使えだと。
なんか腹たつなぁ。Googleからのリンクで検索ワードが無いリファラはアラートを出してしまえ。
検索ワードは個人情報なのか？
腹はたつが、「検索ワードは個人情報なのか？」考えてみました。
個人情報と「なる」、「ならない」はそのサービスの使い方にで判断できると思います。
私は、基本的に「検索ワード」は嗜好データだと考えます。自分のWebの中で個人を特定できる符号を付加して管理した場合、「某県の人の飼育しているカナヘビが、何月に調子悪くなった。何月に死んだ。」と情報が盗れます。
「盗れる」との表現は、「アクセスログをとられている。」と思っていても、「とられた情報」を「名寄せ」されていると考えている人は少ないと思うこと、また、そのことを明記していないので、あえて「盗る」と書いてます。
個人で出来ることを、Googleが出来ないはずはありません。少なくても、「Login」した人に対しては、確実に検索ワードを関連付けて管理されているはずです。この場合は、検索ワードは「個人情報なので提供しません。」は、まぁ、腹ただしが納得です。
Firefoxから、Googleの検索窓を使うと「HTTPS」になります。私の基準では、「検索ワード」は、そのサービスが個人情報としている場合のみ、「個人情報」なので、Firefoxが「HTTPSのGoogle」を使うことは反対です。Firefoxが保護すべきもでもないし、Firefoxが個情報なのでと判断したのならば、「Firefoxでどのように使用されているのか教えて欲しい」です。
「Google Chrome」が、まだ実行していないのに、「GoogleがWebを牛耳る」のにFirefoxが加担しているように見えます。個人的にはFxは「やりすぎ」だと感じます。
どの程度の情報が取得できているのか？
「なんとなく趣味のページ」でどの程度の情報を取得できているのか、「個人情報？」となる部分を含めて書いてみます。
7月3日、16:16頃。光学機器メーカの人が、WebKitのXSLTの情報を求めてページに来訪したと思われます。
Chromeを使い、Googleにログインして検索を使っている人のようです。
2012年の日記を見にきているので、このページをチェックしているようです。けど、ブラウザのブックマークはしていないようです。
2010年のページも見ているので、この年の内容に関心があることが書かれているようです。
そのうちこの内容を目にした後の行動が楽しみです。
私のページでは、「予想や憶測」が入ったものですが、Googleにログインして、Googleのサービスを使うとこれ以上のデータが確信を持って集められています。
その覚悟を持ってGoogleのサービスを使いましょう。
GoogleのWebキャッシュ
このページにアクセスした人が、13秒後に「GoogleのWebキャッシュ」でみている人がいました。なんとなく趣味のページは、「GoogleのWebキャッシュ」でもアクセスログを取得できてしまってます。
「GoogleのWebキャッシュ」で見ても、普通にページを見にきたのと同様のアクセスログがとれます。「気をつけましょう」
２０１２年７月３０日
「CrossDocumentMessaging セキュリティー」なんてアクセスがあった。基本的に「CrossDocumentMessaging」のセキュリティーは無いものだと思ってください。
イベントオブジェクトのoriginは必ずチェックしてください。基本的にIFRAMのmessegeイベントにメッセージが送られた場合、自分で意図いていないIFRAMからメッセージが送られた場合でも受信します。originは「CrossDocumentMessaging」の仕組みでドメインが送られます。最低ここはチェックしましょう。
ただし、「CrossDocumentMessaging」の送信先がレンタルサーバーなど、同じドメインを使用している場合originだけでチェックしても無駄です。それなりにチェックする必要があります。チェック方法は自分で考えてください。
「CrossDocumentMessaging」のデータはテキストです。メッセージ受信側で不用意にeval()してしまうと、JavaScriptが実行されてしまい大変なことになる場合があります。
SQLやPHPも書けたりします。その辺のチェックもしておかないと大変なことになる場合があります。
通信上のセキュリティーは、HTTPでの通信になります。ブラウザからサーバーの通信のセキュリティーをあげたいのならば、自分でHTTPSの設定を行ってください。
もういちど書きます。「CrossDocumentMessaging」のセキュリティーは無い。セキュリティーは自分で作ってください。まぁ、プログラムの基本です。
２０１２年８月３１日
Googleでリッチ スニペットなるものがある。HTMLにMetaデータを埋め込み「検索」に利用する取り組みです。2009年11月からあったサービスです。当初は「microformats」「RDFa」しかなく、両者とも「HTMLに無理やりMETA情報を記述する、HTML以外の仕様」なので無視していた。
ふと、リッチ スニペットのページを覗いてみると、「microdata」に対応していた。調べてみると、2010年3月には対応していたようで、気づいてませんでした。
「microdata」ならHTML5関連仕様なので使ってみようと思います。
リッチ スニペットのページを見るとわかり難い。HTML の基本的な知識があれば、これらの形式の予備知識は必要ありません。なんて書いてある。用意したサンプル通り書けば問題なく動くので、理解する必要は無いなんて感じをうけます。
実際にサンプルを見て自分のページに適応させようとしたら、上手くいかない。さて、なぜだろう。エラーの内容を見ても、きちんと必須の項目をいれているのに上手くいかない。
サンプルの情報でエラーチェックをすると、エラーがでない。中身を確認してみると、トリプルを作っているように見える。これがわかってしまえば応用ができる。
「レビュー」「レシピ」「イベント」をつけてみた。意地悪く、同じ文書ないに別の「microdata」もつけてみた。さて上手くいくのでしょうか。
しかし、「わからないと思うから従え。」みたいな説明では使ってもらえないです。
もうすこしユーザーにわからせる努力があっても良いとおもうのだが。このへんが「Google quality」だったりする。
２０１２年９月２８日
WebKitがCSS3の縦の書方向に一部対応したなんて記事を読んだので実験。
Windowsにもともとあるフォントを@をつけて指定することで対応した、なんて記事に書いてあった。フォントが無い場合、どうなるんだ？WebFontを使った場合どうなるのだ？
やってみると、書方向は縦、文字は横(この文は、書方向は横、文字は縦。)。まぁ、見にくい。サンプルの通りやると、書方向は縦、文字も縦になります。@FontはWindowsの仕様なので他のOSでは無理っぽい。しかも指定のフォントがないと、「書方向は縦、文字は横」になってしまう。
なので、CSS3のWebFontを使ってみる。CSSでWeb上にあるフォントを使い、ページをそのフォントで表示する仕様である。指定をして、横の書方向に適応してみると上手くいった。これを縦の指定をすると、「書方向は縦、文字は横」フォントがWebFontでは無くなる。@をつけてWebFontをダウンロードして適応してみても、「書方向は縦、文字は横」になってしまって見にくい。
IEも対応しているので、IE9でやってみる。見事に縦表示する。これなら使えます。まぁ、Windowsにのみ対応しているIEなら出来て当たり前だと思います。
これは「縦の書方向に一部対応した」といえるレベルではないと思います。

テレワークならECナビ Yahoo 楽天 LINEがデータ消費ゼロで月額500円〜！
無料ホームページ 無料のクレジットカード 海外格安航空券　海外旅行保険が無料！ 海外ホテル