クリップボードにコピーしているテキストのコードポイントや Unicode/UTF-16 エスケープシーケンスを確認するスクリプト

クリップボードにコピーした以下のような文字

の構成とIDEで使いやすいエスケープシーケーンスを確認します。

Python や Android Studio エディター上で絵文字の編集が捗ると思って作ってみました。

クリップボードは生の絵文字データを保持できるので便利です。

UTF-16 サロゲートペア部分はもっと厳密に計算してもいいかもしれません。


テストの「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 はインタラクション（やり取り/相互作用）の確認が目的である。

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

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

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

プログラミング「ChatGPT にコーディングを依頼するだけ」は嘘？

こんな記事がありました。

👉 Jay Little - Software Obsessionist - Low Code Software Development Is A Lie hatena-bookmark

Sometimes a client falls into the trap of believing that there is some kind of silver bullet they can employ which will negate the inherent complexity around coding custom solutions. Nowadays the most cliche form of this is to say, "Well I'll just ask ChatGPT to code that for me". I call bullshit. While ChatGPT can handle some simple coding tasks, anything beyond that causes it to rapidly devolve into an unmanageable mess.

「コーディングの複雑さを解消する特効薬がある」という言葉を信じて罠に陥ることがあります。最近のこの決まり文句は「ChatGPT にコーディングを依頼するだけ」というものです。 私はデタラメだと思います。ChatGPT はいくつかの単純なコーディングタスクを処理できますが、その後急に、管理不能な混乱に陥ります。

Beyond the in vogue AI Chatbot example, there are a wide variety of other snake oil tools lingering about. All of them sell prospective buyers on the premise of allowing them to cut through the cruft and quickly pump out custom software without going through the years of training that professional Software Developers tend to go through. The most relevant example of this syndrome are so-called low code tools. As it so happens, I work with one of these at my current job.

流行りのAIチャットボットの他にも、様々なゴミツールが出回っています。これらはすべて、プロのソフトウェア開発者が経験するような長年のトレーニングを受けることなく、厄介なものを切り捨て、好みのソフトウェアを素早く作り出せるという前提で、購入希望者に売り込んでいます。この問題の最もよく見られる例は、いわゆるローコードツールです。たまたま、私は現在の職場でこのうちの1つを使用しています。

This low-code tool is called ***** and my review of it is that its a steaming pile of shit. I won't go into the technical specifics of why as that probably deserves it's own post. While it has enabled some non-developers to produce custom logic and screens, it hasn't actually removed the inherent complexity around designing proper data structures, writing fault tolerant software and validating the quality of the resulting software. Because a lot of the coders in question don't have this expertise, the end result is a custom software system that is poorly thought through, is brittle and as a result will require constant fire fighting on the part of the future members of the team in an effort to keep it functional.

このローコードツールは ***** というもので、私がみたところ、とんでもないクソの山です。その理由についての技術的な詳細については、ここでは触れません。非開発者でもロジックや画面を作成できるようになりましたが、適切なデータ構造の設計、耐障害性のあるソフトウェアの作成、出来上がったソフトウェアの品質の検証など、固有の複雑さを取り除くことはできません。多くのコーダーはこのような専門知識を持ち合わせていないため、最終的にソフトウェアは、十分に考え抜かれておらず、脆弱で、その結果、機能を維持するために未来のチームメンバーによる絶え間ない消火活動が必要となります。

I haven't even mentioned the best part: Tools like this aren't cheap and they tend to structure their licenses / billing so that you end up paying for as long as you use the software you produce with the tool. On top of which, all of these tools seem to involve accepting some level of vendor lock-in. So the more time you put into tools like these, the tighter their grip on your proverbial balls becomes.

一番大事なことは、このようなツールは安くはなく、ツールで作成したソフトウェアを使用する限り、最終的には、支払いが発生するような ライセンス/請求 の仕組みとなっています。その上、これらのツールはすべてベンダーロックインを受け入れなければならず、このようなツールに時間を費やすほどベンダーロックから抜けられなくなります。

In both the AI Chatbot and the Low Code tool scenarios, the solutions each promise a shortcut around the complexity as perceived by a non-practitioner. That's the essence of the trap. Practitioners know that the writing of the code is merely the last step in a long process that involves a lot of thinking, discussion and planning. The code is generally the end result and producing it is relatively easy once you truly understand the problem at hand.

AIチャットボットとローコードツールの両方で、各ソリューションは、非専門家の複雑さを回避する近道を約束しています。それが罠の本質です。開発者は、コードの記述が、多くの思考、議論、および計画を含む長いプロセスの最後のステップにすぎないことを知っています。コードは通常、最終結果であり、目前の問題を本当に理解していれば、それを作ることは比較的簡単なことです。

TLDR: Designing a solution worth a damn is actually the most difficult part of the software development process. Low Code tools lie to customers by implying that the writing of code is the hardest part. The reality is that No Low Code tool can spare you from having to take the time to properly design your custom software or the consequences you will experience when you build solutions around a half-ass design.

TLDR：価値のあるソリューションを設計することは、実はソフトウェア開発プロセスの中で最も難しい部分です。ローコードツールは、コードを書くことが最も難しい部分であるかのように、顧客に嘘をついています。現実には、どんなローコードツールも、ソフトウェアを適切に設計するための時間や、中途半端な設計でソリューションを構築したときの結末から逃げることはできません。

 

🤔 この意見についてどう思うか ChatGPT に聞いて見た

この意見についてあなたはどう思いますか。関西弁で答えて。

めっちゃ同感やわ。コーディングの複雑さを解消する特効薬があると思ったら大間違いやで。そんなもんあったら、開発者はみんなそれを使って楽々コーディングやろうて思うてるわ。AIチャットボットやローコードツールなんか、一部の単純なタスクをこなすのには使えるやろうけど、それだけや。複雑なタスクをやるには、経験や専門知識、センスが必要なんや。ローコードツールを使っても、適切なデータ構造の設計や品質検証など、ソフトウェア開発の複雑さは取り除けへん。プロの開発者に頼るべきやな。

めっちゃ大事なことは、この手のツールは高くて、ツールで作ったソフトをつかう限り、最終的には、支払わなあかんライセンスか請求のシステムになってるねん。それだけやなくて、全部のツールはベンダーロックインを受け入れなあかんから、この手のツールに時間を使うほど、ベンダーロックから抜け出せなくなることもあるで。

AIチャットボットとローコードツールは、どっちも非専門家でも使いやすいっていうのが売りやけど、それが落とし穴なんよ。開発者たちは、コード書くのは思考や議論、計画が必要な長いプロセスの最後のステップってことを知っとる。コードは普通、最終的な結果であって、問題を本当に理解してたら、それを作ることは比較的簡単なんやで。

要するに、簡単にソリューションを作ることはできへんってことや。どんなローコードツールでも、適切にソフトを設計するための時間や、中途半端な設計から逃げられへんのや。そんなことを顧客に嘘をついて、コード書くのは難しいとか言ってるんや。

 

🤔 まとめ

それを3行にして

1. 特効薬でコーディングが楽になるというのは誤解やで。
2. AIチャットボットやローコードツールは一部のタスクにしか使えへん。
3. 開発には経験や専門知識が必要や。

ナニワ金融道ぽくてワロタ。