What about…

Y es que por la cuenta que me trae, más me vale ir aprendiendo algo de checho ya que es a la República Checa donde me ha llevado mi nueva aventura profesional. No, no he cambaido de empresa sino que a la actual le surgió un proyecto en Praga y yo fui uno de los premiados.

Siempre me mostré encantado con la idea de ir a trabajar una temporada fuera por lo que nunca hubo ninguna necesidad por parte de nadie de convencerme. Ya que le gusta la idea de irse fuera, debieron pensar mis jefes, vamos a plantearlo como un premio: “siempre pensamos en ti cuando surgió este proyecto, te lo has ganado, te lo mereces…”. Seamos sinceros, estoy seguro de que si me respuesta no hubiera sido tan favorable ante la posibilidad de irme a un proyecto fuera otro hubiera sido el planteamiento por parte de la empresa. Tal vez un “es una gran oportunidad, te vamos a pagar más…”. No me parece reprochable este comportamiento de la empresa y es que cada cual intenta jugar sus cartas lo mejor que puede.

Si me paro a pensar llego a la conclusión de que no debe de haber por ahí mucha gente dispuesta a hacer la maleta e irse a un país extranjero donde hablan otro idioma a trabajar en un proyecto complicado.

Mi situación personal y mis vivencias me permite esta aventura:

• Para empezar, ya no sé ni los años que hace que me fui de casa para estudiar fuera. He vivido en distintas ciudades y dormido en una docena de sitios diferentes por lo que no he podido desarrolloar un amor incondicional a un cama y/o colchón en particular. Por ahí se escucha hablar de gente que apenas puede dormir si no es en su propia cama o si el colchón no tiene una infinidad de características.
• Llevo alejado de la cocina de mi madre los mismos años que llevo fuera así que mi estomago no es nada delicado. Los que me conocen, saben que básicamente, si me cae en el plato y hay pan para acompañar, me lo como y hasta rebaño (mi padres pueden estar orgulloso). No tengo problemas si aquí la mitad de los días acabo comiendo pollo porque apenas hay otras opciones viables o si la mayonesa sabe mostaza. Muchos hay por ahí que o comen en casa o se llevan el tupper porque han desarrollado una intolerancia a cualquier comida que no sea la de sus madre.
• Vivir fuera de casa también haces que olvides otros hábitos alimenticio. Si hay que almorzar a las 11 porque es constumbre del país donde estás y cenar a las 23 el mismo día porque es la costumbre en España tampoco tengo problema, no va a provocar en mí ningún trastorno alimenticio. Muchos no sobrevivirían.
• He cambido de ciudad varias veces, como he dicho, y varias veces son las que he dejado a tras práticamente todos los amigos. Sé lo que es estar varias semanas sin poder ir a tomar un copa por no tener con quién ir a tomarla por lo que ahora, si me tengo que quedar un fin de semana sólo en un país extranjero, no voy a entrar en depresión ni llamaré llorando a casa.
• Llevo años viendo series en versión original y leyendo libros en inglés unos años ya por lo que ahora, a pesar de haber recibido mi última clase de inglés allá por el 99 ahora logro sobrevivir en un país extranjero y en un proyecto donde el idioma oficial es el inglés. No sin esfuerzo y ni sin malos momentos… pero sobrevivo, cada día mejor.
• Entrando en el terrenos más personal puedo decir que no tengo novia, al menos no una dependencia que me ate a ningún sitio y estoy acostumbrado a estar meses sin ver a la familia.
• …

Por supuesto, también podría hacer una lista de cosas a las aún no estoy acostumbrado, como el que el sol entre por mi ventana a las 4:25 de la mañana por que aquí amanece a esa hora y porque las persianas no son muy conocidas más allá de los pirineos.

No sé… repasando todo esto creo me doy cuenta de que tal vez no sea tan sencillo mandar a alguién a trabajar fuera.

Dicen que Praga es una ciudad presiosa llena de mujeres bonitas. Sí, es cierto, he podido comprabarlo algún fin de semana que me he quedado aquí y es que aunque la empresa me paga lo billetes todas las semanas es una locura coger un vuelo que siembre va con retraso a España el viernes a las 20.00 y pisar suelo español a eso de las doce. Con un poco de suerte estoy metido en cama a eso de las 1 después de unas 7 horas entre taxis, aeropuertos y vuelo. ¿La vuelta? A las 4.30 de la mañana suena mi reloj el lunes: maleta, taxi, aeropuerto, avión, aeropuerto, taxi, oficina, taxi para por fin llegar a mi apartamento en Praga con un poco de suerte a eso de las 20.30. Y levantandose a las 6.30 de la mañana y saliendo a las 20.30 de la oficina (generalmente) no logro superar el madrugón del lunes.

