2012年9月28日金曜日

Java: クラスが持っているフィールドやメソッド名を検索し,動的に実行する

ちょっとマニアックなネタです。ラボでO/Rマッパーみたいなものを作ろうとしているのですが、その際に使えそうなノウハウを紹介します。

クラスのフィールド名とメソッド名を検索する
あるクラスがどういうフィールドやメソッドをもっているか?を調べるには下記のようにします
Class c = Class.forName("クラス名");
Field[] fields = c.getFields(); //フィールド名
Method[] methods = c.getMethods(); //メソッド名
String methodName = method[0].getName();
これらのメソッドはフィールドインスタンスやメソッドインスタンスを入手するものなので、特定のメソッド名(またはフィールド名)を取ってくることも可能です。その場合は、下記のように記述します。
Method method = c.getMethod(メソッド名, 引数の型<可変長>);
なお、getMethodsやgetFieldsではパグリックなフィールドやメソッドしか入手できませんが、getDeclaredMethodsやgetDeclaredFieldsを利用するとプライベートなフィールドやメソッドを入手することが可能です。

メソッドを実行する 
上記のmethodsはメソッドインスタンスの配列です。これを利用して下記のように検索したメソッドを実行します。下記では,実行対象となるインスタンスを生成してメソッドをinvokeする際に渡してます。staticなメソッドの場合は不要です(第一引数はnullです)。
Constructor constructor = c.getConstructor(new Class[] {});
Object o = constructor.newInstance(new Object[] {});
methods[i].invoke(o, null);

フィールドにアクセスする
 上記で入手したフィールドにアクセスする方法は下記の通りです。
fields[0].set(obj, "abc");
String n = (String)fields[0].get(obj);
O/Rマッパーを自作するときは,プライベートなフィールド名を利用するとよいかもしれません。

2012年9月18日火曜日

教育システム開発のアプローチ ー教育工学会全国大会の議論からー



教育工学会全国大会でシンポジウムに参加してきましたが、SRAの中小路先生の話が非常にツボにはまったので、以下、中小路先生の話のピックアップと感想など。。。

教育システムの研究開発をしている時に考えてなければならないのは、学習・教育活動をどう支援していくかなのだが、そのアプローチについて中小路先生は非常に面白い比喩で説明されていた。そのアプローチには以下の3種類があるという。

  • ダンベルを作る研究
  • シューズを作る研究
  • スキー用具を作る研究
ダンベルというのは筋力を鍛えるための道具。教育支援システムでいえば、学力やスキルを向上させるということだろう。
シューズというのは、走るという動作をサポートする道具。教育支援システムでいえば、理解や正解をし易くするということだろう。
スキー用具というのは、スキーというスポーツをするための道具。教育支援システムでいえば、学習の場を提供するということだろうか。

なるほど上手いこと言うなぁ、、と思ったが、後から振り返ってみると、教育工学という分野が扱う「学び」という要素が入ってくるとちょっと違和感が見えてくる。例えば「走る」ということを考えてみると、その目標は速く走ること。では、速く走れればそれでいいのか?100mを11秒で走れる者が、あるシューズを使うと9秒で走れたとする。その学習者は9秒で走れる能力を身につけたといえるのか?おそらく違うだろう。
もちろん、シューズ的なアプローチが教育工学に合わないという意味ではなく、例えばその道具を使うことで見えなかったモノが見えるようになり、結果的に理解を促進するという効果を持った道具というのはシューズ的な研究としてOKだとは思う。
ただ、個人的に日々の教育において
  • 学習者にわかりやすく教えること
についての学習効果について疑問に思っているのでちょっと引っかかった感じ。というか、なんでもかんでも「わかりやすく、見せてしまう」ことの教育的な妥当性について気になるんですよね。

最後のスキー用具を作るアプローチというのは、新しい学習環境やエクスペリエンスを提供する研究なわけで、これは自分の今までの研究アプローチかなぁ、、と思ったが、ただよく考えてみるとそうでもないような気もしてきた。というより、自分がどの視点なのかを明確にできてないところに問題がある気がしている。
中小路先生が力説されていたのは、自分の研究がこの3つのアプローチのどれにあてはまるのか理解し、それに見合った評価をしましょうということ。今、自分のシステムの評価方法についていろいろ四苦八苦していたので、今回の話に何かヒントがあるのではないかという感触を得た。

ちなみにこの3つの分類については、これらは独立したものではなく、これらの要素が組み合わさったもののように思えるがどうなんだろうか?あるいはどれか1つに絞り込めないようであれば、研究が対象とする支援のポイントが不明瞭になっているということなのだろうか?


2012年9月12日水曜日

GWT:マウスによるペースト処理を検知する

コピーアンドペーストはよく利用される操作ですが、
  • キー操作
  • 右クリックのコンテクストメニューによる操作
の2つの方法があります。後者でやられた場合、キーイベントで検知できないのが問題です。対応策は下記のとおりです。
//コンストラクターに下記を記述
sinkEvents(Event.ONPASTE);

