Hay una muestra de la fotografía de Mercedes Hausmann y de otros cinco artistas fotográficos ( Rosa Ponce, Óscar Romero, Isaac Rojo, David Durán y Albert Manau ) en la exposición “F*ck photo, let’s dance”, que podéis encontrar en el Underwood Café ( Infantas,32, Madrid ).

Podéis encontrar un portfolio de las imágenes de Mercedes en su web mercedeshausmann.com o en su flickr merenelpaisdelasmaravillas .

De repente uno recibe un día una aplicación, de funcionamiento no muy complejo, pero enorme, pesada y monolítica. Difícil de mantener, de expandir y de escalar.

¿Cuál es la mejor solución?

Yo creo que quemarla.

So I’ve been trying today, just because, to compile Cherokee 1.0.0 under Haiku OS alpha r2 (former OpenBeOS) and I’ve found some problems that, by now, stopped me from doing it…

First, there’s no declare of the arch ( i586-pc-haiku ) on the config files, but that would be easy to fix, so I tried it by default.

Second, “error: C compiler cannot create executables”. See error on this pastebin. Apparently there’s a check that it isn’t needed on Haiku of the dload libraries. This libraries apparently aren’t needed because already are added on some other place. I fixed this removing all the ‘-ldl’ flags on the ‘configure’ file.

Third, and the error I haven’t fixed and stopped me of following this port, differences on socket libraries. It fails on ‘./configure’ when checking socket libraries, apparently because are a bit different here on Haiku. So I’ve been checking the Common Problems Guide on the Ports section of Haiku website, where on the last paragraph is a little reference to an error about that, apparently comming from this libevent patch. I tried diferent options on the configure.in file substituting the libraries checks more or less like that example, but without any success. Thanks anyway to cratuki on #haiku (freenode), that download the code and lent me a hand. BTW that guy is porting succesfully Bethon to Haiku. Bethon are python libraries for BeOS, for drawing windows and so on 😀

I’m no programmer, and I don’t have a clue of C, so I’m a bit lost on this…

Any help?

Bien…

Como más de uno habréis observado, mi web estaba, digamos, abandonada. La web, el correo, los blogs, los podcasts… He echado un vistazo y he decidido que no iba a echar mucho de menos, y que no era nada más que un lastre que iba arrastrando de un lado a otro…

Así que lo he borrado casi todo, como un 85 o 90% de las cosas, y a ver si me motivo un poco… le daremos marcha a proyectos como los que tengo en Kanteron, Cherokee o Mozilla…

Después de la celebración del primer Encuentro Internacional del proyecto Cherokee, la publicación de la tan ansiada versión 1.0 es una realidad.

Cherokee 1.0

Cherokee es un servidor web estable, flexible y sólido. Tiene un pequeño tamaño en memoria y es muy fácil de configurar. Soporta gran cantidad de las tecnologías en uso hoy en día en la web: FastCGI, SCGI, PHP, CGI, SSI, conexiones cifradas TLS y SSL, servidores virtuales, autenticación, codificación al vuelo, ficheros de log compatibles con Apache y mucho más.

También tiene una serie de cualidades únicas que le hacen destacar: una caché en memoria muy eficiente para contenidos estáticos, balanceo de carga HTTP integrado, balanceo de base de datos, proxy HTTP inverso, gestión de ancho de banda, streaming de audio y video, informe del estado de la transferencia, soporte uWSCGI, etc.

Otra cosa que le distingue del resto de sus competidores es la facilidad de uso de su interfaz gráfica de configuración, que te permite configurar el servidor de arriba a abajo en todas sus opciones sin tener que editar un solo fichero de texto. Es un aplicación rica, moderna, que también provee de asistentes de configuración para múltiples aplicaciones y escenarios de producción. Estos asistentes permiten incluso la configuración del servidor web sin necesidad de gran conocimiento.

Cherokee Summit 2010

Muchos de los desarrolladores y de lo smiembros de la comunidad Cherokee han unido sus fuerzas el último fin de semana en en Madrid, España, y han publicado la nueva versión como un acto simbólico después de muchos años de desarrollo y mejora constante.

La versión 1.0 trae de sobrenombre “The Summit Release”, y ya se han establecido las guías a seguir para la versión 2.0. El primer encuentro de Cherokee ha sido un gran éxito, así que esperamos ver qué es lo que el futuro nos trae para el próximo encuentro, las próximas versiones de Cherokee, y la comunidad que ha estado creciendo constantemente alrededor de él...

So now, we know that our web app can get easily geographic info from the client, assuming of course the client uses Firefox 3.5 or newer. We won’t talk about code samples yet but go further into the theory of geolocation, now going to the second step mentioned on the first article and do it the other way… finding geolocation on web pages from the client.

There is a number of objects we can find geotagged on a webpage. Basically it will be HTML and jpeg images.

JPEGs

JPEG images are the easiest to get, due to only one existing standard. JPEG geotagging is written on what is called EXIF metadata . EXIF metadata is embedded on the headers of JPEG files, and includes, among other things, all the shooting data as: flash use, speed, ISO value, time and date, camera model and maker, position of the camera, color space… and geolocation data. Of course, all this data has to be supported by the camera to be included (i.e. having a camera with GPS) or you need to add all this info later with another software. Just to point an example, you can get all your photos that aren’t geotagged with a software as iTag, GPSED, HoudahGEO or GeoPhoto and embed the geolocation info on the EXIF data, either pointing on a map or using an autonomous gps waypoint file. Having on the JPEG file all the info about when, where and how all your photos where taken is a very precious value…

Wikipedia has some info on how the dump of the exact data of the EXIF headers would look like, but, we can get the full info without messing around with headers with any EXIF library or tool.

See the awesome console ExifTool software, available on most distros repositories or from source on its webpage, or the Exif Viewer Firefox AddOn if you wanna mess around with EXIF headers and info.

BTW, EXIF headers can contain a lot of interesting info that most people don’t know that even exists, and can lead to info leaks. Some day I’ll write something about it…

HTML

Geotagging doesn’t rely on a single standard when talking about HTML. Digging around we can see that most used formats are:

• ICBM Used by the GeoUrl project ( that has a blog that hasn’t been updated since 2008 ) consists on a ICBM META tag containing lat/long, in form of a decimal number. As GeoUrl is also a database of geotagged sites, they also index GeoTag style tags into their database.
• GeoRDF, defined by the W3, is based on the WGS84 datum (a datum is a standard used for having reference when locating points on the Earth surface) You can check the vocabulary, that is very easy and contains lat, long and alt.
• Microformats, a much hyped tagging system (not standard but “open”, if you really care, but it works), used for “machine tagging” sections and objects, so it can make individual ‘things’ parseable and recognizable by a parser/crawler/indexer. There is a Geo Microformat available, also based on WGS84, that has lat and long properties and it’s a clone of the geo property of the vCard standard.

i.e. Flickr allows you to say where a photo or an album has been taken, and it will geotag all your photos with that info, but it won’t do it inside the EXIF data of the image, but place a pair of tags on that Flickr photo page, one ICBM and one GeoTag.

So, there’s still more to come, in next article I’ll talk about the data we are extracting, the problems we can find, and what to do with it…

So we have to give context info related to the geolocation of what we are seeying on a webpage…

We have two things to geolocate here, that is:

• Finding where are YOU, the browser, the client…
• Finding where is located the info you are reading…

On this post, we’ll talk about that first one…

With Firefox, we have an easy way of dealing with it, it used to be called Geode, and now is embedded on Firefox since 3.5 with the motto “Location Aware Browsing” . It works, more or less, on the same way OS X and iPods work for geolocating you when you have no GPS available. A webpage request your position, you allow or disallow it, it gathers your current public IP address and the ESSIDS and MAC addresses of nearby wifi access points, sends it to Google Location Services, where, checking on a huge database of IPs and access points, find your approximate position and sends it back to the webpage it requested, so it can show you geographically related info or whatever.

Asking from your app to the client, and getting a lat/long reading, in just 3 javascript lines, it’s plain awesome, and you just have to take care of having a nice way of geo searching on your database.

This is kind of cool, and is a nice tool for all that webapps with data related to a place, like directories where you can find places to eat or drink, or tourist guides, or location related services. Think about entering Amazon to buy albums, and knowing the exact rate for shipping before even beggining your order, or arriving to a hotel in a strange place, opening your favourite ‘food and drink’ directory, and, since it knows your location, even without having a gps, recomending you the best places for having dinner, a good party or a show from your favourite artist…

Due to some personal issues, both Andrea and me have been a bit away of the project (I couldn’t use my hand due to a hard sprain on my wrist) but… We’re back again!

In case you don’t konw our project, is called GeoHermes, and we want it to read geo tags on the sits you visit, so you can get related info near geographically, getting info from different feeds from social sites, services sites, and so…

So we’ll put together all the ‘blueprints’ and make the specs ready for this week…

Our project page:

https://launchpad.net/geohermes

After a damn tiring (but very funny and interesting at the same time) week on Fuenlabrada, studying the bells and whistles of XUL, XBL, FUEL JS and so on, appears that we are ready to get released on the wild.

Almost everybody defined the basis of their future projects, and we’ve been provided with a good bunch of resources and help.

BTW, my project is going to be related to geolocalization and geotags, stay tuned here if you wanna get more info…

Finally, here you have, the course photo!

We are just about to begin the Madrid Mozilla Technologies Course, and, of course, that’s an exceptional excuse for reviving this blog, dead almost for two years.

Twenty people selected from more than two hundred from all around Europe, working on the technologies that drive the public face of the Internet, our browser. Our expandable, free, and open browser.

I’m very nervous and quite sure that we’re going to work in something worthy of offering to the Mozilla users and developers community…

Good luck to everybody!