Re: [Jug-Torino] [OT] pure bash bible

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

On Thu, Sep 19, 2019 at 11:59 AM Roberto Franchini ro.franch...@gmail.com
[it-torino-java-jug]  wrote:

>
>
>
>
> On Thu, Sep 19, 2019 at 11:32 AM Federico Fissore feder...@fsfe.org
> [it-torino-java-jug]  wrote:
>
>>
>>
>> Ciao a tutti
>>
>> qualche settimana fa si parlava di bash e di espansione di variabili
>>
>> se siete fan di bash troverete questo link interessante
>>
>> https://github.com/dylanaraps/pure-bash-bible
>>
>
> Grazie, capita a fagiolo.
>
> FRANK
>
>
Grazie, bellissimo!

Re: [Jug-Torino] Remote working: quando, dove, perche' si' e perche' no

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Hai ragione, le interruzioni possono essere un problema; d’altra parte è
meglio essere interrotti da un collega che ha bisogno di un informazione e
sbloccarlo, piuttosto che incoraggiare la gente a fare da soli il più
possibile. Io mi sono rassegnato a pensare che il mio lavoro consiste
principalmente nel farmi interrompere :)

Lavorando in pair programming, però, noto che il danno prodotto da una
interruzione a quello che stiamo facendo è minore, perché il contesto di
quello che stiamo facendo non è solo in una testa ma in due. O anche perché
il treno dei miei pensieri è più breve. Questo per me è un esempio di come
le varie pratiche di xp si supportino l’un l’altra: team room e pair
programming.

Le interruzioni da parte di persone esterne al team sono un altro discorso,
quelle vanno limitate e incanalate in momenti appositi e programmati.

Il giorno mer 12 giu 2019 alle 12:19 Federico Fissore feder...@fsfe.org
[it-torino-java-jug]  ha scritto:

>
>
> Non ho abbastanza esperienza per confrontare l'efficaca di un team da
> remoto con uno co-locato.
>
> Ho però constatato che in un team co-locato le interruzioni sono la
> norma, il che porta a continuo context switching, a un calo
> dell'efficaca e a quella fastidiosa sensazione a fine giornata di non
> sapere su cosa hai lavorato.
> Da remoto invece lavoro per obiettivi, da solo o con un collega. Le
> interruzioni sono asincrone, quindi mantenere la concentrazione è più
> facile. Raramente a fine giornata non ho fatto quello che mi ero
> programmato di fare.
>
> Come detto, avere una parte del team da remoto o "2 gg alla settimana da
> remoto" è la cosa peggiore che si può fare/avere: come hai accennato,
> per lavorare da remoto bisogna imparare a comunicare in modo diverso, e
> avere "alcuni colleghi qui, altri là" ti costringe a un continuo
> saltellare fra queste modalità, creando più problema che altro.
>
> federico
>
> Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug] ha scritto
> il 12/06/19 alle 11:25:
> >
> >
> > Beh tutto vero, ma resta il fatto che per un team, lavorare in presenza
> > nella stessa stanza è parecchio più efficace che in remoto. Più
> > efficace== riesci a fare di più e meglio in meno tempo. Tanto che in XP
> > e Scrum fa parte della definizione del processo lavorare tutti nello
> > stesso spazio fisico.
> >
> > Poi se non si può si adottano contromisure per rendere la comunicazione
> > remota un po’ meno inefficace di quella in presenza. Dove lavoro io
> > abbiamo una parte del team che lavora da remoto, e una parte importante
> > del processo è fare una inception tutti in loco con il cliente per 2-3
> > settimane. Questo ti permette di costruire rapporti personali con le
> > persone, in modo che poi quando sei in remoto ti capisci meglio. Poi
> > facciamo periodi a rotazione in cui un remoto va dal cliente o viceversa
> > (sono appena tornato da una settimana in India)
> >
> > Il nostro contesto è (1) sviluppo custom, siamo una azienda di servizi
> > non di prodotto, e (2) lavoro in team; in tanti posti il lavoro non è
> > veramente in team, ci sono solo individui che fanno la loro parte
> > coordinati da qualcuno. In questo contesto la presenza in team room è
> > cruciale IMO
> >
> > Il giorno gio 23 mag 2019 alle 10:24 Marco Bartolini axles...@gmail.com
> > <mailto:axles...@gmail.com> [it-torino-java-jug]
> >  > <mailto:it-torino-java-jug@yahoogroups.com>> ha scritto:
> >
> > __
> >
> > Io ho la possibilita' di lavorare remoto dal 2016, in Italia e'
> > sempre stata un eccezione, la maggior parte delle aziende per cui ho
> > lavorato grandi/medie/piccole non sono mai state capaci di tracciare
> > obiettivi/partecipazione/risultati in maniera efficiente, quindi
> > l'unica parvenza di controllo era quella di averti in ufficio alla
> > scrivania, che fa molto industria 1800...
> >
> > Qui in Workday c'e' una policy per il lavoro da casa tutta a carico
> > del manager del team, puoi lavorare da casa 100% del tempo o solo
> > quando ti serve, puoi lavorare da altre nazioni a patto che il
> > reparto HR approvi la richiesta, diciamo che quando le dimensioni
> > aumentano, avendo team distribuiti in diverse time zone il concetto
> > di "lavoro da remoto" cambia, perche' praticamente e' sempre da
> > remoto anche quando sei in ufficio e lavorando da casa
> > oggettivamente non cambia nulla a quel punto.
> >
> > La differenza grossa va sulla parte di team bonding secondo me,
> > quando lavori remoto full time e parte del team si vede tutti i
> > giorni in ufficio, diventi un membro astratto del team e ti perdi
> >

Re: [Jug-Torino] Remote working: quando, dove, perche' si' e perche' no

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Beh tutto vero, ma resta il fatto che per un team, lavorare in presenza
nella stessa stanza è parecchio più efficace che in remoto. Più efficace==
riesci a fare di più e meglio in meno tempo. Tanto che in XP e Scrum fa
parte della definizione del processo lavorare tutti nello stesso spazio
fisico.

Poi se non si può si adottano contromisure per rendere la comunicazione
remota un po’ meno inefficace di quella in presenza. Dove lavoro io abbiamo
una parte del team che lavora da remoto, e una parte importante del
processo è fare una inception tutti in loco con il cliente per 2-3
settimane. Questo ti permette di costruire rapporti personali con le
persone, in modo che poi quando sei in remoto ti capisci meglio. Poi
facciamo periodi a rotazione in cui un remoto va dal cliente o viceversa
(sono appena tornato da una settimana in India)

Il nostro contesto è (1) sviluppo custom, siamo una azienda di servizi non
di prodotto, e (2) lavoro in team; in tanti posti il lavoro non è veramente
in team, ci sono solo individui che fanno la loro parte coordinati da
qualcuno. In questo contesto la presenza in team room è cruciale IMO

Il giorno gio 23 mag 2019 alle 10:24 Marco Bartolini axles...@gmail.com
[it-torino-java-jug]  ha scritto:

>
>
> Io ho la possibilita' di lavorare remoto dal 2016, in Italia e' sempre
> stata un eccezione, la maggior parte delle aziende per cui ho lavorato
> grandi/medie/piccole non sono mai state capaci di tracciare
> obiettivi/partecipazione/risultati in maniera efficiente, quindi l'unica
> parvenza di controllo era quella di averti in ufficio alla scrivania, che
> fa molto industria 1800...
>
> Qui in Workday c'e' una policy per il lavoro da casa tutta a carico del
> manager del team, puoi lavorare da casa 100% del tempo o solo quando ti
> serve, puoi lavorare da altre nazioni a patto che il reparto HR approvi la
> richiesta, diciamo che quando le dimensioni aumentano, avendo team
> distribuiti in diverse time zone il concetto di "lavoro da remoto" cambia,
> perche' praticamente e' sempre da remoto anche quando sei in ufficio e
> lavorando da casa oggettivamente non cambia nulla a quel punto.
>
> La differenza grossa va sulla parte di team bonding secondo me, quando
> lavori remoto full time e parte del team si vede tutti i giorni in ufficio,
> diventi un membro astratto del team e ti perdi tutte le conversazioni che
> non avvengono in chat/video, questo a lungo andare si riflette su
> produttivita' e incisivita' nelle scelte a mio parere.
>
>
> On Thu, 23 May 2019 at 07:59, Daniela Ruggeri ruggerid...@yahoo.it
> [it-torino-java-jug]  wrote:
>
>>
>>
>> Riguardo allo strumento di collaborazione, ho un amico che ha sviluppato
>> un prodotto per la condivisione della conoscenza e affiancamento
>> professionale per i dipendenti di un'azienda.
>> Ha dei clienti delle risorse umane molte interessati al prodotto.
>> Potreste darmi un feedback, c'è la possibilità di provarlo
>>
>> http://www.itcoach.it/
>>
>> Ciao :-)
>> Daniela
>>
>> Key GPG ID: AA2DA887 --
>> Il miglior modo per predire il futuro è inventarlo
>> Alan Key 
>>
>>
>> Il giovedì 23 maggio 2019, 00:07:06 CEST, Carlo Bottiglieri
>> carlo.bottigli...@gmail.com [it-torino-java-jug] <
>> it-torino-java-jug@yahoogroups.com> ha scritto:
>>
>>
>>
>>
>> Eccomi, scusate il ritardo, pensavo di riuscire a rispondere dal treno
>> ieri, ma avevo fatto over-commitment.
>>
>> La mia opinione sul lavoro remoto in generale è la seguente:
>> Una società attrezzata e abituata, con le persone e le pratiche giuste,
>> puo' permettersi persone remote anche al 100% e lavorare benissimo.
>>
>> Anche cosi' pero' la creatività e l'efficacia di team sono leggermente
>> sub-ottimali : ad esempio, è stata menzionata la tendenza del remotista a
>> prima esaurire le piste da solo e in fine chiedere; è verissimo e io
>> personalmente lo adoro perché mi piace imparare da solo, ma ho dovuto
>> riconoscere che non é sempre l'approccio piu' produttivo, se hai di fronte
>> persone brave che sanno spiegare.
>> Io trovo che un team dove chiunque chiede e offre aiuto costantemente,
>> con creazione di binomi al volo per risolvere un problema, sia molto
>> produttivo, ma soprattutto tende a una buona distribuzione del rispetto
>> reciproco con poco sforzo; questo aiuta ad aumentare la fiducia e permette
>> discussioni costruttive, una rarità.
>>
>> Inoltre non ho ancora trovato uno strumento di collaborazione remota pari
>> a due persone e una lavagna (e includo anche un paio di surface-hub da
>> 50'', che dovrebbero esserne il perfetto equivalente).
>>
>> Quindi la mia preferenza è creare un ambiente di lavoro bello e comodo,
>> con tantissimi whiteboards, di facile accesso, con ottimi ingegneri che non
>> vivano troppo lontano.
>> A team stabile, con la giusta infrastruttura e abitudini, non ho nulla
>> contro pescare un eccellente sviluppatore che vive lontano e averlo da
>> remoto se non riesco a convincerlo a trasferirsi.
>>
>> Ho 

Re: [Jug-Torino] Tuples in Java 8 streams

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Ah ho capito.

Le classi anonime sono inner class, e quindi hanno un riferimento
> alla classe padre, piaccia o no


Non e'  il riferimento alla classe padre che puo' causare un leak, e' che
*l'istanza* della classe anonima contiene un riferimento all'*istanza* della
classe che la contiene.  Quindi se tu conservi un riferimento all'istanza
della classe anonima, stai tenendo in vita anche l'oggetto che l'ha
generata.

Non e' ovvio!  Grazie per avermelo ricordato.


On Sat, Dec 1, 2018 at 7:30 PM Matteo Vaccari 
wrote:

> Spiegatemi questa cosa perché temo di non averla capita: se io creo una
> classe anonima con new Object() {  }, la classe viene creata una volta
> per tutte, indipendentemente dal numero di volte che il frammento di codice
> viene eseguito?  Oppure viene creata una classe nuova ogni volta che lo
> esegui?
>
> Per come avevo capito io le classi anonime direi la prima.  Anzi ero
> sicurissimo della prima.  Ma se e' cosi', non capisco dove sia il memory
> leak.
>
> On Sat, Dec 1, 2018 at 1:48 PM Federico Fissore feder...@fsfe.org
> [it-torino-java-jug]  wrote:
>
>>
>>
>> Uberto Barbini uberto.g...@gmail.com [it-torino-java-jug] ha scritto il
>> > In tutti i casi pero', anche se volessi restituire una collezione di
>> > Object non c'e' memory leak comunque, non sono inner class ma classi
>> > anonime senza alcun rapporto con la classe principale.
>> > C'e' una inner class creata implicitamente dalla lambda, ma quella
>> > finisce col ciclo.
>>
>> Le classi anonime sono inner class, e quindi hanno un riferimento alla
>> classe padre, piaccia o no
>> Quello che descrivi invece è una static inner class, che però non può
>> essere anonima
>>
>> Visto che la tupla dell'esempio di Simone non è utile a tornare dati,
>> cambio l'esempio usando una mappa e la sintassi delle doppie parentesi
>> graffe
>>
>> https://gist.github.com/ffissore/e4915691cc539b0954faf815609cdceb
>>
>> "...new HashMap() {..." è una inner class, anonima, e può accedere alla
>> classe genitore con la sintassi "Filter3.this."
>> Nel metodo "inspectInOtherMethod", l'instanza di Filter3 non è
>> raggiungibile, eppure la mappa restituita è in grado di accedere ai suoi
>> metodi.
>>
>> Se serve altra letteratura a proposito, Lukas Eder in questo post lo
>> spiega bene [1]. Si focalizza sulle doppie parentesi graffe, ma solo
>> perchè sono la sintassi più compatta per ottenere qualcosa di simile a
>> una Tupla in java. La sorgente del problema memory leak è l'aver tornato
>> un'istanza di una inner class
>>
>> [1]
>>
>> https://blog.jooq.org/2014/12/08/dont-be-clever-the-double-curly-braces-anti-pattern/
>>
>> NB: se nelle vostre codebase usate la sintassi delle doppie graffe,
>> buttatele e migrate o a "ImmutableMap.of" di Guava, o fatevi il vostro
>> metodo di utilità
>>
>> federico
>> 
>>
>

Re: [Jug-Torino] Tuples in Java 8 streams

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Spiegatemi questa cosa perché temo di non averla capita: se io creo una
classe anonima con new Object() {  }, la classe viene creata una volta
per tutte, indipendentemente dal numero di volte che il frammento di codice
viene eseguito?  Oppure viene creata una classe nuova ogni volta che lo
esegui?

Per come avevo capito io le classi anonime direi la prima.  Anzi ero
sicurissimo della prima.  Ma se e' cosi', non capisco dove sia il memory
leak.

On Sat, Dec 1, 2018 at 1:48 PM Federico Fissore feder...@fsfe.org
[it-torino-java-jug]  wrote:

>
>
> Uberto Barbini uberto.g...@gmail.com [it-torino-java-jug] ha scritto il
> > In tutti i casi pero', anche se volessi restituire una collezione di
> > Object non c'e' memory leak comunque, non sono inner class ma classi
> > anonime senza alcun rapporto con la classe principale.
> > C'e' una inner class creata implicitamente dalla lambda, ma quella
> > finisce col ciclo.
>
> Le classi anonime sono inner class, e quindi hanno un riferimento alla
> classe padre, piaccia o no
> Quello che descrivi invece è una static inner class, che però non può
> essere anonima
>
> Visto che la tupla dell'esempio di Simone non è utile a tornare dati,
> cambio l'esempio usando una mappa e la sintassi delle doppie parentesi
> graffe
>
> https://gist.github.com/ffissore/e4915691cc539b0954faf815609cdceb
>
> "...new HashMap() {..." è una inner class, anonima, e può accedere alla
> classe genitore con la sintassi "Filter3.this."
> Nel metodo "inspectInOtherMethod", l'instanza di Filter3 non è
> raggiungibile, eppure la mappa restituita è in grado di accedere ai suoi
> metodi.
>
> Se serve altra letteratura a proposito, Lukas Eder in questo post lo
> spiega bene [1]. Si focalizza sulle doppie parentesi graffe, ma solo
> perchè sono la sintassi più compatta per ottenere qualcosa di simile a
> una Tupla in java. La sorgente del problema memory leak è l'aver tornato
> un'istanza di una inner class
>
> [1]
>
> https://blog.jooq.org/2014/12/08/dont-be-clever-the-double-curly-braces-anti-pattern/
>
> NB: se nelle vostre codebase usate la sintassi delle doppie graffe,
> buttatele e migrate o a "ImmutableMap.of" di Guava, o fatevi il vostro
> metodo di utilità
>
> federico
> 
>

Re: [Jug-Torino] Spring boot

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Capito :-)


>
> intendevo comunque che non abbiamo log.debug "sto per fare questo" /
> "finito di fare questo" sparsi per il codice.
>

Sono d'accordo, l'unica eccezione e' che se sto per chiamare un altro
servizio, faccio "sto per chiamare X con messaggio Y / X mi ha risposto con
il messaggio Y


>
> Uberto
>
>
> Uberto
>
>
> On Fri, 9 Nov 2018, 11:27 Matteo Vaccari matteo.vacc...@gmail.com
> [it-torino-java-jug] 
>>
>>
>> Come minimo pero' ce l'avrai un access log?  Capisco che loggare tutti i
>> dati in ingresso e in uscita è discutibile, ma almeno sapere se ti abbiamo
>> dato un 200 o un 400... :)
>>
>> Il giorno ven 9 nov 2018 alle ore 11:52 Uberto Barbini
>> uberto.g...@gmail.com [it-torino-java-jug] <
>> it-torino-java-jug@yahoogroups.com> ha scritto:
>>
>>>
>>>
>>> Il nostro approccio e' diverso dal tuo in questo: i servizi in genere
>>> non loggano le cose che vanno bene, a meno che non siano significativi per
>>> il business. Tanto meno loggano tutti i dati in ingresso e uscita.
>>>
>>> Tanto per fare un esempio, non logghiamo:
>>> - utente Tizio si e' autenticato
>>> - Tizio ha chiesto la pagina SubmitPaper
>>> - Tizio ha riempito i campi di SubmitPaper
>>> - salvato su db i dati di SubmitPaper
>>> - risposto a Tizio "tutto bene".
>>>
>>> Logghiamo solo "Tizio ha salvato il suo paper xy"
>>>
>>> Se pero' succede qualche cosa di inaspettato (exception) o previsto ma
>>> sbagliato (network failure, etc.) logghiamo tutti i dati utili possibili
>>> per capire cosa e' successo.
>>>
>>> make sense?
>>>
>>> Uberto
>>>
>>>
>>> On Fri, 9 Nov 2018 at 08:28, Matteo Vaccari matteo.vacc...@gmail.com
>>> [it-torino-java-jug] >> > wrote:
>>>
>>>>
>>>>
>>>> Io per il logging ho una regoletta molto semplice che dice:
>>>>
>>>>1. logga tutto quello che il tuo servizio riceve come input, e
>>>>quello che rispondiamo
>>>>2. quando vai a interrogare un servizio esterno, logga quello che
>>>>gli abbiamo mandato e quello che ci ha risposto
>>>>3. logga tutte le eccezioni inaspettate, ma solo al livello piu'
>>>>esterno del call stack
>>>>4. non loggare nient'altro
>>>>
>>>> Magari ci possono essere occasionali eccezioni alla regola 4, e le
>>>> regole 1 e 2 devono evitare di loggare dati sensibili, ma con questo
>>>> sistema sei in grado di fare sia analisi dei guasti, sia di osservare che
>>>> cosa fa il tuo sistema in generale.
>>>>
>>>> Domanda per Uberto: ma se tu passi il monitor che riceve gli eventi giu
>>>> giu giu fino agli oggetti di dominio, non ti da fastidio aggiungere un
>>>> parametro extra a tutti i costruttori?  Od ho sbagliato io a capire?
>>>>
>>>> Il giorno ven 9 nov 2018 alle ore 08:50 Simone Bordet
>>>> simone.bor...@gmail.com [it-torino-java-jug] <
>>>> it-torino-java-jug@yahoogroups.com> ha scritto:
>>>>
>>>>>
>>>>>
>>>>> Ciao,
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 8, 2018 at 11:53 PM Uberto Barbini uberto.g...@gmail.com
>>>>> [it-torino-java-jug]  wrote:
>>>>> > in questo modo i log entrano a far parte del dominio, specifiche e
>>>>> tutto il resto. Inoltre non c'e' piu' il concetto di debug/info/warn/trace
>>>>> ecc. o un evento e' significativo e lo notifichi oppure no.
>>>>>
>>>>> Ma secondo me il problema è definire "significativo".
>>>>> Quello che è importante per qualcuno non lo è per qualcun altro.
>>>>>
>>>>> Io sono sempre stato un fan del tagged logging: niente livelli
>>>>> (debug/info/warn) ma solo tags.
>>>>> A quel punto come dici tu il logging diventa una feature e cosa devi
>>>>> loggare dal punto di vista del business lo chiedi al cliente, mentre
>>>>> lo sviluppatore fa il logging degli internals dell'implementazione.
>>>>>
>>>>> Da Java 9 si è arrivati a questo per il logging interno della JVM, ma
>>>>> niente da fare ancora per il logging applicativo e i vari SLF4J,
>>>>> Log4J2 e LogBack che sono ancorati al modello di 20-30 anni fa.
>>>>>
>>>>>
>>>>>
>>>>> > Kirk Pepperdine mi ha fatto notare una volta come uno dovrebbe
>>>>> loggare il meno possibile quando va tutto bene e il piu' possible quando
>>>>> succede qualche cosa di sbagliato.
>>>>>
>>>>> Anche qui definire "sbagliato" è difficile.
>>>>>
>>>>> --
>>>>> Simone Bordet
>>>>> ---
>>>>> Finally, no matter how good the architecture and design are,
>>>>> to deliver bug-free software with optimal performance and reliability,
>>>>> the implementation technique must be flawless. Victoria Livschitz
>>>>>
>>>> 
>

Re: [Jug-Torino] Spring boot

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Come minimo pero' ce l'avrai un access log?  Capisco che loggare tutti i
dati in ingresso e in uscita è discutibile, ma almeno sapere se ti abbiamo
dato un 200 o un 400... :)

Il giorno ven 9 nov 2018 alle ore 11:52 Uberto Barbini uberto.g...@gmail.com
[it-torino-java-jug]  ha scritto:

>
>
> Il nostro approccio e' diverso dal tuo in questo: i servizi in genere non
> loggano le cose che vanno bene, a meno che non siano significativi per il
> business. Tanto meno loggano tutti i dati in ingresso e uscita.
>
> Tanto per fare un esempio, non logghiamo:
> - utente Tizio si e' autenticato
> - Tizio ha chiesto la pagina SubmitPaper
> - Tizio ha riempito i campi di SubmitPaper
> - salvato su db i dati di SubmitPaper
> - risposto a Tizio "tutto bene".
>
> Logghiamo solo "Tizio ha salvato il suo paper xy"
>
> Se pero' succede qualche cosa di inaspettato (exception) o previsto ma
> sbagliato (network failure, etc.) logghiamo tutti i dati utili possibili
> per capire cosa e' successo.
>
> make sense?
>
> Uberto
>
>
> On Fri, 9 Nov 2018 at 08:28, Matteo Vaccari matteo.vacc...@gmail.com
> [it-torino-java-jug]  > wrote:
>
>>
>>
>> Io per il logging ho una regoletta molto semplice che dice:
>>
>>1. logga tutto quello che il tuo servizio riceve come input, e quello
>>che rispondiamo
>>2. quando vai a interrogare un servizio esterno, logga quello che gli
>>abbiamo mandato e quello che ci ha risposto
>>3. logga tutte le eccezioni inaspettate, ma solo al livello piu'
>>esterno del call stack
>>4. non loggare nient'altro
>>
>> Magari ci possono essere occasionali eccezioni alla regola 4, e le regole
>> 1 e 2 devono evitare di loggare dati sensibili, ma con questo sistema sei
>> in grado di fare sia analisi dei guasti, sia di osservare che cosa fa il
>> tuo sistema in generale.
>>
>> Domanda per Uberto: ma se tu passi il monitor che riceve gli eventi giu
>> giu giu fino agli oggetti di dominio, non ti da fastidio aggiungere un
>> parametro extra a tutti i costruttori?  Od ho sbagliato io a capire?
>>
>> Il giorno ven 9 nov 2018 alle ore 08:50 Simone Bordet
>> simone.bor...@gmail.com [it-torino-java-jug] <
>> it-torino-java-jug@yahoogroups.com> ha scritto:
>>
>>>
>>>
>>> Ciao,
>>>
>>>
>>>
>>> On Thu, Nov 8, 2018 at 11:53 PM Uberto Barbini uberto.g...@gmail.com
>>> [it-torino-java-jug]  wrote:
>>> > in questo modo i log entrano a far parte del dominio, specifiche e
>>> tutto il resto. Inoltre non c'e' piu' il concetto di debug/info/warn/trace
>>> ecc. o un evento e' significativo e lo notifichi oppure no.
>>>
>>> Ma secondo me il problema è definire "significativo".
>>> Quello che è importante per qualcuno non lo è per qualcun altro.
>>>
>>> Io sono sempre stato un fan del tagged logging: niente livelli
>>> (debug/info/warn) ma solo tags.
>>> A quel punto come dici tu il logging diventa una feature e cosa devi
>>> loggare dal punto di vista del business lo chiedi al cliente, mentre
>>> lo sviluppatore fa il logging degli internals dell'implementazione.
>>>
>>> Da Java 9 si è arrivati a questo per il logging interno della JVM, ma
>>> niente da fare ancora per il logging applicativo e i vari SLF4J,
>>> Log4J2 e LogBack che sono ancorati al modello di 20-30 anni fa.
>>>
>>>
>>>
>>> > Kirk Pepperdine mi ha fatto notare una volta come uno dovrebbe loggare
>>> il meno possibile quando va tutto bene e il piu' possible quando succede
>>> qualche cosa di sbagliato.
>>>
>>> Anche qui definire "sbagliato" è difficile.
>>>
>>> --
>>> Simone Bordet
>>> ---
>>> Finally, no matter how good the architecture and design are,
>>> to deliver bug-free software with optimal performance and reliability,
>>> the implementation technique must be flawless. Victoria Livschitz
>>>
>> 
>

