Giochiamo

Second Life. Vita alternativa. Fuga dalla realtà. Realtà ricostruita. Nowhere place in cui abbiamo il coraggio di rischiare, perchè non perdiamo nulla. Nowhere man. Incontri. Giochi.
L'homo ludens ha bisogno di estraniarsi. Recupera tempo al lavoro e, al posto che spenderlo nella vita, gioca.
Un po' come me, con questo blog, quanto sto giocando?
Avremmo ben altre cose più importanti da fare.
Esistono obiettivi assoluti e, invece, perdiamo tempo a giocare.

Siccome continuo ad essere adamantino nella mia ricerca di tali obiettivi e non mi lascio distrarre da nulla, non gioco mica, io.

Mi diverto di più a programmarli, i videogiochi.
Dopo il lavoro, per estraniarmi dall'informatica.

---

Da piccolino, correva l'anno (scolastico) 1982-1983, iniziai a programmare.
Seguii un corso, consigliato da un compagno di classe.
Ai tempi i PC non erano diffusi. Quasi non esistevano.
Infatti, io immaginavo di trovarmi di fronte ad una specie di armadio, con tante lucine colorate, bocche metalliche da cui doveva uscire un rotolo di carta, nastri che continuavano ad avvolgersi ininterrottamente.
Un po' come il computer di Spazio 1999 (mi piaceva, l'ho visto di recente, che tristezza...).

Invece no. Un VIC 20. 1,5K di RAM.
Un corso impostato molto bene: flow-chart fin dal primo giorno (e che altro volevate, con 1,5K? Più si sta lontani dal televisore - non monitor, televisore -, meno se ne vedono i limiti).

