agosto 2016 Blog Posts

I “fat event” non esistono

Nel mio peregrinare nei meandri del mondo SOA e in particolare di Services UI Composition mi sto sempre più convincendo che i così detti “fat events” non hanno ragione di esistere. È un’affermazione forte lo so, e non è ancora una convinzione, ne parleremo ancora magari cercando di sviscerare la questione fino in fondo. Tipologie di eventi Se penso alla parola “event” la penso declinata nei seguenti modi: Domain Event Thin Event Fat Event Abbiamo già detto, e approfondito, che Domain Event è...

posted @ mercoledì 31 agosto 2016 10:15 | Feedback (0)

SOA service model decomposition: i servizi, atto secondo.

Prima di dare un’occhiata al commento di Raffaele devo fare un altro passaggio. Nella nostra analisi ad un certo punto abbiamo introdotto e definito i servizi che servono per soddisfare il requisito. Tempo fa abbiamo anche parlato di cosa sia un servizio nel mondo SOA. Abbiamo definito i nostri servizi: Che sono: per forza logicamente separati possono essere fisicamente separati possono essere, tutti o in parte, servizi di terze parti Un esempio Quando un ordine su Amazon è in...

posted @ lunedì 29 agosto 2016 10:01 | Feedback (0)

Reinventing Organizations: da leggere!

Se come me vivete in una realtà diversa da una tradizionale. Se siete curiosi di capire come si sono evoluti, e perché, i modelli organizzativi dalla notte dei tempi ad oggi. Se desiderate scoprire come questi modelli si evolveranno Reinventing Organizations è il libro da leggere. (Amazon: Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness) Il testo è utile anche per tutti gli scettici, per tutti quelli che dicono che un modello diverso da quello attuale, un modello ad esempio (ma non solo) totalmente basato sul self-management, non sia...

posted @ sabato 27 agosto 2016 12:11 | Feedback (0)

Raccontare una storia

Avete presente quel momento in cui siete al cinema e il film non vi piace? e vi rendete conto che il film non vi piace perché la storia non sta insieme, non ha ne capo ne coda, è congegnata male, o semplicemente non funziona. La storia è tutto La storia che vogliamo raccontare è tutto, sia un film, una pubblicità, un post come questo, una serie di post o una presentazione. Quindi perché vi fate del male e: Le slide? mezz’ora prima della sessione. Gli esempi? ma si li costruisco al...

posted @ venerdì 26 agosto 2016 11:47 | Feedback (2)

La definizione del problema.

Avete presente quelle “amene” situazioni in cui le discussioni si protraggono all’infinito senza alcuna apparente possibilità di soluzione? Tipicamente diciamo che siamo in stallo o in conflitto….in realtà il problema potrebbe essere un altro. Spesso quello che succede è che i contendenti non stanno discutendo dello stesso problema o il problema di cui stanno discutendo è troppo ampio. Quello che succede nel primo caso è che qualcuno solleva un problema, magari un po’ vago, dai contorni non ben definiti o mal descritto. Qualcun altro interviene e dato che il problema non è ben definito interpreta la questione generando...

posted @ mercoledì 24 agosto 2016 09:45 | Feedback (1)

“starters” e “finishers”

Non esistono persone sbagliate, esistono persone al posto sbagliato. Ci sono persone molto brave ad iniziare le cose e ci sono persone molto brave a portare avanti fino alla fine le cose iniziate da altri. È più difficile trovare una persona che sia brava, ho detto brava non in grado, a gestire da sola tutto la genesi e la produzione di qualche cosa. A mio modo di vedere questo è il motivo per cui è molto importante lavorare in team, conoscere molto bene le caratteristiche delle persone che compongono il gruppo e mixare le persone con caratteristiche complementari. ...

posted @ lunedì 22 agosto 2016 10:44 | Feedback (1)

“Everybody, all together, from the early on”

Sempre Luigi: Quoto, e rilancio con pre-sales e supporto all'utente finale ;-) DevOps e' l'anello tecnico di un processo di business piu' complesso, che include dinamiche economiche e politiche, oltre che puramente tecniche o funzionali. Ho avuto la fortuna di lavorare in aziende piccole, dove oltre a dover gestire la parte tecnica (sviluppo, ops), mi sono trovato dover vendere il prodotto e il progetto di turno, a discutere di requisiti in termini di costo e di opportunita', oltre che di fattibilita' tecnica, a parlare con il Direttore di...

posted @ mercoledì 17 agosto 2016 10:40 | Feedback (0)

Typora: Electron / take 2

Gli editor, decenti, di file Markdown languono nel mondo Windows. E no VS Code non è, ancora, un editor decente. Please Welcome Typora Typora è il primo che posso ritenere decente, grazie al mio collega John per la dritta, decente ovviamente in base all’uso piuttosto intenso che facciamo di Markdown. Il vero merito di Typora però è un altro, dimostrare quanto tecnologie come Electron possano essere una scelte vincente per abbracciare mondi che altrimenti rischiano di essere lontanissimi tra loro. Un’altra cosa che mi piace molto di Electron è che porta la qualità del...

