Blog de Paradigma Tecnológico

Web 4.0

publicado el Jueves, 27 de Octubre de 2011 por: Paradigma
Etiquetas: - | No hay comentarios »

Es necesario un cambio de Paradigma, un nuevo modelo de Web.

La Web 4.0 propone un nuevo modelo de interacción con el usuario más completo y personalizado, no limitándose simplemente a mostrar información, sino comportandose como un espejo mágico que de soluciones concretas a las necesidades el usuario.

Web 4.0 es una capa de integración necesaria para la explotación de la Web semántica y sus enormes posibilidades.

La Web 4.0 es un nuevo modelo de Web que nace con el objetivo de resolver las limitaciones de la Web actual.

Actualmente las formas que tiene un usuario de interactuar con la Web son muy limitadas. Una parte fundamental de la Web tal como hoy la conocemos son los buscadores, con el tiempo hemos ido aprendiendo su funcionamiento y nos hemos adaptado a sus limitaciones. Su principal limitación es que no hablan el lenguaje del usuario, no son capaces de responder a preguntas del estilo ¿En qué año murió Kennedy? Y no las pueden responder por una sencilla razón, no son capaces de entenderla.

La Web semántica promete mejorar este problema aplicando técnicas de procesado del lenguaje natural, pero la solución que propone no es suficiente, la Web 3.0 será capaz de responder a la pregunta anterior, pero la novedad se limitará a obtener resultados de búsqueda más precisos. Nunca podrá responder consultas del tipo “Quiero que un taxi venga a buscarme”.

Web 4.0 es una capa de integración necesaria para la explotación de la Web semántica y sus enormes posibilidades.

Se fundamenta en 4 pilares fundamentales:

  • Comprensión del lenguaje natural (NLU) y técnicas de Speech-to-text
  • Nuevos modelos de comunicación máquina-máquina (M2M). La red estará formada por agentes inteligentes en la nube, que serán capaces de comunicarse entre si y delegar la respuesta al agente adecuado.
  • Uso de información de contexto del usuario. Sentiment análisis, geolocalización, sensores…
  • Nuevo modelo de interacción con el usuario. Para que la Web no se convierta en un mero almacén de información son necesarios nuevos modelos de interacción, o incluso ejecutar acciones concretas que den respuesta a las necesidades de los usuarios, haciendo hincapié en su uso sobre dispositivos móviles.

Con este nuevo modelo de Web podremos hacer consultas del tipo “Quiero que un taxi venga a buscarme” y que tu móvil se comunique automáticamente con la compañía de taxis más cercana, sin intervención directa del usuario.

Este proyecto ha sido cofinanciado por el Ministerio de Industria, Turismo y Comercio, dentro del Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica 2008-2011, siendo su número de referencia el TSI-020100-2010-792

Resultado del Reto Java

publicado el Martes, 23 de Agosto de 2011 por: Paradigma
Etiquetas: - | No hay comentarios »

El 14 de Julio de 2011, en la charla organizada por Java Hispano y MadridJUG (“Java SE 7: The Java Platform Evolves”) el equipo de Paradigma Tecnologico propuso un Reto Java para motivar la gente a conocer las funcionalidades aportadas por la nueva versión de la plataforma, Java7.

El flamante ganador del Reto JavaLos participantes enviaron sus propuestas para resolver el reto planteado en nuestra web, que admitió soluciones hasta el 18 de Julio a las 8:00 am.

Se recibieron además varias soluciones al Reto Java fuera del plazo de presentación que no pudieron ser tenidas en cuenta para el concurso.

Desde Paradigma nos gustaria agradecer a todos los que participaron del reto enviando su solución, y en especial a felicitar a Daniel Carroza Santana, por ser uno de los finalistas y haber sido el agraciado por el sorteo del Samsung Galaxy S2.

 

Android vs iPhone (II): Tiendas de aplicaciones

publicado el Martes, 10 de Mayo de 2011 por: José Ignacio Herranz
Etiquetas: - - - | 2 comentarios »

Siempre he pensado que lo realmente revolucionario que ha introducido Apple no es el iPhone, sino todo lo que ha ido construyendo a su alrededor. Con la App Store, Apple ha construido un importante ecosistema económico-tecnológico con una gran cantidad de desarrolladores y usuarios.

Apple no solo ha conseguido que su tienda aporte valor, tanto a usuarios como a desarrolladores, lo que tiene más merito es que lo ha conseguido bajo su control tecnológico y económico. Ninguna otra marca de hardware se había planteado antes llevarse un porcentaje de todas las ventas, creo que solo Apple podría concebir algo así.

Pero tanto control por parte de Apple tiene también su parte negativa, su proceso de aprobación de aplicaciones es lento, incómodo y en ocasiones arbitrario o atiende a los intereses de la propia Apple. Se deniega, por ejemplo, cualquier aplicación que sustituya una funcionalidad del teléfono y otras por razones bastante cuestionables, como paso en su día con Google Voice o con el VLC.

A partir del desarrollo y formidable éxito de Apple, el resto de plataformas se han afanado por construir tiendas similares lo más rápido posible, entendiendo que las aplicaciones tienen un valor fundamental a la hora de escoger una u otra plataforma. En este sentido el Android Market ha crecido bastante, con la ventaja de que la mayoría de sus aplicaciones son gratuitas, incluso aplicaciones que son de Pago en iPhone, como el WhatsApp o el Angry Birds, en Android son gratuitas.

El ser un sistema abierto y con una política de aprobación más ligera tiene también muchas otras ventajas, ha propiciado la aparición de miles de aplicaciones gratuitas para cualquier cosa que se te ocurra, de hecho, es muy destacable que aunque el número de aplicaciones sea mayor en el Apple Store, el número de aplicaciones gratuitas es mayor en el Android Market. Por todo esto, el Android Market es muy atractivo para los usuarios, pero no tanto para los desarrolladores, parece que el contenido de pago no funciona en Android. También hay que decir que este crecimiento un tanto descontrolado hace que sea un poco confuso navegar y encontrar aplicaciones.

