-2月2日(水)-

PhotoShop/カラーマネージメント関連:

カラーマネージメント関連では、無補正印刷に対して　またまたその説明に更新がありました。
内容に関しても、以前の方法はあまり推薦されなくて、他の方法を新たに紹介していますが、なんと低レベルな会社かと思わざるを得ません。
全くユーザ視点からのレビューが反映されていません。

Macでは　どうのこうのと　のたまわっていますが、なぜWindowsでは問題ないのでしょうか。
本来であれば、OS云々の違いがアプリケーションに影響しているのなら、
関連する箇所についてWindowsとMacの本質的な相違を説明した上で、アプリケーション本体での理由と対応を説明すべき事です。
全くそういう説明はなく、「こうやったらできます」なんて言う説明は、全くもって素人の説明です。

PhotoShop/イメージリサイズ:

今回WebAlbum作成時、プログラムでリサイズやらUSMなどを再度調べていました。

photoshop上では　画像解像度というダイアログでまとまっていますが、外部コントロールするスクリプト言語インタフェースでは、ResizeImageでまとめられています。
ここで見るべき箇所は、スクリプトの方には、ドキュメントの幅・高さという項目がありません。
要は、ドキュメントの幅・高さというのは計算上のパラメータで、最終的には、ピクセル幅の方に反映されるのです。
通常画像のみを印刷したり表示したりする分に関しては、幅（Width）と高さ(Height)しか意識しません。
解像度(Resolution)はほとんど無頓着になっている場合が多いです。
一部の現像ソフトでは、解像度を設定できないものもあります。

しかし解像度が問題となるのは、例えば、この画像をドキュメントとした見た場合、このドキュメントに文字を書き込むとなると、
文字の大きさは相対的な大きさである　PT(ポイント)を使う場合が多いと思うが、PTは、解像度に影響を受けてしまうので、違った大きさになってしまいます。
画像を自分で使う場合及び、他者に渡す場合にも、解像度もきちんとした扱いをする必要があります。

SSD：

メインパソコンのOS部に使っているSSDの性能を再度計測してみた。

左は導入当時、右は導入後3ヶ月後の現在の状態。
特に問題はないようです。

C300は4KQD32(つまりはマルチタスク環境下同時SSDアクセス)の性能が出ない場合が時々ある模様。
インターネット上の報告でも時々見られるもの。
またどうやら　C300のアライメント調整は必須との事らしい。
どうも根本的な対策は、OSのパーティションの切り方が、こういう4Kという所に不一致しない箇所から始まっているからの模様。
OSの開始領域をそれ相応に再配置する必要があるが、再配置ツール自体が動かない場合がある模様で、取り扱いは少しやっかいだが、
最終的にはOS再インストールで解決できるので、いかに効率良くやるかだが...

ノートパソコンのSSDに関しては、元々OS領域の前にOSセーブの為のダミー領域がとられている事が影響してか、4Kバイト境界の整数倍から始まっていた。

WebAlbum：

一応完成版でテストデータのサンプルを公開。
以下をアクセスしてみて下さい。

ＰＬＩＥ君のWebAlbum

元々舞台写真に特化していますので、演目一覧も基本は舞台上の演目に合わせています。
なおこの演目一覧も自動生成しています。
キーボード操作はかなり快適です。唯一のマーク機能もおもしろいです。
画像内にファイル番号を書き込んでいるのは、舞台写真がメインなので画面の右下は　かならずグレエの床なので、これで問題ないのです。
キーボード操作でもマウス操作でもサクサク動作すると思われます。
画像の真ん中には、薄く下絵(PLIE)という文字が書かれています。

説明箇所部分を少し手直す必要があると思います。
今年はこれをベースにお客さんに見せる予定です。

もしかしたら来月中に注文書をPDFで作成する所と、お客さん管理をして、お客さんのマークした画像はいつでも見られるようにしたいと思っています。
これをベースにJavaScriptだけで[window:summary/detail]は動作させる事ができるように改造できると思いますので、オレにも欲しいという人は、
連絡下さい。気が向いたらその部分だけ作っておきます。

このまま動作させるには、サーバ環境としてPHPが動作する必要があります。
なお画像は1万枚あっても、性能上は快適に動作できるようになっています。
画像を事前ロードしたりするなんてばかげた事はしていませんし、シンプルな表現にしている為、高速に表示できるようになつています。

Web上での画像：

web上で画像を表示させる場合、大きさについては、やはり唯一の大きさで見せるのが流儀だと思う。
というのも大きさに従って、その大きさに伴うＵＳＭ量はやはり変わってくるし、階調の度合い（ここでは画像圧縮の度合い）も変わってくる。
物の形だけを見せる場合には、あまりそういう事も考える必要はないと思われるが、少なくともカメラマンが公開する画像は、
無意識にでもそういう考慮はしていると思う。

WEBサイト上に画像を掲載する場合、やはりその大きさの制約が一番大きいと思う。
拡大も縮小もさせずに、最適にみれるサイズというのは、なかなかに難しい。
極端な話、通常パソコンの画面は　横長である。
横長の写真を　横長の画面に見せる場合には、適合するが、縦の写真を横長の画面に見せるには、同じ大きさの写真掲載では、
基本的にはユーザ志向でないと思う。

今回作成したWebAlbumでは非常に細かい事だが、縦768pxのノートパソコンが結構多いので、それを考慮してある。
横写真はの横サイズは、なるだけ大きくとって　長辺800px。
これは、舞台の全景写真を掲載する時を考慮してなるべく大きくしたい為、実際には900pxくらいまでＯＫだが、全体の操作性を考えるとこれがリミット。
縦写真に関しては、IE系とSafariでは、元々表示する領域が全く違う。
その為、縦写真に関しては、表示環境を自動評価して、大きさの違う2通りの画像をその時々で切り替えて表示している。
もちろん、IE系でもデカイモニターで表示している時には、Safari用の大きな縦画面を表示している。

私の対象とするエンドユーザでは、WindowsノートでIE使用者も多いので、そういう使用者に対しても、最大限見やすい環境を提供したつもり。
単に作成した画像データをそのままの形式で、サーバにアップロードして、WEBアプリケーションの機能で、画像の大きさをコントロールして
その大きさに適したUSMもかけずに見せるという、全く写真品質を考慮していないような　そんな事はしたくない。

たかが選択見本。たかがWebAlbumでも本質は写真なのです。

CLM-V55/レビュー：

ソニー屋さんでテストしてきました。
D7000と接続してテストしましたが、通常の使用では問題ないでしょう。
但しながら、私のように常時シャッターを切った画像を常時外部ディスプレイに表示をさせたい場合には問題あり。
シャッターを切った後に表示されるまで、約3秒程度かかります。
1秒以内なら許容範囲です。

これは、シャッターを切る前に外部モニターとカメラとの接続が切れている為です。
カメラ側から信号が来ないので、接続が切れており、次回接続時には、ＨＤＭＩの接続プロトコルの確立に時間がかかっているようでした。

ちなみに、ミラーレスのように常時液晶モニターに画像が表示されるカメラの場合には、即座に表示されて問題がありませんし、
カメラをライブビューモードにしてシャッターを切る場合も問題はないようです。
私としては、カメラ側に問題ありとしてカメラメーカ側に強く要望を出しておきました。

ちなみにニコン製カメラには、シャッターを切った場合の画像確認をＯＮにしていても、規定の時間を過ぎると自動的に切れてしまいます。
キャノンのカメラは、シャッターを切った場合の画像確認時間にホールドという項目があって、カメラと液晶モニターの接続を続けておく事ができます。
しかしながら、シャッターの半押しで、接続が切れてしまうと思われます。(液晶モニターの表示が消えるので...)

という事で、カメラ側がHDMI接続時に常時接続モードというものを搭載しない限り、この手の外部モニターを購入する事はないでしゅ。

なおそれ以外、ソニーのこの製品の液晶はとても綺麗ですが、
赤系統の色がまったくダメでした。
しかし、ソニー製カメラの背面液晶モニターと、この外部モニターを見ると同じ色味が表現されているので、
外部モニター自体のキャリブレーションは、ソニー製カメラの背面液晶モニターに特化されているようで、
他社のカメラでは色味に関しては、かなり不満足だと思えます。
なので、ソニーさんには、この液晶モニター単体で、色味の変更が出来る機能搭載を要望しておきました。
一応　輝度・コントラスト・色温度(3段階　9000K 7000K 6500Kくらい　正確には覚えていない)変更機能はありました。

-2月3日(木)-

WEB:

webAlbumのユーザ見せの所は終了。
小規模ユーザならこれで充分だと思う。

大規模ユーザ対応の所では、やはり注文書を作成する所までやりたい。
まあ、注文書(PDF)を作成するよりも、インターネット注文を作成する方が簡単だと思うけど...

とりあえず　各ユーザ毎の現在のマーク画像を一定期間（申し込み期間中）保存・復帰できる所を作る事にした。
その為の技術は
1.ユーザ認証　　　→　PHPでapatchが行っているベーシック認証が行えるので、それを利用。
2.ユーザ登録作業　→　MySqlが利用できるので、認証でなく独自のアカウントを作成できるようにする。
3.マーク情報の登録・復帰　→データに関しては、独自アカウト単位に登録・読み込み。現在のWebAlbumの連携自体は簡単。
4.注文書PDFの作成　→　基本アクセスはできるのでそれで対応可能だが...

一番の難題は「4.注文書PDFの作成」これに関しては、パソコン内であれば、自由にコントロールができるようなＡＰＩが公開されているので、
パソコン内に持ってこれれば問題はなさそう...
Web上でも自由に扱いたいなら、PDFlibというものが有償で売られているがお値段が企業レベルの値段で高い。
あるいは、注文書作成のフェーズで、マークした画像のファイル番号をテキストファイルとしてダウンロードしてもらう。
（この部分は簡単にできてしまう）
その後別途、そのテキストファイルを読み込むＰＤＦにマクロを組み込んだもので、読み取ってもらう。
（これならできそうだ...）

追記
ユーザ認証を調べてたどり着いたら
現在本サイトが稼働しているサーバ上では、PHPからapatchで実装しているBase認証をコントロールする事ができないという事がわかった。
PHPの組み込み方式には、cgi版とモジュール版が存在するのです。
大まかに言えば、cgi版はphpプログラムを動作させる時に一緒にphp本体もそれに対応して複数個動作する。
モジュール版は、apatchの一つのモジュールとして常に動作していて、phpプログラムが複数動作しても、本体は一個だけ。
本サイトが動作しているサーバ上でも一番値段の高い契約形態では、モジュール版が提供されているが、私の契約している内容では、
cgi版しか動作させる事ができない。

