Submit Search
Upload
Flutterアプリ開発におけるモジュール分割戦略
•
0 likes
•
895 views
Yamashita Takeshi
Follow
FlutterKaigi 2022 登壇資料
Read less
Read more
Report
Share
Report
Share
1 of 81
Download now
Download to read offline
Recommended
デザイナのためのGit入門
デザイナのためのGit入門
dsuke Takaoka
社内勉強会用資料です。Gitの使い方の前に。
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
dcubeio
http://d-cube.connpass.com/event/43057/ にて発表した内容です
JIRA / Confluence の必須プラグインはこれだ
JIRA / Confluence の必須プラグインはこれだ
Narichika Kajihara
JIRA / Confluenceの必須プラグインを紹介したいと思います。 使ってみないと分からないのがプラグイン。されど忙しくと中々評価に時間をさくことが出来ないのも実情。 実際使っているプラグインとその感想について共有したいと思います。
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
naoki koyama
GitFlow,GitHubFlow,GitLabFlowは使わない! gitの新しいブランチモデル「GitFeatureFlow」を 考えたので紹介します
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
NTT Tech Conference #2 にて話した資料 時間が足りなかったので全部は話せなかった。
いつやるの?Git入門
いつやるの?Git入門
Masakazu Matsushita
↓のv1.1.0版の方が、より見やすく改善したものになってます! http://www.slideshare.net/matsukaz/git-28304397 社内で開催したGit勉強会の資料。 SVNとの比較や、Gitの内部構造と各コマンドの関係、ブランチやリモートリポジトリとの関係を分かりやすく説明したつもり。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
オススメの標準・準標準パッケージ20選
オススメの標準・準標準パッケージ20選
Takuya Ueda
Go言語LT大会で発表した資料です。 https://go-beginners.connpass.com/event/55768/
いまさら聞けないselectあれこれ
いまさら聞けないselectあれこれ
lestrrat
Goにおける重要な構文、selectについて。今更聞けない基本からちょっとしたトリックまで。
Recommended
デザイナのためのGit入門
デザイナのためのGit入門
dsuke Takaoka
社内勉強会用資料です。Gitの使い方の前に。
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
dcubeio
http://d-cube.connpass.com/event/43057/ にて発表した内容です
JIRA / Confluence の必須プラグインはこれだ
JIRA / Confluence の必須プラグインはこれだ
Narichika Kajihara
JIRA / Confluenceの必須プラグインを紹介したいと思います。 使ってみないと分からないのがプラグイン。されど忙しくと中々評価に時間をさくことが出来ないのも実情。 実際使っているプラグインとその感想について共有したいと思います。
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
naoki koyama
GitFlow,GitHubFlow,GitLabFlowは使わない! gitの新しいブランチモデル「GitFeatureFlow」を 考えたので紹介します
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
NTT Tech Conference #2 にて話した資料 時間が足りなかったので全部は話せなかった。
いつやるの?Git入門
いつやるの?Git入門
Masakazu Matsushita
↓のv1.1.0版の方が、より見やすく改善したものになってます! http://www.slideshare.net/matsukaz/git-28304397 社内で開催したGit勉強会の資料。 SVNとの比較や、Gitの内部構造と各コマンドの関係、ブランチやリモートリポジトリとの関係を分かりやすく説明したつもり。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
オススメの標準・準標準パッケージ20選
オススメの標準・準標準パッケージ20選
Takuya Ueda
Go言語LT大会で発表した資料です。 https://go-beginners.connpass.com/event/55768/
いまさら聞けないselectあれこれ
いまさら聞けないselectあれこれ
lestrrat
Goにおける重要な構文、selectについて。今更聞けない基本からちょっとしたトリックまで。
やさしいGitの内部構造 - yapcasia2013
やさしいGitの内部構造 - yapcasia2013
DQNEO
Gitの内部構造についてのわかりやすい解説です。
こわくない Git
こわくない Git
Kota Saito
「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
Akihiko Horiuchi
Golang勉強会 in Kagawa http://gdgshikoku.connpass.com/event/26262/
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
PostgreSQLをKubernetes上で活用するためのOperator紹介! (Cloud Native Database Meetup #3 発表資料) 2022年1月14日 NTTデータ 技術開発本部 先進コンピューティング技術センタ 藤井 雅雄
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
Java/Spring Boot/MyBatis/Thymeleafを使った、ドメイン駆動設計のサンプルコード。ビジネスルールに焦点を合わせ、計算モデルで複雑さを整理し、型指向のプログラミングで実装する、その具体例。
AlloyDBを触ってみた!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
AlloyDBを触ってみた!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
AlloyDBを触ってみた! (第33回PostgreSQLアンカンファレンス@オンライン 発表資料) 2022年5月31日 NTTデータ 技術開発本部 先進コンピューティング技術センタ 石井 愛弓
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
NTT DATA Technology & Innovation
Grafana LokiではじめるKubernetesロギングハンズオン (NTT Tech Conference #4 ハンズオン資料) 2020年1月31日 株式会社NTTデータ / NTT DATA Masahiko Utsunomiya
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
Pythonによる(Rubyでも大体適用可能)黒魔術へ入門するための案内書
Java開発の強力な相棒として今すぐ使えるGroovy
Java開発の強力な相棒として今すぐ使えるGroovy
Yasuharu Nakano
Presentation slide of my session of Groovy at JJUG CCC 2015 Spring
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
ドメイン駆動設計の4つの基本活動、Springのプログラミングモデル、ドメイン駆動設計のためのSpringの使い方
KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢
Naoyuki Yamada
CyberAgent社内Adtech Developer Conference発表資料
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
アプリ「ニュースパス」をマイクロサービスで開発してみた泥臭い体験談です。
例外設計における大罪
例外設計における大罪
Takuto Wada
例外設計における大罪 Jun 27, 2012 @ java-ja
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
LayerX社内の定例でつかった資料です。
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Preferred Networks
Kubernetesの近年の大きなbreakthroughの一つにCRD & Controllerを使った拡張があります。このセッションではCRD & Custom Controller開発を始めようと思っている人向けに、Kubernetesコミュニティで開発されているCustom Controller向けSDKであるkubebuilder, controller-runtimeについての解説を行います。
async/await のしくみ
async/await のしくみ
信之 岩永
https://connpass.com/event/95696/ 2018/9/15 「Unity 非同期完全に理解した勉強会」にて登壇
DDD sample code explained in Java
DDD sample code explained in Java
増田 亨
2019-02-18 #jsug ドメイン駆動設計サンプルコード徹底解説
Raspberry Pi + Go で IoT した話
Raspberry Pi + Go で IoT した話
yaegashi
golang.tokyo #26 https://golangtokyo.connpass.com/event/147175/
DLR言語によるSilverlightプログラミング
DLR言語によるSilverlightプログラミング
terurou
いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達
softlayerjp
Dockerの基盤としてSoftLayerのベアメタルは最適です。ここでは、Dockerのみならず、周辺のオーケストレーション・ツールを交えた利用シーンや使いどころをご紹介します。
More Related Content
What's hot
やさしいGitの内部構造 - yapcasia2013
やさしいGitの内部構造 - yapcasia2013
DQNEO
Gitの内部構造についてのわかりやすい解説です。
こわくない Git
こわくない Git
Kota Saito
「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
Akihiko Horiuchi
Golang勉強会 in Kagawa http://gdgshikoku.connpass.com/event/26262/
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
PostgreSQLをKubernetes上で活用するためのOperator紹介! (Cloud Native Database Meetup #3 発表資料) 2022年1月14日 NTTデータ 技術開発本部 先進コンピューティング技術センタ 藤井 雅雄
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
Java/Spring Boot/MyBatis/Thymeleafを使った、ドメイン駆動設計のサンプルコード。ビジネスルールに焦点を合わせ、計算モデルで複雑さを整理し、型指向のプログラミングで実装する、その具体例。
AlloyDBを触ってみた!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
AlloyDBを触ってみた!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
AlloyDBを触ってみた! (第33回PostgreSQLアンカンファレンス@オンライン 発表資料) 2022年5月31日 NTTデータ 技術開発本部 先進コンピューティング技術センタ 石井 愛弓
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
NTT DATA Technology & Innovation
Grafana LokiではじめるKubernetesロギングハンズオン (NTT Tech Conference #4 ハンズオン資料) 2020年1月31日 株式会社NTTデータ / NTT DATA Masahiko Utsunomiya
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
Pythonによる(Rubyでも大体適用可能)黒魔術へ入門するための案内書
Java開発の強力な相棒として今すぐ使えるGroovy
Java開発の強力な相棒として今すぐ使えるGroovy
Yasuharu Nakano
Presentation slide of my session of Groovy at JJUG CCC 2015 Spring
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
ドメイン駆動設計の4つの基本活動、Springのプログラミングモデル、ドメイン駆動設計のためのSpringの使い方
KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢
Naoyuki Yamada
CyberAgent社内Adtech Developer Conference発表資料
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
アプリ「ニュースパス」をマイクロサービスで開発してみた泥臭い体験談です。
例外設計における大罪
例外設計における大罪
Takuto Wada
例外設計における大罪 Jun 27, 2012 @ java-ja
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
LayerX社内の定例でつかった資料です。
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Preferred Networks
Kubernetesの近年の大きなbreakthroughの一つにCRD & Controllerを使った拡張があります。このセッションではCRD & Custom Controller開発を始めようと思っている人向けに、Kubernetesコミュニティで開発されているCustom Controller向けSDKであるkubebuilder, controller-runtimeについての解説を行います。
async/await のしくみ
async/await のしくみ
信之 岩永
https://connpass.com/event/95696/ 2018/9/15 「Unity 非同期完全に理解した勉強会」にて登壇
DDD sample code explained in Java
DDD sample code explained in Java
増田 亨
2019-02-18 #jsug ドメイン駆動設計サンプルコード徹底解説
Raspberry Pi + Go で IoT した話
Raspberry Pi + Go で IoT した話
yaegashi
golang.tokyo #26 https://golangtokyo.connpass.com/event/147175/
What's hot
(20)
やさしいGitの内部構造 - yapcasia2013
やさしいGitの内部構造 - yapcasia2013
こわくない Git
こわくない Git
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
AlloyDBを触ってみた!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
AlloyDBを触ってみた!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Pythonによる黒魔術入門
Pythonによる黒魔術入門
Java開発の強力な相棒として今すぐ使えるGroovy
Java開発の強力な相棒として今すぐ使えるGroovy
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
例外設計における大罪
例外設計における大罪
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
async/await のしくみ
async/await のしくみ
DDD sample code explained in Java
DDD sample code explained in Java
Raspberry Pi + Go で IoT した話
Raspberry Pi + Go で IoT した話
Similar to Flutterアプリ開発におけるモジュール分割戦略
DLR言語によるSilverlightプログラミング
DLR言語によるSilverlightプログラミング
terurou
いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達
softlayerjp
Dockerの基盤としてSoftLayerのベアメタルは最適です。ここでは、Dockerのみならず、周辺のオーケストレーション・ツールを交えた利用シーンや使いどころをご紹介します。
インフラエンジニアのためのRancherを使ったDocker運用入門
インフラエンジニアのためのRancherを使ったDocker運用入門
Masahito Zembutsu
#qpstudy 2015.06 Lightning Talks Session 「インフラエンジニアのためのRancherを使ったDocker運用入門」 2015年6月20日(土) 渋谷 GMO Yours
Grailsのススメ(仮)
Grailsのススメ(仮)
Tsuyoshi Yamamoto
JGGUG総会+スペシャルG* ワークショップ 2010/7/24 「Grailsのススメ(仮)」 発表者: 山本剛 (ニューキャスト) ここのところリリースラッシュのWebフレームワーク「Grails」。Grailsのクイックスタートから、Grails 1.3.x+αな最新情報、個人的注目プラグイン情報等、紹介します。
DAS_202109
DAS_202109
Takefumi MIYOSHI
An presentation in DA Symposium about ACRi room
20130803 OSC@Kyoto CloudStackユーザー会
20130803 OSC@Kyoto CloudStackユーザー会
samemoon
Dockerで.NET Core 3.0 GUIアプリを動かす話
Dockerで.NET Core 3.0 GUIアプリを動かす話
You&I
プログラミング生放送勉強会 第60回@名古屋の発表資料。 https://atnd.org/events/108992
Inside frogc in Dart
Inside frogc in Dart
Goro Fuji
Presentation for #yaminabePG http://d.hatena.ne.jp/gfx/20120402/1333323796
Flutter_Forward_Extended_Kyoto-Keynote_Summary
Flutter_Forward_Extended_Kyoto-Keynote_Summary
cch-robo
2023年03月28日(火) にオンライン開催された Flutter Forward Extended Kyoto セッションのスライドです。 Flutter Forward Extended Kyoto https://gdgkyoto.connpass.com/event/277897/ YouTube Live URL https://youtube.com/live/DWhoYfrHyxk
スマートフォン対応、気をつけたいトラブル
スマートフォン対応、気をつけたいトラブル
Hiroaki Wakamatsu
8/18におこなわれたCSS Nite in OSAKA, Vol.32での発表用スライドです。4/27のCSS Nite in OSAKA, Vol.29で使用したスライドをベースに、若干の追記・修正をした内容となっています。
コンテナ&サーバーレス:トレンドの考察と少し先の未来の展望
コンテナ&サーバーレス:トレンドの考察と少し先の未来の展望
Yoichi Kawasaki
Developer Summit 2018 FUKUOKA プレゼンテーション資料 https://event.shoeisha.jp/devsumi/20180906/session/1777/ 関連記事: https://codezine.jp/article/detail/11098
Groovy base gradle_20130309
Groovy base gradle_20130309
Nobuhiro Sue
fluxflex meetup in Tokyo
fluxflex meetup in Tokyo
Kyosuke Inoue
Vagrantでクラウド上にdocker環境を作る
Vagrantでクラウド上にdocker環境を作る
IDC Frontier
Tech-Circle #2: Vagrant+Dockerを使って環境を簡単に作るハンズオン勉強会における、佐々木のLT資料です。
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
日本マイクロソフト株式会社
Git を中心にしてシステム実行環境やアプリケーションの変更を行う GitOps という考え方が広がりつつあります。この GitOps に取り組んでらっしゃる株式会社ベルシステム 24 ホールディングス様の事例とともに、 GitOps の概要とその効果をご紹介します。
Modernization of IT Infrastructure by Microsoft Azure
Modernization of IT Infrastructure by Microsoft Azure
Takeshi Fukuhara
2018年9月に米国で開催されたMicrosoft Ignite 2018での発表をベースに、Microsoft Azureのインフラストラクチャに関する最新情報を紹介。2018年11月5日、Microsoft Tech Summit 2018のセッションスライド。
Windows 8 Developers カンファレンス
Windows 8 Developers カンファレンス
Kaoru NAKAMURA
ひしめき合うOpen PaaSを徹底解剖! PaaSの今と未来
ひしめき合うOpen PaaSを徹底解剖! PaaSの今と未来
Kazuto Kusama
July Tech Festaで発表した資料です。 Cloud Foundry、OpenShift v3、Deis、Flynnを取り上げて、Open PaaSの今と未来について解説しました。
Kubernetes 初心者の僕からの JKD 参加報告
Kubernetes 初心者の僕からの JKD 参加報告
Kentaro NOMURA
JapanContainerDays v18.12 報告会@福岡 での発表資料です。
Net fringejp2016
Net fringejp2016
Yusuke Fujiwara
.NET Fringe Japan 2016 slides about MsgPack for CLI and week end FOSS development (Japanese).
Similar to Flutterアプリ開発におけるモジュール分割戦略
(20)
DLR言語によるSilverlightプログラミング
DLR言語によるSilverlightプログラミング
いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達
インフラエンジニアのためのRancherを使ったDocker運用入門
インフラエンジニアのためのRancherを使ったDocker運用入門
Grailsのススメ(仮)
Grailsのススメ(仮)
DAS_202109
DAS_202109
20130803 OSC@Kyoto CloudStackユーザー会
20130803 OSC@Kyoto CloudStackユーザー会
Dockerで.NET Core 3.0 GUIアプリを動かす話
Dockerで.NET Core 3.0 GUIアプリを動かす話
Inside frogc in Dart
Inside frogc in Dart
Flutter_Forward_Extended_Kyoto-Keynote_Summary
Flutter_Forward_Extended_Kyoto-Keynote_Summary
スマートフォン対応、気をつけたいトラブル
スマートフォン対応、気をつけたいトラブル
コンテナ&サーバーレス:トレンドの考察と少し先の未来の展望
コンテナ&サーバーレス:トレンドの考察と少し先の未来の展望
Groovy base gradle_20130309
Groovy base gradle_20130309
fluxflex meetup in Tokyo
fluxflex meetup in Tokyo
Vagrantでクラウド上にdocker環境を作る
Vagrantでクラウド上にdocker環境を作る
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
【de:code 2020】 Azure Kubernetes Service と Azure DevOps による GitOps の実践
Modernization of IT Infrastructure by Microsoft Azure
Modernization of IT Infrastructure by Microsoft Azure
Windows 8 Developers カンファレンス
Windows 8 Developers カンファレンス
ひしめき合うOpen PaaSを徹底解剖! PaaSの今と未来
ひしめき合うOpen PaaSを徹底解剖! PaaSの今と未来
Kubernetes 初心者の僕からの JKD 参加報告
Kubernetes 初心者の僕からの JKD 参加報告
Net fringejp2016
Net fringejp2016
Flutterアプリ開発におけるモジュール分割戦略
1.
Flutterアプリ開発におけるモジュール分割戦略 〜dart 2500ファイルを100分割する〜 VIVIWARE株式会社 山下武志 @eaglesakura
2.
自己紹介
3.
山下 武志 ● VIVIWARE株式会社
所属 ● アカウント ○ Twitter @eaglesakura ○ Github @eaglesakrua ● 2008年からずっとモバイルアプリ開発中心 ● 2019年頃からFlutterアプリ開発に関わる
4.
導入したプロジェクトの紹介
5.
VIVIWARE Cell Plus ●
https://cell.viviware.com/ ● ノードベースのプログラミングツール ● Bluetoothで自社ハードウェアと連携
6.
VIVIWARE Cell Plus ●
Androidアプリ(Kotlin)をFlutterでリニューアル ○ 現在iOS, Android対応 ○ Windows, Webなどへも展開予定 ● 2022年9月時点で*.dartファイル約2500個、約15万行ほどの規模 ● 約100個の細かいモジュールから構成される ○ Dart的には `package` のほうが正確であるが、このセッションでは「モジュール」に統一
7.
VIVIWARE Cell Plus ●
開発当初から、巨大なプロジェクトになることが予想された ○ 「ユーザーにプログラミング環境を提供する」という複雑なアプリ ○ マルチプラットフォーム対応 ● 導入が予想される多数のプラグイン ○ カメラ ○ Bluetooth ○ データベース ○ データ暗号化 ○ 音源再生機能 ○ その他...
8.
プロジェクトの健康寿命を考える
9.
プロジェクトの健康状態は常に悪くなる ● 開発が続く限り、何もしなければプロジェクトは不健康になる ○ 技術的負債が溜まる、非推奨な
APIを使い続けるなど ○ 誰が何のために導入したかも定かではないライブラリがエラーを出しているなど ● 可能な限りプロジェクトの健康状態を良好に保てる設計が必要である ● 健康を願うだけでは叶わない、健康であり続ける環境が必要になる
10.
VIVIWARE Cell Plusの寿命 ●
リリース後3〜5年を最低限の健康寿命と設定した ● 5年後も健康であり続けるために、モノリシック設計とマイクロモジュール設計のど ちらが良い選択かを検討した ● 結果としてある程度の追加投資をしても、モジュールを積極的分割するリターンの 方が大きいと判断した ● 新たな設計開発手法・アーキテクチャが登場する可能性は高い ○ 5年、もしくはそれよりも早く「存在自体が古臭い」と言われる可能性はある ○ 未来は誰にもわからないが、少なくとも 2021年時点ではこれが最良であると判断した ○ 2022年時点でもその判断は変わっていない
11.
マイクロモジュール設計の定義 ● このセッションでは「(ライブラリではない)アプリ専用の複数のモジュールを組み合 わせて1つのアプリを構築する」設計をマイクロモジュール設計と呼ぶ ● サーバーサイドの「マイクロサービス」のイメージ
12.
マイクロモジュールの利点
13.
機能単位でのリプレイスを容易にできる ● 「ある機能でだけ依存しているライブラリ」の影響範囲特定が容易である ● これはライブラリやAPIが突然の死を迎えた際の治療を容易にする ○
導入しているライブラリの更新停止も珍しく無い ○ 問題が発生した際の代替手段は常に考える必要がある
14.
影響範囲を限定的にできる ● Dart言語は*dartファイル単位で公開・非公開が行える ○ 厳密にはいろいろ例外あり ●
公開していないクラス群の影響範囲は、モジュールのなかに限られる ○ モノリシックの場合、「無関係なはずのコードから参照される」ことを制限する手段がない ● NEED NOT TO KNOW(知る必要のないこと)をソースコードレベルで実現できる
15.
モジュール単位での積極的リファクタリング実施 ● モジュールの外への影響範囲が限定されている ● ソースコードのコンフリクトが起こりにくく、積極的リファクタリングが行える ●
積極的に新しいアーキテクチャを導入しやすい ○ モジュール単位でアーキテクチャやライブラリを選定 /更新できる ○ 基本的にはRedux Architectureを採用しているが、将来的な変更をしやすくしている
16.
レビューの重点を把握しやすくなる ● モジュール内の非公開コードである限り、ある程度品質に妥協できる ○ 「完璧」なコードを常に求めるのは難しい ○
アプリ開発にかけられる期間は有限であるため、メリハリをつけてレビューする ● コードレビューや影響範囲が限定されるため、観点整理しやすい ● レビューの重点をAPIインターフェースとPublicなコードとする
17.
レビューの重点を把握しやすくなる ● 多数のdartコードが内部に存在している ● 例の場合exportされているのは1classだけ ○
それ以外のコードはある程度妥協してマージする ○ 品質に致命的問題が発生した場合、モジュール自体を再実装する
18.
モジュール分割の書き方
19.
モジュールの作成はflutter createから行える ● `flutter
create –template=package util_core` の実行例
20.
テンプレートを作成し、プロジェクトの事情を反映 ● VIVIWARE Cell
Plusではコピペで使えるテンプレートを用意した
21.
pubspec.yamlの記述 / 同一リポジトリの場合 ●
pub.devにアップロードされているライブラリを参照するのとほぼ同様 ● 分割したモジュールを参照する際、pubspec.yamlに次のように記述する ○ util_coreモジュールに便利系処理を分割し、別なモジュールから参照する例 ● 1リポジトリに複数のモジュールを追加して開発できる
22.
pubspec.yamlの記述 / gitの別リポジトリの場合 ●
複数プロジェクト間で共有する際は別リポジトリにしても良い ● 分割したモジュールのリポジトリとバージョンを指定できる ○ “ref:” にはtag名、branch名、ハッシュが記述できる
23.
refにハッシュ値を指定する場合注意点 ● ハッシュ値の文字列 “aabbccdd…”
で比較されるため、意図せず古いバージョンが 使われる恐れがある ○ 複数モジュールから異なるバージョンが参照される場合問題となる ● gitのモジュールを参照する場合はtagを指定した方が問題が少ない
24.
モジュール分割の方針と具体例
25.
ドメインの分割
26.
ドメイン層は積極的に分割する ● 製品ドメインに関わる部分は独立したモジュールにする ● VIVIWARE
Cell Plusでの例(10以上に分割)
27.
画面単位の分割
28.
全ての画面は別モジュールに分割されている ● 画面遷移(Navigator操作)を伴う箇所は全て別モジュールに分割 ログイン画面 view_login モジュール ユーザーデータ一覧画面 view_home
モジュール プログラミング画面 view_project_editor モジュール
29.
画面内での分割
30.
複雑な画面は複数のモジュールに分割されている ● プログラミング画面の例 ● 複雑な画面をUsecase(処理)とView(描画)に分割
31.
複雑なダイアログも別モジュールに分離 ● 複雑なダイアログは基本的に別モジュールとして実装されている ○ ユーザーデータ保存ダイアログなど、複雑なダイアログが多い ○
この画面でしか使用しないコードが多数あるため、モジュールを分割
32.
プログラム編集画面の構成 ● プログラム編集画面 ○ view_project_editor ■
view_project_editor_circuit_jump ■ view_project_editor_comment ■ view_project_editor_variable_register ■ view_project_editor_save ○ usecase_project_editor
33.
インフラ層の分割
34.
プラグインは別モジュールに独立させる ● プラグイン(ネイティブコード)を必要とする処理はモジュールを分離 ○ ネイティブコードを必要とするモジュールもプロジェクトでは「インフラ」と分類した ●
プラグインはマルチプラットフォームでは常にリスクと隣り合わせ ○ 対応していると思ったら機能が限定されていた、とかもある ○ 明日、あなたのもとに LinuxやWindows対応リクエストが届くかもしれない ● モジュールを分離し、適切なインターフェースを介してアクセスする ○ WebではFile Systemが使えない(制限がある)など、プラットフォーム固有の知識も必要 ○ VIVIWARE Cell Plusプロジェクトではファイルアクセスもプラグインと同等の扱い
35.
ビルド時のexport切り替え方法 ● Dart言語ではビルド時に定数を使用してexport切り替えることができる ● 使用するdartファイルが切り替わるため、全く異なるプラグインを使用することがで きる
36.
Bluetooth処理の例 ● flutter_blueがサポートしているプラットフォームは3つ ○ Android,
iOS, Mac ● BLE関連をflutter_blueに全て依存すると、Windows版開発時に問題となる
37.
● infra_celldevice_ble3モジュールのみがflutter_blueに依存している設計 ● flutter_blueは他のモジュールでは依存していない ○
依存関係を限定することにより、意図しない参照を避ける ○ 「やらんやろ」と思っても意外とやらかすのである ● 言語レベルで制限をかけるのが重要 インフラ層にプラグインを閉じ込める
38.
プラグインが モジュールの境界を越えるパターン
39.
プラグインがモジュールの境界を越えているパターン ● Databaseを扱うライブラリはSQLとは切り離しにくい ● 各機能のためのクエリが大量に存在する ●
出来ないことはないが、「これ全部Wrapするの?」というコストがある ○ SQLに関わる全ての例外を Wrapするのは現実的ではなかった ● プラグインが生成したClassへの直接アクセスを許可している ○ Repository層まではアクセスを許可している ○ Repository層よりも上はプラグイン関連へのアクセスを許さない ■ 各RepositoryはDriftを知っている ■ Repositoryの利用者はDriftを知らない ○ Clean Architectureにおける”結婚”の覚悟を持つ
40.
相当の覚悟を持ったexport ● Driftプラグインやsqlite3プラグインの一部をexportしている ● Repository層ではクエリ発行が頻発するため、効率を優先した ○
全ての細かいQueryに対してラッパーを用意することが高コストと判断した ○ RepositoryのDBアクセス部分がDriftと「結婚」する覚悟を持つ ● Driftが非推奨(開発終了など)となった場合は、「離婚」するコストを払う ○ という覚悟である ○ ダラダラとDriftと結婚生活を続けるのはやめよう
41.
プラグインとの縁談 ● どのような観点で結婚を決めるか ● 確認した要素 ○
更新頻度 ○ 対応プラットフォーム ○ PubのLike数 ○ 自動判定されるScore ○ ドキュメントの充実度
42.
分割方針のまとめ
43.
完璧にするコストと、 完璧でないリスクを勘案する
44.
分割の基本方針まとめ ● 1画面につき最低1モジュール以上に分離 ○ 1画面が複数のモジュールで構成されている場合もある ●
共通で使うコードはutilとしてモジュールを分離 ● インターフェースに対して実装が複数ある場合は実装ごとに分離 ● プラグインは必ず1モジュール以上に分離する ○ プラグインとは、ネイティブコードを含む( dartファイルで完結しない)モジュールである ○ レビュー時、「導入するライブラリにネイティブを含むか」は重要な観点である ● プロジェクト内でPrefix/Suffixを決めておくと良い ○ VIVIWARE Cell Plusの例 ■ util, domain, infra, usecase, view など
45.
分割したモジュールを効果的に扱う
46.
Dart言語でInternalアクセスを使う
47.
公開したclassの、一部機能を制限したい場合 ● Dartは言語レベル(コンパイラレベル)の制限が弱い ○ 言語レベルではPrivateとPublicだけが用意されている ○
Privateは自分以外誰も使えず、 Publicにすると無制限に誰でも使える ○ 特にInternalは有用である ■ コンストラクタをinternalにして勝手にインスタンス化するのを防ぐなど ● コメントに「触るな危険」と書いても意味がない ● KotlinやJavaでは可視性が豊富に用意されている ○ Protected(継承先だけ使える) ○ Package Private(同じPackageのグループだけ使える) ○ Internal(同じモジュール内だけで使える)
48.
Annotationで警告を与えることはできる ● 言語レベルで完全なアクセス制御を行うことができない ● `@internal`
Annotationを付与することで、警告を与えることができる ○ classのAnnotationとしても有効で、意図しない exportを防げる ○ `@protected` `@visibleForTesting`など、アクセス制御用の Annotationが用意されている ○ https://api.flutter.dev/flutter/meta/internal-constant.html ● Analyzerと組み合わせることで、意図しないアクセスを抑制できる
49.
現代的なアプリ開発において、 Analyzerの存在は不可欠である
50.
Analyzerの利用
51.
● `flutter analyze`
コマンドでAnalyze(静的解析)を行える ● 正確・迅速に問題点を把握できる ● コンパイラとは違うレイヤーの問題を発見する ○ コンパイラは言語レベルでの問題検出 ○ Analyzerはコーディングルールの問題検出 ● Analyzerが発見した問題は適切な解決方法がガイドされる Flutter標準のコマンドを利用する
52.
Analyzerは必ず設定する ● Analyzerはコード品質の向上に非常に有用である ● Analyzerは開発者の「気を付ける」よりもずっと信頼できる ●
可能な限り全てのモジュールにAnalyzerを導入する ● Flutter 2.5以降で標準で導入されるようになった ○ 無視しているなら今すぐ警告を直そう!
53.
Analyzerの共通化
54.
Analyzerのメンテナンスを簡略化する ● analysis_options.yamlファイルはinclude文が使える ● 共通のanalysis_options.yamlファイルを用意し、他のモジュールはこれをinclude することで共通化する
55.
Analyzerは最新に保つ
56.
Analyzerは導入して終わりではない ● Analyzer(Lint)は適宜アップデートされている ○ flutter_lintsのバージョンを確認してみよう ○
https://pub.dev/packages/flutter_lints ● Flutter / Analyzerバージョンを最新に保つ + Analyzerを有効化するだけでコード品 質の改善に役立つ
57.
意図しない直接importを防ぐ ● これだけは絶対に有効にしておく ● depend_on_referenced_packages ○
https://dart-lang.github.io/linter/lints/depend_on_referenced_packages.html ● pubspec.yamlのdependenciesに記述されていないライブラリを使用している ○ コンパイラレベルでは、 「依存しているライブラリが依存しているライブラリ ....」の使用を防げない ○ モジュールを分割して隠蔽したつもりなのに依存している、という問題を可視化する ○ 「内部でしか使ってないはずだから」と思ってライブラリを切り替えたら大混乱 ...を防ぐ
58.
Continuous Integrationの問題
59.
並列化しすぎるとコストが増大する ● Github ActionsのJobを並列化することでテスト速度を最適化しようとした ○
100モジュールを、100の並列実行で短時間に終了させることができた ● 1つのJobが高速化する代わりにオーバーヘッドが大きくなった ○ cloneやpub get、キャッシュ操作などの 1実行に対するオーバーヘッドが 100倍になった ○ 実時間3分程度で完了するが、 100並列あるので1実行300分の課金となる ○ コミッター×コミット数で加速度的に課金が増える ● 「Jobの実行時間が15分を超えたら分割する」というポリシーで対応した ○ 現在はモジュールを 7つのグループに区切って実行している ○ 実時間11分、課金時間60分程度となっている ■ Github Actionsで1回のCI実行につき$0.5程度となる
60.
開発環境が高スペックを要求する問題
61.
開発環境が非常に高スペックを要求する ● モジュール数に比例して開発環境がメモリを要求する ● VIVIWARE
Cell Plusの場合、最大で30GB程度のメモリを消費していた ● エミュレータなどの実行環境も加わるとさらに消費
62.
銀の弾丸はない
63.
金の弾丸を使う
64.
RAMを増設する ● メモリはPCのパーツとして安価な部類である ● 金はエンジニアのスキルに関係なく、平等に解決してくれる ●
Macbookなど、増設できないマシンを購入するさいはケチらずいこう ● 2022年現在はメモリ64GBを搭載していると安心できる
65.
最近の良い話
66.
Flutterバージョンアップでメモリ使用量改善 ● 最近のFlutterアップデートでメモリ使用量が大幅改善 ● 開発環境の消費量が5GB弱に低減 ○
VIVIWARE Cell Plusの場合 ○ プロジェクト規模に依存する ● 開発環境は可能な限り最新を保つことが大事 ● CPUはビルド速度に直結するため、やはり金の弾丸は無駄にならない
67.
未解決問題
68.
多言語対応のモジュール分割
69.
Intlライブラリ + モノリシックアプリでの多言語対応 ●
言語ファイル(*.arb)を作成してコード生成を行う ● モノリシックであれば全ての言語が1モジュールに含まれていれば問題ない ● 公式ドキュメントではこの利用方法が解説されていた ● モジュールを分割する場合の方法が見つからなかった
70.
スマートな解決方法はなかった
71.
妥協案を採用した
72.
CSVファイルから変換する内製ツールを開発 ● CSVファイルにモジュールごとのリソースを記述 ● 文字列リソースアクセス用クラスが生成される 変換・生成
73.
モジュール内で文字列リソースにアクセス ● StringsMixInのインスタンスにアクセス
74.
全てのCSVが統合されたarbファイルを生成する ● 全モジュールのCSVを統合したarbファイルを生成 ● 生成後はIntlライブラリのドキュメントに従って扱う 統合
75.
依存しているモジュールの持つ文字列リソースを使用 ● MixInと組み合わせることで複数のモジュールの文字列を使用する ● Androidの文字列リソース管理と異なり、手動で組み合わせている
76.
モジュール間の文字列リソース共通化を解決したい ● Androidアプリ開発における文字列リソースの解決はそれなりにスマート ○ 依存しているモジュールが持つリソースは自動的に使用可能になる ●
是非ともFlutter公式も対応して欲しい ○ できればよりよくしてほしい( XMLではなく)
77.
必要であれば内製ツールも検討 参考: CSVからの変換ツールは2〜3日程度で検討と実装
78.
公式にマルチモジュール+ 多言語対応のサポートを求む (既にあるなら教えてください)
79.
まとめ
80.
プロジェクトが 短期間(数か月以内)に終了する場合、 オーバーヘッドが大きい
81.
長期的な開発・メンテナンスを考えれば、 プロジェクトへのマルチモジュール適用は非常 に大きなリターンがある
Download now