En resumen, las aplicaciones son uno de los puntos más importantes a la hora de decantarse por una u otra plataforma. En este sentido Apple, a pesar de su excesivo control, parece disfrutar de un importante efecto pionero, que le lleva a ofrecer, más de 330.000. En segundo lugar, el Android Market, con un crecimiento importantísimo en número de usuarios y aplicaciones, tiene 206.000. En comparación, otras tiendas como la BlackBerry App World palidecen con alrededor de 26.000.

Globalizing Agile: la XP llega a Madrid este año

publicado el Miércoles, 6 de Abril de 2011 por: Paradigma Tecnológico
Etiquetas: - - | 1 comentario »

Del 10 al 13 de Mayo de este año 2011 se celebra la decimosegunda edición de la XP, la conferencia internacional sobre metodologías ágiles más conocida e importante a nivel global.

Y tenemos la suerte de que este año se celebrará en España, en concreto en Madrid, en el Hotel NH Parque de las Avenidas. Serán cuatro días con seis tracks a la vez llenos de charlas, talleres, open spaces, ponencias y presentaciones sobre tecnología y metodologías ágiles, donde gente de todo el mundo comparte ideas, proyectos y, sobre todo, conocimiento. Es el foro ideal para aprender cómo hacer mejor nuestro trabajo y cómo crecer como personas, y por eso seguimos sus pasos muy de cerca.

En Paradigma Tecnológico hace ya tiempo que estamos convencidos de que las metodologías ágiles son el camino a seguir para el desarrollo de proyectos. Principalmente porque fomentan una comunicación abierta y una relación de confianza con nuestros clientes, lo que garantiza el flujo de información que tanto necesitamos para crear buenas soluciones. Y finalmente porque nuestros equipos trabajan más cómodos y tranquilos: las metas a corto plazo y las estimaciones compartidas hacen que se comentan menos errores. Por eso apostamos en su momento por las metodologías ágiles. Y no nos arrepentimos en absoluto, ya que hace tiempo que recogemos los frutos que en su día sembramos: mejores resultados, mejor clima en nuestros equipos y, sobre todo, una mayor satisfacción de nuestros clientes.

Así que hemos querido aprovechar que la XP celebra esta edición en España para participar como patrocinadores Oro y compartir nuestros conocimientos y experiencia con una charla de Óscar Méndez, nuestro CEO. Óscar es el máximo responsable de evangelizar metodologías ágiles entre nuestros clientes, desde hace ya varios años, y de impulsarlas a nivel de proyecto entre nuestros equipos de trabajo. Seguro que estará a la altura esperada, tanto del resto de charlas, como de la conferencia en general.

Estamos contando los días para ir y poder disfrutar aprendiendo con tanta gente que comparte la misma visión enriquecedora del trabajo. Esperamos veros a todos en la XP2011.

Una API de realidad aumentada para Android

publicado el Viernes, 11 de Marzo de 2011 por: Oscar Ferrer
Etiquetas: - - - | 21 comentarios »

Cada día son más las aplicaciones que hacen uso de la nueva tecnología de realidad aumentada.

Esta tecnología, que consiste en combinar elementos virtuales sobre una visión real del entorno físico, parece que ha llegado para quedarse y probablemente, dentro un plazo corto de tiempo, será algo más que habitual verla integrada en multitud de aplicaciones.

Las compañías tecnológicas conocen bien sus posibilidades y ya podemos ver ejemplos como Google Googgles o Nokia Point & Find.

Su implantación en los dispositivos móviles se está viendo acelerada por la rápida evolución de estos ya que la presencia de una cámara, un GPS y una brújula en combinación con una conexión de datos permite crear aplicaciones bastantes completas.

Si nos queremos lanzar a crear nuestra propia aplicación de realidad aumentada en Android hemos de saber que no tenemos porque empezar desde cero. La empresa austriaca Mobilizy ha creado una API que, junto con su ya conocida aplicación Wikitude, nos permite desarrollar aplicaciones de realidad aumentada para nuestro terminal.

Vamos a ver cómo dar los primeros pasos para crear nuestra aplicación de realidad aumentada en Android. Para el ejemplo se utilizará el entorno de desarrollo Eclipse.

Descargar la aplicación Wikitude

Uno de los requisitos para poder usar la vista de cámara de realidad aumentada es tener instalada y arrancada la aplicación Wikitude dentro de nuestro dispositivo. Si vais a probar sobre un terminal podéis descargarla desde el Android Market. Si en cambio queréis hacer las pruebas desde el emulador tendréis que conseguir el APK de modo extraoficial e instalarlo. Para esto último y una vez tengáis el paquete desde la consola debéis teclear:

adb install com.wikitude.apk

Además el AVD sobre el que vayáis a probar deberá tener simulado una tarjeta SD.
Una vez instalada es importante que arranquemos la aplicación para que cuando empecemos a desarrollar nuestra aplicación pueda acceder a la vista de la cámara. Para iniciar la aplicación esta ha de detectar una ubicación por lo que si vamos a probar desde el emulador tendremos que utilizar la simulación de GPS. Para ello mientras la aplicación se encuentra en la pantalla de “Loading” debéis lanzar coordenadas al emulador. Esto se puede hacer de dos formas:

  • A través del Eclipse: En la perspectiva DDMS de Eclipse, en la pestaña Emulator Control, encontraremos una sección llamada “Location Controls” donde podemos lanzar las coordenadas que deseemos.
  • A través de la consola: conéctate al emulador y lanza el comando geo fix. Por ejmplo:
    telnet localhost 5554
    geo fix -82.411629 28.054553
    

Es conveniente que lances repetidas veces las coordenadas hasta que la aplicación recoja alguna y arranque con ese posicionamiento.
Una vez hecho esto ya podremos probar nuestros desarrollos con la API de Wikitude. Vamos a ver ahora como hacer un ejemplo sencillo.

