Novedades de ECMAScript 4.0

Interesante resumen conceptual sobre ECMAScript 4.0 (Javascript 2.0). Mi opinión es que la mayoría de los cambios complican el lenguaje y lo acercan a los ya existentes. Es absurdo. El gran éxito de Javascript viene de su simplicidad y ortogonalidad. Debería reforzarse aún más y corregirse los errores, pero no ampliarlo.

Perfiles de color con Firefox 3

John Resig anuncia que Firefox 3 soporta perfiles de color, de forma que es capaz de reproducir de forma idéntica a Photoshop, por ejemplo. Sin embargo, la opción viene desactivada por defecto debido a una reducción del rendimiento del 10-15% y efectos no deseados con las extensiones.

Soporte de OAuth para Google Accounts

OAuth support for Google Accounts and Contacts API. Ejemplo de uso con PHP.

Parece que OpenID no es el único protocolo que está recibiendo soporte por parte de los grandes, también OAuth que permite a un usuario dar permiso sobre tus recursos privados (como los contactos) de un sitio (llamado proveedor de servicio) a otro sitio (llamado consumidor del servicio) sin necesidad de facilitar la contraseña. Mientras que OpenID trata de usar una única identidad para autenticarse en varios sitios, OAuth trata de dar acceso a tus recursos sin compartir tu identidad.

El auge de los websites sociales como Facebook, que solicitaba la contraseña y un acto de fe para poder acceder a los contactos del usuario habían hecho patente la necesidad de un protocolo que permitiese acceder a esa información de forma controlada en lugar de, literalmente, dar una copia de las llaves de casa.

Ejecutando Java desde JavaScript

John Resig habla en su blog sobre Orto, toda una máquina virtual de Java implementada en Javascript y capaz de ejecutar los bytecodes compilados de Java. A pesar de la relativa poca utilidad de proyectos como éste, sirve para acallar algunas críticas despectivas de otras comunidades de programadores hacia Javascript.

Actualización de CouchDB

Según anuncia plok, uno de los responsables detrás del proyecto de esta base de datos relacional, se siguen haciendo avances en este proyecto ya aceptado para incubación en la Fundación Apache.

Quiero destacar esta review de una, dos y tres partes sobre la base de datos. Y también los dos clones que menciona: FeatherDB basado en Java y StrokeDB basado en Ruby (lo que seguramente explique por qué tiene más resultados en Google).

java'scrypt

Javascript es el lenguaje de ensamblado de la plataforma internet (cuyo sistema operativo es el navegador). Es lo suficientemente flexible para soportar casi cualquier cosa sobre él, y lo estructurado de forma suficientemente pobre para que los humanos no esten escribiendo aplicaciones grandes sobre él. [...] La importancia de Javascript proviene de las posiciones de las versiones existentes en el navegador, y de su flexibilidad. Debe mantenerse simple.
Gilad Bracha. Via Anarchaia.

Tiempos de cambio...

Curiosa reflexión de Tim Bray sobre la cantidad de puntos de inflexión en materia de programación que hay abiertos en este momento. Hace unos meses las opciones para crear un programa eran Java, .NET o C++, y hoy están en pleno auge PHP, Python o Ruby. En cuanto a bases de datos, las relacionales están dando paso a otras opciones como Apache CouchDB, Amazon SimpleDB o la BigTable de Google. En programación sobre redes, CORBA y DCOM están muertas, y WS-* (SOAP) está cediendo rápidamente ante REST. En cuanto a desarrollo web, no dejan de aparecer clones de RubyOnRails. Los modelos de negocio están pasando de montar una auténtico centro de datos propio a externalizar todo el proceso y dejarlo en manos de grandes actores como Google o Amazon. Hasta el escritorio está sufriendo una enorme convulsión cuando OS X y Ubuntu unidos al auge de la virtualización se están convirtiendo en serias alternativas al omnipresente Windows, que aún está digiriendo el enorme fiasco de Vista. Tiempos de cambio supongo... Renovarse o morir, una vez más.

Internacionalización

Interesante explicación sobre internacionalización (o i18n) por parte de Google. Explica la historia de las codificaciones, empezando por la simple ISO-8859-1, y siguiendo por ISO-8859-15, UCS-2 (Unicode), UTF-16, UTF-32 y, por fin, UTF-8, el estándar de longitud variable por carácter más recomendado para aplicaciones web y bases de datos:

UTF-8 es idéntico a ASCII para todos los carácteres inferiores a 128, y usa uno o varios bytes extra (hasta un máximo de 4) cuando tiene que almacenar un número superior a 128. Cualquier texto ASCII en inglés es automáticamente un texto UTF-8 válido. Los textos europeos son en torno a un 2% más grandes que usando ISO-8859-15, ya que sólo los carácteres acentuados aumentan de tamaño. Los únicos que realmente salen perdiendo son aquellos que tenían un alfabeto pequeño (griego, ruso, ...) sin nada en común con el inglés, ya que antes podían codificar cada carácter con un 1 byte y ahora necesitan más. UTF-8 no usa ningún byte 0 en su codificación, y funciones como strcpy funcionan con textos UTF-8.

A parte aconsejan no usar editores de texto que añadan el carácter BOM (EF BB BF) al principio del documento, típica fuente de errores al programar con PHP al generar una salida que no es visible en el editor.

Presentación sobre frameworks

Interesante presentación de Jonathan Snook sobre frameworks Ajax explicando las características de cada uno. En particular considero interesante la siguiente tabla en la que se indica cada framework y su característica más notable:

PrototypeJS	Para cargas pesadas de datos
jQuery	Trabajo pesado con DOM
ExtJS	Widgets de aplicación
Script.aculo.us	Animación
Mootools	Un poco de todo
YUI	Un mucho de todo
Dojo	Widgets de aplicación

En SlideShare. Descargar en PDF.

Cruiser, un parseador Javascript

cruiser en Google Code. Cuando alcanzas los límites de las expresiones regulares de Javascript, puedes pensar que lo que estás intentando hacer no debe ser una buena idea, o como ha hecho esta gente, escribirse un parseador. Esta librería permite escribir parseadores de forma sencilla. Está basada en una gran función, en lugar de usar la solución de YACC de generar código, que es más rápida.

