RubyKaigi2019タイムテーブル徹底解説聞きかじりメモ

先日RejectKaigiに行って参りました!

pixiv.connpass.com

目玉企画として目前に迫ったRubyKaigi、オーガナイザーの松田明さんと高橋会長によるRubyKaigi2019タイムテーブル徹底解説があったので、できる限りメモしたものを書かせていただきます。
メモできなかったところがたくさんあるのでつっこみ歓迎です🙇
(大変恐縮ですが、敬称略です)

ざっくりTrack説明

  • TrackA: Rubyの処理(言語系)
  • TrackD: 日本語でその他の話
  • TrackB&C: 国際色豊かなその他いろいろな話

一枠凡例


10:00-11:10

  • Yukihiro "Matz" Matsumoto: 今回こそはテックな話
  • 登壇者名: コメント
    • 上から順に、TrackA/B/C/Dの順

Apr.18 - Days.1

09:00-10:00

受付


10:00-11:10

  • Yukihiro "Matz" Matsumoto: 今回こそはテックな話

11:20-12:00

  • Matz & the Ruby Core Team: Ruby開発チームからの正式なアナウンス!目玉のひとつ。

12:00-13:30

ランチタイム


13:30-14:10

  • Takashi Kokubun: Railsアプリがどうなるか(Railsがはやくなった!なはず)
  • Maciej Mensfeld: RubyGems.orgが乗っ取られた話が記憶に新しいなか、セキュリティの便利なツール作ってきましたみたいな話!
    「予言してたみたいですよね」
  • ITOYANAGI Sakura: Pure Rubyのなにか…(メモしきれずorz)
  • ota42y: Swaggerの次のバージョンであるOpenAPI3のお話

15:00-15:40

お昼休憩


14:20-15:00

  • Koichi Sasada: VMのなかのほうをRubyですこしだけ書くといろいろいい話
  • Nate Berkopec: マルチスレッドとかProcessとかチューニングとかの理屈(セオリーと実例)
  • Giovanni Sakti: コンテナマネージャを自作した話
  • joker1007: Rubyの黒魔術を使ってRubyを限界まで拡張するお話

15:40-16:20

  • Yusuke Endoh: Rubyの型付けの話、型をつけるためにRubyをごにょごにょする
  • Alexander Ivanov: Rubyなのに型安全なトランスパイラ的な、タイプスクリプト的な
  • Genadi Samokovarov: WebConsoleの作者、PureRubyでデバッガがかけるぞ!て話
  • Yoh Osaki: Rubyで日本語を自然言語処理(チュートリアルっぽい話から)

16:30-17:10

  • Samuel Williams: 一番新しいRubyコミッター、Fiber周りのコードをすごくはやくした人
  • Matthew Draper: Railsコミッター、bundlerが遅い!ってBundler Alternativeのご提案
  • Paolo Perrotta: メタプロRubyの著者、最近DeepLearning本を書いたのでその話。イントロダクション的な話になると思います
  • Shizuo Fujita: RMagickメモリリークとか直して大分よくなったのでRubyKaigiまでに無事リリースして新しくリリースした話にしたい

17:20-18:00

  • Kazuki Tsujimoto: Ruby2.7にパターンマッチングを入れるぞ、という話。RubyKaigiに間に合うかは別として、2.7では確実に入ります
  • Alex Wood: AWSの中のひと、AWS lamdaのご紹介
  • Shawnee Gao: GraphQLをメタプロを使うとよいよという話、おそらく一番アプリよりな話。Squareで使われてる話
  • Aaron Patterson: 日本語です(笑)

Apr.19 - Days.2

08:30-10:00

朝食


10:00-11:10

  • nagachika: ながちかさんならではな話

11:20-12:00

  • Sam Phippen: RSpecメンテナ、RSpecの中の人
  • Noah Gibbs: (メモ取れずorz)
  • Hitoshi HASUMI: mruby/cのファームウェアをごにょごにょする話、アプリケーションの作り方
  • Kouhei Sutou・Kazuma Furuhashi: CSVが早くなった話ともっと早くなる話

12:00-13:30

ランチタイム🍜


13:30-14:10


14:20-15:00

  • Jake Zimmerman・Paul Tarjan: (メモ取りそこね😇)
  • Michael Grosser: parallelとかparallel_testsとかいろんなGemのメンテナ。CoverageGemのご紹介
  • WorkShop: おやつを食べながらRubyでDataでWorkでShop。15:40までぶち抜き枠。
  • Shugo Maeda: Rubyテキストエディタ

15:00-15:40

おやつたいむ


15:40-16:20

  • Vladimir Makarov: light weightなJITのご紹介
  • Amir Rajan: 任天堂Switchのゲームをmrubyで作った話
  • Alex Rodionov: Seleniumの中の人、どのテストコードとどのプロダクションコードが紐付いているかを覚えておいてリグレッションテストを早く(無駄なく)回す
  • Uchio KONDO: RubyでコンテナでCRIU(Checkpoint and Restore In Userspace)な話

16:30-17:10

  • Emily Stolfo: ElasticSearchの中のひと、ベンチマークやパフォーマンスや現場な話
  • Kevin Menard: ChromeのDevtoolでRubyデバッグできたらよくない?って話
  • Mike McQuaid: homebrewのメンテナ、中の人、バージョン2.0のお披露目
  • Tanaka Akira: RubyDSLといえばrakeだけど、なんでlanguageって特別扱いされてるんだろう?DSLって何?って話

17:20-18:30

LT: いろんな人が話します

Apr.20 - Days.3

08:30-10:00

あさごはん


10:00-11:10

  • CRuby Committers: ぐだぐだっとやります

11:20-12:00

  • Yurie Yamane(team yamanekko)・Masayoshi Takahashi: mrubyのお話
  • Ariel Zelivansky: (ききとりそこね🙈)
  • Justin Searls: RubyConfっぽいすごくいい話
  • Sangyong Sim: Oneshot coverageで実際に使われていないコードを5万行以上もりもり消した話

12:00-13:30

ランチ🍜


13:30-14:10

  • Soutaro Matsumoto: (🙇)
  • Charles Nutter, Thomas E Enebo: Rails6について、唯一のRails
  • Colin Fulton: Apple2でRubyがうごくんですよ!て話(超絶技巧プログラミング的な話がきけるのでは)
  • Go Sueyoshi: いろんなAPIを作ってきたのでその話

14:20-15:00

  • Hiroshi SHIBATA: RubyGemsの未来に対する明るい話
  • Kevin Deisz: プレ実行のパフォーマンス
  • ワークショップ: おやつたいむ、おやつはこの部屋にデプロイされて15時40分までぶち抜きです
  • Sadayuki Furuhashi: MessagePack(世界最速ObjectProtocolPack)Rubyのコードをカリカリにチューニングする話

15:00-15:40

おやつたいむ


15:40-16:20

  • Kenta Murata: pluckが2〜3倍早くなっちゃう話
  • Tung Nguyen: lamdaで動くすごいRailsみたいなものの話
  • Tatsuhiro Ujihisa: Rubyのローカル変数が面白いので40分ローカル変数の話
  • nobu: RubyにTimeにzoneをもたせるように拡張ライブラリとコアの共存について考えたい話

16:30-17:10

  • Urabe, Shyouhei: returnのメモリアロケーションとかの話…???
  • Petr Chalupa: TruffleRuby
  • Colby Swandale: 未来のbundlerの話
  • Naotoshi Seo, Yusaku Hatanaka: GPU使ってDeepLearningが早くなるのをRubyでやる

17:20-18:30

  • Jeremy Evans: rodaとか早いアプリを書くのが好きなひと、Keynoteだけどテックな話

松田さん「告知が足りてないんですけど、パーティは結構追加してるんで、数時間おきにみてください

誰かの参考になると幸いです!

Dartのコンストラクタでインスタンスメソッドを上書いてインスタンス変数を変更したかった(未解決)

タイトル通りなのですが、結論から言うと、現時点ではできないと思います。

きっかけはありがちなこんなコード。

class AwesomeButton extends RaisedButton {
  int _index = 1;
  AwesomeButton()
      : super(
            child: const Text('Awesome!'),
            onPressed: () {
              print(_index);
            });
}

タップする度にインスタンス変数を増やすボタンを作りたいな、と思ったものの、とりあえず通ることを確認しようとprintしただけでコンパイルエラー。

Only static members can be accessed in initializers.

staticにすればビルドは通りますが、インスタンス変数で持ちたい。
調べたところ、次のようなIssueがあがっていました。

Allow read-only access to initializing formals. - GitHub

