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, edit the default.aspx page in your Subtext installation.

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

Powered By:

Blog Stats

  • Blogs - 715
  • Posts - 31056
  • Articles - 310
  • Comments - 105973
  • Trackbacks - 591060

Bloggers (posts, last update)

Latest Posts

Kanban Split Column

Finalmente in Visual Studio Online sono stati introdotti alcuni miglioramenti alla Kanban Board, che per lungo tempo era stata lasciata senza sensibili miglioramenti. In questo ultimo update di VSO è stato introdotto una funzionalità realmente fondamentale, che aumenta di molto la possibilità di usare realmente la Kanban Board in TFS/VSO.

Il cambiamento di cui sto parlando è l’introduzione delle Split Columns, ovvero la possibilità di suddividere ogni colonna in due sotto-colonne, rispettivamente Doing and Done. Vediamo il perché questa funzionalità è cosi importante.

Si parte da un presupposto: Kanban è un processo PULL, in cui ogni stadio decide di prendere in carico una card dallo stato precedente, se e solo se non ha raggiunto il suo limite e se tutte le regole sono soddisfatte (regole aggiuntive e Definition of Done). Questo è il segreto e la base su cui poggia Kanban, ogni stadio inizia a lavorare su un task solamente se ha modo di farlo. Questo viene fatto per evitare ingorghi nel processo e per massimizzare il flusso. Lo strumento principale di Kanban è la Board, che deve permettere immediatamente di individuare i problemi affinché il team possa affrontarli.

Ora analizziamo la situazione seguente:

image

La situazione rappresentata ci dice che: le colonne di Analysis e Committed sono attualmente piene (3/3), quindi non è possibile aggiungere del Work In Progress a nessuna delle due colonne. La domanda che ci si pone è: lo stadio di Analysis non può prendere in carico nessun nuovo item, ma i tre item che sono attualmente nella colonna sono stati terminati o no?

La risposta alla domanda precedente è di fondamentale importanza. Supponiamo i due casi estremi. Caso A: i tre item nella colonna Analysis sono tutti "in progress” questo significa che la colonna Analysis è in stato di pieno regime. Caso B: i tre item nella colonna Analysis sono completati e pronti per lo stadio successivo, questo significa che la colonna Analysis è paralizzata, dato che non può prendere in carico nuovo lavoro fino a che la colonna successiva (Committed) non prende in carico ancora del lavoro. Purtroppo dalla Kanban Board precedente è impossibile discernere i due casi.

Senza entrare nei dettagli, stiamo toccando quella che è chiamata teoria delle code che stabilisce modelli matematici per predire l’avanzamento in una catena di processi. L’identificazione delle code è fondamentale in Kanban, ed è una delle ragioni principali per l’adozione stessa del metodo.

Il metodo Kanban ha come scopo la massimizzazione del flusso ed in questa ottica l’individuazione delle code è un’operazione di massima importanza.

D’altra parte, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è: Maximize Throughput while Minimizing Inventory and Operating Expense. La declinazione nello sviluppo software non appare sempre semplice, se da una parte è chiara la parte di minimizzare le Spese (Operating Expenses), si può anche intuire la massimizzazione del flusso (Maximize Throughput, concetto su cui tornerò in un post successivo), è difficile capire come minimizzare lo stoccaggio (Minimizing Inventory), dato che alla fine il codice non occupa spazio :).

Kanban ci aiuta a rispondere a questo problema adottando la tecnica dello split column. Nel nostro account VSO, se premiamo il Customize column troviamo una nuova opzione per le colonne.

image

Quello che accade è che ogni colonna viene ora suddivisa in due sotto-colonne, Doing e Done; questo ci permette di iniziare ad individuare le code nel nostro sistema. Vediamo allora come sarebbero rappresentati i due casi precedenti adottando questa nuova funzionalità. Il CasoA: sarebbe cosi rappresentato

image

è chiaro che il sistema sta larvando bene, tutte le colonne sono impegnate e a pieno regime. Il CasoB avrebbe invece una rappresentazione molto differente.

image

Si è creata una coda tra gli stati di Analysis e Committed, dato che abbiamo la colonna Analysis bloccata dal fatto che il lavoro nella colonna Committed non sta proseguendo, per questo non vengono prese in carico (pull) le card terminate in Analysis e questo fa si che la colonna Doing di Analysis sia vuota e bloccata. Tutte le card che sono nella colonna Dona rappresentano infatti card in Coda per lo stadio successivo e possono essere paragonate a quello che Eliyahu Goldratt chiama Inventory in “The Goal”.

Se siamo d’accordo che è necessario minimizzare le code ed evitare che il lavoro si accumuli nelle colonne “done”, senza questa funzionalità, è impossibile capire dalla nostra Kanban Board se siamo nel CasoA oppure nel CasoB e si perde una informazione di vitale importanza.

Un altro valore secondario dello split column è permettere in maniera semplice allo stadio successivo, di capire quali card dello stadio precedente possono essere prese in carico. Senza la colonna Done infatti, quando si libera uno spazio nella colonna Committed, non è ben chiaro dalla Board quali card dello stadio precedente (Analysis) possono essere prese in carico, perché non si ha la distinzione tra ciò che è in corso d’opera e ciò che invece lo stadio precedente ha completato.

Gian Maria.

posted @ 25/02/2015 18.01 by Gian Maria Ricci

“This eagerness to change”

E insomma, un anno fa pubblicavo il mio ultimo post chiedendomi, tronfio come un vero bauscia sa/deve essere, in quale modo avremmo potuto migliorare l’anno successivo. E allora, quest’anno, io e Daniele siamo partiti da un principio ispiratore: “diversity”. Diversity perchè:

  • se il fenomeno startup ha dimostrato di poter essere un game changer in tema sia di scelte tecnologiche sia di approccio allo sviluppo del software (“va veloce e spacca tutto”, ci disse Marco)
  • se la track “business” inserita in agenda un anno addietro ha riscosso un riscontro che ci ha fatto capire che potevamo toglierla dalla “riserva protetta” e renderla un first class citizen anche se i temi sono (apparentemente) slegati dallo sviluppo software in senso stretto
  • se la partecipazione alla CFP di “signorine & giovanotti” cresce ogni anno ed è un toccasana in un settore storicamente prettamente maschile, con alcuni esemplari (io tra questi) per datare i quali qualcuno potrebbe proporre il Carbonio14
  • se anche chi ci ospita (e s[u|o]pporta) da anni mette la barra a dritta e avanti tutta verso Linux e OS X

Beh, allora il cambiamento è l’unica strategia evolutiva sensata (e qui la mia verve agilista va in sollucchero). E quindi:

  • Volevamo le startup? Ecco Xmetrics, che ci viene a raccontare come anche in Italia un tecnico possa avere una idea, capire che la sua preparazione tecnica non è condizione sufficiente per “farcela”, imparare la lezione ed a questo punto trovare un investitore (anche) grazie al quale trasformare la propria idea in realtà. Ah si, ed avere come testimonial un campione olimpico, scusate se è poco. Io per avere una startup finanziata con oltre 1M $ che abbia per testimonial Martin Gore farei carte false, per dire.
  • L’anno scorso abbiamo inserito i “pezzi grossi” in agenda? E allora quest’anno abbiamo pescato dall’altro lato della pozza e portato in Italia un Senior Director di Microsoft Corporation. Ok, sostanzialmente ha accettato poichè interessato a mangiare decentemente per una settimana più che per il prestigio del nostro evento, ma questo è un trascurabile dettaglio di implementazione, oltretutto dotato di access modifier “private” Sorriso
  • Vogliamo scongiurare il ricorso al Carbonio 14? Ed allora anche le tematiche devono guardare avanti e prendere atto di quanto potente sia ormai il “lato consumer della Forza” ed il suo impatto anche sugli scenari applicativi “tradizionali” e quindi in agenda abbiamo: IoT, wearable, Kinect, Docker, Unity3D, Enterprise UX… Oh, io la sessione su Microsoft Band non me la perdo Sorriso

Questo (ed altro) riuscendo però, a nostro avviso, a non snaturarci: .NET, C++, cloud computing, NoSQL, Xamarin, etc sono lì come sempre in fondo, ad esempio, di “roba” come Mono ne parliamo da prima che fosse “cool” farlo.

Cerchiamo, semplicemente, di rendere il take away dei Community Days utile sia nell’immediato sia in prospettiva. Ci abbiamo provato anche quest’anno, venite e diteci se ci siamo riusciti.

Ci vediamo ai Community Days 2015?

Tag di Technorati: ,

posted @ 27/02/2015 9.31 by Andrea Saltarello

Community Days 2015

Ripetete con me “Community Days 2015”:

  • 3 giorni;
  • Circa 90 speaker;
  • Un’agenda incredibile;
  • Totalmente gratuito;

Ci sarò anche io, anche quest’anno e anche quest’anno sono onoratissimo di essere parte di quest’esperienza e anche quest’anno blatererò di qualche cosa :-)

Nello specifico parlerò di database documentali, non uno in particolare questa volta. Accorrete numerosi i posti vanno a ruba!

.m

posted @ 24/02/2015 10.25 by Mauro Servienti

Some love to Kanban Board in TFS

