Romialyo.NET SDK is public (with an ESB)

I've decided to publish the libraries I use for development in most of my projects. You can get it here, at github. It currently contains:

• Several extensions to the .NET Framework I found myself re-coding many times.
• An Enterprise Service Bus implementation, inspired in the good concepts from nServiceBus and RhinoESB.

Romialyo's ESB supports MSMQ and in-process message sending.

This ESB has become central to most of my projects so it was very important for me to have this code in a unique location and manage its versions properly.

Romialyo's ESB was started from the ground, trying to improve on nServiceBus code which I found hard to compile, extend and understand. The biggest stopper I found with nServiceBus was that it was too difficult for me to create an InProcess transport that will allow me to use the ESB as an Event Aggregator to communicate views in Smart Client applications.

In this blog post, Jeremy D. Miller exposes his conclusion about the "Event Aggregator = Service Bus" idea (braindump #12). I've been using a service bus with an events based in-process transport as the Event Aggregator in my applications for a while, and I must say I've found the idea very attractive.

TEAM's TimeTracker es realmente público ahora

Hoy he recibido una sorpresa: TEAM's TimeTracker pasa a formar parte de la base de software de Softpedia.

Siempre pensé que la aplicación era útil, sin duda lo ha sido para mi y para los Expectros que la utilizan a diario, pero tampoco hay dudas de que tiene demasiados errores.

Creo que esta noticia hará que le dedique un tiempo a pulirla un poco.

Verificación automática de las reglas de negocio

Contexto:
- Empresa muy grande e informatizada.
- Gran volumen de datos.
- Lógica de negocio complejísima.
- La empresa depende en todos los aspectos de que los procesos informáticos funcionen correctamente.

Pregunta:
¿Es posible que todas las verificaciones de los procesos sean manuales, que haya muchísimas dependencias temporales (X debe ejecutarse después de Y) y funcionales entre todos los procesos, y que NO SE DERRUMBE TODO?

Al parecer sí. El coste es alto: muchísimos desarrolladores y muchísimo esfuerzo extra, pero funciona.

Revisando Composite Application Block (Prism)

Después de descartar dedicarle tiempo a Caliburn, le echo un vistazo a Prism. El vistazo es rápido porque no necesito mucho tiempo para ver cosas que no me gustaría ver en mi aplicación.

- Me parece demasiado complejo. Over-architected sería la palabra en inglés. Se parece demasiado al MVP del Composite Web Application Block. Es una complejidad que sufrí una vez y que evitaré siempre que esté en mis manos.
- ¿Un HelloWorld con 2 proyectos, 4 clases y 3 XAML? Sólo eso es una mala señal, aunque por sí mismo no signifique nada.
- Al igual que Caliburn, crea demasiadas abstracciones nuevas encima de WPF. Esto implica mayor curva de aprendizaje y mayor probabilidad de perder el tiempo invertido.
- También se utilizan string mágicos para referenciar elementos importantes de la aplicación, como las "regiones".
- La comunicación entre "módulos" es muy compleja.

El código publicado en codeplex no se corresponde con la última versión.

Conclusión

Seguramente, al igual que Caliburn, Prism implementa mucha funcionalidad, pero el precio de utilizarla me parece demasiado alto: curva de aprendizaje, cantidad de abstracciones por encima de WPF, complejidad impuesta a mi aplicación.

Revisando Caliburn

Estoy revisando Caliburn y
no me ha gustado lo que he visto. Hago un resumen muy rápido e incompleto.

Sólo estoy revisando los ejemplos y lo que veo es:

- Demasiado e incorrecto uso de atributos. Preview, Rescue, etc contienen lógica de ejecución. Me parece muy poco intuitivo y alejado del modelo tradicional espeficar esos aspectos mediante atributos.
- Con los atributos, se pierde todo el chequeo estático de tipos, utilizando para casi todo strings mágicos.
- Demasiada lógica en los XAML. Por ejemplo, se enlazan comandos, acciones, etc, indicando en el propio XAML, mediante una sintaxis inventada, a qué elemento de la vista se le va a asignar el resultado de una operación realizada en un comando o en el Presentador. El compilador tampoco detecta errores aquí.
- Demasiadas abstracciones adicionales por encima de WPF, lo que aumenta la curva de aprendizaje y el peligro de aprender algo que no será útil en otros entornos.

En mi opinión, esto se aleja del ideal:

- Mantener todo lo posible el chequeo estático de tipos!
- Toda la lógica está en los ViewModel.
- Ninguna lógica en el XAML. En el XAML sólo debe hacerse DataBinds contra las propiedades del ViewModel.
- Los XAML de la aplicación deberían ser la mayoría DataTemplates, uno por ViewModel.

Conclusión

Quizás Caliburn ofrezca muchas funcionalidades ya implementadas, pero utilizarlo:

- Me obligaría a aprender todo un modelo nuevo que se aleja demasiado de M-V-P y de WPF.
- EL framework te dirije a una aplicación sin chequeo estático de tipos, y muy parecida a un código espaghetti enlazado mediante strings mágicos.

Cuba en el Clásico Mundial de Pelota

Al parecer, aquí se pueden ver los juegos de Cuba en vivo! No lo he comprobado.

telerebelde.ambacuba.org

Clásico Mundial de Pelota (béisbol, baseball, o como quiera que le llamen)

Aquí se puede ver el clásico en VIVO! Por supuesto, sólo transmiten un juego a la vez. La resolución no es ideal, pero es gratis, y algo es algo.