多忙な Java 開発者のための Scala ガイド: Scitter を使って Twitter を更新する

Scitter ライブラリーに POST 操作と DELETE 操作を追加する

Scitter クライアント・ライブラリーはほぼ実用的なものになりましたが、最後の仕上げが少し必要です。今回の「多忙な Java 開発者のための Scala ガイド」では、Ted Neward が、Twitter にアクセスするための Scala ベースのライブラリーに対し、更新、表示、削除機能を追加する方法について説明します。

Ted Neward, Principal, ThoughtWorks

Ted Neward photoTed Neward は世界規模でコンサルティングを行う ThoughtWorks のコンサルタントであり、また Neward & Associates の代表として、Java や .NET、XML サービスなどのプラットフォームに関するコンサルティング、助言、指導、講演を行っています。彼はワシントン州シアトルの近郊に在住しています。



2009年 10月 20日

私がこの記事を執筆している間に、夏は終わりを告げようとしており、新しい学年が始まろうとしています (訳注: 著者が在住している米国では 9月に新しい学年が始まります)。そして Twitter のサーバーは、世界中の Twitter マニアの近況や Twitter マニアではない人達の近況を、休むことなく吐き出し続けています。北米に住む私達の大部分にとって、話題は海辺のパーティーからフットボールに、そして屋外で行っていた活動は室内でできるものに切り替わりつつあります。それに合わせて、Twitter にアクセスするための Scala クライアント・ライブラリー Scitter を再度取り上げる時期が来たようです。

このシリーズについて

developerWorks のこのシリーズでは、Ted Neward が皆さんと共に Scala プログラミング言語を深く掘り下げ、Scala がもてはやされている理由を調べ、Scala の言語機能の実際の動作を調べます。Scala のコードと Java™ のコードの比較が重要な場合には両者のコードを並べて示しますが、(これから学ぶように) Scala の機能のうちの多くは、Java には直接対応するものがありません。そして Scala の魅力の多くがあるのはそこなのです。結局のところ、Java で可能ならば、手間をかけて Scala を学ぶ必要はないのです。

Scitter の開発について説明した前回までの記事を読んでいる方は、Scitter ライブラリーを利用すると、さまざまな Twitter API を介して Twitter ユーザーの友達やフォロワー、タイムラインなどの情報を取得できることをご存知かと思います。ただしこのライブラリーには、近況のアップデートを POST する機能が欠けています。Scitter に関する記事の最終回である今回は、このライブラリーに欠かせないメソッドである update()show()destroy() と作成するのが楽しい機能 (end と rate) を追加して締めくくります。そのなかで、Twitter API の詳細と、Scala によって Twitter API をうまく利用する方法、そして Scala で Twitter API を利用する上で避けられないプログラミング上の問題を克服するためのヒントについても学びます。

この記事を皆さんが読む頃には、Scitter ライブラリーは公開ソース管理リポジトリーに置かれているはずです。もちろん、この記事にもソース・コードを含めてありますが、ソースのベースは変更される可能性があることに注意してください。つまり、プロジェクトのリポジトリーに置かれているコードは、この記事で紹介するコードと多少あるいは大幅に異なっている可能性があります。

Twitter に POST する

これまでの Scitter の開発では、HTTP GET を使用した操作に焦点を絞ってきました。その大きな理由は、GET を使った呼び出しは非常に容易であり、また私は手軽に Twitter API を使いたかったからです。Scitter ライブラリーに POST 操作と DELETE 操作を追加することは、公開という観点でも大きな一歩を意味します。これまで皆さんは、何をしようとしているのかを他の誰にも知られずに、自分の Twitter アカウントに対してユニット・テストを実行することができました。しかし近況メッセージを送信し始めると、皆さんが Scitter のユニット・テストを実行していることを世界中の人達が知ることになります。

Scitter のテストを継続する場合には、独自の「test」アカウントを Twitter に作成する必要があります。(Twitter にはテストを行ったり、モックを生成したりするための機能がありませんが、これは Twitter API を利用するコードを作成する上で、おそらく最大の欠点です。)