PHPでベーシック認証をコントロールできない事がわかった以上、最終的にはユーザ管理部分を制御する必要があるので、一気にMySQLを連携させてやらざるを得ない。 もちろん簡単に、ディレクトリィにapatchまかせのアクセス制限をかける事はできますが...
しっょぱなから　つまづく...

およよ
私の大得意のExcel帳票に関しては、PEARという無償のPHP上で動作するライブラリでアクセスできる模様。
所属レンタルサーバでも自己でPEARを入れる事で動作可能となっている。
しかもセル単位でアクセスできるじゃないですか！
な～んだ　もしかしてユーザを意識せずに　注文書をExcelで作成できる気になってきた。
よし方針大転換。
Excel帳票にしよう。サーバ上でファイルを一時的に作成する場合は、セッション変数を使って一意性を保って作成したらそれで済む。
Excelなら後でお客さんが自分でデータエントリも計算もできて便利。
もしかして、そのExcel帳票をメール送信してもらえれば、ちょっとしたプログラムを作る事で、注文書データのエントリー作業もしなくても良くなる。
見えたか！?
PEARだと認証も独自実装しているので、認証が必要な場合も行けるかも。

PEARの本を買ってこよう～っと。
今日はおしまい。

WEB2:

eclipseをパソコンに組み込んだ時に、PEARも基本的な物は組み込まれていた。
それでオプショナルなものは組み込まれていなかった。
勉強兼ねて、認証関係である　Auth　ライブラリの組み込みを行った。
EXCELに関しては、Spreadsheet_Excel_Writerを組み込めば良いらしいので、後日実施。
私にとっては、EXCELは超コアユーザなので、心強いでしゅ。

ほとんど最終的なデータベース構造の骨格も決めた。
もともと私は、昔OracleMasterGOLDの資格取得者なので、通常のデータベースの扱いなども全く苦にならない。
実装上は、MySQL。
よく調べてみると、世の中は進歩していて、プログラムからのアクセスでは、PEARのライブラリインタフェースが、
物理データベースの違いをある程度吸収しているんですね。

まあ～、昔勉強した知識を、カメラマンになって使うとは考えてもしなかった。
昔Oracle関係のドキュメントは沢山あったのだが、カメラマンになった時点で、
Oracle含めて商用インターネット構築技術関係の書籍は全て廃棄したのだ。

プログラムでの実装は私にとっては、どうとでもなるが、
環境構築の方で最終的なリモートホストの方がちょっと心配。

恐らく、Ajaxも使う事になるんだろうなぁ...

テストプログラムの仕様を決めて、テストプログラムを今週中に最低限ローカル（パソコン上）環境で動作させたい。
今度は、頭がPHPでいっぱいになりそうだぁ。
PHP と　VB と　JavaScriptを一緒に開発していると、さすがに細かい所で記述ミスをしてしまうのだ。

追記
ちょっとcssを変更して、<P>の箇所のフォント関連をいじってみました。

NIKON/AWB:

ニコンのＮさんに言った事がトリガーとなったのか、ある日突然、AWBの件で電話がかかってきたが...
その後、D7000がリリースされて、AWBにモードが二つ搭載された。
一般ユーザからすれば、この二つの意味合いを知る事はないだろうと思うし、プロの多くも首をかしげる人もいるのは確かなようだ。

この機能に関しては、NIKONは本質を理解して妥協点を搭載したものと思われる。

皆さん、デジタルカメラの性能の進歩に対してAWBが求められる質の変化を理解していません。
カメラ自体は高感度特性がどんどんよくなってきている。
昔、AWBと言えば基本的には、日中光源下での撮影主体で正しく動作する物を目指していたのです。
但しながら、その当時でも、室内撮影の多くで電球照明のような物に対しては、やはり従来フィルム写真を良しとして
その従来スタンスを守って、　それが写真としての　雰囲気描写　として位置づけて搭載したのですよ。
ところが、現在にいたっては、高感度特性が極端に良くなり、カメラのテイストでなく、カメラの写し撮る能力が顕著になってきた為に、
高感度＝雰囲気描写　ばかりではないだろう　もっとAWBとしては、白は白く表現されても良い　という価値が出てきたのです。
その為に、雰囲気描写＝従来フィルムカメラのテイストも残して、デジタルカメラでの表現の幅=人間の見た目により近いホワイトバランス表現
の二通りを搭載した。
というのが、現実解なのです。
単にカメラの性能の向上によって、より多く人達が求める表現の幅を搭載したという事が、多くのユーザにはわからないのですよ。

もちろん私が搭載方式を言ったのは、もっと拡張のある方式だったのですが、それを簡易な形式で搭載したのが今回でした。

-2月4日(金)-

PHP:

Eclipse + PHP + MySQL の基本的な設定確認をした。

------------------------------------------------------------------------
<?php
require_once("MDB2.php");
$dsn="mysqli://ユーザ名:パスワード@localhost/pear";
$option=array(
"debug"=>1,
"portability"=> MDB2_PORTABILITY_ALL);
$db=MDB2::connect($dsn,$option);
if(MDB2::isError($db)){
die("接続失敗".$db->getMessage());
}
print("データベースへの接続は成功しました");
$db->disconnect();
?>
-----------------------------------------------------------------------

これでとりあえず、PHPからデータベースの接続ができた。
Eclipseで実行時、php.iniの中にインクルードするファイル(ここでは MDB2.php)のディレクトリイを設定しているのだが、
有効となっていない。
Eclipse側のインクルードソースファイルという箇所に、上記ディレクリィを設定してやったら、正しく動作してデータベースに接続ができた。
これさえできれば、後は、プログラム上の話なので、どんどん進められる。

PHP2:

ムムッ。
色々と調査しているとPEARは、ちょっと古すぎの技術。
今やJQueryの時代なのか。
JQueryを勉強するより、自前で構築した方がトータル時間は少なくて済みそうな気がしてきた。
結局やる事は、以下の通り。

基本的には、
自分のHTML記述内で　認証画面を出す事。
そこで入力された情報を元に、サーバ上のMySqlの中身を探して検索して一致かどうかをやって、それを元のHTML(JavaScript)に返却するだけ。
PEARに関しては、MDB2が使いかってがよさそうなのと、Excelアクセスができるのでそれを使う事にした。
その他の認証機能に関しては、Ajx+MySqlで構築した方が簡単だと言うことがわかった。
とりあえず、Ajxで自分でプログラミングしてみよう～っと。

相撲界:

事実としたら、どうすべきか...
私なら以下の裁定を。

主文
公益法人として国民の期待を長期間にわたって裏切ってきた事及び昨今の不祥事の連続を考えると上場酌量の余地なし。
しかし一方で日本の伝統として貢献して来た事も事実であり、
連続した不祥事に対して改善対策が有効に働いている事も考慮せざるを得ない。
以上を鑑みて、
最低3年間の公益法人としての扱いを取り消す。
また1年間一切の興業の謹慎を申し渡す。
一時が万事と心得て全て0からやり直し、
国技としての相撲の永続性及び国民の期待に応えて、
再建に真摯に努力する事を期待する。

-2月5日(土)-

時の過ぎ行くままに:

As time goes by.
ある時、ウィスキーが似合うフランス風の夜のパブ。
そこにいたのはまだまだ若い20才の恋人同士。
レスラトンの片隅ではグランドピアノを弾き語りながら歌われる　カサブランカの主題曲。
もう　時は過ぎたのかも知れない。
タクシーの中　激情のくちずけ。
あまりにもはかない

-2月6日(日)-

Web/認証:

まずは順次テストする必要もありlogin用のユーザインタフェース部分を作成。
最終的にはAjaxで非同期通信させるので、JavaScriptで作成。
まぁ　こんなもんで　ええか。
PasswordはJava側(クライアント側)でMD5の暗号化できるみたいだが、それを送れば良いのかなあ。
イマイチ　セッションという役割がわからん...
これから、サーバとの通信部分のデータ送受信部分(Ajax)を入れるぞ。

健康:

走りの方は、週3回くらいが精神的によさそう。
8～9k/回走っているから、月100kくらい走っている事になるが、まずは3ヶ月続けたら。
次はスピードを上げなければならない。
3ヶ月というのは、人間の血液が一通り新しく一巡する時間なのよ。

朝走って、その日のお昼に踊ると、かなりしんどいから、当面はこのパターンはなし。
一日おきに
水・金・日
に走るのがどうも良さそう。
平日は、午前5時代でも、結構車が多いが、日曜日の同時刻は、やはり車は少ない。
日曜はランナーも少し多いが、今は東京マラソンが近いので、平日でも5時台に走っている人は数人いるし、
こんな時間帯に走っているのは、私以外は、かなりの走りに慣れている人が多いようだ。

日の出　70分前＝現在は5時30分　に走り出すと、ちょうど荒川の土手に走り始める時が、暗く、
土手の終わりで明るくなる感じで、ちょうど良い感じ。その間13分程度。
明るいと、逆に走りにくい。
今朝は、今期一番気温が上がっていたように思う。
途中で手袋を脱いで走っていても、手が寒くならなかった。
私の走りが終了した時から　他の人達は生活が始まる。
少し優越感がある。
但し　就寝はなるべく22時代に寝なければ、なかなかに4時50分には起きられない。

Web/認証2/Ajax:

クライアント部分とサーバ処理間をAjaxで通信処理ができる所まで　できましたぁ～。やったぁ～。

通信処理は、一番大切な所は、エラー処理部分だと思っていますので、Ajaxからのエラーと、今後来るであろう
データベース処理部分におけるエラーを考慮して、そこに関してはきっちり設計して作り込んだので、
時間がかかってしまった。

メッセージに関しては、現時点では少し遊びを持たしてこんな感じ。

クライアント側でできるデータチェックもばっちし。
今後、サーバ側から返却されるエラーに関しても、きちんとエラーが出てきます。
そして、きちんと認証されると　以下が表示されます。

これは現時点では、パソコン上でサーバを起動してサーバ・クライアント処理を実施してみたものです。
実際のサーバ上でも動作するハズです。
上記　LOGOUTを選択すると、再度最初の認証画面に戻ります。
全て　Ajaxを利用してやつているので、サーバ側処理で画面全体を書き換えているわけではありません。
サーバ側から受けたデータを解析して、正常処理ができた事を判断して、JavaScriptで、ブロックレベルのスタイル:Displayパラメータを
動的に変更させて、LOGIN画面とLOGOUT画面を切り替えています。

簡単な処理ですが、1日かかってしまった。
後は、SQL処理で問い合わせをする部分を作るだけです。

NAMEとPASSWORDでサーチする。
なければ、NAMEだけでサーチする　なければ、ユーザ名が間違ってる旨を通知する。
NAMEがあった場合には、PASSWORDが間違っている事を通知する。
という処理を作るだけ。
制御的には、セッション制御を入れる必要性がないようにも思うが...

上記までがローカルでできた時点で、実サーバ上でテスト。
それができあがった所で、基本的なシステムの基本が完了するので、その後ユーザ登録処理部分を作成する。
よく認証と言えば、apatchのベーシック認証があるけれど、そもそもPHPでモジュール版が動作しなければ、自分のＨＰでは利用できないし、
利用できたとしても、Ajax対応のものでもない。

自分で構築する方が簡単にできてしまう。

Web/認証3/セッション制御:

自分なりに想像してみた。
旧来のセッション制御は、確かに画面全体をその都度書き換えるようなクライアント・サーバ間通信では必要であったかも知れないが、
元々画面全体をリフレシュしないようなJavaScriptでは、必要性がなくなったとも思える。
今回の設計では、セッション制御は入れずに構築して、問題があればセッション制御を入れる事にした。

-2月7日(月)-

Web/認証:

ユーザ認証云々の件は、実は簡単なんだけど。
一番の問題は、あるディレクトリィに制限をかけておいて、ユーザ認証に合格した物だけ、アクセスさせる事ができるかいなかに関わっていて、
とても悩んでいのだが、結局、サーバのapptchの機能で、.htaccessへの設定でできる事になった。
要は、あるディレクトリィには、アクセス制限をかける。
アクセスできるのは、特定のプログラムだけ　例えば、当方のURLアドレスを持つ物だけ　という事ができるのだ。
→　既にテストしてみた。
それ以外のアクセス、例えば、直接ＵＲＬ指定で画像本体をアクセスしても、WEBサーバがアクセス拒否する。
これで、まず一通りの事は実施できる事となった。
Basicなユーザ認証に困っている人が多いと思いますが、この機能を使えば、どんな認証だって自分で構築できる。

追記
基本的には、自分で認証できるAP(HTML,JavaScript,PHP等)物は、全て個別DB認証を実施してから動作。
→　これは認証キー(ユーザ名及びパスワード等)がないと動作しないから　これで大丈夫
データそのものに関しては、上記特定アクセス制限を実施しておく。
→　データを直接触れないようにしておく事　及び個別DB認証されたＡＰからのみ動作するように許可しておく。
これで大丈夫だ。
後はSSLを使えば良いのだが、そこまではやる必要(直接　お金のやりとりをするわけではないので)はないと考える。
実は制限してしまえばSSLも利用できる。

Canon/200-400F4:

ついにアナウンスされました。
が...　違うんですよね～。
バレエカメラマンが　使えるか？
使えないです。

Canonにはこのレンズは作れない　否実質、製品になるものは作れないと思っていました。
恐らく、要望が高かったのでしょう。
恐らく　100万以上です。
もちろん　スポーツ限定なら使える局面もあると思いますが、(なんと×1.4倍が内蔵！)舞台では使えない。

というのも　フルサイズ使用でなければ、200mm付近が使えないのですよ。
これを使うとすれば、1DMark4しかないけれど、焦点距離が1.3倍となるのですよ。
まあ、5DMark2あるいは次の5DMar3　が候補となるかも知れませんが...
それでは連射速度や、寄りの写真としての必要性、シビアなタイミングが必要なものに対しては、数％撮れない領域があるのです。
使える　フルサイズがないのです。

また、使えるフルサイズが出たとしても、1Ds4なんて物は、恐らく超～解像度　3000万画素以上になるであろうが、
そんな物を必要とする領域ではないのです。

1DMark4N(フルサイズバージョン)が出れば、舞台撮影で使用できると思っていますが、
今更　どうなんでしょうかね...
まぁ舞台撮影なんて言う領域は狙っておらず、スポーツ領域なんでしょうけど。
あまりにも　先のオリンピックで、ニコンの200-400F4の活躍を苦々しくキャノン陣営が思っていたでしょうから、
スポーツ領域に関しては、これで追い抜けるような感じはありますね。

でもキャノンにこんな領域で、まともなピント精度を出せれるような物に仕上がるのでしょうか？
→　非常に　ギ　モ　ン

-2月8日(火)-

Web/認証/おすすめ:

昨日掲載した内容は、いささか通じなかった恐れがありますので、もう少しかみ砕いて記述します。
特に写真等のデータをWEBサイトに掲載している場合、掲載するプログラム＝HTML等と　その画像実体(jpeg等)があります。
画像実体もWEBサイトのどこかのフォルダーに集められている場合が多いのですが、問題なのは、そういう画像が無断でダウンロードや、
直リンクを張られて、他に使われてしまう事です。
そういうフォルダー名は、公開していないから他にはわからないよ　という方もいらっしゃいますが、その画像が掲載されているHTMLを
見れば、フォルダーはほとんど特定できてしまいます。
フォルダーが特定されてしまえば、一気に大量の画像のダウンロードも場合によっては可能になります。
また、たとえＨＴＭＬでそういう画像を使っていなくても、各検索サイトのロボット検索ツールに発見されてしまって、画像のみがそういうサイトに掲載されている
場合もあります。

とにかく、著作権で問題となるような画像に関しては、まず自己防衛する必要があります。
その為には、以下の機能があれば便利です。
1.他のサイトからは、そういう保護したいデータには、アクセスできない機能。
2.自分のサイトからは、自由に保護したいデータにも、アクセスできる機能。
これが簡単にできてしまいす。

設定も一回で出来ます。
「接続元のアドレス制限」というキーワードで公開しているプロバイダーがありますが、
基本的には、.htaccess　の設定でできます。
実際に使えるかどうかに関しては、所属プロバイダーのサーバ機能を調べてもらうしかありませんが、
大概、BASIC認証によるアクセス制限（ユーザ名/パスワードを入力してあるディレクトリィを保護する機能）が実装されている場合が多いので、
それと基本的には同じです。(.htaccessの設定が違うだけです)

設定は、
保護したいデータとして、画像などが納められているフォルダーを指定する。
また、許可したいサイトとして、自分のサイト全体を指定しておく。
これだけです。

実際には、ブラウザーの該当画像はダウンロードできてしまいますが...
直リンクや、直接そのフォルダーをアクセスするような事は、防御できます。
一応、私のこの日記サイトの画像に関しては、制限をかけました。
通常は問題なくアクセスできていますが、画像関係については、直接アクセスできないようになっています。

Web/認証/激疲れた:

今朝は、走らないのに5時前に起きて、朝ご飯を食べて、7時からプログラム設計から始まって、
一番の要であるlogin認証の箇所を、プログラミングして、全体的な考え間違いがないかを確認する為に、サーバを使ってスルーテスト。
スルーテストが終わったのが、途中2時間ほど休憩したが、21時。
激疲れたぁ～。

全く初めての命令ばかりで、テストもどう行っていいかわからず、それでもインターネットやら参考書を総動員して
なんとか、正常系のパスは通った。これで、ほとんど見えた。
しかし、PHPでmysqliを使ってテストするのは、慣れが一番重要だと思った。
いきおい　prepare →　excute →bind →fetch をやったら、もうほとんど、1行ずつのテストになってしまった。
でも、だいたいの感どころはわかった。

私の認証システムでは、認証がＯＫになると、認証した時刻が記録されるようにした。
間違ったパスワードなら、最後に間違ったパスワードを平文で記録しておく事も可能。

今回 pearを使う予定だったが、一番の根幹部分だったので、なるだけオプションナルなモジュールを入れずに
構築する事を心がけたので、標準のmysqliを利用する事にした。アクセスの仕方は、オブジェクトプログラミング。

これで、明日は、現在動いた部分をいよいよ、実機サーバ上に移して、稼働確認をする。
それで問題点を洗い出した後で、残り部分の設計と製造を行う事にした。
だいたい、技術課題はクリアーしたと思う。

しかし
JavaScriptとPHPの両方をまともにプログラミングできる人がいるのか、プログラム自体はそれほど難しい事ではないのだが、
その周辺技術を知って　プログラミングするとなると、結構この手の熟練者でないとダメなような気がした。
私の場合は、これにVBとPhotoShopとillustratorも外部コントロールできるし。もう何がなんやら...

-2月9日(水)-

健康:

右足の親指の付け根＝足の中心部が、痛くなる率が高い。
困ったもんです。
現状のジョギング程度では問題ないのですが、例えば、バレエで右足軸でデリエールアチチュードして、プロムナードで
少しずつ回転する時には、時として　ツーと来る事があります。

今朝は、小雨の中走り出したら、途中で結構降られてしまった。
荒川土手の上では他のランナーは一人だけ。そのランナーも途中で切り上げたみたい。
いつもは何十人もいるお年寄りを中心とした散歩者も、数人程度。
フード付きの上着なので特に問題ないのだが、靴があまり水に強くないので、最後には、
足先の方が濡れた状態になってしまった。

WEB/認証:

ローカルサーバで充分テストした認証モジュールをレンタルサーバに上げて、MySQL上にも認証用のテーブルを作成し、テストをしてみた。
一発で全ての機能が動作した。
お～～。
現在発売されているどんなWeb関係の本にも　認証をAjaxとJavaScriptを利用して構築した例は、まずない。
きちんとローカルサーバ上でテストした機能が、そのままレンタルサーバ上でも動作して、はっきり言って少し驚き。
PHPでまともなプログラムを作成したのは初めてだが、認証モジュールなのでかなり頑強に作ったつもり。
要は、認証するパターンを極力小さくする事が必要でかつ、認証できなかった場合にも、その情報を提示するように工夫した。
サーバ上だとさすがに少し認証に時間がかかるようで、ほんの一瞬だけ、途中で待っているメッセージが出るが、これは消した方が良いかなぁ。
一応、認証中はマウスカーソルを時計マークにするよにしているから、これで良いか...
パスワードも暗号化したし、ユーザ自身がある条件を満たせば、自分でログインアカウントを作成できる機能も入り込んだ。
そして、認証以上に大事な　写真選択した情報を認証ＤＢに保存したり再読み込みたりする基本的な機能も入れ込んだ。
これで、実機サーバ上でのテストも出来たので、認証モジュールを、各プログラムで動作しやすいように、機能分割する。
その後、必要な箇所に取り込みじゃ。

今回わかったのは、HTML(JavaScript)からPHPを呼ぶ所は、内部的には通常のインターネット上の呼び出しをしており、
当面テスト段階なので、GET方式でパラメータを渡しているが、Ajax通信だと画面が切り替わらないので、
そのパラメータもブラウザーのコマンドラインには現れて来ないのです。
もちろん、最終的な実装では、PUT方式に切り替えますが。
但しながら、サーバ上で動作させた場合、直PHPを呼び出す事ができなかったのですが、そんな仕様なのかなあ～。
なぜなんだろう...

-2月10日(木)-

健康:

昨日走ったので今朝は走りの予定ではなかったのですけど、目が覚めたらやっぱり5時前だった事と、 天気予報を見るとどうも明日からは大荒れの天気との事で、今朝もランニング。
今朝は、風があって、なかなかに厳しい。
荒川の土手を走っていると、散歩のおばさん達も寒い～っと言ってた。
やはり2連チャンで、1時間クラスを走ると、体力的に厳しい...

JavaScript/スコープ:

ある本を読んでいたら、どうも解せない解説があったので、自分で再度テストしてみた。

変数のスコープのテストです。
さて結果は、a=OUT b=IN c=OUT d=IN となりました。
aに関しては、関数内部で、aをvarを使ってデータ定義しているので、関数内部のaはローカル変数となります。
bに関しては、関数内部で、bを明示的にデータ定義していませんので、グローバル変数を使っている事になります。
cに関しては、関数内部で、cををvarを使ってデータ定義しているので、関数内部のcはローカル変数となります。
dに関しては、関数内部で、dを明示的にデータ定義していませんので、グローバル変数を使っている事になります。

以上をまとめると、関数の外でvarを使う・使わないに限らず使用された変数は、その内にある関数の上位のグローバル変数になります。
関数内部では、varを使って定義すると、それはその関数内部でのみ使用できるローカル変数となります。
極普通です。

認証モジュールに関しては、今後色々なアプリケーションで簡単に使えるようにモジュール分割/機能分割して、だいたい80％くらいはできた。明日はひさしぶりに撮影の仕事なので、しばらくこのプログラムはおあずけ。

マルチタスク度:

中高校生くらいの時は、数学の問題を解きながら複数人と話をするなんて事は、普通にやっていた。
ただし、その頃でも友達から言わせれば、おまえはお釈迦様かぁ～　と言われたこともあったが、誰もが普通にできる事だと思っていた。その友達のマルチタスク度だけが、少なかったのかも知れないと思っていた。

しかし最近は、マルチタスク度は　ほとんど　1。
要はシングルタスクでしか物事が考えずらくなってきている。
ある意味集中度が高まっているとも言えるが、確かに歳とともに脳みその傾向は変わってきているようだ。

子供達はゲーム機を扱いながらも、人としゃっべっていられるのは、彼らにとっては普通なのだと思う。
大人の感覚で、一つの事をやっているからと言って、他の作業がおろそかになるわけでは多くの場合違うのだ。
まぁ、ゲームをやりながらとか　携帯を操作しながらとか　別な作業をやりながら他人と会話をする事が他人の話が聞こえている聞こえていないは別に、礼儀的に失礼になる事を子供達に教えなければならない事ではある。
が、現代ではそれを教えていない親が多すぎないだろうか？

Web/認証:

今カレントにやっている作業は、認証モジュールの共通ルーチン＝汎用アクセスルーチン＝ライブラリ化という事をしているけど..
元々私は、昔ソフト開発の中でそういう事ばかりやってきたので、そういう事は、得意中の得意な事だと思う。
今は手続き指向的な物だけど、第2版はオブジェクト指向ライブラリにしようと思っている。

-2月11日(金)-

参照元によるアクセス制限：:

何度も言っているのですけど...
例えば実験です。

OUT1.アクセス制限なしのサイト　→　IN1.アクセス制限ありのサイト　→　IN2.アクセス制限あり　のサイトにリンクを張ってあります。
それぞれの写真をクリックをすると、次のサイトへのリンクが張ってあります。

まずは、OUT1をアクセスして順次内部の写真をクリックしてみて下さい。
そうすると、上記の順番にアクセスできます。
とっ　ところが、上記のIN1やIN2に直接クリックしてみましょう。
アクセスエラーとなります。
上記で言えば、アクセス制限ありの領域内部にある(IN1,IN2)は、アクセス制限なしの領域にあるOUT1　のみを許すように設定しています。
そうすると、OUT1からIN1にはアクセスはできて、その時にアクセス制限ありの領域に飛び込む事になり、以降は自由にアクセスできています。

これは例えば、自分が公開したいメインのＵＲＬは自由に設定できて、かつ、そのＵＲＬが参照している自分の内部のサイトに関しては、
直接はアクセスできない事を示しています。
必ず、公開しているメイン窓口となるＵＲＬ経由でないとアクセスできない事になります。

ここで、窓口となるＵＲＬに認証という機能を付けて、それにパスしなければ以降のサイトを見せないようにしておけば、
自分の見せたい人にだけ見せられる機能を作り上げる事ができます。
但し、運用に関しては、かなりきちんと考えておかないと難しいです。

しかし、例えば本日記サイトも、この日記本体箇所をアクセスできるのは、自分の上位のＵＲＬと、例えばmixiアドレスからのみ
というように設定しておけば、他から直接この日記は見れなくする事が簡単にできます。

-2月13日(日)-

D3S/D7000：

先日D7000を実践で使ってみたが、D7000だけを使っている時は全く感じないのだが、
D3Sと比較するととても小さくコンパクトカメラという感じ、シャッター音に関しては（恐らくシャッター音が良くなかったらこのカメラも買わなかっただろうと思うが） とても良好。音が小さいのも良いのですが、その音が小さく音の質が良いし、それとあいまってシャッターの振動音も手にも気持ち良い。
この1年間でニコンさんには、AWBの品質の悪さを言ったが、それもある程度改善されたし、AUTOモードにも特に高感度領域での設定のされ方もモードが一つ増えた。
また、CameraControlPro2の画像表示がおかしい件で要望を言ってたら、独自のビューを止めてViewNXを介して表示するようになりこれも改善された。以前まではDPPの方が使いやすいと思っていたが、少なくとも写真を撮って即パソコンに取り込んで確認をするというパターンでは、DPPや場合によってはCaptureONEproさえも越える使いやすさになったと思う。

通常は上記の形。

不要な物を省いてこういう形も。
更にこのモードはボタン一発で、物理画面全体にまで大きくなるその場合は、ウィンドウ枠もない。
特にノートパソコンなどでは重宝します。

更に、画面上の一点をクリックしている間だけその部分の等倍拡大が表示されます。
ダブルクリックは等倍拡大への移行。
ピントの確認も簡単です。

上記ハードコピーは色の関係で変換してしまっているので、画像の正確な表示はこちら。
私のように舞台撮影時にパソコンに直接データを保存しているという使い方には、とても重宝します。

-2月14日(月)-

健康：

今朝は走る予定だったんだけど、一旦4時50分に起きたものの、起きれず。
疲れがたまってる。
再度寝て、7時過ぎに起床。
プリンタのインクが切れたので朝一で秋葉ヨドにインクを購入しに行く。
ソフトウェアを売っている箇所にはコンピュータ関連の本も売っているのだが、およよ。
ここの品揃えは多分天下一品！
全ての書籍があるように思う。
PHP+MySQL　関係の本を1週間前なら欲しかったのだが、既に勉強したのでいらず。
但し、画像そのものをMySQLに出し入れする方法も掲載されていたので、近々に買うかも知れない。
とりあえず、Apatchの書籍を一冊購入。

BX-310:

BX-310を購入してから時期同じくして閲覧ソフトを開発などしていたので、結構印刷したつもりだが、インクが全く減っちょらん～。
メンテボックスの方は最初のインクの初期充填の時に結構使ったきりだと思う。
インク1本で約3000～3700枚くらい印刷できるようです。
個人で会社を作って仕事をするとなると、やっぱり色々と文書関係を印刷する必要があったり、お客さん用に色々な印刷をする（ラベルや封筒等）上でも、こういうプリンタはとても良いです。全く紙詰まりもなく、インク詰まりもありません。

雪じゃ:

-D3S/ISO1600-

ゲッゲ。
明日の朝は走ろうと思っていたのに。
これじゃ～　無理無理。

-2月15日(火)-

WebAlbum：

WebAlbumの方は一部実践稼働。
認証の方はほぼできているが、WebAlbumに組み込み開始。
Excel帳票を作る件。
調べて見ると、新規に作る事は簡単にPEARライブラリでできるようだが、既存帳票を読み込んで処理する事は、難しいらしい。
一部読み込み用のライブラリもあるが、Excelのバージョン制約もあり評価してみてからになる。
新規に作成する方に関しては、かなり細かくセル単位で制御ができるようだ。
思いついた。
私には、以前Excel帳票からillustratorに変換するプログラムを作った経歴がある。
その時は内部的に、Excel帳票→中間言語→illustrator　という方式を採っていた。
これを流用すれば、中間言語からPEARライブラリ言語を用いて、既存帳票に対して新規帳票を生成するPHPプログラムを生成できると思う。
これわ！ス　ゴ　イ。

WebAlbum/tableタグ：

tableタグは昔からレイアウトデザインでも使われてきましたが、少し凝った使い方をすると、直ぐにそのレイアウトが不安定になります。
IEの場合は思った通り教科書的に動作しますが、table内の要素をある時に表示させたり/消したりした場合には、その他のブラウザーではそのレイアウトが崩れてしまう。動的な変更にtableデザインは耐えられない。これは、以前も経験した事がある。
tableデザインでなく、divなりのブロックで固めて、cssデザインに変更する必要あり。

-2月16日(水)-

バレエ/ピルエット：

相変わらずですが...
よく首を残してとか、首をつけて回るとか言われていますが。
首だけを考えても付く場合もあれば付かない場合もあります。
もう少し詳細に言えば、首が付くような身体使いでなければなりません。
そういう言い方で指導される方は0ですが...
首が付く回り方が正しいのですが、自分をかなり分析していて、首があるラインがやはり、軸足の延長線上でなければならない。
特にアンデオールピルエットの場合、プレパレーションの足4番の位置が多くの場合、4番に入っておらず1番側にずれている為、
そのまま回転の元で立つと、後ろ足側＝パッセがきちんと5番に入らない。
その為に、ズレたバランスの箇所で回る為に、身体が入らない＝正確にバランスの取れた箇所で回れない
というのが、私の理論だ。
なので、昨日は、少し後ろ足4番をもう少し深く5番側に入れ込んで、回ると...
もちろんこの時におかしやすいのは、プレパレーションの重心が逆に、前足と後ろ足の中心になり易いという事。
このままでは、幾ら立っても、今度は重心が後ろ側に行きやすい。
よってまとめると、
・4番は少し深め
・プレパレーションの重心は、軸足の少し前側。
・あくまでも中心は、軸足を中心として、その中心を上で伸ばすのような形で立つという事
これらを考えると、回転し始めた時に、どうしても立たざるを得ない限界点が出てくる。
その限界点までは、首を残しておいて、クイックに立って、クイックに一回転目の首を返すという事が、
意識しておくだけで、自動的に首が付くようになる。

