Tra le innumerevoli novità troviamo l’applicazione nella UI del Material Design, un nuovo sistema di notifiche, ottimizzazione dell’utilizzo della batteria, maggiore sicurezza, multiutenza, quick settings e l’utilizzo di ART (il nuovo Android runtime che dovrebbe dare un notevole contributo a migliorare le performance generali del dispositivo).
Per la lista completa delle features e delle caratteristiche dei nuovi dispositivi Nexus vi consiglio di spulciare i link che ho sparpagliato nel post.
Il seguente script ha lo scopo di estendere il prompt Bash in modo da visualizzare il branch Git in uso nel caso in cui ci si trovi in un repository Git.
Per farlo basta modificare il file .bashrc (presente nella propria home utente) mettendo alla fine le seguenti righe:
RESTORE='\033[0m'
GREEN='\033[00;32m'
LRED='\033[01;31m'
function parse_git_branch () {
CB=$(git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ \1/' | tr -d ' ')
if [ -n "$CB" ]; then
if [ "$CB" == "master" ]; then
PS1="${debian_chroot:+($debian_chroot)}\u@\h:\w\\[$LRED\] ($CB)\[$RESTORE\]\$ "
else
PS1="${debian_chroot:+($debian_chroot)}\u@\h:\w\\[$GREEN\] ($CB)\[$RESTORE\]\$ "
fi
else
PS1="${debian_chroot:+($debian_chroot)}\u@\h:\w\\$ "
fi
}
PROMPT_COMMAND=parse_git_branch
Il codice chiaramente potete modificarlo seguendo le vostre esigenze, otterrete ad ogni modo un risultato simile a questo:
Come potete vedere ho preferito mettere il master branch in rosso mentre tutti gli altri in verde; lo script è valido sia per Ubuntu che per Debian (con qualche piccola modifica dovrebbe funzionare anche su Mac OS).
Notizia fresca fresca che mette ancora in evidenza l’importanza di tenere aggiornati (e monitorati) i propri server: Yahoo.com e Winzip.com sono stati attaccati sfruttando il bug shellshock.
Potete trovare maggiori dettagli nell’articolo scritto da Jonathan D. Hall (“ethical hacker” che ha fatto questa scoperta) di cui vi faccio un tl;dr:
Jonathan D. Hall, facendo delle ricerche tramite Google per scoprire script CGI vulnerabili al bug shellshock, ha scoperto che molti server sono stati attaccati con successo e tramite uno script perl sono stati esposti verso lo stesso canale IRC (che viene usato dal hacker di turno per gestire la rete dei server compromessi). Approfondendo le ricerche ha scoperto che tra i vari server ci sono quelli di Yahoo.com e Winzip.com.
[…] Yahoo! is a publicly traded company. Their users deserve to know that their information is essentially at risk, regardless of what all was compromised and what wasn’t. Their users have a right to know so necessary precautions can be taken, and so they are aware that there is some sort of risk. […]
Attendiamo quindi la risposta di Yahoo! e Corel Corporation.
Dopo Heartbleed, cioè la vulnerabilità che ha colpito OpenSSL, tocca a GNU Bash essere al centro dell’attenzione con il bug a cui è stato dato il nome di “Shellshock” o più semplicemente “Bash Bug“.
La vulnerabilità permette di eseguire comandi remoti sui sistemi vulnerabili (quindi risulta essere di fatto molto più grave di Heartbleed), se non avete aggiornato Bash nelle ultime 24 ore siete quasi sicuramente vulnerabili, vi consiglio pertanto di aggiornare i vostri server/pc.
Dopo aver “scoperto” che la maggiore differenza tra Doctrine e Propel la fa il pattern utilizzato, ho deciso di scrivere questo post per approfondire i due pattern in questione: Data Mapper e Active Record.
Active Record
Un esempio tipico di utilizzo di questo pattern potrebbe essere il seguente (con Propel ORM):
$author = new Author();
$author->setName('Daniele');
$author->save();
Creiamo un oggetto Author a cui settiamo il nome e poi tramite il metodo save() lo persistiamo nel database, possiamo quindi notare che nell’oggetto risulta presente anche la storage logic (cioè come l’oggetto viene salvato nel database).
L’oggetto quindi non contiene solo ad esempio la business logic ma anche la gestione della sua persistenza, eludendo quindi il principio di singola responsabilità (SRP).
L’aumento di responsabilità dell’oggetto (convivenza tra business logic e storage logic) lo rendono più difficile da mantenere e da testare.
Un altro aspetto importante del pattern Active Record è la stretta mappatura tra oggetto e record nel database, questo porta lo stesso pattern ad essere preferito nei progetti meno complessi (anche per la sua facilità di utilizzo).
Data Mapper
Riscriviamo lo stesso esempio utilizzando il pattern in questione (con Doctrine ORM):
$author = new Author();
$author->setName('Daniele');
$entityManager->persist($author);
$entityManager->flush();
Le operazioni eseguite sono le stesse (creazione dell’autore, settaggio nome e persistenza/salvataggio) però, guardando sotto il cofano, si possono notare delle differenze notevoli.
La business logic e la storage logic sono gestite da oggetti diversi, ciascuno con la sua singola responsabilità.
Tutto ciò ci permette di poter estendere/sostituire le logiche di persistenza dell’oggetto e quindi passare ad esempio da un salvataggio verso database MySQL a XML (mantenendo invariata la business logic).
Questa astrazione e l’aumentare degli oggetti utilizzati renderà l’applicazione più complessa ma più mantenibile e testabile nel tempo.
Ho cercato di riassumere l’essenza dei due pattern, ad ogni modo se volete approfondire l’argomento troverete un sacco di materiale in giro.
This site uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. AcceptRead More