Categoría: Microsoft

Todo lo que querías saber sobre las “versiones” en Azure y no te atrevías a preguntar (1)

Posted on by ecardenas

Hace unas semanas alguien me pregunto sobre las “versiones recomendadas” de los recursos de Azure que debían provisionar para una solución, esa pregunta de tanto en tanto aflora y suele ser común entre quienes tienen experiencia en TI on premise, y que por lo general suelen estar acostumbrado a que los software tengan años o versiones, por ejemplo, Windows Server 2003, Windows Server 2019, Oracle 8i, etc.

Súmale el hecho de que en este mundo es usual seguir políticas de “no usar la última versión, hasta que salgan los primeros parches o usar solo la penúltima que ya está probada” “usar las versiones de manera intercalada para ahorrar en licencias (perpetuas)”, paradigmas que tenían sentido en el mundo on premise cambian de valor cuando las organizaciones migran hacia la nube y especialmente a esquemas de pago por suscripción/uso como por ejemplo en el caso de Office, antes era usual que una organización comprara las licencias perpetuas de Office 2010, ignorara el lanzamiento de Office 2013, para solo actualizar hacia Office 2016.

Como sabemos con Office 365 (ahora Microsoft 365), el modelo cambio a un pago por subscripción periódica, donde Microsoft se hace cargo de actualizar constantemente con las últimas versiones que vayan liberando, liberándonos de problemas de desplegar nuevas versiones, nuestra responsabilidad obviamente es elegir el plan correcto para las necesidades y presupuesto de nuestra organización: E1, Pequeña Empresa, A3, etc.

Con esta premisa respecto al modelo de compra basado en uso, podemos ir profundizando en el concepto, y plantearnos la pregunta “¿Existen versiones (incrementales) de los servicios PaaS en la nube?”, y la respuesta corta seria “En la mayoría de los casos no debemos preocuparnos, porque como parte de la responsabilidad compartida, Azure se hace cargo de ir actualizando las plataformas base de los servicios PaaS que vayamos utilizando”. Finish Reading: Todo lo que querías saber sobre las “versiones” en Azure y no te atrevías a preguntar (1)

¡Añade aislamiento a tus despliegues con Environments!

Posted on by ecardenas

Regresando, en plena cuarentena, a las arenas del CI/CD para hablar algo que curiosamente ayuda a lograr cierto aislamiento a tus recursos en la nube al momento de desplegar: Los Environments en Azure Pipelines, así que vamos a ello.

Repasemos un poco, cuando hemos tenido pipelines usando Designer Mode, hemos definido el despliegue (en este ejemplo hacia un Web App) mas o menos así:

Y en el caso de Multi-stage pipelines, el paso de despliegue se define así:

Si nos fijamos en ambos casos, veremos que corresponde al Pipeline definir el recurso “destino” donde haremos nuestro despliegue:Subscripción, Grupo de Recursos y Recurso (en este caso una WebApp), o sea que toda la responsabilidad recae sobre el pipeline y quienes tienen acceso a desarrollar sobre el.

Si, es cierto que podemos establecer una cierta seguridad si, cuando enlazamos nuestro Team Project contra los recursos de Azure, lo hacemos contra Grupos de Recursos acotados y no contra toda una Subscripción, algo de eso lo vimos anteriormente, pero lo que vamos a ver proporciona una abstracción adicional y funcionalidades que nos ayudaran al seguimiento de nuestros procesos de despliegue. Finish Reading: ¡Añade aislamiento a tus despliegues con Environments!

Presentando Azure DevOps

Posted on by ecardenas

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps

Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Posted on by ecardenas

Pues si, de vuelta… ya tocaba tener algo que compartir con ustedes, y en esta ocasión algo nuevo que sea de utilidad para quienes despliegan sus aplicaciones en servidores, pero… mejor contextualicemos.

Cuando originalmente empece a hacer mis pruebas de despliegue automatizado de aplicaciones en .Net tuve que hacerlo sobre servidores Windows, y para lograr eso se tenia que hacer varios pasos, instalar Web Deploy, asignar usuarios, activar servicios, pre configurar los WebSites o Aplicaciones Web, exportar un perfil, usar ese perfil dentro de la configuración de nuestro despliegue XAML, etc.. de hecho la cosa era tan tediosa que tuve que escribir una documentación de varias paginas para mi antiguo trabajo explicando como se hacia el proceso, y bueno… esa en parte fue la razon por la cual me he enfocado especialmente en lo que es despliegue sobre Web Apps, pero claro siempre me quedo el bichito de como ayudar a optimizar las cosas si la necesidad es trabajar con servidores ya sea IaaS u On Premise.

Así que desde hace unos meses he estado leyendo sobre una nueva funcionalidad que te ofrece VSTS llamada Deployment Groups (ya disponible de manera oficial) que esencialmente permite que tu aplicación se despliegue de manera sencilla hacia un servidor o conjunto de servidores, esto lo logra mediante la ejecución de un script (que ya veremos luego) en la(s) maquina(s) destino que esencialmente instala un agente que facilita la ejecución de los diversos pasos necesarios para la configuración el despliegue de nuestra aplicación, y cuando me refiero a configuración me refiero a que es posible realizar de manera desatendida la creación del Website o Aplicación Web en los servidores destino. Mas aun, esta funcionalidad permite agrupar nuestros servidores de manera lógica, de tal manera que no sea lo mismo desplegar a los servidores de QA que a los de Producción.

Todo bien, así que lo que trataremos ahora es de desplegar nuestra aplicación a un conjunto de Maquinas Virtuales creadas en Azure, las cuales estarán detrás de un balanceador de carga el cual nos proveera de una URL o IP unica, siendo que a la hora de efectuar la petición o request la respuesta podrá provenir de cualquiera de las maquinas virtuales que hayamos desplegado, lo cual facilita mucho la disponibilidad de nuestra aplicación, pero que a la vez proporciona retos respecto al manejo de sesiones y recursos compartidos. Finish Reading: Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Completando el ciclo de ALM: Release Management (II)

Posted on by ecardenas

Prosiguiendo con la entrega anterior, pasamos a los pasos 4 y 5 de este proceso que consiste en configurar cada uno de los entornos de despliegue en los que se va a desplegar la aplicación, la idea que implementaremos en esta ocasión sera la siguiente:

  • Cada vez que se efectué un cambio en el código fuente se disparara una Build (Integración Continua, esto ya lo tenemos bien sabido)
  • Si la Build es exitosa se disparara una Release
  • El primer paso de la Release sera desplegar automáticamente al entorno QA
  • Efectuado el despliegue a QA, un aprobador humano dará su conformidad, o no, al contenido desplegado
  • Si el despliegue en QA ha sido aprobado, recién entonces se efectuara el despliegue al entorno PRO

Obvio que este esquema puede extenderse para incorporar mas entornos, para añadir pruebas de carga en la nube, distintas categorías entre aprobadores, etc, pero para demostrar el concepto esta prueba sera suficiente.

De momento vamos a identificar correctamente nuestros entornos, así que nos vamos al entorno llamado por defecto “Default Environment” y le cambiamos el nombre…

Clipboard01

A QA:

Clipboard02

Finish Reading: Completando el ciclo de ALM: Release Management (II)

Empezando bien la 2da mitad del año

Posted on by ecardenas

Este fin de semana pude asistir, por tercera vez consecutiva, al Microsoft Influencers Summit de Perú, un encuentro anual donde nos reunimos quienes en el transcurso del año hemos colaborado en la difusión y el mejor uso de las tecnologías Microsoft.

En esta ocasión el evento fue en el Hotel Las Dunas de Ica, y como cada año fue muy intenso, conociendo a gente y motivandome por las distintas cosas que hacen así como por la capacidad que han tenido para organizar eventos de difusión en las distintas partes del Perú, especialmente (claro esta) los anfitriones, la poderosa comunidad estudiantil de Ica.

Se reviso el plan para el nuevo Año Fiscal que empieza ahora, y estrategias para apuntar mejor en nuestras actividades, pero por sobre todo se compartieron grandes momentos con un grupo muy diverso y a la vez alegre 😀

11709785_885634558178868_2506089030581725766_o

10317608_10152952561132864_4862202713044200559_o

