最近、自分の職場で Working Out Loud という考え方が流行っている気がする。 Working Out Loud については、以下記事を参照されたし。 自分が大切にしている Working Out Loud という考え方 - freee Developers Hub
このやり方は結構自分の仕事のやり方にあっていて、times でちょこちょこつぶやきながらタスクを進めるのが好きだ。 times でつぶやいた直後に解決策が閃いたりすることが何度もあって、言語化して公開することって大事だなって思う。
一方で、"内圧" という考え方もあるらしい。
なるほど。これはこれでそのような気もする。 自分がブログに何かを書くときは、ある程度自分の中で溜め込んで考えてから書いたりする。
もしかしたら、"問題解決"と"アイデア出し"ではアプローチが異なるのかもしれない。 今度から「これは問題解決か？アイデアだしか？」という視点で切り分けてみて、考えるアプローチを切り替えてみるのも面白いかも。
生産性 = 成果量 / かけたリソース
個人で仕事をしている場合、分母のかけたリソースっていうのは、大体が「時間」になると思う。 この場合、やらないことを決めたら、その分の時間が減る。 つまり分母が小さくなる。 しかも、"やるべきこと"に集中できるため、成果量も大きくなる。 これは、"やるべきこと"のクオリティが上がるため。 もちろん、"こと"の手数が減るから物質量は減るかもしれない。 でも同時に"やるべきこと"の質量が上がるため、成果量としては大きくなると思う。 だから、"やらないこと"を決めた瞬間に、生産性は爆上がりする。のだ。
シンプルさの必要性を読んだ。 「これは、Simpleだろうか？」は常に考えていきたいと思った。まる。 まあただの感想なのだが、それだけでは記事が寂しくなるので、少しソフトウェアエンジニアリングの領域で考えてみる。
以下の記事もSimpleとEasyの話なのかもしれない。どうしても、チームに導入する技術はeasyによりがちになる気がした。これをsimpleに倒すには考え抜いてからプレゼンをする必要がある。この考え抜く行為が技術選定なのかもしれない。
あと、レイヤー跨ぐときにいちいちDTOに詰め込むのめんどくさいと思っていたけど、これをきちんとやっっていたらマイクロサービスで切り離すときに、そのままAPIにすれば良いだけになる。これはSimpleだなと。 ただ、開発体験がEasyではなくなる。いっぱいファイル作らないといけない。 でも、ドメインモデルをそのまま渡したりするのは、Simpleではない気がする。 ここら辺のバランスをどう取ったら良いのかわからない。 Domain Modeling Made Functional あたりに書いてそうな気はする。関数型というのはそういう時にSimpleなんじゃないかと思っている。
表題の通り、テストコードであるクラスをモックしようとして、@GenerateMocksで指定したのに、コード生成がされなかった。
flutter pub run build_runner build コマンド自体は成功する。
[SEVERE] Conflicting outputs were detected and the build is unable to prompt for permission to remove them. These outputs must be removed manually or the build can be run with `--delete-conflicting-outputs`. The outputs are: lib/fuga/hoge.dart
標準出力をよく見ると上記があった。 試しに言われた通りに以下のコマンドを実行してみると、生成された。
flutter pub run build_runner build --delete-conflicting-outputs
表題の通り
flutter_local_notificationsのドキュメントに書いていた。
https://pub.dev/packages/flutter_local_notifications#requesting-permissions-on-android-13-or-higher
以下のコードを書いて、パーミッションリクエストの制御をした。
bool? isAllowed = await _notificationsPlugin
.resolvePlatformSpecificImplementation<
AndroidFlutterLocalNotificationsPlugin>()
?.requestPermission();
if (isAllowed == true) {
logger.i('Notification permission granted');
} else {
logger.i('Notification permission not granted');
}
最近、「Progressive Delivery」 という言葉を巷で耳にすることが多くなった。 Kubernetes上でProgressive Deliveryを実現するOperatorとしてFlaggerがある。 それらが何かを掴みつつあるので、ここにまとめておく。
Progressive Deliveryとは、順繰りにステップを踏んでリリースをするのを自動で行う方式だと理解している（3%->10%->20%->100%みたいな）。 リリースが自動で行われるのが肝要なのだろう。 自動でメトリクスを解析してOKなら次のステップに、NGならロールバックというふうに。
FlaggerやArgo Rolloutsというのは、そのメトリクス解析の条件式(PromeQLとか)やステップの記述を設定ファイルに書いておくだけで、Progressive Deliveryを実現してくれるもの。という理解でいる。
Canaryリリースをするのであれば、Serviceのselectorを使ってPodへの振り分けによる分散もできる。 しかし、これをするとマニフェストを読んだだけだと、Canaryと本番の構成が分かりにくい。
この設定を宣言的に書けるというのも利点である。
サービスメッシュが何かあんまり分かっていない。 Progressive Deliveryの文脈から見たら、Podへの通信を設定通りに分散してくれるやつというイメージしかない。 何かを掴んだらまたブログにまとめたい。
マイクロサービスが流行ってるからかなとか思っている。 デプロイするコンポーネントが増えたけど、それら全てに対していちいち、「ポチポチしてCanaryリリースしてGrafana・Podのログ確認して、ポチポチして本番リリースして、、、」みたいな手順をしていたら日が暮れてしまう。 だから自動でロールバック含めて行うというのが必要になったから。では。
