2008年9月27日土曜日

gemspec.infoのER図

gemspec.infoのモック からの続きで、今回はER図を作りました。

設計成果

例によって成果物から。

Ruby on Rails プラグイン まとめ wikiGemSpec.infoのER図がそのページです。

ER図の作図に使ったWWW SQL Designerにはエクスポート機能なんて機能はなく、スクリーンショット取るのもどうかと思ったので、使ったツールのデータファイルをそのままアップロードしてあります。

ER図で検討すべき事

先のエントリで言ったように、そのシステムで何が出来るか、どうやって処理するかはER図で検討すべきです。

まぁ、Webアプリの場合は(言語内の)オブジェクトはリクエスト毎に作り直されるのが普通なので、ユーザが入力したデータは、データベースに全て揃うはずですから、ER図を元に処理の方法を検討するのは道理なのかなと。

Railsの場合はActiveRecordが素晴らしいので、データベースの種類(MySQLなのかPostgreSQLなのかSQLiteなのか)は、あまり意識せずに設計できますが、高負荷になることがあらかじめ予想できたり、位置情報を扱いたい場合などは、設計当初からある程度絞り込んでおく必要がありそうです。

ちなみに、おいらの持っているイメージ(あくまでイメージであって真実ではないかも)

  • SQLiteはぽん付けで設置したい時に使う。性能を期待してはいけない
  • MySQLは最新版以外を使う価値は無いと思う。更新量が大きい場合に有効なクラスタリングのエンジンがあるので、そういう時には必ずMySQLを使う。それ以外ではPostgreSQLとあまり大差無いイメージ。
  • PostgreSQLは必ずしもインストールされているモノではないが、過去のバージョンでもそれなりに使えるイメージがある。単体での性能が良いイメージを持っているので、スケールアウトではなくスケールアップを狙うならこちらかな。PostGISが素晴らしすぎるので、位置情報を扱うなら黙ってこちら。

RailsでERを設計するときの注意点

今まである程度ちゃんとした規模のシステムをRailsで作ったことがなかったんだけど、実際にgemspec.infoの設計をしてみて感じたことがいろいろあるので、 まとめてみます。

コードジェネレータの影響が大きい

まず驚いたことは、プラグインとかgemなどのジェネレータで作られるテーブルやリレーションの影響がかなり大きい事。まぁ、悪いことではなく、歓迎すべき事なんですけど、Rails使うとこんな感じなんだーと思って新鮮でした。

現時点でのgemspec.infoのER図では、7割ぐらいがジェネレータで作られるデータ構造をベースにしています。

うまく言葉にできないけど、データ構造を保持するテーブルではなく、リレーションをうまく使って機能を実現するテーブルの方が、ジェネレータによって作られる比率が高いように思えます。たとえば、ユーザ管理とか、お気に入りとか、タグ関係とか、コメントとか。

逆に、データ構造を保持するテーブル(今回で言えばrubygemsテーブルより右と下側)は、汎用性が無いのでジェネレータで作るのは難しそうです。

ジェネレートするより先にマイグレーション内容を知る必要がある

コードジェネレータの影響が大きいことは事実ですが、これが実作業の流れと反することになるのはちょっと痛かったです。

というのも、コードジェネレータで作られたテーブルも含め、全てのER図に書き出してみて初めて全体像が把握できるので、設計を固めるためには、コードジェネレータを動かしてコーディングを始めるより先に、マイグレーションファイルの内容を把握しておく必要があるからです。

特に上記の通り、よほど特殊なデータ構造でない限り、ジェネレータで作られるテーブルやリレーションの影響は大きいので、これを後回しにしたままERを作ってもあまり実になりません。同じような構造が2つできちゃって、完成時には不思議な構造になってたなんてことも起こる気がします。

おいら的解決法は、ここのようにあらかじめマイグレーションファイルの内容と動作を調べておいて、ER図の部品を作っておくことです。

この観点から見ると、WWW SQL Designerはインポート機能こそないものの、XMLを直接編集することでER図の部品を取り込むことが可能なので、結構使いやすかったです。(他のER作図ツールだとインポートできないモノもあると思います)

ER図を完成させないと全体像が掴めない

