DropDownButtonのselectedItemBuilderを初めて活かせた話

Flutterにはドロップダウンリストを作るためのDropDownButtonがありますが、このクラスのプロパティの一つである selectedItemBuilder が正直何に使うのか分からなかったけど初めて活かせた話をします。

selectedItemBuilderとは何なのか？

こちらを参照👀

api.flutter.dev

デモにもあるように「ドロップダウンリストに表示される項目名」と「選択後に表示される項目名」を変えたい時に使うプロパティになります。
ただ、これだけ見ると「何のために存在してるんや？」ってずっと疑問に思っていました。

どう活かしたのか？

んじゃ実際にそれをどう活かしたのかというと、以下のようなドロップダウンリストを作るために活かしました。

• 生年月日の「年」のデフォルトは「年」で表示

• 選択中項目は「1992」にして、デフォルトの"選択年"も1992にする

• 何も選択せずに閉じるとデフォルト選択年の1992が設定される

タップするまではよくある hint プロパティの表示っぽく見せて、タップしたらデフォルトで選択される1992に選択されている状態にしたいという仕様でした。
で、これを解決するために selectedItemBuilder を活用したわけです。

必要なところ以外のコードはバッサリ切って説明するのですが、

• 初期状態では何も選択されていないことを表しておく（選択年を司る変数を0にでも設定しておく）
• selectedItemBuilder で「何も選択されていないなら"年"を表示」「なにか選択されていれば選択された年を表示」の条件分岐を書く
• タップされた時にデフォルトで選択される年を選択年を司る変数にセットし、ステートの変更を通知する

を行います。

コードで表すとこんな感じです（状態管理にはGetXを使用）

色んな必要なものを省いていて恐縮ですが、主にこんな感じのコードを書くとできます。

こういうことに使えるんだな〜と思ったので書き留めておきました。誰かの役に立つことを祈る🙏

GKEノードの自動アップグレードを監視する

所属しているチームでは様々なイベントを監視し、Slackのモニタリングチャンネルへ通知を飛ばしています。

※ エラーログではエラーが発生したCloud Loggingのリンクが貼り付けており、詳細を追従しやすくなっています

この中で、PodのCreate / Deleteを監視しているのですが（画像のPodのデプロイの通知）、デプロイ以外にもGKEノードの自動アップグレードでも通知が飛ぶためその度に「なんで通知走ってるんだっけ？」といった会話がされることがありました。（突然来ると不気味ですしね）

そこで、GKEノードの自動アップグレードがあった際にはSlackへ通知を飛ばすようにしました。

何をしたか？

やったこととしては自動アップグレードイベントを監視するログルーターを作成し、そこからPubSubを通してCloud Functionsを実行し、Slackへ通知を飛ばすようにしています。
今ではCloud Functionsなどを通さずに、ログベースのアラート機能を使うのがベターかもしません。

cloud.google.com

で、通知を飛ばすまでの処理は他の方々の記事で書いてあると思いますので割愛しまして、肝心要の監視するログは以下のようになります。

さて、これでSlackへ通知を飛ばすようにするとこんな感じに。

先程のPodのデプロイの後に自動アップグレードイベントからの通知が来てますね！
ちょっとしたTipsなのですが監視を強化したい方は是非〜

Flutterでログイン後に再インストールしたらログイン済みのままなのをどうにかした

相変わらずFlutterやってるおじさんです。

今回はFirebase Authenticateを用いてログイン済みのユーザーが、アプリを再インストールしたらログイン済みのままになっていたのが気持ち悪いのでどうにかしました。

何故そうなったか？

iOS, Androidともに裏でバックアップを取っていますが（Android: Google Drive, iOS: keychainを使いバックアップ）、これをdisableにしようと思うとAndroidは以下のようにすればいいので簡単ですが、iOSだとちと骨が折れる作業となります。

• AndroidManifest.xml

<application
    android:allowBackup="false"
>
</applicatoin>

そこで、 shared preferences を使って「インストール後、初めて起動した場合にはログアウトさせる」という処理を噛ませることにしました。

pub.dev

基本的な使い方についてはこちらで詳しくまとまってました。

www.virment.com

で、肝心の実装ですが必ず最初に通る main.dart に対して以下のようなコードを実装しました。

shared preferencesで保存した値はアンインストール時に揮発しますので、再インストール時でも問題なくログアウトされます。
こっちの方が楽なのでこういう形で実装しましたが、他に良い方法を知っている方がいらっしゃいましたら教えて下さい！

2021年の振り返り

今年もあっという間に過ぎて１年の振り返りをする時期になりました。
振り返ればブログを開始してから12年経過し、干支も一周するくらい続けてきたなぁと我ながら驚いています。

そんなこんなで今年１年やってきたことを振り返ります。

1 ~ 3月

1 ~ 3月は仕事で開発しているサービスのリリースに向けて、シコシコと開発しておりました。
RoR / GraphQL / Next.js / TypeScript / k8s と割りかし技術的に面白い構成で開発が出来て楽しかったなぁという感じでした。

