Chrome Extensionで社内メールを「いいね～」したい（第1回）

前口上

　今日は、1ヶ月振り2回目のエントリとなりましたチーフテクノロジストの稲村です。前回のエントリは『私の出会った、できるプログラマ』でした。

　最近はPlay frameworkやCoffeeScriptが楽しいです。



　私の担当回では、これから何回かに分けて、社内で使う為のChrome Extensionを作る過程を書いていきたいと思います。ただ、今まさに勉強しつつ作っていこうという段階なので、次回以降方向性が変わる可能性もありますし、最悪断念する可能性も0ではない点ご了承下さい:-)


　第1回となる本エントリは、概要の説明と現時点で考えている技術要素について書いておきたいと思います。

何を作るか

　一言で言うと『社内のメールに対して「いいね～」できるChrome extension』です。

　モンスター・ラボでは社内インフラの1つとして、Google Appsを利用している為、大半のメンバーがブラウザでGmailを使っています。おまけにだいたいChromeです（たぶん）。そこでメールを表示する画面にChrome extensionで「いいね～」というボタンを埋め込み、メールを読んで「わざわざ返信したり声をかける程ではない（もしくはタイミングが無い）けど良いと思った」際に気軽にそれを伝えられるようにしたら、コミュニケーションに役立つのではないかと考えました。



　なおこのextensionの企画は『モンスター・アワード』という社内のゆるい企画コンペに思いつきで出したところ、まさかの優秀賞となった為実際に作る事になったという経緯があります。

『モンスター・アワード』とは？

（モンスター・ラボ 社長ブログより引用）


新規サービス企画を誰でも発表できるカジュアルな場として「モンスター・アワード」という企画コンペを年に2回実施しようというものです。

これまでも月1の全社会議でいつでも新規事業案を出せるような制度はあったのですが、もう少しライトにかつイベント的な要素（ノリ）も入れてやってみようということで、飲食できる場所を貸し切って実施します。

機能概要

1. 各メールのヘッダ部分（差出人の横あたり）に「いいね～」ボタンが表示される


2. ボタンを押すと、差出人に対して「いいね～」が通知される


3. 通知はだいたいリアルタイムにされるので、なんか楽しい


4. 「いいね～」した側、された側共に自分の送受信履歴を見る事が出来る

課題

・メールの特定

　「いいね～」送信側と受信側で共有されているものとして、メールという事でMessage-IDが候補となります。が、GmailのDOMをちょっと見た感じ、通常の閲覧画面ではMessage-IDは取れなさそうです。また他に何か無いかと見てみましたが、今のところ画面から取れるものでユニークなものは無さそうです。URLのハッシュ値も、送信側と受信側で異なっていました。

　という事でいきなりちょっと困りましたが、本extensionのゆるい性格を考えると厳密に特定できなくてもまあ良いかと思えるので、「件名＋送信日時」で代用する事にしました。但しいくら社内用とは言え、メールの件名を丸ごと送信したりDBに保存するのはかなり微妙です。それが理由で使われなくなったら本末転倒になってしまいます。よって、件名は受け取った人が「あぁ、あのメールか」とだいたい分かるだろうという事で先頭3文字くらいにしょうと考えています。

　なお送信側で後から「いいね～」したメールを確認するのに使えるので、URLのハッシュ値もそれ目的で保存しようと考えています。こちらは本人以外は知っても意味の無い値と思われる為、そのまま保存します。

技術要素

1. 画面にボタンを埋め込む
    
   
      
   • Chrome extensionのContent Script
   
      
   • jQueryによるDOM操作
   
    
   
   


2. ボタンが押されたら、差出人、送信日時、URLのハッシュ、件名の1部をサーバに送信する
    
   
      
   • XMLHttpRequest
   
      
   • サーバ側（Play framework予定）
   
    
   
   


3. 自分への「いいね～」を取得し、通知を表示する
    
   
      
   • Chrome extensionのBackground Pages
   
      
   • Chrome extensionのDesktop Notifications
   
    
   
   


4. 通知をリアルタイム化する
    
   
      
   • HTML5のWebSocket
   
    
   
   

最後に

　次回から、上記技術要素に沿って書いていきたいと思います。冒頭にも書いた通りまさにこれから作ろうという段階で、次回分だけは一応モノが出来ていますが、それ以外は手付かずです。何が言いたいのかと言うと、たぶん最後まで行くのに3ヶ月くらいかかると思います。



　ちなみに名前が「いいね～」になっているのは、「いいね！」よりも更に気軽に送りあいたいという意図です。モンスター・ラボも次第に人が増えて（と言っても30数人ですが）、みんながみんな躊躇わずに全社メールで一言レスできる感じでも無くなってきたので（私は平気でやりますが…）、何かしら軽いコミュニケーション、それもポジティブなものをできないかという事でこんなものを作ろうと思っています。



[モンスター・ラボでは一緒に企画・開発する仲間を募集しています]

iOSメモリー管理について話します。

こんにちは。

金琪峰(キム　ギボン)と申します。

最近アプリのメモリー管理について悩んでいる方がいますので。

私が知っていることを説明します。

100%信じないでください。

でも、メモリー管理の概念は正しいと思いますので

これを読む方に役に立って欲しいです。：）

iOS プログラマーなら一番面倒くさいと思うことがメモリー管理だと思います。

このメモリー管理について話します。

Javaプログラミングをした方は

Garbage Collectionが自動的にメモリー管理をしてくれるので

初めてiOSを開発した時たくさん荒てたと思いますが。

Apple社はエンジニア(開発者)が直接メモリー管理をするようにわざわざ誘っています。

理由はモバイルという環境のせいです。

デスクトップみたい良い環境の場合には几帳面にメモリー管理をしなくても大きい問題にならないですが。

モバイル端末の場合は

最適化されたメモリー管理によってアプリの動作が完全違います。

それでApple社はわざわざメモリー管理を開発者がするように誘っています。(強要しています!!)

１）一旦メモリー管理の基本的な概念は

retainと releaseで管理が成り立ちます。

Objectを振り当てたら retainCountを +1 になります。

使い終わったObjectに対して releaseをしたら retainCountが -1になって

総retainCountが0になったら自動的にObjectが消えます。

例）

ClassA *obj = [[ClassA alloc] init];

...

[obj release];

正確にどの時点に retainCountをチェックして Objectを解体するかは後で説明します。

じゃ、retain/ releaseのおかげで(？)

開発者は自分が生成した 全てのObjectに対して使い終わった時点で必ずreleaseをしなければいけないです。

簡単に少ないObjectだけ使うプロジェクトなら良いですが

Classファイルが100~1000個ぐらい大きいプロジェクトに一々メモリー管理をすること想像して見てください。 >_<

それで。。。

２）Apple社で提供をするのがautoreleaseと言う奴があります。

何か自動的にメモリーを管理する奴みたいです。

そうですが、自動的なメモリー管理は50%だけです。

なぜならいつ自動的にreleaseをするかのを分からないので

急にアプリがクラッシュになる可能性があります。

私が経験したところによれば80%は問題ありませんが20%自分が予想出来なかった時点でクラッシュになります。

autoreleaseのせいで勝手に消えたObjectを参照しようとしてクラッシュになります。

そしてもう必要がないObjectをずっと持っているようになってしまうので, これも非效率的です.

それじゃこの autoreleaseは一体いつ使用をするのか? 疑問です。ー＿ー？

このautoreleaseという概念は内部で Objectを生成して使い終える時使います。

例えば

TestMethodと言うMethodがあると仮定します。

こいつはMethodの内でNSArrayを生成して, このNSArrayを返還する役目をします。

もしNSArrayをautoreleaseかけなくて生成した場合はメモリリークになってしまうのでずっと気を使ってくれなければならないはずです。

開発者立場ですごく面倒になります。

それで普通こんな場合にはTestMethod内で return Objをする時 autoreleaseをかけておいたら

これ以来には変換したarrayについて気を使わなくても良いです。

例）

- (NSArray*)TestMethod{

     NSArray *arry = [[NSArray alloc] init];

     ….

     return [array autorelease]; //あらかじめかけておいても良いです.

}

こんな感じです。

この TestMethodを呼び出した Object内ではこの autoreleaseがかけているarrayをどうやって使うか悩みます。

なぜなら

autoreleaseがかけていたら, いつかObjectが解体されるかも知れないからです。

解決方法はarrayに retainをかけて使うことです。

つまり, これからarrayはA Object自分が管理をすると言うことと同じです。

それでは開発者立場では気を使う領域が減ってメモリー管理をするのがもっと易しくなります。

簡単にObject刑を受け取る時retainをかけて使って使い終わったらreleaseをかけたらおわりからです。

例）

NSArray *tmpArray = [[self TestMethod] retain];

つまり、autoreleaseは特定 Objectに retainCountを管理する権利を委任する時使われると思えば良いです。

でも、iOSを開発する時

[[Object alloc] init]; 

