Impresiones sobre el taller de UML en el IUTET

El 16 y 17 de Noviembre del 2012 tuve el gusto de dictar un taller de UML a un grupo de profesores del IUTET (Instituto Universitario de Tecnología del Estado Trujillo).

UML, que significa en Inglés Unified Modeling Language (Lenguaje Unificado de Modelado en Español), es un lenguaje gráfico que se utiliza para modelar y representar aspectos técnicos y no técnicos de un sistema de software. Éste lenguaje, en esencia, permite que los desarrolladores de software puedan comunicar y documentar ideas y aspectos de diseño de un sistema de software.

El taller de UML, al que por cierto me gusta titular “UML Ilustrado”, principalmente por la cantidad de ejemplos que incorpora y su visión netamente práctica, es parte del trabajo de capacitación que venimos realizando dentro del contexto de Evolución Ágil, que es un proyecto / empresa en el que he estado trabajando desde finales del año pasado junto con Pablo Lischinsky y Elysabeth Guevara, y que tiene como objetivo brindar capacitación y consultoría en marcos de trabajo ágiles para la gestión de proyectos de desarrollo de software u otros productos.

UMLSlides_01_th UMLSlides_02_th UMLSlides_03_th

Ahora bien, dictar un curso de UML dentro de la concepción ágil, es un trabajo un tanto difícil. Esto se debe, principalmente a dos mitos asociados con la agilidad: 1) En el desarrollo ágil no se documenta (realidad: si se documenta) y 2) En el desarrollo ágil no se usa UML (realidad: si se puede usar UML, siempre y cuando se use de forma adecuada). A esto se le suma que si bien UML se tiende a asociar a procesos de desarrollo mucho más pesados tales como RUP, lo que hace que la audiencia que usualmente asiste a este tipo de talleres tienda a estar algo sesgada hacia procesos muy orientados al Waterfall y a una visión Big Design Up Front.

Todo esto me preocupaba un poco al momento de preparar e iniciar el taller, sobre todo porque en Evolución Ágil estamos decididos a mantener nuestro compromiso con la agilidad, pero para mi sorpresa, este sesgo no fue un impedimento en lo absoluto para introducir ideas y valores básicos de agilidad, sino todo lo contrario, fue una oportunidad increible para discutir, por contraste y utilizando UML como centro de todo, aspectos y valores importantes asociados a la agilidad.

Entre otras cosas, fue posible poner UML en su correcto lugar, es decir, no como la panacea que resuelve todos los problemas del diseño/desarrollo de software, que es lamentablemente lo que muchos desarrolladores aún hoy en día piensan, sino como una herramienta más de la caja de herramientas que tenemos a nuestra disposición y que bien utilizada puede ayudarnos a hacer mejor nuestro trabajo.

UMLTool_01_th UMLTool_02_th

Por ejemplo, el taller hizo mucho énfasis en ideas como las que propone Martin Fowler en su artículo “Is Design Dead?”, sobre todo en la sección titulada “UML and XP”, en las que se plantean cosas como que hay que hacer diagramas de UML cuando realmente son útiles, como forma de comunicar ciertas ideas, y que hay que invertir tiempo en mantener los diagramas actualizados siempre y cuando el equipo de desarrollo realmente los esté utilizando (y botarlos a la basura si el equipo de desarrollo no los usa). También pude introducir el concepto de “UML-itis”, que es básicamente esa equivocada necesidad que tienen muchos desarrolladores de hacer diagramas y más diagramas aún en situaciones en las que éstos no son necesarios.

UMLitis_01_th UMLitis_02_th

La recepción en el IUTET fue excelente, creo en verdad que los participantes del taller supieron aprovechar muchisimo el contenido, hubo mucha discusión y mucha interacción. Pocas veces como instructor se tiene una audiencia tan atenta e interesada como la que tuve en el IUTET, y todo esto, claro está, hace que dictar un taller sea muy agradable.

UML_grupo_IUTET_th

Finalmente, quisiera agradecer por la oportunidad y por el recibimiento a Doris Briceño y a José Quintero, ambos profesores del IUTET y que fueron mis anfitriones en Valera, así como también a Jose Mogollon por haberme ayudado a hacer el contacto. Espero en verdad regresar y poder tener nuevamente la oportunidad de ir al IUTET a dictar nuevamente éste u otro taller.

Edit:

La Profesora Doris Briceño muy gentilmente me envió la nota de prensa del curso:

curso_uml_th

RE: Academia e Ingeniería de Software

Nicolas Paez ha escrito un breve post sobre su percepción respecto a la forma en que se enseña Ingeniería de Software en distintas universidades en Latinoamérica. En lo personal, no he realizado investigación alguna al respecto en otras universidades (al menos no formalmente), y cualquier cosa que pueda decir se suscribe por lo pronto, únicamente a mi experiencia y a la forma en que enseñamos Ingeniería de Software en la Universidad de los Andes (ULA), en Venezuela.

En nuestro caso, estamos en el extremo de dictar una sola materia de Ingeniería de Software para toda la carrera. El programa de la asignatura se resume de forma muy general en la siguiente figura:

re_nicolas_map_is

El curso tiene una carga horaria de 6 horas de clase a la semana, de las cuales 4 son “teóricas” y 2 son “prácticas” y se dicta en un total de 16 semanas. Como ven, son 16 semanas en las que si nos remitimos al programa hay que cubrir bastante contenido (debo decir que es un curso bastante agotador, sobre todo si se quiere dictar bien).

Personalmente estoy un poco inconforme con el hecho de que haya una sola asignatura de Ingeniería de Software, y sinceramente creo que la carrera podría beneficiarse mucho si se separase la asignatura al menos en otras dos: Arquitectura de Software por un lado e Ingeniería de Software por el otro. Esto liberaría un poco la presión y el exceso de contenido que tiene la materia actualmente y permitiría profundizar un poco más en algunos temas, y en especial, en algunos aspectos prácticos.

Como se puede apreciar, desde el punto de vista del post de Nicolas, en la ULA estamos mucho más cerca del grupo de “una materia por carrera” (como en la UNQ) que del grupo de “varias materias por carrera” (como es en el caso de la UBA).

Sin embargo, es importante decir que en la ULA ofrecemos una carrera de de Ingeniería en Sistemas, y no una carrera de Ingeniería Informática como sucede en la UBA. La Ingeniería en Sistemas es… bueno, una definición de qué es la Ingeniería en Sistemas (y más importante aún, qué no es) merece otro post completo, pero hay que decir que no sólo nos dedicamos a desarrollar software, sino que también hacemos otras cosas. Somos una escuela formada por tres departamentos (Control, Computación e Investigación de Operaciones) en la que se dicta un extraño híbrido entre varios de los perfiles en computación de la IEEE-ACM, mezclado con Control de Procesos, un poco de Automatización, etc.

Mi visión concreta respecto a lo que plantea Nicolas es muy simple: En la primera clase siempre le muestro a mis estudiantes esta transparencia:

re_nicolas_clase_01_presentacion

Y posiblemente el punto debería ser aún más pequeño de lo que en actualmente es. La pregunta ¿qué representa el rectángulo verde y el punto negro? usualmente flota en el aire por un rato, y hasta ahora, nunca he conseguido que alguien, más que responder, adivine la intención oculta detrás de la interrogante (aunque muchos estudiantes lo han intentado).

La respuesta es simple: El rectángulo representa todo lo que se puede saber sobre Ingeniería/Desarrollo de Software, el punto negro, lo que podemos cubrir en este curso. La idea fundamental detrás de esta pregunta es mostrar lo verdaderamente abismal de todo lo que en efecto NO se puede cubrir durante el curso.

La lámina anterior resume lo que pienso sobre la enseñanza de la Ingeniería de Software hoy en día: Simplemente no podemos enseñar/transmitir a los estudiantes todos los conocimientos teóricos que necesitan para afrontar todos los problemas que se van a encontrar en sus carreras profesionales. Lo que si podemos (y debemos) es formar criterio, suficiente para que nuestros estudiantes puedan aprender luego por sí mismos y enfrentar nuevas situaciones según sea el caso. Esto es particularmente cierto en una ingeniería tan dinámica como la nuestra, y también tan subjetiva, en la que muchas cosas y conceptos dependen de la dirección desde la que se las vea, o tal como lo dice Martin Fowler, refiriéndose en este caso puntual al término “arquitecto” y luego generalizándolo casi a cualquier cosa:

“In software, the term architect means many things. (In software any term means many things)”

…o peor aún, como me gusta decir a mis estudiantes, en Ingeniería de Software, dados dos puntos de vista diametralmente opuestos, simplemente “escojan un bando, pero eso si, argumenten bien el porqué de la elección”.

Finalmente, me gustaría también aportar un poco más que sólo el feedback que solicitó Nicolas en su post. Me gustaría hablar sobre las distintas formas en que hasta los momentos he dictado la asignatura.

No se hasta que punto mis estudiantes se dan cuenta de esto, pero he hecho unos cuantos experimentos durante las distintas instancias del curso a lo largo de los últimos cuatro años. Algunos han salido bien, otros muy bien, y otros casi se convierten en desastres totales (bueno, quizá no tanto). Simplificando un poco, he dictado la materia usando tres enfoques distintos: el teórico clásico (y aburrido) en el que se dicta un curso lleno de contenido, el práctico utilizando cascada y el práctico utilizando métodos ágiles. También he integrado el curso de Ingeniería de Software con el curso de Bases de Datos, y hasta hay un artículo que está por publicarse al respecto, pero eso ya es harina de otro costal.

Con el enfoque ágil, he usado distintos sabores de Scrum (ScrumBut dirán algunos, y probablemente tendrán razón), tratando más que nada de adaptar Scrum al contexto “muy a medio tiempo” de un curso de Ingeniería de Software, en el que los estudiantes son compartidos generalmente con otras cuatro materias, además de otros obstáculos que no vienen al caso. En este sentido he hecho algunos avances importantes y voy refinando la técnica semestre a semestre.

Sobre el punto de vista “teórico versus práctico”, para mi la respuesta es evidente: la visión práctica siempre gana. Tengo la firme creencia de que la Ingeniería de Software es algo que se debe enseñar/aprender de forma práctica, de modo que eso es exactamente lo que hago con mis estudiantes de pre-grado: Utilizar la estrategia RAIS para desarrollar productos. Además, de quedarme solamente con el enfoque teórico, es muy probable que me hubiese aburrido hace rato, después de todo, no hay nada mejor que hacer productos interesantes en el salón de clase.

El otro punto de contraste es ágil versus cascada. Aquí debo decir que me ha ido bien con ambos enfoques, pero me ha ido mucho mejor con el enfoque ágil, que es el que utilizo actualmente. Desde el punto de vista académico creo que las dos visiones tienen ventajas y desventajas. Ágil por un lado permite comenzar a desarrollar casi desde el día uno, cascada no. Por lo antes mencionado, ágil permite desarrollar productos más ambiciosos que con cascada, porque usualmente hay más tiempo dedicado a la programación, a aprender las nuevas tecnologías y técnicas necesarias para desarrollar el producto de turno, etc.

Ahora bien, dependiendo del punto de vista, una de las desventajas de ágil es que pareciera que permite ejercitar menos algunos aspectos más formales del contenido del curso, cosa que si es posible hacer con cascada… quizá ha sido una falla mía, pero por lo pronto esa es la impresión que tengo. Por otra parte, ágil permite hacer algo que considero bueno: ejercitar algunos valores y principios fundamentales para desarrollar software, y con los que particularmente me siento muy identificado, así como enseñar la importancia de generar productos funcionando en lugar de producir pilas de papeles (usualmente inútiles desde mi punto de vista).

En resumen, y por los momentos, hasta ahora me quedo con la visión ágil en mis cursos de Ingeniería de Software.

Lego Models (LDraw) Loaded from Java

Back in 2007 I step on LDraw and MLCAD WEB sites. For someone like me, who played a lot with Lego during his childhood, LDraw and MLCAD are/were certainly an incommensurable source of joy.

I found those WEB sites just before Christmas vacation so I raged to build in MLCAD many of the Lego models I had when I was a child.

By then I was also doing some small work on 3D graphics programming, using mostly Java3D and JOGL, so I developed a small piece of software intended to load LDraw models from Java. The following is a video of that software, showing some of the Lego models I build that Christmas:

Recently, I got a request to write a video explaining how to run the software (I have to admit that there isn’t a tutorial, and it’s not exactly easy to run it). So here goes the tutorial.

First, import the code from the SVN repository (I will not detail this, you’ll have to figure it out). The source code can be found here:

http://code.google.com/p/foo-org-ve/

You will need to get the Lego project. I use Eclipse, so the project is already configured to run in Eclipse.

After importing the project, you should try to run the class view.Main. It will probably not run at first, so you will find in front of this exception:

java.lang.NullPointerException
  at view.Main.display(Main.java:112)
  at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
  at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:281)
  at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
  at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:298)
  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
  at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
  at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
  at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
  at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
  at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

This is because you don’t have the ldraw parts and the models in the right place. To solve it you have to uncompress the files ldraw.tar.gz and model.tar.gz located in the root of the project.

That way you will end with two additional directories in project root: ldraw and model.

Go back to eclipse and refresh the project: select the project Lego and hit F5, or select the project and ”right click->refresh”.

Then go again to view.Main and change the part:

// ***************************************
// XXX: Change according the real location
private static final String ldraw_base = "/home/dmi/workspace/Lego/ldraw"; // LDraw home
private static final String model_base = "/home/dmi/workspace/Lego/model"; // Where to the models to be displayed
// ***************************************

Set the path “/home/dmi/workspace/Lego/XXX” in both entries according to the location of the project root. If you just uncompressed the ldraw and model gz files in the project root left the last part unchanged, if you put the files anywhere else change the route accordingly.

Then, in the same file, go to the part with the models (I only show a few, but you should see a lot of commented similar lines:

part = partLoader.loadPart("1499-1.mpd");  // Medium twin seat spaceship
//part = partLoader.loadPart("885-1.mpd");   // Very small spaceship (5)
//part = partLoader.loadPart("487-1.mpd");   // Medium Ship with deployable car
//part = partLoader.loadPart("6804-1.mpd");  // Very small car (2)
//part = partLoader.loadPart("6807-1.mpd");  // Very (very) small spaceship with robot

And uncomment one line (you can uncomment as many as you want, but it should display the last one). If every thing goes well you should see something like:

Lego_th

You can add your own models in the model directory and then add the appropriate line there to load it.

If you run it and find this exception:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no jogl_drihack in java.library.path
  at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1734)
  at java.lang.Runtime.loadLibrary0(Runtime.java:823)
  at java.lang.System.loadLibrary(System.java:1028)
  at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:78)
  at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:101)
  at com.sun.opengl.impl.NativeLibLoader.access$100(NativeLibLoader.java:47)
  at com.sun.opengl.impl.NativeLibLoader$3.run(NativeLibLoader.java:141)
  at java.security.AccessController.doPrivileged(Native Method)
  at com.sun.opengl.impl.NativeLibLoader.loadDRIHack(NativeLibLoader.java:139)
  at com.sun.opengl.impl.x11.DRIHack.begin(DRIHack.java:105)
  at com.sun.opengl.impl.x11.X11GLDrawableFactory.(X11GLDrawableFactory.java:66)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:169)
  at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:111)
  at javax.media.opengl.GLCanvas.(GLCanvas.java:113)
  at javax.media.opengl.GLCanvas.(GLCanvas.java:82)
  at javax.media.opengl.GLCanvas.(GLCanvas.java:75)
  at view.Main.main(Main.java:240)

It’s because java is not finding JOGL binary libraries. Here you have two options:

  • Add the libraries in a place where they can be found by default. For example, in Linux add them in /usr/lib (or /usr/local/lib) and then run ldconfig. In windows add them in “C:\windows\system32” (I’ve not been windows user for a long time, so find yourself the right place if it does not work). Note that this option will require root access in Linux.
  • Another option is to go in eclipse to the “Run Configurations” and manually set up the library path. To go to “Run Configurations”, pull the run button (don’t click the button, just the tiny arrow besides the button) -> Run Configurations” -> Main”. Main is the name of the “view.Main” executable class. Then go to Arguments -> VM Arguments, and add:
-Djava.library.path=/home/dmi/workspace/Lego

Change “/home/dmi/workspace/Lego” according to your set up.

RunConfiguration1

RunConfiguration2_th

The JOGL binary libraries are included in the root of the project, the files are:

-rw-r--r-- 1 dmi dmi   20480 2012-05-20 16:51 jogl_awt.dll
-rw-r--r-- 1 dmi dmi  114688 2012-05-20 16:52 jogl_cg.dll
-rw-r--r-- 1 dmi dmi  290816 2012-05-20 16:51 jogl.dll
-rw-r--r-- 1 dmi dmi   10107 2012-05-20 16:51 libjogl_awt.so
-rw-r--r-- 1 dmi dmi  185584 2012-05-20 16:51 libjogl_cg.so
-rw-r--r-- 1 dmi dmi    6421 2012-05-20 16:51 libjogl_drihack.so
-rw-r--r-- 1 dmi dmi  962937 2012-05-20 16:51 libjogl.so

The *.so files are for Linux, the *.dll files are for Windows.

If you are using any other IDE instead of Eclipse, or you want to run from the console, or make a jar, etc, you will have to figure it our by yourself, but given this tutorial it should not be difficult. For example, I can run it directly from the console with the commands:

$ > export LD_LIBRARY_PATH=/home/dmi/workspace/Lego/
$ > java -cp bin/:lib/jogl.jar:lib/commons-logging-1.1.jar:lib/commons-lang-2.1.jar view.Main

I wrote the code in 2007 and even then I was using an old version of JOGL (Don’t ask why). A good contribution would be to migrate it to use a newer version of JOGL. Also, considering what I’ve learn since then about software and 3D graphics, I think the code could be probably improved a lot.

Also there is a known bug with transparency. If you use transparent Lego pieces, it’s possible that something behind them would not display correctly. This is because transparency (using depth buffer) requires to draw all transparent geometry after drawing non transparent geometry (on top of non transparent geometry). Currently the code is not doing this, so if any object behind a transparent window is drawn after the window, it will just not been drawn, because it will be behind the window and depth buffer will prevent it from being drawn. One solution would be to detect the transparent objects and add them to a list instead of drawing them, and at the end, draw them after all the non transparent objects.

Relating to the license of the code, basically you can do whatever you want with it. I only ask two things: 1) If you use it, change it, blog about it, or do anything else with it, please mention me as the original author and link back to this post. 2) If you make any changes, improvements, convert it to a library, etc, I would like to know it and have the possibility to add those changes to the original project.

UPDATE

Kevin Loddewykx has contributed a great update to the project. I’ll let his changelog speak for itself:

Update for project “Lego”
1) Uses the most recent version of jogl + gleugen and log4j 1.2
2) Uses the most recent version of ldraw parts library and ldconfig.ldr

ENHANCEMENTS :
3) Camera rotates now instead of the object
4) Model can be given through the command line
5) Pressing R will now change the model when it is changed in the code, when you
are real-time debugging

BUG FIXES :
6) Transparency has been updated, so transparent objects always will be rendered
last
7) Previous when more then one model was uncommented, it’s was possible that
models would get mixed up.

MISC :
8) Extra model added train.ldr :)

The transparency fix is especially important, the following picture shows the bug:

screen_lego_wrong

And the following picture shows the same model after Kevin’s fix:

screen_lego_OK

Thanks a lot Kevin for the update, it works like a charm :)

Compañías y Productos RAIS en el A2011 (conclusión)

Hace algún tiempo escribí sobre los productos que se iban a desarrollar en las asignaturas de Ingeniería de Software y Bases de Datos durante el semestre A2011 utilizando la estrategia RAIS. El A2011 terminó y los productos se desarrollaron (o casi). Me gustaría compartir los resultados, que en general, fueron bastante buenos.

MagicRoot

MagicRoot es un juego de cartas multi-jugador, y también, es el nombre de la compañía RAIS que lo desarrolló. El objetivo del juego es vencer al oponente utilizando cartas mágicas que representan los distintos elementos: Aire, Agua, Fuego y Tierra. La idea está basada en Triple Triad que es un mini-juego de Final Fantasy VIII (Espero que no nos demanden ;-).

El juego fue implementado en Java usando una arquitectura cliente-servidor. La interfaz de usuario está implementada en Swing. El servidor y el esquema de comunicación cliente-servidor implementan una arquitectura muy desacoplada y estructurada, que incluye el uso de varios patrones de diseño y que gestiona la lógica y los estados del juego utilizando una máquina de estados implementada de forma explícita. Sobre éste último punto tengo mucho que decir, e inclusive hay un trabajo de tesis en curso, pero eso es parte de otra historia. La capa de persistencia está implementada con Hibernate como ORM y MySQL como base de datos.

El código fuente de la aplicación se puede encontrar en:

http://code.google.com/p/magicroot

Sobre MagicRoot y su producto hay que decir dos cosas:

1.- La propuesta inicial del juego no me gustaba (debo admitirlo). Aquí, como Jefe Ejecutivo RAIS, es necesario tener fe en la gente con la que se trabaja. Lo que tenía en frente al principio del semestre eran cuatro “Ingenieros RAIS”, muy motivados con una idea clara entre manos. Esa motivación para mi fue suficiente para decidir que el producto era viable, aún cuando en lo personal no estaba completamente seguro.

2.- La propuesta inicial era técnicamente compleja. He desarrollado este tipo de aplicaciones, dado consultorías al respecto y conozco la complejidad del problema: Cliente gráfico, múltiples hilos del lado del cliente y del servidor, comunicación por sockets, protocolo de comunicación, lógica y reglas del juego complejas, máquinas de estado, Hibernate, etc. Esta complejidad añade algo de riesgo, y he visto más de un equipo de desarrollo empantanarse en tales condiciones. Esto me preocupaba mucho, tomando en cuenta que no conocía bien las capacidades técnicas o la madurez del grupo de programadores que tenía en frente.

A algunos desarrolladores de software experimentados el proyecto quizá les pueda parecer algo trivial, pero tomen en cuenta que el trabajo se debe hacer en 4 meses (o menos) a tiempo parcial y que estamos hablando de estudiantes del 7mo semestre que nunca han programado en Java y mucho menos conocen muchas de las tecnologías utilizadas.

Desde el punto de vista de RAIS, en el caso de los cursos de IS y BD, una estrategia que ha funcionado para manejar la complejidad de un producto es que al inicio del curso todos los integrantes de una compañía conozcan el nivel de dificultad y los riesgos presentes en el producto al que se enfrentan.

Me tomo muy en serio esto, explico los riesgos, el volumen de trabajo, los retos y capacidades técnicas necesarias, y me aseguro de que todos los integrantes de la compañía sepan en qué problema se están metiendo. Si hay algún aspecto del producto que desconozco (cosa que sucede con cierta frecuencia) lo digo directamente y sin rodeos, es decir, puedo estimar, hacer comentarios, tratar de adivinar, aconsejar, etcétera, pero soy muy claro de que se trata de un riesgo y no doy falsa confianza sobre algo que en el fondo no conozco y se sale de mi control.

Luego dejo que tomen la decisión por ellos mismos, y si desean cambiar de producto, no hay problema. Esto último también se deja bien claro, y es parte de mi visión particular con RAIS, yo como Jefe Ejecutivo puedo aconsejar y ayudar, pero las decisiones finalmente las toman las compañías de forma voluntaria.

Afortunadamente, los ingenieros de MagicRoot decidieron seguir adelante con el producto, aún después de conocer la complejidad y las dificultades a las que se enfrentaban. Debo decir que esa fue una verdadera demostración de coraje que siempre admiraré.

El resultado no sólo cumplió con las expectativas que tenía, sino que las superó. En verdad MagicRoot fue un producto espectacular, con una arquitectura muy sólida, muy fácil de mantener y manejar, que les permitía arreglar bugs y hacer cambios y ajustes en las reglas del juego muy fácilmente.

Como nota curiosa, los integrantes de MagicRoot cursaron Inteligencia Artificial el semestre siguiente e implementaron la inteligencia del juego, es decir, hicieron que fuese posible también jugar contra la computadora y no sólo contra la otra persona.

El equipo de MagicRoot está compuesto por:

Rafael Solórzano (Gerente), César Vielma, Andres Zamora y Jesus Daniel Garcia.

Mentes en Guerra

Mentes en Guerra, desarrollado por CodeSolids, es un juego de batalla multi-jugador en el que los jugadores pueden crear personajes, combatir con otros personajes de otros jugadores, ganar puntos, aumentar de nivel y comprar equipamiento para mejorar a su personaje.

El juego es una aplicación WEB desarrollada en Java, utilizando Echo3 para la interfaz de usuario, Hibernate como ORM y MySQL como base de datos.

Esta compañía llevó el uso de Echo3 al extremo, y hay cosas que, desde el punto de vista visual si bien imagino como están hechas, en el fondo no tengo una idea clara de como las implementaron. En especial resulta interesante ver la parte de la batalla, en la que los personajes efectivamente tienen animaciones, se mueven y atacan a los otros personajes.

El código fuente de la aplicación se puede encontrar en:

http://code.google.com/p/codesolids-project

Es interesante mencionar que Mentes en Guerra fue uno de los últimos productos que se desarrollaron bajo el concepto de aplicación WEB implementada con Echo3, ya que, pareciera que después de MagicRoot, todas las compañías de los cursos siguientes han querido desarrollar únicamente aplicaciones en Swing.

En general, CodeSolids fue un grupo bueno, la compañía no tuvo ningún problema serio a lo largo del semestre y avanzó bastante bien. Quizá cerca del final sentí cierta preocupación y cierto retraso en el desarrollo del producto, pero finalmente todo salió bien, entregaron un buen producto, que funciona y satisface (mucho) las expectativas.

El equipo de CodeSolids está compuesto por:

José Luis Pérez (Gerente), Antonio Lopez, Karla Moreno, Fernando Osuna y Hector Prada.

Greed Treasure

No todo salió completamente bien en el A2011, de las tres compañías, una de ellas, Thinking & Looking, fracasó rotunda y estrepitosamente.

El fracaso de Thinking & Looking fue doloroso. ¿La razón? El producto que decidieron desarrollar me importaba mucho, era una idea original que realmente quería ver funcionando, al menos a nivel de prototipo o prueba de concepto.

¿Por qué fracasó la compañía? Tengo una teoría (bueno, quizá varias teorías a decir verdad), pero aún así es difícil estar completamente seguro. En mi opinión los factores más importantes fueron:

1.- Falta de liderazgo: El fracaso está asegurado sin un liderazgo fuerte, que logre darle coherencia y sentido a la compañía (y al producto), y sobre todo, que logre dar buenos ejemplos de trabajo al resto del grupo. En este caso, en mi opinión, el gerente no supo aprovechar el equipo de trabajo del cual formaba parte, no supo motivar al equipo y lograr que trabajaran de forma conjunta.

2.- Falta de compromiso de los ingenieros con la compañía y el producto: Esta es la otra cara de la moneda del punto anterior. Creo que hubo mucha, pero muchísima, falta de compromiso. Un buen liderazgo debería crear ese compromiso, pero no toda la responsabilidad debe pesar sobre el gerente de la compañía.

