EnglishEnglishEspañolEspañol

Blog de Paradigma Tecnológico

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 [...]

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).

TDD como metodología de diseño de software

publicado el Lunes, 17 de enero de 2011 por: José Ignacio Herranz
Etiquetas: - | 18 comentarios »

TDD o Test Driven Development es una práctica de programación que consiste en escribir primero las pruebas (generalmente unitarias), después escribir el código fuente que pase la prueba satisfactoriamente y, por último, refactorizar el código escrito. Con esta práctica se consigue entre otras cosas: un código más robusto, más seguro, más mantenible y una mayor rapidez en el desarrollo. En este post voy a centrarme solamente en como TDD afecta al diseño de software, si queréis más información, hay una introducción bastante buena en la Wikipedia y Carlos Ble tiene disponible online un libro muy completo.

Antes pensaba que TDD era una forma de programar que consistía en generar primero los test unitarios antes que la propia aplicación, con lo que conseguías desarrollos de más calidad a costa de disminuir la productividad. Creo que es la misma idea que tiene la mayoría de la gente que conoce por encima esta práctica, pero que no se anima a utilizarla. Sin embargo, últimamente he estado profundizando un poco en TDD y me he dado cuenta que esto no es cierto, TDD no es para hacer pruebas, es una práctica que envuelve el desarrollo en su conjunto, especialmente el diseño de Software. De hecho, algunos dicen que su última letra, debería significar diseño y no desarrollo. Es decir, diseño orientado por las pruebas.

TDD Fue creado por Kent Beck (quien también inventó Extreme Programming y JUnit), y en esencia, es un proceso a seguir, lo cual ya lo hace diferente a un simple enfoque de pruebas primero:

Test driven development

Fuente de la imagen: Wikipedia

Este ciclo también se lo conoce como rojo (hacer que la prueba falle), verde (hacer que la prueba pase) y refactor. Aunque al principio pueda parecer muy parecido a un enfoque de probar primero, al combinarlo con practicas de desarrollo ágil, TDD toma un enfoque mucho más amplio, y cambia su atención de las pruebas al diseño. TDD está mucho más relacionado con el diseño emergente que con las pruebas, de hecho, que TDD genere una gran cantidad de pruebas es un efecto secundario positivo, pero no es su propósito final.

El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:

  1. El cliente escribe su historia de usuario
  2. Se escriben junto con el cliente los criterios de aceptación de esta historia, desglosándolos mucho para simplificarlos todo lo posible
  3. Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria
  4. Se comprueba que esta prueba falla
  5. Se escribe el código que hace pasar la prueba
  6. Se ejecutan todas las pruebas automatizadas
  7. Se refactoriza y se limpia el código
  8. Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando
  9. Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación

Vamos con un ejemplo practico de este ciclo:

  1. Supongamos que el cliente nos pide que desarrollemos una calculadora que sume números (es lo primero que se me ha ocurrido)
  2. Acordamos con el cliente que el criterio de aceptación sería que si introduces en la calculadora dos números y le das a la operación de suma, la calculadora te muestra el resultado de la suma en la pantalla
  3. Partiendo de este criterio, comenzamos a definir el funcionamiento del algoritmo de suma y convertimos el criterio de aceptación en una prueba concreta, por ejemplo, un algoritmo que si introduces un 3 y un 5 te devuelve un 8:
    public void testSuma() {
    	assertEquals(8, Calculadora.suma(3,5));
    }

    Este punto es para mi el más importante de TDD y que supone un cambio de mentalidad, primero escribo cómo debe funcionar mi programa y después, una vez lo tengo claro, paso a codificarla.

    Al escribir el test estoy diseñando cómo va a funcionar el software, pienso que para cubrir la prueba voy a necesitar una clase calculadora con una función que se llame suma y que tenga dos parámetros. Esta clase todavía no existe pero cuando la cree, ya se cómo va a funcionar. Este caso es muy trivial, pero muchas veces no sabemos exactamente qué clases hacer o qué métodos ponerle exactamente. Es más, muchas veces perdemos el tiempo haciendo métodos y clases que pensamos que luego serán útiles, cuando la cruda realidad es que muchas veces no se van a usar nunca. Con TDD sólo hacemos lo que realmente necesitamos en ese momento.

    Realmente es la forma natural de pensar, primero pensamos en Qué queremos hacer y después pasamos al Cómo, la diferencia es que con TDD el test ya queda escrito y se ejecutará cada vez que compilamos nuestro programa.

  4. Por supuesto, si intentamos pasar este test nos dará un error, porque la clase Calculadora aún no existe.
  5. Ahora pasamos a escribir el código de la clase, es fácil porque ya sabemos exactamente cómo se va a comportar:
    public class Calculadora {
    	public static int suma (int a, int b) {
    	int c = a + b;
    	return c;
    	}
    }
  6. Ahora ejecutamos la prueba y ya tenemos el código funcionado con la prueba pasada.
  7. Una vez todo este funcionando, pasamos a refactorizar y a eliminar código duplicado, este ejemplo es extremadamente sencillo, y en un caso real no haríamos tantos pasos para algo tan evidente, pero el código mejorado podría ser por ejemplo:
    public class Calculadora {
    	public static int suma (int a, int b) {
    	return a+b;
    	}
    }

    En ejemplos más complejos, según vayamos escribiendo más test, deberíamos buscar código duplicado y agruparlo en funciones o utilizar la herencia o el polimorfismo.

  8. Es importante pasar todos los test después de refactorizar por si nos hemos cargado algo.
  9. Ahora deberíamos volver al punto 3 con tests más complicados y repetir el proceso, por ejemplo, podíamos pasar a que el algoritmo admita sumar números decimales, etc.

Esta forma de trabajar es también muy buena para entender el código. Sabemos que la calidad del diseño de un software está también relacionada con el conocimiento del equipo de desarrollo en relación al dominio en cuestión. En este sentido, las pruebas son una muy buena forma de entender el código y su funcionamiento, muchas veces incluso mejor que la documentación.

También hay que decir que no todo es perfecto en TDD, cuando llegue el momento de crear un test sobre la interfaz de la calculadora la cosa se complica. Los puntos flojos que veo en TDD son:

  • Hay que utilizarlo y entenderlo bien para que sea realmente productivo, te ayuda a centrarte en lo importante y a no sobrediseñar, pero es importante saber refactorizar el código según vaya evolucionando para que sea consistente.
  • Pruebas sobre interfaces gráficas. Aunque hay soluciones parciales propuestas, para mi TDD solo funciona en la capa de negocio, no encaja con interfaces visuales.
  • Bases de datos. Hacer pruebas de código que trabaja con base de datos es complejo porque requiere generar unos datos conocidos antes de hacer las pruebas y verificar que el contenido de la base de datos es el esperado después de la prueba. Los objetos simulados (MockObjects) son otra opción, pero personalmente creo que se pierde tiempo con esto.

Conferencia “Agile Inception: creando un producto de forma ágil”

publicado el Miércoles, 12 de enero de 2011 por: Paradigma Tecnológico
Etiquetas: - | 2 comentarios »

El martes 18 de enero a las 19:00 en el Espacio CAMON de Madrid (Plaza de Moncloa I, Acceso por Princesa) se impartirá la conferencia “Agile Inception: creando un producto de forma ágil” a cargo de Roberto Gil y Pablo Pazos.

En esta conferencia, organizada por ADWE Madrid, aprenderemos a dar forma y conceptualizar un producto de forma ágil y sencilla. Entender los objetivos de dicho proyecto, conocer el alcance funcional que puede tener, realizar los primeros bocetos y el diseño inicial, y estimar la duración del mismo son aspectos fundamentales que han de trabajarse en colaboración con el cliente.

Las metodologías ágiles de desarrollo de software surgen como contrapartida a los métodos tradicionales basados en la planificación muy estructurada y estricta. Esta nueva manera de desarrollar proyectos, que gana adeptos día a día, deja a un lado la documentación enfatizando las comunicaciones cara a cara y dando autonomía y poder al equipo de desarrollo, con el objetivo de que todos los recursos se empleen en la creación de un software que satisfaga al cliente.

En esta conferencia abordaremos una parte teórica introductoria a la metodología del desarrollo ágil de software y luego un caso práctico en el que se llevará a cabo la simulación de la conceptualización de un proyecto real.