昨日は、レッスン終了後に1回だけ自分で納得の上記通りのピルエットが回れました。

CSS：

最近cssの使い手になりつつあるので、日記の箇所も色々と遊んでいます。

Tabelタグで作成していた汎用login画面をTableを使わずに<div>タグのみで再構成してみた。
めちゃめちゃしんどかった。
formタグを入れずに最初にデキタ～っと思って、formタグを入れるとデザインが崩れてしまうし。
もともとformタグというのが、cssが設定される以前からあったものなので、デザイン的にその動きは非常に怪しい。
なんちゃない構成ですが、実際問題このように作るのは結構難しいです。
半日もかかってしまった。
デザイン要素をJavaScriptでコントロールするのは簡単だが、デザインそのものがcssレベルで正しく動作しない。
意味解釈の相違があるようだ。
これでやっとプログラムの最終版に取りかかれる。
画面の変更部分は、オブジェクト指向のクラス(ライブラリ)を作る事にした。
そういえば、色々と調べていた時に、
特にformタグの中でよく使われる　name属性。
これはcssの世界では使っては非推薦なのらしいし、最終的にはなくなって行くものらしい。
という事で、id属性で作りなさい　という事らしい。

CaptureOnePro6.1：

ニコン製カメラの場合通常では連結撮影ができなかったのですが、問い合わせ所、連結撮影モジュールを互換性プログラム動作　VISTA SP2モードで動作させてくれ。という事でやってみたら、動作しました。
しかし　これってどういう事なのよ？
という事でメールしました。

無茶な宿題：

小学生に対して外国語教育をする事が決定されたそうだが、それを教える教員がいないらしい。

それを聞いて、英語教育の事を思い出した。
私は小学低学年の頃、クラスで１、2を争うほど超成績が悪かった。
またマジで自分でも頭がバカなんだと思っていた。
それでも小学高学年になる頃に学習塾に通わさせられた。
自分の事は自覚していたから常に他人の2倍勉強して人並みという思いを持って勉強した。
2倍以上自分は勉強していたつもりでも、自分のバカさ加減はそれでも人並みだろうと思っていた。
学習塾では6年生の時には英語学習が始まっていた。
スタートラインはみんな同じ。
必死で勉強した。というかここで遅れるのはイヤだと思った。
中学生になって英語が始まった時には、既に中学1年生の英語は全て学習し終えていた。

中学1年生の初めてのテスト時、英語の試験を解く時震えた。
自分にとっては満点は当然。
それでもミスが多くて、90点も取れなかった。
それでもっと勉強した。

その次はクラスＮＯ1。
そのおかげで、中学生から大学卒業するまで英語成績は常にトップ成績という快挙を成し遂げた。
中学生の頃は、試験の回答合わせの時に先生が、私の満点答案をとって回答合わせをする時も何回かあった。
それでも満点というのは、英語に関してはなかなかにあり得ない。
中1の頃、満点とって当然の私がミスするのは、発音の箇所。
それが嫌で、全ての単語の発音記号を覚えた。
それから、満点がとれるようになった。

中学2年生の夏の宿題。
こんな宿題あるのでしょうか！
「中学1年生の時の英語の教科書の本文を全て覚えてくること！」
私はそれを聞いても、別段奇異とも何とも思わなかった。
全て覚えた。

もちろんその宿題をやってこれたのは、私ともう一人の競争相手の女の子だけ。

誰でも若い頃は、なんだってできる可能性があるし、大概その才能は花開く。
ただしながら、その才能の開かせ方には、周囲の環境やチャンスがかなり大きく作用していると考えざるを得ない。
本人が好きというのは根本だが、それ以上に本人がやらなければならないという自覚が
より幼少の子供にとっては、一番その才能を開かせる事なんだと思う。

私、中学生の頃に既に英語の文法に関しては大学英文科以上の知識でなく、力があったと思う。
全ての慣用語句に対しても、全ての語句の生い立ちから理解しなければ納得できなかったので。

-2月17日(木)-

機会損失は首！：

アップルはiPadなど普通に考えれば誰もが思いつく物を製品化してヒットしている。
日本の各メーカは技術力があるのにどうしてこういう　誰もが思いつく物　を製品化できないか。
アメリカは個人の力が大企業の方向性を変えて行ける風土。
悪くも良くもそれがアメリカ企業の基本だと思う。
一方日本社会の大企業の方向性といのうは集団意志の一致する所。
そこには奇抜性・進取の気性はどちらかと言えば乏しい。
唯一個人の発想力が企業を動かしている世界は漫画の世界。
一人の作家パワーが世界をも動かしている。

個々の問題は幾らでもあるが、一つは経営責任者の問題。
私が日本企業のそういう会社の筆頭株主であれば、　誰もが思いつく物　を製品化を一番にしなかった事
すなわち機会損失を招いた事は、ひいては利益損失と同一だととらえて責任者は辞任。

という事にしたい。
そういう体質にして初めて経営者は自社内や客の声にセンシティブになりユーザ指向の製品化が出来ると考えている。

客の声を大事にするというのはとても慎重に考えなければならない。
沢山の客の要望が必ずしも真の声ではない。
客の中で真実の声を持った者が少なくいるのだがまずそういう客を大切にしなければならない。
もちろん客の声を全て分析して次期製品化に結びつける部署があって当然のことではある。
この考え方はもううん十年も前の世界的超大企業のユーザビリティの論文に書かれていた事ではあるが、その重要性など日本の企業は誰も何も言っていない。

もちろん某カメラメーカなどは品質問題を引き起こしてそんな所に目が行くはずもないと思っているが。

人に物を聞く時わ：

今やインターネットの世界
わからない事は単語を並べて検索をかけるだけで大概の事は自分で調べる事ができる。
それでもわからない事というのは非常に少ない。
人に知識的な事を聞く場合は
自分で色々調べた結果　こういう事実とこういう事実を得て、そこから類推して、こういう事をやってみた。
と聞くのが通常。
そういう自己努力をせずに人に聞くというのは　ナシ　なんだけど。

写真教室/新藤事務所：

いつもお世話になっているプロカメラマン　新藤さんがご自身のスタジオで写真教室を4月より開催する事になりました。
商業カメラマンです。
毎週土曜日開催で、初級・中級者応募です。
写真技術も含めて写真に対するプロの感性的な所もじっくり味わえる良い機会だと思います。

WEBアルバムの観点：

Webアルバムの中にはデザイン性をメインにした物もあるが、発表会メインのアルバムにはデザインは最低限だと思う。
それよりも必要なのは、場合によったら1000枚以上の写真の中から自分の写っている写真を素早くアクセスできる事。
また自分が写っていない写真に関しては、斜め見で　ざぁ～と見れる事。
更に、自分の写真や気に入った写真に関しては拡大して見える事。
とくにかく高速性が必須条件。

一部他のサイトなどで公開しているようなインデックス画像をとりあえず全部読み込む　なんて事はネットワーク環境やパソコン環境によっては（キャッシュされる画像がパソコンのＤＩＳＫを使って遅くなったりする）問題になったりする場合が多い。
よってインデックス・サマリーも1画面に表示できるサイズをリミットとして後は、ページ単位でアクセスするのが良いと考えている。

認証/テスト/safari/window.open：

ローカルサーバ上で認証モジュールのほとんど最終版を評価しているのだが、
ちょ～困った。

window.openで開くはずのwindowがSafariのみ　それも簡単なアプリから開かない。
IE / FireFox /Chrome 問題なし
Safariでも他のアプリケーションからは、問題ない。

全くわからず。
ハングアップしているわけでなくwindow.openの戻り値そのものが、エラーとなっている。
いったい何者？？？

インターネットで調べてみると過去によく原因不明でエラーになる場合があったそうな。
ほとんどの場合は原因不明。

追記

正確な原因は不明だが。100％再現するパターンと　100％正常終了するパターンを特定できた。
と言っても、その両者にwindow.openパラメータの発行の仕方は同じなのだ。
しかし　二つのプログラムで、共通の一つのプログラムを呼び出すと、一つはエラー、一つは正常終了。

但しながら、正常終了する方が問題なのかも知れない。
というのも、Safari上でどちらも「ポップアップウィンドウを開かない」としているモードだと上記現象だが、
「ポップアップウィンドウを開かない」を外すと、どちらも正常終了した。

非常に不可解な現象である。
どちらも　10行程度のプログラムなので、更に絞り込んでみたいと思う。
Windowパラメータでなく、自分自身のそれまでの命令の発効の仕方に影響を受けていると思われる。
しかし　こんな事があるとまともなJavaScriptは組めないと思う。

----------------------------------------
function f_childopen(){
w_id = window.open("testpliechild.html","child",c_openopt);
if(w_id){
id_msg1.innerHTML = "子供を起動しました";
}else{
id_msg1.innerHTML = "***子供起動　失敗***";
}
}
addListener(window,'load',f_init);
function f_init(){
id_msg1 = document.getElementById("msg1");
addListener(id_msg1,'click',f_childopen);
f_childopen();
}
----------------------------------------

エッセンスを集約しました。
「ポップアップウィンドウを開かない」モードに設定していた場合
上記は、onloada直後にf_childopen()をすると、window.open時にエラーになります。
但しその後、msg1領域をクリックして、f_childopen()をすると、正常に起動されます。
これは、たまたまわかった事です。
どうも非常に仕様の不可解な件です。
実際のプログラムではもっと複雑なので、window.openをしている箇所の特定的なパターンはわかりません。
これをプログラム的に回避する手段はありません。
一応回避手段を講じているような例を見ると、window.openがダメだった場合には、hrefでリンクで飛ばしているような記述です。
これでは、全くwindow.openしている意味合いがないので、回避策ではありません。

「ポップアップウィンドウを開かない」モードをユーザでＯＦＦにしてもらうしかありません。
そうなると、「ポップアップウィンドウを開かない」モードにしていても、正常にポップアップが出てしまうのは、どうなんでしょうか？
という　わけわからん疑問が出ます。
結局、「ポップアップウィンドウを開かない」モードは仕様バグを含んだインプリメントのままになっているとしか理解できません。

なお、Safariでは　規定値が「ポップアップウィンドウを開かない」モードになっている割には、Safariのサイトを見てみると、この状態だと重要な情報が見れない場合があります。
としています。ユーザは、この事を充分に知らなければならないという事ですが...

