-3月1日(金)-

ショッピングカート/Location:

サーバサイド側のプログラムほぼ終了。
テスト済み。

一箇所不明。
A.https://www.plie.org/pro/a.php に存在するプログラムで

----a.php----
header("Location:https://www.plie.org/dat/b.php")
--------------

ブラウザーのアドレス欄にA.を打鍵してやると、実際に　b.php起動するURLが
----a.php----
https://www.plie.org/pro/https://www.plie.org/dat/b.php")
--------------

なぜか、カレントアドレスが指定したURLの前についてしまう　？？？

なんじゃ　こりゃ〜

-3月3日(日)-

トピックス：

そう言えば、新装開店の時には、行っていたパチンコ屋さんにも行かなくなった。
なんか興味がわかないし。

右回りアンデオールピルエットの方は、大分今の回り方が身についてきたと思う。
もう少し考慮すべきは、スイートスポットを広げるような考察が必要と思う。
しかし、よくこの歳でピルエットのスタイルを変更できたもんだと思う。

ショッピングカート:

今日も朝7時から夕方6時までプログラム作成。

商品リストとしてデータベースに登録されている　写真情報を元に、
ショッピングカート用に写真/種類/枚数を選択させる画面を　自動生成できるメインの所まで
完成した。
一番重要な箇所がテストまで終わったので、後は、小さい箇所を　ポツポツくったけるだけ。

自動生成できるかどうか、気になっていたが、Javascriptで書くXMLでは、簡単にできてしまう。
HTMLとしてのユーザビューの調整に少し時間がかかった。

さぁ　WBC みよ〜っと。

-3月4日(月)-

javascript：

ひぇ〜　まじ〜
SafariだとOK なのにIEでは　ダメじゃない。

IE では　なんと　submitがイベントバブルしないらしい。
確かに　イベントが発生していない。
ひょえ〜

buttonにして、通常イベント処理するしかなさそう。
本来　input文でプログラムに通知すべき事象は、hidden にして通知すればいいや...

-3月5日(火)-

javascript/ショッピングカート：

なんかおかしい　おかしい...
と思って　同じFORM文を　HTMLで静的に記述した物と、javascriptで動的に生成した物を比較してみた。
なんと　そうした場合、同じFORM文で動作に違いが発生しているのだ...
インターネット上でかなり　この問題を検索してみたが、この問題に言及している箇所は、かなり探したが、見つからなかった。
-----------------
// 静的生成
<FORM ACT=a.php id="111"　onsubmit="return b(this)">
　<input type="text" name="txt1"/>
　<input type="submit" value="送信" />
</FORM>
// 動的生成
<FORM ACT=a.php id="777"　onsubmit="return b(this)">
　<input type="text" name="txt2"/>
　<input type="submit" value="送信" />
</FORM>
function b(ev){
}
-----------------
静的と動的に作成しているもので、同じFORM文だが、submitした時に　this の取り方が違っている模様。
本来は、this = document.form 　を期待していているのだが、
静的に記述した場合には、確かに　そのように動作しているが、
動的に記述した場合には、厳密には　微妙に違う。

静的に記述した場合の　thisはFORMタグに含まれている情報の全てを　参照している模様。
動的に記述した場合の　thisはFORMタグそのものだけを　参照している模様。

例えば
静的に記述した場合、function b()の中で以下の参照は問題ない。
　ev.elements["txt1"].value
動的に記述した場合、下記参照がエラーとなる。
　ev.elements["txt2"].value

しかし
静的に記述した場合、function b()の中で以下の参照は問題ない。
ev.id　--> 111
動的に記述した場合も問題はない。
ev.id　--> 777

ひひ〜んだな。
でも、私の場合は、全てをjavascriptで動的生成させるので、自分の使い方さえ統一しておけば、問題はない。
IEもsafariも　バブルイベントをキャプチャーできないので、上記onsubmit で対応する事で問題ない事を確認した。

通常はこの手の商品画面自動生成は、PHPでHTMLを自動生成する場合がほとんどなので、この手の話題が出て
こなかったものと思われる。
本来　ネットワーク上に大量のデータを流してしまうのはのは、システム設計としては、あまりよくないのは当然。
できるだけ、サーバ/クライアント間できちんとシステム設計すれば、最小現のネットワークリソースで良いものを、
現行は　そこまで本当に考えた物はどうも少ない。

ひとまずこれで全ての問題が解決した。
後少し　機能を追加して、やはり来週あたりから、レンタルカート屋のシステムと連携させてテストができそうだ。

あそうそう　JQueryを使えば、submitもバブリングできるようで、ブラウザの違いも吸収できているようだ。
さすがに、今更JQueryまでは、使いたくないが...

-3月6日(水)-

javascript/ショッピングカート：

なんかおかしい　おかしい　おかしい...

昨日の問題点をテストプログラムで確認して、メインプログラムの修正をすると、あれっ　動かない...
メインプログラムの作成途中だったので、DOC宣言の前にコメントを入れていたのですが...

なんと　DOCTYPE 宣言の前にコメントを入れていると、IEでは動的生成したFORM文の　onsubmit文のイベントが発生しません。Safariでは問題ありません。

これには　はまりました。
コメント文が影響を受けているとわ...

恐らく、DOCTYPE宣言がないと、HTML記述等も、昔のバージョン仕様で動作しているのでしょうね。

という事で、これも解決終了！

仕事スタイル：

脱サラする時に働いていた会社は、恐らく日本でも売上高数兆円の会社。
そこで仕事のやり方を勉強したのは確か。
その中でも、自分的には効率化、品質改善という事にかなり執着していた方だと思う。

クラシックバレエ専門で写真を撮影している事を　公にうたってはいるが、
それは、写真を撮影する事だけを言っているのではない。

エンドユーザに写真を提供するというのは、「写真を撮る」だけではすまないのが、現実。
写真さえ撮れれば、後はなんとでもなると思っているような方々が一般的だと思うが、
少なくとも私は、そうは思っていない。

写真を撮るにしても、全ての箇所で、自分で考えた最高のプロセスをとる事を常に考えているし、
更に、写真を撮るという行為は、お客さんに写真を提供するという行為に対して、一部の作業でしかない。
あくまでも、「写真を撮る」という行為は、道具でしかない。

バレエを踊る技術が、道具でしかないのと同じです。
バレエという道具を用いて、観客に表現して初めて、バレエが芸術ならしめているのと、同じです。

その為には、感じる心　感性のしなやかさ　感受性の高さ　と
システム処理としてのワークフローの品質改善、効率化を冷静に見つめる
相反する資質が必要なのだと考えています。

昔、ローザンヌバレエ国際コンクールの批評家であった　クロード・ベッシーさんいわく
「バレエは踊るだけでは　不十分なのです。(表現して初めて)バレエなのです。」

それと同じなのです。

-3月7日(木)-

バレエ/レッスン：

今日は、バーレッスンの時から身体が動いていたような気がする。
今年一番暖かかった為かも知れない。
暖かいと レッスン前のストレッチの時から、身体が伸びるし。

ピルエットは、残して回る！
顔を残すなんて事は、言っていない。
その意味は各人にとって様々です。

アレグロアンシェヌマンの途中から
ブリゼ・ブリゼ・ドゥバンブリゼボレ・デリエールブリゼボレ・パドゥプアッソン・パディシャ・パドゥブレ・デリエールアチチュード(ポーズ)
最後のデリエールアチチュードは　褒められたかも(^_^)

バーレッスンの時には、初めて妙な感じを受けた。
デベロッペドゥバンに上げた足先が、妙に曲がって...
足先の裏で　何か物をつかむような感じで、自分の足先ではないように思うくらい、アウトに曲がっていた。

センターではピルエットバリエーションでは、先生が私のレッスン前の自己練習を見ていたのか
初めから、ピケケアンデダン・アンデオール・トンベパドゥブレ〜
というのがあったので、多分先生が私に期待を込めてのパだろうと思ったので、
アンデダン・アンデオール共に　ダブルで挑戦。
まぁ〜　68点くらいので出来でなんとか...
でも、某プロクラスでいっぱいやっているから、こんなものは出来なくてはダメと自分を叱咤して　ムリムリやったのが本音。

センターも終わって、最後時間があって、男性はアトルシャシス系統。
ひ〜　昔は一番得意だったのに〜

でも全体を通して、身体が動いたように思う。
そして、なんと、超〜ひさしぶりに、自宅に帰ってきてから、足がつってしまったぁ〜
ヒー！

