Second Life è morta o moribonda, o almeno ha avuto un incidente grave

No, non è per niente vero, ma dire che Second Life è morta sembra essere trendy, così lo dico anche io e divento cool. Ancora oggi alcuni giornalisti (?) si esibiscono in funamboliche e fantasiose ricostruzioni di una Second Life che sarebbe “Un horror fantascientifico, uno scenario agghiacciante”, e così via di banalità in banalità.
Ih, quanto patos. Però sarebbe meglio almeno documentarsi un pochino prima di scrivere stupidaggini simili.
In realtà, SL sta benissimo e non è mai stata così bene proprio perché chi aveva pensato di specularci biecamente se n’è andato, meno male, e probabilmente ora (seguendo i consigli dello stesso ufficio marketing Web 2.0 arrembante) sarà su Facebook, riuscendo a buttare via soldi anche lì.
Giusto per capirci, il grafico rappresenta l’andamento delle iscrizioni da novembre 2010 a maggio 2011.
Ci vuole un bel coraggio a dichiarare che SL è morta… Per chi è interessato ai dati reali, molti grafici sono disponibili sul blog di Tateru Nino. Certo che per essere morta SL è bella viva. Un po’ come XHTML

Archiviato in Second Life | Commenti (0)

Second Life e i misteri del BackgroundYieldTime (ovvero, migliorare il multitasking)

Tutti i client per Second Life sono avidi di risorse. Se va bene, stando seduti in qualche posto facendo nulla porta via 350 mega di ram e 30/40% di CPU. È facile da verificare, basta dare un’occhiata a Gestione attività di Windows ((Ctrl+Maius+Esc in Win 7).

Si apre un altro programma e sboink, il sistema appare bloccato, ovviamente. È una situazione molto comune, e il problema è che anche passando ad un altra finestra l’occupazione di risorse rimane elevata. Se vi capita spesso di usare Second Life in combinazione a qualche altro programma, sapete bene di cosa sto parlando.

Però, un parametro di Debug Settings permette di migliorare questo comportamento: BackgroundYieldTime serve a determinare con che intervallo in millisecondi generare nuovi frame quando il client non è in primo piano.

Il valore di default è 40, provate a impostare BackgroundYieldTime a 500 e notate la differenza in Gestione attività: dal 55% di CPU al 10% nella stessa identica situazione non è male (ed è attivo anche lo streaming audio)! E d’altra parte, a che vi serve avere un framerate di 80 fps se non state facendo nulla in SL? Perché sì, SL si sta ciucciando anche la vostra GPU…

Ovviamente la vostra CPU e gli altri programmi in esecuzione ringrazieranno sentitamente.

Archiviato in Second Life | Commenti (2)

Moduli PDF: validare i campi obbligatori, che passione

In moduli complessi è necessario prevedere un meccanismo di validazione degli inserimenti dati effettuati dall’utente nei campi obbligatori.

LiveCycle Designer e Acrobat per i moduli prevedono una gestione di questa problematica via JavaScript o FormCalc, con una abbastanza complessa procedura di validazione di pattern non sempre chiara.

Però, se non è necessario effettuare una vera e propria convalida del pattern di validazione a partire da LiveCycle Designer 8.02 in sù è disponibile un semplice check di compilazione che richiede soltanto l’inserimento di una riga nel codice XML del modulo.

1. Create il campo di testo obbligatorio nel modulo con i normali strumenti di LiveCycle, definendone se necessario la lunghezza in caratteri e nella scheda Valore selezionate la voce Inserito dall’utente – Richiesto nell’elenco a discesa Tipo per rendere la compilazione del campo obbligatoria.
2. Passate alla vista XML del modulo selezionando Visualizza > Sorgente XML.
3. Individuate nel codice le righe
   <present>
<!-- [0..n] -->
4. All’interno dell’elemento <present> potete aggiungere le seguenti condizioni di <validate>:
   prePrint
   preSave
   preSubmit
   preExecute
   Anche combinate.
5. Per esempio, per fare in modo che venga effettuata una verifica sui campi obbligatori al momento del salvataggio, aggiungete
   <validate>preSave</validate>

Il codice risultante sarà:

<config xmlns="http://www.xfa.org/schema/xci/1.0/">
<agent name="designer">
...
</agent>
<present>
<!-- [0..n] -->
<validate>preSave</validate>

…

Le condizioni possono essere combinate, se desiderate che il check venga eseguito prima della stampa aggiungete al modulo un pulsante Print, e così via.

Il codice

<validate>prePrint preSubmit</validate>

Produrrà una azione di verifica al momento della stampa o dell’invio per e-mail del modulo.

Nell’esempio, al momento del salvataggio del modulo compilato verrà eseguito un controllo e se il campo obbligatorio non è stato compilato comparirà un messaggio di errore e nel modulo i campi non corretti saranno evidenziati in rosso.
Con LiveCycle Designer ES2 (distribuito con Acrobat X), è possibile personalizzare la modalità di presentazione degli errori, selezionando in una lista l’opzione preferita:

• Show Every Message In Its Own Message Box One After The Other.
• Combine The Messages Of All The Failed Fields Into One Message Box.
• Show the First Failed Field’s Message And Suppress Any Other Messages

Archiviato in PDF | Commenti (0)