ぶっちゃけコーヒーの銘柄とか覚えてないけど、なんとなく好きだなーいまいちだなーとかはある。 あ、ブルーマウンテンだけはわかる気がする。あんま好きじゃない方に属するけど、飲む飲まないで言うと飲む感じ。 その程度の味覚だけど「毎日一人分のコーヒーを豆挽いて淹れたい」って欲求を満たしてる私の一式を晒しちゃおうという内容です。 雰囲気でやるならこれで十分で、こだわる人には役に立たない内容だし、ちゃんとしたい人はちゃんと調べてね。 道具 豆を挽くもの 湯を沸かすもの 重さはかるもの 淹れるもの （時間はかるもの） （温度はかるもの） 大雑把に前4つあればOKです。時間と温度は雰囲気で。 コーヒーメーカーで全部揃うよとか色々あるとは思うんですけど、「豆から手で淹れる」ので。コーヒーメーカーは一杯分だけ淹れ用と思うと微妙で使わなくなっちゃったのよね。 豆を挽くもの 「粉買えばいいじゃん」って思うかもだけ

システム開発ではよくコードや区分、フラグと呼ばれるものを扱います。 これらが混同していたり、曖昧になっていたりすることは多いので、その辺りを整理しておきます。 IDや名前なんかもこの文脈に登場するので、ついでに。 コード コードはエンコード／デコードできるものです。 桁数ごとに意味があったり。 一定のルールで読み書きできるのがコードかなと思います。 区分 種類が固定されたコードを、特別に区分と呼ぶことにします。 値ごとに意味が決まるので、コードの一種としています。 どんな値が入りうるかわからないものは区分とは呼べません。 それは多分コードと呼んだ方がいいです。 フラグ 種類が2つ（on/offやtrue/false）に固定された区分、特別にフラグと呼ぶことにします。 3つ目が出てきたらフラグとは呼べません。 それは区分って呼んだ方がいいんだろうなと思います。 フラグと区分の関係を示したいの

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

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

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

導入 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 とかで指定できるんだけど、それはあまり使

謎の物体が届きました。 ツイートのリンク どう見ても観光土産ですよね。 エコ炭の置物 【鮭にくわえられた熊 大サイズ】 メディア: 大サイズで写真の通り、MBP16インチのトラックパッドからちょっとはみ出るくらいの大きさです。 この手の置物の「大」と言うと、家の玄関にでーんと鎮座するようなイメージですが、てのひらサイズでした。 他に小とかミニとかあるみたいなので、買うときはご注意を（買う人いるんだろうか……） 買った時の流れ 私のアイコンは魚と言うわけではないんですが。 Twitterのリプで貼られたのは小サイズ。 よく見ると ￥1,980 + ￥880 配送料 で、大サイズでも配送料は変わらず ￥3,190 + ￥880 配送料。ミニでも ￥770 + ￥880 配送料 と配送料は同じ。それなら大サイズだよねーって買いました。 この判断は合理的だと思うんです。購入代金に対する配送料の占め

引きこもり生活が捗って、気付いたら家に白い粉しかなくなりました。 白い粉 = COMP、小麦粉、塩、重曹 せっかくなので、小麦粉で色々してみます。 小麦粉はパンの材料なので「最悪でも微妙なパンくらいだろう」と思ってました。 そんな私の5日の記録。 1日目: 茹でる この日のスレッド 最後の玉ねぎを茹でて、他に何もない状況。 晩ご飯を作っている。具体的には何も考えずに玉ねぎを煮ている。なお、他に食材はない……あ、小麦粉ならある。 この「あ、小麦粉ならある。」が全部悪い。 できあがったもの。 玉ねぎはうまいが、小麦粉塊は所詮小麦粉塊だな……味気ない……… 口は衣の中に具があるかと期待する。最後まで小麦粉。中心の方は粉っぽいままで、なかなか微妙だった。 しかし今思えばこれはまだ美味しかった方かもしれない。玉ねぎは偉大。 2日目: 揚げ焼き この日のスレッド 見た目はナゲットとか、衣つけた鶏肉なん

酷い暴言だ。自己紹介なんですけどね……。 と言うことで、豆腐と紐の絵しか描けない私を含む皆様を救済するかのような「丸と線が書ければいい」と言う言葉がカバーに踊るこちらを買ってみました。 なんでも図解――絵心ゼロでもできる！　爆速アウトプット術 作者:日高 由美子発売日: 2020/09/09メディア: Kindle版 ざっと読みながら、お題をやりながら、一通り描き終えて。 出てくるテーマ的にピクト図解に引っ張られたり、ビジネスフレームワーク図鑑の書き方で行っちゃったり、余念が多い私……。 ビジネスフレームワーク図鑑 すぐ使える問題解決・アイデア発想ツール70 作者:株式会社アンド発売日: 2018/08/29メディア: Kindle版 まあこれはこれでいいんだ。大事なのは伝わるように描くことだから、組み合わせれる物は組み合わせればいいんだ。 値段も1,500円前後と手頃だし、内容から得られ

