Mercato: come saranno gestite le situazioni di fallimento del prodotto dopo un aggiornamento della build? - pagina 2
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
Disabilitare l'auto-refresh è un po' un controsenso.
Disabile - e allora? Stiamo aspettando il feedback che tutto funzioni nella nuova build?
Il rollback, in linea di principio, è un'opzione, ma di nuovo, questo deve venire dal lato server.
Questa è l'unica opzione/offerta al momento. E non è il più conveniente/migliore.
Quindi il mio sospetto è confermato. In base a questa particolare"opzione", sembra che sia il venditore ad assumere il ruolo di capro espiatorio. - Bene, hai messo i puntini sulle "i" e i trattini sulle "t".
Sulla "unicità" dell'opzione è discutibile. Il modo più elementare è quando il venditore scriverà a grandi lettere nella pubblicità del suo prodotto qualcosa del genere: "Il venditore non è responsabile del funzionamento del prodotto su build rilasciate dopo la data così e così".
Quindi il mio sospetto è confermato. In base a questa particolare"opzione", sembra che sia il venditore ad assumere il ruolo di capro espiatorio. - Bene, hai messo i puntini sulle "i" e i trattini sulle "t".
Sulla "unicità" dell'opzione è discutibile. Il modo più elementare è quando il venditore scriverà a grandi lettere nella pubblicità del suo prodotto qualcosa del genere: "Il venditore non si assume alcuna responsabilità per il funzionamento del prodotto su costruzioni rilasciate dopo la data".
E chi comprerebbe qualcosa da un tale venditore?
Sei venuto al mercato, e lì sulla tenda , "Arshin lettere scritte, io non sono responsabile di nulla", anche se in realtà, anche ora (al momento il venditore non è responsabile per il fatto che il suo gatto prosciugato, o meglio responsabile solo indirettamente, attraverso recensioni negative e una diminuzione delle vendite), ma se si scrive come uno slogan, allora non si può vendere nulla a tutti.
Sei venuto al mercato, e sulla tenda c'è "in lettere russe, non sono responsabile di nulla", anche se in realtà, anche ora (come al momento, il venditore è responsabile del fatto che i suoi gufi precipitano? no, piuttosto, solo indirettamente, attraverso recensioni negative e una diminuzione delle vendite), ma se lo scrivi come uno slogan, allora non venderai mai nulla.
Non generalizzare :) "Non responsabile di nulla" e "non responsabile di certe cose" sono due grandi differenze. Il venditore è responsabile delle prestazioni del prodotto al momento della vendita e non può prevedere i futuri bug del terminale.
Non sosterresti che se la tensione salta di 5-6 volte, causando danni al computer, il venditore del computer dovrebbe essere ancora responsabile?
Tuttavia, se un particolare venditore, responsabile solo per se stesso e non per tutti gli altri, si prende tutta la responsabilità - la bandiera nelle sue mani, come si dice :) Qui sono d'accordo :)
Disabilitare l'auto-refresh è un po' un controsenso.
Disabile - e allora? Aspettando un feedback che tutto funzioni nella nuova build? ....
Quindi il mio sospetto è confermato. In base a questa particolare"opzione", sembra che sia il venditore ad assumere il ruolo di capro espiatorio. - Bene, hai messo i puntini sulle "i" e i trattini sulle "t".
Sulla "unicità" dell'opzione è discutibile. Il modo più elementare è quando il venditore scriverà a caratteri cubitali nella pubblicità del suo prodotto qualcosa del genere: "Il venditore non si assume alcuna responsabilità per il funzionamento del prodotto su build rilasciate dopo questa data".
Hai frainteso l'"unicità" della versione. Era l'unico all'epoca in cui ne ho scritto. Ora c'è già una versione modificata e anche altre varianti. Il treno della "singolarità" è già partito. :)
E non posso chiamare il venditore "capro espiatorio" in questo caso. Questo si riferisce al supporto del prodotto. Il lavoro continua anche dopo che il prodotto è stato immesso sul mercato. E non ci vorrà molto per verificare la sua funzionalità sulla nuova build. Ma la correzione della build in caso di un bug che causa il malfunzionamento del prodotto o di alcune delle sue funzioni può richiedere da una settimana a un mese. In questo caso, non è necessario spiegare all'utente che il bug non è nel programma che ha comprato e abbiamo bisogno di qualcosa che sia ottimale per tutte le parti.
Non generalizzare :) "Non responsabile di nulla" e "non responsabile di certe cose" sono due grandi differenze. Il venditore è responsabile delle prestazioni del prodotto al momento della vendita e non può prevedere i futuri bug del terminale.
Non sosterresti che se la tensione salta 5-6 volte nella rete, causando danni al computer, il venditore del computer dovrebbe essere ancora responsabile?
Tuttavia, se un particolare venditore, responsabile solo per se stesso e non per tutti gli altri, si prende tutta la responsabilità - gli vola in faccia, come si dice :) Qui sono d'accordo :)
Vi ho dato un esempio di ciò che l'acquirente leggerà se la frase contiene le parole NON RESPONSABILE.
Per sicurezza, lasciate che vi ricordi che la percezione umana è selettiva. È un fatto noto della cinematografia: se il film non ha interessato lo spettatore nei primi 20 minuti, oltre ci può essere qualsiasi cosa, qualsiasi trucco sconcertante e in generale una bellezza celestiale, ma il cinema è già vuoto, non c'è nessuno che apprezzi questa bellezza.
Lo stesso vale per le vendite, la marca conosciuta nel nostro paese Zhiguli, in Italia ha dovuto essere rinominata Lada, perché ricorda molto Gigolo, bene, che tipo di vendite ci possono essere se l'acquirente arriva, e gli viene offerta "un'auto moderna molto cool" con il nome Gigolo :) poi come cavalcarlo che? Mi immagino le esclamazioni entusiaste degli italiani che dicono "Guarda, guarda, un gigolò!)
Disabilitare l'auto-refresh è un po' un controsenso.
La possibilità di disabilitare l'auto-aggiornamento contraddice il concetto di prodotto olistico, quindi non ha senso considerare una tale possibilità anche teoricamente.
Tuttavia, il concetto di integrità non è in contrasto con l'avere una funzione di backup di rollback. Aggiorniamo, vediamo che la nuova versione del programma non funziona, torniamo alla vecchia build.
La possibilità di disabilitare l'aggiornamento automatico è contraria al concetto di prodotto olistico, quindi non ha senso considerare anche solo teoricamente una tale possibilità.
+1
Se questo è il concetto, non ha senso agitare le mani in aria.
La possibilità di disabilitare l'auto-refresh è contraria al concetto di prodotto olistico, quindi non ha senso considerare una tale possibilità anche teoricamente.
Tuttavia, il concetto di integrità non è contraddetto dalla funzione di backup. Aggiorniamo, il programma smette di funzionare nella nuova versione, torniamo alla vecchia build.
Come funzionerà? Roll back, run - non disabilitare l'auto-update riporta tutto all'ultima build? Se non l'ha fatto, allora dovrebbe essere disattivato dopo tutto.