-3月8日(金)-

ショッピングカート：

ほぼ全てのプログラムのテスト終了。
デザインに関しては、再考慮が必要かも知れない。

来週から、実際のレンタルカートと接続してのテストとなる予定。
しかし、Ajaxを本当に利用している所は、あるのか疑問に思う。
というのも、Ajaxを利用する為には、javascriptもPHPもきちんと理解しないと組めないのです。

今回、またAjaxを利用したプログラムを作成したが、この辺りのプログラミング・デザインはとても厳しいかなぁ〜
って思ってしまう。

WBC：

監督の采配にミスを感じる。

攻める時は、慎重に　それは正解。
守る時は、慎重に、それは間違い。

日本野球の神髄は、守りにあるのですから、守りを攻撃的にやらなければならないのですよ。
田中を守りの軸に据えるのは良い。
しかし短期決戦の中で、田中を3戦目でも起用したのは、采配ミスのなにものでもない。
情け無い。

ああいう場面では、ものおじしない齋藤が適任でしょ。

-3月9日(土)-

ショッピングカート：

複数のプロセスで、セッションを共用するのは、厳しいかなぁと思った。
今日はセッションに対する修正。

後、セッションを廃棄するポイントの実装だけとなった。

但し、ショッピングカートで受注が決定された商品の受注から発送までの処理に関しては、
最適なパターンがあると思われるので、その箇所に関しては、おいおいプログラムを追加しなければならないと考える

-3月10日(日)-

バレエコンクール/写真管理：

将来的にコンクール写真も請け負う事を考えてみた。
一番のポイントは、写真を撮る事より裏方仕事だと思える。

大きなバレエコンクールでは、数千人単位が参加する場合がある。
大量の写真を管理しなければならないが、一番のポイントは、撮影した写真と個人との突き合わせをどのようにするかだと考える。
個人と個人を特定する番号は、出場番号(エントリー番号)として、事前に管理されている。

何も効率化を考えない人であれば、
撮影された写真を見て、一つ一つ、番号をなんらかの方法で割り振るという作業になってくるが...
例えば　2000名出場のコンクールで　1名50カット撮影したとしよう。
全体写真は10万カットのオーダになる。
まぁ、その内必要なカットが　1/10だとしても、約1万カットは有効写真として、個人と突き合わせなければならない。

私であれば、1万というオーダを人間系作業でやるのは、バカげた事であると思うし、そういう仕事が何度もあるとすれば、効率化必須事項と考えるし、写真の管理ミスを低減させる上でもそういう写真番号管理は必須事項と考える。

バレエコンクールは、事前に出場順番と個人が特定できる。
たまに、不出場者は出るかも知れないが、事前に順番が決まっており、撮影も全てその順番に対応して撮影するというルールがある。
この特質さえ利用すれば、全ての写真に対して、自動的に個人番号を振るという事が、簡単にできてしまう事がわかった。
もちろん、写真購入者のリストもきちんと管理しておけば、写真購入者だけの写真を自動的に選択して、印刷に回す事も可能となる。

まあそんな時の突き合わせ処理など、コンピュータでプログラミングを組んだ事のある人なら、誰もが処理するスタンダードなアルゴリズムがあるので、誰でも考えられる事ではあるが...

コンピュータでの自動処理と人間系作業をきちんと考えれば、最小現の工数で最大の効率を上げる事は可能であると考えられる。

写真番号形式: xxYYYzzz
xx　　部門番号(ジュニア1　シニア　とかを分類する番号)
YYY　個人番号=エントリ番号
zzz　 写真番号

部門番号は　00〜99　で100部門管理
個人番号は　000〜999　で1000人管理
写真番号は　000〜999　で1000枚管理

個人の写真に対して、上記番号を全てふっておけば、全てを自動処理できるな。
後は、袋詰めだけ。

写真の受注は、現場ではとらない。
現場では、あらかじめ、個人を特定するエントリ番号に対応して、ランダムに割り振った個人毎のパスワードの発行のみ。
後日インターネットでその個人のみしか閲覧できないような閲覧環境から、規定枚数以上の写真購入をショップカート形式で購入。

購入した情報を元から、半自動で印刷にまわす。

4月は、このシステムを作成しておこう...

-3月11日(月)-

ショッピングカート：

セッション情報を廃棄するタイミングがなかったので、終了ボタンをくっつけて、ほぼ作り込みの箇所は終了。
後は、レンタルカート屋さんからの　正式な見積もりが来たら、最終的な連携部分を修正して作り込みは、終了。

VBでも　連想配列って使えるとは知らなかった。
これで効率的な検索が実現できる。

C1で設定したレーテイングもPhotoShopに連携できる事を確認。
レーテイングした内容をプログラムでアクセスしたいのだが、どうも障害が高い。
PSDファイルの中のXMPファイルをスクリプトで　どうも読めないらしい。

発想を変えて、レーティング/ラベル操作はbridgeで簡単にアクセスできるし、
レーティング操作してものはフィルターで選択するのも一発でできるので、
そのファイルをbridge上で外部フォルダーに書き出してやれば、
結局レーテイングしたファイルが何かは、プログラムで知る事ができる。

たかたが、今の所レーテイング操作は1回きりしかしないので、それで良いことにした。

と　プログラムが出来上がったと思って、VBプログラムを書き込んだら　エラーが出て、そのファイルが壊れてしまい、
結局2回もプログラムを組むはめになってしまった　どっ...

-3月13日(水)-

仕事/写真：

バレエ発表会では、数人で踊るものと、個人で踊るものがある。
4月からの写真販売では、個人で踊っているものに関しては、データ販売をする事になっているが、
個人販売できる写真かどうかを、ユーザに明確に知ってもらわなければならない事。
更に、受注時に、ユーザが指定してきた写真番号に対して、そのチェックもしなければならない。

その為、選択見本に関しては、WEB系及び印刷系含めて、写真番号の色を変えて、明確に通知する事にした。
さて、個人かどうかは、これだけは、人間が指定しなければならないが、Bridge上で、
あるレーテイングを設定した物だけを　個人として処理できるシステムを開発してしまった。

これはかなり便利です。

バレエ：

昨日レッスンが終わったら、知人のバレエ教師から、ピルエットが良くなったね〜って言われた。(^_^)

Safari：

どうもSafariは、以前の内容がパソコン上にキャッシュされていて、それが使用される率が非常に高い。
それが為に、WEBシステム開発時に、あるプログラムを修正したのに、以前のプログラムが動作したりして、非常にうっとおしい。
プログラム修正、サーバに送った後は、Safari をリセットするを　実施しなければならない。

バレエ/写真：

私はバレエを既に　20年以上踊っています。
音楽的な感性は、乏しい部類だと思います。

バレエの写真を撮る場合には、「先読み」が必要なのですが、
踊りを知っている事も重要です。
ただ、私の場合は、「音」というか曲　によって、かなり先読みをしている傾向があります。

-3月15日(金)-

バレエ/レッスン：

昨日は　２つゲット。
一つめ
バーレッスン時に、通常ドゥバンにタンジュした場合、足を外旋(アンデオール)する意識はあるのだが、今まで特にデリエールの場合には、その意識というか意識はあるのだが、どこを動かせば、凱旋できるのかなかなかできなかった。
ところが、昨日は、タンジュもアラベスクの時の後ろ足も、足の付け根から回すという事ができた。
その意識は、足先も外側に回すという意識にも繋がっている事を感じた。
もちろん、そういう意識はできたとしても、外から見た場合は、微々だる動きにしかなっていないと思うが、それでも生まれて初めての感触だった。

二つめ
バーレッスンの時に膝より先をロンデジャンプ(回す)させる練習があるが、それの延長線上で、フェッテアンデオールと、アンデダンピルエットを実施する時がある。
いつも　アンデダンの方が苦手だったんだけど、アンデダンで身体を回して、くびを残して、送り側のアームスを抱えるようにしてやれば回れるじゃない。これも　妙な感触だった。
そして、センターでも、これを意識したらダブルのピケターンが、いつもより安定して回れた。

最近なんかバレエレッスンの中で色々な事に気が付くこと多し。
レッスン楽しい思いが　少し強くなってきた。

ピルエット系は、1回転目に首を回す事でなく、意識的には首を返す中で、軸を作る事が一番大切だと思う。
そして特に送り出し側のアームスが使えるような身体使いが大切。

左/右：

