私のアプローチコアはエンジンです。 - ページ 49

 
Алексей Тарабанов:

イストックに?

いいえ。番号のついた研究所、今は番号を覚えていない。

そして、それでも私は言わない :-)

 
:)
 
Реter Konow:

興味本位で、私のウィンドウを再現するために必要なコードを作ってここに表示して、私のバージョンと比較してみましょうか。

妙な負けず嫌いなんですね :)

興味本位ですが、このようなプログラムのアナログをguiで作ることはできますか?


プログラムは2013年に2ヶ月で書き上げ、並行して別のプロジェクトも まだ進行中です。

プログラムの最終コンパイルは2014年なので、多少の誤作動はありえます :)

取引所取引商品で実行するのがよいでしょう。

司会者への補足:このプログラムは市販されていません。

ファイル:
IShift.ex5  3312 kb
 
Yury Kulikov:

このプログラムは2013年に2ヶ月で書き上げられ、並行して別のプロジェクトがまだ進行中である。

司会者への説明:このプログラムは市販されていません。

は、高品質で、きちんとした外観を持っています!特にマニュアルがあるのがいいですね。これも現在進行形です。

とはいえ、プロとしてやるか、まったくやらないか、つまり、そういうコードを書いたら、それを書き続けてマーケットプレイスで売り続ける必要があり、そうしないと作業負荷が非常に高くなります。

このようなプログラムの需要はどの程度あるのでしょうか?- 月に5個以上売れていますか?

 
Igor Makanu:

このような番組の需要はどの程度あるのでしょうか?- 月に5本以上売れているのでしょうか?

おそらく3年間で8台しか購入されていない。

 
Yury Kulikov:

購入したのは8枚だけで、おそらく3年後。

さめざめ

マーケットに興味がある私にとっては、3クリックで.dllを接続し、フォームデザイナーですべてのギミックを行うことができれば十分です。つまり、標準のMTツールで十分で、手間がかかると思うことはすべてサードパーティーのソフトウェアで行います

もしあなたが開発者なら、市場に「カレンダー付きの塗り絵」ではなく、利益を生み出す、あるいは効果的な分析ツールとなるような、完全な機能を備えた製品を投入する必要があります。

ピーター・コノウが 何をマネタイズしたいのか、誰かわかったか?

 
同じことをOOPを使ってやって みたらどうだろう。なぜその可能性を利用せず、OOPの原則を把握しようともしないのか理解できない。ITスペシャリストという職業は、まさにそのスペシャリストが常に自己研鑽に励んでいることを意味します。技術は止まっていないのだから、新しいプログラミング言語が登場し、PCの性能も向上している。一般に、進歩は止まりません。しかし、あなたのプログラミングスタイルは、2000年のレベルから抜け出せず、他のプログラマーにそのボロボロの時代のレベルに戻るように勧めているのです。何度も言っていることだが、もう一度だけ繰り返す。これをすべてRPFを使ってやってみる。
 

ピーターが考えていることは、確かに良いことだと思います。しかし、そのようなエンジンを作るには、賢い人材が必要です。

というのも、私自身、MQLでパネルを作成 する方法として、シンプルなMQLオブジェクト、標準オブジェクト、Canvasの3つの方法を知っているからです。

また、シンプルなユーザーには、数多くのパラメータや可能性を秘めた巨大なパネルは必要ありません。そして、ここに必要なものがあります。





追伸:このロボットはまだ発売されていませんが、発売され次第、このビデオは削除します。

 
Алексей Тарабанов:

ここが私の反対するところです。半自動売買は、半自動で売買することを意味しており、「買い・売り」ボタンなどをクリックする機能ではありません。

大変残念なことに、作者は頑なにこのボタンを生成する仕組みを教えてくれる--それだけなのだ。

EAの主要なレベルの1つが突然新しいホームロケーションに移動したとき、EAのインタラクティブ性はどこにあるのでしょうか。

半自動売買では、作業の一部はExpert Advisorが行い(この作業は常にルーチン)、他の部分はトレーダーが行います(洞察に基づく情報を生成する-洞察と混同しないように)。その後、Expert Advisorは、トレーダーが繰り返し介入し、その行動を繰り返し修正できるように常に準備しながら、共同作業のインタラクティブなプロセスの結果をピックアップし、それを完了させる。

弾丸を描くのか、活動を自動化するのか。

Peterは、まさにこのようなセミオートマチックExpert AdvisorのためのGUIライブラリを提案しているようです。

つまり、セミオートマは自分で書くのです。そして、ピーターのライブラリ - ちょうどあなたが簡単にユーザーコントロールを表示するのに役立ちます(それは簡単ですか?

もう何度も言いますが、ターゲット層には図書館で十分なんです。しかし、問題はこのまさにターゲットの極端な狭さにある。ここでのピーターへの批判はすべて、ターゲットオーディエンスの一員ではない人たちによるものです。彼らはすべて、たとえ「セミオート」(実際には、少し手動で追加したオートマタ)であっても、多くのコントロールを必要としないプログラマーであり、これらの人々は自分のためにプログラムを書くことを好みます。 ピーターは、プログラムができても、手動取引を好む人々を必要としています - つまり、手動入力、手動停止設定と転送、手動クローズなどです。エキスパートアドバイザーは、あくまでも手軽な形で情報を提供するものです。

評論家の中にそういう人はまだいないし、きっとほとんどいないでしょう。

ピーターは「こういう人たちの層を作る」と主張しているが、それは大いに疑問だ。プログラマーに手動でトレードすることを教え、半自動機での手動トレードの方が優れていることを証明する?非現実的。でもね、もしかしたら私が間違っているかもしれない。

 
Vitalii Ananev:
ピーターさんも、OOPを使って 同じことをやってみてはどうでしょう。その機能を使わず、OOPの原理にも触れようとしないのは理解できない。ITスペシャリストという職業は、まさにそのスペシャリストが常に自己研鑽に励んでいることを意味します。技術は止まっていないのだから、新しいプログラミング言語が登場し、PCの性能も向上している。一般に、進歩は止まりません。しかし、あなたのプログラミングスタイルは、2000年のレベルから抜け出せず、他のプログラマーにそのボロボロの時代のレベルに戻るように勧めているのです。何度も言っていることだが、もう一度だけ繰り返す。RPFを使って全部やってみる。

Vitaly 問題は、ピーターが暗記の巨人であることだ。どこにどんなインデックスがあるのか、それが何を意味するのか、どんなつながりがあるのか、どこにあるのかを忘れない。

このような素晴らしいメモリでは、OOP-enhancementsは不要なジェスチャーに過ぎず、多少のパフォーマンス低下もあります。何のために?

OOPは、なぜある場所で変数を変更できて、隣の場所ではできないのか、一週間もしたら思い出せなくなるような人たちのためのものです。カプセル化、public, protected, prevertedのクラスセクション、仮想インターフェイス、ポリモーフィズムなどを必要とするのは彼らである。また、コンピュータのようにすべてをメモリ上に持っている場合は、OOPを強化しなくても、各オブジェクトに直接アクセスする方がはるかに簡単です。

オブジェクトを渡すときに参照の数を考慮し、誰も参照していないときにそれらを削除するスマートポインタのクラスをピーターに提案する!ピーターは驚くだろう。彼は、それぞれのオブジェクトがいつ作られ、何人のユーザーがいて、いつまで存在すべきか、そしていつ削除されるべきかをよく覚えている。使う意味はあるのか?


いや、そういうやり方もあるんですね。唯一の疑問は、誰のためなのか?ピーター氏は「そのようなユーザーの層を作ることになる」と主張する。さて、さて...見てみよう。