Hay otros como él, pero éste es el mío
He estado remozando mi montaje de cosas conectadas a la tele y quería aprovechar para recoger unos cuantos pensamientos sobre el tema.
Uno, destacar ese gran desconocido que es el HDMI-CEC (que cada fabricante renombra, no sea que la gente se pueda entender lo práctico que es). Es un protocolo de señalización sobre el cable HDMI que permite cosas como que el mando a distancia conectado al televisor pueda controlar otros dispositivos conectados al televisor (como una Playstation o una Raspberry Pi) o que dispositivos conectados al televisor puedan encender el televisor cuando se activan (como un Chromecast que al recibir un vídeo de un móvil puede conectar el televisor y saltar a su canal). Sin demasiados problemas, permite reducir el uso de mandos a distancia y aumentar la comodidad de ciertos dispositivos.
Mi televisor ahora mismo tiene conectados:
Cabe decir que este hardware de Steam me ha dejado bastante boquiabierto, por su audacia y por lo bien pensado que está; son muy muy fáciles de hacer funcionar, de momento no les he encontrado ningún problema de usabilidad y hasta tienen un par de sorpresas ocultas (se puede añadir un mando de PS3 al Steam Link en un periquete y funciona casi perfectamente, y por supuesto, soporta HDMI-CEC).
Todo esto aderezado con una regleta que encontré en Amazon con 8 tomas de corriente y 5 USB, que me permite alimentar el Chromecast y la Raspberry por USB sin un cargador adicional, a parte de cargar los mandos de la Play y demás de una manera muy práctica.
El único problema es que tengo cuatro dispositivos HDMI y mi televisor sólo tiene 3 entradas, con lo que ahora mismo el montaje me cojea un poco (tengo sin conectar la PS3 que es lo único que reproduce Movistar+), pero todo se andará.
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.
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.
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 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.
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.
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.
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.
(sobre el TIOBE de Agosto 2015, básicamente).
Java: junto con PHP, uno de los lenguajes más denostados del mundo. A diferencia de PHP, probablemente una de las mejores opciones disponibles para hacer software grande y complejo y no morir en el intento. Hay una escasez de lenguajes de tipado estático populares en el mundo y si no nos queremos ir a Microsoft, Java cuenta con un ecosistema brutal, da un rendimiento sobresaliente y se aprende fácilmente. Pero no es chachi.
C: el lenguaje que todos adoramos hasta que lo tenemos que usar en serio. Afortunadamente es el siglo XXI y la mayoría de nosotros no tenemos que recurrir a él. Eso sí, le debemos todo y aunque ya no domina el mundo, sus descendientes han heredado el trono.
C++: uno de esos lenguajes que siempre quiero aprender pero con el que nunca me pongo. El C++ auténtico se desliza entre la elegancia y potencia y el jeroglífico más ofuscado. Lamentablemente, no hay tiempo en esta vida para aprender todo lo que se necesita para programar bien en C++.
C#: el Java mejorado de Microsoft. Pero aunque lo estén abriendo, para disfrutarlo plenamente aún cuesta dinero. Sí, sé que cuesta poco para lo que vale, pero habiendo opciones gratuitas, ¿por qué molestarse?
Python: de los débilmente tipados, mi favorito. Un diseño bastante sencillo y ortogonal, alguna rareza por ahí pero en principio la mejor herramienta en muchas situaciones. Y si uno desarrolla web, el admin de Django es lo más disruptivo que existe en el terreno.
Objective-C: hasta Apple ya se ha dado cuenta que debe morir.
PHP: el horror. Cada característica de PHP cuenta con un problema fundamental, pero la gente insiste. Pero existe WordPress, Magento y tantos CMSs que es inevitable caer en sus redes de cuando en cuando.
VB.NET: C# con sintaxis de BASIC. No, gracias.
JavaScript: el lenguaje más accidentalmente popular del mundo. En realidad no es tan malo (salvo los callbacks en callbacks de callbacks) pero tampoco es bueno, y mucho menos como para que se intente que conquiste el mundo.
Perl: aguanta ahí, así como sus fieles. Excelente para ofuscar, confundir y compactar- aún no le he encontrado otra virtud.
Ruby: el sucesor de Ruby. Tiene su propio estilo de ofuscación- la maleabilidad es como la etimología indica, mala.
Haskell: posiblemente, el lenguaje más académico que es medianamente conocido y que goza de un buen ecosistema. Sus virtudes son incontestables, pero las profundidades teóricas en las que hay que sumergirse para entender sus conceptos más básicos es aterradora. La evaluación “perezosa” permite a su vez expresar algoritmos de maneras inimaginablemente elegantes pero hace que razonar sobre el tiempo y espacio de ejecución de un algoritmo sea doloroso.
Bash: posiblemente el mejor lenguaje de propósito específico que existe. Lo que se puede conseguir con unos comandos y unos pipes en un par de líneas y el mejor REPL del mundo hace que sea la herramienta más rápida para un número no despreciable de problemas. Eso sí, el lenguaje que peor escala del mundo.
SQL: el único lenguaje con un movimiento anti oficial. El modelo relacional es de momento el mejor sistema modelado que existe, las bases de datos relacionales de las plataformas más evolucionadas y eficientes del mundo y sin embargo… nadie quiere escribir SQL, todo el mundo prefiere escribir 10 veces más código en lenguajes menos apropiados para lo que necesitan.
Aunque muchas veces digo que soy usuario de Linux (desde 2002 en casa, 2011 en el trabajo), la verdad es que lo que soy es usuario de Debian (también uso CentOS en algunos servidores).
Debian aspira a ser el sistema operativo universal- su versión “testing” contiene la friolera de 58.000 paquetes de software, que incluyen un entorno tipo UNIX y el kernel de Linux, todo en un formato fácilmente instalable. Cantidad no equivalente siempre a calidad, pero al menos para mi, Debian cubre prácticamente todas mis necesidades informáticas con un coste mínimo en tiempo y dinero: en un momento tengo acceso a la mayoría del software que necesito en un entorno eficiente y agradable.
Sin embargo, el mundo de la informática de escritorio sigue dominado por Microsoft Windows. Es un sistema que he usado bastante y realmente tiene muchas virtudes, pero para mi su mayor defecto es que no es Debian. Windows dispone de mucho software interesante que no se puede usar en un sistema Debian, sí- pero Debian también tiene mucho software que es una lata utilizar en Windows- especialmente el que compone el entorno “UNIX” de GNU (los shells y utilidades, que uso intensivamente).
Son dos filosofías completamente diferentes. Debian aspira a empaquetar todo el software libre del universo (e incluso no libre) y Windows te proporciona un sistema operativo y unas migajas de software para que te busques la vida.
¿No podemos tener lo mejor de cada mundo?
Hasta ahora, obtener los beneficios de Windows y Debian suponía mantener dos sistemas. Yo personalmente tengo máquinas virtuales Windows que utilizo para acceder a software que sólo está disponible en Windows- como Microsoft Office, pero en general evito en la medida de lo posible usar Windows porque es un tostón trabajar dentro de una máquina virtual y por tanto aprovecho poco todo el software disponible para Windows.
Ahora bien, Microsoft está cambiando y comienza a contemplar Linux como algo diferente a un enemigo a destruir. Curiosamente, Microsoft parece escoger Debian cuando comienza a acercarse a Linux (sin ir más lejos, han sacado un contenedor Docker para ejecutar aplicaciones de ASP.NET que es Debian Wheezy).
Por otra parte, Debian está preparada para correr bajo otros sistemas operativos. Sin ir más lejos Debian GNU/kFreeBSD es Debian corriendo sobre FreeBSD. También anda por ahí un intento de ejecutar Debian sobre Hurd, el kernel de GNU que quizá algún día sea relevante.
¿Por qué no Debian GNU/Windows?
Existen “distribuciones” para Windows, como por ejemplo Cygwin y MinGW/MSYS, que traen mucho del software GNU y del que incluye Debian, pero que palidecen en comparación con Debian- mucho menos software y mucho menos cariño en su mantenimiento.
No existen imposibles para correr Debian sobre Windows- se requeriría un enorme esfuerzo y hay aún muchas diferencias políticas a limar, pero un Windows, con su enorme soporte de hardware y el acceso a mucho software importante, con un entorno Debian encima sería un entorno que me tentaría seriamente a abandonar Linux.
En este mundo extraño con un Microsoft desconocido que saca software para sus competidores y que emplea Linux… no es algo completamente descabellado.
…
Postdata: soy plenamente consciente que OS X sería una alternativa a Windows en un escenario así. Sin embargo, debo decir que prefiero Windows. Apple y su entorno comienza a disgustarme más de lo que me disgustaba Microsoft. Y desde luego, creo que Apple sería infinitamente menos cooperativa.
La subcultura, friquismo, cosa geek, etc. parece estar de moda últimamente. La tecnología cobra cada vez más importancia y se infiltra hasta puntos insospechados hasta hace poco en el día a día de la gente corriente. Famosos de la informática como Jobs o Zuckerberg son celebridades del calibre de muchos deportistas, actores y músicos. Como no podía ser de otra manera, esto hace que las artes- literatura, cine, televisión… cada vez beban más del mundo tecnológico en sus obras. Sin embargo, hasta el momento (y hasta donde yo he visto), esto ha sido un fenómeno parcial- cultos de personalidad, referencias… poco más.
Halt and Catch Fire, sin embargo, es de las primeras obras relevantes para el gran público centrada argumentalmente en el mundo tecnológico- específicamente en la época de los clones del PC de IBM en los 80. Pese a tomarse licencias artísticas con la historia (la Cardiff Electric de los protagonistas es en gran parte Compaq, pero con bastantes cambios), HaCF no sólo puede considerarse histórica en el sentido que un biopic de Napoleón lo sería, sino que además entreteje la tecnología en el argumento (y además, con grandísimo acierto).
La historia se centra en un ex-comercial de IBM, Joe MacMillan (genialmente interpretado por Lee Pace… sorprendentemente el Thranduil del Hobbit o el villano de Guardianes de la Galaxia) que aterriza en una pequeña empresa de informática de Dallas planeando un producto clave de la época. Su personaje, magnético como debe ser, bascula entre lider carismático y traidor deleznable- de impecable traje caro pero con misterios y bagaje personal, se rige como el eje alrededor del cuál gira la historia. Le acompañan la programadora Cameron Howe (una tal Mackenzie Davis que no me suena de nada) y Gordon Clark [¿Gordon por Gordon Moore de Intel y de la ley epónima? Por Clark sólo me sale un fundador de SGI y Netscape], el experto en hardware (Scoot McNairy- al parecer sale en 12 Años de Esclavitud y Argo). En las dinámicas entre los tres rápidamente cobra protagonismo Donna, la esposa de Gordon, (una magnífica Kerry Bishé- al parecer es la segunda vez que interpreta a la esposa del mismo actor) que es mucho más multidimensional que el otro par (Cameron es excesivamente punk-manzanil para mi gusto- Gordon es un personaje más interesante pero que a mi no me llama mucho) y se lleva una buena cantidad de momentos estelares.
En el aspecto técnico (no hablo de la fotografía, ambientación, edición… todo impecable) no es sólo que HaCF capte la esencia de una época de la industria informática y trace un drama bastante sólido con ello, sino que además los aspectos informáticos se incorporan con total naturalidad y muchísimo acierto en el argumento. No es que HaCF no contenga gazapos técnicos de esos que me levantan del sofá con indignación (yo no he cazado ninguno al vuelo- indudablemente tiene alguno pero ninguna “licencia artística para matar”) sino que grandes éxitos del mundillo son puntos claves de los episodios (una educativa historia sobre los backups, hacer ingeniería inversa de la BIOS de IBM con un osciloscopio, abrir un disco duro y recuperar datos con acertadas alusiones a la FAT, …), haciendo que salte de mi asiento para aplaudir.
Con todo esto, HaCF nos cuenta una historia de pioneros y de los riesgos y daños personales que conlleva. Una historia con personajes trabajados, con sus claros y sus oscuros… con un argumento emocionante que hace que al acabar un episodio quieras ver inmediatamente el siguiente (por no hablar de la larga espera hasta la recientemente anunciada segunda temporada- parece que ha triunfado más allá de los ordenadorfílicos). Y además, ya era hora que alguien hiciese una serie para nosotros.
A todos nos gusta meternos en disquisiciones filosóficas inútiles, generalmente de la forma de “escoger el mejor X”. Para esta aburrida mañana de sábado, voy a hablar de mi lenguaje de programación preferido- un tema nada original.
Para empezar, ¿cuál es el criterio subjetivo para definir “favorito”?
Pues voy a escoger “productividad en su ámbito”; es decir, lo rápido que me permite resolver problemas en un área específica. Por supuesto este criterio está influenciado por los ámbitos en los que uno trabaja y requiere esta productividad.
Dentro de estos criterios, cada vez me es más difícil no responder “el bash”. Con el paso del tiempo he descubierto que para una amplia gama de situaciones, la mejor respuesta es indudablemente abrir un terminal y vomitar una sarta de bash y, muy frecuentemente, observar como funciona a la primera.
Podéis quejaros de que es un argumento un poco tramposo. Cuando uno habla de bash, nunca habla del bash en aislamiento- lo que hace realmente útil al bash es la infinidad de comandos que puede combinar- ya sea herramientas estándar como cut, grep, find, etc. como otras más evolucionadas como el curl u otras más esotéricas como el genial xmlstarlet- o incluso herramientas que son lenguajes de programación a escondidas, como el sed o el awk.
Pero argumentaré que el resto de lenguajes también son inútiles sin sus librerias- es sólo que el bash tiene una librería estándar descomunal que resulta ser cualquier cosa que se pueda ejecutar desde una línea de comandos.
El bash también cuenta con el concepto del pipe- presente en todos los shells pero sorprendemente ausente de la mayoría de los demás lenguajes de programación. El pipe es el pegamento perfecto para combinar cosas en el bash- la mayor parte de bashismos son cosas del tipo:
cat fichero | grep foo | cut -d , -f 3,5 | sed "s/^/foo:/" >resultado
; con esta sencilla primitiva combinamos sin fisuras cuatro comandos distintos- e infinitos más.
El conjunto del bash y el conjunto de herramientas estándar es tan armonioso que la mayor parte de manipulaciones de ficheros de texto, operaciones entre ficheros, etc. pueden resolverse con unos cuantos pipes y unos cuantos grep. Bash también nos permite definir funciones bastante ágilmente, cuenta con estructuras de flujo de control bastante majas, nos permite un primitivo control de errores y lo mejor de todo, permite reciclar nuestro código en scripts fácilmente reutilizables.
Si tuviese que escoger otro lenguaje favorito, por motivos similares escogería el SQL. SQL pelado, sí. Si puedes meter tu información en una base de datos relacional (y a menudo ya vive allí, porque las bases de datos son los mejores hogares para los datos), el SQL te permite con la misma brevedad que bash aplicar cualquier transformación a esos datos, extraer los que te interesan y sumarizarlos a gusto. En mi carrera profesional, pocas cosas se me han valorado más que la habilidad de extraer datos en minutos de una base de datos.
Lo más sorprendente de SQL es que, a diferencia del bash, es un lenguaje profundamente declarativo: raramente le decimos a SQL cómo tiene que hacer las cosas, sino que le decimos lo que queremos y él se preocupa de ejecutarlo de una manera eficiente (siendo capaz de realizar operaciones complejas sobre enormes conjuntos de datos en un periquete).
Detras del bash y SQL vendrían otros; Python por ser un lenguaje de propósito general claro y productivo (que además cuenta con Django- el framework para CRUD más productivo que he encontrado nunca)- Java por similares motivos, pero contando además con un rendimiento espectacular y características y herramientas esenciales para construir programas de gran tamaño, o Haskell, cuya elegancia matemática y su sorprendente modelo siempre me deja boquiabierto.
Pero antes de todos estos lenguajes populares siempre están esos dos- que muchos ni tendrían en cuenta como lenguajes de programación (pues son de ámbitos reducidos), pero que ejecutan funciones (específicas, eso sí- pero muy comunes) a la perfección.
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.
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.