毎朝シャワーを浴びている時に、電動ひげそり機でヒゲを剃っているのだが
顔半分　左と右を比べると、明らかに左顔半分の方が、右半分より、ざりざり言っている率が高い。
左半分の方が、ひげとか産毛が生える率が活発化しているのです。
へんなの...

TPP：

しかし、ばっかだよね〜。
誰も本質について、語らない。

TPP参加云々による、メリット/デメリット　の話し　しか聞こえない。
こういう問題に対して、きちんとした意見を言える人が、公にいない事が、とても問題だと考えます。

既に　解が決まっている事に対して、自分が不利益を被るから　ダメ　という論理は、論理ではあり得ません。
きちんと、先を見通した論理としての見解、現実の一般大衆が感じている事の　ギャップをきちんと説明できていなのは、
原発の問題と同様だと考えます。

情け無い...

-3月16日(土)-

NIKON/80-400：

NIKONから待望　80-400がリニューアルされました。
以前　80-400を一時期保持していたのですが、その時の印象は、
AF遅い、解像度こちらの希望に合わない、何よりも、ズームリングが手前にあって、超〜使いがたい
という事で、半年ほどで手放したものです。

NIKONさんから、短期間お借りしてきました。
ズームリングの位置が改変されており、その意味だけでも、使えそうだし。
どうも　ちまたの噂では、解像度も　凄くあがっているらしい...

という事で、この一週間で、仕事含めて　評価する事にしました。

D4 ISO3200 で　それなりの画像が出るのであれば舞台写真としては、スーパーレンズになるかも知れませんし、
そうはならなくとも、補助的に使えるかも知れません。

もし使えるのであれば、2本ある70-200mmF2.8ナノクリの1本を売って、こっちに乗り換えるかも〜〜〜〜(^_^)

明日以降　泣く子も黙る(!)200-400mmと評価してみます。

-3月17日(日)-

NIKON/80-400：

一般的な評価をしてみます。
テスト環境は80mmでこんな感じ。

信号機の根本にある注意書きを比較してみました。
全て開放、部分切り出し等倍、ISO100,400mm側です。
ちょっと露出は違いますが、解像感は同じ程度ですが、80-400の方に若干色収差があるかも知れません。

若干やはり200-400の方がコントラストが高く、また、色収差に関しても、前述と同様の感じです。
200-400はF4評価なので、同一絞りにすれば、更にコントラストがあがると思います。

横断歩道を歩いている人物を撮ってみました。
やはり、解像感は充分ですが、色収差が若干認められると思います。

まぁ、200-400という超ドキューレンズと比較して、それを凌ができるのは、単焦点しかないと思いますが、新80-400は、そのコンパクトなボディを生かして機動性込みで評価すべきでしょ。
旧80-400と比較すれば、数段上の実力を発揮します。
強力な手ブレ補正、素早いAF、バランスの良い筐体、価格相応だと思います。
200-400も　価格相応ですが、孤高の存在ですね。

Eye-fi/新藤事務所：

今日は、Eye-fi SDカードの技術交流会という事で、新藤事務所に伺ってきた。
私は、個人的な興味で、Di866Mark2の色温度を計ってきたけど、出力1/1　1/2　1/4　くらいがよく使うのだが、
フル発光で　5400K程度から　だんだんと　色温度が高くなってくる。

規定値からすれば、やはりDi866Mark2 +200K位　= MG8000 と思いたい。

しかし　今日驚いた事は、ほとんどが、ニコンユーザ。
そして、ほとんどが、D800(E)ユーザでかつ、Eye-fiカードユーザ。
以前までは、ほとんどCANONユーザばかりだったのに、NIKON友の会みたいな集まりになってしまっていた事。

-3月20日(水)-

トピックス：

ショッピングカートの方は、ほぼ全て商品画面の箇所に関しては、作成し終えた。
デザイン的な要素は、ある程度変更が必要かも知れない。

商品画面に対しては、Ajaxを利用した物で構成。
恐らくこの手法は、どのWEBデザイン・設計でも、やっていない手法を採った。

バレエ/レッスン：

多分　私の思い過ごしだろうと思うけど。
ピルエットに対して、先生が私の回り方に何か価値を見出しているようにも思う。
更に、最上級に身体を使える人も、私の回り方に価値を見出しているようにも思う。