Descargar la API

Podemos descargarnos un Zip con los archivos necesarios aquí http://www.wikitude.org/en/developers Dentro de este ZIP vamos a encontrar:

  • wikitudearintent.jar (jar que contiene el API que vamos a utilizar)
  • documentación
  • ejemplos

Lo que vamos a necesitar para utilizar el API será el jar que habrá que incluir en el build path de nuestro proyecto.

Mi primera aplicación de AR

Para empezar creamos un nuevo proyecto Android.

Añadimos el jar con el API de Wikitude, wikitudearintent.jar. Para ello

Project-> Properties->Java Build Path -> Libraries -> Add external Jars.

Una vez hecho esto podemos empezar a escribir las primeras líneas. Para el ejemplo hemos creado una actividad (MiRealidadAumentada).

Los dos primeros objetos que vamos a utilizar y que nos proporciona la API son:

  • WikitudeARIntent: nos permitirá lanzar la vista de la cámara de realidad aumentada. En este objeto podemos almacenar todos los puntos de interés (POIs) que deseemos mostrar.
  • WikitudePOI: este objeto describe un POI que queramos mostrar.

Para comenzar crearemos un WikitudeARIntent que se lanzará al pulsar sobre el botón.

public class MiRealidadAumentada extends Activity {

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

Button b = (Button) findViewById(R.id.button1);

b.setOnClickListener(new OnClickListener() {

@Override

public void onClick(View v) {

launchARView();

}

});

public void launchARView() {

WikitudeARIntent intent = new WikitudeARIntent(this.getApplication(), null, null, true);

addPois(intent);

try {

intent.startIntent(this);

} catch (ActivityNotFoundException e) {

AbstractWikitudeARIntent.handleWikitudeNotFound(this);

}

}

private void addPois(WikitudeARIntent intent) {

// Añadir puntos de interés

}

}

Los parámetros necesarios para el constructor serían:

WikitudeARIntent (Application application, String applicationKey, String developerName, boolean debugMode)

Los argumentos applicationKey y developerName se utilizan cuando has registrado vuestra aplicación a través de la página Mobilizy. Si rellenáis el formulario de registro te enviarán por correo una API Key que podréis usar en vuestra aplicación y que os permitirá eliminar la marca de agua de la vista de cámara.

Para obtener esta API key lo podéis hacer a través de la siguiente página http://w4client.mobilizy.mobi/w4/jsp/keyGenerator.jsp

Como véis al objeto WikitudeARIntent se le han de añadir los Puntos de Interés que se van a querer mostrar. Para ello vamos a hacer uso del objeto WikitudePOI del que antes hablámos:

private void addPois(WikitudeARIntent intent) {

Resources res = getResources();

WikitudePOI poi = new WikitudePOI(40.441346, -3.785702,636, "Paradigma Tecnológico", "La empresa ágil");

poi1.setLink("http://www.paradigmatecnologicom.com/");

poi1.setIconresource(getResources.getResourceName(R.drawable.icon));

intent.addPOI(poi);

}

Con esto ya podremos probar nuestra primera aplicación en un dispositivo real o en el emulador. Si vais a probar sobre este último podéis simular el movimiento del dispositivo con las teclas 1-6 del teclado numérico y para poner la vista horizantal recordad que podéis hacerlo con Ctrl+F11. De todas maneras os adelanto que depurar con el emulador es bastante incómodo ya que la simulación no funciona todo lo fluido que nos gustaría.

Cuando arranquemos la aplicación se mostrará nuestra primera pantalla con el botón que arrancará la vista de AR.

Vista de inicio de nuestra aplicación de realidad aumentada

Al pulsar sobre el icono del POI que hemos agregado se desplegará debajo una ventana con la información que hemos incorpora objeto.

Realidad aumentada en un POI concreto

Además de esta información podemos añadir un botón de detalles y personalizar la acción que queremos que haga al pulsar sobre él. Para ello debemos escribir

poi1.setDetailAction("wikitudeapi.mycallbackactivity");

y configurar en el Manifest la actividad que se lanzará

<activity android:name=".MiCallbackActivity"

android:theme="@*android:style/Theme.Translucent.NoTitleBar" >

<intent-filter>

<action android:name="wikitudeapi.mycallbackactivity" />

<category android:name="android.intent.category.DEFAULT" />

</intent-filter>

</activity>

Un ejemplo de implementación de una actividad puede ser un diálogo que muestre información extra asociada al POI.

En ella recuperamos el ID del POI seleccionado gracias al Extra que te proporciona el API de wikitude

this.getIntent().getIntExtra(WikitudeARIntentHelper.EXTRA_INDEX_SELECTED_POI, -1);

En el ejemplo hemos hecho la lista con los POI accesible desde cualquier punto de la aplicación incluyéndolo en una clase que herede de Application pero siempre se pueden utilizar otros métodos para recuperarlos.

Os dejo abajo el código de ejemplo para la actividad que muestra el siguiente diálogo cuando pulsemos sobre el botón “Details”.

public class MiCallbackActivity extends Activity {

private static final int POI_CLICKED = 1;

private static final int NO_POI = 2;

private int poiId;

private List<WikitudePOI> pois;

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

pois = ((MiAplicacion) this.getApplication()).getPois();

poiId = this.getIntent().getIntExtra(WikitudeARIntentHelper.EXTRA_INDEX_SELECTED_POI, -1);

if (pois != null && poiId != -1) {

this.showDialog(POI_CLICKED);

} else {

this.showDialog(NO_POI);

}

}

@Override

protected Dialog onCreateDialog(int id) {

AlertDialog.Builder builder = new AlertDialog.Builder(this);

switch (id) {

case POI_CLICKED:

String title = pois.get(poiId).getName();

builder.setTitle("Información sobre: " + title);

builder.setMessage(pois.get(poiId).getIconuri());

builder.setPositiveButton("OK", new DialogInterface.OnClickListener() {

public void onClick(DialogInterface dialog, int whichButton) {

}

});

break;

case NO_POI:

builder.setTitle("No existe POI asociado");

builder.setMessage("Pulse sobre un icono en la vista de cámara para obtener más información");

builder.setPositiveButton("OK", new DialogInterface.OnClickListener() {

public void onClick(DialogInterface dialog, int whichButton) {

}

});

break;

}

return builder.create();

}

Espero este API sirva de revulsivo para aquellas personas que quieran profundizar un poco más en la programación en Android y la Realidad Aumentada. Si alguno lo había pensado alguna vez pero veía complicado empezar con la vista de cámara y la implementación de las capas este API salvará ese primer escalón.

Android vs iPhone (I): Historia y Estrategia

publicado el Martes, 1 de Marzo de 2011 por: José Ignacio Herranz
Etiquetas: - - - - | 7 comentarios »

Hemos llegado a un punto en cual el sistema operativo es más importante que el propio dispositivo, la pregunta hace unos años hubiera sido quién es el mejor fabricante de teléfonos, pero hoy el debate es iPhone vs Android, aunque sería más correcto decir iOS vs Android.

Inicio aquí una serie de post en la que trataré de comparar ambas plataformas a todos los niveles: estrategia, stores, terminales, aplicaciones, usabilidad…

Vamos primero con la historia y la estrategia de ambos sistemas:

En 2007 Apple lanzó su primer iPhone, con iOs e iPhone Apple creó un tándem ganador, vendiendo en el mismo paquete Software más Hardware, una formula que siempre le ha funcionado. Este lanzamiento supuso un antes y un después en el mundo de la movilidad a todos los niveles, fue un salto tan grande que hasta finales de 2009 no comenzaron a salir teléfonos Android que le hicieran sombra.

Viéndolo con perspectiva las caracteristicas del primer iPhone se han establecido como un estándar dentro de la comunidad de móviles. Una pantalla táctil enorme, pocos botones, diseño y funcionalidad por encima de todo. Hasta hace unos años no estaba muy claro cuál era el futuro en los terminales móviles, pero fue llegar Apple y marcar un poco el camino lógico que aún nadie había marcado.

En 2010 salió una nueva versión del iPhone siguiendo con su estrategia de vender hardware y software juntos e intentando diferenciarse por el diseño y la usabilidad. Este terminal no ha supuesto una revolución como su predecesor pero incluyó una serie de mejoras necesarias, ya que la competencia comenzaba a superar en funcionalidades a su primera versión.

Google por su parte, que inicialmente parecía que iba a seguir la misma estrategia de Software+Hardware (todos recordamos la especulación que hubo respecto al supuesto gPhone), se centró finalmente en el software y lanzó también en 2007 Android, un sistema operativo especifico para móviles. Con esta estrategia podría entrar al mercado con cualquier fabricante, pero a la vez afrontaba un gran reto: crear desde cero un sistema operativo atractivo y competitivo para no morir aplastado por las compañías que tenían cuota, prestigio y fuerza. Google apostó fuerte creando una plataforma abierta en la que volcó toda su experiencia y dio plena libertad a las compañías para tomar lo que quisieran, siempre que respetasen el núcleo del trabajo de Google.

No quería un gPhone, quería miles de ellos y lo ha conseguido. Muchos fabricantes de terminales están adoptando Android porque han visto la oportunidad de reducir costes adoptando un producto de calidad. Android da valor a sus teléfonos y mejora la competitividad de sus empresas y productos. La gente ya no se compra un Motorola o un HTC, se compran un teléfono con Android.

De esta forma Android ha crecido muy rápidamente, hasta convertirse en una solida alternativa al iPhone.

Veamos ahora los modelos de negocio:

El modelo de negocio de Apple no se basa únicamente en la venta de terminales sino que también se llevan un porcentaje de todo lo que le rodea: aplicaciones, música, accesorios,… Sin duda una de las mejores cosas que tiene el iPhone es todo lo que ha construido a su alrededor. Comprar un iPhone no es solo comprar un teléfono, es prácticamente una relación contractual con el mundo Mac, para muchos esto es una ventaja pero otros solo buscan un teléfono.

Por su parte la estrategia de Google con Android es la publicidad, de hecho la gente que piensa que Google es un buscador se equivocan, Google es una empresa de publicidad. Están convencidos de que el móvil tiene muchísima importancia ahora mismo y tendrá más aún en los próximo años. El millonario negocio de la publicidad móvil solo esta empezando y Android no es más que una forma de posicionar los servicios publicitarios de Google de forma prioritaria, su buscador, sus mapas con anunciantes geolocalizados etc.

Parece que la cosa se pone interesante para 2011 con una nueva versión del iPhone y un montón de nuevos terminales con Android anunciados ¿Como veis el futuro? ¿Que sistema os gusta más?

Spring social

publicado el Lunes, 21 de Febrero de 2011 por: Federico Caro
Etiquetas: - - - - | 4 comentarios »

Estas últimas semanas he estado preparando la charla en Spring IO del 2011. Llevo siguiendo la pista a proyectos tan interesantes como Spring Data, Spring Mobile, Spring Roo, Spring integration, etc.

Pero, finalmente todas estas temáticas estaban planificadas por algún otro ponente, con lo que revisé los proyectos más novedosos de Spring, encontrándome con Spring Social.

Aunque el proyecto está en un estado muy embrionario y no existe mucha documentación al respecto, lo cierto es que ofrece una funcionalidad básica, pero que a la vez abre el abánico de numerosas posibilidades para poder integrarnos con las principales redes sociales: Twitter, LinkedIn, Facebook, Tripit…

Quizás la mayor carencia que sufra estas primeras versiones de Spring Social es que no han incoporado la integración con OAuth y se debe hacer con una librería externa (la más recomendable Scribe). Pero claro, para los iniciados, debería empezar por definir qué es esto de OAuth.

