核となる物は共通モジュールとして作成しておいて、形式が違う部分については個別にみたいな感じでやる時とかに便利ですね。

慣れた人からすると当たり前そうな感じの事ですが、慣れてないとこの辺の管理が面倒だったり無茶苦茶になりがちなんですよね😅
（自分はだいぶ適当なので規模デカいプログラムの関数や変数等の管理ができませんw）

ある程度以上のプロジェクトだと必須かなと思ってます。

対話形式で、システム要件からフォルダ、ファイルの構成の雛形を作成して、それをベースに各モジュールをコーディングしていくってのが非常に容易に行えるのが良いですね。

単一のファイル単位で作成とかだと後々拡張したい時に意味わからんようになるので・・😅

グラフィカルな表示のアプリ作りたいとなると多分、pythonでバックエンド（データ処理等）を行って、画面表示（ブラウザ）の処理はJavascript(React）とかフロントエンド用の言語使うことになるとおもうで、って・・・初心者向けではないかもしれない・・・ｗ

また、Webアプリ作りたいなとなって、JavascriptとかReact利用しようとすると、基本のプロジェクトの構成のファイル量が多い（１ファイル自体のコード量は多くない）のでこれまた個別にAIで読ませてってやると怠すぎるのでプロジェクト単位で全体見てコーディングできる恩恵がデカい。

というか逆に自分のプログラミングスキルだとこれがないとプロジェクトレベルのアプリは作成できないって感じです。

どれくらいの規模の開発をするかによるんですが、1ファイル2500行くらいが限度で、それ以上になると分割する感じになるんですが、そういうファイルが何個も出てくると個別ファイルのコーディングだとやってらんなくなってくるので、プロジェクト単位で全体をみてコーディングしてくれるClaude Codeは便利です。
が、トークン消費が激しいのでProMax(100$)のプランでないと一瞬でガス欠起こします・・・・

エントリーの位置をギリギリのところに指値置いて、建値にすぐカット設置して、ある程度伸びたら最低利益確保する。明らか伸びそうなら握る。

細かい利益だいぶ握りつぶした実感はあるけど、下記のような感じの成績で安定させやすい。（ちょっと前からこのやり方で大体4～5割、似たようなPFで推移、特大の負のエッジ除く（損切位置ずらして飛ばした奴・・ｗ））

って特大の負のエッジが大きなロスカットタイプにはいい感じなのかなとおもったり。

ナンヤネンモーは置いといて、細かく損切しまくってもこういうので一気に抜けるから細かい損切と利益握り潰しのストレスにさえ耐えられれば、逆張り系や損切幅大きくする系より運用はしやすそう。NQに関しては。いまんところ。

これはあまり経験のないことだから、これから慣れていくんだろう・・・
とりあえず特大の負のエッジが払拭されてきた感。

今日は握らず適宜利確しとけばよかったなぁ～・・・

しょっぺぇだけでやらないってわけじゃないんだけども、しょっぺぇ中でエントリーしてるのかそうでないのかをはっきり認識してる事はメンタル的に重要かなぁ・・

なんかそういうのフワッとしたままやってるといつの間にか自分だけ盛り上がっちゃってガツガツいってしまうから・・・ｗ

しょっぺぇから裏切られまくってもまぁそうよなｗって自然に思える。

ナンヤネンモーは急な動き、急な階段なだけで凹んだところにうまく嵌められれば低リスクハイリターン（方向性はあってるのに細かい損切連発で精神的リスクは高い）な感じ。

トレードに限らず、楽しみとか未知への期待をベースに行ってきた数々の取り組みってのは上手くいったことねぇんだよな。俺は。

途中で飽きるか、下手の横好きみたいな感じで。

逆に楽しくもないけど続けてる事はトップクラスに成果出てるものはある。

学習と楽しみをベースに期待値を積むという行いが適切に行えるのがトレードのセンスなんだろうなあと思う。

そういう事が自然にできるセンスのいい人の真似しようとすると延々となぜかうまくいかない感じになるのかなと思ったりする。

しょうもないお絵描きなんだけど、動きの特徴とかその他モロモロ考慮してみると結構機能すんだよね。（逆になんでそんなに機能すんの？って思ってるくらい）