WikiLeaks y Anonymous / Humor a la 1984

Hoy me encontré con esto en el twitter:

lol_wikileaks_anonymous_th(click en la imagen para verla de tamaño completo)

█████ ████ everything ███ █████ is█████ ████ fine ████ ███ ██████ love █████ █ your █ ████ government

…beware, big brother is watching!

Agile Tour Mérida 2011

¡El “Agile Tour 2011” en Mérida – Venezuela comienza a ser una realidad!

La organización del evento hasta ahora ha salido bastante bien, algún que otro inconveniente menor, propio de este tipo de eventos, pero poco a poco todo ha ido cayendo por su propio peso. En general, puedo decir que ha sido una experiencia bastante “ágil” y “divertida” (y todavía falta).

Como bono, ser parte del comité organizador me da la venia necesaria para incluir el logo del AT2011 en CodeCompiling:

at2011_OrganizerY a decir verdad, estoy pensando añadirlo de forma permanente en la parte derecha, al menos de aquí a finales octubre.

El afiche quedó bastante bien (¡Gracias a Nadia González por su excelente trabajo!) :

at2011_afiche_th

Aún falta incluir a los patrocinantes en el afiche, pero eso está planificado para mediados de septiembre, cuando tengamos ya los patrocinadores definitivos, antes de mandar la versión final a la imprenta.

El sitio WEB del evento es http://at2011.agiletour.org/en/merida.html , los interesados en asistir, bien como conferencistas o como participantes del Día Ágil y/o del Taller de Scrum Master, pueden acudir allí si desean más obtener información (¡yo ya reservé mi cupo para el taller!).

También estamos en proceso de enviar una carta / correo a distintas empresas y potenciales interesados:

Debido a unos problemas logísticos, a partir del 10 de Agosto aproximadamente nos hemos visto obligados a cambiar algunas de las condiciones del taller. A continuación se transcribe la nueva carta:


Estimados Colegas,

Es de nuestro agrado invitarles al Agile Tour 2011 Venezuela.

