diff options
Diffstat (limited to 'content/it/articles')
6 files changed, 363 insertions, 23 deletions
diff --git a/content/it/articles/le-email-queste-sconosciute/index.md b/content/it/articles/le-email-queste-sconosciute/index.md index c790d42..71eb7b7 100644 --- a/content/it/articles/le-email-queste-sconosciute/index.md +++ b/content/it/articles/le-email-queste-sconosciute/index.md @@ -20,7 +20,7 @@ Eh già, si chiama oggetto perchè serve a descrivere ciò di cui l'email parla, Un'altra cosa piuttosto bruttina da vedere è il corpo del messaggio vuoto con tutto il contenuto relegato negli allegati, se ricevo una mail così non è che mi precipito a leggere l'allegato, piuttosto la cestino direttamente! Gli allegati servono per allegare qualcosa che non si può mettere nel corpo del messaggio, non per contenere il messaggio! -Un altro problema che affligge spesso chi riceve email è l'invio di foto! Su questo punto potremmo spendere fiumi di parole parlando del fatto che al giorno d'oggi con le adsl super veloci che ci ritroviamo non sia più un problema ricevere allegati pesanti, ma non capisco perchè io debba stare a scaricare una foto da 12 megapixel a 300 <acronym title="dot per inches (punti per pollice)">dpi</acronym> se non dovrò nemmeno stamparla, ma al massimo condividerla sul blog o su facebook; perdete un attimino del vostro <span style="text-decoration: line-through">prezioso</span> tempo anche voi e riducete le dimensioni delle foto che inviate, già ridurre la risoluzione da 300 a 72 [dpi][4] aiuterà notevolmente chi dovrà ricevere la mail oltre che farvi risparmiare molto tempo in invio.. Un altro appunto relativo alle dimensioni delle foto, se state mandando una foto di un tenero cucciolo che dovrà fare da sfondo al piccì del vostro/a amato/a, che senso ha che misuri 4000 pixel sul lato corto?! Una risoluzione decente potrebbe essere 1600 pixel sul lato lungo e il lato corto dimensionato in proporzione, in questo modo le dimensioni scenderanno ulteriormente senza che si perda la qualità del vostro pregevolissimo scatto! ;) +Un altro problema che affligge spesso chi riceve email è l'invio di foto! Su questo punto potremmo spendere fiumi di parole parlando del fatto che al giorno d'oggi con le adsl super veloci che ci ritroviamo non sia più un problema ricevere allegati pesanti, ma non capisco perchè io debba stare a scaricare una foto da 12 megapixel a 300 {{< acronym title="dot per inches (punti per pollice)" >}}dpi{{< /acronym >}} se non dovrò nemmeno stamparla, ma al massimo condividerla sul blog o su facebook; perdete un attimino del vostro ~~prezioso~~ tempo anche voi e riducete le dimensioni delle foto che inviate, già ridurre la risoluzione da 300 a 72 [dpi][4] aiuterà notevolmente chi dovrà ricevere la mail oltre che farvi risparmiare molto tempo in invio.. Un altro appunto relativo alle dimensioni delle foto, se state mandando una foto di un tenero cucciolo che dovrà fare da sfondo al piccì del vostro/a amato/a, che senso ha che misuri 4000 pixel sul lato corto?! Una risoluzione decente potrebbe essere 1600 pixel sul lato lungo e il lato corto dimensionato in proporzione, in questo modo le dimensioni scenderanno ulteriormente senza che si perda la qualità del vostro pregevolissimo scatto! ;) {{< image src="/uploads/2010/11/url-300x197.jpg" alt="URL structure illustration" >}}{{< /image >}} [5]Il punto successivo di questa carrellata potrebbe avere un titolo e un articolo a se, "_come inviare link. Il modo corretto di condividere i famigerati [URL][6]_"; fin dagli albori di internet si è avvertita infatti la necessità di condividere link interessanti con i nostri contatti, e sopratutto negli ultimi tempi i link sono diventati sempre più lunghi e complessi, cose tipo: @@ -29,11 +29,11 @@ Un altro problema che affligge spesso chi riceve email è l'invio di foto! Su qu http://www.example.net/test/sample_page.php?variable00=aldsgfqeworslkdf2934523&variable01=abbecceddario&variable02=tomorrow+will+rain#bookmark539 ``` -e nonostante io capisca che condividere i link sia fondamentale proprio non riesco a concepire il fatto che chi invia i link non si prenda la briga di controllare che siano quantomeno funzionanti prima di inviare la mail, il copia/incolla è una conquista stupenda, ma perchè fare la figura dei <span style="text-decoration: line-through">pirla</span> (a dir poco) inviando link chilometrici spezzettati in 20 parti che per ricostruirli si impiega più tempo che a leggere il resto della posta, col rischio poi che ci si dimentichi di un minuscolo carattere tipo un punto e il link non funzioni?! Per ovviare a questo tipo di inconvenienti, si può fare più attenzione riguardando la mail prima di inviarla, oppure si può utilizzare uno dei tanti servizi di URL shortening presenti sul web, ~~come ad esempio [uri.danixland.net][7],~~ in questo modo i link diventeranno molto più brevi e semplici da gestire, e si eviteranno tanti problemi per chi legge le email! +e nonostante io capisca che condividere i link sia fondamentale proprio non riesco a concepire il fatto che chi invia i link non si prenda la briga di controllare che siano quantomeno funzionanti prima di inviare la mail, il copia/incolla è una conquista stupenda, ma perchè fare la figura dei ~~pirla~~ (a dir poco) inviando link chilometrici spezzettati in 20 parti che per ricostruirli si impiega più tempo che a leggere il resto della posta, col rischio poi che ci si dimentichi di un minuscolo carattere tipo un punto e il link non funzioni?! Per ovviare a questo tipo di inconvenienti, si può fare più attenzione riguardando la mail prima di inviarla, oppure si può utilizzare uno dei tanti servizi di URL shortening presenti sul web, ~~come ad esempio [uri.danixland.net][7],~~ in questo modo i link diventeranno molto più brevi e semplici da gestire, e si eviteranno tanti problemi per chi legge le email! Ancora un altro consiglio, **ricontrollate ciò che avete scritto**, no seriamente, consegnereste mai un compito senza averlo nemmeno riguardato? E allora perchè prima di inviare una mail che vi sarà costata probabilmente meno tempo per scriverla, non le date una rilettura veloce?! Sono fantastiche le email con l'oggetto ma senza il testo, o quelle con il testo "_Allegato pronto per la spedizione_: ma senza l'allegato! Suvvia, che ci vuole a soffermarsi un attimo su ciò che si sta facendo?! -Per ultimo mi lascio probabilmente la madre di tutti i comportamenti sbagliati quando si invia un'email, il disrispetto della privacy! di cosa sto parlando?! Avete presente quelle stupende catene di S. Antonio che vanno tanto di moda nei periodi di festa? Quelle con allegate le presentazioni strappalacrime in PowerPoint che "_se non le inoltri a 140 amici entro i prossimi 7 minuti non hai cuore e ti morirà il gatto strozzandosi mentre sta mangiando il pesce rosso e morendo cadrà in testa al cane al quale si spezzerà una gamba e per la tristezza l'uccellino non mangerà più e si lascerà morire?_" Bene, quelle catene sono l'eden degli spammer, ricevere una di quelle email è come ricevere in regalo tutta la lista dei propri amici su facebook moltiplicata per tutti gli amici di ogni singolo amico, a volte sono più lunghe le liste di indirizzi email che il corpo stesso del messaggio.. Questo accade perchè probabilmente non si conosce bene il mezzo di comunicazione che si sta usando, il campo "A:: dovrebbe contenere il destinatario dell'email, e fin qui non ci piove, ma come comportarsi quando ci sono più destinatari? Ecco che ci viene in aiuto il campo "[Bcc:][8]: altrimenti detto "<acronym title="Copia carbone nascosta">Ccn:</acronym>". Questo campo viene utilizzato per inserire i destinatari secondari dell'email e far si che il loro indirizzo non sia visibile ai destinatari principali specificati nel campo "To:; quando ci sono tantissimi destinatari e non tutti si conoscono tra loro, è buona norma evitare che gli indirizzi email siano visibili onde evitare che qualcuno possa accusarvi di violazione della privacy! Io personalmente sono spesso tentato di denunciare i mittenti di email del genere :/ +Per ultimo mi lascio probabilmente la madre di tutti i comportamenti sbagliati quando si invia un'email, il disrispetto della privacy! di cosa sto parlando?! Avete presente quelle stupende catene di S. Antonio che vanno tanto di moda nei periodi di festa? Quelle con allegate le presentazioni strappalacrime in PowerPoint che "_se non le inoltri a 140 amici entro i prossimi 7 minuti non hai cuore e ti morirà il gatto strozzandosi mentre sta mangiando il pesce rosso e morendo cadrà in testa al cane al quale si spezzerà una gamba e per la tristezza l'uccellino non mangerà più e si lascerà morire?_" Bene, quelle catene sono l'eden degli spammer, ricevere una di quelle email è come ricevere in regalo tutta la lista dei propri amici su facebook moltiplicata per tutti gli amici di ogni singolo amico, a volte sono più lunghe le liste di indirizzi email che il corpo stesso del messaggio.. Questo accade perchè probabilmente non si conosce bene il mezzo di comunicazione che si sta usando, il campo "A:: dovrebbe contenere il destinatario dell'email, e fin qui non ci piove, ma come comportarsi quando ci sono più destinatari? Ecco che ci viene in aiuto il campo "[Bcc:][8]: altrimenti detto "{{< acronym title="Copia carbone nascosta" >}}Ccn:{{< /acronym >}}". Questo campo viene utilizzato per inserire i destinatari secondari dell'email e far si che il loro indirizzo non sia visibile ai destinatari principali specificati nel campo "To:; quando ci sono tantissimi destinatari e non tutti si conoscono tra loro, è buona norma evitare che gli indirizzi email siano visibili onde evitare che qualcuno possa accusarvi di violazione della privacy! Io personalmente sono spesso tentato di denunciare i mittenti di email del genere :/ Mi sembra di aver esaurito gli argomenti riguardo le email, mi auguro di ricevere tante comunicazioni da voi, e spero proprio che farete tesoro di ciò che vi ho consigliato, altrimenti potete anche risparmiarvi il tempo di scrivermi, tanto probabilmente non leggerò mai ciò che mi mandate ;) diff --git a/content/it/articles/my-hugo-workflow/index.md b/content/it/articles/my-hugo-workflow/index.md new file mode 100644 index 0000000..a482a62 --- /dev/null +++ b/content/it/articles/my-hugo-workflow/index.md @@ -0,0 +1,346 @@ ++++ +title = "Le Impostazioni Git che Uso Davvero" +author = "Danilo M." +type = "tech" +date = "2026-04-28T19:53:46+02:00" +draft = false +excerpt = "Un giro nel mio ~/.gitconfig: le impostazioni su cui mi appoggio ogni giorno e perché ognuna si guadagna il suo posto." +tags = ["git", "workflow", "linux", "gpg", "hugo", "configurazione", "howto"] +categories = ["DIY", "Code"] ++++ + +Qualche anno fa ho impostato un sistema a due repository per questo sito: uno per i contenuti, l'altro per il tema (come submodule). È un'architettura pulita in teoria, ma in pratica gestire due repository significa destreggiarsi continuamente tra aggiornamenti di branch, conflitti sul puntatore del submodule e push su due remote in sequenza. Ho cominciato a portarmi in giro un file `.gitconfig` tra macchine diverse, modificandolo un po' alla volta man mano che scoprivo impostazioni che eliminano l'attrito. + +Questo non è una guida a ogni opzione di git, ci vorrebbe un libro. È invece un tour personale delle impostazioni che ho davvero integrato nel mio flusso di lavoro, perché contano e cosa è cambiato da quando sono attive. + +<!--more--> + +## La Colla del Flusso: `push.autoSetupRemote` e `pull.rebase` + +Queste due stanno insieme perché riguardano i confini dei branch: come li mandi su e come li riporti giù. + +### push.autoSetupRemote + +La vecchia frustrazione: creare un branch locale, scrivere codice, eseguire `git push` e ricevere: + +``` +fatal: The current branch feature/my-new-branch has no upstream branch. +To push the current and set the upstream branch, use: + + git push --set-upstream origin feature/my-new-branch +``` + +Ogni volta la stessa cerimonia inutile. La soluzione: + +```ini +[push] + autoSetupRemote = true +``` + +Ora `git push` su un nuovo branch funziona e basta. Git deduce il branch di tracciamento automaticamente. La prima volta che ho usato questa impostazione con i branch di contenuto Hugo, creando `content/nuovo-articolo` il lunedì e facendo subito push, ho capito di aver eliminato forse cinquanta digitazioni l'anno di `--set-upstream`. + +### pull.rebase + +La storia lineare conta di più su un sito a singolo autore. Senza `pull.rebase = true`, fare pull dei cambiamenti crea commit di merge come "Merge branch 'main' of origin/main" anche quando stai solo sincronizzando. Questi commit non rappresentano lavoro: sono rumore. Intasano `git log`, rendono il bisect più lento e aggiungono confusione al grafo. + +```ini +[pull] + rebase = true +``` + +Con questa impostazione attiva, fare pull ribasa il lavoro locale sopra la punta remota. Quando gestisci un sito Hugo con un submodule del tema, questo è particolarmente utile: gli aggiornamenti del puntatore del submodule restano ordinati nel log invece di nascondersi dentro commit di merge. + +## Identità e Fiducia: `commit.gpgsign` + +Firmare i commit con GPG non riguarda la conformità o il superamento di audit. Riguarda la provenienza. Ogni commit sui miei repository porta la mia firma crittografica, la prova che viene da me e non è stata manomessa. + +```ini +[user] + signingkey = IL_TUO_KEY_ID_GPG + email = danix@danix.xyz + name = Danilo M. + +[commit] + gpgsign = true +``` + +La prima volta che si configura, è necessario che `gpg-agent` sia in esecuzione e che la chiave sia importata localmente. Una volta fatto, ogni commit viene firmato automaticamente. Se vuoi approfondire le chiavi GPG, ho scritto di [gestire le password con password-store](/it/articles/manage-your-passwords-with-password-store/), che copre la configurazione delle chiavi. + +## Ridurre l'Attrito: `help.autocorrect`, `fetch.prune` e `fetch.prunetags` + +Tre piccole impostazioni che risparmiano digitazioni quotidiane e carichi mentali. + +### help.autocorrect + +I refusi capitano. Scrivo spesso `git statsu` invece di `git status`, o `git comit` invece di `git commit`. Il vecchio comportamento è un messaggio di errore con una correzione suggerita. Con: + +```ini +[help] + autocorrect = 10 +``` + +Git autocorregge ed esegue il comando dopo un conto alla rovescia di 1 secondo: + +``` +$ git statsu +WARNING: You called a Git command named 'statsu', which does not exist. +Continuing in 0.9 seconds, assuming that you meant 'status'. +``` + +Il `10` qui significa 1 secondo (git misura in decimi). È abbastanza lungo da notarlo e interrompere se la correzione è sbagliata, ma abbastanza breve da non spezzare il ritmo. + +### fetch.prune e fetch.prunetags + +Quando si eliminano branch sul remote, i riferimenti obsoleti si accumulano nel repository locale. Queste impostazioni li puliscono: + +```ini +[fetch] + prune = true + prunetags = true +``` + +Ora `git fetch` rimuove silenziosamente i branch locali che non esistono più upstream, e fa lo stesso per i tag. Per un repository del tema Hugo, i vecchi tag di release vengono rimossi dal server, e `prunetags` fa sì che non restino nel tuo output di `git tag`. + +## Quando Arrivano i Conflitti: `merge.conflictstyle` e `rerere` + +Due impostazioni che rendono i conflitti di merge meno dolorosi. + +### merge.conflictstyle = zdiff3 + +I marcatori di conflitto normalmente mostrano due lati: + +``` +<<<<<<< HEAD +il tuo codice +======= +il loro codice +>>>>>>> branch +``` + +Vedi cosa hai scritto tu e cosa hanno scritto loro, ma non da dove entrambi sono partiti. Lo stile di conflitto `zdiff3` mostra l'antenato comune: + +``` +<<<<<<< HEAD +il tuo codice +||||||| base +codice originale +======= +il loro codice +>>>>>>> branch +``` + +La sezione `||||||| base` è ciò che entrambi i lati hanno modificato. Ora vedi la storia completa: tu hai cambiato questa riga in X, loro in Y, e l'originale era Z. L'intenzione diventa ovvia. + +```ini +[merge] + conflictstyle = zdiff3 +``` + +### rerere.enabled e rerere.autoupdate + +`rerere` sta per "reuse recorded resolution" (riutilizza la risoluzione registrata). Quando risolvi un conflitto manualmente, git ricorda la risoluzione. La prossima volta che si presenta lo stesso conflitto: + +```ini +[rerere] + enabled = true + autoupdate = true +``` + +Git lo risolve automaticamente. Questo è prezioso quando si ribasa un branch di contenuto su un main che include un aggiornamento del puntatore del submodule. La prima volta che c'è un conflitto nel riferimento del submodule, lo risolvi tu. Su un secondo branch con lo stesso conflitto, `rerere` lo gestisce silenziosamente, e `autoupdate` mette in staging la risoluzione così non devi fare `git add` manualmente. + +## Orientarsi: Visualizzazione Branch, Log e Diff + +Quattro impostazioni che rendono più veloce leggere la storia del repository. + +### branch.sort e column.ui + +```ini +[branch] + sort = -committerdate + +[column] + ui = auto +``` + +Di default, `git branch` elenca i branch in ordine alfabetico. Inutile dopo dieci branch. L'ordinamento per `-committerdate` mostra i più recenti per primi, il branch su cui probabilmente stai per passare è in cima. + +`column.ui = auto` mostra i branch su più colonne quando il terminale è abbastanza largo, riducendo lo scorrimento di una lista lunga. + +### log.abbrevCommit e log.follow + +```ini +[log] + abbrevCommit = true + follow = true +``` + +`abbrevCommit` mostra SHA corti (7 caratteri) invece degli hash completi da 40 caratteri. Log più puliti, più veloci da leggere. + +`follow` traccia i file attraverso i rename. Quando esegui `git log -- path/to/article.md` e quel file si chiamava prima `old-article.md`, il log non si interrompe, segue il file attraverso il rename e mostra la storia completa. + +### diff.mnemonicPrefix, diff.renames e diff.wordRegex + +```ini +[diff] + mnemonicPrefix = true + renames = true + wordRegex = [^[:space:]] +``` + +`mnemonicPrefix` cambia le intestazioni dei diff da `a/` e `b/` a etichette più descrittive come `i/` (index), `w/` (working tree), `o/` (object), `c/` (commit). Più informazioni a colpo d'occhio. + +`renames = true` rileva i rename dei file e li mostra come `file.old => file.new` invece di una cancellazione e una creazione. Diff più puliti. + +`wordRegex` definisce cosa conta come "parola" nei diff a livello di parola (`git diff --word-diff`). Il pattern `[^[:space:]]` tratta qualsiasi carattere non-spazio come una parola, il che significa che la punteggiatura ottiene i propri confini, utile per file ricchi di testo come gli articoli Markdown. + +## Le Abbreviazioni che si Guadagnano il Posto: Alias + +Tengo gli alias al minimo di proposito. Gli alias che nascondono cosa fa git sono rumore; questi due valgono il risparmio di battiture. + +### lg: Log formattato con grafo + +```ini +[alias] + lg = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all +``` + +Eseguendo `git lg` si ottiene un grafo colorato con hash, date, messaggi, autori e puntatori ai branch: + +``` +* abc1234 - (3 hours ago) Aggiungo articolo git config - Danilo M. (HEAD -> master) +* def5678 - (1 day ago) Fix CSS tema - Danilo M. +|\ +| * ghi9012 - (2 days ago) WIP: nuova funzione - Danilo M. (content/bozza) +|/ +* jkl3456 - (5 days ago) Bump submodule tema - Danilo M. (origin/master) +``` + +Molto meglio del semplice `git log`. + +### sw: Abbreviazione per switch + +```ini +[alias] + sw = switch +``` + +`git sw main` è più veloce da digitare di `git switch main`, e `git sw -c feature/nuovo` crea e passa in un solo comando. + +## Una Giornata Tipo + +Ecco come queste impostazioni lavorano insieme nella pratica. + +Mattina: sincronizzo con il repository. `git fetch` parte silenziosamente, `fetch.prune` e `prunetags` puliscono branch cancellati e tag vecchi senza che ci pensi. + +Inizio l'articolo della settimana per il sito Hugo. Creo un nuovo branch di contenuto: + +```bash +git sw -c content/git-config-in-profondita +``` + +Niente `--set-upstream` dopo. `push.autoSetupRemote` ci pensa lui. + +Scrivo, committo. Il commit viene firmato con GPG automaticamente. Nessun passaggio extra. + +```bash +git commit -m "Aggiungo prima bozza articolo git config" +``` + +Push quando ho finito: + +```bash +git push +``` + +Nessun errore di upstream. Funziona e basta. + +Più tardi, il branch main riceve un aggiornamento del submodule del tema. Ribaso il mio lavoro sopra: + +```bash +git fetch +git rebase main +``` + +C'è un conflitto nel puntatore del submodule, il repository del tema è andato avanti. `merge.conflictstyle = zdiff3` mi mostra esattamente cosa è cambiato. Lo risolvo una volta. + +Più tardi, un secondo branch ha lo stesso conflitto del submodule. `rerere` ricorda la mia risoluzione e la applica automaticamente con `rerere.autoupdate`. Nessuna ri-risoluzione. + +Prima di unire su main, controllo il grafo: + +```bash +git lg +``` + +L'output ordinato mostra la timeline chiaramente. + +Merge su main: + +```bash +git switch main +git merge content/git-config-in-profondita +``` + +Se c'è un conflitto qui (improbabile dato che abbiamo ribassato), `zdiff3` mostra il contesto dell'antenato. + +Fatto. Tutte le impostazioni hanno lavorato insieme in modo trasparente. + +## La Configurazione Completa + +Ecco il blocco completo così come sta nel mio `~/.gitconfig`: + +```ini +[user] + name = Danilo M. + email = danix@danix.xyz + signingkey = IL_TUO_KEY_ID_QUI + +[pull] + rebase = true + +[push] + autoSetupRemote = true + +[commit] + gpgsign = true + +[help] + autocorrect = 10 + +[fetch] + prune = true + prunetags = true + +[merge] + conflictstyle = zdiff3 + +[rerere] + enabled = true + autoupdate = true + +[branch] + sort = -committerdate + +[column] + ui = auto + +[log] + abbrevCommit = true + follow = true + +[diff] + mnemonicPrefix = true + renames = true + wordRegex = [^[:space:]] + +[alias] + lg = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all + sw = switch +``` + +Prendi quello che ti serve. Lascia quello che non si adatta al tuo flusso di lavoro. + +## Una Configurazione che Evolve + +Questa non è la configurazione git "corretta", è quella che si adatta a come lavoro io. La sto raffinando da anni e continuerà a evolversi man mano che trovo nuovi punti di attrito e scopro nuove impostazioni. L'obiettivo non è seguire la mia configurazione alla lettera, ma pensare a cosa ti rallenta e cercare l'impostazione git che lo risolve. + +Se usi qualcuna di queste impostazioni, o se ne hai trovate altre che hanno cambiato il tuo flusso di lavoro, fammelo sapere nei commenti. Sono sempre curioso di sapere come gli altri configurano i loro strumenti. diff --git a/content/it/articles/myself-as-a-droid/index.md b/content/it/articles/myself-as-a-droid/index.md index 0ec3758..4816cc0 100644 --- a/content/it/articles/myself-as-a-droid/index.md +++ b/content/it/articles/myself-as-a-droid/index.md @@ -7,8 +7,6 @@ draft = true categories = ["Blogging"] tags = ["web", "android", "droidify", "market"] +++ -<figure style="width: 500px" class="wp-caption aligncenter"><img loading="lazy" style="margin-right: auto; margin-left: auto;" src="http://danixland.net/wp-content/uploads/2011/02/wpid-android21.png" alt="image" width="500" height="500" /><figcaption class="wp-caption-text">che ve ne pare? il mio autoritratto in stile android!!</figcaption></figure> - -l’ho creato usando [droidify yourself][1], un’app di google per il market di android.. ;-) +l'ho creato usando [droidify yourself][1], un'app di google per il market di android.. ;-) [1]: https://market.android.com/details?id=com.google.android.apps.androidify
\ No newline at end of file diff --git a/content/it/articles/speak-to-me/index.md b/content/it/articles/speak-to-me/index.md index 84ee91c..a11cb81 100644 --- a/content/it/articles/speak-to-me/index.md +++ b/content/it/articles/speak-to-me/index.md @@ -7,12 +7,8 @@ categories = [ "Blogging"] tags = [ "mad", "pink floyd"] +++ -<blockquote class="wp-block-quote"> - <p> - I’ve always been mad, I know I’ve been mad, like the most of us are. It’s very hard to explain why you’re mad, even if you’re not mad. - </p> - - <cite>Pink Floyd – Speak to Me</cite> -</blockquote> +> I've always been mad, I know I've been mad, like the most of us are. It's very hard to explain why you're mad, even if you're not mad. +> +> — Pink Floyd – Speak to Me Credo che questo sarà il mio primo tattoo.. :)
\ No newline at end of file diff --git a/content/it/articles/wp_patcher-un-metodo-per-aggiornare-wordpress/index.md b/content/it/articles/wp_patcher-un-metodo-per-aggiornare-wordpress/index.md index cdb77a6..dbfc23b 100644 --- a/content/it/articles/wp_patcher-un-metodo-per-aggiornare-wordpress/index.md +++ b/content/it/articles/wp_patcher-un-metodo-per-aggiornare-wordpress/index.md @@ -22,7 +22,8 @@ Detto fatto, mi sono messo a giocare un po’ con Vim e ho tirato fuori **wp Questo è lo script: -<pre class="wp-block-preformatted language-bash"><code>#! /bin/bash +```bash +#! /bin/bash # WP-patcher - script che si occupa di recuperare le differenze # tra 2 versioni differenti di WordPress, scaricando le revisioni # tramite svn. @@ -70,7 +71,7 @@ svn export $new_vrs wp_$sane_new_vrs rm -rf $old_vrs $new_vrs echo "ho esportato correttamente le 2 versioni di wordpress" echo "adesso procedo alla creazione della patch" -diff -qr wp_$sane_old_vrs wp_$sane_new_vrs |cut -d" " -f4 > patch_file.txt +diff -qr wp_$sane_old_vrs wp_$sane_new_vrs |cut -d" " -f4 > patch_file.txt mkdir $patchdir mods=`cat patch_file.txt` for i in $mods;do @@ -89,7 +90,8 @@ rm -rf $workdir echo "l'archivio contenente i files da sostituire" echo "è il file 'wp_${patchdir}.tar.bz2" # fine :) -exit 0</code></pre> +exit 0 +``` E’ molto semplice e non dovrebbe essere difficile modificarlo secondo le vostre necessità… @@ -105,11 +107,7 @@ Perchè lo script funzioni è necessario che nel sistema sia installato svn, tar Una volta creato l’archivio con i files da aggiornare vi basterà decomprimerlo e caricare i files sul vostro spazio web sovrascrivendo quelli già presenti. Nel caso in cui fosse necessario un aggiornamento del database di WordPress vi basterà lanciare dal browser la pagina **http://urldelblog/wp-admin/upgrade.php**. -<blockquote class="wp-block-quote alert"> - <p> - <strong><em>Come sempre vale il consiglio, prima di aggiornare WordPress, di effettuare un backup dei files e del database, in modo da poter ripristinare una situazione funzionante in caso di problemi.</em></strong> - </p> -</blockquote> +> **_Come sempre vale il consiglio, prima di aggiornare WordPress, di effettuare un backup dei files e del database, in modo da poter ripristinare una situazione funzionante in caso di problemi._** Questo script come potete vedere è rilasciato sotto la GPL v3, quindi è liberamente utilizzabile e modificabile entro i termini di questa licenza appunto. diff --git a/content/it/articles/xrandr-e-dual-head-su-slackware-12-2-e-intel/index.md b/content/it/articles/xrandr-e-dual-head-su-slackware-12-2-e-intel/index.md index 3a82dba..c750a32 100644 --- a/content/it/articles/xrandr-e-dual-head-su-slackware-12-2-e-intel/index.md +++ b/content/it/articles/xrandr-e-dual-head-su-slackware-12-2-e-intel/index.md @@ -23,7 +23,8 @@ Ovviamente facendo in questo modo ho una superficie del desktop di circa il 120% A questo punto, ogni qualvolta io voglia attivare il doppio desktop, mi basterà lanciare questo script che mi sono creato, l’ho chiamato **dualhead.sh**: -<pre>#! /bin/bash +```bash +#! /bin/bash case $1 in start ) xrandr --output LVDS --mode 1280x800 \ @@ -35,7 +36,8 @@ case $1 in exit 1 ;; esac -exit</pre> +exit +``` lanciandolo con flag “start” avvierà il dualhead mentre lanciando lo script con “stop” tutto il desktop ritornerà sul solo schermo del laptop in quanto xrandr spegnerà l’uscita vga esterna. |