Mostrando entradas con la etiqueta explorer. Mostrar todas las entradas
Mostrando entradas con la etiqueta explorer. Mostrar todas las entradas

miércoles, febrero 16, 2011

Google facilita la visualización de datos

Google ha hecho publica su herramienta "Public Data Explorer" para los datos que los usuarios se animen a compartir. Public Data Explorer permite visualizar de forma dinámica y variada cualquiera de los 27 grupos de datos (datasets) disponibles actualmente (y en crecimiento) que van desde: productividad del trabajo (OECD), velocidad de Internet (Ookla), niveles de endeudamiento del gobierno de USA (IMF) hasta estadísticas de densidad de población por municipalidad de Cataluña, etc.



Google Flu Trends (Mexico)


Pero lo interesante es que además de explorar los datasets disponibles, Google ha puesto a disposición de todos el "Dataset Publishing Language" (DSPL) que provee una interfaz para que cualquier usuario utilice el Public Data Explorer con datos propios. Por ejemplo, un Gobierno puede usar este servicio para visualizar datos de la población, indices de crecimiento, crímenes (homicidios), incendios, etc.
También me imagino a una empresa de telefonía móvil, que ponga los datos de activación de teléfonos por minuto, en el transcurso de un año, en una visualización a nivel centroamericano... eso si que sería genial.

Ahora bien Google no es el la primera o única compañía que esta en el negocio de visualizar datos. Otros competidores incluyen: Amazon’s Public Data Sets, CKAN, Factual e InfoChimps.

Para mas información sobre el Public Data Explorer, pueden ver la siguiente presentación:




... y claro, pueden visitar el sitio web:
http://www.google.com/publicdata/home

miércoles, enero 13, 2010

Monitorea los Ajax HttpRequests con Fiddler

Como programador de sitios web basados en Ajax, tiendo a necesitar una herramienta que me permita verificar exactamente que le envió al server en un XmlHttpRequest vía Ajax. Los parámetros que van en el request, la URL a la que lo envió, la respuesta recibida etc. Así puedo determinar si un error se genero porque se enviaron datos erróneos al server desde el Ajax Request o si fue el server quien interpreto o proceso mal los datos.

Mi herramienta para realizar estos monitoreos fue Firebug, un add-on para Firefox que te permite depurar Javascript, inspeccionar/manipular el DOM y también inspeccionar/manipular los estilos de un sitio. Este además visualiza en su consola los diferentes HttpRequests que se hacen al server.

Como muchos sabrán, no siempre basta con realizar pruebas y depuraciones de tu sitio usando el browser Firefox ya que comúnmente los errores ser producen al navegar en tu sitio desde Internet Explorer o algún otro y como hasta donde he podido investigar, ningún otro navegador cuenta con un add-on como el de Firefox para visualizar estas peticiones de Ajax, no hay otra manera de hacerlo mas que con una herramienta externa al browser.

Buscando en la web encontré la herramienta llamada Fiddler. Este es un proxy web hecho con el framework Microsoft.Net para captura y depuración del trafico http que se genera en tu computadora. Este trafico es comúnmente generado por los browsers al navegar dentro de sitios web, dar click sobre algun hipervinculo de alguna pagina o cuando un evento javascript dispara un request XmlHttp.

"Captura de pantalla de Fiddler, monitoreando el trafico http local. Visualizando en la parte derecha el detalle de un Ajax Request de la pagina de twitter.com"

Como pueden ver en la captura de pantalla, Fiddler estomáticamente captura todos los requests http y los lista en la columna de la izquierda, mostrando los detalles de cada request en la columna de la izquierda, como por ejemplo los headers de la petición, parámetros y la respuesta obtenida.

Hay un pequeño problema con Fiddler cuando intentas monitorear el trafico de un server alojado en tu localhost. Esto es porque, como ellos mismos mencionan en su sitio: "Internet Explorer and the .NET Framework are hardcoded not to send requests for Localhost through any proxies" por lo cual, nos vemos en la necesidad de no utilizar la palabra "localhost" ni su IP equivalente 127.0.0.1 para acceder desde nuestro browser a los sitios alojados en nuestro server. Como alternativa podemos usar en su lugar, el nombre de nuestro equipo. Por ejemplo:

en lugar de:
http://localhost:8080/miSitioWeb/index.jsp

tenemos que escribir:
http://laptux:8080/miSitioWeb/index.jsp

Asumiendo que el nombre de mi equipo es "laptux".

Monitorea los Ajax HttpRequests con Fiddler

Como programador de sitios web basados en Ajax, tiendo a necesitar una herramienta que me permita verificar exactamente que le envió al server en un XmlHttpRequest vía Ajax. Los parámetros que van en el request, la URL a la que lo envió, la respuesta recibida etc. Así puedo determinar si un error se genero porque se enviaron datos erróneos al server desde el Ajax Request o si fue el server quien interpreto o proceso mal los datos.

Mi herramienta para realizar estos monitoreos fue Firebug, un add-on para Firefox que te permite depurar Javascript, inspeccionar/manipular el DOM y también inspeccionar/manipular los estilos de un sitio. Este además visualiza en su consola los diferentes HttpRequests que se hacen al server.

Como muchos sabrán, no siempre basta con realizar pruebas y depuraciones de tu sitio usando el browser Firefox ya que comúnmente los errores ser producen al navegar en tu sitio desde Internet Explorer o algún otro y como hasta donde he podido investigar, ningún otro navegador cuenta con un add-on como el de Firefox para visualizar estas peticiones de Ajax, no hay otra manera de hacerlo mas que con una herramienta externa al browser.

Buscando en la web encontré la herramienta llamada Fiddler. Este es un proxy web hecho con el framework Microsoft.Net para captura y depuración del trafico http que se genera en tu computadora. Este trafico es comúnmente generado por los browsers al navegar dentro de sitios web, dar click sobre algun hipervinculo de alguna pagina o cuando un evento javascript dispara un request XmlHttp.

"Captura de pantalla de Fiddler, monitoreando el trafico http local. Visualizando en la parte derecha el detalle de un Ajax Request de la pagina de twitter.com"

Como pueden ver en la captura de pantalla, Fiddler estomáticamente captura todos los requests http y los lista en la columna de la izquierda, mostrando los detalles de cada request en la columna de la izquierda, como por ejemplo los headers de la petición, parámetros y la respuesta obtenida.

Hay un pequeño problema con Fiddler cuando intentas monitorear el trafico de un server alojado en tu localhost. Esto es porque, como ellos mismos mencionan en su sitio: "Internet Explorer and the .NET Framework are hardcoded not to send requests for Localhost through any proxies" por lo cual, nos vemos en la necesidad de no utilizar la palabra "localhost" ni su IP equivalente 127.0.0.1 para acceder desde nuestro browser a los sitios alojados en nuestro server. Como alternativa podemos usar en su lugar, el nombre de nuestro equipo. Por ejemplo:

en lugar de:
http://localhost:8080/miSitioWeb/index.jsp

tenemos que escribir:
http://laptux:8080/miSitioWeb/index.jsp

Asumiendo que el nombre de mi equipo es "laptux".

miércoles, junio 10, 2009

Tu Sitio, Compatible en Todos los Browsers!

"Logotipos de los navegadores mas populares del mercado: Firefox, Internet Explorer, Safari, Opera y Chrome"


Todo diseñador-desarrollador web ha tenido que lidiar mas de alguna vez con el HTML, el CSS, el Javascript o el DOM de las páginas web, para retocar detalles de apariencia o el funcionamiento del lado del cliente. Aún bloggers con pocos conocimientos de desarrollo web se han aventurado a modificar el CSS de sus blogs para adaptar las plantillas a sus necesidades personales. Los que han pasado estas experiencias también sabrán lo molesto que es tener que comprobar que tus modificaciones se ven y funcionan igual en todos los browsers desde los cuales tus clientes-usuarios-lectores te visitan.

Porque sucede esto? Sucede porque no todos los navegadores web cumplen a cabalidad con los estándares definidos para el web. Además cada navegador quiere sobresalir implementando sus propios estándares para poder hacer más cosas que las demas. Ejemplo de ello son las propiedades CSS que inician con el prefijo -moz- o -webkit-

"Prueba del Acid3. Asi es como deberias ver esta imagen al visitar este sitio si es que tu browser cumple con los estándares aca impelemtados."

Para estar seguro que tu sitio se ve bien en cualquier navegador, sugiero estas tres alternativas:

  • Usa Frameworks que te Aseguren la Independencia del Navegador

    En la web estan disponibles una serie de frameworks para el manejo del layout del sitio usando CSS, el acceso al DOM via Javascript, controles capaces de mostrar datos de un server via Ajax, etc. los cuales prometen verse y funcionar de la misma manera en cualquier browser. Esta es mi recomendacion por defecto, ya que te ahorras tiempo y dolores de cabeza teniendo que arreglar ese div que se sale de lugar o esos mensajes Ajax que no llegan al server.

    Entre los frameworks para usar layouts prefabricados de CSS se encuentran:


    Entre los frameworks para el manejo de Javascript, controles HTML avanzados y el manejo del DOM se encuentran:

"Página de prueba de la alineación y apariencia de los elementos de un formulario, usando Blueprints"



  • Usa Herramientas para Probar tu Sitio en Multiples Navegadores/Arquitecturas

    En esta opción caes cuando prefieres hacerlo todo al estilo "do it yourself" o si en tu trabajo no te permiten usar nuevas librerías o frameworks sin la autorización de tus superiores. Puedes hacer uso de servicios en línea como Browsershots y Adobe BrowserLabs para obtener vistas previas de tus sitios web en diferentes navegadores y sistemas operativos. En un antiguo post mencioné algunas herramientas para depurar CSS y javascript en Internet Explorer y Firefox de manera que puedan mover elementos HTML, cambiar propiedades CSS, examinar variables Javascript, entre otras cosas, directamente en el navegador, por lo que se puede conocer a ciencia cierta el resultado final sin usar diseñadores visuales como Dreamweaver.


  • Crea una Versión Diferente de tu Sitio por cada Navegador/Arquitectura

    Esta opción es el último recurso que debes tomar, la opción también llamada "Por si todo lo demás falla...". Una de las diferencias más molestas entre los navegadores es que no manejan las mismas medidas para los pixels y no renderizan del mismo tamaño las fuentes o tipografías. Esto da lugar a que un div de 30px de ancho abarque más espacio en IE que en Firefox u Opera. Para ello, una técnica es utilizar un CSS cargado únicamente cuando el navegador del cliente es Internet Explorer, utilizando la etiqueta < link > dentro de una etiqueta especial propia de IE, llamada < ! --[IF IE ]-- >

    Mediante esta etiqueta podrán cargar un archivo .css preparado para Firefox u otro .css preparado para IE, decidiendo dinámicamente cual cargar según el navegador que esté usando el cliente.

    Otra buena razón para crear una página con un layout diferente es el hecho de poder adaptar tu sitio para ser visto desde dispositivos móviles como smartphones, en los cuales el tamaño y resolución de la pantalla difieren en gran medida de una PC, sin mencionar que la navegación se realiza por medio de la pantalla táctil, prescindiendo del uso de un ratón. Buen ejemplo de ello son las páginas web para móviles de Google, Twitter y Facebook.
"Versión mobil de Twitter, visualizada desde un Nokia n95"

Debido a estas diferencias entre los navegadores, existen muchos sitios que solo son capaces de funcionar o lucir bien en uno u otro navegador, de manera que cuando lo visualizas en cualquier otro el sitio es un completo desastre, como los listados en este sitio.

Conoces algun sitio importante que se solamente se vea bien en uno u otro navegador?

Tu Sitio, Compatible en Todos los Browsers!

"Logotipos de los navegadores mas populares del mercado: Firefox, Internet Explorer, Safari, Opera y Chrome"


Todo diseñador-desarrollador web ha tenido que lidiar mas de alguna vez con el HTML, el CSS, el Javascript o el DOM de las páginas web, para retocar detalles de apariencia o el funcionamiento del lado del cliente. Aún bloggers con pocos conocimientos de desarrollo web se han aventurado a modificar el CSS de sus blogs para adaptar las plantillas a sus necesidades personales. Los que han pasado estas experiencias también sabrán lo molesto que es tener que comprobar que tus modificaciones se ven y funcionan igual en todos los browsers desde los cuales tus clientes-usuarios-lectores te visitan.