Nell’ultimo update di VSO che è stato effettuato ieri (http://www.visualstudio.com/news/2015-feb-18-vso) sono finalmente state fatte importanti modifiche alla Kanban Board, che era rimasta un po ferma da troppo tempo a mio avviso.

La prima novità è che è possibile aggiungere gli item direttamente dalla board, ma sicuramente la funzionalità piu succosa è la divisione delle colonne in doing e done. Non starò qui a sottolineare l’importanza di questa funzionalità, dato che senza la possibilità di capire quali Item sono realmente fatti e sono pronti per essere presi (pull) dalla colonna successiva, la Kanban board ha poco valore.

Nell’upgrade vi sono anche altre novità, tra cui la possibilità di assegnare piu persone alle test suites, e l’annuncio che le funzionalità di Application Insights saranno migrate nel nuovo portale di azure. Il nuovo link di riferimento per Application Insights è quindi il seguente: http://azure.microsoft.com/en-us/services/application-insights/

Happy VSO e buon fine settimana. Smile

posted @ 20/02/2015 19.37 by Gian Maria Ricci

ASP.NET Identity 2.1

Non nego che sia una bella novità del mondo .net ma la mancanza di informazioni al riguardo è molto alta. Ho impiegato 3 giorni per riuscire ad utilizzarla tra l'altro in un modo molto base. Con il progetto web di default si include già troppo codice che poi va commentato o scommentato. Tutti i messaggi di errore sono hard coded e non sono localizzati... Ho dovuto scaricare da nuget i samples per capire cosa non andava nel mio progetto. Gli stessi samples non funzionano se portati all'interno di un proprio progetto: usermanager e rolemanager nell'initializer vanno recuperati direttamente dallo store invece che dall'owin context. Inoltre non è molto chiaro che non posso creare un mio context ma devo utilizzare l'applicationdbcontext già presente... La ciliegina sulla torta? User.IsInRole(...) che restituisce sempre false. Ma per risolvere questo non vi fornirò alcuna soluzione qui. Inutile provare le soluzioni del lazyloading, spostare codice dal global.asax, commentare i dispose (che nei samples non ci sono), abilitare o disabilita il rolemanager nel web.config, cambiare l'entity framework default factory... vi posso solo dire che centra con il voler rinominare le tabelle relative al login ;)

posted @ 19/02/2015 19.30 by Emanuele Prato

DataDog

Interessante tool di monitoring
https://www.datadoghq.com

posted @ 19/02/2015 8.36 by Alessandro Gervasoni

Code search–In preview su VSO

Il blog di VS ALM ha appena pubblicato questo post in cui viene mostrata una nuova funzionalità, ancora in limited preview, presente su Visual Studio Online, il Code Search.

In un progetto è spesso di vitale importanza poter effettuare una ricerca nel source control, alla ricerca di una particolare porzione di codice, oppure di una classe con un particolare commento, etc. Le nuove funzionalità di ricerca introdotte in VSO permettono infatti di effettuare una ricerca semantica, in cui I risultati vengono suddivisi in base alla porzione di codice dove viene effettuato il match. Ad esempio I risultati ci permettono di dire se il testo cercato è presente in un commento, oppure in una dichiarazione di classe Etc.

E’ anche possibile andare a richiedere direttamente un filtro per restringere lo “scope” della ricerca, Es: class: per ricercare nelle dichiarazioni di classe, oppure comment: per cercare all’interno di un commento. La lista completa è presente nel post del blog sopracitato e la riporto per comodità.

image

Attualmente, data la natura di preview di questa funzionalità, esistono delle limitazioni. Il servizio è disponibile solamente per gli account del Nord America, e per progetti che utilizzano Git; la ricerca viene inoltre fatta solamente nella master branch ed il supporto ai linguaggi è per ora disponibile per C#, C e C++.

Gian Maria.

posted @ 17/02/2015 9.08 by Gian Maria Ricci

stackshare.io

Discover, discuss, and share the best dev tools and services
http://stackshare.io/

posted @ 16/02/2015 8.48 by Alessandro Gervasoni

Underscore.string

Javascript lacks complete string manipulation operations. Underscore.string

Es

count(string, substring) => number

count("Hello world", "l"); // => 3 

posted @ 13/02/2015 9.40 by Alessandro Gervasoni

visualcaptcha

alternativa ai soliti sistemi captcha

http://visualcaptcha.net/

posted @ 11/02/2015 8.37 by Alessandro Gervasoni

Mi sono comperato un iPad mini e…

Per l’esattezza un iPad Mini 2, solo Wi-Fi da 16Gb, insomma il minimo indispensabile per spendere poco, si fa per dire, e sperimentare con decenza. Siccome sono anche un felice possessore dell’ormai silverlighted “Surface RT” mi permetto di fare un confronto tra i due.

Non vuole essere una disanima esaustiva e neppure un tentativo di lanciare un flame, quindi non fatelo nei commenti perché il mio alto senso della democrazia vi censurerà subito :-) inoltre devo ammettere che faccio ancora fatica a dare un senso allo strumento tablet, oltre alla lettura quotidiana mattutina :-P, sto pian piano imparando ad usarlo per portare a compimento qualche task lavorativo e poco più, non gioco perché non mi interessa farlo, trovo decisamente inutili la quasi totalità delle “App” (ne ho 4 installate e ne uso 2).

Apple iPad mini 2

Pro

  • Funziona sempre, iOS praticamente non esiste, è quasi impercettibile e per l'utente normale è veramente una gran cosa, il tablet coincide con le App;
  • Ci sono veramente App per tutto, questo non vuol dire di certo che siano di qualità;
  • Bello il tentativo fallito di concentrare i settings delle App in un posto solo insieme ai settings di tutto il resto;
  • Il form-factor, trovo più naturale l’uso in verticale rispetto all’orizzontale wide;

