El retargeting sin sentido y el humo marketiniano

El retargeting es otro de esos inventos incómodos y molestos que nos llegó en estos años de web tardía, donde las aristas del modelo gratis con publicidad dominante gracias al efecto red se ven más visibles, y detestables.

Más allá de la experiencia, es significativo que pasen los años y el retargeting siga siendo tan fallón: que sigan apareciéndote anuncios de artículos que ya compraste, pagados por las propias tiendas donde los compraste, días e incluso semanas después de la compra.

Es relevante por lo que deja entrever: tras toda la fanfarria marketiniana de los gigantes de la publicidad como Google, Facebook, o Amazon, que intentan convencernos de la altísima capacidad de sus motores de recomendación impulsados con machine learning, inteligencia artificial, y blablablá (no sigo porque la cantidad de chorradas es enorme) resulta que al final te bombardean con anuncios que ya no te son vigentes (cosas que ya compraste, a veces incluso en la misma tienda que te sigue haciendo retargeting, y no necesitas hace tiempo) porque ni el algoritmo ni sus sistemas se enteran de nada y tan solo se limitan a spammearte sin cesar.

Esto ya lo hacían hace cuarenta años las empresas que, a ciegas, inundaban tu buzón físico de folletos indeseados. Cuanto más cambian las cosas, más permanecen igual. Ni perfiles, ni personalización, ni capacidad de extraer información suficiente para este propósito a pesar de la cantidad de datos que acumulan.

El retargeting es, a día de hoy, la mascarada al descubierto de la venta de humo marketiniana.

Quizá llegará el día en que alguna de estas empresas sea capaz de saber mejor que yo qué querré hacer dentro de seis meses y concebirá formas de presentarme anuncios que me vendan lo que voy a querer hacer antes aún de que yo sea consciente, de forma que consigan que yo les pague por lo que iba a suceder de todas formas. Pero, como diría Aragorn, ese día no es este día.

Git switch y Git restore, desambiguando git checkout

Anduve de finde largo y poniéndome al día con algunas lecturas atrasadas en mi Inoreader, de las que lo más interesante me lo encontré a modo de anuncio oficial en el blog de Git.

A partir de la versión 2.23 recién publicada, Git tratará de desambiguar las muchas cosas que actualmente puede querer hacer un usuario mediante un git checkout, creando dos nuevas opciones como son la de git switch para cambiar de rama y git restore para devolver la rama de trabajo actual a su último estado commiteado.

De momento es solo una prueba y no creo que a corto ni medio plazo desaparezca el checkout de toda la vida, más que nada por retrocompatibilidad con todas las herramientas que pueda haber por ahí y dependan de eso.

En todo caso, es un paso correcto que beneficiará incluso a personas que lleven más de una década usando git como es mi caso y que ya estén muy habituados a usarlo así. Para todos, pero especialmente para no confundir a nuevos usuarios, la nueva sintaxis diferenciada tiene mucho sentido.

Valora las consecuencias probables

Un par de párrafos interesantes sobre soluciones a problemas, sobre todo cuando se plantean o defienden políticas públicas, a los que he llegado hoy vía Elena Alfaro.

Usually when people think about their position on an issue, they recollect why they believe what they do and they generate arguments in favor of the position they already have. They don’t engage in causal explanations about how the policy would lead to good or bad outcomes.

These are very different forms of thinking. Usually when people think about policies, they are not engaged in causal explanation. Most discourse about policy is about why we believe what we do: who agrees with us, why we hold whatever value the policy addresses, what we heard about it on the news the other day. Our experiment asked people to do something difficult and unusual, to causally explain the effects of a policy. That task requires engaging the details of the policy and spelling out how the policy would interact with a complicated world.

Steven Sloman, The knowledge illusion

Cuando juzgamos una solución en forma de medida o regulación pública, habitualmente pensamos en el objetivo declarado de las mismas y no en sus consecuencias más probables.

Las intenciones pueden ser buenas, o una medida puede sonar bien, pero la forma correcta de evaluarla y juzgarla no es por su fin declarado o sus intenciones, sino por sus resultados probables o esperables.

Siendo siempre importante, lo es más en estos momentos de tentación populista, eslóganes facilones, y campañas que esbozan soluciones fáciles para problemas complejos.

Escribí sobre DevOps en la VS Pedia

Hace unos días añadí a la VS Pedia una entrada acerca de DevOps. Hace varias semanas cuando os conté aquella anécdota con uno de mis profesores de la universidad os prometí escribir sobre DevOps en el blog, pero al final lo que me salió fue una entrada para la pedia.

En multitud de ocasiones se habla de DevOps como una suerte de solución mágica que arreglará todos los problemas de operar un software. De hecho por cómo se usa tanto en webs de perfiles profesionales como en ofertas de empleo, pareciera que DevOps es ahora un sinónimo de administrador de sistemas, alguien capaz de operar en servidores en vivo sin liarla parda. Y el grupo de personas que hace eso es el equipo de DevOps.

DevOps no es eso, no al menos si no somos reduccionistas hasta el punto de desaprovechar lo que enfoques nuevos pueden aportarnos. DevOps es una forma de trabajar que tiene como colateral positivo que los desarrolladores sean mucho más conscientes de cómo se opera su software, y esté mejor capacitados para solucionar los problemas, pero como no quiero repetirme, os animo a leer la entrada en la pedia.

El 5G no va de cargar webs más rápido

Via Daring Fireball llego a un artículo sobre 5G en el Wall Street Journal, (tienen un paywall, así que quizá tengan que tirar de ingenio para leerlo) donde se explica lo siguiente:

Eager to test out a technology that’s been more hyped than flavored sparkling water, I embarked on a 5G expedition from Denver to Atlanta to Chicago to Manhattan’s Lower East Side. I mostly used the new, $1,300 Samsung Galaxy S10 5G, one of the first 5G phones and the only one available across all the carriers. I also tested the LG V50 ThinQ 5G on Sprint’s network; Verizon has a version but I didn’t test it.

After nearly 120 tests, more than 12 city miles walked and a couple of big blisters, I can report that 5G is fasten-your-seat-belt fast… when you can find it. And you’re standing outdoors. And the temperature is just right.

As my findings show, 5G is absolutely not ready for you. But like any brand new network technology, it provides a glimpse of the future.

Hay tantas cosas que esta periodista especializada en tecnología ha entendido mal en su sinopsis que cuesta trabajo decidir por dónde comenzar. Uno de los problemas es que los aspectos claves de futuro vislumbrado ni se mencionan ni se explican en el artículo, seguramente porque la autora no los ha visto siquiera. Schade!

Por partes, aspectos de disponibilidad actual de tecnología tanto en infraestructura (red) como del lado del usuario (terminales):

  • Terminales. Dejando de lado que los terminales que ahora soportan 5G lo hacen de forma muy parcial (cualquier terminal de gama de entrada dentro de 2-3 años le va a dar tremendo baño al más caro que puedan comprar ahora)
  • Despliegue parcial de redes. Las redes desplegadas son más que incipientes, lo cual aún agrava aún más lo de comprar un terminal con sobreprecio por la novedad, para no disfrutar su capacidad la mayor parte del tiempo por andar bajo cobertura de red previa.
  • La condición especialmente pobre de EEUU con el 5G. El 5G progresa por encima de lo esperado, pero aún está globalmente casi en pañales. Esta situación es aún peor en Estados Unidos donde han de convivir con decisiones pasadas vinculadas a las bandas reservadas para 5G en ese país, que son especialmente ineficientes, y su influencia como lastre hacia el presente, como ya comentamos en este blog hace unas semanas al tratar la posición de la UE respecto de esta tecnología.

