Spring Framework 6.1 から追加された RestClient を試してみる - Qiita
この記事はNTTコムウェア Advent Calendar 2023 13日目の記事です。 はじめに こんにちは、NTTコムウェアの田村です。 普段はMacchinetta Framework、Springプロジェクトに関する社内からの問合せ対応や技術検証を行っています。 今回は Spring Framework 6.1 から新しく登場したRESTクライアントである RestClient について公式ドキュメントを参照しつつ試してみました。 Spring Boot では 3.2 からRestClientをサポートしています。 本記事では Spring Framework 6.1.1 をもとに説明しています。 6.1.1 では RestClient による API 応答結果が no response body の場合、null ではなくエラーが返却されることが報告されています（ 6.1.2
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA（命名的問題）より、グループB（構造的問題）の方が正答率が大きいということ。一方でグループA（命名的問題）よりグループB（構造的問題）の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
Prompt Engineering Guide – Nextra
Prompt Engineering Guide プロンプトエンジニアリングは、言語モデル（LMs）を効率的に使用するためのプロンプトを開発および最適化する比較的新しい学問分野です。プロンプトエンジニアリングのスキルを身につけることで、大規模言語モデル（LLMs）の能力と限界をより理解することができます。 研究者は、プロンプトエンジニアリングを使用して、質問応答や算術推論などの一般的なおよび複雑なタスクのLLMsの能力を向上させます。開発者は、LLMsやその他のツールとのインタフェースとなる強固で効果的なプロンプテクニックを設計するためにプロンプトエンジニアリングを使用します。 プロンプトエンジニアリングは、プロンプトの設計と開発に限らず、LLMsとのインタラクションおよび開発に役立つ幅広いスキルと技術を含みます。これは、LLMsとインタフェースすること、ビルドすること、能力を理解すること
ゼロから考えないで既知の思想や他人、潮流に従ったほうがよい - Lambdaカクテル
常識は疑うほうが良い、みたいな妙な思考が頭の中にあって、何かを考えるときに無駄に根本的な所から考えてしまう。 例: 上の階がやかましいようだ 考える: そもそも夜間に振動を発生させるという行為に対する考え方は歴史的にどのように発展していったのか…… 普通こう考えたほうがいい: 管理会社に言ってみるか まったく無駄である。しかしなんか哲学的に考えたほうがカッコ良いみたいな謎のアレがあり、脳を無駄にしている。そのほうが言葉がポンポン出てきて面白いのだが、別にそういうことは既に世界のめちゃくちゃ賢い人が既に通過済みである。 speakerdeck.com 既に通過済みのパッセージを通ったところで劣化版の思考が、再生産されるだけだ。劣化してるので使えないし、再生産しているので無駄なだけだ。 良い書物はイシューに到達するまでの思考の過程をちゃんと再現してくれる。良い書物は基点となってくれる。良いとさ
レビュワーを"憑依"させて Pull Request をセルフレビューする - Konifar's ZATSU
メンバーと1on1をしていると、「うっかりミスが多くて Pull Request で毎回コメントをもらってから気づくのを何とかしたい」という相談を受けることがある。 まず、そういう認識を持てていることが素晴らしい。課題意識があるのであれば、どう補正していくかを一緒に考えることができる。 自分がオススメしているやり方は、レビューを依頼する前に徹底的にセルフレビューすることである。巷でよくやられている方法ではあるが、どういうやり方かを雑に書いておく。 レビューを依頼する前に レビュワーになりきって 自分の Pull Request を自分でレビューしてみる 頭にレビュワーが思い浮かぶのであれば、その人を "憑依" させるイメージ 「この人はここでこういうコメントしそうだな」と思ったら、 先回りして PR上にコメントしておくか、突っ込まれないようにコードやコードコメントを改善する タイトルや説明
35年と3ヶ月間働いて、とうとう定年になりました。 区切りとして、定年エントリーを書きました。お楽しみください。 - Vengineerの妄想
はじめに 今日、勤務先の制度上、定年を迎えました。大昔は、誕生日をもって定年でしたが、最近は定年を迎える月の末日ということのようです。 早いもので、35年と3か月(423か月)、雇われる身として、働いてきました。ちなみに、国民年金の満額は、480か月ですので、満額は貰えません。 今月末に定年エントリーを各予定です。 若い頃の働き方が定年までできるのはほぼ無理です。 家族が増えたり、家の購入、子供教育、親の介護などいろいろな事が起こります。 起こる前提にしておかないと、辛いだけです それから勤務先からの要求も変わっていきます。 という内容を残したいと思います。— Vengineerの妄想 (@Vengineer) 2024年6月9日 定年を意識したのは、パンデミックの2年目です。おこちゃまが大学進学のためにお家から出て行ってからです。 最初に定年について書いたのが下記のブログです。 veng
t-wadaさんの開発生産性の観点から考える自動テストを聴講して悔い改めたこと - shoudaiの日記
t-wadaさんのセッションを聴講したこと 2024/6/29に開発生産性カンファレンスに参加してきました。 その中でなんでもかんでもE2Eテストでも実行してしまうことがあるけど、 悪ではないけどデメリットもあるよ。って話がありました。 speakerdeck.com スライドP47のアイスクリームコーンとピラミッドの図だけはご参照ください。 頭の中にその図が残っているため、前提になってます。 セッションの概要 アジェンダからざっくりお話は 信頼性の高い 誤検知（テストとして正常であるはずがエラーになってしまう）や見逃し（エラーがあっても正常にしてしまう）がないこと 実行結果 実行結果値だしたり、エラー原因が特定しやすいテストを書くこと 短い時間で到達 確認したい観点を確認できる最小のテストスコープ（単体テスト、結合テストなどの粒度）でテストできるようにすること 状態に保つ 短い時間で到達
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
