The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

Posts tagged “facebook

Semi-Synchronous Replication at Facebook

 After intensive testing and hack, we started using Semi-Synchronous MySQL Replication at Facebook production environments. Semi-Synchronous Replication itself was ready since MySQL 5.5 (GA was released 3.5 years ago!), but I’m pretty sure not many people have used in production so far. Here are summary of our objective, enhancements and usage patterns. If you want to hear more in depth, please feel free to ask me at Percona Live this week.

Objective / Why Semisync?

  The objective of the Semi-Synchronous Replication is simple — Master Failover without data loss, without full durability.

 First, let me describe why the objective is difficult without semisync.

 There are a couple of fast slave promotion (master failover) solutions. My own MHA covers both fully automated and semi-automated MySQL failover solution. Fully automated means both failure detection and slave promotion are done automatically. Semi automated means failure detection is not done but slave promotion is done by one command. Time to detect failure is approximately 10 seconds, and actual failover is taking around 5 to 20 seconds, depending on what you are doing during failover (i.e. forcing power off of the crashed master will take at least a few seconds). Total downtime can be less than 30 seconds, if failover works correctly. I’m using term “Fast Failover” in this post, which includes both automated and semi-automated master failover.
 In MySQL 5.6, GTID based failover is also possible. Oracle’s official tool mysqlfailover automates MySQL master failover using GTID. The latest version of MHA also supports GTID.

 Both mysqlfailover and MHA rely on MySQL replication. MySQL replication is asynchronous. So there is a very serious disadvantage — potential data loss risk on master failover. If you use normal MySQL replication and do automated master failover with MHA/mysqlfailover, you can do failover quickly (a few seconds with MHA), but you always have risks of losing recently committed data.

 If you don’t want to take any risk of losing data, you can’t do fast master failover with normal MySQL replication. You have to do the following steps in case of master failure.

– Always set fully durable settings on master. By fully durable I mean setting innodb_flush_log_at_trx_commit=1 and sync_binlog=1.
– On master crash, wait for a while (10~30 minutes) until the crashed master recovers. Recovery takes long time because it involves OS reboot, storage and filesystem recovery, and InnoDB crash recovery.
– If the crashed master recovers, you can continue services without losing any data. Since all data exist on the master, slaves can continue replication. BTW official 5.6 had a bug causing all slaves broken in this scenario, but this bug was fixed in 5.6.17.
– If the crashed master doesn’t recover (H/W failure etc), you need to promote one of slaves to a new master. There is a risk of losing some data but you don’t have any other choice.

 This “safer” approach has two issues.
– Longer downtime. This is because you have to wait for master’s recovery.
– You can’t eliminate risks of losing data. If master is dead and never recovers, your risk of losing data is the same as doing fast failover.

 So, in bad cases, you have to suffer from both longer down time and losing data.

 Semi-Synchronous Replication is helpful to prevent from losing data.

 If you do not care about data loss risk, there is no reason to use Semi-Synchronous replication. You can use normal MySQL replication and do fast failover with mysqlfailover or MHA. Facebook is one of the companies to care about data loss risk with MySQL, so that’s why we were interested in Semi-Synchronous replication a lot.
 Semisync replication was originated from Google in 2007. Official MySQL supported from 5.5. Actual implementation algorithm was substantially different from Google’s.

 MySQL Cluster and Galera offers synchronous replication protocol in different ways. I do not cover them in this blog post.

 Semi-Synchronous Replication currently has two types of different algorithms — Normal Semisync and Loss-Less Semisync. Let me explain the differences.

Differences between Normal Semisync and Loss-Less Semisync

 Loss-Less Semisync is a new Semisync feature supported in official MySQL 5.7. Original implementation was done by Zhou Zhenxing as “Enhanced Semisync” project, and also filed as a bug report. Oracle implemented based on his idea, and named Loss-Less semisync for it. So Enhanced Semisync and Loss-Less Semisync have same meanings. I say Loss-Less semisync in this post.

 Normal semisync and loss-less semisync work as below.

1. binlog prepare (doing nothing)
2. innodb prepare (fsync)
3. binlog commit (writing to fscache)
4. binlog commit (fsync)
5. loss-less semisync wait (AFTER_SYNC)
6. innodb commit (releasing row locks, changes are visible to other users)
7. normal semisync wait (AFTER_COMMIT)

 On normal semisync(AFTER_COMMIT), committing to InnoDB is done before waiting for ack from semisync slave, so the committed rows are visible from applications, even though semisync slaves may not have received the data. If master is crashed and none of the slaves received the data, the data is lost but applications may have seen them. This is called phantom reads, and in many cases it’s problematic.

 Loss-less semisync (AFTER_SYNC) avoids the problem. Loss-less semisync commits InnoDB after getting ack from one of semisync slaves. So when committed data is visible from applications, one of the semisync slaves have received that. Phantom read risk is much smaller: if both master and the latest semisync slave are down at the same time, data is lost. But it’s much less likely to happen compared to normal semisync.

 To avoid data loss and phantom reads, Normal Semisync can’t meet your expectations. Using Loss-Less Semisync is needed.

 With Loss-Less Semi-Synchronous replication, committed data should be on one of the slaves, so you can recover from the latest slave. You can always do fast failover here.

Reduced Durability

 When you do fast failover, you can set reduced durable settings on master as well as slaves. Reduced durability means innodb_flush_log_at_trx_commit != 1 and sync_binlog != 1. With Semi-Synchronous replication, you can immediately start failover when master is down. When promoting a slave to the new master, identify the latest slave (highly likely one of the Semi-Synchronous slaves but not guaranteed) and apply differential logs to the new master. Master’s durability does not matter here, because there is no way to access master’s data during failover. So you can safely reduce durability. Reducing durability has a lot of benefits.
– Reducing latency on (group) commit because it doesn’t wait for fsync().
– Reducing IOPS because the number of fsync() calls is significantly reduced: from every commit to every second. Overall disk workloads can be reduced. This is especially helpful if you can’t rely on battery/flash backed write cache.
– Reducing write amplification. Write volume can be reduced a lot, even less than half in some cases. This is important especially when using flash devices, because less write volume increases flash life expectancy.

Requirements for Semisync Deployment

 To make Semisync work, you need at least one semisync reader (slave with semisync enabled) within the same (or very close) datacenter as the master. This is for latency. When semisync is enabled, round-trip time(RTT) between master and one of the semisync slaves is added to transaction commit latency. If none of the semisync slave is located within close datacenter, RTT many take tens or hundreds of milliseconds, which means you can commit only 10~100 times from single client. For most environments, this will not work. You need a slave within close datacenter.

 To make fast failover work without data loss, you need to make sure Semi-Synchronous Replication is always enabled. MySQL Semisync has a couple of points where optionally semisync is disabled:
– Exceeding timeout (exceeding rpl_semi_sync_master_timeout milliseconds to get ACK from all of the semisync slaves)
– No semisync slave (can be controlled via rpl_semi_sync_master_wait_no_slave)
– Executing SET GLOBAL rpl_semi_sync_master_enabled=0

 If you want to enable semisync always, you make sure these scenario won’t happen. Set infinite or very long timeout, and have at least two semisync readers.


 Facebook Enhancements to Semi-Synchronous Replication

 We spent a lot of time for testing Semi-Synchronous replication in 2013. We found some S1 bugs, serious performance problems, and some administration issues. Our MySQL Engineering team and Performance team worked for fixing issues and finally our Operations team deployed Semisync in production.

 Here are our major enhancements.

Backporting Loss-Less Semisync from 5.7

 As described above, Loss-Less Semisync is needed to prevent data loss and phantom reads, so we backported Loss-Less Semisync patch from official MySQL 5.7 to our Facebook MySQL 5.6 branch. It will be merged to WebScaleSQL branch soon.

 Interestingly, when we tested semisync performance, Loss-less semisync gave better throughput than normal semisync, especially when the number of clients is large. Normal semisync caused more mutex contentions, which was alleviated with loss-less semisync. Since Loss-less semisync has better data protection mechanism, we concluded there is no reason to use normal semisync here.

