La (non) conservazione della quantità di moto

In questi giorni ho portato le classi in laboratorio per verificare con la rotaia a cuscino d'aria che la quantità di moto negli urti si conserva.
L'esperienza più semplice è quella dell'urto di due carrelli di massa uguale di cui uno fermo: se dopo l'urto i carrelli rimangono incastrati, DOVREBBERO procedere a velocità dimezzata rispetto a quella del carrello urtante.
Vediamo:

A prima vista le cose vanno proprio così, nel senso che la velocità diminuisce bruscamente dopo l'urto.
L'analisi del moto con Tracker, però, ci riserva sorprese.....

È evidente che prima del'urto il moto era uniforme (quindi niente attriti) e anche dopo l'urto era uniforme (quindi niente attriti); la velocità, però, non si è dimezzata come avrebbe previsto la legge di conservazione della quantità di moto in assenza di forze esterne!
Per capire quale può essere la ragione di tale "fallimento" vediamo al rallentatore e con un po' di zoom il momento dell'urto analizzato con Tracker: guardando bene noterete che al momento del contatto i due carrelli per un attimo si piegano (per vedere bene è necessario mandare il video a schermo intero)

Nel momento della "piega" la rotaia non riesce a sostenere i due carrelli, sui quali dunque - per breve tempo - agisce la forza di attrito che modifica la quantità di moto:

Cambiare sfondo all'alba e al tramonto

Nel sito Plone della mia scuola lo sfondo è diverso a seconda dell'ora in cui lo si visita, come si può desumere dalla immagine che segue:

Come si può ottenere questo risultato?
Non è troppo complicato, si lavora con i CSS e con un piccolo script Python.
Iniziamo dal CSS:

Il CSS è inserito nella cartella portal_styles/custom della ZMI e sfrutta la sintassi "&dtml" per lanciare due script.
Con le righe:
background: #A3C3E5 url(&dtml-cambia_sfondo;) repeat-x scroll 0 0;
color: &dtml-cambia_colore;;
il CSS imposta sfondo e colore tramite gli script Python "cambia_sfondo" e "cambia_colore" che si occupano materialmente di capire che giorno è, che ora  è e del conseguente settaggio di sfondo e colore.

Il CSS va registrato in portal_css e bisogna disattivare il caching:

Veniamo ora agli script Python per il cambio si sfondo e colore analizzandone uno, quello del cambio dello sfondo.

Lo script è molto grezzo e sfrutta appieno la mia poca conscenza nel gestire date e ore nel Python ristretto concesso agli script che dimorano nella ZMI.

# QUESTO CODICE PER IL CALCOLO DI ALBA E TRAMONTO
# È ISPIRATO DA INTRODUZIONE AL CALCOLO ASTRONOMICO
# DI COSTANTINO SIGISMONDI QUADERNI DI STUDIO 2007
# ISPEF ROMA GEOASTROLAB UNIVERSITÀ EUROPEA DI ROMA
import math
dNow = DateTime()
giorno = dNow.day()
mese =dNow.month()
ora_legale = 0
if mese >=4 and mese<= 10:
  ora_legale=1;
giorni_da_equinozio=giorno+30*mese-(21+30*3)
omega=6.28/365.25
lamb=45*3.14/180
delt=23.5*3.14/180*math.sin(omega*giorni_da_equinozio)
durata=math.asin(math.tan(lamb)*math.tan(delt))*180/3.14*2/15+12
alba=int(round(12-durata/2))+ora_legale
tramonto=int(round(12+durata/2))+ora_legale
tNow = dNow.hour()
if tNow>= alba and tNow <= tramonto:
    print "sfumatura_2.png"
else:
    print "cielo_stellato.png"
return printed

Ecco cosa fa lo script:

• prende dal server la data e l'ora della navigazione
• legge nella variabile "lamb" la latitudine del luogo del sito e la converte in radianti
• converte la data in giorni dall'equinozio di primavera
• calcola la durata delle ore di luce usando le indicazioni di Costantino Sigismondi
• calcola l'ora dell'alba e del tramonto per quel giorno
• se l'ora di navigazione è compresa tra l'alba e il tramonto applica lo sfondo "sfumatura2.png" (sfondo per il giorno) altrimenti applica lo sfondo "cielo_stellato.png" (sfondo per la notte).

Lo script adatta l'ora dell'alba e del tramonto ai diversi periodi dell'anno, anticipando il tramonto durante l'inverno e così lo sfondo del sito sembra seguire il ciclo delle stagioni....
L'adattamento è grezzo e approssimato all'ora intera. Il testing è ancora in corso.

Ricerca avanzata di Plone

Durante la riunione di dipartimento TIC di oggi, è emerso che il motore di ricerca interno del sito scolastico talvolta restituisce risultati poco interessanti.
Ho voluto dunque mettere alla prova il motore di Plone cercando la parola chiave "Cavagna"

Da quanto ho capito il motore di Plone non ha nulla che non va, anzi!
Poichè Plone è in grado di "leggere" anche dentro i documenti Word e PDF che vengono caricati, può succedere che, per diversi motivi, questi "scavalchino" per rilevanza quello che intendiamo cercare.
Fortunatamente ci viene in aiuto la "ricerca avanzata" di Plone, che permette di limitare in vario modo la ricerca, per esempio limitandosi al titolo:
in questo modo la ricerca diventa davvero efficace.

La biro

Non mi capita spesso, eppure oggi è successo: ho ricevuto un regalo. La mia 4T, forse stanca di sentirsi chiedere la biro nera per firmare il registro mi ha regalato una splendida penna a 4 colori. Che dire.... mi ha fatto piacere!

Ridatemi le maniglie!

Plone usa un comodo sistema "Drag and drop" per riordinare i files all'interno delle cartelle: basta trascinare gli elementi prendendoli per le "maniglie" ed il gioco è fatto.

Se il javascript non è attivo, le maniglie vengono sostituite da (scomodi) link a forma di frecce.
Per non so quale motivo lo script "Drag and Drop" ha smesso di funzionare nel mio sito scolastico, e la cosa si ripercuote per tutti i siti che ne condividono la stessa base Zope.

Un illuminante post di Sauzher (leggi il thread) mi ha spiegato come uscirne, ma il metodo non è banale e, dovendo esportare/reimpostare uno ZEXP, immagino che perderò le info sugli utenti ed i permessi.
AGGIORNAMENTI
1) Ho cancellato portal_javascript ed importato lo zexp di un portal_javascript (pari prodotti installati) generato da sito pulito ove drag and drop funziona: non ha risolto il problema.

2) Al Plone migrato manca plone.app.discussion: il workaround per ripristinarlo non funziona. Ecco l'errore:

Traceback (innermost last):
  Module ZPublisher.Publish, line 126, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 46, in call_object
  Module Products.GenericSetup.tool, line 514, in manage_importAllSteps
  Module Products.GenericSetup.tool, line 323, in runAllImportStepsFromProfile
   - __traceback_info__: profile-plone.app.discussion:default
  Module Products.GenericSetup.tool, line 1084, in _runImportStepsFromContext
  Module Products.GenericSetup.tool, line 998, in _doRunImportStep
   - __traceback_info__: toolset
  Module Products.GenericSetup.tool, line 123, in importToolset
TypeError: 'NoneType' object is not callable

3) Si prospetta la migrazione del sito scolastico ad un Plone 4.1.3 pulito. Ho provato ad esportare alcune cartelle in formato ZEXP ed ho notato che l'importazione avviene correttamente e che i contenuti BLOB vengono creati regolarmente. Quindi potrò migrare ma... poi dovrò sistemare A MANO tutti i permessi delle cartelle, le condivisioni, dovrò creare gli utenti....Mah!

4) La migrazione cartella per cartella l'ho fatta. Ho scoperto che l'errore per il javascript del drag and drop era dovuto all'attributo data-rel eliminato per avere la codifica xhtml strict (vedi)

/usr/local/Plone/buildout-cache/eggs/Products.ResourceRegistries-2.0.6-py2.6.egg/Products/ResourceRegistries/browser/kss.pt

  La migrazione cartella per cartella ha comunque sistemato anche la mancanza di plone.app.discussion.

Viva i backup!

Ieri i bidelli hanno pulito l'aula server, avventurandosi fin dietro lo scaffale.
Questo evento ha avuto un bel po' di effetti collaterali, tra i quali quello di "rovinarmi" un pomeriggio...
Nel pulire, infatti, hanno staccato l'alimentazione del gruppo di continuità: le batterie si sono quasi scaricate e i server automaticamente si sono spenti, proprio come deve essere.
Avendo appurato che l'energia elettrica da rete era presente e non avendo notato l'alimentazione staccata abbiamo riacceso i server, che durante il riavvio hanno prosciugato la carica residua delle batterie e dunque si sono spenti in malo modo in fase di boot!
Ahi, ahi, ahi!
ESXI è ripartito regolarmente e, all'apparenza, anche i 3 server virtuali, eppure... non funzionava nulla!
In pratica il server virtuale del firewall risultava funzionante ma senza alcuna scheda di rete installata per cui... è come se non ci fosse stato: mai successa una cosa del genere!
Dopo un'ora di tentativi per sistemare le cose, mi son deciso a ripristinare l'immagine del server virtuale firewall di maggio 2011: 60 minuti 60 per copiare 10 Gigabytes!!!
Con l'immagine dello scorso anno il server virtuale del firewall è partito liscio liscio e, sistemate al volo un paio di configurazioni, i server della scuola sono di nuovo "up and running": tutto è bene quel che finisce bene e.... viva i backup!

Aggiornamento sito scolastico a Plone 4.1.3

Dopo qualche giorno di test è finalmente in linea il sito scolastico con la nuova versione di Plone.
Apparentemente il sito non cambia carrozzeria, ma il motore si....