martes, 27 de marzo de 2012

Providing Synchronous / Asynchronous Flexibility With jQuery.when

Providing Synchronous / Asynchronous Flexibility With jQuery.when:
I’ve quickly become a fan of jQuery’s Deferred / Promise features. They’ve been around for a little bit now, but I only recent started using them and they’ve helped me solve a number of problems with my asynchronous JavaScript code. But what I recently figured out really blew my mind. You can use jQuery to support both synchronous and asynchronous code, with the `$.when` function, and your code doesn’t have to care whether or not it’s async.

$.when(something).then(doSomething);

The core of the $.when syntax is the when/then statement. It’s a simple logical progression in syntax and I think it reads quite nicely: When this condition is met, then execute this code. Of course you can make the statement say things that don’t quite make so much sense if you name your variables oddly, but I prefer to name them so that they do create this type of flow.
For example, you’ll find code similar to this in my Backbone.Marionette project:

 var that = this;
 var templateRetrieved = this.getTemplate();
 $.when(templateRetrieved).then(function(template){
   var html = that.renderTemplate(template, data);
   that.$el.html(html);
 });

view raw
1.js
This Gist brought to you by GitHub.

In this example, I’m waiting for a template to be retrieved before rendering my view. After the template has been retrieved, I’m using that template to do the rendering. The code reads fairly well, in my opinion: When the template has been retrieved, render the view.

$.when.then: Async

If I’m using an asynchronous template loading mechanism for my Backbone.Marionette views (like in my BBCloneMail sample app), the above code only needs to have a jQuery deferred object returned from the call to “getTemplate” on the view. If a deferred / promise is returned, then the $.when/then call will be set up to execute the ‘then’ callback after the template has completed loading. It’s a fairly simple thing to do, honestly. Just return a deferred / promise from “getTemplate” and the view rendering will correctly support asynchronous template loading.
The real magic in this code, though, is that it supports both synchronous and asynchronous returns from the “getTemplate” method.

$.when.then: Synchronous

If you can sift through all of the documentation and really wrap your head around it, you’ll find this little nuget:
If a single argument is passed to jQuery.when and it is not a Deferred, it will be treated as a resolved Deferred and any doneCallbacks attached will be executed immediately.
What this is really saying is that if you call $.when with a deferred/promise, then jQuery will wait until that promise has been fulfilled – resolved – before executing the ‘then’ portion of your code. At the same time, if you pass in an object that is not a jQuery deferred/promise, jQuery will immediately call the “then” callback in your code. This means that a call to $.when/then directly supports both synchronous and asynchronous processing.
You can see this evidenced in Backbone.Marionette, once again. The default implementations of the template loading and rendering for the various views are all synchronous. I’ve added extensive support for asynchronous template loading and rendering, though, using a combination of Deferred objects and $.when/then calls. The above code sample runs no matter the sync/async nature of the template loading and rendering, though.

Sonar 2.14 in screenshots

Sonar 2.14 in screenshots:
The Sonar team is proud to announce the release of Sonar 2.14. This new version includes 100+ improvements, bug-fixes and also new features that we believe are worth stopping your daily work for a couple of minutes to check out : extension of cross projects duplications for all languages, dashboard for reviews, notes on rules, new violations widget, enhanced file header, new treemaps and enhanced login. It is also to be noted that Sonar 2.14 enables LDAP 1.1 which provides support for external authorization.
Here are screenshots of what has changed in the user interface:

Cross-project copy paste detection for all languages

What was already there for Java language since Sonar 2.11 is now available for all languages, the ability to detect cross project duplications:


Dashboard for reviews

The 2.14 distribution comes with a default dashboard for reviews that can of course be customized. This provide a great insight of where you stand with reviews and violations :


Email notification on new violations

This is now possible on a project to subscribe and receive an email when a new violation is added :


Notes on rules

Two distincts functionality have actually been added :

First the ability to extend the description of a rule to give more details for example. This is going to follow the rule in every profile and will also be available when clicking on a violation:



But we have also added the ability to comment a rule in the context of a specific quality profile, to comment for example why it has been assigned a high priority or a special threshold :


Enhanced violations widget

When displaying a dashboard in a differential mode, what was displayed prior to Sonar 2.14 was the net number of violations. It missed an important piece: how many violations were added and how many violations were fixed during the period ? This information is now available:


Enhanced file header

On top of seing in which module a file belongs to, you can also now quickly add/remove a file from favourites :


Enhanced treemaps

We have now replicated the navigation mechanism of the radiators plugin within the treemap, enabling smooth navigation from highest level to source file:


Enhanced login

Context of navigation is now kept when logging in : the user is redirected to the page he came from. This makes sharing of permalinks easier.
Time now to let you give a try to this version 2.14. Release notes are available in the download page. Please do not forget to read the installation or upgrade guides.