Voy a saltarme la parte en la que hablo del proyecto ya que éste sigue su curso y no me parece correcto comentar nada hasta que termine. Sólo diré que en los cinco años que llevo trabajo jamás había deseado tanto que llegaran los viernes… incluso sabiendo que el viernes me pueden estar esperando hasta 7 horas de viaje para llegar a España. Siempre he hecho el remolón al sonar el despertador y miles de mañanas he pensado en lo maravilloso que sería no ir a trabajar y quedarme durmiendo. Ahora mi pensamiento es diferente por las mañanas. Todas las mañanas la misma idea me invade: no quiero ir a trabajar. Como si fuera un crío de 10 años que no quiere ir al colegio porque el profesor le tiene manía y porque además sabe que los otros chicos del cole le van a pegar al entrar, en la hora del recreo y a la salida.

Mucha gente recordará el mundial de fúltbol de Suráfrica como el año que España ganó el su primer mundial. Yo además, como el año que tuve que ver más de un partido en el aeropuerto. ¿Si celebré el trinfo español? No. Tras ternimar el partido y ver a Casillas levantar la copa, me fui a casa a dormir porque al día siguiente era lunes y el reloj ya estaba puesto a las 4.30.

Por supuesto, como dije, estoy aquí voluntario. Me gusta pensar que fui voluntario. Es una gran oportunidad tanto profesionalmente como personalmente y eso me anima a seguir adelante a pesar de todos los problemas y penurias.

A todos aquellos que piensen que esto es como estar en unas vacaciones pagadas, que aquí nos lo estamos pasando bien y que van diciendo por ahí: “pero qué suerte tienes cabrón”… No, esto no es fácil. ¿Te pondrías en mi lugar? Piénsalo detenidamente.

About job, About me Praga

En Variable Not Found han recogido 30 leyes epónimas relacionadas con el Software. He echado unas risas al leerlas aunque la risa no dura mucho al darme cuenta de que he sufrido ésta o aquella ley. Hay una que especialmente me ha hecho gracia:

8. Ley de Brooks

Incluir trabajadores en un proyecto retrasado hará que éste avance aún más lentamente.

Esta gran ley me recuerda una conversación telefónica que tuve hace unos meses:

Gerente: Voy a sacar a fulanito de proyecto porque hace falta para otro con urgencia.

Juande: ¡Pero si entró hace tres semanas y me ha costado dos y medias formarlo! ¡Y vamos con retraso!

G.: No te preocupes, te meto a otra persona.

J.: Eso retrasará más el proyecto.

G.: Pues metemos a dos.

About job, About me desarrollo, leyes, software

En Javi’s Java podemos encontrar un estupendo post a cerca de Quartz, sobre qué es y cómo se configura dentro de nuestra aplicación Web por lo que no es necesario hablar mucho más del tema. En este post sólo me gustaría resaltar la sencillez y elegancia resultante de la integración de Quartz con Spring, como el mismo Javi comentaba en uno de los comentarios, que nos permite configurar una tarea en apenas un par de minutos.

Tampoco es necesario escribir ninguna línea de código como ejemplo para la integración con Spring ya que la documentación de Spring sobre el tema (cronExpression) es clara y sencilla.

¿Quién necesita ahora los crones de Linux o las tareas de Windows para programar tareas relacionas con nuestra aplicación Web?

Si además necesitamos ejecutar la aplicación en distintas instancias y no queremos que haya problemas, como que el proceso se ejecute simultáneamente en todas ellas, podemos configurar Quartz para que se ejecute en Clustering añadiendo sólo unas cuántas líneas extras en la configuración. Ejemplo de configuración en Spring para la ejecución de Quartz en clustering:

<bean name="job"
   class="org.springframework.scheduling.quartz.JobDetailBean">
    <property name="jobClass" value="whatabout.Job" />
    <property name="jobDataAsMap">
        <map>
            <!-- properties
            <entry key="timeout" value="" />
            -->
        </map>
    </property>
</bean>

<bean id="cronTrigger"
   class="org.springframework.scheduling.quartz.CronTriggerBean">
    <property name="jobDetail" ref="job" />
    <property name="cronExpression" value="0 0 6 * * ?" />
</bean>

<bean
    class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
    <property name="triggers">
        <list>
            <ref bean="cronTrigger" />
        </list>
    </property>
    <property name="applicationContextSchedulerContextKey">
        <value>applicationContext</value>
    </property>
    <property name="startupDelay" value="0" />
    <property name="waitForJobsToCompleteOnShutdown" value="true" />
    <property name="dataSource" ref="myDataSource" />
    <property name="quartzProperties">
        <props>
            <!-- ThreadPool -->
            <prop key="org.quartz.threadPool.class">org.quartz.simpl.SimpleThreadPool</prop>
            <prop key="org.quartz.threadPool.threadCount">5</prop>
            <prop key="org.quartz.threadPool.threadPriority">5</prop>
            <!-- Job store -->
            <prop key="org.quartz.jobStore.misfireThreshold">60000</prop>
            <prop key="org.quartz.jobStore.class">org.quartz.impl.jdbcjobstore.JobStoreTX</prop>
            <prop key="org.quartz.jobStore.driverDelegateClass">org.quartz.impl.jdbcjobstore.StdJDBCDelegate</prop>
            <prop key="org.quartz.jobStore.useProperties">false</prop>
            <!-- Clustering -->
            <prop key="org.quartz.jobStore.isClustered">true</prop>
            <prop key="org.quartz.scheduler.instanceId">AUTO</prop>
            <prop key="org.quartz.jobStore.clusterCheckinInterval">30000</prop>
        </props>
    </property>
</bean>

Evidéntemente es necesario configurar un Datasource (myDataSource en el ejemplo) y crear las tablas de Quartz oportunas. He de añadir que en uno de los últimos proyectos en los que he trabajado hemos montado Quartz en Clustering con cinco máquinas con éxito y después de varios meses en producción ningún proceso se ha ejecutado más de una vez o ninguna.

Referencia:

• Scheduling reference
• ConfigJobStoreTX docs
• Tutorial lesson 9

About job clustering, java, quartz, schedule, spring

Hoy me ha venido el jefe diciendo que hay que hacer una aplicación para gestionar los usuarios de la empresa. Según he entendido, creo que vamos a necesitar tres tablas: EMPLEADO, DIRECCION y CIUDAD de empleado.

¿Cómo plantemos las relaciones entre las tablas? Creo que un principio podría centrarme en la tabla EMPLEADO y que ésta tuviera una clave foránea a la tabla DIRECCION, pero no sé, no me convence. ¿Y si un empleado no tiene dirección? Le pregunto al analista funcional (aquel que ha echado un ojo a los dos folios del documento de requisitos) y me dice que nunca se va a dar el caso en el que tengamos un empleado sin dirección. De todas formas, para curarme en salud, creo que mejor centrarme en la tabla DIRECCION y que ésta tenga dos claves foráneas: id_empleado e id_ciudad. Perfecto, así me curo en salud y ahora un usuario puede no tener ninguna dirección o tener N. Sí, el jefe dice que esto no pasará en la vida, pero yo prefiero pensar en posibles evolutivos que para eso soy más listo y con visión de futuro.

Vale, ahora que ya he decidido cómo van a ser las relaciones entre las tablas veamos ahora los campos de éstas.

Tabla EMPLEADO:

• ID_EMPLEADO. Mejor concatenar el nombre de la tabla con el nombre del campo para estar seguro siempre de qué ID hablamos (siempre pensando en los demás y en el futuro). De tipo VARCHAR(100) además me voy a currar un mega algoritmo que cree genere los ID en función de la hora, la cotización del IBEX 35 y la hora a la que llega mi compi al curro, así me aseguraré de que jamás en la vida se repita un identificador.
• FECNA_TRABAJADOR. VARCHAR(10) . He decidido no poner el literal “fecha nacimiento” al completo porque una vez oí que cobran por caracteres.
• DIA, MES y ANIO. Estos tres campos lo utilizaremos para guardar la fecha de incorporación del empleado. Todos VARCHAR(4). Sé que sólo necesitaría VARCHAR(2) para el día y el mes, pero mejor homogeneizar un poco.
• NOM_DIRECCION. VARCHAR(100). Nombre del empleado.

