2008年4月アーカイブ

当社の中心的事業である携帯有料コンテンツのアクセス解析というのは、とりあえずページビューが分かればよいというような単純なものではなく、サイトの性質によっても欲しいデータが全然変わってくるので、今まで決定的な方法を持たずになんとなくオープンソースのアレやコレでお茶を濁してみたり、URLを正規表現で集計する自作のアクセス解析を作ってはみたもののあまり役に立たず放置してみたりしていました。

そもそも、コンテンツやシステム作る方にいっぱいいっぱいでその辺（解析・分析）をおろそかにしていたというのもあります。

で、最近その件について改めて考えたのですが、結局、欲しいデータがその時々で様々なのに加え、単純集計をエクセルでいろいろいじってみて初めて欲しいものが分かるといったこともあるので、一番有効な方法はやはりギリギリまでフレキシブルな集計システムであるな、ということでこんな感じにしようと思いました。

基本的には以下の入力を保存しておいてバッチ処理でレポートを出力するのだけど、レポートの有効性にあたりをつけるために入力時に少しだけお試し集計してくれると嬉しい。

[入力1] 集計対象URLの正規表現、ただし正規表現の一部をパラメータとして指定できる

例）\/hoge\/([a-zA-Z]+)\/fuga\/([0-9]+)\.html ※サブパターンに指定した部分がパラメータ

[入力2] 集計期間 YYYYMMDD～YYYYMMDD

[入力3] 対象キャリア（対象キャリアのアクセス数を合算する）

[出力] 「(パラメータ1)\t(パラメータ2)\t...(パラメータn)...\t(日付)\t(ユニークアクセス数)\t(合計アクセス数)」を1レコードとするtsvデータ

• 過去に作成したレポートの履歴はラベル付きで残しておく。

オープンソースの集計システムで概要をつかんだ上で、気になる部分を上記システムで補足するわけです。

パラメータが1つのときは日付とのクロス集計表で出るとさらに良いような気はするけど、そうするとユニークが一つのレポートに入らないし、その辺はエクセルでなんとでもなるのでまあそれで十分じゃないかな。

たとえば SmartyRenderer の場合、

1. app/templates にベースとなるテンプレートファイルを作成（base.tpl）。コンテンツが入る場所には、{$inner} と書いておく。
2. output_types.xml にレイアウトを作成

<layout name="default">
  <layers>
    <layer name="content" />
    <layer name="base">
      <parameters>
        <parameter name="template">%core.template_dir%/base</parameter>
      </parameters>
    </layer>
  </layers>
</layout>

1. Smarty.class.php のあるディレクトリを include_path に追加。
2. output_types.xml に　renderer を追加。
   

<renderers default="php">
  <renderer name="php" class="AgaviPhpRenderer">
    <parameters>
      <parameter name="assigns">
        <parameters>
          （略）
        </parameters>
      </parameter>
    </parameters>
  </renderer>
</renderers>

↓

<renderers default="smarty">
  <renderer name="smarty" class="AgaviSmartyRenderer">
    <parameters>
      <parameter name="assigns">
        <parameters>
          （略）
        </parameters>
      </parameter>
    </parameters>
  </renderer>
  <renderer name="php" class="AgaviPhpRenderer">
    <parameters>
      <parameter name="assigns">
        <parameters>
          （略）
        </parameters>
      </parameter>
    </parameters>
  </renderer>
</renderers>

• テンプレートファイルの拡張子は、.tpl
• View で assign した値 hoge には、{$template.hoge} でアクセスする
• output_types.xml の中で assign した値に hoge には {$hoge} でアクセスする
  

1. mod_rewrite を使えるようにしておく
2. pub/dist.htaccess を .htaccess にリネーム
3. .htaccess 内を以下の箇所を変更

RewriteRule On
RewriteBase / （ここは必要に応じて変更）

7月5日～13日。カンボジア後のエントリでいろいろ候補は挙げていましたが、結局なんとなくキューバに決定しました。

決め手はあれだね、古いアメ車が走り回っていたり人々が非常に陽気だったりして、街並みがすごく画になりそうなところ。あと音楽とか、治安の良さとか。最近は観光地としての人気が急上昇中らしいので、訪れるにはちょうどよい時期なのではないかと思います。

航空券は込み込み19万円くらい。高い。とにかく燃料サーチャージが高すぎる。往復ともトロントで日を跨ぐ乗り継ぎがあるので、トランジットホテルでもうちょっと費用がかさむ感じか。楽天トラベル、skygate、Yahoo!トラベルと3つのサイトを使ってみましたが、前2つは安めのチケットに空席が全くなし。skygateに至っては検索では空席ありなのに予約完了画面でやっぱり空席なしでしたエラー多発。結局Yahoo!トラベル経由で、代理店に電話。結果的には（相場を考えれば）お安めの金額に落ち着いたのでよかったですけどね。

Wikipedia で歴史を見ると、スペインに征服され、アメリカに占領され、冷戦に翻弄され、いまだにアメリカにいじめられるかわいそうな国。それでも、旅行記なんかを読むと、朗らかであり続けるところがいかにも南国っぽくて楽しげ。

人にものを尋ねるときに、

• 何を

知りたいかを述べるだけで、

• 何のために

知りたいかが抜けているため無駄な時間をすごす人が少なくないのでみんな気をつけろ。

「事実」は一つでもそこから生まれる「情報」は無限にありうるので。

http://d.hatena.ne.jp/gothedistance/20080410/1207832176

工程が分かれてしまっていることの弊害は計り知れなくて色んな問題を引き起こしていると思うのだが、特に思うのが上流工程だけでも下流工程だけでもつまらないんだけど、上流から下流を全部担当するとこれほど面白いものはないということ。

特にここ、狂おしいほど同意。

ま、面白い面白くないはさておき、常々思う弊害の一つは、上流と下流が分かれていると、要件の重要性と実装のコストのバランスが悪い。要するに、どちらかといえば瑣末な要件に重大なコストがかかったりして、結果重大な要件の品質に問題が出たりすることって、案外あるのではないでしょうか。

いままでに何度かある個人受けした案件は、いわゆる開発会社に発注するのに比べれば開発費は20-30%で収まっているのではないかと思う。差額の70-80%の内訳は、会社と違って固定費がかからないのが3分の1、赤字社員がいないのが3分の1、要件を実現するもっともリーズナブルな仕様を自分で決めることができるのが3分の1、かなと。前の2つは会社という組織で仕事をする以上避けられないのだけど、最後の一つはワークフローで改善できるよね、というわけで「プログラマが仕様を決めればいい」に激しく同意なのです。

自分は SIer ではないので他人ごとといえば他人ごとなのですが、今のシステム開発業界はその構造が適切でないがために、結果としてシステムは不当にコストのかかるものになってしまい（意識するとしないとに関わらず）世の中の不幸せが増大しているのではないかという疑念が、業界荒らしの個人受けをあえてしてしまう一つの理由だったりします。

想像力の限界を問われる本。途中まではなんとかついていったものの、あえなくダウン。長い長い、そしてじわじわと理解が難しくなってくる前振りの果てに登場する、肝心の「不完全性定理」については無理やりなんとなく雰囲気をつかんだつもりになっているだけで、本当はあまり伝わっていない可能性大。

そもそも、「不完全性定理」の意味する"事実"が直感的に受け入れられない。直感的に受け入れられない上に、論理的に説明されても理解できない。でも事実。

物理みたいに、はじめから「不完全なんだけどできるだけがんばりますんで」という態度ならまだしも、ずーっと「俺は完全だからどーんと任せておいてよ」みたいな顔をしておいて、ある日突然「ごめん不完全だったわｗ」って、ちょっと数学ったらそんなこと急に言われても困ります、みたいな。

総合的に考えてここに記載されていることは事実である可能性が非常に高いと思うのですが、世の中には知らずにおいたほうが幸せなこともあるという一つの例といえます。

「革マル派」なる方々についてはそういう人たちがいるらしい、という程度の認識で"マルクス"の"マル"であることすら知りませんでした。イデオロギー不在の時代に育った世代としては、やはりその存在はどうにも理解しかねるというのが率直なところ。早稲田が学園祭でひと悶着あったのもなんとなく覚えていますが、その実態がここまで深刻であったということにも驚愕しました。

☆☆☆★★

「コインロッカーベイビーズ」がなかなか良かったので読んでみました。が、文字が目の前を通り過ぎていくだけで、全く頭に入ってこない。

「物語」を読むということは、その登場人物の誰かのどこかに自分のある部分を共感させるという側面が少なからずあるとは思うのです。その点、この作品に関してはあまりに刹那的で破天荒な登場人物達の振る舞いにビタ一共感できなかったというのが、内容が頭に入ってこなかった理由でしょうか。なんせ、まともなやつが誰一人としていないので。

少し前ですが、円高（まあ一時期に比べればですけど）なので DVY / ISHARES DJ DIV を20口購入。30口買えるつもりが微妙に入金額が足りずに20口。冷静に考えると、購入価格が約12万円なので手数料3,000円≒2.5％はちょっと高かったな...。

一般的な日本人が買える海外ETFはドル建てなので、機軸通貨としてのドルの信頼性に揺らぎが見える昨今、ポートフォリオ的には世間で言われる比率よりも米国株は少なめで良いのかもしれないと思いはじめています。

株式市場の不確定性に加えて為替市場の不確定性にも影響を受ける、それ自体は別に損でも得でもないことは分かっているのですが、どうもいろいろなものに振り回されているような気がして、自国通貨が基軸通貨である米国民が少しうらやましかったり。そもそも為替手数料で若干損してる部分もあるし。

以前スピーカーを購入したサウンドハウスでカード番号を含む個人情報の流出があったらしく、当方にもお知らせが来ていました。

その後、自分は流出対象外である旨連絡が来ていて事なきを得たのですが、率直に言って「まあしょうがない」。購入当時は「大手で信頼できる」ショップだったし、実際非常に安かったので。

SQLインジェクションは分かりやすいといえば分かりやすい、すなわち防ぎやすい攻撃だとは思いますが、それでもあらゆるサイトのあらゆるプログラムでそれを防ぐのは事実上不可能です。

かつ、トレンドマイクロがクラックされたことからも、「信頼できる」、あるいは「信頼できなければならない」ところほどクラッカーには狙われるという構図がある以上、「完全なセキュリティ」は少なくとも身近なオンラインショップには存在し得ないでしょう。

というといかにも救いがないように聞こえるのですが、最初のメールによれば、

万が一、お客さまのカード情報が第三者に不正利用され被害が発生した場合には、お客さまのご負担は一切ございませんので、ご安心いただきますようお願い申し上げます。

ということで、万が一の際に上記のような対応を取ってくれなさそうな身元の怪しげなサイトだけは利用を避け、カードの明細もちゃんとチェックしておくということが、「ますます便利になる世界」を享受しつつ、最低限の自己防衛をするためには重要なのではないでしょうか。

個人情報個人情報といって過度に敏感になることは、オンラインコマースの活性を妨げ過剰な対策コストを強いるという点において、消費者の不利益になり得ることも忘れてはいけないと思います。実際、サウンドハウスにしても、オーディオ機器業界の安売り店としてはちょっとした存在だったと思います。

ま、個人情報流出事件に際して書く内容じゃないですが。

ちなみに一点気になったのが、メールによると、

このたびは全く予期せぬ形で個人情報が流出する事態となり、お客様には多大なご迷惑、ご心配をおかけすることに至りましたこと、深くお詫び申し上げます。

ん？SQLインジェクション、しかも中国からというのは最も予期しなければならない流出経路の一つかと思いますが、、、。

自分が撮った写真でネット上に載せているものは、（人が写っているものは除いて）商用・非商用問わず使いたい人には自由に使って欲しいのだけど、そう考えると、そのあたりのライセンスはどう宣言したものでしょうか、という疑問にぶち当たる。有名なところだと「クリエティブ・コモンズ」というのがあり、ちょいと調べてみると以下の4つを組み合わせて設定できるらしい。

Attribution 表示 ... この写真の著作権が、のむらに帰属していることを明示すれば使ってよいよ

Noncommercial 非商用 ... 商用でなければ使ってよいよ

No Derivative Works 改変禁止 ... オリジナルのままでなら使ってよいよ

Share Alike 継承 ... この著作物から派生した著作物のライセンスを、この著作物と同じライセンスにするなら使ってよいよ

正直どれも要らない。経験上、制作会社として商用利用する場合には、最終クライアントの手前クレジット表記をすることさえためらわれるのが分かっているので、Attribute さえも不要。（実際、Attribute のみで公開されているクオリティの高い写真というのは現時点でもかなりの量が存在するものの、それを商用利用するケースはあまり見受けられないように思われる。）でも、現在のクリエイティブ・コモンズのルール上は、最低限 Attribute は必要らしい。

そうすると、パブリック・ドメインというやつが候補に挙がってくるのですが、これは完全な著作権の放棄。それもなんだか気が引ける。

そもそも、既存のライセンスなど利用せずに、勝手に好きなように宣言すればよいのではないかという考え方もあるにはある。ただ、自分が使う側に立った場合、ある程度「身元のしっかりした」ライセンスでないと「使ってよいよ」と言われても正直どこか不安なところがぬぐい切れないので、それをやるのはどうも気が乗らない。

