Buon anno a tutti.
questa discussione sta diventando sempre piu' interessante.
> Ecco, su questo siamo in pacifico disaccordo. :-D
>
> Per me, se dal suo punto di vista sono diverse, il computer riporta
> banalmente questa differenza.
Allora qui ci siamo chiariti, siamo in disaccordo (che ci sta benissimo). :)
Vedi per me il punto di vista del computer e' diverso da quello
dell'esperto, quindi a volte servono termini nuovi.
> Conosco la differenza fra flussi e stock, ma a dire il vero ricordo che mi
> hanno proprio spiegato che la partita doppia tratta i flussi da cui è
> possibile determinare gli stock ad una qualsiasi data.
> E mi hanno anche detto quella bagianata dei segni... Magari pensavano che in
> quanto informatico, non potessi proprio capire! :-D
:)
wikipedia http://it.wikipedia.org/wiki/Partita_doppia
lo chiama "principio della duplice rilevazione simultanea"
se fai partita tripla avrai una triplice rilevazione simultanea ecc.
se invece volessi usare una logica completamente enne a enne, potresti
anche avere un numero illimitato di dimensioni. Una specie di tag
cloud in cui ogni tag e' una partita.
Questo e' stato un esperimento che ho fatto ma apparentemente non
interessa a nessuno :(
>> Per dire nel mio dominio attuale, spesso gli esperti parlano di
>> "device" intendendo un telefono mobile. Pero' il termine device per
>> gli esperti di marketing e' abbastanza ampio (il nome commerciale del
>> cellulare) mentre per chi lavora nel campo di vendita di applicazioni
>> ad ogni "device" deve corrispondere un certo firmware e una certa
>> versione hw (alcuni giochi vanno solo su alcune versioni). Quindi i
>> due gruppi usano device con significati leggermente differenti, che
>> non sono un problema quando si parlano tra di loro, ma sono un
>> problema per noi quando dobbiamo fare un sw che funzioni per entrambi.
>
>
> In questo tipo di situazione, noi definiamo due bounded context, uno per il
> marketing e uno per gli sviluppatori (o anche 3, se utilizziamo uno shared
> kernel).
> In ciascuno esisterebbe il concetto di device, ma con proprietà, comandi e
> query specifiche per il contesto, ma esisterebbe un meccanismo di context
> mapping (il più semplice dei quali è lo shared identifier).
>
> Non c'è bisogno di avere una visione del device che vada bene a tutti.
No qui non ti seguo proprio.
L'applicazione a cui sto pensando mostra sul cellulare del cliente
delle promozioni tipo "clicca qui per avere angry birds al 50% di
sconto", "nuovo piano superconveniente per le nipotine di Mubarak"
ecc.
Ora per ogni "device" il marketing crea un set di promozioni
differente. E qui device==modello + costruttore (HTC Legend, Samsung
Galaxy ecc.)
Quando l'utente schiaccia su angrybirds, noi dobbiamo trovare la
versione del gioco da scaricargli per quella "device". E qui device ==
modello + costruttore + firmware versione + os version + localization.
L'idea di avere due classi Device che sottintendano due cose diverse
in due punti diversi del codice non mi piace per nulla. Noi abbiamo
rinominato la seconda e insegnato anche ai Business Analyst ad usare
un nome diverso.
Nota che e' vero che la logica del download e' in un Bounded Context
diverso, ma comunque il BC delle promozioni deve parlarci col BC dei
download.
Inoltre i documenti tecnici come l'High Level Design coprono tutto il
ciclo, e' quindi importante si usino termini univoci.
> Credo che l'unico vero difetto del libro blu sia non dare sufficiente peso
> ai bounded context.
A me pare che nella seconda parte ne parli abbastanza, mi pare un
topic comunque molto avanzato e per progetti grossi... o forse sono io
che dovrei usarli di piu. :)
> Beh io posso dire che se applicato male è estremamente costoso.
:)
> IMHO, è costoso comunque, anche se applicato bene, ma è il costo minimo per
> certi tipi di applicazioni (ovviamente se devono funzionare, se devono
> macinare utili attraverso i bugfix e il body rental, no).
Esatto e' quello che volevo dire io. Se vuoi un'applicazione di un
certo tipo, che ti mappi un dominio esistente e complesso, e la vuoi
che funzioni, allora DDD e' il metodo piu' economico che conosco.
> Al contrario, se pubblicassimo solo i BC "migliori", sarebbe evidente che è
> DDD (visti i VISION.txt, la documentazione delle interfacce, la forma delle
> stesse etc...) a chiunque conosca C#.
Quello che volevo dire e' "guardando il mio codice chiunque puo' dire
che ho modellato il dominio, ma non puoi sapere se l'ho modellato
giusto se non conosci il dominio stesso." Soprattutto da un punto di
vista didattico, vedendo il codice senza la storia di come ci si e'
arrivati, dubito che uno possa capire DDD.
Pero' da autodidatta DDD, non so a cosa tu ti riferisca con "i
VISION.txt, la documentazione delle interfacce, la forma delle stesse
etc...."
Immagino siano delle pratiche C#-DDD ma non credo proprio sia quello
il punto di "riconoscere DDD".
In generale non credo che il codice di DDD debba essere diverso da
ottimo codice OOP.
Non vorrei mai essere nella posizione di dovermi porre la domanda "ma
questa cosa la faccio in OOP o in DDD?"
> Beh, Epic lo è, ma in effetti non è un domain model è un framework per
> sviluppare applicazioni DDD.
Non conosco Epic, ma personalmente dubito forte che uno possa capire
DDD guardando il codice di un framework, per quanto scritto bene.
ciao
Uberto
questa discussione sta diventando sempre piu' interessante.
Sottoscrivo. :-D
> In questo tipo di situazione, noi definiamo due bounded context, uno per il
> marketing e uno per gli sviluppatori (o anche 3, se utilizziamo uno shared
> kernel).
> In ciascuno esisterebbe il concetto di device, ma con proprietà, comandi e
> query specifiche per il contesto, ma esisterebbe un meccanismo di context
> mapping (il più semplice dei quali è lo shared identifier).
>
> Non c'è bisogno di avere una visione del device che vada bene a tutti.
No qui non ti seguo proprio.
L'applicazione a cui sto pensando mostra sul cellulare del cliente
delle promozioni tipo "clicca qui per avere angry birds al 50% di
sconto", "nuovo piano superconveniente per le nipotine di Mubarak"
ecc.
Ora per ogni "device" il marketing crea un set di promozioni
differente. E qui device==modello + costruttore (HTC Legend, Samsung
Galaxy ecc.)
Quando l'utente schiaccia su angrybirds, noi dobbiamo trovare la
versione del gioco da scaricargli per quella "device". E qui device ==
modello + costruttore + firmware versione + os version + localization.
L'idea di avere due classi Device che sottintendano due cose diverse
in due punti diversi del codice non mi piace per nulla. Noi abbiamo
rinominato la seconda e insegnato anche ai Business Analyst ad usare
un nome diverso.
Nota che e' vero che la logica del download e' in un Bounded Context
diverso, ma comunque il BC delle promozioni deve parlarci col BC dei
download.
Questa è una situazione abbastanza frequente nei nostri applicativi (anche se ovviamente la materia è completamente diversa).
La nostra infrastruttura è estremamente modulare e ci permette di utilizzare bounded context diversi nello stesso applicativo, dove in precedenza sviluppavamo applicativi diversi.
Seguendo il tuo esempio (abbi pazienza, potrebbe non calzare esattamente il dominio che hai in mente), nel bounded context utilizzato dagli esperti del marketing l'entità Device verrebbe identificato da due proprietà, modello + costruttore, mentre nel BC degli utenti che scaricano l'applicativo, il Device avrebbe tutte le proprietà identificative che dicevi (modello + costruttore + firmware versione + os version + localization).
Ci sarebbe un metodo di context map (un servizio di dominio?) per passare da un contesto all'altro.
Nel primo bounded context, verrebbe gestita la creazione delle offerte (bounded role = marketing), in un secondo verrebbero trattati gli acquisti dei prodotti in offerta o meno (bounded role = buyer), in un terzo lo scaricamento delle app (bounded role = app downloader :-D).
I bounded context, "semplicemente" definiscono in modo chiaro (e rigido) i contesti ortogonali che il linguaggio umano assume.
Noi umani siamo estremamente abili a cambiare contesto e (uasi inconsapevolmente) assegnare ai significanti, i significati appropriati al contesto.
Per i computer questa cosa deve avvenire esplicitamente.
Inoltre i documenti tecnici come l'High Level Design coprono tutto il
ciclo, e' quindi importante si usino termini univoci.
Vero, ma semplicemente perché nei documenti tecnici di così alto livello è più importante la struttura di larga scala del dominio, la sua visione di insieme, rispetto ai dettagli di ogni singolo contesto.
Per descrivere le peculiarità di ciascun bounded context, noi utilizziamo il Vision Statement, che ovviamente mettiamo sotto controllo di versione (VISION.txt).
> Credo che l'unico vero difetto del libro blu sia non dare sufficiente peso
> ai bounded context.
A me pare che nella seconda parte ne parli abbastanza, mi pare un
topic comunque molto avanzato e per progetti grossi... o forse sono io
che dovrei usarli di piu. :)
Io lavoro molto con progetti "grossi" (più di 1 anno uomo di lavoro, in genere).
Però, in generale, ho l'impressione che siano uno strumento veramente importante del DDD, forse il più importante, dopo la collaborazione con l'esperto di dominio.
In effetti, IMHO, la necessità di inventare nuovi termini per evitare ambiguità ed educare gli stakeholder ad usarli (cosa che per altro per noi sarebbe impossibile) è sintomo della rinuncia ad analizzare i diversi bounded context (ovvero le diverse prospettive sulla materia del problema).
Accorgersi che, in contesti diversi, lo stesso termine ha un significato leggermente diverso rappresenta uno strumento straordinario anche per gli esperti stessi.
Soprattuto nel momento in cui riescono a dare un nome al contesto.
Pero' da autodidatta DDD, non so a cosa tu ti riferisca con "i
VISION.txt, la documentazione delle interfacce, la forma delle stesse
etc...."
Immagino siano delle pratiche C#-DDD ma non credo proprio sia quello
il punto di "riconoscere DDD".
No no... parlavo della documentazione del codice (metodi proprietà eventi etc.. l'equivalente .NET di Javadoc)
Il VISION.txt è semplicemente il Domain Vision Statement (p415-416 libro blu) che mettiamo su mercurial con il codice del modello.
Secondo me è quasi indicativo dell'aver capito cosa tratta il domain driven design.
In generale non credo che il codice di DDD debba essere diverso da
ottimo codice OOP.
Su questo bisognerebbe scrivere un libro.
Il DDD è tipicamente implementato in OOP, ma di solito quando sento dire questa cosa mi sorge il sospetto che non si abbia veramente compreso il DDD.
La programmazione ad oggetti si applica anche a framework, per esempio, ma un framework non è un domain model, pur essendo di ottima qualità.
Non vorrei mai essere nella posizione di dovermi porre la domanda "ma
questa cosa la faccio in OOP o in DDD?"
No neanche questo è possibile, secondo me.
Scegli DDD perché sai di non sapere una fava sulla materia che il tuo applicativo dovrà trattare.
Scegli OOP per una valanga di ragioni ortogonali a questa (skill degli sviluppatori, infrastruttura esistente etc...)
> Beh, Epic lo è, ma in effetti non è un domain model è un framework per
> sviluppare applicazioni DDD.
Non conosco Epic, ma personalmente dubito forte che uno possa capire
DDD guardando il codice di un framework, per quanto scritto bene.
Beh, qui è un po' offtopic, ma Epic non è un framework fatto solo di codice.
Una buona parte del valore di Epic sta nei pattern di modellazione che documento nel suo manuale.
Pattern che se applicati tutti coerentemente (nella mia personale esperienza) permettono di produrre domain model di altissima qualità e soprattutto permettono di farlo a modellatori diversi, senza bisogno di super esperti nel DDD.
Nel manuale ho chiamato questi pattern una "grammatica condivisa" per la modellazione degli ubiquitous language.
Hai ragione dunque, non è guardando il codice di Epic che si può capire il DDD.
E nemmeno leggere quei pattern è sufficiente (se non si ha letto prima il libro blu, e magari anche PoEE e magari anche qualche libro di Agile Software Development di Martin)
Io rispondevo a questa tua frase:
Di solito i progetti Open Source crowd source non nascono da un esigenza DDD.
Epic è un framework open source che nasce da un "esigenza DDD" ovvero facilitare l'utilizzo di un domain model in applicativi complessi, modulari ed estendibili e con la supercazzola.
Ma non è comunque un framework fatto di solo codice. Tutta la prima parte del manuale che ho scritto non tratta del codice (e per questo interessa a pochi, purtroppo), ma di pattern di modellazione che abbiamo imparato in 3 anni di nasate :-D.
Questa parte "concettuale" di Epic è straordinariamente sottovalutata. Al contrario dal mio punto di vista, il provider Linq a confronto è una bazzecola che chiunque potrebbe fare (e infatti non capisco perché siamo solo in due a lavorarci, sigh...).
Il giorno 01 gennaio 2012 12:28, Uberto Barbini <uberto@...> ha scritto:
Buon anno a tutti.
questa discussione sta diventando sempre piu' interessante.
> Ecco, su questo siamo in pacifico disaccordo. :-D
>
> Per me, se dal suo punto di vista sono diverse, il computer riporta
> banalmente questa differenza.
Allora qui ci siamo chiariti, siamo in disaccordo (che ci sta benissimo). :)
Vedi per me il punto di vista del computer e' diverso da quello
dell'esperto, quindi a volte servono termini nuovi.
> Conosco la differenza fra flussi e stock, ma a dire il vero ricordo che mi
> hanno proprio spiegato che la partita doppia tratta i flussi da cui è
> possibile determinare gli stock ad una qualsiasi data.
> E mi hanno anche detto quella bagianata dei segni... Magari pensavano che in
> quanto informatico, non potessi proprio capire! :-D
:)
wikipedia http://it.wikipedia.org/wiki/Partita_doppia
lo chiama "principio della duplice rilevazione simultanea"
se fai partita tripla avrai una triplice rilevazione simultanea ecc.
se invece volessi usare una logica completamente enne a enne, potresti
anche avere un numero illimitato di dimensioni. Una specie di tag
cloud in cui ogni tag e' una partita.
Questo e' stato un esperimento che ho fatto ma apparentemente non
interessa a nessuno :(
A me interessa.
Dal mio punto di vista non è altro che una variazione sul tema di MVC.
Però non è un argomento che puoi potare al tavolo con l'esperto di dominio, così a cuor leggero.
Rischi di portarlo fuori dall'area in cui si sente tranquillo.
>> Per dire nel mio dominio attuale, spesso gli esperti parlano di
>> "device" intendendo un telefono mobile. Pero' il termine device per
>> gli esperti di marketing e' abbastanza ampio (il nome commerciale del
>> cellulare) mentre per chi lavora nel campo di vendita di applicazioni
>> ad ogni "device" deve corrispondere un certo firmware e una certa
>> versione hw (alcuni giochi vanno solo su alcune versioni). Quindi i
>> due gruppi usano device con significati leggermente differenti, che
>> non sono un problema quando si parlano tra di loro, ma sono un
>> problema per noi quando dobbiamo fare un sw che funzioni per entrambi.
>
>
> In questo tipo di situazione, noi definiamo due bounded context, uno per il
> marketing e uno per gli sviluppatori (o anche 3, se utilizziamo uno shared
> kernel).
> In ciascuno esisterebbe il concetto di device, ma con proprietà, comandi e
> query specifiche per il contesto, ma esisterebbe un meccanismo di context
> mapping (il più semplice dei quali è lo shared identifier).
>
> Non c'è bisogno di avere una visione del device che vada bene a tutti.
No qui non ti seguo proprio.
L'applicazione a cui sto pensando mostra sul cellulare del cliente
delle promozioni tipo "clicca qui per avere angry birds al 50% di
sconto", "nuovo piano superconveniente per le nipotine di Mubarak"
ecc.
Ora per ogni "device" il marketing crea un set di promozioni
differente. E qui device==modello + costruttore (HTC Legend, Samsung
Galaxy ecc.)
Quando l'utente schiaccia su angrybirds, noi dobbiamo trovare la
versione del gioco da scaricargli per quella "device". E qui device ==
modello + costruttore + firmware versione + os version + localization.
L'idea di avere due classi Device che sottintendano due cose diverse
in due punti diversi del codice non mi piace per nulla.
Se sono in due Bounded Context diversi non è un problema.
Se sono nello stesso BC allora si deve agire a livello di naming. Il punto è che il Bounded Context si "leggono" più spesso di quanto non si "scrivano". Quindi se le cose sono state sviluppate da team diversi con una diversa idea di Device, hai 2 BC de-facto. Se uno stesso gruppo o gruppo allargato decide di lavorare per rimuovere le ambiguità tra più BC, di fatto ne sta facendo uno più grande, facendo un lavoro certosino di rinomina.
Tutto legittimo. Dipende dal rapporto costi benefici specifico della situazione.
Noi abbiamo
rinominato la seconda e insegnato anche ai Business Analyst ad usare
un nome diverso.
Nota che e' vero che la logica del download e' in un Bounded Context
diverso, ma comunque il BC delle promozioni deve parlarci col BC dei
download.
Qui in DDD hai N scelte: Conformist, Anti-Corruption Layer, Partner, il punto è qual è la modalità di collaborazione che hai per poter condividere un modello. In questo caso credo di poter dire che abbiate adottato uno shared kernel, o che comunque siate su partnership o customer-supplier in ogni caso, configurazioni ad alto passaggio di informazioni.
Inoltre i documenti tecnici come l'High Level Design coprono tutto il
ciclo, e' quindi importante si usino termini univoci.
Questo è un'aspetto interessante. Ma è anche vero che i contesti possono/devono essere pubblici noti, specialmente a questo livello.
> Credo che l'unico vero difetto del libro blu sia non dare sufficiente peso
> ai bounded context.
A me pare che nella seconda parte ne parli abbastanza, mi pare un
topic comunque molto avanzato e per progetti grossi... o forse sono io
che dovrei usarli di piu. :)
Credo sia questa l'impressione sbagliata che viene fuori dal libro. Io ora parto dalla lettura dei BC e dal presidio del confine del mio BC, altrimenti non posso modellare correttamente. Specialmente in presenza di qualcosa di già esistente. Se parto dal foglio bianco, ci sta che stia tutto o quasi in un BC e che gli altri modelli siano talmente chiaramente esterni da non rappresentare un problema.
> Beh io posso dire che se applicato male è estremamente costoso.
:)
> IMHO, è costoso comunque, anche se applicato bene, ma è il costo minimo per
> certi tipi di applicazioni (ovviamente se devono funzionare, se devono
> macinare utili attraverso i bugfix e il body rental, no).
Esatto e' quello che volevo dire io. Se vuoi un'applicazione di un
certo tipo, che ti mappi un dominio esistente e complesso, e la vuoi
che funzioni, allora DDD e' il metodo piu' economico che conosco.
> Al contrario, se pubblicassimo solo i BC "migliori", sarebbe evidente che è
> DDD (visti i VISION.txt, la documentazione delle interfacce, la forma delle
> stesse etc...) a chiunque conosca C#.
Quello che volevo dire e' "guardando il mio codice chiunque puo' dire
che ho modellato il dominio, ma non puoi sapere se l'ho modellato
giusto se non conosci il dominio stesso." Soprattutto da un punto di
vista didattico, vedendo il codice senza la storia di come ci si e'
arrivati, dubito che uno possa capire DDD.
Pero' da autodidatta DDD, non so a cosa tu ti riferisca con "i
VISION.txt, la documentazione delle interfacce, la forma delle stesse
etc...."
Immagino siano delle pratiche C#-DDD ma non credo proprio sia quello
il punto di "riconoscere DDD".
In generale non credo che il codice di DDD debba essere diverso da
ottimo codice OOP.
Sottoscrivo, DDD si preoccupa forse un po' di più di trovare il posto corretto per poterlo fare :-) ma è anche vero che alcune cose di OOP non è detto che trovino la loro applicazione a livello di domain model. Modellare il dominio è comunque una specializzazione della classe di problemi risolvibili con OOP.
Non vorrei mai essere nella posizione di dovermi porre la domanda "ma
questa cosa la faccio in OOP o in DDD?"
> Beh, Epic lo è, ma in effetti non è un domain model è un framework per
> sviluppare applicazioni DDD.
Non conosco Epic, ma personalmente dubito forte che uno possa capire
DDD guardando il codice di un framework, per quanto scritto bene.
Sottoscrivo, molto più importante il come ed il perché ci arrivi.
Se parli di Management 3.0 non c'è nessunissima obiezione. :) T.
From:
Alberto Brandolini <alberto.brandolini@...>; To:
<DDD-IT@yahoogroups.com>; Subject:
[DDD-IT] Policy, annunci e sdoppiamenti della personalità Sent:
Tue, Mar 6, 2012 3:21:39 PM
Ciao a tutti,
ho un piccolo problema di sovrapposizione di ruoli, etica, logica e sdoppiamento della personalità.
Come piccolo imprenditore, vorrei pubblicare un annuncio su questa ML.
Come moderatore della ML dovrei decidere che policy adottare, di fronte ad una proposta di questo genere.
I requisiti che mi darei - e che quindi dovrebbero valere per ogni annuncio - sono i seguenti:
1) È pertinente agli argomenti trattati nella lista?
2) È riconoscibile come annuncio di tipo commerciale?
3) È di interesse per le persone presenti in lista?
4) Per quanto mi è dato sapere, non è una truffa.
Nella pratica quindi, se passa i punti 1,3 e 4 chiederei di etichettare con [ANN] il messaggio, perché sia riconoscibile e lo lascerei passare.
Posto che non sia una consapevole truffa (4, ma siamo tutti grandi e ci sappiamo difendere), per me basta che valga il punto 3, dato che del 2 ce ne accorgeremmo comunque, e l'1 lè abbastanza implicito nel 3.
Per cui: figliolo, coraggio, vieni avanti e non ti sdoppiare, ché ti buschi un raffreddore! Sui conflitti d'interesse ci siamo già vaccinati più che a sufficienza...
zio brando schrieb:
>> Se non ci sono obiezioni ...procedo :-)
Procedi, poi al limite ti si leva la pelle a colpi di flames. ;)
---------------------------------------------------------------------
Fabio Sogni | E-Mail: fsogni@... |
ESO - EUROPEAN SOUTHERN OBSERVATORY | Phone : +49 89 320 06 566 |
Karl Schwarzschild Strasse, 2 | Fax : +49 89 320 06 677 |
Garching bei Muenchen - Germany | |
---------------------------------------------------------------------
Visita Interiora Terrae, Rectificando Invenies Occultum Lapidem.
---------------------------------------------------------------------
nel primo caso si tratta di una classe "tradizionale" se di tradizionale si può parlare, trattandosi di Greg Young.
Nel secondo caso si tratta di un workshop in cui intervengono oltre alle "mani sul codice" anche elementi di giochi e simulazione, per realizzare collaborativamente la costruzione di un sistema complesso.
In entrambi i casi è necessario portarsi il portatile ed essere ben svegli perché Greg ci rivolterà come dei calzini.
> Alberto Brandolini <alberto.brandolini@...> ha scritto:
>
> Come piccolo imprenditore, vorrei pubblicare un annuncio
> su questa ML.
>
[...]
>
> Se non ci sono obiezioni ...procedo :-)
Procedi tranquillamente.
Che se riesci a portare in Italia (per business e diletto) persone come Young,
Appelo (ed Evans, Beck, Martin, Feathers, Jeff Patton, Rachel Davis,
Poppendieck, ecc..) rischi pure di essere nominato cavaliere del lavoro da
Napolitano :)
Ciao
Sergio
ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
E non ci sono captcha! ;-)
per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
Che ne pensate?
Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
From: Alberto Brandolini <alberto.brandolini@...> To: DDD-IT@yahoogroups.com Sent: Thursday, March 22, 2012 5:15 PM Subject: [DDD-IT] Virtual meetings, any idea?
Ciao a tutti,
ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
E non ci sono captcha! ;-)
per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
Che ne pensate?
Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
Presente per la conference call! :)
Per quanto riguarda la piattaforma, oltre a skype, dalla regia del nostro
reparto IT mi consigliano http://vsee.com/
Personalmente non l'ho mai usato però si potrebbe fare una prova generale e
decidere se ci piace.
Nel frattempo skypeid: giancarlo.pace
Ciao,
--
gk
On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
> Ciao a tutti,
>
>
> ho come l'impressione che ci siano più cose da dire di quelle che in effetti
ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni
interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
> E non ci sono captcha! ;-)
>
> per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale.
Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
> Che ne pensate?
>
> Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo
di Google+, ma forse non è adeguato se siamo in tanti.
> Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
>
> Fatemi sapere che ne pensate!
>
> Grazie mille.
>
> Brando
>
>
>
>
> --
> Alberto Brandolini
> Phone: +39-347-6005027
>
> E-mail: alberto.brandolini@...
> Twitter: @ziobrando
>
> Company: http://www.avanscoperta.it
> Blog: http://ziobrando.blogspot.com
> Linkedin: http://www.linkedin.com/in/brando
>
>
>
ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
E non ci sono captcha! ;-)
per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
Che ne pensate?
Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
E non ci sono captcha! ;-)
per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
Che ne pensate?
Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
E non ci sono captcha! ;-)
per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
Che ne pensate?
Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
E non ci sono captcha! ;-)
per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
Che ne pensate?
Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
Il giorno 22 marzo 2012 17:50, Gian Carlo Pace <giancarlo.pace@...> ha scritto:
Presente per la conference call! :)
Per quanto riguarda la piattaforma, oltre a skype, dalla regia del nostro reparto IT mi consigliano http://vsee.com/
Ok, possiamo provarci.
Skype invece per qualche motivo (acquisizione da parte di Microsoft?) ha cominciato ad essere inaffidabile sul mio Mac...
Personalmente non l'ho mai usato però si potrebbe fare una prova generale e decidere se ci piace.
Nel frattempo skypeid: giancarlo.pace
Ciao,
--
gk
On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
> Ciao a tutti,
>
>
> ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
> E non ci sono captcha! ;-)
>
> per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
> Che ne pensate?
>
> Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
> Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
>
> Fatemi sapere che ne pensate!
>
> Grazie mille.
>
> Brando
>
>
>
>
> --
> Alberto Brandolini
> Phone: +39-347-6005027
>
> E-mail: alberto.brandolini@...
> Twitter: @ziobrando
>
> Company: http://www.avanscoperta.it
> Blog: http://ziobrando.blogspot.com
> Linkedin: http://www.linkedin.com/in/brando
>
>
>
ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
E non ci sono captcha! ;-)
per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
Che ne pensate?
Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
ho come l'impressione che ci siano più cose da dire di quelle che in effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre delle conversazioni interessanti. Ma lo scalino d'ingresso del gruppo pare troppo alto.
E non ci sono captcha! ;-)
per cui mi è venuta questa idea di fare ogni tanto un meeting virtuale. Un'oretta di discussione dopo cena. Ogni tanto. Per chi c'è.
Che ne pensate?
Come piattaforma avete qualche idea? A me era piaciuto molto il videoritrovo di Google+, ma forse non è adeguato se siamo in tanti.
Qualcuno ha qualche esperienza al riguardo? Consigli, suggerimenti?
> On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
>
> Ciao a tutti,
> ho come l'impressione che ci siano più cose da dire di quelle che in
> effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre
> delle conversazioni interessanti.
[...]
> per cui mi è venuta questa idea di fare ogni tanto un meeting
> virtuale. Un'oretta di discussione dopo cena. Ogni tanto.
> Per chi c'è.
> Che ne pensate?
Non male come idea.
Partecipo volentieri.
Ciao,
Sergio
Dato che ci sono state un po' di adesioni provo a buttare lì una data solo per
aprire le danze:
- Martedì 3 aprile.
Cosa ne dite?
Che fascia oraria preferite?
Ciao,
--
gk
On Mar 26, 2012, at 8:25 PM, Sergio wrote:
> > On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
> >
> > Ciao a tutti,
> > ho come l'impressione che ci siano più cose da dire di quelle che in
> > effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre
> > delle conversazioni interessanti.
> [...]
> > per cui mi è venuta questa idea di fare ogni tanto un meeting
> > virtuale. Un'oretta di discussione dopo cena. Ogni tanto.
> > Per chi c'è.
> > Che ne pensate?
>
> Non male come idea.
> Partecipo volentieri.
>
> Ciao,
> Sergio
>
>
Mercoledì 4?
Inviato da iPhone
Il giorno 27/mar/2012, alle ore 21:59, Gian Carlo Pace
<giancarlo.pace@...> ha scritto:
> Dato che ci sono state un po' di adesioni provo a buttare lì una data solo
per aprire le danze:
>
> - Martedì 3 aprile.
> Cosa ne dite?
>
> Che fascia oraria preferite?
>
> Ciao,
> --
> gk
>
> On Mar 26, 2012, at 8:25 PM, Sergio wrote:
>
>>> On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
>>>
>>> Ciao a tutti,
>>> ho come l'impressione che ci siano più cose da dire di quelle che in
>>> effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre
>>> delle conversazioni interessanti.
>> [...]
>>> per cui mi è venuta questa idea di fare ogni tanto un meeting
>>> virtuale. Un'oretta di discussione dopo cena. Ogni tanto.
>>> Per chi c'è.
>>> Che ne pensate?
>>
>> Non male come idea.
>> Partecipo volentieri.
>>
>> Ciao,
>> Sergio
>>
>>
>
>
>
> ------------------------------------
>
> Link utili di Yahoo! Gruppi
>
>
>
Il giorno 28/mar/2012, alle ore 00:09, Alberto Brandolini <alberto.brandolini@...> ha scritto:
Mercoledì 4?
Inviato da iPhone
Il giorno 27/mar/2012, alle ore 21:59, Gian Carlo Pace <giancarlo.pace@...> ha scritto:
> Dato che ci sono state un po' di adesioni provo a buttare lì una data solo per aprire le danze:
>
> - Martedì 3 aprile.
> Cosa ne dite?
>
> Che fascia oraria preferite?
>
> Ciao,
> --
> gk
>
> On Mar 26, 2012, at 8:25 PM, Sergio wrote:
>
>>> On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
>>>
>>> Ciao a tutti,
>>> ho come l'impressione che ci siano più cose da dire di quelle che in
>>> effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre
>>> delle conversazioni interessanti.
>> [...]
>>> per cui mi è venuta questa idea di fare ogni tanto un meeting
>>> virtuale. Un'oretta di discussione dopo cena. Ogni tanto.
>>> Per chi c'è.
>>> Che ne pensate?
>>
>> Non male come idea.
>> Partecipo volentieri.
>>
>> Ciao,
>> Sergio
>>
>>
>
>
>
> ------------------------------------
>
> Link utili di Yahoo! Gruppi
>
>
>
Il giorno 28/mar/2012, alle ore 00:24, Alessio Gogna <agogna@...> ha scritto:
Doodle?
Il giorno 28/mar/2012, alle ore 00:09, Alberto Brandolini <alberto.brandolini@...> ha scritto:
Mercoledì 4?
Inviato da iPhone
Il giorno 27/mar/2012, alle ore 21:59, Gian Carlo Pace <giancarlo.pace@...> ha scritto:
> Dato che ci sono state un po' di adesioni provo a buttare lì una data solo per aprire le danze:
>
> - Martedì 3 aprile.
> Cosa ne dite?
>
> Che fascia oraria preferite?
>
> Ciao,
> --
> gk
>
> On Mar 26, 2012, at 8:25 PM, Sergio wrote:
>
>>> On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
>>>
>>> Ciao a tutti,
>>> ho come l'impressione che ci siano più cose da dire di quelle che in
>>> effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre
>>> delle conversazioni interessanti.
>> [...]
>>> per cui mi è venuta questa idea di fare ogni tanto un meeting
>>> virtuale. Un'oretta di discussione dopo cena. Ogni tanto.
>>> Per chi c'è.
>>> Che ne pensate?
>>
>> Non male come idea.
>> Partecipo volentieri.
>>
>> Ciao,
>> Sergio
>>
>>
>
>
>
> ------------------------------------
>
> Link utili di Yahoo! Gruppi
>
>
>
Il giorno 28/mar/2012, alle ore 00:24, Alessio Gogna <agogna@...> ha scritto:
Doodle?
Il giorno 28/mar/2012, alle ore 00:09, Alberto Brandolini <alberto.brandolini@...> ha scritto:
Mercoledì 4?
Inviato da iPhone
Il giorno 27/mar/2012, alle ore 21:59, Gian Carlo Pace <giancarlo.pace@...> ha scritto:
> Dato che ci sono state un po' di adesioni provo a buttare lì una data solo per aprire le danze:
>
> - Martedì 3 aprile.
> Cosa ne dite?
>
> Che fascia oraria preferite?
>
> Ciao,
> --
> gk
>
> On Mar 26, 2012, at 8:25 PM, Sergio wrote:
>
>>> On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
>>>
>>> Ciao a tutti,
>>> ho come l'impressione che ci siano più cose da dire di quelle che in
>>> effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre
>>> delle conversazioni interessanti.
>> [...]
>>> per cui mi è venuta questa idea di fare ogni tanto un meeting
>>> virtuale. Un'oretta di discussione dopo cena. Ogni tanto.
>>> Per chi c'è.
>>> Che ne pensate?
>>
>> Non male come idea.
>> Partecipo volentieri.
>>
>> Ciao,
>> Sergio
>>
>>
>
>
>
> ------------------------------------
>
> Link utili di Yahoo! Gruppi
>
>
>
Ad oggi nel doodle abbiamo su 8 partecipanti due picchi di 6 presenze: il 3/4
alle 10:30 e il 5 alle 10:30.
Cosa dite: scegliamo una di queste due date o rimandiamo ancora di una
settimana? Come siete messi nella settimana successiva?
Personalmente ho come unico vincolo ho il mercoledì in cui ho un impegno
costante.
Ciao,
--
gk
On Mar 28, 2012, at 9:39 AM, Alberto Brandolini wrote:
> http://www.doodle.com/85h96987ycv4ke6k
>
>
>
>
>
> Il giorno 28 marzo 2012 07:50, Alberto Brandolini
<alberto.brandolini@...> ha scritto:
> +1 per doodle
>
> Inviato da iPhone
>
> Il giorno 28/mar/2012, alle ore 00:24, Alessio Gogna <agogna@...> ha
scritto:
>
>>
>>
>> Doodle?
>>
>> Il giorno 28/mar/2012, alle ore 00:09, Alberto Brandolini
<alberto.brandolini@...> ha scritto:
>>
>>>
>>> Mercoledì 4?
>>>
>>> Inviato da iPhone
>>>
>>> Il giorno 27/mar/2012, alle ore 21:59, Gian Carlo Pace
<giancarlo.pace@...> ha scritto:
>>>
>>> > Dato che ci sono state un po' di adesioni provo a buttare lì una data solo
per aprire le danze:
>>> >
>>> > - Martedì 3 aprile.
>>> > Cosa ne dite?
>>> >
>>> > Che fascia oraria preferite?
>>> >
>>> > Ciao,
>>> > --
>>> > gk
>>> >
>>> > On Mar 26, 2012, at 8:25 PM, Sergio wrote:
>>> >
>>> >>> On Mar 22, 2012, at 5:15 PM, Alberto Brandolini wrote:
>>> >>>
>>> >>> Ciao a tutti,
>>> >>> ho come l'impressione che ci siano più cose da dire di quelle che in
>>> >>> effetti ci diciamo. Quando incontro qualcuno di voi ci sono sempre
>>> >>> delle conversazioni interessanti.
>>> >> [...]
>>> >>> per cui mi è venuta questa idea di fare ogni tanto un meeting
>>> >>> virtuale. Un'oretta di discussione dopo cena. Ogni tanto.
>>> >>> Per chi c'è.
>>> >>> Che ne pensate?
>>> >>
>>> >> Non male come idea.
>>> >> Partecipo volentieri.
>>> >>
>>> >> Ciao,
>>> >> Sergio
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > ------------------------------------
>>> >
>>> > Link utili di Yahoo! Gruppi
>>> >
>>> >
>>> >
>>
>
>
>
> --
> Alberto Brandolini
> Phone: +39-347-6005027
>
> E-mail: alberto.brandolini@...
> Twitter: @ziobrando
>
> Company: http://www.avanscoperta.it
> Blog: http://ziobrando.blogspot.com
> Linkedin: http://www.linkedin.com/in/brando
>
>
>
Hai ricevuto questo messaggio email di cortesia all'account ddd-it@yahoogroups.com perché sei uno dei partecipanti a questo evento.
Per disattivare la ricezione di future notifiche per questo evento, rifiuta l'evento. In alternativa, puoi registrarti per un account Google in https://www.google.com/calendar/ e verificare le impostazioni di notifica per l'intero calendario.
Ho aggiunto le note per ogni slides, per cui se qualcuno non c'era può leggere il mio disordinato flusso di pensieri nelle note, sperando che Slideshare non incasini l'ordine come ha già fatto in passato.
Ho anche aggiunto/modificato/corretto alcune slides per chiarire meglio alcuni aspetti che "live" ho affrontato troppo velocemente o in maniera non molto chiara.
ovviamente sono più che disponibile ad una discussione/follow-up :-)
Ho aggiunto le note per ogni slides, per cui se qualcuno non c'era può leggere il mio disordinato flusso di pensieri nelle note, sperando che Slideshare non incasini l'ordine come ha già fatto in passato.
Ho anche aggiunto/modificato/corretto alcune slides per chiarire meglio alcuni aspetti che "live" ho affrontato troppo velocemente o in maniera non molto chiara.
ovviamente sono più che disponibile ad una discussione/follow-up :-)
Invia email
