Premetto subito che questa non vuol essere una bibbia completissima, ma giusto un'introduzione a questo mondo davvero complesso e vasto, di cui il web è già ben fornito.

Partiamo dal principio: il suono è un onda meccanica, un'oscillazione della pressione nata dalla vibrazione di un corpo, che si propaga per l'aria o un qualsiasi altro mezzo elastico.
Quando un suono viene captato da un microfono, questo lo trasforma in un segnale elettrico, i cui valori di tensione rappresentano la forma dell'onda originale. Questo segnale elettrico è continuo, sia nel tempo che nei valori che può assumere, ed è detto analogico.
In pratica, ad ogni istante di tempo è possibile misurare un preciso valore; gli istanti di tempo misurabili e i valori che può assumere sono infiniti.

Quando convertiamo questo segnale in digitale (digitalizzazione) non facciamo altro che andare a leggere ad intervalli regolari di tempo, il valore di questo segnale; una singola lettura è detta campione, mentre il numero delle letture che facciamo in un secondo è detto frequenza di campionamento.

In questo modo, come risultato delle conversione analogico\digitale otteniamo una serie di valori delle varie misurazioni fatte ad intervalli regolari di tempo. Con queste informazioni è possibile ricostruire un segnale che, anche se non è perfettamente identico all'originale, cerca di approssimarlo (come si vede in figura): più sarà alta la frequenza di campionamento e la precisione nella misurazione del valore, e tanto più il segnale digitale sarà simile all'originale analogico.

Se fino a qui è stato tutto chiaro, il peggio è passato

Con questa piccola introduzione già si spiega cosa vogliano dire i "44.100Hz 16bit stereo" che rappresentano la qualità audio cd: in ogni secondo di audio vengono fatti 44.100 campionamenti, e il valore di questi viene scritto in un numero a 16bit.
Da qui è facile anche calcolare quanto spazio occupa un secondo di audio: 44.100 x 16 = 705.600 bit = 88Kilobyte  x 2 canali stereo = 176KB/s al secondo. Questo valore, ovvero lo spazio necessario per memorizzare un secondo, è detto bitrate.

Senza ulteriori manipolazioni, possiamo salvare questa lista di valori misurati ottenendo un file di audio non compresso (PCM), che solitamente abbiamo visto nei nostri pc con estensione WAV.
Ma l'audio non compresso, beh, ci occupa davvero molto spazio (circa 10MB al minuto)  e come sappiamo un cd-audio di 700MB riesce a contenere solo 80 minuti. Abbiamo quindi il problema di dover ridurre un po' le dimensioni dei nostri file, dato che diventa problematico sia da archiviare, ma ancor più da trasmettere (ad esempio via internet).
La cosa più semplice che ci può venire in mente è quella di abbassare la frequenza di campionamento o ridurre il numero di bit utilizzati per rappresentare un singolo campione, ma questa scelta porta subito ad una drastica riduzione della qualità del suono, in quanto avremo molte meno informazioni per ricostruire il segnale originale.
Allora possiamo provare a comprimere il nostro file WAV con winzip o winrar, ma noteremo presto che difficilmente si raggiunge una compressione maggiore del 30-40%, ed è troppo poco.
Quindi, per poter ridurre il peso del nostro file cercando di mantenere la qualità originale, dobbiamo fare uso di codificatori\decdificatori (codec) che convertono il nostro audio in nuovi formati più o meno compressi.

I codec si dividono in due diverse famiglie: lossy e lossless.

Le compressioni lossless sono senza perdita di informazioni: quando andremo a decomprimere il nostro file, otterremo una copia identica all'originale, esattamente come succede con un file ZIP, ma dato che questi codec sono stati studiati proprio per la compressione audio, si riesce a raggiungere una compressione maggiore del semplice zip\rar, solitamente attorno al 50%. I codec lossless più famosi sono: FLAC, ALE, Monkey's Audio (APE).

Le compressioni lossy invece, riescono a farci risparmiare molto più spazio (fino al 90%) pagando però un prezzo: l'impossibilità di riottenere il segnale originale, perché il codec sceglie di tagliare fuori molte informazioni che ritiene "inutili".
Anche la perdita può far sembrare che questa sia la soluzione sbagliata al nostro problema, in realtà è quella che viene usato praticamente ovunque: gli MP3 fanno parte di questa categoria, assieme ai meno conosciuti AAC, OGG e WMA. Questo perchè entro certi limiti la perdita di informazioni ci è impercettibile e allo stesso tempo lo spazio risparmiato è tantissimo.

Per raggiungere questo risultato si fa uso della psicoacustica, ovvero lo studio della percezione soggettiva umana del suono,  il cui concetto di base è semplice: l'orecchio umano non'è perfetto.
Noi percepiamo frequenze che variano dai 20Hz ai 20kHz (e con l'età il limite superiore tende ad abbassarsi), e in questo range ne sentiamo alcune meglio di altre. Inoltre ci sono casi in cui in presenza di suoni di frequenza simile, ma di diversa intensità, riusciamo a sentire solo quello più forte. Il grafico mostra a quali frequenze siamo più sensibili (la fascia intorno dai 500Hz ai 2500Hz è quella che comprende la voce umana):

Con queste e altre conoscenze, tanti studi e tante prove di ascolto, è stato possibile creare dei codificatori che effettuano dei tagli di tutto quello che il nostro orecchio non percepisce e distribuiscono più bit di informazioni nelle frequenze che precepiamo meglio, e meno in quello su cui siamo più carenti.
E con questi tagli riusciamo ad avere audio di buona qualità anche a solo 16KB/s, che corrispondono al classico MP3 128Kbps.

Ovviamente come detto, per raggiungere questo risultato molte informazioni vengono perse, ed un orecchio allenato riesce a percepire differenze dall'originale anche con un MP3 a 256Kbps o più, a patto però di avere anche un impianto audio o delle buone cuffie. Gli audiofili patiti della massima qualità, e dotati di un buon hardware, ovviamente ripiegheranno sempre sui formati lossless, per tutto il resto facciamo uso di formati lossy: gli mp3 nei nostri lettori portatili, le tracce audio dei dvd, l'audio dei filmati su internet, l'audio nei videogiochi, ecc ecc... Bene o male tutti abbiamo sentito almeno una volta un MP3, e abbiamo idea di come "suona", e credo che sia più che sufficiente per qualsiasi tipo di applicazione.

Gli altri formati lossy, come AAC, OGG, WMA, si basano sugli stessi principi: si distinguono più che altro per lievi differenze di qualità a diversi bitrate, o per il supporto all'audio multicanale, o per essere opensource... Ma alla fine se dovete scegliere il formato per la vostra musica l'unica cosa da fare secondo me è provare a convertire qualche brano e sentire con le proprie orecchie.

Prima di concludere, voglio spendere due parole su un alto formato lossy che però non fa uso della psicoacustica: l'ADPCM.
Quando un file viene compresso con questa codifica, invece di salvare un valore per ogni campione, si usano delle funzioni matematiche che cercano di predire il valore del campione attuale utilizzando quelli passati, e salvando solo 4bit di informazioni che contengono l'errore tra la predizione fatta e il valore reale.
Quando andremo quindi a riprodurre il file, verranno riapplicate le solite funzioni di predizione per ottenere un valore "previsto" il quale verrà ritoccato coi 4 bit di informazione per tornare al valore originale; quindi vediamo subito che la compressione in questo formato è di 4:1, per il semplice passaggio da 16bit a 4 bit per campione.
Fin qui sembra tutto perfetto, ma questo formato fa sempre parte della famiglia dei lossy, in quanto i 4 bit non sono sufficienti per salvare con precisione l'errore della predizione, e quindi anche in questo caso avremo sempre un'approssimazione che sprecialmente alle alte frequenze porterà ad avere dei disturbi.
Nonostante questo, ADPCM è stato ed è molto usato sia nella telefonia (e quindi lavorando con basse frequenze), sia in molti videogiochi (ed è qui che ci interessa): anche se il bitrate necessario è molto più elevato rispetto all'MP3 e simili, il carico di cpu richiesto per la riproduzione è molto inferiore. In particolare è stato usato tantissimo su PlayStation 2, la quale può riprodurre direttamente audio ADPCM senza scomodare la CPU, ma oggi con i processori ben più potenti che ci troviamo nei pc e nelle consoles, questo formato ha molto meno senso di essere utilizzato. Una curiosità su ADPCM: dato che, come per l'audio non compresso, vengono salvati su file una serie di numeri (di 4 bit, uno per campione), zippando un file si ottiene una buona compressione, simile a quella ottenuta zippando un PCM (30-40%), mentre provando a zippare un lossy non si guadagna praticamente nulla, perchè in questi formati i dati sono suddivisi in blocchi, ognuno dei quali contiene le informazioni per la ricostruzione di una serie di campioni.

Finish, qui concluso questa mia piccola introduzione all'audio digitale e ai codec più famosi; ho cercato di semplificare il tutto alle cose più essenziali, giusto per dare un'infarinatura, perché ci sarebbero tante cose su cui scrivere, ma se l'argomento vi ha incuriosi potete iniziare a spulciare su wiki o chiedere a zio Google.
Non dimenticatevi però quanto letto qua, perché sarà utile per il prossimo post della rubrica "A chi serve il bluray?" nel quale parlerò del secondo capitolo della saga "simbolo" PS3.

Come ormai sappiamo oggi giorno vale l'affermazione "su Internet trovi tutto".
E questo è vero! Sul web si trovano tutte le informazioni possibili ed immaginabili. Il problema, per chi come me vuole poter elaborare queste informazioni, è che questi dati non sono sempre fruibili in modo ottimale ai nostri scopi, e soprattutto, non sono utilizzabili "all'istante" perchè per poterle avere disponibili dobbiamo sempre scaricarli dal Web.
Ed è qua che entra il gioco il Web Scraping.
Per citare la Wiki inglese si può dire che Web scraping is a computer software technique of extracting information from websites. Usually, such software programs simulate human exploration of the World Wide Web. In parole povere quello che voglio proporvi oggi è un approccio per poter scaricare automaticamente in locale le informazioni contenute in una o più pagine web, e per poterle poi elaborare nel modo che si ritiene più opportuno.
D'altro canto cercherò anche di offrire delle soluzioni e dei metodi per potersi eventualmente difendere da tutto ciò, perchè come si dice "le informazioni sono fonte di potere".

Ho cominciato ad interessarmi a questa tecnica quando ho avuto la necessità di catalogare decentemente le diverse centinaia di fumetti che possiedo, per esempio in un piccolo database, e non volendo inserire tutti i dati a mano (cosa che mi sarebbe costata decine di ore) ho deciso di vedere se potevo recuperarli dal web (cosa che mi è costata solo qualche ora di lavoro). Il progetto è al momento in fase di stallo per via del poco tempo che ho da dedicargli, però la fase di recupero dati è stata ultimata con le tecniche di cui vedremo le basi più avanti.

Da dove partiamo? Le pagine Web!
I più sono abituati a vedere le pagine web all'interno dei browser, con tutti i link luminosi, i banner pubblicitari, le scrittine colorate, le immaginine animate e tutto quello che piace ai bimbetti. Ma è anche possibile vedere una pagina web come puro e semplice codice HTML (per esempio da FireFox è possibile vedere il codice di una pagina premendo la combinazione di tasti CTRL+U), e quindi vedere come è fatta e strutturata.
Il trucco su cui si basa il web scraping è che possiamo, tramite un programma esterno al browser (non deve infatti essere per forza un plug-in di qualche browser esistente, può anche essere scritto personalmente), scaricare il codice di una pagina come semplice stringa di caratteri per poi poterci lavorare sopra.
Se ci riflettiamo anche il browser, anche se in modo subdolo e senza dirci mai nulla, fa più o meno la stessa cosa: utilizza la URL della pagina per identificarla, poi ne scarica il codice che la definisce, dopo di che lo analizza per costruirne una sua rappresentazione interna, ed elabora tale rappresentazione per costruire/renderizzare la pagina finale che ci viene mostrata.
Se quindi questo lavoro lo può fare un browser perchè non lo possiamo fare anche noi piccoli programmatori della domenica?
Spero che abbiate un po' di conoscenze di programmazione, perchè le parti che seguono conterranno vari esempi (in questo caso scritti in C#)
Quel che mi accingo ora a fare è quindi un qualcosa di simile a quello che fa un browser: vedremo come scaricare la pagina come codice stringa di caratteri, come elaborarla per renderla più facilmente interrogabile e come estrarre le informazioni che contiene.
Naturalmente il browser fa tantissime altre operazioni su una pagina web, come memorizzarla nella cache, scaricarsi le immagini, aggiornare la cronologia, etc.

Scarichiamo il codice di una pagina!
Partiamo con il fornire una metodologia per scaricare la pagina web che ci interessa. Naturalmente per fare questo abbiamo prima di tutto bisogno della URL della pagina, che utilizzerò per identificarla e scaricarla. Senza URL non possiamo nemmeno cominciare!
In un progetto C# abbiamo bisogno di aggiungere questa riga in cima al file
using System.Net;
che ci permetterà di utilizzare l'oggetto WebClient, un componente del .Net framework che ci offre dei metodi per scaricare risorse dal web.
Questo componente offre tantissime funzionalità, ma a noi interessa solo come scaricare una pagina come stringa, ed ecco un piccolo esempio, dove suppongo di voler scaricare dal sito www.schiacciatecomics.it il codice della pagina dei dati dettagliati del primo numero di Annichilimento (che tra l'altro è una saga di cui consiglio la lettura... a buon intenditore poche parole):
WebClient webClient = new WebClient();
string urlDellaPaginaCheVoleteScaricare = "http://www.schiacciatecomics.it/productDetail?viewItem=30071";
string respHtml = webClient.DownloadString(urlDellaPaginaCheVoleteScaricare);
Eseguendo questo codice vi troverete in respHtml il codice html della pagina di cui avete passato l'url.

Adesso che abbiamo il codice della pagina come lo possiamo analizzare per estrarre le informazioni? Perchè ora come ora il codice della pagina si presenta come un'immensa stringa contenente puro html, e non è molto utilizzabile.
Il primo approccio che ci viene in mente può essere quello a forza bruta, e cioè della ricerca ed estrazione delle informazioni. Ma questo ci porterebbe ad uno studio approfondito di TUTTO il codice della pagina solo per essere in grado di individuare dove si trovano i dati. Questo approccio ci costringerebbe a controllare e studiare come viene scritto il codice html, e per estrarre un certo valore dovremmo affidarci una specie di ricerca di sottostringhe. Un lavoro che in questo frangente porta via tanto tempo ed è anche molto impreciso. Ed è una cosa che personalmente voglio evitare come la peste.
E allora come si può semplificare? Il mio obiettivo è arrivare a ridurci a studiare solo quei frammenti di codice html che contengono i dati che vogliamo recuperare, senza impazzire nella ricerca delle informazioni.

Per poter comprendere come fare devo fare una piccola deviazione, ed accennarvi al DOM, il Document Object Model.
Mi piacciono le citazioni, e quindi riprendendo la Wiki italiana su tale argomento "Il Document Object Model è una forma di rappresentazione dei documenti strutturati come modello orientato agli oggetti". In questo caso il DOM si presta bene ad una rappresentazione ad albero. I browser solitamente si costruiscono internamente il DOM della pagina web che devono visualizzare, e lo utilizzano per disegnare correttamente il tutto.
Ogni nodo del DOM di una pagina HTML contiene un pezzettino di informazione, comprendendo gli attributi del tag come il contenuto del tag stesso. Per fare un esempio il nodo padre di tutto il documento lo possiamo vedere come il nodo costruito per il tag <html>. Questo nodo avrà poi (solitamente) 2 figli, relativi ai tag head e body, che poi a loro volta avranno altri figli per definire le varie parti della pagina html.

Ok ora possiamo tornare al nostro problema di estrazione dei dati dalla stringa rappresentante la pagina html. Ma come si trasforma la stringa che abbiamo scaricato in un DOM?
Tranquilli! Non intendo certo proporvi la soluzione "mi costruisco a mano il programma per convertirlo", perchè questo sarebbe un lavoro mastodontico ed inutile (oltre che masochistico). Una delle leggi fondamentali su cui ci si basa l'informatica è "se qualcosa esiste, non stare a rifarla ma utilizzala". Quindi intendo proporvi l'utilizzo di una libreria liberamente scaricabile che si chiama Html Agility Pack. Con questa libreria possiamo ottenere un DOM partendo dalla nostra stringona.

Dopo aver importato la libreria nel nostro progetto dobbiamo riferirla aggiungendo questa riga al corpo degli using in cima al file.
using HtmlAgilityPack;
Supponendo sempre che la nostra variabile respHtml contenga il codice html, possiamo aggiungere quanto segue al precedente esempio:
HtmlAgilityPack.HtmlDocument htmlDoc = new HtmlAgilityPack.HtmlDocument();
htmlDoc.OptionFixNestedTags = true;
htmlDoc.OptionOutputAsXml = true;
htmlDoc.LoadHtml(respHtml);

Perfetto!
Ora htmlDoc conterrà il DOM della pagina html che ci siamo scaricati, e potremmo leggerlo (e volendo modificarlo) in modo molto più semplice.

Estraiamo i dati!
Per fare questo ci viene sempre incontro html agility pack: possiamo estrarre i dati dal DOM utilizzando delle interrogazioni definite tramite XPath. XPath è un linguaggio nato per interrogare file xml, le cui espressioni permettono di identificare e recuperare i nodi, di un documento xml, che soddisfano le condizioni definite dall'espressione stessa. So che qualcuno tende ad odiare xml per il fatto che è drammaticamente e fatalmente ridondante e tende ad occupare molto spazio in più del necessario (alle volte anche qualche decina se non centinaia di volte lo spazio effettivamente richiesto), ma io lo trovo molto comodo per la serializzazione e scambio di dati.
Parlo di xml perchè appunto XPath è nato per lavorare su xml, e ora che con html agility pack abbiamo ottenuto il DOM della pagina web possiamo lavorarci come si lavora su un documento xml. Questo perchè un documento xml è visto come una struttura ad albero (avete mai provato ad aprire un file xml con un browser? Quello che vi proporrà è una visualizzazione ad albero del documento).
Non è mia intenzione entrare nel dettaglio di XPath, quindi dovrete cercare di imparare qualcosa da soli. Però per farvi un esempio, per recuperare tutti nodi relativi alle immagini di una pagina html si può usare l'espressione
HtmlNodeCollection colls = DocumentNode.SelectNodes("//img");
e per recuperare tutti i nodi relativi ai link contenuti nella pagina si può usare
HtmlNodeCollection colls = DocumentNode.SelectNodes("//a");
o per recuperare i nodi relativi ai link che appartengono alla classe idProd (tanto per fare un esempio di condizione)
HtmlNodeCollection colls = DocumentNode.SelectNodes("//a[./@class="idProd"]");
Naturalmente questi sono solo dei piccoli esempi, ma le potenzialità sono enormi. E cavolo, se siete arrivati a leggere fino a qua credo che la voglia di "spippolare" su questa roba ce l'abbiate! ^^

Adesso possiamo tranquillamente scorrere la nostra collezione di nodi, che abbiamo recuperato con una sola istruzione, e salvarla su di un file (per esempio in un bel documento xml, così tanto per strutturare per benino i dati e farmi odiare ancora di più), o inserire direttamente il tutto in un database.
La scelta di quello che volete fare con le informazioni che avete ottenuto è vostra.

Come forse si può intuire dalle piccole espressioni XPath che ho scritto, dobbiamo sempre avere una minima conoscenza di come è strutturato il codice html della pagina, quali sono i nodi che ci interessano, cosa li caratterizza e che quindi ci permette di identificarli e di selezionarli tra tutti i nodi del DOM. Un po' di tempo va sempre perso nel capire dove sono i dati, ma rispetto all'approccio di forza bruta, la ricerca a mano di particolari sottostringhe all'interno del codice html, l'estrazione dei dati tramite XPath è molto più rapida e semplice!

Automatizziamo il recupero di più pagine!
Rimane ora il problema di come automatizzare la richiesta di più pagine, senza dover passare la URL a mano al programma.
Io personalmente ho utilizzato il web scraping su quei siti che hanno la possibilità di recuperare i dati di un fumetto tramite il loro identificativo.
Se come detto la URL pagina di un singolo fumetto è
http://www.schiacciatecomics.it/productDetail?viewItem=30071
so che il fumetto che sto guardando ha come identificativo 30071. Quindi in linea teorica io potrei cambiare il valore di viewItem nella URL (quindi sto cambiando il valore del parametro che passo al server remoto) ed ottenere le informazioni su un volume differente.
Ora immaginate di mettere tutto questo all'interno di un ciclo iterativo e di fare qualcosa tipo

WebClient webClient = new WebClient();
HtmlAgilityPack.HtmlDocument htmlDoc = new HtmlAgilityPack.HtmlDocument();
htmlDoc.OptionFixNestedTags = true;
htmlDoc.OptionOutputAsXml = true;
string urlDellaPaginaCheVoleteScaricare = "http://www.schiacciatecomics.it/productDetail?viewItem={0}";
for(int i = 0; i <= 1000000; i++)
{
string respHtml = webClient.DownloadString(string.Format(urlDellaPaginaCheVoleteScaricare, i));
htmlDoc.LoadHtml(respHtml);
//codice di estrazione ed utilizzo delle informazioni
}
A questo modo stiamo richiedendo i prodotti con identificativo tra 0 ed 1000000. Naturalmente non tutti saranno validi, ma questa è un altra cosa.
E quindi potremmo aver tranquillamente recuperato i dati di tutti i volumi.

Ci possiamo difendere?
Abbiamo visto come è possibile scaricare ed estrapolare con facilità di dati. Ma come si può cercare di difendersi? Quindi qua parlo per coloro che costruiscono i siti, che scrivono le pagine php o quant'altro e soprattutto creano, inseriscono e rendono fruibili i dati sui loro siti. Premetto che non sono molto pratico di questa parte del lavoro, ma qualche idea me la sono fatta.

Un primo approccio credo sia quello di vietare le connessioni a quei programmi che non sono dei browser (si possono riconoscere perchè i browser nella richiesta di una pagina inviano delle informazioni per dire chi sono), ma è una difesa troppo debole, dato che è possibile emulare anche questo comportamento da codice.
E allora che si fa?

Un modo è quello di utilizzare intensivamente dati caricati dinamicamente, per esempio tramite utilizzo di javascript e ajax: come ho detto prima, i browser per renderizzare la pagina si costruiscono il DOM della pagina che stanno visualizzando. Con javascript è possibile modificare il DOM che il browser si è costruito, e quindi tramite delle chiamata ajax caricare successivamente pezzi di codice html che andranno ad aggiungersi a quello che il browser ha precedentemente recuperato, e quindi a modificare il DOM e la renderizzazione della pagina.
Questo fornisce un primo livello di difesa, perchè è il browser stesso che si occupa di eseguire i javascript per il caricamento di informazioni aggiuntive, cosa che chi scrive un programma per fare scarping è costretto ad implementarsi da solo: se ci pensate prima abbiamo scaricato la pagina come una pura e semplice stringa testuale, quindi non c'è nessuna esecuzione del codice javascript presente nella pagina, e questo vuol dire che nel DOM che ci eravamo costruiti non ci sarebbero stati i nodi relativi a dati caricati tramite javascript.

Un altro modo è quello di utilizzare i dati contenuti nella sessione html instaurata tra il server ed il client in questione per decidere come costruire il codice finale della pagina. Per esempio si può pensare di tenere nella sessione l'utente che ha effettuato il login, in modo che se manca questo dato il server non genera nessun codice html, e quindi chi tenta di scaricare i dati non vedrà nulla.
Come per i javascript il browser si occupa in un qualche modo di tenere viva la sessione con il server, mentre nel caso del piccolo programmatore che fa scraping si dovrebbe gestire la sessione a manina, cosa che può risultare essere un po' laboriosa.

Un altro modo per proteggere i dettagli dei nostri prodotti è di utilizzare identificativi casuali: invece di utilizzare id numeri progressivi (come fanno spesso molti siti) si potrebbe utilizzare id numerici molto lunghi e generati "casualmente", per esempio come risultato di un hash MD5 o SHA? In questo modo sarebbe quasi impossibile che qualcuno riesca a fregarci i dati richiedendo mano a mano tutti gli id incrementando il valore di volta in volta, perchè valori del genere avrebbero un limite superiore molto alto, e la distribuzione degli id validi non sarebbe predicibile a priori.

Ma si può effettivamente evitare il Web Scraping?
In linea teorica no, dato che tutto quello che è visibile dal browser può essere recuperato (in modo più o meno artificioso) anche attraverso un altro programma. Si può tentare di rendere la vita più difficile a chi vuol scaricare le nostre informazioni, ma dobbiamo renderci conto che quello che mettiamo online è pubblicamente visibile da tutti, e quindi in un modo o nell'altro se lo possono prendere.
Pensateci bene: se qualcosa lo potete vedere sul browser allora ve lo potete in un qualche modo prendere.

Tutto questo è un argomento un pelino complesso lo so.
Spero però che vi sia interessato.

Saluti a tutti.

Odino

Sto cercando in questo periodo di sviluppare un giochillo per xBox 360 utilizzando XNA, e l'altra sera mi son deciso a studiare un po' sul "problema audio". Mi son messo da bravo nerd-developer a leggere il manuale di programmazione che mi sono comprato, solo che mi son bloccato alla seconda pagina del capitolo, alla frase "1. Open the tool...". Già... non riuscivo proprio a lanciare l'applicativo. Eppure ero sicurissimo che la prima volta che avevo installato l'XNA framework su questo pc tutti i programmi partivano senza nessun problema!
Il manule in questione spiega come utilizzare XACT (Microsoft Cross-Platform Audio Creation Tool), solo che questa volta il programma non voleva proprio saperne di partire. Non è che apparisse un cavolo di splash screen, o che venisse sollevata un'eccezione non gestita quando premevo un qualche tasto, o altro. Appena avviavo l'eseguibile mi appariva la bella finestrella di "Errore generico", che mi diceva solo l'applicazione era stata fermata perchè aveva generato un errore che gli impediva di essere INIZIALIZZATA.
Cioè... cavolo... un errore in fase di inizializzazione?

Sempre da bravo nerd mi son buttato a cercare pareri sul web, ma in questo caso la google-pedia, anche dopo un'oretta di ricerca, non mi ha saputo fornire nessun aiuto specifico per questo problema relativo a XACT.

Allora, dopo aver provato a reinstallare il pacchetto XNA, ho fatto l'unica cosa che mi fosse rimasta da fare e cioè ho effettuato l'autopsia del programma deceduto. Una volta lanciato l'eseguibile ed intercettata l'eccezione mi sono accinto a fare il debug dell'errore che ha causato la prematura morte dell'applicativo, preparandomi a passare minimo una mezz'ora solo a cercare di capire cosa avesse decretato un tale triste destino.

Con mia sopresa invece sono riuscito a scovare subito l'errore: il testo dell'eccezione mi spiegava che il font Arial non supportava lo stile Regular (o Normale).

Allora, trattenendo la mia rabbia (perchè mi stavo domando come fosse possibile che non riuscisse a trovare l'Arial), sono andato a controllare nella directory Fonts di Windows e ho scoperto, con mia enorme sorpresa, che l'Arial Regular non era affatto installato!
Mi sono rimesso a cercare e questa volta la google-pedia mi ha confermato che questa cosa è (a quanto pare) "comune" a molti. Sia sotto Vista che sotto 7 alcuni sistemi non hanno tale font installato.
Il fatto che il programma che stavo cercando di lanciare (come (forse) altri che provai in passato) non riesca a superare la fase di inizializzazione è dovuta al fatto che l'applicativo è configurato per utilizzare questo tipo di font e NESSUN ALTRO, senza cioè avere una seconda opportunità di scelta in caso di font mancante, oppure semplicemente perchè è cablato per ricercare l'Arial Regular e se non lo trova si "arrabbia" con noi sollevando eccezioni a destra e sinistra.

Ancora non ho capito se questo problema è effettivamente così comune a tutte le versioni disponibili di 7 , se è o meno diffuso anche su Vista, o se per un qualche errore questo font sia stato cancellato dalla directory dei Fonts (anche non capisco come, dato che non sono andato mai a modificarla).
Sinceramente è una cosa che mi lascia un po' perplesso... O forse dovevo semplicemente fare alcuni degli aggiornamenti automatici che ogni tanto mamma Microsoft ci propone?
Altra cosa più strana è che anche cercando su vari forum non sono riuscito a trovare una spiegazione decente del perchè sia potuto accadere ciò. Molti utenti di lamentano di molti font scomparsi misteriosamente. Possibile però che nessuno abbia una spiegazione decente a tale fenomeno? Anche perchè posso capire che i font che non sono utilizzati in una cerca zona non siano installati completamente e che quindi vadano installati anche manualmente, ma non capisco come mai font che vengono utilizzati regolarmente spariscano così da un giorno all'altro.

Comunque la soluzione a questo problema c'è: al seguende link, EUupdate, potete scaricare l'aggiornamento per i font europei, che dovrebbe ripristinare il mio mancante Arial Regular, oltre ad altri font naturalmente.
Nel caso abbiate bisogno di più scelta vi posso consigliare Microsoft Typography, il quale vi darà sicuramente una possibilità di scelta molto più ampia e personalizzata.
Se invece avete sottomano il cd/dvd del vostro S.O. potete semplicemente recuperare i font dal cd/dvd di installazione, oppure copiarli da un altro pc che li abbia.
Tanto per chiarire e confermare che non mi sono inventato tutto vi confermo che una volta scaricato ed installato l'aggiornamento il mio odiato XACT è partito senza problemi

Certo che alle volte son proprio le cose più strane che ci creano i problemi più grandi.

Di cosa stiamo parlando? Ebbene sì. Anche fra i Nerd esistono le confessioni religiose. E possono assumere varie forme e caratteristiche, a seconda di come sono venerate.

Ma non è come la religione tradizionale, affatto. Esistono tante ed illimitate fonti di credo, che molto spesso coincidono.

Il problema nasce quando due o più fedi si scontrano, e da lì è possibile vedere tutto il risvolto intrinseco della violenza dell'animo umano, pronto a dare battaglia per schiacciare gli infedeli sotto le proprie assolute convinzioni.

In questo post voglio parlarvi del mondo dei sistemi operativi, uno dei più antichi dove si combattono ancora oggi le più sanguigne battaglie che l'umanità informatica abbia mai conosciuto.

I Windows Faggotti.
Chiamati volgarmente winari, winzozzi, winzozzoni, corrotti di Microsoft, "Quelli di Redmond" e via discorrendo.

Il redmondiano medio è solito aggirarsi usando soltanto sistemi closed-source e dispositivi con interfacce e controlli proprietari, ovviamente avendo pagato un'esigua somma (o talvolta, sottoscrivendo un abbonamento) per l'utilizzo.
Il caso vuole che questa sia la specie più diffusa su tutto il globo, in quanto il sistema operativo di casa Microsoft è il più utilizzato in assoluto in ambito videoludico e professionale (eccetto alcuni ambiti). Bisogna riconoscere di fatto la semplicità intrinseca di come è stato concepito, unita ad un'interfaccia comoda e user friendly (e non parliamo della pirateria, che è meglio).
Chiaramente poi il perchè sia così diffuso è sempre il solito: il nerd alla fin fine è un videogiocatore, ed i giochi (almeno la maggior parte) hanno un'unica piattaforma: Windows.
Come riconoscerlo: ha la generale attitudine di copiare tutto ciò che sembra cool ed appetibile, e ama pensare in finestre. Tende inoltre a non farsi domande se esistono sistemi alternativi, e se esistono non se ne cura, in quanto non è solito riflettere su cosa sia veramente efficiente e cosa no. I sintomi precludono la predisposizione del "ok funziona, ma non m'interessa come, nè m'interessa cambiarlo o aggiornarlo" che fa arrabbiare e uscire dai gangheri gli utenti più smaliziati che ci tengono a conoscere a menadito come lavora il proprio sistema.
Vista la grande diffusione tende anche ad armarsi con utility di antivirus e antispyware, considerando che non è raro che si becchi qualche influenzella ogni tanto (a volte è talmente imbottito di questi farmaci che non possiede un sistema immunitario vero e proprio).
La divinità principale e maggiormente adorata dai Winzozzoni è San Stivio Ballmer I (volgarmente detto Steve Ballmer)  da Redmond:

Papa Ballmer I

E la loro preghierina recita più o meno così:

Windows nostro, che sei monitor, sia santificato il tuo Aero, venga il tuo Azure, sia fatta la compilazione del .NET framework, così nel netbook che nel desktop. Dacci oggi la nostra schermata blu quotidiana, e rimetti a noi i nostri bachi, come noi li rimettiamo ai nostri sviluppatori, e non c'indurre in tentazione, ma liberaci dal pinguino, amen.

I Linux Faggotti
Chiamati volgarmente Linari, Linari Mannari o Talebani di Linux

Il linaro medio solitamente si aggira per la vita decantando le lodi della shell di linux. E' totalmente open-source nel modo di pensare e prendere decisioni, cosa che a volte può sconvolgerlo se si ritrova a farlo in gruppo, in quanto di mente libera e aperta deve poter ascoltare le opinioni di tutti e trovare una soluzione comune.
Il suo miglior compagno di viaggio è un carretto con un server (rigorosamente Debian o Gentoo, a seconda della filosofia adottata, oppure una Distribuzione Linux creata ad Hoc con kernel ricompilato) autoalimentato in qualche maniera. E' acerrimo nemico del mondo Windows e Apple, nutrendo particolare odio per entrambi, seppur con ragioni diverse.
Come riconoscerlo: ha la mania di prendere qualsiasi cosa e smontarla (facendole "a pacchetti"), per poi donare gratuitamente ad un'altra persona il frutto del suo lavoro, corredato chiaramente di documentazione sufficiente a farla funzionare (ed eventualmente rimontare). Necessariamente viaggia con almeno 3 tastiere, vista la sua attitudine di digitare freneticamente per far funzionare il suo server alimentato a criceti (la cosiddetta sindrome da "Dita d'Acciaio").
Chiaramente trascorre i minuti prima di andare a letto col suo fidato manuale di bash per inventarsi uno script più complicato dell'altro che ha inventato la sera precedente, anche soltanto per risparmiare qualche ciclo di memoria.
Hanno la tendenza maniacale di voler sapere TUTTO quel che sta facendo il sistema in quello SPECIFICO momento, in quanto per loro è importante che il sistema si comporti ESATTAMENTE come vuole lui; non a caso vedono molto di mal'occhio le altre due piattaforme, in quanto vengono spesso definite da costoro "pachidermi inaffidabili che torturano il povero hardware".
Sfortunatamente non gode di una vasta diffusione come l'acerrimo rivale Windows o Macintosh, anche se trova enormi consensi in ambito server.

Tradizionalmente venerano il Tux, il pinguino che è l'icona di questo sistema operativo:

Mr. Tux

E la loro preghierina recita più o meno così:

Mio Tux, mi pento e mi dolgo con tutto il cuore del mio Windows, perchè peccando ho meritato i tuoi Kernel Panic, e molto più perchè ho offeso te, infinitamente buono e degno di essere ricompilato sopra ogni cosa.
Propongo con il tuo santo aiuto di non offenderti mai più e di fuggire le occasioni prossime di peccato. Tux, misericordia, perdonami.

I Mac Faggotti
Chiamati volgarmente Macachi

Il macaco medio è il classico ragazzetto fighetto che sa fare allo stesso tempo solo due cose:

- Essere più cool & trendy dei colleghi Winari e Linari.
- Far finta di essere tecnologicamente più avanzato, anche se questo significa molte volte di privarsi di alcune libertà.

Tendenzialmente nasce e rimane concepito soltanto per il mondo Apple. Non possono esistere variazioni e divagazioni in merito, affermandosi superiori in tutto ciò che fanno. Esiste un unico standard, un unico dio in cui credere ciecamente, nessuna obiezione, nè una virgola fuori posto.

Come riconoscerlo: iPod Touch in tasca o iPhone all'orecchio, veste di bianco in modo semplice e asciutto, tende a camminare a testa alta facendo sfoggio dell'ultimo gingillo tecnologico alla moda, anche se completamente inutile, "tanto Apple fa figo", semplifica e cerca di reinventarsi le cose che tutti fino ad oggi usavano celermente, costringendo sè stesso a reimparare daccapo l'utilizzo del Macintosh (non ditegli PC, o s'incazza).
Difende sempre a spada tratta la casa di Cupertino, anche se questa tenta di metterglielo nell'ano più volte.

Essi adorano sua Signoria cardinal Jobs III:

Sua Signoria Cardinal Jobs III

E la loro preghiera recita più o meno così:

Credo in una sola Apple, Madre Onnipotente, creatrice del bit e del byte, di tutte le cose visibili e invisibili.
Credo in un solo Signore Jobs, unigenito figlio di Dio nato dal Padre prima di tutti i sistemi maligni. iPhone da iPhone, iPod da iPod, Mac vero da Mac vero, generato, non creato, dalla stessa sostanza del Padre, Per mezzo di Leopard tutte le cose sono state create. Per noi uomini e per la nostra salvezza discese dal cielo e per opera di iLife si è incarnato nella Time Machine e si è fatto macchina. Fu crocifisso per noi sotto Bill Gates, morì e fu sepolto e il terzo giorno è resuscitato secondo le condizioni del contratto di Snow Leopard ed è salito al Cielo e siede alla destra del Padre ed ogni volta verrà nella gloria per giudicare i vivi e i morti ed il suo Regno non avrà fine.
Professo un solo sistema operativo Apple per il perdono dei peccati e la vita nel futuro OS che verrà, amen.

Con quest'ultima religione concludiamo la nostra piccola analisi di oggi sulle fedi dei sistemi operativi. In futuro vedremo di analizzare altre amene religiosità in altri ambiti. Ci auguriamo che la lettura sia stata interessante, alla prossima puntata!