KotlinのisはJavaのinstanceofだよ

各位

お疲れ様です。 表題の通りKotlinのisはJavaのinstanceofを内部的には使用しています。

以上よろしくお願いいたします。


というわけで、Kotlinのパターンマッチにつかうisが内部的にどのような処理を行っているのかが気になったので調べてみました。 方法としてはKotlinでisを使ったコードをコンパイルしてできたクラスファイルを Javaコンパイラデコンパイルします。

Kotlinのコンパイラのバージョンは'1.3.11 デコンパイラにはCFR v0.139を使用しました。

Kotlinのコード

class A(){
    val a="aaa"
}
fun test(hoge:Int){
    val b= if(hoge==0)A()else null
    if(b is A){
        print("a")
    }else{
        print("b")
    }

}

これをコンパイルして得たTestKt.classデコンパイルした結果が以下のとおりです。

コマンド

java -jar cfr-0.139.jar   out/production/classes/TestKt.class 
/*
 * Decompiled with CFR 0.139.
 * 
 * Could not load the following classes:
 *  kotlin.Metadata
 */
import java.io.PrintStream;
import kotlin.Metadata;

@Metadata([省略])
public final class TestKt {
    public static final void test(int hoge) {
        A b;
        A a = b = hoge == 0 ? new A() : null;
        if (b instanceof A) {
            String string = "a";
            System.out.print((Object)string);
        } else {
            String string = "b";
            System.out.print((Object)string);
        }
    }
}

みごとにinstanceofが登場していることがわかりますね。 Javaではinstanceofを使うのはあまり良くないとされていると思いますが、 Kotlinではスマートキャストのおかげか大活躍していますね。

ちなみにinstanceofの内部の動きに関してはJJUG CCC Fall 2018で発表された方がいて 大変勉強になりました。以下のリンクがその時のスライドです。 参考にどうぞ

Deep dive into instanceof

楽しく見ていただいた方はチャンネル登録お願いします。(?)


追記

スマートキャストが動いている例もやってみました。


sealed class A{
    class B(var num:Int):A()
    class C(var str:String):A()
    class D(var double: Double,var int: Int):A()

}
fun test(hoge:Int){
    val v:A= if(hoge==0){
        A.B(1)
    }else if(hoge==1){
        A.C("1")
    } else {
        A.D(1.0,2)
    }
    when(v){
        is A.B->
            print(v.num)
        is A.C->
            print(v.str)
        is A.D->
            print(listOf(v.double,v.int))
    }

}

逆翻訳後

/* クラス定義は省略します */
public final class TestKt {
    public static final void test(int hoge) {
        A v = hoge == 0 ? (A)new A.B(1) : (hoge == 1 ? (A)new A.C("1") : (A)new A.D(1.0, 2));
        A a = v;
        if (a instanceof A.B) {
            int n = ((A.B)v).getNum();
            System.out.print(n);
        } else if (a instanceof A.C) {
            String string = ((A.C)v).getStr();
            System.out.print((Object)string);
        } else if (a instanceof A.D) {
            List list = CollectionsKt.listOf((Object[])new Object[]{((A.D)v).getDouble(), ((A.D)v).getInt()});
            System.out.print(list);
        }
    }
}

普通にダウンキャストと同じバイトコードになるようですね。

JJUG CCC fall2018参加メモ

JJUG CCC 2018 Fall に行ってきました。 備忘録と生存報告がてらに聴講した発表についてメモ。

www.java-users.jp

会場

西新宿のベルサール新宿グランドコンファレンスセンターに 10:00から開始でした。

うっかり新宿駅から歩いていってしまったので大変な目に会いました。 寒い朝の新宿を歩いて20分位したらつきました。 (西新宿の建物は新宿をなのるな?)

1.Javaの未来を考えよう

1つ目は基調講演のJavaの未来を考えようでした。 ついたのが10:30くらいだったので最後の15分くらいしか聞けませんでした。

中身はいい感じにメモした方がいらっしゃったのでぺたり

最後の15分位は10年位前にSIerがバリバリstrutsを業務で使っていたのに、 コントリビュートをほとんどしないフリーライダーばかりであったみたいな話をしていました。 JJUGというコミュニティを運営している方々はやはりフリーライダーのことを良くは思っていないようで、 JJUG CCCに聴衆として参加するだけじゃなくどんどんコミュニティに貢献していけみたいなことを喋ってらっしゃいました。 (途中でフォローが入って、CCCに参加するようなことも貢献の一つであるという解釈をしていましたが) ほぼ技術情報を表に出せていない自分にとっては耳が痛い話でした。

2.モジュールグラフが作られる様子を学ぼう

モジュールグラフが作られる様子を学ぼう - Qiita

2つ目はJava9から導入されたモジュールシステムに関するお話でした。 正直モジュールグラフという字面を見てJavaのモジュールシステムのことを指していると気づかずになんとなくこの発表を聞いていました。(Java9以上にまだ触ったことがないのです)

モジュールシステムについて全く事前知識がなかったのですが、この発表のおかげでモジュールシステムがどういうふうに動いているかの枠組みがつかめた気がします。

LINE で広告プラットフォームを Java + Golang で立ち上げた話

polyglotなマイクロサービスをどのように構築したか?という話をLINE社内の事例を出して発表されていました。 この発表によると広告関連のシステムは初見の人にはちんぷんかんぷんではあるが、 わりと業界内では構成が統一されているというお話でした。 個人的に気になったキーワードは、サービス感の連携のバッファとして使用しているKafkaとそのスキーマを定義する Apache avroです。 そのうち調べたいと思います。

俺が好きなのはJavaだけどJavaじゃない 〜虎の穴でのJava活用について〜

speakerdeck.com

萌え萌え履歴書が萌え萌えすぎて開くのに躊躇したよかったです。 レガシーなECシステムを自社開発するようになり、エンジニアの採用の一環として?オープンスペースや 他にも様々な取り組みを行っているようです。 気になった人は調べてみよう!

生粋のKotlin LoverによるLINEのKotlinの話

LINE社内のKotlin事例だけだと発表が持たないので 最近のKotlinのアップデート内容やKotlin Confの話をされていました。

自分もKotlinを趣味の開発では使っているのですが いかんせんコルーチンなり新し目の機能を試していないので勉強になりました。 特にInline classesについては普段Javaでやっている開発で同じような機能が欲しくなった場面があったので そのうち試してみようと思います。

複雑なドメインに泥臭く立ち向かう

speakerdeck.com

介護保険という複雑のドメイン周りをどのようにチームで噛み砕いていったかという話を詳細にしてくださいました。 会社でもこのくらいチームで向き合えればもっとドメインの理解が深まりそうだなぁと思う一方、 実際これをどのように自分の労働環境でやっていくか考えるとなかなか前途多難です。

Deep dive into instanceof

個人的に一番面白かったお話でした。 今までJVMの中のコードのことを考えたことがなかったのですが、 この発表でJVMのコードを読んでみたくなりました。 (まずはコンパイルされたあとのバイトコードをみていきたいですね)

GraphQL vs Traditional Rest API

www.slideshare.net

GraphQL Javaのライブラリを使用したコードを実際に動かしながら GraphQLでやれることを発表されていました。 GraphQLの導入で一番インパクトがあるのはフロント側とサーバ側できちんとスキーマを定義することであるという ような話でした。 (Restはサーバ側が用意したAPIの詳細を知り合わせる必要があるが、共通のスキーマを定義することでスキーマにさえ従えば良くなる) 個人的にはGraphQL-javaのライブラリがかなり強力そうに感じました。

Scala とマイクロサービスでつくる証券会社とスタートアップ

speakerdeck.com

社内でscalaの機能をいかに活用して安全で高速に開発を行っているかという話でした。 個人的にはKotlinの発表で知ったinline classが活躍しそうな事例の話をされていて「それKotlinでできるよ」みたいなことで 頭が一杯になっていました。 (発表内ではサービス開始した4~5年前にはサーバサイドKotlinの事例がなかったというフォローをきちんとされていました) その他にもモデリングをどのように行っているかや採用しているFinagle/Finatraの話が参考になりました。 自分は普段の業務では効率的/高速な開発ができるフレームワークを使用していないため、 ある程度揃ったフレームワークを使用した開発もいいなあという感じです。 (Finatraがどのようなスタックを持っているか全然知りませんが)

懇親会

学会の懇親会みたいなめっちゃぼっちを回避して無事1名の方と雑談や情報交換を行うことができました。 次はもうちょっと多くの人と話したいと思います。(こなみ) 最後に集合写真取るの知らなくて20:30に帰ったのはちょっと勿体無かったなと思っております。

まとめ感想

いろいろJava周り(JVM周り?)の話が聞けて刺激になりました。 僕も他の人に刺激が与えられるくらいにはアウトプット力であったりシステム力(ちから)を上げていきたいと思います。 というわけで少しでも貢献になればと思って記事を書いてみましたので、皆さん是非リンク集としてこの記事をお役立ててください。 よろしこっ

参考

・発表スライドがまとまっているページ

GitHub - jjug-ccc/slides-articles-2018Fall: JJUG CCC 2018 Fall 登壇資料まとめ

parcelでelectron向けビルド

parcelでelectron向けビルドするためのオプションについて

手っ取り早いまとめ

parcel watch .\src\index.html --public-url ./ --no-hmr --target=electron

以下詳細

parcelはコマンドなしで実行すると開発用のビルドとhttpのサーブを行ってくれます

parcel hoge.html

本番向けにはbuildサブコマンドを使います.

parcel build hoge.html

ほかにもwatchサブコマンドでビルドだけ行わせることができます.

parcel watch hoge.html

しかしながら,parcelは開発ビルド(デフォルト,watch)をすると(用途は不明ですが) websocketで開発用のサーバと通信を行うコードを出力します. したがって以下のようにelectronと組み合わせて使用すると electronアプリからのページアクセス時にエラーを発行します.

parcel watch hoge.html &
electron dist/hoge.html
// WebSocket': The URL 'ws://:61948/' is invalid エラー発生

この問題をparcelのissueで調べると以下のissueを見つけました. Failed to construct 'WebSocket': The URL 'ws://:61948/' is invalid · Issue #856 · parcel-bundler/parcel · GitHub

したがってparcel watchの際には--no-hmrをつけましょう

parcel watch hoge.html --no-hmr

おわり

おまけ