Si el gerente no puede sacar a flote a su grupo, alguien dentro de la compañía debería asumir esa responsabilidad y lograr que el equipo salga adelante, esto ha ocurrido en otros casos y en otras compañías. Sin embargo esto no sucedió en Thinking & Looking. Todos los ingenieros simplemente se limitaron a hacer lo mínimo que se les pedía y no pudieron salir adelante, no hubo un liderazgo emergente, y de hecho, fue bastante triste verlos al final del semestre buscando la forma de culparse mutuamente.

3.- Problemas de comunicación, coordinación, colaboración y trabajo en equipo: Thinking & Looking tenían el balance adecuado de destrezas y capacidades técnicas, pero en mi opinión simplemente no supieron aprovechar esta fortaleza. Es decir, reunieron un conjunto interesante de talentos individuales, pero nunca lograr en verdad “formar” una compañía. El punto anterior también forma parte de esto último.

4.- No se puede culpar del fracaso al producto: El producto tenía requisitos muy claros y bien definidos, no era excesivamente complejo y no tenía riesgos técnicos serios. El riesgo técnico más fuerte, que era dibujar e interactuar con un mapa estaba ya controlado, a nivel de prototipo y de trabajos hechos en el semestre anterior.

No voy a mencionar los nombres de los integrantes de Thinking & Looking, en mi opinión ya bastante problemas tuvieron tratando de sobrevivir al A2011, de modo que les voy a dejar en el anonimato.

De los tres productos del A2011, dos fueron en mi opinión un éxito rotundo. Aún con el doloroso fracaso de Thinking & Looking creo que fue un buen semestre en el que se obtuvieron excelentes resultados. Inclusive puedo decir que aprendí mucho del fracaso de Thinking & Looking, y que espero ahora poder detectar e intervenir esas “compañías patológicas” con el tiempo suficiente como para poder resolver el problema, e inclusive, desarrollar políticas de organización de compañías que eviten que este tipo de desastres vuelvan a ocurrir.

¡Hasta la próxima experiencia RAIS! :-)

¿Qué se puede mejorar en estas pantallas de Gmail?

Hoy me topé con lo que en mi opinión es una pequeña falla de usabilidad en GMail. Es curioso ver que hasta Google se equivoca de tanto en tanto en cuestiones de usabilidad.

Aquí les dejo el acertijo (al menos para mis estudiantes de Ingeniería de Software). Los voy a dejar mirar las pantallas por un rato a ver si pueden descubrir el problema. Luego, en unos días, escribo mi opinión.

La primera pantalla (click para agrandar):

gmail1_th

Muestra la interfaz que se ve luego de que se hace click en “compose” para escribir un nuevo correo y justo antes de enviar el correo. Es decir, click en “compose”, se escribe el nuevo correo y luego se tendría que hacer click en “send” para enviar el correo.

La segunda pantalla:

gmail2_th

Muestra lo que aparece al abrir un correo y hacer click en “reply” para contestar. Es decir, se selecciona un correo del inbox, se hace click en “reply”, se escribe la respuesta y luego se tendría que hacer click en “send” para enviar el correo.

Puede que entre ambas pantallas exista más de un problema, pero en mi opinión hay uno que muy contundente que se puede argumentar de forma muy sólida. De hecho, este problema ya me ha hecho equivocarme al menos un par de veces, por suerte, sin consecuencias graves.

¿Puede usted, estimado lector, encontrar y argumentar el problema?

Como ya dije, voy a dejar pensar un rato a mis estudiantes de IS, y dependiendo de lo que pase, en unos días edito este post (o publico otro) describiendo el problema.

Por cierto, ayuda tratar de abrir las pantallas en GMail, no sólo ver las imágenes anteriores.

Richard Stallman, Chuck Norris and Octave… Seriously?

The other night I was coding in Octave. I required to calculate a factorial and I had no clue of the function name used to do it… so I guessed:

I typed “fact” … and got:

octave:1> fact

Richard Stallman knows of an unfixed bug in TeX.

Well, this was the daily WTF for me. So I asked for help:

octave:2> help fact
`fact’ is a function from the file /usr/local/octave-3.6.1/share/octave/3.6.1/m/miscellaneous/fact.m

— Command: fact
— Function File: T = fact()
Display an amazing and random fact about the world’s greatest
hacker.

…bla bla bla…

Mmmmm, “Display an amazing and random fact about the world’s greatest hacker?”

So I tried again:

octave:3> fact

Richard Stallman does not own a mobile phone because he can fashion a crude convex dish and shout into it at the exact resonant frequency of the ozone, causing a voice to seemingly come from the sky above his intended recipient.

That was really funny, so I did it again, and again:

octave:4> fact

kill -9 invokes Richard Stallman’s rage against a process.

octave:5> fact

The NOOP was created to give Richard Stallman some time to comb his beard.

octave:6> fact

Richard Stallman gets 9 bits to the byte.

octave:7> fact

Richard Stallman’s left and right hands are named “(” and “)”

octave:8> fact

Richard Stallman user GNU tar to compress air.

octave:9> fact

Richard Stallman wrote his own library and lives in it.

octave:10> fact

Richard Stallman’s DNA includes debugging symbols. But he doesn’t need them.

octave:11> fact

Richard Stallman doesn’t code; he dares the computer to not do his bidding.

octave:12> fact

Richard Stallman’s anti-virus programs cures HIV.

octave:13> fact

In an average living room there are 1,242 objects Richard Stallman could use to write an OS, including the room itself.

At this point I remembered where I have heard this kind of short phrases before: It’s a Richard Stallman geek version of the famous Chuck Norris Jokes!

I kept trying for a while and got:

octave:14> fact

Richard Stallman found Waldo using grep in /dev/null

octave:15> fact

Richard Stallman doesn’t like neither PCs-Intel nor Burger King… He prefers e-Macs…

octave:16> fact

Richard Stallman was coded by himself in lisp with Emacs.

octave:17> fact

There is no Windows in Richard Stallman’s house… only Doors…

octave:18> fact

Richard Stallman’s compiler is afraid to report errors.

The lisp reference and the last one where really hilarious…

By the way, factorial is calculated in Octave with “factorial” function, for example:

octave:19> factorial(5)
ans = 120

And what I really needed was to calculate nCk or n choose k, which is calculated using “nchoosek”:

octave:20> nchoosek(4, 2)
ans = 6

Enjoy the nice Stallman’s Octave Easter Egg :)

El bueno, el malo… y SOPA

Vamos a dejar algo claro de entrada: Desde mi punto de vista SOPA es una barbaridad, y una barbaridad del tamaño de una casa.

Siempre he estado y siempre estaré a favor del conocimiento abierto y del libre flujo de la información, siempre estaré en contra de las patentes y del concepto de “propiedad intelectual” tal y como lo conocemos en esta Orweliana época nuestra. Soy de los que creen que para que la humanidad pueda evolucionar a un siguiente nivel es necesario abolir primero esas viejas y absurdas estructuras, para luego buscar formas alternativas de hacer las cosas. Claro que las viejas y oxidadas estructuras se van a resistir a morir…

Quiero dejar claro de entrada mi punto de vista porque estoy por explorar algunos escenarios un tanto retorcidos en relación a SOPA, de modo que no quiero que alguien malinterprete el texto que sigue. Ante la duda sobre cual es mi posición, ruego se vuelvan a leer el primer y el segundo párrafo de este artículo.

Ahora bien, especulando un poco: ¿Qué tal si después de todo SOPA fuera algo bueno y no algo tan malo como creemos? ¡Exacto, no leyeron mal, no es necesario que vuelvan a leer la frase!

A decir verdad tengo varios días refinando esta idea de forma subconsciente, pero no fue sino hasta hoy que me topé con una excelente infografía sobre el asunto, que finalmente terminé de refinar algunas de las ideas que elaboraré más adelante.

—o—

Antes que nada, voy a hablar un poco sobre SOPA, espero poder hacer un breve (aunque seguramente incompleto) resumen sobre el tema. La siguiente explicación procura ser lo más básica posible, y es en parte el resultado de una conversación en la que una persona mayor me preguntó de que se trataba todo el asunto. Cabe destacar que si bien esta persona es usuaria de Internet, no sabe aún mucho de computadoras o de redes, así que fue necesario apelar a todos mis recursos didácticos para explicar de que se trataba la legislación y cuales eran sus implicaciones.

Aquellos que ya saben lo que es SOPA, pueden simplemente saltar hasta la sección donde expreso las razones por las que SOPA puede en el fondo llegar a ser algo bueno, aquellos que aún no saben lo que es SOPA, sigan leyendo.

—o—

Citando la infografía antes mencionada, SOPA es:

SOPA1_546

La excusa, claro está es “la piratería”, lo que de alguna forma nos regresa al primer párrafo sobre el libre acceso al conocimiento, pero lo grave de esta ley es que en el fondo permite establecer mecanismos de censura a diestra y siniestra, todo claro está, con la excusa de la piratería o de la violación de la propiedad intelectual.

En pocas palabras, por medio de SOPA, es posible en/desde los Estados Unidos sacar un sitio WEB fuera de línea, sin una demanda, un debido proceso, etc. SOPA es al fin y al cabo un mecanismo para censurar el Internet tal y como lo conocemos. ¡La verdad que entre esto y la NDAA 2012 creo que los norteamericanos definitivamente se volvieron locos!

La pregunta que quizá algunos se pueden estar haciendo es: Si yo vivo fuera de los EUA ¿Cómo me afecta una ley de los EUA? Bueno, resulta que el problema es que, al fin y al cabo, el Internet no está tan “descentralizado” y no es tan libre y democrático como muchos creen.

SOPA3_546

Para poder explicar esto es necesario entender que puede hacer el gobierno americano por medio de SOPA, y aquí, apelo nuevamente a la infografía que ya he mencionado y que en parte inspiró este artículo:

SOPA2A_546

Si el lector sabe algo sobre cómo funciona Internet, entonces en este punto ya habrá comprendido la gravedad del asunto, y nuevamente, proveo un enlace para ir a mis ideas finales al respecto… Sin embargo, voy a elaborar algunos detalles para quienes no conozcan el funcionamiento básico de Internet. Debo aclarar que es una explicación superficial diseñada para personas que no saben mucho del asunto (¡geeks por favor ahorrarse los tecnicismos!).

—o—

SOPA para legos

El punto (1) de la imagen anterior (a la que me referiré mucho de ahora en adelante), implica que los usuarios de Internet no van a poder acceder a algunos/muchos de sus sitios WEB favoritos, simplemente escribiendo el nombre del sitio en la barra de direcciones del navegador. Cada vez que alguien escribe el nombre de un sitio como “www.wikipedia.com” en un navegador, hay un servicio llamado DNS (Domain Name System), que traduce ese nombre “fácil de recordar” a un número especial (no tan fácil de recordar), que finalmente permite localizar el servidor que le entrega la información al navegador para que éste despliegue el sitio WEB correspondiente. Este número especial se llama dirección IP, y en IPv4 es algo como 134.153.104.98.

tpb_ip_nm_546

(click en la imagen para agrandarla)

Esto por cierto no es completamente cierto en todos los casos, y es posible que muchos sitios no funcionen directamente sólo escribiendo el IP en el navegador. Pero para explicar esto tendría que entrar en más detalles técnicos de los que quiero dar en este momento.

Una forma de ilustrar todo el proceso de “traducción” nombre->número ya descrito es haciendo una analogía con los números telefónicos y las guías telefónicas (o las agendas telefónicas). La gente simplemente no se sabe de memoria el número de teléfono de sus amigos y contactos, es mucho más fácil memorizar el nombre de alguien y cada vez que se necesita llamar a esa persona simplemente se consulta la guía telefónica o la agenda, que está diseñada para que sea fácil buscar un contacto por nombre o apellido, para así obtener el número telefónico correspondiente.

En Internet ocurre lo mismo: Es más simple memorizar algo como www.wikipedia.org (nombre de un contacto o de un amigo) para que el navegador por medio de un servicio DNS obtenga la dirección IP correspondiente (teléfono), que tener que memorizar las direcciones IP (teléfonos) de los sitios WEB que uno quiere visitar.

¿bueno, y que? dirá el lector…

Resulta que los computadores que prestan el servicio de traducción de nombres de dominio a direcciones IP (DNS), tienen dueños y están ubicados físicamente en un lugar del planeta. Dependiendo del sitio en el que estén ubicados, los servidores caen dentro de la legislación del país correspondiente. En general, cada país tiene nombres de dominio propios, como por ejemplo Venezuela, que tiene los que terminan en “.com.ve” o “.net.ve” u “.org.ve”, entre otros, y que son traducidos por servidores del país al que pertenecen (en este ejemplo el sufijo “ve” corresponde a Venezuela). Estos servidores, generalmente están físicamente ubicados y caen bajo las leyes de país al cual sirven.

Los nombres de dominio que no tienen un sufijo en particular (¿nombres globales?), como por ejemplo “.com” o “.net” u “.org”, entre otros, son servidos en su mayoría desde los Estados Unidos y caen sobre la legislativa de ese país, es decir, caen dentro de la influencia de SOPA.

Todo esto quiere decir que por medio de SOPA, si el nombre de dominio de un sitio WEB es global y cae dentro de la influencia legislativa norteamericana (lo que es bastante común hoy en día), es posible bloquear por completo el proceso de traducción nombre a IP, bloqueando el nombre del sitio y haciendo posible su acceso sólo por medio de la dirección IP. Básicamente, al escribir por ejemplo es.wikipedia.org no se va a poder acceder al sitio, ya que no se va a realizar la traducción nombre->IP, y va a ser necesario escribir la dirección IP, algo como 134.123.104.98.

¿No le parece grave? Navegue un rato por Internet, mire la cantidad de nombres que aparecen en la parte de arriba del navegador y piénselo nuevamente. Además, ya mencionamos que por razones técnicas que no vienen al caso en muchos casos simplemente poner la dirección IP de un sitio WEB no funciona.

Si creen que el punto (1) fue malo, el punto (2) es aún peor. En el punto (2) si el sitio WEB está hospedado (físicamente) en un servidor en los Estados Unidos, lo que es bastante común y no sólo para sitios WEB que prestan servicios y hacen negocios en los EUA sino para sitio que prestan servicios fuera de los EUA, y el sitio WEB cae en desgracia, el proveedor del servicio debe bloquear el sitio, de tal forma que ni siquiera es posible acceder usando el IP directamente. Esto es más grave de lo que parece, porque por ejemplo en el caso de Venezuela, muchos proveedores de servicios WEB tienen sus servidores en los Estados Unidos, de modo que aún cuando presten servicios para clientes fuera de los EUA, caen bajo la influencia de la legislación.

Se puede ver el punto (1) como si la compañía telefónica eliminara el nombre/número de una persona de la guía telefónica, de modo que aquellos que aún conocieran el número telefónico al que quieren llamar todavía podrían llamar, pero el punto (2) desconecta el teléfono, de modo que ni siquiera sabiendo el numero al que se quiere contactar es posible hacer la llamada.

Voy a cambiar un poco el orden de los puntos de la infografía y voy a saltar directamente al (5), que es en mi opinión la “cereza encima del helado”. Luego trataré el (3) y (4) de forma más breve.

Hoy en día, la cantidad de información que hay en Internet es tan vasta, que para poder encontrar algo dependemos de algún tipo de servicio de búsqueda. Hay compañías que se dedican a prestar este servicio, básicamente tienen unos “programas robot”, que están constantemente recorriendo los sitios WEB que hay en Internet y que construyen enormes índices o mapas de lo que encuentran. Cuando un usuario accede a un buscador (por ejemplo Google) e introduce algunas palabras clave, el buscador utiliza sus índices y le muestra al usuario una lista de los sitios WEB que contienen la información más cercana y adecuada a las palabras clave introducidas.

El punto (5) de SOPA ordena que aquellas compañías que ofrezcan servicios de búsqueda, tales como Google o Yahoo, entre otras, remuevan los sitios bloqueados de sus resultados de búsqueda.

Por ejemplo, piense ahora que un sitio WEB está hospedado fuera de los Estados Unidos, y que su nombre de dominio es servido también fuera de los EUA; algo como www.misitioweb.com.ve, de modo que todo cae fuera de la influencia directa de SOPA. El problema es que según el punto (5), si el sitio cae en desgracia y es bloqueado por SOPA, los buscadores WEB que estén bajo la influencia legal de los EUA deben eliminar el sitio WEB de sus índices de búsqueda, de modo que sea imposible encontrar el sitio WEB por medio de esos buscadores. El resultado de todo esto es básicamente una forma directa de censura, ya que independientemente de que el sitio WEB exista y tenga un nombre de dominio “traducible” directamente a una dirección IP, los usuarios no podrán encontrar los sitios WEB bloqueados usando los buscadores tradicionales. ¡He ahí el problema de ser tan dependiente de buscadores gigantes y centralizados como “Google”!

Por cierto que, aún cuando no figura en la infografía, tengo entendido que aún hospedando un sitio WEB fuera de los EUA y usando un nombre de dominio local (ej. “.com.ve”) y un buscador alternativo que opere fuera de los EUA, el sitio puede ser bloqueado desde “dentro” de los EUA, es decir que alguien que esté en suelo norteamericano no va a poder acceder al sitio WEB.

Los puntos (3) y (4) no afectan directamente a sitios pequeños sin fines de lucro, pero afectan seriamente a empresas que se basan en publicidad o que venden algo por Internet. Si un sitio cae en desgracia, según el punto (3) los operadores de publicidad por Internet basados en los EUA (por ejemplo Google) deberán bloquearlo, es decir, no servirle más publicidad. Muchos sitios WEB viven de la publicidad de modo que bloquearles la publicidad simplemente representa la ruina.

El punto (4) es aún más grave: Debido al amplio control que tienen los EUA sobre los medios de pago electrónicos (Visa, MasterCard, PayPal, etc.) se corre el riesgo de poner en peligro los fondos y las transacciones de los sitios bloqueados.

Si esto no les parece grave, consideren el caso del bloqueo impuesto sin razón legal de base por estas estas tres empresas ya mencionadas a WikiLeaks. El siguiente video muestra una rueda de prensa que dio WikiLeaks el 24 de Octubre del 2011 explicando la situación.

El video es la primera de cinco partes (la conferencia comienza en realidad a los 8 o 9 minutos) y se puede llegar a las siguientes partes por medio de enlaces desde esta primera parte. En total la rueda de prensa dura aproximadamente 45 minutos, pero vale la pena verla completa. Cabe destacar que estos dos no son los únicos enlaces que documentan el caso, el bloqueo financiero impuesto a Wikileaks ha sido publico y notorio y está ampliamente reseñado y documentado.

—o—

Y ahora llegamos al punto en que: Si SOPA es semejante barbaridad, ¡¿Cómo puede ser algo bueno entonces?!

SOPA4_546

Se ha dicho mucho sobre las consecuencias de SOPA, y en mi opinión, la legislación definitivamente se usará como un mecanismo de control y de censura. Es posible que algunos sitios WEB como Facebook, Reddit, Twitter, Wikipedia, etc, tengan serios problemas para operar, quizá algunos tengan que cambiar radicalmente su forma de funcionar y quizá algunos tengan que salir fuera de línea.

También se ha dicho que el Internet tal como lo conocemos desaparecerá, que SOPA será un serio impedimento a la innovación, etc. Creo que hay mucho de cierto en muchas de estas afirmaciones, pero también pienso que hay que tomarlas con cuidado y que algunas de estas predicciones son muy relativas. Hay mucho alarmismo. Si algo ha demostrado Internet es que tiene la capacidad de crecer y adaptarse al ritmo y las necesidades de sus usuarios.

De aprobarse SOPA, la legislación definitivamente va a cambiar el Internet tal y como lo conocemos, nuestra libertad en la red se va a ver limitada… al menos por un tiempo. Luego, es probable que terminemos con un Internet aún más abierto y más libre que el que tenemos actualmente.

Si yo estuviera en Europa o en Latinoamérica en este momento (fuera del alcance legal de SOPA) y tuviera suficiente dinero para invertir, seguramente estaría muy pendiente de lo que pasa al respecto, a la espera de hacer inversiones en centros de datos, hospedaje de sitios WEB, buscadores, etc. No soy experto en negocios, pero si SOPA pasa, creo que mucho capital de ese nicho de negocios (hospedaje WEB, servicios, etc.) se va a mover fuera de los EUA.

Como ejemplo, a raíz de todo esto, pase o no SOPA, es muy posible que en lo personal mude el hospedaje de este sitio WEB a Europa o a Latinoamérica, es posible que gradualmente abandone los dominios “.net” y “.org” y los cambie por “.net.ve” y “.org.ve” (o .ar dependiendo), etc. Quizá mantenga el “.net” y el “.org” por un tiempo, pero pueden estar seguros de que voy a tener dominios alternativos por si acaso.

Además, no es como si la crisis y el movimiento de capital estuviera todavía muy lejos. A raíz del apoyo que muchas compañías le han brindado a SOPA, Anonymous, entre otros grupos e individuos, han llamado a realizar un boycott sobre los productos de estas compañías.

Este boycott fue dramático en el caso de GoDaddy, compañía que se dedica a dar servicios de hospedaje WEB y que apoyaba la legislación. Debido al boycott pasaron literalmente de apoyar SOPA a estar en contra de la legislación. Por lo que tengo entendido llegaron a perder (fueron transferidos a la competencia) hasta 35.000 dominios en un sólo día.

Todo comenzó con un post en reddit donde alguien afirmaba que transferiría sus 51 dominios y dejaría GoDaddy debido a su apoyo a SOPA, no estoy completamente seguro del enlace del post, debo decir que luego de verlo por primera vez en diciembre le perdí la pista, pero creo que es el original. El resultado fue una lluvia de respuestas de clientes de GoDaddy afirmando que también moverían sus dominios a otra compañía dado el soporte de GoDaddy a SOPA.

La competencia de GoDaddy evidentemente aprovechó la situación y dejó muy claro que no apoyaban SOPA, dieron descuentos a quienes transfirieran sus dominios usando cupones tipo “SOPASucks” e inclusive se llegó a declarar el 29 de Diciembre como el “día de mover los dominios fuera de GoDaddy“.

Debido a la cantidad extraordinaria de usuarios y dominios que comenzaron a perder, incluido hasta donde tengo entendido el duro golpe (imagino que más simbólico que monetario) de perder los dominios de Wikipedia, la compañía pasó de la noche a la mañana de apoyar SOPA a rechazar la legislación (lo que algunos vieron y siguen viendo como una cínica maniobra de relaciones pública). Además, todo el asunto le costó el cargo al CEO de la compañía Bob Parsons.

El punto es que mucha gente va a seguir la corriente, y al fin y al cabo, SOPA va a generar nuevas oportunidades de negocio fuera de los EUA.

Uno de los mayores argumentos en contra de SOPA es que va a impedir la innovación. Si bien es posible, creo que primero hay que preguntarse dos cosas: (1) ¿La innovación de quién y donde? ¿En los EUA o en el resto del mundo? La innovación en el mundo no se va a detener por una legislación, la innovación va a seguir su curso, se va a adaptar y va a sobrevivir (como siempre lo ha hecho, desde que nuestros antepasados dejaron el mar…) y por otro lado (2) ¿La innovación en qué dirección? ¿La innovación que produce nuevas formas de basura y entretenimiento barato en formato de película típicamente hollywoodense, de ese que lava el cerebro y no aporta ni un ápice de cultura (ojo que también han hecho buen cine, no tomen el comentario a mal) o de cantantes que sólo producen ruido por la simple razón de que es lo que las masas consumen sin pensar mucho? ¿O un concepto sobredesarrollado de innovación en la WEB 2.0 en el que se venden a trocha y mocha aplicaciones WEB usualmente alienantes en extremo que probablemente la gente en el fondo no necesita?, haciendo la salvedad claro está de esas que seguramente la gente si necesita. En fin, la innovación va a seguir, seguramente en direcciones más constructivas, tratando de desarrollar mecanismos que permitan tener un mejor Internet, más libre, más descentralizado, tratando de construir una cultura más abierta y accesible, etc.

La innovación va a seguir en otras direcciones, por ejemplo, mucho se ha dicho ya de los potenciales problemas de la neutralidad e imparcialidad (entre otras cosas) de los buscadores, y sobre el cómo estos pueden funcionar como un mecanismo directo de censura (si un sitio WEB no está en Google es casi como si no existiera). Estoy seguro de que las consecuencias de la ley van a comenzar cambiar la forma en que vemos los buscadores y va a generar innovación en ese sentido.

Por ejemplo, hay pequeñas iniciativas como Duck Duck Go que si bien funcionan bajo el mismo principio centralizado de Google, intentan garantizar la privacidad a sus usuarios y la imparcialidad de sus resultados (excelentes enlaces por cierto, recomiendo mucho revisarlos). Si bien estas iniciativas son un comienzo y representan una alternativa viable, estos nuevos buscadores no son tampoco una garantía de libertad, ya que en cierto sentido Google comenzó de la misma forma, como un buscador alternativo, como un respiro a los buscadores de la época (don’t be evil) y que hoy en día tiene un muy cuestionable manejo de la privacidad, tanto en el buscador como en sus productos alternativos (gmail, google docs, etc). Pero en este caso SOPA no hace más que mostrar algo que ya sabemos: que somos muy dependientes de, y vulnerables frente a los buscadores tradicionales/comerciales, permitiendo abrir una puerta para estrategias alternativas de búsqueda (¿innovación?).

Esto puede ser una oportunidad para que tecnologías como YaCy, Bitcoin, Tor y otras tecnologías distribuidas se terminen de desarrollar, de forma que se resuelva de una vez por todas la necesidad de “descentralizar” buena parte de la infraestructura en Internet. Sólo el trío de productos que acabo de mencionar, YaCy que es un buscador distribuido (!nadie, ninguna compañía, tiene el control del buscador!), Bitcoin que es una “moneda/dinero” virtual no controlado por ninguna oligarquía financiera y Tor, que es un sistema para garantizar el anonimato en la red representan reacciones a los intentos actuales de controlar y censurar la red. ¡Y quién sabe, quizá algún día logremos tener un sistema de nombres de dominio (DNS) descentralizado!

En el fondo creo que a largo plazo SOPA puede llegar a ser algo bueno porque va a forzar aún más la descentralización de Internet. SOPA va a aislar al Internet en los EUA, pero lo va a hacer crecer en el resto del mundo, y eventualmente luego de que se derrumben los muros de la legislación, lo va a hacer crecer también en los EUA, esto es lo verdaderamente invaluable de todo el asunto. Eventualmente imagino que alguien se dará cuenta de que la legislación es absurda e insostenible, y que hizo más daño que bien al país, y en este punto imagino que se derrumbará, generando a largo plazo un Internet aún más libre del que tenemos hoy en día.

—o—

PS: Apenas unos días después de publicar este artículo me conseguí con algunos extractos de una entrevista realizada a Tim O’Reilly sobre SOPA. Si, el mismo Tim O’Reilly de oreilly.com. Algunos comentarios adicionales se pueden encontrar aquí. En mi opinión su punto de vista al respecto es extremadamente claro y contundente.

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?