Script sostitutivo di Dropbox

[Stemby]

Magari nel file README scrivici qualcosa...

[mirko.pagliai]

Devo ancora finire di sistemare Github (e relativo README :-D ).
Intanto ho preparato lo script per configurazione interattiva. Ecco una dimostrazione:

Codice: Seleziona tutto

mirko@mirko-laptop:~/Fud$ ./fudconf 
Questo script configurerà Fud tramite domande interattive. Per maggiori informazioni, consultare la documentazione di Fud o fare riferimento al file di esempio fud.sample-conf.
Configurare Fud? (Y/n): Y

Scegli il metodo da utilizzare per la sincronizzazione.
[1] ssh
[2] ftp
Metodo: 2
Selezionato il metodo ftp.

Server per la connessione: ftp.myserver.com

Utente per la connessione: myuser

Per eseguire la connessione al server, potrebbe essere necessaria una password. Tuttavia, questa opzione non è obbligatoria, perché l'utente indicato potrebbe non avere una password oppure perché si è deciso di utilizzare ssh con un certificato, ad esempio. Nel caso non sia necessario indicare una password, lasciare in bianco questa opzione
Password per la connessione: mypwd

Porta per la connessione: 21

Indicare una directory locale da sincronizzare. Se questa directory non esiste, verrà creata.
Directory locale da sincronizzare: [/home/mirko/Fud] /home/mirko/myownbackups
Creata la directory /home/mirko/myownbackups

Indicare una directory remota per la sincronizzazione. Se questa directory non verrà indicata, verrà stabilita dal server.
Directory remota per la sincronizzazione: /backup

Se lo si desidera, si possono specificare delle opzioni aggiuntive per Unison, oltre a quelle già utilizzate da Fud. Consultare `man unison` per maggiori informazioni. Se non si sa cosa si sta facendo, lasciare vuota questa opzione
Opzioni aggiuntive per Unison: 

Vuoi che Fud venga lanciato automaticamente all'avvio? (Y/n): Y

Successo: Fud è stato correttamente configurato ed è pronto per essere utilizzato. Buona sincronizzazione!

Et voilà:

Codice: Seleziona tutto

mirko@mirko-laptop:~/Fud$ cat ~/.fud/fud.conf 
METHOD="ftp"
SERVER="ftp.myserver.com"
USER="myuser"
PWD="mypwd"
PORT="21"
LPATH="/home/mirko/myownbackups"
RPATH="/backup"
EXTRAOPTIONS=""

Giusto una cosa. Nell'output c'è questo:

Indicare una directory remota per la sincronizzazione. Se questa directory non verrà indicata, verrà stabilita dal server.

Secondo voi è chiaro?

Poi, per l'avvio automatico, questo è il codice:

Codice: Seleziona tutto

		# Gnome
		if [ ! -e "~/.config/autostart" ]; then
			#Crea il file ~/.config/autostart/fud.desktop
			echo -e "\n[Desktop Entry]\nName=Fud\nGenericName=File Synchronizer\nComment[en_GB]=Sync your files\nComment[it]=Sincronizza i tuoi file\nExec=fud\nTerminal=false\nType=Application\nIcon=fud\nHidden=false\nCategories=Network;FileTransfer;\nStartupNotify=false" > ~/.config/autostart/fud.desktop
		fi

Che dovrebbe avere effetto solo se si utilizza gnome. Per gli altri de? Avete indicazioni?

[mirko.pagliai]

Comunque di modi per essere utili ce ne sono:
1) un'icona per Fud. C'è il file .svg che ho lasciato (non si sa mai), ma sono una frana con la grafica. Ci vorrebbe qualcosa di più carino;
2) qualcuno che si occupi del discorso "licenza";
3) verificare se esiste qualche servizio che offra un dominio gratuito con possibilità di hostare file (so che molti, soprattutto gli italiani, pretendono che lo spazio venga utilizzato per un sito effettivo). Quindi scrivere una guida su come crearsi uno spazio gratuito e configurare Fud per utilizzarlo;
4) per ora sto procedendo mischiando inglese e italiano :-D alla fine, bisognerebbe occuparsi di localizzare correttamente il tutto. Io un po' di inglese lo mastico, ma non sono all'altezza del compito;
5) debug, debug, debug.

