Règles sous le travail - page 6
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
La source peut être un modèle bien conçu, avec de nombreuses fonctionnalités supplémentaires, des classes, etc.
Je comprends que vous pouvez utiliser des outils standards pour frapper l'intersection des masques, et ce n'est pas une honte. Mais si une énorme quantité de travail a été mise dans le modèle, alors comment ? Non, vous êtes prêt ?
Avez-vous lu l'ordre de mission ? Il n'y a que des déchets comme les masques de croisement. Si vous ne regrettez pas de le donner, du moment qu'il fonctionne, supprimez toutes les choses inutiles du modèle.
Je n'ai pas vu de "bonnes" idées dans le Forex qui coûtent plus cher qu'une "bonne" mise en œuvre logicielle.
La réponse à cette question - Le code source a la capacité de permettre au client de prétendre être le propriétaire légitime.
Alors laissez-le être le détenteur du copyright. Il a eu une idée pas très bonne, vous avez écrit un logiciel pas très bon et vous avez reçu de l'argent pas très bon pour ça, tout le monde devrait être content. Vous ne vous souviendrez même pas d'un tel logiciel dans une semaine. Il y a de bonnes idées, mais elles ne feront jamais l'objet de bons de travail. La valeur d'une telle idée étant incomparable avec sa mise en œuvre logicielle, aucun crétin ne l'exposerait en public, et même en privé, il ne la montrerait pas à un programmeur inconnu. Ceux qui ont eu une bonne idée peuvent apprendre la langue.
Droit
Puis écrivez au Service Desk. Si l'idée convient (la formulation peut être adaptée si nécessaire).
Réfléchissons donc tout de suite (en silence, pendant que les développeurs dorment)), à quel genre d'ajouts nous voudrions demander dans la section "Travail" ?
À mon avis, il existe une autre solution : il y a un médiateur-arbitre (dans notre cas, MQ) entre l'entrepreneur et le client, et l'entrepreneur remet l'ensemble des matériaux + sources au médiateur (qui les vérifie par rapport aux TDR), après quoi le client reçoit une notification du médiateur indiquant que le travail est terminé et qu'il doit le payer.
En fonction de l'exclusivité du travail et des accords initiaux, après le paiement, le client reçoit le code source ouvert complet ou seulement les fichiers compilés.
Dans ce cas, comme vous le comprenez, l'intermédiaire reçoit une certaine rémunération.
PS
Bien qu'il me semble que MQ ne l'aime pas beaucoup...
À mon avis, il existe une autre solution - un intermédiaire-arbitre (dans notre cas, MQ) s'interpose entre l'entrepreneur et le client, l'entrepreneur remet l'ensemble des matériaux + sources à l'intermédiaire (qui les vérifie par rapport aux TdR), après quoi le client reçoit un avis de l'intermédiaire indiquant que le travail a été achevé et est obligé de le payer.
Pas vraiment, pour tout le monde.)) Cependant, bien sûr, c'est aussi une option... Pour moi, c'est plus pratique d'avoir un seul fichier prêt. Cela complique la tâche (lire - 'coût') Mais la conversation n'est même pas à ce sujet. Cette approche divise l'idée, et le client que nous n'avons pas connu (ou ne connaissent pas ! Ils peuvent être différents) dans de telles choses, mais pas un imbécile ;)) Je pense que la case à cocher "Je veux des sources" est suffisante, et qu'elle permet de résoudre la plupart des problèmes avant de se mettre d'accord sur les termes de référence. Si cette question est compréhensible, vous pouvez continuer à discuter de l'emploi.
1. Pourquoi ? En termes de modèle partiellement fermé, dans lequel seuls certains modules sont ouverts, c'est une idée viable.
Je suis même certain qu'en termes de coût et de temps, cette approche serait beaucoup moins coûteuse.
2. La case à cocher est peut-être nécessaire, mais il ne s'agit pas seulement du code source, mais du transfert de tous les droits au client (droits exceptionnels, permettant au client de faire ce qu'il veut et limitant les actions de l'implémenteur).
Sinon, dites-moi qui empêche l'entrepreneur de vendre les résultats de son travail à des tiers (par exemple par le biais d'un MAGAZINE) ?
Qui empêche le client de faire de même ? Mais il est possible que plusieurs clients se cotisent et paient pour un travail, et puis quoi ?
Alors laissez-le être le détenteur du copyright. Il a eu une idée pas très bonne, vous avez écrit un logiciel pas très bon et vous avez été payé pas très bien pour ça, tout le monde devrait être content. Vous ne vous souviendrez même plus de ce logiciel dans une semaine. Il y a de bonnes idées, mais elles ne feront jamais l'objet de bons de travail. La valeur d'une telle idée étant incomparable avec sa mise en œuvre logicielle, aucun crétin ne l'exposerait en public, et même en privé, il ne la montrerait pas à un programmeur inconnu. Ceux qui ont eu une bonne idée peuvent apprendre la langue.
1. Pas une très bonne idée (à mon avis) personnellement, non seulement je ne vais pas l'automatiser, et en discuter trop paresseux. Eh bien, je n'ai aucune envie de cloner des experts sur deux rondelles et de les vendre pour 10 $.
Bien que si l'idée est valable, et 2 MACHINES peuvent être la base de n'importe quel TS.
2) La question de savoir qui détient les droits finaux est, à mon avis, la plus importante. Pour autant que je comprenne personnellement cette question, si le détenteur du droit d'auteur est le client, il peut faire tout ce qui lui convient (vendre l'œuvre, seul ou avec l'aide de tiers pour apporter des modifications au code, utiliser le code dans ses propres développements, etc.), tandis qu'il est probable que toute référence à l'artiste puisse être supprimée.
Si l'entrepreneur conserve tout ou partie des droits sur le code, il a le droit de faire valoir ses droits, financiers ou d'auteur, auprès du client. Dans ce cas, le contractant a le droit d'utiliser les algorithmes et le code à son propre profit.
Les commandes normales et le travail normal apparaîtront certainement (après que le terminal sera utilisé sur des comptes réels, et que des traders sérieux s'y intéresseront).
PS
Personnellement, je pense que le coût d'un TDR normal peut représenter jusqu'à 50 % du montant total de la commande, en moyenne environ 10 % (bien sûr, le coût du TDR lui-même peut être bien inférieur à ces mêmes 10 %, mais le client et le contractant doivent bien comprendre la nature du travail).
Il existe bien sûr des cas uniques où le coût d'un cahier des charges bien formulé sera plus élevé que le travail lui-même, mais c'est une autre histoire, car dans la plupart des cas, le client ne sait pas ce qu'il veut.
1. Pourquoi ? En termes de modèle partiellement fermé, dans lequel seuls certains modules sont ouverts, c'est une idée viable.
Je suis même certain qu'en termes de coût et de temps, cette approche serait beaucoup moins coûteuse.
2. La case à cocher est peut-être nécessaire, mais il ne s'agit pas seulement du code source, mais du transfert de tous les droits au client (droits exceptionnels, permettant au client de faire ce qu'il veut et limitant l'action de celui qui fait).
Sinon, dites-moi qui empêche l'entrepreneur de vendre les résultats de son travail à un tiers (par exemple, par le biais d'un SHOP) ?
Qui empêchera le client de faire de même ? Mais il est également possible que plusieurs clients se regroupent et paient pour un seul travail, et alors quoi ?
1. Je suis d'accord. Mais le fait est que dans ce cas, vous devez d'une manière ou d'une autre indiquer clairement au client quels résultats (dans ce cas - les fichiers) il veut obtenir. S'il y a une coche, ou même ne peut pas être une coche, mais une option telle que, "sources complètement", "sources partiellement", "compilé". Cela complique le processus et n'a pas de sens au stade de la demande. Tout peut être négocié plus tard. Si le client a coché "sources", il est logique de discuter, et si non, quelles questions, allez-y ! )) La question des sources, vous comprenez, est non seulement sensible, mais aussi très glissante dans cette situation. J'ai même été surpris de ne pas trouver un tel aspect dans les règles.
2. Voici aussi une question sérieuse. Il faut y réfléchir. Ce ne sont pas seulement les artistes qui devraient avoir cette obligation, mais aussi les clients qui devraient spécifier des informations plus complètes dès le stade de la demande. Il est peut-être plus judicieux d'élargir l'application. Introduisez quelques idées. Par exemple, pour protéger même un produit commandé. Personnellement, j'ai toujours protégé mes développements (MT4) en vérifiant sur le compte. Eh bien, la question ne porte pas sur moi...
1. Personnellement, non seulement je n'automatiserai pas une bonne idée (à mon avis), mais je suis trop paresseux pour en discuter. Eh bien, je n'ai aucune envie de cloner des experts à 2 MACHINES et de les vendre pour 10 $.
Bien que si l'idée sera décente, et 2 MACHINES peuvent être la base de n'importe quel TS.
2) La question de savoir qui détient les droits finaux est, à mon avis, la plus importante. Pour autant que je comprenne personnellement cette question, si le titulaire du droit d'auteur est le client, il peut faire tout ce qui lui convient (vendre l'œuvre, seul ou avec l'aide de tiers pour apporter des modifications au code, pour utiliser le code dans leurs propres développements, etc.), tandis qu'il est probable que toute référence à l'artiste puisse être supprimée.
Si l'entrepreneur conserve tout ou partie des droits sur le code, il a le droit de faire valoir ses droits, financiers ou d'auteur, auprès du client. Dans ce cas, le contractant a le droit d'utiliser les algorithmes et le code à son propre profit.
Des commandes et un travail normaux apparaîtront certainement (après que le terminal sera utilisé sur des comptes réels et que des traders sérieux s'y intéresseront).
PS
Personnellement, je pense que le coût d'un TDR normal peut représenter jusqu'à 50% du montant total de la commande, en moyenne environ 10% (bien sûr, le coût peut être le TDR lui-même et être bien inférieur à ces mêmes 10%, mais le client et le contractant doivent clairement comprendre la nature du travail).
Il existe bien sûr des cas uniques où le coût d'un cahier des charges bien formulé sera plus élevé que le travail lui-même, mais c'est une autre histoire alors que, dans la plupart des cas, le client ne sait pas ce qu'il veut.
Je ne connais pas très bien l'idée de la boutique de MQ. Votre idée diverge-t-elle de celle de la boutique ?
1. l'idée de base de MAGAZINE est que le programmeur crée une solution logicielle (expert/script/indicateur ou bibliothèque) et est capable de la vendre à plusieurs "clients" (ou plutôt les appeler acheteurs) sans fournir le code et les droits du détenteur du copyright.
Dans ce cas, MQ, en tant qu'organisateur du service, agit en tant qu'intermédiaire entre le vendeur et les acheteurs, protégeant les deux parties d'une certaine manière. Ainsi, les développeurs doivent protéger les droits du programmeur contre la copie illégale du produit vendu, et garantir à l'acheteur que le produit est conforme à la description et qu'il "vaut son prix".
2. Mon idée rappelle celle de la boutique, mais avec quelques réserves - notamment le client peut ACHETER les droits et le code source. En outre, si je comprends bien, il ne sera pas possible de vendre certaines choses/solutions dans le SHOP. Par exemple, il n'y aura pas de possibilité de "vendre" directement la TK (dans le "job" de service il y a une telle possibilité), toutes les solutions liées à leur propre DLL et des choses similaires dans la boutique ne fonctionneront pas.
PS
De mon point de vue, il y a deux façons de procéder (la principale différence entre SHOP et WORK) :
1. Le programmeur est en mesure de créer une "bonne" solution logicielle et de la vendre à un prix raisonnable à de nombreux clients. Le client est en mesure d'acheter un produit logiciel particulier à un prix raisonnable (mais pas de droits exclusifs sur celui-ci) ;
2. En fonction de l'accord conclu pour une somme acceptable pour les deux parties, le client peut commander un produit logiciel personnalisé. Il peut également acquérir des droits exclusifs sur les résultats du travail de l'entrepreneur.