El evento tendrá sede en Mérida, en la Facultad de Ingeniería de la ULA, y comprende el Día Ágil de conferencias sobre métodos y experiencias ágiles de desarrollo de software, que se realizará el 26 de octubre, así como un taller Certificado de Scrum Master (CSM), dictado por Heitor Roriz (MSc / CST, http://massimus.com/ ), a realizarse los días 27 y 28 de octubre (16 horas).

El taller CSM es un taller oficial CERTIFICADO POR LA SCRUM ALLIANCE. Tras la finalización con éxito del taller y la aprobación del examen en línea correspondiente, cada participante será designado como Certified ScrumMaster. Esta certificación incluye dos años de registro en la Alianza Scrum. Para más información ver:

http://www.scrumalliance.org/pages/CSM

Los métodos de desarrollo de software están evolucionando hacia estrategias más livianas y flexibles, tomando más en cuenta el factor humano y sus aspectos de gestión, colaboración y motivación, entre otros. Todo esto está cambiando profundamente la forma de desarrollar software y la percepción que tenemos de esta industria, por lo que creemos importante que la industria nacional del software considere estos nuevos marcos de trabajo.

Reservaciones e información para ambos eventos por agiletourven@gmail.com

Más información en el sitio web del evento:
http://at2011.agiletour.org/en/merida.html

Twitter: @agiletourven

Nuestros patrocinantes:

Prototal
Biosoft /e-Praxis http://www.biosoftca.com
Otiesca http://www.otiesca.com
Postgrado en Computación ULA http://www.pgcomp.ula.ve
Vicerrectorado Administrativo ULA http://www.viceadministrativo.ula.ve

Atentamente,
El comité organizador.

PS: ¡Por favor difundir entre posibles interesados!

Además, con todo esto de la organización del AT2011, parece que me metí a spammer. Me explico, parte de las labores del comité organizador consisten en enviar la invitación al evento a un poco más de 1200 direcciones de correos, provenientes de una base de datos de (… opps, eso no lo puedo decir …).

En principio, el “comité organizador” en pleno iba a enviar los correos a mano, inclusive, teníamos la división del trabajo bien definida: del 0 al 300 fulano de tal, del 301 al 600 sutano, etc. En verdad no me motiva mucho enviar 300 correos a mano, de modo que se me ocurrió una solución alternativa.

Usando como base un poco de viejo código en Java, que hicimos para una aplicación WEB en Minotauro alrededor del 2005 y que era usado para enviar los correos de confirmación del registro de nuevos usuarios vía SMTP, desarrollé una forma automática de enviar la invitación a todas las direcciones de correo de la base de datos, todo esto tratando de no hacer saltar las alarmas de los detectores de spam, ni las de de mi proveedor de SMTP (gmail), ni las de los servidores de correo de los dominios objetivo (esto se puede lograr con las pausas adecuadas entre correo y correo).

¡Supongo que es mucho más divertido hacerlo de esta forma!

Debo decir que no me remuerde la conciencia, es decir, lo de que me convertí en spammer es evidentemente una broma: (1) Los correos son por una buena causa, libre de lucro y que seguramente en verdad le va a interesar a muchos de los destinatarios (espero) y (2) es un sólo correo por destinatario, es decir, no es que vaya a enviar todos los días un correo durante el próximo año.

Quizá en otra publicación escriba un poco más al respecto y hasta comparta el código fuente. Aunque la verdad, no se si sería hacerle el camino fácil a más de un spammer amateur.

¡Saludos y nos vemos en Mérida en el AT2011!

du | grep and regular expressions

I love regular expressions. I’m not an expert, and I’ve never devoted too much explicit effort to learn them, but little by little I’ve finally learned to use them. The key to this implicit learning is simple, if you have a problem that smells to regular expressions, then write one to solve it… Ah! add that eclipse search and replace dialog supports regexps, which comes very handy to make tests.

du_grep_find1

And also has a nice autocomplete feature:

du_grep_find2

This is the story of one of those regexps cases!

I’m a hard disk “free space eater”, so I was recently running low on disk space. This is common in computers I use, no matter how big my hard drives are, I always suffer of free space shortages. So, I was in the need to check how big some files and directories where in a given path in order to wisely delete some of them.

Easy? Think again. In your comfy Windows, Mac or Linux with Gnome/KDE equipped with a fancy file manager it may be an easy task. But in my hard and weird Fluxbox the task is not as straight/direct/fast as you might think.

Now, don’t get me wrong, from the point of view of many Gnome, KDE or other desktop users out there, I am probably using the crappiest desktop environment ever made (in fact, it’s just a window manager, not a desktop environment), and I’ve been told that. But let me say this as loud as I can: I just love it: It’s lightweight (lightweight enough to be compared to E16… good old times), clean, simple, etc. It just doesn’t get in the middle and does pretty well the work it has to do.

du_grep_fluxbox_th

I have not used Gnome for a long time, but with my Fluxbox install I don’t have to deal with menus, panels, and Gnome things that breaks leaving your session useless. The only things I need to survive are a few shortcuts to switch desktops, stick/unstick windows, launch terminals/shells and I’m done. I’m one of this “give me a terminal and I’ll rule the world” kind of guys! You think that’s crazy? Well, I have a friend that is even more crazy then… he even removed window’s borders and title bars. He handled windows completely with shortcuts! His motives where simple: “If I remove borders and title bars I’ll gain 10 to 15 extra pixels of screen”, he told me once.

So, trying to get back to the regexps topic: I don’t have a file manager in Fluxbox, so I don’t have a “right button->properties” to click on directories to check disk usage. Even worst: I don’t have a fancy GUI available to check how much disk space is being used by all the files and subdirectories contained inside a give directory. Though, if I think it better, I believe Gnome and KDE users don’t have one either. Now that I realize, I have something even better: I have the all mighty “du“, combined with the powerful “grep” command, which by the way supports regexps!

For those of you who don’t know about it, “du” (I think the command name comes from “Disk Usage”) is a nice program used to check the amount of disk used by a given directory (or by the current working directory by default). It generates reports like the following one:

248     ./model
140     ./src/view
212     ./src
3260    ./lib
48      ./bin/view
112     ./bin
1024    ./Make
284     ./ldraw/p/48
1480    ./ldraw/p
4640    ./ldraw/parts/s
40848   ./ldraw/parts
42332   ./ldraw
60280   .

The number at the left represents the bytes occupied by the files in the reported “leaf” folder in the given directory tree. The last line summarizes the bytes used by the given directory in the current working directory. It counts the space used by each subdirectory and the space used by all the files in the current directory.

Although the last “du” obtained example results interesting, it has two main problems / disadvantages:

1) I don’t understand numbers bytes, at least not when talking about disk space. I understand numbers in kilo, mega or giga bytes, but when you show me a number in bytes, specially a big one, I just don’t get it: Guilty, may be I can’t divide by 1000 (or by 1024 to be exact) as fast as you can.

2) I don’t care about the disk space used by each leaf. I’m only interested in the first level. I don’t want to know if I have to delete ./ldraw/p/48 directory, I need to know if I have to delete the whole ldraw directory because it’s using too much disk space. And I don’t want to manually add all the entries under the ldraw directory to find out what I need.

So, du has a few options that solves the stated problems, it’s possible to type:

du -h --max-depth=1

To get:

248K    ./model
212K    ./src
3.2M    ./lib
112K    ./bin
1K      ./Make
7.0M    ./.svn
42M     ./ldraw
59M     .

It’s much better now. Disk usage in each entry is reported in kilo, mega or giga bytes and the result only reports the disk usage under the top directories (but adding subdirectory usage), so you know that ldraw is the one here using too much disk space.

But what if you have a directory with a lot of subdirectories arranged in such a way that only a few of them use most of disk space, while the vast majority use just a few kilobytes? You are interested in locating the few entires that uses most of disk space (those that use megabytes or gigabytes) while ignoring those that use just a few kilobytes. There’s where grep [bold] enters the scene:

du -h –max-depth=1 | grep M

To get:

3.2M    ./lib
1K      ./Make
7.0M    ./.svn
42M     ./ldraw
59M     .

This way you will only get megabyte entries, but… but, the result it is not accurate enough, and that is exactly what I’ve been doing for a long time… until yesterday, when I chose to use regular expressions to get a better result.

The problem with the previous grep is that it will keep only the lines with an M, any M, anywhere. For example, the Make folder gets included in the result, despite the fact that it only uses 1K of disk space. So, in some cases we’ll get entries using kilobytes being reported because the directory name has a capital M somewhere.

How is this problem solved? With a little bit of regular expressions. First we realize that the result matches a pattern (aren’t regular expressions used to match patterns after all?): One or more numbers, then a dot (possibly), then one or more numbers, either a K, M or G letter (which are the ones we are interested in) and finally, whatever it comes: the spaces before the directory name, the directory name itself, etc.

That pattern can be this way “encoded” in a regular expression:

"([[:digit:]]|\.)+(K)(.)+"

So, grep [bold] can be used like in the previous example to check those lines using “megabytes” or using “gigabytes”:

du --max-depth=1 -h | grep -E "([[:digit:]]|\.)+(M)(.)+"

Or…

du --max-depth=1 -h | grep -E "([[:digit:]]|\.)+(G)(.)+"

The “-E” switch is used to enable extended regular expressions. By default, grep uses some kind of basic and very limited regular expressions (I don’t remember right now what are the limitations, so read the manual XD) and without the “-E” some features of the previous regular expression will just not work.

Also, if you want to show only entries using megabytes OR gigabytes, you can change the regular expression to include either Ms and Gs:

du --max-depth=1 -h | grep -E "([[:digit:]]|\.)+(G|M)(.)+"

If you’ve read this far, then you should have the feeling that regular expressions are something you should really know about. And like I said at the beginning, I believe it’s the kind of thing that you should learn little by little as you use it. Learn the basic concepts, the way they are used and what they are used for, and the next time you face the kind of problem where it would be useful to match / replace some string, then you can try to use a regular expressions approach.

At the beginning, there will be situations where it’ll take longer to solve a problem using regexps, than to do it using any other traditional way. But, you’ll sure be amazed with the elegance of the solutions. With enough time, you’ll learn to write better expressions and to do it very fast, so you will add a very powerful tool to your toolbox.

For example, since I started writing this article (which was not long ago), I’ve used regular expressions in at least two completely unrelated situations. The first one to remove leading blank spaces in a wrong indented PHP code using vi:

:%s/^    //g

notice four white-spaces between the ^ and the second /

and the other to do redirects and URL rewriting using mod_rewrite in a “.htaccess” file. Useful, isn’t it?