ChatGPT＋Codex でアプリを作成してみたテスト

github.com

主に StableDiffusionWebUI で生成した画像をメインに管理するためのビューワーです。
で、このリポジトリですが、大分縛りプレイで作成しています。

• コードは人間が読めるレベルを維持する
• ちゃんとモジュール・構成などを定義し、かき捨て実装はさせない
• バグ修正も含め、原則的に手動でコード改変しない

という縛りです。

進め方の手順

Chat-GPT 側で仕様書を作成する

• ChatGPT に、プロジェクトを作成します。
  • プロジェクト機能を利用すると、新しいチャットを開始する際に、プロジェクト内の他のチャット、参照資料を参照して行動するようになります。
• 実装規約を事前に相談します。
• 「実装仕様の相談」という形にチャットを開始します。
  • 壁打ちしながら、仕様の穴や漏れを埋めていきます。
• 仕様が詰まったら、「実装仕様として一つのマークダウンテキストにしてください」として出力します。

Codex 側

• 作成した実装仕様書を、マークダウンファイルにしてフォルダに投下
• 「XXXXに従って実装して下さい」で実装
  • 事前に Skill 定義で、単一責任の原則を読みづらくならない限りは守るというような定義をしておくと便利
• 読みづらかったり、役割が複雑化してきたら該当クラスを役割で分割させる
• 作成された実装の動作検証を行ったら、生成されたファイルの一覧、ファイル内クラス・メソッドの仕様書を作成させる

Chat-GPT の「参照情報」にファイルを添付

• 作成したファイルの一覧、ファイル内クラス・メソッドの仕様書を「参照情報」に追加。
• 何なら「実装仕様」もリリース単位のファイルにまとめて「参照情報」に入れておくと、リリース時のリリースノート作成でも参照できる

まとめ

単純に Codex に指示だけ飛ばすと、一筆書きの書き捨てコードを生成してきます。
なので、事前に Chat-GPT で実装仕様を詰めておくのが便利です。

Codex でチャットすると、トークンも消費するので余計に…

SOLID 原則

プログラミング、特にオブジェクト指向で有名な SOLID 原則…と思うのだけど、案外知られてないのですよ。
なんで、ここでは SOLID 原則について説明していきます。

Single Responsibility Principle ：単一責任の原則

「クラスやモジュールを変更する理由は、たったひとつであるべきだ」 という原則です。

• 内容 :
  1つのクラスに複数の役割を持たせないこと。
• 目的 :
  1箇所を直した際の影響範囲を限定し、「あっちを直したらこっちが壊れた」という事故を防ぎます。
• 注意点 :
  ただし、細かく分けすぎると逆にコードの全体像が見えにくくなるトレードオフがあります。
  ユーティリティ処理（業務ロジックを含まない手続き。例えば特定フォーマットのテキストを日付データに変換する処理など）なんかは問答無用で分離して大丈夫です。
  ロジック側の場合、DRY原則（Don't Repeat Yourself ：同じ処理を二度繰り返さない）に抵触しそうなときまで分離を考えないというのも一つの手です。

Open/Closed Principle : 開放閉鎖の原則

「拡張に対して開いており、修正に対して閉じているべきだ」 という原則です。

• 内容 :
  新機能を追加するときに、既存のソースコードを書き換えるのではなく、新しいコードを追加するだけで済むように設計すること。
• 目的 :
  安定して動いている既存部分に手を加えないことで、デグレ（品質後退）のリスクを最小限にします。
• 例 :
  例えばユーザーレコードを作成するメソッドの引数を、ユーザー名、パスワードなど個別の引数を使うと、項目が増えるたびに既存メソッドを更新する羽目になりますが、「ユーザーオブジェクト」を定義していればそもそもメソッドの書き換えはしなくていいというヤツです。

Liskov Substitution Principle : リスコフの置換原則

「子クラスは、親クラスの代わりとして常に利用可能でなければならない」 という原則です。

• 内容:
  派生クラス（子）は、継承元（親）の期待される振る舞いを裏切ってはいけないというルール。
  例えば Logger クラスというログを標準出力に表示する親クラスを継承した、 FileLogger のインスタンス（ログをファイルに出力する）を Logger の代わりに使っても、呼び出し元に影響しないようにする…とか。
• 目的:
  多態性（ポリモーフィズム）を安全に利用できるようにします。
• 注意点 :
  ペンギンクラスを鳥クラスから継承して「飛ぶ」メソッドでエラーを出すなど例外は考えるべきでしょう

Interface Segregation Principle : インターフェース分離の原則

「利用しないメソッドへの依存を強制してはならない」 という原則です。

• 内容:
  巨大で汎用的なインターフェースを作るのではなく、特定の目的に特化した小さなインターフェースに分割すること。
• 目的:
  クライアントが必要な機能だけを知るようにし、不要な再コンパイルや依存関係を排除します。
• 例 :
  便利そうだから…と、「こんな呼び方できるやろ」とかメソッドを沢山用意しても使わないとか意味NEEEEEEって話です。

Dependency Inversion Principle : 依存性逆転の原則

「上位モジュールは下位モジュールに依存してはならず、両者は抽象に依存すべきである」 という原則です。

• 内容:
  具体的な実装（データベースの操作など）に直接依存するのではなく、抽象的なインターフェースを介してやり取りすること。
• 目的:
  下位レイヤー（DBの種類や外部API）の変更が、ビジネスロジック（上位）に波及しないようにします。
• 例:
  ディスプレイクラスが、ビデオ、ブルーレイ、HDDの各クラスに依存してると、起動時にどのインスタンスを実行するか調べる手続きが必要になってしまう…ので、ビデオ、ブルーレイ、HDDの共通インターフェースで Media.play メソッドを切り出して、ディスプレイからは引数で Media を受け取って play メソッドを呼び出す（play というインターフェースにのみ依存する）という方法で、依存を整理できる。

テキストで設計図を描きたい！Mermaid Chart

紹介するプラグイン

marketplace.visualstudio.com

ニーズ

まず、Excel とかで仕様書を描くというニーズは多いはず。
しかし一方で、皆思ってるはずだ。

Excel の図でフローチャートとか発狂したくなる と…

如何せん Excel で設計図を描く場合いくつか問題がある。

• Git とかでバージョン管理しづらい
• 配置するのにいちいちマウス操作が必要

もうね個人的にどっちも許せないわけですよ…
で、そういうフローチャートを描く場合、過去にはいくつかプロダクトがあったわけです。

Graphviz

graphviz.org

こいつは、グラフを記述するための専用言語、「dot言語」があり、これで記述したファイルをコンパイルすることでグラフに変換するというものだ。

汎用的なグラフ表示を実現するため、細かくカスタムすることができ、テキストで記述できることから、昔はこれを利用していた。
VSCode ならこんなのがある

marketplace.visualstudio.com

これはこれでいいのだけど、メンバーに 「dot 言語覚えて」は言いづらいところがある…

draw.io

もう一つは draw.io もなかなかいいものではある。

www.drawio.com

VSCode 上でも実行することができて、そのプラグインはこっちだ。

marketplace.visualstudio.com

マウス操作が前提ではあるものの、図のタイプを指定して作成など、Excelの様に汎用的にあれもこれもではないため、作成労力は幾分かマシです。
また、ファイルが内部的に XML ファイルであるため、バージョン管理による差分管理もできるのは利点です。

Mermaid を使う理由

• 完全にテキストだけで完結するチャートが描ける(バージョン管理しやすい)
• Grapviz の様に汎用的になんでも…ではなく、プリセットによって描ける図をあらかじめ定義されているので、記述がシンプル

というメリットがある。

最近アップロードした動画類

CSV ファイルを Python で加工する

youtu.be

ヨドバシゴールドポイントカードの CSV ファイルを、Zaim という家計簿管理ソフトの CSV 取り込みにやりやすいように加工するサンプル。

Python の技術要素

• ファイル列挙
• CSVの入出力
• 正規表現

【初級向け】 Salesforce LWC の @api / @wire の使い方

youtu.be

Salesforce 上の Lightning Web Component にてよく利用される、@api と @wire の意味と使い方について説明します。

Salesforce 技術要素

• LWC 、デコレータ

JavaScriptの変数スコープのちょっと深い話

youtu.be

JavaScript の変数スコープ、ブロックスコープとファンクションスコープの他、関連する話題としてバインド、レキシカルスコープなどについて説明します。

技術要素

• VSCode のプラグイン Live Preview
• let, const, var のスコープについての説明
  • ブロックスコープ
  • ファンクションスコープ
• クロージャでの変数バインド
• ファンクションスコープと関数の関係
• レキシカルスコープ

JavaScript関数のちょっと深い話

youtu.be

JavaScript の関数の宣言、引数の書き方や機能は、思ったより多い物。 ここでは普通の関数宣言や引数だけでなく、関数のスコープや扱いなどを説明します。

技術要素：

• 関数 　- 関数の即時呼び出し構文 　- 関数の巻き上げ 　- 関数オブジェクト 　- 高階関数 　- 関数のスコープ
• 引数 　- 引数名の衝突と変数での上書き 　- 引数の数を外から確認する 　- デフォルト引数、残余引数 　- 分割代入 　- arguments オブジェクト

敗者のゲーム(11-12)

この記事

前回の続き

white-azalea.hatenablog.jp

• 11章:収益率の特徴と中身
• 12章:リスクが収益を生み出す

超ざっくり各章まとめ

• 11章:値上がり益はリスクがあるからこそ、リスクを織り込んで高くなる。
• 12章:市場のリスクは認識しておけ。

敗者のゲーム(9-10)

この記事

「敗者のゲーム」を各章単位でざっくりまとめていくよ。
9-10章

超ざっくり各章まとめ

• 9章 : 自分のリスク、知識レベル、収入などを考えて、自分に合った投資方法、ポートフォリオを考えよう。
  因みに、FPに相談するなら、6つのポイントを押さえて相談しよう。
• 10章 : 短期と長期では投資方法自体が大きく変わる。短期であるほど振れ幅は大きいから、安全資産へも投資が必要になる。
  だが、長期視点で投資するなら、より収益性を狙った投資ができる。

敗者のゲーム(7-8)

この記事

「敗者のゲーム」を各章単位でざっくりまとめていくよ。
7-8 章。

超ざっくりまとめ

一言でまとめるとこんな感じ。

• 7 章 : インデックス投資は無駄な情報集や判断をすっ飛ばして、長期的なポートフォリオ戦略に注力できるよ。
• 8 章 : 感情やバイアス、思い込みで失敗する事は多い。ともかく冷静に、リスク回避を心がけよう。