Welcome

This is the generic homepage (aka Aggregate Blog) for a Subtext community website. It aggregates posts from every blog installed in this server. To modify this page, look for the Aggregate skin folder in the Skins directory.

To learn more about the application, check out the Subtext Project Website.

Powered By:
Powered by Subtext

Blog Stats

  • Blogs - 714
  • Posts - 31424
  • Articles - 310
  • Comments - 98210
  • Trackbacks - 228553

Bloggers (posts, last update)

Latest Posts

“no documentation”…WAT?

Leggo questo tweet:

image

che rimanda a questo post e sinceramente resto basito (non trovo un altro termine che sia abbastanza politically correct). Davvero c’è gente che comprerebbe un’autovettura di cui nessuno abbia mai testato che gli airbag funzionino o che il serbatoio non prenda fuoco? Oppure c’è gente che si fiderebbe a farsi operare da un chirurgo che ha preso la laurea su Facebook? - oh, wait… ;-)

Potremmo aprire, e mi piacerebbe molto farlo, un dibattito su quale metodologia di test (unit, TDD, test first, acceptance, end-to-end) sia migliore in quale contesto. Ma mai e poi mai mi sognerei di pensare che testare sia totalmente inutile.

Allo stesso modo trovo molto valore nella documentazione, vi dirò di più trovo molto valore nello scrivere la documentazione. È una forma di testing, spesso ci ritroviamo a scrivere documentazione prima dell’implementazione stessa. L’operazione di scrittura, comprensiva di esempi completi e snippet di codice, impone di mettersi nei panni dall’utilizzatore finale provando in prima persona l’ergonomia di quello che si sta per produrre.

Poi…se vogliamo aprire un dibattito sull’utilità di sta roba:

xml-doc

avete vinto facile, non serve a nulla.

In generale penso (pensiamo) che documentare un’API in maniera pappagallesca è decisamente poco utile, farlo in maniera non pappagallesca è pressoché impossibile.

La documentazione che ha valore è ben altra cosa, è anche molto più difficile da scrivere, ma il gioco vale sicuramente ben più di una candela.

posted @ 9/14/2017 9:24 AM by Mauro Servienti

Devops Heroes 2017

Anche quest’anno avrò l’onore e il piacere di essere a Devops Heroes, edizione 2017, nuovamente a Parma, ma stavolta di venerdì. Ci sarà un attesissimo ospite: Martin Woodward, Principal Program Manager per DevOps in Microsoft Corporation ed HP Enterprise.

Io nel mio piccolo mi cimenterò nel raccontarvi come funziona ad oggi il processo di sviluppo, dall’idea al deploy, in Particular.

Dall'idea al deploy: un lungo viaggio che passa per GitFlow e SemVer

Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi. Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog? Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.

Maggiori informazioni: http://milestone.topics.it/events/devops-heroes-2017.html

Vi aspettiamo numerosi!

posted @ 9/12/2017 9:01 AM by Mauro Servienti

Polly



http://www.thepollyproject.org

Polly is a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback in a fluent and thread-safe manner. Polly targets .NET 4.0, .NET 4.5 and .NET Standard 1.1

posted @ 9/5/2017 5:48 PM by Alessandro Gervasoni

A Wiki for Team Services and TFS

posted @ 9/5/2017 4:39 PM by Alessandro Gervasoni

What's new in TypeScript

posted @ 8/27/2017 3:27 PM by Alessandro Gervasoni

Quanto mi piace il nuovo project system di Visual Studio 2017

Visual Studio 2017 introduce un nuovo project system, i famosi file “proj” a cui siamo abituati. Il nuovo modello è obbligatorio per i progetti .NET Core/.NET Standard mentre è opzionale, e purtroppo la conversione è a manina, per tutti (o quasi) i tipi di progetto tradizionali.

Perché mi piace tanto?

Prendiamo come esempio la persistenza di NServiceBus su RavenDB, questa è la diff tra il prima e il dopo: –187 righe. Devo aggiungere altro?

