Muchas personas no conocen Mootools y, como generalmente ven más sitios o ejemplos hechos en jQuery creen que “es mejor”, pero a mi juicio Mootools es mucho mejor que jQuery. De hecho, NUNCA he visto algo que se pueda hacer en jQuery y que no se pueda hacer en Mootools (por favor si alguien sabe de algo que lo publique acá), y en teoría no tendría porqué jQuery ser mejor que Mootools en ese sentido si ambos están basados únicamente en lo que permite hacer javascript.

El gran plus de jQuery: su documentación

Me he encontrado que cuando quiero buscar algo relacionado a jQuery me es bastante fácil encontrar una solución o ejemplos, a diferencia de Mootools, que su documentación es bastante pobre (sólo lo justo y necesario). Además de eso, mootools tiene unos ejemplos online muy antiguos (de la versión 1.1) y para las últimas versiones ofrecen descargar los ejemplos o revisar su funcionalidad en una interfaz llamada jsFiddle, en la cual también se encuentran ejemplos de las demás librerías como YUI o prototype.

Por su parte jQuery ofrece cosas mucho más simples como jQueryUI o su listado de plugins, los cuales ofrecen ejemplos bastante claros, concretos y simples. Quizás por eso es tan popular jQuery, porque es mucho más fácil encontrar una librería que se ajuste a las necesidades de algún proyecto, la cual puedes implementar incluso con poco conocimiento. De todas formas Mootools no se queda atrás y ofrece Mootools Forge (que en la práctica es un repositorio de plugins) y existen sitios como JOURMOLY que tiene muchos ejemplos realmente útilies y que le “salvan el pellejo”.

El gran plus de Mootools: su funcionalidad

Vamos directo con un ejemplo: cuando tengo un link y quiero que al hacer click haga submit a un formulario simplemente pongo lo siguiente en mootools:

$('id_del_formulario').submit();

En jQuery esto no funciona. Es algo complejo de explicarselo a humanos (yo no soy programador de profesión asique tampoco me gusta explicar las cosas como programador), pero en resumidas cuentas, mootools permite seleccionar un objeto con $ y eso al final es lo mismo que decir document.getElementById. En jQuery, al usar el $ el objeto se convierte en un objeto de jQuery y si quiero hacer un submit tengo que usar una función interna que trae jQuery para dichos efectos. Al ser un objeto de jQuery aparentemente no puede interactuar con todas las funciones básicas de javascript, y eso a la larga es confuso.

NOTA: puede ser que en las últimas versiones de jQuery esto ya no suceda. Me tocó hace tiempo hacer algo como esto y últimamente no me ha tocado desarrollar en jQuery, asique si estoy mal avísenme.

Lo importante es que Mootools es más flexible en ese sentido. Es bastante fácil de implementar y tiene métodos muy simples. Como es obvio, también, hay cosas que son más simples en jQuery, asique creo que en ese sentido es mejor que cada uno decida.

Mi opinión personal

Por mi parte recomiendo Mootools. Personalmente no me gusta jQuery (es como escoger entre WordPress o Joomla, entre los cuales prefiero WordPress), y encuentro que es un poco más engorroso de entender y programar.

Personalmente uso un archivo que pesa 213k pero que contiene TODO Mootools (ya que hay un Mootools “básico” y un “core” que tiene más funcionalidades) y con eso puedo hacer todo lo que quiera en cualquier sitio. Como los .js se cargan una sola vez y luego se toman del caché el impacto que esto produce es imperceptible y además de esa manera no se llama a n archivos (como sucede en jQuery, donde se carga la base y luego se van cargando librerías para efectos, desplegables, carruseles, etc.), sino que se carga sólo 1, lo cual optimiza bastante la carga de la página.

Con esto inicio el debate por si alguien se quiere sumar…

Por ejemplo, si hacemos una aplicacación que se conecte con twitter, vamos a recibir ciertos datos que vienen en una enorme cadena de texto, pero la pregunta es: ¿cuántos caracteres recibiremos?… si no sabemos le pondremos algo así como 255, y probablemente estemos ocupando espacio adicional en el base de datos.

Bueno… a mi me pasó eso… y voy a compartir la información que investigué y que deduje para que se les haga más fácil la tarea XD.

ID = 10 caracteres (hablando de ID’s numéricos con auto-increment y “unsigned”)
Email =256 caracteres (64 antes de la @, y un máximo de 256)
Passwords = 32 caracteres si se almacenan en formato MD5 (recomendado)
Nombres = 100 (generalmente con eso alcanza… sino se puede ocupar un varchar de 255 o un tinytext)
ID de Facebook =64 caracteres (pues cambiaron hace poco el largo de la cadena en vista de que tienen muchos registrados)
Twitter Oauth Token = 50 caracteres
Twitter Oauth Token Secret = 50 caracteres
Twitter Username = 15 caracteres
RUT (chileno) = 12 caracteres (si se almacena con puntos y guión) o 9 caracteres (si se almacena sin puntos ni guión, que es lo más óptimo)
URL = Se supone que no hay un largo máximo definido, sin embargo leí por ahí que IE6 acepta un máximo de 2047 caracteres si la escribo en el navegador… raro, pero en verdad no sabría que largo (maxlength) recomendar. De todas formas yo generalmente pongo 255 ó 500 caracteres… DUDO que alguien tenga un sitio web con más qu eso (los 2047 caracteres probablemente se apliquen a un post en un blog, pero no a la URL de un sitio personal).

BuenoHay muchos otros tipos de datos, y por supuesto que pueden preguntar en los comentarios o aportar si tienen otros datos.

Visítenlo en

http://www.tumensajeajapon.com

Mucha gente no sabe bien que hacer antes de partir con el desarrollo de un sitio Web. Tienen la idea de lo que quieren, pero una cosa es tener una idea y la otra es tenerlo CLARO.

Acá voy a intententar ayudar a definir lo básico que hay que pensar antes de comenzar con un sitio Web, en base a mi experiencia. Espero que les sirva…

Conceptos generales

Lo primero es plantearse objetivos y definir a quien estará enfocado el sitio. Con esto en mente, se podrá tomar desiciones a futuro dándole prioridades a los objetivos y sabiendo que cosas enfatizar cuando sea necesario.

• Objetivo principal del sitio (vender, mostrar la empresa, servir de intranet, generar una base de datos de clientes, etc.)
• Objetivos secundarios (lo mismo que el principal, pero con menos importancia)
• A quién está enfocado el sitio (tratar de caracterizar una personas. Inventarle un nombre ficticio incluso… algo así como “José Andrés. El vive en el barrio alto. Vive con su mamá y su papá y tiene 3 hermanas mujeres. Lee el diario los domingos y estudia Arquitectura en la Universidad XXXX. Cuando egrese va a manejar la empresa del padre, etc.”. Con eso se define el tipo de persona “ideal” a la que quiero apuntar y a futuro se podran tomar desiciones de marketing, comerciales y desiciones respecto al contenido del mismo sitio Web y la forma de comunicarse.
• Definir a los otros públicos que podrían visitar el sitio (la competencia, mis propios empleados, los extranjeros, etc.)
• El impacto que quiero producir sobre los distintos públicos (quiero que la competencia vea mi sitio y sienta envidia. Que los extranjeros vean que mi sitio es tan avanzado como el de ellos, quiero ganar premios en concursos de diseño, etc.)
• Conceptos generales del sitio (fácil uso, limpieza visual, tecnológico, harto movimiento, etc. Deberían ser los 2 ó 3 más importantes).
• Referencias (quiero que mi sitio sea como xxxxx. La idea es saber hacia donde tiene que apuntar el diseño y desarrollo).

Conceptos logísticos

El sitio tiene que ir acompañado por todo un contexto humano detrás:

• Quién será el encargado del desarrollo del sitio por parte de la empresa (tiene que haber una única persona que nos comunique las desiciones que se van a tomar. Si esa persona tiene que discutir con 20 personas detrás de ella, da lo mismo, pero lo importante es que haya un UNICO canal de comunicación entre la empresa que desarrolle y el cliente)
• Cada cuanto tiempo se actualizará el sitio (esto se debe hacer en base a la REALIDAD de la empresa. Si no hay una persona que pueda crear banners o textos y no se pretende contratar a alguien para ese trabajo, hay que saberlo de antemano para ver que desiciones tomar en los puntos siguientes)
• Quién va a administrar el sitio (cuanta gente, cantidad de experiencia en computación, etc.)
• ¿El sitio va a tener un administrador de contenidos o un equipo de trabajo detrás? (esto varía en relación a la complejidad de contenido que deberá ser administrado y lo que quieren que pase con el sitio. Al final esto es consecuencia de los puntos anteriores)
• ¿Se aceptará alguna forma de contacto con el sitio?. ¿Quién responderá esos correos de contacto?
• ¿Quién redactará los textos inciales del sitio?

¿Y si quiero hacer una tienda online?

Las tiendas online son un tema aparte, debido a su complejidad, y requieren pensar cosas adicionales como:

• Cuál será el beneficio de la tienda por sobre las demás formas de venta? (¿porqué la gente va a preferir comprar en esta tienda y no en una tienda física, donde pueda tocar y ver los productos?, ¿los productos que se ofrezcan tendrán precios más bajos que las tiendas físicas?, ¿el despacho será gratis?, etc.)
• ¿Con quién se van a realizar los despachos? (la empresa que se contrate tendrá la capacidad de aguantar la cantidad de carga y llegará a todas partes?, ¿los precios de esta empresa son razonables en base a los tipos de producto que se deban despachar?)
• ¿El costo de despacho va a estar cargado al público o corre por cuenta de la empresa?
• ¿Como se mantendrá actualizado el sistema de stock (manualmente, existe una base de datos de los productos, a través de un excel, etc.)
• ¿Existirá una bodega REAL para la tienda? (¿será una tienda más con su stock propio?)
• ¿Como será la ficha genérica para ingresar productos (debe ser una ficha que sirva para ingresar datos básicos y opcionales para TODOS los productos. Una única ficha que sirva para cualquier tipo de producto)
• ¿Existirán productos “madres” e “hijos”, o sólo productos? (¿cada producto “madre” tendrá variaciones de productos “hijos”?. Hay que ver si para el tipo de tienda eso es viable)

Creo que eso es lo escencial. El resto de las desiciones se toman en la etapa de planificación del sitio en base a los conceptos generales que se hayan definido para el sitio.

Acá les dejo una forma automática de hacerlo, en javascript, por supuesto:

var inputs=$$('#formulario_de_contacto .text','#formulario_de_contacto textarea');
for(i=0;i<inputs.length;i++){
	inputs[i].txtOriginal=inputs[i].value;
	inputs[i].onfocus=function(){
		if(this.value==this.txtOriginal){ this.value=""; }
	}
	inputs[i].onblur=function(){
		if(this.value==""){ this.value=this.txtOriginal; }
	}
}

No hay mucho que explicar de este código: primero selecciona todos los textarea y elementos con la clase “text” (que es la que yo uso para diferenciar los inputs type=”text” de los otros inputs) y luego a cada uno de esos elementos les lee el value original y lo guarda en una variable txtOriginal, para luego decirle que cuando se ponga el cursor sobre ellos revise si tienen el mismo texto que el original o si está vacío para hacer la acción correspondiente.

El código anterior utiliza mootools para optimizar la búsqueda de los inputs de texto y los textarea dentro del código. Si no saben como se utiliza mootools, vean este tutorial.

En GEEKBOX estuvimos haciendo las primeras pruebas de registro para el juego Brooks Brothers Mundial, y parte de este proceso correspondía a enviar correos a los usuarios que se registraban para poder validar sus cuentas. Estos correos se autogeneraban vía PHP y se enviaban con la típica funcion mail().

Resulta que extrañamente los correos dirigidos a cuentas de hotmail no llegaban (ni siquiera al spam), pues el sistema interno de hotmail los bloqueaba al ser generados por programación. La duda que le da a este servicio de correo (por la cual no quería aceptar los correos) era que éstos se enviaban desde una dirección IP xxx.xxx.xxx.xxx (la de los servidores del servicio de alojamiento), pero no era necesariamente la misma IP que la que utiliza el sitio en cuestión (que tiene una de las tantas direcciones IP de los servidores). Esto quiere decir que estos correos le producían “desconfianza” porque no sabía con certeza si eran enviados por terceros utilizando una dirección falsa o si eran enviados REALMENTE por el sitio. Asique, “ante la duda abstente” y ellos lo rechazan.

En resumidas cuentas no llegaban los correos y necesitaba una solución.

La solución!

Buscando y buscando logré entender como se tiene que hacer para que esto no ocurra: el concepto principal es asociarle a nuestro servidor un dato que defina cuales son las direcciones IP válidas para enviar correos “autorizados” por el sitio. Este “dato” es un “registro” (como los típicos registros A o CNAME) del tipo TXT que define los valores (IPs) para que los sistemas de correo (como Hotmail) puedan consultarle. Este “dato” es el llamado registro SPF o SPF record (Sender Policy Framework).

En resumidas cuentas, si Hotmail ve que le están enviando un correo desde la IP xxx.xxx.xxx.xxx diciendo que viene desde tusitio.com, se conectará tusitio.com y consultará si dentro de sus registros del tipo TXT hay alguno que tenga la información de los SPF. Si la encuntra, consultará cuales son las direcciones IP autorizadas desde las cuales el sitio enviará correos. Si todo está en orden (la IP desde donde se envía el correo calza con la autorizada por el servidor) recibirá el correo sin problemas; si no, lo rechazará y probablemente asumirá como que el correo nunca existió.

Un ejemplo de registro TXT que contiene esta información es el siguiente (para Dreamhost):

v=spf1 ip4:64.111.100.0/24 ip4:66.33.201.0/24 ip4:66.33.216.0/24 ip4:208.97.132.0/24
ip4:208.97.187.0/24 ip4:208.113.200.0/24 ip4:208.113.244.0/24 ip4:208.113.175.0/24 mx -all

Este dato se le asocia al servidor y listo. Luego de un rato todo debería funcionar normalmente.

Hay que tener en consideración que los SPF son independientes para cada subdominio. Es decir, que si los aplicas en tudominio.com, no van a ser considerados para tusubdominio.tudominio.com. Hotmail no los considera el mismo sitio (pues no lo son).

Para saber si tu servidor tiene asociado algún registro SPF puedes visitar este sitio de microsoft donde revisa los registros A, MX y SPF de tu servidor. Si encuentra algún SPF te lo muestra, sino, te muestra los registros MX para que puedas crear (con su wizard) los registros que necesitas.

The Geek Toolbox es un sitio Web que permite realizar tareas o acciones completamente “geek”, ya sea relacionada a tus sitios Web, o tareas simples como averiguar la hora UTC, cambiar tamaño a imágenes, o “jugar” a codificar y decodificar palabras.

De más está decir que es uno de mis proyectos, y por algo hago este post para explicar algunas de sus funciones poco comunes. Sitios como este hay muchos, pero ninguno tiene todas estas herramientas juntas, y además, multilenguaje.

Estas son algunas de las herramientas disponibles:

Días entre dos fechas: muy simple: ingresa la fecha de inicio (por ejemplo el día de tu nacimiento) y la fecha de término (por ejemplo hoy) y sabrás cuantos días hay entre esas dos fechas.

Generador de favicon: el favicon es el típico ícono que se ve al lado de la URL de algún sitio. Para generarlo solo basta con seleccionar una foto de tu computador y presionar el botón “crear”. Hay que considerar que el ícono que genera esta herramienta no es un simple gif o png, sino un icono en formato .ico, el cual es el formato OFICIAL para los favicon y es el formato que todos los servidores reconocen automáticamente. No te dejes engañar!… no aceptes imitaciones!

Calculadora de proporciones: esta herramienta es muy buena (si entiendes como se usa, claro está). ¿Alguna vez te ha pasado que tienes una imagen de 800 x 600, por ejemplo, y necesitas ponerla en un sitio Web de 500 x “xxx”?. Si no sabes cual es la proporción exacta, solo basta con que uses esta herramienta y voilá!: ingresas el tamaño original y luego el tamaño al que quieres dejar tu nueva imágen y esta herramienta te entrega el resultado. Nada de abrir photoshop y crear una foto de 800 x 600 y luego achicarla. Con la calcuradora de proporciones podrás ¡¡¡calcular proporciones!!! (WOW!!!). En fin. Esto se puede ocupar para embeber un video de youtube, por ejemplo y saber cual será el nuevo tamaño que le darás sin perder las proporciones.

¿Y que se espera para el futuro?

Pronto, se viene un “formateador de textos” (pasar un texto a minúsculas, “Dejarlo En Formato Título”, quitarle los acentos, reemplazar caracteres, etc.), una “calculadora de permisos UNIX” (los famosos CHMOD), y algunas otras sorpresas.

¿Tienes alguna idea más para incluir?… todo aporte es bienvenido!

Para quienes no estén muy familiarizados con todos los conceptos, les describo algunos poco comunes:

Canonicalización: escoger la mejor URL para mostrar una página (o nuestro sitio web).
Googlebot: es el “robot” de Google, que lee nuestras páginas web para agregarlas a su base de datos.

Vía Ayuda WordPress

Un ejemplo claro de esto lo podemos ver en la frase “el perro ladró”, que claramente significa que “el animal del tipo perro ha realizado el acto de ladrar”, y sea donde sea que mencione eso significará lo mismo. La metainformación entonces está presente en COMO y CUANDO digo esta frase, es decir, en el contexto en que se presenta. Por ejemplo:

• Si deseamos saber quién fue el que despertó al bebé con un sonido de ladrido, puedo decir “EL PERRO ladró”, para “acusarlo” de que él fue quién lo hizo.
• Si el perro es muy pequeño y nunca en su vida había ladrado, y hoy por primera vez lo hizo, puedo decir “el perro ladró!!!” para expresar la emoción del momento.
• Si el perro ladra porque quiere avisarnos algo, podemos decirle a alguien “el perro ladró”, así como contándole que vaya a ver que quiere el perro, pues acaba de ladrar.

Ahí tenemos tres ejemplos distintos de la misma frase, que significa lo mismo, pero que dependiendo del contexto donde se menciona se refiere a distintas cosas. Eso es “metainformación”, pues el contexto me entrega información adicional a la que se ve a simple vista. Lo mismo pasa con las expresiones corporales, por ejemplo, pues una levantada de cejas o una entonación distinta puede variar notoriamente una frase.

Ahora… como aplicamos esto a la Web?

Los sitios Web siempre intentan comunicar algo, y generalmente esta comunicación debe ser transmitida a través de imágenes o palabras. En ambos casos es muy importante escoger bien la manera de comunicarse, porque cada frase o imagen tiene algo de metainformación implícita.

Un ejemplo claro es si quiero hacer un sitio para participar en algo y ganar un premio. Hay que ser muy cuidadoso porque dependiendo de la frase que escoja y la manera de comunicarme con las personas voy a conseguir distintas cosas. Lo que tengo que hacer es invitarlos a participar, pero es muy distinto decir “juega con nosotros” que “participa con nosotros”, aunque en la práctica quiero expresar el mismo concepto. “Juega” es mucho más “diversión”, podría decirse incluso que “para niños”. En cambio “participar” es algo mucho más formal y sobrio. Es algo muy sutil, pero que va a decir mucho de nosotros .

Una foto en blanco y negro y una a color pueden contener exactamente lo mismo, pero por el solo hecho de ser en blanco y negro ya me está diciendo otras cosas que la que a color no hace: habla de arte, talvez de antiguedad, de recuerdos, etc.; al igual que una foto en color sepia me habla de melancolía, desgaste o algún otro concepto similar.

Otro ejemplo está en el código fuente. Yo puedo armar dos sitios que se vean iguales en cualquier navegador, y si veo el código fuente de ambas páginas es igual. Sin embargo lo que los diferencia es que un código está perfectamente ordenado y tabulado y el otro no. Técnicamente ambos dicen lo mismo y cumplen la misma función, pero el código ordenado me va a transmitir que la persona que hizo el sitio hace las cosas bien. El que no es ordenado me va a decir que la persona es desordenada. Tal vez incluso crea que se demoró más en lograr el mismo trabajo porque me da la impresión que no tiene claro lo que hace.

La metainformación es algo de lo que hay que preocuparse mucho, aunque no se vea en una primera mirada.

Hay veces en que llamo a una función pero en la página donde estoy no he cargado el archivo .js correspondiente y por lo tanto el navegador me tira un error. ¿Cómo solucionarlo?: fácil (siempre digo lo mismo). Tenemos que agregar al final del archivo js una variable cualquiera:

var archivoCargado=1;

Y luego, antes de llamar a la funcion que necesitamos le preguntamos si esa variable existe (sin que nos arroje un error). Si la variable existe es porque se cargó el archivo, y si no existe será “undefined“, osea que no ha sido definida, osea que el archivo no se cargó. Algo así:

if(typeof(archivoCargado)!="undefined"){ ejecutarFuncion(); }

…dudas?