OAuth es un estándar que permite un sistema de autenticación delegada. El protocolo presenta los siguientes conceptos básicos:

  • Service Provider: Es el site, web-service o servicio en general donde se localizan los recursos restringidos (y que por tanto hay que proteger mediante un sistema de autenticación/autorización). El protocolo no obliga a que el Service Provider sea adicionalmente el servicio de identidad, con lo que puede usar su propio mecanismo para realizar la autenticación de los usuarios.
  • Usuario. El usuario es el actor principal dentro de OAUTH y es la persona que dispone de recursos privados que no quiere hacer público en el Service Provider, pero que quiere compartir con otro site/sistema.
  • Consumer: Se trata de la aplicación que está accediendo al recurso privado del usuario. Es por tanto, dicha aplicación la que mediante los permisos otorgados por el usuario el que accederá finalmente al recurso.
  • Recursos protegidos: Aquellos recursos que son privados, y para los que se le otorgan permisos al Consumer explícitamente para que proceda a procesarlos adecuadamente: fotos, documentos, contactos, …
  • Tokens: Dentro del protocolo se usan tokens como sustituto a las credenciales del usuario. Se usan técnicas de Firma Digital (par de claves pública-privada, algoritmos de hashing, etc..) para cifrar la información asociada al token y para garantizar la identidad de la persona/sistema que realiza la petición (Usuario/Consumer). Dentro del protocolo hay dos tipos de tokens: Request y Access. Uno asociado con el Consumer y otro asociado con el Usuario. A continuación entramos en detalle.

Para aclarar los conceptos pongamos un ejemplo. Supongamos que estamos desarrollando un servicio de impresión de fotos y queremos que el usuario pueda imprimir las fotos alojadas en un sistema como Flickr.

Con este escenario, el ServiceProvider sería Flickr, puesto que es el sistema donde están los recursos protegidos (en nuestro caso, fotos). El rol de Consumer sería la aplicación de impresión de fotos, el usuario sería la persona que quiere imprimir unas fotos de su cuenta de Flickr, pero no quiere que la aplicación de impresión conozca sus credenciales, incluso no quiere tener unas credenciales específicas en este site. Los recursos protegidos serían las fotos alojadas dentro de Flickr.

Veamos el detalle del flujo del protocolo.

OAUTH: Flujo de autenticación

Normalmente hay un paso previo, que no aparece en el diagrama y que consiste en la necesidad de registrar la aplicación (Consumer) en el Service Provider, proceso que te devuelve un par de valores ConsumerKey y Consumer Secret. Básicamente estos dos datos se comportan como una clave pública y una clave privada en un proceso de firma digital. De hecho como se puede ver en el detalle de parámetros de las distintas peticiones, en algunas de ellas se pasa la clave pública (Consumer Key). Puesto que la clave privada es compartida entre el Consumer y el Service Provider, éste forma parte de la signature incluida en el Token de Petición. Como en cualquier proceso de firma electrónica, esta clave privada será usada en el destino para comprobar la veracidad/integridad de la petición.

A continuación, comentamos los datos más importantes del flujo expuesto:

En la primera petición (A), como se puede ver el Consumer al custodiar las claves Consumer Key y Consumer Secret, usa estas llaves para enviar una petición al Service Provider para que éste identifique el sistema que quiere realizar la petición. Destacar que en el protocolo Auth, es un proceso de autorización en el que interviene básicamente Service Provider, Consumer y Usuario, produciéndose la autenticación en dos pasos básicos: uno en el que se autentica el Consumer (aplicación que quiere obtener recursos protegidos, pero que delega la autenticación en el service Provider). Posteriormente hay una segunda etapa de autenticación donde el usuario debe autenticarse en el sistema para poder ser identificado correctamente. A partir de esta segunda fase y mediante el mecanismo de tokens que estamos definiendo, es posible que el Consumer pueda acceder al recurso protegido (puesto que el usuario le ha dado los permisos oportunos).

Centrándonos ahora en la petición (A), se ve que dentro de la petición se incluye la clave pública del consumer (identifica al consumer), además se genera un campo signature que básicamente consiste en construir una cadena de caracteres base (normalización de la petición http incluyendo el método http, parámetros, URL callback, adicionalmente se usa la clave privada para generar finalmente la signature), la cual va incluida dentro de la petición. Como hemos comentado adicionalmente dentro de la petición se indica la URL de callback, es decir la URL del Consumer a donde se debe redirigir el flujo una vez el usuario se ha autenticado en el Service Provider.

Una vez construida la petición con sus parámetros, el Service Provider realiza el correspondiente proceso de autenticación (procesamiento del parámetro signature) con la clave privada compartida, y garantizando por tanto, que la petición no ha sido alterada y comprobando mediante este algoritmo matemático que el peticionario de la petición es quien dice ser. Tras comprobar la integridad/veracidad de la petición, el Service Provider contesta al Consumer con la clave pública y privada que el usuario deberá usar en el proceso de autenticación de la segunda etapa del protocolo).

Una vez realizado este proceso, el Consumer redirige al Service Provider para que tenga lugar el proceso de autenticación del usuario. Es en este paso, donde el usuario se autentica usando las credenciales del Service Provider. Si para autenticación se produce de un modo correcto, el Service Provider manda el token y un verificador que el Consumer usa para construir el segundo de los tokens (AccessToken). Este token será el que lleva incorporado la autorización implícita del usuario y por tanto, el que concederá al Service Provider la posibilidad de acceder a los recursos privados del Service Provider. Normalmente en el proceso de autenticación del usuario, se pueden otorgar diferentes permisos (acceso a datos personales del usuario, acceso a las fotos, posibilidad de enviar correo electrónicos al usuario, etc..). Es en el token donde reside el proceso de autenticación delegada, donde el usuario delega al Consumer la posibilidad de poder acceder a sus recursos. El protocolo permite que este token sea invalidado en cualquier momento, disponga de un tiempo de vigencia, etc.

Una vez el Consumer dispone del token de acceso, se produce un intercambio similar al realizado para el Request Token, finalizando con el acceso por parte del Consumer a los recursos privados del usuario.

Como he comentado al inicio del post, Spring Social no incluye una integración completa con el protocolo OAuth, quizás su mayor defecto en estas primeras versiones, con lo que es necesario utilizar una librería como Scribe para poder completar la integración con las principales redes sociales.

Spring Social básicamente incluye una serie de Templates (LinkedInTemplate, FacebookTemplate, TwitterTemplate, …) que nos ofrecen acceso a datos de las respectivas redes sociales. Además incluye clases para firmar las distintas peticiones siguiendo la especificación definida por el protocolo OAuth. Finalmente, tiene una librería de tags para realizar la integración con Facebook y una integración con Spring MVC (ArgumentResolver) que permite realizar el binding entre parámetros de la petición HTTP y argumentos de un controlador de SpringMVC, para aislar al programador de las particularidades de la integración con Facebook (obtención del Token de Acceso y el identificador de usuario de Facebook).

Conclusiones

Aunque, inicialmente el proyecto es muy pequeño (unas decenas de clases), y en un primer análisis puede parecer poca la funcionalidad que ofrece, sinceramente se nos abren amplias posibilidades funcionales que permiten enriquecer nuestras aplicaciones obteniendo información de las principales redes sociales. De hecho, esta última semana he conocido http://lanyrd.com/ y al principio, aparte de que me encantó la idea y la tienen implementada con muchísima calidad, no dejaba de ser una aplicación donde se ofrecía información de los principales eventos del mundo organizado por año, por topic, etc. Pero curiosamente descubrí la integración que tenía con Twitter (siguiendo el protocolo OAUth anteriormente mencionado) y cuando finalizo el proceso de autenticación, me apareció el evento en el que participaba, los eventos que mis seguidores estaban interesados, … En definitiva, se personalizó el site en base a la información que proporciona Twitter. Es un ejemplo de que, a veces, las cosas sencillas permiten un abanico funcional muy interesante, y más si tenemos en cuenta la orientación social del actual panorama web. Y finalmente, si Spring me ofrece una API que permite integrarme de una manera homogénea a las principales redes sociales, mejor que mejor.

Razones por las que ir (y no ir) al taller de DSLs en Groovy

publicado el Viernes, 11 de Febrero de 2011 por: Alberto Vilches
Etiquetas: - - | 4 comentarios »

Este viernes en el Spring IO, a las 15:00, daré un taller de creación de DSLs en Groovy.

Será parecido al seminario que dí el año pasado sobre DSLs, solo que está vez será, principalmente, práctico en vez de teórico. La idea es que todos empecemos a programar siguiendo unos pasos definidos para que sea más interesante y los conocimientos se aprendan. Sin embargo, el Spring IO de este año está divido en tres tracks, de manera que tenemos que elegir a qué charlas vamos a ir porque siempre nos vamos a perder algo. A continuación unas razones porqué deberías ir (o no) a mi taller:

Por qué ir:

  1. Porque vamos a dar una charla rápida y explicar qué es un DSL.
  2. Porque vamos a meternos en las tripas de Groovy ver qué nos ofrece para crear DSL.
  3. Porque vamos a jugar con IntelliJ IDEA 10 Community.
  4. Porque vamos a hacer un DSL para crear PDFs, y hasta la fecha no hay ninguno: puedes acabar el DSL en tu casa y después publicarlo y ser famoso.
  5. Porque según lo vayamos creando, saldrán algunos problemas típicos y tendremos que refactorizar.
  6. Porque el taller está dividido en pasos claramente separados donde se ve la evolución del DSL que vamos a crear (y está la solución en el paso siguiente, por si alguien se atasca).
  7. Porque veremos algunos trucos de Groovy interesantes que tengo preparados.
  8. Porque podremos (¡debemos!) preguntar y hablar y opinar y dar ideas sobre el DSL y podremos probarlo sobre la marcha.
  9. Porque vamos a programar.

Y por qué no ir:

  1. Porque a la misma hora hay cuatro charlas interesantes, de las que destaco especialmente la de “Tunning your Grails applications” de Peter Ledbrook.
  2. Porque las otras tienen bastante buena pinta también: será interesante ver la experiencia de Juan Manuel y Michel Jensen enseñando Grails en la Universidad de Cadiz ¡qué suerte tienen sus alumnos!
  3. Porque no conoces (¡como yo!) ni Spring Hadoop ni Summer (la librería de HTML5 para Java y Scala) y te apetece saber qué son y como funcionan.
  4. Porque vienes a Spring IO por Spring y Java, y no te interesa Groovy o los DSLs.
  5. Porque a las 15:00 no perdonas nunca la siesta. ;)
  6. Y porque vivo en Madrid, y sabes que si hay suficiente gente interesada podremos repetir el taller cuando quieras: seminarios.

¡Nos vemos en el Spring IO!

Paradigma patrocina la conferencia Spring I/O 2011

publicado el Miércoles, 9 de Febrero de 2011 por:
Etiquetas: - | 7 comentarios »

Después del gran éxito del año pasado, Spring I/O vuellve en 2011 con más fuerza. En la presente edición vamos a tener dos días llenos de novedades y sorpresas con todo lo relacionado con Spring, Groovy/Grails y Cloud.

Una oportunidad única de compartir conocimiento con expertos y profesionales.

El evento, organizado por Javahispano, se celebrará los días 17 y 18 de febrero en Madrid en la Escuela Politécnica Superior de la Universidad CEU San Pablo en Boadilla del Monte.

