Los Tiempos Cambian

Animaciones y transiciones con AngularJS

danii — Tue, 14 May 2013 07:59:47 +0000

A partir de la versión 1.1.4 del framework (descargar aquí del Google CDN), AngularJS viene con soporte nativo para animaciones y transiciones gracias a la nueva directiva ng-animate. Os recomendamos encarecidamente echarle un vistazo al fantástico artículo en el blog yearofmoo que nos explica cómo utilizar esta nueva y genial feature de AngularJS y nos proporciona un buen número de ejemplos.

Puesto que esta directiva es una novedad de esta versión, debemos consultar la documentación de ngAnimate en los docs de la versión 1.1.4 ya que en versiones anteriores no vamos a encontrar referencias a las animaciones.

Demo: Creación y edición de Slides con animaciones y transiciones

Para demostrar estas animaciones hemos preparado una pequeña aplicación de creación y edición de Slides en formato markdown en AngularJS, con transiciones de entrada y salida que además son dinámicas y dependientes del estado de la aplicación. Es decir, las animaciones de entrada y salida de las slides serán con dirección izquierda-derecha cuando nos movamos a una slide posterior, o derecha->izquierda si nos movemos a una slide posterior

ng directives

Las animaciones en AngularJS se declaran mediante la directiva ngAnimate y pueden asignarse a uno o varios eventos de animación. AngularJs actualmente soporta animaciones asignadas a los siguientes eventos:

hide: cuando un elemento del DOM pasa de visible a hidden,
show: cuando un elemento del DOM pasa de hidden a visible,
enter: cuando un elemento nuevo se añade al DOM,
leave: cuando un elemento es eliminado o deja de estar en el DOMm
move: cuando un elemento cambia de posición en el DOM.

Cada una de las directivas que permite animciones va a poder asignar distintas animaciones a cada uno de estos eventos:

La directiva ngRepeat soporta los eventos enter, leave y move;
ngInclude, ngSwitch y ngView soportan los eventos enter y leave;
y por último las direcivas ngShow y ngHide soportan los enventos show y hide, lógicamente.

También podemos usar el servicio $animator para que nuestras directivas custom soporten animaciones asignadas a cualquiera de estos eventos.

Transiciones CSS3 vs Animaciones JavaScript

AngularJS nos ofrece la potencia de utilizar animaciones y transiciones definidas en CSS3, pero también podemos programarlas mediante JQuery o cualquier otro framework de animaciones en JavaScript que queramos.

Las animaciones basadas en transiciones CSS3 son mucho más sencillas de utilizar ya que simplemente hemos de declararlas en el CSS de nuestra app siguiendo la siguiente nomenclatura: nombreAnimacion-evento-setup para definir la transition (no olvidarse de los malditos vendor prefixes!) y el estado inicial, y nombreAnimacion-evento-start para definir el estado final. Por ejemplo en nuestra demo hemos definido la siguiente animación para la transición entre el estado de edición del slide activo, desde alpha opacidad 0 a opacidad 1 en 2/3 de segundo:

/* ANIMATIONS */
.fade-show-setup {
  -webkit-transition:all cubic-bezier(0.250, 0.460, 0.450, 0.940) 0.66s;
  -moz-transition:all cubic-bezier(0.250, 0.460, 0.450, 0.940) 0.66s;
  -o-transition:all cubic-bezier(0.250, 0.460, 0.450, 0.940) 0.66s;
  transition:all cubic-bezier(0.250, 0.460, 0.450, 0.940) 0.66s;

  opacity:0;
}
.fade-show-setup.fade-show-start {
  opacity:1;
}

Mientras que para animaciones mediante JavaScript utilizaremos una sintaxis más complicada, pero que obviamente nos ofrece mucha más potencia que CSS, ya que podemos recibir parámetros, operar con ellos y también acceder a servicios de Angular. Por ejemplo en nuestra demo hemos definido la siguiente animación de entrada, que tomará dirección izquierda-derecha o derecha->izquierda según un valor precalculado (que dependerá de la slide actual y a la que nos queremos mover):

// Definimos animación enter
app.animation('animate-enter', ['$rootScope', function($rootScope) {
  return {
    setup : function(element) {

      // margin con respecto al tamaño de la ventana del navegador
      var margin = Math.max(100,($(window).width()-880)/2);

      // utilizamos rootScope para discernir offset a aplicar
      var px = ($rootScope.myAnimation==='fade-right')?'-'+margin+'px':margin+'px';

      jQuery(element).css({ 'opacity': 0, 'margin-left': px });

    },
    start : function(element, done) {
      // lanzar animacion
      jQuery(element).animate({
        'opacity' : 1, 'margin-left': 0
      }, function() {
        // llamar a done() cuando la animación termina
        done();
      });
    }
  };
}]);

Secuenciación de Animaciones

Uno de los pocos problemas que vemos es que actualmente, AngularJS no proporciona ninguna manera de secuenciar animaciones: si un elemento del DOM es sustituido por otro, los eventos enter y leave se dispararán simultáneamente. Esto puede presentar un problema, ya que nos parece una utilidad muy común el querer, por ejemplo, que la animación de enter del nuevo elemento se lance solo cuando el elemento reemplazado ha terminado su animación de leave, y no inmediatamente ya puede producirse un solapamiento entre ambas animaciones.

En la demo mostrada hemos solventado esto mediante un uso creativo del servicio $timeout para simular esta secuenciación. Lo que hacemos es primero ocultar el elemento saliente y lanzar la animación asignada a hide, y cuando ésta ha terminado (gracias al $timeout) se ejecutarán los cambios en el DOM que provocan que se disparen los eventos leave (que en este caso no tiene asignada ninguna animación ya que el elemento saliente ya está oculto) y enter.

animateSwitchSlide = function (id) {

    // utilizamos rootScope para discernir qué animacion haremos
    $rootScope.myAnimation = (id > $scope.slide.id)?'fade-left':'fade-right';

    $scope.hide=true;

    // transition tras timeout para dar timepo a la animación hide a finalizar
    $timeout( function(){ $location.path('/slides/'+id); }, 550 );
  };

Conclusión

Nos parece un paso adelante muy importante y un signo de madurez del framework AngularJS el empezar a soportar de forma nativa, sencilla e intuitiva una característica como las animaciones, que puede no ser una funcionalidad básica pero nos da mucho juego para vestir y enriquecer visualmente nuestra Webapp.

Además gracias al esquema de directivas ng y eventos utilizado, es realmente sencillo upgradear una aplicación ya terminada para utilizarlas, ya que simplemente hay que definir las transiciones que queremos y aplicar la directiva ng-animate donde sea necesario, sin necesidad de modificar ni una línea de código. Esto será clave también conforme se consolide el soporte para animaciones con nuevos eventos, funcionalidades y directivas soportadas.

Mejorando la velocidad de carga de nuestra web con Google PageSpeed Insights

danii — Mon, 29 Apr 2013 11:01:04 +0000

PageSpeed Insights es una herramienta de Google para analizar y evaluar la velocidad de carga de una páginas web y, lo más importante, además proporcionar una serie de utilísimas sugerencias y herramientas asociadas para mejorar esta velocidad de carga.

Para evaluar la carga de nuestra página web así como nuestra implementación, Page Insights se basa en este documento de buenas prácticas que abarca tanto a nivel de front-end (carga de imágenes, archivos JavaScript, CSS, etc) como de configuración de servidor.

A grandes rasgos y sin entrar en muchos detalles podemos resumir los objetivos de estas buenas prácticas en principalmente los tres siguientes:

Minimizar el número de peticiones HTTP que se producen,
Reducir el tamaño de las respuestas de estas peticiones HTTP,
y optimizar el renderizado de la página en el navegador.

PageSpeed analizará nuestro webiste y nos asignará una puntuación o score sobre 100 que evalúa cuánto más rápida podría ser la carga de esta web. Un score muy alto y cercano a 100 indica que hay poco que mejorar (es decir, la página ya carga todo lo rápido que puede o cerca) mientras que un score bajo indica que hay bastantes mejoras que podríamos llevar a cabo. Es importante notar que esta puntuación o score es relativa a la página sobre la que estamos, es decir no viene en función del tiempo que tarda la página en cargar, si no en función de cuántas de las buenas prácticas antes comentadas hemos seguido e implementado.

Podemos utilizar PageInsight como servicio online introduciendo la URL de la página que queremos evaluar:

Y además está disponible una extensión open-source para Chrome Developer Tools en el navegador Chrome y también para Firebug para aquellos que sigáis siendo fieles a Firefox. En este artículo nos vamos a basar en la extensión para Chrome Developer Tools en Mac, pero el funcionamiento es prácticamente idéntico en todas las versiones.

Utilizando la extensión de Chrome Developer Tools

Una vez instalada la extensión, con nuestra página web abierta en Chrome, primero abriremos Chrome Dev Tools:

Tools –> Developer Tools o Ctrl + Shift + I (en Mac: ⌥⌘I)

Y una vez abierta la interfaz veremos que aparece una nueva pestaña de PageSpeed dentro de la cual nos encontraremos un call to action:

Al hacer click en cualquiera de los botones rojos ANALYZE o START ANALYZING se producirá una recarga de nuestra página y tras un breve lapso de tiempo de análisis se nos mostrarán los resultados del análisis, empezando por una puntuación PageSpeed Score que viene a evaluar las medidas que hemos implementado en nuestro sitio para mejorar la velocidad de carga.

Puesta en práctica: Mejorando la velocidad de carga de lostiemposcambian.com

En el caso de la home de lostiemposcambian.com incialmente obtuvimos la siguiente evaluación:

PageSpeed Score inicial de lostiemposcambian.com: 86 (de un total de100)

Una puntuación de 86 puntos de 100 posibles no está nada mal, pero evidentemente tenemos bastantes cosas que mejorar.

Por suerte, en el área izquierda nos aparece una lista de sugerencias que el plugin nos ofrece para mejorar la velocidad de carga. Estas sugerencias nos aparecen categorizadas en 3 colores: rojo amarillo y azul según las considere High Priority, Medium Priority y Low Priority respectivamente. Además, en cada sugerencia individual obtenemos detalles de cómo podemos implementarla en el caso particular de nuestra página web.

Obviamente debemos intentar aplicar primero las sugerencias marcadas como High Priority en rojo ya que son los que representan un mayor impacto en la velocidad de carga. También aparecen en verde y menos destacados aquellas buenas prácticas que ya tenemos correctamente implementadas.

En el panel izquierdo PageSpeed Insights nos da sugerencias de cómo podemos mejorar la velocidad de carga de nuestra web

Vamos a analizar algunas de estas sugerencias y cómo implementarlas en nuestra página tomando como ejemplo nuestro caso en lostiemposcambian.com, haciendo por supuesto especial hincapié en las de mayor prioridad pero también fijándonos en las más sencillas y que con poco esfuerzo pueden producir mejoras inmediatas en la velocidad de carga de una web.

High Priority

Aprovechar la caché del navegador
Es conveniente evitar que el navegador realice peticiones para recursos estáticos (como por ejemplo imágenes) que ya tiene descargas de visitas anteriores (lo que se conoce como en caché). Es fundamental por tanto añadir valores para los atributos expiry date o maximum age en la cabecera HTTP de la respuesta para estos elementos a valores con cierta lejanía en el futuro para indicar al navegador que utilice la versión cacheada si la tiene.

Activar Keep-Alive

Keep-Alive es una fantástica feature de los servidores Apache que permite a servidor y cliente negociar una única petición HTTP para transferir varios recursos, en vez de abrir una nueva petición por recurso. Es fácil ver que esto congenia muy bien con nuestro objetivo de minimizar el número de peticiones HTTP.

Puesto que estas la sugerencia sugerencia anterior y esta son de configuración de servidor, en caso de utilizar un servidor Apache podemos configurarlas modificando el archivo .htaccess de nuestra página web. Por ejemplo, estas son las directivas que hemos añadido al .htaccess de lostiemposcambian.com en el servidor para implementar ambas funcionalidades sugeridas:


  ExpiresActive on

# Perhaps better to whitelist expires rules? Perhaps.
  ExpiresDefault                          "access plus 1 month"

# cache.appcache needs re-requests in FF 3.6 (thx Remy ~Introducing HTML5)
  ExpiresByType text/cache-manifest       "access plus 0 seconds"

# your document html
  ExpiresByType text/html                 "access plus 0 seconds"

# data
  ExpiresByType text/xml                  "access plus 0 seconds"
  ExpiresByType application/xml           "access plus 0 seconds"
  ExpiresByType application/json          "access plus 0 seconds"

# rss feed
  ExpiresByType application/rss+xml       "access plus 1 hour"

# favicon (cannot be renamed)
  ExpiresByType image/x-icon              "access plus 1 month" 

# media: images, video, audio
  ExpiresByType image/gif                 "access plus 3 months"
  ExpiresByType image/png                 "access plus 3 months"
  ExpiresByType image/jpg                 "access plus 3 months"
  ExpiresByType image/jpeg                "access plus 3 months"
  ExpiresByType video/ogg                 "access plus 3 months"
  ExpiresByType audio/ogg                 "access plus 3 months"
  ExpiresByType video/mp4                 "access plus 3 months"
  ExpiresByType video/webm                "access plus 3 months"

# htc files  (css3pie)
  ExpiresByType text/x-component          "access plus 1 month"

# webfonts
  ExpiresByType font/truetype             "access plus 1 month"
  ExpiresByType font/opentype             "access plus 1 month"
  ExpiresByType application/x-font-woff   "access plus 1 month"
  ExpiresByType image/svg+xml             "access plus 1 month"
  ExpiresByType application/vnd.ms-fontobject "access plus 1 month"

# css and javascript
  ExpiresByType text/css                  "access plus 2 months"
  ExpiresByType application/javascript    "access plus 2 months"
  ExpiresByType text/javascript           "access plus 2 months"

  
    Header append Cache-Control "public"
    Header set Connection keep-alive

Medium Priority

Combinar imágenes en Sprites CSS
Tambien podemos ahorrar peticiones al servidor si en vez de cargar las imágenes utilizadas en nuestro CSS como background de una en una las combinamos en una Image Sprite y posteriormente mostramos la parte correspondiente mediante un reposicionamiento por código CSS. Esta técnica no es aplicable a todas las imágenes y va a depender cómo está montada la estructura del CSS, de si estas imágenes se repiten en horizontal o vertical, si el contenedor de la imagen será siempre del mismo tamaño o dependerá de su contenido, etc.

Por suerte en nuestro caso de lostiempocambian.com contábamos con el inestimable apoyo de la gran Eli Padilla, maestra de todas las cosas CSS y conseguimos agrupar cuatro de las pequeñas imágenes background que PageSpeed nos indicaba que se cargaban de forma individual y las encajamos en una Spritesheet así:

Ejemplo de Spritesheet con fondo transparente y los elementos combinados: estados on y off del botón de buscar y bullet points de los listados en el footer y en el cuerpo de cada post respectivamente.

El caso del botón con estado on/off es un ejemplo de libro para esta técnica sin demasiadas complicaciones. Para los bullets de los elementos

de los listados teníamos la complicación de que el contenido podía tener diferentes alturas, de ahí el offset entre una y la otra en el spritesheet.

En cuanto a las modificaciones en el CSS, el código sin Image Sprite original era así:


#footer-content ul li{background:transparent url('images/bg-footer-content-bullet.png') no-repeat 0px 5px;}

.page #main .entry ul li{background:url(images/ul_li.gif) no-repeat 10px 9px;}

#searchform .input_submit{background:url(images/buscar.gif) no-repeat center center;border:none;cursor:pointer;height:30px;margin:0px 0px 0px 5px;width:60px;}

#searchform .input_submit:hover{background:url(images/buscar_f2.gif) no-repeat center center;}

Y el código CSS con image Sprite quedaría así:


#footer-content ul li{font-size:0.95em;line-height:1.2em;padding:0px 0px 7px 10px;background:transparent url('images/sprites.png') no-repeat 0px -39px;}

.page #main .entry ul li{background:url(images/sprites.png) no-repeat 10px -80px;}

#searchform .input_submit{background: url('images/sprites.png') no-repeat 0 -18px;border:none;cursor:pointer;height:16px;margin:0px 0px 0px 5px;width:60px;}

#searchform .input_submit:hover{background:url('images/sprites.png') no-repeat 0 0;}

Y ahora sí la única imagen que se carga en estas reglas CSS es images/sprites.png, así que hemos reducido cuatro peticiones HTTP a una sola.

Por supuesto, PageSpeed no tiene en cuenta la estructuración de nuestro CSS ni de nuestro contenido, así que sigue sugiriéndonos la posibilidad de combinar imágenes en un único Sprite aunque no tengamos forma de combinarlas o aunque no tengamos control sobre ellas ya que dependan de sitios externos como Twitter, Facebook, WordPress etc.

Servir recursos desde una URL consistentes
El problema que tenemos aquí es que estamos sirviendo exáctamente el mismo contenido estático, pero lo estamos cargado desde dos URLs distintas. Esto es un gran error, ya que el navegador debe realizar dos peticiones para un mismo recurso, es decir estamos realizando siempre una petición y una carga de datos de más y podríamos estar ahorrando nada menos que 68.7KiB, un peso nada desdeñable.

Por desgracia para nosotros, estudiando las peticiones “culpables” vemos que son las siguientes:
- http://platform.twitter.com/…/follow_button.1363148939.html y:
- https://platform.twitter.com/…/follow_button.1363148939.html
¡Parece ser que el culpable es el follow button del widget de Twitter! Algún programador en Twitter ha utilizado en un sitio http y en otro https y esta sugerencia va a caer en saco roto en este caso.

Low Priority

Todos los puntos que vienen a continuación son menos críticos que los comentados anteriormente, pero muchos de ellos son muy fáciles de solucionar y por tanto merece la pena estudiarlos. ¡Cada granito de arena cuenta!

Optimizar imágenes
PageSpeed nos analiza si las imágenes que estamos sirviendo están bien optimizadas y nos avisará de cuáles podrían comprimirse para pesar menos, con lossless compression obviamente para no perder ni un ápice de calidad.

Una ventaja de utilizar la extensión de Chrome Dev Tools en vez del servicio online es que además, en caso de poder optimizarse la imagen nos la comprime el propio PageSpeed y nos la ofrece para descarga (está un poco escondida, la podemos encontrar bajo en link see optimized content) . Aunque existen programas y aplicaciones web para esto, PageSpeed es realmente cómodo ya que identifica la imagen infractora y en el mismo momento nos la ofrece ya optimizada sin necesidad de ninguna acción adicional por nuestra parte.

Tras optimizar todas las imágenes del front de lostiemposcambian.com, nos encontramos con que algunas de ellas escapan otra vez a nuestro control ya que dependen de WordPress o Twitter.
Minimizar archivos CSSs y JavaScript
Deberíamos siempre minimizar nuestros archivos CSSs y JavaScripts en producción para que ocupen lo menos posible. Al igual que hemos visto con las imágenes, en el caso de que nuestros ficheros CSSs y JavaScript puedan minimizarse, PageSpeed nos ofrece para descarga un fichero minimizado para sustituir en producción. Genial!
Meter inline fragmentos pequeños de CSS / JavaScript en vez de en archivos externos
Cada fichero adicional representa una petición HTTP más. Para archivos muy pequeños, el coste de hacer esta petición adicional es prohibitivo en relación a su peso y por tanto deberíamos incluirlos inline en otros CSS o JavaScript o tal vez incluso en el mismo archivo HTML. Al igual que las anteriores, no siempre va a depender totalmente de nosotros (WordPress, te estoy mirando a ti!)
Evitar bad requests
Por supuesto una petición que acaba en un HTTP Status de la familia 4xx (error de cliente) es una petición desperdiciada. El más común suele ser el 404 (resource no encontrado) y si tenemos alguna o varias de éstas es conveniente arreglarlas manualmente, quitándolas o corrigiéndolas.
Especificar las dimensiones de las imágenes en el HTML
Siempre hemos de especificar las dimensiones de las imágenes en la etiqueta mediante los atributos width y height. Esto es debido a que en caso contrario el navegador no conocerá estas dimensiones hasta que la imagen sea cargada, y por tanto hará dos pasadas para renderizar el contenido de la página: una antes de cargar la imagen y otra después, ya que el layout puede cambiar completamente en función de el tamaño de la imagen.

Si en algún caso por omisión o error humano no tenemos estos atributos, PageSpeed se encarga de indicarnos dónde debemos añadirlos y cuáles deben ser sus valores, para mayor comodidad.
Servir las imágenes al tamaño correcto
Relacionado con el punto anterior, es importante servir nuestras imágenes al tamaño correcto, especificado por las dimensiones en el HTML, para no dejar al navegador la tarea de redimiensionar imágenes. Hemos de servir imágenes del tamaño al que se van a mostrar, ya que si no obligamos al motor de renderizado del navegador a realizar trabajo extra y además podemos estar cargando bytes de más innecesariamente si mostramos una imagen más pequeña de lo que es realmente.

En el caso de este blog, por error humano habíamos especificado algunas dimensiones mal y algunas imágenes estaban siendo redimiensionadas por el browser. Un error muy difícil de detectar sin utilizar PageSpeed ya que las imágenes incorrectas parecían estar bien a simple vista.

Una vez aplicados todos estos pasos, podemos comprobar que si ejecutamos otra vez el analizador PageSpeed Insights veremos que hemos pasado de un score inicial de 86 sobre 100 nuestro site lostiemposcambian.com pasa a un sobresaliente 95 sobre 100 para la home y rondando tambien rondando los 90-95 sobre 100 para los posts individuales. Gracias a la nueva configuración del servidor los visitantes recurrentes serán los más beneficiados, pero los nuevos visitantes también notarán una mejoría gracias a la reducción general del número de HTTP requests y de peso de muchos de los archivos cargados (imágenes optimizadas y archivos CSS y JavaScripts minimizados).

En resumen, una herramienta magnífica y que recomendamos totalmente para desarrolladores web y también webmasters, ya que nos puede ayudar a mejorar sensiblemente la velocidad de carga de nuestra página web. Estamos seguros de que los usuarios (en este caso vosotros, queridos lectores) nos agradecerán cada milisegundo y byte que consigamos arañar de las peticiones HTTP y los tiempos de carga de la página!

Snippets de Gist: de la nube a Sublime

danii — Mon, 22 Apr 2013 09:25:41 +0000

Una de las mejores características de Sublime Text 2 es la posibilidad de añadir muy fácilmente funcionalidades gracias a los numerosos plugins creados por la comunidad. Para recibir un montón de tips de utilización de Sublime y conocer un genial compendio de plugins excelentes para desarrollo web no puedo recomendar suficientemente este curso gratuito en Tuts+: Perfect Workflow in Sublime Text 2.

Cuidado porque a pesar de estar publicado en la segunda mitad de 2012, ya está un poco outdated en algunos puntos y la información de ciertos plugins de Sublime no es del todo exacta o es incompleta debido a que se han producido bastantes cambios y mejoras desde entonces. Éste es el caso con el plugin de Gist, que vamos a comentar en este post y tiene algunas opciones muy interesantes que no existían cuando se grabó este screencast.

Snippets de Código en la nube gracias a Gist

Siguiendo con la temática de nuestro post sobre Snippets de código en Sublime, vamos a comentar otra opción muy interesante que es la posibilidad que nos da Sublime de poder insertar Snippets desde Gist de Github gracias al genial Plugin de Gist para Sublime. Si tenemos una cuenta de Github automáticamente también tenemos acceso a una cuenta de Gist donde podemos almacenar y compartir Snippets. Al igual que muchos otros plugins y complementos, podemos instalar el plugin de Gist fácilmente en Sublime Text mediante Package Control.

Después de instalar el plugin, hemos de asociarlo a nuestra cuenta de Github (que es la misma que nos da acceso a Gist). Para ello, accedemos a la configuración del plugin (Preferences -> Package Settings -> Gist) y en el archivo de configuración del plugin (en formato JSON, al igual que todos los archivos de configuración de Sublime) tenemos la opción de especificar nuestro username + password o utilizar nuestro Github API token:

Una vez el plugin está configurado, tendremos como siempre en Sublime dos maneras para utilizarlo:

Abrimos el menú de Herramientas / Tools y la última opción será Gist, donde podremos además de insertar Gists de nuestra cuenta crear nuevos o modificar ya existentes.

Mediante la Paleta de Sublime no tenemos más que teclear “gist” y aparecerán las opciones de este plugin.

En ambos casos, al seleccionar Insert Gist nos encontraremos con un desplegable que muestra todos los Snippets que tengo guardados en mi cuenta de Gist, y al seleccionar uno de ellos se instalará en la posición actual del cursor.

Filtrando nuestros Snippets de Gist

Sin embargo, Gist muchas veces lo utilizamos para compartir de forma rápida un fragmento de código a través de internet, o quizás para insertarlo en nuestro blog. El caso es que no todos nuestros snippets de Gist los querremos reutilizar de forma regular cuando estemos programando. Por suerte, el plugin nos permite configurar en las preferencias dos opciones para filtrar los Snippets de mi cuenta de Gist que aparecerán en Sublime:

Utilizando un prefijo que colocaremos delante de la descripción (no el nombre) del Snippet. Esta posibilidad está bien, pero a mí me gusta (tal y como se recomienda en el curso de Tuts+) utilizar prefijos para denotar el lenguaje de programación en el que está escrito el Snippet y así encontrar más facilmente el que buscamos a la hora de insertarlo en Sublime.
Mejor aún, podemos filtrar mediante una etiqueta o tag. El sistema de tags de Gist es tan simple como intuitivo y efectivo: cualquier palabra en la descripción que comience por el caracter “#” se considerará una etiqueta y podremos utilizarla para filtrar nuestros Snippets.
El plugin también nos da la opción de mostrar sólo aquellos Snippets marcados como “favoritos” (starred) opción que vemos menos interesante que las dos anteriores.

Así por ejemplo, en mis snippets cualquiera con la etiqueta #sublime será el que podré insertar directamente desde el editor gracias al plugin. La genialidad de esto es que así podremos seguir utilizando Gist para compartir nuestros snippets de código a traves de Internet como siempre, y tan sólo los que etiquetemos para Sublime aparecerán en la lista dropdown de Sublime para ser insertados. Para esto, accederemos a la configuración del plugin (Preferences -> Package Settings -> Gist) y las últimas tres opciones de configuración serán “use_starred”, “gst_prefix y “gist_tag”, como siempre en formato JSON.

Configuración del plugin para que filtre por la etiqueta #sublime, sin especificar prefijo

Ejemplo de un Snippet en Gist con prefijo para denotar el lenguaje (CSS) y etiqueta #sublime para que el filtrado del plugin lo incluya

Además de poder acceder a nuestros propios Snippets, no olvidemos la parte social de Gist: cualquier Snippet que descubramos en Gist (ya sea por que nos topemos con él por casualidad en otro site, curioseando en la cuenta de algún desarrollador conocido o famosete o en la fantástica sección de discover Gists) y que nos interese, podemos forkearlo y tan solo editando su descripción y añadiendo el prefijo o la etiqueta filtro, ya lo tendremos listo para ser insertado en Sublime sin necesidad de abrir navegador, ir a Gist, copiar/pegar, etc etc cada vez que queramos utilizarlo

Snippets de código en Sublime Text 2

danii — Thu, 18 Apr 2013 10:19:36 +0000

Vamos a empezar este post evangelizando un poco y recomendando fervientemente que si alguien no ha probado todavía Sublime Text 2 como editor de código, que se lance ya mismo. Es una auténtica maravilla lo potente, versátil y rápido que puede llegar a ser cuando lo empezamos a dominar, y lo mucho que puede acelerar nuestro workflow.

¿Qué es un Snippet de código? Según la definición de la Wikipedia:

“Un Spnippet es un término utilizado en programación para designar una pequeña región de código fuente, código máquina o texto plano reutilizable. Normalmente, son unidades operativas formalmente definidas que serán incorporadas en módulos programables más grandes.”

Hemos resaltado las que consideramos partes claves de la definición, creemos que se puede resumir en que un Snippet es cualquier fragmento de código que reutilizaremos una y otra vez dentro de uno o varios proyectos.

Puesto que a ningún programador le gusta teclear una y otra vez lo mismo, es lógico que una de las features más importantes de un buen editor de código sea una buena gestión de Snippets que vaya más allá del típico autocompletar de los nombres de las funciones y palabras reservadas del lenguaje.

Por supuesto, Sublime Text, que marca un listón de excelencia para los editores de código, nos permite:

Insertar Snippets ya existentes en nuestro código;
Importar Snippets ya creados por otros usuarios de Sublime como si de plugins se tratase;
Definir nuestros propios Snippets personalizados a nuestro gusto

Insertando Snippets ya existentes

Sublime Text viene con algunos Snippets de uso común preinstalados. Para insertar un Snippet ya existente tenemos dos opciones:

Hacer click en Herramientas/Tools y luego en Snippets o
Sacamos la paleta (Shift + Command + P en Mac, en windows supongo que será Shift + Ctrl + P) y escribimos snippet para filtrar las demás opciones

En ambos casos nos aparecerán todos los snippets que tenemos asociados al lenguaje de programación en el que estamos trabajando. Si no hemos añadido ninguno importado ni propio (ver siguientes secciones) estos serán los snippets preinstalados de Sublime, que suelen ser bastante útiles… pero puede no ser suficiente!

Importando Snippets mediante Package Control

Por supuesto cualquier persona que trabaje con, por ejemplo, jQuery va a necesitar aproximadamente los mismos Snippets. Por eso siempre es conveniente antes de crearnos nuestros propios Snippets para un lenguaje o herramienta el comprobar si ya existe un package de Snippets creado específicamente para esta herramienta. Para esto, podemos utilizar Package Control (un plugin de Sublime que es totalmente un MUST HAVE) -> Instalar Package y buscarlos por nombre:

Instalando Snippets creados por otros usuarios desde Package Control

Creando nuestros snippets

Para crear un nuevo snippet, abrimos el menú de Herramientas/Tools y una de las últimas opción será la de crear un nuevo snippet. Un archivo Snippet de Sublime Text es un XML con diferentes nodos que son los que necesita Sublime para interpretar qué es lo que queremos hacer con ese snippet exactamente. A la hora de guardarlos tendremos que usar la extensión .sublime-snippet para que después Sublime los reconozca.

Si creamos muchos snippets es importante que los tengamos organizados, así que es interesante meter todos los snippets de un mismo lenguaje de programación en una misma carpeta. Si además a esa carpeta le llamamos con el mismo nombre que utiliza Sublime para identificar ese lenguaje, por ejemplo JavaScript, PHP o HTML, tendremos la ventaja añadida de que sin necesidad de especificar el scope del snippet quedará ya asociado automáticamente a dicho lenguaje.. Para abrir y editar nuestros snippets posteriormente, por defecto se guardarán en la carpeta Packages / User.

Al definir nuestro snippet, el nodo tabTrigger es la “palabra de activación” que escribiremos y al presionar la tecla TAB se expandirá en nuestro snippet. Un detalle adicional: en el menu flotante de añadir snippet, además del tabTrigger se muestra en nombre del archivo donde hemos guardado el snippet, así que es interesante utilizar nombres concisos y sobre todo informativos de qué es lo que este snippet hace exactamente.

Insertando Snippet desde la paleta de Sublime se aprecia la importancia del nombre de archivo y el tabTrigger

Programando snippets

En el nodo content del XML meteremos el código del snippet en sí, utilizando la sintaxis de textmate para crearlo. Podemos definir stopPoints con el símbolo $:

$1, ${2:valor por defecto}, $3

y el orden relativo entre los índices que les asignemos a las stopPoints será el orden en el que el cursor se moverá de una zona a otra al pulsar la tecla tabulador. Lo bueno de los valores por defecto es que cuando nos movemos sobre ese stopPoint, se selecciona el valor por defecto entero, de forma que al pulsar cualquier tecla para seguir programando se sustituye automáticamente. Por ejemplo, este es el Snippet que utilizamos para crear una función Event Listener en ActionScript 3:


	
	eventl

Si mientras que estamos programando en AS3 tecleamos “eventl” y después pulsamos TAB, el Snippet anterior se insertará en nuestro código. A continuación, el cursor se colocará en el primer stop point, y cada vez que pulse TAB se moverá al siguiente. El código que se insertará será:

  private function onClick(e:Event):void
  {

  }

Y el cursor estará inicialmente seleccionando la palabra Click de manera que si yo tecleo cualquier cosa la sobreescribiré automáticamente, al pulsar la tecla TAB el cursor saltará a Event otra vez seleccionada para ser sobreescrita, y por último con el siguiente TAB saltará al cuerpo de la función, respetando la indentación.

La clave para mejorar y acelerar nuestro workflow gracias a los snippets es ser persistentes y forzarnos a utilizarlos de forma constante. ¡Esperemos que este post os ayude!

Conferencia AlicantePHP: Proyectos PHP de éxito en nitsnets | studios

elad — Tue, 16 Apr 2013 10:20:46 +0000

Ayer 15 de abril tuvimos el honor de ser invitados a impartir una conferencia / charla entre el nuevo grupo de usuarios de PHP en Alicante. Eran las primeras jornadas que el grupo realizada y se impartieron dos conferencias. Enhorabuena a Raúl Fraile y Manuel L. Jurado por crear este tipo de eventos #alicantephp.

En este post resumiremos un poco las jornadas y contaremos las utilidades PHP que se comentaron así como en qué proyectos fueron utilizadas.

Las conferencias empezaron a las 19:00 en el espacio de coworkers The Green Bees con una pequeña introducción por parte de Raúl Fraile al Grupo de usuarios de PHP en Alicante. La verdad es que la asistencia no estuvo mal para ser el primer evento, es más casi rozábamos el aforo completo!!!
Fue una grata sorpresa encontrarme allí a parte de mi equipo (Eli Padilla, Pere Monerris y Ramón Muñiz), a mi amigo José Manuel Pérez experto en PHP y compañero de trabajo en el master de la Universidad de Alicante PROWEB y a otra mucha gente conocida que habíamos coincidido en alguna oportunidad.

Conferencia: Proyectos de éxito en nitsnets | studios

Después de la breve presentación fue mi turno de explicar nuestra experiencia en PHP y por qué decidimos orientarnos en esta tecnología. En alguna ocasión hemos tenido la oportunidad de hablar de nuestro emprendimiento con nitsnets | studios y cómo llegamos a formar la empresa pero nunca nos habíamos centrado en la importancia del lenguaje de servidor PHP.

nitsnets | studios es una empresa de desarrollo web y nuevas tecnologías que ha desarrollado más de 300 proyectos online a lo largo de sus 7 años de vida; desde el inicio y hasta el día de hoy siempre se ha confiado en PHP para todos los desarrollos y proyectos.

Desde el principio pensamos que era importante la reutilización de código y la estructura de trabajo. En 2007 con el arranque de la empresa empezamos como muchas otras con un framework propio: nts | framework. Tenía una estructura piramidal con distintos componentes (datagrid, combobox con ajax, tratamiento de imágenes…) y creamos un ORM lineal para el tratamiento de base de datos mediante el mapeo de entidades del EER a objetos en PHP. Ni siquiera era MVC (Modelo Vista Controlador). Con este framework se realizaron gran cantidad de proyectos como resources.maxwellrender.com, www.redshark-fuerteventura.com, www.elenarubio.es, www.novelda.es…

En poco tiempo nos dimos cuenta que el framework no era lo suficientemente potente, lo suficientemente escalable y reutilizable; pese a que muchos empleados les encantaba

Hacer un framework al nivel que necesitábamos era un proyecto inmenso en sí y decidimos ¿por qué reinventar la rueda? A finales de 2008 nos metimos de lleno con Symfony 1.1 con un proyecto inmenso como fue Openart, la red social de arte. El proyecto se complicó por su envergadura en sí y además porque la curva de aprendizaje de Symfony fue un poco más lenta de lo normal. Eso sí, el resultado fue un éxito. Actualmente Symfony 2 es considerado uno de los mejores del mercado.

Un poco más tarde, en 2009, empezamos con proyectos pequeños y gestores de contenido con CodeIgniter. La curva de aprendizaje fue tremendamente rápida y todos los empleados (en aquella etapa, siete) aprendieron en apenas una semana; era similar a PHP nativo pero bien organizado.

CodeIgniter fue gradualmente sustituyendo a nts | framework y a Symfony para proyectos grandes, quedándose como el único framework PHP utilizado en la empresa que cada vez contaba con más códigos, librerías y objetos propios dentro de CodeIgniter. Este cambio de framework en la empresa lo explicamos en un polémico post: Frameworks PHP Symfony vs CodeIgniter en dos casos de éxito

A partir de 2009 todos los proyectos fueron desarrollados en este framework CodeIgniter: nosplay.com – red social de videojuegos, plazatio.com – red social oficial del CTAA de arquitectura, portaventura.es, panamajack.es, puralopez.com, comoquierascolacao.com y muchísimos más…

Sobre este tema lo tratamos con más detalle en dos artículos, uno sobre frameworks PHP y otro de nuestro proceso de selección de tecnología y frameworks

En nuestro afán de seguir mejorando estamos evaluando muy seriamente la migración nuevamente a otro framework PHP: Laravel 4. Una muy buena estructuración de objetos y una maravilla que echábamos de menos: los bundles. Paquetes de código con su propia configuración, rutas, migraciones, tareas, etc; pueden ser desde un ORM de base de datos, un sistema de autentificación, etc. La modularidad gracias a los bundles puede ser el éxito de este framework, un concepto que aprendimos en Symfony 2 y es algo que buscábamos y añorábamos en CodeIgniter desde hace tiempo.

Además la migración de CodeIgniter a Laravel es tan inmediata como fue para nosotros el cambio de PHP nativo (nuestro framework) a CodeIgniter. En nuestro ámbito empresarial esto es vital para seguir facturando desde el primer día. ¿Será el 2013 el año de Laravel? Esperamos poder contaros en breve

Librerías PHP

Después comentamos algunas de las librerías que utilizamos en nitsnets | studios y que os pueden ser de mucha utilidad.

Wick HMVC. Todos nuestros proyectos tienen un sistema de High MVC donde partimos de la base que las URLs son únicas y que el controlador principal detecta la URL en cuestión e indica que controlador tiene que aplicar haciendo de dispatcher. Esta utilización la explicamos en otra conferencia: La industrialización en la web.
Esto también se puede conseguir con esta extensión de CodeIgniter HMVC
Smart Image Resizer Tratamiento de imágenes. Un tratamiento que utilizamos en todos los proyectos e incluso lo incluimos en el htacces para poder utilizarlo pero con un SEO de imágenes optimizado. Esto también se vio en la conferencia: La industrialización en la web.
NuSOAP Web Services Toolkit para PHP.
SoapClient Con esta librería nativa de PHP integramos una pasarela de pago intermedia como es PayTPV una utilidad muy necesaria para la máxima conversión de ventas en los ecommerce internacionales.
SimplePie RSS-Atom Feed Parsing. En nuestra plataforma de creación de periódicos y revistas digitales Gopress parseamos las RSS e incluíamos noticias de otros medios mediante el feed. También en nosplay.com extraemos las noticias automáticamente de los blogs registrados.
PHP-ExcelReader Lectura/escritura de ficheros de Excel. Todos nuestros gestores de contenidos CMS tienes funciones de exportar datos en formato Excel ya que los departamentos de marketing y de dirección los necesitan.
DOMPDF HTML to PDF renderer. Por ejemplo en Panama Jack generamos tarjetas de regalo en PDF.
Zend_Gdata_YouTube Conexión con los GData de Google como en Youtube.
Twitter Oauth Conexión con la API de Twitter.
html_to_text Helper que convierte un documento HTML en texto plano. Muy útil para tener un único cuerpo en la generación de emails automáticos de nuestras aplicaciones.
OpenTok Servicio de videoconferencia OpenTok. Este servicio lo utilizamos en Reworklution.com donde puedes videoformarte con profesionales en directo o la videoformación de las promotoras en la innovadora empresa Global Field Marketing

Gracias a todo mi equipo de nitsnets por reunir y agrupar estos conceptos, especialmente a Alejandro Such que me ha ayudado mucho en esta pequeña charla.

Conferencia: Introducción a PHPUnit

Manuel Jurado nos hizo una introducción a la utilización de PHPUnit y lo importante que son las pruebas en el desarrollo web. Me impactó una frase que decía: “lo costoso o difícil no es utilizar PHPUnit sino realizar unas buenas pruebas unitarias”.

Ahora ya no hay excusas para este best practice y hay que realizar test; sobretodo si tienes un proyecto único

Regalitos y cervezas

Al finalizar se realizó el sorteo entre los asistentes de 3 flamantes libros los cuales recomendamos:

Este tipo de regalos se pudieron realizar gracias a los patrocinadores del evento de entre los cuales nitsnets | studios esta orgulloso de poder participar.
Otros patrocinadores son el máster Curso de Especialista Universitario en Programación Web PROWEB de la Universidad de Alicante, The Green Bees – espacio coworking en Alicante y Server Grove – Servidores especialistas en PHP.

Por último continuó el networking con unas cervecitas y cocacolas así como unas partidas a un futbolín donde vimos que no somos tan frikis

Tutorial de Ember: Screencast paso a paso

danii — Mon, 15 Apr 2013 08:21:00 +0000

Cuando presentamos el framework JavaScript Ember.js ya comentamos que uno de los principales problemas de este framework era la dificultad de hallar buenos recursos de aprendizaje actualizados y por tanto los inicios eran (por decirlo suavemente) un tanto duros. Sin embargo, también advertimos de que los creadores del framework eran conscientes de ello y por tanto podíamos esperar interesantes mejoras y novedades al respecto. Pues bien, Tom Dale, uno de los autores del framework, se ha puesto manos a la obra y ha grabado un fantástico screencast de introducción a la programación de una Web App JavaScript en Ember.

En este screencast se programa “en directo” una mini aplicación de blogging con Ember.js partiendo prácticamente desde cero. En este post vamos a seguir el screencast paso a paso, comentando el código y las funcionalidades que se van añadiendo. Este tutorial es un ejemplo muy práctico, así que os recomendamos que intentéis seguir el video a la vez que programáis la App y podéis utilizar este post como guía de consulta adicional.

Ver Demo Finalizada

Como referencia, os mostramos el que será el resultado final de la aplicación que se construye en el screencast, más un par de adaptaciones y mejoras que hemos decidido añadir nosotros y que comentaremos durante el desarrollo:

Os recomendamos que no “hagáis trampas” y echéis mano del código fuente que os proporcionamos y que intentéis seguir el screencast y nuestro step by step programando vosotros cada paso. La idea es aprender Ember siguiendo un ejemplo práctico relativamente sencillo.

ScreenCast

Archivos iniciales

Hemos preparado un zip Starting Point con los archivos que necesitamos para empezar con este tutorial. Hemos tomado como base el Starter Kit de Ember.js al que le hemos añadido los siguientes archivos que se van a utilizar para el desarrollo de la aplicación:

El ubicuo twitter bootstrap CSS para tener una base de estilos CSS agradable sin esfuerzo,
La genial librería moment.js para formatear fácilmente datetimes de JavaScript de forma friendly para personas humanas,
La librería showdown.js, para parsear texto en formato markdown y convertirlo a HTML, ya que utilizaremos este formato para almacenar nuestros posts en el modelo,
Y por último Ember data en su última versión Revision 12, ya que sorprendentemente no está incluído en el Starter Kit antes mencionado.

Además, hemos eliminado el código inicial de prueba con el que viene la app del Starter Kit y hemos dejado una única línea:

  App = Ember.Application.create();

Y tambien hemos substituido las templates iniciales del Starter Kit por la template inicial estática que se muestra en el video.

Descarga aquí el zip Starting Point, descomprímelo y abre el archivo index.html en el navegador (inicialmente no es necesario cargarlo desde un servidor web). Deberías encontrarte el menú de navegación superior y el resto de la pantalla en blanco, pero que todos los archivos necesarios están cargados. Este será nuestro punto de partida:

En este momento podemos empezar a apreciar la magia de Ember: no hemos programado más quen una línea de código de la aplicación, en la que simplemente la hemos inicializado, y hemos añadido una template sin ningún tipo de vinculación a este objeto JavaScript App, y sin embargo el framework Ember.js es lo suficientemente inteligente para saber que esta única plantilla que encuentra es la que tiene que renderizar.

Como se observa en el menú de navegación, nuestar App va a tener dos secciones o páginas principales:

Posts, que incluirá un listado de posts siguiendo un patrón Master-Detail. No es casualidad que nuestra app de intro a Ember y esta estén ambas basadas en Master-Detail, ya que el Router de Ember se adapta muy bien a las características de este patrón tan utilizado, como veremos más adelante.
About, una página con información estática donde presentaremos a los autores del blog, que en este caso vamos a personalizar con nuestras biografías

La Sección About

En este primer paso vamos a centrarnos en la sección About. Primero, crearemos un template de Handlebars con el contenido estático de la sección (en este caso, una presentación del blog y unas mini biografias nuestras como autores) y la añadimos al HTML:

Nota: Aunque en el screencast se utiliza el atributo id=”about” para asociar el template a su ruta, nosotros hemos preferido utilizar el más explícito data-template-name=”about” ya que ambos tienen exactamente el mismo funcionamiento y vemos dos ventajas: primero, nos parece más explicativo y además, preferimos evitar un riesgo de colisiones con otros elementos del DOM.

Para que Ember muestre un template, tenemos que tener una ruta asociada a éste, así que vamos a a definir un objeto Route de Ember super simple, con una única ruta que representa esta sección:

  App.Router.map(function() {
    this.resource('about');
  });

Y aquí entra otra vez en juego la magia de Ember: al haber definido una ruta con nombre ‘about’ y un template con ese mismo nombre ‘about’, Ember ya sabe que esta ruta y este template están asociados, sin necesidad de que yo tenga que definir esta relación en escribiendo código.

Para mostrar este template, debemos hacer dos adiciones en nuestro template principal:

Sustituimos el link estático
```
  About
```
por un un link a la sección about recien creada en el Router utilizando el helper de Handlebars {{#linkTo}}:
```
  {{#linkTo 'about'}}About{{/linkTo}}
```
y añadimos también el helper {{outlet}} que podríamos definir como simplemente un placeholder que indica a Ember en qué punto de la plantilla actual debe renderizar el contenido de la sección.

De esta manera, el template principal queda de momento así:

y al entrar en la sección about (pinchando en el link del menú de navegación o escribiendo en la barra de dirección del navegador /#/about) veremos esto:

Lista de Posts (Master)

Puesto que esta sección no es estática como la anterior, necesitaremos definir un modelo y un Store de datos:

  App.Store = DS.Store.extend({
    revision:12,
    adapter: 'DS.FixtureAdapter'
  });

DS.FixtureAdapter nos permite especificar todo nuestro modelo de datos de manera estática como objetos JavaScript. Es perfecto durante fases del desarrollo inicial para trabajar de manera ágil, podríamos decir que son una “simulación” de carga de datos y que posteriormente podemos susutiurlo sin ningún tipo de fricción por un RESTAdapter que cargue los datos dinámicos del server mediante un servicio REST.

Definimos el modelo en sí:

  App.Post = DS.Model.extend({
    title: Ds.attr('string'),
    author: Ds.attr('string'),
    intro: Ds.attr('string'),
    publishedAt: Ds.attr('date')
  });

Nota: Hemos simplificado un poco el modelo con respecto al que aparece en el screencast agrupando los atributos extended e intro en uno al que hemos llamado fullText

Y a continuación añadimos los FIXTURES es decir datos que van a cargar:

App.Post.FIXTURES = [{
    id:1,
    title: "Mejoras de usabilidad en el ecommerce. Panama Jack",
    author: "elad",
    publishedAt: new Date('4-8-2013'),
    fullText: "..."
},
{
    id:2,
    title: "Introducción al framework Ember.js",
    author: "danii",
    publishedAt: new Date('4-3-2013'),
    fullText: "..."
}];

Para que exista esta sección de posts, añadimos un resource ‘posts’ en el Router, que quedará así:

  App.Router.map(function() {
    this.resource('about');
    this.resource('posts');
  });

Tambien debemos especificar que este modelo de datos que acabamos de crear es el que debemos utilizar para esta ruta, para ello extendemos el objeto Ember.Route y le indicaremos que cargue el modelo:

App.PostsRoute = Ember.Route.extend({
    model: function() {
        //return all elements in model
        return App.Post.find();
    }
});

Y con esto ya hemos implementado toda la funcionalidad necesaria para esta sección en nuestra App, tan sólo nos queda definir su template y linkarla desde la navegación, para esto una vez más hemos cambiar el link estático del template principal por el helper {{linkto}}, en este caso a la sección ‘posts’.

A continuación tenemos que crear una template con template-data-name=”posts” y puesto que el nombre de la ruta y el nombre del template coinciden Ember ya sabe que ambos van asociados. Great!

En este template listaremos todos los posts que tenemos, para ello utilizaremos el helper de Handlebars {{#each}} que itera por cada elemento del modelo de datos y renderiza la parte del template que contiene por cada uno, utilizándolo como contexto. El template quedará por tanto así:

Y ya tenemos la vista Master

Vista Detail de los Posts

Ahora tan solo nos falta que se cargue la vista Detail de cada post individual al seleccionarlo del listado. Vamos a añadir al Router una ruta anidada (nested route) dentro de la ruta ‘posts’ que represente a cada post individual:

App.Router.map(function() {
  this.resource('about');
  this.resource('posts', function() {
    this.resource('post', { path: ':post_id' })
  });
});

Y ahora en el HTML creamos una plantilla template-data-name=”post” asociada a esta ruta:

A continuación tenemos que linkar desde el listado Master de posts a esta plantilla recién creada, para ello sustitumos la linea donde teníamos los links estáticos con el tag a que habíamos dejado por el helper {{#linkTo}}, que quedará así:

  {{#linkTo 'post' this}}{{title}}{{/linkTo}}

En este caso hemos de pasar un parámetro this al helper, que representa el contexto actual, es decir el modelo de datos que debe mostrar el template. El último paso será añadir el helper {{outlet}} en el lugar del placehoder que habíamos colocado en la plantilla Master, para que Ember sepa dónde debe renderizar la vista de la ruta anidada.

En este momento debemos poder clickar en cada uno de los posts de nuestra lista y se cargará el contenido asociado a este post:

Formato mediante Helpers de Handlebars

Por supuesto, hay un par de problemas obvios de formato actualmente:

La fecha de publicación del post se muestra algo parecido a: (Mon Apr 08 2013 00:00:00 GMT+0200 (CEST)) lo cual es un formato de fecha no demasiado legible para el usuario (horrible, vamos);
Y el contenido del post sale en formato Markdown, obviamente, ya que lo tenemos almacenado así en nuestras Fixtures, cuando lo ideal es que se renderice en el navegador como HTML.

Para dar formato a estos elementos utilizaremos las librerías JavaScript moment.js y showdown.js respectivamente, y lo haremos integrándolos dentro de un par de helpers propios de Handlebars que realizarán estas tareas y que posteriormente incluiremos en el template.

Primero, definimos un BoundHelper de Handlebars mediante Ember.Handlebars.registerBoundHelper, este tipo de Helper es perfecto para datos dinámicos ya que se comporta como un observer de los datos que muestra y se actualiza automáticamente si estos datos cambiasen. En el screencast podéis ver una demo de este comporamiento.

El primer parámetro de la función registerBoundHelper será el nombre del helper, y el segundo la función que dará formato a los datos que recibe como parámetro y posteriormente los devolverá ya formateados. Utilizaremos la función fromNow() de moment.js para mostrar el tiempo que ha pasado desde la fecha de publicación del post. Además, vamos a aprovechar la potencia de i18n de moment.js para mostrar el lapso de tiempo en castellano, ya que nuestros posts van a estar escritos en la lengua de Cervantes

moment.lang('es',
{
  relativeTime: {
    past : 'hace %s',
    s : "unos segundos",
    m : "un minuto",
    mm : "%d minutos",
    h : "una hora",
    hh : "%d horas",
    d : "un día",
    dd : "%d días",
    M : "un mes",
    MM : "%d mes",
    y : "un año",
    yy : "%d años"
  }
});

Ember.Handlebars.registerBoundHelper('date', function(date) {
  return moment(date).fromNow();
});

Y substituimos {{publishedAt}} por la llamada al helper: {{date publishedAt}}

A continuación, seguimos los mismos pasos para mostrar el texto del post en formato HTML, con la particularidad de que tenemos que utilizar un Handlebars.SafeString ya que por defecto las plantillas en Ember van a escapar todo su contenido por razones obvias de seguridad:

//creamos objeto converter
//para pasar de markdown a HTML
var showdown = new Showdown.converter();

Ember.Handlebars.registerBoundHelper('markdown', function(input) {
  //devolvemos SafeString para que no escape el contenido HTML
  return new Ember.Handlebars.SafeString(showdown.makeHtml(input));
});

E invocamos al helper al mostrar el texto del post, es decir sustituimos {{text}} por: {{markdown text}}.

Y finalmente deberíamos ver el post con un formato correcto:

Añadimos Modo Edición

Hasta este punto nuestra aplicación es Read-only, pero en este momento vamos a añadir un modo de edición para poder editar el texto y títlo de los posts on the fly y además mostrando un live-preview de estos cambios en la vista principal del post, ya que vincularemos los datos mediante Data Binding. ¡Brutal!

Lo primero será añadir un botón de edit en el template del post. Para distinguir entre los estados de edición y visualización utilizaremos los helpers de Handlebars {{#if}} que renderiza una parte del template de forma condicional, y {{action}} para invocar una función del controlador:

    {{#if isEditing}}
      Edit mode
      
    {{else}}
      
    {{/if}}

Y a continuación debemos crear esta variable de estado booleana isEditing, así como las funciones edit y doneEditing en el controlador. Fijaros que este controlador que se encarga de la vista Post no lo he tenido que implementar hasta que no he necesitado un comportamiento adicional. Esta es la base de la filosofía de Ember: implementar sólo los objetos que necesite, del resto ya se encarga el framework. Al crear un objeto con el nombre PostController, el framework ya sabe que estará asociado a la vista y los datos del Post.

En este caso extenderé a la clase Ember.ObjectController ya que este controlador tiene como modelo un único post (no un array de posts) e implementaré las funciones que hacen un toggle entre el modo de edición y no edición. Además vamos a hacer un commit de todos los cambios que se hagan en el modelo, de manera que cuando estemos listos para guardar los datos y sustituyamos el FixtureAdapter por un RESTAdapter se realicen las llamadas al server:

App.PostController = Ember.ObjectController.extend({
    isEditing: false,
    edit: function()
    {
      this.set('isEditing',true);
    },
    doneEditing: function()
    {
      this.set('isEditing',false);
      //save to server
      this.get('store').commit();
    }

});

El siguiente paso será mostrar una UI para editar el post cuando esté en modo edición. Para mantener nuestro template de post sencilla, vamos a hacerlo de manera modular incluyendo un parcial o template externo mediante el helper {{partial}}. Por convenio, los nombres de template de los parciales empiezan siempre por “_” para distinguirlos del resto de templates. En este parcial vamos a utilizar los helpers view que se encargan de renderizar una vista, y las vistas predefinidas de EmberEmber.TextField y Ember.TextArea, por supuesto vinculadas mediante Data Binding al título y al texto del post respectivamente:

Y en volvemos al template del post para indicarle que debe incluir este partial cuando esté en modo edición:

  {{#if isEditing}}
    Edit mode
    {{partial 'post/edit'}}
    
  {{else}}
    ...

¡Y ya lo tenemos! Casi sin esfuerzo hemos añadido un modo de edición en el que además, como todos los datos con lo que estamos trabajando están vinculados, el post que estamos mostrando se actualizará on the fly automáticamente.

Una pequeña mejora de Usabilidad

Un pequeño detalle que podemos mejorar es que cuando entramos a la ruta posts, por ejemplo desde el botón de navegación superior, nos vamos a encontrar con una pantalla casi vacía como hemos visto anteriormente:

Lo cual no es un para nada un ejemplo de buena usabilidad. Para solucionar este problema, debemos especificar a Ember el contenido que debe mostrar en la ruta por defecto de Posts, es decir cuando no hay ningún post seleccionado. Esta ruta en Ember se llama por convenio /index, así que en este caso por ejemplo debemos llamar a nuestro template posts/index.

Una opción sería crear una plantilla placeholder que indique al usuario lo que debe hacer:

Y quedaría así:

Lo cual es ciertamente mucho mejor y es la opción que se toma en el screencast, pero a nosotros tampoco nos ha convencido.

En nuestra opinión, el comportamiento más adecuado para la usabilidad sería que se cargara automáticamente por defecto el post más reciente. Para ello, lo que vamos a hacer un redirect de esta ruta posts/index a la ruta posts/:post_id con los valores del último post del modelo de datos. Por tanto, puesto que estamos alterando el comportamiento por defecto, tenemos que definir el objeto PostsIndexRouter y dentro haremos las siguientes operaciones:

Tomaremos el primer elemento del modelo de los posts, que será el último post publicado,
A continuación haremos una transitionTo a la ruta ‘post’ con el modelo que antes hemos seleccionado.

El código quedaría así:

App.PostsIndexRoute = Ember.Route.extend({
  redirect: function () {
    var posts = this.modelFor('posts');
    var post = posts.get('firstObject');

    this.transitionTo('post', post);
  }
});

Pero no está todo bien aún, ya que nos vamos a topar con otro problema: con este código, es posible que el router de Ember intente hacer un redirect antes de que el modelo esté completamente cargado, con lo cual saltará un error en tiempo de ejecución y el redirect fallará. Para solucionar este problema, hemos tomado la decisión de tener una precarga de datos mediante bootstrapping de forma que si el primer post no ha sido cargado a la hora de hacer un redirect, lo tome del bootstrap. Añadiendo esta mejora en el código anterior, quedaría así:

App.PostsIndexRoute = Ember.Route.extend({
  redirect: function () {
    var posts = this.modelFor('posts');
    var post = posts.get('firstObject');

    if(!post)
    {
        console.log("LOADING bootstrap'ed DATA");
        DS.get('defaultStore').load(App.Post, bootstrap);
        post = App.Post.find(1);
    }

    this.transitionTo('post', post);
  }
});

Donde bootstrap es simplemente un objeto JavaScript donde hemos incluido los datos del último post. En producción esta variable será creada con datos dinámicos extraídos del server, claro

Redireccinamos Index

Relacionado con el paso anterior, al entrar a la index de la aplicación lo ideal sería que nos redireccionara a la lista de posts directamente (y si habéis implementado nuestra mejora, mostrara la vista Detail del primer post). Para esto, simplemente vamos a definir la ruta por defecto de la aplicación para que vaya a la ruta ‘posts’ similarmente a como hemos hecho el redirectTo en el paso anterior:

  App.IndexRoute = Ember.Route.extend({
    redirect: function () {
      this.transitionTo('posts');
    }
  });

Final: Conectando con server REST

Este último paso no lo vamos a terminar en este ejemplo ya que no tenemos un servicio REST implementado en el servidor de este blog, pero podéis observar en el video que simplemente cambiando ‘DS.FixtureAdapter’ por DS.RESTAdapter y especificando a qué URL tiene que atacar para que el server le pase los datos, ¡ya debería estar funcionando sin tocar ni una línea de código más! El resto de problemas, para el equipo de backend

Conclusión

Esperamos que este step by step así como el código que os mostramos os resulte útil y os ayude a seguir el screencast y a sumergiros en el mundo de Ember. Como ya comentamos en nuestra anterior intro a este framework, nos parece que Ember tiene un potencial enorme y aunque muchas cosas todavía “crujen” al estar el framework en fase de desarrollo, estamos convencidos de que se puede apostar por él ya como una alternativa más que viable para producción de Web Apps JavaScript profesionales.

Backgrid, componente Datagrid para Backbone

danii — Wed, 10 Apr 2013 09:00:00 +0000

Backgrid es un componente Datagrid para el framework Backbone, pensado para construir widgets datagrid que sean semánticos y fácilmente adaptables. Al igual que al trabajar en el framework Backbone, la filosofia de este componente es que las tareas comunes sean fáciles de llevar a cabo, y a su vez posibilitar la realización de tareas difíciles o más especializadas posibilitando una fácil personalización y extensión de sus elementos.

Las principales ventajas de Backgrid son las siguientes:

Poca o nula curva de aprendizaje, ya que trabaja con simples modelos, colecciones y vistas de Backbone así que si ya estamos familiarizados con este framework no nos costará nada hacernos con el componente.
Vista fácilmente personalizable. Al ser el template una tabla HTML es muy fácil de customizar los estilos via CSS, ya sea a nivel de cabecera (th) o fila (tr).
Totalmente modular. Por supuesto, al igual que Backbone, es super liviano (lightweight) pero fácilmente extensible.

Demo: Datagrid con listado de Libros

Vamos a ver un mini ejemplo muy reducido con tan solo seis filas pero esperamos que sea ilustrativo para ver cómo funciona el componente. El valor de cada celda se puede editar haciendo click sobre ella, y al hacerlo sobre la cabecera podemos ordenar los datos en función de los valores, excepto en el caso de la columna Imagen, que para esta demo hemos pensado que no tenía mucho sentido esta funcionalidad. Demo en funcionamiento:

El Modelo

El modelo que hemos utilizado para este ejemplo va a ser el mismo que usamos en las otras demos de los frameworks JavaScript. El objeto JSON con los datos que vamos a cargar del server será:

[
   {
     'id': 1,
     'titulo': 'El Juego de Ender',
     'autor': 'Orson Scott Card',
     'editorial': 'Ediciones B / Zeta',
     'img': 'img/img1.jpg'
    },
    {
     'id': 2,
     'titulo': 'Juego de tronos',
     'autor': 'George R. R. Martin',
     'editorial': 'Gigamesh',
     'img': 'img/img2.jpg'
    },
    {
     'id': 3,
     'titulo': 'I robot',
     'autor': 'Isaac Asimov',
     'editorial': 'Edhasa',
     'img': 'img/img3.jpg'
    },
       ...
]

Para cargar el modelo, tan solo tenemos que definir la URL desde donde fetchearemos del server. El código es exactamente igual que al cargar un modelo de Backbone.js (que, de hecho, es lo que estamos haciendo!):

  var Libro = Backbone.Model.extend({});

  var Libros = Backbone.Collection.extend({
    model: Libro,
    url: &quot;data/libros.json&quot;
  });

  var libros = new Libros();
  //cargamos modelo
  libros.fetch();

  //Inicializamos Datagrid
  var datagrid = new Backgrid.Grid({
    columns: columns,
    collection: libros
});

Una vez hemos definido el modelo y las columnas que vamos a visualizar, podemos inicializar el objeto Backgrid, que se comportará como una Backbone.View. De esta manera, posteriormente el modelo se cargará de forma totalmente asíncrona desde el server y nuestro objeto datagrid se actualizará con los datos.

Las Celdas

Backgrid viene por defecto con 10 tipos de celda predefinidos, con comportamientos y formatos asociados según el tipo de datos que pueden contener. Las celdas son editables por defecto al clickarlas, y la mayoría contienen algún tipo de lógica para presentar sus datos de manera legible y friendly para personas humanas. Para información más exhaustiva, os recomendamos por supuesto echarle un ojo a la API de las celdas.

Por supuesto, podemos customizar extensivamente estos elementos, por ejemplo un NumberCell adaptado al formato locale hispano de números (que sería el contrario que el anglosajón, es decir coma para separar decimales y punto para separar los miles, millones etc) puede definirse así:

  //Extendemos NumberCell para adaptarla
  //al formato locale hispano
  cell: Backgrid.NumberCell.extend({
    orderSeparator: '.',
    decimalSeparator: ','
  })

Es además muy sencillo utilizar objetos formatters para definir y adaptar estos tipos de celda añadiendo comportamientos adicionales que necesitemos. Por poner un ejemplo, en nuestra demo hemos decidido que vamos a mostrar en el front los títulos de los libros en mayúsculas, independientemente de cómo nos vengan en en modelo desde el server. Para ello, hemos definido un objeto formatter que simplemente debe implementar un método fromRaw para formatear los datos que nos vienen en el modelo, y otro toRaw para quitar el formato que hemos añadido y que no se guarde en el server.

    //Extendemos StringCell para asginarle un obj formatter custom
    cell:  Backgrid.StringCell.extend({
      formatter:
        {
          toRaw: function(formattedValue) {
            return formattedValue.toLowerCase();
          },
          fromRaw: function(rawValue) {
            return rawValue.toUpperCase();
          }
        }
    })

Por supuesto las celdas al fin y al cabo extienden de la clase Backbone.View, así que podemos modificar totalmente cómo se renderizan definiendo templates para la clase e implementando el método render, como haríamos con cualquier View de Backbone.

En nuestro caso hemos utilizado este sistema para conseguir que aparezcan en el DataGrid las imágenes thumbnail de los libros, para lo que nos hemos definido una mini-plantilla de Underscore.


  //Extendemos StringCell para asignar una template custom
  //en este caso, img tag
  cell: Backgrid.StringCell.extend({
      template: _.template('&lt;img width=&quot;32&quot; height=&quot;50&quot; src=&quot;&lt;%= img %&gt;&quot; /&gt;'),

      render: function() {
        this.$el.html(this.template(this.model.attributes));
        return this;
      }
  })

Como podéis observar, un sistema realmente potente que nos permitirá en todos los casos encontrar una celda que se adapte a nuestras necesidades, o customizarla de manera simple y efectiva si lo necesitamos.

Demo: Datagrid con extensión Paginator

¿Qué sería de un componente datagrid si no soportara paginación de los datos? Por supuesto Backgrid tiene una extensión pensada para esta tarea. Para utilizarla, debemos definir nuestra colección de datos como Backbone.PageableCollection que es una genial extensión de Backbone.Collection con funcionalidad adicional de paginación realizada por el mismo autor de Backgrid.

En este componente es el modelo el que debe que proveer, además de los datos, la información necesaria para las funciones de paginación, es decir la página actual, el número de items por página a mostrar y el número total de items, pero podemos personalizar el comportamiento para que la paginación se produzca en el cliente (es decir el server nos mandará un json con todos los datos) o en el server (y tendré que recuperar los datos de las diferentes páginas en sucesivas peticiones al server). El objeto JSON que recibimos del server quedaría por tanto así:

[
    { 'per_page': 2, 'total_entries': 6,
      'total_pages': 3, 'page': 1
    },
    [
       {
         'id': 1,
         'titulo': 'El Juego de Ender',
         'autor': 'Orson Scott Card',
         'editorial': 'Ediciones B / Zeta',
         'img': 'img/img1.jpg'
        },
        {
         'id': 2,
         'titulo': 'Juego de tronos',
         'autor': 'George R. R. Martin',
         'editorial': 'Gigamesh',
         'img': 'img/img2.jpg'
        },
        ...
    ]
]

El resto del código del modelo quedaría igual, excepto el detalle antes mencionado de que en este caso nuestra colección de datos deberá extender de Backbone.PageableCollection

//Inicializamos Datagrid, con paginación
//en el elemento footer
var datagrid = new Backgrid.Grid({
  columns: columns,
  collection: libros,
  footer: Backgrid.Extension.Paginator
});

Y por último la inicialización del objeto Backgrid en la que añadimos un elemento footer que contendrá la extensión paginator con las funciones esperadas de paginación. Great!

Conclusión

Esperamos que este componenete os haya parecido interesante, nos parece que se le puede sacar mucho jugo por la potencia que tiene y su facilidad de customización, ya sea mediante la adaptación de los elementos existentes o creando nuevas funcionalidades mediante extensiones. En resumen, una pequeña joya para nuestras aplicaciones JavaScript.

Mejoras de usabilidad en el ecommerce. Panama Jack

elad — Mon, 08 Apr 2013 08:09:24 +0000

Hace unos pocos días publicamos la nueva versión de uno de nuestros grandes clientes Panama Jack. Entre las nuevas mejoras de esta nueva versión se encuentra un nuevo diseño (realizado internamente por el departamento creativo de Panama Jack) y mejoras de usabilidad.

Durante este artículo reflexionaremos de algunas de estas mejoras de usabilidad a partir del antes y después del ecommerce. Esperemos que os sirvan para conocer más sobre nuestro punto de vista de la usabilidad en las tiendas online.

Antes y después

En principio se puede ver el restyling que se hizo de la home. Podemos observar la web nueva online directamente www.panamajack.es (también en esta captura: Panama Jack home 2013) y podemos observar la home de la web anterior de Panama Jack.

Las modificaciones han sido considerables en todos los aspectos pero nos queremos centrar en algunos elementos de usabilidad.

Nueva cabecera. Menú desplegable on-click

La cabecera además de aplicarse un restyling (como en toda la web) se propuso una reducción considerable del alto para poder ver el producto lo más arriba posible.

Por otro lado se han incluido las subcategorias de hombre y mujer como menús desplegables; consiguiendo así una reducción de clicks, evitando tener que hacer dos clicks en favor de uno sólo.

Se han cuidado otros muchos detallitos como por ejemplo el cambio de mercado / idioma al ser una opción que se autodetecta y no se suele utilizar tiene menos presencia en la web y se puede cambiar las dos opciones de golpe desde un popup interior (antes eran dos desplegables)

Listado de productos. 2 líneas de producto

Mediante la reducción de la cabecera y cuidando el alto (height) del resto de elementos conseguimos el objetivo de ver 2 líneas de producto en el primer impacto visual del listado en la resolución mínima de 1024×768. Hay que tener en cuenta que la resolución del iPAD es de 1024×768 y en el mercado de productos de calidad como es Panama Jack muchas ventas vienen habilitadas desde las tablets de Apple.

El objetivo era ver ocho productos de una tacada para llamar más la atención del comprador consiguiendo que en un primer golpe de vista pudiera interesarse y comprar más productos; eso sí sin dar la sensación de bazar ni bajar en exceso la correcta visualización del calzado, es decir intentando respetar las dimensiones de los zapatos que tan buenos resultados habían funcionado.

Si vemos las estadísticas de resoluciones de pantalla en el desarrollo web con una altura de 580px (altura útil) abarcamos aproximadamente a un 40%, otro 48% incluso vería más productos ya que tendría 700px de alto o más, tan sólo el 2% tiene una resolución inferior al 768px de alto con lo que no apreciarían esta mejora.

Por otro lado se eliminaron los paginadores al más estilo Facebook y con la detección del scroll sigue cargando productos. Sin necesidad de hacer click seguimos viendo productos hasta finalizar la visualización de todos

Filtro de talla/color por AJAX

El filtro de tallas y colores del listado de productos se ha mejorado considerablemente. El filtro se realiza por AJAX sin refresco de página ni botón aceptar, simplemente al clickear se refresca el listado. El usuario espera menos y ve su filtro mucho más rápido. También el ordenar cambia su forma de desplegable a un texto enlace plano con flechitas de arriba/abajo, más sutil y menos intrusivo.

Cuando se aplica un filtro se añade una franja informativa con la actual búsqueda para no perder al usuario, si se le da a la (x) se limpia el filtro y se vuelven a ver todos los productos de la categoría que se esta visualizando. Esta franja se redujo también a una sola línea (anteriormente eran varias).

Eso sí, se quería mantener la posibilidad de copiar URLs (para enviarlas a un amigo, etc) incluso con los filtros aplicados. El objetivo era tener una funcionalidad para compartir el listado de productos con filtros. Se ha utilizado la técnica de deeplinking con #/ para no perder esta importante funcionalidad pasando parámetros por la URL y rescatándolos posteriormente. Así se consigue una increíble funcionalidad que ni una de las mejores tiendas online del mundo como es zara.com la tiene mimada a este nivel

Roll-over en los productos con fotografía en uso

Esta mejora ya se aplicó en una versión anterior al restyling pero nos ha parecido muy interesante mencionarla. Al pasar por encima de un producto en el listado se realiza una sustitución de imagen con animación para ver otra vista del calzado o una visualización del calzado puesto en una persona. Con esta segunda opción de la vista de cómo quedaría puesto esta demostrado que el usuario se siente más atraído y compra más.

Ficha de producto

La ficha de producto se ha modificado también considerablemente (versión nueva ficha de producto vs versión antigua ficha de producto). El objetivo volver a ver todo lo importante del producto en el caso extremo de 1024×768 (con visibilidad de alto útil de 580px). Se tenía que ver todas las fotografías, el producto entero a la perfección y por supuesto el botón de comprar.

La distribución de las miniaturas imágenes secundarias del producto cambia de estar debajo de la fotografía (que a ese golpe de vista no se apreciaba) a la parte de la izquierda. Sustituyendo al menú de categorías que ya no es necesario en esta ficha de producto ya que las encontramos en el menú desplegable.

El carrusel de imágenes se desplaza al pinchar sobre la elección de una imagen, de este modo se carga la nueva imagen y sin tener que desplazar el ratón puedes ir pinchando y viendo todas las vistas o imágenes del producto. Una funcionalidad muy cómoda que mejora la anterior web que tenías que pasar por encima de la miniatura (no hacías click pero obligaba a mover el ratón)

De igual modo en la resolución mínima de 1024×768 la imagen se tenía que ver perfecta y centrada con la vertical. En algunos productos de la anterior web para ver bien el producto había que acabar haciendo scroll sobre la ficha de producto lo cual no genera el mismo impacto.

Carrito de la compra

La cesta de la compra se ha diseñado con el concepto de la bolsa de campaña de Panama Jack con lo que se ha conseguido una cesta más corporativa y más visual.
Su utilidad de todas formas es inferior porque se ha realizado un proceso para evitar tener que pasar por la cesta de la compra para realizar tu pedido mediante one-click.

Botón comprar. En un sólo click al proceso de compra

Normalmente en un proceso de compra en la ficha del producto indicas la cantidad de unidades que quieres del mismo. Pero después de meses analizando nuestro mercado nos dimos cuenta que Panama Jack es un producto de calidad que en la mayoría de los casos se compra un único par. Por eso se decidió eliminar el desplegable de cantidad y así quitar un click al usuario.

En el anterior ecommerce una vez añadido el producto a la cesta; aparecía la cesta en el extremo superior derecha con un botón de comprar, al pinchar sobre el se iniciaba el proceso de compra y checkout. Con el nuevo diseño directamente al pinchar sobre comprar de la ficha de producto iniciamos este proceso de checkout evitando así dos clicks (el de selección de unidades y el de confirmar que quieres comprar). Hemos pasado de 4 clicks a 2 clicks (elección de talla y comprar). De este modo reducimos el tiempo de un usuario en la finalización de la compra y se prevén más conversiones de venta.

Conclusión

Estas han sido algunas de las mejoras que hemos visto interesante contaros y que os pueden servir de utilidad.

En nitsnets | studios cuidamos mucho los detalles de usabilidad dándole vueltas una y otra vez a procesos que pueden ser mejorados; unos procesos que dependen del producto que se vende, el mercado, sus usuarios, etc.

Las mejoras de usabilidad van a repercutir directamente en la utilización del site y producir más ventas con lo cual conseguimos mayor satisfacción del cliente. Esperamos seguir observando y estudiando los procesos para mejorar día a día nuestros ecommerce.

En breve conoceremos si estas modificaciones en www.panamajack.es suponen un nuevo incremento en ventas y en la utilización del site del cual estamos convencidos de ello

Cuatro factores para el éxito de JavaScript

danii — Wed, 03 Apr 2013 10:29:22 +0000

No vamos a esconder nuestra admiración en este blog por Jeff Atwood, afamado autor del blog Coding Horror y cofundador de Stackoverflow y ahora Discourse, una aplicacion JavaScript open source para foros de discusión desarrollada en Ember.js. Precisamente fue en el evento EmberCamp 2013, durante la charla de clausura que Atwood hizo algunas reflexiones muy interesantes sobre el pasado y el futuro de JavaScript y las aplicaciones y el desarrollo web en general.

No olvidemos que fue allá por 2007, con la web 2.0 aún prácticamente en pañales, cuando Atwood publicó en su blog la (narcisísticamente nombrada) Atwood’s Law:

“Any aplication that can be written in JavaScript, will eventually be be written in JavaScript”

¡No se puede ser más profético!

Entre otras cosas, Atwood destaca cuatro factores (ya sean características de JavaScript o circunstanciales) que han contribuido al auge de este lenguaje y su actual popularidad entre los desarrolladores.

Ubicuidad

Javascript ciertamente es un lenguaje de programación anticuado, simple, limitado y no particularmente rápido, pero gana por defecto: todo el mundo tiene o quiere acceder a internet, por consiguiente navega en internet a traves de un navegador, y todos los navegadores ejecutan JavaScript.

“JavaScript is the world’s most ubiquitous computing runtime – Jeff Atwood, 2013”

Podemos decir sin duda que JavaScript ha triunfado donde Java fracasó totalmente, ya que la inmensa mayoría de dispositivos lo ejecutan sin problemas, lo cual nos lleva al siguiente punto:
Increíbles mejoras en rendimiento

Slide con los datos tomada de la presentación de Jeff Atwood

El benchmark de JavaScript Sunspider que en 2007 se ejecutaba en entre 5 y 20 segundos dependiendo del navegador, apenas alcanza hoy en día un tiempo de ejecución de poco más de 100 ms en navegadores modernos. Actualmente, los motores de ejecución de JavaScript siguen mejorando, y aunque el ritmo explosivo de incremento de velocidad de ejecución se ha enfriado un poco, lo cierto es que actualmente JavaScript puede ejecutar CASI cualquier tipo de aplicación en un navegador moderno.

Incluso los dispositivos móbiles, sospechosos habituales, están duplicando su potencia de ejecución en menos de un año actualmente (son los únicos computadores que siguen cumpliendo la ley de Moore) y no tienen problemas en ejecutar código JavaScript cada vez más complejo.
Open Source

El código JavaScript es es abierto por defecto, podemos acceder a él simplemente utilizando –>View Page Source en el navegador, o cualquier herramienta de inspección o desarrollo web. Esto lo convierte en totalmente Open Source, ya que aunque es cierto que el código puede ofucscarse, no hay forma de evitar que sea examinado.

Hace unos años era impensable que una industria software funcionase totalmente basada en código abierto, pero JavaScript y las aplicaciones web están demostrando que no solo es viable sino también muy beneficioso para la comunidad de desarrolladores, al fomentar una dispersión del conocimiento, know-how, buenas prácticas etc.
Web User Experience

El genial http://xkcd.com/1174/

Es cierto que a pesar de las mejoras en rendimiento a las que nos hemos referido anteriormente, una aplicación software nativa (ya sea de escritorio o mobile) siempre se va a ejecutar mucho más eficientemente que una aplicación JavaScript en un navegador. Sin embargo, por el hecho de estar ejecutando nuestra aplicación dentro de un navegador tenemos muchas otras ventajas intrínsecas, principalmente a nivel de experiencia de usuario donde el navegador implementa por defecto funcionalidades que el usuario da por supuestas como copy&paste, bookmarking y compartir fácilmente estados a través de URLs o zoom in & zoom out, omisiones en ocasiones realmente molestas en el caso de aplicaciones mobile.

La conclusión es que la tendencia por tanto será el alejarse de las páginas webs tradicionales basadas en contenido estático presentado mediante HTML y con formato CSS y entrar en el mundo de las aplicaciones JavaScript. El sitio web será cada vez más una aplicación con funcionalidades y menos una página de información estática.

Os dejamos por último con el video completo de la charla (en inglés claro):

Durante la charla y la ronda de preguntas y respuestas posterior se habla también de otros tópicos muy interesantes relacionados con el desarrollo web y el mundo de la web en general tales como Progressive Enhancement y si tiene sentido en el contexto de la web actual, Ruby vs PHP (y que nadie se sorprenda de los palos que recibe PHP), qué le falta al entorno Node.js para terminar de despegar y las comunidades alrededor de un producto que se crean gracias al código Open Source y beneficios asociados, y más. Totalmente recomendable.

Estadísticas resolución de pantallas más utilizadas en la web

elad — Mon, 01 Apr 2013 10:46:19 +0000

Imagen original propiedad del artículo de Punchcut (modificada para añadir 1366×768)

Hace un tiempo que queríamos escribir un artículo sobre las estadísticas de resolución de pantallas más usadas en la web. Estas estadísticas son datos muy importantes para conocer cuales son las dimensiones de pantalla de los usuarios, a qué público vamos dirigidos, etc… y así poder tenerlo en cuenta en la usabilidad de nuestro website.

Con la aparición de los tablets y los smartphones el abanico de tamaños de pantalla se ha expandido considerablemente, apareciendo muchísimas dimensiones diferentes y rebajando incluso los porcentajes de los formatos más estándares.

Desde hace ya unos años en el desarrollo web se ha sustituido en cierta medida el problema de la compatibilidad de navegadores (gracias a que poco a poco todas las compañías se están ciñendo a los estándares con HTML5/CSS3 y otras se basan directamente en web-kit) por el problema de las resoluciones de los dispositivos.

Fuentes de datos. Enero 2013

Las fuentes de datos estadísticos analizadas en este artículo recopilan datos actualizados en Enero de 2013:

Statcounter.com. Basadas en 15 mil millones de páginas vistas al mes (3 millones de sites)
W3schools. Se realizan a partir de las visitas obtenidas durante los últimos 10 años a www.w3schools.com. Hay que tener en cuenta que la web de W3schools es para usuarios interesados en tecnologías web por lo que estos números podrían no ser 100% fiables en un usuario de internet medio, aún así nos permite servirnos de referencia. Estadísticas de resolución de pantalla en la web y Estadísticas de Altas resoluciones de pantalla de los navegadores web
W3Counter Realtime Web Analytics for Websites and Blogs
Screenresolution.org
Netmarketshare.com

Resolución de pantalla de los navegadores web

Durante muchos años el desarrollo web se ha basado en la resolución estándar de 1024×768 (hace apenas 3 años aproximadamente el 40% de los usuarios tenía esta resolución). En la actualidad ya no es la resolución más utilizada, actualmente es 1366×768 es la resolución más usada en internet que es la resolución estándar de Windows 8.

Estadísticas de las resoluciones de pantalla más usadas en Internet (las fuentes de datos coinciden en su tendencia):

resolución	% utilización Enero 2013
1366×768	20-25%
1024×768	10-15%
1280×1024	8-10%
1280×800	8-10%
1920×1080	6-10%
1920×1080	6-10%
800×600	2%

La solución técnica que se le ha dado en el desarrollo web al problema de esta diversidad de resoluciones web se llama Responsive Web Design que nos permite hacer interfaces adaptadas al entorno del usuario mediante estructuras e imágenes fluidas gracias a media-queries de CSS.
Podemos ver algunos increíbles ejemplos en The Next Web: 29 new inspiring responsive designs on the web con ejemplos como la BBC, Disney, Time…

En muchas ocasiones se toma un tamaño mínimo como base para el diseño inicial y a pesar de que ya no es el estándar se sigue desarrollando como base el formato mínimo 1024×768, ya que no se puede despreciar a un 10-15% (no sucede lo mismo con 800×600).

Es fundamental tener en cuenta este tamaño mínimo de 1024×768 para la usabilidad y el primer impacto del usuario. Cómo las barras de navegación y scrolls tienen un tamaño, el área visible y útil de esta resolución sería 990×580 aproximadamente (muy utilizado en la antigüedad con Flash ). Es en esta área donde se mostrará el primer mensaje, lo imprescindible de tu producto, el botón de compra, etc.

De todas formas en nuestra opinión, quizás un tanto polémica, es que el Responsive Web Design es la mejor solución desde pantallas de iMac de 27″ hasta los ipads mini de 7″ o incluso un poco menos; pero cuando se trata de desarrollar para smartphones los procesos deben ser distintos ya que su caso de uso es distinto y por tanto deberíamos crear una versión o vista específica para este tipo de dispositivos, sobretodo si hablamos de e-commerce o software (no tanto en páginas meramente informativas). Así lo hicimos en actiu.com

La mejor fuente de datos: nuestra propia web

De todas formas, aunque todas estas estadísticas son muy interesantes es muy importante estudiar nuestra propia web y nuestros propios usuarios; al final pese a que mundialmente existan unos datos lo mejor es ver quién es nuestro público concreto. Mediante Googe Analytics vamos a poder hacer este estudio viendo las tendencias de nuestros visitantes.

Deberíamos fijarnos también de los usuarios que abandonan la web rápidamente, sus resoluciones y navegadores; quizás su salida del site sea por una mala o no correcta visualización de la web y no tanto porque el contenido no le interesaba. Debemos ser muy sensibles con esto

En nuestro caso en concreto de lostiemposcambian.com los datos de los últimos 30 días son similares a los explicados en el artículo:

Browserstack.com la mejor solución para test en navegadores, dispositivos y resoluciones de pantalla

La solución en la nube de www.browserstack.com a nitsnets | studios nos ha cambiado la vida. Pese a no ser una solución muy rápida es una herramienta que nos está ayudando mucho desde el primer día y 100% recomendable; gracias a mi amigo Josele que nos la descubrió.

Consiste en una solución cloud donde probar nuestro desarrollo web en cualquier navegador web así como en cualquier dispositivo en real (hay muchos). Se acabó tener máquinas virtuales para probar los Internet Explorer antiguos, simuladores de tablets y smartphones, comprar varios dispositivos para pruebas, máquinas virtuales en la oficina, etc…

Aquí podemos ver como se vería lostiemposcambian.com en Windows XP con Internet Explorer 7 a una resolución de 1024×768.

Los Tiempos Cambian

Animaciones y transiciones con AngularJS

Demo: Creación y edición de Slides con animaciones y transiciones

ng directives

Transiciones CSS3 vs Animaciones JavaScript

Secuenciación de Animaciones

Conclusión

Mejorando la velocidad de carga de nuestra web con Google PageSpeed Insights

Utilizando la extensión de Chrome Developer Tools

Puesta en práctica: Mejorando la velocidad de carga de lostiemposcambian.com

High Priority

Medium Priority

Low Priority

Snippets de Gist: de la nube a Sublime

Snippets de Código en la nube gracias a Gist

Filtrando nuestros Snippets de Gist

Snippets de código en Sublime Text 2

Insertando Snippets ya existentes

Importando Snippets mediante Package Control

Creando nuestros snippets

Programando snippets

Conferencia AlicantePHP: Proyectos PHP de éxito en nitsnets | studios

Conferencia: Proyectos de éxito en nitsnets | studios

Librerías PHP

Conferencia: Introducción a PHPUnit

Regalitos y cervezas

Tutorial de Ember: Screencast paso a paso

Ver Demo Finalizada

ScreenCast

Archivos iniciales

La Sección About

Lista de Posts (Master)

Vista Detail de los Posts

Formato mediante Helpers de Handlebars

Añadimos Modo Edición

Edit mode

Edit mode

Una pequeña mejora de Usabilidad

Redireccinamos Index

Final: Conectando con server REST

Conclusión

Backgrid, componente Datagrid para Backbone

Demo: Datagrid con listado de Libros

El Modelo

Las Celdas

Demo: Datagrid con extensión Paginator

Conclusión

Mejoras de usabilidad en el ecommerce. Panama Jack

Antes y después

Nueva cabecera. Menú desplegable on-click

Listado de productos. 2 líneas de producto

Filtro de talla/color por AJAX

Roll-over en los productos con fotografía en uso

Ficha de producto

Carrito de la compra

Botón comprar. En un sólo click al proceso de compra

Conclusión

Cuatro factores para el éxito de JavaScript

Ubicuidad

Increíbles mejoras en rendimiento

Open Source

Web User Experience

Estadísticas resolución de pantallas más utilizadas en la web

Fuentes de datos. Enero 2013

Resolución de pantalla de los navegadores web

La mejor fuente de datos: nuestra propia web

Browserstack.com la mejor solución para test en navegadores, dispositivos y resoluciones de pantalla