Entre tazas y pingüinos

Google Waves ...

2009-07-25T01:26:00.004-03:00

No pretendo repetir toda la información que ya anda dando vuelta por Internet, ni tampoco quiero parafrasear a todos las personas que ya han hablado sobre el tema. Mi intención es simplemente expresar mi humilde opinión sobre el tema. Me tomé el tiempo de ver la presentación completa (link al final). Las sensaciones que me quedan son varias y paso a enumerarlas a continuación. En primer lugar, si Waves hace todo lo que en la presentación mostraron y anunciaron, quedará demostrado el poder de GWT en aplicaciones web, tema que ha sido muy cuestionado. Por si no lo conocen, GWT es un framework de Google que permite desarrollar aplicaciones web en Java, centrándote en el desarrollo de la interfaz y no en la compatibilidad con los distintos navegadores. Otro punto que me gustó, es que lo han desarrollado bajo una especificación completamente abierta y su implementación ha sido licenciada bajo Open Source (habría que ver cual de todas ellas). Google ha sido muy criticado ya que viene "monopolizando" muchas áreas de la web y muchos lo señalan como el nuevo Microsoft. Con la actitud de liberar tanto la especificación como la implementación de Waves, le han tapado la boca a muchas personas (y aplaudo fervientemente esta decisión). Google ha demostrado una vez más, porqué está en la posición que está, al no restringir a los usuarios a su producto, haciendo su producto libre y apuntando a la integración casi taxativa entre todos los servicios que normalmente usa una persona en Internet (Twitter, Blogger, YouTube, etc) permitiendo además, que cualquiera que quiera integrarse lo pueda hacer sin ningún problema. Analizando un poco mas en profundidad las funcionalidades y características de Waves, no logro encontrarle realmente una característica nueva y revolucionaria. Lo que si me parece interesante, es el tema de la integración entre todos los servicios. Pero fuera de eso, no hay algo que me haga decir wow. Tiene muchas cosas lindas e interesantes, pero me parece que lo han anunciado con demasiados bombos y platillos. Por si alguien todavía no ha visto el video de presentación de Google Waves, aquí se los dejo: Saludos y hasta la próxima.

Probando Internet Explorer 8 con ACID3

2009-03-21T02:41:00.007-03:00

Van a pensar que soy un loco del test ACID3 (puede que sea cierto!!!), pero pensé en probar el resultado del citado test en el recientemente lanzado Internet Explorer 8 (IE8 de aquí en adelante). Previamente ya había testeado otros navegadores con el mismo test. También habíamos encontrado uno que los pasa en su totalidad. Me basaré en esos resultados anteriores para el análisis. Sin más rodeos, les presento el resultado del test: Para tomar un punto de referencia, recordemos cual fue el resultado con Internet Explorer 7 (IE7 de aquí en adelante): Recordemos ahora cual debería ser el resultado para que pase el test: Observando las imágenes, podemos observar que hay una gran mejora en el renderizado de las páginas, de hecho el resultado en este sentido es muy similar al de la mayoría de los navegadores. pero lamentablemente, la calificación es de 20/100. Esto nos indica que Microsoft sigue con la política de darle muy poca importancia a los estándares. Se ha dicho mucho sobre el fallo de seguridad que se descubrió unas horas después del lanzamiento de IE8. En este aspecto, no debería preocupar tanto la rapidez. De hecho, si se hiciera el mismo esfuerzo en encontrar problemas de seguridad en Mozilla Firefox, Safari u Opera, probablemente los resultados no difieran mucho. Esto es así ya que los fallos de seguridad son inherentes a absolutamente todos los programas que existen. Ningún software está libre de ellos por más testeado que esté. Lo importante sobre este punto, es ver que actitud toma Microsoft con respecto a este problema de seguridad y lamentablemente, la mayoría conoce la respuesta a esa cuestión. Nuevamente, espero que les haya sido de utilidad. Nos vemos en la próxima.

Java vs Ruby

2009-03-08T22:20:00.024-02:00

Utilizo mucho estos 2 lenguajes, principalmente Java. Por ello, voy a tratar de describir sus diferencias, similitudes, ventajas y desventajas. Hago esto para que los que quieran adentrarse en estos lenguajes, puedan tener una referencia. En principio, me gustaría señalar que la principal ventaja que tiene Ruby frente a Java, es lo compacto y simple que es el lenguaje. Esta diseñado para que no tengamos que escribir largos bloques de código y además, para que la lectura del código se asemeje un poco mas al lenguaje humano que al computacional. Para ejemplificar lo que les digo, vamos a programar un simple algoritmo que escribe 3 veces una cadena por la pantalla. En Java:

for(int i=0;i<3;i++) {
    System.out.print("cadena de texto");
}

En Ruby:

3.times do print "cadena de texto" end

Como pueden ver, el código en Ruby es más compacto y es más directa su lectura. Para los que son adeptos a la sintaxis más "computacional", Ruby nos permite escribir el algoritmo anterior, de la siguiente manera:

3.times {
    print("cadena de texto");
}

Podemos ver que la sintaxis anterior, es muy similar a la usada en Java. Puntualmente podemos ver las siguientes similitudes:

Las líneas de código con el "punto y coma" final
Los bloques de código delimitados por los símbolos { y }
Los parámetros pasados a un método, entre paréntesis.

Definitivamente, Ruby es muy flexible con respecto a la sintaxis que usamos para programar. Muchos pueden argumentar en este punto, que la sintaxis de Java es mucho más potente que la de Ruby, ya que en este último no se puede acceder al índice y tampoco es posible especificar los valores inicial, final y de paso, del índice de iteración (La variable i en el código de Java). En respuesta a lo anterior, Ruby nos permite hacer lo siguiente:

0.step(2,1) do |i|
    print "cadena de texto - Iteracion ${i}"
end

