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

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

eseguire applicazione in modalità verbose

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

Contents

  eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-22 10:25 +0100
    Re: eseguire applicazione in modalità verbose Alessandro Pellizzari <shuriken@amiran.it> - 2017-01-22 09:55 +0000
      Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-22 11:22 +0100
        Re: eseguire applicazione in modalità verbose Alessandro Pellizzari <shuriken@amiran.it> - 2017-01-22 15:38 +0000
          Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-22 17:35 +0100
            Re: eseguire applicazione in modalità verbose "ciccio" <21669invalid@mynewsgate.net> - 2017-01-23 11:14 +0000
              Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-23 21:10 +0100
            Re: eseguire applicazione in modalità verbose Alessandro Pellizzari <shuriken@amiran.it> - 2017-01-24 21:07 +0000
              Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-25 13:57 +0100
                Re: eseguire applicazione in modalità verbose Alessandro Pellizzari <shuriken@amiran.it> - 2017-01-25 14:00 +0000
                  Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-25 16:08 +0100
                    Re: eseguire applicazione in modalità verbose Alessandro Pellizzari <shuriken@amiran.it> - 2017-01-25 20:41 +0000
                      Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-25 22:10 +0100
                        Re: eseguire applicazione in modalità verbose Leonardo Serni <lserni@gmail.com> - 2017-01-25 23:28 +0100
                          Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-26 09:49 +0100
                            Re: eseguire applicazione in modalità verbose Leonardo Serni <lserni@gmail.com> - 2017-01-26 23:36 +0100
                              Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-27 13:31 +0100
                          Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-27 13:34 +0100
                            Re: eseguire applicazione in modalità verbose bramante <bramante@yopmail.com> - 2017-01-27 14:26 +0100
                              Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-27 16:24 +0100
                          Re: eseguire applicazione in modalità verbose alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-27 16:26 +0100
                      Re: "ciccio" <21669invalid@mynewsgate.net> - 2017-01-26 09:33 +0000
                        Re: Re: alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-01-26 12:00 +0100

Page 1 of 2  [1] 2  Next page →

#21392 — eseguire applicazione in modalità verbose

Se si tratta di una cli-app

if ($verbose_mode) {// se l'app deve parlare
     // visualizzazione messaggi informativi
     fwrite(STDOUT, 'Caricamento configurazione...');
     fwrite(STDOUT, 'Lettura database...');
     //...
}

Se invece si tratta di una web-app, al posto di fwrite() si potrebbe 
usare qualcosa tipo

echo '<script>console.log("Caricamento configurazione...")</script>';

anche se, secondo me, la *browser-console* andrebbe usata solo per 
visualizzare dati/messaggi di debug, e non dati/messaggi informativi.

Cosa ne pensate? Qual'è la soluzione più adatta?

[toc] | [next] | [standalone]

#21393

Il Sun, 22 Jan 2017 10:25:28 +0100, alex ha scritto:

> Se si tratta di una cli-app
> 
> if ($verbose_mode) {// se l'app deve parlare
> ...
> Se invece si tratta di una web-app, al posto di fwrite() si potrebbe
> usare qualcosa tipo
> 
> echo '<script>console.log("Caricamento configurazione...")</script>';

> Cosa ne pensate? Qual'è la soluzione più adatta?

Monolog.

Bye.

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

#21394

Il 22/01/2017 10:55, Alessandro Pellizzari ha scritto:
> Monolog.

quindi bisogna per forza usare un file tipo *logs/verbose.log*?

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

#21395

Il Sun, 22 Jan 2017 11:22:11 +0100, alex ha scritto:

> Il 22/01/2017 10:55, Alessandro Pellizzari ha scritto:
>> Monolog.
> 
> quindi bisogna per forza usare un file tipo *logs/verbose.log*?

No. Monolog è stra-configurabile.

Puoi configurarlo per non stampare le date e scrivere in console da CLI, 
e per scrivere su file o su Firebug da web. Il tutto filtrato per livelli 
di log.

Bye.

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

#21396

Il 22/01/2017 16:38, Alessandro Pellizzari ha scritto:
> Puoi configurarlo per non stampare le date e scrivere in console da CLI,
> e per scrivere su file o su Firebug da web. Il tutto filtrato per livelli
> di log.

ok, ma non mi è mai piaciuto dipendere troppo da software esterni 
(firebug, xdebug....)

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

#21397

alex <1j9448a02@lnx159sneakemail.com.invalid> ha scritto:

> Il 22/01/2017 16:38, Alessandro Pellizzari ha scritto:
> > Puoi configurarlo per non stampare le date e scrivere in console da CLI,
> > e per scrivere su file o su Firebug da web. Il tutto filtrato per livelli
> > di log.
> 
> ok, ma non mi è mai piaciuto dipendere troppo da software esterni 
> (firebug, xdebug....)

firebug serve per fare il debug lato client.

xdebug serve per fare il debug lato server.

Non c'entra niente il dipendere, c'entra che senza questi software
non puoi fare proprio il debug (se non con le preistoriche stampe
di controllo immerse nel codice).

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

#21399

Il 23/01/2017 12:14, ciccio ha scritto:
> firebug serve per fare il debug lato client.
>
> xdebug serve per fare il debug lato server.
>
> Non c'entra niente il dipendere, c'entra che senza questi software
> non puoi fare proprio il debug (se non con le preistoriche stampe
> di controllo immerse nel codice).
>
>

Quindi
vebose-mode = debug-mode

...per me non è proprio la stessa cosa

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

#21405

Il Sun, 22 Jan 2017 17:35:59 +0100, alex ha scritto:

> Il 22/01/2017 16:38, Alessandro Pellizzari ha scritto:

>> Puoi configurarlo per non stampare le date e scrivere in console da
>> CLI, e per scrivere su file o su Firebug da web. Il tutto filtrato per
>> livelli di log.
> 
> ok, ma non mi è mai piaciuto dipendere troppo da software esterni
> (firebug, xdebug....)

Puoi sempre riscriverti il protocollo simulando firebug o inventando 
qualcosa di nuovo (come cachare tutto e appendere uno

<script>
<?php foreach ($errors as $error): ?>
  console.log('<?php echo $error; ?>');
<?php endforeach ?>
</script>

alla fine della pagina). In alcuni casi va bene (per imparare, per 
implementarlo in modo più efficiente o più customizzabile, ecc.).

In altri casi è una perdita di tempo.

Io ho interpretato la tua domanda come "come mandare output a due cose 
diverse?", mentre forse la tua domanda era in realtà "come mandare output 
solo se attivo il verbose mode?".

Monolog risolve entrambe, perché ti permette di configurare il formato di 
output, il dispositivo di output, e anche il loglevel da mandare, quindi 
puoi avere

$monolog->pushHandler(
  new StreamHandler(
    '/tmp/log.log',
    $verbose ? 'warning' : 'debug'
  )
);

e non devi riempire il tuo codice di if($verbose) printf(...); ma usi 
direttamente $monolog->debug(...) o $monolog->warning(...)

Bye.

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

#21409

Il 24/01/2017 22:07, Alessandro Pellizzari ha scritto:
> Il Sun, 22 Jan 2017 17:35:59 +0100, alex ha scritto:
>
>> Il 22/01/2017 16:38, Alessandro Pellizzari ha scritto:
>
>>> Puoi configurarlo per non stampare le date e scrivere in console da
>>> CLI, e per scrivere su file o su Firebug da web. Il tutto filtrato per
>>> livelli di log.
>>
>> ok, ma non mi è mai piaciuto dipendere troppo da software esterni
>> (firebug, xdebug....)
>
> Puoi sempre riscriverti il protocollo simulando firebug o inventando
> qualcosa di nuovo (come cachare tutto e appendere uno
>
> <script>
> <?php foreach ($errors as $error): ?>
>   console.log('<?php echo $error; ?>');
> <?php endforeach ?>
> </script>
>
> alla fine della pagina). In alcuni casi va bene (per imparare, per
> implementarlo in modo più efficiente o più customizzabile, ecc.).
> In altri casi è una perdita di tempo.

Cachare in che senso?
Mettere nella cache?
O forse intentevi fare il catch (intercettare gli errori)?
Ma poi cosa c'entrano gli errori... (vedi sotto).

> Io ho interpretato la tua domanda come "come mandare output a due cose
> diverse?", mentre forse la tua domanda era in realtà "come mandare output
> solo se attivo il verbose mode?".

Si.

> Monolog risolve entrambe, perché ti permette di configurare il formato di
> output, il dispositivo di output, e anche il loglevel da mandare, quindi
> puoi avere
>
> $monolog->pushHandler(
>   new StreamHandler(
>     '/tmp/log.log',
>     $verbose ? 'warning' : 'debug'
>   )
> );
>
> e non devi riempire il tuo codice di if($verbose) printf(...); ma usi
> direttamente $monolog->debug(...) o $monolog->warning(...)

Il fatto è che non capisco perchè non distinguete la modalità debug (in 
cui vengono visualizzati errori e dati relativamente inerenti), dalla 
modalità verbose (di cui si può avvalere non solo lo sviluppatore, ma 
anche l'utente comune).

Esempio di utilizzo di rsync in modalità verbose:

$ rsync -a --verbose dir1 dir2

Secondo voi verranno visualizzate informazioni di debug, o comuni 
messaggi informativi: cosa sta facendo il programma, quali file di 
configurazione sono stati caricati (qualora, cioè *nell'ipotetico* caso 
in cui volessi configurare qualcosa so dove mettere le mani), ecc.

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

#21411

On 25/01/2017 12:57, alex wrote:

> Esempio di utilizzo di rsync in modalità verbose:
>
> $ rsync -a --verbose dir1 dir2
>
> Secondo voi verranno visualizzate informazioni di debug, o comuni
> messaggi informativi: cosa sta facendo il programma, quali file di
> configurazione sono stati caricati (qualora, cioè *nell'ipotetico* caso
> in cui volessi configurare qualcosa so dove mettere le mani), ecc.

In Unix/Linux ci sono normalmente diversi livelli di verbose. Alcuni 
comandi accettano -vvv, per esempio, per il "most verbose" e -v per il 
verbose.

Questo si traduce, in Monolog (e in PSR-3) nell'innalzamento del livello 
di log. Questi sono i livelli di PSR3:

- emergency
- alert
- critical
- error
- warning
- notice
- info
- debug

Secondo me ce ne sono troppo pochi nella parte bassa (avrei introdotto 
almeno trace e profiling), ma puoi per esempio usare notice per i 
messaggi normali, info per il --verbose e debug per il -vv (double verbose)

Questo ti permette di non toccare il codice:

$logger->notice("Copying file");
$logger->info("Source: " .$source. ", dest: " .$dest);
$logger->debug("Source size: " .filesize($source));

Niente if, niente commenti, niente compilazione condizionale (se fosse 
possibile), ma tutto configurabile al bootstrap:

$verboseLevel = $argumentParser->count('v'); // metacodice...

switch ($verboseLevel) {
  case 0: $logLevel = 'notice'; break;
  case 1: $logLevel = 'info'; break;
  default: $logLevel = 'debug'; break;
}

$logger->pushHandler(
   new StreamHandler(
     '/tmp/log.log',
     $logLevel
   )
);

Bye.

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

#21413

Il 25/01/2017 15:00, Alessandro Pellizzari ha scritto:
> On 25/01/2017 12:57, alex wrote:
>
>> Esempio di utilizzo di rsync in modalità verbose:
>>
>> $ rsync -a --verbose dir1 dir2
>>
>> Secondo voi verranno visualizzate informazioni di debug, o comuni
>> messaggi informativi: cosa sta facendo il programma, quali file di
>> configurazione sono stati caricati (qualora, cioè *nell'ipotetico* caso
>> in cui volessi configurare qualcosa so dove mettere le mani), ecc.
>
> In Unix/Linux ci sono normalmente diversi livelli di verbose. Alcuni
> comandi accettano -vvv, per esempio, per il "most verbose" e -v per il
> verbose.

Che comunque non forniscono vere proprie info di debug.
Il debug (fatto in modo veramente professionale) è tutt'altra cosa
https://it.wikipedia.org/wiki/Debugging
e spesso necessità di dati altamente dettagliati: molto più dettagliati 
di quelli forniti dai *verbali* a cui può accedere anche la GM (gente 
comune) :)
Dati che la maggior parte della GM, peraltro e probabilmente, non 
saprebbe neanche interpretare in modo adeguato.
Magari bastasse una verbose-mode per scovare un bug :)

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

#21415

Il Wed, 25 Jan 2017 16:08:19 +0100, alex ha scritto:

> Il 25/01/2017 15:00, Alessandro Pellizzari ha scritto:

>> On 25/01/2017 12:57, alex wrote:
>>
>>> Esempio di utilizzo di rsync in modalità verbose:
>>>
>>> $ rsync -a --verbose dir1 dir2
> ...
>> In Unix/Linux ci sono normalmente diversi livelli di verbose. Alcuni
>> comandi accettano -vvv, per esempio, per il "most verbose" e -v per il
>> verbose.

> Che comunque non forniscono vere proprie info di debug.

Mi spieghi come sei passato dal verbose al debugging?

Hai chiesto come implementare il verbose e te l'ho detto. Non hai chiesto 
come fare debug.

Se vuoi fare debugging USA XDEBUG!

Quante volte dobbiamo dirtelo?

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

#21416

Il 25/01/2017 21:41, Alessandro Pellizzari ha scritto:
> Mi spieghi come sei passato dal verbose al debugging?
>

Non sono mai passato al debugging.
In realtà quello che chiedo è un area dove poter inviare i 
web-verbose-message, che sarebbero l'esatto corrispondente dei 
cli-verbose-message.
La conclusione a cui sono giunto è che gli attuali browser hanno solo 
una console (più precisamente una debug-console), e quindi per un 
momento non esistono browser dotati di una verbose-console, su cui 
scrivere ad esempio messaggi di carattere generico.

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

#21417

On Wed, 25 Jan 2017 22:10:52 +0100, alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:

>La conclusione a cui sono giunto è che gli attuali browser hanno solo 
>una console (più precisamente una debug-console), e quindi per un 
>momento non esistono browser dotati di una verbose-console, su cui 
>scrivere ad esempio messaggi di carattere generico.

La console del browser è per il codice *client*, mica per il codice *server*.

Se proprio, puoi mandare il log verbose in appositi header.

Siccome io lo faccio ;-) ti dico subito che per leggerli bene ti conviene usare
un nome come

	$headerName	= sprintf('X-Y%05d', $headerCount++);

perché altrimenti alcuni browser te li riordinano come vogliono.

In effetti, i miei script riconoscono il mio particolare useragent e aggiungono
quegli header solo se lo vedono (non sempre posso usare XDebug :-( ).

Leonardo
-- 

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

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

#21419

Il 25/01/2017 23:28, Leonardo Serni ha scritto:
> Se proprio, puoi mandare il log verbose in appositi header.

Cosa intendi per header?

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

#21424

On Thu, 26 Jan 2017 09:49:53 +0100, alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:

>Il 25/01/2017 23:28, Leonardo Serni ha scritto:
>> Se proprio, puoi mandare il log verbose in appositi header.

>Cosa intendi per header?

Be'... header. Header HTTP. Tipo

	Header('X-Y01345: calling Model\Macchina::fasi()');

Che poi puoi leggere nel browser, avendo l'apposito strumento per sviluppatori.

Leonardo
-- 

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

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

#21426

Il 26/01/2017 23:36, Leonardo Serni ha scritto:
> On Thu, 26 Jan 2017 09:49:53 +0100, alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:
>
>> Il 25/01/2017 23:28, Leonardo Serni ha scritto:
>>> Se proprio, puoi mandare il log verbose in appositi header.
>
>> Cosa intendi per header?
>
> Be'... header. Header HTTP. Tipo
>
> 	Header('X-Y01345: calling Model\Macchina::fasi()');
>
> Che poi puoi leggere nel browser, avendo l'apposito strumento per sviluppatori.
>
> Leonardo
>

Come questo
https://addons.mozilla.org/it/firefox/addon/live-http-headers/

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

#21427

Il 25/01/2017 23:28, Leonardo Serni ha scritto:
> In effetti, i miei script riconoscono il mio particolare useragent e aggiungono
> quegli header solo se lo vedono (non sempre posso usare XDebug :-( ).

Useragent, cioè?

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

#21429

Il 27/01/2017 13:34, alex ha scritto:
> Il 25/01/2017 23:28, Leonardo Serni ha scritto:
>> In effetti, i miei script riconoscono il mio particolare useragent e
>> aggiungono
>> quegli header solo se lo vedono (non sempre posso usare XDebug :-( ).
>
> Useragent, cioè?

ogni browser invia un intestazione di chi è (appunto un Useragent) che 
indica chi è (mozilla, webkit, IE, ecc..) e indica anche il SO


esempio di log Apache dello useragent
127.0.0.1 - - [27/Oct/2016:22:40:33 +0200] "GET / HTTP/1.1" 200 4257 "-" 
"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 
Firefox/49.0"


ora lo Useragent può essere modificato e personalizzato (ci sono plugin 
che agevolano questo)
un client che effettua una richiesta ad un server web, non 
necessariamente è un browser basti pensare a tutto IoT (Internet of Things)

prendendo in considerazione quanto sopra puoi far avere un comportamento 
diverso alla tua applicazione in base appunto al riconoscimento dello 
Useragent, come appunto Serni indicava.

Ciao

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

#21431

Il 27/01/2017 14:26, bramante ha scritto:
>
> prendendo in considerazione quanto sopra puoi far avere un comportamento
> diverso alla tua applicazione in base appunto al riconoscimento dello
> Useragent, come appunto Serni indicava.

Non ci avevo mai pensato, grazie :)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web