Regole sotto Lavoro - pagina 16
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ho sempre pubblicato il codice sorgente.
Ma se siete così preoccupati per questo problema, potete presto beneficiare di un semplice schema:
Alla conclusione del contratto di lavoro (quando conoscete l'importo esatto dell'ordine) stipulate che dovete comprare
moduli di plug-in di cui hai bisogno e che hai pubblicato nel negozio. E il codice sorgente del TOR eseguito che hai postato.
Il costo delle biblioteche è scontato di conseguenza.
Anche se si può chiedere a MQ di finalizzare il sistema di pagamento, in modo che i soldi dell'ordine possano comprare qualcosa nel negozio (voglio dire che il cliente ottiene su raccomandazione del contraente, o il contraente per conto del cliente). L'importante è che il cliente possa poi aggiornare l'acquisto.
Quindi perché complicare le cose, negoziare acquisti aggiuntivi e perfezionare il sistema di pagamento, quando una semplice casella di controllo "Fonti" sul modulo di domanda risolve tutti i problemi prima della fase di negoziazione. Questo risolve tutta la confusione e la perdita di tempo. E non sarete disturbati da qualcuno per il quale questo non è accettabile. Il fatto è che il mio sistema è troppo profondamente integrato con l'altro per mettere dei moduli separati. Nessun problema, posso naturalmente allegare il modulo del segnale (o quello dell'applicazione) al file ex, solo per rendere chiara la logica di esecuzione.
Finché non c'è un aggiornamento automatico del codice nel servizio (come dichiarato nel negozio) è tutta spazzatura.
Il cliente dovrebbe ottenere un programma funzionante, non un programma funzionante fino al prossimo aggiornamento della build. Nessun esecutore si assicura che tutti gli ordini eseguiti siano compilati nell'ultima build.
Quindi perché complicare le cose, negoziare acquisti aggiuntivi e perfezionare il sistema di pagamento, se una semplice casella di controllo "Fonti" sull'applicazione risolve tutti i problemi prima della fase di negoziazione.
Quindi perché complicare le cose, negoziare acquisti aggiuntivi, perfezionare il sistema di pagamento, se una semplice casella di controllo "Fonti" nella domanda, risolve tutti i problemi ancora prima della fase di negoziazione. Questo risolve tutta la confusione e la perdita di tempo. E non sarete disturbati da qualcuno per il quale questo non è accettabile. Il fatto è che il mio sistema è troppo profondamente integrato con l'altro per mettere dei moduli separati. Nessun problema, posso naturalmente allegare il modulo del segnale (o quello dell'applicazione) al file ex. solo perché la logica di esecuzione sia chiara.
Solo per interesse, provate a descrivere qui il cliente lobotomizzato down-and-out che ha bisogno di questa zecca.
È il mercato, non importa quello che vuoi tu, non importa quello che vuole il cliente, tutto quello che conta è quello su cui siete d'accordo.
L'1% dei clienti cederebbe la casella di controllo se ordinasse uno script per un uso una tantum, ad esempio per raccogliere alcune statistiche sulla storia
quindi possono rispondere alla domanda solo una volta e dimenticare questa domanda e lo script.
Gli altri avranno bisogno del programma ordinato per molto tempo, in ogni caso, lo pensano certamente.
E poi, qualsiasi servizio, qualsiasi negozio dovrebbe essere scandalosamente semplice, comprensibile, conveniente e affidabile con un numero minimo di clic
Alexei, considera che questa casella di controllo è già presente. Su tutti gli ordini.
Ecco fatto. Grazie a Dio siamo arrivati a qualcosa)). E anche sull'autocompilazione. Va bene, mi arrendo, non voglio discutere. Non ho molti sostenitori qui. Forse più tardi la vita mi farà tornare su questo argomento. Dopo tutto, non sempre il cliente ottiene il codice sorgente, specialmente se lo si guarda non in termini di mql, ma di sviluppo del software in generale...
Grazie a tutti per la discussione.
Integer:
Tutti hanno il diritto di sbagliare. La ragione è indicata in precedenza.
Ogni Ivan Susanin ha il diritto di sbagliare, ogni ingegnere ha il diritto di sbagliare, ogni cecchino ha il diritto di mancare, ogni pilota o autista ha il diritto di schiantarsi, ogni venditore ha il diritto di far pagare troppo il suo cliente, ogni elettricista ha il diritto di misurare la tensione, ogni commerciante ha il diritto di essere colmargin. In qualche modo il diritto di sbagliare sembra assurdo.
Commento su quanto evidenziato: con questo approccio si ha una grande opportunità di riflettere sul postulato "Ogni giudice ha il diritto di sbagliare". E poi applica questo postulato alla tua esperienza di vita.
E se tieni conto che ognuno di noi svolge periodicamente il ruolo di giudice nella soluzione dei suoi problemi, avrai una buona occasione per assicurarti che nel "mio caso" (intendo nel tuo) il postulato sembra assurdo :) o quasi :)
Centinaia di persone sono congelate in un torpore fino a quando non si risolve la questione dei diritti poco chiari su cose poco chiare . E solo il bot genera ordini virtuali e la loro esecuzione nel servizio "Jobs".
Qual è il problema di ammettere l'ovvio?
Non ho molti sostenitori qui. Forse la vita mi riporterà a questo argomento più tardi.
Non si tratta del numero di sostenitori. Si può essere uno contro tutti e avere comunque ragione.
I punti essenziali sollevati nel tuo thread sono stati discussi. Le soluzioni alla situazione sono state discusse. E le provocazioni - quante di loro saranno sul nostro ... modo! :)
Grazie a tutti per la discussione.
Non ho potuto fare a meno di commentare :)
Non è una questione di numero di sostenitori. Si può essere uno contro tutti e avere comunque ragione.
I punti essenziali sollevati nel tuo thread sono stati discussi. Le soluzioni alla situazione sono state discusse. E le provocazioni - quante di loro saranno sul nostro ... modo! :)
Non potevo trattenermi dal commentare :)