【Jetpack Compose】ChatGPT のようなアニメーションの @Composable AnimationText

画面がなんとなく元気になります。

Jetpack Compose AnimationText like ChatGPT



 

💬 実装

LaunchedEffect() のラムダ内は CoroutineScope なので delay() でお好みのスピードで。

JaetpackCompose は、なかなかメモリーリークしないのがいいところ。

 

💬 まとめ

アプリで公開するとすれば、最低でも WEB の UI を超えた機能を実装しなければなりません。

先人たちが公開されている UI の機能を取り込んでいきましょう。

Android Studio Flamingo 隠された新デザイン「New UI」を有効化する2つの方法 🐦

安定版「Android Studio Flamingo | 2022.2.1」にアップデートしてがっかりしていましたが。

👉 Android Studio Flamingo | 2022.2.1 安定版公開される hatena-bookmark

元々、IDEA Intellij に入ってた「New UI」ですが、

Update: The beta version of the new UI is available to all users in the 2022.3 release.
Go to Settings | Appearance & Behavior | New UI to enable it.

👉 Take Part in the New UI Preview for Your JetBrains IDE | The IntelliJ IDEA Blog hatena-bookmark

今現在「Android Studio Flamingo | 2022.2.1」では、デフォルトで無効化しているようで、実際には機能は同梱されてるようです。

有効化してみましょう。

 

🐦 Registry から適用する

上部メニューから、


[Help]

  ↓

[Find Action]

  ↓

[Registry...]

  ↓

[ide.experimental.ui.***] をチェック

以下のように進んでいきチェックを入れたら Android Studio 再起動です。

How to enable Android Studio new ui

GUI部分のテーマやアイコンが新しいものになり、構成もすっきりした感じになります。

または、キーボードショートカットからでも、Registry 画面にいけます。

👉 How to enable Android Studio new ui - Stack Overflow hatena-bookmark

 

🐦 プラグインを使う

このツイート。


WEBページから .jar をダウンロードして、Plugins から import します。

Enable new UI
Android Studio 2022.2 has a new UI that can be unlocked with a plugin. While the official plugin is in closed beta, we’ve made an equivalent plugin that does the job and unlocks the new UI with the same settings and new color schemes.

👉 Hueflake for Android Studio · Hueflake hatena-bookmark

こちらも再起動で綺麗に適用されます。

 

🐦 まとめ

どこか具合が悪いのか、未検証なのか謎ですが、新デザインでまあモチベーションは上がります。

問題あるようなら戻したいと思います。


テストの「Mock(モック)」についての著名ソフトウエアエンジニアはどう思っているか🤔

職場や開発環境や対象となるサービスによっては、テストが「だるすぎ」と思えることがあります。

世界的に著名な方々の意見が気になりますよね。

どのように心得て書くべきか、というようなことをまとめてくれています。

「Mock」についてです。

👉 Unit Testing Experts on Mocks | Perry Street Software Engineering hatena-bookmark

 

👨‍💻 Martin Fowler

In classic tests, many people like the fact that client tests may catch errors that the main tests for an object may have missed, particularly probing areas where classes interact. Mockist tests lose that quality. In addition you also run the risk that expectations on mockist tests can be incorrect, resulting in unit tests that run green but mask inherent errors

When you write a mockist test, you are testing the outbound calls of the SUT to ensure it talks properly to its suppliers. A classic test only cares about the final state — not how that state was derived. Mockist tests are thus more coupled to the implementation of a method. Coupling to the implementation also interferes with refactoring, since implementation changes are much more likely to break tests than with classic testing.

I don’t see any compelling benefits for mockist TDD, and am concerned about the consequences of coupling tests to implementation. I really like the fact that while writing the test you focus on the result of the behavior, not how it’s done. A mockist is constantly thinking about how the SUT is going to be implemented in order to write the expectations. This feels really unnatural to me.

  • クライアントテストがオブジェクトのメインテストでは見逃す可能性があるエラーをキャッチできる。
  • クラス同士がやりとりする領域を調査することができる。
  • 期待値が誤っている場合、単体テストが通過し、本来のエラーが隠蔽される可能性がある。
  • メソッドの実装により結合しやすいため、クラシックテストよりもテストが破綻する可能性が高くなる。

👉 Mocks Aren't Stubs hatena-bookmark

 

👨‍💻 Robert C. Martin (Uncle Bob)

Mocking the interactions between all classes forces you to create mocks that return other mocks (that might return yet other mocks). You have to mock out all the data pathways in the interaction; and that can be a complex task. This creates two problems. 1. The setup code can get extremely complicated. 2. The mocking structure become tightly coupled to implementation details causing many tests to break when those details are modified.

The need to mock every class interaction forces an explosion of polymorphic interfaces. In statically typed languages like Java, that means the creation of lots of extra interface classes whose sole purpose is to allow mocking. This is over-abstraction and the dreaded ‘design damage’.

I recommend that you mock sparingly. Find a way to test — design a way to test — your code so that it doesn’t require a mock.

  • インタラクションをシミュレートするための便利なツール。
  • クラス同士のインタラクションをすべてモックする必要があるため、セットアップコードが複雑になる。
  • モックの構造は実装の詳細に密接に結合するため、実装の変更により多くのテストが破綻する可能性がある。
  • ポリモーフィックなインターフェースが必要となるため、設計上の過剰な抽象化が生じる可能性がある。

👉 Clean Coder Blog hatena-bookmark

 

👨‍💻 Kent Beck

I mock almost nothing. If I can’t figure out how to test efficiently with the real stuff, I find another way of creating a feedback loop for myself.

If I use TDD, I can refactor stuff. And then I heard these stories people say that they use TDD and now they can’t refactor anything. I couldn’t understand that and then I started looking at their tests: If you have mocks returning mocks, returning mocks, your test is completely coupled to the implementation, not the interface, but the exact implementation. Of course you can’t change anything without breaking the test. That for me is too high a price to pay, that’s not a trade-off I’m willing to make.

  • ほとんど使用しない。
  • 多重に入り組んでいると、テストが実装に結合しすぎるため、実装の変更が難しくなる。

👉 TW Hangouts | Is TDD dead? - YouTube hatena-bookmark

 

👨‍💻 Ian Cooper

When we refactored something all these tests with mocks broke and we had to rewrite all the mocks. It was kind of puzzling because the promise was that we should be able to refactor our code, because our tests would enable us to refactor and refactoring kept our code healthy. But the tests were an obstacle to that change, since they were breaking when we changed our implementation details.

Avoid heavy mocking. This allows you to meet the promise to refactoring. You will refactor your code and your tests won’t break.

Mocks are useful when a resource is expensive to create, but the problem with mock objects essentially is that people have used them to isolate classes. Don’t do that.

  • リソースを作成するのがコストが高い場合に便利である。
  • オブジェクトを使用すると、クラスを分離するために使用された場合、リファクタリングが非常に困難になる可能性がある。
  • ヘビーなモックは避けるべきである。

👉 🚀 TDD, Where Did It All Go Wrong (Ian Cooper) - YouTube hatena-bookmark

 

👨‍💻 まとめ

大まかにまとめると以下の3つ。

Mock はインタラクション（やり取り/相互作用）の確認が目的である。

リソース作成のコストが高い場合に便利。

実装と密になるので、実装は変更はしづらくなっていく。

ホンマもんのエンジニアの方々に口を揃えて言われるとスッキリします。