API Keyを取得して利用する方法について
一般的な方法として、codex loginを実行してブラウザからログインして使えるようになります。
API Keyを使って使えるようにしたかったので、その手順などをまとめておく。
API Key名など、必要な情報を入力して作成。
「Save your key」ダイアログにKeyが表示されるので、コピーボタンでコピーします
環境変数 OPENAI_API_KEYを指定しながら、codexを起動。
OPENAI_API_KEY=<copied_key> codex
成功。なんですか、このマークは？
ChatGPTでログインを選ぶと、ブラウザからログインを促されるので差は特に感じないかも。
GoやRustでNativeバイナリを作成し、実行する時にポップアップが表示されて実行ができない。
MacOSには Gatekeeper という機能により、Appleによる署名や公証バイナリのチェックがなされ、確認を通過できないと実行させない仕組みがある。
その時の対処方法。
バイナリ側にAppleの認証が通るように設定してもらう。
- Developer ID
- Apple notarization
配布側に依頼できるのであれば、対応してもらうのが一番良いと思われる。
以下の手順
1. Finderから対象のバイナリを右クリックし、「開く」を選択。
2. 「開いてもよろしいですか？」のような確認がされるので、「開く」を選択。
3. バイナリは実行される。
一度許可すれば、効果が有効な間は再度の実行やCLIからの実行も可能になるようだ。
実行可能になる
xattr -d com.apple.quarantine </path/to/binary>
バイナリ単位でquarantineを操作して認証をスキップする。
参考 - keith.github.io - support.apple.com
コード生成型のAIをつかうための情報を記載する。
選択肢としては複数あると思うが、私はChatGPTの有料プラン（Plus）に加入していたので、Codexも使ってみようと思いました。
IDE連携もできるので、そちらを使おうと思います。
CursorやWindsurfなどでも使えるようですが、今回は多少使っているVisualCodeを使う前提について記載します。
OpenAI製のコード生成AI機能。コード生成AIは人間が言葉でプロンプトから指示することで既存コードの解析・修正・リファクタリングなどをすることが可能。
GitHub 上の膨大な公開ソースコードを学習しているらしい。
個人的には複雑なコードや新しいプロジェクトの説明や、ユニットテストの実装を補助してもらえるのは非常に助かると思う。
ChatGPTの有料プランに入っていればCodexを利用可能らしい。 - ChatGPT Plus - ChatGPT Pro - ChatGPT Team / Business / Enterprise - ChatGPT Edu
PCからの操作を前提にします。
ChatGPTのブラウザを開く。
左側のサイドバーにある「Codex」をクリックし、ブラウザの別タブからCodexのブラウザ画面を開く。
GitHubと連携、認証を行う。
Codexの拡張機能を追加する。
※見失った場合、拡張機能（Ctrl+Shift+x）でcodexで検索して拡張機能を探すことも可能。
拡張機能を追加後、右上にChatGPT風のアイコンが出てくる。クリックしてCodexを起動。
ChatGPTと連携する。API Keyを設定する方法、ChatGPTにサインインする方法があるが、今回はサインインする。
サインインボタンをクリックすると、ブラウザが開いてChatGPTへのログインが促される。ログインして「ChatGPT を使用して Codex にサインイン」を続行する。
「Signed in to Codex」に画面が変わったら、IDEにもどる。
画面にCodexのターミナルがつかえるようになる。チュートリアル的な説明があるので、適宜必要な個所を確認し、Nextを押して進んでいく。
ターミナルに入力できるようになったら利用開始の準備は完了。
タスクの入力をプロンプトから入れたりできる。Chatモード、AgentモードやAIモデルの選択をしたりもできるので必要に応じてカスタマイズする。
以上、おつかれさまでした。
プログラミングを行うとき、ソースコードレビューは非常に重要な役割を担います。
１０年前、２０年前と比べても重要性はあがっていて、仕事やチームで開発する場合は現在では「やって当たり前」くらいの扱いになっているように感じています。
開発の基礎となるべきコードレビューですが、オンボーディングでの説明やチームでの認識合わせのために話している内容をまとめておきたいと思い、記述することにしました。
ソースコードレビューするときの心得について、私の考えや意識していることを記載しようと思います。
ソフトウェアを開発する際、ソースコードの管理はバージョン管理システムをつかっておこなうと思います。
ソフトウェアのオリジナルとなる管理バージョンから、開発者の担当分の開発によるソースコード差分を第三者が確認することをコードレビューと呼びます。
ここではGitを前提に具体的な話を勧めます。
Gitで開発する際、大本となるmain branchがあり、そこから派生したsub branchを作成し、sub branch上で担当者が開発を進めることがあると思います。
sub branch上での作業が完了した際に、main branchに開発差分を合流（merge）させる必要があります。
mergeする前にチームメンバーや共同開発者の確認を専用のシステムで行ってもらいます。
GitHubなどのGitのホスティングサービスではデフォルトで使えるようになっていると思います。
コードレビューをおこなうことで以下のメリットがあります。
レビューをする側をレビューアーと言います。
この時の私の考える注意点について以下に記載します。
重要度：最高
開発によって実現したい要求である仕様を満たせているかを確認することが一番大事だと考えています。
今のソフトウェアでは実現できなかったことを実現できるようにするために開発を行っていると思うので、まず開発によって要求を満たせているかが一番重要だと考えます。
機能として十分か、機能要件・性能要件など様々な指標をクリア可能か、実装者の仕様の解釈は問題ないかなど確認が必要だと思います。
重要度：高
プログラムにバグなどがないかという視点でレビューしています。
たとえばパターンの考慮漏れや、プログラム言語やミドルウェアなど固有の個性による問題を引き起こさないかなどの視点で確認が必要です。
重要度：高
実装者やユニットテストなどの確認は十分か、レビューアーとして確認します。
動作上問題ないか。と似ているかもしれませんが、テストの視点についてはここでは分けました。
実装者自体がただしく動作確認しているか、ユニットテストで必要なパターンが実装されているかの視点でレビューの段階でおこないたいです。
ユニットテストの実装自体がされているかももちろんですが、テストする観点やパターンも十分か確認します。
重要度：高
保守性についてもレビューの対象になると考えています。
実装方法は問題ないか、今後変更する場合に変更しやすいコード、読みやすいコードになっているかなどの視点で確認します。
数か月後に自分がメンテナンスできるコードになっているかなど考えてレビューしています。
重要度：低
チーム内でコード規約があった場合、ルール通りの実装になっているかを確認します。
例えば、プログラム言語上は実装可能だが、あまり好ましくない実装方法になっていないか。など。
ただし、この部分を「重要度：低」として捉えているのは、人間によるレビューとするにはコストがもったいないように感じているからです。
後述もしますが、こういう機械的にできる部分はなるべく自動化など機械に任せて、人間にはより価値の高い仕事ができる環境にしたいと考えます。
重要度：最高
あえて意識する必要もない人も多いと思いますが、必要事項として。
指摘の仕方は重要だと思います。
実装者側は「問題ない」と判断してレビューに出していると思うので、的確に指摘できているかは意識したいです。
指摘は必要ですが、中傷にならないようにする意識は重要です。
また、「本当に変更は必要か」というのは常に自問自答しています。変更してもらうということは、相手の工数を発生させていることは意識して、経済的な部分でもコストが見合うかは検討しています。
レビューをする側をレビューアーと言います。
この時の私の考える注意点について以下に記載します。
※テクニック的な部分よりメンタル的な部分ばかりになってしまった。
第三者にレビューしてもらうまえに、自分できる確認はやっておきたいと思います。
レビューアーの注意点で書いた内容を自分でおこなうことや、
実装が終わってから数時間から１日たってから確認するようにしたいと思います。
時間をおけば自分でも多少客観的に自分の仕事を見つめなおせるので、自分でも問題点に気づきやすくなります。
レビューアーからの指摘は、基本的に修正するように考えています。
レビューイーは背景や実装意図を十分理解していますし、また実装したときのテンションの上昇と疲労からコード細部について見落としがあるかもしれません。
第三者であるレビューアーが違和感を感じていたら、当事者よりも客観視しているはずですし、その視点は実装したときの記憶のなくなった将来の自分かもしれず、将来修正が必要になった時に背景や意図を忘れているかもしれません。
「コレどっちでもよくないか？」と思うことでも、第三者視点を優先して修正するようにしています。
それでも納得できそうにない場合や修正するメリットを見いだせない場合はレビューアーに指摘の意図を確認し、話あうことも解決策の一つだと考えています。
あえて意識する必要もない人も多いと思いますが、意識として持っておきたいので記載したいと思います。
自分としては完璧なものを用意したつもりだと思うので、指摘された内容によっては、もしくは指摘されたこと自体に良い印象を覚えないこともあるかもしれません。
それでも貴重な機会であること、良い品質の仕事をするために必要なことだと捉えて冷静に対応するように心がけたいです。
レビューの仕組みづくりは非常に重要だと思います。
事前に環境の充実や、認識合わせをしておくことで、負担減やレビューの目的の認識合わせをしてレビュー自体の精度を上げていきたいと思います。
必要であれば、チームでレビューするときのルール作りもしておきたいです。
また、レビュー規約は「作って終わり」ではなくて、アップデートが前提にあることを考えておきたいです。
スクリプトやCI機能などを使って、自動化できる部分は自動化したいです。
単純な工数削減や、レビュー時の負担を減らすことでレビューアーの集中力を維持することでレビューのクオリティ向上に貢献したいです。
ターゲットとなるのは、Linter設定などを使って文法やコーディング規約に沿っているかなどは自動で解決できることが理想です。
2025年現在だとAIレビューなども可能な環境もあると思いますが、積極的に活用していきたいです。
レビューをすることもされることも工数的にもメンタル的にも非常に大変です。ですが、非常に重要だと思います。
重要な業務やアクションの一環だと思い、感謝の気持ちを忘れずにやっていきたいと思います。
Dockerを管理するツールとしてRancher Desktopを使えるようにする方法を説明します。
Dockerの管理ツールとしての候補としては Docker Desktop があります。
公式ツールなので、機能が十分であったり、サポートプランがありますが、
ただ、Docker Desktopをつかう場合には、条件次第でライセンス費用1が発生します。
比較的大きめの事業をされている企業での利用や、所属企業でRancherを利用しているので環境を揃えたい場合などに利用する理由になりえます。
Dockerの管理のための機能が十分に備わっています。
Docker Desktopなど、他の管理ツールをインストール済みの場合に必要です。
事前に削除するのをお勧めします。
Docker Desktopに付属しているdockerコマンドと重複したり、機能の衝突で正しく動かなくなる可能性があるためです。
コントロールパネルからプログラムのアンインストールをしてください。
コントロールパネル=>プログラム=>プログラムのアンインストール を選択します。
ダイアログが開き、中にアプリケーションの一覧があるので、その中からDocker Desktopを選択し「アンインストール」をクリックします。
さらに表示されるダイアログから削除の確認をされるので「はい」を選択して削除を実行します。
Docker DesktopのアプリをMacのアプリ一覧からゴミ箱に移動させます。
Finderを開き、左側の一覧から「アプリケーション」を選択します。
アプリケーションの一覧から「Docker Desktop」を選択肢、ゴミ箱み移動させます。
不要であればゴミ箱を空にしてファイルを削除してください。
以下のサイトからインストーラーを取得し、アプリケーションをインストールします。
自分の環境（Mac、Windowsなど）にあったインストーラーを選択し、ダウンロードを開始します。
ダウンロードが完了後、インストーラーを実行します。
承認や設定を確認後、インストールを開始します。完了するまで待ちます。
システム変更の確認が出る可能性がありますが、基本的には承認して継続します。
（管理者権限の確認や、WIndowsサブシステムの権限変更のため。その他の不審な確認があった場合は注意や中断をしてください）
完了した後、設定反映のための再起動を促されますので、準備してから再起動します。2
アプリケーションを起動します。
以下のような画面が出てくると思います。
初期設定のまま問題ないので今回はこのまま進みます。
（必要がある場合は応じて変更してください。）
以下の画面になれば起動完了です。
Dockerを動かすための環境としてRancher Desktopの起動している状態が必要になります。この状態で完了です。
Dockerが使えるようになっていることを確認します。
以下のコマンドは例です。LinuxのDockerが起動できるようになったことを確認します。
docker run --rm rockylinux:9.3-minimal echo hello rancher Unable to find image 'rockylinux:9.3-minimal' locally 9.3-minimal: Pulling from library/rockylinux 8ec988941d66: Pull complete Digest: sha256:305de618a5681ff75b1d608fd22b10f362867dff2f550a4f1d427d21cd7f42b4 Status: Downloaded newer image for rockylinux:9.3-minimal hello rancher
dockerコマンドが正常に実行できたので成功です。
補足:
Rancher Desktopが起動していないと、以下のようにエラーになります（docker daemonに接続できないエラー）。
>docker run --rm rockylinux:9.3-minimal echo hello rancher docker: error during connect: in the default daemon configuration on Windows, the docker client must be run with elevated privileges to connect: Head "http://%2F%2F.%2Fpipe%2Fdocker_engine/_ping": open //./pipe/docker_engine: The system cannot find the file specified. See 'docker run --help'.
Macの場合、設定に「Virtual Machine」という項目があります。
環境に応じて設定を変更してください。
設定の推奨や意図については以下の通り。
| 設定タブ名 | 設定値 | 説明 |
|---|---|---|
| Hardware | Memory: 8, CPU: 4 | dockerを使用するときに使うリソースの上限。利用状況やホストPCの性能と相談 |
| Volumes | virtiofs | Apple仮想化を利用してファイルパスを共有ディレクトリとしてマウント。EmurationでVZを利用しているからも理由。 reverse-sshfsだとssh経由でのマウントのため、セキュアだがファイル操作に制限がある（権限変更など）。特に操作が不要なら他の設定でも可 |
| Emuration | VZ | Apple仮想化システムを使う設定。 古いMacOS（12.3以下）を使っていた時にQEMUを使うとメモリ不足に陥る事象があった時の名残3 |
以上で設定は完了です
以下の書き方でbuild.gradle.ktsを書いた場合に、「Unresolved reference: libs」というエラーが出てprojectを読み込めない場合がある。
plugins {
alias(libs.plugins.android.application)
alias(libs.plugins.jetbrains.kotlin.android)
}
原因の一つはgradle/libs.versions.tomlがないか、設定が誤っている。
※以上のファイルはAndroid Project作成時に生成される。存在しない場合は誤って消してしまったなどの可能性がある。
対処方法としては、新規でAndtoid StudioからProjectを生成し、gradle/libs.versions.tomlを作成してコピーする。
もしくは、以下のファイルを該当ディレクトリに置く。
[versions]
agp = "8.5.1"
kotlin = "1.9.0"
coreKtx = "1.13.1"
junit = "4.13.2"
junitVersion = "1.2.1"
espressoCore = "3.6.1"
lifecycleRuntimeKtx = "2.8.4"
activityCompose = "1.9.1"
composeBom = "2024.06.00"
[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "coreKtx" }
junit = { group = "junit", name = "junit", version.ref = "junit" }
androidx-junit = { group = "androidx.test.ext", name = "junit", version.ref = "junitVersion" }
androidx-espresso-core = { group = "androidx.test.espresso", name = "espresso-core", version.ref = "espressoCore" }
androidx-lifecycle-runtime-ktx = { group = "androidx.lifecycle", name = "lifecycle-runtime-ktx", version.ref = "lifecycleRuntimeKtx" }
androidx-activity-compose = { group = "androidx.activity", name = "activity-compose", version.ref = "activityCompose" }
androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "composeBom" }
androidx-ui = { group = "androidx.compose.ui", name = "ui" }
androidx-ui-graphics = { group = "androidx.compose.ui", name = "ui-graphics" }
androidx-ui-tooling = { group = "androidx.compose.ui", name = "ui-tooling" }
androidx-ui-tooling-preview = { group = "androidx.compose.ui", name = "ui-tooling-preview" }
androidx-ui-test-manifest = { group = "androidx.compose.ui", name = "ui-test-manifest" }
androidx-ui-test-junit4 = { group = "androidx.compose.ui", name = "ui-test-junit4" }
androidx-material3 = { group = "androidx.compose.material3", name = "material3" }
[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }
jetbrains-kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
コピーした後は追加ライブラリの情報など、Syncして追加してあげてください
VSCode で Active Profile を設定する場合、どうするのが良いだろうと調査したので書いておきたいと思います。
SpringBoot には Active Spring Profile という機能が存在します。
開発環境、本番環境で使うDBの種類やリクエスト先のサーバーURLが異なる場合に、設定値で切り替えると思いますが、
この機能で環境毎に設定ファイル自体を切り替えることができるようになります。
デバッグ実行の設定から Active Profile を指定して起動するものを追加するのが良さそうです。
Active Profile を有効にして起動するには以下の方法があります。
- コマンドライン引数にして渡す。起動時のオプション指定に --spring.profiles.active を指定する。
- Java System Option に渡す方法。起動時のオプション引数に -Dspring.profiles.activeを指定する。
「Run and Debug」から設定を追加します。
左サイドメニューから「Run and Debug」のボタンをクリックし、
歯車マークを押すことでlaunch.jsonファイルを開くことができます。
launch.json の configurations に、argsに --spring.profiles.active=<環境名>を指定した設定を追加します1。
今回追加した設定は以下になります（product 毎に変化する場所は必要に応じて変更してください）。
{ "type": "java", "name": "Launch SpringTutorialApplication Local", "request": "launch", "mainClass": "jp.co.who.spring_tutorial.SpringTutorialApplication", "projectName": "spring_tutorial", "args": "--spring.profiles.active=local" },
この設定を保存後、Debug Run の項目から、追加したRunタスクを選択できるようになります。
今回の例だと「Launch SpringTutorialApplication Local」になります2。
application-local.property 、application-local.yaml を使って SpringBoot が起動されます。
