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

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)

Y ahora verificando la performance (II)

Ok, esta vez si me he demorado en la segunda parte de esta serie sobre como agregar pruebas de performance a nuestros procesos de despliegue, en nuestro articulo anterior vimos como agregar configurar una prueba de carga sencilla, básicamente registrábamos una URL, el volumen de la prueba y listo… ya podíamos hacer una prueba preliminar que nos podría ser muy útil en algunos casos (como cuando todos los parámetros de una búsqueda están en el QueryString, por ejemplo), pero si queremos mayor granularidad en los parámetros de la prueba la alternativa es usar los Web Performance and Load Test Project que han ido evolucionando y que mediante el uso de Azure nos permiten desde Visual Studio tener unos resultados de prueba muy configurables, así:

Clipboard26

Y eso esta genial, pues nos permite (mediante nuestra cuenta de VSTS) provisionar recursos Azure que hagan la respectiva prueba mientras sea necesario, y que podamos ver dichos resultados desde nuestro Visual Studio, pero… ¿que tal si queremos que esta validación de carga decida si un despliegue ha ido bien o no? Pues eso es lo que trataremos de conseguir en este post.

En concreto lo que haremos sera agregar un proyecto de carga a nuestra solución, incluirla en el repositorio y de esta manera valernos de sus archivos para incluir un nuevo tipo de tarea durante nuestro proceso de despliegue, asumiremos que estamos trabajando con una solución Web que ya tiene configurado su repositorio asi como sus procesos de Build y Despliegue como hemos visto en anteriores artículos, ¿ok? Finish Reading: Y ahora verificando la performance (II)

Y ahora verificando la performance (I)

Varias cosas han pasado desde que empezamos a probar en nuevo modelo de Builds en VSTS, primero creamos una build sencilla que desplegaba a una Azure Web App, luego probamos como usar los Resource Groups para desplegar entornos, luego retiramos el paso de despliegue de la Build para trasladarlo a Release Management luego de su integración con VSTS, y hace poco agregamos Sonar como parte del proceso de análisis de nuestro código dentro de la compilación.

Y como el ciclo de evolución del proceso DevOps nunca para, en esta ocasión veremos como hacer algo a lo que le he tenido bastante respeto desde la época de las builds con el modelo XAML, en este caso la evaluación de la performance y estabilidad de nuestras aplicaciones web desplegadas.

En corto, la posibilidad de probar nuestras aplicaciones Web precede aun a .Net, recuerdo cuando probé Web Application Stress Tool (Homer) para hacer unas pruebas sencillas sobre ASP Clásico, de ahí le perdí el rastro pero la cosa se puso interesante desde Visual Studio 2013 se permite que los tests de carga se basen en las capacidades de la nube, lo cual significa que durante nuestras pruebas se provisionaran las maquinas virtuales que hagan falta para cubrir la cantidad usuarios y peticiones deseadas, esto ya lo había probado desde Visual Studio (revisar aquí y aquí), con buen resultado, pero… ¿como hacer que estas pruebas se ejecuten cuando se produzca cierto tipo de despliegue?

Antes de proseguir hay algunas consideraciones a tener en cuenta:

Los recursos que Azure provisiona para efectuar estas pruebas tienen un costo (si se va por encima de los minutos de carga incluidos con nuestra suscripción de VSTS) por lo que hay que tener cuidado de no lanzar estas pruebas por cada commit que los desarrolladores efectúen, así que la sugerencia general seria tener un sitio de DEV donde se despliegue continuamente pero sin efectuar las pruebas de cargar, luego definiríamos un sitio QA (por ejemplo) al cual se desplegara ya sea de manera manual o de manera programada el contenido existente en DEV (con Release Management lo que se despliega son paquetes que no necesariamente son recién compilados) y al efectuar ese despliegue se lanzaran las pruebas de carga, las cuales si son exitosas indicar que en el proceso de despliegue esta listo para ser sometido a aprobación (si lo hemos definido así) para decidir su pase a otro entorno.

Con estas consideraciones en mente procederemos con nuestra primera prueba para lo cual no sera necesario usar Visual Studio simplemente agregar un paso adicional a nuestro proceso de despliegue, esto es porque a veces lo que nos interesa es simplemente ver que tan bien resiste una URL en concreto a cierta petición.

Para esto vamos a la pestaña de Release de nuestra instalación de VSTS, elegimos nuestro plan actual, seleccionamos el “entorno lógico” sobre el cual agregaremos nuestra prueba de carga y agregamos el Step de Cloud-based Web Performance Test, así:

Clipboard01

Clipboard02

Ok, ahora toca parametrizar el paso para lo cual dejaremos los parámetros mas o menos así, en breve explicare el significado de cada parámetro:

Clipboard06

Antes de proseguir prestemos atención al parámetro Registered connection, lo que ocurre es que cada prueba de carga se hace con cargo a los recursos y facturación de una cuenta de VSTS y podría darse el caso de que la organización tenga mas de una instancia de VSTS, así que corresponde indicar explícitamente dicha cuenta, así que hagamos clic sobre el enlace que dice Manage, que nos abrirá una nueva pestaña en el navegador para agregar un Endpoint (como ya hicimos anteriormente para enlazar Sonar y la cuenta de Azure), y en este caso elegiremos Generic, así:

Clipboard04Y llenamos los parametros de configuración de nuestra instancia de VSTS, pero ojo, al hacerlo deberemos utilizar los datos de nuestra conexión alterna a VSTS, algo de lo que hablamos hace tiempo cuando empezamos a trastear con Git.

Clipboard05

Listo, ya hemos enlazado nuestra prueba de carga a nuestra cuenta de VSTS,  personalmente yo agregaria un checkbox que permita usar la instancia actual y no hacer nada mas, pero siempre es bueno tener una conexión alterna a VSTS especialmente de cara a la integración con herramientas de terceros en Git.

Ok, antes de grabar repasemos los parámetros que estamos configurando:

  • Registered connection: como lo vimos, la instancia de VSTS sobre la cual se hara la facturación de esta prueba de carga.
  • Website Url: La dirección que vamos a probar, en este caso estoy probando la raiz del site (o mejor dicho del slot) en que acabo de hacer el despliegue, cabe indicar que tranquilamente podria haber colocado cualquier URL interna de nuestro site, o peor aun, una URL totalmente externa no manejada por nosotros, pero eso no queremos ¿verdad?
  • Test Name: El nombre con el que identificaremos a esta prueba.
  • User Load: La cantidad de usuarios supuestos que se estarán conectando a nuestra URL.
  • Run Duration (sec): El tiempo de duración de la prueba.
  • Load Location: La zona geográfica de Azure desde donde se hará la prueba, es muy interesante y conveniente hacer la prueba desde una zona que no sea la que aloja a nuestro site, en mi caso la URL esta alojada en East-2, así que la prueba la estoy lanzando desde West.

Marcamos Enabled y grabamos, ya estamos listos para empezar, asi que lo mas sencillo sera hacer un cambio en nuestro codigo fuente, lanzar una nueva Build manualmente, o si queremos divertirnos relanzar un paquete antiguo al ciclo de Release, en todo caso esperamos un poco y veamos cuando nuestra Release se empieza a ejecutar y llega al paso que hemos agregado:

Clipboard08

Para después terminar:

Clipboard09Normalmente pasaríamos a aprobar o rechazar esta Release, pero ahora me interesa conocer los resultados de nuestra prueba, así que vamos a la pestaña Tests, y elegimos la opción LoadTest, para luego seleccionar la prueba mas reciente (en mi caso tengo algunas pruebas anteriores, pero si es la primera vez deberías tener una sola prueba en tu lista).

Clipboard10

Y así entramos a un detalle de los resultados de la prueba:

Clipboard11

Notemos algo interesante, aparentemente nuestra prueba salio ok (o sea, no hubo errores 500 o timeouts) pero el panel nos indica 2 errores, así que veamos el detalle:

Clipboard12

En mi caso el mensaje de error dice “The value 85.10138 exceeds the warning threshold value of 75“, lo cual nos viene a indicar no un error en el sitio que estamos probando sino un exceso en la capacidad de la instancia provisionada para hacer la prueba, esto apunta a que forzamos la maquina dandole 250 usuarios concurrentes, lo cual se relaciona a las pocas opciones de configuración que ofrece este tipo de prueba.

Listo, sencillo y ya podemos empezar a sacar conclusiones, pero como verán esta prueba es muy sencilla y en adición al ya mencionado problema del threshold no permite saber si por ejemplo el comportamiento es diferente desde un browser u otro, desde un tipo de red, etc, para lograr este tipo de análisis lo que se nos ofrece es la posibilidad de crear un test muy detallado desde dentro de Visual Studio y que cuando se efectúe el despliegue Visual Studio Team Services pueda “leer” todos estos parámetros archivados y ejecutar tras bastidores las pruebas programadas, esto sera tema de nuestro próximo post, de momento sugiero familiarizarse con este tipo de prueba, pues los conceptos siguen siendo validos cuando los escalemos, aparte de que estas pruebas tienen su lugar si  hacemos peticiones Get que luego repercuten a nuestra BD, o queremos probar la mejora si usamos un servicio de cache, etc.

Espero sus comentarios 😉

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Pues si, como fue prometido, ya va tocando meternos con el modelo de Builds, pero antes de proseguir respondamos la pregunta que deje en el post anterior, ¿en que parte de la solución estoy grabando los parámetros de conexión a la BD? pues en el archivo PartsUnlimitedWebsite.pubxml ya que es ahí donde el wizard de deploy guardo los datos de la cadena de conexión a pesar de que al final no sobrescribió los valores del web.config, nos corresponde editar las secciones de dicho archivo a fin de que no persistan los valores dentro de nuestra solución.

Curiosamente, debemos agregar este archivo a nuestra solución, para lo cual hacemos clic derecho y ya formara parte de lo gestionado por VSO, ojo esto solo funciona si hemos editado adecuadamente nuestro archivo .gitignore como ya hemos explicado en el segundo post de esta serie.

Clipboard27
Bueno, ahora si, subamos el cambio y volvamos a nuestro Team Project en Visual Studio Online, dirigiéndonos a la zona de BUILD, de momento estará vacía.Clipboard28
Posicionados sobre la zona que dice “Build definitions” (nótese que aparte tenemos una zona correspondiente a las XAML definitions) y presionamos el “+”, nos saldrá la siguiente pantalla:Clipboard29
Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

Bueno, luego de una pausa, proseguimos con esta serie de artículos para establecer un escenario completo de despliegue usando el nuevo modelo de Builds que traen tanto Visual Studio Online como Team Foundation Server 2015, ¡así que manos a la obra!

Para proseguir con el demo de Parts Unlimited, debemos mencionar que en este ejemplo se hace uso intensivo de los Resource Groups que ya conversamos anteriormente, esto permite automatizar la creación del entorno donde se desplegara nuestra aplicación, vale decir que reduciremos nuestras visitas al Portal de Azure para la creación de nuestros recursos.

Para facilitar esto debemos preparar a nuestra maquina para que sea capaz de provisionar directamente en Azure, para lo cual abrimos una ventana de PowerShell (con permisos de Administrador, claro esta) y escribimos Set-ExecutionPolicy RemoteSigned.

5554.image_thumb_6CC60E94

Bien, terminaron los preparativos así que ya con la aplicación cargada en Visual Studio (y bien conectada a VSO) vamos al proyecto PartsUnlimitedEnv, hacemos clic derecho y elegimos New Deployment… Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

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

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

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

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

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

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

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

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

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

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

Si a mi ya me es dificil: … el PADRE de la AEAT

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

¿Se requiere soporte para Internet Explorer 6/7 ahora?

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.

¿Funcionara la amenaza de Google para reducir a Internet Explorer 6?

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

¿Cómo convencer a un cabinero de actualizar sus browsers?

Este problema me ha pasado en las dos últimas veces que he estado en Perú, en adición a la usual lentitud de las maquinas de las cabinas de acceso a Internet (curiosamente la velocidad de acceso ha ido mejorando de manera muy aceptable) uno se topa con que se usa software obsoleto o muy lento (o que reduce la velocidad de un equipo de por si poco potente).

Como habrán podido deducir, el problema usual con el que me enfrento es el hecho de que al llegar a una cabina no encuentro ya no siquiera Firefox, sino tampoco a Internet Explorer 7 (de la 8 mejor ni hablemos), pero si por el contrario muy orondos programas que te hacen creer que estas en Windows Vista cuando en realidad estas en XP. Y bueno.. uno dirá ¿Qué más da? Pues mucho….. uno se acostumbra a trabajar con pestañas, lo cual es imperativo si estas con límite de tiempo, pero al solo haber IE6 no queda más remedio que dejar que se acumule una pila de ventanas en la barra de tareas… penoso.

Claro, a un administrador de una cabina o locutorio poco le interesa el tema, solo le interesa que todas sus maquinas estén operativas, y si a alguna le entra virus (como suele pasar) pues a formatear se ha dicho, y si se tiene suerte (algunos son precavidos debo reconocerlo) a restaurar desde una imagen para reducir al mínimo el downtime, asi que eso de actualizar a IE7 o IE8 queda fuera de los planes y peor…. Instalar Firefox, eso es lo que me llevo en la reciente presentación de Firefox 3.5 a preguntar sobre como lograr que los dueños de estos establecimientos instalaran Firefox en sus negocios (claro, no iba a decir como lograr que actualizen a IE8 😉 ) .

Al final todo depende de lo que te reclamen tus clientes, en ese sentido es que me parece una buena idea lo que leí hoy en ALT1040 acerca de un plugin para WordPress, el cual permite que si alguien visita una página (hecha en WordPress) que incorpora ese plugin, usando IE6 le ocurra alguna de estas cosas (dependiendo de cómo se configure el plugin):

  1. Una barra superior avisando al visitante que está usando un navegador caduco y que debería actualizar a algo “mejorcito”.
  2. El mismo aviso, pero a pantalla completa, tapando todo el contenido y avisándole que a menos que actualice no podrá ver el contenido.
  3. La medida extrema: hacer que el navegador falle, crasheandolo, congelándolo, como usted quiera llamarlo.

¿Ven la idea?, si hay un número suficiente de blogs que decidan incorporar ese plugin, tarde o temprano habrá usuarios cabineros quejándose del “problema” antes los dueños, por lo que eventualmente estos accederán a instalar un browser mas actualizado. Si tan solo esto también fuera posible en blogspot… seguro que yo lo instalaría en mis blogs.

Así las cosas …. a veces pienso que son los dueños de cabinas los únicos que se han tomado en serio la “campaña” Save IE6, a pesar de que ya se lleva buen tiempo pidiendo la actualización a los usuarios.