Un’altra cosa che mi piace molto è che potete eliminare il file “packages.config” perché i pacchetti Nuget diventano first class citizen tra le reference del progetto. Inoltre finalmente potete costruire un pacchetto Nuget direttamente in fase di build senza pressoché fare nulla. Finalmente tutti i file presenti in una directory sono inclusi per definizione in un progetto, portando praticamente a zero le merge e le rogne in fase di evoluzione massiccia di un progetto.

Ultima cosa che trovo fantastica è che potete esternalizzare in file “Directory.*.proj” parti di configurazione che sono comuni a più progetti che vivono nella stessa folder, o solution. Mi piace poco invece la sintassi usata per escludere contenuti, me ne farò una ragione, anche se è veramente triste.

Provatelo ne vale la pena, vale anche la pena investire tempo per convertire progetti esistenti perché non siete obbligati a passare a .NET Core, l’unico vincolo è Visual Studio 2017.

posted @ 8/22/2017 5:16 PM by Mauro Servienti

Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

376102567_46d54e403f_b

Mi è capitato spesso di assistere a situazioni in cui ci fossero forti pressioni “dall’alto” perché un problema venisse risolto  e venisse risolto alla svelta. Il team si dannava, faceva le notti, accumulava frustrazione, per poi scoprire che la soluzione implementata non era quella desiderata.

L’inghippo, se di inghippo e non di miopia si può parlare, è abbastanza semplice: La fretta genera l’errore in ogni cosa.

Qualcuno, spesso qualcuno in alto nella gerarchia e guarda caso anche molto distaccato dal mondo reale, lamenta un problema e data la sua posizione di potere ne pretende la soluzione. Nella catena di schiavi nessuno ha il coraggio, se lo sa, di dirgli che quello non è il vero problema ma è solo il sintomo. E il team si ritrova a fare le notti.

In retrospettiva posso dire che noi spendiamo tantissimo tempo, dato un presunto problema, per comprendere a fondo se quello è veramente il problema da risolvere o se invece è solo un sintomo.

Identificare il vero problema da risolvere innesca due cose interessanti:

  • Molte meno discussioni interne perché una volta identificato il problema vero siamo tutti orientati nella stessa direzione; tant’è che uno dei metri di misura che ci fanno dire “forse è il problema sbagliato” è quando il dibattimento sulle soluzioni si trascina, e spesso le soluzioni proposte sono diametralmente opposte.
  • La soluzione si rivela essere una soluzione di (più) lunga durata e questo gratifica, con tutto quello che ne consegue.

Prima di iniziare a pensare ad una soluzione concentratevi sul problema.

Post in questa (mini) serie:

posted @ 8/17/2017 8:01 AM by Mauro Servienti

Windows 10 - Controlled Folder Access

controlled-folder-access

Una* delle macchine che uso quotidianamente per lavoro è nel programma insider, slow ring, e da un po’ è stata aggiornata a Creators Update. Una delle feature che aspettavo era il “Controlled Folder Access”.

Quello che potete fare è definire una o più cartelle (e di conseguenza le relative sotto-cartelle) come “controllate”. Questo fa si che fondamentalmente solo i programmi autorizzati possono apportare modifiche a quelle cartelle. Ovviamente la cosa che salta subito all’occhio è che un ransomware non risulta tra i programmi autorizzati e quindi problema risolto.

Occhio perché al momento non è tutto oro quel che luccica

La cosa funziona e funziona bene. Microsoft dichiara, nella UI di Defender, che Windows contiene una lista di applicazioni note che sono autorizzate a prescindere. Ad esempio sulla mia macchina Visual Studio Code fa tutto quello che deve fare senza problemi, Excel no, Word si. Misteri della fede e delle versioni insider, quindi non è che mi possa lamentare.

Ma non è questo il problema. La cosa noiosa è che le applicazioni si comportano in maniera alquanto strana, rendendo difficile anche per l’utente esperto capire, cosa sta succedendo.

Excel, ad esempio, apre i file senza problemi ma poi fallisce miseramente con un errore totalmente scorrelato al momento del salvataggio. Il problema di fondo è che Excel non essendo tra le applicazioni autorizzate sulla mia macchina, non riesce a creare il file temporaneo necessario per gestire le modifiche e quindi in seguito non riuscirà a salvare.

Non ho fatto esperimenti, ma presumo che il sistema operativo rimbalzi l’applicazione con un errore ben preciso, che al momento l’applicazione semplicemente non sa gestire. Nel mio piccolo mi ero dimenticato di averle attivate e quindi ci ho messo un po’ a capire cosa stava succedendo.

L’altra cosa ad oggi noiosa è che non è sempre facile capire quale sia l’eseguibile che dovete autorizzare, se usate molti tool da command line succede che voi interagite con xyz.exe che a sua volta invoca un altro eseguibile che viene bloccato da Defender, generando il perfetto yak shaving.

* Una sola perché fidarsi è bene, ma… devo lavorare :-)

posted @ 8/15/2017 10:20 AM by Mauro Servienti

I “virgoletti” di WhatsApp…

…ci seppelliranno. Avete anche voi amici e/o parenti che sono ossessionati dai “virgoletti”, così li ho sentiti chiamare, di WhatsApp?

Per uno che la prima cosa che fa è disabilitare tutte le notifiche, compresi i virgoletti maledetti, e se non può disabilitarle rimuove l’app, capirete che è incomprensibile. Quello che mi meraviglia di più è che tutta questa gente è spesso nata in un tempo in cui non esistevano neanche i cellulari e se avevi bisogno di qualcuno o di qualcosa la cabina telefonica e il gettone erano il massimo che potevi desiderare. Se non ti rispondeva nessuno te ne facevi una ragione e andavi avanti. Oggi come oggi ci sono coppie che scoppiano o amicizie che vanno in frantumi perché le “virgolette blu”.

Sinceramente non ho parole, se non: provate ad essere irreperibili e felici. È agosto, fa caldo, tra qualche giorno torno a parlare di cose normali e la pianto con gli sproloqui ;-)

posted @ 8/14/2017 7:45 AM by Mauro Servienti

[OT] xkcd


A webcomic of romance,sarcasm, math, and language.

https://xkcd.com

posted @ 8/8/2017 2:10 PM by Alessandro Gervasoni

Rider : New cross-platform .NET IDE

https://www.jetbrains.com/rider

JetBrains Rider is a new cross-platform .NET IDE based on the IntelliJ platform and ReSharper.

posted @ 8/8/2017 10:29 AM by Alessandro Gervasoni

Ipocrisia 2.0

image

Lo lascio qui, così come riflessione.

  • Capezzoli no, razzisti si
  • Capezzoli no, nazifascisti si
  • Capezzoli no, Salvini si (è una specie speciale dei due punti precedenti)
  • Capezzoli no, fakenews come se non ci fosse un domani

Marchino Zuckerbino…sei ridicolo e anche un po’ bigotto.

posted @ 8/8/2017 7:02 AM by Mauro Servienti

Processi (tanti), non risultati.

Parmigiano_reggiano_factory

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

Eliminate la fortuna dall’equazione

Senza processi i risultati possono solo essere controllati dalla fortuna, se siamo fortunati il formaggio quest’anno viene buono altrimenti buttiamo via tutto e imprechiamo contro qualche cosa a caso cercando di trovare un colpevole.

Io il formaggio non l’ho mai fatto, in compenso sto lavorando per essere in grado di percorrere una lunga distanza in bicicletta (in una sola uscita ovviamente :-P ). Non ci si improvvisa ciclisti e neanche formaggiai. C’è una scienza dietro la lunga e complessa preparazione per percorrere lunghe distanze in bicicletta, e non basta improvvisarsi ciclisti, uscire tutti i giorni e semplicemente pedalare.

Le ricette

I processi aziendali sono le ricette per fare il formaggio o le tabelle di allenamento per andare in bicicletta. Un processo vi permette di:

  • eliminare fortuna dall’equazione
  • evitare la caccia alle streghe quando le cose vanno male

