Xacti DMX-HD1000 (黒) を買いました。
Full HD (1080i, 1920×1080 60fps) の H.264/AVC でSDHCカードに撮影でき、重さが280gしかないという優れものです。
ここではMacといっしょに使うという観点で、二日使った感想を書いてみます。
環境:
MacBook (2GHz Core 2 Duo, 2GB RAM)
Mac OS X 10.5.2
iLife ‘06
単なるMP4ファイル
ひとつの撮影は、単にひとつのMP4ファイルとしてSDHCカードに保存されています。
カードリーダーをMacにつなげば、ふつうのファイルコピーだけど映像の取り込みが完了する、というのは、これまで Firewire でDVカメラから映像を取り込んでいたぼくにとっては革命的な手軽さでした。
テープというシーケンシャルアクセスから、ランダムアクセスできるSDカードにメディアが変わったことのインパクトはすごいものです (他の例: FDD→HDD、VHS→HDDレコーダ、などなど)。
他にもまだ、シーケンシャルアクセスでしか使えないものがあれば、そこにはイノベーションのチャンスがある、ということですね。
QuickTimeでの再生
このMP4ファイルはQuickTime Playerで簡単に再生できることもポイントですね。
ただし、Full HD のMP4ファイルはそのままでは再生することができなくて、avc1Decoder というものをインストールするとOKでした。
Full HD のMP4ファイルの再生はさすがにCPUパワーを酷使しますが、再生時にだいたい25〜29fpsは出ていました。ギリギリ再生が追いついている、というところですね。
iMovie で編集
Full HDのMP4ファイルをそのままiMovieに放り込むと、音は聞こえど画像は出ない、という状態になります。価格.comにある情報 に従い、先頭フレームだけをQuickTimeでカットし (先頭でCmd-XすればOK) 、参照ムービーとして保存したものをiMovieでimportすると、ちゃんと編集できました。
iMovieのプロジェクトは、新規作成するときに HD-1080i-30 の形式を選んでおくと、HDの編集ができます。これに最初気づかずにはまりました。
Webカムとして使う
Xacti DMX-1000は、Webカムとしても使えると説明書にあります。
ただし、Windowsでしか使えないよと書かれており、ほんとかいよとMacにUSBでつないでXactiの設定をしてみると、ふつうにQuickTimeの録画ソースとしてXactiを使うことができました。
まとめ
買う前は、ほんとにMacでもちゃんと使えるのか不安でしたが、ちゃんと使えました!
実売で6万円を切っているし、Full HD なビデオカメラが欲しいMacユーザに、とってもおすすめです。
三洋電機 (2007-09-21)
サンディスク (2007-10-05)
自分の戦歴を晒してみる。
戦歴
2007.4.18 にRating 933 からスタート。乱高下の末、2008.1.15 に ハイスコアである Rating 1073 をマークしてGreen Coderになるも、深夜に参加する度Ratingを落とし、現在 Rating 822 。
現在の目標はBlue Coderになることです。先は遠い… Challenge phase はおいといて、コンスタントに250,500,1000のすべてを解けるようになること。
なんでTopCoderに参加してるかというと、修行ですね。アルゴリズムの勉強、速く正確なコードを書けるようになること、他人のコードを読む力。
プログラミングしたいけどつくるネタをおもいつかないよー、という人がいると聞きます。
そんなときは、TopCoderにログインして、Practice Roomに入り、250点問題を解いてみてはどうでしょうか。わりと取り組みやすいので、自分の背中を押してあげるにはなかなか良いとおもうのです。
おととい公開した IDAvailability にいくつか改善を施しました。
1. IDをURLのどこにでも書けるようにした
チェックするURLの末尾にしかIDを書けなかった (‘http://website/user/ここ ‘) ので、登録できないサイトがいくつかありました。
そこで、#{ID} という値があれば入力されたIDで置換するようにしました (‘http://#{ID} .website/ → ‘http://置換された.website/’)。
mattnさんのコメントによる指摘 を反映させたものです。
2. HTTP 404 以外を返すサイトへの対応
ユーザがいない場合に、HTTP 404 を返すのではなく、3xx などを返してくるサイトがあります。
これまでサイトのHTMLをとってくるのには、サーバサイドのRubyスクリプトでopen-uri をつかっていました。
open-uri はとても手軽でよいのですが、3xx を受け取ると自動的にリダイレクトし、その結果が返ってきます。
これだと、正常にリクエストが行われたように見えてしまい、ユーザがいるかいないかの判定に使えませんでした。
よりローレベルなNet::HTTPをつかうことで、HTTP レスポンスのstatus codeをチェックするようにして問題を回避しました。
3. 横並びに
縦にずらずらっとサイトを並べていたのを横に並べることで、俯瞰性を高めました。
2008.04.24 8AM 現在で、サイト数が28 になりました。
wedataというオープンなデータストアだからこそですね。
ToDo
IDAvailability というWebアプリをつくりました。
入力したIDが、世の中のWebサービスで既にどれくらい使われているかをチェックする、というだけの簡単なものです。
Webサービス
チェックするWebサービスは、ぼくが追加したものだけで8つ。
しかし、Webサービスの情報は wedata にあるので、誰でも対応Webサービスを追加できるようになっています。データベースはこれ 。
Webサービスを追加するには、Create New Item から進んで、以下の項目を埋めればOKです。あとは、Webアプリ側がうまいことデータをひっぱってきます。
名前 : Webサービス名 (なんでもOK)
urlToCheck : http://nantokakanto.ka/user/ #{ID} の ‘http…user/’ の部分
condition : urlToCheckにアクセスして404 Not Foundじゃなかったときに、そのページが「そんなユーザはいませんよ」的メッセージを出していることを確認するためのXPath表現
たいていのWebサービスでは、ユーザが存在しなければ404を返すようになっていますが、たとえばflickrでは別のページを表示するようになっていました。そういう場合は、XPathで検出しています。
コード
Coderepos/websites/idavailability にあります。
ライセンスは修正BSDで。
コードがひどい!とかデザインがかっこよくないよ! とかあれば、遠慮なくコードをいじってcommitしてください。
ToDo
XPathによる判定はクライアントサイドでやる
Ajaxで外部サイトのHTMLをもってくる方法を調べる (不可能?)
HpricotだとXPathの演算子が使えなくて判定しづらいので、別の手段を探す
かっこよくする
うまくいかないWebサービスがある (YouTube, NetVibes…)
なぜこんなものをつくったか
これからインターネットをはじめていく人々が、どこでも使える可能性が高いIDを選べるような助けをつくりたいと思ったのでした。
自分も mootoh というハンドルに行きつくまでなかなかの試行錯誤を繰り返しており、こんなのは手動でやってられないよ、と。
もうちょっと背景を
インターネットの世界では、いいIDをとるのは早い者勝ちです。
でもこれって、これからインターネットをはじめていく人々にとって、とても不利な状況なのではないでしょうか。
短くてすてきなIDなんて、そうそう残っているものではありません。しかたなく生年月日をハンドル名につけたりしているのが現状です。将来的に、ここをなんとかしたい。若いひとはもっと不平を言ってもいいんじゃないかな。
ともあれ、いいIDを求めて探求してみたり、Webサービスを追加してみたりしてみてくださいね。
Makerのはしくれ として、Make Tokyo Meeting に行ってきました。
真空バズーカでキャベツの芯がぶち抜かれるのを間近で見たり、
3次元プラネタリウムに感動したりしていました。プラネタリウムはほんとうにすごかった。
akio0911 さんのHMD+位置情報+コンパスのやつ,インパクトありました。もうそろそろスカウターが市販されてもおかしくありませんね。
takkaw さんにリクエストされていたので、どこでもゆびピアノ++ を持参していました。Gainerのワークショップの横で広げてもおもしろかったかも。しまった。
Makerのみなさんは、とてもしゃべるのが上手ですね。プログラマとちがって、ライブで人に見せることが勝負だから、鍛えられてるんだろうな。
あと、MacBookでやってるひとがたくさんいるのが意外でした。Makerのひとなら、中をいじくりたおせないMacよりもふつうのノートPCつかってばりばりにカスタマイズするものだ、という先入観があったもので。
こども連れのひとがけっこう来ていて、彼らが実際に触って動かして体感できる場だったのがとてもよかった。自分もコンピュータの画面の中だけで動くものばかりつくっていちゃいかんなと。発明おじさんを目指さねば。
第2回は、2008年10月に開催されるそうです。次はMakerとして参加したいですね!
ちょっとしたRTMのtips紹介。
よく言われることですが、重要だけど急じゃない タスクをいかにたくさんやるか、が何かを成し遂げるために重要です。主体的に生きる、というやつですね。上の図では青いところ。
意識していないと、ついつい電話の応対 (赤) やマリオカートDS (緑) だけをやる日ばかりを過ごしてしまいがちです。
去年、CartesianTask というものをつくっていました。
RTM のタスクをドラッグアンドドロップで二次元に配置する、というものでした。
これはこれでおもしろかったのですが、もっと簡単な方法があったのでメモっておきます。
RTMの検索オプション
ここ にRTMの検索オプション一覧があるので、どう組み合わせるか考えてみます。
ぼくのところでは、重要だけど急じゃない は、なんらかのpriorityがついていて、締切がないもの だと考えました。
そこで、(NOT priority:none) AND due:never という検索式でタスクを検索します。
よさそうだったら検索結果をリストとして保存しておきましょう。ぼくのところでは30件ありました。多い。
参考までに他のエリアの検索式も書いておくと、以下のようになります。
赤: priority:1 (そのうち、かならず実行されるタスクのリスト)
黄: dueWithin:”1 week of today” (1週間以内にやらないといけないものを急だと見なした。これもまた、時がきたら実行されるだろう)
緑: priority:none AND due:never やらないほうがいい。週次レビューのときに、ここのリストにあるタスクばっかりがこなされてるのを見たら、ちょっと考えなおすべき。
まとめると、RTMの検索式をうまくつかうことで、自分が抱えてるタスクを見る切り口を変えることができる、ということです。RTMはすばらしいリストサービスですね。
まとまってないけど、眠いので今日はここまで。
あるいは、ほんとうのPermaLinkが欲しい。
Webサービスをつくるのが流行ってますね。
ひとりでつくったものを世界中のひとに使ってもらえる、というのはものすごいことです。
たとえばぼくはここのところ、蔵書をWebでまとめておきたくてWeb本棚サービスをいくつか物色してました。本棚.org とか、Booklog とかありますね。
AmazonのデータとAPIをつかって個人がWebアプリをつくる。みんながつかえる。しあわせ。
ぼくも自宅にサーバをたてていて、自分用ではありますがいくつかWebアプリをつくって使ってます。
どこからでもアクセスできてしあわせ。手ぶらの知的生産、というやつですね。
しかしはたと、これは永遠に続くわけじゃない と気づきました。もったいない!
たとえば、自分がいま死んでしまったとする。
そしたら、これまで自宅サーバで動いていたサービスはメンテされない。
葬儀やら引っ越しやらしてるうちに、サーバは止まることでしょう。
そしたらそこにあったコンテンツはもう存在しない。
たくさんの胸踊るコメントが散りばめられたブログは失われてしまうのです。
レンタルサーバとかにコンテンツを置いてる場合もまた然りで、
契約が切れてしまうとコンテンツはなくなってしまいます。
企業がホスティングしてるブログサービスだから、自分がいなくなっても残ってるよ! と言っても、その企業が煙のごとく夜逃げしてしまったりするとアウトですよね。
いかにGoogleといえ、100年後にいまのまま存在してるとは思えない。
となると、Webサービスに自分がすごく大切にしてることを残す、というのはなかなか難しいものがあるんじゃないでしょうか。
個人としてつくっているWebサービスに対しては、楽しむ/体験する といったことまでしかできないのか、と。
インターネットそのものがベータ版であり、たくさんの実験をして遊ぶ場所だといってしまえばそれはそれで納得なんですけどね。
全人類のライフログ
人類はいま史上はじめて、すべてのひとの人生を後世に残すことができるようになったはずです。インターネットと膨大なストレージのおかげで。
これまでは限られたひとのライフログだけが伝記として存在していたのに対し、いまや万人がブログを書き、あるひとはTwitterで日々のあれこれを世界中につぶやいているのです。
しかし現状はまだまだ過渡期です。
いまのインターネットはみんなが楽しいことを実験するという遊び場以上のものになってない (ビジネス的なことを抜きにすると)。
個人のライフログは永遠に残り得る 時代になってきてます。
ぼくはとうとう90歳にして往生するときになっても大した人物になれていないかもしれない。
それでも、ぼくという人間のいろんな側面を、ひ孫や1,000年後にいる誰かがぐぐって 見ることができればいいなと思う。そして、それは技術的には既に可能なのです。これはすごいことだと思う。
どうするか
永続ストレージをつくるしかない。
方法は2つあるのではないでしょうか。
個人の寿命を越えるには組織をつくるという方法がありますね。
現在、archive.org という試みがありますが、一極集中だと全人類という規模に対してスケールしないはず。
ぼくという情報をどこかに保存しておくんじゃなくて、ネットワークそのものに保存すればいいんじゃないかと考えると、P2Pが選択肢にあがります。でも、誰からも参照されなくなるとネットワークから消えてしまうか。うーん。
現在に局所最適化せず、未来をつくっていくにはどうするか。
100年、300年後にはどんな世界になってるか、というのを考えながら書いてると、えらいまとまりのない長文になってしまいました。ご指摘やコメントいただければとてもありがたいです。
Published on
April 9, 2008 in
book .
どうしてますか?
新書とかビジネス書とか技術書を読んだあと、どういうふうにしてアウトプットまでもっていくか悩んでます。
現状は、未読キューと再読キュー、読了セットというストレージで蔵書管理をしています。ひととおり線を引きながら読み、読み終えたら再読キューにつっこんどく。折をみて再読キューから取り出して、メモをマインドマップにしたりしてノートにとっておき、都度見返す。本は読了セットへ、というフローが理想的でした。
なんだけど、再読がぜんぜん進みません。いまぱっと見て、100冊ほどが再読キューに入ってます。この山を見るたびにげんなりしてしまう。困った。
なぜ再読が進まないかというと、メモを書くというアウトプットをするのを避けてるからではなかろうかと考えました。アウトプットには頭も集中力もインプットの3倍は使います。ラクなインプットに逃げてしまいがちです。
がんばってメモをつくり、日々持ち歩いてみることも稀にあります。ところがその場合にも、あまり頻繁にメモを見返すことがない。すき間時間には考えごとをしているか、また新しい本を読んでるかです。
なぜメモをつくるかというと、繰り返し見返すことによって本の内容を自分のアタマに擦り込ませるためですよね。アウトプットのために。ここを端折ってると、せっかく読んだ知識が自分の血肉にならなくて、とっても無駄です。そんなのはいやだ。
そんなことを考えるために、風呂場にたくさんの本を持ち込んで考えてみました。
自分に向いてる読書方法はなにかな、と。
なんといっても、この再読未消化状態が1,000日以上続いてる現状からして、この方法は自分にとってうまくいきそうにないですね。
再読はしない、それでいて自分にとってのエッセンスが頭に残るようにする ためにはどうすればよいだろうか。
30歳になりました。
25歳から今日までは、あっという間でした。
それまでの5年区切り (20-25, 15-20, …) のときと全然ちがう。大人時間は速く流れる。
ぼんやりしてたらたちまちおじさんです。10年後のぼくは何を考えているんだろうか。
基盤となるものをしっかり固めつつ、たくさんのチャレンジをする30代にしよう。ハッピーバースデーツーミー。
日本語 
English