martes, 29 de diciembre de 2015

Generación de metainformación de elementos de código.

Así que la ultima versión de C# incorpora nameof como palabra clave para poder quitarnos de en medio bastantes de las horribles cadenas mágicas que el framework nos obliga a escribir.

Muy poco a poco, gracias a los genéricos, expresiones lambda, funciones y tipos anónimos, dynamic, expando, etc, nos estamos quitando una enorme cantidad de cadenas mágicas del código.

En mi opinión nameof se queda corto. Yo por mi parte llevo años utilizando una plantilla T4 que se encarga de generar metainformación de las estructuras de datos de un proyecto en tiempo de diseño, para luego poder utilizarla en tiempo de ejecución sin tener que usar ni la lenta reflexión en tiempo de ejecución ni las horribles cadenas, que me organizarán un pifostio enorme el día que cambie una triste clase en código fuente. A ver cuando MS se pone las pilas y hace algo parecido pero que este bien integradito en el VS y tenga más flexibilidad.

lunes, 28 de diciembre de 2015

Help wanted

Últimamente estoy metido en demasiadas movidas. Bots de Telegram, procesadores de lenguaje en  NodeJS y forks de github.

Con respecto a los forks de github, tengo uno a medio terminar para un pull request pero no doy abasto. Concretamente se trata de un fork de Newtonsoft.Json al que le estoy agregando soporte mejorado para GUID, URI y todas esas clases en .NET que en realidad son cadenas y/o churros de números que se han convertido en clases en el framework para ofrecer un mejor manejo.

TODO por orden de importancia:

Soporte GUID para versiones .NET < 4.0 (no exite TryParse y hay que currárselo a mano)
Test unitarios para todo el soporte nuevo de GUID.
Soporte URI todas las versiones.
Test unitarios para todo el soporte nuevo de URI.

Si algún espabilado tiene ganas de ponerse al tema es libre de clonar mi repositorio y ofrecer sus cambios.

Happy coding bastardillos.

jueves, 3 de diciembre de 2015

Los colorines que importan.

Ya he comentado en algún caso que todo buen desarrollador de software que se precie debe tener una mente despierta con respecto a los malos olores que puede desprender el diseño e implementación de un sistema de información.

Una cosa que ayuda a detectar estos malos olores es escoger los colorines adecuados en el editor de código fuente. Esto ofrece una ayuda visual para detectar esos malos olores.

martes, 1 de diciembre de 2015

Extensiones de Visual Studio Gratuitas

Para que no se me olviden, para ayudar a otros a encontrarlas y para que la gente comente sus extensiones favoritas y la lista se haga más larga, aquí va:


  1. Automatic Versions: Incremento automático de versiones de los ensamblados. Probablemente no siempre interese con la moda de CI&D y sus build bots, pero siempre está bien saber que lo tenemos.
  2. Build Vision: Visualización del proceso de build más cómodo y bonito. Una pijada tonta que me gusta tener.
  3. Code Maid: Formateo, limpieza, reorganización, etc. Comodidad sin pagar un chavo.
  4. Configuration Transform: Crea transformaciones automáticamente para cada configuración de build. Te quita curro oye.
  5. GhostDoc:  Para la documentación XML del código. También quita trabajo.
  6. JavaScript Parser: Productividad para JavaScript. Si a ti se te pone el pelo verde, como a mi, cuando tienes que leer JS de otro tío esta extensión te ayuda un poquito.
  7. Code Digger: Pequeña ayuda para ver lo mal que programas. Buena sinergia con Code Cotracts, MS Fakes y Test Unitarios.
  8. PowerShell Tools: Ahora que todo es PowerShell en el mundo MS esto te da una buena integración con VS.
  9.  Productivity Power Tools: Puñado de utilidades en el editor. Dicen que aumenta la productividad.
  10. Solution Dependency Viewer: Ayuda para ver lo mal que diseñas y la basura super acoplada que te esta quedando.
  11. SpecFlow: El Cucumber para .NET que tengo instalado y nunca he probado. ¿Alguien tiene algo que comentar sobre esta herramienta?
  12. T4 Editor: Yo soy muy fan de las plantillas T4. La versión gratuita es un poco capada pero aun así es útil.
  13. Visual F# Power Tools: Antes veías cine de autor Sur Coreano; ahora programas en F#. Eres un poser que va de indie pero ¡hey! tienes tus Power Tools como todo hijo de vecino.
  14. Web Essentials: Un porrón de cosas útiles y chulas para el desarrollo web. Incluso te inyecta mierda en el navegador del cliente para que perres tu app. Algún día aprenderé a utilizarla...
  15. LINQBridgeVS: Promete un montón ya que LINQPad me encanta pero no soy capaz de que me funcione en VS2013.