Ok, decido no describir los campos (los nombres son descriptivos por sí solos) ni indicar cuales de ellos pueden ir a NULL.

Tabla DIRECCION:

• ID_DIR. NUMBER(10) que luego mapearé con un Float o Double.
• CALLE. VARCHAR(200).
• NUMERO. VARCHAR(5).
• TLFNO_DIREC. VARCHAR(10).
• CIUDAD. VARCHAR(32). He decidido guardar también en esta tabla el literal del la ciudad para que no haya que cruzar con la tabla CIUDAD las consultas. Esto agradecerá el rendimiento.
• ID_CIUDAD. Identificador de la ciudad.
• ID_EMPL. Identificador de empleado.
• COM. VARCHAR(50). Creo que nunca viene mal crear un campo comodín por si el día de mañana hace falta algún campo extra. Así no habrá que modificar el modelo.

Tabla CIUDAD:

• ID. VARCHAR(100);
• VALUE. NUMBER(3). ¿cuál es el equivalente a NUMBRE en Java? Ya sé, Number.
• DESCRIPTION. VARCHAR(100)
• FC_CREACION, FC_MODIFICACION. Ambos de tipo DATE. Con estos campos llevaré un control sobre cuando se crean y actualizan los datos.

Qué bien me está quedando el modelo.

De repente me viene otra vez el jefe y me dice que hace falta crear otra tabla para guardar las direcciones de las oficinas y que no puede ser la que ya tenemos. Me pongo al lío:

Tabla DIRECCION… no, el nombre ya está pillado… DIRECCION_OFICINAS… muy largo y vaya ser que cobren por caracteres. Ya sé, ADDRESS. Que se note que sé idiomas.

Ya está todo listo. ¿Qué más puedo hacer para mejorar el modelo? Ya sé, voy a desactivar las claves foráneas. He oído que fastidian el rendimiento y quiero que la aplicación vaya super-rápida además, las claves foráneas es algo que está sobrevalorado, en realidad no son tan necesarias. Debemos confiar más en que la gente mantendrá los datos de forma coherente.

Ahora me voy a poner con la capa DAO. He oído que hay por ahí un algo que se llama “Hibernate” que hace las cosas pero a mí eso no me convence. Me gusta saber lo que hago y llevar el control en todo momento y esto no se puede hacer con los frameworks que no te dejan liberta al desarrollador.

¡Cagüen! Me voy que ya ha pasado un minuto de la hora de irme. Otro día sigo con la capa DAO.

About job java, modelo datos

Recientemente hemos podido leer como ahora Google App Engine soporta Java. Ni corto ni perezoso me he lanzado a probarlo. Pero ya puestos no nos íbamos a conformar con probar un simple Servlet ¿no?

En este enlace podemos ver una prueba de Google App Engine funcionando con Struts 1.3.

Para desarrollar la aplicación y desplegarla he utilizado el plugin de Google para Eclipse.

Por ahora me he quedado aquí, pero habrá que seguir estudiando todas las posibilidades que Google App Engine nos ofrece a los desarrolladores Java.

About job google app engine, java, struts

“Maven está corrompiendo las imágenes” es una frase que que he oido a tres compañeros de mi proyecto actual. Tranquilos, no os preocupeis por eso - les dije yo.

¿Por qué Maven corrompe las imágenes cuando por ejemplo, construimos un war con nuestra aplicación Web? Este problema surge cuando “filtramos” nuestros archivos de recursos (src/main/resources) para sustituir las variables indicadas con los delimitadores ${...}. Qué gran utilidad sin duda para poder construir nuestra aplicación Web para diferentes entornos de forma simple y automática.

¡¡Pero es que corrompe las imáganes!! La solución es bastante sencilla, sólo debéis buscar en Google las siguientes palabras: maven filtering resource images y en la segunda entrada, además de explicaros qué es eso del filtrado, os da la solución para que éste no corrampa las imágenes u otros archivos.

Aquí os pongo el fagmento en particular:

  ...
  
    ...
    
      
        src/main/resources
        true
        
          **/*.jpg
        
      
      
        src/main/resources
        false
        
          **/*.jpg
        
      
      ...
    
    ...
  
  ...
.

Aquí os dejo el enlace con más detalles: http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

About job corrompe, images, java, maven

“Always code as if the person who will maintain your code is a maniac serial killer that knows where you live”

