Apuntes de Java

Hace tiempo encontré esto, me parece muy bueno. Todo programa que empieza bien, acaba mal. Todo programa que empieza mal, acaba peor. Siempre trabaja en equipo al hacer algún programa, esto da oportunidad de echarle la culpa a otro. Si el Debuggear es el proceso de remover Bugs, entonces el programar debe ser el proceso de ponerlos Por cada Bug que elimines en un programa, aparecen tres más. Programar es como el sexo, un error y hay que soportarlo para el resto de la vida. Las dos frases más repetidas y más falsas en la programación: "Esta ocasión si correrá bien" y "Acabo de encontrar el último Bug". Todos los programadores en esencia son optimistas, hasta que terminan su programa. Cada programa interesante tiene cuando menos una variable, un procedimiento, un loop.....y de hecho un bug. Las computadoras siempre tienen una excusa, los programadores no. No importando cuanto tiempo hayas probado la versión final de un programa, los bugs aparecerán en la...

El framework iBatis DataMapper (también conocido como SQL Maps) permite reducir significativamente la codificación en java para una aplicación que maneja base de datos relacional. Quizás la primera impresión que uno tenga es que sea igual a Hibernate (que es un mapeador de objetos con tablas relacionales – ORM). Ibatis es diferente. Como veremos en este tutor, iBatis mapea las consultas SQL y permite interactuarlas con JavaBeans tanto como parámetros de entrada y como salidas. Manos a la obra Para comenzar, obtendremos el framework de la página de ASF: http://ibatis.apache.org/ El archivo que habremos bajado (iBATIS_DBL-2.1.7.XX.zip) contendrá tres archivos .jar. En este tutor solo usaremos ibatis-common-2.jar y ibatis-sqlmap-2.jar. No necesita de algún otro .jar, al menos para este capítulo. Definiendo la estructura de los datos Crearemos nuestro JavaBean Categoria con la siguiente estructura. package com.jugperu.tutores.ibatis.beans; public class Categoria { private int id; // p...

¿Qué es AJAX? Imaginemos que estamos haciendo un formulario web de registro de clientes que tiene cuarenta campos. Tres de esos campos son combos para “departamento”, “provincia” y “distrito”. Al seleccionar un “departamento”, el combo “provincia” se debe actualizar con el contenido correspondiente. De igual manera, al seleccionar una “provincia”: sus distritos correspondientes deberán aparecer en su respectivo combo. Para implementarlo tenemos dos maneras: Colocar en el evento “onchange” de los combos un submit() para que se envíe el formulario actual al servidor, y éste devuelva el mismo formulario (sin perder los valores de los demás campos) sólo para que actualice las opciones de los combos afectados. Como se puede predecir, se estaría desperdiciando el ancho de banda enviando todo un formulario sólo para cambiar uno o dos campos. Eso, sin contar que la programación de los submit() en el lado del servidor debe estar contemplada para saber que lo que hizo fue cambiar un combo o se...

Seamos sinceros: nuestras aplicaciones las hacemos usando la metodología ODBC (Ojo De Buen Cubero) que consiste en ir escribiendo todo el código de un tirón calculando "al ojo" que funciona bien... luego ejecutamos toda la aplicación para ver si funciona bien... y si hay un problema, corregimos esa parte y volvemos a ejecutar toda la aplicación " otra vez " para ver si esa pequeña parte ha sido solucionada... y así sucesivamente hasta que ya no haya más problemas... por el momento. JUnit es un framework que permite, a nosotros los programadores y desarrolladores, realizar pruebas a partes de una aplicación (una rutina, una clase, un algoritmo, etc) antes de la etapa de construcción. Nuestro IDE favorito (JBuilder, netBeans, eclipse, JDeveloper, etc) permite crear módulos Test. Si aún no lo has utilizado, este sería un buen momento para conocer más tu IDE. Manos a la obra Imaginemos que estamos haciendo una aplicación que requiere manejar una lista en forma de pila...

Introducción ¿Quién no ha utilizado System.out.println() para saber qué está haciendo en ese momento el programa? A veces ponemos mensajes como “estoy en 'calcularMonto'”, quizás mostrando la hora actual, o quizás el tiempo que pasó entre un proceso y otro, o mostrando el valor que tiene una variable. El problema sucede cuando el programa tiene que estar en producción y estos mensajes pueden resultar incómodos. Se torna una tarea tediosa buscar estas instrucciones para “comentarlas”. Y si hay error después ¿dónde está? ¡voy a tener que editar y recompilar el código para ver lo que pasa!. Afortunadamente programadores como nosotros han tenido el mismo problema y han desarrollado un framework que permite administrar estos mensajes – en inglés el término utilizado es logging – de tal manera que nuestros programas no tengan que pasar por el quirófano cada vez que esté “enfermo”. Este framework es el muy utilizado Log4j. Log4j permite registrar eventos de nuestro program...