La guerra por la supremacía en la web

En las últimas semanas nos han querido vender la idea de una guerra entre Apple y Google, que el blog Gigaom resume en una infografía bastante interesante o la rivalidad entre Microsoft y Google por dominar el mercado de los buscadores, que también ha llenado las líneas de innumerables posts. Son las batallas que la gran mayoría piensa definirán al nuevo rey del sector TIC. Es sin embargo la furiosa rivalidad entre Google y Facebook, la que durante los próximos años, según mi criterio, cambiará el panorama de las TIC de manera irreversible.

Microsoft, Apple, Intel, Nokia o Motorola, son todas corporaciones preparadas para luchar en un entorno industrial, donde la idea es producir en grandes volúmenes. Sin embargo grandes volúmenes de producción requieren grandes volúmenes de consumo, de no ser así el dinero invertido en la producción no puede ser recuperado. Un fenómeno externo al sector TIC como lo ha sido el credit crunch de finales del 2008, ha transformado la mentalidad y ahora menos significa más. El éxito en ventas de las netbooks y de las laptops de menos de $500 son una expresión de que el mercado se ha vuelto bastante sensible al precio. Es esa la razón por la cual el Nexus One, no se ha vendido tan bien como el iPhone o el Droid, básicamente porque a $530 cada unidad sin contrato, está muy lejos del bolsillo del consumidor promedio americano en estos momentos.

En este nuevo mundo de escaso crédito, donde la maximización del poder de compra de cada dólar es la regla para sobrevivir, computadoras con múltiples núcleos o inmensas pantallas, son el equivalente a los SUV. Representan una elevada inversión incial y un alto costo de operación, para satisfacer una elemental necesidad de transporte. Pero cuando se trata de reducir costos, los CIO están ahora también evaluando no sólo el costo de los PCs en los escritorios, sino también los software que estos utilizan. Ya se cuestiona la necesidad de procesadores de texto, debido al hecho de que la mayor cantidad de veces se utilizan para producir documentos que son atachados a correos electrónicos, esto debido a las políticas de ahorro en suministros como papel y tinta para impresora.

El que viene será un mundo diferente al que conocemos, un lugar donde la busqueda de la eficiencia en cada eslabón de la cadena será un requisito para sobrevir, por lo tanto y como consecuencia de lo anterior, la tercerización de servicios jugará un rol central en las estrategias de reducción de costos. ¿Por qué Google y Facebook iniciaran una batalla para determinar quien se quedará con un mercado así?

En los últimos días una serie de noticias han removido las bases de lo que pensábamos eran las redes sociales, primero fue Facebook que anunció que crearía un servicio de correo eletrónico, luego Google presentó Buzz, que añadía capacidades sociales a Gmail, a costa se crear mucha ansieadad en sus usuarios respecto a la privacidad. Casi inmediatamente Google activó Webfinger para sus cuentas de gmail, que también son las cuentas que tienen Buzz. Webfinger es un protocolo que permite usar direcciones de correo para acceder a nuestros perfiles y servir de identidades digitales.

¿Por qué todo lo anterior es importante?, la respuesta es sencilla, aquel que controle las identidades digitales en la web será el nuevo rey del sector. Es por ello que Facebook ha firmado un acuerdo con AOL para permitir que los usuarios de Facebook y del mensajero instantáneo de AOL puedan chatear juntos. Es por ello que que Google está decididamente apoyando oAuth. En un mundo en donde todo servicio relacionado a las TIC se accederá a través de la web y de forma pay-as-you-go (pre-pago), la importancia de una identidad única e interoperatividad entre servicios será el factor clave. Es decir el proceso de login en todo servicio ofrecido en la web se volverá un commodity.

Permitanme explicarles el problema con un ejemplo, supongan que Uds. que son el CIO de una gran empresa con miles de PCs, ¿por qué sería complicado una migración a Google Docs?, pues si se consigue o se programa la herramienta para mover toda la "legacy data" de manera automática al nuevo servicio o se contrata a alguien para que haga eso, no debería revestir mayores inconvenientes. Sin embargo el gran problema de ese tipo de migraciones es la administración de contraseñas (identidades) a dicha escala. El otro problema es que una vez dentro de la red de Google, sería también otra inversión millonaria moverse hacia otra alternativa, digamos Zoho, y el costo estaría también en la administración de las contraseñas (identidades). Por el contrario, si los sysadmin no tienen que lidiar con la administración de las contraseñas y sólo necesitaran saber los "usernames", que se convertirian en las identidades digitales de los usuarios, el trabajo se simplificaría enormemente.

Es por ello que tanto Facebook y Google, desean ser su única solución para su identidad en línea, ya que cotrolando el punto de validación en la web, pueden controlar todo el mercado de SaaS (Software as a Service). Sólo el servir de intermediario de micro-pago reportaría miles de millones de dólares anuales sin tener que asumir casi ningún riesgo. El premio es muy jugoso como para no tomarlo en serio y las únicas dos empresas, por el momento, que están tratando de conseguir el control de ese estratégico punto son Facebook y Google.

Usando el API de bit.ly con CodeIgniter

Como habrán notado soy un fanático de CodeIgniter, un framework ligero, fácil de aprender, seguro y flexible que permite el desarrollo rápido de aplicacione web usando PHP. Esa es la razón por la cual lo uso para implementar muchas de las ideas que expono a lo largo del presente blog.

Pero, la razón de éste mini-tutorial de cómo usar el API de bit.ly, que es un servicio de redución de URL, es justamente por que he visto que Mashable, ahora muestra un numerito sobre el botón para hacer buzz de sus posts. Estuve leyendo la documentación del API de Google Buzz, con la clara intención de duplicar dicha funcionalidad en mi blog y lamentablemente encontré que no es posible encontrar el número de "buzzeadas" que un determinado website ha recibido. Al menos por el momento esa información no es accesible a través del API de Buzz. Entonces, ¿cómo han resuelto el problema la gente de Mashable?, acaso tienen un trato secreto con Google para usar funciones no documentadas que sólo han sido reveladas a ellos, a cambio de buena prensa. Pues la respuesta es menos paranoica. y ciertamente más propensa a errores. Mashable no está contando el número de veces que un artículo ha sido compartido en buzz, sino el número de clicks sobre un link de bit.ly. Una solución simple, aunque de cuestionable eficacia.

Bueno, ahora que ya sabemos el por qué, veamos el cómo.

Para poder usar el API de bit.ly dentro de CodeIgniter debemos de descargar la librería bitly-api-library-codeigniter, que está alojada dentro de los repositorios de proyectos Open Source de Google. Adicionalmente debemos crear una cuenta en bit.ly ya que con ella podremos obtener un API Key, necesaria para usar el API.

Luego de que descompacte el archivo zip que contiene la librería Bitly.php, la debemos colocar en system/application/libraries/,  luego editamos el archivo system/application/config/autoload.php y denemos agregar esta línea:

$autoload[‘libraries’] = array(‘Bitly’);

Ahora ya podemos usar la librería en nuestra aplicación. Supongamos que el nombre de usuario que registró en bit.ly es "usuarioprueba"  y que la clave (key) del API que  obtiene de bit.ly es "R_0da49e0a9118ff35f52f629d2d71bf07", entonces un ejemplo muy sencillo para obtener la estadística de cuantos clicks ha recibido un terminado enlace sería el siguiente:

<?php

class Stat extends Controller {

        function Stat()
        {
                parent::Controller();
        }

        function index()
        {
                $this->bitly->setKey(‘usuarioprueba’,
                                     ‘R_0da49e0a9118ff35f52f629d2d71bf07’);
                $URL = "http://bit.ly/14H1OB";
                list($protocol, $empty, $bitly, $hash)=split("/", $URL);
                $result   = $this->bitly->stats($hash);
                echo "<PRE>";
                print_r($result);
                echo "</PRE>";
        }
}

?>

Observer que estoy usando la función split de PHP para poder obtener sólo la última parte del URL, que es la que necesita el API para retornarnos la estadística del número de clicks que ha recibido el enlace. El resultado de la ejecución exitosa del código anterior sería este:

Array
(
    [clicks] => 6
    [hash] => 3VpSVv
    [referrers] => Array
        (
            [] => Array
                (
                    [direct] => 6
                )

        )

    [userClicks] => 2
    [userHash] => 14H1OB
    [userReferrers] => Array
        (
            [] => Array
                (
                    [direct] => 1
                )

        )

)

Como podrán observar, el valor que nos interesaría para implementar el contador de buzz es "clicks". Sumando esto a lo que ya he comentado en el post  "Si Mashable puede, ¿por qué yo no?" y un poco de JavaScript sería posible hacer un widget como el que está usando actualmente Mashable.

Microsoft se ha vuelto irrelevante

Hace pocos días (4 de febrero) fue publicado en el The New York Times, un artíuclo de Dick Brass, en donde señalaba a la cultura de la destrucción de la creatividad al interior de Microsoft como la responsable de la lenta pero incuestionable caída del coloso de Redmond. Dicho artículo desató bastante ruido en la socialósfera (blogósfera, twitósfera, facebookosfera, etc.). Muchos bits han fluido a lo largo de estos últimos días, pero creo que la razón de la actual y notoria irrelavancia de Microsoft en el sector TIC, tiene su explicación en la aparición de un nuevo modelo de hacer negocios con las TIC y esto ha generado la emergencia de dos nuevas fuerzas dominantes en el sector Google y Facebook.

El mérito de Microsoft fue el de convertir lo intangible (el software) en un commodity, antes de Microsoft el software era producido bastante artesanalmente, los estándares eran una declaración de intención que muy pocos respetaban. Una prueba irrefutable de ello eran los Unix, que a pesar de en teoría todos provenir del mismo código fuente y seguían los mismos estándares algunos software eran específicamente programados para arquitecturas específicas.

En aquellos primeros años de la computación se hablaba de "arquitectura", pero en realidad era un eufemismo para hacer referencia a quien era el propietario de los derechos del hardware y el software, de aquel paradigma los dos únicos fósiles vivientes que existen actualmente son IBM con sus mainframes y Apple con su Mac. Con la introducción del IBM PC y su estándar abierto de hardware, la commoditización del hardware y el software comenzó.

Microsoft supo adaptarse a los tiempos, su mérito más importante fue permanecer como una empresa de software y no seguir el camino que siguió Apple. La idea de software como un commodity se extendió y fue abrazada por muchos, empresas como MicroPro, Borland, Corel, WordPerfect Corp., etc., florecieron en esos primeros años gracias a la aparición de un gran mercado para sus productos. Todas ellas son irrelevantes ahora, ¿por qué?

El gran cambio vino de la mano no del Open Source, sino de Internet. El tener acceso al código fuente es irrelevante sin la forma de compartirlo y mejorarlo en una comunidad bastante grande. Aquellos que usaron aquellas primeras versión de TurboPascal a principios de los ochentas, podrán recordar que el software venía con el código fuente de una rudimentaria hoja de cálculo. Sin embargo eso no generó un clon Open Source que amenazara la existencia de Lotus 123 o Quatro Pro.

Todos hablamos de las ventajas del paradigma Open Source ahora y hasta lunáticos como Richard Stallman quien convertir el Free Software en religión. Pero había una muy activa comunidad de lo que ahora llamamos Open Source a principios de los ochenta. La revista Byte como muchas otras también, incluía código fuente en BASIC o incluso Assambler para las primeras microcomputadoras de los ochenta.

Hay un mantra del Budismo Zen que dice: "¿Si un árbol cae en el bosque y nadie está lo suficientemente cerca para poder oirlo? ¿HACE RUIDO AL CAER?", es usado mucha veces para explicar fenómenos cuánticos, pero esta vez permitanme usarlo para explicar mi punto sobre el hecho de que es más importante la red de usuarios (networking) que el código. Pongamos el mantra en estos términos: Si alguien cambia el código de un programa, pero nadie más lo usa, es esa mejora buena o sólo es otra manera diferente de hacer las cosas. Sin los "usuarios" el paradigma Open Source no tendría viabilidad, pero ¿qué tantos usuarios?.

La famosa regla del 90-9-1 de Jakob Nielsen, nos dice que en toda comunidad de donde los usuarios generan el contenido existe una desigualdad implícita, ya que sólo 1% produce nuevo contenido, 9% proporciona un feedback o es participante activo y el 90% sólo consume de forma pasiva. Si llevamos esa regla al software veremos que se necesitan comunidades realmente grandes para que el paradigma Open Source pueda funcional, ya que no es lo mismo 1% de un salón de clases de Computer Science a 1% de los usuarios de Internet de todo el planeta. En conclusión, sin Internet no hubieramos tenido Linux, Apache, MySQL o PHP.

El factor Internet cambió las reglas de juego del antiguo paradigma del software como commodity, el primer cambio y más obvio fue el abaratamiento del software. Cuando algo se comoditiza, lo primero que ocurre es que la barrera de entrada de reduce y una gran cantidad de personas interesadas en hacer dinero entran al mercado. El incremento de la oferta inevitablemente lleva a la reducción del precio. El Open Source y las soluciones SaaS (Software as a Service) encajan en el reacomodo del modelo, pero no destruyen el modelo, sólo hacen que todos ganen menos, es decir lo degrada a través de una sobreexplotación de la demanda. En términos económicos es fácil ententer lo anterior, el número de nuevos usuarios crece más lentamente que la cantidad de oferta de nuevos productos, por lo tanto la única forma de atraer nuevos usuarios es reducir el precio, ya que no hay oferta más atractiva que gratis muchas nuevas compañías entran en la trampa del famoso freemium (servicio gratis a niver básico, y pagado para las características avanzadas).

Lamentablemente los ejecutivos de Microsoft no han entendido la naturaleza del cambio, por eso sólo siguen aquello que saben es el futuro, pero no entienden como funciona. Es por ello que produjeron XBox, Zune, CodePlex, Bing y ahora desean agregar fundionalidades de social networking a Outlook.

El problema con Microsoft no es que adentro de ella exista una cultura que promueva la destrucción de la creatividad y en consecuencia la innovación, es que todo el ecosistema ha cambiado, y en consecuencia su modelo de copiar al líder, ofrecer gratis o a muy bajo precio un producto equivalente para luego extender algunas funcionalidades haciendose incompatible y luego cerrar el mercado, ya no funciona más. Ese modelo parecido al de asimilación de los borgs alcanzó su cúspide con IE6 que llegó a dominar el 95% del marketshare.

Es como si un gran meteorito llamado social networking ha caído y alterado de manera irreversible el ecosistema en el cual gran Tiranosauro Microsoft goberno sin oposición por los últimos 10 años. El problema es que las redes sociales han cambiado el modelo por completo y es por eso que ahora las dos grandes fuerzas emergente son Facebook y Google. Cómo se desarrollará esta batalla y que implicaciones tendrá para nosotros los simples mortales lo dejaré para un próximo post.

Si Mashable puede, ¿por qué yo no?

El blog Mashable, que podríamos considerarlo la autoridad máxima en lo que a Web 2.0 se refiere ha incluído el botón  "buzz this" que permite compartir un post con nuestros followers de "Buzz". Ciertamente cuando lo vi me llamó la atención y me dije, qué rápido que programan los tíos de Mashable, ayer nomás salió el API de buzz y ya tienen un widget.

Decidí ver si podía robarme el código, pero oh! sorpresa, lo único que hicieron fue usar el google reader para postear el URL y de esa forma indirecta conseguir que el post sea presentado a nuestros followers. Me dije si ellos pueden, por qué yo no y como podrán ver ahora ya tenemos un botón "buzz this" .

UPDATE: Mi amigo @alexispardo me ha pasado un enlace a un post titulado "Como integrar Google Buzz en tu blog de WordPress" que detalla dos diferentes plugins de WordPress que permiten tener la misma funcionalidad que describí en este post.

Facebook presenta XHP (un PHP con esteriodes)

El día de ayer, mientras todo el mundo estaba discutiendo las aplicaciones presentes y futuras de Google Buzz, Facebook presentó XHP. Una de las razones por las que me dí cuenta de la existencia de XHP, fue gracias a que Google no ha habilitado aún Buzz en mi cuenta de Gmail. Lo cual en el fondo agradezco ya que de otro modo hubiera pasado por alto XHP.

¿Qué es XHP?, pues bien XHP es una extensión de PHP que valga la redundancia extiende la sintaxis del lenguaje para hacer la elaboración de front-end más fácil de leer y además incrementar la seguridad. Para conseguir dicho fin hace que PHP pueda entender XML de manera nativa.

La aplicación que Facebook le está dando a XHP es Facebook Lite, una versión mucho más ligera de la web de Facebook. Aunque su autor Marcel Laverdet, dice que es usado además para renderizar varias partes de la web de Facebook, ya que permite combinar porciones de código HTML en un simple nuevo objeto, con todas las ventajas que ello representa.

Pero veamos un ejemplo de cómo la sintaxis de PHP ha cambiado con XHP, usaremos el ejemplo que Facebook da:

<?php
if ($_POST[‘name’]) {
?>
    <span>Hello, <?=$_POST[‘name’]?>.</span>
<?php
} else {
?>
    <form method="post">
    What is your name?<br>
    <input type="text" name="name">
    <input type="submit">
    </form>
<?php
}

En el código anterior pueden presentarse dos problemas, el primero y más obvio es que seremos víctimas de XSS; el segundo problema es que si olvidamos abrir o cerrar los tag PHP, nustra página generaría un error. Con XHP ambos problemas se resuelven, aquí el mismo código anterior pero implementado con XHP:

<?php
// note: includes omitted
if ($_POST[‘name’]) {
  echo <span>Hello, {$_POST[‘name’]}</span>;
} else {
  echo
    <form method="post">
      What is your name?<br />
      <input type="text" name="name" />
      <input type="submit" />
    </form>;
}

Note que ahora todo es un simple block de código PHP, no hay que estar abriendo y cerrando tags PHP. Este cambio en la sintaxis del lenguaje trae consigo algunas ventajas:

  •  Debido a PHP es ahora context-specific, sabe que cuando la variable $_POST es invocada la entrada de datos será HTML y por lo tanto debe escapar los caracteres.
  •  Incorporar XML dentro de la sintaxis PHP permite detectar errores de con los marcadores (markup) en tiempo de parseo y no en tiempo de ejecución. Con lo que no podría existir una página web generada con scripts de XHP malformada.
  • Ya que XML ahora forma parte del lenguaje, en adición a su uso con "echo", también es posible asignarlos a una variable y manipularlos como un objeto cualquiera.
  • Adicionalmente XHP permite definir nuevos tags, con lo que complejas secciones de código HTML, pueden ser ahora definidas como un nuevo marcador, desempleñando de hecho el XHP el papel de un sistema de templates.

Debido a que todas estas ventajas me han interesado decidí probarlo y les dejo un pequeño tutorial de cómo intalar XHP en su server. Lo he probado con CodeIgniter y al parecer XHP no añade ninguna incompatiblidad que impida usarlo en un server donde ya tengamos código PHP. Aquí les dejo como instalar XHP en un server Debian Lenny (esto puede ser usado también para Ubuntu pero recordando usar el  "sudo").

Primero hay que asegurarnos que tenemos instaladas todas las herramientas para compilar XHP:

# apt-get install build-essential flex bisson php5-dev

Ahora descargamos las fuentes y descomprimimos el archivo:

# cd /tmp
# wget http://github.com/facebook/xhp/tarball/1.3.7
# cd /usr/src
# tar -zxvf facebook-xhp-290b185.tar.gz
# cd /usr/src/facebook-xhp-290b185

Ahora comenzamos el proceso de compilación:

# phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519

# ./configure
(…)
appending configuration tag "F77" to libtool
configure: creating ./config.status
config.status: creating config.h

# make
(…)
———————————————————————-
Libraries have been installed in:
   /usr/src/facebook-xhp-290b185/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR’
flag during linking and do at least one of the following:
   – add LIBDIR to the `LD_LIBRARY_PATH’ environment variable
     during execution
   – add LIBDIR to the `LD_RUN_PATH’ environment variable
     during linking
   – use the `-Wl,–rpath -Wl,LIBDIR’ linker flag
   – have your system administrator add LIBDIR to `/etc/ld.so.conf’

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
———————————————————————-

Build complete.
Don’t forget to run ‘make test’.

# make test
(…)

# make install
(…)

Los parentesis (…) indican que verán algunos mensajes, donde he sido específico es en donde muestro algún resultado útil para saber si vamos bien o no. Las líneas en azul son las que Ud. debe tipear (claro omitiendo el prompt ‘#’).

Luego debemos de agregar al archivo de configuración php.ini la línea "extension=xhp.so", en Debian hay dos archivos que modificar:

/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini

El primero es para agregar la extensión dentro del PHP incorporado como módulo de Apache y el segundo para hacer el cambio en PHP cuando se usa como CGI.

Más información sobre el proyecto, la nueva sitaxis que se ha agregado y como resolver algunos errores comunes, pueden encontrarse en la wiki de XHP.