tmty.jp

前回のエントリでは、サーバで生成した FlashLite コンテンツを配信するケータイサイトの開発/制作フローとして、以下のような流れを紹介しました。

1. SWF への入出力(input/output)に見通しを立てる (全員で)
2. Flash IDE でプロトタイプの fla ファイルを制作し、SWF でパブリッシュ (デザイナ)
3. SWF 中の何(What)を、どのように動的にいじりたいかを整理 (全員で) (ここまでが前の項)
4. 動的にいじる手段を選択 (主に開発者で)
5. 決定した手段に応じて、SWF への入出力を決定 (主に開発者とデザイナで)
6. fla の制作ルールを決める (主に開発者とデザイナで)
7. 上の制作ルールに基づいて Flash IDE で fla ファイルを制作し、本番用の SWF をパブリッシュ (デザイナ)
8. 制作した SWF を必要に応じてテンプレート化する (開発者もしくはデザイナで)
9. テンプレート化した SWF をいじるアプリケーションを実装する (開発者)
10. できあがり。運用時の更新は、7〜８〜9の繰り返し

前回は、このフローの4まで、つまり SWF をサーバ上でどのようにいじりたいかを検討し、そのための手段(ツール)として、swfmill を選択する、というところまで紹介しました。

今回は、具体的なコンテンツを想定しながら、このフローの5以降の流れについてまとめていきたいと思います。

サンプルコンテンツの概要

動的にいじるサンプルコンテンツとして、以下のような背景画像+キャラクタのアニメーションを再生するシンプルなFlashLiteコンテンツの動的生成要件を考えてみます。(上記のフローの 3 までの検討結果イメージについても併記してみます。)

• ステージサイズは 176×208
• 背景画像とキャラクタのアニメーションをステージ上に持つ
• SWF を動的に生成するときの入力(input)
  • 背景画像
  • キャラクタ画像
• SWF 再生後の出力(output)
  • なし。ただ再生するだけ
• SWF 中の何(what)をいじるのか
  • 背景画像とキャラクタ画像

文字だけだとどんなコンテンツなのかイメージがわきにくいので、サンプルも貼っておきます。(DeviceCentral で再生しているものをキャプチャしています。)

今回は、このコンテンツをベースに、

• 背景の jpeg 画像を指定のものに差し替え、
• 飛んでいるキャラクタの画像とアニメーションを指定のムービークリップシンボルに差し替える

ということをやってみます。具体的には、背景画像を以下のもの:

に差し替え、さらに、キャラクタのアニメーションを、別途作成した以下のようなムービークリップシンボル:

に差し替えたものを、新しい FlashLite コンテンツとして生成することとします。(余談ですが、FlashLite の動的生成が「FlashLite の(動的)合成」と表現されている事がありますが、その意味するところは、上記のように「ムービー中の画像素材などを指定して、これらを組み合わせて(合成して)FlashLite の生成をおこなう」ということと理解しています。)

それでは、以下、先に紹介した制作フローの続きを紹介していきます。

SWF 生成(合成) 時の入出力を決める

先に検討した入出力を精査し、何を入力パラメタとして SWF をつくり、ムービー再生後にどのような出力パラメタをもってサイト遷移に戻るか、を決定します。今回は、以下のように決定したとします。

• 入力
  • 背景画像: ステージサイズと同じ大きさの jpeg データ
  • キャラクタ画像: アニメーションを伴ったムービークリップシンボルとして指定される(元のキャラクタ画像は GIF89a)
• 出力
  • なし

なお、実際の要件や制作/開発の現場では、上のようにまとめられるとは限りません。「背景画像には jpeg と GIF の形式のどちらかが指定されうる」とか「キャラクタ画像は画像のビットマップのみ入力として与えるだけとし、アニメーションは固定で良い」などの要望が出る場合があります。今回は、この後のステップを紹介するのに都合が良いように要件を決めていますので、まずは以下をお読みいただいた上で、上記のような要件変更/要望の取り込みがどの辺りの開発ステップ/難易度/コストに影響を与えてきそうかを捉えていただければと思います。正直なところ、ここ以降の制作フローの詰めが、FlashLite コンテンツの動的生成をおこなう際の一番の難所(業務でやる場合は、リスク要因となりやすいフェーズ)と、個人的には感じています。

.flaの制作ルールを決める

SWF 中の差し替えをおこなう要素と、そのときに与えられる入力が決まったところで、デザイナと開発者との間でベースとなる SWF の制作ルールを決めていきます。なぜ、制作ルールを決める必要があるかと言うと、一番の理由は、プログラムから差し替えをおこなう要素が特定できるようになっていないことには、画一的な処理で要素の差し替え(SWF の動的生成)をすることができず、ベースとなる SWF ごとに処理をつくってやらなければならなくなるからです。

これは逆を言えば、ベースとなる SWF が少なく、運用時の SWF 追加や更新も無い、などの理由で、個別の動的生成処理を実装していくのにコストがかからないのであれば、この時点で厳密な制作ルールの握りをつくる必要は無い、ということにもなります。

今回は、この後の説明を簡単にする都合で、以下のように制作ルールを決める事ができた、と仮定します。

• 背景画像は、jpeg を貼付けただけのムービークリップシンボルを別途作成しておき、これをステージに配置する際に “bg” というインスタンス名を付与しておく事にする
• キャラクタ画像は、アニメーションを含める形でムービークリップシンボルを別途作成しておき、これをステージに配置する際に “animation” というインスタンス名を付与しておく事にする

上記のように、今回は、差し替えをおこなう要素をふたつともムービークリップシンボル化しておくことを仮定しています。

ただ設置するだけの背景画像を、わざわざシンボル化して、インスタンス名まで付与するのは、制作側からすれば一見非効率かも知れません。ただし、これらのルールは、先にも述べた通り、プログラム側から差し替えをおこなう要素(ムービークリップ)を特定/識別するためのルールですので、ケースバイケースと考えていただければよろしいかと思います。たとえば、「SWF 中には、背景画像として唯一 jpeg 要素を使用する」という制作ルールがあれば、「背景画像として入力した jpeg を SWF 中の jpeg データと置き換える」という処理を作ってやれば、わざわざインスタンス名で特定する必要がないということにもなります。

本番用 SWF をパブリッシュし、必要に応じてテンプレート化し、差し替え処理を実装する

上記のルールに基づいて .fla を制作し、SWF をパブリッシュしたら、いよいよ、具体的な FlashLite 動的生成処理の実装に入っていきます。

まずは swfmill swf2xml を使って、できあがったベースの SWF の構造を確認してみます。(swfmill の基本的な使い方は、他のサイトでもわかりやすい説明が多いので、ここでは割愛します。)今回のサンプル SWF は以下のようになっていたとします。

  1 <?xml version="1.0" encoding="UTF-8"?>
  2 <swf version="4" compressed="0">
:
 13       <DefineBitsLossless2 objectID="1" format="3" width="30" height="30" n_colormap="7">
 14         <data>
 15           <data>eNq9kEsO...
:
 17       </DefineBitsLossless2>
 18       <DefineShape objectID="2">
:
 30               <ClippedBitmap objectID="1">
 31                 <matrix>
 32                   <Transform scaleX="20.00000000000000" scaleY="20.00000000000000" transX="-300" transY="-300"/>
 33                 </matrix>
 34               </ClippedBitmap>
:
 52       <DefineSprite objectID="3" frames="20">
 53         <tags>
 54           <PlaceObject2 replace="0" depth="1" objectID="2">
 55             <transform>
 56               <Transform transX="299" transY="299"/>
 57             </transform>
 58           </PlaceObject2>
 59           <ShowFrame/>
:
176       </DefineSprite>
177       <PlaceObject2 replace="0" depth="3" objectID="3" name="animation">
178         <transform>
179           <Transform transX="3541" transY="1031"/>
180         </transform>
181       </PlaceObject2>
:
182       <DefineBitsJPEG2 objectID="4">
183         <data>
184           <data>/9n/2P/Y/+AAEEp..
:
186       </DefineBitsJPEG2>
187       <DefineShape objectID="5">
188         <bounds>
189           <Rectangle left="0" right="3520" top="0" bottom="4160"/>
190         </bounds>
191         <styles>
192           <StyleList>
193             <fillStyles>
194               <ClippedBitmap objectID="4">
195                 <matrix>
196                   <Transform scaleX="20.00000000000000" scaleY="20.00000000000000" transX="0" transY="0"/>
197                 </matrix>
198               </ClippedBitmap>
:
216       <DefineSprite objectID="6" frames="1">
217         <tags>
218           <PlaceObject2 replace="0" depth="1" objectID="5">
219             <transform>
220               <Transform transX="0" transY="0"/>
221             </transform>
222           </PlaceObject2>
223           <ShowFrame/>
224           <End/>
225         </tags>
226       </DefineSprite>
227       <PlaceObject2 replace="0" depth="1" objectID="6" name="bg">

swfmill を使った FlashLite の動的生成処理を作る際は、(場合にもよりますが、)

• ベースの SWF をそのまま保持しておき、動的に swf2xml => 差し替え処理 => xml2swf するよりは、
• 上記のように XML 化したものを要素を差し替え可能な状態に適宜編集して保持しておき、動的に 差し替え処理 => xml2swf  したほうが、

応答速度的にも効率が良くなると思います。ですので、ここでベースの SWF の構造を XML 化しておき、差し替えをおこなう要素の構造を理解しておくとともに、この XML を差し替え可能な状態に編集し、テンプレートとして保存しておく事にします。

今回の要件では、ステージにムービークリップを配置した際のインスタンス名を “bg” または “animation” で指定してもらっているはずですので、まずはこれらがどこに位置しているかを見ていきます。FlashLite 1.1 でパブリッシュされた SWF では、ムービークリップは PlaceObject2 要素(Tag)で name 属性をともなって配置されているはずです。(このあたりの SWF の構造に関しては、Adobe 社が公開している SWF の仕様 – SWF Technology Center (必要に応じて Open Screen Project )も参考にしてください。)上記の場合では、

177       <PlaceObject2 replace="0" depth="3" objectID="3" name="animation">

の行と、

227       <PlaceObject2 replace="0" depth="1" objectID="6" name="bg">

が該当する事になります。

ここから、さらに PlaceObject2 が参照している object を辿っていきます。objectID 属性を確認すると、たとえば animation インスタンスは objectID=”3″ ですので、objectID=”3″ となっているムービークリップ要素 = DefineSprite 要素を探します。今回の例ですと:

 52       <DefineSprite objectID="3" frames="20">
 53         <tags>
 54           <PlaceObject2 replace="0" depth="1" objectID="2">
 55             <transform>

ここが該当します。このなかで、さらに PlaceObject2 により objectID=”2″ が参照されていますが、ここではムービークリップ内に設置されたキャラクタ画像が参照されているはずです。FlashLite 1.1 でムービークリップ内に画像を定義する方法は何種類かありますが、基本的には、

• DefineBitsLossless2 もしくは DefineBitsJPEG2 で定義した画像データを、
• //DefineShape/styles/fillStyles/ClippedBitmap で参照し、このシェイプを PlaceObject2 で配置する

というのが一般的な構造になるようです。今回は、上で指定されていた objectID=”2″ な DefineShape を辿って、さらにそのなかの ClippedBitmap というように、objectID をたどっていきます。最終的には、

 13       <DefineBitsLossless2 objectID="1" format="3" width="30" height="30" n_colormap="7">
 14         <data>
 15           <data>eNq9kEsO...

に行き着きます。ここの data 要素の中身が、アニメーションをおこなっているキャラクタ画像のビットマップデータということになります。今回はアニメーションとキャラクタ画像を丸ごと差し替えたいという要件ですので、このあたりの DefineBitsLossless2, DefineShape, DefineSprite の構造を、objectID の参照関係を維持したまま作り替えてやれば、アニメーション部分の差し替えができるということになります。

同様に、背景画像については上記 227 行目の PlaceObject2 で参照されている objectID=”6″ を追っていってやれば、

182       <DefineBitsJPEG2 objectID="4">
183         <data>
184           <data>/9n/2P/Y/+AAEEp..

に辿り着きますので、この data 要素を差し替えてやれば良い、ということになります。

対象の SWF の構造がわかったところで、この XML をテンプレート化します。差し替え処理の実装方法は幾つか考えられますが、

• XML 中の置き換えをおこなう部分を場所を一意に特定できる文字列にしておき、プログラムからは文字列置換により書き換える
• 置き換え対象部分を独自に定義した要素などに編集しておき、適当な XML 操作のための API (僕の場合は、PHP であれば SimpleXML、Ruby であれば REXML や Libxml-Ruby などを使ったりしてます) を介して書き換える

