Revista Essentia Libre – Edición 2

Contenido:

• ¿Cómo aprenden los niños?, y eso ¿qué tiene que ver con las Medidas Tecnológicas de Protección en el Código Penal Colombiano?
• El DebConf6 en México: Latinoamérica ¡vive !
• Funciones en Calc13
• El experto aconseja… ntop: Una interfaz Web para análisis de tráfico de red
• Tiras cómicas
• Ingeniería de Sistemas + Software libre: Por una mejor Sociedad de la Información.
• Comunidades, Jornadas de software libre (JSL)

Versión en PDF

Sin comentarios | deja el tuyo

Interfaces gráficas Java en Mono… que decepción

Creo que el titulo habla por sí solo. Me he dado a la tarea de probar la simulación que tiene Mono al utilizar IKVM para ejecutar programas en Java. Lo cierto es que todo va muy bonito cuando haces programas en modo texto, ya que todo es simulado a la perfección (bueno, eso creo); pero al momento de crear interfaces gráficas los resultados son algo frustrantes.

Comenzando porque solo es compatible con los programas en Java hechos con la versión 1.4 o inferior, lo que nos impide trabajar con la 1.5 (y sus bonitas GUI’s de Swing). Pero vamos a ver esto un poco más de cerca, y con ejemplos:

Situación 1: Interfaz Gráfica simple en Swing, utilizando el intérprete de Java:

Todo normal, todo bonito… (casi obvio).

Situación 2: Interfaz Gráfica simple en Swing, utilizando el interprete de Mono (IKVM):

Al principio no sale muy bien la ventana (sale sin el tamaño indicado), y podemos ver como en la primera imagen (después de tratar de ajustarla) se ve un poco “corrida”. Y después de varios ajustes, bingo!!! la GUI queda perfecta, y funcionan los eventos sobre el botón. ALELUYA!!!

Situación 3: Interfaz Gráfica menos simple en Swing, utilizando el interprete de Java:

Lo mismo que en la situación 1.

Situación 4: Interfaz Gráfica menos simple en Swing, utilizando el interprete de Mono (IKVM):

Al principio lo de siempre: la ventana no tiene el tamaño indicado… Vemos como en la primera imagen solo se puede ver el objeto JCheckBox, pero eso puede solucionarse (pensé). Al tratar de ajustar la ventana varias veces me encuentro con que queda más o menos bonita, Pero valla sorpresa: NO sirve para nada; bueno, lo único que funciona es el objeto JcheckBox, porque al tratar de hacer click en el botón (Jbutton) o en la caja de texto (JTextField) es como si se le diera click al JCheckBox.

Y eso que no es una GUI muy compleja…

Y ni hablar de utilizar AWT

Situación 5: Interfaz Gráfica simple en AWT, utilizando el intérprete de Java.

De por sí, al utilizar AWT sobre Linux las GUI’s quedan una porquería. Pero en cuanto a funcionalidad, todo muy bien

Situación 4: Interfaz Gráfica simple en AWT, utilizando el intérprete de Mono (IKVM).

En este caso, con suerte y se ve el botón… y ni hablar de una GUI más compleja: NO SE VÉ NI M*****. Una última comparación… probando una GUI un poco compleja con Swing; Intérprete de Java vs. Mono (IKVM):

En Java:

Utilizando Mono en Linux, ni siquiera corre el programa; y en Windows aparece algo no muy agradable:

Conclusiones (¿o excusas?)

No pretendo con esto ser el crítico destructivo, ni el que crítica por criticar. Porque si algo tengo claro, es que no es nada fácil programar una plataforma como Mono. Pero talvez pudieron dedicar un poquito más de trabajo a la parte gráfica de Java; o bien, omitirla.

Y sí, ya sé: la iniciativa principal de Mono es tener una implementación .NET para UNIX, y que se enfoca principalmente en los lenguajes C# y VB.NET; mas no crear otra VM para Java. Pero también sé que se prometía a los programadores de Java, un trabajo limpio sobre Mono, con el fin de poder migrar satisfactoriamente hacia la riqueza que implica crear aplicaciones en la plataforma .NET, pero sin tener que cambiar mucho la forma de programar o aprender otros lenguajes (que nunca está de más).

Por otro lado, es bueno ver como con C# se pueden crear GUI’s muy bonitas, utilizando las librerías Gtk (de Gnome); e inclusive programando en sistemas operativos tan diferentes de UNIX como lo es Windows.

Pero… ¿acaso la única solución al problema que ocurre al ejecutar GUI’s diseñadas en Java, o en otro lenguaje, sobre Mono, es aprenderse la API de las librerías Gnome (Gtk, Gdk, Atk, etc.), para aplicarlos en lenguajes como C#, Nemerle o Boo? La verdad no creo que sea la solución más eficiente… pero desafortunadamente parece ser la única.

Un comentario | deja el tuyo

Aprende a programar en diez años

“Aprende a programar en diez años”, el título de un excelente articulo de Peter Norvig, en el que se crítica de manera sutil, pero directa, todos aquellos libros o tutoriales de programación cuyos títulos son parecidos a “Aprende Java en 21 días” o “Aprende Pascal en Tres Días”.“La conclusión es que, o bien la gente tiene un gran afán por saber de computadoras, o bien las computadoras son algo fabulosamente más fácil de aprender que cualquiera otra cosa” dice Peter en su articulo.

Se resalta que es imposible aprender todo un lenguaje de programación en unos cuantos días, ya que en esos cuantos días “no tendrás tiempo de escribir varios programas significativos, y de aprender de tus éxitos y errores con ellos. No tendrás tiempo de trabajar con un programador experimentado y entender lo que es vivir en ese ambiente. En resumen, no tendrás tiempo de aprender mucho. Así que esos libros sólo podrán lograr una familiaridad superficial, no un entendimiento profundo.”

Me permito citar una parte interesante del articulo, en lo que Meter dice, que es su receta para el éxito en programación:

• Interésate en la programación, y programa porque es divertido. Asegúrate de que te diviertes tanto como para invertir diez años.
• Habla con otros programadores. Lee otros programas. Esto es más importante que cualquier libro o curso.
• Programa. El mejor tipo de aprendizaje es aprender practicando. Para decirlo más técnicamente, “El máximo nivel de desempeño de los individuos en un dominio dado, no se logra automáticamente como función de experiencia extendida, sino que el nivel de desempeño puede incrementarse incluso en individuos altamente experimentados como resultado de esfuerzos deliberados por mejorar.” (p. 366) y “el aprendizaje más efectivo requiere una tarea bien definida con un apropiado nivel de dificultad acorde con el individuo, retroalimentación informativa, y oportunidades de repetición y corrección de errores.” (p. 20-21) El libro “Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life es una interesante referencia sobre este punto de vista.
• Si quieres, dedica cuatro o cinco años en una universidad (o más en una escuela de graduados). Esto te dará acceso a algunos posiciones que requieren credenciales, y te dará un entendimiento más profundo del campo, pero si no disfrutas la escuela, puedes (con algo de dedicación) obtener una experiencia similar trabajando. Como sea, la lectura de libros por sí sola no será suficiente. “La educación en computación no puede hacer a nadie un experto programador más que el estudio de pinceles y pigmentos puede hacer a alguien un pintor experto” dice Eric Raymond, autor de The New Hacker’s Dictionary. Unos de los mejores programadores que yo haya contratado alguna vez tenía solamente un grado de bachiller; pero ha producido una gran cantidad de excelentes programas, tiene su propio grupo de noticias, y sin duda es mucho más rico de lo que yo pueda llegar a ser.
• Trabaja en proyectos con otros programadores. Sé el mejor programador en algunos proyectos; sé el peor en otros. Cuando eres el mejor, tienes que poner a prueba tus habilidades para liderar un proyecto y para inspirar a otros con tu visión. Cuando eres el peor, aprendes lo que los maestros hacen, y aprendes lo que a ellos no les gusta hacer (pues te ponen a hacerlo por ellos).
• Trabaja en proyectos después que otros programadores. Proponte entender un programa escrito por otra persona. Mira cuánto toma entenderlo y hazle correcciones cuando los programadores originales no están allí. Piensa en cómo diseñar tus programas para facilitarles el trabajo a aquellos que le harán mantenimiento después de tí.
• Aprende por lo menos una media docena de lenguajes de programación. Incluye uno con soporte para abstracciones de clases (como Java o C++), uno que dé soporte a la abstracción funcional (como Lisp o ML), uno que dé soporte a la abstracción sintáctica (como Lisp), uno que dé soporte a especificaciones declarativas (como Prolog o plantillas C++), uno que dé soporte a corutinas (como Icon o Scheme), y uno que dé soporte al paralelismo (como Sisal).
• Recuerda que hay “computadoras” en la “ciencia de la computación”. Conoce cuánto le toma a tu computadora ejecutar una instrucción, alcanzar una palabra de la memoria (con y sin cache), leer palabras consecutivas de disco, y ubicar una nueva localización en disco.
• Involúcrate en un plan de estandarización de algún lenguaje. Podría ser en el mismo comité ANSI C++, o podría ser simplemente decidir si tu estilo de codificación tendrá niveles de identación de 2 ó 4 espacios. Como sea, averigua lo que les gusta a otras personas en un lenguaje, cómo lo perciben, y quizá incluso un poco de por qué lo perciben como lo hacen.
• Ten el buen juicio para lanzar el plan de estandarización del lenguaje tan pronto como sea posible.

Sin duda algo que vale la pena leer, lo podeís descargar de aquí… saludos!!!

4 Comentarios | deja el tuyo