Porque sucede esto? Sucede porque no todos los navegadores web cumplen a cabalidad con los estándares definidos para el web. Además cada navegador quiere sobresalir implementando sus propios estándares para poder hacer más cosas que las demas. Ejemplo de ello son las propiedades CSS que inician con el prefijo -moz- o -webkit-

"Prueba del Acid3. Asi es como deberias ver esta imagen al visitar este sitio si es que tu browser cumple con los estándares aca impelemtados."

Para estar seguro que tu sitio se ve bien en cualquier navegador, sugiero estas tres alternativas:

  • Usa Frameworks que te Aseguren la Independencia del Navegador

    En la web estan disponibles una serie de frameworks para el manejo del layout del sitio usando CSS, el acceso al DOM via Javascript, controles capaces de mostrar datos de un server via Ajax, etc. los cuales prometen verse y funcionar de la misma manera en cualquier browser. Esta es mi recomendacion por defecto, ya que te ahorras tiempo y dolores de cabeza teniendo que arreglar ese div que se sale de lugar o esos mensajes Ajax que no llegan al server.

    Entre los frameworks para usar layouts prefabricados de CSS se encuentran:


    Entre los frameworks para el manejo de Javascript, controles HTML avanzados y el manejo del DOM se encuentran:

"Página de prueba de la alineación y apariencia de los elementos de un formulario, usando Blueprints"



  • Usa Herramientas para Probar tu Sitio en Multiples Navegadores/Arquitecturas

    En esta opción caes cuando prefieres hacerlo todo al estilo "do it yourself" o si en tu trabajo no te permiten usar nuevas librerías o frameworks sin la autorización de tus superiores. Puedes hacer uso de servicios en línea como Browsershots y Adobe BrowserLabs para obtener vistas previas de tus sitios web en diferentes navegadores y sistemas operativos. En un antiguo post mencioné algunas herramientas para depurar CSS y javascript en Internet Explorer y Firefox de manera que puedan mover elementos HTML, cambiar propiedades CSS, examinar variables Javascript, entre otras cosas, directamente en el navegador, por lo que se puede conocer a ciencia cierta el resultado final sin usar diseñadores visuales como Dreamweaver.


  • Crea una Versión Diferente de tu Sitio por cada Navegador/Arquitectura

    Esta opción es el último recurso que debes tomar, la opción también llamada "Por si todo lo demás falla...". Una de las diferencias más molestas entre los navegadores es que no manejan las mismas medidas para los pixels y no renderizan del mismo tamaño las fuentes o tipografías. Esto da lugar a que un div de 30px de ancho abarque más espacio en IE que en Firefox u Opera. Para ello, una técnica es utilizar un CSS cargado únicamente cuando el navegador del cliente es Internet Explorer, utilizando la etiqueta < link > dentro de una etiqueta especial propia de IE, llamada < ! --[IF IE ]-- >

    Mediante esta etiqueta podrán cargar un archivo .css preparado para Firefox u otro .css preparado para IE, decidiendo dinámicamente cual cargar según el navegador que esté usando el cliente.

    Otra buena razón para crear una página con un layout diferente es el hecho de poder adaptar tu sitio para ser visto desde dispositivos móviles como smartphones, en los cuales el tamaño y resolución de la pantalla difieren en gran medida de una PC, sin mencionar que la navegación se realiza por medio de la pantalla táctil, prescindiendo del uso de un ratón. Buen ejemplo de ello son las páginas web para móviles de Google, Twitter y Facebook.
"Versión mobil de Twitter, visualizada desde un Nokia n95"

Debido a estas diferencias entre los navegadores, existen muchos sitios que solo son capaces de funcionar o lucir bien en uno u otro navegador, de manera que cuando lo visualizas en cualquier otro el sitio es un completo desastre, como los listados en este sitio.

Conoces algun sitio importante que se solamente se vea bien en uno u otro navegador?

Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...