Alla fine ero convinto di saper programmare.
I miei cedettero e mi comprarono uno Spectrum (ma davvero, chiesi ai miei insegnanti, può arrivare a 48K? Con 8 colori e con i suoni? E il controllo sul singolo pixel? Beh, se c'è scritto su Byte, sarà vero).

Cosa fa un ragazzino che sa programmare, con il suo nuovo PC? Si programma Pac-Man, ovviamente.
Scoprii che non sapevo programmare.
Ci persi dietro tutta l'estate, per imparare a farlo (beh, insomma...).
Ben prima della fine dell'estate il mio Pac-Man aveva 5 livelli e 1 fantasma che mi inseguiva con cattiveria inusitata (al livello 5 mi mangiava in 7 secondi, alla faccia della giocabilità).

Programmai anche un gioco di una rana che stava su una foglia e doveva cercare di saltare, mangiarsi gli insetti che passavano, senza essere divorata da un improbabile uccello (rappresentato da 3 asterischi, lo ricordo ancora) e senza cadere in acqua.

Tradussi un bellissimo gioco che trovai su un giornale (in inglese) scritto per lo ZX81.
Mi insegnò che si possono creare n stanze, completamente differenti ogni volta che si gioca, completamente identiche ogni volta che si entra e si esce all'interno della stessa partita, dovendo memorizzare un solo byte di informazione.
Il seed della funzione random, ovviamente.

L'anno dopo, per riuscire a programmare un videogioco di corse di automobili, con scrolling verticale della strada, fui costretto ad imparare l'assembler dello Z80.

L'anno dopo lessi il famoso testo di Hofstadter sull'AI e persi la testa (ma questa è un'altra storia).

Non ho mai smesso, però, di programmare videogiochi, per divertimento.

E solo perchè non mi lasciano farlo per lavoro: non avete idea di quanto mi piacerebbe poter essere responsabile di un progetto simile, della durata di 5 anni, con un team di 20 persone, con background culturali e talenti totalmente differenti.

E, marketing o non marketing, se funziona o no, se piace o no, lo si capisce.
Perchè la programmazione di videogiochi, ha dentro grandi complessità.
Enormi complessità logiche.
E' una sfida continua. (il fatto che la vincano sempre loro è un'altra questione).

Ovvio che, ancora oggi, sia interessato dalla notizia dell'uscita dalla beta di uno YouTube per i videogiochi, che si chiama Kongregate.
Ovvio che sia deluso: ma si può, accettare solo videogiochi in Flash? I primi in cui mi sono imbattuto avevano pure una grafica da sito.
Che tristezza.

Tanto per tanto, quasi mi divertirebbe di più partecipare alla comunità di GameMaker.
GameMaker, oggi arrivato alla versione 7, è un simpatico strumento, creato da un professore universitario (o dalle tesi dei suoi studenti?), che permette di sviluppare giochi semplici in modo semplice, senza programmare (seguendo un modello ad eventi e utilizzando delle iconcine, come comandi), e giochi più complessi programmando (ad oggetti, con qualche limitazione).
Ne esiste una versione free, con un po' di funzionalità disabilitate, ma con quelle abilitate si possono già fare cose serie.
E tra quelle abilitate ne troverete una che permette di postare il vostro gioco sul sito della community.

E' famoso, GameMaker. Mi ha fatto divertire, fin dalla versione 5. Se programmare con lui è un po' come giocare a Tetris, a me serve qualcosa di rapportabile ad Oblivion (per la mia rabbia enorme mi servono giganti avrebbe detto Cyrano - va beh, Oblivion forse è un po' troppo, non ho così tanto tempo libero da dedicare alla programmazione di videogiochi, ma spero abbiate capito il concetto).

Fortuna che c'è Java e, soprattutto, che c'è un altro professore, Andrew Davison, che ha pubblicato online le primissime versioni di un suo bellissimo libro: Killer Game Programming in Java.

Che inizia spiegando che è ora di piantarla di dire che serve per forza il C, per andar veloci.
Che scrive una appendice che spiega cosa cercare, quando si scava nella Garbage Collection.
Che prosegue spiegandovi tutto sui timer di Java (con fare universitario, quindi esagera pure).
Che vi porta a fare, passo passo, in nemmeno 12 capitoli, giochi in 2D, come applicazioni (full screen e windowed), applet e Java Web Start.
Con una pretesa di framework (termine un po' eccessivo, nel caso specifico), con musica, side scrolling, Sprite.
Fino ai giochi isometrici tile-based.
Il tutto condito con diagrammi UML, così se non sapete progettare e programmare, lo imparate (scherzo: se non sapete programmare e progettare non riuscite neppure a leggerlo, questo libro).

Per chi sopravvive ai primi capitoli (non dovrebbe essere impossibile), ce ne sono molti di più sulla programmazione con Java3D (con chicca sulla generazione di alberi che crescono).
Per chi regge anche questi (non è da tutti), ci sono i capitoli sui controlli di input non standard (dalla Webcam, al Gamepad, al controllo del braccio dell'omino del videogioco con il nostro braccio destro, al guanto per la realtà virtuale, che certamente avrete tutti a casa).
E poi, JOGL (wrapper attorno ad OpenGL), giochi in rete, J2ME, Bluetooth, Mobile3D.
Serve altro?

Consigliato a chi pensa di conoscere Java.
Me compreso.

Bye

Depa

P.S.: comunque potrebbe essere interessante mettersi a fare un framework che frulli assieme dei tool simil-GameMaker con le possibilità evidenziate dal testo di Davison...

[... continua ...] Leggi tutto

Soldi facili

E' un periodo che continuo ad inciampare in articoli che spiegano come far rendere economicamente un blog. C'è un tale Pavlina che sostiene di essere riuscito a monetizzare circa $4 al giorno dopo 6 mesi, $3000 al mese dopo 15 mesi e, in un crescendo wagneriano, fino a $1000 al giorno dopo 19 mesi.

Chi, come voi, mi segue assiduamente, sarà leggermente frastornato dopo le posizioni prese in Keep in Touch.
Il Depa, vi starete dicendo, dopo aver colto i veri valori della vita, sta decadendo verso argomenti vili e materiali.
Ancora domenica, insistete, parlava di religione e oggi cosa mi fa?
Non si possono seguire due padroni, no? Alla faccia della coerenza.

Calma, calma. Il grillo parlante ce l'ho già, nella mia testa, senza che vi mettiate in fila pure voi.
A spingere, pure.

Facciamo così: io, come al solito, scrivo, di seguito, il corpo di questo post.
Voi e la mia coscienza, se ne avete voglia, continuate a leggere e, se avete qualcosa da ribattere, scrivetela nei commenti, al posto che borbottare come fate sempre.

---

Se state leggendo queste righe vuol dire che le mie toccanti parole dell'abstract hanno fatto breccia nei vostri cuoricini. Lo si capisce perchè gli occhi sono lo specchio dell'anima e sulle vostre iridi vedo ancora stampata la scritta $1000 al giorno (al giorno va a capo, perchè non ci sta, su una sola riga, sull'occhio, ammesso che non siate cinesi).

Immagino che i più attenti di voi abbiano anche considerato che un blog è attivo per 365 giorni all'anno. Quelli più saggi avranno anche impostato la tara e, sapendo che nei weekend l'accesso è circa la metà rispetto ai giorni feriali (chi gestisce una azienda si tranquillizzi, ci sono dei picchi al mattino presto e prima e dopo il pasto, durante le altre ore lavorative è decisamente ridotto - va beh, qualche pausa caffè...), avranno calcolato che non è che sia poi così male un ricavo di $300.000 (trecentomila) circa, all'anno...

E come caspita si fa?

Beh, intanto, certo non con gli accessi che ho io al momento...

Poi, probabilmente, siccome è evidente che esisterà una qualche proporzionalità con il numero di unique visitor, sarebbe utile scrivere in inglese: facendo le dovute proporzioni tra lettori inglesi e italiani a quanti euro potrei puntare? Mi converrà rimettermi a studiare inglese (lo conosco e ho anche gestito progetti in inglese, ma certo non penserete che sia in grado di scrivere simili proposizioni ipotattiche anche in altre lingue, vero?) o contattare uno che mi traduca i post in inglese? Oppure basterà mettere su la traduzione automatica? (fermi tutti, di traduzioni parleremo in prossimi post, non distraetemi con altri argomenti...)

Cerchiamo di approfondire i possibili modelli di business e i calcoli reali, poi ci pensiamo...

Possibili ingressi:
- pubblicità (AD)
- affiliate
- richiesta di donazioni
- vendita di prodotti
- richieste di consulenza
- [c'è altro?...]

Piccola digressione sulla pubblicità: pare ci sia chi si lamenta, se sul blog compaiono gli AD. Ma stiamo scherzando? E che, a casa mia non posso fare quello che voglio? Non avete pensato a quanto sarebbe più piacevole la vostra lettura, se avessi il tempo di limare questi testi, al posto che scriverli in tutta fretta, offline, in treno? Non avete pensato che se avessi dei soldini da investire sul blog potrei fornirvi informazioni straordinarie, sia per il vostro business che per i vostri momenti liberi? Calmatevi, intanto non li ho ancora messi, poi continuate a leggere, che ne riparleremo...

Il nobiluomo citato nell'abstract si chiede se tutti sono in grado di guadagnare altrettanto, dai blog. Si risponde che non ci riesce il 99% dei blogger. La mette sul piano del ci riescono solo quelli che sono in gamba (usa smart, non ho voluto infierire, con la traduzione).

Pare, inoltre, che la condizione essenziale sia quella di capire i principali meccanismi del Web (leggeteveli, non ripeterò la lista).

Interessante che non si fermi a solo quelli più semplici, noti a quasi ogni Web Designer, ma vengano citati anche database e sistemi di pagamento on-line. Chissà quanti soldi potrebbe fare chi dovesse conoscere qualche modalità di utilizzo in più di Java e architetture multilayer basate su WS, Web 2.0 e Web semantico? In effetti, tutti gli autori in lingua inglese sembrano chiarire che più si sa dei mezzi a disposizione, più è facile fare soldi... a differenza di molti manager delle nostre aziende, che sono in grado di sostenere che conoscere la materia è notoriamente un impedimento al business, - non voglio addentrarmi in questo argomento, me lo lascio per un altro giorno, quando avrò voglia di tirare un po' di scherma.

Bisogna anche fare un piano. Di business o strategico. Un piano è qualcosa che sembra che tutti vogliono evitare, di recente (per esempio, provate a nominare questa parola ad un sostenitore dei metodi di produzione di software agyle... fermiamoci ancora, sembra che non riesca a fare a meno che fare un sommario di prossimi argomenti di post, oggi).
Eppure, per quanto sia facile che un piano fallisca, come diceva qualcuno che non ricordo, è sempre meglio avere un piano che non averlo.
Almeno si prende una direzione e si vede se la si sta seguendo o se si sta andando alla deriva. E poi si cerca di cambiare il piano ed adeguarlo.

Prima di redigere il nostro, partiamo dal traffico.
Il tipo che guadagna $1000 al giorno, dichiara anche di aver avuto, al mese 1,1 milioni di visitatori e 2,4 milioni di page views.
Ovvero, circa 1 dollaro ogni 1000 visitatori o ogni 2400 page view.
Al momento il mio sito riporta un po' più di 850 visitatori al mese, se riuscissi a farlo rendere in proporzione al suo (ma sicuramente renderebbe meno, perchè il suo è certamente ottimizzato), potrei già portare a casina circa un caffè senza brioche al mese. No, a ripensarci, ci dovrei pagare le tasse, mi resta una rotella di liquirizia (dimezzeranno anche i suoi 1000 dollaroni, come capiterebbe qui, in USA?)
Acc... bisognerà fare qualcosa per migliorare...

Per cercare di capire se possiamo migliorare, iniziamo a vedere se sono numeri sensati, in Italia.

Secondo Alexa (per quello che vale, lo sappiamo, certamente misura meglio siti USA, non misura tutto, etc. etc., ma è quanto di meglio abbiamo a disposizione free - fornitemi altri indirizzi, se ne conoscete), il sito di StevePavlina, a spanne, fa dalle 6 alle 12 volte le page view di Beppe Grillo (e dalle 12 alle 24 volte quelle di Pandemia e Macchianera).
Acc... bisognerà passare ad una traduzione all'inglese? Possiamo solo sperare in un massimo intorno ai 100 euro al giorno? (che poi sarebbero tagliati a 50 dalle solite tasse?) Perdiamo 900 dollari al giorno solo perchè non sappiamo l'inglese? Credo che, se dovesse crescere il traffico, converrebbe seguirlo, quel corso (costava meno di 900 dollari al giorno, o ricordo male?)

I dati di Pavlina sono compatibili con i CPC (Cost Per Click)? Beh, abbastanza. Se immaginiamo che ci siano 10 impression per pagina, considerato che un rapporto sensato tra click e impression potrebbe essere del 2%, potremmo calcolare, su 2,4 milioni di pagine, 24 milioni di impression, 480.000 click. I CPC (pagati a chi li eroga, non a chi ne ospita la pubblicazione sul proprio blog) variano tra 0,01 a 0,5 euro circa, secondo il link sopra riportato. Stiamo parlando di un range di 4800-24000 dollari al giorno (sempre per l'erogatore). Se un 20-25% viene pagato all'autore del blog, otteniamo circa i valori che dice Pavlina). Siccome credo che le percentuali siano inferiori, per bilanciare la differenza servirà ottenere il fatturato da modalità diverse dal solo advertising. Credo.

Qualcuno mi sa dare informazioni più precise?

Secondo Pavlina il fatturato è proporzionale al traffico. Ci tocca inventare modi diversi per guadagnare con il blog?
Acc... (dobbiamo sperare nella richiesta di consulenza?)

Comunque sia, per fare traffico e guadagnarci i nostri 50 euro al giorno netti (che sono sempre 15000 netti all'anno, che, se non bastano per arricchirsi e convincerci a lasciare il lavoro, comunque potrebbero aiutare), bisogna partire creando valore. Come per ogni tipologia di vendita.
Se aveste letto, per fare un esempio, Il libretto rosso del grande venditore di Jeffrey Gitomer, ne sareste convinti e, come sto facendo io, stareste cercando di cambiare la vostra figura professionale, da tecnicaccio puro a qualcosa di vicino ad un venditore o ad un uomo marketing, cercando di regalare valore. Perchè regalando valore si ottiene valore in cambio.
E' il solito libro fuffa per i soliti creduloni? Sarà, ma a me è riuscito a vendere l'idea e quasi me ne compravo un altro, se non avessi capito che, se già riuscissi a mettere in fila i suggerimenti di quello, sarebbe comunque un buon inizio.
E non è facile, sono proprio negato per farlo, non è nel mio DNA. Ma mi hanno detto che l'homo sapiens sapiens impara, quindi cercherò di continuare a sbatterci la testa fino a che non otterrò qualcosa o mi convincerò definitivamente di non riuscirci. Per ora sono ancora convinto che sia alla mia portata. Sono il solito presuntuoso.
E comunque mi sto divertendo.

In più, a quanto pare, le impostazioni di un grande venditore, sono fortemente improntate all'etica, e questo mi piace: non sopporto quelli che cercano di vendere fumo, ammiro chi sa valorizzare le cose di valore.

Tornando al valore, credo di poter raccontare qualcosa di utile. Un po' troppa roba per ogni articolo, ma se cercate bene, vedrete che troverete anche qualcosa che vi può servire. Come in soffitta.

Su, vediamo cosa ci suggerisce il nostro amico Pavlina per incrementare il traffico: all'inizio, potrebbe essere d'aiuto un Blog Carnival. E che caspita è? Avevo sentito parlare di Blog rings, ma blog carnival... forse bisogna andare in Brasile? Ce ne saranno anche in Italia? Da una ricerca su Google non ne ho trovati (in inglese sì, in italiano no). Acc...

Ragazzi, torniamo alla considerazione di prima: se non si diventa inglesi, non si fanno i soldi.

Questo post mi ha richiesto 4 ore. Per ora può rendere qualche centesimo al mese.

Soldi facili.

Se attivassi gli AD farei contento chi sta spingendo il Web 2.0 per ottenere i vantaggi della coda lunga di cui ho già parlato, ma, salvo che abbia sbagliato i conti (niente di più facile, peraltro) anche teoricamente non mi sembra che possa essermi utile, al momento.
Non mi resta che continuare per divertimento, poi ne riparleremo tra qualche mese.

Bye

Depa

P.S.: coscienza mia, hai ancora qualcosa da dire? Certo, lo so anch'io che se leggessi Dante sarebbe meglio di Gitomer, ma... insomma, mi lasci parlare, almeno per una volta?

[... continua ...] Leggi tutto

Kerygma

Prima di tutto vi ho trasmesso l'insegnamento che anch'io ho ricevuto, Cristo è
morto per i nostri peccati, come è scritto nella Bibbia, ed è stato sepolto. E'
resuscitato il terzo giorno, come è scritto nella Bibbia.
[San Paolo, prima lettera ai Corinzi - 15,3-4]

---

La prima lettera ai Corinzi è stata scritta tra il 54 ed il 57 d.C., ma i versetti (in tutto il post uso la traduzione interconfessionale, ovvero accolta da tutte le diverse confessioni cristiane, tratta da La Bibbia in lingua corrente) fanno riferimento ad una precedente predicazione di Paolo, probabilmente avvenuta intorno al 51 d.C.

L'estratto riportato è una delle forme di Kerygma, parola con la quale gli studiosi indicano quel messaggio sintetico ed essenziale che i primi apostoli usarono per diffondere la buona notizia che avevano ricevuto da Cristo. Un messaggio semplice, se rapportato al dogma, ma fondamentale per chiarezza e contenuto.

Non sono io la persona più adatta ad approfondire il senso di queste parole: semplicemente io credo in questa testimonianza e voglio qui ricordarla.

Data la mia ignoranza in materia, mi baserò parecchio su alcuni testi.
Tra questi, ovviamente, quelli di Messori (consiglio veramente a tutti, anche ai non credenti, Ipotesi su Gesù, Patì sotto Ponzio Pilato? e Dicono che è risorto), ma anche altri approfondimenti reperibili in rete, tra cui vi segnalo, in particolare, una serie di pdf, che citano estratti di documenti molto interessanti.
Si tratta, in entrambi i casi, di approfondimenti seri e logici, senza prese di posizione enfatiche, retoriche o acritiche come se ne trovano talvolta in altri testi cattolici - pur importanti per chi crede, ingenerano spesso l'impressione di estremismo, ingenuità e forzatura in chi ha dei dubbi o negli scettici.

Un simile annuncio, individuato dagli studiosi perchè lingua e stile utilizzate non corrispondono al contesto, è ripetuto anche in altri punti del nuovo testamento, (es.: prima lettera ai Tessalonicesi, lo scritto più antico del cristianesimo, - non successivo al 52 d.C., che tramanda formule risalenti anche a 5-10 anni dopo la morte di Gesù; discorsi kerigmatici degli Atti degli apostoli: 2,14-36; 3,12-26; 4,8-12; 5,29-32; 10,34-43; 13,16-41; 17,18-31). E' segno di una testimonianza collettiva, con espressioni probabilmente concordate per una azione più corale ed efficace.

E' la testimonianza immediata (le date sopra fornite sono condivise oramai dalla quasi totalità degli studiosi, anche quelli non credenti - anzi, in alcuni casi nascono proprio dai loro studi) della resurrezione di Cristo, è, fin da subito, la base fondante del cristianesimo.

Testimonianza rilasciata all'interno della società ebraica, in una cultura ed un periodo storico che mettono in grossa difficoltà chi ritiene che la figura di Cristo sia stata totalmente inventata (scuola mitica) o, comunque, divinizzata posteriormente, a partire da una vicenda storica (scuola critica).
In breve, la difficoltà nasce dal fatto che non ci sarebbero i tempi minimi perchè si possano, storicamente e logicamente, creare i presupposti previsti dalle due scuole - non per nulla sia la scuola critica che quella mitica cercano di posizionare il più possibile lontano dalla data della crocefissione ogni testo cristiano.

Ribadisco ancora, apposta, - non sto facendo ripetizioni per errore, è voluto - il fatto che di testimonianza si parla.

Su questo, infatti, Paolo di Tarso insiste ancora nei versetti seguenti:

ed è apparso a Pietro. Poi è apparso ai dodici apostoli, quindi a più di cinquecento discepoli riuniti insieme. La maggior parte di essi è ancora in vita, mentre alcuni sono già morti. In seguito è apparso a Giacomo, e poi a tutti gli apostoli. Dopo essere apparso a tutti, alla fine è apparso anche a me
[San Paolo, prima lettera ai Corinzi - 15, 5-8]

Paolo sta cercando di evidenziare questo aspetto di testimonianza, enumerando i possibili testi a favore. Non uno o due, ma centinaia.
La maggior parte di essi vive ancora, potete chiederglielo direttamente.

Cristo (l'unto scelto da Dio per una missione per il popolo, il messia atteso dagli Ebrei) è morto ed è risorto.

Ed è apparso a Kefa, poi ai Dodici, poi ad altri 500, poi a Giacomo, agli altri apostoli (oltre ai dodici, quanti erano?), poi a Paolo (e certamente omette o non conosce altre possibili testimonianze, come, per es., quella di Cleopa e dell'altro discepolo di Emmaus - Luca: 24, 13-35).
Si noti che apparve è usato in senso di comparsa oggettiva, non nel senso di visione, in questo testo.

Noi accettiamo le testimonianze come prove giuridiche.
In questo caso le apparizioni si sarebbero ripetute in tempi diversi, su persone diverse (poi... poi... poi...) e avrebbero interessato lo stesso Paolo, che, pure, prima aveva partecipato alla persecuzione dei cristiani e, in particolare, al martirio di S.Stefano (Atti degli apostoli - 7, 54-60; 8,1-3; 9,1-2), tanto che i cristiani non si fidarono subito di lui (Atti - 9,13-14; 9,21; 9,26-27).
Un testimone scomodo.

Il kerygma è la base della testimonianza della resurrezione (Amore più forte della morte, più forte del male, come ha ricordato il papa nella veglia pasquale) dell'Uomo che aveva il potere di accettare di prendere su di sè i nostri peccati, pagarli per noi con la propria sofferenza e con la propria vita, per poi riprendersela, essendo anche Dio.

Bye

Depa

[... continua ...] Leggi tutto

Joost Jump

Forse quelli di Babelgum hanno paura di una recensione come quella di qualche giorno fa su Democracy Player, visto che hanno completamente finto di ignorare la mia richiesta di partecipare alla beta. Forse pensavano che un giudizio tecnico di livello, come quello già fornito per Joost fosse ancora troppo prematuro. Forse volevano solo evitare un confronto?

Tutti quelli tra voi che hanno detto che semplicemente non si saranno accorti della mia esistenza (e figurarsi se hanno letto i post) possono anche fare il favore di andarsene subito, tanto non siamo mai stati amici.

Per gli altri fornirò un ulteriore approfondimento su Joost, assolutamente necessario dopo l'uscita, 3-4 giorni fa, della beta 0.9, seguita immediatamente dalla 0.9.1: nonostante abbiano peggiorato l'accesso al sito, che ora si riesce a non utilizzare in 3 modi differenti a seconda che usiate IE, Firefox o Opera, dal client si ottengono nuovi contenuti e funzionalità migliorate.

Hanno fornito anche informazioni aggiuntive, molto interessanti, relative a quali canali sono al momento previsti in quali paesi.

Un bel salto, qualcosa che giustifica veramente il cambiamento di numerazione nella release.

---

Iniziamo col dire che lo so da me che non va mica bene passare troppo tempo di fronte alla TV e che sarebbe meglio andare a fare dei giri, soprattutto potendo sfruttare una residenza tra le Alpi ed il lago Maggiore.
A mia parziale discolpa (o forse, al contrario, a peggiorare la situazione), lo sapete anche voi che quando torno a casa, non riesco a fare a meno di completare le 12 ore di lavoro con altre 4 a vagolare tra la programmazione ed la navigazione sul Web, probabilmente a causa di qualche virus che ha risparmiato il mio PC, ma non me.

Quindi, torniamo a Joost.
La prima e fondamentale nota riguarda il numero di canali, che sono passati da 38, a 37 nei giorni immediatamente successivi al mio precedente post, ai 67 negli ultimi due giorni. E' comparso, chi mai avrebbe potuto immaginarlo, anche un canale di calcio (ve lo dico anche se a me non interessa, perchè so che c'è gente che lo segue).

Soprattutto ora ci sono anche contenuti che mi interessano decisamente di più, dagli hobby (chitarra, disegno, etc.), alla fantascienza, alla cucina.

Anzi, dopo aver finito questo post, ricordatemi che devo finire il programma che spiega alcuni giochi di prestigio, che ho iniziato ieri e ho dovuto lasciare subito perchè dovevo finire un lavoro.
Ho potuto farlo a cuor leggero perchè, finalmente, è possibile saltare i pezzi già visti, spostando avanti un cursorino. Raggiungere il punto di interesse non è immediato, dicono che ci stanno lavorando, ma è già buono, quando si arriva a metà di un programma di due ore e non si vuole rivedere la prima. Cursore a parte, in realtà, secondo quanto ho letto, dovrebbe ripartire addirittura da dove ho spento. Sperem...

Anche l'organizzazione è migliorata, con comparsa di categorie e guide maggiormente configurabili.

Rispetto alle prove di qualche settimana fa, però, ieri sera, a mezzanotte, era quasi inguardabile per quanto andava a scatti e una volta ho dovuto agire con la forza (taskmanager). Stasera riprovo per capire se si trattava di problema della nuova 0.9.1 o semplicemente di orario - forse troppe persone collegate? a mezzanotte da noi, negli USA intorno delle 17:00: potevano essere sotto stress i server. Sarebbe anche possibile se tutti hanno ricevuto, come me, 5 inviti da dare in giro agli amici: partendo dai precedenti 80.000 beta tester, si arriverebbe a 400.000 ed inizia ad essere un bello stress-test.

Sempre un po' deludente, anche se un filo meglio della volta scorsa, l'aspetto widget. Questa è l'area su cui mi sembra stiano annunciando future evoluzioni.
E, da bravi informatici, attendiamo di vedere cosa si potrà fare con le API che dovrebbero pubblicare a breve.

Nel frattempo, più lo guardo più lo vedo come concorrente della TV tradizionale e non scambierei la libertà (fin troppa, a volte) e la freschezza di YouTube con la qualità offerta da Joost, ma secondo schemi troppo consueti.

Bye

Depa

P.S.: qualcuno di voi ha un invito per Babelgum? A me non interessano veramente i programmi: mi piace giocare con le novità.

[... continua ...] Leggi tutto

Esagoni e carte

Il 29 maggio 1848 la ritirata strategica piemontese nella battaglia di Curtatone Montanara è stata il presupposto per la seguente più importante vittoria nei pressi di Goito. Grazie anche al valore degli Universitari delle università di Bologna, Ferrara, Modena, Padova, Parma, Pavia, Pisa, Siena e Trieste (ho studiato a Pavia e l'Università chiude per commemorare i caduti in quella battaglia, ricordati anche con una gara di canottaggio tra Pavia e Pisa).

Ovviamente state giustamente pensando che la mia immensa cultura non ha limiti ed anche sulla storia me la cavo mica male.
Farò finta di non sentire il borbottio di fondo dei soliti pochi riguardo a fantomatiche mie ricerche a caso sulla Wikipedia e conseguente ricamarci sopra per scrivere un post (è inutile che neghiate, quando non avete neppure il coraggio di guardarmi negli occhi).

Siccome tengo molto alla vostra educazione, vi risponderò con i fatti, fornendovi qualche informazione aggiuntiva e dimostrandovi le mie solidissime basi.
Condivise, peraltro, anche da personaggi illustri come Leopardi (e ogni critico onesto non potrà che convenire) quando associava gli studi leggiadri alle sudate carte, riferendosi, come sto per fare io, proprio al tempo passato a giocare ai wargame.

---

Giocare o imparare?
Finchè si è piccoli il primo è propedeutico al secondo.
Crescendo, il secondo fornisce una buona scusa al primo (quando, ovviamente, non ci si aliena su Second Life per garantire una decente vita sociale al nostro avatar e con il solo illusorio conforto che anche lì si parli di cultura, quando il marketing pensa di tirare in ballo personaggi risorgimentali).

Quelli tra noi che, diventando più grandicelli, hanno cercato ancora di giocare con i soldatini, infatti, hanno pensato bene di confermare le teorie evolutive relative all'homo ludens mettendosi a studiare la storia, le evoluzioni delle divise (competenza immancabile nel bagaglio di ogni grande artista che voglia dipingere personalmente i propri modellini), le tattiche di guerra.

Arrivando pure a leggere quel von Clausewitz che mio padre, generale dell'esercito italiano, ricordava con terrore dai tempi della Scuola di Guerra, sostenendo che, come mattone, Della Guerra nulla avesse da invidiare alla Critica della ragion pura di Kant. Per completezza di cronaca e onestà intellettuale non possiamo dimenticare che quelli che cercavano le proprie radici filosofiche nell'estremo oriente, preferivano, invece, i famosi detti di Sun Tzu.

Entrambi, tra l'altro, riutilizzabili nella seguente (o parallela) vita lavorativa, come citazioni da giocarsi quando si parla di mercati da conquistare o azioni di marketing (disciplina che desume molta della propria terminologia proprio da quella militare) o quando si deve definire un piano di progetto di emergenza.
L'evoluzione delle divise continua e credo che sia quasi banale sostenere che le cravatte e le giacche debbano rientrare a giusto titolo in questo elenco.

Si può giocare ad un wargame anche senza preoccuparsi della storia (quando, addirittura, non si devia, come con Warhammer, sul fantasy: bisogna studiare meno, i testi di riferimento sono più facili, per puro caso richiamano vagamente i film ed i gadget che si stanno vendendo su altri canali, etc. etc.).

Ma se non ti crei un background solido (e questo vale anche per ambientazioni fantasy), non sarai mai un vero giocatore e smetterai certamente alle prime difficoltà (a pag. 10 del manuale di istruzioni, dove iniziano a comparire le tabelle dei costi di movimento ed i concetti di ZOC - ZOna di Controllo - o simili).
Nascondere il tedio del calcolo e della continua consultazione sostituendo le tabelle con dei videogame non serve a molto per continuare, se non studiate anche l'ambientazione, le circostanze di contorno alla battaglia. E il suo esito, ovviamente, per cercare di ribaltarlo: se vinciamo a Waterloo nei panni di Napoleone, non battiamo solo il duca di Wellington, ma, ben più importante, lo stratega per eccellenza stesso, ancora una volta, sul quello stesso campo - il fatto che lui non vedesse il tavolo dall'alto, che non potesse ripetere 10 volte la battaglia prima di vincerla e che si trovasse di fronte un altro vero generale e non il nostro amico, notoriamente un inetto a questo gioco, sono solo scuse meschine che da una persona del livello di Napoleone, davvero, non ci saremmo mai aspettati di sentire).

Chi riesce a darsi delle motivazioni in questo senso diventa un grognard (ovvero un giocatore di wargame, in una accezione che tende a sottolineare una certa esperienza): non un guerrafondaio, ma un giocherellone serio e colto, sostenitore della sostanza.
Se fosse un amante della forma gli sarebbe inacettabile poter passare le giornate davanti a quadratini di cartone di mezzo centimetro di lato, con simboli elementari al posto di disegni e numerini sopra e sotto (è accettabile sostituire i quadratini di cartone con delle figure tridimensionali colorate, ma solo per maggior rigore storico o per rendere più realistica la ricostruzione).

Il grognard è anche un tipo preciso: le unità si muovono su esagoni, nelle 6 direzioni indicate dai lati, perchè con questi poligoni è possibile riempire completamente un'area (il tavolo da gioco) senza lasciare buchi e garantendo che dal centro di un esagono al centro dell'altro sia costante la distanza. Per simulare maggiormente alla realtà è possibile permettere alle unità di muoversi in ogni direzione solo laddove ci si accordi per procurarsi un metro flessibile per controllare inflessibilmente le distanze misurate.

Un hobby a tutto tondo, quindi, che permette non solo di crescere nella cultura della storia e dell'arte, ma di bilanciarle con la precisione di matematica e geometria.

Chiaramente, se ora non vi raccontassi che anche Internet deve essere considerato terreno di conquista e fonte di ulteriore conoscenza dovreste controllare bene il titolo del blog per verificare di non essere stati rediretti altrove.

E' facile, partendo da Web Grognard, trovare i link che permettono di fornire le basi per gestire combattimenti navali nell'800, per poi trovarsi ad approfondire i dettagli storici su Line of Fire di History Channel per ricordare l'ingegno, il coraggio e l'estremo saluto di Nelson nella battaglia di Trafalgar, che chiarì a tutti cosa voleva dire la supremazia inglese sui mari per quasi un secolo.

Potete sfruttare la macchina del tempo e rispolverare il valore degli antichi, prima della polvere da sparo, recuperando le regole classiche di Ancients, basate su esagoni, ed i diversi scenari (mai venuta voglia di evitare che Orlando cerchi di spezzare Durlindana alla fine della battaglia di Roncisvalle, prima di morire?).

Ce ne sono tanti altri, di link simili (quasi tutti reperibili da Web Gognard), ma il punto è che da anni, oramai, vivo in una città diversa da quella in cui risiedono gli amici che mi piaceva affrontare su questi campi.
Ma, ancora una volta, il Web, la piattaforma che, di mestiere, mette in contatto persone lontane, potrebbe venire in aiuto. Per esempio con Vassal, sistema che permette di ridefinire un intero board game su PC e trasmettere i nostri spostamenti sugli esagoni via email (no, non in diretta: stiamo giocando con tempi lunghi, le mosse possono richiedere anche mezz'ora, la mail è lo strumento corretto).

Certo, oltre alla lontananza non ho più neppure tutto tutto il tempo che avevo ai tempi del liceo o dell'Università. Leopardi, da suo pari, già aveva capito la risposta al problema: è, infatti possibile ricorrere a wargame più rapidi e facilmente trasportabili, usando, come il poeta rimembrava a Silvia, (mazzi di) carte (che sarebbe meglio non fossero sudate, perchè rischierebbero di essere riconoscibili come se fossero segnate, come potrebbe notare subito qualche giocatore più esperto).

Anche in questo caso esiste uno specifico programma che ci permette di giocare via Internet, Thoth, con carte predefinite o regole facilmente rintracciabili (es: Hoplites) dalle quali lasciarsi ispirare per disegnarne di nostre.

Ci sono battaglie perse in partenza e anche questo espediente delle carte non basta più per i miei pochi istanti di libertà.
Forse, sintetizzando un po' questi post potrei tornare a giocare...

Chi di voi ha detto che prima sarebbe meglio vivere che giocare?

Bye

Depa

P.S.: se siete in viaggio e non sapete cosa fare, esistono anche carta e penna e un altro po' di regole che potrete trovare, per es., presso il sito di Warp Spawn Games.

[... continua ...] Leggi tutto

SOA (2) - Variazioni Goldberg

[...] l'opera è stata concepita come un'architettura modulare di 32 brani, disposti seguendo schemi matematici e simmetrie che le conferiscono tanta coesione e continuità da non avere eguali nella storia della musica [...]. Così la Wikipedia, riguardo alle Variazioni Goldberg di Bach.

Anche con SOA abbiamo il problema di mettere assieme una architettura modulare, i nostri brani sono i servizi, la coesione e la continuità sono fornite da schemi di processo definiti in un workflow...

Come sarebbe a dire che non sapete cosa sia SOA? A questo punto dovreste, come minimo, avete già letto il mio precedente post introduttivo e la maggior parte di voi saranno stati lì come avvoltoi aspettando che pubblicassi quello sul Web 2.0.
Come sarebbe che non ricordate? (Chi ha detto 'ho rimosso'?)

Capisco che possiate non aver sentito parlare di WOA, SOD e SOR...
Pensate che stia tirando sigle a caso? (Non potete immaginare neppure cosa vi aspetta nel dettaglio di questo post, allora - vendicherò il mio orso dell'altro mio recente articolo sul Web Semantico).

Se non le conoscete perchè leggete solo il mio blog e non vi fidate di nessun altro, certamente non posso biasimarvi...

Però ricordate che a dire bugie vi cresce il naso.
E a non studiare anche le altre fonti, pure le orecchie.

---

Riassunto delle puntate precedenti: abbiamo visto che SOA è una architettura per servizi remoti(zzabili), tipicamente resi disponibili sotto forma di Web Services, prodotti all'interno dell'azienda, ma anche da fonti su Internet.
Abbiamo dato un'occhiata all'architettura, dall'alto di un dirigibile, e abbiamo visto come, di fatto, sia un modo per ripensare il sistema aziendale basandosi su componenti (siccome non è certo una novità, gli cambiamo nome e li chiamiamo servizi), mettendoli in fila con un sistema che è un incrocio tra un motore di workflow ed un EAI (Enterprise Application Integration), chiamato Service Bus o Orchestrator, a seconda dei casi.
Abbiamo anche notato che qualcuno propone servizi già pronti da usare su Web e da essere integrati nei vostri siti e li pubblicizza sotto il nome di Web 2.0.

Abbiamo omesso, (apposta, ma ci torneremo, se non quest'anno, nel prossimo), di dire che il SOA Service Bus potrebbe non esistere, potendosi incastrare i vari servizi in una bella pipe, in cui uno dei servizi usa l'output dell'altro come suo input.

In un modo o nell'altro i servizi si mettono assieme, il risultato delle loro elaborazioni viene presentato in modo uniforme e l'applicazione che ne risulta viene chiamata mashup. A prescindere da tutti i significati e le derivazioni che troverete nel link appena riportato, non so perchè a me viene sempre da tradurlo 'pastrocchio'.

Che alla fine lo sia o meno, al solito, dipende da quanto siamo bravi e attenti nel fare il nostro lavoro, da quanto tempo abbiamo e da quanto era basso il budget o l'offerta: se le fonti sono tante, le API messe a disposizione attraverso i web services (ws, da qui in avanti, se no si fa lunga) potranno seguire differenti filosofie di progettazione, potranno essere più o meno semplici, potranno funzionare o meno, seguendo più o meno fedelmente le rispettive documentazioni (sempre che esista qualcosa cui poter ragionevolmente dare un simile nome).
L'esperienza insegna che l'integrazione di sistemi differenti è, tranne che per operazioni banali, sempre uno dei punti più critici di ogni progetto, è sempre uno dei punti in cui è facile sbagliare le stime. E' sempre bene ricordarlo, quando si progetta un bel mashup. Non tutti sono in grado di mettere assieme tanti moduli come Bach e non subire il severo giudizio della storia...

E' bene notare che, solitamente, si parla di mashup quando più ci si avvicina a servizi destinati ad una presentazione, (più Web 2.0, per intendersi), piuttosto che quando si parla di servizi aziendali in architettura SOA, con tanto di Service Bus, ma non ci stupiremo più di tanto se da qui in avanti le terminologie si mischieranno un po', dal momento che i due approcci tendono a convergere fortissimamente.
Anche per motivi legati alla consumabilità dei servizi (ovvero alla loro utilizzabilità anche da parte dei client più semplici), e in parallelo alla diffusione di interfacce grafiche più ricche su Web (si parla di RIA - Rich Internet Applications), la sigla SOA, con un facile morphing, cambia in WOA (Web Oriented Architecture).

WOA implica maggiore flessibilità e velocità di adattamento, utilizzo di tecnologie più semplici: HTTP, XML più piatto, chiamate ad URI; contrapposte alle complessità di SOAP (peraltro oggi discretamente nascoste da ottimi tool e librerie) come base dei Web Services. Hinchcliffe, nel post sopra citato, nota come l'attuale lista degli standard WS-* sia ormai quasi incomprensibile per il semplice mortale e supporta fortemente (come in quasi tutto il resto dei suoi post) queste tecnologie più alla portata di tutti(anche quando parla di SOA, tende sempre ad omettere l'orchestrator e a far convergere SOA, WOA e Web 2.0 verso lo stesso significato). Il rovescio della medaglia è che, in situazioni con molte differenti fonti di servizi provenienti, bisogna reinventarsi l'interpretazione dell'XML, scambiarsi le specifiche a più basso livello, laddove SOA ci permette di concentrarci sulle interfacce (intese nel senso della progettazione ad oggetti, non nel senso del layer di presentation) e basta.

Siccome questo è il post delle sigle, qualcuno di voi - tra quelli più forti fisicamente, s'intende o, alternativamente, oramai così malridotti che tanto peggio non può andare - si starà chiedendo perchè abbia tirato in ballo alcuni aspetti di REST senza citarlo. Lo faccio ora, così quelli che non hanno capito nulla fino a qui, si confonderanno quel bit in più e non torneranno mai più.

REST sta per REpresentational State Transfer e, in due parole e ben conscio di sminuire alquanto il tutto (ma non potete chiedermi di essere sintetico e di spiegarvi i dettagli: vi fornisco i link apposta), vuol dire che noi abbiamo i dati e, quando ce li chiedono, al posto che creare direttamente una presentazione specifica o inviare interamente dati, inviamo una rappresentazione intermedia, filtrata, dei dati stessi, in modo che il client possa decidere di costruirsi la sua rappresentazione da solo (lasciando aperta la possibilità che la nostra rappresentazione sia già presentabile senza ulteriori engine).
E' più semplice con un esempio: voi puntate ad un URL per avere un feed RSS, vi viene inviato un XML e il vostro client (browser o feed aggregator) mette assieme il tutto e ve lo presenta.
Consiglio, comunque, di seguire il link fornito, non solo perchè il suo autore, Roy T. Fielding, è stato uno dei principali autori e architetti dell'HTTP, ma anche perchè mostra una interpretazione della crescita logica delle principali architetture nel tempo. Non ci stupiremo se Fielding parla di REST come di una architettura e non come una serie di tecniche (quelle che sopra ho contrapposto a SOAP) per supportare l'architettura stessa.

Non si può dire se sia meglio SOAP o REST a priori, è la situazione specifica che decide cosa sia meglio: in un caso siamo più completi e formali, esistono delle librerie di supporto per semplificarci la vita, i protocolli sono già definiti, ci sono modi per gestire sicurezza, attachment, transazionalità ed altro, ma abbiamo la necessità di considerare i client, che dovranno essere compatibili con la nostra specifica e dovremo condividere le interfacce, secondo modalità tipiche dell'OOP, che richiedono un livello di competenza eccessivo, laddove sia sufficiente chiamare un'URL, ottenere un XML e, poniamo, filtrarlo con un semplice XSL o, addirittura, presentarlo direttamente senza rielaborarlo. Normalmente, come accennavo, più andiamo sul front-end più è facile avvicinarsi a REST, più andiamo sul back-end, più ci avviciniamo a WS-SOAP-based.
Inutile dire che, quando i servizi arrivano da Internet, laddove la sicurezza sarebbe da considerare maggiormente, è più facile trovare interazioni più semplici, più basate su REST, che quelle più formali e studiate di SOAP e la gestione di questa delicata problematica è spesso lasciata in secondo piano o trattata puntualmente e differentemente a seconda dei casi.

Ancora, tipicamente avrà più senso parlare di architetture SOA, basate su WS SOAP, laddove l'aspetto aziendale (Intranet/Extranet in senso lato, comprendendo la gestione delle attività operative dell'azienda) sia prevalente e di WOA e REST per architetture che prevedono forti interazioni con l'esterno.

Il che ci porta a fare un passettino indietro: non ci sono solo SOAP e REST, ma, nel caso di integrazioni con sistemi alla base dell'operatività, l'avevo già accennato la prima volta, dovremo accentuare le capacità di EAI dell'Orchestrator o di moduli collegati, con la possibilità di agganciare servizi forniti da un ERP, un CRM o altri sistemi esterni (in altri casi esistono tool che si installano sul sistema esterno e permettono di trasformare - per es., traducendo le API già a disposizione o mediante screen-scraping - i suoi servizi legacy in WS SOAP-based e, quindi, si riesce a far ricadere il tutto nelle casistiche più standard).

Per completare il glossario, restano SOD e SOR. Che sono quasi uno scherzo (non credo che siano termini usati veramente, ritengo siano stati inventati per uno specifico blog, unico punto sul quale li ho trovati citati - e che vi consiglio: un po' ripetitivo, ma solido) che, però, mi serve per introdurre un argomento basilare.

Mentre SOA, (sto rubando l'intera frase dal blog citato), ha a che fare con il fatto di far guidare l'IT dalla visione di business, qualcuno ha trasformato quella visione in bit e bytes e questo è il motivo per cui SOD (Service Oriented Delivery) e SOR (Service Oriented Realisation) sono veramente importanti.

Ovvero: dopo tanto parlare e disegnare macro-architetture, basate su macro-principi, arriva il momento di tirarsi su le maniche e iniziare a pensare ad organizzare il nostro progetto basato su SOA. Basterà utilizzare i task tipici di un progetto Internet/Intranet a cui siamo abituati?
Per finire questo post, mi limiterò ad accennare ad alcuni aspetti importanti di gestione:

• analisi dei processi: è fondamentale (perchè SOA è guidato, come dicevamo, dai principi di business) e deve essere antecedente, il più possibile, all'inizio degli sviluppi: meglio ridurre anche i parallelismi con la fase di analisi tecnica di dettaglio. Conoscere i processi serve, infatti, per identificare le funzionalità atomiche che compongono i processi stessi, cercare di separarle e componentizzarle al fine del riuso. Fin qui niente di diverso rispetto a quanto siamo stati tutti abituati. La differenza sta nell'intensità con cui dovrebbe essere seguito questo approccio, sta nel ricercare la possibilità di creare servizi utilizzabili anche fuori dal sequence diagram in cui li abbiamo disegnati per la prima volta. Questo perchè, altrimenti, il motore di workflow centrale e la gestione a servizi introdurrà solo layer che appesantiranno la struttura, ma i vantaggi che ci resteranno si limiteranno a poco più che una riduzione del carico su un server, perdendoci il vero motivo dell'utilizzo di questa architettura, che è la grandissima flessibilità offerta


• analisi tecnica di dettaglio: l'architettura SOA richiede una maggiore complessità e definizione, quindi sappiate che, nel prendere questa strada, dovete alzare quelle benedette stime relative a questo task. La flessibilità si paga sempre in termini di aumento dei tempi di sviluppo (è un dolore doverlo ricordare, ma sembra quasi che sia vietato considerare stime significative per le analisi tecniche, soprattutto se bisogna metterci una risorsa senior, che costa, nelle stime di progetto - il che porta, inevitabilmente, a trovarsi con il fiato corto e ad un aumento dei costi di sviluppo).


• maggior parallelismo: attenzione a questa ipotesi. E' verissimo che, in una architettura a servizi, ognuno di questi servizi, soprattutto se sono stateless, come spesso suggerito, è, potenzialmente, parallelizzabile. Bisogna, però, tener conto della necessità di integrarli e, quindi, del lavoro da prevedersi sull'orchestrator e in fase di definizione delle interfacce. Inutile ricordare che più aumenta il parallelismo, più aumenta la dimensione del team e il carico di gestione del progetto. Inutile ricordare che, anche procedendo percentualmente, l'ingegneria del software insegna che esiste un limite oltre il quale la gestione salirebbe esponenzialmente e conviene comunque mettere i task in serie, perchè i costa molto meno. Per chiudere l'elenco delle cose che è certamente inutile ricordarvi, permettetemi anche di farvi notare che l'ipotesi di poter fare servizi stateless implica centralizzare parte dell'intelligenza dell'applicazione ed un appesantimento degli sviluppi per continuo passaggio di parametri. Senza considerare che, in un disegno pulito, la gestione della sessione non dovrebbe stare negli strati più alti dell'Application Server, ma tra i servizi e recuperarla potrebbe richiedere ulteriori overhead.


• rework inatteso: se pensate di integrare servizi esposti su Internet, iniziate a mettere in conto un bel po' di contingency, perchè questi servizi possono cambiare senza preavviso. E' facile usarli, solitamente, se ci limitiamo a servizi che impattano solo sulla presentation (widget e compagnia bella), ma se doveste trovare un servizio da integrare per fare qualcosa di serio, pensateci due volte e confrontatelo bene con le stime di cosa comporterebbe rifarlo internamente, tenendo presente queste possibilità di rework


• test: saranno più complessi. Non tanto, come sento suggerire da tutte le parti, per la necessità di automatizzare i test (attività dispendiosa e utile, a mio parere, solo se prevedete di avere potenzialmente molte regressioni, altrimenti costa meno farli fare a qualche umano), quanto per la necessità di testare una ad una tutte le integrazioni con i diversi servizi, soprattutto se ce ne sono di esterni

Pensate che abbia esagerato? Che non dovevo necessariamente raccontare tutto in questo solo post?
Ma se abbiamo solo iniziato, riuscendo a malapena a condividere le basi terminologiche...

Bye

Depa

[... continua ...] Leggi tutto

Adelante, presto, e con un po' meno juicio

Ne ho letto bene altrove da utenti famosi e anche da un punto di vista tecnico, per non parlare della voce più autorevole del lifestyle tecnologico: anche Wired gli dà il suo voto. Se vince queste elezioni, vorrà dire che andrò all'opposizione.

Oggi ho installato Democracy Player e ne sono rimasto profondamente deluso.

Ne ha giovato, però, il mio lavoro, perchè l'ho trovato improvvisamente decisamente più interessante.
E pure la lunghezza di questo post, uno dei più corti delle ultime settimane.
Mi rifiuto pure di aggiungere un'immagine a mo' di protesta sindacale.

---

Se avete tempo 15 minuti per vedere qualcosa nella pausa pranzo, non perdeteli con Democracy Player.
A meno che non l'abbiate lasciato acceso tutta la mattina, per scaricarvi un unico file.

E' lento nel permettervi di usufruire dei video.
E' mortalmente lento nel fare le ricerche.

E' una sorta di download manager e video player, con alcune (poche e banali) pretese social.
Stream come quelli a cui ci stiamo abituando con Joost e YouTube, neanche a parlarne.
Potete cercare su più fonti video (YouTube, Yahoo e Google Video e altri 3 o 4), ma se dai siti originali li potete vedere durante il download, qui dovete aspettare che finisca. Quindi, un filmato di 15 minuti, che avreste visto in 15 minuti con YouTube, ve lo potete vedere in 15 minuti più altri 10 di download.

Assurdo.

Se, per caso, vi sbagliate e cliccate su un altro link qualunque all'interno del programma, dovete ripartire da capo. Davvero non è proponibile una ripresa del download, che già si usava 5 anni fa? I filmati occupano spazio? Ma se una delle caratteristiche del player è quella di salvare i filmati in locale per rivederli (con expire in 5 giorni, di default) anche off-line... (saremo mai off-line, nei prossimi anni?).

E comunque, basterebbe aggiungere una funzionalità per decidere quali di quelli in sospeso cancellare, magari con reminder prima di uscire dal player.

Come tipologia di contenuti trovate quelli delle fonti che avete già nei bookmark, più qualche vblog (video blog).

Stessa qualità video e audio, ovviamente.
No, in realtà avete anche qualche canale in più con la possibilità di accedere a video di altissima qualità.
Fatelo voi, però, perchè io ci ho provato, ma ci volevano oltre 45 minuti, per scaricarli a 4Mbit.

La televisione del futuro?
Effettivamente, se andiamo avanti con i reality che ci propinano, nel futuro potremmo anche arrivare a farci altrettanto male anche con la TV, ma non vedo un solo motivo per anticipare i tempi.

Non posso ottenere lo stream di YouTube, Yahoo e Google e mi vengono filtrate, riducendole di parecchio rispetto ai siti, le funzionalità.
Non posso avere la qualità di Joost.
Se faccio una ricerca devo aspettare un sacco di tempo.
I bookmark posso averli anche nel mio browser.

Qualcuno, per favore, mi spieghi a cosa serve questo oggetto, mi devo essere perso qualche voce di menù.
Come ha fatto a diventare così famoso?

Voglio essere positivo a tutti i costi, però:
- è in grado di gestire un elevatissimo numero di formati video
- è GPL, quindi si può leggere il codice ed imparare come è fatto. Sempre che serva a qualcuno, ovviamente.
- siamo alla versione 0.9.5: prima di arrivare alla 1.0 potrebbero (ma ci sono pochi numeri di release ancora disponibili!) anche riuscire a correggere il tiro qui e là.

Bye

Depa

P.S.: volevo dargli una seconda possibilità, l'ho ricliccato, forse mi sono perso delle preferences (a parte il fatto che scegliere dei comportamenti di default come quelli impostati sarebbe persino peggio).
Ottengo:
XML Parsing Error: undefined entity
Location: chrome://dtv/content/main.xul
Line Number 8, Column 1:<window id="main" title="&main.title;"
^

Si è eliminato da solo. Ha fatto bene. Questa volta sì, che mi ha fatto risparmiare tempo.

[... continua ...] Leggi tutto