[mirko.pagliai]

Applicate ulteriori modifiche e - in un certo senso - sono riuscito a stabilizzare il codice. Inoltre ho automatizzato il tutto, così che non sia necessario modificare file affinché lo script funzioni.
Possiamo, in altri termini, considerarla come la prima beta, in attesa di riscontri positivi :-D

Per provare Fud:

Codice: Seleziona tutto

$ git clone git://github.com/mirkop88/Fud.git
# ./Fud/install
$ fudconf

Vi sconsiglio di abilitare l'avvio automatico (che comunque funziona, per ora, solo con Gnome). Piuttosto, lanciate Fud da riga di comando:

Codice: Seleziona tutto

$ fud

Se si sceglie la modalità Ftp, per ora verranno mostrate informazioni relative alla connessione.

Fatemi sapere!

Adesso:
1) un po' di documentazione;
2) controllo dell'output e delle attività di logging, completamente da rivedere.

[pmate]

Complimenti, hai fatto un gran bel lavoro!

Ho creato un account anch'io su github e ho provveduto al fork del tuo repository (come spiegato in questa pagina). In questo modo mi sarà più semplice "tenermi aggiornato" sugli sviluppi e provvedere a qualche esperimento di mio.

Procederò al debug (spero) più tardi o tutt'al più nella giornata di domani.

Una sola considerazione: visto che il fine è quello di facilitare le cose all'utente finale, credo sia cosa buona prevedere anche la presenza di un eventuale proxy. Insomma, fare in modo che lo script di configurazione possa (se necessario) fare l'export di http_proxy (e di eventuali parametri di autenticazione).

Tutto ciò posso aggiungerlo io allo script senza nessun problema e proporti il diff.

A te la palla.

Ciao,
pmate

[sconosciuto]

Per quanto riguarda l'autostart dovrebbe andare bene per tutti i DE: http://standards.freedesktop.org/autost ... ml#startup. Posso dirti comunque che su KDE funziona (non ho provato tutto lo script, ma ho eseguito il comando che crea il file fud.desktop cambiando la voce Exec=fud).

[mirko.pagliai]

Ho creato un account anch'io su github e ho provveduto al fork del tuo repository (come spiegato in questa pagina). In questo modo mi sarà più semplice "tenermi aggiornato" sugli sviluppi e provvedere a qualche esperimento di mio.

Tutto ciò posso aggiungerlo io allo script senza nessun problema e proporti il diff.

La mia intenzione è quella di accettare il contributo di tutti e invitare tutti allo sviluppo dello script.
Il mio problema è git: mi pare di capire sia il classico strumento ad alta latenza, ovvero dalla enormi potenzialità ma richiedente un certo tempo di studio. E questo tempo non l'ho ancora trovato, per ora :-) Senza contare che volevo anche valutare altri servizi gratuiti, oltre a GitHub.
In altri termini, non ho ancora capito come estendere le funzionalità di git ad altre persone. Mi preme anche poter creare a breve un nuovo ramo, onde evitare di apportare continuamente cambiamenti ad un unico ramo e rendere lo script pressoché inutilizzabile per chi è interessato solo a provarlo.
Per ora ti ho aggiunto tra i collaboratori, dal menù admin, ma non sono un granché sicuro che funzioni così :-D

Una sola considerazione: visto che il fine è quello di facilitare le cose all'utente finale, credo sia cosa buona prevedere anche la presenza di un eventuale proxy. Insomma, fare in modo che lo script di configurazione possa (se necessario) fare l'export di http_proxy (e di eventuali parametri di autenticazione).

Non ci avevo proprio pensato. Ma proprio per niente... sarà che non uso e non ho mai usato un proxy.
Accetto di buon grado :-D E colgo l'occasione per estendere nuovamente l'invito a tutti.

Per quanto riguarda l'autostart dovrebbe andare bene per tutti i DE: http://standards.freedesktop.org/autost ... ml#startup. Posso dirti comunque che su KDE funziona (non ho provato tutto lo script, ma ho eseguito il comando che crea il file fud.desktop cambiando la voce Exec=fud).

Dato un'occhiata al link, perfetto. Quindi la prendo come funzionante, non avendo tempo/possibilità di testarlo sotto i vari de, e in attesa che qualcuno affermi il contrario.
Ho sottolineato un passaggio: come intend con "cambiando la voce"? A me risulta sia impostata già così

[sconosciuto]

No niente, volevo solo dire che al posto di Exec=fud ho messo un comando valido per il mio sistema (Exec=dolphin), perché se il comando non esiste KDE non mostra la voce nel systemsettings. Mi sono spiegato male.

[pmate]

In altri termini, non ho ancora capito come estendere le funzionalità di git ad altre persone. Mi preme anche poter creare a breve un nuovo ramo, onde evitare di apportare continuamente cambiamenti ad un unico ramo e rendere lo script pressoché inutilizzabile per chi è interessato solo a provarlo.

Per aggiungere un nuovo ramo (ad esempio... "nuovoramo"):

Codice: Seleziona tutto

$ cd Fud
$ git branch nuovoramo

Per lavorare sul nuovo ramo:

Codice: Seleziona tutto

$ git checkout nuovoramo

fai le modifiche che vuoi e poi:

Codice: Seleziona tutto

$ git commit -m "testo di esempio"
$ git push origin nuovoramo

Per ritornare al ramo principale:

Codice: Seleziona tutto

$ git checkout master

etc. etc.
In pratica col checkout apponi un tag specifico alle modifiche. Al momento del push quei tag vengono inviati al repo.
Più facile a farsi che a dirsi!

Ho visto che hai accettato la mia prima pull request... era un semplice typo ma occasione utile per esplorare github.

Per ora ti ho aggiunto tra i collaboratori, dal menù admin, ma non sono un granché sicuro che funzioni così :-D

Funziona così (grazie di avermi inserito) tanto che posso uploadare le modifiche direttamente sul tuo master.
Però credo sia meglio come ho fatto fino adesso: tengo il fork del tuo master e ho creato un trunk. In quest'ultimo faccio le modifiche e ti propongo una pull request in modo tale che tu possa valutare la proposta, testare se vuoi e poi decidere se applicare al ramo principale oppure no.
Credo sia meno invasivo così.

Non ci avevo proprio pensato. Ma proprio per niente... sarà che non uso e non ho mai usato un proxy.
Accetto di buon grado :-D E colgo l'occasione per estendere nuovamente l'invito a tutti.

Hai una nuova pull request (faccio presente che non ho testato il codice).

Per il resto mi riservo di testare installazione e configurazione domani su un muletto.
Ho provato lo script al volo su vm ma ci sono delle cose che non mi hanno convinto. Preferisco però riprovare con calma ed eventualmente schematizzare per bene i miei dubbi.

Ciao,
pmate

[mirko.pagliai]

Per aggiungere un nuovo ramo (ad esempio... "nuovoramo"): [...]

E secondo te, quanti e quali rami possono essere adatti per sviluppare tranquillamente uno script del genere (cioè non troppo lungo e complesso, dal punto di vista del codice)?
Io avevo pensato di creare almeno un ramo "stable" (o presunto tale), dove il codice si può grossomodo assumere come tale, e un ramo "di sviluppo", soggetto a cambiamenti anche continui (e quindi di scarso interesse per chi vuole subito utilizzare lo script).

Per ora ti ho aggiunto tra i collaboratori, dal menù admin, ma non sono un granché sicuro che funzioni così :-D

Funziona così (grazie di avermi inserito) tanto che posso uploadare le modifiche direttamente sul tuo master.
Però credo sia meglio come ho fatto fino adesso: tengo il fork del tuo master e ho creato un trunk. In quest'ultimo faccio le modifiche e ti propongo una pull request in modo tale che tu possa valutare la proposta, testare se vuoi e poi decidere se applicare al ramo principale oppure no.
Credo sia meno invasivo così.

