AOWS

Google and Dell tipped to reveal iPhone rival plans. A pesar de ser un gadget caro y con muchos defectos, el nuevo juguete de Apple es la nueva referencia en el mundo de la telefonía móvil.

Los rumores apuntan ahora a una posible alianza entre Google y Dell para hacer frente a la manzana en este terreno. Desde hace tiempo se viene hablando de un posible gPhone, pero las habladurías cesaron cuando se presentó Android.

A más competencia, mejores precios y mejores aparatos, por lo que los beneficiados seremos los consumidores. En unos días (el 11 de febrero para ser más exactos), en el 3GSM de Barcelona, se podrían dar las primeras pistas.

En esta misma conferencia se espera, además, que Telefónica confirme la salida del iPhone en España a lo largo del mes de abril. Esperemos también se detallen precios y planes.

PD: aprovechando el post, comentar el pistoletazo de salida triunfal de Simyo, un nuevo operador que promete numerosas novedades. Las más llamativas, poder darse de baja desde su página web con dos clicks y una interesante tarifa de datos (100MB al día por 0,99€+IVA diarios). Veremos qué tal sale.

El fundador de MySQL, Michael Widenius, acaba de anunciar el lanzamiento del motor que reemplazará a MyISAM, Maria.

Curiosa historia la del nombre: el primer hijo de Michael se llamaba My, de ahí MySQL; al segundo le pusieron Max, utilizado para MaxDB; supongo que todos sabrán cómo se llama la tercera hija de este señor .

Pero volviendo al tema, las principales características de Maria serán (en la futura versión 2.0):

• ACID
• Transacciones
• Consultas concurrentes
• Bloqueo a nivel de registro
• Commit de grupos de transacciones

Maria formará parte de MySQL 6.0.

PD: no lo había comentado por aquí, pero hace unos días Sun se hizo con MySQL. En principio, una buena noticia, que por lo que se ve no está afectando al desarrollo del popular gestor de bases de datos.

Relacionado | MyISAM vs InnoDB

Tenemos varias opciones: las sucias (utilizar scriptlets en las JSP o formatear la fecha en Java y pasarla como String), y la más elegante utilizando JSTL.

La etiqueta formatDate nos permite mostrar una fecha en una JSP de forma sencilla sin más complicaciones.

Sintaxis:

<fmt:formatDate value="expression"
    timeZone="expression"
    type="field" dateStyle="style"
    timeStyle="style"
    pattern="expression"
    var="name" scope="scope"/>

• value: es el único atributo obligatorio, debe ser de tipo java.util.Date y es el que especifica la fecha/hora a mostrar.
• timeZone: indica la zona horaria, por defecto la de la máquina virtual.
• type: indica qué campos de la clase Date se mostrarán. Opciones: time, date o both. Por defecto muestra sólo la fecha.
• dateStyle y timeStyle: cómo se muestran la fecha y la hora, respectivamente. Opciones: default, short, medium, long y full. Por defecto utiliza el locale.
• pattern: nos permite definir un estilo propio, siguiendo el mismo patrón que la clase java.text.SimpleDateFormat. A continuación veremos un ejemplo.
• var: indica la variable donde se guardará la fecha formateada. Por defecto se mostraría por pantalla.
• scope: ámbito de la variable definida en var.

Ejemplo:

<fmt:formatDate value="${fecha}" pattern="dd-MM-yyyy" />

Más completo:

<fmt:timeZone value="CET">
	<c:forEach items="${listaPosts}" var="post">
		<h2><c:out value="${post.titulo}" escapeXml="false"/></h2>

		<div class="contenido-post">
			<c:out value="${post.texto}" escapeXml="false"/>
			<p class="fecha">
				Fecha: <fmt:formatDate value="${post.fecha}" pattern="hh:mm"/>]
			</p>
		</div>
	</c:forEach>
</fmt:timeZone>

Hace tiempo hablé brevemente sobre la inyección SQL y cómo evitarla en ciertos casos concretos con PHP. En este post intentaré profundizar un poco más en este tema y dejar para uno posterior soluciones al problema.

Qué es la inyección SQL

La inyección SQL es una técnica usada para aprovecharse de las entradas que recibe una aplicación, no validadas y utilizadas posteriormente en la construcción de sentencias SQL. Un error muy común a la hora de desarrollar una aplicación web es usar los parámetros proporcionados por el usuario directamente en las consultas, lo que aprovecha el atacante para introducir las modificaciones que necesite para su malicioso cometido. Así, se podría ejecutar cualquier tipo de sentencia SQL en la base de datos valiéndose de estos agujeros de la aplicación o página web.

Como su propio nombre indica, la inyección SQL se da en dicho lenguaje y sobre cualquier plataforma que lo utilice para trabajar contra una BD.

Ejemplo rápido y sencillo

Si tenemos un formulario de búsqueda de usuarios que utiliza la siguiente consulta para conseguir los resultados:

String consulta = "SELECT *
			     FROM usuarios
			     WHERE nombre = '" + texto + "'";

el usuario puede introducir, por ejemplo, pepe, resultando una consulta correcta:

SELECT *
FROM usuarios
WHERE nombre = 'pepe';

Pero, ¿qué ocurre si introduce algo como pepe' OR 'a'='a?

SELECT *
FROM usuarios
WHERE nombre = 'pepe' OR 'a'='a';

Y esta consulta, como vemos, haría que la cláusula del where se cumpla siempre devolviéndonos todos los registros de la tabla.

Peligros principales

• Confidencialidad: las bases de datos contienen datos importantes y privados, la pérdida de confidencialidad es un problema frecuente en las vulnerabilidades de inyección SQL.
• Autenticación: si se utilizan sentencias SQL mal construidas para la comprobación de usuario y contraseña, se podría utilizar este agujero de seguridad para loguearnos con cualquier identidad en un sistema.
• Autorización: como cualquier información almacenada en la base de datos, los permisos y privilegios de un sistema pueden verse afectados por este tipo de ataques.
• Integridad: las posibles modificaciones y borrados que puede producir un ataque de inyección SQL conllevan un peligro enorme para la integridad de los datos.

Por desgracia, este problema es fácilmente detectable y explotable, por lo que hay que tener un cuidado extremo para evitar a toda costa la inyección SQL. En el próximo post veremos algunas soluciones sencillas y eficaces para varios lenguajes y plataformas.

Smultron es el editor que suelo utilizar para ediciones menores, es ligero, rápido y sencillo. Por ello no acabo de entender que la última versión, la 3.3 (no tengo ni idea de cuándo vio la luz), sea sólo para Leopard.

Muy pronto está comenzando a quedarse atrás Tiger por lo que veo. Hace menos de medio año que el nuevo sistema operativo está a la venta, y el 20% de los Macs ya lo están usando. Yo por el momento resistiré a la tentación pues no tengo intención de gastarme 120€ en la licencia, y menos mientras pueda seguir trabajando perfectamente con lo que tengo ahora.

Últimamente me estoy empapando bastante en cuanto a temas de usabilidad, algo que cada día cobra más importancia y que podría marcar el posible éxito o fracaso de una página o aplicación web. Además del excelente libro de Steve Krug (el cual comentaré próximamente), existen multitud de documentos en la red más que recomendables.

Un ejemplo es el Introduction to Good Usability, un paper (pdf) de escasas 21 páginas donde se exponen algunos problemas clásicos de usabilidad y se dan algunos consejos para evitarlos.

Visto en Sentido Web.

Oracle, al contrario que MySQL, sí diferencia entre mayúsculas y minúsculas en las búsquedas. Esto, unido a la tradicional problemática con las tildes y demás símbolos extraños, hace que debamos tomar medidas en nuestras consultas para conseguir los resultados deseados.

Así, si nuestra búsqueda era:

[sql]
SELECT *
FROM tabla
WHERE campo LIKE ‘%texto%’;
[/sql]

si queremos que nos devuelva las coincidencias ignorando tildes y mayúsculas, la transformaríamos en:

[sql]
SELECT *
FROM tabla
WHERE UPPER(translate(campo, ‘áéíóúÁÉÍÓÚ’, ‘aeiouAEIOU’)) LIKE UPPER(translate(‘%texto’, ‘áéíóúÁÉÍÓÚ’, ‘aeiouAEIOU’));
[/sql]

La función UPPER convierte todos los caracteres a mayúsculas en ambos lugares (base de datos y texto a buscar), de forma que se ignoren las diferencias por estar en mayúsculas o minúsculas.

Con translate transformamos una serie de caracteres en otros, concretamente en el caso anterior estaríamos eliminando las tildes.

No es un método sencillo, quizá haya alguna forma de configurar Oracle para evitar realizar estas operaciones, pero funciona.

Un post recopilatorio de enlaces interesantes que tenía por aquí almacenados.

• Google Health en camino. El ojo que todo lo ve: conocen tus intereses y qué sitios frecuentas, les cuentas tu vida, compartes con ellos tus fotos, saben qué harás la próxima semana, tienen tus documentos, leen tus correos, les presentas a tus amigos, debates delante de ellos, les prestas tu código, ven tu casa desde el aire y a ras de suelo. Ahora también sabrán si sufres de almorranas o tienes gripe. Google empieza a dar “algo” de miedo.
• Better Email Links: Featuring CSS Attribute Selectors. Una técnica interesante para mejorar la presentación de los enlaces a direcciones de email utilizando CSS.
• Descargarse archivos por P2P, ¿es delito?. Descargar material protegido, se entiende. Una explicación que debería aclarar este aspecto a pesar de que nos quieran hacer creer lo contrario: un usuario de Internet que desde su domicilio intercambia obras protegidas por la Ley de Propiedad Intelectual no comete delito alguno si dicha conducta se realiza sin ánimo de lucro.
• Componentes de una página de éxito, lo que se ve sólo es la punta del iceberg. Por desgracia este trabajo todavía se toma como un juego de niños.
• WordPress.com, ahora con 3GB de espacio. Un paso adelante de la popular plataforma de blogs, pero mientras no se puedan modificar las plantillas e insertar flash / javascript directamente, no me convencerá.

Life on Mars? Amazing photos from Nasa probe reveal mystery figure on Red Planet

Personalmente, me impresionó más la cara.

La polémica se ha desatado de nuevo en torno al navegador de Microsoft, más concretamente el futuro Internet Explorer 8.

Con la versión 7 la compañía estadounidense daba un paso al frente y se situaba más cerca que nunca de los estándares web (hasta entonces mera utopía), aunque todavía muy lejos de sus rivales y competidores. Esto sin embargo trajo innumerables problemas a Microsoft, pues los clientes vieron cómo sus páginas dejaron de verse igual de bien que en la vetusta y peligrosa edición 6.

El caso es que en Redmond debieron recapacitar sobre lo ocurrido, y cuando ya nos estábamos frotando las manos al saber que IE8 superaba con éxito el AcidTest, toman una decisión más que polémica con la invención de una nueva y exclusiva etiqueta meta.

En el futuro, cuando este programa vea la luz, si el desarrollador quiere que IE8 se comporte como debiera (en modo estándar), tendrá que introducir dicha etiqueta especial en el encabezado de la página (de no hacerlo, por defecto se comportará como ese navegador nada estándar al que estamos acostumbrados).

Por un lado, parece la mejor decisión para que Internet Explorer visualice las webs correctamente en todos los casos, aunque las mismas se salten a la torera todas las normas establecidas (el sempiterno problema de Microsoft y la maldita compatibilidad). Por otro, es un trabajo extra para los desarrolladores, que tendrán que seguir tratando a IE de forma especial. ¿Qué pasaría si todos los navegadores se comportasen de igual forma? ¿Una etiqueta para cada uno?

En mi opinión, no es la mejor solución, pero sí la más sencilla y eficiente. Si con una simple línea nos podemos ahorrar multitud de dolores de cabeza, bendita sea. Ventaja: si IE8 cumple con los estándares, el diseño web se volverá mucho más sencillo. Desventaja: es un nuevo parche, y a veces es mejor comenzar de cero.