日々常々

ふつうのプログラマがあたりまえにしたいこと。

SpringBootのちょっとした動きを確認するサンプルを作ろうと思ってから公開までにやったこと

  • 開始の mkdir : 2020-09-19T19:15:24
  • 公開の git push : 2020-09-19T19:20:53

予想は5分くらいだったので、29秒オーバー……1割以内だからセーフ。

きっかけ

普段Spring使わない@chiroitoさんがSpringBootつかってJITコンパイルを見てくれてるので、なんか助けになったらいいなと。

f:id:irof:20200919194911p:plain

actuatorってそんなこまめに触らないし、挙動どうだったかなーってすごく曖昧なまま、曖昧なこと言っちゃったので、コード書こうと思ったのです。

前置きというか脱線というか裏の主題というか

「ちょっとサンプル作ってみるかー」と思ってからどれくらいの時間でできそうかを把握しておくのは大事だと思うんです。 数ヶ月や数週間の見積もりは当て物になります。これはいくら自身の作業が予想通りだったとしても、必ず制御不能な不確定なことが起こるからです。 なので不確定なことを取り除いた「理想見積もり」とかをするわけですが、それにしても「ド忘れした」とかはあるし、いきなりネットが切れたとかも時間が長ければ長いほど起こりえます。

そう言うのはさておき、数分レベルの自分に完結する物事は、高い精度の未来予測ができると何かと便利です。 これは訓練できると思っていて、私の場合はポモドーロが有効でした。 「25分でできそうなこと」を予定して、その間の割り込みなどは無理矢理でも終わるまで遅延させる。そうすると「25分全力で突っ走った場合にできること」は見えてきます。 25分に合わせてペースを緩めるなんてしません。常に全力で突っ走ったタイムだけを見てます。そうしないと意味なくて、そうできるのは自分が使うため、と言うか自分しか使わないからなんですが。

早く終わったとかも「見積もりと現実との差分」です。この辺の私の考え方は 「遅れ」なんてないで書いてますのでよければどうぞ。タイトルに「遅れ」とかついてますが、「差分」で見れば早かろうと遅かろうと同じです。

そんな感じで、私は「自分が今どれくらいの速度で走れるか」をみるようにしています。 差分があったときは、自分がどの辺の知識が曖昧だったかとかを把握するきっかけになるので。

本題: やったこと

以前 Javaアプリケーションを作るときにまずやってること とか書きましたが、人がどのようにしてプロジェクトを最初に作成してるかってあまり情報ないですよね。 人によってまちまちだし、成果物だけみてもわからないものです。 てことでその詳細を書いてみます。

まず mkdir 、これはいいや。

次にSpringInitializrを使っての build.gradle 作成ですが、これはcurlでやります。 start.spring.ioは覚えてるのでこれは手打ちするんですが、だいたいこんな感じ。

% curl -v start.spring.io
...
< HTTP/1.1 301 Moved Permanently
...
< Location: https://start.spring.io/
...

で気を取り直して https://start.spring.io を呼び直す。これ毎回やってる無駄な手順です。毎回やるなよ私。 ちゃんとリクエストしたら次は使えるdependencyのリストが出てくれるんですが、これはまあ欲しいものがあるときに見るくらい。

% curl -v https://start.spring.io
...
To create a web project using Java 11:
    $ curl https://start.spring.io/starter.zip -d dependencies=web \
            -d javaVersion=11 -o demo.zip
...

こんな感じでサンプルを出してくれることを知っているので、これを見て「あー -d dependencies=xxx だったか」と思い出します。

あとは curl -O https://start.spring.io/build.gradle -d dependencies=web,actuatorbuild.gradle が手に入ります。 /build.gradle をつければこれだけ取れます。 -d type=gradle-project とかつけなくていい。ちなみに build.gradle 以外にもJavaのコードとかもまとめて生成してくれるんですが、解凍とかかったるいし、どうせ消すしなので、 build.gradle だけ取ってます。でもSpringInitializrで作られるのは 'io.spring.dependency-management を使うバージョン管理なので、それよりもGradle側のBOM読み込みの方が好みだったりするので、この辺りもそのうち使わなくなったり……

次にやるのはIDEに取り込み。これは idea . で開くだけ……なんだけど、の前に gradle wrapper を叩くことにはしてます。 ディレクトリには build.gradle だけがある状態なので、Gradleプロジェクトと判断してIDEAさんがいい感じにセットアップしてくれます。 gradle wrapperしておくと gradle-warpper.properties ができて、IDEAさんがそれを使ってくれるので、手元のGradleのバージョンが変わってもこのプロジェクトのビルドに影響しません。 公開するなら必須かなと。Gradle入ってない環境でも使えますしね。

IDEが立ち上がったらクラス作成。 この辺は記憶で。覚えてなかったらドキュメントを検索。なんですが、検索時はキーワード以外に site:https://docs.spring.io/spring-boot/docs/current/ をつけるようにしています。 これはSpringBoot1とか別バージョンが引っかかってくるのがかなりノイズだから……。 多分もっといい感じの検索方法はあるんですけど、これで用は足せてます。

で今回はActuatorのカスタムIndicatorで、こんなのは覚えてないのでIndicatorとかつけて検索して。 動かしたらUPしかでない。

f:id:irof:20200919201406p:plain

「あー、確かdetailsにalways指定しなきゃだ」と曖昧な記憶。これは一度でも自分でやったことなかったらドキュメントを舐めることになるかと思います。こう言うのがあるから素振り大事なんですよね。 雑にSpringのドキュメントブラウザで「details」で検索して、show-detailsを見つける。

一瞬 application.properties にしようか迷いながら application.yml を作って、プロパティ記述。

f:id:irof:20200919201922p:plain

ぱーふぇくと。今見たらこの間が11秒で出来てる……ドキュメント検索とSpringBoot再起動挟んでるにしては早いなぁ。 あ、スクショに出てますが、冒頭に書いてるように自分の時間計測のため、シェルのプロンプトに時刻を出すようにしてます。結構便利。

さてGitHubリポジトリを作成。ブラウザからやりました。hubコマンド入れてるけどこれで作ることはほぼないな……

そいやこんなアンケートもしましたので参考に。(何の参考になるかは知らない) f:id:irof:20200919202327p:plain

リポジトリ名は2秒くらい考えたけど思いつかなかったので愚直に spring-boot-actuator-sample で。 見ての通り手元のディレクトリ名は spring-boot-actuator なんですが、Actuatorを作ってるわけじゃないのにこの名前で公開はないでしょ、と言う常識的な判断が -sample をつけさせました。

リポジトリ出来たらpushして、README足して、冒頭のツイートにリプライ。

まとめ

所々引っかかりはあったんですが(actuatorの綴りをtypoしたり。存在しないdependenciesを指定したら404になるのは初めて知りました。)、概ね私の手やマシン(Java、Gradle、IDEAなど諸々)、Google検索もSpringのドキュメントと私の認識にギャップはなかったことは確認出来ました。

たまにこう言うの確認しておくのは大事だと思うんです。 自分の道具箱に入っている道具が、自分の思うように動くか。使える道具が増えてきたら尚更。

豆腐と紐しか描けない人向けの図解本が出てたので買ってみた

f:id:irof:20200910150706p:plain

酷い暴言だ。自己紹介なんですけどね……。

と言うことで、豆腐と紐の絵しか描けない私を含む皆様を救済するかのような「丸と線が書ければいい」と言う言葉がカバーに踊るこちらを買ってみました。

ざっと読みながら、お題をやりながら、一通り描き終えて。 出てくるテーマ的にピクト図解に引っ張られたり、ビジネスフレームワーク図鑑の書き方で行っちゃったり、余念が多い私……。

まあこれはこれでいいんだ。大事なのは伝わるように描くことだから、組み合わせれる物は組み合わせればいいんだ。

値段も1,500円前後と手頃だし、内容から得られることに比べれば正直安いと思う。 あ、Kindle版で買ったけど、改ページが微妙で文字が読めずに文字サイズを切り替えるとかを何度かするハメになりました。 覚悟して買うか、その辺が嫌なら紙で買うほうがいいかなと思います。

余白をあけろとか、足りなくなったらすぐ次のページに行けとか。その辺りのコツも一つ一つ良いんですが、要素としてはゼロワンくんがめちゃいい。棒人間より早く書けるし、表現力が豊かで使いやすいです。 あと「秒で書ける厳選アイコン200」のビジネスアイコンはどれも「あーこう描けばいいんだ」と、デザインの力に感心しました。 しばらく模写を続けようと思います。

まあこのブログを絵で描いてないところはどうなのって思ったりしますけど。

法律をリファクタリングしながら読んでみる

法律って慣れてないと読みにくいですよね。慣れたら読みやすくなるのかわからないけれど。 取り違いや誤解、漏れが少ないようにを意識して書かれているのか、どうしても冗長に感じます。 よくあるのが「AAAのBBB若しくはCCCのDDD」のようにAAAとCCC、BBBとDDDが並列で、これを一塊として後の文が続くもの。この塊を抜き出せると一気に読みやすくなります。

てことでリファクタリングをしてみる。テストがないのは気にしないで。 やるのは一次変数の抽出と名前の変更。

お題は「特定商取引に関する法律」の第三節 通信販売(通信販売についての広告)、第十一条です。 選んだ理由はたまたま今読んでるから。

まず原文から開始。

第十一条 販売業者又は役務提供事業者は、通信販売をする場合の商品若しくは特定権利の販売条件又は役務の提供条件について広告をするときは、主務省令で定めるところにより、当該広告に、当該商品若しくは当該権利又は当該役務に関する次の事項を表示しなければならない。ただし、当該広告に、請求により、これらの事項を記載した書面を遅滞なく交付し、又はこれらの事項を記録した電磁的記録(電子的方式、磁気的方式その他人の知覚によつては認識することができない方式で作られる記録であつて、電子計算機による情報処理の用に供されるものをいう。)を遅滞なく提供する旨の表示をする場合には、販売業者又は役務提供事業者は、主務省令で定めるところにより、これらの事項の一部を表示しないことができる。
一 商品若しくは権利の販売価格又は役務の対価(販売価格に商品の送料が含まれない場合には、販売価格及び商品の送料)
二 商品若しくは権利の代金又は役務の対価の支払の時期及び方法
三 商品の引渡時期若しくは権利の移転時期又は役務の提供時期
四 商品若しくは特定権利の売買契約の申込みの撤回又は売買契約の解除に関する事項(第十五条の三第一項ただし書に規定する特約がある場合にはその内容を、第二十六条第二項の規定の適用がある場合には同項の規定に関する事項を含む。)
五 前各号に掲げるもののほか、主務省令で定める事項

とりあえず目立つところに一時変数の導入。まずは「いい名前が思いつかないので変な名前をつける」でやります。

  • "販売業者又は役務提供事業者" -> HOGE
  • "通信販売をする場合の商品若しくは特定権利の販売条件又は役務" -> FUGA
  • "当該商品若しくは当該権利又は当該役務" -> FUGA
  • "これらの事項を記載した書面を遅滞なく交付し、又はこれらの事項を記録した電磁的記録(電子的方式、磁気的方式その他人の知覚によつては認識することができない方式で作られる記録であつて、電子計算機による情報処理の用に供されるものをいう。)を遅滞なく提供する旨の表示をする" -> PIYOする
第十一条 HOGEは、FUGAの提供条件について広告をするときは、主務省令で定めるところにより、当該広告に、FUGAに関する次の事項を表示しなければならない。ただし、当該広告に、請求により、PIYOする場合には、HOGEは、主務省令で定めるところにより、これらの事項の一部を表示しないことができる。
一 商品若しくは権利の販売価格又は役務の対価(販売価格に商品の送料が含まれない場合には、販売価格及び商品の送料)
二 商品若しくは権利の代金又は役務の対価の支払の時期及び方法
三 商品の引渡時期若しくは権利の移転時期又は役務の提供時期
四 商品若しくは特定権利の売買契約の申込みの撤回又は売買契約の解除に関する事項(第十五条の三第一項ただし書に規定する特約がある場合にはその内容を、第二十六条第二項の規定の適用がある場合には同項の規定に関する事項を含む。)
五 前各号に掲げるもののほか、主務省令で定める事項

ある程度読めてきたので、意味の通る名前で残りもやります。

  • 販売対象: 商品、役務、権利を纏めて呼称する。FUGAもこれにマージ。
  • 費用: 商品や権利は販売価格(商品の場合は送料含む)や代金、役務では対価が使われているのを纏めて呼称する。
  • 引渡時期: 引渡時期、移転時期、提供時期を纏めて呼称する。
  • 販売者: HOGEをリネーム
  • 別途表示: PIYOをリネーム
第十一条 販売者は、販売対象の提供条件について広告をするときは、主務省令で定めるところにより、当該広告に、販売対象に関する次の事項を表示しなければならない。ただし、当該広告に、請求により、別途表示する場合には、販売者は、主務省令で定めるところにより、これらの事項の一部を表示しないことができる。
一 販売対象の費用
二 販売対象の費用の支払の時期及び方法
三 販売対象の引渡時期
四 商品若しくは特定権利の売買契約の申込みの撤回又は売買契約の解除に関する事項(第十五条の三第一項ただし書に規定する特約がある場合にはその内容を、第二十六条第二項の規定の適用がある場合には同項の規定に関する事項を含む。)
五 前各号に掲げるもののほか、主務省令で定める事項

これくらいなら読めるかな。特に一、二、三の並びが明確。だいたい条文は同じ関心ごとで並んでいるから、読み慣れると自然とこんな感じに見えるらしいです。ほんとかよって気分はありますが。

ここで挙げているのは一条だけなのでそれほど変わっていないように思えるかもしれませんが、全体でみると同じ言葉のくりかえしってたくさんあるので、読みにくい時はやってみると一気に読みやすくなったりします。例えば先に「販売者」で括った「販売業者又は役務提供事業者」は一単語(みたいなもの)なのですが、日本語で考えると「又は」が入っていて文章を混乱させます。こう言うのが頻出してるんですよね。

f:id:irof:20200909180602p:plain

検索してハイライトしたもの。こんなの読みやすいわけがない。

「若しくは」と「又は」をハイライト。つらい……。 f:id:irof:20200909181239p:plain f:id:irof:20200909181245p:plain

これまだ検索で完全一致するならいいんですが、先の例でFUGAに纏めたときみたく「当該」で参照してたりするので機械的にはやり切れないです。

あと、一緒にしちゃいけない物を統合しちゃうと誤解が生じる(バグですね)ので、ある程度意味取りできたらやっぱ原文で意味が変わってないかは確認しなきゃです。

何かの参考になれば。

おまけ

f:id:irof:20200910150504p:plain

ツイート: 法律文書とか利用規約とかを読んだ後、だいたいこんなこと思ってます。

ブクマコメより: 2020-09-10T18:33追記

「これ表形式にした方が100倍分かりやすいだろ…」と読んでて思う条文は大量にある

ありますね。それでか別表にしてたりするんですが、表にしたところで(以下略

f:id:irof:20200910182959p:plain

ちなみに 特定商取引に関する法律施行令の別表第四 です。 表って、もっと、こう・・・、ね?