これは技術なのだと思っています。
永遠にバレエ初心者の私が見つけ出した技術です。

ただ　びっくりするのは、
私のような永遠の初心者がやっている事でも、プロはその中からエッセンスを見出す事をやっていると言う事です。
自身の傲慢さを持っている人など、自分よりレベルの低い人の動きは、全て否定していると思って当然だと思いますが、
本当のあくなき追求をしている人にとっては、それは関係ないようだと言う事。

-3月21日(木)-

トピックス：

昨年は大幅な機材導入をしたので、今年は最大限に節約モードで生活中〜(本当？)

スマホを止めて、従来のガラパゴス携帯+ipadmini +LTEモバイルルータで早　4ヶ月ほど過ぎた。
自分の生活では、これで充分。
ipadminiも使用シーンをきちんとわきまえて使えば、とても良い。
文字がでかくて、情報入手端末としては、非常に良い。

つい先日まで、地下鉄ではほとんど繋がらなかったLTEモバイルルータも、3月に入ってから、4Gモードで繋がっているし、良い感じ。

kindleは、小説を読むにはベストだと思える。
10冊くらいは購入して読んだ。
kindleも　上記モバイルルータと接続して、電車に乗車中でも新しく小説を購入したりもできて便利。
ただ小説を購入する場合は、画面が少しでも大きい方が良いので、ipadminiで購入して、kindleで読む　というのがパターン。

まぁ　小説を読むには良いが、例えば、技術書や言語解説書などは、やはりサイズ的に小さいし、あっちこっちを読むという読み方には、あまり適していないと思える。
本は本で残るし、文字だけの小説などは、電子化がどんどん発展して行くと感じられる。

私は、恐らく一般的なコンピュータの経験者としては、長い部類だと思う。
APPLI2の　あの赤本から、大型コンピュータを　パンチしたカードを入力して動作させていた時代も、windowのマルチタスクOSを徹底的に調査もしたし、全ての今の始まりであるNEXTStepも調査して業務に応用もした。

良い時代になったものだと思う。
また、コンピュータ言語によるソフトウェア開発など、もうこの歳になると、RPGゲームのような楽しさが感じられる。
今は、ゲームをするよりも、ソフト開発をしている方がおもしろいと思う。

さくらインターネット：

さくらインターネットでは、MYSQLデータベースが標準的に使えるのだが...
ほとんど話題になっていないようなのだが、MYSQLデータベースとして使える容量には...
制限がなくて、幾らでも使えるという事。

今回のショッピングカートで、日本語情報をデータベースに載せる必要があり、ちょっと疑問に思ったのは、
データベースの言語設定が規定値ではEUC-JPになっている事。
通常　HTMLの世界では、UTF-8が標準だけど(基本的にはサーバ上はPHPで処理する場合が多く、UNIX系列ではUTF-8が普及している為)、そうすると、ストレートにデータのやりとりが出来ない。

データベースの規定値言語を　UTF-8　に変更しても　元に戻ってしまう？？？
→　今　さくらさんに質問中。
よって、日本語を扱う場合には、コード変換してやりとりしなければならない。
データベースから取り出した　日本後をHTML表記にする場合には、
EUC-JPからUTF-8に変換が必要。

-3月22日(金)-

Eye-fi：

先日新藤事務所で　Eye-fiの勉強会等で伺った時の話題です。
この手の無線環境は、いかに電波を安定に飛ばすかという事が一番大切です。
Eye-fiカード自体は、電波が弱く、私の実測では10mを越えると不安定になる事がありました。

先日の会で集まった中の一人が、以下のような構成で実際に使っているとの事。
カメラ(Eye-fi)+腰にモバイルタイプルータ　-----　パソコン等

要は、近距離で電波が強い箇所をモバイルルータでとらえて、専用のモバイルルータで電波をリフレッシュして、飛ばしているという事です。
私もそれが正解だと思っているのですが、モバイルルータで5Ghz帯を使えるものが以前はなかったので　気にしていなかった。

MZK-MF300Dは2.4Ghzと5Ghzデュアルで使えて、かつ300Mbps、もちろん電池駆動も可能。
2.4GhzでEye-fi 接続して、パソコン等は5Ghzで接続します。

おまけに　お値段が実質3000円をきるし。

PhotoShop/スクリプト：

