Excel – Dynamic lists skipping blanks

Tag

english, excel tricks

Writing here in english just as a reminder of a little nice solution I found for building a dynamic list in excel skipping blank values.

Scenario: you have a column of values with blanks in between and you want to make a contiguous list (in another sheet or column) using the previous column as a source. Plus, you want to do this without using VBA or ctrl+enter, just regular excel formulas.

Say your starting column with values is G and the column where you want to put your contiguous list is K

First: you need to find the first non blank value in your column G. Use type this formula in the first cell of column K (K1)

=INDEX(G:G,MATCH(TRUE,INDEX((G:G<>0),0),0))

NOTE: this formula may vary depending on your case, the aim here is to find the first non blank value, whatever it is the formula to get it

Second: in K2 type this formula

=IFERROR(INDEX(INDIRECT(“G”&(MATCH(K1;G:G;0)+1)&”:G200″);MATCH(TRUE;INDEX((INDIRECT(“G”&(MATCH(K1;G:G;0)+1)&”:G200″);0);1);””)

G200 is just an example value, use any other value depending on the length of your source column G. The above formula is exactly the same one you have put in K1, except it dynamically changes the range of the index-match pair depending on the row number of the previous value in the column using the INDIRECT function to build the index and starting the search from the row after the one corresponding ton the non blank value found in the previous cell.

Third: drag down the formula you typed in K2 to the desired row. At some point the match function will not work any more and will raise an error. Hence the IFERROR to eliminate the #NA values that will inevitably appear.

Your formula may vary. In my case I also had to do it for multiple columns, and I needed to dynamically change not only the row but also the source colums to look into, using the super-useful formula to convert an index number into a cell letter:

=SUBSTITUTE(ADDRESS(1;D1;4);1;””)

Where in D1 I have put the source column index number to use. I also had to mix other index/match pairs in the formula, but this is another story.

Home automation: impianto o Internet of Things

Tag

domotica, home automation, internet of things, iot

Di recente ho iniziato a interessarmi di impianti di home automation perchè devo fare lavori in casa e volevo approfittare per modernizzare.

Sorvolando sull’utilità effettiva della home automation in un normale appartamento di città (cioè con tutti i comandi raggiungibili in non più di 10 secondi ovunque siano), ho quindi deciso di informarmi meglio.

C’è stato tanto sventagliare ultimamente nel settore dell’impiantistica elettrica delle nuove norme CEI per gli impianti (CEI 64-8/3), obbligatoria da fine 2011, in cui si fa menzione degli impianti “domotici”. Seguono ovviamente grandi annunci da parte di tutti i produttori di materiale elettrico, comprensibilmente interessati a vendere i prodotti di domotica, fino ad oggi considerati un po’ un lusso.

Prima di tutto cominciamo col dire che si stanno configurando due modi molto diversi di concepire la home automation in ambito domestico. Riassumendo:

• Approccio “impiantistico”: la home automation è l’impianto elettrico
• Approccio “consumer electronics”: la home automation si collega all’impianto elettrico

Approccio Impiantistico

E’  l’approccio classico, proposto dai produttori di impianti elettrici e mutuato dalla lunga esperienza in materia di building automation e sistemi di supervizione e controllo industriali (SCADA).

In sostanza qui la domotica è l’impianto stesso. Ogni componente dell’impianto (pulsanti, prese, dimmer, interruttori, sensori d’allarme, termostati, …) può essere collegato a un bus e comandato tramite un gateway che si collega al bus (una coppia di fili che entrano e escono dai vari componenti connessi) e a qualche computer di controllo. Un modo di vedere la domotica che è, in buona sostanza, una versione ridotta di un impianto industriale.

Iniziano anche a proporre componenti wireless (solitamente su Zigbee), ma cambia poco, fanno comunque parte dell’impianto.

Inutile dire che in questo caso si lavora sull’impianto, nel quadro elettrico, con lo spellafili e il cacciavite e che ovviamente serve la dichiarazione di conformità fatta da un elettricista perchè si va a intervenire sui fili.

L’intelligenza dell’impianto è centralizzata, perchè tutti gli attuatori e bottoni e componenti sono collegati a un bus (proprietario o standard che sia) ma sono controllati centralmente da un coordinatore. Non esiste “Internet of Things”, il singolo pulsante non ha idea di cosa sia Internet, si limita a mandare un messaggio sul bus quando viene premuto o rilasciato. Il controllo tramite smartphone o tramite interfaccia Web non è sul singolo oggetto, ma passa dal gateway.

I costi di questo tipo di impianti sono abbastanza pesanti, diciamo che tendono a moltiplicare di un fattore 3 o 4 il costo di un impianto elettrico standard. Per non parlare del fatto che l’impianto va programmato da uno specialista dotato di software apposito.

Sono andato a guardare questi software e non si tratta di nulla di trascendentale per chunque abbia un minimo di capacità informatiche (consideriamo che sono pensati per essere usati da un elettricista che in teoria di capacità informatiche potrebbe anche non averne…). Però rimane il fatto che quando di installano fili prese e quadri elettrici bisogna sapere bene cosa si sta facendo e la legge non sempre permette il fai-da-te (anzi, non lo permette MAI).

Approccio “consumer electronics”

Il secondo approccio, spinto soprattutto dalle startup e dai produttori di elettronica di consumo più famosi (il CES di quest’anno era stracolmo di gadget di questo tipo) vede la domotica soprattutto come “connected home”. Questo significa rendere intelligenti gli oggetti di casa, dotandoli di un qualche software e di una connessione WiFi o bluetooth in grado di parlare con smartphone, internet, servizi cloud, eccetera.

Il tutto si riassume in aggeggi collegati alla corrente elettrica di casa (o a batteria), che il consumatore può fare agevolmente con le proprie mani, senza elettricisti o altro:

• Prese elettriche comandate
• Dimmer comandati
• Telecamere
• Lampadine LED WiFi con altre funzioni integrate
• Sensori WiFi di vario tipo

Esempio di “aggeggi connessi”: Samsung Smart things

Diciamo che il trend quì è quello dell'”Internet of Things”. Cioè prendo un aggeggio normalmente meccanico, gli ficco dentro un po’ di elettronica, lo collego a Internet e lo rendo comandabile da remoto. La domotica è quindi un “overlay” sopra l’impianto elettrico.

A questo trend si agganciano anche i produttori di elettrodomestici, che stanno inserendo connettività WiFi e intelligenza in sempre più linee di prodotto.

Gli standard e l’interfacciamento

Nella domotica impiantistica esistono degli standard. C’è lo standard Konnex/EIB, c’è lo standard industriale Siemens Dali, ce ne sono anche altri che però non sono usati in ambito domestico. Poi ci sono dei protocolli più o meno documentati (ad esempio il protocollo Enocean).

In generale, però, quando si monta un impianto domotico, l’interoperabilità tra produttori di componenti diversi è ZERO, nonostante gli standard. Cioè: o si usano componenti tutti dello stesso produttore o dichiaratamente compatibili oppure non c’è speranza di avere un impianto funzionante.

Una volta fatto l’impianto, poi, interagire con lo stesso da un computer esterno (vedi: Arduino, Raspberry o altro) o non si può fare, o richiede l’uso di apposite librerie software sottoposte a licenza oppure richiede l’uso di appositi componenti di collegamento al bus (costosi) che a loro volta richiedono software appositi, ecc ecc. Insomma, l’interfacciamento con questi impianti lo si fa solo se il produttore lo consente. L’approccio è, come sempre, quello industriale: perchè dovresti voler smanettare con il mio impianto???

Nel caso dell’IoT o approccio consumer non ci sono standard nella maniera più assoluta. In passato (ho seguito una tesi di laurea sul tema) ci avevano provato con lo standard Universal PnP (UPNP), ma con scarsissimo successo perchè il mercato ancora non era pronto. Stanno provando adesso a mettere in piedi alcune cordate di produttori di elettronica di consumo: All Seen Alliance e Open Intconnect Consortium, ma ancora si deve vedere cosa combineranno.

Però il modo di ragionare è diverso: l’oggetto connesso non vuole essere proprietario, vuole essere aperto il più possibile, cioè se non c’è un SDK pronto, almeno c’è scritto come interfacciare l’oggetto, che solitamente accetta chiamate REST via Web.

Approcci a confronto

L’impiantista punta tutto sulla sicurezza e affidabilità, mentre la consumer electronics punta tutto sulle funzionalità, sui costi e sulla facilità d’uso.

L’affidabilità è sicuramente chiave quando si considera l’impianto nel suo complesso, ma diventa meno interessante quando la domotica è solo un “di più” (e parliamoci chiaro, nella quasi totalità dei casi è così).

E’ da parecchio che lavoro in questo settore e so che la semplicità (vedi Apple) ha sempre vinto su tutto il resto. Oltretutto il fatto di poter fare facilmente retrofitting in salsa domotica di impianti esistenti a poco costo favorisce di gran lunga l’approccio consumer electronics.

Magari non succederà subito, ma ho la netta impressione che sia la consumer electronics l’approccio vincente, nonostante tutto. Mentre per avere un impianto domotico bisogna essere molto, molto convinti (e investire tempo, soldi e lavori), per collegare una smart plug a una presa ci vogliono 3 minuti e qualche decina di euro.

Prossimamente proverò a guardare meglio al protocollo AllSeen, sembra interessante e c’è il codice open source.

Quando la domotica non serve a niente

Non tutti sanno che quelle poche funzioni comode della domotica sono facilmente realizzabili in un impianto elettrico senza ricorrere a bus e programmazione, ma solo con qualche filo in più nei condotti.

Esempio: le tapparelle elettriche con il comando centralizzato

Basta scegliere un attuatore per tapparelle elettronico con il contatto di uscita per il comando di salita e discesa centralizzato. Si tirano due fili fino al punto dove si vuole il pulsante di “tutte giu” e il gioco è fatto. Niente domotica e con un minimo di abilità anche niente elettricista.

Attuatore Eltako per barra DIN con comando centralizzato

Per inciso, se poi al medesimo comando si collega un Arduino con un relè e un RTC, si può anche programmare.

Circuiti stampati con il metodo Toner Transfer – La versione definitiva

Tag

diy, pcb, press'n peel, toner transfer

Da qualche tempo quando ho un po’ di tempo, mi dedico all’hobby dell’elettronica amatoriale. Dopo aver capito come progettare un circuito (digitale…), testarlo sulla breadboard, ri-testarlo sulla mille-fori, arriva il momento di passare allo steo successivo: stampare il “mio” circuito.

Uno dei punti fondamentali di qualsiasi hobbista dell’elettronica è la stampa dei PCB. Ci sono varie opzioni:

• Fai da te con bromografo, basette fotosensibili, processo di sviluppo, blablabla
• Fai da te con metodo del “toner transfer”
• Farli produrre a una azienda specializzata in modo professionale

Chiaro che la produzione professionale dà i risultati migliori di gran lunga. Il circuito è bello finito, con il silkscreen, i forni metallizzati, si può fare a doppia faccia senza problemi e il costo è abbastanza contenuto. Io con ITEAD studio mi sono trovato bene e con 20 euro ti mandano a casa 10 PCB. Questo è sicuramente il metodo giusto quando il circuito funziona, è testato e è giunta l’ora di produrlo seriamente.

Se però se ne deve fare uno solo, che poi magari nemmeno va e bisogna modificarlo dissaldando tutto, eccetera, meglio far da se. Si spende meno e si fa prima.

Non uso bromografo e fotoincisione. Troppo complicato, troppo chimico, naaahhh….

Ho sempre usato il toner transfer (stampare con stampante laser su un foglio di carta patinata, stirare il foglio sulla basetta, staccare il foglio), e le ho provate veramente tutte tutte, per arrivare al processo DEFINITIVO, almeno per me.

I fattori critici per una buona riuscita sono:

1. Il toner: ne ho provati almeno 3 e quello della HP è il migliore. Io ho una stampante laser P1102W, costa poco e funziona bene, con un toner di ottima qualità, copertura densa e uniforme. Non cambierò più marca. Sbagliare toner significa non riuscire a trasferirlo o avere risultati di trasferimento pessimi.
2. Il foglio di carta trasferibile: dopo aver provato praticamente QUALSIASI cosa, alla fine i fogli press-n-peel blu (si trovano su e-bay e su vari siti di elettronica per circa 3-4 euro a foglio A4) sono i migliori e basta.
3. Il processo di trasferimento: un ferro da stiro va bene, ma deve essere di buona qualità, con una superficie di stiratura piatta e ben livellata. Io ho una stirella con una ottima piastra in acciaio di 2 centimetri, ma non la ho comprata apposta (serve ovviamente per stirare il bucato…). Ottimi risultati si ottengono anche con i ferri per la sciolinatura, reperibili online per 30-40 euro.

Il processo di stampa:

1. Stampare il circuito su un foglio qualsiasi
2. Ritagliare il foglio press-n-peel della dimensione del circuito stampato più circa 0,5-1cm di bordo intorno
3. Appiccicare il foglio ritagliato sul foglio su cui avete stampato il circuito, con la parte opaca rivolta verso l’alto. Per appiccicarlo usare un nastro di carta da bordatura sottile (1 o 2 cm di larghezza al massimo, altrimenti è rognoso da tirare via), attaccando il bordo superiore. Attaccare SOLO il bordo superiore del foglio PnP, MAI attaccare quello inferiore altrimenti si distorce tutto nella stampante e il processo va a farsi fottere (oltre che la stampante…)
4. Rimettere nella stampante dal verso giusto: nel mio caso la stampante stampa sul lato in su, ma ci sono altre stampanti che stampano sul lato in giù. Stampare il circuito di nuovo usando il massimo setting di DPI e densità consentito (nel mio caso 1200 DPI, in altri casi “qualità foto” o simili), disattivando qualsiasi dipo di risparmio energetico o di toner. Il nero deve venire NERO
5. Staccare il nastro adesivo attentamente, evitando come la peste bubbonica di toccare con le dita la superficie stampata del PnP. Al limite usare guanti di lattice. MAI MAI MAI MAI MAI toccare con le dita: si unge e non si trasferisce più un tubo.
6. Posare il foglietto di PnP stampato col lato opaco verso il basso in un luogo chiuso non polveroso (metterlo sotto una scodella rovesciata, al limite.

Preparazione della basetta:

1. Scegliere se tagliare la basetta prima o dopo il trasferimento e l’incisione. Di solito io taglio dopo, così vedo meglio dove tagliare (tanto per evitare l’incisione della parte non stampata basta appiccicare un pezzo di nastro adesivo di plastica). Però questo va a gusti/praticità.
2. Limare bene gli angoli della basetta con una lima o con un pezzo di carta vetrata in modo che non ci siano rilievi o angoli taglienti sui bordi
3. Pulire la basetta con l’acetone
4. Passare la basetta nell’area da stampare con un po’ di lana d’acciaio tipo 00 (non più grossa, raschia troppo) in questo modo:
   1. Passare la lana d’acciaio prima in senso verticale, strofinando per bene e rapidamente. Vedrete il rame che diventa lucido
   2. Passare la lana d’acciaio in senso orizzontale, di nuovo strofinando per bene
   3. Ripetere A e B un paio di volte (così si crea una superficie con una buona striatura che assorbe bene il toner)
5. Pulire molto bene la basetta con alcool a 90° (quello denaturato va bene, purchè non profumato o con disinfettante o altre porcherie: solo alcool)
6. Appoggiare la basetta sulla superficie dove avverrà il toner transfer e NON toccarla MAI con le mani, dicesi MAI

Trasferimento:

1. Scaldare il ferro a una temperatura medio-alta (non altissima, il toner sbaverebbe). Non so a quanti gradi sia, ma credo attorno ai 150°. Scaldarlo bene, lasciandolo acceso per almeno 10-15 minuti
2. Prendere il foglietto PnP, controllare che non ci sia polvere. Se c’è toglierla usando un fazzoletto di cotone fine o un pennellino molto morbido
3. Fare lo stesso con la basetta
4. Girare il foglio PnP con la parte opaca verso il basso e appoggiarlo sopra la basetta, eventualmente allineandolo agli angoli
5. Prendere il ferro e, tenendo il PnP appoggiato (si può toccare con le mani, questo non è il lato “critico”), dare una passata con la punta del ferro senza premere troppo. Questo servirà a far attaccare il PnP alla basetta
6. Prendere un fazzoletto di cotone fine, appoggiarlo sopra il PnP e iniziare a “stirare”
   1. Passare il ferro avanti e indietro prima dal lato destro, poi centrale, poi sinistro, facendo una moderata pressione
   2. Ripetere il punto B ma in modo perpendicolare (passare su tre sezioni, anche se la basetta è più piccola del ferro, serve ad assicurare che la pressione sia uniforme)
   3. Ripetere A e B per circa 5 minuti, poi controllare: se il circuito si vede chiaramente sul retro del foglio PnP e ha assunto lo stesso profilo superficiale della basetta, è OK, altrimenti si può proseguire
7. Quando il toner è trasferito, far raffreddare un po’ la basetta e poi metterla in freezer o sotto l’acqua fredda per 2 minuti. Io preferisco il freezer perchè non bagna
8. Staccare il PnP piano piano da un angolo poi dall’altro, controllando che il toner sulle traccie si stacchi bene. Se non si stacca, si può ripetere la stiratura, ma potrebbe anche darsi che il toner sia sbagliato.
9. Se la temperatura del ferro era troppo alta o avete stirato troppo, la patinatura blu del PnP potrebbe staccarsi anche in alcuni punti dove non c’è toner. In questi casi, bisogna armarsi di pazienza e raschiare via con un piccolo cacciavite o cutter
10. Può succedere ce a causa di granelli di polvere o unto si formino alcuni “buchi” nelle tracce trasferite. Basta semplicemente controllare bene e eventualmente riempire i buchi usando una penna da lucidi a punta fine (non serve spendere soldi in penne per PCB)

A questo punto si può passare all’incisione, con l’intruglio di maggior gradimento (cloruro ferrico, acidi vari, acqua ossigenata, etc…)

Alcune note dall’esperienza:

• Alcuni spergiurano che la carta patinata delle riviste o la carta fotografica per ink jet vadano bene e costino meno della press-n-peel. E’ vero che costino meno (sono gratis!) ma non è assolutamente vero che funzionino uguale: vanno in realtà da male a malissimo. La carta si stacca male, bisogna stare minuti interi sotto l’acqua, non si capisce se è stata trasferita bene dal ferro, ogni volta la carta è diversa a causa degli inchiostri di stampa o a causa della composizione della patinatura, una vera merda. Investite 20 euri, compratevi un po’ di fogli PnP blu e fatela finita. Non ve ne pentirete.
• Non usate la carta forno, come alcune guide in inglese suggeriscono. Non so che diavolo di carta forno vendano in america, ma di sicuro non è quella che vendono qui da noi. Da noi se provate a usarla vi verrà un trasferimento sbavatissimo e scadente. Questo perchè la carta forno non ha patinatura, è solo una carta particolare poco aderente ai grassi (il toner alla fine è una specie di cera, quindi se lo si scioglie e preme, la carta formo lo spalmerà bene bene tutto intorno).
• Alcuni spergiurano che il rullo plastificatore sia meglio del ferro. Sì, può darsi, ma intanto i plastificatori da 4 soldi che si trovano in giro sono degli orrendi pezzi di plastica, vanno male o peggio e si rompono al terzo PCB o richiedono fantasiose modifiche per farli scaldare di più. Spendere 300 euro per un plastificatore professionale non vale assolutamente la pena. Se si usa la PnP come ho detto sopra stirando con il fazzoletto di cotone i risultati sono ottimi.

 

 

 

Un ringraziamento alla IBM Model M: LA Tastiera

Tag

ibm, model m, tastiera

E’ un po’ che non scrivo, ho avuto un sacco di cose da fare. Però ora ricomincio, e ricomincio con un articolo che vuole essere un piccolo tributo a un oggetto che a volte diamo per scontato quando lavoriamo a volte per ore davanti a un monitor: la tastiera. Ricomincio dalla tastiera perchè è con quella che sto scrivendo ed è con quella che scriverò ancora.

In un mondo fatto di touch screen, gesture e comandi vocali, quando arriva il momento di lavorare sul serio, è su questo aggeggio che picchiamo le nostre dita in continuazione.

Però il mio tributo non va a una qualsiasi tastiera, ma alla sola e unica Tastiera che merita la T maiuscola: la IBM Model M.

La mitica IBM Model M: unica e irripetibile

Ne ho due in casa di queste tastiere, regalo di uno zio che per tanti anni ha lavorato all’IBM come tecnico. Usavo questa tastiera anni fa, quando il PC era “Il Personal Computer IBM compatibile”, ed era ancora per me solo un gioco. Poi però era finita in un armadio, dimenticata, sostituita da altre tastiere USB, wireless e bluetooth, quella del laptop, eccetera.

Oggi mi è capitato di dover lavorare a un documento lungo, con un sacco di cose da scrivere. Sulla scrivania avevo una tastiera wireless qualsiasi. Non mi piaceva, tasti un po’ piccoli, troppo vicini, facevo spesso errori di battitura. Quella del laptop è buona, ma scrivi in una brutta posizione, ingobbito. Ho pensato: perchè non provare a tirar fuori la vecchia IBM, sai mai…

Appoggiato questo ENORME e pesantissimo blocco di plastica rigida e metallo sulla scrivania, sembrava di essere tornati indietro di 20 anni. Altro che fighetterie di alluminio con frutta masticata stampigliata in bianco sul retro. Un blocco di granito a forma di tastiera.

Quel color beige chiaro dei primi PC, niente tasto windows, niente simbolo dell’euro, il tasto “exec” al posto del control sulla destra, cavo di collegamento grosso e pesante. Nell’angolo il logo di una azienda che era il simbolo stesso dell’informatica. Per uno che lavora in questo settore era come aver appoggiato una specie di reperto archeologico sulla scrivania.

Poi ho iniziato a scrivere e non mi sono fermato più. Non ci sono altri commenti per descriverla se non: è la migliore tastiera che sia mai stata prodotta nella storia dell’informatica, dalle origini ad oggi, punto.

I tasti sono talmente perfetti che le dita quasi vengono attirate, come se ci fosse una specie di magnete sotto ogni tasto. Ogni colpo fa un piccolo “click” e ogni click è uguale agli altri, con una precisione incredibile. Quasi non vorresti smettere di scrivere.

Ha 30 anni, è vecchia quasi quanto me, ma al contempo è più nuova di tutte quelle prodotte oggi. E ne ho usate tante. Alla vecchia IBM va un grazie per aver inventato questo capolavoro di perfezione tecnologica e meccanica, che, per quanto mi riguarda, resterà per sempre sulla mia scrivania e sicuramente non tornerà più nell’armadio.

 

Sul Monte Pelmo

Tag

dolomiti, pelmo, rifugio venezia

Approfittando dell’unica giornata di bel tempo di questa estate sfigatissima (almeno in montagna), per la prima volta siamo saliti sul Pelmo (3168m). Una delle cime delle dolomiti più belle e tutto sommato più difficili da raggiungere per una via normale.

Su questa cima subito all’inizio è necessario passare una cengia (Cengia di Ball) che, per un traverso di circa 300m, presenta difficoltà tra il 2° e 3° grado ed è molto esposta, con un dirupo di 200-300m subito accanto che ti accompagna per tutta la sua lunghezza. La cengia di per se non è difficile tecnicamente, ma la sua esposizione la rende un limite insormontabile per chi non ha un minimo di pratica di scalata o soffre un po’ di vertigini.

Fortunatamente (non ringrazierò mai abbastanza chi ha preso questa decisione), la cengia non è provvista delle solite maledettissime corde o funi d’acciaio, che la renderebbero banale, attirandovi file di turisti rimbambiti. In questo modo, affronta la salita solo chi è capace, limitando anche in agosto pieno il numero di gitanti. Io sono contrario alla montagna banalizzata.

La montagna non è e non deve essere per tutti: se sei in grado e attrezzato per andarci, ci vai (magari con una guida) e ti diverti, altrimenti te ne resti a valle e la guardi dal basso.

Passata la cengia, comunque, la salita al Pelmo diventa un normale, lunghissimo sentiero dolomitico un po’ ghiaioso con in cima un lungo nevaio rimasuglio della decina di metri di neve caduti durante l’inverno. Il sentiero ha un dislivello in salita di oltre 1000m, molto ripido, ma sempre con un panorama spettacolare.

Non faccio il resoconto completo, bastano solo queste poche parole. Metto invece alcune foto che più mi fanno ricordare questa salita.

Tramonto sull’Antelao

La sera, dopo una giornata piovosa, al rifugio Venezia uno spettacolare arcobaleno sull’Antelao, in lontananza (la seconda cima delle Dolomiti, a quel che mi dicono bella da vedere ma per niente bella da salire).

Alba sul monte Cristallo

La mattina dopo, alle 5 e qualcosa, una spettacolare alba verso il monte Cristallo (sopra Cortina). Certe cose le vedi solo se stai in rifugio a dormire. Da casa o dall’albergo in valle ci si perde tutto.

Poi iniziamo a salire, ma ci accompagna un panorama della valle del Cadore con nebbie basse (viste da sopra ovviamente).

Antelao e la valle del Cadore

La foto è scura a causa del controluce, però rende bene quello che si vedeva (qui siamo a circa 2300m)

Poi, dopo una salita un po’ faticosa ma soprattutto molto lunga, finalmente la cima, con il grandioso panorama dolomitico. Un panorama che non ha pari al mondo (non scherzo, non ha proprio pari) e non smette mai di stupire, anche se la luce è poco adatta a fare belle foto.

Panorama dalla cima del Pelmo

Dalla cima del Pelmo

Nella foto si vede il Pelmetto (in primo piano) con dietro il Civetta, in lontananza la Marmolada e, ai piedi del Pelmo, la Val Fiorentina con Selva di Cadore. Sulla destra, il Formin e la Croda da Lago.

 

BigTable e Hbase: come gestire un DB quando diventa MOLTO grosso

Tag

big data, bigtable, google, hbase, hdfs, nosql, sistemi distribuiti

Personalmente ritengo che i sistemi distribuiti saranno il futuro dei sistemi informatici. Ancora oggi c’è una certa “resistenza” da parte degli IT manager, forse dovuta all’età ed all’abitudine, ad adottare questi nuovi modelli di calcolo nei propri sistemi informatici, ma il trend che spinge a decentralizzare le infrastrutture di calcolo è molto forte e prima o poi avrà il sopravvento.

Non che i DB in cluster non esistessero già, nessuno oggi si sognerebbe mai di tenere in piedi un sistema database centrale senza adottare una infrastruttura a cluster. Ma i sistemi distribuiti “big” sono un’altra cosa, sono fatti (come ho già discusso in altri post) per scalare orizzontalmente all’infinito senza intervento dell’utente.

In questo articolo parlo del famoso Google BigTable, il capostipite dei database distribuiti su larga scala, e della sua versione open source Hbase.

BigTable è nato attorno al 2004, presentato al mondo nel 2006 in un paper fondamentale, che assieme all’altro trittico GFS, MapReduce e Chubby, costituisce la base tecnologica di un sistema distribuito di (Very) Big Data management. Certo, non è l’unica possibile. Yahoo, Amazon (con il mitico Dynamo), Facebook (Cassandra) hanno proposto altri approcci, che tratterò in altri articoli, ma Google è stato decisamente il primo a mostrare al mondo come certi concetti si possano tradurre in tecnologia. Quello che si chiama Innovazione (quella vera…).

Questa è la definizione che da Google a BigTable:

A Bigtable is a sparse, distributed, persistent multidimensional sorted map.

Per il volgo viene presentato come “database di tipo key-value a colonne”, che ricade nell’insieme di nuovi sistemi DB di stampo scalabilt/distribuito non relazionale ampiamente noti come NoSQL (Not only SQL). In realtà Google correttamente lo definisce “mappa”, perchè in effetti di mappa si tratta in realtà. I dati vengono distribuiti sul cluster e raggiunti usando un approccio a “ricerca su una mappa”.

Il ragionamento dietro alla creazione di BigTable è il seguente:

• E’ un sistema che deve essere in grado di archiviare dati di tipo transazionale in quantità crescente potenzialmente all’infinito, senza introdurre problemi di performance
• Deve utilizzare un sistema distribuito, perchè su sistemi verticali la scalabilità è sempre un problema sui grandi numeri (lo sanno bene coloro che devono combattere tutti i giorni con il costo dello storage monolitico di classe enterprise che sale sempre a dismisura)

Per gestire queste proprietà, BigTable introduce un modello di dati del tutto innovativo, il BigTable data model, poi usato da tantissimi altri sistemi DB distribuiti, anche basati su altre architetture (vedi ad esempio Cassandra):

• Il database è costituito solo da una grande tabella, con un numero a piacere di colonne. Non esistono Join, non esiste schema. Lo schema può essere arricchito aggiungendo colonne. Se ci pensate, è quello che si fa quando si usa un foglio di calcolo: si destruttura il DB rendendolo piatto.
• Ogni riga è un insieme di colonne, all’interno delle quali i dati sono omogenei per tipo.
• Su disco le colonne (dette column family) sono archiviate in file separati e, dato che contengono dati omogenei, sono facili da comprimere e ottimizzare a vantaggio dello spazio. Da questo deriva il nome di “columnar database”.
• Ogni riga ha una chiave che la identifica, e un timestamp (in ogni file di colonna per ogni riga che ne contiene un valore, è registrata la chiave della riga e il valore della colonna. Se la colonna per quella particolare riga è vuota, nel file non c’è scritto niente.
• Le colonne sono sempre ordinate in ordine lessicografico per chiave per rendere più facile la ricerca.
• Il DB è spezzato in “tablet” (non è l’iPad, ma il diminutivo inglese per “tabellina”), ognuna costituita da una certa quantità di righe e quindi di column families.
• Ogni tablet è assegnata da un master server a un server diverso, detto “tablet server”, che è il nodo worker del sistema distribuito deputato ad archiviare e estrarre i dati in seguito alle query.

Il modello di accesso ai dati sviluppato da BigTable è a tre livelli:

1. una tabella che contiene solo metadati con puntatori al secondo livello di tabelle (la tabella Root)
2. un secondo livello di tabelle di metadati che puntano a loro volta i veri tablet server (le tabella METADATA)
3. le tablet vere e proprie (user tablet)

In realtà la tabella METADATA è una sola e la root è solo la prima delle sue tablet. Però la tablet root viene mantenuta intera, senza mai suddividerla in più tablet, come invece succede al resto della tabella METADATA.

Il sistema cluster è coordinato usando un sistema di coordinamento separato, basato su un altro prodotto, Chubby (in versione open source: Apache Zookeeper). Chubby mantiene le informazioni di configurazione del cluster e fa in modo che tutti i server siano in grado di funzionare senza incasinarsi tra loro.

Chubby è usato per l’elezione del master (che non è sempre lo stesso, ma viene eletto a runtime) e viene usato per mantenere in una struttura dati specifica l’elenco dei tablet server, il loro stato (i tablet server lo aggiornano usando Chubby a loro volta) e la posizione della tabella root. BigTable è una architettura master-worker, ma non è l’unica possibile. Amazon Dynamo (e quindi Cassandra) ne usano una completamente distribuita basata sull’interessantissima furbata delle Distributed Hash Tables. Altro articolo…

L’operazione di archiviazione e lookup (cioè il modo con cui il client interagisce con il DB) avviene usando un meccanismo basato sulla struttura a tre livelli di cui sopra:

• All’avvio, il master server chiede a Chubby l’elenco dei tablet server e si ripassa tutti i server andando a leggere la root table e le tabelle METADATA, per verificare se tutte le tablet di una tabella siano state assegnate
• Il master server assegna le tablet ai tablet server, controllando di volta in volta quali tablet server sono ancora tattivi ed eventualmente riassegnando la gestione di una tablet ad altro server nel caso in cui uno di questi server fallisca. Inoltre, quando un tablet server raggiunge la quota massima di righe, il master si preoccupa di assegnare un altro tablet server per continuare a gestire in automatico la scalabilità orizzontale.
• L’assegmanento delle tablet avviene cercando di mantenere la locality dei dati (in modo che il tablet server gestisca la tablet il cui file sta nello stesso nodo dal punto di vista del file system distribuito GFS. Notare che “assegnare” non vuol dire che la tablet viene creata appositamente, ma solo che viene indicato ad un determinato server che lui sarà quello che dovrà gestirla (la tablet è fisicamente archiviata su HDFS e quindi su disco).
• Il Master ha pochissimi contatti con i client, che invece interrogano direttamente i tablet server. Lo scopo del master è  quello di mantenere sotto controllo il funzionamento del cluster e distribuire le tablet e venire in contattato con i client solo in caso di cambiamenti allo schema, occasioni nelle quali è responsabile per operazioni di assegnamento o riassegnamento di tablet.

Il client per le query (ovviamente fa tutto da solo, tramite una libreria, lo sviluppatore non deve preoccuparsi di cosa avviene “behind the scenes”) effettua una operazione di lookup di questo tipo:

1. Contatta il servizio Chubby e richiede la posizione della tabella root. La tabella root viene mantenuta dal master, che la aggiorna a seconda delle movimentazioni dei tablet server
2. Contatta il server con la tabella root per cercare la posizione dei server con le tabelle METADATA di proprio interesse (un po’ come cercare in una libreria: prima cerco il reparto, poi lo scaffale, e infine il libro).
3. Contatta i server con le tabelle di metadati per conoscere l’indirizzo dei tablet server che hanno le tablet di proprio interesse
4. Esegue le query direttamente sui tablet server, mantenendo in memoria una cache della loro posizione e del tipo di dati gestiti, per futuri utilizzi
5. Se un tablet server sparisce o non ha i dati giusti, il client “torna indietro” al lookup perchè nel frattempo il cluster potrebbe essersi riaggiustato. Il master server effettua di continuo operazioni di riaggiustamento perchè controlla (sempre tramite Chubby) quali tablet server sono ancora attivi e se sia necessario redistribuire le tablet.
6. I tablet server ottimizzano le operazioni di scan (query) mantenendo in memoria le parti di tablet richieste a mo’ di cache.

Fino ad adesso abbiamo parlato di BigTable, ma che differenza c’è con il suo analogo open source Apache Hbase (usato anche da Hadoop)? In effetti poche, dato che Hbase è dichiaratamente una implementazione del sistema BigTable. Cambiano i nomi di alcuni componenti ma l’architettura è sempre quella:

• Il sistema di cluster management (in Google Chubby) si chiama Apache ZooKeeper
• Il file system distribuito è Hadoop HDFS
• Le tablet in Hbase si chiamano “regions”
• I tablet server, con somma fantasia, si chiamano “region server” (il master si chiama sempre master)
• La tabella di metadati si chiama META e viene archiviata da ZooKeeper (a differenta di BigTable dove è archiviata a sua volta come una tabella vera e propria)
• Il client si comporta in modo del tutto analogo (con lo stesso meccanismo di lookup)

Per interagire con Hbase lo sviluppatore, quindi, usa una libreria client (Java, Python o altro) che invoca dal codice e che poi usa per effettuare le operazioni di query (che però si chiamano Scan, non query, a indicare che questo nnon è un DB SQL…). Inutile dire che per interagire con questo DB NON SI USA SQL. L’interfaccia è una normale API di cui bisogna conoscere le primitive. Niente di complicato: tanto per capirci non è niente di più di un table.scan(key)

Per chi come al solito non vuole investire i propri neuroni nell’usare questi DB come devono essere usati, come al solito è anche possibile usare il solito vecchio SQL perchè (io disapprovo, e non mi interessa se i sistemi legacy usano SQL, cambiateli!) sono stati creati dei wrapper che consentono di fornire un driver JDBC e convertire le query SQL in chiamate a Hbase come Apache Phoenix e Impala (di Cloudera).

I servizi cloud: ma quanto mi costi?

Tag

aws, azure, bluemix, cloud, heroku, iaas, openshift, paas, pricing

Evviva il cloud computing, che tutto può e tutto risolve! Hai problemi? Vai sul cloud che te li risolve!

Scherzi a parte, i servizi IaaS e PaaS si stanno diffondendo parecchio e iniziano a entrare seriamente nella sfera di interesse anche delle aziende un po’ più grandicelle di una startup di 4 soggetti.

Il PaaS in particolare è piuttosto interessante per chi deve sviluppare applicazioni web perchè ti fornisce un ambiente per il deployment delle applicazioni senza doversi preoccupare di tutto quello che ci sta sotto. Chiedi le risorse che ti servono (es: un ambiente Rails), inizi a scrivere e via!

I più noti PaaS ormai offrono tutti un ottimo servizio, che si chiamino Azure, Bluemix, Heroku, AWS o Google e vale certamente la pena di considerarli quando serve capacità di calcolo “al volo” per fare test, sviluppo o anche per tirare in piedi un sito web che magari deve restare attivo per pochi mesi oppure che nasce piccolo per diventare grande, eccetera. Insomma per qualsiasi servizio ICT dal futuro incerto.

Rispetto a servizi IaaS più tradizionali come RackSpace, Softlayer (di IBM) o OVH per fare alcuni nomi, i PaaS sono nettamente più “cloud” e adottano modelli di pricing da bolletta della corrente elettrica: pay-per-use puro, con granularità a volte di anche meno di un’ora di utilizzo. Interessante..

Il problema è che questi pricing model SONO TUTTI DIVERSI!!!!!!! Ma porc… pare sia diventata una gara a chi si inventa il pricing model più incasinato. Come si fa a sapere quanto spenderai o anche solo a confrontare più servizi tra loro? Dato che non esiste ancora uno standard ISO per misurare la “capacità di calcolo” e la “quantità di memoria”, bisogna un po’ arrangiarsi.

“Lista della spesa”: scegli quello che vuoi, metti nel carrello

• Azure: Usa un modello a “lista della spesa”. A parte le macchine virtuali (scegli la taglia e lui ti calcola il prezzo) abbiamo i servizi PaaS. Il PaaS è tariffato sulle due tipologie di servizio disponibili che sono Web Sites e Cloud Services. Web Sites è esattamente quello che significa: web hosting con il linguaggio che preferisci (java, python, ruby, .Net). Cloud services è una versione più evoluta, pensata per applicazioni più complesse che hanno diversi “ruoli” (es: una applicazione con un frontend e un backend). In generale in Azure si paga tutto in modo granulare: calcolo, banda di rete, storage, ecc ecc.
• AWS: Simile ad Azure, si paga a lista della spesa per calcolo/storage/rete/IP pubblici/ecc… (in realtà avrei dovuto dire che Azure è simile a AWS, dato che AWS è arrivato moooolto prima). Il PaaS di Amazon (elastic beanstalk) non si paga, anche perchè l’unica cosa che fa è semplicemente automatizzare la creazione di macchine virtuali AWS con l’ambiente di deployment installato sopra. Inutile dire che Amazon ha l’offerta di servizi cloud più ampia del mercato.
• EngineYard: è la versione fighetta di AWS. In pratica funziona on top a AWS, con un po’ di assistenza in più e maggiore facilità di provisioning. In pratica è “AWS per l’IT manager ‘gnorante che non sa come usare AWS e vuole a tutti i costi qualcuno da chiamare”. Tutti gli altri servizio di AWS sono anche disponibili, al modico prezzo di listino di AWS con un markup del 20%. Un meta-AWS? Boh…

“Un tanto al chilo”: voglio un chilo di cloud! quanto costa?

• Google App Engine: Nonostante tutto, Google è un po’ il “nuovo arrivato” sulla scena. L’offerta PaaS (App Engine) si paga a “istanza”, per numero di ore/risorsa occupate. C’è auto scaling, quindi alla fine se la app cresce o occupa più spazio Google non si scandalizza, semplicemente scala in su e te lo fa pagare!
• Heroku: questo è il più fantasioso di tutti. Heroku ha definito una unità di pagamento e risorse di calcolo che si chiama “dyno”. Ci sono varie gradazioni di dynos a seconda della qualtità di risorse assegnate al container. Si paga per ore di dynos usate al mese. Un dyno è un container (heroku funziona con i container di Linux), più dynos sono più container, messi in load balancing. In più ci sono le solite istanze di DB e assistenza. Orientato a app con modello di scale-up orizzontale.
• OpenShift: Simile a Heroku. OpenShift usa i cosiddetti “gears” (simile ai dynos e alla fine sempre container) e tra l’altro offre anche una catena di CI basata su Jenkins. Si paga per numero e dimensione dei gears e tempo di utilizzo, più i soliti extra. Però ha uno strano capping sul numero massimo di gears che si possono chiedere: ci sono tre livelli di abbonamento: free, bronze e silver. Quello silver si paga un tot al mese e permette di avere un numero infinito di gears. Quello free e bronze ha in vece un limite al numero di gears che si possono attivare. Mah…
• Pivotal.io: Cloudfoundry (a dire il vero, è la spinoff di VMware che lo sviluppa). Modello molto semplice: si paga per quantità di RAM richiesta (quattrini/GB/ora). Molto, per non dire solo, orientato al web e alle applicazioni con scala orizzontale, il load balancing è incluso.

“Misto”: voglio un chilo di cloud, il resto lo prendo dallo scaffale

• Bluemix: La new entry di IBM nel mondo del PaaS, basata su CloudFouondry installato sopra Softlayer (sempre di IBM). Anche Bluemix usa il “GB di RAM per ora” come unità di misura. Ogni container applicativo è misurato in quattrini/GB/hour, quindi alcuni container costano più di altri. Più ci sono abbondanti varie opzioni aggiuntive vendute a lista della spesa.
• Cloudbees: è fortemente orientato al devops e continuous integration con Jenkins. Si paga un tanto a utente (utente=deployer), a cui vanno aggiunti alcuni servizi tra cui il numero di build Jenkins, l’hosting dell’applicazione per cui è definito un modello sul genere un tanto al kg che chiamano “cell”. Molto strano e poco utile per chi non conosce Jenkins e la continuous integraton

Prossimamente vedrò di fare qualche confronto con i dindi.

La legge di Conway e perchè una grande azienda non può essere una startup (e viceversa)

Tag

conway

Perchè certi prodotti ICT sono modulari, agili, innovativi mentre altri sembrano dei monoliti pesantissimi? Perchè è così difficile cambiare il modo in cui una azienda realizza i propri servizi informatici? Perchè una startup riesce a fare cose spettacolare con 4 gatti e una mega corporation ha bisogno di 1000 persone per partorire un giocattolo? Perchè la medesima startup una volta acquisita dalla mega corporation smette immediatamente di innovare e crepa?

A quanto pare le origini stanno in un principio detto “Legge di Conway”, sviluppato da Melvin Conway nel 1968 che recità così:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

In pratica ogni prodotto o sistema (venduto o usato internamente) ricalca la struttura di comunicazione di chi lo ha creato. Questo significa forse che una azienda agile, giovane e piccola (leggi: startup) farà prodotti agili, giovani e tendenzialmente piccoli? A vedere in giro si direbbe di sì.

Un sacco di mega-corporation cercano continuamente di scrollarsi di dosso la nomea di pachidermi vestendosi graficamente da startup. Non basta. I loro prodotti ICT sono e restano pari all’azienda di origine: grossi, complicati, monolitici. Nente di male in questo, perchè quando le cose si fanno complesse chiunque cerca la solidità e le spalle larghe di una azienda ICT di grandi dimensioni.

Uno degli studi che hanno provatola validità della legge di Conway ha dimostrato che team di sviluppo distribuiti tendono a sviluppare prodotti modulari (ogni gruppo parte del team fa proprio un pezzo del prodotto e cerca di integrarlo con gli altri, così come il team nel suo intero agisce per comunicare).

C’è chi lo ha capito bene questo principio. Tra alcuni grossi player del mondo IT (Cisco, ad esempio) va di moda oggi lo spin-in, cioè staccare alcune persone dall’azienda per fargli avviare a tempo pieno e in modo indipendente una nuova startup, finalizzata a creare un nuovo prodotto. In questo modo la nuova azienda è più piccola e sgancia il suo modo di comunicare da quello del pachiderma da cui è stata partorita. Una volta che il prodotto nuovo è stato inventato e lanciato, il pachiderma si rimangia il topolino e mette il prodotto a listino tra gli altri,

Insomma: care aziende, se volete innovare o cambiare faccia ai vostri prodotti ICT (interni o esterni) cambiate prima la vostra organizzazione, altrimenti è una battaglia persa!

 

 

 

God save the Apache Software Foundation

Tag

apache, asf, open source

Quando si parla di open source ci sono tante possibili fonti di progetti e codice (kernel.org, Sourceforge, Github, …) ma se si parla di open source per il backend dei sistemi informatici, la mitica Apache Software Foundation è sicuramente il punto di riferimento.

Il problema della ASF è che non mantiene un elenco “ragionato” di progetti, ma solo una specie di indice per categorie, in cui i progetti peraltro appaiono anche duplicati più volte in più categorie. Poi ogni tanto trovi il nerd di turno che ti dice “io per fare xxx ho usato Apache yyy”. “Apache yyy”???? Mai sentito nominare. Vai sulla pagina e scopri che “Apache yyy” fa il caffè, cerchi su Google e scopri che in molti lo confrontano con “Apache zzz” ecc ecc. Si apre un albero ignoto di progetti e tool.

Qualcuno ha provato anche a fare un grafo dei progetti basandosi sui vari soggetti che contribuiscono allo sviluppo. Tirando fuori questo grafico:

Grafo delle relazioni tra i progetti della ASF

Il grafo è bello e fa capire quanto sono “importanti” i progetti per quantità di team members. Non fa capire però che cosa fanno e come sono tecnicamente collegati tra loro.

Cosa la Big Data Analytics dice e cosa NON dice

Tag

big data analytics

Continuo a vedere un certo fraintendimento in materia di Big Data analytics. Mi pare che in giro non sia esattamente del tutto chiara la funzione di questi sistemi di calcolo distribuito.

Un sistema di BDA (ormai li chiamo anche io così anche se tecnicamente non vuol dire nulla) è un sistema distribuito pensato per effettuare estrazioni, combinazioni e calcoli su un dataset esistente, possibilmente molto grande.

Un job lanciato su un sistema BDA (Hadoop, Spark, …) produce risultati in un modo del tutto analogo a quelli che si possono ottenere con una query di SELECT su un normale database.

Il BDA non serve cioè a fare analisi statistiche sui dati o a predire il futuro. Serve a estrarre dati da un (grande e destrutturato) dataset. Le analisi statistiche o predittive devono essere implementate dallo sviluppatore nel programma che si dà in pasto al cluster! 

Rispetto a un DB relazionale i sistemi di BDA non fanno query, fanno “job”, questo perchè i dati del dataset non hanno struttura (sono dei file di testo) e quindi la struttura viene a mano a mano costruita dirante l’esecuzione del job (map->reduce->join->combine->map->…). Il risultato finale però è lo stesso: estrarre dati.