Web技術でアプリ開発2016特集・第5弾は、プログレッシブウェブアプリ (Progressive Web Apps)をご紹介させていただきます。 はじめに プログレッシブウェブアプリ(Progressive Web Apps)という言葉が初めて登場したのは2015年8月のAlex Russellによる記事Progressive Web Apps: Escaping Tabs Without Losing Our Soulです。当時オフラインやプッシュ通知など、モバイルウェブを飛躍的に進化させる画期的な機能が次々と追加されていた状況において、このムーブメントを呼称するための言葉が求められていました。Google社内でいくつもの候補が挙げられましたが、Service Workerの発案者としてAlex Russellが推したのが、この「プログレッシブウェブアプリ」でした。 また、当初Goog

導入のしやすさ Mac必須 開発というよりかは、iPhoneやiOS Simulatorの為 Flutter Doctor 便利 packageも楽ちん 導入というか性質というか、頻繁にFlutterアップデートが来る。描画が壊れるupdateもあったが、回避方法はあったので致命的ではなかった WYSWYGツール不在の為、UI設計が面倒とおもったけど十分高い生産性 hot reloadが優秀　(ソース保存即時反映） Debug paintが優秀 (各コンポーネントの描画範囲等がわかる) Flutterの基本コンポーネントにしろよと思ったパッケージ群、よっぽどシンプルじゃない限り必要になる　以下 pubspec.yaml dependencies:に追記するべきパッケージ validate: "^1.6.0" #email等、入力チェック http: "^0.11.3+16" # APIと通

DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう