DevLOVE関西 200回目で紹介した、私の個人指針。迂闊に採用すると大怪我する取扱注意なものだとは思います。 出典はClean Coderで、訳書は2012年。薄い本ですが、今回取り上げるのその中でもさらに一部です。 Clean Coder　プロフェッショナルプログラマへの道 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典ドワンゴAmazon "緊急時の規律"(CleanCoder)にはいろいろ納得した。— irof (@irof) 2012年8月28日 「本番は練習のように、練習は本番のように」なども同系統の言葉かと思います。 どういうもの？ Clean CoderはCleanシリーズ2冊目です。Clean Code、Clean CoderのほかにClean Architecture、Clean Agile、Clean Craftsmanshipなど。 多分一番

多くの事象は人の言動によって表出します。 そうして表出した事象に対して、私が「叩き潰す」と表現するような行為があります。 「叩き潰す」という言葉選びの通り、乱暴な行為です。 叩き潰している当人は問題に対処しようとして悪意なく行うのですが、当人の思惑と関係なく、叩き潰しのダメージを受けるのは表出させた人になります。「問題」に向けているのに色々貫通して「人」に至ってしまうのがよくないです。帰属の誤りではあるんですが、当人の意図とは関係なく、言葉は届いた場所で無意味に人を傷つけてしまうものです。 そんなことをしておいて「私は問題に対して攻撃しているのであって、人に対してではない」なんて言い放ったりします。当人は心の底からそう言うつもりなんでしょうが、受け止めた人は攻撃された経験を得てしまいます。 結果として、当然の防衛反応として「攻撃への対処」を考えるようになってしまいます。 ここまで挙げている

薄い本なので軽い気持ちで読みましょう。 先に読むべき？→Yes！ 私は初詣の列に並んでいる1時間で読みました。寒かった。 Tidy First? ―個人で実践する経験主義的ソフトウェア設計 作者:Kent Beckオーム社Amazon 力を失ってしまった「リファクタリング」を復活させる本です。私の中のサブタイトルは「Make Refactoring Great Again」です。 第一部の冒頭から引用します。 整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。 「リファクタリング」という言葉は、機能開発の長い中断を指す言葉として使われ始めたとき、致命傷を負った。 「致命傷を負った」に「だよねー」と思ってしまう昨今。「それリファクタリングじゃねーしなー」とか思いながら「リファクタリング」という言葉が使われているのを眺めつつ

いろんな現場でちょいちょい話題になるので「前にツイートしたなぁ」と見てみたらすっごい長かった。 コメントあると「対応しなければならない」ってなるの。あれが諸悪の根源だと思ってる。— irof (@irof) 2020年9月17日 諸悪の根源？ とりあえず全文転記。誤変換とかもそのまま。 コメントあると「対応しなければならない」ってなるの。あれが諸悪の根源だと思ってる。 目に見えてる問題を潰したくなるのはごく当たり前の感情だと思うけど、目に見えてるもの全て潰したからと言って完璧にはならないことは理解する必要がある。言えるのは「目に見えるものはない」というだけで……そしてコメント対応とかだと、「見た目」のメタファすら使えなくなる。 「コメント対応」のような問題の潰し方をすると必ず歪になる。これは自分の目で見つけたものなら曲がりなりにも「自分の目」の精度は高くないものの一定の見方ではあるのに対し

メソッド名の getXXX と findXXX どっちがいいの？みたいな話になることがある。 この手の話ができるだけでもいい感じだと思います。名前が記号化していないってことなので。 世の中には名前に力を割くのが無駄な文脈もあって、そう言うのに晒されて続けると当然そこに力をかけなくなります。 その文脈では最適解だけど、私は名前が重要だと思っているし、その価値観を土台に他のものを積み上げていきたい。 ということで話を戻す。 「得る」と「探す」のようなものを意図して使い分けるとコードが読みやすくなります。 使い分け方によって読みやすさは変わりはするのですが、「意図して使い分けている」だけでも十分変わります。 その意図に共感できたり汲み取れたりすればさらに読みやすくなりますが、その前段階として意図の有無が重要だと思ってます。 私の基本的な使い分け getHoge(条件): Hoge findHog

SpringFramework 6.0.11 SpringBoot 3.1.2 2024-12-12: SpringBoot3.2のVirtualThread対応で内部の実装はちょっと変わってます。本文中で出ているいくつかのクラスは3.2でDeprecatedになり、3.4で削除されています。拡張したり実装を読んだりするときは違いがあることを前提にどうぞ。 https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release-Notes#support-for-virtual-threads @Async と @EnableAsync の使い方 SpringFrameworkで @Async を使うとかんたんにメソッドを非同期で実行できます。 @Component class AsyncComponent {

ツイート したらそれなりに反応があったので、少し丁寧に書いておこうかなと。 水物な内容なので、自動でつく投稿日時以外にもタイトルに「2023年6月」を入れて強調しておきます。 しょーとあんさー よくわかんないならJava17にしておきましょう。 前提 ツイート。だよねーって思ったので、下に書いてたを持ち上げておきます。 LTSとかいう言葉が出てきますが、現在のJavaはメジャーバージョンがLTSと非LTSがあります。 OracleJavaSE を前提にしています。他のサポートも似たり寄ったりな感じと思っているけれど、自分たちが使ってるとこのサポートを確認してくださいまし。 また、本稿は「Javaのバージョン？何それ？」とか「色々あるけど最新使ってたらいいんだよね？」とかそういう方向けで、プロダクトのJavaバージョンを選定する方々向けではありません。そういうのに必要な知識には全然足りません

Gradle 7.3.2 Gradleを使っているプロダクトだと、基本的にGradleWrapperを使うと思います。 プロジェクト作成時に最新のGradleを使うかと思いますが、Gradleの更新でたまにビルド時間短縮とかもあるんで、新機能使わなくてもWrapperも更新していきたいところです。 なお 公式のユーザーガイド に書かれている内容です。 short answer 私がやってるのは、追加も更新も「 gradle wrapper を叩く」だけです。 以下は説明。 前提 SDKMAN! でGradleをインストールしています。 sdk install gradle なお、手元のGradleのバージョンアップも一緒です。install で新しいのがあったらインストールしてくれる。 sdk install gradle 普通は sdk upgrade gradle なんだろうけど、up

Log4j 2のバージョンアップのやりかた で "「Mavenリポジトリ」の指すもの" を軽く書きましたが、いい機会なのでもう少し書いておきます。 最新版は使える？ https://twitter.com/irof/status/1469139048954724354 こういうツイートをしまして。 見てる順番は Log4j 2のトップページ、MvnRepositoryのlog4j-core、GitHubのLog4j 2のタグ一覧、Central Repositoryのlog4j-apiディレクトリです。 ツイートの状態から「Log4j 2はリリース成功してからタグ作るで運用してるんだなぁ」とか、リリース成功したら自動でタグ作ってるわけでもないのかなぁとか思いました。私はタグをトリガーにリリースのパイプライン動かすのが好きです。リリース失敗したら消したくなるけど。 基本的に「最新版が使える」

システム開発の分野は技術の移り変わりが早く（これも他の分野と比べたことないので「早い気がする」と言うだけなのだけど）、なんらかの成功を収めた企業などの採用しているものがバズワードとなって一気に広まったりします。この時、その技術だけを追ってしまう現象がよく観測されます。だからバズワードになるんだけど。 批判的な意見 バズワードに飛びつくのは往々にしてアンチパターンです。例えば「モノリスからマイクロサービスへ」でも、明確な理由もなくマイクロサービスに飛びつくのは避けるよう書かれています。 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド 作者:Sam NewmanオライリージャパンAmazon 書籍に限らず経験のある人は技術の螺旋を見通し、「この技術は結局のところ重要な課題を解決しない」と示唆する発言をしたりします。 強く辛辣な言葉もたまに見かけます。「そこに問題はないんだ

Java16で導入されたRecordですが、Java17リリースによりこれから一気に使われていくことかと思います。 Java17雑感で「データクラスを新しく作るならRecordを使ってみる」とか書いたんで「よしRecordを使おう！……ところで何気にしなきゃなんだっけ？」な私向けに、現時点で「これくらい知っとくといいんじゃないかな」ってことを書いておきます。だらだら書いたんで順番とか内容の濃淡がひどいかもしれない。 ちゃんとした知識 JEP 395: Records Java Language Specificationの8.10. Record Classes Java Object Serialization Specificationの1.13 Serialization of Records GitHub openjdk/jdkのjava/lang/Record.java とか。

最近「どこどこのサイトからダウンロード」とかしてないなぁ、と思ったので。 IntelliJ IDEA Community Edition 2021.2.2 SDKMAN 5.12.4 macOS（メイン） SDKMAN!にお任せ。 IntelliJ IDEAからはAdd JDKで ~/.sdkman/candidates/java に入ってるのの主だったもの（8, 11, 17）を適当に入れてます。 SDKMAN!で新しいバージョンのを入れた時、古いのを削除するとリンク切れになって地味に面倒だったりします。 なんで ~/.sdkman/candidates/java/current/bin/java を current-jdk とか言う名前で追加してたりします。これはjava全部消さないと消えない。 勝手に変わるんでアレだけど。（自分で変えてる） 今入ってるの Windows SDKMAN

データベース（に限らずあらゆる永続化リソース）を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで

LTSとなるJava17が出ました。組織が今後もJavaを使っていけるかの試金石になるバージョンだと思います。 実際のとこLTSだから特別安定してるとかそんなことはないと思うし、6バージョン（3年）ごとにLTSにするってのもたぶんOracleさんが言ってみただけで、いろんなとこがそれに乗っかってるから、実質的に節目になってるに過ぎない。はず。 その程度のものなんだけど、私のようなのは乗っかりますし、たぶん多数派なんじゃないかなぁ……この派閥が運用で使うJavaのバージョンは8、11、17で、他のバージョンは評価に使うくらいでしょう。 11から17のジャンプになるんで、かなりたくさんの変更がありますが、業務アプリケーションの表層に関係するものはそこまで多くありません。パフォーマンスとかに影響のあるものは多々ありますが、基本的には早くなるはずで、問題になることは稀です。稀なことはよくあるんです

私のね。 三行で Single page HTML でページ内検索する。 Googleでは site:https://docs.spring.io/spring-boot/docs/current/ を検索条件に含める。 GitHubの spring-projects で in this organization で検索する。 蛇足 該当ツイート、発端はbouzuyaさんのクイズ です。 Springのドキュメントは充実していて、欲しい情報はだいたいどこかに書かれています。機能についても使い方についてもどうすればいいのかなども書かれています。なんだけど、できることがたくさんあるうえに一つのことをいろんなやり方でできるため、できることが限定されたものと比べると初見の人が目的のドキュメントにたどり着くのは難しいと思います。 情報はないわけではなく、たいていのものは https://spring

Spring Boot 2.5.2 本稿の対象 以下のような人が対象です。 SpringBootを使っていて new RestTemplate() とかを書いた／見たことがある。 SpringBootを使っていて new RestTemplateBuilder() とかを書いた／見たことがある。 ぼんやり知ってるけど仕組みとかおさえておきたい。 SpringBootのドキュメント／コードの読み方の一例を知りたい。 特に new してるのを書いたり見たことある人に読んでほしい。悲しい事故が起こる前に。 以下のような人は対象ではありません。 SpringBootのドキュメントとコードを必要な時に読んでいる。 RestTemplate を使っているがSpringBootを使っていない。 SpringBootでRestTemplate を使っているが、 restTemplateBuilder.bu

git add {ファイル名} でステージングするファイル単位で選べます。10ファイル変更しててそのうち3ファイルだけコミットしたい時とかに便利です。 git add -p でステージングする変更を行の塊単位で選べます。関係ないコメントを足しちゃったのとか、うっかりついでに変えてしまった変更をコミットから避けたり、別のコミットにしたい時とかに便利です。 間違いなく便利な機能ではあるんだけど、常用するものじゃないと思ってます。 なので git add -A を基本にする。 ……とか言いつつ git add . を常用している私。単にタイプ数と手の慣れ。ちなみにgitのaliasは使わない派です。これは違う環境でコマンド叩く機会が多かったりする都合です。 理由 を並べてみます。 コミット対象を選択するのがいちいちブロッキングなので時間がかかる 10ファイルの変更から3ファイル選択する時間は g

と思うのは、とてもいいこと。 前置き もし行いたいテストが外的振る舞いを示すものであれば（少なくともテストにより観測できる見通しがなければ「テストしたい」とは思わないだろうから、何かしら外から観測可能なものではある可能性は高い）、それがprivateに閉じていていいものではないと言う気づきのきっかけになる。 と言うのは教科書的回答だけど、外には見せたくないけれど複雑なロジックを包含していて、入念かつ局所的にテストしたいと思うこともある。 この動機はすごく自然。きっとそこはテストしなかったらバグってるし。テストしてもバグが見つからないと言うのもよくあるんだけど。 この手のがどうあるのがいいのかはチーム体制も含めたプロダクトによると思っている。 綺麗な考え方は、独立したコンポーネントとして関心ごとや複雑性を閉じ込め、テストしたいと思った内容にもっと高い格を与える。「格」なんて表現は他で使ったこ

導入 SpringBootでProfileを使用するようになると、何かのprofileを指定しないと起動しなくなるような構成になりがちだと思います。 たとえば application-local.yml 、 application-dev.yml 、 application-prod.yml など環境ごとのプロファイルを用意する場合です。 開発効率を考えればProfile無しでも動作するようにしておくのが良いこともあるのですが、それだと設定誤りなどで本番環境で動作してしまうリスクが残ります。 たとえば無印（not default）ではH2で動作するようにしておいて、prod で実際のデータベースに接続するように上書きしていた場合。設定漏れや誤りで上書きできなくても、一見正常に動作し、実はH2だった……などが考えられます。 この問題を検知できる別の仕組みがあれば無印を使用するのも良いかもしれ

2023-03-04追記: Apache POI 5.1.0で解消しているのでご安心ください。 Apache POI 5.1.0出てた - 日々常々 Apache POI の久々のメジャーバージョンアップである 5.0.0 が 2021-01-20 に出ました。 テストも通るしいっかーと、雑に更新したらexecutable jarのサイズが26MB増えてウケました。（笑いごとじゃない 多少のJarサイズはそれほど問題にならないことが多いのですが、今回はもともと40MB程度のJarで、それでも「ちょっと大きいなー」って思っていたのがいきなり60MBを超えただけに、ちょっと待ってくれって気分です。 そんなわけでちょっとみてみようかーと。見ていった手順をだらだら書きます。参考になるかどうかは知りません。 ちなみにPOIのソース管理は Subversion で、GitHubにあるのはミラーです。

2020-12-29 時点で私がどうやっているかって言うの。 色々やり方あるし、他でも書いた記憶あるけど、現時点のスナップショットを書いておきます。 必要なもの 以下が実行できること curl gradle 私は SDKMAN で入れてます gradle の実行にJDKいるけど、JDKは入ってるでしょ← idea IntelliJ IDEAのCLIね やること curl -O https://start.spring.io/build.gradle gradle wrapper idea . こんだけ。以下は解説とかおまけとか。 やってること curl で叩いてるのは Spring Initializr です。 SpringBootの雛形を作成してくれるWebサービス。必要なライブラリとかを -d dependencies=web,actuator とかで指定できるんだけど、それはあまり使

開始の mkdir : 2020-09-19T19:15:24 公開の git push : 2020-09-19T19:20:53 予想は5分くらいだったので、29秒オーバー……1割以内だからセーフ。 きっかけ 普段Spring使わない@chiroitoさんがSpringBootつかってJITコンパイルを見てくれてるので、なんか助けになったらいいなと。 JITとコードの暖気の実体 - #chiroito ’s blog: はじまり Rediness Probeでアプリケーションが十分にJITされたことを検知する - #chiroito ’s blog: このブログが関係する内容 最初の1リクエスト目で何をしているのか？ - #chiroito ’s blog: 知りたかったこと actuatorってそんなこまめに触らないし、挙動どうだったかなーってすごく曖昧なまま、曖昧なこと言っちゃった