Il Blog di Fabrizio Mondo

Universo Multimediale – Come vendere il piombo per oro

agosto 5, 2010 11:29 am

Universo multimediale è un azienda presso la quale ho lavorato nel 2004/2005. Ci tengo a scrivere questo articolo per raccontare, ad anni di distanza, le dinamiche lavorative di questa azienda, in cui sono andato a finire.

Questo articolo verterà solo sulle dinamiche aziendali viste dal punto di vista della cosiddetta ultima ruota del carro, quale io ero. Sono relegate ai commenti e ad eventuali richieste, le mie movenze e le mie avventure quotidiane e pratiche all’interno dell’azienda (o forse ad un altro articolo).

L’azienda si occupa di vendita di materiale informatico, in particolare computer ed enciclopedie su cd o dvd, ma quello che è interessante è scoprire il COME tutto ciò viene venduto.

Per spiegare ciò dobbiamo fare una panoramica più ampia del lavoro settimanale dell’azienda.

Ad inizio settimana lavorativa, alcuni dipendenti dell’azienda si recano in una scuola (meglio se in provincia che non in una grande città) e distribuiscono ai bambini all’uscita da scuola delle brochure colorabili in cui c’è scritto che compilando un modulo con nome cognome e numero di telefono, e facendo un disegnino, si sarebbe potuto vincere un premio.

I bambini lo prendono, lo colorano, lo compilano, e lo restituiscono l’indomani alle stesse persone, che hanno così recuperato un gran numero di disegni con nominativi.

A questo punto tutte queste schede vanno ad un call center che provvederà a chiamare TUTTI i bambini indistintamente a prescindere dal disegno fatto. Il call center non da nessunissima informazione su niente, dice solo a ciascuna famiglia che il disegno è stato scelto e che hanno vinto un premio. Per ritirare il premio, devono recarsi in un albergo, dove cominciava il mio lavoro.

Le famiglie venivano fatte accomodare e si spiegava loro che per avere il premio, il bambino o la bambina doveva prima assistere ad una “presentazione pubblicitaria” che in realtà era un tentativo di vendita abbastanza energico.

Tutti i trucchi che venivano utilizzati per vendere non sono oggetto di questo articolo, ma di successivi in cui spiegherò cosa facevo nel dettaglio ad ogni party.

Se il tentativo di vendita andava a buon fine, si faceva firmare alla famiglia un contratto di vendita di un enciclopedia multimediale su cd, ad un prezzo che nessun essere dotato di senno avrebbe mai accettato.

Il prezzo veniva proposto rateizzato a condizioni che poi si sarebbero rivelate non vere, vedrete ora perchè dico questo.

Nel caso in cui la famiglia non avesse avuto un pc, la vendita cambiava, aumentando di prezzo il tutto. Si arrivava a proporre un pc (di potenza e qualità discutibile) con un’enciclopedia, anche a 4788 euro.

Se la famiglia firmava il contratto, veniva accompagnata alla macchina e veniva fissato un appuntamento per la consegna del tutto, mentre se la famiglia non accettava, veniva dato un regalino (valore commerciale un euro) al bambino, e accompagnati in macchina cercando di evitare che le persone parlassero tra loro.

Il party finiva, e si faceva il conto dei contratti firmati.

A partire dall’indomani, cominciava la fase consegna, quella che tutti i venditori del party attendevano con maggiore ansia.

Il consegnatario con una spallina che si occupava di montare il computer o installare l’enciclopedia (lavoro che ho fatto anche io) si occupava di effettuare il VERO contratto, ovvero quello con la finanziaria.

Se il contratto con la finanziaria veniva firmato, la famiglia era vincolata a pagare quanto dichiarato dal contratto. La maggior parte delle volte, qualora la finanziaria potesse davvero fare una rateizzazione per la persona, si vedevano condizioni di pagamento TOTALMENTE diverse rispetto a quelle proposte in sede di vendita al party.

Ricapitoliamo le fasi di lavoro:

  1. Consegna schede ai bambini a scuola
  2. Ritiro schede e raccolta nominativi
  3. Consegna nominativi al call center
  4. Assegnazione appuntamenti alle famiglie
  5. Party aziendale con proposte di vendita
  6. Validazione credenziali bancarie degli acquirenti
  7. Consegna Pc e/o enciclopedia
  8. Firma contratto di rateizzazzione tramite prestito personale

