Archive for the ‘Mafufadas’ Category.

Google Maps Street View en Tijuana

Google Maps, Street View, Tijuana, 2010-02-12

Por azares del destino encontré que Google ya tiene una pizca de Tijuana lista en el Street View de Google Maps.

Al parecer alguien vio el carro en junio de 2009, se la pasó a algún amigo y éste lo blogueó! :-O

Actualización 1: La mejor foto que publicaron los de tijuanayo.com es la del vehículo de Google siendo cuestionado por la policía.

Actualización 2: También en tijuanayo.com observaron que ya está en línea e hicieron un post al respecto.

Grandioso ¿no? Ojalá pronto podamos tener el resto de los servicios. Particularmente, saber cómo llegar de A a B con optimizaciones, como en San Diego, pero específicas a la localidad. Estas son las optimizaciones que me imagino en Google Maps para Tijuana:

  • Usar sólo transporte público
  • Usar sólo automóvil
  • Evitar boulevares y aprovechar vías rápidas
  • Evitar tráfico (en tiempo real)
  • Evitar baches y charcos (en tiempo real)
  • Evitar balaceras (en tiempo real)
  • Parar por una gasolinera non-rata (en tiempo real?)
  • Evitar el tren (en tiempo real)

:-)

Etiquette in e-mail message quoting

This is a translation of my previous post Etiqueta en el citado de mensajes de e-mail.

Introduction

The most ignored Internet Etiquette rule is that of the posting style when replying to an e-mail message.

By “quoting” I mean the inclusion of a previous message in a new one (for example, a reply) with the intent of stating the relevance of the answer itself in the original context. I would say “Dan, I don’t know what are you talking about. Please quote the original e-mail in your reply next time in order to know what were you replying to.”

Almost every e-mail client do quote the original message in the reply, at least by default. That is good, and it contributes to the “netiquette”, but its abuse has made it completely useless.

Continue reading ‘Etiquette in e-mail message quoting’ »

Operación contraintuitiva de “patch”

Este es un ejemplo de lo que NO se debe hacer al diseñar un software.

[Sun Dec 20 14:37:42 -0800 -- alvarezp@octavio:~/patch-test]
$ ls -l
total 24
-rw-r--r-- 1 alvarezp alvarezp 7127 Dec 20 14:37 slpcall.bak
-rw-r--r-- 1 alvarezp alvarezp 7127 Dec 20 14:37 slpcall.c
-rw-r--r-- 1 alvarezp alvarezp 7232 Dec 20 14:37 slpcall.c.2

[Sun Dec 20 14:37:43 -0800 -- alvarezp@octavio:~/patch-test]
$ diff -u slpcall.c slpcall.c.2 > p

[Sun Dec 20 14:37:57 -0800 -- alvarezp@octavio:~/patch-test]
$ cat p
--- slpcall.c	2009-12-20 14:37:36.000000000 -0800
+++ slpcall.c.2	2009-12-20 14:37:36.000000000 -0800
@@ -66,6 +66,11 @@

 	slpcall->slplink = slplink;

+	slpcall->wait_for_socket = FALSE;
+	slpcall->xfer = NULL;
+	slpcall->dc = NULL;
+	slpcall->branch = NULL;
+
 	msn_slplink_add_slpcall(slplink, slpcall);

 	slpcall->timer = purple_timeout_add_seconds(MSN_SLPCALL_TIMEOUT, msn_slpcall_timeout, slpcall);

[Sun Dec 20 14:38:00 -0800 -- alvarezp@octavio:~/patch-test]
$ diff -u slpcall.bak slpcall.c # .bak is a backup of original

[Sun Dec 20 14:38:19 -0800 -- alvarezp@octavio:~/patch-test]
$ patch < p
patching file slpcall.c

Hasta aquí, todo bien.

[Sun Dec 20 14:38:53 -0800 -- alvarezp@octavio:~/patch-test]
$ cp slpcall.bak slpcall.c

[Sun Dec 20 14:39:02 -0800 -- alvarezp@octavio:~/patch-test]
$ mkdir x

[Sun Dec 20 14:39:04 -0800 -- alvarezp@octavio:~/patch-test]
$ mv slpcall* x/

[Sun Dec 20 14:39:06 -0800 -- alvarezp@octavio:~/patch-test]
$ ls -l
total 8
-rw-r--r-- 1 alvarezp alvarezp  410 Dec 20 14:37 p
drwxr-xr-x 2 alvarezp alvarezp 4096 Dec 20 14:39 x

[Sun Dec 20 14:39:08 -0800 -- alvarezp@octavio:~/patch-test]
$ diff -u x/slpcall.c x/slpcall.c.2 > px

[Sun Dec 20 14:39:20 -0800 -- alvarezp@octavio:~/patch-test]
$ cat px
--- x/slpcall.c	2009-12-20 14:39:02.000000000 -0800
+++ x/slpcall.c.2	2009-12-20 14:37:36.000000000 -0800
@@ -66,6 +66,11 @@

 	slpcall->slplink = slplink;

+	slpcall->wait_for_socket = FALSE;
+	slpcall->xfer = NULL;
+	slpcall->dc = NULL;
+	slpcall->branch = NULL;
+
 	msn_slplink_add_slpcall(slplink, slpcall);

 	slpcall->timer = purple_timeout_add_seconds(MSN_SLPCALL_TIMEOUT, msn_slpcall_timeout, slpcall);

[Sun Dec 20 14:39:22 -0800 -- alvarezp@octavio:~/patch-test]
$ patch < px
patching file slpcall.c.2
Hunk #1 FAILED at 66.
1 out of 1 hunk FAILED -- saving rejects to file slpcall.c.2.rej

¿La solución?

patch -p0 < px

Sin alternativa

Estaba revisando mi correo electrónico y quise mover un mensaje de una carpeta IMAP a otra en Opera, cuando de pronto:

sin-alternativas

El texto dice:

Uno o más de los mensajes seleccionados no tienen el cuerpo descargado localmente, ¿Desea que Opera descargue los cuerpos faltantes antes de la exportación (sumamente recomendado)?

:-D

CCNA revalidation

Today I passed the Cisco Composite exam, which extends my CCNA certification for three more years, and is a great leap towards certification in the CCNP program.

I just have to wait for Cisco to mark my exam as “valid”. I don’t find any reason for them not to.

I gotta take some rest for a few days. Next stop: ISCW.

Cómo quemar CDs de Windows legalmente

burn_cd_1burn_cd_2

Autores: Gultij.

1234567890

Del porqué de la encuesta de tamaños de imagen y sentido común

Bien, en vista de que no hubo más comentarios, planteo de dónde salió mi duda.

La pregunta era:

Si les ponen la encomienda de reducir una imagen al 50% de su tamaño manteniendo la razón de aspecto, y la imagen mide originalmente 1 m x 1 m a 200 dpi, ¿cómo la entregan?

De los votos que estuvieron dentro de las opciones, hubo 2 votos por la opción “entregarla en 0.5 m x 0.5 m a 200 dpi”, es decir, misma resolución, diferente tamaño por lado.

Sin embargo, una imagen de 0.5m x 0.5m cabe 4 veces en una imagen de 1m x 1m. Esto significa que estamos reduciendo al 25% la imagen original (y no al 50% como se pidió). Lo que en realidad está sucediendo es que ese “50%” es por cada uno de sus lados, y 50% x 50% = 25%.

Lo podemos comprobar con Gimp:

  1. Configuramos las preferencias para un tamaño máximo de memoria a 128 MB.
  2. Creamos la imagen de 1000 mm x 1000 mm a 200 dpi. GIMP nos reclama que estamos tratando de crear una imagen de 551 MB.
  3. Intentamos la opción I: 500 mm x 500 mm a 200 dpi. GIMP nos reclama que estamos tratando de crear una imagen de 137 MB MB, aproximadamente el 25% de la imagen original.
  4. Intentamos la opción E: 707.1 mm x 707.1 mm a 200 dpi. GIMP nos reclama que estamos tratando de crear una imagen de 275 MB MB, aproximadamente el 50% de la imagen original.
  5. Regresamos las preferencias de Gimp al valor original.

Sin embargo, aunque matemáticamente la respuesta sería la E, dado que el tamaño de una imagen es su superficie (su área), es algo que aparenta ser antinatural. Para sacar el 40% del tamaño de una imagen, multiplicamos cada lado por SQRT(40/100), lo cual no es agradable (o bien, multiplicar el dpi por SQRT[40/100]).

Entonces, considerando esto, la intención original de mi pregunta era sobre la costumbre entre la gente que a esto se dedica: si cuando se pedía una amplificación o una reducción de imagen, se acostumbra hablar de un porcentaje de la imagen calculado sobre su área o cada uno de sus lados.

Gracias a los que comentaron, y saludos.