Apúntate aquí

¿Quién la imparte?

Roberto Gil del Sol es Scrummaster y responsable de arquitecturas en Paradigma Tecnológico, lleva 12 años trabando con Internet en los cuáles ha realizado tareas como administrador de sistemas Linux, programador Perl, Arquitecto Java y emprendedor.

Pablo Pazos es desarrollador web en Paradigma Tecnológico, experto en tendencias web y analista de nuevas metodologías de desarrollo ágil

Por qué debes diseñar la versión móvil antes que la versión Web

publicado el Lunes, 3 de enero de 2011 por: José Ignacio Herranz
Etiquetas: - | 7 comentarios »

Luke Wroblewski es un experto en diseño de interfaces que lanzó hace poco más de año la idea de “Mobile First”, que consiste en diseñar primero la versión móvil de una interfaz antes que la versión Web.

Para Luke diseñar primero la versión móvil tiene tres ventajas fundamentales:

  1. En Internet, a día de hoy, el móvil es más relevante que los ordenadores.
  2. Diseñar para móvil te obliga a centrarte en lo que es realmente importante. Al tener que diseñar para una pantalla tan pequeña hay que priorizar y centrarse en las tareas clave, por eso las Web que están diseñadas con la filosofía “Mobile First” son más usables y están más enfocadas al ROI.
  3. Las capacidades de un móvil son mayores que las capacidades de un ordenador (GPS, acelrómetro, cámara, pantalla táctil, …) diseñar primero la versión móvil te permite hacer uso de todas estas capacidades en lugar de restringir tu interfaz a las capacidades de un ordenador.

Seguramente muchos de vosotros no estáis de acuerdo con alguna de estas razones, pero yo creo que es un idea muy a tener en cuenta. Quizá a día de hoy es un poco aventurado decir que los móviles son más relevantes que los ordenadores en Internet, pero si que es cierto que muchos estudios indican que esto llegará muy pronto. De momento ya estamos en el punto en el que en muchos países hay más móviles que PC’s e incluso más móviles que personas. Con datos como este tiene mucho sentido que haya empresas que centren sus esfuerzos primero en el móvil, incluso la misma Google se muestra a favor de esta metodología.

Diseñar para dispositivos con pantallas “grandes” tiene una desventaja, te hace pensar muy grande muy rápido, y te da por tanto mucha libertad para confundir al usuario. Es muy fácil sobrecargar la página con cosas inútiles, presuponiendo que serán útiles para los usuarios. Si lo pensamos, las mejores páginas Web suelen ser las que tienen un diseño limpio y poco contenido en la home, solo lo más importante. Yo estoy de acuerdo con esta idea e incluso añadiría alguna razón mas a favor de mobile first:

  • Diseñar para móvil es mucho más divertido que diseñar para Web, porque te da muchas más posibilidades fuera de las típicas con html, css y javascript.
  • Diseñar para móvil es más difícil y supone un reto para los que se autodenominan expertos en diseño de interfaces.
  • Va mucho con las metodologías ágiles porque simplifica mucho las cosas, significa empezar por lo más básico para poco a poco ir construyendo.

Si no estas de acuerdo con este método, creo que al menos deberías tener en cuenta el móvil a la hora de platear tu Web. Es un error (aunque muy típico) construir primero la versión Web y después hacer una versión reducida para móvil, utilizando todo el contenido pero distribuido de otra forma. Con esta forma de trabajar, tu página no será adecuada para los móvile, ni aprovechará las capacidades exclusivas de los móviles que no existen en un PC. Y este error será aún más notable en los próximos años.

El móvil debe ser una parte fundamental de tu estrategia y tienes que tenerlo en mente desde el primer momento. Debes pensar desde el primer momento en funcionalidades que aprovechen las capacidades de los terminales y en una arquitectura que este preparada para que el contenido sea consumido desde diferentes dispositivos.

El móvil, tu futura tarjeta de crédito

publicado el Jueves, 9 de diciembre de 2010 por: José Ignacio Herranz
Etiquetas: - | 8 comentarios »

Hace unos días en una conferencia escuché una frase que se me quedó grabada: “a phone is not a phone”, refiriéndose a que los móviles de nueva generación son mucho más que un teléfono, son una cámara de fotos, un reproductor de música, un GPS, una Agenda electrónica y hasta una videoconsola portátil. Poco a poco los móviles van adquiriendo nuevas funcionalidades y van disminuyendo las ventas de reproductores mp3 o de navegadores GPS en favor de los móviles, que cada vez se usan menos para hablar por teléfono.

Se espera que antes de final de año salga una nueva versión del sistema operativo Android, apodada Gingerbread, que entre muchas otras cosas, contará con una funcionalidad muy interesante, soporte para NFC (Near Filed Communication).

La principal aplicación de esta tecnología es su uso para hacer pagos y que todo parece indicar que dentro de poco los móviles serán también nuestras tarjetas de crédito. Los consumidores simplemente tendrán que poner en contacto su móvil, a un lector parecido al de las tarjetas, habilitado en un punto de venta para realizar un pago. De esta forma, los consumidores podrán pagar con simple toque con el móvil, por lo que un usuario podrá salir de su casa con su teléfono y poco más. Si ya era fácil pasarse con la tarjeta, imaginaros con este sistema…

La tecnología NFC no es precisamente nueva, es una tecnología usada en móviles principalmente en Japón y en algunos terminales de Nokia para Europa. Sirve intercambiar información con otro terminal, pero solo cuando estos dos terminales están prácticamente tocándose (el alcance máximo es de unos 20cm). De primeras, no parece una tecnología muy potente, pero al tener un radio de acción tan pequeño se puede asegurar que la transferencia será “personal”, porque tendrás que sujetar tu terminal y acercarlo con otro terminal para que se comuniquen, siendo consciente de ello. Otra ventaja es que funciona de manera independiente a la señal del móvil, de tal forma que si el usuario se encuentra en el metro, donde a veces no hay cobertura, no tiene problema en utilizar este sistema.

La tecnología NFC se parece a la tecnología bluetooth, pero tiene una ventaja con respecto a ésta: el menor tiempo de configuración. Así, mientras que dos dispositivos NFC se conectan inmediatamente, la conexión entre dos dispositivos con bluetooth requiere de una serie de acciones manuales.

En la actualidad, más de 100.000 establecimientos comerciales en EE.UU. ofrecen lectores sin contacto que aceptan este tipo de transacciones en el punto de venta, incluyendo restaurantes de comida rápida, gasolineras, tiendas, farmacias, máquinas expendedoras, … Y ya hay empresas de tarjetas de crédito que han comenzado a operar con esta tecnología

Parece que esta tecnología será una de las modas de 2011, ya que además de los que os comentaba de Android, Apple y RIM están también trabajando en torno a esta tecnología.

Grails: añadiendo propiedades dinámicas en tus controladores

publicado el Jueves, 9 de diciembre de 2010 por: Alberto Vilches
Etiquetas: - - | 24 comentarios »

Una de las principales ventajas de Groovy es el uso implícito de getters/setters para el acceso y escritura de variables; y la generación durante la compilación, de getters/setters para todos los atributos de nuestras clases.

Con un par de ejemplos se ve más claro: si tenemos una clase con dos atributos:

class Persona {
    String nombre
    int edad
}

El compilador de Groovy va a generar automáticamente los setters y los getters correspondientes, quedando la clase como si hubiera sido codificada así en Java:

public class Persona {
    private String nombre;
    private int edad;
    public String getNombre() { return nombre; }
    public setNombre(String nombre) { this.nombre = nombre; }
    public int getEdad() { return edad; }
    public setEdad(int edad) { this.edad = edad; }
}

Por otro lado, cuando accedemos a una variable desde Groovy, estamos usando implícitamente los getters y setters, de manera que el siguiente código Groovy:

def valor = miedad
persona.nombre = valor

Sería el equivalente a esto:

def valor = getMiedad()
getPersona().setNombre(valor)

Es decir, cualquier acceso a una variable que no exista en el contexto actual, o cualquier acceso a un atributo de un objeto, se transforma en un get/set (para saltarse esto, es necesario utilizar el operador “Java field” de la siguiente manera: persona.@nombre = valor)

