Feb 26, 2006
Feb 25, 2006
CanoScan 9950FV
フィルム時代の画像データをどうしてもデジタル化したい、ということで、スキャナを5年ぶりにゲット。購入したのはキヤノンの最上位モデル「CanoScan 9950FV」。
第一印象は、「で、デカい！！」。箱はiMacG5のやつかと思うくらいデカイし、本体も分厚くてデカイ。でも、どうせ買うなら安物買いの銭失いにならないようにということでこれにしたので置き場所は我慢。
早速古い35mmのフィルムをマウント、スリーブ、ともに取り込んでみました。なんといっても圧巻なのは「30コマ一括スキャン」。うーんこれはスゴい。画質もなかなかで、褐色補正、ゴミ傷除去機能もあるのがGOOD。これでフィルムスキャン専用でもないんですよね〜。いやはや。
昔購入したこれより高い金出して買ったフィルムスキャナーでは1スリーブずつしは取り込めなかった(しかも画質はこの9950FVより劣る)ことを考えると隔世の感があります。
これで手持ちの画像データは全てiPhotoで管理する方向に持って行けそうです。いやー嬉しい。
P_BLOG関連：カレンダープラグイン高速化
ヘチマ_BLOGさんで高速化が施されたP_BLOGのカレンダープラグインが公開されていました。(hetimaさん感謝！)
さっそくP_BLOG Projectの方でも紹介しましたが、私のほうでもローカルの最新版に取り込んで稼働チェック。なるほど、確かにベンチマークの数値を見ると高速化してます。いつもは「0.4x〜0.7x」秒くらいですが、最高「0.2527秒」という数値をたたき出しました。 
ページ生成の時間はエントリーの内容や表示ページ数、サーバーの性能などによっても違ってくるのでどの環境でもこの数値が出ることはないですが、同じ環境でテストしてみると違いが分かりますね。いやはや素晴らしい。P_BLOGユーザーのみなさん、Must-Haveです。さっさと標準のカレンダープラグインと差し替えましょう。
次のリリースでは標準搭載します。
早速コードのほうをチェックしましたが、なるほど、SQLのほうで「DAYOFMONTH」をつかって取り出してグループ化して配列に格納、ですか。この辺はやはりコーディングのセンスと知識ですねぇ。(関心)
早速LOGGiXのほうのカレンダープラグインもこれをベースに修正しようとしてるのですが、んーSQLiteって、DAYOFMONTHによるクエリーをサポートしてない。。DAYOFMONTHなしで出来る方法はないか模索しなければ。
Feb 24, 2006
JAM Antenna、障害発生(復旧しました)
当サイトのアンテナ「JAM Antenna」が現在上手く稼働してません。ご利用の方はご了承ください。
とりあえず原因は分かりましたが今のところ修正する時間が無いので今日の夜あたりにでも直したいと思います。それまでは真っ白画面が表示されつづけると思います。。 
追記 (18:10)：
時間が出来たので修正しました。ついでに、と言ってはなんですが、旧サイト(http://pbx.homeunix.org/tpj/jam_log/index.php)のほうの稼働を一時停止することにしました。リンクをクリックしてもこちらにリダイレクトされるようにしました。あと、過去ログのパーマリンク(恒久URI)のほうもこちらの過去ログにリダイレクトされるように仕込みましたので過去の記事にリンクを張られたサイトからはリンク切れを起こさず飛ぶようになってます。
これは運営するサイトがP_BLOG Project、当サイト、そして今後立ち上げる予定のLOGGiX Projectのサイトと複数あるためで、沢山のサイトを管理・メンテするのが時間的制約もあって大変、というのが理由です。大昔のサイトは未だにそのまま残してますが、あそこはもう2年前から完全放置プレイで、多少情報の不具合や修正が必要な箇所などもあると思いますが今後おそらく永遠に更新する事はないと思います。「クールなURIは変わらない」という言葉がありますが、クールじゃないURIも変わらない状況もありますのでそこのところご了承を。 (未だにあそこ経由で来る人が結構いるのでお知らせがてらに。。)
Feb 22, 2006
トリノオリンピック
なんかここのところ色々とやる事が立て込んでて楽しみにしていたこのトリノオリンピックまともに見れてないのが悔しいんですが...
今大会は始まる前はフィギュア女子の選考時のドタバタがあったのでフィギュアばかりが取りざたされていましたね。(私は参加年齢枠をもっと下げるべきだと思ってます。だいたい24才で「ベテラン」とか言われるようなピークが早い競技というのが分かっているのに未だに15才ですからね。)
...とかなんとか自分の意見を誰に向けてともなく考えてたのですが、ふたを開けてみると「そうだよ、他にも競技はいっぱいあったんだよ！」という感じですねー。
今回の大会での私の中での大ヒットはなんといっても、
これに尽きる気がします。理由はもう、
ただひたすらこれだけ。これだけでもう十分な理由です。特にタイムトライアルじゃなくて複数でレースするやつ。あれ、最高です。夏季オリンピック大ファンである私はこれまで冬季オリンピックの競技で純粋に「かっこいい」と思った競技がなかったのもあるんですが、なんか日本代表の藤森選手のルックスも良いし、ただ単に速い選手が勝つ、という単純なのでもなくて最後まで勝負が分からないところも醍醐味だったりしますね。
あと、カーリングを見逃したのが悔やまれます。なんかすごい人気で「日本全国カーリングブーム到来！」というくらい盛り上がってるようで...うーん、これまでまったく興味が湧かなかった競技なんですが、観た人に言わせるとハマるとすごい面白いみたいですねー。ダイジェストとか特集で出ないかな？と期待。
Feb 21, 2006
コーディング用フォント(その2)
(私の中の)Monaco最強伝説、崩れる
ここ2日間、MonacoフォントからVera Fontに変更して使い込んでみました。結果、Monacoから変更決定。早速エディタやTerminal.appのディスプレイフォントをVera Fontに変更。
決め手は「すっきり感」、「視認性の高さ」、「理路整然感」。コードらしく見えるというのも重要ポイントなんですが、これも問題なし。暫く使ってみた後に試しにMonacoに戻ったらやっぱりVeraのほうが馴染むかなと思ったので、気が変わるまでVera Font Monoで行ってみることにしました。
正直、どうでもいい人にはどうでも良い話しかもしれませんが、毎日見るスクリーンフォントに拘る事はとても大事なことだと私は思っています。日々の時間は少なくても蓄積されると一生のうちに「フォントを見るという行為に費やす時間」は膨大です。少なくともコンピューターの画面を通して情報を得たり思考したりするには必ずフォントを介さないといけないわけですから、いわば「無意識下の情報フィルター」です。フィルターは汚いより奇麗なほうが絶対良いですよね？
その貴重な人生の中の膨大な時間を汚いフォントを見て過ごす占める割合を多くするか、美しく心地よいフォントの割合を多くするかは、その人の人生に及ぼす影響も少なからずあると思う訳です。
Feb 18, 2006
コーディング用フォント
(私の中の)Monaco最強伝説は崩れるか?
ヘチマ_BLOG : 理想のフォントを求めてに感化されて、気分転換にコーディング用のフォントをあれこれ試していました。
大抵の場合コードを書く際にはアンチエイリアスを切ったり、小さめのフォントを使うという人が多いと思うのですが(私の勝手なイメージです)、私の場合は傍流というか、多分主流に反していて、大きめのフォント(基準は13pt)にアンチエイリアスをかけています。(10ptとかはとてもじゃないが長時間見てられない)
そんな趣向なのでヘチマさんのとこで紹介されていたProFontなどはフォントサイズが小さい表示だとコンパクトにまとまって視認性が高くて良いかも知れないのですが私の使用環境には合わず。「結局Monacoフォントがアンチエイリアス+13ptの環境ではベスト」とまた元に戻ってしまうのでした。
ところがLOGGiXに組み込む予定のフリーフォントを物色していて見つけたVera Fontというフォント。これの一等幅フォントがなかなか私の好みに合ったのです。(↓)
例として、同じコードを実際私が使用しているサイズとシンタックスカラーリング環境でMonacoと比較してみます。比較コードは現在開発中のLOGGiXのインターフェイス部分のコード、エディタはCotEditorを使用。
Monaco 13pt
Vera Font 13pt
一見すると結構似てますが、Vera Monoのほうが縦横「キュッ」と締まってます。あと、「a」「g」のフォントが良い感じなのが気に入りました。ちょっと暫く使ってみる事にします。
ちなみにプレビューはこちら、
ダウンロードはこちらから出来ます。
OOP APIとProcedural APIでベンチマーク比較
PHP 5 Power Programmingを読んでいて気になる解説が。
ぬぬ〜っ？これは気になる...ということで、以前MYCOM PC WEBのこちらの記事「【特集】生まれ変わるPHP - Zend Engine 2、SQLiteの実力は? (8) MySQLとSQLiteの比較(MYCOM PC WEB)」で紹介されていたベンチマークコードを利用して、OOPスタイルとProceduralスタイルでINSERT、SELECT、ともに同じ処理をして実行時間を返すスクリプトを作ってみました。
JAM LOG : Downloads : PHP：SQLite Benchmark Test
で、試してみた結果。何度かブラウザをリロードしつつ最短のタイムを測定したものです。
OOP
Procedural
うーん、確かになんか微妙にOOPスタイルの方がタイムが良い感じなんですが。このベンチマークってのも毎回測定結果が異なるので勝ったり負けたりを繰り返すんですが、なんとなくOOPの方が勝率が良いような感じもします。
まぁ、このテストは単純なINSERT、SELECTクエリーを投げているだけなのでもっと複雑なクエリーだとどういう結果になるか分かりません。
ちょっと興味があるので研究してみる価値はありそうなんですが、調べてみてもこれに関する情報が少ないんですよねー。これを読んで興味をもたれた方がどなたかいらっしゃいましたら、上記のスクリプトをDLして実験するなり自前のベンチスクリプトで実験するなりして情報提供頂けたら嬉しいです。もちろん、他の情報元があれば是非募集。