Hay otros como él, pero éste es el mío
Con la cantidad de faena a hacer en el mundo del desarrollo web, es natural preguntarse cosas como qué tecnología elegir y por dónde comenzar si uno quiere dedicarse a esto.
No son preguntas triviales- la espectacularidad diversidad de plataformas, filosofías y frameworks intimida y lleva a pensar que no es posible tomar una buena decisión- es impracticable probar todas las alternativas y en las etapas iniciales de aprendizaje es difícil formarse una opinión razonada.
En este post pretendo dar unos apuntes que espero sirvan para colocar a alguien en el buen camino.
Una manera fácil de comenzar es por el lenguaje. Es conveniente que escojamos un lenguaje que cumpla las siguientes características:
Comenzando por el principio, un buen punto de partida es mi querido TIOBE. El TIOBE es un ránking de la popularidad de los lenguajes de programación calculado a partir de su presencia en la web. La metodología es inevitablemente discutible, pero el ránking está bastante alineado con mi percepción, así que para mi, es una opción cómoda.
En el top 20 (a junio de 2012) encontramos tan solo 8 lenguajes utilizados comunmente para el desarrollo web: Java, C#, PHP, Python, Perl, Ruby, Javascript y Visual Basic .NET. Fuera del Top 20 encontramos muy poquitas opciones (Haskell, Scala y poco más), así que nos ceñiremos a estos.
Vamos a descartar unos pocos:
C# y Visual Basic .NET son dos opciones que el lector mismo puede escoger descartar o considerar- desarrollar razonablemente en ambos supone unos costes que yo prefiero no asumir (se necesitan licencias de Windows para el desarrollo y despliegue y las versiones gratuitas de Visual Studio tienen bastantes limitaciones)- a parte de que soy un firme creyente en que las herramientas de desarrollo deben ser libres y gratuitas. Si eso no supone un impedimento para el lector, puede aplicar mi opinión sobre Java, ambas plataformas son extremadamente similares; quizás .NET goce de herramientas más sencillas de utilizar inicialmente, el sistema base es más completo que el de Java pero el ecosistema goza de menor vida.
Por tanto, nos quedamos con Java, Python y Ruby. Los dos factores más diferenciales entre los tres para mi son:
En mi opinión, ambas herramientas deben estar en el arsenal de un desarrollador web. Python + Django para proyectos sencillos o en los que el Admin de Django suponga una gran ventaja, y Java para proyectos grandes y complejos. Python nos da agilidad y el Admin y Java nos da la potencia para desarrollar sistemas complejos.
Por supuesto, la cosa no se queda aquí. El desarrollo web requiere unos conocimientos de base; más allá de los conocimientos de programación estándar (que obviamente son necesarios), necesitaremos conocer:
Seguramente también necesitaremos un mecanismo de persistencia (donde SQL es la opción más popular, yo recomendaría usar PostgreSQL y evitar el popularísimo MySQL pero infame) y conocimientos básicos de sistemas (deberíamos saber hacer funcionar un servidor web, la base de datos, etc.).
Con todo esto podríamos desarrollar alguna web sencilla con Django, que nos proporciona una plataforma bastante completa y bien documentada con la que podremos implementar bastantes proyectos.
Una vez asentados los fundamentos del desarrollo web, podemos comenzar a investigar Java. Java no es como Django, que incluye prácticamente todo lo necesario en un sencillo paquete y, una vez más nos plantea unos problemas de decisión importantes. Lamentablemente, desconozco una buena referencia completa y vertical de desarrollo Java que ofrezca un stack completo comparable al de Django. Mi recomendación sería partir de Java, añadir Spring (el mecanismo de inyección de dependencias, su librería de JDBC y el motor MVC) y JSP, todo corriendo sobre un contenedor como Jetty o Tomcat (que se integre en nuestro entorno de desarrollo), utilizando Eclipse y Maven para la compilación. Desgraciadamente es una solución más compleja para la parte inicial (y muchas de ellas se deben aprender prácticamente simultáneamente, incrementando la dificultad), pero adoptando todas estas tecnologías tendremos una base similar a la de Django. El camino es mucho más largo, pero nos ofrece una alternativa más apropiada para grandes proyectos.
Lógicamente, esta es una vía “ideal”. Quizás no debe completarse completamente, si no hemos de trabajar en proyectos muy complejos Java es una exageración, o bien la vida nos lleve a sumergirnos en otras tecnologías, pero es un recorrido completo. Si no llegamos a Java (o incluso si llegamos), puede ser conveniente pasar tiempo usando algún microframework que no nos dé un stack completo como el de Django, Django nos lo da casi todo mascado y seguramente hay detalles interesantes de conocer a bajo nivel que nos perdamos. Hacer desarrollo web sin un stack completo ciertamente puede ayudarnos a completar nuestras habilidades. Podemos hacer esto tanto en Python (usando un microframework de los muchos existentes, o incluso desarrollando el nuestro) como en Java (programando directamente servlets en vez de usar el MVC de Spring) o en cualquier otro lenguaje.
nota: más ediciones y sugerencias del de siempre.
Marvel tenía (o tiene, estoy tremendamente desactualizado) un cómic titulado “What if…?” que trataba de qué pasaría en los universos Marvel si algún acontecimiento clave hubiese seguido otro curso. Así pues, podíamos leer cosas como qué hubiese pasado si Spider-Man hubiese sucumbido al simbionte o Gwen Stacy no hubiera muerto.
Yo, la verdad, prefería “What the…?”, que trataba de situaciones absurdas, pero bueno.
El ejercicio que me propongo hoy es “What if… PHP y MySQL nunca hubieran existido?”
PHP y MySQL fueron en su momento las estrellas del desarrollo web. PHP surgió de un proyecto personal de Rasmus Lerdorf inicialmente publicado en 1995, que según el TIOBE, comenzó a dispararse en popularidad allá por 2002 y gozó de su mejor momento entre 2005 y 2010, donde inició un aparente declive (seguramente por el ascenso de otros lenguajes/frameworks para la web menos demenciales). MySQL empezó como proyecto en 1994 y su primera publicación fue (la Wikipedia no es muy específica en este asunto) entre 1995 y 1998—no encuentro buenas fuentes sobre su ascenso a la fama, pero yo lo situaría aproximadamente por la misma época que el de PHP, y sin que se atisbe una caída en su popularidad (si no contamos su adquisición por parte de Oracle en 2010 y la relativa proliferación de forks).
No es casual, claro, que la web explotara justo en ese momento, entre 1996 y 1998, y que los dos estuvieran en el sitio exacto, en el momento exacto para formar la MP de LAMP. En un momento en el que no había una abundancia de herramientas de desarrollo web decentes (Perl era probablemente la alternativa abierta más popular; los servlets de Java son del 97, pero por ejemplo hasta 1999 no existió Tomcat; ASP de Microsoft data de 1998… no había muchas más cosas y por supuesto, gran parte de lo que hoy está de moda en aquella época ni existía), PHP/MySQL era una tupla muy accesible para desarrollo web —fácil de instalar, fácil de comenzar y fácil de obtener resultados rápidos— y sin mucha competencia que hiciese destacar sus defectos. Esto llevó a que prácticamente todo el segmento “no profesional” y una parte importante del profesional se volcasen en esta plataforma (las “MS Shops”, por supuesto, apostaron por ASP y mucha gran empresa se fue a Java) y posteriormente, como suele suceder, el sector no profesional arrastrase al profesional.
Sin embargo, hoy en día PHP está bastante denostado. Se le sigue reconociendo como vía “rápida y sucia” y goza de una inercia considerable (sobre todo, por la abundancia de mano de obra y código existente a mantener), pero puede decirse que ha pasado de moda y que sus abundantes defectos le están pasando factura; prácticamente podría decirse que Facebook es su único usuario de gran perfil (y con importantes peros). MySQL, en cambio, sigue relativamente saludable, sigue siendo extremadamente popular y, pese a que el sector crítico parece crecer día a día, no parece que vaya a ser eclipsado en breve.
¿Qué hubiera pasado si Rasmus Lerdorf se hubiera avergonzado de su pequeño monstruo y hubiese decidido mantenerlo en el sótano oscuro y lúgubre que nunca debió abandonar? ¿Y si MySQL no hubiese tenido su vertiginosa aceptación, quizás por una mala fama alimentada por alguna deflagración especialmente notable?
Probablemente, el mundo web hubiese sufrido algún retraso. Perl, Java o ASP no eran suficientemente accesibles en ese momento como para tomar el relevo (por diversos motivos: de coste en el caso de ASP, de accesibilidad para Java y Perl). Lo más probable es que Perl hubiese ganado bastante terreno y hoy en día gozase de más popularidad, incluso entre los imberbes. ¿Se hubiese adelantado algún framework como el popular Ruby on Rails? Yo creo que no; Rails surge ya en 2005 y no creo que se hubiese acelerado mucho su aparición en caso de haber existido un vacío. Simplemente, hubiésemos visto otros frameworks nuevos sobre algún lenguaje existente, o quizás algún framework que el tiempo olvidó habría sido adoptado masivamente. Apostaría por que Python, que explotó en popularidad en 2004, hubiera cubierto el vacío de PHP con algún framework.
¿Consecuencias? Sí, la web retrasada 2-3 años. Probablemente los titubeos propios de PHP se hubiesen trasladado a su sustituto (algún framework sucio y bizantino de Python se habría impuesto), o quizás (Dios no lo quiera) Perl hubiese arrasado y hoy en día estaríamos condenados a prefijar todo con sigilos (pero seguramente con un framework elegante). La versión optimista (para mí) es que la web como plataforma de aplicaciones no hubiese tenido su auge y nos hubiéramos quedado mayormente en la web de contenidos y el modelo de aplicaciones de escritorio… y con toda probabilidad esto habría supuesto un buen bofetón para Linux y en menor medida para Apple (las aplicaciones web son prácticamente automáticamente multiplataforma). ¿Sería esto positivo? Por una parte, uno es de los que suscribe que nunca debimos apostar por la web para aplicaciones (sí, desde luego, para contenidos) y que quizás buen número de informáticos no tendrían que haber lidiado con los problemas de la web para este propósito y destinado su tiempo a cosas más útiles: siendo optimistas, quizá hoy tendríamos aplicaciones de escritorio multiplataforma de despliegue indoloro (e.g. Java y Web Start, pero bien) y todo sería más de color de rosa. El reverso de la moneda sería un monocultivo Microsoft y todos estaríamos desarrollando en Visual Basic (y no, no el .NET), claro está.
A un nivel más elevado y más del mundo real, igual las burbujas web y sociales no hubieran nacido ni estallado nunca. Habría más desarrollo informático empresarial tradicional con el aburrimiento y la solidez consiguientes.
Por otra parte, creo que la historia no habría cambiado sustancialmente sin MySQL. PostgreSQL seguramente ocuparía su lugar, llevándonos a un mundo con más integridad referencial y donde nuestros datos serían un pelín menos volátiles. Defiendo que el movimiento NoSQL hubiera dado un pequeño paso atrás. Sí: con o sin web de aplicaciones y todo eso, Google hubiera existido y hubiese necesitado BigTable/MapReduce (es el contenido lo que es difícil de indexar). Pero parte de la necesidad de NoSQL viene de las deficiencias de MySQL y no del modelo relacional (adicionalmente, este no estaría tan desprestigiado y probablemente serían más de cuatro gatos los que sabrían sacarle partido). Y es que resulta difícil encontrar una implementación peor de SQL que MySQL (si no contamos SQLite, claro, pero ese juega en otra liga).
Cuesta imaginar un efecto real de la no existencia de MySQL: quizás eso quiera decir que pese a que PHP haya caído antes, quizás éste haya sido más instrumental y relevante en el mundo real. MySQL simplemente ofrecía “funciona en Windows y no hay otro popular” (lo de la velocidad son historias); PHP era “tu web, ahora y sin complicaciones”. Uno pensaría también que los deméritos de PHP son menores que los de MySQL: pese a que ambos son sucios y volátiles, opino que PHP es más sucio que volátil, mientras que MySQL es más volátil que sucio… y en informática, lo sucio es doloroso pero inevitable, mientras que lo volátil puede causar daños corporales permanentes.
(correcciones, ediciones y sugerencias del de siempre)
Con el megapelotazo que ha supuesto los Vengadores (ya sólo a la zaga de Avatar y la inalcanzable Titanic- James échame una limosna, anda) quizás sea el momento de echar la vista atrás y soltar una sesuda reflexión sobre el “género”.
¿Son las pelis de superhéroes un “género” siquiera?
Lo mismo supongo que se preguntarán los que piensan demasiado sobre los westerns; entre una con un John Wayne bonachón, una de Leone, Sin Perdón o Arma Joven, es difícil encontrar nada en común que no sea la época- y aún así no nos es difícil encontrar westerns como Atmósfera Cero o Firefly/Serenity ambientados en el espacio o pensar que si Yojimbo y Por Un Puñado de Dólares son básicamente la misma película, ambos deberían ser westerns, ¿no?
Con las pelis de superhéroes pasa lo mismo. Yo calificaría Los Vengadores como la primera peli de superhéroes de divertimento relevante- quizás la forma verdadera de las pelis de superhéroes… ¿pues no es decir “Hulk, machaca” la auténtica esencia de los cómics de superhéroes? (Quizás otras películas, en particular Green Hornet, de Gondry, o incluso la reciente Thor, se inscriben en esta corriente, pero son sin duda obras menores). No es casual que Joss Whedon, al mando del cotarro, sea guionista habitual de Marvel y DC y haya sido precisamente él quien nos haya brindado una experiencia que hasta el momento se les había escapado a todos. Lamentablemente, la cinta cojea en ocasiones, en mi opinión sobre todo por un exceso de escala que se le escapa en ciertos momentos a Whedon y quizás una cierta falta de ritmo a ratos (quizás por el desigual elenco de personajes).
Otras cintas, de tanto o mayor calado, han ido por otros derroteros. La que es para mí la mejor película de superhéroes, X-Men 2 de Brian Singer (Sospechosos Habituales), pese a enseñarnos a mucha gente con trajes de superhéroes, no tiene apenas escenas de acción (aunque sus dos piezas principales, la introducción con Rondador Nocturno y el asalto a la Mansión de Xavier, son absolutas obras maestras del cine de acción) y se desenvuelve entre el thriller, la cinta de acción prácticamente convencional (recordemos que mucha acción está poblada de gente sin superpoderes y que, desde luego, la escala es mucho menor que Los Vengadores) y la vertiente social típica de los X-Men. Por supuesto la guinda son unos personajes perfectamente dibujados gracias a las excelentes interpretaciones de Ian McKellen, Brian Cox (Stryker) e incluso un acertadisimo, aunque secundario, John Allerdice (Pyro).
Hellboy (Benicio del Toro) en cambio, parte de un cómic más atípico (Hellboy es más un detective de lo oculto que un tipo con mallas que vuela). Como en X2 las interpretaciones (merecidísimo triunfo de Ron Perlman con excelentísima contrapartida de Selma Blair) son el atractivo principal de la cinta, así como una narración y un estilo propio que combinan muy bien un cine “de autor” con cine de acción más que correcto.
En otra nota, Watchmen parte de una obra que tiene superhéroes, pero que se encuadra en un género más reflexivo y analítico; Watchmen sí es descaradamente un estudio sobre la condición humana que utiliza los vigilantes enmascarados y un superpoderoso tal y como Asimov usa a los robots para hablar de las personas (y de pasada, de los superhéroes, sí). Curiosamente Watchmen ya era prácticamente más storyboard que tebeo y estoy indeciso a la hora de valorar el trabajo de Zack Snyder e incluso de los actores- ¿hacen algo más que darle movimiento a la obra de Moore y Gibbons?
Aparte queda alguna rareza- yo destacaría el Hulk de Ang Lee, un preciosista experimento de montaje y fotografia que, pese a que seguramente es insostenible, representa quizá el más acertado acercamiento visual a los cómics; deja a Watchmen en el aspecto visual al nivel del betún. La peli, desgraciadamente, salvo este superlativo montaje de viñetas, poco más tiene que ver con los cómics o los superhéroes. Complejo de Edipo + Super Mario Bros como argumento más unas interpretaciones poco inspiradas lastran mortalmente la película.
¿Es casual que dentro de las pelis más destacables encontremos reconocidos autores? Tim Burton, Christopher Nolan o incluso Kenneth Branagh (¡sí, amigos, recuerden que firmó Thor!) se han metido en el género con desiguales resultados: no, no todas las pelis de superhéroes son bazofia (y desde luego, pocas son realmente buenas). Sí, es un “género” de estos denostados, como los westerns lo pueden haber sido en ocasiones, o la ciencia ficción o las pelis de tiros o de patadas voladoras, pero desde luego que no merece ser despreciado. Por suerte para los aficionados, con los éxitos comerciales y la abundancia de material por adaptar, tendremos películas para rato…
De bonus, un ránking. Yo consideraría The Punisher (1989, la de Dolph Lundgren) como la frontera entre lo aceptable y lo malo (más que nada porque a día de hoy no sé si me gusta de lo mala que es, no es tan mala como parece o si simplemente es mala).
(correcciones y retoques importantes del de siempre, que como siempre evita que escriba sin ninguna revisión)
Hace tiempo ya explicaba por aquí las virtudes de Django. En resumen, se trata de un framework de desarrollo en web Python que implementa un interfaz de administración prácticamente automático a un esquema relacional. Vaya, que defines tus tablas y genera un interfaz dinámico para editar registros que te ahorra una barbaridad de tiempo (como podrá atestiguar cualquiera que haya tenido que hacerse uno).
Tras llevar más tiempo trabajando con Django, sigo convencido que en estos momentos es la mejor solución que existe para desarrollo web basado en CRUD sobre bases de datos; el admin no tiene equivalente alguno que yo conozca, y desarrollarse un sistema similar es extremadamente costoso.
Sin embargo, creo que he aislado unos cuantos defectos clave que hay que tener en cuenta antes de comenzar a usarlo.
1.
Si usamos un esquema donde queramos que la edición de un registro tenga más de un nivel de indirección, el admin no soluciona esto. Pongamos por caso que tenemos una entidad “Empleado” , otra entidad “Proyecto” y una entidad intermedia que nos representa las asignaciones de Empleados a Proyectos (por ejemplo, en esta relación intermedia podríamos querer almacenar el tiempo durante el cual el Empleado está asignado al Proyecto, su porcentaje de dedicación a él, etc.). Podremos añadir un fantástico TabularInline que nos muestre las asignaciones de Empleados dentro de la vista de detalle de Proyecto, pero no hay manera de que se pueda editar el Empleado desde la vista detalle de Proyecto; podremos editar la relación intermedia (primer nivel de indirección), pero la segunda ya no.
Esto nos limita bastante el interfaz sobre esquemas de datos moderadamente complejos que nos podemos encontrar fácilmente en el mundo real; cuando tengamos estos esquemas tendremos que…
Ninguna de las tres soluciones es mínimamente satisfactoria
2.
El admin necesita más hipervínculos. En particular, la fantástica funcionalidad de los raw_id_fields, nos permite hacer que los campos clave foránea de nuestras entidades se puedan editar con un popup selector excelente, pero no nos permite saltar a la entidad enlazada. Una de las grandes virtudes de usabilidad de la web son los enlaces, y nos serían extremadamente útiles en más lugares del admin
3.
Django no proporciona suficiente potencia en el SQL subyacente a su ORM. En particular, sería harto conveniente poder disponer de, o bien un inspectdb más potente que nos permita trabajar continuamente con él (añadir campo en nuestra base de datos y que inspectdb añada dinámicamente el campo al modelo), o un mecanismo para poder personalizar automatizadamente el esquema generado; esto principalmente nos debería permitir implementar una “estrategia” de nombrado de tablas y columnas que nos permita, por ejemplo, que los nombres de tablas sean plurales o cambiar el nombre de las claves primarias surrogadas que Django añade automáticamente.
Si no nos gustan los esquemas que genera Django automáticamente (y no deberían gustarnos), las alternativas son o aguantarnos, o especificarle repetidamente los nombres de tablas y columnas que debe usar o hackear Django para que haga lo que queramos. Una vez más, esto no es del todo satisfactorio.
4.
A un nivel más profundo, el código de Django no es muy amigable a la extensión. Es bastante complicado añadir funcionalidad derivando de las clases de Django; el código no siempre es fácil de seguir (ya que usa bastantes metaclases y otras pythonicidades de las que no soy muy fan) ni tiene un diseño orientado a objetos muy elaborado- se echa en falta que ciertas funcionalidades estén, como mínimo, aisladas en un propio método que podamos sobreescribir para cambiarlas (o utilizar el patrón estrategia, idealmente). Siempre nos queda la opción de forkear, pero esto no es muy mantenible, o hacer monkey-patching, lo que tampoco es muy recomendable ni mantenible.
Pese a todos estos puntos, sigo pensando que el admin de Django es realmente algo único que nos puede ahorrar muchísimo trabajo y proporcionar un resultado de gran calidad para muchos, muchísimos proyectos. Pero aún es mejorable- y con unas pocas mejoras localizadas podría mejorar muchísimo.