Contro

  • La tastiera...maiuscole/minuscole anyone? Capire come si sta scrivendo è quasi impossibile :-) Inoltre la gestione delle tastiere multilingua/multiple è fatta da un troglodita;
  • Le App fanno quello che vogliono e l'utente è molto spaesato, guideline inesistenti o totalmente ignorate; Si vede che molte sono pensate per iPhone dove arrivi con il pollicione un po’ ovunque mentre su iPad sei obbligato a strani contorsionismi con le dita;
  • Notification center pressoché inutile, come quello di OSX del resto;
  • Molte App fanno veramente cagare, quelle blasonate ci sono e sono belle, ma spesso solo belle, il resto è tanta tanta povertà;
  • Trovo il passaggio tra App attive veramente scomodo (doppio pigiamento del bottone hardware + scorrimento);

Microsoft Surface RT

Pro

  • Uniformità del comportamento delle App, guideline imposte dallo store;
  • Gesture, una volta imparate, molto più funzionali soprattutto per il passaggio tra App attive;
  • App side by side: killer :-)
  • Proattività delle tile e in generale gestione dell'home screen anni luce avanti;
  • Il navigation stack è gran cosa;

Contro

  • Windows...che due palle, la presenza imperante del sistema operativo rende il tutto fastidioso per l’utente finale;
  • ogni tanto si blocca, ogni tanto fa quello che vuole, spesso è lento, poi c’è Windows update, poi fai reboot…;

La tanta decantata batteria? circa 8 ore su entrambi :-)

posted @ 09/02/2015 10.47 by Mauro Servienti

Visual Studio 2015 ASP.NET 5, project name e l'errore "install Couldn't read dependencies"

Visual Studio 2015 ha introdotto una nuova modalità di gestione delle librerie e degli asset client side (javascript, typescript, coffescript, css, less...) di un progetto ASP.NET: infatti da questa versione, l'ide si affida ad un tool molto diffuso e apprezzato tra le community open source: Bower.

Bower è un package manager scritto in nodejs, che ha il compito di scaricare e gestire le librerie client side (per quelle server side rimane valido NuGet). Come tutte le librerie basate su nodejs, la modalità di default d'installazione è tramite il package manger di nodejs: npm.

Qual'è il problema?

 Quando creiamo un nuovo progetto Visual Studio 2015, dal template 'ASP.NET 5 Starter Web' e diamo un nome contenente un carattere accentato, scopriremo che:

  • la build fallisce e apparentemente non si trova l'errore
  • da solution explorer il nodo "Bower" sotto le "dependencies" (che dovrebbe contenere le librerie client del template come jquery, bootstrap...) è vuoto e non è abilitata l'opzione "Restore Packages"
  • da solution explorer il nodo "NPM" sotto le "dependencies" indica che i packages: grunt, grunt-bower-task non sono stati scaricati

Mettendo insieme questi indizi, e soprattutto aprendo la finestra "Package Manager Log", si trova un errore simile a questo:

Visual Studio infatti scarica le dipendenze dei tools (tra cui bower) usando il comando npm install. Quest'ultimo per funzionare ha bisogno che nella directory corrente ci sia il file package.json (file aggiunto automaticamente dal template di Visual Studio) il quale contiene alcune informazioni tra cui l'elenco delle dipendenze (un po' come il file packages.config di NuGet) e il nome del progetto; ecco il problema: npm esegue una validazione del nome (notare l'errore: 6 error Error: Invalid name: "ragù") e se questo non super la validazione, il comando install fallisce senza scaricare i tool (tra cui bower), e gli asset client del progetto (tramite bower).

Indagando un po' ci imbattiamo nella funzione ensureValidName che fallisce poichè i caratteri accentati non sono ammessi. Il codice del metodo è il seguente:

In definitiva, fate attenzione al nome del progetto che scegliete o in alternativa, modificate il nome all'interno del file package.json.

Concludendo: perchè dobbiamo cambiare modo di gestire i progetti web rischiando di ricevere errori anche da tool fino ad ora non utilizzati?

Di questo e di tutto ciò che riguarda  Npm, Grunt, Bower e il nuovo package manager di Visual Studio 2015, parleremo il 26 marzo ai CommunityDays di quest'anno.

Ci vediamo là?

posted @ 05/02/2015 14.18 by Gianluca Carucci

Windows 10 e il menu start

Il menu Start sarà completamente  nuovo in Windows 10.

Dopo le numerose lamentele degli utenti di Windows 8 e Windows 8.1 Microsoft ha deciso di cambiare il menu con un’interfaccia moderna ma più usabile per tutti. Una delle principali novità del nuovo menu start è la capacità di poter essere minimizzato per essere meno “ingombrante”.

Però  Alcuni di voi potrebbero preferire avere sempre il menu di avvio aperto, ecco come possiamo fare per impostare questa funzionalità:

  • Apriamo il menu Start e facciamo clic sul pulsante di ingrandimento.
  • Quando vogliamo chiuderlo sarà sufficiente premere nuovamente il pulsante Start.

windowa-10-start-menu

La nuova interfaccia di Windows 10 sarà apprezzata finalmente dagli utenti finali?

Voi che dite?

posted @ 03/02/2015 10.53 by Marco Maltraversi

Overcoming the one weakness of OOP


Abstract:
OOP does not provide a built-in support, comparable to encapsulation for flexibility, in object interrelationship such that relationships between objects or structure of objects in a relationship can change, without affecting the rest of the program. 

The work of Professor Karl Lieberherr on Adaptive Object-Oriented software programming, based on the Law of Demeter, is the first to highlight this weakness of OOP, to explain its relevance and to introduce a solution based on a specific design, high-level specifications and automatic code-generation tools.


This post describes the work and the solution introduced by 
Karl Lieberherr and other well-known authors such as Steve Freeman, Nat Pryce, Tim Mackinnon and Sandi Metz. The presented solutions are based on designs that use composition, dependency injection pattern, visitor-like pattern, composite pattern and duck typing.




Glossary of ambiguous terms, as used here
Object graph: the web of relationships among a group of interrelated objects.
Object relationship
: association such as composition and aggregation, and dependency.
Object structure
: the definition of the publicly accessible object’s state and behaviour, its data and functions, its fields and methods.



Which is the one weakness of OOP?

A key advantage of object-oriented programming is certainly the kind of flexibility that object encapsulation provides.
Thanks to that flexibility, the representation of an object (the inside of the object, the internal implementation details, the internals) can be changed without affecting the rest of the program.
As a consequence, it is easy to locally understand an object in isolation, change it, extend it, evolve it, and reuse it.

When talking about encapsulation, the focus often goes to encapsulating the object’s state, the information, the data, the internal object structure.
What about relationships among objects?
OOP does not provide a built-in support, comparable to encapsulation for flexibility, in object interrelationship such that relationships can change without affecting the rest of the program.






The one weakness of OO code is that it is brittle in the face of changes to the relationship between objects and to the structure of objects that are part of an object graph.
Two common examples follow:
  1. When an object’s unstable dependency changes, it can trigger changes into the object itself and this can start a chain reaction of changes in dependent objects.
  2. When an object graph changes or some responsibilities or state is moved from one object to another, code traversing the objects and making computations on the traversed objects needs to be changed too, to adapt to the new object graph and the new structure of the objects.

Examples with source code are also available here [1] and here [2].

Overcoming the one weakness of OOP is a common design challenge for many software developers building systems with OO languages.
What solutions have been found so far? How do they relate to encapsulation?



How to overcome the one weakness of OOP?

How to make OO code less brittle in the face of changes to the relationship between objects and to the structure of objects that are part of an object graph?


This post introduces solutions from three well-known sources.
The three solutions follow below.


1. Professor Karl Lieberherr work on Adaptive programming and the Law of Demeter



In 1987 Ian Holland at Northeastern University formulated a style rule for designing object-oriented systems called The Law of Demeter [3].


The Law of Demeter is best known in its formulation at the method level that pertains to how methods are written for a set of class definitions. Typical examples of violation for this formulation include method call chains such as  dog.getBody().getTail().wag() that is colloquially known as a train wreck [4]. Conformance to this formulation of The Law of Demeter supports object encapsulation.


The formulation of the The Law of Demeter that applies to the structure of the classes, is less known. This formulation makes the notion of unnecessary coupling very explicit. Conformance to this formulation supports modularity and low coupling in object relationships, and it makes code less brittle in the face of changes in the relationships and in the related objects [4]. In other words, conformance to this formulation helps to overcome the one weakness of OO code. But how to achieve this conformance?


Between 1991 and 1996 Professor Karl Lieberherr [5] developed Adaptive Object-Oriented software programming and the Demeter Method [0], a concept that takes encapsulation to a new level. This work clearly identifies and describes the one weakness of OOP and provides a working solution.


The solution as shown here [1] conforms to the Law of Demeter and uses programming by composition so that each composite object shields other objects from changes in the composed objects and in their relationships. The solution also replaces hard-coded navigation paths used to traverse the object graph with higher-level navigation specifications. Automatic tools called Demeter Tools use the navigation specifications to regenerate and adapt the code that traverse the object graph and invoke the functions, whenever the object graph or an object structure changes.


Here I name this solution as: “Programming by Composition + Demeter Tools”.


2. Mock Objects and Growing object-oriented software, guided by tests

Thanks to Steve Freeman, Nat Pryce and Tim Mackinnon for commenting the draft of this post!


Between 1999 and 2010 a group of people from Connextra team first and then from Extreme Tuesday Club (Connextra team members: Tim Mackinnon, Tung Mac, Matthew Cooke, Iva More, Peter Marks, John Nolan; Extreme Tuesday Club members: Steve Freeman, Philip Craig, Oli Bye, Paul Simmons; Joe Walnes from ThoughtWorks and Nat Pryce) explored, experimented and developed a new way of writing object-oriented software that revolves around the practice of test-driven development (TDD), tests automation and a new technique called Mock Objects.

The full story is documented here too [10]. The initial work between 1999 and 2004 has been documented into two papers [6][7], and in 2010 in a new book [8] that summarised the whole experience produced by all the people involved.



The trigger for the discovery of the technique was when John Nolan set the challenge of writing code without getters and then favouring void methods over non-void ones. Later Peter Marks helped coin the name ‘Mock'.

The driver for the technique was literally a pragmatic way to practice TDD and write good tests without going against what was felt were good design principles, for example without exposing object internals for the sake of testing, or shying away from composition. The work was then inspired and influenced also by the Law of Demeter and Lieberherr’s work and also by [12][13].