上記のwebsockの問題以外にもelctronと組み合わせた際にエラーが発生するケースがあります.

絶対パス<->相対パス

electronはデフォルトの設定ではパスを絶対パスでアクセスしようとするとうまく動作しない問題があります. 例: /js/hoge.js 等 (参考: https://qiita.com/tuttieee/items/4123784f1eb68a1d3925) この問題を回避するには参考ページにあるようにfileプロトコルアクセス時のパス解決をインターセプトするか, もしくは初めから相対パスを使う方法があります. parcelはデフォルトではビルド後のファイルのリンクが/から始まる絶対パス指定になってしまいます. この絶対パス指定をやめるために--public-urlを使用しましょう.

parcel watch hoge.index --public-url .

こうするとパスの起点が設定されなくなり相対パスURLが生成されるようになります.

electronのimport

electronを使用する場合,rendererプロセス側のコードから

import  electron from "electron"

というようにelectronのAPIにアクセスするために‘electron‘モジュールをインポートするのですが, このimport文がparcelに解釈されてしまう関係でエラーが発生します. これを回避するために--target=electronをつけましょう.

swagger-codegen テンプレートとロジックのカスタマイズ

swagger-codegenのテンプレとロジックのカスタマイズ

前回の記事から引き続き swagger-codgenをさわっていきます.

今回はswagger-codegen(以下codegen)のカスタマイズ方法を記載します. カスタマイズ方法については以下の記事を参考にしていますが, この記事に乗っていないことをなるべく記述していきたいと思います!

こんなに簡単! Swagger Codegenのカスタマイズ https://qiita.com/Quramy/items/c583f3213f0b77ff1bac

なお最終的なファイル構成をgithubに上げているのでそちらも併せてご確認ください.

既存のテンプレートで動かす

まずはカスタマイズする前にどのような出力が行われるかを確認してみます. 前回の記事にもjarを使用した実行方法を記載していますが,今回はgradleを使用した方法を紹介します.

gradleの準備

gradleは依存解決+ビルドを行ってくれる支援ツールです. jvm系言語のビルドによく使用されますがC++などのビルドにも対応しているらしいです. 公式ページに記載があるように,パッケージマネージャからinstallするのがおすすめです.

macの場合はbrewで,windowsの場合はchocolaty経由でインストールしましょう. (chocolatyはwindows向けのパッケージマネージャです.インストールもinstallにあるスクリプトをcmdに張り付けるだけなのでぜひ導入しましょう.)

 brew install gradle # mac
 choco install gradle # windows

設定ファイルの準備

codegenを実行するためのbuild.gradleを任意のディレクトリに用意します. また生成に使用するサンプルとしてここからサンプルのSwagger定義を取得してswagger.jsonとして保存します

build.gradleはgradle用の設定ファイルです.

plugins {
  id 'org.hidetake.swagger.generator' version '2.12.0'
}

repositories {
  jcenter()
}

dependencies {
  // Add dependency for Swagger Codegen CLI
  swaggerCodegen 'io.swagger:swagger-codegen-cli:2.3.1'
}

swaggerSources {
  example{
    inputFile = file('swagger.json') //swagger定義ファイル
    code {
      language = 'spring'  //生成先のフレームワーク/言語
    }
  }
}

この設定を用意することでgradle-swagger-generator-plugin を利用してcodegenを動作させられます. また同時にgroovyを使用できるようプラグインを設定しています.

実行

以下のコマンドでcodegenプラグインを実行できます.

gradle generateSwaggerCode

これでbuildディレクトリ以下にソースコードが生成されました. 生成対象はbuild.gradlelanguage = 'spring'と設定したため,springbootを使用したサーバサイドのコードが生成されました.

# tree build
build
└── swagger-code-example
    ├── README.md
    ├── pom.xml
    └── src
        └── main
            ├── java
            │   └── io
            │       └── swagger
            │           ├── RFC3339DateFormat.java
            │           ├── Swagger2SpringBoot.java
            │           ├── api
            │           │   ├── ApiException.java
            │           │   ├── ApiOriginFilter.java
            │           │   ├── ApiResponseMessage.java
            │           │   ├── NotFoundException.java
            │           │   ├── PetApi.java
            │           │   ├── PetApiController.java
            │           │   ├── StoreApi.java
            │           │   ├── StoreApiController.java
            │           │   ├── UserApi.java
            │           │   └── UserApiController.java
            │           ├── configuration
            │           │   ├── CustomInstantDeserializer.java
            │           │   ├── HomeController.java
            │           │   ├── JacksonConfiguration.java
            │           │   └── SwaggerDocumentationConfig.java
            │           └── model
            │               ├── Category.java
            │               ├── ModelApiResponse.java
            │               ├── Order.java
            │               ├── Pet.java
            │               ├── Tag.java
            │               └── User.java
            └── resources
                └── application.properties

language='go'と設定してやるとgolang向けのクライアントのコードを生成できます.

# tree build
build
└── swagger-code-example
    ├── README.md
    ├── api
    │   └── swagger.yaml
    ├── api_client.go
    ├── api_response.go
    ├── category.go
    ├── configuration.go
    ├── docs
    │   ├── Category.md
    │   ├── ModelApiResponse.md
    │   ├── Order.md
    │   ├── Pet.md
    │   ├── PetApi.md
    │   ├── StoreApi.md
    │   ├── Tag.md
    │   ├── User.md
    │   └── UserApi.md
    ├── git_push.sh
    ├── model_api_response.go
    ├── order.go
    ├── pet.go
    ├── pet_api.go
    ├── store_api.go
    ├── tag.go
    ├── user.go
    └── user_api.go

カスタマイズしたい対象を見つける

カスタマイズ対象のピックアップ

さて今回のテーマはカスタマイズですが,まずはカスタマイズしたい個所をピックアップします. codegenのテンプレートは様々な言語に対応していますが 中には手で修正しないとビルドに成功しないテンプレートもあります. 今回はcodegenの設定を以下のように設定してコードを生成します.

build.gradle

//抜粋
  example{
    inputFile = file('mytemplate/ninja.yaml') //swagger定義
    code {
      language = 'java' 
      configFile = file('config.json')
    }
  }

mytemplate/ninja.yaml

# 抜粋
definitions:
  Person:
    type: "object"
    required:
    - "name"
    properties:
      id:
        type: "integer"
        format: "int64"
      name:
        type: "string"
        example: "doggie"
      group:
        type: "string"
        description: "pet status in the store"
        enum:
        - "伊賀"
        - "甲賀"
        - "はぐれ"

すると,コンパイルした際に以下のようなエラーが出ます.

 警告: 識別子として'_'が使用されました
    _("伊賀"),

これはEnumクラスの定義として以下のようなコードが出力されているためです.

  /**
   * pet status in the store
   */
  @JsonAdapter(GroupEnum.Adapter.class)
  public enum GroupEnum {
    _("伊賀"),
    
    _("甲賀"),
    
    _("はぐれ");

    private String value;

すこし調べたところ,これはswagger定義にあるEnumを以下のようにEnumの定数名に変換しているためでした.

String var = value.replaceAll("\\W+", "_").toUpperCase();

当該コード

この処理で全角文字をすべて_に変換しているために起きている問題のようです. 今回はこの問題を回避するようなカスタマイズを行います. (ちなみにこの全角をEnumに設定するとうまくコード生成されないのがただのバグなのかSwaggerの定義にEnumに全角を設定してはいけないせいなのかは知りません!だれか詳しい人がいたら教えてください!!!><)

カスタマイズをはじめる

テンプレートのカスタマイズ

codegen参考記事にあるようにテンプレートとそのテンプレートに流し込むデータを作るロジック部に大別されます. イメージとしては以下のような感じです.

(swagger定義yaml)->ロジック部->(中間データ構造)->mustacheテンプレート

language毎のテンプレートファイルはcodegenのリポジトリのresouces以下で確認できます. language=javaの場合のテンプレートはこれです.

さて問題のコードがどのテンプレートファイルから生まれたのかをgrep等を使用して探してみると,どうやらmodelInnerEnum.mustacheが問題のコードに対応するようです.

テンプレートは一部のファイルだけのカスタマイズが可能なため,modelInnerEnum.mustachemytemplate/template/以下に保存し, build.gradleを以下のように設定します. こうすることでもともとのテンプレートをtemplateDir以下の同名ファイルでオーバーライドすることができます.

// 抜粋
  example{
    inputFile = file('mytemplate/ninja.yaml') //swagger定義
    code {
      language = 'java' 
      templateDir = file('mytemplate/template/')
    }
  }

Mustacheの文法に注意しながらテンプレートを適当に編集して保存します.

mytemplate/template/modelInnerEnum.mustache

   public enum {{#datatypeWithEnum}}{{{.}}}{{/datatypeWithEnum}}{{^datatypeWithEnum}}{{classname}}{{/datatypeWithEnum}} {
     {{#allowableValues}}
       {{#enumVars}}
+      // こんなこめんとをいれました
     {{{name}}}({{{value}}}){{^-last}},
     {{/-last}}{{#-last}};{{/-last}}
       {{/enumVars}}

この状態でgradle generateSwaggerCodeをしたら以下のように出力が変化しています.

  /**
   * pet status in the store
   */
  @JsonAdapter(GroupEnum.Adapter.class)
  public enum GroupEnum {
      // こんなこめんとをいれました
    _("伊賀"),
    
      // こんなこめんとをいれました
    _("甲賀"),
    
      // こんなこめんとをいれました
    _("はぐれ");

    private String value;

このようにテンプレートに追加した文字列がそのまま出力されるため, 簡単なカスタマイズであればこのテンプレートのカスタマイズだけで十分目的を果たせると思います.

ロジックのカスタマイズ

さて先ほど

(swagger定義yaml)->ロジック部->(中間データ構造)->mustacheテンプレート

と紹介しましたが,このようにテンプレートに埋め込む中間データ構造の値を変化させたい場合はロジックのカスタマイズが避けられません.

ロジック部のデータモデル

さてロジック部において各プロパティはCodegenPropertyクラスで扱われています.今回はこのへんenumVars.nameを別名で上書きすることにします.

Vender Extensions

ところで,Swagger定義では,Extensionsと呼ばれるx-から始まるカスタムプロパティを様々な項目に設定することができます. こちらの記事では,このextensions(Vender Extensions)を使用して中間データ構造に値を設定し,その値をテンプレートで参照することでカスタマイズを行っています. 今回はこのextension機能を利用してCodegenPropertyに値を渡し,ロジック内で特定のextensionがついていた場合はその値ででEnumの定数名を上書きします.

ロジックの継承とオーバライド

さきほどからlanguage='hoge'のように出力先の名前を指定していますが, ここの設定にはCodegenConfigインターフェースを継承したクラスのFQCN(パッケージ名とクラス名)を指定すればそのクラスを使用してくれます. したがって,カスタマイズしたいクラスを継承したクラスを自分で定義してそれをクラスパスに追加することで,任意の処理を既存の処理に挟み込むことができます.

というわけでlanguage='java'の際に使用されるJavaClientCodegenを継承したクラスをGroovyで定義してコンパイルしてクラスパスに追加して,そのクラス名をlanguageに指定して実行することでロジックのカスタマイズができました. (最終的ファイルをgithubに上げておいたので参考にしてください)

mytemplate/logic/MySwaggerLogic.groovy

import io.swagger.codegen.*;
import io.swagger.codegen.languages.*;

class MySwaggerLogic extends JavaClientCodegen {
    @Override
    public void updateCodegenPropertyEnum(CodegenProperty var) {
        super.updateCodegenPropertyEnum(var)
        if(var.vendorExtensions.containsKey("x-enum-names")){
            def alternames=var.vendorExtensions['x-enum-names']
            def enums=var.allowableValues["enumVars"]
            if(alternames.size()!=enums.size()){
                return
            }
            alternames.eachWithIndex{str,i->
                enums[i]["name"]=str
            }
        }
    }
}

build.gradle

plugins {
  id 'groovy'  // groovyでロジックを記述する際に使用
  id 'org.hidetake.swagger.generator' version '2.12.0'
}

repositories {
  jcenter()
}

dependencies {
  // Add dependency for Swagger Codegen CLI
  swaggerCodegen 'io.swagger:swagger-codegen-cli:2.3.1'
  // groovyのクラスファイルをクラスパスに追加
  swaggerCodegen files('build/classes/main/')
  swaggerCodegen localGroovy()
  // groovyコンパイル用の設定
  compile 'io.swagger:swagger-codegen-cli:2.3.1'
  compile localGroovy()
}

swaggerSources {
  example{
    inputFile = file('mytemplate/ninja.yaml') //swagger定義
    code {
      language = 'MySwaggerLogic' 
      configFile = file('config.json')
      templateDir = file('mytemplate/template/')
    }
  }
}
// swaggerSourceの前にgroovyをコンパイル
swaggerSources.example.code.dependsOn compileGroovy 
//ロジック記述ファイルの場所
sourceSets.main.groovy.srcDirs=['mytemplate/logic']

結果

  /**
   * pet status in the store
   */
  @JsonAdapter(GroupEnum.Adapter.class)
  public enum GroupEnum {
      // こんなこめんとをいれました
    Iga("伊賀"),
    
      // こんなこめんとをいれました
    Kouga("甲賀"),
    
      // こんなこめんとをいれました
    Alone("はぐれ");

    private String value;

想定したとおりにカスタマイズすることができました.

まとめと補足

本記事ではswagger-codegenを使用してコードを生成する方法,そしてテンプレートとロジックのカスタマイズ方法を解説しました.

個人的には前回の記事 にscaffoldingにcodegenを使ってみてはと書いた手前あれですが,用意されているテンプレートによってはいろいろなカスタマイズが必要になるのでなかなか良しあしがあるように感じます.本当に最初だけにとどめてそのあとは直接生成したコードを編集するのが楽な気がします...

補足

  • codegenのテンプレートはバージョンが変わるとところどころ変わっていることがあるので,github等でテンプレートを見る際は手元のcodegenのバージョンに注意してください
  • swagger仕様には2.0,3.0,3.1?の主なバージョンがありますが,codegenの3.0対応はあまり進んでいないらしい上にそれが原因でフォークプロジェクトができているようです

速習プリパラ1クール目

概要

今からプリパラを見直す際に(個人的に思う)見るべき話数を上げていきます. A プリパラシリーズ上必要 B そのクール上は見たほうがいいかも C 正直ちゃんとみてない

1クール目 ソラミスマイル編

1 アイドル始めちゃいました

A 記念すべき一話. みれぃの「プリパラは好きプリ?」は後々多用されるセリフであるが. この時点ではわりとさっらとやりとりされているね

2 約束やぶっちゃダメぷりっ

A らぁらとみれぃのコンビ結成回. みれぃとらぁらの関係性の基礎となるような話なので必須

3 チーム解散?困るクマ~!

C 練習回でもあり,そふぃ初登場?回でもあり, 校長の友達嫌いがわかる会でもある. 急ぎ目であればいらないかな?

4 かしこま!元気 For You

C テニス組,校長,のんが活躍する話 友達との約束うんぬん~みたいな友情な話, 女児アニメにはこういう話が大事ね

5 あたし、そふぃさんと歌いたいワニ!

B そふぃ回. そふぃ,ちゃんこ,こすもが登場する会. そふぃの人格説明回なのでとばすとわかりづらくなるかも. そふぃ勧誘をみれぃが認めた回でもある. ここからしばらくそふぃを追いかける話なので大事かもね

6 異議あり?らぁらがウチにやってきたっぷり!

C みれいの家訪問回. 正直両親はどうでもいいが, 2人が想像するアイドル検事みれい像の画像がシリーズでちょくちょく出てきた気がする. 新曲お披露目会かつMD作成会でもある. みれぃの昔の写真がMDの発想素だったのね(見直して知った)

7 レッドフラッシュを探して・・・

B そふぃ,うさぎ,校長回? 校長が次クールに向けてめっちゃスタンバってますね そふぃとらぁらのからみ2 そふぃとトモチケを交換するので期待させてからの

8 ドキドキ!夏だ!水着だ!プールでかしこまっ♪

C 幼馴染のなお回 シリーズを通してちょくちょくある 仲たがい...いいね 女児アニメ回 あの演説からこの曲であるみたいな気持ちにならないか? みれぃのアイドルは友達も笑顔に~のセリフは12話に使われる

9 ときめきアイドル大集合!

A そふぃとらぁらのからみ3 キュピコン初登場?

そふぃの出自の話なのでみておいたほうがよいかも トモチケ交換で期待させておいてからの

10 秋色ラブリーライブ

C 新しいコーデを考えながららぁらがぼけ倒す会 裏でそふぃの挫折が描かれていて1クール目の終わりまでの土台となるが見なくてもわかるか チーム結成もそふぃに断られるはなし

11 どうする?どうなる!?3人目!!!

B 1クール目終わりに向けて大事 メイキングドラマの振りが次の会で回収される

12 はばたけ、そふぃ!

A ソラミスマイル結成回 みれぃはそふぃのこと嫌いだな? ドロシー&レオナ登場回でもあるし2クール目に必要な話 初3人ライブ

13 空見て笑って・チーム名発表!

A チーム名決定話 ぷりぷりかしこま そふぃとみれぃの話でもある ファルルが出てくる

14 ライバル登場!イゴ、よろしく!!

A シオンが参戦! れっついごー好き ドレッシングパフェ結成回&初ライブ 初見はかなりインパクトあった

15 一触即発?シオンVSみれぃぷりっ!

C シオン回 初ソラミVSドレシではあるが 話は大きく進まない

続く!?

swagger-codegenですわっとscaffoldingせん

こんにちは. 今回は(swagger-codegen)https://github.com/swagger-api/swagger-codegenを使ったりカスタマイズしてみようの会です.

swagger-codegenとは?

リポジトリのへのリンク github - swagger-codegen

Overview This is the swagger codegen project, which allows generation of API client libraries (SDK generation), server stubs and documentation automatically given an OpenAPI Spec. Currently, the following languages/frameworks are supported:

swagger-codegenは,swaggerエコシステムのツールの一つであり, OpenAPI3.0仕様(もしくはSwagger2.0仕様)から, クライアントライブラリやサーバのスタブ, ドキュメントを生成するツールです.

swagger自体とその周辺ツールについては, おおむね知っている前提で話を進めていきます.

swagger-codegenを使う動機

今回はサーバ側コードのscaffoldingを行うことを目的にswagger-codgenを使用します.

リポジトリのreadmeにあるように,基本的にはswagger-codegenで生成したものは プロダクション環境ではドキュメントとクライアントライブラリのみを使用することを想定されています(サーバはスタブのみ)

しかしながら,スタブ生成の出力先言語/フレームワーク一覧を見てみると, 以下のようになっています.

Server stubs: Ada, C# (ASP.NET Core, NancyFx), C++ (Pistache, Restbed), Erlang, Go, Haskell (Servant), Java (MSF4J, Spring, Undertow, JAX-RS: CDI, CXF, Inflector, RestEasy, Play Framework, PKMST), Kotlin, PHP (Lumen, Slim, Silex, Symfony, Zend Expressive), Python (Flask), NodeJS, Ruby (Sinatra, Rails5), Rust (rust-server), Scala (Finch, Lagom, Scalatra)

注目したのは

  • MSF4J
  • JAX-RS: CDI, CXF, Inflector, RestEasy

のように,scafoldingに対応していないフレームワークのコード生成も行ってくれることです. そこで,今回はswagger-codegenでサーバスタブを生成し, そのコードを足場(scafold!)として開発を行っていきます.

やってみよう!

コード生成自体は,Open API仕様のjsonyamlを用意すれば簡単に行えます. 今回はswaggerプロジェクト公式で配布しているサンプルを使用します.

1. OpenAPI仕様のファイルの準備

サンプルへのリンク このリンクから今回使用するサンプルファイルを取得します. 自分で用意する場合は,swagger-editor等のツールを使用して用意するのがいいと思います. ~(ただ正直swagger-editorを使ってもかなり定義する部分があるので結構大変です)~

2. コード生成

コード生成はおおむね2つの方法があります.

  1. swagger-editorで生成
  2. ローカルでビルド or jarを取得して生成

swagger-editorで生成

先ほど紹介したswagger-editorにコード生成機能が実装されています.editorにjson or yamlをはりつけて上部リンクの Generate ServerGenerate Clientから生成対象の言語/フレームワークを選択すれば,生成されたコードがzip圧縮したものが入手できます.

ローカルで生成

swagger-codegenのreadme内getting Startedにあるように,ソースコードを取得してからビルドすることで,実行可能jarを入手できます.ただ,ビルド済みのjarがmavenリポジトリ 上に配置されているため,ここからjarを取得する方が早いです.

コード生成コマンド

jarを取得した後は,以下のコマンドでコード生成ができます.

java -jar swagger-codegen-cli.jar generate -i [swagger.yaml or json]\
   -l [生成対象の言語/フレームワーク] \
   (-o [生成先フォルダ]\)
   (-c [config.jsonへのパス]\)
生成可能言語/フレームワーク一覧表示

生成可能な対象は以下のコマンドでリストを見ることができます

java -jar swagger-codegen-cli.jar langs 
生成対象言語/フレームワーク毎の設定項目表示

生成対象によってはconfig.jsonでオプションを設定できます. 例えばjava-play-framework向けの設定項目を調べるには以下のコマンドを使います.

 java -jar .\hoge.jar  config-help -l java-play-framework
生成結果

実際にコードを生成すると,フレームワークに応じたファイルが出力されます. これら生成されるコードを利用することでmodelやapiのための記述量を減らすことができます.

 java -jar .\hoge.jar  generate  -l java-play-framework -i http://petstore.swagger.io/v2/swagger
.json -o out
[main] INFO io.swagger.parser.Swagger20Parser - reading from http://petstore.swagger.io/v2/swagger.json
...

└─out
    ├─.swagger-codegen
    ├─app
    │  ├─apimodels
    │  ├─controllers
    │  └─swagger
    ├─conf
    ├─project
    └─public

生成されるコードについては生成対象ごとのテンプレート次第です. なので気に食わなかった場合はテンプレートのカスタマイズ,ロジックのカスタマイズを行っていきましょう.

後半(カスタマイズ編)に続く(予定)

参考リンク

nginxのソースコードを読む1

今回はnginxのメインループをたどっていきます。

ソースコードの入手

ソースコードは(ここ)https://nginx.org/en/download.htmlからダウンロードできます。 今回は1.11.2を利用しています。

ソースのディレクトリ構造は以下の通りです。

/
├── core(エントリポイントや内部で汎用的に使用するデータ構造等)
├── event(イベント処理の仕組み)
│   └── modules(イベントを通知する際に選べるシステムコール毎のモジュール実装)
├── http(httpを処理する部分?)
│   ├── modules(ssl, auth, アクセス制限等configで設定するような細かな項目のモジュール)
│   │   └── perl(perlモジュール?)
│   └── v2(不明)
├── mail(メール関係 stmp, imap等)
├── misc(google_perftoolとそのためのc++用の何かがある)
├── os
│   └── unix(ソケットやforkの処理等システムコールを用いる処理)
└── stream(不明)

ここからざっくばらんにnginxのソースコードを読んでいきます。

エントリポイントからメインループまで

nginxはmaster-worker構成のためメインループが複数存在することになりますが、 まずはそれぞれのメインループに入るまでと入ってからの処理を大まかに観ていきたいと思います。

まずnginx起動時、/core/nginx.cのmain関数から実行されます。

//core/nginx.c
main(int argc, char *const *argv){
/* ポインタ作成 */
/* debugとerrorの初期化 */
/* オプションのパース */
/* 各種初期化及びシグナル送信等*/
 if (ngx_process == NGX_PROCESS_SINGLE) {
    ¦   ngx_single_process_cycle(cycle);

    } else {
    ¦   ngx_master_process_cycle(cycle);
    }

    return 0;
}

いろいろ省略していますが、 -vや-tや-s等のすぐに処理が終わる場合でなければ、 上記のngx_single_process_cycleかngx_master_process_cycleが呼ばれます。 single_processは詳細は知りませんがnginxをシングルプロセスで動かすオプションを つけた場合に実行されると思われます。 そこで今回はmaster_processの方に注目して追っていきます。

ngx_master_process_cycleは/os/unix/ngx_process_cycle.cに定義されています。

/os/unix/ngx_process_cycle.c

void
ngx_master_process_cycle(ngx_cycle_t *cycle){
/* 変数の初期化 */
/* シグナル受信時の処理を設定 */
/* プロセスのタイトル等設定 */
 ngx_setproctitle(title);

/* コンフィグの読み取り */
    ccf = (ngx_core_conf_t *) ngx_get_conf(cycle->conf_ctx, ngx_core_module);
/* ワーカプロセスの起動とキャッシュマネージャの起動予約 */
    ngx_start_worker_processes(cycle, ccf->worker_processes,NGX_PROCESS_RESPAWN);
    ngx_start_cache_manager_processes(cycle, 0);

/* masterのメインループ */
 for ( ;; ) {
/* 何か */
sigsuspend(&set);
/* 何か */
if (ngx_reap) {
/* 子プロセスの削減? */
 live = ngx_reap_children(cycle);
}
if (!live && (ngx_terminate || ngx_quit)) {
/* マスタの終了 */
ngx_master_process_exit(cycle);
}

if (ngx_terminate) {
/* 子を終了させる */
/* 省略 */
 if (delay > 1000) {
 ngx_signal_worker_processes(cycle, SIGKILL);
} else {
 ngx_signal_worker_processes(cycle,
 ngx_signal_value(NGX_TERMINATE_SIGNAL));
 }
continue;
}

if (ngx_quit) {
/* 子プロセスへシャットダウンシグナル */
ngx_signal_worker_processes(cycle,
ngx_signal_value(NGX_SHUTDOWN_SIGNAL));

ls = cycle->listening.elts;
  for (n = 0; n < cycle->listening.nelts; n++) {
     if (ngx_close_socket(ls[n].fd) == -1) {
     ngx_log_error(NGX_LOG_EMERG, cycle->log, ngx_socket_errno,
    ngx_close_socket_n " %V failed",
   &ls[n].addr_text);
    }
     }
     cycle->listening.nelts = 0;

    continue;
    }

    if (ngx_reconfigure) {
/* 設定ファイルのリロード */
ccf = (ngx_core_conf_t *) ngx_get_conf(cycle->conf_ctx,
            ngx_core_module);
     ngx_start_worker_processes(cycle, ccf->worker_processes,
    NGX_PROCESS_JUST_RESPAWN);
     ngx_start_cache_manager_processes(cycle, 1);

    /* allow new processes to start */
     ngx_msleep(100);

    live = 1;
     ngx_signal_worker_processes(cycle,
      ngx_signal_value(NGX_SHUTDOWN_SIGNAL));

    if (ngx_restart) {
   ngx_restart = 0;
    ngx_start_worker_processes(cycle, ccf->worker_processes,
     NGX_PROCESS_RESPAWN);
      ngx_start_cache_manager_processes(cycle, 0);
   live = 1;
     if (ngx_reopen) {
/* ログファイルのリオープン */

    if (ngx_change_binary) {
/* バイナリを起動しながら交換 gracefull*/
    if (ngx_noaccept) {
/* 何か */

}
}

これがマスタプロセスの起動時の動きとメインループ内の処理です。 基本的には子プロセスとキャッシュマネージャの起動予約※をした後、 シグナルを受け付けるだけになります。 マスタプロセスが子を制御しかしていないことがよくわかりますね。 ※キャッシュマネージャは常に存在しているわけではないので定期的に起動しているはず

子プロセスの起動

次にngx_start_worker_processesで何しているかを観ます。 ほげ この関数は先ほどと同じ/os/unix/ngx_process_cycle.cに記述されています。

/os/unix/ngx_process_cycle.c

static void
ngx_start_worker_processes(ngx_cycle_t *cycle, ngx_int_t n, ngx_int_t type)
{
/* ログ記入、変数初期化 */
 ngx_channel_t    ch;

 for (i = 0; i < n; i++) {

    ¦   ngx_spawn_process(cycle, ngx_worker_process_cycle,
    ¦   ¦   ¦   ¦   ¦   ¦ (void *) (intptr_t) i, "worker process", type);

    ¦   ch.pid = ngx_processes[ngx_process_slot].pid;
    ¦   ch.slot = ngx_process_slot;
    ¦   ch.fd = ngx_processes[ngx_process_slot].channel[0];

    ¦   ngx_pass_open_channel(cycle, &ch);
   }
}

観ての通りngx_spawn_processを起動したい数だけ実行したのちにチャンネルの設定を行っています。ngx_spawn_processはnginx内部でプロセス生成する際に用いる汎用的な関数です。第二引数に生成したプロセスで実行したい関数へのポインタを指定します。このプロセス生成部については後程取り上げます。 ngx_process_slotは生成したプロセスの通し番号のため生成したばかりのプロセスの情報をchに格納していることになります。(たぶん生成したプロセスの遠し番号だと思う)

ここの子プロセス生成部で着目すべきはとngx_pass_open_channelです。少し追ってみましょう。(※本当か?)

ngx_pass_open_channelは同じ/os/unix/ngx_process_cycle.cにありまぁす

/os/unix/ngx_process_cycle.c

static void
ngx_pass_open_channel(ngx_cycle_t *cycle, ngx_channel_t *ch)
{
    ngx_int_t  i;

    for (i = 0; i < ngx_last_process; i++) {

    ¦   if (i == ngx_process_slot
    ¦   ¦   || ngx_processes[i].pid == -1
    ¦   ¦   || ngx_processes[i].channel[0] == -1)
    ¦   {
    ¦   ¦   continue;
    ¦   }

    ¦   ngx_log_debug6(NGX_LOG_DEBUG_CORE, cycle->log, 0,
    ¦   ¦   ¦   ¦   ¦ "pass channel s:%i pid:%P fd:%d to s:%i pid:%P fd:%d",
    ¦   ¦   ¦   ¦   ¦ ch->slot, ch->pid, ch->fd,
    ¦   ¦   ¦   ¦   ¦ i, ngx_processes[i].pid,
    ¦   ¦   ¦   ¦   ¦ ngx_processes[i].channel[0]);

    ¦   /* TODO: NGX_AGAIN */

    ¦   ngx_write_channel(ngx_processes[i].channel[0],
    ¦   ¦   ¦   ¦   ¦   ¦ ch, sizeof(ngx_channel_t), cycle->log);
    }
}

ここの処理は子プロセスを生成するごとに行われます。 ①既存のプロセスをひとつ取り出す ①-a 自分自身か無効なプロセスな場合continue ①-b 取り出したプロセスと生成したプロセスを引数にngx_write_channel

個々から見たいもの
ngx_write_channel
ngx_spawn_process(ngx_process_slot)
ngx_channel_t

つづく