サマーインターン開催と募集のお知らせ

こんにちは。ミツバチワークスの諸富と申します。
今日は「サマーインターン」の実施と参加者募集のお知らせをします。


最初に、なぜインターンをやろうかと思ったのかをちょっとご紹介しようと思います。

学生生活が終わると、ほとんどの人が社会に出て、そのほとんどの人がどこかの会社に就職することになると思います。

就職活動では、主に
・自分が何をやりたいのか？
・どんな会社だと、その自分のやりたいことができるのか？
ということをベースに、なるべく自らの意図に沿う会社を探すわけですが、たぶん、この辺のことが感覚的にわかっていて、判断できる人は小数派だと思います。少なくとも僕は全くわかっておらず、就職活動もよくわからなくなって途中でやめてしまった派でした。
何事もやってみなければわかりませんよね。

インターンとは、ざっくり言えば、「就業体験」のようなもので、
実際と近い形でオフィスに通い、業務を体験することで上記の答えを出すヒントを得ることができる、かなり有効な手段だと思います。

ミツバチワークスは現在社員４０人ほどの小さい会社ですが、そんな当社でも、そのヒントを提供することができるのではないかと思います。

・大きな会社だからできること
・小さな会社だからできること
それぞれありますが、ことインターネットが絡んだ世界では、この境界はなくなりつつあります。

ご存じない方もいらっしゃるでしょうが、ミツバチワークスではWEBとリアルを絡めたDECOLOGという国内でも類をみないタイプの大きなサービスを運営しています。

つまり「ミツバチワークスしかできないこと」というのもあるんです。
そのことを実体験を通して知っていただくことは今後のみなさんの視野を広げるという意味で、価値のあることだと思っています。

また、一方で僕たちもみなさんとのこの体験を通して、自分たちの立ち位置を再確認するという良い機会になると思っています。


というわけで、ミツバチワークスでは初めての試みですが、楽しいイベントにできると思うので、ご応募、お待ちしてます！

以下の募集要項をご確認の上、ご応募ください。

募集要項

【期間・場所】

期間：8月20日〜8月31日 の平日10時〜19時

場所：恵比寿本社

※期間の延長については応相談

【応募資格】

以下のすべての条件を満たす方

• 18才以上
• 上記期間中、基本的には全日参加可能な方（ここは応相談です）
• 開発用のPCを自分で用意できる
• プログラミングスキル、デザインスキルなど、WEBサービス開発に関するなんらかの技能を持っている。（いわゆる「エンジニア」に限りません）
• 例）Photoshop,Illustratorでの制作経験やRubyやJavaなどのプログラミングの経験（言語問わず）、HTML5・CSSでの製作経験など
• 学生、もしくは正社員としての就業経験がない
• 大学４年生やM2の方など、今年度卒業予定の方も大歓迎です！

※宿泊場所の用意はございません。

【内容】

• ミツバチワークスの事業・業務紹介
• デザイン・プログラミングなど、サービス開発・運用に必要なスキルに関する講義および実践
• テーマに沿った開発・制作

※内容は応募状況によって変更される可能性があります。

【待遇】

• 往復交通費（上限あり）
• 日当1万
• 期間中、僕達が相談にのれることは何でものります

【選考方法】

書類選考→面接（東京・恵比寿）→採用

※面接の交通費はご負担ください

【書類選考の参加方法】

以下の内容を含んだ書類（書式不問）をメールでintern[at]328w.co.jpまでお送りください。

※[at]を@に読み替えてください

その際、メールの件名に「インターンシップ応募」とご明記ください。

＜応募書類内容＞

• 履歴書
• なぜ応募してみようと思ったのか、その理由。
• WEBサービス開発に関して保有しているスキル
• 前項のスキルをどうやって学んだか、そのスキルを使って何をしたか

※実際に制作物を見せていただける方は書類のどこかで

Blocksでバックグラウンド処理を楽にしよう！

どうも taka です。

Objective-Cの事も書いておかないとiPhoneアプリ技術者だと思ってもらえないのでは？
と思い、今回はObjective-Cのネタを書きたいと思います。

内容は『Blocksでバックグラウンド処理を楽にしよう！』です

slidropでは色んな所でバックグラウンド処理を使っています。

このネタの効能は、

1. 可読性があがった！
2. 楽に使えるようになった！

です。是非使ってみて下さい。

■普通に書くと？



という感じになります。

ちょっとした処理をバックグラウンドに回したい時、
メソッドをわざわざ書かないといけないのが残念…。

そして、バックグラウンド処理に回す場合は

@autoreleasepool

でくくっておかないとメモリリークします。

■NSObjectを拡張してみる

そこで、Blocksを使えるようにNSObjectを拡張します。

NSObject+Extensions.h


NSObject+Extensions.m


■使ってみる！

写真共有サービスslidropの裏側

どうも taka です。

新サービスが公開され楽しくドタバタしてます。

一緒にドタバタしたい人はこちら。　→　仲間募集

【今回、紹介するモノ】

さて、今回は3/6に無事公開された写真共有サービス

slidrop

で使っているAWSのサービスやソフトウェアを紹介しようと思います。

今回は、コードはいっさいありません！

• うんうん
• だよね！
• えっ！こっちの方がいいだろ！
• 普通だなぁー

とか思って頂ければ。

【そもそもslidropって何？】

slidrop(スライドロップ)は、写真を最大12枚までのslideという1つの塊として投稿できる写真共有サービスです。

iPhoneアプリでは、友人が投稿したslideが縦のタイムラインとして表示されます。
そして、同時に投稿した写真は横方向にスライドする事でみることができます。

という事なのですが、百聞は一見にしかず！

こちらからダウンロードしてみて下さい！(笑)

【AWSのサービス】

slidropは以下のサービスを使っています。

EC2
RDS	Multi AZ
S3	画像だけでなく、アクセスログなども期限付きで置いてます。
CloudWatch	RDSの監視
Route53

これらのサービスを使って以下のような構成にしています。

Gateway/デプロイ/管理サーバ	EC2	外部からのssh/デプロイ/インスタンス立ち上げ
Webサーバ	EC2
DBサーバ	RDS
監視用サーバ	EC2	各EC2インスタンスの監視
監視用DBサーバ	EC2

まずまず王道な構成だと思います。

負荷が増えてきたら、

DECOLOGの絵文字変換処理

こんにちは tommy です。今回は絵文字シリーズ後半ということで、DECOLOG サイトでの絵文字処理方式について解説したいと思います。正直な話誰得な感じもしますけれども、滲み出るカオス感を楽しんでいただければ幸いです。なお絵文字そのものの仕様については、適宜前回の記事を参照ください。

1. 携帯時代

まずはスマートフォン登場以前の話です。

絵文字を DB に格納する

DECOLOG の携帯版のサイトでは、ブラウザの入出力の文字コードは Shift JIS、アプリケーション (PHP) およびデータベース (MySQL) の内部コードは UTF-8 としています。よってアプリケーション内で Shift JIS - UTF-8 間の変換を行っています。文字コード変換には CP932 のマッピング (PHP では "SJIS-win") を使います。ここいら辺は割と定番だと思います。
さて、これで 3 キャリアの絵文字のコードを入力するとどうなるかというと、絵文字コードの範囲は CP932 では「利用者定義領域(95区-114区)」または「IBM 拡張文字(115区-119区)」のいずれかに収まるため、一応 1:1 の関係で UTF-8 のコードに変換されます。これはキャリアが定義した Unicode マッピングとは別物 (但しDoCoMoに限っては一致します) であるためシステム外部との運用性はありませんが、内部コードとして使うことはできます。以下これを便宜上「DECOLOG絵文字コード」と呼ぶことにします。
とりあえずここまでは特に何もしなくても、同一キャリア間であれば絵文字を扱うことができることになります。

3キャリア間の絵文字変換

3キャリア間で絵文字をやり取りできるように、出力時に端末のキャリアに応じて文字の置き換えを行います。変換テーブルは

• キャリア間で同じような絵文字があれば、それに置き換えて表示
• 該当する絵文字がなければ、対応する言葉で置き換えて表示

といったルールで作成します。DoCoMo、au、SoftBank それぞれ相互に変換できるようにするので、変換テーブルは全部で 6 種類つくる必要があります。DECOLOG では自力で変換表を作りましたが、今はフリーのライブラリが充実しているので割と簡単に用意できると思います。処理の順番は、

1. ユーザーが入力した文字列に対し、上記の変換テーブルを適用して変換
2. 出力全体を UTF-8 から Shift JIS に変換する
3. ブラウザへ送出

としています。
ここで問題となるのは、ユーザーが入力した文字列がどのキャリアの端末から入力されたのか知る必要があるということです。前回の記事の通り、Shift JIS 上の各キャリアの絵文字のコードポイントは一部重複しているため、ある一文字のコードポイントだけを見てそれがどのキャリアの文字かを判別することができません。
そんなわけで DECOLOG のデータベースでは、ユーザーが絵文字を入力できるテキストを含むテーブルそれぞれに、それがどのキャリアの端末で入力されたのかを保持するためのカラム (「text_mode」という名前です) を一つ用意するという割と力技でこの問題を解決しています。たまにカラムを作るのを忘れたために絵文字の変換がされない箇所が発生することがありますが、いつか直しますので許してください。

携帯時代の DECOLOG 絵文字対応まとめ

ここまでの内容をまとめると、以下のようになります。

• ブラウザから入力された文字列は、そのまま UTF-8 に変換して DB に格納
• DB 格納時に、キャリア情報を専用のカラム (text_mode) に保存
• DB に格納された文字列を表示するときに、専用の変換テーブルを用いて表示しようとしている端末に応じた絵文字に変換

2. スマートフォン時代

DECOLOG では、2010年10月に (割とひっそりと) 携帯以外のアクセスを受け入れるようにしてから、少しずつスマートフォン対応を進めてきました。絵文字の扱いに関しても、やはり少しずつ改善しつつ今に至る、という感じです。現時点では、従来の携帯端末／iPhone／Android間でおおむね絵文字の相互変換ができるというところまで実現できています。

DECOLOG のスマートフォン対応について

DECOLOG のスマートフォン対応は大きく 2 段階で行われています。

1. まずはスマートフォンからモバイルサイトにアクセスできるようにする(モバイルモード)
2. 次にスマートフォンに表示最適化されたページを用意する(スマートフォンモード)

絵文字の観点からモバイルモードとスマートフォンモードを比較したときに大きく違うのは文字コードです。モバイルモードは従来通り Shift JIS のページですが、スマートフォンモードでは UTF-8 のページとなっています。好みに応じて好きなモードを選べるようになっているため、どちらの文字コードの入出力にも対応する必要があります。

絵文字対応0: 携帯端末以外は絵文字変換しない

厳密には絵文字対応とは言いがたいのですが、PC のブラウザなどからのアクセスについては、絵文字変換を行わないという仕様になっています。絵文字が含まれているテキストを表示する際はそのまま表示し、入力されたテキストを DB に保存する際もキャリアは不明という扱いにしています。

絵文字対応1: スマートフォンからのアクセスでキャリアを判別する

前回の記事で触れたとおり、今のところどのスマートフォンも自社のキャリアの絵文字のみ入力できるという仕様になっています。なお、iOS5 の場合は au の iPhone でもパレットから入力できるのは SoftBank 由来の絵文字なので、正確には自社ではなく単一キャリアの文字ということになります。
このため、アクセスしてきたスマートフォン端末がどのキャリアのものか判別する必要が出てきます。従来の携帯端末に対してはアクセス元の IP 帯域やユーザーエージェントの文字列で簡単に判定できますが、スマートフォンでは簡単な判別手段は用意されていません。そのため、DECOLOG では次の手段で判別を行うことにしました。

