Ésta  es una serie sobre el revenue detrás del concepto conocido como Web 2.0. En la intro analizamos los por qués/para qués de buscar plata en esta nueva web. En la parte 1 revisamos como el efecto red ha mejorado la calidad y precisión de aplicaciones basadas en la participación de los usuarios. En esta misma parte comentamos cómo los datos que exponemos no sólo en cantidad sino adecuada y oportunamente al usuario que los pueda estar necesitando, aumenta la confiabilidad en nuestra aplicación y ayuda a provocar el efecto red que, virtuosamente, va a mejorar nuevamente la calidad de los datos

En esta ocasión vamos a revisar mecanismos que permiten a terceros agregarnos a sus cadenas de valor si nosotros antes disponemos partes de nuestra aplicación a modo de ganchos (hooks), partes concretas, tanto funcionales como a nivel de datos

APIs para Re-Usar

Por ejemplo, de nuevo estos "buenudos" de Amazon, ofrecen una serie de servicios web (basados tanto en estándares WS-* como en REST, la simplista alternativa a WS-* -ya vamos a hablar luego de REST-) de modo tal que desde una aplicación tuya puedas exponer servicios de Amazon (búsqueda de catálogo, carrito de compras, ver imágenes de productos, comentarios de compradores, etc) agregando todo el valor que eso significa!! Lógico, los de Amazon ganan también porque se les abre la puerta a vender, pero vos ganás porque más gente podría querer usar tu aplicación ya que les gusta cómo vos clasificás y exponés la información, pero además eventualmente ofrecés la chance de comprar aquello que estás mostrando
Suena tirado de los pelos esto que te digo? A los de Image Database (IMDb) no, fijate. Y son la base de datos en línea del Séptimo Arte más visitada (por algo será, no?)

Enterprise 2.0 en acción: a esta base de datos no la llena un comité de ilustres cinéfilos sino
que vos, yo, cualquiera puede editar los contenidos. Es decir, el sitio es de comunidad y sin
embargo el que quiere saber de un actor o de una peli entra acá a buscar. Y si quiere adquirirla
(ver al costado derecho) Amazon ofrece vendertela ipso facto

Comercialmente hablando todo puede ser. Por ejemplo, en el caso de Amazon, su servicio de e-Commerce no tiene costo (es inversión pura por cuanto les da la chance de usar tu aplicación como sucursal) en tanto que otros servicios de esta gente sí se pueden usar pagando un fee (tasa)

Google, a través de su servicio AdSense descubrió un modelo comercial mejor: usales su aplicación y ganá plata por hacerlo. Te ofrece una API gratuita (un bloque de código HTML) que lo incluís en tu página y despliega avisos basados en un contexto que le indiques (presuntamente relevante a la página que estás mostrando)

"Google Ads" te ayuda a mostrar avisos en el contexto de la noticia que estás leyendo (ver rojo) o
al menos de la sección del diario que estás revisando (ver azul), asumiendo que un lector que se
interese en estas noticias, probablemente tenga mayor interés en esos anuncios que alguien que
lee el diario para saber los resultados de la NBA o de Roland Garros

Si alguien que visitó tu página hace click en el aviso... vos cobrás compre o no!! Google le cobra al anunciante (mediante un acuerdo entre ellos conocido como Google AdWords) y te paga a vos una comisión según lo estipulado en Google AdSense. En el ejemplo que te voy a mostrar, el que está aprovechando esa posibilidad es ni más ni menos que el matutino de mayor tirada de la Argentina: el diario Clarin. Alguna vez te preguntaste cómo van a sobrevivir los diarios cuando todo el mundo tenga Internet y nadie compre el diario de papel? Fijate acá cómo están sobreviviendo hoy  (y en verdad, gozando de muy buena salud!)

Suplemento "Viajes" del diario argentino Clarin: con diferentes tonos te muestro
cómo las ofertas de la derecha se relacionan directa o algo más vagamente con
las regiones a las que aluden las diversas notas (estancias bonaerenses, cordillera
andina o viajes en general)

Todas estas movidas, nuevos modelos comerciales, tendencias, etc, como siempre pasa en estos casos, obligan a un barajar y dar de nuevo. Porque a muchos "ganadores" de la vieja guardia si no evolucionan los van a pasar como a gordo en maratón. Justamente Microsoft (alguna vez opositor de los estándares abiertos y hoy, en cambio, uno de sus más fervientes adherentes), conciente de esto, hace un tiempo que viene lanzando una serie de servicios gratuitos, conocidos como Windows Live. Te invito a que te pegues una vuelta porque creo que te va a sorprender la capacidad de innovación y de re-creación de una compañía que hasta hace poco se venía basando en software cerrado (lo que en su momento le valió varios juicios por monopolio más un rechazo generalizado tanto en la comunidad de desarrolladores como de consumidores)

Por ejemplo, este post lo estás leyendo en Windows Live Spaces, y a su vez yo lo escribí usando Windows Live Writer (aún en versión beta)

Windows Live Writer: la trastienda de ZonaDiegum

Acá viene, entonces, la parte que te pueda interesar: si sos desarrollador de software o de sitios web, Microsoft te da la posibilidad de que añadas valor a tus aplicaciones con el Windows Live SDK. Por ejemplo, este artículo te cuenta cómo, mediante la inclusión de un archivo JavaScript en ciertas páginas de tu aplicación, podés consumir el servicio de búsquedas de Windows Live Search (el "google" de Microsoft). Para más información, novedades y ejemplos acerca de desarrollo basado en Windows Live, visitá el portal en MSDN

Y en lo que a vos y a tu organización respecta? Cómo podés copiar estos modelos para que otros usen tu aplicación desde las de ellos? Primero que nada, negocios son negocios. Quiero decir, no vayas a pretender que usen servicios de tu aplicación sólo porque se los expusistes. Les tiene que aportar realmente algún valor, sea porque se van a ahorrar costos, sea porque incluso puedan llegar a ganar algún ingreso. Del mismo modo, en lo que a vos respecta: no expongas servicios sólo por contar después que lo hiciste. Si tu aplicación se sostiene en una arquitectura de la participación que hace que sus resultados mejoren en la medida en que es usada, exponé justamente esos servicios que al ser usados maduren su calidad. Finalmente, acá sin dudas aplica lo que te expuse en el Boletín Extraoficial de Arquitectura #2, en aquella sesión de Krzysztof (alias "El Pocho") Cwalina: querés hacer un framework o API altamente re-usable? Diseñá entonces algo sencillo de entender, de asimilar. Es típico de varios arquitectos hacer diseños oscurantistas, por así decir, barrocos, creyendo que así los van a respetar mejor. Es posible que los respeten, sí. Pero vos diseñá algo que de tan simple y a la vez potente, lo termine usando y recomendando todo el mundo. Y cuando eso pase y sepan que fuiste vos el creador de eso que todos usan y recomiendan, quiero ver quién te va a faltar el respeto

Datos for Export

Otra forma por demás sencilla de dejar cosas para que te las choréen y en el mismo acto te beneficien no pasa por dejar funcionalidades disponibles sino datos (nuevamente: LOS DATOS MANDAN!!)
Han surgido una serie de protocolos de datos que se han adoptado en forma asombrosa. Dejar tu info en cualquiera de estos protocolos (algunos son un "must" pero si podés incluir otros vas a ganar en alcance) hará que tu info pase a estar disponible desde lugares inimaginables. Te hablo de

• Formatos para Suscribir: RSS y ATOM. Ambos son gramáticas XML que provéen información en forma de digesto. Es decir, similar al ejemplo que te ponía de Google que sólo expone fragmentos de la info pero fundamentalmente un vínculo (link) para que accedas a la misma en forma directa y ya sin Google como intermediario. Eso mismo procuran los formatos suscribibles (o "sindicables" para castellanizar la voz inglesa de "syndication"). Particularmente a RSS me había referido allá por Marzo (un screencast integral que te propongo que revises para no yo repetir todo acá). ATOM, según sus promotores, es más potente que RSS y supuestamente lo reemplazaría. Ahora, aún siendo verdad que es más potente -cosa harto probable- yo no sé si realmente lo reemplazará como tampoco ocurrió que el estándar para definición de gramáticas "XML Schema" (o XSD), claramente más potente que su antecesor "Document Type Definition"  (o DTD), no lo reemplazó debido a su mayor complejidad (a menudo innecesaria). Otro ejemplo donde el "más potente Goliat" no pudo con "el modesto pero suficientemente bueno David" tenés en el lenguaje BASIC respecto de C++, SmallTalk, incluso Java y C#. La clave del éxito, como te decía antes respecto de diseñar tu API re-usable, es que sea lo suficientemente simple de entender y lo suficientemente potente de aprovechar
  Un ejemplo posta de "RSS to go" (RSS para llevar) lo tenés en el portal de Arquitectura MSDN. Ese portal divide el espacio de la "Arquitectura de Software" en varios tópicos, y consiguientemente organiza sus páginas a razón de un tópico por sección (entendamos por sección un conjunto de páginas relacionadas)

  
  El sitio de arquitectura de Microsoft tiene una página donde se despliegan las 100 últimas novedades,
  las cuales en realidad están en un archivo RSS que puede ser suscripto desde cualquier lector RSS
  Justamente en la imagen se ve, solapado con el browser, un gadget de Windows Vista capaz
  de parsear y desplegar contenidos RSS. En este caso, claro, mostrando el mismo RSS del portal

  Ahora, cómo hacer para que la data que publicás en formato suscribible sea realmente "robada" por otros y, más importante aún, cuando ellos la expongan, invite a sus visitantes a consumirla (y, por ende, beneficiarte)? Acá está el secreto de viejo lobo de mar (aunque un auténtico mago no debería explicar los secretos): por empezar, reuní y publicá info que realmente le agregue valor al suscriptor, sea para consumo personal o para re-exposición desde su portal y aplicación, lo que tiene un efecto amplificador
  Ahora, lógico, puede pasar que otros se interesen en suscribirse a tus novedades y re-exponerlas, pero que después nadie se interese en hacer click en ninguno de los ítems por lo que el valor real de la información que vos ofrecés pasa desapercibido (por ejemplo, si querés contar cuánta gente miró cada pieza de contenido de tus páginas, el resultado puede ser muy exíguo)
  Cómo lograr que realmente se sientan interesados a entrar concreta y definitivamente a tu contenido, más allá de tus catálogos? La onda pasa por proveer un título y una descripción lo suficientemente largo como para que no dejé dudas de lo que se puede esperar encontrar si se sigue el vínculo a la pieza; pero lo suficientemente corto -este equilibrio es lo más difícil- como para que deje con ganas de más, de entrar de una vez y sacarse la duda
  Sabías que toda, absolutamente toda la información del sitio de Arquitectura MSDN es suscribible? Si no lo sabías es culpa mía de no comunicarlo bien. Es decir, vos te podés suscribir al flujo general, que permanentemente muestra las últimas cien novedades (según el componente suscriptor de este flujo que uses, vos podés no perder los previos "últimos cien" a medida que van dejando de serlo, ya que la mayoría de los componentes suscriptores son acumulativos: manejan su propia base de datos interna de manera que vos no pierdas la historia)
  De este modo vos podés suscribirte parcialmente a las novedades, por ejemplo

  • Todo el sitio: http://msdn.microsoft.com/architecture/rssArc.xml
  • SaaS (pero solamente artículos): http://msdn.microsoft.com/architecture/saas/rssArticles.xml
  • SOA (pero solamente videos, no artículos): http://msdn.microsoft.com/architecture/soa/rssMultimedia.xml
  • Modelado (pero solamente tools para descargar): http://msdn.microsoft.com/architecture/solutions_architecture/modeling/rssDownloads.xml
• Suscripciones Agregadas: OPML (Outline Processor Markup Language). Es una vuelta de tuerca más de lo anterior, permitiendo suscribir simultáneamente a varias fuentes de datos, consolidando (aggregation) toda la data en un único flujo (el que a su vez se puede exponer como RSS, ATOM y otro formato para ser nuevamente reusado!! )
  Te la dejo a vos para que te maquines cosas que podrías hacer con esto. Sólo si no se te ocurre un soto te muestro lo que hacemos nosotros con los bloggers sobre Desarrollo Ágil en el equipo de Arquitectura de Microsoft

  
  Así es por dentro el OPML de los bloggers de Desarrollo Ágil de Microsoft. Un encabezado con
  info básica y un cuerpo donde cada <outline> apunta, mediante su atributo xmlUrl, a un RSS

  
  Así se ve el OPML anterior una vez que un lector de OPML lo parsea, accede a los RSS que
  están contenidos, los consolida, ordena por fecha, y finalmente transforma todo a un mega
  RSS

  
  Voila! La columna de la izquierda muestra formateadas las entradas del RSS resultante de
  leer el OPML anterior
  

• Formatos para Programar el Browser: JSON (JavaScript Object Notation). El formato anterior es súper piola si lo van a consumir personas (digo, revisarlo visualmente es entendible) o componentes suscriptores como los ejemplos de readers (lectores) que te mostré antes
  En cambio si necesitás trabajar la info desde el código JavaScript de tus páginas, quizás te venga más a mano un formato que los intérpretes JavaScript son capaces de procesar en forma masiva (ché, a todo esto, JavaScript es el lenguaje de programación de facto de los navegadores, just in case que no lo supieras)
  Aca te muestro un ejemplito posta de JSON
  
  {
        "Grupo": {
           "Nombre": "The Cure",
           "CreadoEn": 1976,
           "Origen": "Inglaterra",
           "Lider": "Robert Smith",
           "Sitio": "http://www.thecure.com",
           "Imagen": {   // los brakets engloban las propiedades de un objeto
              "Url": "http://www.mcarecords.com/MCAImageUpload/1547685-Full.jpg",
              "Height": 164,
              "Width": 275
           },
           "Discografia": [   // las llaves engloban los elementos de un Array
              "Three Imaginary Boys (1979)",
              "Seventeen Seconds (1980)",
              "Faith (1981)",
              "Pornography (1982)",
              "The Top (1984)",
              "The Head on the Door (1985)",
              "Kiss Me, Kiss Me, Kiss Me (1987)",
              "Disintegration (1989)",
              "Wish (1992)",
              "Wild Mood Swings (1996)",
              "Bloodflowers (2000)",
              "The Cure (2004)"]
        }
  }
  
  A partir de acá podrías acceder en forma programática a los componentes del objeto siguiendo la idea que te muestro a continuación
  
        // bandaStr es una variable string que contiene lo de mas arriba
        var banda = eval('(' + bandaStr + ')');
        // segundoAlbum pasa a contener "Seventeen Seconds (1980)"
        var segundoAlbum = banda.Grupo.Discografia[1];
  
  La clave de preferir JSON en este caso sobre RSS u otros te la da el hecho de que en JavaScript tenés disponible el comando eval(<expresion>) que llama al intérprete JavaScript y te hace la transformación entre el string y la jerarquía de objetos. Lograr lo mismo con un formato basado en XML implicaría usar alguna biblioteca de parsing (que de hecho las hay, ya voy a hablar más adelante cuando cubra REST)
  Ambas alternativas son posibles y, ojo, ambas son lentas en ejecución pero al menos la de JSON es más rápida que la otra en tanto está incorporada (built-in) en el interprete
  Uses la que uses, lo súper piola de JavaScript es que permite acceder a partes del documento HTML en forma programática (gracias a la API DOM -por Document Object Model-, soportada ampliamente en las distintas versiones de JavaScript), y así modificarlo

  
  Una vez armada la jerarquía de objetos en JavaScript, producir HTML de ello es un trámite
   

• Servicios Web: WS-*. El formato anterior es súper útil en su contexto: un interprete JavaScript. Ahora, y el resto del mundo qué? El resto del mundo tiene -hoy ya se puede decir- un formato de mensajería que va terminando de completarse y ofrece una robustez inigualable (seguridad, identificación, encriptación, mensajería confiable, contextos transaccionales, etc)
  Está también basado en XML y es el estándar de facto si tenés que hacer hablar procesos, digamos, Java EE y .NET (o cualquier otro! Incluso JavaScript: esperá que te cuente de AJAX, ya llego -paciencia-)
  Como te digo, la especificación de servicios es todo lo robusta que necesites (aún está evolucionando, ojo, no está ya-ya todo disponible pero se supone que va a estarlo en el mediano plazo)
  Pero para casos simples -digamos, internos a tu organización, que no requieren privacidad por ejemplo- podés usar el perfil básico de estos servicios web, consistentes en unos pocos protocolos ampliamente disponibles
  -WSDL (Web Service Description Language): que se usa para describir el contrato del servicio. Es decir, qué datos recibe, qué datos devuelve más algunas que otras políticas de uso del servicio -que el framework de ejecución de servicios web deberá verificar que estén siendo cumplidas en cada invocación
  -SOAP (Simple Object Access Protocol): este formato es la gramática de una invocación a un servicio web, o su respuesta. Es decir, no está repitiendo el formato anterior: el anterior describe los tipos y las políticas de la mensajería hacia y desde el servicio web. En cambio SOAP es el mensaje en sí (como en la facu, los parámetros formales y actuales de un método. Formal es "pepe es int" y actual es "en la invocación, pepe vale 5". Ok, "pepe es int" se declara en WSDL" en tanto que "pepe vale 5" se dice en SOAP
  -HTTP y otros: los servicios web se llaman "web" y no "servicios" a secas porque al principio usaban protocolos de la web para transporte (HTTP), mensajería (XML), etc. Hoy eso ya no es mandatorio y es común transportar los servicios web directamente en la capa de abajo de HTTP: TCP. Además más allá de que SOAP presenta la ventaja de que puede ser entendido tanto por procesos como por personas, es muy charlatán (verbose) y consume mucho ancho de banda. Para lidiar con eso se agregó Infoset a WS-*, que sigue siendo basado en XML pero optimiza tags y otra información que a la postre pesaban
  Por esto mismo, se convirtió en una best practice que si tenés que hacer hablar Java con Java o .NET con .NET, quizás es preferente usar formatos nativos como Java RMI (Remod Method Invocation) o .NET Remoting. En este último caso, la API Windows Communication Foundation (WCF) te va a permitir abstraerte del formato de transporte usado por debajo, para que si fuiste por .NET Remoting y te arrepentiste o cambiaron las circunstancias, puedas hacer el switch a servicios Web sin impacto en el código
• REST (REpresentational State Transfer). Es la venganza del XML puro (a veces llamado Plain Old XML o POX) contra JSON y WS-*. Velo como el XML más simple que te quieras imaginar (por ejemplo, volviendo al caso que vimos en JSON)
  
  <grupo>
      <nombre>The Cure</nombre>
      <creadoEn>1976</creadoEn>
      <origen>Inglaterra</origen>
      <lider>Robert Smith</lider>
      <sitio>http://www.thecure.com</sitio>
      <imagen>
          <url>http://www.mcarecords.com/MCAImageUpload/1547685-Full.jpg</url>
          <height>164</height>
          <width>275</width>
      </imagen>
      <discografia>
          <disco>Three Imaginary Boys (1979)</disco>
          <disco>Seventeen Seconds (1980)</disco>
          <disco>Faith (1981)</disco>
          <disco>Pornography (1982)</disco>
          <disco>The Top (1984)</disco>
          <disco>The Head on the Door (1985)</disco>
          <disco>Kiss Me, Kiss Me, Kiss Me (1987)</disco>
          <disco>Disintegration (1989)</disco>
          <disco>Wish (1992)</disco>
          <disco>Wild Mood Swings (1996)</disco>
          <disco>Bloodflowers (2000)</disco>
          <disco>The Cure (2004)</disco>
      </discografia>
  </grupo>
  
  Creo que no hace falta decirte que para parsear XML tenés APIs disponibles por todos lados. Java y .NET lo traen en forma nativa. En el caso de JavaScript hay quichicientas disponibles también (echale, por ejemplo, un vistazo a JKL.ParseXML)
  Las contras de XML, como comentaba antes, son la verbosidad que puede afectar el rendimiento por el mayor consumo de ancho de banda. Afortunadamente hoy ese problema está abordado con frameworks que, mientras que en tu entorno de desarrollo y para propósitos de debugging, te permiten ver el XML en la forma entendible del ejemplo más arriba, para la ejecución te convierten el stream en un formato más reducido (y también menos entendible por vos, claro, no así por el proceso que le va a dar lo mismo si el tag se llamaba <origen> o simplemente <o>)
• Formatos Gráficos: SVG (Scalable Vector Graphic). Si lo que necesitás es transmitir dibujos (un torta estadística, un gráfico de barras o a Súper Mario Bros), este formato viene siendo de a poco soportado por más y más aplicaciones. Tiene una gran virtud por sobre los bitmaps que es, como su nombre expresa, que escala. Es decir, agrandás el dibujo y no se ven los pixels, lo reducís y no se pierde nitidez

  
  La revancha del ICQ: de ser una aplicación de escritorio, instalable, ICQ probó luego ser un
  applet Java pero finalmente se quedó en su versión vectorial (basada en Flash) y disponible
  en http://go.icq.com

Podría mencionar acá también a los Gadgets y los Mashups, pero en tanto la componente visual es realmente tan notoria, voy a cubrirlos en mayor detalle en Que No Se Retove el Usuario (próximo post de la serie). Pero sin duda que completan la idea global de este post

Para cerrar el post, algo a tener muy en cuenta cuando tomamos pedazos de otro para nuestra aplicación, directamente de su sitio, es que nuestro "socio" podría no estar disponible justo en el momento en que lo estamos queriendo acceder. Esto en términos de "Web 2.0" es "oh, qué garrón, yo quería entrar ahora". En cambio en términos de "Enterprise 2.0"... no, olvidalo: en "Enterprise 2.0" no podés darte ese lujo porque la experiencia de usuario cuenta mucho, y además tu competencia está a unos pocos clicks de distancia del frustrado usuario como para que tu oportunidad se le vaya a él (el usuario quizás ni se percate de que no sos vos el que anda con problemas porque sencillamente ni se haya enterado que estás usando piezas de terceros)

Para afrontar esto, ya son varios los proveedores de partes re-usables que ofrecen planes premium atados a un acuerdo de nivel de servicio (Service-Level Agreement o SLA). Claro que, en ese caso... poniendo estaba la ganza: hay que pagar

Nos volvemos a encontrar para proseguir con esta serie

• Introducción
• Más se Usa, Más Nuevo Queda
• Elogio del Choreo
• Que No se Retove el Usuario
• Siempre "Casi Listo"
• Los Últimos Serán los Primeros

 En  la pasada introduccion te conté qué era en economía el efecto red y te hablé de cinco factores que la web inherentemente proveía, que la convertían en un ambiente apropiado para generar comunidades que se fortalezcan por el efecto red (y que en el mismo acto generen dividendos)

Estos factores eran

• Base de clientes de alcance global (y en expansión)
• Internet disponible cada vez en más lugares (geográficos y a nivel de dispositivos)
• Valor agregado de lo que los usuarios producen
• Abaratamiento de costos que va a motivar a que la población digital se siga expandiendo
• Nuevas formas (digitales) de vender

Los mismos han dado lugar a una serie de tendencias, al principio difusas, hoy bastante más claras, a las que me voy a referir en el resto de la serie (en este post voy a destacar a dos de ellas)

Aprovechamiento de la Inteligencia Colectiva

Cuando Google apareció, allá por 1998, ya habían otros buscadores establecidos como estándares "de facto". Google surgía apenas como la iniciativa de dos nerds por las que cualquiera hubiera creído que iban a intentarlo un tiempo y hoy estarían ya separados. En cambio, la empresa que fundaron y que aún no tiene una década de vida es actualmente la empresa de tecnología mejor cotizada y estos muchachos (más los accionistas mayoritarios de Google) acaudalados individuos. En qué se origina tanto éxito? El buscador de Google supo capitalizar la inteligencia colectiva. A ver: en cualquier buscador podíamos poner un string de búsqueda como "dependency injection" por ejemplo. Qué ofrecía de especial Google que en aquel entonces no era ofrecido por sus rivales? Google llevaba la cuenta de cuántas veces las páginas enlistadas eran visitadas por los usuarios luego de haber puesto un determinado patrón. De manera tal que las rankeaba y si una página que aparecía en el centésimo lugar de una búsqueda era clickeada más veces que las que salían del primero al décimo -por poner un ejemplo-, la siguiente vez que ese patrón sea buscado, Google mostraba el elemento más accedido antes

De izquierda a derecha, Larry Page (cofundador y Presidente del Área
de Productos), Eric Schmidt (CEO) y Sergey Brin (cofundador y
Presidente del Área de Tecnología)
 

Esto, por supuesto, fue haciendo de Google un buscador súper confiable que, por si fuera poco, se superaba a sí mismo a medida que era usado!! En resumidas cuentas, Google se basaba en una Arquitectura de Participación donde los usuarios agregaban valor y el "efecto red" (que te mencionaba en la intro) lo magnificaba

El diario argentino Clarin, como varios otros medios, destaca los temas más leídos por
los cibernautas poniendo dichos tópicos en tamaño de letra mayor y posiblemente
destacados en rojo

Esta cualidad fue inmediatamente adoptada no sólo por los restantes buscadores sino también por aplicaciones de retail virtual como Amazon. No sé si alguna vez compraste un CD o un libro por Amazon pero Amazon te ofrece algo realmente tentador: basándose en registros de otros compradores del ítem que estás por llevar (manteniendo siempre la confidencialidad) te destaca aquellos cinco ítems más repetidos por los compradores anteriores (no necesariamente en la misma compra, claro). Es decir, trata de inferir gustos, patrones de conducta para facilitarle futuras búsquedas al cliente (y vender más, lógico! Dijimos Enterprise 2.0, no?). De nuevo, en la medida en que más gente use Amazon, esa característica va a ofrecer resultados más precisos

Los de Amazon me encontraron el punto débil
Les empecé comprando Ringu (un clásico ponja del terror)
Hoy tengo más DVDs ponjas de terror yo que Amazon!!

Ejemplos similares podés encontrar en MercadoLibre, eBay, etc. Qué sería de estos portales si los usara poca gente!!?? Serían como esos videoclubes de barrio, no? Donde no vas con la idea de lo que querés ver porque seguro que no está. Al contrario, vas con la idea de elegir algo de lo que hay disponible. Entonces

1. Si querés vos también aprovechar los beneficios de Web 2.0 para tu organización, acá tenés una best practice que vienen aplicando los líderes de esta movida, consistente en basar tu aplicación en la participación de los usuarios, de manera que cuanto más uso hagan de la misma, mejor la calidad de los resultados
2. Referido al punto anterior: un problema común es el problema del arranque en frío (cold start). Al estrenar la aplicación, todavía nadie la usó, por ende la calidad de los resultados podría llegar a ser paupérrima y eso desanimar a los primeros usuarios, quienes silenciosamente se rehusarían a ser conejillos de indias, reciclando así un círculo vicioso que podría hacer fracasar el proyecto. El workaround que varios han encontrado es lanzar la aplicación en un primer estadío en forma privada, de manera de blanquear el arranque en frío para atenuar la frustración en la misma medida en que lo hacen las versiones beta del software instalable

Los Datos Mandan

Supongamos que tomás al azar dos alumnos de 9 años de edad de la escuela primaria y los hacés pasar al pizarrón. Supongamos entonces, que uno demuestra saber de memoria las tablas de multiplicar, pero es incapaz de imaginarse cuánto demorará un albañil en levantar un muro de un metro y medio de alto (150 cm) si para ello debe apilar 30 hileras de ladrillos de 5 cm de alto y cada hilera le toma 7 minutos. El otro alumno, en cambio, te responde acertadamente que el albañil demorará 30x7 minutos (independientemente de todos los otros datos que le diste), no obstante no es capaz de calcular el resultado de ese producto, así como demuestra no saber practicamente otra tabla de multiplicar que la del 0 y del 1
Cuál de los dos te parece que es más inteligente? El que sabe las tablas de memoria pero no razona o el que es puro razonamiento pero no se acuerda algo tan básico como las tablas? Bueno, Einstein solía decir "no acostumbro atiborrar mi cabeza con cosas que puedo encontrar en cualquier libro", que aggiornado a hoy podría ser "no acostumbro atiborrar mi cabeza con cosas que puedo averiguar con una calculadora o navegando en internet"
Ésa parece ser la clave hoy: al principio te comentaba que el Messenger desplazó al ICQ porque ofrecía más funcionalidades. Pero a igual o medianamente similar funcionalidad, se impondrá aquel que organice mejor los datos -como le hizo Google a Altavista y a Yahoo-, permitiendote en seguida detectar dónde están los elefantes y dónde las hormigas en el cuadro total
Los emprendedores del proyecto Pandora entendieron esto en seguida y te ofrecen crearte una radio a la medida de la música que a vos te gusta. Sólo basta que le pases algunos temas o grupos preferidos, y de allí te arman una programación con temas y grupos similares. Acaso no te pasa seguido que, la radio que escuchás porque presuntamente pasan la música que te gusta, a menudo pasan música que quizás no te gusta tanto, o se la pasan hablando los conductores, etc? Estos tipos, en cambio, perfilan tus gustos y te ofrecen un mecanismo por el cual no va a ser común que te ensartés. Probá Pandora y decime si la radio convencional ofrece una experiencia tan personal (mientras escribo esto estoy escuchando una "estación" que se me creó en base al tema Una Noche Como Ésta -A Night Like This- de The Cure en 1985,  nada más inspirador: si este post no te gusta echale la culpa a Robert Smith)

Pandora Internet Radio: metí una de "The Cure" y me soltó
una tira de temas de grupos que al escucharlos presentaban
reminiscencias al tema y/o a The Cure en general. Mientras
yo no me baje, ellos siguen tirando temas del estilo

Los datos mandan. Sin dudas. Pero mandan aún mucho más si se sabe que la fuente de los mismos no es una corporación de anónimos accionistas motivados por quién sabrá qué interés lucrativo, sino el público en general (vos, yo, tu prima, mi hermá... Noooooo! Cuidadito! Con la nena no). Por ejemplo, actualmente Wikipedia está siendo usado por varios sitios especializados (me refiero a que su contenido no es generado por una comunidad sino por un board editorial) como referencia autorizada (siendo que cualquiera de nosotros puede editar el contenido)

IBM publicó un paper re grosso y puso, como referencias,
a tipos más grossos citando nombre, paper o libro, editorial
y año de publicación. En cambio, en el medio, tiró un link a
Wikipedia made in Lanús Este y pasó piola entre
las referencias posta (nadie preguntó quién lo escribió,
quién lo revisó, quién aprobó la publicación, etc; lo que
da la pauta de que Wikipedia como fuente es incuestionable)

A este fenómeno de contenidos generados por la ciudadanía se lo está estudiando sociológicamente, intentando responder a dudas tales como "por qué genera credibilidad inmediata" dadas las implicancias fraudulentas que -en el peor caso- podría tener. Te invito a que leas esta nota aparecida en el matutino La Nación acerca de este fenómeno: http://www.lanacion.com.ar/903371

El diario argentino "La Nación" publica una noticia generada
por sus propios periodistas, pero a la vez ofrece ver videos
de multimedios competidores ("Crónica" y "Todo Noticias")
y como si eso fuera poco, invita a los lectores a que hayan
estado por allí a que ellos también manden videos

Mejor experiencia en la web que en el papel. El diario chileno
"Las Últimas Noticias" ofrece en la web una réplica de la página
de la versión impresa, pero la enriquece por un video que un
traseúnte ocasional registro con un teléfono móvil

Pero volvamos a la oficina. A la Enterprise 2.0. Cómo capitalizar, convertir en fuente de ingresos, esa información potencial que la comunidad de internautas es capaz de generar? Amazon, nuevamente, parece haberle encontrado la vuelta a esto, habilitando que sus visitantes califiquen (hayan o no comprado allí) los productos que este retail virtual pone a la venta -sean opiniones positivas respecto del producto o no-

"Ayudenos a orientar a nuestros clientes" parece decir Amazon
con esta iniciativa de que la gente -sea o no cliente de Amazon-
pueda ofrecer información útil de los productos

Con esto Amazon ofrece a sus potenciales compradores valor agregado sin pedir nada a cambio (esto es, sin forzar una compra, el ingreso de datos personales ni nada). Ésta es otra clave de Enterprise 2.0: comenzar dando valor antes de recibir plata a cambio. Lo podés mirar en Amazon aunque después lo compres en otro lado, pero al menos Amazon te muestra qué opina el resto. Andá a un shopping a preguntarle al vendedor "qué opinaron los clientes después de comprar ese lavarropas". Amazon logra, con ese valor agregado, lo que pretendía: que entres al portal. Que le des la oportunidad de mostrarte qué hay de nuevo, qué se parece a lo que vos buscás (lo que te comentaba en el punto anterior), qué ofertas tenés actualmente para ese producto, etc. Unos giles de goma estos de Amazon, no?
Los datos mandan. Sin dudas. Pero la buena noticia es que no necesitás poseerlos sino tan sólo exponerlos. Cómo es esto? El buscador Google se ganó el podio entre los de su género, como te contaba en el punto anterior, por inferir relevancia de los resultados a exponer en base a lo que los anteriores usuarios hicieron con ellos. No obstante, es dueña Google de todos los datos que presenta? No es dueña de ninguno!! Elegí cualquier patrón de búsqueda (próceres de la historia, fragmentos de canciones, lo que se te ocurra) y decime qué porcentaje de los primeros 100 links que Google te mostró eran links a Google mismo (0 -cero-, man! Ni pierdas el tiempo...)

Bueno, esto empieza a tomar ritmo. No te pierdas el resto de esta serie

• Introducción
• Más se Usa, Más Nuevo Queda
• Elogio del Choreo
• Que No se Retove el Usuario
• Siempre "Casi Listo"
• Los Últimos Serán los Primeros

Y a cobrar: argentinismo usado para significar una
rápida y segura percepción de un beneficio (generalmente,
aunque no limitado a, económico). Ejemplo típico:
"Un golazo y a cobrar" (Diario Clarín -Feb 2007-, expresando que
ese gol bastó para determinar la victoria)

 Habrás  escuchado hablar de Web 2.0 mucho, poquito o nada. En la serie de posts que se inician con esta introducción no sólo vamos a cubrir todos los conceptos relacionados con Web 2.0 a nivel tecnológico, sino que vamos a destacar lo que los líderes de Web 2.0 están haciendo para capitalizar sus beneficios (dije "capitalizar"? Bienvenidos a Enterprise 2.0)

Web 2.0. la Definición
Se supone que fue Dale Dougherty, uno de los fundadores de O'Reilly (una editora de contenidos relacionados con Computación), quien acuñó el término Web 2.0 para referirse a un conjunto de tendencias económicas, sociales y tecnológicas que, colectivamente, forman la base de esta nueva generación de Internet: más madura, caracterizada por la participación de usuarios, la apertura y por los "efectos red"

"Efecto red" no es cuando en el tenis la pelota venía en una dirección, pega en la red y sale para cualquier lado sorprendiendo así al oponente, quien con suerte le va a terminar pegando con el marco de la raqueta y quizás aún así la logre devolver -y si eso ocurre, pobre de su rival porque tampoco va a poder predecir la dirección-

Te voy a contar qué es "efecto red" con un ejemplo cotidiano: Parque Rivadavia. Parque Rivadavia es una plaza de Buenos Aires que desde hace varias décadas reúne a gente de varias edades que quieren intercambiar cosas usadas (normalmente revistas, películas, álbumes y en menor medida libros difíciles de conseguir). Cada nuevo visitante que se acerca a Parque Rivadavia con la intención de canjear cosas, inmediatamente está beneficiando a los otros visitantes ya establecidos porque aumenta la variedad y disponibilidad de bienes cambiables. Por ejemplo: se cae con un Gráfico -una tradicional revista deportiva argentina- de cuando Argentina ganó el mundial 78 y seguramente más de uno de los potenciales cambiadores se sentirán tentados a dar algo a cambio por ese ejemplar (me atrevo a decir, hoy practicamente inconseguible). Pero también puede ser que no aumente la variedad sino tan sólo la disponibilidad de material, porque se cae con un Condorito siendo que ya otros habían estado cambiando ese mismo número. No importa: igual benefició a "la comunidad de canjeadores de Parque Rivadavia", porque una vez que uno se hizo de ese número de Condorito, este último deja de estar disponible para el resto hasta que el nuevo dueño lo vuelva a poner disponible de canje. Si en el durante, otro canjeador trae ese mismo número, aumenta la disponibilidad de bienes canjeables y de nuevo la comunidad se beneficia

Parque Rivadavia es un sencillo, cotidiano ejemplo de "efecto red" pero hay otros. Cuando comenzó la industria de los videos hogareños (años 70, masivamente en los 80) hubo al principio dos normas que parecían imponerse: VHS y Betamax. Sin embargo en poco tiempo VHS comenzó a perfilarse como líder, y esa sola percepción minó las chances de Betamax de recuperar terreno, por cuanto los fabricantes de reproductores y de películas, pero principalmente los consumidores -fuente indispensable de revenue (ingresos)- se movieron masivamente al presunto ganador, cosa de no ensartarse si finalmente Betamax perdía masa crítica, provocando así el cumplimiento de ese vaticinio: Betamax hoy es un recuerdo. Se dice entonces que a VHS la favoreció el "efecto red", en tanto que a Betamax la mató ese mismo efecto

Un último caso de efecto red fue la pulseada ICQ - Messenger, te acordás? Fuiste usuario de ICQ o de otro programa de chat que el MSN Messenger? Asumo que sí lo fuiste (al menos, antes de que apareciera el Messenger)
Sos actualmente usuario de otro programa de chat que el MSN Messenger? Asumo, con un margen de error muy bajo, que vos hoy usás Messenger para chatear o al menos un programa cliente de chat que se cuelga de la red del Messenger exclusivamente
Por qué dejaste de usar el que usabas para empezar a usar el Messenger? No quiero pecar de presumido pero me parece que fueron dos las razones:
1) El Messenger ofrecía la misma funcionalidad básica, sí, pero mucha más funcionalidad de valor agregado como el intercambio de multimedia en tiempo real y un mayor grado de personalización
2) El efecto red!! Cuando todo el mundo se está pasando al Messenger, las otras redes de chat se perjudican al no ofrecerte tantos contactos disponibles para conversar, al tiempo que llegás a la conclusión de que cambiandote al Messenger vas a beneficiarte más y más en la medida que el resto lo haga también. El resto, a su vez, se beneficia cuando vos te cambiás, retroalimentando el círculo
Dejame ver si adivino: no fue que de un día para el otro te pasaste al Messenger, no? Durante un tiempo mantuviste abiertos ambos, hasta que te terminaste de convencer de que en el otro software ya no quedaba ni el loro. Le erré por mucho?

