エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

SpringAOPで独自アノテーションを付与したクラス配下のメソッドすべて処理したい時に問題にハマった件について

経緯

機能フラグの実装を考えた際に、AOPで手軽にやりたいと思い、アノテーションを目印にいろいろやった際にハマったことを書く

環境

  • Windows11 pro
  • Java17
  • Spring 3.2.4

悩んだ点

  • aseptを正しく書いているのに、全然処理が動かない
  • 起動時に変なエラーが出てくる。しかもAOPとは関係なさそうなエラー

詳細

正解の実装

gradleに、依存関係を追加

    implementation 'org.springframework.boot:spring-boot-starter-aop'

チェック用に作ったアノテーション
チェックに必要な情報を受け取るようにvalueを持つようにしてある。

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface FunctionCtrlAspect {
    String value();
}

チェック処理の実装↓
FunctionCtrlAspectのアノテーションが付与されたクラスで、publicのメソッドが呼ばれた時にvalidateFunctionCtrlを実行するように対応している。
ロジック内容は、チェック処理なので、説明は省略する。

@Aspect
@Component
public class FunctionCtrlValidator {

    @Autowired
    private FunctionCtrlRepository functionCtrlRepository;

    @Before("@within(functionCtrlAspect) && execution(public * *.*(..))")
    public void validateFunctionCtrl(JoinPoint joinPoint, FunctionCtrlAspect functionCtrlAspect) {
        String flg = functionCtrlRepository.getFlg(functionCtrlAspect.value());

        if (FunctionCtrlRepository.FunctionCtrlFlg.OFF.getCode().equals(flg)) {
            throw new FunctionCtrlException();
        }
    }
}

利用箇所の定義内容↓

@RequestMapping("/circulation")
@Controller
@FunctionCtrlAspect("circulation")
public class CirculationController {
// 内部の処理省略
}

悩んでた箇所の詳細

aseptを正しく書いているのに、全然処理が動かない

最初は、下記の実装で動かしてた。

@Before("@annotation(functionCtrlAspect) && execution(public * *(..))")
public void validateFunctionCtrl(JoinPoint joinPoint, FunctionCtrlAspect functionCtrlAspect) {
    String flg = functionCtrlRepository.getFlg(functionCtrlAspect.value());

    if (FunctionCtrlRepository.FunctionCtrlFlg.OFF.getCode().equals(flg)) {
        throw new FunctionCtrlException();
    }
}

なぜか処理が通らなくて、すごいイライラした。。。
理由としては、@annotationが、メソッドに対してチェックしているため。
利用想定が、クラスに付与させる想定だったので、@annotationの条件に当てはまらなかった。
なので、@withinを利用するしてクラスのアノテーションをチェックするように変更して突破できた。

調査方法として、どこかの条件で紐づけが出来てないと思ったので、条件を変えて確認してた。
具体的にやった方法は、以下。

  1. 全メソッドに付与させるように条件を設定して、処理が通るか確認
  2. publicメソッドに付与させるように条件を修正して、処理が通るか確認
  3. アノテーションの条件を付与して、処理が通るか確認

広い適用条件から、段々と狭めて、何が問題なのか判断していった。
いきなり正解だと思っているものを書いていても迷うだけだったことに気づいてからは、少しずつ着実に確認できる方法にシフトしたのが、最終的なゴールに近づけた要員だと思ってる。

起動時に変なエラーが出てくる。しかもAOPとは関係なさそうなエラー

原因は、AOPアノテーションのクラス名が間違っていたので、そんなクラスのインスタンスはないって怒られていた。
怒られていたときのソースを確保するのを忘れたので、ソース内容は省略

発生していたエラーは、以下の通り

org.springframework.context.ApplicationContextException: Unable to start web server
   // 省略
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'tomcatServletWebServerFactory' defined in class path resource [org/springframework/boot/autoconfigure/web/servlet/ServletWebServerFactoryConfiguration$EmbeddedTomcat.class]: BeanPostProcessor before instantiation of bean failed
   // 省略
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.transaction.annotation.ProxyTransactionManagementConfiguration': Pointcut is not well-formed: expecting ')' at character position 75
@annotation(com.galewings.annotation.FunctionCtrlAspect(#functionCtrlAspect.value())) && execution(public * *(..))
   // 省略
Caused by: java.lang.IllegalArgumentException: Pointcut is not well-formed: expecting ')' at character position 75
@annotation(com.galewings.annotation.FunctionCtrlAspect(#functionCtrlAspect.value())) && execution(public * *(..))
   // 省略

参考情報

AOPでコントローラメソッド呼出前にエラー画面に遷移してみた|ITエンジニアとして経験・学習したこと

AspectJ の機嫌の取り方の本質 - あなたの `@Transactional` はどうして無視されてしまうのか #Java - Qiita

プログラミングのレシピ

【Java】独自アノテーションの定義・カスタマイズの方法

【Java】 独自アノテーションの作成 #Java - Qiita

Spring Bootで、独自アノテーションを目印にAOPを行う方法 - エキサイト TechBlog.

あと、GeminiとかchatGPTも利用した。
正解がわからないから、ググるのも厳しくて、大筋のあたりやヒントを得るために利用した。
まぁ、回答が正解だったかと言われると違ったが、解決のヒントにはなった。

感想

なんとかやりたいことが実現できた。。。

問題に直面した時、どうやって解決していくのか、エンジニアとしての真価が問われるなって感じた。
いきなり正解を的中させようとして泥沼にハマりかけるのは、よくあることだと思ってる。
そうなりそうってのに気づいて、別の解法を探る方法にシフトできたのが良かった。
遠回りでも、確実な方法から着実にゴールに向かうことの重要性を痛感した。
童話の「うさぎとかめ」だよなぁ。もしくは、急がば回れ
目先の最速の方法にこだわるあまり、迷走するってことは、これまでも何回か経験している。
プライドが他の方法をとることを拒絶するんだよなぁ。。。
それを捨てて、自分の状況や習熟度を客観的に見てやり方を変えられる奴は、すごいのだと思った。

結構、調べた内容に踊らされがちだった。。。
ちゃんと自分で調べて裏取りをキッチリするべきだったと思った。

忍耐力って大切だよなぁ。
問題が起きた時に、すぐにカーッとなってしまうと、解決するものも解決できない。
冷静に淡々と状況を俯瞰して、とるべき戦略を変えられる人間に、俺はなりたい。

【翻訳+意訳・要約】「生成AIは賃金や経済的格差をさらに拡大しかねない」 - EYが警笛

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

「生成AIは賃金や経済的格差をさらに拡大しかねない」 - EYが警笛 | TECH+(テックプラス)

意訳+要約

「生成AIは賃金や経済的格差をさらに拡大しかねない」 - EYが警笛

1. 生成AIがもたらす恩恵と同時に、深刻な課題も浮き彫りに

EYレポートによると、生成AIは今後10年で世界のGDPを170億ドルから340億ドルに拡大し、世界の労働人口の半数以上に影響を与える可能性を秘めています。しかし、その恩恵は一部の企業や高所得者に偏り、所得格差や市場集中、国際格差の拡大といった深刻な課題もたらす可能性が指摘されています。

2. 5つの主要なリスクと課題

  • 1. 労働需要の減少と労働者への影響: 生成AIによる自動化が進むと、労働需要が減少し、労働者の賃金低下や雇用不安につながる可能性があります。特に、単純作業やデータ入力などの仕事は、AIによる代替が容易で、影響を受けやすいと考えられます。
  • 2. 格差拡大の加速: 生成AIは、高所得者の仕事と補完性が高いため、高所得者層が恩恵を受けやすく、格差拡大を加速させる可能性があります。一方、低所得者層は、AIによる恩恵を受けにくく、さらに不利な状況に追い込まれる可能性があります。
  • 3. 市場集中と「勝者総取り」現象: 生成AI技術をいち早く導入した企業が市場を独占し、莫大な利益を得る可能性があります。これは、中小企業などの競争力を弱め、市場の集中と「勝者総取り」現象を招き、経済全体の活力低下につながる可能性があります。
  • 4. 国際格差の拡大: 生成AI開発・導入に積極的な先進国と、そうでない途上国との間で、経済格差がさらに拡大する可能性があります。途上国は、AI技術へのアクセスや人材育成が遅れ、国際競争力を失い、経済的に不利な状況に追い込まれる可能性があります。
  • 5. 倫理的な問題: 生成AIは、偏見や差別を助長したり、フェイクニュースの作成などに悪用されたりする可能性があります。AI倫理の確立や、適切な規制の導入が急務です。

3. 関係各レベルでの対策が必要

これらの課題を克服するためには、企業、政府、国際社会それぞれのレベルで対策が必要です。

企業レベル:

  • 職を失う可能性のある労働者を支援するスキ retraing プログラムを提供する
  • 倫理的なAI開発・導入ガイドラインを策定し、遵守する

政府レベル:

  • 中小企業のAI導入を支援する政策を策定する
  • 競争促進政策を通じて、市場集中を防ぐ
  • AI人材育成のための教育プログラムを実施する
  • 国際的なAI規制枠組みの策定に積極的に貢献する

国際社会レベル:

  • 開発途上国へのAI技術移転と人材育成を支援する
  • 国際的なAI倫理ガイドラインを策定する
  • AI技術の悪用を防ぐための国際的な枠組みを構築する

4. まとめ

生成AIは、経済社会に大きな変革をもたらす可能性を秘めた強力なツールです。しかし、その恩恵が一部に偏り、深刻な課題を引き起こす可能性も孕んでいます。関係各レベルが協力し、適切な対策を講じることで、生成AIの恩恵を広く共有し、持続可能な社会を実現することが重要です。

GeminiへのQA

Q:主にどういった分野での転用が見込まれているのでしょうか?

生成AIは、その強力な能力から、様々な分野での転用が期待されています。以下、主要な転用分野と、システムエンジニア目線で考えるべき注意点をご紹介します。

1. コンテンツ制作

  • 文章生成:記事、小説、広告コピー、詩歌、脚本など、様々な文章コンテンツを自動生成
  • 画像生成:写真、イラスト、3Dモデルなど、様々な画像コンテンツを自動生成
  • 音楽生成:楽曲、効果音など、様々な音楽コンテンツを自動生成
  • 動画生成:ニュース、広告、エンターテイメントなど、様々な動画コンテンツを自動生成

2. 科学研究

  • 新薬・新素材開発:膨大なデータ分析に基づいて、新たな薬剤や素材の候補を探索
  • 論文執筆:研究結果を自動的に文章化し、論文作成を効率化
  • 実験データ分析:膨大な実験データを解析し、新たな発見を導き出す

3. ビジネス

  • 顧客対応:チャットボットによる顧客対応の自動化
  • マーケティング:顧客分析に基づいた、最適なマーケティング施策の提案
  • 商品開発:顧客ニーズに合わせた、新たな商品やサービスの開発

4. 製造

  • 製品設計:3D CADを用いた製品設計の自動化
  • 製造工程の最適化:生産データを分析し、効率的な製造工程を設計
  • 品質管理:製品の欠陥を自動的に検出

5. その他

  • 教育:個々の生徒に合わせた、最適な学習コンテンツの提供
  • 医療:診断支援、治療計画の立案、創薬など
  • 金融:リスク管理、不正検知、投資判断など

感想+雑記

ゼロサムゲームが始まってるってことだろうか?
ルール作りは大切だろうけど、研究を辞めてしまったら、後発に出し抜かれるから、ルールは後追いだろうなって気がする。

クリエイター系のやつが上がってるけど、生成AIが独占するのは厳しいんじゃないかな?
不気味の谷を突破するのが、結構難しいと思うんだよね。
あと、どれも似通ってしまって、尖った作品が少ない印象がある。
たぶん、まんべんなく取ったせいで、中央値になり、刺さる人に刺さるってのができにくい気がする。
とはいえ、煩雑な作業が減るのは確実だろう。
確実。そうコーラを飲んだらゲップが出るっていうくらい確実じゃッ!

【翻訳+意訳・要約】開発者の仕事に就くには4年制大学の学位が必要ですか?

※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Do I need a 4-year degree to get a developer job? - DEV Community

意訳+要約

開発者の仕事に就くには4年制大学の学位が必要ですか?

このブログでは、4年制の学位が開発者の仕事を得る上で本当に必要なのかについて検討しています。以下は、その要点をプロの視点でまとめたものです。

  • 学位の重要性:

    • 一部の企業は学位を必須としているが、他の企業では実務経験やスキルを重視する傾向がある。
    • 学位がなくても自己学習やオンラインのコースを通じて技術スキルを磨くことができる。
  • 技術スキルの重要性:

    • 実際の仕事では、学位よりもプログラミングスキルやプロジェクト経験が重視されることが多い。
    • オープンソースプロジェクトへの貢献やポートフォリオの構築が役立つ。
  • 学費と時間の節約:

    • 4年制の学位プログラムは費用と時間がかかるため、代わりにオンラインのリソースやコースを利用することができる。
    • 自己学習やブートキャンプを通じて、より効率的に開発者になることができる。
  • 選択肢の多様性:

    • 学位がなくても、技術的な職に就く機会は増えている。
    • インターンシップや実務経験が、学位以上に重視されることもある。

このブログは、学位が開発者になるための唯一の道ではないことを示唆しており、個々人のスキルや経験、学習スタイルに合わせた選択肢があることを強調しています。

ChatGPTへのQA

Q:日本でも同じことが言えますか?

はい、日本でも同様の傾向が見られます。以下は、日本の状況に関連するポイントです。

  • 学位の重要性:

    • 一部の企業は学位を重視するが、技術スキルや実務経験を優先する企業もある。
    • 特に大手企業や公的機関は学位を求める傾向がありますが、中小企業やスタートアップは柔軟な採用基準を持っていることが多いです。
  • 技術スキルの重要性:

    • 日本のIT業界でも、実務経験やプログラミングスキルが重視されます。
    • オープンソース活動や個人プロジェクトなどの経験がポートフォリオとして評価されることがあります。
  • 学費と時間の節約:

    • 日本の大学教育は費用と時間がかかるため、オンラインのコースやブートキャンプなどの選択肢が注目されています。
    • 特に最新の技術トレンドに即したスキルを身につける場合、自己学習や専門のコースが有益です。
  • 選択肢の多様性:

    • 日本でも学位がなくても技術職に就くことは可能です。
    • インターンシップや実務経験が、学位よりも重視されることもあります。

日本のIT業界でも、学位があるかどうかよりも実務経験や技術スキルが重視される傾向があります。個々の経歴やスキルセットに応じて、最適なキャリアパスを選択することが重要です。

Q:新卒採用だと、大卒を条件にしている大企業が多いイメージがあります

確かに、日本の多くの大企業は新卒採用において大卒を条件としています。これは、日本の伝統的な採用文化や社会的期待に起因しています。大卒者を採用することで、企業は一定の学術的な基礎教育を受けた人材を確保し、将来のリーダーシップ育成や組織文化の維持に期待するからです。

ただし、近年ではいくつかの大手企業も、学歴にとらわれずに実力主義を重視する動きが見られます。特に技術系の企業やベンチャー企業では、学位よりも実務経験やスキルを重視する傾向があります。また、新しい働き方や多様なキャリアパスを提供する企業も増えており、学歴だけでなく個々人の能力や意欲を重視する傾向があります。

したがって、新卒採用においては大卒を求める企業が多いものの、学歴以外の要素も重視されることがあります。さらに、中小企業やスタートアップ企業など、採用基準が柔軟な場所もありますので、学歴にこだわらずに自分のスキルや経験を活かせる職場を見つけることも可能です。

感想+雑記

今の就職事情は知らんが、俺が就職活動していたときは、だいたい大手は大卒が条件になっていた印象。
そのせいで、俺という逸材をのがしたと思うんだよね。

たぶん、あと10年もしたら、大卒の条件が抜くところが出てくるのはなかろうか?
大学いくのは、金がかかるし余裕のない家庭は、高卒で働く可能性がある。
働き手が減少していくとなると、大卒の条件を取っ払うか、海外から雇うかのどちらかになりそうな気がする。
思うんだけど、大卒と高卒って、そんなに違うのだろうか?
俺は高卒だけど、普通に大卒の人と同じ仕事をこなしているのだが、そこまで違いがあるのかと思う。

あー、学歴コンプなのかもしれないな。
大学入るという選択肢もあるけど、そんな時間を捻出するくらいなら、遊びに使いたいと思ってしまう。

大手がどう動くかだな。
優秀なやつを見抜ける力があり、育成プログラムがしっかりしているのなら、高卒採用もありかもね。
そうなると、大学の淘汰が始まりそうな気がしないでもないが。

【翻訳+意訳・要約】基本アルゴリズム

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Basic Algorithms - DEV Community

意訳+要約

基本的なアルゴリズム

このブログ記事では、基本的なアルゴリズムについて解説します。アルゴリズムとは何か、そしてデータの検索やソートにどのように使用されるのかについて説明します。

アルゴリズムとは?

アルゴリズムは、問題を解決するための手順を定義したものです。コンピュータは、アルゴリズムを使用して複雑なタスクを実行します。アルゴリズムは、情報検索、データベースシステム、人工知能など、コンピュータサイエンスのさまざまな分野で使用されます。

アルゴリズムの種類

さまざまな種類のアルゴリズムがあり、それぞれに長所と短所があります。記事では、以下のアルゴリズムについて説明されています。

  • 線形探索: データセット内の特定の要素を検索するために使用されます。
  • 二分探索: データセットがソートされている場合に、特定の要素を効率的に検索するために使用されます。
  • 挿入ソート: データセットをソートするために使用されます。
  • マージソート: データセットをソートするために使用されます。

アルゴリズムの応用例

アルゴリズムは、コンピュータサイエンスのさまざまな分野で使用されます。記事では、以下の応用例について説明されています。

  • Web検索: Webサイトを検索するために使用されます。
  • ソーシャルメディア: 友達の投稿を見つけるために使用されます。
  • オンラインショッピング: 商品を検索するために使用されます。

GeminiへのQA

Q:アルゴリズムを効率的に学習する方法はありますか?

アルゴリズムを効率的に学習するには、以下の方法が有効です。

1. 基礎をしっかり理解する

アルゴリズムを学ぶ前に、データ構造やプログラミング言語の基本的な概念を理解しておくことが重要です。これらの基礎知識がないと、アルゴリズムの仕組みを理解することが難しくなります。

2. 書籍やチュートリアルを活用する

アルゴリズムに関する書籍やチュートリアルは、体系的に学習するのに役立ちます。初心者向けの書籍やチュートリアルから始め、徐々に難易度を上げていくのがおすすめです。

3. 実際にコードを書いてみる

アルゴリズムを理解したら、実際にコードを書いてみましょう。コードを書くことで、アルゴリズムの仕組みをより深く理解することができます。

4. 問題を解く

アルゴリズムの問題を解くことで、知識を定着させることができます。問題集やオンラインのコーディングコンテストなどを活用しましょう。

5. 他の人のコードを読む

他の人のコードを読むことで、さまざまなアルゴリズムの書き方を学ぶことができます。オープンソースのプロジェクトなどを参考にしましょう。

6. 説明する

人にアルゴリズムを説明することは、理解を深めるのに役立ちます。友人や家族に説明したり、ブログ記事を書いたりするのも良いでしょう。

7. コミュニティに参加する

アルゴリズムに関するコミュニティに参加することで、他の学習者と交流したり、質問したりすることができます。

特に重要なポイント

  • 基礎をしっかり理解する: アルゴリズムを学ぶ前に、データ構造やプログラミング言語の基本的な概念を理解しておくことが重要です。
  • 実際にコードを書いてみる: アルゴリズムを理解したら、実際にコードを書いてみましょう。コードを書くことで、アルゴリズムの仕組みをより深く理解することができます。
  • 問題を解く: アルゴリズムの問題を解くことで、知識を定着させることができます。問題集やオンラインのコーディングコンテストなどを活用しましょう。

Q:アルゴリズムに原理原則などはありますか?

アルゴリズムには、以下の5つの原理原則があります。

1. 明確性

アルゴリズムは、明確かつ簡潔に定義されなければなりません。手順が曖昧だと、誤解を招いたり、正しく実行できなかったりする可能性があります。

2. 有限性

アルゴリズムは、有限なステップで終了しなければなりません。無限ループに陥ったり、いつまで経っても終了しないようなアルゴリズムは、実用的ではありません。

3. 正確性

アルゴリズムは、常に正しい結果を出力しなければなりません。入力に対して誤った出力を出力するようなアルゴリズムは、役に立ちません。

4. 一般性

アルゴリズムは、特定の問題だけでなく、より一般的な問題にも適用できるべきです。特定の問題にしか適用できないようなアルゴリズムは、汎用性が低くなります。

5. 効率性

アルゴリズムは、できるだけ少ないリソース(時間、メモリなど)で実行できるように設計する必要があります。非効率的なアルゴリズムは、処理速度が遅くなったり、メモリを使いすぎたりする可能性があります。

これらの原理原則は、すべてのアルゴリズムに当てはまるわけではありませんが、アルゴリズムを設計する際に考慮すべき重要な指針となります。

補足

上記の原理原則に加えて、アルゴリズムを設計する際には、以下のような点にも注意する必要があります。

  • わかりやすさ: アルゴリズムは、他のプログラマーが理解しやすいように設計する必要があります。
  • 保守性: アルゴリズムは、変更や修正がしやすいように設計する必要があります。
  • 安全性: アルゴリズムは、セキュリティ上のリスクを最小限に抑えるように設計する必要があります。

参考情報

https://programming.pc-note.net/ https://products.sint.co.jp/topsic/blog/study-algorithm https://career.levtech.jp/word/list/12/ https://labol.co.jp/columns/life/basic-knowledge-that-beginners-must-know-before-becoming-freelance/

感想+雑記

無駄が少ないのがアルゴリズムとしてポイント高いってことね。
問題を、最短で無駄なく解決するのが評価が高いということなのだろう。

ソート系は色々派生があるけど、問題の状態によって解法がことなってくるのがミソよな。

アルゴリズムを覚えるには、個人的には、トレースが一番だと思ってる。
プログラミング教わったときも、トレースの大事さをクドいくらいに叩き込まれた。
あと、写生も重要。単純に書くだけじゃなくて、ちゃんとどこのどういう機能を作ってるのか意識することで、アルゴリズムをより深く認識できると思う。

話は脱線するが、写生って言葉に出すのは、ちと憚られる。
写生大会って、ワルロマが元ネタって認識なんだけど、あってるのかな?どこのだれが発祥なのか、ググってもよくわからんかった。

2024/04/29週 気づきと振り返りなどなど

業務こなしての気づき

特になし
あったのかもしれないが、メモってない。

その他雑記

個人開発

プロパティに動的変更の値はもたせるべきではない

機能制御フラグの値を持たせようと奮闘してた。。。
変更管理用の画面はすぐ出来たんだけど、肝心の値の更新が出来ず、四苦八苦してた。
よくよく考えたら、プロパティファイルって、不変な値をもたせるものだから、その値を更新しようとするのが間違えだったという結論にたどり着いた。

なので、DB管理するように変更して対応した。

学びとしては、プロパティファイルは不変値の保持、値を更新するならDBに持たせろってこと。

なぜClassNotFoundExceptionが発生するんだ?

上記の機能制御フラグをDBに持たせる対応をした際に、なぜか値取得でClassNotFoundExceptionが発生して、事件が迷宮入りしてた。

原因は単純で、SQLを作ったつもりだったが、作られていなかったのが原因。。。
ただ、似たような名前のSQLがあり、パット見、分からなかったんだよね。。。
半日悩んでた。
諦めて寝て、翌日起きたら簡単に解決してもうた。。。

解決したが、原因分かったときはマジで恥ずかった。。。
どらくらい恥ずかしいかと言うと、ドラゴンボールで完全体になる前のセルにイキってたベジータが、完全体になって手も足も出なくなったときくらいに恥ずかしかった。

Thymeleafを使ったhtmlからJavaクラスのメソッド呼び出し

抜粋すると下記。上がThymeleafを使ったHTMLで、下が呼び出してるJavaクラスの抜粋。

  <li class="nav-item mb-2" th:if="${@functionCtrlRepository.getFlg('circulation') eq '1'}">
    <a class="list-group-item" href="/circulation/">circulation</a>
  </li>
// import/packege省略

@Component
@Transactional
public class FunctionCtrlRepository {

// その他メソッド省略

    public FunctionCtrl get(String id) {
        Map<String, String> params = new HashMap<>();
        params.put("id", id);
        return sqlManager.getSingleResult(FunctionCtrl.class
                , new ClasspathSqlResource("sql/functionCtrl/select_one.sql")
                , params);
    }

    public String getFlg(String id) {
        return get(id).flg;
    }

// その他メソッド省略

}

やっていることは、SQLで値を取ってきて、それのフラグを見てタグの表示有無を判定している。 Thymeleaf側では、@クラス名.メソッド名(引数) でアクセスできる。
Controller側でやっても良かったんだが、サイドメニューのhtmlで、いろんなところのhtmlで参照しているから、全部のControllerに対応入れるのがダルかったので、Thymeleafから呼び出すように対応した。

基本的には、使いたくないんだけど、影響範囲を考慮して、こっちに変えた。
初めてやったから、いろいろな問題で躓いて辛かった。。。

参考情報

ThemeleafからJavaのメソッドを呼び出したい! | キャンパーSEの備忘録

私生活

GeminiAPI

とうとう有料化の流れになっちまった。。。。
なので、今まで無料で使っていたのは、廃止した。
簡単に言うと、APIキーを消しただけ。

【翻訳+意訳・要約】ソフトウェア開発におけるデザインパターンの本質に迫る

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Illuminating the Essence of Design Patterns in Software Development - DEV Community

意訳+要約

GeminiへのQA

このブログ記事では、ソフトウェア開発におけるデザインパターンについて解説されています。デザインパターンとは何か、そして5つの一般的なパターンの例が示されています。

デザインパターンの利点

デザインパターンは、以下の利点をもたらします。

  • コードの柔軟性、保守性、再利用性を向上させる
  • 共通の問題に対する解決策を提供する
  • コードをより理解しやすく、読みやすくする

記事で紹介されているデザインパターン

記事では、以下の5つのデザインパターンが紹介されています。

  • Factory Method(ファクトリーメソッド):オブジェクトの生成方法をカプセル化するパターン
  • Builder(ビルダー):オブジェクトを段階的に構築するパターン
  • Singleton(シングルトン):グローバルなオブジェクトを一意にインスタンス化するパターン
  • Adapter(アダプター):異なるインターフェースを持つオブジェクトを互換性のあるように変換するパターン
  • Pub-Sub(パブリッシュ・サブスクライブ):オブジェクト間の疎結合を実現するパターン

これらのパターンは、ソフトウェア開発においてよく使用されるものであり、コードをより効率的で保守しやすいものにするのに役立ちます。

Q:デザインパターンを覚えさせるには、どうするのが効率的ですか?

デザインパターンを効率的に覚えるには、以下の方法が有効です。

1. 書籍や記事を読む

まずは、デザインパターンの概要と基本的な概念を理解するために、書籍や記事を読むことが重要です。 おすすめの書籍としては、以下のものがあります。

これらの書籍は、デザインパターンのそれぞれについて、わかりやすく解説されています。

2. サンプルコードを読む

書籍や記事でデザインパターンを理解したら、実際にそのパターンを使ったサンプルコードを読んでみましょう。 サンプルコードを読むことで、そのパターンの具体的な使い方を理解することができます。

3. 自分で実装してみる

ある程度理解が進んだら、自分でデザインパターンを実装してみましょう。 実際に実装してみることで、そのパターンの仕組みをより深く理解することができます。

4. デザインパターンを意識したコードを読む

オープンソースプロジェクトなどのコードを読んで、その中でデザインパターンが使われている箇所を見つけましょう。 実際に使われているのを見ることで、そのパターンの使い方がより具体的に理解できます。

5. 問題を解く

デザインパターンに関する問題を解くことも有効な学習方法です。 問題を解くことで、自分の理解度を確認することができます。

6. デザインパターンのオンラインリソースを活用する

デザインパターンのオンラインリソースもたくさんあります。 以下のようなサイトを参考にすると良いでしょう。

7. 自分に合った学習方法を見つける

上記以外にも、様々な学習方法があります。 自分に合った学習方法を見つけて、継続的に学習することが重要です。

Q:実装しながら、覚えることは可能でしょうか?

結論:可能

デザインパターンを実装しながら覚えることは、非常に効果的な学習方法の一つです。 実際にコードを書くことで、以下のメリットがあります。

  • 理解が深まる: デザインパターンの仕組みをより深く理解することができます。
  • 使い方が身につく: 実際にどのように使うのかが身につきます。
  • 問題解決能力が向上する: デザインパターンを適用することで、様々な問題を解決することができます。
  • 実践的なスキルが身につく: デザインパターンは、実際のソフトウェア開発でよく使用されるため、実践的なスキルを身につけることができます。

ただし、実装しながら覚えるには、以下の点に注意する必要があります。

  • ある程度の基礎知識があること: デザインパターンの基本的な概念を理解していないと、実装するのが難しくなります。
  • 適切な教材を選ぶこと: 初心者向けの教材を選ぶと、スムーズに学習することができます。
  • 簡単な問題から始めること: 最初から難しい問題に取り組むと、挫折してしまう可能性があります。
  • わからないことは調べること: わからないことがあれば、書籍やインターネットで調べるようにしましょう。

具体的な学習方法

以下は、デザインパターンを実装しながら覚える具体的な学習方法です。

  1. 書籍や記事でデザインパターンの概要と基本的な概念を理解する。
  2. サンプルコードを読んで、そのパターンの具体的な使い方を理解する。
  3. 自分で簡単な問題を実装してみる。
  4. 問題を解くことで、理解度を確認する。
  5. わからないことは調べる。
  6. 理解が深まったら、より複雑な問題に挑戦してみる。

おすすめの教材

以下は、デザインパターンを実装しながら学習するのに役立つ教材です。

まとめ

デザインパターンを実装しながら覚えることは、非常に効果的な学習方法です。 上記のポイントを参考に、自分に合った学習方法を見つけて、デザインパターンをマスターしましょう。

感想+雑記

個人的には、実装しながら覚えるかな?
なんとなく実装していると、力がつかない。
実装方法で悩むことが、デザインパターンへの理解を促進してくれると思う。

学習だけだと、実際に使いこなせないことが多い気がする。
少なくとも、俺は無理だ。バカの壁を超えるのは、相当難しい。
実際に使ってみると、別の解法が良かったなんてこともある。
実践して悩んで、そのあと勉強するってサイクルが、個人的にはオススメ。

悩むのを敬遠しがちな人が多いけど、意外と悩むことは大切な儀式だと思ってる。
まぁ、自分は悩みたいとは思わないけどね。。。

【翻訳+意訳・要約】コードレビューをマスターする: レビュアーとPRクリエーターのためのガイド

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Mastering Code Review: A Guide for Reviewers and PR Creators - DEV Community

意訳+要約

コードレビューをマスターする: レビュアーとPRクリエーターのためのガイド

このブログ記事は、コードレビューに関するベストプラクティスを、レビュー担当者とコード作成者の両方の視点から論じています。

レビュー担当者にとって重要なポイント

  • 建設的なフィードバックを提供する: 攻撃的な言葉は避け、具体的なコメントや提案を行いましょう。
  • コードの背景を理解する: コード変更の理由を理解し、作者の意図を尊重しましょう。
  • コード自体に焦点を当てる: 個人攻撃は避け、コードの改善に焦点を当てましょう。
  • 優先順位をつける: すべての問題を一度に解決しようとせず、重要な問題から順に対処しましょう。
  • 代替案を提示する: 単に問題を指摘するだけでなく、改善のための代替案を提示しましょう。
  • 締め切りを守る: レビューを後回しにせず、迅速かつ丁寧にレビューを行いましょう。
  • 友情で承認しない: 個人的な感情に流されず、客観的な基準に基づいてレビューを行いましょう。

コード作成者にとって重要なポイント

  • コードを準備する: コードレビューの前に、コードを整理整頓し、コメントを付けておきましょう。
  • リポジトリの機能を活用する: プルリクエストの説明、関連するテストケース、コード変更の影響範囲などを明確に示しましょう。
  • 変更の背景を説明する: コード変更の理由や目的を明確に説明しましょう。
  • フィードバックにオープンである: レビュー担当者の指摘に耳を傾け、必要に応じてコードを変更する準備をしましょう。
  • すべてのコメントに対応する: レビュー担当者のすべてのコメントに丁寧に返信し、対応状況を明確に示しましょう。
  • 変更点をテストする: コード変更後にテストを行い、問題がないことを確認しましょう。
  • プルリクエストを簡潔に保つ: 不要な変更は含めず、変更点を明確に示した簡潔なプルリクエストを作成しましょう。

GeminiへのQA

Q:レビュアーが注意するべき点は何でしょうか?

記事によると、レビューアーは以下のような点に注意する必要があります。

  • 建設的なフィードバックを提供する: 攻撃的な言葉は避け、具体的なコメントや提案を行いましょう。
  • コードの背景を理解する: コード変更の理由を理解し、作者の意図を尊重しましょう。
  • コード自体に焦点を当てる: 個人攻撃は避け、コードの改善に焦点を当てましょう。
  • 優先順位をつける: すべての問題を一度に解決しようとせず、重要な問題から順に対処しましょう。
  • 代替案を提示する: 単に問題を指摘するだけでなく、改善のための代替案を提示しましょう。
  • 締め切りを守る: レビューを後回しにせず、迅速かつ丁寧にレビューを行いましょう。
  • 友情で承認しない: 個人的な感情に流されず、客観的な基準に基づいてレビューを行いましょう。

レビューアーがより良いレビューを行うためのヒントもいくつか紹介しています。

  • レビュー前にコードを理解する: コードレビューの前に、コードを実際に実行して理解しましょう。
  • 質問をする: コード変更の目的や背景について、作者に質問することを恐れないでください。
  • ポジティブなフィードバックを与える: 良い点も指摘することで、作者のモチベーションを高めましょう。
  • 明確かつ簡潔にコミュニケーションを取る: レビューコメントは明確かつ簡潔に書き、誤解を招かないようにしましょう。
  • チームワークを意識する: コードレビューはチームで行う作業であることを忘れずに。

Q:レビューを人とする場合と、AIなどのシステムチックなものとの比較結果を教えて下さい

項目 AI
レビュー時間 長い 短い
レビューの一貫性 高い 高い
レビューの可用性 24時間365日 24時間365日
検出できる問題 複雑な問題を含む 単純な問題
最終的な判断 必須 必須ではない
コミュニケーション 可能 困難
倫理的な問題 可能性が低い 可能性がある

感想+雑記

当たり前のことだけど、XZ Utilsの件があったから、要約にそれらを意識した文言が入ってきたな。。
以下にシステム化して運用していくのかが大切だと思う。 毎回思うんだけど、ポジティブフィードバックって必要か?
変にポジティブ要素を入れると、胡散臭くなる気がするんだけど、俺だけなのだろうか?
どう考えても無理やり弄りだした感がするから、建前だなって感じてしまうんだよね。
レビュアーとして動くことが多くなったけど、ポジティブフィードバックを入れようとは思わない。

そういえば、毎回、レビュアーがレビューをする人なのか、受ける人なのか悩むんだが、異種族レビュアーズを見てから、どっちがレビュアーなのか迷うことがなくなった。
レビューに臨む姿勢をというものを学べたぜ☆