Este método, ejecutará el bloque de código variando el índice i, desde el valor inicial 0, hasta el valor final 2, sumándole 1 en cada paso. Como ven, Ruby se adapta bastante a nuestros gustos. Si bien esta flexibilidad tiene muchas ventajas, también puede traer problemas. El principal (según mi punto de vista) es que cuando en un proyecto participan muchos programadores, si no se establece una convención de sintaxis, podemos terminar con una gran mezcla de código de sintaxis muy variada, y esto puede traer mucha confusión en la lectura y manutención del mismo. Otras de las grandes desventajas de Ruby, es que es un lenguaje totalmente interpretado, lo cual trae problemas de rendimiento y escalabilidad. Prueba de esto, es que Twitter está mudando su plataforma de Ruby on Rails, a Scala. Otras de las fuertes debilidades que le veo a Ruby, es que es un lenguaje de tipos débiles. Esto quiere decir que las variables que usamos no tienen un tipo fijo, y que tampoco es necesario declararlas para uso. En mis experiencias (laborales y académicas) utilizando lenguajes de tipos débiles, he llegado a la conclusión de que es algo útil en algoritmos y programas de poco tamaño. Pero cuando la cantidad de código comienza a crecer (proporcionalmente con la cantidad y complejidad de las capas y módulos de nuestra aplicación), esto se vuelve una gran desventaja. Piensen en que si una variable no tiene tipo fijo, entonces tenemos que suponer que tipo tiene al momento de usarla y esto genera errores, que en algunos casos son casi imposibles de detectar, sobre todo en aplicaciones donde los datos se mueven a través de los distintos módulos de la aplicación, atravesando a su vez, las distintas capas de la misma. Como señalé anteriormente, en Ruby tampoco es necesario declarar una variable para usarla. Esta es otra fuente de muchos problemas. Varias veces perdí muchas horas tratando de resolver un bug, para darme cuenta que el problema era que una variable estaba mal escrita (al no tener que declararla, el intérprete la toma como una nueva variable). Aunque tengo que reconocer que el uso de IDE's con autocompletado (como Netbeans o Eclipse) han minimizado mucho estos problemas. Para finalizar, les dejo una lista de similitudes y diferencias que existen entre estos 2 lenguajes. Similitudes:

En ambos lenguajes contamos con manejo automático de memoria, a través de un recolector de basura.
Los objetos son de tipos fuertes (Las variables son de tipos débiles en Ruby, pero los objetos no).
Ambos soportan casi la totalidad del modelo orientado a objetos.
Los 2 cuentan con herramientas de documentación embebidas. (Javadoc en Java y Rdoc en Ruby).
Tanto Ruby como Java, son lenguajes totalmente libres (licencia GPL).

Diferencias:

Ruby es interpretado, Java es compilado y luego interpretado.
En Ruby se pueden usar como separadores de bloques las palabras claves do y end, o los símbolos { y }. En Java sólo es posible usar { y }
En Ruby, todos los atributos de una clase son privados, en Java pueden ser privados, públicos o protegidos.
En Ruby, la lista de parámetros pasados a un método, puede o no estar delimitada por paréntesis. En Java, los paréntesis son obligatorios.
En Ruby, absolutamente todo es un objeto. En Java existen tipos de datos que no son objetos.
En Java existe el chequeo de tipos. En Ruby no, ya que es interpretado.
En Java, las variables son de tipo fuerte. En Ruby las variables son de tipos débiles.
En Ruby tenemos los mixin's, en contrapartida de las interfaces de Java.

Me gustaría destacar una de las grandes ventajas de Java frente a Ruby. Esta ventaja, es la gran cantidad de bibliotecas y frameworks disponibles directamente para su uso. Lo anterior, sumado a una inmensa comunidad de usuarios, hacen que Java sea uno de los lenguajes mas usados. En el poco tiempo que llevo desarrollando en Ruby, he encontrado una gran comunidad de usuarios y bibliotecas disponibles, pero si tenemos que comparar en cantidad, se queda muy corto comparado con Java. Si bien Java es un lenguaje muy potente, no hay que pensar que es lo mejor para todo. Todas las herramientas tiene sus puntos fuertes y débiles y hay que saber cuando utilizar una u otra. En mi caso, he encontrado que Ruby es excelente para hacer proyectos de pequeño y también es bastante aplicable en proyectos de mediana envergadura. En proyectos grandes, definitivamente Java es una de las mejores opciones, sobre todo en términos de rendimiento en ámbitos de mucha concurrencia, y en escalabilidad de los sistemas. Espero que les sea de utilidad. Nos vemos en la próxima.

Una realidad muy geek

2009-03-06T01:05:00.003-02:00

Vi esto colgado por la red, y me causó mucha gracia. Espero que lo disfruten. Saludos gente. Nos vemos pronto.

Instalando Google Gadgets en linux

2009-03-05T21:55:00.008-02:00

En esta ocasión, me dispongo a instalar esta pintoresca herramienta de Google, llamada Google Gadgets (for Linux). Específicamente, vamos a instalar la última versión estable de la misma. Esta es la 0.10.5 Introducción: Google Gadgets es una aplicación para el escritorio, bastante similar al Sidebar de Windows Vista, a SuperKaramba de KDE y a gDesklets de GNOME. Por suerte está liberado bajo licencia Apache 2.0. Si bien todavía no es estable, se ve bastante bien. Instalación Procederemos ahora con la instalación. a) Ubuntu y sus derivados: Hay que descargar el paquete .deb desde aquí. Seleccionen su versión de Ubuntu y la arquitectura correcta. Luego abrimos una consola y como root (o con sudo) ejecutamos el comando: dpkg -i paquete.deb Donde paquete.deb, es el nombre del paquete bajado. b) ArchLinux: Aquí es un poquito mas complicado, ya que el paquete se encuentra en los repositorios AUR. Si lo instalamos directamente con yaourt, la instalación fallará por un bug en el paquete. Para que no falle, es necesario ejecutar un par de comandos que solucionen el problema. Como root (o con sudo), ejecutamos los siguientes comandos: cd /usr/lib/pkgconfig/ cp mozilla-js.pc mozilla-js.pc.bak sed -i 's:stable:unstable:' mozilla-js.pc cd - Ahora si podemos instalarlo desde yaourt. Abrimos una consola y ejecutamos: yaourt -S google-gadgets Si nos pide instalar algún paquete como dependencia, le decimos que sí. Probablemente nos pregunte si deseamos editar el archivo PKGBUILD y el google-gadgets.install, no es necesario editarlos, por lo que respondemos que no. Luego de bajar los archivos necesarios, y de instalar las dependencias, yaourt compilará Google Gadgets. Esto puede tardar un poco, dependiendo principalmente de la velocidad de la PC. Una vez compilado lo necesario, nos pregunta si deseamos instalar el paquete. Obviamente contestamos que si. Con esto termina la instalación. Usando ... Abrimos el menú de nuestro entorno de escritorio, y buscamos la aplicación "Google Gadgets". Probablemente tengan 2 veces listada esta aplicación, una con la leyenda "GTK" y otra con "Qt". Si están usando Gnome o Xfce, ejecuten la primera (GTK) y si están usando KDE, ejecuten la segunda (Qt). Como verán, no es muy difícil de usar, la interfaz es bastante intuitiva y simple. Haciendo click derecho en la barra lateral, y luego en "Add Gadgets" accederemos a la extensa lista de gadgets que podemos agregar a nuestro escritorio. Bueno, les dejo a ustedes que exploren los gadgets y opinen que les parece. Saludos y hasta la próxima.

