レコーディング・ダイエットしようかと

みなさんレコーディング・ダイエットって知ってますか?

自分の食べたものを片っ端からメモして、可能ならカロリー計算し、自分がどれくらい食べているかを自覚することでダイエットへのモチベーションを維持させようっていうダイエット法の一種です。

詳しくはこのへん見てみてください。

今話題のレコーディングダイエットを検証！ - ［話題のダイエット情報］All About

おいら初めてレコーディング・ダイエットをTVで見たとき、「あー、この食事記録してカロリー計算するあたりをWebサービスにしたら人気出るかもなー」と思ってたんですが、すでにその機能が実装されているサービスを発見したのでご紹介します。

カラダカラって?

健康のポータルサイト：カラダカラ

ってサイトなんですが、健康のポータルサイトと冠しているだけあって、ダイエットはあくまでオマケで、睡眠時間とか食事とか精神状態とか病気の治り具合を日記に付けて、仲間交流を深めることで、健康に気をつけましょう、というか辛くても負けないでね的なところを狙っているサイトのようです。

ダイエットダイエットと煽ってない分、信用できるというか、コツコツ続けるには良い環境だなぁと思いました。

で、レコーディングダイエットは?

会員登録すると、カラダカラノートというものに記入できるようになっています。

記録できるノートの種類はたくさんあって、その一つが食事の内容なんですが、実際に見てもらった方がわかりやすいかな。

ちょっと文字が潰れちゃってますが、要はAjaxをバリバリに効かしてるテキストエリアがあって、そこに食べたものを書くと、関連するデータを検索して候補をリストアップしてくれます。

たとえば、「味噌ラーメン」と書くと、「一般的な味噌ラーメン」なのか「まるちゃんのインスタントラーメン」なのか「日新のカップラーメン」なのかといった感じ。一人暮らしに考慮しているのか、インスタントモノが多い気がします。(まぁメーカー公表値がある分データを揃えやすいのかも知れませんが)

んで、リストの中から一つ選んだら、カロリーが自動的に算出されるので、食べた分量(これによってカロリーも増減する)や、時間帯を入力していく流れです。

MacでFirefox3を使うとちょっと表示が崩れますが、ぜんぜん許容範囲です。

で、ここからが凄い

食事内容を記入することで、自分がどれだけ食べているかを自覚させ、意識的に食事量を制限するというレコーディングダイエットの目的(というか記録を支援する目的)はこの時点でクリアできます。

更に、単品毎、一日毎のカロリー量も計算できてしまいます。

ただ、これだけで終わりではなかったところが凄いんです。

これを見てください。

カラダカラではユーザプロフィールの一環として、「体を動かす仕事の人」「普通」「動かさない仕事の人」程度の区分で基礎代謝量を設定することが出来ます。

また、カラダカラノートでは、「腕立て伏せ」「ウォーキング」「ジョギング」といった運動量も記録することができ、距離・時間・回数ごとの単位消費カロリー量を設定可能なので、これらの基礎代謝+運動量によってどれくらいのカロリーが消費されているかを計算することが出来ます。

で、食事によって摂取されたカロリーから、消費されたカロリーを引き、差し引きでカロリーがどうなっているのかをグラフ化することができるのです。(これが上の図)

実際にカロリー収支が数字として計算されているので、月末時点で差し引きどうなっているのかも知ることが出来ます。

今月は2万kcalのプラスだから、その分脂肪が付いてるんだろうなぁとか、数字として突きつけられるわけです。

で、ここで終わらない

ここまでカロリー収支が明確になってしまうと、逆の考えもできるようになります。

たとえば、

• 「(上のグラフのように)おおよそ毎日500kcalのプラスなんだから、日々の生活に500kcal消費する運動を取り入れれば、体重は維持できるんだな」とか、
• 「昨日は飲み歩いてカロリー取り過ぎちゃったから、その分運動しないと…って、取り戻すためには200分もマラソンしなきゃならないの?　マジで。やべー呑み会自重しなきゃ」とか、
• 「やばいよ、○○までにあと5kg痩せなきゃならないじゃん。それって一日当たり1000kcal減らすって事でしょ?　こんなの食事だけでは減らせないよね。食事で500kcal減らすとして、残り500kcalを消費する運動はと…」

みたいに、具体的な数字で考えられるんです。

これは効きますよ。雨が降ってもウォーキングは休めませんよ。

なんせ、今までの「何となく、まいっかーで済ませて結局痩せなかった自分」のように漠然としたモノではなく、「○○に××できなかったが為に痩せなかった自分」をリアルに突きつけられるわけで。

まとめ

カラダカラを知ったきっかけは、このレコーディングダイエットのカロリー計算のアイデア(食べ物の名前を解析して候補を示しカロリーを計算する)を前から思いついていたからなんですが、作るの大変そうだなぁ(データ集めるのがね)と思ってたし、良いのがあるなら使おうというスタンスでした。

なので、カラダカラを知ってどんなもんか使ってみて、自分のイメージの上を行くサービスだとわかったとき、結構感動しました。

何が凄いって、仕組み的に完結してるんですよね。ポータルという名に負けてない。

