La directiva europea de retención de datos, invalidada en los tribunales europeos

Han tenido que pasar años, muchos años, para que una de las regulaciones europeas introducidas la década pasada y vigente desde 2006 sea declarada inválida por el propio tribunal de justicia de la Unión Europea. Fue una directiva ante la que una gran cantidad de personas, sobre todo grupos muy preocupados por la privacidad y la protección de datos personales, mostraron oposición.

Data retention

En la nota de prensa podemos leer:

Estos datos, considerados en su conjunto, pueden proporcionar indicaciones muy precisas sobre la vida privada de las personas cuyos datos se conservan, como los hábitos de la vida cotidiana, los lugares de residencia permanentes o temporales, los desplazamientos diarios u otros, las actividades realizadas, las relaciones sociales y los medios sociales frecuentados.

El texto completo está disponible en alemán, inglés, y francés.

En Banda Ancha comentan el tema, del que también habla Paloma Llaneza.

Yo espero volver sobre él con algo más de tiempo/calma. Como notarán por la baja cadencia de este blog, no estoy teniendo todo el tiempo que me gustaría para escribir por aquí, pero este tema es lo suficientemente llamativo como para no mencionarlo siquiera de forma breve.

Marketing-department Driven Development

Prometo...

Prometo...

En el mundo Agile se habla mucho del design-driven development. Es una aproximación práctica al desarrollo de software que parte de la base de que la magia de un diseño sucede cuando el mismo se concibe y que, por tanto, la clave es concentrarse al máximo en esta etapa de concepción y diseño, dado que determinará y condicionará el éxito o el fracaso de todo lo que le sigue.

Esto está muy bien y si se hace bien el resultado es fantástico, pero no es la panacea y si no se hace bien resulta en catástrofe y concluye peor que si hubieras tomado la «aproximación clásica» (dejar la fase inicial a los técnicos). El problema explota cuando el desarrollo no lo condiciona el diseño, sino las promesas del equipo de marketing.

(Casi) Todo proyecto nace del departamento de marketing, alguien tiene que venderlo antes de que exista necesidad y justificación para construirlo. El tema es que hay muchas formas de vender, de prometer, y de decidir cuándo se van a admitir aportes, o cuáles aportes van a ser admitidos en absoluto.

Una forma sensata de vender un proyecto consiste en contrastar antes con la realidad: preguntar a tu amigo techie o a tu CTO, si tal o cual sistema con tal o cual funcionalidad es vendible y/o programable dentro del presupuesto que el dpto. de ventas está pensando fijar para el mismo.

Una forma insensata de hacerlo es, por contra, que el proyecto tenga fecha de antemano, que la misma sea inamovible (porque el dpto. de marketing que condiciona el proyecto ya ha reservado sala para la launch party), y que los diseños se hagan a espaldas de quien tendrá que desarrollarlos. Un creativo haciendo diseños y un vendedor dándolos por buenos sin que nadie valide internamente que la estructura informacional es correcta, que sirve al objetivo del proyecto, que es usable, que se ciñe a unos bocetos ya consensuados. (Noten que todas estas labores son técnicas, requieren conocimiento especializado, y que no he hablado siquiera de programar; son otras tareas técnicas necesarias para un proyecto de software, aunque nadie hable de ellas.) El resultado se asemeja a las viejas pelis ochenteras, como aquella saga barata de de No me chilles que no te veo.

Como todo buen equipo falto de rigor (esto es un oxímoron, claro), no existirá tal cosa como un hito de validación, se continuarán haciendo cambios hasta el último día. No es grave, al fin y al cabo, el desarrollo es magia, todos hemos visto The Social Network y sabemos Facebook se construyó en un día. Zuck se chinchó con sus colegas de la uni después de la hora de la cena y a la mañana siguiente tenía Facebook terminado, con WhatsApp comprado e integrado, y todo eso. Éste es el concepto.

Y es un concepto catastrófico.

Combos que incrementan la gravedad de esto, y la probabilidad de que suceda: que el vendedor sea asiduo a blogs de tercera tipo PuroMarketing (tranquilos, no lleva nofollow porque no he puesto enlace) en los que se relata con presumido glamour las historias de empresas social media, faunders, CEOs, SEOs, Investors, y toda esa calaña. El vendedor (ahora conocido como CEO) terminará creyendo que él puede ser faunder de su propia startup tecnológica, y dirigir al equipo técnico. Imbuido de esa mística marketiniana irradiada por blogs como el anteriormente mencionado, se verá a si mismo como el próximo CEO de la próxima startup tecnológica, e instaurará para su proyecto, en lugar de un desarrollo condicionado por el diseño, el mucho más divertido diseño condicionado por el departamento de marketing.

Hay otros combos letales también comunes (el conocido síndrome del «este traje me viene un poco grande») que desembocan en la instauración de procesos de desarrollo dirigidos por el departamento de marketing. Otro día los comentaremos.

La marketiniana manía de ser el primero

«En el curso de los años me he vuelto profundamente escéptico con la ventaja de ser el primero. De hecho, paso complicaciones buscando ejemplos de ello. IBM llegó tarde a las computadoras, y entonces décadas después llegó tarde a los PC. Oracle no inventó las bases de datos, Lotus no inventó la hoja de cálculo, Microsoft no inventó los sistemas operativos ni el sistema de ventanas, Apple no inventó la interfaz gráfica de usuario, Google no inventó los motores de búsqueda, y Facebook no inventó el software para redes sociales. La ventaja del primero es probablemente relevante para cosas que pasan una vez. El primer chico malo con megacomputación podría protagonizar el mayor robo relacionado con criptografía de la historia, pero no tendrá una ventaja sostenible.»

Nathaniel Borenstein, inventor del adjunto en los e-mails, en una entrevista que recomiendo leer.

Hay un perfil de personas que dicen hablar de tecnología y sociotecnología, pero muestran un desaforado interés por demostrar que llevan toda la vida siendo los primeros en hacer cosas. En realidad, no hablan de tecnología, hablan de marketing, y sobre todo hablan de ellos mismos. Pero no hablan de tecnología.

Netflix, operadoras, y neutralidad de la red

Neutralidad y cables

Neutralidad y cables

Que la neutralidad de la Red es una utopía a punto de formar parte de la historia no es ya ninguna sorpresa. Que las noticias que certifican su muerte pasen inadvertidas debería encendernos todas las alarmas.

Hoy leemos que «Netflix consigue que Comcast no le ralentice el streaming tras abrir la cartera» y, obviamente, lo primero que debemos pensar es que si no tienes la cartera de Netflix, no podrás conseguir acceso de calidad a posibles clientes a través de Internet. De hecho, el mismo Netflix tendrá que volver a abrir la cartera para contentar a Verizon. Y así con todas las operadoras.

En el mejor de los casos, si logras tener éxito vas a tener que repartirlo con operadoras parasitarias cuyo único valor es haber logrado leyes a su medida con la que ahora pueden innovar con servicios nada innovadores en los que se cobra 2 veces por lo mismo (al usuario, y a los proveedores de contenidos-software a través de Internet).

Actualización (2014-03-11 @ 18:51): la perversión de este asunto que comentábamos justo arriba, en negro sobre blanco: Netflix quiere lanzar en Francia este año y busca… un socio entre los ISP. Si es que está claro que sin neutralidad, hay un peaje automático a favor de las operadoras.

Hablando sobre redes sociales internas con Discourse, en Madrid

Hace un par de semanas se celebró en Madrid el primer encuentro europeo sobre Discourse, al que tuve el placer de ser invitado para contar mi (pequeña) experiencia articulando una comunidad pública y abierta con este software. En concreto, es con él que funcionan los foros de debate para los lectores, amigos, y asiduos de mi blog personal.

Aunque ése es el caso de uso más obvio (al fin y al cabo, es un foro que cumple la misma función que han cumplido siempre estos foros en Internet), Discourse por su propia naturaleza hace posible otros casos de uso: como sistema para articular una red social interna en una empresa, por ejemplo. Se debatió mucho sobre esto tanto en el debate como en la conversación posterior, y las conclusiones y la sensación son tremendamente positivas para este uso.

El evento, compuesto de charlas breves y ágiles, más centrado en el debate que en la disertación, fue bastante interesante y contó con la participación de:

  • Jeff Atwood, impulsor de este proyecto, que participó desde California mediante videoconferencia.
  • David García Navas, que contó el caso de Territorio creativo, que usa el software para establecer la comunicación de la red social interna.
  • Beltrán Rueda, de Bitnami, empresa especializada en empaquetar aplicaciones libres para que cualquiera pueda ponerlas a funcionar con la mínima complejidad.
  • Guillermo Aranda, de Mozilla Hispano, que contó un poco las expectativas que desde Mozilla tienen en que una solución como Discourse consiga solucionar los problemas de comunicación interna de una institución como Mozilla, con muchas personas que poseen trasfondos muy diferentes y hábitos también muy diferentes.
  • Además de que, como digo arriba, me dejaron contar la experiencia de los foros de Versvs.

Sobre este evento podemos leer dos artículos, uno de David García Navas en el blog de Territorio creativo, y también el post de Bianka Hajdu en Con Tu Negocio. Además, las diapositivas que usé (aviso que estas diapos sin el speech quedan algo cojas) se pueden ver en el navegador.

Para terminar, os dejo con la intervención de Jeff Atwood, que es sencillamente directa a la hora de expresar la principal motivación detrás de este proyecto, y los beneficios inmediatos que ofrece a quienes lo integren entre sus herramientas.

La foto la he tomado del mismo post de Territorio creativo que enlazo arriba, ¡gracias!.

GoRead, software libre que no podrás instalar fácilmente en tu servidor

GoRead

GoRead

He probado durante unas semanas GoRead, un nuevo lector de feeds libre. En este post intento recoger algunas ideas en torno a esta herramienta en concreto, y en torno a la panorámica general de los lectores de feeds en la era post-Google Reader.

¿Cuál es la promesa de GoRead?

El objetivo de GoRead es replicar, al máximo, la experiencia de lectura que ofreciera Google Reader. La interfaz, de hecho, está fuertemente inspirada en éste. Añaden la disponibilidad de aplicaciones nativas para tablets y móviles.

GoRead tiene la ventaja de que es software libre, y la desventaja de que está programado para correr sobre Google App Engine, con lo cual difícilmente te lo vas a llevar a tu propio servidor y ejecutarlo donde tú quieras. Antes tendrás que cambiar presumo que no pocas cosas en el código para que corra sobre otra infraestructura que no sea la de Google. De entrada, para registrarte en el software, necesitas forzosamente una cuenta de Google.

GoRead ofrece una alternativa a correr tu propia instancia de la aplicación en tu propia cuenta de Google App Engine, que es usar la versión como servicio que ellos mismos dan, a cambio de 3 euros al mes. El clásico modelo de software libre popularizado por WordPress.com con versión as a service.

A favor

El software va rápido. Como no debería sorprender a nadie, la infraestructura de Google App Engine está fuera de sospechas a estas alturas en cuanto a su rendimiento.

Han copiado los atajos de teclado del viejo Google Reader. Tras años usando TinyTinyRSS tengo otros atajos interiorizados, y os podéis imaginar que al principio me la pasé tecleando atajos que no llevaban a ninguna parte, pero en apenas una mañana de uso ya había despertado en mi cabeza el viejo recuerdo de cómo y dónde hacer lo que quería hacer.

Es un proyecto con sólo unos meses de vida, así que es posible que evolucionen a buen ritmo y mejoren sus principales deficiencias (que las tienen, y son remarcables).

En contra

Las aplicaciones (al menos las de Android) son pobres: la de tablet no aprovecha para nada la pantalla y se comporta exactamente como la del móvil, que a su vez es muy parecida (y no mejora en nada) a la aplicación libre para Android de TT-RSS. En realidad, tanto en móvil como en tablet terminé usando la versión web del lector en lugar de la aplicación nativa, lo cual era bastante doloroso porque la web no se adapta nada de nada al dispositivo, y la interacción con el menú de feeds en la pantalla táctil resultó ser bastante tortuosa.

La interfaz no está pulida: haces scroll y pierdes la parte superior de la web que permite cambiar rápidamente de feed y cosas así. Está claro que eso lo pueden arreglar rápido, pero ojo, que estamos hablando de un servicio de pago y no han tenido en cuenta aspectos básicos de usabilidad. Valga reflejar, además, que la evolución en los 30 días que duró mi periodo de prueba fue inexistente: fallos nimios que estaban ahí el día 1, continuaban ahí el día 30.

Otro gran detalle a no olvidar es que estamos hablando de un servicio de pago con software libre en modo «mirarás y mirarás pero no lo tocarás», ya que al estar programado para funcionar sobre Google App Engine las posibilidades de llevarte la aplicación y ponerla a funcionar en un servidor de tu elección es bastante compleja (si es que existe en absoluto), y desde luego no es nada trivial. Es código libre, pero no te va a permitir ejecutarlo en tus propio servidor así sin más.

Conclusiones: necesita mejorar

Se trata de una herramienta que está algo verde. Es un software libre que no podrás instalar fácilmente donde tú quieras. Funciona bien, la interfaz web para tu desktop no está mal, pero necesita mejoras, y la interfaz para móvil y las aplicaciones para tablet y móvil son claramente deficientes. Al ser un proyecto reciente, nos queda la duda respecto de la velocidad a la que van a evolucionar. Sin embargo, en los 30 días que duró la prueba no se percibió ni la más mínima evolución, lo cual es mal síntoma.

De momento, TinyTinyRSS es una alternativa mucho mejor, y si le sumas que para este software ya existen plugins para guardar enlaces en SemanticScuttle y en Wallabag, sencillamente no hay ningún género de dudas en cuál solución usar.

Este blog usa cookies para su funcionamiento.    Más información
Privacidad