Midori, navegador que pasa el test Acid3

2009-03-03T22:33:00.011-02:00

Y justo que estábamos testeando navegadores con el test Acid 3, me entero por casualidad que existe un navegador (y que probablemente no sea el único) que pasa exitosamente el test Acid 3. El navegador en cuestión se llama Midori, y todavía no es totalmente estable, pero inclusive siendo inestable obtiene un puntaje de 100/100 y la página de prueba es renderizada en forma perfecta. Algo que ninguno de los navegadores más usados logró realizar. La página oficial del navegador es http://www.twotoasts.de. Definitivamente es un navegador que tengo que probar. Como me costó un poco creerlo, decidí comprobarlo por mi mismo. Acá les dejo un video en el cual ejecuto el test, y luego comparo el resultado con la imagen de referencia.

Corriendo el test Acid3 sobre el navegador Mirovi from Tolaware on Vimeo.

Se puede apreciar claramente que el renderizado es perfecto, y que obtiene los 100 puntos. Sinceramente, los desarrolladores de este navegador se merecen un gran reconocimiento por el logro obtenido, sobre todo considerando que el navegador conocido que más se acerca a cumplir con los estándares, es Opera con un 85/100. Bueno, pruebenlo y después me dicen que les pareció.

Software Libre

2009-03-02T19:38:00.010-02:00

En esta ocasión, encontré rondando por Internet un mapa conceptual sobre el Software Libre. Realmente es muy útil para explicar los beneficios del mismo, para todos los usuarios.

(click en la imagen para agrandarla)

Espero que les sea provechoso. Saludos y hasta la próxima.

Testeando navegadores con Acid3

2009-03-02T10:20:00.023-02:00

Introducción He visto muchas pruebas hechas sobre navegadores, principalmente test acid. En casi todos los casos sólo se hace referencia al puntaje total obtenido, sin realizar una comparación entre los resultados visuales obtenidos. Otro error que se suele cometer, es que se suelen correr los tests sobre futuras versiones de los navegadores, que no son las versiones finales. Esto lleva sacar conclusiones erróneas sobre navegadores. Por esto, voy a realizar el test acid 3 sobre los navegadores más usados, comparando la totalidad de los resultados obtenidos. Los tests se realizarán sobre la última versión estable de cada uno. Manos a la obra Los navegadores a testear son los siguientes:

Internet Explorer 7.0.5730
Google Chrome 1.0.154
Mozilla Firefox 3.0.6
Epiphany 2.24.3
Opera 9.63
Safari 3.2.2

Para que un navegador pase el test completamente, tiene que obtener un puntaje de 100/100 y la página resultante obtenida, tiene que ser igual a la siguiente: Resultados de los tests: Muestro los resultados de todos los tests y luego sacaremos conclusiones.

Internet Explorer:

Mozilla Firefox:

Google Chrome:

Epiphany:

Safari:

Opera:

Análisis Los puntajes obtenidos fueron:

Opera --> 85/100
Google Chrome --> 79/100
Safari --> 75/100
Epiphany --> 71/100
Mozilla Firefox --> 71/100
Internet Explorer --> 12/100

Todos los navegadores se acercan en su mayoría al resultado ideal, salvo Internet Explorer que realmente es un desastre en el tema de adopción de estándares. De hecho, dibuja tan mal la página que cuesta ubicar cual es el puntaje. La exactitud del gráfico obtenido por Internet Explorer, es realmente nula. Mozilla Firefox y Epiphany se basan en el motor Gecko, por lo que los resultados son iguales. Me llama un poco la atención que tengan un puntaje más bajo que la mayoría. Safari se encuentra en el medio con 75 puntos. La similitud con el resultado gráfico es menor que en Firefox y Epiphany, sin embargo, se acerca bastante al resultado ideal. Google Chrome se acerca un poco más al puntaje ideal. El resultado gráfico es igual al de Safari. Teniendo en cuenta que este navegador ha sido lanzado muy recientemente, nos indica que ha sido diseñado desde el principio, para que respete los estándares. Probablemente este navegador logre captar una gran porción del mercado. Opera es el que da una gran sorpresa con un puntaje de 85 y logrando una similitud bastante mayor con la imagen de referencia, que el resto de los navegadores. Por alguna razón, este navegador no goza de una comunidad de usuarios muy grande. Es una pena, ya que de todos los navegadores, es el que más cerca está de cumplir con todos los estándares. Conclusiones Recomendaría el uso de cualquiera de estos navegadores, salvo Internet Explorer, ya que es evidente lo desastroso que es con respecto a los estándares. Si Opera fuese liberado con una licencia de código abierto, probablemente lograría un éxito similar al obtenido por Firefox.

Fases en el ciclo de vida de sistemas

2009-02-27T21:41:00.008-02:00

En esta oportunidad, quería compartir con ustedes una imagen que está colgada en la bedelía de la carrera que actualmente estudio (Ingeniería en Sistemas de Información). Representa lo que pasa en el 80% de los proyectos de desarrollo de software. Cada uno de los actores en el ciclo de vida del desarrollo del sistema, desde el cliente que especifica los requisitos hasta el desarrollador, pasando por el consultor, el analista y otros más, tiene una visión distinta de lo que se está desarrollando y aveces, esa visión difiere mucho. Esta clase de desentendido permanente, es muy difícil de evitar. Partiendo del punto en el que el cliente no sabe (o no puede) describir correctamente lo que necesita, eso sumado a que quién capta estos requisitos puede comprender distorsionadamente una especificación que ya es errónea, y así en cada elemento de la cadena, el resultado no puede ser otro que un sistema que no le sirve al cliente. Esto pasa, y no muy pocas veces. De hecho se le suele entregar al cliente un sistema que ambos piensan es el correcto, y el cliente paga con gusto su precio, para darse cuenta un tiempo después, que el sistema no le sirve, o está muy alejado de lo que realmente pasa en el negocio. Existen técnicas para evitar estos problemas, de hecho existen varias técnicas formales. A mi entender, esto ocurre principalmente, por la existencia permanente de las presiones de tiempo sumado a una comunicación deficiente con el cliente (inexistente en ocasiones). Existen líderes de proyecto que en el apuro de avanzar con el sistema lo más rápidamente posible, omiten tareas muy importantes. Por ejemplo, se suele omitir a menudo, las reuniones con todo el equipo de desarrollo (incluyendo líderes, analistas, y testers). Imagino que con el tiempo, estas prácticas irán cambiando. Los proyectos en donde no hay una comunicación fluida y eficiente con el cliente, o no existe una comunicación y puesta común regular con todos los integrantes del equipo de desarrollo, tienen a fracasar, o no satisfacer correctamente las necesidades del cliente.

JDK, GNU Classpath, OpenJDK y IcedTea

2009-02-20T05:46:00.010-02:00

Introducción: Mucho se ha escuchado hablar de estos términos. Principalmente desde que Sun decidió liberar el JDK 6 y 7 bajo la licencia GPL (versión 2). Por esto voy a tratar de explicar en forma concisa y resumida cómo se relacionan estos entornos y por qué es que aparecen en el mercado. Historia: Sun en 1995, crea la versión 1.0 del JDK de Java, dando a luz uno de los lenguajes más poderosos y extensamente usados del medio. El JDK, siempre estuvo bajo una licencia restrictiva, aunque paulatinamente llevaron el lenguaje a la comunidad con procesos abiertos (Java Community Process) y modificando las licencias para que la máquina virtual pueda ser incluida en las distribuciones de Linux. Si bien se podía crear software libre con Java, existía la llamada Trampa Java. Esta "trampa" consistía en que para ejecutar un software hecho en Java, era necesario disponer de una máquina virtual que pudiera realizar esta tarea, y cómo la máquina virtual hecha por Sun no era libre, entonces el software libre hecho en esta plataforma veía coartada su libertad. Debido a esta falta de libertad, anunciada por la Trampa Java, comienzan a surgir implementaciones independientes de Sun, que intentan reemplazar su JDK por otro, libre de la trampa señalada. Entre ellas, las que más se destacaron fueron: GNU Classpath y GCJ. Finalmente, Sun decidió liberar la versión 6 y 7 de Java SE, bajo la licencia GPLv2. Al proyecto lo llamó OpenJDK, he incluyó en él todos los componentes, exceptuando un pequeño porcentaje de ellos por problemas de licenciamiento ajenos a Sun. El problema que surgió, fue que la plataforma Java todavía no era libre en su totalidad. Es aquí cuando Red Hat decide entrar en el juego y lograr que la plataforma Java se pueda usar y construir con herramientas totalmente libres. Por ello toma como base el proyecto OpenJDK y reemplaza los componentes que no son libres, con alternativas libres provenientes principalmente del proyecto GNU Classpath. El proyecto es llamado IcedTea. Al día de la fecha, IcedTea a pasado los test TCK correspondientes, lo que significa que es una alternativa completa al JDK de Sun. Conclusiones: Es bastante claro que los esfuerzos realizados para que Java llegue a ser totalmente libre, han sido muy grandes. Tanto Sun, como RedHat, el proyecto GNU Classpath y muchos otros contribuyentes, merecen un gran reconocimiento por el esfuerzo hecho para llevar a cabo esta tarea. Un reconocimiento a su trabajo, ha sido que tanto IcedTea como OpenJDK, han sido incluidos en la mayoría de las distribuciones principales de Linux, entre las que se encuentran:

Ark Linux
Fedora
Ubuntu y sus derivados
Debian
Gentoo
ArchLinux

Personalmente uso IcedTea en mi instalación de ArchLinux, y no he tenido ningún problema. Considerando que uso bastante Java, tanto como para correr sus programas (NetBeans, Tomcat, Vuze, MagicDraw, etc), como para desarrollar, puedo recomendar su uso sin ningún temor a fallas o comportamientos distintos a los del JDK de Sun.

Facebook pone fin a sus conflictivas políticas de privacidad

2009-02-18T12:57:00.006-02:00

Como muchos habrán notado, se ha armado un gran revuelo por las políticas de privacidad aplicadas por Facebook. Estas políticas básicamente se apropiaban de todos los contenidos publicados por los usuarios en Facebook, incluyendo fotos, textos, videos, etc. La cláusula en cuestión era la siguiente (la cual tenemos que aceptar obligatoriamente si queremos usar el servicio): "Usted cede en forma irrevocable, perpetua, no exclusiva, transferible, dada por pagada, la licencia mundial (con derecho a sublicenciar) para usar, copiar, publicar, reproducir, almacenar, mostrar, transmitir, escanear, reformatear, modificar, editar, enmarcar, traducir, resumir, adaptar, crear obras derivadas y distribuir (a través de múltiples canales), cualquier contenido que usted cuelgue en Facebook." La misma fue eliminada, como anuncia el creador de esta red social (Mark Zuckerberg), en su blog. No entiendo por qué se ha armado tanto revuelo con esto, si esta cláusula llevaba bastante tiempo aplicándose. Lo único que cambiaron de esa cláusula (que ahora han revocado) es que el contenido seguía siendo propiedad de Facebook incluso si el usuario lo eliminaba del servicio. Creo que somos gente libre (al menos eso nos hacen creer) y como tales, tenemos la libertad de dejar de usar el servicio cuando queramos. Y si hiciésemos eso todos los usuarios a los cuales nos molestaba la criticada cláusula en ves de quejarnos, probablemente hubiésemos tenido mejores resultados.

