デジタル一眼レフ(EOS40D)のカメラケース

デジタル一眼レフは普通のコンパクトデジカメに比べて非常にデカイです。
その為、持ち歩く時もポケットに入れる事なんで到底出来ません。

そこで持ち運び用のケースが必要になるのですが、ケースにも色々な種類があります。
リュックタイプ、ウェストポーチタイプ、ハードケースタイプなどなど。。。
どれもレンズと一緒にしまえるタイプが多いですが、自分が使っているのは上記のどれでもありません。

自分が使ってるのは、ソフトタイプのケースです。
カメラケース

普段はコレに入れて、肩からかけて持ち運んでます。。。
理由は以下の通り
1.非常にコンパクトにまとまる。
2.すぐに取り出せて撮影できる。

1については、自分はTAMRON 18~270mmのレンズを常に付けているので、レンズを交換する頻度が非常に低いです。(18~270mmまでズームが効くので・・・)
その為、カメラ本体と交換レンズは別々の袋に入れて持ち歩いているので、必要に応じてカメラのみ、カメラと交換レンズも一緒にと分けられるメリットがあります。
また交換レンズを持ち運ぶ場合は、普通のバックに入れて持ち運んでいます。

2については、ソフトケースを外せばすぐに撮影可能なので非常に便利です。
※ウェストポーチタイプでもすぐに撮影できそうですが、リュックタイプとかに比べれば速いです。

ただ、デメリットもあります。
常にカメラを肩からかけている状態なので、長時間持ち歩くのは疲れます。
ハイキングや登山には向いてません。また突然雨が降ったらケースが濡れて、カメラ本体がピンチになります。

ただ自分の場合は、1歳の子供を連れての移動なので、長時間歩く事はありません。
結果として、このスタイルが自分にとって一番ベストって感じになってます。

VB.NETの技術メモ~DBアクセスの高速化(バインド変数の使用)後編~

my-hobby : VB.NETの技術メモ~DBアクセスの高速化(バインド変数の使用)前編~では、DBアクセス時に動的にSQLを生成したケースと、バインド変数を使用してSQLを生成したケースを紹介しました。
本編では、計測結果を比較・検証したいと思います。

先ずは、動的にSQLを生成したケースの結果(処理時間)は以下の通りでした。
交互にそれぞれ3回同じ処理を行いました。
●1回目(動的にSQLを生成したケース)
[vbnet]
2010/01/19 21:09:13
2010/01/19 21:09:22:700000
[/vbnet]

●1回目(バインド変数を使用してSQLを生成したケース)
[vbnet]
2010/01/19 21:09:34
2010/01/19 21:09:42:700000
[/vbnet]

●2回目(動的にSQLを生成したケース)
[vbnet]
2010/01/19 21:10:23
2010/01/19 21:10:32:700000
[/vbnet]

●2回目(バインド変数を使用してSQLを生成したケース)
[vbnet]
2010/01/19 21:10:34
2010/01/19 21:10:41:700000
[/vbnet]

●3回目(動的にSQLを生成したケース)
[vbnet]
2010/01/19 21:11:11
2010/01/19 21:11:20:700000
[/vbnet]

●3回目(バインド変数を使用してSQLを生成したケース)
[vbnet]
2010/01/19 21:11:45
2010/01/19 21:11:52:700000
[/vbnet]
※2行目の700000という数字は、DBから郵便番号(7桁)が10万回読み込めた事を証明しています。

動的にSQLを生成したケースは平均9秒、バインド変数を使用してSQLを生成したケースは平均7.3秒。
う~ん微妙な感じ。。。
数件の処理でこの違いであれば、かなりの改善ということになりますが 、10万件の処理でこの結果ということは、今回のテストケース自体が簡単過ぎたからでしょうか?
もう少し複雑な処理や、数百万件という大量のデータを扱う様なケースであれば、更なるパフォーマンス向上が見込めるのかも知れません。
逆に言えばこの様な単純な処理でも、結果にここまで差が出た事は、それなりにパフォーマンス向上の効果が出たと言えるのではないでしょうか?