Estos dos características nos permiten añadir, por ejemplo, nuevas variables en nuestros controladores cuyos valores se carguen de base de datos o de la sesión (o de los dos sitios). Por ejemplo, supongamos que tenemos un controlador que requiere en cada petición la lectura de base de datos del usuario y de una factura:

class EjemploController {
  def index = {
    def usuario = Usuario.get(session.miusuario) // Se supone que durante el login, se carga el valor miusuario en la sesion
    usuario.accesos = usuario.accesos + 1
    usuario.save()
    def factura = Factura.findByUsuarioAndFecha(usuario, new Date())
    sendEmailAviso(factura.importe, usuario.email)
    ...
  }
}

Crónica del SIME 2010 en Estocolmo

publicado el Lunes, 29 de noviembre de 2010 por: Ernesto Funes
Etiquetas: - - - | 6 comentarios »

Para el que no lo conozca, SIME 2010 es una conferencia que se celebra todos los años en Estocolmo y en otras ciudades del mundo, creada por el grupo Result y, especialmente, por uno de sus fundadores, Ola Ahlvarsson, uno de los mejores speakers que conozco.

SIME 2010 EstocolmoPor poneros en antecedentes sobre mi opinión respecto a esto tipo de eventos, hasta ahora todos a los que he asistido han sido nacionales, y más bien convencionales (La Red Innova, Internet es Tuyo, …) a excepción del Menorca TechTalk. Mi impresión de estos eventos (menos del de Menorca) es que pocas veces cuentan nada que no conozca o que me sirva para mi trabajo. Entiendo que para la gente de marketing, gran compañía, etc. puedan resultar muy enriquecedores, pero para los que “sudamos” internet son más de lo mismo. La segunda razón para acercarte a estos eventos suele ser el tan traído “networking”. En mi caso (siento si suena un poco pretencioso) tampoco suelo obtener buenos resultados (excepto del Menorca TechTalk) por dos razones, la primera es que no soy el tipo más sociable del mundo con lo que me cuesta conocer gente, y la segunda es que en la mayoría de los casos, en estos eventos hay más posibilidades de que yo ayude a alguien, que de que alguien me ayude a mi. Esto implica que en general estos eventos me parezcan llenos de, usando un termino acuñado por un amigo, “cancamusa” y casi siempre salgo decepcionado de ellos.

Respecto a SIME, de buenas a primeras me atraían varias cosas de la conferencia, y por eso me decidí a asistir. La conferencia se celebraba en Suecia, con lo que me interesaba ver como enfocaban la organización de eventos en un país tan diferente de España. Imaginaba que todo estaría perfectamente preparado y me lleve una desagradable sorpresa al ver que ha sido el congreso peor organizado al que he asistido. Vayamos por puntos:

  • El evento se celebraba en el cine Rigoletto, un sitio adecuado con un escenario perfectamente montado para que se viese a los speakers y las pantallas. Los workshops se celebraban en los “mini cines” y la verdad es que resultaban bastante cercanos. Hasta ahí todo bien.
  • Hubo exceso de gente. No se si porque no tenían previsto tanto éxito o porque el primer día no se controlaron las acreditaciones (yo no la recogí en ningún momento y sólo me la pidieron el segundo día a lo que conteste que me la había dejado en el hotel y me dejaron pasar sin más. En esos momentos pensé en la pasta que podría haberme ahorrado), pero el resultado fue que en algunas de las charlas no había sitio casi ni para estar de pie.
  • Este exceso de gente hizo que en las pausas, para acercarte a la zona de cafés y viandas, tuvieses que esperar 15 minutos de colas.

El evento tenía muy en cuenta el networking mediante un servicio de “match making”. La idea es que al registrarte rellenases los campos en los que estas interesado y dijeses si quieres participar en este servicio. Cuando llega la conferencia, tienes un listado de la gente relacionada con esos campos que quieren hacer “networking” y puedes establecer citas más organizadas con ellos. La verdad es que me pareció una idea genial que me gustaría ver implementada en las conferencias españolas, para evitar los asaltos a tarjeta armada en medio de los pasillos.

