天領倉敷ScalaでTwitter4Sについて発表してきました
いや、まだリリースはしていないんですけどね。なかなか発表の機会もないことですし、発展途上のぼっちプロジェクトについて6/30に開催された天領倉敷Scalaでお話しさせていただきました。
Twitter4Sについて
Twitter4JのScalaラッパです。Scala上でJavaのライブラリがそのまま使えることもあってライブラリの層としては非常に薄いですが、以下の点に気をつけて作っています。
- Twitter4Jの利点(特にタイプセーフな面)はそのまま残す
- APIをScalaのコードで使ったときに違和感がないものにする
- ライブラリが提供するAPIやクラスにScalaの利点を活かす(case classなど)
つまり、とりあえず「ラップして動くよ」レベルではなく、ちゃんと「Scalaのライブラリとして意識して設計されたAPIを提供する」ことを目標としています。自分自身のScala力がまだまだなところがあって、2点目3点目に関してはまだまだ設計の余地があります。
発表について
コードの各論について深い議論ができるほどプロダクトコードの量はありません。今回はせっかくなので、ライブラリの設計で迷ってる以下の部分について参加者の皆さんと一緒に議論させてもらいました。
1について。
Twitter APIでは指定可能なパラメータパターンでもTwitter4Jでは対応していないパターンがあります。これらについてTwitter4Sで対応した方が良いのかどうか、という話題です。対応しようとすると、Twitter4JではAPIメソッドを提供していないため、ライブラリのより深いところまで潜る必要があります。
皆さんからは以下のような意見をいただきました。
- Twitter4Jも使わないと思ったから対応しなかったんじゃないの？
- 多分そこに労力をかけるより特に利用頻度が高いものにしぼった方が使い勝手が良くなりそう
- ライブラリ同士の依存関係が強くなりすぎる
議論をした結果、「Twitter APIのパラメータ優先順位で対応できるパターン以外は例外で委員じゃないか？」という結論になりました。「もし、パターンが必要だったら、pull requestで受ければ良いじゃん」ともww
2については、ライセンスは継承した方が面倒ごとが少ないという意見をいただきました。
3については、よりScalaっぽいライブラリを目指すための話題です。以下のような意見をいただきました。
- 引数にOptionはあまり使わない(戻り値に使う)
- 現状メソッドのエンドポイントはTwitter4Jをまとめたものだが、Scalaから使う際に使い勝手の良いAPIかどうかは議論してみる価値があるのでは？
確かに、Twitter4Jの単なるラップからScalaで使いやすいライブラリに一皮むけるためにはその辺りを本気で考える必要がありそうです。ScalaをドメインとするDSLを作る感覚でしょうか。今回こうやってプロジェクトの宣伝をすることで、コードがより多くの人の目に触れることになるでしょうから、見ていただいた人の意見などがもらえると嬉しいですね。
まとめ
ScalaってJavaのライブラリをシームレスに扱えるんで、当然Twitter4JもScalaのコードの中で普通に扱えます。そういう意味では、そのまま使えるものをわざわざScalaで自然な形にラップしているライブラリの存在価値というかニーズについて若干懐疑的なところがあったのですが、思ったよりも期待をかけていただいて嬉しい限りです。
10月くらいにまた天領倉敷Scalaを開催するらしいので、そのときには完成というかリリースの報告ができるようにがんばります。
Twitter4Sのリポジトリ：https://github.com/Shinsuke-Abe/twitter4s
発表の資料：https://docs.google.com/presentation/pub?id=1V_gcljDnqy3h-ggBW8nfH3YP8fdKrFbtRZx6wsp8dlM&start=false&loop=false&delayms=3000
