Fortunatamente non faccio più parte della categoria.. ma cmq tutto il mio appoggio agli eroi del nuovo millennio..
ciuaz
Fortunatamente non faccio più parte della categoria.. ma cmq tutto il mio appoggio agli eroi del nuovo millennio..
ciuaz
Ultimamente ho registrato per comodità alcuni domini .IT su TopHost, gestendoli poi direttamente sul mio account di Dreamhost.
La scelta è ricaduta su Tophost perchè (tralasciando il servizio di hosting che vale quanto costa) permette di modificare i propri DNS molto semplicemente ed ha dei decenti tempi di aggiornamento.
Le operazioni da fare per far si che i DNS vengano quindi gestiti da Dreamhost sono poche e semplici.
Dopo anni di utilizzo di GUI la memoria inizia a fare brutti scherzi. Dopo essermi dimenticato dell’esistenza di fsck
la scorsa settimana, oggi ho sbattuto la testa 10 minuti sulla tastiera per ricordarmi come settare la giusta timezone in un server Centos 5 sul quale non è presente nessuna GUI.
Beh, la soluzione è veramente semplice, basta infatti copiare il file /usr/share/zoneinfo/Europe/Rome
in /etc/localtime
.
Nulla di più! :)
Ovviamente se il vostro localtime è diverso basterà selezionare quello corretto dal path /usr/share/zoneinfo/
.
ciuaz
Lavorare con SVN offre moltissime comodità, dallo sviluppo di gruppo, alla gestione delle revisioni, alla possibilità di fare fork del proprio ramo di sviluppo per gestire più versioni.
Un’ulteriore comodità che ho scoperto da poco è la possibilità di attivare dei trigger quando vengono compiute particolari azioni (ad esempio un commit).
Ponete di avere il server SVN sulla stessa macchina dov’è presente il server web di sviluppo, cosa ci sarebbe di più comodo ed efficente di avere una versione bleeding-edge online ogni volta che fate un commit? Ma non solo, infatti potete creare degli script per eseguire automaticamente le unit test ad ogni modifica o per inviare email alla ML di sviluppo per avvertire della presenza di aggiornamenti, etc.
Per farlo bastano pochi passi.
Come qualche lettore attento si ricorderà la settimana scorsa e quella prima alcuni dei miei pc hanno deciso che erano troppo stanchi di lavorare ed hanno tirato le cuoia. Mentre nel portatile mi è bastato cambiare l’hd (per fortuna ancora in garanzia) con il fisso la faccenda è stata più seria (sk. madre a puttane).
La cosa mi ha portato a valutare possibili soluzioni per salvaguardare il mio lavoro (ed i miei dati personali) da implementare con la nuova macchina che dovrò ahimè comprare. Innanzitutto, stanco del backup mensile manuale su DVD degli archivi di lavoro (email, configurazioni, documenti e file di sviluppo) sono giunto a due conclusioni distinte ma non contrastanti. Sistemi ridondanti (sul server) e backup su supporti esterni.
Domani Oggi (maledetto google calendar con avvisi anticipati di un giorno) è il SysAdmin Day, quindi cari utenti andate dal vostro amministratore di sistema di fiducia, stringetegli la mano e ringraziatelo di tutto cuore per quello che fa per voi. :)
ciuaz
Se vi capita di usare php per generare file e dovete far in modo che questi ultimi siano modificabili non solo dall’utente apache ma anche dagli altri utenti appartenent al suo stesso gruppo dovrete aprire /etc/init.d/httpd
(o /etc/init.d/apache
) ed inserire subito prima all’invocazione dell’eseguibile la seguente stringa: umask 002
.
Riavviate apache e provate a creare un file con php, il permesso settato dovrebbe essere adesso 664 invece che 644, per modificare i permessi dando ad esempio la lettura/scrittura a tutti (666) il valore di umask sarà invece 000.
Un problema abbastanza noto dello Zend Studio 5 è che l’inclusione di librerie dinamiche (usando il server interno) non funziona un granchè bene.
Quindi se ad esempio vogliamo usare classi PEAR senza usare il path completo delle stesse ma limitandoci a quelli relativi (molto comodi se poi l’applicazione verrà migrata su un server configurato allo stesso modo della macchina di sviluppo) e delegando quindi PHP a cercare negli include_path
predefiniti ci troveremmo a ricevere dallo Zend Studio una marea di errori e warning.
Per risolvere basta aggiungere una riga di configurazione al php.ini
utilizzato dallo Zend Studio per il debug degli script.
aprite quindi il file relativo alla versione di php su cui sviluppate (ad esempio io uso php5)
[code]root@tartar# vi /usr/local/Zend/ZendStudio-5.2.0/bin/php5/php.ini[/code]
ed aggiungete come ultima riga il path nel quale avete installato le librerie PEAR
[code]include_path =/usr/share/pear[/code]
A questo punto provate a far ripartire il debug del codice et voillà! tutto funziona perfettamente ;)
ciuaz