法律って慣れてないと読みにくいですよね。慣れたら読みやすくなるのかわからないけれど。 取り違いや誤解、漏れが少ないようにを意識して書かれているのか、どうしても冗長に感じます。 よくあるのが「AAAのBBB若しくはCCCのDDD」のようにAAAとCCC、BBBとDDDが並列で、これを一塊として後の文が続くもの。この塊を抜き出せると一気に読みやすくなります。 てことでリファクタリングをしてみる。テストがないのは気にしないで。 やるのは一次変数の抽出と名前の変更。 お題は「特定商取引に関する法律」の第三節　通信販売（通信販売についての広告）、第十一条です。 選んだ理由はたまたま今読んでるから。 まず原文から開始。 第十一条　販売業者又は役務提供事業者は、通信販売をする場合の商品若しくは特定権利の販売条件又は役務の提供条件について広告をするときは、主務省令で定めるところにより、当該広告に、当該商品

【オンライン】 JJUGナイトセミナー「おうちで！ビール片手にLT大会！」8/26(水) 開催 でLTしてきました。 オンラインLTは難しいですね。 内容 いつも通り目新しいこともない「ふつう」の話です。 元々40分くらいのセッションを煮詰めて5分に押し込みました。 Live（や公開されるであろう動画）で見られた方はめっちゃ端折って話してるのわかるかと思います。 言いたいことは言ったつもりだけど、言えなかったこともスライドには書いてるつもり。 特に大事なとこを挙げるならこの辺かな。 とにかく完成させて公開する。公開を意識するだけで対応する物の優先順位とか、代替パスをどれやっておくかとか。 今できないものをどうしておくか という、現代のプラグラマに必要なスキルが身につけられます。 ループ図のつもり……なんだけど、全部プラスになっちゃってマイナスがでないからそれっぽく見えない。まあいいか。（K

何度か書いているけど、整理的な意味で。今後は「このエントリ参照」にするつもりで書いてみる。 文字列連結から見るシステム内で扱う型について - 日々常々 Javaプログラマであるかを見分ける10の質問 に答えてみる - 日々常々 String の連結ネタの続き - 日々常々 前書き Stringなんてboxed primitive*1でもないただのクラスのくせに、中途半端に贔屓されて*2てムカつく*3し、その中途半端ぶり*4がなお腹立たしい……。そして +演算子 で連結して問題が起こるような状況、つまりそんな長々と文字列連結したいような場合は、きっと他の適した型がある。StringBuilderじゃなく、もっと別の何か。業務要件で文字列を組み立てる目的を考えれば、たぶんテンプレート的なものに落ち着くんじゃ無かろうか。ライブラリ的な所でなら逐次書き出し等になるような。どちらにせよ文字列の組み立

ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja) お世話になっている人も多い Martin Fowler's Blikiの日本語翻訳サイト 、いつも運営＆翻訳ありがとうございます。 パターン言語は関連が重要な役割を担っています。そして関連はダイアグラムにすると捗ります。ダイアグラムがついている書籍もよくみます。 なので、ダイアグラムがないときや書籍と違う雰囲気のダイアグラムが欲しくなった場合、自分で描きながら読んでたりします。こんな感じで。 紙に手書きすることも多いのですが、インターネットで公開されているものはURLが付けやすいのでSVGで作るのが最近のマイブーム。SVGはサイズが大きくなっても拡大すれば読めるのでいいです。 上の画像はPNGをアップロードしたものなのでGistに上げました。 GistのSVGへのリンクを置いておきます。Gistの

（見やすいコードのために出来るたった一つのこと - 日々常々 の続きみたいなもの） 「フォーマッターを使わないなんてありえないよねー」とか思ってたけど、意外と使っていないプロジェクトは多いのかもしれない。思い返せば、私の経験上も多くのプロジェクトで使ってなかった。なので導入する時にあったあれこれを思い出しつつ書いてみる。 必ず同じ定義を使用する 必ず全員同じ定義でフォーマットしましょう。 個々人の好みはあるとは思いますが、それ以上に共通したものを使うことのメリットの方が大きいはずです。 これから導入する場合、まずはその言語で一般的っぽい定義を手に入れ、既存のコードをフォーマットしながら微調整するのがいいです。 なるべく早いうちに導入する 可能な限り早く導入しましょう。途中からの導入も可能ではあります（後述）が、それでもなるべく早期に導入しているほうが、余計なコストもかかりません。 何よりチ

タイトルは釣りっぽいですけど、結構まじめ。 フォーマッターを使用すること。 これが全てです。「スペースがどうこう」とか「括弧の位置がどうこう」とかどうでもいいです。そんな美的感覚でかわるような枝葉の話に結論は出ません。 コードフォーマッターを使用してください。そのプロダクトを通して、統一された同じフォーマッターでフォーマットすること。コードはそれだけで格段に見やすくなります。個々人が好き勝手にやったり、気をつけたり、CheckStyleなどでの見た目の警告を処理したり……そんなのしてたら不統一で見難いコードにしかなりません。 個人個人での見やすさとかはあります。当然です。例えば変数代入のイコールの位置がそろってる方が見やすい人もいます。変数宣言は1行開いてた方がいいって人も、メソッド間は2行開いてた方がいいとか、賛同できませんけどそんな人も居ます。そう言うときは自分専用にフォーマットして、