この問題みんな困っていたみたいで各所からリファレンスされているのですが、タイトル通りread-onlyでコンストラクタ内でインスタンス変数へのアクセスを許可したよ、とのこと。
具体的には次のような変更だったようです。

  • The grammar is unchanged.
  • An initializing formal this.x of a constructor C introduces the name x into a scope that covers C's initializers, but not the body; it is considered to be a final parameter.
  • The semantics of such an initializing formal access is that it accesses the parameter, not the field. This matters because the initializing formal may be captured by a function expression, and the field may be updated.
  • 文法は変更なし。
  • this.xの形でコンストラクタに渡せるようにはしたけど、コンストラクタのボディでは渡せないよ。
    (渡す値はfinalのパラメータを渡す想定だよ)
  • こういうinitializeする時にアクセスするのってfieldじゃなくてparameterなはずだよね。
    functionを渡してfieldを上書けるようにしちゃう問題を起こすかもだからこうしてるよ。
    ※ 超意訳かつふんわり理解なので、間違っていたらご指摘ください。

つまり、こういうことはできるようになりました。

class AwesomeButton extends RaisedButton {
  int _index = 1;
  // 引数にthis.xの形で値を渡せる
  AwesomeButton(this._index)
      : super(
            child: Text('Awesome!'),
            onPressed: () {
              print(_index);
            });
}
class C1 {
  final int x;
  // 単独でもセットできるし
  C1(this.x);
}

class C2 {
  final int x;
  final int y;
  // コロンの後でも代入できるし
  C2(this.x) : y = x + 1;
}

class C3 {
  int x;
  // ボディでも渡せる
  C3(this.x) { x = 100; }
}

class C41 {
  int y;
  int z () {
    return y;
  }
  C41(this.y);
}

class C42 extends C41{
  int x;
  int y;
  // スーパークラスのコンストラクタにも渡せる
  C42(this.x, this.y) : super(y){
    x = 100;
  }
}

けれども、スーパークラスのコンストラクタにファンクションを渡すとエラーになる

class C51 {
  int y;
  int z() {
    return y;
  }

  C51(this.y, this.z);
}

class C52 extends C51 {
  int x;
  int y;
  C52(this.x, this.y)
      : super(y, () { print('hello'); });
}

// => 'z' isn't a field in the enclosing class.エラー

RaisedButtonのサブクラスみたいにプロパティとして渡す場合は上書けるけど、「setterが無い」と怒られる。

class AwesomeButton extends RaisedButton {
  int _index;

  AwesomeButton(this._index)
      : super(
            child: Text('Awesome!'),
            onPressed: () { _index = 10; });
}
// => Setter not found: '_index'.

setterを作ってもだめ。

class AwesomeButton extends RaisedButton {
  int _index;
  void get index => _index;
  void set index(suuji) => _index = suuji;
  AwesomeButton(this._index)
      : super(
            child: Text('Awesome!'),
            onPressed: () { index(10); });
}

// => Only static members can be accessed in initializers.dart(implicit_this_reference_in_initializer)
// => The expression here has a type of 'void', and therefore cannot be used.
// (※ setterはvoidである必要がある)

というわけで調査した結果、ほとほとつかれはてて「Flutterはコンストラクタでインスタンス変数を上書きするようインスタンスメソッドを定義できない」という結論になったのでした。
冒頭で引用した通りの思想なのだと思いますが、ほんとうにつかれました。。。。。

analysis_options.yamlをカスタマイズする(3)

analysis_options.yamlのカスタマイズ、3回め。
今日はerrorsについてです。

公式ドキュメントはこちら

さて、analysis_options.yamlが面白いなと思うのは、チェック基準を厳しくもできるし、ゆるくもできるところ。

analyzer:
  errors:
    missing_required_param: warning
    missing_return: warning
    todo: ignore
    sdk_version_async_exported_from_core: ignore

errorsに続けてオプションを記述し、[warning, error, info, ignore]を記述することで、チェックツールの挙動をカスタマイズすることができます。

info
An informational message that doesn’t cause analysis to fail. Example: todo
(ざっくり訳) コンパイルエラーを起こさないインフォのこと。 ex. todo

warning
A warning that doesn’t cause analysis to fail unless the analyzer is configured to treat warnings as errors. Example: analysis_option_deprecated
(ざっくり訳)アナライザーがワーニングをエラーと捉えなければコンパイルエラーを起こさないワーニングのこと。ex. analysis_option_deprecated