Este año va a tener tres “tracks” en paralelo: dedicados a Spring, a Groovy / Grails y a talleres prácticos. Entre las estrellas invitadas destacan Juergen Hoeller, cofundador de Spring y el principal commiter y responsable de la arquitectura del framework desde 2003; Graeme Rocher, fundador de Grails; Andres Almiray, cofundador y líder del proyecto Griffon o  Hans Dockter, creador de Gradle. Este año, debido a los invitados internacionales, habrá algunas sesiones en inglés.

Los encargados de representar a Paradigma junto a este elenco de expertos serán:

  • Federico Caro impartiendo la conferencia “Spring Social” el jueves 17 de febrero, en el que conoceremos los detalles técnicos de la especificación del protocolo OAuth 1.0 (implementado por las principales redes sociales) como modelo de autenticación delegada.
  • Alberto Vilches impartiendo el Taller de Creación de DSLs con Groovy (Español) el viernes 18 de febrero.

Este evento, a diferencia de todos los organizados por javaHispano hasta la fecha, no es completamente gratuito. El precio del registro es de 20€ que dan acceso a los dos días de conferencia e incluye la comida y coffee-breaks. No hay que dormirse, que ya llevan más de 150 inscripciones.

Os animamos a que asistais para poder disfrutar de dos días llenos de contenidos interesantes, relacionaros con profesionales con vuestras mismas inquietudes y estar al tanto de las últimas novedades.

Nos vemos en el Spring I/O 2011.

Nuevo plugin TwitterChecker para Grails

publicado el Miércoles, 26 de Enero de 2011 por: Alberto Vilches
Etiquetas: - - - - | 5 comentarios »

TwitterChecker accede a tu cuenta de Twitter (usando Twitter4J y OAuth) y comprueba si hay:

Nuevos followers y nuevos unfollows (gente que te deja de seguir).
Nuevos RTs de tus twits realizados por otros usuarios.
Nuevas menciones realizadas por otros usuarios.

TwitterChecker se encargará de comprobar periodicamente esta información y lanzar eventos programados. En estos eventos se pueden enviar [...]

TwitterChecker accede a tu cuenta de Twitter (usando Twitter4J y OAuth) y comprueba si hay:

  • Nuevos followers y nuevos unfollows (gente que te deja de seguir).
  • Nuevos RTs de tus twits realizados por otros usuarios.
  • Nuevas menciones realizadas por otros usuarios.

TwitterChecker se encargará de comprobar periodicamente esta información y lanzar eventos programados. En estos eventos se pueden enviar mensajes directos al nuevo usuario que te sigue, publicar en tu timeline o simplemente guardar la información en base de datos o enviar emails (en caso de unfollows por ejemplo).
Además, el plugin accede periodicamente a tu timeline, menciones y RTs realizados a ti y los guarda en una caché para que los puedas mostrar con una taglib en tus gsp.

Requisitos:

  • Quartz plugin 0.4.1 o superior.
  • Grails 1.2.0 o superior.
  • Tomcat Julli 6.0.16 o superior.

Y una cuenta de Twitter, claro.

El plugin incluye la librería twitter4j-core-2.1.7.jar (la última versión estable)

Instalación

grails install-plugin twitter-checker

Si no estas desplegando el War en un Tomcat, es posible que necesites el jar tomcat-juli-6.0.16. Si estás usando Grails 1.3+ puedes añadirlo en el fichero BuildConfig.groovy:

dependencies {
    runtime 'org.apache.tomcat:juli:6.0.16'
}

La instalación del plugin creará los siguientes archivos dentro de tu proyecto:

  1. controllers/twitterChecker/TwitterCheckerController.groovy
  2. views/twitterChecker/demo.gsp
  3. views/twitterChecker/index.gsp
  4. views/twitterChecker/_twitFromMe.gsp
  5. views/twitterChecker/_twitFromOther.gsp
  6. src/groovy/twitterChecker/DefaultTwitterCheckerListener.groovy

Configuración

1 Primero necesitas crear una aplicación en Twitter en esta dirección: http://dev.twitter.com/apps/new con estas opciones: “Default access type” a “read&write” y “Application type” a “client”. Una vez creada la aplicación, deberás apuntar el consumer key y el consumer secret.

2. Añade el siguiente fragmento en el archivo Config.groovy de tu aplicación Grails

grails.spring.bean.packages = ["twitterChecker"]
twitterChecker {
    oauth.consumerKey = "AQUI VA EL CONSUMER KEY DE LA APLICACION QUE HAS CREADO EN TWITTER"
    oauth.consumerSecret = "Y AQUI VAL EL CONSUMER SECRET"
    storageFolder = "/ruta/al/directorio/donde/twitter/checker/guardara/sus/archivos"
}
  • grails.spring.bean.package contiene el paquete donde está la clase DefaultTwitterCheckerListener.groovy. No modifiques este valor incluso si renombras la clase, solo es necesario modificarlo si mueves la clase de sitio.
  • outh.consumerKey and oauth.consumerSecret: pon aquí los valores consumer key y consumer secret de tu aplicación de Twitter.
  • storageFolder: el plugin necesita una ruta donde guardar 4 archivos binarios que se corresponden con los followers, menciones y RT.

3. Autoriza tu cuenta de Twitter con la aplicación de Twitter que acabas de crear.

  • Arranca ahora la aplicación Grails (ignora los errores de OAuth que verás en los logs) y visita la dirección del controlador TwitterCheckerController en tu navegador: http://localhost:8080/yourAppName/twitterChecker
  • Sigue las instrucciones, que son: obtener el nuevo pin (logarte en twitter, hacer click en “allow acces”), introducirlo en el formulario y hacer click en submit.
  • Si todo ha ido bien, la aplicación te mostrará un fragmento de código con los valores accountId, token y tokenSecret que deberás añadir en tu Congig.groovy

4. Reinicia tu aplicación y visita de nuevo TwitterCheckerController en tu navegador: http://localhost:8080/yourAppName/twitterChecker. Verás una página con tu timeline, menciones y RTs (si estás intrigado, puedes ver el contenido de esta página en views/twitterChecker/demo.gsp)