上記カロリー収支の話もそうだし、一緒に運動するための仲間作りや、実際に体の調子がおかしいときの医学事典や自己診断までできちゃう。

よくある「ポータルを目指してるけど上手く回せず力尽きてダメになるパターン」ではなく、うまく回ってる実例を見てる気がして、サービスの企画にもかかわっている身としてスゲーと純粋に思ってます。

…このサービス、人気あるのかな?　おいら的にはど真ん中ヒットなんだけど、(おそらく)長くやっている割には名前が知られていない感じがして、もったいないなぁと思いました。

gemspec.infoのフィーチャモデル

gemspec.infoのコンセプト からの続きで、今回はフィーチャモデリングしました。

と言っても、かなり我流ですが。

モデリング結果

まずは設計成果から。

例によってWikiに上げました。

Ruby on Rails プラグイン まとめ wikiのGemSpec.infoのフィーチャ がそのページです。

一応FreeMindからTWikiエクスポートかけたテキストとして書いてありますが、正直見にくいと思うので、添付してあるFreeMind用のファイルを開いてもらうのが一番良いかと思います。

全体的な流れ

ええと、前にも書いたかも知れませんが、これらの設計成果物は「設計結果の清書」としてではなく、「考えるために書く」(書きながら設計する)ために作っているものです。よって、これで完成という意味合いではなく、極端に言えばアプリケーションが完成するときにやっと設計成果物も完成するものと捉えています。(まぁ、リリース間近になっても設計資料をメンテしているかは疑問ですが)

実際、おいらの作業はほぼERが完成してモックの細部を詰めているところですが、この段階になっても作りながら新たなアイデアが浮かんで、一部フィーチャモデルにフィードバックが入ることもあります。なので、今アップロードしたものも現在の最新版であって、まだ変更される可能性もあります。

アジャイルやRailsのお作法的には、全体的な方向性を整えるために、全体を通しての設計はすべきだと思いますが、Ruby on Rails によるシステム開発をモデリングで効率的に行う であかさたさんもおっしゃっているとおり、ある程度でレールに乗っちゃった方が効率的だと思います。

なので、ここでは細部まで突っ込んで考えるより、ある程度まとまったらコーディングに移り、問題が浮上したら都度微調整ぐらいに考えています。

コンセプトからフィーチャを起こす

ここからは我流前提で行きます。

例によって内容はWikiを見てもらうとして、ここでは何に注意して作業したかだけ説明します。

まずは、「ログイン」とか「記事投稿」などの主要機能について、「意味合い」「必要機能」「問題点」に分けて書いていきました。

意味合い

• 何故この機能が必要なのかを明確にする
• コンセプトと被るものが多いけど、コンセプトよりもっと具体的に書く
• 「何故」こうしたかを明確にした方がシンプルになって、方向修正もしやすい
• たとえば機能同士の整合性やユーザインタフェースが不自然になりそうだったら、一度「なんでこの機能が必要なんだっけ?」と気軽に戻れる場所を作っておくのは気分的に楽

必要機能

• 機能や画面として必要なものを列記する
• 意味合いと合わせて、何故「こうした」かを明確に対として書く
• gemやプラグインを使う場合はそれを書いておく
• でも、どんな時にgemやプラグインを使えばいいかわからないと思うので、前もってgemやプラグインが提供してくれる機能やマイグレーションの内容は知っておく必要がある
• Ruby on Rails プラグイン まとめ wikiとかgemspec.info使え(再帰的に)

問題点

• 意味合いとか必要機能を勢いに任せて書き進んだときにふと思いついた「そういえば、こういう場合にこの機能ってちゃんと機能するのかな?」みたいな疑問をメモしておく
• おおよそ書きたいことを書き終わった後、問題点を潰しに入る
• もう周りの状況は見えているはずなので、意味合いに立ち返りながら、機能を諦めるのか、機能を活かして問題点をうまく避ける工夫をするのかを考える
• 機能を諦めることで問題点を解決するなら、マインドマップから両方消す
• 機能を活かして問題点を上手く避けるなら、具体的にどうするのかを詳しく書く

意味合い→必要機能→問題点→次の項目の意味合いと、がーっと書き進んだ後、書く速度も落ちてきて、もう大体いいかなーと思ったら、もう一度全体の整合性を見直しながらgemやプラグインを使えそうな部分を探し、最後に問題点を潰していく感じでしょうか。

実際にはgemやプラグインの検討を始めたあたりで、モックやER図も描き始めています。おいらの場合、そうしないと全体の流れがうまくイメージできないので。(特にユーザインタフェース上の問題や、データ構造上実現可能/不可能なことがイメージできない)

そうそう

Railsのちゃんとした設計はおろか、業務レベルの実装もしたことはない(業務では管理はしてた。個人レベルで実装はしてた)ので、このへんかなりぐたぐた感ありますが、ご容赦ください。

逆に、効率的な設計手法には興味があるので、突っ込みとかアイデアあればガシガシどぞー。

今後の予定

札幌Ruby会議01でライトニングトークの選考に残ったので、参加予定の方はよろしくです。

もうちょっとで設計が終わるので、来週からはコーディングできるかな。10月上旬には完成したいなぁ。

ただ、今月の北海道は勉強会ラッシュなので、プライベートの時間があまり取れないのです。

勢いで徹夜するのが結局効率的なのかな。

be動詞の疑問形を作れなかった男が感じたiKnowとマイリストのおいしい関係

iKnowやってて、こうすれば効率的に覚えることが出来るかも、と思ったことがあったのでまとめるよ。

マイリスト使ってる?

iKnowをやっていて、初めて出題される単語じゃないけど、毎回忘れてしまうような単語は、1〜2ステップ毎ぐらいにマイリストを作ってまとめておき、定期的に確認すると定着しやすいように思う。

特に定着度75%ぐらいになったときには、簡単にわかる単語と忘れちゃう単語がハッキリするから、iKnowを始める前にさらっとマイリストを見るのがいいかも。(iKnowでおさらいという位置づけにする)

マイリストには

• スペル
• 単語の発音(音声)
• 日本語訳
• 品詞

が表状にまとめられているので、さらっと確認するのにちょうど良い感じ。

たとえば、おいらの場合、動詞とか名詞はイメージしやすい分すぐ覚えれるんだけど、副詞とか形容詞は基礎英語ステップ1とか2のレベルでなかなか覚えられないものが出てきた。(学生の時にも覚えられなかった気がする)

ステップ2つ分(単語数200)で、マイリストに入った単語は10個ぐらい。だいたいステップ1つを終わらせるのに毎日やっても2週間ぐらいかかると思うから、最短だと1ヶ月で2ステップ消化できて、1つのマイリストづつ増えていくことになると思う。

iKnowアプリケーション内からマイリストに単語を追加できるともっと楽なんだけどね。現状、iKnowやってて「あ、この単語覚えてないや」と思ったときに、別ウインドウでマイリストを追加しながらやってる。

マイリストは将来の自分の時間節約のために作る

マイリストって、他人と共有したり、iKnowアプリに読み込ませて使うイメージが強かったけど、こんな風に苦手な単語を集めて、自分だけが使う方が気楽に使えて良い気がする。一度学習済みの単語だから、表状で見えればささっと確認できるしね。

苦手な単語って、iKnowアプリ上は完了した扱いになっても、いざ実際の英文に出てきたとき「あれ?　こういう意味だっけ?」とうろ覚えになっていることに気づく事が多いので、後でまとめて見直せるように準備しておくと、後々幸せになれる気がしてきた。

アジアの一生懸命

嫁に教えてもらったので、みなさんにもお伝えします。

とりあえず50記事程度目を通していただければ、言いたいことは伝わるはずです。

家族団らんにご活用ください。

アジアの一生懸命

※飲食中は周りの人に迷惑をかけますのでご遠慮ください

be動詞の疑問形を作れなかった男がiKnowのdictationってアプリの使い方を考えてみた

イマイチ派手さというか、エンターテイメント性に乏しく、メニューにあるからたまにはやってるけど、何のためにやってるのかイマイチわからん感があるdictationだけど、これこそが英会話には必要な気がしてきたので、効率的に学習する方法を考えてみた。

dictationの学習の流れ

まず、dictationは基本的にこんな流れで出題される。

• 同じ英語の例文について、穴埋めの範囲が違う問題が2回出題される。
  1. 半数の単語が穴埋めになっている英文が表示され、同時にその音声がながれるので、穴埋め部分を聞き取って正しいスペルを入力→正解の英文と日本語訳が表示される
  2. 全文が穴埋めになっている問題が再度出題されるので、聞き取って全文のスペルを入力→正解の英文と日本語訳が表示される
• で、全文穴埋めに正解するとその例文はクリアしたことになる。
• 最初の穴から順に単語を入力していくんだけど、間違っているとすぐに指摘されるので、正解されるまでその単語を再度入力することになる。
• ただし、一部聞き取れなくても、ヒント機能を使うと、今入力中の単語の正解を約2秒間だけ見せてくれる。全文ではなく、あくまで今カーソルがある単語のみ。
• で、間違いまたはヒント回数が3回(もしくは4回)に達すると、聞き取れなかったと見なされて次の質問に移り、後でもう一度出題される。

dictationの効率的な学習方法

まぁ、特殊な学習方法ってことじゃなくて、こんなところを押さえながら解くと学習効果が高いんじゃないかなぁと思った点をまとめてみる。

• まずシャドーイングまたはリピーティングして、単語を聞き取る(口に出すと正確に聞き取れているかどうか解る)
• いくつかの単語を聞き取れたら、元々表示してあった単語もしくは写真と合わせて意味を推測する(コレ重要)
• 聞き取れた単語を入力してみる
• 推測してみた単語を入力してみる。この時文字数などが合わなかったらさっさとヒントを使う
  
• 穴埋めが完成したら、日本語訳を見ながら推測が正しかったか確認する

たぶん、この方法を繰り返していくと、道でいきなり外国人に話しかけられても意味がわかるようになるんだと思う。

実際、英語が話せない人って、こっちから何か話しかけても、その返答が聞き取れないから会話が出来ないんだと思う。「I want to なになに」とか、一方的に話すだけなら(相手が理解しようとしてくれるなら)まぁまぁ実用になる程度話せるもんだ。

で、なんで聞き取れないかっていうと、いつもは文字を読んで、主語とか動詞とか副詞の位置関係を何度も目で追いながら意味を考えるんだけど、聞き取りだと、この目で追うっていう動作が出来なくて、単語同士の繋がりを頭の中で解けないからだと思う。

で、dictationの場合は、この「聞いて」「意味を考えて」「穴埋め&日本語訳で復習」という流れがうまく回るので、だんだん聞くだけで意味がわかってくるんだと思う。(残念ながらおいらはまだそこまで辿り着いていないが…)

dictationは1回につき10分以上かかると思うけど、何度も繰り返さない分だけ進行が早いので、1日1回って感じで良い気もする。

iKnowアプリ側がステップ3を進行中ならば、dictationはステップ2をやるのが良いかも。同じステップ3をやってると、知らない単語(iKnowアプリ側でまだ出題されてない単語)が出てきて、学習効率が落ちる気がするので。

同じ理由で、ステップ10をやってる時より、ステップ1をやってる時の方が知らない単語が混じる可能性が高いんだけど、これはしょうがないとして進めるしかない気がする。さすがにステップが低いうちは、学習済み単語が少ないので、例文にならないだろうし。(こういう事情もあって、最初おいら的にdictationはウケが悪かった)

dictationでは、回答欄に何文字入れるのかといったインジケーターが表示されるので、簡単に聞き取れるようになったら何文字はいるかも無視して(見ないようにして)解くと、難易度が上がって良いのかも知れない。

iKnow!で提供されているアプリの位置付け

おさらい的に、各アプリの位置付けと学習効果をまとめてみた。

紛らわしいけど、「iKnow!」と表記するものはサービス全体を指して、実際にFlashアプリとして動く方は「iKnowアプリ」(もしくはiKnowとだけ)と表記してるよ。

iKnow

• 単語やコロケーション(特定の単語のセットで特別な意味になるもの)を覚えるためのアプリ
• 単語の意味、スペル、発音など、単語辞書にのっているような内容を扱う
• レベル毎にまとめられた単語辞書を暗記していくのと同じような学習効果。平たく言うとボキャビリティー向上
• 定着率という概念があり、単語を覚えるまで最適なパターン・スケジュールで学習可能
• 携帯版もあるので、場所を問わずちょっとした時間に学習可能
• iKnowアプリでの効率的な学習方法は、このブログで既にとりあげています

dictation

• ヒアリング能力向上や、スペルを覚えるためのアプリ
• 再生される英文を聞き取って、そのままの英文を入力するだけの問題を繰り返す。
• ニンテンドーDSのえいご漬けみたいな感じ?(や、おいら持ってないからよく知らないんだけど)
• 耳で聞いて、それを入力することで、聞き取った内容が正しかったかどうかが判断できるため、ヒアラング能力が向上する
• 聞き取れなかった単語も、全体の意味を考えて聞き取れなかった単語を推測する推測聞きをすることになるので、英語の文脈についての感覚を養うことが出来る(ここには助動詞しか入らないはずだとか、この単語は名詞じゃなくて動詞だとすれば、ここにはこれが入るはずだとか)
• 耳で聞いて意味を理解できるようになるので、英会話するには重要な気がする(英文を目で見て意味を理解できても、なかなか耳で聞くだけじゃあ理解できないよね)
• 効率的な学習方法は今回取り上げました

BrainSpeed

• iKnowアプリなどで既に学んだ単語を、ゲーム感覚で復習するためのアプリ
• 1秒に1問ぐらいのペースで、瞬間的に簡単な2択の問題を次々に解いていくことで、単語を見た瞬間に意味を思い出せるようにトレーニングする
• ヒアリングにしても、スピーキングにしても、単語の意味は瞬間的に浮かんでこないとうまく話せないので、一度覚えた単語の復習として使うと良いかも
• 単純にゲームとしてたまにするぐらいでいい気もする

iKnowアプリを基本としつつ、ヒアリング方面をdictationで補完して、ゲーム感覚での復習にBrainSpeedを使うって感じかな。

gemspec.infoのコンセプト

RubyOnRailsの設計手法もレールに乗せよう からの流れで、これから作る予定のGem情報集約サイト(gemspec.info)について、設計資料からソースコードまでこのブログで晒してみますね。

自分としてもRubyOnRailsの設計手法もレールに乗せよう で煽っておいて、実際にステップを意識して設計をしたことはあまりないので、Ruby on Railsでこの設計手法を採用することは現実的か、問題点はないか、効率的か、といった点も確認してみたいので。

もちろんgemspec.infoのプロモーション活動も兼ねて。

まず始めに

設計とは本質的にケースバイケースだと思います。

ただRailsぐらい作り方が決まっているモノの設計は、ある程度パターンがあるだろうと。

なので、RubyOnRailsの設計手法もレールに乗せよう の流れを基本としつつ、足りないところは付け足して、無駄と思えるところは省けばいいという方針で進めます。

ただ、足したり省いたところには理由は説明しますね。

で、初っぱなから足したモノがあります。

ユースケースとコンセプトの関係

RubyOnRailsの設計手法もレールに乗せよう では「ユースケースがそのアプリケーションの存在意義となる」とか言った記憶がありますが、そもそもコレってユースケースの範疇じゃないよなぁと思い直しました。