Y es que, nunca se sabe si la persona que va a mantener tu código es un programador o un asesino en serie. Pero claro, qué fue antes, ¿el huevo o la gallina?, porque ¿a quienes no os ha entrado ganas de matar a alguien tras ver algunas líneas de código? A mí sí, es algo que ya sabéis.

Por otro lado, si queréis mantener vuestro puesto de trabajo para siempre, corriendo el riesgo de ser asesinado por un asesino en serie claro está, siempre podéis usar las técnicas de escritura de código inmantenible. Si echáis un vistazo a estas prácticas seguro que os daréis cuenta que sois habituales en algunas de ella aunque de forma menos exagerada (o quizás no). Tal vez sea nuestro instinto de supervivencia lo que nos hace escribir código inmantenible pero paradójicamente esto nos pueda llevar a ser asesinados  por un asesino en serie.

About job code, java, serial killer

Estos días he tenido que montar el esqueleto para un nuevo proyecto. Para mi sorpresa la combinación de Frameworks que se requerían no estaba entre las disponibles de Appfuse Light así que tuve que montarla casi desde cero.

Son muchos los ejemplos y la documentación que se puede encontrar que hablan acerca de cómo montar JPA con Spring, pero como suele suceder casi todos proceden de un ejemplo original por lo que al final todos quedan reducidos a muy pocos que para colmo, están incompletos. Así pues, voy a hacer mi pequeña aportación y describiré el archivo de Spring al completo. No describiré cómo se realizan Test o cómo se crean claves primarias compuestas porque son temas que ya tratan bien en otros blogs.

En primer lugar, empezaré definiendo una entidad, sobre la que girará el ejemplo: User.

package es.whatabout.model;

@Entity
@Table(name = "USER")
public class User{

    @Id
    @Column(name = "ID")
    private Integer idUser;

    @Column(name = "FIRST_NAME")
    private String firstName;

    @Column(name = "LAST_NAME")
    private String lastName;

    ...get/set methods...

}

Como se puede ver, esta clase lleva anotaciones JPA que identifican a esta clase como un entidad, su clave primaria y el mapeo de sus atributos a la tabla y columnas correspondientes en la base de datos. Esta será la única clase que contenga anotaciones ya que el resto de la configuración, como la transaccionalidad, la configuraremos desde Spring.

Antes de definir la clase DAO crearemos un interfaz genérico y su implementación que proporcionará a nuestro dao particular y a todos los que generemos (y su implementaciones) de todos los métodos CRUD gracias a los tipos genéricos de Java.

package es.whatabout.dao;

import java.io.Serializable;
import java.util.List;

public abstract interface GenericDao <T, PK extends Serializable> {

    public abstract List<T> getAll();

    public abstract T findByPK(PK id);

    public abstract void update(T object);

    public abstract void remove(T object);

    public abstract void insert(T object);

}

Y su implementación.

package es.whatabout.dao.impl;

import java.io.Serializable;
import java.lang.reflect.ParameterizedType;
import java.util.ArrayList;
import java.util.List;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.orm.jpa.support.JpaDaoSupport;

import es.whatabout.dao.GenericDao;

public class GenericDaoImpl extends JpaDaoSupport
        implements GenericDao {

    private static Log logger =
            LogFactory.getFactory().getInstance(GenericDaoImpl.class);

    private Class persistentClass;

    public GenericDaoImpl() {
        this.persistentClass =
                (Class) ((ParameterizedType) getClass()
                    .getGenericSuperclass()).getActualTypeArguments()[0];
    }

    public void insert(T t) {
        getJpaTemplate().persist(t);
    }

    public T findByPK(PK id) {
        return getJpaTemplate().find(persistentClass, id);
    }

    public List getAll() {
        List entities = new ArrayList();

        try {
            String s =
                    "select c from " + persistentClass.getSimpleName() + " c";
            entities = getJpaTemplate().find(s);
        } catch (Exception e) {

            logger.error(e.getStackTrace());
        }
        return entities;
    }

    public void remove(T t) {
        getJpaTemplate().remove(getJpaTemplate().merge(t));
    }

    public void update(T object) {
        getJpaTemplate().merge(object);
    }

}

T será la entidad que maneje nuestra clase dao mientras que PK será la clase de la clave primaria de ésta, que puede ser de tipo simple o compuesta (composed primary key)

A continuación crearemos una interfaz para un dao particular y su implementación utilizando el interfaz y la implementación de éste antes definido.

package es.whatabout.dao;

import es.whatabout.model.User;

public interface UserDao extends GenericDao<User, Integer> {

}

Vemos que nuestro interfáz es muy simple, ya que dispone de los métodos CRUD del interfaz GenericDao. Del mismo modo, su implementación también será muy simple ya que ésta extiende de la implementación de GenericDao, GenericDaoImpl

package es.whatabout.dao.impl;

import es.whatabout.dao.UserDao;
import es.whatabout.model.User;

public class UserDaoImpl extends GenericDaoImpl<User, Integer>
        implements UserDao{
}

Sólo queda definir el archivo de configuración de Spring:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:aop="http://www.springframework.org/schema/aop"
	xmlns:tx="http://www.springframework.org/schema/tx"
	xsi:schemaLocation="
		http://www.springframework.org/schema/beans
		http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
		http://www.springframework.org/schema/tx
		http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
		http://www.springframework.org/schema/aop http://
		www.springframework.org/schema/aop/spring-aop-2.5.xsd">

	<!-- archivo de configuracion para los datos de conexion -->
	<bean id="propertyConfigurer"
		class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
		<property name="location" value="classpath:jdbc.properties" />
	</bean>

	<!-- Transaccionalidad para todas las clases del paquete indicado -->
	<aop:config>
		<aop:advisor id="managerTx" advice-ref="txAdvice"
			pointcut="execution(* es.whatabout.dao.impl.*.*(..))" />
	</aop:config>

	<!-- restringimos a solo lectura las transacciones metodos que comienzan por get -->
	<tx:advice id="txAdvice">
		<tx:attributes>
			<tx:method name="get*" read-only="true" />
			<tx:method name="*" />
		</tx:attributes>
	</tx:advice>

	<!-- configuramos el transaction  manager-->
	<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
		<property name="dataSource" ref="dataSource" />
		<property name="entityManagerFactory" ref="entityManagerFactory" />
	</bean>

	<!-- Conexion a bd con las propiedades del arhivo jdbc.properties-->
	<bean id="dataSource"
		class="org.springframework.jdbc.datasource.DriverManagerDataSource">
		<property name="driverClassName" value="${jdbc.driverClassName}" />
		<property name="url" value="${jdbc.url}" />
		<property name="username" value="${jdbc.username}" />
		<property name="password" value="${jdbc.password}" />
	</bean>

	<!-- configuramos la Factory Manager, que trabajará con hibernate-->
	<bean id="entityManagerFactory"
		class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
		<property name="dataSource" ref="dataSource" />
		<property name="jpaVendorAdapter">
			<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
				<property name="showSql" value="true" />
				<property name="databasePlatform" value="${hibernate.dialect}" />
			</bean>
		</property>
		<property name="jpaProperties">
			<value>hibernate.show_sql=true</value>
		</property>
	</bean>

	<!-- configuramos LOG4J -->
	<bean id="log4jInitialization"
		class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
		<property name="targetClass" value="org.springframework.util.Log4jConfigurer" />
		<property name="targetMethod" value="initLogging" />
		<property name="arguments">
			<list>
				<value>classpath:log4j.xml</value>
			</list>
		</property>
	</bean>

	<!-- inyeccion del entityManagerFActory a nuestro Dao particular-->
	<bean id="userDao" class="es.whatabout.dao.impl.UserDaoImpl">
		<property name="entityManagerFactory" ref="entityManagerFactory" />
	</bean>

</beans>

Con este archivo de cofiguración ya podemos disponer de nuestro dao capaz de realizar todas las operacoines CRUD sin ningún proplema.

Referencia: The Spring Framework - Reference Documentation, chapter 9, Introduction to Spring 2 and JPA
Código: descargar

About job appfuse, crud, hibernate, java, spring

Después de diez meses en el proyecto para el Grupo Antena3, que empezó cuatro meses antes de mi llegada, éste ha llegado su fin, al menos para la mayoría, yo entre ellos.

Se han cometido muchos errores, a todos los niveles y de toda clases, algunos incluso fuera de mi alcance y comprensión pero sin duda también ha habido muchas cosas positivas que merecen ser destacadas.

Entre ellas, la evolución de todos los miembros del proyecto y del equipo en conjunto que se puede ver reflejada en los cuatro portales desarrollados hasta ahora (y un quinto en camino) ya que cada portal que hemos desarrollado refleja las ganas y el esfuerzo del equipo por hacer las cosas mejor.

