Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20907 > unrolled thread

monitor di debug

Back to article view | Back to it.comp.www.php

Contents

  monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-04 08:58 +0200
    Re: monitor di debug Alessandro Pellizzari <shuriken@amiran.it> - 2016-06-04 08:04 +0000
      Re: monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-04 15:44 +0200
      Re: monitor di debug fmassei@gmail.com - 2016-06-04 10:40 -0700
        Re: monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-05 13:19 +0200
          Re: monitor di debug Alessandro Pellizzari <shuriken@amiran.it> - 2016-06-05 12:20 +0000
            Re: monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-05 14:56 +0200
              Re: monitor di debug fmassei@gmail.com - 2016-06-05 11:00 -0700
                Re: monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-06 15:12 +0200
                  Re: monitor di debug Alessandro Pellizzari <shuriken@amiran.it> - 2016-06-06 15:26 +0100
                  Re: monitor di debug fmassei@gmail.com - 2016-06-06 19:21 -0700
                    Re: monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-08 11:59 +0200
                      Re: monitor di debug Alessandro Pellizzari <shuriken@amiran.it> - 2016-06-08 11:53 +0100
                        Re: monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-08 13:21 +0200
                          Re: monitor di debug Alessandro Pellizzari <shuriken@amiran.it> - 2016-06-08 13:15 +0100
                            Re: monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-08 15:15 +0200
                  Re: monitor di debug Leonardo Serni <lserni@gmail.com> - 2016-06-07 14:39 +0200
              Re: monitor di debug Leonardo Serni <lserni@gmail.com> - 2016-06-05 20:13 +0200
                Re: monitor di debug alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-06-06 15:14 +0200
    Re: monitor di debug marimbarza <fan@culo.it> - 2016-06-12 19:11 +0200
      Re: monitor di debug fmassei@gmail.com - 2016-06-12 12:01 -0700

Page 1 of 2  [1] 2  Next page →

#20907 — 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?

[toc] | [next] | [standalone]

#20908

Il Sat, 04 Jun 2016 08:58:12 +0200, alex ha scritto:

> 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...

A me rende nevrotico su OSX, dove ci mette quasi 1 secondo a cambiare 
desktop tra l'editor e il browser e viceversa (se qualcuno ha un hack per 
abbassare questo tempo su Yosemite gli pago una birra, ma vi garantisco che 
non è una semplice ricerca su Google :P).

Su Linux (Mate) ci mette un centesimo di secondo e non mi pesa per niente.

> In ambito professionale come ci si organizza?
> 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.

[toc] | [prev] | [next] | [standalone]

#20909

Il 04/06/2016 10:04, Alessandro Pellizzari ha scritto:
>
> 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
>

Niente di nuovo insomma.

[toc] | [prev] | [next] | [standalone]

#20910

On Saturday, June 4, 2016 at 4:04:32 AM UTC-4, Alessandro Pellizzari wrote:
> 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
> 

Idem qui, anche se con un setup leggermente diverso :)
Browser su 1, 3 shells 80x54 (più una 80x10 per compile/git/publish/etc.) sul
2, 1 shell di log sul 3, MySQL workbench sul 4, documenti vari dal 5 in poi.
Devo passare velocemente tra due desktop praticamente solo tra 1 e 2, e lo
faccio con ctrl+alt+destra/sinistra, che trovo più comodo perché quei tasti
ce l'ho sotto le dita, mentre gli F-qualcosa non li trovo mai senza guardare
:D e comunque è più facile ricordarsi cosa è a sinistra o a destra di cosa
invece che il numero :)

Comunque non mi trovo *così* spesso a cambiare desktop: l'unica cosa che
potrebbe portare via tempo nel farlo è quando si aggiustano i fogli di stile
o lo HTML, ma quello lo faccio nell'inspector del browser e copio-incollo
nel codice quando ho finito...
Quando devo avere la struttura del DB sott'occhio mentre scrivo codice, mi
porto dietro una shell dal desktop 2 al 4 (ctrl+alt+shift+destra/sinistra) e
la riporto indietro quand'ho fatto :)

> 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.
> 

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!

[toc] | [prev] | [next] | [standalone]

#20913

Il 04/06/2016 19:40, fmassei@gmail.com ha scritto:
>> 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.
>> >
> 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.

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

[toc] | [prev] | [next] | [standalone]

#20914

Il Sun, 05 Jun 2016 13:19:09 +0200, alex ha scritto:

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

Lo dicono anche i pianisti e i chitarristi alle prime armi. :P

Bye.

[toc] | [prev] | [next] | [standalone]

#20915

Il 05/06/2016 14:20, Alessandro Pellizzari ha scritto:
> Il Sun, 05 Jun 2016 13:19:09 +0200, alex ha scritto:
>
>> Ma servono anche le dita (a fine giornata ho i campri) per passare
>> *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)!!!

[toc] | [prev] | [next] | [standalone]

#20916

On Sunday, June 5, 2016 at 8:56:36 AM UTC-4, alex wrote:
> 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!

[toc] | [prev] | [next] | [standalone]

#20918

Il 05/06/2016 20:00, fmassei@gmail.com ha scritto:
> 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..
>

Il monitor lo devi guardare solo quando serve 1-2 volte al minuto.

> 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.

In fase di creazione pura.
Se devi fare un refactoring ad es. in genere ti fai guidare solo dagli 
errori.
Una funzione non è più richiamabile xchè ha cambiato nome?
Dovi devi guardare per controllare?

> 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:)

E ad un test iniziale in genere seguono altre decine di interventi di 
assestamento :D

[toc] | [prev] | [next] | [standalone]

#20920

On 06/06/2016 14:12, alex wrote:

> Se devi fare un refactoring ad es. in genere ti fai guidare solo dagli
> errori.
> Una funzione non è più richiamabile xchè ha cambiato nome?
> Dovi devi guardare per controllare?

In git blame :P

Questo è il motivo per cui uso PHPStorm e odio i DIC/ServiceLocators 
classici.

> E ad un test iniziale in genere seguono altre decine di interventi di
> 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.

[toc] | [prev] | [next] | [standalone]

#20921

On Monday, June 6, 2016 at 9:12:25 AM UTC-4, alex wrote:
> Il 05/06/2016 20:00, fmassei@gmail.com ha scritto:
> > 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.
> 
> In fase di creazione pura.
> Se devi fare un refactoring ad es. in genere ti fai guidare solo dagli 
> errori.
> Una funzione non è più richiamabile xchè ha cambiato nome?
> Dovi devi guardare per controllare?
> 

Fammi capire, cambi la firma di una funzione e poi vai a cercare gli errori?
Non mi sembra per nulla una buona strategia.. :)

> > 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:)
> 
> E ad un test iniziale in genere seguono altre decine di interventi di 
> assestamento :D
>

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

Ciao!

[toc] | [prev] | [next] | [standalone]

#20923

Il 07/06/2016 04:21, fmassei@gmail.com ha scritto:
> Fammi capire, cambi la firma di una funzione e poi vai a cercare gli errori?
> Non mi sembra per nulla una buona strategia..:)
>

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

[toc] | [prev] | [next] | [standalone]

#20924

On 08/06/2016 10:59, alex wrote:

> per evitare ciò faccio diventare le vecchie funzioni dei puntamenti alle
> 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.

[toc] | [prev] | [next] | [standalone]

#20925

Il 08/06/2016 12:53, Alessandro Pellizzari ha scritto:
> On 08/06/2016 10:59, alex wrote:
>
>> per evitare ciò faccio diventare le vecchie funzioni dei puntamenti alle
>> 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.
>

Esattamente quello che faccio.
Solo che prima o poi si decide di eliminare (con la dovuta cautela) la 
deprecated-function, e proprio qui bisogna intervenire su tutti i 
riferimenti (io faccio tutto manualmente, lasciandomi guidare dagli errori).

> 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.

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

[toc] | [prev] | [next] | [standalone]

#20926

On 08/06/2016 12:21, alex wrote:

> Solo che prima o poi si decide di eliminare (con la dovuta cautela) la
> deprecated-function, e proprio qui bisogna intervenire su tutti i
> riferimenti (io faccio tutto manualmente, lasciandomi guidare dagli
> errori).

Uno dei motivi per cui uso PHPStorm. :)

Metti un /** @deprecated */ come commento alla vecchia funzione. In 
questo modo l'editor te la evidenzia ogni volta che la usi e ti dà 
warning (o errori, dipende da come lo configuri) quando fai l'analisi 
del progetto.

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

PHPStorm. :)

Bye.

[toc] | [prev] | [next] | [standalone]

#20927

Il 08/06/2016 14:15, Alessandro Pellizzari ha scritto:
> On 08/06/2016 12:21, alex wrote:
>
>> Solo che prima o poi si decide di eliminare (con la dovuta cautela) la
>> deprecated-function, e proprio qui bisogna intervenire su tutti i
>> riferimenti (io faccio tutto manualmente, lasciandomi guidare dagli
>> errori).
>
> Uno dei motivi per cui uso PHPStorm. :)
>
> Metti un /** @deprecated */ come commento alla vecchia funzione. In
> questo modo l'editor te la evidenzia ogni volta che la usi e ti dà
> warning (o errori, dipende da come lo configuri) quando fai l'analisi
> del progetto.
>

Ripeto:
Solo che prima o poi si decide di eliminare (con la dovuta cautela) la
deprecated-function, e proprio qui bisogna intervenire su tutti i
riferimenti (io faccio tutto manualmente, lasciandomi guidare dagli
errori).

Cmq leggi sotto.

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

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

[toc] | [prev] | [next] | [standalone]

#20922

On Mon, 6 Jun 2016 15:12:22 +0200, alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:

>Se devi fare un refactoring ad es. in genere ti fai guidare solo dagli 
>errori.
>Una funzione non è più richiamabile xchè ha cambiato nome?
>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.

Leonardo
-- 

A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

[toc] | [prev] | [next] | [standalone]

#20917

On Sun, 5 Jun 2016 14:56:48 +0200, alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:

>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)!!!

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

Leonardo
-- 

A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

[toc] | [prev] | [next] | [standalone]

#20919

Il 05/06/2016 20:13, Leonardo Serni ha scritto:
> On Sun, 5 Jun 2016 14:56:48 +0200, alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:
>
>> 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)!!!
>
> Qualcosa come un server di Continuous Integration, intendi? :-D

In un certo senso :D

[toc] | [prev] | [next] | [standalone]

#20928

Il 04/06/2016 08:58, alex ha scritto:
> 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?

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | it.comp.www.php

csiph-web