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

[AlexeyFX]

pronych:

ソースは、余分な機能やクラスなどがたくさんある、よく設計されたテンプレートにすることができます。

標準のツールでマスクの交点をバンバン削るのはわかりますが、残念でなりません。しかし、テンプレートに膨大な労力を費やしたのであれば、どうやって？いや、ここにいるよ？

ジョブオーダーを読みましたか？仮面越えとかゴミしかないじゃん。もし、手放しで後悔しないのであれば、動作さえしていれば、テンプレートから不要なものをすべて削除してください。

面白いですね。

私は、FXで「良い」アイディアが、「良い」ソフトウェアの実装よりもコストがかかるというのを見たことがありません。

この質問への回答 - ソースコードには、お客様が権利者であると主張できる機能があります

だから、著作権者は彼に任せよう。彼はあまり良くないアイデアを思いつき、あなたはあまり良くないソフトウェアを書いて、あまり良くないお金を手に入れた、みんな幸せになるべきだ。そんなソフトも1週間もすれば思い出せなくなる。良いアイデアもあるのですが、作業指示書には絶対になりません。このようなアイデアの価値は、そのソフトウェア実装とは比較にならないので、バカは人前に出さないし、プライベートでも見知らぬプログラマーに見せることはないだろう。良いアイデアを思いついた人は、その言語を学ぶことができます。

[Yedelkin]

pronych:
右

そして、サービスデスクに手紙を 出す。アイデアが適切であれば（必要に応じて文言の調整も可能です）。

pronych。

では、「仕事」にどんな追加をお願いしたいのか、一度（開発者が寝ている間に、静かに）考えてみましょう。

問題は発生した時に解決するのが良いのです :)ちゃんとしたスレッドを立ち上げたのだから、アイデアが出れば発言してくれるだろう。

[Aleksey]

Interesting:

私の考えでは、もう一つ別の方法があります。請負業者と顧客の間に調停者-仲裁者（私たちの場合はMQ）がいて、請負業者は材料＋ソースのパッケージ全体を調停者に渡し（調停者はTORと照合）、その後、顧客は調停者から仕事が完了した旨の通知を受け取り、その代金を支払わなければならないのです。

仕事の独占性と支払い後の最初の取り決めにより、クライアントは最大限のオープンソースコードまたはコンパイルされたファイルのみを受け取ります。

この場合、仲介者は一定の報酬を受け取ることはご承知の通りです。

追記

MQはあまり好きではないようですが...。

彼らは、今のままで十分なのだ...。

[Yedelkin]

Interesting:

私の意見では、仲介者（私たちの場合はMQ）が請負業者と発注者の間に入り、請負業者は材料とソースのパッケージ全体を仲介者に渡し（仲介者はそれをToRと照合）、その後、発注者は仲介者から仕事が完了した旨の通知を受け取り、その代金を支払う義務があるという別の方法があります。

MQのショップ構想にはあまり馴染みがない。ショップのアイデアと乖離があるのでは？

[削除済み]

pronych:
誰にでも、というわけではありません））ただし、もちろん、それも選択肢の一つではありますが・・・。私としては、1つのファイルを用意しておく方が便利なんです。これは、タスク（読み取り - 'コスト'）を複雑にしますが、会話はそれについてさえありません。 このようなアプローチは、アイデアを分割し、我々はそのようなことで（または知らない！彼らは異なっていてもよい）知っていない顧客、愚かではない ））） 。私は、「ソースが欲しい」というチェックボックスで十分だと思いますし、規約の合意以前に、ほとんどの問題を解決するだけです。この問題が理解できるようになれば、仕事の話を続けることができます。

1.なぜ？特定のモジュールだけをオープンにして、部分的にクローズドなテンプレートという意味では、有効なアイデアだと思います。

コストや時間の面でも、この方法の方がずっと安上がりだとさえ思っています。

2.おそらくチェックボックスは必要だと思いますが、ソースコードに限らず、すべての権利をクライアントに譲渡すること（例外的な権利、クライアントに好き勝手させる、実行者の行動を制限する）です。

そうでなければ、請負業者が自分の仕事の結果を第三者に売る（例えば雑誌を通して）ことを誰が妨げるのか、教えてください。

お客様が同じことをするのを誰が止めるのですか？しかし、1つの仕事に対して、複数のお客様が投じ、お金を払ってくれる可能性もあるわけで、その場合はどうするのでしょうか。

[削除済み]

AlexeyFX:

だから、著作権者は彼に任せよう。彼はあまり良くないアイデアを思いつき、あなたはあまり良くないソフトウェアを書いて、あまり良くないお金を得たのだから、みんな幸せになるべきだ。1週間もすれば、そんなソフトのことは思い出せなくなるはずです。良いアイデアもあるのですが、作業指示書には絶対になりません。このようなアイデアの価値は、そのソフトウェア実装とは比較にならないので、バカは人前に出さないし、プライベートでも見知らぬプログラマーに見せることはないだろう。良いアイデアを思いついた人は、その言語を学ぶことができます。

1.非常に良いアイデア（私の意見では）個人的に、だけでなく、私はそれを自動化することはありませんし、あまりにも怠惰なそれを議論する。まあ、2枚のワッシャーに専門家のクローンを作って10ドルで売ろうという気はさらさらないんですけどね。

とはいえ、アイデアがまともであれば、2MACHINESはどんなTSのベースにもなり得ますが。

2.ただ、最終的な権利を誰が持っているかということが、最も重要だと私は考えています。私が個人的にこの質問を理解する限り、著作権者が顧客である場合、彼は適切なこと（作品を販売する、単独で、または第三者の助けを借りてコードに変更を加える、自身の開発でコードを使用する、など）を行うことができ、一方でアーティストへの言及は削除できる可能性が高いです。

請負業者がコードの全部または一部の権利を保持している場合、請負業者は顧客に対して金銭的または著作権的な権利を主張する権利を有しています。この場合、契約者はアルゴリズムとコードを自己の利益のために使用する権利を有します。

通常の注文や通常の作業は、（ターミナルが実際のアカウントで 使用され、真剣なトレーダーが興味を持った後に）間違いなく表示されるでしょう。

追記

個人的な意見ですが、通常のTORのコストは受注総額の50％まで、平均すると10％程度です（もちろんTOR自体のコストは同じ10％よりずっと低くても構いませんが、顧客と請負業者が仕事の内容を明確に理解することが必要です）。

もちろん、よく練られたToRのコストが仕事そのものよりも高くつくような特殊なケースもありますが、それは、ほとんどの場合、顧客が何を望んでいるのかがわかっていない場合の話であり、別の話なのです。

[Aleksey]

Interesting:

1.なぜ？特定のモジュールだけをオープンにして、部分的にクローズドなテンプレートという意味では、有効なアイデアだと思います。

コストや時間の面でも、この方法の方がずっと安上がりだとさえ思っています。

2.おそらくチェックボックスは必要だと思いますが、ソースコードに限らず、すべての権利をクライアントに譲渡すること（例外的な権利、クライアントに好き勝手させる、実行者の行動を制限する）です。

そうでなければ、請負業者が仕事の成果を第三者に（例えばSHOPを通じて）販売することを誰が妨げるのか、教えてください。

誰がお客様を阻止するのか？しかし、複数のお客様がプールして、一つの仕事にお金を払うということもあり得るわけで、その場合はどうするのでしょうか。

1.私もそう思います。チェックボックスがあれば、あるいはチェックボックスでなくても、「ソースは完全に」「ソースは部分的に」「コンパイル済み」などのオプションがあれば、顧客にどの結果（この場合はファイル）を取得したいかを明確に示す必要があるということです。これではプロセスが複雑になり、アプリケーションの段階で意味を成しません。すべては後で交渉すればいいのです。お客様が「ソース」にチェックを入れたのであれば、議論することに意味があるし、そうでなければ、どんな質問をするのか、どうぞ！ということです。))この状況では、情報源に関する質問は、敏感であるだけでなく、非常に滑りやすいものであることはおわかりいただけるでしょう。ルールにそのような側面がないことに驚いたくらいです。