ちょっとクドイですが、先にER図を完成させておく必要性についてもうちょっと突っ込んでおきます。

コーディングを始める前にER図を完成させなければならない一番の理由は、先のエントリの通り、モックとER図を付き合わせて設計を煮詰めていくからです。

設計を煮詰めるにあたり、やはり可視化がきちんと出来ていないと漏れが出てしまって、効率的に作業できないように感じます。

ユーザインタフェースを改良したり、ワークフローまで立ち返って検討するって作業は、結構高次元の作業なので、いろんな事がぱっと見でわかることは重要だと思います。

特に、ER図の内容でそのシステムの限界(機能や性能)が決まってしまいますし、プラグインやgemの動作によって画面構成も変わってきますので。(作るのが楽になるような画面構成にするという意味も含む)

また、実際にモックやER図を煮詰める過程で、頭の中では必要なクラスやメソッド、その中で行う処理の概要をイメージしながら煮詰めています。

ER図の部品化とパターン化

さて、こんな感じでER図の設計を進めているのですが、これってRailsの流れからはちょっと外れるので、ER図の部品を作っておく必要があると述べました。

裏を返せばこの部品を作る作業は一人だけで良く、かつ部品は(ツールが同じであれば)みんなで共有できるので、プラグインの情報を扱うサイトとか、gemspec.infoのようにgemの情報を扱うサイトはかなり有用に思えます。(プラグインの情報が欲しい方はRuby on Rails プラグイン まとめ wikiの情報元あたりから調べ始めることをオススメします)

また、このへんを突き詰めていくと、「こういう用途には、このgemとこのプラグインの組み合わせで、ER図はこう、画面構成はこう」といったパターンも出来てくると思います。

ここまで整備できれば、設計はかなり効率化できると思うんですけどね。

個人的には、Railsを使う一番の強みはここなのかなと思っています。正に「設計 on Rails」

設計に使ったツール

最後に使ったツールについての紹介でも、と思ったんですが、これもRubyOnRailsの設計手法もレールに乗せよう で紹介しきっているので、リンクを張るに留めます。

極端な話、ツールはあまり重要ではなく、どちらかというと、ジェネレータで作られるマイグレーションファイルの内容をあらかじめ知っておくことの方が、設計作業上は重要な気がします。

あ、そうそう。WWW SQL Designerでポリモーフィック関連を表現するための線を引くには、データファイル(XML)のノードを直接編集する必要があります。このへんもうちょっと改良できればなぁと思います。(作者にソースもらってちょっと改良しようかなぁと思ったり思わなかったり)

2008年9月26日金曜日

gemspec.infoのモック

gemspec.infoのフィーチャモデル からの続きで、Railsアプリケーションの設計を生でお伝えしようという企画(=思い付き)の第3回だか4回だかになります。(←適当)

今回はモックを作りました。

設計成果

例によって成果物から。

Ruby on Rails プラグイン まとめ wikiGemSpec.infoのモック がそのページです。

モックは簡単に画像ファイルにできるので、画像ファイルをペタペタ張った感じでまとめてあります。一応生データもアップロードしてあります。

モックとER図は同時に進める

あー、まずモックモックと言ってますが、これはペーパープロトタイピングレベルの画面設計のことです。正しくはモックの定義から外れるかも知れません。(面倒なのでこのエントリではモックで統一します)

で、Ruby on Rails によるシステム開発をモデリングで効率的に行うにはモック(というか画面設計)の話は出てきてないのですが、なんでコレを必要としたかって話を少し説明します。

まずおいらは、ユーザのワークフロー(「カートに商品を入れてから決済画面に進む」などの作業の流れ)とかユーザインターフェイス(使いやすいかどうか)はモックで検討を行い、そのシステムで何が出来るか、どうやって処理するかはER図で検討を行っています。

具体的にモックで何をするかというと、「その画面でユーザに入力してもらうデータそのものの種類と数」と、「次の画面に移ったり特定の処理を行うために必要なデータがその時点で揃っているかどうかを、その画面に配置された要素と、既に入力されデータベースに格納されて居るであろうデータだけで行うことが可能かどうか」の2つを検討するために使っています。

エントリの都合上、ここではモックの話だけしますが、実際にはモックとERを同時に検討しなければなりません。理由は下記の通り。

「その画面でユーザに入力してもらうデータそのもの」の検討

これは単純で、比較的ユーザインターフェイスが貧弱なWebアプリの場合、画面に出てくる要素の構成が、そのままデータベースの構成(ER図)になることが多いと経験上思っているからです。

これは、たとえばJavaでクラス設計をキチッとした場合は、間に抽象的な構造が入る分、画面=ERにはなりにくいのかなぁと思っています。(や、クラス設計キチッとしたことないから脳内の話なんだけど)

WindowsネイティブのGUIアプリとか、FlashやAjaxアプリなんかも、間に1層入る形なので、画面=ERにはならない可能性が高くなります。特にFlashとかAjaxなんかは、機能毎にもう1画面作ってるのと同じようなもんだし。

上記で「経験上思っている」と言ったのは、そうした方が構造がシンプルで実害もなく、結果として工数が少なくなると思ったから、実務では画面=ERとしたケースが多かったという意味です。(もちろん例外もあります)

逆を返せば、処理の都合上データ構造(ER)が制限され、それが画面インターフェイスに影響する場合があると思いますが、その影響がさほど不便ではなかったり、ユーザインターフェイスを工夫することによって乗り切れる範囲であれば、システム側の都合を優先させる方がいろんな意味(システム構築やデータ入力作業やサーバ負荷解消のためのコスト)で楽になるので、意図的に画面=ERになるような設計をすることも多いです。(あまり良い方法論とは言えないですが、この辺が理想と現実でしょうか)

「次の画面に映ったり特定の処理を行うための必要なデータがその時点で揃っているかどうか」の検討

若干上記と被っていますが、処理の都合上、次の画面へ行くために必要な最低限のデータセットというものがあるとして、

  • その画面に辿り着くまでに入力されていることを期待するデータは何か(今までの必須項目)
  • 次の画面に行くために必須となるデータは何か(処理上の必須項目)
  • その画面で最低限入力しなければならないデータは何か(この画面での必須項目)
  • ワークフロー上、その流れは自然か

というあたり、ワークフロー上の時系列に沿って考えるためにモックを使います。

「どの画面で何を入力できて、どれが必須か」というのは頭の中で管理するのは無理で、ましてや使いやすいかどうかは可視化しなければわからないものだと思います。

おいら的に、その「流れが自然か」「使いやすいか」というところは拘るべきところで、処理の都合上必須なのは仕方ないとしても、その画面のユーザインターフェイスを工夫したり、一つ前の画面で入力できるようにしたり、そもそもワークフローを変えても問題ないのであれば、自然な流れになるように調整したりといった作業が必要になります。

問題点

FlashやAjaxの場合、画面=ERとならない事も多いけど、これをうまく整理する方法がわからない。まぁ、Mockupsを使う分には簡単にモックをコピーできるので、動きの要所要所でもう一枚モックを作ればいいのかもしれないけど、なんかしっくり来ない気もする。

まぁ、ActionScriptとかJavaScriptで無理矢理ER図に合わせた形に加工できれば良いんだろうけど、それもどうかと思うしねぇ。

一つ言えるのは、FlashやAjaxやその技術を使ったリッチアプリケーションが増えてくるのは自然なことで、これら業界的な要求を満たす設計手法が確立してないってことかな。

画面設計するためのツール

さて話変わるんだけど、モックアップを作るために使ったツールを紹介しておきます。

