デブサミに呼んでもらいました
翔泳社が主催されている10年後も世界で通じるエンジニアであるために Developers Summit 2012の座談会に呼んでもらいました。このような晴れ舞台に呼んでもらえたのは初めてで、嬉しいのと自慢したいのでエントリーを書こうと思ったのですが、それでは読んでいる方になんの利得もないので、感想を書いてみようと思います。
会場
開催会場は、目黒駅から徒歩ですぐのところにある雅叙園でした。結婚式場だそうですが、その威風堂々とした入り口に圧倒されました。
その内部も豪華絢爛で、建物の中なのに、池があり、竹林があり、藁葺の家がありました。天井や壁の修飾も美しく、歴史がありそうなもので、キョロキョロするばかりでした。
日本にはこんな場所があるんだなって、驚きました。
座談会
呼んでいただいたのは、http://seshop.com/se/timetable/21の
2月16日 [Mobile Technology] 15:25〜16:15 16-D-5】
iPhoneアプリ開発者座談会2012
高橋 征義 氏 / shachi 氏 / 上原 昭宏 氏 / 増井 雄一郎 氏 / 川畑 雄補 氏
でした。スポンサ企業また聴衆の方々の層、そして座談会の皆様の顔ぶれから、ハードウェアとソフトウェアの微妙な境界を領域としている自分にはアウェー感がいっぱいです。
なにがあったか
バックヤードでの座談会の打ち合わせ、座談会、またその後の会話がごちゃごちゃに記憶していて、自分の思い込みも混ざったと思うのですが、印象に残ったことを列挙してみます。
アプリのデザイン
アプリの魅力を決めるデザインは、紙ベースの静的なデザインをする方と、動的なデザインをする方がいるよね、という話がありました。
今のスマフォのアプリは、動きや感触の表現が大きな魅力となるので、後者の動的なデザインをする方と組みたいね、という感じでした。前者の紙ベースのデザインをする方は、ウェブ系でFlashを好まない経験を持っているウェブ系のデザイン領域の方に多く、後者の動的な方は、Flashとかが出身の方が多いよね、とのこと。動的なデザインをする方と組むと、例えばアプリのデザインが、1枚の静止画ではなくて、映画やアニメと同じ絵コンテで出てきて、さらにFlashでプロトタイプを作られてくるので、アプリを作る側はそれをみてタイミングやアニメーションを作ればいいので、とてもやりやすい、とのこと。
過去にウェブにアニメーションを取り入れた時に、魅力が引き出しづらかった経験があったとしても、今のスマートフォンの時代での成功体験にあわせて、デザインが担う役割が違ってきているのかなと思いました。
あと、会社の組織で、このアニメーションはいいぞって開発者が思って作っても、その上の人が、アニメ？だめだめ、な意見の方だと、そこを突き通してアニメなアプリを出すのは突破に工夫がいると。だが出ちゃって、ユーザがアニメいいねっって言うと、けっこうするっとそのままいっちゃうとか。
iPhoneとAndroid
いろいろなところで聞きますが、iPhoneとAndroidでユーザ層が違うんだなと。iPhoneユーザは、するっとお金を支払うけど、Androidユーザは、デフォルト構成のままアプリをインストールすという考えがないっぽい？とか。日本でiPhoneに対してAndroidは台数で3〜4倍あるのに、アプリダウンロード数は課金で1/10、無料でも1/2程度と。アプリのダウンロードを知らないのか、また最近のAndroidのマルウェアや不正なアプリについての報道でアプリ自体を入れないのだろうか、とのこと。
iPhoneはアプリなど使うこと楽しむ端末、Anrdoidはネットを使う端末(ブラウザとメールが使える電話機プラスアルファ)、かなというのが印象に残りました。
10年前と10年後と
デブサミが10周年で、全体テーマが開発者の10年後は？だったので、10年をキーワードにした話がありました。10年後を予測することはまず無理ですが、逆に10年前を振り返るとメールが企業に導入されて、”前略”ではじまる長ったらしい電子メールが、ビジネスルールとして定着、それに業務時間が費やされていたインターネットの普及期、でした。
今現在のコミュニケーション手段は、SkypeやFacebookやTwitterで、チャット的に短い必要な文章をやりとり、必要があればSkypeで喋り、また仕事相手とは数ヶ月に一度はリアルに顔をあわせる、という、かなりダイナミックに変化している、感触でした。ただ、皆さんの仕事のやり方は、現在ではまだ少数派かもしれないので、10年後にこれが多数派になるかは分からないかもです。例えば、Githubでソースをみた方がお前のソースはいい仕事だからこの仕事を頼みたいとか。そんな感じのお仕事の流れ。
開発者の概念は違ってるよね、って感じでした。例えば10年前だと、VCやVB、あるいはEXCELが使える人が開発者と呼べるようになった感じで、10年後はターミナルでコマンドを叩けるレベルは開発者だろうと。また、例えばUnityみたいに、道具を供給する側と、その道具を使う(使いこなす)人に、更に分極するかなと。いまどきのスマフォは、演出、デザイン、あるいは課金の導線など、必要な構成にあわせて、それらを開発する人達全体をみると、開発者が何を示す言葉なのかは、変化するんだろうなと思いました。
海外とのお仕事
海外との仕事と日本での仕事は違うよね、が面白かった。海外だと、ディレクターが、この目標この(具体的な)イメージをやりたいのだと、成果物を明確に伝えてチームを率いる感じ。日本だと、機能説明が文章で長々書いているけど、ユーザには何を体験させたいのか？と、開発者がその意図を逆に尋ねてしまうとか。また日本だと明文化すらなされず、わかるだろ、みたいな空気感で進行があるとか。海外だと、文化圏が違うから、あきらかな明文化せずには仕事にならない背景があるから、違ってくるんだろうなと。
海外から仕事を頼む人が、日本の開発者をみる目が面白かった。今は円高で日本人開発者は高い。それにインドなどにも開発者はいる。試しにインドの技術者と仕事してみたら、今は荒削りなところもあるけれど、5年もすればちゃんとした戦力になると思うし、彼らは英語圏でコミュニケーションができるやつらだから、使える、という感触。
じゃ、日本人開発者の意味って？ それは、日本という文化を持っているところがあるんじゃないかと。例えば、日本でうける萌えゲーを作ろうとすれば、その空気感が分かる日本人じゃないと作れないと。逆に、日本人が米国でウケるゲームを作ろうにも、その空気感がわからないと作れないだろうと。日本だと萌え、じゃ米国で萌えみたいなものは？って思うと、それゾンビかな、と。米国では、ゾンビの日というのがあって、その日は映画館がずっとゾンビ映画ばかりかけたり、街中みんなでゾンビの仮装をするそうな。文化、違いすぎる。
出張の締め
私が乗る品川から豊橋までの新幹線は本数が少ないので、品川での待ち時間がよく発生します。
なので夕食は品川駅でインドのカレー。チーズとほうれん草のカレーとココナッツミルクたっぷりのフィッシュカレー。おいしかった。
おみやげは、新幹線乗り場近くで売っている、芋羊羹。
iPhoneで外部機器を動かすインタフェースの選び方
これは
iPhone/Androidで外部アクセサリ/外部機器を作りたい方に、インタフェースの選び方などを聞かれるので、情報をまとめます。素早く作るなら有線ならRedPark社のシリアルインタフェース、無線ならWiFiが手軽です。一般販売するなら、部品コストとAndroidでも動く利点から、有線ならイヤホン端子の利用、無線ならBluetooth4 low energy、の利用範囲が広いです。
iPhoneで外部機器を動かすには
公式のiPhoneと外部制御機器との接続端子はドック端子のみです。このドック端子には、オーディオ入出力、シリアル信号、USB、FireWireおよび電源端子があり、外部機器接続に必要な機能が全て提供されています。ただし、このドック端子を使うにはApple社とMade For iPhoneプログラムの秘密保持契約(NDA)締結が必須です。このNDAのもとで、iPhoneが正規のアクセサリー機器と確認するための認証チップの技術情報およびアプリ開発に必須のフレームワークが提供されます。
MFiプログラムが不要の外部機器開発手段
小規模の研究開発、試作でMFiプログラムを選ばない場合の、ドック端子以外の方法には、有線ならば汎用MIDIインタフェース、RedPark社のシリアルケーブル、およびイヤホン端子、無線ならば、WiFiおよびBluetooth4 Low energy (BLE)があります。
概要プレゼンテーション資料が、iPhoneで外部装置の作り方概要は：
OTOduino_iPhoneアクセサリ開発_ギークラボ6月28日_プレゼン
イヤホン端子を使う開発は： View more presentations from akihiro uehara
Ot oduino i_phoneアクセプレゼンpart2
にあります。
View more presentations from akihiro uehara
岐阜高専カンファでのプレゼンテーション
2月4日に岐阜県大垣市のソフトピア ドリームコアで開催された 高専カンファレンス in 岐阜 - 高専カンファレンス Wiki でプレゼンテーションをしました。
プレゼンテーションの録画動画は：
このプレゼンテーションのスライドの元になったスライドは：
MY LIFE AS A KIGURUMI
です。 View more presentations from akihiro uehara
私は高専出身ではないのですが、実行委員の方とご縁があり、カンファに呼んでいただきました。基調ということで、何を話そうかと思ったのですが、時代の流れやIT普及が引き起こす、働き方への考え方の変化や多様な稼ぎ方が、興味を持ってもらえるのではと思い、自分自身の独立してから2年間の体験を紹介しました。
昨年から今年にかけて、何かの節目を感じさせる流れが続いています。例えば、国内や国外での震災、またここ数年以内に首都圏での大規模震災が生じる可能性が指摘され、さらには大手電機メーカーが決算で巨額の赤字を出すなど。そん大きな流れが変化する中で、小さな我が身の置き方、その大きな流れの変化の自分なりの楽しみ方を考えるきっかけになればと思いプレゼンテーションを組み立ててみました。
プレゼンテーションで伝えたかったのは、今の立ち位置が学生でも会社員であっても、外的要因に決定的な影響をうけてしまわないように、そして余寿命のスパンで自分が技術そして仕事を楽しむには、3つくらいの立ち位置を持っておくことではないか、ということでした。例えば会社員であっても、仕事外で趣味や自己学習をとおして違う世界で通じる力を身につけることもできそうです。そして今の、技術ではなく使いこなす方が増大しているという意味で、発達したIT、例えば、ブログ、フェイスブックやツイッターなど、を通して情報を広め、また集約していくことで、情報の流れの中での存在感を高めていくことができそうです。これは、例え兼業や副業が業務規程で禁止されていても、お金のやり取りを伴わないやり方などで、立ち位置を作れる時代が来ている、それを活用してみては？という提案でした。
ただ、そんな固い話を真面目にまとめると、とてもではないですが5分も聞いていられません。そこで、自分自身の体験に話題を絞ることで、自分をイタい人にして(実際、かなりイタいですので)、聞き方により他人ごとにできるよう、またまどか☆マギカを混ぜることで、希望と絶望は同じものだよと言外に置いてみました。
そんな感じです。
演出やる人向けのObj-Cのコードの書き方、めも
これは
Objective-Cの講師をしていて演出系な人に説明した時の、こう書けば楽ができるよ、情報をまとめてみる。processingで演出をやっているけど、if文, switch文って知っているけど難しくって使えないな、という直感的なコーディングをしている方むけな感じで。環境はiOS4またはiOS5。iOS5のSDKをARC有効とします。コードは、意味が分かる程度で書くので、このままコンパイル通りません。
要は
- 目的：動かしてみてデバッグ、なんて必要を減らす。書いたら動く、そんなコードにする。
- 手段：コンパイラがエラーを出してくれるような書き方をする。
- 例：定数は定義する。動作パラメータやプロパティ名とか、スペルミスしたら動かないところは定数宣言にする。
- 手段：コンパイラがエラーを出してくれるような書き方をする。
- 目的：簡素で出戻りがいらないコードの作り方をする。
- 手段：何を作るかを紙に書いてから、画面に向かう。
- 例：モデル-View-制御、の3つの役割に分けて、考える。みたまんま(玉を動かすから玉のオブジェクトを作る、とか)だけでは、破綻する時がある(複数の玉が衝突する処理がいるとき、どこに衝突検出と反応のコードを書くか、わからなくなる)
- 手段：プログラムを作る考え方をする。
- 例：機能は何か、時間経過でどんな処理(機能)をするのか、モデル-View-制御はどう組めばいいか、を分析する。
- 例：”機能”は1つのメッセージにまとめる。メッセージの名前がその機能を、引数がどんな情報でその機能が動くのかを、明らかに示してくれる。
- 手段：何を作るかを紙に書いてから、画面に向かう。
位置などが変化する画像の表示
雪がうえからチラチラ降ってくるコードを見るとこんな感じだった。
@interface ViewController : UIViewController {
UIImageView *snow1, *snow2;
}
ViewControllerにUIImageViewを必要な数だけ変数宣言しておいて、
- (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view, typically from a nib. [NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@(timer:) userInfo:nil repeats:nil] } -(void)timer:(NSTimer *)timer { snow1.frame = ランダムな位置; 以下snow2に対して同じ処理... }
それの位置変更処理をNSTimerで一定時間ごとに呼び出して処理している。
変数は配列で扱うと便利
雪みたいな細かい画像を1つづつ処理してたら大変なので、配列にまとめます。配列毎に処理していきます。
//雪の数とかは、定義しておくといい。10個という直接の値(マジックナンバー)をコードのいろんな所で書き散らかすと、値を変更するときに手間、かつ、どこかで修正もれが出てバグる #define NUM_OF_SNOW 10 @interface ViewController : UIViewController { NSMutableArray *snows; //配列を宣言する }
UIImageViewを必要な数だけ変数宣言しておいて、
- (void)viewDidLoad { [super viewDidLoad]; snows = [NSMutableArray new]; for(int i =0; i < NUM_OF_SNOW; i++) { //10個の雪を表示することにする [snows addObject:[[UIImageView alloc] initWith...]; //雪のインスタンスを作る } [NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@(timer:) userInfo:nil repeats:nil] } -(void)timer:(NSTimer *)timer { //for文+イテレータで、配列の要素を取り出す処理を自分で書かなくてもいいから楽。 //何番目の要素か分からないといけないときは、普通にfor(int i=0; i < [snows count]; i++) {...という書き方をする。 for(UIImageView *snow in snows) { snow.frame = ランダムな位置; } }
とすれば、雪の数の増減でコードをいじらなくてもいい。
一定時間経過した後に処理する
例えば、触られたらなにか反応して、その1秒後にまた反応するものを作るとして、タッチイベントで、sleep()とかすると、アプリの動きが止まる。
- (IBAction)someImagetouched:(id)sender { UIImageView *img = (UIImageView)sender; img.frame = 移動位置; sleep(1); //ちょっと経ってから img.frame = 次の移動位置; }
プログラムの実行は、スレッドという単位でコードが処理されている。UI周りはメインスレッドで処理されていて、一定時間ごとに処理すべき項目が順番に処理されていく(NSRunloop)。sleep()という関数は、スレッド自体の動きを指定時間止めるので、UIの処理の途中でsleep()したら全てのUI処理が停止する。こんな時は、非同期処理を使う。
- (IBAction)someImagetouched:(id)sender { UIImageView *img = (UIImageView)sender; img.frame = 移動位置; double delayInSeconds = 1.0; dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC); dispatch_after(popTime, dispatch_get_main_queue(), ^(void){ img.frame = 次の移動位置; }); }
この書き方で、dispatch_afterの処理は、一定時間が経過したら、NSRunloopが自動的に取り出して処理してくれる。
タイマーの使い方&UIViewクラス継承を使う
UIViewControllerにViewごとの処理を全て書いていくと、この処理はどのViewの処理だっけ？とごっちゃごっちゃになる。View1つで完結する処理は、Viewクラスにまとめてしまえば、コードの見た目がすっきりする。
例えば
@interface snowView : UIImageView { NSTimer *timer_; } -(void)start; -(void)stop; @end @implementation snowView -(void)start{ if(timer_ != nil) return; timer_ = [NSTimer scheduled...]; } -(void)stop{ if(timer_ == nil) return; [timer invalidate]; timer_ = nil; } -(void)timer:(NSTimer *) { 位置移動の処理; } @end
View毎にNSTimerを使ったらメモリ消費が、とか考えなくてもOK。たぶん、読み込んだ画像やUIViewのほうがよっぽどメモリを消費している。NSTimerをたくさん使うとNSRunloopの処理が増えてUIがカクカクになるのでは？っていうのは、タイマーの時間間隔を広めにして、アニメーションと組み合わせて、見た目を滑らかにする工夫をすればOK。
UIVewを継承したクラスを作っておくと、InterfaceBuilder(以下、IB)で自分が作ったクラスを配置できるから便利。IBでUIViewを適当に置いて、右ペインの左から3つめのタブをクリックして、Custom Classを例えば"snowView"にすれば、さっき作ったクラスインスタンスが配置できる。同じクラスをたくさん配置するときは、インスタンスが1つづつ配置されて面倒。こんなときはIBOutletCollectionで配列にまとめれば、扱いやすい。
外側に見せる変数はプロパティを使う
クラスの外側に見せるときは、”かならず”プロパティを使う。その理由は：
- どの値が外からアクセスできるのか、明示的にコードに表現できる。(ドキュメント並みの情報)
- 値変更のタイミングで処理を入れられる。
- 読み込みだけとか、参照がstrongかweakかなどのメモリ管理など、面倒なところを隠してくれる。(自動生成してくれる)
例えば、タイトル文字列を指定して、それが表示される処理はこんな感じ。
@interface snowView : UIImageView { public: //public変数でも、値が渡せそうだけど？ NSString *title; } @property (strong, nonatomic) NSString *title; //明示的にセッターを定義してもいい。セッターは引数を取るから、メッセージの最後に必ず":"が必要なことに注意。 // @property (strong, nonatomic, setter=setTitle:) NSString *title; @end @implementation snowView @synthesize title; //プロパティの自動生成 // セッター -(void)setTitle:(NSString *)title { [setNeedDisplay]; } -(void)drawRect:(CGRect)rect { //実際の描画処理 } @end
まずプロパティでtitleを指定しておく。titleが変更されたら、それを表示に反映しないとけいないので、[setNeedDisplay]を呼ぶ。これを呼ぶと画面更新のタイミングでdrawRect:が呼ばれるので、その中で実際の描画処理をおこなう。UIViewを継承していると、UIViewの流儀にそった描画処理が使える。
プロパティの属性には、nonatomic/atomic, (NSObjectに対しては) strong/weak, read/readwrite、がある。
最初のは、変数アクセスの排他処理を行うか否か。いくつものスレッドが平行して走っているとき、1つのプロパティに同時に読み書きが生じる可能性がある。何も書かないときはデフォルトでatomic指定になる。atomicを指定してあれば、変数を読み書きできるのは1つのスレッドだけ、という排他処理を(コンパイル時に自動で)いれるので変なことにならない(設定するわけがない、化けた値が読み出されるとか)。だけど大抵のコードはUI処理とおなじメインスレッドで処理されていて排他処理は速度を低下させるだけの無駄なものになる。だからほとんどのコードでnonatomicがおまじないのように書かれる。
strong/weakは参照カウンタを+1するかしないかの違いで、デフォルトはstrong。ほとんどの場合strongでいいのだけど、delegateをプロパティで保持する場合は、メモリの参照循環が生じてメモリ解放されなくなるので、delegateはweak指定をする。これは、例えばUIViewControllerがUIViewを継承したインスタンスを持っていて、そのプロパティにselfをdelegateに入れたとする。UIViewControllerはすでにUIViewを参照して保持しているのに、UIViewがdelegateとして親のUIVivewControllerをstrongで保持してしまったら、互いに参照値を+1しているから、メモリが解放されない。delegateを指定するのは、そのインスタンスをすでに保持している場合だから、delegateまでstrongにする必要はない。だから、おまじないのようにweakにしちゃうのも、ありかもしれない。
readonly/readwriteは読み書きの設定。外部に伝えたいけど、変更されたら動作の支障になる値はreadonlyを指定しておけばいい。デフォルトはreadwrite。
あとはsetter/getterというのがある。プロパティは、見た目変数として使えるけれど、その実態はメッセージ。セッター/ゲッターの名前は自動生成ルール(set/getにプロパティ名の先頭を大文字にしたものが、デフォルトのメッセージ名)に従い、@synthesizeで指定したら自動生成されている。Key Value Observationの仕組みも、この自動生成されたコードに入ってくる。先の例のように、値の変更タイミング、取得タイミングで、いろいろと処理を行いたい場合がある。例えばUI表示に反映するするとか、値が妥当かチェックしてから取り込むとか。そんなときにゲッター/セッターの名前を指定するのがこの属性。
単純なpublicな変数として外部に値を解放するメリットは、ない。プロパティを使いましょう。
変数を置くのは、使う場所、共有すべき場所で分ける
クラスが使う情報をAppDelegateに置くと、AppDelegateに暗示的に依存するから、もしもあとでコードを取り出し再利用すると、AppDelegateに必要な実装がなくて動かないけれど、その原因がわからない、なんてことになる。だからAppDelegateに値を置くことは止めたほうがいい。どうしてもアプリケーション全体で共有すべきデータがあるなら、必要な情報を1つのクラスにプロパテイとしてまとめて(バリューオブジェクト)、それをinitのときに引数で渡せばいい。この仕組を入れておけば、例えば値が変更されたら、表示に反映するなどの動作を後からKVOで実装できる柔軟性が得られる。
目に見えない依存関係は、動かない原因を探すときに、とても厄介なものになる。データにしろ、機能にしろ、なにかに依存するなら、明示的に引数で渡す書き方をして、明らかに表現するのがいい。
delegateとKVOの使い分け
状態変化等の処理を外部に出したいときにdelegateを使います。@protocol で委譲したい処理がメッセージ名と引数で明確に表現できるのが利点です。値の変化をみるだけ、ならばKVOが便利です。プロパティのsynthesizeでKVOのコードが自動生成されるので、delegateを定義してコード内で通知するコードを書く手間がありません。通常delegateは1対1になります。処理を外部に委譲するのが目的なので、1対1になるだろう、ということです。例えばNSMutableArray *delegates;みたいにプロパティでreadonlyで外部に見せて、[delegates addObject:self], [delegates removeObject:self]とおまじないとすれば、その他のdelegateに影響せずに複数delegateも実装可能ですが、これが必要になる場合は、処理を外部に委譲する、というもともとの意味から逸脱していると思うので、構成などを見直すほうが楽でしょう。
2011年、年末物欲リスト
賞与、ローンやボーナス支払いを組んでいなければ、生活費とは切り離された可処分可能な収入。そんな素敵なボーナスシーズンに向けて、11月から12月に発表されるユニークな新製品をリストアップしてみました。テーマは、作る、書く、見る、遊ぶ、の3つ。
作る
まずはオリジナルマインドからの、ご家庭用の数値制御の削り出し装置。樹脂はもちろん真鍮等の柔らかい金属の加工ができる、個人でロボット工作をしている方には便利な一品。前作のBlackIIシリーズが10万円程度に対して13万円程度と多少価格があがったが、軸にハンドルが付いて手動操作が可能になり、またモータ制御回路のインタエースが現在では入手が難しいプリンタポートからUSBに変更されて、使いやすさに磨きがかかっています。
KitMillでは大きすぎるな、そんなに常時使わないし、ソフトとか設定がめんどくさそう、そんな方にはローランドのiModelaがいい。先ほどのKitMillよりずっと小さいテーブルサイズで、本体を収納するケース付き。加工可能な大きさは名刺大、加工可能な材質は樹脂だけど、加工用のソフト一式がついたフルセットで7.5万円とお値頃。この手の削り出す装置は、削り粉が周囲に飛散するため、外周を覆うケースが必要だけど、これは外周カバーがついているから、(それほどには)削り粉が飛ばない(はず)。
私は、これを使った、これまで切削装置を使わなかった分野や、面白い発想が出てくるんじゃないかと期待している。例えば、削り節の塊から、かわいい動物の像を削り出した、猫向けの楽しいおもちゃ、とか。
書く
デジタル時代になっても手書きの手軽さ、文章と図を思考を妨げずに素早くまとめ上げる気持良さは、変わらない。そんな手軽さを実現できるのが、ワコムのInkling。超音波+赤外線でペン先位置を検出して、描画データに変換するものだけど、よくあるその手のペンと違うのが、1024段階の筆圧が取れること。Wacom Pen Tablets & Interactive Pen Displays | Wacom 価格は1.8万円。ケースが凝っていて、ケーブルやペン先を収納できる。データの吸上げがUSBだけなのが残念で、もしもBluetoothでiPhoneにデータ転送ができればと思うのだけれども。
もっと手軽にデジタルな手書きを楽しみたいならブギーボード。 これまでのブギーボードは書いたら消す、シンプルな黒板としての使い方だったが、それにデータ保存機能がついたもの。価格は1.5万円。しっかりしたノートを手書きかつデジタルデータにするならば、解像度の高さと動作の安定さで海連のTechNote TechNoteでデジタルな手書きノート生活 - にがつうさぎ以外におすすめ出来る製品はないけれども、ちょっとしたラフ図を書き入れたい、でも紙データは別にいらない、用途にはいいだろう。
見る
なぜか映像と音は、すでに手持ちの機材があるだろうに、何度も買い足す人が多い、こだわりなのか、ただの新しもの好きなのか、理解は難しいジャンル。
ソニーが出してきたヘッドマウントディスプレイ(HMD)。自社で培ったシリコンに形成した液晶駆動回路に直接液晶をのっけた精密な表示デバイスを使った、これぞ最上といわんばかりのスペック。しばらくは予約分だけで製品がさばかてしまって入手困難かもしれない。
映像を見るを極めていくHDMとは別に、映像を見る場面ごとにユニークになっていくHDMもある。
たとえばこのエプソンのHMDは、Android2.2を搭載したシースルータイプのHMD。ヘッド部分のデザインは無骨だし、商品構成はAndroidプレイヤーに液晶を接続しただけじゃないかと、ハードウェアだけを見るとチャチャを入れたくなるが、今のデジタルな映像環境で映像を楽しむHMDという提案は、楽しいと思う。価格は6万円。
さらにモバイルな環境に特化した製品なら、こんなのが400ドルである。ゴーグルの中に小さい表示器とAndroid搭載装置を組み込んだもので、GPSなども搭載している。スキーをしつつ、コース指示や時間配分などのデータ表示を提供するなど、屋外で新しい利用方法があるかもしれない。
他にも100ドルくらいのスリムなHDMもある。単なるスリムなHDMならたくさんあるけれども、ここは開発キット(内部の表示器と開発用の回路？)を提供する(らしい)のが面白い。自分オリジナルのHMD開発のベースとして、楽しめるかもしれない。
遊ぶ
iPhoneでラジコンというとARDroneという飛行ラジコンがあったばかりだったが、今年はiPhoneで操縦するラジコンがいろいろ発売されてきている。
こちらは赤外線操縦の車。
これはヘリコプター。
そしてWiFi操縦の車。カメラ搭載で遠隔撮影ができる。
どれも価格が50〜200ドルの範囲で、iPhoneとつながるから、で高価格を狙っていないのが印象的。目新しさがあっても、値頃さもなければ、売れないのだろう。
まとめ
この年末に発表される新製品を漫然と並べてみました。
iOSで連続したアニメーションを発行する
iOSでアニメーションを実行している最中に、別のアニメーションに繋ぎ変えたいときのやり方メモ。例えば、Viewが上から下に移動している最中に、動作キャンセルが入って、Viewを下から上にアニメーションで戻したいとき。
オプションに、 options:UIViewAnimationOptionBeginFromCurrentState を指定してアニメーションを発行すればよい。
オプションを何も指定せずに別のアニメーションを発行すると、今実行しているアニメーションが強制終了されてから、次のアニメーションが実行されるために、先の例だと、Viewが一度下まで移動して、そこから次のアニメーションが開始されるため、動きの見た目が不連続になってしまう。
MacでOpenCV 2.3を32/64-bit ユニバーサルにビルドする
MacではOpenCVを使ったアプリは32-bitでなければカメラが使えない(っぽい)ので、ユニバーサルなライブラリをビルドした。その方法は、環境変数 CMAKE_OSX_ARCHITECTURES を指定するだけでいい。以下、メモ:
手順
- OpenCV 2.3.1 のソースを入手、展開 http://sourceforge.net/projects/opencvlibrary/files/opencv-unix/
- CMakeを入手 http://www.cmake.org/cmake/resources/software.html
mkdir build; cd build; export CMAKE_OSX_ARCHITECTURES="i386;x86_64" cmake ../ make sudo make install (/usr/local/以下にインストールされる)
