Il fallimento dei click day: una questione culturale, non tecnologica

Un limite deve per forza esserci. Gli stanziamenti vanno approvati [U]prima[/U], altrimenti rischia di diventare una cifra assurda.

Non stiamo parlando di assegni familiari, che sono un tantino più importanti. Per queste cose è normale che ci siano bonus ad esaurimento. Se non accedi al bonus bici o monopattino si campa lo stesso. Lo scopo è trainare il mercato, non che ce l'abbiano tutti.

È un sistema ridicolo che ha lasciato tantissime persone che avevano già fatto degli acquisti senza rimborso perché altre, che ancora non hanno acquistato niente, hanno fatto richiesta del bonus per un acquisto futuro.
Vero che in teoria fra 30 giorni i soldi non spesi torneranno disponibili.. ma si farà un altro click day?

Senza contare quanto già detto sui tempi di attesa e del crash dello SPID di Poste.

probabilmente nel mucchio si sono infilate anche migliaia di persone che volevano il voucher per un futuro acquisto, che poi magari si rivendono a qualcun altro per monetizzarlo. Bagarini digitali insomma, come già successo in altri contesti peraltro

condivido in pieno l'articolo.
si voleva utilizzare una coda -> perchè non gestirla tramite l'invio di una pec?
si voleva dare un rimborso? perchè non inserire la spesa sostenuta tra le deduzioni del 730?
e son solo due esempi. da qualche anno lo stato ha incrociato tutti i database, quindi per gestire un qualsiasi cosa che ci riguarda, basterebbe (lato nostro) fornire il codice fiscale....

Il click day favorisce automaticamente chi ha il pc più performante e la connessione più veloce, basterebbe questo per renderli tutti illegittimi



caschi male fra....



Ti sei risposto da solo, i siti vanno in down sistematicamente perché con questi sistemi attirano mille volte l'utenza per cui sono stati progettati
il dirigente INPS che millantava attacchi hacker si merita gli schiaffi

I problemi di indisponibilità del sito sono cominciati ben prima che si manifestassero problemi con gli IDP SPID, questo è stato riportato da più fonti.

Senza offesa per l'autore ma a me l'articolo pare un'accozzaglia di luoghi comuni e di slogan che sentiamo ovunque (innovazione, digitalizzazione, rivoluzione digitale, bla bla bla...).

Anzitutto sostiene una tesi (il modello del click day è sbagliato) senza nemmeno argomentare perchè...
Perchè è vecchio? Quindi?
Perchè si basa su presupposti sbagliati? Quali?
Perchè è frutto di una cultura immobile? Eh?!?!?

Si potrebbe accusare di essere iniquo perchè aperto a tutti a prescindere dalla condizione economica, si potrebbe accusare di essere assurdo perchè tecnicamente insostenibile, invece l'articolo "pedala nello yogurt" con slogan che non dicono nulla e non stimolano ne la discussione ne la riflessione.

Passando a questioni tecniche, che fosse un modello assurdo e difficile da sostenere tecnicamente lo si sapeva ed era palese a chiunque masticasse un minimo di IT.
Tirare in ballo cloud, container e scalabilità in questi casi viene quasi automatico, peccato che di solito lo faccia chi non ha idea del livello di complessità di base delle applicazioni, e infatti sono parole sempre in bocca a personaggetti come manager e venditori di fumo (spesso le due figure coincidono), i quali, proprio perchè incapaci di entrare nel merito tecnico dei problemi e della loro complessità, ragionano sempre e solo in termini quantitativi (quante risorse, quante giornate, quanti nodi, etc etc etc...).

Personalmente mi sono trovato in condizioni di ideare servizi del genere (con una platea inferiore ma pur sempre consistente, circa 1,5 milioni di utenti) per l'attribuzione di buoni per il trasporto pubblico, anche in questo caso la logica era "chi prima arriva meglio alloggia". **

Il problema tecnico c'è stato, ma più che sui singoli strumenti il problema è stato sostanzialmente di logica applicativa, ovvero non aver disaccoppiato il processo nelle sue due fasi essenziali:
[LIST]
[*] prenotazione del posto
[*] presentazione della domanda
[/LIST]

Mantenere unite queste due fasi in un unico processo è una follia per alcuni semplici motivi:
[LIST]
[*]la prima (prenotazione) non ha bisogno della seconda (presentazione domanda).
[*]la prima (prenotazione) può essere fatta in anonimo, per la seconda (presentazione domanda) l'utente dev'essere necessariamente profilato e quindi presuppone una autenticazione
[*]la finestra operativa della prima (prenotazione) per definizione è estremamente breve (chi prima arriva meglio alloggia appunto), quella della seconda (presentazione domanda) può essere molto ampia e "spalmata" nel tempo (es 1 mese).
[*]la prima (prenotazione) ha una logica applicativa estremamente semplice e leggera (sostanzialmente il submit di una form che scatena la insert su un database), la seconda (presentazione domanda) ha una logica applicativa complessa, spesso con attività pesanti dal pdv computazionale e/o interazioni con servizi di terze parti (es interrogazione web services di altri enti)
[/LIST]

Pensare di accorpare entrambi in un unico processo è una follia, anzitutto nessuno può ragionare a risorse "infinite" (altra panzana spesso spacciata da manager e i guru dell'innovazione) perchè anche ammettendo una scalabilità ottima le risorse economiche di cui si dispone sono limitate per definizione, e scalare un servizio non serve a nulla se non scalano altrettanto quelli da cui dipende (che essendo di terze parti non dipendono da chi progetta il servizio iniziale).

** = per chi se lo chiedesse il servizio ha retto benissimo l'assalto seguendo le linee guida che ho descritto, tutto il processo di prenotazione ha girato su una singola macchina GNU/Linux (hw del 2007) con una form in php (5.6 con MPM prefork, non certo il top in termini di prestazioni, parliamo cmq di qualche anno fa) e un singolo dbms MySQL, carico rilevabile a livello strumentale ma tutt'altro che preoccupante o percepibile dagli utenti.
Per assurdo abbiamo avuto più problemi di carico durante la seconda fase, in quanto deployata su un portale pieno zeppo di portlet e eccezioni non gestite a non finire... ma questo è un altro discorso

Articolo noioso e inconsistente; non se la prenda l'autore (questo è solo il mio parere) ma leggendolo mi sembrava di ascoltare il nostro commerciale, un lunghissimo bla bla bla bla bla di luoghi comuni e alla fine il nulla. Su una cosa però concordo: nel nostro paese ci vuole un cambio culturale, anche da parte di chi scrive articoli su giornali e magazine (soprattutto se non generalisti ma tecnici).


Ma certo, nessun limite e bonus per tutti... a proposito, paghi tu?


Veramente io ho fatto tutto con un pc vecchiotto (originariamente c'era Vista, fai un po' tu i conti) e l'ADSL da 12 mega della TIM.

Noto con molto dispiacere che l'unico ad aver capito l'articolo sia stato cronos1990. Non mi infastidisce chi dice che il pezzo è una sequela di luoghi comuni: dopotutto sono le stesse persone che sostengono che il modello usato vada bene così. Purtroppo i commenti non fanno che confermare che quanto ho scritto è corretto, ed è abbastanza sconfortante.
Ho criticato il concetto stesso di "click day" affermando che servano altri modelli, come ad esempio quello adottato in Francia che prevede la creazione di un codice da parte del venditore all'atto della vendita, ma la risposta di praticamente tutti quelli che hanno commentato è che il sito è andato bene ed è colpa di SPID se il "click day" è stato un fallimento. Mi sembra il classico caso di chi guarda il dito anziché la Luna.
A Tasslehoff rispondo che c'è scritto chiaro e tondo che il modello non è sostenibile per limitazioni tecniche e per il fatto che chiede ai cittadini di mettersi in coda con modalità assolutamente assurde, anziché sfruttare il fatto che si sta operando nel dominio digitale, ma capisco anche che faccia più comodo dire che è l'articolista che non argomenta. La responsabilità, tanto, è sempre degli altri.

verissimo. lo vedo quasi ogni giorno in 1000 cose.

è la "finta digitalizzazione", per es il pdf del foglio firmato scansionato, che poi magari viene e ulteriormente firmato digitalmente ed infine stampato e archiviato