と言っても、RubyOnRailsの設計手法もレールに乗せよう で紹介しきっているので、おいら的選定基準など。

  1. 書きながら考えやすいモノが良い
  2. 発注者やプログラマ達などに気軽に確認してもらえるモノがよい
  3. 2の観点からWebアプリで設計出来た方が、常に最新版を提示できるので良さそうだけど、ネットワークがあることが前提となるので、出張先などで開けなかったり、喫茶店で仕事できないのが痛い
  4. 3の観点から、ネイティブアプリ(Windows用とかMac用とかJavaモノとか)か、ローカルで動作可能なWebアプリが現実的かな
  5. 2の観点から作ったモノを簡単に配布できること。画像にエクスポートかけるか、(一般的なアプリで、データをファイルに落とせるなら)生データで展開するのが現実的かな
  6. 5の観点から、モックアップを作るためのツールが無料であること。画像は簡単に確認できるけど、メタ情報が落ちてしまうし、微調整さえも面倒になるので
  7. 素人でも理解できる程度の表現力があること
  8. 1にも準ずるけど、大雑把なものが、簡単に作れること。モックは何度も書き換えることになるので、簡単に作れないと心理的抵抗が大きくなる
  9. 注目すべき点は、デザイン的要素ではなく本質的な要素なので、見た目がキレイなのはいいけど、あまり拘らないこと(特に作り替えるときの心理的抵抗が大きくならないように)
  10. ネイティブアプリを作れるぐらいの表現力があること。この先AjaxやFlashはその高みまで到達すると思う
  11. 可能なら動きも再現可能なこと(でも難しいよね)
  12. データがテキストファイルになっている方が、subversionやgitなどでバージョン管理しやすい(データ量が少なかったり差分が見れたりなど)
  13. データが構造化テキスト(XMLとかYAMLとか)になっていれば、プログラムで解釈させてジェネレータなどを作ることも出来る

まとめると、「見せやすくて」「大雑把に簡単に作れる」ことかな。

候補としては

があるんだけど、ExcelとPowerPointは表現力が乏しいのでダメ、DreamWeaverはどうしてもCSSとかDivなどのブロックを考えなきゃいけないので本質から反れてダメ、となったときbalsamiq mockupsPencil が有力になると思う。

おいら的にはbalsamiq mockups だったんだけど、これはbalsamiq mockups の方が知ったタイミングが早くて、あまりPencil に興味がわかなかったってのが大きい気がする。

Pencil って実際どうなんだろう? ちゃんと使わないと比較はできない気はするモノの、できることはあまり大差がないように思えるので、どっちでもいい気がする。(mockupsは有料なのでPencil有利かな)

ただ、Pencilは気になるものの、balsamiq mockupsに満足しちゃってるので、乗り換えるかどうかは微妙だなぁ。

2008年9月25日木曜日

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

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

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

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

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

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

カラダカラって?

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

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

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

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

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

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

食事の記入

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

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

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

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

で、ここからが凄い

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

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

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

これを見てください。

カラダカラノートを使ったカロリー収支グラフ

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

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

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

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

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

で、ここで終わらない

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

たとえば、

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

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

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

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

まとめ

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

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

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

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

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

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

2008年9月20日土曜日

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

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

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

モデリング結果

まずは設計成果から。

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

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

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

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

全体的な流れ

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

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

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

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

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

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

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

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

意味合い

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

必要機能

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

問題点

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

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

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

そうそう

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

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

今後の予定

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

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

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

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

2008年9月18日木曜日

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

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

マイリスト使ってる?

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

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

マイリストには

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

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

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

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

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

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

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

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

2008年9月16日火曜日

アジアの一生懸命

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

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

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

アジアの一生懸命

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

2008年9月15日月曜日

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を使うって感じかな。

2008年9月10日水曜日

gemspec.infoのコンセプト

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

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

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

まず始めに

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

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

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

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

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

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

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

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

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

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

gemspec.infoのコンセプト

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

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

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

こんな感じ。

GemSpec.infoのコンセプト

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

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

コンセプトのまとめ方

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

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

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

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

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

テンション上げ上げで

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

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

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

2008年9月7日日曜日

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を推す)

2008年9月5日金曜日

Androidに触ってきた

先日「第5回EMS-JPグループ展示会に来ませんか?」みたいなメールが届いて、「armadilloもあるよ」みたいなことも書いてあったので、興味本位でちょっと見てきました。

まいむぞう × armadillo

おいらは組み込み系には疎く、せいぜいGainerで「わーおもしろーい。でも基盤焦がしちゃったせいでこのセンサーうごかなーい」とか言うぐらいなんですが、前に仕事で組み込み系の機材を調べたことがあって、armadilloの事は知ってました。

