Newsgroup: it.comp.www.php
Titolo: monitor di debug

Durante la realizzazione di un'applicazione, per vedere i risultati 
ottenuti (funzionamento generale dell'applicazione e/o vari dati di 
debug) in genere si passa continuamente dal proprio editor per file php, 
al browser (o al terminale, se si tratta di una cli-app).
Questa operazione svolta spesso centinaia di volte al giorno, rende 
nevrotici...
In ambito professionale come ci si organizza?
Doppio monitor? Strumenti per indirizzare gli outputs/streams su altri 
dispositivi? Replicatori di desktop?
Voi come siete organizzati?

 Doppio monitor? 
 
Trovo il doppio monitor pessimo per questo uso. Non c'è una combinazione 
di tasti (che io sappia) in nessun SO che dica "passa alla finestra attiva 
sull'altro monitor", quindi di solito ci si riduce a premere alt-tab finchè 
non si trova la finestra giusta, facendo perdere tempo e diventare 
nevrotici.
 
Io su Linux tengo l'editor sul desktop virtuale 1, la shell sul 2, il 
browser sul 3. Passo da uno all'altro con Alt-F1, F2, F3.
 
Quindi quando lavoro su un sito: edit, alt-f3, f5, alt-f1, edit
 
Su shell: edit, alt-f2, up, enter, alt-f1, edit
 
Il doppio monitor è utile quando hai un (o più) tail sui log su uno dei 
due mentre interagisci con l'altro.
In pratica: un monitor passivo e uno attivo.
 
Quando sviluppo librerie o componenti, rimango sull'editor e lancio i test 
con una combinazione di tasti (ctrl-r su PHPStorm)
 
Se stai facendo "tracing" delle variabili di un'applicazione web, ti 
consiglio monolog con output su firebug, così vedi i dump direttamente 
nella console del browser, senza abusare dei print che ti spaccano 
l'output.
 
Bye.


 
Niente di nuovo insomma.
 

 
 
Concordo, è utile solo per tenere d'occhio logs o output di processi lunghi
e, anche lì, giusto per sentirsi fichi, visto che abbiamo solo due occhi e
per leggere qualcosa servono entrambi.
 
Ciao!

 per leggere qualcosa servono entrambi.
 
Ma servono anche le dita (a fine giornata ho i campri) per passare 
*freneticamente* da una finestra/desktop all'altra.
 

 *freneticamente* da una finestra/desktop all'altra.
 
Lo dicono anche i pianisti e i chitarristi alle prime armi. :P
 
Bye.


Certo, ma per quanto riguarda il nostro campo la tecnologia (invece di 
pensare solo a produrre principalmente cellulari, teblet, notebook per 
gente figa) ci potrebbe aiutare.
Una macchinetta a parte (programmabile oppurtunamente) con apposito 
monitor, che esegue i test in modo ciclico e ne visualizza i risultati 
in real-time... perchè non la progettano?
Mani sempre sull'editor (niente tic-tac per passare da una *schermata* 
all'altra), occhi sempre sulla tester-machine (digito una cosa e vedo 
subito gli effetti)!!!


 
Questo lo puoi fare anche subito, non ci vuole nulla..
Per il browser, lo metti sul secondo monitor e imposti un refresh ogni N
secondi. Per applicazioni shell idem, puoi impostare degli hook che fanno
girare i test su ogni save, o git add, o chessò io. Tieniti pronto ad avere
sempre, costantemente, una valanga d'errori (statisticamente i refresh o i
test gireranno quasi sempre metre stai ancora facendo modifiche). Questo sì
che, personalmente, mi farebbe innervosire alquanto..
 
Quindi boh, almeno per come lavoro io non la vedo come una cosa tanto utile:
non è che scrivi una riga - controlli - scrivi un'altra riga - controlli, etc.
stai sull'editor almeno 10/15 minuti ogni volta, e poi fai girare i test e/o
controlli il browser: fare la combinazione di tre tasti dopo che ne hai 
premuti diecimila non mi sembra un grande sforzo :)
 
Ciao!

subito gli effetti)!!!
 
Qualcosa come un server di Continuous Integration, intendi? :-D
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 premuti diecimila non mi sembra un grande sforzo:)
 
E ad un test iniziale in genere seguono altre decine di interventi di 
assestamento :D
 

 Qualcosa come un server di Continuous Integration, intendi? :-D
 
In un certo senso :D
 

 assestamento :D
 
Se hai i test, appunto, di solito è una combinazione di tasti sull'IDE, 
altrimenti hai un phpunit in loop su un terminale.
 
Se stai facendo e2e di solito non lo puoi avere in tempo reale, perchè 
può durare ore, e non lo vuoi fare su codice "live", ma solo quando stai 
per fare deploy.
 
A dire il vero non sono sicuro di aver capito il tuo use case.
 
Bye.
 
 


 
Se gli "interventi d'assestamento" sono la normalità non hai un problema di
editor, ma di metodologia di sviluppo..
 
Ciao!

Dovi devi guardare per controllare?
 
In genere nel file 'tags' :-)
 
Altrimenti nell'output di phpgrep, o tool similari come rephactor o scisr.
 
...questo, nell'ipotesi che il tuo IDE (e.g. PHPStorm) non lo faccia di suo.



 
per evitare ciò faccio diventare le vecchie funzioni dei puntamenti alle 
nuove funzioni; ma quindi in genere qual'è la strategia?

 nuove funzioni; ma quindi in genere qual'è la strategia?
 
SOLID. La O sta per Open for extension, Closed for modification.
 
Una volta che una funzione è pubblica e usata da altre parti del 
software, non la devi modificare, nè la firma, nè soprattutto il risultato.
 
Puoi scrivere una nuova funzione con un nome diverso cha fa più cose, e 
riscrivere la vecchia funzione perchè usi la nuova, ma devi mantenere 
gli stessi parametri e lo stesso risultato sulla vecchia.
 
Se stai sviluppando un sistema nuovo, e quindi fai spesso refactoring, 
il discorso è diverso, ma allora nessuno all'esterno la sta usando, 
quindi tecnicamente non è ancora pubblica.
 
In questo caso lo fai a mano, se l'IDE non ti fornisce tool di 
refactoring, ma lo scope è limitato e non dovrebbe essere difficile 
gestirlo.
 
Bye.
 

 gestirlo.
 
Refactoring automatizzato dici... con tutti i rischi e le 
controindicazioni; ho cercato sempre di evitarlo.
Cmq tu di solito cosa usi? Scisr?

 Cmq tu di solito cosa usi? Scisr?
 
PHPStorm. :)
 
Bye.
 

 PHPStorm. :)
 
OK, mi sa che dovrò iniziare a fidarmi degli automatismi, a costo di 
intensificare le precauzioni: backup preventivo, istantanee di git, ecc.
 


Io uso un doppio monitor. Su uno ho l'ambiente di sviluppo, sull'altro 
il browser con la pagina di sviluppo.
Generalmente il mio debug esce o sull'error log oppure nella pagina di 
sviluppo.
Mantengo costantemente un terminale con "tail -f error.log" nello stesso 
monitor dell'ambiente di sviluppo, che porto in primo piano quando serve.
Usando ubuntu trovo estremamente comode le funzioni messe a disposizione 
di Unity (a dispetto di quanto se ne parli male) per bloccare una 
finestra su tutti i desktop.


 
Dai, Unity è veramente uno schifo :) Monta xfce: ha più funzioni, è più carino
e un ordine di grandezza più leggero. Perché Unity sia il WM di default non
l'ho mai capito.
 
Ciao!