Qualche mese fa mi sono imbattuto nel sito del database Shodan, un crawler che ispeziona gli indirizzi IP pubblici di internet documentando gli header delle risposte restituite dagli host a interrogazioni sulle porte ftp, ssh, http, telnet, smnp. Il database può essere liberamente consultato sia dall’interfaccia web sia tramite API disponibili per i linguaggi Python e Ruby e il protocollo JSON, per utilizzare le quali occorre una API key ottenibile gratuitamente dal sito.

Per semplificare l’accesso al database Shodan tramite le API mi sono divertito a scrivere una mini-shell in Python e a pubblicarla su Google Code.

Di Shodan e della mia shell parlerò in un successivo articolo. Qui mi limiterò a descrivere come inizializzare un repository di progetto su Google Code usando il sistema di revisione di codice Git.

La creazione di un nuovo repository su Google Code è cosa abbastanza semplice a farsi, seguendo le istruzioni che guidano la procedura passo passo. Come strumento di controllo revisione è possibile selezionarne uno tra: svn, git, mercurial. Ho scelto il secondo e per rendere il tutto più eccitante ho deciso di limitare l’utilizzo alla linea di comando evitando front-end grafici come github, Tortoise e simili.

Do per scontato che arrivati a questo punto abbiate già scaricato Git per la vostra piattaforma e creato il progetto in Google Code. Assumo inoltre che stiate lavorando in un ambiente Unix-like, come ad esempio: Linux, Mac Os X, Cygwin, ecc. Infatti, come ben avrete sperimentato voi stessi, operare dalla linea di comando in ambiente Windows è il M A L E e so che seguirete il mio esempio e non vi cimenterete.

Orbene, innanzitutto procuratevi la password assegnata automaticamente da Google Code per i commit del codice accedendo al tab “Source” del progetto e cliccando su googlecode.com password:

Ciò fatto, nella $HOME del vostro utente create un file denominato .netrc e inserite quest’unica riga:

machine code.google.com login [GOOGLE USERNAME]  password [GOOGLE PASSWORD]

essendo [GOOGLE USERNAME] il nome del vostro utente Google (completo di suffisso @gmail) e [GOOGLE PASSWORD] la password ottenuta come descritto sopra.
Recatevi ora nella directory dove desiderate creare il vostro repository e inizializzatelo con il comando:

git clone https://[GOOGLE USERNAME]@code.google.com/p/[NOME PROGETTO]

dove [GOOGLE USERNAME] è il vostro utente Google ma questa volta senza suffisso @gmail e [NOME PROGETTO] è il nome che avete assegnato al vostro progetto: l’URL indicata sulla linea di comando è comunque la medesima riportata nella pagina “Source, Command-line access” raffigurata nell’immagine sopra. L’esecuzione del comando produrrà una nuova directory nel percorso locale denominata [NOME PROGETTO] e dovrebbe restituire il messaggio:

Warning: You appear to have cloned an empty repository

Il comando crea anche i file di controllo di Git, in particolare la directory .git. Spostatevi in questa directory e con un editor di testo aprite il file config ivi contenuto: vi troverete una sezione

[remote "origin"]

all’interno della quale è presente la direttiva

url = https://[GOOGLE USERNAME]@code.google.com/p/[NOME PROGETTO]

Rimuovete la parte [GOOGLE USERNAME@] in modo che la direttiva alla fine risulti essere semplicemente:

url = https://code.google.com/p/[NOME PROGETTO]

Questa modifica è richiesta per evitare un errore che si manifesterebbe in fase di push delle modifiche al server (maggiori dettagli qui: Using Git and .netrc)

Bene, ora potete copiare i file del vostro progetto nella directory creata dal comando “clone”. Fatto questo, dovrete dire a git quali file vanno sottoposti al controllo di revisione, cosa che si ottiene facilmente con il comando:

git add [NOME FILE]

Procedete poi con il commit dei nuovi file aggiunti:

