Mi tortuosa historia de aprender web (parte 2).
¡Hola! Prácticamente este año se ha acabado, y aunque la pandemia nos ha traído tantos problemas laborales, sociales y familiares, lo importante es que has llegado hasta este punto, y esa es razón suficiente para que celebres, así que ten paciencia, no pierdas el ánimo y pasa una ¡Muy feliz Navidad!.
Te agradará saber que el día de hoy he publicado en El Camino de Java, Volumen 2, las lecciones que la mayoría están esperando: Todo acerca de Tomcat y el desarrollo de aplicaciones web, y lo he hecho de una manera muy cuidadosa, para que no sufras todas las penas que yo tuve que sufrir cuando estaba aprendiendo:
Bueno, ya te había contado cómo comencé a hacer desarrollo web, en la primera parte de esta historia, donde te platiqué la forma en que comencé a desarrollar páginas web: Literalmente en la edad de piedra, con herramientas de la edad de piedra. Después tuve mi primer trabajo y lo que estaba de moda eran los sistemas cliente-servidor, que consistían en una aplicación de escritorio que funcionaba como cliente, y un servidor que manejaba la base de datos. Hoy día a cualquier administrador se le pararían los pelos de punta cuando viera este modelo: Cada computadora tenía acceso directo al servidor de base de datos, y después de obtener un usuario y clave de acceso, que no debería ser difícil para cualquier hacker principiante, era posible entrar a la base de datos y hacer lo que quisieras, pero esos eran otros tiempos, donde solo había dos clases de usuarios: El que no tenía ni idea de cómo funcionan las cosas (que eran todos los usuarios) y el que tenía el conocimiento, pero esos estaban en nuestro equipo de trabajo, recibiendo tantas quejas y latigazos, que en lo último que pensarían sería en descomponer lo que con sudor y sangre estaban construyendo.
Como también ya te platiqué, los programas se hacían en Visual Basic, que utilizaba el modelo COM, y de buenas a primeras, se pusieron de moda las aplicaciones web, y no creas que pensamos en el cambio solo porque se había puesto de moda, simplemente lo vimos de esta manera: En lugar de estar sufriendo porque el programa no funciona con aquella computadora vieja que tiene el cajero, el sistema funciona en un servidor central, y cualquier computadora con un navegador puede trabajar, además, con una aplicación web se eliminaban por completo todos los problemas de instalación que teníamos: Sistemas incompatibles, instalaciones que no funcionan en algunos equipos, y computadoras infectadas de virus, porque si algo no funcionaba, no era culpa del usuario que estaba infectado de virus por andar instalando programas prohibidos, ¡era culpa nuestra! porque no se podía trabajar con nuestro programa.
Así que en su momento vimos todas esas ventajas, y como la empresa se especializaba en Microsoft y su modelo COM, pues obviamente la estrategia fue desarrollar aplicaciones web usando IIS y Visual Basic. Nada mas de acordarme me dan ganas de aventarme por la ventana: Al principio todo era novedad, las páginas se escribían en HTML, usando códigos de escape para incluir código en Visual Basic, pero no pasó mucho tiempo cuando nos dimos cuenta que mezclar código con HTML era una pésima idea porque el resultado parecía una pintura de Picasso, y llegaba el punto en que agregar una nueva funcionalidad no solo necesitaba un esfuerzo titánico, sino que en el proceso descomponíamos lo que ya estaba funcionando.
Para solucionar esto, comenzamos a separar funcionalidad: La página era en su mayoría HTML, y cuando necesitábamos lógica, entonces creábamos un objeto en Visual Basic y lo llamábamos desde la página HTML, o mejor dicho desde las páginas ASP, que significa "Active Server Pages". Con esto, habíamos hecho el trabajo más simple, porque ahora concentrábamos toda la funcionalidad en módulos hechos en Visual Basic, y esta funcionalidad era invocada desde las páginas ASP. ¿Encontramos en esto el paraíso? Nunca podíamos estar más lejos de eso, mas bien, lo que encontramos fue un nuevo infierno: Resulta que no pasaba mucho tiempo cuando el desarrollo empezaba a ser muy difícil, y de lo que más me acuerdo es que compilábamos el proyecto en VB, probábamos las páginas y no podíamos ver los cambios, eso nos podía tomar mucho tiempo y simplemente no encontrábamos la causa.
Después de mucho batallar encontramos el problema: Como cada clase de Visual Basic se compilaba como un objeto COM, éste se tenía que registrar en Windows. ¿Haz alguna vez oído hablar del registro de Windows?, bueno, si no lo haz hecho puedes hacer este experimento: Selecciona la tecla Windows+R, en el diálogo para ejecutar programas escribe "regedit" y OK, con eso te aparecerá el editor del registro de Windows, del lado izquierdo se encuentran folders que puedes abrir para explorar la información. Pronto te darás cuenta que el registro de Windows es enorme, y para que tengas una experiencia inolvidable, experimenta cambiando algunos valores, especialmente en el folder HKEY_LOCAL_MACHINE, y verás que rápidamente habrás arruinado el funcionamiento de Windows, si no lo arruinaste en este momento no te preocupes, porque tal vez mañana, o en una semana, o un mes, inexplicablemente tu computadora fallará, y seguramente ya no recordarás que la causa fue lo que cambiaste en este momento.
Bueno pues algo parecido sucedió con nuestros desarrollos: Cada que compilábamos el proyecto, se tenía que registrar en Windows, pero los componentes anteriores tenían que des-registrarse, en un proceso que no era fiable, y eventualmente o no quedaba ninguna clase registrada, o se registraba tanto el objeto viejo como el nuevo. Por supuesto también era posible que quedaran 3, 4 o más copias de los ejecutables, incluso podían existir clases registradas apuntando a archivos que se encontraban en la basura. Programar de esta manera rápidamente se hizo una pesadilla, a tal grado que terminamos odiando el desarrollo web, y mejor ni te menciono el hecho de que era una época donde no había estándares establecidos, así que cada navegador entendía su propia versión de HTML, y el programador tenía que hacer programas que funcionaran en todos los navegadores, nada más imagínate el esfuerzo que se requería.
Y de repente, apareció Tomcat. Nunca supe cuando apareció en el mercado, solo recuerdo que llegó un cliente potencial que solicitaba un desarrollo web, pero lo quería hecho en Java, y cuando escuché la noticia, empecé casi casi a suplicar: ¡Sii, acepten por favor ese proyecto, yo me comprometo a ayudar en lo que haga falta!, y es que yo usaba Java regularmente, pero no para el trabajo. Yo no sé si mi insistencia habrá ayudado, pero el caso es que aceptaron ese desarrollo, en el cual yo no participé, pero en mis ratos libres me ponía a estudiar como usar ese nuevo servidor Tomcat, y ¡era un sueño hecho realidad!. Primero que nada, era infinitamente más estable que IIS, y como las clases de Java no se registraban en Windows, entonces nunca se descomponía la computadora, simplemente compilabas y probabas; además, contábamos ahora con un lenguaje 100% OOP, y podíamos aprovechar todas sus bondades. Para que te des una idea de lo que sentí, era como llevaras semanas trabajando bajo el sol, en el día más caluroso del desierto, y de repente de dijeran: "Por favor, entra a esta habitación con aire acondicionado", bueno pues así me sentía trabajando con Tomcat. Por supuesto programar nunca ha sido fácil sin importar que lenguaje estés utilizando, pero yo prefiero sufrir con mis propios problemas, que tener que soportar además los problemas de las herramientas con las que trabajo, y bueno, para no alargar más la historia, no pasó mucho tiempo hasta que al fin tuve en mi empleo mi primer proyecto Java, y por los siguientes 20 años, no volví a trabajar con algo que no fuera Java, a menos que no tuviera otra alternativa claro.
¿Por qué creo que Java es popular?, pues de lo que estoy seguro es que no es solo por moda, sino porque es un lenguaje que le permite a las empresas mantenerse productivas, porque a una empresa no le interesa si un nuevo lenguaje está de moda, lo que les interesa es si sus costos se van a mantener bajos, si los programadores seguirán siendo productivos y si hay suficiente fuerza de trabajo en el mercado para reemplazar a quienes renuncian. En otras palabras: Los motivos que realmente hacen popular a una tecnología son simplemente intereses económicos. No olvides esto cuando le vayas a decir a tu jefe: "¿Podemos usar este nuevo lenguaje? ¡es que se ve bien bonito!".
¡Feliz Navidad! y nos vemos el año que entra...
Sinceramente,
Raúl Cosío