4 trucos, consejos o tips para el programador

Aunque es estado un poco offline ultimamente, por cuestiones de trabajo, hay que hacer labor de blogger y postear una que otra vez, que sino el blog se me va al piso. En esta ocasión recomendarles unos consejitos que recopilé en las últimas dos semanas, de dos fuentes recomendadas: Yo, programador y javaHispano. Hay van…

Consejos para programar en Swing

Un listado de consejos y buenas prácticas para desarrollar en Swing. No son patrones, no son trucos, son consejos desde el dolor de haber sufrido durante tiempo fruto de la experiencia y del día a día. No los pases por alto si te vas a meter de cabeza con Swing:

• En la aplicación sólo debe haber un único JFrame, correspondiente a la aplicación principal. Todas las ventanas secundarias deben ser JDialog. Todas las ventanas secundarias deben tener una ventana padre, que es a partir de la cual se despliega. Es decir, todos los JDialog secundarios deben tener como padre al JFrame principal. Si desde un JDialog se va a visualizar otro, este segundo debe tener como padre al primero, y así sucesivamente.
• Evita en lo posible los JDialog modales, o ten muy en cuenta su jerarquía de padres. El primer JDialog modal no tiene problemas si le pones su padre adecuadamente. Si tienes un JDialog modal visible, no muestres otro JDialog secundario, salvo que también sea modal y sea hijo del anterior. Si pones visibles a la vez dos JDialog modales y no son el uno hijo del otro, tendrás problemas al intentar escribir en ellos o cerrarlos.
• Nunca heredes de JFrame o JDialog o JApplet para hacer tus ventanas. Hazlo siempre de un componente que no sea ventana y que no te limite. Si tus ventanas heredan de JPanel, podrás ponerlas siempre que quieras dentro de un JFrame, un JDialog, un JInternalFrame, un JApplet o incluso incrustarlas en otro JPanel. Si tu ventana hereda de JFrame, está condenada a ser un JFrame toda su vida.
• Reaprovecha las ventanas, no se las dejes al recolector de basura. Si un botón, al apretarlo, visualiza un JDialog, no hagas un new de JDialog cada vez que pulsas el botón. Es mejor hacer sólo un new la primera vez y guardarselo. En las siguientes veces bastará con hacer setVisible(true) y setVisible(false). Para que el recolector de basura libere una ventana, además de lo habitual, hay como minimo que llamar al método dispose() de dicha ventana -cosa que mucha gente no sabe- , para que el sistema de eventos de teclado y ratón eliminen todas las referencias que tienen a ella. De todas formas, incluso así no tengo muy claro que los JDialog se liberen siempre y, desde luego, en versiones anteriores de Java, los JFrame NUNCA se liberaban. La excusa de SUN es que como sólo debía haber un JFrame principal, no tenía sentido liberarlo.
• Los layouts para situar componentes no son tan complicados, sólo hay que ponerse a ello. No uses el layout null, ya que tu ventana no será redimensionable y puedes tener problemas si cambia la fuente de letra, si tu programa se ejecuta en otro sistema operativo, se cambia el look & feel, etc.
• Una vez que sepas los layouts simples, tenderás a hacer ventanas grandes a base de anidar muchos JPanel que a su vez tienen dentro JPanel que su vez tienen dentro JPanel, todos ellos con un layout simple. Eso hace ventanas muy pesadas y que consumen mucho. Aprende a usar el GridBagLayout para hacer un solo panel con todo. La excepción a esto es que tengas pequeños JPanel reutilizables, como un editor de coordenadas geográficas que pida latitud, norte/sur, longitud, este/oeste, un panel que pida usuario y password, etc.
• Todos los eventos de ratón y teclado se ejecutan en el mismo hilo que repinta las ventanas. Si en un actionPerformed(), keyPressed(), … tu código tarda mucho o pretendes que se pinte algo en una ventana, simplemente no lo hará hasta que tu código termine. Si tu código en un actionPerformed() va a tardar mucho o tiene que pintar cosas en la ventana, lanza un hilo aparte para hacer esa tarea y termina el actionPerformed() lo antes posible.

Los diez errores más comunes en el diseño de una base de datos

Un poco off-topic este enlace pero creo que es bastante interesante para la mayoría de los desarolladores que consultan este portal. Louis Davidson es un experto en el diseño de Base de Datos y es autor del libro SQL Server 2005 Database Design and Optimization en el artículo aquí enlazado presenta los diez errores más comunes en el diseño de una BD que el ha detectado a lo largo de su experiencia:

• Mala planeación del diseño
• Ignorar la normalización
• Estándares de nomenclatura deficientes
• Falta de documentación
• Una sola tabla para guardar todos los valores del dominio
• Usar columnas GUID como la única llave de una tabla
• No usar las funcionalidades SQL para preservar la integridad de los datos
• No usar Stored Procedures para acceder a los datos
• Intentar construir objetos genéricos en los stored procedures
• Falta de pruebas

En mi experiencia la mayoría de los desarrollos donde he trabajado presentan algunas de estas deficiencias en su base de datos. Creo yo que en muchos de los casos es porque se deja a un programador diseñar la base cuando debe ser haber un DBA involucrado en el proceso. Se que muchos proyectos no pueden pagar el sueldo de un DBA en exclusivo pero creo que al menos debe haber un DBA por organización que supervise el diseño elaborado por los programadores, lo mejore y le de su visto bueno.
Con las bases de datos pasa como con el diseño web, cuando se deja en manos de un programador el resultado puede ser un desastre e imagino que la mayoría de ustedes ha tenido que lidiar con chapuzas como una tabla totalmente desnormalizada (digo a veces está bien desnormarlizar para ganar en desempeño pero hay límites) y que necesita de 5 o más campos para tener una llave compuesta (y dile adios a tu idea de usar un ORM para la capa de datos), o una tabla con 20 campos que se llaman campo1, campo2, .. campoN y que nadie en la organización sabe que diablos es el campo7 o quién era el encargado de actualizarlo pero sin él tu aplicación no funciona, en fin no seguiré descargando mi frustración aquí . En mi opinión una forma de evitarle frustraciones a los otros programadores es que, dado que las empresas no van a querer pagar un DBA para auxiliarte en el 70% de los casos,nosotros nos documentemos con artículos como el de Louis para realizar un mejor trabajo que programar no es solo usar Spring o el último patrón de diseño.

Los 12 principios sobre test unitarios

Alberto Savoia ha dejado una entrada en su blog donde nos descubre los secretos del buen hacer con tests unitarios. Está escrito con toques de humor, a modo de manuscrito antiguo y es, sin duda, una amena lectura para la vuelta al tajo (y al debate). Les traduzco los 12 principios con los que concluye su artículo (corregirme si se me ha pasado algún juego de palabras):

• Si escribes código, escribe tests.
• No seas inflexible siguiendo el dogma del test unitario.
• Abraza el karma del test unitario.
• Piensa en código y test como un todo.
• El test es más importante que la unidad.
• El mejor momento para hacer tests es cuando el código está fresco.
• Hacer tests no es perder el tiempo.
• Un test imperfecto hoy es mejor que un test perfecto mañana.
• Un test feo es mejor que ningún test.
• A veces, el test justifica los medios.
• Sólo los tontos no usan herramientas.
• Los buenos tests fallan.

10 problemas de rendimiento de J2EE

Siguiendo con los listados “top” de los últimos días, me entero vía TSS de la lista de los 10 errores de rendimiento más comunes en las aplicaciones J2EE. Coincido con algunos de ellos y otros me dejan perplejo. Traduzco y comentamos :

• 10. Excesivo Logging
• 9. Configuración del Serv. de Aplicaciones incorrecta.
• 8. Uso incorrecto de Java EE
• 7. Uso innecesario de XML
• 6. Configuración de Caché incorrecta
• 5. Uso de memoria excesivo
• 4. Pobre rendimiento de librerias de terceros
• 3. Mala implementación de concurrencia
• 2. Remoting innecesario (remoting es una llamada a un elemento local como si fuera externo).
• 1. Uso incorrecto de la base de datos.

Sin más, un saludo, y espero que les sirva de algo!!!

8 Comentarios | deja el tuyo