2.こちらも真面目な質問です。考えなければならないことがある。演奏者だけが義務を負うのではなく、お客様も申し込みの段階から、より充実した情報を指定すべきです。もしかしたら、アプリケーションを拡張する方が理にかなっているかもしれません。いくつかのアイデアを紹介する。例えば、受託生産品でも守るために。個人的には、自分の開発したもの（MT4）は、常にアカウントで確認しながら守っていました。まあ、この質問は私のことではないのですが...。

[Aleksey]

Interesting:

1.私個人は、（私見では）良いアイデアを自動化しないだけでなく、議論するのが億劫になります。まあ、2台のマシンで専門家のクローンを作って10ドルで売りたいとは思わないが。

しかし、そのアイディアに価値があり、2MACHINESはどんなTSの基礎にもなり得ます。

2.ただ、最終的な権利を誰が持っているかということが、最も重要だと私は考えています。私が個人的にこの質問を理解する限り、著作権者が顧客である場合、彼は適切なこと（作品を販売する、単独で、または第三者の助けを借りてコードを変更する、自分の開発でコードを使用する、など）を行うことができ、一方でアーティストへの言及は削除することができると思われます。

請負業者がコードの全部または一部の権利を保持している場合、請負業者は顧客に対して金銭的または著作権的な権利を主張する権利を有しています。この場合、契約者はアルゴリズムとコードを自己の利益のために使用する権利を有します。

通常の注文と通常の作業は、（ターミナルが実際のアカウントで 使用され、真剣なトレーダーがそれに興味を持った後に）間違いなく現れます。

追記

個人的な意見ですが、通常のTORのコストは、受注総額の50％まで、平均10％程度です（もちろん、TORそのものがコストとなり、同じ10％よりはるかに低くなる場合もありますが、顧客と請負業者が仕事の内容を明確に理解する必要があります）。

もちろん、よく練られたToRのコストが仕事そのものよりも高くつくような特殊なケースもありますが、それは、ほとんどの場合、顧客が何を望んでいるのかがわかっていない場合の話であり、別の話なのです。

そのとおりです。私は、何も付け加えることはありません。さあ、次は甘やかしの番です。すべてはこれから

[削除済み]

Yedelkin:
MQのショップ構想にはあまり馴染みがない。ショップのアイデアと乖離があるのでは？

1. MAGAZINEの基本的な考え方は、プログラマーがソフトウェアソリューション（エキスパート／スクリプト／インジケーター／ライブラリ）を作成し、コードや著作権者の権利を提供することなく、複数の「顧客」（むしろバイヤーと呼ぶ）にそれを販売することができるというものである。

この場合、MQはサービスの主催者として、販売者と購入者の間を仲介し、両者を一定の形で保護する。 したがって、開発者は販売した製品の違法コピーからプログラマーの権利を保護し、購入者は製品が説明どおりで「お金を払う価値がある」ことを保証する必要があるのである。

2.私のアイデアは、ショップのアイデアを彷彿とさせますが、いくつかの留保があります - つまり、お客様は権利とソースコードをBUYすることができます。また、私の理解では、SHOPで販売できないものもあるようです。例えば、TKを直接「販売」する機会はありません（サービス「ジョブ」ではそのような機会があります）、ショップで独自のDLLと同様のものに関連するすべてのソリューションが動作しません。

追記

私の考えでは、2つの方法があると思います（SHOPとWORKの大きな違い）。

1.プログラマーは「良い」ソフトウェアソリューションを作り、それを多くの顧客に適正価格で販売することができる。顧客は、特定のソフトウェア製品を適正価格で購入することができる（ただし、その独占権はない）。

2.両者が納得する金額での合意により、顧客はカスタマイズされたソフトウェア製品を注文することができる。また、請負業者の仕事の結果に対する独占的な権利を取得することもできる。

[Aleksey]

店頭では）混乱も起きている。ここでは、何を売るのかに重点を置いて考えなければなりません。それは、彼らが言うように、オール・アンド・サン ドリーのための一つのことですが、別のものは、ターゲット、顧客は、将来の参考のために、口座とブローカーを指定することです。それ以外にはないでしょう？またもや、まったく異なる状況ですね