viernes, 6 de noviembre de 2015

Glimpse es un gustazo.

Pues aquí estoy jugueteando con Glimpse un rato viendo lo cómodo que es para diagnosticar aplicaciones ASP.NET. ¡Si hasta tiene versión para WebForms! No os podréis quejar...

Si además le instalamos el pluging para Elmah esto ya es la repanocha.

jueves, 5 de noviembre de 2015

La inyección de propiedades es el mal encarnado.

En StackOverflow no paro de encontrarme a gente preguntando como se realiza la inyección de dependencias en las propiedades, en vez de en el constructor, de una clase con tal o cual contenedor.

Las putillas kármicas que quieren puntos de reputación sin importarles lo demás un carajo se dedican a poner las 4 líneas de código de turno y se llevan sus 15 puntitos calentitos.

Yo, a costa de no recibir puntuación ninguna, prefiero responderles con ética y plantarles un "WRONG WAY, TURN BACK!!" bien gordo al principio de la respuesta y luego una extensa explicación que nadie se preocupa en leer.


jueves, 27 de agosto de 2015

El GET invisible.

Hoy por casualidad he descubierto un bug en un código PHP que permite realizar cualquier operación con la aplicación sin estar autenticado, y que no se detecta con las herramientas de depuración de los navegadores web.

El programador de la aplicación realiza de forma sistemática una comprobación de la autenticación del usuario al principio de cada página PHP y en caso de no estar autenticado envía al cliente un cabecera HTTP 302 Found. Cuando el programador probaba la aplicación, con el Chrome y sus herramientas de depuración de red, podía ver perfectamente como en cada GET sin cookie de autenciación el navegador recibía un código 302 y, en el cuerpo del response, un mensaje gordo que decía "Failed to load response data", que es lo que dice siempre que no hay cuerpo en la respuesta HTTP.


Indispensables (o no tanto) para empezar con Node.js

En una entrada anterior hice una reseña sobre mi primer acercamiento a Node.js. Esta entrada tiene por objeto agrupar en unas pocas líneas algunas anotaciones y recomendaciones sobre las herramientas necesarias para empezar a explorar este mundo. Aunque he procurado hacer algunas pesquisas adicionales, mi punto de partida es, como no podía ser de otro modo, el curso al que hice mención con anterioridad. 

Bien, ¿Por dónde empiezo? Estoy ávido de conocimiento. Quiero hacer un "Hola mundo" ya... 

Lo primero y más importante (y tan absolutamente obvio que podrías mandarme a tomar viento...) es instalarse Node.js en el equipo. Cuando empecé con el curso, los tutores (y varios sitios web que consulté) recomendaban trabajar en un entorno Linux porque "Node en Windows podía dar algunos problemas". Yo habitualmente trabajo con Windows 7, así que al principio me rondó la idea de instalar un VirtualBox o similar, pero finalmente decidí arriesgarme con la instalación para Windows y no tuve mayores problemas. Podéis descargar el archivo .msi en este enlace. Una vez instalado tendremos a nuestra disposición todo un abanico de módulos que nos facilitarán la vida en el desarrollo de aplicaciones. 

jueves, 20 de agosto de 2015

Trasteando con Node.js y JavaScript

De un tiempo a esta parte me estoy aficionando a los MOOC (Massive Open Online Course). Me parece una magnífica manera de satisfacer mi curiosidad y de enriquecerme un poquito profesionalmente, ¡Y por un precio muy módico! De hecho creo que de disponer de más tiempo podría llegar a convertirse en una verdadera adicción afición. Hace algún tiempo conocí una plataforma en castellano (también en portugués) que se llama MiriadaX. Hice con ellos un curso de HTML5, CSS y Javascript, desarrollado por la Universidad Politécnica de Madrid y, salvando los inconvenientes y pequeñas carencias de este tipo de plataformas, me gustó bastante y me dejó cierto poso, sobre todo en lo referente a hojas de estilo. 

Hace poco he terminado otro, también de la Politécnica de Madrid, sobre servicios en la nube y Node.js. No es que me vaya a convertir en un experto en Node.js (Probablemente eso no ocurrirá en un plazo de tiempo razonable... ¡más quisiera!) pero me ha dado dado una buena overview y sobre todo me ha dejado con ganas de aprender más. Como estas cosas, si no se practican, empiezan a olvidarse casi en el mismo momento en el que presentas el último ejercicio, me hubiera gustado revisar profundamente todos los temas del curso en el blog, pero lo cierto es que el tiempo del que dispongo es muy limitado, así que no voy a hacerlo; aunque probablemente sí que iré dejando algunas píldoras... Dicen que tratando de explicar algo es como mejor termina de comprenderlo uno mismo. Sea, al menos, por tener donde agarrarme cuando quiera recordar alguna de estas cosas... 

jueves, 13 de agosto de 2015

Querying the Domain.

En una entrada en SapiensWorks sobre DDD he tenido una interesante discusión que voy a dejar aquí para que no se pierda en un futuro.

Esto es una de las lineas del post:
CQRS: have one model (behaviour and data) handling business state changes and at least one other model handling non-domain queries
Y esto los comentarios generados:

lunes, 29 de junio de 2015

Specification Pattern en .NET

Esta entrada es para que no se me olvide. Siempre que trabajo con árboles de expresiones me paso la primera hora mirando la documentación tratando de recordar las 2 malditas líneas que te permiten combinar 2 expresiones Lambda.

viernes, 19 de junio de 2015

Los Microservicios requieren macrodiseño.

Respondiendo una pregunta en StackOverflow sobre el tema; me he dado cuenta que la cosa daría para una pequeña entrada.

Microservicios es la palabreja de moda. Antes de que la mayoría de empresas medianas en vías de desarrollo hayan podido siquiera empezar a implantar decentemente SOA y ESB's en sus procesos de negocio informatizados ya salta algún geek que te dice que eso esta out; que el camino a seguir son los microservicios.

martes, 16 de junio de 2015

Asúmelo y sigue

Tienes una base de datos relacional cuyas tablas tienen -todas- identificadores automáticos; no tienes modelada ninguna herencia del dominio; tienes restricciones contextuales que no se representan en el esquema de persistencia (relación uno a uno si una entidad es de un tipo o uno a muchos si es de otro tipo, así que ponemos uno a muchos y ya controlamos desde código que se cumpla), tus VO aparecen, desaparecen y cambian constantemente; la mitad de tu persistencia son meta-datos no relativos directamente al dominio de la aplicación; no tienes borrados en cascada; tus entidades tienen datos que son mutuamente exclusivos... y tantas otras cosas como estas que sé que tienes.

martes, 19 de mayo de 2015

Dale la vuelta antes de decidir.

No, en este post, no voy a recomendar que se cuelgue uno del pie para que llegue más sangre a la cabeza, se oxigene mejor el cerebro y se gane un par de puntos de C.I.

El título de este post proviene de ver como, muchas veces, las decisiones en cuanto al diseño y desarrollo de un sistema de información se hacen al revés. Por esto, recomiendo que siempre le deis la vuelta a la solución que se os a ocurrido y la analicéis en profundidad para determinar si es una mejor solución.

Los resultados de estas decisiones desastrosas es lo que se llama "Gran bola de lodo" y estoy seguro que muchos de vosotros lo habéis sufrido en algún modo o lo estáis sufriendo ahora mismo.

viernes, 8 de mayo de 2015

La concurrencia y el estancamiento de datos no es lo mismo.

Hablando con un compañero de trabajo me he percatado que todavía hay quien no entiende la diferencia entre los problemas con el estancamiento de datos y los problemas con la concurrencia cuando se trabaja con persistencia. De hecho el problema no es sólo entender la diferencia de estos 2 conceptos; si no comprender también el proceso que debe seguir la aplicación para aplicar correctamente los cambios en una entidad persistida y con acceso concurrente.

jueves, 19 de marzo de 2015

Un puñado de Servicios Web NO es SOA

Me habían pedido que le pegase un vistazo a un nuevo proyecto de integración y al abrir la presentación del proyecto, en la tercera página, me encuentro con las letras SOA. ¡Imposible! me digo. SOA se basa en ofrecer servicios con bajo acoplamiento que se encargan de la orquestación y coordinación de procesos de negocio, los cuales pueden implicar uno o varios dominios.

Se de buena tinta que no se han definido es esta compañía dominios lógicos (por lo tanto no existen fronteras entre dominios), ni planificados procesos de negocio estándar, no hay coherencia ni contexto; por lo tanto no se pueden modelar servicios que coordinen ni orquesten nada. Ni siquiera existe un lenguaje ubicuo con el que entenderse. SOA no es un patrón arquitectónico tecnológico, es un patrón arquitectónico para modelar la organización lógica del negocio en servicios flexibles, escalables y sin dependencias; si no hay organización no puede haber SOA.

Cuando abrí el documento del catálogo de servicios mis sospechas se confirmaron. Lo único que hay es un puñado de servicios web que hacen cosas sueltas y completamente descontextualizadas.

No quiero poner en evidencia el equipo de desarrollo de la plataforma; estoy más que seguro que son gente lista y competente. No es su culpa. En las condiciones actuales es IMPOSIBLE montar una arquitectura orientada a servicios.





martes, 17 de marzo de 2015

Procesos de negocio de larga duración.

Cuando se modela un sistema, el cual está constituido por un conjunto de procesos de negocio, no es difícil percatarse de que existen procesos de negocio que tienen una larga duración. Esto nos genera una situación en la que el flujo de trabajo se convierte en una máquina de estados intermedios desconectada en espera de los eventos para continuar hasta su resolución final.

martes, 3 de marzo de 2015

Mantén el historial GIT limpio.

Prisas, despistes, inoportunos de última hora, dobles interpretaciones, gerencia inestable (en más de un sentido ;) ). Todas estas cosas, y muchas más, son las que provocan que acabemos con varios commits en el repositorio local de GIT para un work item que en un principio tiene bien definido el "Done" y sus fronteras. Esto genera un historial lioso e ilegible que no debería reflejarse en las ramas remotas. La mayoria de las veces, un ammend soluciona los líos; en otras se requiere una medida una tanto más drástica.

Supongamos que hemos generado 4 commits locales a partir de la rama remota para finalizar work item. En la rama remota lo único que interesa es el commit que refleja todas las modificaciones realizadas necesarias para el work item; por lo que antes de realizar el push debemos reescribir el historial de la rama local y "aplastar" (squash) todos los commits en uno sólo.

Por suerte, GIT nos permite reescribir el historial utilizando el comando rebase. Asumiendo el ejemplo anterior sólo necesitaríamos ejecutar el comando:

git rebase -i HEAD~4
y nos aparece un editor con los 4 últimos commits a partir de donde está la etiqueta HEAD. En este editor debemos marcar el primer commit con la opción "pick" y el resto con la opción "squash". Básicamente le estamos diciendo que combine los 4 commits en el primero.

El resultado final es un solo commit que contiene todos los cambios realizados para la finalización del work item. Ya sólo queda realizar el push a la rama remota sin más complicaciones.


lunes, 23 de febrero de 2015

Las cosas chulas de HTTP/2

Ya tenemos el draft 17 del protocolo y la cosa está bastante consolidada. También hay un buen puñado de implementaciones. Pero, ¿que podemos esperar a grandes rasgos de este nuevo protocolo por mucho que cambien cosas en los sucesivos draft? Os voy a contar, así a salto de mata, con lo que os vais a encontrar.

La API no cambia

HTTP/2 no introduce cambios en las cabeceras, códigos de estado, verbos, etc. Teóricamente, podrías sustituir la librería HTTP/1 que usas actualmente por una HTTP/2 y no deberías tener que cambiar ni una sola línea de código.
Esto no quiere decir que no existan mejoras en la API que agreguen nuevas capacidades y mejoras al protocolo, pero éstas son de uso opcional y, aunque recomendadas, su aplicación se puede posponer.

Request ligeros y baratos

Con HTTP/1, los request son caros y pesados. Tanto es así, que han surgido una gran variedad de técnicas para reducirlos, como puede ser el inlining , el spriting o el batching.
HTTP/2 reduce en gran medida esa pesadez usando multiplexación de varios mensajes HTTP a través de una sola conexión. Esto permite que utilizando una sola conexión abierta se puedan enviar varios mensajes al servidor y además éstas no se bloquean entre ellas.
HTTP/2 también comprime las cabeceras, por lo que nos ahorramos un montón de ancho de banda. Esto es genial para clientes de celulares que suelen tener limites de datos y para Single Page Applications (SPA) que realizan un montón de requests cuyo body suele ser muy pequeño (un par de Identificadores de entidades y poco más)

Cache pushing

Aunque el computo de tiempo de carga final sea el mismo, siempre queda mejor, de cara al usuario, una espera inicial más larga (app bootstrap) y que el proceso posterior, mientras se trabaja, sea más fluido.
HTTP/2 permite mandar datos al cliente explícitamente para su cacheo y futuro uso. También permite  al servidor invalidar o actualizar esa cache de forma proactiva.

Protocolo binario

HTTP/2 ya no esta basado en texto. Es binario puro. Esto minimiza la carga de procesamiento del request/response, ocupa menos ancho de banda y es más simple y menos dado a errores. El problema de la depuración se tendrá que solventar con nuevas herramientas. De momento, el sniffer de red más popular, WireShark,  ya tiene un plugin para esta tarea.

domingo, 22 de febrero de 2015

viernes, 6 de febrero de 2015

martes, 27 de enero de 2015

Un proyecto en NetBeans de principio a fin (VIII). Integración transaccional de la lógica de negocio

¡Ey! Ya creíais que había terminado hasta el gorro de este tutorial y que no volveríais a ver un tostón de este calibre ¿Eh?. Lo cierto es que el trabajo y otros avatares (como que se me fue al garete el proyecto de NetBeans con el que estaba llevando este tutorial paso a paso...) han hecho que pase tanto tiempo desde la última entrada (creo que exactamente un año) que a punto he estado de darlo por perdido, olvidado, defenestrado y enterrado... Sin embargo aquí estamos de nuevo, al menos durante un capítulo más... ¡Qué no desfallezca el ánimo! (no hay otra forma de afrontar esto)...

En fin que me enredo, el objetivo de esta unidad es explicar las bondades del mapeo objeto-relacional, u ORM por sus siglas en inglés (Object-Relational Mapping), proporcionado por las tecnologías EJB y JPA para recolectar datos de una petición web y escribirlos en una base de datos en el back-end. Básicamente, ORM es una técnica de programación que permite convertir los datos entre el sistema de tipos usado por un lenguaje de POO y una base de datos relacional, utilizando un motor de persistencia.

El modelo de dominio es EL MODELO.