error
An error that causes analysis to fail. Example: invalid_assignment
(ざっくり訳)コンパイルエラーを起こすエラーのこと。ex. invalid_assignment

たとえばmissing_required_paramsrequiredのプロパティを設定しないとウィジェット(画面)の描画時にエラーが発生するけど、コンパイルエラーは起こさない(warning状態)。

// Paddingはpaddingプロパティが必須(required)
// 指定しないとコンパイルは通るけど、描画しようとすると例外が発生する
Padding hoge() {
    return Padding(
      child: Text('Hello, World!'),
    );
  }

これをerrorに指定すると、同じ記述でもアナライザーがエラーを表示してくれます。 (エラーは表示されるだけで、コンパイルは通ります)。

analyzer:
  errors:
    // errorを指定するとエラーとして表示されるようになる
    missing_required_param: error

missing_returnreturnを記述していない場合の挙動。
ウィジェット生成のファンクションはreturnを指定しなくても動くのですが、明示的にわたすほうが好ましいようです。

ということで今日はここまで、また明日続きからやっていきます!

analysis_options.yamlをカスタマイズする(2)

昨日の続きで、analysis_options.yamlの項目たちの説明です。 昨日の復習も含めて書いてゆきます。

analyzer:
  strong-mode:
    implicit-casts: false
    implicit-dynamic: false

動的型付け・型のキャストを許可する項目です。どちらもデフォルトはtrue
動的型付け・型のキャストを禁止したい時のみfalseで指定します。

implicit-casts: false

暗黙的な型変換を許可しない設定。

Object o = 'hoge';
String s = o;

ObjectクラスのインスタンスoStringクラスの変数sに代入しようとすると文字列をStringに入れるのでコンパイルは通るのですが、implicit-casts: falseに反して暗黙的な型変換が行われるのでアラートが発生するようになります。
アラートを避けるには、型変換が行われないよう変数の型を揃える必要があります。

String o = 'hoge';
String s = o;

implicit-dynamic: false

動的型付けを許可しない設定。
castsは型変換禁止なので、ObjectStringとなると静的型付だけどアラートが出るし、dynamicは動的型付け禁止なので、型をつけていないとアラートが出るという感じですね。

抜けがちなのは配列やオブジェクトの時かなと思いました。それぞれ要素の型を指定する必要があります。

// 1. hogeはListだけど、Listの中身を指定していないのでアラートが出る
final List hoge = ['hoge'];

// 1. Listの中身をジェネリクスで指定するとアラートが解消される
final List<String> hoge = ['hoge'];

// 2. MapのListだと指定しているけど、Mapの中身を指定していないので
// Missing type arguments for map literalアラートが出る
final List<Map> hoge = [{'fuga': 'piyo'}];

// 2. Mapの要素の型を再帰的に指定するとアラートが解消される
final List<Map<String, String>> hoge = [{'fuga': 'piyo'}];

// 3. 明示的にvarを指定するとアラートは出ない
var hoge = ['hoge'];

// ちなみにそもそもvarと型は共存できない(analysis_options.yamlによらず)
// これはコンパイルエラー
// "Variables can't be declared using both 'var' and a type name."
// var List hoge = ['hoge'];

関数呼び出しの際も、返り値のクラスを指定する必要があるようです。
たとえば、showDialogメソッドで返ってくるのはAwesomeDialogインスタンスなので指定します。

// アラートが出る
showDialog(
  context: context,
  builder: (_) {
    return AwesomeDialog();
  }
);

// 返り値のクラスを指定するとアラートが出なくなる
showDialog<AwesomeDialog>(
  context: context,
  builder: (_) {
    return AwesomeDialog();
  }
);

以上、動的型付け禁止の項目でした!

Dart DevToolsの使い方

ウィジェットを並べていくFlutterは、ウィジェットのネストが深くなりがち。
どのウィジェットのHeight指定がうまくいってないの…?🤔を確認したくなった時とか、ウィジェットの構造を確認したくなった時に便利なのがDart DevToolsです。

DartDevTools - Getting Started

Android StudioVS Codeと、それぞれ説明されていますが、わたしはVSCodeをメインに使っているのでVSCodeのやり方を書いていきます。

DevToolsのインストール、立ち上げ

VSCodeからエミュレータを起動(F5)するとこんなメッセージが出てきます(DevToolsがインストールされていない初回のみ)。

Dart DevTools need to be installed
with 'pub global activate devtools' to use this feature.

DevToolsを使うにはpub global activate devtoolsでインストールしてね、と言われるので、「Activate Dart DevTools」をクリックするとflutter packages getが走ってDevToolsをActivateしてくれます。

しばらく待つとhttp://127.0.0.1:58696/?hide=debugger&port=57931のようなアドレスでブラウザが立ち上がり、ウィジェットツリーをブラウザから確認することができます。

DevToolsが立ち上がらなかった時

なんらかの原因でDevToolsが立ち上がらなかった時は、VSCodeから直接コマンドで立ち上げることができます。

$ flutter packages pub global activate devtools

ポート番号がわからなくなった時

URLはhttp://127.0.0.1で固定ですが、ポート番号は動的に振られてセッションが変わる度(アプリを再起動する度)に切り替わります。
ポート番号がわからなくなった時はVSCodeのステータスバーにある「Dart DevTools」の文字をクリックすると、ブラウザでDevToolsが立ち上がります。

DevToolsの使い方

直感的に使えるUIですが、よく使う機能を少しだけ。

  • Debug Paint
    オンにするとウィジェットの枠線を引いたり、mainAxisAlignmentの向きを表示したりしてくれます。
    モック作りではおそらく一番使うところ。

  • Select Widget Mode
    オンにすると、ブラウザでウィジェットを選択することでエミュレータウィジェットも選択することができるようになります。
    Chromeデベロッパーツールで要素を選択できるのに似ているイメージ。

  • Refresh Tree
    エミュレータはホットリロードが効きますが、DevToolsはホットリロードが効かないので手動でリロードするためのボタン。
    Navigator.pushなども反映されないので画面遷移した時も同様にリフレッシュする必要があります。

注意点としては、stackされているScaffoldが全てツリー表示されるので、違うウィジェットツリーを見ながら「あれ?ない??🤔」となりがちなこと。
ありがちなミスだと思うのでお気をつけて、快適なFlutter開発をお楽しみください!🎉

analysis_option.yamlをカスタマイズする

VSCodeやAndroidStudioを使っていると、Dart Analysis Serverが構文エラーをチェックしてくれます。非常に便利な機能ですが、これをカスタマイズできるのがanalysis_option.yaml

Customize Static Analysis - Dart

pubspec.yamlと同じディレクトリに置いておくだけでAnalyserをカスタマイズすることができます。
ちなみに、analysis_option.yamlの冒頭でincludeすることもできるそうで、ベースとなるルールをincludeして、それをプロジェクトごとにカスタマイズするという使い方も便利そうです。

include: package:pedantic/analysis_options.yaml

上述のDartのサイトに詳しく解説があるのですが、理解の為に少しずつ訳していこうと思います。

今日の項目はtype checks
Dartは動的型付言語ですが、より厳しくチェックをしたい場合、静的型付でないとエラーを出すことができます。

analyzer:
  strong-mode:
    implicit-casts: false
    implicit-dynamic: false

implicitは「暗黙的な」という意味だそう。
つまり、ひとことでいうと、暗黙的な型変換を許可しないよ、という設定。
implicit-castsimplicit-dynamicは別々に設定することができます。
どちらもデフォルトはtrue

  • implicit-casts
    値がfalseの場合、暗黙的に特定の型にキャストしません。
    公式で例示されているのは下記のコード。
Object o = 'hoge';
String s = o; // Implicit downcast

Object oに入っているのはhogeという文字列なので、Stringの変数であるsoを入れてもDartコンパイラは許してくれますが、implicit-castsをfalseにしていると暗黙的な型変換を行うと、エラーが表示されるようになります(エラーは表示のみで、コンパイラは通ります)。

  • implicit-dynamic
    値がfalseの場合、静的型を決定できないときに動的型を選択しません。

これはちょっと具体例が理解できていないので、続きはまた明日書きます!

FlutterでDialogの表示を変更できなかったお話

今日はFlutterのダイアログのお話。

ダイアログの中にテキストフィールドを準備して、バリデーション違反があったらエラーメッセージを追加したいということがありました。

ダイアログの表示自体はSimpleDialogAlertDialogを使えばできるのですが、表示の変更ができずにハマりました。