Probably the most important effects on coding style were the development of the Mock Objects, and favouring composition over inheritance that led toward programming by composition. Programming by composition led to decouple object behaviour from the structure of the object graph. In addition to that, each composite object shields, to some degree, other objects from changes in the composed objects.

Programming by composition also led toward a design pattern that nowadays is called dependency injection [9] not to be confused with the dependency injection frameworks (a.k.a. IoC frameworks or IoC containers) that were never needed in the large Connextra code base. In turn dependency injection led to minimising objects’ dependencies and to decoupling dependencies.

Unlike the solution of Lieberherr, this solution does not use automatic tools for code generation.

Here I name this solution as: “Programming by Composition + Dependency Injection”.


A secondary effect on coding style was the tendency to push behaviour towards Visitor-like objects, objects resembling the Internal Iterator pattern [11] that have similarities with the Visitor pattern. A team member from Connextra remember using the Visitor-like pattern together with the Composite pattern used among other things to abstract away differences between the traversed objects.

The abstraction introduced with the Composite protects the code, to some degree, from changes in the object graph and in the structure of the object.
The Visitor-like design reverses the direction of an unstable dependency relationship (from a stable object to an unstable one), turning it into a stable relationship (from the unstable object acting as the "visitor" to the unstable one acting as the"element").




While the focus on this solution diminishes after the first paper, it is documented here because of a similarity with the solution presented by Sandi Metz.

Here I name this solution as: “Visitor-like + Composites”.



An interesting after thought about the technique of TDD with mocks from Tim Mackinnon: I can’t stress enough how most people have missed, and still do, that connection with CRC cards, mocks and role play. Mocks and the technique really came from the idea of working with a partner to act out what you expected the design/objects to do - and then “asserting” those interactions. That was the number one design point. For us, this was the aha moment.

On the same line Nat Pryce comments: There was quite a change in emphasis between the Endo-Testing paper and the Mock Roles, Not Objects paper and GOOS book. For example, the former recommended using mock objects to fake third-party APIs that are difficult or slow to use for real in tests, such as JDBC. The latter recommended *not* mocking third-party APIs, but rather discovering the appropriate interfaces for mocking from the need of client objects. Also the Mock Roles, Not Objects and GOOS style focused more on messages and protocols between objects.


3. Less, The path to better design



Sandi Metz in her speech 'Less, The path to better design' [2] takes on the challenge of the one weakness of OOP and presents design solutions that deal with changes in unstable object’s dependencies, both in the object structure and in the object graph.


The approach she presents is based on the idea that designers cannot predict the future but they can guard against it choosing carefully object dependencies, identifying those that are less stable and surrounded by more uncertainty and then aggressively decoupling them.

This approach is in tune with the second formulation of the The Law of Demeter that applies to the structure of the classes.


The solution that Sandi Metz presents, employs a design similar to the visitor pattern to decouple from unstable dependencies.

In the problem presented there are two objects that needs to interact to execute a task. The first object is known, under control and more stable, the second object is less stable because surrounded by more uncertainty. In order to reduce the coupling of the first one to the second, the second object acts like a Visitor in the Visitor pattern while the first object plays the role of the visited element. This design reverses the direction of the dependency, doing so it turns the unstable dependency relationship into a stable one.

Unlike the previous solution, this one does not make use of the Composite pattern to guard the code against changes in the object graph, because the language she uses is Ruby that supports duck typing, which serves the same purpose.


Here I name this solution as: “Visitor-like + Duck Typing”.



Comparing solutions

These are some similarities about the solutions suggested by the authors:

  • One solution uses tools and higher-level navigation specifications to regenerate code whenever there are changes to the relationship between objects and to the structure of objects.

  • Two solutions include the use of Programming by Composition: to decouple object behaviour from the structure of the object graph, and to shield, to some degree, other objects from changes in the composed objects.

  • One solution include the use of the dependency injection pattern: to minimize objects’ dependencies and to decouple dependencies.

  • Two solutions include the use of a Visitor-like pattern, used essentially to reverse the direction of an unstable dependency and so turning the dependency relationship into stable.

  • Two solutions abstract away differences between objects traversed in an object graph to protects the code, to some degree, from changes in the object graph and in the structure of objects:
    • One solution for statically typed languages does this with the Composite pattern,
    • The other solution for dynamically typed languages does this with Duck Typing.

  • All the solutions explicitly tell how to carefully choose and limit dependencies, with different but substantially equivalent means.

 

posted @ 20/01/2015 0.14 by Luca Minudel

jsdelivr

A free super-fast CDN for developers and webmasters.


http://www.jsdelivr.com

posted @ 19/01/2015 12.12 by Alessandro Gervasoni

API Ergonomics

Diversi anni fa (fine 2008) pubblicai un post intitolato "ergonomia dell'architettura", oggi mi sento di fare un punto pensando anche all'evoluzione della programmazione in generale. Ovviamente tutto con spirito IMHO!

Una nuova definizione

