Más de un mapa con MyGMMS

[spanish]

El plugin MyGMMS del que hablaba en el post anterior sólo permite insertar un mapa por post, pero habréis visto que tengo dos. ¡Es que soy más chulo que un ocho! :-D

He modificado el plugin para poder insertar tantos mapas como queramos por post. Podéis descargar el parche aquí.

[/spanish]

[english]

The MyGMMS plugin I mentioned on the previous post only allows one map per post, but as you can see I inserted two. I rule! :-D

I’ve modified the plugin so that you can insert as many maps as you want in a post. You can download the patch here.

[/english]

Tarde de buceo sin mucha suerte…

Ésta tarde nos hemos ido a bucear unos amigos y yo. El fin de semana pasado nos quedamos con las ganas por culpa del temporal, y como a lo largo de la semana ha ido mejorando el estado del mar estábamos deseando mojarnos. Y además, ¡que se note que estoy de vacaciones, coño!
El plan inicial era ir a una cala que conocía Gabi poco antes de llegar a Villajoyosa, pero ya de camino nos temíamos lo peor porque el mar estaba un poco picado y había viento de Levante. Una vez en la cala en la orilla directamente se veía que la visibilidad era mala, con 10cm de agua a penas si se veía el fondo. Así que hemos dado media vuelta.

#GMAP_SIT(«-0.278606@38.490883|15|102760741917115417098.000438ef84432cfc789d4|500|300»)#

La verdad es que la calita al menos tenía buena pinta y el acceso es bastante bueno, llegas con el coche hasta la misma arena (bueno, piedras). Otra vez será.

El plan B ha sido ir a Cala Palmera, en el Cabo las Huertas. Ésta la conocíamos todos pues es un sitio típico donde te llevan a hacer las primeras inmersiones del Open Water. Bufff, un desastre. Ya desde fuera veíamos que la cosa no estaba muy bien, pero como somos unos cabezones nos hemos ido al agua. Visibilidad malísima, ¿un metro? ¿Metro y medio? Casi teníamos que ir de la manita para no perdernos, no exagero. Tenías que estar más pendiente del compañero que de ver el entorno submario, que de todas formas no se veía hasta que no te dabas de bruces con él. Así que hemos hecho el paripé media hora que a penas si hemos bajado de los 4m (¡qué triste!) y nos hemos vuelto para casa.

#GMAP_SIT(«-0.409906@38.352999|15|102760741917115417098.000438ef84432cfc789d4|500|300»)#

Por lo menos el día nos ha servido para:

  • convencernos de que si el mar está mal, no vale la pena ir a bucear. No ves nada, no lo pasas bien (vas preocupado por despistarte de los compañeros, etc.), y pierdes más tiempo entre coche, montar el equipo, ponértelo, y luego endulzarlo y demás que bajo el agua. Una retirada a tiempo es una victoria.
  • Víctor ha estrenado su nuevo ordenador de buceo. :D
  • yo he estrenado casi todo el equipo: gafas, escarpines, traje y aletas. Y me ha servido también para descubrir que no mola estrenar equipo si las condiciones del agua no son buenas: las he pasado putas con las gafas (se me empañaban, luego me entraba agua hasta que he conseguido ajustarlas bien…) y ¡¡se me ha salido una aleta!! Un agobio.

Y aparte éste post me sirve para probar un plugin que integra Google Maps en WordPress. :)

Migrando a MacOS X

Ya comenté hace un tiempo que mi ordenador había pasado a mejor vida y estaba pensando comprarme un Mac. Pues finalmente «piqué» y hace algo más de un mes que soy un feliz propietario de un MacBook Pro. :-D

La migración no ha sido nada traumática ya que en el trabajo ya había trabajado con MacOS X. Eso sí, me había limitado a administrar la red, impresoras, etc. e instalar los programas que necesitaban mis compañeros, y poco más. Ahora es cuando estoy sacándole todo el jugo.

Voy a comentar algunos de los programas que uso. Todo es GPL o en su defecto «free as in free beer».

Vayan las gracias por adelantado a mi amigo Ramses de Zelofan, que me echó una mano los primeros días con una versión inicial de ésta lista. :)

Ofimática

  • NeoOffice. Versión nativa para Mac del Open Office.
  • Abiword. Un procesador de texto más simple que el NeoOffice.

Internet

  • Firefox. Por supuesto. :) La verdad es que el Safari lo estoy ignorando bastante…
  • Adium. Un cliente IM con soporte de varios protocolos. No en vano usa las librerías del Pidgin (antiguamente GAIM).
  • Transmission. Cliente de bittorrent sin complicaciones.
  • Reader Notifier. Avisa de artículos nuevos en Google Reader.

Juegos

  • DOSBox. Emulador de MS-DOS, para todos los juegos del año la polca.
  • MAME OS X y MAME Library. El emulador de recreativas por excelencia y un front-end chulo.
  • ScummVM. Intérprete para las aventuras clásicas de Lucas y muchos más.

Sistema

  • Burn. «Tostador» cómodo y fácil de usar.
  • VirtueDesktops. Cuando no estoy en Linux siempre echo de menos tener varios escritorios virtuales. :)
  • ClamXav. Anti-virus GPL para Mac. Tiene un módulo que monitoriza todo lo que se deje en una carpeta.
  • InsomniaX. Para evitar que el sistema entre en ahorro de energía y tenerlo toda la noche con música, descargando cosas, etc.
  • OnyX. Permite configurar varias características ocultas del sistema.
  • The Unarchiver. Descompresor universal de todo lo que le echen.
  • QuickSilver. Tipo Google Desktop, permite buscar archivos, programas, etc. con una sencilla combinación de teclas.
  • Growl. Es un sistema para sacar pequeñas ventanas de sucesos que usan un montón de aplicaciones.
  • ExtFsManager. Permite montar particiones ext2 de Linux.
  • Fan Control. Importantísimo para que el equipo no se caliente más de la cuenta.
  • Fink. «fink install joe». ‘nuff said.
  • Q. Versión Mac del QEMU (si, el Parallels va más rápido, pero es de pago) P-)

Multimedia

  • VLC. Reproductor multimedia, me parece el más completo, con más codecs y demás.
  • mplayer. Hay una versión para OS X, pero no es tan bueno como en Linux.
  • Xee. Un visor de imágenes sencillote pero funcional. Si tienes instalado el Unarchiver abre cómics en formato .CBR y .CBZ.
  • MacTheRipper. Para hacer «copias de seguridad» de los DVDs. P-)
  • ScrobblePod. Envía a last.fm datos de lo que escuchamos con el iPod (tipo mi gtkpodscrobbler).

Desarrollo

  • Eclipse. Faltaría más.
  • MAMP. LAMP sustituyendo la L por M. :-D
  • Komodo Edit. Editor de código. Es parte de un IDE de pago, el editor sólo es gratis.

Y seguro que me he dejado alguno en el tintero, pero bueno, para el próximo post. ;)

Webs

Y ahora alguna web útil para ir entrando en el mundillo:

Arquitecturas escalables en Google

[spanish]

Un compañero de trabajo me manda tres interesantes artículos de la web High Scalability, que no conocía aún y que ya he añadido a mi lista de RSSs en Google Reader. :) Los artículos tratan sobre las decisiones de diseño y arquitectura de computadores/redes tomadas en YouTube, Google y GTalk, para hacer frente a la altísima cantidad de visitas y datos que deben servir por segundo, comentando también más o menos la estructura actual y la evolución de la infraestructura de cada uno de ellos:

Algunas conclusiones a extraer de éstos artículos:

  • No intentar arreglarlo todo con una única arquitectura o una única herramienta. Dividir el problema en subproblemas, ver en cada caso si el límite es CPU, ancho de banda, IO y optimizarlo. Especializar servidores para cada caso y coordinar el trabajo de cada parte.
  • Cachear contenido siempre que sea posible. Pregenerar contenido siempre que sea posible. Utilizar las directivas HTTP para el control de caché. Usar squid como proxy inverso para aliviar a los servidores de aplicaciones.
  • Plantearse externalizar algún servicio, el hosting de imágenes o videos que puedan suponer más ancho de banda del que actualmente tenemos. Aunque sea como solución de compromiso mientras se contrata más ancho de banda. Lo importante es ofrecer el servicio en condiciones.
  • Simplicidad, dentro de lo que cabe. Permitirá hacer cambios y evoluciones sin cagarla demasiado.
  • Clusters basados en PCs normales. Maximizan la relación potencia/precio. Tener montado un sistema de redundancia para que una caída no afecte al servicio, y un sistema de instalación sencillo para poder añadir/sustituir equipos sin calentarse mucho la cabeza. Y empezar a planificar los problemas de alimentación y aire acondicionado. ;)
  • La programación hoy en día se basa en librerías y frameworks. No reinventar la rueda. Usar un framework común, propio o no, de forma que los programadores no tengan que hacer una y otra vez las mismas cosas y una actualización beneficie a todos nuestros productos de golpe.
  • Pensar en la arquitectura desde el principio. Estoy tristemente acostumbrado a que los desarrolladores no se preocupen de lo que hay por debajo de su código, ni si éste va a provocar problemas de red, disco, CPU, etc. Google enfoca todos los problemas desde la arquitectura necesaria para dar el servicio, y luego programa alrededor de ésa arquitectura. Es lo que diferencia a Google del resto.

[/spanish]

[english]

A coworker has sent me three interesting articles from High Scalability, a site I still didn’t knew but which I’ve already added to my Google Reader list. :) The articles talk about the design and computer/network architecture decisions taken at YouTube, Google and GTalk in order to handle the big load their services face. They also comment the current architecture in each site and their evolution over time:

Some lessons to learn from these articles:

  • Don’t try to fix everything with one single architecture or tool. Divide the problem, see if each sub-problem is CPU-, bandwidth- or IO-bound, and optimize it. Specialize server for each task and coordinate their work.
  • Cache content whenever possible. Pre-generate content whenever possible. Make good use of HTTP’s cache-control directives. Use squid as a reverse proxy to leverage your application servers’ load.
  • Think about externalizing some things, like hosting images or videos off-site. These elements may need more bandwidth that you currently have, and moving them off-site can be a good idea, even if it’s just a temporary measure while you manage to get more bandwidth. The service must run at all times.
  • Simplicity. Will let you make changes and evolve your architecture without screwing up.
  • Commodity-PC based clusters. They maximize the power/price ratio. Have a redundancy system in place so that when one node goes down or needs maintainence, the system keeps working without it. Have a system to easily install/change a node, also without affecting the service. And start planning the power and cooling problems ahead. ;)
  • Programming today is much about libraries and frameworks. Don’t reinvent the wheel. Use a common framework in all your developments, homegrown or not. This way novel programmers will be able to start writting code faster, will be able to switch projects easily, won’t have to code the same things over and over again, and a system upgrade will benefit all your applications.
  • Think about the architecture you’ll need from the start. I’m sadly used to developers not caring about what their code runs on, or if their code will lead to CPU, IO or bandwidth problems. Google seems to face every new development looking at the architecture they’ll need to handle the service, and then develop the code arount that architecture. This is what settles Google appart from the rest.

[/english]