Ovviamente i processi non devono essere scolpiti nella pietra, ma quando le cose vanno male ci possiamo concentrare su cosa non ha funzionato nel processo, cosa possiamo modificare in quello che abbiamo fatto affinché il problema non si ripresenti. I processi vanno quindi oliati e manutenuti nel tempo, adattandoli alle nuove esigenze e ai nuovi scenari.

Post in questa (mini) serie:

posted @ 8/2/2017 9:37 AM by Mauro Servienti

"Learning is working"

education-1959551_1280

In un commento su LinkedIn al post Il lavoratore remoto: la flessibilità, diritto e un dovere, Massimo chiede:

ciao, ti seguo da tempo, mi spieghi come fai ad essere sempre aggiornato, lavorando tutto il giorno?

Ammetto che la domanda mi ha fatto specie, è un problema che non mi sono mai posto. Semplicemente studio, e dedico anche molto tempo allo studio. Come dicevo nella mia risposta probabilmente, perché non l’ho mai misurato, dedico circa una giornata alla settimana allo studio.

Incuriosito comunque dalla domanda sono andato a curiosare tra le nostre policy se c’era qualcosa al riguardo, ed ho trovato questo:

Learning is working: Further education is considered part of your job and not your free time. Use our flexible hours and free time off policy to find a time that works for you.

Direi che non devo aggiungere altro. Fa parte di quelle cose che aiutano a creare un ambiente in cui fallire non è un problema, avere il tempo di prepararsi è un requisito fondamentale per affrontare qualsivoglia problema.

posted @ 7/31/2017 8:21 AM by Mauro Servienti

Meet{cast} - Advanced .NET Frontend - #AperiTech

image

Con mio grandissimo piacere a settembre sarò a Roma ospite, insieme a Michele Aponte, di un AperiTech organizzato dai ragazzi di dotNetPodcast, si parlerà principalmente di front-end.

Io nel mio piccolo vi racconterò come approcciare l’interfaccia utente in un mondo basato su Microservices costruendo un reverse proxy con .NET Core, quindi:

  1. se vi interessa il mondo Microservices…
  2. …o se non ve ne frega nulla ma siete curiosi di scoprire qualche dettaglio sugli internals di .NET Core…

Venite a trovarci :-)

Michele invece mi sa che darà vita definitivamente ad Inception, generando un framework per generare una SPA basata su un framework. Forza gente, accorrete numerosi.

Ovviamente, dopo perché durante dicono che faccia brutto ;-), che la gricia sia con noi.

posted @ 7/26/2017 10:23 AM by Mauro Servienti

ownCloud

https://owncloud.org

Access & share your files, calendars, contacts, mail & more from any device, on your terms

posted @ 7/25/2017 5:15 PM by Alessandro Gervasoni

Fiducia, fiducia e ancora fiducia.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

Abbiamo parlato (male) di manager e (bene) di leader, di quanto le metriche possano essere problematiche e di come le persone debbano lavorare in team e non sole.

La domanda che probabilmente in molti (spesso manager) si fanno è:

come posso non gestire le persone, smettere di misurarle e controllarle e in più lasciarle lavorare in gruppo ovviamente riducendo la produttività, perché in gruppo ci si imbosca meglio?

Fidandosi

Costruendo un percorso di assunzione che miri a cercare le persone giuste, persone che condividono i valori dell’organizzazione, persone mature e responsabili e concedendo loro fiducia dal primo momento. La fiducia viene sempre ripagata, e in un contesto l’organizzazione stessa si auto controlla, facendo emergere e correggendo quei comportamenti che sono, o possono essere, lesivi per l’organizzazione stessa.

L’organizzazione si rende conto che i vantaggi sono talmente tanti, e i benefici pure, che lasciarsi sfuggire tutto questo bengodi sarebbe semplicemente stupidissimo.

Post in questa (mini) serie:

posted @ 7/24/2017 11:33 AM by Mauro Servienti

BabylonJs

https://www.babylonjs.com

