@takamii228知は力なり2019-12-14FlutterでID/Password入力画面を作ってみるFlutterでID/Pass入力画面を作るときに設定するのパラメータをちょっと調べたのてまとめてみます。(※入力のバリデーションやオートフォーカス等のアクションは含みません)よくあるID/Pass入力画面の要件よくあるID/Passの入力画面の要件といえばこんな感じでしょうか。半角英数が入力できるPassword半角英数が入力できる入力内容はマスクしたい入力内容を確認したいので、マスクの表示非表示を切り替えられるようにしたい予測変換はさせたくないしヒストリーに記録なんてさせたくない入力欄のコピペはブロックしたい入力フォームはTextInputFiledを使えば実現できます。中でTextFieldをラップしているようです。API上記の要件に絡みそうなパラメータは以下の通りです。obscureText入力内容のマスク表示の切り替えautocorrectオートコレクト・予測変換の有効・無効化enableInteractiveSelection入力エリアのセレクトアクション(コピペ、選択、削除など)の有効・無効化TextInputType立ち上げるキーボードタイプ。APIdatetimeemailAddressmultilinenumberphonetexturlvisiblePassword今回の要件では、以下のような設定にするのがよさそうです。メールアドレスとかだとサジェストがあると嬉しいかもしれない。コピペしたいケースがありそうなので。IDがメールアドレスのケースも多く、とりあえず半角英数で立ち上がってほしいので。右端に目のアイコンを用意し、クリックで切り替えられるようにする。パスワードは守りたいので。コピペはブロックしたいので。パスワードを見せる専用のキーボードタイプ。v1.9.1+hotfix-6から使える模様。Widgetに上記の設定をしてiOS/Androidそれぞれエミュレータで動かしてみます。今回試したコードサンプルはこちら。garallyにもあり、今回の実装の参考にしました。github.com実行環境は以下の通りです。(simulator)挙動確認iOS想定通り動いてそうです。AndroidAndroidも大丈夫そうです。余談:TextInputTypeがvisiblePasswordじゃないとAndroidでautocorrectが効かないらしい。そもそもFlutterにはautocorrectのバグがあったようです。github.comこのバグの対処のために、最新のstableであるv1.12.13+hotfix.5ではenableSuggestionsというパラメータが追加されたようです。このパラメータ追加で予測変換を一律制御できるのかな〜と思ったのですがそもそもAndroidのみとのこと。IssueのコメントにあるようにTextInputType.textだと予測変換の無効化は効かない模様。入力のI/O周りはAndroidとiOSの両OSのモジュールをうまくラップして制御するのが難しいのでしょうかね。いえばWebやDesktopもあるんだった・・・。あと今回他のサービスはどうなってるのかな〜と思っていろいろ調べたのですが、ほとんどがWebViewでの入力画面が立ち上がるパターンでした。API経由で取得するシェルを書きました。${TAG_NAME},${TIMESTAMP_JST}donetag一覧の取得は/api/v4/projects/${PROJECT_ID}/repository/tagsのエンドポイントを叩くと取れます。https://docs.gitlab.com/ce/api/tag一覧の取得はページングのハンドリングが必要なので、レスポンスヘッダーのX-Total-Pagesからページ数を取得し、最終的にはfor文で回してjqで加工したものを連結します。タイムゾーンの設定によってはUTCで結果が帰ってくるので、最後にdateコマンドでJSTに変換しています。上記のシェルを実行すると以下のようなcsvが取得できます。1.5.0,2019-09-30T10:59:49.000Z1.4.0,2019-09-26T15:35:21.000Z1.3.2,2019-09-20T19:00:11.000Z1.3.1,2019-09-17T18:21:30.000Z1.3.0,2019-09-11T21:01:37.000Z1.2.0,2019-09-03T22:08:34.000Z1.1.0,2019-08-27T22:41:38.000Z1.0.2,2019-08-20T22:37:28.000Z1.0.1,2019-08-13T22:13:56.000Z1.0.0,2019-08-06T21:38:05.000Z0.3.0,2019-07-30T21:16:30.000Z0.2.0,2019-07-23T22:38:51.000Z0.1.0,2019-07-17T15:30:01.000ZあとはこれをSpreadSheetなりExcelなりPythonなりで集計すればリリース頻度の分析の集計ができます。APIを使ってtag名とtagのタイムスタンプをcsv形式で出力するTweet広告を非表示にするもっと読むコメントを書く2019-11-26master中心のブランチ戦略で開発している話ここ数年、CI/CDパイプラインを構築したりブランチ戦略を考えるロールで仕事をすることが多いのですが、ブランチ戦略はいつも頭を悩ませていました。Flowの採用を考えたりしたのですが、ブランチやマージの戦略がちょっと重厚でめんどうなだという印象を持っていました。「releaseブランチとかpre-productionとか管理面倒だからぶっちゃけmasterだけでよくね?」とふと思い、master中心のシンプルなブランチ戦略を考え、実践してみました。するとそれなりにうまく立ち回ることができるようになっていたので、整理もかねてまとめておきます。対象とするプロジェクト本ブランチ戦略は、以下のような開発チームに対してうまく機能できると考えています(※もちろんこの方法が最適な解とは限りません)バックエンド・フロントエンド・スマホアプリなど開発領域ごとにチームが別れているサービスを成立させるためには各チームが独立にリリースすることはできず、最終的には資材の同期を取る必要がある先に開発を終えたチームは次の案件の開発に着手しており、追加開発とリリース用の2つの資材を管理する必要がある開発チームメンバーは数人から20人程度masterをcleanに保つためのCIが整っている基本的な考え方master中心のブランチ戦略のベースとなる考え方は以下の通りです。Flow)を表すブランチはどこかのブランチにマージするか、マージしない場合は独立に更新を続け最終的には捨てるこの機能を入れる資材と入れない資材が必要、というときにブランチを切って開発の流れを分岐させるリリースバージョンはタグに紐づけるようにし、ブランチと実行環境は紐付けないこれら原則に従うことで、以下のようなメリットが得られます。Requestのマージ先はhotfix以外はすべてmasterになり、追加開発時のマージ先誤りの事故を防ぐことができるブランチと実行環境が分離されるため、環境管理とは独立して資材のバージョン管理ができる以下、実際にリリースの前・リリース後のブランチ戦略を説明していきます。リリース前のブランチ戦略リリース前のブランチ戦略は非常にシンプルです。masterブランチに対して、featureブランチ・bugfixブランチをマージすることで機能追加を反映していきます。初期開発時に利用するブランチは以下の通りです。CIが通ったもののみマージする。チケット番号と紐付ける。masterにマージしたら削除する。テスト・QA等で発覚したバグの修正用のブランチ。CIが通ったもののみマージする。チケット番号と紐付ける。masterにマージしたら削除する。このとき、成長するブランチはmasterブランチのみであり、チームメンバはmasterブランチのみを追いかけていればよいです。検証環境へのリリース資材を作成する場合はtagでバージョンとコミットハッシュを紐付けることでバージョン管理ができます(図のv0.1.0、v0.1.1)。リリース後のブランチ戦略ここでのリリース後、とは自分のチームの開発範囲のリリースを指します。バックエンドチームであればバックエンドのAPIのみのリリースを指します。バックエンドは順調に開発が進み先に環境へリリースできた一方で、フロントエンドは画面の仕様調整に難航しスケジュールが遅れてしまった、というケースはよくあると思います(逆もしかり)。このときバックエンドチームはフロントエンドチームの待ちの状態になるため、開発チームの余ったリソースを使って先に追加開発に着手し始めるケースがよくあります。このとき、masterブランチのみの運用だと本来のリリースには含めてはいけない資材が混じってしまう可能性があるため、フロントエンドの改修がバックエンドに波及したときのhotfixの対応を受け入れるために、masterとは別のproductionブランチを作成し2つの流れを作って運用します。productionブランチを作っておくことで、フロントエンドチームと同期をとったときの不具合のフローと追加開発のフローを分けて管理することができます(下図)。利用するブランチは以下の通りです。リリース後のブランチはリリース前にあったブランチに加えてproductionブランチとhotfixブランチが追加されています。最新のリリース版、リリースごとに作成する。リリース版にのみ緊急に反映させたいパッチがあればあてる。追加開発版のリリースが行われたら今まで使っていたproductionブランチは削除し、リリース対象のタグから新しいproductionブランチを作成する。CIが通ったもののみマージする。チケット番号と紐付ける。masterにマージしたら削除する。テスト・QA等で発覚したバグの修正用のブランチ。CIが通ったもののみマージする。チケット番号と紐付ける。masterにマージしたら削除する。リリース版バグ修正用のブランチ。CIが通ったもののみマージする。チケット番号と紐付ける。productionにのみパッチをあてる場合はproductionから切ってproductionにマージし削除する。master両方に必要なパッチの場合はそれぞれの根本から2本パッチを充ててそれぞれにマージし削除する。productionブランチは外部チームへの提供可能なバージョンのタグを切ったときに作成します。productionブランチにはリリースに必要なパッチや緊急のhotfixのみの変更が当てられます。hotfixのパッチは場合によってはデグレを防ぐためにmasterとproduction両方に当てる必要があります(※後述)。追加開発向けの機能追加はリリース前と同様です。リリース版で発覚したバグ修正のhotfixは、追加開発を行っている最新版のmasterに入れる場合と入れない場合とで以下のように対応を分けます。リリース版および最新版にもパッチを入れる場合(例:恒久的なバグ対応)hotfixブランチをproductionから切って、productionにマージするhotfixブランチをmasterからも切って、productionブランチへのhotfixと同様の変更を加えmasterにマージする(cherry-pickなどを使う)リリース版のみに入れるパッチの場合(例:ライブラリの緊急パッチ等の暫定対処)hotfixブランチをproductionから切って、productionにのみマージするhotfixの対応は一見複雑そうに見えますが、「masterが常に追加開発の最新版である」こと、「productionブランチがリリース版の最新版である」ことを考えると意外とシンプルにまとまっているのではないでしょうか。productionブランチはmasterには不要な変更を含んでいる場合があるため、masterにはマージしません。次のリリース版のtagが打たれたらまた新しいproductionブランチを作成します。Flow等がありますが、どちらも扱うブランチの種類が多かったりデプロイ先の環境と密結合に語られていて扱いにくい印象を持っていました。「masterを最新の安定版ブランチ」とする、というこのmaster中心のブランチ戦略を使うことで、シンプルで運用しやすい資材管理ができるようになったと個人的には考えています。興味を持たれた方はぜひ実践してみてください。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。