iPadの感想
iPad買いました(Wifi/16GBモデル)。数日使ってみただけだけど、非常に完成度の高いデバイスで、ほぼ期待通りの満足度を感じてます。
海外ではちょっと前から発売されてたこともあって、ある程度事前情報があったんだけど、やっぱり自分で使ってみて初めてわかることもあり、他のサイトにはあまり書いてなくて、自分が感じたことについて書いてみようと思います。
(ちなみにこのエントリはiPadで書きました)
全体的な速度について
全体的に非常に軽快にスルスルと動きます。アプリの起動や切り替えも早く、またWebサイトの表示がストレスなく快適に表示されます。もちろんFlashが搭載されてないので見れないサイトは見れないんですが、大部分のサイトはストレスなく参照できます。
こういったポータブルデバイスでは、もっとCPUが速ければ、もしくはメモリが多ければ快適になるのに、、、ってのを感じる事が多いのですが、iPadの場合、現時点でのスペックでの完成度が非常に高くiPhoneのように3Gを買って、そのあと発売された3GSのサクサク具合を見てがっくり、みたいなことにはならないかなと思います。
恐らくこれから1年後以内にiPadのさらに新しい機種が発売されるとは思いますが、ゲームコンソールのようにスペックは固定しつつ、軽量化してバッテリー増やして値下げする、という方向性もありじゃないかと思っています。
数ヶ月後にはiPhoneの新機種が発表されますが、もしそのスペックがiPadと同じ(画面解像度以外)になって、かつそのスペックのデバイスの供給期間が長いとなると、ゲームコンソールのようにそのデバイスに対するアプリの作り込みをしやすくなるため、かなり強力なエコシステムになり得るんじゃないかと予想しています。
アプリについて
海外での発売は早かったとはいえ、iPhoneに比べやはりまだまだiPadに対応したアプリは少ないです。もちろんiPhoneのアプリがそのまま動くので使えなくはないんだけど、iPadでそのまま表示するとかなり小さく表示されてしまうし、拡大表示すると文字の画像がそのまま表示されるのでめちゃめちゃ汚いので、残念なことにまったくもって使う気がしません。
ただiPhoneの場合、アプリが用意されてないと結構使いにくかったのが、iPadだとWebサイトが普通に見れるので、アプリの必然性はiPhoneより低いと思います。
例えばクックパッドは、現時点でiPhoneアプリしかなく、iPad対応アプリが用意されてないんですが、Webサイトが普通に見れて、サイトも非常に使いやすいので、もうiPadアプリをわざわざ開発する必要はないんじゃないって思っています。
もちろん作り込んだアプリの方が使い勝手は上になるとは思いますが、今後Androidベースのタブレットが登場してくる事を考えると、サイトを作ってる人はHTML5+JavaScriptでしっかり作り込んでいくのが将来的な方向性かなと感じました。
その流れで考えると、今はiPhone/iPad/Androidのアプリレビューサイトがいくつかありますが、Webサイト/Webアプリのレビューサイトが必要になってくるのかなと思ってます。
例えばiPadで一番みやすい天気予報サイトはこれだ、みたいな。
UIについて
すっごい細かい部分なんだけど、iPadのUIでよくできてるなって思ったのがあったのでちと紹介。
iPadの標準的なUIで左右二つのカラムがあって、それぞれスクロール出来るんだけど、二本指を使えばこれを両方同時に操作できる。
って普通の人はふーんって思う内容かもしれないけど、プログラマの視点で見てみると、結構これって実装大変な気がするんだよね。
PCってアプリが複数動いてたとしてもマウスは一つしかないので、UIの操作ってのはシングルタスクになる。
でもiPadはマルチタッチで操作ができるので、UIの操作もマルチタスクで実行できてしまう。マルチタスクで出来るってことは、いろんな操作を同時にしたときの挙動をちゃんと考えなきゃいけないってことになり、プログラムが破綻しないようにするってのは当然なんだけど、ユーザーから見て自然な操作になるようデザインするってのは、想像以上に大変だと思う。
iPhoneでもマルチタッチはできてたんだけど、画面解像度が小さいので同時に操作出来るオブジェクトってのはほとんどなかったんだど、iPadだと画面上にいろんなものを置ちゃうので、ちゃんとそこを考えて実装しなくてはいけない。
ちなみに標準のUIの部分でちょっと試した限り、同時にスクロールしたり、スクロール中に他のボタンをタップしたりってのをやってみると、ちゃんと思ってた通りの挙動になってるので、こういった部分の作り込みはさすがだなって思いました。
コンビニのおもてなし
うちの近くにあるコンビニなんだけど、ベビーカーで連れていくと、コンビニから出るときには必ず店員さんがドアを開けててくれる。
レジにお客さんが並んでても、ダッシュで開けてくれるのだ。
はじめは同じ女の店員さんが開けてくれてたので、気が利く人だな、くらいにしか思ってなかったんだけど、今日は別の男の店員さんが開けててくれた。
多分コンビニのオーナーの教育が行き届いてるんだな、きっと。
素晴らしい。
退職金
さてこのたび転職して、今はもう新しい仕事を始めている。
んでもって退職金が少しばかし手に入る訳だが、これの使い道を今考えてます。
あんまり豪遊はできないけど、せっかくなんで色々と買い物をしようと思ってるんだが、今のところ候補はこんな感じ。
■液晶テレビ
東芝のREGZAが第一候補。んでもREGZAはうちの嫁さんには評判が悪い。
いわく、こんなかっこ悪いテレビ買うやつは福山のファンしかいねぇー、とのこと。
さんざんな言われ様だw
ちなみに、こことかの記事を見ると、やはりお買い得な気がする。
http://ascii.jp/elem/000/000/404/404633/
＃と思ってたら、ちょうど今日新型の発表があったみたい。
＃んー、どうしよ
■ネットブック
ねっころがりながらうぇぶうぇぶ出来る軽いノートPCが欲しい。
ってことでネットブックを買いたいわけだが、以外と種類が多く、どれがいいのかいまいちわからん。
■椅子
ノートPCがあっても結局はデスクトップも使うわけで、今使ってる椅子は長時間使ってると、
腰が痛くなるので、ちょっといい椅子が欲しい。
全部買う事についてはあまり迷いはないんだけど、どれを買うか選ぶのが面倒だなぁって思う今日この頃。
（これがお勧めってのがあれば、誰か教えてちょ）
子育て日記開始
子育て日記初めてみました。
http://d.hatena.ne.jp/r-hana/
Androidデベロッパーチャレンジ
最近ちまたで話題(?)のGoogleのAndroidですが、デベロッパーチャレンジなるものを開催するらしい。
http://www.google.co.jp/intl/ja/press/pressrel/20071113.html
ちなみにAndroidを簡単に説明すると、携帯上のOSのことで、Androidのアプリを作るってのは、
Androidが搭載された携帯電話のアプリを開発することに相当します。
デベロッパーチャレンジの総額1000万ドルってのに心惹かれたので、
Android上で自作アプリ作るとしたらどんなのがあるかちと考えてみた。
残留思念
ちと適当な名前が思いつかなかったんだけど、別にオカルトなアプリじゃない。
必要なのはGPSとネットにアクセスできる携帯。
まず残留思念(＝メッセージのことね)を残したいユーザーは、適当な場所でメッセージを書き込む。
そうするとGPSで読み取った位置情報とそのメッセージがリンクされ、
他の人は、そのメッセージを書き込んだ場所の近くじゃないと読めない。
書き込んだ場所の近くじゃないと読めないってのが不便に思えるけど、
他の場所の余計な情報は入らず、入ってくるメッセージはだいたいその場所にリンクしてる情報だし、
その場所ならではの情報ってのが面白いと思う。
残留思念って名前がオカルトな感じで、イメージしにくいかもしれないけど、
すっごくローカルな情報をメッセージとして残せるので、
例えば、すっげーうまい(or まずい)飯屋に行ったとして、
その情報をその店の近くに残留思念として残しておけば、
近くを通りかかった人はそのメッセージを読み取って、その店に行くか行かないか決めれるわけだ。
また、残留思念の公開範囲を設定して、教室一個分だけにしておけば、
学校で同じ授業に出てる人達ためだけのメッセージをやり取りすることもできるようになる。
もちろんこういうのは携帯の掲示板とかを設置しておけば今でも出来るんだけど、
残留思念のやり方だと事前準備は必要ないし、アドホックな掲示板をいつでもどこでも設置できるってのがミソかな。
あとはちょっとしたオリエンテーリングのツールとしても使えるかも。
最初のヒントから得た情報を元に、ある場所に行いけばそこで残留思念のメッセージが読めて、
次のヒントに進める、とかね。
・・・
でもよく考えたらこれって Android じゃなくっても、今のiアプリでも出来るわ。
つーわけで Android ならでは、というのを考えるのは難しいので、
とりあえず今の携帯でも出来そうな事も含めて、新しいアプリを考えてみよ。
監視カメラ
携帯のデジカメで撮影した画像データを、常にサーバーにアップし続けるアプリ。
そのアップされた画像をPCで表示しておけば、携帯カメラがあたかも監視カメラのように使える。
FOMAとかはテレビ電話があるけど、テレビ電話だと画像を一つの携帯にしか送れないけど、
サーバーにアップするやり方にすれば、その画像は複数台のPCで見れるし、
他の携帯でも見ることもできる。
もちろん第一用途は盗さ・・・(以下自粛)
デジカメバトラー
昔あったバーコードバトラーってやつのデジカメ版で、
バーコードバトラーはバーコードを読み取って、それを攻撃力・守備力・素早さとかに数値化したけど、
デジカメバトラーは携帯のデジカメで撮影した画像データからパラメータが決まる。
パラメータは画像が一ドットでも変化すれば、大きく変わるようにしておけば、
うまくバランスのいいパラメータが生成される画像というのは、
とにかく画像を撮りまくって試してみるしかないってことになる。
バーコードバトラーのように、画像→パラメータ化→バトル、という単純なゲームにしてもいいけど、
このパラメータ化のロジックに、ある程度の偏りをあえて入れてみて、
例えば赤が多い画像だと攻撃力が強くて、素早さが低い、
青だと守備力は高いけど、攻撃力が弱い、みたいな感じにするもよし、
画像認識をもうちょっとがんばってみて、
男の画像だと普通に攻撃するけど、女の画像だと体力回復する、
とかってのができれば、RPGでの戦闘コマンドとして使えるんじゃないかな。
つまり、普通のRPGだと、攻撃する種類をコマンドとして選ぶけど、
攻撃するときに毎回画像を撮影して、その画像を元に攻撃方法やパラメータが決まる。
これだと、とにかく攻撃したいときは赤い男の画像を撮影するし、
回復したいときは青い女の人(できれば美人w)を撮影することになる。
これ、PSPのデジカメ使って、電車の中でやれると面白いかも。
今日のところはここまでー
ブログワールド
むー、前回の日記からまたもや期間があいてしまった。。。
というわけでちょいと頭に浮かんだアイデアを書いてみる。
まず、そのサービスはユーザーがブログを書く事から始まる。
ブログを書くと、そのエントリが数値化されてポイントとなる。
例えば今日のエントリは123点です。みたいな。
もちろんそのポイントは、エントリの長さによって増減するわけではなく、
内容によって(ハッシュ値等)決められる値で、その値の計算方法は未公開なので、
どういった値になるかはエントリを書いてみない事には分からない。
で、その値がポイントとしてその人に加算されるわけだけど、
そのポイントを何に使うかというと、ブログワールドというところにパーツを置く為に使う事ができる。
例えばRGPツクールみたいに、マップにオブジェクトを置いていくような感じね。
http://www.enterbrain.co.jp/digifami/products/rpgxp/capt01.gif
そのマップというか、ここではワールドと呼ぶけど、ワールドはみんなの共通のスペースになってて、
自分が置いたパーツは他の人に見えるし、他の人の置いたパーツは自分も見える。
パーツというのは2Dかもしれないし3Dかもしれないけど、そのパーツを組み合わせて配置すれば、模様になったりメッセージにしたりもできる。
さて、これが続いていくと、ブログのエントリを書けば書くほどパーツが置けるようになり、みんながパーツを置き続けていくと、
それがやがて一つのワールドになる。それがブログワールド。
とここまで書くと、セカンドライフみたく、ユーザーが自由にパーツとかを買って配置できるのと何が違うの？ってことになるけど、
ブログワールドは一つ一つのパーツがブログのエントリで構成されている。
つまりブログワールドを見てて、例えばここの部分はステキな模様みたいになってるけど、誰が作った(配置した)んだろうって思ったら、
そのパーツをクリックしてみるといい。そのブログのエントリに飛べるから。
それを見れば誰が作ったか分かるし、どういったエントリで出来たパーツなのかも分かる。
ブログワールドを眺めてみて、それを作り上げた人達の顔が背後に思い浮かべる事が出来るようなサービス、、、面白いと思いません？
P2P型分散共有ファイルシステム(その1)
Internet上でP2Pで通信する分散共有ファイルシステムを考えてみる。
基本的なストーリーはこうだ。
あるネットワーク上に、ユーザーA, ユーザーB, ユーザーC がいたとして、それぞれのHDDの総容量と空き容量は下記のようになっている。
| 名前 | HDDの総容量 | HDDの使用容量 | HDDの空き容量 |
|---|---|---|---|
| ユーザーA | 200GB | 80GB | 120GB |
| ユーザーB | 200GB | 40GB | 160GB |
| ユーザーC | 200GB | 20GB | 180GB |
| トータル | 600GB | 140GB | 460GB |
ここでユーザーAのHDDの空き容量は120GBしかないため、それ以上のデータを保存することはもちろん出来ない。
しかし、ここで考えている共有ファイルシステムでは、別のユーザーのHDDの空き容量も利用できるため、ユーザーAは最大460GBの領域を使用することもできる。
ただし、ユーザーAがすべての領域を使い切ってしまうと、ユーザーB/Cは追加のデータを保存することは出来なくなってしまう。
次に、このファイルシステムにデータの冗長性を持たせてみて、それぞれのデータは別のユーザーのHDDに必ずコピーされた状態で保存されるとすると、使用できる総容量は減るものの、ある一人のHDDが故障したとしても、別のユーザーのHDDに保存されたデータを使い、データが復旧できるようになる。
上記のような考えを実際に実装したものとして NRFS がある。
NRFSは、ネットワークRAIDファイルシステムの略だそうで、NRFSの特徴は上記URLより下記のように紹介されています。
NRFSの特徴
1. 複数(3 台以上)の PC もしくは WS を持っていればネットワーク RAID ファイルシステム(NRFS)を使用可能 → 高価な RAID 装置を購入する必要がない
2. 訂正可能な障害はファイルシステムが自動的に修正 → ハードウェア交換が必要な障害に対しても停止することなく交換作業が可能
3. マシンレベルの冗長性を持っている → 故障ノードの電源を切断して修理作業を行ってもファイルシステムは運用可能(システムレベルのホットスワップ)
4. 自動的にファイルシステムの内容を引き継ぎ 1 台ずつのマシン交換可能 → 低コストかつ便利でメンテナンスが容易
5. Gigabit Ethernet レベルの高速 LAN 上において NRFS を使用 → SAN (Storage Area Network) として同様な運用も可能
・データのビット等を自動修正し、ディスククラッシュ時もファイルシステムが停止せずに運用でき、 ディスククラッシュ時からの復旧のための莫大な作業時間も削減
・NRFS のベースとなる NFS 自体が分散共有ファイルシステムを実現しており、 さらに NRFS は高信頼性を付加しているため、 NRFS を高速ネットワークと共に使用することで、 高価な SAN 用ディスクサブシステムを導入する必要がなくなる。
NRFSはIPAの平成 12 年度・13 年度の未踏ソフトウェア創造事業の一環として開発のサポートを受けたようだが、最近は開発が止まっているのか Linux kernel-2.2.16 で動くコードしか公開してないようだ。
kernel-2.6系で動くのであればすぐにでも試してみたかったし、実際使えるのであれば使ってみたいと思えるユースケースがあったので、とても残念である。
さて、上記のNRFSの特徴と、Winnyの特徴を組み合わせたものを、P2P型分散共有ファイルシステムとして考えてみます。
そのファイルシステムは、まずNRFSの特徴である、ディスククラッシュ時でも訂正可能な障害はファイルシステムが自動的に修正することで、ファイルシステムが停止せずに運用できるという機能を有し、また、Winnyの特徴である、データをP2Pで通信し、自動的に接続先のノードを探して、それぞれが保持するキャッシュデータを交換する、という機能を持ったファイルシステムになります。
ユーザーから見たストーリーで説明すると、あるユーザーがP2P型分散共有ファイルシステムを立ち上げて、自分専用の領域を作成し、その領域にファイルをコピーすると、そのデータは自分のローカルHDDとは別に自動的にInternet上の別のユーザーのHDDにもコピーされ、もし自分が使ってるPCがクラッシュしても、別のマシンから自分専用の領域をマウントすることで、Internet上に分散されているデータをかき集めて、復旧できるようになっています。
ただし、データの分散のし具合や、データを保持してる別のユーザーがずっとオフラインのままだと、データが失われる可能性があるため、もしデータを失わないようしたいのであれば、データのコピー数を多くする必要があるでしょう。
こう考えると、データが常に複数コピーされるため、冗長性のためとはいえディスクの空き容量が無駄に消費されていってしまうという可能性もありますが、もし保存されたデータとまったく同じデータを別のユーザーが元々保存してた場合、そのデータは複製する必要はなくなるため、冗長性を保ちつつ、ディスク容量を節約できるようになります。
例えば、Winnyでは大量の画像・音楽・動画が流れてるそうですが、それらのデータはそっくりそのまま多くのユーザーのHDDにコピーされてるため、こういったデータは（データの違法性はともかくとして）P2P型分散共有ファイルシステムで共有して保存するのに向いてるでしょう。
また、Winnyはファイル交換を目的として作られてるため、データの暗号化はほぼ行われてない(Winnyクライアントなら誰でも受信可能)が、P2P型分散共有ファイルシステムで自分専用のファイルシステムとして利用するのであれば、他のユーザーのHDDにデータを保存はするが、そのデータの中身は見られては困るということはあるでしょう。
その場合は、データを分散する際に自分が持ってる公開鍵で暗号化し、データを復旧する場合は、自分しか持っていない秘密鍵で復号化すればいいでしょう。ただし、暗号化してしまうと、データが同じかどうかが判断できなくなるため、データを別のユーザーと共有できなくなってしまいます。
共有されるディスクの総空き容量がある程度多くて、自分が利用できない別のユーザーのデータが勝手に自分のHDDにコピーされても問題ないという環境であれば、暗号化した状態で分散するのもありでしょう。
・・・今日のところはここまで。続きはまた今度。