特にGraphQLは出始めの頃に触った時よりも断然使いやすくなっていて時代の進歩を感じました。

4 ~ 6月

無事サービスのリリースを終えて、開発する傍らGraphQLの負荷検証とかをやっていました。
RoRのGraphQLライブラリである rmosolgo/graphql-ruby を使っていますが、レスポンスサイズが大きすぎるとかなりのレスポンスタイムになるよねみたいなのが問題としてあるので、そういうところは注意が必要みたいなtipsをコツコツ溜めておりました。

github.com

後はインフラ触れる人を増やしたかったので、啓蒙作業のための資料作りなどをやったりしていました。
インフラ触るのに興味持ってもらうの難しいですね🤔

7 ~ 9月

この頃から記事でも書いた開発環境の使用状況分かるくんの開発を開始しました。
それまではサービスの立ち上げに必要な最小限のメンバーで回していたのですが、メンバーが増えるに従って何かしらの仕組みの必要性を感じたために 作り始めた次第ですね。

また、サービス内の検索UIのバージョンアップを行う中でCSSアニメーションを初めて触ったり新しい体験も幾つかありました。

10 ~ 12月

会社から「GCPの資格試験無料で受けれるよ」というお達しに飛びついたので勉強したり、チームが上手く回るための仕組み作りを考え実行したりしていた時期でした。
ポストモーテムを書く習慣作りや、インシデント対応のマニュアルを作ったり・・・

開発面だと負荷検証環境をLocustで構築したりしました。あとローカルで負荷かける時はvegeta使ってたんですが、ちょっと信用ならん結果出しまくってたのでk6に乗り換えました。惰性で使ってるツールはたまには見直さんとダメですね。

会社のアドベントカレンダーにも参加しましたが、まさかあんなにブックマークされるとは思わずビックリしました。
どうせ誰も見ないだろ〜と思ってましたが意外にも需要があるということが分かったので、仕事で得た知識をもうちょっと外に出すことを来年の目標にしたいです。

まとめ

今年もギリギリ生き残れた気がしました。ただ段々と自分の脳みそが衰えてきているのでもっと喝入れて性能戻さんとダメですね・・・
来年も頑張って生き抜こう。

「開発環境の使用状況分かるくん」を作って冗長コミュニケーションを無くした話

本記事は ミクシィグループ Advent Calendar 2021 の22日目の記事です。

前置き

私が現在所属しているプロジェクトでは「アプリケーション × 4 + 開発環境 × 3」という環境で開発しており、機能開発後のQA作業などのため常に３つある開発環境がどこかしら使われているという状況でした。
（ちなみに Fansta（ファンスタ） というプロジェクトですので、興味のある方は @syossan27 までご連絡を！）

そのため開発環境の使用状況をtrelloを使い管理していましたが、新しく開発環境へデプロイする際にはSlackでデプロイしても大丈夫か尋ねる、という流れが定常化しておりました。
このままでも良いのですが、ここはエンジニアとしてこのような冗長コミュニケーションを無くすために技術を使おうじゃないかと思い立ち、カッとなって掲題の「開発環境の使用状況分かるくん」を作成し始めました。

• 開始

  便利ツール作るおじさんになるか

  — しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) 2021年7月9日

• 終わり

  ファ〜〜〜〜〜どこになにがデプロイされたかが分かる君１号が完成した

  — しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) 2021年7月23日

※「どこになにがデプロイされたかが分かる君１号」は開発中の仮称となります

結局、業務時間のスキマ時間を使ってちまちま書いてたら２週間ちょいかかってしまいました。
そして出来たのがこれ！

※左列のアプリ名は別名にマスキングしています

さてはて、この開発環境の使用状況分かるくんの概要と技術詳解を書いていきます。

開発環境の使用状況分かるくん - 概要

画像からも分かるように、開発環境の使用状況分かるくんは各開発環境とアプリケーションのマトリクスで使用状況を表示しています。
これで「今、dev1環境のアプリ１を使っている方いますか？」などの冗長コミュニケーションは防げますね！また、使用状況以外に「何の目的で使用しているのか？」が分かるように「使用中」「空」と書かれている箇所を押下することで、デプロイしたPull Request（以下PR）、またはコミットへ遷移するようになっています。

この開発環境の使用状況分かるくん、一体どこで表示しているかというとGitHubのREADME.md上になります。CLI作って表示させるとかも考えたのですが、「そういえばGitHubのREADME.mdでも表示出来るんじゃない？」と思い付き、エンジニア的にも一番GitHubは見るだろうということでREADME.mdに表示させています。（これが後々面倒なことに...）

あとは、表示させている「使用中」「空」がどのように切り替わるかというと、以下の４つをトリガーに切り替わります。

• PRにて deploy dev_1 といったようなデプロイコメントをすることでデプロイ＆「使用中」へ切り替え
• デプロイコメントをしたPRのマージ or クローズで「空」へ切り替え
• デプロイタグをpushすることでデプロイ＆「使用中」へ切り替え
• 「未使用に切り替え」ボタンの押下で「空」へ切り替え

このような機能になっており、今の所はうまくワークしております。

開発環境の使用状況分かるくん - 技術詳解

ここからが本題の技術詳解です。
とは言ってもそこまで難しいことも無く、構成要素としては以下になります。

• GitHub Actions : デプロイのタグ付け、使用状況データの更新、GitHub Image CDNのキャッシュパージ
• Cloud Functions : デプロイしたPR・コミットへの遷移処理、未使用に切り替えボタン処理
• Cloud Storage : 各開発環境・各サービス毎の使用状況データの格納
• CircleCI : デプロイ処理

これら４つの要素を組み合わせて、使用中/空の切り替えを以下のように行っています。

使用中切り替え

使用中への切り替えは先述したように

• PRにて deploy dev_1 といったようなデプロイコメントをすることでデプロイ＆「使用中」へ切り替え
• デプロイタグをpushすることでデプロイ＆「使用中」へ切り替え

の２つがトリガーとなっています。

デプロイコメントの方ではGitHub Actionsの issue_comment:created を使って、PRコメント/Issueコメントの２つの新規作成を契機に起動するようにしています。

その後if statementでデプロイコメントのみ後続処理へ進むようにし、

1. setup-gcloud を使ったGoogle Cloud SDKのセットアップ
2. github script を使ったPRのブランチを取得
3. リポジトリのチェックアウト
4. デプロイタグのpush
5. 使用状況画像を使用中画像へ置換
6. 遷移先テキストファイルの編集
7. GitHub image CDNのキャッシュをパージ

といった流れで処理していきます。キャッシュのパージは他のGitHub Actionsでも使うので、①~⑥の処理をするGitHub Actionsと⑦の処理をするGitHub Actionsでファイルを分けており、以下のような２ファイルがあるイメージです。

キャッシュのパージについては私が作ったアクションを使っています。詳細は以下の記事に書きましたが、GitHubのREADME.mdにある画像はGitHubのImage CDNにキャッシュされるため、変更を反映するためにキャッシュをパージしています。（これが先述していたREADME.mdに表示するようにしたことで面倒だったところ...）

syossan.hateblo.jp

デプロイコメントをトリガーとした切り替えは説明しましたので、次はデプロイタグをトリガーとした切り替えの説明に移ります。
とは言ったものの基本的な処理はデプロイコメントの場合とそう変わりません。

ちなみにデプロイコメントでデプロイタグをpushしていましたが、この際にデプロイタグのアクションは動きませんのでご安心ください。
（※GitHub Actionsをトリガーに実行する workflow_run 以外はアクションからアクションへの実行は動きません）

あとgithub scriptはめちゃくちゃ便利で、APIドキュメント見て頂けると分かる通りGitHubにおける操作は何でも出来るので使ってみると楽しいです。

github.com

空切り替え

空状態への切り替えですが、こちらは使用中への切り替えとは違いCloud Functionsを使った処理があります。
まずは先に「PRのマージ/クローズ」の実装例を見ていきましょう。

やっていることとしてはPRコメントの走査とデプロイコメントがあった場合の切り替え処理ですね。

次に「未使用に切り替え」ボタンの押下処理を見ていきます。こちらは今までと違い、GitHub Actionsを動かす前にCloud Functionsを挟んでいます。
まずはREADME.mdに配置するボタンは以下のように記述しています。

[![Run Action](ボタン画像URL)](https://[Cloud Functions URL]/example-function?env=app-1&num=1)

これでクリック時に所定のCloud Functionsが動きますので、次はCloud Functionsのコードを見ていきましょう。ちなみに今回は手慣れているGoをランタイムとして作成しました。

そしてCloud Functionsから動くGitHub Actionsが以下になります。

ここまででデータの変更について見てきましたが、最後に「使用中」「空」を押下した時のPR/Commitへの遷移処理を見ていきましょう。これは図にも示した通りCloud Functionsを通してCloud Storageにある遷移先テキストファイルを参照し、記述しているURLへ遷移する流れになります。

最後にREADME.mdに貼り付けるコードがこちらになります。

長くなりましたが、このようにGitHub ActionsやCloud Functionsを用いて開発環境の使用状況分かるくんを実現しています。

やってみて

今回の開発でGitHub Actionsを初めてガッツリ触りましたけど色々出来て面白いですね。大体の欲しいActionはMarket Placeに落ちているので、やりたいことはそれらの組み合わせで済むことが多いかと思います。

github.com

あとはREADME.mdの画像のキャッシュのところはめちゃくちゃ詰まりました。幸いにもこちらのmpywさんの記事を見て「あ〜なるほど〜」となり解決した次第です・・・🙏

qiita.com

久々に業務改善ツール作りましたが使ってくれる人が明確な分、作りやすいですし便利に使ってもらえるところを間近で見れるのはやっぱり良いですね。
皆も自分だけの最強の○○くんを作って日々の開発業務を楽にしよう！！！