Los speakers que acuden a la conferencia parecían bastante interesantes, desde el fundador de Gowalla, a los creadores de Angry Birds pasando por el director de ventas de Spotify. Creo que las charlas fueron buenas, y mi decepción fue más por mis altas expectativas, que por fallo de los speakers. Yo iba esperando que me abriesen los ojos a nuevas tecnologías, nuevas tendencias, algo de lo que no hubiese oído hablar y que poder llevarme a España e implantar en Paradigma, y lo que escuche fueron historias ya conocidas, eso si relatadas por sus protagonistas, y con cifras y datos que resultaban esclarecedores. De las charlas destacaría las siguientes:

  • Gowalla: Típica historia “cursi” sobre la creación de una compañía, la pasión por el usuario, el trabajo bien hecho y demás. Sinceramente, me encanta la empresa, pero si fuera ellos estaría vendiendo ya: no vi ningún modelo de monetización y Facebook Places/Deals les van a comer la tostada en pocos meses.
  • Angry Birds: Impresionante el éxito de esta gente. Se están forrando (“undecent amounts of money” como dijo Peter Vesterbacka) en todas las plataformas y su estrategia de actualizar el juego con niveles gratis cada X tiempo hace que la gente no lo borre. Así consiguen que cuando lanzan ediciones especiales gran parte de su “user base” las compre (el caso del especial Halloween, 1,8 millones de descargas en 2 semanas).
  • Spotify: Lo que más me llamo la atención es su denominación como compañía de tecnología, y su obsesión por estar en el mayor número de plataformas posibles, especialmente en el móvil. Por otro lado, su dependencia brutal de la buena fe de la industria musical, el que sigan teniendo perdidas y su incapacidad de saltar al mercado americano da que pensar.
  • Qualcomm: Una de las presentaciones que mas me gusto con diferencia. Se dedicaron a mostrar en el escenario aplicaciones innovadoras de todo tipo usando sus dispositivos, desde control médico para monitorizar el estado de un paciente (interesante como uno de los datos que usan es la posición de la persona: estos dispositivos se usaron con los mineros de Chile) a juegos en el móvil con realidad aumentada ¡verdaderamente impresionante!
  • Crítica al “User generated content”: Esta charla estuvo curiosa, porque la trajeron principalmente para provocar a la audiencia. Eran dos personajes defendiendo que el contenido generado por el usuario es básicamente mediocre y que había que volver al modelo anterior donde el contenido era controlado por la industria y por tanto de mejor calidad. Lo más divertido es que por más que lo intentaban, no había manera de que los suecos se sintiesen “provocados”, con lo que no conseguían la respuesta que esperaban. Si intentan algo parecido en España los apedrean.

Además de las conferencias por la tarde había organizados “Workshops”. Este formato estaba más orientado a la interacción con el speaker y al intercambio de opiniones. Me gustó el formato, ya que al menos a mi me permitió sacar muchas mas conclusiones al ver diferentes opiniones y experiencias. Le criticaría que al menos uno de los workshops pareciese mas orientado a presentar una empresa a la que parecía que estuviese ayudando a internacionalizarse, que realmente a hablar sobre un tema. Sin embargo lo bueno de este formato es que aunque ese fuese el objetivo, la interacción entre los presentes hacía que la discusión se fijase en el tema (behavioural targeting) en vez de la empresa (de la que ni recuerdo el nombre)

Resumiendo, para mi la experiencia en SIME ha sido muy positiva, aunque en ello haya tenido mucha influencia el conocer a gran parte de los responsables del evento. El formato de SIME como conferencia es el que más me ha gustado hasta a la fecha, pese a los fallos organizativos. Eso si, si no se tienen intereses en Escandinavia (ya sean empresariales o personales) me acercaría a la conferencia de Barcelona en vez de a la de Estocolmo, ya que el networking se podrá rentabilizar mucho más.

Definitivamente una conferencia para guardar en el calendario.

Ernesto Funes (@ernestofunes) es Ingeniero Superior de Telecomunicaciones y uno de los socios fundadores de Paradigma Tecnológico. LLeva trabajando en proyectos relacionados con Internet desde 1997 cuando entro como becario en Indra. Actualmente se dedica a buscar diferentes maneras de implementar las últimas tendencias en tecnología e Internet en los clientes de Paradigma, o incluso si la situación lo permite, en spinoffs de Paradigma con entidad propia. Su obsesión por las nuevas tecnologías sólo es comparable a su pasión por el buen comer y el buen beber.

