Git bash diff explained

In uno dei nostri articoli precedenti su Git abbiamo spiegato come avere una bash Git configurata secondo alcuni nostri ( miei 😛 ) gusti.

Anche oggi, volendo essere un po’ geek, andremo a sviscerare con attenzione come fare il diff con Git attraverso la linea di comando 🙂

Dai… è divertente! 🙂

Per prima cosa creiamo una cartella di prova sul nostro desktop e creiamoci un repository git:

Poi inseriamo un file (prendiamo l’html di example.org) e lo committiamo.

a questo punto lo apriamo con il nostro editor di testo preferito e ne facciamo alcune modifiche.

Quindi lanciamo il diff per quel file. Ecco che cosa verrà visualizzato (più o meno in base alle vostre modifiche)

Compared Files

Diff ci dice che sta comparando il file “a” che è example.org.txt con il file “b” che è sempre, in questo caso il file example.org.txt ma con le modifiche

File Metadata

Queste sono informazioni molto tecniche che dipendono da come Git identifica gli “oggetti” al suo interno (potete non considerarli per lo scopo di questo articolo)

a/b Identifiers 

Git da degli identificatori per le righe che visualizzerà successivamente per indicare una riga di “a” e una riga di “b”. Qui si vede che le righe di “a” saranno indicate con il simbolo “-” (meno) mentre quelle di “b” con il simbolo “+” (più).

Poiché il diff di un file con la sua versione precedente identifica con  “a” la versione precedente e con “b”  la versione successiva, in questo modo è anche possibile leggere le righe con “-” come eliminate mentre quelle con “+” come aggiunte. Infatti le righe identiche non vengono etichettate.

Chunk Header

Poiché le modifiche ad un file potrebbero espandersi per molte righe di codice, diff cerca di visualizzare solamente degli “spezzoni” (chunk) dove sono presenti le modifiche, tralasciando le molte (o poche) righe identiche tra un chunk e l’altro.

L’header è racchiuso tra i tag @@

All’interno c’è una sezione per il file “a” indicata con il “-” e una per il file “b” indicata con il “+”.

Qui ci viene detto che nel chunk che segue sono visualizzate 7 righe di “a” a partire dalla riga 11 e 7 righe di b a partire dalla riga 11 se abbiamo (come il nostro primo chunk)

@@ -11,7 +11,7@@

Chunk

Nel chunk sono indicate con “-” le righe di “a” eliminate e con “+” le righe di “b” aggiunte. Le righe senza segni sono le stesse in entrambi i file

Git bash diff explained

Friendly firewalls for your OSX, Windows and Linux

 _  _

Oggi parleremo di tre firewall veramente facili da utilizzare che che ci daranno modo (a livello di utilizzatore basico di PC) di avere sotto controllo tutte le connessioni di rete che avvengono nei nostri computer.

Per Windows descriverò la versione di GlassWireBasic” (a pagamento) che ad oggi costa circa 60€.

Mentre per OSX descriverò il bundle LittleSnitch+MicroSnitch che costa ad oggi circa 32€.

Le cifre sono una-tantum e quindi una volta acquistata la licenza, siamo a posto per sempre. Non come i firewall messi a disposizione dagli antivirus che sono attivi solamente con le versioni professionali a pagamento annuale, ma non voglio dilungarmi oltre su questo argomento.

OpenSnitch è il porting di LittleSnitch su Linux che sta facendo Simone Margaritelli (aka evilsocket). OpenSnitch, devo dire la verità, non ho ancora avuto modo di utilizzato perché è molto recente e in sviluppo in questi giorni, ma credo comunque che meritasse di essere menzionato e tenuto d’occhio visto che si prefigge di dare sotto Linux le stesse opzioni di LittleSnitch.

Le funzionalità di questi software sono veramente belle, e credo che ogni utilizzatore di PC dovrebbe averle a disposizione!

La funzione più bella è la modalità del firewall  “Ask To Connect” (in Little e Open Snitch è attiva di default, mentre in GlassWire va abilitato nella scheda Firewall).

Questo cosa vuol dire?

Vuol dire che non appena avremo installato il programma, questo comincerà a controllare tutte le connessioni al computer in Ingresso e in Uscita e di default non permetterà quelle in Uscita.

Se per ogni connessione in Uscita non è ancora stata stabilita una regola, allora vi verrà presentato un popup con il quale decidere se negare o acconsentire la connessione.

GlassWire:

OpenSnitch:

LittleSnitch:

Ad esempio facendo per la prima volta anche un solo telnet su Windows, dovremo abilitare la regola su GlassWire prima di riuscire nell’intento 😉

Stessa cosa per LittleSnitch.

Inoltre avremo la possibilità di andare a vedere le regole impostate sul Firewall e fare alcune operazioni sia sulla regola ma anche sull’applicazione stessa. Potremo per esempio fare la scansione con l’antivirus corrente sul PC (GlassWire) e vedere chi ha firmato il programma (GlassWire e LittleSnitch) e anche vedere se la firma è valida (LittleSnitch).

Avrete quindi sotto controllo tutto il traffico suddiviso per applicazione o per connessioni!

Se poi volete spingervi ancora più a fondo, potete abilitare (GlassWire) le notifiche sull’attività di fotocamera e microfono.

Ma se avete comprato anche MicroSnitch, avrete le stesse funzioni anche su Mac OSX.

Beh, spero che queste cose vi piacciano e vi possano tornare utili!

Soprattutto vi facciano stare più tranquilli mentre utilizzate il vostro PC.

Alla prossima.

 

Friendly firewalls for your OSX, Windows and Linux

MacOSX trackpad gestures

Poiché molte persone che conosco hanno un Mac con un bellissimo Trackpad, ma continuano a cliccarci “con forza” invece che semplicemente tapparlo, oggi voglio suggerire in questo articolo come abilitare alcune utili “gesture” sul vostro Mac 🙂

Innanzitutto ecco qui i link ufficiali:

Poiché vi ho già messo i link per configurare le varie opzioni qui vi metterò la sintesi  per accedere ad esse (io ho il sistema operativo in inglese):

  • Le gesture: System Preferences –> Trackpad –> Mouse Gestures
  • Trascinamento a tre dita: System Preferences –> Accessibility –> Mouse and Trackpad –> Trackpad options –> Enable dragging –> Three finger drag

Una volta impostati, difficilmente ne farete a meno.

E’ ovviamente del tutto personale, ma fatemi sapere come andate!

MacOSX trackpad gestures

Git bash environment on Mac OSX

Oggi vogliamo essere un po’ geek e configurarci il prompt per git a linea di comando.

Per fare questo scarichiamoci questi cinque file più, se volete utilizzarlo come editore predefinito, Sublime Text:

Il profilo dobbiamo importarlo dal menu del nostro terminale: Terminal –> Settings (io l’ho in inglese) e poi sotto la lista di profili, clicchiamo la piccola ruota dentata vicino al “-” (meno)

Scarichiamo (nella cartella Downloads)  bash_profile e apriamo il terminale e digitiamo:

cd
mv Downloads/bash_profile .bash_profile

ATTENZIONE: copiate il .bash_profile solo se non ne avete già uno, altrimenti integrate il vostro con quanto scritto nel mio.

