Si te suena familiar, no estás solo. Según los últimos datos de Pragmatic Engineer (2026), el 95% de los ingenieros ya usan herramientas de IA semanalmente. Pero el número que importa de verdad es otro: el 70% usa entre 2 y 4 herramientas o modelos diferentes cada semana. No hay un stack unificado. No hay criterio compartido. Solo fragmentación total disfrazada de adopción.

Y ese es el problema real: la mayoría de empresas creen que adoptar IA significa comprar licencias. Eso es el paso cero.

El espejismo de la licencia

El patrón se repite en todas las organizaciones. Alguien en dirección aprueba el presupuesto para licencias de Copilot o Claude, envía un email diciendo «ya tenéis acceso» y espera a que la magia ocurra sola.

Los números de Harvard Business Review de este año son demoledores: el 95% de las organizaciones no ven ningún ROI en sus iniciativas de GenAI, y el 74% están atrapadas en el «purgatorio del PoC», pruebas de concepto que nunca escalan a producción real.

Bain cuantificó la brecha con precisión: las herramientas de IA para código usadas de forma aislada producen una mejora del 10-15% en productividad. Pero cuando hay transformación de extremo a extremo (directrices, procesos, métricas y cultura), ese número sube al 25-30%. La diferencia no es la herramienta. Es todo lo que la rodea.

La analogía que ya he vivido: Mobile-First

Cuando Android empezó a explotar, las empresas no se limitaron a decir «haced una app» y listo. Bueno, algunas sí. Y esas apps se convirtieron en desastres legendarios. Las que lo hicieron bien cambiaron procesos, construyeron equipos dedicados, adaptaron sus métricas, definieron guías de UX para iOS y Android, y redefinieron lo que significaba «release» cuando ya no controlabas cuándo actualizaba el usuario.

Lo mismo pasó con Kotlin. Decir «podéis usar Kotlin» sin un plan de migración, sin directrices para la coexistencia con Java, sin formación – receta para un codebase Frankenstein.

La adopción de IA sigue exactamente el mismo patrón. Dar licencias sin un plan es el equivalente en 2012 de «haced una app móvil» sin cambiar nada más. Puedes tener la mejor herramienta del mercado: Claude Code ha superado a GitHub Copilot como la herramienta más usada en 2026 [1], pero si cada uno la usa a su manera, sin criterio compartido, el resultado es inconsistencia disfrazada de velocidad.

Cómo es una adopción real de IA

Si me preguntas, hay cinco bloques que no te puedes saltar.

1. Define el stack de IA de tu equipo

No se trata de prohibir herramientas, sino de tener un stack recomendado y documentado. Igual que tienes estándares para linting, testing y CI, necesitas uno para IA. Qué herramienta para generación de código. Cuál para code review. Cuál para documentación. Y por qué.

Pero un stack no es solo una lista de herramientas aprobadas. Es configuración compartida. En mi equipo, hemos desarrollado algo que la verdad llevábamos tiempo queriendo hacer; al final lo conseguimos al tener más recursos en el equipo core. Hemos ido un paso más allá: construimos un plugin de Claude Code que empaqueta todo el toolkit de IA del equipo en una única unidad instalable. Cada desarrollador tiene la misma configuración con un solo comando. Los mismos prompts, el mismo conocimiento de la arquitectura, los mismos estándares de código integrados. No una página de documentación que diga «por favor, usad estas herramientas». Una configuración real compartida por la que pasa cada interacción con IA. Estamos actualmente en proceso de desplegarlo en todo el equipo; quizá lo cubra en un futuro artículo.

Hay que ir mucho más allá: no solo elegimos la herramienta, la configuramos para que conozca nuestro codebase.

2. Crea directrices de uso reales

El informe DORA 2025 reveló un número que debería estar en la pared de cada Engineering Manager: los equipos con políticas claras de uso de IA ven una adopción 4,5 veces mayor que los que no las tienen. No es un matiz – es la diferencia entre adoptar de verdad y estar jugando.

¿Qué incluyen esas directrices? Cuándo usar IA y cuándo no. Qué tipo de código requiere revisión humana exhaustiva (pista: todo lo que toca seguridad, datos personales o lógica de negocio crítica). Cómo documentar qué partes del código fueron generadas o asistidas por IA. Qué prompts y configuraciones comparte el equipo.

El concepto de AI Usage Charter de LeadDev – co-creado con los ingenieros, no impuesto por dirección, revisado trimestralmente – es un buen punto de partida. Pero la evolución que he visto en la práctica es esta: el destino natural de los estándares de código no es un documento que el equipo debería leer. Son esos estándares embebidos en la propia herramienta de IA, ejecutándose automáticamente en cada PR, sin depender de que nadie se acuerde de consultar la wiki. En el plugin que estamos ideando en el equipo, cuando un desarrollador lanza una review de PR, no recibe una review genérica de IA. Recibe una review contra la arquitectura real del equipo: nuestros patrones de Compose, nuestro modelo de manejo de errores, nuestras directrices de testing, nuestras reglas de seguridad. Todo precargado. Los estándares de código ya no son un documento de referencia. Son un sistema en ejecución.

3. Onboarding progresivo, no Big Bang

No todo el mundo parte del mismo punto. Los early adopters ya están experimentando, el riesgo con ellos es evangelizar sin criterio. Los escépticos (normalmente los seniors más experimentados) necesitan algo diferente: no un pitch, sino evidencia concreta de que la herramienta resuelve problemas que ellos reconocen como reales.

Lo que la mayoría de líderes no ven: la resistencia senior a la IA rara vez es técnica. Es una cuestión de identidad profesional. Si llevas 15 años resolviendo problemas complejos y alguien te dice que una IA puede hacerlo, la reacción natural no es curiosidad: es amenaza. Ignorar esto y etiquetarlo como «resistencia al cambio» es un fallo de liderazgo, no un problema de ingeniería.

Barry O’Reilly lo clavó en HBR este año: la resistencia basada en identidad es el patrón dominante en la adopción de IA, no el escepticismo técnico. El senior que cuestiona todo no es tu obstáculo, está haciendo stress testing de tu plan de adopción gratis. Sus preguntas («Y el testing?» «Quién es responsable del código generado?» «Qué pasa con la seguridad?») son tu hoja de ruta de adopción.

Es interesante medir el sentimiento del equipo hacia las herramientas de IA de forma continua, no solo el throughput. Porque si tu equipo odia la herramienta pero saca más PRs, tienes una bomba de relojería a seis meses vista, no un caso de éxito.

4. Adapta el code review al mundo post-IA

Este es el punto del que casi nadie habla. Si tu equipo genera código un 20% más rápido, ¿quién revisa ese 20% extra? ¿Con qué criterio? Hay estimaciones de un aumento del 2.500% en defectos de código generado por IA sin supervisión adecuada. Velocidad sin quality gates es deuda técnica acelerada.

La respuesta no es un checklist manual pegado al monitor. La review asistida por IA necesita llevar el mismo contexto que la generación asistida por IA. Si la IA que escribe el código no conoce tu arquitectura, va a producir basura con buena pinta. Si la IA que lo revisa tampoco la conoce, va a dar el visto bueno a esa basura con un pulgar arriba.

Por eso construimos tooling de IA consciente del equipo. Cuando nuestro plugin ejecuta una review de PR en código Android, no busca problemas genéricos – comprueba contra los patrones concretos que hemos acordado como equipo. Nuestras convenciones de Compose. Nuestro enfoque de testing de ViewModels. Nuestros patrones de inyección de dependencias. La review está enmarcada bajo unos criterios porque nosotros la hicimos así, y esos criterios son las del equipo, no los defaults del modelo.

Y esto conecta con algo que escribí en Tokenmaxxing: medir tokens consumidos como proxy de productividad es exactamente el tipo de métrica vacía que surge de una adopción sin plan. Es la versión IA de medir líneas de código – un número bonito que no te dice absolutamente nada sobre el impacto real.

5. Mide lo que importa, no lo fácil de medir

Las métricas de adopción de IA deberían responder preguntas concretas: ¿Ha bajado el time-to-merge? ¿Ha mejorado la calidad del código en PRs asistidas frente a las no asistidas? ¿Ha disminuido el tiempo de onboarding de nuevos desarrolladores?

Pero medir la adopción no es suficiente. Necesitas medir la calidad y la eficiencia. Y para eso, no puedes fiarte de los benchmarks del vendor.

Esto es otro proyecto que estamos construyendo ahora: un framework de evaluación interno para nuestro codebase Android (primer paso, después iOS). Tareas reales, las mismas que nuestros desarrolladores resuelven cada semana. El agente de IA corre en un contenedor Docker aislado con el Android SDK, intenta la tarea, y el framework evalúa el resultado ejecutando tests de Gradle. Escribir tests de ViewModel. Construir una pantalla Compose desde cero. Crear componentes de UI reutilizables. Mutation testing para verificar que los tests de la IA realmente pillan bugs reales.

En lugar de enviar manualmente 50 PRs idénticas para comparar herramientas, automatizas la comparación. Puedes ejecutarlo contra diferentes modelos, diferentes versiones del agente, diferentes configuraciones de prompts, y obtener resultados reproducibles y comparables. No confíes en el benchmark de Anthropic para saber si Claude Code funciona bien con tu código. Construye el tuyo. Las tareas que uses para evaluar deberían ser las mismas que tu equipo resuelve cada semana.

Estos dos sistemas, el plugin que da a la IA el contexto de tu equipo, y el framework de evaluación que mide si la IA realmente funciona bien con tu código, son las dos caras de la misma moneda. Contexto más medición. Esa es la brecha entre la mejora del 10-15% y la del 25-30%.

Los tres errores que veo una y otra vez

Después de participar en adopciones tecnológicas de esta escala, Android en empresas que solo hacían web, Kotlin en codebases Java con cientos de miles de líneas. Los errores siguen un patrón predecible:

1. Dejar que los early adopters evangelicen solos. El entusiasta que monta una demo un viernes por la tarde no es una estrategia de adopción. Es una persona que se va a quemar cuando nadie le escuche.
2. Ignorar a los escépticos en vez de integrarlos. Los seniors que cuestionan la IA suelen tener las mejores preguntas: «Y el testing?» «Quién se responsabiliza del código generado?» «Cómo afecta esto a la seguridad?» Esas preguntas son tu hoja de ruta de adopción, no tu obstáculo.
3. No adaptar los procesos downstream. Generar código más rápido sin adaptar code review, QA y deploy es como ponerle un motor de F1 a un coche con frenos de bicicleta. Las ganancias de velocidad se evaporan o, peor, se convierten en deuda técnica que pagarás con intereses.

En definitiva

Adoptar IA en un equipo de desarrollo no es un problema de herramientas. Es un problema de gestión del cambio. Y como cada cambio tecnológico que hemos vivido – móvil, cloud, microservicios, Kubernetes – los que lo hacen bien no son los que llegan primero, sino los que llegan con un plan.

Si buscas por dónde empezar mañana, mi sugerencia: elige dos cosas.

Primero, codifica los estándares de tu equipo como conocimiento del agente. Coge tus convenciones de código, tus decisiones de arquitectura, tus directrices de testing – todo lo que actualmente vive en una página de Notion o Confluence que nadie lee – y conviértelo en configuración que tus herramientas de IA realmente consuman. No un documento de referencia. Un sistema que se ejecuta.

Segundo, define 3-5 tareas reales como tu benchmark interno. Tareas que tu equipo resuelve cada semana de verdad. Ejecuta tu tooling de IA contra ellas. Mide los resultados. Y vuelve a ejecutarlas el mes que viene después de mejorar la configuración. Ese es tu feedback loop. Vale más que cualquier benchmark de vendor.

Define tu stack de IA. Crea directrices con el equipo, no para el equipo. Mide impacto real, no tokens consumidos. Integra a los escépticos. Adapta tus procesos.

La pregunta no es si tu equipo va a usar IA. Ya la usan. La pregunta es si tú, como líder técnico, vas a dejar que eso ocurra de forma caótica o lo vas a liderar con la misma intencionalidad que aplicas a cada decisión técnica relevante.

Llevo meses viéndolo: empresas montando leaderboards internos para rastrear quién gasta más tokens de IA. El término que circula es tokenmaxxing — la práctica de maximizar tu consumo de tokens para demostrar que «estás adoptando IA». Algunas organizaciones están literalmente gamificando el uso de LLMs como si fuera un reto de pasos en una pulsera de empresa. Y no es un rumor de pasillo: Hard Fork, el podcast de tecnología del New York Times, le dedicó un segmento entero, y el patrón sigue apareciendo en cada Slack de ingeniería en el que me cuelo. Esto está pasando a escala.

Cuando escuché el término por primera vez, no me reí. Hice una mueca. Porque esta película ya la he visto.

El déjà vu: ya hicimos esto con las líneas de código

En 2019 escribí en Genbeta Dev un artículo sobre por qué medir la productividad de un programador por las líneas de código que escribe al día era una idea terrible. El argumento era simple: más código no significa mejor código. Un ingeniero senior que refactoriza 500 líneas hasta dejarlas en 50 es objetivamente más productivo que el que mete 2.000 líneas de espagueti que el equipo estará desenredando durante los próximos tres sprints.

Todos asentimos. Todos dijimos «sí, sí, líneas de código: métrica horrible». Los managers lo compartieron en LinkedIn. Se dieron charlas en conferencias. Se escribieron libros.

Y entonces llegó la IA, y aparentemente sufrimos una amnesia colectiva.

Porque el tokenmaxxing es simplemente líneas de código con una gabardina encima. La misma lógica rota, con un envoltorio más brillante. En lugar de «quién escribió más código», ahora preguntamos «quién quemó más tokens». Como si bombardear a Claude Sonnet 4.6 con prompts mal estructurados 47 veces al día te convirtiera en un ingeniero AI-forward.

No lo hace. Te convierte en un ingeniero caro.

Consumo no es impacto

Déjame pintarte dos escenarios.

La Ingeniera A gasta 3.000 tokens en un único prompt bien construido a Claude Sonnet 4.6. Describe el problema con claridad, aporta contexto, especifica restricciones y recibe una solución funcional que revisa, testea y despliega. Tiempo total: 25 minutos. La PR está limpia. Los tests pasan.

El Ingeniero B gasta 40.000 tokens volcando su codebase entero en la ventana de contexto de 1M de Opus porque puede, y luego dispara una tarde caótica de «arregla esto», «no, eso no», «prueba otra vez pero diferente» y «en realidad vuelve a lo que tenías antes». Acaba copiando y pegando una solución que no entiende del todo, y que introduce una regresión que lleva dos días diagnosticar.

¿En el leaderboard? El Ingeniero B es tu campeón de IA. Dadle un trofeo.

Esto no es hipotético. Llevo más de 15 años en desarrollo móvil, y te puedo asegurar que el patrón es siempre el mismo: cada vez que llega una herramienta nueva, alguien en management decide que la mejor forma de impulsar la adopción es medir el volumen de uso. Y todas y cada una de las veces, se optimiza para lo que no toca.

No mides cuántas veces alguien abrió el IDE. No mides cuántos tickets de Jira creó alguien. No mides cuántos mensajes de Slack envió alguien. Entonces, ¿por qué narices ibas a medir cuántos tokens consumió?

Qué deberías estar midiendo

Si de verdad quieres entender si la IA está haciendo a tu organización de ingeniería mejor — y no solo más cara — esto es lo que hay que mirar:

• Time to resolution. ¿Se resuelven los problemas más rápido? No «¿la gente promptea más rápido?», sino ¿se cierran los issues reales antes?
• Calidad de las PRs. ¿Las code reviews van más fluidas? ¿Hay menos rondas de ida y vuelta? ¿Menos comentarios de «esto no cubre el edge case»?
• Reducción de bugs. ¿El código que sale con asistencia de IA es realmente más fiable? ¿O estamos desplegando más rápido y rompiendo más cosas?
• Velocidad de equipo. No velocidad individual — velocidad de equipo. Porque la adopción de IA debería subir el barco entero, no hacer que una persona parezca productiva mientras genera trabajo de limpieza para todos los demás.

Esto encaja con la filosofía de las métricas DORA — medir resultados y estabilidad, no actividad en bruto. No voy a profundizar en ese framework aquí; eso da para un artículo propio, y está en camino. Pero el punto es claro: estas métricas miden resultados. El gasto en tokens mide actividad. Y si llevas más de cinco minutos en gestión de ingeniería, sabes que actividad y resultados a menudo están inversamente correlacionados.

La trampa del leaderboard

Aquí es donde la cosa se pone seria.

Cuando pones un leaderboard, la gente juega al juego del leaderboard. No al juego del valor. No al juego de «voy a usar la herramienta adecuada para el trabajo adecuado». El juego del leaderboard. Esto es la Ley de Goodhart en acción: cuando una medida se convierte en objetivo, deja de ser una buena medida.

Así que déjame hacer unas cuantas preguntas incómodas que nadie en el «comité de adopción de IA» parece estar haciendo:

¿El objetivo real del leaderboard es identificar a quién no se sube al tren? Porque si es así, enhorabuena: estás midiendo la adopción mediante presión social, no creación de valor. Eso no es una estrategia. Eso es hacer sentir culpable a la gente con un dashboard.

¿Qué pasa con la arquitecta senior que no usa IA porque su trabajo — diseño de sistemas, mentoría, alineación entre equipos — no se beneficia del consumo de tokens? ¿Está «atrasada» porque no promptea? ¿O está exactamente donde tiene que estar, haciendo el trabajo que ningún LLM puede hacer?

¿Estás incentivando calidad o volumen? Porque los leaderboards de tokens incentivan volumen. Punto. De la misma manera que las métricas de líneas de código incentivaban codebases inflados y sobreingeniarizados que hacían que todo el mundo pareciera ocupado y nadie pareciera efectivo.

La gamificación funciona cuando la métrica se alinea con el resultado que buscas. Los pasos de una pulsera funcionan para el fitness porque los pasos genuinamente correlacionan con la salud. Los tokens consumidos no correlacionan con el impacto en ingeniería. Correlacionan con la frecuencia con la que alguien le dio a «enviar» en un prompt.

La factura está en camino

Y esta es la parte de la que nadie quiere hablar todavía: el dinero.

Los informes sugieren que hasta un 40% de los presupuestos enterprise de IA se están desperdiciando en ineficiencias: prompts inflados, llamadas redundantes a la API, uso de modelos clase Opus para tareas que Haiku resolvería durmiendo. Las empresas con uso intensivo están quemando entre 200 y 500 dólares por empleado al mes en créditos de API. Multiplica eso por una organización de ingeniería de 500 personas y estás mirando una partida que hace que las antiguas licencias de Jira parezcan calderilla. El gasto global enterprise en IA alcanzó los 2,53 billones de dólares en 2026, y una parte significativa de eso es puro desperdicio disfrazado de adopción.

Gente como Aaron Levie y Andrej Karpathy ya están hablando de «token budgeting» como una disciplina real. Lo que significa que las mismas empresas que hoy reparten trofeos a quien más tokens quema estarán, en seis meses, contratando consultores para averiguar por qué su factura de IA tiene siete cifras y sigue subiendo. Spoiler: el problema no es el coste de los tokens. El problema es que incentivaste a la gente a quemarlos sin criterio.

El leaderboard da, y la revisión financiera quita.

El ciclo se repite

Llevo en tecnología el tiempo suficiente como para haber visto este patrón con cada cambio grande. Llega una herramienta nueva. Management entra en pánico por la adopción. Alguien propone una métrica de vanidad. La métrica se gamifica. La gente optimiza para la métrica en lugar del objetivo. Dos años después, todos fingen que siempre supieron que era mala idea.

Lo vi con el móvil. Lo escribí con las líneas de código. Y ahora lo estoy viendo otra vez con la IA.

La ironía es brutal: tenemos las herramientas de razonamiento más potentes de la historia de la ingeniería de software, y estamos usando la métrica más estúpida posible para evaluar si la gente las usa bien.

El tokenmaxxing no es una estrategia de adopción de IA. Es un cargo cult disfrazado de gestión data-driven.

Mide impacto. Mide resultados. Mide si el trabajo realmente está mejorando.

O no lo hagas. Y dentro de dos años, todos podemos escribir la retrospectiva sobre lo obvio que era.

Imagina la escena: vas conduciendo por una carretera infinita a máxima velocidad. El indicador de la gasolina lleva desde hace varios kilómetros atrás avisando, pero no puedes parar a repostar. Tienes que llegar cuanto antes a tu destino y no hay tiempo para otro asunto. El final: tarde o temprano te quedarás sin combustible, el motor se romperá y tendrás que abandonar ese coche. 

Esta analogía podría servir para ilustrar la apisonadora del día a día de muchas startups, solo centradas en sacar nuevas funcionalidades a cualquier coste. Sin dedicar tiempo y pararse a preguntar a sus desarrolladores de software lo que necesitan para trabajar más eficientemente o qué partes técnicamente les producen mayores de dolores de cabeza.

Aquí hablamos de algo muy amplio, ya que pueden ser desde herramientas software que no tienen, hardware o el propio codebase, la deuda técnica, librerías obsoletas que nunca sacamos tiempo para actualizar. Es decir, cosas que pasamos por alto sin prestar atención. Aquí incluimos procesos de testing, procesos de QA, integración continua y release para conseguir una build, la documentación, el proceso de onboarding de los nuevos miembros o la forma de comunicación con el resto del equipo de producto (diseñadores, Product Manager o Engineering Managers).

¿En qué puntos técnicos debemos mejorar? Obviamente esto no es un KPI sin más, sino que necesitamos un contexto para ayudar a priorizar mejor un roadmap.

¿Cuáles son los puntos que están causando problemas de su trabajo diario? ¿En qué puntos técnicos debemos mejorar? Obviamente esto no es un KPI sin más, sino que necesitamos un contexto para ayudar a priorizar mejor un roadmap. La solución podría ser preguntar a los desarrolladores del equipo qué opinan. Aquí surge la idea de la Developer Survey, no confundir sin más con un indicador de la felicidad de los desarrolladores, engloba muchas más cosas.

Creando una encuesta para ver qué opinan los desarrolladores

En el día a día, en las propias weekly del equipo, las retrospectivas o los 1:1 aparecen temas interesantes para mejorar la productividad y “la felicidad del equipo”. Pero aun así, sigue siendo difícil tener algo específico que nos ayude a tomar decisiones, acometer action point y priorizar ciertas tareas técnicas por encima de las feature que el producto demanda.

Tener un equipo centrado en el tooling, la arquitectura y que vaya más allá de las propias features de producto ayuda bastante. Llamémosle equipo de Core, Tooling, Staff o Platform, depende de la compañía. 

A la hora de crear un roadmap puramente técnico necesitamos priorizar un gran número de tareas que irán surgiendo y afectará a distintas áreas. Esto solo se podría conseguir teniendo unos indicadores concretos que identifiquen el problema, el objetivo a solucionar y las acciones a aplicar.

Para ello, un punto de partida es crear esa encuesta dirigida a los desarrolladores del equipo sobre distintas facetas. Tanto de producto como sobre asuntos técnicos y de la salud del proyecto. Esto último es fundamental para anticiparnos a problemas futuros que el día a día frenético oculta.

Lo primero que deberíamos hacer es dividir los temas que nos interesan. El Joel Test es un buen punto de partida. Aquí viene un ejemplo más amplio que nos podría servir de guía:

• El entorno de desarrollo. Herramientas necesarias, documentación de onboarding al equipo, documentación de procesos internos, etc.
• Codebase: grado de satisfacción con el código actual, posibles refactors, partes de la arquitectura que deberíamos mejorar, cómo afecta el código legacy para entregar nuevas funcionalidades, errores comunes, etc.
• Code Review: proceso de revisión de código, Pull Request, calidad del código entregado.
• Testing: entorno de ejecución local y en CI, tipos de test usados (UI o Unit)
• Entorno de pruebas: entornos de pre producción, staging, entornos locales de ejecución.
• CI: uso de la integración continua, grado de las satisfacción de la infraestructura
• Proceso de release: principales cuellos de botella, facilidad para hacer builds, despliegue a los usuarios finales
• Documentación: grado de satisfacción general, temas que deberíamos documentar.
• Feedback del equipo: grado de felicidad, coordinación, satisfacción del trabajo hecho.
• Trabajo en remoto: herramientas de comunicación, coordinación, sincronización, meetings, etc.
• Futuros desarrollos: nuevos framework, mejoras en la arquitectura, futuras pruebas de concepto, priorización de las áreas de investigación y desarrollo.

Este listado de temas cubre un amplio abanico de asuntos que nos interesa evaluar dentro del equipo. Saber cuál es la salud de cada uno de ellos y detectar lo que no estamos haciendo bien y reforzar lo positivo.

Después de tener ese listado de temas a evaluar, similar al descrito arriba, lo interesante es empezar a formular las preguntas necesarias. Os comparto una plantillas en markdown con algunas de las preguntas que hemos ido a haciendo con el tiempo en el equipo de desarrollo.

¿Preguntas de valoración o preguntas de texto libre?

Después de tener el listado de temas, lo ideal es usar una combinación de preguntas en las que podamos calcular una valoración y otro conjunto de preguntas de texto libre para que los desarrolladores puedan complementar sus valoraciones, además de dar ideas explayándose todo lo que quieran.

Para los valores numéricos podemos usar una escala NPS (0-10) o Likert (1-5). Por la naturaleza de las preguntas que tenemos en la encuesta, nos decantamos por este último modelo.

Likert es una escala psicométrica comúnmente utilizada en cuestionarios y es la escala de uso más amplio en encuestas de investigación. El formato típico de elementos con 5 niveles serían: totalmente satisfecho, satisfecho, neutral, insatisfecho o totalmente satisfecho.

Con esta plantilla podéis jugar con un conjunto de combinaciones: satisfacción, acuerdo, relevancia, frecuencia o importancia. De hecho, será con este tipo de valoraciones con la que intentaremos intercalar las preguntas a los ingenieros para tener una foto más amplia.

Recomendaciones a la hora de rellenar la encuesta

Vamos a ir preparando el camino. 

Porcentaje de encuestas rellenadas. Todo depende del tamaño del equipo. Obviamente para un equipo de 4-6 personas podríamos decidir que todo el mundo debería completarla, es una obligación. En equipos más grandes de 20-50 personas, quizás no sea posible que todo el mundo lo rellene, aunque un 80% sería adecuado para no dejar escapar ningún punto de vista.

Tiempo para completar la encuesta. Da tiempo a tu equipo para hacerlo. Suelen ser preguntas largas, por lo tanto, mínimo una semana para que el equipo pueda ir rellenándola con calma. Tienen que estar avisados.

Define cómo debe ser el formato de las respuestas esperado. Fija ciertas recomendaciones antes de completar las preguntas de texto libre. Explica al equipo que algunas preguntas requieren redactar o  un análisis con antelación. No valen las respuestas: “Ahora mismo no se me ocurre nada”, “No tengo nada en mente”, etc. Esta encuesta no es una encuesta rápida que te hacen al salir del supermercado.

Deja claro que la encuesta tiene un objetivo y un plan posterior. Esto es importante, ya que sino el equipo podría estar desanimado y no verá ninguna utilidad en la encuesta. Explica el plan que tienes cuando obtengas los resultados de la encuesta y cómo se crearán los action points necesarios.

¿Qué cosas queremos averiguar con la encuesta?

Lo más obvio, los problemas que tiene el equipo. Los temas más conflictivos en lo que probablemente recibiremos puntuaciones más bajas: documentación, comunicación entre teams, falta de conocimiento en el uso de herramientas o impedimentos para hacer de una forma más eficiente el trabajo. 

También, deberíamos obtener ideas de nuevas tareas que hacer: refactors de las piezas más conflictivas, herramientas para automatizar ciertos aspectos más ásperos, futuras ideas de investigación o pruebas de concepto, etc. Y sin olvidarnos de la adopción de nuevas tecnologías, ya sean lenguajes, framework, librerías o paradigmas que mantengan la motivación del equipo y veamos que son necesarias.

Con todos esos temas nuestro objetivo será construir un plan de acción, ya sea priorizando esos asuntos en el roadmap. Dando un peso mayor a esas tareas técnicas que hasta ahora estaban quedando ocultas por el día a día de las features de producto.

Para ello después de recopilar los resultados, siéntate con el equipo para acordar los action point. Si puedes fija algunos action point ligados a ciertas valoraciones para poder validar que hemos conseguido el objetivo. Por ejemplo: aumentar el grado de satisfacción de la documentación que tiene el equipo o la sensación de velocidad a la hora de revisar PRs. Puede que estas sean las más fáciles, pero son un buen punto de partida.

En resumen: crea tu primera encuesta de desarrolladores y observa los resultados, algunos puede que te sorprendan

Como hemos comentado anteriormente, no hay que olvidar las otras vías para obtener feedback de los desarrolladores (1:1, weeklies, PR, etc..), pero las encuestas nos permite documentar y crear unos indicadores de la satisfacción del equipo fácilmente. Con estas “developer surveys” tendremos una excelente foto general de la marcha del equipo y nos servirán de motivación para ayudarle a crecer.

Puedes lanzarte creando una encuesta sencilla con un par de temas que preocupan a los desarrolladores. Lo fundamental es que después de analizar y recopilar los datos tengas un plan de acción. Empresas como Linkedin o Shopify basan su estrategia de tooling en las encuestas de anuales o semestrales de Developer Survey.

Puedes usar la plantilla que comentaba más arriba para crear tu primera encuesta. Elige las preguntas que mejor se adapten a tu equipo o dale una vuelta. 

Elige algún servicio de encuesta que te permita crear un formulario online vistoso y fácil de rellenar, por ejemplo, Google Forms o Typeform que ya cuenta con ciertas plantillas permitiendo exportar los resultados y resumirlos de forma sencilla. 

Y por supuesto, la encuesta de desarrolladores también puede ser usada para mejorarla así misma en sucesivas iteraciones, así que reserva algunas preguntas para consultar feedback sobre el propio cuestionario.

Foto Glenn Carstens-Peters on Unsplash

This article was also published in English Ask the Developers What Headaches Really They are Facing

El futuro en el que cualquier persona sea capaz de programar probablemente nunca llegue. Y siendo realistas, aunque tuviéramos unas bases mínimas en alguno de estos lenguajes casi omnipresentes, como Python o JavaScript, no sería suficiente para lanzarse a construir una app o una web desde cero. En el mejor de los casos conseguiremos hacer unos bonitos pet project, más cercanos a una práctica de universidad que algo sobre lo que construir un negocio o sostener el flujo de trabajo de tu empresa.

Dentro de la industria del desarrollo software crecen cada vez más las herramientas No-Code y Low-Code. Sin tirar ni una sola línea de código, ayudan a arrancar algo bastante decente. No necesitar saber programar para crear aplicaciones es una idea muy atractiva.

De hecho, muchas compañías ya las están empleando actualmente en sus aplicaciones internas o creando procesos automáticos que no podrían permitirse de otro modo. Básicamente porque no cuentan con el capital laboral suficiente (desarrolladores y diseñadores de interacción) o porque aún son pruebas de concepto en el más puro estilo bootstrapping. 

Plataformas SaaS para prototipar, construir y automatizar en la nube sin tirar una línea de código

Este tipo de herramientas SaaS son interfaces visuales que utilizan componentes ya creados, conectados entre sí y fácilmente reutilizables. Nos permiten construir flujos basados en acciones de usuario, o en ciertas reglas previamente definidas.

Generalmente, el camino que se suele seguir es crear un experimento tipo prototipo, probarlo y, finalmente, distribuirlo a los usuarios finales (deploy). Más tarde seremos capaces de pensar si graduar ese experimento a algo dentro de nuestro propio stack tecnológico implicando a los desarrolladores. Mientras tanto podemos seguir usando estos third parties como si fuera nuestro propio sistema.

Podemos encontrar diferentes plataformas integradas en el negocio de muchas compañías como puede ser un Typeform para crear un formulario vitaminado, y perfectamente segmentado, que después exportemos a un Google Spreadsheet, AirTable o incluso analizamos en algún proceso de machine learning en la nube.

Por otro lado, la automatización se ha abierto camino con fuerza usando Zapier o IFTTT para que cuando cualquier trigger (evento) realice ciertas acciones como: Enviar un email por Mailchimp o Twilio, guardar un fichero multimedia, actualizar unas gráficas en un dashboard con Google Spreadsheet, etc.

Los ejemplos anteriormente mencionados son plataformas SaaS que permiten hacer diversas acciones o procesos que hasta ahora necesitarían una infraestructura de servicios difícil de configurar y nada rentable para una pequeña empresa. De hecho, el modelo de negocio de estas plataformas se centra en ofrecer servicios cada vez más personalizados sin necesidad de integrar ni una sola línea de código. Simplemente, ofreciendo decenas de integraciones a otros servicios que sirvan de fuente de datos o de canal de comunicación con el usuario final.

Todos tenemos ya muy interiorizados que la mayoría de webs o aplicaciones están alojadas en la nube, ya sean en Google Cloud, AWS o Azure de Microsoft, por ejemplo. Ahora bien, también tenemos que tener en la mente que todos esos procesos asociados proceden de otros servicios SaaS. Todos los correos electrónicos, SMS o Push Notifications que recibimos como usuarios procede de Mailchimp, Salesforce, Twilio, Amazon SNS, etc. 

Tampoco las acciones que han originado el envío de esas comunicaciones han necesitado en la mayor parte de los casos ni un par de líneas de código ni complejas colas de eventos. Muchos de ellos proceden de servicios como Firebase o AWS, por ejemplo, capaces de generar audiencias basadas en las herramientas de analíticas asociadas. Aunque si necesitamos algo muy específico tenemos la posibilidad de incluir pequeños scripts o fragmentos de código en la nube como Cloud Functions o Lambdas.

¿Qué diferencia a las herramientas No-Code de las Low-Code?

Es importante hacer una clara diferenciación sobre que No-Code y Low-Code no es lo mismo. En el caso de las plataformas Low-Code necesitamos un mínimo de conocimientos de programación. En cambio, en No-Code básicamente nos movemos con interfaces visuales y no veremos, salvo que queramos algo avanzando, una línea de código.

Low-Code es un empujón tremendo para programadores con menos conocimientos e, incluso, una excelente forma de lanzar algo rápido para programadores más avanzados que puedan trabajar sobre ello más adelante, creando integraciones con código más complejo. Es también una progresión natural en el dominio del desarrollo de software donde los lenguajes cada vez son más abstractos añadiendo capas y capas para centrarse más en el qué queremos hacer que en el cómo.

En el caso de no-code nos centramos en el sentido de qué queremos que el usuario vea. Así de forma abstracta las herramientas pueden crear, según nuestras indicaciones, las interfaces visuales multiplataformas de nuestra idea. Ya sea una app web, nativa o incluso un intercambio de mensajes por slack o por alguno de los asistentes de voz.

«El concepto low-code no es algo que no hayamos visto antes, sino que es más bien de la época de los años 90«. Así lo describían recientemente en un artículo en Spectrum IEEE. Podemos recordar esas herramientas CASE y ese vetusto framework de Microsoft Visual Basic que muchos aún recordarán. Ahora mismo, hay herramientas que intentan emular este planteamiento aunque salvando las diferencias como son las Power Apps de Microsoft, Oracle Visual Builder o Salesforce Lightning Platform. Incluso Google hizo una adquisición reciente como AppSheet, una plataforma no-code para crear apps móviles. 

Una de las herramientas de desarrollo web que más están pegando fuerte es Webflow capaz de crear complejas webs sin apenas poner un par de líneas. Es como dicen sus creadores “el Photoshop del desarrollo front”, puedes diseñar qué van a ver los usuarios simplemente arrastrando componentes, conectando flujos y reutilizando todo lo que la plataforma te provee. Sin olvidar las integraciones externas que más complejidad supondría. Podéis ver en su web decenas de tutoriales al respecto.

Los tres elementos fundamentales de una plataforma No-Code

En definitiva, este tipo de plataformas No-Code tienen que tener los siguientes elementos para permitir ese empoderamientos de los usuarios sin la necesidad de escribir una sola línea de código.

User Interface Builder

Webflow es un buen ejemplo, trabajaremos con un conjunto de componentes ya definidos a través de una vistosa interfaz visual más cercana a una herramienta de diseño que de programación. Funciona simplemente arrastrarlo y posicionado donde queramos que se muestre el elemento al usuario. Ya sea una caja con un párrafo, un par de imágenes, un formulario o un layout dinámico que dependa de una API que nos provea los datos. Podemos combinar todos esos elementos y reutilizarlos en cada pantalla.

Visual Modeling

Aparte de arrastrar y soltar elementos sobre un layout tenemos que definir pasos, flujos y relaciones entre los elementos. Incluso crear una jerarquía entre los componentes y los modelos de datos. Por lo que la mayoría de estas herramientas permiten visualizar y configurar por medio de diagramas la relación entre los elementos.

Integraciones

Es fundamental que nuestras aplicaciones se comuniquen con otras herramientas, sobre todo esas herramientas SaaS que mencionamos al principio para automatizar el proceso o comunicarse con el usuario.

¿Por dónde empezar con estas herramientas de “programación” sin tirar una línea de código?

Lo primero que sería pensar algún proceso que podamos automatizar. De este modo, podemos empezar a familiarizarnos con herramientas de automatización como Zapier, IFTTT o Microsoft Flow. Creando unos flujos sencillos que, por ejemplo, consulten el email y escriban un registro en un spreadsheet, que disparen algún mensaje automático o integre un pequeño CMS que procese acciones dependiendo del estado en el que coloquemos cada uno de los elementos, por ejemplo. Ya sean los productos de una tienda virtual o en el board de email pendientes a clientes o contactos. Hay centenares de integración desde Gmail. YouTube, Spreadsheet, Drive, Dropbox, Salesforce, Stripe, redes sociales o hasta el envío de SMS, pushes o creación de bases de datos flexibles como Airtable. 

Hace poco descubrí la web de Codeless How dónde puedes ver pequeños tutoriales en vídeo de como crear un conjunto de integraciones que automaticen un montón de procesos como un calendar chatbot, un completo No-Code MVP, un personal Assistant, etc.. Todo ello usando las herramientas anteriores.

Después intentaría explorar alguna de las herramientas que permitan crear una presencia digital, es decir, una web o una app. Aquí mis favoritos son Webflow, AppSheet y Microsoft Power Apps. 

Por supuesto, las plataformas No-Code no significan reemplazar completamente a los desarrolladores de software. Más bien, representan una evolución de las herramientas software del ecosistema que permiten empoderar a cada vez más personas en la cadena de construcción de software. Sobre todo, permitiendo centrar en lo más importante e iterar rápido con prototipos funcionales para valorar si una idea es factible antes de desarrollar por código o integrar en nuestro strack de producto.

Photo by Émile Perron on Unsplash

Hace unas semanas tuve la oportunidad de probar las llaves de seguridad físicas Titan Security Keys desarrolladas por Google. Aquí está mi reseña en Genbeta, explicándolo a fondo. Me gustaría resumir algunas de las cosas que tienes que tener en cuenta antes de comprarla y resolver algunas dudas sobre el uso de este tipo de llaves físicas de seguridad.

Primero, tienes que tener en cuenta que a día de hoy estas llaves de seguridad sólo sirven como sistema adicional para la verificación en dos pasos o Two Factor Authentication (2FA). Tanto en la cuenta de Google, Twitter o Github donde he probado configurarla es necesario tener previamente alguna forma de verificación previa.

Sobre estas formas adicionales, puedes usar tanto Google Authenticator, 1Password para almacenar esas claves temporales o el más rudimentario uso de los SMS. En el caso de Google, llevan tiempo avanzando en el tema de usar el móvil como sistema de verificación, ya sea con una Push Notification o con los móviles Pixel como si fuera un llave física usando el hardware de Titan M presente también en dichos dispositivos móviles.

Por otro lado, Google está desarrollando un programa avanzado para activistas, periodistas, directivos o responsables de infraestructura que permite un control más estricto en el que el uso de estas llaves forma un papel fundamental. La idea es evitar posibles ataques a distancia o phishing a mediante los códigos de seguridad que por ingeniería social pueden ser vulnerables. Con este medio sólo puedes acceder a tu cuenta si tienes en tu poder una llave física. Podéis apuntaros al programa beta para cuando sea accesible a todo el mundo.

Además de las Titan Security Keys existen otras llaves en el mercado, las más conocidas las Yubico

Probablemente, una de las más conocidas sea las Yubico. De hecho, es una de las empresas partner del proyecto de Google, cuya llave física de seguridad USB-C está basada en las suyas. Las actuales Titan Security Keys de Google viene en dos formatos: una USB-A con NFC incluido y otra Bluetooth, solamente.

Aquí en este post de The Verge podéis ver un amplio abanico de opciones. En mi opinión, sería imprescindible que como mínimo si adquirimos una llave física a día de hoy sea con USB-C y NFC.

Todas estas llaves están basadas en el estándar de seguridad FIDO (Fast Identification Online). Una alianza de varias compañías que buscan simplificar y securizar el acceso a las cuentas de usuario online. Su objetivo final es eliminar el uso del password debido a sus riesgos obvios: muchos de los passwords no son robustos, los usuarios los suelen reutilizar y son vulnerables a ataques a distancia por fuerza bruta o ingeniería social.

Aquí juega un papel fundamental WebAuth como el estándar de la W3C que utilizan los navegadores modernos como Chrome, Firefox, Opera o Edge para utilizar las llaves físicas en las web que usen estos sistemas.

¿En qué servicios o apps puedo usar las llaves de seguridad físicas?

En esta web podemos encontrar un amplio listado de servicios agrupados por sectores que hacen uso de las llaves de autenticación: WebAuthn, FIDO u OTP (One Time Passwords).

Con las Titan Security Keys he podido probarlo en Google, Github y Twitter. Aquí puedes ver los dispositivos y navegadores que soporta.

Obviamente, Google es la que mejor interfaz de usuario tiene y mejor cuida la experiencia de configuración. Puedes agregar un gran número de formas de autenticarnos adicionales: SMS, mensaje de Google en nuestro móvil, la propia app de Authenticator o los códigos de seguridad. Por supuesto, debemos introducir previamente el usuario y contraseña, de eso de momento no podemos prescindir.

El proceso de instalación es bastante sencillo. Elegimos la nueva forma de autenticación, permitimos al navegador leer el hadrware asociado del USB y vinculamos esa llave con su correspondiente certificado privado (interno) con nuestra cuenta. No olvides de asignarle un nombre para poder identificarla.

Github también tiene una experiencia bastante limpia y permite añadir esta forma de autenticación para acceder a nuestra cuenta. Twitter hace lo mismo, aunque sólo desde el navegador web, nada de apps.

Una de las preguntas que más curiosidad me produjo al realizar el análisis fue por qué muchas apps no tienen integrado esto aún. Parece que al menos en Android si es posible, ya que hay disponible un conjunto de APIs para manejar estos eventos e integrarlo en el propio flujo de autenticación. Es posible utilizarlos en los terminales que tengan Android 5.0 y dispongan de NFC.

Sea por la urgencia o por el deseo de matar al proyecto. Lo cierto es que muchos se apresuraron a titular esta semana artículos como “Google retira del mercado las Google Glass”, “Google abandona en una esquina las Google Glass”, “Google Glass fracasa”, etc.. Titulares confusos que no entran en profundidad en el tema.

En lugar de remarcar la apertura de una nueva etapa, se centraban en el fracaso de un gadget experimental. Tratándolo como si fuera un producto final que se retiraba del mercado, cuando aún no ha sido lanzado a los usuarios, sólo a los desarrolladores.

Todo surge del final de una etapa: Google Glass, realmente se “gradua”. Es decir pasa de la división experimental de Google X a un departamento propio, donde se le dará el enfoque comercial pensando en los usuarios finales. Dirigido por Tony Fadell (ahora en Google) creador de Nest y responsable del iPod. Un peso pesado en la industria que en cualquier otro producto hubiera sido tomado con euforia al tener en cuenta la experiencia y la visión de producto que tiene la mente de Tony Fadell.

Este movimiento implica con total seguridad que el producto que salga a las tiendas sea diferente a las Google Glass edición Explorer actuales, sólo aptas para desarrolladores y algunos Glasshole que ayudaron a popularizar a esta nueva tribu de nerds.

El hype de las Google Glass se esfumó

El hype de Google Glass se ha ido diluyendo. Desde esa esperpéntica Keynote de la Google I/O de 2012 con Sergei Brin saltando en paracaídas sobre el Moscone West Center con las Google Glass puestas, una Google I/O 2013 plagada de glasses por todos los lados (cada ingeniero de Google tenía las suyas), en esta tuve la oportunidad de probarlas, En la Google I/O 2014 donde ni se mencionó una palabra en la Keynote.

El experimento ha acabado, pero no sus desarrollos

Un laboratorio de experimental funciona así. Después de conseguir todo el feedback necesario implicando a desarrolladores interesados en el producto y tomar ideas para un producto final se da por finalizado, en este caso el programa Google Glass Explorer. No era más que otro experimento más. Una prueba de concepto con una serie de desarrolladores entusiastas.

No implica que todo el trabajo realizado se tire a la basura. Recordemos todo lo que se ha lanzado para que los desarrolladores creen sus aplicaciones. Tenemos el Glassware y su integración con Android. Mirror API y todo un subconjunto de elementos similares con Android Wear (quizás el foco actual a nivel de usuario de Google).

Retos para la nueva versión de Google Glass en 2015

Habrá que esperar en este 2015 la evolución para ver si todas esas apps sigue siendo compatibles con el nuevo modelo. Tony Fadell tiene varios retos interesantes para cocinar un producto final vendible en el mercado junto a la que sigue siendo responsable directa, Ivy Ross, muy preocupada por el tema estético y diseño.

• Por un lado, luchar con el mal endémico de todos los wearables: la escasa autonomía. Recordemos que las Glass no llegaba a una 4 o 5 horas.

• Enfocar un producto complicado a nivel de privacidad. Muchos gobiernos ya se aventuraban a legislar sobre este tipo de dispositivos que no avisan de que estás siendo grabado. Aunque nos hayamos vuelto locos como si fuera un capítulo de Black Mirror, todo el mundo llevamos una cámara en nuestro teléfonos móviles.

• Hacerlo atractivo estéticamente. Rediseñar un gadget que no es nada fácil de llevar en la vida cotidiana (aunque haya decenas de vídeo sobre ello). O tirar definitivamente por el uso profesional como su programa Glass for Work (ojo a esto) en ámbitos en que puede ser una ayuda y no tenga ninguna limitación estética o funcional.

• La compatibilidad con otros productos de la compañía como Android Wear o el rediseño de su interfaz de uso. Esto implica todos los layout de tarjetas menús, etc.. vistos ya en las apps ya lanzadas.

Quizás 2015 sea el año de Google Glass o no. Lo cierto, es que aún no ha muerto, aunque nos hayamos precipitado a matarlo.

Hace unos días hicimos una pequeña introducción en formato charla en el curso de desarrollo de aplicaciones iOS de Ironhack sobre el desarrollo de la aplicación móvil de idealista.

Una de las partes fundamentales de una aplicación es el backend, así que con unas breves pinceladas explicamos el mobile backend actual de idealista (Android e iOS) (fueron tan sólo 20 minutos más preguntas). Por una parte hablamos de nuestra API usada por las aplicaciones móviles y, por otra, sobre el sistema de notificaciones push que creamos adhoc para enviar a aplicaciones iOS y Android. El objetivo era dar a conocer la problemática que representa para un desarrollador de móviles toda esa parte «oscura» del backend de su app.

Hicimos una breve comparativa, más bien en el transcurso de la charla, sobre las distintas alternativas como Parse, pero en el momento de realizar el proyecto de alertas de nuevos inmuebles decidimos crear nuestra librería de envío (apoyados en el código de Javapns y GCM) y el proceso en backend de envío alertas simultáneamente para Android e iOS.

Según BiciMad, el éxito de su lanzamiento en el primer día tumbó sus sistemas informáticos. ¿En serio que 1.000 usuarios no concurrentes a lo largo de un día fueron capaces de hacerlo? Recordemos que es un sistema que debería estar planteado para dar servicio a 123 estaciones con 1.580 bicicletas de forma ininterrumpida 24 horas.

Fallos técnicos y mal planteamiento de la plataforma

Hay que distinguir el apelativo de fallos informáticos de un mal planteamiento técnico de la plataforma. En el primero podemos asumir que durante un tiempo tengan problemas con la carga de los servidores, fallos de conectividad o algun bug descubierto. Pero después de ver los errores, agujeros de seguridad y la pobre implementación del sistema informático de BiciMad está claro que no se hizo un análisis de lo que suponía el despliegue técnico de este proyecto en el que la tecnología forma un papel fundamental.Parece que el estándar de calidad de la administración es mucho más bajo de lo que podríamos pensar.

Enbicipormadrid hace un excelente resumen de las 12 pruebas que tiene que superar el usuario de BiciMad, prácticamente todas son por problemas de la plataforma, nadie se queja de las bicicletas, por ejemplo. Entre ellas nos encontramos el registro, conseguir el descuento de abono transporte, obtener el código para recoger la tarjeta, incluso descifrar el código con mayúsculas y minúsculas confusas, encontrar un totém operativo o, finalmente, devolver la bici sin problemas.

@bicimad He escrito un post con una auditoria muy generica de seguridad de vuestros sitemas: http://t.co/N6zEczEKol Un saludo.

— CityBikes (@ctbikes)

June 24, 2014

¿Qué debería manejar el sistema informático de Bicimad y no hace bien?

Inscripciones de usuarios. Nadie pensó que si un usuario se registra por la web o el totem puede que no reciba el código de recogida de abono al instante. Asumamos que existe un fallo en el servidor de correo o SMS y no se envían. ¿No sería más fácil que el usuario pueda consultarlo en la web o incluso solicitar el reenvío de ese código en otro momento. De esta forma se podría evitar que cientos de usuarios tengan que reclamar el envío del código por el teléfono de incidencias. Otro asunto es la expedición del abono en la propia estación que provoca problemas, algo que debería ser instantáneo al asociar el identificador del usuario con la tarjeta expedida.

Vaya, 5 dias después recibo el código para recoger el abono de @BiciMAD. Probaremos si funciona

— Txema (@durbon)

June 27, 2014

Monitorización de las estaciones, es decir, número de bicicletas libres y plazas disponibles de aparcamiento. Posiblemente el punto más delicado de información. La web de BiciMad se supone que debería contar con un mapa en tiempo real con la información de cada base mostrando su disponibilidad pero fue eliminado por su pésimo rendimiento.

Totem. Curioso las instalaciones de una versión completa de escritorio de Ubuntu, además con una versión desatentida, (hasta con libreoffice instalado) en los totem. Matar moscas a cañonazos. Bien, por el software libre pero mal por elegir una distribución que debería ser más limitada básicamente para mostrar la aplicación del totem y evitarían imagenes como estas.

@Bici_MAD @BiciMAD @enbicipormadrid … Celeron con 8gb de RAM… Con Ubuntu. #moscasacañonazos ??? pic.twitter.com/l6fWdmYPu7

— Manu Arenas (@digitalcual)

June 26, 2014

Anclajes de las bicicletas en las estaciones. Una cosa es que la web lenta y otra que todos las estaciones estén caídas por el mismo problema. Hay que hacer una separación clara de tu backend y de lo que se expone. Recordemos el riesgo que supone que falle un sistema que requiere de esos anclajes inteligentes para dejar las bicicletas. Un usuario puede llegar a una estación que no funcione y ser incapaz de dejar la bicicleta en el anclaje con el consiguiente riesgo de que sea robada o que se le cargue un tiempo extra. La realidad es que es difícil encontrar una estación que funcione correctamente, sólo las “sagradas” que cuenta con un operario de Bonopark está operativas.

@BiciMAD @enbicipormadrid en méndez Álvaro sí la coge. Cuatro puestos he tenido que recorrer y probar. Me habrá cobrado la hora entera…

— Rodrigo Alfaro (@rodricels)

June 23, 2014

La pseudo API que usa la app de Bicimad (sólo Android, de momento) no dispone de ninguna seguridad intermedia, key, token ni https para securizar las llamadas de usuario, lo que representa un auténtico problema de seguridad para ciertas peticiones con datos de usuario. Se abusa del envío del DNI (un grave error que se usado como identificador en el modelo de datos del sistema).

Detalles que han aflorado los errores, trazas de excepciones es algo curioso. La web parece haber sido implementada con Spring Framework (un robusto framework si se usa bien) quizás demasiado si vemos lo que es la web. Pero lo grave es que la pseudo API de Bicimad está hecha en PHP no tengo claro si a pelo o con framework mediante. (Oh, wait) Lo hizo gente distinta seguramente. Quizás no sabía que Spring cuenta potentes herramientas para crear APIs RESTful.

Sin API pública ¿dónde está el Open Data?

Después de una petición pública se ha conseguid que se publique el dataset de la localización de las estaciones de Bicimad, pero eso no es suficiente. Un servicio como BiciMad debería contar una API pública para desarrolladores, lo cual permitiría integrar la información de alquiler de bicicletas en aplicaciones como Citymapper o crear aplicaciones, por ejemplo, como el mapa de disponibilidad creado usando CartoDB por @iamzenitraM usando la pseudo API actual de la app móvil.

¿Cómo suele crearse una API? Hace un par de años con el auge de las apps móviles muchas empresas se lanzaban a crear una API con el simple propósito de comunicar y obtener datos entre la web y las aplicaciones móviles (iPhone y Android). Esta API era muy básica, creada a partir de una serie de objetos sencillos con información limitada de lo que se veía en la web (el único producto para los consumers durante esos años).

Nuestro primitivo servicio de acceso API, pensado para un reducido número de dispositivos, crece y es la base de esas aplicaciones móviles, por lo tanto, tiene que evolucionar. Pasa durante un tiempo por un lavado de cara, una refactorización y algún que otro versionados. Cada vez va incorporando más funcionalidades, es la base central sobre la que se sustenta el desarrollo móvil de la compañía. Sin ella difícilmente se puede crear una aplicación integrada al ecosistema de negocio de la compañía.

La dependencia de las apps móviles hacia la API es tal que, que empieza a evolucionar a conceptos más cercanos al backend específico de las aplicaciones, como el acuñado recientemente MBaaS que reflejan la necesidad de servicios en la nube que proveen notificaciones push, almacenamiento de datos, gestión de sesiones y autenticación de usuarios.

¿Una API debe considerarse un producto y dejar de ser el backend oscuro de las apps?

A nivel de negocio tiene potencial para ser otra fuente de ingresos: se puede vender, otras empresas están dispuestas a crear productos entorno. La API pasa a ser una plataforma en la que desarrolladores pueden crear aplicaciones, incluso mejores que la nuestra, será entonces una especie de competencia pero que nos dará visibilidad a nuestro principal producto de negocio.

Lo más importante, para ser considerado un producto tiene que ser tratado como tal, olvidar la concepción simplista de que es un mero servicio REST.

Como producto tiene una consistencia propia, tiene sentido entonces que se despliegue aparte. Que tenga sus propios recursos y que adquiera cada vez más peso.

Imagen | Kin Lane (API Evangelist)

Me traen entrañables recuerdos esos animales en las portadas de los libros de O’Reilly. He sido mucho de libros: comprarme un libro y devorarlo para aprender algún lenguaje, tecnología, etc… o algunas veces sólo por tenerlo, debo reconocerlo. De los que tengo, y son unos cuantos de O’Reilly, siempre me han acompañado algunos de ellos reposados en la mesa o en la pila de libros.

¿Pero de dónde vienen esos animales? ¿Qué tienen que ver con Javascript, Perl, Apache, Tomcat, etc…? Pues bien, tenía pendiente un post en evernote hablando de los orígenes de esas portadas de O’Reilly que he publicado en Genbeta Dev.

A mediados de los años ochenta, Edie Freedman, una de las primeras diseñadores de las portadas de los libros de O’Reilly, presentó una curiosa idea que serviría para diferenciar a los libros de la editorial del resto en las estanterías. A partir de una láminas de animales empezó a crear los primeros bocetos. Una relación entre el sentimiento de una dibujante de la portada, que poco sabía de lo que se hablaba en el libro, las características del animal y el sonido de los títulos o términos empleados cuyo sonido al pronunciarlos le recordaba a la tecnología.

Podéis ver un listado de los animales de todas las portadas usadas en los libros de O’Reilly.

Hace unos años se creó un herramienta para generar portadas curiosas con el mismo formato, una pena que parece que ya no está disponible. ¿alguien lo recupera?

Describir de la forma más simple las notificaciones push nos llevaría a calificarlas como “pequeñas interrupciones aleatorias” que llegan a nuestro móvil con píldoras de información. La vida hiperconectada alienta a ir acumulando aplicaciones que traen consigo más pequeñas burbujitas, globos y iconos en la barra de estado. Ahora mismo es la funcionalidad estrella que toda aplicación móvil quiere tener. Son útiles, pero hay que tener cuidado de no abusar de ellas.

Las notificaciones tienen que aportar valor. Su principal característica es la inmediatez y la información en forma compacta que ofrece.

El alcance de una notificación es variable según el evento o alerta al que vaya ligada:

• Suscripción a un topic general. Ese mismo mensaje de notificación se enviará a todos los usuarios que la tengan activa. Ejemplos: resultados de fútbol, avisos de lluvia, etc…

• Notificaciones sobre las acciones o eventos que el usuario ha realizado. El ejemplo típico de Twitter o Facebook que nos avisan de los comentarios o retuits de nuestros contactos.

• Notificaciones push masivas. Todos los usuarios recibirán la misma notificación. Ejemplos: nueva actualización de la aplicación.

La utilidad de las notificaciones push pueden resquebrajarse cuando son usadas sin una estrategia definida. Buceando entre varias aplicaciones y algunas experiencias, por lo general malas, aquí van algunos errores comunes que me gustaría reseñar.

• Cuando una notificaciones no es inmediata pasa a ser un mero recordatorio

Que te llegue antes un correo que una notificación push chirría mucho. Esas notificaciones push deberían pasar a denominarse recordatorios. ¿Si ya lo tenemos en el correo del móvil por qué usar una notificación push? Ese debería ser la pregunta para esforzarse en aportar valor. La primera debe ser la inmediatez y la segunda poder aprovechar al máximo la aplicación.

• No preguntar a los usuarios sobre sus preferencias

Abusar de la simplicidad lleva a ignorar los ajustes personalizados de usuario. Errores como no ser transparente en cuántas notificaciones quiere el usuario recibir, a qué hora no quiere ser molestado, o el mero hecho de avisar que si activas tal aviso los recibirás tanto en el móvil en forma de notificación como de correo electrónico.

• No completar la notificación con alguna acción o contenido en la propia app

Cuando nos llega una notificación, por lo general, tan sólo con el texto que contiene ya sabemos de que se trata. Si es de correo al pinchar sobre ella vamos al mensaje en nuestra bandeja de entrada, si es una mención vamos directamente al tuit, etc.. pero hay algunas apps que no tienen definida una acción concreta. Estas aplicaciones nos llevan a la home y luego allí tenemos que buscarnos la vida. Suerte.

Un fallo típico es no aprovechar la llegada de la notificación para hacer cierta carga en background para que al llegar a la notificación no tengamos que esperar a que se cargue el contenido relacionado.

• No sincronizar las notificaciones entre dispositivos

Si tienes un segundo dispositivo con las notificaciones activas de la misma app, seguro que te pasas el día borrando notificaciones que ya has visto en otro dispositivo. Es un fallo muy típico y que pasa en las mejores aplicaciones. Es complicado de solucionar pero el usuario supone una enorme frustración. Lo único que puede mejorarlo es que al menos borrar las notificaciones/avisos dentro de la app se hagan de la forma más cómoda y rápida posible.

• Enviar la misma notificación a todos los usuarios sin contextualizar o marcar un target específico

Es complicado manejar notificaciones en aplicaciones que tienen un público multi-país o multi-idioma. Pero por ello no debemos dejarlo pasar y no contextualizar los mensajes. El usuario espera recibir mensajes personalizados y no escritos de cualquier manera en otro idioma o huso horario.

• Spamear o abusar del autombo

Muchas empresas ven que sus boletines, mailing, etc… vía email ya no tienen la misma convergencia que hace unos años. Por ello muchas se están lanzando a ofrecer sus productos vía notificaciones push dentro sus apps (peligro). Para mejorar sus números de visitas se ha puesto, en cierta forma, de moda escribir mensajes push que vienen a ser un “te echamos de menos, vuelve a entrar en la app”.

Ahora mismo es imposible filtrar esas notificaciones y no todo el mundo sabe ignorarlas (por ejemplo en Android o iOS aunque sus sistemas operativos lo permitan). Por favor, no abuses del autobombo con tus usuarios. Las apps son bastante fáciles de desinstalar si no son imprescindibles para el usuario y, peor aun, calificar negativamente en el market de turno.

¿Cuántas aplicaciones tienes actualmente instaladas en tu móvil que constantemente te interrumpen con avisos?

Desde el 2010 no se había celebrado ningún Devfest en Madrid, el último lo organizó Google España. Aunque estos años seguía contando con su apoyo, dependía de los GDGs de cada zona su organización. Con cierta envidia sana contemplamos como el GDG de Barcelona, mucho más fuerte, consiguió durante estos años que su Devfest se llevará acabo. Mientras tanto, en el resto de ciudades no acaba de cuajar la idea de que los GDGs organizarán un evento de este estilo de un día de duración. Ojo, las reuniones mensuales iban saliendo adelante y participando junto a otros GDGs internacionales en los GDG Summit previos a Google IO.

Parece que en 2013 la cosa ha cambiado. Se nota mucho la labor del nuevo Developer Program Manager en Google España, Andrés Leonardo Martínez, que se está pateando evento tras evento y conectando tanto a GDGs como desarrolladores. Además de que cada GDG local está cogiendo más fuerza llevando iniciativas propias e implicando a más gente inquieta.

Este año hemos podido disfrutar de eventos en Barcelona, Bilbao, Córdoba (en representación como Devfest Sur) y, el último en Madrid. Los comentarios han sido bastante positivos y muchos de los ponentes (gente muy buena, por ejemplo, que esta trabajando en Android)

El Devfest de Madrid, el último de la temporada de 2013

Destaco unas cuantas de las charlas que más captaron mi foco de atención, seguro que mucho otros blogger estuvieron presentes y dan profundidad a mi análisis. El evento giró sobre el pilar de Android y el interés por las Google Glass de alguno de los ponentes.

Koush, el crack de CyanogenMod que vino desde Seattle al Devfest Madrid

Como plato fuerte, uno de los rockstar ponentes era Koushik Dutta, co-creador de CyanogenMod vino a hablar del proceso de convertir un gran proyecto Open Source en una compañía cuyo principal producto es una de las ROMs más reconocidas de las comunidad Android. Hizo un recorrido por lo que representa Cyanogen y su hoja de ruta para ser un producto comercial. Comentando futuras novedades: servicios añadidos de backup, integración en la nube, facilidad de instalación (tu madre tiene que poder instalarlo con tan sólo un click) o como podrá verse integrado en el futuro móvil OPPO.

No se podía desperdiciar la presencia de Koush y el esfuerzo de traerlo al Dev Fest de Madrid, así que hizo doblete con una sesión técnica hablando de las interioridades de HTPP en Android. Pocos de los asistentes conocíamos las librería en la que está trabajando para facilitar las comunicaciones HTTP en las aplicaciones Android. Se trata de Ion y, tal como planteó la presentación mostrando las características y problemáticas a las que nos enfrentamos los desarrolladores Android, sin duda es una opción interesante para usar en nuestro próximo proyecto.

Liquid Galaxy

Desde el GDG de Lleida, nos trajeron a Madrid un proyecto que lleva fraguandose entre esa ciudad y la sede central de Google en Mountain View. Andreu Ibañez presentó el proyecto Liquid Galaxy conecta distintas pantallas y ordenadores hasta formar un cluster que permite interaccionar con mapas (Google Maps y Google Earth) de una forma espectacular. Formando un inmersión total.

Google Glass, aún sigue siendo pocos sus poseedores en España

El interés de Google Glass en España está in crescendo. Hay pocos poseedores de las gafas españoles (creo que un censo no oficial lo sitúa en unas 5 personas). Uno de ellos es Antonio Zugaldia que nos hizo una auténtica review del producto en directo comentando algunas de sus características. Entramos en detalle de cómo se programa para ellas: Google Glassware en la que podemos hacer uso de Mirror API o el GDK nativo de Glassware para programar app más complejas.

Un evento que al fin recuperamos la comunidad de desarrolladores. Que ha sido posible gracias a la organización del GDG Madrid.

Fotos | Album del Dev Fest Madrid 2013 en Google+ Otros resúmenes | Devfest Madrid Andreu Ibañez

Esta ha sido la primera I/O a la que he asistido, una experiencia increíble en San Francisco. Tres días no son suficientes para absorber toda la información que la Google I/O 2013 ha generado. Tanto una keynote de tres horas en las que se ha tocado muchos frente abiertos (aunque no con todas las novedades que queríamos) y muchas de sesiones técnicas que en algunos casos simultaneaban entre 6 y 7 charlas.

Ahora toca digerir toda esa información tranquilamente desde el escritorio, gracias a que Google ha publicado ya muchas de las charlas en YouTube. Revisar las sesiones técnicas a las que asistí y las que me perdí por no poder desdoblarme (o triplicarme) en otras salas.

Mis impresiones generales de la Google I/O como desarrollador han sido bastante positivas. Es muy estimulante asistir en persona y cruzarse en las sesiones con los programadores más importantes de Android, y en general de Google. Gente bastante cercana a la que podías abordar sin problema.

Realmente me parecieron desarrolladores bastante humildes (muy importante en esta profesión) dispuestos a invertir tiempo a que todos los asistentes aprendieran como usar de la mejor posible los productos que han desarrollados. Tenía especial interés en conocer en persona a Roman Nurik, Matias Duarte, Reto Meier, Romain Guy, Nick Butcher, Francesco Nerieri, Xavier Ducrochet y mucho más.

El pistoletazo de salida la dio una keynote de 3 horas en las que se reunió una docena de novedades. Otros años se había dividido en dos días distintos, aglutinando temáticas. Este año no ha sido así, si no que se han ido saltando de un tema a otro y con la aparición estelar final de Larry Page (buen símbolo de transparencia, pero que enfrió el ambiente y no dejo ningún anunció sorprendente como las Glass del año pasado con Sergey, esta vez ni apareció.

Android, sin nueva versión pero con IDE propio (Android Studio) e importantes nuevas APIs en Google Play Service

El protagonista al que todos teníamos puesto las miradas era Android, aunque finalmente no hubo anuncio de nueva versión (ni Jelly Bean 4.3 ni mucho menos Android 5.0 Key Lime), tampoco se anunciaron nuevos dispositivos (ni Nexus 5, ni renovación de Nexus 7, Phone X o un Nexus 8). Lo más cercano en cuanto a hardware fue que el Samsung Galaxy S4 se podría adquirir con un Android puro desde Google Play, o lo que mucho vimos como que Android sin Google cada vez mola menos por la ovación del público al eliminar el software de Samsung.

Pero siendo un evento de desarrolladores (que mucho olvidan cada año), hubo novedades en ese sentido sobre Android. Creo que una de las más importantes es que Android al fin dispone de un IDE propio, se trata de Android Studio basado en IntelliJ. Aunque es una primera versión y ni mucho menos se va a dejar de dar soporte a Eclipse si que apunta hacia donde se dirige el desarrollo de la plataforma.

Las mejoras de Android han venido de cara a los servicios que ofrece Google para desarrollar apps, queda clara la estrategia de Google mejorando Google Play Services demostrando que Android sin los servicios de Google no mola tanto. Muchas ganas de probar Location APIs y sus Geofencing APIs.

Así, las nuevas APIs presentadas como Google Play Game, Location APIs, Google Cloud Messaging o la plataforma de sign-on de Google+ demuestran ventajas respecto a nuevas funcionalidades que explotar en el desarrollo de nuevas aplicaciones y, por supuesto, juegos que cada están presentes en el negocio.

También nos encontramos con muchas cosas de cara a la distribución de aplicaciones: servicios integrados de traducción, mejora en los gráficos y estadísticas de rendimiento, posibilidad de distribuir versiones alpha y beta, más tips de optimización, Google Analytics integrado en la consola de desarrolladores o los referal trackings.

Chrome de navegador a plataforma para usar la web

Chrome es otro de los productos destacados de Google. Ya no sólo como navegador, el cual ha logrado ser el navegador más usado, si no que quiere ir más allá como sistema operativo con Chrome OS. Google es web y la nube donde almacenamos todos nuestros datos por eso tiene sentido dispositivos como el Chromebook Pixel con Chrome OS que regalaron a todos los asistentes, i5, 4GB y pantalla multitáctil de 12.85 pulgadas 2560 x 1700. Más de 6.000 desarrolladores trasteando con un dispositivo bastante potente que gira entorno a las apps webs y Chrome aunque con un núcleo Linux, donde mucho ya hemos instalado Ubuntu y poder correr, por ejemplo, Android Studio en una increíble maquina.

Glass, el invento más arriesgado al que le queda madurar

Era impresionante la cantidad de desarrolladores con Glass, entre los Googler y los pioneros paseando por la Google I/O. Muy complicado poder probarlas a fondo y había una distinción muy fuerte entre las gafas de algunos pioneros y los desarrolladores de Google (que estaban prohibidos a dejar probar, ni siquiera a sus propios compañeros de trabajo).

Pude probarlas brevemente y deje un post de primeras impresiones en Xataka Android, creo que de las primeras en castellano. Sinceramente, creo que es un producto muy bueno pero que con unos pocos minutos es imposible que te impresione, no me lo apareció e incluso me pareció muy incomodo consultar información hacer falta acostumbrarse a esta nueva extensión.

Google+ y Google Search, Google Now

Google es social, el camino emprendido con el lanzamiento de Google+ lo ha dejado claro más claro este año. Sinceramente cada vez lo uso más y estos cambios son a mejor, personalmente mi uso es esta enfocado a temas de desarrollo siguiendo a programadores interesantes y comunidades de desarrollo, pero como plataforma social no tiene nada que envidiar a Facebook.

Google cada vez nos conoce más, así nos ofrece búsquedas más potentes con Google Now. La forma de buscar información a través de Google ha cambiado y va cambiar aún más con la incorporación de la búsqueda por voz (real).

Entre otros servicios que me impresionaron fue el cambio del nuevo Google Maps. Interfaz totalmente renovada con integración de muchos servicios como Google+ en la recomendación de sitios o la mejora de la descripción de la info de transporte público, aunque claro las demos en este sentido sobre la ciudad de San Francisco son otra cosa, ya que allí es increíble como funciona.

Google Hangout es un buen servicio, y creo que empece a usarlo en los primeros minutos que estuvo disponible con mis contactos presentes en San Francisco, pero cada vez que lo uso echo más de menos a Google Talk. Creo que la transición a un servicio más parecido a mensajes al estilo Whatsapp perdiendo las cosas positivas del formato chat.

Otros servicios como Google Music, me dejaron frío, realmente sigo usando Spotify y creo que necesitaré mucho para que me acabe de encajar como alternativa.

En definitiva, una gran oportunidad de conocer aun más como trabaja Google y descubrir una ciudad increíble como San Francisco donde se respira innovación tecnologica y mucho movimiento de gente con talento. Ocasión aprovechada también para charlas con emprendedores y desarrolladores españoles allí.

Sacando estadísticas del año, creo que este 2012 ha sido el que más kilómetros he hecho como runner: 458 kilómetros y romper la barrera de los 74km en el mes de Diciembre, tuve un lapsus de ritmo en los meses de verano (el único punto negativo). Al menos, desde que subo cada carrera a Nike Plus Running. Buenas sensaciones para acabar el año logrando hacer de esto de correr un hábito. Salir 2 veces entre semana al Retiro con mis compañeros de ofi y una vez en el fin de semana por el Ensanche de Vallecas a hacer kilómetros.

No he corrido ninguna carrera popular, salvo la tradicional San Silvestre Vallecana que ha notado esta mejoría con un tiempo de los mejores épocas (47’52»). Queda apuntado correr más carreras populares durante este 2013. Tener un objetivo a corto plazo siempre es bueno.

Este ha sido el año, que aunque al principio podía parecer un capricho tecnológico más de los míos, me compré el reloj de Nike+ Sportwatch GPS. Estoy convencido que ha sido una de las mejores inversiones que he hecho para manejar tiempos, kilómetros hechos, ritmo y sumándole el extra de tener el recorrido de cada traza nueva que hago. Lo recomiendo aunque, sólo por el panel de Nike+ y su ecosistema como reloj de runner pro hay otras opciones mejores. Ya sabéis Nike+ hizo a los geek levantar el culo y ser deportistas sólo por llevar esos gadgets para presumir en twitter.

Retos runner:

• Correr alguna carrera popular más
• Mejorar ritmo. Mi último fue a 4′ 44» por km en la pasada San Silvestre Vallecana. Se puede mejorar mucho
  Hacer más kilómetros.
• Llegar a superar la barrera de los 800 km en un año (algo menos del doble que ahora sería el objetivo en mente)

Más:
* Carrera de la San Silvestre Vallecana 2012
* Mi perfil Nike+ Durbon

Hace unos días se pusieron en contacto conmigo la gente que lleva todo el apartado de UOC Alumni (la comunidad de graduados de la UOC) para hacerme una entrevista. De forma periódica seleccionan a un estudiante de la UOC para que cuente su experiencia en la universidad, su trabajo actual y sus expectativas profesionales y personales, lo llaman Alumni Destacado.

Creo que en una de las partes de la entrevista comenté la frase que pusieron de titular. La verdad es que leyéndola así de grande me sigue pareciendo bastante acertada cuando se habla de innovación:

Innovar es, sobre todo arriesgar, hacer cosas nuevas sin miedo.

En la entrevista me preguntan sobre mi paso por la UOC (estoy estudiando el Máster Universitario de Ingeniería Informática y anteriormente cursé el Máster de Software Libre), mi día a día como desarrollador de I+D en idealista.com, los proyectos en los que he participado, mis proyectos personales en especial mi participación en Weblogs SL como coordinador de Genbeta Dev, además de qué es para mi la innovación o mis referentes tecnológicos.

Puedes leer la entrevista completa en el portal UOC Alumni.

Y si quieres también en catalán.

Foto de mis gadgets imprescindibles:

Soy ferviente usuario de Android y programador: mi móvil habitual es un HTC Desire y mi tablet una Asus EEE Trasformer con HoneyComb. Pero no siendo un talibán de Android uso habitualmente mi iPod Touch para escuchar música a través de la aplicación de Spotify y asi trastear con iOS 5.

Para leer libros electrónicos comencé con el Kindle de 6 pulgadas, pero como cada vez era más habitual que consultará libros en pdf, sobre todo de programación, que no se veía bien acabe pillandome un Kindle DX.

Como ordenador principal uso un MacBook Pro, este en concreto es un i5 con 8 GB de RAM. En los viajes a veces uso el ASUS de 10 pulgadas, aunque cada vez la tablet sustituye la función habitual de consultar internet.Sobre todo es imprescindible el modem MiFI para crear una red WiFi para los distintos dispositivos a partir de la red 3G (uso un tarjeta de datos de Simyo).

Como cámara compacta uso una Canon Powershot SX230 cuya mayor cualidad es su zoom de 14x y el GPS incorporado para geoposicionar las fotos. También tengo una tarjeta Eye-Fi con WiFi integrado que me permite subir fotos directamente desde la cámara.

Internet es parte de nuestras vidas y la ventana que nos abre al mundo. Otra pantalla más que deben cuidar donde esta la gente que ve su películas. Y es que sin espectadores no tiene sentido hacer cine. Hay que cambiar el modelo de mercado, innovar con nuevas formas de como llegar al mundo. El actual no funciona. Está comprobado y no podemos impedir el crecimiento de internet. No es un futuro, es la realidad. Internet es la salvación de nuestro cine.

No hay nada mejor que sentirse LIBRE creando, y compartir esa alegría con los demás.

Bravo, @alexdelaiglesia.

Texto integro del discurso de Alex de la Iglesía en los Goya 2011 en escolar.net

Los ciudadanos y las empresas usuarias de Internet adheridas a este texto manifestamos:

1. Que Internet es una Red Neutral por diseño, desde su creación hasta su actual implementación, en la que la información fluye de manera libre, sin discriminación alguna en función de origen, destino, protocolo o contenido.
2. Que las empresas, emprendedores y usuarios de Internet han podido crear servicios y productos en esa Red Neutral sin necesidad de autorizaciones ni acuerdos previos, dando lugar a una barrera de entrada prácticamente inexistente que ha permitido la explosión creativa, de innovación y de servicios que define el estado de la red actual.
3. Que todos los usuarios, emprendedores y empresas de Internet han podido definir y ofrecer sus servicios en condiciones de igualdad llevando el concepto de la libre competencia hasta extremos nunca antes conocidos.
4. Que Internet es el vehículo de libre expresión, libre información y desarrollo social más importante con el que cuentan ciudadanos y empresas. Su naturaleza no debe ser puesta en riesgo bajo ningún concepto.
5. Que para posibilitar esa Red Neutral las operadoras deben transportar paquetes de datos de manera neutral sin erigirse en “aduaneros” del tráfico y sin favorecer o perjudicar a unos contenidos por encima de otros.
6. Que la gestión del tráfico en situaciones puntuales y excepcionales de saturación de las redes debe acometerse de forma transparente, de acuerdo a criterios homogéneos de interés público y no discriminatorios ni comerciales.
7. Que dicha restricción excepcional del tráfico por parte de las operadoras no puede convertirse en una alternativa sostenida a la inversión en redes.
8. Que dicha Red Neutral se ve amenazada por operadoras interesadas en llegar a acuerdos comerciales por los que se privilegie o degrade el contenido según su relación comercial con la operadora.
9. Que algunos operadores del mercado quieren “redefinir” la Red Neutral para manejarla de acuerdo con sus intereses, y esa pretensión debe ser evitada; la definición de las reglas fundamentales del funcionamiento de Internet debe basarse en el interés de quienes la usan, no de quienes la proveen.
10. Que la respuesta ante esta amenaza para la red no puede ser la inacción: no hacer nada equivale a permitir que intereses privados puedan de facto llevar a cabo prácticas que afectan a las libertades fundamentales de los ciudadanos y la capacidad de las empresas para competir en igualdad de condiciones.
11. Que es preciso y urgente instar al Gobierno a proteger de manera clara e inequívoca la Red Neutral, con el fin de proteger el valor de Internet de cara al desarrollo de una economía más productiva, moderna, eficiente y libre de injerencias e intromisiones indebidas. Para ello es preciso que cualquier moción que se apruebe vincule de manera indisoluble la definición de Red Neutral en el contenido de la futura ley que se promueve, y no condicione su aplicación a cuestiones que poco tienen que ver con ésta.

La Red Neutral es un concepto claro y definido en el ámbito académico, donde no suscita debate: los ciudadanos y las empresas tienen derecho a que el tráfico de datos recibido o generado no sea manipulado, tergiversado, impedido, desviado, priorizado o retrasado en función del tipo de contenido, del protocolo o aplicación utilizado, del origen o destino de la comunicación ni de cualquier otra consideración ajena a la de su propia voluntad. Ese tráfico se tratará como una comunicación privada y exclusivamente bajo mandato judicial podrá ser espiado, trazado, archivado o analizado en su contenido, como correspondencia privada que es en realidad.

Europa, y España en particular, se encuentran en medio de una crisis económica tan importante que obligará al cambio radical de su modelo productivo, y a un mejor aprovechamiento de la creatividad de sus ciudadanos.

La Red Neutral es crucial a la hora de preservar un ecosistema que favorezca la competencia e innovación para la creación de los innumerables productos y servicios que quedan por inventar y descubrir. La capacidad de trabajar en red, de manera colaborativa, y en mercados conectados, afectará a todos los sectores y todas las empresas de nuestro país, lo que convierte a Internet en un factor clave actual y futuro en nuestro desarrollo económico y social, determinando en gran medida el nivel de competitividad del país. De ahí nuestra profunda preocupación por la preservación de la Red Neutral. Por eso instamos con urgencia al Gobierno español a ser proactivo en el contexto europeo y a legislar de manera clara e inequívoca en ese sentido.

Si te sientes representado por este manifiesto te pedimos encarecidamente que lo copies y lo publiques en tu blog o que lo menciones en tu cuenta de Twitter o en Facebook usando el hashtag #redneutral. ¡Muchas gracias!

Tenía parado el blog desde hace unos meses. Entre una cosa y otra no he tenido tiempo de actualizar mi blog personal. Y eso que es aquí donde debería escribir más sobre las ideas que me pasan por la cabeza.

Una de las cosas que me ha pasado estos meses ha sido el viaje a Nueva Zelanda. En julio ya avancé el vídeo que @flequilu mandó para el concurso de Atrapalo Largate. En Septiembre lo eligieron como ganador por su originalidad y su buena puesta en escena. Yo sólo era un foto de carnet, si no lo hubiera estropeado. 100% trabajo de Lourdes. Al fin consiguió que me «largarán» a las antípodas. Gracias.

Entre el 27 de Octubre y el 8 de Noviembre estuve por tierras Neozelandesas, contando los casi 4 días entre el viaje de ida y vuelta que estuve en el aire volando entre diferentes aviones. Una experiencia única que no se puede resumir en las 400 fotos que he subido a Flickr, hay muchas más en mi retina guardadas. Además de toda la gente que conocí. A pesar de ir solo me sentí super acompañado. Tuve la oportunidad de conocer gente de diferentes países, incluyendo a unos cuantos españoles que iban por una cuantos meses a vivir en Nueva Zelanda y buscarse la vida, una auténtica aventura.

Nueva Zelanda son las antipodas de España, el país más alejado, 12 horas de diferencia horaria y 20.000 kilometros de distancia. Mi ruta de avión fue desde Madrid-Londres, Londres-Los Angeles y Los Angeles-Auckland en unas 30 horas. La vuelta un poco más añadiendo el regreso desde Christchurch a Auckland para seguir la misma ruta de regreso.

Estuve alojado en Auckland, Rotorua, Queenstown, Wanaka y Christchurh. En el autobús del tour nos desplazamos de una isla a otra en avión. Monté en barco en los glaciales de Milford Sound, donde llegamos a salir al Mar de Tasmania. Incluso me monté en una las lanchas rápidas que recorrían el río Shotover a gran velocidad entre las rocas.

He hecho un resumen de todas las fotos en Flickr de los sitios que visité. Además estuve haciendo un mini diario de lo que veía para no olvidar nada. Prometí que publicaría un post en el blog de atrapalo a mi vuelta.

Mis fotos en flickr. Mi Viaje a Nueva Zelanda.

Antes simplemente existían la marcas X ó Y. Pero ahora nos encontramos con un aluvión de marcas diferentes para un mismo producto. La culpa la tiene el dichoso longtail.

Si hace unos años la televisión era la forma más eficaz para transmitir a los consumidores lo que debían comprar (él que ponía más anuncios ganaba), pero ahora las empresas se tienen que esforzar en fidelizar a las usuarios: los mensajes sean reenviados, votados, comentados, valorados y hasta construidos por los usuarios.

Las marcas que usaron los community manager de forma pionera experimentaron una mejora de la percepción de la marca por parte de los nuevos consumidores 2.0 (early adopter, prescriptores de marca, evangelizadores). Todo eso era una ventaja competitiva, pero ahora nos enfrentamos a que todas las empresas quieren tener un community manager y muchos jóvenes 2.0 quieren ser esos conductores del branding de la empresa.

Ya no es una ventaja competiva usar un community manager, si no lo usas te quedas átras parece. Cada vez es más difícil gestionar la reputación de una empresa y los community manager (o los que dicen serlo) que se encuentran a patadas no son tan buenos como los consumidores experimentados que controlan las redes sociales y los canales de comunicación para llegar a más gente.

Interesante esta reflexión de Enrique Dans en Expansión sobre los Community Manager.

Ya hemos consumido la mitad del año 2010 y Marta Kagan, nos regala una nueva presentación de lo que es la saga ‘What the F**k is Social Media’ y ‘What the F**k is Social Media‘.

Además de los packs Lárgate que puedes adquirir con diferentes destinos (tanto cerca como lejos) han propuesto un concurso en el que cuentes tus razones en un vídeo. Ellos lo estudiarán y mandarán a esa persona de vacaciones con todos los gastos pagados.

También hay una aplicación de Facebook de Lárgate de Atrápalo puedes presionarle socialmente para que se largue. Sólo por usarla regalarán 2 Packs Lárgate: uno para largar a esa persona y otro para que quien le haya enviado pueda disfrutar de su ausencia

@flequilu me quiere mandar a las Antipodas. Sí, el del vídeo soy yo. Viva el stop motion. Aquí están sus razones:

Vía | blog Atápalo

Eskup (de scoop, en inglés primicia) es la reciente plataforma de micropublicación de El Pais lanzada a mediados de Junio. Está basada en Utoi que el antiguo equipo de Soitu desarrolló antes de ser cerrado en octubre de 2009. Gumersindo Lafuente con buena parte del equipo que creó este experimento, ahora en El País, lo ha recuperado inteligentemente y le ha dado un soplo de aire fresco a elpais.com.

En esta red se mezclan en cierta manera de forma horizontal los periodistas del El Pais y los lectores/usuarios de Eskup. Aunque los primeros tienen ciertos privilegios, ya que ellos son los que editan algunos temas restrigidos retuiteando (fwd) las publicaciones que consideren más interesantes de los lectores. Se genera de esta forma un enriquecedor feedback entre periodista y lector. Un paso muy acertado para el periodismo moderno.

Para publicar tienes 280 caracteres más la posibilidad de incluir una imagen que ilustra el post. Además se pueden incluir enlaces, usando el acortador, también herencia de Soitu, Cort.as. Se han incorporado botones sociales para publicar también en facebook y twitter. Los usuarios pueden comentar las publicaciones de otros usuarios y hacerles un fwd (el retuiteo de siempre).

Las publicaciones se organizan en temas. Por ejemplo, la cobertura del mundial de Surafrica, la huelga de metro o temas especificos como zona de Madrid o Barcelona. El usuario puede hacer seguimiento a determinados usuarios o temas. No todos pueden escribir en los temas sino que son los editores de cada uno (los periodistas) los que conceden el privilegio a algunos usuarios o simplemente retuitean lo más interesante de los lectores. De esta forma se forma 2 grupos de usuarios: primera clase (los editores) y segunda clase los lectores. Un tema delicado por un lado si se quiere que los lectores se enganchen a escribir, pero necesario si se quiere evitar el ruido de las publicaciones irrelevantes.

La implementación técnica es muy correcta. Ofreciendo una interfaz muy 2.0 rápida para consultar cada publicación. Desde el primer momento nos ofrecen una versión móvil (si pensamos el movimiento de las conversaciones es lógico poder leer/publicar en cualquier lugar), una API donde podemos enganchar nuestras aplicaciones interesante para extender este servicio y widgets para aprovechar nuestras publicaciones para incluirlas en nuestro blog. Promete ir incorporando nuevas funcionalidad según vaya avanzando.

Mi perfil en Eskup | @durbon
Más información | Qué es eskup
hablan de eskup | Eskup y la huelga de metro (Jorge Galindo)
Eskup, el modelo twitter dentro de un medio de comunicación (error500)

Le veo el punto a foursquare por rachas. Aunque siempre pienso que tiene un potencial enorme si las empresas lo saben aprovechar bien. Muchas campañas de street marketing que lográn congregan a sus acólitos participantes en un lugar concreto se podría beneficiar de su uso, aunque fuera para contabilizar frente a los que ponen la pasta el número de seguidores que han tenido en el evento. El ruido que pueden hacer en las distintas redes sociales es enorme.

Una cosa que ha hecho bien Foursquare es ser abierto. Tanto en plataformas (iPhone, Android, Blackberry, web móvil) como en las redes sociales donde lanza sus actualizaciones (twitter o facebook). A mucha gente le suena 4sq por los mensajes que aparecen en su timeline como este «I’m at C.C. Hipercord Méndez Álvaro (Calle de la Retama, 8, Madrid). http://4sq.com/9cal6M«.

Lo que se mueve en EE.UU se sitúa en dos tipos de anunciantes (empresas que van a utilizar foursquare para sus labores publicitarias/repercusión 2.0).

La primera es la más obvia: aquellos locales que visitan los usuarios de foursquare que pueden premiar a los major y a los que hagan un check-in en un determinado momento. Pueden seguir al instante quién está en su local y está hablando de él. Además los mensajes push al realizar un checkin cercano sirve de atracción por medio de ofertas o premios. Y parece que de momento es barato atraer a usuarios influenciadores en las redes sociales, aun están a la altura de los primeros blogueros allá por el 2005.

La segunda es la de marcas que proponen lugares que visitar o incluso pueden incentivar acudir a distintos lugares para conseguir algo. Convirtiendo a los usuarios en exploradores que cumplen con los distintos tips que no dejan de ser minicampañas de su propia marca-productos o de sus establecimientos asociados.

Interesante seguir el blog de foursquare para ver como se van moviendo las cosas en EE.UU. Mucho más avanzados que en España.

Mi perfil de Fousquare es durbon

Google IO es el evento de desarrollo más importante de Google y para el resto de desarrolladores que usamos sus servicios: un ristra de APIs, servicios y aplicaciones, sin olvidarnos de Android (el SO de nuestros móviles).

Al igual que Apple con su WWDC, Google se reservará un sorpresa como «One more Thing». En este caso se barajan varias que pueden causar una revolución: la televisión de Google, la tableta que pueda competir con el iPad con Android o algun netbook con Chrome OS.

Las principales apuestas son:

– Google liberara más APIs de sus servicios. Las que tienen más intereses son las de Google Buzz y las nuevas funcionalidades de la API de Google Latitude para competir con las nuevas redes de geolocalización como Foursquare y Gowalla.

– Los fans de Android estamos impaciente de la nueva actualización a Android 2.2 Froyo. Se espera con Adobe Air que aumentaría las posibilidades de muchas aplicaciones, o el tan querido Flash de Adobe.

– La liberación de VP8, el codec de vídeo que puede dar un impulso definitivo a HTML5 en el tema de los vídeos. Mejor compresión que h264 y no estar controlado por ninguna empresa.

– Chrome OS puede ser el producto revolucionario que más posibilidades tiene de ser presentado. Y sería un buen golpe de efecto ahora que los netbooks están de capa caída con la salida del iPad.

El resto se sabrá ya el miércoles 19 o el jueves 20. Entre la decena de sesiones que hay de todos los servicios: Android, Geo, GWT, App Engine, Buzz, Wave, Chrome…

Recomendable no perdersela, que por cierto darán en streaming en su canal de YouTube. Para mí Facebook f8, Google IO y la Apple WWDC son las tres grandes conferencias que guían el futuro de internet y la evolución de la tecnología.

Y el anterior vídeo de agosto del 2009 para comprobar la evolucción de todo esto.

Fue una experiencia enriquecedora en la que se habló abiertamente de muchos conceptos importantes de innovación del mundo de internet. Se nota que todos los asistente en menor y mayor medida se dedican algo relacionado con internet y de un forma creativa buscan innovar en internet.

Dolores Reig, editora del blog El Caparazón indicó unas importantes premisas a tener en cuenta cuando queremos innovar en internet:

1. Keep it simple: la caja de búsqueda de Google, el timeline de Twitter…
2. Keep it free: la comunidad es la que decide, nosotros no somos propietarios, les debemos dejar que ellos mismos decidan
3. Keep it open: no hay nada más libre que internet, los bits fluyen
4. Keep it diverse: hay que dar diferentes opciones, en la diversidad está el éxito
5. Keep it funny: aplicar la Fun Theory para mantener al público en vilo. La gente está más pendiente de lo que hacemos si se sienten entretenido y lo hacemos divertido
6. Keep it clever: a veces aprendemos más de nuestros público que lo que podemos ofrecer nosotros. Eso esta bien, es la filosofía abierta de internet quién lo permite. La wikipedia se creó con apenas del 1% de las horas que los americanos pasan viendo TV cada año.

Internet es una gran meritocracia en la que la gente es valorada por lo que hace no por lo que son. Sólo funciona lo que merece la pena, es muy fácil desaparecer si no eres útil, nadie tiene el poder de permanencia. Algo que funciona ahora puede dejar de existir en dos años. Hace unos pocos años no existían Facebook o Twitter. Para que triunfe un servicio que sustituya a otro es importante valorar el coste del cambio de un servicio a otro.

En la presentación de José Antonio Gallego sobre Crowdsourcing. Las multitudes al servicio de nuestra empresa, gracias al 2.0. Utilizando inteligentemente el trabajo colaborativo podemos conseguir que nuestros usuarios nos ayuden a construir algo más potente de lo que nosotros no seríamos capaces de crear. Hay ejemplos importantes como: la traducción de Facebook, la red Innocentive, Kiva, ebay, Threadless…

También estuvo bien la charla sobre Comunidades Virtuales, donde se mostró por donde va internet y la filosofía que tiene implícita. Hacía donde nos dirigimos y como nos comportamos en las comunidades con nuestra identidad en internet.

Impresionante el uso de Twitter de los asistentes. Teníamos una gran pantalla para mostrar los tweet y no paraban de aparecer mensajes interesante que aportaban ideas interesantes a la conversación. Podéis seguir la conversación con el hashtags #innosfera.

La filosofía de Google en esto de los social es clara, ser el paradigma de las redes social en un entorno abierto que se adhiera a estándares abiertos. La prueba es que Buzz ya dispone de api a pesar de no saber si tendrá exito.

Google parece estar formado por un ejercito de ingenieros que juega duro. Son capaces de generar cada poco una nueva herramienta poniendo todas sus energías en ofrecer sus apis abiertas al servicio de internet integradas a todos los servicios de Google. Se nos acumulan las clases para saber usar Wave y Buzz. Quizá este Buzz sea la apuesta más acertada en contraposición de Wave, algo que no acabamos de comprender aún y probablemente, salvo nuevo cambio de planes, no comprenderemos en un corto tiempo. Buzz es lo que debería haber sido Wave.

Buzz ya esta disponible en el iPhone o Android gracias a la interfaz de aplicación móvil web HTML5 creada. Permite ver el timeline de nuestros contactos y de los más cercanos (en listado y sobre mapa). Una interfaz muy cuidada demostrando que Google se aleja de la aplicaciones nativas y apuestas por webs adaptadas para los nuevos dispositivos móviles sacándole todo el partido a HTML5.

Freaklances es una pequeña serie de animación online que con tan solo dos capítulos, de momento, pinta muy bien.

En episodios de corta duración vemos las aventuras de Fausto, un freelance y sus posibles trabajos, además de los freaklances que se cruza por su camino. Ya sean diseñadores gráficos, realizadores de vídeo, consultores de marketing, ilustradores, fotógrafos…

Os dejo el segundo capítulo y espero con ansiedad el tercero. El primero fue buenisimo.

Vía | Obviedades

Evita al máximo todas esas bolsas, servilletas, vasos de plástico y, en general, todo lo que estuviera envasado. Logra reducir los kilos de basura de los cuales se arrepiente de generar a diario junto a su mujer y su pequeña hija. Evita los transportes que emitieran co2 a la atmósfera. Nada de ascensores, coches, taxis, metros, autobuses y por supuesto aviones. Además logra obtener una austeridad en la forma de comprar, nada es comprado para usar y tirar. Apuesta por las cosas de segunda mano, nada nuevo, excepto la ropa interior. La alimentación sostenible se basa en no consumir producto que utilicen productos químicos y, además, se compromete en consumir alimentos de temporada de su área local, evitando ser transportados y que crezcan de forma artificial. El consumo eléctrico se frena en su hogar. Nada de electricidad. Colin se hace con un pequeño panel solar con el que producir la energía necesaria para alimentar su portátil y algún electrodoméstico.

Por supuesto, nada de televisión que incita nuestras ansias de consumismo. Consumir nos hace tan felices que en nuestro lecho de muerte nos arrepentiremos por no haber comprado más. Gilipolleces. Eso no da la felicidad, en cambio sí los pequeños placeres de la vida que no se anuncia por la tele.

Me ha encantado su filosofía zen de vida, el cambio que todos podemos producir aunque seamos una sola persona y su ecologismo que va más allá de utilizar bombillas de bajo consumo o reciclar: hay que ser realmente consciente de los recursos que gastamos y desperdiciamos del planeta. Hay que concienciarse del uso que hacemos de los recursos del planeta y la vida que llevamos. Somos más felices, por ejemplo, trabajando con la luz del día y aprovechando las noches para disfrutar de la familia olvidándonos del televisor. El libro te hace plantearse si es necesario todo lo que utilizamos en esta sociedad moderna.

Además del libro Colin Beavan protagoniza su propio documental. Lo mismo que narra en el libro visto por las cámaras que se cuelan en su apartamento de Nueva York.

Más información | No Impact Man

Éste es un antiguo Koan Zen que puede ilustrar muchas disputas que tenemos a diario y que vemos en nuestra sociedad, sobre todo en los políticos.

Hace mucho tiempo en China un gato callejero fue vagabundeando hasta llegar al monasterio del maestro zen, Nam Cheon. Unas veces el gato se acurrucaba en el regazo de los monjes que vivían en la residencia del Este, y otras veces se acurrucaba en el regazo de los que vivían en la residencia del Oeste. En vez de ocuparse de cuidar al gato conjuntamente, los monjes del Este y del Oeste se pusieron celosos los unos con los otros.

– Nosotros amamos al gato más que vosotros, así que debería vivir solo con nosotros – decían los del Este.
– Ni hablar, nosotros sabemos cuidarlo mejor; ¡se debería quedar solo con nosotros! – replicaban los del Oeste.

Un día estalló la discusión el salón del dharma, donde los monjes debían estar meditando. Finalmente, el maestro Nam Cheon irrumpió en la sala, agarró al gato y le puso un cuchillo en el pescuezo.

– Monjes -dijo el maestro-, dame un sola palabra de amor verdadero por este gato y lo salvaré; si no lográis hacerlo, lo mataré.

Nam Cheon estaba poniendo a los monjes a prueba. ¿Amaban al gato de verdad o lo único que querían era ganar la disputa? ¿Se harían responsables de su vida o estaban demasiado ocupados con la pelea? Según cuenta la historia, ninguno de los monjes supo hacer o decir nada: lo único que les preocupaba era demostrar que los del otro bando no tenían razón, de modo que Nam Cheon degolló al gato.

Podéis leer más Koans de este estilo en la web Zen Koans Database.

Hace unas semanas me compré un Kindle, el dispositivo de lectura(ebook) desarrollado por Amazon. Lo quieren llamar el ipod de los libros. Están en lo cierto: creo que el Kindle será la punta de lanza que acelere la penetración de los ebooks en al vida cotidiana.

Estoy contento con la compra y le veo muchas posibilidades futuras. Mejoras que llegarán por medio de actualizaciones del firmware (ya permitieron ver pdf). Sus posibilidades son inmensas: disponiendo de conexión 3G integrada, 2 GB de disco duro, teclado QWERTY completo y su alucinante tinta electrónica E-INK que se asemeja bastante a la tinta imprensa de un libro.

Su precio es más barato que los ebooks que hay en el mercado en España (sorprendente). Para comprarlo Amazon te muestra su precio detallado, incluido aduanas y gastos de envío a tu país. Además se han propuesto que cualquier Kindle llegue en menos de una semana a cualquier parte del mundo (lo certifico, al menos para España).

La pantalla: (16 tonos de grises) y 800×600 píxeles. Se asemeja bastante a la tinta impresa en un libro. Incluso, debo confesar que nada más abrí la caja, pensé que tenía pegada una pegatina cuando decía que lo enchufará al usb (realmente era la propia pantalla). No gasta batería en reposo, así es posible mostrar de forma aleatoria portadas de libros cada vez que lo «apagamos». Tiene una autonomía de unos 12 días sin tener que volver a cargar. Lo único malo que veo es que 6 pulgadas se quedan cortas para visualizar pdfs (todos al final queremos el Kindle DX, pero su precio es prohibitivo y no se vende fuera de EE.UU.

Conectividad: 3G total y sin pagar un duro al mes. Eso sí, de momento el navegador que dispone sólo nos deja consultar la wikipedia (en inglés) y la tienda amazon del kindle (kindle store) para comprar/descargar libros donde hay más de 300.000 libros a golpe de click. Se supone que se subvenciona el 3G al comprar libros. A Amazon le interesa que podamos comprar libros en cualquier momento así que ellos ponen la conectividad. No sé cuanto les puede costar proveer ese servicio pero para nosotros es gratis siempre que lo utilices desde el país donde se registre el Kindle.

Capacidad: 2 gb es más que suficiente para almacenar entorno a 1.500 libros. ¿Así que para que más? De todas formas sería interesante aprovechar la conectividad 3G para almacenar documentos en la nube. Amazon es la de EC2 y S3, señores.

Su diseño es liviano, más delgado que un lapiz y una superficie plana como una hoja plegada con una pantalla que como decía podía ser más grande. Teclas bastante cómodas a pesar de su tamaño y botones de avance en ambos lados de la tableta. Se nota una mejora considerable respecto al Kindle de primera generación.

Se pueden cargar los libros por usb o enviarlos a una dirección de correo electrónico que los sincronizará automáticamente con nuestro dispositivo. También podemos suscribirnos a periódicos y revistas digitales que se enviarán a nuestro dispositivo automáticamente como por ejemplo El País o El Mundo, aunque su precio no es barato, no han sabido venderlo bien y es una pena.

Admite pdf nativamente, la mayoría de soporte de ebooks y el formato de kindle book desarrollado por Amazon. Para sacarle todo el partido es recomendable utilizar el software de código abierto Calibre que nos ayuda a gestionar nuestra biblioteca digital, así como convertir a formatos mas amigables para el dispositivo. Este es el caso de algunos pdfs que no estén maquetados para un pantalla de 6 pulgadas por lo que podemos convertirlos a ebook con lo que el Kindle nos permitirá por ejemplo aumentar el tamaño de letra e incluso text-to-speech que tiene incorporado (para inglés).

Ideas que podrían ser interesantes:
– tomar notas y sincronizarlas con google docs.
– consultar y enviar emails
– almacenamiento en la nube (EC2, S3..)

Y en fase de experimentación en el modo (experimental) tienen el navegador web y la reproducción de mp3.

La idea romántica del libro se mantendrá perenne siempre. Pero la tecnología nos hace cada vez ser más prácticos: llevar miles de libros (desde ahora ebooks) en un dispositivo tan delgado como un lápiz, disponer de prácticamente cualquier libro en menos de 2 minutos, poder leer cómodamente esos pdf que siempre tenemos en el ordenador pero que al final no leemos debido a lo incomodo de la pantalla del pc.

Un par de libros que me he propuesto terminar de leerme integramente en el kindle:

– ebook claves del nuevo marketing
– Designing Social interface O’Really
– Getting Things Done

Más información, otras reviews que me han parecido interesantes: Eduardo Arcos, Enrique Dans, Berto Pena o Juan Andrés Milleiro.

Askaro es un sitio web donde realizar preguntas y recibir respuestas sobre una zona concreta. Bien sea nuestro barrio, o un lugar que queremos visitar o quizá una zona donde buscamos casa (una opción muy válida). Formulamos la pregunta y definimos el área sobre el mapa que nos interesa. Luego funciona muy parecido a Yahoo Answers, la gente responde a la pregunta y son valoradas según su utilidad.

Hace unos meses, no sé muy bien como me enteré de la web, puse una pregunta sobre mi relativamente nuevo barrio. Preguntaba dónde había un kiosko de prensa, definí una zona por donde no había visto ninguno. El otro día, después de que realizarán el anunció oficial del lanzamiento, recibí una respuesta de un vecino de mi barrio. El servicio de Askaro me avisó por mail y me dieron la posibilidad de puntuar la contestación. Ya casi se me había olvidado, pero esta forma es útil para mantener un seguimiento, ahí seguía la página con un mapa muy útil para que nos respondan donde nos recomiendan el lugar exacto de lo que buscamos, viendo multiples opciones si las hay.

Los responsables de este proyecto son Ubaldo Huerta (creó Loquo, vendido a Ebay) y Eduardo Manchón (creó Panoramio, vendido a Google). Osea que parece que saben lo que hacen cuando crean un proyecto novedoso, los dos lo fueron en su día y Askaro lo es ahora mismo: un servicio hiperlocal sobre preguntas. En post del blog de Askaro explican que están usando Google App Engine, así que baratito les ha salido el despliegue del proyecto, aunque aun deben tener reservas de como va a funcionar en la nube.

De momento reconocen que está muy verdecito, pero prefieren salir así y recibir sugerencias. A mi me parece un servicio excelente, solo falta que se genera una comunidad interesante alrededor suyo entre preguntas, respuestas y pinchos sobre el mapa.

Buscamos tener planes interesantes y para eso necesitamos herramientas simples que nos den los planes hechos. No buscamos un catalogo de opciones enormes si no que al final demandamos un decisión de ocio: una guía simple e instantanea con unos cuantos planes cercanos y accesibles. Al final la Guía del Ocio o el On Madrid de El País nos saturan.

Vía el blog del 11870 me entero de esta web, anti:bleh, sencilla que nos localiza a través del navegador (con la api de geolocalización de firefox funciona genial) y nos ofrece una selección pequeña, pero variada, de planes. Adaptadas más o menos a nuestra hora y nos indica la distancia a la que están. Ya está, nada más. Efectivo.

Además de la api de 11870 han usado la de ChefMoz, Google, Kedin, Last.fm, Meetup, Ticketmaster.es, Upcoming, Yahoo! y Zvents. Por supuesto, los usuarios pueden enviar los suyos propios. Y lo mejor que anti:bleh ya tiene dispone de aplicación para el iphone.

Y a cuento de todo esto, si no lo sabéis, el lunes lu (diseño y contenido) y yo (me encargo de la parte técnica y de posicionarla) lanzamos la web de vivan los lunes. Una apuesta sencilla para convertir los lunes en un día de ocio más de la semana, comenzando así con buen pie ofreciendo diferentes alternativas culturales y de ocio en Madrid #vivanloslunes. Una selección de de 6 actividades que hacer los lunes en pdf.

Facebook alcanza la cifra de 350 millones de usuarios y Mark Zuckerberg escribe una carta abierta a todos los usuarios. En esta carta da las claves del futuro de las redes sociales: compartir y controlar.

Cada vez tenemos más conexiones dentro de Facebook, más amigos y cada vez más dispares, por lo que cuando compartimos algo tenemos que controlar más con quién lo estamos haciendo. Así Facebook va a proveer de más herramientas para controlar con quién se comparte ciertos datos, dando la posibilidad de controlar uno a uno que ven de nosotros nuestros contactos. Eliminan definitivamente las redes regionales que no eran una manera eficaz de agrupar intereses desde que Facebook dejó de ser una red estudiantil y se conviertió una red global.

Cada vez Facebook es más internet y para muchos cada vez más internet significa entrar en Facebook. Nunca habiamos estado tan hiper conectados todo el mundo entero.

Ayer Dreamhost experimentó un network failure que afectó a todas las webs alojadas en sus servidores. Desde 2005 que contraté el hosting nunca había tenido problemas. Alguna caída de vez en cuando, pero algo normal, no es un servicio que te asegure cinco nueves de servicio (99,999% de estabilidad). Tampoco tengo nada crítico alojado, pero fastidia ver como tu páginas no responden y devuelven un error 500 durante TODO un día. A parte de algun dinerillo de adsense que se perdió.

Era impresionante ver los tweets de la gente, una muy mala imagen para empresa; todo el mundo anunciaba que migrarían de servidor que ya no aguantaban más a Dreamhost. Desde este verano las caídas se están produciendo muy a menudo y es normal que la gente esté rebotada.

En Dreamhost hay alojadas todo tipo de páginas desde blogs con wordpress, tiendas online o pequeñas webs corporativas de PYMES. Es un dominio barato, relativamente con lo que ofrece, aunque lo haga sobre explotando sus recursos y creyendo que nadie va a llegar al límite de lo que ofrecen. Por supuesto, no es gratis así que se espera que cumplan con los términos del servicio y intente solucionar estos servicios, por que sino van a ver como muchas gente se pira y encima con una mala publicidad hacia a ellos. La gallina de los huevos de oro se terminará acabando.

Más información | Dreamhost Status

Twitter ha comenzado a probar una vieja funcionalidad para todos los usuarios de twitter: los RT (retweet). Era una acción bastante común habitualmente y que todas las aplicaciones de twitter disponen. Es curioso que para hacer un retweet haya que hacerlo con alguna aplicación de estas o hacerlo manualmente (una pesadez). Así que Twitter ha decidido permitir los retweet desde el timeline, pero de momento a algunos usuarios en forma beta al igual que hicieron con las listas.

En las imágenes veis como han diseñado la nueva funcionalidad. Ya la vimos hace tiempos en un diseño en papel (mola esos bocetos en papel). Esperemos que los RT no se vuelvan contra twitter, al ser más accesibles, a veces parece que la gente se pasa con ellos y retweetea cualquier cosa.

Nace un nuevo término y una nueva faceta que las empresas tienen que tener en cuenta Socialnomics

Vía | Mixer

De un tiempo a esta parte me he aficionado a comprar dominios. Se puede llamar afición o adicción, de casi todos he sacado al menos el dinero que me costó en dreamhost. Un buen dominio con una palabra clave siempre ayuda en la búsqueda y por supuesto, una buena optimización de el contenido pensando en los buscadores: malta, tdt2010…

En otros ni he metido un misero adsense para que un paracaidista de google clickeé, ni tampoco lo he llevado a un mal parking en alguna empresa de venta de dominios. Está sin explotar.

Para rentabilizar los que tengo y los futuros habrá que aplicarse con el adsense, adwords, openx y SEO.

No creo que venda ninguno. Aunque siempre existe esa esperanza de encontrar la palabra mágica que alguien desee y tenga pasta.

¿Por qué hay gente que recompra dominios?

La subasta de dominios suena bien. Sedo.com es una empresa que funciona, ¿pero existe a estas alturas algun dominio interesante libre? Piensa en alguna palabra, seguro que está pillada. Quizás todas las palabras que llevo escritas en este post tienen un dominio .com comprado por alguna chalado. Los dominios premium son aquellos que designan una palabra tan genérica que solo su nombre te puede reportar visitas y un buen posicionamiento orgánico. Aunque resulte una falacia a estas alturas, seguimos creyendo en esto. A pesar de todas las técnicas SEO que nos rodea y de comprobar que dominios con nombre que no tienen nada que ver con el negocio al que se dedica triunfa más que otras que se gastan miles de euros en un dominio premium.

Un buen contenido es lo que hace que la gente quiera visitar tu web, pero un buen dominio hace que recuerden mejor como entrar. El dominio en la era internet es la marca. Aunque todas las marcas tienen ya su dominio y la ley les protege de la usurpación y chantaje de sus marcas comerciales en internet, pero siempre se puede sacar provecho. Faltas ortográficas, juegos de palabras o una hábil heuristica para crear nuevos nombres a partir de dominios/marcas bien conocidas. SEO de sombrero negro, penalizable o libre de cargo para rentabilizar un dominio hecho un saco de escombros de palabras claves vacías de contenido.

Este fin de semana asistí por primera vez a un partido de rugby. Y no ví uno sólo, si no tres partidos: las semifinales y la final de la Liga Superibérica de Rugby (SIR) 2009(la primera edición del torneo) y que tuvo lugar en el estadio del Rayo Vallecano, convertido en uno de Rugby. Alli se enfrentaron los cuatro mejores equipos de la liga regular: Los Gatos de Madrid, Los Korsariak, Mariners y Los Almogavers.

Hice algunas fotos de la gran final entre los Gatos de Madrid y los Mariners. Que ganaron los Gatos por un ensayo más en un igualado 28 -28.

En definitiva, un experiencia agradable y recomendable para todo iniciado. Eso sí, es necesario tener alguien al lado que te vaya explicando las reglas. Entenderás que no sólo son ostias, si no que hay mucha estrategia y nobleza en el juego.

más información | página oficial de la Liga Superibérica de Rugby

ya está aquí Firefox 3.5. después de cinco betas y dos release candidate, tenemos el navegador más avanzado del momento. Sólo falta que las extensiones vaya actualizándose. Y hablando de eso, echarle un ojo al concurso de addons de Mozilla Firefox.

más información sobre las novedades que trae, por supuesto, en Mozilla Hispano.

Ya tengo entre mis manos la guía de los imprescindibles de 11870.com. Qué ilusión me ha hecho, aunque sea una tontería, aparecer en ella con uno de mis comentarios. Es un detalle por parte del 11870.com regalarnos con esta guía para celebrar sus dos añitos de vida. Sólo se la han enviado a los usuarios más activos, vaya, no sabía que lo fuera :)

En la foto mi comentario sobre el Cerro del Tío Pio en Vallecas. Un parque genial donde se puede divisar casí todo Madrid. Un acierto haberlo incluido en la guía porque es uno de los lugares más desconocidos de Madrid y que podría ser un buen lugar de visita para los turistas que vienen a la ciudad.

La guía cuenta con los mejores sitios de Barcelona, Madrid, Bilbao, Sevilla, Valencia, Zaragoza. Con lo que ya sabéis, los mejores restaurantes, sitios para pasar el día, para comprar o para salir de noche.

Si os interesa echarle una ojeada os podéis bajar la versión en pdf. Ojo!, son 70 megas.

Google ha trabajado duro para ofrecer un interfaz digna de dispositivos avanzados como el iphone o el HTC Android G1 . Puede que por tener en el mercado un teléfono propio no se han centrado en realizar aplicaciones nativas para el iphone por lo que el trabajo web ha sido más intenso. Han utilizado las técnicas más avanzadas: HTML 5, CSS 3 y todos esos hack, por llamarlo de algun modo, que permiten redimensionar y ofrecer una interfaz acorde a un pantalla táctil. Interacción y diseño excepcionales. Es casi planteable utilizar gmail en lugar de la aplicación de mail del propio iphone.

Versión móvil: gmail iphone

Flickr dispone de varias aplicaciones que aprovechan su api, pero no tiene ninguna aplicación par el iphone propia. Pero no ha dejado pasar la oportunidad de sacarle el máximo partido a safari en el iphone.

Su versión móvil es sobria y con los efectos para manejar el pase de imágenes, la búsqueda de imágenes y presentar una página de perfil que cumpla con las necesidades de los usuarios a la hora de visualizar y gestionar su colección de imágenes.

Versión móvil: m.flickr.com

Otro buen ejemplo es la web movil para el

Como último ejemplo satisfactorio, se encuentra la web adaptada para el iphone de caja . La entidad bancaria ya contaba con una aplicación móvil, pero en esta es claramente superior. Aprovecha la gran pantalla para mostrar mucha más información. Las transicciones entre cada página se hace más suaves mediante la aplicación de ajax en su interface. Sorprende la cantidad de información y operaciones que podemos realizar en la palma de la mano de una forma segura.

Versión móvil: caja para iphone

Todas estás aplicaciones se ejecutan desde safari. Son simplemente páginas webs adaptadas y en muchos caso cumple mejor su función que una aplicación nativa. Para mejorar el acceso a estas web el iphone cuenta con la opción de enviar un acceso directo al menú principal con el icono de la web. A la hora de iniciarla será prácticamente como un aplicación más, abriendose el correspondiente enlace en safari. Todas ocultan la url para mejorar la experiencia del usuario frente a la pantalla. Casi se nos olvida que estamos en una web.

Después de pegarme toda la mañana con La Fonera y haberlo intentado con linux y mac, al fin tengo la fonera 2.0 funcionando de nuevo. La mayor novedad, poder bajar directamente torrents y archivos de megaupload al disco duro conectada al router.

Me la cargué hace unas semanas intentando actualizar a la ultima versión del firmware (Platero) saltandome dos firmware intermedios. El problema vino por hacerlo desde la herramienta web que sólo era posible desde Tantor, OktoPussy o Caterpillar. Yo tenía al pequeño Alfred…

El primer síntoma vino al ver como el SSID cambiaba al nombre «FON_ATTENTION_PLEASE_CONNECT«. Un grito bastante claro de que algo iba mal. Al conectarse aparecía el mensaje de que se cargara un firmware válido, pero todos los que intenté subir vía web los rechazaba. Viendo en varios foros, el problema era que me había cargado la tabla en la que se almacena el archivo loader.bin, FONXX.image y FONXX.image2. La solución era forzar un reboot del router.

Para hacer el reboot se necesita un ordenador conectado con el cable ethernet al puerto WAN del router (el blanco). También necesitamos un servidor TFTP para enviar los archivos que necesita desde el ordenador a la fonera.

En la wiki FOn está explicado como hacerlo tanto para windows, linux y mac.

Paso a seguir para un reboot en la Fonera 2.0.

1. Necesitamos un servidor TFTP. Voila, mac os X (recordemos que es un UNIX dopado) tiene un daemons que actua de TFTP , así que lo único que tenemos que hacer es configurarlo, meter los archivos que queremos y arrancarlo. En este tutorial se explica bastante bien como configurar TFTP en mac.

2. Como la ip del router al arrancar es 192.168.1.1 al arrancar tendremos que cambiar la ip de nuestra ethernet (conectada de ordenador a la fonera por la entrada WAN). La que tenemos que tener es 192.168.1.254. Paso sencillo: #sudo ifconfig 192.168.1.254

3. Ahora viene la movida. Tenemos que desenchufar y enchufar la fonera. Tenemos apenas 2 segundos para ejecutar el siguiente comando después de que nos devuelva los ping desde 192.168.1.1

#echo -e "\0377\0364\0377\0375\0006" >break.bin; sudo nc -vvv 192.168.1.1 9000 < break.bin; telnet 192.168.1.1 9000

Un consejo es tener las dos ventanas preparadas del Terminal y darle rápido. A mí me costó unos 4 o 5 intentos...

Si lo hemos hecho bien debería salir:

== Executing boot script in 1.000 seconds - enter ^C to abort

e inmediatamente:
ReBoot>

donde ya podemos introducir los comando.

El primero que ejecute fue:
RedBoot> fis list

indica la tabla de particiones. Tiene que estar como viene en la wiki (esta tabla).

En mi caso tenía mal la image (es decir, el firmware) en este caso lo recomendable es cargar desde el tftp la última release (este archivo lo hemos tenido que haber metido en nuestros servidor tftp).
.

Con los siguientes comando:

RedBoot> load -r -b %{FREEMEMLO} .image
Raw file loaded 0x80040400-0x80380403, assumed entry at 0x80040400
RedBoot> fis delete image
..........................................
RedBoot> fis create image
..........................................

esto puede tardar unos 20 minutos, después ya está lista la fonera. Desenchufamos y enchufamos y se tendrá que iniciar normalmente.

Google App Engine ha anunciado que ya soporta java junto a python en su plataforma de aplicaciones distribuidas (su particular nube).

Desde el inicio ha sido uno de los lenguajes más demandados. Conseguir un alojamiento que soporte aplicaciones webs de java no es barato por lo que esta nueva vía se hace bastante interesante.

De momento, el soporte de java está limitado a unas 10.000 cuentas . Te puedes apuntar para que te comunique cuando tendrás el soporte activo en tus aplicaciones. Hasta entonces se puede probar el SDK y el interesante plugin para eclipse. Aquí tienes una buena de empezar con java en Google App Engine.

El plugins permite crear la estructura de la aplicación, simular en local el entorno que tendremos en google app engine y, por último, desplegar desde eclipse la aplicación en la infraestructura App Engine en unos sencillos pasos.

Como era previsible ese soporte de java está limitado a un sandbox. Lo que hace que nuestras aplicaciones se desarrollen dentro de un entorno seguro, con limitaciones de lo que se puede hacer. Se ha comentado que se soporta API de Servlets, JDO, JPA, javax.cache y javax.mail. Además de GWT que acabaremos utilizado dadas las facilidades que nos ofrecen. Falta saber si se podrá usar Spring MVC, algunos dicen que sí, según este listado de APIs y frameworks que han ido probando.

Actualización: Google App Engine soporta Spring Framework finalmente. Queda claro viendo la demo que tienen en el sdk Autoshoppe implementada con Spring. :)

En el siguiente vídeo se realiza una demostración de algunas de las caracteristicas de Java en el Google App Engine como su soporte a JDO y su uso en Eclipse (prueba y despliegue). La instalación y uso es bastante sencilla.

La forma de vender un producto, darle relevancia o obtener beneficios vía publicidad son distintos a hace unos años.

Para entender mejor este nuevo paradigma en el marketing actual surge el libro «Del 1.0 al 2.0: claves para entender el nuevo marketing«.

Se puede descargar gratis o pedir una versión vía bubok en papel.

Aún no he tenido tiempo de leerlo del todo, pero os lo recomiendo, podéis consultar cada uno de los capítulos escritos por diferentes profesionales del mercado español, además de reconocidos bloggers. Un libro colaborativo que aprovecha las herramientas que promulgan en sus textos.

No era más que un iframe que ocultaba hábilmente el botón de update de la página de twitter, y si pulsabas estando logeado en tu cuenta de twitter mandabas el mensaje «don’t click [y la dichosa url del boton]» como actualización de estado. Así que otros incautos followers tuyos lo vería de nuevo y propagarían el clickjacking.

En ajaxiam explican como lo hicieron.


iframe { position:absolute;width:550px;height:228px;top:-170px;left:-400px;z-index: 2;opacity: 0;filter: alpha(opacity=0); }
button { position:absolute;top:10px;left:10px;z-index:1;width: 120px; }


