De calaveras, pingüinos y Pareto

Que faena lo de morirse. Y más para descubrir que, una vez en la Tierra de los Muertos, todavía te queda un buen trecho para alcanzar el Descanso Eterno. A pie son 4 años de nada… Por suerte, si has sido un tipo majo en vida, puedes optar por métodos de transporte bastante más cómodos, y sobre todo más rápidos, como coches o un tren bien lujoso. Manny Calavera es un triste agente de viajes que trabaja para el organismo que oferta dichos “packs” a los infelices que acaban de morir. Y Neus, mi pareja, quiere ser Manny. Así empieza todo.

Manny Calavera y el resto de esta pintoresca historia son parte del universo de Grim Fandango, laureada aventura gráfica de LucasArts de finales de los 90, obra del ínclito Tim Schafer. El actual estudio de este último, Double Fine, consiguió de Disney (actual dueño de la propiedad intelectual de LucasArts) los derechos para un remake de Grim Fandango allá por 2013. Hace poco, a finales de enero de 2015, Grim Fandango Remastered llega a las consolas de Sony y a PC (Windows, OS X y Linux). Neus, como buena aficionada a las aventuras gráficas clásicas, quiere jugarlo. Al tener un servidor su copia pre-comprada desde hace meses en GoG, sin DRM ni zarandajas, en principio nada más fácil que descargar la versión para Windows (el “portátil” de Neus corre Win 7), instalar y a jugar. En principio.

Grim Fandango Remastered

¿Windows? Esto va a molar…

Mejor sí, pero… ¿para quién?

Tantos años en la sala de máquinas, trabajando en las tripas de la bestia, sin contacto directo con los usuarios finales. Como tantos otros técnicos, mi percepción del producto siempre ha sido “de puertas para dentro”. En esas condiciones, tomas decisiones de diseño e implementación basadas en tu propio criterio, y tu criterio es técnico. “Mejor” es más eficiente, “mejor” es más correcto y elegante, “mejor” es más ingenieril. En definitiva, te esfuerzas en hacer mejor software, pero no tienes ni idea de si estás haciendo mejor producto. Porque una mejor ejecución no implica más aceptación, y un producto es tan bueno como su penetración en el mercado atestigüe. Eso, amigos, es lo que habré sacado en claro de estos años al frente de una empresa de producto. El cliente manda, ya sabéis.

Esto, tan evidente y de sentido común para todo aquel que haya tratado de llevar un producto al mercado, no es tema baladí. Muchas veces el mercado tiene opiniones sobre lo que tu producto debería ser muy alejadas de la tuya propia, y eso es complicado de gestionar. Maldito orgullo. A Steve Jobs le funcionaba bien lo de saltarse esa máxima a la torera, al resto de los mortales suele precipitarlos al abismo. Un asunto espinoso, complejo y apasionante.

Los entresijos del llamado market fit me tienen por tanto muy interesado, y se ha estado desarrollando en los últimos días un episodio a mi parecer muy ilustrativo, que por peso del producto implicado es de especial interés. Me refiero a la muy en voga transición de Python 2 a Python 3 y al tremendo pifostio que se ha montado alrededor. Agárrense que vienen curvas.

I feel geek

De cháchara: arquitectura de Ducksboard

Buf, que gordo estaba hace año y medio. Aunque también es verdad que tenía menos canas y se me notaba menos la calvicie incipiente. En fin, cosas de la edad y la tensión de mantener un negocio a flote, supongo… Este no es un post en sí mismo, sólo una nostálgica mirada atrás. Allá por julio de 2012, el siempre acogedor Alberto Sanz, CEO de Neventum y poseedor de una oficina / teatro / domicilio en plena Barcelona que ríase usted de las hipster-offices san-francisquinas, me invitó a hablar de Ducksboard (el Proyecto Tecnológico™) ante un atento público techie de lo más florido de la Ciudad Condal. Estos tipos saben organizar un evento, vaya que sí, y además de cervezas y una pared de 4×4 dónde proyectar, Alberto consiguió filmar la charla con sonido profesional y todo, para disfrute de los que no pudieron dejarse caer por allí.