以下がコード例。
簡単に、AppBarにあるアイコンをタップするとダイアログが表示されて、ダイアログ内のボタンをタップすると表示をトグルするようなコードにしています。

class _AwesomePageState extends State<AwesomePage> {
  bool _isAwesome;
  String _awesomeText;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Everyday Awesome'),
        actions: <Widget>[
          PopupMenuButton(
            onSelected: (String value) {
              showDialog(
                context: context,
                builder: (BuildContext context) => SimpleDialog(
                      title: const Text('It says'),
                      children: <Widget>[
                        const Text('Flutter is awesome.'),
                        RaisedButton(
                          child: const Text('u a Awesome!'),
                          onPressed: () {
                            setState(() {
                              _isAwesome = !_isAwesome;
                              _awesomeText = _isAwesome
                                  ? 'u a Awesome!'
                                  : 'please tap Awesome..';
                            });
                          },
                        ),
                      ],
                    ),
              );
            },
            itemBuilder: (BuildContext context) => <PopupMenuEntry<String>>[
                  const PopupMenuItem(child: const Text('A'), value: 'a'),
                ],
          )
        ],
      ),
      body: Center(
        child: const Text('Awesome'),
      ),
    );
  }
}

ボタンをタップする度にonPressedの中でsetState()して_awesomeTextが変更されて「u a Awesome!」となるはずですが、何度タップしても変更されません。
ボタンだけでなく、タイトルやテキストを変更しようとしても同じ。
おかしいな、と思ってSimpleDialogのコードを読んでみると、理由がわかりました。

class SimpleDialog extends StatelessWidget {
// ...(略)
}

StatelessWidget!!
setState()しても意味ないはずでした!
念の為AlertDialogDialogクラスを見てみても、どちらも同じくStatelessWidget

ガイドラインをそう読み込んだわけではないのですが、Material Designガイドラインを読むに、ダイアログはあくまでも警告・エラーを表示したり、選択可能なリストを表示したりといったすごくシンプルなUIを目的としているみたい。
じゃあどうすれば…というと、FlutterによるFull-Screen Dialogの実装例があるのを先輩に教えて頂きました。

ちょっと長いですが、要は、StatefulWidgetを作って、SimpleDialogの代わりに呼び出す、ということのよう。
実装するとこんな感じになりました。

class _AwesomePageState extends State<AwesomePage> {
  bool _isAwesome;
  String _awesomeText;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Everyday Awesome'),
        actions: <Widget>[
          PopupMenuButton(
            onSelected: (String value) {
              showDialog(
                context: context,
                builder: (_) {
                  return AwesomeDialog();
                },
              );
            },
            itemBuilder: (BuildContext context) => <PopupMenuEntry<String>>[
                  const PopupMenuItem(child: const Text('A'), value: 'あ'),
                ],
          )
        ],
      ),
      body: Center(
        child: const Text('Awesome'),
      ),
    );
  }
}

class AwesomeDialog extends StatefulWidget {
  @override
  _AwesomeDialogState createState() => _AwesomeDialogState();
}

class _AwesomeDialogState extends State<AwesomeDialog> {
  bool _isAwesome;
  String _awesomeText;

  @override
  void initState() {
    super.initState();
    _isAwesome = false;
    _awesomeText = 'please tap Awesome..';
  }

  Widget _buildAwesomeButton() {
    return RaisedButton(
      child: Text(_awesomeText),
      onPressed: () {
        setState(() {
          _isAwesome = !_isAwesome;
          _awesomeText = _isAwesome ? 'u a Awesome!' : 'please tap Awesome..';
        });
      },
    );
  }

  @override
  Widget build(BuildContext context) {
    return SimpleDialog(
      title: const Text('It says'),
      children: <Widget>[
        const Text('Flutter is awesome.'),
        _buildAwesomeButton(),
      ],
    );
  }
}

showDialog関数のbuilderSimpleDialogではなく、AwesomeDialogを渡しています。
AwesomeDialogも返すウィジェットSimpleDialogですが、stateを持ったRaisedButtonを外だしにして渡すことで、stateの変更が反映されるようになりました。

では、最初の例でもRaisedButtonを外だししたり、stateにしてしまえばよいのでは?🤔と思ったけれど、これはうまくいかない。
この辺りはまたいずれ調べてみようと思います!