Retrofitの仕組みを知ろう
はじめに
Javaアドベントカレンダー5日目担当の null です。
Javaのライブラリやフレームワークで登場するアノテーションは、メソッドやフィールドにつけるだけで値が勝手に入ってきたりして魔法のように思うかもしれません。今回はHTTP ClientのライブラリであるRetrofitを題材にアノテーションがどのように使われているか調べてみましょう。
Retrofitのざっくりした動き
ドキュメントのサンプルからコードを引用します。
ライブラリの利用者はGitHubのAPIを叩くインターフェースを用意します。
public interface GitHubService { @GET("users/{user}/repos") Call<List<Repo>> listRepos(@Path("user") String user); }
Retrofit#createにインターフェースのClassクラスを渡すとインスタンスが取れます(!)
Retrofit retrofit = new Retrofit.Builder() .baseUrl("https://api.github.com/") .build(); GitHubService service = retrofit.create(GitHubService.class);
以下のようにGitHubServiceのメソッドを呼び出すとなんとAPIを叩いて結果を返してくれます。
Call<List<Repo>> repos = service.listRepos("octocat");
実装を用意していないのにインスタンスが作れてしまったり実装ができていたりして不思議ですね!
魔法の正体を追う
Retrofit#createの実装を覗いてみましょう
return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class<?>[] { service }, new InvocationHandler() { private final Platform platform = Platform.get(); private final Object[] emptyArgs = new Object[0]; @Override public Object invoke(Object proxy, Method method, @Nullable Object[] args) throws Throwable { // If the method is a method from Object then defer to normal invocation. if (method.getDeclaringClass() == Object.class) { return method.invoke(this, args); } if (platform.isDefaultMethod(method)) { return platform.invokeDefaultMethod(method, service, proxy, args); } return loadServiceMethod(method).invoke(args != null ? args : emptyArgs); } });
Proxy.newInstanceが怪しそうですね!Java SEのクラスなのでProxyクラスのJavadocを読んでみましょう。
Proxy (Java SE 11 & JDK 11 )
Proxyクラスはプロキシクラスというインターフェースのインスタンスのように振る舞うインスタンスを作るメソッドを提供しています。第二引数のインターフェースを実装したプロキシクラスを作り、プロキシクラスのメソッドが呼び出されると第三引数のInvocationHandlerのinvokeメソッドが呼び出されます。
InvocationHandler#invokeにはプロキシクラスのインスタンス、呼び出されたMethod、メソッドに渡された引数が与えられるので、リフレクションを駆使しつつ処理を行い結果をreturnすればRetrofitの完成という仕掛けでした。
その他のアノテーションが使われる場面
アノテーションは今回のようなリフレクションで使われるだけでなく、アノテーションプロセッシングというコンパイル時にコードを生成する仕組みでも利用されます。
代表的なライブラリだとLombokやDomaなどが有名だと思います。アノテーションプロセッシングはリフレクションと違ってコンパイル時に処理するためエラーをより早いタイミングで警告することができるメリットがあります。
おわりに
Retrofitを通じて魔法のようなアノテーションの裏側の仕組みの理解が進むと嬉しいです。
明日は@hishidamaさんの「Asakusa Frameworkと次世代データ処理基盤技術」です。
いつも灰色のページお世話になってます!ありがとうございます!
お絵かき入門
はじめに
エンジニアをやりつつ絵を描き始めてからもうすぐ2年目になるし、上達してきた感じがするので2年前の自分と同じくキャラクターの絵を描きたい!という人のために情報をまとめてみようと思ったので、やってみたいぞ!という人は参考にしてもらえると!
ちなみに2年での成長はこんなかんじ。
対象
絵を描き始めたいけど何から手を付けていいかわからない人
道具を揃える
ペイントソフトとペンタブor液タブが必要。
ペイントソフトはCLIP STUDIOとSAIがあります。好みで選べば良いと思いますがCLIP STUDIOは機能が豊富で、SAIは描き味が良いというイメージです。ちなみに僕はCLIP STUDIOを使ってます。
pixivのプレミアムになればCLIP STUDIOがもらえるので、プレミアム会員の人はそれを使っても良いと思います。
ペンタブに関しては大体ワコムのものを使っておくと良いと思います。液タブはすごくお値段がするので、最初は手を出さないほうが良いかと思います。ipad proがあればそれでやってみるのもいいかも。
キャラの描き方を覚える
いくつか入門サイトがありますが、最初はpixiv senseiのキャラクターコースから始めました。特に顔の基本コースをずっと頑張るって感じですね。これだけでは結構難しいところもあるので入門書の力も借りましょう。
おすすめの入門書はヒロマサのお絵かき講座<顔の描き方編>です。ヒロマサ先生のシリーズはかなりわかりやすく解説してあるのでおすすめです。
ある程度顔の描き方を覚えると髪や目の描き方が気になってくると思うので、tips系のサイトを見ながらやっていくと良さそうです。
自分が見てたサイト
好きな絵描きさんの絵を観察する
好きな絵描きさんを目標に、どうやったら髪が柔らかく見えるか、顔はどんな輪郭になっているか、パーツのバランスはどうかを観察しながら自分の中で噛み砕いて絵を描いてました。
絵を投稿してモチベーションを保つ
はじめの頃はリアクションがもらえなくて辛かったので、リアクションが貰えそうなところに絵を投稿しました。
Twitterやpixiv Sketchですね。とくにpixiv Sketchははじめの頃でもリアクションがもらえるのがすごい嬉しくてモチベーションに繋がりました。
最後に
続けてたらなんか成長するので最後は継続力なのかなーと思います。あとはpixiv sketchのライブなどで上手い人がどうやって描いてるか見ると勉強になるかも!とか思いました。
こういう絵描き系の記事って需要あるのかな?w
気が向いたらまた書くかもしれないです
SpringFoxを使ってみる
最近仕事でSpringBootを使う機会ができたのでSpringFoxを使ってみました。
REST APIを作ったとき殆どの場合でそのAPIのドキュメントを用意する必要があると思います。大体の場合はSwaggerを使うと思うのですが(Railsのときはそうでした)これを手書きするのはかなり手間です。
特にエンジニアにとってドキュメントを書く作業は退屈なはずなので自動で作って欲しいですよね。Railsでは難しかったのですが、偶然にもJavaは静的型付けの言語なので(最高ですね)型からいい感じにドキュメントを作れそうです。
SpringFoxを使ってみる
build.gradleで以下の依存関係を追加しましょう。残念ながらstarterはないようです。
implementation('io.springfox:springfox-swagger2:+') implementation('io.springfox:springfox-swagger-ui:+')
あとはちょっと設定を追加すれば出来上がりです。
@SpringBootApplication @EnableSwagger2 // <- これと public class MyApplication { public static void main(String[] args) { SpringApplication.run(MyApplication.class, args); } // このBean @Bean public Docket document() { return new Docket(DocumentationType.SWAGGER_2).select().paths(PathSelectors.any()).build(); } }
/swagger-ui.htmlにアクセスすればSwaggerの画面が見れるはずです。このパスを変更する方法は調べましたが、提供されてなさそうです。
情報を増やす
APIのパラメータとレスポンスについては自動的に作ってくれますが、APIの説明がないので付け加えたいですね。
handler methodにアノテーションを書くことで説明を追加することができます。
@ApiOperation("ここにAPIの説明") @ApiResponses({ @ApiResponse(code = 400, response = ErrorDetails.class, message = "エラー時のレスポンス") }) @GetMapping("/hoge") public HogeResponse hoge(@RequestParam(value = "page", defaultValue = "1") int page) { ... }
手軽に使えるのでAPIを作る場合はとりあえず入れておけば良いと思いました。
Doma2環境の中間テーブルを考える
Doma2環境でレコードを削除するときに中間テーブルをどう扱うか悩んだのでそのメモ。
悩んだ状況
上のようなテーブルで、repositoriesのレコードを削除するときのことを考える。
repositoriesにはlanguages、frameworksの間に中間テーブルが存在していて、一緒に削除しないと外部キー制約に引っかかってエラーになる。
repositoriesを削除する前にこの中間テーブルを削除しなければならないが、Doma2ではsqlファイルに複数のSQL文を書くことができないので何かしらの方法を考える必要がある。
考えられる選択肢
カスケードを使う
中間テーブルの外部キーにON DELETE CASCADE
をつけてrepositoriesのレコードを削除したときに一緒に削除できるようにする。
DB側で頑張るのでアプリケーションコードがすっきりする。ただし、テーブルA -> B -> C -> Dのように伝播が広がりすぎると手がつけられなくなる可能性がある。ちょっとこの辺は経験不足なのでどうなるかわからない。
アプリケーションコードで頑張る
中間テーブルのDaoを作ってアプリケーションコードで削除するようにする。アプリケーションコードがつらくなる。面倒。
メリットとしてはDBのマイグレーションよりはアプリケーションコードのほうが変更が容易であること。
JOINして削除する[ボツ]
これは試してボツになった案。調べてみて知ったが、joinして複数のテーブルをまとめて削除できるらしい。
Document のMulti-Table Deletes
参照
以下のようなSQL1発で解決できると思ったが外部キー制約に引っかかってダメだったのでボツ。
delete repositories, rf, rl from repositories join repository_frameworks rf on repositories.id = rf.repository_id join repository_languages rl on repositories.id = rl.repository_id where repositories.id = /*repo.id*/2
カスケードを使うことにした
アプリケーションコードがシンプルになる・カスケードに関してはテストである程度担保できるという理由で選択。
カスケードの伝播が広がりすぎて手がつけられなくなりそうになったら撤退する予定。