//onBrowserEventメソッドをオーバーライド
@Override
          public void onBrowserEvent(Event event) {
            super.onBrowserEvent(event);
            switch (event.getTypeInt()) {
            case Event.ONPASTE:
              //event.stopPropagation(); //ここは状況に応じて
                System.out.println("paste");
              break;
            }
          }

stopPropagationメソッドについては、イベントの伝播を止めたい場合に呼び出します。

2012年9月11日火曜日

GWT:TextAreaでエンターキーのイベントを検知し処理する

「TextAreaで文字入力を受け付けて、改行と同時にその内容を取り込んでクリアする」というツイッターみたいなプログラムを作成する場合にちょっとハマったので、メモ書きしておきます。

キーイベントの発生順番
TextAreaでのキーイベントの発生順序は下記の通りになりますが、TextAreaにその文字が入力されるタイミングに注意する必要があります。
  1. Down ・・・ 入力前発生
  2. Press ・・・ 入力前発生
  3. Up ・・・ 入力後発生
例えば、改行時にTextAreaの内容をクリアしたい場合、1,2のタイミングでは改行コードはクリア後にTextAreaに入ってしまいます。必ず3のタイミングで処理する必要があります。

キーコードの検知
現在入力されたキーのコードを検知するには、
  • KeyPressEvent
でしか検知できません。

KeyPressとKeyUpを組み合わせる
KeyPressEventでキーの内容を検知し、KeyUpEventでTextAreaの中身を取ってくる(消す)という手順が必要です。例えば以下の様な記述になります。
       @UiHandler("textArea")
        void onEnterKey(KeyPressEvent e) {
                System.out.println("Press");
                if (e.getCharCode() == KeyCodes.KEY_ENTER) {
                        isEnter= true;
                }
       }

        @UiHandler("textArea")
        void onUpKey(KeyUpEvent e) {
                System.out.println("Up");
                if (isEnter) {
                        /*ここでなんらかの処理をする*/
                        isEnter=false;
                }

        }
なお、上記のコードはUiBinder利用時の記述です。

2012年9月9日日曜日

参加報告:文章表現・ライティングの授業設計ワークショップ


現在、学科で初年次教育系の科目(いわゆる基礎ゼミ)の取りまとめ役になっているのと、個人的にライティング支援システムの研究をやっている(やろうとしている)ので、情報収集のため河合塾FDセミナーに参加してきました。以下、メモ書きです。

対象とする学生のレディネスはどうか?
どの学年でどのようなスキルを持った学生を対象としているのか?そのレディネスを探るのは重要でしょう。プレテストのようなものでチェックするのもひとつの手だと思いますが、それを容易に把握できるシステムが重要になってくるかもですね。

何を学ばせるのか?
教える側としては「教えたいこと」は山ほどあり、そして多様。しかし時間が限られる。この制約でどうやって学習目標を設定して、カリキュラムの中で取り入れていくか、、、教員間で共有すべき問題でしょう。事前にチェックするというのは1つのアプローチですね。本セミナーでは
  • 語彙文法志向
  • 学びの基礎志向
  • 実用志向
  • 読解志向
  • 学術志向
  • グループワーク志向
という6つの分類で、ニーズ分析を図る方法が紹介されていました。この中で優先順位を決めるのはありかと思います。

ライティングにおける3つの教育スタイル
セミナーでは講義のアプローチとして以下の3つを紹介していました。教育工学の世界ではよく知られたことですが、「ライティング」という科目にどう当てはめていくのか?をグループワークでまとめました。

(1)教えるタイプ(行動主義×伝統的)
従来型のスタイルですが、ライティングの視点から考えた時
  • レポートと感想文との違いを明示する
  • サンプルを見せる
というのは、有効な方法のようです。

(2)気づかせるタイプ(認知主義×協同的)
グループ学習を意識したアプローチですが、その中で
  • 誤りを学生に修正させる
というアプローチが有効のようです。学生自身が書いた文章をお互いに修正させあったり、誤りのあるレポートに対してグループ内で修正させるというやり方が考えられます。

(3)気づき合うタイプ(構成主義×協調的)
これはどちらかというと高度な手法で、学生にもスキルが求められます。基本的には学生グループに主体的に学習させるもので、例えば
  • テーマ決め
  • KJ法やマップなどによる意見・データの集約と分析
  • 相互によるチェック
などレポートライティングのプロセスを学生自身にすべて行わせます。初年次の学生には難しそうですが、実はこれに類似したことを実践されている先生もおり、やり方次第で十分可能のようです。

これらを組合わせて講義にどう活かしていくか
ライティング講義においては、上記の3つはどれか1つに限定するものではなく、いろいろ組合わせていくことになります。ただ実際(2)や(3)というのをやろうと思ったら難しい、、、ここのところをどうするか?が個人的には一番知りたいところなのですが、残念ながら本セミナーではこの点について言及する機会がなく、個人的には残念なところでした。