I'm Pixelated

Dos cosas,

1 - Verificación e-mail. Es increíble que todavía siga existiendo!

2 - Captchas

WTF?? Como suponen que vamos a adivinar ésto?!?!?

Para reducir los scripts JavaScript encargados de compatibilidad entre browsers, se puede hacer lo siguiente.

En lugar de poner el código para cada browser en cada página:

if (isFirefox()) {
// firefox related code...
} else if (isIE()) {
// internet explorer related code...
}

Podríamos verificar el browser una vez en la primer página que visite el usuario, donde se genere la sesión, y en la misma sesión guardar el browser, mediante XMLHttpRequest.

if (isFirefox()) {
// update session, set browser is firefox
} else if (isIE()) {
// update session, set browser is internet explorer
}

De ésta forma, cada vez que se necesite mandarle una página al usuario, se chequea en la sesión el tipo browser que se está utilizando, y se manda sólo el código Javascript+HTML que el usuario va a ejecutar en su máquina, ahorrando nuestro preciado ancho de banda, haciendo que la página cargue más rápido, y que el código también se ejecute mas rápidamente ya que nos estaríamos ahorrando de hacer los chequeos de browser.

Ésto es posible ya que la sesión se guarda por usuario, hasta que el usuario cierre su browser. Es decir, jamás un usuario va a poder cambiar de browser durante una sesión, porque al momento de hacerlo su sesión va a desaparecer.

¿Cuántas veces nos habrá pasado que para usar cierta aplicación Flash, nos saltó el cartel de “Se necesita descargar la última version de Adobe Flash Player para continuar”.
En cambio, con los websites, pasa todo lo contrario. Los desarrolladores quisieron mantener la retrocompatibilidad con navegadores antiquísimos como Internet Explorer 4 y Netscape Navigator (!!). Ésto acarrea un problema: el usuario, al no verse requerido a actualizar su navegador, continua usando su viejo amigo, probablemente arriesgándose a los bugs y agujeros de seguridad que pueda tener, al no haberlo actualizado.
Si bien en primera instancia yo me sumé a la movida de que una página se vea bien en todos lados, me bajé por la razón de que, con la futura llegada de CSS3, todos los navegadores viejos quedarán obsoletos. Si hay un grupo de gente trabajando duro para brindarnos el potencial de CSS3, entonces ¿Por qué tenemos que gastar nuestras neuronas pensando en cómo hacer para que una página se vea bien en un navegador viejo? Y aunque puedan opinar que incluyendo un Framework se soluciona la vida, ¿Vale la pena gastar varios kb de datos en algo así?
Creo que es el único lado donde la retrocompatibilidad todavía continúa, ya que generalmente se insta al usuario a descargar la última versión con parches de seguridad y mejor estabilidad. ¿Un usuario puede actualizar su máquina virtual Java, pero no puede actualizar su navegador?
Otro punto mas importante, es la inclusión de Javascript V8 en Chrome. Espero que la mayoría de los browsers considere realmente incluir éste engine en sus productos, así crecería la creatividad para desarrollar en Javascript. Pero claro, no se podría si todos continúan con sus piezas de antigüedad instaladas en sus computadoras. (Noticia de último momento: Opera incluiría en su próximo browser, un engine llamado Carakan, el cual realiza optimizaciones por bytecode y native code, algo misteriosamente similar a lo que hace Javascript V8)
Creo que es un deber de todos el terminar con la movida de que una web se vea linda en un navegador viejo. Y hay que empezar a poner links a las últimas versiones, en caso de que el usuario todavía no haya entrado en razón.
Creo que lo ULTIMO se consideraría Internet Explorer 7+, Mozilla Firefox 3+, Opera 9+ (no lo uso, así que alguien me corrija si me equivoco) y para las demás plataformas, no tengo idea. Igualmente, para testeo siempre utilizo éstos tres productos, además de mi querido Lynx. Si se ve bien en Lynx, cumple su objetivo.

Muy obvio, pero muy eficiente.
A la hora de sumar una variable $count dentro de un while, php nos tiraria un error diciendo que la variable no está definida. Un error muy cierto. Si bien podemos desactivar esa clase de errores usando error_reporting(); yo prefiero utilizar lo siguiente.

<php
while(1) {
   @$count++;
}
?>

Como se sabe, la arroba (@) desactiva el error trigger para la instrucción en la que se lo utilice. Así, nos libramos de errores que a la hora de debuguear nos pueden asustar a simple vista ;)

Soy un n00b.
Parse error: parse error, unexpected T_STRING, expecting ',' or ';' in C:\My\Path\To\Work\fp.image.php(110) : runtime-created function on line 1

UPDATE `matches` SET `date` = ADDDATE(now(), INTERVAL 5 DAY)

En un script PHP, el tiempo de ejecución era de 5 segundos promedio.
Comiéndome el coco pensando en qué podía ser, cierro el µTorrent y vuelve a sus feos 0.04 segundos. Es lógico que mi script sea lento, pero no para tardar 5 segundos!

La verdad que creí que los Stored Procedures de MySQL eran muy distintos. Y no me llevo para nada bien con la documentación de éste motor de base de datos.
Tengo un PDF, escrito por Peter Gulutzan (un crack en su rubro), que dice que las funciones no pueden acceder a las tablas. Mientras que en la web oficial, se indica lo contrario.
Además de éso, el error de sintáxis de MySQL no es muy descriptivo que digamos, algo así como “Tenés un error por ahí, fijate en el manual”.
Los Stored Procedures no pueden devolver valor, entonces hay que usar los Stored Functions. Pero con éstos, tenía error al declarar los parametros! Pasa que no se pueden mandar otros valores mas que IN a las funciones. Pero claro, si indicas que es un IN, no le gusta, y te tira un error “por ahí”.
Nunca creí que se podía tardar tanto en hacer una simple función, tardé como 30 minutos sumado al tiempo que me llevó dar con las páginas correctas en Internet (hasta que mi ISP se dignó a funcionar, gracias Speedy!).
Definitivamente, no nací para SQL. Igualmente, acá está lo que me llevó tanto tiempo.

DROP FUNCTION IF EXISTS BuyPlayer$$
CREATE FUNCTION BuyPlayer
(team INTEGER,
player INTEGER)
RETURNS INTEGER
READS SQL DATA
BEGIN
UPDATE players SET tid=team WHERE id=player;
IF ROW_COUNT() = 0 THEN RETURN 0; END IF;
UPDATE teams SET wealth = (teams.wealth - (SELECT worth FROM players WHERE id=player)) WHERE id=team;
RETURN (ROW_COUNT() 0);
END$$

Hoy por primera vez instale una Wiki. Resultó mucho más fácil de lo que creia, y realmente esta muy bueno para los diseños de los videojuegos. Creo que es útil por donde se lo mire, y se pueden aprender algunas cosas editando y creando artículos.