Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue

Quienes han dedicado un rato a ver mi serie sobre automatización en el despliegue de aplicaciones con Azure habrán notado que había varios pasos manuales a la hora de preparar los entornos en los que íbamos a desarrollar y luego desplegar nuestras aplicaciones.

Pero, ¿nos hemos preguntado que pasa cuando hemos llegado a cierta madurez y nos encontramos con un escenario en que?: siempre creamos nuestros Websites en la misma zona geográfica de Azure, el mismo plan de precios, y… que la organización ya definió cuantos slots (ranuras) de despliegue son requeridos para el ciclo de desarrollo antes de que algo pase a producción.

En ese sentido Azure nos ofrece los Azure Resource Manager templates, que nos permiten definir y usar plantillas para automatizar la creación de recursos y entornos completos dentro de Azure, y ojo esto no esta limitado unicamente a Web Apps, sino también a entornos que involucren VM, Docker, Logic App, etc, en suma algo muy potente si queremos simplificar tareas repetitivas.

Este mecanismo llamo mi atención luego de que la genial GiS (a quien pude conocer de pasada en mi época en España) publicara este interesante articulo sobre como crear las citadas plantillas desde Visual Studio y es a ese articulo a donde deben remitirse para entender con detalle las partes de un proyecto de este tipo, luego de lo cual podemos regresar aquí.

¿Ok? En nuestro caso vamos a definir un proyecto de plantilla de tipo Web App (a diferencia de GiS que eligió la Blank Template para explicar con mas detalle la estructura base), así:

RM1En este caso notaremos que a diferencia del ejemplo genérico, lo que obtendremos serán archivos de nombre WebSite.json y WebSite.param.dev.json, los cuales se corresponden con los DeploymentTemplate.json y DeploymentTemplate.param.dev.json que con tanto detalle se describieron en el articulo de GiS.

RM2Ahora lo que haremos sera configurar los diversos archivos a fin de lograr una plantila que automáticamente nos permita:

  • Crear un Web App que incluya dos slots por defecto: “QA” y “Staging
  • Localizar esta Web App (y sus slots) en una zona geografica determinada, en mi caso: “East US
  • Usar siempre un mismo Grupo de Recursos (ya previamente creado en nuestro Portal de Azure, o creado la primera vez que invoquemos la plantilla), en mi caso: “Default-Web-EastUS

Finish Reading: Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue

Los retos para hacer cloud en el Perú

Cloud es una interesante y validad promesa para las empresas peruanas, la promesa de reducir sus costos fijos, haciendo que buena parte de la infraestructura pase a ser costo variable pagando solo lo que se consume, es algo muy atractivo, y mas cuando un caso de éxito como el de Cineplanet llama la atención por la escalabilidad que esta logrando.

Para lograr esto hay que mirar con otros ojos a nuestras conexiones de internet, si antes se orientaba a facilitar acceso a la web y al correo, ahora… las cosas cambian, si antes el servidor de correo estaba en la red local ahora lo esta fuera, así que cada request sale fuera de la red de la organización por mencionar el detalle que podría ser mas común.

Otro escenario en que nuestra velocidad de conexión puede asomar un lado poco amable es el de la carga de datos desde nuestra organización hacia la nube, y claro como usualmente la infraestructura de la nube esta fuera de nuestro país la latencia si que es un factor a considerar, para lo cual habrá que recurrir a herramientas como Azure Speed y así determinar en que zona geográfica nos conviene mas provisionar nuestros servicios en la nube; pues como vengo insistiendo, el hecho de que haya datacenters cloud en Brasil no implica que vayamos a conseguir mejores velocidades de conexión que las que tenemos con USA.

Pero por mas de que elijamos bien la zona geográfica y aumentemos razonablemente el ancho de banda, hay otro factor que toca considerar y es que la mayoría de conexiones a Internet que se contratan son de tipo ADSL (Asymmetric Digital Subscriber Line) siendo que la A, que antes usualmente no nos importaba pues solo consumíamos contenido, nos puede jugar una mala pasada pues la Asimetría nos recuerda que la velocidad con la que nos podemos bajar contenido siempre sera mucho mayor que la velocidad de subida… upss y eso se refleja en los problemas mencionados anteriormente, de ahí que dentro del planeamiento de uso de soluciones cloud debe hacerse la evaluación de pasar de conexiones ADSL a conexiones DSL que no restrinjan la capacidad de subir contenido.

Ya en el lado que no esta mucho en nuestras manos esta el reclamar por los precios y las velocidades que se ofertan en el Perú (penosas realmente) y esperar que a se haga una NAP a nivel de la Comunidad Andina, lo cual justificaria a los proveedores de cloud el montar un datacenter en la región, o que se mejore la conexión vía fibra óptica con Brasil y así reducir la latencia con los datacenter de dicho país.

Por otro lado, corresponde hacer una mayor difusión respecto a lo que implica cloud en cuanto a generar nuevas aplicaciones (PaaS) o gestión de Infraestructura (IaaS), pues percibo que aun en los departamentos de IT se habla de cloud solo en términos de compartir información en repositorios de facil acceso o usar herramientas de ofimática basadas en Web, y como bien sabemos es mucho mas que eso, todo un reto para los informáticos en estos tiempos ¿no?

 

 

Cloud, de manera sencilla

A veces tiendo a emocionarme con la tecnología, y hablar “en binario”, pero el hecho es que es necesario tener conceptos claros, e ideas fuerza para poder hacer aterrizar una idea en publico no tecnológico, y en el caso de cloud, mas aun.

En este caso, la razón por la cual uno debería estar interesado en cloud desde el punto de vista de negocios es simple: tradicionalmente las empresas han tenido la necesidad de hacer inversiones de infraestructura en previsión de “lo que pueda pasar”, con cloud el esquema cambia, la provisión se hace conforme vayan creciendo tus requerimientos, pagando solo por lo que de veras se necesita.

Consideraciones adicionales vienen después, pero la idea fuerza es esa, atacando por la cuenta de resultados, que al final es lo que define la decisión.

¡Mudanza!

Si has sido un visitante que ha pasado por aquí en semanas anteriores te habrás dado cuenta del cambio de estilo en el blog, lo cual ya es mas obvio, pero lo que no lo es tanto es que desde hace una semana este blog ha dejado de estar alojado en Blogger para estar alojado en Azure usando WordPress.

Las razones para ello son varias, con WordPress hay una mayor escena de temas y plugins para usar, en ese sentido Blogger se había quedado muy atrás, pero una razón muy importante es que siendo que ahora me he enfocado en Cloud Computing en general y en Azure en particular, decidí que una buena opción seria hacer uso de esas opciones y así profundizar en el uso continuo de un recurso en Azure.

La primera decisión que tome fue el tipo de servicio de Azure a usar, descartadas las maquinas virtuales (el uso continuo de procesador garantiza una factura alta) la opción obvia era elegir un Azure WebSite, y dentro de esta opción opte por un servicio de hospedaje “Compartido” (Shared).

wordpress03

La razón por la que elegí este nivel fue porque es el mas “barato” que permite asignar un dominio personalizado (en este caso consultorinternet.com) y no quedarse con el modelo sitio.azurewebsites.net que viene por defecto. Y si por alguna razón este site crece en trafico siempre podre crecer a alguno de los modelos como “Basic” o “Estandar”.

Implementar WordPress fue muy sencillo, solo tuve que elegir de la galeria que te ofrece Azure a WordPress y listo.

wordpress04

Ahora bien, en la siguiente pagina si que hay que tener cuidado en agregar todos los parámetros (son varios) que se piden, y anotar sus valores en lugar seguro.

wordpress05

Nótese que en WebScaleGroup estoy usando un plan de hosting que ya tenia previamente,  y que ya había migrado del modelo “Gratis” al “Compartido” para de esta manera poder hacer uso del tema de los dominios personalizados que ya mencione mas arriba. Con respecto a la BD si es tu primer site en WordPress tienes que crear una BD nueva, si ya tienes otro site deberás usar una BD ya existente a menos que por tu volumen requieras contratar BD extra en ClearDB.

Ya con el WordPress corriendo seguí las indicaciones de este enlace para efectuar la migración de Blogger a WordPress, todo bien pero creo que no es necesario efectuar los pasos recomendados en la sección “Redireccionar los enlaces de blogger a wordpress” (que incluye el uso de un plugin) siendo que mas practico es configurar el formato de los enlaces permanentes de esta manera:
wordpress02
Esta configuración (ojo a la palabra html que hay que agregar manualmente) es la que ya tenia en Blogger, por lo que si los buscadores tenían referenciado un enlace “antiguo” esta referencia no se perderá, lo que si se ha perdido son los enlaces que hacen referencias a entradas agrupadas por mes, bueno… no se puede tener todo.

Con todo esto listo, toca configurar los parámetros en el proveedor de dominios (en mi caso Network Solutions) de acuerdo a lo indicado en esta documentación, nótese que el tiempo en que se propagan los cambios en los valores puede variar, en unos casos en 5 minutos ya Azure “sabia” de los cambios, en otros se tardo como media hora, pero nunca ha tardado las horas que se supone que tienen de colchón para propagar los cambios.

Ya configurado el site, me percate que si bien al entrar a www.consultorinternet.com accedía al nuevo site en WordPress y ya no al de Blogger, cuando administraba el site o iba a los enlaces veía el dominio en azurewebsites.net que no era lo que esperaba, luego de revisar tanto en la consola de Azure como en Network Solutions por si había algún error, revise la administración en WordPress percatándome que tenia que editar algo tan simple como lo que se ve en el siguiente gráfico, upsss.

wordpress06

Bueno, ya esta listo, espero sus visitas y comentarios en esta nueva etapa. Lo mas probable es que en breve migre Fisica 3, el site hermano.

Reflexionando sobre DevOps y Cloud computing

Como indique en el post anterior, mi sesión “El reto del DevOps ágil” trajo buen debate e inquietudes, por lo que en el Open Space del #Agiles2014 propuse una sesión dedicada al tema de Cloud Computing, a la vez Adrian Moya propuso otra para profundizar el tema de DevOps, luego de una breve coordinación fusionamos las sesiones, así que luego del almuerzo nos reunimos en una de las salas y empezó la conversación cuyas ideas fuerzas trate de reflejar aquí:

_DSC0059

Mas que un tema técnico, la reunión se enfoco desde el punto de vista organizacional, ver el porque las organizaciones están adoptando cloud, como lo están haciendo y también porque no lo hacen.

_DSC0058

Dentro de las experiencias se evidencio que el cloud permite empoderar a las unidades de negocio (que usualmente tenían que esperar mucho para la asignación de un recurso *), lo cual puede lograrse mediante nube publica o mediante nube privada si es que hubiera restricciones de seguridad (generalmente por temas legales).

Algo que me llamo la atención fue que si bien un escenario PaaS (Plataform as a Service) esta mas orientado para implementar aplicaciones escalables desde el inicio, las empresas han empezado usando IaaS (Infraestructure as a Service) debido a que ya hay mas madurez en herramientas de automatización, como Puppet y Cheff, y porque este modelo no se queda tan corto como Paas aparte de que nos permite desplegar las aplicaciones ya existentes, a tenerlo en cuenta para entender las necesidades de una organización que quiera dar el salto a la nube.

Un punto clave que salto en el dialogo es que para una implementación adecuada de cloud es imprescindible medir las fortalezas de la organización, así como entender cuales son los blockers que afectarían a la organización en este proceso, en adición a los ya mencionados de seguridad y leyes hay que tener en cuenta el si la organización ya ha hecho una fuerte inversión en hardware, eso me hizo acordar lo que comento Alex Le Bienvenu de Microsoft en su momento, que ese es un escenario muy difícil de adopción y que se podría intentar entrar ofreciendo cloud como mecanismo de contingencia.

Ya metidos en el tema de los blockers afloro el tema del sector bancario, sector que (aparte del tema legal y seguridad) por su dependencia a tecnologías legacy como AS/400 y RPG se encuentran en escenarios mas complicados para poder implementar cloud, pero se menciono que algunos bancos están utilizando cloud para proyectos No Core, y que han empezado a surgir plataformas cloud especialmente orientadas a sus necesidades como FinQloud, habrá que hacer seguimiento a estas opciones.

Llegados al tema de precio, quedo claro entre los asistentes que debemos entender que el uso de cloud no necesariamente es mas barato que tener una infraestructura on premise, siendo que los ahorros van por otro lado debido a que se pueden provisionar los recursos teniendo en cuenta los picos y caída de demanda, en ese sentido es necesario validar los costes desde el principio, hacer seguimiento del consumo (un compañero comento como se les disparo la facturación mensual por una transferencia de datos) y tomar en cuenta la letra pequeña de los contratos.

El tema de desarrollo no podía ser dejado de lado y se recordo que los desarrolladores deben ser conscientes del entorno en que se va a correr la aplicación, pues de lo contrario no se podrá aprovechar las características de escalabilidad de la nube, o tener problemas al toparse con algo usualmente trivial como los FileSystem.

El tiempo paso rápido y fue un gran momento de aprendizaje mutuo para todos los asistentes, espero poder repetir esta clase de diálogos mas adelante en Perú o en próximos Ágiles.

Luego los amigos de Tech & Solve tuvieron otra charla donde comentaron su experiencia y problemas en la evolución del modelo DevOps, donde de paso nos explicaron sobre un producto muy interesante: Docker que están utilizando como una manera ágil para poder provisionar infraestructura (de momento Linux) vía código de manera sencilla, como feedback ante sus problemas debemos recordar que la tendencia DevOps se trata de colaboración entre áreas para llegar a soluciones y no centrarse unicamente en lo técnico, esto viene después.

_DSC0067

Ademas de Adrian, un gran agradecimiento a Diego Garber (extremo derecho en la foto **) que estuvo presente en todas estas sesiones compartiendo su experiencia y punto de vista.

_DSC0068

* Como dije en otro post, en este blog no usamos la palabra “recursos” para referirnos a las personas, siendo que en este caso usamos la palabra para referirnos a maquinas físicas, maquinas virtuales, espacio en disco, websites…

** El asistente del medio también estuvo muy presente y activo en estas sesiones DevOps, pero se me paso apuntar su nombre, así que si alguno de los asistentes al Ágiles lo puede identificar se agradecerá.

“El reto del DevOps ágil” en el Ágiles 2014 de Medellín

Del 23 al 25 de Octubre tuve la oportunidad de estar en Medellin para el Ágiles 2014, fueron unos días bastante intensos, de reencuentro con amigos y sobre todo de aprendizaje, especialmente con keynotes de la talla de Tobias Mayer, Martin Alaimo y en particular Angel Medinilla que al fin (luego del intento frustrado de Lima) hemos podido tenerlo en el Ágiles con su charla “Unicornios, Krakens, equipos autoorganizados y otras bestias mitologicas“.

IMG_0728-2

Este Ágiles también me permitió presentar una charla que tenia planeada hace tiempo, “El reto del DevOps ágil”, tema que a pesar de estar de “moda” en realidad ha sido una necesidad dentro de las empresas, por lo que me alegro mucho el debate y feedback que se genero en la sesión, un aliciente para seguir impulsando el tema y romper las barreras tradicionalmente existentes entre Desarrollo y Operaciones.

IMG_1755

Mención especial merece la visita de Javier Garzas y su charla Verdades incomodas y mentiras reconfortantes… Que aprendí después de trabajar para 80 empresas software en la que nos recordo que sin calidad (y otros elementos que estamos olvidando) no se puede ser ágil.

En definitiva una gran experiencia, y ahora solo toca esperar que los amigos uruguayos nos sorprendan en el próximo Ágiles 2015 que se realizara en Montevideo.

_DSC0171

En defensa de Visual Basic.Net y las “buenas practicas”

Primero el Disclaimer: La herramienta a la que le tengo mas cariño y con la que he sido mas productivo es Borland Delphi (ahora Embarcadero, pero la que yo conocí era de Borland), dicho esto pasemos al grano.

El titulo del post proviene a razón de la ultima sesión de Mad.Nug en la que Jorge Serrano compartió su experiencia sobre las posibles acciones a tomar cuando se tienen aplicaciones en Visual Basic 6 y existe la necesidad/presion/requerimiento de migrarlas a .Net, la sesion fue muy explicativa, recordandonos cuales son los puntos donde hay mas incompatibilidades y las posibles opciones:

– Herramienta de migración automática
– Entorno mixto (Microsoft Interop Forms Toolkit 2.1 y wrappers)
– Empezar todo desde cero.

De acuerdo a su experiencia (corrígeme si te estoy referenciando mal, Jorge) debería procurarse por la ultima opción (en ese sentido Jorge facilito un buen enfoque para acometer esos proyectos), y estar alertas ante el riesgo de que una solución puntual como un entorno mixto crezca y pierdas el control.

Si bien comparto la idea de que hay casos en que no queda otra que proceder de esa manera, creo que esa decisión tiene que ser sopesada teniendo en cuenta criterios como: cantidad de lineas de código existente, dependencia de terceros, disponibilidad de conocimiento funcional, etc… en ese sentido se sintió la falta de cubrir posibles estrategias de cuando se ha decidido ir por el camino de la migración (que igual se hace para algunas aplicaciones, dejando el resto a un rehacer desde cero).

Bueno, a lo que iba, como parte del camino de un rehacer desde 0, Jorge planteo que había que procurar migrar hacia C# en lugar de hacia VB.Net, ¿por qué? es lo que nunca me queda claro, salvo por un hecho (mencionado en la reunión) que es la mayor disponibilidad de recursos en Internet para C# que para VB.Net, pero fuera de ello el acceso hacia el Framework de .Net es básicamente el mismo (salvo excepción que contare luego), por lo que también en la conversación con los asistentes se dejo caer que con C# se es mas ordenado y se encamina hacia las buenas practicas, por lo que ya entramos a un tema de preferencias y es a donde quería llegar.

Admitamoslo, por sus propias características en Visual Basic 6 era muy muy fácil desarrollar con malas practicas y que el código spaghetti generado sea muy difícil de mantener, pero si una cosa tiene Visual Basic .Net es que significo una ruptura sin pasos intermedios con respecto a VB6 a fin de volverlo OOP y compatible con el nuevo Framework (*), y por lo tanto mucha de la laxitud inherente al viejo VB6 ya no existe, es un buen lenguaje OOP y muy valido para aprovechar los conocimientos de sintaxis propios de Basic: Dim, as, Next, End…, el problema gordo es la herencia de mala imagen que lastra el lenguaje, asi que explicar a un manager que seria menos traumatico continuar con VB.Net en vez de C#…. complicado, triste realidad.

Siendo así creo que solo hay dos razones no personales para optar por desarrollar un proyecto en C#:
– Es muy critico contar con todos los recursos de documentación disponibles para un tema en concreto, que lamentablemente en su mayoría están en C# (p.ej. hay casi tres veces mas info para Generics en C# que para Visual Basic).
– Te ha tocado acceder a una parte del Framework que expone justamente un tipo de datos existente en C# pero no en Visual Basic.Net, eso me paso con la versión 1.1, no se si lo habrán solucionado, pero … queda como alerta.

En contraparte tengo algunas razones de productividad para seguir usando VB.Net siempre que puedo:
– Detección automática de algunos errores y de su corrección, esa potencia de mostrarte un subrayado en algunos errores de sintaxis es de veras de agradecerse, y lo mismo con el hecho de que si compilas y saltan errores no tienes que recompilar para ver si has corregido bien o no, conforme vas corrigiendo tu pila de errores se reduce.
– No sensible a las mayúsculas/minúsculas, esta característica va de la mano con lo anterior, si defines bien una variable (usando Camel y Pascal case adecuadamente) y luego la invocas, el hecho de que se te auto corrijan las mayúsculas y minúsculas es una señal inmediata de que no te has equivocado al invocar el nombre de dicha variable.
– Las instrucciones (begin..end..next..) son mas claras que las llaves ({}) para poder hacerse una idea del ámbito de un bloque de código.

Dicho esto, como desarrollador he venido a conocer ambos lenguajes, pero lo fundamental es el Framework, siendo que el saber C# me ha facilitado acceder a ciertos recursos no existentes para VB.Net, pero que luego a la hora de implementar no he vacilado en aplicarlos sobre proyectos en VB.Net, así que es bueno saber ambos, pero uno no debería de inhibirse y proponer el uso de VB.Net en los proyectos.