などの方法があります。前者は単純な文字列置換なので、対象の SWF がシンプルであれば非常に簡単に実装できますが、その分、.fla の制作ルールや実行環境によってはバグやセキュリティホールを作り込んでしまう可能性もあるので、注意した方が良いかもしれません。

ちょっと長くなってきたので、実際の入れ替え処理を書いていくところは、次回以降にしたいと思います。

まとめ

以上、２回にわたってケータイサイトで FlashLite コンテンツを動的生成する方法の概要をまとめてきました。全体の流れが見えると、ベースとなる SWF の制作ルールと、システム開発コストがどのように関連してきそうか、が、なんとなく見えてくるんじゃないかな、と思います。

実際のところ、制作ルールの策定は、動的生成処理の開発コストを、システム開発側とSWF制作側とで分担する割合/バランスを探る作業であるようにも感じています。ですので、全体の流れや仕組みの見通しが立たない事には、実サービスにこういった仕組みを入れていくのは大変かもしれません。

FlashLite 動的生成のシステムには何回か関わらせていただいていますが、正直なところ、こういった流れ、とくに制作側にいろんな制作ルールをお願いするようなやり方が本当に良いのかどうかは見え切れていません。今でも、わりと試行錯誤しています。この手のシステムに関わった方と情報交換する機会がほとんど無いので、いろんな方のご意見をうかがってみたいです。

さて、次回以降は、今回紹介したサンプルコンテンツの動的生成の続きから、実際に FlashLite 動的生成をやっていて使用したコードや、ハマったところなどが紹介できればと思います。

長々と読んでいただいてありがとうございました。期待せずにお待ちください。

PHP×携帯サイト デベロッパーズバイブル を日頃からお世話になっている、memokami の荒木さんよりご献本いただきました。荒木さん、ありがとうございました。


さて、タイトルにも書きましたが、この本、ケータイサイト開発に関わる方なら PHPer でなくともオススメです。実装例やサンプルライブラリこそ PHP で紹介してあるものの、各種環境構築やサーバ設定などの主題から外れる内容は極力省かれており、全体的な解説の重心は「ケータイサイトを作る際に知っておきたいこと、考えておきたいこと」におかれています(と僕は思います)。ですので、「知っておきたいこと、考えておきたいこと」を読み解いていくことで、他言語での開発をおこなう場合でも、とても参考になる一冊だと思います。


もうちょっと細かく書くと、僕がこの本をオススメする理由は、大きく次の 3 点が挙げられます。

1. 3キャリア対応サイトを作るために、3箇所(以上)に分散している一次情報をチェックし、比較活用できる形にする必要がある => その手間をショートカットできる
2. キャリア仕様からは必ずしもうかがい知れない、「やってみなければ分からない」ポイントが押さえてある
3. これらの情報が、実際のサイト開発の流れに載せて、順序立てて解説してある

1 点めは、ケータイサイト開発を始めて、すぐに遭遇する「メンドクサイポイント」です。たとえば「位置情報を使ったサイトを作るぞ」という状況になったとき、各キャリア仕様を当たることになりますが、「つくろうiモードコンテンツ」やら「EZ Factory」やら「SoftBank Mobile Creation」やらを巡回して、必要そうな資料(PDF)をピックアップしてくることになるわけです。当然、3 社とも資料の様式/解説手順は異なりますし、必ずしも一つの資料じゃ見えきれないキャリア特有の前提知識があったり、初めて見る標準仕様っぽい名前やら用語が出てきたりと、これらの情報を整理解釈するフェーズがどうしても必要です。これらの情報が「一次情報はどこにあって」「最低限見ておくところがこれで、3 キャリアではこうなってて」「実装するならこうだ」というのが一通り書いてある、というのは、これだけで大きなショートカットになります。


2 点めですが、たとえば、次のような情報で「何だこりゃ、どういうことよ」「うわ、ケータイサイト、メンドクさそう(でもやることになっちまった)」って方は、きっとこの本を読んでおくと、少なからず救われるのではないかと思います。

