・・・という事に最近気づきましたよ!
僕は普段から水分をたくさん飲むんですよね。
だいたいは冷たいお茶で、ブランドは「おーいお茶」のペットボトル。
この辺けっこう拘りがあって、というか慣れてしまっていてか他のはなんか嫌。
おーいお茶の缶ですらペットボトルのと味が違って違和感があります。
基本デスクワークなのに仕事中によく飲みます。
だいたい500mlのを1日3本くらい。
職場では1本140円で売っているので1日420円も使ってることになりますね。
これはいかん、いまの時代節約せねば・・・!
と思って水筒を用意して2Lのペットボトルから移し変えて持っていくというのをやってみたんですが、肝心の2Lのペットボトルが近くのスーパーで売ってない事があるのと、箱で買うとすんげえ重いのでいつのまにかまた会社で買うようになってしまいました。
で、最初の行の話につながるわけです。
Amazonで送料無料で(Amazonプライムだし)入手できればきっと節約の達人に近づけるはず!
(*達人はきっとペットボトル飲料なんて飲まない)
さて、肝心の値段ですが、今日現在では2Lペットボトル6本セットが1,037円で売っています。
12Lで1,037円(;・∀・)!?
12Lといえば12000mlですよ! 判りやすく言えば120デシリットルですよ! (わかりやすくない)
なんか心の暗算でかなり安いような・・。
普段の買い物・・・500ミリリットルで140円。1ml辺り 28銭
Amazon・・・・・・120000ミリリットルで1,037円。 1ml辺り 8銭7厘
はい、3分の1以下の値段でした。
調べてみたらAmazonじゃなくても売ってますね。
送料の事考えるとAmazonがよさげですが。
そもそも、ペットボトル飲料を外で買って飲むなんてことが贅沢すぎるという事実を忘れてましたよ。
子どもの頃なんてそんな事あり得なかったのに。
いつのまにか浪費体質が染み付いてしまっていますね。
しかし、今度はペットボトルを捨てるのが面倒になりそうだなぁ・・・。
やっぱり家で麦茶かなんか作るような生き方に戻るべきなのでしょうか。
#今年のテーマは節約で。
お金が無いというわけじゃないんですが、制限つけてなにかやると面白いので。
というわけで、節約のための浪費は惜しまない方向でw
いまだに、というべきなのかどうか分りませんが、プライベートでも仕事でもよく使う言語はC言語とC++です。
PGというわけではないので道具として使うだけで専門家ではありません。
他にまぁ扱える、程度で知っている言語というと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が付けられています。
でもこれを推奨したいわけじゃありません。
本来C言語などは型付けが言語で定義されているのでそんな事を変数名で区別する必要がないし、後から型を変える時などのメンテナンス性が下がり良くないという批判があります。
見た目もバッチイですしね。
現在ではマイクロソフトも.NET Frameworkになってからはハンガリアン記法の使用を禁止しています。
>ハンガリー表記法は使用しないでください。
だからハンガリアン記法は使うの止めましょう・・・・ってそうじゃありません。
ハンガリー記法はマイクロソフトの技術者、チャールズ・シモニイが考案し彼がハンガリー人だったのでこんな名前で呼ばれるようになりました。
この人はWordなどの開発に携わった人で優れた実績を上げました。
彼が考えたハンガリー記法の本来意図は変数の種類・用途を示すことであって、実は型を示すことではありませんでした。
種類というのの例をあげると、座業系などがあげられます。
仮にテレビのようにピクセル比が1:1でないディプレイがあったとします。
更にスケーリングも違うとしましょう。
1024×768で出力した映像が1920×1080のパネルに表示されるとかですね。
前者を内部座標系、後者を表示座標系と呼ぶことにすると、出力座業系のX座標と表示座標系のX座標みたいなものは全く無関係の数値で直接足したり引いたりしてはいけない数値だという事になります。
しかし、人間うっかりミスをします。
直接代入してはいけないはずの表示座標系の数値を出力座業系の変数に代入してしまったりするというミスが発生するということです。
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" という言葉を用いて書いて説明してしまったそうなのです。
これが変数の"型"と混同されやがてはハンガリアン記法=システムハンガリアンという誤解が生まれたそうなのです。
しかもマイクロソフト自身もそれを使ってしまったためこの概念は広まってしまいました。
といわけです。(・・・何がだろう)
要するに、アプリケーションハンガリアンはとても有用だということです。
僕はシステムハンガリアンとアプリケーションハンガリアン混ぜ混ぜですが、システムハンガリアンはC言語でWindowsのAPIを直接いじるプロジェクトのみで使用するようにしています。
APIを直接呼ぶことが多いので自然とMicrosoftの型に合わせてしまうんです(半分言い訳)
システムハンガリアンはC言語以外では使うことは少ないと思いますし、C言語でもあまり意味がないというのは前述のとおりです。
でもアプリケーションハンガリアンは違います。
場合にもよりますが、ものすごく有用です。
JavaでもPerlでも。
いくつもの変数の"意味"があるプログラムをされるアナタ。
ハンガリアン記法はいかがでしょうか。
上記のことは以下に詳しく書かれています。
■Making Wrong Code Look Wrong 【Joel Spolsky】
■間違ったコードは間違って見えるようにする(和訳されたもの)
新生銀行のWebログインがとても面倒です。
逆に言えばそれだけセキュアかと言えばそうでも無い気がするのですよね。
新生銀行のWebログインには以下が必要です。
・店番号、口座番号
・暗証番号
・パスワード
・暗号表から3つの数字
これらをスクリーンキーボードから入力
これだけ面倒な金融機関は僕の知る限り新生銀行がダントツです。
他の多くの銀行などの場合、口座番号もしくは顧客番号+パスワードでログインできて、出金や解約を伴う処理は追加で乱数表やワンタイムパスワードを要求されるパターンです。
ただログインするだけでこれだけ面倒だと、とてもメインバンクとしては使えないと思うのですが・・・。
面倒な分セキュアかと言えばそれも疑問です。
残高確認するだけで毎回乱数表を取り出すのは危ない気がします。
情報を盗み取ろうとする者にとってはチャンスが増えるわけです。
暗証番号もたかだか4桁の数字をログイン時に増やすメリットよりも、ATMでの最後の砦である4桁の数字を不用意にパソコン上で入力する機会を作る事のほうが問題ではないでしょうか。
その分パスワードを長くすれば済む話なんだし。
また、あんまり面倒な認証システムはユーザーが間違った運用をして返って危ないという側面もあります。
面倒すぎてログイン情報を自動入力するソフトまで作られているようです。
なんでこんなシステムになってしまったのか判りません。
たぶん以前のシステムを改修してきたら結果的にこうなった、なんだと思いますが改善を望みたいところです。
やはりセキュリティと利便性のバランスを考えるとワンタイムパスワード方式が候補に上がりますね。
例えばジャパンネット銀行や野村證券がこの方式です。
ログインだけならパスワードだけ、実際の取引にはワンタイムパスワードを使う方式です。
ワンタイムパスワードの代わりに乱数表を使う所が多いですね。
でも暗号表って保管がけっこう面倒ですし、ふとしたスキにデジカメで撮影されたらそれでおしまいです。
また、ローカルマシン上でキー入力を何回か傍受したら埋められてしまいます。
利便性についてはワンタイムパスワード生成機は持ち歩くのが面倒というのもあるので好みがあると思います。
また、パスワードだけで全て済んでしまうところもあります。
パスワードは複数あって使い分けるようになっている事がほとんどですが、どちらにしても一度でも入力した情報を取られてしまったらおしまいです。
何も持たなくても良いので便利かもしれませんがセキュリティ的にはちょっと心配ですね。
去年はお休みでしたが、今年はまた八重山諸島に行ってきました。
詳しくはまたの機会に書くとして、そのとき見た夜空のお話。
普段、八重山に旅行する場合日程が選べるならば新月の頃を選んでいたのですが、今回は満月でした。
新月の日を選んでいたのはもちろん星がよく見えるから。
そして出来れば南十字星(正式には「みなみじゅうじ座」)を見たかったからです。
沖縄では海上が水蒸気でモヤがかかっている事が多く実のところ1度も見えたことは無かったのですが。
そんな訳で、今回は星は見えないだろうと思ってました。
でも行ってから気づいたんですが、満月の日って日の入りのしばらく後に月が出るんですね。
沖縄では日が長いので完全に暗いのは1~2時間ですが、月が出たらちょうど道も明るくなって安全に宿まで戻れるしむしろちょうどいいです。
てな訳で夕食の後夜空観察に行きました。
こんな時手元に星座早見盤があれば便利なんでしょうけど、本州とは正座の全然見え方が違うのでなかなか大変ですね。
沖縄版ってのもあるんでしょうけど、どこに売ってるのかな。。
で、何の準備も知識も乏しい自分にはまったく正座が判らない状態に。
普段見える有名な星座がひとつも発見できないわけです。
さすが南国。
しかしよくよく見てみると・・・
(竹富島より西方向)
・・冬の大三角が見えていました。(シリウス-ベテルギウス-プロキオン)
しかしオリオン座が地平線の下です。オリオンが見えないとシリウスさえ見つからないとは。。
シリウスは全天で一番明るい星なので、逆に今住んでいる名古屋のほうが簡単に見つかりますね。
ほとんど他の星見えないですし。
写真には西表島の街灯って書きましたが、手前にある小浜島の灯りかもしれないです。
この程度の光でもやっぱり邪魔は邪魔です。
で、すっかり忘れていた南十字星なのですが、ふと南の方角を見てみたら・・・!!
・・・なんだよ。普通に見えてるじゃん。。
むしろ今まで1度も見えなかったのが運が悪かったのでしょうか。
判りにくい人のために図付き。
アクルックスの下はすぐにもう丘だったりして水平線に向いていない位置からだったんですが、よく見えました。
思ったより高い位置まで来るんですね。
後で写真をみたらω星団(Wikipedia)まで写っていたようです。
肉眼で見えるほど明るいので古代には単体の恒星扱いだったそうです。
星を見るには本当は空気の乾燥した冬が良いらしいのですが、それは寒いので南国の夏頃がいいですね。
最低30分くらいは見てないと目が慣れませんので寒いと耐えられませんw
5月だったので桟橋でひとり、ぼーっとしてましたが風が気持ちよかったです。
流星や人工衛星もたくさん見えました。
もう少し写真をキレイに撮れると良いんですが、デジカメではむずかしいですね。
明るいレンズ使って感度落とせばもっとノイズ減るかもしれません。
というか暗くて絞りも開放し忘れてました。
星の撮影も今後の課題です。
§ LiedgeTit [is tramadol stronger than percosets tramadol in a pee tes..]