Pero algo se me quedo dando vueltas ya desde la sesión a propósito de eso de que C# te ayuda a ser mas ordenado (o algo así), y a esto se sumo el comentario de uno de los asistentes comento que ellos tenían una aplicación grande en VB6, basada en COM+/MTS, hecha según las recomendaciones que daba Microsoft por entonces para el desarrollo en COM, lo cual me hizo retroceder a la época en que este diagrama salia en toda presentación de arquitectura y diseño de aplicaciones alla por el final de los 90s:

Pongámonos en contexto, para el lanzamiento de Visual Basic 6, ya había un gran parque de aplicaciones en VB4 y VB5, pero la fama del “DLL Hell” ya era muy fuerte, así que Microsoft emprendió una campaña muy intensiva para explicar el concepto de desarrollo de aplicaciones distribuidas, las ventajas del multicapas en la mantenibilidad de las aplicaciones, etc etc… conceptos que ahora son el pan de cada día en los objetivos de los diversos proyectos actuales, fueron recien conocidos para muchos gracias a Microsoft, y la verdad es que en ese entonces Microsoft se preocupo mucho en hacer pedagogía de las buenas practicas, tan así que en los cursos de certificación se hacia énfasis en lo que hay detras de la instanciación de objetos en COM para de esa manera impulsar formas mas ordenadas de programar, y lo bueno de todo es que esa pedagogía era de manera no agresiva, planteándola como una evolución de las aplicaciones que habia en desarrollo entonces, a fin de que los programadores mejoraran sus practicas frente a la fama de caos, o sea se pugnaba (por entonces) un cambio evolutivo en las formas de hacer las cosas apoyándose en lo que los desarrolladores ya conocían, lo cual condujo a que los partners serios si que hicieran aplicaciones buenas y solidas usando VB6.

Para bien o para mal todo cambia con la introducción de .Net, que como ya hemos indicado en este y otros posts vino a ser un ruptura muy fuerte, en la que sobrevivía el que tenia mejor las bases de OOP y/o Windows DNA. Claro, ya lo peor paso (salvo las app VB6 que se resisten a morir) y la cosa esta mas o menos estabilizada, salvo por la nueva tendencia del famoso patron SOLID, sobre el cual ya comente que tenia mis dudas sobre si facilitaban la mantenibilidad de las aplicaciones, pero que en todo caso hay que entenderlas y saber como y cuando aplicarlas, siempre sin dogmatismos.

Y es justamente que ahora los dogmatismos se hacen presentes, pues en lugar de introducirnos progresivamente a las nuevas “buenas practicas” se nos pide que ya no usemos ni Windows Forms (aunque si, podríamos pasar a WPF) ni Windows Forms, diciendonos que “no es testeable” “no permite xxx principio” de buenas a primeras sin mostrar evolutivamente como mejorar el código que estamos desarrollando, de ahi a lo que dije en un twitt reciente: Si nos explicasen las pruebas unitarias con ejemplos basados en multicontroles, eventos y mantenimientos, igual las adoptariamos #digonomas (o este otro), digo eso porque la mayoría de las aplicaciones corporativas de uso interno (no portales de contenido) terminan siendo eso y no los clásicos ejemplos de calculadoras o números perfectos, así que seria bueno que los planteamientos de difusión sobre TDD o SOLID partan de un enfoque evolutivo y no rupturista (dando cobertura tanto a VB.Net como C#) a fin de lograr una mejor adopción.

A ver si no llega alguien por aquí diciendo que he “perdido el punto”… xD