Il discorso... fila. Vada così, allora.
Mi sto anche studiando un po' Git (per chi fosse interessato, ho trovato questa splendida ed esaustiva guida.

[pmate]

E secondo te, quanti e quali rami possono essere adatti per sviluppare tranquillamente uno script del genere (cioè non troppo lungo e complesso, dal punto di vista del codice)?
Io avevo pensato di creare almeno un ramo "stable" (o presunto tale), dove il codice si può grossomodo assumere come tale, e un ramo "di sviluppo", soggetto a cambiamenti anche continui (e quindi di scarso interesse per chi vuole subito utilizzare lo script).

Mah secondo me i tradizionali "master" e "trunk" possono andare bene per le due tipologie "stabile" e "di sviluppo".
Poi se le esigenze cambiano è un attimo aggiungere/togliere/unire/separare i rami.
Per il momento, ripeto, credo che due rami (master e trunk - o come più ritieni opportuno -) siano sufficienti.

pmate

[Stemby]

Per aggiungere un nuovo ramo (ad esempio... "nuovoramo"): [...]

E secondo te, quanti e quali rami possono essere adatti per sviluppare tranquillamente uno script del genere (cioè non troppo lungo e complesso, dal punto di vista del codice)?

Più che i rami master (trunk) e sviluppo (branch) come nel vecchio SVN, visto che con Git la gestione delle branche è uno dei suoi punti cardini, ti consiglio di aprire un nuovo ramo per ogni singolo "argomento". Mi spiego con un esempio: vuoi aggiungere la gestione del proxy? Crei un ramo "proxy". Poi quando hai finito il lavoro e tutto è testato a dovere, merge in master e seghi via il ramo proxy. Questo può avvenire anche dopo aver aperto altri rami: i merge di solito vanno lisci (Git è davvero efficientissimo in questo).

Mi sto anche studiando un po' Git (per chi fosse interessato, ho trovato questa splendida ed esaustiva guida.

Sì, quello è il miglior manuale disponibile.

Ciao!

[mirko.pagliai]

Più che i rami master (trunk) e sviluppo (branch) come nel vecchio SVN, visto che con Git la gestione delle branche è uno dei suoi punti cardini, ti consiglio di aprire un nuovo ramo per ogni singolo "argomento". Mi spiego con un esempio: vuoi aggiungere la gestione del proxy? Crei un ramo "proxy". Poi quando hai finito il lavoro e tutto è testato a dovere, merge in master e seghi via il ramo proxy. Questo può avvenire anche dopo aver aperto altri rami: i merge di solito vanno lisci (Git è davvero efficientissimo in questo).

Wow! Questo sì che mi piace! :-) Un ramo stabile, uno di sviluppo, sotto-rami di sviluppo per argomento! :-D

[Stemby]

Un ramo stabile, uno di sviluppo, sotto-rami di sviluppo per argomento! :-D

Beh, il ramo di sviluppo principale diventa inutile: solo il master più tanti rami di sviluppo, uno per ogni argomento.

[mirko.pagliai]

Chi non sta partecipando non sa quale divertimento si sta perdendo! :-D

The Fud network graph:
https://github.com/mirkop88/Fud/network

;-)

p.s. quanto detto da Stemby:

Più che i rami master (trunk) e sviluppo (branch) come nel vecchio SVN, visto che con Git la gestione delle branche è uno dei suoi punti cardini, ti consiglio di aprire un nuovo ramo per ogni singolo "argomento". Mi spiego con un esempio: vuoi aggiungere la gestione del proxy? Crei un ramo "proxy". Poi quando hai finito il lavoro e tutto è testato a dovere, merge in master e seghi via il ramo proxy. Questo può avvenire anche dopo aver aperto altri rami: i merge di solito vanno lisci (Git è davvero efficientissimo in questo).

Mi pare di aver capito, è alla base di Git. Conviene e bisogna mettere ogni modifica per "argomento" su un singolo ramo.
E così è, per ora, per il proxy e il supporto a ntf (quest'ultimo ancora tutto da testare...).