Java es perjudicial para la ingenieros del mañana

Bien, ahora que tengo tu atención querido lector, puedo detallar un poco más esto. En realidad, creo que ha habido una gran confusión, en un comentario anterior, me pasaron el siguiente artículo titulado: "Eminencias informáticas: 'Java es perjudicial'".

Ahora bien, antes de opinar, lo mejor es ir a la fuente directamente y leer el paper original para saber con exactitud que están diciendo estas "eminencias". Encontré el artículo, pero estoy seguro que debido a la extensión .mil de la url que lo presenta, no se puede ingresar directamente. Pero decidí no darme por vencido encontrar alguna forma de ver el artículo. Aquí tienen 2 opciones:

1. Google Caché: pueden seguirlo en este link, pero no hay imágenes (de todos modos no importa ya que las únicas imágenes que aparecen son los 2 "eminentes").
2. Estos .mil hijos de "mil" discriminan a los que pueden ver el artículo por la dirección ip, así que usando el querido Anonymouse.org, se puede ver en este link.

Ahora que todos podemos ver el artículo, quiero mandarle UN SALUDO GRANDE a los servidores de la U.S. Airforce


Realizada mi descarga de rabia, pasaré a expresar mi opinión del artículo. Los autores presentan tres tendencias fundamentales de los ingenieros de software actuales y futuros. Concuerdo completamente con estas falencias, especialmente con una presente consecuencia "We are training easily replaceable professional".

Perspectiva personal - experiencia diaria

El otro día me puse a ver unas charlas de Google Developers acerca de Cluster Computing y Map Reduce (por cierto, tengo que escribir de esto y lo recomiendo muchísimo). Varios algoritmos de árboles y grafos, super interesante. Lo malo fue que para resolver un problema, el presentador empezó a hablar de LISP y lenguajes funcionales. Lo único que vi en la facultad de LISP es "QUE ES UN LENGUAJE FUNCIONAL!!!!!". Tengo como pendiente estudiar un poco más de este paradigma, realmente me avergonzó no saber que es el cálculo lamda y cómo maneja las listas este lenguaje.
En ese momento me di cuenta de que no tengo una formación demasiado amplia en cuanto a paradigmas, salvo por la orientación a objetos y funcional. Pero los demás también sirven!!!!

Perspectiva educativa local - Argentina - Córdoba - UTN

Bien, los que cursan o cursaron hasta hace poco en esta universidad, sin duda pueden ver lo "actualizado" que estamos en relación con universidades estadounidenses. Yo tuve la suerte de comenzar en primero y segundo año con C y C++, después aprendí Java por mí cuenta. Desde hace 3 o 4 años se abandonó C y C++ en favor de Java.

Hagamos una comparación sencilla: Como alumno, después de aprender C++ (y ni siquiera en profundidad), aprender Java fue cosa de niños, la verdad. Sin embargo, me doy cuenta como profesor que enseña Java como lenguaje inicial de lo difícil que les resulta a las nuevas generaciones de programadores, realmente complicado. Y la verdad es que esto me pone un poco nervioso. Y ni siquiera estamos hablando de punteros (a.k.a. apuntadores).

Qué quiere el mercado de ti, querido programador?

Salvo que actualmente no estés trabajando, esta pregunta tiene respuesta sencilla: el mercado quiere piezas intercambiables con facilidad, que sepan lo mínimo e indispensable para terminar las altas, bajas y modificaciones usando Struts, Hibernate, Spring, etc. sin saber bien porqué esos requerimientos (tal vez moda, tal vez recomendación de otros desarrolladores, etc).
Ah, por si no te has dado cuenta, las "pieza intercambiable" eres tú, querido desarrollador. Pero este debate con tintes sindicalistas es harina de otro costal y para otra oportunidad.

Para resumir, el mercado no quiere que reinventemos la rueda, si ya está hecho, no hace falta hacerlo de nuevo, lo que también se puede traducir en "No intentar mejorar lo que está hecho", "No innovar", "No pienses mucho", etc.

Si, mucho bla bla, pero cuál es la conclusión de todo esto?

La conclusión no es ni revolucionaria, ni novedosa, ni pro ni en contra Java, C, C++, LISP. Te lo explicaré con un ejemplo:

Hace varios años fui a una entrevista de trabajo, donde me preguntaron cuál era el mejor lenguaje según mi consideración. Mi respuesta fue C++ y nunca me dieron el trabajo. Por supuesto reflexioné sobre el tema durante mucho tiempo y me di cuenta de la mejor respuesta a era: "Depende ¿Qué problema intentas resolver?"

Y que mejor para resolver un problema, que conocer las opciones que tenemos a mano para resolverlo. Estas opciones NO SON LENGUAJES, son PARADIGMAS de programación.
Si el único paradigma de programación que aprendemos es el orientado a objetos, entonces es probable que podamos resolver muchos problemas, pero siempre quedará la duda: "¿Habrá algo mejor?"

Recuerda: "Cuando la única herramienta que tenemos a mano es un martillo, todos los problemas son clavos"

Saludos

Pablo

Buscando algoritmos (supergeek post)

Este es uno de los posts más "supergeeks" que voy a escribir (y por suerte, no será el último). Pero la verdad es que he disfrutado mucho con el resultado de la búsqueda.
No es nada del otro mundo, pero no sabía que en la mejor enciclopedia on-line (wikipedia), existían un listado tan interesante de algoritmos. Muchos de ellos ya los conocía pero lo había olvidado, otros, son completamente nuevos (para mí), lo que me hace feliz, la verdad, siempre hay algo para aprender.
No intenten buscar el código fuente para cada uno de ellos, algunos son puramente teóricos o dependen del problema que se quiera resolver.
Dentro de las categoría que más me interesaron están las de "2 Compression algorithms", "6 Cryptographic algorithms", "8.3 Operating systems algorithms", "10 Neural networks" (estos me los tengo que aprender bien para rendir Inteligencia Artificial), "14 Numerical algorithms" (cuantos recuerdos).

Uds. se preguntarán: ¿Esto es lo que hace en sus vacaciones? Respueta: si, entre muchas otras cosas. "Carpe Diem Memento Mori" . Hoy me levante y decidí como vivir este día.

Saludos
Pablo

Educación, Trabajo y Tecnología

No hay nada para agregar, sólo visita el siguiente link del blog de Franco Iacomella:

Educación, Trabajo y Tecnología

Saludos
Pablo

Splash Screen con SwingWorker

Me han pedido que haga un ejemplo de una ventana de Bienvenida / Cargando con SwingWorker. El ejemplo en sí es bastante básico, pero creo que servirá para ilustrar el uso y una posible solución (quizá no la mejor de todas).

Esta pantalla (no estaba muy creativo) se va a mostrar cuando se inicie la aplicación (perdón por la calidad de la animación, creo que estoy decayendo en la calidad de los tutoriales):

Esta pantalla es el puntapié inicial para el resto de mi aplicación (es el que tiene el void main). Aquí se genera un worker que actualiza el label de descripción de carga. La actualización es realizada usando el Thread.sleep(); para que tenga exactamente 1 segundo de duración entre actualización y actualización. Veamos parte del código que lo realiza:

La clase MiSwingWorkerInit es una inner class de la ventana emergente WelcomeWindow. Básicamente, la clave de ejecución está en el método doInBackGround() el cual lo único que hace es seleccionar el mensaje que se mostrará. En una aplicación real, aquí deberían realizarse todas las actividades previas a la carga de la pantalla principal de la aplicación. Una aclaración adicional, si se fijan estoy usando el método this.setProgress(100); con el único propósito de que se ejecute un evento interno del swingworker. Este evento notificará a la aplicación general de que se ha terminado el proceso y que puede seguir cargando la pantalla principal.

¿Dónde se inicia el proceso del SwingWorker? En el siguiente código pueden visualizarlo:


Es bastante simple el inicio de su ejecución, lo único que hay que hacer es instanciar un objeto de SwingWorker y darle execute(). Pero hay algo más interesante aquí, la llamada al método addPropertyChangeListener(this); bueno, lo que hago aquí es pedirle al worker que me avise (en forma de evento) cuando ocurra algún cambio en alguna propiedad. Ahora, si se fijan en la primera porción de código, notará que esto ocurrirá cuando se invoque al método setProgress(100) del worker. Si bien esto se podría hacer como una clase anónima al mejor estilo eclipse y los actionPerformed, no me queda otra opción que declarar a la misma ventana para que implemente la interfaz PropertyChangeListener, ya que de otra manera, no podré llamar a setVisible(false).
Por supuesto, el implementar la interfaz, hace que deba tener en la clase el método propertyChange, de la siguiente manera:



Cuando en este método verifique que ha cambiado la propiedad "progress" (interna del SwingWorker), entonces puedo sacar la ventana de Cargando y mostrar la ventana Principal.

Fácil, ¿no?

Cualquier duda, no duden en consultar, les dejo el link con los fuentes (hecho en eclipse) aquí.

Saludos
Pablo

Tomcat vs JBoss vs Gerònimo vs GlassFish

Retomando la lectura de los newsletter de The Server Side, llegué a un artículo de The Java World, donde se comparan Tomcat, JBoss y Gerónimo.
El artículo en sí está bastante bueno, se nota que el autor tiene bastante experiencia en la instalación y configuración de los servidores en distintas plataformas, aunque el benchmark realizado no es precisamente el más completo de todos.

Ahora, la parte más interesante la pueden ver en los comentarios, no sé si el autor se olvidó o lo hizo a propósito, pero nunca mencionó a GlassFrish de Sun, ¿que sucedió? inmediatamente los defensores de GlassFish atacaron de a montones. Debo confesar que me causa mucha gracia cuando los comentarios muestran que lo quieren matar al buen hombre (matar en sentido figurado, por supuesto).

De todos modos, el benchmark en sí está incompleto sin GlassFish y por lo menos alguno comercial, así se podría ver en un mejor espectro las diferencias, ventajas y desventajas de cada uno. También hay que considerar algo muy importante que quiero suponer que todos nos preguntamos antes de elegir cualquier servidor/contenedor: ¿Cuáles son los requisitos de mi aplicación? ¿Cuál es el volúmen de usuarios que accederán en las horas pico? ¿Qué tan eficiente es el uso de las sesiones, cuánta información promedio se almacenará durante cuánto tiempo?, etc, etc.

Algunos links:
-Contraofensiva en Java.net, aquí
-Matriz de servidores en The Server Side (muy desactualizada), aquí

Saludos
Pablo

LANCOR vs OLPC

En noviembre del año pasado nos enterábamos que una empresa Nigeria (Lancor) iba a demandar a OLPC (One Laptop per Child) debido a que supuestamente se habían infringido patentes en los drivers del teclado para XO (el sistema operativo de OLPC).
Bueno, finalmente ha llegado a la justicia esta demanda por U$S 20.000.000 y como si fuera poco, también piden la prohibición de entregar laptops OLPC en todo Nigeria. Además parece que todo el proceso va a durar varios meses (como estamos acostumbrados todos los que vivimos en el tercer mundo)

Yo personalmente espero que la justicia no se duerma, o al menos no se corrompa y que permita seguir los intentos por eliminar el analfabetismo digital (si, ya sé lo que estás pensando, pero nunca pierdo las esperanzas, me gusta soñar).

Fuente: CNet Blogs

Saludos
Pablo