Un viaje sobre lenguajes, APIs y otras cosas raras en el mundo del desarrollo de sistemas.


Normas corporativas y ambientes heterogeneos.
Yo siempre he dicho que el que es carpintero le ve a todo cara de martillo.
Resulta que me decidí a escribir esto para comentar mis experiencias a raíz de una decisión corporativa donde trabajo, quienes me conocen saben donde y no quiero quemar a nadie.
En un principio se me pidió hacer en Java un programa que tuviera las siguientes consideraciones:
Tener por lo menos un 80% de código común entre las distintas versiones.
Que pueda correr en DVD (stand alone pa’ los cuates), intranet, internet y red.

Mi primer impulso fue hacerlo todo en Swing con Java, generando un applet que se comunicara con webservices y estos a su vez con una base de datos, la fachada (comunicación entre el applet y los WS) podrían reducirse a llamados de una fachada común en el programa stand alone de ser necesarios, ya que estos serían consumidos por "Juan Pueblo" y darle soporte sobre como activar o desactivar un WS puede ser incomodo.
Se me pidió que no usara Swing, ya que es una plataforma demasiado "desconocida" y podría presentar problemas de mantenimiento si yo no estaba, por lo cual surgió la idea de que se hiciera todo con JSF hospedado en un servidor de bajo peso para la versión stand alone (tipo tomcat o Jetty) mientras que para las demás estaría en una potente Sun.
Así pues inicié mi desarrollo en JSF y al estar al 80% de avance se me informó que "debido a que corporativamente la norma era .NET" debía detener mi desarrollo, el que por cierto trajo cosas muy interesantes como un DataTable que programé para JSF con una cantidad tan impresionante de funciones que vale la pena utilizarlo en cualquier desarrollo.
Así pues, dada mi ignorancia en .Net, y ante la incapacidad de hacerles ver a la gente que maneja las normas corporativas que hay mundo después de Microsoft y que el costo total de desarrollo y propiedad iba a ser mucho más caro… tuve que iniciar mi desarrollo en C#.
C# es sintacticamente parecido a Java, lo cual me hizo que un buen porcentaje de código siguiera funcionando (30% aproximadamente) y que otra cantidad similar necesitara solamente arreglos menores, mientras el resto se tuviera que ir al arcón de los recuerdos.
La solución final es un applet (perdón, tengo que cambiar mi lenguaje a .NET), quiero decir una aplicación WPF, que para browser (un XBAP) pueda correr en un ambiente de partial trust (es decir un applet que corra en una máquina virtual CLI en vez de una JVM), que se comunique via WebServices para solicitar los datos y estos WebServices se comuniquen a la base de datos…. ¿Donde he escuchado eso antes?
Así que empecé mi tormento, digo, mi programación sobre esta "nueva arquitectura" basada en "tecnología de punta" de Microsoft que tiene menos de 1 año en el mercado (creo que hace 10 años hice algo similar en Java… pero debe ser mi imaginación por que esto es realmente nuevo y novedoso).
Así pues empecé a ver que WCF es una excelente idea, muy mal documentada, en la cual los tutoriales "abundan" (aunque todos sean el mismo ejemplo) y los detalles finos de configuración no se indiquen en ningún  lado. Así que mi proyecto WCF en Visual Studio 2008 quedó ensamblado rápidamente. Igual de rápido que lo que empezaron a surgir los problemas de configuración y encontrar la falta de información (los cuales detallaré uno por uno en este blog en posts individuales, por que algunos son de "antología")., después empecé a hacer mi Applet….aahhhhhhhgggggg… mis "Pages" de WPF y encontré que XAML es una excelente idea, pero que la forma de realizar los Bindings es muy mala… JSF se lleva un premio en ese sentido.
Una vez realizados mis cambios y pasado los tormentos la aplicación salió, ahora espero que no me digan que WPF no es la norma y que lo pase a ASP.
De todas formas ya me pidieron investigar si puedo pasarlo a SilverLight,  por que sería bueno que fuera "multiplataformas" y corra en Mac y en Linux… ¿Alguien me puede ayudar a contar hasta 10?… Claro que sería bonito, pero resulta que hay una pregunta que NADIE en Microsoft les va a resolver ahorita… ¿Qué es lo más conveniente, desarrollar para WPF o para SilverLight y por qué carajos no tienen una CLI para ambos ambientes que hagan compatibles los dos desarrollos?
Así que estén atentos a las "soluciones" de los "problemas poco comunes" de programar en C#, WPF, WCF…. y al que se ría… lo cuelgo…

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: