jpa-mini-logo

Introducción

Cuando se introdujo JPA 2 en el 2009, incluía la nueva criteria API. El propósito de este API era alejarse del uso de los strings JQL (JPA Query Language) en tu código. Aunque JQL parece una buena idea para “apalancarte” en tus conocimientos de SQL, en el mundo de la OO (Orientación a Objetos) tiene una grave desventaja: no existe la comprobación de las query strings en tiempo de compilación. La primera vez que tienes constancia de algo mal escrito o sintácticamente incorrecto en tu query string es en tiempo de ejecución. Esto puede hacer que baje mucho el rendimiento si los desarrolladores tienen que corregir, compilar y redesplegar para continuar.

Los test unitarios pueden ayudar a solucionar este problema pero un área donde no ayudan los test unitarios es en la refactorización. La mayoría de las herramientas de refactorización no se llevan bien con las cadenas de texto y acabas teniendo que ejecutar de nuevo los test y teniendo que corregir manualmente cada string en cada iteración de test hasta que todo está correcto.

Con la JPA Criteria API es posible tener consultas type safe (con comprobación de tipado) que se comprueben en tiempo de ejecución y que permitan una refactorización mucho más eficiente.

Leer el resto de esta entrada »

hibernate_logo

Cuidado con usar SQL Queries con Hibernate

Como nuevo usuario de Hibernate, te puede sorprender agradablemente ver que soporta la ejecución de consultas SQL mediante el método createSQLQuery() del objeto Session de Hibernate.

Inicialmente parece beneficioso utilizar las viejas y sencillas sentencias SQL para generar las consultas en tus DAO’s. Después de todo, ya conoces SQL, así que porque perder el tiempo aprendiendo HQL (Hibernate Query Language) o el Hibernate Criteria API. Además, con SQL podemos probar fácilmente las consultas en herramientas de edición de base de datos como DBVisualizer y en el caso “raro” de que lo pudiera necesitar, un DBA no familiarizado con Hibernate podría mantener y mejorar mis consultas de un modo sencillo.

Parece la solución.

Leer el resto de esta entrada »

MAVEN Lifecycle

10/06/2016

Maven

Fundamentos básicos del ciclo de vida de la construcción

Maven se fundamenta en el concepto central de ciclo de vida de construcción (build lifecycle). Esto significa que el proceso de construcción y distribución de un artifact (artefacto = proyecto) concreto está definido claramente.

Para la persona que quiera construir un proyecto significa que solamente es necesario aprender un pequeño conjunto de comandos para construir cualquier proyecto Maven, y el POM se asegurará de que obtenga los resultados deseados.

Existen tres ciclos de vida en el sistema: default, clean y site. El ciclo de vida default controla el despliegue de tu proyecto, el ciclo de vida clean controla la limpieza de tu proyecto, mientras que el ciclo de vida site controla la creación del site de documentación de tu proyecto.

Leer el resto de esta entrada »

Maven

Para conseguir nuestro objetivo debemos seguir una serie de pasos:

  • Obtener el código fuente tal cual está
  • Asociarle una versión (probablemente eliminado el subfijo -SNAPSHOT) de modo que pueda ser identificado unívocamente
  • Construir, probar y empaquetar
  • Desplegar en un repositorio de artefactos donde pueda ser recuperado para su instalación
  • Etiquetar este estado en el SCM para que pueda ser asociado con el artefacto correspondiente
  • Asociar una nueva versión de desarrollo (probablemente subiendo el número de versión y añadiendo el subfijo -SNAPSHOT)
  • Construir y probar
  • Subir el cambio de versión de desarrollo al SCM

Bastante sencillo, no?

Leer el resto de esta entrada »

Maven

Para conseguir nuestro objetivo debemos seguir una serie de pasos:

  • Obtener el código fuente tal cual está
  • Asociarle una versión (probablemente eliminado el subfijo -SNAPSHOT) de modo que pueda ser identificado unívocamente
  • Construir y probar
  • Etiquetar este estado en el SCM para que pueda ser asociado con el artefacto correspondiente
  • Asociar una nueva versión de desarrollo (probablemente subiendo el número de versión y añadiendo el subfijo -SNAPSHOT)
  • Subir el cambio de versión de desarrollo al SCM
  • Obtener el código fuente de la versión etiquetada
  • Construir, probar y empaquetar
  • Desplegar en un repositorio de artefactos donde pueda ser recuperado para su instalación

Bastante sencillo, no?

Leer el resto de esta entrada »

Maven

Si alguna vez has trabajado con Maven sabrás que te permite definir propiedades personalizadas que se pueden utilizar como placeholders (marcadores o comodines) para reutilizar valores o con fines de configuración o incluso como un modo de configurar los recursos de tu construcción final usando filtros (filters).  Esto nos viene muy bien para definir configuraciones específicas por entorno.

Estas propiedades personalizadas se pueden definir en múltiples lugares.  Pero ¿qué ocurre cuando defines (o re-defines) la misma propiedad en múltiples lugares?  ¿Que definición tendrá precedencia sobre las otras?

El orden de precedencia a la hora de resolver el valor de las propiedades personalizadas en Maven es el siguiente:

  • Propiedades del sistema (system):  establecidas con -Dxyz=valor desde la línea de comandos
  • De/los perfil/es (profile) activo/s actualmente:  settings.xml del directorio de usuario primero, profiles.xml del directorio raiz del proyecto después, y los perfiles definidos en el pom.xml en último lugar.  Si están activos varios perfiles y una propiedad está definida en más de uno, el orden de precedencia se basa en el último perfil en que la propiedad ha sido definido, en orden alfabético del nombre del perfil.
  • En la sección properties del pom.xml
  • Por último, en los properties de los filtros.  Si una propiedad se define en múltiples filtros, el último (en orden de aparición en la sección filters) tiene precedencia sobre los otros.

vía

Remix_OSHay varios tutoriales para realizar la instalación en un equipo que ya tiene instalado un sistema operativo y realizar un arranque dual, pero no he encontrado ninguno en el que expliquen, paso a paso, cómo instalar Remix OS 2.0 Alpha en un PC “limpio”, dejando el Remix OS como único Sistema Operativo del sistema y ocupando todo el disco duro.

Para realizar la instalación utilizaremos un LiveCD de instalación de Ubuntu 15.04 y un CD o USB con la imagen iso del Remix OS 2.0 Alpha (versión legacy).

  1. Arrancamos el PC con el LiveCD de ubuntu.
  2. Usando el programa gparted, creamos en el disco duro una partición de tipo ext4 que ocupe todo el disco duro.
  3. Formateamos la partición con formato ext4 y la marcamos como partición de arranque (boot).
  4. Montamos la nueva nueva partición en el Live Ubuntu (suponiendo que la unidad es /dev/sda):

    # mkdir -p /mnt/disk
    # mount -t ext4 /dev/sda1 /mnt/disk

  5. Creamos el directorio /boot donde instalaremos el gestor de arranque Grub:

    # mkdir /mnt/disk/boot

  6. Instalamos el Grub en la nueva unidad:

    # grub-install –boot-directory=/mnt/disk/boot /dev/sda

  7. Creamos ahora dos nuevas entradas para el menú de arranque de Grub, una para realizar la instalación y otra para arrancar el sistema una vez arrancado.  Para ello editamos (creamos) el fichero /boot/gub/grub.cfg en la nueva partición:
    # gedit /mnt/disk/boot/grub/grub.cfg

    menuentry “Remix Os Install” {
    insmod gzio
    insmod part_msdos
    insmod ext4
    set root=’hd0,msdos1′
    linux    /RemixOS/kernel root=/dev/ram0 androidboot.hardware=remix_x86_64 androidboot.selinux=permissive quiet INSTALL=1 DEBUG=0
    initrd    /RemixOS/initrd.img
    }

    menuentry “Remix Os Run” {
    insmod gzio
    insmod part_msdos
    insmod ext4
    set root=’hd0,msdos1′
    linux    /android-2016-01-12/kernel root=/dev/ram0 androidboot.hardware=remix_x86_64 androidboot.selinux=permissive quiet SRC=/android-2016-01-12 DATA=CREATE_DATA_IMG=1 DPI=160 UVESA_MODE=1366×768
    initrd    /android-2016-01-12/initrd.img
    }

  8. Montamos la imagen ISO del Remix OS 2.0 Alpha:

    # mkdir -p /mnt/iso
    # mount -o loop Remix_OS_for_PC_64_B2016011201_Alpha.iso /mnt/iso

  9. Creamos un directorio RemixOS en la nueva partición y copiamos todo el contenido del CD del Remix OS en dicho directorio:

    # mkdir /mnt/disk/RemixOS
    # cp -R /mnt/iso/* /mnt/RemixOS

  10. Reiniciamos el equipo (sin el LiveCD de Ubuntu, arrancando desde el disco duro)
  11. Aparecerán las opciones definidas en el arranque de GRUB.  Seleccionamos Remix Os Install.
  12. Seguimos las instrucciones para realizar la instalación del Sistema Operativo indicando que no se desea instalar el GRUB ni formatear la partición y los datos.
  13. Esto instalará el nuevo sistema en la carpeta android-2016-01-12.
  14. Reiniciamos el sistema y ahora seleccionamos “Remix Os Run”.
A %d blogueros les gusta esto: