Tag: cosas importantes que no interesan a nadie

Gmail desde consola (UNIX) con mutt

Instalas mutt:

apt-get install mutt

Configuras mutt (usualmente, .muttrc en tu home):

set from = "user@gmail.com"
set realname = "Guillermo Garron"
set imap_user = "user@gmail.com"
set imap_pass = "password"
set folder = "imaps://imap.gmail.com:993"
set spoolfile = "+INBOX"
set postponed ="+[Gmail]/Drafts"
set header_cache =~/.mutt/cache/headers
set message_cachedir =~/.mutt/cache/bodies
set certificate_file =~/.mutt/certificates
set smtp_url = "smtp://user@smtp.gmail.com:587/"
set smtp_pass = "password"
set move = no
set imap_keepalive = 900

(nota: imap_user e imap_pass no son necesarios para envío).

Envías correo:

mutt -s "Subject" [direccion] {direccion 2} {...} {-a "Adjunto"}

o bueno, con la redirección del cuerpo.

Originalmente publicado el 2 de Diciembre de 2011

King Kong vs. Godzilla

Mañana comienza la batalla entre los dueños de la NFL y los jugadores. Ambos bandos cuentan con impresionantes equipos de abogados, un amplio repertorio de maniobras legales, y por supuesto el odio total e incondicional de los fans. Porque estos dos nos están quitando el deporte que adoramos, porque no pueden ponerse de acuerdo en cómo repartirse 7 mil millones de dólares al año.

Iba a hacer un laaaargo post acerca de cómo está el problema, pero es muy sencillo: todos quieren más dinero. Y todos asumen que nosotros, los pendejos fanáticos, vamos a seguir ahí en 20xx, cuando sea que regrese el espectáculo. No importa si es el 2011, créanme… a muchos ya nos está afectando. Y algunos, pues ya casi nos vamos.

Como en la película, en realidad no quieres que gane ninguno. Finalmente, cualquiera de los dos nos va a comer.

Extraer nombres de rutinas en códigos fuente tipo C

Bien dicen que la necesidad es la madre de la invención.

Tenía que extraer todos los nombres de rutinas de las diferentes clases de C# que he estado trabajando. Después de buscar en Visual Studio por alguna opción que me permitiera hacer esto de manera sencilla – y vaya que busqué – me desesperé y pensé… finalmente son texto plano, no? Las clases, esto es.

Pues, ¡claro que lo son! Y entonces awk viene muy al caso. El siguiente script sirve para cualquier código fuente tipo C (rutinas con parámetros entre paréntesis, código de la rutina entre llaves) – siempre y cuando las llaves no estén nunca en la misma línea que el nombre de la rutina (una práctica relativamente común). Ejemplo de lo que sirve:

modificador modificador RUTINA(parámetros si los hay)
{
...
}

o también

modificador modificador RUTINA(parámetros si los hay)
{...}

o cualquier combinación entre ellas. Luego entonces, el script:

awk 'BEGIN{x=0;} {if($0 ~ /{/) x=x+1; if($0 ~ /}/) x=x-1; if(x==0 && $0 !~ /}/) print $0;}'

Nótese que esto no nos quita los modificadores, solo el código intermedio. Si queremos quitar todo lo demás, podemos utilizar sed – pero después de 10 minutos de jugar con él me doy cuenta que no es trivial (al menos ahorita ¬¬) y lo dejo para otro post – o como dijeran mis libros de la prepa: “Queda como ejercicio para el lector”.

🙂

Acerca de .Net, el manifiesto y los requisitos previos

Pues llevo la mejor parte de la noche (ok, ok, apenas un par de horas, pero es bastante para mí!) lidiando con un problema interesante. Explicaré un poco de los preeliminares, para que todos nos entendamos.

La plataforma de .Net es, para mi gusto, una verdadera maravilla. Si vas a desarrollar para Windows (y no te importa mucho obligar a tus usuarios a que instalen X dependencias que bien pueden ser molestas), te permite utilizar una serie de lenguajes muy parecidos entre sí, sólidos, con una gran base de desarrolladores que pueden ayudarte, código disponible en línea, e incluso bibliotecas listas para ser aprovechadas. Como Java, pues, pero sin la molestia de tener que usar… *eso*. Si tú desarrollaste en Visual Basic, VB.net es prácticamente lo mismo; si trabajaste en Java, C# es un camino bastante directo. Tiene gran versatilidad para desarrollar aplicaciones web, permite redistribución de dependencias (recuerden esto), tiene soporte para actualizaciones automáticas de tu aplicación… bueno, las bondades son demasiadas. En fin, es una plataforma que personalmente, me agrada bastante.

Nosotros, los programadores eventuales (es decir, que en realidad no nos dedicamos a esto para vivir), tenemos muchas malas mañas. Generamos código sucio, no muy organizado ni comentado; nuestra documentación puede catalogarse como garabateadas en servilletas y hojas de papel que acaban tiradas por ahí; y tendemos a vivir en el modo “debug”, nunca preocupándonos por cómo va a quedar la aplicación final cuando el usuario final decida instalarla – digo, podemos dejarlo hasta el final, no? El problema con esto es que cuando llega el famoso final… es una pesadilla.

De entrada, les recomiendo esto: no utilicen acentos para nombrar a su aplicación. No, .Net no truena con eso. Pero si quieren utilizar la funcionalidad de actualizaciones, su servidor web puede darse de topes con ustedes, porque va a buscar archivos y cadenas no fácilmente codificables. Solo… tómenlo como una recomendación amable.

Y por supuesto, el centro del problema: los requisitos previos. .Net corre sobre una máquina virtual (el “Framework”), y mi aplicación en particular utiliza un motor de bases de datos sencillo (SQL Server CE, que es algo así como el primo debilucho de SQL Server Express, que a su vez es el babas a comparación de SQL Server, que a su vez… etc etc), comparable con sqlite. El Framework, para instalarle, utiliza *otro* requisito previo, el Windows Installer (v.3.1 en este caso en particular). Estos requisitos son manejados elegantemente por el instalador generado por .Net: se descargan automáticamente de internet, si el usuario final no los tiene ya instalados. El problema es que, combinados, son alrededor de 100 Mb de descarga: ciertamente no es mucho para un geek, pero un usuario con una conexión de Infinitum a 512 (cuando le va bien) nos va a obligar a visitar a los papás. So… debemos poder incrustarlos con nuestro instalador, cierto?

La respuesta es “sí, pero te va a costar trabajo”. Resulta que estos instaladores (que se pueden bajar bastante fácil de internet) no se ponen en cualquier localidad. Deben ir en el directorio que .Net utiliza para almacenar los instaladores. Suena sencillo… hasta que nos enteramos que cada versión del Framework tiene diferentes localidades (y lo mismo para cada versión del Installer, SQL, etc), y que a su vez, cada versión de la IDE lo pone en directorios ligeramente diferentes. En mi caso?

C:Program Files (x86)Microsoft SDKsWindowsv7.0ABootstrapperPackages

¬¬ Sí te iba a encontrar, no?

Pero gracias a un valiente y hermoso post:

http://social.msdn.microsoft.com/forums/en-US/Vsexpressvb/thread/56584721-3064-46c2-81f4-6c29c01e1895/

Tuvo solución el problema. La moraleja, como siempre, es no fiarse de M$.

😀

De verdad que no te entiendo, Axtel

Allá en la fuente, había un chorrito…

Ok, figúrense este problema: su navegación por internet es, a todas luces, buena. La velocidad es decente, o al menos no es notoriamente lenta. Al menos, así parece en el buen puerto 80. SSH tampoco reporta lentitudes. Todo marcha bien. De pronto, se les ocurre hacer una descarga (digamos, para actualizar los paquetes de su *Nix). La velocidad los tira al piso: alrededor de 30 KBps. Caray, hasta Infiernitum da más! OK, esto es probablemente un problema con el servidor de Linux, cierto? Veamos, tengo por aquí un archivito de MegaUpload que puedo probar…

…a unos notables 25 KBps. W. T. F?!

He hecho 4 llamadas al soporte técnico de Axtel (por cierto, ajúa con el acento, chavos!). Las 4 llamadas han resultado en lo mismo: “Sí señor, prometemos resolverlo. [2 días después] A ver señor, pruébelo. [Funciona aparentemente bien]. Gracias por su preferencia. [30 minutos después… cuerno.]” Qué pedo, Axtel? Estamos jugando, o qué demonios? Ah, pero eso sí: cada vez que me piden utilizar un medidor de velocidad en línea, “casualmente” me reporta un ancho de banda normal. Dammit!

Se hacía grandote…

Hace un par de días, estaba yo feliz trabajando en una sesión ssh en la valiente jusanet (a eso de las 3 de la mañana), cuando de repente, mi vi estaba mas menso con mis comandos que de costumbre. Supuse que era la jusanet, y aventé 40 maldiciones en arameo antiguo al cielo (lo cual no suele solucionar nada en la conexión, pero se siente tan bien… ahem, pero me desvío del tema), hasta que volteé a ver mi monitor de uso de red… al pico. Hhmm…. esto se ve raro. Ah, pero está abierto JDownloader! Será? Será?? Ya tengo buena velocidad?

Efectivamente. Mis dulces, adorados y muy extrañados 240 KB/s. Pero… ¿cómo llegaron ahí? ¿Qué agradable duende del ancho de banda me los trajo? (No fue el gnomo, eso es seguro) Será que… nahhh… Axtel tiene problemas de mucho uso???

Se hacía chiquito…

Pues que me pongo a investigar. Hice una ligera “auditoría de seguridad” en las redes de los alrededores; supuse que podría identificar a mis vecinos con Axtel por el nombre de la red, la dirección IP pública, y el tipo de autenticación solicitada por el modem, si existe. Rápidamente encontré 3 aquí cerca (copiones). Estaba apenas apuntando nombres de red, cuando de pronto, oh tristeza… de vuelta a los 25 KBps. No, esto no podía quedar así.

Estaba de mal humor… el sysadmin.

Pues que saco la Alfa. Y que disparo el Beini. Un frontend de kismet a prueba de imbéciles (inserte broma acerca del autor aquí), me permitió en 15 minutos, como dicen los americanos, estar kicking ass and taking names. De redes, evidentemente. Efectivamente: uno de mis vecinos, en su eterna sabiduría, está descargando a lo baboso algún contenido (no, no me interesa investigar *qué* es). Lo estuve monitoreando por casi 2 horas; a punto de quedarme dormido, ví que su tráfico disminuyó. Y, sorpresa, mi monitor de tráfico subió de nuevo.

Un simple problema de recursos, evidentemente.

Pero algo sigue sin cuadrar: mi enlace, para aquellos que no lo conocen, es de 2 Mbps. 2 tristes megas. Y cuando alguien en la zona, con un enlace de 1 Mbps, comienza a descargar, esto me pasa? WTF, Axtel? Digo, somos 3 en una zona de como 16 cuadras (… cuadradas?). En serio, no somos muchos. CUando alguien se acapara tantito ancho de banda, esto pasa? Que servicio tan pinchurriento tienen, que un usuario le puede dar en la madre a todos los demás? Fuck, estoy no es cable! Y además, estamos hablando de 2 Mbps! Imagínense, si así se pone MI red, cómo se pondrá la del pobre tercero, o cuarto, con mi amigo el descargador y yo? Seguro que no pueden abrir ni Google.

No se vale, mis amigos. Cada vez me convenzo más que, para tener un enlace decente en este país, hay que estar dispuesto a pagar muuuucho dinero. Digo, si contrato un T3, seguro que no tengo estos problemas, verdad?

En fin. Mejor me consigo unas latitas y un cablecito…

Migración, v. 2.0: Nos vamos a Amazon!

Estaba yo bien tranquilo el fin de semana, trabajando, como dios Yopas manda… Ok, ok, me estaba rascando la panza, cuando jusafing me comentó que el servicio de EC2 (Elastic Cloud Computing) de Amazon, por alguna extraña razón, estaba siendo gratuito (con sus respectivas limitantes) para clientes nuevos. Interesado, traté de activarlo con mi cuenta existente, pero – oh sorpresa – me comenzaron a cobrar. $1.04 USD después, me desanimé (no queriendo crear otra cuenta en Amazon) y dejé las cosas hasta ahí, en parte porque había mucha chamba que sacar.

Pero hace un par de días se me ocurrió darle otro intento. Y esta vez… voilá! Sin problemas. Así que decidí empacar el itacate de sergiob.org y migrarlo a este nuevo servidor. Debo decir… funciona bastante bien. Al menos tan rápido (en procesamiento) como sergiob 2.0, y ciertamente con mucho mejor enlace de red (digo… mínimo, no? Está en la fucking cloud!) Así que… nos mudamos!

Beneficios inmediatos: mejor conexión de red, disponible en puerto 80 (y el puerto 800 todavía, por cuestiones de compatibilidad), mejor seguridad, menor costo (nulo, de hecho).

Beneficios a futuro: … déjenme pensarlo…

Desventajas: Pues nada, en realidad. Todavía conservo el viejo servidor, y lo tengo ruteado para usos (más) personales.

Algo que me preocupa es la privacidad de mis datos. Pero bueno, sergiob nunca ha tenido información confidencial, y no pienso comenzar ahora. Posiblemente mude este blog a un subdominio dentro de poco, pero no hay nada seguro aún.