• SoftBank モトローラ機種は、User-Agent の表示フォーマットが異なる
• au は Win かそうでないかで利用可能絵文字数を見分けると良い
• SoftBank 絵文字の扱いは 3GC 機種とそうでない機種で微妙に違う
• au デコレーションメールの MIME フォーマットは他キャリアのフォーマットと異なる
• SoftBank の旧機種では端末シリアル番号が取得できない
• au だけは HTTP リクエスト拡張ヘッダで、位置情報対応有無を確認できる

こんなふうに、まさしく「ハマった人しか知らない」「やったことがある人でないとわからない」ポイントが目白押しです。とくに絵文字の扱いに関する説明の丁寧さには特筆すべきものがあります。3 キャリアサイトでの絵文字対応は鬼門ですが、ここまで絵文字についてページを割いて丁寧に説明している本を、僕は見たことが無いです。

余談ですが、僕は最近↑のデコレーションメール周りでいろいろハマってました(諸事情あり、ここで紹介できてなくて申し訳ないです)。ここも、しっかり解説してくれてるのが、ちょっと悔しかったりする。


最後の 3 点めは 2 点めとも共通してくるのですが、

ケータイサイトの開発では、「技術的に難易度が高い」というのとは異なるトリッキーなハマりどころが多く、何も知らずに足を突っ込んでしまうと、「オイオイ、こんなのでアリなのかよ」「この○○××め〜！(○○にはお好みの文句、××にはお好きなキャリア名もしくは機種メーカをどうぞ)」という実装 TIPS と、特異な( bad というには抵抗があるので)ノウハウの嵐に遭遇します。ケータイサイト開発を安易に考えていた結果、落とし穴にハマりまくって、見積りが大きくブレたという痛い経験は無いでしょうか。僕はあります。泣きました。


現実的には、最近は、これらのハマりポイントも Web 検索で解決できるようになってきました。けれど、この本は単にハマりポイントと対処療法を散乱させた、Web で検索できるネタの寄せ集めではありません。これらを、実際のサイト開発の流れに載せて、順序立てて解説してくれているという構成もオススメポイントのひとつです。こういう構成にしてくれているおかげで、これからケータイサイト開発に取り組む方がハマる前に、何を見ておくべきかを、あらかじめ知ることができると思います。


というわけで、携帯サイトの開発にかかわっている僕も、多くを勉強させていただきました。ケータイに関する開発にこだわって携わってこられ、自身でのケータイサービスも運用されている荒木さんならではの、エネルギーを感じる一冊です。これからケータイサイト始める方にも、すでに幾つか経験されてる方にもオススメです。


最後に、

荒木さんが巻末に書かれている通り、ケータイ技術は日進月歩、異常に速いスピードで進化していますから、確かにこの本の内容も、すぐに古くなって行ってしまうかもしれません。が、今までのスピードに比べれば、端末の買い替えサイクルも長くなってきたし、「普通のケータイサイト」を作る上でのポイントはちょうど成熟してきた頃なんじゃないかな、とも思います。

今後は iPhone やら android やらの話題がモリモリ世に出て行きそうですが、それらの開発 TIPS が一般的に必要とされるのは、もうちょっと先になりそうですよね。まだまだケータイサイトはいっぱい生まれてきてますし、ケータイサイト開発解説本としては、とても良いタイミングで発売されたのではないでしょうか。

• memokami :: 「PHP x 携帯サイト デベロッパーズバイブル」が発売になりました

EC ナビさんで開催されたモバイル勉強会にて、携帯の機種情報 DB についてお話してきました。

今回の勉強会は、第一線で大規模な自社サービスを展開されている方のスピーチが多く、大変参考になりました。僕の話が、前回同様、かなり地味なテーマだったので、かなり緊張しましたが、他のスピーカの皆さんの胸を借りるつもりでお話させていただきました。

僕の資料はこちらの trac にまとめましたのでご参考ください。

機種情報を集める手間然り、デバッグの繁雑さ/実機手配の費用と手間然り、絵文字処理の複雑さ然り、ケータイサイト開発には、技術的障壁とは言い難い観点での泥臭い障壁があります。今回のような勉強会やノウハウ共有の活動が、ケータイアプリ開発に興味を持っておられるクリエイタの方に、少しでも参考になり、もっと面白いモバイルサービスが生み出されるようになっていくのであれば、これ以上楽しいことはありません。

では、例によってメモを転記。

