Flutterメモ 始めます
Flutterメモ始めます。
バイトで溜まってきたメモをもとに個人開発のアプリを作りながら、それを例に説明していけたらいいなあ、と思ってます。
以下のような感じで進めていきたい
- Flutter導入・開発環境のセットアップ
- Flutterの基本UIパーツ(Widget)
- Flutterの状態管理(setState・BLoC)
- Flutterでアニメーション
- Flutterのレイアウト・レスポンシブ
- 使ったライブラリ紹介
- その他ハマりどころ等
今回は以下のガイドライン(後でまたちゃんと更新します)に沿って書いていく予定です
- コードだけを載せない。
- 動作の様子をgifなどの動画で説明
- 図を用いた説明が可能であれば図を用いる
- 参考文献を載せる
- 無理に自分の言葉で説明をしない(よりわかりやすい資料があればそれを紹介するだけの方が良い)
11章 DIP 依存性逆転の原則 アジャイルソフトウェア開発の奥義
- 抽象(抽象クラス・interface)に依存せよ
- 再利用や拡張の可能性が低いものはDIPしなくて良い
- 依存の方向は本来ならA use B なら A -> B。Bを変えるとAに影響が及ぶ。
- 逆転させると、A use B は変わらないまま、 A <- B とできる。実際は、A -> インターフェース <- B 。抽象化されたインターフェースを介することで、AはBの知らなくていい部分の実装を知らなくてすむようにする。ということは、Bの実装が変わってもAには影響が及ばない。というより、影響が及ばないように実装するのだ
- A <- B だとしても、Aが変更されたからといってBに影響が及ぶわけではない。その場合おそらく A does not use B なのだから。
アジャイルソフトウェア開発の奥義のメモ 14章
14章 継承と委譲 template method と strategy の違い
http://yusuke-ujitoko.hatenablog.com/entry/2009/12/29/000000
https://www.slideshare.net/mobile/gaaupp/ss-36273759
これらの記事でも述べられているが、
Strategyの方は，細かいパーツをinterfaceとして用意し、それを使って全く異なるアルゴリズムにごっそり差し替えられるようにしておくためのパターン。
Templateメソッドパターンはあるアルゴリズムを使う前提で、アルゴリズムの大きな流れのテンプレートを継承して拡張できるようにするためのパターン。
Strategyパターンでは、ソートの方法(実装)とソートに使う基本的な計算のパーツとに分けておき、そのパーツだけをinterfaceに切り出しておく。つまりパーツは使いまわせるが、必ずしもバブルソートという具体的なソートの方法のために使う必要はない状態になっている。
Template methodパターンでは、抽象クラスがソートの方法と計算のパーツの両方を知っているということになってしまっている。これではこの二つは分けられず、計算のパーツだけを使いまわして別の新しいアルゴリズムに切り替えるということがやりにくい。
書籍では継承と委譲という対比で書かれているが、責務の切り出しの大小の違いと考えた方が良さそう。 Strategyパターンが優れていると書かれているが、実際にはおそらく場合によって責務の切り出しが必要でないような場合にはTemplate methodを使った方が単純で見通しが良い場合もあるはず。
学生エンジニアによるtry! Swift Tokyo 2019感想
初めてのプログラミング系カンファレンス参加
僕はSwift歴2年程度(趣味なのでレベルは低めですが)ですが、初めてのカンファレンス参加でした。
try! Swift Tokyo 2019というSwiftというプログラミング言語関連のカンファレンス(講演会)に参加してきたのでその感想です。
注：発表はしてません。
Swiftのマニアックで深い議論
発表の内容としては、普段あまり聞いたことのないような話が多かったです。
正直ほとんどついていけませんでしたが、ライブラリの開発者の方など最先端の技術動向が知れる内容で、レベルの高そうな方でもあまり知らないという感じの内容も多かったので、ある意味レベルに関係なく楽しめる内容だったのではないかと思います。
割と業務向けの話というよりはかなり限定的な用途で使えるような話も2、3割くらいありました。
「ARKitのアプリを作ろう」 speakerdeck.com
ラズパイでSwiftを動かす話
www.slideshare.net
SwiftのType Metadataを活用する話（全然理解がおいつきませんでした）
「アセンブリ、君ならできる！」
あまり使っていなかったアセンブリを使ったデバッグ方法を知れたので立ち往生した時の解決方法の引き出しが増えた気になりました
https://www.andrewmadsen.com/AssemblySlides.pdf
デザイン(UI・アプリケーション設計)の話も多い
Human Interface Guidelineをちゃんと読みたくなりました。
ネイティブアプリっぽいアプリとはどんなもの？デザインの本質に踏み込んだ話
パーツ同士の色のコントラストについて深く考える話
https://raw.githubusercontent.com/emarley/ColorContrast/master/ColorContrast.pdf
デザインシステムの話（マテリアルデザインみたいなの）
開発者としての価値観やマインドについての話も
以下の二つの発表では、開発者としてのマインドの持ち方や人種に対する偏見や環境の違い(お金がなくてmacが買えない人が意外と多いなど)の話もあって、こういう発表もありなんだと思うと同時に、結構評判が良い印象を受けました。
文字起こし資料
文字起こし資料
休憩時間やパーティーでお話ししたり
休憩時間やパーティで、他の参加者の方とコミュニケーションを取ることもtry! Swiftでは推奨されてました。 僕は結構こういう場で話すのが苦手で技術的なコンプレックスもあってあまり話せなかったのが残念でした。 結構先輩の社会人の方から色々とお話を聞かせていただくだけになってしまったので、次回は自分にしかない経験をたっぷりと用意して行きたいですね。
ワークショップは手厚くサポートしてくれる
ワークショップもありました。僕はServer Side Swiftのハンズオンコースだったんですが、いい感じにハンズオンを区切ってくれて質問がしやすい環境で、そのテーマに詳しくない人でも問題なくついていけるようになっていました。
ハンズオン資料
意外とガチ勢ばかりではない
意外とSwift歴1年程度(僕があった人はほぼ業務で触ってましたが)の方も多く、雑談の際の話が合わないというレベルではなかったように思います。（そもそも技術的な話というよりは、作っているものの内容やどんな開発体制をとっているか（何言語か、どんなチームかなど）という話が多かったです）
みなさんもぜひtry!してみては
はじめてのカンファレンスで結構反省すべきところも多かったですが、参加して良かったと思える素晴らしいカンファレンスでした！
少しでも興味のある方はぜひ参加してみてはいかがでしょうか。
Djangoのfunction based viewとclass based viewの違い・メリット・デメリットを調べた
DjangoにはRailsなどと異なり、class based viewとfunction based viewという概念があります。MTVで言う所のView、MVCでいうところのControllerにあたる所のメソッドの定義の仕方に２通りメジャーなやり方があるという感じになっています。
調べてみた
この記事が詳しかったです
以下、上の記事で挙げられていた中で自分が大事だなと思った違い（メリット）をあげます。もっと知りたい人は上の記事を参照してください。
class based viewの主なメリット
- 継承が使える
- コードが少なくなる
- 一覧などのテンプレコードを使い回すこと（再利用）ができる
- HTTPのメソッドがそのままクラスのメソッドになり 、わかりやすい
class based viewの主なデメリット
- コードが読みづらい
- デコレータが使いづらい
- 継承やmixinが複雑になることがある
function based viewの主なメリット
- 実装がシンプルで、読みやすい
- 関数なので、デコレータが使いやすい
function based viewの主なデメリット
- 再利用しづらい
- GET, POSTなどを関数内で分岐させないといけない
思ったこと
function based viewの実装がシンプルで読みやすいというのがいまいちわからなかったです。シンプルなのは確かに基本的に一つの関数だけで完結するため（内部で別の関数を呼ぶことはもちろんあるが）ということかもしれないが、読みやすいというのはどうなんだろう。クラスを使わない分、メンバを気にする必要がなく、関数の中にある変数だけを気にすればいいため、コードを読むとき目を比較的上下させなくていいことや、必然的に継承ではなく委譲を使うことになるためだろうか。
ちなみに、フロントエンドを描きやすくするためにReactやVue、Angularなどを使ってバックエンドはAPIにするという形をとるのが主流な現在では、RESTに則ってGET, POST, PUT, DELETEを活用するため、それらをクラスのメソッドとして実装できるclass based viewが優勢なのかもしれません。
多分今後APIを作るときは、class based viewを使うと思います。
今後に活かしたい
DjangoはDRYの原則に乗っ取ったつくりになっていることを考えると、class based viewの方がいいのかもしれません。いままでなんとなくfunction based viewを使っていましたが、メリットを活かして書いていけるよう意識していこうと思います。
