Arragonán

Hace un tiempo, estuve un par de días jugando un poco con el api de google maps y el de twitter, más que nada por la excusa del google maps, la de twitter es muy sencilla (bueno, twitter en sí lo es). El resultado es TuiterMaps.

Es algo parecido a twittermap, puedes ver de dónde son las personas que escriben, siempre que tegan puesto en su perfil el location.
En un principio muestra los mensajes del public timeline, también se puede seleccionar un usario en concreto y un usuario con sus amigos.

Es muy chorras, pero ya he visto lo fácil que es mostrar una localización gracias a la clase GClientGeocoder, simplemente le pasas al método getLatLng una cadena de la localización y una función callback que recibe un obeto GLatLng, y a partir de ahí puedes crear un GMarker para añadir al mapa.

Lo que le falta es un poco de diseño, pero para eso yo soy muy malo.

A mi personalmente nunca me ha gustado, como usuario, que la navegación dependa de las recargas del objeto XMLHTTPRequest, más que nada por los problemas del botón de actualizar o atrás de los navegadores, por lo que no lo veo sólo como un problema de accesibilidad, de usabilidad también.

Como desarrollador, tampoco me gusta hacer el doble de trabajo para cumplir con la accesibilidad, y eso si no hay que hacer modificaciones con el desarrollo acabado, cosa que NUNCA se cumple o yo no he tenido esa suerte.

Por esto recomiendo un post muy interesante sobre este tema, AJAX accesible en el blog de Olga Carreras, del que me ha llamado la atención que la etiqueta noscript desaparecerá en el estándar XHTML 2.0, por lo que abrá que tomarse más en serio el uso de javascript no intrusivo y empezar a olvidarnos de usar los eventos del html.

Actualmente estoy participando en el desarrollo de una aplicación web con un altísimo uso de javascript (AJAX y DHTML),
y hay tres plugins de Firefox que me están ayudando muchísimo:

Web Developer: Lo uso para deshabilitar las css, ver los detalles de los formularios, pasar las validaciones al HTML…

Firebug: Debugger para javascript,puede ahorrate hacer muchos alerts para ver qué está pasando.

View Source Chart: Este plugin es menos conocido que los anteriores, pero yo es el que más estoy utilizando. Muestra el código fuente de la página, incluido el generado dinámicamente por AJAX o DHTML, para mi este plugin ha sido una bendición.
Otros plugins que no utilizo pero que pueden ser útiles:

IE Tab: Para utilizar en Firefox el motor de IExplorer

Selenium IDE: Para baterías de test de selenium, este espero utilizarlo pronto.

Si necesitas algún otro plugin, tienes un listado completo de herramientas web y de desarrollo para Firefox.

Estos últimos días, me he estado peleando con la librería yui, de yahoo (y me va a tocar seguir una temporada) para usar los componentes que trae de serie.

Estaba trabajando con la versión 0.11.1, el caso es que necesitaba que el componente calendar mostrara un botón para cerrarse, y siguiendo la documentación, sólo conseguía que me dieran errores de javascript.

Después de mucho trastear, hoy al final, me he dado cuenta que no estaba utilizando la última versión (la 0.12.2). Al ver esto, me he dado cuenta que lo más probable es que fuera este el problema.

Me he descargado la última versión, he reescrito algunos pequeños cambios que le hice al componente del calendario y cuando, siguiendo la documentación, he conseguido que mostrara el botón… no ejecutaba el método (o función, que no sé cómo llamar esa pseudo POO con javascript) que anteriormente cargaba la configuración personalizada del componente (customConfig), y me aparecía el calendario en inglés.

He tenido que utilizar el calendarioYahoo.cfg.setProperty(), pruebo otra vez… y nada, finalmente esto era porque antes de renderizar el componente hacía una llamada al setupConfig (que este a su vez, anteriormente, hacía la llamada a customConfig), y al parecer me machacaba la personalización. Al quitar esta llamada todo “perfecto”, al menos hasta la próxima.

Con esta librería se me está quedando grabado algo, que ya he leído muchas veces… NUNCA UTILIZAR VERSIONES ANTERIORES A 1.0, que luego te puedes llevar los disgustos.

Bueno es viernes y me tenía que desahogar antes del fin de semana:P.

Me he encontrado una curiosidad, montando una función que recuperara el html dentro de un td.

La curiosidad en cuestion es childNodes, me esperaba que este método, recuperara sólo los nodos html hijos y, si existe, los nodos de texto.

Pero me he encontrado con que, en firefox, recupera también los saltos de línea tal y cómo explican en dhtmlya más detalladamente.

Este es el código javascript:


tr=document.getElementById(idTr);
td=tr.childNodes[0];
return td.innerHTML;


Para que funcionara correctamente, como simplemente busco el html que contienen los

, lo he modificado así:
tr=document.getElementById(idTr);
tds=tr.getElementsByTagName("td");
td=tds[0];
return td.innerHTML;


Que es la forma que debería haber utilizado desde un principio, pero así nunca hubiera conocido la curiosidad del childNodes

Vía el blog de Javier Gutiérrez (Guti), he encontrado un test de rendimiento de Javascript para navegadores.

Lo he probado con Firefox 1.5 y Iexplorer 6.0, y estos han sido los resultados que me ha dado al pasar el test:


Firefox:

Try/Catch with errors 188
Layer movement 296
Random number engine 282
Math engine 328
DOM speed 266
Array functions 156
String functions 78
Ajax declaration 204
Total Duration 1798ms

Iexplorer:

Try/Catch with errors 47
Layer movement 500
Random number engine 78
Math engine 172
DOM speed 391
Array functions 31
String functions 31
Ajax declaration 344
Total Duration 1594ms

En este test, Explorer gana por bastante diferencia en todas las pruebas excepto en el Layer movement, pero al parecer en este test Opera les gana con mucha diferencia como podéis ver en la misma web del test, sería interesante conocer datos de otros como Safari o Konqueror.

Actualización 24/08/2006:

Konqueror 3.5.2: (Sobre Kubuntu)

Try/Catch with errors 37
Layer movement 295
Random number engine 383
Math engine 447
DOM speed 116
Array functions 92
String functions 62
Ajax declaration 225
Total Duration 1657ms

Curioso el Konqueror… esto es en la primera ejecución pero si lo vuelves a ejecutar varias veces, a ratos bajan los tiempos muchísimo (unos 700ms en total).


Otra ejecución con Konqueror:

Try/Catch with errors 17
Layer movement 127
Random number engine 163
Math engine 191
DOM speed 50
Array functions 39
String functions 27
Ajax declaration 98
Total Duration 712ms

Hace unos días me descargué de AdictosAlTrabajo un tutorial para empezar a cacharrear google maps.

El ejemplo es muy sencillo ya que los tutoriales que publican suelen ser para iniciarse.

Lo he trasteado muy por encima, pero lo que me ha quedado claro es que puede tener muchísimas aplicaciones.

Para empezar os sitúo dónde está mi pueblo.

Como siempre, el problema con javascript es (además de hacer un código mantenible) es la compatibilidad con los navegadores, y eso que sólo pruebo el javascript que escribo con firefox y explorer, siempre utilizo firefox por la consola javascript y el plugin WebDeveloper, y luego vienen los problemas.

Algunos problemas con los que me he encontrado han sido trabajando con el DOM de javascript, siempre (qué casualidad) con explorer, por ejemplo si quisieramos cambiar el class de una etiqueta, que me dió un pequeño dolor de cabeza hasta que buscando por internet ví que explorer no lo soportaba:

midiv=document.getElementById(...midiv...);

//Con DOM simplemente sería un cambio en el atributo class

midiv.setAttribute(...class...,...miclass...);

Probamos con fiefox y…¦ ¡funciona! Ahora explorer y…¦ vemos que no.

La solución es utilizar el className:

midiv.className= ...œmiclass...;

Otro problema, pero menos por que está muy documentado enmuchísimas webs, es la creación del objeto XMLHttpRequest, para asegurarte la compatibilidad entre explorer y otros de los navegadores más utilizados esta es una posible solución:

ids=["Msxml2.XMLHTTP.5.0","Msxml2.XMLHTTP.4.0","Msxml2.XMLHTTP.3.0","Msxml2.XMLHTTP","Microsoft.XMLHTTP"];
for(var cont=0; !xmlhttp && ids.lengh>cont;cont++)
try {
xmlhttp = new ActiveXObject(ids[cont]);
}
catch(ex) {
xmlhttp = false; }
}
if (!xmlhttp && typeof XMLHttpRequest!="undefined") {
xmlhttp = new XMLHttpRequest();
}

Este es un ejemplo de los muchos problemas que nos da el dichoso explorer, que no soporta como debería el DOM y no daría tanto miedo el tocar AJAX en cuanto a compatibilidad entre navegadores.

Por ahora la solución que he encontrado es visitar el msdn de microsoft, para ver qué puedo hacer y qué no, ya que pocas veces me ha ocurrido el caso contrario.