git commit -m "Inserite il vostro commento qui"

E infine, sincronizzate il vostro repository locale con quello remoto su Google Code:

git push origin master

In chiusura, posso dire che il poco che ho visto di Google Code non mi ha impressionato ed è probabile che in futuro sposti il mio progetto su GitHub, anche perché dallo scorso Maggio, la piattaforma non consente più i download se non tramite Google Drive.

E oggi vedo questo annuncio qui.

Tutto secondo i piani direi.

• La demo skydive di Google Glass ha mostrato vista una videocamera miniaturizzata, innestata su un paio di occhiali indossati da gente che si è buttata con il paracadute da un aereo riprendendo e trasmettendo il tutto in forma di Google+ Hangout. Spettacolare ma eravamo già preparati a una cosa del genere dal primo film della serie Mission Impossible,
• Project Glass punta ovviamente molto più in alto: l’aspetto chiave di Glass è la combinazione di realtà aumentata, dispositivi computerizzati indossabili e interfacciamento con la Rete, il tutto reso sempre meno invasivo, sempre più discreto,vestibile e infine invisibile
• Io credo che la tecnologia più indicata per il sistema ottico sia la proiezione diretta sulla retina: microcamera da un lato e proiettore dall’altro. La radiazione luminosa verrà catturata dalla microcamera, digitalizzata e mixata con lo strato informativo (la parte “augmented” di “agumented reality”), riconvertita in analogico e trasmessa alla retina
• Alla realtà visiva si potranno applicare filtri in tempo reale: guardi un paesaggio, fai alcuni gesti con le mani che vengono interpretati e tradotti in comandi dal software di acquisizione video e modifichi il contrasto, la luminosità, la saturazione di un paesaggio, vista in bianco e nero, solarizzata, ecc.
• Si potrà diffondere in tempo reale il risultato delle nostre elaborazioni cosicchè gli altri possano vedere letteralmente con i nostri occhi.
• Nasceranno nuove espressioni artistiche
• Si manifesteranno nuove patologie legate alla persistente distorsione della percezione visiva: forme di dipendenza dalla realtà aumentata, di rigetto della realtà vera, qualcuno renderà permanente il dispositivo ottico di visione, i neo-luddisti lo rigetteranno
• In parallelo si svilupperanno sistemi avanzati di digital identity atti a cosentire la nostra identificazione a fini legali e rendere pubblico ciò che desideriamo gli altri percepiscano di noi. La nostra esistenza fisica diventerà a tutti gli effetti un avatar agli occhi degli altri, in maniera molto simile a quello che è possibile fare oggi in Second Life. Le prime versioni saranno un rozzo overlay che tenta di riprodurre i nostri movimenti,versioni più sofisticate saranno in grado di sostituire completamente la nostra figura. Dilemma: saremo gli unici a cui sarà permesso decidere come apparire agli occhi degli altri o anche gli altri potranno decidere quale immagine appiccicarci addosso?
• Le implicazioni dal punto di vista della sicurezza informatica non sono nemmeno lontanamente comparabili con quelle di oggi: l’intrusione in sistemi altrui consentirebbe di modificare il tipo e la quantità di informazioni che noi mostriamo agli altri. Simpatici crackers faranno comparire il saldo del nostro conto bancario sulla nostra fronte, modificheranno il modo in cui gli altri ci percepiscono
• Altro…

Sleep tight.

Il Nostro (sempre S.G.) ha illustrato una interessante teoria su come si dovrebbe impostare la strategia di vendita dei nostri prodotti software e dei relativi progetti di implementazione.

Poiché stiamo assistendo a un picco di lavoro per i servizi professionali, che, mancando del numero di consulenti che sarebbe necessario, gestiscono con difficoltà (com’è ovvio e umano) l’allocazione efficiente delle risorse sui progetti, bisognerebbe RALLENTARE la vendita e acquisizione di nuove attività per consentire di evadere il backlog di ordini pregresso, pronti ovviamente a ripartire di gran carriera quando il backlog sia stato ricondotto a una dimensione più gestibile e si siano finalmente liberate risorse.