with ( Parser.Operators ) {
  var g = Behaviors.Stylesheet.Grammar; 
  var t = Behaviors.Stylesheet.Translator;
  // basic tokens
  g.lbrace = token('{'); g.rbrace = token('}');
  g.lparen = token(/\(/); g.rparen = token(/\)/);
  g.colon = token(':'); g.semicolon = token(';');
  // attributes
  g.attrName = token(/[\w\-\d]+/); 
  g.attrValue = token(/[^;\}]+/); 
  g.attr = pair(g.attrName,g.attrValue,g.colon);
  g.attrList = list(g.attr,g.semicolon,true);
  g.style = process(
    between(g.lbrace,g.attrList,g.rbrace),t.style);
  // style rules
  g.selector = token(/[^\{]+/); 
  g.rule = each(g.selector,g.style); 
  g.rules = process(many(g.rule),t.rules);
  // comments
  g.inlineComment = token(/\x2F\x2F[^\n]\n/);
  g.multilineComment = token(/\x2F\x2A.*?\x2A\x2F/);
  g.comments = ignore(
    any(g.inlineComment,g.multilineComment));
  // parser
  Behaviors.Stylesheet._parse = process(
    many(any(g.comments,g.rules)),t.parse);
}

Un reproductor de video sólo con Javascript

JSONVid es un reproductor de vídeo basado únicamente en Javascript. No necesita ningún tipo de Plug-in. Tiene un formato de vídeo propio basado en JSON, en el que la secuencia de imágenes JPG que componen el vídeo aparecen codificadas en base64:

{
  frm : "JSVID",   // format id tag
  ver : 1,  // version number of format
  width : 320,  // width of video
  height : 240,  // height of video
  rate : 15,  // framerate (frames per second)
  frames : 495,  // number of frames in file
  data : {
    video : [ // here comes 495 data:uris containing base64 encoded jpeg image frames
      "data:image/jpeg;base64,/9j/4AAQSkZJRgABAgEASABIAAD/7gAOQWRv ... ",
      "data:image/jpeg;base64,/9j/4AAQSkZJRgABAgEASABIAAD/7gAOQWRv ... ",
      ...
    ]
  }
} 

Ahora sólo falta resolver el tema del audio. ;-)

API de búsqueda de Google AJAX

Simon Willison:
Más de un año después de que Google cerrase su API de búsquedas SOAP, discretamente han publicado una basada en JSON bajo la excusa de soportar “Flash y otros entornos Javascript”. En total son tres especificaciones:

• Google Ajax Search API
• Google Ajax Feed API
• Google Ajax Language API

A parte de las búsquedas y de la ya conocida API de lenguaje para traducir e identificar textos en otros idiomas, la API de Feeds permite pasar la URL de un feed en Atom o RSS y obtener en formato JSON el contenido incluido en ese feed. Eso facilita el uso de esa información desde Javascript en el navegador.

50 ejemplos creativos con CSS

aNieto2K:
Usando CSS para todo.

El texto es el nexo

Personalmente echo en falta más integración entre los distintos protocolos o tecnologías de consola. Empezando por el RS-232, pasando por Telnet, SSH, Mensajería instantánea (como Jabber), los shells de Unix, Microsoft PowerShell, los SMS, MMS y GPRS en el móvil, y llegando a las interfícies web (URL, REST, AJaX, Comet o Javascript Shell) todo sigue un mismo patrón de funcionamiento: una conexión basada en texto en la que por un lado se indican comandos que pueden generar una salida textual en sentido inverso. Quizás no debería ser necesaria una extensión y las aplicaciones podrían implementar un estándar de interacción, una mezcla entre el protocolo de descubrimiento de capacidades de Bluetooth y las capacidades de línea de comandos que implementan los sistemas operativos, todo ello coordinado si se desea por un lenguaje como Javascript... o por un lenguaje de marcado basados enteramente en texto (Json, Markdown, Textile o el nuevo CrossMark). Hace falta algo aún más simple, que nos permita consultar cualquier cosa, en cualquier momento, en cualquier lugar, y ese algo está basado en texto... ¿Alguien se anima a subirse las mangas?

Automatizando Firefox con JSSh

Ideas For Dozens ha descubierto aquí una extensión para Firefox (instalar XPI) que permite establecer conexiones entre un cliente Telnet y la consola Javascript del propio navegador. La comunidad se ha hecho eco inmediatamente de una técnica que abre infinitas posibilidades a la hora de controlar un navegador sin asistencia. Permite desde código compilado abrir páginas, explorar el DOM de páginas cargadas o capturar el estado de la página después de haber interactuado, de forma automática a través de JavaScript, con ella.

StylizedWeb.com:
Los trucos CSS más usados.

Libro sobre Adobe AIR

libro PDF gratuito de Adobe para que programadores Javascript empiecen a trabajar con Adobe AIR. Esta tecnología de Adobe también propietaria de Flash, y equivalente a Microsoft Silverlight o a Mozilla XUL, es una de las distintas propuestas para crear un lenguaje de definición de interfícies que se convierta en una base para facilitar la creación de aplicaciones web.

Google Code - Sitio del desarrollador

Google acaba de presentar la versión en español de su Sitio del desarrollador (Google Code). Contiene presentaciones, noticias, y documentación traducida sobre muchos de los productos de Google.

Visibone PHP

Tengo las páginas de referencia de Javascript y CSS y son más que útiles. Están muy bien pensadas e incluyen información muy útil que debería estar siempre disponible y a mano. Nueva página de referencia PHP en A4 a dos caras. 10$.





Y nuevo libro de 8 páginas de referencias PHP. 20$.

Google App Engine portado a Amazon EC2

En Waxy.org anuncian que alguien ha creado AppDrop, un contenedor para aplicaciones desarrolladas con el SDK de Google App Engine que funciona sobre la infraestructura de Amazon EC2, demostrando así que el bloqueo que Google aplica a su nuevo proyecto no es tal. Se trata de una proof-of-concept o prueba de concepto que sirve para comprobar que, efectivamente, el sistema funciona tal y como se anuncia y demuestra que es factible la portabilidad.

Aquí está la galería de aplicaciones portadas, y aquí hay un ejemplo de aplicación portada y aplicación original.

Lighttpd

Aunque Apache es, de largo, el servidor web más usado, hay otros servidores web como Nginx o Lighttpd que tienen otras características como la ligereza o un rendimiento muy superior. He probado a instalar sin ningún problema Lighttpd en mi portátil de trabajo para utilizarlo habitualmente, debido a su ligereza. Paso a paso:

Aunque mencionan que el sitio oficial es http://wlmp.dtech.hu/down_lighty.php, en estos instantes no está disponible pero he podido descargar la última versión disponible 1.4.15 desde aquí (Weblog de Kevin Worthington).

He modificado los archivos para arrancar y detener el servidor:

start /inv d:\web\apache\php\php-cgi -b 127.0.0.1:521 -c d:\web\apache\bin\
.\app\sbin\lighttpd.exe -f d:/lighttpd/app/etc/lighttpd.conf -m D:/lighttpd/app/lib

Y para detenerlo:

taskkill /F /IM php-cgi.exe
taskkill /F /IM lighttpd.exe

Así mismo, el archivo de configuración para Lighttpd ha sido modificado para permitir el uso de FastCGI con PHP, tal y como explican perfectamente aquí (En la segunda sección, porque en la primera lo explican para el anticuado CGI e indican que no es posible hacerlo funcionar con FastCGI, que es justo lo que hacen inmediatamente después). Lighttpd.conf (sólo las líneas NO comentadas):

server.modules = (
"mod_rewrite",
"mod_redirect",
"mod_access",
"mod_fastcgi",
"mod_accesslog" )
server.document-root = "D:/web"
server.errorlog = "D:/lighttpd/app/logs/lighttpd.error.log"
index-file.names = ( "index.php", "index.html",
"index.htm", "default.htm" )
mimetype.assign = (
".pdf" => "application/pdf",
".sig" => "application/pgp-signature",
".spl" => "application/futuresplash",
".class" => "application/octet-stream",
".ps" => "application/postscript",
".torrent" => "application/x-bittorrent",
".dvi" => "application/x-dvi",
".gz" => "application/x-gzip",
".pac" => "application/x-ns-proxy-autoconfig",
".swf" => "application/x-shockwave-flash",
".tar.gz" => "application/x-tgz",
".tgz" => "application/x-tgz",
".tar" => "application/x-tar",
".zip" => "application/zip",
".mp3" => "audio/mpeg",
".m3u" => "audio/x-mpegurl",
".wma" => "audio/x-ms-wma",
".wax" => "audio/x-ms-wax",
".ogg" => "application/ogg",
".wav" => "audio/x-wav",
".gif" => "image/gif",
".jpg" => "image/jpeg",
".jpeg" => "image/jpeg",
".png" => "image/png",
".xbm" => "image/x-xbitmap",
".xpm" => "image/x-xpixmap",
".xwd" => "image/x-xwindowdump",
".css" => "text/css",
".html" => "text/html",
".htm" => "text/html",
".js" => "text/javascript",
".asc" => "text/plain",
".c" => "text/plain",
".cpp" => "text/plain",
".log" => "text/plain",
".conf" => "text/plain",
".text" => "text/plain",
".txt" => "text/plain",
".dtd" => "text/xml",
".xml" => "text/xml",
".mpeg" => "video/mpeg",
".mpg" => "video/mpeg",
".mov" => "video/quicktime",
".qt" => "video/quicktime",
".avi" => "video/x-msvideo",
".asf" => "video/x-ms-asf",
".asx" => "video/x-ms-asf",
".wmv" => "video/x-ms-wmv",
".bz2" => "application/x-bzip",
".tbz" => "application/x-bzip-compressed-tar",
".tar.bz2" => "application/x-bzip-compressed-tar"
)
mimetype.use-xattr = "enable"
server.tag = "lighttpd/1.4.15-Win32"
accesslog.filename = "D:/lighttpd/app/logs/access.log"
url.access-deny = ( "~", ".inc" )
$HTTP["url"] =~ "\.pdf$" {
server.range-requests = "disable"
}
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
server.port = 81
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"host" => "127.0.0.1",
"port" => 521
)
)
)


La única pega es que el PHP debe quedar residente para atender las peticiones de FastCGI desde Lighttpd, pero debe notarse una mejora en rendimiento y, sobre todo, en consumo de recursos: Una de las características de Lighttpd es el consumo relativamente constante de memoria.

CSRF o Cross Site Request Forgery

... o Falsificación de peticiones entre sitios. Se trata de una técnica prácticamente desconocida pero extremadamente peligrosa que permite aprovechar que tenemos abierta una sesión en el navegador con un sitio fiable (un banco, gmail, ...) para que desde el código HTML de una página que estemos visitando se cree una petición como la siguiente:

<img src="https://our.example.com/change_account
?paytype=debit
&paytype_id=1234
&paytype_field_1=123456789 // el numero de cuenta
&paytype_field_2=12345678 // el código de banco
&paytype_field_3=Richie+Rich // el propietario de la cuenta
&paytype_field_4=BancoDeEspaña // el nombre del banco
&op=editpaytype.save
&confirmmode=" />

que podría tener la consecuencia de enviar una petición (legítima en apariencia porque procede de un navegador en el que mantenemos una sesión válida abierta) a la aplicación web del banco para que realice una operación sin que sea en ningún momento evidente. Los riesgos que supone esta técnica son enormes (pueden acusar a alguien de acceder a sites de pornografía infantil o habilitar un filtro en el correo para que todos los mensajes se reenvien a una tercera cuenta y, entre otras cosas, robar dominios o cambiar contraseñas gracias a los mensajes de confirmación).