一応プログラミングの方からは、エラー事象はとらえる事ができるので、その時には「ポップアップウィンドウを開かない」モードをチェックしてもらうようメッセージを出して促すというのが、正しいプログラミングの対応の仕方になります。

このような回答をしているサイトは、私が調べた限りどこにも書いていませんでした。

これでほぼ　認証テストの方も　ローカルサーバ上では全てできあがった。

-2月18日(金)-

WEB/閲覧：

一応認証モジュールに関しては全て開発が終了。
認証される子供の方は、アクセス制御される領域に置くので何もしないでも問題ないが当面何があるかわからないので、強固な自己認証機能を入れて対処する事に設定してある。
強固な自己認証とは自分で認証ＤＢに問い合わせをして動作可能かどうかを判断したり、アクセス制限領域外でも直起動された時に各種防御をするようにした。それらをたった１行で可能とした。

来週はおしりに火がついた年度末報告書を仕上げて税務署対応する必要があるのでしばらく開発関係はストップ。
3月に入ってから新閲覧ソフトの見直しと認証機能の組み込み、選択した画像のDBへの保存・復帰機能の組み込みを実施する。
まぁこれらは、全て基本部分は完成しているので、組み込むだけで動作できるようにしてある。

ローカルサーバ上でテストすれば後は、実機サーバにアップロードするだけで全て動作するのを目的として、
開発環境としてローカルサーバ上で実機サーバ環境を完全にシュミレーションできるように環境を整備する事にした。

なぜこんな事をしているか。
200人発表会レベルでは、紙焼きの選択見本だけではユーザにとって物理的な閲覧制限が発生する事が予測される。
また注文書に2人に1個の注文ミスがあったとしたら全体で100個のミスとなる。
100個のミスの修復作業は個別作業となってしまう為ユーザ・主催者・当方にしても大変な事になる。
その為にはそのミス確率を減らす方式を考えておくのは当然の事だと思う。
写真には舞台の演目順で番号が振られる。
ユーザはあれやこれや選択する時に、その閲覧順に写真を選択するとは限らない。
写真にかける費用の制限もあるかも知れない。
その為一旦欲しい写真をセレクトした後に再度見直しをかけて削除したり追加したりして最終的な注文をするのが一般的である。
そうした場合にミスが発生する可能性が増大する。
人によっては別紙に一旦書いた後に注文書に清書する人もいる。
しかし、この事も現場を考えると、紙焼き選択見本はお教室現場にある。
そのお教室現場でも、一旦メモ用紙に書くにしても、そういうメモ用紙自体をあらかじめ用意して持参する人など、そこまで気を回す人はいないのが普通である。そうなると、勢い注文書に書いて注文書上で追加や削除等の変更作業をやると、書き損じも含めてミスのでる可能性が出てくる。

場合によっては同じ写真を選択したり、番号の読み間違いで存在しない写真番号を注文したりもする。
そういう注文を忠実に注文として受けて処理するというのも良いのだが、私の心情としてはあくまでもユーザの立場にたって、ミスと思われる箇所は指摘を行いたいし、これまでもそうやってきた。

今回作成した閲覧ソフトを使えば、写真セレクト時の追加や削除は自由に高速にできて、かつ最終的には写真番号順に一覧が表示されるので、書き損じは防げないが（帳票の自動生成をすれば　これも防げる）重複注文も、ない写真番号の注文も、期待しない写真の注文（再考時の削除忘れ）等のミスを防ぐ事に大きく貢献できると考えている。
もちろん注文納期の短縮も可能である。
注文納期の短縮は、主催者が発表会後にかける工数削減の意味でも大切。

たかが閲覧ソフトだが、閲覧ソフトの意味合いを考えれば、その機能が変わってくるのです。

今回参考にした書籍。
新規に購入した本だけでもやっぱり2万円くらいかかった。
こちらの知識度に対応して一つで充分というのはない。
入門書レベルの本と　本質を書いた本と　知識インデックス（辞典）
の3冊くらいがどうしても必要だと思う。
WEB上で各種情報は得られるけど、やっぱりWEB上の物はトピックス的な利用にならざるを得ない。
体系的な箇所は書籍。トピック的な項目に関してはＷＥＢから　というのが全うな勉強の仕方だと思う。

-2月19日(土)-

WEB/閲覧：

全てのプログラムの呼び出し関係を相対パス指定にできるようにし、ローカル開発環境と実サーバ環境で同一のソースで動作するようにプログラムを全て見直した。
またクロスサイトスプリクト対応で各種プログラムも見直した。
関連事項として　JavaScript　が動作しない場合には、その旨の表示と共に以下サイトへの誘導を行うようにもした。

動作環境の提示

商業的なサイトを構築する場合、JavaScriptを利用しないでサイトを構築する事はほとんどないし、実際問題構築不可能と言っても良い。
しかしながらJavaScriptが利用できない場合に、どうなるかを明示しているサイトというのはとても少ない。
明確に、<noscript>タグの指定をしておいた方が良いと思う。
当方のメインのサイトには全てそういう仕掛けを入れておいた。

-2月20日(日)-

会社/仕事：

仕事について
私は会社の為に全力を挙げて仕事しています。
とか言う言葉を聞く時がある。
私からすればとても歯が浮くフレーズに聞こえて仕方ない。
何々の為にという言葉、それは裏返せば、
他にやりたい事はあるのだけれど自分がやらなければならない事の為にその他の事は犠牲にしている。
というように聞こえる。

私は自分の為に自分の仕事をしている。
犠牲にする事は何もない。
全ては自分の為である。
こういう事でなければ全力は出ないでしょう。

会社を創業した人達は会社の為にがんばるなんて事は言わない。
あくまでも自分が心血を注いだ会社で自分の分身として全力を尽くしている。
それだけなのだ。
その為には利益度外視の所もある。
会社が利益の追求と同程度に社会貢献する使命があるのは、
人間がこの世に生まれて来て他の人に貢献するのが基本と一緒である。

私が大企業の社長であれば
新入社員の企業面接の時に
会社の為に何々　という人があれば　却下します。
そんなものどうだって良いし、裏を返せば会社の為に犠牲にする他の物があるという事を言っているのと同じ。
それよりも、明確に自分自身の為にこの会社を選んだ、せーいっぱいこの会社で人生勉強させて欲しい。
そういうスタンスの人の方がよっぽど素直で耐性があると思える。

カメラ/辛口コメント：

毎月20日はカメラ雑誌の出版日。
昨日もざっ～と立ち読み。

その中で70-200mmクラスに対して三脚+手ブレ補正ＯＮ/ＯＦＦのテストがあったけど。
評価者も1行だけコメントはあるものの、評価としてかなりイマイチ。
ニコンのレンズに関しては、旧世代レンズで三脚手ブレ補正が有効な機種を使っていない。
本来であれば、三脚手ブレ補正が有効な機種の評価も入れないと評価になっていないと思う。
一部のカメラメーカが説明書で記述している内容を評価しているだけで、最新カメラ・レンズでの評価がされていない。

ユーザの知りたい事の半分しか言っていないと思う。

BX-310：

2万9千8百円のこのプリンタ。

写真画質以外のビジネス文書系統のプリンタだが、私としてはお気に入りの一つ。
しばらく使ってきたが。
再度マイナス点のみを以下に書いておきます。

フチなしプリントができない

フチなしプリントができずマージンが3ｍｍとられます。
まあ～写真を印刷するのでなければフチなしプリントの必要性はあまりないかも知れませんが。

大容量給紙カセットにセットする用紙の種類が限定されている

このプリンタでビジネス用途で一番品質の高い用紙が、インクジェットコート紙なのだが、それが650枚セットできる下段の大容量給紙カセットに非対応。
薄い用紙なので恐らく紙詰まり等を考えた場合に不適当なのだと思う。
しかしながら通常使う分には特に問題はなさそうなので、まぁプリンタお勧め標準を無視して使えばそれで済むが。

まぁ　これくらいです。
筐体がいかにも何のストレスもありません。

そうそうよく地図を印刷するのにグーグルの地図検索してその中から印刷するのですけど、
いつからかわからないけど、地図を印刷すると、地図の真ん中に十字のフロータマークが印刷されるようになったんですけど...

アクセス制限/window.open：

やっと出来たと思って実機サーバ上でテスト。
第一優先ブラウザーのsafariでは全てが設計通りに稼働。アクセス制限も完璧。
とっとっ　ところが、IEではアクセス制限サイトに入る事ができない。

許可されたサイトからのhref属性の飛ばしや、<a>リンクなどでは問題なくアクセス制限サイトに入れるが、window.openでは入れない。

結局、どうもIEではセキュリティ対策の為に、プログラムでコントロールするようなwindow.open時には、ブラウザーがサーバにREFFERつまり元のアクセス制限元の情報を送らないらしい。
悪意のサイトでは、自分のサイトのREFERを偽装する事で、他人サイトに入ってセキュリティを突破するなどかあったそうだ。
→　という事は、最新のSafariとて　安全面ではセキュリティホールがある事になる...
その為、サーバのアクセス制限＝リンク元がどこから来たかが正しく認識できずに、エラーとなるようだ。

ゲッゲッ。アタァタァ～。

準備段階で激調べて設計したのに！
但しながら、Window.open時にURLの実体部分がアクセス制限領域にあるとダメなので、window.openで開く.htmlやら　.phpなどを、アクセス制限領域から出してやれば良い。
実際に保護すべきは、私の場合画像データそのものなので、データに関してアクセス制限をかけておけばそれで済む。
そして、参照するツール自体には、元々DB認証を全て入れ込んであるので、それで制限が行える。
　プログラムとして動く物→DB認証
　プログラムとして動かない物　→　システムのアクセス制限
という割り振りで考えるしかない...

しかし、金さえあって、高額なサーバと契約できれば、ユーザ認証のアクセス方法とＤＢを使ってベーシックにプログラムが組めるものを！
という事で公開する時の、ディレクトリィを少し検討すればとりあえずなんとかなりそうだ。

そうそうそれと共に　奇妙な事にぶつかった。
ＨＴＭＬには、<body>属性があるのは当然だと思っていた。
ところが、なんの事はない、frameを構成するHTMLには、<body>がないんですね...

健康：

先週は1回しか走れなかったし日曜日夕方は雨かも　という予報だったので、
朝気合いで走って来ました。
1時間3分。
これでも　結構　トット走ったつもりだが。
やっぱり最低1日おきくらいには走った方が走るリズムが一定になる。

今朝は、湿度が高い分それほど気温が低くはないものの、走ると少し汗をかいてそれが風にさわると冷たい感じだ。
湿度が高いと基本的には走りがたい感じがする。
一番良い感じは、3～5度くらいで快晴・風なしのパターンくらいがちょうど気持ち良いかも。
温度がそれ以下になると、身体が温まるまでに時間がかかるように思う。

