Cogestione 2026 — seat-tracking

contesto

La cogestione scolastica richiede di raccogliere iscrizioni per decine di attività in parallelo, ognuna con un numero limitato di posti. Lo strumento storico — un foglio Google condiviso — finiva inevitabilmente in overbooking: decine di studenti che aprivano la stessa cella nello stesso istante, last-write-wins.

Serviva un meccanismo che garantisse consistenza senza rompere il workflow già noto ai ragazzi: form di Google, niente app da installare, niente account esterni.

approccio

Frontend: Google Form con domande dinamiche — una lista di attività popolata dal foglio, aggiornata via Apps Script prima di ogni sessione di iscrizione.
Backend: trigger onFormSubmit su uno spreadsheet contenitore. Il gestore esegue la verifica di capienza e la scrittura in maniera atomica.
Concurrency safety: ogni submit acquisisce un document-lock via LockService.getDocumentLock() con timeout 30s. All'interno della sezione critica: lettura del conteggio posti corrente, confronto con capacità, scrittura della riga o rifiuto con email al mittente.
Presenze: al cutoff delle iscrizioni uno script genera automaticamente i fogli presenze per i moderatori — una tab per attività, partecipanti ordinati, celle pronte per la firma.
Monitoring: log di ogni submit (accettato o rifiutato) con timestamp e causale, utile per il debrief post-evento.

outcome

Zero overbooking nel giorno di apertura delle iscrizioni.
Fogli presenze pronti automaticamente, senza lavoro manuale dei coordinatori.
Aggiungi qui: numero totale di studenti iscritti, picco di submit concorrenti nel primo minuto, tempo medio di risposta del trigger, eventuale confronto con l'edizione precedente.

constraints

Apps Script ha quote rigide: runtime massimo di 6 minuti per esecuzione, limiti giornalieri su trigger e invio email. Il gestore è stato progettato per chiudersi in <2 secondi anche sotto carico, delegando la generazione dei fogli presenze a un trigger schedulato separato.

Autenticazione limitata all'account Google: sufficiente per il contesto scolastico (tutti hanno un account istituzionale) ma non generalizzabile a contesti aperti al pubblico.

Se hai incontrato un limite specifico di Apps Script che ha richiesto un workaround (es. timeout del LockService, fallimento silenzioso di un trigger, race condition residua), raccontalo qui.

lezioni

LockService è l'unico primitive di Apps Script che permette davvero di costruire flussi multi-utente consistency-safe. Senza, ogni submit vive nel suo mondo.
I trigger di Apps Script possono essere ri-eseguiti silenziosamente dal runtime (retry interno). I gestori vanno scritti idempotenti — scrivere due volte la stessa iscrizione è peggio che non scriverla affatto.
Tenere la logica fuori dal form e dentro lo script separa il UI dal dominio: quando le regole cambiano, cambia solo lo script.
Aggiungi una lezione tua — magari qualcosa sul dialogo con gli insegnanti, sul deploy il giorno dell'evento, o sul debrief.