Blog

WebApps Working Group

Últimamente leo bastante la página del w3c (Qué acierto fue cambiar su diseño), y casi siempre me veo a mí mismo leyendo sobre el Grupo de Trabajo de Aplicaciones Web (WebApps Working Group). ¿Qué es?

El W3C Web Applications (WebApps) Working Group, una fusión de los grupos de trabajoWebAPI y WAF, se constituye para desarollar APIs estándar para el desarrollo de Aplicaciones Web del lado del cliente. Este trabajo incluirá tanto la documentación de APIs existentes como el XMLHttpRequest, como el desarrollo de nuevas APIs que enriquezcan las aplicaciones web.

Veamos en qué consisten algunas de esas APIs que están desarrollando.

Vídeo, audio e imágenes de entrada al navegador

Hace poco se ha publicado un nuevo borrador del w3c (The Capture API) que permitirá conectar dispositivos de entrada al navegador, permitiendo por ejemplo capturar una fotografía, mensaje de audio por el micrófono, o un vídeo.

Aun se encuentra en un estado muy prematuro, pero nos enumeran una serie de posibles casos de uso:

  • Captura y envío de imágenes. Permitiendo el envío por XHR de varias imágenes.
  • Captura de imagen panorámica. Por ejemplo, con 3 tomas que posteriormente se “concatenan” automáticamente para mostrar la panorámica.
  • Video Chat. Aun está sin definir el método para realizar streaming, sin embargo todas las soluciones propuestas pasan por websockets.
  • Cámara web. Permitirá realizar una aplicacion de vigilancia para controlar la cámara, incluyendo movimientos como arriba, abajo, izquierda o derecha, o hasta aplicaciones de detección de movimiento.
  • Búsqueda por voz. Introduciendo por el micrófono la cadena de búsqueda.
  • Recordatorio de voz. De nuevo, desde el micrófono.

Por supuesto, para proteger la privacidad de los usuarios, el navegador tendrá que pedir explícitamente confirmación del usuario para permitir que se acceda a estos dispositivos.

Ejemplo de uso:

// Create a container div element and append it to the document body.
var container = document.createElement("div");
document.body.appendChild(container);

// The browser viewport width in pixels.
var screenWidth = window.innerWidth;

function successCallback(data) {
for (var i in data) {
var img = document.createElement("img");
img.src = data[i].uri;
// If the image width exceeds that of the browser viewport, the image
// is scaled to fit the screen keeping the aspect ratio intact.
if (data[i].format.width > screenWidth) {
img.style.width = screenWidth + "px";
img.style.height = (data[i].format.height/data[i].format.width)*screenWidth + "px";
}
container.appendChild(img);
}
}

function errorCallback(err) {
alert(err.message + " (" + err.code + ")");
}

// Launch the device camera application and invoke the callback once 
// the user exits the camera application.
transactionId = navigator.device.captureImage(successCallback, 1, errorCallback);

Mientras tanto, y hasta que esto sea una realidad, se puede utilizar el paquete flash.media de ActionScript3, en concreto las clases Camera y Micrphone. Pero claro, no es lo mismo. Una verdadera lástima tener que esperar tanto tiempo. Veremos cuándo tiene el navegador más utilizado estas funcionalidades.

Google Chrome ahora con Web Sockets

La noticia del día en cuanto a desarrollo web sin duda ha sido la implementación de Web Sockets en Chromium. una tecnología de comunicación bidireccional para aplicaciones web.

Los Web Sockets son un borrador del W3C que, mediante una conexión TCP, permiten realizar fácilmente un Server Push, es decir, una petición iniciada desde el servidor central. Es un cambio notable en la programación web, hasta ahora dirigida por peticiones iniciadas desde el cliente.

¿Qué diferencias hay entre Google Chrome y Chromium?

Es posible que, al igual que a mí, os haya surgido esa duda. Si bien desde hoy tenemos a nuestra disposición Google Chrome para Linux y de Mac, hace tiempo que podíamos disfrutar de Chromium. ¿No habíamos quedado en que era lo mismo? ¿Qué diferencias hay? Voy a tratar de dar respuesta a estas dudas.

chrome_vs_chromium

Si consultamos la Wikipedia en castellano veremos que:

  • Google Chrome es un navegador web desarrollado por Google y compilado con base en componentes de código abierto [...]
  • Chromium es el proyecto de software libre detrás de Google Chrome[...]

O dicho de otra forma, Google Chrome es la compilación y el paquete que Google hace del software Chromium. Algo así como los distints paquetes que las distribuciones de GNU/Linux hacen del kernel.

Si eso es todo… ¿Qué más me da usar uno u otro? ¿No son lo mismo pero empaquetado por entidades diferentes? Bien, Google tiene una página explicativa al respecto que con vuestro permiso voy a traducir:

Chromium en Linux tiene en general dos sabores: Puedes instalar o bien Google Chrome o bien un navegador Chromium. Esta página trata de explicar la diferencia entre ambos:

Google Chrome

Google Chrome es el proyecto de software libre Chromium construído, empaquetado y distribuído por Google. Tiene las siguientes diferencias respecto a Chromium:

  • Logo coloreado
  • Opción de informe de errores
  • Opción de métrias de usuarios
  • Soporte para H.264, AAC, MP3, Vorbis y Theora con las etiquetas audio y video.
  • Aislamiento de procesos
  • Un sólo paquete deb/rpm
  • Los ficheros de los perfiles se almacenan en  ~/.config/google-chrome

La compilación del canal de desarrollo se actualiza alrededor de una vez por semana, tras pasar los test automáticos y unos pocos test manuales de garantía de calidad.

Chromium

  • Logo azul
  • Soporte para Vorbis y Theora con las etiquetas video y audio
  • El aislamiento de procesos es opcional, depende del mantenedor del paquete
  • Los paquetes dependen de la distribución, a veces se dividen en múltiples partes.
  • Los ficheros de perfiles se almacenan en ~/.config/chromium

Bien, ahora queda un poco más claro. La principal diferencia que veo yo es el soporte para los codecs de compresión de audio y vídeo. Google, como compañía, está dispuesta a pagar royalties por la licencia de la patente de dichos codecs, no así las ediciones libres.

Por otra parte, mientras nada me haga pensar lo contrario, creo que el nivel de calidad que ofrecen las distribuciones Linux en general es bastante elevado, por lo que no considero que ese hecho otorgue ventaja a Google Chrome.

¿Cuál elegir? Yo personalmente seguiré usando Chromium como navegador secundario y Firefox como primario. Principalmente para promover el uso de tecnologías libres y estándar, como son Vorbis para el audio y Theora para el vídeo.

Facturas en CSS

Vía css-tricks veo un sencillo método para crear facturas sólo con CSS. ¿Y por qué usar este método en lugar de un software específico? Bueno, gracias a esto sólo necesitas el navegador para poder crear tus facturas. Y qué demonios, es muy ilustrativo el ejemplo. ¡Qué de cosas se pueden hacer con textarea! Además, es fácil de imprimir, y pasarlo a PDF es algo trivial.

Ver demo

Botones súper increíbles con CSS3 y RGBA

CSS3 ya está aquí, y ha llegado para quedarse. Gracias a él, podemos crear increíbles efectos en navegadores modernos (Teniendo en cuenta un enfoque de graceful degradation). En éste artículo voy a mostrar cómo, desde ZURB, han creado unos botones CSS que realmente son súper increíbles. Accede a la página del artículo para ver demostraciones en vivo.

Botón en ancla »

Botón en ancla 2 »

La magia está en el CSS:

.button{
   background:#222 url(/wp-content/uploads/2009/12/alert-overlay.png) repeat-x 0 0;
   display:inline-block;
   padding:5px 15px 6px;
   color:#fff !important;
   font-size:13px;
   font-weight:bold;
   line-height:1;
   text-decoration:none;
   -moz-border-radius:5px;
   -webkit-border-radius:5px;
   -moz-box-shadow:0 1px 3px rgba(0,0,0,0.25);
   -webkit-box-shadow:0 1px 3px rgba(0,0,0,0.25);
   text-shadow:0 -1px 1px rgba(0,0,0,0.25);
   border-bottom:1px solid rgba(0,0,0,0.25);
   position:relative;
   cursor:pointer;
   overflow:visible;
   width:auto
}

button::-moz-focus-inner{
   border:0;
   padding:0
}

.button:hover{
   background-color: #111111;
   color: white
}

.button:active{
   top:1px
}

Una sombra a la caja, otra al texto, un borde redondeado, y de fondo una imagen png que realiza el degradado (Se puede realizar también con CSS en Webkit). Una pasada hacer todo esto sólo con CSS, ¿no?

¡Pero espera! ¡Ahí no queda la cosa! ¿Qué ocurriría si cambiásemos el color de fondo sobre el que está el botón? La sombra se vería “rara”, al igual que el color del borde.

super-awesome-buttons-fixed

Y lo mismo ocurriría con la sombra del texto si cambiásemos el color de relleno del propio botón. ¿Cómo se soluciona? Ahora es cuando llega al rescate la A de RGBA :) Por ejemplo, en la sombra de la caja, lo hemos definido como:

rgba(0,0,0,0.25)

Es decir, color negro al 25% de transparencia. De ese modo, la sombra siempre “lucirá” del mismo modo usemos el color que usemos.

Espero que os haya gustado tanto como a mí.

Vía Smashin Magazine,

El test de Joel adaptado al desarrollo web

Leyendo blogs, me encuentro con este artículo que trata sobre una revisión del sencillo test de Joel Spolsky sobre la calidad del software. Esta nueva revisión, de la mano de Brandon Savage, propone 12 pasos adaptados al desarrollo web hoy día. Los pasos se responden con un sí o un no. Estos son los posibles resultados:

  • 12 síes. Perfecto.
  • 11 síes. Aceptable.
  • 10 o menos síes. Tienes un serio problema.

Ahora veamos las preguntas:

  1. ¿Usas algún sistema de control de versiones?
  2. ¿Puedes generar fichero para distribuir tu software en sólo un paso?
  3. ¿Usas integración continua?
  4. ¿Guardas un registro de bugs?
  5. ¿Corriges los bugs tras escribir nuevo código?
  6. ¿Cumples los hitos a tiempo?
  7. ¿Documentas las especificaciones?
  8. ¿Disfrutan tus programadores de un entorno de trabajo tranquilo?
  9. ¿Usas las mejores herramientas, y gastas dinero en aquéllas que son necesarias y caras?
  10. ¿Escribes test unitarios?
  11. ¿Tus nuevos candidatos demuestran sus conocimientos de programación con alguna prueba tangible durante la entrevista?
  12. ¿Tienes testers?

En mayor o menor medida, todas me parecen propuestas muy acertadas. No deja de ser una curiosidad más, pero posiblemente este “juego” sea una métrica de calidad de software equiparable a otros sistmas varios órdenes de magnitud más complejos.

Por cierto, yo obtengo un 6 sobre 11 (La pregunta número 11 no se aplica en mi caso).

Mejora progresiva

De un tiempo a ahora, cada vez leo con más frecuencia el término progressive enhancement, o en catellano, mejora progresiva. ¿Qué es exactamente? Como desarrolladores web, debemos lidiar con numerosos navegadores, cada uno con una serie de prestaciones y recursos. Como veremos a continuación, normalmente hay 4 formas de abordar esta situación:

  1. Impedir el acceso a determinados navegadores. Creedme, existen páginas a las que no se puede acceder con según qué navegadores. No me refiero a que se muestren defectuosas, es que directamente te muestran un mensaje de error. Tratad de acceder a una página de El Plural cambiando el user-agent de vuestro navegador y sabréis a qué me refiero. Ésta es una pésima solución.
  2. Quedarnos en el mínimo común denominador. Esto es, diseñar la página de modo que sólo contenga recursos disponibles por todos los navegadores. No es una solución muy escalable, puesto que se está limitando a las funcionalidades mínimas (Funcionalidades que, por otro lado, normalmente se corresponden con las de nuestro querido IE6). Visto con un enfoque más visual, esto significa que la manada debe ir a la velocidad del más lento. Por ejemplo, querémos posicionar un <div> de forma ‘fixed’. IE6 no lo permite, de modo que, o no lo hacemos, o dedicamos esfuerzos en buscar retorcidos hacks para lograrlo en este navegador. Mmmm no me gusta. ¿Qué más hay?
  3. Graceful degradation. Durante mucho tiempo ésta ha sido la tendencia reinante, y seguramente seguirá siéndolo. Consiste en partir del máximo de prestaciones de forma que, a medida que se usen navegadores menos avanzados, la página se mantenga usable con pequeños defectos. Un ejemplo perfecto es el uso de imágenes PNG con semitransparencias: Mientras que los usuarios de Firefox o Safari las verán sin problemas, los de IE6 se encontrarán con imágenes corruptas. En estos casos es frecuente dividir la página en dos niveles: El nivel 1 corresponde a una buena experiencia para el usuario, el nivel 2 con una versión degradada de la página. Encontramos un ejemplo en el servicio de correo de Google Gmail, con su versión avanzada (Por defecto) y una versión básica.
  4. Mejora progresiva. Y al fin llegamos a la mejora progresiva. ¿En qué consiste? Es exactamente igual que graceful degradation pero al revés. En lugar de partir de una versión avanzada, se parte de la versión mínima, de forma que, a medida que un navegador ofrece mejores recursos, la página también se ve mejorada. En este caso, se parte de un mínimo razonable, por ejemplo, que sea compatible con HTML 4. Podría, por ejemplo, usarse transparencias en GIF, y sin embargo, en aquéllos navegadores que sí lo soporten, semitransparencias en PNG.

Lógicamente las dos mejores soluciones son las dos últimas. ¿Cuál es mejor? Realmente depende del caso. Pero como método general yo prefiero la mejora progresiva, pues a diferencia de graceful degradation parte de una experiencia de usuario razonablemente buena. Además, con esto siempre ganaremos en accesibilidad.

Si bien cada día existen más navegadores con sus respectivas versiones, también es cierto que disponemos cada vez más de recursos que nos permiten abstraernos de ellos, como los numerosos frameworks javascript como jquery o mootools, además de brillantes soluciones como Google Chrome Frame.

Más información:

FirePHP – Integra logs de PHP en Firefox

En todo desarrollo se hacen necesarias herramientas que permitan hacer un seguimiento del código. Hoy voy a mostrar cómo mostrar logs desde PHP directamente a una consola en Firefox. ¡Di adiós a los “echos” y a los “var_dump”!

Expresiones Regulares

La primera vez que ves una de ellas sientes nauseas. A partir de ese momento cada vez que te enfrentas a ellas sientes mareos, hasta que poco a poco empiezas a entender su idioma. Llega un día en el que te sientes capaz de dialogar con ellas. La amistad se ha forjado.

Con las expresiones regulares ocurre como con los frameworks de desarrollo. La curva de aprendizaje suele ser lenta, pero siempre acaba mereciendo la pena. Son las encargadas de poner orden en los caos con los que muchas veces tienen que lidiar nuestros pobres procesos.

Gracias a ellas podemos confeccionar laboriosas expresiones como por ejemplo “Quiero saber cuales son todas las palabras que preceden a todos los números de 4 cifras que no terminan en 2″. Inventate una condición, seguro que se puede construir.

AVISO: No he sometido a prueba ninguno de los ejemplos que aquí pongo.