Dopo attenta riflessione, ho ribattezato il vecchio post in API ergonomics (mi piace tanto come suona in inglese :)), che tradotto in italiano è ergonomia dell'interfaccia di programmazione di un'applicazione. La definizione contenuta nelle prime righe di wikipedia di Application programming interface è calzante e musa ispiratrice per aprire questo post: "Con Application Programming Interface (in acronimo API, in italiano Interfaccia di Programmazione di un'Applicazione), in informatica, si indica ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l'espletamento di un determinato compito all'interno di un certo programma. Spesso con tale termine si intendono le librerie software disponibili in un certo linguaggio di programmazione" (Ho evidenziato punti chiave in grassetto)

Le API independemente dalla modalità di pubblicazione, dal linguaggio in cui sono state realizzate o dal sistema operativo/architettura fisica in cui si eseguono, sono strumenti disponibili al programmatore per realizzare il proprio lavoro, cioè il software.

Ergonomia nell'industria

Quando ero ancora un ragazzo, oltre alla mia prima passione, l'informatica, mi piaceva l'elettronica, una volta rimasi affascinato da una semplice riflessione sulla maturità del software che lessi in un articolo, l'autore confrontava l'elettronica con lo sviluppo del software, evidenziava come l'industria informatica, pure avendo un grandissimo potenziale, non aveva ancora la maturità tecnologica e produttiva di altre industrie, come quella elettronica... ad esempio adduceva il salto qualitativo e produttivo introdotto dai circuiti integrati.

Ora confrontiamo, presa sempre da wikipedia, la definizione di Ergonomia con gli elementi che ho evidenziato nella precedente di API: "L'ergonomia, secondo la IEA (International Ergonomics Association), è quella scienza che si occupa dell'interazione tra gli elementi di un sistema (umani e d'altro tipo) e la funzione per cui vengono progettati (nonché la teoria, i principi, i dati e i metodi che vengono applicati nella progettazione ), allo scopo di migliorare la soddisfazione dell'utente e l'insieme delle prestazioni del sistema[1]. In pratica è quella scienza che si occupa dello studio dell'interazione tra individui e tecnologie." (Ho evidenziato punti chiave in grassetto)

In effetti in questi anni abbiamo tutti visto un rapido progresso nell'industria delle applicazioni e abbiamo notato come, ad esempio, la "pacchettizzazione" e il deploy del software con metodologie e strumenti più rubusti abbia portato un vantaggio competitivo, in termini di produttività, integrazione e aggiornamento del software. Ma questo è solo un esempio, altre idee importanti ne hanno permesso l'evoluzione qualitativa: i pattern per lo sviluppo di applicazioni (chi non ha letto Patterns of Enterprise Application Architecture? ;)), i linguaggi di programmazione, i compilatori, gli ambienti di sviluppo, le metodologie e gli strumenti agili, il testing unitario e automatico del software (Unit Test e TDD) ...

Ergonomia nel software

Per esperienza ho verificato o sono arrivato alla conclusione che alcune pratiche e metodologie sono strumenti che possono permetterci di modellare l'ergonomia della nostra API. Premetto che ho una mia filosofia sull'utilizzo delle pratiche e metodologie, queste vanno applicate con il giusto equilibrio e nel giusto contesto, sono quindi contrario all'approcio "dogmatico" nell'uso di una pratica, con "dogmatico" intendo un approccio per il quale sembra che una metodologia sia il vaso di pandora che quando la scopro risolverà tutti i miei problemi di sviluppatore e che dovrà essere usata sempre per ogni riga di codice che scrivo ;) ... ho visto nella realtà progetti fallire applicando questa "fuorviante e pericolosa strategia"! Premesso questo di seguito illustro alcune ideo o strumenti che se usati bene sono utili a sviluppare codice "ergonomico" per i nostri programmatori, spiegandone brevemente vantaggi e applicazione puramente nell'ambito di cui si discute in questo thread.

  • Naming approach

    Il nome che diamo a una classe o a un metodo, in relazione alla struttura e alla gerarchia di oggetti, soprattuto quando deve essere usato da altri (specialmente quando fa parte del contratto pubblico della nostra API) dovrebbe essere pensato con attenzione. Alcuni programmatori pensano sia una perdita di tempo soffermarsi troppo su quest'aspetto, peccato che poi ci si trova classi e librerie con nomi che seguono una logica disomogenea e a volte fuorvianti che richiedono molto tempo e ragionamenti per capire quale metodo devo chiamare per effettuare una certa operazione oppure peggio ancora mi spingono intuitivamente a chiamare quello sbagliato! Non sarà mai possibile applicare una strategia "perfetta" ai nomi che diamo ai nostri "oggetti", visto che la comunicazione e il linguaggio sono aspetti molto complessi, ma un po' di attenzione, di rigore e di riflessione fanno la differenza.

  • Abstraction details

    Così come un cruscotto di una macchina pieno di pulsanti e/o non bene organizzati forse con un eccesso di gruppi, il modo e il livello di astrazione con cui disegnamo il nostro sistema puo influire sulla complessità di comprensione e utilizzo dello strumento.

  • Test Driven Development

    La pratica dello sviluppo guidato dai test o TDD è utile per obbligarci a modellare i contratti pubblici della nostra applicazione prima del loro dettaglio implementativo. In particolare quando penso ai contratti pubblici non mi riferisco solo ai nomi dei metodi ma anche ai nomi delle classi e alle strategie e al dettaglio di astrazione del nostro modello ad oggetti.

  • Convention Over Configuration

    Quando alcuni anni fa, in un grosso progetto in cui lavoravo, decidemmo di adottare nello sviluppo del nostro software alcune soluzioni "enterprise" ci appoggiamo ad una factory open source derivata da java totalmente configuration driven dove era necessario specificare nel file di configurazione tutto il dettaglio di come construire gli oggetti e iniettare le dipendenze, pur valorizzando la potenza di questo livello di configurazione, dovendo lavorare con domini molto complessi, di centania di componenti, il dettaglio della configurazione stava diventando il nostro tallone di achille. Così decidemmo di intervenire, allora analizzai tutto ciò che poteva essere definito implicitamente per convenzione e sviluppando un sistema automatico di configurazione e l'ausilio di attributi nel codice, con un investimento relativemente ridotto abbiamo portato in carreggiata la competitività del prodotto aumentando produttività e qualitità. La "convention over configuration" se applicata bene (identificando con opportuna attenzione le "reali" convenzioni) rende lo strumento software più produttivo e malleabile, in altre parole più ergonomico.

Conclusione

In altre industrie è stato ed è fondamentale lo studio dell'ergonomia, tanto che ormai è un elemento che fa parte del processo di progettazione e realizzazione di qualsiasi nuovo prodotto. Non sarebbe corretto dire che nella nostra industria non si tenga conto di quest'aspetto, in effetti fa implicitamente parte di diverse pratiche e pattern di sviluppo, ed emerge in alcune librerie di successo, ma non è certamente definito in modo rigoroso come pratica e/o all'interno forse di un approccio metodologico più ampio (che non possa essere quello agile? :D)

Spero che queste riflessioni possona produrre maggiore sensibilità da parte di programmatori, archittetti e responsabili tecnici a quest'aspetto che ho definito 'API ergonomics' soprattuto nell'ambito di progettazione e sviluppo di librerie e strumenti che dovranno usare altri sviluppatori. Sarebbe utile individuare in modo più rigoroso le pratiche, le metodologie, gli strumenti che sono utili allo sviluppo di librerie applicative più ergonomiche, tenendo conto che anch'esse a loro volta, dovrebbero rispondere a criteri di ergonomia. Sarebbe interessante anche poter misurare il livello di ergonomia di una libreria o di una applicazione defininendo e applicando oppurtune metriche (ad esempio come possiamo dare un indice di complessità al codice applicando determinati algoritmi)

E' possibile che per alcuni questa disquisizione possa sembrare mera filosofia, in realtà dal mio punto di vista la preoccupazione di scegliere, o progettare e sviluppare, strumenti più facili e comprensibili da usare per la realizzazione di un progetto software da un vantaggio competitivo e tecnologico non indifferente. Io ho vissuto questa esperienza occupandomi dello sviluppo e della manutenzione di una libreria "enterprise" per un grosso progetto gestionale e ho visto che lavorando nell'applicare pratiche per rendere più intuitivo ed efficacie l'utilizzo dell'infrastruttura al programmatore ne hanno beneficiato in maniera effettiva produttività e qualità.

posted @ 18/01/2015 16.42 by Marco Baldessari

Echarts : facilitates your swim in big data



http://ecomfe.github.io/echarts/index-en.html

posted @ 15/01/2015 12.10 by Alessandro Gervasoni

Radical news

Anno nuovo buone nuove :-)

Grazie al preziosissimo aiuto di Michael (https://github.com/micdenny) ed Enos (https://github.com/enosrecanati) stiamo dando linfa a Radical

A new home

Siamo sempre su GitHub, niente paura, ma abbiamo anche deciso di sfruttare la GitHub Pages per avere un bel front-end: http://radical.topics.it

Universal Apps

Cominciato dall’instancabile Enos e portato a termine in queste vacanze natalizie oziose possiamo finalmente annunciare che abbiamo il supporto per Universal Apps, la nuova versione è in un repository separato per agevolare il versioning che non ha senso che vada di pari passo con quello della versione desktop.

Documentazione

Complici Michael e Nazareno (http://blogs.ugidotnet.org/ddl) la documentazione prende forma sempre di più ed è ogni giorno più ricca: https://github.com/RadicalFx/radical/wiki

Visual Studio Templates

Tadaaaaa :-) finalmente, dopo un po’ tanto sudore e un po’ di lacrime abbiamo il supporto per i template di Visual Studio, disponibile nella Visual Studio Gallery: https://visualstudiogallery.msdn.microsoft.com/5ff17cc4-ecf3-4395-9e18-d4673186e2fe

posted @ 15/01/2015 11.13 by Mauro Servienti

Shower HTML presentation engine

https://github.com/shower

posted @ 14/01/2015 8.55 by Alessandro Gervasoni

Jet Profiler for MySQL

Real-time query performance and diagnostics tool for the MySQL database server.
http://www.jetprofiler.com

posted @ 14/01/2015 8.53 by Alessandro Gervasoni

Latest Images

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 Foto
From Foto
From Foto
From Immagini
From Immagini