Refactoring: improving the design of existing code
Refactoring: improving the design of existing code
Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Por qué lo he leído
El título me pareció sugerente. Me gusta que el código que utilizo, el código que escribo o el código que leo, tenga muy buena apariencia, sea legible, sencillo y, por qué no, sea bonito.
No soporto ver clases mal identadas, o con nombres que no significan nada. Lo odio. Y siempre he pensado que refactorizar el código ayuda a conseguir todo esto.
Qué esperaba
Evidentemente, según el título, esperaba un manual, una guía, sobre cómo refactorizar. Esperaba que el libro me enseñara a refactorizar, a mejorar las refactorizaciones que hago en mi día a día.
Teniendo a Martin Fowler como autor principal, esperaba una descripción de experiencias, una demostración de veteranía, de la que poder beneficiarme y aprovechar esa sabiduría para mejorar en mi trabajo.
Qué encontré
Encontré un catálogo de acciones de refactorización. Muchas de las refactorizaciones descritas en el libro son sencillas, otras ya las practicaba sin conocerlas formalmente y otras estoy seguro de que me resultarán muy útiles de aquí en adelante.
Conclusiones
El libro me ha resultado un poco denso, y a veces muy lento, incluso llegó un momento en el que estuve a punto de dejar de leer.
Cada acción de refactorizar está muy detallada. Esto hace que leerlo sea un poco aburrido, pero como referencia no tiene precio.
Como ya he dicho antes, muchas refactorizaciones ya las estaba realizando personalmente, pero ni las había categorizado, ni les había puesto nombre. Por esto mismo, no he encontrado muchas refactorizaciones desconocidas para mí, pero al mismo tiempo me ha permitido categorizar, catalogar, varias refactorizaciones que estaba realizando. De las refactorizaciones nuevas, tengo pensado escribir sobre alguna de ellas.
Sin duda, es un libro a tener en cuenta para cualquier desarrollador software, tanto como para su lectura como para tenerlo de referencia. Totalmente recomendado.
Pasajes que quiero recordar de este libro
El primer paso, es construir un conjunto sólido de tests para el código que se va a refactorizar.
En la mayoría de los casos, un método debería residir donde los datos que el método usa.
Para refactorizar, lo mejor es pasito a pasito, lo que lleva a cometer menos errores.
La lección más importante del ejemplo es el ritmo del refactor: test, cambio pequeño, test, cambio pequeño, test, …
¿Por qué refactorizar? Mejora el diseño del software, hace el software más fácil de mantener, ayuda a encontrar errores, ayuda a programar más rápido.
¿Cuándo no refactorizar? Cuando es necesario empezar desde cero, o cuando estás cerca de una entrega.
Cuando los testers encuentran un bug, hay que hacer dos cosas: arreglarlo y crear un test que te asegure de que el bug no volverá a aparecer.
El estilo que yo sigo es el de fijarme en todas las cosas que la clase puede hacer y pruebo cada una de ellas para todas las condiciones que pueden hacer que la clase falle. No es lo mismo que testear cada uno de los métodos públicos. Los tests deben de exponer cierto riesgo.
La repetición es la raiz de todos los males del software.
(Las sentencias de protección indican: esto es raro, haz algo y sal de aquí) La sentencia de protección o retorna de la función o lanza una excepción, nunca debería dejar seguir ejecutando el método.
A veces, se da por supuesto algo y se escribe un comentario. Es mejor hacer explícita lo asumido creando una sencia assert.
Mi experiencia me dice que conforme refactorizar se va convirtiendo en una rutina, deja de ser una sobrecarga y comienza a ser algo esencial
TibrvException[error=901,message=Library not found: tibrvj]
Actualmente, en el trabajo estamos utilizando TIBCO Rendezvous como herramienta de mensajería entre nuestras aplicaciones java, y recientemente me he encontrado con un problema. En este post voy a hablar de dicho problema, así que si no te interesa el tema, ya has terminado de leer el artículo 
Problema
El problema es el siguiente: no soy capaz de que nuestras aplicaciones carguen la librería para poder comunicarse. Más concretamente, estoy obteniendo la siguiente excepción:
[...]
Caused by: TibrvException[error=901,message=Library not found: tibrvj]
at com.tibco.tibrv.Tibrv.loadLib(Tibrv.java:474)
at com.tibco.tibrv.Tibrv.open(Tibrv.java:275)
[...]
Antes de nada, voy a contextualizar este error:
El entorno de trabajo es un Windows 7, con procesador Inter de 64 bits, la versión de Tibco Rendezvous es la 8.2 y tengo instalada una JDK de java versión 1.6.0_17.
Googleando el error no llego a ninguna solución en concreto, sólo conversaciónes acerca del classpath de la aplicación. Pero me he dado cuenta de que se deben dar unas condiciones:
- El fichero tibrvj.jar debe estar accesible en el classpath de la aplicación
- La variable de entorno PATH debe contener (entre otros) este valor:
%TIBRV_HOME%\bin
Siendo TIBRV_HOME el directorio de instalación de Tibco Rendezvous, por ejemplo y en mi caso es: "C:\tibco\tibrv\8.2"
Cumplo todas estas condiciones, pero sigo teniendo el error.
La excepción salta cuando en mi aplicación intento cargar la librería Tibrv mediante el código:
Tibrv.open(Tibrv.IMPL_NATIVE);
Como no puedo ver el código interno de la implementación de Tibco, intento cargar la
librería al más bajo nivel, mediante:
System.loadLibrary("tibrvj");
La librería debería cargar, ya que previamente he comprobado que el fichero tibrvj.dll está accesible a la aplicación, ya que ese fichero está localizado en el directorio %TIBRV_HOME%\bin, incluido en la variable de entorno PATH, y lo puedo comprobar dentro de mi aplicación java leyendo el valor de la variable de sistema java.library.path.
Al ejecutar el código System.loadLibrary("tibrvj"); obtengo la siguiente excepción:
[...]
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\TIBCO\tibrv\8.2\bin\tibrvj.dll: Can't load AMD 64-bit .dll on a IA 32-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1758)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1683)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
[...]
Bueno, ya tengo una pista. Resulta que estoy intentando cargar una librería desarrollada para 64bits en una plataforma (java, supongo) que es de 32bits. Luego, voy a comprobar mi versión instalada de java y si no es de 64bits tendré que instalar una de 64bits.
Compruebo mi versión de java:
C:\>java -version java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)
(FAIL) No indica nada de que sea java de 64bits, por lo que supongo que será de 32.
Solución
Descargo la última versión de java 1.6 de 64bits, la instalo y vuelvo a comprobar la versión instalada:
C:\>java -version java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)
Bien! ya tengo instalada una versión de java de 64bits.
Pruebo mi aplicación, …, FUNCIONA!
Conclusión
Todas las soluciones que encontré se centraban solamente en corregir las variables de entorno PATH y CLASSPATH, pero estas soluciones no eran suficientes para mí. Al menos, al acotar el problema mucho más y llegando al un nivel más bajo de abstracción obtuve una pista que me indicó que debería asegurarme de usar una versión de 64bits de java. Una vez instalada la versión correcta del JDK/JRE de java, todo funcionó.
Espero que esta información sea de utilidad a todos aquellos que tienen el problema de encontrarse con la excepción:
TibrvException[error=901,message=Library not found: tibrvj]
El código completo usado para demostrar este error se puede encontrar aquí:
import com.tibco.tibrv.Tibrv;
import com.tibco.tibrv.TibrvException;
public class TibrvLoaderTest {
public static void main(String[] args) {
new TibrvLoaderTest().start();
}
private void start() {
printClasspath();
printLibraryPath();
testLoadLibrary();
openTibrvjLibrary();
}
private void printClasspath() {
String cp = System.getProperty("java.class.path");
for(String cpElement : cp.split(";")){
System.out.println("Classpath element: " + cpElement);
}
}
private void printLibraryPath() {
String lp = System.getProperty("java.library.path");
for(String lpElement : lp.split(";")){
System.out.println("Library path element: " + lpElement);
}
}
private void testLoadLibrary() {
System.loadLibrary("tibrvj");
}
private void openTibrvjLibrary() {
try {
Tibrv.open(Tibrv.IMPL_NATIVE);
} catch (TibrvException e) {
throw new RuntimeException("Can't load Tibrv", e);
}
}
}
The Clean Coder
The Clean Coder: a code of conduct for professional programmers
Rober C. Martin
Por qué lo he leído
Me decidí a leer este libro porque leyendo varios blogs en español encontré más de una referencia, por lo que parecía un buen libro para leer. Además, conseguí que un amigo me dejara un ejemplar. Todos los requisitos cumplidos.
Qué esperaba
La verdad es que el propio título ya dice bastante: “clean coder”. Esperaba encontrar una guía de buenas prácticas para aplicar en mi día a día profesional, una serie de consejos sobre cómo desarrollar software de calidad, limpio, que sea fácil de leer. Estaba incluso decidido a soportar una lista de tópicos sobre el desarrollo del software, pero estaba seguro de que iba a encontrar consejos/prácticas nuevas y, por supuesto, iba a aprender técnicas útiles.
Qué encontré
La verdad es que no encontré exactamente lo que buscaba. Robert C. Martin nos cuenta más batallitas que otra cosa, pero no nos miente, desde el principio del libro nos advierte que éste es un libro de experiencias personales.
El libro es un conjunto de experiencias, unas buenas y otras malas, del autor, de las cuales, Uncle Bob ha aprendido todo lo que sabe.
El libro también es un conjunto de consejos, una guía, de cómo Robert cree que se debe comportar un desarrollador de software profesional.
Conclusiones
El libro me ha encantado.
El tono que usa Uncle Bob para relatar sus experiencias es informal y cercano. En algunas de ellas puedo ver reflejados a compañeros míos o incluso a mí mismo (aunque ya no trabajamos con tarjetas perforadas, pero la esencia sigue siendo la misma).
Algunos consejos son, para mi gusto, un poco extremistas, pero el autor da sus razones de porqué él cree que debe ser así. Al fin y al cabo, han sido y son sus vivencias y no las impone a nadie. Con otros consejos no estoy muy de acuerdo, pero siempre es bueno conocer otras opiniones.
En definitiva, si te preocupa tu trabajo, éste es un buen libro para conocer qué piensa una de las personas más importantes en el mundo del desarrollo del software. Así es como Robert C. Martin cree que debe ser un profesional:
- Es responsable: cuando un profesional comete un fallo, arregla el desorden que ha provocado.
- Usa su conocimiento para construir, no para destruir.
- Debe estar seguro de que funciona (tests).
- Conoce el campo en el que trabaja (banca, transporte, …).
- Nunca ridiculiza a los demás.
- Trabaja duro para encontrar caminos creativos para decir “si”, para entregar funcionalidad.
- La actitud que tiene hacia las interrupciones es de mostrarse voluntarios de poder ser de ayuda. Se ofrece a ayudar a los compañeros si ven que están teniendo problemas.
- Programa en parejas.
- Mantiene la mente abierta a nuevas tecnologías, ideas, diseños, y acepta que estas novedades pueden ser incluso mejor que las actuales.
Pasajes que quiero recordar de este libro
Debes ser responsable de tus imperfecciones, lo primero que debes aprender es a pedir perdón, después debes hacer que tu ratio de errores tienda a cero.
Entregar funcionalidad a coste de romper la arquitectura es un error de principiante. Comprometer la arquitectura es comprometer el futuro.
Regla del Boy Scout: deja siempre el código un poquito más limpio de lo que te lo encontraste.
Tu carrera es tu responsabilidad, no culpes a tu empresa.
La mejor forma de aprender, es enseñando. Otra forma de aprender es colaborar con otra gente.
Los problemas de tu empresa (quien te paga) son tus problemas.
Programar es un acto de creación. Cuando escribes código, estás creando algo de la nada.
(Sobre estimaciones y compromisos) Negocia para alcanzar el máximo de las dos partes enfrentadas.
La promesa de “lo intentaré” es la aceptación de que guardas un esfuerzo extra, y además es un compromiso de que necesitarás aplicar ese esfuerzo extra para conseguir el objetivo.
Agresión pasiva: dejar que tu compañero falle públicamente cuando sabes de antemano que lo que está haciendo fallará.
Dilo, comprométete y hazlo. (no lo intentes, hazlo)
Programar es una actividad agotadora, que reta tu inteligencia [...], si estás cansado o distraído, no programes.
Las estimaciones tienen que estar basadas en datos, no incorpores esperanza en tus estimaciones. Y no dejes que los demás tengas esas esperanzas.
No aceptes hacer horas extras, excepto si: te lo puedes permitir personalmente, es para un período corto y tu jefe tiene un plan B por si no funciona.
La única forma de mejorar la planificación, es reducir el alcance. No caigas en la tentación de correr.
Los tests te dan la certeza suficiente para entregar.
TDD (desarrollo dirigido por tests) es una disciplina que mejora la certeza, el coraje, reduce los defectos, la documentación y mejora el diseño.
Katas:
- http://katas.softwarecraftsmanship.org
- http://codekata.pragprog.com
- http://thecleancoder.blogspot.com/2010/10/craftsman-62-dark-path.html
Tom DeMarco: Una ambigüedad en los requisitos, refleja un conflicto en el cliente.
Los tests unitarios y de aceptación, primero son documentos y luego tests.
Nada tiene un efecto tan negativo a largo plazo en la productividad de un equipo desarrollador como la deuda técnica.
Programar conlleva trabajar con gente. Si quieres pasar tus días desarrollando software, deberás aprender a hablar con la gente.
Lleva tiempo que un equipo funcione, por eso, las empresas profesionales, organizan proyectos alrededor de equipos que funcionan, nunca forman equipos alrededor de proyectos nuevos.
Mi retrospectiva de la XPWeek 2011
El lunes 19 asistí como oyente al día de conferencia que formó parte de la XPWeek. Fue una lástima que no pudiera asistir a ninguno de los cursos sobre TDD que se impartieron en los días siguientes 
.
Hacía mucho tiempo, mucho, que no participaba en alguna conferencia así, y la experiencia me encantó (pienso seguir hacer proposiciones indecentes a mi empresa para poder asistir a todas aquellas que pueda).
Me encantó poder conocer en persona a Carlos Blé, ver en vivo y en directo a Jose Manuel Beas (la lástima es que se me escapó y no pude presentarme, otra vez será). De Enrique Amodeo también había oído hablar, y me gustó mucho su presentación. De los demás ponentes no tenía referencias, pero sentí la pasión que tienen sobre el mundo del software. Encantado de conoceros.
Las presentaciones fueron las siguientes:
- TDD con el stack Objective-C, por Alejandro Pérez, diapositivas, más material
- 9 rules to better OO, por Sebastián Hermida, diapositivas
- BDD de fuera a dentro, por Luismi Cavallé, diapositivas
- CoffeeScript, por Guillermo Pascual, diapositivas
- No metodologías, por León, diapositivas
- CSS orientado a objetos, por Enrique Amodeo, diapositivas
- BDD y arquitectura Javascript, por Carlos Benítez, diapositivas
- Testing con Spring 3, por Israel Alcázar, diapositivas
(Sigo atento a que los ponentes vayan colgando sus diapositivas, y algún que otro vídeo que se grabó).
La sensación general con la que me quedo de la conferencia es positiva. No necesitaba que nadie me convenciera de las virtudes de TDD y BDD, pero ver que se pueden llevar a cabo con muy distintas tecnologías, y conocer a gente apasionada por ellas, me motivó bastante para seguir intentando seguir estas metodologías y continuar atrayendo a mis compañeros hacia ellas.
Pero (sí, lo siento, tengo un “pero”) eché de menos que se hablara más de metodologías ágiles, más acerca de las metodologías en general. Tengo la sensación de que sólo se habló de TDD y BDD, aunque sé que hubo una charla sobre metodologías en general, que tuvimos tiempo de hablar con quien quisiéramos de lo que quisiéramos, pero, no sé, es una sensación, y tengo claro que me encantaría repetir.
De la conferencia me llevo unos contactos (@fperezsorrosal, @jalbertopaz), unos cuantos fans de groovy (@yurenaghm, @juanmagomer y @arturoherrero) y las ganas de volver a ser parte de eventos como éste.
Lista de logros para ser mejor programador
Me he permitido copiar el título del post del blog donde encontré la idea para escribir el mío propio: Lista de logros para ser mejor programador (que a su vez fue inspirado por Jason Rudolph) y espero que la palabra se extienda y poco a poco se cree toda una marea de programadores que queremos mejorar.
La idea original es hacer públicos una serie de logros que se quieren conseguir como programador. Yo he hecho lo propio y he comenzado haciendo un fork del gist original de Jason: https://gist.github.com/1189847
Me gusta mucho la idea de exponer, de publicar las metas que uno quiere conseguir. Eso hace que te esfuerces más por llegar a ellas, por hacerlas realidad. Espero que hacerlas públicas me ayude, y también que inspire a otros profesionales del desarrollo del software para tomar iniciativas similares.
Yo en particular no estoy de acuerdo con todas las metas de Jason, por lo que iré modificando mi gist con mis propias metas. Puede que no sean tan ambiciosas como las de Jason, puede que sean menos concretas. Pero serán las mías.
Como bonus, me gustaría compartir un enlace relacionado con el aprendizaje perpetuo. En Tu no sabes programar encontré varios de las metas con las que empezar a personalizar mi gist de logros para ser mejor desarrollador: patrones y principios de diseño, metodologías y disciplinas de desarrollo, herramientas, …
Enlaces relacionados:
¿Qué es un gist?
Gist es una forma sencilla de compartir con otros pequeños archivos de ejemplo. Todos los gists son repositorios git, por lo que son automáticamente versionados, pueden ser duplicados y usados como un repositorio git.
Linchpin
Linchpin: are you indispensable?
Seth Godin
Por qué lo he leído
Suelo leer a Alberto Peña “plagelao”, y en su viejo blog leí su post sobre La Resistencia. Así fue como descubrí el libro. Yo tambien siento cada día esa “resistencia”, ese miedo a conseguir lo que quiero, por lo que decidí darle una oportunidad al libro en cuanto tuviera tiempo, y lo he tenido antes de lo que yo me esperaba.
Qué esperaba
Me esperaba una serie de consejos para mejorar en mi trabajo, y quizá en mi vida personal, al estilo auto-ayuda.
Eres indispensable?
Solo el título ya te hace pensar que seguramente no estás haciendo todo lo posible para ser mejor mañana de lo que eres hoy.
Qué encontré
La verdad es que sí, al principio parece un libro de auto-ayuda. Repite una y otra vez los mismos conceptos, para que los asimiles una y otra vez.
Según fuí avanzando en el libro, fui conectando las ideas y todo empezó a tomar otra forma. Muchos consejos y sabiduría comprimida, pero nada de sentimiento de inferioridad que se encuentra en los libros puros de auto-ayuda.
Conclusiones
El libro en general me ha gustado bastante, pero me ha dejado con la miel en los labios. Claro, al final no hay un método claro para hacerte indispensable, y por supuesto el camino no es fácil, pero el libro viene acompañado de inifinidad de referencias y casos reales. Es con la lectura de estos casos reales donde uno entiende a qué se refiere el autor con eso de ser indispensable: eres original? eres generoso? no tienes miedo a triunfar? eres adaptable?
Aquí dejo unos cuantos consejos para ayudaros a ser mejores, sacados del libro:
- Cualquier persona es un genio, no las 24h del día, pero seguro que en algún momento has hecho alguna genialidad
- Para ser indispensable, debes hacer “trabajo emocinal” (emotional labor): es aquello que haces por tus sensaciones y sentimientos, no algo físico.
- No es beneficioso establecer una carrera haciendo algo escrito en un manual, lo beneficioso es hacer algo diferente.
- Se un artista (creativo, apasionado, generoso). No lo hagas por dinero, hazlo porque quieres, y quieres ayudar a los demás.
Pasajes que quiero recordar de este libro
Estas son algunas de las citas que puedes encontrar en el libro, todas son traducciones libres, lo siento si no se corresponden exactamente con lo que quiere decir el autor.
Un genio es alguien que mira donde otros están paralizados y es capaz de poner el mundo en funcionamiento de nuevo.
El empleado indispensable trae consigo humanidad, comunicación y arte a su empresa.
Lo que el mercado busca ahora es alguien: excepcional, generoso, artista, que conecte gente (clientes) con ideas.
Un trabajador brillante, es brillante durante pequeños momentos, el resto del tiempo hace trabajo que cualquiera puede hacer.
Arte es cualquiercosa que sea creativa, apasionada y personal. Arte es un regalo personal que cambia al receptor. Arte es el producto del “trabajo emocinal”.
Pasión es el deseo, la insistencia y la voluntad de dar un regalo.
La disciplina de entregar, producir (“to ship”) es esencial para ser indispensable a largo plazo.
Los verdaderos regalos, los generosos no demandan reciprocidad, y el mejor regalo es un regalo de tu arte.
Nikola Tesla: el genio al que le robaron la luz
Nikola Tesla: el genio al que le robaron la luz
Margaret Cheney
Por qué lo he leído
Suelo leer microsiervos bastante a menudo, y en ese blog son admiradores de Tesla, así que ya tenía cierta introducción acerca de él. Hace tiempo, publicaron una reseña del libro y me llamó la atención. Mi cumpleaños estaba cerca, así que aproveché la oportunidad para pedir un regalo. Y así llegó a mis manos.
Qué esperaba
Ésta es mi primera biografía, asi que no tenía mucha idea de lo que me podía encontrar. Quizá una lista de fechas y logros realizados por Tesla, una serie de sucesos personales, qué se yo. Dada la reputación que le daban en microsiervos, no podía haber nada malo. Al fin y al cabo, pese a quien le pese, Nikola Tesla es bastante conocido como inventor, aunque yo lo catalogaba más como científico, y ésta es la primera biografía en castellano (aunque es una traducción), así que esperaba llegar a conocer en profundidad a un personaje fundamental para entender el mundo tal y como lo conocemos hoy.
Qué encontré
Encontré el relato de una vida, una enumeración de hechos bastante bien documentados, pero no sólo una mera enumeración, como la vida misma, todos los eventos se interrelacionan, todos los personajes (en este caso, personas reales con los que Tesla tuvo relación) se relacionan en una serie de actos sociales, de logros científicos, de descubrimientos, de disputas sobre patentes, empresas que se crean y acaban por desaparecer, …
El libro me ha conducido por las distintas fases de la vida de Tesla, y describe a Tesla con gran admiración pero también con fuentes contrastadas y documentadas, aunque a veces no fuera posible dado que hay cierto halo de misterio en torno a muchos de los proyectos en los que trabajó Tesla.
Conclusiones
En general es un libro que me ha gustado mucho leer, del cual he aprendido mucho sobre la vida de una persona tan extraordinaria como es Nikola Tesla.
También creo que he podido disfrutar del libro gracias a mi edad, creo que si lo hubiera leído con 25 años no me hubiera gustado nada, no podría haber disfrutado del recorrido de una vida. Ahora paso justo de los 30 y voy entendiendo que la vida es un largo camino donde a las locuras de la juventud le siguen los grandes logros de la madurez.
Al final del libro me he quedado algo apenado, ya que según describe el libro, Tesla tenía muchas manías y un temperamento bastante fuerte (especialmente al final de su vida), casi hasta el punto de parecer como si tuviera alguna enfermedad mental. De todas formas el libro me ha dado a conocer aspectos de la vida de Tesla de las que no tenía ni idea, y me ha convencido de que Tesla era sobretodo un tipo extraordinario, con una imaginación sobresaliente y que debido a eso era un hombre adelantado a su tiempo, muchas veces incomprendido y que tuvo que superar tremendas dificultades. Las más difícil, en mi opinión, es el rechazo al reconocimiento que se merecía, y que lo obtuvo a título póstumo. Muy injusto.
Uso de JPA, Hibernate y Derby
Tengo una pequeña aplicación en la que uso Apache Derby como base de datos para guardar los datos.
Hasta ahora, estaba utilizando el patrón DAO para guardar los datos que quería hacer persistentes en la aplicación. Cada clase DAO se encargaba de crear, borrar, editar y actualizar un tipo de datos. Estas operaciones las hacía mediante SQL puro y duro. No es que el modelo de datos que utilizo sea muy complicado, pero es tedioso editar consultas SQL para cada tipo de dato que quieres persistir.
Así pues, decidí que debería utilizar algo un poco más elaborado. Java dispone de la Java Persistence API, así que, ¿porqué no usarla? Y este post describe los primeros pasos a dar para utilizar JPA en una aplicación.
JPA es una definición, por sí sola no hace nada, necesita de una implementación para realizar realmente el trabajo. Existen varias implementaciones (ver comparativa). De todas ellas he elegido Hibernate. Puede que no sea la mejor, puede que no sea la más rápida o la más eficiente, pero creo que es la más conocida y la referencia para el resto de implementaciones.
El ejemplo, paso a paso
Nuestro ejemplo va a consistir en algo muy (pero que muy) sencillo, pero que nos va a permitir aprender cómo configurar hibernate con nuestra base de datos derby. Nuestros datos a guardar van a ser objetos de la clase Person, que va a tener un nombre. No va a haber relaciones con ningún otro objeto, así que sólo exisitirá una tabla en la base de datos. Más sencillo, imposible.
Datos que serán persistentes
Como ya hemos visto, sólo vamos a persistir objetos de la clase Person, la cual tendrá un campo id, que funcionará como la clave principal de la tabla, y un campo name, el nombre de la persona. A continuación vemos el código de esta clase:
package es.rct.jpa.model;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
@Entity
public class Person {
@Id
@GeneratedValue
private long id;
private String name;
public void setName(final String name) {this.name = name;}
public String getName() {return name;}
public void setId(final long id) {this.id = id;}
public long getId() {return id;}
}
De esta clase vamos a destacar 3 anotaciones, pertenecientes a JPA. Las podemos encontrar en el paquete javax.persistence:
- Entity: indica que esta clase es una entidad, lo cual significa que esta clase tiene correspondencia con una tabla en la base de datos.
- Id: indica qué campo de la clase va a ser utilizado como clave primaria de la tabla representada por la entidad.
- GeneratedValue: indica que la clave va a ser generada automáticamente por el motor de persistencia (hibernate)
Dependencias de Maven
Para poder usar Derby como base de datos y Hibernate como implementación de JPA, debemos incluir las siguientes dependencias en nuestro fichero pom.xml de configuración de maven:
<!-- ... --> <dependency> <groupId>org.apache.derby</groupId> <artifactId>derby</artifactId> <version>10.6.2.1</version> <type>jar</type> <scope>compile</scope> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-entitymanager</artifactId> <version>3.4.0.GA</version> <type>jar</type> <scope>compile</scope> </dependency> <!-- ... -->
Las versiones de las dependencias pueden variar. Aquí aparecen las que yo personalmente he utilizado.
Configurar JPA / Hibernate / Derby
Para configurar JPA, debemos escribir la configuracion en un fichero llamado persistence.xml, en un directory META-INF, accesible desde el directorio de trabajo de nuestra aplicación. Yo lo he creado en src/main/resources/META-INF/persistence.xml, ya que maven empaqueta el contenido del directorio src/main/resources en el jar de la aplicación, con lo que tenemos el resultado deseado.
El contenido del fichero de configuración JPA es el siguiente:
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0"> <persistence-unit name="test-jpa" transaction-type="RESOURCE_LOCAL"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <class>es.rct.jpa.model.Person</class> <exclude-unlisted-classes>true</exclude-unlisted-classes> <properties> <property name="hibernate.connection.url" value="jdbc:derby:memory:testing-jpa;create=true" /> <property name="hibernate.connection.driver_class" value="org.apache.derby.jdbc.EmbeddedDriver" /> <property name="hibernate.dialect" value="org.hibernate.dialect.DerbyDialect" /> <property name="hibernate.hbm2ddl.auto" value="create" /> <property name="hibernate.connection.username" value="" /> <property name="hibernate.connection.password" value="" /> </properties> </persistence-unit> </persistence>
De este fichero xml podemos destacar las siguientes etiquetas:
- persistence-unit, atributo name: define una unidad de persistencia, es obligatorio darle un nombre, para poder crear un EntityManager en nuestra aplicación. El EntityManager es el encargado de manejar la persistencia de nuestros datos.
- provider: aquí indicamos que queremos usar Hibernate como implementación de JPA
- class: debe existir una etiqueta class por cada clase que queramos persistir, es decir, una por cada entidad que formará nuestra unidad de persistencia.
- Dentro de las etiquetas properties, definimos propiedades propietarias de la implementación JPA. De entre ellas cabe destacar:
- hibernate.connection.url: define la URL de conexión a la base de datos. Aquí estamos configurando Derby como base de datos. Estamos creando una base de datos llamada “testing-jpa” en memoria (no en disco).
- hibernate.dialect: configuramos Hibernate para que “hable” con Derby
Crear un test para probar el funcionamiento
Ahora sólo queda crear nuestro código para almacenar algunos objetos del tipo Person.
Primero, debemos crear un objeto EntityManager, que manejará todo lo relacionado con la persistencia: transacciones, guardar datos, actualizarlos, borrarlos, etc.
EntityManagerFactory emf = Persistence.createEntityManagerFactory("test-jpa");
EntityManager em = emf.createEntityManager();
Una vez terminemos de utilizar nuestro EntityManager, debemos cerrarlo:
em.close(); emf.close();
Ahora ya disponemos de un objeto “em” para poder persistir objetos de tipo Person:
private void insertSomeData() {
Person p = new Person();
p.setName("person 01");
Person p1 = new Person();
p1.setName("person 02");
em.getTransaction().begin();
em.persist(p);
em.persist(p1);
em.getTransaction().commit();
}
Para poder guardar los datos en base de datos, debemos arrancar una transacción, llamar al método “persist” y terminar la transacción. Si queremos indicar que ha habido un error durante la transacción, y no queremos llevarla a cabo, llamaríamos al método “rollback” en lugar del método “commit”.
Para comprobar que realmente hemos almacenado los objetos en la base de datos, sólo tenemos que buscarlos por identificador. Ya que sólo hemos almacenado 2 objetos, y son los 2 primeros, los ids serán 1 y 2 respectivamente:
private void listInsertedData() {
em.getTransaction().begin();
for (long i = 1; i <= 2; i++) {
Person pFinded = em.find(Person.class, new Long(i));
System.out.println("Id: " + i + ", name: " + pFinded.getName());
}
em.getTransaction().commit();
}
Código fuente del ejemplo
Puedes descargar/ver el código fuente en este repositorio de github: https://github.com/rchavarria/JPAHibernateDerby
Referencias
Si quieres profundizar en el tema, aquí dejo unos enlaces que me han sido de gran ayuda.
God and the new physics
God and the new physics
Paul Davies
Por qué lo he leído
La verdad es que como la mayoría de los libros, lo he leído casi por casualidad. Un compañero de trabajo le estaba leyendo, lo ví encima de su mesa y el título me llamó la atención. Dios y la física mezclados? Parecía interesante.
Qué esperaba
Con ese título, me esperaba más de la eterna discusión ciencia-religión. Además, dado que mi compañero es de “ciencias”, estaba casi seguro que ganaría la ciencia.
No conocía al autor, pero con una pequeña búsqueda te das cuenta de que Paul Davies es un gran divulgador científico, más concretamente un gran divulgador de la física, con un gusto especial por la astrofísica.
Qué encontré
Bueno, lo que encontré no fue exactamente una discusión ciencia-religión. El autor expone muchos, si no todos, los argumentos de una y de otra parte. Encontramos argumentos a favor de la existencia de Dios (con mayúscula) así como sus contra-argumentos, encontramos argumentos a favor de que no existe ningún dios, con sus contra-argumentos también.
Gracias a este libro he recordado muchos conceptos de física y matemáticas que hacía mucho tiempo que no me planteaba, y también he aprendido otros nuevos: como la teoría de que el universo se hinchó como si fuera una burbuja, por ejemplo.
El autor conoce a la perfección la problemática y la complejidad de las teorías expuestas, pero las expone con mucha claridad y sencillez. Evidentemente, no profundiza en ellas, cada una de las teorías expuestas merece, y han tenido, muchas palabras habladas y escritas.
El autor ha escrito el libro siguiendo un orden que me encanta, comienza con una pequeña introducción enfrentando la ciencia y la religión, sigue con la creación del universo y cuestiona su existencia. Después se concentra en la vida y el ser humano, mente, alma, cuerpo. Lo reduce todo a la teoría cuántica y al origen y composición de la materia. Termina describiendo el fin del universo.
El último capítulo es un cierre genial para un libro que despierta la mente, me quedaría con un párrafo que me emocionó:
Central to the physicist’s notion of beauty are harmony, simplicity and symmetry. [...] When physics talk of beauty and symmetry the language through which these concepts are expressed is mathematics. [...] Fear of mathematics is a barrier that cuts people off from a full appreciation of scientific discoveries. [...] Many physicicists has become so deeply impressed with the mathematical simplicity of the laws of nature that they maintain it reveals a fundamental feature of existence. Sir James Jeans once wrote: God is a mathematician.
Lo que podría traducir libremente como:
Para los físicos, la noción de belleza va acompañada de armonía, simplicidad y simetría. [...] Cuando los físicos hablan de belleza y simetría el lenguaje que usan son las matemáticas. [...] El miedo a las matemáticas es una barrera que impide a la gente apreciar de verdad los descubrimientos científicos. [...] Muchos físicos han quedado tan impresionados con la sencillez matemática de las leyes [físicas] de la naturaleza que mantienen que ello revela una característica fundamental de existencia. Sir James Jeans dijo: Dios es un matemático.
Conclusiones
Al final no gana ni ciencia ni religión, pero no deja en muy buen lugar a la religión, ya que cree que juega con ventaja. Mientras que la religión se basa en fe y creencias, la ciencia se basa en hechos, y claro, las creencias son imposibles de desmentir mientras que los hechos están ahí y puede haber múltiples interpretaciones.
En uno de los capítulos llega incluso a insinuar que Dios podría ser humano (o al menos un ser inteligente, pero nada divino), y para ello sigue el siguiente argumento: en un período corto de tiempo (comparado con la edad de la Tierra), el hombre y la ciencia han avanzado muchísimo en el campo de transformar la naturaleza y el entorno. Si la vida del universo se estima que puede llegar a ser mucho mayor que la edad que tiene actualmente, ¿dónde no llegará el hombre? Podría llegar a modificar órbitas, crear lunas, modificar galaxias, crear agujeros negros, … ¿Por qué no iba a ser capaz de crear un nuevo universo? ¿Por qué no? Con suficiente tiempo, … Nadie puede demostrar que vaya a ser así, pero tampoco lo contrario.
Dormir sin lágrimas
Dormir sin lágrimas
Rosa Jové
Por qué lo he leído
Dentro de muy poquito voy a ser padre primerizo de un niño, y como buen padre (y muy influenciado por la mejor madre) decidí leer algún libro relacionado con los bebés, para tener alguna idea de qué nos vamos a encontrar.
En realidad no tenía pensado leer este libro, si no más bien Duérmete niño, de Eduard Estivill. Pero nuestra matrona, con ideas algo diferentes a las expresadas por Estivill, nos recomendó Dormir sin lágrimas, de Rosa Jové, lo cual, sin lugar a dudas para mi mujer y para mí, ha sido la elección correcta.
Qué esperaba
Sin haber leído el libro de Estivill, conocía por encima la idea general del método para dormir que expone en su libro, pero no me encontraba muy cómodo con la idea de dejar que mi hijo aprendiera a dormir por sí solo.
Así pues, ya que Dormir sin lágrimas nos fue presentado como un libro antagónico, esperaba un libro cuyas ideas eran opuestas a las de Estivill. Siendo realistas, no esperaba que el libro propusiera un método infalible para poder dormir a los bebés, pero hubiera sido lo ideal, ya que es una de las cosas que los padres/madres primerizos estamos deseando tener.
Qué encontré
Encontré un libro bien estructurado, donde las soluciones a los problemas vienen precedidas de unas correctas explicaciones de los problemas.
El libro no se limita a documentar los problemas con casos extremos que un doctor puede encontrar en su consulta, si no que primero analiza científicamente (pero cercano a los que no tenemos grandes conocimientos médicos) los problemas y sus causas. Los primeros capítulos se analiza el sueño en el ser humano, desde que nacemos, durante el crecimiento y la madurez, hasta la vejez. La idea principal se puede resumir en la siguiente frase:
El sueño es un proceso evolutivo.
Un bebé no duerme como un niño, así como un niño no duerme como un adolescente, ni éste como un adulto, ni ésto como un anciano. El sueño tiene, para cada edad, sus particularidades, y conocerlas nos ayuda a comprender el sueño de los bebés.
En capítulos siguientes analiza distintas patologías del sueño en los bebés y los niños: problemas para conciliar el sueño, despertares nocturnos, pesadillas, … Para cada uno de ellos nos ofrece una explicación científica y consejos para minimizarlos, aunque todos se podrían resumir en que el mejor consejo es la prevención.
Tiene muchas referencias a artículos y estudios, lo cual hace confiar en sus palabras, aunque también ejemplifica varias veces con casos extremos “de consulta”. Supongo que para hacer más ameno el libro.
Conclusiones
Básicamente, las ideas que promueve Rosa Jové en este libro las encontraremos totalmente opuestas a aquellos libros que nos muestran métodos para dormir a los bebés. De hecho, una de las ideas que defiende Jové es que, precisamente, no hay ningún método para dormir a los bebés. ¡Qué decepción! Con lo magnífico que sería que los bebés tuvieran un botón de apagado, pero, no puede ser. Según la autora:
Los bebés son personas, debemos tratarlos como tal
Lo único, que son personas que dependen totalmente de sus cuidadores, normalmente sus padres. Así pues, es una crueldad no atender a sus necesidades más básicas: comer y dormir.
Otras ideas fuertemente defendidas por Jové serían:
- Las necesidades de los bebés hay que cubrirlas bajo demanda, es decir, darle de comer cuando lo pida, y dormirle cuando lo pida. Según vaya creciendo el bebé, se irá acostumbrando al ritmo de sus padres, ¡siempre!. No es necesario obligar al bebé a seguir nuestro ritmo, acabará por adaptarse.
- Defiende aférrimamente el colecho, que el bebé duerma en la misma cama que los padres.