ビジネスモデルというか、物事の本質というか、まず実現したいことがあって、それをモデリングすることで具現化したものがユースケースだろうと。このエントリではこの実現したいことを(なんと表現すべきか解らないので)コンセプトとしますが、今までに無いものを作るならば、コンセプトこそが存在意義だろうと思ったのです。(逆に既に存在するモノに対して使い勝手で差別化するならユースケースが大事)

あともう一つ、受託開発など設計者がユーザでは無い場合に、設計者がビジネスロジックを理解し、発注者(や開発チーム)と理解した内容をすり合わせしやすいようにユースケースを作るって意味もあるのかなと。でも、今回はおいらユーザでありGem作者だし、おいら自身が欲しいと思ったシステムを作るので、わざわざユースケースを作る必要はないかなと思ったのです。

なので、今回はコンセプトだけまとめ、ユースケースは省くことにしました。　

gemspec.infoのコンセプト

そもそも設計のような変化していくモノをブログにまとめるのはどうかと思ったので、内容自体はWikiにまとめることにしました。(文書化できる部分だけでも)

これだけのためにWikiを立てるのもなんなので、Ruby on Rails プラグイン まとめ wiki にgemspec.info特設ページを作りました。

コンセプトに関するモノはgemspec.infoのコンセプトです。(@wikiはURLがイケてない…)

こんな感じ。

コンセプトのアイデア出しとまとめはFreeMindというマインドマップ描画ツールを使っているのですが、さすがにそのまま貼るには適さないので、テキストに書き出しています。Twiki用のエクスポート機能を使ったのでちょっと不自然ですが、FreeMindのデータファイルをアップロードしておいたので、自然な形で読みたい人はそちらをどうぞ。

Wikiと同じ事を解説してもつまらないので、ここでは触れませんが、要は立場によって違うニーズをまとめ、情報をうまく集約できる仕組みを考え、それを効率的に検索できる方法を考える。って感じかなぁ。

コンセプトのまとめ方

まぁ、人それぞれだと思うけど、まいむぞうの場合って感じでまとめておきます。

コンセプトの骨格部分は思いつきでまとめていますが、この初期段階で問題点を洗って、その解決方法(というか補完するアイデア)をフィーチャなどと合わせて時間をかけて煮詰めと肉付けをくりかえしている感じです。

具体的には犬の散歩しながらとか、風呂とかトイレや寝る前にあ、これいいかもとアイデアが浮かぶことが多いですね。浮かんだアイデアはすぐ書き出さないと絶対忘れるので、その場でエディタに書くか携帯メールに溜めました。

この後のフィーチャモデルと違って、調べることは少ないと思うので、(別のアプリやサイトや本などに触れて)いろんな視点からコンセプトを考えると、色々浮かんでくる気がします。ただ、おいらの場合はあまり時間をかけすぎると飽きてくるので、適当なところで切り上げます。

おいらはいつも考えるときにマインドマップを使っていますが、アイデアのようにポツポツと浮かんでくるモノを体系立てて考える時ってマインドマップはいいですよ。おいら漢字や絵を書けない子なので、PC上で書いていって、後で再構成できるFreeMindはかなり気に入ってます。(他にもマインドマップ描画ツールはありますが、自分の知ってる中では一番イイです。特にver0.90イイ)

テンション上げ上げで

忙しさを理由に進まないのは自分的にもマイナスなので、札幌Ruby会議01までには完成して「でけましたー」と叫びたいところ。

自分を追い詰めるためにライトニングトークの申し込みもしておいたので、作業もはかどると思うよ。

コンセプト見て「はにゃ?」とか「ここってこうだと思うでー」ってところがあったら、ブログでもwikiでもいいのでコメントください。

WebコンFESTA2008に参加してきました

WebコンFESTA2008に参加してきたのでレポートしますよー

基本デザイナ向けセッションなんだけど、プログラマにとって重要(とまいむぞうが判断した)なものをピックアップしますよー

Adobeクリエイティブツール最前線! ～アメリカ直送の最新動向ご紹介～

プログラマ寄りのトピック(まいむぞうの判断による)

• FlashPlayer10RCが夏リリース予定(正式版は2009中にリリース予定)
• Open Screen Project　携帯用FlashPlayerが無料化される。これによって普及が進み、同じバージョンで横に揃うかも、とのこと。(Adobe的には無料化してでも欲しいところなんだろうね)
• SWF search optimization for Google & Yahoo　Flashを使ったコンテンツの場合でも効率的にインデックスされるように、GoogleやYahooと協業し、Flashの内部構造を示しているみたい

Flash Player 10

• リアルタイム静止画・動画フィルタが使えるようになる。フィルタはプラグインとして動き、Labから公開される。Adobe Pixel Benderを使ってプラグインを自作することも可能。
• 標準で3D空間系の関数がサポートされる。デモで見た感じではパフォーマンスも良好。(でもちゃんとオブジェクト作って動かした訳じゃないし、他のサードパーティライブラリとの比較は不明)
• テキストエンジンの強化。縦書き対応。テキスト流し込みできちんと(横書きと同じように)レイアウトされる。
• 動画レンダリングエンジンの強化。可変長ビットレートやオープンソースのSpeexコーデックに対応。