Mas casos de efecto red (con ganadores y perdedores) vas a encontrar en la pulseada Windows 95 (Microsoft ganador) vs IBM OS/2 (IBM perdedor), arquitectura "Wintel" (Microsoft e Intel ganadores) vs Arquitectura Apple Mac (Apple perdedor). Aunque el efecto red no es que se aplica solamente a batallas comerciales. Desde el surgimiento de la web se han venido creando "comunidades" en las que habrás entrado, consumido, contribuido y tal vez hoy abandonado o cambiado por comunidades similares (pensá no sólo en el chat, también en YouTube, eMule, BitTorrent, Napster, Kazaa, Webshots, listas de discusión, Flickr y, como un fenómeno originalísimo, pensá en los blogs)

Es abrumador el efecto red que generan los servicios que estas aplicaciones provéen. Y hasta acá sólo estamos hablando de Web 2.0. Definamos Enterprise 2.0 al conjunto de aplicaciones web empresariales que usan las tendencias económicas, sociales y tecnologías introducidas por Web 2.0 con el fin de capitalizar utilidades

Por Qué Una Organización Querría Explorar Web 2.0 Para Ganar Plata?
Se pueden distinguir cinco (5) motivaciones

1. Una base de clientes tan global como se quiera. La querés acotada a tu ciudad o país? La querés ampliada a todo el mundo de habla hispana? (este blog en castellano es un claro ejemplo: se lée en Colombia, en Chile, Venezuela, México, España... incluso recibí feedback desde Brasil). La querés a escala mundial? Bueno, en ese caso te recomiendo que uses el inglés (o sea, el "latín" de la era digital y el mundo de los negocios) como lenguaje principal

   
   Crecimiento incesante de la población digital
   
   
   
   Cómo se distribuye según
   continente la población digital

   Los usuarios de la Web a nivel mundial vienen creciendo a razón de unos 150 millones por año, de los cuales un 8% está en América Latina, que viene creciendo en participación en forma vertiginosa ya que de momento sólo un 17.3% de su población tiene acceso a Internet (eso es menos de la mitad de Europa, que a su vez está por detrás de Australia, quién junto a América del Norte gozan de tener a más de la mitad de su población conectada)

   
   Podríamos ser muchos más (relación entre los usuarios
   "conectados" de un continente y el total de su población)

   Si miramos el vaso medio lleno, tenemos un montón de plafond como para poder seguir creciendo gracias a iniciativas de inclusión digital -expresión con que se designan los programas de ventas de PC a usuarios de bajos recursos- como "Mi PC" y otras

2. Acceso a Internet cada vez más... accesible (valga la redundancia ). La cobertura de la red se asoma como total -Kirkland, el pueblo cercano a Redmond, donde vivo, es una ciudad WiFi (esto es, salís a la calle, prendés tu notebook y hay acceso a Internet inalámbrico)-. Además hoy a Internet no se entra con una compu de escritorio o una notebook: un celular sirve, un iPod, incluso una consola de videojuegos tipo Playstation, televisores e incluso... autos

    
   AVIS ofrece un servicio peculiar para
   ejecutivos: Internet en el auto

   Claro, el uso que le damos es diferente en cada caso: el celular te permite chequear mails y -con limitaciones- responder algunos. También te permite bajarte ringtones (o sea, el sonido que querés que haga cuando suene). El iPod te permite comprar canciones y películas, además de rankear temas. Con una Playstation o una XBox podés jugar en línea, pero también te podés bajar juegos para probarlos y eventualmente decidir comprarlos (si no, al tiempo dejan de andar). O podés comprar películas en formato HD (high definition, alta definición)
   Respecto de la TV, olvidate de la tele tal como la conociste. La tele en un tiempo más va a llegar directamente por Internet (eso se llama IPTV, o Internet Protocol Television). Vos vas a poder mirar qué dan en los canales, tal como lo hacés hoy; o eventualmente vas a poder elegir ver un programa bajo demanda (esto es, que lo pasen exclusivamente para vos). También, si no tenés muy claro qué es lo que querés ver vas a poder "googlear" por palabras claves y recibir una lista de alternativas rankeadas. Hay varios proyectos en curso pero yo te paso referencias de dos titanes conocidos: Microsoft TV y Apple TV

3. El usuario de Internet no consume pasivamente: produce también! Al principio la web era un camino de vuelta nada más: vos ponías una URL y te volvía una página. Hacías click en un link y te volvía otra página, y así sucesivamente. Parecido a cambiar canales con el control remoto de la tele. Después pudiste empezar a ingresar formularios vía web y con eso quizás te ahorraste de hacer colas u otros trámites. Completabas tus datos y qué querías y después la seguías por email o por teléfono. Cool. Hoy podés opinar en foros, diarios, comentar libros o tener un blog personal. Qué bárbaro eso, no? Contás tu vida para que la lea cualquiera. Por ejemplo, mi blog: quién me da cuerda a mí para llevarlo? Para qué lo hago si no sé ni quién me lée? Y ni que hablar de los que suben fotos (oh, yo otra vez... ), videos!!  (just click). Raro, no? Ahora... sería lo mismo la web si volviesemos a los sitios estilo años 96, 97? A esas páginas con casi nada de capacidad de que dejemos nuestra huella? Volver a eso sería una experiencia tan pobre que el efecto red que esta web viene produciendo año sobre año se vería seriamente comprometido. Ya no hay vuelta atrás

    
   Los lectores de The Server Side .NET no se conforman con leer los contenidos,
   sino que aportan su propia visión sobre los mismos (y nada complaciente!)

4. Costos de producción tienden a la baja. No quiero decir con esto que podés esperar un mes para comprarte una compu que seguro que va a valer menos. Lo que quiero decir es que si bien los precios aumentan, conseguir hoy una compu con dos procesadores, diez veces mayor capacidad de almacenamiento que la que te compraste el año pasado, multimedia on board con un 30% de mejor resolución gráfica y otros chiches más, quizás te sale un 10% más de lo que habías pagado (no te sientas un gil: nos pasa a todos todo el tiempo, pero esperar para comprar no vale la pena porque cuando finalmente lo hagas, igual te va a pasar). Esto, por cierto, va a digitalizar más y más a la población con lo que andá pensando en crear una comunidad que se beneficie del efecto red que los nuevos te puedan llegar a proveer
5. Nuevas oportunidades de obtener ingresos. La web ha masificado el acceso a datos, incluso a datos recientemente generados como lo son las noticias. En otras palabras, los diarios se pueden leer en Internet. Gratis
   Son giles los que hacen diarios de papel? Cómo les puede cerrar el negocio si regalan las noticias por internet? Encima teniendo que pagar por la granja de servidores, el espacio de hosting creciente (porque las ediciones anteriores de varios años hacia atrás están igualmente en línea)!! Se van a fundir!!!
   Y lo harían, si no fuera por las propagandas que uno tiene que recibir "obligado". Esos avisos son la forma de pagar por ver noticias de un diario que ya ni compramos (para qué si está en la web). Pero estas propagandas, pareciera un tema menor, una diferencia sutil, pero no son nada que ver con sus equivalentes en el diario de papel o en la televisión
   La web es un hipertexto y, como tal, al hacer click en una propaganda entramos al sitio de la empresa que ofrece lo que la propaganda anuncia (un crédito, entradas para un espectáculo, un DVD recién lanzado, etc). Está todo tan "a pedir de boca" que el factor "calentura" hace el resto (clinck caja)

Todos estos elementos están impulsando a la web como un gran escenario para el comercio y los negocios que no se había vivido en la época del "cuerpo a cuerpo", cuando íbamos en persona a hacer compras. Esta serie trata de eso: de qué tendencias sociales, tecnológicas y económicas se están dando para hacer plata en la web

Esta serie Enterprise 2.0 va a continuar de la siguiente (tentativa) manera

• Introducción
• Más se Usa, Más Nuevo Queda
• Elogio del Choreo
• Que No se Retove el Usuario
• Siempre "Casi Listo"
• Los Últimos Serán los Primeros

Nos vemos

Chupetín Topolín: golosina argentina que
venía acompañada de un juguete (regularmente
una miniatura de una juguera o un xilofón)

 No  me gusta publicar dos boletines seguidos en el blog, porque suena que empiezo a hacer "la fácil" con mi bitácora (qué palabrita tan fina) y a sólo comentar acerca de lo que otros hacen, sin aportar un valor genuino. Pero lo cierto es que en estos días me encuentro abocado a un post acerca de Web 2.0 y para ello estoy investigando y consumiendo información de diversas fuentes (libros, artículos, audios, etc) de modo de sintetizar algo entendible por nosotros -porque en realidad hay muchos conceptos no técnicos que hacen a Web 2.0, que se deben entender también para captar la oportunidad que se nos abrió con esta nueva movida-

Pues bien, en lo que al boletín respecta ha corrido tanta agua bajo el puente en este último mes (digamos, entre los 15 de Abril y Mayo) que, como siempre me pasa, me dolió sacar la tijera y la tentación de decir "mah, sí, vo meté todo" era altísima

Pero no es la idea de este boletín. No. La onda es contarte 10 cosas interesantes que tenés a mano para profundizar, para que tengas una idea de lo que Microsoft está haciendo con su plataforma -la uses o no- con la intención de que conozcas lo que tenés disponible para lograr aplicaciones empresariales de misión crítica en una forma sensata (y especialmente, ojalá, placentera!!)

Como premio al mejor lector, esta vez te estoy arrimando una herramienta que, si vos o tus desarrolladores se estaban volviendo bizcos punteando tags HTML en sus páginas web, te va a venir al pelete. Se trata de la barra de herramientas para el desarrollador que se cuelta del Internet Explorer (versiones 5 en adelante) y te permite explorar y modificar el árbol DOM del documento que estés desplegando (no por agregar o sacar nodos pero sí de modificar sus atributos). También vas a poder ubicar un elemento específico en una página (sea por nombre o marcándolo visualmente y que te lo señale en el árbol), bosquejar los bordes de las tablas invisibles, validar gramáticas HTML, CSS, RSS y otras presentes en tu página (porque por mucho que se desplieguen bien, capaz que en Firefox, Opera o Safari no se ven bien), trabajar las imágenes embebidas en la página y con todo esto no te conté ni la mitad de todas las cosas que esta herramienta hace

Bueno, ahora sí, aquí están, estos son

