2012/02/27

おとなの正しいおねだりのしかた

こんにちは!レーシックにより生まれ変わりました!hiroshi改めhiroshi2.0です!(視力が2.0)夏が楽しみ!!

さて、takaがAWSを使ったサービスについてのエントリを書いてますが、AWSを使いたいから採用したわけではないですし、会社組織なので使いたかったら使えるというもんでもないわけです。場合によっては田園調布に家が建つくらいのお金が動きうる話ですので、相応の行動を起こさねばいけません。このギャグ知らないか。

すなわち、意味があるかどうかをキチンと検討し、意味があるという結論になれば、それを理解してもらうべき人に理解してもらうというステップを踏む必要があります。

今回は、そのステップの足がかりのイメージがわかない人向けに、その足がかりが提供できればと思います。誰得なのかわかんないですけど。

本当にAWSが必要なのか?意味があるのか?を検討する

当たり前といえば当たり前ですが、この問いに対して論理的・具体的に答えられる人は少ない気がします。

  1. コスト的側面
  2. 事業スピードの向上的側面
  3. リクルーティング的側面
  4. 技術研究的側面
など、決裁者に対して訴えるべきモチベーションはケースバイケースだと思いますが、こういうケースの場合、最終的には「それっておいしいの?(=儲かるのか?)」というところに終着すると思ってます。

その判断は最終決裁者のみぞ知る所だと思われるかも知れませんが、そこにつながるストーリーの妄想は誰でもできるはずです。妄想しましょう。

妄想して、ある程度のストーリーが描けたら、その妄想が現実に即しているかどうかの裏を取ります。

たとえば、「AWSを使うとコストが抑えれるお!利益増えるどだから使うべきだお!」という妄想をしたのならば、「そうである」ことを具体的なデータを以って現実的(客観的)なものにします。

妄想ポイントはあまりにもケースバイケースなので、今回はこの程度でサクっと通り過ぎます。

妄想の現実化をしたら次のステップです。

紙は大事
妄想したら、その内容を紙に書きましょう。まあ、普通に考えても、こんな話を口頭でいきなり話されても全部理解なんてできないですし、宿題にしようと思っても覚えきれるわけもありません。真剣味も伝わりません。

ぼくが20代を過ごした環境では、「手ぶらだったら会議なんてやらないほうがいい。1枚でもいいから紙もってけ」とか「会議は戦だ。そして戦は準備の段階で勝敗が決まる(←武田信玄のセリフらしいです)」といった具合に交渉ごとや打ち合わせなどの会議においては必ず紙という装備で攻守を固めることを要求されましたが、こういった経験はいろんなところでぼくを助けてくれています。感謝。

ところで、会議の内容にもよりますが、なにもない時でも5分で書ける程度の箇条書きのアジェンダでいいので持って行きましょう。たった一枚の紙が、参加者する人の目的意識を統一し、緊張感を持たせることができたりします。5分でかけるアジェンダもないなら会議をやめたらいいじゃない。

なお、ここでいう「紙」というのは資料のことで、僕にその辺のことを叩き込んだ先輩たちがそういっていたので一般的な言い方かどうかはよくわかんないです。パワポでもKeynoteでも何でもいいと思います。やっぱ何でもよくないかも。状況に応じて適切なものを選んでください。

口頭で言って通るケースもありますが、少なくともお金や時間がかかるものであれば、そういったケースはラッキーだと思うべきでしょう。

というわけで、できたものをふんだんに伏せ字などの加工したものがこちらになります。



この資料で主に訴えているのは、が「コスト効率」と「事業スピード向上」ですが、「リクルーティング」も自動的におまけで少しついてくる気がします。これはたぶん、ほとんどのAWS採用のケースにおいて同じかと思います。

これをベースに進めていきたいと思います。



2012/02/13

キャッシュマニフェストってなんだ

leonです。