↑今ココ。

なぜパブリック・ドメインがダメか、が「なんだか気が引ける」という理由な時点で大幅に間違っている気もしますが、結局のところ、クリエイティブ・コモンズよりももうちょっときめ細かいライセンスがあるといいよね、というお話。

現状、自分の公開している写真にその潜在的利用者がたどり着くことは難しいので、上記の話は特に実質的な意味は持たないのですが、こういうことを考えるにはよい機会なのではないかと思った次第。実際のところクリエイティブ・コモンズって名前だけで中身は知らなかったしね。

それにしても法律関連は話が難しい。

WYSIWYGエディタを使いたいがために、なんとなくMT4にしてみました。

今時MT4？WordPressでよくね？って話もあるのですが、各エントリのURLが変わるのもどうかと思ったので。まあ誰もリンクなんざ貼っていませんがね、気分的に。

で、楽しくスタイルを選んでいたら件名のエラー。

mt-static/themes は 777 になってるよ、と思ったら、mt-static/support/themes も777（なければ作る）にしないといけないみたいですな。

これで10万ちょっととか安すぎるな...。なんと撮影中にリングを回して撮影速度を変えることすら可能だとか。さらに、静止画撮影も60枚/秒（600万画素）と神スペック。

今まで、写真は現実を超える何かが作り出せるけど、（コンシューマーレベルの機材だと）映像はせいぜい現実そのものだよねと思っていて映像にはあまり興味がなかったのですが、これは明らかに現実を超える感動を作り出してる。なんでハイスピード撮影するとドラマチックなのかはよく分かりませんが。

CASIOはどちらかというと地味なイメージのあるメーカーなのだけど、改めて考えると電卓・デジカメ、あとG-SHOCK なんてのもあり、そして今回のハイスピードカメラと、結構エポックメイキングなことをしている会社です。

プログラムを作っていて、「うまくいきません」「困ってるんです」と助けを求めに来る人、一つのバグで延々悩む人、意外と多いです。

その手の質問のほとんどは、さすがに一瞬で解決することはないものの5～15分程度でほとんど解決します。それは別に自分がスーパーハカーだったり観察眼が超優れているわけではなくて、「うまくいかない」「困っている」原因となりうる可能性を一つずつつぶしていく中で、必然的に答えにたどり着くだけです。

人に聴きに来るからにはそれなりに悩んだ後であるはずなのに、その際の問題解決の進捗が「なんだか分からないけどとにかくうまくいきません」じゃどうしようもない。

「考えられる原因を一つずつ潰していく」というのは決して一子相伝みたいな秘蔵ノウハウではないし、それを運用するに当たって何か特殊な能力が必要なわけでもないのに、できない人が案外多いという事実がいまだ以って納得いかない今日この頃です。

しかし改めて考えてみると、大学のプログラミング入門の授業ではそんなことは習わなかったし、今まで読んだプログラミングの本にもその手のことは書いていなかった気がします。教える立場、執筆する立場の凄腕の人々からすれば言わずもがなのことだからという側面もあるに違いないですが、「デバッグ」はプログラム制作において決して小さくない時間を占める要素であるわりには、手薄なジャンルかもしれません。

なぜなら自分の行く手を阻むものが何もないから。

愚かでワガママなクライアント（あくまでもたとえ話です）もいないし、携帯に比べれば閲覧環境（ブラウザ仕様）上の制限もないに等しい。システムもデザインも思うがまま。

こんなに楽しい仕事が世の中にあったとは。

そんな中、CSSだけは相変わらずファックな感じですけどね。

ほとんど自分が勝手に進めてしまっているだけに、ちゃんと利益が出るのかという不安も非常にありますけどね。

でもやっぱり楽しい。ピアノの練習さえなければ泊まり込みでやりたいくらいだ。

「欲しいものリスト」で個人の嗜好性がだだ漏れな件については、少なくとも自分はもともとその用途を正しく理解していたのでともかくとして、Amazonポイントがお会計時にデフォルトで「使用する」になっているのがどうしても納得いかない。

こういうのって、ある程度貯まったあたりで囲い込みの効果が加速度的にアップするものかと思うのですが、、、。毎回10円とか20円とか引かれてもちっとも嬉しくないしなー （´・ω・`）

購入履歴がもうすぐ500件達成の Amazonist としてはジャンジャンポイントを貯めたいのだけど、購入のたびに「ポイントを使用する」のチェックをはずすのはいかにも面倒だ（しかも通常の購入遷移から横道に逸れないとこのチェックボックスがない）。