１時間というのは結構いります。
30分だと最長距離にあたる箇所が15分なので、走り途中に何らかの障害があってもそれほど問題とならないが、
1時間だと 最長部で30分となり、これがやつかい。
たまにトイレに行きたくなる時もあるのだが、15分なら場合によりけりだがＯＫだけど、30分は我慢できない。
その為、走りコースの中にトイレに行く事のできるコンビニを入れておく事は、都会走りの場合には必要と思う。

年度末対応：

しょえ～。
最後の最後。
21～22日で会計ソフトにデータエントリ。
23日に各種帳票作成。
24日提出・納税じゃ。

浅田真央/4大陸：

フリーはひさびさぶりに見る完璧な演技でした。
身体に比べてアームスの部分が長い彼女ですが、それを差し比してもあのアームスを見ていると、
彼女はアームスを肩胛骨の下に乗せるという事が意識できているのではないでしょうか。

-2月21日(月)-

年度末/決算：

昨年度の領収書(経費)を全て整理した。
嫌な領主書ですが、 仕事が少ない分領収書も少ない。
毎年一番でかいパイプファイルがはちきれそうになるのだが、昨年度はスリム。
まずいよなあ～。

さぁこれから、会計ソフトにデータ打ち込み。
領主書も少ないからデータエントリ作業は軽減たが...

健康：

昨日に続き今朝も連チャンで走ってきた。
そして午後一のレッスンにも出てきた。
やっぱりレッスンは間を空けるとてきめんに回転系が悪くなるような気が...

ニコン/200-400F4/70-200F2.8：

ニコンのカメラを使い出してから1年が経過しました。

その間の修理表は、D300Sのシャッターストロークが長かったので、超軽くしてもらっただけです。
それ以外一切なし。
仕事で使うカメラはやっぱり安定した稼働があって初めて心に余裕が出てくる。

ニコンのこの二つのレンズとD3Sの組み合わせでは、コンティニアスAFも躊躇なく使える。
もしかしたらシングルＡＦよりも良いかもと思うくらいだ。
カメラまかせに出来る所がより増して、シャッターチャンスに集中度が増す。

70-200F2.8VR2　超高性能なレンズで早く、これで舞台全景を撮りたい。
早くフルサイズ2400万画素D800(標準価格29万　買値23万)を出してよ～。
3月には発表がある事をせつに望むなり。

-2月22日(火)-

認証/window.open：

新しい方式による設計を終わった後、更にまた新しい考え方が出てきた。

window.openで制限サイトを呼び出すからダメ。
単なるhref属性ではＯＫ。

認証時に呼び出す箇所というのはよくよく考えればhrefでも構わないのだが、hrefで呼び出す以上認証されたサイトにユーザ情報(ユーザ名等)をどのように呼び出された元に渡すか？
まさかコマンドラインで渡すなんてアホな事はできない。

このような事の為にセッション制御を使う意味が出てきた。

セッション制御を使わずとも、実際に認証するのはサーバ側プログラムなのでそのサーバ側プログラムで直接href情報を元に制限サイトのＵＲＬを呼び出してやればそれで済むし、ユーザ名等の情報も渡す事が可能。

という事でほぼ最終的な方式が決定。
この手の基本方式であるセッション制御を使う事にした。

セッション変数は呼び出されたＵＲＬモジュール側で再度サーバにアクセスした時に廃棄すれば良い。
これでほぼ完全だが。
一懸念があるが、どうしようか。
今週は決算作業だし、う～プログラムを作りたい...

追記

テストＯＫ。懸念も解消。

非常に不思議なのは、Aサイト（許可）　Bサイト(制限)　ディレトクリィの縫合関係は
～/Aサイト(X.html)/Bサイト(child.html)

とした場合、BサイトにあるＵＲＬをコマンドラインで呼び出す事も、Aサイト以外から呼び出す事もアクセスエラー。
また、Aサイトからwindow.openで呼び出す事もIEの場合アクセスエラー。

一方、AサイトからＢサイトにhref属性で呼び出され、child.htmlは正しく呼び出される。
と、ところが、今度はchild.htmlは、Aサイトにあるwindow.openで呼び出された　X.htmlがあった場合、X.htmlはBサイトのデータに自由にアクセスできる。

ふ～ん。
当然と言えば当然か。

しかし以下のような構造の場合
～/Aサイト(X.html)/Bサイト(child.html/Z.html)

Aサイト→(href呼び出し)Bサイト(child.html)→(OPEN呼び出し)Bサイト(Z.html)
では、「(OPEN呼び出し)Bサイト(Z.html)」の時に、openで呼び出し元のhref情報がわからないので、制限サイト内ではエラーになるのだろうと思う。

ふ～ん。

ちなみに
Aサイト→(href呼び出し)Bサイト(child.html)→(href呼び出し)Bサイト(Z.html)
の場合は、例え制限サイト内でも(href呼び出し)Bサイト(Z.html)は成功する。
これは、アクセス制限の許可をAサイトに適用すると、ディレトクリィの包合関係からその許可サイトとしてその下にあるBサイトも有効となってしまうからだ。

もしＢサイト内で自由に呼び出しを制限したいのであれば（普通はそうしないが）以下のような構成にすれば良い。
～/moto/制限/Bサイト(child.html/Z.html)
　　　　/許可/Aサイト(X.html)
このような構成にし、制限ディレクリィにアクセス制限、許可ディレクトリイに許可アクセスを与えれば良い。
まあ、このような関係でも、制限デイレクリィを許すサイトとして、自分自身を登録しておけば自由にできるようになるが...

一つのプログラム構成の中で、複数window.openを発行するプログラムがあった場合、制限サイトにはメインのプログラムだけ入れておいて、その他の子供openプログラムは許可サイトに入れて置けば良いという事。
許可サイトからは自由に、制限サイトのデータハンドリングはできるので、それで良い事になる。
もちろん許可サイトに入れた子供openオープンプログラムは、制限もとにある親と連携して動作しなければ動作しないようにしておけば、子供だけを動作しても意味がなくなる。

評価してみたが、これもＯＫ。

ふ～ん。

このような事を調べたサイトは、どうもどこにもない模様。

結局認証プログラムからは、認証された結果呼び出すプログラムは制限サイトに入れて置いて、サーバ側の認証モジュールから直接href属性で呼び出す事にした。それなら今までのディレトクリィ構成を変更する事もクライアント側認証モジュールの変更も最低限で済むし、アクセス制限にも強い物が出来る。
考えれば解決策があるもんだ...

どちらにしろ　サーバ側認証モジュールは少し変更する予定があったのでこれで良い。
サーバ側認証モジュールは制限サイト内に入れるので（これはwindow.openで使うわけでなく直接ajaxで通信）このモジュールを許可サイトからしか呼び出せないのでより強固。

な～いす。

追記

もしかして...
認証に対してfacebookを利用できるかも　そうしたらもっと認証元情報として確実になるのだが...
という事で　facebookも調査する事にした。

健康：

そう言えば昨日走った時には、荒川の土手ですれ違ったランナーは　0　だった。
恐らく日曜日に皆さん最後の長距離を走って、月曜日はその休養に充てたと推測される。
今週末の東京マラソンに皆さん出られるものなんでしょう

それゃ～　朝の5時～6時に走っている人の中に、健康の為に走っている人は、
超少ないと思われるし、それなりにランニングに対してこだわりのある人達がほとんどだと思う。

でも　私は違う。

日曜日から
走・走舞・舞
とやると、超厳しいんですけど。

舞というのは、踊れて楽しそう　と思われがちですけど、
私などでも、レッスンの前に1時間程度ストレッチするのです。
そして年がら年中足が張った状態になっています。
そういうは、恐らく他の運動の中では数少ない物だと思います。

そして歳も効いてきます。
一日の中で1時間走って、それでバレエレッスンに出るのは、もう～、キーって(？)言う感じです。

-2月23日(水)-

確定申告：

データエントリーは今回は、数種類の同じ仕分けの物を一括して、コピーしながらどとんどん入力したら効率よく入力が行えた。
決算書に関しては、別表がいやらしいのだが、それも、e-Taxで清書して作成。
下のレベルから順次入力してやると、上の階層の帳票に自動的にデータが反映されるので、これも効率よく入力できる。

都道府県法人税と市民法人税は、申告書類のみをel-Taxで入力して送信。
但し　el-tax側のアナウンスミスで、Windows7 64bit標準では、JPKIに対して単にインストールしただけでは動作しない。
参照設定で、明確にそのインストール先を後でel-tax内で指定しなければ動作しない。
この為また、3時間ほどウロウロしてしまった。
最終的には、el-taxに問い合わせて解決。

el-taxでは電子申告はＯＫでも電子納税がまだ、私の住んでいる所では対応していない。

ので、明日、銀行で納税、確定申告書を歩いて10分の税務署に持参して申告して　終了じゃ。

しかし、昨年度の決算結果を見て驚いた。
この5年間で最低の売り上げ！
キャ～　今年もこの調子だと　マ　ズ　イ～！

-2月24日(木)-

セッション：

朝一で税務署に確定申告の提出と銀行で納税実施。全て終了。
今年はがんばらねば！

セッション制御を取り入れる為に各種テストと設定を行った。
こんな簡単なプログラムを作ってみた。

これは　セッション変数を使った簡単なカウンターと　その時のセッションの納めるファイルの元となるセッションＩＤを表示しています。
プログラム実行後、リロードするとカウンターの値が上がって行きます。
また、このＵＲＬを別のＷＩＮＤＯＷ（同種のブラウザー）で起動すると、カウンターの値が引き続いていると思います。
別種のブラウザーで動作させると、別なセッションＩＤがとられます。

二つのウィンドウ上で交互にリロードすると、矛盾なくカウンターの数値が上がっていきますし、1個のウィンドウを消して、再度別なウィンドウを立ち上げても、継続しています。
別種のブラウザーで動作させると、例えばｓａｆａｒｉ同士ならセッションは継続されますが、ｓａｆａｒｉとＩＥなどでは、別な物として扱われます。

サーバ上のプログラム上では　セッション変数として扱われ、サーバ上の指定された箇所にセッションファイルがセッションＩＤを元としたファイル名として格納されます。

また、ユーザというかセッションの単位を識別する為に、ユーザＰＣ上にも　このセッションＩＤを元としてファイルがクッキーとして格納されます。但しユーザＰＣ上に格納されるクッキーの中身には、何も書かれていません。セッションＩＤのみが必要なので、そのＩＤを元としてファイルがクッキーとして保存されます。