DreamWeaver CS4についても話がありましたが、次のセッションにまとめます。

超スピードで進行したので、捉え間違っていたらごめんよう。

質疑応答

Q:KulerやPhotoshop ExplessやShereのインターフェイスは顧客からの評判がよいが、これは何で作られている?

→A:Flexで作られている。

Q:これらのソースは一部でも公開されている?

→A:現状では公開されていない。

公開してくれるとうれしいなーと伝えておきました。

あと、懇親会でMac用のPlayerが未だにBuggyだよーって突っ込み入れておきました。

Webサイト制作の「今」とともに進化するDreamweaver CS4

DreamWeaver CS4

• リアルタイムHTMLレンダリングエンジンにSafariと同じWebKitを採用。(うん。これ良いね)
• Webを使ったライブビュー機能では、オンマウスでのCSS切り替えや画像差し替えなどがリアルタイムに確認可能。JavaScriptなどによって書き換わったDOM要素をFireBugのように確認可能。(オンマウス時に画像を切り替えたならimgタグのsrc属性がリアルタイムで書き換わるなど)
• 特定エレメント(たとえば<h2>タイトル文字</h2>とか)に影響しているCSSの一覧を、コードヒントのような形で表示可能。ただし、FireBugのように最終的になにが有効になっているのか(継承とオーバライト)を考慮したものではなさそう
• jQueryやPrototype.jsなどの外部JavaScriptライブラリも検知し、エディタ内でコードヒンティング可能
• subversion(やっと)サポート。ただしignoreなどの属性系機能はサポートされてないみたい。(デモ画面から)

このドリはちょっと便利そうな気はした。でも、テンプレートいじるならドリ使うけど、JavaScriptとかなら他の環境(aptenaとか)使うかもなぁ。

質疑応答

Q:HTMLレンダリングエンジンはWebKitを使っているとのことだが、JavaScriptの実行エンジンは?

→A:JavaScriptの実行エンジンもWebKitと同じ。ただしDreamWeaverチームの方でWebKitをチューニングしているので、Safariとまったく同じ表示ではない。

Q:特定のタグにかかっているCSSをコードヒントを使って表示する機能は、FireBugのように複数のクラスのどの要素が実際に使われているか(継承される過程でどのプロパティがオーバライトされているか)は判断してくれるのか?

→A:コードヒントでは、適用されているクラスなどを列挙するだけ。継承とオーバライトについては実は前のバージョンで実装されていたみたい。CSSのパネル(デフォルトだと右上)内にてFireBugと同じように表示できる。また、優先ポイント付け(クラスだと何点でIDだと何点みたいな)ものもオンマウスで簡単に確認できる。

他何個か質問があったけど忘れちったぃ。

文字コード判定や、erbやsmartyなど、一部サーバサイドスクリプトが組み込まれているHTMLテンプレートをきちんと表示できて、壊さないようにしてくれるような機能が欲しいよね。(時間が無くて言えなかったけど)

懇親会では、(erbとかsmartyとかdjangoなどの)テンプレートファイルをいじりやすくしておいて、サーバにアップする機能と、ドリ内部でIEコンポーネントを起動(コード/デザインの切り替え機能に、ブラウザ経由で表示するモードを追加する)して、サーバからの出力をブラウザを通してスムーズに動作確認できるとプログラマに受けるかも、って話が出てました。

Fireworks as phoenix（おめでとう、Fireworks 10周年！）

ごめん。おいら興味ないので、興味ある人はAdobeのサイトで調べて。(おいらグラフィックツールを使うことはないので)

でもプレゼンターの鷹野さんはすごくプレゼンがとても上手でした。慣れてる感じ。

Fireworksは、フォトショ・イラレなどの画像ツールと、ドリやFlashやFlexなどの開発ツールの間に位置し、マテリアルの加工や配置・プロトタイピング・ボタンなどのちょっとしたマテリアルを作る、みたいな場面で使われていくのではないか、とのこと。(でもビミョー)

質疑応答

Q:HTMLコーディング専門会社から見ると、Fireworksを使いこなせば業務がすごく楽になりそうなので、Fireworksをぜひとも普及させましょう!!

→A:承知しました!!

Adobe AIRで作るRIAのご紹介

AIRの概念とかデモを見せてもらいましたが、あまり目立った情報はありませんでした。(自分の知識ベースでは)

セッション内で紹介されたAIRアプリは、後で資料もらえると嬉しいかも。

AIRの使いどころ(説明を聞いていてまいむぞうが思ったもの)

• 背景を透明に出来るので、3Dヒューマンインターフェイスを提供できる基盤技術としては有効かも(ただし3Dプログラミングに精通しないと作るのは難しいよねー)
• SQLiteを使ったクライアントキャッシュを効かせたアプリ(サジェスト系?　もしくは、確定できずとも予約受付だけでも意味があるような予約システムとか。ネットワークレスで動くので)
• ウィジット
• ブラウザの独自拡張(HTMLをきちんと再現できるところまではコンポーネント化されているので、作りたい独自機能だけのプログラミングで済む。まぁVisualStudioでもあるけどね。レンダリングエンジンの好みの問題)