PhotoShopの多くの機能は、外部からスクリプトで動作させる事ができる。
私の場合は、windowsがメインなのでVBAでスクリプトを書いているが、Javascriptでのアクセスも可能。
Javascriptは、閲覧ツール等でがしがし使っているいて、PhotoShopの処理もJavascriptで記述しても良いのだが...

問題点は、Javascriptの方は、ユーザインタフェース部分を構築するのが、あまりよくない。
例えば　画面上から入力したパラメータを覚えいて、次回起動時には、そこから始めたいという事が、嫌らしい。
いちいちユーザとのインタフェース部分を作り込まなければならないし、デバッグも嫌らしい。

その点　VBAは　もともとExcelをコントロールする物なので、ユーザインタフェース部分をほとんど考慮しなくても良い、
更にデバッグも充分なものが用意されているので、開発もしやすい。
ただ　一点難があるとすれば、MacにはVBAが提供されていない事くらいで、Macでは互換性がない。
いや　MacでもVBAは提供されているのですが、まだ実績が少なく、なかなかに普及しずらいのが問題。

というのも
windowsで使う場合　vba特有の機能　windowsシステム特有の機能　PhotoShopの機能　を使うわけですが、
Macで使う場合は、 windowsシステム特有の機能　つまりファイルアクセス回り　の扱いが違う為に、なんらかの対処が必要なのです。

住基カード：

住基カードの発行率は5%だそうです。
住民は自分の所属している国の政策等について勉強しなさ　過ぎると考えています。
広報も当然必要ですが、自分が所属している国のルールの事について、勉強した事があるのでしょうか？
私などは、e-tax等を利用する為に、真っ先に勉強しましたし、真っ先に利用しました。

私の80歳になる母親などは、各種身分証明の為に、顔写真付き住基カードを作りました。
保険証では、身分証明としては100％ではないのは周知の事実。
歳老いて　免許証も持たない老人に対しては、住基カードが100％の身分証明となるのでとても便利です。

そんな事は、国民であれば、自らからが関心を持って、社会勉強すべき事なのです。
情け無い...

社会番号制度：

バカじゃないのぉ〜　と思ってしまう。
個人を特定する　一意な番号が悪いという事の　バカさ加減。

これに至っては、そういう人達自身のバカさ加減を露呈しているという事も、自覚していません。

本人を特定するのに、現状でも、本籍、現住所、生年月日、氏名があれば、まず一意に特定されるでしょ。
そう言った情報を、コンピュータに入れてしまえば、単なる数値です。

数値で特定されるのが　嫌という感情的な意見しか聞こえてきません。

現状それら情報を数値にした場合には、長い文字列すぎるので、もう少し短い数値にしましょう　としか言ってないだけなのです。
住所や、本籍地も　変えられる恐れがあるので、それでは、安定的に利用しずらい。
それを現状のシステムで利用しましょうとしか言っていない。

-3月25日(月)-

仕事：

電源あり。ホール音がとても響くので、発表会でも遮音が必要かも。
撮影したデータ。　RAW 120Gbyte!

パソコンとカメラ連結撮影：

パソコンとカメラの連結撮影しているパワーユーザの筆頭は私であろうと思いますが...
昔　EosUtiltyでも　144枚以上撮影できないバグを発見しました。
今回　CameraControlPro2 にも、大きなバグを発見しました。
なんとこちらは　CameraControlPro2とカメラが接続できないというとんでもないバグです。
普通に発生します。誰にでも発生する可能性があります。
電池の抜き差しや、パソコンやカメラの再起動でも、復旧は不可能。
接続を諦めるしかあり得ません。

まぁバグの原因がわかったので、ニコン屋さんに報告してきます。

追記
ニコン屋さんに報告してきて、その後、やはり私の推測していた可能性があたっていた模様で、
ニコン内部でも同じように発生している(途中確認中)模様。
CCP2を使う人は、全ての人に発生しています　と言えますね。
緊急修正が必要と思います。

5D3とシグマ120-300：

初めてこのレンズの　120側と300mm側でピントが来ているものを見た。
これなら　使えると判断する。
但しながら、300側は、ニコンの200-400の300側と比較すると、若干解像していないと思える。
ピントは来ているが、像がぼける

-3月26日(火)-

ニコン/障害情報：