結局その案件ではarmadilloは使わなかったのですが、タバコの箱ぐらいの基板上でLinuxが動いていて、メモリの制限はキツイもののよく見るオープンソースモノが動いていたのは、いろんな可能性を感じました。まぁ、結局使わなかったので感じただけで体験できなかったんですけど。

armadillo × android

で展示会のarmadilloブースに行ってみると、なにやらもっと面白そうなモノがありました。

armadillo_android.jpg

ちょっと見づらいですが、armadilloのボードに十字キーとタッチパネルを付けて、androidが動いてました

えー!? アメリカでクリスマス商戦時期に最初の端末がでるんでしょ? 日本ではまだスケジュールさえ出てないのになんでココに?って感じだったんですが、話を聞くとまだ試作品段階とのこと。秋口にはでるかもって言ってましたが。

androidは全てオープンソースで構成されているので、SDKから必要部分を突っ込んだら動いちゃったーって感じみたいです。

実際、まだ試作機っぽく、ちょっと動かしたら固まってました(笑 そして担当の方も使い方がわかんないようでした(笑

android × 組み込み機器

androidって携帯電話に載るモノだとばかり思ってたおいらにはちょっとショックでした。

でもまー、よく考えたら、Javaが元々目指していた家電製品などの組み込み機器のための言語(および周辺アプリケーションと開発環境)と考えると、結構しっくり来てるかも。とも思いました。

特に、OSがLinuxなので足回りが強い感はありますよね。ネットワークとかファイルシステムが(ハード的な制約が許せば)PCの世界のスタイルでそのまま作れてしまうので。

実際Androidアプリを作った訳じゃないんですが、armadilloandroidが動いちゃうぐらいなんだから、それこそfelicaライタくっつけて「はい、会員カードシステム」とか、何もくっつけなくてもWeb連動POSとか居酒屋のオーダーシステムぐらいは簡単にできちゃう気がしてきました。(や、完全素人の考えなんですけど)

なんかそう考えると、androidのプログラミングって結構面白そうです。

写真ではちょっとわかりづらいですが、タッチパネルも手のひらぐらいの大きさはあるので、結構実用的に感じました。

android vs Linuxベース組み込み機器

今までもLinuxベースの組み込み機器で、タッチパネル付きというのがあるにはあったんですが、流石にX Windowを載せるわけにもいかず、独自というか組み込み向けWindowシステムを使うことが多かったように思います。(繰り返しますが、素人なので一部しか見えていません)

で、そういう独自Windowシステムって、「このGUIはCで作ったんだよ、がんばったでしょー」的な違和感を感じ、日頃使っているWindowsとかMacのようなしっくり感はあまり感じませんでした。

でも、試作とはいえ動いていたandroidは、「あ、コイツいつも使ってるGUIの血筋のモノだ」と思わせるようなしっくり感を感じました。

まぁ、その分リソースは食ってるんでしょうけど、どちらを選んでも実現できることには大差がないので、この感覚は大きいかも。

android vs Windowsベース組み込み機器

現状では狙ってるモノが違うので、この比較は意味があるのかどうかわからないですし、正直Windowsの組み込み路線は種類が多くてイマイチ方向性が解らないんですが、androidのGUIの競合になるのはこのへんなのかなぁと。

ただ、天下のMicrosoft様なので、プログラミング環境はWindowsベースの方が整っているでしょう。ライブラリも。(や、素人(r)

でも、windowsベースって、その元になるOSがね…。おいらはWindowsCE 1.0のユーザだったんだけど、未だにあの感覚なんだよなぁ、今の奴も。

あと、どうしてもMicrosoft様はマジメなので、ネットと絡めて面白いアプリを作ろうとか、ゲームを作ろうってなったらandroid優勢になる気がする。

あと、android market構想もあるんだっけ?

android on armadilloの将来

展示会から戻ってくるまで、このandroid × armadilloで何が出来るか考えてみたんだけど、やっぱり携帯電話などの常時接続ネットワークを持たないandroid端末は、ちょっと微妙な存在なのかも。

常時インターネットに接続できるなら、非力なマシンでもそこそこ使えるんだけど、いざスタンドアローンマシンとなると、まだPCベースの方が何かと便利に感じられる。値段も最近のAtom搭載ノートの方が安いし。(このandroid on armadilloは12万越えだそうです。まぁ、組み込みにしてはかなり安いイメージ)

じゃあまったく無駄かというとそうじゃなくて、armadilloのような組み込み機器にandroidが載って、それが普及することで、androidが組み込み向け標準windowマネージャ(widnows3.1みたいな感じ?)になってくると、その先が結構面白いことになる気がする。

iPhoneのように閉じた環境ではなく、各ハードメーカーとか、中小の技術者が面白いギミックをガッチャガチャくっつけて「ドライバだけ作っておいたから後よろしくー」みたいに投げてあって、それをおいらみたいなフリーランサーとか数人でやってるようなベンチャーが、趣味がてらにPC上のEclipseからJavaを使って変なアプリを作る、みたいな環境はけっこーおもしろいと思うのだ。やっぱりCでメモリ量を計算しながらプログラムするより、Eclipse上で富豪的に作りたいよね。(笑

ただ、これを実現するためにはarmadilloだけではダメで、他の主要組み込み機器メーカーもandroidを搭載して、windowsかlinuxかandroidかぐらいまで持ってくる必要があるし、armadillo自体も現状ではバッテリー駆動できないし、防塵や衝撃や防水とか耐久性の話もあるので、あと1世代か2世代ぐらい(あるいはもっと)待たないと、じゃあandroidで行こうかと簡単に言える時代にはならない気がした。

てなことで、暇が出来たらiPhone SDKではなくandroid SDKで遊ぼうと心に誓った日だった。

2008年9月4日木曜日

たとえばこんなプロフィールサービス

最近北海道のIT系イベントの紹介してて、一緒に自分の興味範囲を書き出してみたりしてるんだけど、これを能動的に書き出して示しておくのって、友達が出来やすい(とっつきやすい)気がする。

で、たぶん既にあるよなーと思ってabout meとかソレ系を調べてみたんだけど、自分の欲しい機能を持ったプロフィールシステムは見つけれなかった。

ってどんなシステム?

探しているシステムはこんな感じ

  • 一般的なプロフィールを登録・閲覧できる
  • マインドマップ的に言うと、自分が中心にあって、そこからの枝として「Rubyに関する興味範囲」「Javaに関する興味範囲」「PHPに関する興味範囲」など、既に登録してある(もしくは自分で登録できる)カテゴリから、興味範囲を羅列できる。
  • 自分のプロフィールをURLで指定できて、ログインなど無しにみんなに公開できる
  • ブログパーツなどで簡単に格好良く貼れる
  • 他人の興味範囲に対して検索できる

「プロフィールをサイトで示す」という意味と、上記機能って結構被ると思うから、既にあるよなーと思ってるんだけど。

こんな感じで使えたらもっと面白そうってのを突っ込むと

  • 既に他の公開プロフィールを持っている人にも、追加プロフィール的に興味範囲だけ書かれたページを表示できる。
  • ユーザ認証にOpenIDを使う(ID見て「あぁやっぱりあの人ね」という使い方がしたい)
  • ついったーのフォローみたいな感じに、簡単にコネクションを増やせる
  • 興味範囲を仲介して繋がったコネクションをグラフ化(ネットワーク図?)

SNSとかソーシャル系のサービスのいち機能となってる気もするけど、誰か知ってたら教えてください。


2008年9月2日火曜日

LOCAL PHP部 aka PHP北海道のイベントに参加しようかと

最近北海道のイベント紹介ブログのようになってきましたが、別にそういう意図は無くて、単純に北海道でのコミュニティ活動が活発になってきた(ように感じる)からなのです。

たとえば、9月は新しく先日紹介した札幌Java勉強会や、今回紹介するLOCAL PHP部が活動を開始しました。定期的に活動しているコミュニティって片手で収まらなくなりましたね。

で、おいらはまたどんなもんか参加してみようかと。(や、決して呑みたいからとかとかいう理由ではないよ)

概要

  • 日時 9/21(日) 14時〜16時ごろ
  • 会場 ちえりあ  サークル活動室4
  • 締め切り 当日イベント終了まで(笑)
  • 内容 docTestについて(by bobchinさん) 及び 今後のLOCAL PHP部の活動を考える会
  • 参加方法 こちらからログインして参加登録する

地理的に地下鉄の端に位置する「ちえりあ」で行うので、ドニチカ切符買った方がお得かもとのこと。

てか!!

2年前のOSC2006 Hokkaido内セッションでPHP関係のコミュニティメンバー募集しますーと言ってたのは、この布石だったのかー(笑

突っ込み

ちょっとまだ流れが決まってないこともあって、

の使い分けがはっきりしてない感がありますが、 まぁ、全部見れば良いと思うよ。(たぶんそのうち決まるでしょう)

おいらの立ち位置

PHP on ZendFrameworkを使ってきたとはいえ、個人的には既にRailsに移行してしまっているので、正直今からPHPを追うってのは考えてない。

PHPとRubyって、自分の使い方では同じ領域をカバーしているように見えてるし、Rubyの方がコマンドラインで動かす時に便利に感じるので。(や、PEAR使えば同じなんだろうけど)

個人でRails使いながら、会社でZendFramework使ってたので、不満いっぱいあってイメージ悪いってのが大きい気がする。やっぱり浮気はいけないと思った瞬間だった。(何?

ただ、Railsを使うべきではない領域(個人的にはテンプレートが10ページ以内の小規模システムかな。メールフォームだけなど)とか、Railsが動かない(もしくは動かすのが現実的ではない)サーバもあるから、これからもPHPは使うこともあるだろうけど。

あーでも、ぶっちゃけると、現時点で(アプリケーションサーバ的)負荷が高いシステムを作るなら、迷わずPHPを使うだろうけどね。(苦笑

実行速度やサーバの管理(インスタンスが落ちてないかどうかとか)は、圧倒的にPHPの方が楽だから。まぁ、組み方によるけど。

個人的興味範囲

こんな感じなので、PHPそのものというより、その周辺事情とか使い分けの方が興味あるかな。

  • 個人的には言語がどうというより、言語の上にフレームワークとか、プラグイン的ライブラリとか、IDEとかなどの開発環境が載って、「どこまで作ることに楽を出来るか」みたいなところ
  • 他言語も含めて、「こんな用途(問題領域)」には「この言語でこんな使い方(解決領域)」みたいな使い分け
  • 言語非依存の「設計」「テスト」「デーモンやライブラリとの絡ませ方」あたり

みんなの興味がありそうな範囲

最近PHP周辺であたらしい話題がない気がするので、王道的な

  • PHP4からの移行ポイント
  • PHP4システムのメンテ方針
  • どういうバックグラウンドがある人には、どういうフレームワークが良いか(もしくはコレサイコーなのでコレ使え)
  • どういう用途には、どういうフレームワークが良いか(もしくはコレサイコーなのでコレ使え)
  • PHPでのUnitテストの仕方(知り合いのPHPerでUnitテストしてる人見たこと無い)
  • PHPでの開発環境(IDEとかSCMとかBTSとか。だまされたと思って今からいうモノ全て入れろ的なノリで)
  • 初学者向けのsmartyの使い方(システムも手がけ始めたデザイナ対象とか)
  • 中上級者向けのPHPとAjaxを絡める方法(特にjQueryあたりぽん付けで動くのが多いので)
  • 中上級者向けのPHPでのセキュリティ対策方面(最近の傾向と対策的な)

的なところにみんなの興味がある気がする。

てか、おいらはこれらに興味があった。(でも、最近PHP追ってないので既に一般では対象外のものも含まれている気もする)

興味ある人集まれー

で、全然上記と関係ないけど、こんな興味ある人お友達になりませんか?

  • Amazonのリコメンドシステムのように、「見た」「買った」などから「オススメ商品」を計算する系(うまく言えない)
  • Flex系(Flashをシステムちっくに使っている人含む。AIR含む)
  • 自然言語処理系(自然文から意味や統計を導き出すあたりに興味を持っている人)

一緒に勉強したり呑みたいので、北海道の人で友達が出来ると嬉しいです。 もちろんネット前提の遠方の方でも嬉しいですー。

興味がある人はとりあえずmaimuzo@gmail.comにメールくださいなー。