クラスを作ることをサボらない
JJUG CCC 2018 Fallのいくつかのセッションで型についての話があったので書きたくなった。
この話はJavaやScalaみたいな静的型の世界の思想で、多分Rubyとかでは違う思想だとおもう。
Javaを書いてるときのおれきゅーの脳内
型を定義して取りうる値を狭めることで 間違った使い方ができないようにする ことを最初に考えてる。多分。防御的プログラミングってやつなのかな?しらんけど。
とにかくエラーはより早いタイミングで見つかるほうが良くて、実行時よりコンパイル時にわかるほうが便利だし、コンパイル時よりエディタ上でリアルタイムに分かるほうがもっと良い。
たとえば汎用的な型を使うとこんなミスがあり得る。
long id = 10; new User(id); new Item(id);
静的型なら多分こうかけるほうが間違えなくて嬉しい。
Id<User> id = Id.of(10); new User(id); new Item(id); //コンパイルエラー
型に意図をもたせる
これはirofさんのセッションに出てきた話で、突然String str
という変数が出てきたとき、これが何なのか、どんな操作が許されているのかがわからない。Stringという型には文字列以上の情報が含まれていなくて、splitしたりsubstringできたりする。仮にこれがDisplayNameという型であれば、splitやsubstringなんて操作はないし、表示用に整形するだとかDisplayNameとしての操作だけが提供されて間違えることはない。
コンストラクタやfactoryメソッドで入力値をチェックすることで例えば空文字の場合はインスタンス化できないようにすると、DisplayNameの取りうる値の範囲が制限されてDisplayNameを扱うときに考えなければいけないことを減らすことができる。
Railsにはcomposed_ofというあまり使われていないマイナーな機能があってそれを好んで使っている。これはDBのカラムの値を値にマッピングする機能で、JPAでいうEmbeddedと同じような機能。Rails界隈であまり使われていない機能でも好んで使うのは取りうる値の制限ができるという理由から来ている。
宣伝ですが、composed_ofについては技術書典5で頒布した「pixiv PAYの薄い本」で書いてある。ちなみに表紙は僕が一番好きなイラストレーターのしらたま先生です。
Folioという証券会社のScalaの事例では、金額などの計算に型を使うことでうまく意図をもたせていた。
val yen = JPY(100) yen * 5 // JPY(500) yen * yen // JPY同士の掛け算は定義していない。そんな意味不明な計算はありえない。 yen / 5 // 割り算とかもありえないのでコンパイルエラー
これはわかりやすい例なのでそんなことでミスしないだろうと思いがちだが、ドメイン知識が複雑になると力を発揮する。
別の例で、損益と損益の引き算の例では以下のようなコードが示されていた。
/** 実現損益と含み損益をあわせて損益 */ case class PnL(unlialized: UnlializedPnl, realized: RealizedPnl) { /** 損益の差は損益ではなく損益の差 (例えば前日比)*/ def -(other: PnL): PnlDiff = PnlDiff(this.value - other.value) def value: JPY = unlialized.value + realized.value }
計算結果の型によって計算の意図が読みやすくなるし、型が明確に分かれることで取り違いがなくなったり、気をつけたり意識することの脳内リソースを開放できる。
クラスはどれだけ作れば良いか
別の概念のものなら息をするように作る細かく分ける。
名前考えるのは面倒だけど、作るのは一瞬。ずっと使うものだしどんどん作ろう。プリミティブは滅ぼそう。
とにかく最初はやりすぎかな?って思うくらいやればいい。分けるのは大変だけど統合は簡単。しらんけど。とりあえずやってから考えよ。
おれきゅーのコードを書くときの心構え
息をするようにクラスを作る。名前を決める。
クラスを作るのをサボらない。
参考
コードをどまんなかに据えた設計アプローチ - Speaker Deck
Scala と Microservices でつくる 証券会社とスタートアップ / FOLIO in JJUG CCC 2018 Fall - Speaker Deck
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を作る場合はとりあえず入れておけば良いと思いました。