Twitter API

まだ Twitter API をよく理解していない人は、数分間時間をとり、http://apiwiki. twitter.com/REST+API+Documentation にある Twitter API のウィキ・ページを調べてください。基本は単純です。パラメーターは URL クエリーの一部として渡され、レスポンスは 4 つのフォーマット (JSON、XML、ATOM、RSS) のいずれかである、等々です。しかし、どの API の場合も同じですが、問題は詳細部分にあります。この記事を読む際には、画面上のどこかにブラウザーで Twitter API を開いておくと、Scala に関係する部分に注目しやすくなるはずです。

前回までの説明

Scitter ライブラリーの新しい UPDATE 機能を説明する前に、これまでに作成したものを説明しましょう。(この記事には完全なソース・リストを含めてありませんが、これは Scitter の完全なソース・リストを記事に含めるには不適切なほど長くなり始めているためです。この記事を読みながら、別のウィンドウでコードを見てください。)

大まかに言えば、Scitter ライブラリーは以下の 4 つの部分に分割されます。

  • API の一部として送受信されるリクエスト型とレスポンス型 (UserStatus など)。これらは case クラスとしてモデリングされます。
  • 場合によると同じく API の一部である OptionalParam 型。これらの型も基底 OptionalParam 型を継承する case クラスとしてモデリングされます。
  • 通信の基本部分や Twitter への匿名 (非認証) アクセスに使われる Scitter オブジェクト。
  • 指定の Twitter アカウントに認証アクセスするためのユーザー名とパスワードを保持する Scitter クラス。

ファイルを比較的扱いやすいサイズに保つために、今回の記事からはリクエスト型とレスポンス型をそれぞれ別のファイルに分割してあることに注意してください。


end と rate

目標がはっきりしたので、「読み出し専用」の 2 つの Twitter API を実装することから始めます。この 2 つというのは、(ユーザーのセッションを閉じる) end_session API と、(特定の期間、あるユーザー・アカウントがあと何回 POST できるかを指定する) rate_limit_status API です。

end_session API は、同じくアカウントに関する API である verify_credentials API と同様に、非常に単純な API です。認証リクエストを使ってこの API を単純に呼び出すと、この API は開いているセッションを閉じます。この API は比較的容易に Scitter クラスに実装することができます (リスト 1)。

リスト 1. Scitter に end_session を実装する
package com.tedneward.scitter

{

  import org.apache.commons.httpclient._, auth._, methods._, params._

  import scala.xml._



  // ...

  class Scitter

  {

    /**

     *

     */

    def endSession : Boolean =

    {

      val (statusCode, statusBody) =

        Scitter.execute("http://twitter.com/account/end_session.xml",

          username, password)



      statusCode == 200

    }

  }

}

いかがでしょう。それほど容易ではないかもしれませんね。

POST を使用する

end_session では、これまで Twitter API の中で扱ってきた他の API とは異なり、受信されるメッセージを HTTP POST で送信する必要があります。現状では、Scitter.execute メソッドは GET を使ってすべてを実行します。これはつまり、Scitter.execute メソッドは、GET を使用する API と POST を使用する API とを何らかの方法で区別する必要があるということです。

この問題はしばらく脇に置いておくとして、もう 1 つ明らかに変更が必要な点があります。POST を使用する API 呼び出しでは、名前と値のペアも execute() メソッドに渡す必要があります。(GET を使用する他の API 呼び出しの場合には、すべてのパラメーターは URL の行にクエリー・パラメーターとして含まれること、また含めることができることを思い出してください。POST を使用する場合には、HTTP リクエスト本体の中にパラメーターが含まれます。) Scala の場合、名前と値のペアと言えば、Scala の Map 型が必ず頭に浮かびます。つまり、POST の一部として送信されるデータ要素のモデリング方法として考えられる最も簡単な方法は、それらのデータ要素を Map[String,String] の中に入れて渡す方法です。

例えば、新しい近況メッセージを Twitter に渡す場合には (この場合、140 文字以下のメッセージを名前と値のペア (status と呼ばれます) の中に入れる必要があります)、リスト 2 のようになります。