VB.NETの技術メモ~DBアクセスの高速化(バインド変数の使用)前編~

アプリケーションのパフォーマンスでボトルネックになりやすい要因の一つに、データベース(DB)へのアクセスがあります。
今回はDBへのアクセス(特にSQL文の発行)に関して、バインド変数を使ったパフォーマンス向上の方法を紹介し、それぞれの方法でどれだけパフォーマンスに違いが出るのかを検証してみたいと思います。
なお、前提事項として、以下の開発環境で検証をしました。
・言語:VB.NET
・フレームワーク:.NET Framework 2.0
・DBサーバ:SQL Server 2005 Express Edition

検証を行なうに当たり大量のデータが必要なので、zpnaviでもお世話になっている、郵便番号検索 – 日本郵便より提供されている住所データを使用します。
10万件の住所データに対して、1から順番にシーケンス番号を振ります。 そのデータを1件づつ読み込んで、10万件目が終わるまでの処理時間を計測します。

●動的にSQLを生成したケース
動的にSQLを生成したケースでは、以下の様に動的にSQL文を組み立てて、その内容に対してDBにSQLを発行します。

[vbnet]
Imports System.Data.SqlClient
Imports System.Text

sub Test()
Debug.Print(Now)

Dim SqlConn As New SqlConnection
Dim SqlCmd As SqlCommand
Dim SqlRd As SqlDataReader
Dim StSQL As String
Dim i As Long
Dim TownName As New StringBuilder

SqlConn.ConnectionString = "(DB接続文字列)"
SqlConn.Open()
SqlCmd = SqlConn.CreateCommand

For i = 1 To 100000
StSQL = "SELECT NEW_ZIP FROM T_ADDRESS WHERE SEQ = " & i
SqlCmd.CommandText = StSQL
SqlRd = SqlCmd.ExecuteReader
SqlRd.Read()
TownName.Append(SqlRd(0).ToString)
SqlRd.Close()
Next
SqlCmd.Dispose()
SqlConn.Close()
Debug.Print(Now & ":" & TownName.Length)

End Sub
[/vbnet]

●バインド変数を使用してSQLを生成したケース
[vbnet]
Imports System.Data.SqlClient
Imports System.Text
sub Test()
Debug.Print(Now)

Dim SqlConn As New SqlConnection
Dim SqlCmd As SqlCommand
Dim SqlPrm As SqlParameter
Dim SqlRd As SqlDataReader
Dim StSQL As String
Dim i As Long
Dim TownName As New StringBuilder

SqlConn.ConnectionString = "(DB接続文字列)"
SqlConn.Open()
SqlCmd = SqlConn.CreateCommand
SqlPrm = SqlCmd.Parameters.Add("@SEQ", SqlDbType.Int)
SqlPrm.Direction = ParameterDirection.Input
StSQL = "SELECT NEW_ZIP FROM T_ADDRESS WHERE SEQ = @SEQ"
SqlCmd.CommandText = StSQL

For i = 1 To 100000
SqlPrm.Value = i
SqlRd = SqlCmd.ExecuteReader
SqlRd.Read()
TownName.Append(SqlRd(0).ToString)
SqlRd.Close()
Next
SqlCmd.Dispose()
SqlConn.Close()
Debug.Print(Now & ":" & TownName.Length)
End Sub
[/vbnet]

なお、上記のプログラムを作成するに当たり、.NET アプリケーションのパフォーマンスとスケーラビリティの向上 – 第 12 章 「ADO.NET パフォーマンスの向上」を参考にしました。

前者と後者のプログラムの違いは、各プログラムの19行目のDBに発行するSQL文が動的か、固定かの違いです。

この様な実装方法にする理由はmsdnのサイトには記載されていませんでしたが、Oracleの場合でもバインド変数を使った実装の方が、パフォーマンスがいいと言われています。
具体的な理由もありました。

Oracle Database 10gがOracle Database 10gがSQL文を受け取った場合、共有プール(メモリ領域)をチェックして、文がすでに存在しメモリに格納されているかどうかを確認します。文がメモリに存在し、Oracle Database 10gがその文を再利用できる場合、データベースは文を解析および最適化するタスクをスキップできます。バインド変数を使用すると、SQL文がメモリに格納される可能性が大幅に高まります。これによって、そのSQL文を必要とする次の操作で迅速にそのSQL 文を使用できます。
※Oralceでバインド変数を使用する為には、「Oracle.DataAccess」コンポーネントを参照追加する必要があります。

上記の内容は、値のバインドの「バインド変数が重要な理由」より抜粋

SQL Serverの場合は上記の様な具体的な理由までは記述されていませんでしたが、恐らく同様の理由だと思います。

では動的にSQLを生成したケースと、バインド変数を使用してSQLを生成したケースとではどれくらいパフォーマンスに違いが出るのか?
結果はVB.NETの技術メモ~DBアクセスの高速化(バインド変数の使用)後編~ に掲載しています。

mixiサンシャイン牧場で夫婦対決してみごと敗北

ウチの奥さんとどちらが早く地位レベル30に達するかで対決してましたが、年明けついに決着が付きました。
結果は見事に完敗しました。

しかも、畑に関しては7000ポイント近くまで経験値を離されてました。
原因はすぐに分かりました。
花の栽培が思いのほか経験値が稼げなかった事。

竹はmy-hobby mixiサンシャイン牧場で竹を育ててみたでも紹介したように、非常に効率よく経験値を稼げる半面、収穫する時間の間隔が短い(ほぼ12時間おきに熟成する)為、日中仕事をしている自分にとっては不都合な作物でした。
そこで、ほぼ24時間という間隔で開花する「花」に栽培を切り替えたのですが、年末の不規則な生活のせいで収穫タイミングが合わず、結局大きく差をつけられてしまう事になりました。

そして負けの代償に、正月早々、食べ放題バイキングをおごるハメになりました。。。

今回負けて思った事
・お金を稼ぐなら花を栽培するのがベスト
・経験値を稼ぐなら竹を栽培するのがベスト
※あくまで主観です

次は別のゲームで勝負します!

帰省時に箱根駅伝に遭遇

新年明けましておめでとうございます。
今年もmy-hobyをよろしくお願いします。

1/3にウチの奥さんの実家に帰省した際に、ちょうど箱根駅伝のランナーと遭遇しました。
場所は戸塚中継所付近。

その時クルマに乗っていて、2車線ある内の右車線だけが渋滞していて、ラジオの実況からも箱根駅伝の選手がこの近くを走っているという情報をキャッチし、奥さんも大興奮!
我がクルマも右車線の渋滞にわざと合流し、箱根駅伝の選手が来るのを待ちました。
暫くして拡声器を付けた広報車らしきクルマがやってきて、「もうすぐ駅伝の選手が通過しま~す」とのアナウンス。
助手席に座っていた奥さんが、後部座席に置いていたデジタル一眼レフを取り出し、スタンバイ完了。

先導パトカーが見えた後、白バイが・・・
その後ろに選手の姿が見えました。
東洋大学の選手だ!!!
駅伝

箱根駅伝をナマで見るのは初めてだったので、自分も大興奮!!!
こっちに向かって走ってきたと思いきや、あっという間に通り過ぎて行きました。
速い!
ちなみに、自分のクルマは停止していたので、自分のクルマのスピードによる錯覚では無いです。。。

それから5分ほど経過して、2位以降の選手が続々と通過していきました。
結局全選手が通過するのを見て、そのまま帰省の途に着きました。

年の初めからこの様な偶然に出会えるとは・・・今年もいい年になればいいなと思いました。
でも次の日、カゼをひいてしまいました。