HTML5 es muchisimo mas que un estandar, mucho mas que un simple buzz, va bastante mas alla de un simple lenguaje de markup. Tratare de explicar HTML5 desde el punto de vista de un desarrollador web, especialmente que implica para un developer de ASP.NET.

El evento pueden encontrarlo en el link de Google Calendar, no olviden hacer la transformacion en su huso horario.

I downloaded the JustCode internal build and the installer correctly detected my Visual Studio 2011 installation, sweet, everything finished without any problem. Then when I started Visual Studio 2011 I realized JustCode didn’t load… and all what I get it’s a very verbose exception in the JustCode’s output window:

ERROR 2011-10-23 00:23:38.842 :  [HResult: 80131602]
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
   at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
   at System.Reflection.RuntimeModule.GetTypes()
   at System.Reflection.Assembly.GetTypes()
   at System.ComponentModel.Composition.Hosting.AssemblyCatalog.get_InnerCatalog()
[and a lot of more lines...]

I submitted some bug tickets, write to some Telerik’s developers but no right answers, you know, the usual.

Well, I decided to see what’s happened, so I did what every other developer would do, attach your debugger to Visual Studio and then found the issue. JustCode is trying to load the assembly Microsoft.VisualStudio.CSharp.Services.Language, Version=10.0.0.0 but in a machine without Visual Studio 2010 this assembly didn’t exist, it’s unique of a Visual Studio 2010 installation. Of course, I’m using a Virtual Machine snapshot, I don’t have a previous version installed. The assembly present in my VS2011 installation is Version=11.0.0.0.

The easy way to fix it? Go to a Visual Studio 2010 installation, copy the assembly Microsoft.VisualStudio.CSharp.Services.Language.dll from the Common7 directory and paste into your Telerik’s JustCode directory, that’s all, JustCode now it’s going to load. Maybe this would cause some other problems, but come on, it was my first attempt! =)

Probably a better way to fix it would be using assembly binding redirection, or taking care of the fact that maybe a previous installation it’s not present maybe in the installation process. I’m just saying!

Note for developers in general: it’s a good idea to test your installation in a pristine installation before release it to the wild, just to see what’s happening, you know, just in case =)

El concepto de “capas” o “layers” me parece desde unos años para acá tan ortodoxo, viejo, fuera de lugar, obsoleto, mal aplicado, afuera totalmente de contexto. La idea de capas tenía mucho sentido hace décadas atrás (tampoco décadas pero fue hace tiempo) cuando los programadores cavernícolas (en los cuales me incluyo yo picando piedra) teníamos que depender fuertemente en la base de datos, hacíamos las consultas en plano SQL, insertábamos directamente en plano SQL, y si mi DB me la movían literalmente movían mi aplicación.

Esto tenía todo el sentido del mundo en nuestras aplicaciones no tan complejas y sin mucha orientación lógica que hacíamos en aplicaciones desktops o web, o sea, en vez de escribir cientos de líneas SQL esparcidas por doquier en nuestro código de php (por ejemplo), mejor lo abstraíamos todo en un solo lugar donde estaba guardadito nuestro SQL, ahí en su cajita, donde nadie lo tocaba y si alguien lo tocaba era una vez (como que si tocar una consulta no involucrara cambiar algo… silly us). Esto se llevó un paso adelante y en vez de poner consultas como SELECT * FROM [tabla] mejor usamos SP’s, así que cambiamos eso por EXEC usp_MiConsulta, esto dio origen a otro problema, pero vamos a ir al grano primero.

En ese tiempo la gente comenzó a percatarse de algo, si abstraigo las consultas a la DB, luego las llamadas a la DB en otro lado, puedo entonces poner la “lógica” de negocio en otro lado y sobre ella hacer la UI. Esto tenía mucho sentido y asi nació el concepto de “layers”… Tiene sentido, tenía sentido en ese tiempo, teníamos aplicaciones con el “típico” color aqua y un par de botones con iconos de puertas y equis tachadas en primera plana, con una grid para mostrar facturas y un botón donde agregábamos una factura nueva (generalmente con el icono más o con un lapicito que aun no entiendo porque aparecía ahí).

Luego vino la moda SOA (que pareciera nunca acabar) y dijeron, va, ahora en vez de hablar directamente la lógica con la data, vamos a tener alguien en el medio que expone esa data por un servicio. Entonces hablamos de SOA… como ya no eran 3 capas si no 4 o más renombramos el modelo a n-Capas…. y aun me perfora el oído escucharlo….

He visto degeneraciones de este modelo, un “buen” ejemplo son las aplicaciones ejemplo de MS, donde abstraen todo a servicios que al final el mismo objeto desde el comienzo al fin es el mismo. Es increíble pero he visto a desarrolladores veteranos que aun insisten en usar su versión de servicio para exponer todo, pero esa es otra historia…

Nuevamente recalco, eso tenía sentido *en ese tiempo* los ORM’s o no existían o eran sumamente rudimentarios, la mayoría de db devs que habían estaban aún acostumbrados a hacer _todo_ en la DB (no, en serio, una vez vi una app que hasta el proceso de pago de paypal era hecho internamente en la DB), tenía sentido cuando tu aplicacion era la tipica aplicación con botones grandes y background aqua… Tenía sentido cuando decías que abstraías el acceso a datos en una clase que por lo general comenzaba por una pequeña clase con un par de métodos y terminaba como cientos… porque tal cosa como reutilizar el acceso a datos se tornó un santo grial.

Eso no tiene sentido HOY, cuando nuestros objetos son (o deberían ser) ricos en comportamiento, cuando modelamos en base a lo que _va a pasar y hacer nuestra aplicación_ no en cuanto a la data que va a contener la base de datos (puntos extras para el que comprenda la diferencia entre ambos approaches en la oración anterior). No tiene sentido hoy que nuestra “lógica de negocio” realmente puede ser embebida en el objeto del dominio o de negocio, donde hacemos una distinción entre lógica de negocio (o reglas del negocio) y lógica de presentación (que como dice el nombre solamente afecta la vista). No tiene sentido cuando no interactuamos contra solo una base de datos si no contra base de datos, archivos, servicios (y generalmente varios). No tiene sentido porque no le veo ni cara ni cuerpo a tener un ORM (por simple que sea) y envolver las mismas entidades y exponerlas mediante otras entidades que contienen los mismos símbolos, no tiene sentido hablar de capa de acceso a datos ya que tus Objetos de ORM no solamente viven ahí y pueden contener la lógica que tanto necesitas en la “siguiente” capa. No tiene sentido en un mundo donde el programador está acostumbrado (y hasta espera) que la consulta se genere automáticamente mediante Linq, no tiene sentido en un mundo donde ya no escribimos SQL a mano.

¿No te gusta un ORM porque tiene demasiada carga para lo que necesitas? bueno usa un MicroORM… y aun así sigues sin hablar de capa de datos, tal cosa ya no existe. Ni siquiera Microsoft con sus prácticas habla de layers…. Vamos, ahora ni en PHP puedes tener el coraje de decir que tienes que escribir SQL a mano, porque entonces abstraer todo en una “capa”, ¿quieren producir algo de misterio? Traten de preguntarle a un programador de Rails donde está su capa de datos, no existe, ¿porque?… No es necesaria tal separación.

Ahora, lo que si debes distinguir es el concepto de Tiers, una aplicación si va a tener varios Tiers, la base de datos (a menos que sea embebida) vivirá y es por definición un tier, ¿expones servicios? bueno, otro tier mas…. Un tier es una separación física de la cual no puedes deshacerte, una layer es una separación lógica que realmente no tiene sentido en un mundo ágil donde no usamos 6 meses “diseñando” la aplicación.

Algún día ordenare todos mis pensamientos y terminare escribiendo un poco más sobre porque el concepto de layer sigue siendo obsoleto, por lo menos para mí.

NOTA: Este fue un largo correo en la lista de Alt.Net hispano que termino siendo tan largo que llego a ocupar un blog post.

Well, one of the awesome points in mfakes it’s to abstract mocking frameworks, so mfakes provides adapters for popular mocking frameworks like Rhino Mocks, Moq, NSubstitute and FakeItEasy. So instead of thinking which one to use, just concentrate in the test. Simple.

Anyway, there was a feature lacking in mfakes, and as every developer when something it’s lacking a feature you just go ahead and implement it, nothing beats open source. The interesting point was trying to “wrap” different way to interact between every mocking framework, everyone has a different way to see the world, it’s not bad, but it’s different. I found a very interesting problem with FakeItEasy and constructor parameters in a Mock.

In most mocking frameworks there’s an easy way to specify constructor parameters for a mock, in Moq, for example, you just do something like this:

var foo = new Mock<T>("foo", "bar");

// Generate this it's easy, it's just a simple generic type
// with a parameter list

public object CreateFake(Type interfaceType, params object[] args) {
    var closedMockType = typeof(Mock<>).MakeGenericType(interfaceType);
    var objectProperty = closedMockType.GetProperty("Object", closedMockType);
    var instance = (args != null && args.Length > 0)
        ? Activator.CreateInstance(closedMockType, args) : Activator.CreateInstance(closedMockType);
    return objectProperty.GetValue(instance, null);
}

The problem it’s that FakeItEasy it’s magic, and uses a very nice strong typed way to do it

var foo = A.Fake<FooClass>(x =>
    x.WithArgumentsForConstructor(
        new[] object {"foo", "bar"}));
// Another way to do it, more strongly-typed
var foo = A.Fake<FooClass>(x =>
    x.WithArgumentsForConstructor(
        ()=> new FooClass("foo", "bar")));

Well, if you think about that, there’s not a simple way to abstract a non-generic, non-typed expression with a generic, strong-typed, functional expression, well, not a simple way to do it at least you use the expressiveness of binary expression trees. How do we abstract this? well, let’s see the simple expression:

Now, let’s create a function to return that expression based in parameters, let’s abstract everything with the only knowlege of the type and the parameters:

// Transforming this:
var foo = A.Fake<T>(Action<IFakeOptionsBuilder<T>> opts)

// Implies something like this
public static Delegate CreateForType(Type type, object[] args) {
    var optType = typeof(IFakeOptionsBuilder<>).MakeGenericType(new[] { type });
    var actType = typeof(Action<>).MakeGenericType(new[] { optType });

// Now we have the type for the action and the options builder
// Let's use it to create an expression tree!

    var r = Expression.Parameter(optType, "r");
    var method = optType.GetMethod("WithArgumentsForConstructor", new[] { typeof(IEnumerable<object>) });
    var p = Expression.Constant(ctorArgs);
    var call = Expression.Call(r, method, p);
    var lambda = Expression.Lambda(actType, call, new[] { r });
    var exp = lambda.Compile();
}

And well, now that we have the function to call (we generated it), it’s time to create the fake

public object CreateFake(Type type, params object[] args) {
    var closedFakeType = typeof(Fake<>).MakeGenericType(interfaceType);
    var objectProperty = closedFakeType.GetProperty("FakedObject", interfaceType);

    var options = args != null && args.Length > 0
        ? FakeItEasyHelper.CreateForType(interfaceType, args) : null;

    var instance = args != null && args.Length > 0
        ? Activator.CreateInstance(closedFakeType, new object[] {options})
        : Activator.CreateInstance(closedFakeType);

    return objectProperty.GetValue(instance, null);
}

See? that’s the reason because Functional programming it’s so awesome, functions are just another variable, you can generate them, use them, modify them, use them. Next time you have a problem try to think in a functional way, you will see how awesome is!.

More about Expression Trees in the amazing book C# in Depth, Second Edition by John Skeet or go and pick a functional language (like this Programming F#), study it, enjoy it, use it in your favourite non-functional language.

Happy coding!

NOTE: the patch it’s already included in mfakes, no worries!

Even if you are not a programmer you cannot avoid using Ritchie’s legacy, the Windows operating system you are using? well, took many of its ideas from Unix, and it’s made in C. Are you using MacOSX? well, guess what, it’s made in C. Well, you are a PHP developer? PHP is made itself in C and it’s obvious where the syntax it’s coming from. Even “modern” C#/Java/Python/Ruby developers cannot avoid it’s legacy.

Sir, we are going to remember you with every line of code we write. We owe you too much to be able to measure.

Do you have a blog? Give Dennis Ritchie the tribute he deserved, the one the media won’t give him. http://t.co/bsFFbAA8

UPDATE: Saddest piece of code ever http://t.co/Xp5EmFRg

In the last year I’ve been facing so many different problems as a developer and consultant with different customers, different technologies, different use cases, so many different areas of knowledge. Today I was thinking about the ideas about Gibbs theories and I saw something interesting with my developer life and how they are related.

You’ll see, one day my professor just explained how the Gibbs free energy is related to the human body chemical reactions and how the Entropy is important in everything that happen in human life, including relations. So at the end everything concludes in a simple fact: “you will get the complete equilibrium when you die”. Many developers look for a constant equilibrium in their life’s, some of them spend many years doing the same and making themselves confortable with the same thing, same technology, same platform, same risks, maybe they expect to face tomorrow the same problems they faced today, maybe they are looking for a zero entropy in their developers’ life.

Personally I like the fact to learn new things everyday, to face new problems, new challenges, maybe it’s the fear to have zero entropy in my life and realize I’m just death.

Maybe you need a little more of Entropy in your working life, what do you think?

A little more about Human Thermodynamics.

Si quieres saber mas acerca de las VAN para la comunidad de Alt.Net Hispana acercate a su homepage, tienen de todo para todos =)

Y claro esta, las diapositivas usadas:

Referencias:

• What’s new in ASP.Net 4.5 http://www.asp.net/vnext/whats-new
• Scott Hanselman y ASP.NET v4.5 http://bit.ly/n7YlWW
• Scott Guthrie y ASP.NET v4.5 http://bit.ly/o4m4CC
• What’s new in everything 4.5 http://bit.ly/oqbUAk
• Download Webmatrix 2 beta http://bit.ly/qw1AbU
• Extending Webmatrix 2 beta http://bit.ly/nr5P1w
• More about Extending Webmatrix 2 beta http://bit.ly/p1RstO
• Webmatrix 2 beta features http://bit.ly/phcmcf
• Damian Edwards talk at BUILD http://bit.ly/psQgZb
• Mattheuw Osborn talk at BUILD http://bit.ly/r7n4I2
• Vishal Joshi talk at BUILD http://bit.ly/pXch2B

Recently a friend of mine asked me the following question:

As we have several apps created into the same output folder they all override each others Nlog.config files.
I was wondering what is the best approach for that? Should I provide nlog configuration in app.config file? it doesn’t let me name NLog.config differently….

This is a very common question, looks like they have many exe files in the same directory, and they are using a nlog configuration file to configure the logging. Of course, if you are running two applications in the same directory with the same nlog file the logging settings will be shared between both applications. The answer to this problem is easy, use an specific nlog file for each application. That means: if your application is named app.exe your specific application nlog configuration should be called app.exe.nlog. If you want to automatically rename the file after compilation it would be a good idea to create a post build action in your proj file to do so, easy and clean.

The order in which nlog locates the configuration is easy to remember:

1. Configuration section in your application configuration (app.exe.config)
2. Specific nlog file for your application (app.exe.nlog)
3. nlog.config file
4. nlog.dll.nlog file

There is more in the official nlog documentation

By default all the extensions in Expression blend made by 3rd party developers would live in a MEF directory catalogue under the folder Extensions in the installed path of your Blend application (the same happen for Expression Web). To “register” our application we need to provide a special bootstrapper known as Package, this special class implement the contract IPackage and takes care of our extension initialization (you know, things like registering your own services or adding things to blend) and when everything finish, provide support for cleaning up routines.

I mention a very common word in software development, services, the base of Expression extensibility. Every time we expose a new functionality to Blend we need to create and register a service and of course we will be consuming other services in our extension. The way to access this service collection is through the contract IServices, it exposes two important methods: Load and Unload, well, we will cover some important exposed core services in this series but if you want you could start taking a look by yourself using any “decompiler” tool like Red Gate’s Reflector, Jetbrains’ DotPeek, Telerik’s JustDecompile or the now popular ILSpy. Go feel free to start playing with them.

Well, no more to talk, let’s create our first simple package

1. Add a reference to Microsoft.Expression.Framework and Microsoft.Expression.Extensibility tell to Visual Studio to never copy those assemblies to output. Those assemblies are in the Expression Blend installation directory
2. Add a reference to System.ComponentModel.Composition, this library is in the GAC
3. Create a class library for your extension
4. Tell to Visual Studio to copy the output directly to your Expression Extensions directory

1. Specify your library will be named with the postfix .Extension, this is needed for the MEF Extension Catalog to load the assembly, sort of convention.

1. To easy your development effort, tell to Visual Studio to run Expression Blend when you debug the extension.

1. Write the code for your “Package”

The code for your package would be very simple, let’s output to the debug output a simple message

using System.ComponentModel.Composition;
using Microsoft.Expression.Extensibility;
using System.Diagnostics;

namespace SampleExtension01 {
    [Export(typeof(IPackage))]
    public class SamplePackage : IPackage {
        public void Load(IServices services) {
            Debug.WriteLine("Hey, I'm in!");
        }

        public void Unload() {
            Trace.WriteLine("Boo! time to go =(");
        }
    }
}

Now we just run the Extension and look, our package works!

There are some differences in the way we create and register an Add-In instead of an Extension, but I think the bloggers around there already pointed them.

Now, the next time we are going to start doing a little more complex things, I promise =)

Meanwhile I let you with some links to people who explain a little more about the same thing:

• David Burela’s blog post about using Visual Studio to create Blend plugins: https://davidburela.wordpress.com/2010/02/02/guide-to-creating-expression-blend-3-addins/
• Tim Koke wrote a good beginning tutorial about the same subject: http://www.timmykokke.com/2010/03/building-extensions-for-expression-blend-4-using-mef/
• There’s a really good article in CodeProject about it: http://www.codeproject.com/Articles/75961/Building-extensions-for-Expression-Blend-4-using-M/
• Scott Barnes blog posted something about it too: http://www.riagenic.com/archives/275
• Jeremy Alles wrote a little about debugging a live compiled application using Reflector (in this case I can ensure you it’s Expression Blend): http://www.japf.fr/2010/03/debug-any-app-in-visual-studio-without-the-original-sources/

You can get my sample code from Bitbucket. https://bitbucket.org/cprieto/extendingblend

NOTE: The index of the series could be found here http://cprieto.com/index.php/2011/09/17/a-week-extending-blendintroduction/

Well, Expression Blend 4 (and the whole Expression Suite by Microsoft) is created around this principle using the Microsoft Managed Extensibility Framework (MEF)http://msdn.microsoft.com/en-us/library/dd460648(VS.100).aspx to handle extensibility concerns. I strongly recommend to become familiar with the principles around MEF and take advantage of this amazing framework. Before Expression Blend 4 Microsoft used MEF “kind of predecessor” the Extensibility Add-In Framework in the .Net Framework 3.5 (available also in 4.0 of course). So with this in mind we need to differentiate between two different types of extensions in Microsoft Expression:

• Add-Ins: It’s the old way to extend Expression, this model is available from Expression Blend 2.0 to Expression Blend 4.0, it’s not as flexible as the Extension model but together expose the same functionality and works almost in the same way. If you need to support versions before 4.0 this is the model you need to use.
• Extensions: It’s the new way and uses MEF as extensibility mechanism. If you love things like Inversion of Control and auto discovery this is the model you need to use. It is very similar to the Visual Studio Extensibility Model and I hope one day in the future both models would merge together (so we can share extensions from one package with the other, just imagine that, well, I can dream). We are going to use this model for our samples and mention the differences with the classic Add-In model when necessary.

A primer to MEF

MEF is the extensibility core for Microsoft Expression Suite, it’s an amazing framework to handle concerns about discovery, dependency, lifetime and registration of components for extensions. This framework is used by other Microsoft products like Visual Studio. We are not going to cover the usage and basics around MEF, but before continue with the series I strongly recommend you to take a look at some basic MEF tutorials like the simple tutorial written by Brad Adams or the walkthrough in the MEF home page in Codeplex. Go ahead, take your time and have fun with the joy of using MEF.

UPDATE: After publishing the post I just realized a big mistake in it, MAF (Managed Add-In Framework) it is not MEF predecessor, it’s just another “application extensibility model” different than MEF, maybe in the next future I will talk a little more about it. Sorry for my mistake!