Seminario “Introducción a Android” el próximo 25 de noviembre

publicado el Viernes, 12 de noviembre de 2010 por: Paradigma Tecnológico
Etiquetas: - - | 5 comentarios »

Tenemos el placer de anunciaros que el próximo 25 de Noviembre, a las 18:00, impartiremos un seminario gratuito sobre Android en el aula polivalente 2 de la Escuela Politécnica Superior de la Universidad San Pablo CEU.

Estáis todos invitados a ir ¡os esperamos!

El seminario se celebrará en el Aula Polivalente 2

Más información en:

Cómo ir, quién lo imparte, temas a tratar: Seminario

Videos y materiales seminarios anteriores: consulta nuestra sección de seminarios

¿En qué seminarios estarías interesado? Vota en nuestra encuesta y decide el tema del próximo.

HTML5 y CSS3: Soporte para aplicaciones en smartphones

publicado el Jueves, 11 de noviembre de 2010 por: Luis Calvo
Etiquetas: - - - | 9 comentarios »

Ya lo apuntabamos en uno de nuestros posts: en el panorama de las aplicaciones móviles, que parecian monopolizar las diferentes apps stores, está entrando con fuerza un nuevo actor: la aplicación web. Este hecho lo corroboran los resultados de una encuesta publicada por Adobe que demuestra que los usuarios de smartphones prefieren, en la mayor parte de los casos, aplicaciones web frente a aplicaciones nativas. Mientras que algunas aplicaciones (los juegos por ejemplo) seguirán siendo nativas, en los próximos años viviremos la aparición imparable de aplicaciones web que sustituirán a las instalables.

Esto puede parecer inconcebible (sobre todo si pensamos en las antiguas aplicaciones Wap), pero hay una serie de motivos que nos pueden ayudar a entender por qué puede pasar esto.

Hace un par de años, la única tienda de aplicaciones era la de Apple, aunque en poco tiempo surgió la de Android. Iphone era el líder de las aplicaciones móviles y si pensábamos en una aplicación móvil, pensábamos en una aplicación para el Iphone. Este panorama ha cambiado mucho en la actualidad.

Según datos de Nielsen, en Estados Unidos, los dispositivos Android están creciendo inexorablemente (representan ya un 19%), en un mercado dominado por Blackberry (30%) y seguido de cerca por Iphone OS (28%). En Europa, la mayor cuota de mercado es para Symbian. A esto hay que añadir las nuevas incorporaciones de Samsung con su Bada y el nuevo OS de Microsoft, que planea gastar 400 millones de dólares en su lanzamiento. WebOS, de la mano de HP, parece que quiere volver a por su trozo de pastel. En España, los líderes son Iphone OS, Symbian y Android.

Este escenario complica bastante nuestra labor en el desarrollo de aplicaciones, ya que ahora necesitamos crear versiones de la misma aplicación para más plataformas, con el incremento en costes y tiempos de desarrollo.

Sin embargo, a pesar de la disparidad de plataformas, todos los smartphones del mercado tienen algo en común: excelentes navegadores. Como vimos en nuestro post dichos navegadores soportan en gran medida las novedades de HTML5 y CSS3 que nos permite crear aplicaciones web que consiguen una experiencia de usuario similar (o incluso superior) a las aplicaciones nativas. Tal y como muestra el estudio de Adobe los usuarios de smartphones empiezan a preferir aplicaciones en su navegador frente a las instalables, tal y como muestra la siguiente gráfica:

Las nuevas posibilidades de HTML5 y CSS3 son las que posibilitan este cambio de actitud. El mejor rendimiento y la interoperabilidad eran los puntos fuertes de las aplicaciones nativas, y lo siguen siendo (en las aplicaciones para música y los juegos la preferencia de los usuarios siguen siendo las apps instaladas), pero la posibilidad de acceder al GPS (geolocalización), a la cámara, al micrófono, el almacenamiento de datos local, las mejoras de rendimiento de los navegadores, etc, han contribuido al cambio.