En la noche del viernes tuvimos también la premiación de los Influencers mas destacados del año en las diversas categorías (Academy, IT Pro y Developer), tocándome el inesperado honor de ser designado como Top Influencer 2015, desde aquí mi agradecimiento especial a Microsoft Perú, a Jorge Oblitas y Mauricio Sougarret por esto, que no hace sino motivarme para seguir investigando y difundiendo tecnología como lo he intentado hacer en este modesto blog.

10987714_885632364845754_4509327738474147560_o

Empieza un nuevo FY, un plan de trabajo de difusión en el que espero contribuir con las diversas comunidades en lo que sea posible, y en particular mi reto personal que es mejorar los ciclos de desarrollo y despliegue de aplicaciones así como incentivar la adopción de la nube PaaS.

(Primera y Tercera fotografía gracias a Manuel Miranda del Solar)

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

Posted on by ecardenas

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.

Pensando en estrategias de migración de VB6 a VB.Net

Posted on by ecardenas

Casi a hilo de lo que comentaba en el anterior post, hace poco Jorge Serrano publico Cada vez que migras una línea de código de VB6 a .NET se muere un gatito en el mundo, interesantisimo post que vale la pena leer pues resume muy bien los dilemas, actitudes,creencias erróneas y decisiones que se acometen cuando se tienen aplicaciones en Visual Basic 6 y se piensa el migrar a .Net como una opción a considerar.

Me detendré poco en el tema de la discusión de si migrar si o migrar no, pero en mi modesta opinión creo que los criterios de discusión deberían girar alrededor de (entre otras) estas preguntas:
– ¿Qué tan diferente son los procesos de negocio de la organización de como eran cuando la aplicación fue construida?
– ¿Son los algoritmos técnicos de las aplicaciones aun validos para los procesos de datos?
– ¿El esfuerzo de “entender” la aplicación actual y documentar la especificación de la nueva es mayor que el de la “simple” migración? (Cuando no queda nadie del equipo original)

Llegados a nuestro escenario “pues si, necesitamos migrar esa aplicación pues ya cada vez es mas difícil mantenerla y vamos a migrar de plataforma….. ” hay que plantearse las cosas de como acometerla, no tanto desde el punto de vista técnico, que para eso hay suficiente información en Internet, sino mas bien de cuales serian los pasos razonables para lograr el objetivo de una migración exitosa.

Con esas miras puestas, la experiencia que he tenido recientemente me llevan a plantear dos pequeñas metas antes de la migración en si:
– Reducir todo lo que se pueda la cantidad de lineas a migrar.
– Reducir y aislar los comportamientos críticos no migrables.

Cuando hablo de reducir la cantidad de lineas a migrar, parto del hecho de que es mas que probable que la aplicación a migrar hay sufrido modificaciones durante su tiempo de vida, lo cual haya ocasionado que métodos o clases que antes eran invocados se hayan convertido en código muerto, y reducir ese código muerto antes de la migración deberá ser uno de los principales objetivos que debamos de plantearnos, puesto que es preferible saber de antemano que código ya no es invocado (y eliminarlo/comentarlo) que matarnos en hacer que funcione para luego saber que … sorpresa.. sorpresa… era código muerto.

El tema de los comportamientos de lenguaje no migrables (“As any”, redimensionamiento de arrays …) es complicado, por lo que creo que es conveniente, en la medida de lo posible tomar las acciones para reducirlos antes de la migración y si eso no es posible marcar dicho código como problemático.

Ahora bien, estos son objetivos loables, pero lamentablemente difíciles de conseguir con las herramientas de Microsoft “out of the box”, que si que el Code Analysis de VS .Net nos facilitara el encontrar las referencias “muertas”, pero lamentablemente el tener una información completa de este tipo solo sera posible cuando el código migrado compile sin errores, pero claro… volvemos a lo mismo podemos pasarnoslas divertidos corrigiendo código para luego descubrir que ese código no era invocado en ningún lugar.

Entonces queda claro que el análisis de dependencias es critico, y lamentablemente no queda sino recurrir a herramientas de terceros, concretamente he estado probando Project Analyzer con resultados muy interesantes pues ademas de encontrarme con la opción de encontrar todo el código muerto, me detecto todos las porciones de código que requerían migración manual.