Abrace a un desarrollador

2009-02-16T18:33:00.012-02:00

Naufragando por la red, me encontré un video con el cual la mayoría de los desarrolladores de software se pueden sentir identificados. No tiene desperdicio. Les traduzco las frases por si las moscas: Los desarrolladores están sufriendo mucho, en todos lados Estoy sufriendo Estamos en el cuarto mes de un calendario de 5 meses, y recién ayer recibimos los requerimientos finales (y cambiaron nuevamente) Paso la mitad de mis días en reuniones sobre cómo aumentar el trabajo (en vez de trabajar) Mi jefe leyó en una revista que los desarrolladores que usan el lenguaje de programación "______" son el doble de productivos. Por lo que compró una licencia y redujo el calendario a la mitad Todos los días, mi jefe cambia de parecer sobre lo que desarrollamos La gente sigue pidiéndome que les arregle el correo, por lo que no me queda tiempo para programar Mi papa ya no tiene tiempo para mi Unos consultores le dijeron a mi jefe que podían desarrollar nuestra nueva versión por la mitad del dinero. Ellos les creyeron y ahora se gastaron todo el dinero, se tardaron todo el tiempo, y terminaron sólo la mitad. Ahora se fueron y el código es un desastre ... y nosotros tenemos que terminar lo que ellos empezaron. Hoy, dele un abrazo a un desarrollador Acabo de terminar un curso intensivo de Visual Basic, de 6 semanas

Debian GNU/Linux Lenny publicado

2009-02-15T11:41:00.010-02:00

Debian GNU/Linux, desconocida para algunos, amada por otros. Esta distribución, que ha sido muy criticada por la "antigüedad" de sus paquetes, es una de las más estables que conozco. Para los que no lo saben, es la base de todas las versiones de Ubuntu y sus derivados. Ayer (14/02/2009), publicaron la versión "Lenny" 5.0, como se muestra en este anuncio. Las mejoras que se destacan son:

Posibilidad de probarlo sin instalarlo, mediante una imagen que puede ser cargada desde un CD, un DVD, una memoria USB, o en forma remota (previa configuración de red).
K Desktop Environment 3.5.10 y GNOME 2.22.2
X.Org 7.3
La inclusión de OpenJDK, una versión totalmente libre del JDK de Java.
Soporte para la plataforma Orion de Marvell.
Nueva adaptación ARM EABI, para plataformas ARM.

Y por supuesto, la confiabilidad de ser una de las pocos distribuciones que se basa en la estabilidad del sistema y no en una fecha específica para hacer una release. Por algo es una de las mejores distribuciones que existen para servidores. Algunas cosas se han dejado de soportar:

Kernel 2.4
No se da más soporte a la arquitectura Sparc32
Apache 1.x fue reemplazado por Apache2
XMMS 1.x fue reemplazado por XMMS2
Algunos firmwares ya no están en el repositorio principal, pero sí en non-free. (por cuestiones de licencias)
FlashPlayer disponible sólo en backport (pero swfdec-mozilla instalado por defecto)

Pueden encontrar una lista completa y detallada de cambios aquí. La página oficial de esta distribución es: http://www.debian.org. Saludos lectores, y hasta la próxima.

JavaPassion: cursos online gratuitos sobre Java

2009-02-14T18:43:00.005-02:00

Hola a todos. En esta oportunidad quiero hacerles conocer una serie de cursos online sobre Java. Los cursos en cuestión son llamados genéricamente JavaPassion. Se trata de varios cursos orientados a las distintas partes y componentes de las tecnologías Java en General. Comenzando desde lo más básico de Java, llegando a tópicos bastante avanzados como la programación con GoogleWebToolkit. Hay también disponibles cursos sobre Ruby, JRuby y Rails, y hasta sobre programación en redes sociales. El curso que más se destaca es el de JavaEE, el cual estoy tomando en este momento y sinceramente es uno de los cursos que más satisfacción me ha dado, ya que es notorio el esfuerzo y tiempo que ha dedicado ha elaborarlos y mantenerlos actualizados. Estos cursos son creados y actualizados por Sang Shin, que trabaja actualmente para Sun ocupando los cargos de Technology Evangelist y Technology Architecture Consultant. La página de JavaPassion es http://www.javapassion.com/. El único problema es que los cursos están en Inglés, pero por suerte, el lenguaje usado en los apuntes es bastante técnico y entendible fácilmente. Espero que les sea de utilidad. Saludos y hasta la próxima

Tahoma negrita en Linux

2009-02-13T14:05:00.008-02:00

Tanto en Ubuntu y sus derivados, como en ArchLinux, siempre es necesario instalar un paquete de fuentes luego de la instalación normal, para que las Webs se visualicen correctamente (o al menos como el diseñador web la diseñó). El problema que existe con estos paquetes de fuentes, es que no incluyen todas las fuentes normalmente usadas en la web, y que por ende estas se dibujan mal en la pantalla. La fuente que, a mi parecer, es la que más hace falta es Tahoma Bold (Tahoma Negrita), tal como se indica en los correspondientes reportes de bugs de Ubuntu y ArchLinux. Como se puede ver en esos reportes, el bug no será solucionado próximamente. Por ello, elaboré aquí una miniguía sobre como solucionar este problema. Los pasos a seguir son: 1) Obtener la fuente correspondiente La pueden obtener de este enlace, o del directorio Windows/Fonts de alguna instalación de Windows (el archivo se llama tahomabd.ttf) 2) Copiarla al directorio correspondiente. En el caso de querer disponer de la fuente sólo para un usuario, debes copiar el archivo en la carpeta /home/usuario/.fonts/ (Si no existe, deben crearla). En caso de querer disponer de ella para todo el sistema, debes copiar el archivo a /usr/share/fonts 3) Refrescar la caché de fuentes. Esto lo hacemos ingresando en una consola como root (o con sudo) y ejecutando el comando fc-cache -vf Esperamos un momento y listo. Todas las aplicaciones que abramos desde este momento, usarán la fuente Tahoma bold correcta.

Lanzamiento de JavaFX 1.1 y Linux

2009-02-12T16:46:00.003-02:00

Como se anuncia en la página oficial de JavaFX, Sun ha lanzando una nueva release de JavaFX, la versión 1.1. En el lanzamiento de la versión 1.0 de esta tecnología, se armó revuelo porque no se había lanzado una versión para Linux. Ni siquiera se lanzó una versión para OpenSolaris, lo cual es raro ya que es un sistema operativo desarrollado también por Sun, y al tomar la política de no lanzar una versión para su propio sistema operativo, me deja pensando sobre las razones que lo llevan a tomar esas acciones. Sun anunció que lanzaría una versión para Linux y OpenSolaris en una futura release. Llegó la primera "futura release" y como era de esperarse tampoco hay una versión para Linux y OpenSolaris. Sun nuevamente anunció que dispondrá de una versión para las plataformas nombradas, en una futura release. Es poco probable que Sun esté evitando intencionalmente lanzar estas versiones. Digo improbable ya que han demostrado un fuerte compromiso con el software libre y las plataformas alternativas a Microsoft. Pero, de todas maneras, me sigue pareciendo raro. Todavía no he tenido la oportunidad de desarrollar en esta plataforma, pero a juzgar por la amplia aceptación que está teniendo, y por la calidad gráfica de las aplicaciones desarrolladas sobre ella, es una tecnología que definitivamente quiero probar y el hecho de no contar con una versión oficial para Linux, es bastante molesto. Destaco la palabra "oficial" ya que es posible usar JavaFx en Linux, con algunas limitaciones. Esperemos que Sun finalmente disponga de una versión para Linux y OpenSolaris en su próxima release, que al parecer será la 2.0 y no falta mucho para que vea la luz. Saludos lectores. Hasta la próxima.

Tamaño de la cache de paquetes en archlinux

2009-02-11T03:38:00.012-02:00

Me disponía a crear una nueva máquina virtual para realizar algunas pruebas, y me encontré con que mi disco estaba bastante lleno. Tengo en la misma partición el sistema base y mi directorio personal, lo cual a llevado a que con el tiempo, se llene de cosas innecesarias. Por ello, me decidí a limpiar mi disco de cosas innecesarias y prescindibles. Como es sabido que en linux la "basura" que se genera es muy poca (hablando de archivos innecesarios), es obvio que usar alguna herramienta automatizada para eliminarla (como en Windows), no es una solución efectiva. Por lo que decidí a analizar el contenido del disco y decidir en forma manual (osea yo) que es lo que se borra y que es lo que no se borra. Para ello, usé una excelente herramienta llamada baobab, o "Analizador de uso del disco" en idioma coloquial. Herramienta que detalla con precisión y profundidad, el uso específico de espacio de cada carpeta, lo cual nos permite determinar qué carpetas están excedidas de peso :). Luego de unos minutos de análisis, los resultados fueron los siguientes: Como puede observarse, las carpetas más voluminosas son /media y /home, llevándose el 66.4% de todo el espacio ocupado. Si bien son las más voluminosas, también son las más difíciles de achicar en tamaño, ya que los archivos que coloco ahí son colocados a conciencia y por ende, son necesarios. Si dirigimos la atención a la siguiente carpeta en orden de tamaño, nos encontramos con /var, la cual representa un "modesto" 20% de todo el espacio ocupado. Es en ella en donde enfocaremos nuestra limpieza. Para ello miremos con detenimiento el contenido de esta carpeta. En la imagen de la derecha, se aprecian claramente las carpetas contenidas dentro de /var y sus respectivos tamaños y porcentajes. Hay un claro dominante y es la carpeta /var/cache con 6 Gib de espacio ocupado. Esto quiere decir que nuestro sistema está ocupando bastante espacio en realizar cacheo de archivos que probablemente no usemos ni en un 5%. Esto es debido a que la cache está muy llena (6 Gib de archivos es demasiado). Por ello, miremos con detenimiento el contenido de la carpeta /var/cache Al observar la imagen de la izquierda, vemos que hay un claro ganador, y es /var/log/pacman. Para los que no conocen mucho de archlinux, pacman es el gestor de paquetes de esta distribución, y como observamos en esta figura, ha dedicado 6 Gib de nuestro de disco a guardar los paquetes que descargamos y luego instalamos. Hecho el análisis y encontrada la raíz del problema, es necesario encontrar una solución. Las solución más obvia sería borrar directamente la cache de pacman con el comando pacman -Scc, lo cual nos llevaría a tener esos 6 Gib de nuevos con nosotros, pero anularíamos completamente la funcionalidad de la cache, por lo que la solución óptima sería eliminar de la cache los paquetes que ya hemos desinstalado y los que se han actualizado (que por ende la versión anterior ya no es necesaria) Esto se realiza muy fácilmente con el comando pacman -Sc . Analicemos ahora los resultados de la limpieza: Como se aprecia claramente en la imagen, hemos disminuido el espacio ocupado por la cache de pacman, de 6 Gib a sólo 1.3 Gib, recuperando casi 5 Gib de espacio y sin resignar el contenido útil de la misma. Cabe aclarar que hay muchas otras maneras de reducir el espacio ocupado innecesariamente. Por ejemplo, podríamos limpiar la carpeta /var/log, la cual está cerca de legar al Gib de espacio ocupado. De todo esta análisis, es necesario sacar una conclusión bastante importante. Si bien linux es un sistema bastante optimizado y eficiente en muchos aspectos, como así también lo son la mayoría de los programas que usamos con el, es necesario revisar esporádicamente en que estado están los distintos componentes del sistema (entre ellos el disco rídigo y sus sitemas de archivos). Esto es válido tanto para linux, como para los otros sistemas operativos.

Creando Servicios Web con Ruby

2009-02-10T17:18:00.020-02:00

Introducción En esta ocasión, mostraré como crear un servicio web (basado en XML-RPC) y publicarlo en nuestra PC, con el lenguaje Ruby. Publicaremos como servicio web, 2 funcionalidades matemáticas, muy básicas, pero que sirven de ejemplo para mostrar como hacer pública una funcionalidad hecha en Ruby. Siendo precisos, publicaremos 2 servicios, uno de suma y otro de resta de números que pertenecerán a un servicio web de nombre "ejemplo". El Código Les muestro el código y luego lo vemos paso por paso.

require 'xmlrpc/server'
server = XMLRPC::Server.new(1234)
server.add_handler("ejemplo.sumar") do |a,b|
    a.to_i + b.to_i
end
server.add_handler("ejemplo.restar") do |a,b|
    a.to_i - b.to_i
end
trap("INT") {server.shutdown}
server.serve

Si corren este código con el intérprete de Ruby, habrán creado y publicado en su propia PC, un Servicio Web. Explicación Vamos por partes. La primera línea del código es esta:

require 'xmlrpc/server'

Con esa línea, importamos la clase Server de la librería xmlrpc, la cual es la que nos permite crear y usar servicios web basados en XML-RCP, de una manera simple. La clase Server es la que utilizaremos para crear y publicar el servicio web. En caso de queramos usar un servicio web, deberíamos usar la clase Client de la misma librería, pero eso lo veremos en otro momento. La siguiente línea que nos encontramos luego del require, es:

server = XMLRPC::Server.new(1234)

Lo que hacemos aquí, es crear una instancia de un servidor de servicios web (webrick para ser exactos) y le indicamos que escuche en el puerto 1234 (en un dejo de originalidad). Esta instancia de servidor de servicios web, se materializa en un objeto de la clase Server nombrada anteriormente. Luego nos encontramos con:

server.add_handler("ejemplo.sumar") do |a,b|
    a.to_i + b.to_i
end

Aquí hace falta un poco más de explicación. El objeto server lo acabamos de crear, y es a este objeto al que le tenemos que indicar que funcionalidades tendrá nuestro servicio web. En este caso estamos agregando una funcionalidad llamada "sumar" a nuestro servicio web llamado "ejemplo". El método usado se llama add_handler, y el mismo requiere como parámetro el nombre del servicio ("ejemplo.sumar" en nuestro caso) y un bloque de código, que es el bloque de código que ejecutaremos cuando se invoque al servicio web. A este bloque de código le pasamos como parámetro 2 variables, las cuales convertimos a números y las sumamos con la siguiente línea de código

a.to_i + b.to_i

Como esa línea es la última del bloque de código pasado al método add_handler, entonces el resultado de esa línea de código es lo que devuelve la invocación del servicio web, es decir, la suma de "a" y "b". Luego nos encontramos con un bloque de código similar al anterior:

server.add_handler("ejemplo.restar") do |a,b|
    a.to_i - b.to_i
end

La única diferencia, es que ahora publicamos una nueva funcionalidad del servicio web "ejemplo", llamada "restar", la cual tiene los mismos parámetros pero en vez de sumarlos los resta. Continuando, vemos:

trap("INT") { server.shutdown }

Aquí lo que hacemos es atrapar la señal "INT" que nos peude llegar a enviar el sistema operativo para cerrarnos. Si el sistema nos envía esa señal, nuestro código ejecutará el bloque pasado por parámetro. En nuestro caso, lo único que hace ese bloque es parar el servidor. La última línea que encontramos es:

server.serve

Esta le indica al servidor que arranque. Desde este punto en adelante, tendremos el servicio web andando y disponible. Comentarios finales En este caso, hemos publicado servicios de una manera un poco forzada, especificando directamente el código que queremos ejecutar cuando se invoquen esos servicios. En otro oportunidad, mostraré como publicar como servicios web las funcionalidades encapsuladas en una clase, evitando especificar directamente el bloque de código en la llamada al método add_handler de la clase Server. Nos vemos y hasta la próxima.

Crear un servlet con Ruby

2009-02-10T04:38:00.013-02:00

Bueno, en este corto tutorial voy a mostrar como hacer un pequeño Servlet en Ruby. Para ello me voy a valer de la librería webrick para montar el servidor que escuche las peticiones. Por si no saben lo que es servlet, es algo así como un programa puesto en la red (internet o red local) el cual escucha peticiones y lo podemos invocar desde nuestro navegador web, pasándole datos inclusive. Este programa procesa el pedido que le hacemos, y nos devuelve un resultado, por lo general una página web que es visualizada en el navegador. El código de un servlet básico es el siguiente:

require 'webrick'
class MiServlet < WEBrick::HTTPServlet::AbstractServlet
    def do_GET(request, response)
        response.status = 200
        response.content_type = "text/plain"
        response.body = "Hola mundo!"
    end
end
server = WEBrick::HTTPServer.new( :Port => 1234 )
server.mount "/", MiServlettrap("INT"){ server.shutdown }
server.start

Como pueden ver es bastante simple. En la primera línea importamos la librería webrick, la cual nos permitirá levantar un servidor web y hacerlo escuchar en un puerto específico. En la segunda línea, nos ocupamos de crear una clase que herede de AbstractServlet (clase importada de la librería webrick), esta nos da la funcionalidad básica para implementar el servlet. Lo único que tenemos que hacer, es implementar el método do_GET o do_POST, según la respuesta que queramos dar. En nuestro caso, usamos do_GET y respondemos con una página simple que sólo tiene un texto corto adentro. Con esas líneas ya creamos el servlet. Ahora es necesario crear una instancia del servidor web que escuche en el puerto 1234 y que canalice las peticiones a nuestro Servlet. Por último, arrancamos el servidor, y LISTO. Si has programado en Java, probablemente veas bastantes similitudes con los Servlets de Java, esto así porque la idea detrás de esta funcionalidad, es la misma en ambos casos. Espero que les haya sido de utilidad.

Instalando KDE 4.2

2009-02-09T19:35:00.003-02:00

Como comenté en una entrada anterior, me dispuse a instalar KDE 4.2 en mi notebook. La misma ya tiene toda una instalación de ArchLinux funcionando con Gnome. Si revisan la wiki de ArchLinux, en este artículo encontrarán que por un tema de modularidad, es mejor instalar una versión modificada de KDE, llamada kdemod, en lugar de la versión oficial publicada en los repositorios de ArchLinux. Instalé kdemod, siguiendo los pasos que indica la web oficial, y luago de un rato, tenía kde corriendo en mi notebook. Los problemas no se hicieron esperar. No pude hacer una evaluación con algún grado de profundidad, ya que luego de instalarlo y de iniciar mi Gnome, me di cuenta de los problemas que esta instalación generó. En principio, cuando inicié Gnome quedó seleccionado por defecto el WindowManager de Kde (llamado Kwin), lo cual trajo varios problemas en los efectos gráficos y hasta reinició el servidor gráfico en forma forzada en 2 ocasiones. Luego de iniciar Gnome y de establecer metacity como WindowManager, voy al menú y me encuentro con listas de aplicaciones realmente largas, al punto de tener que poner un scroll en los menús ya que no entraban todos los items a lo alto de la pantalla. Luego de reiniciar la notebook, me encuentro con que el inicio de Gnome ahora tarda casi el doble de lo que tardaba previo a la instalación de kdemod. Además del tiempo tardado, veo con asombro que las particiones de mi disco (salvo el raíz) no se habían montado. Esto se debe a que por alguna extraña razón, dejó de funcionar hal. Decidido a borrar kdemod de mi sistema, me remito a la web oficial nuevamente, y sigo el proceso de desinstalación de kdemod. Luego de terminado el mismo, reviso un poco en detalle lo hecho por pacman, y veo que dejó instalado casi 80 paquetes pertenecientes a kdemod, los cuales tuve que borrar manualmente. Entre los paquetes que dejó la instalación/desinstalación de kde, me llamó la atención que estuviese uno llamado lilo. Lilo es un boot loader, y me llama mucho al atencion que kde dependa de un boot loader, y en todo caso que no respete y use, el bootloader instalado previamente (GRUB en mi caso). Resumiendo, es claro que la mayoría de estos problemas no son responsabilidad de KDE, y que tranquilamente pueden ser evitados, procediendo a instalar KDE en una instalación que no tenga ya en entorno de escritorio, o como actualización a una version anterior de KDE. Por lo pronto, me dispondré a tratar de solucionar los problemas nombrados, y cuando tenga un poco más de tiempo, probaré KDE 4.2 en un entorno limpio.

Gnome funcionando con Kwin

2009-02-09T05:36:00.008-02:00

Hoy me disponía a probar KDE 4.2, debido a su reciente lanzamiento y para hacer algunas comparativas con respecto a mi actual instalación de Gnome. Tras algunos minutos de descargas y algunos más de instalación, doy inicio a tan acabado entorno gráfico. Realmente una belleza. Como siempre, existen algunos problemas de integración entre ambos escritorios, así que me dispuse a iniciar Gnome para mis tareas normales. Cuál fue mi sorpresa al ver que mi Gnome, tenía un look distinto al que tenía previamente. De hecho un look muy parecido al de KDE 4.2. Chequeando la configuración de compiz-fusion, veo que habia quedado seleccionado el WindowManager de KDE (llamado Kwin) en vez del WindowManager de Gnome (llamado Metacity). Sinceramente es grande mi sorpresa al ver que 2 piezas de software que están hechas para funcionar en ambientes de escritorio con filosofías opuestas, puedan funcionar tan apaciblemente. De hecho es sorprendente que hayan funcionado sin errores!! Acá les dejo un video y una foto para que vean con detalle. Como se puede ver en la imágen, los bordes de las ventanas están totalmente administrados por kwin. Se puede apreciar en el video que los efectos gráficos también están proporcionados por el mismo WindowManager. Estos son los beneficios (involuntarios en este caso) de programar bajos los estándares establecidos.

Estrenando un blog

2009-02-09T03:21:00.005-02:00

Hola a todos. En principio quería agradecerles a todos los visitantes por invertir un rato de sus tiempos en navegar por este, mi espacio personal destinado a publicar, comentar y discutir, sobre todas las cosas que me parecen curiosas e interesantes sobre el mundo de la programación (específicamente en Java y Ruby), linux y el mundo de la computación en general. Soy un tanto novato en Ruby, ya que lo descubrí hace algunos meses buscando una alternativa más ágil al desarrollo de aplicaciones web. Como tenía muy buenas referencias del framework Ruby on Rails, empecé a aprender un poco de él y me di cuenta que si no sabía Ruby, no me iba a ir bien con Ruby on Rails. Así que me decidí a aprender Ruby primero y me terminó gustando como lenguaje de programación (a pesar de que no veo con muy buenos ojos los lenguajes interpretados y de tipos débiles). Con respecto a Java, llevo varios años usándolo como lenguaje principal y ya 2 años en el ambiente profesional. Como a la mayoría de las personas que lo han usado, me parece un excelente lenguaje de programación de aplicaciones de escritorio y uno de los líderes en el ámbito de las aplicaciones empresariales. También soy asiduo de algunos lenguajes de menor nivel (más cercanos al hardware) como C y C++ (principalmente). Si bien presentan ventajas únicas a la hora de la optimización en el uso de recursos, combinado con la potencia de la orientación a objetos (C++), la disponibilidad de librerías y el tiempo de desarrollo quedan relegados frente a lenguajes más potentes como Java o .NET. Como siempre he dicho, cada tecnología tiene su campo de aplicación, y ninguna es totalmente mejor que otra. Siempre hay que considerar el uso que se le dará a esa tecnología. Soy usuario del sistema operativo Linux, específicamente de la distribución ArchLinux, y apoyo en general los principios del software libre, aunque no hago de ello una religión. Actualmente estoy estudiando Ingeniería en Sistemas de Información en la UTN y por suerte me queda un año nomás. Bueno, espero que puedan sacar algún provecho de mi blog. Saludos visitantes.