aulambra.com

Modularizable, rápido y con soporte multinavegador. Estas tres características tiene que tener todo buen framework de desarrollo de Javascript. Y esos son los tres valores que ha buscado jQuery en su versión jQuery 1.8

Modularidad de jQuery 1.8

Y es que si vas incrementando las funcionalidades de jQuery no puede ser que el framework sea cada vez más pequeño, por lo tanto lo que se ha hecho ha sido modularizar el framework. Esto significa que montaremos el framework con el core y los módulos del framework que realmente estemos utilizando. Consiguiendo quedar el fichero lo más pequeño posible.

Para conseguir esto, la gente de jQuery se ha apoyado en la herramienta Grunt.

Rapidez

En la versión jQuery 1.8 han modificado todo el engine de selectores (parte muy vital del framework), para que este ocupase menos y fuese más rápido.

Soporte Multinavegador

Si estás trabajando con CSS3 te habrás dado cuenta que volvemos a tener una “guerra de navegadores” o quizás, mejor llamada, “guerra de prefijos”. Y que si trabajas con transformaciones, gradientes,… tienes que utilizar los prefijos -moz, -ms, -webkit,….

jQuery 1.8 nos ayuda a olvidarnos de todo el problema de gestión de prefijos y sus métodos de manipulación de css controlan si tienen que insertar el prefijo o no.

Un poco fuera de estos tres pilares también es digno reseñar que están modificando su sistema de animaciones y que en versiones futuras será algo a mejorar. De momento ya tenemos la capacidad de tener callbacks progresivas. Podéis ver un ejemplo de uso de las nuevas animaciones.

Si te gusta mucho el jQuery 1.8 o eres muy friky o tienes mucho tiempo/interés te puedes leer todas las mejoras y bugs corregidos en jQuery 1.8.

Ya solo te queda descargar jQuery 1.8 y empezar a utilizarlo:

• jQuery 1.8 para entornos de producción
• jQuery 1.8 para entornos de desarrollo

Desde hace dos meses que venimos trabajando con la nueva versión de PHP. La versión PHP 5.4.0. Aunque ya tenemos disponibles dos minos releases PHP 5.4.1 y 5.4.2 vamos a ver las principales características de esta versión

PHP 5.4.0 es una major release dentro de la versión 5.x de PHP. Esta nueva versión PHP 5.4.0 viene cargada de un buen número de novedades y de corrección de errores. Dentro de las novedades de PHP 5.4.0 encontramos:

• Uso de Rasgos
• Sintaxis corta para los arrays
• Servidor Web Embebido
• Mejoras de rendimiento y Memoria
• Corrección de cientos de bugs

Uso de Rasgos: Traits

El mecanismo de rasgos permite compartir código en PHP en formato de herencia, pero sin las restricciones de la misma. Ya que el código del rasgo podrá ser utilizado por clases de otras jerarquías. Los rasgos los conocemos como Traits.

<?php
class Base {
  public function decirHola() {
    echo '¡Hola ';
  }
}
 
trait DecirMundo {
  public function decirHola() {
    parent::decirHola();
    echo 'Mundo!';
  }
}
 
class MiHolaMundo extends Base {
  use DecirMundo;
}
 
$o = new MiHolaMundo();
$o->decirHola();
?>

Sintaxis Corta de Arrays

Se pueden definir los arrays de forma simplificada mediante los corchetes.

$a = [1, 2, 3, 4];
$a = ['uno' => 1, 'dos' => 2, 'tres' => 3, 'cuatro' => 4];

Servidor Web Embebido

Quizás una de las cosas más interesantes de PHP 5.4.0 es que lleva embebido su propio servidor. Lo cual nos evita el tener que instalar uno para poder realizar las pruebas. Algo que echaba atrás a mucha gente a la hora de empezar a aprender el lenguaje.

Ahora podemos instanciar el servidor en la línea de comandos poniendo:

$ php -S localhost:1337

Por sacarle una pequeña pega, no incluye soporte de SSL. Si bien, no deja de ser un perfecto servidor para pruebas en local.

Mejoras en rendimiento y memoria

Esta versión trae mejoras de rendimiento y consumo de memoria.

Correción de Bugs