(*) Y si, sigo creyendo que muchos traumas se hubieran evitado si al hacer .Net (y C#) se hubiera mirado lo que tenia VB6 a fin de hacer la ruptura menos dolorosa.

Lo tenia delante pero no sabia decir porque no me gustaba: Java

Cuando uno llega a una situacion u opinion es porque ha recorrido un camino previo, nadie te ha teletransportado ahi, solo que a veces nos olvidamos de dicho camino.

Concretamente debo referirme a la predileccion como desarrollador que tengo para con la plataforma .Net, el porque termine ahi y lo prefiero frente a Java … tiene su historia.

Luego del paso obligatorio por Pascal, C/C++, COBOL tocaba enfrentarse a las herramientas de desarrollo “real”, con la que se hacian las cosas en las empresas, y sobre todo, las que permitian desarrollar para Windows. Tuve ocasion de hacer un curso de Gupta SQL Windows, el cual me dejo un mal sabor de boca.

Es por esa epoca que tambien me expongo ante Visual Basic 4/3, se comenta algo sobre Java, pero aun no recuerdo el como y porque (creo que lo que lei por ahi) termino en mi casa haciendo experimentos con Borland Delphi 1 y fue quedar seducido por la propuesta hecha: un poderoso lenguaje Orientado a Objetos, con una interfaz que cogia lo mejor de los conceptos drag and drop popularizados por Visual Basic.

Pero claro, lamentablemente en Peru Delphi era un lenguaje casi de “culto”, por lo que urgia revisar las cosas que iban apareciendo en el mercado y una de esas cosas fue algo que me comentaron a poco de terminar mi primera Feria del Hogar: un lenguaje llamado Java el cual prometia traer la interaccion a la web mediante los llamados “applets”, propuesta interesante la verdad, el caso es que no me pude poner a probar Java sino hasta el 97 en que pude instalar Windows 95, esto debido a que no habia opciones para correr Java en W3.11 como no sea mediante el proyecto ADK que no se en que habra terminado.

Intente darle su espacio a Java, pero entonces me topaba con unos problemas que para entonces eran criticos:
– Ausencia de un IDE lo suficientemente rapido, aun el Borland JBuilder era muy lento, siendo que aun VB (5 para entonces) era mucho mas rapido y ni que hablar de Delphi (3 y 4).
– No continuidad en el modelo de presentacion grafica, de un momento a otro se decidio que las AWT debian dar paso al modelo Swing.

El lenguaje en si no daba muchos problemas (regresaremos a esto), pues ya contaba con la base de saber C/C++, pero lamentablemente costaba mucho ser productivo, siendo que con Delphi implementar algo era relativamente simple (pero no tan innecesariamente simple como con VB). Tambien es conviente notar que como el enfoque era hacia dar “dinamismo” a la web, surgieron herramientas que proponian alejarte del codigo para generar applets (semi prefabricados) de manera mas agil, hablo de Kinetix y Jamba. Y claro, por otro lado teniamos a Kawa, que fundamentalmente era un gestor de proyectos que tras bastidores llamaba por linea de comandos al JDK.

Es asi que me volvi en uno de los pocos defensores de Delphi en Lima de esa epoca, hice experimentos con las opciones de desarrollar paginas con ISAPI, controles ActiveX incrustados, desarrollo en 3 capas mediante Midas, y claro un buen rato metido en el newsgroup non-technical de Borland asi como en ClubDelphi, circunstancias que me llevaron a conocer a Claudio Briceño (responsable comercial de Borland para Latinomaerica) quien me vino a visitar a mi trabajo de entonces, lo cual luego conduciria (gracias a la posterior coordinacion de un comunidad de Linux en el Peru) a la posterior presentacion de John Kaster en el Hotel Los Delfines para presentar los avances que hacia Borland en desarrollar Kylix un entorno Delphi para Linux, y si, ahi estoy yo… :

Luego me tocaria cenar tanto con Claudio y John a la espera de posteriores acciones que permitieran potenciar la presencia de Delphi en el mercado peruano, lo cual no logro a materializarse.

En esas circunstancias, veo que las cosas cambian, nadie habla de applets, todo se orienta hacia los servlets, y a los EJB, les doy una revision… nuevamente, cuesta hacer algo simple de manera rapida, se nos habla de que ya saldran los JSP….. Lo interesante es que a pesar de esas limitaciones Java estaba cogiendo un mayor arrastre, el cambio de lo “visual” hacia los modelos de componentes orientados a servidor habian probado ser buenos para la estrategia de Sun, ya que habia una demanda en el mercado por una solucion no atada a Microsoft, mas orientada a objetos y que fuera robusta, en ese sentido los Application Server lanzados por diversos fabricantes permitieron consolidar su posicion en el mundo corporativo.

Es en esas circunstancias que (me)ocurrieron varios eventos de manera casi consecutiva, Microsoft anuncia .NET prometiendo una plataforma totalmente Orientada a Objetos(*), soy admitido en una beca de Microsoft para estudiar VS 6 y ceso en mi trabajo de entonces.

Estudiar lo que ofrecia VS (VB + Interdev fundamentalmente) me hace ver ciertos detalles que no eran tan claros para mi, era perfectamente viable construir aplicaciones robustas con esas herramientas, pero que muchas veces la simplicidad te conducia a errores de diseño que penalizaban la performance y la mantenibilidad, siendo necesario un conocimiento serio de la arquitectura detras (algo en lo que los cursos de Certificacion enfatizaban bastante).

A pesar de haber “cambiado” de herramienta por razones de mercado, sabia que esto era algo transitorio, pues veia la fuerza que iba a arrastrar el lanzamiento de .NET, producto al que recibia con expectativas positivas debido a que el cerebro detras de esto era nada menos que Anders Hejlsberg quien habia sido arquitecto de Delphi en sus dos primeras versiones, del cual solo podria esperar que introdujera en la nueva plataforma la evolucion de las innovaciones que habian sido introducidas originalmente en Delphi.

(Para ese entonces Borland libera Kylix, el cual debo decir que nunca use)

Obviamente que apenas pude me consegui una de las primeras Beta de Visual Studio .NET, aparatoso como buena beta, ya dejaba ver que habia asumido totalmente el modelo de objetos, y por todas partes se notan los guiños a Delphi, especialmente en C# en el tema de la gestion de eventos, comprendi entonces que me encontraba ante una herramienta potente y sobre todo que introducia la programacion RAD y orientada a eventos al desarrollo Web, algo tan simple y a la vez potente era algo por lo que los desarrolladores habiamos estado esperando buen tiempo. Pero lo mas importante era que todo lo aprendido sobre OOP en Delphi se aplicaba directamente en la nueva plataforma, y a estas alturas creo que mi transicion fue mucho mas simple que si hubiera venido solo procedente de VB6, lenguaje que con todo lo flexible que era, te enmascaraba muchos detalles los cuales no te permitian una total potencia en el desarrollo.

Para cuando llegue a España ya habia experimentado con la Beta 2 (y una pre-Beta2 no lanzada masivamente pero que me fue facilitada en Microsoft Peru), por lo que seria cuestion de tiempo que me terminara involucrando en proyectos de .NET como ha sido hasta la fecha, incluyendo examenes de certificacion en el interin.

Han pasado los años y es gracias a CampusMVP que me entero de unos articulos de Ian Marteens(al cual ya habia leido por 1999) en los que se hacen interesantes comparativas entre Java y C#, enterandome de que la implementacion de los Generics en C# es mejor que en Java, pero confirmando algo que ya habia intuido en mis primeras peleas con Java: su implementacion de eventos es penosa, ya que como el mismo Marteens dice “Los diseñadores de Java eran personajes que odiaban los punteros, y nunca hubiesen aceptado implementar los eventos al estilo Delphi. De hecho, ni siquiera tuvieron en cuenta el soporte para eventos cuando crearon Java”. No vieran el alivio que tuve al leer esto, durante mucho tiempo creia que era yo quien podria estar haciendo algo mal cuando trate de implementar cosas en Java, pero como se puede ver en esta serie de articulos, hay errores (llamalos caracteristicas si quieres) en la implementacion del lenguaje, y era algo que alguien que provenia del entorno Delphi podia intuir, pero es bueno saber que hay bases formales para entender las ventajas de un lenguaje (lenguaje, no plataforma, esa es otra guerra) sobre otro.

Como digo, es un camino el que me ha traido hasta aqui y ese camino empezo con la experimentacion de Delphi, herramienta que a pesar de no trabajar con ella en años, no puedo sino recordar con cariño y agradecimiento por las bases que me dejo.

(*)Recordemos los fuertes ataques que recibia VB por no incluir algo tan simple como la herencia.