Pseudorebujitado: Frozen

La compañía famosa por leyendas urbanas criogénicas saca Frozen, un cuento infantil sobre princesitas Disney gay-friendly que lanzan chuzos de hielo por la mente que se torna megapelotazo. El mal sabor de boca de Brave no me auguraba mucho, pero…

El argumento de Frozen es un poco irregular. Por una parte, es original; los temas subyacentes sorprenden dentro de lo que es Disney línea dura (Pixar es Disney pero no es Disney, no sé si me entienden) y no sorprende que se le hayan dado las lecturas que se le han dado- si es lo que pretendían sus creadores no sé si lo podremos saber. Es refrescante que no sea la enésima repetición de lo de siempre y se agradece. Por otra parte, el argumento es a menudo incoherente y sirve de mero vehículo para la película; va cogido por los pelos para llevarnos a situaciones y escenas concretas y el recorrido hasta ellas flojea un poco.

Sin embargo, y a diferencia de Brave donde los puntos álgidos del itinerario no eran tan álgidos y los transbordos eran soberanos bodrios, aquí las atracciones turísticas son fabulosas y los intermedios, completamente soportables.

La aurora boreal de Frozen es Let It Go, un temazo desatado que lógicamente arrasó al Happy de Mi Villano Favorito II y la cancionucha de Her en los Óscar. Es una de esas canciones que la Disney hace para llevarse a casa la estatuilla y en este caso, se salen. No sólo la canción en sí y la interpretación (la tal Idina Menzel colecciona premios de musicales, y se nota), sino que el numerito palacio de hielo es una exhibición del mejor 3D que el dinero puede comprar.

La animación es impecable como debe ser. Los programadores encargados de dibujar hielo y modelar nieve deben haber costado dinero, pero están más que amortizados. La estética nórdica y toda esa cantidad de hielo y nieve funcionan de maravilla- el hielo captura la luz virtual y le da a la película el toque sobrenatural que necesita.

Los personajes no acaban de cuajar. Los protagonistas son algo sosos y los villanos no dan mucho miedo, pero bueno, supongo que la película no va de eso. Los dos secundarios que destacan son el muñeco de nieve que quería ir a la playa y Oaken, el comerciante (encarnado por un animador de la peli), que están metidos un poco con calzador, pero que dan las secuencias más graciosas de la cinta.

En fin; si bien no es una cinta completamente redonda, Frozen vale el precio de la entrada sólo por poder desafinar a gritos Let It Gooo al acabar. Recomendable.

El viento renquea, pero remonta

Uno tiene una relación irregular con Studio Ghibli. Si bien creo que Porco Rosso es una obra maestra del cine y soy bastante fan de Chihiros y Totoros, otras como La Princesa Mononoke me dejan frío (por no hablar de Cuentos de Terramar, de Goro hijo de Hayao, que me deja profundamente dormido).

Esta “El Viento se Levanta” trata la historia de Jiro Horikoshi, el diseñador del caza Zero que hizo estragos en las filas aliadas en la Segunda Guerra Mundial. Con mis antecedentes con películas aéreas de Miyazaki, pintaba bien la cosa.

Curiosamente, a mi me funciona más la parte romántica (la historia de Jiro con su esposa) que lo de los avioncitos. Los avioncitos es más místico que otra cosa, intentando establecer una conexión entre Jiro y un diseñador de aviones italiano de nombre Caproni. La animación marca Ghibli le da atractivo a la cosa, pero le falta algo para acabar de emocionarnos. La peli, dentro de una controversia sobre una supuesta falta de mensaje antibelicista, retrata los diseños de Jiro en poco más que vuelos de prueba, apenas mostrando escenas de combate.

Quizá esto sea para mejor, aunque parece que mucha gente no capta igualmente el mensaje pacifista de la película.

Para mi el hilo argumental de Jiro con su mujer es el que consigue mayor emotividad. Si bien el argumento es un poco surrealista (y curiosamente, parece que se desvía bastante de los hechos reales, que a mi me hubiesen parecido más interesantes para adaptar), el tratamiento de Miyazaki de la historia es realmente fantástico y alcanza momentos de una lírica y dulzura realmente entrañables.

La suma de estas dos desiguales partes equivale a una película que está bien pero se nos antoja un poco corta para la despedida de Miyazaki. Técnicamente es sublime como toda su obra, y ya sólo por eso merece la pena pagar por verla en pantalla grande, pero le falta un pelín para volverse imprescindible.

Tengo dos móviles

En junio de 2011 me compré una Blackberry Bold 9780. En aquel momento, el iPhone 4 era el iPhone a la venta, Nokia sacó el N9 con Meego y Gingerbread era la última versión de Android para teléfonos. La Blackberry me costó 139€ (a base de puntos), sustituyendo un Nokia C5 que me encantaba pero que comenzaba a quedarse atrás.

Mi experiencia táctil anterior con un LG Viewty (modelo de 2007, coetáneo del primer iPhone) me hizo decantarme por un teléfono con teclado. No tardé en acostumbrarme a él y disfrutar de mi primer smartphone real.

Hace unas semanas, Feedly rompió el interfaz web que me permitía usarlo con relativa comodidad en mi Blackberry- unos ajustes en el comportamiento del viewport lo hicieron completamente inusable, con lo que perdí mis dos horas de metro diarias como mecanismo para ponerme al día de noticias y novedades.

Habiendo jugado bastante con un Nook y un Xperia Mini Pro, me resigné a reconocer que vivir sin un dispositivo Android o iOS (o incluso quizá Windows Phone) era una lucha cuesta arriba. La verdad que mi Blackberry de casi 3 años de edad seguía cumpliendo mis necesidades ampliamente pese a sus defectos, así que estuve bastante tiempo valorando alternativas.

Estaba bastante claro que la mejor opción era un dispositivo Android- no soy un gran fan de Apple y Windows Phone no fue una opción que consideré demasiado (¿está maduro ya? ¿Google le hace caso?). Me plantée algún tablet pequeño (7” es demasiado para llevar en mis bolsillos), haciendo tethering con la Blackberry, pero el tethering Bluetooth (BB OS 7 soporta tethering wifi, pero mi dispositivo es BB OS 6 y por tanto la única opción es Bluetooth) es frágil y en cualquier caso, la batería de mi Bold no creo que se lo tomase muy bien, así que me incliné por algo con SIM. Realmente no hay muchas opciones, y al final se redujo a un Galaxy S III rebajado o al Moto G- seguramente los mejores móviles en la franja alrededor de los 200€ (el S III estaba por 229€ con un cupón de Rakuten recibiendo además 45€ en puntos, el Moto G comienza en 150€ por la versión con 8Gb).

El Moto G me gustaba más por su tamaño, pero a nivel de especificaciones el S III se impone en casi todo lo demás, especialmente cámara y batería, así que no con muchas dudas, me lancé a ser un zombie de Samsung más.

Provisionalmente, le he puesto una SIM nueva de Yoigo (tarjeta, 7€/mes, 600Mb) y sí, soy un pringao que lleva dos móviles encima. Tengo dudas sobre las capacidades de comunicación de un dispositivo con pantalla táctil y prefiero no saltar al vacío.

Las impresiones del S III son las que uno esperaría. Enorme, pero delgado. Usar un Android potente (el S III tiene dos años, sí, una barbaridad en móviles, pero recordemos que fue el buque insignia de Samsung) es una revelación acostumbrado a BB OS- un navegador que puede con todo (el de BB OS es muy bueno con páginas adaptadas a móviles, pero le puede cualquier cosa página no móvil con una tonelada de anuncios e imágenes) y con soporte de primera línea de aplicaciones.

Sí, aplicaciones. Realmente debo decir que las aplicaciones importantes para mí (mensajería, redes sociales, mapas [aunque el soporte de Google Maps empezaba a preocuparme], etc.) están para Blackberry, y que no estoy tirando casi nada de aplicaciones en el S III (salvo Feedly, claro- pero hasta que lo rompieron, la versión web me iba aceptablemente bien), pero se nota que las apps de Blackberry están… descuidadas.

La cámara también se nota- con mi pésimo pulso sacar una foto con la Blackberry decente era un desafío- con el S III es todo mucho más sencillo.

Por último, aunque cuando lo compré la batería de la Blackberry era fantástica (un día de uso intensísimo sin problemas, fines de semana de uso ligero sin recargar), dos horas de uso intensivo en el metro con poca cobertura durante tres años destruyen cualquier batería (tanto, que me compré una sin marca- pero da más o menos el mismo rendimiento que la batería de marca usada). El S III tira de su enorme batería y no sufre para acabar el día, mientras que la Blackberry la tenía que cargar durante el día para que no me dejase tirado volviendo a casa (como curiosidad, ahora que no le doy tanto tute a la Blackberry, aguanta mucho mejor).

Pero…

Sí, teclear en cristal sigue siendo un despropósito. No tanto como pensaba, pero entre la Blackberry donde puedes teclear lo que quieras sin mirar a la pantalla, alternando idiomas, metiendo puntuación compleja, etc. y el agónico teclado táctil, sigue habiendo un mundo de diferencia. El swipe que lleva el teclado por defecto y el buen soporte multi idioma ayuda bastante, pero tiene puntos bastante débiles- sobre todo la puntuación y cuando te apartas mínimamente del diccionario. La Blackberry aguantaba hasta usos muy exigentes como usarla de terminal SSH- algo que requiere del uso de modificadores, combinaciones de teclas y palabras “raras” era algo que soportaba de maravilla, mientras que con un teclado táctil se puede hacer algo… pero es muy incómodo.

También se nota, y mucho, la atención que requiere teclear en pantalla táctil. Mientras que con la Blackberry puedes escribir andando por la calle casi sin prestarle atención, el S III dificulta muchísimo esto.

Por otra parte, el tamaño, que sí importa. No tengo las manos grandes, pero tampoco pequeñas, y el uso a una mano es terriblemente poco práctico. El ridiculizado trackpad de la Blackberry es realmente una virguería ergonómica. Se usa perfectamente con una mano, tiene muchísima precisión y para ciertos movimientos (e.g. scroll continuo), es mucho más cómodo. El S III a una mano es harto incómodo y a dos manos, hay tareas en las que pierde claramente contra el cutre trackpad. Quizá el más pequeño Moto G hubiese sido mejor en este sentido, pero…

Sí, la anticuada Blackberry es mucho más… cómoda. El teclado ayuda enormemente en la faceta “comunicativa” y alguna más esotérica, y el trackpad resuelve algunas mecánicas muy bien (selección y movimiento dentro de texto, etc.). Los atajos de teclado y búsqueda son la guinda- es mucho más cómodo teclear calc y hacer click con el trackpad que ir al menú aplicaciones, hacer swipe hasta encontrar la calculadora y pulsar el icono.

Combinar las ventajas de ambos dispositivos parece el camino a seguir, al menos de momento, aunque me costará 7€/mes (e igual los 600Mb se me hacen cortos).

Lo curioso del tema es que mi netbook sí ha sufrido un inesperado desplazamiento en su “uso en el sofá”. El S III es un digno contrincante: tiene más resolución de pantalla (¡1280×720 contra 1024×600!), 1Gb de RAM (mi netbook ahora tiene 2Gb, pero durante mucho tiempo tuvo 1Gb) y hasta reproduce mejor vídeos de Youtube. Obviamente, el teclado del netbook apabulla aún más que el de la Blackberry, pero aún así… hay días que no arranco el netbook.

La conclusión es que por favor, que alguien saque un móvil Android con el formato Blackberry clásico. Tenía esperanzas en que Lenovo comprase Blackberry, pero la política se ha puesto en medio. Igual ahora que Lenovo tiene Motorola, sacan un móvil Thinkpad con teclado, pero eso parece un sueño ahora mismo. Aunque la nueva directiva de Blackberry parece que se ha dado cuenta que sus nuevos formatos cojean (los BB OS clásicos siguen vendiendo más que los nuevos), veo muy complicado que le den la vuelta a su situación, e impensable que adopten Android.

Mientras, seguiré en esta curiosa vida con dos móviles esperando a ver como se desenvuelven los acontecimientos.

Números son números

Por hacer algo, he anotado el calendario de La Liga que queda para los 3 primeros y la clasificación de sus rivales aquí.

Cada uno lo interpretará como quiera. Yo opino que el que venza el Real Madrid – Barça se lleva la liga, pero quien quiera inventarse fórmulas, que se entretenga.

* nota, sé que restar dos porcentajes no tiene sentido…

Ad nauseam, que en latín quiere decir ad infinitum

Anteriormente nos preguntábamos sobre las repeticiones de los episodios de Los Simpson. Hoy, presa del aburrimiento, me preguntaba en general qué serie se repetía más veces.

Los canales infantiles son los reyes del mambo, con Hora de Aventuras al frente y sus 87 emisiones del episodio “Pánico en la fiesta de pijamas”- entre diciembre de 2011 y junio de 2013 fue emitido más de una vez por semana. De los 113 episodios que se han visto por aquí, 24 han sido emitidos más de 50 veces y sólo 15 no han sido repetidos.

Fuera de los infantiles, Castle (emitido por FDF, Cuatro y Divinity) se lleva la palma. “Derribo”, “Nikki Heat” y “Última Ronda” han sido emitidos 27 veces cada uno (repartidos entre Cuatro, FDF y Divinity 17-7-3, 18-7-2 y 17-7-3, respectivamente). En general los episodios de Castle se emiten como una vez al mes desde su primera emisión.

La Que Se Avecina, Aquí No Hay Quién Viva, Dos Hombres y Medio también cuelan un episodio (no 3) con 27 emisiones.

Los Simpson, por supuesto, son los primeros en cuanto a series de animación “para adultos”, con “El infilBartado” y sus 25 emisiones, dejando a las series de Seth McFarlane en ridículo (el episodio 66 de Padre made in USA y Vivir y morir en Dixieland de Padre de Familia se quedan en 9 repeticiones).

Los datos cubren más o menos desde mediados de diciembre de 2011 hasta hoy, con un hueco en agosto-octubre de 2013 por problemas técnicos.

Ella está ahí

Ayer nos fuimos a ver “Her”, la supuesta comedia romántica de chico conoce a inteligencia artificial que está arrasando con la crítica y llevándose un buen puñado de galardones.

La peli va de eso, de Theo (Joaquin Phoenix), un depresivo escritor de cartas íntimas que se instala una inteligencia artificial con la que va intimando a lo largo de la película. Se trata de la cuarta película de Spike Jonze (¡sí, sólo cuarta!), un especialista en virguerías visuales (véanse sus videoclips para Bjork) que dio el salto al cine con la rarísima Cómo Ser John Malkovich cuya particularísima premisa desembocaba en una cinta más que sorprendente.

Her parece ir con derroteros similares- su idea inicial no es tan original (vaya, ha sido hasta el argumento de un episodio de Big Bang Theory) pero tiene un obvio potencial del que aún se pueden sacar unas cuantas películas interesantes. Lamentablemente, mientras que anteriormente Spike contaba con Charlie Kaufman para el guión de Malkovich, en Her se lanza a escribir su primer guión y, en mi opinión, fracasa estrepitosamente. Una lástima, dado que Kaufman fue el guionista de la impecable Olvídate de Mi, y uno no se imagina hasta dónde había podido llevar esta cinta.

Her malgasta su premisa interesante más que nada porque… no sabe qué hacer con ella. El drama y el conflicto vienen y van caprichosamente y sin explicación. Las cosas pasan un poco porque sí, de una manera inconexa e incoherente, torpemente introduciendo situaciones y diálogos que esporádicamente funcionan, pero que no cuajan en ningún momento, dejando un argumento completamente artificioso y torpe.

Esto lastra la película mortalmente- el resto de sus virtudes y defectos son bastante irrelevantes. Joaquin Phoenix sostiene bien la película a pesar de que su mostacho está en primer plano algo así como el 75% del metraje. Pese a lo caricaturescamente patético que pintan a su Theo, aguanta bien el tipo y no pierde la credibilidad más que en un par de ocasiones (y vaya, a todos nos pone muy nerviosos las actualizaciones del sistema operativo). No oímos a Scarlett, sino a su dobladora, que no creemos que le ande muy a la zaga- Samantha pese a ser una voz incorpórea es un personaje perfectamente creíble sólo lastrado por los volantazos que tiene que dar para seguir el irregular guión.

La factura de la película es más que correcta- gran parte de la película es el anuncio de Apple más largo de la historia, que posiblemente ayudará a algunos a comprender por qué los usuarios de iPhones y demás están tan enamorados de sus aparatitos; puede gustar o no gustar pero innegablemente está todo muy bien hecho. La peli recuerda a ratos a Lost in Translation, la mencionada Olvídate de Mi y otros pelotazos del cine moderno, y evoca cuando debe evocar- soledad, amor y desamor son sensaciones que la peli consigue transmitir a través de imágenes, una virtud más que valorable y no tan habitual como debería.

Lamentablemente, como dijimos, todo esto da igual por lo chapucero del argumento- la peli plantea preguntas interesantes, pero lamentablemente las responde (cuando podría no hacerlo) de una manera bastante pobre, y la peli vaga sin rumbo de una manera que al que escribe se le hizo interminable mientras pensaba qué podría haber hecho un buen guionista con ella.

En definitiva, para mi, sobrevaloradísima (venga hombre, ¿nominada a tres Globos de Oro y se lleva precisamente sólo el de mejor guión?) pero bueno, habrá quien la disfrute.

NO quiero construir algo hermoso

El proyecto con más estrellitas ahora mismo en Github es el famoso Bootstrap (con más del doble de estrellas que su más inmediato perseguidor, jQuery), ese framework CSS beautiful y awesome que nos asegura que nuestra web tenga un aspecto único e individual como un extraordinario copo de nieve.

Viendo esto, me entra la sensación de que de alguna manera hemos abandonado el pasado sombrío donde los proyectos de software fracasan a raudales, que se pasan en costes y tiempos y que no tienen la mitad de la funcionalidad que requieren sus usuarios. Que encontrar la perfecta combinación de iconos, tipografías y widgets es la mayor preocupación ahora mismo- el backend es un problema resuelto y el frontend es donde tenemos que enfocar nuestros esfuerzos.

O eso, o somos seres simples e importar Bootstrap en nuestro proyecto (¡oh, no, perdón! Usar un framework que nos trae Bootstrap y media docena de opinionated awesomeness en una simple operación) y asegurarnos que todo tenga un borde redondeado es más entretenido y fácil que poner una funcionalidad de búsqueda en nuestra aplicación que sirva de algo. Implementar un wireframe de un autoproclamado experto en UI/UX nos dará mucha más usabilidad que asegurarnos que nuestro interfaz reporte errores al usuario de una manera clara y entendible.

Es una preocupante tendencia ahora mismo dedicar unas cantidades desproporcionadas de tiempo a la parte visual en detrimento de hacer cosas que funcionen, sean robustas y rápidas. Nuestra web cargará a toda pastilla en nuestra conexión de fibra con el flamante y bonito portátil recién estrenado- ¿a quién le importa el tipo que tira de 3G con un móvil de hace un par de años? Estamos lejos aún de que el desarrollo de hasta aplicaciones moderadamente simples sea rápido, eficiente y barato, pero hemos pulido hasta el infinito las técnicas para darle un bonito aspecto.

Sé perfectamente que soy un caso extremo- el CSS de este blog son 20 líneas (y son 20 líneas más de las que me gustarían), y hasta hace poco tenía un sistema en producción moderadamente popular cuyo backend tenía 0 CSS (de cuya austeridad, por cierto, en una empresa artística, no se quejaba nadie). Soy consciente de la necesidad de vender y que la apariencia es una de las claves para ello, pero me temo que en 10 o 20 años nos preguntaremos por qué narices le dedicamos tanto tiempo a inflar la burbuja y no dedicarnos a resolver los problemas de verdad.

¿Por qué el CRUD es importante?

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:

  • Poder crear fácilmente pantallas de listado de entidades, con filtrado, ordenación, paginado y búsqueda; que dé la opción de edición directa sobre el listado y que permita mostrar/editar información de entidades relacionadas
  • Poder crear fácilmente pantallas de edición de entidades, que tengan widgets adecuados para los tipos de datos que necesitamos, y que permita editar directamente entidades relacionadas, dando un interfaz adecuado a las claves foráneas y relaciones de todo tipo de cardinalidad y complejidad
  • Poder navegar ágilmente entre entidades relacionadas
  • Un sistema de permisos completo que permita restringir con granularidad por grupos de usuario hasta los niveles de columna y fila (i.e. qué registros puede editar cada usuario, y de cada uno, qué atributos)
  • Un sistema de workflows que permita manejar diversos estados para cada entidad, aplicar permisos sobre las transiciones y disparar eventos sobre los cambios de estado
  • Un sistema de auditoría de cambios que permita ver los históricos de modificaciones y si es factible, restaurar versiones anteriores
  • … y sobre todo, que todo lo anterior sea extensible, ya que siempre, siempre, necesitaremos más de lo que está previsto

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…

Código y sensibilidad

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.

Integración, APIs y no me toques los bezos

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.