Tanto il mercato e la concorrenza sono lì che aspettano i comodacci nostri no, S.G.? Sottospecie di ruminante biungulato fissipede!

riproduzione vietata (© pigreco314)

Chiunque abbia anche solo una vaga esperienza di progetti IT basati sull’implementazione di una applicazione software sa che per soddisfare un requisito utente è sempre opportuno privilegiare l’adozione di una funzionalità standard già presente nell’applicazione rispetto alla creazione di feature personalizzate: nel primo caso si utilizza una caratteristica del software che (sperabilmente) ha superato determinati test di qualità, non sono richieste ulteriori attività di progettazione, sviluppo, test e documentazione, e se il software è disegnato con un minimo di accortezza ci si deve attendere che tale funzionalità sia preservata nelle future versioni del software.

Anche quando si è costretti a sviluppare una funzionalità personalizzata, qualora essa diventi in seguito parte del software standard (in genere questo accade quando gli architetti dell’applicazione riconoscono che di quella particolare feature beneficerebbe l’intera comunità di utenti ed è quindi opportuno renderla disponibile a tutti), durante la pianificazione della migrazione del sistema alla nuova realease io prenderei in seria considerazione la possibilità di dismettere la versione “custom” della funzionalità e sostituirla con la sua controparte “built-in” perché da quel momento in poi aprofitterei di tutti i vantaggi citati sopra. È evidente che questa considerazione di principio deve essere accompagnata da una valutazione di costi e benefici: se il costo della conversione da “personalizzato” a “standard” è superiore ai benefici a lungo termine derivanti dal passaggio, è bene lasciar perdere.

Giovedi ho dovuto sprecare alcuni minuti del mio prezioso tempo (che sarebbero stati molti di più se non ci avessi dato un taglio brusco) per spiegare a S.G. questo elementare concetto che secondo me avrebbe già dovuto far parte del suo bagaglio culturale. E invece alla fine mi sono persino sentito replicare:”Se la funzionalità personalizzata fa quello che deve e soddisfa il requisito originale perché sostituirla con una standard?”. Per la serie: se funziona non toccare niente, non pensarci nemmeno, è male.

A S.G. non dovrebbe essere consentito di stare lì, nella posizione di responsabilità in cui si trova a propalare idee perniciose che esercitano un’influenza nefasta sulle menti dei nostri giovani business analyst.

Perché?

Perché è un cretino.

• numero di sottoposti: cioè quante persone lavorano nei professional services
• fatturato complessivo della business unit che combinato con il dato precedente consente di ricavare un’idea della nostra produttività
• margine operativo del gruppo di supporto (!)
• margine operativo annuale dei servizi professionali (!!)
• una descrizione piuttosto dettagliata di quanto egli sia esperto nell’implementazione e gestione di certi nostri processi operativi strategici (!!!)

Ovviamente in numeri presentati sono molto buoni,ottimi direi e la descrizione delle modalità organizzativa appare assai brillante.

Ora io mi domando, il lettore casuale (o estremamente interessato) dei profili di LinkedIn imbattendosi in quello del Nostro sarà portato a pensare che egli sia un grande manager o uno sprovveduto ed emerito cretino?

Crisi Greca

Ma che fatica convincere i colleghi ad usare questi mezzi di comunicazione e avere la possibilità di parlare del proprio lavoro in maniera originale e raccontare la propria storia, la propria “versione dei fatti”!

Non mi sembra poi così male aggiungere al proprio curriculum un link a quell’articolo del blog in cui spiegate in maniera convincente come secondo voi si gestisce un progetto di successo, quali brillanti risultati avete ottenuto e come siete riusciti a spaccare il mondo, voi e il vostro team.

Leviamo via la polvere e le ragnatale, please!