Semisync mysqlbinlog

 Starting from MySQL 5.6, mysqlbinlog supported remote binlog backups, by using –raw and –read-from-remote-server. On remote binlog backups, mysqlbinlog works like a MySQL slave. mysqlbinlog connects to a master, executing BINLOG DUMP command, then receiving binlog events via MySQL replication protocol. This is useful when you want to take backups of the master’s binary logs. Slave’s relay logs and binary logs are not identical to master’s binary logs, so they can’t directly be used as backups of the master’s binary logs.

 We extended mysqlbinlog to speak Semisync protocol. The reason of the enhancement is that we wanted to use “semisync mysqlbinlog” as a replacement of local semisync slaves. We usually run slaves on remote datacenters, and we don’t always need local slaves to serve read requests / redundancy. On the other hand, as described at above “Requirements for Semisync Deployment” section, in practice at least two local semisync readers are needed to make semisync work. We didn’t like to run additional two dedicated slaves per master just for semisync. So we invented semisync mysqlbinlog and use it instead of semisync slaves, as shown in the below figure.

 Compared to semisync slave, semisync mysqlbinlog has a lot of efficiency wins.

– semisync slave has lots of CPU overheads such as query parsing, making optimizer plans. semisync mysqlbinlog does not have such overhead.
– semisync slave writes 2x (relay log and binary log). semisync mysqlbinlog writes binary log only.
– For semisync slave, the way to write to relay log is not efficient. IO thread writes to kernel buffer per each binlog event. For regular auto-committed transactions, it consists of three binlog events (query BEGIN, query body, and commit XID). When using InnoDB only, writing to kernel buffer for every XID event is enough (though it does not cover DDL). By writing to kernel buffer for every XID event, it makes the frequency of kernel buf flush by less than 1/3. semisync mysqlbinlog could easily do such optimizations. We have not done yet, but it is even possible to make mysqlbinlog send back ACK before writing, to a file, and the extension is very easy.
–  Slave causes contention between SQL thread and I/O thread, so IO thread itself slows down, which slows down semisync master throughput too. Semisync binlog does not have such overhead because there is no SQL thread.

 With mysqlbinlog reader, master failover step becomes a bit tricky. This is because mysqlbinlog is not mysqld process so it doesn’t accept any MySQL command, such as CHANGE MASTER. When doing master failover, it is highly likely that one of local mysqlbinlog has the latest binary log events, and the events should be applied to a new master. New MHA version (0.56) supported the feature.

 In this configuration, mysqlbinlog processes need to be highly available. If all semisync mysqlbinlog processes are down, semisync is stopped or suffering from long wait time.. 

Reducing plugin_lock mutex contention

  Prior to MySQL 5.6.17, there was a performance bug that transaction commit throughput dropped significantly when there were non-semisync many slaves or binlog readers, even if there was only a few semisync readers. On typical deployments, there are two or three semisync readers and multiple non-semisync readers, so performance drop with many non-semisync readers was annoying.
 The performance drop was caused by “plugin_lock” MySQL internal mutex on master. For those who don’t know, semisync is a plugin in MySQL, and it’s not installed by default. The plugin_lock mutex was needed by semisync binlog dump threads only, but actually the mutex was held by all binlog dump threads. We looked into the problem further.
 First we tried replacing plugin_lock mutex with read/write mutex. It actually did not help much. But Linux profiling tools showed that plugin_lock still caused contentions. During profiling, we learned that most/all glibc rw-locks had an internal lock (mutex-like thing) on which threads could stall. The pattern was get lock, get exclusive access to cache line to modify data, release lock. This was relatively expensive for plugin_lock mutex, since it doesn’t do any expensive I/O inside.

 So switching plugin_lock to read/write lock was actually a bad idea. It was needed to remove below plugin related locks as long as possible. There are four major plugin related mutexes in MySQL.
– plugin_lock
– plugin_lock_list
– plugin_unlock
– plugin_unlock_list

 We also noticed that Delegate classes had read/write locks and they caused very hot contentions (especially Binlog_transmit_delegate::lock). The read/write lock protects a list, so probably switching to lock-free list was possible. BTW we noticed that performance schema did not collect mutex statistics on the mutexes on Delegate classes (bug#70577). 

 The real problem was all of the above locks were held not only by semisync binlog readers, but also non-semisync binlog readers.

 Based on the above factors, we concluded removing all plugin mutexes was not easy, then we decided to optimize to hold these locks by semisync binlog readers only, and not holding by non-semisync binlog readers. The below is a benchmark result.

 x-axis was the number of non-semisync binlog readers, y-axis was concurrent INSERT throughput from 100 clients. The number of semisync binlog readers was always 1 to 3. Detailed benchmark conditions were described in a bug report.
 Hopefully our patches were finally merged to 5.6.17 and 5.7 so everybody can get benefits easily.

 With all of the enhancements, we could get pretty good benchmark results with semisync.

 This is a mysqlslap insert benchmark on the master, with one semisync slave/mysqlbinlog running. x-axis is the number of clients, y-axis is the number of inserts on the master. Enhanced means loss-less semisync.
 Normal slave is traditional (non-semisync) slave. Enhanced mysqlbinlog is our semisync usage pattern. As you can see, loss-less semisync beats normal semisync due to internal mutex contention reductions. semisync mysqlbinlog also beats semisync slave because of much less overheads. This shows that loss-less semisync scales pretty well.

Conclusion and Future Plans

 After several performance improvements, Semi-Synchronous replication became good enough for us. From performance point of view, I expect that single-threaded application performance will be next low-hanging fruits. On our benchmarks, we got around ~2500 transaction commits per second with semisync (0.4ms per commit). Without semisync, it was easy to get ~10000 transaction commits  per second (0.1ms per commit). Of course semisync adds RTT overhead, but on local datacenter network, RTT is much lower than 0.3ms. I think there is another semisync overhead here, so will revisit this issue and will work with Oracle Replication team and outside experts.

Lost User’s

Facebook ha perdido 10 millones de usuarios en tres meses

Facebook ha bajado de 550 a 540 millones de usuarios en los meses de junio a septiembre de 2010, según los datos de Adplanner de Google utilizados para realizar un estudio sobre Demografía del Social Media en el tercer trimestre de 2010.

El estudio aporta otros datos sorprendentes, tanto de Facebook como de otras redes sociales como Twitter o MySpace. A pesar de todo, no hay que alarmarse, significa únicamente que las redes sociales comienzan a crecer a un ritmo inferior, tras el boom experimentado en los últimos dos años.

Con respecto a Facebook, la caída de usuarios sólo muestra que el crecimiento se está estacionando, tras la etapa de investigación y curiosidad por la red social por parte de los internautas.

Sin embargo, quien se conecta a Facebook, lo hace más tiempo que antes. De media, pasa 23 minutos en la red social. Comparado con los tiempos que se pasa en otras redes sociales (14 minutos en MySpace; 13 en Twitter y casi 10 en LinkedIn) al día, Facebook continúa ganando por goleada.

Eso sí, Facebook también registra una caida de usuarios en el segmento de edad que mayor crecimiento había experimentado hasta ahora: los mayores de 54 años. Del 16% ha caído al 10% en los últimos seis meses.

Según el informe, Facebook llega al 57% de los estadounidenses, y al 35% de los habitantes de todo el planeta. Los porcentajes no dejan de sorprender. Lo que no varía es la distribución por sexos. El 57% de los usuarios de Facebook son mujeres.

Datos de Twitter

Twitter tampoco crece demasiado en el tercer trimestre. Si acabó el Q2 con 96 millones de usuarios, ahora posee 98 millones en todo el mundo.

Por edades, Twitter crece más entre el público más joven. De hecho registra un aumento del 16% entre los usuarios con edades comprendidas entre 18 y 34 años. Eso sí, los usuarios entre 35 y 64 años caen un 9% en los últimos seis meses.

Con respecto a otras redes sociales, cabe citar que MySpace ha conseguido ganar un millón de usuarios en todo el mundo en el último trimestre y ya se sitúa en 67 millones de usuarios, según los datos de Google Adplanner. Las mujeres suponen el 64% del total de sus usuarios.

Fuente: Trece Bits

Foursquare VS. Facebook

Foursquare versus Facebook Places: primeros datos

from El Blog de Enrique Dans by Enrique Dans

Es una de esas confrontaciones que todo el mundo está siguiendo con cierta atención: la empresa que encabezó el despegue significativo de las aplicaciones de geolocalización, Foursquare, frente a la gran red social que incorporó posteriormente dichas aplicaciones.

Los datos fríos: en este momento, cuatro millones de usuarios en Foursquare, frente a treinta millones en Facebook Places, anunciado el pasado 18 de agosto. Más de siete veces más. Sin embargo, no nos quedemos únicamente con el frío dato numérico: sabíamos que para una red con casi seiscientos millones de usuarios activos, llevar una fracción de éstos a un nuevo servicio sería prácticamente trivial. Pero ¿qué más hay detrás de esos datos?

En Silicon Alley Insider se dedicaron a llevar un registro del número de personas que hacían checkin en tres localizaciones específicas en la ciudad de Nueva York durante un período de cinco semanas, y se encontraron con un interesante dato: los usuarios de Foursquare son evidentemente menos, pero son en cambio inmensamente más activos en el uso de la herramienta. De hecho, todo parece indicar que, al menos por el momento, los treinta millones de usuarios de Facebook Places son más bien inactivos: tienen la herramienta a su disposición, sí, pero la usan verdaderamente muy poco. Puede haber otros factores, tal vez el tiempo de difusión no haya sido suficiente o exista un sesgo neoyorquino a favor de una herramienta que nació y se empezó a popularizar en esa misma ciudad, pero por el momento, Foursquare parece mantener claramente su ventaja a la hora de medir actividad. Una apreciación coincidente con lo que indican algunas encuestas iniciales de preferencias, o con la opinión obviamente sesgada de Dennis Crowley, uno de los fundadores de Foursquare, que parece haber estado haciendo sus deberes de análisis de la competencia utilizando Facebook Places y lo tacha de experiencia aburrida.

De una u otra manera, parece que la batalla por los servicios de geolocalización y por dotarlos de una propuesta de valor no solo de cara a los usuarios, sino también para los propietarios y gestores de los locales que son geolocalizados no va a ser ningún paseo militar. Obviamente, la promesa de tener metidos en su sistema a los varios cientos de millones de usuarios de la mayor red social del mundo no es poca cosa, pero si la experiencia de uso de éstos no les lleva a repetir, o peor aún, ni siquiera llegan a probar la herramienta, la difusión más lenta pero mucho más comprometida vía usuarios hiperactivos de Foursquare podría acabar teniendo un valor mucho más elevado. Veremos cómo va evolucionando la cosa…

Facebook Disconnect, una extensión de Chrome que hace invisibles los cuadros de Facebook

Facebook Disconnect, una extensión de Chrome que hace invisibles los cuadros de Facebook: “

facebook disconnect

Seguro que alguna vez os habéis encontrado con el típico cuadro de Facebook en algunas páginas y que indica cuánta gente es fan de esa web, o el mensaje de “Conécate a través de Facebook”, o los típicos chats que permiten a la gente comentar en directo algunos eventos. Si no queréis ver eso más, Facebook Disconnect es la solución.Facebok Disconnect es una extensión para Google Chrome que ha sido diseñada por Brian Kennish, que es, precisamente, un ingeniero de Google. Instalando y activando la extensión aparantemente evitaremos que cualquier tipo de información sea enviada a Facebook desde las páginas web que tienen instalado el plugin de FB Connect.Aunque esto no supone que no podamos acceder a Facebook normalmente, sí que es una buena forma de evitar ver esos mensajes que a veces pueden ser un incordio y además, de evitar compartir nuestra información.Lo más curioso de todo el asunto es, seguramente, que esta extensión haya sido diseñada por un propio trabajador de Google, que últimamente tiene muchos frentes abiertos con Facebook. Aunque él mismo ha dicho que una cosa no tiene nada que ver con la otra y que es totalmente un proyecto personal e independiente, seguro que levanta algunas sospechas entre compañeros y competidores. ¿No creéis?

Vía | TechCruch
Más información | Descarga Facebook Disconnect

¿Facebook y Twitter reemplazarán a los lectores de feeds?, difícilmente…

¿Facebook y Twitter reemplazarán a los lectores de feeds?, difícilmente…: “

Google Reader vs. Facebook y Twitter
En vista del reciente declive de servicios como el otrora popular lector de feeds Bloglines, o la empresa Six Apart, antes dedicada al desarrollo de la plataforma Movable Type para blogs (la misma que Genbeta ocupaba en sus orígenes), muchas han empezado ya a augurar el declive de los lectores RSS, asegurando que estos se encuentran en retirada para dar paso a servicios sociales como Facebook y Twitter, que pueden ser usados como fuentes de información.

Justamente a raíz de esto, los de Google Reader han sacado a la luz unas cifras bastante esclarecedoras sobre el tema. Se trata de las estadísticas de uso de este lector de feeds desde su lanzamiento, las cuales desmienten que el uso de servicios como este esté decayendo. Muy por el contrario, la cantidad de usuarios activos de Google Reader ha aumentado de forma constante en ese periodo. De hecho, en el gráfico se aprecia que 2009 fue un año de crecimiento récord, donde el uso estuvo cerca de duplicarse (perdonadme la insensatez de aseverar esto sin las cifras exactas en mano).

Estadísticas de Google Reader

Que cierre Bloglines no debe ser interpretado como un síntoma de la salud de los agregadores de feeds en general, solo es síntoma de una alta concentración por parte de Google, lo cual no es necesariamente malo, ya que alternativas no faltan (FeedDemon el escritorio, montones de lectores de feeds para móviles, otros en la web como NewsBlur o Feedlook, etc), solo que ninguno ha sido capaz de ofrecerle a los usuarios un servicio del nivel del de GReader. Y en el caso específico de Bloglines, ya sabemos que este lector venía de capa caída desde hace tiempo.

Por supuesto que nos gustaría que existiera más descentralización en este mercado. Pero decir que el cierre Bloglines significa que la lectura de feeds RSS se viene abajo es ir demasiado rápido.

Redes sociales y lectores de feeds: complementos antes que competidores

¿Pero cómo interpretamos la explosiva popularización de Facebook y Twitter como fuentes de noticias? Lo que ocurre simplemente es que estas herramientas han acercado el consumo de contenidos digitales al “gran público”, sólo eso. El usuario avanzado sigue prefiriendo la comodidad y versatilidad de un lector de feeds RSS, ya sea web o de escritorio. ¿O alguno de ustedes ha dejado de usar un lector de feeds para “pasarse” a Twitter como lector de noticias? Creo que muy pocos.

De hecho, es probable que muchos usuarios, al descubrir esta nueva forma de acceder a los contenidos, distinta de los medios tradicionales, hayan querido dar “un paso adelante” y hacer upgrade desde informarse vía Twitter, a agregar a un lector de feeds sus medios online favoritos.

Esto explicaría el explosivo aumento del uso de Google Reader que ocurre casi a la par con la popularización de Facebook/Twitter. No son sustitutos, sino que complementos. No se trata de usar uno y el otro. Cada uno cumple una función específica, con Google Reader recibimos contenidos, con Twitter iniciamos una conversación sobre estos.

El salto desde usar “Twitter para todo”, a ocupar un lector RSS especializado está dado por un aumento del tiempo que el usuario dedica a los medios online. Cuando este tiempo se reparte entre radio, televisión, diarios en papel, etc, solo quedan unos minutos al día para leer en la web.

En este escenario, es obvio que las redes sociales son un canal más conveniente para informarse, ya que funcionan más como la televisión o el diario: son un flujo constante de información que circula en cada momento, que podemos dejar semanas o incluso meses sin atender, para luego echar un vistazo solo a lo más reciente (del mismo modo como cuando volvemos de vacaciones la televisión no nos dice “tienes no-se-cuántos noticieros pendientes por ver”).

How RSS works

En tanto, Google Reader funciona más como el correo electrónico: nos suscribimos a los feeds que nos interesan y en cierto modo se nos obliga a seguirles el rastro, a enterarnos de todo lo que se publica. Existe una pequeña presión para permanecer al día con todo lo que sale.

Pero cuando el usuario va migrando desde los medios tradicionales hacia el contenido web, dispone más tiempo para recibir información online, y es natural que migre a una herramienta más especializada como Reader (que es lo que de hecho ocurre).

Además, Google ha sabido integrar en su lector las funciones sociales que tanto se le alaban a Twitter y Facebook, de forma tal que sean de utilidad para sus usuarios. Personalmente, muchas veces me ha pasado que cuando no tengo tiempo de ponerme al día con todas las suscripciones, simplemente me pongo a revisar lo que han compartido las personas a las que sigo, dejando que el criterio de ellos funcione como un auténtico filtro que separe lo que vale la pena leer de lo irrelevante.

También se nos permite comentar los posts e iniciar conversaciones en el mismo lector, y se nos sugieren feeds acordes a nuestros gustos. Incluso, Reader va más allá de lo que ofrecen las redes sociales tradicionales, y ofrece un algoritmo que ordena los artículos no por antigüedad, sino que por los temas que nos interesan.

Los lectores de feeds tampoco son perfectos: el problema de la “infoxicación”

Google Reader en móviles

Hay ciertos elementos que caracterizan a que caracterizan a Twitter y Facebook como fuentes de información y que han sido causantes de su fuerte aceptación entre la gente. Los lectores de feeds bien podrían aprender de esto e incorporar estos elementos, para así acercar más los agregadores RSS al “usuario de a pie”, pero sin perder las ventajas que ya poseen.

Como dije arriba, los lectores RSS tienden a esclavizarnos a “un estilo de vida” de sobreinformación. Esto puede ser aceptable para los “power users” y los llamados nativos digitales, pero no para el usuario común.

Por esto, sería espectacular si Google Reader y otro lectores agregan un “modo de lectura” ad-hoc para los lectores ocasionales. Que en vez de ofrecerse la opción de “marcar como leído lo que sea anterior a 48 horas”, se muestre como pendiente por leer sólo lo publicado en las últimas horas, sin que el usuario tenga usar la opción de “marcar como leído”.

Por supuesto, de implementarse esta función, tendría que estar desactivada por defecto, pero ser sugerida de forma automática a quienes ingresen a su cuenta de Google Reader cada 1 semana o menos. De ese modo, Reader se estaría adaptando a las necesidades de cada tipo de usuario.

El futuro de los blogs


Para ir cerrando este artículo, no niego que estamos presencia de la retirada de los blogs como fenómeno masivo donde todos publiquen contenidos, de la utopía de 1 blog por persona. Ahora existen formas mucho más efectivas de compartir y difundir información personal, ideas, comentarios, opiniones, etc.

Pero como medios de comunicación, los blogs todavía van en alza, y a un ritmo envidiable. Por ejemplo, la red de blogs Gawker ya ha superado en número de lectores a la mayoría de los diarios online de Estados Unidos, y por otras latitudes la tendencia es la misma. Y mientras haya blogs, habrá lectores RSS, ya que es la forma más efectiva y cómoda de acceder a los contenidos de estos.

Imágenes (Flickr) | Latte Blog, Google Reader Mobile, RSS flow

Con Places, Facebook por fin presenta su servicio de geolocalización

Con Places, Facebook por fin presenta su servicio de geolocalización: “

Facebook presenta Places, su servicio de geolocalización

Ya está. Se acabaron los rumores. Muchas sospechas se han cumplido y es que ya tenemos entre nosotros, aunque de forma limitada, Facebook Places, el nuevo sistema de geolocalización de la principal red social del mundo en el que la empresa llevaba trabajando los últimos ocho meses.

Hace unos días mi compañero Miguel ya escribió sobre el evento que Facebook tenía pensado realizar en el día de ayer. Y esta misma madrugada se han confirmado todos los rumores y por fin Facebook se ha decantado por la creación de un sistema basado en localización que viene a complementar, por ahora, los ya existentes como Gowalla, Foursquare o Yelp.

En la presentación de Facebook Places, Mark Zuckerberg dijo que este nuevo servicio tiene tres objetivos principales:

  • Ayudar a la gente a compartir su posición
  • Ayudar a los usuarios a ver quién está a su alrededor
  • Ayudar a los usuarios a ver qué está pasando ahora mismo y descubrir nuevos sitios
  • ¿Cómo funciona?

    El funcionamiento, a falta de probarlo, parece bastante sencillo. Una vez que estamos identificados en nuestra cuenta de Facebook y accediendo a través de un terminal móvil, pinchando en el botón de “Check in” accederemos a una lista de lugares que se encuentran a nuestro alrededor, basándose en la información de geolocalización proporcionada por nuestro teléfono. Si el lugar en el que estamos no se encuentra disponible, podemos agregarlo manualmente y que así sea visible después para todo el mundo.


    Cuando hacemos Check in, esta información será publicada en nuestro flujo de actualizaciones y será visible, por defecto, para todos nuestros amigos. Como ocurre con las fotos, si estamos en un lugar con más amigos que están registrados también en Facebook podremos etiquetarlos a ellos también. De esta forma, su perfil también será actualizado.

    Esto puede presentar, en principio, un problema de privacidad. Al parecer, la primera vez que un contacto nuestro en Facebook intente etiquetarnos junto a él en un check in concreto recibiremos una notificación de que se va a hacer eso. Si aceptamos, en siguientes ocasiones ya no será necesaria esta confirmación y podemos aparecer etiquetados en cualquier momento, aunque no estemos allí en ese preciso instante.

    Otra de las posibilidades es una pestaña denominada “People Here Now” que nos muestra qué otros usuarios de Facebook, amigos o no, están también en nuestra misma localización. Aunque también puede suponer esto un problema para aquellos que no quieren que su posición sea pública, parece que Facebook esta vez sí que ha estado atento en cuanto a las opciones de privacidad y cualquier usuario podrá decidir aparecer en tales listados o no, además de decidir si nuestros amigos pueden o no etiquetarnos también a nosotros.

    ¿Qué pasa ahora con servicios como Foursquare, Gowalla o Yelp?

    Muchos se preguntaban en los últimos días qué dirección iba a tomar Facebook con su nuevo servicio. Algunos pensaban que de hacerlo de forma adecuada, podría quitarse de en medio a competidores como Foursquare o Gowalla. Éstos, aunque tienen ventaja por llevar funcionando ya unos meses, difícilmente podrían hacer frente a los 500 millones de usuarios que tiene Facebook.


    Pero han decidido seguir una línea alternativa y estos servicios van a dejar de ser un competidor claro para pasar a formar parte de la estrategia de Facebook. Con el lanzamiento de Places, esta información geolocalizada también será puesta a disposición de programadores y desarrolladores a través de una API pública. Estos datos podrán ser utilizados por Foursquare, Gowalla o Yelp para permitir que los check-ins que realicemos en dichos servicios puedan aparecer también en la red social y que nuestros contactos puedan visualizarlos. Eso sí, esto es un calle con un solo carril, puesto que resultará imposible que los check-ins de Facebook aparezcan en nuestros perfiles en esas otras páginas.

    Restricciones geográficas y de uso

    Por ahora Places (o Lugares) sólo está disponible en Estados Unidos y más concretamente en la aplicación oficial para el iPhone o accediendo con nuestro móvil a través de la dirección Las intenciones de Facebook han sido claras y durante la presentación del servicio han confirmado que la expansión internacional se producirá “en las próximas semanas” pero no tenemos una fecha concreta.

    Por otro lado, también está previsto el lanzamiento de Places en las apps oficiales de Android y Blackberry, pero sobre ese tema sí que no existe por ahora ninguna fecha aproximada.

    Para empresas y negocios: Places + Pages

    Los usuarios de Facebook no son sólo gente común, sino que también podemos encontrar un número muy importante de negocios y empresas. Para éstas, Facebook ofrece la posibilidad de integrar la página en concreto de dicha empresa con su sección en Places.


    De esta forma, por ejemplo, un restaurante podrá ofrecer directamente en su página mucha más información. No sólo la elaborada por la misma empresa, sino también las opiniones de otros usuarios que están en el lugar en ese momento o han estado en el pasado. Esto supone una oportunidad muy interesante para muchas compañías para tener una representación virtual, en directo, de sus propios negocios físicos.

    ¿Dónde está Google Maps? Facebook se decanta por Bing Maps

    Esta ha sido una pequeña sorpresa. Yo, personalmente, no me esperaba que Facebook fuese a apostar por utilizar la tecnología de Bing y sus mapas. Pero parece que va a ser así, como confirman desde el propio blog de Bing. Esto puede suponer un incremento muy importante de la utilización de este y otros servicios del buscador de Microsoft, que además en las últimas fechas ha incrementado su cuota de mercado con respecto a otros competidores como Yahoo.

    Lo cierto es que Bing está trabajando mucho y muy bien con su producto, añadiendo nuevas características y proporcionando servicios que otras empresas están simulando poco a poco. Un público extra de cerca de 500 millones de usuarios nunca resultará una mala noticia.


    Antes de nada, estaremos atentos para avisar de cuándo Facebook Places vaya a estar disponible para el resto de países y en otros sistemas operativos además de iOS. Mientras tanto podremos ir viendo cómo evoluciona en las próximas semanas y qué nivel de adopción toma por parte de los usuarios. Muchos se pensaban que de un plumazo tomarían todo el terreno allanado por competidores como Gowalla o Foursquare, pero es de agradecer que vaya a existir algún tipo de integración entre todos estos servicios.

    Vía | Facebook Blog