_ [日記][写真] 昨日に引き続きフィルムの現像

昨日、フィルムは古くしたらダメ！　って事で早速（？）カメラに入ったままだったフィルムを取り出して現像に出しました。

フィルムはFUJICOLOR PRO400でした。

・・・・。

プロ用フィルム？　

５００円近くもするじゃねえかよ・・。

・・もったいない事した。

そして現像して受け取る。

この現像したフィルムを受け取る前のワクワク感と受け取った後のガッカリ感がたまらない。

えー・・・。

８枚しか撮影してませんでした・・・(´・ω・`)

しかも最初のコマは去年でした・・・。

・・もったいない事した。

こんな事ならもっとガンガン撮ればよかったです。

それにですね。

だいたいこのフィルムってですね。

たぶんプロユース向けに色再現重視＝なんとなく発色が地味なんですよね。きっと。

なんか一つ勉強になりました。

去年撮影したコマもものすごくおかしいという事はありませんでした。

↓去年末撮影、今日現像

（神田川/FUJICOLOR PRO400/Rollei35）

昨日書き忘れましたが、使用したスキャナはニコンのSUPER COOLSCAN 5000 EDです。

とはいえ、フィルムの特性か、撮影した環境によっては色がおかしい気もします。

はい。たぶん用途に対して間違った機材使ってますね。

（近所の道/FUJICOLOR PRO400/Rollei35）

しかし、なんだろ。

Ｗｅｂに載せるためにこのサイズにすると案外キレイに見える。

うーん。そもそもこんな物なのかなぁ。

あと、カメラやフィルムの写り云々の前に構図が酷すぎますね。。

ピントやら露光に気を取られてデジタルの時よりも適当にフレーミングしている気がします・・・。

これも次回への課題で。

_ [日記][写真] 魅惑のフィルムカメラ

デジタル１眼はとても便利です。

そしてコンデジに戻れなくなるのも事実。

リコーのGR DIGITAL IIはかなり欲しいですが、実用性考えるとGX200か・・・とか迷いながらなんとか買わずに済んでます。

実際のところは４年近く前のFinePixF10をまだ現役利用してるのでスナップの撮影は困ってないんですが、やはりそれでは純粋に”なんでもない風景”を撮る楽しみは薄れるもの。

といってデジタル一眼を持ち出すのも・・・って時にコンパクトフィルムカメラです。

ひょんな事で、というか親から貰ったRollei 35が活躍します。

・・・活躍したいんですが、フィルムカメラよりもデジカメ世代な自分にとってはまず基本が色々問題がありました。

なんか写真が昭和っぽくなるんですよね。

（秋葉原にて）

まぁ、それが正しいのかもしれませんが、もっと鮮やかな写真は昔からあったハズだし、キレイに撮影してらっしゃる方もいる！

って事でリバーサルフィルムで撮影してみたり。

（飛行機より。デジカメじゃないから離着陸時にも撮影可能！）

たしかにちょっと鮮やか？

リバーサルフィルムは魅力的なのですが、如何せんRollei 35では露光が難しすぎる！

現に１／３くらいのコマはアンダーでした。

そして現像が大変！　（扱ってる所がもうほとんど無い＆高い）

出来ればネガで気軽に撮りたいのであります。

露光計も実は用意してみたんですが、そんなも持っていくならEOS Digital持っていけますね。

なんとなくモノクロにして誤魔化すとか。。。

（福岡市内にて）

で、気づいたのです。

フィルムが古いのかもと。

↓なんか色あせた感じ？

（名古屋市内にて）

やー、あれですね。

比較的キレイに撮れているときとそうでない時があります。

実は知らなかったんですが、撮影済みのフィルムって比較的すぐ現像しないとダメなんですね。

買ったフィルムもそもそも古めだし。

噂によると撮影後１週間以内くらいに現像したほうが良いとか？

そりゃ全然ダメでした。

数ヶ月放置とかしてました。

だってそんなに撮らないし・・・。

しかも使ったフィルムの種類とかきちんと管理してなかったせいで、どの写真がどのフィルムで撮ったかもうわからん。

今ボディに入っているフィルムは既に数ヶ月経ってるので・・・、とりあえず次は、セット→撮影→現像を１週間以内にやってみようと思います。

果たして「昭和っぽさ」からは脱却できるでしょうか。

とりあえずなんかコツを知っている方教えてください。。

＜ルール＞次の目標

１．フィルムはカメラ屋でちゃんとしてそうなのを買う

２．開封後１週間以内に使いきって現像に出す

３．現像後はスリーブから出してすぐにスキャンする（時間がたつと何かと汚れたりするので）

_ [日記][旅行記] 八重山諸島からの南十字星

去年はお休みでしたが、今年はまた八重山諸島に行ってきました。

詳しくはまたの機会に書くとして、そのとき見た夜空のお話。

普段、八重山に旅行する場合日程が選べるならば新月の頃を選んでいたのですが、今回は満月でした。

新月の日を選んでいたのはもちろん星がよく見えるから。

そして出来れば南十字星（正式には「みなみじゅうじ座」）を見たかったからです。

沖縄では海上が水蒸気でモヤがかかっている事が多く実のところ１度も見えたことは無かったのですが。

そんな訳で、今回は星は見えないだろうと思ってました。

でも行ってから気づいたんですが、満月の日って日の入りのしばらく後に月が出るんですね。

沖縄では日が長いので完全に暗いのは１〜２時間ですが、月が出たらちょうど道も明るくなって安全に宿まで戻れるしむしろちょうどいいです。

てな訳で夕食の後夜空観察に行きました。

こんな時手元に星座早見盤があれば便利なんでしょうけど、本州とは正座の全然見え方が違うのでなかなか大変ですね。

沖縄版ってのもあるんでしょうけど、どこに売ってるのかな。。

で、何の準備も知識も乏しい自分にはまったく正座が判らない状態に。

普段見える有名な星座がひとつも発見できないわけです。

さすが南国。

しかしよくよく見てみると・・・

（竹富島より西方向）

・・冬の大三角が見えていました。（シリウス−ベテルギウス−プロキオン）

しかしオリオン座が地平線の下です。オリオンが見えないとシリウスさえ見つからないとは。。

シリウスは全天で一番明るい星なので、逆に今住んでいる名古屋のほうが簡単に見つかりますね。

ほとんど他の星見えないですし。

写真には西表島の街灯って書きましたが、手前にある小浜島の灯りかもしれないです。

この程度の光でもやっぱり邪魔は邪魔です。

で、すっかり忘れていた南十字星なのですが、ふと南の方角を見てみたら・・・!!

・・・なんだよ。普通に見えてるじゃん。。

むしろ今まで１度も見えなかったのが運が悪かったのでしょうか。

判りにくい人のために図付き。

アクルックスの下はすぐにもう丘だったりして水平線に向いていない位置からだったんですが、よく見えました。

思ったより高い位置まで来るんですね。

後で写真をみたらω星団(Wikipedia)まで写っていたようです。

肉眼で見えるほど明るいので古代には単体の恒星扱いだったそうです。

星を見るには本当は空気の乾燥した冬が良いらしいのですが、それは寒いので南国の夏頃がいいですね。

最低３０分くらいは見てないと目が慣れませんので寒いと耐えられませんｗ

５月だったので桟橋でひとり、ぼーっとしてましたが風が気持ちよかったです。

流星や人工衛星もたくさん見えました。

もう少し写真をキレイに撮れると良いんですが、デジカメではむずかしいですね。

明るいレンズ使って感度落とせばもっとノイズ減るかもしれません。

というか暗くて絞りも開放し忘れてました。

星の撮影も今後の課題です。

_ [日記] 新生銀行のログインが面倒すぎる件についてセキュリティの考察

新生銀行のＷｅｂログインがとても面倒です。

逆に言えばそれだけセキュアかと言えばそうでも無い気がするのですよね。

新生銀行のＷｅｂログインには以下が必要です。

・店番号、口座番号

・暗証番号

・パスワード

・暗号表から３つの数字

これらをスクリーンキーボードから入力

これだけ面倒な金融機関は僕の知る限り新生銀行がダントツです。

他の多くの銀行などの場合、口座番号もしくは顧客番号＋パスワードでログインできて、出金や解約を伴う処理は追加で乱数表やワンタイムパスワードを要求されるパターンです。

ただログインするだけでこれだけ面倒だと、とてもメインバンクとしては使えないと思うのですが・・・。

面倒な分セキュアかと言えばそれも疑問です。

残高確認するだけで毎回乱数表を取り出すのは危ない気がします。

情報を盗み取ろうとする者にとってはチャンスが増えるわけです。

暗証番号もたかだか４桁の数字をログイン時に増やすメリットよりも、ＡＴＭでの最後の砦である４桁の数字を不用意にパソコン上で入力する機会を作る事のほうが問題ではないでしょうか。

その分パスワードを長くすれば済む話なんだし。

また、あんまり面倒な認証システムはユーザーが間違った運用をして返って危ないという側面もあります。

面倒すぎてログイン情報を自動入力するソフトまで作られているようです。

なんでこんなシステムになってしまったのか判りません。

たぶん以前のシステムを改修してきたら結果的にこうなった、なんだと思いますが改善を望みたいところです。

やはりセキュリティと利便性のバランスを考えるとワンタイムパスワード方式が候補に上がりますね。

例えばジャパンネット銀行や野村證券がこの方式です。

ログインだけならパスワードだけ、実際の取引にはワンタイムパスワードを使う方式です。

ワンタイムパスワードの代わりに乱数表を使う所が多いですね。

でも暗号表って保管がけっこう面倒ですし、ふとしたスキにデジカメで撮影されたらそれでおしまいです。

また、ローカルマシン上でキー入力を何回か傍受したら埋められてしまいます。

利便性についてはワンタイムパスワード生成機は持ち歩くのが面倒というのもあるので好みがあると思います。

また、パスワードだけで全て済んでしまうところもあります。

パスワードは複数あって使い分けるようになっている事がほとんどですが、どちらにしても一度でも入力した情報を取られてしまったらおしまいです。

何も持たなくても良いので便利かもしれませんがセキュリティ的にはちょっと心配ですね。

_ [日記][コンピュータ] ハンガリアン記法（アプリケーションハンガリアン）を使おう

いまだに、というべきなのかどうか分りませんが、プライベートでも仕事でもよく使う言語はＣ言語とＣ＋＋です。

ＰＧというわけではないので道具として使うだけで専門家ではありません。

他にまぁ扱える、程度で知っている言語というとPerl、ruby、Java、ActionScript、、あれ意外と知らないなぁ、まぁいいか。

プログラミング言語の用途としては色々あるんですが、最初に入ったのがMS Windowsだったせいもあってなんとなくハンガリアン記法っぽく書く癖がついてしまっています。

しかもみんなに嫌われるシステムハンガリアンです。

例えば整数型の変数の頭にはiとかnとか付けるというアレです。

Microsoftは少し前までこれを使っていて、例えば時刻を表すSYSTEMTIME構造体は以下のように定義されています。

typedef struct _SYSTEMTIME {

　WORD wYear;

　WORD wMonth;

　WORD wDayOfWeek;

　WORD wDay;

　WORD wHour;

　WORD wMinute;

　WORD wSecond;

　WORD wMilliseconds;

} SYSTEMTIME;

WORD型の変数だから頭に全部wが付けられています。

でもこれを推奨したいわけじゃありません。

本来Ｃ言語などは型付けが言語で定義されているのでそんな事を変数名で区別する必要がないし、後から型を変える時などのメンテナンス性が下がり良くないという批判があります。

見た目もバッチイですしね。

現在ではマイクロソフトも.NET Frameworkになってからはハンガリアン記法の使用を禁止しています。

■一般的な名前付け規則 【MSDN】

＞ハンガリー表記法は使用しないでください。

だからハンガリアン記法は使うの止めましょう・・・・ってそうじゃありません。

ハンガリー記法はマイクロソフトの技術者、チャールズ・シモニイが考案し彼がハンガリー人だったのでこんな名前で呼ばれるようになりました。

この人はWordなどの開発に携わった人で優れた実績を上げました。

彼が考えたハンガリー記法の本来意図は変数の種類・用途を示すことであって、実は型を示すことではありませんでした。

種類というのの例をあげると、座業系などがあげられます。

仮にテレビのようにピクセル比が１：１でないディプレイがあったとします。

更にスケーリングも違うとしましょう。

1024×768で出力した映像が1920×1080のパネルに表示されるとかですね。

前者を内部座標系、後者を表示座標系と呼ぶことにすると、出力座業系のＸ座標と表示座標系のＸ座標みたいなものは全く無関係の数値で直接足したり引いたりしてはいけない数値だという事になります。

しかし、人間うっかりミスをします。

直接代入してはいけないはずの表示座標系の数値を出力座業系の変数に代入してしまったりするというミスが発生するということです。

int local_pos = 100; //表示位置（内部座標系）

int display_pos = 200; //ディスプレイの表示位置（表示座標系）

int scraoll = 10; //スクロール量（内部座標系）

...色々な処理...

localpos += scraoll;

...色々な処理...

display += scraoll; //おかしい

いい加減な例ですが、おかしな部分があります。

「スクロール量」というのが内部座標でのものなのか表示座標系でのものなのかよくわからなくなってしまっています。

この場合、どちらの変数も同じ型、例えばintで宣言されていたとするとコンパイラは何のエラーも出しません。

人間がその行だけを見ても間違いかどうか分りません。

そこでハンガリアン記法の出番です。

上の例では例えば以下のようにします。

int iLocalPos = 100; //表示位置（内部座標系）

int oDisplayPos = 200; //ディスプレイの表示位置（表示座標系）

int iScroll = 10; //スクロール量（内部座標系）

...色々な処理...

iLocalPos += iScroll;

...色々な処理...

oDisplayPos += LocalposToScreenPos(iScroll);

内部座標系の変数にはiを表示座標系の変数にはoを頭に付けるというルールにしました。

もし、間違えて iLocalPos += oScroll; みたいな事を書いてしまったとしてもその行だけを見れば間違っていることが分ります。

座標系を混ぜてしまっているからです。

LocalposToScreenPos(int val)という関数もoLocalposToScreenPos(int iVal)なんてすれば更に明快かもしれません。

oDisplayPos += oLocalposToScreenPos(iScroll);

これが本来チャールズ・シモニイが意図したハンガリアン記法でした。

同じ型でも混同してはいけない変数の意味（種類）を変数名に与えるというアイデアです。

これなら誰が見ても変数の意味が明確に分ります。

現在ではアプリケーションハンガリアンと呼ばれたりします。

これを知った時はちょっと衝撃でしたね。

実際最初にプログラミングを始めた頃はこの手のミスで痛めにあっていましたから。

ハンガリア人すげー。

大変すばらしいアイデアなのですが、彼はひとつミスをしました。

変数の意味を "type" という言葉を用いて書いて説明してしまったそうなのです。

これが変数の"型"と混同されやがてはハンガリアン記法＝システムハンガリアンという誤解が生まれたそうなのです。

しかもマイクロソフト自身もそれを使ってしまったためこの概念は広まってしまいました。

といわけです。（・・・何がだろう）

要するに、アプリケーションハンガリアンはとても有用だということです。

僕はシステムハンガリアンとアプリケーションハンガリアン混ぜ混ぜですが、システムハンガリアンはＣ言語でWindowsのAPIを直接いじるプロジェクトのみで使用するようにしています。

APIを直接呼ぶことが多いので自然とMicrosoftの型に合わせてしまうんです（半分言い訳）

システムハンガリアンはＣ言語以外では使うことは少ないと思いますし、Ｃ言語でもあまり意味がないというのは前述のとおりです。

でもアプリケーションハンガリアンは違います。

場合にもよりますが、ものすごく有用です。

JavaでもPerlでも。

いくつもの変数の"意味"があるプログラムをされるアナタ。

ハンガリアン記法はいかがでしょうか。

上記のことは以下に詳しく書かれています。

■Making Wrong Code Look Wrong 【Joel Spolsky】

■間違ったコードは間違って見えるようにする（和訳されたもの）