Mostrando entradas con la etiqueta java. Mostrar todas las entradas
Mostrando entradas con la etiqueta java. Mostrar todas las entradas

lunes, 19 de diciembre de 2016

Como Generar Entidades a partir del Modelo

Después de generar una aplicación con JHipster, esta se encontrá vacia de contenido a no ser que generemos entidades, tendrá la funcinalidad básica, control de acceso, autentificación y autorización, tendrá implementada la internacionalización, etc. pero no podremos hacer mucho más porque no contamos con entidades.

Para generar entidades tenemos dos opciones:

Generar las entidades una a una.

Con el siguiente comando:
yo jhipster:entity EntityName
Donde EntityName es el nombre de la entidad que queremos generar,  jhipster nos preguntará si queremos añadir campos a esta entidad, el nombre del campo, el tipo, si queremos validaciones básicas sobre este campo, como que sea obligatorio, o una longitud mínima, si queremos relaciones con otras entidades.

En lo que a la interfaz de usuario se refiere nos preguntará si queremos paginación y de que tipo.

Y en lo que a la arquitectura se refiere nos preguntará si queremos crear un DTO (Data transefer Object, o Objeto de Transferencia de Datos) o si queremos usar la entidad directamente.

Finalmente nos informará de los ficheros que genera.


~$ yo jhipster:entity entity
The entity entity is being created.

Generating field #1
? Do you want to add a field to your entity? Yes
? What is the name of your field? field1
? What is the type of your field? String
? Do you want to add validation rules to your field? Yes
? Which validation rules do you want to add? Required, Minimum length
? What is the minimum length of your field? 10
================= Entity =================
Fields
field1 (String) required minlength='10'

Generating field #2
? Do you want to add a field to your entity? No
================= Entity =================
Fields
field1 (String) required minlength='10'

Generating relationships to other entities
? Do you want to add a relationship to another entity? Yes
? What is the name of the other entity? user
? What is the name of the relationship? user
? What is the type of the relationship? one-to-one
================= Entity =================
Fields
field1 (String) required minlength='10'
Relationships
user (User) one-to-one

Generating relationships to other entities
? Do you want to add a relationship to another entity? No
================= Entity =================
Fields
field1 (String) required minlength='10'
Relationships
user (User) one-to-one


? Do you want to use a Data Transfer Object (DTO)? No, use the entity directly
? Do you want to use separate service class for your business logic? No, the REST controller should use the repository
directly
? Do you want pagination on your entity? Yes, with a simple pager
Everything is configured, generating the entity...
   create .jhipster\Entity.json
   create src\main\resources\config\liquibase\changelog\20161208212848_added_entity_Entity.xml
   create src\main\resources\config\liquibase\changelog\20161208212848_added_entity_constraints_Entity.xml
 conflict src\main\resources\config\liquibase\master.xml
? Overwrite src\main\resources\config\liquibase\master.xml? overwrite this and all others
    force src\main\resources\config\liquibase\master.xml
   create src\main\java\com\jlg\basketshop\domain\Entity.java
   create src\main\java\com\jlg\basketshop\repository\EntityRepository.java
   create src\main\java\com\jlg\basketshop\repository\search\EntitySearchRepository.java
   create src\main\java\com\jlg\basketshop\web\rest\EntityResource.java
    force src\main\resources\ehcache.xml
   create src\main\webapp\app\entities\entity\entities.html
   create src\main\webapp\app\entities\entity\entity-detail.html
   create src\main\webapp\app\entities\entity\entity-dialog.html
   create src\main\webapp\app\entities\entity\entity-delete-dialog.html
    force src\main\webapp\app\layouts\navbar\navbar.html
   create src\main\webapp\app\entities\entity\entity.state.js
   create src\main\webapp\app\entities\entity\entity.controller.js
   create src\main\webapp\app\entities\entity\entity-dialog.controller.js
   create src\main\webapp\app\entities\entity\entity-delete-dialog.controller.js
   create src\main\webapp\app\entities\entity\entity-detail.controller.js
   create src\main\webapp\app\entities\entity\entity.service.js
   create src\main\webapp\app\entities\entity\entity.search.service.js
   create src\main\webapp\i18n\en\entity.json
    force src\main\webapp\i18n\en\global.json
   create src\main\webapp\i18n\es\entity.json
    force src\main\webapp\i18n\es\global.json
   create src\test\javascript\spec\app\entities\entity\entity-detail.controller.spec.js
   create src\test\java\com\jlg\basketshop\web\rest\EntityResourceIntTest.java
   create src\test\gatling\simulations\EntityGatlingTest.scala