Diseñar primero el esquema de datos en persistencia es un fallo tremendo y, por lo visto, muy común.

El Dominio es la razón por la que la aplicación existe y todo debe gravitar alrededor de el. El dominio no debe depender de nada, y mucho menos de detalles de implementan de persistencia.

El esquema de persistencia debe de estar al servicio del modelo de dominio y no al revés. Una vez que se tienen diseñadas las entidades, sus relaciones y los servicios de dominio es cuando se debe crear un esquema de datos que permita persistir en el tiempo esa información.

Si diseñamos el esquema de persistencia primero; nuestros servicios y entidades se van a ver llenas de hacks y workarrounds de lo más bizarros, que permitan casar los casos de uso del dominio con la persistencia; puesto que ésta no ha sido diseñada para el dominio, si no que ha sido diseñada simplemente para evitar redundancias e inconsistencia de datos sin tener en cuenta las necesidades de las operaciones y reglas del dominio; ya que estas todavía no han sido analizadas, modeladas ni probadas.

Esta es la razón por la que Eric Evans recomienda empezar el desarrollo diseñando el dominio e ignorar completamente cualquier cosa relativo a la persistencia.

Es la persistencia la que se debe adaptar al dominio. Es por esto, por lo que existen incluso técnicas para adaptar un diseño orientado a objetos a persistencia relacional:


Tabla por jerarquía: Desnormaliza el esquema y utiliza una columna discriminadora.

Tabla por tipo: Representa herencia utilizando relaciones.
Tabla por clase concreta: La persistencia relacional no es consciente de ninguna herencia puesto que no se representa de ninguna manera.



Regla de Oro: Cuando desarrollas una aplicación la persistencia NO EXISTE. 


Primero diseña una aplicación que cumpla el dominio; en la que tus entidades estén simplemente en arrays en memoria y que cada vez que arranques la aplicación la información desaparezca. Una vez tienes esto completado es la hora de crear un esquema de persistencia que permita almacenar las entidades y sustituir los repositorios que almacenan y buscan en los arrays por repositorios que almacenan y buscan en persistencia; y todo esto sin modificar absolutamente nada del dominio.

Si diseñas primero la base de datos lo estás haciendo MAL y mal te saldrá la aplicación.

jueves, 22 de enero de 2015

Un blog maravilloso.



Muerto de sana envidia me encuentro con el descubrimiento de este blog que sólo puedo calificar de maravilloso.

Me encantaría tener la capacidad, los conocimientos y el sentido común de Marco Di Stefano para conseguir que mis entradas en este blog se parezca mínimamente al suyo.

http://www.refactoringideas.com/

Y este otro tampoco tiene desperdicio.

http://www.sapiensworks.com/blog/

jueves, 8 de enero de 2015

Arquitecura de Android SOLID(A) III

El controlador

En este ejemplo el controlador es extremadamente sencillo y puede que carezca de sentido pero pensad que en una aplicación real tendríamos, además de la modificación del modelo y del modelo de vista, lógica de aplicación, coordinación y orquestación de servicios, acceso a persistencia, etc.

El controlador es invocado por la vista y contiene la lógica para modificar el modelo y el modelo de vista en caso de ser necesario.


lunes, 5 de enero de 2015

Arquitecura de Android SOLID(A) II

El Modelo de Vista

El Modelo de Vista representa el estado de los componentes de la vista. Contiene variables que representan el estado de los controles como su visibilidad, si están activos, chequeados, si debe tener un color de fondo u otro, etc.

La lógica que encapsula el MV es la toma decisiones con respecto a la interfaz de usuario dependiendo de el Modelo y/o el estado de otros controles.

Por ejemplo, el MV podría contener el código y los estados que controlan si una lista desplegable se debe activar o desactivar dependiendo de si el usuario ha activado un checkbox y además cambia de color el fondo de una caja de texto para que al usuario no se olvide de rellenarla. Ofreciendo una función al controlador que tendría esta pinta :