En PHP 5.4.0 han sido corregidos más de 100 bugs.

Descárgate PHP 5.4.0 desde el área de descargas de PHP. También es recomendable que le eches un vistazo a la guía de migración desde PHP 5.3

Ya ha pasado un tiempo desde que apareció Dojo 1.7. Echemos un vistazo a las novedades que trae la nueva versión de este popular framework de Javascript.

Entre las nuevas características encontramos:

• Dojo Nano o como tener un core de la librería con poco peso.
• Separación de los datos de negocio de la experiencia de usuario.
• Cambios en el API sin dejar de ser compatible.
• Mejoras en la carga asíncrona de módulos: AMD.
• Módulo dbGrid rediseñado.
• Mejoras en el core de DOJO.
• Compatibilidad con Navegadores

Dojo Nano o como tener un core de la librería con poco peso.

Uno de los handicaps que tienen los frameworks es que, aunque facilitan nuestro trabajo, incrementan el número de elementos de descarga de nuestras páginas web y por ende el tamaño de desacarga de las mismas. Así que pensando en la optimización Dojo 1.7 nos ofrece Dojo Nano, fichero comprimido que solo pesa 4kb.

Luego, dependiendo de nuestras necesidades, ya se van añadiendo las funcionalidades necesarias al core de Dojo Nano.

Separación de los datos de negocio de la experiencia de usuario.

Este punto es y va a ser la clave para el desarrollo de aplicaciones de todo tipo. Hoy en día, cuando montamos una aplicación tenemos que pensar que el usuario puede consumirla desde diferentes ambientes.  Ya sea desde una aplicación web, el escritorio o un móvil. Realmente el usuario va a estar realizando operativas similares con más o menos datos de presentación.

En todo este proceso lo que se reutiliza son los datos de negocio (sus servicios). Así debemos de intentar mantenerlo separados del interface , o mejor dicho, de los interfaces de usuario.

De cara a la separación de los datos de negocio de la experiencia de usuario, Dojo nos ofrece:

1. Herramientas que te permiten mezclar los dos mundos y así crear tu propia aplicación.
2. APIs que permiten separar los datos del interface de usuario de una forma sencilla
3. Capacidad de modularizar los proyectos

Cambios en el API sin dejar de ser compatible.

Uno de los verdaderos quebraderos de cabeza de cualquier framework es cómo mantener la compatibilidad entre versiones y no dejar de ser compatible con versiones anteriores. Así Dojo 1.7 mantiene la compatibilidad con versiones 1.5 y 1.6 y nos introduce nuevos módulos que podemos considerar como los módulos alpha de Dojo 2.0

 Mejoras en la carga asíncrona de módulos: AMD.

Desde Dojo 1.6 ya contábamos con AMD (Asynchronous Modules), la cual ha sido afinada en Dojo 1.7. Los programadores de Dojo se han enfocado en ayudar a la especificación AMD, de lo cual han salido proyectos como RequireJS. Librería, que por otra parte, se utiliza en otros frameworks como jQuery.

Las mejoras en AMD han ido enfocadas a:

• Gestión de paquetes
• Optimización en la reducción de peticiones balanceadas
• Detección de características de Javascript atendiendo al agente de usuario mediante has.js
• Facilidad de reconstruir proyectos con las librerías de nuestro código, los módulos de Dojo y otras librerías. Para ello la idea es utilizar CommonJS como gestor de paquetes.

Módulo dbGrid rediseñado.

Mejoras en el core de DOJO.

Han sido refinados objetos nuevos como el DOJO Object Store API o el DOJO Socket (ambos implementan las mejoras de HTML5 sobre IndexedDB y Websockets)

Compatibilidad con Navegadores

Los test de compatibilidad han establecido que el soporte de Dojo 1.7 se circunscribe a:

• Chrome 8+
• Firefox 3.6+
• Internet Explorer 6, 7, 8 y 9
• Opera 11 y 12
• Safari 5.0 y 5.1

Descargarte Dojo

Prueba a descargarte Dojo 1.7 (en realidad ya tenemos 1.7.2) y empezar a trabajar con él. Además puedes leerte todas las novedades de Dojo 1.7

No cabe duda que jQuery sigue siendo uno de los frameworks Javascript más importantes y utilizados por los desarrolladores y fruto de su uso aparece la nueva versión jQuery 1.7. En jQuery 1.7 podemos encontrar una nueva forma de asignar y desasignar eventos, mejoras de soporte HTML5 para navegadores antiguos, optimización de sus objetos y métodos en búsqueda de un mejor rendimiento y algún método nuevo que otro.

Pero echemos un ojo, en detalle, a las novedades que vienen en jQuery 1.7. Entre ellas encontramos:

• on() y off(), se ha decidido estandarizar y mejorar la gestión de eventos. Para ello se han creado estos dos métodos con los que podremos asociar/desasociar eventos a los elementos de la página. Aunque los métodos que existían hasta ahora como bind(), unbind(),.. seguirán presentes en jQuery 1.7 se recomienda que se pase a utilizar on() y off().
• Mejora de rendimiento en los métodos delegados, se ha refactorizado el manejo de eventos para que la delegación de eventos sea mucho más rápida. Consiguiendo una reducción del 50% con respecto a jQuery 1.6.4.
• Soporte HTML5 para Internet Explorer 6/7/8, estas versiones de Internet Explorer no soportan las tags de HTML5 y además son eliminadas del DOM. jQuery 1.7 nos ayudará a soportar los tags HTML5 en esos casos. Para ello deberemos de cargar html5shiv o Modernizr.
  
• Cambios en las animaciones, se han corregidos problemas que se producían cuando se cambiaba entre animaciones y si la última había terminado mediante un .stop().
• Asynchronous Module Definition (AMD), jQuery 1.7 da soporte a la especificación del API AMD la cual nos sirve para cargar los módulos de forma asíncrona.
• jQuery.Deferred, se han extendido este objeto con nuevos manejadores y métodos de notificación.
• jQuery.isNumeric(), utilidad sencilla, pero que no existía. Nos devuelve true si el dato es numérico.

Además y como es normal, un buen grupo de bugs han sido corregidos.

Tienes toda la información sobre jQuery 1.7 en http://blog.jquery.com/2011/11/03/jquery-1-7-released/

Los beneficios de la W3C son incuestionables y su trabajo en la estandarización de Internet ha sido excepcional. Si bien siempre se le ha achacado la complejidad de su modelo de trabajo. Los grupos cerrados, la falta de visión global de la industria, el tiempo desde que propone un estándar hasta que lo cierra,…

En este sentido la W3C ha empezado a dar pasos que modifiquen este modelo. Hasta ahora para proponer/crear un estándar había que hacerlo mediante un Working Group. Su nueva idea es crear Community Groups y Business Groups.

Community Groups

La idea es abrirse a los desarrolladores de Internet y ofrecerles toda la infraestructura de la W3C para el desarrollo de estándares. La participación será gratuita y sin cargos. No habrá presión de fechas en la propuesta de nuevos estándares.

La idea de los community groups es la de:

• Fomentar la propuesta de nuevas especificaciones
• Promover la discusión sobre los estándares
• Generar y desarrollar casos de test
• Crear una comunidad alrededor de la innovación

Business Groups

Son grupos dedicados a empresas. De esta manera se quiere generar un foro premium de empresas para desarrollar tecnologías específicas orientadas a industrias.

Con los Business Groups se busca el tener más información de empresas en las especificaciones que genere la W3C.

Si la empresa es un W3C Members no tienen coste en su participación. En caso contrario se tiene un coste anual que va desde $300 a $10.000 dependiendo del tamaño de la empresa.

Parece que a lo largo del verano empezará a funcionar este modelo, de momento puedes encontrar más información sobre las nuevas comunidades en http://www.w3.org/2010/12/community/

Si hay un grupo de trabajo que me gusta dentro de la W3C ese es el Web Applications Working Group. Este grupo es autor, de entre otras especificaciones, del Websockets API, File API, Indexed Database API,… Vamos, de todos los APIs que están naciendo alrededor del HTML5.

En este caso, uno de los últimos borradores de trabajo es el del estandarizado en el uso del portapapeles. De esta forma programar, desde nuestros navegadores web, los accesos a copiar, cortar y pegar desde el portapapeles se hará de forma estándar.

La idea es que el portapapeles o Clipboard lance una serie de eventos (ClipboardEvent). A ver copiar, pegar y cortar.

¿Qué te parece la estandarización del Clipboard API?

Seguimos revisando los trabajos del Device APIs and Policy Working Group (ya hemos visto el Messaging API y el Calendar API). En este caso vamos a ver qué tiene el borrador que proponen para la especificación de los eventos de estado de la batería.

Es un API para que las aplicaciones puedan acceder al estado de la batería: si hay batería, el nivel de carga de la misma, cuánto tiempo le queda a la batería y saber si la batería está cargando.

De momento la especificación está en los primeros pasos y propone un interface muy sencillo. Echemos un ojo:

interface BatteryStatusEvent : Event {
    readonly attribute boolean        isBattery;
    readonly attribute boolean        isCharging;
    readonly attribute float?         level;
    readonly attribute unsigned long? timeRemaining;
    void initBatteryStatusEvent (DOMString type, boolean bubbles, boolean cancelable, boolean isBattery, boolean isCharging, float? level, unsigned long? timeRemaining);
};

Revisa el borrador de la primera especificación para los eventos de estado de la batería.

El grupo de trabajo Device APIs and Policy Working Group de la W3C está definiendo un nuevo borrador, en este caso es el Calendar API. Dicho API intenta definir de forma genérica el acceso a los eventos de un calendario.

Para ello dentro del Calendar API se definen dos interfaces Calendar y CalendarEvent. El interface Calendar nos permite encontrar eventos o items en el calendario y CalendarEvent define qué es un evento en sí, con su descripción, fecha de inicio y fin, si es recursiva,… El interface CalendarEvent está propuesto de la siguiente forma:

interface CalendarEvent {
  readonly attribute DOMString           id;
  attribute DOMString           description;
  attribute DOMString?          location;
  attribute DOMString?          summary;
  attribute DOMString           start;
  attribute DOMString?          end;
  attribute DOMString?          status;
  attribute DOMString?          transparency;
  attribute CalendarRepeatRule? recurrence;
  attribute DOMString?          reminder;
};

Seguiremos atentos a esta especificación.

¿Cuál es la especificación del Device APIs and Policy Working Group que más te llama la atención?

Al crear una aplicación móvil es muy probable que estemos accediendo a las capacidades del dispositivo. Entre estas capacidades encontramos, sin duda alguna, el punto de poder enviar o consultar los SMS del dispositivo. Las diferentes plataformas de dispositivos móviles nos ofrecen sencillos APIs para poder ejecutar esta tarea.

En este sentido, la W3C, en su papel de estandarizar los lenguajes y APIS ha lanzado el primer borrador del Messaging API. El Messaging API pretende estandarizar la funcionalidad de mensajería en el dispositivo: SMS, MMS y email.

Aunque Messaging API está en un estado inicial (solo están definiendo un método sendMessage) merece la pena seguirla los pasos.

El Messaging API esta gestionado por el Device APIs and Policy Working Group

Cuándo no tenemos a una persona frente a nosotros y tenemos una comunicación (email, chat,…) es complicado el transmitir nuestras emociones. Diferentes técnicas pueden ser aplicadas: negritas, subrayados, texto en mayúscula, incluso los emoticonos

Es por ello que el grupo Multimodal Interaction (MMI) Working Group creo el lenguaje Emotion Markup Language (EML), con vistas a poder modelar las emociones.

Emotion Markup Language (EML) intenta complimentar a otros lenguajes de marcado ofreciendo:

• Anotaciones manuales de datos
• Reconocimiento automático de emociones en el comportamiento del usuario
• Generación de emociones relacionadas con el comportamiento del sistema

Ahora, el grupo Multimodal Interaction (MMI) Working Group, pretende establecer un vocabulario en el que se recojan las posibles emociones. En este sentido ha publicado el primer borrador de vocabularios que pueden ser utilizados en el Emotion Markup Language (EML).

Así se revisará que vocabulario tener en Emotion Markup Language (EML) partiendo de clasificaciones existentes como las emociones básicas como ira,  miedo, felicidad, tristeza, sorpresa,… emociones diarias como miedo, diversión, enojado, aburrido,… u otras clasificaciones.