JPA Criteria queries

Ver artículo.

viernes, 16 de marzo de 2012

Paypal Here, un lector de tarjetas de crédito móvil que hace la competencia a Google Wallet y Square

Paypal Here, un lector de tarjetas de crédito móvil que hace la competencia a Google Wallet y Square:

Muchos de vosotros conocéis ya los servicios como Google Wallet o Square, utilizados para realizar pagos desde nuestros dispositivos móviles.
Hoy se suma un nuevo servicio de este tipo, aportado por el mayor proveedor de este tipo de servicios por internet: Paypal.
La oferta de Paypal incluye un lector de tarjetas de crédito que se acopla a nuestro terminal por la conexión de los auriculares y que funciona conjuntamente con su respectiva aplicación, el cual nos permite realizar cobros.
Aparte de poder leer tarjetas de crédito, también utiliza la cámara para poder leer los números impresos en los cheques y así poder comprobar su validez y cobrarlos.
Por otra parte, también nos permite enviar facturas vía e-mail que pueden ser pagadas utilizando Paypal y realizar un seguimiento de todos los pagos que hemos realizado haciendo uso de este servicio.

De momento, está planteado para pequeñas y medianas empresas, que podrían obtener el lector y la aplicación gratuitamente a cambio de una pequeña comisión que Paypal les cobraría en cada compra.
Su puesta en funcionamiento es para hoy mismo en países como Estados Unidos, Canadá, Australia y Hong Kong, y se prevé salida en otros países en los próximos meses.

Paypal Here se perfila como una muy buena alternativa (y bajo mi punto de vista, la más fiable) a Google Wallet y Square, debido al prestigio del que goza la empresa por su actual servicio en internet que, con el tiempo, se ha convertido en el más fiable y extendido.
Paypal Here

Seguramente también te interesará...





martes, 13 de marzo de 2012

10 Sitios web que muestran el poder de HTML5

10 Sitios web que muestran el poder de HTML5:
Se viene hablando todo el tiempo de los diseños que se pueden lograr usando HTML5 y CSS3. Muchas veces hemos hablado de páginas donde se refleja el alcance de ambos y hoy quiero mostrarles 10 sitios web que muestran el poder de HTML5 y las increíbles cosas que se pueden lograr sin la necesidad de recurrir a Flash.
Agent 008 Ball
agent8ball 10 Sitios web que muestran el poder de HTML5
The Wilderness Down Town
thewildernessdowntown 10 Sitios web que muestran el poder de HTML5
Ben The Bodyguard
benthebodyguard 10 Sitios web que muestran el poder de HTML5
Rome
rome 10 Sitios web que muestran el poder de HTML5
universeries
universeries 10 Sitios web que muestran el poder de HTML5
This Shell
This Shell 10 Sitios web que muestran el poder de HTML5
rumpetroll
rumpetroll 10 Sitios web que muestran el poder de HTML5
Nakshart
nakshart 10 Sitios web que muestran el poder de HTML5
Lost Worlds Fair
lost world fairs 10 Sitios web que muestran el poder de HTML5
Toyota Prius Projects
toyatapriusprojects 10 Sitios web que muestran el poder de HTML5

Fundamentos para el diseño de interfaces

Fundamentos para el diseño de interfaces:
Las interfaces de usuarios las vemos a diario y no están arbitrariamente diseñadas. El diseño de interfaces es toda una rama dentro del diseño y es muy importante ya que es utilizada directamente por nuestro cliente.
Hoy les vamos a contar 10 fundamentos para el diseño de interfaces, para que los tengan en cuenta a la hora de realizar un trabajo de este tipo.
interfaz de usuario Fundamentos para el diseño de interfaces

1. Conocer al Cliente

Es más importante conocer los gustos y manejos que tiene un cliente frente a interfaces que preocuparse por copiar, imitar, mejorar la interfaz de un competidor. Es bueno conocer y experimentar con el cliente, la usabilidad que le dará a la interfaz, cuáles son los objetivos y diseñar en base a eso.

2. Prestar atención a los patrones

Si bien no es necesario copiar una interfaz, tampoco lo es diseñar algo nuevo ya que en la red, los usuarios y clientes están expuestos a interfaces ya conocidas que manejas muy bien (wordpress, facebook, etc). Se puede sacar lo mejor de ellas para diseñar la nuestra.

3.  Mantener Consistencia

Los usuarios necesitan consistencia. Ellos necesitan saber que una vez que aprenden a hacer algo, van a ser capaces de hacerlo de nuevo, es decir que no está bueno los cambios radicales entre una versión y otra por ejemplo.

4. Usar la jerarquía visual

Diseñar la interfaz de una manera que le permita al usuario centrarse en lo que es más importante. El tamaño, el color y la colocación de cada elemento y la forma en que trabajan juntos, deben crear un camino claro para la comprensión de la interfaz

5. Mantener informado al usuario

No dejen de informar a los usuarios de las acciones, los cambios en el estado y los errores o excepciones que se producen. Asi ellos sabrán si están haciendo las cosas como deben hacerse, o si hay que volver un paso atrás.

6. Sean indulgentes

Aunque nuestra interfaz parezca muy clara y simple, la gente puede equivocarse.  Su interfaz de usuario debe permitir y tolerar el error del usuario. Es bueno diseñar formas para que los usuarios puedan deshacer acciones.

7. Dotar a los usuarios

Una vez que los usuarios entendieron la interfaz, es bueno preveer atajos de teclado y formas más simples de llegar al final. La interfaz debe ser adecuada para un principiante y para alguien que la utiliza a diario y no quiere seguir todos los pasos básicos, leer todos los mensajes de como se completa, etc.

8. Hablar en su idioma

Mantener siempre la conversación con el usuario, la interacción de la interfaz con él. Colocar etiquetas claras que indiquen las cosas.

9. Mantener la simplicidad

Es importante la simplicidad del diseño para la mejor comprención

10. Seguir adelante.

A menudo se dice que el desarrollo de interfaces se necesita para fallar rápidamente, y repetir a menudo. Al crear una interfaz de usuario se pueden cometer errores, en ese caso hay que volver a intentarlo.
Fuente | Thinkvitamin

miércoles, 29 de febrero de 2012

Historias de usuario, una forma natural de análisis funcional

Historias de usuario, una forma natural de análisis funcional:

Historias de Usuario

Hoy es el día 0 del proyecto que me va a llevar a mí y al resto de compañeros a construir una buena y bonita aplicación, de la cual nos ha hablado con entusiasmo nuestra directora, nuestro gerente y el jefe de proyecto.

Tiene pinta de ser un poquillo compleja y, además, el JP lleva casi un mes escribiendo el documento de análisis funcional que estamos esperando como agua de Mayo. A ver si firma de una vez el cliente y nos ponemos a lanzar líneas de código.

La cara de todos se queda un poco más pálida cuando nos encontramos enfrente de 150 páginas de casos de uso, tablas de funcionalidades, de acciones externas e internas, de diagramas de estado, de esquemas de datos, de diagramas de clases. Todo siguiendo un estricto UML.

Para finalizar, o en medio de todo este volumen de papel, me encuentro con la matriz de trazabilidad que relaciona los diferentes casos de uso con el requisito que lo cumplimenta y que, seamos sinceros, es absolutamente ilegible en cuanto supera las 20 filas por 20 columnas.

Hagámoslo Agile, hagámoslo en equipo


Hoy es el día 0 del primer Sprint del proyecto que va a llevar al equipo en donde estoy integrado, ha realizar un buena y bonita aplicación. Y de la cual dirección nos ha hablado con entusiasmo.

Como casi siempre, no tenemos Product Owner, si no un JP haciendo labores de Proxy. Y se ha tirado dos semanas haciendo reuniones de toma de requisitos con el cliente para iniciar la construcción del product backlog, para que empecemos a tirar líneas en cuanto tengamos para rellenar el primer Sprint de tareas. Las reuniones para escribir, priorizar y mover las Historias de Usuario seguirán durante todo el proyecto.

Nos removemos en nuestras sillas. Ya empieza la acción. El PO (realmente el proxy), nos da la visión general que el cliente ha transmitido, y nos desglosa las historias de usuario en tareas.

Ahora nos toca el plantear las preguntas. El hacer emerger los mejores diseños y las mejores arquitecturas del análisis funcional de cada historia de usuario, en equipo.

Finalmente salimos de la reunión con el Product BurnDown y el Sprint BurnDown listos para empezar a quemar tareas. Con los criterios de aceptación claros. Y todo en un lenguaje natural claro y sencillo, asimilando el glosario del dominio. Y, por supuesto, al alcance de la mano en el repositorio documental o en el tablero.

Historias de usuario vs casos de uso UML


¿Pero qué es una Historia de Usuario, y porqué son tan importantes como toma de requisitos en un ambiente productivo Agile?

La primera gran diferencia es que en un análisis funcional con descripción de requisitos, generalmente se utiliza UML. Un lenguaje descriptivo pensado inicialmente en la sencillez de la comunicación y que se ha convertido en un, a mi parecer, monstruo que entienden muy pocos y que utilizan correctamente aún menos.

En cambio la Historia de Usuario está escrita en lenguaje coloquial al ser, simplemente, el recordatorio de la conversación con el cliente. Y un acuerdo formal de mínimos para dar por buena la funcionalidad descrita y esperada.

