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.

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.

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?.

Si tuviera que decir que funcionalidad del Visual Studio (y de VB6 ya puestos) he estado usando mas ultimante, la respuesta seria "Go to Definition" (seguida de "Find All References").

La razón de esto es debido a que ahora me corresponde estar en mantenimiento de aplicaciones, lo cual implica que cuando hay un error tratar de encontrar que metodo o clase fallo y ver que hacer para solucionar el error, y en otras ocasiones añadirle una funcionalidad a cualquiera de las aplicaciones ya existentes (en cuya creación yo no intervine).

Como ya explique anteriormente esta es una situación en la que no se empieza de cero, y se requiere tratar de entender de manera rápida el como esta montado todo a fin de encontrar la raiz del problema, por lo cual usualmente tengo dos caminos:

- Ubicar la aplicación e ir haciendo una "depuración sin ejecutar" mediante el "Go to definition" tratando de ubicar los puntos de paso críticos que hay durante la cascada de llamadas de los sucesivos métodos involucrados en la funcionalidad.
- Buscar el texto con el mensaje de error reportado, y de esa manera mediante el "Find all references" identificar de abajo hacia arriba la posible pila de llamadas y en el camino encontrar lo que ocasiono el problema.

Pero llegados a este punto vemos que se ha incrementado la demanda por desacoplamiento y pruebas unitariasdentro de nuestros codigos, todo como parte de los patrones SOLID:

* SRP: The Single Responsibility Principle (Principio de Responsabilidad Única)
* OCP: The Open/Closed Principle (Principio Abierto / Cerrado)
* LSP: The Liskov Substitution Principle (Principio de Sustitución de Liskov)
* ISP: Interface Segregation Principle (Principio de Segregación de Interfaces)
* DIP: The Dependency Inversion Principle (Principio de Inversión de Dependencias)

Principios muy interesantes, que valen la pena revisar, pero que introducen tendencias como la Inyección de Dependencias y la Inversión de Control, para lo cual recomiendo este muy bien explicado articulo de Gisela Torres de donde extraigo esta explicacion;

Generalmente, cuando tenemos una clase que depende de otras para ciertas acciones, necesitamos inicializar instancias de las mismas para poder utilizarlas posteriormente. En ocasiones, una de las alternativas puede ser crear un objeto de dichas clases de forma privada e inicializarlas, utilizando el constructor de la clase principal.

Si vemos estas acciones desde el punto de vista de la Inyección de Dependencias y la Inversión de Control, no sería la forma más óptima debido a que la clase que sufre estas dependencias no debería ser la responsable de la creación de las mismas.

¿QUÉ CONSEGUIMOS?

• Desacoplamiento.


• Mejora la posibilidad de testeo de la aplicación.


• Mejor mantenimiento a la hora de realizar cambios de los componentes, gracias a la modularidad.


• [...]

Ambos conceptos están tan ligados que, en ocasiones, no se hace distinción. Se utiliza el concepto Inversión de Control para delegar en otro componente, un framework por ejemplo, la responsabilidad de crear las instancias necesarias en lugar de crearlas nosotros mismos. Por otro lado, la Inyección de Dependencias es el término utilizado cuando una clase depende de otra y, a través del constructor generalmente acepta un parámetro del tipo del cual depende. 

Siguiendo el ejemplo, podemos ver que en lugar de el tradicional mecanismo de instanciación de la clase que necesitamos, por detras existe un interesante mecanismo de Configuración y Factoria de Objetos que nos permiten que en lugar de:
public class HomeController : Controller
{
private readonly ITwitterService _twitterService;
public HomeController()
{
_twitterService = new TwitterService();
}

public ActionResult Index()
{
return View(_twitterService.FetchTweets());
}
}

Tengamos:
public class HomeController : Controller
{
private readonly ITwitterService _twitterService;

public HomeController(ITwitterService twitterService)
{
_twitterService = twitterService;
}

public ActionResult Index()
{
return View(_twitterService.FetchTweets());
}
}

Nada mal según parece, usamos interfaces, y se logra una mayor facilidad para pruebas unitarias, lo cual es uno de los objetivos a lograr, pero oh sorpresa... si ahora le hacemos "Go To Definition" al FetchTweets notaremos que ya no vamos a la implementación del método en cuestión (definido en la clase TwitterService), sino al cuerpo de la Interfaz ITwitterService, lo cual detendría nuestra búsqueda en cascada, al no tener mucha idea de cual es la implementación real que se esta invocando, por lo cual nos quedan dos potenciales soluciones:

- Correr la aplicación y en tiempo de ejecución ver la implementación real para así tomar las medidas de análisis necesarias a fin de resolver el problema.
- Tratar de entender la configuración de las dependencias y así inferir cual es la clase que se esperaba instanciar.

Como se comprenderá esta circunstancia puede hacer complicado una tarea de mantenimiento, y la idea de que esas tendencias pueden significar un problema, no en el tiempo de desarrollo, sino en posteriores mantenimientos me han dado vueltas en la cabeza durante un buen tiempo, hasta que encontré este interesante articulo, del cual cito y traduzco:

Yo lo he experimentado de primera mano, en muchos diferentes proyectos donde he tenido que hacerme cargo de codigo despues de que un desarrollador dejo la compañia, y puede ser una experiencia exasperante. Una mejora es solicitada, o un bug es reportado, digamos que se trata de un bug. Se me puede haber dado una excepcion en la pila, y eso al menos me lleva al codigo fuente en donde empezar. Lo que usualmente encuentro es un bonito set de pruebas unitarias que puedo correr y comprobar que todas se ejecutan correctamente, lo cual no es una gran sorpresa; pero, todos los tests usan "mocks" por lo que no puedo reproducir inmediatamente el bug como no sea escribiendo un lindo mock test para simular como el código debería responder ante un particular error de entrada, puesto que yo puedo "mockear" facilmente el error. Eso esta bien, pero no es util si mi objetivo principal es evitar que el error ocurra.

¿Que clase en concreto es la responsable del bug? Aqui es donde se pone complicado, en la mayoria de los casos, la pila no te da ninguna pista. Leer el codigo y examinar la configuración puede ser una enorme perdida de tiempo y termina siendo una tediosa búsqueda en amplitud.


Como el autor apunta "la capacidad para obtener información rápidamente y entender un programa al leer el código es degradada por IoC debido al desacoplamiento", y así.. esa seria la alerta con la que nos deberíamos quedar, ver cual es el lugar de estos patrones, y si la búsqueda de objetivos en este momento como el desacoplamiento y las pruebas unitarias, no vendrían a significar un lastre en el largo plazo, cuando la aplicación tenga que ser mantenida por un equipo diferente.

El paso por mantenimiento de aplicaciones te hace tener en cuenta estas otras consideraciones.

Otro articulo interesante:
Dependency Injection makes code unintelligible

Bueno, este mes toca entregar la declaración de la Renta aquí en España, así que como buen informático, acostumbrado a casi no ir a bancos y hacerlo todo por Internet, decidí nuevamente hacer uso del programa PADRE de la AEAT.

Ya había tenido problemas en años anteriores, pero la solución al final paso por:
- meterte al "about:config" del Firefox, y habilitar a "true" el signed.applets.codebase_principal_support
- Ya cuando toco hacer la transmisión... al final usar Internet Explorer, pues por alguna razón el paso final no podias hacerlo desde Firefox.

Eso durante los dos años anteriores, esperaba que la cosa hubiera mejorado en este periodo pero... error.. hemos ido para peor como contare:

- Lo primero y mas sangrante, es que a diferencia de años anteriores, nomas bajarse el programa se nos advierte de instalar la Java Virtual Machine, lo cual indica que la aplicación ya no era nativa de Windows, con las consiguientes perdidas de performace.
- Otro error de diseño, la instalación coloca al programa en C:\AEAT en lugar de c:\archivos de programa, que es como indican las practicas recomendadas para aplicaciones Windows, con los consiguientes problemas de seguridad y usabilidad que luego comentare.

Pero bueno, lo instale sospechando que esa ubicación le daría problemas a la ejecución... en todo caso me asegure de verificar que tenia a Internet Explorer marcado como browser por defecto, ya que al menos IE si que incorpora como Autoridad de Certificacion, de serie, a la FNMT, todo lo contrario que Firefox a pesar del tiempo que se lleva pidiendo esa modificación.

Arranquemos el programa, doble clic, nada... doble clic.. nada, botón derecho "Run as Administrator" ahi si!!! primer problema, ¿qué sabe un usuario común y corriente de eso de elevar privilegios? y ¿si por seguridad tu cuenta de Windows no permite el elevar privilegios a menos que tengas el password respectivo?.. bueno.. primer problema resuelto.

Bueno, la aplicación es de su padre y de su madre, no tiene ningún criterio de usabilidad basado en las experiencias conocidas de Windows, botones diferentes, tipografía diferente a la que tengas configurado tu Windows, y un pequeño detalle.. cuando entras a crear una declaración el botón/enlace para "Nueva Declaración" no funciona a menos que hayas escrito primero el nombre de la nueva declaración a crear, siendo que lo usual es que luego de dar "nuevo..." recién se te habiliten los campos de edición o bien un cuadro de dialogo te invite a llenar el dato... me pregunto si esa practica es lo usual en Mac o en Linux...

Luego de enterarme un poco de que va ello (insisto, rompe los paradigmas que solemos tener cuando usamos aplicaciones Windows) solicito que se importen mis datos de usuario, lo cual predeciblemente termina invocando a mi browser por defecto: Internet Explorer, pero.... veo que le solicita permiso para ejecutar ¡un control ActiveX!!, le doy permiso y.... nada, en eso me pregunto que si no estará lanzando la versión de 64 bits de IE (tengo Windows 7 Ultimate 64 bits), así que lanzo manualmente la versión 32 bits de IE y repito el proceso, y felizmente el PADRE decide valerse de esa sesión y ahí si... si funciona la importación de los datos que tiene la AEAT sobre, previa firma digital por parte mía, por supuesto.

Importa los datos, y como es lógico decido enviar la declaración telematicamente, me salio a pagar asi que escojo el modo de "adeudo" pues se me paso la fecha para domiciliar el pago, y descubro que:
- El IE no encuentra el archivo .100 con mi declaración, ¿que había pasado? simple, cuando le di a grabar mi declaración (desde el PADRE) escogió grabarlo en "Mis Documentos" en vez del C:\AEAT, por lo que relance el proceso asegurandome esta vez de grabar el archivo .100 en la carpeta de marras.
- Hay un error de "secure channel" cuando desde el IE inicio el proceso para que se notifique a mi banco para que se pague mi deuda...
- Probamos pagarlo con tarjeta de crédito... nada, por alguna razón mi banco no aparece listado, lo cual hace la cosa aun mas bizarra, pues en todo pago que hecho con mi tarjeta de crédito, nunca se me ha pedido el banco emisor, solo el tipo (VISA/MC/AMEX) y los datos correspondientes.

También intente con Firefox para ver si podía evitar el problema del "secure channel", pero nada, y como era predecible en Firefox aun se necesita habilitar el signed.applets.codebase_principal_support, y agregar manualmente a la FNMT como Autoridad Certificadora.

Por si creían que usando Internet Explorer solo tenia el problema de los 64 bits, pues no, en algún momento (que no recuerdo) del proceso tuve que modificar mi definición de sitos de confianza, agregando manualmente a los sitios de la agenciatributaria.es, pues de otra manera las transmisiones no funcionarian.

Obviamente que todos estos trucos y workarounds los fui buscando conforme me tropezaba con los problemas, y debo decir que si siendo informático ya me resulta un poco pesado toquetear el proceso, para un usuario común ya es algo complicadisimo.

Lo ideal seria que la parte (tecnica, no tributaria) mas complicada del proceso sea instalar el certificado digital y dar la firma cuando te lo pida, pero como se puede ver lograr que el proceso sea transparente al usuario no ha estado en los objetivos de los "genios" de la Agencia Española de Administración Tributaria.

.... ya contare como lo soluciono....

Hace unos días conversaba con Angela sobre el hecho de que a pesar de estar ambos fuera del Perú, existen todo un conjunto de opciones para estar "al día" con respecto a lo que pasa ahí (política, deportes, estrellas de Youtube), lo cual me llevo de vuelta a una idea que me había dado vueltas en la cabeza hace un tiempo: ¿que tan factible es tener/simular "la experiencia de vivir" (virtualmente) lo que pasa en un país que no conoces y al que no has visitado?.

En teoría debería ya ser posible, pues a estas alturas ya hemos superado la etapa en que eramos solo consumidores de información, por lo que volví sobre una idea de hacer esta experiencia un experimento universitario para un curso semestral, con variantes de acuerdo al perfil de la carrera, siendo que el curso que yo haya llevado que mas se podría aprovechar este experimento seria la Sociología(*) que lleve en EEGGCC.

En términos generales se parte de la idea que cada alumno debería asumir un rol de "impostor" y de "seguidor" simultáneamente, la duplicidad de roles viene dada a efectos de control, como ire explicando.

En el rol de "impostor" cada alumno tendría que simular vivir en un país dado al azar, y como "seguidor" hacer un seguimiento de la huella que un compañero (también al azar) va dejando, para esto al final de cada semana uno debe informar a su respectivo "seguidor" de los lugares mas relevantes por los que ha pasado. En otras palabras, cada alumno seria "impostor" sobre un país dado, seria "seguidor" de un compañero, y a la vez tendría un "seguidor" que lo monitorearia.

Se entiende que la razón de establecer el rol de "seguidor" es ver la huella que el "impostor" va dejando (para efectos de registro y elaborar un informe), pues parte del reto es hacerlo convincentemente y lograr que alguien totalmente externo pueda generar respuestas, debate y hasta controversias sin llegar a ser un troll. Este aspecto es tal vez el mas importante de mi propuesta, pues no se trata tan solo de recopilar noticias de actualidad del país elegido, sino también ser parte de los pequeños debates y trends que se van generando en cada diferente realidad.

En el estado actual los sitios destinos para simular la "experiencia de vivir" : twitter (no Facebook), Skyscrapercity, uno o los dos primeros diarios (generalistas) de circulación nacional así como uno deportivo. Por supuesto que se dejara abierto a que en clase se sugiera algún foro adicional.

¿Por que Skyscrappercity? porque es es un foro donde la gente discute urbanismo de manera coloquial y comenta sobre como eran y han ido cambiando sus ciudades, así que es un buen mecanismo de demostrar hasta que limite podemos llegar con la impersonación planteada.

Para simular mejor la idea, se cogerán los 5 mejores equipos (según el campeonato del año) de fútbol y por sorteo el alumno deberá asumir ser hincha del equipo que te haya tocado. Así que si te toca un equipo nuevito y de poca hinchada que le ha ido bien (como el San Martín) piña pues, tendrás que defenderlo en los foros o comentarios sobre las respectivas noticias.

Previo a la "identidad falsa" se dispondrán de dos o tres semanas para elaborar un informe preliminar sobre la situación del país, estableciendo (no hay que ser muy rigurosos) los 3 principales perfiles sociopoliticos urbanos.