Así pues, creo que el contar con una herramienta de ese estilo (he mencionado Project Analyzer, pero igual podría ser alguna otra) cobra un importancia muy especial en esta clase de proyectos, ya que permite cubrir los dos primeros objetivos señalados y llevando de rebote una ventaja adicional: darnos cuenta, mediante el análisis de dependencias de que porciones de código no compatible como llamadas a la API de Windows, podrían ser reemplazadas por código .Net.

Ese análisis e identificación de codigo critico seria un primer paso, de ahí vendrían los siguientes:
– Refactorización, si, se puede, y nos ayudara a tener nuestro código heredado mas legible.
– Preconversión de código no migrable a código migrable, donde sea posible y se sepa que se seguirá usando luego de la migración.
– Migración en si, ya sea usando Visual Studio o una herramienta de terceros, y de ahí las sucesivas iteraciones para estabilizar el producto hasta el nivel deseado (reemplazo de ADO por ADO.Net, eliminación de los Interop….)

Es obvio que este proceso iterativo por lo que no conviene dar un paso nuevo hasta que no se sepa que la nueva versión sigue haciendo lo que hacia antes, de ahí la importancia de tratar de acometer la mayoría de los cambios posibles antes de la migración en si.

¿Qué le hubieramos pedido a un hipotetico VB 6.5?

Posted on by ecardenas

Pues si, ya han pasado poco mas de 10 años en que .NET fue anunciado (recordemos que antes era llamado NGWS), por lo que ya tendría poco sentido hablar de su predecesor, pero la experiencia de volver a tener que lidiar con VB6 me ha hecho volver a reflexionar algunas cosas…

Primero situémonos en el contexto, VB6 fue lanzado durante 1998 he incluía mejoras como: ADO 2.0 (un enésimo santo grial en la unificación de los modelos de acceso a datos), WebClasses, mejoras en el soporte a COM e integración con MTS; con todo no fue un modelo rupturista y las empresas entusiastamente dieron el salto desde VB5 (versión que por primera vez libero a VB del p-code permitiendo compilar en modo nativo).

Todo bien excepto algunos detalles…. como la herencia, lo cual le hacia ser denostado como un lenguaje no totalmente orientado a objetos, palideciendo en ese sentido ante sus rivales: Delphi y Java. Admitamoslo, durante buen tiempo los fans de VB actuaron con la política de la zorra y las uvas, diciendo que la herencia no era totalmente necesaria, y pregonando la potencia de las interfaces para lograr el polimorfismo. Aun así Microsoft decidio explorar por el lado de una OOP sin las complicaciones del C++, y el resultado fue Visual J++ 6.0 el cual tuvo problemas con Sun, por lo que el producto no tuvo tanto éxito, aunque si que me he topado con un cliente en el cual había herencia de su uso.

Visto ese escenario, para principios del 2000 se rumoreaba sobre lo que seria el inminente ASP+ y el NGWS (Next Generation Windows Services), pero Microsoft sorprendió al mundo cuando en Julio anuncio a .NET, C# y el hecho de como el nuevo VB.Net seria un lenguaje totalmente orientado a objetos, luego vendrian las primeras versiones beta de Visual Studio .Net, sobre cuyo primer contacto ya me he explayado.

Como ya he comentado mi adaptación como desarrollador al nuevo entorno fue fácil, gracias a la base OOP proveída por Delphi, así como a las buenas practicas de los cursos de certificación, pero eso no impedia que mantuviera un ojo en los problemas que se iban a presentar en la transición de VB6 a VB.NET….

Estos cambios venian dados por dos lados: cambios en el lenguaje y cambios en el Framework (de COM a .NET) y ambos eran muy agresivos, tan asi que dos respetados gurues de la época dieron su explicación (muy acalorada por cierto) de porque VB.Net era un nuevo lenguaje (para ellos peor) y no una evolución de VB6:

Karl E. Peterson: VB Fred, A Marketeer’s Worst Nightmare
Bruce McKinney: The End of Hardcore Visual Basic

Sugiero dar un vistazo a esos artículos y a los enlaces ahí contenido para entender la magnitud de los cambios, y si bien luego las cosas no fueron tal como se pintaban en la beta, los cambios si que son muy rupturistas e intentar asumir una migración es algo de veras intimidante.

