Hay otros como él, pero éste es el mío
No sé si se vislumbra completamente por aquí, pero llevo mucho, mucho tiempo prácticamente obsesionado con encontrar la solución para el CRUD. Ya desde mi primer curro, allá por el 2001-2002, donde usaba el jurásico ATG Dynamo- que pese a primitivo ya se enfrentaba al CRUD bastante frontalmente pude apreciar que en un significativo número de trabajos por los que te pueden pagar, el CRUD es vital.
No sólo porque sí, los programas informáticos suelen servir para eso, para manejar información. Create, Read, Update, Delete es lo que uno puede hacer con los datos, y lo hace muy a menudo, y si lo implementas rápido, ahorras dinero.
La verdadera importancia de esto reside en que si implementarlo es farragoso, eso te lleva por mal camino. Si necesitas un esquema de datos complicado e implementar el CRUD necesario para mantenerlo es costoso y tedioso, existe la poderosa tentación de simplificar el esquema. Denormalizamos, quitamos funcionalidad y en definitiva, guarreamos, porque hacerlo bien nos cuesta. Si hacer CRUD es costoso, tendemos a evitar la base de datos para guardar cosas y las metemos en el código- lo que podrían ser tablas de soporte editables por el usuario se convierten en configuración incrustada en el código que sólo puede cambiar el programador.
Por último, pero no menos importante, cuanto más cuesta implementar el CRUD, peor lo implementamos. Interfaces inflexibles, que no permiten ordenación y paginación, que distribuyen la información que nos interesa entre varias páginas que hacen que editarlo sea un suplicio, con desplegables inacabables y sin función de búsqueda… son males que se pueden evitar si nos vienen gratis.
Es por eso que es importante disponer de frameworks que simplifiquen el CRUD. Es frustrante que sólo Django tenga un CRUD potente y bien implementado, y que todos los demás estén uno o varios pasos por detrás. Es por este motivo que detrás de muchas aplicaciones de negocio lo que hay detrás en realidad es un framework CRUD, y que la calidad de éste es uno de los mayores factores que determinan la calidad del producto.
¿Qué necesita un buen CRUD? En mi opinión:
Con esto, tenemos gran parte del camino recorrido en muchos proyectos. Sin embargo, el hecho de que aún Django, el primero de la clase, esté bastante cojo en algunos aspectos, me hace pensar que o bien esto no puede existir, o que los que lo han implementado no lo van a publicar o que me pierdo algo…
Cada persona, y los programadores no dejan de ser personas, desarrolla a lo largo del tiempo diferentes sensibilidades. A base de cometer errores y sufrir por ellos, nos hacemos especialmente perceptivos a los síntomas que nos causan dolor. Un programador de lenguajes de la familia de C es capaz de notar la ausencia de un ; para terminar una sentencia en una pantalla plagada de símbolos. Alguien que trabaje con SQL habitualmente desarrolla un sexto sentido para no lanzar un DELETE que no lleve WHERE (normalmente tras el tercer incidente grave). Y así, cada uno enumerará sus ejemplos favoritos en los que ha desarrollado una aptitud sobrehumana para evitar inacabables pérdidas de tiempo.
Es esto, por encima de otros factores, lo que nos hace expertos en algo. Saberse de pe a pa todos los comandos UNIX habituales no te convierte en experto- es saber que nunca debes ejecutar killall en Solaris, pese a lo útil que resulta este comando en Linux lo que demuestra que has vivido tus propios vietnames- y has aprendido de ellos.
Una observación curiosa sobre las sensibilidades es que estas no se adquieren así como así. Uno de los motivos por los que creo que las enseñanzas en materias de programación deben ser eminentemente prácticas y rehuyo la formación por exposición- sean cursos, sea un compañero que escriba un documento descriptivo sobre un área funcional/librería/arquitectura, ya que en general son una pérdida de tiempo. Saber cómo funciona algo es relativamente fácil- se puede acelerar pero raramente es el problema. El problema es que cuando no tenemos sensibilidad en lo que hacemos, todo nos cuesta un orden de magnitud más. Lo que necesitamos es ponernos manos a la obra y tener alguien con la sensibilidad que nos hace falta mirándonos por encima del hombro y arreándonos un sopapo cuando vayamos a hacer algo estúpido, o que nos desatasque cuando seamos incapaces de ver el bosque.
La sensibilidad no es más que un atajo heurístico que nos permite ser eficaces antes de haberlo aprendido y comprendido todo en el más absoluto detalle (algo frecuentemente necesario, pero no siempre), y que aún cuando somos expertos en algo, seguimos aplicando por su efectividad.
Seamos sensibles. Transmitamos nuestras sensibilidades. No perdamos el tiempo de entrada, lancémonos de cabeza- démonos golpes que desarrollen nuestra sensibilidad o aprovechemos los golpes que se han dado otros antes.
Según Steve Yegge, un día Jeff Bezos, el capo de Amazon, envió un memorándum interno que venía a decir:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6) Anyone who doesn’t do this will be fired.
Este puñetero memo, y toda la gente que lo ha leído y ha aplicado el silogismo falaz de “En Amazon son unos cracks, en Amazon siguen este credo ergo si yo sigo este credo seré un crack” son un maldito dolor de cabeza.
Conste que no es que considere que las APIs sean una plaga a exterminar, ni mucho menos, pero debería olernos mal las sentencias absolutistas y los razonamientos de talla única. No todos los entornos son iguales, ni se enfrentan a los mismos problemas- y por tanto lo que funciona para unos, no funciona para otros. Adicionalmente, es difícil razonar que la aplicación ciega de esta doctrina es lo que ha llevado a Amazon al éxito y estoy seguro que no en pocas ocasiones mejor les hubiera ido siendo un poco más críticos.
La realidad, maldita ella, siempre se interpone a los ideales. Implementar una API tiene un coste en tiempo que no siempre es amortizable por sus beneficios. Conste que el hecho que no se vaya a usar la citada API tampoco es un argumento tan fuerte en contra de estas- el hecho de añadir una API usable nos fuerza a hacer el código modular lo cual es un valioso beneficio en sí mismo que si puede valer la pena- aunque es perverso el argumento de ser modulares porque tenemos que implementar una API: seamos modulares porque está bien ser modular sin necesidad de dichosas APIs.
Pero más allá del coste de implementar la API, la imbezosidad esta muchas veces lleva a auténticos pantanazos donde dos departamentos de la misma empresa fuerzan que dos sistemas se comuniquen a través de una API. API a la que muchas veces no se le dedica el tiempo necesario y que no permite alcanzar todo lo que se necesita de una forma eficiente y efectiva, que fuerzan a implementar soluciones chapuceras que no benefician a nadie, cuando habría alternativas perfectamente efectivas.
Bezos prohibe explícitamente, por ejemplo, el acceso a base de datos entre aplicaciones- quizá la situación más común en el que la gente se arma del memorándum para tomar decisiones insensatas. “¡Os daremos una API maravillosa!”, “¡Permitirá que saquéis toda la información que necesitéis!”, “¡La extenderemos rápidamente con vuestras nuevas necesidades!”. Mentiras y más mentiras. Cuando yo te podría escribir un par de selects que me sacan todos los datos que necesito fácil y eficientemente, tú me darás una API castrada en la que tendré que hacer numerosas llamadas de API para obtener los mismos resultados y que se tendrá que extender cada vez que surja un nuevo requerimiento. Eso si lo extiendes, porque “oh, lo siento, ahora estamos liados con otra cosa” hará que no se pueda implementar tal requerimiento en no pocas ocasiones.
Sí, desde luego, esto no es algo universal tampoco- como tampoco lo es la doctrina de las API. Si son los mismas personas las que implementan la API y la consumen, o hay una suficiente coordinación de objetivos, esto no tiene por qué ser un problema. Sin embargo, muchas veces lo es. Y es precisamente para levantar vallas entre vecinos uno de los motivos con los que se esgrime el credo- consciente o inconscientemente.
¿La solución? No sigas ninguna regla ciegamente. Como siempre.
Es indiscutible que el cine de animación ha observado un gran resurgimiento en los últimos tiempos y muchos de sus pelotazos han sido universalmente aclamados como grandísimas películas para niños y adultos. Un servidor debe admitir que siempre se ha sentido un poco al margen de esto y que salvo honrosas excepciones (casi que me limitaría a WALL-E, el primer acto de Up y si me he de estirar cual Elasti-girl, los Increíbles) me deja en general bastante frío.
Obviamente en su momento vi los trailers y promociones de ¡Rompe Ralph! en su momento, y por supuesto secuencias como la reunión de villanos anónimos con un fantasma de Pacman, Zangief, Bowser y otros me atrajeron como un bicho a la luz, pero por un motivo u otro acabé no viéndola en el cine. Posteriormente, por casualidades del destino, Renfe se dignó a ofrecerme a Ralph en vez de una tercera proyección en dos semanas de Star Trek: en la oscuridad.
¡Y qué feliz coincidencia!
Pocas veces me he quedado tan enganchado a una butaca mirando una pantalla minúscula forzando el cuello. ¡Rompe Ralph! es una maravilla de principio a fin. Parte de la más que jugosa premisa de que los personajes de los juegos de un salón recreativo tienen vida propia y se ocupan de sus asuntos fuera de sus “horas de oficina”- en este caso el Ralph del título es el malo de “Repara Félix Junior”, cansado de su rol como villano que decide ser el bueno por una vez. Este argumento, que podría haber resultado plano y simplón se transforma en toda una epopeya gracias a un trabajadísimo guión que si bien tampoco es que sea un laberinto inacabable de giros y sorpresas, es más elaborado de lo que uno pensaría y consigue aprovechar todo el potencial del planteamiento y de las generosas licencias que permiten que aparezcan multitud de personajes de videojuegos reales.
La historia combina los personajes de tres juegos inventados- el “Repara Félix Junior” de Ralph, “Hero’s Duty”, un shooter de marcianitos y “Sugar Rush” un Mario Kart aún más almíbarado si cabe- hilvanandos las historias de sus personajes con habilidad, tirando de clichés y dejes videojueguiles y con alguna que otra hábil subversión. Además los personajes tienen unas personalidades más que tridimensionales que ayuda a darle una tremenda dimensión humana a la película- Ralph en toda su apariencia caricaturesca tiene toda una dimensión trágica y una humanidad que ya quisieran para sí muchos personajes de sesudos dramas- él y los demás dotan a la película de una emotividad sorprendente y poderosa.
En el aspecto técnico, la animación es absolutamente sobresaliente y destaca en su completa virtuosidad en el paso a las tres dimensiones de los juegos bidimensionales. Cada videojuego tiene una estética trabajadísima que se combinan con fluidez con el estilo visual de otros tantos videojuegos reales; los personajes de juegos más retro se maravillan de los gráficos de los juegos de última generación, pero encajan perfectamente conservando cada uno su propia personalidad sin mayor problema.
La banda sonora así mismo recorre con gracia todos los lugares habituales videojueguiles, e incluso las dos canciones-estrella-invitada, una de Rihanna y la de los créditos de Owl City en VO y Auryn en España no desentonan.
En definitiva, una película sobresaliente a la que es muy difícil no querer colocar en los olimpos cinematográficos. Hasta los no videojueguistas disfrutarán de lo lindo y los rompe-joysticks sobra decir que alcanzarán en el extásis (y hay un par de guiños ahí que sacarán ovaciones cerradas). Peliculón.