iPhone

SoftBank絵文字が入力されたものとして扱う。

Android

ユーザーエージェントの文字列に含まれる機種名と出荷元のキャリアの対応表を用意して判別

ということで、またも力技です。なので Android の新機種が出ると都度対応表をアップデートしているという状況です。

絵文字対応2: スマートフォンへの出力で絵文字が表示できるようにする

端末のキャリアが分かると、まずは従来の携帯端末から入力された 3 キャリア別の DECOLOG 絵文字コードをスマートフォンで変換して表示できるようになります。変換ルールは前回の記事で説明したとおり、

種類	変換先
iPhone	SoftBank UTF-8 絵文字コード
DoCoMo Android	Google 絵文字コード (の DoCoMo 由来の範囲だけ)
au Android	Google 絵文字コード (の au 由来の範囲だけ)
SoftBank Android	Google 絵文字コード (の SoftBank 由来の範囲だけ)

となります。
これも変換テーブルを用意するわけですが、3 キャリアの絵文字コードをそれぞれ上の 4 パターンに変換するため計 12 種類のテーブルを作成しました。ただし、Andorid からモバイルモード(Shift JIS)のページにアクセスされた場合は、従来の携帯と同じ扱いとすれば良いので変換テーブルも従来の携帯向けのテーブルをそのまま適用します (それも含めると全 18 種類)。
といっても、これは手で作ったわけではなく、Unicode 6.0 の元になった emoji4unicode プロジェクトが作成した対応表の XML

http://emoji4unicode.googlecode.com/svn/trunk/data/emoji4unicode.xml

からほぼ機械的に作成できます。
例として、DoCoMo の DECOLOG 絵文字コードから au Android のコードに変換するテーブル(の一部)はこんな感じになっています。入力が UTF-8、出力が 16 進の数値参照形式です。

絵文字対応3: スマートフォンからのフォーム入力で絵文字を入力できるようにする

出力側が対応できたので次は入力側の対応です。DECOLOG ではそもそもメール投稿での絵文字利用をサポートしていないため、対応範囲は主にフォームから入力された絵文字ということになります (他に iPhone アプリからの記事投稿にも対応しています)。
スマートフォンから送出される絵文字を DB に格納するにあたって、そのコード体系は携帯時代の 3 キャリアの絵文字コードをそのまま踏襲することにしました。
最大の理由は、MySQL のテーブルが「utf8」で作成されていることです。iOS/Android 共に、送出される絵文字のコードは 4byte UTF-8 を含んでいます。これをそのまま「utf8」で作成されたテーブルに格納しようとすると、該当する文字以降がすべて切れて格納されてしまうという問題が発生します。MySQL で正しく 4byte UTF-8 を扱うためには、

• MySQL のバージョンを 5.5.3 以降にアップグレードする
• テーブルの文字コードを「utf8mb4」にする。既存のテーブルの場合、ALTER 文の実行が必要(!)

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

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

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

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

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

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

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

1. コスト的側面
2. 事業スピードの向上的側面
3. リクルーティング的側面
4. 技術研究的側面

など、決裁者に対して訴えるべきモチベーションはケースバイケースだと思いますが、こういうケースの場合、最終的には「それっておいしいの？（＝儲かるのか？）」というところに終着すると思ってます。

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

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

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

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

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

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

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

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

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

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

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

proposal for the system platform

View more presentations from Hiroshi Morotomi

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

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

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

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

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

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

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

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

古き良き(?)携帯の絵文字の仕様については既に解説が既に多くありますので詳細は省略します。(きちんとした用語を使って)解説しているページとして、以下を挙げておきます。

http://coderepos.org/share/wiki/Mobile/Encoding

なお、スマートフォン上の絵文字の仕様を理解する上で必要となる知識は、