ガラケー向けだったDECOLOGも最近どんどんスマートフォン化してます。
ガラケーとスマートフォンではブラウザの表現力が雲泥なので、各ページのHTML書き直し必須です。
これを機にHTMLを勉強しなきゃ、ということでHTML5を新年の抱負にしました。

まずは、HTML5ってなんですかってところなんですが、HTML5が示す仕様って範囲広い。
HTML5に含まれている仕様には以下のようなものがあるらしいです。

  • セマンティックス
  • オフラインとストレージ
  • デバイスアクセス
  • 接続性
  • マルチメディア
  • グラフィック
  • パフォーマンス
  • CSS3


というのも、HTML5はブラウザプラグインで提供されているFlashなどのリッチインターネットアプリケーションをプラグインレスで利用できるようにするために、ウェブアプリケーションのプラットフォームとしての機能やマルチメディア要素をすべて取り込んだものになってる模様。

HTML5を勉強するって決めたもののどこから手を付ければいいのかなと、途方に暮れそうになりましたが、考え方を変えると最近のWEBトレンドを追いかければ大概それはHTML5なんじゃないかと気づきました。
いうことで、気にせず好きなところから始めることにしました。

で、最初に手をつけたのがキャッシュマニフェストです。
キャッシュマニフェストは、HTML5で実装されたWEBアプリケーションをオフラインで実行できるようにするための仕組みだそうです。

ところで、オフラインWEBアプリケーションって自己矛盾した言葉ですよね。
WEBアプリケーションはサーバーにリクエストを投げて、レスポンスとしてHTML、Image、CSS、Javascriptといったリソースをダウンロードしてページを表示する仕組みなので、ネットワークに接続して利用することが前提という先入観を持ってました。

まぁともあれお勉強ってことでこんな本読んだり、こんなとこを読んだりしました。

じゃぁ、キャッシュマニフェストって?

単純にWEBアプリケーションをオフライン実行するには、必要となるHTML、Image、CSS、Javascriptといったリソースファイルが事前にローカルにキャッシュされている必要があります。
キャッシュマニフェストは、オフラインWEBアプリケーションが使用するリソースファイルをページのリクエストとは別契機でダウンロードしておき、リクエストの代わりにキャッシュを返す仕組みです。

キャッシュマニフェストを利用するには、マニフェストファイルと呼ばれるリソースファイルのURLをリストにしたファイルを用意し、このマニフェストファイルをhtmlタグのmanifest属性で指定します。

<!DOCTYPE HTML>
<html manifest="/cache.manifest">
<body>

</body>
</html>

するとこのページにアクセスした際、オンラインの間にオフライン実行に必要なリソースをダウンロードしてローカルにキャッシュしてくれます。
なお、マニフェストファイルはMIMEタイプtext/cache-manifest使って送信するので、Apacheの設定ファイルにAddTypeディレクティブを追加しく必要があります。

AddType text/cache-manifest .manifest

マニフェストファイルのリソースリストは以下のように記述しておきます。

CACHE MANIFEST
/hoge.css
/hoge.js
/hoge.jpg

オフラインWEBアプリケーションでもローカルにキャッシュしたくないリソースもあると思います。
マニフェストファイルにはそんなリソースを定義する構文がいくつか用意されてます。

マニフェストファイルは3つのセクションヘッダで分けられるようになっています。先のようにセクションヘッダがない場合は全体がCACHEセクションとして扱われます。

2012/02/06

スマートフォンブラウザの絵文字事情

こんにちは。tommy です。どういうわけか名前だけは時々出ていたと思うのですが、自分でエントリを書くのは初めてです。よろしくお願いします。
さて、DECOLOG では、ユーザーが投稿したテキストに含まれる絵文字を各キャリアに合わせて適宜変換して表示しています。携帯サイトでは当たり前にやっていることではありますが、DECOLOG の場合はそれに加えて携帯-スマートフォン間についても相互変換を実現しています。ここではそれをどのように実現しているかを 2 回に分けて解説していきたいと思います。
まず今回は、現状のスマートフォンのブラウザがどのように絵文字を扱っているのかを整理し、次回それに対して実際にどのような仕組みで対応しているかを説明したいと思います。

1. 携帯絵文字の仕様のおさらい

古き良き(?)携帯の絵文字の仕様については既に解説が既に多くありますので詳細は省略します。(きちんとした用語を使って)解説しているページとして、以下を挙げておきます。
http://coderepos.org/share/wiki/Mobile/Encoding
なお、スマートフォン上の絵文字の仕様を理解する上で必要となる知識は、
  • Shift JIS の空き領域 (85区〜120区) に絵文字が配置されている。具体的な位置 (コードポイント) はキャリアによって異なる。
    DoCoMo112区〜114区
    au101区〜103区
    107区〜110区
    SoftBank109区〜110区
    113区〜114区
    117区〜118区
    例えば「晴れ」の絵文字は、DoCoMo: 0xF89F, au: 0xF660, SoftBank: 0xF98B となる
  • 上記の絵文字を Unicode で表すためのマッピング定義が各キャリアで公開されている。これもコードポイントはキャリアによって異なるが、いずれも基本多言語面の私用領域 (PUA, U+E000U+F8FF) 上に配置されている。
    DoCoMoU+E63E - U+E757
    auU+E468 - U+E4E3
    U+E4E5 - U+E5DF
    U+E82E - U+E82F
    U+EA80 - U+EB1D
    U+EB1F - U+EB2D
    U+EB30 - U+EB8E
    SoftBankU+E001 - U+E05A
    U+E101 - U+E15A
    U+E201 - U+E25A
    U+E301 - U+E34D
    U+E401 - U+E44C
    U+E501 - U+E53E
    例えば「晴れ」の絵文字は、DoCoMo: U+E63E, au: U+E488, SoftBank: U+E04A
となります。まあコードポイントの詳細はともかく、見事に定義がバラバラなためキャリア間で絵文字をやり取りするためには変換が必要な事、また各キャリアの絵文字は1対1に変換できるわけではないことを押さえておけば良いと思います。

2. Unicode 6.0 の絵文字について

現在では各キャリアの絵文字のほとんどが公式に Unicode に収録されています。よって、対応するフォントデータがあれば PC 等携帯電話以外の環境でも絵文字を扱うことができるようになります。仕様策定の中心となったのが Google と Apple という今のスマートフォンのメインプレイヤーであるため、スマートフォンの絵文字を理解する上でこの仕様を押さえておくことが非常に重要となります。
特徴は以下のようになっています。
  • もともと Unicode にあった記号に割り当てられたものと、新たなコードポイントが割り振られたものが存在する。
  • 新たなコードポイントが割り振られた文字の多くは追加多言語面に配置されている。
  • 一部の文字 (国旗など) は結合文字によって表現することになっている。
  • 例示図形が絵文字っぽくないものも……(笑)
「晴れ」の絵文字は U+2600 に割り当てられています。
なお、各キャリアの絵文字との互換性は以下のようになっています。
  • 商標の問題がある文字は収録されていない (i-modeのロゴなど)
  • 各キャリアで共通の (ということにした) 絵文字は同じコードポイントに配置されている
  • 仕様策定の際に使われた、各キャリアが定義した PUA 上のコードポイントとの間の対応表が公開されている
    http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html
すべての携帯/スマートフォンが Unicode 6.0 の絵文字コードでの入出力に対応すれば、環境差を一切気にすることなく絵文字をやり取りすることができるようになるわけです。
※ もちろん現時点ではそのようになっていないのでこの記事が存在するわけなんですが。

3. iOS 4 以前の絵文字対応

iPhone OS 2.2 から SoftBank 絵文字が取り扱えるようになりました。ソフトウェアキーボードからの入力は、i.softbank.jp や SMS/MMS に限られますが、Webブラウザでもメールアプリで入力してコピー&ペーストすることによって入力・表示が可能です。
絵文字のコードポイントは SoftBank の Unicode マッピングに準拠しています。
またどこかのバージョンから、Unicode 6.0 で定義された絵文字のうち SoftBank 絵文字の範囲についても対応するフォントデータが用意されており表示が可能になっています。
ブラウザで絵文字を表示する方法
SoftBank の Unicode マッピングの絵文字コードを表示可能です。
UTF-8 で記述されたページの場合は、 UTF-8 のコードをそのまま記述できます。もちろん HTML の数値参照形式で記述しても良いです。「晴れ」なら 0xEE818A または "&#xE04A;" となります。
Shift JIS で記述されたページの場合は、HTML の数値参照形式で記述すれば良いです。「晴れ」なら "&#xE04A;" となります。
HTML のフォームから送られるコード
SoftBank の Unicode マッピングの絵文字コードが送られてきます。
UTF-8 で記述されたページの場合は、UTF-8 のコードがそのまま送られてきます。「晴れ」なら 0xEE818A です。
Shift JIS で記述されたページの場合は、UTF-8 のコードが SJIS コードに変換されて送られてきます。このコードは通常の SoftBank の Shift JIS コードとは異なり、いわゆる Unicode から CP932(Windows-31J) への変換ルールによって変換されたものとなります。「晴れ」なら 0xF08B です。

4. iOS 5 の絵文字対応

iOS5 で全てのアプリで絵文字入力が可能になると同時に、標準的に使われる絵文字のコードが SoftBank の Unicode マッピングから Unicode 6.0 の絵文字に変更されました。ドラスティックな変更を思い切って行うあたりがとても Apple らしく開発者泣かせではあります。
  • Unicode 6.0 の絵文字全てのフォントデータが用意され、SoftBank 絵文字以外の、DoComo/au に由来する絵文字も表示できるようになりました。ただし白黒表示です。仕組み上はカラー表示にできるはずなので、データの準備が間に合わなかったのかやる気がなかったのかどちらかでしょう。
  • ソフトウェアキーボードから入力される絵文字のコードも Unicode 6.0 のコードになります。
  • 今のところソフトウェアキーボードから入力できる絵文字は SoftBank 絵文字由来の文字種に限られているようです。ほかの絵文字は白黒で見栄えが悪いからでしょうか。
ブラウザで絵文字を表示する方法
Unicode 6.0 の絵文字コード、SoftBank の Unicode マッピングの絵文字コードのどちらも表示可能です。記述の方式は iOS 4 以前と変わりません。「晴れ」なら、UTF-8 で 0xE298800xEE818A、数値参照形式で "&#x2600;", "&#xE04A;" のいずれかとなります。
HTML のフォームから送られるコード
Unicode 6.0 の絵文字コードが送られてきます。
UTF-8 で記述されたページの場合は、UTF-8 のコードがそのまま送られてきます。「晴れ」なら、0xE29880 です。
Shift JIS で記述されたページの場合は、UTF-8 のコードが HTML の数値参照形式(10進)に変換されて送られてきます。これは PC のブラウザでは一般的な挙動です(よく考えるとおかしいんですけどね……)。これは Unicode 6.0 の絵文字コードから Shift_JIS へのマッピングが存在しないからでしょう。「晴れ」なら、"&#9728;" です。

5. Android の絵文字対応

Android では、絵文字は Google が定義した内部コードで管理されることになっているようです。実際のコードは上で触れた Unicode 6.0 の対応表で「Google」と書いてある列が該当します。特徴としては
  •  3 キャリア分すべての絵文字が Unicode の私用面 (第15面) 上に配置されている (U+FE000 - U+FEEA0)
  •  Unicode 6.0 で結合文字の組み合わせで表される絵文字も独立したコードポイントが与えられている
  •  Unicode 6.0 の絵文字とはほぼ 1 対 1 で変換できる
と、いかにも内部コードっぽい性質を持っています。「晴れ」の絵文字をこのコードで表すと U+FE000 となっています。
ただし Android 全体としての対応はここまでのようで、実際にこの絵文字を使うためには、