セッションアクセスは通常ＰＨＰの関数としてセッション関数が提供れさています。
通常セッションの有効期間は、セッションを用いたクライアント側の画面が表示されているか、あるいはそれを用いたサーバ側のプログラムが動いている限り有効で、最長で規定値では24分です。（厳密には定義された確率で消されますが...）
セッションを使ったシステムでは、24分以上クライアント側が何もしなければ、セッションはなくなってしまいます。
よく、長い間インターネット上で書き込みをしていたら、切れてしまったぁ～　という部類には、これに付随するものもあります。

なぜ24分かは　明確な定義はないようです。
私の画像閲覧では、24分では、どうみても短すぎるので、2時間に変更しました。
これは、ホスト側サーバの設定変更あるいは、プログラムでも出来ます。

ただ　時間が長いとログインしたまま　ほっぽり出されたＰＣは、他の人にも利用されてしまう可能性が出てくるわけですけど...
通常は、お金や重要な個人情報を扱うようなシステムでは、むやみに長くするのは、問題だと思えます。

セッションＩＤは、PC側にクッキーで保存　と記述しましたが、クッキーを受け付ける事ができないと、かなり問題が発生します。
サーバ側の規定値としては、クッキーが利用ができない場合、セッションＩＤを、ホスト側ＵＲＩの引数に自動的に作成されるようになります。機能としては、これでも良いのですが、そうした場合、目に見える形でセッションＩＤが出てくる事になり、セッションハイジャックの元となります。

よって、セキュアーの意味では、強制的にクッキーのみの利用とするように、これもサーバ側の設定で変更しておきます。
クッキーはインターネットを利用する上では、必須の機能となります。

セッションＩＤは、通常ログインの有効期間をセッションＩＤの有効期間に合わせています。

更に、サーバ上でのセッションファイルは、規定値はサーバのルートディレトクリィの/ｔｍｐ領域に設定されています。
通常レンタルサーバのほとんどは、一つのサーバを複数人で使っている事になり、規定値のままでは、他人のセッションファイル＝セッションＩＤが、他人に知られてしまいます。もちろんそのファイルの中身は、わかりませんが。
これもセキュアーな意味からは、危ない事になります。
よって、このセッションファイルを保存する場所も、ユーザディレトクリィ内に変更します。
但し、ユーザディレトクリィと言っても、インターネットからはアクセスできない箇所におく事が望まれます。

セッションはユーザ認証と結びつけられてシステムを簡単に構築できますし、現在のインターネットシステム上のセッションは全てこの機能を使っていると言っても良いでしょう。

しかし時折問題となるのは、このセッション制御が、ＰＣブラウザーとサーバのドメイン間で一つしか同時には制御できない事だろうと思います。
例えば、ある一つのドメイン配下でインターネットショッピングサイトを二つ作る事にした場合、サーバのドメインは一つだし、使う側のブラウザーも一種とした場合、もし二つのユーザ認証をセッション制御で構築し、同時に使ったら、セッションは一つしか出来ないので、二つのユーザを認識できくなってしまう可能性が多いにあります。

という事で、セッション制御をユーザ認証と結びつけて考える場合には、複数のユーザ管理システムではなく、一つのシステムにしなければならないという事が、わかってきます。
この事から、逆に求められる設計要素としては、セッション制御を使う限り、現在認証している時に、同一ユーザからの再認証要求は、却下するなどの必要性もあるかも知れません。

私の場合であれば、一つのユーザが、二つの別のお教室の閲覧を一つのサーバ上の一つのブラウザーで同時にログインさせるかどうかを決めなければなりません。まあ、ブラウザー種別を判断して、同一ブラウザーからは却下するんでしょうな...

追記

上記プログラムに関しては、本プログラムを呼び出す毎に、セッションＩＤを変更するように変更しました。
セッションＩＤが変更になっても正しく、その内容（セッション変数）は更新されている事がわかります。

更に子供を呼び出すと、セッションをクリア＝ログアウトの意味　するようにしました。
なお　セッションを廃棄せず終わると、サーバ側にセッションファイルがゴミとして残ったままになります。

-2月25日(金)-

セッション：

セッション制御を組み込んだ。
特に問題なく動作しているようだ。
またセッション制御を利用してアプリケーション側のアクセス制限機能も組み込んだ。

色々と問題がありあり　すぎ。

元々ブラウザーとサーバ間の通信は非常に制約が多すぎ。
そもそも一般的に内部通信は、HTTPプロトコロなのだが、これがくせ者。

今回つまづいたのは、クライアント認証プログラムからAjaxで通信させてＤＢ認証させる。
その結果をクライアント認証プログラムに返却させて、問題なければ、ＤＢに登録されてあるＵＲＬを起動するもの。

元々　ＵＲＬ先がIEの場合、apatchでのアクセス制限サイトにあると、幾らもとのＵＲＬが許可されたサイトでも　JavaScriptからの動的起動は、参照元アドレスがＮＵＬＬとなる為に、アクセス制限にひっかかってエラー。
それならば、サーバ側でＤＢ認証後に、ＵＲＬ起動させてやれば良いのだが、Ajaxの通信とＵＲＬの通信がどちらもHTTPプロトコロを利用するので、どちらか一方しかできず　これもできない。

という事で、全てがダメ。

結局　元々の設計通り、
　静的データに関しては、アクセス制限。
　動的プログラムに関しては、ＤＢ認証を利用して論理的アクセス制限。

という事に落ち着いた。
この元では、IE/Safari/Chrome/FireFox　全て動作検証終了。

セッション制御は、うまく使えば、強力で簡単。

追記

通常　セッションを持ったブラウザーが　×点押下で終了した場合、セッションファイルが残ってしまう場合が多い。
これに関しても、イベントリスナーでアンロード事象を捕らえて、セッションファイルを削除するようにした。
一つのブラウザー上で　1セッションしか持てない為に、1セッションを開いた状態にしておくと、セッション制御上は、他のセッション制御すべきプログラムも認証された状態となってしまうが、これもセッション変数等を調べてブロックするようにした。
セッション制御に関しては、現在考えられる限り完璧な対処になったと思う。

-2月27日(日)-

日曜日：

東京マラソン。
市民ランナー　男性が3位。
これには、涙しました。おめでとう！
最後激走でゴール後倒れ込んでインタビューにも答えららず。

しかしながら身体はこれを記憶してしまうのです。
次回は、身体が記憶したこの事象に対しセーブをかけてしまうのだが、
それをどう、練習の中で克服して行くか、全て練習にかかわるわけだが、そんなに甘くはない。
多分次回は、今までの市民ランナーとしてでは、ダメだと判断します。

先週は　週4回　1時間ラン。3回のバレエレッスン。
かなり身体に負担がかかりました。
本来であれば、バレエなどは身体が解放されなければなりませんが、私のレベルでは全くダメです。

-2月28日(月)-

Web：

フレームを使ったHTMLだと、どこにJavaScriptを書いて良いのか？
これもブラウザーの動作は微妙に異なる。

Safariだと、例えばフレームを分割するHTMLにJavaScriptを記述しておいても、実際の子供フレームの中からでも普通に呼べる。
他のブラウザーだと、明確に各フレームを構成するHTML内に記述しなければならない。
また、やっかいなのが、それじゃー、フレームを持った全体のWindowをクローズさせるにはどうするの？
という事もあるし、全体のＨＴＭＬそのものがwindow.openでオープンされたWindowでかつ、そのwindow内がフレーム分割されていたら、クローズはどうするのか？

という仕様的に曖昧な箇所が複合的にからまっている場合の処置も非常に困難。
色々とやってみてなんとか解決した。
本当にもぅ～、仕様的に不明な箇所が多すぎるぅ。

一応認証そのものとアクセス制限、閲覧機能は完成。

次は、閲覧機能部分に対して、マーク画像の保存・復帰機能まで入れて、閲覧機能は終了。

閲覧機能のサブセット版を作成して、一般ユーザ公開用の画像アルバムも作成する事にした。
こっちは簡単にできる。

そうそうブラウザーがキャッシュしているせいで、全く動作が不正になる場合が結構あるが、キャッシュをプログラムから明示的にクリアーさせる方法はない模様。
非常にいやらしいのは、ブラウザーのリロードでキャッシュを使わず最新内容がリロードされれば良いのだが、それもダメなパターンは多い模様。JavaScriptを使ったプログラムでは、どういうアルゴリズムでキャッシュされるのかわからないが、URL指定でopenやhref属性で飛ばすような場合、そのオプションパラメータが毎回異なれば、少なくともそのＵＲＬは別な物が使用される。
Ajaxを利用して、サーバ間でデータをやりとりする場合に、キャッシュされると大変な事にもなる。

そのような場合、起動するURLのオプションデータとして、それを受け取るプログラムには無関係なデータとして　例えば現在の時刻情報をくっつけて送れば、キャッシュデータが使われる事が回避できる。

プログラムを修正したのに、プログラムが正常に動作しないパターンもよくある。

少し調べてみたら、私が所属しているサーバに、ＶＰＳが使えるとの事。
これだと980円/月。ＯＳから全て自分で構築できる。必要なのは、自分の知識だけだ。
これなら、サーバサイドでJavaも動作できれば、モジュール版PHPも動作できるので、やろうと思えばなんだってできそうなんだが、さすがに、そこまではやってれないよなあ～。

トピックス：

大学入試時に問題がインターネットに漏洩した件。

よくわわからないが、携帯電話を使って問題が漏洩したのではないかと言うことだが、もしそうなら、やはり大学入試にもまともに受からない低能者のやった事だとどうしても思わざるを得ない。

携帯電話は基本的にはダイアルアップ。
いつかは足が付く。

よく本人特定にＩＰアドレス云々が出るが、そんなものは直ぐ偽装できる。
インターネット犯罪をするレベルでは全くない。
普通は、物理機器に1個付与された物理アドレスも偽装する。

誰もが考えられる事なので、最低以下の事はプロの犯罪者ならすると思う。

事前に無線Ｌａｎに不正に侵入できるエリアを探しておく。
これは事前に調べる時間さえあれば、確実に見つかる。
複数人で実施するなら、構内から携帯メールを使って、構外にいる共犯者に直接メールする。
共犯者は、事前に調べておいた無線Ｌａｎに不正に侵入する。
但しながら、不正に侵入する機器は、別なパソコン等で、ＩＰアドレスと物理アドレスの改ざんを行って、
無線Ｌａｎに侵入して、ネットワーク接続する。
ちなみに、無線Ｌａｎはセキュリティの低い所は一発で入れてしまうし、ＩＰアドレス/物理アドレスも改ざんも可能。
そうしておけば、インターネットを通じて、足が付く事はまずない。

 

－ 日記一覧に戻る－