1	Pariendo A Windows Server 2008: Salió la Beta 3 Allá por 1993 aparecía Windows NT, un windows para correr en servidores (hasta ese momento el networking de Microsoft se venía dando en forma peer-to-peer mediante la llamada edición Windows for Workgroups, también conocida como Windows 3.11) En un principio hubo algo de descreimiento de que un servidor hecho por Microsoft pudiera destronar a UNIX. Aunque eso fue lo que finalmente pasó. No obstante el surgimiento de Linux hizo pensar en algún momento que el liderazgo del servidor Windows (que fue mutando de nombre, de NT pasó a llamarse "Windows 2000" a secas y ahora Windows Server -actualmente 2003 pero en un año más 2008-) podía verse perjudicado (y ni que contar de la suerte de UNIX, siendo que Linux estaba basado en UNIX pero además -excepto algunas distribuciones- no tiene costo). En los hechos algo de eso hubo: Linux se había empezado a comer parte de la torta de Microsoft y varias empresas distribuidoras de UNIX desaparecieron. Inclusive, durante la crisis conjunta que Latinoamérica padeció a principios de este siglo, varias empresas y también organismos gubernamentales tomaron la iniciativa de pasar a software de código abierto. Pero hoy esa tendencia parece haberse detenido y en varios casos, empresas que habían ido a Linux o que habían, incluso, iniciado con Linux, comenzaron a migrar a Windows Server (si bien aún quedan las que planean el camino recíproco) Te dejo acá varias guías paso a paso. Y un webcast de las novedades y demos interesantes
2	Zachman o TOGAF? La de Gartner o la Federal? Una Sesión con Roger Sessions Yo sé que no hay que recomendar las cosas por quién las hace sino por lo que son. Pero es que este artículo no sólo es muy revelador... El autor es un grosso, un monster of rock. Es director de IASA (algo así como el gremio de lo sarquiteto de computación). Escribió seis libros de modelado de arquitecturas (cuchame, yo apenas si escribo este blogcito), es MVP (most valuable professional, una distinción que Microsoft otorga a los que hacen cosas grossas con la plataforma de Billy y dirige un newsletter, ObjectWatch, que ya va por su décimo tercer aniversario (y pensar que el otro día yo estaba orgulloso de que mi blog cumplió un año) En esta ocasión el muchacho se la toma con (no contra) las metodologías de modelado de arquitecturas empresariales (ojo al piojo, no estoy hablando de modelado en capas de una aplicación, sino del modelo completo de procesos de una organización -esto es, incluyendo cualquier aplicación Cliente/Servidor, en capas, etc: todo-). Las describe, compara y contrasta. El estudio es valiosísimo en sí. Pero encima, hecho por Sessions
3	MIX Remixado y Remasterizado Si estás leyendo este blog es porque hablás castellano. Si hablás castellano es porque seguro (con un margen de error inferior al 1%) que tu patrón o vos mismo decidiste no ir a MIX, el evento más "Web 2.0" de Microsoft, que reúne desarrolladores de aplicaciones con diseñadores, porque el round trip salía muy caro. Me equivoqué? Si te sirve de consuelo, yo tampoco soy el nieto de Rockefeller pero por suerte, como ya había ocurrido el año pasado, las sesiones están disponibles (ojo, si bien está la lista de todas, las van subiendo por tandas y es posible que si visitas el sitio en estos días que publiqué el boletín, tengas la mala suerte de que querés ver una que no subieron aún, pero lo que no esté va a estar) Lo novedoso es que Microsoft se come su propio pesto (en inglés a esto se lo llama eating your own dogfood, o "comerse la propia comida para perros" que es cuando consumís lo que vos mismo producís para mostrar que no te vas a morir ni te vas a envenenar) porque las sesiones se pueden ver online mediante Silverlight: un entorno gráfico (vectorial) y multimedial (audio y video) que se acopla a los browsers más conocidos en la misma forma en que Flash (originalmente de Macromedia, hoy de Adobe) lo hace. Es que Microsoft enfiló fuerte a pelear contra Adobe en ese terreno -Flash es hoy indiscutidamente usado en forma masiva (por mencionar algún clientito, Youtube, uno chico seguramente)- Paralelamente, y porque de Web 2.0 se trata, las sesiones están también para Windows Media Player, iPod, Zune (ah, sí: el iPod de Microsoft, te conté? Microsoft enfiló fuerte contra Apple ) y, por último, en formato Powerpoint 2007 (OpenOffice y Google enfilaron fuerte contra Microsoft ) Si no tenés Office 2007 y necesitás abrir documentos de esta versión desde versiones previas de Word, Excel, etc, hacé click acá Volviendo al MIX -porque ya mezclé demasiados temas, dicho sea de paso- las sesiones están muy bien agrupadas por tracks: tomadores de decisión, desarrolladores y diseñadores de interfaces
4	Programación en Biztalk... Y Ahora me lo Dicen? Puede que tengas mucha o poca experiencia con Biztalk, que ya hayas implementado proyectos o que apenas si estés proyectando incursionar. Pero hay metidas de pata que solemos cometer no de inexpertos sino por no razonar lateralmente, no cuestionarnos si no habrá una forma mejor de hacer las cosas. Y después, como decía Nicolino Locche (una gloria del boxeo argentino), "la experiencia es un peine que recibís el día que te quedaste pelado" Este artículo consiste en ocho paraguas a tener a mano para distintas tormentas que se pueden asomar mañana, aunque hoy todo se vea exitoso. Te va a servir aunque sea echarle un vistazo aunque no tengas nada que ver ni con Biztalk ni con la plataforma Microsoft, porque lo que más me decidió a seleccionar este artículo es la reusabilidad de varias de sus recomendaciones
5	Windows Compute Cluster Server: la Patota de Microsoft Venís apurado? Tenés que correr procesos de misión crítica que no pueden esperar, llenos de cálculos complejos que te mandan la CPU al 100%? Ponete en onda, jovatón, te quedaste en el tiempo vos! No sabés que existe una versión de Windows para Cómputo de Alto Rendimiento (High Performance Computing o HPC)? Esta versión provée elementos para que procesos complejos puedan separar partes medianamente independientes para que se procesen en paralelo en diferentes procesadores (los que componen el cluster o súper computador) Quince años atrás estos equipos eran tan caros que normalmente los gobiernos o las empresas más grandes podían darse el lujo de contar con esta tecnología. Hoy los costos han caído sobremanera y están accesibles para cualquier empresa mediana y/o proyecto científico -viste que normalmente los científicos se quejan de que nadie financia proyectos de investigación, no?- Esta presentación te muestra en forma integral no sólo cómo trabaja el sistema operativo, sino también cómo se opera, administra y también -jé, sos desarrollador, no? Cómo se debuguea en paralelo con Visual Studio 2005-
6	Y Dale con Object/Relational Mapping: Ahora ADO.NET Entity Framework Una presentación integral de la próxima versión de ADO.NET, aquella que extiende .NET mediante el agregado de mecanismos de consultas sobre objetos (LINQ o lenguaje integrado de consultas -integrado al framework .NET, se entiende-) El presentador muestra también las extensiones a Visual Studio para mapear tablas y objetos en forma visual. No va de lleno a detalles tales como lazy loading (carga perezosa) para evitar sobrecarga de objetos pero tengo sabido que la futura versión de ADO.NET lo contempla (es interesante leer las revelaciones de Pablo Castro, Project Manager de ADO.NET, al respecto)
7	Conozcan Al Buchón de la Clase: System Center Operations Manager 2007 Muchachos, estamos en problemas. Porque System Center Operations Manager 2007, sucesor de Microsoft Operations Manager 2005, proyecta continuar la linea de su antecesor, deschavando el estado general del sistema (como ser "qué servidor se cayó", "cuál se está por caer", "qué proceso se está comiendo la CPU", etc A los que desarrollan software .NET les quiero decir que si hacen uso inteligente de la biblioteca de Instrumentación, sus aplicaciones van a poder ser monitoreadas por Operations Manager. Esa biblioteca permite generar eventos Windows Management Instrumentation (WMI) que son capturados por el sistema operativo. Operations Manager se suscribe a estos eventos de manera de -como buen alcahuete- disparar alarmas (para más info al respecto, click acá. No obstante, te sugiero mucho que en lugar de usarla directamente le echés un vistazo a lo que los chicos de Patterns and Practices han hecho con el Logging and Instrumentation Application Block)
8	Objetos en JavaScript JavaScript suele dar una mano piola, especialmente cuando se trata de evitar correrse un pique hasta el servidor web para validaciones menores y otras cosas que puedan degradar la experiencia del usuario (user experience o UX) Lo que varias veces escuché, y compartí sobre JavaScript es que sí abrazaste el paradigma de Orientación a Objetos... bueno, acá de todo eso nada. JavaScript maneja un conjunto básico de objetos (Window, Navigator, y otros relacionados con browsers y HTML). Ahora, le preguntás de herencia (inheritance) a JavaScript y te contesta que sus antepasados no le dejaron un mango. Le preguntás si tiene algo para decir de polimorfimo y te dice "sí, polis: mucho, morfi: comer; polimorfismo es la facultad de tener varias comidas al día, no?" Esto, obviamente, hacía que algunos developers pierdan el interés en este lenguaje de scripting y lo menospreciaran. Si estás en ese grupo, este artículo te va a mostrar cómo simular varias características de objetos (herencia, constructores, propiedades, etc) mediante el tipo function()
9	Negro el 11: El Journal de Arquitectura Número 11 Está Entre Nosotros El amigo Simon nos arrima una edición más del magazine para Arquitectos de Software. Esta vuelta el eje pasa por Infraestructura para Aplicaciones de Misión Crítica Vas a encontrar artículos sobre hosts escalables, computación de alto rendimiento (HPC, como te contaba en el punto 5), uno que me llamó muchísimo la atención porque aplica conceptos de Test-Driven Development (esto es, desarrollo de software, no infraestructura) para planear la plataforma (hardware, software de base) También, como en todos los journals ocurre, siempre hay uno o dos artículos extra al tópico de la edición. En este caso se trata de un tema que es recurrente en orientación a servicios: el versionado. Porque, seh, el proveedor de un servicio está desacoplado del consumidor del mismo, sólo comparten el contrato por lo cual la implementación del servicio puede versionarse cuando se quiera sin necesidad de desplegar nada en los clientes y bla bla bla... Ahora... si lo que cambia es el contrato? (El contrato se compone de los mensajes de entrada y salida del servicio). Recorcholis, Batman! Espero que te guste esta edición y, cualquier cosa, cuidadito con criticar que el director es mi jefe (el pájaro nunca le apunta a la escopeta, no sabías eso vos?)
10	Policy Injection Application Block: Aspect-Oriented Programming (AOP) en .NET? Los amigos de Patterns and Practices no dicen eso directamente, pero si leés este artículo describen a este nuevo bloque de aplicación (incluído en la versión 3.0 de la Enterprise Library liberada el pasado 5 de Abril) como un proxeador transparente de objetos. Tecnicamente hablando, no es AOP. Pero si vamos a los bifes, AOP es un instrumento para resolver el problema del código enredado (tangled code, también llamado spaghetti code) al replicar en clases de negocio la lógica de ciertos intereses globales a toda la aplicación (autorización, por ejemplo, trazabilidad, etc). A estos intereses globales se los conoce como cross-cutting concerns Un lenguaje se decía que era orientado a aspectos o AOP si al separar los intereses en componentes cohesivos(separation of concerns), permitía luego definir reglas de tramado (weaving rules), algo así como un surcido invisible que nos permita que al invocar directamente un método de una clase, algún otro aspecto como los que te mencionaba (seguridad, etc) se interponga en la llamada y haga lo que necesitemos que haga, pero sin que llamador o llamado se involucren directamente en esto En realidad, .NET siempre permitió interceptar llamadas mediante un mecanismo, por decirlo suave y que no me rajen, cuestionable: la clase interceptada tenía que heredar de ContextBoundObject. Esto no es muy atractivo por cuanto nos hace perder grados de libertad siendo que .NET no permite herencia múltiple Para ilustrar mejor lo que no me gusta del enfoque: qué pasa si la clase a interceptar es ClientePersonaJuridica que hereda de la clase abstracta Cliente? Si hago que ClientePersonaJuridica herede de ContextBoundObject voy a tener que copypastear todos los metodos de Cliente (lo que va a decantar en doble mantenimiento). Si no, hago que Cliente herede de ContextBoundObject (si no heredaba más que de Object aún, de lo contrario traslado ese problema al antecesor de Cliente). Qué querés que te diga... no digo que sea el apocalipsis pero no me gusta el approach Otra cosa, perdón que esté criticón con la empresa que me da de comer, que no me gustaba del enfoque era que la intercepción se definía mediante atributos ContextAttribute en el código (o sea, no por configuración). Se suponía que la onda era desenredar el código al quitar llamadas a métodos de intereses globales en clases de negocio. Contame qué diferencia entre llamar a un interés al ppio o final del método, o decorar el método con un ContextAttribute. Quiero decir, el código va a seguir estando enredado (ya alguna vez me saqué la bronca de mi discrepancia con ese approach para simular AOP en un post memorable) Bueno, este application block mejora sensiblemente ese enfoque. Si bien podés seguir definiendo pointcuts mediante atributos (que ahora basta con que implementen una interfaz llamada ICallHandler), también lo podés hacer -es más, hacelo así- mediante el archivo de configuración de la aplicación que usa Enterprise Library (y por ende, lo podés configurar con la herramienta que te permite mantener ese archivo sin tener que editarlo directamente). Es interesante la forma en que definís puntos de corte, porque puede ser mediante un pipeline de handlers (lo que garantiza el orden de intercepción, algo que no vas a poder predecir si usás atributos en el código), o mediante reglas de concordancia (matching rules). Con estas últimas vas a poder interceptar conjuntos más amplios, como por ejemplo "todos los métodos del espacio de nombres Cobranzas que devuelvan Pago" (qué me contás). En términos de AOP, en esas reglas tenés tus weaving rules Respecto de las clases interceptables, al principio me sonó a más de lo mismo cuando ví algo como que debían heredar de MarshallByRef (.NET Remoting). Pero estaba ya por mandar mi "aaaaandá a cantarle a Gardel" cuando ví que eventualmente podés definir una interfaz con los métodos interceptables y que la clase a interceptar implemente la interfaz (eso no atenta contra la herencia múltiple, por cuanto una clase sí puede implementar varias interfaces). De nuevo, andate por esa alternativa: no te sugiero extender MarshallByRef. Además, interface-based programming es una práctica saludable Bueno, si querés ver todo esto en acción hay un webcast de poquito más de una hora que te lo muestra

Mucho te conté en este boletín, mucho me ha quedado afuera (AJAX, Windows Communication Foundation, Seguridad, Performance, interoperabilidad con UNIX, Java, ...). Pero todo eso lo podés seguir en mi otro blog: el MSDN Architecture Center 

Abrazo y hasta el próximo bulletin

 Éstra!!  Éstra!! Salió la tercera edición del boletín estraoficial para arquitestos con la súltima novedade para las plataforma Java y el Punto Nés!!

1	[JavaWorld] Generando AJAX desde Java con el Google Web Toolkit (GWT) Si sos javero y querías empezar a ver AJAX pero te desalentaba todo lo que tenías que aprender, esta noticia no te podía venir más al pelo El caso es que Google viene liberando un toolkit que te permite crear la "plomería" de las llamadas asíncronas de AJAX en JavaScript... sin siquiera enterarte de qué es todo eso Es más, si usás Eclipse o IDEA (IntelliJ), el toolkit se "cuelga" del mismo para pasar que todas estas novedades sean, en seguida, parte de tu día a día Este artículo va de menos a más en el tema, anillazo al dedo
2	[InfoQ] Java y .NET: Se Ha Forrrrrrmado una Pareja Ted Neward nos arrima acá uno de sus mejores papers, aunque no va a ser el típico ensayo de interoperabilidad entre las plataformas Java y .NET (de eso hay bocha publicado) sino en qué aplicar lo mejor de cada uno Como bien dice Ted al principio, la clásica pregunta "cuál es mejor?" no tiene una respuesta valedera en forma vertical sino que según el área, alguno será más versatil que el otro. Su propuesta entonces es tomar lo mejor de cada uno
3	[.NET Development] Lecciones Aprendidas para Visual Studio Team System Está por salir un libro llamado "Recetas para Team Foundation Server: un Enfoque Problema-Solución". Su autor, Michael Ruminer, nos brindó una presentación al respecto, contándonos las mejores prácticas para control de versiones, seguimiento de unidades de trabajo, administración de proyectos, adaptación de plantillas de procesos y otras instancias del ciclo de vida de desarrollo de software. Aprovechá a mirarla que esta vez no es un evangelizador de Microsoft haciendote el verso de que vas a ser, por fin, un programador feliz
4	[SaaSCon] Aplicación SaaS a la Microsoft A fines de Abril se realizó nuevamente la conferencia principal sobre "Software as a Service" ("Software como un Servicio", o SaaS). Gianpaolo "GP" (yipí) Carraro, nuestro arquitecto jefe para guías y recomendaciones SaaS estuvo allá, explicó lo que viene estando analizando al respecto con Southworks, la consultora argentina que lo asesora en la materia, y por supuesto mostró la aplicación de referencia que implementa las guías que están produciendo: LitwareHR (una aplicación ficticia para recursos humanos)
5	[Java Insight] Cachando Algo de la Caché Las aplicaciones de misión crítica requieren alta disponibilidad. Para ello deben ser capaces de escalar acorde a la cantidad de usuarios. La escalabilidad se suele ver comprometida cuando recursos externos de acceso limitado (por concurrencia, por velocidad de transmisión, etc) comienzan a generar contención. Entonces ahí es donde a varios se les ocurre "y si dejamos las consultas más frecuentes en memoria u otro recurso no tan comprometido?". Eso es lo que se conoce como caché de datos. Pero hacer una caché no es una tarea sencilla porque, para que sea efectiva, necesitamos dar en el clavo y terminar cacheando aquello que realmente se accede muy frecuentemente. Además, en el durante, qué pasa si en el back-end se modifica algo de lo que tenemos cacheado? Cómo nos enteramos para así refrescarla? Ésa y tantas otras inquietudes -incluso las que quizás ni habías pensado- te las va a contestar la autora de este artículo, para que lo tengas en cuenta y guardes en la caché
6	[IBM] El Mejor Programador También Puede Chamuyar Normalmente a los buenos developers se los descubre jugando un picado en Parque Saavedra: son aquellos que no la ven ni cuadrada (ergo, yo soy un excelente programador). Los que conocen mucho de programación normalmente son los que se quedan a arreglar los bardos que saltan a las cinco y media de la tarde cuando todos creían que faltaba media hora para rajarse. Como estos individuos terminan, así, conociendo bien la aplicación, suelen también tenerla clara para indicar qué habría que rediseñar para que valores medibles como el rendimiento y la mantenibilidad no sean un dolor de . Sin embargo, y curiosamente, a esta gente suele escatimarsele consideración en cuanto a emitir opinión se trata. Ellos mejor que se dediquen a programar callados que para opinar bastante que se le paga a los que juegan bien a la pelota. El Gigante Azul en un esfuerzo sin precedentes nos arrima acá un importantísimo documento para ir dejando de programar de 9 de la mañana a 9 de la noche
7	[Sun] JPA: de la Base de Datos a Su Mesa La Java Persistence API está destinada a estandarizar el mapeo entre objetos y tablas relacionales en la plataforma Java. Este artículo muestra un interesante ejemplo en código de esta nueva facilidad, y a la vez aprovecha y muestra tips interesantes de la compilación de aplicaciones Java (lástima, en mi caso, venir a enterarme ahora que me pasé al lado oscuro )
8	[O'Reilly] Open Source: Éramos Pocos y Parió la Abuela Cuando yo era parte de la comunidad Java, me acuerdo que consideraba una gran virtud el hecho de que la plataforma Java daba lugar a una innumerable cantidad de proyectos Open Source de manera tal que para cualquier cosa que yo necesitara, tenía no menos de tres y seguramente más de cinco alternativas distintas de frameworks para incluir en mi aplicación. Querías Object/Relational Mapping? Ahí están Hibernate, iBatis y otros. Querías producir JSP de una manera rápida? Cocoon, Velocity, Tiles, y varios otros, cada uno con su enfoque particular, pero te iban a permitir lograrlo. Y qué me podés decir de motores de workflow, sistemas basados en reglas? Otro tanto Claro, el problema -y yo realmente no lo notaba- era que si bien había un tiempo ahorrado de codificación de toda esa lógica que el framework aportaba, habían tiempos ocultos no siempre contemplados: primero, el tiempo que tomaba investigar y aprender no sólo lo básico del framework seleccionado sino también las mejores prácticas para que no se nos vuelva en contra. Pero además, y éste era un tiempo realmente sustancioso, cómo decidir rápido y bien por alguno de los frameworks entre tanta oferta disponible. A mí personalmente me pasaba que incluso habiendo tomado una decisión, todavía dormía con el cxxx fruncido durante varios meses de proyecto, temeroso de haber tomado la decisión equivocada. Los amigos de uno ayudaban poco, porque mientras que algunos eran radicalmente defensores de lo que uno "tenía" que elegir, otros decían "nuh!! no te metas con eso...!" Bueno, este artículo comenta eso mismo y destaca el surgimiento de un portal donde los usuarios de los distintos frameworks no sólo los califican en determinados aspectos, sino que cuentan casos concretos de uso en proyectos reales. Por lo menos, si te vas a ensartar con lo que elegiste, enterate quién más piso el palito!
9	[TheServerSide] Un Cluster de Java Virtual Machines hecho con Terracotta En sistemas de Misión Crítica se necesita que las aplicaciones estén altamente disponibles. Para ello es necesario minimizar al extremo el downtime (esto es, el tiempo que las aplicaciones dejan de estar disponibles). Una manera de lograr reducir esta minimización casi a 0 es correr la aplicación en más de un equipo (servidor o no), de modo que si alguno de los equipos deja de operar, al menos el/los otro/s van a seguir brindando el servicio en tanto uno o más operadores reviven al equipo "convalesciente" (y, claro, si todos los equipos salen de operación... el downtime empieza a correr de nuevo). Pero para que el/los equipos remanentes puedan hacerse cargo, es necesario que ciertos datos de la aplicación estén en alguna forma replicados (las sesiones de una aplicación web, por citar un ejemplo). Replicados o al menos persistidos, de manera de poder ser accedidos por cualquier otro equipo del grupo, de imponerlo así las condiciones Una aplicación que corre en esta manera se dice que se ejecuta en un clúster de equipos (CPU, servidores, etc). Obviamente, los clústers se tienen que poder gobernar de alguna manera. Y en realidad hay varias formas de lograrlos. Las hay descentralizadas, donde cada equipo del clúster comparte su info proactivamente con el resto. Las hay basadas en un administrador central, donde cada uno de los equipos le alcahuetea lo que está haciendo a este administrador central Así las aplicaciones van a poder escarlar. Hablaremos, por lo tanto, de escalabilidad horizontal, cuando el cluster se compone de varios equipos homólogos, y de escalabilidad vertical cuando en realidad es un sólo equipo pero con varias CPUs trabajando en forma independiente aunque coordinada. Seguramente hayas tenido que aprender esto cuando tuviste que trabajar con granjas de servidores web corriendo una misma aplicación Open Terracotta es un servidor de clúster para aplicaciones Java, y este artículo te cuenta en detalle cómo está pensada su arquitectura
10	[O'Really] Orientación a Servicios APB (a prueba de... ya sabés) Como cierre, un artículo que no pretende ser otra vuelta de tuerca más sobre Windows Communication Foundation (WCF). Es un poco la historia de la orientación a servicios (que no se debe necesariamente interpretar por SOA o Arquitectura Orientada a Servicios) sino más bien del concepto como patrón de diseño de componentes En ingeniería de software, como en la vida misma, todo tiene su por qué. Y la Orientación a Servicios no es una excepción acá. En realidad emergió como una consecuencia de intentos previos, de paradigmas más primitivos que al ser puestos en práctica resolvieron bastante de los problemas que prometían venir a resolver, en tanto que otros de estos problemas debieron seguir esperando a ser resueltos por otros mecanismos; y, finalmente y admitiendolo, los paradigmas previos a su turno introducían nuevos problemas Pues bien, este artículo te relata brevemente qué paso con los intentos anteriores, cómo se llegó a la Orientación a Servicios, y te describe en detalle todas las premisas a cumplir por este tipo de componentes