Sé que el propio equipo, desde los programadores hasta los gestores, e incluso el mismo cliente son conscientes de esta evolución resultado del esfuerzo personal a través de muchas horas de trabajo y las ganas de aprender y hacer las cosas bien por parte de todos los componentes.

Todos los miembros del equipo podemos y debemos, a pesar de todo, estar orgullosos de nuestro trabajo, de lo que hemos conseguido bajos unas condiciones muy duras (falta de documentación, tiempos de entrega imposibles, desplazamiento en cliente…).

Recuerdo cómo en mi primera etapa en Indra cuando al equipo nos caía un marrón decíamos entre risas: ¿y lo que vamos a aprender?. Ahora, tras tanto esfuerzo, yo le digo al equipo: ¿y lo que hemos aprendido?. Sin duda mucho. Por eso es tiempo de mirar atrás para contemplar todo aquello que hemos aprendido y reflexionar sobre qué aspectos debemos seguir mejorando. Sí sí, yo tengo que mejorar mi diplomacia y mi mano izquierda, lo sé lo sé.

Por otra parte, debido al tamaño del proyecto, son viarios los miembros del equipo que han tenido la oportunidad de dar un paso al frente y hacerse cargo de responsabilidades huérfanas cuando, como se dice comúnmente, no están pagadas. Algunos de ellos lo hicieron, dieron un paso al frente, tomaron responsabilidades y demostraron su capacidad. Qué gusto da ver a una persona aprovechar una oportunidad para demostrar su valía y salir triunfante. Otros, no lo hicieron y ha sido una lástima ya que estas oportunidades no se presentan todos los días.

Ahora, sólo queda esperar nuevo proyecto.

About job, About me antena3, java, proyecto

A pesar de los años que han pasado, todavía recuerdo con exactitud aquel día de mi primer año en la facultad, hace ya 9 años, en el que estando cogiendo apuntes como un loco en la clase de Física mi fijé en cómo tomaba apuntes la compañera que tenía a mi izquierda. La chica tomaba apuntes de todo lo que decía o escribía en la pizarra el profesor como si de una mecanógrafa se tratase, cosa que me parecía absurdo e inútil, mientras que yo sólo tomaba nota de aquello que consideraba importante, no molestándome en anotar aquellas cosas que me parecían evidentes y que por tanto no se me olvidarían.

Con la llegada de los primeros exámenes, momentos en lo que tiré por primera vez de mis apuntes de forma seria, descubrí que mis apuntes eran un desastre puesto que había grandes lagunas sobre esas cosas tan evidentes que no me molesté en anotar. Pero aprendí. Aprendí que todas las cosas que en un momento dado en caliente parecen evidentes pueden dejar de serlo cuatro meses después.

Mis apuntes del segundo cuatrimestres fueron muy distintos. Eran muchos más gruesos ya que al igual que hacía la chica (que se ve que aprendió esta lección antes que yo) yo anotaba toda y cada una de las cosas que decía el profesor. Si éste decía algo evidente o que yo no consideraba importante en ese momento, lo anotaba. Que dos minutos después lo repetía, pues yo lo volvía a anotar como si fuera tonto.

Sin duda, esta decisión de considerarme tonto a la hora de coger apuntes me vino de gran ayuda el resto de años en la facultad.

Hoy en día, procuro extender esta práctica a mi profesión, tomando nota de cualquier chorrada que se diga en las reuniones o comentando los métodos que programo sabiendo con certeza que debido a las líneas que tiro a lo largo de una semana que en un mes no recordaré ni haber hecho tales métodos o clases. Y si yo no recordaré si tan si quiera haber programado esos métodos… ¿cómo voy a recordar qué hacen? Y peor aún, ¿cómo sabrá alguien que ni si quiera ha escrito esos métodos qué hace?

La respuesta es bien fácil: documentando el método. ¡Pero si es un método muy intuitivo que no necesita documentación! Se comenta. ¡Pero si está claro lo que hace! Se comenta. ¡Pero si hasta un tonto sabría lo que hace con sólo leer el nombre del método! Se comenta, que para tonto yo.

Así que para concluir: señores y señoritas, si no se consideran suficiente tontos como yo como para comentar lo evidente por favor, piensen en mí que sí lo soy y comenten todo.

About job documentación, evidente, java, programación