Se recomienda no mantener abiertas las sesiones de aplicaciones web con datos sensibles mientras se navega y no navegar con el mismo navegador en que se visualicen dichas operaciones (usar Prism es una buena idea). A la hora de programar aplicaciones web, es buena idea incorporar tokens variables a todas las peticiones que incluyan, por ejemplo, la fecha y la hora para ser generados con el fin de detectar peticiones que no provengan de la propia aplicación web.

Links:

• CSRF Demystified
• Presentación de Jeremiah Grossman en SlideShare

Homer Simpson en CSS

Por Román Cortés. Via aNieto2K.

---

Addendum: Alguien se ha tomado la molestia de aplicar jQuery a cada elemento para que se pueda contemplar el trabajo paso a paso de la creación de la figura. Ver Aquí.

Dromaeo

John Resig acaba de dar a conocer un sistema para testear el rendimiento de Javascript en cualquier plataforma llamado Dromaeo. Más información en el post que lo ha dado a conocer y en el wiki creado para discutir sobre el sistema.

También permite realizar comparaciones entre navegadores, muchas de ellas interesantes:

• http://dromaeo.com/?id=222,223,219 (Compara Safari 3.1, Firefox 3.0b5, y Opera 9.5 nightly sobre Mac OSX.)
• http://dromaeo.com/?id=232,226,229,237 (Compara Safari 3.1, Firefox 3.0b5, Opera 9.5 nightly, y IE 8b1 sobre Windows XP.)
• http://dromaeo.com/?id=250,246,251,256 (Compara Safari 3.1, Firefox 3.0b5, Opera 9.5 nightly, y IE 8b1 sobre Windows Vista.)
• http://dromaeo.com/?id=234,236,237 (Compara IE 6, IE 7, e IE 8 sobre Windows XP.)

41 of the Best MooTools Ajax Example Downloads | Speckyboy. Via aNieto2k.

Nuevas propuestas para CSS

aNieto2k:
New features proposed for CSS - CSS3 . Info.

• CSS Animation
• CSS Transforms
• CSS Transitions
• CSS Variables

Especialmente útiles las últimas ya que, entre otras cosas, evitan repetir valores a lo largo del código, facilitando las modificaciones al aparecer en un único lugar al principio de la hoja de estilos.

MindTouch

En su boletín de Marzo, MindTouch anunciaba varios cambios a su sistema de contenidos (wiki). MindTouch es un completísimo wiki open-source orientado a organizaciones y comunidades y que permite colaborar en equipo, compartir documentos como emails, videos, imágenes o documentos de Office u organizar proyectos. Se distribuye como una máquina virtual para VMWare, y que también está disponible como servicio en wik.is.



Al igual que Jotspot (adquirido por Google), las características del producto son impresionantes:

• Edición intuitiva WYSIWYG (tipo Word) que permite pegar contenido con formato o enlazar a otras páginas fácilmente.
• Subir archivos fácilmente adjuntándolas a la página actual y manteniendo versiones (nunca se pierde nada: si un usuario renombra un adjunto, todos los enlaces se actualizan).
• Sistema de permisos con soporte de grupos de usuarios y creación de espacios privados, de sólo lectura o páginas con contraseña.
• Soporte de jerarquías tradicionales, clasificación de páginas con tags, marcado automático de tiempos de los cambios realizados,...
• Utiliza el conocido y potente buscador Apache Lucene para encontrar cualquier documento rápidamente.

Dojo 1.1

Se acaba de liberar una nueva versión del framework Javascript Dojo, tal y como comentan en Tagneto. Entre sus mejoras:

• Notas de esta versión
• Nueva herramienta API
• Dojo Book
• Soporte multiversión
• Cargar Dojo después de cargar la página (ejemplo)
• Soporte para Adobe Air
• Almacenamiento en el lado del cliente con Dojo.storage
• Optimizaciones CSS en el sistema de montaje (build)
• Dojo Base, 29KB gzipped en un sólo archivo (dojo.xd.js) con funcionalidad base.
• Ejemplos: Gráficos, Calendario y Una página para jugar con la nueva versión online sin necesidad de descargarla

.

Timer and Interval Offset

John Resig explica que con los navegadores derivados de Gecko (Mozilla), es posible averiguar el tiempo exacto transcurrido entre llamadas a una función callback especificada en un setInterval:

var count = 0;
var interval = setInterval(function(off){

  document.body.innerHTML += " " + off;

  if ( ++count == 10 )
    clearInterval( interval );

}, 100);

Por ejemplo, éste código que en otros navegadores muestra diez undefined, en Mozilla muestra una secuencia parecida a 4 -8 -7 -3 6 1 -1 -3 0 0 que indica que, aunque la función debería llamarse cada 100 milisegundos exactos, en realidad, la primera llamada se hace a 104ms, la segunda 92ms después, la tercera 93ms después - y así sucesivamente. Esto puede ser muy útil para obtener una sincronización precisa.

JavaScript en el servidor con Helma

Aprovechando la aparición de la nueva versión de Helma (1.6.2), el servidor de aplicaciones web basado en Javascript, he traducido una pequeña pequeña introducción de Past Midnight: Se ha extendido el rumor de que el lenguaje de programación más ampliamente desplegado es Javascript, debido a que está embebido en cada navegador actual. Esta característica extraordinaria ha oscurecido el hecho de que el lenguaje en sí mismo no es sólo adaptable a programación en el lado del cliente, sino también para el desarrollo en el lado del servidor. Los lenguajes dinámicos y tipados débilmente ofrecen ciclos de desarrollo cortos, agilidad en adaptarse a los requerimientos cambiantes del cliente, particularmente para empresas sin procesos de negocio bien especificados, o empresas que se expanden rápidamente que adaptan constántemente su núcleo de negocio. Javascript en el navegador es el estándar de facto; usarlo en el servidor facilita el beneficio de reusar una sola base de código y de modelo de datos, y de depurarlo una sola vez.

También es relativamente conocido que existe ya más de una framework para programar Javascript en el servidor. La más madura de ellas es Helma, un framework abierto (opensource) que ha sido usado en entornos de producción durante años, como la Corporación de Radiodifusión Austríaca. He estado jugando con ella durante un tiempo y me gustaría mostrarte lo fácil que es levantarse y correr, con el fin de que cualquier alma aventurera tenga menos miedo y le brinde una oportunidad.

Configurar Helma es bastante directo. Lo primer es descargar la última versión de http://helma.org/download/. Sigue el enlace apropiado para tu plataforma y el archivo zip o tar se descargará en tu sistema. Tras extraer el archivo creará una carpeta con la última versión de Helma (1.6.1 cuando escribo esto) en ella. El único prerrequisito es que tengas Java instalado en tu sistema, ya que Helma usa internamente el motor Rhino de Javascript. Si tu sistema no tiene Java preinstalado, una visita a java.com debe ser suficiente. Debes obtener la última versión disponible (Java 6 en este momento), pero cualquiera posterior a la 1.4 es buena. Si ya lo tienes, ves al directorio de Helma y ejecuta start.bat o start.sh dependiendo de tu plataforma y deberías ver algunos mensajes breves:

Mac:~/helma-1.6.1 panagiotisastithas$ ./start.sh
Starting Helma in directory /Users/panagiotisastithas/helma-1.6.1
Starting HTTP server on port 8080
Starting Helma 1.6.1 (January 8 2008) on Java 1.5.0_13

El servidor está ahora preparado para aceptar peticiones. Helma incorpora Jetty como motor HTTP, algo que hace casi instantáneo el proceso de inicio y provee algunas elecciones arquitectónicas interesantes con su soporte para continuaciones. Apunta tu navegador a http://localhost:8080/ y verás la siguiente página de bienvenida:



Esta es una aplicación real, la aplicación “welcome”, con la que estás interactuando. Podrías navegar un poco para tener una primera idea a través de la documentación on-line disponible. Cuando tengas bastante, puedes detener el servidor volviendo a la ventana de la consola y pulsando Control-C:

^CShutting down Helma - please stand by...
Mac:~/helma-1.6.1 panagiotisastithas$

Para recapitular:

• Descarga Helma desde http://helma.org/download/
• Descomprimir
• Ir al directorio descomprimido
• Asegúrate de tener Java 1.4+ instalado
• Ejecutar start.bat/start.sh
• Navegar a http://localhost:8080/

Crear una aplicación simple con Helma implica sólo unos pocos pasos. Primero crear un directorio llamado _hello dentro del subdirectorio _apps del directorio principal de instalación de Helma (el que contiene el archivo _{app.properties}). Dentro de _hello, crear un directorio llamado _Root. Dentro de _Root crear un archivo llamado _actions.js con el siguiente contenido:

function main_action() {
   res.write("Hello, World!")
}

La siguiente captura ilustra nuestro progreso hasta el momento:



Ahora abre el archivo _{app.properties} en el directorio principal de instalación de Helma y añade una sola línea al final del archivo con el siguiente contenido:

hello

Ahora inicia (o reinicia si ya está en marcha) el servidor y apunta el navegador a http://localhost:8080/hello. Esto es lo que deberías ver en el navegador:



¡Ya está! Tu primera aplicación Javascript en el lado del servidor está preparada. En próximos posts discutiré como Helma junta las diferentes piezas y exploraré algunas de sus características más interesantes. Mientras tanto, sugiero que descargues y experimentes. ¡Podrías sorprendente gratamente!

aNieto2K: El juego Mario en un javascript de tan solo 14kb.

---

Addendum: John Resig analiza hoy las técnicas utilizadas por el juego para insertar gráficos y música dentro del único fichero .js con el que funciona. Básicamente hace uso de "data: URLs", o codificación de datos en línea, y un sistema para codificar los gráficos que usan índices a cuatro colores como máximo.

Google App Engine

La publicación por Google de un sistema para aprovechar sus recursos e infraestructura para alojar aplicaciones web de usuario, ha sacudido fuertemente a la comunidad de desarrolladores web (en especial de los programadores de Python). En los siguientes enlaces se pueden ver algunas de las reacciones. Y a continuación se puede leer la traducción que he realizado de la página de presentación del servicio.

• El más completo review
• Prueba en TechCrunch
• Bret Taylor de Friendfeed construye un blog CMS sobre Google App Engine en 30 minutos.
• Ejecutar Django en Google App Engine.
• Simon Willison:Write applications in Python using a WSGI compatible application framework, then host them on Google’s highly scalable infrastructure. The most exciting part is probably the Datastore API, which provides external developers with access to Bigtable for the first time.
• Videos en YouTube

Google App Engine te permite ejecutar tus aplicaciones web sobre la infraestructura de Google. Las aplicaciones App Engine son fáciles de construir, fáciles de mantener y fáciles de escalar conforme tu tráfico y necesidades de almacenamiento de datos crezcan. Con App Engine, no hay servidores que mantener: Sólo subes tu aplicación, y ya está preparada para servir a tus usuarios.

Puedes servir tu aplicación usando un nombre de dominio gratuito sobre el dominio appspot.com, o usar Google Apps para servirlas desde tu propio dominio. Puedes compartir tus aplicaciones con el mundo, o limitar el acceso a miembros de tu organización.

App Engine no cuesta nada para ponerse en marcha. Regístrate para una cuenta gratuita, y podrás desarrollar y publicar tu aplicación para que la vea todo el mundo, sin cargos y sin ninguna obligación. Una cuenta gratuita puede usar hasta 500MB de almacenamiento persistente, y suficiente PCU y ancho de banda para unas 5 millones de páginas vistas al mes.

Durante la fase preview de Google App Engine, sólo hay cuentas gratuitas disponibles. En el futuro próximo, podrás adquirir recursos de computación adicionales.

El entorno de aplicación

Google App Engine facilita construir una aplicación que se ejecuta fiablemente, incluso bajo condiciones de cargas elevadas y con grandes cantidades de datos. El entorno incluye las siguientes características:

• servicio web dinámico, con pleno soporte para tecnologías web comunes
• almacenamiento persistente con consultas, ordenación y transacciones
• escalado y balanceo de carga automáticos
• APIs para la autenticación de usuarios y para enviar emails usando cuentas Google
• un entorno de desarrollo local completo que simula Google App Engine en tu equipo

