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 😉

La eterna búsqueda de lo que agrega valor a los proyectos

Hay lecciones que uno las recuerda como si hubieran sido ayer, y esta si bien ocurrió hace como 18 años, la tengo siempre en mente cuando surge algo nuevo, pero… empecemos desde el principio.

Era una clase de Lenguajes de Programación 1, la dicto el profesor Alejandro Muñoz (un Ing. Civil con bastante pasión por los temas de informática) y el tema que tocaba era C++, para ese entonces ya habíamos aprendido Pascal (algunos laboratorios habían sido bien largos), Fundamentos de Programación y algunas cosas muy interesantes en Algoritmos y Estructura de Datos, pues bien, la primera sesión no se trato de explicarnos que incorporaba C++ sobre su antecesor C (el cual habíamos visto en la primera parte del curso), sino para plantearnos como surge la Programación Orientada a Objetos, como una respuesta a la Creciente Complejidad del Software, el cómo los programas tenían cada vez mas y mas líneas de código, por lo cual la Programación Estructurada ya había tocado su techo, siendo la OOP la respuesta al ser una nueva forma de ordenar los proyectos, así como para enfocar el código hacia entidades mas cercanas al mundo real.

Y claro, aun faltaban pocos años para que el boom de Internet nos cogiera por sorpresa, pero ahí nos quedamos con esa idea, la OOP como respuesta a todo, pero por otro lado vemos la aparición de Visual Basic y su enfoque RAD, en el cual (¡oh herejía) la OOP brillaba por su ausencia, pero aun asi permitió el desarrollo rápido de soluciones que si las hacias en C++ hubiera sido recontra complejo, claro que luego a alguien se le ocurrió una buena idea: mezclar el RAD de Visual Basic con el orden de la OOP y surgió Delphi, y asi hemos visto una sucesión de nuevas respuestas (nuevos retos, recuerden), como comente hace un tiempo , pero quien lo expone mejor es Esteban:
La primera aplicación que hice en mi vida profesional, fue una típica intranet para una empresa. Todo el código y acceso a la base de datos, se ejecutaba en archivos ASP.
Luego me dijeron que está mal acceder directamente a las tablas de la base de datos desde el código, por lo tanto implemente store procedures para cada uno de los accesos a la base.
Luego me dijeron que está mal mezclar lógica de negocio y de presentación en el mismo archivo…..
…..pasé de tener un simple archivo ASP (o ASPX, o JSP) a tener que crear un archivo HTML, una clase model, una clase controller, una clase repository de acceso a datos con su respectiva interface, una clase service que maneje la lógica de negocio con su respectiva interface, una clase para test unitarios, otra clase para test de integración, aprender a utilizar (como mínimo y básico) un framework MVC, ORM, de Unit Testing, Mocking, de inyección de Dependencias y de autenticación.
Todo para mejorar la productividad y velocidad en el desarrollo de aplicaciones. Todo para que el “desarrollador no pierda tiempo en programar aspectos secundarios de la aplicación y se concentre en lo mas importante, que es la lógica de negocio.”.
No se ustedes, pero a mi este ciclo de evolución del desarrollo de software me parece que esta muy alejado de la palabra “productividad”.

Efectivamente, esos han sido los vaivenes y trends por los que hemos pasado los desarrolladores en los últimos 15 años, es que efectivamente una vez que nos terminaron de convencer acerca de la OOP, eso no fue suficiente, tocaba programar basado “en componentes” y de ahí todo lo que cuenta Estaban en su post.

Y si, si bien esa historia puede ser descorazonadora para quienes producimos software debemos recordar algo:
• Siempre se nos pedirá mas y mas funcionalidades, y mas funcionalidades significan mas líneas de código, osea mayor complejidad.
• El entorno donde correrá tu aplicación cambiara, no tiene sentido pensar en tu web como la antigua aplicación de facturas hecha en Fox, porque ahí entran diversos factores que por mas que la funcionalidad sea “similar” a lo que ya había, cambian totalmente la forma en que la tendrás que desplegar y por ende estructurar el proyecto, baste mencionar el tema de seguridad y todas las consideraciones de zona militarizada que eso conlleva.
• Es impredecible saber con que interactuaran nuestras aplicaciones en el futuro, pero está claro que aun a la clásica aplicación de facturación se le puede pedir integración con Google Maps para que te ayude a ubicar la dirección del cliente.
• No puedes estar seguro de cuánto tiempo vivirá tu aplicación, pero alguien tendrá que mantenerla, por lo que hay que tener consideración con el que le toque hacerlo.

Llegados a este punto debemos reconocer algo, muchas de estas modas, surgieron para afrontar los retos que iban surgiendo progresivamente ante problemas que antes no había, o que terminaron volviéndose mas repetitivos terminandose al final conceptos ya asumidos “por defecto”: OOP, Web, BD relacionales, SOA, etc; ahora bien, eso no quita que hubo muchas soluciones para necesidades inventadas, por lo que pasaron sin pena ni gloria (¿alguien recuerda los “behaviours” en IExplorer 5?).

Ahora bien, el problema que debemos afrontar es saber cuándo seguir o no una tendencia (ya me paso a mí con LINQ 2 SQL, pero pese a ello era claro que los ORM habían venido para quedarse) y sobre todo si esta aporta real valor a nuestra solución, ya exprese mis dudas respecto a los nuevos patrones de diseño, pero de nuevo Esteban nos ofrece su visión de porque algunas cosas se terminan imponiendo (sin necesidad): Assumptions Driven Development. Es que es así, implementamos por inercia cierta arquitectura (de moda) sin tener en cuenta cual es el escenario real para la cual esta tiene sentido, o porque esperamos que cierta condición se cumplirá en el futuro y para ello “hay que estar preparados”, y como bien se apunta en el articulo esas condiciones nunca terminan de cumplirse pero en el camino ya hemos agregado complejidad innecesaria a nuestro proyecto.

No es sencillo, la verdad, pero como dije al final algunas cosas vinieron para quedarse: OOP, aplicaciones distribuidas, nuevas interfaces de usuario mas ricas, interconectividad, y ante ello no queda sino tener la suficiente cabeza fría de saber si la novedad que estamos queriendo implementar en nuestro proyecto agrega valor o no al producto a ser entregado, si los retrasos y complejidad añadidos son superados por las ventajas futuras (a veces puede que no ), la cosa es no temer a la respuesta de un análisis hecho a conciencia.

Por ejemplo, estoy convencido que ciertas capas de las aplicaciones pueden beneficiarse muchísimo del uso de pruebas unitarias, componentes algorítmicos puros, formulas matemáticas, financieras, su determinismo es tan alto que una prueba unitaria de veras se luciría para probar el código, pero de ahí a querer una cobertura del 100% o plantearse el TDD como panacea para mejorar la calidad de los programas… me lo tomo con pinzas, a riesgo de que me llaman hereje indicando que he “missed the point”.

Ojo, nótese que prudencia no es pasividad ni conformismo, pues de lo contrario estaríamos como las empresas que siguen usando mainframes.

Si, es complicado, pero es mejor tener las cosas claras y no renunciar al análisis para saber separar la paja del trigo.

Rediseñando… estropeando Peru.21

Pues si, como ya ciertos cartelitos lo indicaban Peru.21 cambia de diseño y adquiere nueva URL, como podemos ver en esta captura a pantalla completa:

La verdad es que no me termina de gustar, el primer pantallazo da menos informacion que la version anterior, parte de ello derivado por las las letras gigantes, antes no era necesario hacer tanto scroll para enterarte de los titulares, no les parece que hay mucho espacio negro desperdiciado?.

Siendo expatriado y no estando en contacto directo con los medios audiovisuales, las webs de los diarios son los mecanismos mas directos para tomar contacto con lo que esta pasando en el pais, y una de las razones por las que me gustaba el anterior diseño era justamente la capacidad de tener todo a la mano en un vistazo, siendo justamente esta web la que recomendaba a los demas compatriotas expatriados que estan mas ocupados y requerian un mecanismo agil para enterarse de las noticias en la patria distante. Hemos perdido esa ventaja.

Siguiendo el patron de sus “papis” de El Comercio, parece que ahora habra mas dependencia del Flash, algo que no tenia la web anterior.. otro punto en contra.

Se aprecia tambien que las secciones de los columnistas no estan tan a la mano, me imagino que eso se solucionara pronto, y pueda seguir gozando de mi placer culpable de leer las opiniones progresistas y con conciencia social de sus economistas.

Tan dificil es pensar en la usabilidad? A ver si hacen caso a los 10 mandamientos del diseñador grafico.

Actualizacion: Como era de esperarse, si en algun sitio se habia hecho referencia a alguna URL de la web, es casi seguro que ya no funcione… por lo visto el mantener las URLs como algo permanente es asignatura dejada de lado cuando hay migraciones de entornos, entorno? si…. gracias a Ocram nos enteramos que no solo han migrado de diseño sino de software de plataforma, curiosamente estos defensores del software libre no valoran la libertad de opinion pues la nota donde cubren ese aspecto tecnico tiene los comentarios deshabilitados…

Por lo que puedo ver, la migracion incluye dejar el segmento de red de Telefonica del Peru para pasar a uno de El Comercio, interesante.

El Morsa: Perú21 es ahora Peru21.pe

Ocram: Blogs en Perú.21

Esto de diseñar para Aplicaciones Web….

La reciente nota de ALT1040 sobre el lanzamiento de Adobe GoLive 9 y los problemas que acarrea como consecuencia del mal codigo HTML generado me trajo de golpe a la memoria los muchos dolores de cabeza asociados con la creación de Aplicaciones Web con las que he tenido que lidiar.

Si bien en mi primer trabajo era multifuncional: un dia programaba en C y el otro dia retocaba una imagen (no se rian! así corrían los tiempos hace 10 años!), ese modelo no me duro mucho y tuve que centrarme eventualmente en la programación web y en como los websites generaran contenido dinámico, la parte del diseño gráfico correría a cargo de otros…. y ahí empiezan los líos.

Como dice la nota :“….nunca entendieron como se diseña para el web y lo hacen al revés: primero cómo se ve y después cómo funciona cuando debería ser al revés: cómo funciona y después cómo se ve.”, completamente de acuerdo… mi idea siempre ha sido establecer el modelo de arquitectura y generación del contenido dinámico, produciendo un HTML mas o menos estructurado y simple que después podría ser “adornado” con los estilos y gráficos que fueran convenientes.

Pero no… parte de los problemas que tuve en un trabajo fue debido a la forma en que trabajaba el departamento de Diseño Web (estático) a la hora de plantearse algo, primero dibujaban con Corel (o lo que usaran en sus Macs) la idea de las paginas y una vez refinado se procedía a una etapa llamada de “corte” donde agarrando el gráfico y una herramienta se procedia a trocear y a dividir en secciones dicho gráfico y con eso generar un HTML que seria el que al final se publicaría, este esquema podía ser muy practico para los clientes que solo querían su Web “para estar en Internet”, el problema se da cuando nuestro equipo de Desarrollo pasa a asumir la creciente demanda de Aplicaciones Web (lo que un vendedor mal llamo “web con base de datos”) por parte de la clientela.

En esa época no había ASP.NET y lo que se usaba era ASP Clasico y PHP, JSPs recien trataban de lograr lo que no habían logrado los Servlets, pero bueno… esta clase de tecnologías requerían un conocimiento mas o menos claro del HTML que se estaba generando, controlar bien los bucles, saber cuando acababa una sección de HTML y empezaba la otra…. nada que dependiera mucho de los estilos y si de tener un HTML ordenado y con los Tags completos.

El lió venia cuando ellos nos daban una plantilla generada con el método arriba comentado, y tratábamos de integrarla con nuestros desarrollos… que lio!!! Tags mal agrupados, estilo inconsistente a la hora de definir los nombres de los objetos, y tags sin cerrar, esto era lo peor pues ya podías pasarte un buen rato tratando de cerrarlo (porque se daba la casualidad de que justo ahi era donde tenias que colocar código dinámico) y darte cuenta que en cada intento todo se descolocaba, eventualmente se lograba el efecto pero a costa de mucho esfuerzo y de insistirles que por favor comentaran las secciones del HTML generado, especialmente las que se sabia que iban a ser regeneradas dinamicamente. Tuve suerte que ya tenia esa practica cuando cambie de trabajo pues en este caso dependíamos de una empresa externa para el diseño y la practica me permitió corregir algunos errores e informar a dicho proveedor que tuvo el buen tino de incorporar el ajuste en su siguiente entrega.