• 以前のケータイサイト .. 遅い NW 経由の断続アクセス .. より多くのコネクションが必要になる
• au の絵文字表記はバイナリコードを使うべし
• moxy は pluggable。最近の perl アプリは pluggable であることが大事
• サイト運用時のドメイン変更は注意。3割くらいのユーザにメールが届かなくなる = 3割くらいのユーザがドメイン指定してる
• ドコモでメールを送った後に「OK」を押すと接続が一旦切れる。メール返信処理をしてるときは、再接続が発生するので、「OK」を押さずに待つのが吉
• ニワンゴ郵便では Subject にセッション ID を埋めて会話セッションを管理してる。一時間有効。一期一会
• ニワンゴでコマンドメールの応答を自分でつくれる .. OpenAPI
• ニコ動モバイル
  • 気合いでできている
  • キャリアの通信制限をiアプリ, Flash で超える
  • motionJPEG(のようなもの) + ADPCM(エセ着うた) で draw+play 繰り返し
  • flv 素材 => 変換サーバ(C++) => jpeg + ADPCM => 再生サーバ(java) => クライアントアプリ
  • クライアントへのデータフォーマットは、ヘッダ + 命令列。命令列は音再生 + 描画の羅列。音データは MFi や SMAF ベースの独自フォーマット。クライアントは、ほぼパーサのみの実装
  • 一回のデータ単位は上限の 150KB でやっている。一番効率がいい
  • 可変ビットレート .. 利用できる転送速度に応じて 150KB の中で送るフレーム数を変えている。クライアントが限界 fps を申告する。音声は 1 秒単位区切り
  • play から音再生までタイムラグがある。AudioPresenter を切り替えながら再生
  • 描画スレッドにsleep()を入れないと通信が止まる罠
  • Flash版では、どの端末も 1fps が限度
  • 繋いで見せるのが難しい。子 Flash の再生までの時間が不定
• モバゲー .. 142億PV/月間。画像チェックは全部人力。SH903i ユーザが多いらしい
• SWF::File .. SWF を生成する perl スクリプトを生成
• AS のバイトコードにダミーのジャンプコードを差し込んで、逆コンパイラを誤認(難読化)させるテクニック
• ドワンゴでの検証機 5000 台以上。server side browser .. ruby(rails?) で 3 日で書いた

最後になりましたが、今回の勉強会の発起人であり、スピーカの皆さんへの呼び掛け、裏方運営まで諸々ご尽力いただいた memokami さん、休日開催/多人数の参加にもかかわらず会場を快くご提供いただいた EC ナビさん、参考になるお話を惜しげもなくご披露いただいたスピーカの皆様に感謝いたします。お疲れさまでした＆ありがとうございました。

う、実はここ5ヶ月ほどPHPは書いていません。が、行ってきました。
会場の大田区産業プラザ(PIO)は、京急蒲田駅が最寄りです。東急(JR)蒲田から、ひょこひょこ歩いていったら結構距離があってびっくりしました。当日朝に場所を調べて出てきたけど、ちゃんと準備しなきゃダメですね..

例によって、自分的に「おっ」って思ってメモったとこ中心に、あと、思い出したことだけ書いときます。

• php-x.x.x/zend/bench.php ってベンチマークのソースがあるのは知らんかった。[あとで読む]
• php-mysqlnd っていう native driver があるのね。php5 でもいけるのか。ちといじってみよう
• ウノウの尾藤さんとこのシステム運用グッズ群。養生テープとマジックテープね。なるほど、そういう細かいアイテムの使い勝手は大事すね
• GREE のアプリケーションアーキテクチャ。フロントの後ろはサービス単位でレイヤリングしてある。「あっちのサービスから " あしあと " 付ける」とか、横断的に使えるようにするため。なんとなくはわかるけど、キレイに分けられてるもんなんだろか
• GREE ほど (xx-xxxMPV/day) になると require_once もコスト高。bootstrap.php で共通利用するライブラリをまとめて指定
• symphony definitive guide 読んだことない
• CakePHP 1.2 で validation と pagenation が強化されるとか
• Piece の画面フロー設計に使える Eclipse 用プラグイン。ほ〜
• いちいさん、ログ解析の話が出てこなかった。あとで聞きにいこう
• でも僕が一番使って[る|た]のは Ethna かなー。Framework って微妙に面倒だからなー、覚えるのが
• Yahoo! Japan での PHP 運用。1338MPV/day とかオカシイ
• Yahoo だと smartyみたいなテンプレートエンジンは使ってない。DAO とか低レベルなところは C/C++ での実装。不正なアクセスも、できるだけ下位のレイヤでさばく。キャッシュは APC 、 x-debug はデバッガというよりプロファイラとして使ってる。セッション管理もコスト高なので Cookie と hidden 引き回しで軽減。i18n は r3 っていうのを使ってる。このセッション、結構メモったなー。面白かった
• memokami 荒木さんのLT。時間切れ。詳しくはモバイル勉強会で (w
• cocoiti さんの PHP で画像加工してモテようとする話。でも、結局モテなかったらしい。画像加工だけじゃダメなのか
• アシアル海原さんの恋愛術の話。最後まで恋愛術で通した。声が良かった
• オープンタイプ早川さんの code* (コードなにがし)の話。リリース当初にロードアベレージ 140 。ssh で 40 分待ったとか、よく待つなあ (w 結構面白そうなサービス。知らなかった
• 尾藤さん再登壇。PHP のシェル。?> 書かなくても動く、と。あの壁紙はよかった
• 10/5,6 同じ会場で OSC だよ by 宮原さん
• Xbox 360 争奪じゃんけんは 3 回戦で敗退。ざんねん
• 懇親会途中で名刺なくなった。ちゃんとお渡しできなかったみなさん、すみません。いろんな方とお話できて、超楽しかったです！

ところで、先月は何だかバタバタで、要領悪かったもので、ほとんどブログが書けずじまい。ブログだけでなく某所や某所の書き物も全然進みませんでした。「最近あんまし出てこないっすねー」って言われちゃったし、今月はゴリゴリやろうとおもう。うん。

追記。
今回のイベント、セッション中も懇親会中も、採用活動的な会話がいっぱい聞こえた。最近は、この業界、どこも採用大変なのね..
でも、こういう場での採用活動は、わりと効果的だろうなあ、とは思った。

@ノッキングオン様オフィス(麻布十番)。

twitterでのminiturboさんのつぶやきがキッカケで集まった人たちと、モバイル勉強会をやってきた。

細かいレポートはどなたかに譲るとして(またこれだ)、飲み会でのネタ含め、「おっ」と思って走り書きしたメモだけ残しておく。

• GPSってトラステッドじゃなかったっけか。少なくとも定期的に自動ポーリングとかはできなかった気が
• キャリアを跨ぐときの、一対多絵文字問題。テンプレレベルで回避
• 絵文字やるときは、PHPの内部エンコーディング設定注意
• ソフトバンク3Gでのフォームからの絵文字受け取りは手強い。連続入力されるとヤバい
• 絵文字メールの、サーバ受け取り処理は無理
• 一日20時間働くひと
• FlashLiteでのセッション管理。SWFへの埋め込み
• W3C, OMA のモバイル向けWeb標準の動向。WCSS、ちゃんと見ておく
• operaが一部実装してあるぽい
• ケータイサイトをPCで見られたとき用の、幅設定div
• 回り込みテキストの扱いは float:left しとけ
• 流行りのケータイコンテンツといえば、ケータイ小説
• @media handheld でモバイル機器向けのスタイル
• スモールスクリーンモードは、一番上から、それ用のCSSをかぶせてるようなイメージ
• http://dev.opera.com/
• ケータイでコーディングするスタイル
• インフルエンサーマーケティング
• bl(ビーエル)系
• Java FX、まだStringのconcatenation実装が無い？
• iアプリ、今まではlong 64bitがatomicで無かったのね
• あのプリプロセッサはぜひ公開してほしい

僕の話した機種判別に関する資料は、この辺に置いてみました。地味な話題で、内容薄かったのですが、それなりに盛り上がったのでよかったです。

最後に、お礼。
つぶやきから始まったけど、責任もって開催までリードされたminiturboさん、お疲れさまでした。勉強だけでなく、いろんな方とお会いできて、とても有意義な一日でした。ありがとうございました。
それから、会場提供いただいたノッキングオン様、ELF様にも。素敵なオフィスですね。良い勉強会ができました。本当にありがとうございました (_ _)