Category : General

Primera lección

Primera lección
para novatos de
Java

Más recursos

Otra página de ayuda, si quieres darte una idea de todos los Frameworks, librerías, ERPs, CMS, proyectos open source y todo lo que rodea Java aquí te dejo la liga de esta página de referencia.

http://java-source.net/


Recursos para el programador ocupado

Interesante página con muchisimas fichas técnicas en PDF sobre varios lenguajes y tecnologías, muy recomendable.

Encontraras referencias sobre Java, C, C#, C++, Perl, Python, Linux, Ruby, etc…

 la liga: digilife.be


Algunas cosas que solemos decir los programadores

Algunas cosas que solemos decir en nuestra profesión:

  • «Funcionaba en mi computadora. Ven conmigo y velo por ti mismo si no me crees»
  • ¿Quién te dio el usuario admin?  ¿Eres administrador?
  • «No es un error, es sólo otra de sus funciones»
  • «Eso es raro…»
  • «Nunca había hecho eso antes…»


  • «Ayer funcionaba»
  • «¡¿Cómo es posible?!»
  • «Revisaste la conexión de red, configuración?» (Especialmente si la aplicación se vuelve muuuy lenta)
  • «¿Metiste datos erróneos y falló?»
  • «Hay algo extraño en tus datos»
  • «¡No he tocado el código en semanas!»
  • «Has de tener una versión equivocada de librerías»
  • «Debe haber sido una coincidencia desafortunada, así que no molestes»
  • «¡No puedo hacer pruebas unitarias de todo!»
  • «No fue error mio, debe ser algo en la librería Open Source que estamos usando»
  • «Esto funciona, aunque no he escrito ninguna prueba unitaria»
  • «Alguien debe haber movido mi código»
  • «¿Ya revisaste si no tienes virus en tu computadora?»
  • «Bueno a pesar de que no funciona, ¿Como se siente con la aplicación?»
  • «No puedes usar esta versión en este sistema operativo»
  • «¿Qué es lo que quieres hacer metiendo esos datos?»
  • «¿Dónde estabas cuando la aplicación se cayó?»
  • «Estoy seguro de que eso lo arregla»
  • «¿Ya reinició el servidor?»
  • «¿Que versión de JRE/JDK/JVM tienen instalada?»

Tomado del artículo original de javacodegeeks.com


El primer paso para tu recuperación

…admitir que tienes un problema

Como escribir buen código


Integración JavaServer Faces 2.0, Spring 3 y Hibernate 3 con MySQL en Netbeans 7.0 y Maven

Un video donde mostramos como integrar JavaServer Faces 2.0 con Spring 3 y Hibernate 3 de forma esquemática.  La intención es tan solo de dar una idea de como están estructuradas las carpetas, clases y archivos de configuración, así como dependencias de librerías.  En este ejemplo nos conectamos a una base de datos MySQL y desplegamos una lista de usuarios. El script de la tabla utilizada viene comentado en la clase UsuariosObj.  El proyecto es creado en Netbeans 7, con Maven lo que lo hace portable entre diferentes IDEs.

Todos los archivos de configuración y clases están en un archivo para su descarga y no es necesario poner atención al detalle del código escrito durante el video.  Las librerías se descargarán en cuanto se construya el proyecto desde Netbeans.

El código se puede descargar de: IntegracionJSF2Spring3Hibernate3.zip


Quince Principios Que Un Ingeniero De Software Debe Seguir

Una lista de quince principios que un Ingeniero de Software quizá debería seguir.

  • Mantén en mente los fundamentos.  Si olvidas los conceptos básicos de los lenguajes de programación estás perdiendo tu conocimiento más fundamental.  Lo cual no es buena idea.
  • Asume siempre el peor escenario.  Si tuviste una educación formal en ciencias de la computación, quizá aprendiste algo acerca de la notación “big-O” que te dice el costo de un algoritmo, si es lineal o cuadrático por ejemplo. Saber cuando un algoritmo no tiene manera de ejecutarse rápidamente es importante.



  • Prueba tu código. Asegúrate de probar tu código.  Dependiendo del método que uses, puedes manejar pruebas en varios niveles.  Pero siempre debes crear tantas pruebas como puedas.
  • No emplees nuevas tecnologías sólo porque son nuevas, úsalas para resolver problemas. Como tecnólogos, tendemos a usar las herramientas más nuevas con la esperanza de arreglar las cosas mágicamente.  Que sea útil es la clave, aunque no sea lo máximo.
  • Leer, y mucho. Si no lees acerca de la industria tarde o temprano quedarás fuera de ella.
  • Prueba nuevas técnicas y tecnologías.  Esto no se contrapone con lo dicho anteriormente. Es necesario probar cosas nuevas para determinar si puede ser útil.  Probar cosas nuevas ayuda a aprender y a mantenerte al tanto de la industria.  Prueba sin poner en riesgo un proyecto crítico.
  • Si falla aprenderás algo.  Si tu código falla al menos aprenderás porque no funciona y refinarás la solución.  En algunos casos, se puede considerar a la falla como un pequeño éxito.
  • Cambia el software.  Algunas veces se necesita simplemente terminar el trabajo, pero se debe estar consiente de la deuda técnica que se adquiere. Si simplemente se entrega software sin remover la deuda técnica de forma continua, a la larga el proyecto será una verdadera pesadilla cuando demasiados errores se hayan acumulado.
  • Hacerlo de la “forma correcta”. Muchos desarrolladores tienen la idea de una «forma correcta» de diseño y desarrollar aplicaciones, pero esto puede no ser lo ideal para el proyecto o puede estar sobrado. Esto parece una contradicción con el punto anterior, pero lo ideal es conservar un balance.
  • Deja el código mejor de lo que lo encontraste. En vez de predicar los beneficios de la refactorización, piensa si quieres mantener una pila de código que se vuelve cada vez peor. Si se limpia un poco cada vez que se modifica entonces no será tan difícil después.
  • Ten en cuenta siempre la concurrencia. Si estas construyendo una aplicación web, y no nos referimos a algo de la escala de Facebook, cosas raras pueden ocurrir con la carga excesiva.  Siempre que se tenga una aplicación con una concurrencia de usuarios mayor a 100 pueden ocurrir cosas raras cuando se lee y se escribe sobre algunos recursos, como en las instancias de HashMaps y esto es solo alguna de las cosas de las que te debes preocupar.
  • La cantidad de almacenamiento puede ser libre, pero la transferencia apesta.  Quizá piensas que escribir todo en disco es una forma excelente de persistir datos. Generalmente lo es, pero si usas el almacenamiento en disco para guardar recursos temporales sin depurar, tu aplicación podría volverse lenta muy rápidamente.  El almacenamiento debería limitarse a aquellos datos que necesiten persistir por largos periodos de tiempo, o cuando los datos no pueden residir en memoria.
  • La memoria no puede llegar tan lejos como se piensa.  Para comenzar, muchos tienen sus aplicaciones y sus bases de datos en el mismo servidor. Esto es perfectamente aceptable hasta que ambos requieran de mucha RAM.  Por ejemplo típicamente se tiene una aplicación con Tomcat a 528MB, no obstante una vez que se tiene que lidiar con el almacenamiento persistente (RDBMS, NoSQL, etc) frecuentemente se puede pasar hasta los 8GB y las cosas pueden ponerse difíciles. Obviamente, esto depende mucho de los usuarios que acceden al sistema y de cuantos datos almacenan.
  • El almacenamiento en cache lo arregla todo hasta que tira al servidor. Si se buscan mecanismos para liberar de consultas excesivas a la base de datos, se termina usando una especie de cache.  El problema es que el cache puede terminar usando mucha más memoria que la que se usa de forma típica, especialmente cuando se tiene que lidiar con datos que dependen del numero de usuarios que acceden. Lo peor de usar un cache es que se puede llegar al punto en que se genere un error OutOfMemory, por mencionar el caso de java.  En este punto, el servidor caerá o dejará de responder y el cache no será de ninguna utilidad y se habrá convertido en parte
    del problema.
  • Piensa como un consultor.  Con los empleados algunas empresas tienden a cambiar las cosas.  Los plazos se pueden mover, el alcance puede aumentar y el desarrollador tiene que encontrar la manera de cumplir con estas nuevas restricciones.  Es necesario que se deje en claro que los plazos no pueden moverse debido a que el trabajo necesario para hacer las cosas no cambia o que el alcance no puede aumentar sin hacer lo mismo con el número de recursos disponibles.  Los consultores tienden a administrar los proyectos de forma diferente que los empleados y está en estos últimos cambiar esa regla.

Buenas prácticas para el uso de Bases de Datos

  1. Usa nombres consistentes y bien definidos para tablas y columnas (ejemplo: Escuela, CursoEstudiante, etc)
  2. Usa nombres en singular para las tablas (Estudiante en lugar de Estudiantes).  La tabla representa una colección de entidades, pero no es necesario usar nombres en plural.
  3. No incluyas espacios en los nombres de la tablas.


  4. No uses prefijos innecesarios  (como TblEscuela, o EscuelaTabla, etc.)
  5. Mantén los passwords encriptados por seguridad. Desencriptalos en la aplicación si es necesario.
  6. Usa enteros como identificadores para todas la tablas.  Si un identificador no es requerido en el momento, probablemente los sea en el futuro (para asociar tablas o indexar).
  7. Elige columnas con tipos enteros (o sus variantes) par indexar.  Una columna con tipo varchar puede causar problemas de rendimiento.
  8. Usa campos de tipo bit para almacenar valores booleanos.  Usar enteros o varchar repercute en un consumo innecesario de almacenamiento.  Incluso los nombres de esas columnas puedes ponerles el prefijo «Is» o «Es» en español.
  9. Provee siempre de autenticación para el acceso a base de datos. No le des el rol de  administrador a cada usuario.
  10. No uses querys del tipo «select * » a menos de que sea necesario, extrae solo las columnas necesarias para un mejor rendimiento.
  11. Usa un framework o marco de trabajo ORM (Mapeo Relacional de Objetos)  como hibernate, oBatis, etc, si el código de tu aplicación es lo suficientemente grande.  Los problemas de rendimiento de los ORMs pueden manejarse detallando sus parámetros de configuración.
  12. Particiona tu base de datos separando las tablas que se usan mucho de las que no se usan tanto para un mejor desempeño.
  13. Para bases de datos grandes, sensibles y sistemas de misión crítica, usa los servicios de recuperación de desastres y servicios de seguridad como el failover clustering, respaldos automáticos, replicación, etc.
  14. Usa constraints (llaves foraneas, Checks, valores no nulos, etc) para la integridad de detos. No hagas todo el control desde el código de la aplicación.
  15. La falta de documentación en una base de datos es mala idea.  Documenta tu diseño de base de datos con esquemas de entidad
    relacionales (ER) e instrucciones. Incluso escribe lineas de comentarios en tus trigers, procedimientos almacenados y otros scripts.
  16. Usa indices para scripts frecuentemente usados en tablas grandes.  Hay herramientas de análisis que puede ser usadas para determinar donde pueden estar definidos
    los indices. Para queries que extraen un rango de registros, índices agrupados usualmente son mejores.  Para queries de punto  los indices no agrupados son la mejor opción.


  17. Un servidor de base de datos y un servidor web deben estar en máquinas diferentes.  Esto provee de mas seguridad y separan la carga de trabajo en dos CPUs y memoria diferentes.
  18. Imágenes y columnas de tipo blob no deben estar definidas en tablas frecuentemente requeridas para evitar problemas de rendimiento.  Estos datos deben ser puestos en tablas separadas relacionadas por un identificador.
  19. La normalización debe ser usada cuando sea requerida para optimizar el performance.  Una baja normalización puede repercutir en una repetición de datos, una sobre normalización puede tener efectos en el rendimiento a causa de las excesivas uniones entre tablas para extraer datos.  Se debe mantener un equilibro.
  20. Usa tanto tiempo como puedas para diseñar tu base de datos, el tiempo que gastes para el diseño de la base de datos es tiempo que no emplearas rediseñando la base de datos mas tarde.

Anti Patrones Java – Manejo de XML

Una mala práctica en el manejo de documentos XML es no hacer uso de parsers o analizadores. El siguiente código muestra un escenario común:

int inicio = xml.indexOf("<nombre>");
int fin = xml.indexOf("</nombre>");
String nombre = xml.substring(inicio, fin);

El método anterior que en apariencia funciona, tiene los siguientes inconvenientes:

  • Puede haber mas de un nodo «name» en el documento.
  • El contenido de «name» puede no estar hecho de caracteres de datos solamente.
  • Puede haber caracteres escapados en los datos.
  • Si los datos contenidos en el nodo son CDATA puede no devolver el resultado esperado.
  • El documento XML puede tener namespaces.

En general un documento XML es mucho mas complejo que es un String de java, por el tipo de operaciones que están implícitas en la lectura. Para leer de forma correcta el contenido de un documento XML existen analizadores como Xerces que ademas son muy ligeros. El equivalente en JDOM es el siguiente:

SAXBuilder builder = new SAXBuilder(false);
Document doc = doc = builder.build(new StringReader(xml));
String nombre = doc.getRootElement().getChild("nombre").getText();

Otra mala práctica en el manejo de XML que es muy común es en la construcción del documento, haciendo algo como esto:

String nombre = ...
String atributo = ...
String xml = "<root>"
            +"<nombre atr=\""+ atributo +"\">"
            + nombre
            +"</nombre>"
            +"</root>";

Cuando lo correcto es hacer más bien lo siguiente:

Element root = new Element("root");
root.setAttribute("atr", atributo);
root.setText(nombre);
Document doc = new Documet();
doc.setRootElement(root);
XmlOutputter out = new XmlOutputter(Format.getPrettyFormat());
String xml = out.outputString(root);

Olvidándonos de escapar caracteres y con la sentencia

XmlOutputter out = new XmlOutputter(Format.getPrettyFormat())

Le damos el formato visual adecuado a nuestro documento.  También podremos agregar namespaces a nuestros nodos sin ningún problema. JDom es sin duda una magnifica opción para manejar documentos XML.

JDom es sin duda una magnifica opción para manejar documentos XML.