Terminal

Supongamos que queremos cambiar el UID (USER ID) y el GID (GROUP ID) para todos los ficheros y directorios de un usuario.  El procedimiento es muy sencillo:

  1. Primero, asigna un nuevo UID al usuario usando el comando usermod.
  2. Segundo, asigna un nuevo GID al grupo usando el comando groupmod.
  3. Finalmente, utiliza los comandos chown y chgrp para cambiar los antiguos UID y GID respectivamente.  Puedes automatizar este proceso con la ayuda del comando find.

Por seguridad, es importante hacer una copia de seguridad de tu sistema antes de hacer esto.

Supongamos que tenemos:

  1. Nombre de usuario: foo
  2. Viejo UID de foo: 1005
  3. Nuevo UID de foo: 2005
  4. Nombre de grupo de usuario: foo
  5. Viejo GID de foo: 2000
  6. Nuevo GID de foo: 3000

Comandos:

Para asignar un nuevo UID al usuario llamado foo, escribe:
# usermod -u 2005 foo

Para asignar un nuevo GID al grupo llamado foo, escribe:
# groupmod -g 3000 foo

Tan pronto como como escribes los anteriores comandos, todos los fichero ubicados en el directorio home del usuario tendrán el UID cambiado automáticamente.  Sin embargo, los ficheros que se encuentran fuera del directorio home del usuario tendrán que ser cambiados manualmente.  Para cambiar manualmente fichero con los viejos GID y UID respectivamente, escribe:
# find / -group 2000 -exec chgrp -h foo {} \;
# find / -user 1005 -exec chown -h foo {} \;

El comando -exec ejecuta el comando chgrp o chmod en cada fichero.  La opción -h pasada al comando chgrp/chmod afecta a cada enlace simbólico en vez de a cualquier fichero referenciado.

vía

javalogo

Desafortunadamente la JDK no está disponible como un zip portable para Windows.  Sin embargo, para tener una versión portable puedes seguir esto pasos:

  • Crea un directorio JDK de trabajo (en este caso C:\JDK)
  • Descarga la última versión de la JDK de la página de Oracle (por ejemplo jdk-7u7-windows-x64.exe)
  • Descarga e instala 7-Zip (o descarga la versión 7-Zip portable si no eres administrador)
  • Extrae con 7-Zip todos los fichero de jdk-XuXX-windows-x64.exe en el directorio C:\JDK
  • Ejecuta los siguiente comandos en cmd.exe:
    • cd C:\JDK\.srcs\JAVA_CAB10
    • extract32 111
  • Desempaqueta C:\JDK\.rsrc\JAVA_CAB10\tools.zip con 7-zip
  • Ejecuta los siguientes comando en cmd.exe:
    • cd C:\JDK\.rsrc\JAVA_CAB10\tools\
    • for /r %x in (*.pack) do .\bin\unpack200 -r "%x" "%~dx%~px%~nx.jar"
      (esto convertirá todos los ficheros .pack en fichero .jar)
  • Copia todo el contenido de C:\JDK\.srcs\JAVA_CAB10\tools a donde quieras que esté tu JDK
  • Establece manualmente las variables JAVA_HOME y PATH para que apunten a tu directorio JDK y su subdirectorio BIN

NOTA:  En las últimas versiones de la JDK, al descomprimir el dichero jdk-XuXX-windows-x64.exe con el 7-Zip, directamente nos aparece el dichero tools.zip (no hay que ir al directorio .srcs\JAVA_CAB10 y ejecutar el extract32).

vía

jpa-mini-logo

Introducción

Supongamos que tenemos las siguientes tablas con sus correspondientes relaciones:

tablas

Leer el resto de esta entrada »

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 »

A %d blogueros les gusta esto: