English Русский Español Français
preview
MQL5 Algo Forgeへの移行(第1回):メインリポジトリの作成

MQL5 Algo Forgeへの移行(第1回):メインリポジトリの作成

MetaTrader 5 |
15 7
Yuriy Bykov
Yuriy Bykov

内容



はじめに

中規模から大規模のプロジェクトを進める際には、コードの変更を追跡し、それらを意味ごとに整理し、必要に応じて以前のバージョンに戻す必要が必ず生じます。一般的に、これはGitやSubversion (SVN)といったバージョン管理システムによって実現されます。

ほとんどの開発環境は、何らかのバージョン管理システムのリポジトリを操作するための組み込みツールを提供しています。MetaEditorも例外ではなく、SVNを基盤とした独自のリポジトリMQL Storageをサポートしています。ドキュメントには次のように記載されています。

MQL5 Storageは、MQL4/MQL5のソースコードを保存する個人用オンラインリポジトリです。これはMetaEditorに統合されており、エディタで直接ストレージからデータを受信することができます。

このストレージはバージョン管理システムを備えています。変更を取り消すと、以前のバージョンに戻すことができます。

MQL5ストレージを使用すると、ソースコードは常に安全な状態に保たれます。データは保護されたサーバに保存され、アクセスできるのは1箇所だけです。ハードドライブに障害が発生した場合でも、以前に保存したすべてのコードを復元できます。

さらに、ストレージを利用することで、チャートテンプレートやプロファイル、MQL5プログラムのテスト用パラメータセット、取引銘柄セットを複数のプラットフォーム間で簡単に共有し、同期することができます。

また、MQL5 Storageはチームでのリモート開発にも対応しており、共有プロジェクトを通じてMQL5アプリケーションを共同で開発することが可能です。

しかしながら、バージョン管理システムとしてはGitがはるかに広く普及しており、私たちもその理由を十分に理解できます。おそらくこのため、MetaQuotesは2024年半ば、MetaEditorにおける標準のバージョン管理システムとしてGitを採用し、さらにGitHubの社内代替サービスとなるMQL5 Algo Forgeを立ち上げる計画を発表しました。

この記事の執筆時点で、新しいリポジトリはすでに利用可能になっていますが、MetaEditorとの統合はまだ完了していません。そのため、MetaEditorが依然として主要な開発環境ではあるものの、開発者は現状SVNベースのMQL Storageに制限されています。

私たちはこれまでのプロジェクトにおいて既存のバージョン管理システムを積極的に活用してきました。しかし、連載記事「多通貨エキスパートアドバイザーの開発」を執筆した際、コードの並列開発やブランチ統合をサポートする機能が不足していることが特に顕著になりました。SVN自体はブランチをサポートしていますが、MetaEditorはそのためのインターフェースを提供していません。外部のSVNクライアントを利用することは可能ですが、それでは既存のワークフローを大きく再構築する必要があります。

このため、MQL5 Algo Forgeの発表は歓迎すべきニュースでした。MetaEditorがついにブランチをサポートするのではないかと期待したのです。しかし、発表から7か月が経過した現在、その期待はまだ実現されていません。そこで、本記事では現時点で利用可能なツールを用いて、開発プロセスをどのように改善できるかを検討していきます。

理解を深めるには、少なくともバージョン管理システムに関する基礎知識が必要です。必要に応じて、MQL5公式サイトや「Getting started with Git」などの資料を事前にご参照いただくことをお勧めします。


現在利用可能なツール

MetaQuotesがMQL5 Algo Forgeの立ち上げを発表して間もなく、同プラットフォーム上にmql5というリポジトリが作成され、そこには既存のMQL Storage内のすべてのファイルが格納されました。ただし、それらはすべてユーザーsuper.adminによる単一のコミットとして追加されており、コミット履歴は一切保存されていませんでした。これは想定された結果です。異なるバージョン管理システム間で完全な履歴を移行することは、ほぼ不可能だからです。

その後、MetaEditorの一部のインターフェース要素に新しいリポジトリ名が表示されるようになりました。たとえば、バージョン履歴ダイアログのタイトルは「MQL5 Algo Forge」に変更されました。

しかし、本質的な部分は変わっていません。すべての変更は依然としてMQL Storageに保存されており、Algo Forgeには反映されていないのです。したがって、7か月前にAlgo Forgeにコピーされたファイルは更新されないまま残っています。

一方で、変化した点もあります。それは、複数のリポジトリを扱えるようになったことです。以前はリポジトリが1つしかなく、異なるプロジェクトをMQL5データフォルダ内の別々のディレクトリに作成しなければなりませんでした。MQL5データフォルダは常にリポジトリのルートであったため、新しいプロジェクト用に新しいターミナルインスタンスを作成してストレージを有効化すると、関係のないプロジェクトを含めてすべてのプロジェクトがストレージからダウンロードされてしまいました。プロジェクト数が増えるにつれて、これはきわめて不便になりました。

不要なプロジェクトをデータフォルダから単純に削除することもできませんでした。なぜなら、その状態でコミットを行うと、削除された項目をストレージに送信しないよう、毎回手動で除外設定をしなければならなかったからです。

一方、正規のGitリポジトリを使えるようになったことで、ストレージの構造化や異なるプロジェクトの管理について、いくつかの選択肢が可能になりました。

  • 各プロジェクトを独立したリポジトリとして管理する
  • 各プロジェクトを1つのリポジトリ内の別ブランチとして管理する
  • ハイブリッド型モデル:一部のプロジェクトは独立リポジトリに配置し、その他は1つのリポジトリ内のブランチとして共存させる

それぞれのアプローチには長所と短所があります。たとえば、複数のプロジェクトが同じライブラリを共有している場合、そのライブラリを別のリポジトリに分離して管理するのは不便です。その場合は、専用のブランチにライブラリを保持し、必要に応じて各プロジェクトブランチへ変更をマージする方が適しています。一方で、外部依存のない独立したプロジェクトについては、他のプロジェクトに関連しないコードを保存しなくて済むため、別リポジトリとして管理する方が望ましいでしょう。


移行の開始

変更を行う際には、既存の環境を保全しておくことが賢明です。MetaQuotesがsuper.adminを通じて追加作業を行う可能性があるため、自動作成されたmql5リポジトリをそのまま利用するのは最適な方法ではありません。そこで、まずはすべての既存プロジェクトを保存するための新しいリポジトリを作成します。ここでは、各プロジェクトを異なるブランチで管理するモデルを採用します。この分離を実現するため、以下のルールを定めます。

  • mainブランチは空のままにしておくか、すべてのプロジェクトで共通して利用される最小限のコードのみを格納します。
  • アーカイブブランチには移行時点で存在するすべてのコードを保存します。ここから各プロジェクトブランチへ必要なコードをコピーします。
  • その他のブランチは各プロジェクトに対応し、それぞれプロジェクト名に従って命名します。
  • プロジェクトブランチは採用するブランチ戦略に応じて複数アクティブなものを持つことができます(例:「A Successful Git Branching Model」で説明されている手法)。

ここで、ターミナルがインストールされ、MQL Storageに接続されているMetaTrader5フォルダを想定します。すなわち、MetaTrader5/MQL5データフォルダには標準ファイルとともに、私たちのプロジェクトのコードも含まれています。


MetaTrader5.forgeという名前の新しいフォルダを作成し、そこに2つの実行ファイルをコピーします。

このフォルダからMetaTraderターミナルをポータブルモードで起動します。環境によってはダブルクリックで自動的にポータブルモードが有効化されますが、そうでない場合はコマンドラインから起動時に「/portable」を明示的に指定するか、ショートカットを作成して起動コマンドに「/portable」を追加してください。この段階ではデモ口座を開設したり、MQL5.communityにログインしたりする必要はありません。

新しいフォルダには初期フォルダ構造が作成され、その中に空のMQL5データフォルダが含まれています。まだファイルは含まれていません。

ターミナルからF4を押してMetaEditorを起動します。

フォルダ名を右クリックすると、コンテキストメニューに[MQL5 Algo Forgeを有効にする]オプションが表示されます(実際にはMQL Storageが有効にされます)。ここでは新しいリポジトリに移行する予定のため、まだ有効化しないでください。

この後しばらくはターミナルやMetaEditorを使用しないため、両方とも閉じます。以降の操作はターミナルフォルダ内で直接実行します。


リポジトリ管理ツール

次のステップは、新しいリポジトリを操作するためのツールを選定することです。将来的にはこの役割をMetaEditor自体が担う可能性もありますが、現時点では別のツールを使用する必要があります。Gitリポジトリを扱えるツールであれば何でも利用可能です。たとえば、Visual Studio Code (VSCode)とGitの組み合わせです。Windows版Gitはgitforwindows.orgからダウンロードできます。

まずはGitとVSCodeをインストールします(すでにインストール済みであれば確認のみで構いません)。VSCodeには、MQL5ファイルを扱うための拡張機能「MQL Tools」を追加します。

拡張機能をインストールした後、設定のMetaeditor5 DirパラメータにMetaEditor実行ファイルへのパスを指定します。ターミナルインスタンスの作業フォルダ外にあるMQL5ソースファイルを扱う必要はないため、推奨されているとおり、VSCodeで開いているフォルダからの相対パスを指定するとよいでしょう。

さらに下の設定項目にある[Portable MT5]オプションは必ず有効化することを強く推奨します。

構文ハイライトを利用するためには、VSCodeにC/C++拡張機能をインストールする必要があります。

ただし、MQL5はC++に非常によく似ていますが、標準のC++には存在しない言語構文を含んでいます。そのため、この拡張機能はMQL5の文脈では無関係な構文エラーを表示する場合があります。

VSCodeでMetaTrader5.forge/MQL5データフォルダを開きます。

任意のエキスパートアドバイザー(EA)ファイルを開いてみてください。

構文ハイライトは正しく機能し、エディタウィンドウ右上にMQL5構文チェックやMetaEditor経由でのコンパイル用ボタンが追加表示されます。ただし、この時点ではすべての#includeディレクティブがエラーメッセージを出すはずです。これはMQL5がC++ではなく、標準ライブラリのインクルードファイルの場所が異なるためです。エラーを解消するには、VSCodeのC/C++拡張機能の設定で、MetaTrader5.forge/MQL5/Includeへのパスを追加します。

設定を終えるとエラーメッセージは消え、EAは問題なくコンパイルされるようになります。

この段階で、VSCodeのセットアップは完了です。一旦VSCodeから離れ、いよいよ本記事の主役であるMQL5 Algo Forgeを使った作業に移ります。


メインリポジトリの作成

まず、https://forge.mql5.io/にアクセスし、新規アカウントを登録するか、既存のMQL5.communityの認証情報を使用してログインします。

右上のメニューから[New repository]を選択します。

次にリポジトリ名を指定します(例:mql5-main)。ーカル環境でリポジトリをクローンする際は、ルートフォルダ名を自由に設定できるので、リポジトリ名そのものは厳密に重要ではありません。初期化時には、必ず.gitignoreREADME.mdを追加します。

これでリポジトリが作成されます。最初のコミットは自動的に行われます。

次のステップとして、リポジトリのURLをコピーします。今回の例では「https://forge.mql5.io/antekov/mql5-main.git.」になります。これでブラウザからVSCode、MetaEditor、そしてMetaTrader 5ターミナルに戻って作業を続行できます。


リポジトリのクローン作成

リポジトリをローカル環境にクローンするには、ターミナルディレクトリ内に空のMQL5フォルダが必要です。現在はすでにファイルが格納されているため、以下の手順で作業を進めます。

  • VSCode、MetaEditor、MetaTrader 5をすべて終了します。
  • 既存のMQL5フォルダの名前を変更します(例:MQL6)。

これで、MetaTrader5.forgeディレクトリ内にMQL5フォルダは存在しなくなります。

このフォルダをVSCodeで開き、ターミナルを起動します(「Ctrl +」を押下)。

リポジトリのURLをコピーし、以下のコマンドでクローンを実行します。ローカルリポジトリのルートフォルダ名としてMQL5を指定します。

git clone https://forge.mql5.io/antekov/mql5-main.git MQL5

リポジトリがプライベートで、初めてクローンする場合は認証情報の入力が求められます。クローン完了後、ターミナルディレクトリ内にMQL5サブフォルダが作成され、その中には.gitignoreREADME.mdが格納されます。

次に、MetaTrader5.forge/MQL6内のすべてのファイルおよびフォルダをMetaTrader5.forge/MQL5に移動し、移動後、古いMetaTrader5.forge/MQL6フォルダを削除します。

VSCodeでMetaTrader5.forge/MQL5フォルダを開きます。左側のSource Controlパネルを見ると、リポジトリフォルダに大量の新規ファイル(今回の例では581ファイル)が表示されます。

ただし、これらの多くは標準のMetaTrader 5インストールに含まれるファイルであり、私たちのリポジトリに含めるべきではありません。新しいバージョンでは、標準ライブラリやサンプルプロジェクトの内容や構造が変更されることがあります。これらをリポジトリに含めて変更すると、次回ターミナルを更新した際や新しい作業フォルダに切り替えた際にコンフリクトが発生するリスクがあります。そのため、標準ファイルをリポジトリに含める必要はありません。


除外ファイルの設定

ここで役立つのが.gitignoreファイルです。.gitignoreでは、Gitに対して無視するファイルやフォルダを指定できます。これにより、数百にも及ぶ不要な変更が表示される代わりに、自分たちが実際に管理したいファイルの変更のみを確認できるようになります。現時点では、まだリポジトリにカスタムファイルを追加していないため、現在リストされているファイルはすべて無視対象とするのが妥当です。

.gitignoreを開き、デフォルト内容を以下のように置き換えます。

# ---> MQL5
# VSCode Preferences
.vscode/*

# Executables
*.ex5

# MQL5 Standard Files
/Experts/Advisors/
/Experts/Examples/
/Experts/Free Robots/
/Experts/Market/
/Files/
/Images/
/Include/Arrays/
/Include/Canvas/
/Include/ChartObjects/
/Include/Charts/
/Include/Controls/
/Include/Expert/
/Include/Files/
/Include/Generic/
/Include/Graphics/
/Include/Indicators/
/Include/Math/
/Include/OpenCL/
/Include/Strings/
/Include/Tools/
/Include/Trade/
/Include/WinAPI/
/Include/MovingAverages.mqh
/Include/Object.mqh
/Include/StdLibErr.mqh
/Include/VirtualKeys.mqh
/Indicators/Examples/
/Indicators/Free Indicators/
/Libraries/
/Logs/
/Profiles/
/Scripts/Examples/
/Scripts/UnitTests/
/Services/
/Shared Projects/
/experts.dat
/mql5.*

この設定により、バージョン管理システムはVSCodeの設定ファイルや、コンパイル済みのEAやインディケータファイル(リポジトリには通常ソースコードのみを保存します)、そして指定されたフォルダ内にある標準のMetaTrader 5ファイルを除外するよう指示されます。これにより、自分たちのソースコードのみが追跡対象となります。


変更のコミット

.gitignoreを保存すると、VSCodeには変更されたファイルとして.gitignoreだけが表示されます。MQL5フォルダ内の他のファイルは、現在mql5-mainリポジトリのルートフォルダになっていますが、物理的には存在するものの、すべて無視される状態になります。

次に、ローカルリポジトリでコミットを行います。メッセージとして「Add standard files to .gitignore」などを追加し、[Commit]をクリックします。

この時点では、変更はローカルリポジトリにのみ存在します。リモートリポジトリに反映するには、pushコマンドを実行します。方法はいくつかあり、VSCodeでは[Sync Changes]をクリックしてCHANGESの横にある省略メニュー(…)から[Push]を選ぶ、あるいは手動で「git push」コマンドを実行することも可能です。

ただし、最後のコミットをプッシュする前に、GRAPHでコミット履歴を確認してください。ここには、[Initial commit]と[Add standard files to .gitignore]の2つのコミットが表示されます。ブランチ名は右側に色付きで表示されます。最初のコミットはorigin/mainとラベルが付けられ、2つ目のコミットは単にmainと表示されます。実際にはどちらも同じmainブランチです。ここでoriginはリモートリポジトリのエイリアスであり、origin/プレフィックスはそのコミットがリモートリポジトリのmainブランチにおける最新のコミットであることを示します。2つ目のコミットにはこのプレフィックスが付いていないため、ローカルリポジトリにのみ存在する最新のコミットであることを意味します。

[Sync Changes]を押します。

変更がリモートリポジトリに正常にプッシュされ、紫色の「origin」ラベルが2つ目のコミットに移動します。Webインターフェースでリポジトリを確認することで、この状態を確認できます。

この段階で、ほぼ空のリポジトリが作業用に準備されました。唯一のブランチであるmainには、追加した2つのファイルのみが含まれます。このターミナルインスタンスのデータフォルダに存在するその他のファイルは、バージョン管理システムによって無視されます。


アーカイブブランチの作成

前述の通り、まず最初のステップとして、既存のすべてのファイルを1つのブランチにまとめ、バージョン管理下に置き、リモートリポジトリへプッシュできる状態にします。こうすることで、必要に応じて他のコンピュータからもファイルを取得できるようになります。

バージョン管理システムにおける他の操作と同様に、ブランチはさまざまな方法で作成できます。VSCodeからは、リポジトリメニュー(…)を開き、[Checkout to…]を選択します。

次に、表示されるアクション一覧から[Create new branch…]を選択します。

Webインターフェースでは、リモートリポジトリの[Branches]タブから、新しいブランチ作成ボタン(下図の緑枠で強調)をクリックします。

この2つの方法には1つ違いがあります。最初の方法はローカルコンピュータ上でブランチを作成し、変更をプッシュするまではリモートリポジトリはこのブランチの存在を知りません。2つ目の方法はリモートリポジトリ上でブランチを作成するため、ローカルリポジトリはpullコマンドで変更を取得するまでブランチの存在を認識しません。どちらの場合も、最終的にはpullまたはpushを実行して同期すれば問題ありません。

3つ目の方法として、コマンドラインを使用することも可能です。たとえば、ローカルリポジトリ内で新しいブランチarchiveを作成するには、リポジトリフォルダで次のコマンドを実行します。

git checkout -b archive

VSCode統合ターミナルで実行すると、次のように表示されます。

リポジトリが新しく作成されたarchiveブランチに切り替わったことが表示されています。コミット一覧では、ブランチ名がmainからarchiveに変更されます。変更履歴には、この新しいブランチをリモートリポジトリにプッシュすることを促すメッセージが表示されますが、まずはこのブランチにファイルを追加します。

もともとMetaTraderターミナルのフォルダには、すべてのファイルが入ったMQL5フォルダがありました。リポジトリは別のターミナルフォルダ内に作成済みです。ここで、古いMetaTrader5/MQL5フォルダ内のすべてのファイルを、新しいリポジトリのフォルダにコピーします。

すると、バージョン管理システムはリポジトリ内の新しいファイルを即座に検出し、いくつかの操作が可能になります。これらすべての新規ファイルをインデックスに追加する必要があります。これは、VSCodeのインターフェースで変更リストのヘッダーにある「+ (Stage All Changes)」を選択するか、コマンドラインで次のコマンドを実行して行うことができます。

git add .

これにより、変更リスト内の各ファイルがU (Untracked)からA (Added)に変更され、インデックスに登録された状態になります。その後、変更をコミットし、リモートリポジトリへプッシュします。

この時点で、mainブランチの最後のコミットは2つ目のコミットとなり、3つ目のコミットがarchiveブランチで作成されます。新しいブランチがリモートリポジトリにプッシュされたことを確認しましょう。

最新のコミットがリモートリポジトリ上でarchiveブランチに属していることがわかります。このコミットをクリックすると、含まれる具体的な変更内容を確認できます。

これで、すべてのファイルが無事にarchiveブランチに追加されました。次に、ローカルリポジトリでmainブランチに戻ります。


プロジェクトブランチ作成の準備

まず、mainブランチに切り替えるには、コンソールで次のコマンドを実行します。

git checkout main

これにより、ローカルリポジトリはファイルをコピーする前の状態に戻ります。しかし、ブランチを切り替えた後にMQL5フォルダの内容を確認すると、多くのEAのフォルダが残っていることに気づくかもしれません。

これらのフォルダには依然としてコンパイル済みの.ex5ファイルが含まれています。これは、これらのファイルをバージョン管理から除外していたため、archiveブランチからmainブランチに切り替えた際にGitが削除しなかった結果です。リポジトリにステージングされてコミットされたソースファイルのみが、フォルダから削除されています。

このままでは非常に不便なため、コンパイル済みファイルや、それらを削除した後に残った空のディレクトリも併せて削除する必要があります。手作業で行うと時間がかかり、将来的に同じ作業を繰り返す可能性もあるため、自動で処理できる簡単なスクリプトを作成する方が実用的です。

スクリプトを作成する過程で、ファイルを削除するだけではブランチ切り替え後のルートフォルダを元の状態に戻すには不十分であることがわかりました。.ex5ファイルを削除した後に空になったディレクトリも併せて削除する必要があります。ただし、一部のフォルダは意図的に空のままにしておく必要があるので、除外リストに追加します。このリストには、以前.gitignoreに記載されていたすべてのフォルダに加え、バージョン管理のメタデータを格納する.gitフォルダも含めます。 

このようなスクリプトの例を次に示します。

import os


def delete_ex5_files_and_empty_dirs(path, excluded=['.git', '.vscode']):
    # Exceptions
    excluded = {os.path.join(path, dir) for dir in excluded}

    # Check all folders and files in the directory tree
    for root, dirs, files in os.walk(path, topdown=False):
        is_excluded = False
        for ex in excluded:
            if root.startswith(ex):
                is_excluded = True
                break
        if is_excluded:
            continue

        # Delete all files with extension .ex5
        for file in files:
            if file.endswith('.ex5'):
                file_path = os.path.join(root, file)
                os.remove(file_path)
                print(f'File removed: {file_path}')

        # Delete all folders that have become empty after deleting files
        for dir in dirs:
            dir_path = os.path.join(root, dir)

            # IF the directory is empty after deleting files
            if dir_path not in excluded and not os.listdir(dir_path):
                try:
                    os.rmdir(dir_path)
                    print(f'Empty folder removed: {dir_path}')
                except OSError:
                    pass  # If error occurred, ignore


excluded = [
    '.git',
    '.vscode',
    'Experts\\Advisors',
    'Experts\\Examples',
    'Experts\\Free Robots',
    'Experts\\Market'
    'Files',
    'Images',
    'Include\\Arrays',
    'Include\\Canvas',
    'Include\\ChartObjects',
    'Include\\Charts',
    'Include\\Controls',
    'Include\\Expert',
    'Include\\Files',
    'Include\\Generic',
    'Include\\Graphics',
    'Include\\Indicators',
    'Include\\Math',
    'Include\\OpenCL',
    'Include\\Strings',
    'Include\\Tools',
    'Include\\Trade',
    'Include\\WinAPI',
    'Indicators\\Examples',
    'Indicators\\Free Indicators',
    'Libraries',
    'Logs',
    'Presets',
    'Profiles',
    'Scripts\\Examples',
    'Scripts\\UnitTests',
    'Services',
    'Shared Projects',
]

if __name__ == '__main__':
    current_dir = os.getcwd()  # Current working directory
    delete_ex5_files_and_empty_dirs(current_dir, excluded)

このスクリプトをリポジトリのルートにclean.pyという名前で保存し、mainブランチでバージョン管理に追加します。これ以降は、archiveブランチからmainブランチに切り替えた後、このスクリプトを実行するだけで、コンパイル済みファイルや空フォルダのクリーンアップを自動的に行うことができます。


まとめ

これで、新しいリポジトリシステムに関する初期作業は終了です。すべてのファイルを無事にリポジトリに移行できました。また、新しいプロジェクト用のブランチを作成するための基盤も整いました。コードはアーカイブブランチに安全に保存されているため、必要に応じて各プロジェクトを別ブランチに順次移行していくことが可能です。

次の興味深いステップとしては、連載記事「多通貨エキスパートアドバイザーの開発」のソースコードを公開リポジトリとして作成することです。連載内の各回のコードをどのように配置するかはまだ検討中ですが、近いうちに取り組む予定です。

ご精読ありがとうございました。またすぐにお会いしましょう。


アーカイブ内容

#
 名前
バージョン  詳細 
  MQL5   リポジトリのルートフォルダ(ターミナルデータフォルダ)
1 .gitignore 1.00
Gitバージョン管理システムによって無視されるフォルダとファイルのファイルリスト
2 clean.py
1.00 リポジトリのmainブランチに切り替えるときにコンパイルされたファイルと空のディレクトリを削除するスクリプト

MetaQuotes Ltdによってロシア語から翻訳されました。
元の記事: https://www.mql5.com/ru/articles/17646

添付されたファイル |
MQL5.zip (1.66 KB)
最後のコメント | ディスカッションに移動 (7)
Maxim Kuznetsov
Maxim Kuznetsov | 7 4月 2025 において 15:52
Yuriy Bykov プロジェクトの コードを取得することができなくなります。

正直なところ、このシナリオは考慮されていません。現在、フォーラムでユーザーを追放すると、現在のMQL Storageリポジトリへのアクセスが制限されるのかどうか、また、それによって新しいリポジトリへのアクセスも制限されるのかどうかはわかりません。もしそうなら、このリスク要因は確かに考慮する価値があります。

これを確認するのは難しいので、リスク評価は理論的なものです ;-) しかし、以下のようなリスクがあります。

MQLStorageはコミュニティにログインする必要があります。ログインの技術的な可能性は管理者の手に委ねられています。理論的には、もしあなたが規則に著しく違反した場合(または誰かがそれを真剣に考える場合)、ハードBANを受ける可能性があります。一時的な禁止krodeで唯一の "権利の敗北 "として、それは単にサイトのコンポーネントであり、個々のサービスが禁止されています。

しかし、仮想、サーバー、データセンター、禁止-ポ-ipを獲得しているネットワークもあります。MQLStorageはそこから利用できない可能性が高いです。個人的な努力は必要なく、動的なIPを使用するだけでも入手することができます:-)

このようなリスクを最小化するために、リポジトリの完全なバックアップと独立したミラーを維持してください。それはまた別の楽しみです...

Rashid Umarov
Rashid Umarov | 9 9月 2025 において 09:00
Maxim Kuznetsov プロジェクトとは おさらばです :-)

まず、https://forge.mql5.io/ には2つの認証オプションがあります。MQL5.comから完全に独立したアカウントを作成することができます。

第二に、フォーラムでの禁止は投稿の禁止のみを意味し、他のサービスには影響しません。

フォーラムではなく、ロボットの開発に参加してください。




Stanislav Korotky
Stanislav Korotky | 9 9月 2025 において 14:09
Rashid Umarov #:

まず、https://forge.mql5.io/ には2つの認証オプションがあります。MQL5.comから完全に独立したアカウントを作成できます。

しかし、mql5.comに依存しない場合、どうやってMEプロジェクトにアクセスするのでしょうか?そこのコミュニティにログインすることが義務付けられているようです。

Rashid Umarov
Rashid Umarov | 9 9月 2025 において 14:13
Stanislav Korotky #:

mql5.comに依存しないのであれば、MEからプロジェクトにアクセスする方法は?そこのコミュニティにログインする必要があるようです。

アカウントはMQL5.comに作成されます。

Yuriy Bykov
Yuriy Bykov | 9 9月 2025 において 14:27
Stanislav Korotky #:

mql5.comに依存しないのであれば、MEからプロジェクトにアクセスする方法は?そこのコミュニティにログインする必要があるようです。

まだコミュニティにログインする必要はありません。Algo ForgeやGitHubなどのリポジトリから、MQL5のデータフォルダ内のフォルダにリポジトリをクローンすると、ファイルのあるフォルダとして表示されます。編集、起動、デバッグにはこれで十分ですが、リポジトリに対するすべての操作はサードパーティのツールを使用して実行する必要があります。MEがまだAlgo Forgeで作業できない間は、このオプションをしばらく使っていました。しかし、一般的にはmql5.comアカウントを使う方が簡単です。

EAのサンプル EAのサンプル
一般的なMACDを使ったEAを例として、MQL4開発の原則を紹介します。
プライスアクション分析ツールキットの開発(第23回):Currency Strength Meter プライスアクション分析ツールキットの開発(第23回):Currency Strength Meter
通貨ペアの方向性を本当に決定しているのは何でしょうか。それは各通貨自体の強さです。本記事では、通貨の強さを、その通貨が含まれるすべてのペアを順に分析することで測定します。この洞察により、各通貨ペアが相対的な強さに基づいてどのように動くかを予測することができます。詳しくは本稿をご覧ください。
エラー 146 (「トレードコンテキスト ビジー」) と、その対処方法 エラー 146 (「トレードコンテキスト ビジー」) と、その対処方法
この記事では、MT4において複数のEAの衝突をさける方法を扱います。ターミナルの操作、MQL4の基本的な使い方がわかる人にとって、役に立つでしょう。
機械学習の限界を克服する(第2回):再現性の欠如 機械学習の限界を克服する(第2回):再現性の欠如
本記事では、同一の戦略と金融銘柄を用いても、ブローカーによって取引結果が大きく異なる理由について探ります。その背景には、価格が分散的に形成されていることや、データの不一致があるためです。本記事は、MQL5開発者がMQL5マーケットプレイスで自らの製品に対して賛否両論の評価を受ける理由を理解し、透明性が高く再現可能な成果を確保するためには、特定のブローカーに合わせたアプローチを取る必要があることを示唆しています。この取り組みが広く受け入れられれば、コミュニティにとって重要な実務上のベストプラクティスへと発展する可能性があります。