Regras do Trabalho - página 16
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Eu sempre afixei o código fonte.
Mas se está tão preocupado com esta questão, poderá em breve beneficiar de um esquema simples:
Na conclusão do contrato de trabalho (quando conhece o montante exacto da encomenda) estipular que tem de comprar
módulos plug-in de que precisa que sejam publicados na loja. E o código fonte dos TOR executados que afixou.
O custo das bibliotecas é descontado em conformidade.
Embora se possa pedir à MQ para finalizar o sistema de pagamento, para que o dinheiro da encomenda possa comprar algo na loja (quero dizer que o cliente recebe por recomendação do empreiteiro, ou do empreiteiro em nome do cliente). O principal é que o cliente pode então actualizar a compra.
Assim, porquê complicar as coisas, negociar compras adicionais e refinar o sistema de pagamento, quando uma simples caixa de verificação "Fontes" no formulário de candidatura resolve todas as questões antes da fase de negociação. Isto resolve toda a confusão e perda de tempo. E não será incomodado por alguém para quem isto não é aceitável. A questão é que o meu sistema está demasiado profundamente integrado entre si para colocar módulos separados. Não há problema, claro que posso anexar o módulo de sinal (ou o da aplicação) ao ex-arquivo, apenas para tornar clara a lógica de execução.
Enquanto não houver uma actualização automática do código no serviço (tal como declarado na loja), é tudo lixo.
O cliente deve obter um programa funcional, não um programa funcional até à próxima actualização de construção. Nenhum executor se certificará de que todas as ordens executadas são compiladas na última compilação.
Assim, porquê complicar as coisas, negociar compras adicionais e aperfeiçoar o sistema de pagamento, se uma simples caixa de verificação "Sources" na aplicação resolve todas as questões, mesmo antes da fase de negociação.
Então, porquê complicar as coisas, negociar compras adicionais, aperfeiçoar o sistema de pagamento, se uma simples caixa de verificação "Fontes" no pedido, resolve todas as questões mesmo antes da fase de negociação. Isto resolve toda a confusão e perda de tempo. E não será incomodado por alguém para quem isto não é aceitável. A questão é que o meu sistema está demasiado profundamente integrado entre si para colocar módulos separados. Não há problema, claro que posso anexar o módulo de sinal (ou o da aplicação) ao ex-arquivo. apenas para que a lógica de execução seja clara.
Só por interesse, tente descrever aqui o cliente lobotomizado que precisa desta carraça.
É o mercado, não importa o que se quer, não importa o que o cliente quer, tudo o que importa é aquilo em que se está de acordo.
1% dos clientes cediria à marca de verificação encomendando um guião para uma utilização única, por exemplo para recolher algumas estatísticas sobre o histórico
por isso podem apenas responder à pergunta uma vez e esquecer esta pergunta e o guião.
Os outros necessitarão do programa encomendado durante muito tempo, em todo o caso, pensam certamente que sim.
E depois, qualquer serviço, qualquer loja deve ser escandalosamente simples, compreensível, conveniente e fiável com um número mínimo de cliques
Alexei, considere que esta caixa de verificação já lá está. Em todas as encomendas.
Aí está. Graças a Deus que chegámos a algo)). E também sobre a autocompilação. Muito bem, desisto, não vou discutir. Não tenho muitos apoiantes aqui. Talvez mais tarde a vida me faça regressar a este assunto. Afinal, nem sempre o cliente recebe o código fonte, especialmente se olharmos não em termos de mql, mas sim de desenvolvimento de software em geral...
Obrigado a todos pela discussão.
Integer:
Todos têm o direito de estar enganados. A razão é indicada anteriormente.
Cada Ivan Susanin tem o direito de estar errado, cada engenheiro tem o direito de estar errado, cada atirador furtivo tem o direito de falhar, cada piloto ou condutor tem o direito de bater, cada vendedor tem o direito de sobrecarregar o seu cliente, cada electricista tem o direito de medir a voltagem, cada comerciante tem o direito de ser colmargin. De alguma forma, o direito de estar errado parece absurdo.
Comente sobre o destacado: com esta abordagem tem uma grande oportunidade de reflectir sobre o postulado "Todo o juiz tem o direito de estar errado". E depois aplicar esse postulado à sua própria experiência de vida.
E se tiver em conta que cada um de nós desempenha periodicamente o papel de juiz na solução dos seus problemas, terá uma boa oportunidade de ver que no "meu caso" (quero dizer no seu) o postulado parece absurdo :) Ou quase absurdo :)
Centenas de pessoas são congeladas num estupor até que a questão dos direitos pouco claros a coisas pouco claras seja resolvida. E apenas o bot gera encomendas virtuais e a sua execução no serviço "Jobs".
Qual é o problema em admitir o óbvio?
Não tenho muitos apoiantes aqui. Talvez a vida me traga de volta a este tópico mais tarde.
Não se trata do número de apoiantes. Pode ser um contra todos e ainda assim ter razão.
Os pontos essenciais levantados no seu fio foram discutidos. As soluções para a situação têm sido discutidas. E provocações - quantos deles estarão no nosso ... caminho! :)
Obrigado a todos pela discussão.
Não pude deixar de comentar :)
Não se trata do número de apoiantes. Pode ser um contra todos e ainda assim ter razão.
Os pontos essenciais levantados no seu fio foram discutidos. As soluções para a situação têm sido discutidas. E provocações - quantos deles estarão no nosso ... caminho! :)
Não podia deixar de comentar :)