Vídeo y slides dentro

Cuando éramos cracks

No sé cuántas veces habré oído/leído eso de que los técnicos no sabemos vendernos (al menos los de por estas latitudes – ya conocéis el rollo ese de que los americanos son grandes comerciales de sí mismos y fuck yeah amazingly awesome). Pero el hecho es que basta con sumergirse ligeramente en la comunidad techie vía Twitter, conferencias o blogs, y resulta que no, que somos (con perdón) los putos amos. Toda esa incapacidad para ponernos un lazo de cara al extraño se torna en confianza ilimitada de puertas adentro. Seguro que habéis leído mucho sobre “cracks” y “talento” en los últimos años: pues eso.

Ahora bien, ¿y todo ese orgullo? ¿Tan interesante, importante es lo que hacemos? Pues en un principio sí. La informática ha revolucionado nuestro concepto de sociedad. Las comunicaciones, el comercio, el trabajo, todo depende ahora de un modo u otro del software, y siendo nosotros los responsables de crearlo y mantenerlo, que menos que sacar pecho, ¿no? Pues francamente creo que no. Hoy vengo a defender que el desarrollo de software está hecho unos zorros, y que sobra autocomplacencia.

Bring it on!

De safari con Chrome: cazando leaks en Javascript

Ay, Javascript, Javascript. Que tiempos aquellos en que todo el uso que te daba era “fadeardivs, hacer un poco de AJAX o añadir algún que otro copo de nieve en fechas señaladas. La robustez de nuestra relación radicaba en las bajas expectativas mutuas. Yo no te veía como un lenguaje de programación, más bien como un juguete prescindible, y tú no me dabas ningún feedback útil, para qué molestarte si no iba a exprimirte el jugo. Pero los tiempos han cambiado, las modas se imponen y suceden, y lo de no tomarte en serio ya no va a ser posible. Y es que se acabó lo de ser la comparsa en una página web, esta es la era de la aplicación web, y las aplicaciones web, cada vez más grandes y complejas, son cosa tuya por derecho. Pero que duro está siendo, que duro…

Vamos a amastrear a ese Javascript…

Orden y concierto

Programar es controlar. Ejercer de comandante de una máquina cabezota dándole un fin y los medios (en forma de instrucciones) para alcanzarlo. Ponemos orden en los pensamientos de esas entrañables calculadoras XXL (y en no pocas ocasiones XXX) y las empujamos a trabajar en nuestro mejor interés. Ahora lo llaman arte o artesanía, antes nos conformábamos con considerarlo ingeniería. No hay mucha magia detrás del asunto: se les habla en un lenguaje que entiendan, y suelen obedecer. Escribir software consiste en traducir una serie de instrucciones (un algoritmo) a un lenguaje de programación, para su posterior transformación en código ejecutable por la máquina. Dead simple, right? Pues a veces sí, pero a veces no.

Si el algoritmo que estamos aplicando es trivial, y se limita a una serie de pasos dados en un orden estricto, la traducción a código ha de ser igualmente directa. Pero, ay amigos, el software tiende a modelar problemas de la vida real, y en la vida real raramente son tan sencillas las cosas. Una estrategia estándar para atacar un problema complejo en descomponerlo en problemas más pequeños, fáciles (o más fáciles al menos) de solventar. La combinación de todas esas soluciones es la solución al problema original. Y de eso quiero charlar un rato hoy, de la combinación de procesos en la resolución de problemas complejos.

Resolvamos esos problemas…

Show me your stuff

Suelo usar este blog para dar salida a todo tipo de disquisiciones sobre el sexo de las startups o a qué huele su tecnología. Permitidme hoy ponerme algo más terrenal y proponer algo. Quiero (queremos, más sobre eso luego) montar una reunión, o varias. De frikis para frikis, pero diferente. Hoy, y sin que sirva de precedente, me dejo de pajas mentales. Y sí, he dicho paja, al fin y al cabo es mi blog y me lo follo cuando quiero. Ups, me estoy pasando ya… voy a aplicar aquello que me decía mi padre de “habla bien, joder, que no cuesta una puta mierda”… En fin, al turrón.

Reuniones, decía. Vamos a contextualizar todo esto un pelo si no os importa. Antes de Ducksboard, yo nunca había sido de pasarme por eventos de desarrolladores u otros. El Meetup Group de Python de Barcelona en un par de ocasiones y ya. Vivía ajeno a la fiebre de los eventos. Pero entonces fundamos Ducksboard, y cuando empiezas algo lo suyo es darlo a conocer, y empecé a pasarme por encuentros y más encuentros a hablar del proyecto. Con todo, en estos últimos dos años me he paseado por una buena cantidad de reuniones de desarrolladores o startuperos. Y ahora, con conocimiento de causa, puedo afirmar que me generan sentimientos encontrados.

Sigue leyendo…

El que muere paga todas sus deudas

Toma título lapidario, de la pluma del más funesto William Shakespeare nada menos. Que no se disparen todavía las alarmas, no va a tratar el post sobre la muerte de nadie, faltaría más. Pero sí sobre un factor que puede acelerar el fracaso de un proyecto tecnológico. Un fenómeno que toda acometida técnica de cierto calado va a enfrentar tarde o temprano. La crisis económica de los geeks de a pelo, su fin de ciclo particular. En fin, hablamos de la deuda técnica. Para los no puestos en el tema, la palabra “deuda” ha de ser indicativa de que no es éste un asunto baladí. Vaya si no lo es…

¿Deuda? Esto parece el telediario…

El diablo está en los detalles, Python edition (y II)

En mi anterior post (y con “anterior” quiero decir “de hace más de un mes”, la frecuencia de mis entradas va a quedarse lejos de ser legendaria…) estuve comentando algunas características de Python que me parecían especialmente útiles. Herramientas como las comprensiones de listas y los generadores multiplican la productividad y hacen que el lenguaje sea compacto y legible. Un 2×1, como en los anuncios de detergente. Pero se me fue un poco de largo, y dejé fuera del mismo varias características igual de interesantes que quería explicar también. Si os parece bien, hoy echaremos un ojo a alguna más. Al final sólo a una más: ¡los decoradores!

¿Me vas a amueblar la casa?

El diablo está en los detalles, Python edition

No es un secreto que Ducksboard está implementado en Python. Hemos dado alguna que otra charla sobre el producto, y en ellas hablamos de la elección de tecnologías y otras hierbas. El decantarnos por Python no nos llevó demasiado trabajo a Jan y a mí. Es un lenguaje que conocíamos bien (Flumotion está escrito en Python, y de ahí veníamos), y nos parecía razonablemente decente (no es Lisp, pero tampoco es PHP) y adaptado a las necesidades del proyecto. En alguna de esas charlas nos han preguntado que por qué no usamos Javascript y Node.js, o Ruby, o Erlang, o Go, o cualquier otro lenguaje / plataforma.

Bien, esa pregunta tiene su jugo. Justificar el uso de una tecnología frente a otras puede derivar rapidamente en un flamewar de libro, lo que suele aportar poco y poner a la gente de mal humor. Como la política, ¡o el fútbol! Mal rollo. Y aquí no quiero malos rollos, soy un tío positivo. Así pues, he optado por no responder atacando las flaquezas de otros lenguajes, sino subrayando algunas de las pequeñas cosas que me hacen feliz en Python. Vamos, que paso de explicar la ponzoña de lenguaje que es Javascript, y en cambio prefiero centrarme en esos detallitos que hacen que Python mole bastante más. Sin acritud.

A ver qué tiene ese Python que no tenga Javascript…