CameraControlPro2を使用して連結撮影を行う時、カメラと接続時に必ずメディア内の空き容量チェックを行う為に、
メディア内のファイル数が増えると全数ファイルチェックをかかる為に、接続の為に時間がかかる。
例えば、SanDisk 32GMB UDMA対応60MB/S で、90%程度使ったメディアの場合、接続に約6分程度かかる。

これって誰が考えてもバカな設計ですよね。
メディアにファイルを残さない設定をしたとしても、必ずチェックに入ります。
設計ミスの何ものでもない。

カメラシャッターが切れない時があるという致命的なバグだと考えます。
屋外でカメラを使う場合には、こまめにカメラ側の電源を切ったりします。
それ毎に、何分もまたなければなりません。
64Mbyteのメディアを使ったら、10分以上使えない場合もあると考えます。
あり得ない設計ミスです。

-3月27日(水)-

舞台写真：

舞台写真を最高クォリティで写真にする為には、RAW現像が必須作業。
例えば、舞台中央照明がある中で2500Kで適正色温度とした場合、舞台脇で照明が弱い場所では、
更にそれより低い色温度で適正となる場合も多い。
色温度をダイナミックに変更しながら撮影できなくはないが、非常に難しい作業となる。

がそれだけではない。
カメラ単体の機能で色温度の最低は、2500Kまでしか設定できない。
カメラでどうがんばっても　最高クォリティでは写真ができないという事です。
また、カメラの液晶を見てアバウトに設定はできますが、厳密な色温度設定ができるなんて事はあり得ない。

5D3 対D4：

ISO6400クラスで両者の画像ノイズは、RAWで全くノイズ処理しなければ、D4の方が良。
うまくノイズ処理してやれば、画像の解像度が高い分5D3の方が良いように思う。

しかし改めて、NIKON 200-400mmF4の　画像先鋭度の高さを感じてしまった。

-3月28日(木)-

PC：

昨日は、一日に2度もパソコンがブルースクリーン(クラッシュ)になってしまった。
ブルースクリーンの経験はほとんどなく、凄く安定性の良いPCだったのに。

という事で、OSディスクに対してCHKDISK をかけたら、幾つかのファイルに対して修復がなされた模様。
その後、ついでにOSディスクに対してもデフラグを実施。

とりあえずは、問題が解消されたように思うが...

相続税：

ついに3月の国会で相続税の新案が可決されて、2015年から施行との事。
例えば　今までは　4000万　+　1500万×法定相続人　までは基礎控除される。
法定相続人が2人の場合、7000万までは非課税。

新案では　3000万　+　600万×法定相続人
4200万までは非課税、2800万の箇所に課税がされる。
約370万程度の課税額となる模様。

-3月29日(金)-

PC：

ブルースクリーンはどうも直ったようだ。
快調　快調〜

D800：

今回から天ばんに、MG8000 + PS8 投入。
5m延長コードも丁度良い感じ。
色温度をモノブロックと揃える為にフィルターLBA3設定。
モノブロックと組み合わせても光があばれる事なくレスポンスも問題なく安定した撮影が可能になった。

色々な衣装もあるし、特にモアレの出やすい衣装もある為、D800が出た時にD800Eは戒めてD800を購入したが、
解像感では心はD800Eに動くが、私の仕事ではD800がベストチョイスだと改めて思う。

-3月31日(日)-

PC：

以前はたまに電源を入れてもPCが起動しない場合があったが、これも直ったように思う。

バレエ：

今日は首が痛い。
時々首が痛くなる時があるけど、前日に回転系で首をグリグリ回した時の模様。
一回転目をいかにクリッとクイックに首を返して立つ事だけが課題。

ケーキ：

間食はしない私です。
ケーキなどの甘い物も好きですが...
それまでケーキを食べるのは、年間に1回あるかどうかだったのですが...

私の自宅前にあるケーキ屋さん。
激うま。
私の生涯の中でNO1のケーキ屋さん。

昨日もそこのケーキをお土産に、あるお店の開店記念に行ってきたけど、
飲食店のそのお店の方から、そのケーキがかなりおいしかったとの事。

私の住んでいる川口の名店のNo1だと考えています。
まぁ、ここのケーキを持って行けば、全てを納得させられると考えています。

 

− 日記一覧に戻る−