Adobeとしては、音声や動画を簡単に使うためのサーバサイドミドルウェアがあるので、こっち方面では結構良いんじゃないの?的なスタンスの模様。(懇親会では「あの値段じゃあやっぱり使いづらいなぁ。オープンソース版出ないの?」的な突っ込み入れておきました。まぁRed5とかもあるので、いいっちゃあいいんですが)

あとは3D系エンジンが色々出てるので、VIsualStudioより(サーバパーティ製ライブラリを使わないならば)結構良い物が作れる気がする。特に3Dでマルチタッチインターフェイス(対応できるか知らんけど)とか絡めると、結構面白そう。

時間が無くてあまり質問できなかったのが残念。

(もしAdobeさんがこのエントリを見たなら、「ぶっちゃけ、AIRってどうよ?」というエントリに返信くれると嬉しいです)

ワークショップ

AIRで作ったら面白そうなアプリについて3人一組でグループ使って考えました。

発表されたアイデア

• サッカー選手のデータベース
• ドラマなどで出てきた服やインテリアを自分のアバターに着せることが出来るAIRアプリ
• AIRでの勤怠管理
• ヤフオク専用AIRアプリ。終了時間通知機能や商品管理機能がついてる

簡単にブラウザ拡張ができそうなので(しかもこの方法ならレンダリングエンジンを限定できるので)、特定用途向け専用ブラウザというアイデアは結構良い気がします。

HTMLの中にどの程度アクセスできるのか(HTTPリクエストをフックできればOK)理解していないので、ダメな理由はありそうですが…

Hokkaido Fresh Flash

Flashでのプログラミングについて

• ASライブラリは便利。使うべき

おすすめライブラリ

AS2なら

• Tweener(AS2ではあまり使われてないかも)
• FuseKit(有名)
• CASA Framework(有名)

ただし、AS3だとTweenerの利用頻度が高いので、これから使うならTweenerがオススメ

AS3なら

• アニメーション　→　Tweener / Go
• 3D　→　Papervision3D / Away3D / FlVe3D
• 物理演算　→　Box2DFlashAS4 / APE
• マップ　→　GoogleMAP API for Flash(基本Flexだけど非公式版ならcs3でも使える)
• タスクシステム　→　Thread
• フレームワーク　→　Progression Framework
• スライド　→　Slides(プレゼンに便利かも)

Spark projectのページは熟読すると良いよ

実際にセッション内に携帯用抽選アプリを用意しており、賞品付きで抽選アプリケーション(スクリーンにリアルタイムで募集状況がアニメーションしており、当選者は携帯を持って賞品と引き替える)を実演していたので、感覚的におーって感じでした。

次世代型広告コミュニケーション

個人的に一番期待していたセッションです。

いんてぐれーて(rは内容変更のため聞けませんでした。

• 流行は必ずWebが絡んでくる。発端もしくは結果として。
• 広告業界の視点で見たWebマーケティングはWebCampaign って本が事例とかに詳しい
  
• 広告業界では「広告は消費者へのラブレター」と昔から言われている
• このセッションでは、このラブレターの作り方から、渡した後でのフォローまでをまとめて、コミュニケーションデザインと定義している
• 購買行動はAIDMAからAISASへ変化してきている(詳しくはこのへん参照)
• 広告は消費者とブランドのbuddy化
• Encounter(出会い)→Interactive(遊び)→Repeat(もう一度)という流れでコミュニケーションデザインするような流れが生まれてきた
• 新しい広告の形。デジタルサイネージ(ネットから広告を随時更新する大形カンバン)
• デジタルサイネージ+顔認証。デジタルサイネージにカメラが付いていて、顔認証にて通行人の性別を判断し、内容を変更するような事例あり
• デジタルサイネージ+携帯。携帯の画面上にコントロール用のインターフェイスがあって、カンバン上の水槽が動く。魚釣りゲームで、釣れると携帯が震える。(サイトの右上のサムネイルをクリックすると、イケスのようにデジタルサイネージが置いてあり、実際に釣っているイメージ画像があるので、それ参照。これオモロー!!)
• Interactive Everywhere!
• googleのエンジニアもyahooのエンジニアも、PC上のインターネットユーザ数は頭打ちで、次の爆発はモバイル周辺で起きると思っており、今からこれに備えて色々動いている模様。
• androidについてgoogleに聞いても根っこ押さえればおれら儲かるからいいんだみたいなノリで進んでるんだって

"Webキャンペーンのしかけ方。 広告のプロたちがつくる“つぎのネット広告”" (渡辺 英輝, 阿部 晶人, 螺澤 裕次郎, 伊藤 直樹)

Planning Method(プランニングする上での留意点)

• Insight
• Cultural Trend / Fuel
• Hurdle
• Emotion
• Childhood memories

上記文字だけだったので、話を踏まえて自分なりに整理(で、おいらは横文字苦手)

• 深層心理を理解する
• 傾向や動機を理解する
  
• 上記を見据えての問題点を把握する
  
• 感情に訴える
  
• 幼い頃の記憶とダブらせる

心に残った話

• 子供の頃の思い出を引っ張り出して、再体験するのがいいんじゃない?
• マトリックスみたいなカメラを360度並べてアニメーションを作るのは、実はデジカメにデータをWiFiで飛ばすスマートメディアのようなもの+シャッターだけ切るように作れば、後は人力の根性でなんとかなるかも。
• Web広告予算は20%ぐらい?(総予算の20%?ちょっとわかんない)
• ナイキの社風が「尖っているものを大切に」的な感じなので、ナイキのようなチャレンジングを全ての企業に提案できるわけではない。
• 飛び抜けた企画を持って行っても、クライアント企業(広告主企業)の協力がなければ実現できない。自分の企画は50%ぐらい?　あとはクライアントの社風やクライアント側担当者の熱意が必要。

でも、自己紹介とか自分のプロダクトの事例紹介永杉。上記内容は40分中後半10分で語られた。(途中まで「がっかりだった」的な記事を書きかけていて、後半オモローだったので書き直した。全体としては満足してます)

でも、インサイトをこういう風に見つけて、こういう理由でこういいキャンペーンを張って、このぐらいのスケジュールのこのぐらいの予算で動いたら、このぐらい効果があったよー、みたいな具体的な話が聞きたかったなぁ。紹介された本 にのってんのかな?

全体的に

特徴的だったのは、プレゼンターのほとんどがMacでKeyNoteを使っていた点です。やっぱりインパクトあるからかな。

結構人来てたねー。100人ぐらい集まったみたい。懇親会50人、二次会25人、三次会12人?(これ法則?)

CSS Nite仕切ってる鷹野さんはとってもオモローな人でした。プレゼン上手すぎ。早速モンタメソッド使ってましたね。

Adobeのねーちゃんは結構オモローな人だった。いじられキャラ。

基本大満足。

北海道でFlexユーザグループ?

あ、そうそう。北海道でFlex/AIR関係のコミュニティ作ったら参加したい人なんて居ますか?

人数集まるならコミュニティ作れってお達しが出てるんですが。adobeさん後援かも。(てか、実現すると↓みたいにユーザフィードバックを集めて送れるってのが大きいかも)

興味ある人居たらmaimuzo@gmail.comまでどぞー

Adobeのねーちゃんへ

文句たれたれリスト復習編

• Mockupsのオンライン版。シングルバイトは入力できるけど、カナは入力できない。ただし、コピペはできる。
• おいらが常用しているAIRアプリはこのデスクトップ版。Balsamiq Mockupsを使ってみた 参照。こっちは普通にマルチバイト通る。
• MacのFlashPlayerがBuggyという証言その1。これが悲しいんだ、たぶんmacだけ - mes que un club
• UstreamのIRCチャットボックスにも入力できなかった覚えが。(これはFlashだったかどうか微妙だけど。ちなみにMacOSX10.5+FireFox使ってます)
• Mockupsはイイけど、でもこれがAIRである必然性はない気がする。これもおいら何回もバグレポート送ったよ。やっぱりこのクラスだと作りにくいんだと思う。(まだまだbuggyだし)
• 上記と同じ人。同意。AIRって何に使うの？って話 - mes que un club
• AIRに関する考察。AIRってどうよ? 参照
• SQLiteは非同期で使うと非常に使いづらい。同期で使うようにはできないのかな? (サポートしてないのかも知れないけど)トランザクションとかどうやって使うの?　それともトランザクションを使うようなクリティカルなモノは対象外ってこと?
• Flexをベタで書くスタイル(旧来通りのHTMLにonclick="hoge();"とかしといてJavaScriptの関数を呼ぶのに相当)では、ある程度の規模になると保守しづらい。AS3/Flex2 を使い始めて約半年 - 8時40分が超えられない - subtechあたりに深く同意。
• でもケアンゴームは大げさに感じる。要は中規模で使えるFlexベタとケアンゴームの中間がないように感じる。Flexのフレームワークまとめ あたりではさらっと調べたんだけど、ピンと来るモノは無かった。adobeさん的にどれか一つを推せば、力が集中される気もする。(これは善し悪しか)
• Flexでの利用を前提としたASのコードジェネレータ欲しいなぁ。Railsのscaffoldみたいな感じのやつ。RailsとかならXMLはちょー簡単に返せるし、定型なのでscaffold作りやすいと思うんだけど。AMI(だっけ?)も簡単に使えるし。
• いちプログラマの視点で見るとAIRってウィジット以上複雑なシステム(クリティカルなモノとか)には使いづらいと理解している(だったらVisualStudioで作ればいいじゃんと思っちゃう。銀色なものもあるし)
• 他のアイデアはAIRってどうよ?のまとめとか、このエントリのAIRセッションあたり参照。でもイマイチ「コレ!!」ってのは思いつかない。
• で、これについてAdobeさんのスタンスは、こんなん(AIR)作ったからどこで使うかはユーザサイドで考えてねみたいに感じた
• これって堂々巡りで、結局使い分けとして考えていくと、ウィジット系以外に使い道がないとして止まってしまう気がする。ほらこの用途で使えば他と比較してこんなに便利だよー的なエリアって想定できないのかな?　このへんはやっぱりMSは理詰めで上手いなぁと思う。(ちなみにおいらMSは嫌い。だけど現状業務アプリならMSを推す)
•