He realizado migraciones de aplicaciones .NET de la version 1.0 a 1.1 y de la 1.1 a la 2.0 y se puede decir que el camino es mas o menos controlado, pues el lenguaje siempre es compatible hacia atrás, y si bien el Framework evoluciona, dejando algunas tecnologías obsoletas (como Remoting) siempre se puede recompilar en una versión superior, siendo que los potenciales problemas están por el lado de:

– Dependencia de una librería de terceros, cayendo en esta categoría el Enterprise Library, el cual si que tuvo cambios que obligaban a modificar el codigo, problema no presentado en una libreria comercial como Dundas.
– Necesidad de apuntar a una plataforma especifica (como x64 o Itanium), lo cual sumado a lo anterior da para pruebas y comprobación de entornos.
– Alguna cosa que compile, pero que en ejecución falle, son pocas pero las hay, aunque siempre se pueden controlar añadiendo un mayor control de excepciones.
– Cambio de estructura de proyectos, como en el caso de los Servicios Windows, pero se soluciona creando el proyecto desde cero e inyectando progresivamente las clases y métodos necesarios.

En resumidas cuentas, un camino que puede ser mas o menos pesado dependiendo de cuan complejo sea el proyecto, pero en el cual siempre hay vías de hacer que la migración funcione.

Planteemoslo de otra manera, ¿para 2002 habían en producción aplicaciones en VB5 o VB4? Lo dudo sinceramente, el punto de quiebre fue VB5 y como comentaba la migración de VB5 a VB6 era totalmente transparente, salvo (como de costumbre) en la dependencia de algún control de terceros.

Osea, que para migrar dentro de versiones de VB.NET o de Visual Basic “clasico” los caminos han estado mas o menos marcados y eran controlables, pero… para migrar de VB6 a VB.Net… ahi es otra cosa.

Como mencionaba lineas arriba los cambios vinieron por dos frentes: cambios traumaticos en el lenguaje y reemplazo del framework basado en COM por uno basado en .NET. (los dos primeros capitulos de este libro pueden dar una vision de los cambios), si le sumas esto al hecho de que cuando Anders Hejlsberg acometio el desarrollo de .Net, decidió crear un nuevo lenguaje C#, e hizo muchos de los diseños del CLR y el CLI sin tomar en cuenta las particularidades (ya muy usadas por los desarrolladores) de VB, esta claro que lidiar con los cambios seria una tarea harto compleja, cito el libro arriba mencionado:

The Decision to Break Compatibility

When did Microsoft decide to break compatibility with Visual Basic 6? It was actually in early December 1999, during the development of Visual Basic .NET. Until that time, Visual Basic .NET was being developed to support the notion of “Visual Basic 6 sourced” projects that allowed you to edit and compile Visual Basic 6 projects in Visual Basic .NET. These projects would have a compatibility switch turned on, meaning that the language would be backward compatible with Visual Basic 6 and would even have access to the old Visual Basic 6 forms package.
By the end of 1999, it was obvious that this strategy wasn’t working.
Little differences were slipping through: The old forms package could not be fully integrated into .NET, and the Visual Basic 6 sourced projects could not use some of the new features of the .NET platform. At that point Microsoft made the decision to break compatibility and instead concentrate on ensuring that people could upgrade their projects from Visual Basic 6 to Visual Basic .NET.

En fin, es cierto que muchos cambios (de lenguaje) eran inevitables y demandados por la comunidad de desarrolladores: soporte de herencia, excepciones y threading, pero esta claro que Microsoft pudo haberlo hecho mejor en algunos aspectos (de hecho, parte de las criticas de los gurus arriba citados van por el lado de que algunos cambios no eran necesarios para hacer a VB un lenguaje OOP) como la gestión de los arrays, no forzando a tener que hacerlos basados-en-zero y si por el contrario permitir que su gestión de limites sea equivalente a la de VB6.

Entonces esa es la situación a la que llegamos cuando sale al mercado Visual Studio .Net 1.0, el gap del Framework y el lenguaje es tan grande que solo proyectos triviales son susceptibles de ser migrados a .NET, para lo demás muchas veces es mejor hacer el proyecto desde 0, o sino… seguir manteniendo y parchando el código en VB6 hasta que se decida tomar la decisión de migrar (pues ya se sabe lo que dicen las gerencias “Si funciona ¿para que tocarlo?”, claro, es así como el COBOL no muere). La dura realidad es esa, que las organizaciones se han quedado con un parque de aplicaciones para un lenguaje/plataforma que ya no evoluciona y si bien ahora se cuenta con una buena herramienta como el Artinsoft Visual Basic Upgrade Companion, la verdad es que en todo proyecto complejo nos toparemos con situaciones como estas:

– Las inevitables llamadas a la API de Win32, ya no funcionan, y no hay forma directa de hacer un cambio que permitan la recompilacion.
– A revisar todos tus arrays para estar seguro de su comportamiento.
– Replantearte como gestiona el ciclo de vida de tus objetos.
– Los controles y clases tienen otras propiedades, no hay equivalente directo en .NET para algunas clases de terceros y la importación (wrapping) no siempre es segura.

Previo al lanzamiento de VS.Net, algunos articulistas pedían que saliera una ultima versión de VB basada en COM que facilitara la transición y/o introdujera algunas mejoras a VB6, la verdad es que mire de lejos esas peticiones, claro… estaba entusiasmado por el giro a OOP que no mire la complejidad que estoy narrando, pero ahora luego de estos 10 años de .Net (contando desde su primer anuncio y Beta) creo que si que Microsoft debió intentarlo y proveer esa herramienta a fines del 2000 o principios del 2001 a fin de que hubiera un punto intermedio en el camino desde VB6 hacia .Net, lo cual me lleva a la pregunta planteada como titulo de este post….

Personalmente yo hubiera excluido la herencia como caracteristica de un VB 6.5, implementarlo es complejo y el problema radica en como gestionar caracteristicas usadas en las aplicaciones hechas en VB 6 para que funcionen luego en .NET, siendo asi, VB 6.5 debería haber tenido (como anticipo al cambio en .Net):

– Soporte dual para arrays con limites libres y basados-en-zero. Si MS seguia terco en lo de no permitir los limites libres, la compilación debería permitirlo pero indicar que esa característica estaba “deprecada” y no soportada en futuras versiones.
– Fin de las propiedades por defecto de los objetos.
– Eliminación del tipo Variant.
– Cambio en el ámbito de la visibilidad de las variables.
– Uso obligado de paréntesis en las subrutinas.
– Ofrecer un mecanismo de llamadas a la API Win32 cercano al uso que luego tendria DLLImport, pero respetando (temporalmente) la mayoría de los hacks que se tuvieron que hacer para trabajar con dicha API.
– Opcional: soporte para try..catch..finally
– Únicos cambios en el IDE: Encontrar todas las referencias, herramienta imprescindible ahora para una adecuada inspección del código, y un compilador que devuelva una lista de errores y no uno por uno.

La idea de esto seria que los desarrolladores acometieran ciertos cambios sin retorno, sin todavía decirle adiós a COM, para de esta manera tener hechos los deberes en el grueso del lenguaje, quedando (en teoría) cambios menores en el lenguaje y “solo” adaptarse al .Net Framework.

Si Microsoft hubiera hecho esto, a estas altura no habria esas aplicaciones en VB6 que se resisten a morir, haciendo a VB6 el nuevo COBOL, pues eso es lo que esta pasando… un nicho de aplicaciones que persisten mas alla de su ciclo de vida.

Y tu ¿que característica le hubieras puesto a un VB 6.5 todavía basado en COM?.

Luego de mes y medio con Windows 7

Posted on by ecardenas

Bueno, ya tocaba luego de estar en la fiesta de El Bruno compartir mis experiencias con Windows 7 Ultimate x64.

Antes que nada debo de comentar de que hubo dos razones por las que opte por la version de 64 bits: estar cansado de tener 1 GB de memoria totalmente muerto de risa debido a las limitaciones de direccionamiento de memoria de los sistemas operativos de 64 bits, ademas con que contaba con usar el “Windows XP mode” por lo que un poco mas de memoria seria de mucha ayuda.

Ya he contado lo que tuve que hacer cuando cambie de placa (no de procesador, ojo) y reinstale Windows, por lo que solo debo indicar que a estas alturas habia reemplazado un disco de 320GB (!con dos particiones!) por uno de 1.5 TB en una unica particion, el cual destinaria fundamentalmente para datos y archivos grandes.