• Shift JIS の空き領域 (85区〜120区) に絵文字が配置されている。具体的な位置 (コードポイント) はキャリアによって異なる。
  

  DoCoMo	112区〜114区
  au	101区〜103区 107区〜110区
  SoftBank	109区〜110区 113区〜114区 117区〜118区

  例えば「晴れ」の絵文字は、DoCoMo: 0xF89F, au: 0xF660, SoftBank: 0xF98B となる
  
• 上記の絵文字を Unicode で表すためのマッピング定義が各キャリアで公開されている。これもコードポイントはキャリアによって異なるが、いずれも基本多言語面の私用領域 (PUA, U+E000〜U+F8FF) 上に配置されている。
  

  DoCoMo	U+E63E - U+E757
  au	U+E468 - U+E4E3 U+E4E5 - U+E5DF U+E82E - U+E82F U+EA80 - U+EB1D U+EB1F - U+EB2D U+EB30 - U+EB8E
  SoftBank	U+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 または "" となります。
Shift JIS で記述されたページの場合は、HTML の数値参照形式で記述すれば良いです。「晴れ」なら "" となります。

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 で 0xE29880、0xEE818A、数値参照形式で "☀", "" のいずれかとなります。

HTML のフォームから送られるコード

Unicode 6.0 の絵文字コードが送られてきます。
UTF-8 で記述されたページの場合は、UTF-8 のコードがそのまま送られてきます。「晴れ」なら、0xE29880 です。
Shift JIS で記述されたページの場合は、UTF-8 のコードが HTML の数値参照形式(10進)に変換されて送られてきます。これは PC のブラウザでは一般的な挙動です(よく考えるとおかしいんですけどね……)。これは Unicode 6.0 の絵文字コードから Shift_JIS へのマッピングが存在しないからでしょう。「晴れ」なら、"☀" です。

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 全体としての対応はここまでのようで、実際にこの絵文字を使うためには、

Chefサーバーの容量不足になった時の対策メモ

はじめまして。hiroshiの部下、yoshitoです。

僕の主な仕事は、ここだけの話、hiroshiのゴキゲンをとることですが、稀にコードを書いたり、サーバーをいじったり、hiroshiの弁当を買ってきたりしています。

僕はとくに技術力が高いわけではなく、難しい事は他の方々がさくっとやってくれるので、僕はみなさんがゴキゲンよろしくお仕事ができるようにサポートしています。

技術的なものはあまり書けないと思いますが、社内の雰囲気をお伝えできればと思います。

しかし。
ネタが無いので、今回は技術ネタにしましたさーせん！！！！

：Chefサーバーのディスク容量が増えすぎて困ったですの巻

以前の記事で紹介されているように、DECOLOGではChefというサーバー管理ツールを使ってサーバーを管理しています。
今回は、そのChefサーバーがディスク容量不足になってしまった時のことを紹介します。

DECOLOGのサーバーは、Zabbixというサーバー監視システムで監視されていて、サーバーの状態がおかしくなるとメールを送ってくれたりします。

今回の場合も、
「Chefサーバーのディスク使用量が90%を超えましたよ」
的なアラートメールが届いて、問題が発覚しました。

調べてみると、chef.couchというファイルがHDDのほとんどを占めている状態。




Google先生に聞いてみると、Chefが使っているCouchDBというデータベースシステムのファイルだということがわかりました。

ChefサーバーはCouchDBを使って、クライアントの情報を管理しており、今回はそのデータベースのファイルが大きくなりすぎていたようです。

教訓：

Chefサーバーが容量不足になったら

CouchDBを疑ってみる！

の巻

CouchDBは、ドキュメント管理に特化したデータベースです。（ってここに書いてありました）

特徴として、データが更新されるたびに、新しくリビジョンを作成するという特徴があります。
つまり、過去のデータをまるっととっておくわけです。

Chefで管理しているクライアントの情報がアップデートされるたびに、
CouchDB上ではそのデータが複製されて、情報を更新すれば更新するほどDBは肥大化してしまいます。

そこで、Compactionの出番です。

Compactionは、CouchDBに保存されている過去のデータを削除する機能。

Compactionを実行しましょう！

CouchDBは面白くて、RESTfulなAPIでアクセスできるんです。
URLを叩けば、お手軽にDBを操作できます。

例えばDBの情報を見たければ、Curlコマンドを使って、

$ curl http://localhost:5984

とすると、

{"couchdb":"Welcome","version":"0.11.2"}

こんな感じで情報を取得することができます。

ChefのDBの情報は、こんな感じです。

$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":3875,"doc_del_count":99,
"update_seq":5139079,"purge_seq":0,
"compact_running":false,"disk_size":455128299901,
 "instance_start_time":"1287986483011849","disk_format_version":5}

らくちんですね。

ということで、早速Compactionを実行してみましょう。

$ curl -H "Content-Type: application/json" -X POST http://localhost:5984/chef/_compact
{"ok":true}

OK！

確認してみましょう。

$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":3875,"doc_del_count":99,
"update_seq":5139107,"purge_seq":0,
"compact_running":true,"disk_size":455131086952,
"instance_start_time":"1287986483011849","disk_format_version":5}

おおお!
compact_running:true
になってます。うまくいってそうです。

Compactionが終了すると、
compact_running:false
になります。

結果

　Before

$ df
 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/sda2            564436604 481904116  53398212  91% /

　After

$ df
 Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2            564436604  37030504 498271824   7% /

効果絶大。 めでたし めでたし。

で、隠してましたが実は僕が紹介した内容は
すべてここに書いてあります。
僕がよくtommyさんにRTFM(*1)って怒られますが、そういうことですね。

ちなみに、CouchDBの読み方はカウチです。

*1 : Read The Fucking Manualの略。「マニュアル読んで」的な。実際、大抵のことはマニュアルに書いてあります。

EC2インスタンス管理の極意

[新春特別企画]2012年 女子のスマホ事情徹底解析!!

どうもこんばんわ。目で負かし、心で伝える、変幻自在のエンターテイナーhiroshiです。

というわけで今回は新年特別企画ということでDECOLOGから見えてくる最近の女子のスマホ事情を予測してみました。

といってもこういうタイトルつけたらブクマが100ついたり100RT超えたりするかもしれないからつけただけで、実際はapacheの生ログからおもむろに100万行抽出して、そのユーザーエージェントから機種情報を整理しただけなのでかなりテキトーな数字です。そのテキトーな数字に僕のテキトーな分析を添えてあなたにお届けします。

iOSバージョン別

表1. iOSバージョン分布

図1.iOSバージョン分布グラフ

過半数が5以上です。個人的にはiTunesを使ったバージョンアップのハードルの高さはそれなりに高いと思っていたのでiPhone4Sとauの参入をきっかけに乗り換えた人が多いのかな、と考えましたが、iOS5がリリースされた10月以前のiPhoneのPVを鑑みるとiOS4からのアップデート組もそれ相応にいるように思いました。

Androidキャリア別


DoCoMo 57.41%
au 　　　37.89%
SoftBank 4.66%

全体(docomo6割強,au3割,SB1割弱)の割合と比較するとauの多さとSBの少なさが目立ちますが、SBの少なさは特に説明はいらないでしょう。auが多めなのは嵐のおかげなのでしょうか。データがテキトーなのでいろいろ考えるのにはちょっと微妙な数字です。


Android OSバージョン別

表2. Android OSバージョン分布

図2. Android OSバージョン分布グラフ

2.3系がほとんどですね。まあこれはなんていうかそれ以上のコメントはないです。

Android 機種別ランキング

表3．Android機種別ランキング

Galaxy SⅡが2位以下を大きく引き離しての1位です。4位のGalaxy Sと合わせてブランド別でもGalaxyが1位のようで、現在のモバイルメーカー情勢を表した結果と言えるのかもしれません。

それを追うのがXperiaシリーズですね。ここで気になったのは、「そういや”女子向けスマホ”としてプロモーションされていたXperia-rayはどこぞ？」ということでした。探してみたところ45位と意外な位置に。個人的にも、昨年9月末に機種変更をしたさい、今の愛機であるIS05の対抗馬として考えた機種で、おサイフケータイさえ付いていればおそらくrayにしてたであろう、思い入れのある機種だったのでちょっと驚きでした。上位の機種を見ているとなんとなく昨年の夏休みにAndroidに乗り換えた方が多いように思いますので、発売時期が8月末ということで、夏休みの終わりごろだったのも１つの要因なのかもしれません。

その後、僕の愛機でもあるIS05などシャープ製の機器が目立ちますが、やはりここで注目すべきはIS04が4％あまりのシェアを持つことでしょう。様々な伝説を持つこの機種ですが、「HTML上のmailtoリンククリックでメーラーを立ち上げたときに、宛先アドレスの全長が30数バイト（正確なのを忘れた）を超えるとメーラーが宛先を拾わない」という地味すぎる仕様は他のメジャーな仕様に隠れてあまり知られていないかと思いますが、会員登録を始めメール送信ありきな機能が多いDECOLOGにおいては致命的な仕様だったため、日増しに増える問い合わせを背にその対応に追われたのも今では良い思い出です。

なお、現在ではケータイアップデートを行なっていただくことにより、この問題は解決しますので、もし万が一DECOLOGユーザーの方かつIS04をご利用の方がこちらをご覧になっていましたならば何卒ケータイアップデートをしていただきますようお願いいたします。

その他

IE

31875	IE 9
20962	IE 8
3359	IE 7
2339	IE 6

これはナウいですね。StatCounter Global Statsを見ればこれがどれだけナウいことかがわかると思います。

ゲーム機

1695	Mozilla/4.0 (PSP (PlayStation Portable); 2.00)
1284	Opera/9.50 (Nintendo DSi; Opera/507; U; ja)
764	Mozilla/5.0 (Nintendo 3DS; U; ; ja) Version/1.7455.JP
614	Mozilla/5.0 (PLAYSTATION 3; 1.00)
211	Opera/9.30 (Nintendo Wii; U; ; 3642; ja)
116	Opera/9.50 (Nintendo DSi; Opera/446; U; ja)
104	Mozilla/5.0 (PlayStation Vita 1.51) AppleWebKit/531.22.8 (KHTML, like Gecko) Silk/3.2

PSPはXperia-rayより多いです。

windowsモバイル

110	Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0; FujitsuToshibaMobileCommun; IS12T; KDDI)
3	Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Toshiba/X02T; Windows Phone 6.5)
1	Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 8.12; MSIEMobile 6.5) T-01B

家電量販店の店頭でIS12Tは触ってみましたが、思っていたより操作性がよくて驚いた記憶があります。が。。。

それにしても見事１を叩き出したT-01Bはすごい。笑っていいともだったらタモさんストラップ10000個くらいもらえるレベルだと思います。

というわけで、いかがでしたでしょうか。繰り返しますがこのレポートはけっこうテキトーにとったデータを元に僕がテキトーにコメントしています。どれだけテキトーなのかは僕が統計学を学んでないのでよくわかりません。もしかしたら統計学的には冒頭に紹介したデータの取り方でもよいのかもしれませんが、そんなことはないでしょう。

また、なんとなくDECOLOGでの「機種別所有者」の割合っぽく書いてしまいましたが、正確には「機種別アクティビティ」の割合になると思います。

日常生活においてもエンジニアリングにおいても、数字を客観的に読む力というのは大事だと思うので、こんなお遊びでも実際やってみると良いトレーニングになると思います。お手元にウェブサーバの生ログがある方はぜひやってみてはいかがでしょうか。

最後に、データ抽出して整理してくれた上に僕にブログネタとして書く権利を譲ってくだすったtommy氏にはテキトーテキトーいったことを深くお詫び申し上げたいと思います。

それでは、みなさん、また会いましょう。