5. Una vez configurada tu aplicación con tu token y tokenSecret, puedes borrar el controlador TwitterCheckerController.groovy y las vistas twitterChecker/demo.gsp y twitterChecker/index.gsp. Pero no borres las vistas _twitFromMe.gsp y _twitFromOther.gsp, ya que son utilizadas por los taglibs (puedes modificarlas, pero no borrarlas)

Mostrar timeline, menciones y RTs

Para mostrar tu timeline, menciones y RTs en tu aplicación puedes usar estas tags (como puedes ver en la vista demo.gsp):

<twitterChecker:timeline max="10"/>
<twitterChecker:mentions max="200"/>
<twitterChecker:rts/>

(El parámetro max es opcional y puedes usarlo en cualquiera de las tres tags)

El plugin refrescará esta información cada 15 minutos y el taglib mostrará siempre una versión cacheada de estos datos, de esta manera se pueden utilizar tantas veces como se deseen estos taglib en tu aplicación. Se usarán las vistas _twitFromMe.gsp y _twitFromOther.gsp que están en tu propio proyecto, por lo que puedes modificarlas si lo necesitas.

Eventos

Cada 15 minutos, el plugin chequeará tu cuenta de Twitter en busca de nuevos followers, unfollows, menciones y RT. Puedes abrir la clase src/groovy/twitterChecker/DefaultTwitterCheckerListener.groovy que está copiada en tu propio proyecto y modificar los closures onNewFollowers, onUnfollows, onMentions y onRetweets que serán los que se ejecutarán cada vez que el plugin detecte un cambio en tu cuenta.

Puedes modificar cada cuanto tiempo el plugin chequeará tu cuenta de Twitter añadiendo estos valores en tu Config.groovy:

twitterChecker {
    checkTimelineEvery = 5  // 5 minutes
    checkMentionsEvery = 30 // 30 minutes
    checkRetweetsEvery = 30 // 30 minutes
    checkFollowersEvery = 120 // 2 hours
}

ATENCIÓN: Recuerda que Twitter limita el acceso a su Api a 350 peticiones por hora y aplicación. Cada vez que el plugin chequea tu timeline, menciones, rts y followers es una request, por lo que un valor de 15 minutos implica 16 peticiones en una hora. Bajar este tiempo puede incrementar drasticamente el número de peticiones a la hora. Para más información consulta: http://dev.twitter.com/pages/rate_limiting_faq

Usando la api the Twitter4J

El plugin proporciona el servicio TwitterCheckerService que actua igual que una clase twitter4j.Twitter ya preconfigurada gracias a la anotación @Delegate de Groovy. Es decir, este servicio tiene los mismos métodos que la clase twitter4j.Twitter (aunque si abrimos la clase no los veamos). Para ampliar información sobre los métodos de esta clase con los que enviar mensajes directos, publicar en el timeline, etc: http://twitter4j.org/en/javadoc-latest/core/twitter4j/Twitter.html

Además, el servicio TwitterCheckerService tienes estas nuevas propiedades: cachedMentions, cachedTimeline y cachedRts que serán usadas por las taglibs para renderizar las vistas.

Puedes usar este servicio desde cualquier controlador, por ejemplo:

class MyController {

    def twitterCheckerService

    def updateStatus = {
        // use the http://twitter4j.org/en/javadoc-latest/core/twitter4j/Twitter.html#updateStatus(java.lang.String) method
        def status = twitterCheckerService.updateStatus("Test from grails TwitterChecker plugin")
        ...
    }

    def readTimeline = {
        // use the cached version of the user timeline
        println twitterChecerService.cachedTimeline
        // get a new fresh version of the user timeline http://twitter4j.org/en/javadoc-latest/core/twitter4j/Twitter.html#getUserTimeline()
        def timeline = twitterCheckerService.userTimeline
        ...
    }
}

Crear un nuevo checker que consulte y cachee información de Twitter

Por ejemplo, si quieres mostrar en tu aplicación los resultados de buscar el tag #grailsx en Twitter, puedes crearte un nuevo job en Quartz que consulte esta información y la cachee para después mostrarla.

class CheckSearchQueryJob  {

    def yourOwnService // Servicio donde se desea guardar la información cacheada

    static triggers = {
        simple(name: 'CheckSearchQueryJob',
        repeatInterval: 15*60*1000) // Every 15 minutes
    }

    TwitterCheckerService twitterCheckerService
    def execute() {
        def resultQuery = twitterCheckerService.search(new twitter4j.Query("#grailsx"))
        yourOwnService.cachedQuery = resultQuery // Guardar la información en un servicio
    }
}

Después solo tienes que acceder al atributo yourOwnService.cachedQuery desde tus vistas.

Resolución de problemas

Si obtienes esta exepción:

Caused by: 401:Authentication credentials were missing or incorrect.
{"error":"Read-only application cannot POST","request":"\/1\/statuses\/update.json"}

Es porque tu aplicación es solo de lectura y no te permite actualizar tu estado ni enviar mensajes.

  1. Ve a http://dev.twitter.com, edit your app details y asegúrate de que se ha elegido “read-write” en access type.
  2. Visita tu cuenta de Twitter y revoca los permisos a tu aplicación en in http://twitter.com/settings/connections.
  3. En tu aplicación Grails, quita el token y tokenSecret actuales de tu Config.groovy, reinicia y vuelve a solicitar un pin para dar permisos a tu aplicación (es decir, repite todo el proceso de autorización).

Nuestro Blog

Autor: Paradigma - Jueves, 27 de Octubre de 2011

Es necesario un cambio de Paradigma, un nuevo modelo de Web.

La Web 4.0 propone un nuevo modelo de interacción con el usuario más completo y personalizado, no limitándose simplemente a mostrar información, sino comportandose como un espejo mágico que de soluciones concretas a las necesidades el usuario.

Ver más


Comment spam by theme