Se trata de la respuesta al .JAR de Java y por tanto es una forma de empaquetar todos los archivos de una misma aplicación dentro de un archivo con compresión Zip.

Phar será integrado en la versión 5.3 de PHP. La otra ventaja es evidente, por ejemplo, instalar una aplicación web como Wordpress copiando un sólo archivo al raíz del servidor web. O publicar una librería para usar en los programas propios indicando un sólo archivo .phar.

// Referencing a .phar archive or its contents:
include 'userlibrary.phar';
include 'phar://userlibrary.phar/internal/file.php';
 
// Utilizing the Phar Stream Wrapper:
header('Content-type: image/jpeg');
echo file_get_contents('phar://userlibrary.phar/img/image.jpg');

Visto en NickAWilliams.com.

Una tendencia muy marcada ultimamente por los sitios web con mucha afluencia de tráfico es crear colas dedicadas para los trabajos que no necesitan actualización instantánea (ver Amazon SQS o Apache ActiveMQ). Por ejemplo, al subir una foto en Flickr, tal y como explican aquí, los cambios han de reflejarse sobre la página del usuario, pero también en todos sus contactos.

Puesto que lo realmente importante es la sensación de respuesta rápida del usuario, y para realizar todas esas actualizaciones habría que atacar varias tablas, sólo se realiza instantáneamente la actualización para el propio usuario, dejando el resto del trabajo en una cola para que otros procesos dedicados se encarguen del resto de actualizaciones. Esa obsesión de quitarse de encima el trabajo es la que está calando en el lado del servidor, y no sólo con sistemas de caché, sino identificando cualquier cuello de botella por pequeño que sea.

En el caso de Flickr, tal y como explican en el artículo, ellos mismos han creado su propio sistema de colas funcionando sobre el mismo lenguaje que utilizan en el resto del site (PHP). De esa forma les resulta más cómodo realizar cambios y tenerlo todo integrado.

En Ajaxian anuncian la disponibilidad inminente de la API jQuery para ASP.NET y para el desarrollo de aplicaciones web sobre el motor webkit (Apple Safari, Apple iPhone, Google Chrome) para navegadores en teléfonos Nokia. Una excelente noticia para una plataforma que no ha hecho sino aumentar su difusión.

Pero además tenemos otra buena noticia: hace poco se publicaba el proyecto PhoneGap con la finalidad de poder acceder a funcionalidades del teléfono desde aplicaciones web que sólo están disponibles usando el SDK oficial. Parece que Nokia va a seguir el mismo camino. Aunque esto pueda suponer un problema de seguridad, bien implementado tendrá como consecuencia un uso aún mayor de la plataforma web para el desarrollo y ejecución de aplicaciones.

Competitividad en los motores Javascript. Esa es la mejor noticia que podría traer la aparición de Google Chrome. No sólo el nuevo motor TraceMonkey de Firefox 3.1 es ahora la versión que viene activada por defecto acortando distancias con V8 (por cierto, cuyo funcionamiento explican muy bien en Ajaxian), sino que además el equipo de WebKit acaba de anunciar la disponibilidad de su nuevo motor SquirrelFish Extreme.

Empezar una guerra de velocidad (que no de compatibilidad) entre navegadores es un notición para los desarrolladores web. Presuponer la total compatibilidad de los navegadores con los estándares y desplazar el área de competitividad al terreno de la velocidad (en el que sigue habiendo mucho margen de mejora) es la noticia perfecta para el usuario medio. Y además es una forma excelente de dejar descolgada a la histórica oveja negra (IE). Y es que, ¿qué mejor forma de perder cuota de mercado que la lentitud?

Una de las consecuencias del incremento del uso de Javascript es el de los problemas de seguridad. Al igual que los virus atacan al sistema operativo más extendida (Windows) no sólo por su falta de seguridad, con el tiempo están surgiendo más agujeros en las páginas web que pueden ser aprovechadas para robar información.

En esta presentación de Simon Willison en el evento @mediaAjax 2008 se hace una descripción de todos los problemas que han ido surgiendo en el desarrollo web y que se deberían conocer a la hora de programar código que va a estar expuesto en Internet. Siglas como XSS, CSRF, las inyecciones de código javascript y las vulnerabilidades de Flash o del PDF deberían resultar familiares. Los ejemplos que se indican en la presentación son muy reveladores.

En cualquier caso, el uso de la extensión NoScript de Firefox es mucho más que recomendable. Ya se conocen casos de robo de dominios gracias a un problema de seguridad con GMail que permitía crear un filtro de reenvío de correo sin que el usuario se enterase.

Una situación muy común en programación es necesitar ayuda para resolver un problema concreto. A partir de una búsqueda en Google se obtiene:

• Un montón de enlaces a foros de discusión en los que gente que tampoco tiene ni idea del tema se pega con el mismo problema y no consigue resolverlo.
• Un enlace a un sitio de preguntas y respuestas que aparenta tener la respuesta, pero cuando llegas, la respuesta está encriptada o se te pide que te des de alta a un plan de suscripción de pago.
• Un antiguo artículo en Usenet con la respuesta exacta al problema pero para Windows 3.1 que, casualmente, ya no es aplicable ni funciona.
• Algo en otro idioma imposible de entender.

Si tienes suerte, puede que en la cuarta página de resultados encuentres una página con montones de respuestas de las cuales el 25% son anuncios de spam y de las que algunas son realmente útiles enterradas entre tanta basura.

Esta ha sido la demostración de la necesidad de un nuevo site de preguntas y respuestas orientado a la programación llamado stackoverflow.com. La idea es que las preguntas aparezcan una sola vez, se clasifiquen y que sean los usuarios los que, mediante un sistema de puntuaciones, hagan subir las mejores respuestas.



Via ClientSide.

Hace unos meses, con el auge de las redes sociales, muchos sitios (facebook, myspace, ...) empezaron a pedir las credenciales de acceso a tus cuentas de otros sitios para acceder a tu lista de contactos sin tener que introducirlos expresamente uno a uno. Esa práctica resultaba peligrosa, porque aunque los sitios expresamente afirman que no se guardan las contraseñas, no hay más remedio que fiarse de su palabra, lo que en la época del phising y de los crackers roba-contraseñas resulta prudente no fiarse.

OAuth fue la respuesta de la comunidad ante estas prácticas. Un estándar respaldado por los grandes que permite el acceso a esos datos siempre y cuando el usuario de su permiso expreso solicitado desde el sitio que alberga la información y a petición del sitio que desea obtenerla.

Por ello no se entiende que a estas alturas, Google publique el siguiente formulario en el que, como puede apreciarse, repite la mala práctica de solicitar al usuario lo que nunca debería solicitar un sitio web de otro. Tirón de orejas para los señores.

Via ZdNet

En AskApache mencionan una herramienta para comparar el resultado de aplicar las herramientas de compresión de código Javascript existentes (JsMin, Dojo shrinksafe, Packer y YUI compressor).

Hay que tener en cuenta que para códigos distintos, la mejor herramienta puede variar, por lo que una comparativa es útil para identificar la mejor compresión. Aunque por otra parte, conviene tener en cuenta que el tiempo de descompresión necesario antes de tener el código disponible en el lado del cliente debe ser tenido en cuenta. Unos pocos bytes no necesariamente van a implicar, por tanto, una mejor experiencia para el usuario.

Debe tenerse en cuenta también que teniendo activada la opción de compresión gzip en el lado del servidor, y que los navegadores modernos aceptan sin problemas, el tamaño aún se reduce más. Para comparar con los casos en que no se hace puede usarse la casilla gzip del comparador.

El hecho de que Google Chrome sea fuente abierta y, por tanto, también lo sea el nuevo motor Google V8 desarrollado sobre C++ implica que es cuestión de tiempo que aparezcan soluciones de servidor de aplicaciones como PHP, Python o Ruby pero teniendo como lenguaje de desarrollo a Javascript. Un Javascript bastante optimizado que puede comerse un bocado del pastel que hay al otro lado del navegador.

Hasta hoy, muy pocas plataformas como Helma han tenido una cierta notoriedad con ese lenguaje y a ese lado de la conexión. Google Chrome va a traer muchos cambios a muchas cosas, sustituyendo al sistema operativo como ya apuntan muchos. Es previsible que Google continúe publicando programas que, funcionando en el navegador, sustituyan a las aplicaciones más comunes con las que realizamos tareas cotidianas: editores de texto, entornos de desarrollo, edición gráfica y vectorial, visores de imágenes, reproductores multimedia y, en definitiva, todo aquello que hasta ahora se ha considerado terreno exclusivo del escritorio.

En cualquier caso, tendría gracia que Javascript, el lenguaje de la web, ninguneado durante años y considerado un juguete por muchos (en buena parte por culpa de las pésimas implementaciones del DOM del navegador), empezase, merecidamente, a desvincularse del navegador (y del DOM) y a hablar de tú a tú a los (cada vez menos) omnipresentes Java, Visual Basic o C++.

Y ya puestos, ¿por qué no hay una versión de Google App Engine con V8 como motor?

Repito las siguientes frases del post oficial:

• Como la página de inicio de Google clásica, Chrome es limpio y rápido. Se aparta de tu camino y te lleva donde quieres ir.
• Un motor de Javascript, V8, para mover la siguiente generación de aplicaciones web que ni siquiera son posibles en los navegadores actuales.
• Este es sólo el principio.
• Hemos usado componentes de Apple's WebKit y de Mozilla Firefox entre otros [...]. Esperamos colaborar pcon la comunidad entera para ayudar a llevar hacia adelante la web.

En página dan detalles del motor de Javascript y de las optimizaciones implementadas. Sobre esto, Simon Willison destaca el uso de clases ocultas para optimizar la obtención de propiedades de los objetos y un poco de información sobre la generación de código máquina y el trabajo del colector de basura (garbage collection). El código fuente completo está disponible en el proyecto Chromium de Google Code.

Todavía está plagado de detalles por corregir. Por ejemplo no funciona la rueda del ratón o la gestión de procesos correspondiente a pestañas no parece corresponderse totalmente. También he tenido problemas para acceder a las páginas que albergo en el trabajo, aunque después he encontrado la opción "Utilizar la precarga de DNS para mejorar el rendimiento de carga de páginas" que denota el afán por arañar milisegundos de cualquier sitio para optimizar la carga de páginas, pero que en mi caso puede suponer un problema por el cambio de DNS que hago periódicamente para acceder a mis sitios.

Respecto a las implicaciones, Enrique Dans hace un análisis de mercado, mientras que John Resig habla de las implicaciones del cambio de arquitectura remarcando acertadamente que exponer el consumo de recursos de cada página va a suponer una carga adicional a los desarrolladores de páginas y aplicaciones web. Varios sitios apuntan a que, sin lugar a dudas, se va a convertir en uno de los navegadores principales de forma casi inmediata. Conviene recordar que hace 4 años Google descartaba pisar este terreno. Probablemente, el crecimiento de Firefox 3 por debajo de las expectativas de Google y el que Internet Explorer (los que más incumplen los estándares) sigan con una cuota de mercado tan exagerada ha motivado que Google decida tomar cartas en el asunto. No son los únicos convencidos de que cuando la cuota del navegador de Microsoft pierda posiciones, los estándares web experimentarán un empuje tremendo fruto de la enorme cantidad de tiempo que todos los programadores perdemos en "compatibilizar" nuestro trabajo con ese navegador.

Algunos análisis destacan la velocidad del motor de renderizado (que es Webkit, el mismo que Safari, el iPhone y Android) y del motor de Javascript. Las pruebas muestran que, aún estando en beta, ya es tres veces más rápido que Firefox 3.1. Incluye herramientas para depuración que aún están lejos de Firebug pero que resultan más que completas para ser la que viene incluida con el navegador sin plugins adicionales.


En resumen, aunque supone una amenaza evidente para Firefox, el objetivo parece ser terminar con la hegemonía de Internet Explorer de una vez, usando para ello un navegador rápido, simple y atractivo y respaldado por una compañía que, ahora sí, todo el mundo conoce. Deseémosle suerte.

Via Blogoscoped y Simon Willison. El único precedente es el navegador incluido en Android, el sistema operativo para móviles de Google y que sigue sin tener un teléfono en el mercado. Pero Chrome, que viene explicado como un cómic, es sólo un globo sonda, vaporware, para obtener ideas y tantear el actitud de la comunidad. Características:

• basado en el motor webkit (Safari, Android)
• multi-hilo para evitar que se bloquee el navegador al ejecutar javascript
• más seguro con cambios estructurales para evitar el malware y actualizaciones continuas de sitios dañinos
• más estable
• más veloz, con optimizaciones importantes en una máquina virtual para javascript (V8)
• cada pestaña tendría su propio proceso
• open source
• interfície de usuario limpia, simple y eficiente, con las pestañas en la parte superior externa de la ventana y no en la parte superior
• barra de direcciones inteligente, muy parecida a la de firefox 3, pero con sugerencias y la posibilidad de utilizar el motor de búsquedas de los sites visitados
• más privada, posibilidad de usar una pestaña en modo "incógnito" en la que nada de lo que se haga queda registrado en ningún caso (como Microsoft InPrivate en IE8)
• aplicaciones web ejecutables como ventanas separadas (Mozilla Prism)
• sistema de plugins

Según este post en el blog de Google, Chrome será publicado mañana martes día 2 de Septiembre. Ver capturas de pantalla aquí y aquí. Firefox dejaría de ser el navegador soportado por Google. Además, un navegador optimizado para el uso de aplicaciones de Google va a introducir muchísima presión a Microsoft. Internet Explorer no va a tener muchas más opciones que comportarse correctamente si quiere no perder demasiada cuota de mercado. De hecho toda la actividad del equipo del IE, parada durante 4 años con el IE6, podría deberse a que Microsoft sabía de este proyecto de Google. La probable ubicación de descarga será http://www.google.com/chrome .