Las aplicaciones de Google App Engine se implementan usando el lenguaje de programación Python. El entorno en tiempo de ejecución (runtime) incluye el lenguaje Python completo y muchas de las librerías estándares de Python.

Aunque Python es actualmente el único lenguaje soportado por Google App Engine, esperamos soportar más lenguajes en el futuro.

La caja de arena (Sandbox)

Las aplicaciones se ejecutan en un entorno seguro que provee acceso limitado al sistema operativo subyacente. Estas limitaciones permiten a App Engine distribuir las peticiones web para aplicaciones a través de múltiples servidores, e iniciar y detener servidores según las demandas de tráfico. La sandbox aisla tu aplicación en su propio entorno seguro y fiable que es independiente del hardware, del sistema operativo y de la localización física del servidor web.

Ejemplos de las limitaciones del entorno seguro de la sandbox incluyen:

• Una aplicación sólo puede acceder a otros ordenadores en Internet a través de los servicios y APIs de obtención de URL y email. Otros ordenadores sólo pueden conectar a la aplicación haciendo peticiones HTTP (o HTTPS) sobre los puertos estándar.
• Una aplicación no puede escribir al sistema de archivos. Una aplicación puede leer archivos, pero sólo archivo subidos con el código de la aplicación. La aplicación debe usar el almacenamiento de App Engine para todos los datos que persisten entre peticiones.
• El código de aplicación sólo se ejecuta en respuesta a una petición web , y debe devolver datos de respuesta en unos pocos segundos. Un manejador (handler) de peticiones no puede crear un nuevo sub-proceso o ejecutar código después de que la respuesta haya sido enviada.

El entorno Python en tiempo de ejecución

App Engine provee un entorno en tiempo de ejecución que usa el lenguaje de programación Python. Otras configuraciones de lenguajes de programación y entornos de tiempo de ejecución están siendo considerados para futuras versiones.

El entorno de tiempo de ejecución Python usa la versión Python 2.5.2.

El entorno incluye la librería estándar Python. Desde luego, llamar a un método de la librería que viole la restricción de la sandbox, tal como intentar abrir un socket o escribir a un archivo, no tendrá éxito. Por conveniencia, varios módulos en la librería estándar cuyas características principales no están soportadas por el entorno en tiempo de ejecución han sido deshabilitadas, y el código que las importa lanzará un error.

El código de aplicación debe escribirse exclusivamente con Python. El código con extensiones escritas en C no está soportado.

El entorno Python provee APIs Python ricas para servicios de almacén de datos, cuentas Google, obtención de URL y email. App Engine también provee una framework simple para aplicaciones web Python llamada webapp para facilitar la construcción de aplicaciones.

Por conveniencia, App Engine también incluye la framework de aplicaciones web Django, version 0.96.1. Nótese que el almacén de datos de App Engine datastore no es una base de datos relacional, que es requerida por algunos componentes Django. Algunos componentes, tales como el motor de plantillas (templates) de Django, funcionan como está documentado, mientras que otros requieren un poco más de esfuerzo. Mirar la sección de Artículos sobre usar Django con App Engine.

Puedes subir otras librerías de terceros con tu aplicación, mientras estén implementadas con Python puro y no requieran ningún módulo de librería estándar no soportado.

Para más información sobre el entorno de ejecución de Python, mirar El Entorno en Tiempo de Ejecución Python.

El almacén de datos

App Engine provee un potente servicio de almacenamiento de datos distribuidos que incluye un motor de consultas y transacciones. Conforme el servidor web distribuido crece con tu tráfico, el almacén de datos distribuidos crece con tus datos.

El almacén de datos de The App Engine no es como una tradicional base de datos relacional. Objetos de datos, o "entidades", tienen una clase y un conjunto de propiedades. Las consultas pueden recuperar entidades de una clase dada filtradas y ordenadas por los valores de las propiedades. Los valores de las propiedades pueden ser cualquier de los tipo de valores de propiedades soportados.

El API Python para el almacén de datos incluye una interfície de modelado de datos que puede definir una estructura para las entidades del almacén. Un modelo de datos puede indicar que una propiedad debe tener un valor dentro de un rango, o proveer un valor por defecto si no se indica ninguno. Tu aplicación puede proveer tanta o tan poca estructura para los datos como necesite.

El almacén de datos usa bloqueo optimista para el control de la concurrencia. Una actualización de una entidad ocurre en una transacción que es reintentada un número fijo de veces si otros procesos están intentando actualizar la misma entidad simultáneamente. Tu aplicación puede ejecutar múltiples operaciones de almacenamiento de datos en una sola transacción con el resultado de éxito o fallo de todas ellas, para asegurar la integridad de tus datos.

El almacén de datos implementa transacciones a lo largo de su red distribuida usando "grupos de entidades". Una transacción manipula las entidades dentro de un solo grupo. Las entidades del mismo grupo se guardan juntas para la ejecución eficiente de transacciones. Tu aplicación puede asignar entidades a grupos cuando las entidades son creadas.

Para mayor información sobre el almacén de datos, mira la referencia de la API del Almacén de Datos.

Cuentas de Google

App Engine incluye un servicio API para integrar con cuentas de Google. Tu aplicación puede permitir a un usuario que abra sesión (log in) con una cuenta de Google, y acceder a su dirección de email y nombre de usuario asociado con la cuenta. Usar cuentas de Google permite al usuario iniciar tu aplicación más rápidamente, porque el usuario podría no necesitar crear una nueva cuenta. También te ahorra el esfuerzo de implementar un sistema de cuentas de usuario sólo para tu aplicación.

Si tu aplicación se ejecuta bajo Google Apps, puede usar las mismas características con miembros de tu organización y cuentas de Google Apps.

El API de usuarios también puede decirle a la aplicación si el usuario actual es un administrador registrado para la aplicación. Esto facilita implementar áreas para administradores en tu sitio.

Para mayor información sobre integración con cuentas de Google, mira la referencia de la API de Usuarios.

Los servicios de obtención de URL y Email

Las aplicaciones pueden acceder a recursos de Internet, tales como servicios web u otros datos, usando el servicio de obtención de URL de App Engine. El servicio de obtención de URL recupera recursos web usando la misma infraestructura de alta velocidad de Google que recupera las páginas web para otros productos de Google.

Las aplicaciones pueden también enviar mensajes de email usando el servicio de email de App Engine. El servicio de correo también usa la infraestructura de Google para enviar mensajes de email.

Para más información sobre los servicios de obtención de URL y correo, mira la referencia de la API de Obtención de URL y la referencia de la API de Correo.

Flujo de desarrollo

El Kit de desarrollo de software de App Engine (SDK) incluye una aplicación servidor web que emula todos los servicios de App Engine en tu ordenador local. El SDK incluye todas las APIs y librerías disponibles en App Engine. El servidor web también simula el entorno seguro sandbox, incluyendo comprobaciones de importación de módulos deshabilitados e intentos de acceder a recursos del sistema no permitidos.

El SDK de Python está implementado en Python puro, y se ejecuta en cualquier plataforma con Python 2.5, incluyendo Windows, Mac OS X y Linux. Puedes obtener Python para tu sistema en la web de Python. El SDK está disponible como un archivo Zip, y hay instaladores disponibles para Windows y Mac OS X.

Puedes descargar el SDK aquí.

El SDK también incluye una herramienta para subir tu aplicación a App Engine. Una vez que has creado tu código de aplicación, archivos estáticos y archivos de configuración, puedes ejecutar la herramienta para subir los datos. La herramienta te pide tu cuenta de correo de Google y la contraseña.

Cuando construyes una versión principal de una aplicación que esté ejecutándose en App Engine, puedes subir la nueva versión como tal. La vieja versión continuará sirviendo usuarios hasta que pases a la nueva versión. Puedes probar la nueva versión en App Engine mientras la vieja versión sigue ejecutándose.

La Consola de Administración es una interfície basada en web para gestionar tus aplicaciones ejecutándose en App Engine. Puedes usarla para crear nuevas aplicaciones, configurar nombres de dominio, cambiar qué versión de tu aplicación está en funcionamiento, examinar los registros (logs) de accesos y errores, e inspeccionar el almacén de datos de la aplicación.

Cuotas y límites

No sólo es fácil de crear una aplicación de App Engine, sino que ¡es gratis! Puedes crear una cuenta y publicar una aplicación que la gente pueda usar directamente sin cargos, y sin obligaciones. Una aplicación en una cuenta gratuita puede usar hasta 500MB de almacenamiento y hasta 5 millones de páginas vistas al mes.

Durante la fase preview de Google App Engine, sólo hay cuentas gratuitas disponibles. En el futuro próximo, podrás adquirir recursos de computación adicionales.

Durante la fase preview, puedes registrar hasta 3 aplicaciones.

Los límites de recursos de aplicación, o "cuotas", se refrescan continuamente. Si tu aplicación alcanza una cuota basada en tiempo, tal como el ancho de banda, la cuota empezará a refrescarse inmediatamente al ritmo del límite dado. Las cuotas fijas tales como el uso de almacenamiento son sólo liberadas cuando se decrementa el uso.

Algunas características imponen límites no relacionados con cuotas para proteger la estabilidad del sistema. Por ejemplo, cuando una aplicación se llama para servir una petición web, debe dar una respuesta en unos pocos segundos. Si la aplicación tarda demasiado, el proceso es terminado y el servidor devuelve un mensaje de error al usuario. El tiempo límite es dinámico, y puede ser acortado si un manejador (handler) de peticiones alcanza su límite frecuentemente con el fin de conservar recursos.

Otro ejemplo de límite de servicio es el número de resultados obtenidos por una consulta. Una consulta puede devolver como mucho 1000 resultados. Las consultas que generen más resultados, sólo devolverán ese máximo. En este caso, una petición que lleve a cabo esa consulta no es probable que devuelva una petición antes del tiempo límite, pero el límite se mantiene para conservar los recursos del almacén de datos.

Intentos de subvertir o abusar de las cuotas, tales como operar aplicaciones sobre múltiples cuentas y que trabajen en tandem, son una violación de los Términos de Servicio, y podría resultar en aplicaciones deshabilitadas o en cuentas clausuradas.

Para mayor información...

Para mayor información sobre el Google App Engine:

• Mira el video de Campfire One o lee su transcripción.
• Mira el video demo de App Engine.
• Descarga el SDK, registra una nueva cuenta, lee la Guía de inicio y sigue el tutorial.
• Inspecciona la Galería de Aplicaciones para ejemplos de aplicaciones construidas con App Engine.
• Comprueba el resto de documentación de App Engine.

HotRuby, máquina virtual de Ruby con JavaScript

John Resig acaba de publicar un review de un nuevo proyecto llamado HotRuby que lo que hace es convertir un script embebido en la página en formato Ruby en código Javascript ejecutable. En cuatro pasos:

1. Primero un script local encuentra las etiquetas <script type="text/ruby"></script> y extrae el código en línea de su interior.
2. El código Ruby es enviado al servidor via XMLHttpRequest.
3. El script CGI en el servidor (escrito en Ruby 1.9) compila el código Ruby en sus opcodes asociados (código de máquina virtual) y los serializa en una estructura de datos JSON.
4. El navegador recibe los opcodes, los traduce a Javascript y lo ejecuta

Ver ejemplo. Lo más fascinante son los resultados:

Firefox 3.0 beta 5 :	2.47 segundos
Firefox 2 :	6.71 segundos
Ruby 1.8.2 :	12.25 segundos

Es decir, el resultado es cinco veces más rápido que con la Máquina Virtual propia de Ruby.

Processing

Interesante introducción a Processing, un lenguaje de programación orientado a la visualización y animación de datos. Cuando apareció, algunos lo intentaron comparar con Flash, pero Processing no es tan comercial, está vinculado al mundo universitario, y está mucho más orientado a trabajar en la visualización de información explorando nuevas ideas. Algunos ejemplos: Bouncing, Zip Decode, Substrate, Genetic Tree o Solar, una animación sincronizada con una canción. Via el blog de John Resig.

clearfix

Comentan mis excompañeros de Pixelinglife (Observer) un truco para conseguir terminar una serie de floats de forma que el siguiente elemento se ubique bajo ellos. La forma habitual de hacerlo implica crear un elemento div vacío con el estilo clear establecido (both, left o right). Pues bien, si se le asigna la clase clearfloat al último elemento float se conseguirá el mismo resultado, definiendo dicha clase de la siguiente forma:

.clearfix:after
{
  content: ".";
  display: block;
  height: 0;
  clear: both;
  visibility: hidden;
}

Como se puede ver, estamos usando la pseudo-clase :after para generar automáticamente un elemento con el mismo resultado.

XUL, ideal para applets robustos

XUL es un lenguaje basado en XML interpretado por el motor de los navegadores Mozilla (Gecko) para crear interfícies de programa. Firefox o Firebird tienen definidos sus interfícies (diálogos, botones, ...) con este lenguaje. Al ser interpretado, es posible indicar una URL para obtener un recurso XUL y que este se muestre como si fuese una página web, pero con las ventajas en cuanto a robustez y velocidad de respuesta de una aplicación de escritorio:

Lo interesante de los applets de XUL es su tamaño ligero y su naturaleza interpretada. XUL, Javascript o CSS son lenguajes interpretados, y cada uno está libre de la formalidad de lenguajes totalmente orientados a objetos. La simplicidad y facilidad de expresión de XUL lo convierte en una gran tecnología para el prototipado de interfícies (GUI). Su flexibilidad facilita separar o reorganizar tales interfícies.

Aunque esté restringido a la plataforma Mozilla, varios escenarios corporativos pueden beneficiarse de este enfoque, particularmente intranets donde el software de cliente está controlado por configuración. Otros ejemplos son entrega de análisis o terminales software de introducción de datos para mejorar el rendimiento de los usuarios. Las características de XUL ilustradas en este artículo son sólo la punta del iceberg.

Tutorial de IBM para crear applets con XUL.

Ejemplos: (Ver sólo con Firefox, K-Meleon o Prism) Pequeños tests en Xul.
Gestor de presentaciones y una presentación de ejemplo.

Técnicas avanzadas de depuración JavaScript

SitePen Blog : Advanced JavaScript Debugging Techniques. Más que interesante guía de depuración para ptogramadores Javascript con muchas ideas para localizar cualquier problema con el código. Imprescindible.

UTF-8

Douglas Crockford:

"UTF-8 es una de las cosas más elegantes que he visto. Es una codificación de flujos de bytes para valores simples (como los caracteres Unicode) que pueden ser mayores que un byte. UTF-8 tiene algunas propiedades maravillosas:

• ASCII es un subconjunto válido, por lo que todos los flujos codificados en ASCII son también flujos UTF-8.
• El primer byte de un caracter multi-byte indica el número de bytes que lo componen.
• Los bytes de continuación son fácilmente distinguibles de los primeros bytes.
• Se preserva la ordenación.

Un primes byte puede contener entre 2 y 7 bits de datos. Cada byte de continuación lleva 6 bits de datos.

UTF-8 tiene una desventaja desafortunada, que algunos caracteres de 16-bits se codifican en 3 bytes (24 bits). Esta desventaja es más que compensada por sus otras ventajas, y por tener una sola y simple codificación que funciona en todos los lenguajes y contextos. Los beneficios van desde una mayor fiabilidad a una mayor seguridad. Esa es la razón por la que JSON usa UTF-8. UTF-8 es buen material. Gracias, Ken Thompson. [...]

Primer Byte	Longitud	Primeros Bits	Bits Totales	Rango
00-7f	1	7	7	7f
80-bf	continuación		6	n/a
c0-df	2	5	11	7ff
e0-ef	3	4	16	ffff
f0-f7	4	3	21	1fffff
f8-fb	5	2	26	3ffffff
fc-ff	6	2	32	ffffffff

CSS Compatibility and Internet Explorer

Tabla de Microsoft que muestra la compatibilidad de cada versión de Internet Explorer con cada característica de CSS.

Manejando datos jerárquicos en bases de datos relacionales

Aunque la mayoría optamos por usar un campo "padre" cuando tenemos que tratar con estructuras jerárquicas...

+-------------+----------------------+--------+
| category_id | name                 | parent |
+-------------+----------------------+--------+
|           1 | ELECTRONICS          |   NULL |
|           2 | TELEVISIONS          |      1 |
|           3 | TUBE                 |      2 |
|           4 | LCD                  |      2 |
|           5 | PLASMA               |      2 |
|           6 | PORTABLE ELECTRONICS |      1 |
|           7 | MP3 PLAYERS          |      6 |
|           8 | FLASH                |      7 |
|           9 | CD PLAYERS           |      6 |
|          10 | 2 WAY RADIOS         |      6 |
+-------------+----------------------+--------+

...existe la alternativa de usar conjuntos anidados representados por pares de números que indican los límites izquierdo y derecho:

+-------------+----------------------+-----+-----+
| category_id | name                 | lft | rgt |
+-------------+----------------------+-----+-----+
|           1 | ELECTRONICS          |   1 |  20 |
|           2 | TELEVISIONS          |   2 |   9 |
|           3 | TUBE                 |   3 |   4 |
|           4 | LCD                  |   5 |   6 |
|           5 | PLASMA               |   7 |   8 |
|           6 | PORTABLE ELECTRONICS |  10 |  19 |
|           7 | MP3 PLAYERS          |  11 |  14 |
|           8 | FLASH                |  12 |  13 |
|           9 | CD PLAYERS           |  15 |  16 |
|          10 | 2 WAY RADIOS         |  17 |  18 |
+-------------+----------------------+-----+-----+

Las ventajas y el mantenimiento se explican en el artículo Managing Hierarchical Data in MySQL