Mercado: Como serão tratadas as situações de falha do produto após uma actualização de construção ? - página 3

 
Urain:

+1

Se é esse o conceito, não deveria estar a acenar com os punhos.

Porque não? Talvez a MQ nos leve a algo de bom sem o saber. Um conceito não é um dogma.
 
tol64:

Entendeu mal sobre a "singularidade" da opção. Foi o único na altura em que escrevi sobre o assunto. Agora já existe uma versão modificada e até outras variantes. O comboio da "singularidade" já partiu. :)

OK, vamos assumir que cada opinião é a única na altura em que foi escrita :) O único para o autor do parecer :) Ironia, claro.

Tol64:

O trabalho continua mesmo depois de o produto ter sido colocado no mercado. E não vai demorar muito tempo a testá-lo numa nova construção.

Tem a certeza de que todos escrevem programas com todos os módulos em uso a toda a hora e imediatamente? E que ninguém tem módulos que são ligados uma vez a cada quinzena ou uma vez por mês. Com este tipo de código, os bugs podem ser detectados "à medida que vão avançando" com bastante antecedência, e pelos clientes.

 
Yedelkin:

OK, vamos assumir que cada opinião é a única no momento em que é escrita :) O único para o autor do parecer :) Ironia, claro.

Tem a certeza de que todos escrevem programas, todos os módulos dos quais são utilizados constante e imediatamente? E que ninguém tem módulos que estejam ligados a cada quinzena ou a cada mês. Em tal código, os bugs podem ser detectados "no decurso do trabalho", longe de imediatamente, e pelos clientes.

A decisão será tomada pelos criadores do terminal comercial. Antes de o fazer, eles irão considerar a questão de tantos ângulos que nem sequer podíamos sonhar. No final, tudo pode ficar como está. :)

Tem alguma variante de solução para esta questão? Ou qual das opções propostas considera que está mais próxima do que deveria estar?

Ордерa, позиции и сделки в MetaTrader 5
Ордерa, позиции и сделки в MetaTrader 5
  • 2011.01.05
  • MetaQuotes Software Corp.
  • www.mql5.com
Надежный торговый робот не может быть создан без понимания механизмов работы торговой системы MetaTrader 5. Клиентский терминал получает от торгового сервера информацию о позициях, ордерах и сделках. Чтобы правильно обработать эти данные средствами MQL5 необходимо хорошо представлять как происходит взаимодействие mql5-программы и среды исполнения терминала.
 
Urain:

Dei-vos um exemplo do que um comprador leria se houvesse as palavras SEM RESPONSABILIDADE na frase.

Só por precaução, deixem-me lembrar-vos que a percepção humana é selectiva. Um facto bem conhecido do cinema: se o filme não interessa ao público nos primeiros 20 minutos, então pode ser qualquer coisa, quaisquer acrobacias intrigantes e geralmente de beleza celestial, mas o cinema neste momento está vazio, vejam esta beleza ninguém.

O mesmo se aplica às vendas, a conhecida marca Zhiguli no nosso país, em Itália teve de ser renomeada Lada, pois faz lembrar muito o gigolo, bem, que tipo de vendas pode haver se um comprador vier e lhe for oferecido um "carro moderno muito fixe" com o nome gigolo :) então como andar nele que? Posso imaginar exclamações excitadas de italianos, olha, olha, chegou um gigolô :)

É apenas surpreendente que a maioria deles veja o problema apenas de um dos lados. E de tópico para tópico. Deixe-me explicar para um caso específico.

Havia um autor do programa, havia o programa, havia um cliente. O programa funcionou bem durante algum tempo, mas depois um bug no MQ fez com que parasse de funcionar. O que é uma conclusão imparcial? - Isto é correcto, se a MQ foi a fonte do problema, é responsável, e as questões devem ser abordadas a partir dessa perspectiva. O que faz a maioria das pessoas? - Começam, de uma forma ou de outra, a dividir os deveres e interesses do autor e do comprador, e propõem variações com base na relação entre o autor e o comprador. Por outras palavras, eles deixam a razão para trás. Para resolver um problema e oferecer variantes é necessário proceder a partir da razão de um tema, em vez das consequências da razão para o autor e o comprador...

Cláusula especial: sem desvios ao tema.

 

Yedelkin, pára de misturar a discussão da tua personalidade e as sugestões sobre o tema no teu posto.

Não tenho a liberdade de apagar o seu posto na sua totalidade, tem frases sobre o tema. Também não posso apagar frases individuais de um posto fora de tópico.

Já lhe foi emitido um aviso - não volte o tema à sua personalidade.

 
tol64:

Tem alguma opção para lidar com esta questão? Ou qual é a opção que lhe parece mais próxima do que deveria ser?

A julgar pelo número de postos, as acusações de trollishness estão prestes a chegar :)

... A primeira opção, como se costuma dizer "on the fly", já declarou. Se pensa que uma discussão construtiva só é possível se houver um monte de opções diversas - agora vou pensar. Embora o vector de pensamento acima indicado.

 
sergeev:

Yedelkin, pára de misturar a discussão da tua personalidade e as sugestões sobre o tema no teu posto.

Não tenho a liberdade de apagar o seu posto na sua totalidade, tem frases sobre o tema. Também não posso apagar frases individuais de um posto fora de tópico.

Já lhe foi emitido um aviso - não volte o tema à sua personalidade.

OK, eu apago o poste "estragado" que fiz, vocês apagam o poste que citei, e o actual poste. De acordo?

Quanto aos "avisos" - foi você quem moveu o fio para a minha identidade. Mesmo que posteriormente tenha apagado esse post. Portanto, não vamos jogar o jogo de aviso.

 
tol64:

Tem alguma opção para lidar com esta questão? Ou qual é a opção que lhe parece mais próxima do que deveria ser?

Opção 2. Se houver um desejo de formalizar as relações ao abrigo da lei russa, é necessário convidar peritos na Parte 4 do Código Civil da Federação Russa para resolver o problema. Ver, por exemplo, o Artigo 1296 do Código Civil "Programas de computador e bases de dados criadas por encomenda". Segundo sei, se o comprador começou a utilizar o programa, não há nada a exigir do programador - todas as reivindicações são contra a MQ como fonte de um possível bug. Se a MQ é capaz de rejeitar tal reclamação é uma questão para eles. ...Talvez outros vejam uma solução diferente no Código Civil.

Opção 3. O comprador do Mercado deve não só ser informado da disponibilidade de uma nova construção, mas ao mesmo tempo "no mesmo fluxo de informação" para que tal comprador tenha conhecimento de que esta construção está aprovada / não aprovada pelo autor do programa. Se a construção não for aprovada pelo autor do programa - não permitir que esta construção seja descarregada ao nível do terminal no computador do comprador do Mercado (ou não permitir que o programa do Mercado seja carregado com a nova construção). Isto resultará em:

  • (a) o comprador será, se assim o desejar, obrigado a contactar o autor do programa;
  • (b) o autor do software verificará as suas obrigações contratuais em relação ao produto em questão no Mercado;
  • (c1) se o autor tiver previamente subscrito para apoiar o produto para novas construções - cumprir as suas obrigações gratuitamente dentro de um período de tempo razoável e provocar a MQ se encontrar bugs;
  • (c2) se o autor não se comprometer a manter o produto em ordem quando novas construções forem lançadas no Mercado, pode recusar o comprador ou, mediante pagamento, comprometer-se a verificar a construção e a falar com a MQ, se necessário;
  • (d) o autor pode, se a MQ não responder dentro de um prazo razoável, informar o cliente de que a reclamação deve ser remetida à MQ, ou reescrever o produto "tal como está", se assim o desejar;
  • (e) Será necessário que a MQ estabeleça um mecanismo para manter as versões antiga e nova do build no servidor durante um período de tempo razoável.

=====De alguma forma, os detalhes podem sempre ser esclarecidos/acrescentados. Digo-vos desde já: pediram-me opções - eu gerei-as. Espero que a ideia seja clara. Sugeriu o que eu inventei agora. A perguntas "como imagina tal implementação" não pode responder. Definitivamente não defenderá as opções, com base em experiências infelizes.

 
Yedelkin:

(c2) se o autor não estiver empenhado em manter o produto no mercado quando forem lançadas novas construções

este é o ponto em questão.

as regras e mesmo hipoteticamente as meta-cotações não incluíam tal cláusula no acordo de Mercado. Isto implica que as novas construções não podem afectar o funcionamento do produto MQL5. E não é assim nos produtos reais.

E isto é essencial. Uma vez que o desempenho do produto após o lançamento dependerá dos programadores, e não do programador de mql.

 
sergeev:

esta é a cláusula em questão.

nas regras e mesmo hipoteticamente as meta-cotações não colocaram tal cláusula no acordo de mercado. Implicando que as novas construções não podem afectar o funcionamento do produto MQL5. E não é assim nos produtos reais.

E isto é essencial.

Eu não tinha conhecimento de tais subtilezas. Ou seja, actualmente é a MQ que (voluntariamente ou não) assumiu toda a responsabilidade nesta parte, não é?

Quanto ao Acordo, não é uma fundação de betão armado, está sujeito a melhorias :) Se este ponto é tão importante para os autores de produtos - a ênfase deve ser colocada também nele, a fim de se chegar a uma solução mutuamente aceitável.

Além disso, os advogados civis têm esta abordagem... Resumindo: o fabricante pode dar a sua garantia sobre uma parte de algumas obrigações e a loja pode complementar esta garantia. Bem, lembra-se do Mvideo, por exemplo? - Aí dão uma garantia de troca gratuita durante 2-3 anos por 100-200 dólares. Portanto, a questão é que o fabricante do produto é responsável apenas pela parte das obrigações que ele próprio assumiu, a loja - pelo resto.

Assim, se eu fosse o autor do programa, tentaria utilizar a primeira opção, nomeadamente: na publicidade, o produto indicaria que é responsável apenas por "so-and-so", "so-and-so" e "so-and-so" (longa lista). Mas eu não sou responsável por "isto" (a pequena lista). E se as regras do mercado permanecerem inalteradas, então a responsabilidade pelo produto para além dos deveres que eu cobro recairá sobre a administração da loja (porque as suas regras são assim).

Razão: