A regañadientes, desde el cine sin ley a la ciudad de los ángeles

¿Cuál es el propósito de una crítica de cine?

Aunque a veces parezca que sea demostrar que tienes un buen diccionario de sinónimos y que has visto pelis que no le importan a nadie, supongo que es hacer saber a alguien si le valdrá la pena ir a ver algo.

En ese caso, sí, id a ver La La Land. Siendo un musical, supongo que sólo estarán leyendo aquellos que acepten los musicales o que no sepan que lo es. Fuera de eso es difícil precisar más, la peli tiene tantas cosas buenas y bastantes cosas malas como para que salgáis del cine haciendo claqué o echando espumarajos por la boca.

Visualmente, La La Land es un trabajo impecable. Desde el larguísimo plano secuencia inicial al imaginativo acto final, hay poquísimos momentos que no asombren y sólo un par de cosillas que chirrían un poco (por mucho que avancen los efectos especiales, aún quedan cosas sencillas que no se pueden hacer). Sentarse y absorber todo ese derroche ya vale el precio de la entrada y las dos horas que dura.

Musicalmente, a mi no me convenció tanto. Vaya por delante que mi mente tararea en bucle el repertorio de Hair pero que la mayoría de canciones de musical me suelen parecer olvidables, y La La Land no es una excepción. La Stone y el Gosling dan un esfuerzo más que admirable, pero no son cantantes y en especial la garganta de éste último no está hecha para llevar la voz cantante. ‎Eso sí, en baile para mí sí que dan totalmente el nivel. En cualquier caso, creo que en una semana ya no recordaré las canciones.

Lo otro es el guión. Aunque contiene un par de ideas buenas, no las aprovecha casi nada y cuando lo hace es un poco atropelladamente. No consigue meter al espectador en la vida de los personajes y no se sabe muy bien por qué; hay elementos de tensión y drama, pero nunca parece que vaya a pasar nada.

Aún así, sí que la peli goza de unos cuantos aciertos- la escena de la fiesta es una auténtica gozada que me dejó una sonrisa difícil de borrar. Hay destellos por toda la película que dejan ver que de alguna manera podía haber sido mucho más- creo que también porque a veces intenta abarcar demasiado, explicar todos sus amores y homenajear todo lo homenajeable, con aciertos y fallos por igual (aunque aprovechar que ruedas en la meca del cine como hacen en La La Land es algo que deberíamos ver mucho más a menudo).

Pero vedla. Puede que en un par de años no nos acordemos de ella, pero es uno de los acontecimientos de año y hay material para disfrutar un rato. Si Damien Chazelle es el segundo advenimiento o un niño mimado y sobrevalorado es una pregunta que tendrá que esperar un par de películas más; Whiplash tenía la carga de diez megatones que todo debut debe tener y La La Land tiene el ansia de aprovechar todo recurso disponible y se le pueden perdonar sus vicios derivados. Habrá que ver si cuando se estabiliza puede cuajar cintas totalmente redondas o seguirá con estallidos irregulares.

Por qué no uso productos Apple

En un mundo en el que el iPhone es el modelo de teléfono más vendido y parece que una inmensa cantidad de desarrolladores de software utiliza ordenadores Apple, a veces uno se siente necesitado de justificar por qué no usa ningún producto de esta compañía. Aquí va, para facilidad de referencia.

La censura no mola

Apple desea controlar lo que el usuario de sus dispositivos puede ver y no ver. El ejemplo más claro es la prohibición de pornografía en la App Store. Si bien es su tienda y pueden poner sus reglas, y puede parecer una política respetable, sigue siendo censura y control. Me parece perfecto que se etiqueten los contenidos que pueden ser malignos (obviamente no digo que la industria pornográfica sea un nido de virtud, más bien al contrario) e incluso los que puedan ofender la sensibilidad de unos pocos- y incluso creo que es levemente defendible que el responsable de un menor pueda intentar bloquear el acceso de ciertos materiales a éste [aunque personalmente no esté de acuerdo], pero estoy firmemente opuesto a que una empresa intente restringir lo que puedo hacer con su dispositivo.

Entiendo que los dispositivos iOS disponen de navegadores que hacen que estas restricciones sean más bien un brindis al sol, pero temo que Apple no haya extendido estas restricciones a la totalidad del dispositivo no por falta de ganas sino por la imposibilidad de hacerlo.

Si bien los inicios de la censura suelen ser por motivos loables, el uso de ella es incorrecto de por sí por más de acuerdo que podemos estar con la indeseabilidad del material bloqueado, ya que la voluntad de usar la censura se extiende fácilmente a otros materiales cuya indeseabilidad es mucho más relativa o incluso incorrecta. El hecho de que dispongamos alternativas que nos permitan sortear esta censura tampoco las justifica- la censura es malvada y la única manera de que avance es cortándola de raíz antes de que sea inevitable.

La libertad de desarrollo

Como desarrollador de software, creo que los dispositivos programables son uno de los grandes avances de la humanidad, quizá no a la altura del agua corriente o la higiene, pero sin duda con el potencial de hacer del mundo un lugar mejor. Recuerdo con cariño el Commodore 64 de mi infancia que arrancaba directamente a un interprete de BASIC y que permitía distribuir el software que uno mismo desarrollaba grabándolo en una cinta de cassette de coste mínimo.

Si bien los ordenadores Apple con OS X hasta vienen con herramientas de desarrollo incluidas, la punta de lanza de Apple son sus dispositivos más vendidos, los que usan iOS donde la situación de desarrollo es totalmente diferente. Para desplegar las aplicaciones que desarrollamos sobre hasta 100 iPhones, debemos ser desarrolladores registrados por Apple, lo que tiene un coste y requiere aprobación (dudo mucho que rechacen muchas solicitudes, pero aún así, pueden hacerlo). Si queremos que use nuestro software más de 100 personas, debemos pasar inevitablemente por la App Store y que Apple examine y apruebe nuestra aplicación.

Es decir, no podemos desarrollar software para iPhone y que sea usado por más de 100 personas si este software no es del agrado de Apple- según unos criterios que además son poco transparentes- para lo cual deben tener acceso completo a él.

Esta restricción de la libertad de desarrollo de software me parece completamente draconiana e inaceptable- y extremadamente dañina si se extendiese, por lo cuál una vez más creo que debe ser cortada de raíz.

Apple ya tiene suficiente dinero

Apple gana mucho dinero. Muchísimo. Tiene un margen comercial más amplio que sus competidores. A igualdad de condiciones, si la empresa A tiene un margen del 15% y la empresa B tiene un margen del 30%, voy a comprar el producto de la empresa A. Si bien la eficiencia en la producción de Apple muchas veces significa que los precios de Apple son competitivos (durante mucho tiempo, el Macbook Air de 13″ era imbatible en calidad/precio, y sigue dando mucha guerra), en muchas ocasiones los precios de Apple coloca a sus productos en el segmento de lujo que yo no puedo justificar.

Apariencia sobre utilidad

Con la famosa batería del iPhone, el cargador del Magic Mouse y el lapiz del iPad Pro, últimamente se hace mucho cachondeo sobre la supuesta caída en picado del diseño de Apple. La verdad, no creo que sea algo nuevo.

Hace mucho, mucho tiempo que me compré mi primer producto Apple, un Mighty Mouse  que en vez de ruedecilla tenía una bolita que permitía hacer scroll en dos dimensiones, una idea que me intrigaba sobremanera. Sin embargo, al cabo de muy poco tiempo descubrí que el mecanismo de la bolita acumulaba suciedad sin que hubiese un mecanismo razonable para limpiarla, con lo que el ratón murió prematuramente. Una idea cojonuda pero mal ejecutada.

Veo en los productos de Apple pantallas ultrabrillantes con insoportables reflejos, portátiles innecesariamente delgados (el peso de un portátil importa mucho, que sean finos no aporta nada) que tienen teclados sin profundidad (el teclado del nuevo Macbook es realmente terrible), insistencia en los touchpad cuando los ratones y trackpoints son superiores, teclados a los que les faltan teclas vitales (reemplazando la útil “suprimir” por una peligrosísima tecla de apagado), etc. etc. Apple sacrifica constantemente la utilidad por la apariencia, y yo uso los ordenadores, no los contemplo.

El camino de la verdad y la virtud

Apple tiene claro cómo quiere que el usuario interactúe con sus dispositivos. Más allá de su deseo de controlar los contenidos y software que se pueden experimentar, también tiene una idea clara de los patrones de uso. Si bien debo decir que seguramente su visión sea de las más claras y coherentes del mercado y que su persecución de la simplicidad es acertada en la mayoría de los casos, uno no puede evitar pensar que para usar adecuadamente un producto Apple uno debe convertirse a su verdadera religión y su manera de hacer las cosas.

Creo que diferentes personas prefieren interactuar con los ordenadoras de diferentes maneras, y que cada uno puede encontrar la manera de trabajar más eficiente para él. Puede que lo haga para fastidiar, pero uso un entorno de escritorio muy peculiar (un “tiling window manager”), utilizo un móvil con teclado físico, prefiero las líneas de comandos y adoro los trackpoints. Apple reduce su diversidad al máximo y si quisiese adoptar sus productos, tendría que renunciar a muchas de estas cosas, ya que Apple nunca se dedicará a ellas. Y si bien su visión es completa y poderosa, a mi no me convence.

Prefiero el software libre

Como programador creo que el software libre es una alternativa muy atractiva al software propietario. Los intereses comerciales raramente se alinean con los de los usuarios (podría parecer que sí, y a veces coinciden, pero no), mientras que si el usuario puede participar activamente en el desarrollo del software, esta alineación es más probable. Mis experiencias en este sentido han sido muy positivas- he conseguido influir en el desarrollo de software que utilizo para obtener arreglos y mejoras que me han beneficiado directamente, algo que creo es muy complicado con el software propietario.

Adicionalmente, también me he beneficiado de poder estudiar y analizar código publicado por terceros, y creo que es una poderosa herramienta de aprendizaje para los nuevos desarrolladores de software.

Así pues, en la medida que sea posible utilizo software libre. Si bien Apple coopera con el software libre en ocasiones, lo hace a regañadientes y primando su interés comercial por encima de todo- y por supuesto, la mayoría del software que desarrolla no es libre.

Esquemas de datos explícitos e implícitos

Hablando de bases de datos relacionales, es común referirse al esquema de datos como la definición de las tablas, vistas, funciones, etc. que conforman la base de datos*. El esquema es sumamente importante, por supuesto, nos define qué datos admitimos y nos condiciona todo código que accede a la base de datos.

Este es un esquema explícito; está ahí, podemos enumerar los objetos de los que se compone y conocer milimétricamente su estructura; podemos saber qué tablas hay y qué columnas tienen, etc.

Ahora bien, supongamos que cogemos una aplicación que usa una base de datos y de repente, ocultamos el esquema. Asumamos por un momento que no podemos saber qué tablas hay, ni qué columnas, ni nada. Aún haciendo este gran cambio, nuestra aplicación seguirá funcionando**. Aún más, si desconectamos todas las restricciones de integridad y admitimos que se inserten valores en columnas que no existen (e incluso los almacenamos)… nuestra aplicación muy probablemente seguirá funcionando correctamente.

La primera observación interesante que podemos hacer es que aquello a lo que llamábamos el esquema de datos puede que no esté ahí, pero los datos que tenemos almacenados seguirán siguiendo el anterior esquema de datos. La programación seguirá condicionada por ese mismo esquema; seguiremos insertando en las tablas y columnas que definía el esquema.

El esquema de datos original que habíamos declarado explícitamente ya no existe, pero el esquema de datos implícito sigue ahí. Los datos continuan cumpliéndolo y el programa sigue regido por él. Existe, por tanto, un esquema implícito que podríamos deducir con bastante certeza observando los datos almacenados y el código que los manipula.

Siguiendo con este experimento, podríamos preguntarnos… ¿no hemos perdido nada, verdad?

Aparentemente, no. En cuanto a funcionamiento, quizá ocultemos y amplifiquemos algún defecto que ya existía (la base de datos aceptará datos inválidos cuando antes los rechazaba, y muy probablemente, no nos daremos cuenta), pero realmente no habremos perdido mucho.

Pero cuando nos llegue el momento de modificar o ampliar el código, sí tendremos un problema: al no poder consultar el esquema, se dificultará mucho nuestra labor. El esquema explícito era eso: explícito, claro, fácil. El esquema implícito sigue ahí, pero está oculto. Lo duro es que antes bastaba con ajustarnos al esquema explícito de los datos, que estaba delante de nuestros ojos, pero ahora seguimos teniéndo que seguir un esquema de datos implícito, mucho más críptico. Tendremos que mirar los datos almacenados o el código para saber cómo se llamaba cada tabla y cada columna, y esta información muy probablemente no esté centralizada.

Por supuesto, hay un caso en el que sí seguirá disponible. Si usamos un algo como un ORM, podremos contar con otro esquema explícito de datos; la definición del ORM -e incluso en algunos casos podremos reconstruir perfectamente el esquema a partir de la definición del ORM- claramente son conceptos si no equivalentes siempre, muy cercanos***. Si este esquema es suficientemente bueno, podría suplir perfectamente al esquema explícito de las bases de datos (e incluso mejorarlo: podría permitirnos expresar un esquema de datos más restringido).

Podríamos decir que el esquema de datos explícito de la base de datos no es estrictamente necesario, pero ciertamente, un esquema de datos explícito es una herramienta muy útil, quizás no tanto para el funcionamiento de las aplicaciones como para su codificación y mantenimiento.

Adicionalmente, es bien cierto que puedan existir datos que no se ajusten al modelo relacional -cuya estructura o restricciones sean sumamente especiales (normalmente por ser extremadamente laxos), pero aunque esto fuera cierto, seguirían teniendo un esquema implícito (o incluso explícito, si la herramienta que usáramos en sustitución de la base de datos lo permitiera o requiriera, o si nosotros  decidiéramos escribirlo) y, igual que en el caso relacional, no disponer de un esquema explícito nos entorpecería las labores de mantenimiento y extensión del código.

Así pues, aunque es posible que un esquema relacional no sea lo más adecuado para nuestros datos, es falaz concluir que la ausencia de un esquema explícito es una ventaja -el esquema implícito sigue existiendo y nos debemos ajustar a él- y es más fácil ajustarse a algo explícito y claro que a algo implícito y oculto.

* en algunos gestores de bases de datos, el término se confunde un poco porque se pueden separar los objetos de la base de datos en “esquemas” para gestionarlos mejor

** las bases de datos permiten a las aplicaciones consultar el esquema [explícito]; hay aplicaciones que utilizan esta funcionalidad (para permitir su personlización mediante la creación de nuevas tablas, etc.); en este poco frecuente caso, dejarían de funcionar, claro

*** lo que nos debería llevar a pensar que uno de los dos es redundante e innecesario

corregido por el de siempre

X-Men: La vieja generación

X-Men: Primera Generación es la nueva entrega de la saga mutante marcada por el regreso de Bryan Singer. Tras Batman Vuelve en el 92, las pelis de superhéroes habían quedado relegadas a Spawns, Blades y Batmans infames, hasta que en 2000, con un presupuesto de mínimos acorde con la crisis del género, Singer encontró un enfoque moderno y verosímil e hizo una peli de calidad aprovechando las posibilidades de los poderes, sembrando la semilla que llevaría a Spider-Man un par de años más tarde, que reventaría los records de taquilla del género y puso en marcha la maquinaria comercial que hoy nos bombardea continuamente.

Tras la primera entrega, Singer firmó X2, en mi opinión una obra maestra que ya con medios respetables conseguía aprovechar al máximo el potencial de los superhéroes, dentro de una excelente película sin apenas puntos flojos, nos dejó por ejemplo con dos memorables escenas de acción (Rondador Nocturno en la Casa Blanca y el asalto a la mansión Xavier) que son dos joyas del cine.

El traspiés vino en la siguiente entrega- los cantos de sirena llevaron a Singer a intentar reflotar la franquicia de Superman con nefastos resultados, y lo peor es que dejó su saga en manos del incompetente Brett Ratner, que firmaría la mediocre X3 cuyos únicos momentos de brillo serían meramente inerciales. Paralelamente, un spinoff bastante olvidable con Lobezno pasaría sin pena ni gloria por las pantallas.

Pero el hijo pródigo ha vuelto, aunque sólo en calidad de productor. X-Men: Primera Generación es una precuela que narra los orígenes del Profesor Xavier y Magneto. La historia se enmarca dentro del conflicto de los misiles de Cuba, claramente una estratagema de Sebastian Shaw (Kevin Bacon) y su Hellfire Club de mutantes selectos, que Xavier y el sr. Imán deberán detener.

El guión quizá sea el elemento más débil de la película- juega demasiado entre la consistencia con entregas anteriores, fidelidad a los cómics y un argumento extremadamente ambicioso y no acaba de cuajar en ningún aspecto; hay agujeros e incongruencias, en ocasiones los personajes se separan demasiado de sus orígenes de papel y la historia no conduce demasiado hábilmente la película.

Pero como contrapartida, tenemos los actores. Especialmente, algunos de ellos. Por qué no decirlo, el Magneto de Michael Fassbender está ahí ahí con el Magneto del magnífico Ian McKellen. Fassbender atraviesa todos los sentimientos con una facilidad y realidad pasmosa, en una interpretación absolutamente espléndida y sobresaliente. Ciertamente el personaje de Magneto da para muchísimo y especialmente en sus orígenes como amigo del que posteriormente sería su némesis, el Profesor X. Sus conflictos internos, sus giros y su tragedia son el punto fuerte de la película. Desgraciadamente, James McAvoy está meramente correcto tirando a bien como el profesor telépata- no queda claro si por el personaje o por la interpretación- como todos los buenos, se nos antoja un poco soso al lado de un goloso villano. Una lástima porque de haber igualado a Fassbender, es posible que muchas de las debilidades de la película hubiesen quedado totalmente eclipsadas por las interacciones entre ambos.

Kevin Bacon como Sebastian Shaw también destaca, así como la mayoría de secundarios; especialmente Rose Byrne como Moira MacTaggert, la humana asociada/ayudante/amante de Xavier (aquí agente de la CIA en vez de genética con Nóbel) y Jennifer Lawrence (la prota de Los Juegos del Hambre) como Mística. Quizá cojea un poco el personaje de Emma Frost, que ya venía un poco cojo de los tebeos y que además se ve lastrado por los peores efectos especiales de toda la película.

En cuanto a la acción y los efectos, en general muy bien. Ninguna escena de acción llega a las alturas de X2- no están tan bien pensadas y no utilizan los poderes a su nivel, y lo más destacable en ellas es, como no, Magneto, seguido de un demoníaco Azazel que está muy aprovechado.

En definitiva, una peli de superhéroes decente y correcta, e impulsada a mayores cotas por el sublime trabajo de Fassbender como Magneto, que nos demuestra, como hizo hicieran antes Hugh Jackman como Lobezno, Robert Downey Jr. como Iron Man, Ian MacKellen como Magneto y un escaso puñado de actores más, lo que se puede hacer con estos personajes.

El ránking quedaría así:

  1. X2
  2. Iron Man
  3. Hellboy
  4. Watchmen
  5. The Dark Knight
  6. The Avengers
  7. X-Men: Primera Generación
  8. Hulk (2003)
  9. Batman
  10. Spider-Man 2
  11. X-Men
  12. Batman Begins
  13. Spider-Man
  14. Batman Returns
  15. Iron Man 2
  16. X-Men Origins: Wolverine
  17. X-Men: The Last Stand
  18. The Punisher (1989)
  19. Thor
  20. Blade
  21. Elektra
  22. The Green Hornet
  23. Fantastic Four
  24. The Green Lantern
  25. Daredevil
  26. Superman Returns
  27. The Incredible Hulk
  28. Superman
  29. Spider-Man 3

Desarrollo web como Dios manda

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:

  • Popular
  • Con tracción para el desarrollo web
  • De calidad

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:

  • PHP: pese a ser un lenguaje explícitamente diseñado para el desarrollo web, en mi opinión PHP nunca debe usarse para desarrollar un proyecto desde 0- a no ser que lo que queramos desarrollar sea extremadamente mínimo- ya sea porque se trate de un desarrollo extremadamente pequeño o bien que pretendamos reutilizar completamente un desarrollo existente como WordPress o Magento. Desarrollar grandes bases de código en PHP es un ejercicio frustrante ya que, sencillamente, no está pensado para ello. Sus limitaciones en cuanto a modelo de ejecución, estructura y modularidad son motivo suficiente para descartarlo, pues el resto de lenguajes que consideramos lo superan ampliamente en estos aspectos, ofreciendo PHP muy poco para compensar (su velocidad para proyectos mínimos).Puede sernos útil conocer PHP, pues existe mucho trabajo manteniendo código PHP (sin embargo, no se trata de un trabajo especialmente gratificante) y en algún momento nos puede ser útil. Pero debe ser erradicado lo antes posible.
  • Perl: durante mucho tiempo fue una de las mejores opciones disponibles, en realidad, una de las pocas viables. Una vez más, el resto de lenguajes de la lista le superan en virtudes sin que Perl ofrezca muchas ventajas propias. El mercado de Perl decae lentamente y cada vez se inician menos proyectos que lo utilicen.
  • JavaScript: si bien deberemos conocer JavaScript para desarrollar efectivamente sobre la web, aún no lo considero una opción viable en el lado servidor. Tendremos que aprender JavaScript, pero el grueso del proyecto deberá ser siempre en otro de los lenguajes. Soy anti-aplicaciones web 100% Javascript, creo que su campo de aplicación es extremadamente limitado y presentan desventajas considerables, pero hay quien les encuentra virtudes

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:

  • Pythoncuenta con el framework Django, que a su vez goza del “Admin”. El Admin es un desarrollo genérico que implementa un sistema de gestión de modelos web genérico muy sofisticado, que nos permite definir las entidades con las que trabaja nuestra aplicación (e.g. en una web de contenidos, artículos, categorías, etc.) y obtener prácticamente sin esfuerzo una interfaz de gestión bastante buena que permite a los usuarios gestionar los objetos, añadiendo un sistema de permisos más que aceptable (i.e. podemos decir que los reporteros pueden crear y editar sus artículos y que los administradores pueden crear y gestionar secciones). Dado que en la mayoría de los proyectos se necesita una funcionalidad así y Django nos la proporciona sin dedicarle apenas tiempo (y desarrollar algo de ese calibre es considerablemente costoso), para muchos proyectos Django nos puede ahorrar muchísimo tiempo de desarrollo tedioso, dándonos una gran ventaja.Puede parecer que otras plataformas cuentan con cosas similares (e.g. Roo en Java, el scaffolding de Rails), pero no están a la altura.
  • Javaes el único de los lenguajes que cuenta con tipado estático. El tipado estático (deber declarar explícitamente el tipo de las variables) parece un problema (debemos “perder tiempo” especificando tipos), pero en realidad no lo es (uno ya razona sobre el tipo que debe tener una variable, escribirlo explícitamente no es costoso) y en cambio permite la existencia de herramientas sofisticadas que trabajen sobre el código. En los lenguajes dinámicos, por poner un ejemplo, es extremadamente laborioso localizar dónde se utiliza un determinado trozo de código, algo necesario para tareas como eliminarlo (debemos asegurarnos que no exista otro código que lo utilice y adaptarlo si existe) o modificarlo (debemos asegurarnos que adaptamos el código que lo utilice), tenemos que buscar las referencias por todo el código y esto puede ser extremadamente problemático si la búsqueda no es muy específica (i.e. si tenemos un campo llamado “página” en un objeto concreto, una búsqueda de texto nos reportará usos de “página” en clases no relacionadas, o que contengan “página”), pues podemos tener una cantidad de falsos positivos muy elevada fácilmente.Esto propicia que los cambios en el código sean mucho más trabajo del que debiera. En cambio, en un lenguaje estático es posible implementar búsquedas muy exactas gracias a la presencia de tipos en el código fuente (básicamente, la herramienta puede discernir si la referencia que buscamos es la que encuentra con exactitud). En Java el compilador nos avisará si un cambio/eliminación rompe código, y las herramientas nos pueden localizar exactamente todas las referencias a un trozo de código. Adicionalmente, las herramientas no se quedan aquí, sino que implementan funcionalidades similares mucho más avanzadas y potentes que no pueden ser implementadas efectivamente sobre lenguajes dinámicos.

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:

  • El protocolo HTTP, el “alma” de las comunicaciones web
  • HTML + CSS, con los que desarrollamos la capa visual de la aplicación
  • JavaScript para las funcionalidades que lo requieran (con jQuery)

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.

What if… PHP y MySQL nunca hubieran existido?

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)

Apuntes sobre Dart

Google ha sacado hoy Dart.

El apunte rápido (que seguro que otros mejoran) es que es un verdadero Javascript. Es un lenguaje muy muy Java que compila a Javascript. Las diferencias con Java van por dos lados:

  • Adecuaciones para funcionar bien cuando se compila a Javascript- i.e. no hay threads, hay “isolates”, etc.
  • Esas mejoras puntuales de Java que llevamos pidiendo a gritos desde hace siglos

Las mejoras de Java son de ovación cerrada:

  • Las clases en Dart generan un interfaz equivalente a su parte pública
  • Constructores con inicializadores concisos
  • Declaraciones anónimas y concisas de funciones
  • getters y setters transparentes. De bonus, se integran con los interfaces
  • Literales para listas y mapas
  • “==” es equals y “===” es “==”. Ver “===” me produce grima por traumas varios, pero creo que es la solución correcta.
Siendo realistas, cubre la mayoría de “defectos” “resolubles” de Java. No, no tiene inferencia de tipos, ni lambdas con excepciones chulas, ni “final” por defecto… y quizás no es todo como uno lo había soñado, pero es una solución práctica y disponible hoy.
Eso es lo positivo. En lo negativo, el tipado opcional me escama- y me duele que signifique sacrificios (hay ahí una cosilla un poco rara con las funciones que no devuelven valor que me deja intranquilo). Me queda la curiosidad de estudiar los isolates para saber si aportan algo o si son sencillamente la manera correcta de montar concurrencia en código que será compilado a Javascript y ejecutado por los motores de Javascript existentes.
He visto otras cosas que aún no me he mirado a fondo que no sé dónde colocar: soporte en el lenguaje para factorías, “const” el sistema de librerías y que null sea un objeto; es difícil saber si serán cosas buenas o malas.
En fin, cosas interesantes. No parece, sin embargo, que Dart aspire de momento a ser algo más que un sustituto de Javascript (algo que no me interesa mucho- el principal problema de Javascript no es el lenguaje en sí, en mi opinión)… con lo que para mi, no es muy interesante de momento.  Si algún día se planta como una alternativa para desarrollo de aplicaciones y para programación, tiene  la oportunidad de ser Java++, pero sin añadir la complejidad y cerradez de C#… pero ni siquiera sé si Google pretende que lo sea (ese rol lo quieren para… ¿Go? ¿Dart? ¿Java? ¿Python?) .