Hoy en el Twitter de Tomás Rufino he visto un gracioso gadget, bastante estúpido por otra parte, pero que me ha hecho mucha gracia: el Gadget SEO Serp definitivo.
Estúpido, ¿verdad? Así seguro que puedo posicionar en Google lo que quiera…
A veces publicar cosas en nuestros blogs se nos hace costoso: localizar fotografías no propias que podamos publicar sin problemas legales y sin violar la voluntad de su autor. Recuerdo docenas de veces en las que he tenido que revisar las galerías fotográficas de Wikipedia, donde casi todo aparece con licencias Creative Commons, y buscarme la vida para localizar esa foto que coincida, al menos parcialmente, con lo que yo personalmente necesito.
Pues bien, Google ha añadido, al fin, un campo de filtrado en su buscador de imagenes para poder realizar una criba de resultados por tipo de licencia aportada por su autor, como podés ver en este listado de fotografías de Madrid que pueden ser usadas y modificadas libremente, autorizados por su autor.
La verdad es que esto nos puede facilitar mucho la vida… ¡Adelante!
Hoy estoy probando las nuevas funcionalidades que Google ha ido introduciendo en el terreno de Geo, y como siempre, Google Maps es el lugar ideal donde verlo, ya que suelen (suelen, porque no siempre es así) añadir allí todo antes de que pueda usarse en cualquier otro producto de Google.
De momento, han añadido un pequeño botón que nos permite ubicar nuestra posición actual. Presupongo que lo hace por geolocalización de IP, sobretodo porque falla bastante: desde un equipo fijo conectado a una red local me situa medianamente bien, en Madrid, pero por 3G o WiFi me pone, o bien en medio de la sierra, o cerca de Tarancón… Incluso me ha llegado a poner cerca de Benidorm esta mañana. Curioso, ya me gustaría a mi.
Además, para el que no se haya fijado, al realizar una búsqueda con la función “What’s here?” nos añade un historial en la parte inferior del control izquierdo. Muy interesante cuando hacemos búsquedas masivas de cosas, como suelo hacer yo muchos días 
. El equipo de Google Maps no se queda sin ideas, y cada día me entusiasman más.
Bueno, llevo varios días de retraso en mis lecturas diárias en Google Reader, pero recuperando trabajo perdido me he encontrado una grata noticia de Google: ha mejorado notablemente la disposición de resultados con mapa y fotografías:
No está nada mal, me gusta . Y ya puestos, resaltar que los iconos de SearchWiki han sido movidos a la línea de URL, caché y búsquedas similares.
Estoy deseando que saquen el nuevo interfaz que ya propuso Google…
¡Día histórico! Hoy mismo saldrán de su fase BETA proyectos como Google Mail, Google Calendar o Google Docs. Como bien dice Google, esto es debido esencialmente a dos factores, uno oficial, otro quizá no tanto aunque ellos mismos lo reconocen: todas sus aplicaciones han pasado los escrutinios y revisiones de standard, y además, pretenden captar la atención de las grandes empresas y multinacionales hacia su paquete de servicios Google Apps.
Sí, el BETA en el logo no queda demasiado bien para convencer a Telefónica, sin ir más lejos. Hoy mismo desaparecerá esa banderita de “beta” de los logos de sus productos.
Este siempre ha sido tema de conversación: ¿por qué todo lo que hace Google permanece como BETA? ¿no quieren hacerse cargo de los problemas que su uso y explotación pueda causar cuando sucedan imprevistos? Pues ya tenemos respuesta. Ahora tendremos que hablar de otra cosa… ¿del nuevo fichaje del Madrid (odio el fútbol…)? ¿del desarrollo de los caracoles africanos? La vida no será lo mismo…
Yes! Really! Oh God…
A estas alturas del día todo el mundo lo sabrá ya, pero aun así me apetece hacer eco también por mi parte de este importante anuncio: Google ha publicado hoy un post en su blog anunciando la salida de Google Chrome Os, es decir, el primer sistema operativo de Google.
Por lo que parece, su intención es reinventar los sistemas operativos en la nueva era de Internet, basandose en el simple argumento de que cuando se crearon los primeros sistemas modernos no solo no existía la web, sino que no se tenía la conciencia global con la que contamos en la actualidad.
De esto podemos sacar en claro un factor: estará volcado enteramente a Internet. Estará orientado especialmente a netbooks y será lanzado como open source para finales de este año, 2009, para su futuro lanzamiento en equipos netbook para mediados de 2010. Además, para rizar el rizo, estará basado en un núcleo Linux.
Personalmente, no soy un gran amante de Google Chrome como navegador, y aunque Android aunque me parece excelente no me atrae tanto como otros entornos (vease Symbian) sobretodo por el factor Java, pero viendo la calidad que presenta Google siempre en sus productos estoy deseando meterle mano.
¿Tendré que ir pensando en tirarme a por un netbook que complemente mi pequeño Dell XPS M1330?
Es un tema archiconocido y muy usado hoy en día, y por si fuera poco, hipersimple: conseguir las coordenadas de una ubicación por su nombre o mediante una dirección postal. ¿Desde dónde? Pues bueno, hay muchos servicios que ofrecen este tipo de trabajo: desde Geonames (un proyecto increible que recoge coordenadas e información geográfica e incluso demográfica de prácticamente todo el planeta… muy recomendable) hasta los servicios de GData para Google Maps.
La ventaja de usar Google Data (AKA GData) es que el trabajo ya viene hecho, y de paso, está integrado diréctamente en el Google Maps API y por lo tanto el esfuerzo es minomo. Y encima, podemos hacer la consulta de manera asíncrona mediante AJAX. Si usaramos servicios como el de Geonames deberíamos currarnos nosotros mismos esta parte. Pero bueno, todo esto es texto redundante y a nadie le interesan mis verborreas absurdas sobre este tema. Vamos al grano.
function showAddress(address)
{
var geocoder = new GClientGeocoder();
geocoder.getLatLng(address,
function(point)
{
if (!point)
alert(address + ” –> no encontrado en Google Geo Services.”);
else
map.setCenter(point, 13);
}
);
}
Bien, ¿qué hace éste código? Pues es bien sencillo. Primero creamos la instancia de la clase GClientGeocoder, incluido con el Google Maps API desde su versión 2.55, y que contiene una serie de servicios de geocodificado que nos permiten consultar diferentes datos al mercadillo de Mountain View.
Concretamente nos interesa el método getLatLng, que recibe como parámetro la dirección o nombre de la ubicación que nos interesa, y al recibir la respuesta (callback) ejecutará la función creada, recibiendo como parámetro el punto concreto donde se encuentra el lugar, con un objeto de clase GLatLng. ¡Tachán! Ahí está nuestro resultado. Para centrar la vista en él, solo debemos llamar al método setCenter, pasandole como parámetros el punto en cuestión y el nivel de zoom.
Bueno, todo esto está tirado y todos sabemos hacerlo. Sobretodo porque viene en la documentación de la API, y aunque no es exáctamente esta la explicación que dan, es bastante aproximada.
Pero lo interesante aquí es rizar el rizo: recibir como respuesta lugares cercanos a una ubicación concreta.
Dentro del mundo GEO, y a un nivel fundamentalmente básico, hay tres maneras de representar una ubicación:
Pues bien, en el mismo objeto GClientGeocoder tenemos un método que nos permite pedir a Google una colección de localizaciones cercanas a una ubicación concreta: getLocations, que puede recibir como parámetro de consulta o una dirección, o un punto GLatLng.
¿Qué nos va a devolver esta llamada? Un objeto estructurado con todos los datos precisos: por un lado, la información detallada de la ubicación pedida, y por otro, el resultado de Google para la ubicación, con todas las ubicaciones almacenadas en un array de Placemarks, tal que así (lo pego diréctamente desde la documentación de ejemplo de Google, es más claro así, para la geocodificación inversa):
[ { name: "Washington, DC", Status: { code: 200, request: "geocode" }, Placemark: [ { address: "Washington, DC, USA", population: "0.563M", AddressDetails: { Country: { CountryNameCode: "US", AdministrativeArea: { AdministrativeAreaName: "DC", Locality: { LocalityName: "Washington" } } }, Accuracy: 4 }, Point: { coordinates: [-77.036667, 38.895000, 0] } } ] }, ... // etc., and so on for other cities ]
Espero que os sea de utilidad… Aunque sea algo tan básico.
Hoy he podido comprobar (aunque no se si esto ya se hacía ayer o antes de ayer, la verdad) que Google ha modificado la manera en que presenta las URL en sus hojas de resultado de búsqueda. En lugar de mostrarlas completas (sí, esa ruta en verde bajo la descripción del resultado) ahora las acorta destacando los keywords usados en la búsqueda.
Esto, sin duda, mejora la presentación y elimina “paja” de la URL en su presentación, reduciendo el tamaño de la página de resultados y aclarando la imagen ante el usuario.
No tengo demasiado claro que esto nos afecte en SEO: ¿ayudará el hecho de destacar estas nuevas URL con keywords? Creo que, al menos de cara a posicionamiento, la respuesta es no. Pero de cara al usuario que realiza la búsqueda, sí: nos ayudará a mejorar el ratio de entrada desde Google para aquellos afortunados que hemos implantado URL rescrita.
Mucha gente dirá que esto en realidad no es importante: al usuario le da igual. No estoy de acuerdo, tanto desde el punto de vista de atracción visual (todas esas negritas resaltando nuestro resultado en el SERP…) como de cara a mostrar al usuario mejores pruebas de la utilidad de nuestra web.
Gracias SEO Profesional por el aviso 
.
Bueno, como vistes en mi anterior post, ando jugueteando a ratos con Javascript y algunas de sus mejores funcionalidades (o metodologías, como prefiráis): AJAX y JSON. Como muchos sabéis, la gran utilidad que se nos presenta explotando estas tres tecnologías (este método, éste protocolo y este lenguaje de programación de scripting de lado de servidor, para ser exáctos) es la posibilidad de intercambiar datos entre cliente y servidor de manera asíncrona y sin tener que recargar todo el HTML de la página, y por lo tanto, de enviar comandos en uno u otro sentido y conocer el resultado de los mismos.
En PHP existen dos maneras de recoger información que venga del exterior: mediante GET o mediante POST. Cuando trabajamos con GET, podemos probar bien nuestras aplicaciones haciendo uso del ya bien conocido QueryString de la URL, pero cuando tratemos de trabajar diréctamente mediante POST (bastante más seguro y útil) la cosa se vuelve más complicada.
¿Quién no ha desperdiciado horas tratando de enviar parámetros por POST a una aplicación PHP para probar su funcionamiento?
Hoy he visto la luz. Que sí, que muchos ya conoceríais su existencia, pero… he encontrado este Addon de Firefox que nos permite controlar los parámetros que enviamos a la aplicación tanto mediante GET como POST y probar así diferentes juegos de prueba. Se llama Tamper Data, y os puede facilitar mucho la vida .
Mira que siempre he sido un buen amante de los addons para Firefox, pero por suerte o por desgracia soy un programador muy tradicional y siemre intento hacer todo a manita y pasando de herramientas externas siempre que me fuera posible. Porque, como bien me dicen mis amigos, siempre me gusta reinventar la rueda… ¡qué le vamos a hacer!
Y, como no, también nos permitirá ver la respuesta que recibimos del servidor de manera sencilla, aunque si trabajais con JSON, os recomiendo también instalar otra extensión: JSONView, que nos mostrará formateada y resaltada mediante diferentes colores y formas nuestras estructuras JSON sin necesidad de andar haciendo pirulas con nuestro Javascript (esos históricos alert(miobjeto.toString()); que tanto usamos para hacer pruebas de Javascript…
¿Alguna vez habéis querido llamar a métodos PHP desde el lado del cliente mediante AJAX? Pues bien, es bastante sencillo y voy a explicarlo de un modo rápido. Puntualizo que para la comunicación usaré el formato JSON (Javascript Object Notation) para la toma y devolución de datos.
Para facilitar las peticiones usaremos jQuery, que ya trae en sí todo lo necesario para poder realizar este tipo de petición. Primero vamos a crear una función en PHP que multiplique dos números, tal que así:
function Multiplicar(a,b) { return a*b; }
Hasta aquí supongo que todos hemos llegado. Ahora viene lo divertido… Creamos la parte de cliente, en Javascript, una vez hayamos incrustado la librería de jQuery en nuestra página:
function DoMultiplicar(p_a,p_b)
{
$.post(ruta_al_servicio, {a:p_a,b:p_b,cmd:”multiplica”},
function(data)
{
eval(“var obj = ” + data + “;”);
alert(data.result);
}
, “json”);
}
Y procesamos la petición en PHP:
if ($_POST["cmd"] == “multiplica”)
Multiplicar($_POST["a"],$_POST["b"]);
Vale, pero, ¿qué ha hecho todo esto? Pues muy sencillo… Por la parte de Javascript, hemos llamado al método $.post, al cuál le hemos pasado como parámetros, en el mismo orden:
Una vez recogido el resultado con el callback, ya lo tenemos: el resultado de la multiplicación. Si tenéis dudas, no tengáis problema en dejar comentarios… aunque sé que este pequeño tutorial es sencillo y básico para muchos , puede que para otros no tanto.