Re: [Jug-Torino] Spring boot

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Io per il logging ho una regoletta molto semplice che dice:

   1. logga tutto quello che il tuo servizio riceve come input, e quello
   che rispondiamo
   2. quando vai a interrogare un servizio esterno, logga quello che gli
   abbiamo mandato e quello che ci ha risposto
   3. logga tutte le eccezioni inaspettate, ma solo al livello piu' esterno
   del call stack
   4. non loggare nient'altro

Magari ci possono essere occasionali eccezioni alla regola 4, e le regole 1
e 2 devono evitare di loggare dati sensibili, ma con questo sistema sei in
grado di fare sia analisi dei guasti, sia di osservare che cosa fa il tuo
sistema in generale.

Domanda per Uberto: ma se tu passi il monitor che riceve gli eventi giu giu
giu fino agli oggetti di dominio, non ti da fastidio aggiungere un
parametro extra a tutti i costruttori?  Od ho sbagliato io a capire?

Il giorno ven 9 nov 2018 alle ore 08:50 Simone Bordet
simone.bor...@gmail.com [it-torino-java-jug] <
it-torino-java-jug@yahoogroups.com> ha scritto:

>
>
> Ciao,
>
>
>
> On Thu, Nov 8, 2018 at 11:53 PM Uberto Barbini uberto.g...@gmail.com
> [it-torino-java-jug]  wrote:
> > in questo modo i log entrano a far parte del dominio, specifiche e tutto
> il resto. Inoltre non c'e' piu' il concetto di debug/info/warn/trace ecc. o
> un evento e' significativo e lo notifichi oppure no.
>
> Ma secondo me il problema è definire "significativo".
> Quello che è importante per qualcuno non lo è per qualcun altro..
>
> Io sono sempre stato un fan del tagged logging: niente livelli
> (debug/info/warn) ma solo tags.
> A quel punto come dici tu il logging diventa una feature e cosa devi
> loggare dal punto di vista del business lo chiedi al cliente, mentre
> lo sviluppatore fa il logging degli internals dell'implementazione.
>
> Da Java 9 si è arrivati a questo per il logging interno della JVM, ma
> niente da fare ancora per il logging applicativo e i vari SLF4J,
> Log4J2 e LogBack che sono ancorati al modello di 20-30 anni fa.
>
>
>
> > Kirk Pepperdine mi ha fatto notare una volta come uno dovrebbe loggare
> il meno possibile quando va tutto bene e il piu' possible quando succede
> qualche cosa di sbagliato.
>
> Anche qui definire "sbagliato" è difficile.
>
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless. Victoria Livschitz
> 
>

Re: [Jug-Torino] Fwd: [JavaSpecialists] 15000 Push-Up Challenge

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Occhio che fare le flessioni non e' salutare per tutti!  Soprattutto per
quelli di noi particolarmente sedentari, o che hanno la pressione alta.
Conviene fare prima l'esame che ti da' il certificato per praticare
attivita' sportiva, che comprende un ECG.

Non l'ho letto, ma credo che questo libro
https://pragprog.com/book/jkthp/the-healthy-programmer contenga dei buoni
consigli, fra cui quello di camminare di piu' (la camminata e' meno
"violenta" per il fisico ed e' consigliata per una maggioranza piu' ampia
di persone)



Il giorno lun 1 ott 2018 alle ore 09:44 Andrea Ligios andrealig...@gmail.com
[it-torino-java-jug]  ha scritto:

>
>
> Ce n'era anche una in JHipster mi pare :)
>
> Intendo che devo ricordarmi di contarle proprio, prima di segnarle (lì
> andiamo a tempo, es. 10 serie da un minuto l'una, ora invece dovrò tenere
> le reps)
>
> Ciao
>
>
> Il giorno lun 1 ott 2018 alle ore 09:40 Roberto Franchini
> ro.franch...@gmail.com [it-torino-java-jug] <
> it-torino-java-jug@yahoogroups.com> ha scritto:
>
>>
>>
>>
>>
>> On Mon, Oct 1, 2018 at 9:33 AM Andrea Ligios andrealig...@gmail.com
>> [it-torino-java-jug]  wrote:
>>
>>>
>>>
>>> Fantastico! Ci sto :)
>>>
>>> P.S: tre anni fa mi salvò questo dalla sedentarietà:
>>> https://www.youtube.com/watch?v=oswPhLNL8SA
>>> Dovrò solo ricordarmi di contare le flessioni fatte lì per integrarle
>>> nella 15000 Push-Ups challenge...
>>>
>>>
>>  Un foglio di calcolo, oppure ci sono un sacco di app per farlo.
>> FRANK
>> Io
>>
>>
>> --
>> Roberto Franchini
>> "The impossible is inevitable"
>> https://github.com/robfrank/
>> https://twitter.com/robfrankie 
>> https://www.linkedin.com/in/robfrank
>>
> 
>

Re: [Jug-Torino] REST API asincrone, CompletableFuture e Callable

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

>
>
> Quindi qual è il modo migliore per far fare alla CPU altro lavoro mentre
> è in attesa del risultato di una query?
> Oppure ha ragione il mio collega e potevo risparmiarmi del lavoro?
>

Non devi fare nulla; il sistema operativo garantisce che mentre il tuo
thread è bloccato in attesa di I/O, qualsiasi altro thread pronto ad
eseguire potrà usare la CPU.  Se stai sviluppando un servizio REST, il
thread bloccato lascia la CPU disponibile per qualsiasi altra richiesta
concorrente.

Tutto dipende da che cos'è che stai cercando di ottenere esattamente.  Se
l'obiettivo è fare in modo che il tuo chiamante riceva 200 prima che sia
completata la chiamata al DB o a qualsiasi sia l'operazione "lenta" che
devi eseguire, allora devi eseguire l'operazione lenta su un secondo
thread; ma poi devi fornire un secondo endpoint per consentire al chiamante
di sapere se l'operazione è completata.  Questa cosa può avere senso per
operazioni molto lunghe (tipo elaborazioni grafiche)

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

Eh sarebbe bello se il TDD rendesse impopolari i singleton :)  In realtà
si', li rende impopolari ma solo per i pochissimi che fanno veramente TDD!

2018-01-15 22:58 GMT+01:00 Massimo Ugues m.ug...@gmail.com
[it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:

>
>
> *L'uso dei builder per costruire oggetti nei test è stato reso popolare
> dal GOOS <http://www.growing-object-oriented-software.com/>*
>
> Sinceramente non riesco a vedere una differenza sostanziale tra un builder
> e una fluent interface dei setter del POJO in oggetto.
> Come PRO la fluent interface ti evita di avere una classe che fa appunto
> da builder, e come spesso LESS IS MORE.
>
> Il fatto che tu sostenga che i builder siano stati resi popolari dal TDD
> mi sembra a dir poco opinabile (https://tinyurl.com/y9qxgzhh).
> E' un po' come dire che il Singleton sia stato reso impopolare dallo
> stesso movimento......
>
>
>
> 2018-01-15 21:30 GMT+01:00 Matteo Vaccari matteo.vacc...@gmail.com
> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>
>>
>>
>>
>> L'uso dei builder per costruire oggetti nei test è stato reso popolare
>> dal GOOS <http://www..growing-object-oriented-software.com/>
>>
>> 2018-01-12 18:35 GMT+01:00 Federico Fissore feder...@fsfe.org
>> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>>
>>>
>>>
>>> Ciao
>>>
>>> domandina del venerdì sera
>>>
>>> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>>>
>>> return ExpenseBuilder.anExpense()
>>> .withId(id)
>>> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
>>> .withDate(new Date())
>>> .withReason("Something pretty")
>>> .build();
>>>
>>> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
>>> presi da un altro bean via getter, oppure quest altro bean offre lui un
>>> metodo che restituisce un builder pre-popolato
>>>
>>> Anche voi siete abituati a fare così quando dovete passare dati da una
>>> DTO a un altro? Se no, come fate?
>>>
>>> ciao
>>>
>>> federico
>>>
>>
>>
>
>
> --
> Massimo Ugues
>
> 
>

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

L'uso dei builder per costruire oggetti nei test è stato reso popolare dal
GOOS 

2018-01-12 18:35 GMT+01:00 Federico Fissore feder...@fsfe.org
[it-torino-java-jug] :

>
>
> Ciao
>
> domandina del venerdì sera
>
> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>
> return ExpenseBuilder.anExpense()
> .withId(id)
> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
> .withDate(new Date())
> .withReason("Something pretty")
> .build();
>
> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
> presi da un altro bean via getter, oppure quest altro bean offre lui un
> metodo che restituisce un builder pre-popolato
>
> Anche voi siete abituati a fare così quando dovete passare dati da una
> DTO a un altro? Se no, come fate?
>
> ciao
>
> federico
> 
>