作業中のルール - ページ 16

[Mykola Demko]

pronych:

私はいつもソースコードを掲載しています。

でも、そんなに気になるなら、簡単な仕組みですぐに効果が出ます。

作業契約の締結時（正確な発注額がわかっている時）に、購入することを規定する。

ショップで公開した、必要なプラグインモジュール。投稿した実行済みTORのソースコードも。

それに伴い、図書館の費用も割り引かれます。

---

MQに決済システムを確定してもらい、注文したお金でお店で何か買えるようにすることはできますが（お客さんが業者の勧めで手に入れる、あるいは業者がお客さんに代わって手に入れるという意味です）。その後、お客様が購入内容を更新できることが大きなポイントです。

[Aleksey]

Urain:

それなのに、なぜ物事を複雑にし、追加購入の交渉や支払いシステムの改良をするのか。申込書に「Sources」というチェックボックスを入れるだけで、交渉の前にすべての問題が解決されるのに。これで、すべての混乱と時間の無駄を解決することができます。そして、それが受け入れられない人に邪魔されることはありません。というのも、私のシステムは互いに深く統合されているので、個別のモジュールを設置することができないのです。もちろん、シグナルモジュール（またはアプリケーションのもの）をex-fileにアタッチすることは可能です。

[Mykola Demko]

pronych:
それなのに、なぜ物事を複雑にし、追加購入の交渉や支払いシステムの改良をするのか。申込書に「Sources」というチェックボックスを入れるだけで、交渉の前にすべての問題が解決されるのに。これで、すべての混乱と時間の無駄を解決することができます。そして、それが受け入れられない人に邪魔されることはありません。というのも、私のシステムは互いに深く統合されているので、個別のモジュールを設置することができないのです。問題ありません。もちろん、実行のロジックを明確にするために、ex-fileにシグナルモジュール（またはアプリケーション内のもの）を添付することは可能です。

サービスに自動 コード更新が ない以上（ショップでの宣言通り）、すべてゴミになる。

お客様は、次のビルドアップデートまでの間、動作するプログラムを得るべきであり、動作しないプログラムを得るべきではありません。実行されたすべての注文が最新のビルドでコンパイルされていることを確認するエグゼキュータはありません。

[Andrey Khatimlianskii]

pronych:
しかし、アプリケーションに「Sources」というチェックボックスを追加するだけで、交渉の前にすべての問題が解決するなら、なぜ物事を複雑にし、追加購入の交渉や支払いシステムを改良する必要があるのでしょうか。

Alexeiさん、このチェックボックスはすでに あるとお考えください。すべての注文に

[михаил потапыч]

pronych:
アプリケーションに「ソース」というチェックボックスを追加するだけで、交渉の前からすべての問題を解決できるのであれば、なぜ物事を複雑にし、追加購入の交渉や支払いシステムを改良する必要があるのでしょうか。これで、すべての混乱と時間の無駄を解決することができます。そして、それが受け入れられない人に邪魔されることはありません。というのも、私のシステムは互いに深く統合されているので、個別のモジュールを設置することができないのです。もちろん、シグナルモジュール（またはアプリケーションのもの）をex-fileにアタッチすることは可能です。

参考までに、このティックを必要とするロボトミーされた落ちこぼれのお客様をここに表現してみてください。

市場なんだから、自分がどうしたいのか、お客さんがどうしたいのか、そんなことは関係ない、大事なのは自分が納得することなんだ。

1％のお客様は、履歴の統計を取るためなど、1回限りの使用でスクリプトを注文し、チェックマークに屈することになります。

ということで、一回だけ答えて、この質問とスクリプトのことは忘れてしまうかもしれません。

他の人たちは、とにかく長い間、命令された プログラムを必要とする、確かにそう思っている。

そして、どんなサービスも、どんなお店も、最小限のクリックで、とんでもなくシンプルに、わかりやすく、便利で、信頼できるものでなければならないのです

[Aleksey]

komposter:
Alexeiさん、このチェックボックスはすでに あるとお考えください。すべての注文に

これでよしとする。よかったー、何か来たようだ))オートコンパイルについてもね。わかったよ、降参だ、反論はしない。ここには多くの支持者がいない。もしかしたら、後の人生でこのテーマに立ち戻ることになるかもしれない。結局、顧客がソースコードを入手できるとは限らない。特に、mqlの観点ではなく、ソフトウェア開発全般の観点で見れば......。

皆さん、議論していただきありがとうございました。

[Yedelkin]

Integer:

イェデルキン
誰にでも勘違いする権利はある。その理由は先に述べたとおりです。

すべてのイワン・スーザニンには間違える権利があり、すべてのエンジニアには間違える権利があり、すべてのスナイパーには外す権利があり、すべてのパイロットやドライバーには衝突する権利があり、すべてのセールスマンには顧客に過剰請求する権利があり、すべての電気技術者には電圧を測定する権利があり、すべてのトレーダーには利益を得る権利があるのである。間違っていることが正しいというのは、なぜか不条理な感じが します。

ハイライトされたコメント：このアプローチでは、「すべての裁判官は間違う権利がある」という仮定について考える良い機会です。そして、その仮定を自分の人生経験に当てはめてみてください。

そして、私たち一人ひとりが自分の問題を解決するために定期的に裁判官の役割を果たしていることを考慮すれば、「私の場合」（つまりあなたの場合）にはこの仮定が不合理に見えることを理解する良い機会になるでしょう :) あるいは、ほとんど不合理です :)

[Yedelkin]

Mischek:

不明確なものに対する不明確な権利の問題が 解決されるまで、何百人もの人々が茫然と凍りついたままである。そして、ボットだけが「ジョブズ」サービスで仮想注文とその実行を生成します。

当たり前のことを認めて、何が問題なのか？

ミシェイクが ご丁寧に右の「F」を付けられた時に起きたことである、ということは既に皆が認識している。 従って、「...an issue of unclear rights of unclear what」という表現は、「an issue of unclear rights of unclearMischek on what」と見るべきだろう。悪気はないのですが、ただ事実を述べたまでです。

[Yedelkin]

pronych:

ここにはあまり支持者がいないんです。もしかしたら、後で人生からこの話題に戻されるかもしれません。

支持者の数が問題なのではありません。一対一でも、正しいことができる。

あなたのスレッドで提起された本質的な点が議論されています。その解決策を議論してきました。そして、挑発は、私たちの上にいくつあるのだろうか......。ざまみろ:)

pronych。

皆さん、議論していただきありがとうございました。

コメントせずにはいられなかった :)

[Aleksey]

Yedelkin:

支持者の数が問題なのではありません。一対一でも、正しいことができる。

あなたのスレッドで提起された本質的な点が議論されています。その解決策を議論してきました。そして、挑発は、私たちの上にいくつあるのだろうか......。ざまみろ:)

コメントせずにはいられなかった :)

まあ、そうですね。 ポイントは議論されています。状況の推移を見守ろう。