コード、涙、そしてAlgo Forge
27
14
内容
まずは、少し興味深い話から
純粋な感情のまま書くべきなのか。それとも、実用性を重視すべきなのか。くしゃくしゃに丸めた下書きの山。そして、最後には不要だと判断して捨てられた言葉たち。そんなものに囲まれながら、私は長い間、書き始めることができませんでした。いや、正確には「書くこと」ではありません。自分にとって、ほとんど未知だったものについて説明しようとしていたのです。何度試しても、何かがおかしく思え、どうもしっくりきませんでした。そして何より、自分の言葉になっていませんでした。そこで今、私はただありのままに話してみることにしました。これは、単なる説明ではありません。私自身の印象についての話です。個人的な部分もありますし、そうではない部分もあります。これは、慣れた方法から、必要な方法へ移行する道のりについての、感情的な物語になるでしょう。単純なアーカイブ管理から、まだ馴染みのないリポジトリ管理へ移行する過程についてです。ここで、すぐにこんな疑問が浮かぶかもしれません。「なぜですか？」そうです。なぜ、長い間慣れ親しんできた単純な快適さから離れて、複雑で理解しにくいものへ移行する必要があるのでしょうか？そこにはどんな意味があるのでしょうか？どんな利益があるのでしょうか？
一般的なプログラマーや記事の著者にとって、今後3世紀は必要になることもないと思えるようなものを調べ、学ぶ意味とは何なのでしょうか？すべては、とても簡単です。コードを書きます。記事を書きます。ソースコードをアーカイブにまとめて添付します。そして公開します。それで終わりです。次の作業へ進むことができます。
しかし、実際にはそうではありません。本当のところ、これは後回しにするのではなく、今取り組むべきことなのです。ただ、そのためにはこれまでの習慣を変える必要があります。殻の外に出て、見てみる必要があります。すると、慣れ親しんだ「コードを書く → 記事を書く → アーカイブする → 忘れる」という繰り返しの日々よりも、はるかに生活を楽にしてくれるものが存在することが分かります。
ZIP管理では限界があると気付いた時
長い間、すべてはこのように続いていました。まあ、便利ですよね？すべては決められた流れ通りに進みます。コードを書き、記事を公開し、知識を共有する。それでいいはずでした。しかし、公開する記事が増えれば増えるほど、そして私自身の歩みの始まりから時間が経てば経つほど、過去のコードや公開物による問題が、より頻繁に、より大量に現れるようになりました。
たとえば、21番目の記事を書いている途中で、ライブラリの最初の部分にバグを見つけたとします。すると、そのバグを修正し、最初の記事から最後の記事まで、すべてのファイルをもう一度アーカイブにまとめ直し、それぞれについて再公開を依頼しなければなりません。あるいは突然、読者から「記事に添付されているコードをインストールできません」とか「リリースごとの変更点について質問があります」などの問い合わせがあります。どのアーカイブに何が入っているのか、そこで何を変更したのか、何がまだ変更できていないのかなどはもう覚えていないのに、読者に返答し、自分の開発したものをサポートしなければなりません。そうして、検索が始まります。言い換えれば、自分自身の記事から、自分自身のソースファイルをダウンロードする作業です。しかも、変更点を探すために、2つの異なるバージョンを比較しなければならないこともあります。
この頃から私は、自分で公開したものに縛られているような感覚を覚えるようになりました。そして次第に、MQL5 Algo Forgeが、私の開発物や公開物を維持する際に発生していたさまざまな問題への解決策になるのではないか、と考えるようになりました。
最大の壁：私がGitをまったく知らなかったこと
ここでジレンマがあります。プロジェクトを書かなければならない。記事も書かなければならない。やることリストも片付けなければならない。そして、その後でGitを学ばなければなりません。もちろん、Gitに出会ったことがないわけではありません。しかし、それはほんの一瞬触れただけで、表面的な理解に過ぎませんでした。以前、Elite DangerousのWaip Squadron (Wild Priest Corps)のためにC#アプリケーションを書いていた時、私はプロジェクトを手伝ってくれる助っ人を一人、チームに招きました。彼はプログラマーで、すでにこうした仕組みを理解していたので、私は、変更をプッシュし、作業を始める前に変更を受け取るだけでした。しかも、それは彼がそう指示した時だけです。そして、もし何かが壊れた場合（もちろん、壊したのは私ですが）、彼がすべて直してくれました。だから、自分一人でプロジェクトを扱っている今。突然、何かを壊してしまうかもしれないと思うのです。そうしたら、どうするのでしょうか？もし、たった一度の不注意な操作で、すべてを消してしまったら？もちろん、こうした不安のせいで始めることができませんでした。
しかし、開発者たちは、すでにエディタ内にAlgo Forgeとの連携機能を組み込んでいました。まだ完全なものではありませんでしたが、少なくとも、Gitのコンソールコマンドのヘルプを目の前に開いたままにして、必要になった時に何を入力すべきかを覚えておく必要はありませんでした。まあ、私はキーボード操作の速さや、朝起きた瞬間から使わなければならない、覚えにくくて理解することさえ難しいコマンドを暗記していることを自慢するようなタイプではありません。エディタには、基本的で必要な操作のためのコマンドが、すでに右クリックメニューの中に組み込まれています。
そこで私は、「いつかは始めなければならないのだから」と思い、少しずつ始めてみることにしました。
最初のプロジェクト移行：簡単なはずなのに迷ったわけ
さて、「言うが早いか」ということで、私は始めることにしました。幸いなことに、私にはすでに数多くの記事が公開されており、それ以上に多くのソースファイルがありました。対象となるプロジェクトには困りませんでした。そこで、いくつかの疑問が次々と浮かんできました。幸い、仕組みを理解すること自体は難しくなかったので、それぞれのプロジェクトにどの種類を選択すべきかについては、あまり悩む必要はありませんでした。単独のスクリプトならプロジェクトも同じようにスクリプトにする、インジケータならインジケータにする、などです。1つのプロジェクト内に多くのファイルが含まれている場合は、空のプロジェクトを作成し、実験用プロジェクトにあるすべてのローカルファイルを、その新しい公開用プロジェクトへコピーする方が良いでしょう。
しかし、すぐに疑問も出てきました。なぜこのようにしなければならないのでしょうか？なぜ、まず空のプロジェクトを作成して、その後で必要なファイルを移動する方法ではいけないのでしょうか？その中の1つを、必要なプログラム種類としてコンパイルできる状態にしておけばよいのではないでしょうか？試してみて、これは結局、作業スタイルの違いなのだと理解しました。私たち自身にとって、あまりにも慣れ親しみ、身近になった快適さの問題なのです。ですから、私は自分の中で、新しく公開用プロジェクトを作成する場合で、それが実行可能なプログラムなら、必要なプロジェクトタイプを選択すると決めました。しかし、すでに昔から存在しているコードを移行する場合は、空のプロジェクトを作成して、そこへ必要なファイルを入れていく方が便利です。また、1つのプロジェクト内に複数のコンパイル可能なプログラムが含まれる、あるいは将来的に含める予定がある場合も、空のプロジェクトにまとめます。
「よし、これで行こう」そう決めました。そして実行しました。（すでにAlgo Forgeの達人になったような気分で）右クリックメニューから意気揚々とプロジェクトへファイルを追加しました。そしてWeb版へ移動すると、新しいプロジェクトに追加したすべてのファイルが表示されていました。やった！と思った次の瞬間、私は疑問に思いました。なぜファイルがここに表示されているのでしょう？ローカルリポジトリへファイルを追加しただけのはずです。魔法の「Push」はまだ押していません。一体どういうことなのでしょう？しかし、その時、コミットのコメント欄に「新しいファイルの追加」と表示されていることに気付きました。
なるほど。もしかすると、（私のような人間が、あまり長く苦しまなくて済むように）開発者たちはこのように作ってくれたのかもしれません。実際、追加したばかりのファイルはすべてWeb版で見ることができます。完全に読み取れます。全体として、すべてが正しい場所にあります。そして、ファイルにはデフォルトのコミットコメントまで付いています。素晴らしいです。
でも、私はそこに自分自身のコメントを追加したかったので、それではダメでした。自分のコメントを残したかったのです。そこで、私がしたことは一番簡単な方法でした。もう2026年なのに、ファイルにはずっと昔の年が表示されていました。そこで私は、エディタで各ファイルを開き、現在の年を書き込み、保存しました。すると、ファイルの横に、ファイルが変更されたことを示すアイコン（
）が表示されました。しかし、Web版を見ると、そこにあるファイルは以前と同じままでした。
そこでエディタへ戻り、Gitの変更をコミットしました（右クリックメニューのGit Commit）。やった、再び成功です。エディタ上のファイルアイコンは通常の色に戻りました（
）。つまり、Web版と同じ状態になったということです。そこで確認してみると、その通りでした。すべてがきれいに変更されていて、「2026」が私のことを見ていました。
そして私は、Git、そしてそれに対応するAlgo Forgeの魔法のような性質を思い出しました。プロジェクトファイルに加えられた変更履歴を記憶し、表示できるということです。ライブラリの異なるバージョンで何を変更したのかについて、何度も質問されたことを考えると、これは画期的です。これからは、「Shared Projects」フォルダでプロジェクトを開発し、変更をコミットし、Webサイト上ですべての履歴を見ることができます。履歴を確認してみることにしましたが、そこで「これはバイナリファイルです。表示できません」と言われました。まさかと思いました。では、私は何を壊したのでしょうか？ファイル自体は普通のテキストとして表示されています。文字も見ることができます。しかし、変更内容は表示されません。そして、依然として「バイナリファイル」と表示されています。思わず額に手を当てました。
もちろん、この話の結末は大丈夫でした。すべて解決しました。ただし、それは「先輩たち」の助けを借りてのことでした。そして、この経験は永遠に記憶に刻まれました。では、秘密は何だったのでしょうか？それは、Algo Forgeの現在の仕様にありました。現在のAlgo Forgeは、UTF-8で保存されたファイルだけを正しく扱います。しかし、エディタでは、ファイルはデフォルトでUnicode形式で保存されます。そして、ここは非常に重要な点です。公開プロジェクトを扱う場合、新規プロジェクトであっても、過去のコードから組み立てたプロジェクトであっても、リポジトリへ送る前に、必ずすべてのプロジェクトファイルをUTF-8で再保存する必要があります。そうすれば、変更履歴が表示されるようになります。
変更履歴を確認できるようになったことで、突然、さらに多くの疑問が出てきたことに気付きました。変更内容は見えるようになったのですが、何週間、何か月もの時間と、多くの修正や改善を重ねて作られた大きなライブラリの場合はどうでしょうか？そのようなライブラリでは、それぞれのバージョンが対応する記事で説明されています。そして、それらの記事は大量に積み重なっています。これらすべてを、リポジトリを見る人に分かりやすく、ライブラリがどのように発展してきたのか分かる形で表示するには、どうすればよいのでしょうか？
もしライブラリの最終版だけを公開プロジェクトへアップロードした場合、その履歴はいったいどこから来るのでしょうか？履歴は私のコンピューターにあります。そして、別々のオンライン記事にもです。論理的に考えれば分かります。最初のバージョンから最後のバージョンまで、順番にプロジェクトへアップロードする必要があるのです。そして、それぞれの新しい記事（つまり、ライブラリの新しいバージョン）、より正確には、その記事に添付されたアーカイブ内のライブラリファイルを、リポジトリへコミットする必要があります。そうすれば、完全な変更履歴ではないとしても、少なくともリリースの履歴をクラウド上に残すことができます。OKです。では、これらの各段階を「リリース」として記録する方法があればどうでしょう？それは本当に素晴らしいことになるでしょう。ライブラリのリリース履歴です。さらに、それぞれの記事は、対応するライブラリのリリースを参照できます。そこで私は、ドキュメントを読み、インターフェースを調べ始めました。そして（奇跡です！）Web版Algo Forgeで[Releases]タブを見つけました。そこには、現在の状態からリリースを作成する機能がありました。
3回目の成功です。しかも、作成する際には、そのリリースを例えば安定版としてマークすることも、ベータ版としてマークすることもできます。これは素晴らしい機能です。
そこで私は、同じライブラリに関係するすべての記事を集め、コードを1つずつ公開プロジェクトへ送ることにしました（もちろん、そのたびに忘れずに各ファイルをUTF-8で再保存しました）。そしてリポジトリでは、次の記事に対応するファイルを追加するたびにコミットし、その後リリースを作成し、安定版としてマークしました。すべての作業が完了した時、私は8つのリリースを持つ、そのライブラリ専用のリポジトリを手に入れていました。そして、それぞれのリリースへのリンクを提供できるのです。そのリンクを開けば、そのリリースに属するファイル一式へ直接アクセスできます。
これ以上ないほど嬉しい結果でした。
しかし、プロジェクトをゼロから作成する必要がある場合は、もちろん「Shared Projects」フォルダ内のプロジェクトから始める必要があります。そして、すべてのコミットは、その瞬間からプロジェクトの変更履歴に含まれます。コミットされたすべての変更は、プロジェクト開発の履歴の一部となり、表示されます。プロジェクトを世の中へ公開できる状態になったと判断したら、リリースを作成します。こうして、どのプロジェクトも少しずつ自分自身の歴史と、連続したリリースを持つようになります。
一番難しかったのは、コードではなく規律でした
そして、分かったことがあります。Gitで変更をコミットするとき、送信ウィンドウにはコメント欄があります。そこには当然、変更の理由を書く必要があります。あるいは、コードのどこを変更したのか説明する必要があります。ソースコードには、ほとんど隅々まで詳細なコメントを書く習慣がある私でさえ、コメント欄に変更内容を書くことには、かなりの抵抗がありました。コメントの中のカンマを1つ変更しただけなのに、なぜ書く必要があるのでしょう？誰のために？何のために？面倒です。なんでわざわざ？そう思いました。そして、コメント欄を空のままにしました。その方が速いからです。そして後になって、特定の変更を探す必要が出てきた時、私は空白のコミット一覧を目にしました。さて、探してください。どうぞ、頑張って探してくださいといった感じです。そこで理解しました。「誰のために」「なぜ」「何のために」といったすべての疑問には、明確な答えがあります。自分自身のため。後でわからなくならないように自分の作業を整理しておくため。そしてもちろん、未来の読者のためです。これは、自分自身と将来このコードに関わる人への配慮でもあります。
これは規律です。まず、自分自身のための規律です。そして…私はREADME.mdを見ました。そこで気付いたのです。コミットにコメントを書くことなど、まったく問題ではないのです。変更したなら、コミットを送る。そして、何をコミットしたのか説明する。それだけです。READMEは、プロジェクトのデータシートです。プロジェクトの「顔」です。プロジェクトページを訪れたすべての人が、それが何なのかすぐに理解できるようにするために、プロジェクト全体について説明するのです。これが表紙です。その表紙をどのように作るかによって、受け取る印象が決まります。もし空白のままにしておけば、外から見た人には、単なるファイルの集まり、目的の分からないコードの置き場所に見えるでしょう。もちろんMarkdownの記法についても学ぶ必要がありましたが、この時点ですでに、その理由は理解していました。プロジェクトの表紙をきれいに整えるためです。これもまた、読者への敬意なのです。誰かが訪れ、整えられたプロジェクトを見て、何についてのものなのかを確認する。そして最も重要なこととして、すぐに理解する。
そして私にとっては…私にとってREADMEは、新しいことを学び、探求するためのもう一つの理由になりました。その通り。すべてを整えるためにはAlgo Forge のWeb版へ行く必要がありますが、もうそれは問題ではありません。プロジェクトを始める時、私は必ず説明を書くことから始めます。大きな変更を加えるたびに、READMEにメモを残します。最終的なプロジェクトページには反映されないメモだったとしても、自分にとっては素晴らしいノートになります。そしてREADMEを読むためだけにWeb版へ行く必要もありません。エディタ内でも完全に読むことができます。プロジェクトのGitからこのファイルの変更を取得すれば、エディタのウィンドウで開いて、自分のメモを読むことができます。プロジェクトが完成したら、Web版へ行き、プロジェクトの表紙を作成します。そうすれば、利用する人がその目的を簡単に理解できるようになります。
途中で投げ出さずに済んだ理由
Gitを一通り勉強し、いろいろ試してはやり直し、最初からやり直して……。もちろん、あっという間に嫌になりました。ちょうど「これでもう分かった。あとはこの新しいやり方で作業を続けていけばいい」と思った頃になると、不思議なことに、また何かしら問題が起きるのです。そのたびに調べて、読んで、また試してみる。そんなことの繰り返しでした。そうこうしているうちに、私は一つのことに気付きました。このまま全部を一度に覚えようとしていたら、そのうち頭が破裂してしまう。だったら、まずは本当に必要なことだけに絞ればいい。そう考えるようになったのです。自分のプロジェクトを進めるうえで必要なのは、もう十分理解できていて、きちんと動いてくれることだけです。それ以外のことは、必要になったときに少しずつ覚えていけばいい。それで十分だと分かりました。私にとって大事だったのは、プロジェクトは必ず「Shared Projects」フォルダから始めること。プロジェクトには用途に合った種類を選ぶか、あるいは空のプロジェクトを作ること。空のプロジェクトなら、自分の好きなように構成できますし、それでも開発履歴や編集履歴はきちんと残ります。
そして、もう一つ。これだけは習慣にしてしまおう、と決めました。毎日作業を始める前には、まずGitから最新の変更を取得することです。コミットするときには、「何を変更したのか」があとから見ても分かるように、一言でもいいのでコメントを書いておくこと。そうしておけば、時間が経ってから見返しても、「このコミットは何だったかな」と悩まずに済みます。そんなことを続けているうちに、気付けば私は、以前とは少し違う感覚でプロジェクトを作るようになっていました。コードは分かりやすく整理され、変更履歴も残っています。途中の節目となるリリースも、正式なリリースもあります。方向性を決めれば、あとは自然と進むべき道が見えてきました。目標があります。進む道があります。そして、その先へ進むための方法も、ちゃんとあります。
実際に移行しようとすると、どのような変化があるのか
まず最初に言っておきます。「切り替えた瞬間にすべてが変わって、一気に快適になる」そんな期待はしないでください。そんなことはありません。長い間、普通のフォルダとZIPアーカイブだけで管理してきた人なら、新しいプロジェクトの中で同じことを何度もやり直すことになると思います。試行錯誤を繰り返しながら、「こんなことをする意味、本当にあるんだろうか？」「作業が速くなるどころか、問題ばかり増えて時間を取られているじゃないか」そんなふうに思う瞬間も、きっとあるはずです。少しずつですが、やがて、作業が最初のうちはなかなか進まないのは、新しい仕組みのせいではなく、長年染みついた習慣を変えようとしているからなのだと気付くようになります。そしてその先には、公開したプロジェクトが、公開した瞬間から古くなり始めることは、もうなくなるということにも気付くでしょう。
これからは、プロジェクトそのものが独自に成長し続け、公開した記事にもその変化が反映されます。プロジェクトに加えた変更は、そのまま記事にも反映されるのです。コードを更新したことを読者へ知らせるために、「記事が再公開されるまで待ってください」「古いアーカイブはダウンロードしないでください」と案内する必要は、もうありません。すべて自動で処理されます。アーカイブではなくリポジトリへ移行し、これまでの習慣を乗り越えることで、プロジェクトや記事の保守作業そのものを自動化できるようになるのです。
こうして初めて、本当に必要としていた整理された開発環境が得られます。そして、そのときになって初めて、Algo Forgeが持つ本当の価値がはっきりと見えてくるのです。
すぐには思いつかなかった結論
ここまで読むと、問題解決の話が、宣伝のように聞こえてしまうかもしれません。しかし、それは私自身が、静的なアーカイブよりもリポジトリの方がはるかに優れていることを実感するようになったからです。かつては、古いプロジェクトに縛られ、それらの保守に追われながら前へ進めずにいた頃のことを、今では思い出すことさえ難しくなっています。今では、その面倒な作業はリポジトリが引き受けてくれるのです。
Algo Forgeの本質は、リポジトリ、同期、バージョン管理、そしてドキュメント管理にあります。私にとって、それは「昔作ったアーカイブが永遠に使い続けられる」と期待してはいけないということでもあります。つまり、「公開したら終わり」という考え方は、プロジェクトを継続的に保守しなければならないという現実とは相容れません。その負担は結局、作者自身が背負うことになり、本来取り組むべき重要な作業の妨げになってしまいます。しかし、Algo Forgeを使うようになってからは、公開したプロジェクトはきちんと整理され、変更履歴も完全に可視化されました。そして、「いつになったら、この散らかり放題のフォルダやファイルを整理できるのだろう」という悩みも、もうなくなりました。その問題は、すでに解決されているのです。
もしも今、以前の公開方法へ戻りたいかと聞かれたら、私は迷わず「いいえ」と答えます。新しい公開方法と保守方法のメリットを知ってしまった以上、もう元には戻れません。もちろん、アーカイブが悪いものだとか、存在価値がないと言いたいわけではありません。アーカイブは、公開するその瞬間においては確かに便利です。しかし、その後は記事とともに古くなり、保守には手間と不安がつきまといます。一方で、Algo Forgeは公開時に多少の時間と労力を必要とします。しかし、その投資はすぐに報われます。保守は容易になり、履歴は透明になり、サポートにも安心して対応できるようになります。これは非常に重要なことです。これから先に開発するプロジェクトは、古いアーカイブの中で眠り続けるのではなく、本来あるべき姿として、自ら成長し続けるプロジェクトになっていくのです。
実践ガイド：実際の使い方
Algo Forgeでのすべての作業は、すぐに習慣化できる3つのシンプルなルールに基づいています。まず、「Shared Projects」フォルダで基盤を整えます。ここからクラウドへの直接アクセスが開始されるためです。次に、「最初の一歩」のルールを身につけます。コード作業を始める前に、必ずリポジトリから最新バージョンを取得します。そのためには「Get updates from Git」コマンドを使用します。特に複数のコンピューターを使って作業する場合、この手順は非常に重要です。最後に、作業内容をコミットします。「Commit changes to Git」をクリックするだけで十分です。編集内容はコミットされ、クラウドにも反映されます。
開発者たちは、このプロセスを可能な限り簡単にしました。ローカルでのコミットとクラウドへのコード送信を、1つの操作にまとめています。このシンプルな流れを守ることで、バージョンの混乱から完全に解放され、プロジェクトは常に整理された状態で、必要なときすぐに利用できるようになります。
では、実際にはどのように見えるのかを確認してみましょう。Algo Forgeへコードを統合するプロセスは、2つのシンプルな道筋に分けられます。1つは、以前作成したコードに新しい命を吹き込む場合。もう1つは、最初から正しいルールに従って新しいプロジェクトを開始する場合です。
以前公開した記事からコードを移行する
このような状況を想像してください。新しいプロジェクトに落ち着いて取り組んでいると突然、通知が届きます。2年前に公開した記事に、誰かがコメントを残したのです。「コードがコンパイルできません」「新しいターミナルビルドでエラーが発生します」といった内容です。そして、あなたはその古いソースファイルをハードディスクのどこに保存したか探し始めることになります。さらに悪い場合には、記事から自分自身のコードを再度ダウンロードし、解凍し、質問に答えるために「どうやって組み立てたのか」を思い出そうとする必要があります。
このような問題を防ぐ最良の方法が、これらの資料をリポジトリへ移行することです。過去の作業内容をアクセスしやすく整理された状態にしておきましょう。しかも、その作業自体はメールを確認する時間とほとんど変わりません。いくつかの簡単な手順に従うだけで、コードが最新の、使いやすく、そして何よりも完全に管理可能なプロジェクトへと変わります。
- プロジェクトの作成
まず、エディタ設定の[Community]タブで、mql5.comアカウントのログイン情報（ユーザー名とパスワード）が設定されていることを確認してください。
MetaEditorのナビゲーターで、必ず「Shared Projects」フォルダを右クリックし、[新しいプロジェクト]を選択します。ここが、最新の開発環境への入口になります。
- 設定の選択
ここでは、古いアーカイブの構成によって選択が変わります。複数の異なるファイルが含まれている場合は、[空]を選択してください。一方で、プロジェクトが単一のコンパイル済みエキスパートアドバイザー(EA)やインジケータだけで構成されている場合は、MQLウィザードで対応する種類を直接選択する方が適しています。この場合、エディタが正しいプロジェクト構造を自動的に作成します。その中へ必要なプロジェクトファイルをコピーするだけで済みます。もちろん、空のプロジェクトを使用する場合でも、必要なファイルをすべて配置する必要があります。
- クラウドへの接続
プロジェクト名は、[Material Type]-[ID]-[Short Subject]の形式で設定します。
ここでいうIDとは、記事URLに含まれる記事番号を意味します。たとえば、https://www.mql5.com/ja/articles/12900の場合、IDは12900です。
最終的な名前は、Article-12900-MQL5-Structs-Printのようになります。
ウィザード画面の下部に表示される、「このプロジェクトはAlgo Forge上でホストされます」という通知によって、クラウド形式のプロジェクトであることを確認できます。 - ファイルの移行
任意のファイルマネージャーを使用して、プロジェクトのすべてのソースコードファイルを、新しく作成したフォルダへコピーします。MetaEditorでは、リポジトリに含めたい各ファイルについて、「Add file/folder to Git」コマンドを選択します。プロジェクト内のすべてのファイルをまとめて管理したい場合は、フォルダ自体を追加することもできます。
- コミット
[Commit changes to Git]をクリックするだけです。これで完了です。以前の作業内容はモダンなリポジトリ環境へ移行され、これからははるかに簡単に整理・管理できるようになります。
新しい記事のためのプロジェクト開発
新しい記事を書く予定があるなら、最初から正しい基盤の上で始めましょう。公開の直前まで待つ必要はありません。最初から「Shared Projects」ディレクトリ内に直接プロジェクトを作成してください。適切なテンプレートを選択すると（多くの依存関係を持つ複雑なエキスパートアドバイザーであっても、単純なスクリプトやインジケーターであっても）、MetaEditorは自動的に正しいプロジェクト構造を構築します。
ここで、1つ技術的な特徴を理解しておく必要があります。Projectsウィンドウ内のフォルダ構造は仮想的なものです。実際のディスク上では、すべてのソースファイルが1つのフォルダに保存されている場合でも、MetaEditorのインターフェースでは論理的な区分に整理して表示されます。プログラムファイルはSourcesフォルダに、ヘッダーファイルはHeadersフォルダに、リソースファイルはResourcesフォルダに表示されます。
これは、作業を便利にするための仕組みです。実際のディレクトリを探し回ることなく、ファイルの種類や役割ごとに必要なものをすぐに見つけられるようになっています。
この方法でコードを書き始めた最初の1行目から、プロフェッショナルな開発スタイルが自然と身につきます。作業の流れは、意味のある一連のステップになります。論理的なブロックを書き、確認し、その後すぐに[Commit changes to Git]を選択してリポジトリへ送信します。重要な変更を行った場合は、コミットコメントに内容を記録することをおすすめします。そうすれば、後からファイルの変更履歴を確認するときに、このバージョンで何を変更したのかを思い出す必要がありません。
管理範囲は自分で自由に決められます。プロジェクト全体の変更をまとめて記録することもできますし、各ファイルごとに個別にコミットすることもできます。この柔軟性によって、突然新しいアイデアがうまくいかなかった場合でも、いつでも以前のバージョンへ戻ることができます。
そして記事を書き終える頃には、プロジェクトは完全にクラウドと同期された状態になっています。しかも、プロジェクトは非公開のまま維持されます。公開するタイミングはあなた次第です。Algo ForgeのWeb版へログインし、1つの切り替え操作で公開アクセスを有効にするだけです。必要なタイミングですべての人に公開できます。
プロジェクトの顔：ドキュメント作成の技術
技術的な部分はこれで終わりです。コードはデバッグされ、ファイルは同期され、Algo Forge内のフォルダにもきちんと整理されています。しかし、この状態でリポジトリを開いてみると、そこに見えるのは単なるファイル一覧だけです。外部から見ると、そのプロジェクトはまだ「自己完結した何か」にすぎません。表紙もありません。タイトルもありません。説明もありません。あなたの作品が本当の意味で読者に「語りかける」ためには、顔が必要です。その役割を果たすのが、プロジェクトのルートディレクトリに配置される README.mdファイルです。このファイルこそが、単なるファイルの集合体を、整理された知識ベースへ変える接続点になります。
READMEファイルは、基本的にAlgo ForgeのWebページ表示エンジンに対するマニュアルのようなものです。プロジェクトをブラウザで開いたときに、閲覧者が見るページの構成を決定するのがこのファイルです。これは名刺のような存在であり、目の前で静かなソースファイルの集合を、明確で生きたソフトウェア製品へと変化させます。説明がしっかり書かれたプロジェクトの方が、単なるファイル一覧だけのプロジェクトよりも、はるかに信頼感を与えることは言うまでもありません。
しかし、ゼロからドキュメントを書くために貴重な時間を使う必要はありません。もっと効果的な方法があります。現代のツールを活用しましょう。今日、AIはこの作業における最高のアシスタントです。面倒な作業は積極的にAIへ任せてください。コードと記事の下書きをニューラルネットワークへ渡し、Markdown形式のREADMEファイル構成を作成するよう依頼するだけです。覚えておいてください。AIはすぐにコードの特徴を分析し、主要なパラメータを整理し、論理的なセクション構成を提案してくれます。完成した「骨組み」は、あなた自身のスタイルに合わせて少し調整するだけで使用できます。覚えておいてください。AIはあなたの創造性を置き換えるものではありません。AIは、面倒なマークアップ作業を引き受け、本当に重要な作業に集中するための時間を生み出してくれる強力な加速装置なのです。
構文と制御文字
ニューラルネットワークによってREADMEファイルのテンプレートが作成されたら、次はそれを完成されたショーケースへと仕上げる必要があります。単に機能一覧を並べるだけではなく、あなたのコードがどのような価値を持つのかを明確に伝えられるドキュメントにすることが重要です。
ファイルを完成させるために必要なのは、Markdownマークアップ言語の基本を理解することだけです。Markdownを使えば、複雑なレイアウト技術を学ぶ必要はありません。シンプルな記号による指定だけで、テキストを美しく整形できます。自信を持ってデザインを行うためには、いくつかの基本ルールを覚えておけば十分です。
プロジェクトをプロフェッショナルな見た目にするために必要なのは、Markdownの基本を習得することだけです。これはプログラミング言語ではありません。むしろ、Algo Forgeがすぐに美しいレイアウトへ変換してくれる、シンプルなテキスト用コマンドの集合です。
それでは、主なデザインツールとなる制御文字を見ていきましょう。
- 見出し階層(#)
行の先頭に置くシャープ記号(#):の数によって、セクションのレベルが決まります。
1つの#は最も大きな見出しを作成します。通常、これはプロジェクト名に使用します。2つの##、または3つの###を使うことで、論理的なサブセクションを整理できます。 - リスト（-または*）
行の先頭にハイフン（-）またはアスタリスク（*）を置くと、自動的に整理されたリストが作成されます。各項目はグラフィカルな箇条書きとして表示されます。
これは、プログラムの特徴や入力パラメータを説明するときに最適な方法です。 - テキストの強調（**、*）：
記号をペアで使うことで、特定の部分を強調できます。2つのアスタリスクで囲む(**text**)と太字になります。1つのアスタリスクで囲む(*text*)と斜体になります。 - コードスニペット(`)：
文章中に登場する関数名や変数名は、バッククォートで囲む必要があります（例： `OnInit`）。このように記述すると、技術的な用語が通常の文章から視覚的に区別されます。 - コードブロック(```cpp)
完全なコードリストを挿入する場合は、3つのバッククォートを使用します。開始時のバッククォートの直後にcppという識別子を指定すると、構文ハイライトが有効になります。これにより、C++、そしてそれに対応するMQL5プロジェクトの構造が正しく表示されます。 - リンクと画像([]())
「[Text](Address)」の形式は、通常のクリック可能なリンクを作成します。
ただし、その前に感嘆符!を追加すると、レイアウトエンジンに、リンク先へ移動するのではなく、その場で画像として表示するよう指定することになります。
つまり、ブラウザは指定された場所からファイルを取得し、画像として文章内に表示します。
角括弧内には短い説明（altテキスト）を書き、丸括弧内には画像ファイルへの直接パスを書きます。
この「記号による言語」によって、通常の文章は視覚的なショーケースへと変わります。取引パネルのスクリーンショットや、ストラテジーテスターのチャート画像を数枚追加するだけで、不要な説明を増やすことなく、プロジェクトはより生き生きと分かりやすくなります。README作成にわずか10分を費やすだけで、単なるファイル集合を、注目を集める高品質な製品へ変えることができます。これこそがプロフェッショナルなアプローチです。作者がアルゴリズムのロジックだけでなく、それを学ぶ人や利用する人にも配慮しているということなのです。
そして、ここで重要な点が1つあります。MetaEditorはREADME.mdを正しく読み込み、表示することはできます。しかし、編集用のツールとして設計されているわけではありません。そのため、READMEを書く際にはAlgo ForgeのWeb版を利用します。
そこで、便利なオンラインエディタを使い、AIが作成したテンプレートを貼り付け、文章を編集し、ショーケースの見た目を整えます。
Webサイト上で [Save Edits]をクリックすると、作業内容は消えることなくプロジェクトの一部になります。その後、MetaEditorへ戻り、いつもの[Get updates from Git]ボタンをクリックするだけで、新しく整えられた説明文がクラウドからエディタへ直接反映されます。
推奨されるドキュメント構成
リポジトリのデザインには、基本となる普遍的な構成を採用することをおすすめします。論理的な構成では、通常、まずプロジェクトの簡単な概要を示し、次に主要な機能一覧を掲載します。その後、ファイル構成全体を説明し、最後に各ファイルをどのような手順で実行すべきかを順番に示します。ドキュメントの最後には、理論的な基礎資料へのリンクや、フィードバックを受け付けるための連絡先を含む参考情報セクションを配置します。この構造にすることで、プロジェクトは読者にとって透明性のあるものになり、作者にとっても完全な作品として整理されます。
以下は、独自のプロジェクトに利用できる一般的なREADME.mdファイルの例です。
#Project or library name Brief summary: Description of the problem being solved, its key purpose, and its suitable applications (one or two sentences). ##Key Features - Listing key features or modules. - Describing unique characteristics, such as performance or cross-platform development. ##Project Composition Overview of the repository structure: What tasks are the main directories or files responsible for? ## Usage sample Below is a basic sample of how to call the main function from this library: ```cpp #include <MyLibrary.mqh> void OnStart() { double result = MyFunction(10.5, 20.0); Print("Computing result: ", result); } ``` Use the code carefully. ##Instructions for use - Procedure for integrating into other projects. - Necessary dependencies and external resources. - Basic steps for compilation and first run. ##Reference information - Links to theoretical materials or to the main article on the portal. - Contacts for feedback or links to the community discussions.
READMEは、単なる形式的な作業であり、「見せるためだけに適当に埋めればよいもの」と考えられがちです。しかし実際には、どれほど優れたコードであっても、数分で内容を理解できなければ、棚の奥でほこりをかぶる可能性があります。よく設計されたREADMEファイルは、単なる文章ではありません。それはあなた自身の署名であり、品質の証明であり、そしてあなたのコードを学ぶ人々に対する最低限の敬意でもあります。このようなショーケースによって、プロジェクトは単なるファイルの集合から、時間が経っても価値を持ち続ける生きたツールへと変わります。記事を公開してから1年後、2年後、あるいはそれ以上の時間が経過した後でも、あなたの評価を積み重ね続ける存在になるのです。
結論：新しい開発文化へ
Algo Forgeへの移行は、単にファイルの保存方法を変更することではありません。それは、プロフェッショナルな活動における新しい標準へ移行することです。私たちは、固定されたZIPアーカイブや、長い時間を必要とする再公開作業から離れ、今この瞬間にも完全に管理できる、常に最新状態を保つ生きたプロジェクトへ進んでいます。
作者であるあなたにとって、これは何よりもまず、時間の節約と整理された作業環境を意味します。もうドライブの中から古いアーカイブを探し出す必要はありません。読者に対して、プロジェクトを手動で組み立てる方法を何度も説明する必要もありません。これからは、あなたの作品はクラウド上で管理され、修正が必要になった場合でも、MetaEditorから1つのコマンドを実行するだけで、すぐにリポジトリへ反映できます。不要なメールのやり取りもありません。モデレーションを待つ必要もありません。記事本文そのものを修正する必要もありません。
このようなツールを開発ワークフローへ取り入れることは、単に流行に合わせることではありません。記事制作をより予測可能で、より高品質なものにするための方法です。最終的に、作者がコードの見せ方に対して最新のアプローチを選択すると、その影響はリソース全体の品質向上にもつながります。これは、テクノロジーが本当に重要な部分へ集中することを助けてくれる良い例です。そして、それぞれの記事を、コミュニティ全体にとって長く利用できる、完全な実用ツールへと変えていくのです。
エコシステムの機能をさらに深く理解したい方は、以下の参考セクションをご覧ください。
- MQL5 Algo Forgeのご紹介 - クイックスタートのための基本ガイド
- 連載「MQL5 Algo Forgeへの移行」：
理論を実践へ移すために、私は実際に移行作業がどれほどスムーズに進むのかを自分自身で確認することにしました。そこで、いくつかのプロジェクトをリポジトリへ移動してみました。その結果、すべてがこの記事で説明した通りに動作することが分かりました。高速で、論理的で、そして不要な手間はありませんでした。
実際に最終的にどのような形になるのかを確認するために、私の結果を参考例として見ることができます。
以下は、すでに私がリポジトリへ登録した記事の一部一覧です。
- プロジェクトは「PrintFormat()の学習と既成の例の適用」稿に基づいて「単体スクリプト」として実装されています。
ここでは「スクリプト」プロジェクトタイプを使用しました。特定のユーティリティを転送する必要がある場合は、これが理想的かつ最速の方法です。 - プロジェクトは、「MQL5の構造とそのデータを出力する方法」稿に基づいて、「複数スクリプト構成」として実装されています。
この場合、複数のスクリプトを1つのプロジェクトにまとめるために[空]を選択しました。 - MVCパターンに基づいたライブラリのプロジェクト。各記事に対応するサブバージョンがあります。これは「空のプロジェクト」として実装されており、各リリースはコミットとリリース作成によって、それぞれの記事からプロジェクトにマージされます。
すべてのプロジェクトはクラウド上に保存され、メンテナンスはワンクリックで完了します。
MetaQuotes Ltdによってロシア語から翻訳されました。
元の記事: https://www.mql5.com/ru/articles/21732
警告: これらの資料についてのすべての権利はMetaQuotes Ltd.が保有しています。これらの資料の全部または一部の複製や再プリントは禁じられています。
この記事はサイトのユーザーによって執筆されたものであり、著者の個人的な見解を反映しています。MetaQuotes Ltdは、提示された情報の正確性や、記載されているソリューション、戦略、または推奨事項の使用によって生じたいかなる結果についても責任を負いません。
MQL5取引ツール（第24回）：3Dカーブ、パンモード、ViewCubeナビゲーションによる奥行き感の向上
エラー 146 (「トレードコンテキスト ビジー」) と、その対処方法
MQL5とデータ処理パッケージの統合（第8回）：グラフニューラルネットワークによる流動性ゾーンの検出
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
正直言って、忘れていました……申し訳ありません。
例えば、このリポジトリです。
エディタ（公開プロジェクトの一覧が表示されるタブ）では、なぜかこのプロジェクトが見つかりませんでした。Forgeのサイトでようやく見つけたのですが、アーカイブとしてダウンロードできることがわかりました。
個人的には、記事にコードを直接貼り付ける方式の方が、読者にとってはまだ使いやすいと思います。せいぜい、記事を編集せずに誤ったコードを再アップロードしたい場合などに便利という程度でしょう。
当面は、コードの掲載方法として両方の方法を併用するのが良いと思います。
エディタ（公開プロジェクトの一覧が表示されるタブ）では、どういうわけかこのプロジェクトが見つかりませんでした。Forgeのサイトでようやく見つけ、アーカイブとしてダウンロードできることがわかりました。
個人的には、記事にコードを添付する方式の方が、読者にとってはまだ使いやすいと思います。せいぜい、記事を編集せずに誤ったコードを再アップロードできるという点で便利かもしれません。
当面は、コードの掲載方法として両方の方法を併用するのが良いと思います。
もちろん、アーカイブとしてダウンロードすることも可能です。しかし、フォークを作成するほうが良いでしょう（私は自分のプロジェクトのため、当然ながらフォークを作成することはできません）：
この場合、ローカルマシン上にプロジェクトのミラーが作成され、そこで修正や改良を加えて、著者にレビューのために送信することができます。著者は提案を受け取り、検討した上で、自身の元のプロジェクトに追加することができます。
これこそが、プロジェクトに対する共同作業となります。
素晴らしい記事ですね。
最新のベータ版では、アプローチを全面的に見直し、ソースファイルやプロジェクトを Unicode/UTF-16で保存することをやめました。
これは、GitやUTF-8を好むAIアシスタントとの互換性を最大限に高めるためです。
これは、GitやUTF-8を好むAIアシスタントとの互換性を最大限に高めるためです。