Con todo, el principal problema es de concepto, y parece mentira que a estas alturas una periodista especializada en tecnología en uno de los medios más prestigiosos del mundo pase por alto estas cosas: el 5G no es al 4G lo que el 4G fue al 3G. No es una simple mejora en el sentido de ahora internet en tu móvil va a ir más rápido. Si fuera tan solo eso, puede que el análisis fuera suficiente; sobre todo si consideramos que escribe desde y para los Estados Unidos.

El asunto es que ese incremento de velocidad se va a usar, principalmente, en incorporar todo tipo de dispositivos conectados a la red con tu teléfono móvil actuando como edge service, o proxy, como queráis llamarlo. Por eso en muy poco tiempo vas a necesitar una tarifa móvil con decenas de gigas de datos mensuales solo para ir tirando.

La clave es que las velocidades que se alcanzan cruzan el punto de inflexión de la viabilidad para ciertas aplicaciones como vehículos autónomos, uso remoto de maquinaria (por ejemplo, para usos médicos y de cirujía en casos donde el paciente no pueda ser trasladado) que obviamente no tienen nada que ver con la experiencia de uso de 4G pero más rápido. El 5G no va de cargar webs más rápido, y si lo miras con esos ojos estás aplicando un reduccionismo tan burdo que asusta. Va a haber que repetirlo mucho, sobre todo a periodistas tecnológicos de oído duro.

Fabricar, envasar, y vender

Hace no mucho tiempo preparé una pequeña presentación sobre todo lo que implica el trabajo como DevOps, un tema del que quizá hablemos otro día ya que casi todo lo que leo al respecto yerra bastante en su enfoque. Pero eso será otro día. De momento, vamos con el post de hoy, para el que me valdré de una vieja anécdota de mis tiempos de estudiante universitario (undergrad, antes de comenzar la tesis): el día en que me contaron que allí íbamos a aprender a fabricar, envasar, y vender.

El tema es que estábamos charlando con Juan Francisco Arenas, que además de ser un excelente químico físico es un señor altísimo, y, en un momento dado, nos preguntó: ¿Para qué creen ustedes que vienen aquí a la universidad? Mi compañero y yo nos miramos, pensando que la respuesta era fácil: obviamente íbamos allí a aprender química. La realidad, sin embargo, era algo más compleja de lo que nos imaginábamos.

«Claro», nos replicó, «pero vienen ustedes a algo más: aquí se viene a aprender a fabricar, envasar, y vender«. Creo que pocas veces una respuesta tan sencilla me ha hecho volver a ella tantas veces a lo largo del tiempo.

Dejando la química y hablando de software, que es de lo que más hablamos en este blog, en el mundo de desarrollo de software es muy habitual que los profesionales crean que su trabajo es programar y únicamente programar. A menudo olvidamos que programar un prototipo es sencillo y lo realmente complicado es productizar el prototipo. Lograr que corra estable o que sea fácil de desplegar y operar por nuestros queridos sysadmins es clave.

Sin todo eso, tu software no deja de ser un prototipo: poco más que un juguete; y sea cual sea nuestro modelo de negocio, va a ser muy complicado que nos paguen por algo que es poco más que un juguete.

Con todo ello es más fácil lograr que otra persona pueda cerrar un acuerdo en el que a cambio de ese software, o de nuestros servicios, se nos pague. Fabricar (programar), envasar (productizar), y vender (ejem, vender, sí).

Fabricar, envasar, y vender. Si eres de los que piensa que tú tan solo desarrollas y que a ti no te tienen que calentar la cabeza con costes, precios, y demás asuntos de factorías de software (o de jefes), es hora de que vayas cambiando la forma de concebir tu propio trabajo.

Problemas complejos

Para cada problema complejo hay una respuesta que es clara, sencilla, y equivocada.

H. L. Mencken, citado en Pawn Sacrifice (película biográfica sobre Bobby Fischer), dirigida por Edward Zwick en 2014.