Scarichiamo (nella cartella Downloads) git-prompt.sh e git-completion.bash (presi direttamente dal repository ufficiale di git su GitHub – https://github.com/git/git) e git_configure_commands.sh

Digitiamo i comandi

cd
mv Downloads/git_configure_commands.sh .
mv Downloads/git-completion.bash .
mv Downloads/git-prompt.sh .

A questo punto lanciamo il comando git_configure_commands.sh

./git_configure_commands.sh

che imposterà il conflict style a diff3, metterà il push.default ad upstream e imposterà Sublime Text come l’editore di default per il messaggio di commit (fate attenzione qui che il percorso di Sublime Text sia anche da voi come nel file, altrimenti correggetelo)

A questo punto non vi resta che chiudere e riaprire il terminale e navigare in una cartella che sia un repository git.

Ecco qua!

 

Si lo so, l’interfaccia grafica ci vizia un po’, ma avere anche una riga di comando tutta personalizzata non è male 😉

Git bash environment on Mac OSX

TimeMachine Local Snapshot

Intanto se non sapete cosa sono i “local snapshot” andate a leggere qui.

MacOSX TimeMachine non esegue i backup solamente sul disco esterno, ma fintantoché non ha fatto il backup (ripeto all’ultimo), ad intervalli regolari, tiene un local snapshot in locale, “rubando” spazio al nostro prezioso Macintosh HD! 🙂

Bene, se volete non farli più occorre:

Aprite un terminale.
Digitate il comando: 

sudo tmutil disablelocal

Inserire la password di amministratore (se richiesta).
Riavviare il Mac.

Disabilitando i “local snapshot” tutti gli snapshot presi fino a questo momento saranno cancellati.

TimeMachine Local Snapshot

Android Studio – Crea UI Test con Espresso Test Recorder

E’ ancora in beta la versione di Espresso Test Recorder su Android Studio, ma promette moooolto bene! 🙂

Con Espresso, come bene saprete, è possibile creare Test Automatizzati sulla User Interface della nostra App.

Scrivere un Test articolato può essere laborioso. Ma ecco che ci viene in aiuto Espresso Test Recorder!

Leggete qui!

Ad esempio creiamo un nuovo progetto di una “Basic Activity” e se abbiamo Android Studio 2.3 o superiore vedrete che Espresso sarà già impostato come da documentazione nel progetto.

A questo punto… magia 🙂

Andate in Run –> Record Espresso Test

Clicchiamo sul bottone “fab” e asseriamo che il testo “hello world” esista! 🙂

E finiamo.

Ecco il nostro test bello che scritto!!!

Nell’esempio noterete che ho cliccato (per sbaglio) due volte sul pulsante “fab”.

Beh… che dire… fantastico!

Provate e fatemi sapere.

Alla prossima.

 

Android Studio – Crea UI Test con Espresso Test Recorder

Visual Leak Detector per Visual C++

Ho utilizzato questo prezioso strumento per diversi progetto durante la mia carriera e mi sono accorto di non aver mai scritto un articolo al riguardi! Gravissimo! 🙂

La pagina del progetto è questa: https://vld.codeplex.com/

Con vld è possibile riconoscere se nel nostro codice nativo (C/C++) abbiamo dei memory leak direttamente dopo un solo ciclo di utilizzo del nostro programma dalla console di Output di Visual Studio.

Sul sito del progetto la documentazione è chiara. Vi mostrerò qui ora un semplice esempio.

Per prima cosa scarichiamo l’eseguibile da https://vld.codeplex.com/ e installiamolo sul PC sul quale abbiamo il nostro Visual Studio (nel mio caso la versione 2015).

A questo punto creo un progetto Win32 Console Application con il seguente main.cpp

Se scrivete il codice prima di impostare i path per gli include di vld, la riga 10 vi darà errore. Non preoccupatevi, la sistemiamo subito.

Come vedete il nostro bel programmino è fatto apposta per sprecare memoria all’infinito. La alloca e non la rilascia mai… che bravo! 😀

La documentazione ufficiale è ben fatta e la trovate qui.

Uma volta lanciato il setup.exe di VLD quello che dovete fare è andare ad impostare sul progetto in cui lo volete utilizzare per la build di Debug che vi interessa (x86, x64 o entrambe) i path delle librerie e dei file di include di VLD.

A questo punto compiliamo in Debug e lanciamo il nostro codice. La riga 10 non darà più errore e in console vediamo l’avvenuto corretto caricamento del nostro Leak Detector prendendo i suoi parametri di configurazione dal vld.ini nella directory di installazioine del VLD.

Al termine del programma ecco quali utili informazioni vld ci offre nella cosole di output di Visual Studio!

E questo è tutto, gente!

Visual Leak Detector per Visual C++

Utilizzare Let’s Encrypt con IIS su Windows

Finalmente dopo un po’ di tempo qualcuno si è “preso la briga” di fare un wrapper del protocollo Certbot anche per windows integrato con IIS.

Ecco qui il link al progetto su GitHub: https://github.com/Lone-Coder/letsencrypt-win-simple/releases

E’ costruito a sua volta sopra il  .net ACME protocol library.

Basta scaricare lo zip e metterlo in una cartella sul vostro server.

Dopodichè con un prompt dei comandi con diritti di amministratore andate nella cartella e semplicemente lanciate il comando:

Letencrypt.exe

E seguite i vari passaggi.

  • inserire la mail
  • leggere e accettare le condizioni di contratto e policy
  • scegliere il sito IIS su cui richiedere il certificato e aspettare

Fa tutto lui:

  • Chiede il rilascio del certificato
  • Lo salva sul server
  • Crea il bindig sulla porta 443 con il certificato appena richiesto
  • Crea il job schedulato per il rinnovo automatico

Bene! Finalmente la richiesta dei certificati SSL no sarà più un problema anche su IIS! 😀

Utilizzare Let’s Encrypt con IIS su Windows

PHP+Oracle OCI+CLOB

Oggi ho avuto necessità di leggere e scrivere da PHP un camp CLOB in una tabella di ORACLE.

Nel manuale al seguente indirizzo

http://php.net/manual/en/function.oci-new-descriptor.php

ho trovato subito il mio scenario.

Example #2 oci_new_descriptor() example

<?php
/* Calling PL/SQL stored procedures which contain clobs as input
 * parameters.
 * Example PL/SQL stored procedure signature is:
 *
 * PROCEDURE save_data
 *   Argument Name                  Type                    In/Out Default?
 *   ------------------------------ ----------------------- ------ --------
 *   KEY                            NUMBER(38)              IN
 *   DATA                           CLOB                    IN
 *
 */

$conn = oci_connect($user, $password);
$stmt = oci_parse($conn, "begin save_data(:key, :data); end;");
$clob = oci_new_descriptor($conn, OCI_D_LOB);
oci_bind_by_name($stmt, ':key', $key);
oci_bind_by_name($stmt, ':data', $clob, -1, OCI_B_CLOB);
$clob->write($data);
oci_execute($stmt, OCI_DEFAULT);
oci_commit($conn);
$clob->free();
oci_free_statement($stmt);
?>

Utilizzare PL/SQL permette di superare il limite di 4000 caratteri passati per il CLOB.

L’esempio nel manuale però dava errore.

Quello che ho dovuto modificare perchè il tutto funzionasse è stato sostituire

$clob->write($data);

con

$clob->writeTemporary($data);

Altrimenti ottenevo l’errore: OCI-Lob::write() : OCI_INVALID_HANDLE

Inoltre sarebbe bene ottenere il valore di ritorno dal oci_execute e fare la commit solo se “true”

$ok = oci_execute($stmt, OCI_DEFAULT);
if ($ok) {
    oci_commit($conn);
} else {
    oci_rollback($conn);
}

Nel caso qualcun altro avesse bisogno di questo scenario 😉

PHP+Oracle OCI+CLOB

Debug Diagnostic Tool

Oggi vedremo un caso di utilizzo del Debug Diagnostic Tool che è uno strumento molto utile per fare del debugging e del profiling sia in ambiente di Sviluppo ma sopratutto in ambiente di Produzione.

Il caso in particolare è andare ad analizzare una applicaizone ASP che in produzione, sotto stress quindi, ogni tanto manda il processore del server al 100%.

Come primo workaround si è subito messo in linea uno script di Power Shell che andasse a verificare lo stato del processore e nel caso fosse rimasto al 95% per più di 20sec, andasse a fare un IIS Reset.

Poi subito dopo seguendo questo articolo su Debuggin IIS High CPU siamo andati a impostare:

  1. Data Collection con il Performance Monitor
    In particolar modo:

    • Richieste Correnti Totali (ASP .NET)
    • Richieste in Coda (ASP .NET)
  2. Creazione di un Dump tramite Debug Diagnostic Tool 2 Collection
    In particolare:

    • Se il processore rimaneva al 90% per più di 5 secondi

E siamo rimasti ad aspettare che nuovamente succedesse lo scenario incriminato.

Abbiamo lasciato in piedi la cosa per tutta la notte: il data collection continua finchè non lo si stoppa, mentre il dump è one-time (una volta scattato, va riattivato manualmente il trigger, altrimenti si ferma).

Nella notte abbiamo avuto ben 4 casi di processore al 100% e durante il primo caso si è generato il Dump e durante tutti i casi abbiamo collezionato i dati dei contatori per le Richieste Correnti e per le richieste in Coda.

Ecco come abbiamo poi analizzato la cosa.

Per quanto riguarda i dati collezionati dal Performance Monitor si è visto che le richieste correnti schizzavano in occorrenza dell’evento incriminato:

Andando ad analizzare anche le richieste in coda:

si evince che aumentano proporzionalmente alle richieste attive.

Questo ci fa sospettare che sia effettivamente un problema di performance e non un problema di “attacco” in quanto le richieste in coda ci sono solamente durante gli eventi incriminati e quindi IIS non riesce ad evadere le richieste perchè è impegnato nell’operazione che porta il processore al 100% e questo scenario è coerente con il fatto che facendo IIS Reset la situazione ritorno normale.

Andiamo quindi ora ad analizzare il dump con il Debug Diagnosti Tool 2 Analysis.

Vediamo subito che l’analisi del Dump conferma High CPU Usage.

Andando a vedere quindi i Topo 8 Thread scopriamo da dove parte il tutto:

Dalla pagina “RivestimentiDettagli” ed è scatenata dal metodo “.get_data()” (Tutto Codice Utente).

Andando quindi ad analizzare il codice si è scoperto che si era fatto un uso improprio di variabili statiche e quindi c’erano problemi di concorrenza che si vedevano solo in presenza di forte carico del server.

 

 

 

Debug Diagnostic Tool