Países: descartados los muy mediaticos, así en en el caso de Perú descartariamos: Argentina, Chile y Venezuela, pero seria muy interesante incluir Belice o Guinea Ecuatorial. Estos filtros van de cara a evitar en lo posible que un alumno que tenga asignado a Argentina tenga mucha ventaja sobre el que tiene asignado a El Salvador, p. ej.

Lo que no tengo tan claro (y quedaría abierto a la implantación del profesor):

Si el alumno deberá hacer la "impersonación" sobre el país acerca del que hizo la investigación o se le asignara el informe hecho por algún compañero, tampoco tengo claro si seria conveniente decirles que asuman alguno de los perfiles sociopoliticos identificados en el primer informe, probablemente esto dependa del tiempo y de cuan profundo se quiera que sea el análisis.

La idea es simple, comprobar la viabilidad de una posible impersonación hacia una identidad nacional que es la de uno, aparte claro esta de descubrir mas cosas sobre otra realidad. La idea esta puesta, ¿alguien se anima a montarla?


(*)Curiosamente fue en el curso de Sociología de la profesora Sandra Vallenas que tuve mi primer esbozo de lo que era Internet, gracias a la charla que nos dio Carlos Wendorff sobre lo que se empezaba a hacer: correo electrónico, conversaciones en tiempo real, boletines....

Hace exactamente 3 años comentaba la situación en la que se encontraban muchas empresas, ancladas al pasado tecnológico con tecnologías de mas de 20 años, y de paso enlazando tecnologías que estaban muriendo o agonizando: Cobol(*), Bases de Datos no Relacionales, redes no TCP/IP, ccMail, ColdFusion, C (puro, no C++), PowerBuilder, Netware, PC network y OS/2; claro esta que a esa lista añadiria xBase (¿se acuerdan cuando casi todo pequeño negocio tenia su aplicación en Clipper o Fox para DOS?).

Ya sabemos que aun en pequeños negocios como cabinas de internet cuesta de convencer el migrar hacia tecnologías mejores y mas eficientes, pero aun así al ver la lista mencionada uno ve que el estado de estas tecnologías es mas bien dispar, algunas tecnologias estan realmente muertas o terminando de morir en sus ultimos espacios, mientras que otras a pesar de no brindar nada nuevo, siguen siendo la base para nuevos desarrollos, conviviendo con otras tecnologías.

¿Qué es lo que hace que algunas resistan y otras no? Especulare un poco y a ver si comparten mis ideas.

1)La ola es muy fuerte y no puedes sino dejarte llevar, si, en este caso estamos hablando de Internet y el efecto de arrastre que implico para la adopción del protocolo TCP/IP como la opción por defecto en las organizaciones, todo Ethernet, adiós token ring, protocolo IPX.... lo cual de rebote termino cargándose a las redes Netware de Novell, antaño bien implantadas en muchas organizaciones. Así que si todos los proveedores, incluyendo los de mainframe, deciden dar el salto al soporte de TCP/IP (como ocurrió en la segunda mitad de los 90s) el cambio ya es inevitable. Por mas que algunos digan que Internet resucito un protocolo que ya era "cadáver", al final la inercia del mercado y la demanda por conexión a Internet nos arrastro a todos, y ya no miramos atrás.

2)El costo de mantener la compatibilidad es muy alto comparado con la migración, aquí ya entro un poco en la especulación basándome en lo que he visto en las pymes, quieras que no el mercado de aplicaciones para pymes es muy dinámico y llega un momento en que ya no se pueden mantener las aplicaciones existentes por: no se pueden encontrar profesionales, o porque eventos como la introducción de Windows 95 o el problema del año 2000 te hacen sacar la calculadora y ver que mas barato te sale migrar que seguir manteniendo tu querido Clipper.

3)Lo que elegiste no era tan masivo y cada vez te costara mas encontrar soporte, aquí caen dos tecnologías al margen de sus méritos: Delphi y PowerBuilder, efectivamente ofrecían una buena respuesta tecnológica a las necesidades de desarrollo en Windows de esa época (mejor que VB en el caso de Delphi, p. ej), pero la presión introducida por el desarrollo de aplicaciones Web, así como la pujanza de .NET y Java, hizo que el nicho de mercado que se había construido alrededor de estas tecnología se debilitara impulsando su migración. Lo bueno en este caso es que la arquitectura modular de estas tecnologías (el entorno de desarrollo de la aplicación no esta amarrado a la BD como en xBase) permite migraciones menos traumaticas y mas progresivas.

4)Es mas caro migrar que mantener la compatibilidad si, al revés que el caso 2) y en este caso nos topamos con los engreídos de la industria: el mainframe ya sea en sus variantes PL/1 o COBOL, están ahí, las empresas se resisten con uñas y dientes al cambio, por la sencilla razón de que debido al volumen y trafico de información, el riesgo de tener la producción caída es algo que no se puede asumir, punto. Es curioso que cuando hubo el problema del años 2000 en algunos casos se haya optado por una huida hacia adelante, parchando la infraestructura en vez de aprovechar la oportunidad de reemplazo. Y así como están las cosas, se requerirá mucho valor y cabeza fría para que una organización decida migrar sus aplicaciones, pero la verdad.... ¿de veras tiene sentido basar lógica de negocio en la posición de un carácter en un texto plano?

5)Entenderlo es mas complicado que parcharlo esta es la peor situación de todas, pues la limitación viene dada no por las características de la tecnología, si no por como esta tecnología no te coloca restricciones para hacer mal código, concretamente Visual Basic 6 cae en esta categoría, ya que como comente antes es perfectamente posible construir aplicaciones en VB6 con una arquitectura robusta y buenas practicas (y he visto buenas aplicaciones de este tipo), pero la propia filosofía del lenguaje no te impulsa a ello, recayendo totalmente en el desarrollador y la organización el montar algo ordenado, siendo que una vez empezado el trabajo esa reorganización es tarea imposible. Resultado: que esas aplicaciones se mantengan, crezcan y crezcan a golpe de parches, haciendo la migración algo temido por la organización, haciendo que VB6 ya sea considerado como el nuevo COBOL, con la diferencia de que el soporte y evolución quedo cerrado hace rato, así que solo resta esperar una nueva revolución que nos fuerce a dejarlo.

Esto es, dentro de mi experiencia, lo que creo que establece diferencias entre los destinos de diversas aplicaciones, me quedo con la curiosidad de saber cual ha sido el proceso por el que pasaron tecnologías como ADABAS, mainframes NCR y AS/400.

(*)Aunque yo lo consideraría de la mano de su hermano en mainframe: PL/1.

Como desarrolladores generalmente esperamos estar desde el arranque de un proyecto, con la idea de que asi "esta vez hacer las cosas bien" usando una buena arquitectura y claro, con lo ultimo de la tecnología, al final terminamos llegando al estado de "parecia una buena idea en su momento" y que hay que terminar el proyecto "como sea", bueno... exagero un poco, pero debe quedar claro que estar en el proyecto desde un inicio no es una garantia para que todo vaya como una seda todo el tiempo.

Pero para bien o para mal, si uno es un desarrollador "desde las trincheras" y no un "guru", no sera rara la situación en que nos veamos en la necesidad de dar mantenimiento a un programa que alguien mas haya hecho o empezado (en cualquier grado de avance), y ahí es donde empieza nuestra historia.....

Antes de proseguir, debo decir que cuando he estado una buena temporada en un proyecto, trato de pensar (sobre todo en las ultimas etapas) en "como hacerle mas simple la vida al pobre tipo que se hara cargo de esto" para lo cual opto por un enfoque realista, dejar comentarios en las secciones de código que se que pueden ser mas crípticas, y de ser el caso dejar documentación útil, ¿y cuando una documentación es útil? ¿no se supone que lo útil es documentar todo lo posible? ¡Error! una documentación es util cuando uno honestamente sabe que leyéndola proveerá una idea para entender la lógica detras de la implementación de un código.

Entonces como decia, nos encontramos en la situación de que hay una aplicación existente, en cuya creación no hemos intervenido, y se nos pide ver porque ha dejado de funcionar o que le agreguemos una nueva funcionalidad, la documentación es escasa y con suerte tenemos las referencias de los servidores involucrados.

Asi que con esta premisa vamos tras el codigo fuente a ver que podemos sacar en claro (*), con lo que nuestra rutina es mas o menos como sigue:
- Ubicar el punto de entrada de la aplicacion, o sino, los controles y sus eventos respectivos que desencadenan la accion a investigar.
- Ubicado el punto de entrada o el evento deseado (capa de Interfaz de Usuario), ir viendo como se van creando las sucesivas instancias de las capas de Negocio, Fachada, Datos y los métodos involucrados.
- De ser necesario ir depurando para evaluar los valores que van tomando las variables criticas...

En fin, este es el mundo real y creo que alguna vez todos habremos pasado por este lió, siendo nuestros dilemas el saber a que clase/metodo se esta invocando desde un punto del código, así que me he sentido afortunado cuando he podido hacerme una idea del código usando las herramientas para encontrar la "Definicion" de un método invocado.

Es que así es el código típico:

- Método f1 de la clase A necesita llamar al método f2b de la Clase D.
- Método f1 instancia un objeto "miD" de la Clase D.
- Método f1 ejecuta el método miD.f2b.
- Método f2b de la clase D necesita......

Si el código esta mas o menos estructurado (y no es un spagetti por supuesto), esa es la lógica que uno busca, con las debidas excepciones de cuando se tienen que ejecutar instancias remotas y/o usando Interfaces en vez de clases directas.

Una de las cosas que tienen de bueno los entornos RAD como Delphi y .NET (WebForms y Winforms) es que brindan un mecanismo comprensible para empezar a depurar, sabes el control y quieres ver que hace, pues entonces... a ver los eventos vinculados y de ahi para adelante, de capa en capa. Quienes hemos trabajado con ASP Clasico recordamos la pesadilla que eran los puntos de entrada de las paginas, revisando todas las posibles combinaciones de parametros que venia en el Request razon por la que la introducción de WebForms fue la respuesta a nuestros problemas, y para mi lo sigue siendo.

Pero la evolución del desarrollo de software es imparable, y asi hemos visto como han surgido tendencias que han procurado añadir valor a nuestros ciclos de desarrollo como: WebServices, Refactorizacion, SOA y varios intentos de mecanismos para construir una arquitectura distribuida: DCOM, COM+, .Net Remoting, WCF....

Pero al margen de como vayan evolucionando las tendencias, una cosa que siempre procuro en mis desarrollos, es dejar el camino mas o menos despejado para que el que venga luego pueda entender el código que esta leyendo, procurando tener las inevitables sofisticaciones bajo control. Teniendo esto en cuenta... cabe preguntarse si tendencias como el "desacoplamiento" y la necesidad de "pruebas unitarias" facilitan o no la vida del que luego tiene que enfrentarse a mantener tu código, pero ese análisis lo dejo para un posterior post.

De momento quiero dejar la reflexión de que a veces estamos tentados a emplear unos patrones novedosos, potentes, pero... también debemos pensar que no todos los desarrolladores siempre desarrollan desde cero, que se llega a proyectos ya empezados, a código terminado en producción que hay que mantener, y que no hay que complicarle la vida en aras de lucirte con lo mas novedoso en metodologias y arquitecturas si es que no es de veras necesario, ya que estas no solo deben prometerte mas facilidades para ti, si no para el que luego tendra que mantener tu codigo.

(*)Aunque alguna vez no contamos ni siquiera con el código fuente, como me paso en un cliente hace 3 años, por lo que toca ver si podemos desensamblar el código, pero eso ya es otra historia y mas bien un extremo de irresponsabilidad por parte del cliente.

Pues justo ahora que comentaba sobre si al final Google lograria que Internet Explorer desaparezca, leo esta nota en Slashdot:

"Following Google's announcement ending support for Internet Explorer 6, I find myself wondering whether we (Web developers) really need to continue providing support for IE6 and IE7. Especially when creating Web sites intended for technical audiences, wouldn't it be best to end support for obsoleted browsers? Would this not provide additional incentives to upgrade? Recently I and my colleagues had to decide whether it was worth our time to try to support anything before IE8, and in the end we decided to redirect any IE6/7 user-agent to a separate page explaining that the site is not accessible with IE 6 or 7. This was easy once we saw from our analytics that fewer than 5% of visitors to the site were using IE at all. Have you had to make a choice like this? If so, what was your decision and what was the reasoning behind it?"

En resumidas cuentas, se cuestionan si en estos tiempos los desarrolladores de Web deberían seguir dando soporte a browsers obsoletos, siendo que era mejor redireccionar a los usuarios a una advertencia diciendo que el sitio no era accesible en IE 6 o 7, lo cual fue fácil ya que menos del 5% de los usuarios usaban IE.

Razonamiento simple ¿verdad? es mas, yo lo seguiría en la mayoría de los casos en que tuviera un site abierto, dedicado al publico masivo, pues me interesaría contar con elementos actuales que faciliten la programación de una mejor experiencia de usuario, pero......

Hay veces en que la disponibilidad y usabilidad de tu site estan definidas por un contrato, y este contrato no es con un usuario final individual sino con una institucion (ya sea publica o privada), por lo que si luego de una pequeña modificación en una pagina, te llama un cliente quejándose de que no le funciona la Web usando IE 6 (o IE5) no tienes sino que revisar y hacer que la aplicación vuelva a funcionar. Es por esa razon que antes de hacer un pase a producción de un cambio de plataforma (sin cambiar contenido) tuve que dedicar un buen rato a levantar Maquinas Virtuales(*) a fin de comprobar que el site seguia operativo en plataformas "antiguas".

En circunstancias como esta ¿Que queda por hacer?, todo depende, lo mas seguro es avisar con unos cuantos meses de anticipación (seguramente mas de los que ha dado Google) de que llegada cierta fecha no se dara soporte a ciertos browsers, o de ser el caso esperar la siguiente renovación de contrato para introducir dicha condicion.

El punto es, que si bien lograr el cambio es difícil, las empresas que se encuentran en una situación como la descrita pueden ser los mejores agentes para lograr el abandono de IE6, mas aun que Google, ya que si una organización sigue usando internamente un browser obsoleto, el que venga una orden "de arriba" indicando que hay que hacer el cambio sera mucho mas efectivo que un empleado normalito quejándose que no le funciona el Gmail. Aunque claro, esto traera el efecto colateral (positivo) de que esta empresa cliente también deba actualizar sus webs.

Actualizacion 21-2-2010 Gracias a Slashdot he encontrado este interesante articulo donde se investigan las razones por las que las empresas aun siguen sin actualizar sus browsers, es que ... ¡simplemente no actualizan nada! (ademas de otras interesantes razones que invito a leer).

(*) Esto porque IE ha mantenido la política de no permitir mas de una versión en un mismo equipo, y que por ejemplo no puedes instalar IE4 en XP, o IE6 en Vista.

En realidad es un tema que ya habia estado dando vueltas desde hace rato, y volvió a tomar relevancia cuando Microsoft empezo a pedir a sus usuarios que actualicen a Internet Explorer 6.

La verdad es que la posicion de Microsoft es algo complicada, ellos estan obligados por su propio contrato a dar soporte a los elementos con los que vino instalado Windows XP (alla por el 2001), siendo que Internet Explorer es parte de esa instalación, es mas ya sea que uno instale XP SP3, o aplique SP3 sobre una instalación ya existente, el browser instalado (a menos que uno lo cambie manualmente) es Internet Explorer 6.

Bueno, Microsoft ha hecho algunas cosas sutiles para ir conduciendo a los usuarios a que vayan actualizando su browser, asi, si bien los contenidos generados por un servidor MOSS pueden ser vistos en IE 6, para poder administrar el servidor se necesita IE 7 o superior, no es mucho pero algo es algo.

Y la verdad es que esa migración no se producirá a menos que los usuarios estén convencidos de ello o no les quede mas remedio so pena de no poder seguir trabajando o realizar cosas que les sean de veras importantes, por lo que la idea de que los blogs tengan un plugin que malogre la experiencia de navegación en IE6 a efectos prácticos no paso de una anécdota.

Pero la cosa cambia cuando Google anuncia que dejara dar soporte para IE6 (osea que practicamente dejaran de funcionar) en aplicaciones como Google Docs primero y Gmail luego, movimiento sin lugar a dudas de veras desequilibrante teniendo en cuenta la popularidad de la plataforma de correo de Google.

Asi pues, dada la ubicuidad de Google, se podria decir que el fin de Internet Explorer 6 en los escritorios esta cerca ¿ o no?, para estar seguros debemos analizar dos de los huesos mas duros de roer en cuanto a la actualizacion tecnologica:

Cabinas, Locutorios y Cibercafes Como comentaba hace unos meses estos negocios solo se mueven bajo la premisa de que las maquinas estén funcionando, instalan siempre un mismo patrón de aplicaciones, nunca corren el Windows Update, si entra virus, pues nada... a formatear y a seguir adelante, y claro si un usuario se quejo porque algun blog colgo el browser, dicha queja se solucionaba con un "cambiate de maquina", solucion que ahora ya no podra ser efectiva cuando el usuario no pueda entrar a ver su Gmail, asi que quieras que no el cabinero deberá establecer una nueva plataforma base para sus equipos so pena de que los usuarios se alejen de su local, y como el dinero manda, creo que en ese sector si veremos el cambio.

Empresas Lo mas complicado, una empresa de mediana tirando a grande tiene totalmente restringido lo que el usuario puede hacer (supongamos que le deja salir a Internet), siendo que en un temor de que nada "extraño" entre demoran infinitamente el despliegue de los Service Packs, no ejecutan el Windows Update, aun cuando el parche a desplegar sea muy critico, y por supuesto... solo usan un browser: Internet Explorer 6. Ya centrándonos en el browser, las razones son diversas: tener equipos homogéneos para que sea mas sencillo dar soporte (plan que se va al carajo cuando los gerentes empiezan a estrenar modernisimas laptops con Vista entonces y con Windows 7 ahora), y la mas común y mas valida, garantizar la ejecución de aplicaciones diseñadas cuando IE6 era standard de facto, ya que a menos que se este planeando hacer una migración del parque de aplicaciones Web, la organización debe velar para que lo que funcionaba entonces siga funcionando ahora, y créanme, muchas aplicaciones complejas pueden simplemente empezar a fallar si no se las usa en el browser correcto, y el tiempo de parchado ... cuesta. Así que en ese sentido no creo que un administrador de red este por la labor de ayudar cuando una secretaria se queje de que su Gmail ha dejado de funcionar.

Así pues, la amenaza de Google significara un avance, pero creo que el mayor avance se dará cuando las empresas terminen de evaluar a Windows 7 y decidan hacer un despliegue general, circunstancia en la que los parchados (o migración integral) de las Aplicaciones Web existentes tendrán que hacerse si o si, o si no educar a los usuarios en el modo de Compatibilidad de Explorer 8.

Ya sea por una razón u otra, a ver si terminamos de sacar a IE6 de nuestros equipos, las versiones anteriores de IE y Netscape entraban y salían de nuestros equipos muy rápido, en cambio IE6... esta siendo mas persistente que lo esperado.

CNET: Microsoft actively urges IE 6 users to upgrade

Todo empezó esta mañana cuando veo un twit de seniormanager donde decia: Se debate mucho sobre nativos e inmigrantes digitales. Cuando habría que centrarse en los "vírgenes" digitales que son la mayoría, y claro inevitablemente me puse a pensar en mi propio padre, el cual por su trabajo, para todo el día con el celular, pero no se sienta frente a una computadora pues "la maquina no me domina, yo la domino" y así, siendo que la mayoria de sus colaboradores si que se conectan a Internet y todo eso, pero el no, a pesar de que fue él quien me compro (y con quien fui a comprar) mi primera computadora (286, 25Mhz, 1MB) hace 18 años.

Pues si, la reflexión planteada por seniormanager no deja de tener sentido, al margen de que hay adolescentes con los dedos sobreentrenados para mandarse mensajes, así como ejecutivos que les ha costado pelearse con el Outlook y navegar por Internet, el caso es que una vez dado el primer paso, la interacción con los recursos disponibles en estos tiempos cae por su propio peso, y de acuerdo a como te mueve tu propia curiosidad, recuerdo que fue un usuario (cuando trabajaba en un CPI alla por 1997) quien me explico como funcionaban los newsgroups, y este usuario era un respetable medico de 60 y pocos al cual no le llamarías nativo digital, pero si que lo era, era mucho mas curioso para ver lo que había que nosotros mismos, supuestos tecnologos.