Hace unos cuantos años, cuando hablábamos de aplicaciones web nos referíamos a aquellas aplicaciones Wap poco atractivas, lentas y rudimentarias. HTML5 y CSS3 permiten crear interfaces de usuario similares a los nativos, sin las restricciones de presentación de cada plataforma y, sobretodo, sin necesidad de multiplicar las versiones de la aplicación para cada una de ellas.

Está empezando a moverse el desarrollo de este tipo de aplicaciones a un ritmo cada vez mayor. Además estamos asistiendo a un cambio importante de paradigma. Cuando se desarrollaban versiones para móvil de aplicaciones web para ordenador, se adaptaba dicha aplicación (generalmente reduciendo funcionalidad y simplificando el aspecto gráfico) a los smartphones. Esto está cambiando también, y se está empezando a pensar primero en la aplicación para móvil y después, gracias a la mejora progresiva, en la versión para ordenador, creando así una única aplicación que se adapta a la plataforma en la que se ejecuta.

También podemos utilizar potentes frameworks de desarrollo de aplicaciones web específicos para móviles. Uno de los mejores ejemplos es Sencha Touch que permite desarrollar aplicaciones web, basadas en estándares (HTML5, CSS3, javascript) para iOS y Android.

Sin embargo, hay aspectos muy importantes a tener en cuenta que pueden decantar la balanza hacia las aplicaciones nativas y las apps stores: la distribución/difusión de las aplicaciones y la obtención de ingresos. El modelo de tienda de aplicaciones es muy ventajoso para los desarrolladores: alguien crea la tienda, que distribuye y publicita las aplicaciones, y proporciona un sistema de pago por descarga de las mismas (y unas comisiones por los servicios prestados).

¿Cómo obtener ingresos de una aplicación web?. Pues es un tema recurrente en internet, y hay varios modelos (publicidad, versiones free/premium…) y probablemente surgirán más. Esto no es aplicable, por supuesto, a aplicaciones web que son meros interfaces de procesos de compra de otros productos (venta de billetes, reservas, bienes de consumo…) y que en las apps stores son también gratuitas.

Respecto a la distribución y publicidad, deberemos analizar cómo conoce un usuario una aplicación (recomendación de familiares/amigos, reseñas en algún blog,…) y actuar en dichos canales para dar a conocer nuestro producto. En este sentido ayudaría también una mejora en la búsqueda a través del móvil (buscadores de aplicaciones web).

La “cara oscura” de las apps stores son sus criterios de admisión. Podemos dedicar varios meses al desarrollo de una aplicación y que ésta, por el motivo que sea, no cumpla dichos criterios y no sea publicada. O sea publicada y retirada posteriormente. Lo peor de todo es que no podemos prever esto en la fase de desarrollo (a menos que nuestra aplicación sea flagrantemente censurable, claro).

Esta es la situación actual. Existe un movimiento favorable por parte de los usuarios de smartphones al uso de aplicaciones web, debido a la gran difusión de los nuevos estándares web (HTML5 y CSS3) que posibilitan la creación de interfaces que generan experiencias de usuario similares a las de las aplicaciones nativas. La potencia de nuevos frameworks de desarrollo web para móviles, y la posibilidad de disponer de una única aplicación que se adapta a la plataforma reducen considerablemente el tiempo de desarrollo (y actualización) de las mismas. Habrá aplicaciones, como hemos mencionado, que serán siempre nativas, pero al igual que está pasando cada vez más en las aplicaciones nativas de ordenador, en los próximos dos años asistiremos a la migración de aplicaciones nativas a la web.

Hace unos años era descabellado pensar en escribir documentos en la web, o revisar el correo electrónico desde un navegador, hoy en día es lo más habitual.

¿A qué esperamos?


Nuestro Blog

Autor: Equipo de Experiencia de Usuario - Jueves, 17 de mayo de 2012

Mucho se ha contado ya (basta con revisar la lista abajo) acerca del primer UX Spain (Encuentro de profesionales de la Experiencia de Usuario en España) al que tuvimos ocasión de acudir el pasado 11 y 12 de mayo una representación de ocho Seres Paradigmáticos. A saber; @cvidal, @nacho_herranz, @vissit, @luiscalvodiaz, @jaucan, Óscar, Miguel y @davidmontalvo.

Ver más
Autor: Paradigma - Jueves, 27 de octubre de 2011