Por el lado opuesto se daba una situación peor, teníamos un portal de ventas que constaba sencillamente de Tablas y un poco de gráficos, les pedí a los de Diseño gráfico que por favor la hicieran presentable: estilos, tipos de letra, iconos; creo que el reto era demasiado para ellos pues un poco mas y me daban una plantilla generada con su método para que nosotros rehiciéramos nuestro trabajo, en lugar de aprovechar lo ya existente…. Osea, este equipo contaba con gente muy calificada que hacia verdaderas maravillas con buen gusto, pero a la hora de pedirles de que integren sus habilidades de una manera mas productiva ya les costaba.

Los desarrolladores de Aplicaciones Web, no tenemos porque ser los creativos de la presentación, pero creo que al menos estamos en la condición de pedir que la gente de Diseño realice una sinergia positiva a la hora de trabajar juntos, pero estos a veces en aras de la creatividad omiten el paso de generar algo que sea fácil de ser integrado, o de mejorar lo ya existente sin necesidad de destruirlo.

Evitando errores al hacer Websites…

Acabo de revisar este enlace de Microsiervos : Cosas que no debes hacer al construir un sitio web, que es la traduccion de: 19 Things NOT To Do When Building a Website, vale la pena revisarlo pues a pesar de que los websites ya llevan tiempo entre nosotros, aun no terminamos de aprender todas las lecciones al respecto.

Alt1040 tiene sus favoritas y las mías son:

  • Si todo tu sitio está hecho en Flash despide al desarrollador de la página y hazla otra vez; si la has hecho tú colócala en el apartado “sitios inútiles que he hecho” de tu portafolio y hazla otra vez. Total no nos importa que nuestro web no aparezca en Google….
  • No pretendas reinventar la navegación de los sitios web. Tienen que ver lo ingenioso que soy, el que es inteligente se quedara!!!
  • El contenido es el rey: si tu página web no tiene suficiente contenido o ningún texto real que no esté en una imagen contrata a un copy y despide a tu webmaster ahora. O sino mejor contratamos a un Search Engine Optimizer para que nos posicione en los rankings y asi evitarnos la carga de escribir contenido relevante y util… para que, verdad?
  • Si la página contiene música asegúrate de que el usuario puede detenerla o apagarla y mejor si no se inicia automáticamente —lo mismo para el vídeo. No vean lo incomodo que es este error muy frecuente aun en paginas de la administración publica.
  • Cuida el tiempo que necesita la página para cargarse. Claro, creemos que todos tienen una conexión DSL con un huevo de megabits, asi que los demás a sufrir, no? Has oído hablar de la previsualizacion de imágenes en lugar de colocar el tamaño final? Es de veras necesario ese applet Java??
  • No utilices técnicas y tecnologías nuevas en tu sitio web simplemente porque puedes o porque son novedosas. Las tecnologías nuevas son chulas, pero utilizalas sólo si realmente mejoran de algún modo la vida a tus lectores / clientes / usuarios. Eso eso…. el Ajax esta bien, no? así que a usarlo… no sabemos para que pero ya encontraremos uso.

En adición a estos errores, también me parece irritante cuando el diseñador tuvo la genial idea de deshabilitar el botón derecho del mouse pues no me deja controlar donde quiero abrir los enlaces.

Pero en todo caso el error mas común que se comete es no visitar su propia pagina para ver la usabilidad real comentada en estos puntos o simplemente que el contenido HTML se este formando bien (en todos los browesers!!!), error que he notado en las paginas de algunos compañeros bloggers, de lo cual es sencillo darse cuenta con solo ver el icono amarillo del Internet Explorer o las herramientas de las que dispone el Firefox, es fácil olvidarnos de comprobar si el bonito añadido que le colocamos a la pagina ha empezado a soltar pop-ups o a generar errores de JavaScript, errores que a veces saltan de manera muy evidente e incomoda debido a la las alertas que puede dar el navegador (llegado a este punto pensaba colocar los enlaces de los bloggers “culpables”, pero baste decir que son dos dedicados a la historieta, mas uno dedicado al análisis político).

Cuando el cliente nos ofrece el camino del crecimiento y … lo rechazamos

Hace 10 años me encontraba trabajando en uno de los CPIs (Centro Proveedor de Internet) surgidos al amparo del lanzamiento que hubo de Unired como un medio para tumbarse al entonces operador principal (tema de otro post) en el Peru. Como todo eso de Internet era nuevo mis labores incluian el ser Webmaster, dar soporte telefonico, ayudar en la supervision de los servidores (sin cuarto frio!!!) y eventualmente apoyar a los vendedores cuando tocaba visitar a algún cliente que requería mayor detalle técnico para convencerle de la compra de nuestros servicios que incluian:

  • Diseño de paginas web
  • Hosting y eventualmente housing
  • Configuracion de FTPs
  • Cuentas dial-up para conexion a Internet
  • Cuentas de correo usando POP3, (¿Webmail? que es eso?)

Recuerdo que en una de esas uno de los vendedores nos pidió a Percy (un compañero PUCP que habia entrado junto conmigo a practicar en ese CPI) y a mi a que le acompañáramos para ver a un potencial cliente, pues se veía bien interesante aunque el no tenia muy claro sus requerimientos. Fuimos al local del cliente ubicado en la Av. Pardo, donde explicando resulto que la situación del cliente era esta: ellos editaban una revista sectorial con muchos datos sobre las actividades (vinculadas a los procesos de negocios del rubro) que se iban a realizar en los siguientes meses, así que este cliente pensaba que la Web seria un mecanismo útil para que sus suscriptores pudieran ver los listados de actividades mediante criterios de búsqueda de acuerdo a sus necesidades, dando de esta manera un valor agregado en el servicio que proveía.

Esto que ahora suena como una tarea simple (consultas sin transacciones) en su momento era novedoso, no existían aun las aplicaciones web, los CGIs se usaban esencialmente como contadores y con suerte para rotar publicidad, pero aun así ese cliente tenia la visión de lo que se podía hacer al generar dinamicamente contenido personalizado, Percy y yo lo vimos entonces como una gran oportunidad asi que con el coordinador del área tratamos de empezar a estimar los recursos a utilizar y las posibles herramientas (Intrabuilder, Cold Fusion y los IDC de Microsoft surgieron como opciones), para toparnos con lo que nos dijo el Gerente: “No, no somos una empresa de desarrollo”, seguidamente nos propuso que trataramos de venderle el hacerle muchas paginas y tratar de volcar su contenido pero de manera estática.

Fuimos donde el cliente (ya muy desmotivados) y como es lógico, al cliente no le interesaba ese parche, ya tenia claro lo que necesitaba (cosa rara) y no iba a aceptar pulpo como animal de compañía.

¿Qué ocurría?, que esta pequeña empresa se sentía muy segura en tanto lo que hacia como proveedor de instalaciones de red, y entonces el nuevo rubro de negocio que era vender conectividad y paginas web, así que creía que no había que mirar mas allá en cuanto a ofrecer valor agregado a sus potenciales clientes. Que paso al final? que la empresa dejo el rubro de Internet, regreso al tema de instalaciones de red y vendió su negocio de CPI (con usuarios y todo) a Terra cuando esta empresa surgió (y de esta manera arrancar ya “grande”).

Siempre tengo esto como un ejemplo de oportunidad perdida para despegar en un mercado que esta emergiendo, ¿se habrán percatado ellos de lo que se le paso por las manos?

Errores de alto vuelo en la web de Air Plus

Un articulo reciente de Eduardo y su posterior discusión, me ha convencido de seguir con esto de los problemas en las paginas Web, problemas que no están restringidos a ninguna tecnología en particular, ya que como le decía a Eduardo no ha sido rara la ocasión en que he visto la entera pila interna de mensajes de error generados en sites JSP o PHP. Sin ir mas lejos, la primera versión de la web del Continental te sacaba todos sus mensajes JSP cada vez que salia un error (cosa muy frecuente entonces)

Como sabran estoy yendo a Perú en Septiembre, así que como contaba entonces realice mi investigación de precios (con los resultados conocidos), lo que no conté entonces fue de este error que aparecio mientras buscaba precios en la web de Air Plus Comet

Lindo, no? Una hermosa query SQL para que todo el mundo intuya como van tus tablas mySQL, y de ahí … hasta la cocina.

Por cierto, los webmasters de El Comercio bien harían en revisar el siguiente articulo: 25+ ASP Tips to Improve Performance and Style, articulo muy especifico a ASP y que me sirvió de gran ayuda antes de la llegada de ASP.NET.

Joder con el puto AJAX de los cojones!!

Como decia un profesor en el IE “mis muertos los cuento frios”, asi que recien ahora puedo contar algo de mi experiencia profesional reciente, que espero que sea de utilidad para el que le interese la gestion del desarrollo de software.

Con todos estos años de practica, algunas cosas se te quedan claras en base a las experiencias pasadas y tratas de aplicarlas en la medida de lo posible, lamentablemente a veces no se esta en la posicion de aplicarlas y este fue el caso.

Como decia, algunas cosas se te quedan claras y con fundamento, en este caso tenia claro que avanzado un proyecto no es conveniente meter una tecnologia nueva salvo que: Estuviera focalizada en un sector con poca interaccion con el resto de la aplicacion, o que estuviera claro que fuera completamente compatible y/o evolutiva de la tecnologia empleandose en ese momento.

Pareceria una politica simple y razonable de seguir, pero quienes estan en informatica sabran que estas dos palabras no estan precisamente a la orden del dia en la gestion de proyectos, aunque debo reconocer que he tenido jefes que sin tenido la habilidad suficiente como para llevar razonablemente el proyecto y los intereses de los stakeholders.

Se trataba de una aplicacion Web para uso interno, donde como consecuencia del alto numero de datos a ingresar eran frecuentes las idas y vueltas al servidor, ocasionando un efecto de parpadeo o “pantallazo” que era incomodo para algunos usuarios. Sin ir al detalle tecnico (conocido para quienes conocen esta tecnologia) sabran que este efecto es consecuencia del modelo que trajo ASP.NET el cual es necesario para brindarnos una facilidad de desarrollo que habiamos perdido cuando se paso de la Programacion Visual (con VB, Delphi o PowerBuilder) a desarrollar para la Web (quien ha programado CGIs, ASP Clasico o PHP3 sabe de lo que hablo).

Lamentablemente las quejas salieron cuando la estructura de la aplicacion estaba completada en un 80%, asi que poco se podia hacer (yo proponia aumentar la capacidad de procesamiento del servidor), hasta que alguien planteo la posibilidad de usar lo que recientemente se ha dado por denominar AJAX (aunque las tecnologias base han estado disponibles desde hace tiempo) para solucionar el problema y claro …. se dio el visto bueno a dicha propuesta.

Como ya he comentado la aplicacion ya habia avanzado bastante pero aun faltaban ajustes finales, por lo que se inicio un desarrollo paralelo, por un lado se trataba de replicar en AJAX la funcionalidad existente, y por otro lado se continuaba el refinamiento en la tecnologia actual hasta llegar a un punto de convergencia para integrar las modificaciones hechas en paralelo (las cuales tenian que apuntarse con sumo cuidado).

Cuando correspondio a que se manipulara mis modulos recien cai en la cruda realidad, trabajar con AJAX (al menos en la version que se utilizo) involucraba un paso atras en lo que habiamos ganado en funcionalidad de desarrollo con ASP.NET (si quieres la explicacion marciana ve al final del articulo) siendo mucho mas complicado depurar la aplicacion obligandote a mantener un doble juego de variables y de logica de la pantalla, ya que como la tecnologia se inyecto estando la aplicacion avanzada no hubo alternativa, siendo otra la situacion si se hubiera tenido un desarrollo en AJAX puro desde el principio o con modelo ASP.NET como lo teniamos.

La desesperacion para tratar de ajustar y que vuelvan a funcionar cosas que YA ESTABAN BIEN nos llevo en algunos momentos a decir la frase que titula este post, porque de veras…. era desesperante que cosas sencillas como asignar u obtener el valor de un control de una variable fuera algo complicadisimo.

En honor a la verdad debo decir que el proyecto salio adelante y ya esta en produccion, pero no dejo de pensar que los dos meses (como minimo) que se agregaron al proyecto multiplicado por el coste de 2 recursos (igualmente como minimo) hubiera podido alcanzar para la adquisicion de un mejor servidor, sin el inconveniente de la poca mantenibilidad que adquirio el proyecto.

En resumidas cuentas con ASP.NET uno se acostumbra a manipular directamente los valores de los diversos controles que estan en la pantalla, con AJAX tareas simples como requerian la regeneracion de un XML con el conjunto de valores de los controles, siendo necesario implementar funciones (mas complejas) para recuperar los valores utilizados pues los valores que usa por defecto ASP.NET se vuelven completamente inutiles, mas aun: como en este caso teniamos logica duplicada en ciertos momentos debia hacerse una multiple verificacion para saber que conjunto de variables estaba informado, so pena de que la aplicacion fallara.