posted @ venerdì 12 agosto 2016 09:39 | Feedback (0)

Services UI Composition - tecniche di recupero delle informazioni: IT/Ops

Nei nostri esperimenti con UI Compostiion fino a questo momento abbiamo dato per scontato che ci sia un solo modo per “parlare” con i servizi di backend, come potete immaginare non è proprio così. Di seguito l’elenco dei post che trattano l’argomento: SOA service model decomposition: il requisito SOA service model decomposition: un tentativo SOA service model decomposition: i modelli SOA service model decomposition: i servizi Services UI Composition: Recap Questo post sarebbe dovuto arrivare prima del...

posted @ giovedì 11 agosto 2016 09:53 | Feedback (0)

Nessuno dice che sia facile. Tutt’altro.

Nazareno, ma quanto parla Nazareno :-D, commenta: Tu vedi un lato della medaglia... io l'altro... continuo a vedere team che non si spostano da quello che conoscono e "accettano" di "morire di manutenzione" per evitare di uscire dalla loro zona di confidenza: "in VB6 usavo il Recordset foward-only, read-only... ma non trovo il Recordset in .NET" Come al solito "in media stat virtus"... non bisogna andare dietro solo al proprio ego, come non bisogna sedersi su quello che già conosciamo. Fino a un po' di tempo fa pensavo...

posted @ lunedì 8 agosto 2016 09:29 | Feedback (0)

DevOps significa (anche) condivisione delle conoscenze

Un giorno di qualche tempo fa in una conversazione tra dev: Utilizzando HTTP si possono scambiare facilmente informazioni tra servizi remoti. Il limite è che il client deve sapere innanzitutto dove si trova (IP) il server, problema risolvibile con un file di configurazione. Un altro problema è come possiamo inserire altre macchine in modo che le richieste vengano bilanciate. Diventa necessario far si che il client sappia quante e quali macchine server sono disponibili e quando sono disponibili. E così la conversazione continuava. Ora lasciamo perdere per un secondo l’assurdità della conversazione, DNS,...

posted @ sabato 6 agosto 2016 18:06 | Feedback (0)

DevOps e la prima linea

Possiamo generalizzare il commento di Luigi? Nello specifico mi riferisco a questo passaggio: I giovani facciamoli sbagliare e divertire (e lasciamogli manutenere i loro mostri, cosi' "imparano") ;-) È una delle cose che mi piacciono di più dell’esperienza DevOps che ho vissuto e per certi versi vivo a tutt’oggi: Prendi il team che produce il codice e rendilo reperibile (“on call” nel mio gergo) di notte, durante i fine settimana e durante le festività. Scommettiamo che la qualità cresce, i bug diminuiscono e i mostri pian...

posted @ venerdì 5 agosto 2016 10:44 | Feedback (2)

Sincero fastidio…

…per l’incapacità del dev di immedesimarsi nei bisogni dell’utente. Sto generalizzando ovviamente. Troppe volte mi ritrovo a chiedere il perché di certe scelte e troppe volte la risposta è: non lo so, mi piaceva così. Mi spiegate a che diavolo serve? Sinceramente, avete così bisogno di soddisfare il vostro ego personale da introdurre una valanga di problemi? Perché ovviamente ogni volta che “consegniamo” qualcosa che nessuno ci ha chiesto poi dobbiamo fare manutenzione, dobbiamo fissare bug perché ovviamente qualcuno userà quel qualcosa come non abbiamo previsto, dobbiamo decidere come deprecare la cosa quando questa ci scoppierà in...

posted @ mercoledì 3 agosto 2016 12:26 | Feedback (3)

Backlog e reminder

Sempre il buon Nazareno: domanda: reminder diciamo che è una sorta di backlog con una data a in cui guardarci... e dopo che ci hai guardato? Insomma hai un calendario delle cose da fare nei prossimi giorni? Perchè questo non c'è nella tua definizione di calendario qui sopra... o sbaglio? Come dicevo uso principalmente i reminder di Google Inbox, ma poco importa il tool secondo me. Diciamo che quando penso al concetto di reminder mi vengono in mente le seguenti possibilità: Voglio ricordarmi un’idea o di qualcosa che prima o...

posted @ martedì 2 agosto 2016 14:35 | Feedback (1)

“Get things done”: le mie prime due fasi.

Nazareno chiede: Una domanda rispetto l’agendina delle attività: Ma tu ci scrivi solo le attività della giornata o tutte le attività in backlog e poi spunti e quello non fatto passa al giorno dopo? C’è una logica di prioritizzazione delle cose? O questo va su altri “strumenti”? Insomma è una sorta di “cose da fare” come nella tecnica del pomodoro ma senza pomodori o un backlog sempre in divenire o un mix? “Getting things done” è una tecnica arcinota che io non uso assolutamente :-) Il Pomodoro è altrettanto una tecnica arcinota che io non uso...

posted @ lunedì 1 agosto 2016 09:53 | Feedback (3)