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

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…

Ande yo caliente, ríase la gente

Me encuentro con ciertas preguntas recurrentes en toda charla que doy sobre la arquitectura y tecnología de Ducksboard. Una de ellas es cómo demonios hemos acabado usando la base de datos de una manera tan… original. Otras, y éstas son las interesantes, van en la línea de:

¿Y por qué Python y no Ruby?
¿Y por qué PostgreSQL en vez de MongoDB?
¿Y por qué Backbone.js si mola más Ember.js?
¿Y por qué <ducks-tecnología-X> y no <yo-prefiero-tecnología-Y>?

Nuestra elección de tecnología sigue una serie de criterios. Lo que sigue es una explicación de algunos de ellos para responder a todas esas preguntas, así del tirón. Once and for all, que decía aquel.

Venga, sigue

Concurrencia en Python

Buena gente la de Betabeers. Montan un evento para desarrolladores una vez al mes, y los patos solemos pasarnos por ahí. Se presentan proyectos, hay algo de debate técnico, y luego unas cervecillas (o copichuelas para los más valientes) ejercen de lubricante social. Ahora los hay en casi todas las ciudades del mundo, así que buscad el vuestro :)

Pues andaba yo un día echando un ojo a la lista de correo de Betabeers (me gusta leer en ese tipo de foros pero sin participar, muy en plan voyeur, pero sin tocarme, claro) y me llamó la atención una pregunta que se hacía por ahí. Hablaba alguien de su proyecto, y de que lo había hecho en Java, y tal y cual. Y entonces venía alguien y preguntaba aquello de “¿Java? ¿Por qué no Ruby o Python o Tecnología Cool X?”. Y el primero respondía algo como “necesito concurrencia, y no tengo demasiada idea de como está el tema de la concurrencia en esos lenguajes esotéricos, en Java uso threads y p’alante…”.

Read more