でObjectを生成しなくて使う場合があります。

例えば

NSArray *array = [NSArray array];

NSDictionary *dic = [NSDictionary dictionary];

NSString *str = [NSString stringWithFormat:@"%@", str];

等。。たくさんあります。

上のObjectたちを使い終えてreleaseをかけてくれた時アプリがクラッシュになったことがあると思います。

どうしてクラッシュになるか。

理由は内部的にautorelease処理をするからです。

内部的にautorelease処理になっているObjectをreleaseをしたので

後でautorelease処理をする時

[nil release]をするようになります。(=_=;;

autoreleaseはここまでです。

３）最後に Propertyのメモリー管理があります。

Javaの setter/ getter のような概念です。

他のObjectからinstanceを参照する時使いますが。

このObject instanceにretainをかける場合があります！！

下記のように宣言して使います。

@property (nonatomic, retain) NSMutableArray *tmpArray;

この retain オプションが問題です。

例）

xxx.tmpArray = other_Array;

これに使う時

内部の処理を見たら

if(tmpArray)[tmpArray release];

tmpArray = [other_Array retain];

return tmpArray;

になります.

内部的に retainをかけます。

これが問題です!!

retainが内部的に自動でかけているので

propertyのオプションにretainのかけたら必ずrelease処理をしなければいけないです。

だったらいつ処理するか？

それは

クラスのObjectが解体される時

- (void)dealloc{

　　[obj1 release];

      ...

}

-(void)dealloc Methodが呼び出しになります。

- (void)dealloc で release処理をすれば良いです。

今まで

1) retain/ release

2) autorelease

3) property

について説明しました。

今からは

内部的に隠された retain/release管理に対してもっと調べます。

先に NSArrayのような配列にObjectを入れる場合があります。

例）

[tmpArray addObject:obj];

この時内部的にretainがかけられます。

もっと説明したら

AObject *obj = [[AObject alloc] init];                              // retainCount +1

NSMutableArray *tmpArray = [NSMutableArray array];

[tmpArray addObject:obj];                                             // retainCount +1

合わせてretainCountが2になります。

そして後でreleaseをしても-1だけなのでObjectが解体されないです。

結局メモリーリークになります。

それで配列にObjectを入れる場合には特別な場合を除き

autorelease 処理をして入れます。

もちろんDictionaryの場合も同じです。

＃＃応用編＃＃

iOS開発本を見れば

[self.view addSubview:tmpView];

[tmpView release]

こんなrelease処理ををよく見られます。

これが何を意味しましょうか?

iOSは UIViewを管理する時 Arrayの概念で管理します。

つまり、一番初めに addSubViewになるViewが 0 indexの ViewのArrayに入って行きます。

このUIViewに関するArrayが self.view.subviews です。

NSArrayで addObjectになる時内部的に retainがかけるのを理解している方なら

この後どうして releaseをしてくれるのかも理解できると思います。

文が長くなりました。

長い内容読んでくださってありがとうございます。

仕様変更について

こんにちは。モンスター・チャンネルのシステム担当、橋本です。

コンピューター・システムの開発者にとって、「仕様変更」というのはとっても嫌なものです。

せっかく作ってテストも終わっているのにプログラムを書き換えたり、

ひどい場合は全部捨てて作り直さなくてはいけません。。

プロジェクトをスムーズに終わらせ、お客様にも喜んで頂けるようチェックリストを作ってみました。

□ 開発中のシステムの提案書・見積書を見たことがない

営業が提出している文書に、開発者の知らない前提条件や提出物が書かれているかもしれません。すぐにチェックしましょう！

□ 用件定義書・仕様書がないが、実装を進めている

論外です。すぐに作りましょう！

□ お客様との仕様に関する打ち合わせに議事録がない、またはあってもお客様に確認してもらっていない

お客様との打ち合わせをしたら、すぐに議事録を作って送付して確認して頂くべきです。

それをやっていないと、お互いの認識にズレが最後まで尾を引く恐れがあります。

□ あって当然だと思える機能がないが、仕様書に無いので作っていない

たとえば売り上げレポートの表示画面に、一覧をダウンロードする機能がないなど。

仕様書に無くても、お客様の利便性を考えると当然必要と考えるべきです。

□ 仕様をフィックスしたかどうか、お客様に確認をとっていない

「この仕様で作ります」という確認を取らずに作っていると、

後で追加や変更を切り出されても仕様変更と認めて頂けませんね。

□ お客様にバグを指摘され、ついでに仕様追加を要求された

バグやスケジュール遅れを指摘されると、お客様に対して引け目を感じてしまい、

ついつい無条件に引き受けてしまいがちです。

バグはバグ、仕様変更は仕様変更で切り離して考えましょう。

□ 仕様に矛盾点があるが、設計書をお客様にレビューして頂いたのでそのまま進めてよい？

設計書をお客様にレビューして頂いたからといって、漏れや間違いを放置してはいけません！
もう一度お客様に確認しましょう。

□ 出来上がったアプリケーションの動作が遅いが、用件定義書にパフォーマンスの項目が無いので問題ないと思う。

たとえ明記されていなくても最低限のパフォーマンスは確保すべきです。

さて、あなたのプロジェクトは大丈夫でしたか？

では良いエンジニアライフを！

iOS5の顔認識を使ってみた

技術系の仕事してます。
泉と申します。(_ _)>


遊んでる訳じゃありません。仕事の為に、先にいろいろ実験してるんです。
言い訳じゃないですよ。


iOS5に搭載された顔認識機能を使ってなんか作ろうと思って遊んでみましたが
まだweb上にあんまりサンプルがないのと、幾つかハマったポイントがあるので
書いとこうと思います。(技術系の人でないとさっぱり分からんと思いますが)
ただ、iPhoneいじり始めで怪しい部分が多々あるのでまんま信じないでください。




●やろうとしたこと
　iDetectが左右の目と口の位置が検出してくるので、
　ビデオ入力(640*480)でリアルタイムで顔認識して、目の状態変化を追って
　目の位置にレイヤーかける様なこと


●ハマったポイント
 iDetectorの検出設定と出力される座標方向、ビデオバッファの座標、
  画面との位置合わせの座標関係が？？？？だった。
　


【検出設定】
　ここは普通に資料でわかりますが、iphoneを縦に普通にもってる状態、横構え状態などで
　カメラに対する顔の方向が変わるので、これをまず設定せねばなりません。


   NSNumber* orientation=[NSNumber numberWithInt:orientation_];  
   NSDictionary* foptions=[NSDictionary dictionaryWithObject:orientation    
   forKey:CIDetectorImageOrientation];


  ただ、デフォルトが横構えになってるのと、OpenGLとか使う場合など、
　再定義する必要があるケースがあり、なにを入れればいいの？となるので
　orientation_になにが入るのと言うと、だいたい下の様になります。
　(縦持ち以外はまだ動かしてないので間違ってたらごめんなさい)


 　switch (orientation) {
    case UIInterfaceOrientationLandscapeLeft:
        orientation_=1;
        break;

        orientation_=3;
        break;

      orientation_=5; 
        break;

      orientation_=7;
        break;
      default:break;
   }




【iDetectから出力される座標方向】
   検出方向で、縦だとか横だとか設定するにも関わらず、iDetectorの返す座標は、
　　横に構えたときの座標になります。(0,0)は横に構えた場合の左下すみです。


・横構えで見てるとき   
----------640------------
|                   
|     目      目
|         口
↑
(0,0)→ -----------------
　　


・縦構えで見てるときも基準位置は横のときのままです。
 つまり、縦に構えてるときは、xy逆に考える必要があるということです。


(0,0)→--480--
↓     
|
|　　目　目
640　  口
|
|
| -----------




【ビデオバッファの座標方向】
　検出した目とか口の部分の画像情報を取ったり、ARするのに重ねたりするとかすると
　対応する位置のビデオのピクセルバッファを取得する必要があります。
　
　bitmapなんかを触った人は経験があると思いますが、bitmapだとピクセルバッファは
　画面の下から入っています。が、そうだと思ったら逆でした。
　逆にiOS良くできてるな～と思います。


  ＊こっちの左右は、videoのinput設定でミラーとかすると変わりますので、
　　別途注意がいります。




(0,0)→ ------640-----
↓                 
|     目    目 
480      口
|
 --------------------


　
【画面との合わせ】
　バッファをいじるのでなく、上にレイヤーとか重ねようとする場合、
　ビデオのバッファが640*480だとしても、画面は320*460?だっけ？なので、
　比率を調整しないと、位置が合いません。
  縦に構えてる場合などは以下の様にすればとりあえず合います。
   f.leftEyePosition.y*preview_.frame.size.width/480;
   f.leftEyePosition.x*preview_.frame.size.height/640;
   f.rightEyePosition.y*preview_.frame.size.width/480;
   f.rightEyePosition.x*preview_.frame.size.height/640;




今回はとりあえずこれだけ。
ではまた。




























  

リズムについて

おはようございます。mingです。

monstar.labではミュージックプロデューサーという肩書きでお仕事させていただいてます。

僕は主にmonstar.ch(モンスターチャンネル）というBGMサービスで選曲したりしてます。

ですので、僕の出番のときは主に音楽についてのお話をさせていただこうと思います。

皆さまこれからどうぞよろしくお願いいたします。

まず今回は、「リズム」についてを話そうと思います。

が、そーんなにすごい知識はありませんので悪しからずでお願いします。

■リズム■

リズムは、二拍子とか四拍子とかがグループ化したとき（そう感じたとき）に生れるそうです。

テレビやネットやラジオや携帯で流れる最近の曲のほとんどは
この「リズム」にのせて歌ったりして、

曲のスピードを上げたり下げたりでさらに雰囲気を出して、

メロディの明るい暗いでまたさらに感情を表現しているように感じます。

ですから、リズムも何かの理由を元に生れると僕は考えています。

このことを深く実感したのは、以前アフリカ音楽に触れるイベントに行った際に

「ポリリズム」を説明されたときでした。

■ポリリズム■

その時に話してたことによれば、ポリリズムとは要は言葉の訛りだ　とのこと。

たとえば、「キリマンジャロ」という山の名前、

僕たち日本人はすぐにコーヒーを連想して「キリマンジャロ」

というワンワードがインプットされると思います。

キリマンジャロを僕たち感でリズムにすると・・・。

♪キリマンジャロ・キリマンジャロ・キリマンジャロ♪

となります。あったりまえですけど。

ですが、キリマンジャロは　スワヒリ語で

キリマ=山

ンジャロ=白い

という意味で　

実際は白く輝く山という意味だそうです。

でわ、本当の意味の言葉をリズム化すると

♪キリマ　ンジャロ・キリマ　ンジャロ・キリマ　ンジャロ♪

となり、

土っぽい雰囲気のアフリカンなリズムが生れます。

実際に同じテンポで手拍子しながら、二つをつぶやいて比較してみると

より実感できるはずです。

簡単にいうと、こういった現地の言葉の「なまり」がポリリズムだそうで、

なーるほど人間の日常のなかからもリズムは生れているのだーと当時は感心しました。

言葉の意味（理由）によっても生れるこのような「リズム」ですが、

自分自身の様々な生活シーンの中で音楽をチョイスする際に、この「リズム」は

とても重要な作用を起こす一部になると思います。

実際、BARやラウンジなど、「遊び」に「食」や「会話」という複数のシーンが起る

場所でのDJの際には、シーンに似つかわしくないリズムをミスセレクトしちゃうと

お客さんよりも先にお店のスタッフたちに冷たくどやされますW

そんだけ空気を壊すってことですね。。さすがに今はありません。きっと。･･･あれ？

わかりやすく例えば、まさに近々やってくるクリスマス。

特に我々オトコ共の中には、素敵なサムシングをおこすべく

そんなシーンに自分で音楽をチョイスする輩も多いと思いますが、
こんなときにもリズムのセレクトは大切です。

■超スロウな2拍子の中に感じる3拍子■

クリスマスで二人きりであれば余計に

特別な空間を演出したいと草食男子以外は思うはず。

そこにBGMという武器は必ず出てきますが、

アカラサマにアマアマなアダルトコンテンポラリーばかりをかけまくっても

魂胆みえみえでヒジョーにダサくなるどころかヒかれてしまうこともありそうです。

ですから、ビートがややはっきりしたものでムードが出る曲が最適なのですが、

先日とあるスロウな曲をきいていて発見しました。

座ってても自然に体が揺れて、すこーしずつ落ち着きを誘発するリズムが

素敵なサムシングを起こすには更に最適じゃないかと･･･。

そのリズムってのは・・・・

超ゆっくりとした「ドン　　　　ｯツパッ」的な
R&B調のビートの中に三拍子がなぜか浮かんでくる
ようなリズムの曲です。

いっけんスロウなR&B調で体がゆれているのかと思いがちですが

ドラムのウワモノやリフから3拍子を感じれていけば、
ドンブラコ・ドンブラコと

落ち着きながら体が揺れて触れ合って・・
みたいな効果が出そうな気がします。


ディスコやクラブで、踊るカラダがぶつかって男女の仲が深まっていったりすることが
あったりしますが、ある種同じようなカンジがレイドバックな空間でもリズムで起きる
ような気がします。

信じるか信じないかは　アナタ次第ですが

そもそも音楽に愛が無いと魔法はおきません。

ありがとうございました。