Establecido esto, queda efectivamente ver lo que se debe de hacer con los "virgenes digitales", dejando de lado temporalmente a quienes no lo pueden por razones economicas(*), toca enfocarnos en quienes el temor ante lo desconocido surge como principal barrera para acceder ya sea a una computadora, navegar por internet o un smartphone.

El problema fundamental es como los paradigmas de interfaz de usuario no han sido "naturales" desde sus inicios, recordemos las pantallas verdes, el DOS, o los primeros SO con interfaz gráfica como Mac OS o Windows, que si... ¡que el raton tampoco es un paradigma natural! ayuda, pero no es natural como indican las referencias de los profesores de informáticas para mayores, quienes cuentan que algunos elevaban el ratón a la altura del monitor, pues era lo que aprecia mas lógico.

¿Y las aplicaciones? pues mucho juegan en ese sentido como podemos verlo en el grafico (que vi gracias a ALT1040) al costado, lamentablemente como desarrolladores a veces hemos pecado en seguir demasiado fielmente el paradigma del textbox, combo y lista, sin pensar si corresponde o no a la necesidad del publico que queríamos que use nuestra aplicación, pero al final creo que se esta viendo la luz al final del tunel, hay un buen numero de aplicaciones que se están desarrollando con nuevos paradigmas de interfaz de usuario (como pude verlo en el Remix) así como con las tecnologías que facilitan dicho desarrollo: Silverlight, iPhone, WPF....

Así que ahí va la respuesta a la pregunta inicial, simplemente desarrollar mas y mas productos y/o aplicaciones con interfaces de usuario mas naturales y de facil acceso, ofrecerles dispositivos mas amigables que la tradicional computadora o laptop, de hecho, la primera idea que se me ocurrió es que mi padre debería tener un smartphone con conexión a Internet como punto de partida, ya que seria como una evolución de algo que si que usa.

Hace tiempo Bill Gates hablaba de "information at your fingertips", personalmente creo que recien con los nuevos terminales pequeños se esta logrando esa idea, asi pues.. ¿que mas simple para alguien que ya sabe usar un movil que ver el listado de las noticias del dia en su telefono? La facilidad para disponer de la informacion, rompe la primera barrera de temor del usuario.

Nuestro reto es entender como cambian los modelos de UI y pensar en las mejores formas para valernos de las nuevas tecnologías para brindar soluciones que la gente se sienta cómoda al usar.

(*)Para este sector cobra mucho sentido iniciativas como la Wikipedia offline.

Si, ya se que es el trend del momento, y que he escrito alguna que otra cosita a proposito de Apple, pero bueno, dentro de todo el aluvion de criticas y sorpresas, prefiero separar la paja del trigo.


Muchas de las quejas relativas a sus dimensiones, marco negro, conectividad, espacio de almacenamiento, luminosidad, etc etc, a efectos prácticos son irrelevantes (o en todo caso mejorables en una nueva versión) para el exito del producto, como lo fue la carencia de radio FM durante varios años, no, Apple no esta orientado a los criticos tecnologos, sino al usuario final que busca una mejor experiencia con el gadget de turno, y es por ahí por donde quiero empezar.

- Flash, se indica que el iPad no tendrá soporte para Flash (lo que no le ha gustado mucho a los de Adobe), como tampoco lo han tenido los iPhone, circunstancia que si bien es solo un inconveniente menor, en el iPad ya podría ser muy critica y decepcionante ¿Por que? Simple, al final quien navega desde un smartphone por lo general lo hace hacia versiones de Webs que ya están preparadas para navegación en estos dispositivos, lo cual incluye otras dimensiones y generalmente no incluir a Flash; ahora bien las dimensiones del iPad en teoría deberían permitir una navegación cómoda por Webs "normales", pero oh sorpresa.... al entrar a estas paginas uno "disfrutaras" de una funcionalidad o estética limitada. Igual la apuesta de Apple va por el HTML5, y les funciona, pero de momento ya le estas capando la web a los usuarios.

- App Store, el éxito que ha tenido el modelo seguido en el iPhone ha hecho que Apple haya decidido no usar su OSX, sino una variante del sistema operativo del iPhone, lo cual entre otras cosas mantiene el modelo cerrado para el uso de aplicaciones de terceros: solo puedes correr aplicaciones aprobadas por Apple (disponibles desde su App Store) lo cual reduce muchísimo la potencialidad de uso del dispositivo, ya que de esta manera una empresa que cree que podría crear una aplicación de uso interno con el iPod, estaría obligada a registrarla y validarla ante Apple, vamos, ni los mayores Microsoft-haters podran decir que lo mismo de Windows.

Asi que, si bien no creo que sea un fracaso ni mucho menos, es muy probable que la iPad no gozara de un arranque de expectativas de compra como el que tuvo la iPod en su momento.

Apple iPad: Cue the haters

ALT1040: Por que no comprare un iPad (muy recomendable)