タグ

ブックマーク / irof.hateblo.jp (18)

  • getとfindの使い分け - 日々常々

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

    getとfindの使い分け - 日々常々
  • Javaのバージョンの取り扱い(2023年6月) - 日々常々

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

    Javaのバージョンの取り扱い(2023年6月) - 日々常々
  • Javaで「ライブラリの最新版がある」と言うときの基礎知識 - 日々常々

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

    Javaで「ライブラリの最新版がある」と言うときの基礎知識 - 日々常々
  • Log4j 2のバージョンアップのやりかた - 日々常々

    Log4j 2に脆弱性があるらしい、バージョンアップしたら治るらしい。」 日話題のこのテーマで軽く書いておきます。 未完です。 未完公開の言い訳。更新した内容は最後に書いてます。大きな間違いは(今のとこ)ないので、よかった。 2021-12-20追記: 2.17.0 出てますのでコピペしてそのままにせず適宜読み替えてくださいね。 とにかくバージョンを上げよう ……リリースできるかは別の話として。 バージョンを上げられないことには話になりません。ということでとにかくあげましょう。 Log4j 2のようなログライブラリは多くのプロダクトで使用されています。 意識する/しないに関わらず、ログライブラリは何かしら関連があると思うべきでしょう。 使用しているかの調べ方 常時依存ライブラリリストを出力するなどして管理しているのであればそれを見ればいいだけの話ですが、そうでなければ、 mvn dep

  • テストでのデータベース単位の捉えかた - 日々常々

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

    テストでのデータベース単位の捉えかた - 日々常々
  • Java17雑感 - 日々常々

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

    Java17雑感 - 日々常々
  • コミット対象をよりわけるのをやめてみよう - 日々常々

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

    コミット対象をよりわけるのをやめてみよう - 日々常々
  • SpringBootのプロジェクトを作成する - 日々常々

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

    SpringBootのプロジェクトを作成する - 日々常々
  • リファクタリングに関する何か - 日々常々

    リファクタリングの話をするとき、焦点が合ってないなーと感じることがたまにあるのでざっくり描いてみた。 自分のために描いたものなので、なんか違うなーって思ったらご自身で描いてみるといいと思います。レッツモデリング。 破線は依存、実線は変換。長方形は名前などで明確に識別可能なもの、角丸は様々なものを包含する活動。雲は思いです。 描いた時の経緯と言うか 該当ツイート: リファクタリングって常時やるものなんですよね。もちろん「よーしやるぞー」って感じで行うものもあるんですけど、それは深呼吸的な。 とは言え。やったことがない、やってはいけない文化(動いているコードに触ってはいけない)に染められてしまっている、そのような方に「無意識にやれ!」と言っても、何の意味もないので言いません。むしろ害悪ですらある。 該当ツイート: 無意識にやるようになって、ようやく「リファクタリング」がカタログ化される前の「偉

    リファクタリングに関する何か - 日々常々
  • ドメイン駆動設計に関する何か - 日々常々

    2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも?くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ

    ドメイン駆動設計に関する何か - 日々常々
  • 脱ブランチファースト - 日々常々

    あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト(造語) 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン( master ブランチ)に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙

    脱ブランチファースト - 日々常々
  • finalを付けるのをやめてみた - 日々常々

    2024-06-12 追記: 書いた内容自体はそうなんだけど、なんだかんだで `final` 書くほうがいいやってなってます😜 ほら、「やめてみた」なんで。ほら。 Javaの話ね。バージョンは8以降の実質的final(effectively final)があるものとします。7以前は匿名クラス(この呼び方は 匿名クラスとかローカルクラスとか参照)でローカル変数を使うにはfinalが必要なので文脈変わります。 前提の整理 final は色々なところにつけられます。 例えばこんな感じ。 final class FooClass { final Object barField = new Object(); final void bazMethod(final Object quxParameter) { final Object corgeLocalVariable; } } このエントリで対

    finalを付けるのをやめてみた - 日々常々
  • ArrayListじゃなくListを使うという話 - 日々常々

    具象型ではなく抽象型で扱え、インタフェースを使え、みたいなお話に対して。 前置き Javaの話。他の言語だと話は変わります。 「こうするのが絶対的に正解」と言うものではありません。私の現在の選択の説明です。明日になったら違うこと言ってるかも。 主な登場人物は掲題の java.util.ArrayList および java.util.List、そして java.util.Collection と java.lang.Iterable です。 こんな世界観。他のインタフェースやクラスもたくさんありますが、この話の筋では無いので触れません。 前提として以下を置いています。 フレームワークやライブラリではなく、一つの業務アプリケーションに閉じた話です。ゆえに不特定多数から使われる型ではなく、影響を与えるコードは全て目が届く範囲にあるものとします。 計算量は別の話です。扱うドメインにもよりますが、

    ArrayListじゃなくListを使うという話 - 日々常々
  • JavaBeansって言葉に煩わされない - 日々常々

    JavaBeansって言葉を目にして、ふと検索してみたらあまりに酷かったので書いておこうかと。対象は「JavaBeansってなんだろ?」と思ってしまった初学者さん。でもそんな人って私のブログ読むんだろうか…… 今後は「このエントリ参照」にするつもりで書いてみる。 文字列連結と+演算子について整理しておく みたいな感じ。 ShortAnswer JavaBeansを学ぶ必要はありません。JavaBeansと説明されているものの多くは、JavaBeansの名前を借りた独自の物体です。 長い説明 「あまりに酷い」と「要らない」だけだと流石にアレなので、仕様を斜め読みしながら説明していきます。あ、EJBには触れません。まぜるなきけん。 仕様について JavaBeans仕様としてげったーせったーがーとか、こんすとらくたがーだとか、しりあらいざぶるがーだとか。よく見聞きするのだけど、仕様って読んだんだ

  • Javaエンジニアからみた最近のJava事情 - 日々常々

    5/9(水) 大正GeekNight Vol.1で話しました。 https://taisho-geek.connpass.com/event/85508/ 4ヶ月前のスライドです。 Javaのサポートについては続報も出てきていますし、思い込みで騒がないのが吉です。 いよいよ今月命のJava11がリリースですね。どうなるかな。

    Javaエンジニアからみた最近のJava事情 - 日々常々
  • 「あるエンジニアがプログラムを紡いでいく様を見てみる」ライブコーディング・リプレイ - 日々常々

    あるエンジニアがプログラムを紡いでいく様を見てみるでしたライブコーディングで言ったことや言わなかったことを書いてみます。 意識してるのは「コードをどまんなかに」です。 speakerdeck.com ……あ、このスライドのブログ書き忘れてた。 スライド中の「えらぶ」はだいたいIDEの機能を指します。なのでライブコーディング中に使用したIDEの機能も挙げようと思います。基的にデフォルトのつもりだけど、vimとの兼ね合いで変更してるのもあるので、そこはごめんなさい。あとMacです。今回はメソッド抽出とかクラス間移動とかダイナミックなのがなくて地味だけど、便利な子たちなので使ってあげてください。 リプレイ 今日の公開コーディングはスゴい新鮮だった🎵 コミット後のソースには、どこに悩んだのか、どこにこだわったのかは残らないのですね。 実際のコーディングを見させて頂く事で、気づかされる事が多かっ

    「あるエンジニアがプログラムを紡いでいく様を見てみる」ライブコーディング・リプレイ - 日々常々
  • 「現場で役立つシステム設計の原則」の感想 - 日々常々

    現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行(ソフトカバー)この商品を含むブログ (1件) を見る 目次流しは以前書きましたが、読み終わってるので改めて。 一緒に開発する人には読んでおいてほしい。可能なら手元に置きながら開発してほしいです。手頃なサイズ、重量、厚さ、価格ですし。鈍器系に比べれば持ち運びやすい。実際レビューやペアプロの際、「あのに書いてるんだけど・・・」という感じで何度か参照しています。 読書会をしてみて 4つのイベントに参加しました。うち2つは輪読形式の読書会で、最初から最後まで読み上げです。有用なのと同時に危険でもある、というのが読書会での感想です。 平易な文章で理解しやすいように思えるのですが、表面だけで理解した気になっていると間違いな

    「現場で役立つシステム設計の原則」の感想 - 日々常々
  • DIコンテナのインジェクション方法の使い分けについて - 日々常々

    DIコンテナを使う時にどのインジェクションを使うかって話です。 たぶん誰かがどこかで同じようなことを書いているだろうけれど、気にせず書くよ。 「他の誰かが書いている」なんてのを書かない理由にしてると何も書けなくなるし。 コンテナ DIコンテナのこと。 コンテナ管理 インスタンスのライフサイクルをコンテナが管理していること。雑に言えば、使う側で new しないってこと。 インジェクション Dependency Injectionのこと。 Short Answer コンストラクタインジェクションを使いましょう。使い分けなくていいです。 3種類のインジェクション インジェクションには3種類ありますね。他あっても知らない。 フィールドインジェクション セッターインジェクション コンストラクタインジェクション フィールドインジェクション 一番よく見るかな。 class Hoge { @Inject

    DIコンテナのインジェクション方法の使い分けについて - 日々常々
  • 1