Wednesday, April 8, 2015

Radical Splash-Screen support for desktop apps

Take a look at the following snippet:

image

It is not available yet, it is a feature we are working on that leverages the intrinsic power of partial regions: it is enough to call the EnableSplashScreen() method (the configuration is optional) and define a partial named “SplashScreenContent”, the partial user control will be automatically wired up at startup and used as the splash screen content.

If you have any idea or comment chime in.

.m

Wednesday, April 1, 2015

Solution Architect @ Particular Software

I’m so excited to announce that starting today I’ll be a Solution Architect in Particular Software, an amazing group of awesome people, supporting customers in their journey with NServiceBus and the Particular Platform.

I have no words to express my satisfaction, so enjoy:

This long journey started 15 years ago and is really far away from its end, but this is one of those milestones that can change your life, at least changed mine.

There is a long list of people I must (yes must) thank, too easy to miss someone, but at least 3 were a game changer in my life, so thank you Raffaele, Lorenzo and Andrea. (in strict order of appearance).

.m

Tuesday, March 31, 2015

Radical Vegan (RC) release

We have just released (also on NuGet) the RC version of Radical “Vegan”, closed issues: https://github.com/RadicalFx/radical/issues?q=milestone%3AVegan+is%3Aclosed

Highlights

It is a release candidate so use it, it is supported, stay tuned and report any issue you may encounter.

.m

Thursday, January 15, 2015

Radical news

Good news :-)

Thanks, many thanks, to Michael (https://github.com/micdenny) and Enos (https://github.com/enosrecanati) we are powering Radical with new fuel.

A new home

Still GitHub, no worries, but we also decided to leverage GitHub Pages to have a nice front-end: http://radical.topics.it

Universal Apps

Started by the tireless Enos and brought to an end during the past Holidays we can finally announce that we now support Universal Apps. The new version is hosted in a new repository because is has a different lifecycle from the desktop one.

Documentation

With the complicity of Michael and Nazareno (http://blogs.ugidotnet.org/ddl) the documentation is richer every single day: https://github.com/RadicalFx/radical/wiki

Visual Studio Templates

Tadaaaaa :-) finally, after a long  sweat and some crying too we now have Visual Studio templates support, available today in the Visual Studio Gallery: https://visualstudiogallery.msdn.microsoft.com/5ff17cc4-ecf3-4395-9e18-d4673186e2fe

.m

Tuesday, November 4, 2014

NServiceBus Configuration API Webinar - errata corrige

In september I had the opportunity to drive the "Mastering NServiceBus Configuration API" webinar. The webinar recording can be found here: https://particular-1.wistia.com/medias/q8tdr6mnzz


This post is a sort of "errata corrige", a few things need clarification:
  • at minute 18: I said that "we can rely on DI in a INeedInitialization" implementation: wrong, we cannot. At this stage we cannot resolve any components yet, what we are guaranteed is that the container is setup and injected in NServiceBus so we can register components not yet resolve them;
  • At min 35: there is a self-hosting sample, since now the IBus interface implements the Idisposable interface it is much better to change the sample code using the "using" pattern, in order to correctly shutdown the bus:
    using( var bus = Bus.Create( cfg ) )
    {
        bus.Start();
        Console.Read();
    }
  • the AsAClient role is for SendOnly endpoints: wrong, the difference between AsAClient and AsAServer roles is the client one turns off transactions, SLR, Timeouts and purges queue at startup.
  • At min 45.40: talking about registering steps in the pipeline, I said the InsertAfter/Before is right after/before: it is not accurate, the registration just guarantees that the step is inserted after or before another step, it does not guarantee that it will be inserted right after or before, so there could be steps between the new registered step and the one that was configured to be after or before.
Thanks to John Simons (https://twitter.com/johnsimons_) for reviewing the material and highlighting the above issues.

Thursday, August 21, 2014

ASP.NET Web API Succinctly

Last week while travelling to London I had the pleasure to read “ASP.NET Web API Succinctly” by Emanuele DelBono, the book is part of the Syncfusion technical collection and I must admit that it is simply complete despite its brevity, I read it in not more than 2 hours.

Emanuele starts with a brief introduction to what REST is and to its philosophy, to deep dive into the ASP.NET Web API technical aspects and into how REST combines with the Web API technology.

The technical part of the book is the perfect combination between simplicity and in-depth analysis, given the nature of the book collection, everything is faced with the expected complexity rate, enough to give to the reader the information required to start moving with its own feet but much more enough to give all the information required to start diving into Web API topics independently. Topics that ranges from the routing engine to security management passing through the Web API extensibility pipeline.

A must read.

.m

Monday, April 28, 2014

RavenDB and the LoadDocument feature

To make a long story short: handle with care.

The long story…

In a relational world you must live with joins, full stop. It is not a problem neither an advantage it is a sort of a non-functional requirement, this is it, a relational model most of the time requires joins.

If you have in your object model a Person class with a list of Addresses it will be stored in 2 different tables and in order to load them there are 2 options:

  • shoot yourself in a foot and perform 2 queries;
  • issue a join and in one single round-trip to the db get all the data;

When it comes to document modeling in a non-relational world the available options are a bit more and ranges from model your document in a relational fashion (most of the time shooting yourself in a foot) or model them in a document oriented manner.

Modeling in a document oriented manner open up to an infinite range of options because it barely depends on the context, the usage, the type of the application and much more. For the purpose of the article consider the above Person class, one solution in a document database is the following:

{
   firstName: 'Mauro',
   lastName: 'Servienti',
   addresses: [{
      country: 'Italy',
      city: 'Milan'
   },{
      country: 'Ireland',
      city: 'Dublin'
   },]
}

We can embed everything in one single document with the consequence that we do not need a join to load the entire data set, it is one single trip in all the cases.

Nothing forces us to model the solution as in the above sample, even if is a good approach, we can model the solution in a relational fashion even if in this case will be the worst solution but in the end I’m just trying to find a simple sample use case for the LoadDocument feature :-)
What we can do is store persons and addresses as separate documents introducing a relation (application level relation) between them, something like:

{
   id: 'people/123',
   firstName: 'Mauro',
   lastName: 'Servienti',
   addresses: [ 'addresses/123' ]
}

{
      id: 'addresses/123'
      country: 'Italy',
      city: 'Milan'
}

There are valid use cases for the above choice, what we immediately lose is the ability to easily search a person given an address because with the first design choice we can define an index such as the following:

from doc in docs.People
select new 
{
   Content = new object[]
   {
      doc.FirstName,
      doc.LastName,

doc.Addresses.SelectMany( x => x.City ) } }

and we immediately get full text search capabilities even on addresses, and that is pretty cool. In the second scenario with separate documents the application must decide where to search and if we need to search as in the first scenario we need to issue 2 search queries.

LoadDocument to the rescue

from doc in docs.People
let addresses doc.Addresses.Select( x => LoadDocument(x))
select new
{
    Content = new object[]
    {
        doc.FirstName,
        doc.LastName,
        addresses.SelectMany( x => x.City )
    }
}

The above index definition solves the problem, we have basically defined a join in an index that at indexing time will load related documents and indexes also their content.

Handle with care

What we need to take into account, if we decide to use the above feature, are the side effects that the above decision introduces. Under the hood what RavenDB does is to keep track of the fact that we have defined the relation, in the index, between a bunch of documents, this is done so that whenever an address document changes the index will be marked as stale simply because this is the expected behavior otherwise the above index will always produce stale results.

Think about it for a minute: keeps track of the relation to re-evaluate the index at each related document change.

Once again: …at each related document change…

Why am I telling all this?

Simply because we have clearly outlined something that can be a real problem if not handled with care, imagine a scenario where you have a huge team of experienced developers migrating an application from a relational model to a document based model where they approach the migration in a relational manner, as in the second sample, introducing indexes with a lot of “load documents” (where “a lot” means more than 10 per index) everywhere.

trust me, the result is a nightmare :-) it surely works, on the developer machine only…

.m