Un par de líneas para comprende lo sencillo que fue aprovechar la actualización de status para propagarse. Una simple visita con el firebug lo delata.

Y por cierto, al estar acortada con una tinyURL ya ha sido bloqueada por uso inapropiado. http://tinyurl.com/amgzs6

Esta semana los usuarios de los PVR de inOut se han dado cuenta del valor de la Sincroguia, o al menos el que cree que tiene InOut. Al adquirir un PVR de InOut se anunciaba ambiguamente que el servicio de Sincroguia se promocionaría gratuitamente hasta finales de 2007.

A partir de 2008 no se sabía nada. Luego se prolongó por 6 meses. Más tarde hasta el 1 de febrero de 2009. InOut parecía que no tenía modelo de negocio, tampoco la web proporciona demasiada información sobre el asunto.

La oferta que han remitido por email es la siguiente: 34’95€ (29’95€ PVP hasta el 15 de Febrero de 2009). ¿Vale eso por un año? Yo creo que no. Sobre todo motivado por el funcionamiento del equipo: continuos cuelgues, haber refrito 2 discos duros desde que lo tengo y los fallos de la Sincroguia en las grabaciones ( muchas se pierden).

La Sincroguia no sería tan importante, sino fuera por que estos equipos comercializados en España por Carrefour y InOut no suministran la EPG convencional. Convierte un servicio fundamental de la TDT en su negocio: la Sincroguia. Pero eso sólo ocurre en España (donde los fabricantes nos está obligados a facilitar EPG en sus equipos).

Sin renovación de la Sincroguia no se puede grabar. Adiós al disco duro y todo los servicios de PVR, nos quedamos con un TDT sin información de programación que se cuelga cada poco. En mi experiencia personal he tenido que cambiar dos veces de disco duro porque básicamente se los fundió, no tiene un sistema de apagado de disco mientras no se está usando, además tuve que buscarmelas para recuperar el firmware porque simplemente dejó de funcionar.

¿Cuál es la solución? De momento, yo no no voy a pagar. Existen desarrollos de código abierto sobre estos equipos. Recordar que el hardware es Siemens, el cual es comercializado en Alemania y Reino Unido por ellos mismo. Además todo el software tiene licencia GNU hasta el de InOut por lo que puedes cargar otros firmware.

He estado mirando es el proyecto VDR-M7x0. basado sobre el Siemens Gigaset M740/M750. Lo que hace es habilitar el EPG de los equipos e incorporar diversas novedades y funcionalidades adicionales.

Quizá quede poquisima gente ya que no haya oido  hablar sobre spotify, la nueva sensación de la música en internet. Esta semana empezó a explotar el servicio que de momento funciona en varios países de Europa, entre ellos España. Para él que no sepa que es Spotify, decir que es como tener una biblioteca inmensa de canciones en internet que podemos escuchar sin limitaciones. Un last.fm dopado con iTunes. Cuatro de las discográficas más importante del mundo casi el 90% de la toda la música del mundo está presente: Sony BMG, Universal, EMI y Waner Music. Pero de hecho ese 10% aun es mucho y quedan grupos independiente que no están en la plataforma.

Se puede usar oyéndolo en modo radio, o buscar un grupo, canción o album y escuchar todo lo que se quiera de ese artista. También se puede crear lista de reproducción y enviar canciones (los enlaces directos para escucharlo en el programa). Por cierto, he visto que hay circulando una lista pública de Twitter con recomendaciones de canciones.

Su modelo de negocio se basa en tres tipos de cuentas: free con anuncios (Yo aun no he oído ninguno, según dicen están bastante espaciado, ya llegará), una cuenta de 24 horas(sin anuncios) por un dolar y otra de 1 mes por 10 dolares. Aunque aun no le veo el sentido de pagar por el servicio, ya que pagar no ofrece ninguna funcionalidad extra.

Tenéis una descripción más detallada en Genbeta.

Han potenciado las posibilidades de colocar en portada las noticias por parte de los periodista de una forma más destacada y de rápido acceso. Los suplementos toman un lugar más destacado en portada. Además de incorporar las actualizaciones de los blogs y de los encuetros digitales.

La verdad, es que el anterior diseño no me parecía malo. En contra a este le falta contenido en portada. Se han ordenado algunas cosas pero también se han perdido otras importantes, ahora más escondidas. Veremos si hay sorpresas o se queda en una simple evolución, no revolución.

otras opiniones: Sobre el rediseño de El Mundo, La revolución tendrá que esperar

Hace unos meses descubrí la revista AdBusters, a través de la iniciativa «Hoy no compro nada» que promueve cada año. Kalle Lasn, fundador de la revista, ha iniciado una cruzada para denunciar la contaminación de nuestro espacio mental por la grandes marcas. Ya no sólo nos venden un producto sino un estilo de vida quitandonos nuestra capacidad de decisión autónoma.

Según Kalle Lasn, vivimos vidas diseñadas. Dormir, comer, ir en coche, trabajar, comprar, mirar la televisión y volver a dormir. Ya no existen los minutos espontáneos. Nuestro papel se reduce a mirar y escuchar, después a comprar lo que hemos visto y oído.

El libro Sabotaje Cultural escrito por Kalle Lasn intenta explicar una estrategia para la desmarketizacion de la sociedad. Espero hacer una breve reseña de lo que lea. De momento, las pocas páginas que he leído me ha enganchado su forma directa de contar las estrategias de las grandes marcas para manejar los hilos de la sociedad moderna devoradora de productos. De como estamos adoptando cada vez más fuertemente y perdiendo la identidad de nuestra cultura frente a la monocultura de America®.