Running gulp Inject to add javascript to index

Generar todas las entidades y sus relaciones de golpe a partir de una representación del modelo.

La otra forma de generar las entidades, es utilizar jdl-studio para diseñar el modelo, entidades y relaciones, exportar ese modelo a un fichero en formato json, y después utilizar ese fichero como entrada para generar todas las entidades de una sóla vez.




Este este es el diagrama ejemplo que podemos encontrar en jdl- studio.

A mi esta herramienta me gusta bastante, a medida que diseñas las entidades mediante la edición de texto, puedes ver la representación en la parte de la derecha, por ejemplo, la entidad Empleado tiene la siguiente pinta:

entity Employee {
/**
* The firstname attribute.
*/
firstName String,
lastName String,
email String,
phoneNumber String,
hireDate ZonedDateTime,
salary Long,
commissionPct Long
}

Una vez que estamos contentos con el modelo, sólo tenemos que descargar el fichero y utilizar el comando:

yo jhipster:import-jdl jhipster-jdl.jh

En este caso he llamado al fichero con el modelo, "jhipster-jdl.jh".




jueves, 1 de diciembre de 2016

Video Demostración de JHipster


En este vídeo muestro la potencia de JHipster, como generar una aplicación con tecnologías a medida. En concreto en este vídeo se utilizan:

  • OAuth2
  • H2 y MySQL BBDD
  • Hibernate
  • Spring y Spring Boot
  • Gradle
  • Saas y LibSaas
  • Gatling
  • Angularjs
  • gulp


















Posteriormente se crea el modelo utilizando como entrada un fichero donde especifican las entidades que se quieren generar, pero ya hablaremos de este proceso en sucesivos post.

Y para finalizar se hace una pequeña demostración de la aplicación generada.

domingo, 20 de noviembre de 2016

JHipster



En pocas palabras, JHipster es un generador de Aplicaciones web con Angularjs en la parte del cliente y Sprint Framework en la parte del servidor, en el pasado he trabajado con Sprint, pero no con Angularjs, y no tengo que deciros que Angularjs es muy popular cuando se trata de desarrollar aplicaciones web de una sóla página, esto es lo que principalmente hace de JHipster un generador de código muy interesante, en particular si lo comparamos con otros generadores de código para Sprint como "Sprint Initializr".

Pero empecemos por el principio.



¿Qué es un generador de código?

Pues bien, en un generador de código especificamos una serie de parámetros, como las technologías que queremos utilizar en la aplicación, especificamos el modelo de datos, pulsamos un botón, y el generador se encarga magicamente de producir una aplicación entera para nosotros.










Como es de esperar esta aplicación es muy genérica y necesita customización, y aquí entramos en uno de los problemas más habituales que tienen este tipo de herramientas y donde se nos ocuren la típicas preguntas:


  • ¿Como de fácil es luego customizar estas aplicaciones?
  • ¿Si cambiamos el modelo, tenemos que volver a generar la aplicación?
  • ¿Es posible generarar sólo una parte de la aplicacion?


La mejor forma de responder estas preguntas es utilizar Jhipter en un pequeño proyecto, y esa es mi intención para el próximo post.

¿Qué generará JHipster por mi?

Entre otros cosas generará:


  • CRUD para cada una de las entidades especificadas.
  • Sistema de autorización y autentificación, con varios usuarios por defecto.
  • Frontend application with Angularjs y Bootstrap.





viernes, 29 de agosto de 2008

Revisión del libro: J2EE Architect's Handbook

Recientemente he terminado de leer un libro sobre arquitectura The J2EE Architect's Handbook de Derek Ashmore, te lo puedes descargar de forma gratuita de theserverside , el libro es un poco antiguo, del 2004, y eso se nota al abordar ciertos temas como por ejemplo las tecnologías que sugiere para las distintas capas de una aplicación J2EE, en muchos casos ya han quedado un poco obsoletas, pero tampoco entra en detalles de bajo nivel con lo que no importa mucho y hace un completo repaso del ciclo de vida del desarrollo software desde un punto de vista de las tecnologías J2EE, me pareció buena idea echarle una lectura saltando algunas partes.

