近所にある映画館でアバターを見たら、ガラガラで誰も居ないんですよ。日曜のレイトショーとなると、隣に居ないっていうレベルじゃない空き具合。快適すぎてやばい。
3Dの上映方式がいろいろあるらしいけど見たのはXpanDという赤いメガネのやつ。以下は注意する点まとめ。
- 眼鏡と併用はやめた方がいい。このためにコンタクトレンズを用意していいくらいだと思う。まるで違う。眼鏡だと重くて痛くて鑑賞どころではなくなってしまう。
- テッシュを持参しておくこと。テッシュを使う理由は２つあって、一つは汚れを取り除くため。フレームとかバンドはプラスチックとラバー地なんだけど、再利用するので人の脂とか気になるのもあれなので、そっちを掃除するのに使う。サングラスのレンズはデリケートなので軽く拭き取る程度までとすべき。眼鏡拭きならベター。しかしながら、本当にひどかったら交換をお願いしたほうがいい。
もう一つの理由は鼻とサングラスの間に挟むとずれにくくなり、フィットするようになるため。
- サングラスは紐で後ろを固定する方式だったけど、頭は後部にもたれないほうがいい。やってみるとわかるけど、頭をヘッドレストにつけるとサングラスがずれるし、ずれ落ちる。
- 無理に全部見ようとしない。この映画は多焦点な上映方式ではない。また飛び出る3Dというよりは奥行きのある3Dという演出になっている。だから全く違うところはピンぼけになったままが正しい。目安は字幕の焦点で、無理して他の場所と交互に見ようと頑張ると、気持ち悪くなるほど酔ってしまう。面白いのは字幕がスクリーン中央くらいまで上がってくることがあること。これは下部が手前側に思いっきり突出していて、人物が奥まっていて、その人物にフォーカスが合っているから。
- 上映前から飲み物はほどほどに。約160分＝3時間くらいの長さなので、途中でトイレに立つ羽目になってしまう。
そのうち109シネマズ川崎のIMAX3D上映を見てみたいなと思いつつ、予約が大変そうなのでしばらく待ってからかなー。
あるとき私はこの文章は不適切じゃなかろうかと思い修正する。数日経過すると元に戻っている。ある人がたまたま気づき、荒されたページを元に戻しておいてくれたのだろう。気前よく素晴らしい修正をしたと私は思ったが、それに同意がなく、つまり他人からは改悪だと思われていたらそれは荒らしなんだろう。適切だ。確かに適切な対応だ。
こういう時Wikiなんだなあと思う。砂漠の中で鬼ごっことは言い得て妙だ。文責とか編集者とか意味のありそうな特権階級をつけてみたくなる。Wikiでは意味をなさない。というか。そんな権限がついたらWikiWikiWebと名乗るのはどうだろう。
Googleの検索結果からたどり着く人から見れば管理者だろうが一般ユーザーだろうが荒らしだろうがなんでもいいのだろう。それがWikiであるということが明示されている以上はWikiなんだろう。そのページの情報が正しいかどうかを取捨選択するのもアクセスしてきた本人の自由意志と責任によると思う。嘘書いてあるじゃないですか、と聞くより速く、なら無視するなり勝手に修正するなり告発すれば？というやり方なんだろう。
鶴の一声が大好きな日本人にはやりにくのかもしれないとか、改ざんとか改悪に過敏な日本人にはデリケートさに欠けるんだろなとか思いつつ、コンテンツ蓄積に向いているシステムなんだなと思った。
N-03Bっていいなあと食指が動くかと思いきや、5万円という金額に意欲が失せる。正気の沙汰に感じなかった。1年放置してもう1万円くらい安くなってから買おうかな、とか悩む時点でアウトだと思う。
そもそも買い換えをしないとか。N705iは黒を選んだせいもあってか、マットな黒色は傷が目立たちにくい。ところでピアノブラックっていう光沢色は、買う前はいいんだけど、買ってから後悔する色だね。
機能とかどうでもいいんで、壊れなくて傷つかなくて電池の持つやつがいいよな。としみじみ思う。今更P158(現在も最軽量のシティフォン。なんと57g)が販売されていたら、買ってしまいそうだ。
現在のラインナップにそんな機種は一台も存在しないことを知っているだけに、なんだかなと思う。
らくらくホンがあるじゃないかと人はいう。携帯弱者のための。しかしあれは楽なんじゃない。ラクラクとはイージーという意味であって、シンプルって意味じゃない。値段も決して安いわけじゃない。安直なケータイとは高価なおもちゃだと思う。
洗練された単純さは美しい、そう言わせるだけの魅力が感じられなくて残念に感じる。
携帯サイト構築に便利そうなapacheモジュール。速攻で忘れそうなのでメモ。
興味を持ったはいいが、実際に使うのかというと微妙。理由は後述。
mod_chxj
オープンソースなapacheモジュール。ソースもあるのでバグってたら自力で直せ仕様ですかな。機能を適当に要約。
- DoCoMo/au/SoftBank対応モジュール(Apache2.X用なのでapx2を使えと)
- CHTML(余計なものがつかない簡素なHTML)/HTMLをユーザーエージェントから判定しそれぞれ変換してくれるらしい
- 画像はJPG/GIF/PNGからJPG/GIF/PNG/BMPに変換してくれる。たとえばドコモだとPNG→JPEGにしてくるんだろうな
- 絵文字をドコモ用ShiftJISバイナリーで入力するとau/SoftBankの絵文字に変換してくれる
- Cookieシミュレート機能。DoCoMoはCookieに対応しないので、勝手にセッション発行してCookieもどきをやってくれるらしい
- Cookieシミュレート機能の延長線上でRefererシミュレート機能がおまけでついてくる
- 全角カナを半角カナに変換してくれるらしい
- iモードID(guid)ＥＺ番号(サブスクライバID)x-jphone-uid(ユーザーID)とか端末情報を取得して一元管理
- QRコード生成機能
ソフトウエア上でこれらを自前で用意すればいいけど(1)専門知識が必要＆実機テストも必要(2)モバイルを主でやりたくないから手間を省略したい、という理由にとても魅力的なモジュール。似たようなものがもう一つある。
mod_ktai
株式会社ゆめみが公開しているapacheモジュール。オープンソースではないけどRHEL5/CentOS5用RPMを配布している。機能はmod_chxjとかぶるでの異なる点をまとめると
- mod_chxjでは一つのモジュールになっているけど、mod_ktaiはmod_ktai_info(端末情報)/mod_ktai_emoji(絵文字変換)/mod_ktai_image(画像変換)に分かれている。別々に必要なものだけインストールして使用することが可能なようだ。
- Cookieシミュレートはないらしい(その代わりといってはなんだけどmemcachedもMySQLサーバーも要らない。)
- mod_ktai_ipadmin(IPアドレスによるプロキシ判別)/mod_ktai_auth(公式サイト用？)は未公開。mod_ktai_authは自分たちの商売だからと言わんばかりに公開する予定はないらしい。
- ぱっと見る限りmod_chxjのほうがディレクティブの設定が豊富すぎて難しそう。mod_ktaiのほうが簡単だけど、機能限定されてそう。
- 絵文字の変換テーブルがmod_chxjではXMLで書かれているが、mod_ktaiではtsv(タブ区切りテキスト)で書かれているので、mod_ktaiのほうがメンテナンスが容易に感じる。
他にも相違点はありそうだけど、どっちも使用していない現状では省略。
どうしてこれらを使わないかというと、理由は単純で
- すでにソフトウエアで対応してしまった。サーバーで対応するので低メモリ＆高速と今更言われてもなあ。都市伝説？と疑ってしまう。
- 結局IPアドレスリストとか、auのデバイスID→端末名の変換とか、常に更新作業が発生するじゃないか。インストールして終了にはならない。
- 結局中身を何でもわかっているヘボいライブラリのほうが、なんだか分からないけど便利そうなアプリより使い倒せる。自力で直せる。
- 複数サイトを1サーバーで運用するときApacheの場合VirtualHostで分けてしまうけど、これらのモジュールってApache全体に影響するんじゃない？
というわけで、PCサイトを構築しているけど、これからケータイサイトを追加で作らなきゃいけないと言われているが、さっぱりわからんという人には福音となるんだろうな、と感じた。
携帯電話などのモバイル端末でアクセスしたときに表示されるケータイ用スキンを改良してみた。ざっくり適当。
現状の問題点はreCAPTCHAプラグインのケータイ対応があるけど、ケータイからWiki編集するという行為そのものが結構大変そうだなと思ったので、とりあえず保留。
PukiWiki/1.4/ちょっと便利に/テーブルの中央寄せor右寄せにあるtable_align.diffを手動でマージしてみた。PukiWikiPlus!でもちゃんと動くんだね、とすこし感心する。
パンヤFAQWikiをドコモのケータイでアクセスすると画像表示がいけていない。具体的に何がいけていないのかというと、
- 100Kバイトを越える画像がエラー
- PNGファイルが表示できない(そりゃそうだ)
そこでresizeimage.inc.phpを導入して少しいじってみた。現在の状況では正常に動作しなかったので修正するしかなかった。
まずPHP5.3になってからgd_infoの挙動が異なっている。
従来は”JPG Support”
5.3から ”JPEG Support”
元画像を取得するところでJPEGファイルのとき結果が常にFALSEだったので、少し調べてみると上が原因のようだ。修正する。
次にキャッシュファイルの生成が、一回作るとそのままになっていた。負荷対策はすばらしいと思えるのだけれども、ファイルが新しくなったときに更新されない(そういう場合があるのかというと想定しずらいが。)
そこでfilemtime関数を使用してキャッシュファイルが元ファイルより古いときはキャッシュファイルを作り直すよう判定を修正。
細かい修正はデフォルトWIDTHを240にする(128pxかなと思ったけど、最近のソフトバンクは480pxまで出るようなので240pxでいいんじゃないかと。)
それからJPEG画質を95へ。あんまり大きくしすぎてもファイルサイズだけ大きくなるので適当に調整。
またアスペクト比保持をデフォルトでTRUEになるよう定数追加した。
さらにref.inc.php(refプラグイン)の中も修正した。モバイルからのアクセスのときは
&plugin=ref&page=XXX&file=YYY
↓
&plugin=resizeimage&page=XXX&src=YYY
と出力を変更。これらでとりあえず動作するようになった。
Gauche 0.9のリリースから結構経っている気がするけど、ついつい日常の煩雑さからスルーしていたものの、正月に入ったのでやってみた。
バージョン0.8.Xの時だと問題なかったけど0.9になってからrpmbuildが上手く動作しなかったのでメモ。
結論としては2カ所問題があった。まず一つ目はプラットフォームの指定でGauche-0.9.tgzの中に入っているrpmfiles-encoding.txtと rpmfiles-gdbm.txtの指定にこんなリスト
C:
-
/usr/lib/gauche/0.9/x86_64-unknown-linux-gnu/gosh
-
/usr/lib/gauche/0.9/x86_64-unknown-linux-gnu/libgauche.so
-
(略)
確かに64bit版ならいけそうだけど、自宅にあるCentOS5.4は32bit版。そこでこういう書き換えが必要になった。
(修正前)x86_64-unknown-linux-gnu
(修正後)i686-pc-linux-gnu
sedで記載すると
C:
-
sed -e "s/x86_64-unknown-linux-gnu/i686-pc-linux-gnu/g" rpmfiles-encoding.txt
-
sed -e "s/x86_64-unknown-linux-gnu/i686-pc-linux-gnu/g" rpmfiles-gdbm.txt
せっかくなので以下のようにパッチを作成した。
diff -Naur Gauche-0.9 Gauche-0.9.new > Gauche-0.9-i686-pc-linux-gnu.patch
このパッチを使用するにはGauche.specに修正が必要になる。具体的には
Patch0: Gauche-%{version}-i686-pc-linux-gnu.patch
という追記をし、%prep %setup の後に
%patch0 -p1 -b .
を追加する。
次に二つ目の修正。これは割と簡単だけど、具体的には
/usr/lib/libgauche.so.%{version}
→/usr/lib/libgauche.so.0.9
というファイルは存在せず、
/usr/lib/libgauche.so.%{version}.0
→/usr/lib/libgauche.so.0.9.0
が必要になる。
以上からパッチとSPECファイルを参考用に添付。WordPressの都合上ZIPに圧縮してある。
Gauche-0.9-i686-pc-linux-gnu.zip
Gauche.zip
さて、これをどうするか。別にソースファイルをいじっているわけでないし、布教用に欲しいけどrpmだからな～、時間があったらMLで聞いてみよう。
パンヤFAQWikiのデザインを一新するほど気力がわかないけど、VistaとかWindows 7に搭載しているメイリオで表示させたいなというわけで、適当に指定を変更した。
ついでにMacだとヒラギノになるように指定を変更した。Macが手元にないので設定が上手くいっているのか確認できず。
CSSを編集していて、いつも思うけど、どうしてCSSってあんなに汚い上にブラウザ毎で挙動が違うのだろう。大したことも出来ないくせに面倒くさい＆手間で嫌だ。
ちなみに今回表示させて確認したのはOpera10とIE8。FireFoxとかは未確認。
Windows 7にインストールされているWindows Media Player 12にはリモートメディアストリーミングという機能が搭載されている。リモートメディアストリーミングが思いの外便利。
Windows Live IDを2台のWindows 7 マシンに登録しておくと、両者で動画や画像・音楽を共有することができ、インターネット経由でもアクセスできるようになる。主にデスクトップをホームサーバー代わりにし、出先のノートPCやネットカフェでリモートアクセスするイメージ。
ストリーミングでも画質はそれなりで劣化は見られなかった。たまたま使用していたのが社内だったので十分高速。
難点はホストにする側のPCを常時電源をつけたままにしておかないといけないところ。消費電力より劣化とか寿命が気になる。
Windows Home Serverのしたかったことってこういうことだったのか、と今更ながら感心した。
コメント (0) 
Themocracy