A complete JavaScript framework for building 3D games with HTML5, WebGL, WebVR and Web Audio

posted @ 7/24/2017 10:30 AM by Alessandro Gervasoni

Il lavoratore remoto: la flessibilità, diritto e un dovere

Se lavorate da remoto e state facendo 9/18 con 1 ora di pausa pranzo state sbagliando tutto. Il lavoratore remoto è diverso, deve essere diverso e deve giovare dell’essere diverso.

Forse qualcuno avrà notato che ho cambiato la cadenza dei post, non ce ne sono più il venerdì. Perché? Semplice sono in ferie tutti i venerdì fino a fine agosto. Anche quest’anno per ora niente ferie lunghe e consecutive, ma lo stress e la fatica si accumulano comunque, la flessibilità che ho mi permette con tranquillità di prendermi 14 venerdì di ferie.

Allo stresso tempo visto che fa caldo, troppo caldo perché le mie sinapsi producano qualcosa di intelligente, la flessibilità di cui sopra mi permette di cambiare la mia giornata e spaccarla in due in maniera completamente diversa. La mattina inizia presto, 6.30, finisce verso le 11, piscina, piscina, piscina. Il pomeriggio inizia tardi, verso le 15.30 e finisce tardi.

Nel nostro caso specifico ottengo il vantaggio che ho più sovrapposizione con i colleghi australiani e americani, ma è un dettaglio. Il tutto è permesso dal fatto che la struttura organizzativa e i processi sono pensati con la flessibilità come uno dei punti cardine, nel nostro caso perché è un requisito ovviamente, ma nel vostro?

Se siete un lavoratore 100% remoto e siete obbligati al 9/18 con 1 ora di pausa pranzo, fatevi delle domande, probabilmente c’è qualcosa di profondo che non va e quella è la punta dell’iceberg, o l’effetto collaterale. Uno scenario potrebbe essere che l’organizzazione non è strutturata per il lavoro remoto, ma le percepisce solamente come un benefit (se volete leggere contentino fate pure ;-) ) e come tale lo tratta.

posted @ 7/19/2017 11:24 AM by Mauro Servienti

Le persone vanno unite, non divise.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

Eroi solitari

Ho spesso la sensazione che si tenda a promuovere una cultura in cui l’eroe solitario, che arriva e risolve tutto, sia la cosa da favorire. Certo dal punto di vista dell’eroe è bello pensare di essere la figura indispensabile, senza la quale non funziona nulla. Quello con il numero 11 sulla maglia. Allo stesso tempo l’eroe è il perfetto capro espiatorio, se ha successo verrà osannato, ma se fallisce abbiamo la figura su cui puntare il dito, quello da punire e castigare.

Cui prodest?

La mia esperienza dice che tutto ciò è figlio di una cultura che premia, o punisce, il risultato. Una cultura focalizzata sul cosa si ottiene e non sul come. In tutto ciò ovviamente il manager, quello nell’accezione negativa, ci sguazza con gioia perché in questo modo detiene potere.

Se al contrario facessimo lavorare, sempre, le persone in team (diciamo in tre)? cosa otterremmo?

  • Diversità di pensiero
  • Lo stimolo a trovare un modo per raggiungere il consenso
  • La nascita, spesso inaspettata, di nuovi leader
  • La scoperta che alcune persone sono dei perfetti avvocati del diavoli
  • Lo stimolo a crescere e alla sfida costante

Forse la cosa più importante è la spersonalizzazione della colpa, se sei solo e fallisci è per forza colpa tua, se sei un team e fallisci è colpa di tutto il team. Ebbene si, magari la colpa è di uno solo del team, ma gli altri lo hanno lasciato fallire portandosi a casa la loro fetta di responsabilità. Un team sano e coeso fa di tutto per auto-correggersi.

Ovvio che siamo in oligarchia, tutto ciò spaventa molto.

Post in questa (mini) serie:

posted @ 7/17/2017 9:23 AM by Mauro Servienti

Latest Images

From miscellaneous
From miscellaneous
From miscellaneous
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini