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 - 31045
  • Articles - 310
  • Comments - 105894
  • Trackbacks - 591210

Bloggers (posts, last update)

Latest Posts

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 3 sources:

  • 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 and of the dependency inversion pattern: to decouple object behaviour from the structure of the object graph, to decouple dependencies and to shield, to some degree, other objects from changes in the composed objects.

  • Two solutions include the use of a design similar to the 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 three 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

js-sequence-diagrams

http://bramp.github.io/js-sequence-diagrams
generatore di diagrammi uml partendo da un testo....forse un giorno mi tornerà utile

posted @ 30/12/2014 0.30 by Alessandro Gervasoni

JsHint - Permettere variabili globali

Senza entrare nella discussione di quale lint-tool utilizzare per il verificare la “bontà” del codice js scritto, e poichè JsHint è incluso nel plugin di VS WebEssentials, mi sono ritrovato a faccia a faccia con il seguente messaggio:

image

Tale messaggio indica chiaramente che la variabile “_” (lodash nel mio caso) è usata senza che essa venga precedentemente dichiarata. Da qui il mio pensiero è stato:

  1. Vero è che, di buona norma, occorrerebbe evitare di utilizzare variabili globali ed iniettarle tutte tramite injection, però è anche vero che ce ne sono un insieme ($, _, angular, toastr…) che sinceramente si fa “fatica” ogni volta definirle come parametro da iniettare (si, sono molto lazy).
  2. Perchè non esiste lo stesso problema con angular (anch’essa variabile globale)?
  3. E’ possibile in qualche modo nascondere questo messaggio di errore selettivamente per altre librerie?

La risposta è ovviamente positiva e può essere risolta nei seguenti modi:

  1. All’inizio di ogni file .js che utilizza “_”, è possibile aggiungere la direttiva /*global _: false*/, ovvero indica di non considerare “_” in quanto è definito nello scope globale
  2. Da visual studio, sotto il menù “WEB ESSENTIALS-Edit global JSHint settings” è possibile modificare le impostazioni utilizzate dall’utente corrente:
    image
    Il file “.jshintrc” è un file json che, tra le altre cose, definisce quali variabili sono considerate globali:
    image
    Ecco quindi il motivo per il quale “angular” non viene mostrato di default nei messaggi di JsHint. La sezione può essere quindi arricchita in modo da aggiungere altre librerie:
    image
  3. Nel punto precedente tutto funziona perfettamente eccetto che tale setting è a livello di utente e magari “Emix” è una variabile che si vorrebbe considerare globale solo in uno specifico progetto. Per ovviare al problema è possibile creare una copia del file “.jshintrc”, aggiungerla alla solution in modo da utilizzare un set di impostazioni specifiche per il singolo progetto/solution:
    image
    In questo modo inoltre, poichè il file è all’interno della solution, le impostazioni possono essere salvate su source control e quindi condivise tra tutti gli sviluppatori del team.

posted @ 24/12/2014 0.47 by Roberto Sarati

bigpicture

bigpicture.js is a library that allows infinite panning and infinite zooming in HTML pages.
https://github.com/josephernest/bigpicture.js

posted @ 19/12/2014 0.15 by Alessandro Gervasoni

www.buildmystring.com

ok non è mai bello inserire complessi script sql direttamente nel codice ma per quando è necessario questo tool ti aiuta a formattare il codice in un stringa o in uno stringbuilder
www.buildmystring.com

posted @ 11/12/2014 10.12 by Alessandro Gervasoni

sourcetreeapp : A free Git & Mercurial client for Windows or Mac.



http://www.sourcetreeapp.com/

posted @ 10/12/2014 9.16 by Alessandro Gervasoni

Beauty & Dignity

Beauty: what pleases the senses, what enlightens the mind, what is righteous, what is just, what is truthful, what is good.

Dignity: the idea that each and every human being without distinction of any kind, by the mere fact of being born into this world, has innate equal rights such as the right to freedom and to the pursuit of happiness, and is worthy of honour, esteem, consideration and respect.


 

posted @ 06/12/2014 16.03 by Luca Minudel

Verificare se un evento è già registrato

Problema

Verificare se un evento "incapsulato" ( public event ... ) è già registrato dato l'oggetto origine che genera ed incapsula l'evento, l'oggetto di destinazione che ha registrato l'evento e il nome dell'evento.

Soluzione

Code Snippet
  1. public static bool IsEventAlreadyRegistered<T>(T source, object target, string eventName) where T : class
  2. {
  3.     if (source == null)
  4.         throw new ArgumentNullException("source");
  5.     if (target == null)
  6.         throw new ArgumentNullException("target");
  7.  
  8.     return (typeof (T)
  9.         .GetEvents()
  10.         .Where(@event => @event.Name == eventName)
  11.         .Select(@event => source.GetType().GetField(@event.Name, BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance))
  12.         .Select(fi => fi.GetValue(source)))
  13.         .OfType<MulticastDelegate>()
  14.         .Any(@delegate => @delegate.GetInvocationList()
  15.             .Any(_delegate => _delegate.Target == target));
  16. }

Esempio

Code Snippet
  1. [Test]
  2. public void WhenEventIsMappedIsEventAlreadyRegisteredReturnTrue()
  3. {
  4.     var source = new EventSourceStub();
  5.     source.SomeEvent += ReflectionExtensionsEventTest_MyEvent;
  6.     Assert.IsTrue(ReflectionExtensions.IsEventAlreadyRegistered(source, this, "SomeEvent"));
  7. }
  8.  
  9. void ReflectionExtensionsEventTest_MyEvent(object sender, EventArgs e)
  10. {
  11. }

Vedi progetto FxCommon sorgente ReflectionExtensions.cs test ReflectionExtensionsTest

posted @ 03/12/2014 16.44 by Marco Baldessari

Datejs

datejs.com

posted @ 03/12/2014 0.59 by Alessandro Gervasoni

microjs

http://microjs.com/

posted @ 03/12/2014 0.46 by Alessandro Gervasoni

Il mio primo progetto OpenSource (GitHub & NuGet)

  • Ho creato il repository del progetto GIT su GitHub applicando la licenza Apache 2.0

  • Ho quindi clonato il nuovo repository in locale con SourceTree


  • Ho effettuato il merge da un precedente repository git dei progetti FxCommon e FxCommonTest da cartelle diverse
  • Sono partito da questo post Git: Copy a file or directory from another repository preserving the history
  • Merge progetto FxCommon
        mkdir /c/temp/mergepatchs
        export reposrc=/c/Sviluppo/Libreria/FxCommon
        git format-patch -o /temp/mergepatchs $(git log $reposrc|grep ^commit|tail -1|awk '{print $2}')^..HEAD $reposrc
        cd /c/Sviluppo/FxCommon
        git am /temp/mergepatchs/*.patch
        
    Merge progetto FxCommon
        mkdir /c/temp/mergepatchs
        export reposrc=/c/Sviluppo/Tests/FxCommonTest
        git format-patch -o /c/temp/mergepatchs $(git log $reposrc|grep ^commit|tail -1|awk '{print $2}')^..HEAD $reposrc
        cd /c/Sviluppo/FxCommon
        git am /temp/mergepatchs/*.patch
        
  • Ho creato la soluzione VS.2013 vuota e aggiunti i due progetti di Sviluppo e Test
  • Ho preparato una build rudimentale del pacchetto NuGet
    1. Ho configurato le proprieta' del nuovo progetto (Properties/AssemblyInfo.cs)
    2. Ho creato la cartella /Build sotto la root ed aggiunto il file NuGet FxCommon.nuspec
                  <?xml version="1.0" encoding="utf-8" ?>
                  <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
                      <metadata>
                          <id>MBaldessari.FxCommon</id>
                          <version>0.0.1</version>
                          <title>FxCommon</title>
                          <description>.NET core library used by FxXXX projects</description>
                          <authors>Marco Baldessari</authors>
                          <language>en-US</language>
                          <projecturl>https://github.com/waldrix/FxCommon</projecturl>
                          <tags>fx</tags>
                      </metadata>
                  </package> 
          
    3. Ho quindi creato un batch denominato Build.bat
                  mkdir .\bin
                  del .\bin\*.nupkg
                  ..\.nuget\nuget.exe pack ..\FxCommon\FxCommon.csproj -Build -Properties Configuration=Release -OutputDirectory .\bin\
                  pause        
              
  • Effettuato l'upload su NuGet (triviale) da Upload Your Package


    Nota: Non ha preso l'url del progetto dal pacchetto (mi chiedo il perche'??), ma e' stato possibile modificare le proprieta' prima di confermare il pacchetto

  • Il gioco e' fatto! ... ecco il mio pacchetto visibile su NuGet, e' solo una libreria di base con pochissima roba ma comunque "testata", più avanti vorrei pubblicare una libreria più significativa! :)

posted @ 01/12/2014 21.57 by Marco Baldessari

ASP.NET 5 e AzureTableStorage

Riprendiamo l’esempio del post precedente per testare l’integrazione tra EF7 e lo storage di Azure. Apriamo NuGet ed installiamo il package “EntityFramework.AzureTableStorage” (sempre in beta):

image

Modifichiamo il codice della classe ItemDB in questo modo:

1 public class ItemDB : DbContext 2 { 3 public DbSet<Item> Items { get; set; } 4 5 protected override void OnConfiguring(DbContextOptions options) 6 { 7 options.UseAzureTableStorage("[Storage_Name]", "[Secret_Key"); 8 } 9 10 protected override void OnModelCreating(ModelBuilder modelBuilder) 11 { 12 modelBuilder.Entity<Item>().ForAzureTableStorage() 13 .PartitionAndRowKey(a => a.CategoryId, a => a.Id) 14 .Table("Items"); 15 } 16 }

Rispetto all’esempio precedente è stato rimosso il metodo di estensione UseSqlServer ed aggiunto un degli overload di UseAzureTableStorage che accetta in ingresso due parametri: accountName ed accountKey. Tramite l’override di OnModelCreating andiamo ad istruire il runtime sulle propietà della classe Item che rappresentato rispettivamente la PartitionKey e la RowKey del Table Storage su Azure. Modifichiamo il file Project.json commentando la voce aspnetcore50 nella sezione frameworks:

image

La classe Item modificata è la seguente:

1 public class Item 2 { 3 public int Id { get; set; } 4 public int CategoryId { get; set; } 5 public string Code { get; set; } 6 public string Description { get; set; } 7 }

Infine modifichiamo la classe Program.cs:

1 public void Main(string[] args) 2 { 3 using (ItemDB db = new ItemDB()) 4 { 5 int nextId = new Random().Next(100000); 6 7 db.Items.Add(new Item() 8 { 9 Id = nextId, 10 Code = "Item #" + nextId, 11 Description = "Description #" + nextId 12 }); 13 14 db.SaveChanges(); 15 } 16 17 using (ItemDB db = new ItemDB()) 18 { 19 foreach (Item item in db.Items) 20 { 21 Console.WriteLine("Item Id: {0}, Code: {1}, Description : {2}", 22 item.Id, item.Code, item.Description); 23 } 24 } 25 26 Console.ReadLine(); 27 }

Proviamo quindi ad eseguire l’applicazione:

image

Ulteriore prova che tutto funzioni correttamente si puo’ avere utizzando l’”Azure Storage Explorer”:

image

posted @ 30/11/2014 22.48 by Pietro Libro

ASP.NET 5 e Entity Framework 7 (beta)

Vediamo in questo post come iniziare a giocare con Entity Framework 7 “beta” (in “beta” solo per uniformità con in rilascio della preview di VS 2015, cosi come descritto in questo post). Partiamo con aprire VS 2015 e creare un progetto di tipo “ASP.NET 5 Console Application”:

image

Per utilizzare Entity Framework 7, apriamo il file Project.json e aggiungiamo nella sezione dependencies le tre dipendenze seguenti:

  1. "EntityFramework": "7.0.0-beta1"
  2. "EntityFramework.Commands" : "7.0.0-beta1"
  3. "EntityFramework.SqlServer": "7.0.0-beta1"

Le dipendenze 1 e 3 ci servono per integrare EF nel nostro progetto ed “informare” che andremo a lavorare utilizzando EF per SQL Server (dato che nella nuova versione, il provider di EF puo’ essere utilzzato nativamente per interagire con SqlServer, SqlLite, AzureTableStorage e InMemory, quindi non solo database relazionali), la dipendenza 3 ci serve per utilizzare i comandi di DB Migration all’interno del nostro progetto.

Sempre in Project.json aggiungiamo la sezione Commands con la relativa voce “EF”:

"commands": {
    "ef": "EntityFramework.Commands"
},

 

Cosi’ che alla fine delle modifiche il file Project.json sia simile a quanto illustrato nella figura seguente:

image


Aggiungiamo al progetto un file di tipo “ASP.NET Configuration file” (Config.json):

image

Il quale di Default si presenta in questo modo:

image

Nella sezione “Data\DefaultConnection” modifichiamo la voce ConnectionString editando la propietà Database oppure cambiando l’intera stringa di connessione, secondo di dove vogliamo ospitare il nostro database (Istanza di SQL Server Express piuttosto che LocalDB ad esempio). Tramite “NuGet Package Manager” (molto piu’ carino graficamente di quello precedente), aggiungiamo un riferimento al Package “Microsoft.Framework.ConfigurationModel.Json” :

image

Aggiungiamo al progetto il file Startup.cs:

image

E modifichiamolo come segue:

1 public class Startup 2 { 3 public static Microsoft.Framework.ConfigurationModel.IConfiguration Configuration { get; set; } 4 5 static Startup() 6 { 7 Configuration = new Microsoft.Framework.ConfigurationModel.Configuration() 8 .AddJsonFile("config.json").AddEnvironmentVariables(); 9 } 10 }

Aggiungiamo al progetto due nuovi classi C#, “Item” e “ItemDB”, dove “ItemDB” è la classe derivata da System.Data.Entity.DbContext ed “Item” il Data Model:

1 public class Item 2 { 3 public int Id { get; set; } 4 public string Code { get; set; } 5 public string Description { get; set; } 6 } 7 8 public class ItemDB : DbContext 9 { 10 public DbSet<Item> Items { get; set; } 11 12 protected override void OnConfiguring(DbContextOptions options) 13 { 14 options.UseSqlServer(Startup.Configuration.Get("Data:DefaultConnection:ConnectionString")); 15 } 16 }

Il nuovo metodo OnConfigure di cui abbiamo eseguito l’override ci permette di specificare quale Data Provider (nel nostro caso SqlServer) lavorerà con il nostro DbContext. UseSqlServer accetta come parametro  una stringa di connessione che recuperiamo dal file Config.json tramite la proprietà Configuration (Microsoft.Framework.ConfigurationModel.IConfiguration) presente nella classe Startup.cs.

Per utilizzare EF Migrations, non è ancora finita, in quanto è necessario installare e configurare KVM (K Version Manager), sul sito è presente una piccola guida all’installazione.

Apriamo un’istanza di Windows PowerShell (o Command Prompt secondo le preferenze) e ci spostiamo nella directory del nostro progetto, dopo digitiamo il comando “K ef migration add initial”:

image

Se tutto è stato eseguito correttamente, nel nostro progetto viene aggiunta la classica cartella “Migrations” con tutti i file necessari:

image

Applichiamo quindi il nostro “piano di migrazione” tramite il comando “migration apply”:

image

Ora possiamo testare che tutto l’Ambaradan (Smile) funzioni, modificando la classe Programs.cs in questo modo:

1 public void Main(string[] args) 2 { 3 ////Save data. 4 using (ItemDB db = new ItemDB()) 5 { 6 db.Items.Add(new Item() 7 { 8 Code = "Item #1", 9 Description = "Description #1" 10 }); 11 12 db.SaveChanges(); 13 } 14 15 ////Load data. 16 using (ItemDB db = new ItemDB()) 17 { 18 foreach (Item item in db.Items) 19 { 20 Console.WriteLine("Item Id: {0}, Code: {1}, Description : {2}", 21 item.Id, item.Code, item.Description); 22 } 23 } 24 25 Console.ReadLine(); 26 }

E poi avviando il tutto con un bel F5:

image

Sicuramente la versione 7 di EF è ancora “poco” matura per essere utiizzata in progetti reali, ma questo esempio vuole essere un punto di partenza per scoprire quali novità ci attendono Smile

posted @ 30/11/2014 12.21 by Pietro Libro

10 anni.

Cominciavo esattamente 10 anni fa a quest’ora. Però :-) non male.

.m

posted @ 30/11/2014 11.15 by Mauro Servienti

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