Il tutto comincia facendo credere ai bambini di avere vinto un premio, e finisce con una famiglia che, se non sa farsi valere o non capisce di cosa si sta trattando, si inguaia a volte anche per 60 mesi per un pc che spesso, prima era stato utilizzato al party per mostrare come funzionava la stessa enciclopedia.

Come convolvere una funzione qualsiasi con una funzione rect

luglio 25, 2010 3:30 pm

RECT!
Questo articolo riguarda la teoria dei segnali, un campo dello scibile ovviamente fondamentale per chi (come me!) vuole diventare un professionista nel campo delle telecomunicazioni.

Questo articolo parla di convoluzione, un operazione che per chi è nel campo dell’ingegneria dell’informazione, deve essere automatica come il fare le addizioni.

Supponiamo di dovere convolvere questi due segnali:
Primo segnale

analiticamente descritto da:

Analitico

E una semplice funzione rettangolo:

Primo segnale

definita da questa casistica:

Analitico

Per effettuare la convoluzione tra i due segnali possiamo agire in più modi.

  • Il primo modo è utilizzare la definizione, scopriremo che in questo caso, è il modo più complicato.La definizione di convoluzione tra due segnali è la seguente:

    Analitico

    In questo caso, tutto si riduce a muovere una rect da meno infinito a più infinito e effettuare, istante per istante con continuità, il prodotto tra i due segnali, e quindi integrare.

    Il grafico dell’integrale del prodotto, istante per istante, darà la funzione di convoluzione tra i due segnali.

    Possiamo notare che sicuramente, se i due supporti non si intersecano, il loro prodotto è nullo, per cui si avrà convoluzione da quando la finestra rect tocca l’altro segnale, a quando si stacca, dopo averlo attraversato. Ciò giustifica visivamente il perchè la convoluzione abbia supporto pari alla somma dei supporti dei segnali di partenza.

    Convolvere questi due segnali tramite la definizione è abbastanza semplice, data la natura della rect, ma è possibile operare in modo molto più semplice, vediamo come.

  • Il secondo modo è utilizzare la proprietà di derivazione e di elemento neutro della delta di dirac.
  • La regola di derivazione ci dice che la derivata della convoluzione si ottiene convolvendo uno dei due segnali con l’altro derivato.

    Deriviamo allora la rect:

    Derivata della rect

    Otteniamo due delta di dirac (rappresentate dalle frecce) che, da letteratura, sappiamo che sono elementi neutri della convoluzione.

    Tutto adesso si riduce a dovere banalmente SOMMARE il segnale di partenza, traslato di -2, e lo stesso segnale di partenza, traslato di più due e ribaltato.

    Segnali sovrapposti

    Adesso sommiamo i due segnali…

    Segnali sommati

    Adesso occorre soltanto integrare!

    Convoluzione finale

    P.S le immagini hanno degli errori e la convoluzione potrebbe non essere numericamente esatta. Il procedimento è perfettamente coerente, provvederò a sistemare al più presto le cifre.

    Come creare una web radio con Linux, Icecast e Ices2 (Guida avanzata) – Ices-Alsa

    maggio 3, 2010 3:59 pm

    Alsamixer
    Settantasettesimo articolo dedicato alle web radio.

    Cominciamo le guide avanzate dedicate ad icecast su linux, studiando i file XML di esempio che vengono forniti a corredo con ices2.

    E’ chiaro che il server icecast può non essere utilizzato necessariamente con ices2, ma in questo caso, risulta secondariamente necessario alla trasmissione (quantomeno per passare da un livello amatoriale ad uno semi-professionale) conoscere e sapere manipolare i file di configurazione, che in questo caso sono del tipo Extensive Markup Language.

    Il primo di questi file che considereremo è quello dedicato allo streaming da ALSA. Alsa sta per Advanced Linux Sound Architecture e contraddistingue in questo caso una modalità di streaming improntata sul live o sull’ingresso della scheda audio, ad esempio un banale simulcasting.

    Andiamo quindi a considerare le parti di questo file, che è meglio ricordare, si trova in /usr/share/doc/ices2/examples

    La prima parte del file è questa:

        <!-- run in background  -->
        <background>0</background>
        <!-- where logs go. -->
        <logpath>/var/log/ices</logpath>
        <logfile>ices.log</logfile>
        <!-- size in kilobytes -->
        <logsize>2048</logsize>
        <!-- 1=error, 2=warn, 3=infoa ,4=debug -->
        <loglevel>4</loglevel>
        <!-- logfile is ignored if this is set to 1 -->
        <consolelog>0</consolelog>

    Il tag background va settato ad 1 se si vuole porre ices in background.

    Il tag logpath identifica una directory che può essere scritta dall’utente che ices2 sta identificando. Può essere piazzata ovunque, ma chiaramente devono essere abilitati i permessi di scrittura.

    Il tag logfile identifica il nome del file di log. Alla riapertura del log file l’esistente viene rinominato come “logfile”.1

    Il tag logsize indica la massima grandezza del file di log prima di andare in modalità ciclica di scrittura.

    Il tag loglevel Indica un numero che rappresenta il livello di logging prescelto.
    1 – Loggati solo i messaggi d’errore
    2 – Come il punto uno, ma anche i Warnings verranno loggati
    3 – Come il punto due, ma anche i messaggi informativi verranno loggati.
    4 – Come il punto tre, ma anche i messaggi di debug verranno loggati.

    Il tag consolelog, se impostato ad 1 causa l’apparizione dei messaggi loggati in console, piuttosto che in un log file.

    Nelle applicazioni più sensibili al ritardo (tra cui OVVIAMENTE una radio), è sconsigliato avere logging in console. E’ un opzione utile in fase di studio del software.

    Il tag pidfile consente di creare un file in cui è scritto il ProcessID del processo ices2 corrente.

    Veniamo adesso alla sezione stream.

    La sezione stream è composta da tre sottoparti, chiamate metadata, input e instance.

    Esaminiamole tutte e tre nel dettaglio.

    Metadata intuitivamente si capisce già su cosa abbia influenza, ovvero si occupa di trasmettere tutti i dati a corredo della trasmissione stessa.

    Le sue sottoparti sono nome, genere, descrizione e url, esattamente gli stessi campi che si trovano in generale nei server shoutcast, ma in realtà praticamente in tutti.

    Input invece tratta la parte hardware della trasmissione, vediamo come.

    Module, ci indica di scegliere quale modulo hardware stiamo trattando, qui si parla di alsa, per cui scriviamo alsa.

    I successivi parametri sono rate, channels, device e i metadata.

    Rate indica la frequenza di campionamento del segnale analogico di partenza. E’ normalmente settata a 44100 hertz, se non sapete come mai, vi invito caldamente a leggere il teorema divino.

    Channels indica se vogliamo una trasmissione mono o stereo.

    Device indica la posizione della scheda audio nell’elenco delle periferiche del nostro sistema.

    Metadata e metadatafilename rappresentano uno switch di scrittura e un nome file dove vengono scritti i metadati.

    Istance rappresenta la generica istanza di trasmissione. Dico “generica” in quanto, se conoscete il software di cui stiamo parlando, o avete letto altri articoli (non per forza di questo blog) su ices2, saprete che è un source multi-instanziabile, ovvero ha la possibilità di trasmettere, a differenza di molti software per shoutcast ad esempio, lo stesso stream a più server contemporaneamente.

    hostname indica l’indirizzo ip del server da contattare, può essere sia un ipv4 che ipv6.

    port indica la porta del processo sul server da contattare, vi ricordo che si comunica in tcp.

    password non necessità spiegazioni

    mount, identifica il cosidetto mountpoint, ovvero un particolare stream in un singolo server icecast, che può trasmettere più stream contemporaneamente.

    yp è uno switch che abilita o disabilita la visione pubblica dell’emittente.

    La sezione Encode indica i parametri di codifica dello stream, che devono matchare chiaramente quelli impostati in hardware nella sezione precedente.

    Il tag downmix è uno switch che indica se, in caso di necessità, si preferisce diminuire il numero di canali da due ad uno, ovvero passare da stereo a mono.

    La sezione Resample definisce la frequenza in hertz a cui passare in caso ad esempio di problemi di rete. Tipicamente si preferisce passare ad un valore pari alla metà della frequenza di partenza. Ricordatevi sempre che sempre per il teorema divino, se volete ricostruire senza aliasing un segnale che ha banda N hertz, avete bisogno di una frequenza di campionamento NON INFERIORE a 2N hertz. Quindi avere 22050 hertz di frequenza di campionamento, consente di sentire discretamente una banda di 10000 hertz. Sufficiente per il parlato ma non certo per la marcia turca di mozart.

    Con questa sezione finisce la parte alsa, vedremo nei prossimi articoli di considerare anche le altre opzioni possibili, ovvero OSS e una playlist.