El libro está dividido en cuatro secciones:

  • Planificando aplicaciones J2EE.
  • Diseñando aplicaciones J2EE.
  • Construyendo aplicaciones J2EE.
  • Testeando y manteniendo aplicaciones J2EE.


En algunas fases da buenos consejos, coincido con el autor en el empleo de varias “Best Practices”, pero no estoy de acuerdo en varios aspectos, como por ejemplo creo que le da demasiadas atribuciones a la figura del Arquitecto que creo que deberían pertenecer al Jefe de proyecto, que desde mi punto de vista debe tener también un importante background técnico en el desarrollo de aplicaciones, pero como conclusión creo que si que merece la pena echarle un vistazo porque siempre aportará alguna idea nueva o aunque sólo sea por hacer un repaso de como se desarrolla una aplicación.

Al dar consejos para hacer un buen desarrollo de software me recordo a "The Pragmatic Programmer" de Andrew Hunt, que es un verdadero clásico al respecto, y que fue considerado en su día por javalobby como el 9º de los libros técnicos imprescindibles , donde también aparecen un par de libros relacionados con arquitectura J2EE de Rod Jonson que a mi me resultaron muy interesantes: “J2EE Design and Development” y “J2EE Development without EJB” aunque este último es anterior a que saliese la especificación de EJB 3.0.


delicious | digg | technorati | yahoo | meneame

jueves, 28 de agosto de 2008

Análizador Estático de Código para Java.

Le estoy echando un vistazo a los Analizadores estáticos de código que existen para java, La definición de un AEC podría ser la siguiente: Es una herramienta software que realiza Análisis estático de Código, es decir examina el código fuente de una aplicación, en contraposición al análisis dinámico que lo que hace es examinar el resultado de este código en ejecución, la intención de este tipo de herramientas es encontrar posibles errores o incorrecciones, antipatrones o malas practicas de programación de una forma automática, suelen ofrecer informes con métricas del tipo complejidad ciclomática, longitud de línea, el número de líneas sin comentarios, el tamaño de métodos, clases, etc.

Para tener una idea del estado de madurez y del empleo de estas herramientas en el mundo real y antes de decidirme a probar una en profundidad he decidido realizar el típico estudio utilizando las herramientas de google para comparar el impacto que tiene cada una de las distintas alternativas en la red, en este caso he usado la nueva herramienta de google, google insights compañera de google trends, utilizando la lista de que propone la wikipedia para java y oponsource:

  1. Bandera
  2. Checkstyle
  3. Classycle
  4. FindBugs
  5. Jlint
  6. PMD
  7. SCL
  8. Soot
  9. Hammurapi
  10. UCDetector

Y añadiendo a cada término de búsqueda “java” para delimitar el contexto he realizado las siguientes comparaciones:

1 - cinco primeros

Es necesario dividir las búsquedas en grupos de cinco ya que google insights no permite introducir más términos de una sola vez.

2 - cinco siguientes


Si nos quedamos con los que más movimiento tienen ( menos en el caso de jlint y bandera que he decidido quedarme con jlint ya que bandera es un término muy común y seguro que se cuelan más resultados indeseados):


3 - cinco más exitosos

Como podéis ver históricamente Checkstyle se sitúa en cabeza pero a día de hoy está por delante PMD (aunque es un poco sospechoso ya que si buscamos en google sólo por PMD obtenemos casi 6 millones de ocurrencias, eso si el proyecto en sourceforge es la primera) y seguido muy de cerca por
FindBugs.

También se puede apreciar que estas herramientas están tenido mucho más éxito en países como la India o Japón que en los países hispanohablantes de los cuales no aparece ninguno en las 10 primeras posiciones, aunque me imagino que esto será debido al volumen de software desarrollado en cada zona.

Cuando saque un rato me gustaría echarle un vistazo a estas tres, ver si se pueden integrar en alguna de las IDEs más populares, evaluar usabilidad, rapidez, calidad de los informes, etc.

¿Tenéis experiencia en el uso de alguna de estas herramientas?, ¿Cuál de ellas o que combinación de ellas usáis?

Otros artículos relacionados:

javaHispano Persiguiendo la calidad del código
javaHispano PMD v4 publicado
javaHispano Checkstyle 4.2 publicado

También existen voces críticas en lo que a este tipo de herramientas se refiere.

delicious | digg | technorati | yahoo | meneame