La instalacion fue sencilla, no tuvo ningun problema en trabajar con soporte AHCI y copiar los archivos del nuevo Windows.

El unico problema fueron los drivers, en cuanto a video ATI habia sacado drivers compatibles con Windows 7 para mi Radeon, con la advertencia de que por limitacion de hardware no usaban toda la potencia de la ultima version de DirectX. Pero el principal inconveniente fue de que Asus no ha sacado soporte Windows 7 para la P5E WS Professional, por lo que he debido de usar las versiones Vista 64 para la tarjeta integrada de red, asi como para audio (aunque en esto me detendre luego).

En contrapartida debo decir que no hubo necesidad de instalar nada para que reconozca ni mi Scanjet 3570c HP (comprado el 2003) ni mi antena Bluetooth.

Todo operativo y funcionando, a excepcion del sonido al cual tuve que dar muchas vueltas hasta que decidi usar los drivers Windows 7 proveidos por Realtek y no por Asus, aun asi tuve que hacer varios intentos para que me funcionaran los parlantes Creative 5.1, pero una vez logrado esto no he vuelto a tener problemas.

La verdad es que estaba algo asustado, pues igual no alcanzaba un buen rendimiento con un chip Core2Duo de 2.1 Ghz del 2006, con memoria de 833, hardware que al dia de hoy dista mucho de lo ofrecido en el mercado. Al final resulto que el comportamiento es mucho muy bueno, aun aplicaciones complejas corren sin problemas y teniendo mas de una abiertas.

Ya que hablamos de aplicaciones, toca hablar de MP3Gain, la unica de las aplicaciones que uso habitualmente que no corrio en 7, ¿la razon? En Windows 7 no se ha introducido soporte para COM, lo cual descarta tambien a aplicaciones como el controvertido Visual Basic 6.

Este “problema” con MP3Gain me obligo a adelantar un paso que ya habia considerado desde el principio: el uso de Windows XP Mode, la razon original para ello era para solventar la razon por la que no migre a Vista: la potencia de la version 9 del Windows Media Player, biografias, reviews e identificador de canciones.

Para instalar Windows XP Mode solo toco bajarse el componente respectivo de la web de Microsoft, instalarlo y lanzarlo desde el boton de inicio, asi es, sin necesidad de instalar el sistema operativo dentro de una maquina virtual nueva, total sencillez y transparencia.

El resto fue sencillo, instalar el MP3Gain dentro del XP Mode, verificar que le faltan algunos Common Controls, descargarlos y listo… . Y claro que el Windows Media Player 9 corre bien dentro de la maquina virtual.

Asi pues, luego de reconfigurar mis aplicaciones he visto que la performance es muy buena, y me he vuelto adicto a la nueva barra de trabajo con sus miniaturas de las aplicaciones corriendo, nunca habia sido tan facil cambiar entre aplicaciones.

No todo es color de rosa, asi que toca comentar lo que me ha costado un poco mas adaptarme:

– Un Media Player menos potente que el 9, pero eso ya lo sabia de antemano y como ven lo he podido arreglar con el uso del XP Mode. Ojala algun dia Microsoft reincorpore en el WMP las cosas buenas que tuvo dicha version.
– Un buscador de archivos mas dificil de usar, en teoria ahora se incorpora una indexacion de archivos mas poderosa que la de versiones anteriores, el problema es que ahora pasar parametros de busqueda es muy complicado, de momento no he podido acotar la busqueda a un rango de fechas, solo decirle si fue creado/modificado antes o despues de una unica fecha dada, y si queremos a eso añadir una restriccion de tamaño, mas dificil aun, siendo que esta caja de dialogo te daba toda la potencia necesaria en tus busquedas:
Seguro que hay alguna forma de hacer lo que busco, pero es curioso que siendo este nuevo SO efectivamente mas sencillo de usar, haya por ahi “algo” en el que se da un paso atras.

Ahora solo resta esperar que vayan saliendo mas y mas versiones de nuestras aplicaciones en version 64bits, para asi hacer aun mas optima la gestion de memoria. Pero nuevamente, estoy muy satisfecho con el hecho de que no he tenido que actualizar nada de mi equipo de 3 años para que Windows 7 trabaje razonablemente rapido y sobre todo muy pero muy estable.