Archivos de solucion (sln) realmente no son solucion

Bueno, he leido una interesante entrada de mi amigo/colega de blog etomas y dedico estas breves lineas a responderle:

He trabajado con VS por mas de 12 años y desde hace un par de años vengo trabajando con Nodejs activamente y lo que puedo extraer de mi experiencia es que cuando existen dependencias compartidas, la mejor forma de referenciarlas es la ‘binaria’ (llamese binaria a la forma publicada y/o distribuida en .net es usando nuget en nodejs es usando npm) y es inevitable la apertura de multiples editores de texto por ‘proyecto’ no hay y hasta ahora no me puse en una busqueda formal de resolver este tema, pero yo te apoyo en el hecho de que los archivos de solucion realmente no solucionan nada, al contrario perjudican y voy un paso mas alla, creo que los archivos csproj tambien hacen lo propio, al estar en un formato bastante complicado de leer y mantener SIN usar VS, yo creo que la solucion podria ser el crear un nuevo archivo de texto editable al estilo de nodejs como package.json donde manualmente se referencian las dependencias usando versionado semantico, agregarle la posibilidad de referencias por directorio/folder y finalmente asumir que el ‘proyecto’ actual es el folder contenedor de ese archivo package.json (como lo hace nodejs), creo que hubo un intento de Microsoft de crear algo asi pero dieron media vuelta con asp.net core, en fin creo que otro tema que podria impedir crear una movida asi es tambien la compatibilidad hacia atras.
Hay mucho camino por recorrer y aunque me estoy alejando poco a poco de .net creo que hay formas en las que podria evolucionar para mejor, en sus estructuras de proyectos.

Saludos

Visual Studio, C# and Microsoft Programming State of the Art

Parece que Abril es el mes elegido para escribir entradas en este blog y aunque intento hacerlo con regularidad siempre estoy corriendo con algo mas. En fin, con el reciente lanzamiento de Visual Studio 2017, C#7 y con la inminente liberacion de la actualizacion de Windows 10 con el famoso “Creators Update” se  me han acercado personas a conversar sobre mi opinion del estado del arte en la programacion en las plataformas Microsoft/Windows y especialmente motivadas porque muchas de ellas han visto con extrañeza que mis ultimas charlas las he estado haciendo bajo Linux y la verdad es que desde hace algun tiempo atras estoy ‘volviendo’ a enamorarme de Linux y muchas de las posibilidades que abre a los desarrolladores.

Image result for windows 10 creators update linux

Visual Studio y C# son las herramientas per-se de aquellos que quieren producir para las plataformas Microsoft, sin embargo desde hace algunos años la hegemonia en el desarrollo ha sido rota por una nueva tendencia (ola), que no hace mas que crecer, el desarrollo basado en javascript, bueno miento, el desarrollo basado en open source, del cual probablemente javascript es el abanderado y liderando las preferencias se encuentra nodejs, si se que hay otros lenguajes y muy populares con increible crecimiento, pero dejenme decir que nodejs ha cambiado para siempre lo que una vez solamente fue C# y Java.

Plot-1

El desarrollo hegemonico que caracterizo la segunda ola, basado en frameworks robustos y cuasi-completos, como .NET y J2EE ha terminado. Pero que quiere decir esto?, que significa para los desarrolladores? Significa ‘evolucion’, nada negativo pienso yo, mas diversion probablemente, mas cosas por aprender, mas cosas por combinar.

Image result for open source

Microsoft esta liberando en la siguiente actualizacion una version estable y lista para los desarrolladores de su “Windows Subsystem for Linux” y aunque lo he estado diciendo en mis conferencias pocos me han prestado atencion, es sin duda alguna, una pieza fundamental en el cambio que Microsoft esta mostrando. La idea es atraer a aquellos desarrolladores que estan disconformes con los altos precios de equipos Apple/Mac, a aquellos desarrolladores que usan maquinas virtuales bajo Windows para hacer desarrollo y a aquellas nuevas generaciones de desarrolladores que estan entrando en el mundo del desarrollo Open Source.

WSL no solo es una estrategia para estar a la ‘moda’, es una cuestion de supervivencia para Microsoft, en unos años el codigo y soluciones C#-only sera ‘legacy-code’ y la mayor parte de las soluciones involucraran una combinacion de diferentes productos y librerias Open Source y los desarrolladores que tengan que lidiar con el mantenimiento de tales sistemas, se estan formando ahora y Microsoft debe mantenerse en camino, quiza no solamente como el proveedor de un unico framework sino con diferentes opciones para estos nuevos desarrolladores.

Image result for linux and mac

El exito de esta iniciativa solo estara dado por la libertad que WSL tenga, meses de foros y de sugerencias a los desarrolladores de WSL espero que hayan alimentado con todo lo necesario para que sea justo lo que todos necesitamos. Solo resta esperar unos dias mas hasta el 11 de Abril donde seguramente sabremos la verdad acerca de como Microsoft se ve a si misma en su ‘State of the art”

Libros recomendados para Arquitectura de Software

Generalmente recibo preguntas de que libros recomiendo para avanzar hacia la Arquitectura de Software y aunque repito constantemente una y otra vez estos libros, creo que es mejor dejarlos sentados en esta entrada:

El clásico de clásicos “Pattern Oriented Software Architecture: A System of Patterns“: Este libro contiene los principios de la arquitectura de software, describiendo perfectamente varios estilos de arquitectura que aunque algunos pueden considerarse en ‘desuso’ (no obsoletos, porque aprenderemos que aquello que algún dia es obsoleto puede volver a estar de ‘moda’) son principios muy útiles y vigentes hoy en día y probablemente en un futuro.

Otro ‘clasico’ escrito por Eric Evans: “Domain-Driven Design: Tackling Complexity in the Heart of Software“y a pesar de pecar de ‘viejo’ debo decir que este libro es una joya en cuanto a recomendaciones y fundamentos de muchos estilos o patrones de arquitecturas hoy en dia, quizá mi favorito CQRS, un estilo moderno (no siempre aplicable), incomprendido totalmente pero muy útil y versátil

El infaltable maestro Martin Fowler, aportando con dos clásicos e indispensables en vuestra biblioteca “Patterns of Enterprise Application Architecture” y “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions“, contienen un enfoque más contemporáneo a la arquitectura de software, sin embargo no descuida ni contradice a los autores de POSA, al contrario refuerza los estilos o patrones e introduce nuevos, con una explicación clara y usando referencias a lenguajes de programación ‘modernos’

Definitivamente hay otros muchos que están fuera de esta lista, pero estos han marcado el estado actual de mi profesión, espero que también les sea útil esta recomendación.

Saludos

 

 

Visual Studio Code & Intellisense mejorado

Desde hace algún tiempo estoy desarrollando en javascript, para ello he dejado de lado mi apreciado Visual Studio (fue complicado debo admitirlo) pero una vez que encuentras la herramienta adecuada, todo es mas simple. En mi caso lo mas adecuado fue Visual Studio Code, que aunque por el nombre parecería un Visual Studio tradicional o gratuito, como muchos tienden a confundir, pero nada de ello, es un editor de texto con esteroides J, su competencia mas directa es Sublime Text, que me estuvo tentando en mi desconocimiento de Visual Studio Code (VSCode).

Una de las cosas que mas se extraña de Visual Studio, es el Intellisense, aquella útil característica de autocompletado y sugerencias, Intellisense no es presisamente lo mejor en VS, hay necesidad de instalar las famosas WebExtensions al menos en la versión 2013 (aun no retomo mis proyectos ASP.NET en VS2015). Pero en VSCode parecía prácticamente inexistente la posibilidad de tener un Intellisense decente. He encontrado un interesante articulo en el blog de JhonPapa (cuando no) que habla de algunas sugerencias para mejorar la experiencia Intellisense en VSCode. Aquí no hago mas que extenderme un poco mas en la explicación, para no dejar lugar a dudas.

Configurando una forma simple

Ahh olvide mencionar que estoy usando Linux para mi desarrollo? (pues si aunque parezca extraño a aquellos que me conocen hace una década)

La mejor experiencia Intellisense que se puede lograr, es a travez de los archivos TSD (TypeScript Definicion), para ello sigan las siguientes instrucciones:

   

sudo npm install tsd -g

Instalando globalmente el tsd manager (otro package manager) 

tds install node 

Instalando el archive node.d.ts (en un momento muestro como ha quedado la estructura)

tsd install mocha

Instalando el archivo mocha.d.ts

tsd install chai

Finalmente instalando el archivo chai.d.ts

 

El resultado de todo lo anterior es lo siguiente:

Se ha creado automáticamente toda una estructura de archivos y directorios bajo typings.

Como se utiliza todo esto? En cualquier archivo javascript (no necesitamos tener un archivo typescript tampoco) se coloca las siguientes líneas como cabecera:

Configurando una forma elegante

Observese la declaración y el resultado después de guardar el archivo, en la línea 32. Pero todo esto tiene una complicación, si observan las líneas 1,2 y 3 observaran que voy declarando los archivos d.ts a medida que los voy necesitando y aunque estas declaraciones no tienen ningún efecto colateral en el archivo javascript, no deja de ser molesto e incomodo tener esas varias líneas al principio de cada archivo javascript.

Una forma simple y elegante de solucionar esto es utilizar las capacidades de administración de tsd, de la siguiente manera

   

sudo npm install tsd -g

Instalando globalmente el tsd manager (otro package manager) 

tds init

Genera e inicializa un archivo tsd.json, al mejor estilo de un gestor de paquetes. Este archivo contendrá las referencias de los archivos *.d.ts instalados

Tambien este comando genera un archivo vacio llamado tsd.d.ts. Este archivo contendrá las referencias de los d.ts que se vayan agregando

tsd query chai –action install –save

Finalmente este comando instala (en este caso) el archivo chai.d.ts, actualiza los archivos tds.d.ts y tds.json al mismo tiempo

   

El resultado de todo esto se muestra en las capturas de pantalla siguientes:

Ahora los archivos javascript solo necesitan incluir una única línea en su cabecera:

Espero que les sea de utilidad saludos.

Entendiendo correctamente los modulos de nodejs

Cuando se programa en nodejs, es realmente importante tener un entendimiento del manejo de modulos, pues esta es una pieza angular dentro de nodejs.

Aquí algunas recomendaciones, que se deben aplicar:

 

Es también importante mencionar que ES6 (EcmaScript6) esta alterando ligeramente la sintaxis que se usa en la definición de modulos, aquí algunos enlaces importantes, esta sintaxis ya puede ser utilizada mediante Babel o Typescript:

Una explicación oficial de los cambios soportados

https://github.com/ModuleLoader/es6-module-loader/wiki/Brief-Overview-of-ES6-Module-syntax

Una explicación también mas detallada de lo anterior

http://www.2ality.com/2014/09/es6-modules-final.html

   

Saludos

Configurando un agente linux de VSTS

La necesidad de tener un proceso de integracion continua de una aplicacion basada en nodejs, me ha llevado a tener que investigar como integrar Visual Studio Team Services (aka Visual Studio OnLine) con Linux, tenemos nuestro projecto y queremos ejecutar basicamente grunt dentro de el. Algunos diran del porque no usamos solamente Windows y las opciones de build que Brinda, la respuesta: “no nos son suficientes”. Aqui algunos interesantes links que me permitieron ejecutar el agente dentro de mi servidor linux.

 

   

Javascript, NPM y la programacion orientada a objetos

Como muchos han conocido, estos días, muchos grandes paquetes o componentes de NPM estuvieron quebrados por algún tiempo, entre los más famosos paquetes podemos nombrar a ReactJs y Babel. Y la razón no deja de ser absolutamente ridícula, todos esos paquetes se rompieron porque hubo un error en una dependencia, un paquete llamado ‘leftpad’. Este paquete lo muestro a continuación:

Pero lo preocupante incluso después del análisis que hace @haneycodes, es que aparte de estarnos olvidando de programar, estamos olvidando programar con unidades elementales de abstracción como las clases, estamos convirtiendo una simple función, en un paquete y aunque los defensores del nuevo modelo de desarrollo creen que está bien hacer jolgorio de las potencialidades de javascript. Creo que estamos tendiendo al desorden y a la anarquía del código, donde lo importante es entregar el producto (en este caso el paquete) que haga lo que se necesita sin preocuparnos de principios elementales de diseño. Esperemos que el advenimiento de ES6 signifique un cambio para mejor, con todas las nuevas características que me hacen recordar programar en de una manera ordenada (no llamemos orientada a objetos, porque javascript es peculiar en sí mismo y único en su campo), una manera en la que los principios de desarrollo primen por encima de las soluciones cómodas y frágiles.

Saludos

Opciones de Serializacion Binaria

En estas semanas me vi involucrado en la necesidad de realizar un serializacion binaria personalizada, en cualquier caso esa historia pertenece al pasado, la cuestion es que encontre que hay varios serializadores muy populares alla afuera, que muchos utilizan. Aqui les dejo los links y mas que todo un recordatorio a mi mismo para algun momento futuro:

MessagePack: Quiza mi favorito, simple, extensible (modificando el codigo, haciendo un fork al Proyecto) https://github.com/msgpack/msgpack-cli

BinarySerializer: Simple bastante bien documentado, no lo revise a profundidad pero para aprender los ‘secretos’ de la serializacion, un buen punto de inicio https://github.com/jefffhaynes/BinarySerializer

SharpSerializer: Popular con Xamarin/Mono, no estoy seguro cuan actualizado esta. http://www.sharpserializer.com/en/index.html

Protobuf: De lejos el serializador para interop por excelencia, ampliamente usado por diversos lenguajes de programacion y apoyado por Google https://github.com/google/protobuf ; https://developers.google.com/protocol-buffers/docs/csharptutorial#defining-your-protocol-format

 

Saludos

Instalando RabbitMq en mi maquina

Estoy comenzando mis andadas con RabbitMq y aunque he trabajado en entornos que ya lo tienen instalado decidí no depender de ellos y tener mi propio servidor, para efectos de prueba. Debo admitir que hace tiempo que las cosas se me simplificaban y el comun denominador es Siguiente->Siguiente->Terminar En este caso esperaba que la situacion fuese similar y mas aun asistido por chocolatey, pero me equivoque.

Chocolatey trabaja grandiosamente y no hay que recriminarle nada, para instalar RabbitMq, lo único que hay que hacer es lanzar:

choco install rabbitmq

Esto es suficiente para instalar la unica dependencia que es Erlang, debo advertir que la descarga del instalador puede demorar porque pesa más de 190 MB

La instalación termino exitosamente sin ningún mensaje de error que haga sospechar que algo anda mal, sin embargo cuando intento acceder a: http://localhost:15672/, es imposible.

Primer problema, las variables de entorno siguientes, deben tener estos valores (bueno esto depende de donde instalaron erlang)

ERLANG_HOME = C:Program Fileserl7.0

ERLANG_SERVICE_MANAGER_PATH = C:Program Fileserl7.0erts-7.0bin

Segundo y más grande problema, la variable HomeDrive no se porque razón apuntaba a U:, tuve que desinstalar rabbitmq con chocolatey, setear correctamente la variable usando

SET HOMEDRIVE=C:

Volver a ejecutar choco install rabbitmq y voila todo funcionaba perfectamente.

Las páginas que utilice para resolver este problema son las siguientes:

http://stackoverflow.com/questions/18661791/failed-to-start-rabbitmq-management-plugin-on-windows

https://www.rabbitmq.com/troubleshooting.html

https://www.rabbitmq.com/configure.html#configuration-file

https://www.rabbitmq.com/management.html

 

Saludos