El concepto de Criterios de Aceptación de las Historias de Usuario, es la gran segunda ventaja sobre los requisitos funcionales UML. Ya que no requieren de las terribles matrices de seguimiento de requisitos, al incluir en la propia HU las pruebas que debe superar para ser aceptada como completada. Y que dicha aceptación es binaria: o vale o no vale. No hay medias tintas, ni el 99% finalizado. El concepto de “Done” en estado puro.

Las Historias de Usuario están vivas. Al realizarse el análisis funcional y técnico en profundidad en la reunión de planificación del Sprint, su desglose en tareas lo realiza un equipo de personas. Y ya se sabe lo cierto del dicho que dice “dos cabezas mejor que una”, y no veas si son cinco o nueve. El nivel de detalle y previsión supera en mucho al que puede hacer un único arquitecto o analista funcional.

Mientras, el resto de las Historias de Usuario pueden ser modificadas en su declaración, en su objetivo o en sus criterios de aceptación. Pueden ser re priorizadas u ordenadas por nuevos parámetros que le surjan al cliente. O pueden ser sacadas del Product Backlog al modificar el alcance o las tareas ha desarrollar.

Por último, hay una ventaja de la forma en que se construyen las historias de usuario, una conversación con el cliente, que es muy poderosa. Las historias de usuario, en cualquiera de sus características indican, señalan y emergen otras Historias de Usuario que pudieran estar ocultas o no existir.

Características de una Historia de Usuario


Las Historias de Usuario están divididas en dos apartados diferentes, el enunciado y los criterios de aceptación.

Si estuviéramos escribiéndolas en una cuartilla, como mandan los cánones y que yo nunca cumplo, escribiríamos el enunciado en el anverso y los criterios de aceptación en el reverso. Pero en mi caso particular, que utilizo a veces un tablero físico con post-it pero mucho más tableros electrónicos, siempre pongo el enunciado encima de los criterios de aceptación y los separo con una línea o de alguna forma visible que divida la tarjeta, sea física o virtual, en dos.

La manera más estándar de construir el enunciado es: Como Quiero Para

Y a continuación desgrano los Criterios de aceptación de forma taxativa. Quiero poder pulsar el botón. Quiero ver un listado con las marcas de coches. Quiero abrir la página desde mi móvil y sea agradable de ver (aquí emergen más historias de usuario)

Además, las Historias de Usuario deben cumplir las siguientes características para que puedan realizar su función de manera correcta:

  • Independientes. Deben ser atómicas en su definición. Es decir, se debe intentar que no dependa de otras historias para poder completarla.
  • Negociables. Como he dicho anteriormente, son entidades vivas. Deben ser ambiguas en su enunciado para poder debatirlas, dejando su concreción a los criterios de aceptación.
  • Valoradas. Deben ser valoradas por el cliente. Para poder saber cuanto aporta al Valor de la aplicación y junto con la estimación convertirse en un criterio de prioridad.
  • Estimables. Aunque sea siempre un poco como leer de una bola de cristal, deben poder ser estimadas. Tener su alcance lo suficientemente definido como para poder suponer una medida de trabajo en la que pueda ser completarla.
  • Pequeñas. Para poder realizar una estimación con cierta validez y no perder la visión de la Historia de Usuario, se recomienda que sean mayores de dos días y menores de dos semanas.
  • Verificables. Este es el gran avance de las Historias de Usuario. Que, junto con el cliente, se acuerdan unos Criterios de Aceptación que verifican si se ha cumplido con las funcionalidades descritas y esperadas.

Ejemplo real


Para finalizar este artículo, quiero compartir una Historia de Usuario real para que sirva de ejemplo de lo que estoy hablando.

Como usuario validado.
Quiero poder dar de alta anticipos.
Para poder recibir dinero anticipado para gastos.

Criterios de aceptación:

  • Quiero poder de alta un anticipo rellenando el formulario de anticipos.
  • Quiero poder dar de alta la petición de un anticipo del tipo permanente.
  • No debo poder solicitar dos anticipos permanentes.
  • No debo poder solicitar dos anticipos normales.
  • Debo poder solicitar un anticipo permanente y uno normal, y viceversa.
  • Cuando pulse “Aceptar o Grabar” debe de registrarse la solicitud en el sistema y desencadenar el flujo de aprobaciones.
  • Cuando pulse “Aceptar o Grabar” el formulario debe quedar bloqueado para su edición.

La visión general, es un gestor de anticipos a cuenta. La historia de usuario trata del formulario para pedir un anticipo para gastos. Y es parte de un Product Backlog real de un proyecto del cual soy responsable.

Y funciona…