リスト 2. Map の基本的な構文
val map = Map("status" -> message)

この構文を使用すると、Map を引数に取るように Scitter.execute() メソッドを再構成することができます。Map が空の場合には、POST ではなく GET を使う必要がある、と見なすことができます (リスト 3)。

リスト 3. execute() をリファクタリングする
  private[scitter] def execute(url : String) : (Int, String) =

      execute(url, Map(), "", "")

    private[scitter] def execute(url : String, username : String,

	                             password : String) : (Int, String) =

      execute(url, Map(), username, password)

    private[scitter] def execute(url : String,

	                             dataMap : Map[String,String]) : (Int, String) =

      execute(url, dataMap, "", "")

    private[scitter] def execute(url : String, dataMap : Map[String,String],

                                 username : String, password : String) =

    {

      val client = new HttpClient()

      val method = 

        if (dataMap.size == 0)

        {

          new GetMethod(url)

        }

        else

        {

          var m = new PostMethod(url)


          val array = new Array[NameValuePair](dataMap.size)

          var pos = 0

          dataMap.elements.foreach { (pr) =>

            pr match {

              case (k, v) => array(pos) = new NameValuePair(k, v)

            }

            pos += 1

          }

          m.setRequestBody(array)

          

          m

        }


      method.getParams().setParameter(HttpMethodParams.RETRY_HANDLER, 

        new DefaultHttpMethodRetryHandler(3, false))

        

      if ((username != "") && (password != ""))

      {

        client.getParams().setAuthenticationPreemptive(true)

        client.getState().setCredentials(

          new AuthScope("twitter.com", 80, AuthScope.ANY_REALM),

            new UsernamePasswordCredentials(username, password))

      }

      

      client.executeMethod(method)

      

      (method.getStatusLine().getStatusCode(), method.getResponseBodyAsString())

    }

execute() メソッドに対する最大の変更は、Map[String,String] パラメーターが導入されたこと、そしてこのパラメーターのサイズに基づいて判定を行う if 文が導入されたことです。この if 文によって、GET リクエストを扱うのか POST リクエストを扱うのかを判断します。Apache Commons の HttpClient では POST リクエストの本体を NameValuePairs の中で行う必要があるため、foreach() 呼び出しを使ってマップの要素に繰り返し処理を行います。この処理では、2 つの部分から成る pr というタプルとしてマップのキーと値を渡し、ローカル変数 k と v の中にキーと値を抽出し、これらの値を NameValuePair コンストラクターに対するコンストラクター引数として使います。

PostMethodsetParameter(name, value) API を使用すると、こうしたことのすべてを、もっと容易に行うことができます。私がリスト 3 の方法を選択した理由は教育的な観点からです。つまり Scala の配列では配列参照が val として定義されていますが、Java の配列と同じように相変わらず可変であるという事実をリスト 3 で示したのです。ともかく、実際のコードでは各 (k、v) タプルに対して PostMethodsetParameter(name, value) メソッドを使った方がはるかに適切である、ということを頭に入れておいてください。

もう 1 つ注意する点として、Scala コンパイラーは型推論をする際に、if/else によって返される「method」オブジェクトの型を適切に判断します。Scala は if/else によって GetMethod オブジェクトが返されたのか PostMethod オブジェクトが返されたのかを判断できるため、「method」に対する戻り型として直接の基底型、HttpMethodBase を選択します。これは、HttpMethodBase で利用できないメソッドを execute() メソッドの他の部分で利用することはできない、という意味でもあります。幸いなことに、ここではそうしたメソッドは必要ないため、少なくとも今のところ、それが問題になることはないでしょう。

リスト 3 の実装に潜む最後の問題は、execute() メソッドが GET 操作を扱うのか POST 操作を扱うのかを、Map を使って判断しているという事実と関係しています。もし、他の HTTP 操作 (PUTDELETE など) を使う必要がある場合には、もう一度 execute() をリファクタリングする必要があります。ここまでの時点ではこの問題を気にする必要はありませんでしたが、先に進む際にはこのことを頭に入れておく必要があります。

テストする

このリファクタリングを実装する前に、ant test と入力して実行し、GET ベースの元々のリクエスト API がすべて変わらず動作することを確認しましょう。テストしてみると、実際に問題なく動作します。(この結果から、本番の Twitter API の変更や、Twitter サーバーを利用する上での変更が何もないという前提で話を進めます。) すべては適切に動作するので (少なくとも私のマシンでは適切に動作したので)、新しい execute() メソッドの実装は非常に簡単です。

リスト 4. Scitter v0.3: endSession
  def endSession : Boolean =

    {

      val (statusCode, statusBody) =

        Scitter.execute("http://twitter.com/account/end_session.xml",

          Map("" -> ""), username, password)


      statusCode == 200

    }

これ以上簡単にならないほど簡単です。

次に、rate_limit_status API を実装する必要があります。この API には認証版と非認証版の両方があります。ここではこのメソッドを rateLimitStatus として Scitter オブジェクトと Scitter クラスの両方に実装します (リスト 5)。

リスト 5. Scitter v0.3: rateLimitStatus
package com.tedneward.scitter

{

  object Scitter

  {

    // ...

	

    def rateLimitStatus : Option[RateLimits] =

    {

      val url = "http://twitter.com/account/rate_limit_status.xml"

      val (statusCode, statusBody) =

        Scitter.execute(url)

      if (statusCode == 200)

      {

        Some(RateLimits.fromXml(XML.loadString(statusBody)))

      }

      else

      {

        None

      }

    }

  }

  

  class Scitter

  {

    // ...

	

    def rateLimitStatus : Option[RateLimits] =

    {

      val url = "http://twitter.com/account/rate_limit_status.xml"

      val (statusCode, statusBody) =

        Scitter.execute(url, username, password)

      if (statusCode == 200)

      {

        Some(RateLimits.fromXml(XML.loadString(statusBody)))

      }

      else

      {

        None

      }

    }

  }

}

これも非常に単純だと思います。


アップデート

POST を使用できる新しいバージョンの HTTP 通信レイヤーが用意できたので、Twitter API の中心とも言える、update 呼び出しに取り組むことにします。当然ですが、update を呼び出すためには、status という少なくとも 1 つの引数を取る POST が必要です。

この status パラメーターには、認証ユーザーの Twitter フィードに POST するための 140 文字以下のメッセージが含まれています。またオプションのパラメーターとして、in_reply_to_status_id も含まれています (in_reply_to_status_id は、POST されたアップデートが別のアップデートに対する返信である場合に、その返信の対象となるアップデートの ID を指定します)。

これで update 呼び出しに対する説明は終わりです (リスト 6)。

リスト 6. Scitter v0.3: アップデート
package com.tedneward.scitter

{

  class Scitter

  {

    // ...


    def update(message : String, options : OptionalParam*) : Option[Status] =

    {

      def optionsToMap(options : List[OptionalParam]) : Map[String, String]=

      {

        options match

        {

          case hd :: tl =>

            hd match {

              case InReplyToStatusId(id) =>

                Map("in_reply_to_status_id" -> id.toString) ++ optionsToMap(tl)

              case _ =>

                optionsToMap(tl)

            }

          case List() => Map()

        }

      }

      
      val paramsMap = Map("status" -> message) ++ optionsToMap(options.toList)


      val (statusCode, body) =

        Scitter.execute("http://twitter.com/statuses/update.xml", 
           paramsMap, username, password)

      if (statusCode == 200)

      {

        Some(Status.fromXml(XML.loadString(body)))

      }

      else

      {

        None

      }

    }

  }

}

このメソッドで、おそらく最も「変わっている」部分は、このメソッドの内部に定義されているネストされた関数でしょう。GET を使用する他の Twitter API 呼び出しの場合とは異なり、Twitter は POST される本体内部に POST のパラメーターが含まれているものと想定しています。つまり、POST のパラメーターを Map のエントリーに変えてから Scitter.execute() を呼び出す必要があります。しかしデフォルトの Map は、(scala.collections.immutable によって) 不変です。つまり Map を組み合わせることはできますが、既存の Map にエントリーを追加することはできません。(実際には追加できるのですが、追加しない方が適切です。これについては囲み記事「可変コレクション」を参照してください。

可変コレクション

Scala では、scala.collections.immutable パッケージの代わりに単純に scala.collections.mutable をインポートすることで可変コレクションを扱うことができます。ただしそうすると、可変データを扱う場合に発生する、おなじみのリスクが生じます。そのため、Scala の一般的なプログラミング・スタイルとしては、他の不変コレクションから不変コレクションを作成する方が適切です。どうしても可変コレクションが必要な場合、あるいは可変コレクションを扱いたい場合には、scala.collections をインポートし、パッケージ名の一部を接頭辞として (つまり mutable.Map または immutable.Map のようにして)、Map (または他の) コレクション型を参照します。こうすることで、1 つのスコープ・ブロックの中で可変コレクションと不変コレクションの両方を扱う場合の混乱を避けることができます。

このちょっとした難問を解くための最も容易な方法は、渡される OptionalParam 要素のリスト (実際には Array[]) を再帰的に処理する方法です。ここでは各要素を分離して独自の Map エントリーにします。そして新しい Map (新しく作成された Map と再帰呼び出しによって返された Map で構成されます) を optionsToMap に返します。

こうしておけば、ネストされた optionsToMap 関数に OptionalParamArray[] を渡すのは非常に簡単です。optionsToMap 関数では、返された Map と、status メッセージを含むように作成された Map とを連結します。最後に、この新しい Map をユーザー名とパスワードと共に Scitter.execute() メソッドに渡すと、Twitter のサーバーに送信されます。

ところで、このように延々と説明するよりも、実際にコードを見た方がわかりやすいはずです。このコードは非常にスマートなプログラミング方法を示しています。

考えられるリファクタリング

update に渡されるオプション・パラメーターによって実行される内容は、理論的には GET ベースの他の API 呼び出しにオプション・パラメーターとして渡された場合に実行される内容と、ほとんど同じです。異なるのは、結果のフォーマットが URL 用の名前と値のペアではなく、POST に適した名前と値のペアになっていることのみです。

Twitter API で他の HTTP 操作をサポートする必要がある場合には (必要となる可能性が最も高いのは PUTDELETE/ の 2 つです)、いつでも HTTP 操作を特定のパラメーター (例えば case クラスのセットなど) にし、execute() が 5 つの引数として、HTTP 操作、URL、名前と値のペアのマップ、そして (オプションとして) ユーザー名とパスワードを取るように設定することができます。そうすると、オプションのパラメーターを必要に応じて 1 つのストリングにしたり、または POST される一連のパラメーターにしたりすることができます。これを今後のために頭に入れておいてください。


表示

取得対象の Twitter 近況メッセージの ID を指定して show を呼び出すと、Twitter 近況メッセージが 1 つ表示されます。update の場合と同様、show の呼び出しもほとんど自明です (リスト 7)。

リスト 7. Scitter v0.3: show
package com.tedneward.scitter

{

  class Scitter

  {

    // ...

	

    def show(id : Long) : Option[Status] =

    {

      val (statusCode, body) =

        Scitter.execute("http://twitter.com/statuses/show/" + id + ".xml",

		  username, password)

      if (statusCode == 200)

      {

        Some(Status.fromXml(XML.loadString(body)))

      }

      else

      {

        None

      }

    }

  }

}

何か質問はあるでしょうか。

別の表示方法

もう少しパターン・マッチングを試してみたいと思う読者のために、リスト 8 は show() メソッドを作成するための別の方法を示しています。

リスト 8. Scitter v0.3: 別の方法で作成する show
package com.tedneward.scitter

{

  class Scitter

  {

    // ...

	

    def show(id : Long) : Option[Status] =

    {

      Scitter.execute("http://twitter.com/statuses/show/" + id + ".xml", 
          username, password) match

      {

        case (200, body) =>

          Some(Status.fromXml(XML.loadString(body)))

        case (_, _) =>

          None

      }

    }

  }

}

この方法が if/else の方法よりも簡潔であるかどうかは美的感覚の問題以外の何物でもありませんが、こちらの方が簡潔だと言えることは確かでしょう。(おそらく、コードを見る人が Scala の「関数型」の部分に注目すればするほど、こちらの方が魅力的だと思うでしょう。)

パターン・マッチングによる方法には、if/else の方法に勝るメリットが 1 つあり、新しい条件 (今までにはないエラー条件や HTTP レスポンス・コードなど) が Twitter から返された場合、パターン・マッチングによる方法のほうが、それらの条件を明確に区別することができます。例えば、ある日 Twitter の仕様が変更され、本体そのものの中に 400 というレスポンス・コードと 1 つのエラー・メッセージを入れて返し、何らかのフォーマット・エラー (例えば Retweet を適切に行わなかったなど) の発生を示すようになったとしたら、パターン・マッチングによる方法のほうが if/else の方法よりも容易にレスポンス・コードと本体の内容の両方をテストすることができ、より明確な結果を得ることができます。

もう 1 つ注目すべき点として、リスト 8 を部分的に適用し、URL とパラメーターのみを必要とする関数を作成することも考えられます。しかし正直なところ、こうしたソリューションは問題を招くことになるので、私は手を出すつもりはありません。


POST を破棄する

実行されたアクションを Scitter のユーザーが取り消しできるようにする必要があるでしょう。そのためには、POST された Twitter 近況メッセージを削除する destroy 呼び出しが必要です (リスト 9)。

リスト 9. Scitter v0.3: destroy
package com.tedneward.scitter

{

  class Scitter

  {

    // ...

	

    def destroy(id : Long) : Option[Status] =

    {

      val paramsMap = Map("id" -> id.toString())

    

      val (statusCode, body) =

        Scitter.execute("http://twitter.com/statuses/destroy/" + id.toString() + ".xml",

          paramsMap, username, password)

      if (statusCode == 200)

      {

        Some(Status.fromXml(XML.loadString(body)))

      }

      else

      {

        None

      }

    }

    def destroy(id : Id) : Option[Status] =

      destroy(id.id.toLong)

  }

}

ここまで完成すると Scitter クライアント・ライブラリーを「アルファ版」と見なすことができ、少なくとも単純な Scitter クライアントならば実装することができます。(私は、著者に特有の思い上がった習慣に従って、この Scitter クライアントの実装を「読者の演習」とすることにします。)


まとめ

Scitter クライアント・ライブラリーの作成は興味深い演習でした。まだ Scitter は完全に本番で使える状態とは言えませんが、単純なテキスト・ベースの Twitter クライアントを実装するためには十分使用可能であり、公開できる状態にあります。このコードを使うと何ができるのか、また、より使いやすくするためにどんな機能が必要かを知るためには、コードを公開することが一番です。

私は Scitter に関する今回の記事と以前の記事のコードを、最初のリビジョンとして、Google Code でホストされる Scitter プロジェクトのホームページに公開しました。このライブラリーを自由にダウンロードして実際に試し、皆さんの意見を聞かせてください。またバグ・レポートやバグ修正、助言なども歓迎します。

皆さんは私のコードベースにこだわる必要はありません。Scitter の開発についての今回までの 3 回の記事を読むことで、Twitter API がどのように動作するかの感覚をつかめたはずです。また、Twitter API の使い方に関して別のアイデアを思いついたら、Scitter を捨て去り、皆さん自身の Scala クライアント・ライブラリーを作成してみてください。そうした、ちょっとした作業をしてみるのも楽しいものです。

では、これで Scitter に別れを告げ、Scala を使って問題を解決するための新しいプロジェクトを探すことにしましょう。それを楽しみながら、Scala での実際的なプログラミングを見つけた場合には、ぜひ私に知らせてください。


ダウンロード

内容ファイル名サイズ
Source code for this articlej-scala10209.zip812KB

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, Open source
ArticleID=446975
ArticleTitle=多忙な Java 開発者のための Scala ガイド: Scitter を使って Twitter を更新する
publish-date=10202009