あとで見るために
JSUG勉強会 2019 Spring for Beginner
2019/8/28
未分類
www.slideshare.net
後から見るために
2019/8/27
www.slideshare.net
www.slideshare.net
190827_JJUG-PivotalSpringRuntime - Google スライド
2017/7/19
www.slideshare.net
www.slideshare.net
しばらくしたら削除する一時的なメモ
<!DOCTYPE html> <html> <head> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script> <title>サンプル</title> </head> <body> <script> $(document).on("click", "#btn", function () { const $row = $("input[name='lang']:checked") const $item = $row.closest("tr").find(".number"); alert($item.text().trim()); }); </script> <header> <p>ヘッダー部</p> </header> <div> <table> <tr class="row"> <td> <input type="radio" name="lang" value="ruby">Ruby </td> <td class="number"> 001 </td> </tr> <tr> <td> <input type="radio" name="lang" value="perl">Perl </td> <td class="number"> 002 </td> </tr> </table> <button type="button" id="btn" name="radio-change" value="radio-change">切替</button> </div> <footer>フッター部</footer> </body> </html>
Spring Framework / Spring Bootに入門する人はまずこの資料を読もう! #jsug - Qiita
www.slideshare.net
www.slideshare.net
www.slideshare.net
https://tanzu-dev-portal.netlify.app/developer/guides/spring-boot-testing/
Spring Boot で Thymeleaf 使い方メモ - Qiita
Spring MVC(+Spring Boot)上での静的リソースへのアクセスを理解する - Qiita
Spring MVC(+Spring Boot)上でのリクエスト共通処理の実装方法を理解する - Qiita
入力チェック:@NotNullで未入力時に正しくNULLを返すようにする。STS 3+Spring Boot +thymeleaf - SE_BOKUのITな日常
EclipseやSTSでlombokを使えるようにする方法 - A little bit of everything
Spring BootでHTTPセッションをあつかう3つのパターン - くらげになりたい。
レビューしてほしいとのことなので...
— Toshiaki Maki (@making) August 17, 2019
Autowired省略できます。RequestMappingよりGetMapping, PostMappingを普通使います。初期化はContextRefreshedEventではなく@ PostConstructでやるのが一般的です。@ Repositoryいらないです。Rest Repositoriesの依存不要です(記事で機能が使われていない)。
Boot前時代はビジネスロジックを親にweb系を子に登録するのが割とよく行われていました。一つの親Context に対してWeb(DispatcherServlet)が複数ってのもしばしばありました。
— Toshiaki Maki (@making) August 16, 2019
Bootになってその辺Embeddedになったので設定することはなくなりましたね
2019年8月現在だと、おすすめできるSpringの本は2冊しか無い。
— Masatoshi Tada (@suke_masa) August 9, 2019
・改訂新版Spring入門
・Spring徹底入門
古かったり品質があれだったりするので、他の本は読まないほうがいい。
ただ、2冊とも本当にSpringが初めての人に進められるレベルの本じゃないのが悩ましい。
バグだらけのWebアプリケーションのクローンをSpring Bootでつくってみました - Qiita
認証システムが別にあって、認証情報がCookieに設定されている場合のSpring Securityとの連携サンプルhttps://t.co/vAd18UIk1p
— Toshiaki Maki (@making) July 30, 2017
🍥RequestParam("hoge") String hoge みたいなの、パラメータないときエラーになるのどうするのーと思ったら🍥RequestParam("hoge") Optional<String> hogeでOptional使えるんだ。へーへー。って寝ないと…。
— キクタロー@エバスク役職超ボッター (@kikutaro_) July 27, 2017
spring boot のサポート期間の間、pivotalの人たちが依存ライブラリのバグを全部治してくれる、というわけでもないし、結局は依存するライブラリのうち、一番サポート期間が短いものにひっぱられるよね。それがEEとの決定的な違いなわけで、サポート期間まで粘るのはSpringBootでやると辛いと思う。
— 徳永広夢 (@tokuhirom) December 21, 2018
ロングタームに運用したくて、securityパッチ出たときにそこの変更だけを適用する、みたいな運用がBootだと難しい。それを求めるなら、生springか、eeか、薄めのフレームワークで頑張ったほうが良いと思うんですよね。
— 徳永広夢 (@tokuhirom) December 21, 2018
www.slideshare.net
A Study in Spring WebFlux · GitHub
Spring & Spring Boot ハンズオン 演習ページ · otty375/weather-forecast Wiki · GitHub
唐突かつ、全く技術に関係のない話
我が家(というか、私が作る)カルボナーラは、クリームもチーズも使わない。
オリーブオイル&ベーコンの油 と ゆで汁による乳化で、クリームもチーズも入れなくても十分クリーミー。 ベーコンの塩気が ちょっとチーズっぽくて、別にチーズとか入れなくても特に気にならない。
もともとクリームやチーズ臭の強いカルボナーラが苦手ということで 試しにやってみたら 思った以上に食べられるものだったことから、私の定番になり 今は我が家の定番に。
ポイント
*1:残った卵白は、冷凍して肉団子などのつなぎに
Java EE 8 / Jakarta EE 8の利用を検討する人はほぼ居ないだろう。いるとしたら、昔からJava EEを利用していて、何らかの理由ですぐにアップデートが必要な場合くらい?
— Masatoshi Tada (@suke_masa) 2019年5月18日
Jakarta EE 9を遅くとも来年にはリリースしないと、世のエンジニアはどんどん離れていくと思う。
への私なりの考えをツラツラと。
@suke_masa さんは間違っている!とかいうつもりは全くありません。
確かに、そういう考えもあると思います。
私が EEを使ってみようと思った経緯や、意固地(?)にEEを使っている背景などを自分にとっての整理も兼ねて綴っているだけです。
@suke_masa さんは Springにも Glassfish勉強会にも関わる中で感じた危機感のようなものを表現されたのだと、私は思っています。*1
Java EE(Jakarta EE)を採用するしないはエンジニアの意向とは別
(今更)焦っても大して変わりはしない、かな?
これがきっかけかな?と思います。
つまり javaxパッケージが EEとして拡張できなくなるということで、EE離れが起きるのでは?という問題提起。
パッケージに関しては、
Java EEは標準仕様だけどオープンではなかった。
— Yamashita (@_vermeer_) 2019年5月11日
Jakarta EEはオープンで標準仕様。
なのでパッケージ javax.* はオープンではないので使用注意。
今後は jakarta(仮)パッケージでオープンになります。
というのが私の雑な理解
の中の @yamadamnさんと、@khasunumaさんの返信が参考になります。
SpringとEEへの影響ですが、個人的には「Springを使っている方が影響は少ないんじゃないかな?」です。 理由は、javaxパッケージを直接使うのではなくspringパッケージでラップしているから。 EEは標準技術ということで、javaxパッケージを直接使っているという認識。 「ラップしてると影響を局所化できる云々」は、@suke_masa さんとのやり取りの通り。
Java EEの研修をやる時、自分は常に「標準の機能で作りましょう。実装独自の機能はなるべく使用を避けましょう」と言ってきた。今となっては、その説明が嘘になってしまった。javax.*なクラスではなく実装独自のクラスを使っていた方がバージョンアップにかかる変更が少ない。やりきれない気持ち。
— Masatoshi Tada (@suke_masa) 2019年5月18日
なので、Java EEの延長としての Jakarta EE への移行については、拡張部分を除けば これまでのJava EE8のアップデートと同じ計画ですすめて行けば良いし、拡張部分を使うのであればベンダー謹製か自社ライブラリでラップしておけば まぁ良いんじゃないですかね?というのが雑な移行計画。もうちょっと真面目に補足すると、EEに限らず 今後のシステム移行というかシステム構築のあり方はクリーンアーキテクチャとかDDDとか、そういう設計思想や知見を活用して ドメイン知識(業務の主たる関心事)をPOJOで実装しましょうってことだと思います。今回はたまたまJava EE側の問題ですが、Spring側で今回のような問題が発生しないとは言い切れませんからね。もっといえばGraalVMまで考えるとドメイン知識の実装はJavaじゃなくても良いかもしれない。むしろStruts1系からの卒業を考える際に、そもそもフレームワーク(を含めた外部ライブラリ)から如何に影響を受けないようにするのかということを考えるべきだったのかもしれません*2。少なくとも SoRなシステムであれば。SoEは当たるか外れるか分からないものを扱うものだと思うので そこまでやるのは YAGNI として良いのですけどね。
どうでも良いけど、オレオレFWを考えてみようと思ったのも外部ライブラリの影響を局所化するためには?という思考実験の延長。 クリーンアーキテクチャとかDDDとか、そのあたりの情報を知ってライブラリをラップするというのではなくアーキテクチャー的なアプローチで解決できそうだというのを知って考え始めました。
Springを採用するにせよ、EEを採用するにせよ 実際のところは
言語とは違うけど、Java EE(Jakarta EE)やSpringもそんな感じだという理解。
— Yamashita (@_vermeer_) 2019年5月24日
あの時期もMSはIDEを含めて実質選択肢が1つでしたし。@kikutaro_ さんがJava EEを選んだ経緯とか読むと「同じく」と思いました。
今だったらデファクトになっているSpringを選ぶかもしれないですね。 https://t.co/TVKLmZAqyd
言ってしまえば、Struts1系が何故採用されたのか?と実質同じ。
私は標準であるという思考停止だけど、デファクトだからというのも似たり寄ったりじゃないかと。
私は標準であることを理由に使ってみることにしました。
実際に手を動かして比較して、というところまではしませんでしたが @kikutaro_ さんが大体同じプロセスを経て EE6に至っているように思いますので、以下の記事を読んでいただければ雰囲気は伝わると思います。*3
初めてのJava EE 6開発! 最初の壁をどう乗り越えた?──最新Java EE開発“虎の穴” 第1回 菊田洋一氏 - builder by ZDNet Japan
違いとして特徴的なのは JSFとJPAだと思うので、EE側の利用者としての感想。
SpringMVCは、Struts1系と同じでアクション指向だから採用されて、JSFは違ったから避けられたのかな?
テンプレート的な使い方であればJSFは使いやすいと思うし、実際、私はEEを金魚本で独学しているときに、SAStrutsの案件に関わって「EEと変わんない」というくらいの違いしか感じず。
アクション指向とコンポーネント指向という違いやライフサイクルの違いは分かるけど、そんなものと思ってしまえば、まぁそんなもの。
リクエストにたいしてレスポンスをページ単位で返却する、というWebの仕組みの範疇。
紙芝居的なWebページだったらJSFに不満ないなぁ。
ただ、JSFをjQueryMoble(とjQueryのAjax)と合わせ技で動的にView更新をしたら相性の悪さを感じました。 でも、これは自分の技術力不足だと思っています。*4
率直な感想としては動的ページ(SPA)はJAX-RSを使ってJSFを中途半端に使うのは辞めた方が良いです(笑)
MyBatisのSQLを直接書ける感じが好まれてJPAは避けられたのかな?JPAのステートフルなところやJPQLのクセはあるけど、別にSQLを直接書いてはダメということもないしJDBCの延長くらいの使い方であれば別に困ることは無いんだけどなぁ。 私はそこまでリッチなこともしていないから本当の苦しみは分かっていないだけかもしれません。 MyBatisを使ったことは無いけど置き換えを考えたくなるほどでもないです*5。 正直、MyBatisにするくらいなら、S2JDBCの方が良い。なので実質後継であるDoma2の方が魅力的。 JPAを使わないんだったら、私はDoma2を選ぶなぁ*6。
※あくまで自分の理解なので、間違っている可能性はあります。整理としても雑なので雰囲気だけ伝わればと思います。
MSのASPが標準的な扱いで、Javaの標準もそれに近しいJSFが良いのでは?みたいな話をどこかで読んだような気がしますけど曖昧です。
RoRによるEoDの影響はかなり大きかったと思います。当時の私は全く知りませんでしたが、SAStrutsやJSF(Java EE6)のことを調べる過程でRoRそのものと、RoRが各言語のFWに与えた影響の大きさを知りました。
Java EE6リリースの時期を確認すると、SAStrutsと同じか ひょっとしたら先だったかもしれませんが、私の当時の認識では SAStrutsが先で EoDとしてRoRなどの影響を受けて Java EE6が出た印象です。
なので、EEを先に勉強はしていましたが、SAStrutsをベースとした開発案件を受けて勉強した際に「SAStrutsを参考にJSF2.x系は作られたんじゃないのか?」と真剣に思ったくらいです。
SpringBootが無かったらSpring自体も群雄割拠の1つであった可能性はあるのでは?と思ったりもします。 そういう意味ではSpringはJavaでありがちな「環境構築の壁」をエンジニアの甘えとせず敷居を下げてユーザーのことを考えたから一気に増えたとすると、それはPivotalの努力だと思います。 それが無ければSpringがデファクトになれたのか?それくらいStruts(SAStrutsも含めて)の影響は長きにわたるものだったという印象です。*9
ちなみに日本語情報の有無については、ちょっと微妙で MyBatisは日本語書籍は ほとんど(もしくは全く?)無いんですよね。
MyBatisが使いやすいことの証左なのかもしれませんが、でも私は使用しているプロジェクトを見る限り、そこまでの嬉しさが分かりませんでした。
あえていえば、Struts1系と同じで「iBatisを使っていて、後継のMyBatisをこれまで通り使っている」というだけじゃないの?と。もちろん使い続けたいと思わせるライブラリだというのは大前提として。
私はSpringがデファクトになった理由はJavaを採用する人にとって採用しやすかったであってSpringをエンジニアが採用したからではないと思っています。
(といいつつ、この後、前言撤回しますが。)
Springの歴史
モノリシックなWebアプリにおいては上述の理由であると思いますが、もう1つの波があります。
みんな大好きMicroserviceです。
色々と端折りますが、UberJarの仕組みを簡単に提供したのが SpringBootだと思っています。
EE陣営もPayaraMicroやKumuluzEEが頑張っていたと思いますが、肝心のOracleは行動が遅かったです。なんだかんだといっても「標準」のオーナーである Oracleの腰が重いと EEの仕様として標準化されません。
たった数年かもしれませんが、この出遅れは結構致命的だったと思います。
この点についてはEEからエンジニアが離れたと言っても仕方ないかなと。
それらに加えて、いずれMicroService化するのでは?Webサービスは12Factorであるべきだよね?と モノリスな設計思想を捨ててもないのに*10MicroServiceで構築する必然のないシステムでも採用していきます。
最新技術へのキャッチアップです。エンジニアとしては嬉しい限りですね。
でも気をつけてください。Pivotalの速度感に皆さんがついていくということですよ?
当然、SpringBootは2系を使っていますよね。1系そろそろEOLですよ?
マイナーバージョンアップでも逐一キャッチアップ&デリバリーをするライフサイクルを開発プロセスとして組み込んでいますよね?
アジャイル開発してますよね?
嫌味に煽っているわけではなくて、それがSpringを使うことの価値観だと私は思っているということです。
Strutsをデファクトだからと採用していた企業*11が、Springを採用するときに そこまで考慮していれば良いのですけれど、という杞憂です*12。
EEも下位互換がすべて出来るかというと、まぁそういうことはありませんが標準仕様として 良くも悪くもたくさんの関係者がいる分、それなりに配慮はされていると思います。 本当に求めているのは新規性ですか?それとも安定性ですか?
EEを採用する理由は標準仕様だからということ以外は正直ないと思っています。
そして、私にとって それが大切だと思っています。
ツラツラと冗長に書いてきましたが、@yoshioterada さんと @kawasima さんの対談が、私の言いたいことに近しいです。
「Java EE 8」の注目機能は何か? この先、Java EEはどう進化していくべきか? 寺田佳央氏と川島義隆氏に聞いた - page2 - builder by ZDNet Japan
Jakarta EEとして標準仕様として明確になりそうな(なってる?)MicroProfileにも期待です。
スターターも出てきました。
MicroProfile Starterで選べるMicroProfile Serverを調べてみた - Challenge Java EE !
心強いですね。
EEをラップしてベンダー謹製のFWにするための土台は、改めて整いつつあると言っても良いのではないでしょうか?
さて、EEは見捨てられるのでしょうか?
それに対する私の認識は「EJBをきっかけに離脱したユーザーもエンジニアも ほとんど帰ってきていないんじゃないでしょうか?」です。
つまり今も昔も見捨てられ続けています。身も蓋も無いですね。
でも標準仕様の仕組みはJakarta EEとして生き残りました。
私としては ここが大事だと思っています。
上述でも引用させていただいた @ceto_tさんの
選択肢が増えて、それを比較したり最適なものを選ぶのを良いと思うのは、ごく一部の中上級者だけ。
— TANIMOTO Shin🦊🤘 (@cero_t) 2019年5月23日
大半の人は、選択肢は少ないほうが良いし、何だったら唯一の正解を知りたいと思ってる。
っていう前提です。
EJBの延長としてのEEへの再評価は今後も無いと思いますが、Javaによるシステム構築における選択肢として EEが選ばれることはあると思います。
個人でも私のように「デファクトのStrutsのXML地獄はちょっと。。良く分かんないけど、標準というものを選ぼう。」みたいな人もいるでしょう。
もしも見捨てられるとしたら、そもそもJavaでシステム構築をすること自体が見捨てられた時じゃないでしょうか(つまりSpringと競っても意味がない)。
Java SEのオープン化で、ごちゃついてしまったところはあり、それで立ち去ったユーザーもいるようですが、それも私からすれば「エンジニアが採用を見送った」ではなく「ユーザーが ごちゃごちゃしていると判断して敬遠した」だと思っています。
ライセンスやサポートへの意識が高いエンジニアが あの意味を理解できないなんてことないですよね?Linuxのディストリビューションがややこしいから やっぱりWindowsServerだね、というのであれば「あっ、はい」という感じですけど*13。もし、エンジニアとして Java SEのオープン化を有償化といって判断したとしたら、うーーん、、なんだろう。。「頑張れ」かな?*14
これは完全に余談ですが、今回のきっかけのtweetの私のリツイートに
実務でEE使ってらっしゃると思っていました。驚きました。
— うらがみ⛄ (@backpaper0) 2019年5月19日
と @backpaper0 さんに言ってもらえたのは素直に嬉しかったです。
「うらがみさんは、カンファレンスで登壇していたり、Doma2のコミッターだったり、凄い人なんだよ!」という喜びを妻に伝えましたが反応はイマイチでしたが(笑)
なぜ、嬉しいかというと、私のJavaスキルは実質 独学であり我流です。
誰も私のコードをレビューしてくれたこともありませんし、システム構築にあたって誰かに相談することも無い状態で作り込みをしました。SIer時代では開発案件のJava実装者であったことはありません。PLとして方式を検討したり、レビューや部分修正をすることはありましたが1から構築するということはありませんでした。当然、私のコードを誰かがレビューをしてくれて指摘をされるという経験はありません。
SIerを離れる数年前くらいから書籍などで学んだ 良いコードのあり方 とかオブジェクト指向とは?みたいなことを自分で勉強し、SIerを離れてからDDDとかの知識を学びました。Java EEによるシステム構築の際も元SIerのPL経験を踏まえて「もし自分がリーダーだったら、自分のコードにどういうダメ出しをするのか」みたいな禅問答のようなことを陰々とし続けて、自社システムを構築しました。
作り切った後、当然ですが「動くものは作れたけど、なんだか美しくないなぁ」と。設計思想としてアーキテクチャとして、システムとはどうあるべきなんだろう?と考えるようになり、改めてJava EEを使いながら整理をやり直すことにしました。
あわせてEEの情報は少なかったので、独学かつ我流であれ誰かの役に立つかもしれないと思いブログで情報を垂れ流すことにしました。
とまぁ、そういう経緯もあり「実務経験があるかと」と言ってもらえたのは、独学我流ではあったけど そこまで変なことはしていないと初めて実感し、しかも自分が「すごいなぁ」と思っている方に言ってもらえたという意味で非常に嬉しかったわけです。
余談が長くなってしまいました(笑)
EEにおけるベンダーサポート云々の話も書こうと思いましたが、ベンダーとしてSpringであれ EEであれ それ以外であれ、有償サポートを受けつつフレームワークを採用するのであれば言及する意味は無いかな?と思ってやめました。*15
*1:愛のある故の危機感的なものだと思っています
*2:とはいえ、あの時期にDDDとか、そのあたりの知見は出たばかりだったような気がしますが
*3:このプロセスで @yoshioterada さんを知るのは EEあるあるな気がします
*4:独学というか我流というか相談できる人がいない辛さを感じつつ力技で対処しましたが、もっと良い対処方法はあったはずだと思っています。
*5:あくまで個人的な意見
*6:ドキュメントを読む限りの理解ですが
*7:Springをラップして自社FW(TERASOLUNA)として活用する
*8:ベンダーがラップして自社FW(https://cloud.watch.impress.co.jp/docs/release/396408.html)として活用する
*9:ちなみに、まだ生き残っているという話も最近聞きました。
*10:口が滑りました
*11:エンジニアとはあえて言いません
*12:あっ、それを嫌味というのか
*13:それはそれできちんと理解して選定しています
*14:様子を見るというのであれば理解できますけど
新紙幣が発行されることが発表されました。
さて、これにともなって どのような論が出てくるでしょうか?
陰謀論的な発想も含めた頭の体操です。
福沢諭吉から渋沢栄一へ、ということは 経済界における慶応閥の力が弱まってきているという論。
三菱は岩崎弥太郎で、彼と福沢諭吉との 関連を鑑みるに、国としては みずほ銀行(旧第一勧銀) 推し?
三菱UFJはマイナス金利の際に国債を買わないという宣言をしたり、仮想通貨(暗号通貨?)の発行をメガバンクとして早々に打ち出したりと「反日本」と見られて 紙幣の顔から福沢諭吉が外された的な。
バブル期(1984年)からの「顔」が、今 役目を終えたという見方。
でも新しい顔が東京証券取引所の創設者って、結局(ry。
とはいえ、渋沢栄一は 多数の企業設立に関わっているから、それを言ったら何かしらに関係してしまうので「新しい時代に どんどんビジネスを起こしていこう」と考えた方が前向きですね。
新しい紙幣に「電子透かし」的なものを採用することによって、古い紙幣が使えなくなる という論。
電子透かしの無い紙幣は、ある一定期間を経て 市中で使えなくなるという話。
銀行にもっていって新しい紙幣に交換しないといけない、または預金(貯金)としてしないといけない。
タンス預金(地下経済)を把握しようという流れの一環。
キャッシュレスも同じ理屈ですね(インドとか中国とか)。
日本は タンス預金率が高いと言われていますし、どうにかして把握するためには「古い紙幣は 電子透かしがないと市中では使えなくなります」という論理で あぶりだすんじゃないかなぁ、なんて。
そこまでするか分かりませんが、そこまでしたら 結構なインパクトになることは必至でしょう。
先の電子透かしの延長。
紙幣につける電子透かしは、透かしと言うよりも ID。
IDをもって、それをブロックチェーンとして把握するという論。
預金(貯金)はマイナンバーで把握、紙幣はブロックチェーンで把握。
お釣りとして、小額紙幣は使われるけど、1万円の高額紙幣は お釣りとして出ていくことは無いので それなりにブロックチェーンの効果はあるんじゃないですかね。
ロンダリング対策の影響を受けて、グローバルな仮想通貨へのシフトがより強まるかも。
そうすると値段が上がるかもしれませんね。
(しらんけど)
紙幣読み取り関連の銘柄が上がるんじゃないですかね。
特に電子透かしという特殊性があるし、これまでとは違う気がするんですけど どうかなぁ。
(しらんけど)
新紙幣対応として、自動販売機の入れ替えをするコストアップに対応はできないということで、自動販売機から 紙幣投入口が無くなるという話。
結果として、硬貨と電子マネー(QR決裁含めて)しか使えなくなる。
これは、割とありそうな気がします。
特に地方の自動販売機だと、紙幣のところに蓋をして使えなくなる可能性が大きいんじゃないかなぁ。
今更、新しい自動販売機に置き換えるコストをかけ無さそうな気がします。
キャッシュレスとか、タンス預金の是正の延長で ありがち(?)な話として、預金封鎖もあるかなぁ。
正しくは、預金封鎖がやりやすくなるための土台になっていますよね?という感じ。
戦後 日本国債が紙切れになったようなことを 恣意的にやるためには、できるだけ 現金を預金にしておいた方が効果は大きいのは 言わずもがな、です。
(さらに ぶっ飛んだ発想)
円が無くなって ドルとか元とか 何かしらの通貨に 一括置き換えされる未来。
日本が無くなるのか、日本以外も含めて国家が無くなるのか、経緯は ともかくとして、円が無くなってしまう。
貨幣変換は 電子化されたら ボタン ポチッでおしまい。
そんなに単純なものでは無いというのは分かっていますが、まぁ、ぶっとんでいくと そういう世界もありますねという論。
とりあえず、インドみたいに高額通貨(1万円)が無くしてまで キャッシュレス化を進めることはしないみたいですね。
逆に10万円札も無いということでもあるようですね。
信じるか信じないか(ry